MVPのリリースは、本来であれば勝利の瞬間のはずだ。エージェンシーを見つけ、価格交渉を終え、3ヶ月でリリースし、最初のユーザーを獲得した。デモは見栄えがいい。投資家も関心を示している。次の機能セットについて考え始めている。
それから6ヶ月後、メイン開発者が退職する。あるいは決済ゲートウェイを追加しようとすると、バックエンド開発者が8週間かかると言い出す。あるいは新しいエージェンシーに引き継いでもらおうとすると、前のチームが何を作ったのかを理解するだけで2週間欲しいと言われる。
これが時限爆弾の爆発だ。そして導火線に火がついたのは、外注MVPが書かれたその日だった。
技術的負債の実態
技術的負債は抽象的な概念ではない。外注MVPでは、予測可能なパターンとして現れる。経験豊富な開発者であれば、コードベースを開いた瞬間に気づくものだ。
スパゲティルートと肥大化したコントローラー。 クリーンなモジュラーアーキテクチャの代わりに、認証、ビジネスロジック、データベースクエリをすべて一つのコントローラーに詰め込む。新機能を追加するには、絡み合ったコードを解きほぐす必要がある。そもそもそのコードは解きほぐされることを想定して書かれていない。
環境管理の欠如。 認証情報、APIキー、データベースURLがソースファイルに直接ハードコードされている。.envファイルもなく、シークレット管理もなく、ステージングと本番環境の設定分離もない。本番でエラーが発生してもローカルで再現できない。「本番環境」が何を意味するのか、誰もドキュメント化していないからだ。
テストカバレッジゼロ。 予算プレッシャーを受けた外注チームはテストを完全に省略する。リグレッションを検知する仕組みがない。変更のたびに賭けをしているようなものだ。デプロイは恐怖のイベントになる。
ドキュメントの不在。 前のチームは自分たちの判断の理由を知っていた。今、彼らはいない。新チームはREADMEも、アーキテクチャ図も、非自明な部分のインラインコメントもないコードベースを引き継ぐ。新しい開発者のオンボーディングに何ヶ月もかかる。
意図せぬベンダーロックイン。 エージェンシーが独自ツール、ドキュメント化されていないサードパーティ統合、または自社のインフラ上（あなたのものではない）で重要なサービスをホストしていた場合、彼らがいなくなればアプリも消える。
見えないコスト
契約書にサインする時、数字は魅力的に見える。「MVP 300万円——やろう。」しかし請求書には、その後に何が起きるかは書かれていない。
保守性を考慮せずに構築されたコードベースは、コストが急速に積み重なる：
- 開発者のオンボーディングは、ドキュメントがなくアーキテクチャが一貫していないため、通常の2〜3倍の時間がかかる。
- 新機能の追加には、新しいコードを書く前に既存コードを解きほぐす作業が必要になる。1日で終わるはずのタスクが1週間になる。
- バグが増殖する。 テストカバレッジがなければ、修正が新たな問題を生み出す。QAサイクルが終わらない。
- 最終的に、誰かがその言葉を口にする。 書き直し（リライト）。
完全なリライト——元のコードベースが拡張不可能なほど壊れているため最初からやり直すこと——は通常、元の開発コストの3〜5倍かかる。300万円のMVPが、1,200万〜1,500万円のリライトになる。さらに、火消しに追われていた間の数ヶ月分の機会損失も加わる。
これは仮説ではない。スタートアップ界では繰り返される話だ。2026年、コスト削減のために初期構築を外注する企業が増え、スケールしようとした時に壁にぶつかるケースはさらに増えている。
引き継いだコードベースを監査する際の警告サイン
別のエージェンシーからコードベースを引き継いだ場合、あるいは契約前にコードベースを評価している場合、以下の点を確認しよう：
コミット履歴を確認する。 すべてのコードが1回のコミットでプッシュされていた場合、チームがバージョン管理の規律なしにローカルで作業していたサインだ。健全なコードベースには、どのように構築されたかの物語を伝える、明確でインクリメンタルなコミット履歴がある。
.env.exampleファイルを探す。 存在しない場合、アプリが必要とする環境変数のドキュメントがない。これは専門性の基本的なシグナルだ。
テストスイートを実行する。 テストスイートがなければ、それだけで全てが分かる。あれば実行して、コードベースのどれだけをカバーしているか確認する。
最も大きなコントローラーを開く。 1ファイルが300〜400行を超えていれば、やりすぎだ。そこに複雑さ——そしてバグ——が潜んでいる。
デプロイプロセスを聞く。 チームの誰もが暗黙知なしにデプロイできるか？答えが「このスクリプトを実行する」ではなく「○○さんに聞かなければならない」なら、CI/CDパイプラインが存在せず、1人の退職でデプロイ危機が起きる。
ハードコードされた値を探す。 localhost、password、または設定ファイル内の実際のAPIキーなど、一般的なパターンをコードベースで検索する。見つかれば、即座に対処すべきセキュリティ問題を発見したことになる。
責任あるエージェンシーが提供すべきもの
コードは最低限だ。責任あるエージェンシーは、彼らが去った後もあなたが実際に所有・運用できるコードベースを提供する。それは以下を意味する：
機能するREADME。 開発環境のセットアップ方法、テストの実行方法、デプロイ方法を説明するもの。どの新しい開発者でも、誰かに連絡することなく従えるもの。
環境設定。 シークレットをコードから分離する。.envファイル、文書化された変数、開発・ステージング・本番環境向けの異なる設定。
CI/CDパイプライン。 自動テストとデプロイは贅沢ではない。チームが自信を持ってリリースできるためのベースラインだ。
テストカバレッジ。 100%は不要——MVPのタイムラインでは非現実的だ。しかし認証、決済、コアビジネスロジックなど重要なパスにはテストが必要だ。
引き継ぎノート。 アーキテクチャの意思決定、既知の問題、サードパーティの統合、新しい開発者が知る必要があることを説明した文書。これは誰かの頭の中だけに存在してはならない組織の記憶だ。
あなたのインフラ、彼らのものではなく。 アプリはあなたのアカウント——あなたのクラウドプロバイダー、あなたのドメインレジストラー、あなたのメールサービス——で動作すべきだ。プロバイダーを変えずにエージェンシーを変えられるべきだ。
契約前に確認すべき質問
エージェンシーの実践を評価する適切なタイミングは、前払い金を渡す前だ。以下を質問しよう：
「過去のクライアントに納品したコードの例を見せてもらえますか？」 自信のあるエージェンシーは、サニタイズされたコードベースを見せるか、以前のプロジェクトのアーキテクチャを説明することをためらわない。
「MVPビルドにおけるテスト戦略はどのようなものですか？」 正しい答えには、少なくとも重要なパスのユニットテストが含まれる。間違った答えは「テストは後で追加します」だ。
「プロジェクト終了時にリポジトリとホスティングアカウントは誰が所有しますか？」 すべてあなたの名義であるべきだ。躊躇するようであれば、それは危険信号だ。
「引き継ぎはどのように行いますか？」 プロフェッショナルなエージェンシーには標準的な引き継ぎプロセスがある。困惑した顔をするなら、ローンチ後に何が起きるかを考えたことがないということだ。
「CI/CDのセットアップはどのようなものですか？」 自動化パイプライン、ステージング環境、デプロイスクリプト——これらは標準であるべきで、オプションではない。
これらの質問をすることは、難しい客になることではない。重要な投資を守ることだ。基本的な透明性に抵抗するエージェンシーは、コア製品を構築させるべき相手ではない。
最初から正しく構築する
外注市場には、デモで見栄えのするものを構築してくれるエージェンシーがあふれている。長く使えるものを構築してくれるところは少ない。その違いは提案書には必ずしも見えない——アーキテクチャの意思決定、コードの品質、そしてプロジェクト終了時に何が引き渡されるかに現れる。
MVPは捨てることを前提としたプルーフオブコンセプトであってはならない。その上に積み上げていける基盤であるべきだ。採用するチームがその違いを理解しているか、確認しておこう。
