データ統合はどこから始める？Excel・SaaS・CRMが分散した企業の進め方

産業インサイト・課題解決//

DXやデータ活用を進めようとしたとき、「必要なデータが部署やシステムごとに分散している」という問題に直面する企業は少なくありません。

営業部門ではCRM、経理部門では会計システム、現場ではExcel、別の部門ではSaaSや基幹システムを利用している、といった状態です。同じ顧客や商品を扱っていても、システムごとに名称、コード、日付、金額の意味が異なる場合もあります。

こうした状況を見ると、「まず社内データをすべて統合しなければならない」と考えがちです。

しかし、データ統合そのものを目的にすると、対象システム、項目、関係部署が増え、プロジェクトの範囲も大きくなりやすくなります。

最初に決めたいのは「何を統合するか」ではなく、「何を判断したいか」です。その判断に必要なデータ、データの定義、データ同士を結び付ける共通キーを整理し、小さい範囲から統合することが一つの実務的な進め方です。

本記事では、Excel、SaaS、CRM、会計、基幹システムなどにデータが分散している企業を想定し、データ統合をどこから始めればよいかを具体的に解説します。

なぜ企業のデータは部門ごとに分散するのか

企業内に複数のシステムが存在すること自体は、不自然なことではありません。

営業部門には営業活動に適したCRM、経理部門には会計処理に適したシステムがあります。販売管理、生産管理、人事、問い合わせ管理など、それぞれの業務に必要な仕組みを導入すれば、企業内に複数のデータソースが存在するのは自然です。

問題が表面化するのは、それらを横断して分析しようとしたときです。

例えば、経営企画部門が「顧客ごとの商談状況と実際の売上を合わせて確認したい」と考えたとします。営業CRMには商談情報、会計システムには売上情報がありますが、両者には次のような違いがあるかもしれません。

確認項目営業CRM会計システム
顧客名株式会社ABC(株)ABC
顧客IDC001C001
金額商談金額・受注金額会計上の売上金額
日付商談日・受注日売上計上日
データ粒度商談・案件単位伝票・明細単位
更新頻度営業活動に応じて更新会計処理に応じて更新

人間が見れば同じ顧客だと分かっても、システム上では異なる文字列として保存されています。

さらに重要なのは、同じ「金額」「日付」という項目でも、業務上の意味が異なる場合があることです。

異なるデータソースを統合する際には、列名を合わせるだけでなく、項目やデータ構造の対応関係を整理する必要があります。異なるスキーマ、つまりデータ構造の対応付けを行う「スキーママッチング」は、データ統合における基本的な課題の一つです（Rahm and Bernstein, 2001）。

DATA LANDSCAPE
営業部門

CRM・営業Excel

経理部門

会計システム

業務部門

SaaS・業務システム

基幹領域

基幹システム

名称
ID
日付
粒度
定義

それぞれのシステムが個別の業務では正しく機能していても、名称、ID、日付、粒度、定義まで自然に揃うとは限りません。

データ統合は「全部まとめる」ことから始めない

データが分散していることが分かると、全社データ基盤の構築、Excelのデータベース化、全部門の顧客マスタ統一、すべてのSaaS連携など、大きなテーマへ進みやすくなります。

継続的なデータ活用のために、最終的には全社的なデータ基盤が必要となる場合もあります。一方で、データ活用の初期段階から必ずしもそこまで実施する必要はありません。

例えば、「顧客ごとの営業活動と実際の売上を確認したい」という目的であれば、まず確認するデータは営業CRMと会計データです。人事データ、生産設備データ、Webアクセスログまで同時に統合する必要はありません。

INTEGRATION SCOPE
Scope First 保有データから考える
社内データを広く棚卸しする
統合対象が拡大しやすい
統合自体が目的になりやすい
Decision First 判断目的から考える
判断テーマを具体化する
必要なデータを選択する
小さい範囲で検証する

したがって、データ統合では、「保有しているデータをどう全部まとめるか」ではなく、「何を判断するために、どのデータが必要なのか」という順序で考えることが重要です。

データ統合を進める5つのステップ

実務では、次のような順序で対象を絞っていくと整理しやすくなります。

DECISION-LED DATA INTEGRATION
  1. 判断テーマ

    何を判断したいのかを明確にする

  2. 必要データ

    判断に必要なデータだけを選ぶ

  3. 定義・粒度

    値の意味とデータ単位を確認する

  4. 共通キー

    顧客や案件を対応付ける方法を決める

  5. 小規模統合

    確認後に必要な範囲へ広げる

Step 1：判断したいことを決める

最初に、「どのデータを分析したいか」ではなく、「分析結果を使って何を判断したいか」を整理します。

  • どの顧客を重点的にフォローするか判断したい
  • 商談から売上までの期間を確認したい
  • 顧客ごとの売上推移を確認したい
  • 営業活動と売上実績の関係を確認したい

