データ基盤に投資すべきか ― 整える層が無いと何が壊れるか

「データ基盤に投資すべきか」という問いは、たいていツールと予算の問題として持ち込まれますが、本質は診断の問題です。問うべきは「いくらかけるか」ではなく、「ローデータを使える形に整える層が、すでに壊れていないか。そして、それが下流でやりたいこと（予測・因果・パーソナライズ）の上限を抑えていないか」です。この記事では、整える層が無いと具体的に何が壊れるのか、いつ投資すべきで・いつはまだ早いのか、リターンをどう見るかを、匿名化した実在のB2B案件を例に、決裁者が自社に当てはめて判断できる形で整理します。

扱うのは新しいツールの話ではありません。GA4のBigQuery Export、広告各媒体、CRM、ECが別々のスキーマで降ってくる——それを毎回その場のSQLとスプレッドシートで突き合わせている状態の、見えているコストの話です。

「分析がうまくいかない」の正体 ― たいてい手法ではなく土台

高度な分析が当たらない、レポートが信用されない、という相談の多くは、手法を変えても解決しません。原因がその下の層、つまりローデータを「使える形」に整える工程の不在にあるからです。

データの流れは、ローデータ → staging（ローデータに最初に触れて正規化する層）→ intermediate（再利用する結合・集計）→ marts（事業の語彙で表現した最終形）と積み上がります。整える層とは、このうち真ん中の変換を、その場しのぎのクエリではなく、定義を一元化した恒常的な仕組みとして持つことを指します。ここが無いまま上に分析を載せると、何を載せても土台ごと揺れます。問題は分析者の腕ではなく、立っている地面のほうです。

整える層が無いと壊れる4つのもの

抽象論にしないために、症状で並べます。次の4つは、整える層が無い組織でほぼ例外なく起きます。

1. 同じKPIなのに数字がぶれる（定義の散逸）

「CVは何を数えているのか」「アクティブユーザーの定義は」——同じ言葉が、人やツールごとに別の計算式を指している状態です。定義が各スプレッドシートと各クエリに散らばっているので、突き合わせると数字が合いません。会議の時間が、意思決定ではなく「どの数字が正しいのか」の論争に溶けていきます。

2. 分析が再現できない・属人化する

重要な集計が「あの人のスプレッドシート」「あの人しか触れないクエリ」に貼り付いている状態です。私はこれを秘伝のタレSQLと呼んでいます。担当者が抜けた瞬間に再現できなくなり、資産が組織ではなく個人に紐づきます。属人化したものは資産に見えて、実際には負債です。

3. 壊れても気づかない（サイレント障害）

上流の媒体側がスキーマを変えた、ある日からデータが半分欠けている——こうした異常が静かに下流へ流れ、間違った数字のまま意思決定に使われます。気づくのは、たいてい予算を動かした後です。テストが無いシステムは、壊れたことを誰にも教えてくれません。

4. 下流の上限が頭打ちになる

予測（リードスコアリング）も、因果（施策が本当に効いたかの測定）も、活性化（セグメントへの自動配信）も、整ったマートがある前提で初めて成立します。つまり、入ってくるデータを整える工程が不完全なままでは、どれだけ高度な分析やAIツールを足しても、意思決定に使える数字は増えません。整える工程の出来が、その先でできることの上限を決めてしまうからです。ここを飛ばして分析側に投資すると、信用できないデータの上に、信用できないモデルを積むことになります。

自社が「壊れている」かを見抜くチェック

投資の是非を決める前に、いま壊れているかを診断します。会議や現場で起きている症状から逆算するのが速いです。

一つでも強く当てはまるなら、整える層はすでに壊れていると考えてよいです。複数当てはまるなら、それは「いつか整える」課題ではなく、いま意思決定の質を毀損している現役の負債です。

一次データで見る ― 整える層が無いと、真のCACすら出せない

抽象論を一つ地に着けます。以前に扱った都内のオフィス仲介の受託案件（匿名化・数値はレンジで丸めています）では、真のCAC（実際の成約あたりの獲得コスト）を出すために、媒体の出稿データ・サイト上の行動・CRM上の実成約を、一本に突き合わせる必要がありました。

