製造業向け分析レポート基盤 (DW 構築 / Django API 置換)

Background

製造業向けに分析レポートを提供する事業に正社員エンジニアとして所属し、2021 年から 2024 年までの 3 年間、レポートの運用と基盤刷新を担当しました。参画当初はレポート出力の維持運用が主担務でしたが、データの取り回しに無理が出ていたため、BigQuery を中心としたデータウェアハウスの新設と、既存の Django ベースの API レイヤーを段階的に置き換えるところまでスコープを広げて取り組みました。データ周りを横断的に見られる立ち位置でレポート機能の追加・運用と基盤刷新を兼任した形です。

Challenge

レポートの仕様変更ごとに Django のビューと SQL の双方を触る必要があり、変更コストが線形に積み上がっていく構造になっていました。レポート定義が Django のビュー・カスタム SQL・運用手順の 3 箇所に分散していたため、改修のたびに整合確認のコストが大きく、軽微な変更でも工数が読みづらい状態でした。さらに Django API は分析向けクエリと業務向けリクエストが同じレイヤーに同居しており、性能・運用負荷の両面で持続困難な状態でした。一方でレポート提供そのものは止められないため、DW 移行と API 置換を運用と並走させる必要があり、切替の安全性確保と進行スピードの両立が課題でした。

Approach

DW は BigQuery を採用し、生データのステージング層とレポート単位のマート層を分けるレイヤード構成にしました。共通の指標定義はマート層に集約し、レポート追加時の重複実装を抑える方針です。Django API については、分析クエリ起点の系統を順次 BigQuery 側に切り出し、業務向けで残すべき系統は責務を絞った形で再実装することで、分析と業務のレイヤーを分離しました。切替は系統ごとに区切り、切替前後で同じ入力に対する出力を突き合わせて差分を検証してから本番経路を切り替える、シャドーラン寄りの進め方を取り、レポート出力に影響を出さずに段階移行できる状態を作りました。

Outcome

3 年の取り組みで、レポート開発のリードタイムと運用負荷の双方を改善する形で着地しました。レポート追加時の改修箇所がデータ層に集約され、Django のビュー側と SQL 側の二重改修が発生しなくなったことで、軽微な追加要望に対する着手から反映までの所要時間が以前の体感より大幅に短縮されています。副次効果として、データ基盤側に共通レイヤーが整備され、後続のレポート追加が個別実装に依存しなくなりました。今後の類似案件では、運用引き継ぎを前提とした基盤刷新の段取りを参画初期に合意することで、より早く価値を返せると考えています。