書籍『誰も教えてくれなかったアジャイル開発』（日経BP）では、ウオーターフォール型開発が主流の「日本企業」で試行錯誤しながらアジャイル開発を成功に導いてきたコンサルタントたちが、自らの経験を体系化している。本書から抜粋し、初期計画段階における優先順位付けの進め方を解説する。（技術プロダクツユニットクロスメディア編集部）
ポイント（3） 4段階で優先順位を付ける
PO（プロダクトオーナー）やPPO（代理プロダクトオーナー）はプロジェクト初期段階で洗い出された全てのPBI（プロダクト・バックログ・アイテム）に対して、取り組む優先順位を付けていく。
優先順位を付ける際の手法としては「MoSCoW（モスクワ）分析」がある。同手法では以下の4段階で優先度を分類する。
- M（o）＝Must have（必須）:このPBIが実現されなければサービス／システムを導入する意味がない
- S＝Should have（推奨）:このPBIが実現されなくてもサービス／システムを導入する意味はあるが、導入メリットは大きく損なわれる
- C（o）＝Could have（可能）:このPBIが実現されなくてもサービス／システムを導入する意味やメリットがあるが、実現することでさらに大きなメリットを享受できる
- W＝Won't have this time（先送り）:このPBIは現時点で議論する必要がなく、実現しない
MoSCoW分析では、POやPPOは実現したい目的に合致しているかを軸に、法令や内部規制、関連システムを含めたシステム上の制約などの客観的観点を加味した判断基準を明確にし、ステークホルダーの合意を得たうえでそれぞれのPBIにM／S／C／Wを割り当てる。ここで注意が必要なのは「このPBIがない場合、業務が成り立つのか」という観点が漏れやすい点である。
優先度の高い「M（必須）」の機能だけを先にリリースしても、業務としては運用できない状態となりかねない。POやPPOが優先順位を付けたPBIを「ユーザー・ストーリー・マップ」で可視化することで、PBIがM／S／C／Wのどれに割り当てられているかを一目で把握しやすくなり、業務が成立するかを検証したりステークホルダーの合意を得たりすることが容易となる。
優先順位を可視化するユーザー・ストーリー・マップ
ユーザー・ストーリー・マップとは、業務フロー上に登場するPBIをM／S／C／Wにマッピングした表である。図の例は、ある派遣会社で契約社員管理をシステム化した際に作成したものである。
