あらすじ
「ウォーターフォールの安定性」と「アジャイルの柔軟性」をAIで両立！
古くて新しい「仕様重視」の再発見
AIが実現する「仕様駆動開発」によって、仕様とコードが常に同期し、仕様とコードが最適なバランスを保てるようになります。その基本から実践方法まで、じっくり解説します。
本書では、GitHubが公式ブログで提唱した仕様駆動開発の4つの工程に、日本の組織特性を加味して、7つの工程として拡張・定義します。
【7つの工程】
1. 原則決定 → 2. 企画・要件定義 → 3. 設計計画 → 4. タスク分割
→ 5. 実装 → 6. 検証・受入 → 7. 移行・運用
さらに4つの原則と、3つの技術要素を定義し、仕様駆動開発を実現します。
【4つの原則】
●原則(1)「仕様は"生きたドキュメント"」
●原則(2)「仕様は”信頼できる唯一の情報源”」
●原則(3)「仕様は”変更と反復が前提”」
●原則(4)「AIでコストを抑える」
【3つの技術要素】
・Markdown
・Git/GitHub
・AI/AIエディが
仕様駆動開発は小規模チームから大規模組織まで展開できる開発手法です。組織への展開で陥りがちな落とし穴とその対策まで本書はカバーします。
感情タグBEST3
Posted by ブクログ
仕様駆動開発 実践入門
AIで実現する開発方法論
著：田中 秀樹
著：田中 秀彦
出版社：日経BP
ITシステムの構築に対して、仕様とコードをAIの支援で1対1で管理する
仕様をベースにするから、仕様駆動開発(Spec-Driven Development:SDD：スペック駆動開発とも)と呼ばれている
やがて、巨大システムもこの仕様駆動開発をつかって開発すれば、いままでよりもずっと速く、より安価に、高品質なものが生み出されていくことであろう
いまは、新規開発がメインであったとしても、いずれは、システム全体が、AIにわかるような仕様書があれば、部分開発でも仕様変更でも、デグレードを含めて、決められたテストをAIの支援で実施できるようになるだろう
仕様があって、それに対応するコードを生成する仕組みなのであるから、アジャイルもウォータフォールもない
仕様どおりにシステムを構築する仕組みである
仕組みとしては、３つ
①MarkdownというAIツールで分かる形で仕様書を書く
他に、CSV,JSON,YAMLが推奨されている
②Git/GitHubで管理を行う
③AIエディタであるCursor
CUIベースであり、すぐ実装できるので、Cursorが推奨されている
仕様駆動開発の基本サイクルは４つ
①非エンジニアが仕様を書く
②エンジニアが実装する
③エンジニアが仕様を確認する
④非エンジニアが確認をする
更新された仕様をお互いに確認し、必要に応じて修正や、要件の追加を行う仕組みである
やり方としては、２つの掲示板と、仕様のマスターを使う。
① issue：合意形成 というまだ決まっていないことを決める掲示板
② Pull Request：承認の場 という、すでに決まったことが正しく反映されているかを確認する掲示板
③ 仕様の一群を一元管理するためのマスター README.md :承認された仕様はすべてここに集約される
つまり、仕様のマスターである、README.md をシステムの中心において、構築すればいいということになる
Issue 議論の場：アイデアを出し合い合意形成する
ブランチ 作業の分岐 合意内容を反映させる作業を、本流に影響なく開始
Pull Request 承認のプロセス 変更を提案し、レビューを依頼、承認を得る
マージ 正式な反映 承認された仕様を本流(README.md)に統合
が手順である
そもそも、README.md の作り方
①仕様を記述する
②目的、背景、想定ユーザをさらに書く
③決まっていることを書く
④決まっていないことも書く
⑤AIに不明瞭な点はありますかと聞く
⑥変更を記録する
が手順である
４つの原則
①仕様は、生きたドキュメント
②仕様は、信頼できる唯一の情報源
③仕様は、変更と反復が前提
④AIでコストをおさえる
最初はあいまいな記述でも、AIと対話をしながら、実装できるベースにまで、詳細化できるというのもいい
仕様駆動開発は３つのループを回す
①作業のループ
②議論のループ
③７つの工程のループ である
仕様駆動開発の７つの工程
①原則決定工程
②企画・要件定義工程
③設計計画工程
④タスク分割工程
⑤実装工程
⑥検証・受入工程
⑦移行・運用工程
各工程は、AI駆動開発の手法によって、実装できるのが前提だ
７つの工程の歴史的起源というのがあって目からうろこでした。
①1970's ウォータフォール
②1980's後半 DOA データ中心アプローチ
③1980's後半 オブジェクト指向
④1990's ペルソナ開発
⑤2000's スクラム
⑥2000's ランニンググリーン（ムダを排除、リーン開発）
⑦2000's SBE（テスト駆動開発）
⑧2010's MDD（モデル駆動開発）
⑨2010's DevOps
⑩2020's AI駆動開発
やり方は、プロジェクトの規模人数によって若干ことなるようだ
①小規模チーム：３～５人 全員で仕様を共有できる規模
②中規模チーム：６～３０人 管理者が必要な規模
③大規模チーム：５０人以上 組織的な階層で管理を必要とする規模
まあ、最後に索引ぐらいはほしかったかも。
目次
ひと目でわかる！仕様駆動開発の全体像
はじめに なぜ今、仕様駆動開発なのか
第１章 仕様駆動開発の全体像
第２章 30分で実感する仕様駆動開発
第３章 Cursorで仕様を記述・活用する
第４章 GitHubとCursorで仕様を管理・活用する
第５章 最初の1週間で仕様駆動開発を始める方法
第６章 規模別に合意形成と承認を実現する方法
第７章 なぜ今、仕様駆動開発が実現可能になったのか
第８章 仕様駆動開発の思想的背景と設計思想
第９章 仕様駆動開発を成功させる要因
第10章 レガシー文書を仕様駆動開発に取り込む方法
第11章 仕様駆動開発の実践的進め方
第12章 組織全体導入のガバナンス設計
第13章 組織全体導入の文化変革
付録
A1 チェックリスト一覧
A2 トラブルシューティングガイド
A3 引用文献一覧
A4 用語集
あとがき
ISBN：9784296080496
判型：A5
ページ数：400ページ
定価：3500円（本体）
2026年03月25日 第１版第１刷発行
