生まれた背景と役立つ理由
MoSCoW法は、ソフトウェア開発やアジャイル型のプロジェクト管理の現場で、長い採点方式を使わずに優先順位についてすばやく共通認識を持つための方法として生まれました。最大の強みは、「必須」とは実際に何を意味するのかを明示的に交渉させる点にあります。チームは往々にして、MustとShouldの境界線をどこに引くかで最も意見が分かれるものです。
バランスを取るためのよく使われる目安
よく引用される(ただし絶対的ではない)目安として、Must haveの項目を全体の作業量のおおよそ60%以下に抑え、Should haveやCould haveの項目にも意味のある余地を残すという考え方があります。すべての項目がMust haveとされてしまうと、本来の「実際にトレードオフを迫る」という分類の役割が失われてしまいます。
よくある質問
MoSCoW法と、タスクに単純に1、2、3と順位をつけるのはどう違いますか?
番号による順位付けは、すべての項目が他のすべての項目とちょうど1段階ずつ違う優先度だと暗に示してしまいます。一方MoSCoW法は、項目を少数の、意味のある違いをもったグループに分けるため、細かい順位について議論するより、チームとして早く明確な合意に至りやすくなります。
何をMust haveとするかは誰が決めるのですか?
理想的には、特定の1人が一方的に決めるのではなく、関係者全員で話し合って決めます。MoSCoW法で最もよくある失敗は、全員がそれぞれ自分の項目を密かにMust haveだと思い込み、それを他の項目と照らし合わせて検証しないまま進んでしまうことです。