MoSCoW分析（モスクワ分析）とは何か？その意味と使い方と解説
MoSCoW分析とは
MoSCoW分析とは、要件定義の際に使用される分析手法の１つで、要件をMust（対応必須）、Should（対応すべき）、Could（できれば対応）、Won’t（対応不要）という４つの分類で評価し、プロジェクトで対応する要件の優先順位を決める方法です。
MoSCoW分析という名前の"M"、"S"、"C"、"W"はそれぞれ"Must"、"Should"、"Could"、"Won’t"から来ており、発音しやすいように"o"の文字が加えられ、ロシアのモスクワの英語名“Moscow"と同じ綴りにしています。
MoSCoW分析はなぜ必要なのか？
ソフトウェア開発などのITプロジェクトでは、発注者やユーザーからいろいろな注文を付けられて、開発側が混乱してしまうことが多々あります。
そうしたプロジェクトのトラブルを防ぐために、このプロジェクトで何を対応するのかを明確にしておく必要がありますが、その際に使われるのがMoSCoW分析です。
また、近年ではスタートアップの際に、 実用最小限の製品（MVP、Minimum viable product） と呼ばれる最低限必要な機能だけを実装した製品を開発し、早めにリリースする手法が注目されていますが、「実用最小限の機能とは何か？」を考える上でも、MoSCoW分析は役に立ちます。
MoSCoW分析の使い方
上述の通り、MoSCoW分析では、要件をMust（対応必須）、Should（対応すべき）、Could（できれば対応）、Won’t（対応不要）という４つのカテゴリーに分類して、優先順位を決定していきます。
ここからは、これら４つのカテゴリーについて、さらに詳しく見ていきましょう。
Must（対応必須）
Must（あるいはMust have）のカテゴリーの要件は、このプロジェクトで必ず対応しなければならない要件です。
このカテゴリーに分類される要件は、この要件が満たせないのであれば依頼者が開発プロジェクトを中止させるほど、プロジェクトの根幹を担うものです。
例えば、以下のような要件がこのカテゴリーに該当します。
- この要件が満たされなければ営業活動ができない。
- この要件が満たされなければ安全に稼働させられない。
- この要件が満たされなければ法律に違反してしまう。
こうした要件はMustのカテゴリーに分類され、その要件の実現は最優先で対応されます。
Should（対応すべき）
Sould（あるいはShould have）のカテゴリーに分類された要件は、この要件が満たされないことでプロジェクトが中止になることはないものの、影響を受けるユーザーやステークホルダーが多い要件です。
Souldに分類された要件は、それを対応する場合・対応しない場合の影響を見積もり、実際に対応するか否かを判断していきます。
例えば、パフォーマンスの改善はSouldのカテゴリーに分類されやすい要件です。
「システムの応答時間を２秒以内にする」という要件は、これがなくともシステムを使用することも可能ですが、システムの応答時間にストレスを感じるユーザーが多いのであれば、できれば対応したい要件です。
こうした「あればよりよくなるもの」については、Souldに分類し、その影響を受けるユーザー数や開発の金額を見積もり、対応の是非を考えていきます。
Could（できれば対応）
Could（あるいはCould have）のカテゴリーは、Souldのカテゴリーと同様にこの要件が満たされなくともプロジェクトが進行する要件に分類されます。
Souldのカテゴリーとの違いは、その影響の程度だけで、例えば、滅多にみられないエラーの対応などはCouldに分類されます。
Won’t（対応不要）
Won’t（あるいはWon’t have this time）は今回のプロジェクトで対応する必要のない要件や、今回のリリースまでには対応しなくともよい要件に分類されるカテゴリーです。
対応しなくともよい要件なので、わざわざWon’tというカテゴリーなど作らず、そうした要件はリストから除外してしまった方がよいと思われることもあります。
しかし、プロジェクトが進んでいくと以前に口頭で対応する必要はないとされていた要件が再燃することもよくあります。
そうした場合、何も文章になっていない場合は、その要件の対応可否を改めて検討しないといけなくなってしまいます。
こうしたトラブルを防ぐためにも、Won’tの要件もきちんと整理し、「何を対応しないのか」を明確にしていく必要があります。
MoSCoW分析のデメリット・使用上の注意点があります。
このように、MoSCoW分析では要件の優先順位が整理することができるため、要件がまとまらずにプロジェクトが座礁するということが少なくなります。
しかし、MoSCoW分析も万能ではなく、いくつかのデメリットや使用上の注意点があります。
例えば、MoSCoW分析では同じような優先度の要件しかない場合は、あまり効果があげられません。ほとんどの要件がMustやSouldになり、そこまでプロジェクトの進行に影響を与えません。
また、MoSCoW分析を使うタイミングでも優先順位が変動することがあり、いつMoSCoW分析を使うのかが重要になります。
例えば法律がプロジェクト中に変わった場合、その影響を受ける要件については、優先順位が変動することがあります。
そのため、MoSCoW分析を一度行って終了とはせずに、要件を見直すタイミングで、MoSCoW分析をし直すということも視野に入れる必要があるでしょう。
対応しなかった要件はいつ取り組むのか
今回は要件の優先順位づけの手法であるMoSCoW分析について解説していきました。
MoSCoW分析はMust、Should、Could、Won’tの４つのカテゴリーに分類して「今回のプロジェクトで何を対応するのか」を考えていく手法でした。
これから進めていくプロジェクトで対応する要件をMoSCoW分析で整理した後は、今回のプロジェクトで対応しない要件をどうするのかも考えていく必要があります。
先ほど紹介したように、最低限必要な機能だけを実装して世に送り出したMVPと呼ばれる製品も、最低限必要な機能だけでは、そこからの成長はなかなか見込めません。そこから成長していくには、開発当初に対応しなかったSouldやCould、Won’tの要件についても対応し、機能を充実させていく必要があります。
そのため、MoSCoW分析で要件の優先順位をつけていったあとは、今回のプロジェクト終了後にどのような活動をしていくのかというロードマップをつくっておくと、システムの改善活動を明示することができるでしょう。
参考
書籍
- 細川 義洋『なぜ、システム開発は必ずモメるのか? 』日本実業出版社、2013年。