基礎知識

データ分析基盤の作り方。3つの層とETL・ELTの違い

データを活用したいという要望は多くありますが、そのための基盤づくりは頓挫しやすい領域です。この記事では、何をどう作るのか、なぜうまくいかないのかを整理します。

データ分析基盤とは

データ分析基盤とは、散らばったデータを集め、分析できる形に整えて、使えるようにする仕組みです。

多くの企業では、データが複数の場所に分散しています。基幹システム、販売管理、顧客管理、Webのアクセス記録、表計算ファイル。それぞれ形式も更新頻度も違います。

この状態では、横断的な分析ができません。「この施策で売上がどう変わったか」を見るために、毎回手作業で集める必要があります。

分析基盤は、この作業を自動化し、常に使える状態を保つための仕組みです。

3つの層で考える

分析基盤は、大きく3層で構成されます。

• ①収集・保管／各システムからデータを取り込み、そのまま貯める
• ②加工・整備／使える形に整える。表記の統一、重複の除去、結合
• ③活用／可視化、分析、機械学習への入力

①で貯める場所をデータレイク、②を経て整った状態をデータウェアハウスと呼びます。用途別に切り出したものをデータマートと呼ぶこともあります。

この層の分離が重要です。生のデータを残しておけば、後から別の目的で加工し直せます。最初から整形して保存すると、やり直しがきかなくなります。

ETLとELTの違い

データを移す処理には、2つの順序があります。

ETL。取り出し（Extract）、加工（Transform）、格納（Load）の順です。整えてから入れる方式で、保管する容量を抑えられます。

ELT。取り出し、格納、加工の順です。生のまま入れて、後から加工する方式です。

近年はELTが主流になりつつあります。クラウドの保管費用が下がり、処理能力も上がったため、生のまま貯めておく方式が現実的になりました。

利点は、後から目的を変えられることです。ETLでは加工時に捨てた情報を、後から使うことができません。

構築の進め方

実際に作る場合の順序を示します。

第一に、目的を1つ決める。「何を知りたいか」を先に決めます。すべてのデータを集めようとすると、いつまでも完成しません。

第二に、必要なデータだけ集める。目的に必要なものに絞ります。

第三に、小さく作って見せる。最初の可視化を早く出し、使ってもらいます。ここで要望が具体化します。

第四に、対象を広げる。使われることが確認できてから、範囲を拡大します。

最初から全社の全データを対象にする計画は、ほぼ失敗します。データの整備だけで数年かかり、その間に何も価値を出せません。

うまくいかない理由

構築が頓挫する典型的な原因を挙げます。

• データが汚い／表記の揺れ、欠損、重複。整備に想定の数倍かかる
• 使う人が決まっていない／作ったが誰も見ない。最も多い失敗
• 目的が曖昧／「データを活用したい」だけでは、何を作るか決まらない
• 元データの管理者と合意できない／他部署のシステムからデータを取れない
• 更新が止まる／作った人が異動し、誰も維持できなくなる

2つ目が本質的な問題です。技術的に立派な基盤でも、意思決定に使われなければ費用だけがかかります。誰が、どの判断のために、いつ見るのかを先に決めるべきです。

求められるスキル

この領域で働くために必要なものを整理します。

SQL。必須です。大量データを扱うため、性能への理解も求められます。

データモデリング。分析しやすい構造を設計する力。業務の理解が前提になります。

基盤の知識。クラウド上の分析基盤、処理を自動実行する仕組み。

可視化の技術。BIツールを使い、見て判断できる形にする。

そして業務理解。何を見れば判断できるかを知らなければ、有用な基盤は作れません。技術より、この点が差になります。

なぜ需要が伸びているか

この領域の需要が増えている理由を整理します。

第一に、判断をデータに基づいて行う流れが広がっています。経験と勘だけでは説明できない場面が増えました。

第二に、AIの活用です。機械学習も生成AIの社内活用も、整ったデータがなければ始まりません。AI導入の障害が、実はデータの整備であることは多くあります。

第三に、扱えるデータ量が増えたことです。クラウドの普及で、以前は捨てていた記録も保管できるようになりました。

単価は月額70〜110万円の範囲が中心で、設計まで担える場合は上限に近づきます。この数字は民間各社の集計で、公的統計ではありません。

データの品質という壁

構築で最も時間がかかるのが、この部分です。

典型的な問題を挙げます。同じ会社が「株式会社A」「(株)A」「A」と3通りで登録されている。日付の形式が部署ごとに違う。必須のはずの項目が空になっている。退会した顧客の記録が残っている。

これらを機械的に統一する作業が、前処理です。実務では全工程の大半を占めることも珍しくありません。

根本的な対策は、入力の段階で防ぐことです。選択式にする、形式を検証する、重複を検知する。ただし既存システムの改修が必要になるため、実現は容易ではありません。

現実的な方針は、整備のルールを決めて自動化し、それでも残る例外を記録することです。完全を目指すと終わりません。

誰が管理するか

技術より難しいのが、組織の問題です。

データの所有者が不明確。他部署のシステムからデータを取りたいが、誰に許可を得ればよいか分からない。実際によくある障害です。

定義が揃っていない。「売上」が部署によって意味が違う。税込か税抜か、計上のタイミングはいつか。数字が合わない原因の多くはここにあります。

対策として、用語の定義を文書化します。何をもって何と呼ぶかを揃える作業です。地味ですが、これがないと分析結果が信用されません。

管理の責任者を決めることも必要です。データごとに、誰が正しさに責任を持つのかを明確にします。

技術的に優れた基盤でも、この整理がなければ使われません。