小さく始めるならどこから？データ基盤の役割と必要になるタイミング

データ基盤を構築するとき、最初に決めるべきなのはデータを使って変えたい判断と、その判断に必要な仮説です。製品や保存先ではありません。

扱うデータや運用が限られていれば、スプレッドシートでも始められます。一方、データの取得・統合・更新・加工・提供を同じ条件で続ける必要があるなら、データ基盤が選択肢に入ります。

この記事では、データ基盤の役割と構築手順、スプレッドシートから移るタイミングを整理します。

なお、仮説を立ててデータを集め、分析し、施策を変えて成果を測る一連の流れを、この記事ではデータ活用と呼びます。データ基盤は、その流れの一部を支える仕組みです。

データ基盤の構築が必要になる背景

データ基盤の構築が必要になる背景には、「データを使って業務上の判断や施策を変え、成果につなげたい」という目的があります。

構築にあたって製品比較や現在保有しているデータの棚卸しから始めると、「何のために構築するのか」が曖昧になりがちです。

これを防ぐために、「どの判断を速くしたいのか」「どの施策を見直したいのか」を決めるといいでしょう。

データ基盤（データ分析基盤）とは何か

では、その判断や施策を支える仕組みとしてのデータ基盤は、具体的に何をするものなのでしょうか。

データ基盤とは、業務システムやアプリなどからデータを継続して取得し、同じ単位と定義で統合・保存する仕組みです。（データ分析基盤と呼ばれることもあります。）

つまりデータ基盤は、「同じ単位と定義で揃える」ことを軸にした仕組みです。裏を返せば、何を判断したいかが決まっていなければ、どのデータをどの単位で揃えるべきかも決まりません。

だからこそ、製品比較より先に「どの判断を速くしたいのか」を決める必要があります。

データ基盤を構築するメリット

データ基盤を構築すると、仮説の検証に必要なデータを、同じ条件で繰り返し利用できるようになります。具体的には下記のようなメリットがあります。

• 複数のシステムからデータを継続して取得できる
• 顧客や商品など、共通の単位でデータを統合できる
• 指標の定義や分析ロジックを管理できる
• 同じ条件で分析を繰り返せる
• データの取得・更新を自動化できる
• 複数の部署で同じデータを利用できる
• BIやAIへ、定義をそろえたデータを継続して提供できる
• 施策前後の変化を同じ条件で比較できる

BIとAIは、基盤から受け取ったデータを利用する

データ基盤は、データの取得、統合、加工、提供を担います。BIは基盤から受け取ったデータを可視化し、AIは決められた用途に応じて参照します。分析結果を受けて誰がどの施策を実行するかは、基盤とは別に決めます。

データ活用にあたって考えるべき課題（5つの壁）

速くしたい判断を先に決めたとしても、それが成果に届くまでには複数の詰まりどころがあります。

データ基盤が担う範囲を見定めるために、まずデータ活用が止まる場所を「5つの壁」として分解していきましょう。

データ活用の5つの壁とは、仮説、データ、分析、行動、成果の壁のことです。

データ基盤が主に担うのは、この5つのうちのデータの壁です。しかし、扱うデータの種類は仮説で決まります。

この記事では、基盤の設計と利用に直結する仮説の壁とデータの壁を中心に扱います。

• 仮説の壁：何を変えたいのか、何を確かめれば判断できるのかが決まっていない状態です。たとえばマーケティング・ミックス・モデリング（MMM）の実施が先に決まり、分析開始後に「MMMで何を明らかにするのか」という議論へ戻ります。
• データの壁：仮説の検証に必要なデータを取得できない、またはデータ同士をつなげられない状態です。たとえばGoogle Analyticsのアクセスデータから商談までを追おうとしても、顧客やリードをひも付ける項目がなく、グラフを作れません。
• 分析の壁：目的に合う分析方法や表現を選べず、数字から判断材料を得られない状態です。たとえば対象間の比較が目的なのに、差を読み取りにくいグラフを選んでしまいます。
• 行動の壁：分析結果を誰がどの判断に使うのかが決まっておらず、施策や業務が変わらない状態です。数値の根拠や使い方が共有されていないと、現場は分析結果を判断材料として使えません。
• 成果の壁：施策の実行後に結果を測り、原因を分析して修正するサイクルが続かない状態です。一度の施策で成果が出なかっただけで、データ活用自体が止まることがあります。

データ基盤の設計前に決める仮説とは

データ基盤の中身を左右するのは「仮説の壁」です。ここが決まらないと、どのデータをどの単位で持つかも決まりません。

仮説を立てるにあたって、最初に決めるべき事項は、何を把握し、どの判断に使うかです。

