ux-inspiration

プロダクト開発における意思決定のための「ユーザーストーリーの優先順位付け手法」まとめ

こんにちは、@h0saです。

プロダクト開発で、どんな機能をどのタイミングで提供すべきか、どうユーザーストーリーの優先順位をつけるべきか、悩んだことはありませんか？

プロダクト開発は意思決定の連続です。優先順位を明確することは、スピーディな意思決定につながります。

今回の記事では、プロダクト開発における意思決定に役立つ「ユーザーストーリーの優先順位付け」手法についてまとめました。

※「ユーザーストーリー」の他にも、開発環境によって「機能」「フィーチャ」「ジョブ」など、様々な呼び方があると思います。本記事では、アジャイル開発環境で最も馴染み深いと思われ、かつ「成果」にフォーカスしている「ユーザーストーリー」という言葉を一貫して用います。

個人的な経験として、前職のスタートアップではUXデザインだけでなくプロダクトマネジメント的な業務にも携わり、ユーザーストーリーの優先順位付け作業に参加していました。明確な優先順位付けのルールはありませんでしたが、プロダクトオーナーはビジネス観点を、テクニカルディレクターは技術観点を、僕はユーザー観点をベースに、定期的に議論して優先順位を決めていました。

一方、現職ではクライアントワークになりました。外部から参画する形でユーザーストーリーの優先順位付けを行う機会があるのですが、特にステークホルダーが多い場合、優先順位にはより客観性を持たせ、合意形成を円滑に進める必要があります。

そこで、自分の経験と最近読んだ本の知識を踏まえて、優先順位付けの手法を以下の５つに分類してまとめました。下へ行くほどやり方が細かく、客観性が高くなっていきます（番外編は除く）。

1. 「投票」による優先順位付け
2. 「比較」による優先順位付け
3. 「マトリクス」を用いた優先順位付け
4. 「スコアリング」による優先順位付け
5. 番外編：「ラベリング」による優先度の整理

また、各手法にはメリット(Pros)とデメリット(Cons)も付記しました。

この記事が同じような優先順位付け業務に携わっている方のお役に立てれば幸いです。

※本記事は、洋書ですが『Product Roadmaps Relaunched』という本からインスピレーションを得ています。プロダクトのロードマップの描き方を再定義している良書です。プロダクトマネジメントに関わる方にはとてもオススメです！

 

そもそもダメな例

HiPPOに従う

本編に行く前に、「やってはいけない」例をご紹介しておきます。

HiPPO (Highest Paid Person’s Opinion) とは、カバのことではなく「最高給取りの意見」のことで、ポジションが高く発言力が強い人の一声を指します。「鶴の一声」とか「神の声」とかいうやつですね。

HiPPOは発言者の主観に大きく依存するため、優先順位付け作業においてその意見が本当に「正しい」かどうかは判断するのが難しいでしょう。

また、HiPPOによって今まで現場でしてきた議論が無駄になり、現場のモチベーションを下げるという負の効果もあります。

したがって、HiPPOを回避し、可能な限り客観的な判断基準で優先順位付けを行うべきです。

では、以下より具体的な優先順位付け手法を見ていきましょう。

繰り返しなりますが、下へ行くほどやり方が複雑になっていきます。

 

1. 「投票」による優先順位付け

1-1. ドット投票 (Dot Voting)

その名の通り、ドットのシールを使って投票する方法です。ブレインストーミングなどでわっとアイデアを量産した時に、だいたいのアタリをつけるために使われることが多いです。投票の観点は、「新規性」「広がりがある」「自社の強みと適合」など、様々考えられます。

ただし、多くの場合「優れているものに数票」入れるため、投票の入らなかったものの優先順位をつけるのは難しいです。

Pros: スピーディに優先順位をつけられる

Cons: 網羅的でない、客観性が少ない

 

1-2. 100ドルテスト ($100 Test)

