Roadmapの優先順位付け: RICE vs Kano vs オポチュニティ・ソリューション・ツリー

あるチームがRICEスコアリングによって1年間、誰も必要としない機能を作り続けるのを目の当たりにしたことがあります。15項目、すべて丁寧にランク付けされ、すべてスケジュール通りにリリースされました。アクティベーションは動きませんでした。リテンションも動きませんでした。アカウントあたりの収益は横ばいのままでした。CEOがとうとう、すべてのPMが恐れる問いを発しました。「実際に何を学んだのか?」誰もまともな答えを持っていませんでした。フレームワークは最初から学習のためのものではなかったからです。リストの順番を守ることが目的でした。

優先順位付けフレームワークとはそういうものです。多くのPMがRICEを使うのは、Intercomが2017年にブログで紹介し、Notionを使うすべてのプロダクト組織に広まったからです。厳密に見えます。数字を出します。スプレッドシートを見るとステークホルダーはうなずきます。しかしフレームワークは、roadmapの問題への答えではありません。チームが避けている会話を強制するための仕掛けです。正しい会話を強制するものを選べば、より良いリリースができます。間違ったものを選べば、多くのリリースができます。

では、実際に守ることを求められる3つについて、それぞれが得意なこと、崩れる場面、そして組み合わせるべきときを話しましょう。

RICEの計算式、実際の数字で

RICEはReach(リーチ)、Impact(インパクト)、Confidence(確信度)、Effort(工数)の頭文字です。計算式はシンプルです:

スコア = (Reach × Impact × Confidence) / Effort

• Reach: 一定期間内に影響を受けるユーザー数。通常は月次。「影響を受ける」の意味は正直に定義してください。
• Impact: 影響を受けたユーザー1人あたり、目標指標がどれだけ動くか。Intercomのオリジナルルーブリックは、massive/high/medium/low/minimalに対して3/2/1/0.5/0.25を使います。意図的に粗めの設定です。
• Confidence: パーセンテージ。100%はデータがあること。80%は根拠があること。50%は推測です。
• Effort: プロダクト、デザイン、エンジニアリングを合わせた人月。

実際の例で見てみましょう。月間アクティブアカウントが4,000の B2B SaaS を想定し、来クォーターのroadmap候補3つをスコアリングします:

一括インポートが大差で勝ちます。正直、このスコアリングであれば当然です。確信度が高く、リーチも適切で、工数が少ない。RICEはまさに設計どおりに機能しています。コストが低く効果が高い明らかなベットを浮かび上がらせています。

RICEが本当に機能するとき:

• 明確なKPIを持つ成熟したプロダクト。 アクティベーション、リテンション、コンバージョンがどういう状態かわかっています。インパクトを合理的な範囲で予測できます。
• 並行してリリースする大規模チーム。 5つのスクワッドがシーケンスを調整する必要があるとき、共通のスコアリングルーブリックは10回の会議より効率的です。
• 財務志向のエグゼクティブへのトレードオフの説明。 CFOはRICEテーブルを読めます。カスタマージャーニーマップは読めません。

RICEが崩れる場面:

• 初期プロダクト。 まだ本当のオーディエンスがわかっていないため、Reachは推測です。成功がどういう状態かわかっていないため、Impactは願望です。
• ディスカバリー段階のベット。 RICEはConfidenceの乗数によって不確実性にペナルティを与えます。つまり、本当に新しいものは何でも、段階的なものすべてに押しつぶされます。Roadmapは一括インポート機能で埋まり、軌道を変えられるかもしれないベットは永遠に入りません。
• 戦略的なベット。 「中規模市場に拡大すべきか?」はRICEテーブルには収まりません。試みないでください。

率直な評価: RICEは計測できるものを最適化します。重要なものではなく。計測が簡単な場所で使い、そうでない場所では使わないでください。

Kanoモデル、実際に機能するアンケート質問とともに

Kanoモデルは、RICEより古くて奇妙なモデルです。狩野紀昭氏が1980年代に、なぜある機能は顧客に愛され、ある機能はほとんど気づかれないのかを説明するために構築しました。5つのカテゴリがありますが、優先順位付けに必要なのは3つだけです:

• 当たり前品質(Must-have): あれば気づかれず、なければ激怒される。二要素認証。CSVエクスポート。まともな検索。これらを構築しても愛着は生まれません。省略すれば離脱します。
• 一元的品質(More is better): 満足度は比例的です。ページの読み込み速度、統合機能の数、稼働率の向上。コストに見合う投資が価値を持ちます。
• 魅力的品質(Delighters): 顧客は期待せず、求めることもできませんが、提供されると喜びます。デモを成約させる要素。Slackのスレッド機能、Linearのキーボードショートカット、Figmaがローンチした時のマルチプレイヤーカーソルがその例です。

他の2つのカテゴリ(無関心品質と逆品質)は機能を削るための判断基準です。無関心品質は誰も気にしないことを意味します。逆品質は一部のユーザーが積極的に嫌うことを意味します(穏やかな生産性ツールにおける攻撃的なAI提案を想像してください)。

私が実際に使うアンケートの質問テンプレートです。機能ごとに2つの質問:

