prd-template

PRD テンプレートスキル

このスキルは、業界のベストプラクティスに沿った、プロフェッショナルな製品要件定義書（PRD）の作成を支援します。

配置場所 — 意思決定プロセスの中間

製品の意思決定プロセスの2番目です。/assumption-mapper → prd-template → /rice-prioritisation → /roadmap-narrative。/assumption-mapper が実行されている場合は、そこから最もリスクの高い仮説を受け取ります（リスクを再推測するのではなく、そのマップを参照してください）。 そして、PRDの成功指標を/rice-prioritisationに引き渡します。これは、RICEのImpactとなる、ベースラインを設定した唯一の数値です。共通用語（問題の定義、仮説、成功指標、出所）は docs/craft/product-decisions.mdに一元化されています。用語は そのまま使用してください。

プロセス

PRDは常に問題から解決策へと、外側から内側に向かって4つのフェーズで作成します。フェーズ1は基盤となるものです。問題が曖昧なまま作成されたPRDは、最後まで磨き上げても間違ったものになります。

1. 問題の定義を確定する。 誰が、いつ、どのような問題を抱えていて、それを放置するとどんな損失が生じるのかを1文で記述します。解決策については書きません。以降のすべての内容は、この定義に結びつけます。 完了条件： 問題の定義に機能名が含まれておらず、それだけで成立していること。また、初めて読む人が「解決」の意味を理解できること。
2. 成功指標のベースラインを設定する。 問題が解決したことを証明する唯一の数値を、現在のベースラインと成功とみなす変化とともに記載します。上流の/assumption-mapperから引き継いだリスクがあれば、暗黙の賭けにするのではなく、未解決の質問として記載します。 完了条件： 指標にベースラインがある（または、ベースライン未設定と明記されている）こと。また、活動ではなく問題を測定していること。
3. 各セクションを、問題とのつながりを保ちながら作成する。 以下のテンプレートを埋め、すべての要件とユーザーストーリーが問題の定義に結びつくようにします。結びつかないものは削除してください。事実には出所を付記します。推測した数値には[hunch]と明記します。 完了条件： すべての要件が問題の定義に結びつき、主張するすべての事実に[データ]／[推測]／[仮説]のいずれかが付記されていること。
4. 引き継ぐ。 成功指標と取り組みを提示し、/rice-prioritisationが別の指標を作り直すのではなく、この指標からImpactを評価できるようにします。 完了条件： PRDに指標とスコープが記載されており、/rice-prioritisationが再確認せずに評価できること。

必要な入力

与えられた情報に基づいて作業します。以下の情報が不足している場合も、完全な出力を作成してください。不足箇所は妥当な仮定で補い、*(仮定、要確認)*と記し、最後にそれらの仮定を列挙します。中核となるテーマ自体が不明な場合（書く内容が何もない場合）に限り、先に質問してください。

• 機能または製品名
• 解決する問題（ユーザーの視点）
• 対象ユーザー（役割、状況、達成しようとしていること）
• 成功指標（成功したかどうかをどう判断するか）
• スコープ（MVPと最終的な構想、対象に含めるものと含めないもの）
• 主要なステークホルダー（レビューと承認が必要な人）

Brainからの読み込み／Brainへの書き込み

professional-brain（brain/）が存在する場合は、すでに把握している背景情報を再度尋ねず、そちらを使用してください。

• まず読み込む： context.md（製品、指標の定義、文体）、knowledge/strategy.md （製品の方向性）、関連するhypotheses/と、該当する機能のentities/ファイル。python3 ../professional-brain/scripts/brain_query.py ./brain "<feature>"を実行して 根拠のある事実を取得し、その出所タグをPRDに引き継ぎます（[hunch]を確定した要件として提示しないでください）。
• 作成後に書き込む： 機能をentities/<feature>.mdとして、またはそのファイルに保存し、スコープ決定をdecisions/に記録して、新たな仮定をhypotheses/に追加します。それぞれに出所を付記してください。

詳細資料

このスキルには、補足ファイルが2つ含まれています。利用可能な場合は活用してください。

