BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース ビジネス価値を基準に(バックログの)優先順位を付ける

ビジネス価値を基準に(バックログの)優先順位を付ける

ブックマーク

ビジネス価値を基準に(バックログの)優先順位を付ける。Luke Hohmann氏は(リンク)、バックログのどの項目から検討を始めるべきかについて定量的な判断を下す方法を述べている。Luke氏は、実装の取り組み方のようなお決まりの特性に加えて、ステークホルダの要求と戦略的な位置づけを見計らいつつ、ビジネス的価値の有無を問うような特性を追加することを提案している。

今週行われたAgile2008で、Luke氏は(リンク)下記の手法の概要を説明した(リンク)。これは彼のプレゼンの要約だ。

優先順位付けをするための特性を選ぶ

バックログの項目を並び替えるときに便利なように、特性を一通り決めます。特性のスコアを決めるのにかかるコストについても評価しておいた方がよいでしょう。(全く新規の市場を調査するというような)特性のスコアを出すのに必要なデータを手に入れるのは、高いコストがかかるかもしれません。その特性のスコアを出す過程で得られる利益が、コストに見合うかどうかバランスを取る必要があるでしょう。

類似している特性はまとめて考慮できるように、関連する特性をグループ分けします。Luke氏は、バックログにある項目それぞれのビジネス的価値に焦点を当てる手助けとして、3つのグループ分けを提案しています。

  1. ステークホルダの基準 (「これが完了するのを望むのは誰だろうか?」)
  2. 戦略的な基準(「なぜこれをしているのだろうか?」)
  3. 利益の原動力(「これはお金やコスト削減に結びつくのだろうか?」)

ステークホルダの基準は、プロジェクト(内外の)のステークホルダのリストで、ステークホルダ毎に特性1つとします。例えば、営業、法務、顧客、オペレータ、開発者、そして「システム」もそうです。「システム」とはプログラム自身を表していて、バックログの項目の中では、プログラム的な改善点とう形で表現されるものです。例えば、技術的な負債や、何某かのフレームワークの更新する、などといった利害もそのひとつです。

戦略的な基準という観点では、プロダクトマネージャは、まずプロダクトを作るための戦略を見つける必要があるでしょう。ここで戦略というのは取締役会で設定されているだろう事業部計画や会社的な目標も含んでいます。Luke氏は、例として「グローバル」で「社会的」で「モバイル」といった特性から、戦略的な目標を導き出した会社の例を挙げています。

利益の原動力の特性は、どうやって製品からお金を産み出すか、そしてバックログの項目がお金とどんな関係を持っているかを明らかにするものです。端的に言えば、「収入を増やし」て、「コストを下げる」ような特性と言えます。

結果がどのようなものになろうと、順位付けプロセスの透明性を高めるためにも、順位付けの決定は特性によってなされるべきです。他にも特性となりうるものがあった場合、例えば法令遵守の規定を満たす必要があろうとも、そこに営業担当が居たとしても、仮に迅速な製品化に結びつくとしても、そういった特性については「次のリリースを待つ必要があります」と言ってしまえばよいのです。

個々の特性に重みを付ける

特性が、他の特性にとってどれだけ重要な関連を持っているかを表現するものとして、特性の重さを決めていきます。

プロダクトが進化していくのに応じて、この重みづけを変えてもいいでしょうし、そうすべきです。計画完了時はいつでも、重みづけの再評価をすべきです。開発の段階によって、いろいろなステークホルダが関わってゆき、それぞれに重みづけをしてゆきます。最初のうちは、運用よりもおそらく営業と顧客のステークホルダが、より重要な位置づけにあるでしょうから、新機能はバックログの中でより重い位置を占めます。終わりの方の(たぶんリリースに近い)イテレーションでは、デプロイとか運用に焦点あたるようになります。従って、営業と顧客の重みづけは減ってゆき、結果的に運用を行うステークホルダの重みが増していきます。この影響で、バックログの中の運用関係の項目がより重要な位置づけになっていきます。



特性の集計

全てのバックログの項目に対して、リストにある全ての特性を、はい/いいえで答えられる質問として投げかけてください。例えば、それぞれのステークホルダの代表する人に、「この項目が実現したら、あなたの仕事に役立ちますか?」と尋ねてみてください。ある特性対する回答が、全てのバックログ項目で同じだとしたら、その特性からは順位付けをするための情報は得られていないということなので、立ち返って特性を変更する必要がある、とLuke氏は指摘しています。また特性を2つ以上の特性に分割することで、バックログの項目を異なる視点からもっとよい捉え方ができるようになることもありますし、逆に特性を除去することで、最適な判断ができるようになることもあります。



はい」と答えた特性については、バックログ毎の項目のスコアの合計に、その特性に設定した重さを足してあげてください。全ての特性のスコアを、各項目について集計すると作業は終わりです。

バックログの項目を並び替える

最後に、バックログの項目をスコアによって分類して、スケジュール(イテレーション計画、リリース計画)をたてます。Luke氏は、ステークホルダは少なくとも1つは項目を持っているようにし、さらに、それぞれの項目には、少なくとも1つは戦略的な基準のグループの中の特性が「はい」となるように、少なくとも1つは利益の原動力グループの特性のが「はい」となるように調整した方が良いと言っています。こうすることでバランスのとれたバックログを持った仕事、つまり全員が楽しく、貢献できる仕事ができるようになります。


Agile2008のプレゼンでは、Luke氏はバックログの優先順位付けをした集計表の見本を見せていた。この内容はほどなく彼のウェブサイトにポストされるだろう(リンク)。彼のウェブサイトには、この話題に関する他(リンク)の記事や(リンク)、別のツール、バックログの優先順位付けをより洗練させるためのアイデアなどを(リンク)発見することができる。あなたが行き詰まったときの手助けになるはずだ。

原文はこちらです:http://www.infoq.com/news/2008/08/Hohmann-prioritization-profit

この記事に星をつける

おすすめ度
スタイル

BT