仕様駆動開発（SDD）とは？現場で試してわかった本当のメリットと落とし穴
そもそも何が変わるのか
やることはシンプルで、コードを書く前に仕様を書く。それだけ。
ただし「仕様を書く」の意味が、従来の開発とは少し違う。従来のウォーターフォールで書かれた仕様書は、人間が読んで解釈するものだった。SDDの仕様書は、AIが読んで実装できるレベル で書く。
流れはこうなる：
- 人間が仕様を定義する（要件 → 設計 → タスク分解）
- AIが仕様に基づいてコードとテストを生成する
- 仕様とコードの整合性を検証する
- 変更があれば仕様を更新し、コードを再生成する
ポイントは、コードを直接いじらない こと。変更したくなったら、まず仕様を直す。コードは仕様の「副産物」という位置づけだ。
バイブコーディングとの違い
「バイブコーディング」という言葉が流行ったのは2025年の前半だった。AIと自然言語でやりとりしながら、ノリで開発を進めるスタイル。個人開発やプロトタイプなら、正直これで十分なケースも多い。
では、なぜわざわざSDDが必要なのか？ チーム開発になった瞬間に破綻するから だ。
バイブコーディングの「ノリ」は属人的で、共有できない。Aさんが「ユーザー認証を実装して」とAIに投げた結果と、Bさんが同じことをした結果が一致する保証はゼロ。テストの基準もなければ、レビューの拠りどころもない。
実際に導入した企業は何が変わったのか
「速くなった」より「ズレなくなった」
チーム内で仕様を「requirements → design → task」の3段階で言語化するプロセスが定着したことで、暗黙知が形式知になった。「なんとなくこうだよね」という認識のズレが、スプリント初期の段階で発見できるようになった。
開発期間の短縮
SDD導入後に開発期間が約1ヶ月から1〜2週間に短縮された事例もある。ただし、その分レビュー負荷が増えたという報告も。AIが大量にコードを生成するので、レビューする人間側の作業量が増えるのだ。
対策として、linterとAIレビューツールの組み合わせで自動チェックを強化し、人間のレビューは設計判断に集中させる運用が有効だ。
TDDやBDDとは何が違うのか
- TDD（テスト駆動開発）は「テストを先に書いてからコードを書く」。対象は実装フェーズだけ
- BDD（振る舞い駆動開発）は「ユーザーの振る舞いを定義してからテスト・実装する」。要件〜実装をカバー
- SDD（仕様駆動開発）は「仕様を定義して、設計もコードもテストもそこから生成する」。要件定義から検証まで全フェーズが対象
SDDはTDDやBDDを否定するものではなく、むしろ それらを包含する上位概念 だ。
SDDが向かないケース
正直に言うと、SDDが常にベストな選択肢ではない。
- 個人の小さなプロジェクト には、仕様書を書くオーバーヘッドが見合わない
- 探索的なリサーチ — そもそも何を作るか決まっていない段階では、仕様を書きようがない
- 単純なバグ修正 — 1行直せば済む修正に仕様書は要らない
SDDの恩恵が最も大きいのは チームで開発する中〜大規模のプロダクト だ。
SIer・受託開発が考えるべきこと
AIがコードを書く時代に、「エンジニアの頭数 × 月数」で売上を立てるモデルは持続しない。
SIerの価値は 上流工程、つまり要件定義と設計に移る。SDDの文脈でいえば、「良い仕様を書ける力」がそのまま競争優位 になる。
「人月を売る」から「仕様策定力を売る」へ。この転換ができたSIerが、次の10年を生き残る。
始めるなら、まず1つのプロジェクトから
具体的なステップ：
- 仕様駆動開発ツールをインストールして、チュートリアルを1つ完走する
- 次のスプリントの1機能で仕様→設計→タスクの3段階を試す
- 振り返りで効果を検証 — 手戻りは減ったか？レビューは楽になったか？
- うまくいった部分だけ横展開する。全部やろうとしない
最初から完璧な仕様書を目指す必要はない。雑でもいいから書く。それだけでAIの出力品質は目に見えて変わる。
アツメルでの取り組み
私たちアツメルは、AI開発の受託案件で仕様駆動のアプローチを取り入れている。
クライアントのビジネス要件をヒアリングし、AIが最大限の力を発揮できる仕様に落とし込む。「何を作るか」だけでなく「AIにどう伝えるか」まで設計する。これが、ただの受託開発とAI開発パートナーの違いだと考えている。