私がデータ活用の相談を受ける中でも、基盤に載せる指標を決める段階になってから、「この指標が変わったら、どの判断を変えるのか」という議論に戻ることがあります。複雑な指標を加える前に、会社にとっての意味と使い道を確認する必要があります。

例えば、経営者への報告や現状把握が目的なら、確認する指標と頻度を定めます。施策の検証が目的なら、「何が起きていると考えるか」「結果に応じて誰が何を変えるか」まで仮説に含めます。

現場では、現在取得できるデータから入ることもあります。「この数字を出せる」「加工すれば別の指標も作れる」と考えるのです。このやり方は、探索の入口にはなりますが、算出できることを採用理由にすると、数字を出すことが目的に変わるので注意が必要です。

仮説が違えば必要なデータも変わる：登録月と登録後日数の例

仮説が違えば、必要なデータも変わる例として、会員登録型のサービスをご紹介します。

使う生データは、どちらも登録日とアクセス履歴です。目的は、「経営者への報告や現状把握」と「施策の検証」としました。

経営者への報告や現状把握は登録月でまとめ、施策の検証は登録後の日数順にしています。どちらが正しいという話ではなく、確かめたいことが決まって初めて軸が決まります。

さらに、施策の検証では、登録日とアクセス履歴だけではデータが足りません。機能の利用履歴、解約の有無、ユーザー属性が必要になります。仮説によって変わるのは集計の軸だけでなく、基盤に持たせるデータの範囲そのものです。

同じデータを使っても、集計方法、BIの出力、その後の行動は変わります。

仮説からデータ基盤を構築する6つの手順

決めた仮説を基盤の要件へ落とすまでには、次の6つの手順があります。

この順序で考えると、現在取得できるデータをすべて集めるのではなく、変えたい判断に必要な範囲から構築できます。

1. 変えたい判断と、検証する仮説を決める
2. 仮説を検証する指標と、分析する単位を決める
3. 指標の算出に必要なデータと保存場所を確認する
4. 足りないデータの取得経路を作る
5. 取得したデータを統合し、分析できる形へ加工する
6. 更新方法と、BI・AIなどの提供先を決める

手順1から4までは、仮説や指標を決め、必要なデータを確認・取得することが中心です。また、手順1は、先ほどまでお話ししていた「何を確かめ、どの判断に使うか」にあたります。

手順5の「取得したデータを統合し、分析できる形へ加工する」部分は、整理の仕方に定石があります。

ディメンショナルモデリング：データを「業務上の出来事」と「比較するための情報」に分けて整理する

ディメンショナルモデリングは、分析に使うデータを「業務上の出来事」と「比較するための情報」に分けて整理する方法です。

マーケティングであれば、Webサイトへのアクセス、コンバージョン、商談、受注などの出来事が「ファクト」に当たります。顧客、企業、商品、流入経路、キャンペーン、日付など、比較に使う情報が「ディメンション」です。両者をひも付けると、同じ出来事を顧客別、商品別、流入経路別に分析できます。

先に2つの役割を分けておくと、元データのテーブル名や保存形式に引きずられなくなります。BIやAIへは、元システムの都合ではなく、顧客、商品、商談、受注など、ビジネス側が理解しやすい単位でデータを渡せます。

先ほど例に出した「解約ユーザーと継続ユーザーのアクセス推移を比べる」という仮説は、アクセスというファクトを、解約の有無というディメンションで切ることに対応します。

なお、具体的な設計方法は別の記事で紹介する予定です。

スプレッドシートがデータ基盤として足りる条件

ここまでは、基盤を構築するとどこまでできるかを見てきました。

「概要は理解できたものの、本格的なデータ基盤の構築はハードルが高い。スプレッドシートはデータ基盤の代わりにならないんだろうか。」という方もいらっしゃるのではないでしょうか。

扱う範囲が限られているなら、スプレッドシートでもデータの保管、加工、集計、可視化を始められます。

スプレッドシートで始めるかデータ基盤を構築するかの定量的な判断フローは以下の図のようになります。

また、観点としては以下の項目を押さえておきましょう。

表の数字は、超えたら必ずデータ基盤を構築するという基準ではありません。数式や権限管理が複雑なら10万行未満でも基盤が合います。一方、値を保管するだけなら10万行を超えてもスプレッドシートで扱える場合があります。

Googleスプレッドシートの仕様は、1ファイルあたり1,000万セルまたは18,278列が上限です。ただし、これはファイルを作れる上限であり、快適に運用できる目安ではありません。数式、条件付き書式、外部参照が増えるほど、上限より前に動作が遅くなります。この点も押さえておきましょう。

データ基盤が必要になるタイミング

同じデータを手作業で扱い続けるのが難しくなってきたら、データ基盤を検討しましょう。

