ExcelからBIツール移管時の数値ズレの原因と対応策5選

こんにちは、SPENDAの伊藤です。
各企業にとってAIとBIツールの重要性がどんどん増しています。
弊社でもBIツールの導入、エラー対応の相談は良く受けるのですが、その中で「ExcelとBIツールの数値が合わない」という問題が相談件数の上位占めており、多くの企業で見られる課題です。

特にExcelからPowerBIやTableauなどのBIツールへ移行した直後に「以前のExcelとBIレポートで数値が食い違う」という指摘は毎回と言っても良い程よくあります。

一見BI側の不具合に思えますが、ほとんどの場合は設定やデータ状況の違いによって起こります。こうした違いを理解・対処せず放置すると、原因調査に時間を浪費したり、誤った判断によるその後の大きな損失に繋がりかねません。

そこで今回は、ExcelからBIツールへデータ移行する際に良く起こる数値ズレの主な要因とその具体的な対応策を以下に解説します。

1. Excelでの手作業による補正・加工

Excelファイルの作成や更新作業では、担当者の裁量によってデータに変更が加えていることがほとんどです。例えば、特定の取引先や異常値を手動で除外したり、端数調整のために数値を丸めたりするケースです。

このように規則性なしに微調整がExcel上で行われている場合、同じデータを機械的に集計するBIツールとは結果がずれる結果になるのは当然です。しかも、その手作業が関係者に共有されていなければ、差異の原因究明に余計な時間を費やすことになります。

この問題への対応策としては、Excelの編集時の操作を明文化してルール化し、可能な限りそれをBIツールで再現できる内容として定めることが重要です。まず担当者にヒアリングしてどんな補正や除外処理を行っていたのかを洗い出す必要があります。

洗い出した内容はBIツールの前処理（ETLやクエリ）に組み込み、だれでも再現できる形で自動化します。こうすることで人為的な調整忘れによる数値ズレを防ぎ、エラーや数値ずれの度に原因調査に追われる無駄な時間を削減できます。

2. 集計条件やフィルタの前提の違い

ExcelとBIで比較する際に集計対象の条件が揃っていないと、出力される数字が食い違います。例えば、下記のような前提違いが原因になることがあります。

3. KPIや用語定義の不統一

「売上」「契約数」「新規顧客」などの指標が部門ごと・担当者ごとに違う定義で使われている場合も数値ズレの原因になります。
同じ言葉でも解釈が異なれば算出結果も異なるためです。

例えば、「売上」ひとつ取っても人によって税込み・税抜きのどちらを指すかが異なったり、計上基準を「出荷日ベース」か「入金日ベース」かで認識が分かれるケースがあります。

また「新規顧客」の定義が「初回受注件数」「初問い合わせ数」「初ログイン数」のどれを意味するかで異なることも考えられます。
定義がバラバラのままでは、せっかくBIツールで統一されたダッシュボードを作っても「自分の知っている数値と違う」と誤解され、議論が平行線をたどってしまいます。

この問題を防ぐには、KPIや業務用語の定義を社内で統一することが必要です。
データ担当者や各部署の代表者が集まり、指標ごとに正式な定義を決めましょう。

例えば「売上」は「税込・出荷日ベース」とする等、用語の意味を明文化したドキュメントを作成します。
そしてBIツール上の計算ロジックや項目名も、その統一定義に沿ったものに揃えます。定義が共有されていれば、ExcelでもBIツールでも数値比較において「どの定義で算出された数字か」が明確になるため、余計な議論や調整作業に時間を割くことが減ります。

4. データ粒度の違い（明細とサマリ、日次と月次）

集計するデータの粒度（細かさ）が異なることも、数値の不一致を招く要因です。
Excel側では月次のサマリデータを見ているのに、BI側では日次の明細データまで含めて集計している、といったケースです。

例えば、Excelでは月ごと・カテゴリごとの売上集計値を扱っている一方で、BIツール上では全ての取引を日別・商品別に集計している場合、両者で数字が食い違うのは自然なことです。
粒度が違えば、単純に合計や平均を比較しても一致しません（明細を合算すると端数の差異が出る、月次平均と日次平均で計算方法が異なる等）。
この齟齬に気付かず比較を続けると、「なぜ一致しないのか」と不要な分析作業に時間を浪費してしまう恐れがあります。

対策としては、比較するデータの粒度（集計単位）を揃えることが不可欠です。
Excelの月次集計とBIの明細集計を比べるなら、BI側で月次カテゴリ別に集計し直すか、Excelを日次明細レベルまで展開して検証する必要があります。
また、BI導入時には「どのレベルのデータを標準の報告単位とするか」を決めておき、利用者に周知しておくとよいでしょう。

例えば「基本は日次の詳細データもBIで確認できるが、経営指標は月次サマリで見る」などルールを決めておけば、粒度の違いによる数字の食い違いへの戸惑いを減らせます。
要は比べる土台を同じにすることが、無駄な確認作業を防ぐポイントです。

5. Excelは加工済みデータ、BIは生データ

ExcelとBIで扱っているデータの状態が異なることも、大きな数値ズレの原因になります。
現場のExcelでは必要に応じてデータ抽出後に整形・クレンジングされ完成形のデータを使っている一方、BIツール側では基幹システムやデータベースから取得した未加工の生データをそのまま集計しているケースが多々あります。

例えば、売上データから明らかに誤入力と分かるテスト取引や返品データを手動で削除してからExcelで集計している場合、BIでは何も除外せずにそのまま集計するため数値が合わなくなります。
同様に、マスタの不備による無効なレコードや社内テスト用のデータを現場判断で除外していれば、Excel上ではきれいな数字でもBIではそれらが含まれて「増えて」見えることになります。

こうした処理は属人的に行われていることが多く、Excel側で何を除外・修正したかが明文化されていないと、原因の特定に非常に手間取ります。
このズレを解消するには、Excelで行われている事前加工の内容を洗い出し、BIのデータ取り込み過程に反映させることが有効です。

具体的には、Excel担当者が暗黙的に行っていた除外・変換処理を一覧化し、それをデータベース側で実施したりBIのクエリに組み込んだりします。
例えば「返品データは分析対象から除外する」「顧客マスタの不備レコードは集計前に補正する」等のルールをETLプロセスやクエリに組み入れるのです。

また、どうしてもBIでは再現しきれない特殊ケース（例：特定取引先を意図的に除外する等）は、レポート上で注釈を付けるか、業務プロセス自体の見直しも検討する必要があります。
ポイントとしては、生データと現場加工データの差を埋めることです。

この対応で「Excelでは合っているのにBIではおかしい」と担当者が混乱するのは良くあることです。数値合わせに時間がかかりすぎるのは本末転倒なので、設計段階でしっかり同じ数値が得られるように検証しながらデータ出力することが大事です。