正本を決めるプロジェクトは、まずどこから着手すればよいですか?

全指標を一度に整理しようとすると必ず頓挫するため、役員会議や月次報告で頻繁に食い違いが指摘される指標を一つ選び、そのデータフローを可視化するところから始めることをおすすめします。

正本を一度決めたら、その後は見直さなくてよいのですか?

見直しは必要です。事業拡大や新規ツール導入、組織変更のタイミングでデータの発生源自体が変わることがあるため、定期的に正本マップを棚卸しする機会を設けるべきです。

小規模なチームでも、ここまで厳密な設計は必要でしょうか?

規模が小さいうちは簡易な運用で問題ないことが多いですが、システムの数が増え始めるタイミングで手遅れになりやすい領域です。ツールを追加する前に、簡易版でよいので正本の考え方を導入しておくことが望ましいです。

CRMとMA、BI、データ基盤の正本をどう決めるか

この記事の要約

CRMの商談金額とBIダッシュボードの売上が合わない、MAのリード数とSFAの商談数がずれる——
こうした「数字の食い違い」の原因は、ツールの性能不足ではなく、どのデータをどのシステムの「正本(マスターデータ)」とするかを決めていないことにあります。

本記事では、CRM・MA・BI・データ基盤という4つのレイヤーがそれぞれ本来担うべきデータ領域を切り分け、正本を決定するための判断基準を提示します。さらに、正本が決まった後に必要になる「連携境界」の設計、つまりどのデータをどの方向にどの頻度で同期し、どこで名寄せするかという実務手順まで解説します。

読み終える頃には、自社のデータ構成を思い浮かべながら、どこに正本を置き、どこをAPI連携やETLで結ぶべきかを具体的に判断できる状態になっているはずです。

この記事でわかること

CRM・MA・BI・データ基盤それぞれが「正本」を持つべきデータ領域の切り分け方
数字の食い違いが起きる典型的な原因と、その根本にある設計不備
正本を決定する際の判断基準(発生源・更新頻度・利用目的の3軸)
システム間の連携境界を設計する具体的な手順とチェックポイント
正本運用を組織に定着させるためのガバナンス体制の作り方

はじめに
なぜCRM・MA・BIで数字が食い違うのか
CRM・MA・BI・データ基盤、それぞれが持つべき正本領域
正本を決定するための3つの判断基準
連携境界をどう設計するか
正本運用を組織に定着させるガバナンス体制
まとめ
Q&A
専門用語解説

はじめに

月次の役員会議で、営業部長が提示した受注件数とBIダッシュボードの数字が一致せず、会議が止まってしまう——RevOpsやデータ管理を担当している方なら、一度はこうした場面に立ち会ったことがあるのではないでしょうか。原因を調べてみると、CRMでは「受注」のステータスが更新された日付、MAでは商談化した日付、BIはそのどちらとも違う集計ロジックを使っていた、ということがよくあります。

それぞれのツールは正しく動作しているのに、どのデータを基準にするかが決まっていないために、全社で共有できる「一つの数字」が存在しない状態になっているのです。この記事では、この状態を解消するために、CRM・MA・BI・データ基盤の役割分担と正本の決め方、そして連携境界の設計方法を順を追って整理していきます。

なぜCRM・MA・BIで数字が食い違うのか

結論から言えば、数字の食い違いは「同じ概念を、複数のシステムがそれぞれ独自の定義で保持している」ことが原因です。ツールを増やすたびにこの構造は悪化し、最終的にはどの数字を信じればよいのか誰も分からなくなります。

「同じはずの数字」が実は違う定義で計算されている

例えば「商談化率」という指標一つを取っても、MAでは「MQLに転換した件数÷リード数」で計算し、SFA(CRM内の営業支援機能)では「商談ステージに進んだ件数÷リード数」で計算しているケースは珍しくありません。両者は似ているようで、カウントの起点も終点も異なります。BIツール側でさらに独自の集計ロジックを重ねてしまうと、3つのシステムで3種類の「商談化率」が併存することになります。

この状態が長く続くと、現場は次第に「どうせ数字は合わない」という前提で仕事を進めるようになります。これは非常に危険な兆候です。データそのものへの不信が、意思決定のスピードと質を静かに蝕んでいくためです。

ツールを増やすほど「正本不在」の弊害は拡大する

