MoSCoW（優先順位） フレームワーク

用途

アクションプラン作りでは、やりたいこと・やるべきことが常に資源（人・時間・予算）を上回る。 MoSCoWの狙いは、要件を4つのバケツに分けることで「全部大事」という思考停止を壊し、この期間で必ず届ける最小の約束（Must）と、明示的に見送る対象（Won't）を先に決めきることにある。 特にWon'tを言語化する点が肝で、これがスコープの膨張を止め、締切と品質を守る合意の土台になる。 単なる序列付け（1位2位3位）と違い、区切られた期間・リリース単位に「入れる／入れない」の線を引くのがMoSCoWの本質である。

使い方

1. 1対象範囲と期間を固定する。 『今四半期のリリース』『次の1スプリント』など、優先順位を判断する箱の大きさ（使える工数・予算・締切）を先に決める。 箱が曖昧だと分類も曖昧になる。
2. 2要件・タスクを1枚に洗い出し、各項目をMust（無ければ成立しない）／Should（重要だが代替や先送りが効く）／Could（あれば良い、コスト小なら入れる）／Won't（今回は明示的にやらない）に振り分ける。
3. 3Mustが箱の容量に収まるか工数で検算する。 目安としてMustが全体工数の6割程度に収まらなければ過剰。 Must同士で削り合いか、Shouldへ降格して余白（バッファ）を確保する。
4. 4Won'tに落とした項目に『なぜ今回やらないか／いつ再検討するか』を1行添える。 見送り理由を残すことで、後から蒸し返される差し戻しと合意崩れを防ぐ。
5. 5確定後はロードマップやWBSへ落とし込み、実行中に新規要求が来たら必ず既存項目とのトレードオフ（何をWon'tに落とすか）とセットで判断する。

適用例

B2B向け勤怠管理SaaS（従業員30名の開発会社が運営、月額課金・既存顧客80社）が、次の四半期リリースに向けて機能要望を整理する場面。 開発に割ける工数は2名×3か月＝約120人日。 要望は全9件、見積合計は210人日で容量の1.75倍あり、全部は入らない。 \nMust（必ず出す・合計70人日）：法改正対応の残業上限アラート（30人日）、解約が集中していたスマホ打刻の不具合修正（25人日）、二要素認証（15人日）。 この3件は「無ければ契約更新に響く」ため死守。 \nShould（重要・合計65人日）：CSV一括取込の高速化（35人日）、承認フローの多段化（30人日）。 工数に余裕があれば入れる。 \nCould（あれば良い・合計25人日）：ダッシュボードの配色カスタマイズ（15人日）、通知音の選択（10人日）。 \nWon't（今回見送り・合計50人日）：多言語対応（40人日→海外顧客が現状ゼロのため次期以降）、AI残業予測（10人日→精度検証が未了）。 \n120人日の枠にMust70＋Should35（CSV高速化のみ採用）＝105人日を確定し、残15人日をバッファとして確保。 結果、リリース遅延リスクを抑えつつ、更新率に直結する3機能を確実に届けられた。

よくある誤解・つまずき

• 『Mustを増やせば重要な機能が全部守れる』という誤解。 Mustを積み過ぎると容量を超え、結局どれかが落ちて締切割れを起こす。 Mustは『本当に無ければ成立しない最小限』に絞り、目安として箱の6割程度に収めるからこそ機能する。
• 『Won'tは書かなくても分かる』という油断。 見送りを明文化しないと、実行中に『やっぱりこれも』と割り込みが入り、スコープが静かに膨張して品質と締切が崩れる。 やらないことを合意文書に残すのがMoSCoW最大の効き所。
• MoSCoWで序列は決まるが『どれが儲かるか・効果が大きいか』は測れないという誤解。 分類はあくまで『今回入れる／入れない』の合意であり、投資対効果の定量比較はICEスコアリングやペイオフマトリクスなど別の手法で補う必要がある。

使うタイミング

使うべきなのは、アクションプラン（④）で「使える資源＜やりたいこと」が確定し、期間や締切という箱の大きさが決まった後。 早すぎる失敗は、ビジョン（①）や戦略方針（③）が固まる前に機能単位の優先度を議論してしまうケースで、そもそも何を目指すかがブレていると分類が空中戦になる。 遅すぎる失敗は、実装が走り出してから優先度を付け直そうとするケースで、着手済みの手戻りコストが発生し、Won'tへの降格が政治的に困難になる。 前工程で目的と評価軸を固め、実行に入る直前に線を引くのが最適なタイミング。

関連する用語・フレームワーク