MoSCoW

全てのステークホルダーを招集

あなたのプロジェクトにおけるステークホルダーで、このアクティビティに関与する人をこの場に招集してください。

要件を共有

要件をディスプレーかホワイトボード、あるいは大きな紙に書いて掲げてください。

要件の割り振り

下記の文字の内のどれかを、それぞれの要件に割り振ります。すべての要件を、まず“Won’t Haves（いらない）”から始め、そこから一つ一つをより高い優先順位に上げる必要があれば、その正当な理由を証明してください。なぜこの要件が必要なのか？を問いただしてみるのです。

Ｍ – 必須
このカテゴリーに割り振られた要件は、必ず解決策の一部を担います。これらの要件が全て満たされた時、その解決策は採用可能となるでしょう。

Ｓ – あるべき
このカテゴリーに割り振られた要件は、重要で高い価値がありますが、不可欠ではありません。解決策は、これらの要件が満たされなくても受容できます。

Ｃ – あってもいい
このカテゴリーに割り振られた要件は、解決策の一部であるが、選択の範囲にあります。もし時間とリソースが許すなら達成させよう、といいような任意の要件です。もし満たされなかった場合、その影響は“should have（あるべき）”要件よりも小さいものです。これらの要件が満たされないと、その解決策は採用されない、という訳ではありません。

Ｗ – いらない
これらの要件は、当初の解決策を何ら構成しえない要件ですが、その解決策が後に繰り返して利用される場合、追加される可能性があります。

これらの要件は解決策では関係しません。これらが示すものは、ユーザー体験に否定的な影響を与えるかもしれません。すなわち、ユーザーがニーズをみたすための解決策として選択しなくなるような、場をぶち壊すことになりえるということです。

Tip

この要件が達成できなかった時どうなるのだろう？と問いただしてみましょう。もし“この要件を達成できないような解決策は、実施する意味がない”という答えに辿り着いたら、その要件は “Must Have（必須）”要件となります。

ステークホルダーの中で違う意見が出たら、ドット投票 を活用すると意見の一致につなげることができるかもしれません。

条件の要約

それぞれのカテゴリーに割り振られた要件を共有しましょう。それらの要件を、アイデアを考案する時の条件として使ってください。

見直し

時間を追うごとにプロジェクトで必要とされるものは変わっていきますから、プロジェクトの期間中はずっと、これらの要件を見直し続けていってください。