技術トレンド

データ基盤・BIエンジニアの仕事と需要。ETLからELTへの移り変わりと、求められるスキル

データ基盤の作り方は、この数年で大きく変わりました。処理してから格納するETLから、格納してから処理するELTへ。この転換によって、求められるスキルの中心もサーバー運用からSQLとモデリングへ移っています。この記事では、データ基盤・BIエンジニアの具体的な仕事、モダンデータスタックと呼ばれる構成、案件で評価されるスキルを整理します。

データ基盤・BIエンジニアとは

社内に散らばったデータを集約し、分析や意思決定に使える形に整える職種です。担当範囲は大きく2つに分かれます。

• データ基盤（データエンジニア）／各システムからデータを収集し、データウェアハウス（DWH）へ集約するパイプラインを設計・実装する。品質の担保と運用も含む
• BI／集約されたデータをもとに、ダッシュボードやレポートを設計し、現場が使える形にする

案件によっては両方を1人が担うこともあれば、明確に分かれていることもあります。共通しているのは、技術だけでなく「そのデータが何を意味するか」という業務理解が必要な点です。売上データひとつ取っても、計上基準を理解していなければ正しい集計はできません。

ETLからELTへ、何が変わったのか

従来主流だったのはETL（Extract, Transform, Load）です。データを抽出し、専用のサーバーで変換処理をしてから、DWHへ格納します。DWHの計算資源が高価だった時代には、事前に整形して格納量を減らす方法が合理的でした。

現在広がっているのはELT（Extract, Load, Transform）です。生データをまずDWHへ格納し、DWH内のSQL処理で変換します。Snowflake、BigQuery、Redshiftといったクラウド型のDWHが、ストレージと計算処理を分離した構成を取っているためです。

この構成では、変換に必要な計算資源だけを一時的に増やせます。中間サーバーを自前で管理する必要がなくなり、インフラの運用負荷とコストの両方が下がりました。

エンジニアにとっての意味は明確です。サーバーの構築・運用スキルよりも、SQLでの変換ロジック設計とデータモデリングの比重が上がりました。 変換処理の中身がコードとして管理され、テストやレビューの対象になったことも大きな変化です。

モダンデータスタックの構成

クラウド前提のツール群を組み合わせた構成は「モダンデータスタック」と呼ばれます。役割ごとに分業されているのが特徴です。

← 横にスクロールしてご覧いただけます →

案件でよく見かけるのはdbt＋Snowflake（またはBigQuery）＋Airflowの組み合わせです。とくにdbtは、SQLによる変換処理をGitで管理し、テストとCI/CDの対象にできる点で、いまのデータ基盤案件の中心的な存在になっています。

近年は「リバースETL」と呼ばれる流れも加わりました。DWHで算出した集計結果を、SalesforceなどのSaaSへ書き戻す仕組みです。分析結果を現場のツールに戻すことで、データが実際の業務で使われるようになります。

データを層に分けて設計する

データ基盤の設計では、生データから利用可能な形まで段階を分けて管理するのが一般的です。層の呼び方はプロジェクトによりますが、考え方は共通しています。

• 生データ層／取り込んだままの状態を保持する。加工前の姿を残すことで、後から遡って検証できる
• 中間層／クレンジング、名寄せ、型の統一を行い、扱いやすい形に整える
• 利用層（データマート）／分析や可視化の用途に合わせて集計した状態。BIツールが参照する

層を分けておくと、問題が起きたときにどこで壊れたかを追跡できます。 データ品質の検証を各層の境目に置くことで、誤ったデータが下流へ流れるのを防ぐ設計が取られます。

案件で求められるスキル

• SQLでの複雑な集計・変換ロジックの実装
• クラウドDWH（Snowflake、BigQuery、Redshiftなど）の設計と運用
• dbtによる変換管理とテスト設計
• Airflowなどによるワークフローの構築
• Pythonによるデータ処理
• データモデリング（ディメンショナルモデリングなど）
• BIツールでのダッシュボード設計
• 対象業務のデータに対する理解

案件で差がつくのは、「再利用性と保守性を考えた設計ができるか」です。動くパイプラインを作ることと、半年後に他の人が引き継げるパイプラインを作ることは別物です。テストの自動化、命名規則、ドキュメントまで含めて設計できる人材は評価されます。

AI活用がデータ基盤に求めるもの

生成AIやMLの活用が広がるにつれ、学習データを準備するパイプラインの重要性が増しています。 特徴量の計算、学習用データの品質チェック、フィーチャーストアへの格納を自動化する仕組みは、AI基盤の必須要素になりつつあります。

AIモデルの精度は、投入されるデータの質に強く依存します。「AIを導入したいが、そもそも社内のデータが整っていない」という状況は珍しくなく、その整備こそがデータ基盤エンジニアの仕事です。AI案件の増加が、そのまま基盤側の需要につながっている構図があります。

キャリアの広げ方

専門を深める方向では、大規模なデータ基盤のアーキテクチャ設計を担い、要件定義から入れるポジションを目指します。ビジネス要件を技術要件に翻訳し、技術的な意思決定を主導できるようになると、関わり方が変わります。

AI・機械学習へ広げる方向では、MLOpsやフィーチャーパイプラインの領域へ進みます。データ基盤の知識がそのまま土台になるため、移行しやすい方向です。

業務側へ広げる方向もあります。SAPやSalesforceといった業務システムからデータを取り込む案件では、その業務そのものを理解している人材が重宝されます。基幹システムやCRMの知識とデータ基盤の技術を併せ持つ立場は、担い手が限られる領域です。