4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

2025年、生成AIを使ってみてどうだった？
@aganesy

スペック駆動開発はウォーターフォール回帰なのか

4
Last updated at Posted at 2026-02-25

スペック駆動開発（SDD）が「ウォーターフォール回帰」かどうかは、仕様を先に書くかでは決まりません。
決め手は、SDDが 反復ループとして運用されているか、そして仕様が 検証（テスト/契約/CI）に接続されているかです。

「ウォーターフォール回帰」批判の本質

SDDへの批判は「仕様を先に書くのが嫌」という単純な話ではなく、次の“失敗パターン”への警戒が本体です。

  • 承認ゲート化
    仕様や設計のFIXが工程の関門になり、変更が止まる（固定化された工程になる）
  • ドキュメント肥大化
    仕様・設計・タスクが増殖し、読むこと／整合を取ることが主作業になる
  • doc rot（陳腐化）
    仕様が更新されずコードと乖離し、「結局コードだけが真実」に戻る
  • 偽の安心
    “仕様があるから大丈夫”という期待が、実際は逸脱やテスト欠如で裏切られる
  • 二重レビュー
    仕様内の擬似コードと実装の両方をレビューする羽目になり、レビューコストが増える

marmelab は、SDDがこの方向へ戻り得る（重い文書先行へ見える）点を批判しています。

Spec-Driven Development (SDD) revives the old idea of heavy documentation before coding

この批判が当たる現場は確かにあります。重要なのは”SDDそのもの”ではなく、運用設計がこの失敗パターンに陥るかどうかです。

アジャイルは「ドキュメント不要」ではない

アジャイルは「包括的ドキュメントに価値がない」と言っていません。優先順位の話です。

That is, while there is value in the items on the right, we value the items on the left more.

つまり争点は「書く/書かない」ではなく、「何を、どの粒度で、何のために残すか」です。

SDDがウォーターフォール化する条件

前述の“失敗形”を運用として踏むと、SDDは実質ウォーターフォールになります。

  • 仕様・設計のFIXが工程ゲートになり、実装開始が遅延する
  • 仕様が肥大化して更新が追いつかず、陳腐化する
  • 仕様が検証に接続されず、逸脱が統合される
  • 仕様が「読むための説明」に寄り、実装とテストの唯一の根拠にならない

ここまで来ると、批判の矛先は「SDD」ではなく「その運用」です。

「AIで作って早く学べ」という潮流と、スケール時のボトルネック

「仕様を整えるより、AIで作って動かし、フィードバックで収束させるほうが速い」というスタイルは、少なくとも“簡単なアイデア”や“探索”で強く支持されています。

marmelab は「実装が安いなら、小さく作って収束するのが最速」という立場を明示しています。

When implementing simple ideas is cheap, building in small increments is the fastest way to converge toward a good product.

また、 “vibe coding” という呼び名で、自然言語でAIに任せて試行錯誤する開発スタイルが広く流通しました。

There’s a new kind of coding I call ‘vibe coding,’ where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

一方で、プロジェクトがスケールし、仕様の精密さや整合（I/F、例外、非機能、変更影響）が求められるほど、次のデメリットが顕在化します。

  • AIが“それっぽく補完”して仕様から逸脱しやすくなる
  • 逸脱を検出するためのフィードバック往復が増える
  • 結果として、人間の評価・修正指示が増え、人間作業がボトルネックになる

この「生成が速いほど検証が支配的になる」という構図は、IT Revolution でも明確に述べられています。

If verification and validation are your constraints, generating more code faster does nothing to improve overall productivity.

また、そもそもエージェントは指示を完全に守らないケースがあり得る、という観測もあります。

I frequently saw the agent ultimately not follow all the instructions.

つまり「AIで速く作って回す」運用は、スケールに伴い“人間の評価が増える方向”へ転びやすい。
ここに対して「反復ループを壊さずに、往復コストを抑える」ための設計として、AI時代のSDDが出てきます。

SDDを反復ループとして捉える

SDDをウォーターフォールに見せないために重要なのは、SDDを「順序工程」ではなく、学習のサイクルとして扱うことです。

この図のポイントは、検証から仕様へ戻る矢印です。
この戻り矢印が運用に入っていないと、SDDは簡単に“固定された工程”へ劣化します。

SDDがアジャイルを補強する条件

上のループに沿って、SDDの要点だけを最小化すると、ウォーターフォール化を避けたまま効果を出しやすくなります。

仕様は完成品ではなく更新対象

  • 仕様は、検証で得た学びで更新される前提にする
  • 仕様のFIXを工程ゲートにしない（戻る矢印を消さない）

仕様は最小でよい

