月曜日の朝、会議室に三枚のスライドが並んでいる。営業部が出した先月の売上は1億2千万円、経営企画が提出した同じ期間の数字は1億1千5百万円、そしてシステム部門が自動生成したダッシュボードには1億3百万円と表示されている。誰も嘘をついていない。それなのに、数字は三つある。この種の混乱は、多くの組織で静かに、しかし確実に進行している。問題の本質はデータそのものの品質ではなく、「何を売上と呼ぶか」という定義と、「いつの時点で集計するか」というタイミングの、二重の不統一にある。本稿では、その根本原因を特定するための具体的な調査手順を、現場で実際に役立つ形で書き記す。

第一章　三枚のスライドが生まれるまで——不一致の解剖

どの組織にも、それぞれの部門が長年かけて育ててきた集計ロジックがある。営業部は受注確定日を基準に売上を計上し、経営企画は請求書の発行日を使い、システムのダッシュボードは入金日を参照する。どれも「正しい」運用であり、それぞれの業務目的に照らせば合理的な選択だ。しかし月をまたぐ取引が増えるほど、三つの基準は三つの異なる数字を生み出す。調査の第一歩は、この「基準日の多様性」を地図として描き起こすことにある。具体的には、主要な五つから十のレポートを選び、それぞれが参照しているテーブル名、日付カラム名、フィルター条件を一覧化する。ExcelでもNotionでも構わない。重要なのは、比較可能な形式で横断的に並べることだ。この作業だけで、多くの場合、不一致の六割は説明がつく。

第二章　データ定義の不統一——言葉の地層を掘り下げる

「売上」という言葉は、組織の歴史の地層を持っている。十年前に基幹システムを導入したとき、当時の担当者が「売上＝出荷完了」と定義した。五年前にSaaSツールを追加したとき、そのツールのデフォルトは「売上＝サブスクリプション開始日」だった。三年前に経営企画が独自のBIレポートを作ったとき、CFOの指示で「売上＝入金確認」に変えた。誰もその変更を一元的に記録していない。これを調査するために有効なのが「定義インタビュー」だ。関係する三つから五つの部門のキーパーソンに、同じ質問を別々に投げかける——「先月の売上の数字を出すとき、あなたはどのシステムの、どのテーブルの、どのカラムを使っていますか？」。答えを書き留め、並べてみると、言葉の意味が部門ごとに静かに分岐していることが、初めて可視化される。

第三章　集計タイミングのずれ——スナップショットという概念を知る

データウェアハウスやBIツールが扱うデータは、常に「ある瞬間の複写」だ。この複写をスナップショットと呼ぶ。問題は、スナップショットが取られる時刻が、ツールやパイプラインによって異なることにある。あるダッシュボードは毎朝午前三時にETLジョブが走り、別のレポートは月次バッチで前月末日の深夜零時時点のデータを参照し、もう一方はリアルタイムAPIで現在の状態を返す。同じ「先月の売上」を問い合わせても、月末締め後に訂正された取引を含むかどうかで、数字は変わる。調査手順としては、各データパイプラインのジョブログを確認し、「最終実行日時」と「参照期間の定義」を記録する。特に月初の数日間は、前月データの遅延投入や訂正が集中するため、レポート生成のタイムスタンプが数字の差を大きく左右する。この事実を議事録に残すだけで、会議室の空気が変わる。

第四章　具体的な調査手順——現場で使える五つのステップ

第一に、問題のあるレポートを二つ選び、差分の金額を特定する。たとえば五百万円の乖離があるとする。第二に、それぞれのレポートのSQLクエリまたは集計ロジックを取得し、FROM句のテーブル名とWHERE句の日付条件を書き出す。第三に、差分に相当するトランザクションを特定するために、両方のロジックで共通して存在するはずのIDを軸に突合する。この突合で、「片方にあって片方にない」レコードが浮かび上がる。第四に、そのレコードの日付カラムを複数確認する——受注日、出荷日、請求日、入金日が一致しているか。月末をまたいでいるものが多ければ、タイミング問題が主因だ。第五に、残差がある場合は定義の問題を疑い、ディメンションテーブル——顧客区分、商品カテゴリ、チャネルコードなど——のマスタデータが二つのレポート間で異なるバージョンを参照していないかを確認する。この五ステップで、多くの不一致は解明できる。

第五章　根本的な処方箋——データ契約という考え方

不一致を特定した後、多くの組織が「正しい数字はどれか」という議論に入ろうとする。しかしそれは問いの立て方が間違っている。正しい問いは「何のための数字か」だ。近年、データエンジニアリングの世界では「データ契約（Data Contract）」という概念が広まっている。これはデータの生産者と消費者が、スキーマ、更新頻度、品質基準を明示的に合意する文書だ。具体的には、「売上」という指標について、定義（受注確定日基準）、集計単位（円、税抜）、更新タイミング（毎営業日午前六時）、担当者（経営企画部・田中氏）を一枚のドキュメントに書き、全レポートがそのドキュメントを参照する形にする。これは技術の問題ではなく、組織のコミュニケーション設計の問題だ。ドキュメントを作る会議に、ITだけでなく事業部の意思決定者を必ず呼ぶこと——これが最も重要な実装上の注意点だ。

第六章　再発防止のための観測体制——数字のずれをアラートで知る

調査と修正が終わった後、同じ問題が静かに再発することは珍しくない。人事異動、新しいツールの導入、基幹システムのバージョンアップ——これらはいずれも、合意した定義を壊す可能性を持っている。予防策として有効なのは、重要な指標について「整合性テスト」を定期的に自動実行することだ。たとえば、営業レポートの月次売上と経営企画レポートの月次売上の差が、一定の閾値——たとえば〇・五パーセント——を超えた場合にアラートを送る仕組みを作る。dbtのテスト機能やGreat Expectationsといったオープンソースのツールがこの用途に使える。技術的な実装よりも重要なのは、そのアラートを誰が受け取り、誰が調査の責任を持つかを、あらかじめ決めておくことだ。データ品質はエンジニアだけの問題ではない。それは組織全体の信頼性の問題だ。

おわりに——数字を信頼することの、静かな意味

会議室の三枚のスライドに戻ろう。調査を終えた後、あの場に戻れたとしたら、問うべきは「どれが正しいか」ではなく「それぞれが何を表しているか」だ。一億二千万円は営業が管理する受注ベースの数字であり、一億一千五百万円は経営が使う請求ベースの数字であり、一億三百万円は財務が確認する入金ベースの数字だ。三つはすべて真実であり、すべての目的に同時に答えることはできない。データの不一致を解くとは、数字の背後にある人間の意図と文脈を丁寧に掘り起こす作業だ。その作業を怠ったとき、組織は数字に振り回される。その作業を丁寧に続けたとき、数字は初めて、信頼できる道具になる。

「数字が合わない」という問題は、技術の失敗ではなく、対話の不足から生まれることが多い。調査の手順を踏み、定義を合意し、観測体制を整えること——その一連の営みは、データチームだけでなく、組織全体の判断力を静かに底上げする。次の月曜日の朝、あなたの会議室に並ぶスライドが、同じ一枚の地図を指し示すことを願っている。