この記事はenechain Advent Calendar 2025の20日目の記事です。
enechainのeClearデスクでエンジニアをしているヒョンスンです。
今回は、電力取引の決済・リスク管理プラットフォームである「eClear」において、コアなデータの集計をdbtで改善した事例を紹介します。 Finance（金融・決済）領域の開発において、データの整合性と集計ロジックの管理は永遠の課題です。似たような課題を抱えているエンジニアの方々の参考になれば幸いです。
はじめに
eClearとは
まず、私たちが開発している「eClear」について簡単に触れます。 eClearは、電力の現物取引におけるクリアリングサービスで、カウンターパーティリスクを解消し、決済業務を効率化するためのプラットフォームです。 詳細はこちらの記事もご覧ください。
Finance領域における設計の「あるある」な課題
Finance領域のシステム設計、特に決済・清算・請求・決算といった業務フローにおいて、以下のような課題に直面することは多いのではないでしょうか。
- データが「多目的」に使われる
- 1つのトランザクションデータが、請求書発行、会計システムへの連携、経営管理上の予実集計、リスク管理ダッシュボードなど、あらゆる場所で異なる形で参照されます。
- データ加工に係る工数の増加
- それぞれの用途に合わせて、「今月はこの区分で集計したい」「消費税の計算タイミングを変えたい」といった要望に応えるため、データを加工・変換する処理（ETL/ELT）が膨らみ続けます。
eClearも例外ではなく、サービス拡大に伴い、この「データ加工の複雑性」が開発のボトルネックになりつつありました。
eClearが直面していた課題
バックエンド実装の限界
当初、eClearでは集計やデータ加工の処理を、Goを用いたバックエンドのバッチ処理として実装していました。 データベースからデータを読み出し、ロジックを通して加工し、結果を別のテーブルに書き込む、という一般的な手法です。
しかし、サービスが成長するにつれて以下の「3つの壁」にぶち当たりました。
- ビジネスロジック変更による影響範囲の拡大
- 機能追加でテーブル構造が変わるたびに、集計バッチの改修が必要になる。
- データ構造変更に対する耐性の低さ
- 例えば、ENUMが1つ増えただけで、想定していなかった集計バッチがエラーを吐いて停止する。
- インフラリソースの枯渇
- データ量が増えるにつれ、メモリ不足やDBコネクションの枯渇など、インフラ起因のジョブ失敗が発生しやすくなる。
実際に決済機能において「預託金の相殺処理」という新機能を追加した時のことです。 アプリケーション側（バックエンド）では正しく実装・リリースされましたが、裏側で動いている集計基盤側のバッチへの反映が漏れてしまい、正しく集計されないという事象が発生しました。
「機能を作る人」と「集計を見る人」の間で、ロジックのオーナーシップがバックエンドのコードの中に埋もれてしまっていたことが原因でした。
改善のアプローチ：Argo Workflows + dbt + BigQuery
そこで私たちは、「アプリケーション（機能開発）」と「集計（データ活用）」の責務を明確に分離するアーキテクチャへと刷新しました。
解決策の核となったのが dbt です。 dbtは、ELT（Extract, Load, Transform）プロセスの「T（変換）」に特化したツールで、SQLを使ってデータウェアハウス内のデータを変換・加工するモデルを定義できます。
構成は以下の通りです。
- Raw Data: アプリケーションDBのデータをBigQueryへ同期
- Transform (dbt): Argo Workflows等でdbtを実行し、ビジネスロジックに基づいた加工を行う
- Data Mart: 利用用途ごとに整理されたデータマートを作成
The Go gopher was designed by Renee French.
この構成のメリットは以下になります。
- オーナーシップの分離と集計の透明化
- 集計ロジックが複雑なアプリケーションコードから宣言的なSQL（dbt）に移ったことで、「集計を見る人」自身がロジックを設計・実装できるようになりました。
- これにより、以前のように集計ロジックがバックエンドのコード深くに埋もれてブラックボックス化することがなくなり、機能追加時の集計漏れや仕様認識のズレを構造的に防げる体制となりました。
- 機能開発と集計の疎結合化
- アプリケーション側の変更が、直接的に集計処理を破壊するリスクを減らせます。
- 爆速な追加対応
- dbtであれば、SQL（とJinja）を書くだけで新しい集計ビューやマートを作成できます。複雑なアプリケーションコードをデプロイする必要がなく、データマートとして柔軟かつ迅速にビジネス要求に応えられるようになりました。
抱えていた課題はどう解決されたか
導入したアーキテクチャ（Argo Workflows + dbt + BigQuery）は、前述した3つの課題を以下のように解消しました。
ビジネスロジック変更による影響範囲の拡大 → 「集計」と「機能」の分離
集計ロジックをアプリケーションから切り離したことで、機能開発（Go）と集計開発（SQL）のデプロイサイクルを分離できました。 過去データの再集計が必要になった際、アプリケーションDBを直接更新するのは危険ですが、BigQuery上のデータであればdbtコマンド一つで何度でも安全に再計算が可能です。
データ構造変更に対する耐性の低さ → ELTによる柔軟な受け入れ
データソースに変更があっても、まずはRawデータとしてBigQueryにロードされます。 dbt側でテスト（dbt test）を実装することで、「データ構造が変わったこと」を検知しつつ、影響をレポート出力の遅延のみに留め、本番システムを落とすことなく対応できるようになりました。
インフラリソースの枯渇 → BigQueryのコンピュートリソース活用
集計処理の実行基盤が、メモリ制限のあるアプリケーションサーバーから、強力なBigQueryに移りました。 これにより、データ量が数倍〜数十倍に増えても、エンジニアがメモリ管理やコネクションプールを気にする必要がなくなり、インフラ起因のジョブ失敗はほぼ皆無になりました。
なぜバックエンドではなくdbtなのか？
「DBのスキーマが変われば、dbtのクエリも修正が必要になるのは同じでは？」と思われるかもしれません。 確かに「修正が必要」という事実は変わりません。しかし、「変更の影響範囲」と「リカバリの容易さ」において決定的な違いがあります。
- 本番サービスとの疎結合（Decoupling）
- バックエンドで集計を行っていた時は、集計バッチの改修ミスがアプリケーションのデプロイ（＝本番稼働中の決済機能など）に悪影響を及ぼすリスクと常に隣り合わせでした。
- ELTアーキテクチャでは、データはまずRawデータとしてBigQueryに運ばれます。dbtはその後の加工のみを担うため、 万が一集計ロジックが壊れても、eClearのメイン機能である決済や取引は止まりません。
- 宣言的記述による堅牢性
- 命令的なGoのコードで for 文を回して集計するのと違い、SQLは宣言的です。
- 例えばENUMが増えた場合、アプリケーションコードではSwitch文の網羅性チェックでパニックを起こすことがありますが、SQLの GROUP BY であれば「新しい区分値の行が増えるだけ」で処理自体は完走することも多く、致命的なクラッシュを避けやすい性質があります。
構成変更によって可能になったデータ活用
dbtによって整備された信頼性の高いData Martは、現在様々な場所で活用されています。
スプレッドシート連携
Financeチームの実務において、スプレッドシートは依然として最強のツールです。BigQueryに貯まったクリーンなデータを「データコネクタ」でスプレッドシートに直接連携。 これにより、エンジニアにSQLを依頼することなく、経理担当者が最新のデータを手元で分析・加工できるようになりました。
外部サービス連携
作成されたデータマートは、単なる分析用だけでなく、システム間連携のソースとしても機能しています。
- 請求システム連携: 請求確定データをdbtで作成し、「楽楽明細」などの外部システムへ連携。
- BIツール連携: LookerなどのBIツールと接続し、経営層向けのダッシュボードを構築。
データが1箇所に集約され、そこから各所へ配られる「Hub & Spoke」のような形になったことで、ロジックの散在に起因する『システムAとBで数字が合わない』という事象は完全に解消されました。
まとめ
Finance領域のように、複雑なビジネスロジックと高い信頼性が求められるドメインにおいて、「データを中心にする」 というアプローチは非常に強力です。 バックエンドから集計の責務を剥がすことで、開発効率と安定性が向上しました。 ビジネス状況の変化によって頻繁に変わる「集計・分析」の要望に対し、dbtを用いることでSQLベースで素早く対応できるようになりました。
dbt自体も進化し続けています。dbt jobをコード管理できるようになったり、新しいエンジンが公開されたり、今後にも期待できるプロダクトです。
金融や決済に限らず、複雑な集計ロジックに悩まされているバックエンドエンジニアの皆さんは、ぜひ一度dbtを活用したアーキテクチャへの移行を検討してみてはいかがでしょうか。
enechainでは一緒に働くメンバーを募集しています。 興味がありましたら是非ご応募お待ちしております。
