人が設計し、AIとつくる。仕様駆動開発という考え方

仕様を「信頼できる唯一の情報源」にする

本の核にあるのは、仕様を「信頼できる唯一の情報源（Single Source of Truth）」として扱うという考え方だ。

従来、仕様書はプロジェクトの最初に作られ、開発が進むうちに実態と乖離していくことが多かった。書いた時点で役目を終え、あとは誰も見ない「過去の成果物」になりがちだ。

仕様駆動開発では、仕様を過去の成果物ではなく、現在進行形で更新し続ける開発資産として扱う。ウォーターフォールの「先に決める明確さ」と、アジャイルの「変化に合わせる柔軟さ」を、仕様という一点で両立させようとする考え方だ。

AIに任せる前に、人間が何を決めるのか

AIにコードを書かせる前に、人間が決めておくべきことは思った以上に多い。本を読みながら、自分の言葉でも整理してみた。

• そもそも何の業務課題を解くのか
• どんな運用方式で回すのか
• どの解決策を採るのか
• 将来複雑化したときにどう耐えるのか
• 現場に本当に合うのか
• どこまでをスコープに含めるのか

これらは、AIが代わりに決めてくれるものではない。業務を理解し、現場を知っている人間が決めるべき領域だ。ここが曖昧なまま実装に進むと、その曖昧さがそのまま成果物に表れる。

曖昧な仕様は、そのまま実装に出る

AIは指示された内容を素早く形にしてくれる。ただ、それは裏を返せば、曖昧な指示は曖昧なまま、誤った前提は誤ったまま実装されるということでもある。

人間同士なら「たぶんこういう意図だろう」と補ってくれることもあるが、そこに頼り続けるのは危うい。だからこそ、仕様の精密さがAI時代にはより重要になる。実装が速くなったぶん、仕様の粗さが返ってくるのも速い。

これは、見た目より先に土台を固めるべきだというUIよりも構造が命という話とも、根っこは同じだと思っている。

仕様駆動開発を支える、三つの技術

本では、この開発スタイルを現実的に支える技術として、次の組み合わせが挙げられていた。

• Markdown ── 仕様を軽量なテキストで書き、読みやすく保つ
• Git / GitHub ── 仕様の変更履歴を残し、レビューできる形にする
• AI / AIエディタ ── 仕様をもとに実装を支援する

仕様をテキストで書き、バージョン管理し、その仕様を起点にAIへ渡す。こうすることで、仕様が「生きた資産」として回り続ける。理論としては前からあった考え方が、生成AIの登場でようやく実務に落ちるようになった、という感覚がある。

人間を起点に、AIと作る

本を通して一貫していたのは、ヒューマンインザループ ── 人間を流れの中心に置く、という姿勢だった。

役割を整理すると、こうなる。

• 人間 ── 業務を理解し、設計し、仕様を定め、レビューする
• AI ── その仕様をもとに、実装を支援する

AIに丸投げするのでも、AIを使わないのでもない。人間が責任を持つ部分と、AIに任せる部分を切り分ける。この線引きが、これからの開発では効いてくる。

自分が作りたい開発の流れ

本を踏まえて、自分が目指したい流れも整理できた。

• 1. 業務を理解する
• 2. 設計する
• 3. 仕様として書き起こす
• 4. Gitで管理する
• 5. Issueに分解する
• 6. AIに実装を支援してもらう
• 7. 人間がレビューする

上流の「理解・設計・仕様化」は人間が担い、実装は AI と一緒に進め、最後は人間がレビューで締める。業務システムのように、現場の事情と整合性が重い領域ほど、この流れが向いていると感じている。

おわりに

生成AIによって、コードを書く速度は確かに上がった。だが、速くなったのは実装であって、何を作るべきかを決める部分ではない。むしろそこは、これまで以上に人間の仕事として残る。

『仕様駆動開発 実践入門』は、その「人間が決める部分」をどう仕様として残し、AIとどう分担するかを考えるうえで、いい補助線になった。AIと開発する時代だからこそ、仕様を丁寧に書くことの価値が増している ── そう思わせてくれる一冊だった。