MoSCoW法: 要件を正しく優先付けする方法

MoSCoW法はプロジェクトチームにとって最も実践的な優先付けフレームワークのひとつであり、習得に約30分、うまく適用するには生涯にわたる規律が必要です。多くのチームが失敗するのは間違ったツールを選んだからではありません。すべてにYesと言い続け、期限通りに有用なものを何も出荷できなくなるからです。

MoSCoW法とは何か

MoSCoW法は、プロジェクト管理、製品開発、ビジネス分析において要件・機能・タスクを重要度と緊急度に基づいて4つのカテゴリに分類するための、構造化された優先付け技法です。頭文字の各文字が1つのカテゴリに対応します。

• Must have（必須）: 交渉の余地のない要件。これがなければプロジェクトは失敗します。
• Should have（すべき）: 重要だが必須ではない。大きな価値を加えるため、可能な限り含めるべきです。
• Could have（あれば良い）: あると嬉しい機能。Must-haveを危険にさらさない範囲で時間と予算が許す場合のみ含めます。
• Won't have (this time)（今回はなし）: 今回の納品では明示的に対象外。「今回は」という言葉が重要で、将来のイテレーションで登場する可能性があります。

このフレームワークは1994年にOracleUKのDai Cleggが開発し、後にDynamic Systems Development Method（DSDM）で正式化されました。MoSCoWの小文字（"o"と"W"）は発音しやすくするための記号です。意味を持つのはM、S、C、Wの4文字です。

重要なデータ

• Standish Group CHAOS Reportによると、ソフトウェア製品の機能の45%は一度も使われず、さらに19%はほとんど使われないことが分かっています。つまりチームが開発するものの約3分の2はほとんど価値を提供しないということです（Standish Group CHAOS Report、2020年）。
• 構造化された要件優先付けを使用するプロジェクトは、正式な優先付けなしのプロジェクトと比較して期限・予算内での完了率が2倍高い傾向があります（PMI Pulse of the Profession、2021年）。
• プロジェクト開始時に対象外の項目を明確に定義するチームは、プロジェクト途中のスコープ変更を最大30%削減します（DSDMコンソーシアムの実践者調査、2019年）。

4つのMoSCoWカテゴリ

60/20/15/5の分割はあくまでも目安であり、絶対的なルールではありません。重要な制約はMust-haveがチームの確定した納品キャパシティを超えないことです。超える場合は、分類が間違っているのであり、キャパシティが間違っているのではありません。

MoSCoWと他の優先付け手法の比較

MoSCoWは通常、ステークホルダーワークショップでの適用が最も速いフレームワークです。スコアや曲線ではなく平易な言葉のカテゴリを使うためです。Sprint Planningや納品キックオフの前に、技術的でないステークホルダーから賛同を得る必要がある場合に特に有効です。

MoSCoW優先付けのメリット

共通言語を作ります。 プロダクトマネージャーが「それはShould」と言えば、チーム全員がその意味を理解します。機能が「重要かどうか」（要求した誰もが重要と言います）について議論する時間が無駄になりません。

明示的なトレードオフを強制します。 Won't-haveカテゴリはフレームワークの最も強力な部分です。何を構築しないかを書き留めることは、聞こえるより難しく、キックオフ後にスコープが静かに拡大することを防ぎます。

作業開始前にステークホルダーを調整します。 RACIマトリクスのステークホルダー全員でMoSCoWワークショップを実施することで、優先度に関する意見の相違を早い段階で明確にします。後期の優先度対立は高コストです。

Agile納品と自然に組み合わさります。 このフレームワークはAgileメソドロジーと相性が良く、プロジェクト全体ではなく各イテレーションのスコープを設定します。チームはすべての要件を一度だけ固定するのではなく、各リリースサイクルの開始時にMoSCoWを再実行します。

Must-haveを守ります。 最高優先度の項目に独自の保護されたバケットを与えることで、追加要求を政治的に断りやすくなります。「それはMust-haveから何かを外すことになります」という主張は「ただ時間がない」より反論しにくいです。

よくある間違い

1. Must-haveが多すぎる。 これが最もよくある失敗パターンです。すべてが重要なら、何も重要ではありません。健全なMust-haveリストは、予期しない事態のためのバッファを残しながら確定した納品キャパシティに収まるべきです。Must-haveがキャパシティの90%を消費するなら、技術的な問題へのバッファが全くなく、Should-haveを無意味にしています。

