フレームワーク活用ガイドひとことで言うと#
すべての要件を**Must have（必須）/ Should have（重要）/ Could have（あれば嬉しい）/ Won’t have（今回はやらない）**の4カテゴリに分類する、シンプルで強力な優先順位付け手法。読み方は「モスクワ」。
押さえておきたい用語#
- Must have（マストハブ）
- これがないとリリースできない必須要件のこと。法的要件やコア機能が該当。全体の60%以内に抑えるのが目安。
- Should have（シュッドハブ）
- 重要だがなくてもリリースは可能な要件のこと。次のイテレーションで対応できるもの。
- Could have（クッドハブ）
- あれば嬉しいがなくても大きな影響がない要件のこと。時間が余れば対応する。
- Won’t have（ウォントハブ）
- 今回のスコープでは意図的にやらない要件のこと。「やらない」ではなく「今回はやらない」という位置づけ。
MoSCoW法の全体像#
こんな悩みに効く#
- リリースに向けて要件が膨らみすぎて、期限内に終わらない
- 「全部必須」と言われて優先順位が付けられない
- ステークホルダーごとに「これが一番大事」の主張が異なる
基本の使い方#
各カテゴリの定義をチーム全員で共有する。ここが曖昧だと分類がブレる。
- Must have（M）: これがないとリリースできない。法的要件、コアの価値提供に不可欠な機能
- 判断基準: 「これがなかったらプロダクトとして成立しないか？」→ Yesなら Must
- Should have（S）: 重要だが、なくてもリリースは可能。次のイテレーションで対応できる
- 判断基準: 「なくても最低限の価値は提供できるか？」→ Yesなら Should
- Could have（C）: あれば嬉しいが、なくても大きな影響はない。時間が余れば対応
- 判断基準: 「一部のユーザーだけが恩恵を受けるか？」→ Yesなら Could
- Won’t have（W）: 今回のスコープでは意図的にやらない。将来の検討課題として記録
- 判断基準: 「今回やらなくても、次回以降に回せるか？」→ Yesなら Won’t
黄金比率: Must 60% / Should 20% / Could 20%。Mustが80%を超えていたら、本当にMustかを再検討する。
チームワークショップ形式で分類する。
手順:
- すべての要件を付箋に書き出す
- 1つずつ「このカテゴリは？」を議論
- 意見が割れたらユーザーへの影響度で判断
- 分類結果を全員で確認
議論のコツ:
- 「Must」に分類したい気持ちをぐっと抑える。本当に「ないとリリースできない」か？
- 営業やCSの「顧客が絶対必要と言っている」は鵜呑みにしない。何人の顧客が言っているか定量化する
- 「Won’t have」は「やらない」ではなく「今回はやらない」。将来の可能性を否定しないので安心して分類できる
分類結果を開発リソース（工数・期間）と照合する。
確認手順:
- Mustの合計工数を見積もる → リソースの60%以内に収まるか確認
- 収まらなければ、Must自体を再検討する（本当にMustか？ スコープを狭められないか？）
- 残りリソースでShouldの上位を選択
- さらに余裕があればCouldから選択
重要: Mustがリソースの100%を占める場合、そもそもリリースのスコープか期間の設定に問題がある。リリースを分割することを検討する。
具体例#
状況: 従業員30名のEC事業会社。サイトリニューアルで要件が30個出て「全部入れたい」状態。開発リソースは3ヶ月・エンジニア4名。
分類結果:
| カテゴリ | 要件例 | 件数 | 工数比 |
|---|---|---|---|
| Must | 商品検索、カート、決済、会員登録、レスポンシブ対応 | 12件 | 55% |
| Should | お気に入り、レビュー投稿、ポイント機能 | 8件 | 25% |
| Could | AIおすすめ、ギフトラッピング、SNSログイン | 6件 | 15% |
| Won’t | AR試着、ライブコマース、多言語対応、サブスク機能 | 4件 | — |
議論で変わった分類:
- 「ポイント機能」: 初期はMustと主張されたが、リニューアル初日からなくても既存のポイントカードで代替可能 → Shouldに降格
- 「レスポンシブ対応」: Shouldと言う人がいたが、モバイル比率70%のデータを見て全員がMustに同意
| 指標 | リニューアル前 | リリース後3ヶ月 |
|---|---|---|
| リリース遅延 | — | 予定通り（0日遅延） |
| モバイルCVR | 1.2% | 2.8% |
| 開発チーム満足度 | 3.1/5.0 | 4.2/5.0 |
MoSCoW分類で「やらないこと」を明確にしたことで、3ヶ月で予定通りリリースできた。「Won’t」に入れた4件は営業チームにも共有し、期待値を事前に調整できた。
状況: 従業員80名のHR SaaS。2週間スプリントで開発しているが、毎回スコープが膨らんでスプリントが失敗する。PdMが毎スプリント開始時にMoSCoWワークショップを導入。
あるスプリントの分類例:
| カテゴリ | 要件 | ストーリーポイント |
|---|---|---|
| Must | 勤怠エクスポート機能のバグ修正、給与計算APIの精度改善 | 18pt |
| Should | 管理画面のフィルター改善、通知設定のUI変更 | 10pt |
| Could | ダークモード対応、CSVインポートのエラーメッセージ改善 | 8pt |
| Won’t | Slack連携、多言語対応の準備 | — |
スプリントキャパシティ: 30pt（Must 18pt = 60%、ちょうど黄金比率）
| 指標 | MoSCoW導入前（6スプリント平均） | 導入後（6スプリント平均） |
|---|---|---|
| スプリント完了率 | 62% | 91% |
| Must達成率 | 78% | 100% |
| チームのベロシティ | 24pt | 28pt |
「全部やろうとして全部中途半端」から「Mustは**100%**やり切る」に変わったことで、チームの達成感と予測精度が劇的に向上した。
状況: 人口8万人の地方自治体。住民サービスのデジタル化で62個の要望が各課から上がったが、予算は年間2,000万円。全部やると5年かかる試算。
MoSCoWワークショップ（参加: 各課の代表12名）:
| カテゴリ | 要件例 | 件数 | 予算配分 |
|---|---|---|---|
| Must | 住民票オンライン申請、ごみ収集日通知、防災情報配信 | 8件 | 1,200万円 |
| Should | 施設予約システム、子育て支援情報ポータル | 12件 | 600万円 |
| Could | AIチャットボット、多言語対応、オンライン相談 | 18件 | 200万円 |
| Won’t | メタバース窓口、ブロックチェーン台帳、ドローン配送 | 24件 | — |
議論のハイライト:
- 「AIチャットボット」: 企画課がMustと主張したが、「24時間対応がなくても住民は困らない」で全員がCouldに同意
- 「防災情報配信」: 最初はShouldだったが、災害時のリスクを考えMustに格上げ
| 指標 | DX推進前 | 1年後 |
|---|---|---|
| オンライン申請率 | 0% | 34% |
| 窓口来庁者数 | 月12,000件 | 月8,400件（-30%） |
| 住民満足度 | 3.2/5.0 | 3.9/5.0 |
62件の要望をMoSCoWで整理したことで、「今年はこの8件に集中する」と全課で合意できた。Won’tに入れた24件の多くは「流行りの技術」であり、住民ニーズとは乖離していた。
やりがちな失敗パターン#
- 「全部Must」になる — 関係者全員が自分の要件をMustに入れたがる。**「これがないとリリースできないか？」**というリトマス試験を徹底する。Mustが全体の60%を超えたら赤信号
- Won’tを使わない — 「やらない」と言うのは勇気がいるが、Won’tに入れることでリソースの集中が実現する。Won’tが0件のMoSCoWは機能していない
- 一度分類したら変えない — 状況は変わる。スプリントごとに見直し、新しい情報に基づいて再分類する柔軟性を持つ
- 定量データなしで議論する — 「顧客が必要と言っている」は何人の顧客か？ ユーザー数・問い合わせ件数・収益インパクトの数字を持って議論する
まとめ#
MoSCoW法は「全部大事」の状態から「本当に大事なもの」を見極めるシンプルな手法。Must/Should/Could/Won’tの4分類で全員の認識を揃え、「やらないこと」を明確にする。Mustが60%を超えたら立ち止まって再検討。シンプルだからこそ、毎回のリリースで使える実践的なツール。