🎬 シナリオ
MOps チームは、年末商戦（11月下旬のセール）に間に合わせて 「カゴ落ちリマインドメール」 を初めて出すことになった。カートに商品を入れたまま購入せずに離れた会員に、「カートに商品が残っています」とメールで知らせる機能である。
キックオフ後、関係部署から12件の要望がバックログに集まった。困ったことに、ほぼ全員が自分の要望を「Must」と書いてきた。 要望者の優先度のまま Must を合計すると31人日で、4週間の実キャパシティ30人日を超えている。
- マーケティング部: 「クーポンが付いていないリマインドなんて誰も開かない。500円OFFの自動添付は Must」「LINE でも送りたい」
- CRM担当: 「LINE のほうが開封率は高い。メールだけでは片手落ち」「同じ人に何通も送ると配信停止が増える。頻度上限は Must」
- CS部門: 「前に再入荷通知で在庫切れ商品を案内して、問い合わせが殺到した。在庫切れは必ず除外して」「もう買った人に『お忘れですか』と送ったらクレームになる」
- 法務担当: 「広告宣伝メールなので特定電子メール法の対象。同意のある会員だけに送り、配信停止の方法と送信者を必ず表示すること」
- データ分析担当: 「配信しない対照群（ホールドアウト）を最初から作ってほしい。後からでは11月の比較ができない」
💬
PO「全部 Must だと、どれかが遅れたときに何を落とせばいいか誰にも分からない。このタイムボックスのリリースゴールを先に決めて、それに照らして分け直してほしい。Must は工数の6割までに抑えること。落としたものは『いつ・何が分かったら拾い直すか』も書いておいて。そうしないと、マーケは来月も同じ話を持ってくる」
確認できている制約・データ（出所ラベルつき）:
| 項目 | 値 | 出所 |
|---|---|---|
| カート投入セッション数 | 約180,000件/月 | 実測 アクセス解析、直近3ヶ月平均 |
| カート放棄率 | 72% | 実測（参考 外部統計 Baymard Institute 50調査の平均 70.22%） |
| 放棄カートのうちログイン会員 | 65% | 実測 |
| ログイン会員のうちメール配信同意済み | 58% | 実測 会員DB |
| 放棄カートの平均金額 / うち5,000円以上 | 8,200円 / 60% | 実測 |
| 開発体制 | エンジニア2・QA1、4週間（1タイムボックス） | 決定済み |
| 実キャパシティ | 30人日 | 導出 15営業日×3名×稼働率約67% |
| 既存資産 | 再入荷通知メールのテンプレートと配信基盤（配信停止リンク・送信者表示あり） | 実測 既存システム |
バックログ（要望者が付けた優先度つき）:
| # | 要望 | 要望者 | 工数 | 要望者の優先度 |
|---|---|---|---|---|
| 1 | 放棄カート検知バッチ（ログイン会員・カート投入後1時間購入なし） | PO | 5 | Must |
| 2 | リマインドメールのテンプレート（新規デザイン） | マーケ | 4 | Must |
| 3 | 同意会員に限定＋配信停止リンク・送信者表示 | 法務 | 2 | Must |
| 4 | 在庫切れ・販売終了商品を除外し、残りの商品だけで案内 | CS | 3 | Must |
| 5 | 送信頻度の上限（同一会員に7日間で1通まで） | CRM | 2 | Must |
| 6 | 検知から送信までの間に購入した会員への送信取り消し | CS | 2 | Must |
| 7 | 5,000円以上の放棄カートに500円OFFクーポンを自動添付 | マーケ | 4 | Must |
| 8 | LINE 通知チャネル | CRM | 6 | Must |
| 9 | メール内のおすすめ商品枠（レコメンドエンジン連携） | マーケ | 5 | Should |
| 10 | ホールドアウト群（対象の10%に送らない）の割り当てと計測イベント | データ分析 | 3 | Must |
| 11 | 効果ダッシュボード | マーケ | 4 | Should |
| 12 | カート内商品の値下がり時に再通知 | マーケ | 3 | Could |
| 合計 | 43 | Must 合計 31人日 |
📝 課題
あなたのタスク: 次の3点を作成してください。
- このタイムボックスのリリースゴール（1〜2文）。MoSCoW は「何に対しての Must か」が無いと分けられない
- MoSCoW 優先順位表: 12件を Must / Should / Could / Won't（今回はやらない）に分け、各行に「分類の理由」を書く。Must・Should・Could の工数合計と、30人日に対する比率を示し、Must は60%（18人日）以下に収める。1件を分割して一部だけ Must にするのも可
- Won't の再検討条件表: 今回やらないものについて「何が分かったら・いつ拾い直すか」を書く
加えて、検討した分け方（採らなかった案）を2つ以上、理由つきで残してください。
🔍 ヒント（段階的開示）
ヒント1: Must の判定の問い
DSDM の問い「リリース前夜にこれが間に合わないと言われたら、リリースを止めるか？」。止めないなら Must ではない。「要望者にとって重要か」と「このリリースに無いと出す意味が無いか」は別の問い。
ヒント2: 要望を分割する
「在庫切れ商品だけ除いて残りを案内（3人日）」と「在庫切れを含むカートにはそもそも送らない（1人日）」は、CS の心配を消すという点では同じ効果。既存の再入荷通知テンプレートと配信基盤を使えば、新規で作る量も減る。
ヒント3: バックログの外を見る
誰も要望していないが、無いと怖いものがないか。初めて本番で一斉にメールを送る機能で、誤送信が起きたらどう止める？
ヒント4: 後から足せるか
頻度上限は後から足せる（暫定の固定ルールで代替もできる）。ホールドアウトは11月のデータで比較するなら、配信開始日に存在していないと意味が無い。
ヒント5: クーポンの原資
クーポンは「追加で買ってくれた人」だけでなく「どうせ買った人」にも配られる。送信数 × 購入率 × 5,000円以上の比率 × 500円 で概算してみる。
📚 背景知識・用語解説
📖
一次資料: Agile Business Consortium（DSDM）「MoSCoW Prioritisation」
agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html（参照日 2026-09-24）
agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html（参照日 2026-09-24）
- Must の判定: 満たされなかったら「プロジェクトを中止する」なら Must。もう一つは「リリース前夜に Must が間に合わないと伝えたら、リリースを止めるか」
- Must は工数の60%を超えないのが成功に確信を持てる安全な比率。Could は典型的に約20%を予備（コンティンジェンシー）として持つ
- Could は予備の主な源: 最良の場合にだけ全部届くもの。遅れたら最初に落とす
- Won't have this time: この期間には届けないと合意したもの。記録しておくことで非公式な再混入を防ぎ、期待値を管理する
- MoSCoW はプロジェクト・リリース単位・タイムボックスのレベルごとに付け直す。同じ要件がレベルで違う優先度を持ちうる
なぜ60%なのか: 見積もりは外れるからである。Must が100%だと、1件遅れた瞬間に Must を落とすしかなくなり、「Must は必ず届ける」という約束そのものが壊れる。MoSCoW の本当の価値は、遅れたときに落とす順番がすでに決まっていることにある。
Won't は「却下」ではない: 「今回はやらない」であり、永遠にやらないわけではない。だからこそ「いつ・何が分かったら拾い直すか」を書いておくと、要望者の納得を得やすい。
⚖️
特定電子メール法（総務省「迷惑メール対策」、参照日 2026-09-24）
広告宣伝メールには、事前の同意（オプトイン）、送信者の表示、受信拒否（配信停止）の方法の表示、拒否した人への送信禁止が求められる。詳細は同ページから辿れる「特定電子メールの送信の適正化等に関するガイドライン」。カゴ落ちメールは購入を促す広告宣伝メールで、注文確認のような取引メールとは扱いが違う。
広告宣伝メールには、事前の同意（オプトイン）、送信者の表示、受信拒否（配信停止）の方法の表示、拒否した人への送信禁止が求められる。詳細は同ページから辿れる「特定電子メールの送信の適正化等に関するガイドライン」。カゴ落ちメールは購入を促す広告宣伝メールで、注文確認のような取引メールとは扱いが違う。
ホールドアウト群: 対象者の一部にあえて送らないグループ。カゴ落ちした人の一部はメールが無くても戻ってきて買う。送った群の購入率だけを見ると「どうせ買った人」の分までメールの効果に見えてしまう。送った群と送らなかった群の差だけが、メールの本当の効果（増分）である。
✅ 模範解答
1. リリースゴール
年末商戦（11月下旬）の前に、メール同意会員へのカゴ落ちリマインドメールを、誤送信なく配信開始し、11月末に「メールを送ったことで増えた購入」をホールドアウト群との比較で測れる状態にする。
要素は3つ：配信できる／誤送信しない（法令・クレーム）／効果を測れる。Must はこのどれかに直結するものだけになる。
2. キャパシティの使い方（比較）
3. 配信対象の規模
| 段階 | 件数/月 | 計算 | 出所 |
|---|---|---|---|
| カート投入セッション | 180,000 | — | 実測 |
| 放棄カート | 129,600 | ×72% | 実測 |
| うちログイン会員 | 84,240 | ×65% | 実測 |
| うちメール同意会員 | 約48,900 | ×58% | 実測 |
| 在庫切れを含むカートを除外 | 約45,000 | ×92%（在庫切れを含むカート8%） | 仮定 |
| 1会員1通の制限で重複を除外 | 約31,500 | ×70%（同一会員の複数回カゴ落ち30%） | 仮定 |
| ホールドアウト10%を除いた送信数 | 約28,300 | ×90% | 導出 |
4. MoSCoW 優先順位表
判定の問い（前夜テスト）: 「間に合わなければ、リリースを止めるか？」 ／ 水色の左線＝バックログに無かったエンジニア起案の項目
| # | 要望（分割後） | 工数 | 分類 | 分類の理由 |
|---|---|---|---|---|
| 1 | 放棄カート検知バッチ（1会員につき期間中1通のみの固定条件を含む） | 5 | Must | 無ければ機能が存在しない。止める |
| 2a | テンプレート: 既存の再入荷通知テンプレートを流用 | 2 | Must | 本体が無ければ送れない。止める。新規デザインは不要 |
| 3 | 同意会員に限定＋配信停止リンク・送信者表示 | 2 | Must | 特定電子メール法の義務。欠けたまま送れない。既存基盤の設定を流用 |
| 4a | 在庫0の商品を含むカートには送らない | 1 | Must | CS の過去事例が再発する。止める。「残り商品で案内」までは不要 |
| 6 | 検知後に購入した会員への送信取り消し | 2 | Must | 買った人に「お忘れですか」はゴールの「誤送信なく」に反する |
| 10 | ホールドアウト10%の割り当てと計測イベント | 3 | Must | 配信開始日に無いと11月の比較データは二度と取れない。「測れる」が消える |
| 13 | 配信リハーサルと緊急停止スイッチ（社員宛て試験配信・管理画面から全配信を即停止） | 3 | Must | 誰も要望していないが、初の一斉配信で誤送信時に止める手段が無い |
| Must 小計 | 18 | 60%（上限ちょうど） | ||
| 4b | 在庫切れ商品だけ除き、残りの商品で案内 | 2 | Should | 4a で CS の心配は消える。除外した約8%に送れるようになる改善 |
| 5 | 頻度上限（7日1通）の正式ルール | 2 | Should | 初回は #1 の固定条件で代替。継続配信（12月〜）までに入れたい |
| Should 小計 | 4 | 13% | ||
| 2b | テンプレートのデザイン改善 | 1 | Could | 流用でも送れる。効果は未検証 |
| 11' | 簡易の効果集計（既存 BI で送信群・ホールドアウト群の購入率を週次表示） | 2 | Could | 11月末の比較は分析担当の SQL でもできる。あれば途中経過が早く見える |
| Could 小計 | 3 | 10% | ||
| 予備（未割り当て） | 5 | 17%（Could と合わせ27%を遅延吸収に） | ||
| 7 | クーポン自動添付 | 4 | Won't | 下の原資試算を参照 |
| 8 | LINE 通知 | 6 | Won't | 1件でキャパの20%。LINE 連携会員の比率が不明で届く人数が見積もれない |
| 9 | おすすめ商品枠 | 5 | Won't | レコメンド連携が必要で効果未検証。初回の効果測定を混ぜてしまう |
| 11 | 効果ダッシュボード（本格版） | 4 | Won't | 11' の簡易版で代替 |
| 12 | 値下がり時の再通知 | 3 | Won't | 基本の効果が分かる前に派生機能を足さない |
| Won't 小計 | 22 | — |
⬇️
遅れたときに落とす順番（事前合意）: 予備5人日 → Could（2b → 11'）→ Should（4b → 5）。Must には手を付けない。
交換ルール: Must は上限ちょうど。今後 Must を1件足すなら、同じ工数分を Must から外すことが条件。
交換ルール: Must は上限ちょうど。今後 Must を1件足すなら、同じ工数分を Must から外すことが条件。
5. クーポンの原資試算（#7 を Won't にした根拠）
送信数 約28,300通/月 導出
メールが無くても買う率 8% 仮定 ／ メールによる増分 +1.0pt 仮定 ／ 5,000円以上 60% 実測
クーポン原資 = 28,300 × 9% × 60% × 500円 ≒ 約76万円/月
うち「どうせ買った人」分 = 28,300 × 8% × 60% × 500円 ≒ 約68万円/月（約89%）
メールが無くても買う率 8% 仮定 ／ メールによる増分 +1.0pt 仮定 ／ 5,000円以上 60% 実測
クーポン原資 = 28,300 × 9% × 60% × 500円 ≒ 約76万円/月
うち「どうせ買った人」分 = 28,300 × 8% × 60% × 500円 ≒ 約68万円/月（約89%）
仮定の数字でも、原資の約9割が「メールが無くても買った人」への値引きになりうる。さらにクーポンを学んだ会員がわざとカゴ落ちしてクーポンを待つ行動を誘いかねない。ホールドアウトでメール単体の効果を測る前にクーポンを混ぜると、効果の出どころが分けられない。
6. Won't の再検討条件
| # | 要望 | 拾い直す時期 | 拾い直す条件 | 判断が変わるケース |
|---|---|---|---|---|
| 7 | クーポン自動添付 | 12月第1週 | ホールドアウト比較でメール単体の増分が +0.5pt 未満なら、クーポンありの A/B を次のタイムボックスで試す | 増分 +1.0pt 以上なら原資をかける理由が薄く、引き続き Won't |
| 8 | LINE 通知 | 12月第1週 | メール非同意だが LINE 連携済みの会員が放棄カートの15%以上と分かった場合 | 比率が小さければ6人日を他に使う |
| 9 | おすすめ商品枠 | 1月 | メール単体の効果が測れた後、クリック率を伸ばす施策として A/B | — |
| 11 | ダッシュボード本格版 | 12月 | 継続配信が決まり、マーケが毎週見る運用になった場合 | 11月末で配信停止なら不要 |
| 12 | 値下がり再通知 | 1月以降 | 基本リマインドの増分が確認できた後 | — |
7. 検討した分け方と採らなかった理由
| 案 | 内容 | 判断 | 理由 | 判断が変わる条件 |
|---|---|---|---|---|
| A. 要望者の優先度のまま | Must 31人日 | 不採用 | キャパ30人日超、予備0。1件遅れた時点で Must を落とすしかない | — |
| B. クーポンを Must に残しホールドアウトを外す | マーケの「クーポン無しでは開かれない」を優先 | 不採用 | ホールドアウトは後から足せない。12月にクーポン原資を続けるか判断する材料が消える | 経営が「今年は測定より売上優先」と明言した場合。その場合もホールドアウトは5%に縮めて残すよう交渉 |
| C. LINE を先に出す | CRM の「LINE のほうが開封率が高い」を優先 | 不採用 | 連携会員の比率が不明で届く人数が見積もれない。メールは既存基盤があり工数が小さい | 連携会員の比率が高いと分かった場合 |
| D. リリースゴールに照らして分け直す | Must 18人日（60%）、分割と既存資産の流用で圧縮 | 採用 | 前夜テストで説明がつく。遅れたときに落とす順番が決まっている | ゴールから「効果を測れる」を外すなら #10 は Should に下がる |
8. 要望者への伝え方
| 相手 | 伝える一言 |
|---|---|
| マーケ | 「クーポンは止めたのではなく、メールだけでどれだけ効くかを11月に測ってから、12月第1週にクーポンありを試すか決めます。今混ぜると原資の約9割がどうせ買う人への値引きになる試算です」 |
| CRM | 「LINE は連携会員の比率を出していただければ12月第1週に拾い直します。頻度上限は今回『期間中1通』の固定で代替し、正式ルールは Should に入れました」 |
| CS | 「在庫切れを含むカートにはそもそも送りません。買った人への送信取り消しも Must です」 |
| 法務 | 「同意会員限定と配信停止・送信者表示は Must。既存の再入荷通知と同じ仕組みを使います」 |
| データ分析 | 「ホールドアウト10%は Must。配信開始日から割り当てます」 |
💡 なぜこう作るのか
1
先にリリースゴールを書いた。ゴールが無いと「自分にとって重要」で分けることになり全部 Must になる。ゴールに「効果を測れる」を入れたかどうかで、ホールドアウトは Must にも Should にもなる。分類の議論は、実はゴールの議論である。
2
1件を分割し、Must の部分だけを小さくした（#2→2a/2b、#4→4a/4b、#11→11'）。CS の心配は「在庫切れ商品を案内すること」であって「残りの商品で案内すること」ではない。心配の芯だけ Must にすれば、工数は減っても要望者の不安は残らない。
3
誰も要望していない #13（緊急停止スイッチ）を Must に入れた。「失敗したときの止め方」は誰の要望にもなりにくい。月約2.8万通を初めて一斉に送る機能で止める手段が無いことは、リリースを止める理由になる。エンジニアが優先順位の会議に出る意味の一つ。
4
「後から足せるか」で Must と Should を分けた。頻度上限は後から足せるので暫定ルールで代替して Should。ホールドアウトは開始日に無いと11月のデータが取れないので Must。
5
クーポンを Won't にする根拠を数字で示した。仮定の数字でも「原資の約9割がどうせ買う人へ」という桁が分かれば、「マーケの要望を軽視した」ではなく「測ってから決める」という話になる。仮定はラベルで明示し、ホールドアウトで実測に置き換える道筋も書いた。
6
Must をちょうど60%にし、交換ルールを宣言した。今後 Must を足すなら何かを外す。会議で先に宣言しておくと、途中で Must が増え続けるのを防げる。
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| リリースゴールを書かずに分類を始める | 声の大きい部署の要望が Must になる | 最初にゴールを1〜2文で書き、前夜テストはゴールに対して行う |
| 要望をまるごと Must / Won't に振り分ける | 心配の芯まで捨てるか、不要な部分まで Must にするかの二択になる | 要望を分割し「止める理由」の部分だけを Must に |
| Must を100%近くまで積む | 見積もりが外れた瞬間に Must を落とすことになる | Must は60%以下、Could と予備で20〜30%。落とす順番を事前に決める |
| Won't を「却下」として伝える | 次の会議で同じ要望がまた Must で来る | 「今回はやらない」とし、拾い直す時期と条件を書く |
| バックログにある要望だけを分類する | 失敗時の止め方・監視など、誰の要望にもならないものが抜ける | 「バックログの外に、無いと止めるものはないか」を最後に問う |
| 測定用の仕組みを「あとで」にする | 対照群は後から作れず、繁忙期のデータが無駄になる | 「後から足せるか」を分類の軸に入れる |
🏆 実務での使いどころ
EC の販促機能は、年末商戦・セールのように日付が動かせないタイミングに合わせて出すことが多く、要望が集中して「全部 Must」になりやすい。そのとき PdM やテックリードがやるべきことは、要望の重要さを比べ合うことではなく、リリースゴールを1文で決め、それに対して「止めるか」を1件ずつ問うことである。既存資産の流用（#2a・#3）、要望の分割（#4a）、失敗時の止め方（#13）、測定の仕組みは後から足せないこと（#10）は、実装を知っている人のほうが気づきやすい。
転用できるテンプレート:
リリースゴール: [期限]までに、[誰]に[何]を[どういう品質で]届け、[何を測れる状態]にする
優先順位表: # | 要望 | 工数 | 分類 | 理由（前夜テスト：止めるか）
小計行: Must ≤60% / Should / Could ≈20% / 予備
遅れたときに落とす順番: 予備 → Could → Should
Won't 表: # | 拾い直す時期 | 条件 | 判断が変わるケース
優先順位表: # | 要望 | 工数 | 分類 | 理由（前夜テスト：止めるか）
小計行: Must ≤60% / Should / Could ≈20% / 予備
遅れたときに落とす順番: 予備 → Could → Should
Won't 表: # | 拾い直す時期 | 条件 | 判断が変わるケース
🚀 次のステップ
- 11月末にホールドアウト比較の結果が出たら、#7 クーポン・#8 LINE を Value vs Effort マトリクス（テーマ5-2）で並べ直す。仮定の増分 +1.0pt が実測に置き換わるとクーポンの価値の見積もりが変わる
- ホールドアウト10%（月約3,150人）で +1.0pt を統計的に検出できるかは別途計算が必要（PdM-リサーチの A/B テスト設計の題材）。検出できないなら、比率を上げるか測定期間を延ばすかをゴールの段階で決め直す
- 自分への問い: マーケ部長が「クーポンが無いなら年末商戦に出す意味が無い」と言い、経営もそれを支持したら、リリースゴールをどう書き換え、表のどの行が動くか
🧭 扱わなかった範囲（この演習の限界）
- 特定電子メール法の同意の取り方（同意画面の文言・記録の保存など）は、既存の会員同意を使う前提にして扱っていない
- ホールドアウト10%で増分を検出できるかのサンプルサイズ計算は次のステップに回した
- 非ログイン利用者のカゴ落ち（放棄カートの35%）はメールアドレスが分からないため対象外とし、分類表にも載せていない
- 「実測」ラベルの数値は演習シナリオ上の設定値。Baymard の70.22%のみ外部の公開統計（baymard.com、参照日 2026-09-24）