• templates/prd-skeleton.md — 各セクションに「良い状態の例」のヒントが付いた、記入式のPRDスケルトンです。ユーザーが生成されたドラフトではなく、自分で仕上げる文書を求めている場合は、これをベースにしてください。
• references/success-metrics-guide.md — 成功指標セクションの調整に役立つガイドです。4つの観点から指標を検証する方法、標準的な導入・成果・ビジネス・ガードレールの指標セット、よくある落とし穴が記載されています。指標の表を作成またはレビューする際は、必ず参照してください。

テンプレートの構成

すべてのPRDに、次のセクションを順番どおりに含めてください。

1. 概要

• 問題提起：どのような問題を解決するのか（2～3文）
• 提案するソリューション：何を構築するのか、その概要（2～3文）
• 成功指標：成功をどのように測定するのか（主要指標を3～5個）

2. コンテキストと背景

• 今取り組む理由：なぜ今が適切なタイミングなのか
• 戦略との整合性：会社の目標とどのように整合するのか
• ユーザー調査の概要：調査から得られた主な知見（該当する場合）

3. ユーザーストーリーとユースケース

形式：「[ユーザータイプ]として、[メリット]を得るために、[アクション]したい」

• 主要なユーザーストーリーを3～7件含める
• それぞれに受け入れ基準を追加する

4. 要件

機能要件：

• 必須機能（P0）
• あると望ましい機能（P1）
• あると便利な機能（P2）

非機能要件：

• パフォーマンスに関する期待事項
• セキュリティ上の考慮事項
• アクセシビリティ要件

5. デザインとユーザーエクスペリエンス

• デザインモックやワイヤーフレームへのリンク
• 主要なユーザーフロー
• エッジケースとエラー状態

6. 技術的な考慮事項

• アーキテクチャへの影響
• 他システムへの依存関係
• 技術的リスクと軽減策

7. 実装計画

• フェーズ1（MVP）：初回バージョンに含める内容
• フェーズ2：次に対応する内容
• フェーズ3：今後の機能強化

8. 未解決の質問

• まだ決定が必要な事項
• 相談すべき関係者
• 必要な調査

9. 付録

• 調査へのリンク
• 関連文書
• 競合分析

出力の最後には、必ず簡潔な前提と不足情報のブロックを付けてください。入力に記載がなかったために置いた前提と、出力内容を最も大きく左右する不足情報を、2～4個の箇条書きで挙げます。前提も不足情報もない場合は、その旨を1行で記載してください。

執筆ガイドライン

トーン：明確で、簡潔かつ実行可能 対象読者：エンジニア、デザイナー、関係者 分量：機能の場合は3～6ページ、プロダクトの場合は8～12ページを目安にします

ベストプラクティス：

• 抽象的な説明より、具体例を使う
• 「何を」だけでなく「なぜ」も記載する
• 要件をテスト可能な形にする
• 補足資料へのリンクを記載する
• 決定事項が増えたら更新する

優れたPRDの条件

✅ 実践すること：

• ユーザーの視点で書く
• 具体的な成功指標を含める
• エッジケースに対処する
• 調査やデータへのリンクを記載する
• トレードオフを明確にする

❌ 避けること：

• 実装の詳細を書く（それは技術仕様書の内容です）
• 読者が全員、背景を知っていると想定する
• 要件を曖昧なままにする
• 「なぜ」を省く
• アクセシビリティを忘れる

スコアリング基準（0–40）

このスキルの出力は、引き渡す前に採点してください。32 点以上であれば、リリース品質です。

評価項目	0	5	10
課題の根拠	会社の視点で課題が書かれている、または根拠なしに断定されている	ユーザーの視点で課題が書かれているが、裏付けとなるデータが曖昧（「ユーザーは不満を感じている」など）で、調査も引用されていない	ユーザーの課題が、現状を示す定量データとともに記載され、「なぜ今なのか」では何が変化したのかが説明されており、主張には引用した調査が紐付いている
要件の検証可能性	要件が曖昧な品質（「高速」「直感的」など）で、レビュー担当者が検証できない	ほとんどの要件は具体的だが、受け入れ基準が不十分で、非機能要件が定型文になっている	すべての P0/P1/P2 項目と NFR が検証可能（しきい値、パーセンタイル、標準など）で、それぞれがユーザーストーリーまたは調査結果に紐付いている
指標の厳密さ	成功指標がない、またはベースラインのない割合だけが示されている	ベースラインと目標はあるが、指標は導入状況しか測定しておらず、ビジネスに悪影響を与えながら機能が成功している場合にそれを検知できない	すべての指標にベースライン → 目標があり、指標全体で成果と導入状況の両方を評価でき、指標の向上がユーザーに害を及ぼすことを防ぐガードレールが少なくとも 1 つある
スコープとリスクの誠実さ	MVP と将来のフェーズの区別が曖昧で、未解決の質問も挙げられていない	フェーズは分けられているが、範囲を分けた理由がなく、意見の相違も表面化していない	各フェーズの境界には理由が明記され、スコープ外の要望は再検討の条件とともに記録され、未解決の質問には担当者、期限、各回答に伴うコストが記載されている

