優先順位付け
Mitch Lacey 著。 アジャイルとスクラムの導入と改善に特化したコンサルティング会社である Mitch Lacey & Associates, Inc の経営者です。
2012 年 1 月
この記事では、Mitch Lacey は多くのアジャイル チームで特に有効であると証明された 3 つの方法を説明しています。顧客満足度の Kano モデル、Luke Hohmann による一連の Innovation Games、Karl Weigers の相対的な重み付けのモデルです。 これらの方法のいずれかを使用すると、バックログの大まかな優先順位付けから、リスク、重要性、および顧客満足度を十分に評価した正確な順序付けに移行することができます。
対象
アプリケーション ライフサイクル管理; Team Foundation Server
この記事の内容:
はじめに
顧客満足度の狩野モデル
イノベーション ゲーム
製品ツリーの剪定
機能の購入
相対的な重み付け – Karl Weigers
まとめ
アジャイル チームが有効に機能し続けるには、プロダクト バックログの項目を重要性に応じて順序付けした後、プロジェクトが進行するにつれてそれらの優先順位を更新する必要があります。 すべてのプロダクト バックログには、ビジネス価値とリスクに基づいて優先順位を付ける必要があります。 この優先順位を認識することで、チームは、製品の成功に寄与する可能性が最も高い機能に労力を集中することができます。 バックログを適切な優先順位で順序付けすることは、チームと顧客満足度にメリットがあるだけでなく、ビジネスの最終的な収益も向上させます。 バックログの詳細については、「プロダクト バックログの構築と管理」、「バックログの作成」、および「バックログのグルーミングと見積り」を参照してください。
プロダクト バックログに優先順位を付けるときは、多くの要因を考慮するだけでなく、意思決定を正当化できなければなりません。 未加工のプロダクト バックログから作業を開始する場合、最初はプロセスがほとんど手に負えないものに思えるかもしれません。 しかし、すべてのバックログ項目を今すぐ完璧に順序付けする必要はありません。 「見積もり」では、「大きな壁」と名付けた手法を説明します。これは、未加工のプロダクト バックログを素早く評価し、利害関係者と協力して大まかな優先順位付けに到達する効果的な方法です。
この大まかな優先順位付けは開始点として適切であり、状況によってはこれで十分な場合があります。 しかし、場合によっては、このような優先順位を改良する必要があります。つまり、より科学的な方法でバックログに優先順位を付ける必要があります。 このために使用できる手法が多数あります。 この記事では、多くのアジャイル チームで特に有効であると証明された 3 つの方法を説明します。顧客満足度の Kano (狩野) モデル、Luke Hohmann による一連のイノベーション ゲーム、Karl Weigers の相対的な重み付けモデルです。 これらの方法のいずれかを使用すると、バックログの大まかな優先順位付けから、リスク、重要性、および顧客満足度を十分に評価した正確な順序付けに移行することができます。
顧客満足度の狩野モデル
顧客満足度の狩野モデルは、東京理科大学の狩野紀昭教授によって 1980 年代に開発されました。 このモデルは、不可欠な属性と差別化する属性を区別する単純な順位付けの方法です。 質問に基づいた方法をとるこのモデルは、製品の特徴を視覚化して、設計チーム内の議論を刺激する効果的な方法です。
.png "製品機能グラフの例")
狩野モデルでは、一連の質問を充足と不充足という 2 つの形式で行います。 たとえば、自動車の GPS ナビゲーション システムについてお客様に質問するとします。 まず、充足形式の質問をします。
- この車に GPS ナビゲーション システムが装備されていたらどう思いますか。
回答は次のものに限定します。
好ましい
どちらかというと好ましい
どちらでもよい
どちらかというと好ましくない
好ましくない
この例では、架空のお客様が「好ましい」と回答したとします。
次に、不充足形式の質問をします。
- この車に GPS ナビゲーション システムが装備されていなかったらどう思いますか。
架空のお客様は、前に挙げた回答のうちいずれかを選択できます。 最初と同じ回答をすることもできますが、たいていは異なる回答になります。 この例では、架空のお客様が不充足形式の質問に「どちらかというと好ましい」と回答したとします。
実際のプロジェクトでこれを行う場合は、このような逆の質問をお客様の複数のグループ (お客様の組織のさまざまな職務を代表する人たち) に尋ねることができます。 マーケティング グループ、会計グループ、製造グループ、などです。 ここでは、このモデルについて理解する目的のために、お客様の 1 つだけのグループに 1 つの質問をしたと想定します。 回答のペア (充足形式と不充足形式の質問への回答) を集計し、表 1 の各欄に記入します。
.png "Kano マップの例")
表 1 – 狩野マッピング
この例では、架空のお客様が充足形式の質問に対しては「好ましい」と回答し、不充足形式の質問には「どちらかというと好ましい」と回答したことに注目してください。 表にこのペアを記入すると、2 つの属性の交差部分が E であることがわかります (黄色で示してあります)。 これはバックログの優先順位付けでは何を意味しているのでしょうか。
E = 魅力的。 これらは、お客様が当然とは考えていなかった機能であり、競合他社に対して製品を本当に差別化できる機能です。 特に最初のうちは、これらを特定するのは困難です。魅力的な機能を引き出す質問を考えつくのが難しい場合があるからです。 したがって、魅力的な機能は、プロジェクトが進行してお客様からのフィードバックが始まってから優先順位内に登場し、上昇する傾向があります。
お客様は、このような機能に深い満足感を覚え、そうした機能を得るために代価を払う意思があります。 たとえば、Apple 社の iPod は、画面の向きに合わせてコンテンツの向きが変化する直感的な機能でお客様を喜ばせました。 しかし、この機能がなくても満足感は減少しないと思われます。お客様はそのような機能を当然のものとは考えないからです。
この例では、GPS ナビゲーションの装備は魅力的な機能です。 この機能の調査では、遅くともお客様のフィードバックを調査する頃には、ある程度の優先順位が付くはずです。
B = 当然。 これらの機能は、製品に不可欠です。 これらは製品に必ず含める必要があり、優先順位の高い機能です。
このような基本的な属性は、どれほど優れていても、製品への評価でお客様は「どちらでもよい」と感じます。 たとえば、ワープロであれば、文書の作成や文書の保存といった機能が必要です。 これらは最低限の機能です。
たとえばお客様のグループにシート ベルトについて尋ねたとすると、ほとんどの人は新しい自動車にシート ベルトが付いているのは「どちらかというと好ましい (当然である)」と答え、シート ベルトのない自動車は「好ましくない」と答えるはずです。 これら 2 つの回答を表に記入すると、シート ベルトはベースライン (B) の機能である、つまり必須機能であることがわかります。
L = 一元的。 一元的な機能はパフォーマンス要件とも呼ばれ、顧客満足度に直接的に相関します。 これらは優先順位ではベースライン機能のすぐ下にありますが、コストとのバランスを取る必要があります。
機能の増加や品質の向上によって顧客満足度が向上します。 機能が減少すると、満足度が低下します。
多くの場合、製品の価格はこれらの属性に関連しています。
I = 無関心。 これらの機能はお客様にとって重要度が最も低いため、製品にとっても重要度が最も低いはずです。 これらはビジネス価値をほとんど、またはまったく持たないと考えられます。
表 1 には Q と R もあります。
Q: 疑問の余地がある – 質問が正しくないか、回答に疑問の余地があります。
R: 逆効果 – 回答の組み合わせが意味を成しません。 GPS ナビゲーション システムの場合、装備していることが「どちらかというと好ましい (当然)」と回答した人が、装備していないことを「好ましい」と回答すると R に分類されます。
応答のペアが Q または R になる場合は、質問や、回答の組み合わせについてさらに詳しく調べる必要があります。
イノベーション ゲーム
イノベーション ゲーム (Innovation Games) は、一次市場調査の開発に役立つツールです。 これらのツールでは、製品またはサービスに関するフィードバックとインプットを生成する目的で、お客様が「ゲーム」をします。 Luke Hohmann は 12 個を上回るこのようなゲームを作成し、著書『Innovation Games』の中で説明しています (この本は購入をお勧めします)。 バックログに優先順位を付けるのに適した 2 つのゲームは、"Prune the Product Tree" (製品ツリーの剪定) と、"Buy a Feature" (機能の購入) です。この著書で Luke 氏が説明している内容を抜粋します (転載許可承諾済み)。
製品ツリーの剪定
庭師は樹木の生長を管理するために剪定を行います。 ときには、剪定が芸術的に行われることがあり、低木が動物や興味深い抽象図形のようになります。 多くの場合は、バランスの良い樹形を作り、上質な果実を実らせるために剪定を行います。 このプロセスは "切ること" ではなく "成形" です。この比喩を使用すると、お客様の望む製品を作成する上で役立ちます。
ゲーム
まず、ホワイトボードまたは模造紙に大きな木の絵を描くか、木のグラフィック イメージを大判ポスターに印刷します。 太い枝は、システム内の機能の主な領域を表します。 木の端の部分 (枝の先) は、現在のリリースで提供している機能を表します。 新機能の候補をいくつかのインデックス カード (木の葉の形が理想的) に書き出します。 お客様に依頼して、希望する機能を木の周囲に配置してもらいます。これが、次の成長段階を表します。 木がバランスよく生長するように配置していますか。 1 つの枝 (おそらく製品の中核となる機能) が大きく生長していますか。 木の十分に活用されていない側面も強化されていますか。 木の根 (サポートとカスタマー ケアのインフラストラクチャ) も、少なくとも枝葉と同じ大きさに広がる必要があります。 そのようになっていますか。
.png "製品ツリーの簡略化のレイアウトの例")
製品ツリー – Hohmann
役に立つ理由
開発者もお客様も、機能によって重要度が変わることを知っています。 そのため、最も重要な機能 (お客様にとって最も大きな価値を提供する機能) に労力をつぎ込もうとする傾向があります。 残念ながら、このために、製品を完成させるために必要な機能に費やす労力が足りなくなる場合があります。 この "製品ツリーの剪定" ゲームでは、お客様が製品を構成する一式の機能を全体的にとらえ、意思決定のプロセスにインプットを提供する機会を与えます。
機能の購入
お客様が製品を購入する気にならせるのはどの機能でしょうか。 お客様がアップグレードするように動かすのはどの機能でしょうか。 変更したり取り除いたりしたほうがよいと感じる機能が気にならなくなるほど、または大目に見ることができるほど、お客様が満足するのはどの機能でしょうか。
製品プランナーは、このような質問について際限なく議論します。 多くの場合、新製品に追加する適切な機能セットの選択によって、短期的な失敗と長期的な成功の違いが顕著になります。 残念ながら、製品の影響を最も受ける人たち、つまりお客様を含めずにこの選択を行う製品プランナーが多すぎます。 "Buy a Feature" (機能の購入) ゲームは、お客様にプランナーの意思決定を手助けしてもらうことにより、意思決定の品質を向上させます。
.jpg "ゲームのレイアウトの例")
機能の購入 – Sterne
ゲーム
候補機能の一覧を作成し、それぞれに価格を付けます。 実際の製品の場合と同様に、価格は開発コストやお客様にとっての価値などに基づいて決めることができます。 機能に対して請求する実際のコストを価格にすることも可能ですが、通常はそうする必要はありません。 お客様は、メーカーから与えられた金銭を使用して、次回リリースの製品に期待する機能を購入します。 必ずいくつかの機能に、どのお客様でも購入できないほど高い価格を付けるようにしてください。 お客様には、特に重要な機能や特に高価な機能を購入するためにお金を貯めるように促します。 これにより、どの機能が最も重要かという折衝がお客様の間で活発になります。
このゲームはお客様の 4 ～ 7 人のグループに最適です。折衝によってお金を貯める機会を増やせるからです。 "Product Box" (製品ボックス) ゲームとは異なり、"Buy a Feature" (機能の購入) ゲームは、開発ロードマップに組み込まれる可能性が高い機能の一覧に基づいています。
役に立つ理由
製品プランナーは、多くの場合、製品の優先順位をお客様が明確に定義していると誤解しがちです。 定義しているお客様もいます。 ほとんどのお客様はそうではありません。 多くのお客様は一連のオプションを提示されると、「すべて必要」とだけ答えて、それらの要求に優先順位を付ける責任は製品プランナーに任せます。 または、多くの場合、製品マネージャーは、顧客と 1 対 1 で作業して機能の優先順位を収集します。しかし、その過程で、おそらく自覚なく、機能の優先順位を付ける役割を再び引き受けます。 むしろ、グループとしてお客様に参加してもらい、限られた量の資料を提供して、自分たちの希望にグループとして優先順位を付けてもらうようにしてください。 ただし、その方法にマジックがあるわけではありません。 お客様が特定の機能について互いに折衝を行うとき、その会話の中にマジックがあります。 お客様が実際に何を望んでいるかをよく理解できるのは、この折衝を通してにほかなりません。
相対的な重み付け – Karl Weigers
優先順位付けのもう 1 つの優れた方法は、Karl Weigers が 1999 年に紹介した相対的な重み付けです。 この方法は、ユーザーからのインプットとフィードバックに基づいて要件の優先順位を付けるメカニズムを提供するだけでなく、専門家チームによる判断も含まれています。 狩野モデルやイノベーション ゲームと同じく、相対的な重み付けは、どの機能をどのような優先順位で実装するかをより適切に判断する尺度を製品所有者に提供します。
最初のステップでは、機能の相対的な利益に重みを割り当てます。 利益とは、最終的な製品にその機能が含まれている場合のユーザーにとっての利点です。 次のステップでは、相対的な不利益を割り当てます。 不利益とは、最終的な製品にその機能が含まれていない場合のユーザーにとって不利な点です。 (利益と不利益を評価することで、狩野モデルでの充足形式と不充足形式の質問と同じ成果が得られます。)重みは、会社が機能の利点とリスクをどのように評価しているかを表す任意の数です。 これは、教師が全体の成績を決めるときに、宿題、出席、質問、テストにどのような重みを付けるかを決定する方法とよく似ています。それは教師ごとに異なります。 利益が不利益を上回ると判断した場合は、適していると考える比率で、不利益よりも高い重みを付けます。 不利益が利益を上回ると判断した場合は、それに応じて重みを調整します。 表 2 の例では、利益には相対的な重み 2、不利益には相対的な重み 1 を付けています。これは、最終的な優先順位を決定するときに、利益がより大きな要因になることを意味します。
同様に、コストの割合とリスクの割合の重みを決めます。 次の例では、リスクはこのプロジェクトでは特に問題ではないため、コストの割合に重み 1、リスクの割合に重み 0.5 を付けています。 (利益と不利益は重みを付けた後で割合の値を計算しますが、コストとリスクは割合として重み付けすることに注意してください。)リスクの高いプロジェクトがある場合は、リスクの重みをコストより高くしてもかまいません。
.png "機能表の例 - 開始")
重みを設定したところで、各機能の相対的な利益と相対的な不利益を評価するようにユーザーに依頼します。 各利益と不利益は、一定のスケール (Weigers は 1 ～ 9 を推奨) で評価しますが、一貫している限り別のスケールを使用することもできます。 相対的な利益は、機能が提供された場合の価値です。相対的な不利益は、その機能がないことによる潜在的な悪影響です。
たとえば、予定している 1 つの機能が、"ウィジェットをサーベンスオクスリー法に準拠させる" ことであるとします。ユーザーにとっての相対的な利益は事実上ありませんが、ビジネスへの相対的な不利益は多大です。これを行わないことで会社が倒産するおそれがあります。 したがって、相対的な利益のスコアは 1 または 2、相対的な不利益のスコアは 8 または 9 になります。
次の例でユーザーは、"業者注文の問い合わせステータス" という機能の相対的な利益を 5 と評価しました。 相対的な不利益は 3 と評価しました。 この機能の合計値を求めるには、2 つの数値にそれぞれの相対的な重み付けを掛けてから合算します。
(Benefit * Weight) + (Penalty * Weight) = Total Value
(5 *2) + (3*1) = 13
この場合は、機能の合計値は 13 点です。
.png "機能表の例 - 処理中")
機能の合計相対値と値の割合を取得したら、ユーザーから離れ、チームから洞察を得ます。 同じスケールを使用して、各機能を実装するための相対的なコストを見積もるようにチームに依頼します。 Karl Weigers は、「開発者は、要件の複雑さ、必要となるユーザー インターフェイスの作業の範囲、現在の機能仕様やコードを再利用できる可能性、必要なテストおよびドキュメントのレベルなどの要因に基づいて、コストの評価を見積もる」と説明しています。
相対的なコストを見積もった後で、相対的なリスクを見積もります。 Weigers はさらに次のように述べています。「開発者は、各機能に伴う技術的なリスクまたは他のリスクの相対的な程度を 1 ～ 9 のスケールで見積もります。 見積もり 1 は、眠っていてもプログラミングできるほどであることを意味します。9 は、実現可能性、必要な専門知識を持つ人員の調達、効果が不明であったり慣れていなかったりするツールや技術の使用に関して深刻な懸念があることを意味します。 スプレッドシートによって各機能の合計リスクの割合が計算されます。」
相対的な利益、不利益、コスト、およびリスクの値を記入したら、各列を合計します。 これらの合計を使用して割合を計算します。
合計値の割合: 相対的な利益と不利益の合計値を一番下の総合計で割ります。 次の例では、13 / 154 = 8% です。
相対的なコストの割合: 相対的なコスト値を一番下の相対的なコストの合計で割ります。 次の例では、2 / 42 = 4.8% です。
相対的なリスクの割合: 相対的なリスク値を一番下の相対的なリスクの合計で割ります。 次の例では、1 / 33 = 3% です。
優先順位: 値の割合を (コストの割合 * コストの重み) + (リスクの割合 * リスクの重み) で割ります。 次の例では、8.4% / ((4.8% * 1) + (3% * 0.5)) です。 これにより、優先順位値 1.345 が計算されます。
優先順位値を取得したら、優先順位の列で降順に並べ替えて、優先順位が一番高い項目が一番上になるようにします。 プロダクト バックログに項目が追加された場合や、ストーリーの新しい情報が明らかになった場合には、優先順位を再評価する必要があります。
最終的には、シートは次の表のようになります。
.png "機能表の例 - 完了")
この方法により、チームと利害関係者にとって役立つ範囲をよく理解できるようになります。 また、議論の土台を適切に形成するためにも役立ちます。各機能の利益、不利益、コスト、およびリスクを客観的に考慮するのは難しい場合があるためです。
Weigers は、このモデルをさらに現実に近づける方法を次のように説明しています。
「以前の製品で完成している一連の要件または機能に基づいて、このモデルを使いやすいように修正してください。 計算された優先順位が、テスト セットの要件の重要性の事後評価と一致するようになるまで、重み付けの要素を調整します。 このモデルは、提案された新しい要件を評価する際のトレードオフ決定にも役立ちます。 このモデルを使用して新しい要件の優先順位を見積もり、既存の要件とすり合わせることで、適切な実装順序を選択できます。 要件の優先順位付けを、駆け引きの領域から客観的かつ分析的な領域に移行するために行動をおこせば、最も適切な順序で最も重要な機能がプロジェクトで実現される可能性を高められます。
Karl Weigers は、相対的な重み付けについて詳しく説明した 2 冊の本『Software Requirements, Second Edition』および『More About Software Requirements: Thorny Issues and Practical Advice』を著しています。
この記事で説明した方法のいずれか、または別の手法を使用するとしても、プロダクト バックログが生き物であることを忘れないでください。 1 回優先順位を付けて終わりではありません。適切なバックログを維持するには再優先順位付けが必要です。 プロジェクトを順調に進めるためには、ストーリー、プロジェクトにとってのストーリーの重要性、および新しい情報がバックログに与える影響を定期的に再評価する必要があります。 プロジェクトが終了するまで利害関係者とお客様が関与し続けるように気を配る必要があります。 また、項目の優先順位を決定するには項目の見積もりが不可欠です。 バックログが陳腐化して使い物にならなくなることのないようにしてください。 時間と労力をかけてバックログを世話して育てます。そうすることで、最終製品だけではなく収益にも成果が出ます。
参照
概念
Team Web Access を使用して要求と認証の関係者フィードバック
『Agile Software Requirements』、Dean Leffingwell 著、Addison Wesley 刊。
「魅力的品質と当たり前品質」、狩野紀昭著、『品質』(日本品質管理学会)、Vol. 14、No.2、1984 年 10 月 狩野氏の元の論文。
「First Things First: Prioritizing Requirements」、Karl E. Wiegers 著。