MoSCoW分析

MoSCoW分析（モスクワぶんせき、モスコウぶんせき、MoSCoW analysis）とは、ビジネス分析（英語版）、プロジェクトマネジメント、ソフトウェア開発において、それぞれの要求の優先度についてプロジェクトの利害関係者の間で共通の理解に達するための手法である。MoSCoWメソッド(MoSCoW method)ともいう。

MoSCoWは、以下の4つの優先順位付けのカテゴリの頭字語である。

M - Must have（対応必須）
S - Should have（対応推奨）
C - Could have（対応可能）
W - Won’t have（対応先送り）

小文字の"o"は、発音しやすいように加えられたものであり、意味のない文字であることを示すために、通常は小文字で書かれる。

背景

この手法は、Rapid Application Development(RAD)で使用するために、1994年にダイ・グレッグによって開発された^[1]。2002年からは動的システム開発手法（英語版）(DSDM)と共に広範囲に用いられるようになった^[2]。

MoSCoW分析は、締切が固定され、最も重要な要求に焦点が当てられるタイムボクシング（英語版）と共に用いられることが多く、スクラム、RAD、DSDMなどのアジャイルソフトウェア開発でよく用いられる。

要求の優先順位付け

全ての要求は重要であるが、ビジネスの利益を最大限かつ即時のものにするためには、要求の優先順位付けが必要である。開発者はまず、"Must have"、"Should have"、"Could have"の全ての要求を満たそうとするが、締切に間に合わないようであれば、"Should"や"Could"の要求から削減される。優先順位を表す言葉として「高」(High)「中」(Medium)「低」(Low)などの平易な言葉もありうるが、優先順位の設定がもたらす影響を顧客によりよく理解してもらうために"Must"などの言葉を使うのは有用である。

一般的に、各カテゴリの意味は以下のように理解されている^[3]。

Must have（対応必須）: "Must have"とラベル付けられた要求は、現在の納品タイムボックスを成功するために極めて重要である。"Must have"の要求で1つでも満たされていないものがあれば、そのプロジェクトの納品は失敗とみなされる（ただし、全てのステークホルダーの合意があれば、Must haveの要求をダウングレードすることは可能である。例えば、より新しい要求の方が重要と判断された場合などである）。"MUST"は"Minimum Usable Subset"（最小限の使用可能なサブセット）の頭字語と考えることもできる。
Should have（対応推奨）: "Should have"とラベル付けられた要求は、重要ではあるが、現在の納品タイムボックスの納品には必須ではない。"Should have"の要求は"Must have"の要求と同程度に重要である場合もあるが、多くの場合、それほど時間的に重要ではないか、または要求を満たす別の方法があり、将来の納品タイムボックスまで延期できる。
Could have（対応可能）: "Could have"とラベル付けられた要求は、僅かな開発コストでユーザ体験や顧客満足度を向上させることができ、開発することが望ましいが、必須ではない。これらは、時間とリソースに余裕があれば開発される。
Won't have（対応先送り）: "Won't have"とラベル付けられた要求は、最も重要度が低く、最も回収投資が少ない、あるいはその時点では開発するのが適切ではないとして、ステークホルダーによって合意されたものである。そのため、このカテゴリの要求は、現在の納品タイムボックスのスケジュールには組み込まれず、削減されるか、次の納品タイムボックスのタイミングで再検討される。なお、"Would like to have"という言葉が用いられることがあるが、これは誤りである。それは、このカテゴリが、明らかに納品の範囲外であることを示しているからである。

変種

"W"は"wish"や"would"の意味で使用されることがある。すなわち、対応可能ではあるが、リリースに含まれる可能性は"could"よりも低いという意味である。これは、明示的にその要件を除外するという意味の"X"(excluded)と区別される。"Would"は、現在は必要とされていないが、将来の拡張の機会としてアーキテクチャの観点から考慮する必要があることを示すために使用される。

新製品開発における利用

新製品開発、特にアジャイルソフトウェア開発を採用している場合、時間や資金などの資源以上に多くの作業が発生するため、優先順位付けが必要となる。