1ドル札100枚を各ユーザーストーリーに分配する、という手法です。日本風にアレンジすると、「1000円札を100枚」ぐらいでしょうか。

ドット投票と似ていますが、身近な「お金」をイメージすることでより現実感を持って優先順位をつけることができます。

優先順位をつけるためのゲームで、参加者が持っている100ドルを分配することで、リストにあがっている項目に対して相対的な価値を配分します。このゲームは仮想的とはいえ現金を使って行うため、普通の順序づけよりも注意を引き、参加者が熱中しやすくなります。

引用：『ゲームストーミング ―会議、チーム、プロジェクトを成功へと導く87のゲーム』

『Product Roadmaps Relaunched』によると、この手法は特にワークショップなどで参加者の意識をすり合わせるのに有効だそうです。

ただ、あくまで投票はそのワークショップの中で閉じるため、ワークショップに参加しなかった人が見ると、なぜその優先順位なのかの理由がわかりにくいことが懸念されます。そのため、すり合わせに至るまでの議事録を取るといったフォローが必要でしょう。

また、以降で紹介する手法と比べるとやはり客観性が少なくなってしまうことは拭えません。

Pros: 参加者の意識のすり合わせに有効

Cons: 客観性が少ない

 

2. 「比較」による優先順位付け

2-1. ペアワイズ比較 (Pairwise Comparison)

ユーザーストーリーを１対１の総当たり戦で比較していく手法です。

まず機能Aと機能Bを比較し、しその次に機能Aを機能C、そして機能Dなどと比較します。最終的にすべてのペアを比較するまで続けましょう。

これは長くて骨が折れそうなプロセスに聞こえますが、実際には比較があっという間に終わることに驚くでしょう。ある機能が別の機能より優先されたら、その機能に１ポイントを与えます。そして、すべての機能のポイントを合計したら、優先順位リストのでき上がりです。

引用：機能に優先順位をつけるための５つのテクニック | UX MILK

やり方はとてもわかりやすいですが、ユーザーストーリーの数が膨大になると、組み合わせがその分増えるため、現実的ではなくなってきます。ストーリーの数が10個であれば、9+8+7+6+5+4+3+2+1 = 45回 繰り返す必要があります。

機能数が少ないプロダクト初期フェーズだと効果的に使えそうです。

Pros: やり方が明快

Cons: ユーザーストーリーの数が膨大だと破綻する

 

3. 「マトリクス」を用いた優先順位付け

２つの軸を設定してマトリクス上に対象をプロットするやり方です。何かしらの機会に一度はやったことがある方も多いのではないでしょうか。

ここでポイントとなるのが、２つの軸の選び方です。

新社会人のころ、タスクの優先順位の付け方として「緊急度 x 重要度」に分類して考えよ、というのをよく耳にしました。これも１つの軸の選び方ですね。

一方ユーザーストーリーの優先順位付けの場合、ユーザー、ビジネス、テクノロジー、コスト、リスク、といった視点から俯瞰的に眺める必要があります。必要に応じて必要な軸を選択すれば良いわけですが、以下に具体例を２つご紹介します。

 

3-1. ユーザーへのインパクト x 実装コスト

“WOW, HOW, NOW, POW” (略してWHNP) と呼ばれる手法です。

引用：WOW, HOW, NOW, POW design game – UXM

• 縦軸：ユーザー体験へのインパクト (UX Impact)
• 横軸：実装コスト (Implementation Cost)

ユーザーストーリーを上図のような四象限にプロットします。UXインパクトが大きければ大きいほど上側に、実装コストが高ければ高いほど右側にプロットしていきます。

そして、プロットが完了したら四象限を以下のように処理するのが良いとのこと。

• WOW (影響力大・低コスト): 最も重点を置くべき
• HOW (影響力大・高コスト): いかに導入コストを下げるべきか考えるべき
• NOW (影響力小・低コスト): 製品を徐々に改善するために、すぐに導入するべき
• POW (影響力小・高コスト): バットマンのように “Pow!” のパンチで取り除くべき

