# PRD: {機能名 / プロジェクト名} | 項目 | 内容 | |---|---| | ステータス | Draft / In Review / Approved / Released | | 作成者 | {作成者名} (PdM) | | 関係者 | EM: {EM名} / Tech Lead: {TL名} / Designer: {Designer名} / QA: {QA名} | | 最終更新 | {YYYY-MM-DD} | | ターゲットリリース | {YYYY-Qx} | | 関連ドキュメント | Spec: {URL} / Design: {URL} / Tech Design: {URL} | ## 1. 概要 (TL;DR) {3行で。誰の何の課題を、どう解決するか} ## 2. 背景・課題 (Why) {なぜ今この機能を作るのか / どんな課題が観測されたか} - データ：{データソース、数値} - ユーザーの声：{インタビュー / サポート / NPS から} - 戦略上の位置付け：{プロダクト戦略 / OKR との接続} ## 3. ターゲットユーザー - ペルソナ：{ペルソナ名} - ユースケース：{具体的なユースケース1〜3} - 利用シーン：{いつ / どこで / どんな状況で} ## 4. ゴールと成功指標 (Goals & Metrics) ### Goals - {ゴール1（ユーザー視点）} - {ゴール2（ビジネス視点）} ### Non-Goals - {今回やらないこと（明示することでスコープ膨張を防ぐ）} ### Success Metrics - 主要指標：{North Star Metric}（目標値：{目標値}） - ガードレール指標：{下げてはいけない指標} - 計測方法：{計測ツール、ダッシュボード URL} ## 5. 要件 (What) ### 機能要件 - [必須] {要件1} - [必須] {要件2} - [推奨] {要件3} - [将来] {要件4} ### 非機能要件 - パフォーマンス：{要件} - 可用性：{要件} - セキュリティ：{要件} - アクセシビリティ：{要件} ## 6. ユーザーフロー {図 or 箇条書き。ハッピーパスとエラーパスを両方} ## 7. デザイン - ワイヤーフレーム：{URL} - モック：{Figma URL} - 主要画面：{画面1, 画面2, 画面3} ## 8. 検討事項とトレードオフ | 検討事項 | 採用案 | 理由 | 棄却案 | |---|---|---|---| | {テーマ1} | {採用案} | {理由} | {棄却案と理由} | ## 9. リリース計画 - フェーズ1（{時期}）：{内容} - フェーズ2（{時期}）：{内容} - ロールアウト：{社内ドッグフード → ベータ → 全体} - フィーチャーフラグ：{利用 / 不要} ## 10. リスクと未解決事項 - リスク：{リスク1}（緩和策：{緩和策}） - 未解決：{Open Question} ## 11. ステークホルダー承認 - [ ] {役職}: {氏名} - 承認日 {日付} - [ ] {役職}: {氏名} - 承認日 {日付}

件名：【PRD レビュー依頼／{機能名}】コメント期限：{期限} {宛先} 各位 お世話になっております。{プロダクト名}担当 PdM の{自分の名前}です。 {機能名}の PRD ドラフトを作成しました。レビューとコメントをお願いいたします。 【ドキュメント URL】 {PRD URL} 【概要】 {TL;DR を3行で} 【背景】 {なぜこの機能を提案しているか、簡潔に} 【特にレビューしてほしい観点】 ■ EM ({EM名}) 様 ・実現可能性、見積もり感（M / L / XL） ・既存システムへの影響、技術負債のリスク ・推奨する設計アプローチ ■ Tech Lead ({TL名}) 様 ・アーキテクチャ上の懸念 ・スケーラビリティ・パフォーマンスへの影響 ■ Designer ({Designer名}) 様 ・UX フローの妥当性 ・既存デザインシステムとの整合性 ・アクセシビリティ ■ QA ({QA名}) 様 ・テスト容易性 ・エッジケース、リスク領域 ■ 営業 / CS 様 ・お客様の反応予測 ・既存顧客への影響 【ご対応のお願い】 1. {期限}までに、ドキュメントに直接コメントをお願いします 2. 重要な論点は本スレッドでも議論できればと思います 3. {キックオフ日}にキックオフ MTG を予定しています（別途招待） 【意思決定が必要な未解決事項】 ・{Open Question 1} ・{Open Question 2} お忙しいところ恐縮ですが、よろしくお願いいたします。 {自分の名前} (PdM)

件名：【ご相談】{四半期}優先順位の再調整について {宛先（経営 / EM / 営業）} お世話になっております。{プロダクト名}担当 PdM の{自分の名前}です。 {四半期}の開発候補をリストアップしましたが、エンジニアリングリソースに対して候補が多すぎるため、優先順位の再調整をご相談させてください。 【現状】 ・候補プロジェクト総工数：{合計工数} 人月 ・利用可能リソース：{利用可能リソース} 人月 ・ギャップ：{ギャップ} 人月（{ギャップ率}% 過剰） 【優先順位案（RICE / WSJF スコアで評価）】 ■ Must (今四半期に必ず実施) 1. {プロジェクト名} - スコア {スコア} 理由：{理由} 工数：{工数} 2. {プロジェクト名} - スコア {スコア} 理由：{理由} 工数：{工数} ■ Should (リソース許せば実施) 3. {プロジェクト名} - スコア {スコア} 理由：{理由} 工数：{工数} ■ 次四半期送り 4. {プロジェクト名} - スコア {スコア} 理由：{送りの理由} 影響：{影響} 5. {プロジェクト名} - スコア {スコア} 理由：{送りの理由} 【判断のポイント】 ・OKR への寄与度 ・収益インパクト（短期 vs 長期） ・リスクの大きさ ・依存関係（他プロジェクトのブロッカーになっていないか） 【ご相談したいこと】 1. 上記の Must / Should の振り分けに同意いただけるか 2. 「次四半期送り」となる項目に強い反対があるか 3. リソース追加の可能性があるか 【意思決定希望日】 {意思決定希望日}（着手準備のため） 下記日程で 30分のオンライン MTG を設定したく存じます。ご都合の良い時間をお知らせください。 ・{候補日時1} ・{候補日時2} ・{候補日時3} よろしくお願いいたします。 {自分の名前} (PdM)

