プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。
具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
| 成果物のパス | 内容 |
|---|---|
docs/D1.business-requirements/business-requirement-document.md | 上流のBRD(スコープ・KPI・予算/期間制約・コンプライアンス制約・フェーズ2要件 等を参照) |
docs/D1.business-requirements/actor-list.md | 上流のアクター一覧(直接利用アクターの抜粋元・対応アクターIDの引用元) |
docs/D1.business-requirements/domain-definition-document.md | 上流のドメイン定義書(ドメイン構成と分割方針の起点) |
docs/D1.business-requirements/product-requirement-document.md | 既存PRD(更新・レビュー時のみ参照。新規作成時は未存在) |
| 成果物のパス | 内容 |
|---|---|
docs/D1.business-requirements/product-requirement-document.md | プロダクト要求仕様書本体 |
出力時は以下のテンプレートを読み込み、その章構成・書き方ヒントに従う。
| テンプレートのパス | 内容 |
|---|---|
.claude/skills/d1-product-requirement-document/template.md | PRDテンプレート(章構成・書き方ヒント) |
本書は 6 章構成。具体的な横断要求はドメイン共通要求仕様書に降ろし、本書は ID を持たない方針宣言・概念整理・制約・受け入れ基準のみを扱う。
新規作成時(docs/D1.business-requirements/product-requirement-document.md 未存在)は ユーザーへのヒアリングを行わず、上流3成果物(BRD・アクター一覧・ドメイン定義書)と業界一般知識から PRD を直接生成する。
[フェーズ2] ラベルで明示。本システムが内製スコープから外す領域(既存内部システム・外部サービス)も簡潔に列挙DOM-COMMON-*)を表形式で示し、各ドメイン要求仕様書(個別)がこれを継承する旨を明示。外部システム連携の非機能水準・データ取扱は §非機能要求(互換性・信頼性)/ §データアクセス要求 に内包され、独立カテゴリは持たないことに留意DOM-COMMON-FR-1 等)はすべてドメイン共通要求仕様書 で採番する。本書は ID を引用するのみ(DOM-COMMON-NFR-* 等)ACT-1, ACT-2, ...)をそのまま用いる(二重識別子を避ける)。複数アクターをまとめる場合は中黒区切り(例: ACT-5・ACT-6)<br> + ・ の改行記法で箇条化して視認性を上げる[フェーズ2] ラベル(または「フェーズ2以降」記号)で明示し、初期/将来の境界を読み手に分からせる。BRD の同種ラベルと表記を揃える執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。
ACT-n) を2列目 に置き、PRD 独自の USR1 等の二重識別子が混入していないか<br> + ・ の改行記法で箇条化されており、視認性が確保されているか[フェーズ2] ラベル(または同等表記)が付与されているか{{ や XXX のプレースホルダが残っていないか作成・更新時は以下の下流成果物との整合を意識する:
| 下流成果物 | PRDから何を引く |
|---|---|
| ドメイン共通要求仕様書 | §「ドメイン共通要求への分割方針」/ §「プロダクト概要」/ §「体験設計」 を起点に、横断要求を具体化 |
| ドメイン要求仕様書群(個別) | §「体験設計」/ §「ドメイン共通要求への分割方針」 を方針として参照(具体要求は ドメイン共通要求 を継承) |
| ユーザーストーリー一覧 | §「体験設計 > システム利用ユーザーと体験設計」/ §「体験設計 > 提供価値・体験方針」 |
| ユースケース一覧 | §「体験設計 > システム利用ユーザーと体験設計」/ §「体験設計 > 提供価値・体験方針」(ユーザーストーリー一覧からさらに派生) |
| 画面コンセプト集 | §「体験設計 > 提供価値・体験方針」(体験コンセプトの源泉) |
| 画面要件群(D2) | §「体験設計 > 利用形態」 + 各ドメイン要求仕様書 + 機能一覧 |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。
ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。
ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。
ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。
ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。
画面コンセプト集の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト全体の画面体験コンセプト(体験方向性・体験原則・トーン&マナー方針)と、それを体現する代表シーン2-3を、ビジネスサイドが議論・合意できるサイズに整理する文書。業界を問わず利用可能(業務アプリ・ゲーム・コンシューマー向けサービス・SaaS 等)。プロダクト要求仕様書(PRD)・アクター一覧・ユーザーストーリー一覧を上流とし、下流のワイヤーフレーム・画面遷移図・画面要件群(D2)の判断基準となる画面体験の方向性を定める。全画面の網羅は D2 画面要件群に降ろし、本書はコンセプトと代表シーンに集約する。PRD・ユーザーストーリー一覧の策定後、D2 画面要件群の作成前、もしくはデザイン会社への発注前に呼び出す。