【PdM】機能の優先順位付手法
しばらく執筆しなかったので、大事なトピックについてメモりたいと思います。
プロダクトを作ろう、となった時に欲しい機能やユーザーのニーズを全て詰め込んでしまっては時間もコストもかかりすぎて「良いプロダクト」と言うものはできません。
そこで「じゃあどの機能をまず作ってリリースするべきか」という重要な課題に直面します。１番と２番目に重要な機能はこれとこれで、まずそこから着手しよう！となっても、人によって１番と２番目の機能というのは違うこともあり得ます。ひどい時は一番うるさい人（意見を押し通す人）がいう通りになってしまい、それがベストな選択だとは限りません。
そこで他のPdMたちが利用している手法をいくつか紹介します！
RICEフレームワーク
RICEはIntercom社が考えた、以下の言葉の頭文字をとって作った言葉です（米じゃなく）：
R: Reach→ どのターゲット・人たちに影響を及ぼすのか
どの範囲の人、時間帯なのかはプロジェクト毎に話す
範囲を決めたらそれをもとに数字を作る
例1：1000人のユーザー登録を半年で行う→リーチスコアは1000
例2：2000人を目標としたときに、10％のユーザーを最初の一月で確保する→最初の月のReachスコアは200
I: Impact→ どれくらいインパクトがあるか
インパクトを定義するのは難しいが、やり方の一つとしてIntercom社が使用しているものを使うことなどできる：
3：最大のインパクト
2：大きなインパクト
1：普通のインパクト
0.5：少ないインパクト
0.25：最小限のインパクト
C: Confidence→ どれくらい自信があるか
ReachとImpactがどれくらいデータに基づいた示唆なのかを調整するための指標です。例えばインパクトは大きいが、データはないなどの場合、正しくその機能を理解するために使えます。大体ですが：
100%：High confidence
80％：Medium confidence
50％：Low confidence→ 50％以下の場合はかなり可能性が低いと思われるので、行わない方がいいでしょう。
E: Effort→ どれくらい大変か
これはコストの部分になります。単純に工数（例：エンジニア二人で開発できる機能なら2）です。
これらの四つの指標を計算式に入れることで、どの機能が優先されるべきかを定量化します。
RICEはよく用いいられる手法で、しっかり定量化され他の手法よりもデータに基点を置いているところが大きな特徴だと思います。一方で、チーム内で各指標の認識合わせをしっかり行うなどしないとブレが出てしまうので要注意です。また、他の手法に比べて少し時間がかかるというのもあります。
Value vs Effort費用対効果
Value vs Effort (Complexityという場合も有)は至ってシンプルで明快な手法だと思います。単純に機能やタスクの投資・費用に対して生み出される価値を算出し、順位づけしていくものです。
まず最初に「費用」と「価値」の定義は企業によって大きく異なるので、これがブレないように定義しておきます。そして各機能ごとに１〜５の数字を当てていきます（５が一番高い数値で、価値が５であれば最も価値があり、費用が５であれば最もコストがかかる具合になります）。１〜５である必要はないので、プロジェクト・プロダクトにあったものを選びましょう。
次にその二つの数字を使って四章限にプロットしていきます。これによって何がいわゆるクイックウィン（左上）だったり、優先順位が低い（左下）なのかはっきりします。
また、より明確にKPIへの貢献度を踏まえた優先順位づけを行いたければ、KPIへの貢献度も１〜５の数字をわり当て、以下の計算式を当てはまると良いでしょう。
( Value / Effort ）x KPI
例えば機能AとBがあるとします（Value、Effort、KPIの順）：
A: 5, 2, 3
B: 4, 2, 5
優先順位づけのために、上の計算式を使うと：
A: (5/2) x 3 = 7.5
B: (4/2) x 5 = 10
よって、同じ努力で価値は若干劣るものの、KPIへの貢献がより大きいBの方が優先的に着手されるべきだということがわかります。
この手法の良いところははっきりと優先順位を決める変数を定量化でき、またシンプルにできるというポイントです。しかし、RICEと比べて若干シンプルすぎるかもしれない、主観が入りやすい、という難点もあります。
MoSCoW（モスクワ）
MoSCowは前提がいくつかあり、それらの認識合わせを各ステークホルダーとまず行わなければいけません。
ゴール・目的は何か？
何をとって優先順位を高いとするのか？
優先順位付で意見が割れた時の対応は？
どれくらいのリソースを費やしたいのか？
プロジェクトはしっかりtime-boxed化されているか？（フェーズ・成果物で分けられているか）
これらの前提をクリアしたのち、各機能に下記４つの選択肢を振り分けていき、優先順位付していきます：
Must Have’s：リリースに不可欠な機能。この機能がないと当初計画していた目的（課題への解決）が達成できない
Should Have’s：必要不可欠ではないが、大きな付加価値を生む機能
Could Have’s：あった方がいい機能で、含まないことで少し影響が出る
Would Have’s：今回リリースで・タイミングは必要ではない機能
この手法は至って単純でわかりやすいものだと思っています。一方で、上で掲げた前提をしっかり、正しいステークホルダーたちと決めないと、そもそも意味のない優先順位になりかねないと言うのが要注意点です。
まとめ
いかがだったでしょうか？チームやプロジェクト、状況によってどの手法がうまく使えるかは変わってくると思うので、環境に合わせた手法を応用していくのがベストと言えるでしょう。各種方にメリット・デメリットは存在するので、うまく使い分けるのがいいと思いました。
この記事が気に入ったらサポートをしてみませんか？