🎬 シナリオ
MOps（Marketing Ops/販促システム）チームが運用しているクーポン機能は、現在「1注文につきクーポン1枚まで」という単純な仕様で稼働している。この仕様を変える提案が、複数の部署からほぼ同時に持ち込まれた。
マーケティング部門は、来月の秋の大型セールに向けて「送料無料クーポン」と「〇〇円引きクーポン」を併用できるようにしたいと要望している。競合の主要ECサイトが軒並み複数クーポンの併用に対応しており、併用不可であることが購入直前のカート離脱理由の一つになっているとマーケティング部長は考えている。
一方でCS（カスタマーサポート）部門には別の問題が見えている。直近1ヶ月のクーポン関連の問い合わせは月120件あり、その内訳を集計すると約7割にあたる85件が「クーポンコードを2つ入力しようとしたがエラーになる」というものだった。会員側にはすでに「併用できるはず」という期待が生まれつつあり、CS部長は「今の1対1対応のシステム仕様と、会員が実際に取ろうとしている行動がずれている」と指摘している。
さらに、この提案には社内で慎重にならざるを得ない前例がある。3ヶ月前、「誕生日クーポン」と「新規会員登録クーポン」の判定ロジックに条件分岐の不備があり、本来は併用不可のはずの2枚のクーポンが一部の会員に対して併用適用されてしまう事故が発生した。想定していたクーポン原資は月180万円だったが、実際の原資消化額は320万円（想定の約1.8倍）に達し、経理部長から「クーポンの併用条件を扱う機能を出すときは、原資の上限をどう技術的に担保するのかを事前に示してほしい」と強く釘を刺されている。
現行のクーポン適用ロジックは、クーポンコードを1件受け取り、そのコードの割引条件（金額引き/率引き/送料無料のいずれか）を注文に適用して確定する、という単純な一本道の処理になっている。開発体制はエンジニア2名、QA1名、セール開始までの6週間での対応を想定している。
確認できている制約:
- 現行仕様は「1注文につきクーポン1枚まで」
- クーポン関連の月間問い合わせ120件のうち85件（約7割）が「併用しようとしてエラーになる」というもの
- 3ヶ月前、クーポン併用判定の不備で原資が想定180万円に対し実績320万円（約1.8倍）に超過した事故があり、経理部門が原資上限の技術的担保を要求している
- 現行ロジックは「コード1件→割引種別1つを適用して確定」という一本道の処理
- 開発体制はエンジニア2名、QA1名、6週間以内（セール開始までに間に合わせる必要あり）
📝 課題
あなたのタスク: 上記の状況をもとに、「クーポン併用対応機能」のPRDを作成してください。背景/課題/ゴール/非ゴール/要件/成功指標/オープンな論点の7セクションを必ず含めること。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 「マーケ部長（併用で売上を伸ばしたい）」「CS部長（会員の期待とシステム仕様のズレを埋めたい）」「経理部長（原資超過を二度と起こしたくない）」の3者は、実は全員「クーポン併用に対応すべき」という結論自体には反対していない。対立しているのは結論ではなく「どこまで無条件に併用を許すか」という範囲の話であることに注意する
- 3ヶ月前の事故は「併用させたこと」自体が問題だったのではなく、「本来併用不可のはずの組み合わせが判定ロジックの不備ですり抜けた」ことが問題だった。この違いを課題セクションで正確に言語化できるかがポイント
- 非ゴールでは「すべてのクーポンの組み合わせを無制限に併用可能にする」ことを避け、どの組み合わせなら併用してよいかの範囲をどう絞るかが設計判断の核になる
- 要件では、併用可否を判定するロジックそのものと、原資超過を検知・停止する仕組み（3ヶ月前の事故の再発防止に直結する部分）を分けて書けるとよい
- 成功指標には「売上・離脱率の改善」というマーケの狙いに加えて、CSの狙い（問い合わせ件数の減少）と経理の狙い（原資超過0件）の両方を検証可能な指標として置く
📚 背景知識・用語解説
PRD（Product Requirements Document、プロダクト要求仕様書）とは、「何を」「なぜ」作るのかをチーム全員が同じ理解で進められるようにするための文書です。今回のように複数の部署（マーケティング・CS・経理）が異なる関心を持って関わってくる企画では、PRDが「一番声の大きい部署の要望だけを通した文書」にならないよう、各部署の懸念を課題・要件・成功指標のどこかに位置づけて拾い上げる役割を持ちます。
問い合わせデータから仕様の課題を発見する: CS部門が持つ「問い合わせの内訳」は、会員が実際にプロダクトに何を期待し、どこでつまずいているかを示す一次データです。今回のように「エラーになる」問い合わせの多くが特定の操作（クーポンの複数入力）に集中している場合、それは個々の会員の操作ミスではなく、現行の仕様が会員の自然な行動を想定できていないことを示している可能性があります。PdMはこうした問い合わせの偏りを、機能改善の根拠として扱う必要があります。
原資の技術的な上限担保: マーケティングが「訴求のために併用を許可したい」と考える一方、その併用によってどれだけの割引原資が消化されるかを事前に精緻に見積もることは難しい場合があります。こうしたとき、見積もりの精度に頼るのではなく、「原資消化額が一定の閾値に達したら自動的にクーポン発行・適用を停止する」といった技術的なガードレールを仕組みとして組み込むことで、想定外の事態が起きても被害を一定の範囲に抑えることができます。
ガードレール指標（Guardrail Metric）: 「伸ばしたい指標」だけでなく、「悪化させてはいけない指標」を事前に決めておく考え方です。今回で言えば「クーポン併用によるセール期間中の売上・カート離脱率の改善」が伸ばしたい指標、「クーポン原資消化額」と「原資超過事故の件数」がガードレール指標にあたります。
✅ 模範解答
背景
- 現行のクーポン適用ロジックは「1注文につきクーポン1枚まで」という仕様であり、コードを1件受け取ってその割引種別（金額引き/率引き/送料無料）を適用して確定する一本道の処理になっている
- 直近1ヶ月のクーポン関連問い合わせ120件のうち85件（約7割）が「クーポンコードを2つ入力しようとしてエラーになる」というものであり、会員側にはすでに「併用できるはず」という期待が生まれている
- マーケティング部門は、競合ECサイトが軒並み複数クーポンの併用に対応していることを踏まえ、来月の秋の大型セールに向けて「送料無料クーポン」と「金額引きクーポン」の併用に対応したいと要望している
- 3ヶ月前、「誕生日クーポン」と「新規会員登録クーポン」の判定ロジックの不備により、本来併用不可のはずの2枚が一部会員に対して併用適用され、想定原資180万円に対し実績320万円（約1.8倍）の原資超過事故が発生した経緯がある。経理部門からは、併用に関わる機能を出す際は原資上限をどう技術的に担保するかを事前に示すよう求められている
課題
- マーケティング部門（売上を伸ばすために併用対応したい）、CS部門（会員の期待と現行仕様のズレを埋めたい）、経理部門（原資超過を二度と起こしたくない）の3部門は、いずれも「クーポン併用への対応自体」に反対しているわけではなく、対立しているのは「どの組み合わせを、どこまで無条件に併用可能にするか」という範囲の判断である
- 3ヶ月前の事故は「クーポンを併用可能にしたこと」自体が原因ではなく、「本来併用不可のはずの組み合わせが判定ロジックの不備ですり抜けたこと」が原因であり、この区別をせずに「併用は危険」という結論に倒すと、CS・マーケティング双方の課題（問い合わせの多さ・離脱率）に応えられなくなる
- セール開始までの6週間という期限と、経理部門が求める「原資上限の技術的担保の事前提示」という要求は、実装スケジュール上のトレードオフになりうる
ゴール
- 会員が自然に行おうとする「クーポンの複数入力」という操作に対して、事前に定めた組み合わせルールの範囲内で正しく併用を適用できるようにし、関連する問い合わせ件数を減らす
- 併用によって発生しうる原資消化を技術的な仕組みで一定の範囲に抑え、3ヶ月前と同種の原資超過事故を再発させない設計とし、経理部門のレビューを通過する
非ゴール（今回やらないこと）
- 「送料無料クーポン」×「金額引き/率引きクーポン」の組み合わせのみを併用可能とし、「金額引きクーポン」同士・「率引きクーポン」同士のような同種クーポンの併用は今回のスコープに含めない。同種併用は割引額の予測がより難しく、原資管理の難度が一段上がるため、まずは種別が異なる組み合わせに絞って効果と原資影響を見極める
- 3枚以上のクーポンの同時併用は対象外とし、併用は最大2枚までに限定する
- 誕生日クーポン・新規会員登録クーポンなど、会員個別属性に紐づく既存クーポンの併用可否ルールの見直しは今回のスコープに含めない。これらは3ヶ月前の事故の直接の当事者であり、既存の併用不可ルールをそのまま維持し、変更しない
- クーポン発行・原資管理システムそのものの再設計（アーキテクチャ刷新）は行わない。今回は既存のクーポン基盤を前提に、併用可否判定と原資上限監視という機能を追加する設計にとどめる
要件
機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| F1 | 併用可否マスタの導入 | クーポン種別（送料無料/金額引き/率引き）ごとに、どの種別との併用が許可されるかを定義するマスタを新設する。初期設定は「送料無料×金額引き」「送料無料×率引き」のみ許可、それ以外は不可とする |
| F2 | 複数コード入力UI | カート画面のクーポンコード入力欄を、最大2枚まで入力できるように改修する。3枚目以降の入力は受け付けない |
| F3 | 併用可否判定ロジック | 入力された2枚のクーポンについて、F1のマスタに基づき併用可否を判定する。不可の組み合わせが入力された場合は、どちらのクーポンが原因で併用できないかが会員に伝わるエラーメッセージを表示する |
| F4 | 原資消化額のリアルタイム集計 | セール期間中のクーポン原資消化額（併用によって追加で発生する割引分を含む）をリアルタイムに集計する仕組みを導入する |
| F5 | 原資上限到達時の自動停止 | F4の集計値が、経理部門と事前合意した閾値（セール想定原資に対して一定割合）に達した時点で、新規の併用クーポン適用を自動的に停止し、単体利用のみ継続可能な状態に切り替える。停止時は経理部門・マーケティング部門の担当者にアラート通知する |
| F6 | CS向け併用ルール照会機能 | CS担当者が、問い合わせ対応時にどのクーポン同士が併用可能かをすぐに確認できる一覧画面を用意する |
非機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| N1 | 併用適用ログの保持 | どのクーポンの組み合わせが、いつ、どの注文に適用されたかのログを、経理監査に耐えられる形式で一定期間保持する |
| N2 | 既存の単体クーポン利用フローとの後方互換性 | 1枚のみのクーポン利用は、現行のフロー・ロジックを変更せず、これまでどおり動作することを担保する |
成功指標
| 指標 | 現状値 | 目標値 | 計測方法 |
|---|---|---|---|
| クーポン併用関連の問い合わせ件数 | 月120件中85件（約7割）が併用エラー関連 | セール期間後1ヶ月で、併用エラー関連の問い合わせを明確に減少させる | CS問い合わせ管理システムでの理由コード別集計 |
| セール期間中のクーポン起因カート離脱率 | 計測なし（新規） | 併用非対応の同時期実績と比較し、離脱率を改善させる（マーケティング部門の狙いに対する主指標） | カート画面でのクーポン入力〜購入完了までのファネル分析 |
| クーポン原資消化額の想定超過事故件数 | 3ヶ月前に1件（想定比1.8倍） | 0件（最重要ガードレール） | F4のリアルタイム集計値と経理部門の事後突合 |
オープンな論点
- 同種クーポン同士（金額引き×金額引き等）の併用は今回あえて対象外としたが、マーケティング部門からは中長期的な要望として挙がっており、原資影響の見積もり手法を含めて次回以降の検討課題としたい
- F5の「原資上限の閾値」は経理部門との合意がまだ済んでおらず、閾値の置き方（セール全体の想定原資に対する割合か、日次の消化ペースに対する基準か）によって運用のしやすさが変わるため、要調整
- 自動停止（F5）が発動した場合、セール期間中にマーケティング施策として告知していた併用訴求と矛盾する状態が生まれる可能性があり、その際の会員向けの見せ方はマーケティング部門と別途詰める必要がある
- 併用可否マスタ（F1）の初期設定は今回のセールを想定した最小構成であり、今後クーポン種別が増えた場合の運用ルール（誰がマスタを更新する権限を持つか）は未確定
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| マーケティング部門の要望（売上のための併用対応）だけをそのままPRDにする | CS部門が持つ問い合わせデータの根拠や、経理部門が求める原資上限の担保が反映されず、レビュー段階で差し戻しが発生する | 関係する全部署の懸念とその根拠データを課題セクションに並列で明記する |
| 3ヶ月前の事故を理由に「併用機能は危険」と結論づけ、既存仕様の維持を提案する | 会員の実際の行動（複数コード入力）とCS部門の問い合わせデータという課題の存在を無視することになり、問題を先送りするだけになる | 事故の真因（判定ロジックの不備）を特定し、同じ欠陥を作らない設計で前に進める提案をする |
| 「併用できるようにする」という表側の要件だけを書き、原資超過を防ぐ仕組み（検知・停止）を要件に含めない | 実装段階で「想定外に併用が使われた場合どうなるか」が仕様として合意されておらず、経理部門のレビューを通過できない、または通過後に同種の事故が再発する | 併用可否判定のロジックと、原資消化の監視・自動停止の仕組みを、それぞれ独立した要件として明記する |
| 「異種のみ」「最大2枚まで」のようなスコープの絞り込みを、理由を書かずに非ゴールに列挙するだけで済ませる | なぜその範囲に絞ったのかが伝わらず、マーケティング部門から「なぜ同種併用はやらないのか」という疑問が後から出て手戻りになる | 各非ゴール項目に、なぜ今回は対象外とするのか（原資影響の見積もり困難さ、事故の当事者クーポンである等）の理由を添える |
🏆 実務での使いどころ
クーポン・割引施策のような「原資（お金）が直接動く」機能改善は、マーケティング・CS・経理という立場の異なる複数部署が、同じデータ（問い合わせ件数・原資消化額）を別々の角度から見ていることが多く、対立しているように見えて実は同じ方向を向いているケースが少なくありません。エンジニア出身でPdM/PM方向を目指す場合、対立の構図を「誰の要望を通すか」という二択で捉えるのではなく、「全員が納得できる範囲はどこまでか」を技術的な仕組み（判定ロジック・自動停止の閾値）に翻訳して示せるようになると、実際の現場で複数部署の板挟みになった際にも、PRDという1つの文書で建設的に合意形成できるようになります。
🚀 次のステップ
今回のPRDの要件のうち、F3（併用可否判定ロジック）は「送料無料×金額引き」「送料無料×率引き」という2パターンの組み合わせと、それぞれのエラーメッセージ分岐が絡む要件です。次はこの要件をユーザーストーリー形式（テーマ4-2）に分解し、受け入れ条件（テーマ4-3、Given-When-Then形式）で「送料無料×金額引きを入力した場合」「金額引き×金額引きを入力した場合」のような組み合わせパターンごとの境界値を明確にする練習に進むとよいでしょう。また、F5の原資上限の閾値をどう設定すべきかという論点は、次回以降にRICEスコアリングやトレードオフ判断（PdM-優先順位カテゴリ）で扱う材料にもなります。