どちらの軸にも「ビジネス観点」が入っていないため、ビジネス観点での評価は別に行うか、縦軸にビジネス観点も加えてプロットしてみるのもありでしょう。

Pros: 四象限それぞれに対して違うアクションを取れる

Cons: ビジネス観点の評価は別で行う必要がある

 

3-2. 価値 x リスク

『Lean UX』で提唱されている優先順位付け方法です。仮説検証フェーズにおいてこの軸の取り方は有用です。

参考：『Lean UX 第2版 ―アジャイルなチームによるプロダクト開発』p.53

• 縦軸：価値 (Value)・・・どれぐらい価値を創出するか
• 横軸：リスク (Risk)・・・前提が間違っていた場合、どれぐらい悪影響が生じるか

「価値」についてはユーザーの価値かビジネスの価値かの言及がないため各々の解釈に委ねられますが、大事なのは「リスク」を軸に使っているところです。

リーン的な考え方では、リスクが高く、かつ高い価値を創出しそうな仮説を最初にテストすることが優先されます。右上の象限にプロットされた仮説からどんどん検証していきましょう。

Pros: 高価値かつ高リスクの仮説を明らかにできる

Cons: 「価値」の定義はチーム内ですり合わせが必要

なお、以下のPivotalさんの事例では、縦軸にビジネス価値、横軸に実現可能性を設定してユーザー課題をマッピングしており、参考になります。

事例紹介：ANAアプリ開発を振り返る – Product Run – Medium

 

4. 「スコアリング」による優先順位付け

スコアリング、つまり各ユーザーストーリーにスコア（得点）をつけて、優先度を評価するやり方です。

 

4-1. 狩野モデル (Kano model)

東京理科大学名誉教授の狩野紀昭氏が提唱した、顧客の求める品質を以下の３つに分類したモデルです。

• 魅力的品質：あると大きな満足をもたらす（なくても顧客満足度に影響はない）
• 一元的品質：あればあるほど良い
• 当たり前品質：ないと大きな不満をもたらす（あっても顧客満足度に影響はない）

各ユーザーストーリーをこれら３つの品質に分類するには、アンケートを通じて２つの質問を行います。『アジャイルな見積りと計画づくり』によると、20から30人のユーザーから回答をもらうだけでも、かなり正確な優先順位ができるそうです。

１つ目の質問は「充足質問」と呼ばれ、「そのユーザーストーリーが実現されるとしたらどう思うか」を問います。

２つ目の質問は「不充足質問」と呼ばれ、「そのユーザーストーリーが実現されないとしたらどう思うか」を問います。

どちらの質問にも、以下の５つの選択肢から回答を選んでもらいます。

1. 気に入る
2. 当然である
3. 何とも感じない
4. しかたない
5. 気に入らない

そして、以下の対応表を利用して、２つの回答を１つの意味に絞り込みます。

参考：『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』p.133

以上の手順を20〜30人に対して繰り返して得られた結果を集計すると、得票数が最多の品質が判明します。

なお、得票数が複数の品質に割れる場合は、ユーザーの種類によって期待の抱き方に差があるということなので、ユーザーセグメントを分類して再度分析する必要があります。

『Product Roadmaps Relaunched』によると、狩野モデルが特に有効なのは、ユーザー自身の価値観に基づいて優先順位付けを行いたいときです。一方で、技術的視点やビジネス視点は考慮されていないため、別で検討する必要があります。

Pros: ユーザー視点で「魅力的」「一元的」「当たり前」という３つの品質に分類できる

Cons: 定量調査の手間と工数がかかる

 

4-2. 機会スコアリング (Opportunity Scoring)

現実と理想のギャップで “機会スコア” を測る手法です。『UXリサーチの道具箱』によると、「アウトカム駆動イノベーション創出法 (ODI: Outcome Driven Innovation)」という手法から来ているそうです。