1. このプロダクトにこの機能があれば、どう感じますか?
2. このプロダクトにこの機能がなければ、どう感じますか?

両方を5段階で回答します: 気に入る / 当然だと思う / どちらでもない / 許容できる / 嫌だ。

クロス集計でカテゴリが判明します。「気に入る / なければ嫌」= 一元的品質。「どちらでもない / なければ嫌」= 当たり前品質。「気に入る / なくてもどちらでもない」= 魅力的品質。セグメントごとに50〜100人の顧客に実施すれば、守るに値するシグナルが得られます。

Kanoが優れているとき:

• 機能パリティの判断。 「競合Xがある機能をリリースした。必要か?」Kanoはその機能が当たり前品質(今すぐリリース)、一元的品質(スケジュールに沿ってリリース)、魅力的品質(差別化できるときのみ)を教えてくれます。
• スコープ削減。 エンジニアリングが仕様書には6週かかると言い、手元には4週しかないとき、Kanoは何を削るべきかを教えてくれます。当たり前品質が未完成なら、魅力的品質から削ります。
• 「これを作るべきか?」の判断。 ある機能が無関心品質のスコアなら、データが撤退を告げています。

罠: Kanoには本物の顧客データが必要で、PMの直感的な分類は通用しません。3人が会議室で一括削除をどの列に入れるかを議論するだけのKano分析でroadmap全体を正当化しているのを見たことがあります。それはKanoではありません。PMが意見をフレームワーク名で正当化しているだけです。

オポチュニティ・ソリューション・ツリー、価値を発揮するとき

Teresa TorresがOSTを構築したのは、継続的ディスカバリーを実践するチームのためです。構造:

                  アウトカム
                     |
       -----------------------------
       |             |             |
  オポチュニティ オポチュニティ オポチュニティ
       |             |             |
   ---------     ---------     ---------
   |       |     |       |     |       |
 ソリューション ソリューション ソリューション ... ソリューション
   |
実験

1つのアウトカム(「トライアルから有料への転換率を15%向上」といった計測可能なビジネス成果)から始めます。毎週の顧客インタビューから収集したオポチュニティ(顧客のペインポイント、未充足のニーズ、摩擦の瞬間)をマッピングします。各オポチュニティの下に複数のソリューションをブレインストーミングします。有望なソリューションの下に、構築前に検証するための実験を設計します。

このモデルの優れた点は、階層を強制することです。ソリューション同士を優先順位付けすることはできません。オポチュニティのみを優先順位付けし、選んだオポチュニティに最良のソリューションを選びます。

OSTが優れているとき:

• 継続的ディスカバリーのチーム。 週次で顧客との接触を実施し、プロトタイプテストを行うチーム。ディスカバリーが新たなオポチュニティを発見するにつれてツリーが更新されます。
• アウトカム主導の組織。 リーダーシップが機能リストではなくアウトカムとして目標を設定する場合。OSTはアウトカムをディスカバリーと構築のパイプラインに変換します。
• 機能工場モードの回避。 OSTの最大の強みは、ソリューションがオポチュニティに、オポチュニティがアウトカムに連鎖していないときに可視化できることです。繋がらないなら、作らない。

OSTが失敗する場面:

• 「ディスカバリー」が四半期に1回のユーザーインタビューを意味する組織。 OSTは継続的ディスカバリーのオペレーティングシステムです。ディスカバリーのリズムなしでは、ツリーは装飾品です。発見したオポチュニティではなく、仮定したオポチュニティでツリーを埋めることになります。
• リサーチアクセスのないチーム。 PMが月5件の顧客コールのために奮闘しなければならない環境では、OSTは理想論であり、運用可能なものではありません。
• 純粋な実行クォーター。 更新を阻んでいる課題をリリースしなければならないときがあります。OSTは既知の8つの機能をシーケンスするのに役立ちません。

「Now/Next/Later」とRICEの本質

ほとんどの「Now/Next/Later」roadmapは、数字を隠したRICEランキングです。PMがすべてをスコアリングし、上位がNowに、中間がNextに、下位がLaterに入りました。フォーマットは柔軟そうに見えますが、優先順位付けはソートされたスプレッドシートと同一です。

各バケットが異なる認識論的基準を持つとき、フォーマットは本当の意味を持ちます:

• Now: 確信度が高く、スコープが決まり、コミット済み。これはリリースします。チームがアウトカムを所有します。
• Next: 中程度の確信度、問題は検証済み、ソリューションはまだディスカバリー中。これが重要だと信じています。ソリューションが機能することはまだ証明されていません。
• Later: ソリューションではなくオポチュニティ。顧客から聞いたが、まだスロットを獲得していないもの。

「Later」バケットに工数見積もり付きの機能名があるなら、数字を隠しただけのRICEをやっています。「Later」バケットに未解決の問いを伴う顧客の課題があるなら、正しくやっています。

Confidence、誰も正直にスコアリングしない入力値

会ったことのあるすべてのPMが、自分のお気に入りの機能のConfidenceを水増しします。キャリブレーションツールになるはずのConfidence列が、感覚で入力する列になっていくのを目の当たりにしてきました。