長文説明を目指さず、AIが外しやすいポイントに寄せます。

  • 境界（スコープ）
  • 例外
  • 不変条件
  • 非ゴール
  • 用語・参照ID（機械追跡できる形）

仕様は検証に接続する

“仕様があるから大丈夫”ではなく、逸脱が統合されないようにします。

  • 受入テスト／契約テスト／CIで逸脱を検出する
  • 重要な制約は「文章」だけでなく「検査可能な定義資産」に落とす（例：OpenAPI＋契約テスト）

判断は履歴化する

  • 却下案の蒸し返しや再採用を減らすために、意思決定ログ（ADR等）を持つ

仕様をアジャイル成果物に寄せる理由

「ウォーターフォール的仕様書が嫌われる」根本は、形式そのものより、サイクルを回しづらいという運用の副作用です。
一方、アジャイル由来の成果物（US/AC/examples、契約、テスト、ADR等）は、現場の手癖として

  • 更新しながら進める
  • 検証とセットで扱う
  • 小さく運ぶ

に馴染みがあります。つまり「アジャイル成果物に寄せる」は、単なる見た目の問題ではなく、

  • SDDを工程ゲート化しにくい形へ誘導し
  • 反復ループ（検証→仕様更新）を自然に維持し
  • チームの既存運用とのフィット感を保ったまま受け入れやすくする

という効果があります。

批判への回答：SDDは「工程を増やすこと」ではなく、対話コストの資産化である

ここで扱っている批判の中心は、だいたい次の2つに集約できます。

  • 「SDDはドキュメント作業を増やす。実装が遅くなる」
  • 「ドキュメントが工程ゲートになり、書けるまで実装へ進めなくなる（ウォーターフォール化する）」

この2点に対して、私の回答はこうです。

SDDが増やすのは“新しい作業”ではなく、既に払っているコストの再利用性

AIに自然言語で実装を依頼し、AIが探索し、計画を立てて、人間がそれをチェックしてステアリングする。
この流れ自体は、SDDを採用しなくても、AI開発をやる限りほぼ避けられません。

SDDは、その過程で生じる意図・判断・制約・例外・学びを、使い捨てにせず資産として残し、再利用可能にする発想です。
言い換えると、SDDの狙いは「ドキュメントを書くために実装を止める」ことではなく、どうせ発生する対話・検討コストを毎回リセットしないことにあります。

「工程ゲート化」への拒否感があるなら、成果物の形を変えるべき

「ドキュメントが増える」こと自体よりも、アレルギーの根にあるのは多くの場合、

  • 仕様書・設計書のFIXが工程ゲートになり
  • それが完了しないと実装に着手できない

という運用です。

だからこそ、検証と更新に馴染むアジャイル成果物（US/AC/examples、契約、テスト、ADR等）へ寄せることが、SDDの受け入れやすさを上げます。
それは単なる“見た目”ではなく、成果物がもともと 更新前提・検証前提で扱われるため、SDDが工程ゲート化する方向に倒れにくいからです。

SDDの開発速度がフィードバックループを超えるフェーズ

ここで答えておきたい疑問は、「結局、SDDを取り入れるとリリーススピードは上がるのか？」です。

結論は、プロジェクトのスケール・複雑度・要求精密さが上がるほど、SDDの方が優位になりやすい、です。
理由は単純で、規模が上がるほど「AIが仕様から逸脱する頻度」と「その逸脱を人間が検出・修正する往復回数」が増え、結果として人間の評価作業がボトルネック化するからです。
SDDは、最小の仕様と検証（テスト/契約/CI）を接続することで、往復の回数を抑える方向に効きます。

下図は、その関係をイメージとしてグラフ化したものです。

  • 横軸：プロジェクトのスケール／複雑度／要求精密さ
  • 縦軸：リリーススピード（相対）
  • Vibe Coding：小規模では速いが、右に行くほど急激に低下
  • SDD：初期コストはあるが、低下は緩やか
  • どこかで交差し、以降はSDDが上回る

この図は「どちらが常に正しいか」を示すものではありません。
ただ、スケールが上がるほど“AIが間違える”コストが支配的になり、そこに対して仕様と検証の接続で往復を減らすSDDが効力を発揮しやすい、という論点を可視化しています。

まとめ

SDDがウォーターフォール回帰かどうかは、手順の見た目では決まりません。

  • 検証から仕様へ戻る矢印が運用に入っているか
  • 仕様が最小で、検証可能資産に接続しているか
  • 承認ゲート化・肥大化・陳腐化を避けているか

この条件を満たす限り、SDDは「ウォーターフォールの復活」ではなく、AI時代の反復開発を成立させる設計になり得ます。

参考

4
5
0

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
4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?