PRDからバックログへ：要件への糸を切らずにAIで計画済みissueを生成する

要件への糸が重要な理由

PRDから生成したバックログは初日には完成して見えます。40件のissue、整ったタイトル、きれいなラベル。2サイクル後に誰かが「エクスポート上限は作ったっけ？」と聞くと、誰も答えられません。それを担っていたissueは分割され、改名され、別のissueと統合され、その間にPRDは2回編集されていたからです。

各issueから、それが実装する正確な要件への糸があれば、その質問に答えられます。また、エージェントや人が後からカバレッジ確認を行うこともできます。どの要件にissueがないか、どのissueがどの要件も指していないか、どの要件がissue作成後に変わったか。糸がなければ「カバレッジ」は気分にすぎません。

したがって最初のルールは、生成前にPRDを凍結し、すべてのissueに要件をidで引用させることです。

渡す前にPRDを整える

エージェントは曖昧なPRDを忠実に曖昧なissueに変えます。文書に30分かければ、チケット整理の1日が浮きます。

1. 要件に番号を振る。 R1、R2、R3、あるいは入れ子の体系。エージェントには引用できる安定した取っ手が必要です。散文の段落は取っ手になりません。
2. 各要件に受け入れ基準を付ける。 「前提 / 操作 / 結果」形式かシンプルなチェックリストで2〜4行。基準を書けない要件はissueになる準備ができておらず、エージェントが基準をでっち上げます。
3. 非ゴールを明記する。 対象外の短いリストがあれば、意図的にやらないことのissueをエージェントが生成するのを防げます。
4. 凍結する。 版を保存し、ベースラインとしてラベルを付け、その版からだけ生成します。後の編集は新しいベースラインと差分を生むのであって、進行中のissueを静かに変えるものではありません。

私たちのPRDテンプレートがこの順番でこれらのセクションを持つのは、まさにこのためです。

エージェントへのブリーフ

ブリーフは短く厳格です。私たちのものを少し編集して示します。

入力: PRD「予約リマインダー」v3（凍結ベースライン）。要件R1〜R9、
それぞれ受け入れ基準付き。非ゴールのセクションは拘束力を持つ。

次の条件を満たす計画済みissueを作ること:
- 各issueは実装する要件idをちょうど1つ名指しする。
- 各issueはその要件の受け入れ基準をそのまま写し、その後に必要な
  技術的基準を追加する。
- 各issueは1人が1サイクルで終えられる大きさにする。要件がそれ以上を
  必要とするなら分割し、各部分がどう組み合わさるかを書く。
- 各issueは既存ラベル一覧からタイプラベル（feature, bug, chore）を1つ、
  領域ラベルを1つ付ける。ラベルを新規作成しない。
- 非ゴールを実装するissueを作らない。
- issueにできなかった要件を列挙し、理由を書く。

計画済みissueのみ作成すること。既存のissueやステータスは変更しない。

最後の行はエージェントの権限に対応します。計画の実行には計画済みissueを作るための work.write を与え、稼働中のボードに触れるものは与えません。

良い生成issueの姿

この表はレビューのチェックリストも兼ねます。40件のissueを6列で確認するのに約40分で、書くより速く、後で穴を見つけるよりはるかに速いです。

却下ルール：バックログに受け入れないもの

却下し、理由を添えてエージェントに戻します。

• 要件idがない。 最も多い失敗。issue自体はまともかもしれませんが追跡できません。要件を実装するなら引用し、保守作業ならそうラベルを付け、スコープの膨張なら捨てます。
• 1つのissueに複数の要件id。 それはissueではなくエピックです。分割します。
• 受け入れ基準が写しではなく言い換え。 言い換えはずれていきます。issueの基準はPRDの基準そのものでなければならず、技術的な追加は追加だと明記します。
• 「正しく動く」「設計どおり」が基準。 テストできません。却下。
• 非ゴールのissue。 エージェントは非ゴールを読んだ上で生成します。起こることです。却下。
• 1人が1サイクルで終える姿を思い描けないサイズ。 あなたに終わりが見えなければ、担当者にも見えません。
• 発明されたラベルやコンポーネント。 エージェントは与えられたラベル一覧を使うべきです。新しいラベルは人が決めます。

通常は2ラウンドで十分です。3ラウンド目でも同じ失敗が出るなら、問題はエージェントではなくPRDです。

issueをサイクルとラベルに計画する

issueが通ったら、それは計画された作業であって約束された作業ではありません。Atrixではプロジェクト管理がサイクルを計画するまでバックログに保持します。サイクルはゴールとissue数を数えるバーンダウンを持つ1〜4週間で、サイクルが閉じると未完了のissueは次のサイクルかバックログに戻ります。ストーリーポイントはありません。上のサイズのルール（「1人、1サイクル」）が見積もりモデルのすべてで、意図的に粗くしています。

ラベルはワークスペースに属し、色を持ちます。私たちはissueごとにタイプラベル1つと領域ラベル1つを使い、ブリーフでエージェントにもそう指示しています。要件の集合に出荷日があるときは、マイルストーンがサイクルをまたいでissueをまとめます。

要件監査はその後、納品されたものを凍結ベースラインと比較してカバレッジとドリフトを報告します。どの要件に出荷済みissueがあり、どれにないか、どれがissue作成後に変わったか。比較するのは要件と計画であってコードではありません。コードがissueの言うとおりに動くかは、依然としてコードレビューの仕事です。

LinearやJiraでも同じワークフローができます。Linearのプロジェクトとラベル、Jiraのエピックとコンポーネント。それらのツールでは要件への糸は機能ではなく慣習なので、issueのタイトルに要件idを入れ、PRDは版履歴のある場所に置いてください。

よくある質問

AIはPRDからバックログを生成できますか？

はい。PRDに受け入れ基準付きの番号付き要件と非ゴール一覧があれば、分割とラベル付けはうまくやります。分割の合計が合っているかは判断しないので、生成された各issueはバックログに入る前に短い却下リストに照らした人の確認が必要です。

生成されたissueはどう要件に紐づけるべきですか？

各issueが要件idをちょうど1つ名指しし、その要件の受け入れ基準をそのまま写します。PRDは生成前にベースラインとして凍結するので、後の編集は進行中のissueを静かに変えるのではなく新しいベースラインを生みます。

生成issueの大きさはどれくらいにすべきですか？

1人が1サイクル内で終えられる大きさ。要件がそれ以上を必要とするなら分割し、各部分の組み合わせ方を記します。この粗いルールがストーリーポイントの代わりです。Atrixには設計上ポイントがなく、バーンダウンはissue数を数えます。

AI生成のバックログから何を却下すべきですか？

要件idのないissue、複数要件を引用するissue、言い換えやテスト不能な受け入れ基準、明示された非ゴールのissue、終わりを思い描けないほど大きいissue、発明されたラベル。理由を添えて戻します。通常2ラウンドで十分です。

プロダクトバックログとは何ですか？

まだサイクルに予定されていない計画済み作業の順序付きリストです。ロードマップやサイクルとの違いはバックログの用語集の項目を参照してください。

要件監査はコードを確認しますか？

いいえ。納品されたissueを凍結した要件ベースラインと比較し、カバレッジとドリフトを報告します。コードがissueの言うとおりに動くかは、人が行うコードレビューです。

次のステップ

次のPRDでは要件に番号を振り、それぞれに受け入れ基準を付け、エージェントにissueを頼む前に凍結してください。PRDテンプレートはそのために構成されており、AIエージェントのページにはDevelop実行が返すもの、つまり要件、アーキテクチャ、そしてそれぞれが要件を指す計画済みissueが載っています。