SaaS企業のKPI統合 — 意思決定が3倍速くなった設計の全容

「経営会議の最初の30分が、毎回"どの数字が正しいか"の議論で消えるんです」

従業員350名規模のB2B SaaS企業のCEOから聞いた、最初の一言がこれでした。

私がPMとしてこのプロジェクトを担当することになったとき、正直に言えば「KPIの定義を揃えてダッシュボードを整備すれば解決するだろう」と思っていました。実際に現場を見るまでは。

最初のヒアリングで見えた景色

初回のヒアリングで、営業部長、経理部長、経営企画マネージャーの3名に個別に「御社の"売上"はどう定義されていますか」と聞きました。3名とも、間を置かず答えてくれました。そして、3つの回答は全て違いました。

• 営業部長: 「受注確定日ベースの金額」
• 経理部長: 「入金確認日ベースの金額」
• 経営企画: 「契約開始日ベースのARR換算」

どれも「間違い」ではありません。それぞれの部門にとっては合理的な定義です。しかし、この3つが同じ会議テーブルに並んだとき、「先月の売上は上がったのか下がったのか」すら合意できない状態になります。

経営企画のマネージャーが苦笑いしながら言った言葉が印象に残っています。「毎月、3つのExcelを突き合わせて"正解の売上"を作るのが私の最初の仕事なんです。月に2日かかります。」

この時点で、私は当初の「ダッシュボードを整備すれば解決する」という見立てが甘かったことに気づきました。

問題はツールではなく、もっと手前にあった

BIコンサルやデータ分析会社であれば、おそらく「データウェアハウスを構築し、KPIダッシュボードを作りましょう」と提案するでしょう。技術的にはそれで「見える化」は実現できます。

しかし、KPIの定義が3つある状態でダッシュボードを作っても、「どの定義で集計するか」の議論が先送りされるだけです。ツールを入れてもデータの定義が統一されなければ、3ヶ月後にExcelに戻る。私たちが他のプロジェクトでも見てきたパターンです。

私たちのアプローチは違いました。ツールの選定やダッシュボードの設計に入る前に、まず「データの定義を統一し、どのデータが誰のどんな判断を支えるかの導線を設計する」——この工程をDiscoveryとして4週間かけて行いました。

具体的に言えば、この企業のダッシュボードが使われなかった理由は明快でした。経営企画が「念のため」で全指標を並べた結果、30以上のグラフが並ぶダッシュボードができていた。どのグラフが、誰の、どの判断を支えるかが定義されていない。結果として、誰にとっても「自分のための画面」ではなくなっていました。

4週間のDiscoveryで起きたこと

第1-2週: データの「定義」を統一する

CEO、営業部長、CS責任者、経理部長、経営企画マネージャーの5名とのヒアリングを経て、データ×意思決定×業務の対応関係を1枚のMeaning Mapに整理しました。

このプロセスで想定外だったのは、CS責任者の反応でした。KPI定義の統一会議で、「チャーンレート」を「月初ARRに対する当月解約ARRの比率」に統一すると提案した際、CS責任者が「それだと、私たちが日々追っている"解約リスクの兆候"が見えなくなるんですが」と声を上げたのです。

もっともな懸念でした。全社KPIの統一は重要ですが、現場の判断を支える指標を消してしまっては逆効果です。最終的な落としどころは、「チャーンレート」は経営KPIとして統一定義を採用し、CSチームが使っていたチケットベースの指標は「解約リスクスコア」として独立させる、という二段構成にしたことです。

この合意は、CEOが会議に出席し「今後はこの定義で行く」と宣言したことで成立しました。KPI定義の統一は技術判断ではなく経営判断です。

第3-4週: データ導線の再設計とロードマップ策定

統一されたKPI定義に基づき、「プロダクトライン別の月次MRR推移」——経営層が最も見たかった切り口——から逆算してデータの集計構造を設計しました。30以上のグラフが並んでいたダッシュボードは、「経営会議用」「営業レビュー用」「CSモニタリング用」の3つに分離し、それぞれの利用者と判断シーンを明示しました。

北極星KPIとして「経営会議における意思決定開始までの時間」を設定。ベースラインは30分。

Deliveryで何を作ったか

Discovery完了後、3ヶ月のDeliveryフェーズに入りました。

• 集計データベース: クラウド上にデータウェアハウスを構築。Salesforce、Zendesk、会計システムの3ソースからのデータパイプラインを自動化（日次ETL）
• ダッシュボード: 3つの役割別ダッシュボードを構築。経営会議用には「MRR推移」「チャーンレート」「新規ARR」の3指標に絞り込んだ
• アラート基盤: CS用の「解約リスクスコア」がしきい値を超えた場合に自動通知する仕組み

導入時にも一つ想定外がありました。ダッシュボードの初期運用で、営業部長から「受注ベースの数字も一覧で見たい」というリクエストが来たのです。全社KPIは契約開始日ベースに統一しましたが、営業の日常業務では受注日ベースの速報が必要でした。これは設計漏れでした。「ドリルダウン表示」として受注日ベースを副次表示する機能を追加し、統一KPIを崩さずに営業の実務ニーズにも対応しました。

成果 — Delivery完了3ヶ月後の定量計測

以下は、Delivery完了3ヶ月後（導入から3ヶ月経過時点）に、月次経営会議4回分の平均値として計測した結果です。

CEOの言葉:「会議の雰囲気が変わった。"数字が合っているか"ではなく、"この数字をどう改善するか"から始まるようになった。」

このプロジェクトがうまくいった条件

このプロジェクトには、うまくいくための条件が揃っていました。これがなければ同じ結果にはならなかったと思います。

• CEOがDiscoveryに参加した。 定義の統一は経営判断。現場だけでは合意が取れない
• データ自体は存在していた。 データ整備から始めるなら期間とコストは倍以上になる
• 部門間の関係が対立的ではなかった。 CS責任者の懸念にも「二段構成」で応えられた背景に、協力的な文化があった

逆に、以下のケースでは同じアプローチは機能しにくいと考えています:

• 意思決定者がプロジェクトに参加できない組織
• データの整備（収集・クレンジング）から始める必要がある場合
• 部門間の政治的対立が深刻な場合

あなたの組織でも確認してみてください

以下のうち、2つ以上に該当するなら、ツールを追加する前にデータの定義と判断基準の導線を見直す価値があるかもしれません。

• 経営会議で「数字の正しさ」の確認に10分以上かかる
• 同じKPIの定義が、部門によって異なる（または定義自体がドキュメント化されていない）
• BIツールやダッシュボードを導入したが、日常的に見ている人が限られている

30分かけて"正しい数字"を探す会議は、定義さえ揃えば5分で終わります。問題はデータの量ではなく、定義と導線にあります。