2. Won't-haveリストがない。 このバケットをスキップするチームはスコープをあいまいなままにします。ステークホルダーはその曖昧さを仮定で埋めます。Won't-haveリストを書面にして、Must-haveに同意したすべての人と共有してください。

3. カテゴリを永続的なものとして扱う。 MoSCoWは特定の納品ウィンドウのある時点での評価です。リリース1のCould-haveはリリース2ではMust-haveになることがあります。最初の分類を最終的なものとして扱わず、各イテレーションの開始時に見直してください。

4. 時間制約なしにMoSCoWを使う。 このフレームワークは固定されたタイムラインまたは予算に対して優先付けする場合にのみ機能します。制約がなければ、選択を強制する要因がないため、すべてがMust-haveのままです。

5. 適切なステークホルダーなしでワークショップを実施する。 単一のアナリストやプロジェクトマネージャーがステークホルダーの入力なしで行った分類は、誰もオーナーシップを感じないリストを生みます。セッションにはトレードオフを受け入れる立場にいる人々が必要です。

6. Should-haveとCould-haveを混同する。 Should-haveはそれがなければビジネスが積極的に困るものです。Could-haveは良い機能強化です。プレッシャー下で何をカットするかを決める際に、この区別が重要です。

MoSCoW法の使い方

ステップ1: 要件を収集する

納品の候補となるすべての要件、機能、ユーザーストーリー、またはタスクを集めます。この段階では何もフィルタリングしません。整理を始める前に完全なリストが必要です。全体的なプロジェクトの何が対象内かを確認する境界文書としてプロジェクトスコープステートメントを使用してください。

ステークホルダー分析マトリクスは、優先付けワークショップ中に誰の意見が必要かを特定するのに役立ちます。異なるステークホルダーが異なる要件を所有しており、彼らの相対的な権限が対立がどのように解決されるかを形成します。

ステップ2: カテゴリの定義に合意する

チームが分類を始める前に、各バケットがこの特定のコンテキストで何を意味するかを確認するのに5分を使います。一部のプロジェクトでは「Must have」は法的に要求されることを意味します。他では、MVPが機能するために技術的に必要なことを意味します。分類する前に定義を調整することで、2つ目の項目ごとにセッションが止まることを防ぎます。

ステップ3: 協力して分類する

すべての要件を見えるようにした状態で（ホワイトボード、付箋、または共有スプレッドシート）、チームが各項目をバケットに割り当てます。リストを体系的に進めます。各要件について問いかけましょう。

• これなしに製品が使えないか、コンプライアンス違反になるか？ → Must
• これがなければ大きな残念感とともに出荷することになるか？ → Should
• 余裕があれば追加するか？ → Could
• 今回の納品では対象外か？ → Won't（今回は）

この段階での意見の相違は健全です。それは調整されていない期待を早期に表面化させます。今それを解決しましょう。3週間後のScrumのDaily Stand-upではなく。

ステップ4: Must-haveの予算をサニティチェックする

最初の分類が完了したら、すべてのMust-have項目の見積もり工数を合算します。その合計を確定した納品キャパシティ（利用可能な工数またはStory Pointから20%のコンティンジェンシーバッファを引いたもの）と比較します。Must-haveがキャパシティを超える場合は、何かを移動させる必要があります。数字が合うまで、最も弱いMust-haveをShould-haveに降格させます。

このステップがMoSCoWが投資対効果を発揮する場面です。これなしに、チームはプロジェクトの3分の2が過ぎた時点でのオーバーコミットを発見します。その時点では優雅に調整するには遅すぎます。

ステップ5: 各イテレーションでレビューと改訂を行う

各SprintまたはReleaseサイクルの開始時にリストを見直します。完了した項目は削除します。新しい発見、変化するビジネスニーズ、技術的な制約によって項目がカテゴリ間で移動することがあります。前回のイテレーションのWon't-haveリストは、次のイテレーションでCould-haveまたはShould-haveへの昇格候補として最良のソースです。

このレビューループこそが、MoSCoWを元の計画ではなく現実に沿わせ続けるものです。プロジェクト憲章が戦略的な境界を設定し、MoSCoWは戦術的な実行をその境界内に保ちます。

MoSCoWの実例

以下のテーブルは、顧客向けプロジェクトポータルMVPの機能リストをMoSCoWカテゴリ別に分類したものです。

