ロードマップPM意思決定

データで語るロードマップ|優先順位を説明できるようにする

2026年08月04日 ・ Stride

四半期のロードマップを開くと、機能名がずらりと並んでいる。誰が言い出したのかは思い出せるのに、なぜ今それをやるのかはうまく説明できない。

そんな状態になっていませんか。

ロードマップが要望リストに変わってしまうのは、PMの怠慢ではありません。判断の材料が揃わないうちに、締め切りだけが先に来るからです。

この記事では、優先順位に数字の裏づけを持たせる組み立て方を、機会サイズの見積もりからステークホルダーへの説明、そして見直しの運用まで順番に整理します。

ロードマップが要望リストになる理由

最初に言葉を揃えておきます。ロードマップとは、これから何にチームの時間を使うかを、時間軸に沿って示したものです。

機能の一覧表ではありません。時間という有限な資源の、配分表です。

ここが曖昧なまま運用すると、ロードマップは自然と要望の置き場所になります。営業から3件、カスタマーサポートから2件、経営から1件。

どれも正しい要望です。だから断りづらい。

いちばん声が大きい人の意見が通る

根拠が並んでいないと、議論は好みのぶつけ合いになります。そうなったとき勝つのは、いちばん役職が上の人か、いちばん粘り強い人です。

これは人格の問題ではなく、構造の問題です。比較の物差しが用意されていないので、比較のしようがないだけ。

厄介なのは、通ったあとに誰も検証しないことです。効果が出なくても、言い出した人の面目があるので触れにくくなります。

そして次の四半期も、同じやり方で決まっていきます。

全部やると約束してしまう

もう1つのつまずきが、優先順位をつけずに全部を積むことです。要望を断ると角が立つので、とりあえず後ろのほうに置いておく。

その結果、ロードマップは実現不可能な量になります。入りきらない予定表は、予定表として機能しません

しかも、後ろに置かれた項目は期待として残り続けます。やらないと決めていないので、半年後にまだ聞かれる。

やらない判断を明示しないことは、優しさではなく先送りです。

データで語るとは、数字が答えを出すことではありません

誤解されやすい点を先に潰しておきます。データで語るロードマップとは、スコアの高い順に並べて機械的に決めることではありません。

新しい価値を生む施策ほど、過去のデータは薄いものです。数字だけで決めると、確実に測れる小さな改善ばかりが上位に来ます。

半年後、CVRは0.2ポイント上がったけれど、プロダクトとしては何も変わっていない。そんな結末になりがちです。

では数字は何のためにあるのか。役割は3つに整理できます。

まず、大きさの単位を揃えること。声の大小ではなく、影響を受ける人数と伸びしろで比べられるようにします。

次に、見込み違いに早く気づくこと。事前に効果の見込みを書いておけば、あとで答え合わせができます。

最後に、合意のコストを下げること。同じ数字を見ていれば、議論は好き嫌いではなく解釈の話になります。

判断そのものはPMがします。数字は、その判断を説明可能にする道具です。

根拠は4つの要素に分解すると揃えやすい

やみくもに数字を集めても、ロードマップの材料にはなりません。何を埋めれば説明できるのかを、先に決めておきます。

実務で使いやすいのは、次の4つに分けることです。

要素 何を見るか どこから取るか
機会の大きさ 影響を受ける人数と伸びしろ ファネルの各ステップ到達数
確からしさ その仮説をどれだけ信じられるか 過去の検証結果、定性調査
コスト 実装と運用にかかる時間 開発チームの見積もり
戦略への適合 会社が今年伸ばしたい指標に効くか 北極星指標とKPIツリー

4つとも埋まらない施策があっても構いません。埋まらないこと自体が、判断材料になります。

たとえば機会の大きさが書けないなら、それは影響範囲を誰も把握していないということ。まず調べるところから始めればいい。

4つ目の戦略への適合だけは、施策ごとに調べて埋めるものではありません。会社として今年どの指標を伸ばすかが決まっていないと判定しようがないので、プロダクト指標の設計|北極星指標とKPIツリーの作り方を先に整えるほうが早道です。

機会サイズは、ファネルの引き算で出す

いちばん詰まりやすいのが、機会の大きさの見積もりです。ここは推測ではなく、実際の到達数から引き算で出します。

ファネル分析とは、訪問からゴールまでの各ステップに何人到達したかを段階的に並べ、どこで人が減るかを見る手法です。この数字がそのまま機会サイズの分母になります。

具体例で見てみましょう。あるBtoBサービスのサイトで、こんな数字が出ていたとします。

月間セッション            40,000
 └ 料金ページ到達          8,000   (20.0%)
    └ 申込フォーム到達     1,600   (20.0%)
       └ 送信完了            480   (30.0%)

■ 施策の見込み
フォームの入力項目を12→6に減らし、送信率を 30% → 38% へ
  480件 → 608件 / 月   (+128件)
  商談化率 40% × 受注率 25% × 客単価 30万円
  → 月あたり +384万円の見込み

