「予実が合わないのは、2つの表を同じ物差しで並べていないからです」
SFAのオブジェクトをそのままBIにつなぐと、商談と活動を結合した瞬間に行が膨らみ、粒度の違う数字が混ざります。分析基盤（DWH）を入れても、設計図・点検・配管の3つがなければ同じことが起きます。基本編と応用編で決めた「数え方」を、分析基盤の上でどう組み、どう守り、どう現場に戻すかを整理します。
設計図：業務ごとに記録し、切り口は全社で共有する
学年全体の成績を分析したいのに、クラスごとに名簿の並び順も科目名も違ったら、クラスをまたいで比べられません。必要なのは、名簿と科目表を学年で1つにして、全クラスで共有することです。Kimball流のディメンショナルモデリングは、これを会社全体でやる方法です。出来事の記録（ファクト）は業務プロセスごとにつくり、切り口（ディメンション）は全社で1つにして共有します。
ファクトの設計は、次の順番で行います。2番目を飛ばさないことが一番大事です。
例：商談のステージが変わる
例：1行＝1回のステージ変更。文章で書いて残す
日付・取引先・担当者など
金額、前のステージにいた日数など
全体の設計図として、業務プロセスと共有する切り口を1枚の表（バスマトリクス）にします。
| 業務プロセス | 粒度（1行は何か） | 日付 | 取引先 | 人 | 担当・組織 | 商品 | 施策 |
|---|---|---|---|---|---|---|---|
| 施策との接点 | 人×施策×日時 | ● | ● | ● | 使わない | 使わない | ● |
| 活動 | 活動1件 | ● | ● | ● | ● | 使わない | 使わない |
| 商談の週次写真 | 商談×週 | ● | ● | 使わない | ● | 使わない | ● |
| 受注明細 | 明細1行 | ● | ● | 使わない | ● | ● | 使わない |
| ARRの月次写真 | 取引先×商品×月 | ● | ● | 使わない | 使わない | ● | 使わない |
| 利用の月次まとめ | 取引先×月 | ● | ● | 使わない | 使わない | ● | 使わない |
列の切り口は、どの行でも同じテーブルを使います。これで、マーケの接点・営業の受注・CSの利用を、同じ取引先・同じ月でつなげて見られるようになります。
- どの方向にも足せる数字
- 受注額、活動件数。そのまま合計してよい
- 期間の方向には足せない数字
- ARR残高、パイプライン残高。月末の残高を12か月分足すと、実在しない数字になる。期間で見るときは期末の値を使う
- どの方向にも足せない数字
- 勝率、単価、利用率。担当者ごとの勝率の平均は、チームの勝率ではない。分子と分母を別々に持ち、最後に割る
予実の比較は「ドリルアクロス」
予算も、1つのファクトとして見ることができます。実績は「明細1行」や「取引先×商品×月」、予算は「部門×商品×月」と、粒度が違います。この2つを、共有の切り口（部門・商品・月）でそろえて並べる操作を、Kimballは「ドリルアクロス」と呼びます。つまり予実の比較とは、粒度の違う実績と予算を、同じ物差しで並べることです。
成り立つ条件は、部門・商品・月の表を、実績側と予算側で共有していることです。予算そのものをつくるのは経営企画の仕事です。SFAと分析基盤の側では、実績を予算と同じ切り口で集計できるようにしておきます。
点検：静かな失敗を、目に見える失敗に変える
データの失敗で怖いのは、ダッシュボードが空になるような目に見える失敗ではありません。選択リストに新しいステージが追加され、その商談だけが集計の条件から漏れる。数字は少し減るだけなので、誰も気づかない。こうした「もっともらしい間違い」です。テストの目的は、この静かな失敗を、目に見える失敗に変えることです。
- 欠けていないか・重複していないか
- 商談の種別や明細の開始日が空でないか。法人番号が重複していないか
- ありえない値はないか・つながっているか
- ステージが決めた値のどれかか。施策の貢献の配分比率は合計100%か
- 新しいか・量はおかしくないか
- 週次の写真が今週も撮れているか。新規リードが急に半分になっていないか
SFAの入力規則・選択肢の制限・重複ルール。ただし厳しくしすぎない
分析基盤のテスト（一意・空でない・許容値・参照の整合）と鮮度のチェック
SFAとダッシュボードの合計の突き合わせ、急な変化の検知
入口だけで品質を守ろうとして必須項目を増やしすぎると、金額1円や「完了予定日はいつも月末」のような、形だけ正しい値が増えます。また、SFAの管理者がステージ名を変えた翌朝にダッシュボードがずれる、という事故は、送り手と受け手のあいだで「変えるときは事前に知らせる」という約束（データ契約）を結んでおくことで防げます。
配管：記録はSFA、数え直しは分析基盤、行動はSFA
SFAから分析基盤へは、元の形のまま全部を取り込み、加工は分析基盤の中で行います（ELT）。定義を変えたときに、過去を新しい定義で数え直せるようにするためです。取り込みには、Salesforce特有の落とし穴がいくつかあります。
- 削除・統合されたレコード
- 分析基盤に古いレコードが残り、件数が多くなる。削除済みのフラグも取り込み、マート層で除外する
- 数式項目
- 参照先の値が変わっても、レコードの更新日時は変わらない。更新日時で差分だけ取り込むと取り漏れる
- タイムゾーン
- 日時はUTCで保存されている。日本時間の深夜の受注が前日の日付になり、月末の受注が別の月に入る。日本時間に変換してから日付にする
分析の結果は、現場が毎日見ている画面に戻して初めて行動を変えます（Reverse ETL）。ヘルススコアや席の利用率、名寄せの結果など、行動に使う値だけを書き戻します。書き戻す項目は「正は分析基盤」と明記して読み取り専用にし、営業が手で直した値が次の同期で消える、という事故を防ぎます。
自己診断
- BIは、SFAに直接つながっていますか？
- 直接なら、結合による行の水増しと粒度の混在を疑う
- 営業・マーケ・CSで、同じ取引先の表を使っていますか？
- 違えば、部署ごとに顧客数が変わる
- 予算のデータは、実績と同じ部門・商品・月の切り口を持っていますか？
- 持っていなければ、予実はドリルアクロスできない
- SFAのレポートとダッシュボードで、受注の合計は一致していますか？
- 一致しないなら、出口での照合がない
- 月末の受注は、SFAと分析基盤で同じ月に入っていますか？
- 入っていなければ、タイムゾーンを疑う
よくある質問
- 最初から完璧なスタースキーマをつくる必要がありますか
- ありません。最初は1つの大きな表でも構いません。ただし、1つの表には1つの粒度だけを入れることと、バスマトリクスを1枚描いておくことは、最初から守ると手戻りが減ります
- 分析基盤をつくる前に、やっておくべきことはありますか
- SFAのデータの取り込みと、週次の写真の撮影だけは先に始めておくことをおすすめします。どちらも、始めた日より前にはさかのぼれないためです
ここで整えたデータをAIにどう渡すかはAI編、分析基盤の3層の考え方はデータレイク・マートの記事で扱っています。
シリーズ：営業データの「数え方」
- 1.基本編：6つの論点（顧客・商談・時間・お金・施策・指標）
- 2.応用編：組織・予測・価格・活動・利用データ
- 3.分析基盤編：設計図・点検・配管（この記事）
- 4.AI編：AIに営業データを渡す前に
- 5.運用編：権限・オーナー・入力・変更管理
問い
SFAのレポートとダッシュボードで、同じ「今月の受注」が違う数字になったとき、どちらが正しいかを議論していないでしょうか。それは、どちらかが間違っているというより、2つの表を同じ物差しで並べる設計と、それを毎日点検する仕組みが、まだないだけかもしれません。