## US-{番号}: {ストーリータイトル} ### Story **As a** {ユーザー（ロール）} **I want** {やりたいこと（手段）} **So that** {達成したい価値（目的）} ### Acceptance Criteria（受け入れ基準） #### Scenario 1: {シナリオ名} **Given** {前提条件} **When** {行動} **Then** {期待結果} #### Scenario 2: {シナリオ名（エラーケース）} **Given** {前提条件} **When** {不正な行動} **Then** {エラー処理結果} ### Definition of Done - [ ] 単体テストが書かれており、通っている - [ ] 受け入れ基準を満たすテストが通っている - [ ] PR がレビュー・マージされている - [ ] ドキュメント・ヘルプが更新されている - [ ] 機能フラグの初期設定が完了している - [ ] 監視・ログが追加されている - [ ] アクセシビリティチェックを通過 - [ ] PdM の確認が完了している ### Notes - 工数見積もり：{ストーリーポイント または時間} - 担当：{担当者} - 関連 Issue：{Issue #} - 依存関係：{依存している他のストーリー} - リスク：{懸念点} ### Out of Scope (今回やらないこと) - {やらないこと1} - {やらないこと2}

件名：【スコープ合意】{機能名} MVP リリース版の確定について {宛先} お世話になっております。PdM の{自分の名前}です。 {機能名}について、検討の結果、まずは最小限の機能でリリース（MVP）し、ユーザー反応を見ながら段階的に拡張する方針を提案します。 【背景】 {背景：当初フルスペックで検討していたが、〇〇な事情で MVP 化が必要} 【MVP の判断基準】 ・「これがないとそもそも価値検証できない」機能のみを Phase 1 に入れる ・「あったら良い」は全て Phase 2 以降に送る ・MVP リリース後 {期間}以内に必要な拡張ができる設計にする 【スコープ案】 ■ Phase 1: MVP（{リリース予定日}） - {機能1}（必須）：{なぜ必須か} - {機能2}（必須）：{なぜ必須か} - {機能3}（必須）：{なぜ必須か} 工数：{工数} ■ Phase 2: フォロー（{予定}） - {機能4}：MVP の利用状況を見て決定 - {機能5}：ユーザーの声を反映 ■ Phase 3: 拡張（{予定}） - {機能6}：本格展開 【MVP の成功条件】 ・{指標1}：{目標値} ・{指標2}：{目標値} → 達成 → Phase 2 着手 / 未達 → 振り返り後に方針再検討 【意図的に外したもの・理由】 | 機能 | 外した理由 | |---|---| | {機能} | {理由} | | {機能} | {理由} | 【リスクと緩和策】 ・リスク：MVP では機能不足と感じるユーザーがいる 緩和：「ベータ」表記、ロードマップ公開、要望受付窓口設置 【ご相談したいこと】 1. Phase 1 のスコープでお客様への提供価値が成立するか 2. Phase 2 / 3 のタイムラインに齟齬がないか 3. 営業・CS の期待値コントロール方針 意思決定期日：{期日} コメント・反対意見はドキュメント（{URL}）または本メールへの返信でお願いします。 よろしくお願いいたします。 {自分の名前} (PdM)

件名：【PRD 承認・キックオフ】{機能名} 開発開始のお知らせ 関係者各位 お世話になっております。PdM の{自分の名前}です。 {機能名}の PRD が下記の通り承認されましたので、開発を開始いたします。 【PRD】 {PRD URL}（v{バージョン}・{承認日}承認） 【承認者】 ・{役職1}: {承認者1} ✓ {承認日} ・{役職2}: {承認者2} ✓ {承認日} ・{役職3}: {承認者3} ✓ {承認日} 【プロジェクト概要】 ・名称：{プロジェクト名} ・目的：{目的} ・成功指標：{指標}（目標：{目標値}） 【体制】 ・PdM：{PdM名}（全体責任） ・EM：{EM名}（実装責任） ・Tech Lead：{TL名} ・エンジニア：{エンジニア名} ・Designer：{Designer名} ・QA：{QA名} 【主要マイルストーン】 | フェーズ | 期日 | 成果物 | |---|---|---| | キックオフ MTG | {日付} | チームアラインメント | | 設計レビュー | {日付} | 技術設計書 / デザイン | | 開発開始 | {日付} | - | | 社内ベータ | {日付} | ドッグフード開始 | | 限定リリース | {日付} | 一部ユーザーへ提供 | | 全体リリース | {日付} | 全ユーザーへ展開 | 【コミュニケーションチャンネル】 ・Slack：{チャンネル名} ・進捗共有：{ツール}（毎週{曜日}更新） ・週次定例：毎週{曜日} {時間} 【キックオフ MTG】 ・日時：{日時} ・場所：{場所 / オンライン URL} ・アジェンダ：PRD 共有、体制・スケジュール確認、リスク・懸念点共有、次のアクション 気になる点や懸念点があれば、いつでも{Slack チャンネル}でお気軽にどうぞ。 よろしくお願いいたします。 {自分の名前} (PdM)