2010年7月12日

要求定義フェーズにおいて、要求に優先順位をつけることは難しいようです。それはなぜでしょうか。

よく耳にするのは以下のような理由です。

　－ユーザー（発注側）が優先順位をつけてくれない

　－ユーザー（部署）によって、優先順位が異なる。誰も調整してくれない。

　－大きな声のユーザーの要望を受け入れる傾向にある。

多くの読者も似たような経験をされているのではないでしょうか。上のようにユーザー側が決められないのはなぜでしょうか。それは使う立場によって、ソリューションへの期待がユーザーごと（部署ごと）に異なるからです。

大変厄介なことのようです。

インプット：　－ビジネスニーズ
　　　　　　　　－ビジネスケース
　　　　　　　　－要求（*）
　　　　　　　　－要求マネジメント計画
　　　　　　　　－ステークホルダーのリスト、役割、権限

BABOK(R)では比較的容易に優先順位を付けることができます。

最も重要な要素はビジネス価値です。どんなに立派な要求でもビジネスに価値をもたらさない限り取り入れるべきではありません。当然実装のコストも考慮します。すなわちコストパフォーマンスということになります。
インプットにビジネスニーズやビジネスケースがあるのはそのためです。

つづいて、実装の難易度もあります。実装が容易なものから考慮します。

全体を次の図にまとめると分かりやすいと思います。

ビジネス価値　　　　　実装の難易度

　高い　　　　　　　　　　低い　　　　：なるべく早く実装するべきものです。

英語ではLow Hanging Fruits（手を伸ばせば届く

おいしい果物）

　低い　　　　　　　　　　低い　　　　：積極的に取り上げるべきほどの物ではありませんが、

他の優先順位の高い要求を支援するものであれば

考慮します。

　高い　　　　　　　　　　高い　　　　：一番悩むものです。

　　　　　　　　　　　　　　　　　　　　　　　これ以外の要素、例えば法的規制、緊急性、

　　　　　　　　　　　　　　　　　　　　　　人命に係るような場合は取り入れざるを得ない

　　　　　　　　　　　　　　　　　　　　　　ものです。

　低い　　　　　　　　　　高い　　　　：当然、取り入れてはいけないものです。

もうひとつ、優先順位付けの方法を紹介します。

スコアリングマトリクスの応用です。少し複雑です。

　　　　　　　　　　　　　　　　　　　　「ソフトウェア要求」（Karl Wiegers）より筆者がカスタマイズ

1.機能（要求）の相対的利益を明確にします：最も高いと思われるものに満点（上図の場合は9点）を与えるのがよいでしょう。他の機能（要求）はその満点の機能に対して相対的な点数をつけます。

2.相対的不利益は、その機能がなくても困らなければ最低点（1点）、その機能がなければ非常に困るものに最高点（9点）を与えます。

3.さらに相対的利益には重要度として2倍の重みづけをし、合計価値を算出します。

4.合計価値を足したもの（上図の場合は131点）で各機能の合計価値を割り、価値%を算出します。

5.同様に相対的費用も算出し、費用%を算出します。

6.価値%と費用%の比をとれば優先順位の数字が算出されます。

単純なスコアリングマトリクスなので、試してみる価値はあると思います。数値化されるので説得力があるかもしれません。さらに、リスクを加えるなどして、ご自分の組織に適したものを構築されることを勧めます。物事を数値化したもので意思決定する組織文化には向いています。

中身をみると、Low Hanging Fruitsが優先順位が高いこともよくわかります。何も数値化しなくても図で意思決定できるという組織文化もあると思います。それぞれの組織に合う優先順位付け方法を確立されることです。

その他のテクニックとして、MosCow分析、投票などがあります。BABOK®ガイドをお読みになればお分かりになると思いますので、解説は省略します。

大事なことはなるべく早めに優先順位を付けることです。さまざまな要求（*）は「要求を体系化する」タスク、および「要求の仕様化とモデリングを行う」タスクを経て「ステークホルダー要求」および「ソリューション要求」にまとまります。モデリングは時間とコストのかかる作業です。せっかく手間暇かけてモデリングしたあとで、優先順位が低いことが分かったらどうなるでしょうか。優先順位の低いものは実装されませんから、モデリングの手間と労力が無駄になってしまいます。ですからなるべくモデリングする前に優先順位を付けておくことが好ましいと言えます。

「ビジネスに直結するソリューション/システム」を実現するために極めて重要なタスクの一つです。