🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは、EC定期購入（サブスクリプション）機能の改善案をCS（カスタマーサポート）部門から持ち込まれた。CS部門が直近3ヶ月の解約理由データを集計したところ、解約件数1,200件のうち408件（34%）が「今回だけ届けなくていい」「来月は少し量を減らしたい」といった一時的な受け取り調整の要望であり、恒久的にやめたいわけではないことが判明した。しかし現状のマイページには「解約する」ボタンしかなく、一時停止の導線が存在しないため、本来は一時的な離脱で済んだはずの会員が恒久解約に流れてしまっている疑いがある。
CS部長からの依頼は明確だ。「次回のお届けだけスキップできる機能を、できるだけ早く追加してほしい」。
一方でマーケティング部長はこの案に諸手を挙げて賛成しているわけではない。「スキップを簡単にできるようにすると、『今月は届けなくていいや』が習慣化して、そのままフェードアウト解約につながるのではないか。定期便の価値は『自動で届く安心感』にあるのに、それを自分で止める選択肢を目立たせすぎるのは逆効果かもしれない」という懸念を示している。
さらに、この施策には社内で慎重にならざるを得ない事情がある。半年前、「お届け日を変更する」機能をリリースした際、変更後の請求書生成タイミングと自動課金バッチの実行タイミングが競合し、一部の会員に対して同じ月に二重で課金してしまう事故が発生した。件数は37件と少数だったが、経理部門・法務部門を巻き込む騒ぎになり、経理部長からは「次に決済タイミングに関わる機能を出すときは、事前に整合性のテスト計画を見せてほしい」と釘を刺されている。
現行のサブスク基盤は、指定日に自動課金が確定した後、出荷指示バッチが夜間に走る仕組みになっている。開発体制はエンジニア1.5名、デザイナー0.3名、6週間以内でのリリースを想定している。
確認できている制約:
- 直近3ヶ月の解約1,200件中408件（34%）が一時停止ニーズ（恒久解約ではない）
- 半年前、決済タイミングに関わる別機能で二重課金事故（37件）が発生し、経理部門から事前のテスト計画提示を求められている
- 現行基盤は「指定日に自動課金確定→夜間に出荷指示バッチ」という順序で動いている
- 開発体制はエンジニア1.5名、デザイナー0.3名、6週間以内
📝 課題
あなたのタスク: 上記の状況をもとに、「定期購入お届けスキップ機能」のPRDを作成してください。背景/課題/ゴール/非ゴール/要件/成功指標/オープンな論点の7セクションを必ず含めること。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 今回は「CS部長（早く出したい）」「マーケ部長（習慣化・フェードアウト解約を懸念）」「経理部長（決済タイミングの事故を再発させたくない）」という3者の異なる懸念が同時に存在する。課題セクションでこれらを取りこぼさず言語化できるかがポイント
- 半年前の二重課金事故は、単なる背景事実ではなく「なぜ今回は決済タイミングの整合性を要件として明記する必要があるのか」の根拠になる
- マーケ部長の懸念（スキップの習慣化）は、機能を作らない理由にはならないが、「スコープをどこまで広げるか」（例: 連続スキップを許可するか）の判断材料になる。非ゴールで扱うと筋が通りやすい
- 成功指標には「解約率を下げたい」という狙いに加えて、マーケ部長の懸念に応える指標（スキップ利用者のその後の継続率など）と、経理部長の懸念に応える指標（二重課金事故件数）の両方を置けるとよい
- 要件では「スキップ操作そのもの」だけでなく、「スキップした月の課金・出荷バッチがどう動くか」という裏側の挙動まで明記できるかが、経理部門のレビューを通す鍵になる
📚 背景知識・用語解説
PRD（Product Requirements Document、プロダクト要求仕様書）とは、「何を」「なぜ」作るのかをチーム全員が同じ理解で進められるようにするための文書です。今回のように複数の部署（CS・マーケティング・経理）が異なる利害を持って関わってくる企画では、PRDが「誰か一人の言い分だけを通した文書」にならないよう、各部署の懸念を課題・要件・成功指標のどこかに位置づけて拾い上げる役割を持ちます。
解約理由の解像度を上げる: 「解約」という1つのイベントの裏には、実は「完全にやめたい」と「一時的に止めたい」という性質の異なる2つのニーズが混在していることがあります。今回のように解約理由データを分解すると、恒久解約用の導線しか用意していないプロダクト側の設計不備によって、本来は防げたはずの解約が発生している可能性が見えてきます。これはPdMが「なぜ解約が起きているか」を数字の背後まで掘り下げる典型例です。
機能追加が行動を変えるリスク（習慣化懸念）: 新しい選択肢を提供すると、それが便利であるほど利用者の行動パターン自体を変えてしまうことがあります。「スキップを簡単にする」という提案に対して「それが恒久解約への足がかりになるのでは」という懸念が出ること自体は自然であり、頭ごなしに否定せず、非ゴール（例: 今回は連続スキップまでは許可しない）や成功指標（スキップ後の継続率）で検証可能な形に落とし込むのがPdMの役割です。
ガードレール指標（Guardrail Metric）: 「伸ばしたい指標」だけでなく、「悪化させてはいけない指標」を事前に決めておく考え方です。今回で言えば「一時停止起因の恒久解約率の低下」が伸ばしたい指標、「二重課金事故件数」「スキップ利用者のその後の継続率」がガードレール指標にあたります。
✅ 模範解答
背景
- 直近3ヶ月の定期購入解約1,200件のうち408件（34%）が、CSへのヒアリングにより「今回だけ届けなくていい」等の一時的な受け取り調整ニーズであることが判明した。現行のマイページには恒久解約の導線しかなく、一時停止したいだけの会員が恒久解約に流れている疑いがある
- 半年前、「お届け日を変更する」機能のリリース時に、変更後の請求書生成タイミングと自動課金バッチの実行タイミングが競合し、37件の二重課金事故が発生した経緯がある。経理部門からは、次に決済タイミングに関わる機能を出す際は事前にテスト計画を提示するよう求められている
- 現行のサブスク基盤は、指定日に自動課金が確定した後、夜間バッチで出荷指示が行われる順序で動作している
- マーケティング部門からは、スキップ機能が「定期便を自分で止める」行動を習慣化させ、フェードアウト型の解約を誘発するのではという懸念が示されている
課題
- CS部門は「一時停止ニーズに応える恒久解約防止の導線」を求めているが、マーケティング部門は「スキップの習慣化による中長期的な解約リスク」を懸念しており、両者の要求は完全には一致しない
- 決済タイミングに関わる機能である以上、半年前と同種の事故（課金・出荷バッチのタイミング競合）を再発させないための整合性設計が不可欠であり、これを怠ると経理部門・法務部門からの信頼をさらに損なう
- 「早く出したい」というCS部門の要望と、「事前にテスト計画を見せてほしい」という経理部門の要望は、開発スケジュール上のトレードオフになりうる
ゴール
- 一時的な受け取り調整ニーズを持つ会員が、恒久解約を選ばずに済む導線（次回お届けのスキップ）を提供し、一時停止起因の恒久解約を減らす
- 課金・出荷バッチのタイミング競合による事故を再発させない設計とし、経理部門のレビューを通過する
非ゴール（今回やらないこと）
- 2回以上の連続スキップ（例: 来月・再来月をまとめて止める）は今回のスコープに含めない。マーケティング部門の懸念（習慣化）を踏まえ、まずは「次回1回のみ」に絞って利用状況と解約率への影響を見極める
- お届け内容そのものの変更（量を減らす・商品を変更する等）は対象外とし、あくまで「次回分を届けない」というオン・オフの選択肢に限定する
- 決済基盤や出荷バッチそのものの再設計（アーキテクチャ刷新）は行わない。今回は既存の課金確定・出荷指示の順序を前提に、スキップという新しい状態を安全に組み込む設計にとどめる
- スキップ理由のアンケート等、定性的なデータ収集の仕組み化は今回のスコープに含めない（必要であれば別途PdM-リサーチのテーマとして扱う）
要件
機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| F1 | スキップ申請UI | マイページから、次回お届け分についてのみ「今回はスキップする」を選択できるようにする。選択できるのは1回先の配送分のみ |
| F2 | 申請締切の設定 | スキップ申請は、当該月の課金確定バッチ実行の3日前までに完了させる必要がある。締切を過ぎた申請はエラー表示とし、通常どおり課金・出荷が行われる |
| F3 | 課金・出荷バッチへのスキップ状態の反映 | 課金確定バッチと出荷指示バッチの双方が、対象会員のスキップ状態を判定条件に含めるよう改修する。スキップ確定済みの会員に対しては、課金確定バッチ・出荷指示バッチのいずれも実行しない |
| F4 | 決済タイミング整合性テスト計画の策定・実施 | 半年前の二重課金事故を踏まえ、スキップ確定・課金確定・出荷指示の3つのバッチが競合するケース（申請直後にバッチが走った場合等）を洗い出し、本番同等データでのテスト計画を経理部門にリリース前レビューとして提示する |
| F5 | 次回請求日の自動再計算 | スキップした月は課金を発生させず、翌月以降は通常の周期（毎月同日）で課金・出荷を再開する。スキップによって以降の請求サイクル自体がずれないようにする |
| F6 | CS向け管理画面での照会機能 | CS担当者が会員ごとのスキップ申請履歴・次回請求日をマイページと同じ情報で照会できるようにする。問い合わせ対応時の齟齬を防ぐ |
非機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| N1 | 操作ログの保持 | 誰が・いつ・どの会員のスキップを申請・確定したかのログを、経理監査に耐えられる形式で一定期間保持する |
| N2 | 既存の配送日変更機能との排他制御 | 同一の配送サイクルに対して「配送日変更」と「スキップ」が同時に申請された場合の優先順位・排他ルールを明確にし、両機能が矛盾した状態を作らないようにする |
成功指標
| 指標 | 現状値 | 目標値 | 計測方法 |
|---|---|---|---|
| 一時停止ニーズ起因と推定される恒久解約率 | 解約1,200件中408件（34%）が一時停止ニーズ由来と推定 | リリース後3ヶ月で、同ニーズ由来と推定される恒久解約件数を明確に減少させる | 解約理由ヒアリング（CS記録）とスキップ機能利用ログの突合 |
| スキップ利用者の3ヶ月後継続率 | 計測なし（新規） | スキップを1回以上利用した会員の3ヶ月後継続率が、未利用会員と比べて著しく低下しない（マーケ部長の懸念に対するガードレール） | 会員IDベースでのスキップ利用有無×継続状況のコホート比較 |
| 決済タイミング関連の事故件数 | 半年前に37件（別機能） | 0件（最重要ガードレール） | 経理部門への事故報告記録、課金・出荷ログの突合監査 |
オープンな論点
- 連続スキップ（2回以上）の要望はマーケティング部門からも一部あり、今回あえて1回のみに絞ったことの妥当性は、リリース後の利用データを見た上で企画会議で再検討したい
- スキップ後の継続率という指標が実際に「習慣化によるフェードアウト解約」を検出できる指標として十分かは未検証であり、観測期間をどの程度取るべきかも含めて要議論
- F4（決済タイミング整合性テスト）にどの程度のリードタイムが必要かは経理部門との調整が済んでおらず、6週間のスケジュールに収まるかは未確定
- 申請締切「3日前」は暫定値であり、物流側の出荷準備リードタイムとの整合が取れているかは物流部門への確認が必要
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 依頼元（今回はCS部門）の要望だけをそのままPRDにする | マーケティング部門・経理部門など他部署の懸念が反映されず、企画会議やレビューの段階で差し戻しが発生する | 関係する全部署の懸念を洗い出し、課題セクションに並列で明記する |
| 過去の事故（決済タイミングの競合）を背景に書かず、新規施策として提案する | 経理部門が「前回と何が変わったのか」を判断できず、口頭説明が必要になり、PRDとしての説得力が下がる | 過去の事故は事実として背景に明記し、要件でどう再発防止するかまで書く |
| 「スキップ機能を作る」という表側の要件だけを書き、課金・出荷バッチ側の挙動を明記しない | 実装段階で「スキップした月の請求はどうなるのか」が仕様として合意されておらず、後から仕様の作り直しが発生する | 表側の操作だけでなく、裏側のバッチ処理がどう変わるかまで要件に含める |
| マーケティング部門の懸念（習慣化）を「気にしすぎ」として扱い、成功指標に反映しない | 施策が解約率という主指標では成功していても、水面下で別の問題（フェードアウト解約の増加）が進行していることに気づけない | 懸念として挙がった論点は、検証可能な指標に翻訳して成功指標に含める |
🏆 実務での使いどころ
サブスクリプション・定期購入のような継続課金モデルの機能改善は、CS・マーケティング・経理・法務など、立場の異なる複数部署が同時に関わってくることが多く、特に決済タイミングが絡む機能では過去の事故の有無がレビューの通りやすさを大きく左右します。エンジニア出身でPdM/PM方向を目指す場合、「一部門の要望に応える」だけでなく「他部門が懸念する副作用を検証可能な指標に翻訳する」という発想に慣れておくと、実際の現場で複数部署の板挟みになった際にも、対立をそのまま持ち越さずPRDという1つの文書に落とし込んで合意形成できるようになります。
🚀 次のステップ
このPRDの要件（F1〜F6）のうち、特にF3（課金・出荷バッチへのスキップ状態の反映）は複数の条件分岐（申請タイミング・既存の配送日変更との組み合わせ等）が絡む要件です。次はこの要件をユーザーストーリー形式（テーマ4-2）に分解し、受け入れ条件（テーマ4-3、Given-When-Then形式）で「締切2日前に申請した場合」「締切当日に申請した場合」のような境界値を明確にする練習に進むとよいでしょう。また、連続スキップを許可すべきかという論点は、次回以降にRICEスコアリングやKanoモデル（PdM-優先順位カテゴリ）で優先度を検討する材料にもなります。