8月21日、Georgy Starikovが「Waterfall 2.0: Controlling LLM-Driven Software Development with Stage-Gated Discipline」と題した記事を公開した。この記事では、LLMを活用したソフトウェア開発においてウォーターフォールを「軽量な制御構造」として復活させる「Waterfall 2.0」という開発手法について詳しく紹介されている。
「ウォーターフォールは死んでいなかった」——LLM時代の逆説
Agileに葬られたはずのウォーターフォールが、LLMによって蘇りつつある。
この一見逆説的な主張を打ち出したのは、実際の統合プログラムにこのアプローチを繰り返し適用してきたStarikovだ。彼の論旨はシンプルで説得力がある。ウォーターフォールが嫌われた理由は「フィードバックが遅すぎた」からであり、LLMがその速度問題を解消した今、ウォーターフォールの構造的な強みが再び有効になる、というものだ。
Agileが「小さなバッチで素早くフィードバックを得る」のに対し、ウォーターフォールは「全体を一貫した設計に整合させる」のが得意だ。複雑に絡み合うマイクロサービス群や共有データプラットフォームでは、純粋にインクリメンタルなアプローチが断片的なアーキテクチャや技術的負債の蓄積につながる——そこにウォーターフォールの構造がフィットする、という指摘は現場感がある。
Waterfall 2.0を成立させた4つの技術変化
元記事執筆時点（2025年）では、以下の4つの開発が収束したことでこのアプローチが現実的になったとStarikovは整理する。
- ロングコンテキストウィンドウ：最新モデルは最大100万トークンを処理でき、プロジェクト全体のアーティファクトを一度にロードして横断的に推論できる
- 高推論モード（Extended Thinking）：単なる高速テキスト生成ではなく、大規模な相互依存セットにわたって一貫性を保てる
- ツール連携とMCP：Model Context Protocol（MCP）により、モデルがライブデータやツールを標準化された方法で呼び出せる
- コーパス全体への推論：これらが組み合わさることで、1つのLLMセッションが「小規模ながら連携のとれたエンジニアリングチーム」のように機能する
5ステージのパイプライン
Waterfall 2.0の核心は、以下の5段階のパイプラインだ。
| ステージ | 所要時間 | 概要 |
|---|---|---|
| Vision（ビジョン） | 30〜60分 | コア課題・制約・成功基準を記した簡潔なドキュメント |
| ADR（アーキテクチャ決定記録） | 2〜3時間 | 主要コンポーネントに関するアーキテクチャ決定を記録 |
| プロトタイプ | 1〜2日 | ライブラリ互換性・実現可能性を検証する実験的コード |
| アーキテクチャスケルトン | 約2時間 | 散在するプロトタイプを統一プロジェクト構造に統合 |
| コード＋テスト | 0.5〜2日 | 蓄積アーティファクトをコンテキストに持たせて最終生成 |
各ステージの要点を補足する。
Visionでは、ステークホルダーのメモ書きをLLMに渡して構造化させる。ADR（Architecture Decision Records）はコンパクトで決定事項に集中したフォーマットであり、LLMとの相性が良く、高推論モードで2〜3サイクル（各15〜30分）繰り返してレビューする。プロトタイプについてStarikovは「プロトタイピングはほぼゼロコストになったため、必須フェーズになった」と述べている。コード＋テストのフェーズでは、テスト戦略として「ダイヤモンドモデル」を強く推奨している——ユニットテストは最小限（独自の価値がある箇所のみ）、インテグレーションテストに重点、E2Eテストはクリティカルパスのみ、という構成だ。
最大の差別化要因：「バブルソート的バックトラッキング」
従来のウォーターフォールで最大の問題だった「後戻りのコスト」が、Waterfall 2.0では逆に強みになる。
プロトタイピング中に根本的な欠陥が見つかった？ Visionに戻り、更新して、ADRを再生成し、再プロトタイプする。このサイクル全体が数週間ではなく数時間で完了する。
Starikovはこれを「バブルソート的バックトラッキング」と呼ぶ。要素が正しい順番に落ち着くまでスワップし続けるように、問題を発見するたびに前のステージに戻って修正することが奨励される。修正コストが低いため、問題の早期発見が報われる構造だ。
ナレッジコーパスという中心概念
このアプローチ全体を支えるのが、「ナレッジコーパス」——要件ノート、ADR、ソースコード、スキーマ、図、テレメトリなどを1つのディレクトリやリポジトリに集めた共有知識基盤だ。
定量的な根拠（データ量、スループット、テールレイテンシなど）が必要な場合も、自分でクエリを考える必要はない。モデルにMCP経由でツールアクセスを与えるか、適切なSQL、PromQL、k6スクリプトを生成させ、その結果をコーパスに戻せばよい。Starikovはこれを「実践的な幻覚対策メカニズム」と位置づけている——仮定ではなく実測値をコーパスに入れることが、LLMの出力の信頼性を担保する。
エンジニアの役割シフト：「コンビシェイパー」の復活
Starikovが提唱するのは、「コンビシェイパー（combi-shaper）」という役割概念だ（本記事内でStarikovが用いる独自の表現）。約30年前、エンジニアの多くはエンディアン、ELFフォーマット、x86のNOP命令の効果まで知りながら、顧客の課題に向き合って開発をリードする存在だった。Web時代の分業化でその役割は失われたが、LLM時代にそれが高い抽象レベルで復活する、というのが彼の見立てだ。
生成が高速になった結果、本当のボトルネックはバリデーションと意思決定に移る。ロールを細かく分割しすぎると学習ループが壊れ、長期的な生産性を下げる。Waterfall 2.0では、1人のエンジニアが要件からコードまでのフルループを担えるようになるが、その代わりに求められるのは「コーパスのキュレーション」「LLMのオーケストレーション」「トレードオフの最終判断」だ。
この変化は、機械語からアセンブリ、CへとLLMが登場するまでの抽象化レベルの上昇という長い連続線上の、次の一段として捉えられている。
詳細はWaterfall 2.0: Controlling LLM-Driven Software Development with Stage-Gated Disciplineを参照していただきたい。
