🎬 シナリオ
MOps（Marketing Ops/販促システム）チームに、CS（カスタマーサポート）部門長から「在庫切れ商品の再入荷通知」に関する要望が届いた。CSのヒアリングによると、在庫切れ商品ページからの問い合わせが月間280件前後あり、その9割が「いつ再入荷しますか」「再入荷したら教えてほしい」という内容。CS担当者が個別にメールで案内しているが、対応工数が月20時間相当かかっており、繁忙期（セール前後）には対応が追いつかず未回答のまま埋もれる問い合わせも出ている。
あわせて分析チームからは、在庫切れ商品ページの直帰率が通常商品ページの約2.3倍という数値が共有されている。「再入荷したら通知が来る」導線があれば、その場での離脱を防ぎ再訪問のきっかけにできるのではという仮説もある。
プロダクトオーナーから「まずPRDを書いて、エンジニアリードとデザイナーに共有できる状態にしてほしい。来週のプランニングMTGで内容をレビューする」と依頼された。あなたはこの機能の企画担当としてPRDの起草を任されている。
確認できている制約:
- 通知チャネルはメールのみ（PUSH/LINE通知は別チームが管掌するため今回は対象外）
- 開発体制はエンジニア1名（あなた）、デザイナー0.5名、8週間以内でのリリースを想定
- 在庫管理システム（既存の社内システム）は在庫数が0→1以上に変化したタイミングでイベントを発行できる仕組みがすでにある
📝 課題
あなたのタスク: 上記の状況をもとに、「在庫切れ商品の再入荷通知機能」のPRDを作成してください。背景/課題/ゴール/非ゴール/要件/成功指標/オープンな論点の7セクションを必ず含めること。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 「背景」と「課題」は混同しやすいが、背景は状況説明（何が起きているか）、課題は解決すべき問題（なぜそれが問題か）を分けて書くと後で要件との対応が追いやすい
- ゴールは可能な限り測定可能な形で書く（「使いやすくする」ではなく「〇〇を〇%改善する」）
- 非ゴール（Non-Goals）は「今回はやらないこと」を明記するセクション。ここを飛ばすとスコープクリープの温床になる。今回はPUSH/LINE非対応・多言語非対応など、シナリオ中の制約から拾えるものがある
- 要件は「機能要件」と「非機能要件」を分けて書くと、エンジニアリードがレビューしやすい
- 成功指標は「何を持って成功と判断するか」を事前に決める。CSの問い合わせ数・直帰率など、シナリオ中に出てきた数値を使えないか考える
- オープンな論点は「まだ決まっていないが、レビューで議論したいこと」。すべてを自分だけで決め切ろうとしない
📚 背景知識・用語解説
PRD（Product Requirements Document、プロダクト要求仕様書）とは、「何を」「なぜ」作るのかをチーム全員が同じ理解で進められるようにするための文書です。エンジニアやデザイナーが実装方針（How）を検討する前提として、PdM（またはPdM役）が「何を解決したいか（Why/What）」を明文化する役割を持ちます。
ゴール（Goal）と非ゴール（Non-Goals）: ゴールはこのプロジェクトが達成すべきことを指します。非ゴールは、意図的に今回のスコープに含めないことを明記するセクションです。非ゴールを書かないと、後から「なぜPUSH通知に対応しないのか」といった問い合わせが都度発生し、スコープクリープ（当初の想定を超えて要求がなし崩し的に拡大すること）の温床になります。
成功指標（Success Metrics）: PRDを書く段階で「リリース後、何をもって成功と判断するか」を事前に決めておく指標です。事前に決めずにリリースすると、後から都合の良い指標だけを拾って「成功」と結論づけてしまうリスクがあります。
要件（Requirements）の機能要件・非機能要件: 機能要件は「システムが何をするか」（例: 再入荷時に通知メールを送る）、非機能要件は「どのくらいの品質・性能で動くべきか」（例: 在庫イベント発行から通知メール送信まで◯分以内）を指します。
✅ 模範解答
背景
- 在庫切れ商品ページに関するCSへの問い合わせが月間約280件発生しており、その約9割（約250件）が「再入荷時期を知りたい」「再入荷したら知らせてほしい」という内容
- 現状はCS担当者が個別にメールで案内しており、対応工数は月20時間相当。セール前後の繁忙期には対応が追いつかず、未回答のまま埋もれる問い合わせが発生している
- 分析チームの計測によると、在庫切れ商品ページの直帰率は通常商品ページの約2.3倍。ページを離脱したユーザーの再訪問を促す導線が現状存在しない
課題
- CSの対応工数が構造的に線形増加しており、会員数・取扱商品数が増えるほど問い合わせ対応が破綻に近づいている（属人的な個別対応がスケールしない）
- 在庫切れというユーザーの離脱理由が明確に特定できているにもかかわらず、再訪問を促す仕組みがなく、機会損失（再入荷後の売上取りこぼし）が発生している可能性が高い
- 上記2つの課題は、CSの負荷軽減と売上機会の回復という異なる部門のKPIに同時に効く可能性があるため、優先度高く着手する価値がある
ゴール
- 在庫切れ商品ページに「再入荷通知を受け取る」導線を設け、会員がメールアドレス登録だけで再入荷通知を受け取れるようにする
- リリース後3ヶ月で、在庫切れ商品に関するCS問い合わせ件数を月280件から月140件以下（50%削減）にする
- 再入荷通知経由での商品ページ再訪問率・購入転換率を計測できる状態を作る（初期リリース時点では具体的な目標値は設定せず、計測基盤を先に整える）
非ゴール（今回やらないこと）
- PUSH通知・LINE通知への対応（別チームが管掌するチャネルであり、本リリースの範囲外。将来的な拡張候補としてオープンな論点に記載）
- 非会員（メールアドレス未登録ユーザー）への通知登録機能（今回は会員登録済みユーザーの保有メールアドレス宛のみを対象とする）
- 入荷予定日の事前予測・表示（在庫管理システムには入荷予定日データが存在しないため、今回は「入荷したタイミングでの通知」のみを扱う）
- 多言語対応（現状の対象ユーザーは日本語話者が中心のため、日本語メールのみで開始する）
要件
機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| F1 | 通知登録ボタンの表示 | 在庫切れ商品ページに「再入荷したら通知を受け取る」ボタンを表示する |
| F2 | 通知登録処理 | ボタン押下でログイン中会員のメールアドレスを紐付けて通知希望リストに登録する。未ログインの場合はログイン画面に誘導する |
| F3 | 重複登録の防止 | 同一会員・同一商品の組み合わせで、既に登録済みの場合はボタン表示を「登録済み」に変える |
| F4 | 在庫イベント連携 | 在庫管理システムが発行する「在庫0→1以上」イベントを受信し、該当商品の通知希望リストに登録している会員を抽出する |
| F5 | 通知メール送信 | 抽出した会員に対し、商品名・商品画像・商品ページへのリンクを含む再入荷通知メールを送信する |
| F6 | 登録解除 | マイページから通知登録済み商品の一覧を確認し、個別に登録解除できる |
| F7 | 送信済み登録の自動クリア | 通知メール送信後、その商品・会員の組み合わせの登録は自動的に完了扱いとし、再度在庫切れ→再入荷が起きても再登録が必要な状態に戻す（二重通知の防止） |
非機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| N1 | 通知遅延の上限 | 在庫イベント発行から通知メール送信まで15分以内を目標とする |
| N2 | 送信失敗時のリトライ | メール送信基盤側のエラーで送信に失敗した場合、最大3回まで自動リトライする |
| N3 | 登録上限 | 会員1人あたりの通知登録可能商品数に上限を設ける（想定: 50件。上限超過時はエラーメッセージで案内） |
成功指標
| 指標 | 現状値 | 目標値 | 計測方法 |
|---|---|---|---|
| 在庫切れ商品関連のCS問い合わせ件数（月間） | 約280件 | 140件以下（3ヶ月後） | CS問い合わせ管理システムのカテゴリ別集計 |
| 再入荷通知の登録率（在庫切れページ訪問者に対する登録者の割合） | 計測なし（新規） | リリース後1ヶ月で計測基盤を確立し、数値を初計測する | 通知登録ボタンのクリックログ |
| 通知経由の商品ページ再訪問率・購入転換率 | 計測なし（新規） | 初期リリースでは目標値を設定せず、計測のみ先行する | 通知メール内リンクのUTMパラメータ計測 |
オープンな論点
- PUSH/LINE通知への拡張は、今回のメール通知の登録率・効果が確認できた後に、担当チームと連携して検討する。優先度は次期ロードマップ会議で決定したい
- 通知希望リストの登録上限（50件）は暫定値。過去の類似機能（お気に入り登録上限など）の実績値を確認し、プランニングMTGまでに再検討する
- 「入荷予定日の事前提示」は将来的にユーザー価値が高いと考えられるが、在庫管理システム側のデータ拡張が前提になるため、今回のPRDでは非ゴールとした上で、次期以降の企画候補として関連チームに共有する
- CS問い合わせの50%削減という目標値は、CS部門長へのヒアリングベースの仮説。過去の類似施策（入荷案内メールの試験配信実績等）があれば参照し、妥当性を再検証したい
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 背景と課題を1つの文章にまとめて書く | 事実（何が起きているか）と主張（なぜ問題か）が混ざり、レビューで「その数値は本当に問題なのか」を検証しにくい | 背景＝事実の記述、課題＝その解釈・主張、と明確に分けて書く |
| 非ゴールを書かない、または後回しにする | リリース直前に「なぜPUSHに対応しないのか」等の追加要望が発生し、スコープクリープが起きる | 要望が出やすい隣接機能（今回ならPUSH/LINE、入荷予定日表示）を先回りして非ゴールに明記する |
| ゴールを「使いやすくする」のような定性表現だけで書く | リリース後に成功したかどうかを判断できず、次の施策判断にもつながらない | 可能な限り定量目標を置く。基準値がない場合は「まず計測基盤を作る」ことをゴールにする |
| 成功指標を「あれば良い」程度の付け足しで書く | 効果測定が形骸化し、機能を作ったこと自体が目的化する | ゴールで掲げた数値と成功指標を1対1で対応させ、計測方法まで具体的に書く |
🏆 実務での使いどころ
PRDは「エンジニアがいきなり実装に入らない」ための最初の防波堤です。特に今回のシナリオのように、CS部門・分析チームなど複数の関係者から断片的に要望や数値が集まってくる状況では、PdM役が一度PRDという形に整理し直すことで、「何のために作るのか」の共通認識をチーム全体で持てるようになります。エンジニア出身でPdM/PM方向を目指す場合、PRDを自分で書けるようになると、逆に他部署が書いたPRDのレビューでも「この非ゴールは本当に妥当か」「この成功指標は計測可能か」といった観点で建設的な指摘ができるようになります。
🚀 次のステップ
このPRDの要件（F1〜F7）をもとに、次はユーザーストーリー形式（テーマ4-2）に分解し、それぞれに受け入れ条件（テーマ4-3、Given-When-Then形式）を書いてみましょう。特にF7（送信済み登録の自動クリア）は状態遷移が絡むため、受け入れ条件で境界値（在庫が0→1→0→1と繰り返した場合の挙動）を明確にする練習に向いています。