Select a result to preview

仕様駆動開発

#software-development #ai #coding-agent #development-methodology

「仕様を真実の源（Source of Truth）」とし、仕様から実装を生成するコーディングエージェント時代の開発手法。2025年7月にAWS Kiroで提唱された。

ワークフロー

要件 → 設計 → 実装という3段階のプロセス。

  1. 詳細な仕様を事前に確定
  2. 仕様を人間が読み、変更する
  3. コーディングエージェントが仕様からコードを生成
  4. 人間はコードを触らない

背景：バイブコーディングへの危機感

バイブコーディング（AIに曖昧な指示でコード生成させる手法）の混乱への反動として登場。大規模コードベースでの品質とメンテナンス性への懸念から、「無秩序なAI活用 vs 仕様駆動」という二項対立の構図で語られる。

歴史的文脈：ウォーターフォールの再来

ウォーターフォールからアジャイルへの移行で得られた知見——フィードバックループの重要性、仕様と実装の相互作用——を無視し、再び「仕様を先にすべて書く」方向に向かっている。

批判

Martin Fowlerの懐疑論

実装からのフィードバックの欠如

実際に動くコードを見ることで初めて分かる問題は多い。具体的な構造・状態遷移・振る舞いからのフィードバックがなければ、良い仕様は書けない。

DDDとの矛盾

Domain-Driven Designが強調する「コードとモデルの深い結びつき」「ユビキタス言語」は、仕様とコードが分離していないことを意味する。仕様書とコードを分離する仕様駆動開発とは相反する。

コンテキストの非効率

コンテキストウィンドウの制約下で、仕様書とコード両方をAIに読ませるのは非効率。むしろ、コードこそが真実であり、ドキュメントは補助的存在とすべき。

代替アプローチ：仕様・実装共進化

仕様駆動でもバイブコーディングでもない第三の道として、仕様・実装共進化が提案される。仕様と実装を高速に往復しながら、フィードバックループを回し続けるアプローチ。

銀の弾丸症候群

「仕様を先に書けば解決する」という主張は、銀の弾丸症候群の一例。複雑性への恐怖と予測可能性への渇望から、極端な秩序への逃避が起こる。

翻訳方向の非対称性による批判

自然言語のspecをSSoTにしても、そこからImplementationへの変換は本質的に非決定的であり、射影が安定しない。これは翻訳方向の非対称性が示す情報理論的な根拠による。逆に、ImplementationからContractやRequirementsへの翻訳は収束的であり、コストが小さい。

認知的距離との関係

「仕様を先にすべて書く」方法論は、仕様側と実装側の認知的距離が較正ループなしに管理可能であるという暗黙の前提に依存している。しかし実装から得られるフィードバックなしでは距離の測定自体ができず、認知的不協和（仕様と現実の乖離）が蓄積される。

関連

参照