D1: プロダクト要求仕様書 (PRD)

inputする成果物

成果物のパス	内容
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(更新・レビュー時のみ参照。新規作成時は未存在)

outputする成果物

成果物のパス	内容
docs/D1.business-requirements/product-requirement-document.md	プロダクト要求仕様書本体

使用するテンプレート

出力時は以下のテンプレートを読み込み、その章構成・書き方ヒントに従う。

テンプレートのパス	内容
.claude/skills/d1-product-requirement-document/template.md	PRDテンプレート(章構成・書き方ヒント)

章構成

本書は 6 章構成。具体的な横断要求はドメイン共通要求仕様書に降ろし、本書は ID を持たない方針宣言・概念整理・制約・受け入れ基準のみを扱う。

• §本書について(概要 / 想定読者 / 注記)
• §プロダクト概要(BRD「事業戦略とプロダクト概要」をプロダクト視点で言い換え)
• §体験設計(提供価値・体験方針 / システム利用ユーザーと体験設計)
• §ドメイン共通要求への分割方針(ドメイン共通要求仕様書 へのポインタ)
• §制約事項(BRD制約のPRD段階での影響を整理)
• §受け入れ基準(プロダクト全体としてのローンチ可否判断基準)

新規作成時の振る舞い

新規作成時(docs/D1.business-requirements/product-requirement-document.md 未存在)は ユーザーへのヒアリングを行わず、上流3成果物(BRD・アクター一覧・ドメイン定義書)と業界一般知識から PRD を直接生成する。

1. 上流3成果物を読み込み、本書の各章にどの成果物の何を引き取るかを整理する
2. テンプレートの章順に従って書き出す。各章の主な引き取り元と注意点は以下:
   • 本書について: 概要 / 想定読者 / 注記 の3つのサブ見出しに分割。概要では「PRD は方針」「具体的な横断要求はドメイン共通要求仕様書に集約」「PRD(方針)・ドメイン共通要求仕様書(横断要求)・ドメイン要求仕様書群(個別要求)との上下流関係」を明示する
   • プロダクト概要: BRD「事業戦略とプロダクト概要」をプロダクト視点で言い換え(業務フローではなく「何を提供するか」)。将来拡張(チャネル拡張・新商品・機械学習活用 等)は [フェーズ2] ラベルで明示。本システムが内製スコープから外す領域(既存内部システム・外部サービス)も簡潔に列挙
   • 体験設計 > 提供価値・体験方針: BRD「事業戦略」「KPI」「マーケティング戦略」「将来拡張性」から直接派生する設計原則。3〜6柱に絞る。利用ユーザーへの絞り込みは次節に委ね、本節では行わない
   • 体験設計 > システム利用ユーザーと体験設計: アクター一覧から直接利用アクターのみを抽出したフィルタビュー。アクター一覧の役割・責務・関心事を本節で重複記載せず、PRD レベルで体験設計に効く観点(配慮点・利用形態)に絞る。配下に「システム利用ユーザーと体験設計上の配慮点」表と「利用形態」表を配置
   • ドメイン共通要求への分割方針: ドメイン共通要求仕様書 へのポインタとして、ドメイン共通要求仕様書 と 各ドメイン要求仕様書(個別)への振り分けを宣言。横断要求の各カテゴリ(機能/非機能/UI/UX/セキュリティ/法務)と ID 体系(DOM-COMMON-*)を表形式で示し、各ドメイン要求仕様書(個別)がこれを継承する旨を明示。外部システム連携の非機能水準・データ取扱は §非機能要求(互換性・信頼性)/ §データアクセス要求 に内包され、独立カテゴリは持たないことに留意
   • 制約事項: BRDのスケジュール・予算・人事・連携先システム制約 のうちPRD段階で意識すべきものを抜粋
   • 受け入れ基準: BRDの「プロジェクトの成功の定義」とKPIから派生。プロダクト全体としてのローンチ可否判断基準(法令遵守・セキュリティ・業務継続性・並行運用・コンプライアンス監査対応 等)を箇条書きで示す
3. 上流から確定できない値には要確認マーカーを付ける
4. 本書は要求 ID を持たない。具体的な要求(DOM-COMMON-FR-1 等)はすべてドメイン共通要求仕様書 で採番する。本書は ID を引用するのみ(DOM-COMMON-NFR-* 等)
5. ユーザー識別子は別途PRDで作らず、アクター一覧の対応アクターID(ACT-1, ACT-2, ...)をそのまま用いる(二重識別子を避ける)。複数アクターをまとめる場合は中黒区切り(例: ACT-5・ACT-6)
6. §「体験設計 > システム利用ユーザーと体験設計」配下の表は アクター名を先頭、アクターIDを2列目 に並べる(ユーザー名が読み手の関心事、IDは追跡用の補助)。配慮点列は <br> + ・ の改行記法で箇条化して視認性を上げる

留意事項

