「仕様駆動開発」と「Vibe Coding」は何が違う？
セッションの冒頭で吉田氏は「今日のゴールは、みなさんが仕様駆動開発を今日から始めてみたいと思うことです」と宣言した。そこで吉田氏は、著書『実践Claude Code入門』第4章の内容をもとに、仕様駆動開発を体験できるシンプルなデモを行った。
デモはまず、CLAUDE.mdに記載する開発ルールを、Claude Code自身に生成させるところから始まった。生成されるルールは250行ほどで、必要なドキュメントの種類や、作業ごとに専用フォルダを作るといった規約が定義されている。このルールに基づき、要件定義、設計書・タスクリストの生成、アーキテクチャ仕様書の作成と進んでいき、内容を確認した上で実装に移る、という流れだ。
作業単位のファイル管理とマスター仕様書の継続的なメンテナンスという2点を押さえるだけで、コーディングやテストを着実に進められる、とてもシンプルな方法だ。
仕様駆動開発のメリットを実感するには、併せてVibe Codingも試してみてほしいと、吉田氏は勧める。Vibe Codingとは、音声や自然言語による指示でLLMにコードを生成させ、成果物を詳しくレビューせずに進める方法だ。スキルのあるエンジニアであればプロトタイピングの手段として活用の余地があるが、慣れていないと成果物の動作が不安定な、いわば「ガチャを引く」ような開発手法でもあると、吉田氏は言う。
「エンジニアであれば、何をどのように開発すべきかを明確にし、ねらい通りに開発を進めたいはずです。つまり、ソフトウェアエンジニアリングをしっかりとやりたいのです」と、仕様駆動開発の優位性を説明する。
しかし一方で、「現実の複雑な開発に適用するにはシンプルすぎるかもしれない」と仕様駆動開発の課題についても率直に語る。第1の課題は、ステアリングポリシーをCLAUDE.mdに集中させることによるコンテキストの浪費だ。すべてのルールを1つのファイルに書き込むとメモリーファイルが肥大化し、Claude Codeが動作するたびに全内容を読み込むため、コンテキストウィンドウを圧迫してしまう。さらにCLAUDE.mdに詳細なルールを書いてしまうと、そこに書かれていない動きを自律的に行わなくなる傾向があるという。ルールは必要なタイミングで必要な分だけ読み込む構造にしておく方が望ましい。
第2の問題は、状態管理と監査証跡の不十分さだ。書籍のアプローチでは作業単位のタスクリストが事実上の状態管理を兼ねているが、ユーザーがどのような入力を行い、AIがどう判断したかというやり取りの詳細までは記録されない。すると開発が進むにつれて、過去の意思決定の根拠を辿れなくなるリスクが高まる。本格的な仕様駆動開発で求められるトレーサビリティの確保には、より体系的な仕組みが必要になると吉田氏は指摘する。