解決策: 感情ではなく根拠に紐づけられたConfidenceルーブリックです。

60%未満のものは、どのフレームワークのNow列にも入れるべきではありません。40%未満のものは、roadmap上の機能ではなく、OSTのオポチュニティであるべきです。2クォーター以上roadmapに載っているのに60%の確信度に達せないものは、削除してください。そのままにしておくコストは、実際の進捗なしに進捗しているように見えることです。

ステークホルダーがRICEを嫌う理由

「RICEがうまくいかない」と言うすべてのチームとする診断的な会話があります。問題はほぼ常にフレームワークではありません。翻訳のレイヤーです。

営業がRICEを嫌うのは、顧客の要望がReachで低くスコアされるからです。 営業は年8万ドルを支払う見込み客から来た商談を阻む要望を持ってきます。その顧客のReachは1です。RICEスコアは端数です。営業はこれを「PMは収益を気にしていない」と読みます。解決策: 商談を阻む要望をRICEから完全に引き出します。勝率インパクトに基づいてサイズ設定された「商談ブロッカー」レーンを別途維持します。そのレーンが存在することを営業に伝えます。

CSがRICEを嫌うのは、リテンションのベットがImpactで低くスコアされるからです。 リテンションに関する機能は短期的な指標の変動をほとんど示しません。6ヶ月後に発生するはずの解約を防いでいます。RICEのImpactは将来を見越していますが、ほとんどのPMは四半期ごとの変動でスコアリングします。解決策: リテンションのベットを分けて、Impactを四半期のアクティベーションではなく年換算の解約率の変動としてスコアリングします。

エンジニアリングがRICEを嫌うのは、Effortがあなたの推測であり、彼らのものではないからです。 PMは類似の過去の機能に基づいてEffortを見積もります。エンジニアリングはコードベースに3つの地雷があることを知っています。解決策: 自分のEffort数値でRICEスコアを公開しないでください。レンジ(1〜2人月、3〜5人月、6人月以上)を使い、簡単なスコーピングパスの後でエンジニアリングに絞り込ませます。PMがReach、Impact、Confidenceを担います。エンジニアリングがEffortを担います。

パターン: RICEは1つの数字を出しますが、4つの入力は4つの異なるステークホルダーから来ます。単一のスコアを根拠を示さずに公開すると、各ステークホルダーは自分が気にする入力値だけを読み、それに異議を唱えます。入力値を見せてください。Reachについてはマーケティングと、Impactについてはデータチームと、Confidenceについてはリサーチと、Effortについてはエンジニアリングと議論してください。スコアはそれら4つの会話のアウトプットであり、代替品ではありません。

3つを組み合わせるとき

私が実際に使うやり方です:

1. OSTを使って正しいオポチュニティを見つける。 継続的ディスカバリーを通じてアウトカムを顧客のオポチュニティにマッピングします。最も強い根拠と最大のアウトカムへのインパクトを持つオポチュニティを選びます。課題を熟知している場合はこのレイヤーをスキップしてください(成熟した機能、よく理解されたドメイン)。誰も求めていない機能をチームがリリースしているなら、スキップしないでください。

2. Kanoを使ってソリューションを分類する。 オポチュニティを選び、2〜3つの候補ソリューションが揃ったら、実際の顧客データでKanoを候補に実施します。ソリューションが明らかに当たり前品質(認証、エクスポート、アクセシビリティ)なら、このレイヤーをスキップしてください。「既存機能を速くする」と「魅力的な瞬間を加える」の間で選ぶ場合で、どちらを顧客が本当に評価するかわからないなら、スキップしないでください。

3. RICEを使って構築をシーケンスする。 構築するオポチュニティとソリューションを選んだら、RICEでクォーター内のシーケンスを組みます。Effort、依存関係、キャパシティ。RICEはシーケンシングツールであり、ディスカバリーツールではありません。そこに本来の価値があります。

このフルスタックはほとんどのチームにとってほとんどの場面で過剰です。成熟したCRMの段階的な改善をリリースするチームは毎クォーターOSTを必要としません。クリーンな backlog に対するRICEが必要です。プロダクトマーケットフィット前のスタートアップはRICEを必要としません。OSTとroadmapの半分を捨てる覚悟が必要です。フレームワークの深さを実際の認識論的状況に合わせてください。リサーチアクセスのないチームにOSTを強制することは形式だけの話です。KPIを把握していないチームにRICEを強制することは、精度なき正確さです。

フレームワークは答えではありません。チームが避けている会話を強制するものを選んでください。チームが顧客との接触を避けているなら、OSTを使ってください。チームがスコープ削減を避けているなら、Kanoを使ってください。チームがシーケンシングのトレードオフを避けているなら、RICEを使ってください。そして、チームが3つ全部を避けているなら、問題はフレームワークではありません。誰も本当の決断をしたくなく、スプレッドシートではそれは解決できません。

関連ガイド

• PM求人票(関連)
• PMのための継続的ディスカバリーの習慣
• エンジニアが嫌がらないPRDの書き方
• エンジニア・デザインとの四半期計画