あるプロジェクトが始まったのは、十月の終わりだった。クライアントの担当者——東京・恵比寿にオフィスを構える中堅EC企業のデータ推進室長——は、会議室のホワイトボードにBigQueryのアーキテクチャ図を描きながら、こう言った。「まず基盤を作って、そこにデータを流し込めばいいんですよね」。その言葉を聞いたとき、筆者は静かに椅子を引いた。なぜなら、その問いかけ自体が、データ基盤プロジェクトが失敗する最もありふれたパターンの入り口だと知っていたからだ。ツールは手段であり、構造ではない。現場の業務フローとデータの発生源を把握しないまま器だけを作っても、それは空の倉庫を建てるに等しい。この記事では、BigQueryやSnowflakeといったクラウドデータウェアハウスを導入する前に、必ず整理しておくべき三つのことを、実際のプロジェクト経験をもとに丁寧に解説していく。

整理すべきこと その一 ── 誰が、何のために、データを見るのかを問い直す

データ基盤の設計を始める前に、最初に立ち返るべき問いはシンプルだ。「このデータを、誰が、何のために、いつ使うのか」。だが、この問いに明確に答えられる組織は驚くほど少ない。 前述のECクライアントのケースでは、当初「全社横断のダッシュボードが欲しい」という要件定義書が存在した。しかしヒアリングを重ねると、マーケティング部門が見たいのは週次のCAC（顧客獲得単価）の推移であり、物流部門が必要としているのはリアルタイムに近い出荷ステータスの確認であり、経営陣が求めているのは月次のコホート分析だ、ということが明らかになった。これら三者のニーズはそれぞれ、更新頻度も粒度もジョインするテーブルの構造も、まったく異なる。 「全社横断」という言葉は美しいが、設計の観点からは危険なあいまいさを含む。意思決定のサイクルが週単位の部門と月単位の部門を同一のデータモデルで扱おうとすると、どちらのニーズも中途半端にしか満たせないパイプラインが生まれる。まずユーザーを具体的な人物として特定し、彼らの意思決定の頻度・粒度・文脈を言語化することが、設計のあらゆる選択の根拠になる。

整理すべきこと その二 ── データの発生源と「一次記録」の場所を地図にする

データがどこで生まれ、どのシステムを経由して、どこに着地するのか——この流れを図に描き起こす作業を、筆者は「データの地形図を作る」と呼んでいる。これは単なるシステム構成図ではない。業務フローと照らし合わせながら、各データがいつ、誰の手によって、どのような文脈で記録されるのかを追跡する作業だ。 例えば、あるBtoBのSaaS企業では、商談の進捗をSalesforceに入力するのは営業担当だが、その同じ商談に紐づく技術的な要件定義はNotionに書かれており、契約締結後の請求情報は別の会計システムに存在していた。これら三つのシステムを「データ基盤に統合する」という話になったとき、問題になるのはETLの技術的な難易度ではなく、「商談ID」という共通キーが三システム間で一致していない、という業務上の事実だった。Salesforceでは自動採番、Notionでは営業担当が手入力、会計システムでは契約番号に差し替わっている。この不整合は、テクノロジーではなく業務プロセスの設計で解決するほかない。 一次記録がどこにあるかを特定することは、データの信頼性の根拠を特定することでもある。SnowflakeやBigQueryに流れてくる数字が「正しい」とはどういう意味か、その問いに答えられるのは、発生源を把握している者だけだ。

整理すべきこと その三 ── 「現在の業務フロー」と「あるべき業務フロー」を区別する

データ基盤を構築するプロジェクトで頻繁に起きる混乱のひとつは、現状の業務フローをそのままデータモデルに焼き付けてしまうことだ。現場をヒアリングすると、「このデータは毎週月曜日の午前中に担当者がExcelに手入力してから、マネージャーがSlackで送ってくる」という運用が発覚することがある。それを前提にパイプラインを設計すると、手作業という脆弱な環節がデータ基盤の一部として永続化されてしまう。 重要なのは、「現在の運用がそうなっているから」と「本来そうあるべきだから」を峻別することだ。データ基盤の構築は、業務プロセスを見直す好機でもある。ある小売クライアントでは、店舗スタッフが日次の売上をPOSシステムとは別にGoogleスプレッドシートにも手入力していた。二重入力の理由を追うと、POSシステムの管理画面が使いにくいため、本部への報告用に独自のフォーマットで再集計する習慣が数年前に根付いたのだとわかった。この運用をデータ基盤に取り込む前に、まずPOSのAPI出力を整備し、スプレッドシートへの手入力そのものをなくす——その業務改善を先行させたことで、その後のデータパイプラインは格段にシンプルかつ堅牢になった。

三つの整理を終えた後に、ようやくツールの話をする

上記の三点——ユーザーと意思決定サイクルの特定、データ発生源の地形図の作成、現状フローとあるべきフローの区別——を丁寧に行った後、初めてBigQueryとSnowflakeのどちらが適切かという比較が意味を持ち始める。 例えば、Google CloudのエコシステムにすでにGCP上のサービスが多く存在し、データエンジニアのチームがSQLに習熟しているならBigQueryの方向性は理にかなう。一方、複数のクラウド環境が混在し、将来的にデータをパートナー企業と共有するSecure Data Sharingの要件が見えているなら、Snowflakeの設計思想との親和性が高い。しかしこれらの判断は、前段の整理なしには「営業資料の読み比べ」にしかならない。 ツールを選ぶことは設計の終わりではなく、設計の始まりにすぎない。恵比寿の会議室でホワイトボードを消してもらい、代わりに「最初に誰のどんな問いに答えるか」を書き出すことから始めた例のプロジェクトは、最終的にBigQueryとdbtを中心としたシンプルなスタックで、六ヶ月後に本番稼働した。アーキテクチャ図を先に描いていたら、おそらくその倍の時間がかかっていただろう。

現場を歩くことが、最良の設計ドキュメントになる

データ基盤の設計において、最も価値ある情報は往々にして会議室の外にある。倉庫の担当者が棚卸しデータをどう扱っているか、コールセンターのオペレーターが顧客情報をどの順序で参照しているか、経理担当が月末に何時間かけて数字を突き合わせているか——こうした現場の実態は、システム構成図やER図には決して現れない。 筆者が実践しているのは、プロジェクト初期に必ず「現場観察」の時間を設けることだ。実際のオペレーションを横に座って見る、担当者が「あ、ここはいつもズレる」とつぶやく瞬間を聞き逃さない。そのつぶやきこそが、データ品質の問題の所在を指し示すことが多い。設計とは抽象を扱うことではなく、具体の中に潜む構造を見つけ出すことだ。ツールの選定はその後でいい。

データ基盤を作ることは、組織の記憶と判断の仕組みを作ることだ。だからこそ、最初の一歩を焦らないでほしい。ホワイトボードにアーキテクチャ図を描く前に、現場を歩き、業務を聞き、データが生まれる瞬間に立ち会う時間を持つこと——それが、後から何百時間もの手戻りを防ぐ、最も地味で最も確実な投資である。