67
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

新人プログラマ応援 - みんなで新人を育てよう！
@ju-kosakainKDDIアジャイル開発センター株式会社

仕様駆動開発は、ウォーターフォールへの回帰ではない。

67
Last updated at Posted at 2026-04-07

仕様駆動開発は、ウォーターフォールへの回帰ではない。

みなさん、仕様駆動開発（SDD：Spec-Driven Development）、意識していますか？

GitHub Spec KitやKiroが登場し、AIを活用した仕様駆動開発が一気に注目を集め始めました。
国内外の技術ブログにも実践事例が増え、「いよいよSDD元年か」という空気が漂いはじめています。

でも、ちょっと待ってください。

日本でのSDD導入の文脈を眺めると、妙な既視感があります。
「まず仕様書を完璧に書いて、それをAIに読み込ませてコードを生成する」——そういう解釈が、じわじわと広がっているように見えるのです。

これは、ウォーターフォールの復活ではないでしょうか。

AIを使って高速に仕様書を書き、AIを使って高速にコードを生成する。
確かに「速い」かもしれません。でも、速いだけの、ウォーターフォールです。

今日は、この誤解に正面から向き合いたいと思います。

TL;DR

以下、二つのブログを読みましょう
(このブログよりもおそらく長いですがとてもよく書かれています）

そもそも「Spec」とは何か

誤解を解くには、まず言葉を整理する必要があります。
⬆️のブログ記事でとてもわかりやすく考察してくれておりますのでぜひ。
以下が要約となります

「仕様（Specification）」とは何か。日本語では「要求」「要件」「仕様」「設計」といった言葉が文脈ごとに混ざって使われており、実務上もあいまいなまま運用されていることが少なくありません。

ISO/IEC/IEEE 29148（JIS X 0166）は、このレイヤを次のように整理しています。

  • Needs（ニーズ）
  • Requirements（要求事項）— 満たすべき条件の1文
  • Specification（仕様）— 要求事項を体系化・明文化した成果物
  • Design（設計）— その条件をどう実現するか

ここで重要なのは、SpecificationはDesignではないという点です。

Specは「守るべき前提・約束」であり、Designはその前提の中で自由に探索できる領域です。この境界が曖昧なまま進むと、設計変更のたびに前提条件まで揺れてしまい、レビューの論点が噛み合わなくなります。

この整理は、AIエージェントと並列に開発する文脈でさらに重要になります。
人間同士なら会話で補完できた暗黙知が、AIには通じません。
「何が前提で、何が自由なのか」を明文化することで初めて、人もAIも並列に動けるようになるのです。

この視点を踏まえた上で、日本でのSDD解釈の問題に向き合ってみましょう。

仕様駆動の「仕様」を、設計書と混同するな

ウォーターフォール的なSDD解釈はなぜ生まれるのか。

それは、「仕様（Spec）」を従来の「設計書」や「要件定義書」と同じものとして読んでしまうからだと思っています。

上流工程で仕様を決める。
AIがその仕様からコードを生成する。
チームはそのコードを統合して動かす。

一見スマートに見えます。でも、何かがおかしい。

このやり方では、チームは依然として自分たちで何かを決める権限を持っていません。
仕様は相変わらず中央集権で管理され、変更のたびにレビューのボトルネックが生まれます。
そして最も痛いのは、「大きな統合」が最後にやってくること
これはウォーターフォールの最大の弱点であり、アジャイルやスクラムで解決したかった問題のはずです。

根本的な誤解があります。

SDDが解こうとしているのは「仕様の網羅性」ではありません。
「チーム間の契約の明確化」 です。

"In SDD, code stops being the place where truth emerges and becomes the place where truth is merely realized."

— Leigh Griffin, Ray Carroll「Spec Driven Development: When Architecture Becomes Executable」(InfoQ, 2026年1月)

仕様駆動開発において、コードは真実が生まれる場所ではなく、真実が実現される場所に過ぎない。
これは些細な言葉の違いではなく、ソフトウェア開発の権力構造そのものの逆転です。

チームは、独立して動けているか

本来のSDDの威力は、チームが仕様という「契約」をもとに、互いを待たずに開発を進められる点にあります。

フロントエンドチームは、バックエンドの実装が終わるのを待たなくていい。
バックエンドチームは、フロントエンドの都合でAPIの設計をひっくり返されなくていい。
インフラチームは、アプリケーションが動く前から環境を整備できる。

これを可能にするのが「仕様を境界として使う」という発想です。
（別リポジトリで独立させましょう、の説明ではないです。念の為。）

チーム間のAPIの形を先に定義し、そこからスタブを自動生成します。
各チームはそのスタブに向かって、独立して実装を進めます。
「仕様が変わったら全部崩れる」ではなく、「仕様の変更が他チームに与える破壊的変更をCIが即座に検知する」
これがSDDの本質です。

仕様は「全員が従う命令書」ではなく、「チーム間の約束を機械的に検証するための道具」なのです。

そのためには、仕様のオーナーシップがチームごとに分散している必要があります。
1つの巨大な仕様リポジトリに全チームの変更を集中させるのではなく、ドメインごとにチームが自分たちの仕様を管理する——フェデレーション型の仕様管理が有効です。
中央のCI/CDパイプラインは、各チームの仕様を集約し、「破壊的変更がないか」だけを機械的にチェックします。

チームの自律性を保ちながら、システム全体の整合性を担保する。
これがSDDの設計思想の核心です。

統合リスクとどう向き合うか

統合のリスクは、規模が大きくなるほど指数関数的に増大します。
10チームが3ヶ月後に一斉に統合しようとすれば、何かが壊れるのは必然です。
壊れてから直すコストは、早期に検知するコストの数倍にも数十倍にもなります。

SDDがこの問題に提供する答えは、こうです。

仕様を「最初から完璧に書く」のではなく、「チーム間の境界に置き、継続的に機械的な検証にかける」。

消費者主導契約テスト（CDCT：Consumer-Driven Contract Testing）の考え方はここに接続します。
APIを使う側（消費者）が「欲しいもの」を定義し、提供する側がそれを満たすように実装します。
「仕様通りか」をCIが自動で検証し続けることで、「最後に統合したら動かなかった」という悪夢を防げます。
（統合の回数を増やすとコストが跳ね上がるリスクがある点に留意しながらCI環境を更新しましょう）

また、自動生成の範囲を「チーム間の境界だけ」に限定することも大切です。

自動生成するもの：APIクライアント、ルーティングの型定義、リクエスト・レスポンスの型、スタブ（モックサーバー）。
人間が書くもの：コアとなるビジネスロジック、複雑なトランザクション処理。

境界部分のコードだけを仕様から生成することで、統合エラーを防ぎつつ、ビジネスロジックの可読性とコントロールを人間の手に残せます。
AIにすべてを任せてブラックボックス化し、「仕様にバグがあったとき誰も直せない」という事態を避けるためにも、この線引きは意識的に守るべきです。

"Drift detection does not patch runtime behavior; it corrects specification authority and triggers controlled regeneration of the system."

— Leigh Griffin, Ray Carroll「Spec Driven Development: When Architecture Becomes Executable」(InfoQ, 2026年1月)

ドリフト検知とは、ランタイムの動作にパッチを当てるのではなく、仕様の権威を正し、システムの再生成を制御しながら引き起こすものだ。
統合の問題が起きたとき、直すべきはコードではなく仕様であるという視点は、多くのチームがまだ持っていないものです。

「完璧な仕様」を先に書くのではなく、「最小の仕様で境界を定め、継続的に検証しながら育てる」
これが統合リスクへの正しい向き合い方だと私は考えています。

大規模開発をやめる勇気

そして、もっと根本的な話をしましょう。

SDDを正しく使おうとすると、いずれこの問いに直面します。
「そもそも、100名が1つのシステムに向かって同時に開発する必要があるのか？」

大規模な一枚岩のプロジェクトは、構造的に「大きな統合」を生みます。
大きな統合は、最後になって初めて「市場からのNO」を受け取るリスクを内包しています。
仕様がどれだけ精緻でも、半年かけて作ったものが市場に刺さらなければ、それは失敗です。

AI-DLC（AI-Driven Learning Cycle）と呼ばれる考え方では、開発とは仮説検証のサイクルそのものだと捉えます。
チームは小さな仮説を立て、実装し、市場に問い、フィードバックを得て、次の仮説に進みます。
ここでの「市場に出す」は、数ヶ月後の大きなリリースではありません。数日〜数週間単位の、独立したインクリメントです。

SDDが本来目指しているのもここに接続します。
チームが独立した「仕様の単位」で開発し、その単位ごとに市場からフィードバックを得る。
「大きな仕様書を完成させてから作る」のではなく、「最小の仕様で最小の機能を作り、並行して検証しながら統合していく」のです。

"The unit of delivery is no longer a service or a codebase. The unit of delivery becomes the specification itself."

— Leigh Griffin, Ray Carroll「Spec Driven Development: When Architecture Becomes Executable」(InfoQ, 2026年1月)

デリバリーの単位は、もはやサービスでもコードベースでもない。仕様そのものが、デリバリーの単位になる。
この一文が示すのは、「何を作るか」の粒度を変えるということです。スプリントごとに仮説を仕様として定義し、その仕様を起点に実装・検証・統合を回す——それが、大規模開発という「大きな賭け」を解体する具体的な方法です。

並行した仮説検証とインクリメンタルな統合は、リスクを分散し、「自分たちが正しい方向を向いているか」を継続的に確認させてくれます。
チームは「作り終えてから正しさを知る」のではなく、「作りながら正しさを確認する」ことができます。

10チームが一斉に同じゴールに向かうより、それぞれのチームが独立した仮説を持ち、並行して検証し、結果として統合されていく——その設計こそが、SDDの本当の使い道です。

大規模開発をやめることは、スピードを落とすことではありません。
むしろ、「大きな賭け」をやめ、「小さな確認」を繰り返すことで、自分たちの設計や開発の確かさをずっと高く保てるのです。

おわりに

仕様駆動開発は、ウォーターフォールに戻るための技術ではありません。

それは、チームが自律的に動き、統合の失敗を最小化し、市場からのフィードバックを継続的に得るための設計哲学です。

AIが仕様を書いてくれる時代になっても、「誰がどう決めるか」「チームはどう独立して動けるか」「市場はいつフィードバックをくれるか」
これらの問いへの答えは、私たちエンジニアが設計しなければなりません。

「SDDを入れました」で満足せず、その先を問い続けてください。

チームは本当に自律して動けているか。
統合は、最後の一発ではなく継続的に行われているか。
仮説は、ちゃんと市場で検証されているか。

仕様駆動開発を「AIに仕様書を渡して仕様通りに作らせる技術」とせず、「チームの自律性と市場との接続を設計するための哲学」として捉え直してもらえたらと思います。

そうすれば、SDDに限らず、生成AIたちは間違いなく私たちの開発を前に進める力となります。

参考文献

国内記事

海外記事

67
35
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
67
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?