Loading article…
MoSCoWメソッドは、管理、ビジネス分析、プロジェクト管理、ソフトウェア開発で使用される優先順位付け手法であり、各要件の提供に与える重要性について関係者と共通の理解に達するために使用されます。MoSCoW優先順位付けまたはMoSCoW 分析とも呼ばれます。
MOSCOWという用語自体は、 4 つの優先順位付けカテゴリのそれぞれの頭文字から派生した頭字語です。M - Must have (必須)、S - Should have (必要ない)、C - Could have (できるかもしれない) 、W - Won't have (できない) 。
単語を発音しやすくするために、中間のOが追加されます。Oは通常、何も表さないことを示すために小文字で表記されますが、すべて大文字のMOSCOWも使用されます。[要出典]
背景
この優先順位付け方法は、1994年にダイ・クレッグ[1]によって、迅速なアプリケーション開発（RAD）で使用するために開発されました。2002年からは動的システム開発手法（DSDM）[2]で広く使用されるようになりました。
MoSCoW は、期限が固定され、最も重要な要件に焦点が当てられるタイムボックス化で使用されることが多く、スクラム、ラピッドアプリケーション開発(RAD)、DSDMなどのアジャイルソフトウェア開発アプローチでよく使用されます。
要件の優先順位付け
すべての要件は重要ですが、最大かつ最も迅速なビジネス上のメリットを早期に実現するには、要件を優先順位付けする必要があります。開発者は、最初に「必須」、「すべき」、 「可能」の要件をすべて実現しようとしますが、配信のタイムスケールが脅かされている場合は、「すべき」と「可能」の要件が最初に削除されます。
優先順位付けカテゴリのわかりやすい英語の意味は、高、中、低などの代替案と比較して、優先順位設定の影響を顧客がよりよく理解できるようにする上で価値があります。
カテゴリーは一般的に次のように理解されています: [3]
- 必須
- 「必須」とラベル付けされた要件は、現在の納品タイムボックスを成功させるために不可欠です。必須要件が 1 つでも含まれていない場合、プロジェクトの納品は失敗と見なされます (注:関連するすべての関係者との合意により、たとえば新しい要件の方が重要だと見なされる場合など、要件は「必須」から格下げされることがあります)。MUSTは、 Minimum Usable Subset (最小使用可能サブセット) の頭字語と考えることもできます。
- すべきだった
- 「すべき」とラベル付けされた要件は重要ですが、現在の配信タイムボックスでの配信に必須ではありません。「すべき」要件は「必須」要件と同じくらい重要ですが、時間的にそれほど重要ではないことが多く、要件を満たす別の方法があるため、将来の配信タイムボックスまで延期できる場合があります。
- 可能性があった
- 「可能」とラベル付けされた要件は、望ましいものの必須ではなく、わずかな開発コストでユーザー エクスペリエンスや顧客満足度を向上させることができます。通常、時間とリソースが許せば、これらが含まれます。
- （今回は）ない
- 「Won't have 」とラベル付けされた要件は、関係者によって、最も重要度が低く、投資回収が最も低い項目、またはその時点では適切ではない項目として合意されています。その結果、 「Wo n't have」要件は、次の納品タイムボックスのスケジュールには組み込まれません。「 Won't have」要件は、削除されるか、後のタイムボックスに含めるよう再検討されます。(注: 「Would like to have 」という用語が使用されることもありますが、この使用法は誤りです。この最後の優先順位は、明らかに納品の範囲外にあることを述べているためです)。(ビジネス分析ブックの第 3 版および第 4 版の BCS では、「W」を「今回は必要ないが、欲しい」と説明しています)
バリエーション
W はwish (またはwould )、つまりまだ可能だが、含まれる可能性は低い ( couldよりも可能性が低い) という意味で使用されることがあります。これは、明示的に含まれていない項目のexcluded (除外) を表す X と区別されます。would は、現在は必要ではないが、設計中に将来の拡張の機会としてアーキテクチャの観点から考慮する必要がある機能を示すために使用されます。これにより、将来特定の機能が提供されることを妨げる行き止まりの設計のリスクを回避できます。
新製品開発への活用
新製品の開発、特にアジャイル ソフトウェア開発アプローチに従う製品の開発では、時間や資金が許す範囲を超えて、やるべきことが常に多くなります (したがって、優先順位付けが必要になります)。
たとえば、チームの次の製品リリースで潜在的なエピック（つまり、高レベルのストーリー）が多すぎる場合、 MoSCoWメソッドを使用して、どのエピックが必須 で、どのエピックが必要かなどを選択できます。最小限の実行可能な製品（またはMVP）は、必須としてマークされたすべてのエピックになります。[4]多くの場合、チームはMVPを特定した後でも、予想されるキャパシティに対して作業が多すぎることに気付きます。そのような場合、チームはMoSCoWメソッドを使用して、どの機能（または、組織内のエピックのサブセットである場合はストーリー）が必須、必要ななどであるかを選択できます。最小限の市場性のある機能（またはMMF）は、必須としてマークされたすべての機能になります。[5] MVPまたはMMFを選択した後で十分なキャパシティがある場合は、チームは必須や必要 な項目も含める計画を立てることができます。[6]
批判
MoSCoW 方式に対する批判には次のようなものがあります。
- 同じ優先度内の複数の要件を決定するのに役立ちません。
- 競合する要件をどのようにランク付けするかについての理論的根拠の欠如：なぜ何かが「すべき」ではなく「しなければならない」のか。[7] [8]
- タイミングに関する曖昧さ、特に「含まれない」カテゴリに関して：今回のリリースには含まれないのか、それとも今後も含まれないのか。[7]
- 技術的な改善（リファクタリングなど）よりも新機能の構築に政治的に重点が置かれる可能性がある。[8]
その他の方法
製品の優先順位付けに使用されるその他の方法は次のとおりです。
参考文献
- ^ クレッグ、ダイ、バーカー、リチャード (1994)。ケースメソッド ファストトラック: RAD アプローチ。アディソン・ウェズリー。ISBN 978-0-201-62432-8。
- ^ Bittner, Kurt; Spence, Ian (2002-08-30).ユースケースモデリング. Addison-Wesley Professional. ISBN 978-0-201-70913-1。
- ^ 「MoSCoW 分析 (6.1.5.2)」。ビジネス分析知識体系ガイド(第 2 版)。国際ビジネス分析研究所。2009 年。ISBN 978-0-9811292-1-1。
- ^ Wernham, Brian (2012).政府のためのアジャイルプロジェクト管理。メイトランドとストロング。ISBN 978-0957223400。
- ^ Davis, Barbee (2012)。ウォーターフォールプロジェクトのためのアジャイルプラクティス：競争優位性のためのプロセスの転換。プロジェクトマネジメントプロフェッショナルシリーズ。J. Ross Publishing。ISBN 978-1604270839。
- ^ Cline, Alan (2015).現実世界におけるアジャイル開発. Apress. ISBN 978-1484216798。
- ^ ab Wiegers, Karl; Beatty, Joy (2013).ソフトウェア要件ワシントン、米国: Microsoft Press。pp. 320–321。ISBN 978-0-7356-7966-5。
- ^ ab McIntyre, John (2016年10月20日). 「モスクワかカノか - どのように優先順位をつけるか?」HotPMO! . 2016年10月23日閲覧。
外部リンク
- RFC 2119 (要件レベル) この RFC は、正式な文書で使用される要件レベルを定義します。これは、契約書やその他の法的文書でよく使用されます。文言は似ていますが、意味が必ずしも同じではないため、ここに記載します。
- バッファリングされた MoSCoW ルール このエッセイでは、成果物の優先順位付けと、基礎となる見積りの不確実性に応じた一定の保証を提供するという目的を達成する、修正された MoSCoW ルール セットの使用を提案します。
- MoSCoW 優先順位付け DSDM MoSCoW ルールに従った優先順位付けの手順とヒント。