TL;DR
- 仕様駆動開発（SDD）の失敗は「仕様書の書き方」より、運用設計と組織レンズの欠落で起きるケースが大半（経験則）。
- 本記事では現場でよく見る7つの失敗パターンを「症状 → 根本原因 → 対策」で整理し、Tech Lead・PM・EM がそのままチェックリストとして使える形にした。
- ツール選定（GitHub spec-kit や Kiro（AWS系のAI IDE） 等）の前に、組織側の運用課題を解くことが先である。
はじめに：SDD は導入すれば効くわけではない
Spec Driven Development（SDD） は、AI コーディング時代に「会話ログではなく仕様ファイルを Source of Truth にする」考え方として再注目されている。GitHub spec-kit や Kiro、GitHub Copilot coding/cloud agent（旧 Copilot Workspace 系の Issue 起点ワークフロー） など、SDD を支援するツールも 2025〜2026年にかけて急速に増えた。
ところが、現場の Tech Lead・PM・EM からはこんな声が聞こえてくる。
- 「仕様書を書いている割に、PR の手戻りが減らない」
- 「spec-kit を導入したのに、AI の出力が安定しない」
- 「結局チャットで指示した方が早いと言うエンジニアが増えた」
これらは仕様書の書き方が悪いというより、SDD を回す運用の設計や、組織レンズでの観点が抜けていることから来る症状だ。本記事は、筆者が複数の中小〜中規模チーム（5〜30人）で見てきた典型的な失敗を 7パターンに集約し、各パターンに対する一次対策を併記する診断記事である（経験則ベース）。
読み方:
- 各セクション冒頭の「症状」が自組織で当てはまるかチェック
- 当てはまる失敗パターンの「対策」を優先順位の高い順に1つだけ実行
- 最後の「導入チェックリスト」で1週間のアクションに落とす
失敗パターン1：仕様書が「網羅型」に膨張してレビュー不能になる
症状: 1つの仕様ファイルが 1,000 行を超え、レビューが 2〜3 日かかる。誰も全文を読まないまま LGTM が押される（経験則）。
根本原因: 「仕様書 = 完璧主義で網羅すべきもの」という旧来的な思い込み。受入条件・設計判断・運用手順・FAQ・将来計画まで1ファイルに詰め込もうとする。
対策:
- 仕様の最小単位を 「1受入条件 = 1セクション」 に揃える。1ファイル 300 行を目安にする。
- 時間軸で
In Progress / Done / Blockedを分離する（spec ファイルの管理パターン 参照）。Done は履歴として保存し、現役の意思決定からは隔離する。 - レビュアーは「完了条件として何を確認するか」だけを見る。設計詳細は別ファイルに切り出す。
巨大仕様は読まれない、つまり仕様として機能しない。読まれるサイズに保つ運用設計が、仕様書の品質より先に来る。
失敗パターン2：受入条件を後付けにして AI 出力が安定しない
症状: 実装が一通り動いてから「受入条件は…」と書き始める。AI に任せた実装が「なんとなく動く」ものになり、レビュー時に粗が見つかる（経験則）。
根本原因: 仕様 → 実装の順序が逆転している。受入条件を後付けにすると、AI は「最後に通るテスト」を逆算できないため、出力の方向性が安定しない。
対策:
- 実装着手前に Example ベースの受入条件 を最低3つ書く（受入条件を先に書くTDD実践 参照）。
- 「Given / When / Then」の Then を観測可能な値で書く（HTTP ステータス、DB の行数、ログメッセージなど）。
- AI には受入条件を最初のプロンプトに含める。これだけで一発合格率が体感で 1.5〜2 倍になる（経験則：5〜30人規模チーム複数で観測）。
OpenAI Codex 公式 Prompting では、再現手順・検証手順・lint / pre-commit checks を含めると品質が上がるとされている（公式値）。Claude Code 公式ドキュメント でも CLAUDE.md でプロジェクト指示・テストコマンドを管理できるため、完了条件を仕様側に寄せる運用と相性がよい（公式値 + 経験則）。
失敗パターン3：AI が勝手にスコープを拡張する
症状: 「ついでに似たコードもリファクタしました」「テスト名も統一しました」と、依頼していない変更が PR に混入する。レビューが膨らみ、リスクが見えにくくなる（経験則）。
根本原因: 仕様の 非目的（Non-Goal） が書かれていない。AI は不在の境界を「やってよい」と解釈する。
対策:
- 仕様テンプレートに 「目的 / 非目的 / 制約」 を必須項目として組み込む（Issue テンプレートの必須5項目 参照）。
- 非目的の例: 「既存テストの名称変更は対象外」「他コンポーネントへの影響波及は別 PR」。
- PR テンプレートに「diff 範囲が仕様の目的に収まっているか」チェック項目を追加する。
非目的を書くのは多くの場合 5 分程度で済む。少なくともレビュー時にスコープ越境を判定しやすくなる（経験則）。
失敗パターン4：ツール先行で組織の運用設計が後回し
症状: spec-kit や Kiro を導入したが、PR の通過率も AI 出力の品質も改善しない。「ツールが悪い」という結論になり、半年後に別ツールへ乗り換えを検討し始める（経験則）。
根本原因: ツールはフォーマットを与えるが、運用文化までは作らない。Decision Log・受入条件テンプレ・PR チェックリストといった運用資産がないまま導入すると、空のテンプレートが増えるだけになる。
対策:
- ツール導入の前に、最低限以下を整える: Decision Log / 受入条件テンプレ / PR チェックリスト（GitHub Copilot Workspace の実用性レビュー 参照）。
- 既存運用と新ツールの 二重化期間 を 2 週間取る。フォーマットを完全移行する前にチームが慣れる時間を確保する。
- 効果測定は「PR 差し戻し回数」「仕様レビュー時間」で取る。ツールのインストール数で評価しない。
ThoughtWorks Technology Radar では GitHub Spec Kit が 2026年4月時点で Assess とされ、constitution / instruction bloat / context rot など、ツール導入時の運用設計課題が併記されている（公式刊行物）。
失敗パターン5：Tech Lead が仕様レビュアーで固定されボトルネック化
症状: 仕様レビューがリードのカレンダーで埋まり、承認待ちが滞留する。リードが休暇を取ると組織の進捗が止まる（経験則）。
根本原因: 「仕様 = 重要 = リードが見るべき」という一極集中思考。SDD 導入で仕様の量が増えるほど、ボトルネックが顕在化する。
対策:
- 受入条件レベルの LGTM は シニア以外にも委譲 する。リードはアーキテクチャ影響のある仕様だけレビューする。
- AI を 事前バリデータ として配置する。受入条件の構文チェック・非目的の有無・テンプレート遵守を CI で検査する（Claude Code Hooks のパターン集 参照）。
- ペアレビュー枠を週2回・各30分など固定枠で運用する。非同期レビューだけに頼らない。
リードがレビューで埋まる組織は、SDD 以前にエンジニアリングマネジメントの設計を見直す必要がある。
失敗パターン6：仕様書と実装の同期が崩れて「腐ったドキュメント」が増える
症状: spec/ ディレクトリに古い仕様が大量に残り、AI が古い仕様を参照して逆効果な提案をする（経験則）。
根本原因: 仕様の Lifecycle 管理が未設計。書いた人と消す人が分かれ、誰も古い仕様を Done に移す責任を持たない。
対策:
- 仕様完了時の
Done/配下への移動を PR テンプレートのチェック項目 に組み込む。 - CI で 参照断ちチェック を入れる（コードと spec の双方向リンク切れを検知）。GitHub Agentic Workflow と CI/CD で示した GitHub Actions パターンが応用できる。
- AI に仕様を読ませる際、In Progress 配下のみを参照スコープに固定する（CLAUDE.md / AGENTS.md で明示）。
仕様の鮮度は信頼の通貨。腐った仕様を放置すると、AI も人間も spec を読まなくなる。
失敗パターン7：チャット指示と SDD が混在し Single Source of Truth が崩壊
症状: 同じ機能の仕様が Slack スレッドと spec ファイルで食い違う。AI に指示するときは「最新は Slack の方」と人間が翻訳している（経験則）。
根本原因: コンテキストの SSoT（Single Source of Truth）設計が不在。チャットと spec の役割境界が暗黙化している。
対策:
- CLAUDE.md / AGENTS.md を整備し、AI が読むべき参照階層を明示する（CLAUDE.md の最適化パターン 参照）。
- Slack スレッドで決まった内容は、その場で spec に反映するルールにする。Slack を「決定の場」ではなく「ドラフトの場」と位置づける。
- AI への指示は spec ファイルへのパスを必ず含める。「最新の方針は Slack 見て」は禁句にする。
SSoT が複数あると、AI も人間も「最新はどっち？」を毎回考えることになり、認知コストが大幅に上がる。
失敗パターン早見表
| # | 症状 | 根本原因 | 一次対策 |
|---|---|---|---|
| 1 | 仕様膨張 | 完璧主義 | 1受入条件 = 1セクションに分解 |
| 2 | 受入条件後付け | 順序逆転 | Example先書き |
| 3 | スコープ拡張 | 非目的不在 | Non-Goal 明示 |
| 4 | ツール先行 | 運用文化未整備 | Decision Log・PR CL を先行整備 |
| 5 | リード集中 | 一極集中思考 | 権限委譲＋AI 事前検証 |
| 6 | 仕様腐敗 | Lifecycle 未設計 | Done 移動＋CI 参照チェック |
| 7 | SSoT 崩壊 | 参照階層不在 | CLAUDE.md / AGENTS.md で固定 |
導入チェックリスト：今週やる3つ
優先順位を付け、まず1つだけ実行する。3つ全部やろうとすると失敗する（経験則）。
- 既存 spec の Done 移動（所要 30分）
In Progress配下から完了済み仕様をDone/に移す。AI の参照スコープから外す。
- 直近 PR 5本の Non-Goal 監査（所要 1時間）
- PR の diff が仕様の目的に収まっているか、Non-Goal 違反がないか確認する。違反があれば仕様テンプレートに Non-Goal 欄を追加する。
- CLAUDE.md / AGENTS.md の参照階層を1枚絵に整理（所要 半日）
spec/docs/Slackの役割境界を1枚にまとめ、AI に読ませる参照順を明示する。
このチェックリストは「失敗パターン1〜7のうち、最も影響が大きい3つに対する初動」として設計してある（パターン6・3・7に対応）。
FAQ
Q1. 仕様駆動開発（SDD）と TDD の違いは？
TDD は実装前にテストを書く開発手法、SDD は実装前に 仕様（受入条件含む） を書く開発手法。SDD のほうが上位レイヤーで、TDD は SDD の中で「受入条件をテストコードに落とす」段階に相当する（受入条件を先に書く TDD 実践 参照）。
Q2. spec-kit と Kiro、どちらから始めるべき？
spec-kit は GitHub Issue / PR ベースで動かす軽量フレームワーク、Kiro は IDE 統合型で要件 → 設計 → 実装を一気通貫で扱う。チームが Issue 中心の文化なら spec-kit、IDE 中心なら Kiro が入りやすい。ただし、ツール選定の前に「Decision Log と受入条件テンプレ」を整える方が先である（失敗パターン4）。
Q3. 失敗パターン1〜7のうち、最も影響が大きいのは？
組織規模によるが、5〜30人規模では パターン6（仕様腐敗）と パターン7（SSoT 崩壊） が最も影響が大きい（経験則）。仕様の信頼が崩れると AI も人間も spec を見なくなり、SDD の前提が瓦解する。
Q4. 小規模チーム（5人未満）でも SDD は必要？
必要。ただし軽量版で良い。受入条件 + Decision Log の2つだけでも、AI 出力の安定性は明確に上がる（経験則）。フルセットの spec-kit を導入する必要はない。
Q5. SDD 定着までどれくらいかかる？
筆者の観測範囲では 8〜12 週間 が目安（経験則：5〜30人規模で複数チーム）。最初の4週間で運用設計、次の4週間で慣熟、最後の4週間でメトリクスが改善し始める。3週間で諦めると失敗パターン4に陥る。
まとめ：次のアクション
仕様駆動開発の失敗は、仕様書の書き方より 運用設計と組織レンズ で詰むケースが大半である。本記事の7パターンを自組織に当てはめて診断し、最も影響の大きいものを1つだけ選んで1週間で潰す。これが SDD を本当に効かせる最短路である。
- 関連: なぜ AI エージェントは仕様書を無視するのか
- 関連: 受入条件を先に書く TDD 実践
- 関連: SDD 体系入門ハブ
シリーズ全体に戻る: 親記事
組織導入の壁打ちが必要な場合、X もしくは GitHub Issue で受け付けている。失敗パターンの自己診断結果と、現在の運用課題を1〜2行で添えてもらえると、議論がスムーズに進む。
