プロジェクトを進めていると、「やりたいことが多すぎる」「どの機能から作るべきか分からない」「全部必要と言われてしまい、優先順位が決まらない」と悩むことがあります。
特に、システム開発、Webサイト制作、業務改善、社内研修、新規事業、商品企画などでは、関係者から多くの要望が出てきます。現場は「この機能も必要」と言い、管理職は「この条件も満たしたい」と言い、経営層は「早く成果を出したい」と言うかもしれません。
しかし、限られた時間、予算、人員の中で、すべてを一度に実現することは難しいものです。優先順位を決めないまま進めると、重要なものが後回しになったり、低優先度の作業に時間を使いすぎたり、納期直前に混乱したりします。
そこで役立つのが、MoSCoWです。
MoSCoWは、要件やタスクを「Must」「Should」「Could」「Won’t」の4つに分けて、優先順位を整理するためのフレームワークです。
初心者にとっては少し変わった名前に見えるかもしれませんが、考え方はとてもシンプルです。「絶対に必要なもの」「できれば必要なもの」「余裕があればやるもの」「今回はやらないもの」に分けるだけです。
MoSCoWを使うと、関係者との話し合いが整理され、限られたリソースの中で何を優先すべきかを決めやすくなります。
この記事でわかること
・MoSCoWとは何か
・MoSCoWは何に使うのか
・MoSCoWの基本的な考え方
・MoSCoWの使い方
・MoSCoWの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「MoSCoWは、やることを重要度別に分けて優先順位を決めるための型だ」とつかめれば十分です。
MoSCoWとは？
MoSCoWとは、要件やタスクの優先順位を4つの区分で整理するフレームワークです。
MoSCoWは、次の4つの頭文字からできています。
・Must
・Should
・Could
・Won’t
実際には、読みやすくするために「o」が入っていますが、意味を持つのはM、S、C、Wの4つです。
Mustは、必ず必要なものです。これがないとプロジェクトの目的を達成できない、サービスとして成立しない、業務として運用できない、という要件です。
Shouldは、重要だが、最悪なくても成立するものです。あると価値は高いものの、Mustほど絶対ではありません。
Couldは、余裕があれば実施したいものです。便利ではあるが、なくても大きな問題にはならない要件です。
Won’tは、今回はやらないものです。将来的には検討する可能性があっても、今回の対象からは外すものを明確にします。
たとえば、社内研修システムを作る場合、「受講者がログインできる」「研修動画を視聴できる」「受講完了を記録できる」はMustかもしれません。一方、「受講者ランキングを表示する」「デザインを細かくカスタマイズする」はCouldかもしれません。
初心者向けに言い換えるなら、MoSCoWは「絶対やる、できればやる、余裕があればやる、今回はやらない」を整理する方法です。
一言でいうと、MoSCoWは要件やタスクの優先順位を明確にするためのフレームワークです。
MoSCoWは何に使うのか
MoSCoWは、プロジェクトや業務で「何を優先して実施するか」を決めるために使います。
仕事では、要望が増え続けることがあります。すべての要望を受け入れると、スケジュールが延び、コストが増え、重要な成果が遅れる可能性があります。そこで、要件やタスクを整理し、優先順位を明確にする必要があります。
MoSCoWは次のような目的で使われます。
・要件の優先順位を決める
・やることとやらないことを明確にする
・関係者の認識を合わせる
・限られた時間や予算を重要なものに集中する
・スコープの膨張を防ぐ
・リリースや公開の範囲を決める
・アジャイル開発やScrumのバックログ整理に使う
・納期に間に合わせるための判断材料にする
たとえば、Webサイト制作で「問い合わせフォーム」「導入事例」「FAQ」「チャットボット」「会員機能」「動画掲載」などの要望が出たとします。すべてを初回公開までに入れようとすると、公開が遅れるかもしれません。
MoSCoWを使えば、「問い合わせフォームはMust」「導入事例はShould」「チャットボットはCould」「会員機能はWon’t」のように整理できます。
これにより、関係者と「今回は何を優先するのか」「何を後回しにするのか」を合意しやすくなります。
どんな人に向いているか
MoSCoWは、要望やタスクが多く、優先順位づけに悩んでいる人に向いています。
特に、次のような人におすすめです。
・プロジェクトを任された人
・要件定義を行う人
・システム開発やWeb制作に関わる人
・関係者から多くの要望を受けている人
・納期や予算に制約がある仕事を進めている人
・新規事業や商品企画で機能を絞り込みたい人
・アジャイルやScrumでバックログを整理したい人
・やらないことを明確にしたい人
MoSCoWは、IT開発だけでなく、さまざまな仕事で使えます。
たとえば、社内研修の設計、営業資料の作成、業務改善施策、マーケティングキャンペーン、展示会準備、新商品企画、制度設計などでも活用できます。
「全部大事と言われてしまう」「優先順位が決まらない」「スコープが広がり続ける」と感じる場面で、MoSCoWは特に役立ちます。
MoSCoWの基本的な考え方
MoSCoWの基本は、要件やタスクを4つの優先度に分けることです。
それぞれの意味をもう少し実務寄りに整理します。
Mustは、必ず必要なものです。これがないとプロジェクトの目的を達成できない、法令や社内ルールを満たせない、顧客や利用者に提供できない、というレベルの要件です。
たとえば、申請システムであれば、「申請を登録できる」「承認できる」「履歴を残せる」はMustになる可能性が高いです。
Shouldは、重要ではあるものの、最初のリリースや納期までに必須とは言えないものです。あると価値が高く、できれば入れたいが、最悪なくても運用できる要件です。
たとえば、「申請内容を検索しやすくする」「承認者にリマインド通知を送る」はShouldかもしれません。
Couldは、余裕があれば実施するものです。便利さや見栄えを高めるもの、利用者体験を改善するものなどが該当します。
たとえば、「画面テーマを個人で変更できる」「ダッシュボードにグラフを表示する」はCouldかもしれません。
Won’tは、今回はやらないものです。ここが非常に重要です。単に優先度を下げるだけでなく、「今回の範囲外」と明確にすることで、スコープの膨張を防ぎます。
たとえば、「スマートフォンアプリ版は今回は作らない」「多言語対応は次期検討にする」といった判断です。
MoSCoWで大切なのは、すべてをMustにしないことです。
関係者は、自分の要望をMustと言いたくなることがあります。しかし、本当にMustなのかを確認する必要があります。「それがないと目的を達成できないのか」「後回しにした場合、本当に致命的なのか」を問い直すことが重要です。
MoSCoWの使い方
手順1 要件やタスクを洗い出す
最初に、対象となる要件やタスクを洗い出します。
MoSCoWは優先順位づけのフレームワークなので、まずは何を優先順位づけするのかを明確にする必要があります。
たとえば、社内システム導入なら、次のような要件があります。
・ログインできる
・申請を登録できる
・承認できる
・差し戻しできる
・申請履歴を確認できる
・通知メールを送信できる
・管理者がユーザーを設定できる
・データをCSV出力できる
・スマートフォンから利用できる
・ダッシュボードで進捗を確認できる
社内研修を作る場合なら、次のようなタスクがあります。
・研修目的を決める
・対象者を決める
・第1章の教材を作る
・確認テストを作る
・受講後アンケートを作る
・動画を収録する
・LMSに掲載する
・受講者ランキングを作る
・修了証を自動発行する
最初の段階では、重要度を気にしすぎず、関係者から出ている要望や必要そうな作業を広めに出します。
手順2 判断基準を決める
次に、Must、Should、Could、Won’tを判断する基準を決めます。
基準が曖昧なまま分類すると、人によって判断がばらばらになります。特に、Mustが増えすぎる原因になります。
判断基準の例は次の通りです。
・プロジェクト目的の達成に必須か
・法令、規制、社内ルール上必要か
・顧客や利用者に最低限提供すべきものか
・なくても運用できるか
・後回しにした場合の影響はどれくらいか
・今回の納期や予算で実現可能か
・次回以降に回しても問題ないか
たとえば、Mustの基準を「これがないとサービスとして成立しないもの」と決めます。Shouldは「重要だが、最初のリリース後に追加してもよいもの」とします。Couldは「便利だが、なくても運用できるもの」とします。Won’tは「今回は範囲外にするもの」とします。
判断基準を先に決めることで、関係者との議論が感情的になりにくくなります。
手順3 Mustを厳しく選ぶ
次に、Mustを選びます。
MoSCoWで最も重要なのは、Mustを厳しく絞ることです。
Mustが多すぎると、優先順位づけの意味がなくなります。すべてがMustになると、結局すべてをやらなければならず、納期や予算を守ることが難しくなります。
Mustを判断するときは、次の問いを使います。
・これがないと目的を達成できないか
・これがないと業務が成立しないか
・これがないと法令や規則に反するか
・これがないと顧客や利用者に提供できないか
・これを後回しにすると致命的な問題が起きるか
たとえば、申請システムで「申請を登録できる」はMustです。しかし、「申請画面の背景色を選べる」はMustではありません。
社内研修で「受講者が教材を見られる」はMustです。しかし、「修了証のデザインを複数選べる」はMustではないでしょう。
Mustは、プロジェクトの最低成立条件です。ここを厳しく選ぶことで、限られたリソースを本当に重要なものに集中できます。
手順4 ShouldとCouldを分ける
Mustを決めたら、残りをShouldとCouldに分けます。
Shouldは、重要度が高く、できれば今回入れたいものです。しかし、Mustではないため、納期や予算が厳しい場合は後回しにできます。
Couldは、余裕があれば実施するものです。あると便利、見栄えが良くなる、使いやすくなる、といった要件が多くなります。
ShouldとCouldを分けるときは、次の問いが役立ちます。
・利用者にとって価値は高いか
・後回しにしても大きな問題はないか
・実施しない場合の不満はどれくらいか
・少ない工数で大きな効果があるか
・今やるべき理由があるか
・次回以降でもよいか
たとえば、社内システムで「通知メール」はShouldかもしれません。なくても申請や承認はできますが、運用効率を高めるためには重要です。
一方、「画面のテーマカラーを選べる」はCouldかもしれません。便利ではありますが、業務成立には大きな影響がありません。
ShouldとCouldを分けることで、納期が厳しくなったときに何を残し、何を後回しにするか判断しやすくなります。
手順5 Won’tを明確にする
最後に、Won’tを明確にします。
MoSCoWで見落とされがちなのが、Won’tです。しかし、実務では非常に重要です。
Won’tは、「今回はやらない」と決めるものです。単に優先度が低いというだけではなく、今回のスコープから外すことを明確にします。
たとえば、次のようなものです。
・スマートフォンアプリ版は今回は作らない
・多言語対応は次期フェーズで検討する
・AI機能は初回リリースには含めない
・全社展開は試行後に判断する
・高度な分析ダッシュボードは今回は対象外にする
Won’tを明確にしないと、後から「これも入れると思っていた」「できれば今回やりたい」と要望が戻ってきます。その結果、スコープが膨らみ、納期や品質に影響します。
Won’tは、否定的なものではありません。むしろ、プロジェクトを成功させるために、今回集中すべき範囲を守るための判断です。
関係者には、「やらない」のではなく、「今回はやらない」「次回以降の候補として管理する」と説明すると合意しやすくなります。
MoSCoWの具体例
例 社内システム導入の場合
社内の申請管理システムを導入する場合を例に考えます。
関係者から、次のような要望が出たとします。
・申請を登録できる
・上司が承認できる
・差し戻しできる
・申請履歴を確認できる
・通知メールを送れる
・スマートフォンから申請できる
・CSVでデータ出力できる
・ダッシュボードで件数を見られる
・承認期限が近い申請を自動リマインドする
・多言語対応する
これをMoSCoWで整理します。
Mustに入るものは、申請登録、承認、差し戻し、申請履歴確認です。これらがないと、申請管理システムとして成立しません。
Shouldに入るものは、通知メール、CSV出力、自動リマインドなどです。業務効率を高めるうえで重要ですが、最悪の場合、初回リリース後に追加しても運用できるかもしれません。
Couldに入るものは、ダッシュボードやスマートフォン対応の一部かもしれません。便利ではありますが、初回リリースの最低条件ではない場合があります。
Won’tに入るものは、多言語対応です。将来的には必要になるかもしれませんが、対象利用者が国内社員中心であれば、今回は範囲外としてもよいでしょう。
このように整理すると、初回リリースで何を作るべきかが明確になります。関係者との議論も、「全部必要」ではなく、「どれが本当に初回に必要か」という話に変わります。
別の例 社内研修教材を作る場合
社内研修教材を作る場合にも、MoSCoWは使えます。
たとえば、新入社員向けのeラーニング教材を作るとします。要望として、次のようなものがあります。
・研修の目的説明
・基本知識のスライド
・実務例
・確認テスト
・受講後アンケート
・動画解説
・修了証の発行
・ランキング表示
・受講者ごとの詳細分析
・スマートフォン最適化
これをMoSCoWで整理します。
Mustは、研修目的説明、基本知識のスライド、実務例、確認テストです。これらがないと、研修としての最低限の価値が成立しません。
Shouldは、受講後アンケート、動画解説、受講履歴の確認です。理解度や改善につながるため重要ですが、初回実施では簡易的な方法でも代替できるかもしれません。
Couldは、修了証の発行、スマートフォン最適化の細かな調整などです。あると便利ですが、初回公開の必須条件ではない場合があります。
Won’tは、ランキング表示や高度な詳細分析です。学習意欲向上や分析には役立つ可能性がありますが、初回教材では範囲外にしてもよいでしょう。
このように整理すると、まず学習効果に直結する部分を優先できます。見た目や追加機能に時間をかけすぎて、肝心の教材内容が薄くなることを防ぎやすくなります。
具体例でわかるポイント
MoSCoWの具体例からわかるポイントは、次の通りです。
・すべての要望を同じ重要度で扱わない
・Mustはプロジェクト成立に必要なものに絞る
・Shouldは重要だが後回し可能なものとして整理する
・Couldは余裕がある場合の追加価値として扱う
・Won’tを明確にするとスコープ膨張を防げる
・関係者との優先順位の合意形成に使いやすい
MoSCoWは、単なる分類表ではありません。限られた時間や予算の中で、何を優先し、何を後回しにするかを合意するための実務的なフレームワークです。
MoSCoWを使うメリット
MoSCoWを使う最大のメリットは、優先順位を分かりやすく整理できることです。
プロジェクトでは、多くの要望が出てきます。関係者にとっては、それぞれの要望が重要に見えます。しかし、実際には、プロジェクトの目的達成に必須のものと、あると便利なものは分けて考える必要があります。
MoSCoWを使うメリットは次の通りです。
・要件の優先順位が明確になる
・関係者との合意形成がしやすい
・スコープの膨張を防ぎやすい
・納期や予算に合わせて調整しやすい
・初回リリースや第1段階の範囲を決めやすい
・アジャイルやScrumのバックログ管理に使いやすい
・やらないことを明確にできる
・重要な成果にリソースを集中できる
特に実務で大きいのは、「やらないこと」を明確にできる点です。
多くのプロジェクトが失敗する原因の一つは、やることが増え続けることです。MoSCoWでWon’tを決めておくと、今回の対象外を明確にでき、プロジェクト範囲を守りやすくなります。
また、MoSCoWは説明しやすいフレームワークです。専門知識がない関係者にも、「これは必須、これはできれば、これは余裕があれば、これは今回は対象外」と伝えやすいため、会議や合意形成で使いやすい特徴があります。
MoSCoWを使うときの注意点
MoSCoWはシンプルで使いやすい一方、運用を間違えると効果が薄れます。
最も多い失敗は、すべてがMustになってしまうことです。関係者がそれぞれ自分の要望を重要だと主張すると、Mustが増えすぎます。すると、結局優先順位がつかず、MoSCoWを使う意味がなくなります。
よくある失敗例は次の通りです。
・Mustが多すぎる
・判断基準が曖昧
・関係者の声が大きい順に優先される
・Won’tを決めずに後でスコープが膨らむ
・ShouldとCouldの違いが曖昧になる
・分類した後に見直さない
・実現工数やコストを考慮していない
・顧客価値ではなく社内都合だけで判断する
・優先順位を決めた理由が共有されていない
・一度決めた分類を絶対視しすぎる
特に注意したいのは、MoSCoWは固定された正解を出すものではないという点です。
プロジェクトの状況が変われば、優先順位も変わることがあります。たとえば、最初はCouldだった機能が、顧客要望の変化によってShouldになる場合もあります。逆に、Mustだと思っていた要件が、代替手段によってShouldになることもあります。
また、MoSCoWでは、優先度だけでなく実現工数も考える必要があります。価値は高くても非常に時間がかかるものと、少ない工数で大きな効果があるものでは、判断が変わることがあります。その場合は、WSJFなどのフレームワークと組み合わせると効果的です。
関連フレームワークとの違い
MoSCoWと似た場面で使われるフレームワークはいくつかあります。それぞれの違いを理解しておくと、プロジェクト管理や優先順位づけで使い分けしやすくなります。
WSJFとの違い
WSJFは、Weighted Shortest Job Firstの略で、価値や緊急度を作業規模で割って、優先順位を決めるフレームワークです。
MoSCoWは、Must、Should、Could、Won’tの4分類で優先度を整理します。一方、WSJFは、数値を使って「どれから着手すると効果が高いか」を判断します。
MoSCoWは初心者にも分かりやすく、関係者との合意形成に向いています。WSJFは、複数の候補をより定量的に比較したい場合に向いています。
MoSCoWは分類、WSJFは定量的な優先順位づけに強いフレームワークです。
Scrumとの違い
Scrumは、Product Backlog、Sprint、Review、Retrospectiveなどを使って、短いサイクルで成果物を作るフレームワークです。
MoSCoWは、その中でProduct Backlogの優先順位を整理するときに使えます。
つまり、Scrumはプロジェクトを進めるための全体的な枠組みであり、MoSCoWはその中で「何を優先するか」を決める道具です。
Scrumは進め方、MoSCoWは優先順位づけに強いフレームワークです。
WBSとの違い
WBSは、プロジェクトの作業を分解するためのフレームワークです。
WBSが「何をやる必要があるか」を洗い出すのに対して、MoSCoWは「その中で何を優先するか」を整理します。
実務では、まずWBSで作業を分解し、その後にMoSCoWで優先順位をつけると使いやすくなります。
WBSは作業分解、MoSCoWは優先順位づけに強いフレームワークです。
アジャイルとの違い
アジャイルは、変化に対応しながら小さく作って改善する考え方です。
MoSCoWは、アジャイルでよく使われる優先順位づけの方法の一つです。
アジャイルでは、限られた期間で価値の高いものから作る必要があります。そのため、MoSCoWでMust、Should、Could、Won’tを整理すると、スプリントやリリースの範囲を決めやすくなります。
アジャイルは仕事の進め方の考え方、MoSCoWは要件の優先順位を決める方法です。
Kanoモデルとの違い
Kanoモデルは、顧客満足に影響する要素を分類するフレームワークです。
基本品質、性能品質、魅力品質などに分けて、顧客満足との関係を考えます。
MoSCoWは、プロジェクトやリリースにおける優先順位を決めるために使います。一方、Kanoモデルは、顧客満足の観点から機能や品質要素を考えるのに向いています。
たとえば、Kanoモデルで「基本品質」と判断された機能は、MoSCoWではMustになる可能性があります。魅力品質はCouldやShouldとして扱われる場合があります。
MoSCoWはどんな場面で使うと効果的か
MoSCoWは、要件やタスクが多く、優先順位づけが必要な場面で効果を発揮します。
逆に、やることが少なく、優先順位を迷う必要がない単純な仕事では、本格的に使う必要はありません。
MoSCoWが効果的な場面は次の通りです。
・システム開発
・Webサイト制作
・アプリ開発
・社内システム導入
・業務改善プロジェクト
・新商品企画
・新規事業立ち上げ
・社内研修教材の開発
・営業資料の作成
・マーケティング施策の設計
・展示会準備
・ScrumのProduct Backlog整理
・リリース範囲の決定
特に、「全部必要と言われる」「納期が厳しい」「予算が限られている」「最初のリリース範囲を決めたい」という場面で有効です。
また、関係者が多いプロジェクトにも向いています。MoSCoWは分類が分かりやすいため、専門知識がない人でも議論に参加しやすく、合意形成を進めやすいからです。
まとめ
MoSCoWは、要件やタスクをMust、Should、Could、Won’tの4つに分けて優先順位を整理するフレームワークです。
プロジェクトでは、要望が増え続けることがあります。すべてを一度に実現しようとすると、納期遅れ、予算超過、品質低下、チームの疲弊につながります。そこで、何が本当に必要で、何を後回しにできるのかを明確にすることが重要です。
MoSCoWを使えば、「必須のもの」「できれば必要なもの」「余裕があればやるもの」「今回はやらないもの」を分けて考えられます。特に、Won’tを明確にすることで、スコープの膨張を防ぎやすくなります。
ただし、MoSCoWを使うときは、すべてをMustにしないことが大切です。判断基準を決め、関係者と合意しながら、限られたリソースを重要な成果に集中させましょう。
まずは、今進めているプロジェクトの要望やタスクを10個書き出し、Must、Should、Could、Won’tに分類してみてください。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
WSJFとは？初心者向けに意味・使い方・具体例をやさしく解説
Scrumとは？初心者向けに意味・使い方・具体例をやさしく解説
アジャイルとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
プロジェクト管理で使えるフレームワークまとめ｜初心者向けに種類・使い分け・活用例を解説
