この国では犬が

本と芝居とソフトウェア

【翻訳】忘れられたプラクティス: バックログ優先順位ゲーム(Backlog Priority Game)

この記事は、Forgotten practices: The Backlog Priority Game (Zuzi Sochova) の翻訳です。


バックログの優先順位付けは、多くの企業にとってアジャイルの受容におけるもっとも難しい部分の一つです。では、それを正しく行う方法は何でしょうか? 推奨事項や、何らかの手法があるのでしょうか。それとも、プロダクトオーナーが決めればそれで十分なのでしょうか? こういった質問や、似たような質問がよく出てきます。

バックログの優先順位付けについて、最もよくあるシナリオは次のような主張から始まります。「要件の優先順位は常に定めてきたし、今までそれなりにうまくいってるのに、どうして何かを変える必要があるっていうんだ?」 ところが、そのプラクティスをよく見て理解しようとしてみると、現実は通常、まったく調和の取れたものではないことがわかります。チームは個々の機能のビジネス価値の理解度が非常に低く、いずれにせよ全部終わらせる必要があることを理由に、たいていは自由な順序で取り組みます。ビジネスが興味を持っているのは、予定通りリリースが行われるかどうかだけです。そういうわけで、アジャイルを始めたら、ユーザーストーリーは3種類の優先度を持つことになります。全機能の 60% は優先度「1」、必ず含める必要のある機能という意味です。約 30% は優先度「2」、これもまた必要な機能です。残り 10% が優先度「3」、これもほとんどの場合は含めるべき機能です。もしかすると、「優先順位付け(prioritization)」という言葉は間違っていて、「並び替え」という言葉を使うほうがよいのかもしれません。とはいえ、どんな表現であっても誤解されることはあるので、問題の原因を名前に押し付けるわけにはいきません。このような機能不全のプロダクトオーナーの影響下にあるチームには、うまくやるためのいくつかの選択肢があります。一つは、ギャップを乗り越えて、失われたビジネスのコンテキストをできるだけ速く把握しようとする「プロダクトオーナー代理」の役割を置くことです。もう一つは、プロダクトオーナーを押し返して、次のスプリントの優先順位を決めることはプロダクトオーナーの責任であり、決めてくれないのならアルファベット順に取り組むだけだと単に伝えることです。

バックログをこのようなやり方で並べ、チームの実際のベロシティに基づく太くて赤いラインを引いてプロダクトオーナーに示し返せば、どの機能が次のリリースに含められ(ラインより上)、どの機能が含められそうにないか(ラインより下)を可視化することができ、たいていはプロダクトオーナーを優先順位付けのプロセスに立ち戻らせることができます。このような状況は、プロダクトオーナーが行動を起こし、実際の優先順位と機能性の変更を検討し始めるのに十分な強さのプレッシャーを生み出すのです。「相対重み付けゲーム(Relative Weight Game)」をプレイする時が来ました。

あなたは、プロダクト企業の一員だとします

その場合、優先順位付けの鍵はシンプルです。ビジネス価値と、そのコストに着目するのです。コスト対価値の比率が大きければ、その機能に投資します。小さければ、改善のためのアクションを取るか、バックログからその機能を削除します。

このアプローチをサポートするのが、以下の手法です。目新しいものではありませんすが、やり方を知っているチームは多くはありません。この手法は、アジャイルチームでユーザーストーリーの見積もりによく使われる相対ポイント見積もりと同じ原則にのっとり、相対的な重みにもとづいています。考え方はシンプルです。アジャイル手法の力のほとんどはチームワークに由来するので、プロダクトチームを作ることから始めます。プロダクトオーナーは実際には一人でこのゲームをプレイすることもできますが、その場合、他の人たちの視点を欠くことになります。議論の欠如によって予期しない問題に遭遇したり、ビジネス価値の重要な側面を見逃すことになるおそれがあります。チームの構成は、プロダクトや企業の構造、役割によって異なるかもしれません。ある程度のカスタマイズが可能なパッケージ製品を作っている企業の場合、プロダクトオーナーは通常、ビジネスアナリスト、UX デザイナー、ソフトウェアアーキテクト、マネージャといった人たちを巻き込むことになるでしょう。ある時点で、コンサルタントや顧客の代表者にも議論に加わってもらうかもしれません。ユーザーストーリーの優先順位についての決定は、それでもプロダクトオーナーに委ねられています。とはいえ、そういった人びとによる議論はたいてい非常に価値あるものとなりますし、プロダクトオーナーが一人で優先順位を決めた場合よりもずっと質の高い決定を下すことが可能になります。

プロダクトオーナーはなお、このプロセスのキーパーソンです。プロダクトオーナーはミーティングを主催し、議論をファシリテートします。意思決定、全体的な機能性、ひいてはプロダクト全体の成功に責任を負うのです。ユーザーエクスペリエンスの専門家の役割は、企業ではしばしば過小評価されています。しかし、そのような専門家はプロダクトの成功にとって必要不可欠です。ビジネス価値に対する彼らの視点は、最終的なプロダクトのほとんどに欠けているものかもしれません。そのような専門家たちは、プロダクトオーナーがビジネス価値を保ちながら機能をシンプルにするのに役立ちます。そういったチームに求められる次の役割としてあげられるのは、ビジネスアナリストです。その役割自体は、かなり論争の的になっています。多くの場合、ROI とのつながりがなく、すべての潜在顧客の要求を満たすために機能をできる限り拡張しようとするからです。特に、誰もが自分の役割に固執し、コンピテンシーが役割ごとに正式に分けられているような形式ばった環境ではこれが顕著です。この場合、プロダクトオーナーは抽象度の高いビジョンと戦略を持ち、個々のユーザーストーリーの詳細には関与しません。一方、ビジネスアナリストは、顧客との関係や環境の詳細に通じていないのです。そのため、それらの人たちを集めて共通の目的を持つ単一のチームを作ることは実際よいアイデアであり、それ自体かなり有効になりえます。他の役割としては、ソフトウェアアーキテクトがあげられます。ソフトウェアアーキテクトは、プロダクトオーナーが技術的なリスクを取らずにすむようにできます。たとえば、チームがこれから必要になる技術の経験がないとき、課題に対するスパイクを打ってプロトタイプを構築したり、リスクを解消するために一つのユーザーストーリーを届けることが賢明かもしれません。結局のところ、可能な限り顧客と接し、技術的な観点から意味があるだけではなく、ビジネス上の理由からも投資に値する解決策を提案することはアーキテクトの役割です。このグループのメンバーは、ここで言及した役割に限りません。価値ある意見を出してくれそうな人であれば、誰でも招待してください。

