データエンジニアは、業務システムなどにあるデータを集め、分析に使える形へ整え、継続して届ける仕組みを扱う職種です。Microsoft Learnの職務説明でも、データの統合・変換と、要件に合うデータパイプラインや保存先の設計・支援が挙げられています。
「SQLを書く仕事」「クラウドを使う仕事」だけでは、業務のつながりが見えません。この記事では、架空の売上集計を題材に、入力データから利用者へ届くまでの仕事を説明します。職務を検討する技術者が、自分の経験と求人の担当範囲を比べるための解説です。
データを届ける流れの、どこを担当するか
例えば、複数店舗の注文情報から日別売上を作る場合、次のような経路を考えられます。
店舗の注文データ
→ 取込用の保存領域
→ 型・重複・更新情報の整形
→ 集計に使うテーブル
→ 分析担当のレポートこれは説明用の構成で、特定企業の実例ではありません。データエンジニアの担当範囲を考えるときは、各矢印について「何が届き、どの条件で加工し、失敗したらどこからやり直すか」を言えるようにします。
英国政府のData engineer職務定義には、業務システムと分析基盤をつなぐデータフロー、入力から出力への対応表、ETL処理、再利用できるデータの提供などが含まれます。ETLは抽出・変換・格納の処理です。この枠組みは職務を理解する参考であり、日本のすべての求人で同じ範囲を担うという意味ではありません。
架空の売上集計で見る、設計から運用まで
1. 「売上」の意味と必要な鮮度をそろえる
最初に、利用者が何を判断したいかを聞きます。「日別売上を見たい」だけでは、注文日と入金日のどちらで集計するか、取消しをどう扱うか、いつまでのデータを含めるかが決まりません。
この例では「店舗の営業日単位で、取消しを除いた注文金額を翌朝確認したい」と仮定します。ここから、集計の日付、状態、締め時刻、訂正分の扱いを整理します。データエンジニアだけで会計上の意味を決めず、業務担当者と合意して仕様へ残します。
2. 入力と出力の対応表を作る
次の表は、設計を相談するための例です。
| 入力項目 | 出力での使い方 | 決めておくこと |
|---|---|---|
| 店舗ID・注文ID | 注文を識別するキー | 注文IDは店舗間でも一意か |
| 注文日時 | 営業日を求める材料 | 時間帯、営業日の切替時刻 |
| 金額 | 集計の対象 | 税込み・税抜き、通貨、数値の型 |
| 注文状態 | 集計対象を絞る条件 | 取消し・返品・保留の扱い |
| 更新日時 | 変更された注文を取り込む材料 | 同時刻更新や遅延データの扱い |
項目名が同じでも、意味が同じとは限りません。「金額」が一方では単価、他方では行全体の合計なら、そのまま足せません。対応表には変換式だけでなく、判断の根拠と確認先も残します。
3. 処理と検証を実装する
この例なら、取得した原票を残し、型の変換、集計対象の抽出、注文の識別、日別集計を段階に分ける方法が考えられます。最初から一つの大きな処理にせず、途中結果を確かめられる単位にします。
例えば、取込件数が100件なのに変換後は80件なら、残り20件が取消しなのか、型の不一致で除外されたのかを区別できるようにします。除外理由を記録せず捨ててしまうと、利用者が集計値の変化を説明できません。
重複への対応も、単に「同じ行を消す」では足りません。同じ注文の新旧版が届くなら、どちらを採るかが必要です。店舗IDと注文IDをキーに更新版を採用する、といった設計を業務上の訂正ルールと合わせて決めます。これは設計例であり、すべてのシステムに共通する正解ではありません。
4. 失敗した処理を安全に再開できるようにする
運用では、通信の中断や入力形式の変更を想定し、失敗した範囲を特定できる記録を作ります。この売上例なら、処理日、対象店舗、入力ファイル、処理版、件数を記録する案があります。
途中で失敗して同じ日のデータを再実行するときに、単純追記で二重計上しないかを考えます。対象日の結果を作り直して置き換える方法、注文のキーで更新する方法などから、遅れて届く訂正や同時更新の条件に合う方式を選びます。
「処理が終了したか」と「必要なデータが届いたか」も分けます。処理自体は成功していても、一店舗分のファイルが未着なら、集計は不完全です。未着時にレポートを保留するか、暫定値と明示するかは利用者と相談しておきます。
成果物はコードだけではない
職務を説明するときは、次のような成果物を並べると担当の広さが伝わります。
| 成果物 | 誰に役立つか |
|---|---|
| 入力と出力の対応表 | データの意味を確認する業務担当者 |
| 取込・変換コードとテスト | 変更する開発者 |
| テーブル定義と利用上の注意 | 分析担当者 |
| 実行結果・エラーの記録 | 運用担当者 |
| 再実行・復旧の手順 | 障害時に対応する担当者 |
個人情報を扱うなら、業務上必要な項目と利用者を確認し、組織の規程に従ってアクセスや保存期間を設計します。学習用の成果物では、本番から取得したデータを無断で転用せず、公開利用が許されるデータや架空データを使いましょう。
隣接職種とは、主に何を受け渡すか
役割の違いは肩書きだけで固定せず、成果物の受け渡しとして考えると明確になります。売上の例なら、業務担当者は「何を売上と呼ぶか」、分析担当者は「どんな傾向を調べたいか」を示し、データエンジニアはその分析に使えるデータの経路と提供方法を整えます。
アプリケーション開発者とは、注文データの仕様変更や取得方法を相談します。インフラ担当者とは、処理を実行する環境、権限、監視などをすり合わせます。少人数のチームでは兼任も考えられるため、求人ではどこからどこまでが自分の責任になるかを具体的に確かめます。
学習は、小さなデータ経路を完成させるところから
学習課題として、架空の注文CSVを読み、型の不一致を記録し、日別集計を作り、同じ入力を再処理しても二重計上しないことを確かめると、職務の一部を体験できます。成果物にはコードだけでなく、入力の仕様、除外ルール、実行方法、検証結果も添えます。
SQLやプログラミング、データモデル、運用のどれから学ぶかは、求人の業務と自分の経験に合わせます。技術名を増やすことより、「どのデータを、どの条件で、誰に届ける仕組みを作ったか」を説明できることを目標にすると、学習内容を職務へ結び付けやすくなります。
応募前には、新規基盤の構築か既存処理の改修か、バッチか継続的な取込か、障害対応を含むかを確認しましょう。株式会社テクノヴァースの現在の募集内容は採用情報で案内しています。本稿は職務理解のための解説で、データエンジニア職の募集や案件への配属を保証するものではありません。