スペック駆動開発とcc-sddの仕組みを図解しながら整理してみた

仕様書を実装より先に確定させる開発手法が「スペック駆動開発」だ。これ自体は昔から存在する考え方だが、ここ1～2年でAIコーディングツールが浸透してきたのに伴って、改めて定義が整理され、実運用に耐えるハーネス（cc-sddという日本製ツール）が生まれた。AWSも同じ考え方の上にKiroという開発ツールを立ち上げており、大手も小さなスタートアップも、同じ方向に賭けている。重要なのはツールではなく、AIが実装を始める前に「何が正解か」を人間が機械判定できるレベルまで仕様化する、という発想の転換だ。

AIの鬼が見ている奥行きはここだ。従来のウォーターフォール開発も仕様書を作るのに、何が違うのか。答えはシンプル——従来は仕様書とコードの間に「人間の記憶と善意」しかないということだ。実装者が仕様を読んで頭の中で解釈し、コードを書く。その後、コードと仕様がズレていても、バグ報告が来るまで気づかない。スペック駆動開発では、仕様書が何度も何度も機械的に読み返され、実コードと照合される。ズレていれば、次のレビュー工程で弾かれて先に進めない。つまり、仕様と実装の乖離が「構造的に起きにくくなる」のだ。

AI開発が当たり前になった現場こそ、この仕組みが効く。「プロンプトを試行錯誤する」開発では、何が正解か曖昧なまま進む。だが中小企業が実務ツールを作るなら、「このボタンを押すと在庫が1減る」のように、YESかNOか判定できるレベルまで仕様を落とさねばならない。仕様が確定していれば、あとはAIに「この仕様を満たすコードを書け」と指示するだけで、レビューも単純化される。