STOP Inc.

データエンジニアの役割

2026.02.16
#ETL #データエンジニア #データガバナンス #データパイプライン #データプラットフォーム #データ基盤 #ビッグデータ
データエンジニアの役割

データエンジニアの役割

現場課題を解くデータエンジニアの仕事の芯

データエンジニアの価値は「分析が回る」状態を継続させる点にあります。華やかな可視化やモデルの裏で、データが欠けない・遅れない・計算がズレないことを保証するのが仕事の芯です。責務は大きく、収集（ログ/DB/外部SaaS）、モデリング（スキーマ/粒度/履歴）、変換（ETL/ELTとテスト）、信頼性（監視/SLO/再実行）、ガバナンス（権限/PII/監査）の5つに整理できます。

意思決定に効くのは、「何をどれだけ守るか」の閾値を事前に決めることです。曖昧な“頑張る”ではなく、次のような運用指標で管理します。

  • 鮮度SLO：主要マートはT+15分、日次マートはJST 06:00まで
  • 品質閾値：欠損率2%超はブロック、ドメインキー重複は失敗扱い
  • 遅延P95：バッチDAGは45分以内、ストリームは5分以内
  • コスト上限：マートごとに日次クエリ予算を設定し逸脱でアラート
  • 変更管理：スキーマ変更はデータ契約経由、影響範囲を自動検出

この地道な運用の積み重ねが、分析・機械学習・生成AIの成果の再現性を担保します。近年は開発効率向上のためにCopilotやChatGPT、Claude、Geminiを使い、SQLレビューやドキュメント生成、テストケースの提案に活用する現場も増えています。

アーキテクチャの現実解と選び方

「全部ストリーミング」「全部ウェアハウス」で解決しようとすると破綻します。妥当なのは、レイクハウスとDWHを役割分担させ、バッチとストリームを併用する設計です。永続層はParquet＋Iceberg/Deltaでスキーマ進化とタイムトラベルを担保、集計系はDWHにマートを載せる構成が運用しやすいです。オーケストレーションはAirflowやDagster、変換はdbt、分散処理はSpark/Flinkが定番です。

選定の基準は抽象ではなく閾値で切ります。

  • ストリームを選ぶ条件：鮮度要件が5分以内、もしくは外れ値検知・在庫同期など即時性でビジネス価値があると定義済み
  • パーティション/クラスタリング：日次粒度の事実テーブルはevent_dateでパーティション、user_idやshop_idでクラスタ
  • スキーマ戦略：上流ログはワイド化せずイベント単位、派生はstar schemaで分離、履歴はSCD2 or 有効期間で統一
  • PII対策：PIIは物理分離＋列暗号化、マスクビューを提供し、開発者はサンプル合成データで検証
  • コスト：ストレージは安価に冗長化、計算はスケールトゥゼロ可能なエンジン優先、頻用マートのみマテリアライズ

また、データ契約（イベント名・必須項目・型・遅延許容量）をプロダクト側と合意し、破ったらリリースをブロックします。ここを曖昧にすると、後段のBI/MLが不安定になり、結局高くつきます。

身近な企業活用例：地域ECアパレルの失敗と改善

地域型EC（EC比率70%）の例です。導入初期は、Webと受注DBを日次でDWHにロードし、マーケが都度SQLを書いていました。ブラックフライデーでアクセス急増時、在庫集計の遅延と重複計上が発生。広告入札は昨日データを参照しCPAが悪化、BigQueryのスキャン費用も跳ね上がりました。

原因は、イベントの粒度混在（セッションと受注の結合）、非正規化のまま直接BIへ供給、スキーマ変更の無通告です。改善では、次を実施しました。

  • 収集：アプリ/サイトのイベントをSnowplow系スキーマで統一、受注DBはDebeziumでCDC
  • 保存：データレイクにParquet＋Iceberg、原本は不可変、派生はdbtで段階化（stg→int→mart）
  • モデル：受注事実＋ディメンションの星型、カートはストリーム集計に切り出し（P95遅延3分）
  • 品質：主キー重複・金額整合・為替レートの当日適用をテスト化、SLO違反で広告連携を自動停止
  • ガバナンス：PIIは別テーブルに隔離、マスキングビュー経由で分析提供

運用面では、Copilotでdbtモデルのテスト雛形を量産し、ChatGPT/Claudeでドキュメントと血統図の説明文を整備。GeminiでSQLの実行計画のボトルネック候補もレビューしました。結果、在庫のP95鮮度は40分→4分、広告の入札は当日データで最適化できCPAが18%改善。月間クエリ費用は42%削減、計数の不一致アラートは四半期でゼロになりました。

ポイントは、技術の“盛り”ではなく、データ契約・粒度統一・マート分離という地味な原則に立ち戻ったことです。

運用に根づく作法と意思決定の基準

データ契約と品質SLO

  • 1イベント＝1目的、必須カラム・型・タイムゾーンは契約化
  • SLO例：主要KPIマートは06:00まで99.9%達成、違反時は影響サービスをセーフモード
  • 変更は「互換/非互換」を明示、非互換はフラグ付き併存→段階的移行

スキーマとテーブル設計の具体

  • 命名規約：raw.、stg.、int.、mart.で層を明示、テーブルは{domain}_{entity}_{granularity}
  • パーティション：event_date、クエリのフィルタ列でクラスタ、TTLで古い派生を自動削除
  • キー：数値IDは64bit固定、自然キーは正規化して比較、時刻はUTCで保持し表示時に変換

監視とインシデント対応

  • 監視：鮮度/行数/分布/ユニーク率/外部参照整合を自動テスト
  • アラート優先度：P1はKPIマート欠落、P2は派生の遅延、P3はデータドリフト
  • Runbook：リトライ回数、バックフィル手順、切替先（前日値/推定）の定義
  • コスト：クエリバジェットとタグで可視化、重いSQLはマテリアライズか列削減を検討

データエンジニアの役割は、単発のダッシュボードやモデルを越えて、組織が安心して意思決定できる足場を提供することです。データ解析プラットフォーム事業は、この足場をプロダクトとして継続運用する取り組みそのものです。自助的に使える基盤（テンプレート化されたDAG、自己登録できるデータ契約、観測性とコストのガードレール）を整え、チーム横断で同じ“道”を走れるようにすることが、結果としてビジネスの速度と品質を両立させます。

関連記事