データエンジニアリングとは・役割｜データエンジニアリング

🎓 レベル：基礎　|　重要度：A（必須）

📎 前提：なし（この章の出発点）　|　関連：バッチ処理とストリーム処理・現代データスタックの地図

要点（BLUF）

データエンジニアリングは、バラバラで汚い生データを、分析やMLがすぐ使える「整ったデータ」に変えて届ける仕事。分析の“下回り”であり、データチームの土台。
仕事の流れは 生成 → 取り込み → 保存 → 変換 → 提供 という「データエンジニアリング・ライフサイクル」で捉えると整理できる。各段に横断テーマ（データ管理・DataOps・オーケストレーション・セキュリティ）が貫く。
「モデルを作る人（データサイエンティスト）」ではなく「そのモデルに流すデータの蛇口と配管を作る人」。良い分析の8割は、実は届くデータの質で決まる。

概念 ── 「集める・整える・届ける」を担う

分析の現場でよく言われるのが「データサイエンティストは時間の8割をデータの準備に使う」という話です。その準備を専門に引き受け、再現性のある自動パイプラインにするのがデータエンジニアです。

要するに、データエンジニアリングとは 生データ（raw data）を、信頼できて・使いやすい・分析可能なデータに変換するシステムを設計・運用すること。一回限りの手作業ではなく、「毎日・毎時・リアルタイムに、勝手に・正しく動き続ける配管」を作るのが本質です。

仕組み ── データエンジニアリング・ライフサイクル

現代の標準的な整理（『Fundamentals of Data Engineering』）では、データは次の5段を流れます。

flowchart LR
    G["生成（ソース：DB・ログ・API・IoT）"] --> I["取り込み（Ingestion）"]
    I --> S["保存（Storage：DWH・レイク）"]
    S --> T["変換（Transformation：整形・集計）"]
    T --> SV["提供（Serving：BI・ML・分析）"]
    classDef u fill:#eef,stroke:#557
    class G,I,S,T,SV u

生成（Generation）：業務DB・アプリログ・外部API・センサーなど、データが生まれる源。ここはデータエンジニアの“管轄外”だが、形を知っておく必要がある。
取り込み（Ingestion）：源からデータを引き込む。バッチ（定期一括）か、ストリーム（来た端から）かを選ぶ（→ バッチ処理とストリーム処理）。
保存（Storage）：取り込んだデータを置く。OLTP向けのDB、分析向けのDWH／レイク（→ 第5章）。
変換（Transformation）：クレンジング・結合・集計・次元モデル化（→ 第2章・第4章）。
提供（Serving）：BIダッシュボード、機械学習の学習データ、分析クエリとして“使える形”で渡す。

そしてこの5段すべてを縦に貫く**横断テーマ（undercurrents）**があります。

flowchart TB
    L["生成 → 取り込み → 保存 → 変換 → 提供"]
    U1["データ管理（品質・ガバナンス・メタデータ）"] --> L
    U2["DataOps（自動化・監視・信頼性）"] --> L
    U3["オーケストレーション（依存と順序の制御）"] --> L
    U4["セキュリティ（権限・暗号化）"] --> L

これらは特定の段ではなく、全段にまたがる関心事です。本テキストでは品質→第4章、オーケストレーション→第7章、ガバナンス→第7章で扱います。

役割分担 ── 誰が何をするか

役割	主な関心	成果物
データエンジニア	配管・基盤・信頼性	パイプライン・DWH・整ったテーブル
データアナリスト	過去の説明・可視化	ダッシュボード・レポート
データサイエンティスト	予測・モデリング	機械学習モデル・実験
アナリティクスエンジニア	変換層（dbt等）	整形済みデータマート

データエンジニアは下流（アナリスト・サイエンティスト）の生産性を最大化するのが使命です。下流が「データを探す・直す」時間をゼロに近づけるほど、基盤として優秀ということになります。

なぜそうするか ── 再現性と分業

なぜ手作業ではなくパイプラインにするのか。(1) 再現性：同じ入力から同じ結果が何度でも得られる（→ べき等性と再実行）。(2) スケール：データ量が増えても人手を増やさず回る。(3) 分業：源の形が変わってもパイプラインの一部だけ直せばよい。一度作った配管は資産になり、組織のデータ活用の“複利”を生みます。

⚠️ よくある落とし穴

「分析できればいい」と一回限りのSQLで済ませる → 翌月には誰も再現できず、数字が合わなくなる。自動化・再現性を最初から設計に入れる。
ツール選びから始める → 「Sparkを使うべきか」より先に「バッチかストリームか」「どの段の課題か」を決める。ツールは手段。
データエンジニアが分析・モデリングまで抱える → 役割が肥大化し基盤がおろそかに。分析は機械学習／統計、ここは供給基盤と割り切る。

対応ラボ

なし（概念回）。次トピック以降でSQL・変換の実行検証に入る。