プロダクトマネージャー（PdM）の仕事のなかで、もっとも失敗が多く、かつリカバリーに時間がかかるのが「KPIの設計ミス」です。そのなかでも特に多いのが、KPIを単体で設定してしまい、「何をすればその数字が動くのか」が現場に伝わらないケースです。月次レビューでKPIを見ても、なぜ下がったかの原因がわからない。施策を打ってもどのKPIに効くかが曖昧なまま進む。これは「KPIの孤立」と呼ぶべき状態で、KPIツリーを正しく設計することで解消できます。
本記事では、プロダクトマネージャーがKPIツリーを作成する際の具体的な手順を、よくある失敗パターンと実例を交えながら解説します。SaaS型プロダクトを例として、KGI（最終目標指標）からアクション指標まで4階層のツリーを構築するプロセスを追います。また、ツリーを作って終わりではなく、日々の意思決定・施策立案・チームコミュニケーションに活かすための運用のコツも紹介します。
KPIツリーとは何か？基本概念の整理
KPIツリーとは、プロダクトの最終目標指標（KGI）を起点として、それを達成するための構成指標を段階的に分解した木構造（ツリー）のことです。KGIを頂点に、下に向かって「中間KPI → 先行KPI → アクション指標」と階層を下げるほど、より具体的でコントロール可能な指標になっていきます。
例えば、SaaSプロダクトの場合を考えてみましょう。
- KGI（頂点）: 月次経常収益（MRR）を四半期内に20%成長させる
- 中間KPI（レイヤー1）: 新規MRR、拡張MRR、チャーンMRR（解約によるMRR減）
- 先行KPI（レイヤー2）: トライアル転換率、アップグレード率、チャーン率
- アクション指標（レイヤー3）: 機能利用率、サポート対応時間、オンボーディング完了率
このように、KGIは「結果」を示す指標であるのに対し、下の階層ほど「原因・プロセス」を示す指標になります。現場のエンジニア・デザイナー・CSメンバーが日々動かせるのはアクション指標であり、その積み重ねが先行KPIを動かし、最終的にKGIの改善につながるという因果の連鎖をツリー構造で可視化するのがKPIツリーの本質です。
KPIツリーとKPIダッシュボードの違い
「ダッシュボードにKPIを並べているから同じではないか」という誤解があります。ダッシュボードは「複数のKPIを見えるようにする」ツールですが、KPIツリーは「KPI同士の因果構造を設計する」フレームワークです。ダッシュボードは可視化、ツリーは設計思想です。KPIツリーが正しく設計されていないと、ダッシュボードに並んだ数字が「なぜ下がったか」の議論につながりません。
KPIツリーとOKRの違い
OKR（Objectives and Key Results）との違いも整理しておきます。OKRは四半期ごとにストレッチな目標を設定し、達成率70%程度を良しとする「目標管理の仕組み」です。一方、KPIツリーは「プロダクトの健全性を継続的にモニタリングする構造」です。OKRのKey ResultsにKPIツリーの指標を活用することはできますが、両者は役割が異なります。KPIツリーは年間を通じて機能するインフラ的な指標設計であり、OKRはその上で期ごとのチャレンジを設定するための仕組みです。
なぜKPIツリーが必要なのか？「指標の孤立」問題
PdMが単体のKPI（例：「MAUを増やす」）だけを設定した場合、以下のような問題が起きます。
問題1：原因分析ができない MAUが前月比10%下落したとき、「なぜ下がったか」を説明するために、施策との因果関係を後付けで探すことになります。KPIツリーがあれば、「新規ユーザー獲得数は変わらないのに、7日以内の再訪率が下がっている → 初期体験に問題がある可能性」と即座に絞り込めます。
問題2：チームが何をすればいいかわからない 「MAUを増やせ」というゴールだけでは、エンジニアもデザイナーも「自分のタスクがどのKPIに効くのか」を判断できません。KPIツリーがあると、「このUI改善は初回完了率（アクション指標）→ 7日以内再訪率（先行KPI）→ MAU（中間KPI）に連鎖する」とロジックを説明できます。
問題3：施策の優先順位がぶれる ツリーがない状態では、各チームが「自分のタスクが重要だ」という論理を個別に展開し、PdMが全施策の優先順位を直感で決めるしかなくなります。KPIツリーを共通言語にすることで、「どの指標が一番ボトルネックか」を数字ベースで議論できるようになります。
よくある失敗・誤解
KPIツリーを作ろうとしたPdMがはまりやすい3つの罠を紹介します。
失敗1：ツリーが深すぎて管理できなくなる
「網羅的に分解しよう」と意気込むと、5〜6階層のツリーになり、追うKPIが30個以上になるケースがあります。これでは日常のモニタリングが破綻します。目安は3〜4階層、末端の指標（アクション指標）は1チームあたり3〜5個が限度です。最初はシンプルに作り、運用しながら補完する方が実用的です。
失敗2：分解に因果関係がない
「MRR = 新規MRR + 拡張MRR – チャーンMRR」のような数式的な分解（加法分解）は正しいですが、「MAU → タスク完了率 → サポート問い合わせ数」のような因果仮説に基づく分解は、その因果が実際に存在するかを検証しないまま使うと危険です。「仮説として設定した因果関係」と「データで確認した因果関係」を区別して管理する必要があります。
失敗3：ツリーを作って満足する
最も多い失敗です。丁寧なKPIツリーをドキュメントに書いたが、スプリントのバックログ選択時・施策のROI計算時・週次レビュー時にツリーを参照する習慣がないまま、3ヶ月後には「あのドキュメント何だっけ」となるケースです。KPIツリーは作ることではなく、使い続けることに価値があります。
KPIツリーの作り方：5ステップ
ここからが本題です。KPIツリーを実際に設計するための5ステップを解説します。
ステップ1：KGI（最終目標）を1つに絞る
まず頂点となるKGIを1つに決めます。「複数の最終目標がある」という場合は、KPIツリーを複数作るか、より上位の事業目標（例：売上）を1つのKGIにして、その下に複数のプロダクト指標をぶら下げます。
KGIの決め方で重要なのは「測定可能か」「時間軸を持つか」の2点です。「プロダクトを良くする」はKGIになれません。「2026年Q3末時点でMRRを1,500万円に到達させる」はKGIになれます。
SaaSプロダクトでよく使われるKGI候補は以下の通りです。
| KGI候補 | 適しているプロダクトフェーズ |
|---|---|
| MRR（月次経常収益） | スケール・グロースフェーズ |
| チャーン率 | 成熟・リテンション強化フェーズ |
| NPS（ネットプロモータースコア） | PMF（プロダクトマーケットフィット）検証フェーズ |
| アクティブユーザー数（WAU/MAU） | ユーザー数拡大フェーズ |
| トライアル→有料転換率 | 初期グロースフェーズ |
ステップ2：KGIをMECEに分解して中間KPIを定義する（レイヤー1）
KGIを「それを構成する中間指標に分解する」ステップです。ここではMECE（漏れなく・ダブりなく）を意識します。代表的な分解パターンは2つあります。
加法分解（数式的分解）：KGI = A + B + C という形で成立する分解です。MRR = 新規MRR + 拡張MRR – チャーンMRR は典型例です。数式として成立するため、分解の整合性を保証しやすい。
因果分解（仮説的分解）：「KGIを動かす主要な要因」を仮説ベースで列挙する分解です。例えば「アクティブユーザー数を規定する主要因は、新規獲得数・継続率・復帰率だ」という仮説を置く分解です。因果が正しいかどうかは後でデータを見て検証する必要があります。
中間KPIの数は2〜4個が適切です。この段階では因果の仮説を過度に細かくせず、大きな構成要素を捉えることを優先します。
ステップ3：各中間KPIをさらに分解して先行KPIとアクション指標を定義する（レイヤー2〜3）
中間KPIをさらに下に分解します。ここでのポイントは「現場がコントロールできる指標に到達するまで分解する」ことです。
例えば「チャーン率（中間KPI）」を分解する場合：
- チャーン率 → 90日以内の解約率と91日以降の解約率に分解
- 90日以内の解約率 → オンボーディング完了率（先行KPI）
- オンボーディング完了率 → 3日以内の初期設定完了率・7日以内のキーアクション到達率（アクション指標）
- 91日以降の解約率 → 機能定期利用率・サポート問い合わせ解決率（先行KPI）
- 90日以内の解約率 → オンボーディング完了率（先行KPI）
アクション指標まで分解できると、チームメンバーが「今週何をすれば数字が動くか」をKPIツリーを見ながら判断できるようになります。
ステップ4：各KPIにオーナー（責任者）とデータソースを割り当てる
KPIツリーが完成したら、各指標に対して「誰が責任を持って追うか」と「どこからデータを取るか」を決めます。これを省くと、モニタリングが誰の仕事かが曖昧になり、ツリーが使われなくなります。
| 指標 | オーナー | データソース | 更新頻度 |
|---|---|---|---|
| MRR | PdM | Stripe / 経理システム | 月次 |
| チャーン率 | PdM + CS | CRM（例: HubSpot） | 週次 |
| オンボーディング完了率 | PdM + デザイン | アクセス解析（例: Mixpanel） | 週次 |
| 3日以内の初期設定完了率 | エンジニアリング | プロダクト内ログ | 日次 |
ステップ5：因果仮説を検証し、ツリーを育てる
ツリーの初版は「仮説」の集合体です。リリースから数ヶ月後には「実際に因果がある指標とない指標」が見えてきます。この検証を意識的に行い、ツリーを更新することが重要です。
因果の検証方法として実務でよく使われるのは、以下の2つです。
相関分析：先行KPIとKGIの過去データを並べ、相関係数を見る。0.7以上の正相関が確認できれば因果仮説の信頼度が上がります。
ABテスト：先行KPIを意図的に変化させる施策を打ち、その前後でKGIの変化を比較する。最も信頼性の高い検証方法です。
具体例：SaaS Webサービスのチャーン削減KPIツリー
ここで具体例として、B2B SaaSプロダクトのチャーン削減をテーマにKPIツリーを組み立てます。
プロダクト概要：中小企業向けのプロジェクト管理SaaS。月額9,800円〜。トライアル期間14日、導入後3ヶ月以内の解約が多い課題を抱えている。
KGI：月次チャーン率を現状の4.2%から四半期内に2.5%以下に下げる
分解：なぜチャーンが起きるか（仮説）
- 導入初期にプロダクトの価値を実感できず解約する（早期チャーン）
- 一定期間使ったが、競合ツールに乗り換える（成熟チャーン）
上記の仮説に基づき、チャーン率を「導入90日以内チャーン率」と「91日以降チャーン率」に分解します。
[KGI] チャーン率 2.5%以下
├── [中間KPI-1] 導入90日以内チャーン率（目標: 6%以下）
│ ├── [先行KPI-1-1] オンボーディング完了率（目標: 70%以上）
│ │ ├── [アクション] 初回ログイン後3ステップ完了率
│ │ └── [アクション] チュートリアル動画視聴率
│ └── [先行KPI-1-2] 14日以内キーアクション実施率（目標: 50%以上）
│ ├── [アクション] 最初のプロジェクト作成率
│ └── [アクション] チームメンバー招待実施率
└── [中間KPI-2] 91日以降チャーン率（目標: 1.5%以下）
├── [先行KPI-2-1] 週間アクティブ率（目標: 65%以上）
│ ├── [アクション] 週次レポート機能利用率
│ └── [アクション] 通知クリック率
└── [先行KPI-2-2] NPS（目標: +30以上）
├── [アクション] サポートチケット解決時間（目標: 24時間以内）
└── [アクション] 新機能認知率このツリーがあることで、「今月チャーン率が改善していない」という事象に対し、「どの中間KPIが原因か → どの先行KPIが動いているか → どのアクション指標に手を打つか」という分析の流れが一本化されます。
実際の運用での会話例
Before（ツリーなし）：「先月のチャーン率が4.8%でした。引き続き改善に取り組みます」
After（ツリーあり）：「先月チャーン率が4.8%でした。内訳を見ると、90日以内チャーン率が8.1%と悪化しています。深掘りすると14日以内キーアクション実施率が38%（目標50%）と低く、最初のプロジェクト作成ステップで詰まっているユーザーが多いことが判明しました。今週のスプリントでは初期設定UIの改善を最優先とします」
KPIツリーを「生きた指標」にする運用・実践のコツ
コツ1：週次レビューのアジェンダにKPIツリーを組み込む
週次のプロダクトレビュー会議で、ツリーの最下層（アクション指標）から順番に読み上げる習慣を作ります。「前週比でどこが動いたか、動かなかったか」を確認し、上の階層への影響を議論します。この習慣が「ツリーを使う文化」を育てます。所要時間は10〜15分が適切で、深掘り分析は別途時間を取ります。
コツ2：スプリントプランニングでKPIツリーを参照する
新しいタスク・施策をバックログに追加する際、「これはツリーのどのアクション指標に寄与するか？」を必ず確認します。KPIツリーに紐づかないタスクは「ビジネス価値不明」として優先度を下げるか、ツリーに新しい指標として追加することを検討します。これにより、「感覚的な優先順位決め」から「指標ベースの優先順位決め」への移行ができます。
コツ3：四半期ごとにツリーを棚卸しする
プロダクトのフェーズが変わると、KGIも変わります。立ち上げ期はユーザー数、グロース期はMRR、成熟期はチャーン率とNPS、という具合に、注力すべき指標は変化します。四半期の節目に「ツリーの構造が今のフェーズに合っているか」を確認し、必要に応じてKGIを変更します。ただし頻繁に変えすぎると比較ができなくなるため、大きな事業転換がない限り1年単位を目安にKGIの変更は検討します。
コツ4：ツリーをチーム全員が見られる場所に置く
Notion、Confluence、Miro、Figjamなど、チームが日常的に使うツールに最新のKPIツリーを貼ります。「最新版はどこにあるか」が全員に伝わっていることが大切です。また、更新日時を明記し「このツリーはいつ時点の情報か」を明確にします。
コツ5：因果検証の結果をツリーにフィードバックする
「先行KPIが改善したのにKGIが動かなかった」というケースは、仮説の因果が成立していなかったことを意味します。このような検証結果を記録し、ツリーの構造を修正します。「使ったら改善する」サイクルを回すことで、ツリーはプロダクトの成長とともに精度が上がります。
FAQ
Q1. KPIツリーとピラミッドストラクチャーは何が違いますか？
ピラミッドストラクチャーは「主張を論理的に構造化する」コミュニケーションのフレームワークで、MECE原則に基づいて主張・根拠・データを整理するものです。KPIツリーは「プロダクトの指標を因果関係で構造化する」計測のフレームワークで、用途が異なります。ただし、ピラミッドストラクチャーの「漏れなく・ダブりなく分解する」考え方はKPIツリーの中間KPI設計にも応用できます。
Q2. スタートアップの初期フェーズでもKPIツリーは必要ですか？
PMF前の極初期段階では、KPIツリーを精緻に作ることよりも、ユーザーヒアリングと仮説検証に集中する方が優先度が高いです。ただし、「何を計測するか」は最低限決めておく必要があります。初期フェーズでは、KGI1つと先行KPI2〜3つ程度の「シンプルなツリー」で十分です。複雑なツリーは成長フェーズで段階的に拡張します。
Q3. チームメンバーがKPIツリーを理解してくれません。どうすれば良いですか？
最もよくある原因は「ツリーが複雑すぎる」か「自分ごと感がない」のどちらかです。対策として、まず各メンバーが担当する領域のアクション指標1〜2個だけを共有し、そのKPIが上位指標とどうつながるかを1対1で説明します。全体構造の理解は後回しで良いです。まず「自分の仕事がKGIにつながっている」という実感を持ってもらうことが先決です。
Q4. KPIツリーのためのおすすめツールはありますか？
専用ツールは不要で、手段よりも構造設計の質が重要です。実務でよく使われる選択肢を挙げると、Miro・Figjam（ホワイトボード系：ビジュアルで作るのに向いている）、Notion・Confluence（ドキュメント系：テキストとデータを一緒に管理したい場合）、Googleスプレッドシート（シンプルに表で管理したい場合）があります。重要なのはチーム全員がアクセスでき、更新が習慣化されることです。
まとめ
プロダクトマネージャーがKPIツリーを作る最大の目的は、「チームが毎日動かせる指標と、事業目標を1本の線でつなぐこと」です。KGIを頂点にして3〜4階層の因果構造を設計し、アクション指標まで分解することで、施策のROI議論・原因分析・スプリントプランニングがすべてKPIツリーを共通言語にして進むようになります。
ポイントを振り返ると、ツリーはシンプルに（最大4階層・末端指標は1チーム5個以内）、各KPIにオーナーとデータソースを割り当て、週次レビューとスプリントプランニングで使い続けることが重要です。そして四半期ごとに因果を検証し、ツリーを育てていくことが「生きたKPIツリー」の条件です。
KPIツリーはプロダクトが成長するほど価値が増します。まずはシンプルな構造から始め、チームとともに育てていきましょう。
プロダクト開発・DXについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や新人PdM育成、DX推進のサポートを承っています。 「何から始めればいいかわからない」という段階からでもお気軽にどうぞ。
