PdMの意思決定では、さまざまなフレームワークを使います。
要望の性質を分類する狩野モデル、施策を数値で比べるRICE。
どちらも複雑な判断を扱いやすくしてくれますが、便利な道具ほど、その前提や構造を見落としたまま使うと、結論の見え方が変わってしまいます。
この記事では、狩野モデルとRICEを例に、フレームワークを使うときに気をつけたいポイントと、数字の先にある意思決定をどう扱うかについて書いてみます。
シーン1：候補の性質を見極める — 狩野モデル
優先順位づけの場には、ユーザー要望、既存機能の改善、運用課題、技術的負債、競合との差分など、さまざまな候補が集まります。
ただし、すべての候補をそのまま同じ点数表に載せても、比較できる状態にはなっていません。まずは、それがユーザー体験の中でどんな役割を持つのか、現在のロードマップや戦略に照らして、いま議論すべきものなのかを整理する必要があります。
このとき狩野モデルが役に立ちます。狩野モデルは、機能の充足度と顧客満足度の関係から品質を分類する考え方です。機能を「あるかないか」ではなく、ユーザー体験の中でどんな役割を持つのかで見られます。
当たり前品質は、満たして当然と受け取られ、欠けると強い不満を生むものです。一方で、満たしても積極的な評価や差別化にはつながりにくい。
一元的品質は、満たすほど満足度が上がるものです。性能、速度、精度のように、改善した分だけ評価されやすい。
魅力的品質は、なくても大きな不満にはなりませんが、あると印象や評価を大きく引き上げるものです。
この3つは優劣ではなく、役割の違いです。当たり前品質は守るもの、一元的品質は伸ばすもの、魅力的品質は差別化や学習につながるもの。同じ候補に見えても、意思決定上の扱い方は変わります。
罠1：分類は時間で変化する
どの品質に当たるかは固定ではありません。かつて魅力的品質だったものが、市場に浸透すると当たり前品質に変わります。
たとえばAIアシスタント機能は、その変化がわかりやすい例です。少し前までは「AIで要約できる」「AIに聞ける」こと自体が驚きや新しさを生む魅力的品質でした。ところが今では、多くのSaaSや業務プロダクトで、AIによる支援が少しずつ期待値の中に入り始めています。
この移行には過程があります。先行プロダクトが魅力的品質として出したものが市場に受け入れられ、各社がリサーチやPoCを重ねて追随し、やがて標準化される。その結果、いつのまにか「あれば嬉しい」ではなく「ないと物足りない」ものになっていきます。
後発プロダクトではこの時間差が特に重要です。検討開始時点では魅力的品質に見えていたものが、リリース時点では当たり前品質になっていることがある。一方で、市場の変化や先行プロダクトの受け入れられ方を見れば、何を前提として満たすべきか、どこで差別化するのか、いつローンチするのかを考えやすくなります。
つまり分類は、一度して終わりではありません。いま魅力的品質に見えているものが、いつ当たり前品質に変わるのか。そして、それが現在のロードマップや戦略に照らして、いま扱うべきものなのかを見続ける必要があります。
罠2：当たり前品質は、この後のスコア競争で埋もれる
当たり前品質は、満たしても積極的な評価につながりにくい一方で、欠けると強い不満を生みます。つまり、満足度やインパクトを基準にした次の比較フェーズでは、評価されにくい。
シーン2でRICEのスコアを扱うと、この「埋もれる当たり前品質」が根拠の弱い成長仮説にスコアで負ける、という現象が起きます。性質の見極めと数値の比較は、地続きで罠が連鎖します。
シーン2：候補を数値で比べる — RICE
性質を見極めたうえで、同じ土俵に載せられる候補を数値で比較します。RICEは代表的なスコアリングで、次の式で計算します。
$$\text{RICE} = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}$$
Reach（到達ユーザー数）、Impact（一人あたりの影響）、Confidence（見積もりの確度）、Effort（工数）。感覚で語られがちな候補を共通の軸で比較できます。便利な式ですが、この構造そのものに気をつけなければならない点がいくつかあります。
罠1：Effortが分母にいるので、小工数の施策が過大評価される
RICEはEffortで割るため、分母が小さいほどスコアが跳ね上がります。たとえばEffort 0.5の施策は、分子が同じならEffort 5の10倍のスコアになります。
しかも工数は、過小評価されがちです。やってみたら倍かかった、関係者調整やQA、リリース後の問い合わせ対応まで含めると想定より重かった、ということはよくあります。結果として、「小さく見積もられた施策」が上位に来やすい。クイックウィンに見えるものが、単に見積もりの甘さで上位に来ているだけ、ということが起きます。
Effortをどう扱うか
Effortは分母であり、コストを表す項目です。つまり実装工数だけで見積もるのではなく、仕様整理、デザイン、レビュー、QA、リリース作業、運用、問い合わせ対応、関係者調整まで含めて見積もる。小さな施策ほど、こうした固定費の影響が大きくなりがちです。
値は人月とし、不確定要素による揺れを軽減するため概算値は整数（1ヶ月未満の場合は0.5）に留めて扱うのがよいでしょう。
Effortは見た目以上にスコアを動かします。低く出た見積もりほど、「本当に小さいのか」「見えていないコストがないか」を確認してからRICEに載せる必要があります。
罠2：Confidenceは、根拠の薄い皮算用を自動で止めてくれない
Confidenceは0〜100%の係数として掛かり、確度が低ければスコアを割り引きます。ブレーキに見えますが、ReachとImpactを大きく置くと、Confidenceを低めにしてもスコアは高く出ることがあります。
問題は、Confidenceそのものではありません。根拠の薄い候補や、そもそも同じ土俵で比べるべきではない候補まで、同じ表に載せてしまうことです。
| 候補 | Reach | Impact | Confidence | Effort | RICE |
|---|---|---|---|---|---|
| 根拠の弱い成長仮説 | 1,000 | 2.0 | 40% | 2 | 400 |
| 当たり前品質の担保 | 1,000 | 0.5 | 100% | 2 | 250 |
この表は、「根拠の弱い成長仮説を優先すべき」という例ではありません。比較対象の整理を誤ると、RICEはそれらしい順位を出してしまう、という例です。
スコアだけを見ると、「根拠の弱い成長仮説」の方が優先されます。
一方で、「当たり前品質の担保」はConfidenceが100%でも、Impactが地味に見えるためスコアでは下がります。
ここでシーン1の話がつながります。当たり前品質は、満たして当然であるがゆえに加点されにくく、スコア競争では埋もれやすいのです。
Confidenceをどう扱うか
まず、当然ですがConfidenceをPdMの直感や熱意で決めてしまうのは危ういです。
感覚ではなく、Reach・Impact・Effortそれぞれの見積もりに、どれだけ根拠があるかを見ます。
Reachは実データで確認できているのか。Impactはユーザーリサーチや過去施策で裏づけられているのか。Effortは開発・デザイン・運用まで含めて見積もれているのか。
NotionのRICE解説では、ConfidenceはReach・Impact・Effortという他の3項目の正確性に対する評価として扱われています。100%は3項目すべてにメトリクスやリサーチの裏づけがある状態、80%は3項目中2つに楽観的（optimistic）である状態、50%は3項目中2つに自信がない状態、と整理しています。
Confidenceを細かく刻みすぎず、100%・80%・50%くらいの粗い段階にまとめるのは、見積もりの根拠の厚みを大まかにそろえ、スコアを必要以上に複雑にしないためです。
統一されたシンプルなルールで管理することで、Confidenceは単なる「自信の強さ」ではなく、見積もりの根拠を点検するための項目として機能します。
また、50%と置く根拠すら薄い候補は、そのまま実装優先度の比較に載せるより、先に検証すべき仮説として切り出した方がよいでしょう。Reachが読めないならログ分析や対象ユーザーの確認。Impactが読めないならユーザーリサーチやプロトタイプ検証。Effortが読めないなら技術調査や仕様整理。
そう考えると、Confidenceは単なるブレーキではなく、学習すべき場所を示す目印になります。
RICEのスコアに振り回されないために
RICEは比較するには便利ですが、スコアは現時点の情報をもとにした予測値であり、あくまで意思決定を助けるものです。
式の構造による特性や概算の不確実性等を念頭に置いたうえで、数値の差に過度に敏感になるよりどの変数でスコアを稼いでいるのか、どこに根拠がありどこに仮説が残っているのかを見ることが重要です。
そして狩野モデルの分類と同じように、RICEも市場環境、顧客の要求、チームのリソースが変われば、当然スコアも変わります。状況の変化に適応できるよう再評価することも忘れてはいけません。
終わりに
ここまでの罠に共通しているのは、フレームワークの構造が、結論の見え方を静かに変えることです。
狩野モデルは候補の性質を整理できますが、その分類は時間とともに変わります。RICEは候補を数値で比べられますが、比較対象の置き方やEffort、Confidenceの扱いで順位は変わります。
出てきた数字をそのまま答えにするのではなく、その数字が今、何を前提にしているかを見ることが重要です。
これは同じ土俵で比べてよい候補なのか。このスコアはどの変数で稼いでいるのか。その数字は、狙っているアウトカムにつながるものを測っているのか。
INSPIRED の著者Marty Caganは、ロードマップに関するSVPGの記事で典型的なロードマップが機能やプロジェクトのリストになり、アウトプット中心の計画になりやすいことを指摘しています。重要なのは何を作るかではなく、その先でどんな顧客価値や事業成果を生むのかです。
優先順位づけは点数の高い順に並べることではありません。指標が映しているものとまだ映していないものを見分けながら、戦略に照らして何をやるか、何を見送るかを引き受けることです。
フレームワークを使った先に残るその判断まで含めて、PdMの仕事なのだと思います。