ここまで書けると、話が変わります。やりたい機能ではなく、月384万円の機会として提示できるからです。

ポイントは、率ではなく件数と金額まで落とすことです。送信率8ポイント改善という言い方だと、経営には大きさが伝わりません。

なお、料金ページ到達20%という数字自体にも意味があります。フォームより手前の落ち方が大きければ、優先すべきはフォームではなく導線かもしれない。

どのステップに手を入れるかを決める考え方は、ファネル分析の基本|離脱ポイントの見つけ方と改善の進め方で詳しく扱っています。

Strideのファネル分析は、訪問から登録・購入までの各ステップの到達数と離脱をそのまま可視化できるので、この引き算のための集計を毎回組み直す必要はありません。

ただし、ここで正確に線を引いておきます。ウェブ解析で見えるのは、訪問・回遊・フォーム到達・コンバージョン・再訪といったサイト側の行動までです。

ログイン後のプロダクト内で機能がどれだけ使われたかを追うには、別途プロダクト分析の仕組みが必要になります。ロードマップの根拠を集めるときは、どちらの数字なのかを混ぜないでください。

確からしさは、根拠のレベルで割り引く

もう1つの落とし穴が、見込みを楽観的に書いてしまうことです。誰でも自分の企画は通したいので、自然と数字が甘くなります。

そこで、根拠の強さに応じて機械的に割り引くルールをチームで決めておきます。目安はこんな形です。

根拠のレベル 確度の目安
自社で検証済み 過去のA/Bテストで差が出た 80%
定量の傾向がある ファネルで大きな離脱を確認済み 60%
定性の声がある 該当の不満をユーザー数名から聴取 40%
思いつきのみ 会議で出た提案 20%

数字の絶対値に意味はありません。大事なのは、根拠の弱い施策が自動的に下がる仕組みを持つことです。

先ほどの例で、送信率30%→38%という見込みに確度60%を掛けると、期待値は月+77件になります。それでも十分大きいなら、やる価値はある。

確度を上げたければ、根拠のレベルを1段上げにいけばいい。ユーザーの操作を実際に見る、アンケートで聞く、小さくテストする。

Strideのセッションリプレイは記録の時点で全テキストを伏せ字にし、入力値や画像は保存しません。どの入力欄で手が止まっているのかを、個人情報を抱え込まずに確認できます。

20件も見れば、だいたい同じ場所で止まっているのがわかりますよ。

RICEやICEは、実データを入れて初めて働きます

優先順位づけのフレームワークとして有名なのが、RICEとICEです。名前だけ知っているという方も多いのではないでしょうか。

RICEは、Reach(対象人数)、Impact(1人あたりの効果)、Confidence(確度)、Effort(工数)の4つでスコアを出す方法です。計算式は Reach × Impact × Confidence ÷ Effort。

ICEはそこからReachを外した簡易版で、Impact × Confidence × Ease(やりやすさ)で出します。項目が少ないぶん、素早く並べ替えたいときに向いています。

先ほどのファネルの数字を、そのままRICEに入れてみます。3つの候補を並べてみましょう。

施策Aは、申込フォームの入力項目を12から6へ減らす案です。Reachは月1,600人、Impactを0.3、Confidenceを0.6、Effortを1.5人月とすると、1,600 × 0.3 × 0.6 ÷ 1.5 = 192

施策Bは、トップと事例ページから料金ページへの導線を足す案。Reachは月40,000人と大きい一方でImpactは0.02と小さく、Confidence 0.4、Effort 0.5人月で、40,000 × 0.02 × 0.4 ÷ 0.5 = 640

施策Cは、管理画面のダークモード対応です。Reach 900人、Impact 0.05、Confidence 0.8、Effort 2.0人月で、900 × 0.05 × 0.8 ÷ 2.0 = 18

数字の中身より、施策AとBのReachとImpactにファネルの実測値が入っている点を見てください。ここが推測だと、スコアは精密に見えるただの願望になります。

そして結果は少し意外だったのではないでしょうか。工数の小さい導線追加が、手間のかかるフォーム改善を3倍以上上回りました。

スコアの高い順に着手してはいけない

ここが重要なところです。RICEはあくまで議論を始めるための並び順であって、決定ではありません。

限界を3つ挙げておきます。

  • 過去データのない新しい賭けは、Reachが低く見積もられて必ず下位に沈む
  • 法対応やセキュリティ対応は、やらない選択肢がないのでスコア比較の対象外
  • 基盤の作り直しは効果が間接的で、Impactを正直に書くほど負ける

つまりフレームワークは、既存の改善施策を横並びで比べるときにいちばん力を発揮します。性質の違うものを同じ土俵に乗せると、必ず歪みます。

対処はシンプルで、枠を分けることです。四半期の開発時間を、改善に6割、新しい賭けに2割、技術的負債と保守に2割といった形であらかじめ配分しておく。

