LIGHTz は 今年(2022)の10月に念願の SaaS プロダクト "Pincy Park" をリリースしました。
BtoB でマルチテナントな構成です。
SaaS 開発の 0 -> 1 を経験して、各フェーズ毎にできていてよかったこと、できていなくて後悔していることをプロジェクト立ち上げに参画したバックエンドエンジニアの立場から見たことをまとめてみたいと思います。(最初はフルアサインでないので、見えていない部分もあります)
フェーズ1: プロジェクト立ち上げ期
できていてよかったこと 
- 正社員採用活動
- 1年近く先まで事業計画が立っていたので、採用活動が進められた
- (明日も分からない組織に人を誘うことはできない)
- エースエンジニアを専任でプロダクトに貼り付けること
- 受託開発途中だったので、アサインリソースが限られていた
- 全員で半々のアサインをするのではなく、フロントもバックエンドもできるメンバーが土台作りにフルコミットできるようにサポートした
- プロダクトの特性に合ったアーキテクチャーを Microsoft と相談
- プロダクトの特性に合ったアーキテクチャーをプロダクトを作り込み始める前に Microsoft にレビュー・相談ができた
- 技術スパイクに使う時間が限られている中で後は自分たちの手を動かすだけに近づけることができた
- 事前にテナントのリソース分離の方向性を調査して実装したので途中での大きな混乱はなかった
- docker compose をベースとした開発環境の整備
- Mac, Win ユーザーが入り乱れる中で比較的開発環境による混乱は少なかった
- 組織で実績のあるフロント技術で開発初期を安定させられた
- 別プロダクトで培われた Vue のベースを転用して、リードフロントエンジニアがアサインできなくてもクローズドベータ中期まで開発できた
- 採用面談では React をメインに使う方の方が多かった
できていないくて後悔していること 
- プロダクトの再命名
- ドメインを再取得する手間が省けたものの、過去に開発した Pincy Park とリソースがぶつかることが多々発生
- サービス内容も微妙にピボットしているため、再命名してもよかったかもしれない
- タブレット・スマホ対応を明確にしておくべきだった
- UIの作り方が異なるため
- 導入企業が所属する業界の典型的なセキュリティガイドラインと自分たちが必要だと思うセキュリティのギャップ調査をしてから要件を作っても良かったかもしれない
- 公式エミュレータが無いインフラリソースを使い、且つ自作自演モックを実装した結果、ローカルでテストができない部分がある
- まさにこれ
-
データアクセスレイヤのテストを書く際にDBをモックするのは自作自演のテストになりがちなので個人的にはおすすめしません / “Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog” https://t.co/3YIcK3ptU9
— Takuto Wada (@t_wada) November 24, 2022
フェーズ2: クローズドベータ開発期
できていてよかったこと
- クローズドベータ開発中期には採用計画を満たすメンバーがジョインしていた
- 正社員採用目的で声をかけた方が経験豊富なSREが業務委託で壁打ち相手になってくれた
- トラブルを未然に防げている
- 気づかなかった視点が得られている
- 後は手を動かすだけに近い状態が維持できている
- 認証にIDaasを利用
- マイグレーション(後述)もスムーズだった
- 認可の仕組み
- OpenAPIとOAuthの連携
- CI・CDの自動化
- ドメイン用語と実装のネーミングがずれていた部分の修正
できていないくて後悔していること
- 本番環境の構築を後回しにしたら顧客のお試し環境が本番環境になった
- 費用面やアーキテクチャーの成熟度、機能開発優先などの理由で後回し
- お試しの約束が本番さながらの運用になり、本番環境へのマイグレーションに時間と神経を使うことになった
- バックエンドの実装方針を明文化できておらず、実装方法が個人に委ねられる部分が生まれた
- 初めて使うDBとORMの理解不足によりMigration回りで負債が噴出した
- クローズドベータ開発期で多くを回収済み
- ライブラリのメジャーアップデートを自動化しておくべきだった
- リリース後は前に比べるとハードルが高い
- コードカバレッジの目標設定
- リファクタリングとリグレッションテストのコストに直結してくる
- リグレッションテスト方針設定
- 人力でカバーするのか、unittestのカバレッジでするのか、E2Eを回すのかを決められていない
- request object を router 層以降も使用しまっている実装があること
- N+1 を意識した実装
- 早くもリリース直前期でデータアクセスのパフォーマンスの悪さが顕在化した部分がある
- バッチ削除の実装
- 削除系の処理でバッチ削除するべき実装が単体削除で無理を通している部分がある
- dev と stg 環境のインフラリソースの分離
- dev と stg 環境のインフラリソースが一部共有されているため、インフラのコード化に障っている
フェーズ3: リリース直前期
できていてよかったこと
- 新規テナント追加のオペレーションをCSチームに引き渡すこと
- デプロイスロットを用いてほぼ本番環境で動作確認ができること
- 各種インフラリソースの認証にAzureADTokenを用いること
- 安心感が格段に違う
できていないくて後悔していること
- サインアップフローがわかりづらい
- CSチームが運用でカバーしている
- もっとあるはずだけど、なんか出てこない、ごめんなさい
最後に
以上です。
人は成長するので、もっと良くできる=負債と認識していまいますが、
肥大化する前に適切なフェーズで潰していきたいですね 
最後まで読んで頂きありがとうございました。
弊社、別プロダクトで絶賛採用中です
https://www.wantedly.com/projects/1181162