連載「業務SEのための仕様駆動開発」第2回
SDDのツールが次々に出てきて、どれを覚えればいいのか分からない
仕様駆動開発（SDD：Spec-Driven Development）という言葉を見かけるようになって、しばらく経ちました。Kiro、cc-sdd、GitHub Spec Kit と、関連するツールも次々に出てきています。
気になって調べてみるものの、ツールごとにコマンドもファイル名も違います。どれを選べばいいのか、覚えたところで来年も使えるのか。そう考えて、手が止まっている方も多いのではないでしょうか。
私は、仕様駆動開発の専用ツールを使わずに、この進め方をしています。使っているのは、フォルダとMarkdownのファイルだけです。今回は、その置き方を紹介します。
結論：SDDの中身は「順番」。順番を守れば、ツールがなくても回せる
ツールの画面やコマンドは違っても、仕様駆動開発のツールがやっていることは共通しています。いきなりコードを書かせず、要件、設計、タスクのように、文書を順番につくらせることです。
つまり、ツールの本体は「順番を守らせる仕組み」です。順番を自分で守れるなら、ツールは必須ではありません。
そして、この「決めてから作る」順番は、エンジニアにとって目新しいものではありません。ウォーターフォールです。私は、仕様駆動開発とは、ウォーターフォールの順番をAIに守らせるやり方だと考えています。
5つの工程で進める
私は、次の5つの順番で進めます。
- 目的確定
- 設計
- テスト作成
- 実装
- テスト
ツールによって流れは少しずつ違いますが、私は「テスト作成」を、実装の前の独立した工程として置いています。先に合格ラインを文書にしておくと、AIが作ったものを人が判定できるからです（テスト作成の話は第3回で扱います）。
目的確定は、前回紹介した「目的・合格ライン・制約」を決める工程です。ツールでいえば「要件」の文書にあたるところですが、私はその手前の「何のためにやるのか」から文書にします。要件は、目的が決まってから出てくるものだからです。
型：フォルダとファイルの置き方
私は、次のような構成でフォルダをつくっています。コピーして使ってください。
プロジェクト/
├── input/ # 渡された資料（既存の仕様書、画面の画像、データのサンプルなど）
├── output/
│ ├── 01_目的確定.md
│ ├── 02_設計.md
│ ├── 03_テスト作成.md
│ ├── 04_テスト結果.md
│ ├── 要作業一覧_進捗.md # 課題ごとの進み具合（％）
│ └── 引き継ぎ.md # 作業を離れるときの申し送り
├── src/ # プログラム
└── 履歴.md # いつ、何を決めて、何をしたか
ポイントは3つです。
1. 工程の文書には、番号をつける
01_ 02_ と番号を振るだけで、どこまで進んだかがファイル一覧で分かります。AIに対しても「02_設計.md を読んで、03_テスト作成.md をつくって」と、ファイル名で指示できるようになります。
そして、前の文書を人が読んで「これでいい」と言うまで、次の文書に進ませません。 ツールがやってくれる順番の管理を、ここで人が引き受けるわけです。
2. 管理用のファイルを3つ置く
工程の文書とは別に、次の3つを置いています。
- 履歴：いつ、何を決めて、何をしたか。後から「なぜこうなったんだっけ」と思ったときに見る
- 引き継ぎ：作業を離れるときの申し送り。いま何をしていて、次に何をするか
- 要作業一覧・進捗：課題の一覧と、それぞれの進み具合
この3つが効くのは、AIは、会話が変わると前回のことを覚えていないからです。翌日に新しい会話を始めても、まず引き継ぎを読ませれば、前回の続きから始められます。別のAIに渡すときも同じです。
引き継ぎに書くのは、長い報告ではありません。たとえば「設計はOKが出た。次はテスト作成。画面に出す項目の並び順だけ、まだ決まっていない」くらいです。これだけでも、AIは次に何をすべきかが分かり、人も「そうだった」と思い出せます。
3. ルールも文書にしておく
フォルダの置き方や「OKが出るまで次に進まない」といったルールも、文字にしておきます。Claude Codeなら、プロジェクトの CLAUDE.md に書いておくと、会話のたびに読み込まれます。毎回同じ説明をしなくて済みます。
たとえば、次のように書きます。コピーして、案件に合わせて直してください。
# CLAUDE.md
- 返答と文書は日本語で書く
- 工程の文書は output/ に、01_目的確定.md から番号順に置く
- 前の工程の文書に人のOKが出るまで、次の工程に進まない
- 仕様書に書いていないことは、勝手に足さずに質問する
- 既存のコードの書き方（名前の付け方、インデント）に合わせる
- 作業の最後に、変更したファイルと変更した理由をまとめる
箇条書きで数行あれば十分です。
ツールを否定したいわけではありません
チームでKiroやcc-sddを使うと決まっているなら、それに乗るのがいいと思います。ツールには、順番を自動で守らせてくれる便利さがあります。
ただ、ツールは変わります。1年後に同じツールが同じ形で使えるとは限りません。一方、Markdownの文書は、どのAIにも、後から来た人にも、そのまま渡せます。ツールが変わっても、文書は残ります。
だから私は、ツールより先に「順番」と「文書」を身につけることをおすすめしています。順番が身についていれば、どのツールに移っても、中で何が起きているかが分かります。
私の場合：専用ツールなしで、案件を回してきました
私は、仕様駆動開発の専用ツールに頼らず、このフォルダと文書だけで複数の案件を回してきました。
文書が残っていると、判断の理由も後から追えます。「なぜこの順番にしたのか」「なぜこの案をやめたのか」は、履歴を見れば分かります。
まとめ
- 仕様駆動開発のツールがやっているのは、文書を順番につくらせること
- その順番は、エンジニアが知っているウォーターフォールと同じ
- フォルダと番号つきのMarkdownファイルで、順番は自分で守れる
- 履歴・引き継ぎ・進捗の3ファイルを置くと、会話が変わっても続きから再開できる
次回は、5つの工程のうち、いちばん飛ばされがちな「テスト作成」を扱います。実装の前に、テスト仕様書をAIに書かせる理由と、業務システム向けのテスト観点表を紹介します。
連載「業務SEのための仕様駆動開発」
一覧はこちら → https://qiita.com/sha44444/stocks/3c9167054a4a82837bb3
この連載では、仕様駆動開発の「型」を1回に1つずつ紹介しています。
5つの工程を実案件でどう回しているか（各工程でAIに渡す依頼文、変更が入ったときの回し方、通しの実例）は、1冊の本にまとめました。第1章は無料で読めます。
→ https://zenn.dev/shin4/books/31499dd20de8ac