レポートの数字が再現できない。「予約47件 vs 58件」を1件単位で突合して分かったこと

月次の振り返りで、分析チームのレポートは「商談予約47件」、現場の顧客管理ツールの画面は「58件」。さて、どちらが正しいでしょうか。

答えは「どちらも正しい」です。そして、これがいちばん厄介なパターンです。ある案件のレポート作成で実際にこの食い違いが起き、1件単位で突合して原因を完全に分解しました。結果わかったのは、数字が割れる原因は集計ミスではなく、誰も明文化していなかった定義の差が3つ重なっていたことでした。

この記事は、その分解の過程と、再発を止める「定義の固定」のやり方を書きます。

実話：差分11件の内訳を全部割った

47件と58件。11件の差を、データを1件ずつ並べて分類しました。内訳はこうです。

3つの軸を揃えると、47件と58件は1件の狂いもなく一致しました。つまりどちらのシステムも正確で、壊れていたのは数字ではなく言葉の方だった。「予約数」という同じ単語が、人によって違う集計を指していたわけです。

結論：指標は「3軸＋正データソース」を書いて初めて定義になる

この経験から、指標の定義テンプレートをこう固定しました。

1. 日付基準：何の日付で月を区切るか（申込日か、実施日か、成約日か）
2. 対象範囲：どの拠点・どのチャネル・どの商品を含むか
3. ステータス条件：キャンセル・無効・テストをどう扱うか（「予約レコードが存在する」と「有効な予約である」は別物）
4. 正とするデータソース：複数システムに同じ情報がある場合、どれを正にするか

例えばこの案件では「商談予約＝顧客管理上のステータスが予約済のレコード。マーケ評価はコホート基準（問い合わせ月で集計）、現場の稼働報告は実施日基準。両者は別指標として併記する」と決めました。どちらかに寄せるのではなく、用途が違う2つの指標だと認めて名前を分けるのがポイントです。マーケ施策の評価に実施日基準を使うと先月の問い合わせの成果が今月に混ざりますし、現場のキャパ計画にコホート基準は使えません。

もうひとつの教訓：再現できない数字は捨てる

突合の過程で、より深刻な発見もありました。過去のレポートに載っていたある指標を、今回どの定義・どの条件で集計し直しても再現できなかったのです。集計した本人の手順が残っておらず、その月だけのアドホックな抽出だった可能性が高い。

再現できない数字は、前月比較の基準として機能しません。私たちは「以後この数字は使わない」と宣言して捨てました。痛みはありますが、出所不明の数字に接ぎ木を続けるより安い。レポートの数字には、SQLなり抽出条件なりの「再現手順」をセットで残す。これが守られていれば、そもそも今回の騒ぎの半分は起きていません。

数字が割れたときの実務手順

同じ状況に当たったら、この順で進めるのが速いです。

1. 多数決や直感で選ばない。「現場の画面が正しいだろう」で片方を採用すると、原因が温存される
2. 両方の集計条件を書き出す。日付基準・範囲・ステータス・ソースの4点を、それぞれについて明文化する
3. 1件単位で突合する。集計値の比較では原因は割れない。レコードを並べて、差分の1件1件に理由をつける
4. 定義を文書化し、レポートに注記する。「本レポートの予約数＝○○基準」と毎回1行書く。読み手が二度と迷わない

3が面倒に見えますが、差分は今回のように十数件程度のことが多く、実作業は数時間です。数ヶ月ごとに同じ論争を繰り返すコストよりずっと安い。

アンチパターン：逆算で「合う」条件を探す

一番やってはいけないのは、「現場の58件に合うまでフィルタ条件を足し引きする」ことです。偶然一致する条件の組み合わせは大抵見つかりますが、それは定義ではなくただの帳尻合わせで、翌月また割れます。突合は「合わせる」作業ではなく「差の理由を全部言えるようにする」作業です。

なお、ステータス条件の見落とし（キャンセル混入）はSQL実装レベルでも頻発する罠で、その実装側の話は別記事「BigQueryで数えるべき行を間違えるステータスフィルタの罠」で書く予定です。本記事はその一段上、定義ガバナンスの話でした。

まとめ

• 数字が割れる原因の多くは集計ミスではなく、明文化されていない定義差（日付基準・範囲・ステータス）
• 指標は3軸＋正データソースを書いて初めて定義になる。用途が違うなら別指標として名前を分ける
• 再現手順のない数字は基準にできない。捨てる勇気を持つ
• 突合は集計値ではなく1件単位で。逆算の帳尻合わせは翌月また割れる

「会議のたびに数字が違う」状態の整理、KPI定義書の策定からレポート基盤の構築までを支援しています。お問い合わせはこちら。