- Spec-Driven Development（SDD） は、コーディング前に膨大な文書を作成するウォーターフォール型アプローチを復活させた手法で、AIコーディング支援ツール向けの構造化を目的とする一方、俊敏性を損なうおそれがある
- オープンソースコミュニティでは、初期プロンプトと指示に基づいて仕様書・実装計画・作業リストを自動生成するツールが開発されており、代表例としてSpec-Kit、Kiro、Tessl、BMad Methodがある
- しかし実際に使うと、コンテキスト認識不足、過剰な文書化、二重コードレビュー、虚偽の安心感など、さまざまな限界が明らかになり、大規模コードベースでは効率が急激に低下する
- この記事は、SDDが開発者を置き換えようとする試みとしてウォーターフォールモデルの失敗を繰り返していると指摘し、代わりに自然言語ベースの反復的な開発手法を提案する
- AgileとLean Startupの原則を組み合わせたアプローチのほうが、コーディングエージェントを活用する現代の開発により適しており、視覚的インタラクションツールの発展が次の課題だ
スペック主導開発（SDD）の登場
- Spec-Driven Development（SDD） は、AIコーディング支援ツール向けに構造的な開発方式を提供するため、コーディング前に仕様文書を作成する手順を導入する
- 初期プロンプトと指示をもとに、LLMが製品仕様書、実装計画、作業リストを生成する
- 各文書は前段階に依存しており、ユーザーが修正して仕様を洗練させる
- 完成した文書はClaude Code、Cursor、Copilotなどのコーディングエージェントに渡され、コード作成に活用される
- 代表的なツールとして**GitHubのSpec-Kit、AWSのKiro、Tessl、BMad Method（BMM）**などがある
- 関連する比較分析として、Birgitta BöckelerのUnderstanding Spec-Driven-Development: Kiro, spec-kit, and Tesslに言及している
Markdown文書化の問題
- SDDの仕様は大半がMarkdownファイル形式で構成されており、例としてGitHub Spec-Kitで単純な機能を実装した場合でも8ファイル、1,300行に達する
- Kiroを使ってAtomic CRMに「referred by」フィールドを追加した事例でも、多数の文書に分割されている
- 実際の利用では、次のような欠点が表れる
- コンテキスト認識不足（Context Blindness）：既存の関数やコードの文脈を取りこぼし、依然として専門家のレビューが必要
- 過剰な文書化（Markdown Madness）：長大な文書のため、単純なエラー探索にも多くの時間を消費する
- 体系的官僚主義（Systematic Bureaucracy）：不要な反復と過度な詳細化によって非効率が生じる
- 見せかけのアジャイル（Faux Agile）：「User Story」の概念を誤用し、散漫さを招く
- 二重コードレビュー（Double Code Review）：仕様内のコードと実際の実装をそれぞれレビューしなければならない
- 虚偽の安心感（False Sense of Security）：エージェントが仕様に完全には従わない
- 逓減する効用（Diminishing Returns）：初期プロジェクトでは有用でも、規模が大きくなるほど速度が低下する
- ほとんどのコーディングエージェントはすでにplan modeやtask list機能を備えているため、SDDの追加的な利点は限定的で、むしろ開発コストを増やす可能性がある
プロジェクトマネージャーの逆襲
- SDDの限界はツールの未成熟さによるものかもしれないが、根本的には誤った問題設定に由来する
- 「開発者をソフトウェア開発から排除する方法」という目標を前提にしている
- 開発者をコーディングエージェントに置き換え、それを緻密な計画で統制しようとする構造だ
- これはウォーターフォールモデルに似ており、膨大な文書化によって開発者を単なる翻訳者の役割にしてしまうやり方だ
- しかしソフトウェア開発は非決定的（non-deterministic）な過程であり、計画だけで不確実性を取り除くことはできない（No Silver Bullet論文を引用）
- SDDでは要件定義段階でビジネスアナリスト、設計段階で開発者の専門性がいずれも必要になるため、実際には両方の役割を担える少数の人しか使えない
- 結果として、No Codeツールと同様に「開発者なしの開発」を約束しながら、結局は開発者を必要とする
新たな代替案：自然言語ベースの反復開発
- Agile手法は、予測可能性ではなく適応性を選ぶことで、非決定的な開発問題に対処する
- 複雑な要件を複数の単純な問題に分割することが、コーディングエージェント活用の核心だ
- Lean Startupの原則を適用したシンプルな反復手順を提示する
- 製品における最もリスクの高い仮説を特定する
- それを検証するための最小限の実験を設計する
- 実験を開発し、結果に応じて反復する
- 例として、Claude Codeを用いて約10時間で**3D彫刻ツール（sculpt-3D）**を開発した
- 仕様書なしで短い指示文だけを使い、機能を段階的に追加した
- 誤った実装は即座に修正し、高速な反復を行った
- この方式ならウォーターフォール型の文書化がなくても素早く収束でき、Agileとコーディングエージェントの組み合わせによってリアルタイムのプロダクト構築が可能になる
- ただしコーディングエージェントはテキスト中心のため視覚的インタラクションが不足しており、今後は視覚的インターフェースを強化するツールの開発が必要だ
結論
- Agile手法はすでに仕様文書を不要なものにしており、SDDはそれを復活させようとする試みだと評価される
- SDDは開発者を排除しようとする理論先行のアプローチであり、コーディングエージェントによる新しい開発者世代の能力強化の機会を逃している
- コーディングエージェントを内燃機関になぞらえ、SDDがそれを機関車に縛りつける一方で、私たちは自動車・飛行機など多様な形へ拡張すべきだと述べる
- 最後に、環境を考慮するならコーディングエージェントの節度ある利用が必要だ
1件のコメント
Hacker Newsの意見
開発者として最も大きな生産性向上を得られた方法は、あらゆる作業を事前に計画する習慣を身につけたことだ
チケットを受け取るたびに大きなTODOリストへ分解し、設計・依存関係・仕様をあらかじめ明確にする
こうするとプログラミング時にフロー状態(flow) により頻繁に入れる
AIコーディングエージェントにもこのアプローチが有効なのは、思考プロセスを前もって移しておけるからだ
詳細は私の記事にまとめてある
実際には問題を細分化して仕様を書くのは良いことだ
ただし変更不能なスペックが問題を引き起こす。数か月後になってから実装を始めると、スペックが固定化してしまう
一方でAgileは、戦略的な計画を先延ばしする言い訳として使われることが多い。その結果、手戻りが増える
結局はバランスの問題であり、人生でも開発でも「It depends」が良いモットーだと思う
LLMがスペックを管理すれば、保守負担が減る利点はありそうだ
関連記事はこちらにある
予測が難しい場合はまずスパイク(spike) を行ってコードやライブラリを調査する
理想的な構成図と、現実的な制約を反映した構成図を両方作り、長期的にアーキテクチャ上の落とし穴を避けている
数か月間vibe codingをしていたが、直近6か月はspec-driven developmentへ切り替えた
1日2〜3時間かけて仕様を書き、その日のうちにテスト済み機能をデプロイしている
仕様を書くからといって機敏さが落ちたわけではない。むしろ8時間単位の高速反復が可能になる
仕様はプロンプトではなく、正確性の判定基準だ
よく定義されたend-to-endテストがAIの誤りを大きく減らしてくれる
実行のたびに結果が変わり、結局は人間がレビューしなければならないので非効率になりうる
1日単位の作業を「スペック」と呼ぶのは誤解を招く。結局は既存プロセスに新しい名前を付けているだけだ
単純な論理式ですら誤って解釈することが多く、自然言語のスペックを理解させるのは危険だ
それをエージェントに渡せば勝手に実装してくれて、私は途中でレビューするだけだ
AIが働いている間、私は自分のレースカーをいじっているので完全にWin-Winだ
結局大事なのは、コードがテストを通ることだけだ
この記事は、「spec-based developmentは自分には合わない」とすでに結論づけた人向けのように見える
私はスペックをLLMのコンテキストへの入口として見ている
プロジェクトの構造、モデル、関数、要件などを十分に与えれば、LLMは文脈を理解して拡張できる
しかもLLM自身にスペックを更新させれば、Agileな反復も可能になる
テストがLLMの現実へのグラウンディング(grounding) として機能し、ハルシネーションを防ぐ
テストはドキュメントであり品質基準にもなり、LLMはジュニア開発者のように管理すべきだ
複数のエージェントを並列に動かしつつ、テストの階層で相互検証させれば驚くような結果が出る
LLMのおかげで安く速く全体スペックを反復できるだけで、本質は同じだ
長すぎるスペックは、かえって探索的思考を妨げる
LLMは決定論的システムではなく確率的システムなので、私たちは今やコードではなくスペックをデバッグしなければならない
開発者はこれから認知システム設計者(cognitive systems architect) へ進化すべきだ
上位レベルのスペックと詳細コンポーネントのスペックが共存している
私はGitHubのSpec-KitでCLIツールを作ってみたが、あまりに多くの修正・分析・書き直しの工程が必要だった
ウォーターフォールのように反復フィードバックが不足していて、もどかしかった
結局、間違ったコードを見て原因を探るより、最初からやり直したほうがよかった
LLMと一緒にコーディングするのは良いが、SDDは重くて非効率なワークフローに感じられた
LLMはコンテキストを好むので、繰り返し明確に指示する必要がある
たとえばNextJSアプリを作るときは、ログイン、RBAC、テスト優先実装などを明確に記述する
小さな単位から始めて徐々に機能を追加していく方式のほうが適している
ウォーターフォールの問題は長いリードタイムと高価な反復コストだった
SDDではこの2つが解決されるので問題ないと思う
数時間で書くスペックをウォーターフォールと呼ぶのは大げさだ
複雑な解空間に早く入りすぎると、単純な問題解決が難しくなる
Agileは小さな空間から出発し、徐々に拡張していく
スペックが十分に詳細なら反復は遅くなり、不十分ならLLMがうまく機能しない
結局、管理者が好むウォーターフォールの矛盾をそのまま抱えている
LLMは小さな単位で明確に指示したときに最もうまく機能する
数年分のスペックを書き、6か月ごとにLLMを回し、失敗すれば開発者のせいにするはずだ
記事の筆者本人です
いまだにウォーターフォール vs アジャイル論争が活発なのは興味深い
SDDに価値を感じる人たちの背景を読むのも面白い
ただ、私はすでに実装前にPlanモードを使っているので、SDDが追加の価値をもたらすわけではない
コーディングエージェントが一発で完璧に実装したこともほとんどない
結局は反復が必要なので、Big Design Up Frontの意味は薄れる
それでもコーディングエージェントが新しい開発パラダイムを開きつつあるとは信じている
以前見た動画を思い出した
エンジニアとプログラマーが互いに学べることを語っていて、事前計画の重要性が印象的だった
アジャイルが仕様書を殺したと言われるが、実際には数千件のJiraチケットに分解しただけだ
AIがこうした散在する意思決定と文脈をすべて記録し、過去の選択と矛盾するときに質問できる
「Jimが5年前にこのコードをこう書いた理由は、今でも有効なのか？」のようなフィードバックを返せるはずだ
この記事は少し変に感じた
不完全なスペックを受け取って試行錯誤で解決するのは、人間の開発者でもAIでも同じだ
明確に分かっているなら、詳細に指示するのが当然だ
たぶんこの記事の要点は「悪いスペック」の話なのかもしれない
全体としてはAgile業界の自己防衛ロジックのように見える
私はいくつかのMarkdownのスペックファイルでSDDを試したが、本当に効率的だったのはbeadsだった
エージェントが作業ツリーに沿って進み、集中できるようにしてくれる
各作業をTDDで分割し、テストに通るまでは次の段階へ進めない
エージェントがレビュー用コマンドまで教えてくれるので、コードレビューがしやすくなる
Spec-Kitは重すぎて、beadsのほうがずっと実用的だ
完全にvibeベースで作ったzmxプロジェクトも、後でエージェントのコードを参考に全面的に書き直した