「営業データを分析したい」だけでは対象範囲が広すぎますが、意思決定まで具体化すると必要なデータも見えやすくなります。

Step 2：必要なデータを絞る

次に、その判断に必要な項目を洗い出します。

例えば「商談から売上までの期間を確認したい」のであれば、顧客ID、案件ID、受注日、売上計上日、商談金額、売上金額などが候補になります。

CRMに多数の項目が存在していても、すべてを最初から取得する必要はありません。必要な項目から確認し、分析上不足する情報が見つかった段階で追加する方が、対象範囲を管理しやすくなります。

Step 3：データの定義と粒度を確認する

次に確認するのが、データの「意味」と「粒度」です。粒度とは、データ1行が何を表しているかという単位です。

例えば、CRMの1行が「商談1件」、会計システムの1行が「売上明細1件」であれば、両者は単純な1対1では結合できません。

「売上」という言葉についても、営業部門では受注金額、経理部門では会計上の売上高、管理部門では請求金額を指している可能性があります。日付についても、受注日、契約日、納品日、請求日、売上計上日、入金日はそれぞれ異なる業務イベントです。

データ品質には正確性、完全性、一貫性など複数の観点があり、単に値が入力されているだけでは十分とは限りません（Batini and Scannapieco, 2006）。計算処理自体が正しくても、データの意味を誤って解釈すれば、分析結果を意思決定へつなげることが難しくなります。

Step 4：共通キーと対応ルールを決める

異なるデータを結合するときには、同じ顧客や案件を識別するための「共通キー」が重要です。

例えば、CRMと会計システムの双方にcustomer_id = C001という顧客IDが存在すれば、「株式会社ABC」と「(株)ABC」という表記の違いがあっても、同じ顧客として対応付けることができます。

共通IDが存在しない場合には、分析用の対応表を作成する方法もあります。

CRM顧客名会計上の取引先名統合用ID
株式会社ABC(株)ABCC001
XYZ株式会社XYZC002

元のCRMや会計システムを書き換えなくても、分析時に使用するマッピングテーブルを用意することで対応できる場合があります。

Step 5：小さい範囲で統合して確認する

最初から全期間・全部門・全顧客を対象にする必要はありません。特定の期間、一つの事業部、主要顧客、一つの商品カテゴリなどに対象を限定して確認できます。

  • 想定したキーで正しく結合できるか
  • 欠損や重複がないか
  • データ定義に違いがないか
  • 分析結果を実際の判断に利用できるか

必要性と課題が確認できた段階で、対象期間、部門、システムを段階的に広げます。

CRMと会計システムで顧客名・売上月が異なるケース

ここからは具体例で考えます。以下は説明のために作成した架空データです。

システム顧客名顧客ID金額日付
営業CRM株式会社ABCC001商談金額 1,000,000円受注日 2026年4月25日
会計システム(株)ABCC001売上金額 1,000,000円売上計上月 2026年5月

このケースでは、顧客名称と日付が表している業務イベントが異なります。

CRMを基準にすれば、「4月に100万円を受注した」となります。一方、会計システムでは「5月に100万円を売上計上した」となります。

どちらかが誤っているわけではありません。それぞれ異なる業務事象を記録しています。

したがって、「4月の売上はいくらか」という問いだけでは、何を集計するべきか決まりません。営業活動を評価するのであれば受注ベース、財務実績を確認するのであれば会計上の売上計上ベースなど、判断目的によって見るべきデータが変わります。

データを統合する前に、「今回の分析で『売上』とは何を意味するのか」を決めておく必要があります。

共通キーがない場合はどうするか

実務では、CRMと会計システムの双方に同じ顧客IDが存在するとは限りません。

その場合には、既存データの中に対応付けへ利用できる情報がないかを確認します。例えば、法人番号、取引先コード、顧客管理番号、電話番号、所在地、メールドメインなどです。

複数のデータベース上のレコードが同じ企業や人物などの実体を表しているか判断する問題は、entity identificationやentity resolutionと呼ばれます。共通キーが存在しない場合には、複数の属性や識別ルールを組み合わせて対応関係を判断する考え方があります（Lim et al., 1996）。

ただし、会社名が似ているという理由だけで機械的に同一企業と判定することには注意が必要です。株式会社の有無、全角・半角、旧社名などは表記揺れとして整理できる場合がありますが、同名企業、子会社、支店などを誤って統合する可能性もあります。

自動的に判断しにくいデータについては、人による確認を残すことも選択肢になります。

データ統合前に確認したいチェックポイント

実際に統合を進める前には、少なくとも次の項目を確認しておくと整理しやすくなります。