CRM、MA、BI、さらに専用のデータ基盤(DWHやCDPなど)を導入する企業が増えていますが、ツールの数が増えるということは、同じデータを保持し得る場所が増えるということでもあります。正本を決めずにツールだけを増やすと、食い違いの発生源が比例して増えるという単純な構造になっています。

つまり、この問題はツールの選定ミスではなく、データアーキテクチャ設計の不在によって起きています。次のセクションでは、どのシステムがどのデータの正本を持つべきかを、レイヤーごとに整理していきます。

CRM・MA・BI・データ基盤、それぞれが持つべき正本領域

先に結論を示します。正本は「そのデータが最初に発生する場所」に置くのが原則です。発生源から離れたシステムに正本を置くと、必ず入力の二重管理や更新漏れが発生します。この原則に沿って4つのレイヤーの役割を整理すると、以下のようになります。

レイヤー	正本とすべき主なデータ	理由
CRM(SFA含む)	商談情報、顧客企業・担当者情報、受注・失注理由	営業活動が実際に発生する場所であり、最新の商談状況を最も正確に反映できる
MA	リードのスコアリング、行動履歴、メール反応データ	マーケティング施策への反応が最初に記録される場所
BI	経営指標の集計ロジック、可視化定義	複数ソースを統合して意思決定用に加工する役割であり、元データの発生源ではない
データ基盤(DWH/CDP等)	名寄せ済みの統合顧客ID、履歴データのアーカイブ	複数システムのデータを突合・統合する唯一の場所として機能する

この表からも分かる通り、BIは正本を持つ場所ではなく、正本を「見せる」場所である点が重要です。BIツールに直接データを手入力したり、BI側だけの独自ロジックで数値を作り込んだりすると、それは新たな正本を勝手に生み出す行為になってしまいます。

CRMが正本を持つべき理由と、持ちすぎてはいけない理由

CRMは商談・顧客情報の正本として最も適したシステムです。営業担当者が日々の活動の中で更新するため、発生源に最も近い場所だからです。しかし一方で、CRMにマーケティング施策の詳細な行動履歴まで抱え込ませようとすると、入力負荷が急増し、結果としてデータの鮮度が落ちるという逆効果が生まれます。CRMは「商談に関する事実」の正本であり、「見込み客の興味関心の推移」の正本ではない、という線引きが実務上は有効です。

MAが正本を持つべき理由と、限界

MAはリードの行動データや反応履歴において最も精度の高いデータを持っています。開封率やクリック率、フォーム送信履歴など、行動そのものを記録する仕組みが備わっているためです。ただしMAが持つデータは「見込み客」の段階のものであり、商談化した後の実態を正確に反映し続けることは想定されていません。商談化した瞬間に、その顧客に関する正本の主導権はMAからCRMへ移す、という考え方が整理の起点になります。

データ基盤が正本を持つべき理由

複数システムに分散した顧客データを統合し、名寄せを行う役割は、CRMにもMAにもBIにも本来担わせるべきではありません。それぞれのツールは自分の管轄範囲のデータ管理に最適化されており、他システムとの突合を主目的として設計されていないためです。データ基盤(DWHやCDPなど)を用意し、そこで統合IDを発行・管理する体制が、中長期的には最も安定します。

CRMを売上プロセスの基盤として再設計する進め方は、次の記事で確認できます。

HubSpotを売上を生む仕組みとして設計し直す：診断から90日まで

HubSpot責任者・CMO向けに、顧客名簿化したHubSpotを定義・データ・運用・レポートの4視点で診断し、90日の実行順序で再設計する考え方を解説します。

正本を決定するための3つの判断基準

どのシステムを正本にするか迷った場合は、次の3つの軸で判断すると整理しやすくなります。

発生源に最も近いか:そのデータが最初に人の手や行動によって生まれる場所はどこか
更新頻度と鮮度の要求水準に耐えられるか:リアルタイムに近い更新が必要なデータを、更新が遅いシステムに正本として置いていないか
利用目的が「記録」か「意思決定」か:記録用途のデータは発生源のシステムに、意思決定用途のデータは統合・加工後のBIやデータ基盤に置くべきではないか

チェックリストで自社の状況を点検する

以下の項目に一つでも当てはまる場合、正本設計の見直しが必要なサインです。

同じ指標について、複数のシステムで異なる集計結果が出ている
BIツールの中に、他システムに存在しない独自のマスタデータがある
手作業のExcelがなければ月次数値が確定しない
誰か特定の担当者しか「正しい数字」の作り方を把握していない
システムを追加するたびに、名寄せ作業の工数が増えている