つまり、まずインタビュー調査でジョブやアウトカム（顧客ニーズ）を探索して、次にアンケート調査でアウトカムを数値化（機会スコア）して、最後に数値に基づいて戦略を立てるのです。

引用：UXリサーチの道具箱

具体的には、定量調査で各ユーザーストーリーの「重要度」と「満足度」を 1〜10 のスコアで評価してもらいます。そして以下の計算式で機会スコアを求めます。

機会スコア = 重要度 + max(重要度 – 満足度, 0)

重要度が満足度よりも小さい場合は、その差はマイナスになりますが、max値は0となります。

計算例①：重要度 1, 満足度 10
　機会スコア = 1 + max(1-10, 0) = 1

計算例②：重要度 10, 満足度 1
　機会スコア = 10 + max(10-1, 0) = 19

つまり、重要度は高いが満足度が低いユーザーストーリーほど、大きなチャンスがあるということです。

図で表すとこのようになります。

参考：20 Product Prioritization Techniques: A Map and Guided Tour

この手法も狩野モデルと同様、ユーザーのみに焦点を当てているため、ビジネス観点や技術観点は評価に含まれていません。

使い方としては、既存プロダクトを改善したい時に、まずはユーザーの評価を手がかりにどこから着手すべきかのアタリをつけるのに有効と思われます。

Pros: 狩野モデルよりは集計がシンプル

Cons: 定量調査の時間がかかる

 

4-3. 有用性、技術的実現性、経済的実現性 (Desirability, Feasibility, Viability)

引用：Design Thinking | Design Thinking
翻訳参照：イノベーションにつながるアイデアの３つの条件 – Think Social Blog

これまでご紹介してきた優先順位付け手法は、「ビジネス視点」「ユーザー視点」「技術視点」の１つまたは２つを用いて優先順位付けするものでした。

この Desirability, Feasibility, Viability では、それら３つの視点を数値化して総和を求め、優先順位付けを行います。

• Disirability: 有用性・・・顧客の役に立つか
• Feasibility: 技術的実現性・・・実装可能か
• Viability: 経済的実現性・・・お金を生むか

具体的には、各ユーザーストーリーに対して各指標ごとに3段階 [1(低) 2(中) 3(高)] 評価を行います。その総和が優先度のスコアとなり、高いものから順に着手していくことになります。

参考：『Product Roadmaps Relaunched』p.141

もちろん、3段階ではスコアの差がつかない場合は、5段階や10段階の評価にしても良いでしょう。

ただし、３つの視点をただスコア化するというシンプルなやり方な分、このままのフォーマットだと応用が効かない部分があります。それを解決するのが、次にご紹介する「重み付けによるスコアリング」です。

Pros: 「ユーザー」「テクノロジー」「ビジネス」３つの視点を入れられる

Cons: ３つの視点を同列に扱うため、細かなチューニングに不向き

 

4-4. Weighted Scoring（重み付けによるスコアリング）

一番複雑な優先順位付け手法です。

その分、最も客観的かつ汎用性が高い方法です。時間はかかりますが、ステークホルダーの多いプロジェクトでは効果を発揮するでしょう。（実プロジェクトでもほぼ同じやり方で実施したことがありますが、合意を得ながら納得感を持って進めることができました。）

Product Planというツール（自分はフリートライアルしか使ったことはないのですが）で、この重み付けによるスコアリングを利用することができます。

下にあるのが「重み付け」を追加したスコアの表です。

引用：Benefit versus Cost: How to Prioritize Your Product Roadmap

ご覧の通り、Benefit と Cost が複数のカラムに分かれています。

Benefitは、この記事のこれまでの用語を使うと、「ビジネス視点」と「ユーザー視点」に分類することができます。この表では、”Increase Revenue” と “Strategic Value” がビジネス観点と思われます。ユーザー観点も、プロジェクトに応じて適宜分解するのが良いでしょう。

