MoSCoW法：会議後に要件の優先順位を付ける方法

優先順位は目標と期間で決まる

会議で全員が自分の機能を必須と呼ぶと、対象範囲を選べません。まず次のリリースで何を実現し、何が欠けると使えないのかを合意します。段階が変われば分類も大きく変わり得ます。

MoSCoW法にはMust Have、Should Have、Could Have、Won’t Have this timeの四つがあります。最後の分類は、対象期間から意図的に外すという意味です。将来の対応を約束するものでも、案を永久に退けるものでもありません。

外した場合の影響を話し合う

1. リリースの目標を書く

   利用者、タスク、使用条件を記録します。制約と計画期間も明確にします。目標が「製品を改善する」だけでは、判断基準がそろわず、ほぼすべてが必須になってしまいます。

2. Mustの候補を検討する

   要件ごとに、それがなくても使える成果が得られるか尋ねます。許容できる回避方法や依存関係も検討します。必須には具体的な根拠が必要です。「責任者が頼んだ」では要望の出所は分かりますが、除外の影響は分かりません。

3. 重要なものと望ましいものを分ける

   Shouldは、なくなると成果が明らかに弱くなるものの、利用はできる重要項目です。Couldは、比較的外しやすい有用な追加要素です。「どうしても欲しい」といった言葉だけでなく、利用場面と欠けた場合の影響で違いを説明します。

4. 除外項目と見直し条件を合意する

   今回のWon’tには理由と再検討の条件を書きます。要件の依存関係と、選んだ範囲を実現できるかも確認します。必須の作業が処理能力を超えるなら、範囲か計画を見直します。分類の文字を変えても作業量の問題は解決しません。

イベント申込フォームの初回リリース

以下は架空の学習用事例です。名称、条件、結果は手順を説明するためのものです。

この例の目標は、参加者を登録し、分かりやすい確認を返すことです。申込を送信できないと主な利用場面が成り立たないため、これはMustです。合意した代替手段で一時的に対応できるなら、リマインダーはShouldにできます。

名札の色はCouldとし、個人アカウントは今回は外せます。分類はこの例に限ります。イベントや対象者が違えば、影響も異なります。

優先順位の根拠カード

分類と一緒に判断の根拠も残します。条件が変わったときに決定を見直しやすくなります。

リリース／期間／目標：
要件：
利用シナリオ：
要件がないと何が起きるか：
許容できる回避方法の有無：
依存関係：
MoSCoW分類：
選択の根拠：
決定を確認した人：
見直し条件：
この期間に含めない項目：

一覧が判断に役立つか確認する

• 分類と並べて目標と期間が書かれている。
• 各Mustについて、外した場合の影響が書かれている。
• 一時的な代替手段を明示的に評価した。
• 今回はWon’tという分類が、今回の除外として理解されている。