このチェックリストに複数該当する場合、問題はツールではなく設計にあると捉えるべきです。次に、正本が決まった後に必要になる「連携境界」の設計に進みます。

連携境界をどう設計するか

正本を決めただけでは、システム間の数字は自動的には揃いません。正本から他システムへ、どのデータをどの方向・どの頻度で流すかという連携境界の設計が必要になります。ここを曖昧にしたまま運用を始めると、結局は手作業での二重入力に逆戻りしてしまいます。

データフローの方向を明文化する

連携設計の第一歩は、データがどちらからどちらへ流れるのかを明文化することです。例えば「商談ステージはCRMからBIへ一方向で流す」「リードスコアはMAからCRMへ一方向で流す」というように、双方向同期を安易に選ばないことが重要です。双方向同期は便利に見えますが、同じ項目を両方のシステムで編集できる状態を作ってしまい、結果的にどちらが正しいのか分からなくなる原因になります。

名寄せのタイミングと責任範囲を決める

顧客や企業の名寄せは、連携設計の中でも特に揉めやすいポイントです。CRM側で入力した企業名の表記ゆれ、MA側で取得したメールドメイン、データ基盤側で統合した法人番号——これらをどの段階で、どのロジックで、誰の責任で突合するのかを明確にしておく必要があります。名寄せロジックを複数の担当者・複数のツールに分散させないことが、後々のトラブルを防ぐ最大のポイントです。

連携の更新頻度を目的に合わせて設計する

すべてのデータをリアルタイム連携にする必要はありません。むしろ、目的に応じて更新頻度を意図的に使い分けることが、システム負荷とコストの観点でも合理的です。

データの種類	推奨される連携頻度	理由
商談ステータス	リアルタイム〜1時間ごと	営業現場の意思決定に直結するため
リードスコア	日次	施策の効果測定には日次で十分なケースが多い
経営ダッシュボード用集計値	日次〜週次	意思決定のサイクルに合わせれば十分
履歴アーカイブ	週次〜月次	分析用途が中心で即時性の必要が低い

連携が壊れたときに気づける仕組みを持つ

どれほど丁寧に設計しても、APIの仕様変更やシステムアップデートによって連携が止まることは起こり得ます。連携が止まった場合に、誰かが気づける仕組みを用意しておかないと、数週間分のデータが欠落したまま誰も気づかない、という事態に陥ります。同期件数の異常値を検知するアラートや、日次での件数突合チェックなど、簡易な監視の仕組みを組み込んでおくことをおすすめします。

現場がツールを信頼できずExcelへ戻る構造については、次の記事を参照してください。

CRM、MA、BIがあるのに現場がExcelへ戻る理由

CRM・MA・BIを導入しても現場がExcelに戻る理由を、業務導線・データ品質・変更管理という3つの観点からCEO・RevOps・IT向けに解説します。

正本運用を組織に定着させるガバナンス体制

正本と連携境界を設計しても、それを維持する体制がなければ、時間の経過とともに形骸化していきます。ツールの担当者が異動するたびに独自ルールが生まれ、気づけば元の状態に戻っている、というのはよくある失敗パターンです。

データオーナーを役割ごとに明確にする

正本ごとに「誰が最終的な責任を持つか」を明文化しておくことが欠かせません。CRMの商談データはセールスオペレーション、MAの行動データはマーケティングオペレーション、統合IDはRevOpsやデータ管理者、というように役割単位でオーナーを割り当てることで、変更が発生した際の意思決定ラインが明確になります。

新しいツール導入時に「正本のどこに位置づくか」を必ず問う

新しいSaaSやAIツールを導入する際、多くの企業は機能面ばかりを検討し、「このツールはデータ構造のどこに位置づくのか」という問いを後回しにしがちです。導入前に正本マップ上での位置づけを確認するという一手間を挟むだけで、後から発覚する二重管理のリスクを大幅に減らすことができます。

よくある失敗パターン:正本を「決めたつもり」で終わるケース

正本設計のプロジェクトが頓挫する典型例として、キックオフ時の会議で「CRMを正本にしましょう」と合意したものの、具体的なフィールド単位での取り決めまで踏み込まないまま終わってしまうケースが挙げられます。例えば「顧客ステータス」という項目一つとっても、CRM側の定義とMA側の定義が微妙に異なっていれば、正本を決めた宣言だけでは食い違いは解消しません。