🎬 シナリオ
MOpsチームでは、ECサイトの「返品・交換申請フォーム」（マイページから返品・交換を申請する画面）の改修を検討している。きっかけは2つある。
1つは、直近3ヶ月の返品関連CS問い合わせが月平均450件あり、そのうち約35%（約158件）が「返品期限がいつまでか分からない」という問い合わせであること。もう1つは、消費者庁が通信販売の返品ルール表示（返品可能期間・返品送料の負担者の明示）に関するガイドラインの運用を強化する方針を打ち出し、同業のEC事業者数社が既に指導を受けた事例が業界内で共有されたこと。法務部門はこれを受けて「行政指導が入るのは時間の問題」と社内に警鐘を鳴らしている。
各部門から改修要望が8件バックログに積まれており、あなたは次のスプリント（3週間・実キャパシティ20人日）に収まる形でMoSCoW分類を行う役目を任された。バックログは以下の通り。
| # | 要望内容 | 出所部門 | 工数見積 |
|---|---|---|---|
| 1 | 商品ページ・返品申請フォームへの「返品可能期間」「返品送料の負担者」の明示表示 | 法務部門 | 4人日 |
| 2 | 返品申請フォームに「返品期限まで残り◯日」のカウントダウン表示 | CS部門 | 3人日 |
| 3 | 返品理由の選択肢（現行7種）に自由記述欄を併設し分析精度を上げる | マーケティング部門 | 3人日 |
| 4 | 返品受付後の着払い伝票（返送ラベル）の自動発行（現状は手作業でPDF発行） | 物流部門 | 6人日 |
| 5 | 返品ステータスのマイページでのリアルタイム追跡表示（配送業者API連携） | CS部門 | 8人日 |
| 6 | 返品申請フォームのUIリニューアル（既存デザインシステムへの統一） | デザイン部門 | 4人日 |
| 7 | 交換（同一商品の色・サイズ違い）申請時の在庫連動チェック追加 | 物流部門 | 5人日 |
| 8 | 返品理由データの月次自動集計ダッシュボード | マーケティング部門 | 4人日 |
バックログ合計は37人日。実キャパシティ20人日には収まらないため、大胆に絞り込む必要がある。
さらに、法務部門長と物流部門長がそれぞれ「自分の要望こそ最優先」と主張して対立している。
両者とも役員クラスへの説明責任を持ち、社内での発言力は同等。あなたはPdM/エンジニアとして、両者の主張に優劣をつけて全体のMoSCoW分類を確定させる必要がある。
📝 課題
あなたのタスク: 上記8件のバックログをMust/Should/Could/Won'tに分類し、実キャパシティ20人日に収まる形で優先順位表を作成してください。さらに、法務部門長と物流部門長の対立を裁定する基準を明示し、その基準に沿ってどちらを優先するか（または両方をどう扱うか）を1つの意思決定メモとして書いてください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 前回（Day026）のMoSCoW演習では対立を「両方Must」に落とし込んだ。今回も同じ結論に逃げ込む前に、「Mustにするしかない理由」と「Shouldに留められる理由」の違いを一度立ち止まって考える
- MoSCoW公式定義でのShouldは「重要だが、次善策（回避策）が存在する」もの。「次善策が存在するかどうか」を対立裁定の軸にできないか検討する
- 法令・規制対応と、金額換算できる内部コスト（オペレーション工数）は、どちらも「損失」だが性質が違う。後戻りできるかどうかで扱いを変える
- 物流部門長の要望を退ける場合、「今回はやりません」だけで終えると次のスプリントまで月107時間の手作業が続く。何らかの一時しのぎ（暫定策）を用意できないか考える
- キャパシティに対してMust+Should+Coreがぴったり収まるのではなく、多少バッファを残す
📚 背景知識・用語解説
MoSCoW法とは、要求・機能を以下の4区分に分類する優先順位付け手法です。
- Must have: これがないとリリース・運用が成立しない。やらない場合の損失が具体的で大きく、次善策（回避策）が存在しないもの
- Should have: 重要だが、なくても致命傷にはならない。次善策が存在する（時間はかかる・非効率だが、別の方法で当面をしのげる）
- Could have: あれば望ましいが、優先度は低い。工数に余裕があれば着手
- Won't have（this time）: 今回のスコープでは意図的にやらない。「永久にやらない」ではなく「今回のサイクルでは」という時限を明示する
MoSCoWが機能不全を起こす典型パターンは、「発言力の強い部門の要望が全部Mustになる」ことです。これを防ぐ実務的な裁定軸の1つが、「対応しない場合の損失が、後戻り不能な外部リスク（法令違反・行政指導・レピュテーション毀損）か、金額換算できる内部コスト（オペレーション工数・人件費）か」という切り口です。
前者（法令・規制対応）は、時間をお金で買う・人を増やすといった代替手段が原理的に効かないタイプの損失です。表示を出さないこと自体が違反であり、「表示を出さずに他の方法で乗り切る」という次善策が存在しません。そのため、工数の大小にかかわらずMustになります。
後者（オペレーションコスト）は、金額に換算できる分だけ「一時的に人を増やす」「手作業のまま我慢する」「簡易的な効率化で当面をしのぐ」といった次善策を設計できる余地があります。次善策が用意できるのであれば、MoSCoWの定義上はShouldに留めるのが筋が通っています。ただし「Shouldだから後回し」で終わらせず、次善策そのものを今スプリントの中に小さなタスクとして組み込むのが、要望元との関係を壊さないための実務上の工夫です。
✅ 模範解答
MoSCoW優先順位表
| # | 要望内容 | 出所部門 | 工数 | 分類 | 分類理由 |
|---|---|---|---|---|---|
| 1 | 返品可能期間・送料負担の明示表示 | 法務 | 4人日 | Must | 行政指導リスクという後戻り不能な外部リスク。表示しないこと自体が問題であり、代替手段（次善策）が存在しない |
| 2 | 返品期限カウントダウン表示 | CS | 3人日 | Must | 要望1と同じ画面・同じデータ（返品期限）を扱う。要望1だけ実装すると中途半端な表示になり、CS問い合わせ158件/月の主因を放置することになる。同時実装が合理的 |
| 4 | 返送ラベル自動発行 | 物流 | 6人日 | Should | 月107時間という金額換算できる内部コスト。「CSV一括出力での暫定効率化」という次善策が設計できるため、フル自動化は次善策を挟んだ上でShouldに留める |
| — | （暫定策）返送ラベルのCSV一括出力機能（複数件まとめてPDF一括生成） | 物流 | 1人日 | Should（今スプリント内） | フル自動化を待たずに導入できる小さな効率化。1件8分→約3分程度に短縮見込み |
| 6 | UIリニューアル | デザイン | 4人日 | Could | Must/Shouldで発生する画面変更と足並みを揃えて一度に直すのが効率的。ただし現行UIでも機能は成立しており、今回落としても運用は止まらない |
| 3 | 返品理由の自由記述欄併設 | マーケ | 3人日 | Won't（今回） | 分析精度向上という便益はあるが、緊急性のある損失が発生していない。次期バックログ候補として保留 |
| 7 | 交換の在庫連動チェック | 物流 | 5人日 | Won't（今回） | 在庫不整合による事故は現状報告されておらず、仮説段階。定量的な損失が未確認のため今回は見送り |
| 8 | 月次自動集計ダッシュボード | マーケ | 4人日 | Won't（今回） | 現状も手動集計で運用継続できている。要望3と合わせて次期以降にまとめて着手する方が手戻りが少ない |
| 5 | リアルタイム追跡表示（配送業者API連携） | CS | 8人日 | Won't（今回） | バックログ中最大の工数でありながら、緊急性のある損失（行政指導・大規模な工数超過）が存在しない。Must/Shouldを実現した後の次々期候補 |
キャパシティ突き合わせ
| 項目 | 工数 |
|---|---|
| Must合計（1, 2） | 7人日 |
| Should合計（4, 暫定CSV出力） | 7人日 |
| Must+Should合計 | 14人日 |
| Could（6） | 4人日 |
| Must+Should+Could合計 | 18人日 |
| 実キャパシティ | 20人日 |
| バッファ | 2人日（意図的に残す） |
| Won't（3, 5, 7, 8） | 今回のサイクルでは着手しない（合計20人日相当） |
対立の裁定メモ（法務部門長 vs 物流部門長）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 対立が起きるたびに「両方Must」で丸く収める | 一見公平だが、次にキャパシティを超える対立が起きたときに使える判断基準が育たない。Mustの定義自体が形骸化する | 「次善策の有無」「後戻り可能かどうか」等、状況に応じた裁定軸を都度明示し、白黒つける勇気を持つ |
| Shouldに落とした要望を「今回は無理」とだけ伝える | 要望元は「軽視された」と受け取り、次回の協力が得にくくなる。107時間/月のような実害は放置され続ける | 次善策（暫定策）を小さなタスクとして今スプリントに組み込み、「先送り」ではなく「橋渡し」として伝える |
| 法令対応の工数が小さいことを理由に後回しにする | 工数の大小と損失の重大性は無関係。行政指導やレピュテーション毀損は事後対応コストがはるかに大きい | 損失の性質（後戻り可能か）で判断し、工数の大小をMust判定の基準にしない |
🏆 実務での使いどころ
MoSCoWは、複数部門から要望が集中し、かつ発言力が拮抗する対立が起きたときに最も試されます。今回のように「法令対応」と「オペレーションコスト」という異なる種類の損失が同時に提示された場合、単純な工数比較や役職の重さでは裁定できません。エンジニアがこの裁定に加わる価値は、暫定策（CSV一括出力のような小さな効率化）の実現可能性と工数を即座に判断できる点にあります。PdMだけで「Shouldです」と伝えるよりも、エンジニアが「1人日でここまでの緩和ができます」という具体案を添えることで、要望元の納得感が大きく変わります。
🚀 次のステップ
今回はMust/Should/Could/Wontという4区分の粗い分類に、「次善策の有無」という裁定軸を1つ加えた程度でした。次はテーマ5-2「Value vs Effortマトリクス」で、同じバックログを価値と工数の2軸に配置し、MoSCoWでは「Won't」に分類した要望5（リアルタイム追跡表示、8人日）が、実は価値も高いが工数も飛び抜けて大きいだけなのか、それとも本当に優先度が低いのかを可視化してみましょう。