MoSCoWの4分類とは？
MoSCoW は、4つの分類の頭文字を並べた名前です。間の小文字の o は、読みやすくするために入れたもので、意味はありません。アジャイル開発の手法の一つである DSDM で広く使われるようになりました。
| 分類 | 意味 | 判断の目安 | 例 |
|---|---|---|---|
| Must have（必須） | これがないと成り立たない | ないと法令違反・リリースできない・使う意味がない | 申請・承認・精算の基本機能 |
| Should have（重要） | 大事だが、なくても代わりの方法で回せる | 手作業などの回避策がある | 領収書の画像の自動読み取り |
| Could have（あれば望ましい） | あると便利だが、影響は小さい | 時間や予算に余裕があれば入れる | 申請画面のデザインの変更 |
| Won't have this time（今回はやらない） | 今回の範囲では作らない | 合意して外す。将来の候補として残す | 海外出張の多通貨対応 |
Won't は「永久にやらない」ではなく、「今回はやらない」という意味です。外したことを記録して関係者と合意しておけば、後から「入っていると思っていた」という行き違いを防げます。
DSDM を広めている Agile Business Consortium は、Must を「Minimum Usable SubseT」の頭文字とも説明しています。最低限使える部分という意味で、Must だけで製品が使える状態になることが条件です。
MoSCoWはどう使う？
基本の手順は次のとおりです。
- 目的と制約を確かめる：何のためのリリースか、期限と予算はどれくらいかを関係者でそろえる。
- 要求を洗い出す：ユーザー・ストーリーや機能の一覧を作る。大きすぎる要求は分解しておく。
- 4つに分ける：関係者と話し合い、それぞれを Must・Should・Could・Won't に分ける。「Must でないと本当に困るか」を一つずつ確かめる。
- Must の量と依存を確かめる：Must だけで作業量の大半を占めていないか、Must が Should や Could に頼っていないかを見る。
- 計画に反映し、見直す：Must から計画に入れ、状況が変わったら分類を見直す。
大きな要求をそのまま分類すると、全体が Must になりがちです。「経費精算」を「申請」「承認」「多通貨」などに分解すると、Must とそれ以外を分けやすくなります。
Mustはどれくらいに抑える？
よくある失敗は、すべてが Must になることです。関係者はみな自分の要求を大事に思うので、話し合わないと Must が増え続けます。
Agile Business Consortium は、Must の作業量を全体の60%以下に抑えるよう勧めています。Could は20%程度を持ち、調整の余地にします。Must が多すぎると、少しの遅れで Must すら終わらなくなるからです。
- Must60%以下
必ず届ける
- Should約20%
できる限り届ける
- Could約20%
遅れたら最初に外す
Could が調整の余地になるので、時間と予算を守りながら Must を確実に届けられる。
カノ・モデルなど他の手法とはどう違う？
優先順位づけの手法はほかにもあります。目的によって使い分けます。
| 手法 | 考え方 | 向いている場面 |
|---|---|---|
| MoSCoW | 必須かどうかで4つに分ける | 期限と予算が決まっていて、範囲を調整したいとき |
| カノ・モデル | 機能を「当たり前品質」「一元的品質」「魅力的品質」などに分け、顧客満足への効き方を見る | 利用者の満足度を高める機能を選びたいとき |
| 100ポイント法 | 関係者が持ち点100を要求に配分する | 多くの関係者の意見を数字でそろえたいとき |
| 価値と労力の比較 | 価値が高く労力の小さいものから手を付ける | 早く成果を出したいとき |
| ペア比較 | 要求を2つずつ比べて順位を付ける | 要求の数が少なく、順位をはっきりさせたいとき |
カノ・モデルは、日本の狩野紀昭氏が提唱した考え方です。たとえば「ブレーキが効く」は、あって当たり前で、なければ大きな不満になる当たり前品質です。MoSCoW なら Must に当たることが多いでしょう。2つを組み合わせて使うこともできます。
バックログではどう使う？
スクラムでは、プロダクト・バックログの並び順を決めるのはプロダクト・オーナーです。MoSCoW は、そのための判断材料として使えます。
- リリースの計画：次のリリースに入れるものを Must・Should・Could で分け、Must を確実に届ける。
- スプリントの計画：スプリントの目標に欠かせない項目を Must として扱い、ほかは余裕があれば取り込む。
- 関係者との合意：Won't を明示し、今回やらないことを合意しておく。
- 見直し：市場の変化や関係者の意見で、分類はリリースやスプリントごとに見直してよい。
最初のリリースで最小限の製品を出すときは、Must の範囲が出発点になります。考え方は MVPとは？ で解説しています。バックログの並べ方そのものは プロダクト・バックログとは？ をご覧ください。
MoSCoWの弱点と対策は？
MoSCoW は簡単なぶん、使い方を誤ると形だけの分類になります。よくある弱点と対策をまとめました。
| 弱点 | 起きること | 対策 |
|---|---|---|
| 同じ分類の中の順番が決まらない | Must が20個あると、どれから作るか決まらない | Must の中も、価値・リスク・依存関係で一列に並べる |
| 声の大きい人の要求が Must になる | Must が増え、期限に間に合わない | 「ないとリリースの意味がないか」という基準を先に合意する |
| Won't の扱いがあいまい | 外したはずの要求が、いつの間にか戻ってくる | Won't を記録し、いつ見直すかを決めておく |
| 品質や保守の作業が後回しになる | テストや技術的な改善が Could 扱いになる | テストや改善の作業も、機能と同じ土俵で分類する |
スコープを決めて合意する手順の基本は スコープ・マネジメント で扱っています。
PMP試験ではどう問われる？
ECO 2026年版の Process 領域には、「価値に基づく提供を確実にする」タスクがあります。その中に、価値と関係者の意見で作業の優先順位を決めることが含まれています。スコープを定めて関係者の合意を得るタスクもあります。MoSCoW は次のような場面で出ます。
- 期限は動かせないが、作業が終わりそうにない → 優先順位の低いもの（Could）から範囲を調整する。
- 関係者がみな自分の要求を Must と主張する → 目的に照らして話し合う場を設け、分類を合意する。
- 用語問題：MoSCoW の各分類の意味。特に Won't を「永久にやらない」と取り違えない。
関係者の利害が強くぶつかり、プロジェクトの中で決められないときは、上位の会議体で判断することもあります。詳しくは 運営委員会（ステアリング・コミッティ）とは？ をご覧ください。優先順位をめぐる状況問題は 無料模試30問 で練習できます。
確認問題1
すべてがMustになる
（当サイトの独自問題）新しい予約システムのリリースまで3か月。優先順位を決める会議で、3つの部署の代表がそれぞれ自部署の要求をすべて Must だと主張した。Must だけで3か月の作業量を大きく超えている。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。Must は「ないとリリースの意味がない」ものに限ります。目的に立ち返って基準をそろえ、関係者と一緒に分類し直します。
1：役職で決めると、価値に基づく判断になりません。2：数で公平にしても、価値の大きさは反映されません。3：話し合いの前に、期限という制約を崩しています。
確認問題2
期限に間に合わない
（当サイトの独自問題）法改正の施行日に合わせてシステムを改修している。残り4週間の時点で、作業は予定より遅れている。施行日は動かせない。要求は MoSCoW で分類済みで、Could の機能がいくつか残っている。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。期限が動かせないときは、優先順位の低い Could から範囲を調整するのが MoSCoW の使い方です。外す前に関係者と確認します。
2：最も大事な Must の品質を下げています。3：分析を理由に報告を遅らせると、関係者が手を打てなくなります。4：長続きしない対応で、品質やチームの状態を損なうおそれがあります。
確認問題3
Won'tの意味
（当サイトの独自問題）MoSCoW 分析の Won't have（this time）の説明として、最も適切なものはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。Won't は「今回はやらない」という意味です。外したことを関係者と合意し、将来の候補として残します。
1：合意は必要ですが、永久に作らないという意味ではありません。2：これは Could の説明です。4：削除とは限らず、候補として残すのが一般的です。