MoSCoW分析のやり方｜要件の優先順位付けの例と判定シート

MoSCoW（モスクワ）分析は、要件を Must（必須）・Should（重要）・Could（できれば）・Won't（今回はやらない）の4つに分けて、期限と予算の中で「必ず届けるもの」を決める方法です。 原典の DSDM では、Must の工数は全体のおよそ 60% まで、Could は 20% 程度を目安にするとしています。

確認環境：定義と目安は、DSDM を管理する Agile Business Consortium の「Chapter 10: MoSCoW Prioritisation」の原文で確かめました。記事の例の比率は、Python 3.11（Linux）で計算した結果です。判定のフロー図は Mermaid 12.1.0 で描画できることを確かめています（確認日 2026年10月12日）。

MoSCoW の原典と定義

MoSCoW は、アジャイル開発の手法の1つである DSDM（Dynamic Systems Development Method）の中で説明されている優先順位の付け方です。 名前は4つの区分の頭文字（M・S・C・W）に、読みやすくするための「o」を足したものです。

原典の定義のポイントは次のとおりです。

• Must Have は "Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver"、つまりプロジェクトが届けることを保証する、最小限使える要件の集まりです。
• Should Have は "Important but not vital"。外すと痛みはありますが、解決策としては成り立ちます。回避策は一時的なものでもよいとされています（期待値の調整、効率の悪い運用、既存の仕組み、紙の作業など）。
• Could Have は "Wanted or desirable but less important"。外したときの影響は小さく、プロジェクトの予備（contingency）のおもな供給源とされています。期限が危うくなったら、まず Could から外します。
• Won't Have this time は "requirements which the project team has agreed will not be delivered (as part of this timeframe)"。今回の期間では届けないと、チームで合意した要件です。

「Won't」は「やらない」ではなく「今回はやらない」です。 原典の名前にも "this time" が付いています。

Must の比率の目安

原典は、Must の工数を「通常は 60% を超えない」こと、Could の工数を「通常 20% 程度」持つことを勧めています。 理由は次のとおりです。

• Must 以外の要件は、どれもある程度「予備」として働きます。遅れたときに外せるからです。
• Must の工数が多すぎると、外せるものが少なくなり、計画どおりに届けられる確からしさが下がります。
• 原典は、60% を超えてよいのは、見積もりが正確で、進め方がよく分かっていて、チームが成熟していて、外部のリスクが低い場合に限られるとしています。

「全部 Must」は、優先順位を付けていないのと同じです。 Must が多いときは、要件を分けて、その一部だけを Must にできないかを考えます。

Must かどうかを判定する質問

原典の中心の質問は「この要件が満たされなかったら、何が起きるか（What happens if this requirement is not met?）」です。 答えが「プロジェクトをやめる。この要件を満たさない仕組みを入れても意味がない」なら Must です。原典には、ほかにも次のような確かめ方が書かれています。

回避策がある場合は、原典では「回避策のコスト」と「あとで作るコスト・遅らせるコスト」を比べて、Should か Could を決めるとしています。

1つの要件の中でも、受け入れ基準ごとに優先度を変えられます。 原典の例では、「4時間以内」に応えるのが Should、「24時間以内」が Must のように分けています。

