MVPの作り直しの多くは、元のコードが悪かったから起きるわけではありません。相応の理由と本当の時間的プレッシャーの中で下された、ほんの一握りの初期の意思決定が、いつの間にかプロダクトの成長を支えきれない前提になってしまうことが原因です。良い知らせは、本当に重要な意思決定はごくわずかであり、そのどれもがMVPのスピードを落とす必要がないということです。
単一サービスとしてデプロイする場合でも、モジュールの境界は引いておく
モノリスはMVPにとって十分に理にかなった選択です——問題があるとすれば、それは内部境界のないモノリスです。課金ロジック、認証ロジック、コアとなるドメインロジックが共有の可変状態を通じて絡み合っている場合、後でそれらを分離することは「切り出し」ではなく「もつれをほどく作業」になります。単一のデプロイ単位の中であっても、初日から明確なモジュール境界とその間の明示的なインターフェースを保っておけば、将来のサービスへの切り出しは書き直しではなくリファクタリングで済むようになります。
データモデルは最初の画面のためではなく、ビジネスのために設計する
最初のUIが必要とするものに合わせてデータベーススキーマを形作りたくなるのは自然なことです。しかしそれがうまくいくのは、二つ目の機能が同じデータを別の切り口で必要とするまでです。その時点で、あなたはプレッシャーの中でライブデータを移行する羽目になります。中核となるエンティティは、それがビジネス上実際に何を表しているかに基づいてモデル化し、ビューやAPIのほうを画面に合わせて適応させましょう。逆ではありません。
最初からサービスをステートレスに保つ
セッション状態やリクエスト状態をアプリケーションのメモリに保存することは、書き直しなしには水平スケールできないものを作ってしまう最も確実な方法です。最初から状態はデータベース、キャッシュ、あるいはセッションストアに置きましょう。MVP規模ではほとんどコストがかからず、チームが最初の本格的なトラフィックの急増でリクエスト処理層全体を作り直す羽目になる、最もありがちな原因の一つを取り除いてくれます。
まだ手にしていない規模のために作り込まない
ここまでの話の裏返しも同じくらい重要です。トラフィック量、チーム規模、あるいは信頼性要件がその複雑さを正当化する段階に達する前に、マイクロサービス、イベントソーシング、マルチリージョン構成に手を出さないことです。MVPを過剰に設計することもまた一種の技術的負債であり、それは書き直しという形ではなく、単に開発速度の低下という形で現れます。
「検証してから」ではなく、初日からCI/CDとテストを組み込む
初期のスピードを優先して自動テストやデプロイパイプラインを省略するチームは、ほぼ例外なく、後になって利息付きでその代償を払うことになります——本番インシデントという形か、あるいは古いコードに触れることへの恐怖という形で、それが今後のあらゆる変更を遅くしていきます。軽量なCI/CDと意味のあるテストスイートは、最初に一日か二日のコストがかかるだけで、コードベースが成長していく中でもスピードを落とさず出荷し続けるための自信を与えてくれます。
これはMVPに必要以上のものを作り込むという話ではありません。モジュール境界、データモデリング、ステートレス性、リリースの規律——後から覆すのにコストがかかる少数の決定を意図的に行うことで、後から変更しやすい部分は安いままにしておき、そうでない部分がシリーズAの段階で書き直しを強いることのないようにする、という話です。