この記事の要約
HubSpotを導入していても、経営会議・マーケティング・営業でそれぞれ違う数字が出てきて、どれが正しいのか分からなくなる。この問題の正体は、ツールの不具合ではなく「作成日とクローズ日の混同」「ライフサイクルステージとディールステージの取り違え」といった定義の未合意です。
本記事では、数字がずれる典型的な原因を分解したうえで、経営・マーケ・営業それぞれが本当に見るべき指標を切り分け、その土台となる「共通定義」の作り方を整理します。さらに、全部門が参照できる「単一の真実」ダッシュボードの考え方と、明日から着手できるチェックリストも提示します。
読み終えたときには、自組織のレポートのどこに定義のズレが潜んでいるかを点検できる状態になっているはずです。
この記事でわかること
- HubSpotで部門ごとに数字がずれる典型的な原因（日付プロパティ、ステージ定義、タイムゾーンなど）
- 経営・マーケ・営業それぞれが本当に見るべき指標とその時間軸の違い
- 部門を横断するために最低限そろえるべき「共通定義」の4要素
- レポートガバナンス（定義の管理・変更承認）の設計の考え方
- 全社共通の「単一の真実」ダッシュボードの作り方と失敗パターン
はじめに
月次の経営会議で、マーケティングが報告した新規商談数と、営業が報告したパイプライン残高が微妙に噛み合わない。誰も嘘をついているわけではないのに、なぜか数字が合わない——こうした場面に心当たりはないでしょうか。HubSpot責任者やCROの立場にいると、この「数字のズレ」の説明責任を一手に引き受けることになりがちです。
原因を突き止めようとレポートを開いても、フィルター条件は一見どれも正しく見える。実はこの「どれも間違っていないのに合わない」という状態こそが、レポート設計の落とし穴なのです。
経営・マーケ・営業で数字がずれる、本当の理由
結論から言うと、HubSpotで部門ごとに数字がずれる原因のほとんどは、ツールの不具合ではなく「定義の未合意」です。同じ「商談数」という言葉を使っていても、経営は着地見込みの金額ベースで見ており、マーケはリード起点の件数で見ており、営業は自分の担当パイプラインで見ている。前提が違うまま同じ単語で会話しているので、数字が合わないのは当然の結果とも言えます。
経営会議の場で「先週報告された数字と今回のレポートで数百万円のズレがある」という指摘を受け、その場で原因を説明できずに終わった経験がある方も少なくないはずです。多くの場合、犯人はHubSpotそのものではなく、レポートを作った人がそれぞれ違う前提でフィルターを組んだこと自体にあります。ここを放置したまま新しいレポートを増やしても、ズレの種類が増えるだけで根本の解決にはつながりません。
「作成日」と「クローズ日」のズレ
もっとも多いのが、レポートのフィルター条件に使う日付プロパティの不一致です。例えば経営会議用のレポートは「クローズ日（Close Date）」を軸に今月の成約実績を見ているのに、マーケ側のレポートは「作成日（Create Date）」を軸にリード獲得数を見ている。この場合、月をまたいで成約した商談は片方にしかカウントされず、月次の合計を突き合わせると必ず差分が出ます。
ライフサイクルステージとディールステージの混同
もう一つの典型が、コンタクトのライフサイクルステージ（Lead、MQL、SQLなど）と、ディールのステージ（商談化、提案、クロージングなど）を混同したレポート設計です。マーケがMQL数を「ライフサイクルステージがMQLになった日」でカウントし、営業が商談化率を「ディールが作成された日」でカウントしていると、同じ案件でも起点となる日付が数日〜数週間ずれます。この差分が積み重なると、月末のレポートで見える数字は実態と乖離していきます。
「レポートが正しいのに合わない」というやっかいなケース
さらに厄介なのは、個々のレポート自体は設定として間違っていないのに、前提条件が違うために結果が食い違うケースです。例えば、マーケが「今月獲得したMQL」を集計する際に日本時間ではなくHubSpotアカウントのデフォルトタイムゾーン（UTCなど）で日付を切っていた場合、月初・月末の数件が翌月扱いになります。
一件二件の話に見えても、月次で経営に報告する数字としては無視できない誤差になります。こうした「設定は正しいが前提がズレている」パターンは、レポートを見ただけでは気づきにくく、複数部門の数字を突き合わせて初めて発覚することが多いのが実情です。
役割ごとに本当に必要なレポートを切り分ける
HubSpotのレポート設計で最初につまずくのは、「全員に同じダッシュボードを見せれば揃う」という発想です。実際には、経営・マーケ・営業では意思決定に使う時間軸も粒度もまったく異なります。ここを混ぜたまま一つのダッシュボードに詰め込むと、誰にとっても使いにくいレポートが出来上がります。
経営層が見るべき指標
経営が知りたいのは「このままいくと今期の着地はどうなるか」という予測に近い情報です。具体的には次のような指標が中心になります。
- 四半期・年度のKGI進捗（売上、パイプラインカバレッジ率）
- 商談ステージ別の滞留日数と失注率の推移
- チャネル別・ICP別の獲得効率の四半期比較
ここで大切なのは、細かいキャンペーン単位の数字を持ち込まないことです。経営レポートに情報を詰め込みすぎると、意思決定に必要な「傾向」が数字のノイズに埋もれてしまいます。
役割ごとの視点の違いを整理すると、次のようになります。
| 役割 | 主な関心事 | 中心となる時間軸 |
|---|---|---|
| 経営 | 今期の着地予測、投資対効果 | 四半期・年度 |
| マーケティング | チャネル別の獲得効率とファネル転換 | 月次 |
| 営業 | パイプラインの充足度と担当者別実績 | 週次・月次 |
こうして並べてみると、同じ「商談化率」という指標でも、経営は四半期トレンドとして俯瞰したいのに対し、営業は週次で自分ごととして追いたいという違いが見えてきます。この温度差を無視して一つのレポートに統合しようとすると、結局どちらの用途にも中途半端なものになりがちです。
マーケティングが見るべき指標
マーケティングは、リードの量と質、そしてチャネルごとの投資対効果を追う立場です。MQL数やCPL（リード獲得単価）はもちろんですが、それだけでは「量は出ているが質が悪い」という状態を見逃します。そこで重要になるのが、MQLからSQLへの転換率、そして商談化後の成約率までを一つのファネルとして追う設計です。
例えば、あるチャネルのMQL数は多いのに商談化率が極端に低い場合、そのチャネルの獲得基準（ICP適合度）を見直すべきサインです。マーケ単独のダッシュボードでリード数だけを追っていると、この兆候には気づけません。
営業が見るべき指標
営業にとっての関心事は、目の前のパイプラインが目標達成に足りているかどうかです。パイプラインカバレッジ率（目標に対して何倍の商談量があるか）、担当者別の商談化率、そして失注理由の分布が中心的な指標になります。
ここでよくあるのが、失注理由を「価格」「タイミング」といった大分類だけで記録し、後から分析できない状態にしていることです。失注理由をプロパティとして構造化しておかないと、営業レポートは「結果の記録」で終わり、次のアクションにつながる分析材料になりません。
また、担当者別の実績を見る際にも注意が必要です。異動やチーム再編があった場合、過去の実績を「現在の所属チーム」で再集計するのか、「当時の所属チーム」のまま残すのかによって、チーム単位の数字は大きく変わります。この扱いを決めずに運用していると、組織変更のたびに過去の実績比較ができなくなり、営業側から「前年同期比が信用できない」という不満が出やすくなります。
部門横断で定義と責任をそろえるRevOpsの考え方は、次の記事で整理しています。
共通定義という土台をどう作るか
役割ごとにレポートを分けると同時に、絶対に譲れないのが「共通定義」の存在です。これがないと、部門ごとのレポートは正しくても、部門をまたいで数字を比較した瞬間に矛盾が生まれます。
定義すべき4つの要素
共通定義として最低限そろえておきたいのは、次の4点です。
- 日付プロパティの使い分けルール：どのレポートでCreate Date、どのレポートでClose Dateを使うかを明文化する
- ライフサイクルステージとディールステージの対応表：どのステージがどのステージに対応するかを一覧化する
- 担当者・チームのプロパティ設計：異動や兼務があっても実績集計がぶれない構造にする
- 金額の丸め方と通貨換算ルール：多通貨案件がある場合は特に重要
これらは一度決めて終わりではなく、組織変更や新しいチャネル追加のたびに見直しが必要です。だからこそ、誰がこの定義を管理し、誰が変更を承認するのかという「レポートガバナンス」の設計が欠かせません。
多くの企業では、この役割をRevOpsやHubSpot管理者が兼務しています。ただし、マーケや営業の現場から見ると「自分たちの知らないところでレポートの定義が変わった」と感じる場面も出てきます。定義変更のたびに関係部門へ簡単なアナウンスを流すだけでも、後から「なぜこの数字が急に変わったのか」という混乱を防ぐことができます。ガバナンスは厳格なルールというより、変更を可視化する仕組みだと捉えるとうまく機能しやすくなります。
レポート定義書を持つ組織と持たない組織の差
実務でよく見かけるのが、レポート定義がHubSpotの設定画面の中にしか存在せず、ドキュメント化されていないケースです。この状態では、担当者が異動したり退職したりした瞬間に、なぜそのフィルター条件になっているのかが分からなくなります。
レポート定義書は、凝ったフォーマットである必要はありません。「このレポートは何のために存在し、どのプロパティをどう使っているか」を一枚のシートにまとめておくだけで、新しく担当になった人がゼロから調査する時間を大幅に削減できます。RevOpsやHubSpot責任者がこの定義書のオーナーになることで、部門間の解釈のズレを未然に防げます。
CRM・MA・BIの正本をどう分けるかは、次の記事を参照してください。
「単一の真実」ダッシュボードという考え方
役割ごとのレポートと共通定義の両方が揃ったら、最後に必要なのが、経営・マーケ・営業が共通で参照する「単一の真実（Single Source of Truth）」となるダッシュボードです。これは各部門の詳細レポートとは別に、全社共通の主要数値だけを載せた、いわば「基準点」の役割を果たします。
このダッシュボードに載せる指標は、あえて絞り込むべきです。目安として5〜7個程度に留め、それぞれの指標がどのプロパティ・どの日付条件で計算されているかを明記しておきます。会議の場でこのダッシュボードを起点に会話をすることで、「あなたの数字とは違う」という議論そのものを減らすことができます。
導入時によくある失敗パターン
単一の真実ダッシュボードを作る際、よくある失敗が「既存の各部門レポートをそのまま並べる」ことです。これでは定義の不一致がそのまま持ち込まれてしまい、根本解決になりません。まず共通定義を整理し、その定義に基づいて指標を再設計してから初めてダッシュボードに載せる、という順序を守ることが重要です。
今日から始められるチェックリスト
大掛かりな再設計に着手する前に、次の項目だけでも確認しておくと、数字のズレの多くは未然に防げます。
- 経営・マーケ・営業、それぞれのレポートで使っている日付プロパティを書き出し、一致しているか確認する
- ライフサイクルステージとディールステージの対応関係を一枚の表にまとめる
- 担当者・チームのプロパティが異動時にどう扱われるかのルールを明文化する
- 主要レポートについて「誰が定義変更を承認するか」を決めておく
- 全社ダッシュボードに載せる指標を5〜7個に絞り込む
一度にすべてを完璧にする必要はありません。まずは経営会議で使う数字だけでも共通定義を合わせるところから始めれば、部門間の不毛な数字合わせの時間は確実に減っていきます。
まとめ
HubSpotで部門間の数字が合わないのは、ツールの欠陥ではなく「日付プロパティ」「ステージ定義」「担当者集計ルール」といった前提の未合意が積み重なった結果です。経営・マーケ・営業はそれぞれ見るべき時間軸も指標も違うため、レポートを分けること自体は正しい判断です。
ただし、その前提として共通定義とガバナンスを整えておかなければ、分けたレポートが矛盾を増幅させます。共通定義を土台に、全社で参照する「単一の真実」ダッシュボードを一つ持つ——この順序を守ることが、数字を巡る不毛な議論から組織を解放する最短ルートです。
Q&A
- Q既存のレポートが多すぎて、どこから手をつければ良いか分かりませ。
- A
まずは経営会議で使われている主要レポートから着手するのがおすすめです。経営層が見る数字の定義を最初に固めることで、そこから逆算してマーケ・営業のレポートとの整合性を確認しやすくなります。全レポートを一斉に見直そうとすると作業が止まりやすいため、影響範囲の大きいものから順に着手する方が現実的です。
- Q部門ごとに定義が違うのは、そもそも組織構造や評価制度の問題ではないでしょうか?
- A
評価制度が数字の見方に影響することは確かにありますが、レポート設計上の定義のズレは評価制度とは切り離して解決できる問題です。まずはレポートの前提条件を揃えることに集中し、評価制度の議論は別のテーマとして扱う方が、実務上は前に進みやすくなります。
- Q共通定義を決めても、現場が守ってくれるか不安です。
- A
ルールを作るだけでなく、定義が変わった際に誰が承認し、どこで確認できるかという「見える化」が定着の鍵になります。定義書を作成した上で、変更履歴を関係者に簡単に共有する運用を続けることで、次第にレポートを作る際の共通言語として浸透していきます。
専門用語解説
- MQL（Marketing Qualified Lead）：マーケティング活動によって一定の基準を満たしたと判断された見込み客のこと
- SQL（Sales Qualified Lead）：営業がアプローチする価値があると判断した見込み客のこと
- ライフサイクルステージ：見込み客が購買プロセスのどの段階にいるかを示すHubSpotの分類項目のこと
- ディールステージ：商談が現在どの進捗段階にあるかを示す項目のこと
- CPL（Cost Per Lead）：一件のリードを獲得するためにかかった費用のこと
- パイプラインカバレッジ率：目標達成に対して現在の商談総額が何倍あるかを示す指標のこと
- ICP（Ideal Customer Profile）：自社にとって最も成果につながりやすい理想的な顧客像のこと
- RevOps（Revenue Operations）：マーケ・営業・カスタマーサクセスの業務基盤とデータを横断的に統括する機能のこと
- KGI（Key Goal Indicator）：組織が最終的に達成すべき目標を数値化した指標のこと
- Single Source of Truth（単一の真実）：組織全体が共通の判断基準として参照する、唯一の正しいデータ源のこと
