プロダクトマネージャー（PdM）の仕事の中で、もっとも地味でありながら、もっとも成果を左右するのがKPI設計です。良いKPIを置けたチームは、施策の優先順位がブレず、議論が「好み」ではなく「数字」で進むようになります。逆にKPIが曖昧なチームは、四半期の終わりに「結局、何が良くなったのか」を説明できなくなります。
本記事では、PdMが現場で使えるKPI設計の手順を、よくある失敗パターンとあわせて整理します。KGI・OKRとの違いから、5ステップの設計フレームワーク、SaaSプロダクトを例にした具体例、そして「作ったKPIを死なせない」運用のコツまで、実務にそのまま使える形でまとめました。
KPIとKGI・OKRの違いを整理する
KPI設計の議論が空回りする最大の原因は、KGI・KPI・OKRという似た言葉の役割が整理されていないことです。
KGI（Key Goal Indicator）は「最終的に達成したい事業目標」そのものです。たとえば「年間契約継続率を95%にする」「ARRを30%成長させる」といった、経営が追いかける数字がKGIにあたります。
KPI（Key Performance Indicator）は、KGIを達成するための「先行指標」です。KGIは結果が出るまでに時間がかかるため、もっと早いタイミングで進捗を把握できる指標としてKPIを設定します。良いKPIは、KGIと因果関係があり、KPIが改善すればKGIも追随して改善するという関係が成立している必要があります。
OKR（Objectives and Key Results）は、KGI・KPIとは少し別の文脈で、組織全体の「目標管理の仕組み」です。Objective（目標）に対してKey Results（主要な成果指標）を紐づける点はKPIと似ていますが、OKRは四半期ごとに見直す前提で運用され、達成率70%程度でも「ストレッチな目標だった」と評価される点が特徴です。KPIは継続的に追いかける運用指標、OKRは一定期間のチャレンジ目標、と役割を分けて理解すると混乱が減ります。
PdMの実務では、経営が決めたKGIを受け取り、それをプロダクトチームが日々の意思決定に使えるKPIへ「翻訳」する役割を担います。この翻訳の精度が、KPI設計の質を決めます。
PdMがKPI設計で失敗しがちな3つのパターン
KPI設計でよく見る失敗には、共通したパターンがあります。
1つ目は、追いやすい指標を追ってしまうパターンです。 DAU（日次アクティブユーザー数）やPV数のように取得が簡単な指標は、つい主役のKPIに据えられがちです。しかし、それが事業目標と因果関係を持つかを検証しないまま運用すると、「数字は伸びているのに事業は伸びていない」という状態に陥ります。
2つ目は、KPIの数が多すぎるパターンです。 ダッシュボードに20個の指標が並んでいるチームをよく見かけますが、人間が同時に意識して動かせる指標は実質3〜5個程度です。指標が多いほど「結局どれを見ればいいのか」が曖昧になり、現場の意思決定に使われなくなります。
3つ目は、KPIを決めた後の運用設計をしていないパターンです。 KPIを設定するワークショップは盛り上がっても、その後「誰が」「いつ」「どの会議で」その数字を確認し、悪化したときに「誰が」次のアクションを決めるのかが決まっていないケースが非常に多いです。KPIは作った瞬間に終わりではなく、運用に乗せて初めて機能します。
KPI設計5ステップ（実践フレームワーク）
ここからは、上記の失敗を避けながらKPIを設計するための、再現性のある5ステップを紹介します。
ステップ1：事業目標（KGI）を言語化する
最初のステップは、KPIではなく、その上位にあるKGIを言葉にすることです。「売上を伸ばす」のような抽象的な表現ではなく、「今期、有料プラン継続率を92%から95%に上げる」のように、期間・対象・数値を含む形で言語化します。ここが曖昧なまま次のステップに進むと、後のすべての指標が的外れになります。
ステップ2：ユーザー指標・ビジネス指標・プロダクト指標に分解する
KGIが決まったら、それに影響を与える要素を3つの軸に分解します。
- ユーザー指標：ユーザーがプロダクトのどの体験で価値を感じているか（例：オンボーディング完了率、主要機能の利用率）
- ビジネス指標：事業として収益・コストにどう影響するか（例：解約率、アップセル率、CAC）
- プロダクト指標：プロダクトの健全性そのもの（例：障害発生率、ページ表示速度）
この3軸で分解すると、「ユーザー体験は良くなっているが、収益化につながっていない」のような、単一指標では見えないギャップが発見しやすくなります。
ステップ3：KPIツリーで因果関係を可視化する
分解した指標を、KGIを頂点にしたツリー構造に並べ、矢印で因果関係をつなぎます。これがKPIツリーです。下の図のように、KGIから逆算して「どの指標が動けば、上位の指標が動くのか」を1枚の図にまとめると、チーム内で指標の優先順位について合意を取りやすくなります。
KPIツリーを作る際のポイントは、矢印でつないだ指標同士の関係を「本当に因果関係があるか」「相関で止まっていないか」を一つひとつ問い直すことです。データが取れたら、可能な範囲で相関分析や過去データの検証を行い、仮説のままになっているKPIには「検証中」のラベルを付けておくと、後から見直しやすくなります。
ステップ4：North Star Metricを決める
KPIツリーの中から、チーム全員が常に意識すべき「North Star Metric（北極星指標）」を1つ選びます。North Star Metricは、ユーザーへの価値提供と事業成長の両方を反映する指標であることが理想です。たとえばSlackであれば「チームが送信したメッセージ数」、Airbnbであれば「予約された宿泊数」のように、ユーザー価値と事業成果が重なる地点を指標化します。
PdMはこのNorth Star Metricを、施策の優先順位付けやロードマップ設計の基準として使います。新機能の提案が出たときに「これはNorth Star Metricにどう影響するか」を問うだけで、議論の軸がぶれにくくなります。
ステップ5：ダッシュボード化して定例で追う運用に落とす
最後のステップは、決めたKPIを実際に「見る仕組み」に落とし込むことです。BIツールやスプレッドシートでダッシュボードを作り、週次・月次の定例ミーティングで確認する時間を固定化します。このとき、各KPIに対して「閾値を下回ったら誰が動くか」をあらかじめ決めておくと、数字が悪化した際の対応スピードが大きく変わります。
具体例：SaaSプロダクトのKPI設計サンプル
イメージをつかみやすくするため、BtoB SaaSプロダクトを例にKPI設計の流れを示します。
KGIを「年間継続率（NRR）を110%にする」と設定した場合、KPIツリーは次のように分解できます。
| 階層 | 指標例 | 役割 |
|---|---|---|
| KGI | 年間継続率（NRR）110% | 経営が追う最終目標 |
| KPI（ビジネス） | 解約率、アップセル率 | NRRに直結する事業指標 |
| KPI（ユーザー） | 主要機能の週次利用率、オンボーディング完了率 | 解約率に先行する体験指標 |
| KPI（プロダクト） | 主要機能のエラー率、平均応答速度 | 利用率に影響するプロダクト健全性指標 |
このケースでは、North Star Metricを「主要機能の週次利用率」に設定することが考えられます。利用率が高いユーザーほど解約しにくく、アップセルにもつながりやすいというデータが過去にあるなら、利用率を上げる施策に集中することが、結果的にNRRの改善につながるという仮説が成立します。
PdMはこの仮説をもとに、ロードマップ上の機能開発に優先順位をつけ、施策実施後は利用率の変化と解約率の変化を継続的にモニタリングして、仮説の検証と更新を繰り返していきます。
KPI運用を定着させるための3つのコツ
KPIを設計しても、運用が続かなければ意味がありません。定着させるための実践的なコツを3つ紹介します。
1. KPIの数を絞る。 ダッシュボードの主役は3〜5個までにし、それ以外は「参考指標」として別枠に置きます。
2. KPIの「持ち主」を決める。 指標ごとに責任者を明確にすることで、数字が悪化したときに誰が動くべきかが即座にわかるようになります。
3. 定期的にKPIそのものを見直す。 プロダクトのステージが変わればKPIも変わります。半期に一度は「このKPIは今もKGIと因果関係があるか」を問い直す機会を設けましょう。
AI時代のKPI設計で気をつけたいポイント
2026年現在、AI機能をプロダクトに組み込むケースが急増しており、KPI設計にも新しい論点が増えています。
まず、「AI機能の利用率」を単独のKPIとして扱うのは避けるべきです。AI機能を使った回数が増えても、それがユーザーの本来の課題解決やビジネス成果につながっていなければ、ステップ1で言語化したKGIとの因果関係が崩れてしまいます。AI機能についても、必ず既存のKPIツリーの中に位置づけ、「この機能の利用が、どのユーザー指標・ビジネス指標を動かすのか」を明示してから計測を始めることが重要です。
また、AI機能はユーザーの期待値とのギャップが大きくなりやすい領域でもあります。利用率に加えて、「AIの提案を実際に採用した割合」や「AIへの再質問・修正の発生率」のような、品質を示す補助指標をセットで持っておくと、利用率だけでは見えない問題（使われているが満足度は低い、など）を早期に検知できます。
よくある質問（FAQ）
Q1. KPIはどのくらいの頻度で見直すべきですか？
プロダクトの成長フェーズによりますが、一般的には四半期に一度、KGIとKPIの因果関係が崩れていないかを点検するのが目安です。大きな機能リリースやピボットがあった場合は、その都度KPIツリー全体を見直すことをおすすめします。
Q2. KPIとOKRのKey Resultsは同じものとして扱ってよいですか？
役割が異なるため、完全に一致させる必要はありません。KPIは継続的に運用する定常指標であるのに対し、OKRのKey Resultsは一定期間のチャレンジ目標です。ただしKey Resultsの達成度を測る際に、既存のKPIを流用するケースは多く、両者を完全に分離する必要はありません。重要なのは、それぞれの指標が「何のために存在するのか」をチームが理解していることです。
Q3. KPIツリーを作る際、どのチームを巻き込むべきですか？
PdM単独で作成すると、ビジネス側・開発側の実情と合わない指標になりがちです。営業・カスタマーサクセス・エンジニアリングの代表者を最低限交え、特に「データが実際に取得可能か」をエンジニアリング側に早い段階で確認しておくと、後工程での手戻りを防げます。
Q4. 小規模なチームでも5ステップすべてを実施すべきですか？
人数が少ないチームほど、フルセットのKPIツリーを作る時間的コストが負担になりがちです。その場合は、ステップ1（KGIの言語化）とステップ4（North Star Metricの決定）だけを先に固め、ステップ2・3のツリー化は四半期に一度のタイミングでまとめて整理する、という簡易運用でも十分に効果があります。
まとめ
KPI設計は、KGIを言語化し、ユーザー・ビジネス・プロダクトの3軸で分解し、KPIツリーで因果関係を可視化し、North Star Metricを定め、運用に落とし込むという5ステップで進めることで、再現性のあるプロセスになります。重要なのは、KPIを「作ること」ではなく「使われる状態にすること」です。指標の数を絞り、持ち主を決め、定期的に見直す仕組みまでセットで設計することで、KPIはチームの意思決定を支える本当の武器になります。
AIプロダクトの台頭で扱う指標も複雑化していますが、KGIからKPIへの「翻訳」という基本のプロセスは変わりません。まずは自社プロダクトのKGIを1行で言語化するところから始めてみてください。
プロダクト開発・DXについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や新人PdM育成、DX推進のサポートを承っています。
「何から始めればいいかわからない」という段階からでもお気軽にどうぞ。
