🎬 シナリオ
MOps（Marketing Ops/販促システム）チームに、マーケティング部門から「カート放棄（カゴ落ち）フォロー施策」の企画依頼が届いた。EC分析基盤の計測によると、商品をカートに追加したにもかかわらず24時間以内に購入に至らず離脱する「カート放棄」が月間平均4,200件発生している。さらに詳しく見ると、その約35%（月1,470件相当）は過去に購入履歴のある既存会員のカート放棄であることが分かっている。
マーケティング部長からの依頼はこうだ。「カートに入れるところまで進んだユーザーは、購入意欲がそれなりに高いはず。放置している今の状態はもったいない。カート放棄後にリマインドメールを送る仕組みを企画してほしい。ただし、値引きクーポンをむやみに乱発すると粗利を圧迫するし社内の稟議も通しにくいので、まずはクーポンなしのリマインドのみで効果を検証したい」
一方で、過去に実施した「セール開始通知メール」施策では、配信頻度が高まった時期にメール配信停止（オプトアウト）率が通常の約1.8倍に跳ね上がった実績がある。エンジニアリングリードからは「今回はメールをまた1本増やすことになる。カート放棄の機会損失を取りに行きたい気持ちは分かるが、配信頻度への配慮もセットで考えてほしい」と釘を刺されている。
確認できている制約:
- メール配信は既存の販促メール配信基盤を使う（1日あたりの配信数上限は5万通/日で、他の販促メールと共有枠）
- 会員のみ対象（非会員のゲスト購入カートはメールアドレスと紐付けできないため対象外）
- カート情報は既存のカートシステムが保持しており、「カートに商品が入ったまま一定時間購入されていない」状態を検知するイベント発行の仕組みはまだ存在しない（今回新規に作る必要がある）
- 開発体制はエンジニア1名（あなた）、デザイナー0.3名、6週間以内でのリリースを想定
📝 課題
あなたのタスク: 上記の状況をもとに、「カート放棄リマインドメール機能」のPRDを作成してください。背景/課題/ゴール/非ゴール/要件/成功指標/オープンな論点の7セクションを必ず含めること。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 今回のシナリオには「機会損失を取りに行きたい」という要求と「配信頻度を上げすぎるとオプトアウトが増える」という制約が同時に存在する。この2つを両方とも「課題」に落とし込めるかがポイント
- ゴールは測定可能な形で書く。ただし「オプトアウト率を過去の水準以下に抑える」のように、達成したい数値だけでなく守りたい上限（ガードレール）も書けるとよい
- 非ゴールでは、シナリオ中で明示的に除外されているもの（クーポン付与、非会員対応）に加えて、「配信回数を絞る」判断もスコープの意思決定として書けるとよい
- 要件は機能要件・非機能要件を分ける。今回は「カート放棄をどう検知するか」という技術的な前提（イベント発行の仕組みがまだない）が要件に影響することに注意する
- 成功指標は「取りに行きたい効果」と「守りたい上限」の両方を指標として置く。どちらか一方だけだと、後から「効果は出たがオプトアウトが急増していた」といった見落としが起きうる
- オープンな論点には、まだ決め切れていない配信タイミングや配信対象の絞り込み条件などを書く
📚 背景知識・用語解説
PRD（Product Requirements Document、プロダクト要求仕様書）とは、「何を」「なぜ」作るのかをチーム全員が同じ理解で進められるようにするための文書です。エンジニアやデザイナーが実装方針（How）を検討する前提として、PdM（またはPdM役）が「何を解決したいか（Why/What）」を明文化する役割を持ちます。
ガードレール指標（Guardrail Metric）: 「伸ばしたい指標」だけでなく、「悪化させてはいけない指標」を事前に決めておく考え方です。今回で言えば「リマインド経由の購入転換率」が伸ばしたい指標、「メール配信停止率」がガードレール指標にあたります。ガードレール指標を決めずに施策を進めると、主指標が改善していても、別の指標が静かに悪化していることに気づけません。
非ゴール（Non-Goals）とスコープの意思決定: 非ゴールは、意図的に今回のスコープに含めないことを明記するセクションです。今回のように「クーポン付与はしない」「配信は1回のみ」といった判断は、単なる制約の受け入れではなく、「機会損失の回収」と「配信頻度への配慮」のバランスを取るためのPdMとしての意思決定です。この意思決定の理由まで書いておくと、後からのレビューで「なぜクーポンを付けないのか」という問いに根拠を持って答えられます。
成功指標（Success Metrics）: PRDを書く段階で「リリース後、何をもって成功と判断するか」を事前に決めておく指標です。今回のように相反する力学がある施策では、伸ばしたい指標とガードレール指標の両方を成功指標に含めることが特に重要になります。
✅ 模範解答
背景
- 商品をカートに追加後、24時間以内に購入に至らず離脱する「カート放棄」が月間平均4,200件発生している
- カート放棄のうち約35%（月1,470件相当）は、過去に購入履歴のある既存会員による放棄である
- 現状、カート放棄後のフォローアップ施策は存在せず、離脱したユーザーへの再アプローチは行われていない
- 過去の「セール開始通知メール」施策では、配信頻度が高まった時期にメール配信停止（オプトアウト）率が通常の約1.8倍に上昇した実績がある
- メール配信基盤は既存の販促メール配信システムを共有しており、1日あたりの配信数上限は5万通/日（他の販促メールと共有枠）
課題
- カートに商品を追加するという「購入意欲がある程度高い」ユーザーの離脱を、現状まったくフォローできておらず、機会損失（取りこぼした購入）が発生している可能性が高い
- 一方で、過去にメール配信頻度を増やした施策でオプトアウト率が急上昇した実績があるため、今回新たにメールを1本追加することは、他の販促メール全体の到達率を下げるリスクを伴う
- 「カート放棄による機会損失の回収」と「配信頻度増加によるオプトアウトの抑制」は相反する力学であり、どちらか一方だけを追う設計にすると、もう一方が悪化した際に気づけない。両方を成功指標として同時に扱う設計が必要
ゴール
- カートに商品を入れたまま一定時間購入に至っていない会員に対し、カート放棄から一定時間後にリマインドメールを自動送信する仕組みを構築する
- リリース後1ヶ月で、リマインドメール経由の購入転換率を計測できる状態を作る（初期リリース時点では具体的な目標値は設定せず、計測基盤を先に整える）
- メール配信停止（オプトアウト）率を、過去のセール通知メール施策時の水準（通常の1.8倍）を超えない範囲に抑える
非ゴール（今回やらないこと）
- 値引きクーポンなどのインセンティブ付与（マーケティング部長の要望どおり、まずはクーポンなしのリマインドのみで効果を検証する。効果が確認できた場合、次期施策としてクーポン付与のA/Bテストを検討する）
- 非会員（ゲスト購入）カートへのフォロー（メールアドレスと紐付けができないため、今回は会員のカートのみを対象とする）
- 放棄後の複数回フォロー配信（配信頻度増加によるオプトアウトへの懸念を踏まえ、今回は放棄後1回のみの送信に限定する。複数回配信の効果検証は次期以降の課題とする）
- PUSH通知・アプリ内通知への対応（今回はメールチャネルのみで先行検証し、他チャネルへの拡張は効果確認後に検討する）
要件
機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| F1 | カート放棄イベントの検知 | カートに商品が追加されてから一定時間（暫定: 3時間）購入に至っていない状態を検知するバッチ処理を新規に作る。既存のカートシステムにはこの検知の仕組みがまだないため、今回新規実装する |
| F2 | 対象会員の絞り込み | 検知対象は会員のみとし、非会員（ゲスト購入）のカートは対象外とする |
| F3 | リマインドメール送信 | 検知した会員に対し、カートに残っている商品名・商品画像・カートページへのリンクを含むリマインドメールを送信する |
| F4 | 送信済みフラグの管理 | 同一カートに対して一度リマインドメールを送信したら、そのカート内容に対しては再送しない（複数回配信をしない、という非ゴールの実装上の担保） |
| F5 | 購入完了時の送信キャンセル | リマインドメール送信予定の会員が、送信タイミングより前に該当商品を購入した場合、送信をキャンセルする（購入済みの商品を「まだ買っていませんか」と案内してしまう事故を防ぐ） |
| F6 | 配信停止（オプトアウト）の反映 | 会員が既存の配信停止設定を行っている場合、リマインドメールの対象から除外する |
非機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| N1 | 配信数上限の遵守 | 既存の販促メール配信基盤の1日あたり上限（5万通/日、他施策と共有）を超えないよう、送信対象件数を事前に見積もり、上限に近づく場合はアラートを出す |
| N2 | 検知処理の実行間隔 | カート放棄検知バッチは1時間に1回実行し、検知から送信まで最大1時間程度のばらつきが生じることを許容する |
| N3 | 送信失敗時のリトライ | メール送信基盤側のエラーで送信に失敗した場合、最大3回まで自動リトライする |
成功指標
| 指標 | 現状値 | 目標値 | 計測方法 |
|---|---|---|---|
| リマインドメール経由の購入転換率（送信対象に対する購入完了の割合） | 計測なし（新規） | リリース後1ヶ月で計測基盤を確立し、数値を初計測する | メール内リンクのUTMパラメータ計測 |
| カート放棄件数のうちリマインド送信できた件数の割合（カバレッジ） | 0% | リリース後1ヶ月で80%以上（送信対象外〈配信停止会員等〉を除く） | 検知バッチのログ集計 |
| メール配信停止（オプトアウト）率 | 通常施策時を基準値とする | 過去のセール通知メール施策時の水準（基準値の1.8倍）を超えない | 配信基盤のオプトアウトログ集計（リリース前後で比較） |
オープンな論点
- カート放棄から何時間後に送信するのが最適かは未検証（今回は暫定3時間としたが、短すぎると「急かされている」印象を与え、長すぎると購入意欲が冷めてしまう可能性がある）。プランニングMTGで初期値の妥当性を議論し、リリース後にA/Bテストで検証したい
- カート内商品の在庫が放棄後に0になった場合の挙動（リマインド対象から外すか、「在庫わずか」として送るか）は未決定。在庫管理システム側との連携要否も含めて次回までに確認する
- 高額商品のカート放棄と低額商品のカート放棄で、メール文面や送信タイミングを分けるべきかは今回のスコープでは検討していない。将来的な拡張候補として共有する
- オプトアウト率のガードレール（基準値の1.8倍）は暫定値。過去のセール通知メール施策のログを精査し、プランニングMTGまでに妥当性を再検証したい
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「伸ばしたい指標」だけを成功指標に置く | 施策が成功しているように見えても、配信停止率のような別の指標が悪化していることに気づけない | ガードレール指標（今回はオプトアウト率）を必ず成功指標に含め、両方を同時に見る |
| 相反する要求・制約のうち片方だけを課題に書く | 要件セクションで無意識にもう片方が軽視され、レビュー段階で「配信頻度への配慮はどこに反映されているのか」と指摘されて手戻りが起きる | 課題セクションの時点で相反する力学を両方明示し、要件・成功指標の両方がそれに応答する形にする |
| 非ゴールを単なる制約の受け入れとしてだけ書く | 「なぜやらないのか」の理由が抜けると、後から「効果が薄いから範囲を広げよう」という提案に対して反論する根拠が持てない | 非ゴールには「なぜ今回はやらないと判断したか」の理由（今回は配信頻度への配慮）まで書く |
| 新規に必要な仕組み（今回はカート放棄検知バッチ）を要件の中に埋もれさせる | エンジニアリードが実装工数を見積もる際に「既存の仕組みを使うだけ」と誤解し、スケジュールに新規実装分が反映されない | 「既存にない・新規に作る」ことが明確な要件は、背景または要件の説明文で明示しておく |
🏆 実務での使いどころ
PRDは「エンジニアがいきなり実装に入らない」ための最初の防波堤です。特に今回のシナリオのように、事業部門からの要望（機会損失の回収）とエンジニアリング側の懸念（配信頻度への配慮）が同時に存在する状況では、PdM役がPRDという形でその両方を一度に整理し直すことで、「何を、どこまでやるか」の共通認識をチーム全体で持てるようになります。エンジニア出身でPdM/PM方向を目指す場合、こうした相反する要求を1つのPRDの中で両立させる書き方に慣れておくと、実際のプロジェクトで「営業・マーケの要望」と「開発・運用の懸念」の板挟みになった際にも、両方を成功指標に落とし込んで説明できるようになります。
🚀 次のステップ
このPRDの要件（F1〜F6）をもとに、次はユーザーストーリー形式（テーマ4-2）に分解し、それぞれに受け入れ条件（テーマ4-3、Given-When-Then形式）を書いてみましょう。特にF5（購入完了時の送信キャンセル）は「検知→送信予約→購入→キャンセル」という時系列の絡む処理のため、受け入れ条件でタイミングのずれ（送信直前に購入された場合など）を明確にする練習に向いています。