品質チェック

• 課題の記述がユーザーの視点で書かれている（会社の視点ではない）
• 成功指標が具体的で測定可能である
• ユーザーストーリーに受け入れ基準が含まれている
• 要件が検証可能である（曖昧ではない）
• 未解決の質問が明示されている
• 実装計画で MVP と将来のフェーズが区別されている

アンチパターン

• 会社の視点で要件を書かないでください。すべての要件はユーザーのニーズに紐付ける必要があります
• 「システムは高速であるべき」のような曖昧な要件を含めないでください。すべての要件は検証可能である必要があります
• MVP と将来のフェーズを混同しないでください。初回リリースのスコープに含まれるものと含まれないものを明確にしてください
• 成功指標を、ベースラインのない割合だけで済ませないでください。現状と目標を明記してください
• 未解決の質問を省略しないでください。未解決の前提はリスクです。それを明らかにするのが PM の役割です

PRD の冒頭例

# PRD: Multi-Channel Customer Support Dashboard

## Overview

**Problem Statement**: Support teams are currently managing customer inquiries across email, chat, and social media using three separate tools, leading to delayed responses, duplicated work, and inconsistent customer experiences. On average, support agents waste 2.3 hours per day switching between tools and manually tracking conversation history.

**Proposed Solution**: Build a unified dashboard that aggregates customer inquiries from all channels into a single interface, maintains conversation history across channels, and provides intelligent routing based on agent expertise and availability.

**Success Metrics**:
- Reduce average response time from 4 hours to 1 hour
- Decrease tool-switching time by 80% (from 2.3 to <0.5 hours)
- Improve customer satisfaction score from 3.8 to 4.5 (out of 5)
- Increase support agent productivity by 35%

## Context & Background

**Why Now**: Customer satisfaction has declined 15% over the past 6 months, primarily due to slow response times. Our top competitor launched a unified support dashboard last quarter, and we're hearing about it in sales calls. Support team turnover is at 45% annually, with "tool complexity" cited as a top frustration.

**Strategic Alignment**: This aligns with our Q1 company objective to "Improve customer retention by 10%" and our support team's OKR to "Reduce average handle time by 25%."

**User Research Summary**: We conducted interviews with 12 support agents and observed 20 hours of support sessions. Key findings:
- Agents spend 35% of their time finding context from previous interactions
- 65% of escalations are due to lack of conversation history
- Agents rated tool-switching as their #1 daily frustration (9.2/10 pain)
- Current NPS for support experience is -12

## User Stories & Use Cases

**US1: Unified Inbox**
As a support agent, I want to see all customer inquiries in one place so that I don't miss urgent requests and can prioritize effectively.

Acceptance Criteria:
- Inbox shows inquiries from email, chat, and social media
- Inquiries are sorted by priority (urgent, high, normal, low)
- Agent can filter by channel, customer, or status
- Real-time updates when new inquiries arrive

**US2: Cross-Channel Context**
As a support agent, I want to see the full conversation history regardless of channel so that I can provide consistent, informed responses without asking customers to repeat themselves.

Acceptance Criteria:
- Timeline view shows all interactions chronologically
- Each interaction displays channel, timestamp, and content
- Customer profile shows demographics and account information
- Previous issues and resolutions are accessible

[Continue with 5-7 total user stories...]

トリガーフレーズの例

• 「PRD を作成してください。」
• 「この機能の製品仕様書を作成してください。」
• 「機能仕様書を作成してください。」
• 「新機能の要件定義書を作成してください。」