そのうえで、それぞれの枠の中だけでスコアを比べます。こうすると、賭けの枠を守る議論と、枠の中で何をやるかの議論を分けられます。

スコアの付け方や運用の詳細は開発の優先順位づけ|RICEとICEをデータで運用するにまとめました。

ステークホルダーには、順番と理由をセットで出す

材料が揃っても、伝え方で台無しになることがあります。ロードマップを一覧で見せるだけだと、必ず自分の要望を探されるからです。

おすすめは、施策1つを決まった型の6行で書くことです。書式を固定すると、抜けている検討にすぐ気づけます。

[施策]     申込フォームの入力項目を 12 → 6 に削減
[なぜ今]   フォーム到達1,600に対し完了480。導線上で最大の離脱
[効果見込] 送信率 30% → 38%(+128件/月、確度60%で期待値+77件)
[根拠]     リプレイ20件中14件が会社名・部署の入力途中で離脱
[コスト]   1.5人月 + A/Bテストによる検証2週間
[外れたら] 2週間で差が出なければ元に戻し、次の候補へ

最後の1行が効きます。外れたときの撤退条件を先に書いておくと、提案が賭けではなく実験として受け止められるからです。

追加要望への答え方

説明の場で必ず出るのが、これも入れてほしいという声です。ここで反射的に持ち帰りますと答えると、静かに全部やる約束が積み上がります。

答え方は1つだけ覚えておけば足ります。何を後ろに下げるかとセットで相談させてくださいと返すことです。

トレードオフの提示は、拒否ではありません。時間の総量が変わらない以上、当然の確認です。

そのうえで、相手の要望を4つの要素の型で一緒に埋めてみるといい。機会の大きさが書けないと気づいた時点で、たいてい相手のほうから順位を下げてくれます。

やらないことを、明文化して残す

ロードマップに載せなかった項目は、消すのではなく別の場所に残します。見送り理由つきの一覧として置いておくのがおすすめです。

理由が書いてあれば、状況が変わったときに再検討できます。逆に理由がないと、同じ議論を3か月ごとに繰り返すことになります。

やらないと決めたことを可視化するのは、勇気がいります。でもこれをやると、ロードマップへの信頼が目に見えて上がりますよ。

見直しは、決めた日にやる

作ったロードマップは、必ず外れます。だから見直しの日をあらかじめカレンダーに入れておきます。

気づいたときに直すという運用は、実際には忙しさで流れます。リズムを固定しましょう。

  • 週次:走っている施策の実測値を、見込みと並べて確認する
  • 月次:四半期のロードマップの並び順を、新しい数字で再確認する
  • 四半期:枠の配分そのものと、前四半期の見込み精度を振り返る

このうち、いちばん価値があるのに省略されやすいのが四半期の振り返りです。

見込みと実測の差を記録する

やることは単純です。効果見込みに書いた数字と、実際に出た数字を並べて残すだけ。

たとえばフォーム改善の見込みが+128件で、実測が+41件だったとします。この差そのものより、なぜ外れたかの一言メモが資産になります。

入力項目を減らしたぶん、営業側で確認の手間が増えていた。あるいは、離脱していたのは項目数ではなく確認画面の分かりにくさだった。

こうした記録が10件たまると、チームの見積もりは目に見えて現実的になります。当たったかどうかではなく、外れ方の癖を知ることが目的です。

なお、実測を出すには変更前後を正しく比べる必要があります。同じ期間に別の施策や広告出稿が重なっていると、差の原因が特定できません。

その意味でも、効果検証は同時に出し分けて比べるA/Bテストで行うのが確実です。StrideのA/Bテストはノーコードで、サイトを開いたままビジュアルに編集して作れるので、検証を開発の待ち行列に入れずに回せます。

途中で止める勇気を持つ

見直しの目的は、続けることではなく止めることです。始めた施策を最後までやりきるのは美徳に見えますが、外れたとわかった時点で止めたほうが、次に使える時間が増えます。

そのために、開始時点で撤退条件を書いておきました。あの1行は、未来の自分を守るための保険です。

止めた記録も残してください。止められるチームだと分かれば、次の提案はもっと大胆になります。

まとめ

データで語るロードマップとは、数字に決めてもらうことではありませんでした。判断はPMがして、その判断を他人が検証できる形にすることです。

やることは4つです。機会の大きさをファネルの実数から出す根拠の強さで見込みを割り引く枠を分けたうえでスコアを比べる見込みと実測の差を記録する

どれも新しい手法ではありません。ただ、この4つが揃うと、なぜこれを先にやるのかという問いに30秒で答えられるようになります。

まずは今のロードマップの上位3件について、機会の大きさを件数と金額で書き出してみませんか。書けない項目が見つかったら、それが最初の宿題です。

Strideで、あなたのサイトの導線を可視化しませんか?

Cookieレスで、離脱ポイントとコンバージョンが数分でわかります。

無料で始める