Costはテクノロジー観点で、上の表では “Implementation Effort”, “Operational Costs”, “Risk” に分かれています。

これらに対して”Weight” 行が設けられています。この Weight がスコアに掛け算されることで、スコアに重みをつけることができます。

つまり、大事なBenefitに対しては大きいWeightを、大事ではないBenefitに対しては小さいWeightを設定することで、スコアのコントロールが可能になります。Costについても同様です。

Weight の設定は、ビジネス価値・ユーザー価値への寄与度が高い因子を、プロジェクトゴールやユーザーリサーチ結果を振り返りながらステークホルダーとディスカッションして見極めるのが良いでしょう。

また、『Product Roadmaps Relaunched』では、”Confidence（自信）” による重み付けが紹介されています。

仮説が事前に正しいとわかっているものであれば Confidenceは100%となり、仮説に自信がなければ50%など100%よりも小さい値を設定します。それをスコアに掛けることで重みが変わります。

下の表では、生データによる計算結果 (Raw Score) では User Story A が一番スコアが高いですが、Confidenceを掛け算することで User Story B の方がスコアが高くなりました。

参考：『Product Roadmaps Relaunched』p.147

評価軸が細かくなればなるほど評価に時間がかかりますが、その分客観性を持たせることが可能です。

Pros: 「ユーザー」「テクノロジー」「ビジネス」３つの視点を分解して評価でき、カスタマイズしやすく、客観性が高い

Cons: とにかくスコアリングに時間がかかる

 

5. 番外編：「ラベリング」による優先度の整理

最後に、ここでご紹介する手法は、厳密的には優先順位付け方法ではありません。あくまで各ユーザーストーリーにラベルをつけることで、わかりやすく分類する方法です。上記で紹介した優先順位付け手法を実行した後に、ラベリングすると効果的でしょう。

 

5-1. MoSCoW

MoSCoWは、Must have, Should have, Could have, Won’t have の頭文字を取ったものです。

• Must have：ローンチ時に必須。これがないと世に出せない。
• Should have：ないと痛みを伴う重要な機能。予算や期限にどうしてもミートしない場合に切る。
• Could have：あったら望ましいが、Should haveよりは重要でない機能。予算や期限のリスクが懸念されたらまず切る。
• Won’t have：スコープ外とする機能。

ユーザーストーリーをスプレッドシート等で管理し、専用カラムを作ってこの4分類をラベリングしていくのがベーシックな使い方かと思います。

Pros: ユーザーストーリーを整理でき、コミュニケーションが取りやすくなる

Cons: スコープが変わった場合再度ラベルを付け直す必要がある

 

終わりに

以上、ユーザーストーリーの優先順位付け方法をご紹介しました。

簡単にできるものから時間のかかるものまでたくさんリストアップしましたが、あくまで優先順位付けの目的は「意思決定」にあります。

小さいスタートアップ企業であれば、時間のかかる「スコアリング」はする必要なく、「投票」や「マトリクス」を用いて簡易的に優先順位をつける方がスピーディで事足りることが多いでしょう。

一方で、大企業などで複数の部署にまたがる大きなプロジェクトの場合では、どのユーザーストーリーに着手していくか意思決定がしづらいシチュエーションが想定されます。そんな時は時間をかけてでもユーザーストーリーをスコアリングして客観性を持たせることで、その後の開発がスムーズに行くことが期待されます。

言い換えると、適切なユーザーストーリーの優先順位付け方法は、プロジェクトのスコープや組織サイズ、メンバーによって変わり、正解はないと思っています。ただ共通して言えるのは、どの手法でも関係者を巻き込んで合意形成を行いながら進めることが大事だということです。

優先順位の意思決定に迷った際には、ぜひこの記事を見返していただき、一番効果がありそうなやり方をカスタマイズして導入してみてください。

 

参考書籍