PdMのKPI設定が「絵に描いた餅」になる理由。目標達成するための因数分解と優先度管理術

「KPIを設定したものの、具体的な施策に落ちていない」
「施策の優先順位が、声の大きい人の意見や思いつきで決まってしまう」
「リリースした機能が、どの数字に貢献したのか振り返れていない」

プロダクトマネージャー（PdM）にとって、機能を作ることは手段に過ぎません。本来の仕事は「数字（KPI）を伸ばすこと」です。

しかし、多くの現場では「とりあえず機能を作ること」が目的化し、KPIがお飾りになっています。
なぜKPIがワークしないのでしょうか？

それは、「KGI（最終ゴール）から施策までの因数分解（ロジック）」と「何をやって何をやらないかの判断基準（優先度）」の2つが設計されていないからです。

今回は、感覚に頼らず、ロジカルに数字を伸ばすための「KPI設計」と「優先度管理」の型について解説します。

1. KPIは「ツリー」で分解しないと意味がない

よくある失敗は、いきなり「MAU（月間アクティブユーザー）を追おう」と決めてしまうことです。
MAUは結果指標（KGIに近い指標）であり、直接コントロールできません。

現場のPdMが追うべきは、もっと分解された先行指標です。
これを可視化するのが「KPIツリー」です。

因数分解の例（ECサイトの場合）

• 売上 ＝ 訪問数 × CV率 × 客単価
• 訪問数 ＝ 新規流入 ＋ リピート流入
• 新規流入 ＝ 広告経由 ＋ 自然検索 ＋ SNS

ここまで分解して初めて、「今月は『自然検索』が弱いから、記事コンテンツを強化しよう」という具体的なアクションが見えてきます。
KPIツリーがないチームは、地図を持たずに航海しているようなものです。

2. 施策の優先順位は「ICEスコア」で決める

やるべき施策が見えても、リソースは有限です。
ここで「社長が言ったから」「営業が急かしているから」で優先度を決めてはいけません。

成果を出すPdMは、「ICE（アイス）スコア」などのフレームワークを使って、機械的に優先順位を判断しています。

• Impact（インパクト）： その施策でKPIはどれくらい伸びるか？（10段階）
• Confidence（確信度）： その予測にどれくらい根拠があるか？（10段階）
• Ease（容易性）： どれくらい少ない工数で実装できるか？（10段階）

スコア ＝ I × C × E

このスコアが高い順に並べることで、「工数が少ない割にインパクトが大きい施策（Quick Win）」を逃さず着手できるようになります。
また、ステークホルダーからの「あれもやって」という割り込みに対しても、「スコアが低いので後回しです」とロジカルに断れるようになります。

3. 数字と施策を「1枚のボード」で管理する

KPIツリーと優先度（ICEスコア）は、別々に管理してはいけません。
「どのKPIを伸ばすために、どの施策を、どの優先順位でやるのか」が一覧で見える状態を作る必要があります。

私は普段、これをNotion上の1つのダッシュボードで管理しています。
目標（KPI）と手段（施策）が紐付いているため、チーム全員が「今なぜこれを開発しているのか」を理解した状態で走ることができます。

KPIを決めただけでは、数字は伸びない

ここまで「何をやるべきか（KPI・優先度）」を決める話をしてきました。
しかし、PdMの仕事はここで終わりではありません。

決定した施策を、エンジニアに正しく伝え、バグなくリリースして初めて数字は動きます。

多くのPdMは、KPI設計で満足してしまい、その後の「要件定義」や「ドキュメント作成」で手を抜いてしまいます。
その結果、手戻りが起きたり、意図と違うものができたりして、結局KPIは達成されません。

「正しい目標」を決めたら、次は「正しい実装」に進みましょう。