確認事項確認内容
判断目的統合したデータを使って何を判断するのか
対象データ判断に本当に必要なデータか
共通キー顧客ID、案件ID、商品ID等が存在するか
項目定義同じ名称でも意味が異なっていないか
データ粒度1行が顧客、案件、伝票、明細のどれか
日付受注日、納品日、計上日等のどれか
単位円・千円、個・箱等が統一されているか
欠損分析に必要な項目が記録されているか
重複同じデータが重複登録されていないか
更新頻度リアルタイム、日次、月次等のどれか
管理責任データ定義を確認できる担当部署はどこか

この確認を行うと、「システム連携が必要な問題」と「データ定義や運用を整理すれば対応できる問題」を切り分けやすくなります。

どのデータから整理すべきか判断しにくい場合には、現在保有しているExcel、CSV、CRM等から、まず分析可能なテーマと不足データを整理する方法もあります。

データ基盤を構築する前に考えたいこと

データ統合を検討すると、DWH（データウェアハウス）、データレイク、ETLといった技術の話へ進むことがあります。

これらは、複数のデータを継続的に利用する場合には有効な選択肢です。一方で、技術基盤を構築するだけで、「顧客とは何を指すのか」「売上とは何を指すのか」「どの日付を使うのか」「どの粒度で分析するのか」といった業務上の定義まで自動的に決まるわけではありません。

そのため、判断目的、必要データ、データ定義、共通キー、小規模な統合・分析を先に整理し、その後に必要性を踏まえて基盤化を検討するという順序が考えられます。

また、データ統合は「既存システムを一つのシステムへ置き換えること」と同義ではありません。

CRM、会計、販売管理などをそのまま利用しながら、分析時に必要なデータだけを取り出し、共通キーやマッピングテーブルによって論理的に結合する方法もあります。その上で、データ量、更新頻度、利用人数、分析の継続性などを踏まえ、恒久的なデータ基盤が必要かを判断します。

まず自社で実施できる3つのアクション

1. 判断したいことを一つ書き出す

「データを活用したい」ではなく、「顧客別に商談と売上を比較し、重点的にフォローする対象を判断したい」のように、実際の意思決定まで具体化します。

2. 関係するデータを2〜3種類に絞る

最初から社内システムをすべて統合対象にせず、その判断に直接関係するデータから確認します。今回の例であれば、まず営業CRMと会計データです。

3. 少量のデータを実際に横並びにする

対象となる顧客について、顧客名、顧客ID、金額、日付、案件番号などをExcel等へ並べて比較します。

  • 顧客IDが一致していない
  • 顧客名の表記が異なる
  • 金額の意味が違う
  • 日付の意味が違う
  • 必要な情報自体が記録されていない

このような問題は、小さい範囲でデータを並べるだけでも見つかる場合があります。大規模なデータ基盤を構築する前に確認することで、実際に解決すべき問題がデータ連携なのか、データ定義なのか、入力・運用なのかを整理しやすくなります。

まとめ

部署ごとにExcel、SaaS、CRM、会計、基幹システムが分散していても、最初からすべてのデータを統合する必要はありません。

  1. 何を判断したいのか
  2. その判断にどのデータが必要なのか
  3. データの意味と粒度は一致しているか
  4. データを結び付ける共通キーは存在するか
  5. 小さい範囲で実際に分析できるか

特に重要なのは、同じ名称の項目が存在することと、同じ意味のデータであることは別だという点です。顧客名や商品名の表記だけでなく、「金額が何を意味するのか」「日付がどの業務イベントを示すのか」まで確認する必要があります。

全社的なデータ基盤の構築は、こうした整理と小規模な検証を行った後に検討することもできます。

SCI総合研究所株式会社のRASHINRAでは、既存のExcel、CRM、販売管理、会計等のデータを確認し、経営・業務上の判断テーマに対して、どのデータが利用できるかを整理する支援を行っています。

  • データはあるが、何を分析すべきか整理できていない
  • 複数システムのデータをどう組み合わせるべきか分からない
  • データ基盤を構築する前に、現在のデータで何が判断できるか確認したい

こうした段階から、データ活用の進め方を検討できます。

RASHINRA｜経営データ活用・意思決定支援について詳しく見る

参考文献

  • Rahm, E. and Bernstein, P. A. 2001. A survey of approaches to automatic schema matching. The VLDB Journal. Vol. 10. Issue 4. pp. 334-350. DOI: 10.1007/s007780100057.
  • Lim, E. P. et al. 1996. Entity Identification in Database Integration. Information Sciences. Vol. 89. Issues 1-2. pp. 1-38. DOI: 10.1016/0020-0255(95)00185-9.
  • Batini, C. and Scannapieco, M. 2006. Data Quality: Concepts, Methodologies and Techniques. Springer Berlin, Heidelberg. DOI: 10.1007/3-540-33173-5.