🎬 シナリオ
MOpsチームでは「会員ランク（ロイヤルティ）プログラム」画面の改修を検討している。現在のランクはブロンズ/シルバー/ゴールド/プラチナの4段階で、マイページ上でランクと特典を確認できる。
各部門から改修要望が9件バックログに積まれており、あなたはこれを次のスプリントサイクル（3週間・実キャパシティ30人日）に収まるようMoSCoWで分類する役目を任された。バックログは以下の通り。
| # | 要望内容 | 出所部門 | 工数見積 |
|---|---|---|---|
| 1 | ランクダウン予告バナー（マイページ上部に「来月ランクが下がる可能性があります」を表示） | CRM部門 | 5人日 |
| 2 | 新ランク帯「ダイヤモンド」の特典訴求UI追加 | マーケティング部門 | 6人日 |
| 3 | ランク進捗バーのビジュアル刷新（残ポイント数の視認性向上） | デザイン部門 | 4人日 |
| 4 | ランク特典の適用漏れに関するFAQ自動表示（マイページ内） | CS部門 | 3人日 |
| 5 | ランク基準の見直しサイクルを年1回→四半期ごとに変更 | 経営企画部門 | 8人日 |
| 6 | ランク別クーポンの自動発行バッチ化（現状は手動発行） | マーケティング部門 | 7人日 |
| 7 | ランクをSNSでシェアできる機能の追加 | マーケティング部門 | 5人日 |
| 8 | ランク到達時のプッシュ通知 | CRM部門 | 3人日 |
| 9 | 管理画面でのランク会員一覧CSV出力 | CS/オペレーション部門 | 2人日 |
バックログ合計は43人日。実キャパシティ30人日には収まらないため、削らざるを得ない。
さらに、CRM部門長とマーケティング部門長がそれぞれ「自分の要望こそ最優先」と主張して対立している。
両者とも役員クラスへの説明責任を持ち、社内での発言力は同等。あなたはPdM/エンジニアとして、両者の主張に優劣をつけて全体のMoSCoW分類を確定させる必要がある。
📝 課題
あなたのタスク: 上記9件のバックログをMust/Should/Could/Won'tに分類し、実キャパシティ30人日に収まる形で優先順位表を作成してください。さらに、CRM部門長とマーケティング部門長の対立を裁定する基準を明示し、その基準に沿ってどちらを優先するか（または両方Mustにするか）を1つの意思決定メモとして書いてください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- MoSCoWは「全部やりたい」を前提にすると機能しない。Won'tを明確に言い切ることが一番重要
- Mustは「これがないとリリース・運用が成立しない、または重大な損失を防げない」もの。Shouldは「あった方が良いが、なくても致命傷にはならない」もの
- 2人の対立は「声の大きさ」や「役職の重さ」で決めると次も同じ対立が起きる。再現可能な判断基準（軸）を1つ言語化してから当てはめる
- キャパシティに対してMust+Shouldがぴったり収まるのではなく、多少バッファを残す（見積もりのブレへの備え）
- Could/Wontに落とした要望も、なぜ今回やらないかの理由を一言添える（「忘れられた」ではなく「意図的に見送った」と伝わるように）
📚 背景知識・用語解説
MoSCoW法とは、要求・機能を以下の4区分に分類する優先順位付け手法です。
- Must have: これがないとリリース・運用が成立しない。法令対応や重大な事故の再発防止など、やらない場合の損失が具体的で大きいもの
- Should have: 重要だが、なくても致命傷にはならない。次善策（回避策）が存在する
- Could have: あれば望ましいが、優先度は低い。工数に余裕があれば着手
- Won't have（this time）: 今回のスコープでは意図的にやらない。「永久にやらない」ではなく「今回のサイクルでは」という時限を明示するのがポイント
MoSCoWが機能不全を起こす典型パターンは、「全員が自分の要望をMustだと主張し、結局ほぼ全部Mustになる」ことです。これを防ぐには、Mustの定義を「やらないと何が起きるか」を定量・具体的に言えるものに絞り込む必要があります。定性的な「重要だと思う」だけではMustにしない、という運用ルールが実務では有効です。
✅ 模範解答
MoSCoW優先順位表
| # | 要望内容 | 出所部門 | 工数 | 分類 | 分類理由 |
|---|---|---|---|---|---|
| 1 | ランクダウン予告バナー | CRM | 5人日 | Must | 8,400人規模の解約リスクに直結。実害が発生してからでは取り返しがつかない |
| 2 | ダイヤモンド特典訴求UI | マーケ | 6人日 | Must | 社外プレスリリース済み・告知準備が進行中の対外コミットメント。延期は企業の信用問題になる |
| 8 | ランク到達時のプッシュ通知 | CRM | 3人日 | Must | 要望1（予告バナー）とセットで運用しないと「下がる予告はあるが上がった通知はない」という体験の非対称が生まれ、CRM部門の別クレームを誘発する |
| 4 | 適用漏れFAQ自動表示 | CS | 3人日 | Should | 現状も人力対応という次善策があるため致命傷ではないが、Must3件のリリースで問い合わせ増加が見込まれるため同時に入れたい |
| 6 | ランク別クーポン自動発行バッチ化 | マーケ | 7人日 | Should | 現状も手動発行で運用継続できている。ただし手動運用のミス率・工数負担が既に問題化しており次サイクル最優先候補 |
| 3 | 進捗バービジュアル刷新 | デザイン | 4人日 | Should | UX改善効果はあるが、現行UIでも情報は伝わっており運用が止まるわけではない |
| 9 | 会員一覧CSV出力 | CS/オペ | 2人日 | Could | あれば運用が楽になるが、現状も個別に管理画面から確認できているため優先度は低い |
| 5 | 見直しサイクルの四半期化 | 経営企画 | 8人日 | Could | 工数が大きい割に、今すぐ変えないと事業が止まるわけではない。次々回以降で仕切り直す |
| 7 | SNSシェア機能 | マーケ | 5人日 | Won't（今回） | 効果検証されていない新機能追加であり、Must/Shouldの解決を優先すべき局面ではない。次期バックログ候補として保留 |
キャパシティ突き合わせ
| 項目 | 工数 |
|---|---|
| Must合計（1+2+8） | 14人日 |
| Should合計（4+6+3） | 14人日 |
| Must+Should合計 | 28人日 |
| 実キャパシティ | 30人日 |
| バッファ | 2人日（意図的に残す） |
| Could（5, 9）・Won't（7） | 今回のサイクルでは着手しない |
対立の裁定メモ（CRM部門長 vs マーケティング部門長）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 声の大きい部門の要望を無条件でMustにする | 裁定基準がないため、次の対立でも同じ揉め方を繰り返す。他部門からの不公平感も生む | 「社外コミットメントの有無」等、再現可能な裁定軸を先に決めてから当てはめる |
| MustとShouldの合計をキャパシティぴったりに組む | 見積もりが少しでもずれると即座にスケジュール破綻する | 意図的に数人日のバッファを残す |
| Won'tに分類した要望を要望元に説明せず放置する | 「無視された」と受け取られ、次回以降の協力関係が悪化する | 見送り理由を一言添えて伝え、次サイクルの候補として扱う |
🏆 実務での使いどころ
MoSCoWはスプリント計画やリリース計画の直前、複数部門から要望が集中するタイミングで最も効果を発揮します。特にエンジニアがこの分類作業に関わると、「なぜこの機能が今回は入らないのか」を技術的な工数根拠とともに説明でき、PdMだけで裁定するよりも部門側の納得感が高まります。対立する要望の裁定は本来PdMやPMの役割ですが、キャパシティの妥当性（工数見積もりの根拠）を握っているのはエンジニア側であることが多く、両者が共同で裁定メモを作る形が実務では機能しやすいです。
🚀 次のステップ
今回はMust/Should/Could/Wontという4区分の粗い分類でした。次はテーマ5-2「Value vs Effortマトリクス」で、同じバックログを「価値」と「工数」の2軸でプロットし、MoSCoWでは見えなかった「工数は小さいのに価値が高い（クイックウィン）」項目がないか探ってみましょう。今回Shouldに分類した要望4（FAQ自動表示、3人日）などが該当候補になるかもしれません。