はじめに
Spec-Driven Development 自体はめちゃくちゃいい手法だと思っています。仕様を先に定義して、それをベースに開発を進める。考え方としてはイケてると思ってます。
ただ、やっていると感じると思うんですけど、どんなに仕様書を詰めてレビューしてもらって修正して、っていうフローを回すのがまず大変です。まあそれはいいとして、じゃあ頑張って仕様書ができましたってなったとしても、実装していく中でどうしてもずれとか要件の抜け漏れが出てきてしまう。
そのときに仕様書の修正までちゃんとやればいいんですけど、多分ほとんどの場合は仕様書の修正なんてしないんですよね。結果的に、Specで書いた内容や詳細設計の内容と実際の実装がどんどん違ってくる。差分が増えていく。これが結局きついっていうのが、Spec-Driven Developmentをやっていて感じた一番の課題です。
そんな中で、PRD駆動開発がいいんじゃないかと考えるようになりました。
PRD駆動開発とは何か
現状のSpec-Driven Developmentって、やりたいことや目標の話からスタートして、最終的には詳細設計のところまで設計を仕切ってから実装を開始する、っていう流れが一般的かなと思います。そこまでの全部をドキュメントとしてちゃんと残して、それをベースに開発していく。
僕が考えているPRD駆動開発は、ここの考え方がちょっと違います。
- なぜやるのか
- ユーザーにとってどういう価値があるのか
- なぜ修正したいのか
- どういう機能をつけたいのか
- どういう体験ができる機能が欲しいのか
こういった要望ベース、機能ベースの内容は引き続きしっかり書きます。ここは今まで通りです。
ただ、詳細設計 ── 実際にこういうふうに実装しますとか、こういうデータベース設計にしますとか ── こういうのはSpecには書かないです。Issueベースで管理して、Issueは実装が完了したら捨てる。これが僕の提案です。
なぜそれでいいかというと、ソースコード自体が詳細設計のシングルソースオブトゥルースだからです。
整理するとこうなります。
| 役割 | 寿命 | |
|---|---|---|
| PRD | なぜ作るか・何を作るか・どんな体験を提供するか | 永続的に残す |
| Issue | 作業単位（詳細設計を含む） | 実装完了したら捨てる |
| ソースコード | 詳細設計の正本（仕様書そのもの） | 永続的に残す |
PRDは残す。Issueは捨てる。コードが仕様書。これがPRD駆動開発の基本的な考え方です。
開発フロー
実際の開発フローはこんな感じで回しています。
流れをまとめると:
- 人間がPRDを作成して、PRを作ってマージする
- マージをトリガーにGitHub Actionsが走り、AIが勝手にIssue分割してくれる
- 分割されたIssueを人間がレビューする
- レビューが完了してマージするとIssueが
status: readyになる -
status: readyのIssueを別のAIが自動でフェッチしてきて実装し、PRまで作成する - CIが失敗した場合は自己修正（セルフヒーリング） の機能が付いていて、自動で直してくれる
- PRの影響度が低いものは自動マージ、それ以外は人間がレビュー
人間がやるのは「PRDを書く」「Issueをレビューする」「影響度の高いPRをレビューする」の3つだけです。
PRDに書くこと
PRDに書く内容はシンプルです。
- やりたいこと
- 作ろうとしている機能のざっくりした体験
- ユーザーがどのような体験をするかのまとめ
具体的なセクションとしてはこんな感じです。
| セクション | 役割 |
|---|---|
| Summary | 3〜5行で何を実現するか |
| Problem / User Value | 誰にどう価値があるか |
| Goals / Non Goals | 達成目標と範囲外 |
| Scope | 対象画面・機能 |
| Requirements | 実装要件 |
| Constraints / Risks | 制約と既存互換条件 |
| Success Metrics | 成功指標 |
| Acceptance Criteria | 完了条件 |
| Validation / Rollout | 検証方法と展開方針 |
繰り返しになりますが、ここに詳細設計は書かないです。DB設計とか、クラス設計とか、API設計とかは書かない。それはIssueとコードの仕事です。
まとめ
同じようなことを考えている人は結構いるんじゃないかなと思っています。今回はそれっぽく自分なりに名前をつけて、PRD駆動開発として提案してみました。
もちろん、同じような発信をしている人はいっぱいいると思いますし、もっといいやり方があるかもしれないです。「こういうところが課題感としてありそうだよ」とか「うちではこうやってるよ」みたいなのがあれば、感想でいただけるとうれしいです。
僕のチームで少し運用してみて課題感とか出てきたらまた記事書こうと思います！