データエンジニアの面接ガイド

面接官が評価するポイント

データエンジニアの面接質問サンプル

• コーディング部署ごとに2番目に高い給与を求めるSQLクエリを書いてください。
  良い回答が押さえる点

  • ウィンドウ関数DENSE_RANK使用
  • 部署ごとのパーティション分割
  • NULL処理と同順位の考慮
  • 効率的なJOINの回避

  サンプル回答を見る

  この問題では、部署ごとに2番目に高い給与を求めるSQLクエリを記述します。一般的な方法としては、ウィンドウ関数のDENSE_RANKを使用して部署内で給与の順位を付け、順位が2のものを抽出します。同順位がある場合はDENSE_RANKが連続した順位を付けるため、2番目に高い給与が複数人いる場合も正しく取得できます。サブクエリまたはCTEで順位を計算し、外部クエリでフィルタリングします。NULLの給与は通常考慮しません。パフォーマンス面では、部署と給与に複合インデックスがあると効率的です。この方法は標準SQLで動作し、可読性も高いです。

  -- 部署ごとに2番目に高い給与を取得
  WITH RankedSalaries AS (
    SELECT
      department_id,
      salary,
      DENSE_RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rnk
    FROM employees
  )
  SELECT department_id, salary
  FROM RankedSalaries
  WHERE rnk = 2;

• 技術面接ETLとELTの違いと、それぞれをいつ使うか説明してください。
  良い回答が押さえる点

  • ETL: Extract-Transform-Loadの順序
  • ELT: Extract-Load-Transformの順序
  • データ量と変換の複雑さによる選択
  • データレイク vs データウェアハウス
  • クラウド環境でのELTの優位性

  サンプル回答を見る

  ETL（Extract, Transform, Load）は、抽出したデータを変換してからターゲットにロードする伝統的な手法です。一方、ELT（Extract, Load, Transform）は、生データをまずロードし、その後ターゲットシステム内で変換を行います。ETLは、データ品質が重要で変換が複雑な場合や、ターゲットの処理能力が限られている場合に適しています。例えば、変換後にのみロードすることでストレージコストを抑えられます。ELTは、大規模データやクラウドデータウェアハウス（例：BigQuery, Snowflake）で威力を発揮します。これらのシステムは高い計算能力を持ち、変換をSQLで柔軟に行え、データ探索やアドホック分析が容易です。また、ELTはデータの生の状態を保持するため、後から別の変換を適用できます。近年はクラウドの普及によりELTが主流になりつつありますが、どちらを選ぶかはデータ量、変換の複雑さ、レイテンシ要件、組織のスキルセットに依存します。

• 技術面接安全に再実行できる冪等なパイプラインをどう設計しますか？
  良い回答が押さえる点

  • 冪等性の定義：何度実行しても同じ結果
  • ユニークキーとUPSERT（MERGE）
  • ウォーターマークとバッチ処理の境界
  • ステート管理と再実行可能なジョブ
  • モニタリングとアラート

  サンプル回答を見る

  冪等なパイプラインを設計するには、まず処理の各段階で冪等性を保証する必要があります。具体的には、データの書き込み時にユニークキーを使用し、INSERTではなくUPSERT（MERGE）を実装します。これにより、同じレコードが重複して挿入されるのを防ぎます。また、バッチ処理では、ウォーターマーク（処理済みの範囲を示す値）を利用し、ジョブが失敗しても同じ範囲を再実行できるようにします。例えば、処理済みの最大タイムスタンプを永続化し、次回はその後のデータのみを処理します。ステートフルな処理（例：集計）では、チェックポイントやWAL（Write-Ahead Log）を使用して状態を保存し、再実行時に復元できるようにします。さらに、データソースが変更される場合に備えて、イミュータブルなデータレイクに生データを保存し、変換ロジックをバージョン管理します。最後に、モニタリングとアラートを設定し、冪等性が破壊される異常を検知できるようにします。

• 技術面接ストリーミングパイプラインで遅延到着データをどう扱いますか？
  良い回答が押さえる点

  • ウォーターマーク（watermark）
  • 許容遅延（allowed lateness）
  • 遅延データの別ストリームへの出力
  • ウィンドウの再処理トリガー
  • イベント時間と処理時間の区別

  サンプル回答を見る

  ストリーミングパイプラインにおける遅延到着データ（late-arriving data）の扱いは、正確性とレイテンシのトレードオフです。一般的なアプローチとして、Apache FlinkやKafka Streamsなどのフレームワークでは、ウォーターマーク（watermark）を使用してイベント時間の進行を推定します。ウォーターマークより遅れて到着したデータは、latenessとして扱い、許容遅延（allowed lateness）以内であればウィンドウを再計算して結果を更新します。更新が難しい場合は、遅延データをサイドアウトプット（side output）に出力し、後でバッチ処理で修正します。また、トリガー（trigger）を設定して、遅延データが来たときに追加の結果を出力することもできます。重要なのは、システムがイベント時間ベースで動作し、処理時間に依存しないことです。設計時には、許容できるデータの古さと計算コストを考慮し、サービスのSLAに合わせてパラメータを調整します。

