🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは、会員が保有ポイントと保有クーポンを一画面で確認・利用できる「ポイント・クーポン統合管理画面」の開発チームでもある。次の3週間スプリントで着手するスコープを決めるプランニングMTGが来週開催される。
直近2週間で、複数部門から改修要望が集中して届いた。
- セキュリティチーム: 外部の脆弱性診断で「クーポンコード入力欄にレート制限がなく、総当たり攻撃で有効なコードを推測できる」という指摘を受けた（CVSS 7.5相当）。診断報告書には「次回リリースでの是正」が明記されている。
- 法務部門: 外部監査で、現在のポイント有効期限表示が資金決済法の表示義務を満たしていないと指摘された。是正期限は来月末。
- CS部門: CS部長から「ポイント利用履歴の検索・フィルタ機能を最優先にしてほしい」と強い要望。月間のポイント関連問い合わせ180件のうち62%（約112件）が「いつ・どこでポイントを使ったか分からない」という内容で、CS対応工数は月換算で約20時間相当と算出済み。
- マーケティング部門: マーケ部長から「期間限定ポイント2倍キャンペーンのセグメント配信設定機能を今期の売上目標達成に必須なので最優先にしてほしい」と強い要望。ただし効果は仮説段階で、A/Bテスト等の検証はまだ行っていない。
- 開発チーム内: 旧ポイントAPIの非推奨化対応（技術負債）。将来の保守コスト削減にはなるが、緊急性はない。
- 経営層: 次期事業計画で「他社ポイントとの相互交換機能」を新規事業として検討中という構想があるが、提携先も仕様も未確定。
- CS部門（2件目）: 退会時のポイント失効について、事前に通知メールを自動送信してほしいという要望。CS問い合わせの減少が見込まれるが、定量的な効果はまだ測定できていない。
- デザインチーム: ウォレット画面のビジュアル全面リニューアル。ブランドガイドライン刷新に伴う提案だが、事業インパクトの試算はまだない。
開発体制はエンジニア2名、3週間スプリント。通常の保守・問い合わせ対応に稼働の40%を確保する必要があり、新機能開発に充てられる実工数は概算で24人日と算出されている。
💬
プロダクトオーナー「来週のプランニングMTGでバックログをMust/Should/Could/Won'tに分類して持ってきてほしい。特にCS部長とマーケ部長がそれぞれ『自分の要望を最優先にしてほしい』と言っていて、両方は工数的に収まらないのは分かっている。板挟みにならないように、判断基準を明確にして両部門に説明できるようにしておいて」
📝 課題
あなたのタスク: 上記8件の要望を整理し、MoSCoW法（Must/Should/Could/Won't）で分類したバックログ表を作成してください。各要望に概算工数（人日）を見積もった上で、Must+Should の合計が新機能開発の実工数24人日に収まるように分類してください。特に、CS部長（ポイント利用履歴検索機能）とマーケ部長（キャンペーン配信設定機能）の要望が同時にはShouldに収まらない場合、どちらを優先しどちらを見送るかを、声の大きさではなく判断基準に基づいて決め、両部長にそれぞれ何と説明するかまで書いてください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 今回もセキュリティ脆弱性と法定対応期限という、性質の異なる2種類の「客観的なMust根拠」が混在している
- CS部長とマーケ部長の要望は、どちらも「部長が最優先と言っている」という点では同格に見える。声の大きさで判断せず、それぞれの要望が「定量的な実績データに基づく要望」か「まだ検証されていない仮説」かを見極める
- 見送った側の要望には、「今回はやらない」で終わらせず、「どうすれば次回優先度を上げられるか」の条件（例: 小規模検証の実施）を示す
- 見送りを伝える相手が社内の部長職であることを踏まえ、感情的な反発を避けるための説明の順序（先に判断基準を共有してから結論を伝える等）も意識する
- 経営層の要望（他社ポイント相互交換）は「声の大きさ」では上位に見えるが、提携先・仕様が未確定という着手可能性の問題をどう扱うか
📚 背景知識・用語解説
MoSCoW法とは、要求・機能を4段階の優先度に分類する手法です。
- Must（必須）: これがないとリリースの意味がない、またはやらないとリスクが顕在化するもの
- Should（重要）: 重要だが、今回のリリースになくても致命的ではないもの。定量的な業務インパクトがあるものが該当しやすい
- Could（あれば良い）: 実施できれば価値があるが、優先度は相対的に低い。キャパシティに余裕がある場合にのみ着手する
- Won't（今回は実施しない）: 今回のスコープには含めないと明示的に決めたもの。「今回は」という時間軸付きの判断
💡
部門長同士が対等な発言力で対立するケースの裁定: 今回の核心は、CS部長もマーケ部長も、どちらも組織上の発言力を持ち、それぞれ「自分の要望が最優先」と主張している状況をどう裁くかです。役職の強さや主張の熱量、あるいは「先に頼んできた方」といった非本質的な基準で決めてしまうと、負けた側の部門との信頼関係を損ないます。ここで有効なのが要望を支える根拠の性質を揃えて比較するアプローチです。CS部長の要望は「月180件中112件・約20時間相当」という既に発生している実績データに基づく一方、マーケ部長の要望は効果検証を経ていない仮説段階です。この違いは「どちらの部長が重要か」ではなく「どちらの要望がより確からしい根拠を持っているか」という、MoSCoW本来の判断軸に沿った比較です。
見送りの伝え方: 「今回はやらない」とだけ伝えると、見送られた部門は「軽視された」と受け取りがちです。「小規模なA/Bテストを実施して効果を定量的に示せれば、次のスプリントで優先的に検討する」のように、再提案の条件を明示することで、判断基準の一貫性を保ったまま関係を維持できます。
✅ 模範解答
📄
ポイント・クーポン統合管理画面 改修バックログ — MoSCoW分類（次期3週間スプリント）
バックログ一覧と工数見積もり
| ID | 要望内容 | 起票部門 | 背景・理由 | 概算工数 |
|---|---|---|---|---|
| P1 | クーポンコードのレート制限実装 | セキュリティ | 外部脆弱性診断でCVSS7.5相当の指摘。報告書で次回リリースでの是正が明記 | 6人日 |
| P2 | ポイント有効期限表示の是正 | 法務 | 資金決済法の表示義務違反を外部監査で指摘。是正期限は来月末 | 5人日 |
| P3 | ポイント利用履歴の検索・フィルタ機能 | CS | 月180件中112件（62%）が履歴不明の問い合わせ。CS対応工数月20時間相当 | 6人日 |
| P4 | ポイント2倍キャンペーンのセグメント配信設定 | マーケ | 今期売上目標達成に必須と主張。効果検証は未実施の仮説段階 | 7人日 |
| P5 | ウォレット画面のビジュアル全面リニューアル | デザイン | ブランドガイドライン刷新に伴う提案。事業インパクト試算なし | 10人日 |
| P6 | 旧ポイントAPIの非推奨化対応 | 開発チーム内 | 技術負債の解消。将来の保守コスト削減、緊急性なし | 4人日 |
| P7 | 他社ポイント相互交換機能の新設 | 経営層 | 次期事業計画の新規事業構想。提携先・仕様ともに未確定 | 20人日（概算） |
| P8 | 退会時ポイント失効の事前通知メール自動化 | CS | 問い合わせ減少見込みだが定量効果は未測定 | 4人日 |
MoSCoW分類
| 分類 | ID | 要望内容 | 工数 | 分類理由 |
|---|---|---|---|---|
| Must | P1 | クーポンコードのレート制限実装 | 6人日 | 外部診断で悪用可能性（CVSS7.5）が指摘済みのセキュリティリスク。放置するとクーポン不正利用による実害に直結する |
| Must | P2 | ポイント有効期限表示の是正 | 5人日 | 資金決済法の表示義務違反という法定リスク。是正期限があり、対応しないと法令違反が継続する義務ベースの根拠 |
| Should | P3 | ポイント利用履歴の検索・フィルタ機能 | 6人日 | 月112件・月20時間相当という既に発生している実績データに基づく要望。マーケ部長のP4と比較し、根拠の確からしさで優先 |
| Should | P8 | 退会時ポイント失効の事前通知メール自動化 | 4人日 | 工数が軽く残キャパシティに収まる。定量効果は未測定だが、退会という不可逆な事象への事前通知はCSトラブル予防として妥当性が高い |
| Could（見送り） | P4 | キャンペーンセグメント配信設定 | 7人日 | 残キャパシティ3人日（24−21）には収まらない。加えて効果が仮説段階であり、実績データを持つP3より確からしさで劣る。小規模A/Bテストで効果を示せれば次スプリントで最優先候補とする |
| Could（見送り） | P6 | 旧ポイントAPIの非推奨化対応 | 4人日 | 残キャパシティ3人日には収まらない。緊急性がないため次スプリント以降への繰越候補とする |
| Won't（今回） | P5 | ビジュアル全面リニューアル | 10人日 | 事業インパクトの試算がない状態で10人日を投じる判断はできない。試算とセットでの再提案を求める |
| Won't（今回） | P7 | 他社ポイント相互交換機能 | 20人日（概算） | 提携先・仕様ともに未確定でスコープ化できる段階にない。提携交渉が具体化し仕様が確定した時点で改めて工数を見積もる |
キャパシティ突き合わせ
| 項目 | 工数 |
|---|---|
| Must合計（P1+P2） | 11人日 |
| Should合計（P3+P8） | 10人日 |
| Must+Should合計 | 21人日 |
| 新機能開発の実キャパシティ | 24人日 |
| 残枠 | 3人日 |
| Could採用分 | 0人日（P4・P6ともに3人日の残枠に収まらないため今回は見送り） |
| 最終消化予定 | 21人日（キャパシティ内、バッファ3人日を保持） |
両部長への説明メモ
| 相手 | 伝える内容 |
|---|---|
| CS部長 | 「ポイント利用履歴の検索機能はShouldとして今回のスプリントで着手します。月112件・約20時間相当という実績データに基づく判断です」 |
| マーケ部長 | 「キャンペーン配信設定機能は工数と実キャパシティの都合で今回は見送ります。理由は声の大きさではなく、CS側の要望が実績データに基づく一方、こちらはまだ効果検証前の仮説段階だからです。小規模なA/Bテストで効果を数値で示していただければ、次スプリントで最優先候補として扱います」 |
💡 なぜこう作るのか
1
Must をP1（セキュリティ）とP2（法務）に絞った理由は、リスクベース（悪用されたら実害）と義務ベース（期限までにやらないと違反）という性質の異なる2種類の客観的根拠を区別して説明できるようにするため。
2
今回の分類の核心は、CS部長とマーケ部長という対等な発言力を持つ2人の対立をどう裁くかという点にある。両者とも「最優先にしてほしい」と主張する状況で、役職の強さや主張の熱量ではなく、「要望の裏付けが実績データか、未検証の仮説か」という一段階客観的な基準に置き換えたことで、判断の一貫性を保った。
3
P8（退会時通知）をP4より先にShouldへ入れたのは、工数の小ささだけでなく、不可逆な事象（退会）に対する事前通知という性質上、後から取り返しがつかないケースへの予防効果を重視したため。P4は今回見送っても後日再提案できるが、P8を見送って退会トラブルが起きた場合の説明責任の方が重いと判断した。
4
P4を単純にWon'tにせず「Could（見送り）」とし、かつ小規模A/Bテストという具体的な再提案条件を付けたのは、マーケ部長との関係を維持しながら、次に判断材料が揃ったときにスムーズに優先度を上げられるようにするため。
5
残キャパシティ3人日をあえて使い切らず、CouldのP4・P6をどちらも見送ったのは、3週間という短いスプリントで見積もり誤差が発生しやすいことを踏まえ、Must+Shouldの実行に集中するバッファを残す判断。
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 部門長同士の対立を「声が大きい方」「役職が上の方」で決める | 判断基準が属人的になり、負けた側との信頼関係を損なう。次回また同じ対立が再燃する | 「実績データに基づく要望か、未検証の仮説か」のように、双方に適用できる客観的な基準を先に決めてから個別要望を当てはめる |
| 見送りを「今回はやりません」とだけ伝える | 見送られた部門が「軽視された」と受け取り、次回以降の協力関係が悪化する | 再提案の具体的な条件（小規模検証の実施等）を明示し、「今回は」という時間軸と「次はこうすれば」という道筋をセットで伝える |
| 工数の小ささだけでShould/Couldの順序を決める | P8のように定量効果が未測定でも重要度が高いケース（不可逆な事象への対応）を軽視してしまう | 工数の大小だけでなく、見送った場合の後戻りしにくさ・説明責任の重さも判断材料に加える |
| 残キャパシティを無理に使い切ろうとする | 見積もり誤差やMust/Shouldの遅延リスクを吸収するバッファがなくなり、結果的に全体が遅延する | 短いスプリントほど一定のバッファ（未着手の残枠）を意図的に残す判断も選択肢に入れる |
🏆 実務での使いどころ
MoSCoW法は、単一部門からの要望整理だけでなく、複数の部門長が対等な立場で「自分の要望が最優先」と主張し合う場面でこそ真価を発揮します。声の大きさや役職の強さで決めてしまうと、その場は収まっても長期的な信頼関係を損ないます。今回のように「実績データに基づく要望か、未検証の仮説か」という一段階抽象化した基準に置き換えることで、どちらの部長にも筋の通った説明ができます。エンジニアからPdM/PM方向を目指す場合、この種の板挟み状況を「判断基準を先に共有し、それに沿って結論を出す」という手順で乗り切れるようになることが、部門横断の調整役としての信頼につながります。
🚀 次のステップ
今回はShould内での2部門対立を扱いましたが、次はテーマ5-2「Value vs Effortマトリクス」で、P4（キャンペーン配信、価値は仮説段階）とP6（技術負債、価値は将来の保守コスト削減）のような「価値の種類が異なるCould候補」を、MoSCoWより連続的な2軸でどう配置し直せるか練習してみましょう。