仕様駆動開発はやめた方がいいって本当？

#Offers_DeepDive Lightning Talk 仕様駆動開発は やめた方がいいって本当？ やって分かった仕様駆動開発の現在地と今後の方向性 Atsushi Nakamura 2026.05.28

本日の最重要ポイント 本題に入る前に、まず2つだけお伝えしたいこと。

先にお伝えしておきたいこと 01 02 「やめるべき」の話ではない マサカリはお手柔らかに 「仕様駆動開発はやめるべき」 個人の経験に基づく所感です。 と主張する話ではありません。 異論反論は大歓迎ですがお手柔らかに。 「仕様駆動開発の入門の先」を考える入口として。 仕様駆動開発はやめた方がいいって本当？ 3 / 14

自己紹介 中村充志 @nuits_jp リコージャパン株式会社 プリンシパルITアーキテクト Microsoft MVP for Development Technologies（2017/01〜） 仕様駆動開発はやめた方がいいって本当？

今日のながれ 01 02 03 概略 DEMO 所感 仕様駆動開発とは何か spec / plan / task を実際に動かす やってみて感じている現在地 約10分 / DEMO に半分ほど使います 仕様駆動開発はやめた方がいいって本当？ 4 / 14

仕様駆動開発（Spec Driven Development-SDD）とは 実装の前に、要求と設計を 明示してから AI に書かせる。 Vibe Codingへの対案として登場。 段階を踏んで人間と AI の合意を積み重ねていく開発スタイル。 仕様駆動開発はやめた方がいいって本当？ 5 / 14

SDD の歴史と発展 2025.07 Kiro 登場 AWS が AI IDE Kiro をプレビュー公開。 spec → design → tasks を IDE に内蔵。 2025.09 Spec Kit 公開 GitHub が OSS として公開。 複数エージェントから共通フローを使える形に。 2025末〜 OSS フレームワークが続々登場 OpenSpec / BMAD / Tessl / Intent ほか。 ※ SDD ネイティブなのは現状ほぼ Kiro のみ。 2026〜 チューニング期 フル SDD への反発も顕在化。 plan / goal のみの部分適用が増えてくる。 仕様駆動開発はやめた方がいいって本当？ 6 / 14

4つのレイヤーで実装に進む Spec ユーザーストーリーと受け入れ基準。 仕様 何を作る／作らないかを明示する。 Design / Plan アーキテクチャ・データモデル・ 設計・計画 影響範囲を整理し、方針を決める。 Tasks AI が一つずつ消化できる粒度に タスク 分解し、実装を進める。 Implement AI がタスクを実行し、 実装 コードとして成果物を生成する。 仕様駆動開発はやめた方がいいって本当？ 7 / 14

SDD が狙うこと 意図の明文化 コンテキストの永続化 暗黙の前提を実装前に減らす 別セッション・別エージェントでも同じ前提から 段階的レビュー 再現性とトレース コードだけでなく仕様・設計の段階で見る 「なぜこの実装か」を仕様から辿れる 仕様駆動開発はやめた方がいいって本当？ 8 / 14

Section 02 DEMO specify / plan / tasks / analyze / implement を、実際に動かしてみる。

GitHub Speckitによる進め方 01 specify 02 plan 03 tasks 04 analyze 05 implement 要件・目的を AI に 実装方針・設計を AI が実行できる 既存コードを読み タスクを順に 伝える仕様書を まとめた設計書を 粒度のタスク一覧を 実装前の影響範囲を AI に実行させる 生成する 生成する 生成する 把握する 本日の例：OSS パッケージ GistGet の sync コマンドに --dry-run オプションを追加する 仕様駆動開発はやめた方がいいって本当？

DEMOの所要時間 01 specify 02 plan 03 tasks 04 analyze 05 implement 3 4 3 6 20 分 分 分 分 合計 36分 ※ 実際には clarify（仕様の確認・補足）や checklist（完了確認）などのステージが適宜追加される場合もある 仕様駆動開発はやめた方がいいって本当？ 分

仕様駆動開発の利点 01 02 03 書く前に、頭が整う 実装前にズレが消える 再利用可能なspecが残る spec / plan を書く過程で 合意してから書き始めるので コンテキストが文書に残る 曖昧さが先にあぶり出される 後戻りが起きにくい 再開や継続開発に生きる AI 駆動開発を一段深める、その入口としては良い。 仕様駆動開発はやめた方がいいって本当？ 10 / 14

一方で、指摘されやすいこと 1 文書の生成・維持コストが高く、陳腐化しやすい 2 出力される spec の粒度・形式が現場と噛み合わないことがある 3 文書が整っていても AI 由来の曖昧さは残り、レビュー省略には直結しない 4 軽い変更や PoC にフル手順を踏むと、明らかに重い 仕様駆動開発はやめた方がいいって本当？ 11 / 14

評価の分かれ方 A B C とても良い プロセスとして重い 仕様書としては不足 AI に意図がそろい、開発が安定 する 毎回フル手順は割に合わない 現場や顧客向け文書とは噛み合 わない どれが正解、ではなく、文脈で揺れる。 仕様駆動開発はやめた方がいいって本当？ 12 / 14

文脈で、合う粒度は変わる 受託開発 自社サービス 「仕様 = 契約」になりがち 「コード＝Single source of truth」 ■ spec を顧客向け仕様書としてそのまま使う ■ 実装方針は plan/goal があれば足りる場面 が多い のは難しい ■ 既存の仕様書資産と重複しやすい ■ 毎回フル SDD は速度面で重く感じる ■ plan / task の方が嬉しいことが多い 「採用するか / しないか」より、「どこまで使うか」。 仕様駆動開発はやめた方がいいって本当？ 13 / 14

今日のまとめ 01 やめるべきもの、ではない。 02 必須、でもない。 03 現状、環境に応じて取捨選択が必要。 仕様駆動開発を適用するか？しないか？どう適用するか？業界全体が現在進行形で模索中。 仕様駆動開発はやめた方がいいって本当？ 14 / 14