従来のアジャイル開発では優先順位をつけるとき、ビジネス価値の低いユーザストーリーよりもビジネス価値の高いユーザストーリーを優先して実装するようにする。このやり方はシンプルだが、うまく実装できるかどうかはビジネス価値を評価する仕組みがあるかどうかにかかっている。 Pascal Van Cauwenberghe氏は最近、ビジネス価値を定義する方法について説明している。この方法は"ビジネス価値モデリング"と呼ばれ、役に立つかもしれない。
ユーザストーリーのビジネス価値はどうやって見積もる? いや見積もれない。と題した記事で氏が警告しているのは、ユーザストーリーが前提にあり、そのユーザストーリーのビジネス価値を評価する、という想定には根本的な欠陥がある、ということだ。そして、より優れた出発点として次の質問を考えることからはじめることを提案している。すなわち、"どうやったらビジネス価値を生み出すユーザストーリーを見つけられるか?"。そして、氏はこの方法についていくつか提言を続けている。
- プロジェクトや製品を立ち上げる前に、どのような価値(または利益)を手に入れたいのかを決める。
- そして、その価値を生み出すビジネスプロセスを発見し改善する。
- さらに、価値を生み出すプロセスを成立させるために必要な補助的ビジネスプロセスを発見し改善する。
- チームがユーザストーリーを必要とするときは、最高の価値があるビジネスプロセスをチームにとって最適な大きさのユーザストーリーに砕く。そうすれば、チームは自分たちでそのストーリーを発展させるので、最低限のユーザストーリーだけ作っておけばいい。
さらに続きの記事で、氏は"ビジネス価値"という言葉自体を検討している。'株主価値'のような単一の評価基準を退けながら、氏は、大抵の場合、異なるゴールやニーズをもった様々な利害関係者がいることを指摘している。氏は自身が"ビジネス価値モデリング"と呼んでいる作業を行っている。これには下記のような作業が含まれている。
- 利害関係者を特定する。
- 利害関係者のニーズとゴールを特定する。
- そのニーズやゴールに対する達成度の評価/検証方法について合意を形成する。
- (少数の)最も重要な評価基準や検証方法、“価値要素”を選択する。
- それぞれの価値要素の間の関係を定義する。
- はじめから終わりまで、価値要素に基づいて作業に着目し、作業の優先度を付ける。
上述した方法と同じような方法についてBrandon Carlson氏があっという間のユーザストーリー優先順位付けと題した記事で書いている。氏の方法では、まずビジネス価値に貢献するような特性を洗い出すことからビジネス価値の構築を始める。氏のチームは、契約上の義務、製品投入の時期、顧客へのインパクト、システムの可用性、経営戦略等の観点からそのような特性の一覧を作成した。そして、これらの分野の専門家がそれぞれの特性について影響の度合いを見積もる。そして見積もりを元にして開発予定の機能のビジネス価値を算出する。
一度、すべてのステークホルダーが自身の専門とする特性について見積もりを行うと、それらの見積もりを集計します。そして、製品を最も良い影響を与えると見積もられた特性が一覧の一番上にきます。ディベートはしません(確かに少しはしますが、以前ほどではない)。集計結果の数値だけで決定します。このような方法を採用することで[優先順位付けの]ミーティングの生産性に顕著な改善が見られました。基本になる優先度はミーティングの最初の数分で決まります。ミーティングの時間も以前は1時間半くらいかかっていましたが、大幅に削減でき30分くらいになりました。
Mike Cohn氏は"製品のバックログに優先順位をつける"と題したプレゼンテーションの中で、ビジネス価値を評価する様々な方法を提示している。これらの方法には"テーマの抽出"、"テーマのスコアリング"、"相対比重の算出"、"狩野分析法"が含まれている。また、このプレゼンテーションの一環としてScrum Allianceのサイトで、氏はテーマ(テーマとは関連するユーザストーリーの集合のこと)に価値を割り当ているための財務的なモデルを正味現在価値と内部利益率の観点から説明している。
生産性の評価基準と題した記事のなかで、James Shore氏はビジネス価値を計る方法がなければ、生産性に対して満足の行く評価基準を作ることができないことを指摘している。
作業をするプログラミングチームのアウトプットを定義して、そのチームのソフトウエアがどの程度ビジネスに影響を与えるのか探れます。利益を算出したり、費用対効果を計算したり、また、その他のビジネス価値を反映した値を見積もることもできるでしょう。
このトピックについては、氏はバリューベロシティ: より優れた生産性の評価基準?という記事でも触れている。氏はこの記事で、ビジネス価値の優れた評価基準を作成するのは難しい、認めている。
私はこの方法が気に入っていますが、しかし、欠点があるのも事実です。価値を測定するのは本当に難しいです。ある種の価値ある仕事をしても直接セールスの改善に結びつきません。チームの作業とは関係なしに価値が発生することもあります。従来のやり方の中では価値を発揮しないユーザストーリーもあります。厄介なバグを修正した場合の価値はどのくらいでしょうか。そのソフトウエアと同じくらいの価値があるのでしょうか。それとも、全くないのでしょうか。ソフトウエア全体の仕上がり具合の価値についてはどうでしょう。
ビジネス価値の見積もりを作成する方法として最終的に氏が提案するのは、アジャイルチームが作業見積もりを作成するのと似たような方法だ。Kelly Waters氏もアジャイルソフトウエア開発のビジネス価値を見積もると題した記事でこの方法を推奨している。ストーリーの大きさを考慮する一方で、氏は各ストーリーに対して関連するビジネス価値を割り当てるためにフィボナッチ数の目盛りを利用している。
開発チームが点数を使って見積もりをするのと同じように、プロダクトオーナーも各項目に対して、相対的なビジネス価値を決めます。このとき重要なのは、このビジネス価値は相対的なものであるということです。例えば2ポイントのビジネス価値を持つ特性は、1ポイントのビジネス価値を持つ特性よりも2倍の価値があります。５ポイントなら1ポイントの５倍の価値があるということになります。このようにバックログの各項目にポイントを付与することで'ビジネスベロシティ'を算出できます。例えば、各スプリントでどのくらいのビジネス価値(点数)を生み出すことができるかわかるようになります。この点数を'右肩上がりのグラフ'にすれば、継続的に価値が提供され続けていることが視覚的にわかるようになるでしょう。
あなたの組織ではどのようにしてビジネス価値を見積もっているだろうか。それは開発者の優先順位付けにどのくらい影響を与えているか。コメントを投稿してあなたの経験と意見を共有してみてはどうだろう。