• コーディングウィンドウ関数を使って7日間の移動平均を計算してください。
  良い回答が押さえる点

  • ウィンドウ関数のROWSまたはRANGE指定
  • PARTITION BYとORDER BYの組み合わせ
  • 移動平均の計算式
  • フレーム指定（例：ROWS BETWEEN 6 PRECEDING AND CURRENT ROW）
  • NULLの扱いと境界条件

  サンプル回答を見る

  7日間の移動平均を計算するには、ウィンドウ関数を使用します。日付順に並べ替え、直近7日間の平均を求めます。例えば、テーブルに日付（date）と値（value）がある場合、以下のクエリで実現できます。PARTITION BYでグループ化（例：商品ごと）が必要ない場合は省略します。ROWS BETWEEN 6 PRECEDING AND CURRENT ROWで現在の行とそれ以前の6行を含むウィンドウを定義しますが、データに欠損があると正確でないため、RANGE INTERVAL '6' DAY PRECEDINGを使用する方が適切です。これにより、日付が連続していなくても過去7日間のレコードを対象にできます。境界条件では、最初の6日間はウィンドウサイズが小さくなるため、平均は少ないデータ数で計算されます。必要に応じて、データ数が一定以下の場合はNULLを返す処理も考慮します。

  -- 7日間の移動平均（日付ごとに過去7日間の平均）
  SELECT
    date,
    value,
    AVG(value) OVER (
      ORDER BY date
      RANGE BETWEEN INTERVAL '6' DAY PRECEDING AND CURRENT ROW
    ) AS moving_avg_7d
  FROM daily_sales
  ORDER BY date;

• システム設計EC企業の分析向けのデータウェアハウスを設計してください。
  良い回答が押さえる点

  • ファクトテーブルとディメンションテーブル
  • スタースキーマまたはスノーフレークスキーマ
  • 主要な分析指標（売上、注文数など）
  • データソースとETL/ELT設計
  • スケーラビリティとパーティショニング

  サンプル回答を見る

  EC企業の分析向けデータウェアハウスは、スタースキーマを基本に設計します。ファクトテーブルには、売上ファクト（販売明細）や注文ファクトを置き、ディメンションとして顧客、商品、日時、店舗、プロモーションなどを定義します。売上ファクトには、数量、単価、割引額、売上金額などのメジャーを含めます。商品ディメンションにはカテゴリ、価格帯、在庫状況などを保持し、顧客ディメンションにはセグメントや地域属性を持たせます。日時ディメンションは年、月、週、曜日など階層分析を可能にします。データソースは、トランザクションデータベース、Webログ、在庫システムなどから抽出し、ELTアプローチで生データをステージングにロードし、SQLで変換・集計します。スケーラビリティには、ファクトテーブルを日付や地域でパーティショニングし、クエリパフォーマンスを向上させます。また、サマリーテーブル（集計済みデータ）を作成して、ダッシュボードの応答を高速化します。データ品質を保つために、整合性制約や重複除去をETLプロセスに組み込みます。

• 行動面接見つけて修正したデータ品質の問題について教えてください。
  良い回答が押さえる点

  • STAR法による構成
  • 具体的なデータ品質問題の例
  • 原因分析と根本原因
  • 修正手順と再発防止策
  • ビジネス影響とチーム協力

  サンプル回答を見る

  以前、顧客マスタデータで重複レコードが存在する問題に取り組みました。Situation: ECプラットフォームの顧客データベースで、同一人物が複数のアカウントを持つデータが約5%存在し、キャンペーンの効果測定に誤差が生じていました。Task: 重複を特定し、マージするとともに、将来の重複を防止するプロセスを確立する必要がありました。Action: まず、氏名、メールアドレス、電話番号の類似度を基にファジーマッチングを行い、重複候補をリストアップしました。手動レビューで確認後、マスタリングルールを定義し、最新の更新日時が新しいレコードをマージ先としました。同時に、新規登録時に既存顧客とマッチングするフロントエンドのバリデーションを追加し、データ入力時点での重複を防止しました。また、重複検出と修復のパイプラインを定期的に実行するジョブを実装しました。Result: 重複率は0.1%未満に低下し、キャンペーンのROI計算精度が向上しました。この経験から、データ品質はプロアクティブな監視とシステム的な防止策が重要だと学びました。

• 行動面接パイプラインの信頼性と新規リクエストの優先順位をどうつけますか？
  良い回答が押さえる点

  • 技術的負債のバランス
  • SLAとサービスレベル目標
  • 信頼性向上施策の優先度付け
  • 新規リクエストのビジネスインパクト評価
  • 透明性とコミュニケーション

  サンプル回答を見る

  パイプラインの信頼性と新規リクエストの優先順位を付けるには、まず現在の信頼性レベルを定量的に把握します。ダウンタイムやデータ遅延の頻度をSLAと比較し、ギャップがあれば信頼性向上を優先します。新規リクエストは、ビジネスインパクトと工数を評価し、信頼性に直接影響するもの（例：モニタリング強化）は優先度を高くします。技術的負債を許容すると後で大きな問題になるため、利益率の高い改善は常に検討します。具体的な方法として、四象限マトリクス（重要度・緊急度）を使い、信頼性に関わる緊急タスクは即座に対応し、重要だが緊急でないものは計画的に実施します。また、ステークホルダーと定期的にコミュニケーションを取り、信頼性投資の必要性を説明し、合意を得ることが重要です。最終的には、データパイプラインの健全性を維持しつつ、ビジネス要件に応じた新機能をバランスよく提供するようにします。

レベルによる違い

ジュニア

確かなSQL、基本的なETL、範囲が明確なパイプラインタスクが問われます。

ミドル

モデリング、オーケストレーション、自立したパイプライン運用が問われます。

シニア

プラットフォーム/ウェアハウスのアーキテクチャ、信頼性、ガバナンスの責任が問われます。

準備の進め方

• SQLを磨きましょう — ウィンドウ関数と最適化はほぼすべての面接ループで出ます。
• パイプライン設計では、冪等性・リトライ・バックフィルから始めましょう。
• データ品質とリネージに自発的に触れましょう。本番での成熟度を示します。

よくある質問