判断の材料は2種類あります。1つは、いますでに起きている状態です。

• データ量が増え、処理や更新に時間がかかる
• 複数のシステムから手作業でデータを集めている
• 更新作業が特定の担当者に依存している
• 計算式が複数のセルやシートに分散している
• 指標の算出方法を担当者以外が説明できない
• 部署ごとに同じ指標の定義が異なる

もう1つは、今後必要になる要件です。

• 権限管理や変更履歴の確認が必要になる
• 複数の部署やサービスで同じデータを利用する
• BIやAIへ継続してデータを提供する

前者が一つでも続いているか、後者が見えているなら、データの取得・統合・加工をスプレッドシートから切り離したほうが運用しやすくなります。

条件が見えているなら、最初から基盤を選べる

逆に言えば、以下のような条件が最初から見えているなら、スプレッドシートを経由する必要はありません。

• 扱うデータが大量
• 複数システムとの連携
• 更新の自動化
• BI・AIへの提供

小さく始めるとは、必ずスプレッドシートを選ぶことではなく、対象とする判断、データ、利用者を絞ることです。

よくある失敗と回避策

データ基盤の構築で起きやすい失敗は、着手するときと運用が続いたときで分かれます。

製品（ツール）比較から始め、比較する軸が決まらない

製品の選定そのものは重要です。ただし、必要な機能は扱うデータの種類と量、管理する担当者によって変わります。何を判断したいかが決まっていない段階では、比較する軸も決まりません。

回避策は、変えたい判断を一つ決め、そこから必要な範囲を逆算することです。判断が決まれば、必要なデータと量、更新頻度が絞れ、比較すべき軸も見えてきます。

出せる数字から指標を決めてしまう

算出できることを理由に指標を決めると、数字を出すこと自体が目的に変わります。実態を反映しない独自のロジックが作られたり、意味のない目標設定につながったりします。

回避策は、指標の意味と、結果を使う業務を先に確認することです。その指標が売上のどの要因に対応するのかを確かめます。

運用が続き、計算の根拠を追えなくなる

スプレッドシートで運用を続けた場合には、計算ロジックが少しずつ追いにくくなっていきます。

回避策は、分析ロジックの管理が必要になった時点で基盤を検討することです。簡単なロジックなら、スプレッドシートの柔軟性を活かせます。

ただし、「修正が重なって説明に手間がかかるようになった」「ロジックを把握しているのが社内で数人だけになった」このどちらかが起きたら、移行を検討する時期です。

データ基盤の構築を何から始めるか

最初にするのは、データを使って変えたい判断を一つ言葉にすることです。そこから検証する仮説を置き、必要なデータと運用を逆算します。製品の比較は、その後です。

基盤の範囲を決める際は、次の4点を確認します。

1. 何を確かめ、結果をどの判断に使うのか
2. 必要なデータはどこにあり、量と更新頻度はどれくらいか
3. 同じ定義と分析ロジックを、誰がどのくらい繰り返し使うのか
4. BIやAIを含め、どの業務やシステムへデータを提供するのか

4点がすべて決まっていなくても、変えたい判断が一つあれば、必要なデータと構築範囲を整理できます。

マーケティングデータ基盤構築のご紹介

月曜日のトラでは、仮説の整理、必要なデータの選定、取得・加工方法の設計、データモデリング、データ基盤やBIの構築、AIへ提供するデータの整備まで支援しています。スプレッドシートで続けられるか、基盤へ移るべきかを決める段階からご相談いただけます。

月曜日のトラのマーケティングデータ基盤構築

関連セミナーアーカイブのご案内

この記事と近いテーマのセミナーを、アーカイブでご覧いただけます。

AI活用を見据えたデータ基盤の現状チェック

（2026年5月21日開催アーカイブ視聴可）

AI活用を見据えたデータ基盤の現状チェック

※ セミナーアーカイブ視聴にはお申し込みが必要です。メールアドレスをご登録いただくと、動画のURLをお送りします。

メールマガジンで最新情報をどうぞ

月に2回、メールマガジンを配信しています。各メンバーによるコラムや書籍紹介、近日開催のセミナー情報、アーカイブ配信のご案内をしております。

お昼休み11:30頃に配信。さっと読めるお手軽メールマガジンです。ご興味がありましたらこちらからご登録下さい。

月曜日のトラメールマガジン登録ページ

参考サイト一覧

この記事の内容理解を助ける公式サイトを一覧にしています。

• Googleドライブに保管可能なファイル（Googleドライブ ヘルプ）
• IMPORTRANGE（Googleドキュメント エディタ ヘルプ）
• Googleスプレッドシートのパフォーマンスを改善する（Googleドキュメント エディタ ヘルプ）
• スキーマとデータ転送の概要（Google Cloud）