その本の「はじめに」には、著者の「伝えたいこと」がギュッと詰め込まれています。この連載では毎日、おすすめ本の「はじめに」と「目次」をご紹介します。今日は田中秀樹さん、田中秀彦さんの『 仕様駆動開発 実践入門 AIで実現する開発方法論 』。「はじめに」の一部略版をお届けします。
はじめに：なぜ今、仕様駆動開発なのか
AI技術で、仕様を原動力にできる
システム開発において、仕様書や設計書は最も価値ある資産のうちの1つです。これが、本書の出発点です。
仕様駆動開発とは、「仕様そのものを出発点・原動力としてシステム開発全体を推進する手法」です。
従来、仕様をシステム開発の原動力とすることは大きな工数がかかり困難でした。仕様を書いても、それをコードに変換する作業に時間がかかり、仕様を原動力とすることは現実的ではありませんでした。
しかし、AI技術の登場により、この理想が実現可能になりました。AI技術を使えば、書いた仕様からコードを自動生成できます。AIがあれば、仕様をシステム開発の原動力にできます。
これが、なぜ今、仕様駆動開発なのかという問いに対する答えです。
仕様駆動開発は、真に役立つ仕様書・設計書を作る方法ともいえます。仕様書や設計書を開発チームの日常的な参照資料として活用し、コードと常に同期させることができるからです。これが、仕様を原動力とした1つの形です。
歴史を重ね成熟期を迎えた開発方法論
歴史をひも解くと、システム開発が世界で初めて行われて以来、それは苦難の連続でした。人は、それらの苦難に対して、ウォーターフォールやアジャイル開発など、いわゆる開発方法論で解決を試みてきました。
● ウォーターフォール開発の「仕様の明確化」という強み
● アジャイル開発の「変化への柔軟な対応」という強み
仕様駆動開発は、この両方を取り入れることで、仕様を信頼できる基盤としながら、変化に対応できる開発を可能にします。いわば、「ウォーターフォールの安定性とアジャイル開発の柔軟性のいいとこ取り」を実現するものです。その理論的な背景は第8章で詳しく紹介します。
「仕様駆動開発」という言葉は、現在の生成AIが登場するはるか前の2004年に論文として登場しています。GitHubやAWSによって最近生み出された「バズワード」ではないのです。この論文から現在に至る道筋についても第8章で紹介します。
また仕様駆動開発は、その成り立ちから、小規模開発から大規模開発まで、多くのシステム開発の現場に適用できる可能性がある開発方法論です。
ただし、仕様駆動開発をしっかり組織に根付かせることは容易ではありません。「AIにより開発手法は根底から変わっていく」ことは多くの方の同意を得られるでしょう。それでも変化には必ず抵抗があるものです。それを打ち破る方法については、第11～13章で詳しく解説します。
よくある誤解：仕様駆動開発は「ウォーターフォール」ではない
次の第1章から仕様駆動開発について詳しく解説していきますが、その前に「よくある誤解」を解いておきます。ウォーターフォール開発とアジャイル開発との関係性です。
「仕様を重視する」と聞くと、従来のウォーターフォール開発を思い浮かべる方もいるでしょう。確かに、仕様駆動開発では仕様を重視しますが、そもそも、開発プロセス（ウォーターフォール／アジャイル）とは独立した概念なのです。
なぜ誤解が生まれるのか
この誤解は自然なものです。なぜなら、従来のウォーターフォール開発では、プロジェクト初期に仕様を確定し、その後は変更を極力避けるという進め方が一般的だったからです。そのため、「仕様を重視する＝ウォーターフォール開発」と連想されやすいのです。
しかし、第1章で解説する4つの原則と7つの工程を理解していくと、仕様駆動開発がウォーターフォール開発とは全く異なることがわかります。
4つの原則が示す違い
仕様駆動開発の4つの原則（第1章で詳述）は、従来のウォーターフォール開発とは明確に異なります。
● 原則①「仕様は"生きたドキュメント"」：仕様は固定ではなく、継続的に更新される
● 原則②「仕様は"信頼できる唯一の情報源"」：会話やメールに頼らず、仕様に立ち返る
● 原則③「仕様は"変更と反復が前提"」：変化を例外扱いせず、必然として取り込む
● 原則④「AIでコストを抑える」：AIの支援で生産性を向上させ、仕様の更新コストを劇的に削減
これらの原則を実践すると、仕様は「一度書いて終わり」ではなく、「常に進化し続ける」ものになります。これが、ウォーターフォール開発との最大の違いです。
7つの工程が示す柔軟性
7つの工程（第1章で詳述）も、ウォーターフォール開発の「順序的な進行」とは異なります。次に示す7つの工程は、必要に応じて反復し、行き来することが前提です。
1. 原則決定 → 2. 企画・要件定義 → 3. 設計計画 → 4. タスク分割 → 5. 実装 → 6. 検証・受入 → 7. 移行・運用
この工程は次に示すように一方向には進みません。
● 実装中に仕様を更新：実装で得られた学びを仕様に反映（工程5 →工程2）
● 検証で問題が見つかれば設計に戻る：柔軟に戻って修正（工程6 →工程3）
● 運用中の学びを次の企画に活かす：継続的改善（工程7 →工程2）
これは、ウォーターフォールの場合のシステム開発とは異なります。むしろアジャイル開発に近い進め方です。仕様駆動開発は「計画→設計→実装→テスト」という一方向の流れではなく、「仕様を書く→実装する→フィードバックを得る→仕様を更新する」という反復的なサイクルで進みます。
アジャイル開発との関係
アジャイル開発を実践している方からは、「アジャイルでは文書より対話を重視するのでは？」という疑問を持たれることもあります。
アジャイルソフトウェア開発宣言には、「包括的なドキュメントよりも動くソフトウェアを」とあります。しかし、これは「ドキュメント不要」という意味ではありません。
仕様駆動開発は、アジャイル開発の価値観と矛盾しません。むしろ、アジャイル開発を支援するツールとして機能します。
● スプリント計画：仕様を、GitホスティングサービスであるGitHubのIssueで管理し、スプリントバックログと同期
● デイリースタンドアップ：GitHubのPull Requestの進捗状況を共有
● スプリントレビュー：仕様の変更履歴を通じて「何が変わったか」を明確化
● レトロスペクティブ：仕様レビューのフィードバックを改善に活用
「仕様」はどこまで詳しく書くのか
「仕様駆動開発では、詳細設計レベルまで書く必要があるのか？」という質問もよく受けます。
答えは、「プロジェクトの性質と規模による」です。しかし、重要なのは、「詳細設計のすべて」を仕様に書く必要はないということです。
仕様駆動開発では、以下の判断基準に従います（第3章で詳述）。
●「Why（なぜ）」と「What（何を）」は仕様に書く
●「How（どうやって）」はコードとコメントに書く
対象のシステムによって、仕様を書く範囲は変わります。例えば、ログイン機能を例にすると次のようになります。
● 小規模なWebアプリ：仕様を記述・体系化した文書であるREADME.mdに「ユーザーログイン機能が必要（Why：セキュリティ確保）」と書くだけで十分。認証ライブラリの選定や実装方法（How）はコードに任せる
● 金融システム：「なぜOAuth 2.0を使うか」（セキュリティ基準への準拠）、「どのフローを採用するか」（Authorization Code Flow）まで仕様に明記。実装の詳細（How）はコードに任せる
AIがコードを生成できる時代において、「実装の指示書」としての詳細設計書は不要です。代わりに、「判断の根拠」「制約条件」「ビジネス要件」を明確にすることが重要です。
さまざまな開発手法の中での仕様駆動開発の位置づけ
まとめると、仕様駆動開発は次のようなものです。
● 開発プロセス（ウォーターフォール／アジャイル）とは独立した、仕様管理の手法
● どの開発プロセスでも適用可能（むしろアジャイルと相性が良い）
● 文書の量ではなく質を重視（必要な分だけ、継続的に更新）
● AIとの協働により、従来は困難だった「仕様とコードの同期」を実現
第1章で解説する4つの原則と7つの工程を理解することで、仕様駆動開発が「ウォーターフォール開発の再現」ではなく、「仕様を原動力とした新しい開発手法」であることがわかります。そして、AIとの協働により、従来は困難だった「仕様とコードの同期」を現実的なコストで実現できるのです。
「仕様」「コード」などの言葉の定義
本書における「仕様」「コード」などの用語の定義を、表1で整理します。そして、本書全体で解説していく、仕様駆動開発が目指す3つの「理想像」について説明します。
仕様とコードのあるべき姿
仕様とコードのあるべき姿は、仕様が信頼され、現場で使われる状態です。仕様とコードが常に一致し、関係者全員が同じ仕様を参照しながら開発を進められます。仕様とコードの良いバランスを保つことが重要です。
多くの現場では、このあるべき姿になっていない場合もあります。「ひとまず動くものを先に作り、仕様は後でまとめる」といった状態や、「仕様書を書いたものの、あまり見られていない」といったケースです。
あるべき姿を実現するには、人間だけでは困難です。AIを支援ツールとして最大限活用する必要があります。
より理想を明確にし、イメージしやすくするために、現代のシステム開発現場で目指したい3つの理想像を挙げます。
● 理想像1：仕様とコードは常に同期している
● 理想像2：仕様とコードは最適なバランスが保たれている
● 理想像3：仕様とコードの同期・修正はAIの支援で行う
システム開発で目指すべき3つの理想像を実現する方法が、仕様駆動開発なのです。
理想像1：仕様とコードは常に同期している
ドキュメントが少なければ、それを維持するのは簡単です。しかし、量が増えるほどコードとの一貫性を保つのが難しくなります。プロジェクトが大きくなるほど契約や納品といった手続きが増え、多くの書類が必要です。
さらに最近のシステム開発では、やりとりが電話やオンライン会議、チャットやメールなどさまざまなツールが活用されます。そのため、仕様とコードの同期がさらに難しくなります。
仕様とコードを常に同期させ、仕様書・設計書を最新に保つことによる主なメリットは、以下の通りです。
● 誤った情報による手戻りやミスの防止
● 関係者全員が正しい情報にアクセス可能
● 開発の優先度やタスクの状況が把握しやすい
● 新メンバーのオンボーディングが容易
● チーム全体での知識共有・ナレッジ蓄積が進む
「仕様とコードを常に同期させる」メリットは多く、さまざまなシステム開発で重要です。
理想像2：仕様とコードは最適なバランスが保たれている
仕様とコードの最適なバランスを保つことは、システム開発において重要です。文書が全くないことも、多すぎることも問題となります。
2001年に発表された「アジャイルソフトウェア開発宣言」以降、アジャイル開発は広く普及しました。しかし、多くの現場で「アジャイル開発＝文書不要」という誤解が広がっています。これは正しくありません。
アジャイル開発には、スプリント（通常1～4週間の反復開発期間）と呼ばれる繰り返しのプロセスがあります。要求が目まぐるしく変わるため、その度に正式な文書を変更すると、文書作成に時間を費やしすぎてしまいます。一方で、文書を全く作らないと、仕様が不明確になり、開発が混乱します。
仕様とコードの最適なバランスを保つことによる主なメリットは、以下の通りです。
● 知識の属人化を防ぎ、チーム全体で知識を共有できる
● 特定のメンバーが休暇を取っても、システム開発を支障なく進められる
● 実装も進み、コードが書かれ、仕様とコードのバランスが維持される
● 過度に詳細な文書で開発が停滞することもなく、文書不足でコードの意図が不明確になることもない
仕様とコードの最適なバランスを保つことは、アジャイル開発でも、その他のさまざまな開発手法でも重要です。
理想像3：仕様とコードの同期・修正はAIの支援で行う
理想像1「仕様とコードは常に同期している」と理想像2「仕様とコードは最適なバランスが保たれている」を実現すれば、仕様書と設計書が明確に存在し、常に最新の状態が保たれます。しかし、ここで新たな課題が浮かび上がります。それは、その労力です。
以前は、仕様の修正やコードとの同期を手作業で行う必要がありました。仕様が変更されれば、関連するコードをすべて確認し、手動で更新する必要があります。コードが変更されれば、仕様書との整合性を確認し、必要に応じて仕様書も更新する必要があります。
こうした「仕様を変える→コードを変える」「コードを変える→仕様を変える」という双方向の同期作業は、プロジェクトが大きくなるほど、人間の手に余るようになります。これらの作業は、設計書通りに実装されているかを照合・突合するもので、一般的に「レビュー」と呼ばれます。一人で行うとミスが発生しやすいため、レビューは通常、複数名・会議形式で実施されてきました。
そんな中、2022年のChatGPT登場以降、AIが開発現場に急速に浸透しました。GitHub Copilot、Cursor、Windsurf、Kiro、Antigravity、Claude Code、Codexなど、さまざまなAIコーディング支援ツールが、エンジニアの日常となっています。AIは、レビューなども含め、人間を支援できます。
仕様とコードの同期・修正をAIの支援で行うことによる主なメリットは、以下の通りです。
● 仕様とコードの両方を理解し、変更を自動的に検出できる
● 仕様とコードの整合性を保つための支援を受けられる
● 理想像1「仕様とコードは常に同期している」状態をAIを使って検証できる
● 理想像2「仕様とコードは最適なバランスが保たれている」ことをAIを使って検証できる
● AIが生成したコードが、本当に求められていた機能を実装しているかを確認できる
すなわち、2つの理想像を実現する際に発生する多大な負荷を、AIの強力な支援で低減することが、3つめの理想像です。
本書の構成と読み進め方
本書は、現場で実際に取り組んでいる経験に基づいて執筆しました。また理論から実践、そして組織への展開まで、段階的に学べるよう構成しました。各章の意図を理解することで、より効果的に仕様駆動開発を実践できるでしょう。
● はじめに（本稿）：なぜ今、仕様駆動開発なのか（3つの理想像）
● 第1章：仕様駆動開発の全体像（3つの技術要素、4つの原則、7つの工程）
● 第2章：30分で実感する仕様駆動開発（GitHubのWebインターフェースだけで実践）
● 第3章：Cursorで仕様を記述・活用する（AIエディタの使い方）
● 第4章：GitHubとCursorで仕様を管理・活用する（3つの技術要素の統合）
● 第5章：最初の1週間で仕様駆動開発を始める方法（実践の始め方）
● 第6章：規模別に合意形成と承認を実現する方法（IssueとPull Request）
● 第7章：なぜ今、仕様駆動開発が実現可能になったのか（歴史的背景）
● 第8章：仕様駆動開発の思想的背景と設計思想（理論的基盤）
● 第9章：仕様駆動開発を成功させる要因（状況適合と状況適応）
● 第10章：レガシー文書を仕様駆動開発に取り込む方法（Docs-as-Code）
● 第11章：仕様駆動開発の実践的進め方（組織への展開）
● 第12章：組織全体導入のガバナンス設計（セキュリティ・監査）
● 第13章：組織全体導入の文化変革（チーム文化とマネジメントの変革）
実践的なリソース
本書では、練習用リポジトリとしてSDDリポジトリ（GitHubリポジトリ『elvezjp/SDD』、https://github.com/elvezjp/SDD）を用意しています。SDDリポジトリについての詳細は、第2章2.5「練習用リポジトリ（SDDリポジトリ）を活用する」を参照してください。
このSDDリポジトリでは、仕様駆動開発を進めていくための実践的なリソースが豊富に提供されています。
「完璧じゃないREADME.md」から始めよう
本稿の冒頭で、仕様駆動開発は真に役立つ仕様書・設計書を作る方法であることを説明しました。システム開発に関わる多くの方が、これが理想であることは理解していることでしょう。
しかし、仕様駆動開発を実現するには、AI技術が必要でした。AIが発展している昨今ではありますが、それをどのように適用するのかは、とても難しい問題です。
ここで1つ大切なことがあります。仕様駆動開発は、完璧な仕様を最初から書く必要はありません。むしろ、チームで共有され、継続的に成長していく仕様こそが、仕様駆動開発の目指すものです。「まず書いて、育てていく」という気持ちが重要です。
本書でも紹介するGitHubというサービスでは、ディレクトリを説明するためのREADME.mdというファイルがよく使われます。最初は、このREADME.mdを少し見るだけで、大丈夫です。次には、少し編集して、保存するだけで、大丈夫です。
最初のREADME.mdは、完璧ではないでしょう。そのREADME.mdで問題ありません。
完璧じゃないREADME.mdから始めましょう。
【目次】
