MVPが「負債の塊」になるのはなぜか

MVPを作り終えた直後に「テストもドキュメントもない、何がどう動いてるかわからないコード」が手元に残る——この経験、ある人には刺さるはずだ。

元記事の著者はこれをはっきり問題として指摘している。「速さだけなら Vibe Coding でいいですが、それだと MVP ができた後に『テストもドキュメントもない、何がどう動いてるかわからないコード』になりがち」。

Vibe Codingは勢いで動くものを作るには強い。ただ、その後の保守フェーズで詰む。エージェント駆動開発はそこへの回答として提案されている手法だ。

エージェント駆動開発の全体像

構成はシンプルで、PM・Dev・QAの3つのAIエージェントがサイクルを回す。人間は設計と意思決定に集中する。

ポイントは、開発に入る前に3ステップの準備があること。ここを飛ばして「とりあえず作って」とやると、後から全部やり直すハメになる、と元記事は言い切っている。意思決定は多めになるが、それが後の保守性を担保する。

準備フェーズの中身：ここを飛ばすと全部やり直し

Step 1：UI/UXファースト

コードを書く前にモックアップを作る。具体的な方法としては、HTML + Tailwind でサクッと作り、Netlify に上げてスマホで確認する。「この段階では動かなくていい。見た目だけ」という割り切りが明確だ。

モックアップを先に作ることの効果は3つある。テスト戦略が見える（「画面遷移が複雑だからE2Eが要るな」と気づける）、仕様の抜け漏れが減る（「この画面のエラー時ってどうなる？」という問いが出やすい）、AIが完成イメージを理解して実装できる。

Step 2：仕様の整理

モックアップをもとに仕様書を作る。概要・ターゲット・機能一覧（MVP対象かどうかのフラグ付き）・データモデル・画面フロー・技術スタックを整理する。元記事ではMarkdownのテンプレートが具体的に示されており、「何を作るか」をここで確定させる。

Step 3：品質基盤の決定

ここが一番大事、と元記事は明言している。具体的には、ISO/IEC 25010の品質特性をベースに、このシステムで何を重視するかを最初に決める。

品質特性からテストの種類が自動的に導出される仕組みになっている。たとえば「機能適合性」ならUnitテスト・Integrationテスト、「セキュリティ」なら入力検証テスト・認証テスト・シークレット検出、「使用性」ならE2Eテスト・スナップショットテストという対応だ。

「AI分析アプリ（個人利用）」の例では、負荷テストは「同時アクセスを考慮する規模ではない」として明示的に除外している。採用しない理由を書くというのが、後から見たときに判断の経緯が分かって助かる部分だ。

セキュリティ方針も同様に、「MVPではここまで、本開発ではここを追加」を明示する。認証をIP制限で済ますのかSSOまで入れるのかを最初に決めておくことで、後から「あれ、認証どうするんだっけ」にならない。

ドキュメントについても「MVP完成後にまとめて書く」を避けるため、何をいつ書くかをここで決める。API仕様書はAPIを追加するタスクごと、ADRは技術選定があったとき、アーキテクチャ図・ER図はMVP完成時——という具合に事前にスケジューリングしておく。

タスクサイクルの設計：完了条件にテストとドキュメントを最初から入れる

品質基盤が決まったら、PM → Dev → QAのサイクルでタスクを回す。

PMが出力するタスク定義には、最初から「テスト要件」と「ドキュメント要件」が完了条件として含まれている。元記事の例では「POST /api/sessions で結果をD1に保存できる」「不正な入力に400を返す」という完了条件に加え、「Unit: バリデーションロジック」「Integration: POSTの正常系・異常系」「API仕様書にPOST /api/sessionsを追加」がセットで記述されている。

DevはTDDで実装し、タスク完了時に対応するドキュメントも更新する。完了条件に書かれていない機能は実装しない、というルールが明確だ。

QAのチェック項目は品質基盤から自動的に決まる。完了条件・テスト・セキュリティ・ドキュメント・コード品質（lint + typecheck）を毎回同じ基準で確認する。「QAが毎回『何を見るか』を考える必要がない」という設計になっている。不合格なら具体的な理由をつけてDevに差し戻す。

AIおじさんの見方：「品質基盤の先出し」が本質

この手法で面白いのは、品質基盤を「開発前に決める」という構造にある。普通、テスト戦略やセキュリティ方針は開発が進んでから後付けで考えがちだ。でもそうすると、個々のタスクの完了条件が「動いたらOK」になってしまう。

ここで逆転の発想がある。品質基盤を先に決めておくことで、PMのタスク定義・Devの実装ルール・QAのチェック項目が全部そこから「自動的に」導出される。つまり、品質基盤が決まれば、後の判断コストが大幅に下がる。

ISO/IEC 25010を使うのも実用的な判断だ。「何を重視するか」を議論するとき、共通の語彙があると話が速い。抽象的な「品質を大事にしよう」ではなく、「機能適合性 > 性能効率性」と順序付けができるから、テストの取捨選択に根拠が生まれる。

MVP完成時点で揃っているもののリストも具体的だ。テスト・API仕様書・状態遷移図・ADR・セキュリティ方針・アーキテクチャ図・ER図。これが揃っていれば、次のフェーズからドキュメントファースト開発にそのまま移行できる、というのが設計の目標になっている。

実務的な示唆

すぐ全部を取り入れるのは難しくても、Step 3の「品質基盤の決定」だけを先にやる習慣から始めるのは現実的だ。「このシステムで何のテストを書くか・書かないか、理由付きで最初に決める」というだけで、後から「なぜここにテストがないんだ」という問い直しがなくなる。

人間の介入ポイントも明確に定義されている。品質基盤の承認・タスクごとのPM完了条件の確認・QA合格後の差分レビューと動作確認。このうち「品質基盤の承認」と「QA合格後のレビュー」はスキップ不可とされている。エージェントに任せるところと、人間が必ず見るところを分けるという考え方は、どんな開発フローにも応用できる。

"保守性のあるMVPを高速に作る"という目標は地味に聞こえるが、MVPを作った後に「さあ本開発」とならずに詰む経験をした人には、かなり刺さる話だと思う。