Revenue Data Flowとは何か
—— なぜ「数字がつながらない」のか

SalesforceとHubSpotの数字が違う。BIとも合わない。営業資料の数字も違う。そして最終的にExcelで調整している——これは日本のBtoB企業で非常によく起きています。SaaS導入が増え、CRMが増え、部門が分かれ、KPI管理が始まるタイミングで「どの数字を信じればいいのか分からない」問題が発生します。

多くの企業は「システム連携を強化しよう」と考えます。しかし問題はAPI連携不足ではありません。本当の原因は、Revenue Data Flowが設計されていないことにあります。

Revenue Data Flowとは何か

Revenue Data Flowとは、見込み客の発生から受注・請求・契約更新・追加受注に至るまでの収益データが「どこで生成され、どこへ流れ、どこで使われるか」を設計する考え方です。重要なのはデータの保存ではありません。収益を一貫して追えることが目的です。

多くの企業ではデータは存在しています。しかし、マーケティング・営業・カスタマーサクセス・財務がそれぞれ別のツールを使い、データがつながっていません。収益データが存在しても、収益の流れが設計されていなければ意思決定に使えません。

「数字が合わない」原因となる5つの構造問題

1. 正データの所在が決まっていない

   売上はSalesforce基準、顧客数はHubSpot基準、請求は会計システム基準——それぞれが別々の数字を持つと、部門ごとに異なる数字が出てきます。「どこが正しいか」を定義しない限り、統合しても数字は揃いません。

2. KPIの定義が部門ごとにずれている

   「SQL」「年間売上」「アクティブ顧客」「解約率」の定義が部門によって違うと、会議の冒頭で必ず「その数字の定義は？」という確認から始まります。議論の前提を揃えるためにKPI定義の統一が不可欠です。

3. 収益の流れが部門で分断されている

   マーケティングは見込み客獲得まで、営業は受注まで、カスタマーサクセスは契約後——それぞれが担当範囲だけを見ていると、収益全体の流れが誰にも見えなくなります。

4. Excelが「最終的な正」になっている

   BIもCRMもあるが最終的にExcelで補正が走る。この状態が続くと収益の可視性は維持できません。Excelによる補正は個人の知識に依存するため、担当者が変わると再現できなくなります。

5. データ責任者が存在しない

   KPI定義・収益データ・マスタデータを誰が管理するか不明な状態は典型的な問題です。データの責任範囲が曖昧なまま複数のツールを導入すると、定義の乱立が加速します。

「システム連携」だけでは解決しない

多くの会社は収益データの問題をAPI連携の問題として捉えます。しかし本当に必要なのは収益構造の設計です。SalesforceとHubSpotをつないでも、KPI定義・収益の流れ・データの責任者が曖昧なら数字は崩れます。問題は接続ではなく、Revenue Data Architecture（収益データ構造の設計）です。

ツールをつなぐ前に、収益データの流れと正データの所在を設計することが先決です。

本当に必要なのは「収益の可視化」

Revenue Visibility（収益可視性）とは、営業・マーケティング・カスタマーサクセス・財務を含めて「収益を一貫して追える状態」を指します。重要なのはダッシュボードの画面ではありません。どの施策が収益につながったか、どこで収益が失われたか、どこが詰まっているか——これが見えることが目的です。

収益データの流れを整えると何が変わるのか

Revenue Data Flowが整うと、会議で数字確認をしなくなります。経営判断が速くなり、見通し精度が改善し、KPI議論から改善議論へと会議の中身が変わります。マーケティング・営業・カスタマーサクセスがつながり、Excelへの依存が下がります。これらは個別のツール改善では実現せず、収益の流れを構造として設計することで初めて得られます。

Revenue Architecture という考え方

収益データの問題はシステムの問題ではありません。営業・マーケティング・カスタマーサクセス・CRM・KPI・データを「収益につながる一つの構造」として設計するRevenue Architectureの問題です。Revenue Architecture・Revenue Data Flow・RevOps・KPI設計・収益可視化という構造が整って初めて、数字は一貫してつながります。

日本企業で特に難しい理由

日本企業ではExcel文化・部門最適・属人運用・SaaSの乱立が根強く残っています。そのため収益データの流れが人力で補完されやすく、担当者の経験と記憶がシステムの代わりになっているケースが多い。必要なのは「収益が自然に流れる構造」であり、日本企業の組織文化に合ったRevenue Architectureの設計が求められます。

Consilegyの考え方

ConsilegyではCRM連携やBI構築を単なるシステム連携とは考えていません。本質はRevenue Architecture・Revenue Data Flow・RevOps・収益可視化・KPI設計にあります。Salesforce・HubSpot・Kintone・BI・Slack・会計システムを横断しながら、「収益が一貫して流れる構造」を設計します。目的はシステムを増やすことではなく、収益が自然につながる構造を作ることです。

まとめ：数字の問題はRevenue Data Flowの問題

「数字がつながらない」原因はAPI不足ではありません。Revenue Architecture不足・Revenue Data Flow未設計・KPI設計不足・RevOps未整備が本質的な原因です。だからこそ必要なのはシステムの追加ではなく、「収益が流れる構造」を設計することです。Revenue Data FlowはRevenue Architectureの中核であり、ここが整うことで初めて収益データは経営判断の武器になります。