flowchart TD
  q1{満たされなかったら<br>リリースする意味がないか<br>（法令・契約を含む）}
  q1 -- はい --> q2{手作業などの<br>回避策があるか}
  q2 -- ない --> M[Must]
  q2 -- ある --> q3
  q1 -- いいえ --> q3{外すと痛みが大きいか<br>（影響する人数・費用）}
  q3 -- 大きい --> S[Should]
  q3 -- 小さい --> q4{今回の期間に<br>入れる余裕があるか}
  q4 -- ある --> C[Could]
  q4 -- ない --> W[Won't this time]

システム開発の例：経費精算システムの要件 25件

社内の経費精算システムの最初のリリース（3か月）を例に、25件の要件を振り分けます。 工数（人日）は説明のための仮の値です。

比率を計算する

同じ表を CSV（列は「ID,要件,工数,区分」、区分は M・S・C・W の1文字）にして、区分ごとの件数と工数を Python で計算しました。Won't の工数は、今回の期間の合計に入れていません。

import csv, collections

rows = list(csv.DictReader(open("moscow.csv", encoding="utf-8")))
eff, cnt = collections.Counter(), collections.Counter()
for r in rows:
    eff[r["区分"]] += float(r["工数"])
    cnt[r["区分"]] += 1

total = sum(v for k, v in eff.items() if k != "W")   # Won't は今回の工数に入れない
for k in "MSCW":
    share = f"{eff[k] / total:.0%}" if k != "W" else "-"
    print(k, cnt[k], "件", eff[k], "人日", share)
print("今回の合計（M+S+C）", total, "人日")
if eff["M"] / total > 0.60:
    print("警告：Must の工数が 60% を超えています")

M 8 件 53.0 人日 50%
S 7 件 31.0 人日 29%
C 5 件 23.0 人日 21%
W 5 件 34.0 人日 -
今回の合計（M+S+C） 107.0 人日

Must は 50%、Could は 21% で、原典の目安（Must 60% まで、Could 20% 程度）に収まっています。 試しに、交通費の取り込み（R08）とスマートフォンの画面（R13）も Must にすると、次のように 60% を超えて警告が出ました。

M 10 件 69.0 人日 64%
S 5 件 15.0 人日 14%
C 5 件 23.0 人日 21%
W 5 件 34.0 人日 -
今回の合計（M+S+C） 107.0 人日
警告：Must の工数が 60% を超えています

このようなときは、Must にしたい要件を分けられないかを考えます。 たとえば R13 を「スマートフォンで申請の状態を見る（Must）」と「スマートフォンで申請を入力する（Should）」に分ける、という方法です。

表計算ソフトで同じ計算をするなら、区分の列を条件にした SUMIF 関数で区分ごとの工数を合計し、M・S・C の合計で割ります。

Won't の扱い

Won't は消さずに、要件の一覧に残します。 原典では、Won't は優先順位付きの要件一覧（Prioritised Requirements List）に記録され、プロジェクトの範囲をはっきりさせるのに役立つとされています。記録しておくと、あとで同じ要件が「正式な手続きなしに」戻ってくるのを防げます。

Won't を決めることは、発注者と開発チームの「やらないことの合意」です。 合意を記録しておくと、受け入れのときに「この機能がない」という行き違いが減ります。範囲の変更の手続きは、関連記事「仕様変更の管理方法 変更管理表テンプレートと変更要求フロー」で扱っています。

優先度は見直すもの

原典は、優先度は作業の前に決め、作業中も見直し続けるものとしています。 少なくとも、タイムボックス（決まった長さの作業期間）と、リリースの単位（Project Increment）の終わりに見直します。

• 原典の説明では、MoSCoW は プロジェクト全体・リリースの単位・タイムボックス のそれぞれで付けられます。プロジェクトでは Must の要件でも、あるタイムボックスの中では Should として扱うことがあります。
• 今回の Could が次は Won't になることも、Must になることもあります。
• 新しい要件を足すときは、Must の比率が合意した上限を超えないかを確かめます。

Should と Could の境目は人によって変わりやすいので、原典は「最初に、客観的な基準を合意しておく」ことを勧めています。 たとえば「影響を受ける人が 50 人以上なら Should、それより少なければ Could」のように、プロジェクトで決めておきます（50 人は例です）。

ほかの優先順位付けの手法との比較

• Kano モデルは、狩野紀昭らの論文「魅力的品質と当り前品質」（『品質』14巻2号、1984年）で示された考え方です。「満たされて当然、ないと不満」の当り前品質は、MoSCoW では Must になりやすい要件です。
• RICE は、Intercom の記事で示された点数の付け方です。Impact は 3・2・1・0.5・0.25、Confidence は 100%・80%・50%、Effort は人月で見積もります。点数で並べられる一方、Must のような「約束」は表しません。
• 緊急度×重要度は、タスクや課題の順番を決めるのに向いています。関連記事「優先順位の付け方｜緊急度×重要度マトリクスの例と点数表」で扱っています。

MoSCoW と RICE は組み合わせて使えます。 MoSCoW で Must を決め、Should・Could の中の順番を RICE の点数で決める、という使い方です。プロダクトバックログでの並べ方は、関連記事「プロダクトバックログの書き方と例｜優先順位の付け方とテンプレート」で扱っています。

判定シートのテンプレート

要件ごとに「満たさないと何が起きるか」と「回避策」を書いてから区分を決めると、理由が残ります。 表計算ソフトに貼れる CSV の形です。

ID,要件,満たさないと何が起きるか,回避策,回避策のコスト,工数(人日),区分(M/S/C/W),理由,決めた人,決めた日,見直す時期
R01,社員がログインできる,誰も使えない,なし,-,8,M,システムの前提,業務部門長,2026-10-12,
R09,申請・差し戻しをメールで通知する,気づくのが遅れる,画面を毎日見る,1人1日5分,3,S,回避できるが手間,業務部門長,2026-10-12,
R21,法人カードの明細の取り込み,手入力が続く,手入力,月2時間,12,W,契約が未決,業務部門長,2026-10-12,次のリリース計画時

シートの集計欄に置く項目は次のとおりです。

要件の一覧と要件IDの付け方は、関連記事「要件定義書の書き方｜記入例と要件ID・受け入れ基準」で扱っています。

よくある質問

Q. 非機能要件（性能・セキュリティ）にも MoSCoW を付けますか。 A. 付けられます。原典の例のように、受け入れ基準ごとに区分を分けると決めやすくなります（例：画面の応答 3 秒以内が Must、1 秒以内が Should）。非機能要件の項目は、関連記事「非機能要件一覧｜IPA非機能要求グレード6大項目と定義書テンプレート」で扱っています。

Q. 発注者が「全部 Must」と言います。 A. 原典の質問「リリース前日に間に合わないと言われたら、リリースを止めますか」を1件ずつ聞くと、Must の範囲が絞られることが多いです。あわせて、Must の比率が 60% を超えると、遅れたときに外せるものがなくなり、期限を守れる見込みが下がることを、計算した比率で示します。

Q. MoSCoW の区分と、チケットの優先度（高・中・低）は同じですか。 A. 同じではありません。MoSCoW は「この期間で届けると約束するか」で、チケットの優先度は「どの順番で手を付けるか」です。Must の中にも、先に作るものと後に作るものがあります。

Q. ウォーターフォールの開発でも使えますか。 A. 使えます。要件定義の段階で、初回リリースの範囲（Must・Should）と、次のリリース以降（Won't）を分けるのに使えます。品質・費用・納期のバランスの考え方は、関連記事「QCDとは？優先順位の決め方とトレードオフの例・管理指標一覧」で扱っています。

まとめ

• MoSCoW は DSDM で説明されている優先順位付け。Must は「必ず届けると約束する最小限」
• 目安は Must の工数 60% まで、Could 20% 程度。例では Must 50%・Could 21% で、2件を Must に変えると 64% になった
• Must の判定は 「満たされなかったら何が起きるか」「回避策はあるか」
• Won't は「今回はやらない」。消さずに、理由と見直す時期を残す
• 優先度は タイムボックス・リリースの終わりに見直す。Should と Could の境目は最初に基準を合意する

参考・出典

確認日はいずれも 2026年10月12日です。

• Agile Business Consortium「Chapter 10: MoSCoW Prioritisation」（DSDM Project Framework）：https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html
• Intercom「RICE: Simple prioritization for product managers」：https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
• ＠IT「狩野モデル」の解説（元論文の書誌情報）：https://atmarkit.itmedia.co.jp/ait/articles/2308/29/news012.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。