MoSCoW優先順位付けとは？要件の優先度を4段階で整理する手法

MoSCoW優先順位付けとは

MoSCoW優先順位付け（MoSCoW Prioritization）とは、プロジェクトの要件や機能をMust have（必須）、Should have（重要）、Could have（あれば嬉しい）、Won’t have（今回は対象外）の4段階に分類する優先順位付け手法です。ダイ・クレッグが1994年にDSDM（Dynamic Systems Development Method）の一部として考案しました。

名称の「MoSCoW」は、4つのカテゴリの頭文字から来ています。間に挟まれた小文字の「o」は、単に発音しやすくするために加えられたものです。

この手法の最大の特徴は、優先度の議論を「高・中・低」という曖昧な3段階ではなく、具体的な判断基準を持つ4段階に構造化している点です。特に「Won’t have（今回は対象外）」というカテゴリの存在が重要で、これにより「やらないこと」を積極的に定義できます。

構成要素

4つのカテゴリの定義

カテゴリ	定義	判断基準
Must have	なければリリースできない必須要件	法的要件、安全要件、コアビジネス機能、契約上の義務
Should have	重要だがワークアラウンドが存在する要件	ビジネス価値は高いが、代替手段があり遅延しても致命的ではない
Could have	あると良いが、なくても支障がない要件	ユーザー体験の向上、効率化。リソースに余裕がある場合に対応
Won’t have	今回のスコープには含めない要件	将来的には検討するが、今回の制約条件下では対応しない

カテゴリ配分の目安

実務上の指針として、以下の配分比率が推奨されています。

• Must have: 全要件の60%以下
• Should have: 約20%
• Could have: 約20%

Must haveが60%を超える場合、プロジェクトのリスクが高い状態です。ShouldやCouldに分類された要件が、リソース不足やスケジュール遅延時のバッファとして機能するため、Mustに偏りすぎるとバッファが失われます。

Won’t haveには明確な配分比率はありませんが、「検討した上でやらないと決めた」要件を記録に残す役割があります。

実践的な使い方

ステップ1: 要件の一覧化

プロジェクトの要件、機能、ユーザーストーリーをすべて一覧に整理します。この段階では優先度をつけず、まず全体像を把握します。要件の粒度を揃えることが重要です。「ログイン機能」と「ボタンの色の変更」のように粒度がバラバラだと、優先順位の議論が噛み合いません。

ステップ2: ステークホルダーとの分類ワークショップ

プロダクトオーナー、ビジネス側の責任者、開発リードなど、主要なステークホルダーを集めてワークショップを開催します。各要件について「これがなければリリースできないか」という問いから始めます。Yesであれば Must、Noであれば次に「重要だが代替手段はあるか」と問い、Should/Could/Won’tに振り分けます。

ステップ3: Must haveの妥当性検証

Must haveに分類された要件が60%を超えていないか確認します。超えている場合は、「本当にこれがないとリリースできないか」を一つずつ再検討します。ステークホルダーの「あれもこれもMust」という傾向に対しては、「法的に必要か」「ビジネスが停止するか」という基準で絞り込みます。

ステップ4: タイムボックスごとの運用

アジャイル開発では、スプリントやイテレーションごとにMoSCoWを適用します。まずMustを完了させ、余裕があればShouldに着手し、さらに余裕があればCouldに取り組みます。タイムボックスの終了時点で完了していないCouldやShouldは、次のイテレーションで再評価します。

活用場面

• アジャイル開発のスプリント計画: 各スプリントの開始時に、バックログの優先順位をMoSCoWで整理します
• プロジェクトのスコープ管理: スコープクリープ（範囲の肥大化）を防ぐため、新規要件をMoSCoWで評価してから受け入れ判断を行います
• リソース制約下での意思決定: 予算やスケジュールが限られる場合に、CouldとWon’tを活用してスコープを調整します
• ステークホルダーとの期待値調整: 「すべてが最優先」という要望に対して、構造的な優先順位の議論を促します
• RFP（提案依頼書）の作成: 発注側の要件をMoSCoWで整理し、提案者に優先度を明示します

注意点

「すべてがMust」問題への対処

ステークホルダーがすべての要件をMustに分類しようとするのは、最も一般的な問題です。この場合、「リソースが半分になったら何を残すか」「法規制に違反するか」「顧客がサービスを利用できなくなるか」といった具体的な判断基準を提示して議論を促します。

カテゴリ間の移動ルールを決める

プロジェクトの進行に伴い、ShouldがMustに昇格したり、MustがShouldに降格することがあります。カテゴリの変更には、誰の承認が必要で、どのような基準で判断するかのルールを事前に定めておくことが重要です。

Won’t haveの扱いに注意

Won’t haveは「永久に実装しない」ではなく「今回のスコープでは対応しない」の意味です。この認識をステークホルダーと共有しないと、「要件が却下された」という誤解を生みます。Won’t haveの要件は、将来のバックログとして適切に管理してください。

定量的な評価との併用

MoSCoWは定性的な分類手法であり、ビジネス価値やROIの定量的な評価とは異なります。大規模なプロジェクトでは、WASJFなどの定量的な優先順位付け手法と組み合わせることで、より精度の高い判断が可能になります。

まとめ

MoSCoW優先順位付けは、要件をMust・Should・Could・Won’tの4段階に分類し、プロジェクトの優先度とスコープを明確にするフレームワークです。特にMust haveを60%以下に抑え、ShouldとCouldをバッファとして確保することが運用上のポイントです。ステークホルダーとの期待値調整ツールとしても機能し、「やらないことを決める」Won’t haveの活用が、スコープマネジメントの質を向上させます。