🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは、社内の「販促バナー管理システム」を保守・改修している。四半期末に近づき、次の8週間スプリントで着手する開発スコープを決めるプランニングMTGが来週に控えている。
この2週間で、複数部門からバナー管理システムへの要望が立て続けに届いた。
- 法務部門: 先月の社内監査で「掲載期限が切れたバナーが自動的に非表示にならず、実際に3件、期限切れ後も表示され続けていた」ことが指摘された。来月の内部監査フォローアップで是正状況の報告が必須になっている。あわせて「バナー掲載前に法務承認を必須化するワークフロー」も再発防止策として求められている。
- インフラチーム: 直近2週間でバナー掲載ページの表示速度アラートが3回発生した。原因調査の結果、同時掲載バナー数に上限がなく、掲載数が増えるとページ表示が遅延することが判明した。
- マーケティング運用チーム: バナー登録が1件ずつの手動作業で、月20時間相当かかっている。繁忙期（セール前）には登録漏れも発生している。クリック率の集計も毎月Excelで手動集計しており、月3時間かかっている。スマホ/PC別にバナーを出し分けたい要望もあるが、これは「CVR改善仮説」の域を出ておらず効果は未検証。
- デザインチーム: バナー管理画面のダークモード対応を要望しているが、業務への影響は軽微。
- CS部門: 問い合わせ対応で過去に掲載していたバナーの内容を確認したいケースが月数件ある。現状は過去バナーを検索する手段がない。
- 営業部門: 外部パートナー企業向けにバナー掲載を提案したいとして掲載申請フォームを要望しているが、現時点で具体的な引き合いはまだゼロ件。
- マーケティング部門（野心枠）: クリック率データをもとにバナー表示順を自動最適化する機能を提案しているが、前提となるクリックデータの蓄積とアルゴリズム検証がこれから必要な段階。
開発体制はエンジニア2名、8週間のスプリント。ただし通常の保守・軽微な問い合わせ対応に稼働の40%を確保する必要があり、新機能開発に充てられる実工数は概算で30人日と算出されている。
📝 課題
あなたのタスク: 上記10件の要望を整理し、MoSCoW法（Must/Should/Could/Won't）で分類したバックログ表を作成してください。各要望に概算工数（人日）を見積もった上で、Must+Should の合計が新機能開発の実工数30人日に収まるように分類し、Couldに分類した項目については「実工数の残り枠に対して、なぜその項目を選び、なぜ別の項目を見送ったか」まで説明してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- MoSCoWの分類基準は「重要度」だけでなく「今回のリリースでやる/やらないの線引き」であることを意識する。Couldは「余裕があればやる」であって「やらなくていい」ではない
- Mustの基準を「コンプライアンス・障害リスクなど、やらないと事業・法務リスクが顕在化するもの」に絞ると判断がぶれにくい。「あった方がいい」レベルのものをMustに入れると、Mustが際限なく膨らむ
- Shouldは「定量的な業務インパクトが説明できるもの」を基準にすると、Couldとの線引きがしやすい（工数削減時間、機会損失額など、数値で語れるかどうか）
- MoSCoWは分類して終わりではない。Must+Shouldの合計工数が実際のキャパシティに収まっているかを必ず突き合わせる。収まらなければ、Should→Couldへの格下げも検討する
- Won'tは「永遠にやらない」ではなく「今回のスコープではやらない」。理由（データ不足、需要未確認など）を明記すると、後で再提案された時に判断基準として再利用できる
📚 背景知識・用語解説
MoSCoW法とは、要求・機能を4段階の優先度に分類する手法です。
- Must（必須）: これがないとリリースの意味がない、またはやらないとリスクが顕在化するもの
- Should（重要）: 重要だが、今回のリリースになくても致命的ではないもの。定量的な業務インパクトがあるものが該当しやすい
- Could（あれば良い）: 実施できれば価値があるが、優先度は相対的に低い。キャパシティに余裕がある場合にのみ着手する
- Won't（今回は実施しない）: 今回のスコープには含めないと明示的に決めたもの。将来やらないという意味ではなく、「今回は」という時間軸付きの判断
もう一つ重要なのが、MoSCoWは工数キャパシティとセットで運用するという点です。分類だけして「Must+Shouldの合計が実際に開発チームがこなせる量を超えている」状態のままプランニングMTGに持っていくと、結局その場で優先順位の再議論が発生します。分類の時点で、見積もり工数とチームの実稼働キャパシティを突き合わせておくことで、会議の場では「なぜこの線引きにしたか」の議論に集中できます。
✅ 模範解答
バックログ一覧と工数見積もり
| ID | 要望内容 | 起票部門 | 背景・理由 | 概算工数 |
|---|---|---|---|---|
| B1 | 期限切れバナーの自動非表示 | 法務 | 内部監査での指摘事項。来月のフォローアップ監査で是正状況の報告が必須 | 3人日 |
| B2 | バナー掲載審査ワークフロー（法務承認必須化） | 法務 | B1と同じ監査指摘に対する再発防止策として要求 | 5人日 |
| B3 | 同時掲載バナー数の上限アラート | インフラ | 直近2週間で表示速度アラートが3回発生。放置するとページ全体の表示遅延に波及するリスク | 2人日 |
| B4 | バナーCSV一括アップロード | マーケ運用 | 手動登録工数が月20時間相当。繁忙期に登録漏れも発生 | 4人日 |
| B5 | クリック率ダッシュボード | マーケ | 月次Excel手動集計に月3時間。リアルタイム把握ができず機会損失の可能性 | 4人日 |
| B6 | スマホ/PC別バナー個別設定 | マーケ | CVR改善仮説あり。ただし効果は未検証 | 6人日 |
| B7 | バナー管理画面のダークモード対応 | デザイン | 運用担当からの要望。業務影響は軽微 | 5人日 |
| B8 | 過去バナーのアーカイブ検索機能 | CS | 問い合わせ対応で過去バナー内容を確認したいケースが月数件 | 3人日 |
| B9 | クリック率ベースのバナー表示順自動最適化 | マーケ | 野心的だが、前提となるクリックデータの蓄積・アルゴリズム検証がこれから必要 | 10人日 |
| B10 | 外部パートナー向け掲載申請フォーム | 営業 | 新規要望だが、現時点で具体的な引き合いはゼロ件 | 6人日 |
MoSCoW分類
| 分類 | ID | 要望内容 | 工数 | 分類理由 |
|---|---|---|---|---|
| Must | B1 | 期限切れバナーの自動非表示 | 3人日 | 監査指摘事項であり、来月のフォローアップ監査までに是正報告が必須。やらないとコンプライアンス上のリスクが顕在化する |
| Must | B2 | バナー掲載審査ワークフロー | 5人日 | B1と同一の監査指摘に対する再発防止策。監査対応として一体で報告する必要があり、B1と切り離せない |
| Must | B3 | 同時掲載バナー数の上限アラート | 2人日 | 直近で実際に障害の予兆（表示速度アラート3回）が出ており、放置するとシステム障害に発展するリスクがある |
| Should | B4 | バナーCSV一括アップロード | 4人日 | 月20時間の工数削減効果が定量的に説明できる。繁忙期の登録漏れという業務リスクも解消する |
| Should | B5 | クリック率ダッシュボード | 4人日 | 月3時間の集計工数削減に加え、リアルタイム把握できないことによる機会損失という定量的な裏付けがある |
| Should | B6 | スマホ/PC別バナー個別設定 | 6人日 | CVR改善仮説自体はマーケティング上の重要性が高いが、効果が未検証なため確度はB4・B5よりやや落ちる。それでも合計工数（Must+Should=24人日）がキャパシティ30人日に収まる範囲であれば採用する |
| Could（採用） | B8 | 過去バナーのアーカイブ検索機能 | 3人日 | 残キャパシティ6人日（30−24）に対して、CS部門から実際の利用ニーズ（月数件の問い合わせ対応）が確認できているため優先して採用 |
| Could（見送り） | B7 | ダークモード対応 | 5人日 | 残キャパシティ6人日のうちB8（3人日）を採用すると残り3人日となり、B7（5人日）は収まらない。業務影響も軽微なため、次回リリース以降のCould候補として持ち越す |
| Won't（今回） | B9 | バナー表示順自動最適化 | 10人日 | 前提となるクリックデータの蓄積・アルゴリズム検証が終わっていない段階で着手すると手戻りリスクが高い。データ蓄積後に改めて提案してもらう |
| Won't（今回） | B10 | 外部パートナー向け掲載申請フォーム | 6人日 | 具体的な引き合いがゼロ件の段階で開発するのは投機的すぎる。実際の引き合いが1件でも確定した時点で再検討する |
キャパシティ突き合わせ
| 項目 | 工数 |
|---|---|
| Must合計（B1+B2+B3） | 10人日 |
| Should合計（B4+B5+B6） | 14人日 |
| Must+Should合計 | 24人日 |
| 新機能開発の実キャパシティ | 30人日 |
| 残枠 | 6人日 |
| Could採用分（B8） | 3人日 |
| 最終消化予定 | 27人日（キャパシティ内） |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 声の大きい部門の要望を無条件でMustにする | Mustの基準が曖昧になり、結局すべてが「必須」になって優先順位付けが機能しなくなる | Mustの基準を「客観的な期限・リスクの裏付けがあるか」に固定し、要望元の部門の影響力で判断しない |
| 工数見積もりをせずに分類だけ行う | Must+Shouldの合計が実際のキャパシティを超えていることに気づかず、プランニングMTGで手戻りが発生する | 分類と同時に概算工数を見積もり、必ずキャパシティとの突き合わせを行う |
| Won'tを「永遠にやらない」という否定的な扱いにする | 要望元の部門との関係が悪化し、次回以降の要望のヒアリングがしにくくなる | Won'tには「今回はやらない理由」と「再提案の条件」をセットで明記し、時間軸付きの判断であることを伝える |
| Couldの選定を工数の小ささだけで決める | 実際の利用ニーズが薄い項目を優先してしまい、限られた開発余力を使い切ってしまう | Couldの中でも「実際の利用ニーズ・裏付けの有無」を比較し、工数だけでなく価値の確からしさで選ぶ |
🏆 実務での使いどころ
MoSCoW法は、複数部門から同時多発的に要望が届き、かつ開発リソースが限られている状況で特に効果を発揮します。今回のシナリオのように、法務（コンプライアンス）・インフラ（障害リスク）・マーケ（業務効率・売上）・デザイン・CS・営業といった異なる部門の要望を同じ土俵で比較するには、「重要度」という主観的な物差しだけでなく、Mustの基準を客観的なリスク・期限に固定することが合意形成の鍵になります。また、キャパシティとの突き合わせまで行っておくことで、プランニングMTGでの議論を「分類は妥当か」ではなく「このキャパシティの前提自体が正しいか」というより本質的な論点に集中させることができます。エンジニアからPdM/PM方向を目指す場合、自分たちのチームの開発キャパシティを定量的に把握し、それを優先順位付けの判断材料として持ち込めることは大きな強みになります。
🚀 次のステップ
今回はMoSCoWという4段階の分類を使いましたが、次はテーマ5-2「Value vs Effortマトリクス」で、価値（インパクト）と工数（Effort）の2軸を使い、B4〜B8のようなShould/Could候補をより連続的な尺度で比較する練習をしてみましょう。特にB6（スマホ/PC別設定、価値は仮説段階）とB8（アーカイブ検索、価値は小さいが確実）のような「価値の確からしさが異なる項目」をどう2軸上に配置するかは、MoSCoWだけでは表現しきれない判断の練習になります。