優先順位付け
Mitch Lacey 著アジャイルとスクラムの導入と改善に特化したコンサルティング会社である Mitch Lacey & Associates, Inc の経営者です。
2012 年 1 月
この記事では、Mitch Lacey は多くのアジャイル チームで特に有効であると証明された 3 つの方法を説明しています。顧客満足度の Kano モデル、Luke Hohmann による一連の Innovation Games、Karl Weigers の相対的な重み付けのモデルです。これらのいずれかを使用すると、バックログの大まかな優先順位付けから、リスク、重要性および顧客満足度を十分に評価する正確な順序付けに移行することができます。
対象
アプリケーション ライフサイクル管理; Team Foundation Server
この記事の内容:
Introduction
顧客満足度の Kano モデル
革新的なゲーム
Prune the Product Tree (製品ツリーの剪定)
Buy a Feature (機能の購入)
相対的な重み付け – Karl Weigers
結論
アジャイル チームが有効に機能し続けるには、プロダクト バックログの項目を重要性に応じて順序付けて、プロジェクトが進行するにつれてそれらの優先順位を更新する必要があります。すべてのプロダクト バックログは、ビジネス価値とリスクに基づいて優先順位を付ける必要があります。この優先順位を認識することで、チームは、製品の成功に関与する可能性が最も高い機能に労力を集中することができます。適切な順序付けと優先順位付けが行われたバックログは、チームと顧客満足度にメリットがあるだけでなく、ビジネスの最終的な収益も向上させます。バックログの詳細については、「プロダクト バックログの構築と管理」、「プロダクト バックログの作成または追加」および「バックログのグルーミングと見積り」を参照してください。
プロダクト バックログの順序付けおよび優先順位付けを行うときは、多くの要因を考慮すると共に、決定を正当化できるようにする必要があります。未処理のプロダクト バックログから作業を開始する場合は、そのプロセスが非常に困難に思えることがあります。ただし、バックログのすべての項目をすぐに完全に並べ替える必要はありません。「見積もり」では、「高い壁」と呼ばれる手法について説明します。これは、未処理のプロダクト バックログをすばやく評価し、利害関係者と協力して大まかな優先順位付けを行う効果的な方法です。
この大まかな優先順位付けは、開始点として適切であり、状況によってはこれで十分な場合があります。場合によっては、このような優先順位を改良する必要があります。つまり、さらに科学的な方法でバックログに優先順位を付ける必要があります。このために使用できる手法が多数あります。この記事では、多くのアジャイル チームで特に有効であると証明された 3 つの方法を説明します。顧客満足度の Kano モデル、Luke Hohmann による一連の Innovation Games、Karl Weigers の相対的な重み付けのモデルです。これらのいずれかを使用すると、バックログの大まかな優先順位付けから、リスク、重要性および顧客満足度を十分に評価する正確な順序付けに移行することができます。
顧客満足度の Kano モデル
顧客満足度の Kano モデルは、東京理科大学の狩野紀昭教授によって 1980 年代に開発されました。このモデルは、基本的な属性と差別化する属性を区別する単純な順位付けの方法です。質問に基づいた方法を取るこのモデルは、製品の特徴を視覚化して、設計チーム内の議論を活性化する効果的な方法です。
.png "製品機能グラフの例")
Kano モデルでは、一連の質問を充足と非充足という 2 つの形式で行います。たとえば、自動車用の GPS ナビゲーション システムについて顧客に質問するとします。まず、充足形式の質問をたずねます。
- この車に GPS ナビゲーション システムが装備されていたらどう思いますか。
回答は次のものに制限します。
好ましい。
当然である。
どちらでもよい。
仕方ない。
好ましくない。
この例では、架空の顧客が「好ましい」と回答したとします。
次に、不充足形式の質問をたずねます。
- この車に GPS ナビゲーション システムが装備されていなかったらどう思いますか。
架空の顧客は、前に示した回答のうちいずれかを選択できます。異なる回答を選択することができ、通常は異なります。この例では、架空の顧客が "不充足形式" の質問に「どちらかというと好ましい」と回答したとします。
実際のプロジェクトでこれを行う場合は、このような反対の質問を複数の顧客グループ (顧客の組織のさまざまな職務を代表する人々) にたずねることができます。マーケティング グループ、会計グループ、製造グループなどが考えられます。ここでは、このモデルを説明するために、1 つの顧客グループだけに 1 つの質問だけをたずねると想定します。回答のペア (充足形式と不充足形式への回答) をまとめたら、表 1 のように各欄に記入します。
.png "Kano マップの例")
表 1 – Kano マッピング
上の例で、架空の顧客が充足質問に対しては「好ましい」と答え、不充足質問には「当然である」と答えたことに注意してください。表にこのペアを記入すると、これら 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 は次のように説明しています (転載許可承諾済み)。
.gif "Hh765981.collapse_all(ja-jp,VS.110).gif")
Prune the Product Tree (製品ツリーの剪定)
庭師は樹木の成長を管理するために剪定します。場合によっては剪定は芸術的に行われ、低木が動物や興味深い抽象図形のようになります。多くの場合は、バランスのよい樹形を作り、上質な果実が実るように剪定を行います。このプロセスは "切ること" ではなく "成形" です。この比喩を使用すると、顧客が望む製品の作成に役立ちます。
ゲーム
まず、ホワイトボードまたは模造紙に大きな木の絵を描くか、木のグラフィック イメージを大判ポスターに印刷します。太い枝はシステム内の機能の主要な部分を表します。木の縁の部分 (枝の先端) は、最新リリースで提供している機能を表します。新機能の候補をいくつかのインデックス カード (木の葉の形が理想的) に書き出します。顧客に依頼して、望む機能を木の周辺に配置してもらいます。これが、次の成長段階を表します。木がバランスよく成長するように構成していますか。1 つの枝 (製品のコア機能) が大きく成長していますか。木の十分に活用されていない側面も強化されますか。木の根 (サポートおよび顧客ケア インフラストラクチャ) も、少なくとも枝葉と同じ大きさに広がる必要があります。どうですか。
.png "製品ツリーの簡略化のレイアウトの例")
製品ツリー –Hohmann
役に立つ理由
開発者も顧客も、機能の重要度は多様であるとわかっています。したがって、最も重要な機能 (顧客にとって最も大きな価値を提供する機能) に労力を注ぎ込もうとする傾向があります。ただし、このために、製品を完成するために必要な機能に費やす労力が足りなくなる場合があります。Prune the Product Tree (製品ツリーの剪定) ゲームでは、製品を構成する一連の機能を確認することによって、顧客が全体を意識して意思決定プロセスにインプットを提供することができます。
Buy a Feature (機能の購入)
顧客に製品を購入する気にさせるのはどの機能でしょうか。顧客にアップグレードさせるのはどの機能でしょうか。変更したり取り除いたりした方がいいと考える機能が気にならなくなるほど、または大目に見ることができるほど、顧客が満足するのはどの機能でしょうか。
製品プランナーは、このような質問について際限なく議論します。多くの場合、新製品に追加する適切な機能セットの選択によって、短期的な失敗と長期的な成功の違いが顕著になります。ただし、製品の影響を最も受ける人物 (顧客) を含めずにこの選択を行う製品プランナーが多すぎます。Buy a Feature (製品の購入) ゲームは、顧客に意思決定を支援してもらうことで意思決定の品質を向上させます。
.jpg "ゲームのレイアウトの例")
Buy a Feature (製品の購入) –Sterne
ゲーム
候補機能の一覧を作成し、それぞれに価格を付けます。実際の製品と同様に、価格は開発コストや顧客価値などに基づいて決めることができます。機能に関して請求しようとしている実際のコストを価格にすることも可能ですが、通常はそうする必要はありません。顧客は、与えられたゲーム用の通貨を使用して、製品の次のリリースで望む機能を購入します。必ず一部の機能に、どの顧客も購入できないほど高い価格を付けるようにしてください。特に重要な機能や特に高価な機能を購入するためにはお金をためるように顧客に促します。これにより、どの機能が最も重要かというネゴシエーションが顧客の間で活発になります。
このゲームは 4 ～ 7 名の顧客のグループに最適です。ネゴシエーションを介して顧客がお金をためる機会を増やせるためです。Product Box (製品ボックス) ゲームとは異なり、Buy a Feature (機能の購入) ゲームは、開発ロードマップに含まれる可能性が高い機能の一覧に基づいています。
役に立つ理由
製品プランナーは、多くの場合、製品の優先順位を顧客が明確に定義していると誤解しがちです。定義している顧客もいます。ほとんどの顧客はそうではありません。多くの顧客は一連のオプションを提示されると、「すべて必要」とだけ答えて、その要求に優先順位を付ける責任は製品プランナーに任せます。または、多くの場合、製品マネージャーは、顧客と 1 対 1 で作業して機能の優先順位を収集します。その過程で、おそらく自覚なく、機能の優先順位を付ける役割を再び引き受けます。グループとして顧客に参加してもらい、限られた量の資料を提供して、グループとしての希望に優先順位を付けてもらうようにします。ただし、その方法に魔法があるわけではありません。魔法は会話を組み立てる際に発生し、顧客が特定の機能について互いにネゴシエーションを行います。顧客が本当は何を望んでいるかをよく理解できるのは、このネゴシエーションに他なりません。
相対的な重み付け – Karl Weigers
優先順位付けのもう 1 つの優れた方法は、Karl Weigers が 1999 年に紹介した相対的な重み付けです。この方法は、ユーザーのインプットとフィードバックに基づいて要件の優先順位を付けるメカニズムを提供するだけでなく、チームの専門家による判断も含んでいます。Kano モデルや Innovation Games と同じく、相対的な重み付けにより、実装すべき機能や優先順位を製品の所有者が適切に判断することができます。
最初の手順では、機能の相対的な利益に重みを割り当てます。利益は、最終製品の機能を保有するユーザーにとっての利点です。次に、相対的な不利益を割り当てます。不利益は、最終製品の機能を保有しないユーザーにとっての結果です。(利益と不利益を評価することで、Kano モデルでの充足形式と不充足形式の質問と同じ成果が得られます。)重みは、会社が機能の利益とリスクをどのように評価しているかを表す任意の数です。これは、教師が全体の成績を決めるときに、宿題、出席、質問、テストにどのような重み付けるかを決定する方法とよく似ています。教師ごとに異なります。利益が不利益を上回ると判断した場合は、適していると考える比率で、不利益よりも高い重みを付けます。不利益が利益を上回ると判断した場合は、それに応じて重みを調整します。表 2 の例では、利益には相対的な重み 2、不利益には相対的な重み 1 を付けています。これは、最終的な優先順位を決定するときに、利益がより大きな要因になることを意味します。
同様に、コストの割合とリスクの割合の重みを決めます。次の例では、リスクはこのプロジェクトでは特に問題ではないため、コストの割合に重み 1、リスクの割合に重み 0.5 を付けています。(利益と不利益の重みを付けた後で割合の値を計算しますが、コストとリスクは割合として重み付けされることに注意してください。)リスクの高いプロジェクトの場合は、リスクの重みをコストよりも高くします。
.png "機能表の例 - 開始")
重みを設定したところで、各機能の相対的な利益と相対的な不利益を評価するようにユーザーに頼みます。各利益と不利益は、一定のスケール (Weigers は 1 ～ 9 を推奨) で評価されますが、一貫している限り別のスケールを使用することもできます。相対的な利益は、機能によって提供される価値です。相対的な不利益は、その機能がないことによる潜在的な悪影響です。
たとえば、予定しているある機能が、"ウィジェットをサーベンスオクスリー法に準拠させる" ことであるとします。ユーザーにとっての相対的な利益は事実上ありませんが、ビジネスへの相対的な不利益は多大です。これを行わないことで会社が倒産するおそれがあります。したがって、相対的な利益のスコアは 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 月。狩野の元の論文。