https://bootcamp.uxdesign.cc/the-prioritization-cheat-sheet-1d9aa54b4713
最も一般的な優先順位付けのフレームワークの手引き
「優先順位付けとは、最も重要なことを決め、そのことにまず取り組むこと」 - ジェイソン・フリード
プロダクトマネージャーとして、あなたは常に複数のプロジェクトと優先順位を競っています。限られたリソースと時間の中で、どの取り組みを進め、どの取り組みを後回しにするかを判断するのは難しいことです。このような判断に役立つツールの1つが、優先順位付けマトリックスです。優先順位付けマトリックスは、プロダクトマネージャーが取り組みに優先順位を付け、より良い意思決定を行うためのシンプルで効果的なツールです。取り組みの優先順位付けに使用できるフレームワークはいくつかあり、それぞれにメリットとデメリットがあります。この記事では、取り組みの優先順位付けに使用でき、プロダクトマネージャーがより良い意思決定をするのに役立つ、いくつかの異なるフレームワークについて説明します。
アイゼンハワー・マトリックス、価値と複雑性の四分儀、Kanoモデル、重み付けスコアリング優先順位付け、RICEフレームワーク、ICEスコアリングモデル、MoSCoW法、オポチュニティスコアリングなどのフレームワークを取り上げます。各フレームワークにはそれぞれ利点があり、自社のニーズに最も適したものを選択するのはプロダクトマネージャー次第です。これらのフレームワークを使用することで、プロダクトマネージャーは、どの取り組みが最大のROIを提供する可能性が高いかを迅速に特定し、それに応じて優先順位をつけることができます。
ただし、単一のフレームワークで完璧なソリューションを提供できるわけではなく、取り組みを包括的に把握するためには、常に異なるフレームワークを組み合わせて使用するのが良いということに留意する必要があります。異なるフレームワークを組み合わせて使用することで、プロダクトマネージャーは取り組みを異なる視点から評価し、より良い意思決定を行うことができます。この記事では、各フレームワークの例や長所・短所を紹介し、十分な情報を得た上で意思決定ができるようにします。
これらのフレームワークを1つの記事にまとめるという大変な作業をしましたので、後で保存しておけば、どんなことに遭遇しても、いつでもこれらを指先に置いておくことができます💾。
アイゼンハワー・マトリックス
ソース：Asana
アイゼンハワー・マトリクスは、タスクや取り組みの優先順位を決めるためのシンプルで効果的なツールです。このマトリックスは、4つの象限に分かれています。
- 象限1：重要かつ緊急 - これらは、すぐにでも実行しなければならないタスクで、潜在的な影響力が高いものです。プロダクトの成功に不可欠で、できるだけ早く完了させなければならない取り組みです。
- 象限2：重要だが緊急ではない - 重要だが先延ばしにできるタスクです。プロダクトの長期的な成功のためには重要だが、短期間なら待つことができる取り組みです。
- 象限3：緊急だが重要ではない - 重要ではないが、すぐに実行しなければならないタスクです。プロダクトの成功にとって重要ではないが、納期や契約上の義務などの外的要因によって完了させなければならない取り組みがこれにあたります。
象限4：重要ではなく、緊急でもない - 重要ではないため、延期や委任が可能なタスクです。プロダクトの成功にとって重要でなく、悪影響を及ぼすことなく延期できる取り組みです。
長所：アイゼンハワー・マトリックスはシンプルで使いやすく、最も重要で緊急性の高い取り組みを特定するのに役立ちます。また、あらゆる種類のタスクに優先順位をつけるのに使用でき、重要なことに集中するのに役立ち、先送りを避けるのに役立ちます。
- 短所：影響度は高いが緊急度が低い取り組みには適さない場合がある、取り組みの複雑さや実現可能性が考慮されていない、長期的な計画には適さない場合がある、取り組みに必要なリソースを考慮していない。
アイゼンハワー・マトリックスの例
アイゼンハワー・マトリックスを使った取り組みの優先順位の付け方の一例は以下の通りです。
- 緊急かつ重要：かなりの数のユーザーでアプリがクラッシュする原因となっている重大なバグを修正します。
- 重要だが緊急ではない：ユーザーニーズをより深く理解し、アプリのユーザーインターフェイスを改善するために、顧客調査を実施します。
- 緊急だが重要でない：アプリの小さな変更を要求している顧客からのメールに対応します。
- 緊急でもなく重要でもない：ユーザーからの要望もなく、会社の目標とも合致しない新機能を追加すること。
カテゴリー1の取り組みである致命的なバグの修正は、緊急性と重要性を兼ね備えているため、優先的に取り組むべきでしょう。カテゴリー2の「顧客調査の実施」は、重要だが緊急ではないため、優先的に取り組むべきです。カテゴリー3の「お客様からのメールへの対応」は、他の取り組みと比較して重要度が低いため、委任または延期する必要があります。カテゴリー4の「新機能の追加」は、緊急性も重要性もないため、却下すべきです。
アイゼンハワー・マトリックスについて詳しくはこちらをご覧ください。
価値と複雑性の四分儀
ソース： Productfolio
価値と複雑性の四分儀（インパクト-エフォートマトリックスとも呼ばれます）は、一方の軸を価値、他方の軸を複雑性として、取り組みをグラフ上にプロットするフレームワークです。マトリックスの右上に位置する、価値が高く複雑性が低い取り組みが、優先されるべきものです。このフレームワークにより、プロダクトマネージャーは、どの取り組みがプロダクトやビジネスに最も大きな影響を与え、かつ実装が容易であるかを特定することができます。
- 長所：価値と複雑性の四分儀は、取り組みをグラフィカルに表現しています。価値が高く、複雑性の低い取り組みを特定するのに役立ちます。早く実装できる取り組みを特定するのに役立ちます。
- 短所：取り組みの緊急性を考慮しない、取り組みに必要なリソースを考慮しない、長期的な計画に適していない可能性がある、インパクトは低いが価値の高い取り組みに適していない可能性があります。
価値と複雑性の四分儀の例
価値と複雑性の四分儀を用いて、取り組みの優先順位を決める例を以下に示します。
- 高付加価値かつ低複雑度：アプリのユーザーインターフェイスの小さな変更を実施することで、ユーザーエクスペリエンスを改善し、顧客満足度を向上させます。
- 高価値かつ高複雑度：高付加価値かつ高複雑度：ユーザーがアプリを通じて支払いを行うことができる新機能を開発し、収益を増加させます。
- 低価値かつ低複雑度：アプリの背景に新しいカラーオプションを追加します。
- 低価値かつ高複雑度：規制基準で要求されていない新しいセキュリティプロトコルを実装します。
カテゴリー1のアプリのユーザーインターフェイスの改善は、高価値かつ低複雑度であるため、優先的に取り組む必要があります。カテゴリー2の取り組み、決済のための新機能の開発は、価値が高いが複雑度が高いので、これも優先されるべきです。カテゴリー3の「新しいカラーオプションを追加する」という取り組みは、他の取り組みのように高価値かつ低複雑性ではないため、延期すべきです。カテゴリー4の「新しいセキュリティプロトコルの実装」は、価値が低く、複雑度が高いため、却下する必要があります。
価値と複雑性のフレームワークについては、こちらをご覧ください。
狩野モデル
ソース：Product Plan
狩野モデルとは、顧客要求を「基本」「性能」「感動」の3つに分類した顧客満足モデルです。基本要件とは、顧客が期待する最低限の要件であり、プロダクトが機能するために必要なものです。性能要件とは、顧客がプロダクトに期待する機能であり、満足度を高めることができます。感動要件とは、お客様が期待していないが、あると満足度が大きく向上する機能です。感動要件を対象とした取り組みは、顧客満足度を大きく向上させることができるため、優先的に取り組むべきです。
- 長所：狩野モデルは顧客中心のアプローチであり、顧客満足度を大きく向上させることができる取り組みを特定するのに役立ち、プロダクトの独自のセールスポイントを特定するのに役立ち、プロダクトが競合から際立つことができる領域を特定するのに役立ちます。
- 短所：取り組みの実現可能性や複雑性を考慮しない場合がある、企業の内部プロセスに高い影響を与える取り組みに適していない場合がある、企業のボトムラインに高い影響を与える取り組みに適していない場合があります。
狩野モデルの例
取り組みの優先順位を決めるために「狩野モデル」を活用した例を挙げると、以下のようになります。
- 必需項目：ユーザーがアプリ上でタスクを完了できないような重大なバグを修正します。
- パフォーマンス属性：アプリのロード時間を改善し、ユーザーの体験を向上させます。
- 嬉しいこと：プロフィールをパーソナライズできる新機能を追加し、アプリの利用をより楽しくします。
- 無関心：アプリの背景に新しい色の選択肢を追加します。
カテゴリー1の重要なバグを修正する取り組みは、アプリの基本的な機能を維持するために必要不可欠なものであるため、優先的に取り組む必要があります。カテゴリー2のアプリの読み込み時間の改善は、ユーザー体験を向上させるパフォーマンス属性であるため、優先的に取り組む必要があります。カテゴリー3の取り組み、パーソナライズのための新機能の追加は、ユーザーの体験を高め、アプリをより楽しく使うためのデリケートな要素であるため、考慮されるべきです。カテゴリー4の「新しいカラーオプションを追加する」という取り組みは、無関心であり、ユーザーの体験に大きな価値を与えないため、却下すべきです。
狩野モデルについて詳しくはこちらをご覧ください。
重み付けスコアリングによる優先順位付け
ソース：The Ascent
重み付けスコアリングによる優先順位付けは、さまざまな基準に重みをつけ、その基準に基づいて各取り組みをスコアリングすることができるフレームワークです。基準や重み付けはプロダクトや会社によって異なりますが、例えば、顧客への影響、実現可能性、会社の目標との整合性などが挙げられます。最も高いスコアを得た取り組みは、優先順位をつける必要があります。このフレームワークは、プロダクトマネージャーがさまざまな視点から取り組みを評価し、より良い意思決定をするのに役立ちます。
長所：プロダクトおよび企業目標に基づき、基準と重みをカスタマイズすることができます。
短所：各取り組みに重みとスコアを割り当てるのに時間がかかる場合がある、各基準の適切な重みを決めるのが難しい場合がある、取り組みの緊急性が考慮されていない場合があります。
重み付けスコアリングによる優先順位付けの例
取り組みの優先順位付けに「重み付けスコアリング優先順位付け」を使用する例を以下に示します。
優先順位をつけるために、以下の要素を考慮するとします。インパクト（40％）、実現可能性（30％）、企業目標との整合性（30％）です。
- 取り組みA：アプリで決済ができるようにする新機能を開発します。
- インパクト：8、実現可能性：7、企業目標との整合性。9
スコア = （8*40%） + （7*30%） + （9*30%） = 3.4 + 2.1 + 2.7 = 8.2
- 取り組みB：アプリの読み込み時間を改善します。
- 影響度：6、実現可能性：8、会社目標との整合性。8.
スコア = （6*40%） + （8*30%） + （8*30%） = 2.4 + 2.4 + 2.4 = 7.2
- 取り組みC：アプリの背景に新しいカラーオプションを追加します。
- 影響度：2、実現可能性：4、会社目標との整合性。4.
スコア = （2*40%） + （4*30%） + （4*30%） = 0.8 + 1.2 + 1.2 = 3.2
取り組みA、決済のための新機能の開発は、最も高いスコア8.2であるため優先されるべきであり、取り組みB、アプリの読み込み時間の改善は、スコア7.2であるため考慮されるべきです。新しいカラーオプションを追加する取り組みCは、最も低いスコア3.2であるため、却下されるべきです。
重み付けスコアリング優先順位決定フレームワークの詳細はこちらでご確認ください。
RICEフレームワーク（Reach、Impact、Confidence、Effort）
ソース：Intercom
RICEフレームワークは、取り組みの優先順位を決めるために使用できるフレームワークです。Reach（範囲）は、取り組みの影響を受ける人の数を表します。インパクトは、取り組みの潜在的な価値を表します。Confidence（信頼度）は、取り組みの成功の確実性のレベルを表します。Effort（努力）は、取り組みを完了するために必要なリソースを表します。Reach、Impact、Confidenceのスコアが高く、Effortのスコアが低い取り組みは、優先順位をつける必要があります。このフレームワークは、プロダクトマネージャーが潜在的な影響力と実現可能性に基づいて取り組みを評価するのに役立ちます。
- 長所：RICEフレームワークは、潜在的な影響力と実現可能性に基づいて取り組みを評価するのに役立ちます。取り組みのリーチと実装に必要なリソースを考慮するのに役立ち、高い潜在的な影響力を持ち、実装が可能な取り組みを識別するのに役立ちます。
- 短所：取り組みの緊急性を考慮しない場合がある、長期的な計画に適していない場合がある、インパクトは低いがリーチが高い取り組みに適していない場合があります。
RICEの例
RICEメソッドで取り組みの優先順位を決める例を挙げると、以下のようになります。
- 取り組みA：アプリで決済ができるようにする新機能を開発します。
- リーチ（R）：100、インパクト（I）。8、自信（C）：8、努力（E）：6
`スコア = （100*8*8）/6 = 1333
- 取り組みB：アプリの読み込み時間を改善します。
- リーチ（R）：50、インパクト（I）。6、自信（C）：9、努力（E）：4
スコア＝（50*6*9）/4＝675
- 取り組みC：アプリの背景に新しい色の選択肢を追加します。
- リーチ（R）：10、インパクト（I）。2、自信（C）：4、努力（E）：2。
スコア = （10*2*4）/2 = 40
取り組みA、決済の新機能の開発は、RICEスコアが1333と最も高いため、優先的に取り組むべきです。取り組みBは、アプリの読み込み時間を改善するもので、スコアが675であるため、検討すべきです。新しいカラーオプションを追加する取り組みCは、最も低いスコアである40であるため、却下されるべきです。
ICEスコアリングモデル（Impact、Confidence、Ease）
ソース： Productfolio
ICEスコアリングモデルは、取り組みの優先順位付けに使用できるもう一つのフレームワークです。Impact（重大性）は、取り組みの潜在的な価値を表します。Confidence（確実性）は、その取り組みが成功する確実性のレベルを表します。Ease（容易性）は、取り組みの実施しやすさを表します。Impact、Confidence、Easeのスコアが高い取り組みは、優先順位を高くつける必要があります。このフレームワークは、プロダクトマネージャーが成功の可能性が高く、実装が容易な取り組みを特定するのに役立ちます。
- 長所：ICEスコアリングモデルは、潜在的なインパクト、実現可能性、実施の容易さに基づいて取り組みを評価するのに役立ち、成功の可能性が高く、実施が容易な取り組みを特定するのに役立ちます。
- 短所：取り組みの緊急性が考慮されていない場合がある、長期的な計画に適していない場合がある、インパクトは低いが実施の容易性が高い取り組みには適していない場合があります。
ICEスコアリングモデル例
ICEスコアリングモデルを用いて、取り組みの優先順位付けを行う例を以下に示します。
- 取り組みA：アプリで決済ができるようにする新機能を開発します。
- 。インパクト（I）：8、信頼性（C）：8、容易性（E）：6
スコア = （8*8*6） = 384
- 取り組みB：アプリの読み込み時間を改善します。
- インパクト（I）：6、信頼性（C）：9、容易性（E）：4
スコア = （6*9*4） = 216
- 取り組み（C）：アプリの背景に新しいカラーオプションを追加します。
- インパクト（I）；2、信頼性（C）：4、容易性（E）：2
スコア = （2*4*2） = 16
取り組みA、決済のための新機能の開発は、ICEのスコアが384と最も高いため、優先的に取り組むべきです。アプリの読み込み時間を改善する取り組みBは、スコアが216であるため、検討すべきです。新しいカラーオプションを追加する取り組みCは、最も低いスコアである16であるため、却下されるべきです。
ICEスコアリングモデルについてはこちらで詳しく解説しています。
MoSCoW法（Must Have、Should Have、Could Have、Won't Have）
ソース：Tech Target
MoSCoW法は、取り組みの優先順位付けに使用できるフレームワークです。Must Haveは、プロダクトの成功に不可欠な取り組みを表します。Should Haveは、重要だが重要ではない取り組みを表します。Could Haveは、望ましいが必要ではない取り組みを表します。Won't Haveは、必要でない取り組みを表します。Must HaveとShould Haveに分類された取り組みは、優先順位を高くつける必要があります。このフレームワークは、プロダクトマネージャーが最も重要な取り組みを特定し、重要度の低い取り組みに移る前にそれらが完了することを確実にするのに役立ちます。
- 長所：MoSCoW法は、最も重要な取り組みを特定し、それらが最初に完了することを保証するのに役立ちます。それは、その重要性と緊急性に基づいて取り組みを優先するのに役立ち、それは重要でない取り組みにリソースを無駄にすることを避けるのに役立ちます。
- 短所：取り組みの実現可能性や複雑さを考慮しない場合がある、長期的な計画に適していない場合がある、インパクトは強いが重要性や緊急性が低い取り組みに適していない場合があります。
MoSCoW法の例
MoSCoW法を用いて、取り組みの優先順位を決める例を挙げると、以下のようになります。
- Mus-haves：ユーザーがアプリでタスクを完了できない重大なバグを修正し、アプリで支払いができるようにする新機能を実装します。
- Should-haves：アプリの読み込み時間を改善します。 ユーザーのニーズをよりよく理解し、アプリのユーザーインターフェースを改善するための顧客調査を実施します。
- Could-haves： ユーザーが自分のプロフィールをパーソナライズできる新機能を追加して、アプリをより楽しく使えるようにします。
- Will Not have：アプリの背景に新しいカラーオプションを追加すること。
「Mus-have」のカテゴリの取り組みは、アプリの基本的な機能と収益を上げるために重要であるため、最初に優先されるべきです。「Should-haves」カテゴリの取り組みは、ユーザーの体験とニーズの理解に重要であるため、次に検討する必要があります。「Could-haves」カテゴリの取り組みも、アプリに付加価値を与えることができるが、最初の2つのカテゴリの取り組みほどではないので、検討する必要があります。「Won't-haves」カテゴリの取り組みは、アプリに大きな価値を与えないため、却下されるべきです。
MoSCoW法についてはこちらをご覧ください。
オポチュニティ・スコアリング
ソース：Product Plan
オポチュニティ・スコアリングは、各取り組みの潜在的な機会や投資対効果を評価し、取り組みの優先順位を決めるために使用できるフレームワークです。このフレームワークは、市場規模、競合状況、企業目標との整合性などの要素に基づいて、各取り組みにスコアを割り当てます。最も高いスコアを獲得した取り組みは、成功の可能性が最も高いため、優先的に取り組む必要があります。このフレームワークにより、プロダクトマネージャーは、成長を促し収益を増加させる可能性が最も高い取り組みを特定することができます。
- 長所：オポチュニティ・スコアリングは、潜在的な投資収益率に基づいて取り組みを評価するのに役立ち、成長と収益の増加を促進する最大の可能性を持つ取り組みを特定するのに役立ち、取り組みを会社の目標とビジョンに整合させるのに役立ちます。
- 短所：取り組みの緊急性が考慮されていない可能性がある、各取り組みを評価しスコアリングするのに時間がかかる可能性がある、各要素の適切な重みを決定するのが難しい可能性があります。
オポチュニティ・スコアリング・フレームワークの例
取り組みの優先順位付けにオポチュニティ・スコアリングを活用した例を挙げると、以下のようになります。
- 取り組みA：アプリで決済ができるようにする新機能を開発します。
- 市場規模（M）：8、競争優位性（C）：9、実現可能性（F）：9。8、収益性（R）：9
スコア = （8*9*8*9） = 4864
- 取り組みB：アプリの読み込み時間を改善します。
- 市場規模（M）：6、競争優位性（C）：7、実現可能性（F）：9、収益性（R）：6
スコア = （6*7*9*6） = 2376
- 取り組みC：アプリの背景に新しい色の選択肢を追加します。
- 市場規模（M）：2、競争優位性（C）：4、実現可能性（F）：4。4、収益性（R）：2。
スコア = （2*4*4*2） = 64
取り組みA、決済のための新機能の開発は、機会スコアが4864と最も高いため、優先的に取り組むべきです。取り組みBは、アプリの読み込み時間を改善するもので、スコアが2376であるため、検討されるべきです。新しいカラーオプションを追加する取り組みCは、スコアが64と最も低く、企業にとって低い機会であるため、却下されるべきです。
オポチュニティ・スコアリング・フレームワークについて詳しくはこちらをご覧ください。
「優先順位をつける能力は、優れたマネジャーの最も重要なスキルである」 - ジョン・C・マクスウェル
優先順位付けマトリックスは、プロダクトマネージャーが限られたリソースと時間を最大限に活用するための強力なツールです。アイゼンハワー・マトリックス、価値と複雑性の四分儀、狩野モデル、重み付けスコアリングによる優先順位、RICEフレームワーク、ICE スコアリングモデル、MoSCoW法、オポチュニティ・スコアリングなどのフレームワークを使用すれば、どの取り組みが最大のROIをもたらす可能性が高いかを素早く特定し、それに応じて優先順位を決めることができます。各フレームワークにはそれぞれ利点があり、自社のニーズに最も適したものを選択するのはプロダクトマネージャー次第です。また、1つのフレームワークで完璧なソリューションを提供できるわけではなく、取り組みの包括的なビューを得るためには、常に異なるフレームワークを組み合わせて使用することが良いアイデアであることを覚えておくことが重要です。