Must-haveが機能する製品を定義します。Won't-haveは初日にすべてを求めるステークホルダーとの交渉境界を定義します。

ベストプラクティス

MoSCoWはソロ作業ではなくワークショップとして実施する。 分類中の議論こそが調整が生まれる場所です。1人が記入してメールで送られたスプレッドシートでは、同じ共有オーナーシップは生まれません。

Must-haveを機能名ではなく受け入れ基準として書く。 「セキュアログイン」は曖昧です。「ユーザーがメールとパスワードでログインでき、30分間の無操作後にセッションが終了し、ログイン失敗試行数がレート制限される」はテスト可能です。明確な基準があればMust-haveが実際に完了したことの確認が容易になります。

Won't-haveリストをプロジェクト全体を通じて見える場所に置く。 印刷する、固定する、scrum vs kanbanボードのヘッダーに載せる、またはチームチャンネルに投稿する。対象外の項目は誰も見ていない間に静かにスコープに戻ってくる習性があります。

MoSCoWを見積もりプロセスの代わりではなく、並行して使う。 キャパシティ見積もりのない優先付けは願望に過ぎません。リストを更新するたびにステップ4のサニティチェックを実行してください。

「今回はWon't have」の意味について正直であること。 それは丁寧な拒絶ではなく、スケジュールされた先送りです。ある項目が永遠に構築されないとわかっているなら、それをWon't-haveに無期限に置いたままにせず、明確に伝えましょう。チームとステークホルダーには明確さが必要です。

よくある質問

MoSCoWの「o」は何を表しますか？

何も表しません。小文字の「o」は頭文字を発音しやすくするために追加された記号です。意味を持つ4文字はM（Must have）、S（Should have）、C（Could have）、W（Won't have）です。Dai Cleggが1994年にOracleでこの用語を作り、特殊な大文字化は意図的なもので、6文字のうち4文字だけが意味を持つことを示しています。

要件の何パーセントがMust-haveであるべきですか？

普遍的なルールはありませんが、多くの実務家はMust-haveの要件が利用可能な納品キャパシティの60〜70%を超えないことを推奨しています。これによりShould-haveとコンティンジェンシーバッファの余地が生まれます。Must-haveが常にキャパシティの80〜100%に達するなら、優先付けではなく、構築する予定のすべてをただリストアップしているに過ぎません。

要件はカテゴリ間を移動できますか？

はい、そうすべきです。MoSCoWは生きたツールです。ある規制変更や顧客コミットメントによってその重要性が変わった場合、1つのSprintのShould-haveが次のSprintでMust-haveになることがあります。最初の分類を最終的なものとして扱わず、各イテレーションの開始時にカテゴリをレビューし更新してください。

MoSCoWはAgile納品とどのように組み合わさりますか？

MoSCoWはAgileと自然に組み合わさります。両アプローチとも反復とトレードオフを重視するためです。Agileのコンテキストでは、MoSCoWは完全な製品Roadmapではなく、各SprintまたはReleaseのスコープを設定します。Product OwnerはSprint Planning前に分類ワークショップを実施するのが一般的です。Sprint Backlogは最初にMust-haveから、キャパシティが許すならShould-haveから、確定したスラックがある場合のみCould-haveから構成されます。

MoSCoWセッションの進行役は誰がすべきですか？

プロジェクトマネージャーまたはビジネスアナリストが通常進行しますが、セッションには要件に対する意思決定権を持つすべてのステークホルダーを含めるべきです。通常、Product Ownerまたはスポンサー、主要な技術リーダー、納品に大きな利害を持つビジネス部門が含まれます。進行役の仕事は会話を前進させ、意見の相違がセッション終了前に（先送りではなく）解決されることを確認することです。

---

優先付けは技術的なスキルではありません。意思決定の規律であり、MoSCoWはその規律に、認定資格やスコアリングスプレッドシートなしに多くのチームが実際に使える構造を与えます。完全な要件リストから始め、適切な人々でワークショップを実施し、オーバーコミットからMust-haveを守り、構築しないものを書き留めましょう。残りはついてきます。

関連記事

• Agileメソドロジーとは？
• Sprint Planning: 効果的なSprint Planningミーティングの進め方
• Scrumとは？
• Scrum vs Kanban
• プロジェクトスコープステートメント
• RACIマトリクス
• プロジェクト憲章
• ステークホルダー分析マトリクス