ビジネス価値の見積もり: 相対重み付けゲーム

プロダクトチームができたら、ビジネス価値を見積もるためのポイントを用いて、ゲームを始めることができます。ポイント見積もりのプロセスにおいて議論は最も重要な部分なので、ビジネス価値見積もりのゲームにおいても同様です。あなたはチームとして、バックログに含まれるすべてのユーザーストーリーに対して 2 つの独立した値を見積もることになります(なお、バックログが議論を方向付けます)。チームはさまざまな種類のメンバーで構成されているので、すべての異なる側面が考慮されます。最初に見積もる値は、「ベネフィット」です。その機能の価値にどれほどの重み付けをするか、ということを意味します。2 つ目の値は、「ペナルティ」で、そのユーザーストーリーを実装しなかった場合の損失の重さを表しています。それぞれの見積もり値は、同じ種類のもの同士、相対的な値です。通常は、いずれも 0 から 100 までの範囲の値で見積もります。たとえば、あるユーザーストーリーがマーケットにおけるどのプレイヤーもが持っている機能を表していて、ゆえに実装が期待されているなら、0 に近いとても低いベネフィット値と、100 に近いペナルティ値を与えられるかもしれません。逆に、あるユーザーストーリーが競合他社に対する差別化要因となり、かつユーザーにとって本当に重要なものであれば、そのような機能が実装されるとは誰も予期していないわけなので、ベネフィット値は 100 に近く、ペナルティ値は 0 になるかもしれません。キーとなるストーリーはベネフィットもペナルティも 100 になるかもしれませんが、ほとんどの機能には中間の値が与えられるはずです。ベネフィットとペナルティは互いに独立していることを忘れないでください。値を得るためにプランニングポーカーや魔法見積もり(Magic Estimations)を行うこともできますが、よい見積もりを得るにあたっては、数字はあくまで議論の脇役にすぎないことを覚えておいてください。早く結果を得るために議論を省略してはいけません。ビジネスの視点が必要なので、顧客の立場から見積もりを見るようにしましょう。これは普段やっていることとあまり変わらないと思うかもしれませんが、ベネフィットとペナルティという 2 つの異なる見方をする必要があることで、重要な側面を決して見落とさずにすみます。企業による優先順位付けのほとんどは直観だけで行われていて、ベネフィットの方のみを考慮し、ペナルティについては目立って明らかな場合にのみ検討するのが普通です。

ベネフィット値とペナルティ値がわかったら、それらの見積もりを合計してビジネス価値(BV)を算出します。

ベネフィット + ペナルティ = ビジネス価値(BV)

その数値は 0 から 200 の間になります。これで終わりにして、ビジネス価値に応じてバックログの優先順位付けをすることもできます。しかし、多くの場合では、もう少しゲームを続ける必要があります。各ユーザーストーリーのビジネス価値/コスト比を比べるために、チームにストーリーの複雑さを見積もってもらうのです。その計算結果が、バックログアイテムの優先度になります。

優先度 = ビジネス価値(BV) / 複雑さ

ビジネス価値に対するコストが低い「クイックウィン」がバックログの一番上に行き、範囲が広く難しい機能ながら価値は限定的なものが一番下に行くことがわかります。なお、これらは単なる数字にすぎないので、結果が気に入らない場合は変えても構いません。ただし、よりよく見て、議論の内容をもう一度思い出すことを検討するとよいかもしれません。すると多くの場合、ベネフィットとペナルティが独立した値として正確には見積もられていなかったことに気づくでしょう。もっとよくあるのは、ビジネス価値/コスト比を改善するためにユーザーストーリーをより小さなストーリーに分割する必要性に気づくことです。ビジネス価値と複雑さが機能性の全体にわたって均等に分布していることなどないからです。価値を届けられるけれども、実装はそれほど難しくなさそうな要素があることに気づくでしょう。一方で、限られたビジネス価値しかないけれども、機能実装の足手まといになる要素もあるでしょう。たとえば、あらかじめ定義されたフィルタを用いてデータをチャートに描けば、ユーザーの要求を満たすのに十分かもしれませんが、顧客がフィルタを作れるようにするのは難しいかもしれません。いくつかの調査によると、成功したプロジェクトの約 60% は一度も使われたことがないか、ほとんど使われていないということを忘れないでください。機能を削るのは難しいことですが、優先順位付けのプロセスに顧客を巻き込み、機能のコストを説明すれば、顧客はすぐに賛成してくれるかもしれません。

相対重み付けゲーム(Relative Weight Game)はアジャイルコミュニティでもあまり知られていませんが、プロダクト指向の開発においてとてもよい結果をもたらします。さらには、簡単に、楽しくプレイすることもできるのです。

この記事は、2013 年 5 月 の Agile Record No14 に掲載されました。