11月16日、「Spec-Driven Development: The Waterfall Strikes Back」と題したブログ記事が公開され、海外で話題を呼んでいる。この記事では、仕様書駆動開発（Spec-Driven Development; SDD）がAI時代のプログラミングに秩序をもたらすという期待と、冗長な文書作成がアジリティを損なうという懸念の両面について詳しく紹介されている。以下に、その内容を紹介する。

仕様書駆動開発（SDD）の台頭

チャット入力を中心に据えるコーディングアシスタントは、従来のIDEと比べ手がかりが少ない。そこでオープンソース界隈では、初期プロンプトと数個の指示からLLMに「仕様」「実装計画」「タスクリスト」を生成させ、ユーザーが追記・修正し、完成した文書群をコーディングエージェント（Claude Code、Cursor、Copilot等）へ渡す、という流れが生まれている。これがSDDである。

Birgitta Böckelerによる比較記事「Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl」など、ツール群の解説も出始めている。

Markdown化する仕様――現場の実例

仕様は多くの場合、複数のMarkdownファイルとして生成される。GitHubのspec-kitを用いた例では、小さな機能追加でも8ファイル・約1,300行のテキストになったという。

Kiroによる小規模機能（Atomic CRMへの「紹介元」フィールド追加）でも、Requirements・Design・Tasksといった文書が整然と並ぶ。見た目は整っているが、運用してみると様々な課題が見えてくるという。

著者が指摘するSDDの短所

以下は記事が挙げる代表的な問題点である。

• 文脈の見落とし：SDDエージェントは検索とファイル回遊で文脈を推測するため、既存関数の更新漏れなどを起こしやすい。結局、業務・技術の両面レビューが必要になる。
• Markdown過多：設計段階の記述量が過剰になりがちで、開発者は冗長な文書を読む時間が増える。些末な誤りが饒舌な文章の中に埋もれる。
• 書類主義の制度疲労：三段階設計（要件→設計→タスク）が大半のケースで過剰最適化となり、重複・想像上のコーナーケース・過度の微修正が積み上がる。
• 擬似アジャイル：ツールが生成する「ユーザーストーリー」は定義を外すことが多く、実害は薄いがノイズになる。
• ダブルコードレビュー：技術仕様内にコード断片が含まれるため、実装前後で二重にレビューが発生し、負担が倍化する。
• 安心感の錯覚：仕様でエージェントを拘束する狙いに反し、実際には仕様を逸脱することがある。単体テスト未実装にも関わらず「検証済み」とマークする例も見られた。
• 収穫逓減：ゼロからの新規開発では効くが、既存大規模コードベースではポイントを外し、開発が遅くなる。

多くのコーディングエージェントがすでに「計画モード」や「タスクリスト」を備える現状では、SDDが上積みする価値は限定的だと総括している。

「プロジェクトマネージャーの逆襲」か、それとも逆行か

SDDが未成熟ゆえに成果が出ていない可能性はある。しかし筆者は、SDDが本質的に誤った課題設定――「開発者を開発から排除する」――に根ざすと批判する。重厚な文書を先行させる点で、SDDはウォーターフォールやBig Design Up Front（BDUF）を想起させるが、いずれも仮説を積み上げる構造により失敗しがちである。ソフトウェア開発は本質的に非決定的であり、計画では不確実性を排しきれないという立場だ。

さらに、要件段階の誤りを見抜くにはビジネスアナリストの素養が、設計段階の誤りを見抜くには開発者の素養が要る。結局、両方を兼ね備えた稀有な人材にしか有効に扱えず、「ノーコード」と同様に「開発者不要」を謳いながら開発者依存を深める、と指摘する。

代案：自然言語開発（NLD）とアジャイルの組み合わせ

アジャイルは、予測可能性を適応性に置き換えることで非決定性に向き合ってきた。筆者は、複雑な要件を複雑な設計文書へ翻訳するのではなく、複雑な要件を小さな要件へ分割し、エージェントで安価に検証を繰り返す道を推す。リーンスタートアップに倣ったシンプルな運用手順は以下の通りである。

1. プロダクトで最もリスキーな仮説を一つ選ぶ。
2. それを検証する最小の実験を設計する。
3. 実験を実装し、失敗なら②へ戻り、成功なら①から繰り返す。

3Dスカルプトツールの事例では、仕様書なしで小粒な要求を積み重ね、エージェントの誤解や自身の仮説の誤りを都度修正しながら短時間で到達したという。可視化やブラウザ操作の成熟度（例：Playwright MCP Server）には不満が残るものの、エージェントはアジャイルを加速し、バックログからリアルタイムにプロダクトを立ち上げる力を持つと結論づける。

結論

アジャイルはすでに仕様書中心の開発を過去のものにした。SDDは、エージェントの力を本来の方向――自然言語で反復的に作る開発者の増幅――ではなく、文書と計画の再肥大化へ引き戻す危険がある。内燃機関を機関車に閉じ込めるのではなく、車や飛行機へ展開したように、エージェントもまた自由度の高い使い方へ開くべきだ、という比喩で締めくくられている。

詳細はSpec-Driven Development: The Waterfall Strikes Backを参照していただきたい。