データエンジニアのメソッド｜日次売上の集計基盤を例に、設計から運用までの手の動かし方
- 最終更新日：2026/10/16
データエンジニアのメソッドと聞くと、特別な技法やツールの組み合わせを想像しがちですが、現場で長く通用しているのは、地味な型の積み重ねです。この記事では、架空の通販サイトの日次売上集計を作る場面を例に、要件の置き方から取り込み、変換、テスト、運用までを順にたどります。あわせて、その型が合わない場面と、経験の段階ごとの身につけ方も説明します。
データエンジニアのメソッドは戻せる、やり直せる、説明できるの3点に集まる
どんな基盤でも、いつかは入力データが壊れたり、処理が途中で止まったりします。そのときに元の状態へ戻せるか、同じ処理をやり直しても結果が変わらないか、なぜその数字になったのかを第三者へ説明できるか。以降の手順は、この3点を満たすための工夫として読むと整理しやすくなります。
日次売上の集計基盤を例に手順を追う
題材は、受注データを毎朝集計し、経営会議用の売上表を出す仕組みです。データは受注管理システムのデータベースにあり、集計は現在、担当者がExcelで手作業しているという想定で進めます。
要件を利用者の質問に言い換える
「売上を集計したい」という依頼のままでは設計に入れません。会議で出る質問に直すと、必要な粒度が見えてきます。たとえば「昨日の商品カテゴリ別の売上は」「先月の同じ曜日と比べてどうか」といった質問です。返品を売上から引くか、税込か税抜かも、この段階で依頼者と確かめます。
取り込みは加工せず生のまま残す
データを入れる前に加工する従来の方式をETL、入れてから加工する方式をELTと呼びます。ELTは生データを保管しておけるため、集計のルールが変わっても元の取得からやり直さずに済むのが利点です。一方で、品質の問題が後の段階で見つかりやすく、機密情報を生のまま置く場合は、アクセス権限の管理も必要になります。
層を分けて変換する
変換は一度にやらず、役割ごとに層を分けると、不具合の場所を特定しやすくなります。
| 層 | 役割 | この例での中身 |
|---|---|---|
| 生データ層 | 取得したままを保管する | 受注テーブルのコピー |
| 整形層 | 列名や型をそろえる | 日付型への変換、重複行の除去 |
| 集計層 | 利用者が見る形にまとめる | 日付とカテゴリごとの売上表 |
同じ処理を何度流しても同じ結果にする
処理を二度流しても結果が変わらない性質を、冪等性と呼びます。夜間の処理が途中で失敗したとき、そのまま再実行しても売上が二重に積み上がらないよう、日付単位で上書きする設計にします。追記だけの設計だと、再実行のたびに数字が膨らんでしまいます。
テストを先に決めておく
dbtのようなツールには、列が空でないこと、値が重複しないことを確かめる標準のテストがあります。この例なら、受注番号が重複していない、金額が負の値になっていない、集計の合計が元データの合計と一致する、の3点を最初に決めます。数字が合わないという相談を受けてから原因を探すより、毎朝の処理の中で自動で確かめるほうが、はるかに早く気づけます。
失敗に気づく仕組みを足す
処理が止まっても誰も気づかず、会議の直前に古い数字が出る、という事故は少なくありません。失敗時にSlackへ通知を送る、集計層の最終更新時刻が前日のままなら警告を出す、といった監視を組み込みます。通知先は、深夜でも見る人に設定しておくことが大切です。
数字が合わない朝に原因を切り分ける順番
型を整えても、売上表の数字がおかしいという連絡は来ます。慌てて集計層のSQLを書き換える前に、下流から上流へ順にたどる癖をつけます。
最初に更新時刻と行数を見る
集計層の最終更新が前日のままなら、数字の誤りではなく処理が止まっています。更新されているのに行数が極端に少ないなら、取り込み側の欠落を疑います。この二つを見るだけで、調べる範囲が半分ほどに絞れます。
層ごとの合計を突き合わせる
生データ層、整形層、集計層の売上合計を並べて、どこで差が出るかを探します。差が出た層の変換だけを読めば足りるため、全体のSQLを読み直す必要はありません。重複行の除去で正しい行まで消していた、というような原因がここで見つかります。
直したあとは過去分を流し直す
変換の誤りを直したら、それまでの期間の集計も作り直す必要があります。この再処理をバックフィルと呼びます。冪等な設計になっていれば、日付の範囲を指定して流し直すだけで済みます。流し直した前後の数字を依頼者に伝え、どの期間の数字が変わったかを記録しておきましょう。
型が合わない場面もある
先ほどの手順を、どんな現場にもそのまま当てはめるのは危険です。
個人情報を取り込む前に落としたい場合
氏名や住所のような情報を、分析用の基盤に生のまま入れたくない現場では、取り込む前に不要な列を落とすETLの考え方が向いています。保管の範囲を最初から絞れるためです。
データ量が小さく道具が重すぎる場合
1日に数百行しか増えない集計に、ジョブ管理ツールと変換ツールを組み合わせると、運用の手間のほうが上回ります。スクリプト一つとスケジューラーで足りるなら、それが正解のこともあります。
保管費用が膨らむ場合
生データを全量残す設計は、データが増え続けると保管費用に響きます。保管期間を決め、古いものを安価な領域へ移す運用もあわせて考えましょう。
経験の段階で身につける順番
未経験の方は、まずSQLで集計を書き、結果を自分で検算する習慣から始めます。ツールの選定より先に、データエンジニアの基本で扱う取り込みと変換の流れを、小さなデータで一周させることが近道です。
実務経験のある方は、再実行や障害時の挙動を意識して、既存の処理を見直してみてください。冪等でない処理と、テストのない集計が、最初に直すべき候補になります。AIにSQLを書かせる場面でも、出力を検算する目が必要で、データエンジニアのAI活用で整理した使いどころと合わせて考えると、任せる範囲を決めやすくなります。
手順を人に引き継げる形で残す
型を実践していても、頭の中にだけあるうちは、チームの資産になりません。層の役割、列の命名規則、再実行の手順をREADMEに書き、レビューで確かめ合う習慣を作ります。この書き方は、データエンジニアのポートフォリオを作るときにも、そのまま使える考え方です。
最初に試すなら冪等性から
ここまでの型をすべて同時に取り入れる必要はありません。いま手元にある一つの処理を取り上げ、二度流しても数字が変わらないかを実際に試してください。変わるなら、そこが最初の改善点です。小さな修正でも、戻せてやり直せる処理が一本増えれば、基盤全体の信頼が確実に上向きます。