例えば、チームが次のリリースに向けて非常に多くの潜在的なエピック（高いレベルのユーザーストーリーなど）を抱えている場合に、MoSCoW分析によって、どのエピックが必須で、どのエピック推奨であるかなどを選別することができる。実用最小限の製品(MVP)とは、"Must have"（必須）とマーク付けされた全てのエピックとなる^[4]。場合によっては、MVPを特定した後でも、予想される能力に対して作業量が多すぎることもある。その場合、開発チームはMoSCoW分析によって、どの機能もしくはストーリーが必須であるか推奨であるかを選択することになる。市場に出せる最低限の機能（英語版）(MMF)は、"Must have"（必須）とマークされたものの全てとなる^[5]。MVPやMMFを選択した後、十分に余裕がある場合、開発チームはShould haveやCould haveの項目も含めた計画を立てることができる^[6]。

批判

MoSCoW分析には以下のような批判がある。

同じ優先度の要求の取捨選択には役立たない。
ランク付けの根拠（なぜある要求が"should"ではなく"must"なのか）が示されていない^[7]^[8] 。
それぞれのランクの要件を実施するタイミングについて。特に、"Won't have"の要求はこのリリースに含まれないだけなのか、今後一切含まれないのか^[7]。
技術的な改善（リファクタリングなど）よりも新しい機能の構築に政治的な重点が置かれる可能性がある^[8]。

その他の手法

その他の優先順位付けの手法として狩野モデルがある。

脚注

^ Clegg, Dai; Barker, Richard (1994). Case Method Fast-Track: A RAD Approach. Addison-Wesley. ISBN 978-0-201-62432-8
^ Bittner, Kurt; Spence, Ian (2002-08-30). Use Case Modeling. Addison-Wesley Professional. ISBN 978-0-201-70913-1
^ “MoSCoW Analysis (6.1.5.2)”. A Guide to the Business Analysis Body of Knowledge (2 ed.). International Institute of Business Analysis. (2009). ISBN 978-0-9811292-1-1
^ Wernham, Brian (2012). Agile Project Management for Government. Maitland and Strong. ISBN 978-0957223400
^ Davis, Barbee (2012). Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage. Project Management Professional Series. J. Ross Publishing. ISBN 978-1604270839
^ Cline, Alan (2015). Agile Development in the Real World. Apress. ISBN 978-1484216798
^ ^a ^b Wiegers, Karl; Beatty, Joy (2013). Software Requirements. Washington, USA: Microsoft Press. pp. 320–321. ISBN 978-0-7356-7966-5
^ ^a ^b McIntyre, John (October 20, 2016). “Moscow or Kano - how do you prioritize?”. HotPMO! October 23, 2016閲覧。

外部リンク

RFC 2119 (Requirement Levels) This RFC defines requirement levels to be used in formal documentation. It is commonly used in contracts and other legal documentation. Noted here as the wording is similar but not necessarily the meaning.
Buffered MoSCoW Rules This essay proposes the use of a modified set of MoSCoW rules that accomplish the objectives of prioritizing deliverables and providing a degree of assurance as a function of the uncertainty of the underlying estimates.
MoSCoW Prioritisation Steps and tips for prioritisation following the DSDM MoSCoW rules.

[1] Clegg, Dai; Barker, Richard (1994). Case Method Fast-Track: A RAD Approach. Addison-Wesley. ISBN 978-0-201-62432-8

[2] Bittner, Kurt; Spence, Ian (2002-08-30). Use Case Modeling. Addison-Wesley Professional. ISBN 978-0-201-70913-1

[3] “MoSCoW Analysis (6.1.5.2)”. A Guide to the Business Analysis Body of Knowledge (2 ed.). International Institute of Business Analysis. (2009). ISBN 978-0-9811292-1-1

[4] Wernham, Brian (2012). Agile Project Management for Government. Maitland and Strong. ISBN 978-0957223400

[5] Davis, Barbee (2012). Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage. Project Management Professional Series. J. Ross Publishing. ISBN 978-1604270839

[6] Cline, Alan (2015). Agile Development in the Real World. Apress. ISBN 978-1484216798

[:0-7] Wiegers, Karl; Beatty, Joy (2013). Software Requirements. Washington, USA: Microsoft Press. pp. 320–321. ISBN 978-0-7356-7966-5

[:1-8] McIntyre, John (October 20, 2016). “Moscow or Kano - how do you prioritize?”. HotPMO! October 23, 2016閲覧。

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]