• 要求 ID を持たない: 具体的な要求事項(機能/非機能/UI/UX/セキュリティ/法務)はドメイン共通要求仕様書 と 各ドメイン要求仕様書 に降ろす。本書は方針宣言・概念整理・制約・受け入れ基準のみを扱い、要求 ID を持たない
• ドメイン共通要求への分割方針 は薄い節: 当該節は「ドメイン共通要求仕様書へのポインタ」「カテゴリ一覧+ID 体系の表」のみを書く。具体的な要求は書かない(=ドメイン共通要求仕様書 へのポインタとして機能する)
• 下流成果物との棲み分け: 以下は本書に書かず、各下流成果物に降ろす
  • 横断機能要求・非機能要求・UI/UX 方針・セキュリティ要求・法務要求 → ドメイン共通要求仕様書
  • 個別ドメインの業務ルール・業務状態遷移・業務運用(イレギュラー対応) → ドメイン要求仕様書群(個別)
  • ユーザーストーリー(誰が何のために) → ユーザーストーリー一覧
  • 画面の具体仕様 → 画面要件群(D2)
• 業務 + プロダクト観点に留まる: 機能名・画面名・テーブル名・API 名等のシステム実装語は混入させない
• 継承関係の見える化: PRD・ドメイン共通要求仕様書・ドメイン要求仕様書群 の継承関係を本書から明示し、下流成果物が ID で辿れる状態を作る
• アクター一覧との関係(フィルタビュー): 本書の「システム利用ユーザーと体験設計」節は、アクター一覧で網羅された全アクター(直接利用・業務関係者・統制/監督)のうち 本プロダクトを直接利用するアクターのみを抽出したフィルタビュー であり、役割・責務・関心事はアクター一覧を正典とする。本節は PRD 固有レンズ(配慮点・利用形態)のみを書き、アクター一覧の情報を重複記載しない
• 章順の規律(BRD → 何を → 誰に): §「体験設計」は「提供価値・体験方針 → システム利用ユーザーと体験設計」の順序を守る。提供価値は BRD から直接派生する設計原則であり、利用ユーザーは「その価値を届ける対象の絞り込み」として後続するため、逆順にしない
• フェーズ2 ラベルの付与: 初期フェーズの対象外で将来追加される要件(チャネル拡張・新商品・機械学習活用・将来連携 等)は [フェーズ2] ラベル(または「フェーズ2以降」記号)で明示し、初期/将来の境界を読み手に分からせる。BRD の同種ラベルと表記を揃える
• 上流との整合性: BRDのスコープ・KPI・制約・フェーズ2 / アクター一覧の対象ユーザー / ドメイン定義書のドメイン構成 と矛盾させない

完成時のセルフチェック

執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。

• 本書に具体的要求(FR/NFR/UX/SEC/REG 等)が本書に直接置かれていないか(それらはドメイン共通要求仕様書 に降ろされているか)
• §ドメイン共通要求への分割方針 が ドメイン共通要求仕様書へのポインタに留まり、具体要求を抱え込んでいないか
• 個別ドメインの業務ルール・業務状態遷移・業務運用(イレギュラー対応)が混入していないか
• ユーザーストーリー・ユースケース・機能の網羅リスト・画面の具体仕様が混入していないか
• BRDのスコープ・KPI・制約と整合しているか(フェーズ2の境界も含む)
• §「体験設計 > システム利用ユーザーと体験設計」がアクター一覧のフィルタビューとして機能し、役割・責務・関心事の重複記載がないか
• §「体験設計」配下の章順が「提供価値・体験方針 → システム利用ユーザーと体験設計」になっているか(BRD → 何を → 誰に の派生順)
• §「体験設計 > システム利用ユーザーと体験設計」配下の表で アクター名を先頭、対応アクターID(ACT-n) を2列目 に置き、PRD 独自の USR1 等の二重識別子が混入していないか
• 配慮点セルが <br> + ・ の改行記法で箇条化されており、視認性が確保されているか
• 機能名・画面名・テーブル名・API 名等のシステム実装語が混入していないか
• 将来要件・将来拡張に該当する箇所に [フェーズ2] ラベル(または同等表記)が付与されているか
• {{ や XXX のプレースホルダが残っていないか

下流への伝搬関係

作成・更新時は以下の下流成果物との整合を意識する:

下流成果物	PRDから何を引く
ドメイン共通要求仕様書	§「ドメイン共通要求への分割方針」/ §「プロダクト概要」/ §「体験設計」 を起点に、横断要求を具体化
ドメイン要求仕様書群(個別)	§「体験設計」/ §「ドメイン共通要求への分割方針」 を方針として参照(具体要求は ドメイン共通要求 を継承)
ユーザーストーリー一覧	§「体験設計 > システム利用ユーザーと体験設計」/ §「体験設計 > 提供価値・体験方針」
ユースケース一覧	§「体験設計 > システム利用ユーザーと体験設計」/ §「体験設計 > 提供価値・体験方針」(ユーザーストーリー一覧からさらに派生)
画面コンセプト集	§「体験設計 > 提供価値・体験方針」(体験コンセプトの源泉)
画面要件群(D2)	§「体験設計 > 利用形態」 + 各ドメイン要求仕様書 + 機能一覧