【部署内表彰】「仕様書駆動開発（SDD）」で開発スピード4〜5倍！？実践者に話を聞いてみた

こんにちは、アドウェイズエンジニアブログ運営かつADWAYS DEEEでアプリケーションエンジニアをしている渡辺です。

突然ですが、皆さんの会社には「褒め合う文化」ってありますか？

私の部署では毎月の全体定例で「改善さん変革さん」という表彰をしています。その月に良い動きをしたメンバーを称え、ヒーローインタビューをするという、ちょっと楽しいコーナーです。

実はこのヒーローインタビュー形式自体も、2025年10月から始まった改善の取り組みなんです。以前は受賞者の取り組み内容を読み上げるだけだったのですが、「プロ野球のヒーローインタビューのように、受賞者の取り組みや裏側を掘り下げたい」という想いから、インタビュー形式に変更されました。今回が2回目の実施です。

今回、2025年11月度の表彰で面白い取り組みが紹介されたので、その内容を皆さんにもシェアしたいと思います！

今月の改善さん：中利さん

受賞理由： AI界隈で今アツい「仕様書駆動開発（SDD）」を実際の担当案件で実施！

すごくいいチャレンジで、DIV全体の生産性を上げるためにぜひ推進してほしい取り組み

とのことで選ばれました。

さっそく、中利さんにお話を聞いてみましょう！

ヒーローインタビュー

── 中利さん、改善さん受賞おめでとうございます！

中利　ありがとうございます！

── 仕様書駆動開発（SDD）という新しい開発手法を実案件で試すって、他に実績がない中でかなり勇気がいったと思うんですが…。まず簡単に、SDDってなんですか？

中利　簡単に言うと、AIと人間でまず最初に要件定義書みたいなものを作って、その要件定義書をもとにAIがタスクを切ってくれて、それをAIがコーディングしてくれるというものです。

── なるほど。導入しようと思ったきっかけは？

中利　前の案件でテストを書くときに、コードを元にして自然言語で「こういうことをテストしてください」ってAIに指示してたんですけど、それってそもそも最初に仕様書を書いて、それに対してテストを作ってもらえばいいんじゃないかと思ったんです。開発のところにも仕様書をもとにしてやれたらなと思って探したのがSDDでした。

── SDDをチームやDIV全体に広げていくにあたって、どんな可能性や課題があると思いますか？

中利　可能性としては、今までAIがコーディングの範囲内でしか活躍できなかったところから、AIが開発サイクル全体に使えるようになることですね。要件定義とか設計にもAIが関わることで、コーディングフェーズでもAIの力がより発揮されます。

中利　課題としては、CI/CDとか基本的な部分は守らなきゃいけないのが一つ。あとはSDD前提の開発ライフサイクルが必要になってくるんですけど、理想としては常に職種を超えたペアプロ…デザイナーとエンジニアとPdMが同じ場で常に作業してるみたいな状態が必要なので、どこのチームでも簡単に導入できるわけではないですね。

── 生産性を上げるために必要なものの、いろいろ解決していかなきゃいけない課題があるんですね。ありがとうございました！

同日のLTでSDDについて詳しく解説してもらいました

実は中利さん、このインタビューの後にLT（ライトニングトーク）でSDDについて詳しく発表してくれました。その内容もあわせてご紹介します！

1. VibeCodingの限界

まず、なぜSDDが必要なのか？という話から。

最近「VibeCoding（バイブコーディング）」という、AIに自然言語で指示してコードを書いてもらうスタイルが流行っていますよね。でも、これには限界があると中利さんは言います。

自然言語指示の「曖昧さ」問題

例えば、こんな指示を出したとします。

ユーザーの指示	AIの解釈と現実
「Notionみたいなアプリ作って」	「わかりました（データベースを作ります）」
期待：柔軟なビュー、便利なツール群、それさえあればデータベースにはこだわらない	結果：機能は動くが思ってたのと違う
前提：これくらい言わなくても分かるはず	原因：自然言語には文脈が欠けている

バグはないけど「思ってたのと違う」という状況、AIでコーディングしたことがある人なら経験あるのではないでしょうか？

2. 仕様書駆動開発（SDD）とは

そこで登場するのが仕様書駆動開発（SDD: Specification-Driven Development）です。

核心は「いきなり作らない」

SDDの基本ワークフローはこうです：

1. 曖昧な指示をまず「仕様書」に落とし込む
        ↓
2. 人間が仕様書をレビュー・承認する
        ↓
3. 承認された仕様書に基づいてAIが実装

AIが作業、人間が意思決定

この役割分担がポイントです。「作らせてみて間違いに気づいて時間を無駄にした」を防ぐために、いきなり作らないのです。

3. 具体的な実践プロセス

中利さんが使ったのはKiroとcc-sddというツール。以下の3ステップで進めます：

Step	内容	詳細
1. Requirements	要件定義書の生成	スコープと機能の確認
2. Design	アーキテクチャ設計	データ構造定義
3. Tasks	実装タスクへの分解	タスクに抜け漏れがないか確認

要件定義から実装までを1ステップずつレビューしながら進めるのが特徴です。

4. 試してみた結果

実際の効果

ユーザーストーリー単位で要件を書いてくれる
同じようなプロジェクトと比較して開発スピードが4〜5倍に！

課題

ただし、いいことばかりではありません。

仕様書の量が単純に多い（数えてみたら約1400行）
一人でレビューは難しい → チームメンバーに見てもらいながら進めた

5. SDDの課題とよくある誤解

課題：レビュー負荷

要件定義書の量が多いのは、ある程度避けられません。理想はモブエラボレーション（異なる職種の人がペアプロのように一緒に要件定義書をレビュー・修正していく）だそうです。

誤解1：ウォーターフォールへの回帰？

「SDDってウォーターフォールに戻ってるんじゃないの？」

これは中利さん自身も最初勘違いしていたそうですが、実際はアジャイル的にやるのがベストとのこと。小さな価値単位で仕様化と実装を回していくスタイルです。

誤解2：特殊なツールが必要？

Kiroを導入する必要がある…と思われがちですが、cc-sddやSpec KitならAIエージェントに普通のスラッシュコマンドとして入れることができます。

まとめ：SDDの強みと課題

強み	課題
曖昧さの克服：自然言語による曖昧な指示が引き起こす「認識のズレ」や「手戻り」を防止	レビュー負荷：仕様書のレビュー負荷という新たな問題が存在
分業の実現：「AIが実行し、人間が承認・意思決定する」という役割分担を実現	組織的な課題：職種を超えた協業体制の構築が必要