プロダクトマネージャー（PM）のメソッド｜優先順位付けと検証を回す3つの手法と進め方

何を決めたいのかをはっきりさせる

決めたいことが「次の四半期に何を作るか」なのか、「この機能を作る価値があるか」なのかで、使う手法は変わります。前者は優先順位付け、後者は仮説の検証が中心です。目的が曖昧なまま手法を当てはめると、点数は付いても意思決定は進みません。

使えるデータの量を見極める

利用者数や行動ログが十分にあるプロダクトでは、数値を使った手法が機能します。立ち上げ直後で数字が少ない段階では、同じ手法を使っても推測の積み重ねになりがちです。その場合は、数値の精密さより、仮説を早く検証することに重心を置きます。役割全体の位置づけはプロダクトマネージャーの基本で整理しています。

RICEで機能を比べる

RICEは、Reach（影響を受ける利用者数）、Impact（1人あたりの影響の大きさ）、Confidence（見積もりへの確信度）、Effort（工数）の4つから点数を出す手法です。計算式は「Reach×Impact×Confidence÷Effort」で、Impactは0.25、0.5、1、2、3といった段階で付けるのが一般的です。

たとえば、四半期に500人が使う機能で、影響は大きい（2）、確信度は80％、工数が78人時間とします。計算は500×2×0.8÷78で約10.3です。別の機能が約6なら、前者を先に検討します。ただし、数字の根拠は担当者の見立てに左右されるため、点数の差が小さいときは、差を絶対視せず議論の材料として使います。

RICEで点数が割れたときの扱い

点数が僅差の候補が並ぶときは、依存関係を先に確認します。ある機能が別の機能の前提になっているなら、点数が低くても先に着手する価値があります。また、法令対応や重大な不具合の修正のように、点数にかかわらず実施が決まっているものは、比較の対象から外して別枠で管理します。

MoSCoWで範囲を切る

MoSCoWは、要件を「必須」「あったほうがよい」「今回は見送る」などに分ける手法です。リリース日が決まっていて、範囲を調整する場面に向いています。数値を計算しないため、関係者と短時間で合意しやすい反面、全部が必須に見えてしまう場合は、見送る項目を先に決めるところから始めます。

カノモデルで満足の質を見分ける

カノモデルは、機能を「ないと不満になるもの」「あるほど満足が上がるもの」「あると驚かれるもの」に分けて考える見方です。アンケートで分類する方法が知られています。他社にもある当たり前の機能を後回しにして不満を招く失敗を避けるときに役立ちます。

仮説を1文で書き、検証の基準を先に置く

検証は、「〇〇の利用者は、△△の導線を変えれば、□□が増える」のように、誰の何をどう変えるかを1文で書くところから始まります。あわせて、何がどれだけ動いたら仮説が正しいとみなすかを、実施前に決めておきます。結果を見てから基準を決めると、都合のよい解釈になりやすいためです。

最小限の形で試す

機能を完成させる前に、画面だけの試作を見せる、手作業で代行して反応を見る、限られた利用者にだけ出すといった試し方があります。作る量を減らして学びを先に得るのが目的です。ただし、少数の反応だけで結論を出すと外れることがあるため、試した人数と条件は必ず記録します。

結果の読み方と撤退の判断

検証の結果が基準に届かなかったときは、仮説が誤っていたのか、試し方が悪かったのかを切り分けます。対象にした利用者が偏っていた、期間が短すぎた、導線が目立たなかったなど、試し方の問題なら条件を変えてもう一度行います。仮説自体が外れていた場合は、時間をかけた案でも手放す判断が必要です。撤退の基準を実施前に決めておけば、愛着で判断が鈍るのを防げます。

ユーザーへのヒアリングを組み合わせる

行動ログは「何が起きたか」を示しますが、「なぜか」は分かりません。5人程度でも直接話を聞くと、数字の裏にある理由が見えてきます。質問は「その機能は使いたいですか」と聞くより、「前回その作業をしたときはどうしましたか」のように、実際の行動を尋ねるほうが偏りが出にくくなります。

手法を選ぶ前の確認項目

場面に合わせた手法の選び方を、先に短く確認しておきます。

• 決めたいのは順番か、範囲か、価値の有無か
• 利用者数や行動ログは十分にあるか
• 関係者への説明に数字が必要か
• 見直しの時期を決めているか

立ち上げ期とグロース期の違い

立ち上げ期は数字が少ないため、ヒアリングと小さな検証を中心に回します。グロース期は、RICEのような数値を使った比較と、指標を見ながらの改善が有効です。成熟したプロダクトでは、カノモデルで当たり前品質を点検することも増えます。

関係者との合意に使う

手法は、自分の判断を説明するための共通言語にもなります。営業や経営層に「なぜこの順番か」を説明する際に、RICEの前提を見せれば、反対意見も前提の違いとして整理できます。AIが集計や案出しを助ける場面でも、前提を決めるのは人の役割です。AIとの付き合い方はプロダクトマネージャーのAI活用の記事で触れています。

目標管理やロードマップとのつなぎ方

四半期の目標を立てる場合は、OKRのように達成したい成果を先に定め、その成果に効く施策をRICEなどで選ぶ流れにすると、手法同士が噛み合います。ロードマップには日付の約束を並べるより、「いま取り組む」「次に検討する」「まだ決めていない」といった段階で示すほうが、状況の変化に対応しやすくなります。

手法が目的になってしまう失敗

点数表を作ること自体が目的になると、実際の利用者から離れてしまいます。計算結果が直感と大きくずれたときは、手法を疑うだけでなく、見落としている前提がないかを点検するきっかけにします。まず、いま手元にある候補を3つ選び、RICEの4項目を仮の数字で埋めて、どの項目の根拠が最も弱いかを確かめるところから始めてみてください。