収益指標・RevOpsガイド
部門ごとに違う指標で成果を語っていると、KPIツリーを組んでも共通言語になりません。ここでは継続収益型のビジネスを中心に広く使われる指標群と、部門横断でそれらを統合する「RevOps」という考え方を整理します。単発売り切り型のビジネスでも、LTV・CACなど多くの指標は応用できます。
代表的な収益指標
健全性の目安ラインに対する到達度(バーは各指標の一般的な上限目安に対する比率)
110%超が優良の目安
40%以上が健全の目安
3倍以上が健全性の目安
- NRR / GRR
- 既存顧客の売上維持・拡大率。NRR 110%超が優良の目安とされる
- Rule of 40
- 成長率+利益率が40%以上であれば健全とされる経験則
- Magic Number
- セールス・マーケティング投資に対する新規ARRの効率性指標
- LTV / CAC
- LTV/CAC比が3倍以上、CAC回収期間が12〜18ヶ月以内が健全性の目安
ノーススターメトリック(NSM)
顧客価値と事業成長を同時に代表する単一の指標です(例:Slackの「週間送信メッセージ数」)。NSMを頂点に、それを構成する入力指標(KPIツリー)を組むことで、部門横断のGTM目標を1つに統一できます。
AARRR(海賊指標)
Acquisition/Activation/Retention/Referral/Revenueの5段階でグロースを計測するフレームです。特にPLG(プロダクト主導成長)・コンシューマ寄りのプロダクトのKPI体系としてよく使われます。
RevOps(Revenue Operations)という考え方
マーケティング・営業・カスタマーサクセスのオペレーション・データ・ツールを統合管理する組織思想です。ファネル全体のボトルネック解消を担い、SFA/MAの設計思想や、部門間のデータ分断解消の拠り所になります。「GTMエンジニアリングの3層モデル」の自己診断が扱う「部門横断で意思決定できない」という詰まりは、まさにRevOpsが対処しようとしている課題そのものです。
自分で組むKPIツリーの作り方
ノーススターメトリックを頂点に、部門ごとの指標をツリー状に分解する作業は、次の3手順で進められます。ここでは架空のB2B SaaS企業(従業員80名、部門はマーケ・営業・CS・プロダクトの4つ)を例に、実際にどう考えて手を動かすかを追ってみます。数字はすべて説明用の仮の値です。
部門をまたいで語れる単一の目標を頂点に置く
頂点の目標に効く指標を部門別に列挙する
指標同士が上流・下流でつながっているかを確認する
STEP1|全社目標を1つに決める:候補をどう比較するか
この架空企業では「新規ARR」「NRR」「アクティブ利用率」の3つが頂点候補に挙がったとします。3つとも「良い指標」に見えますが、頂点に置けるのは1つだけです。判断基準は次の2つ。
- ① 全部門の活動が、その指標に矢印でつながるか
- 「新規ARR」はマーケ・営業には直結するが、CSの日々の活動(オンボーディング、解約対応)はほぼ影響しない。「NRR」なら新規(営業)・拡大(CS/営業)・解約防止(CS)のすべてが矢印でつながる
- ② 今の経営課題に対して、動かすべき指標か
- この企業は直近で新規契約は伸びているが解約が多い、という課題を抱えている想定。だとすれば「新規ARR」を頂点にすると伸びている数字をさらに追う設計になり、本当の課題(解約)が霞む
この2軸で見ると、この架空企業では「NRR」を頂点に置くのが妥当という結論になります。**頂点の選定を間違えると、ツリー全体が「経営課題とズレた数字を追う構造」になる**のが、このステップ最大のリスクです。
STEP2|部門ごとの指標を洗い出す:出てきた候補をどう絞るか
各部門にヒアリングすると、普段見ている指標が大量に出てきます(この架空企業では合計20個以上)。全部をツリーに載せると機能しないため、「NRRの計算式のどの項に効くか」で機械的にふるいにかけます。NRR =(期首ARR+拡大-解約-ダウングレード)÷期首ARRなので、各部門の指標をこの4項目のどこに紐づくかで仕分けます。
| 部門 | 出てきた指標(例) | NRRのどの項に効くか | 採用/観察指標 |
|---|---|---|---|
| 記入例CS | 記入例オンボーディング完了率 | 記入例解約の先行指標(直接は非採用) | 記入例観察指標として別枠管理 |
「オンボーディング完了率」のように、NRRに直結はしないが先行指標として重要な数字は、**ツリー本体には入れず「観察指標」として別枠で持っておく**のが実務的です。無理にツリーに押し込むと因果関係が曖昧な矢印だらけになります。
STEP3|因果連鎖を確認する:矢印がつながらない指標をどう扱うか
指標同士を実際に矢印で結んでみると、必ず「どちらの項にも綺麗には収まらない」指標が残ります(この架空企業では「営業担当者の商談化率」がマーケ側の指標ともCS側の指標とも微妙に重なっていた、という想定)。ここでの裁定ルールは以下の3つです。
- ルール1:矢印を無理に引かない
- 「関係がありそう」なだけで矢印を引くと、後から見た人が因果関係を誤読する。直接の計算式でつながる場合のみ矢印を引く
- ルール2:どちらの部門にも中途半端に効く指標は、主担当部門を1つに決める
- 両論併記すると誰も責任を持たなくなる。「今回は営業側の指標として扱う。理由:架電〜商談化までの一連の流れの中で営業側の裁量が最も大きいため」のように、決めた理由を残す
- ルール3:3ヶ月動かしてみて、実際に他の指標と連動しなかった指標はツリーから外す
- 机上の因果連鎖は仮説にすぎない。運用しながら検証し、連動が確認できなければ観察指標に格下げする(このKPIツリー自体を作って終わりにしない、というのが継続モジュールとして提供する理由)
そのままコピーして埋められるKPIツリーの記入フォーマットです。
| 指標名 | 担当部門 | 現在値 | 目標値 | 誰が見るか | 詰まった場合のアクション |
|---|---|---|---|---|---|
| 記入例MQL数 | 記入例マーケ | 記入例120件/月 | 記入例180件/月 | 記入例マーケリーダー | 記入例獲得チャネル別に配分を見直す |
さらに各指標について「誰が見るか」「なぜ見るか」「詰まった場合にどう意思決定するか」「どんなアクションにつなげるか」まで1行で書き添えておくと、ツリーが単なる集計表ではなく、意思決定の道具として機能します。
メトリクス辞書(指標定義集)の作り方
KPIツリーを組んだ後、各指標について「どのシステムのデータか」「どれくらいの頻度で更新されるか」「何を意味するか」を1箇所にまとめておくと、部門をまたいだ共通言語として機能し続けます。これは本物のリアルタイム同期ではなく、同期の前提となる定義の一元化のフェーズです。
ここで見落とされがちなのが、指標ごとにデータの確度が違うという点です。同じ表の中に「システムから直接取れる実測値」と「代理指標での推定」が混在したまま並んでいると、精度の低い指標を精度の高い指標と同じ確信度で意思決定に使ってしまう事故が起きます。指標定義集には必ず確度の列を設けてください。
| 指標名・単位 | データソース | 更新頻度 | 定義(計算式レベル) | データ確度 |
|---|---|---|---|---|
| 記入例商談化率(%) | 記入例Salesforce | 記入例日次 | 記入例当月MQL数のうち、当月中に商談化したものの割合 | 記入例実測(Salesforceから直接算出) |
確度の目安:①実測(システムから直接算出)②代理指標(本来知りたい値が直接測れず、近い値で代用)③推定(担当者のヒアリング・経験則)。②③の指標は、意思決定の重み付けを下げるか、確度を上げる改善計画をセットで残しておきます。
先ほどの架空企業の例で言うと、「解約率」は契約解除データから実測できますが、その先行指標として使いたい「顧客満足度」は四半期アンケートの回答率が6割程度しかない、という想定なら、これは②代理指標にあたります。もしこの企業がアンケートの数字を実測データと同じ確信度で経営会議に出していたとしたら、それは「本当に測りたいのは満足度全体だが、実際に測れているのは回答した6割の満足度」というズレを隠したまま意思決定していたということになります。確度の列を分けておくだけで、この種の事故は防げます。
指標をツリーのどこに置くか(優先順位マトリクス)
指標を並べただけでは優先順位が付きません。「経営判断への影響度」×「今どれだけ変動が大きいか(放置コストの高さ)」の2軸マトリクスで、KPIツリーのどの階層に置くか、どれだけの頻度でレビューするかを機械的に決めます。先ほどの架空企業(NRRを頂点に置き、解約が課題)の指標で、実際に4象限に振り分けてみます。
| 象限 | 該当する指標(架空企業の例) | ツリー上の扱い | レビュー頻度 |
|---|---|---|---|
| 記入例影響度:大/変動:大 | 記入例解約率、拡大MRR | 記入例ツリー最上位(経営会議で毎回見る) | 記入例週次 |
影響度は高いが変動が小さい指標は、頻度を落として月次確認に回してよい指標です。逆に影響度が小さい指標をツリー上位に置いてしまうと、経営会議の時間が枝葉の数字に奪われます。この判定を最初にやらずに指標を並べると、後から「結局どれを見ればいいのか分からない」状態に戻ります。
指標定義が部門間で割れたときの裁定ルール
「エンゲージメントスコア」のような言葉は部門ごとに定義が食い違いがちです。話し合いで毎回すり合わせるのではなく、あらかじめ裁定ルールを決めておくと、定義を巡る不毛な議論を減らせます。
- ルール1:契約・請求に紐づく定義を優先する
- 解約率のように契約データと直結する指標は、経理・契約データ側の定義を正とする(現場感覚の定義は参考値に格下げ)
- ルール2:最終的な意思決定者に近い部門の定義を優先する
- 経営会議で報告に使う指標は、報告を受ける側(経営陣)が普段使っている定義に揃える。作る側の都合を優先しない
- ルール3:どちらの定義にも与しない場合は、両方を残し名前を分ける
- 無理に1つに統一せず「商談化率(マーケ基準)」「商談化率(営業基準)」のように名前ごと分けて辞書に併記する。これも実務ではよくある妥当な決着
架空企業の例で言うと、「エンゲージメントスコア」を営業は「直近30日の商談化率」の意味で、CSは「直近30日のログイン頻度」の意味で使っていた、というケースを考えます。契約解除には直結しない(ルール1は使えない)指標なので、次はルール2を検討します。この数字を最終的に見て意思決定するのは誰かと言えば、解約防止の打ち手を決めるCSリーダーです。したがって「エンゲージメントスコア=ログイン頻度」をCSの定義として正式採用し、営業側の「直近30日の商談化率」は辞書上「商談化率」と改名して別項目にする、という決着になります。
指標定義が壊れていないか、何で確かめるか
メトリクス辞書は作って終わりではありません。集計ロジックが変わっても指標名が同じままだと、誰も気づかないうちにトレンドの意味が変わってしまいます(定義ドリフト)。以下を定点観測すると早期に気づけます。
- 指標①:定義変更のログが残っているか
- 計算式・データソースを変えたら辞書に変更履歴を残すルールがあるか。無ければ、いつの間にか定義が変わっていても誰も気づけない
- 指標②:同じ指標名を複数部門が独自集計していないか
- 「エンゲージメントスコア」を営業とCSがそれぞれ別のスプレッドシートで別の計算式で出していないか。四半期に一度、名寄せチェックをする
- 指標③:代理指標で運用している項目が、実測に置き換わる見込みがあるか
- 「データ確度」列が②③のままの指標が半年以上放置されていないか。放置コストが高い指標から優先的に実測化する
架空企業の例で続けると、裁定ルールでCS側に一本化した「エンゲージメントスコア(=ログイン頻度)」の集計方法を、半年後にCSチームが「アクティブ判定の閾値」を現場判断でこっそり変えていた、というのが典型的な定義ドリフトです。指標①(変更ログ)が運用されていれば、この変更はすぐ辞書に記録され、他部門にも共有されます。運用されていなければ、経営会議で見ているグラフの意味がある月を境に変わっているのに、誰も気づかないまま数字だけを追い続けることになります。
コホート分析 / RFM分析
コホート分析は獲得時期別に顧客行動を追跡する手法、RFM分析はRecency(直近性)・Frequency(頻度)・Monetary(金額)で顧客をランク分けする手法です。どちらもリテンション改善や既存顧客への打ち手の優先順位づけに使われます。
例えば、月次でNRRが徐々に下がってきたとき、全社平均だけを見ていても原因はわかりません。コホート分析で「契約から6ヶ月以内に解約する顧客が特定の獲得チャネルに偏っている」ことが分かれば、そのチャネルのオンボーディング設計を優先的に見直す、といった打ち手につながります。
実際に使う:ARR純増イシューマトリクス
ここまでの考え方をARR成長の分解にそのまま当てはめたのが「ARR純増イシューマトリクス」です。ARR純増を新規・拡大・縮小・解約に分解し、各軸の必要値(目標)と実測値のギャップから、着手すべきイシューを機械的に絞り込みます。
考え方の詳細を見る →よくある質問
- NRRとGRRはどちらを重視すべきですか
- 両方を併せて見るのが一般的です。NRRはアップセル・クロスセルを含む拡大率、GRRは純粋な解約・ダウングレードの影響のみを見る指標です。NRRだけが高くGRRが低い場合、一部の大口顧客の拡大が解約の多さを覆い隠している可能性があります
- Rule of 40はアーリーステージのスタートアップにも当てはまりますか
- 成長率と利益率の合計が40%以上という経験則は、主に一定規模に達した継続収益型ビジネスの健全性評価に使われる指標です。赤字が前提のアーリーステージでは、この基準をそのまま適用するより、成長率・バーンレート・ランウェイを別途重視するのが実務的です
- ノーススターメトリックはKPIツリーの頂点にどう組み込めばいいですか
- 顧客価値と事業成長を同時に代表する単一指標を頂点に置き、それを構成する入力指標(獲得数、活性化率、継続率など)をツリー状に分解します。部門ごとに違う指標で成果を語っている状態を防ぐための共通言語として機能します