このとき整える層が無いと、突合は毎回その場限りのSQLになり、誰かが書いて、誰も再現できず、媒体側の仕様変更で静かに壊れます。さらに、成果のうち手前の行動まで辿れる割合（接合率と呼んでいます。詳細は記述・予測編）を継続して監視することもできません。接合率が分からなければ、その先の予測モデルが使える実弾が成果の何割なのかも分からない。整える層は、こうした「測定の上限を測る」こと自体を可能にする土台でもあります。

では、いつ投資すべきか ― 発動条件と「まだ待て」の線引き

ここは正直に書きます。整える層は、早すぎると過剰投資です。売る側はいつでも「今すぐ基盤を」と言いますが、規模に合わない投資はオーバーエンジニアリングで、保守だけが残ります。

発動条件は「データが多いから」ではなく、「突合が常態化したか」「定義のぶれが意思決定を歪めたか」「下流に進みたいのに土台が無いか」で判断します。逆に、これらが揃うまでは、整える層に資源を割くより、いま手元のデータが素直に許す範囲（真のCACの記述、簡単なスコアリング）に集中するほうが筋がよいです。

投資のリターンをどう見るか

整える層の投資は、直接の売上増として現れにくいので、ROIが見えづらいのが難点です。リターンは別の四つの形で返ってきます。

速度——毎回の手作業の突合が消え、新しい問いに数分で答えられるようになる。信頼——「どの数字が正しいか」の論争が終わり、会議が意思決定に戻る。再現性——分析が個人から組織の資産へ移り、人が抜けても壊れない。オプション——予測・因果・活性化という下流の選択肢が、初めて現実的に解禁される。

そして見落とされがちなのが、現状維持のコストです。秘伝のタレSQLの維持費、手戻り、そして間違った数字で予算を動かした損失は、どの帳簿にも計上されませんが実在します。投資判断は「基盤にかける額」と「この隠れコストを払い続ける額」の比較です。後者が前者を上回り始めた点が、投資の損益分岐です。

内製か、外注か、段階導入か

規模が小さいうちは、整える層は専任チームを置かなくても、少人数——場合によっては一人——で回せる領域になりました。マネージドのデータウェアハウスと、変換をソフトウェア工学の作法（version管理・テスト・系譜）で書く仕組みがあれば足りるからです。AIコーディング（私の場合は Claude Code）で変換モデルの生成・テスト追加・リファクタが速くなったことも、内製の現実性を一段押し上げています。ただし、これは「魔法で一瞬」という話ではなく、設計の良し悪しがそのまま効くという、ふつうの工学の話です。

専任を置けず規模だけ大きいなら、設計と初期移行を外注し、運用は内製へ移管するのが現実的です。いずれにせよ避けたいのは、いきなり全社のデータを一気に整えようとすることです。最も突合に苦しんでいる一つの領域——たとえば前述の真のCAC（媒体×サイト×CRM）——から、再利用できるマートを一つ作る。価値連鎖（計測 → 整える → 作る → 測る → 活性化）の順に、計測が整っているところから一段ずつ上げるのが、失敗の少ない入り方です。

意思決定への接続（まとめ）

投資判断のフィルタは単純です。いま整える層が壊れているか、そして下流に進みたいか。どちらかがYesなら投資の検討に値し、どちらもNoならまだ早い。基盤は手段であって目的ではないので、「動かす意思決定がそこにあるか」を最後の関門に置いてください。整える層は地味で、売上の数字には直結しません。けれど、その上に立つすべての分析の信頼性は、この層の有無で決まります。

章末チェックリスト

• 同じKPIで「数字が違う」が起きていないか（定義は一元化されているか）
• 重要な集計が、特定個人のスプレッドシートに依存していないか
• データの異常を、事後でなく自動で検知できる仕組みがあるか
• 予測・因果・活性化など下流に進みたいのに、土台が無くて止まっていないか
• 投資の発動条件（突合の常態化・定義のぶれ・個人依存・下流志向）が揃っているか
• 現状維持の隠れコスト（手戻り・誤判断・属人化）を、投資額と比べたか

---

ここまでは「投資すべきか・何が壊れるか」という決裁者の判断です。整える層を実際にどう設計・実装するか（dbtによる3層・テスト・系譜、そしてマートの組み方）は、対になるLab連載で具体的に扱います（本記事のbridge先＝なぜSQLは「秘伝のタレ」になるのか）。土台の上で「何を測り、何を動かすか」を考える段階は、記述・予測編へ。