coconala社におけるDataformを利用したイミュータブルデータモデル新会計システム

ツール導入前の課題

• 弊社では新規事業が急速に立ち上がるなかで、それぞれに対応した会計システムの構築が急務であった。しかし、既存の会計システムのアプローチには以下の課題があり、短工期・少人数での対応が困難な状況だった。
  • メンテナンスと品質担保のコスト増大: 既存システムでは巨大なSQLのメンテナンスが必要であり、デグレードの懸念があった。
  • システム負荷とコスト: 会計DBが本体DBと同じRDSインスタンスに同居しており負荷が高く、また、RDSからBigQueryへの通信コストも無視できない状態だった。
  • 調査の困難さ: 科目の振替などの複雑なロジックの密結合により、トレーサビリティが極めて悪い状態だった。

どのような状態を目指していたか

• 開発スピードと品質の両立: 複雑なロジックを分割統治し、シンプルでメンテナンス性の高いデータ基盤を構築すること。
• コストと負荷の最適化: プロダクトDBへの負荷を分離し、BigQuery上で完結させることでコストを抑えたワークフローを実現すること。
• 監査性の担保: 会計データとしての信頼性を確保するため、「事実(Fact)」と「解釈(Derived)」を分離し、過去の取引履歴を正確に追跡できる状態にする。

• 特になし（BigQueryを中心としたエコシステム内での選定）

• SQLベースであること: 将来的に別の言語やツールへ移行したくなった場合でも、移植が容易である点。
• 依存関係の管理: 複雑になりがちなデータ加工のパイプラインをコードで管理できる点。
• コスト効率: インクリメンタルな更新が可能で、処理コストを抑えられる点。

• BigQuery上で完結するワークフローとイミュータブルデータモデルの実現。
  • Dataformを採用することで、データの加工(Transform)プロセスを管理可能なコードとして定義でき、BigQueryのパワーを活かしたELT処理が実現できる点が決め手となった。
  • また、TM理論やイミュータブルデータモデルの考え方を取り入れ、状態更新(Update)を行わず「事実」を積み上げる設計と相性が良い点も魅力的だった。

改善したかった課題はどれくらい解決されたか

• 非常に高いレベルで解決された。
  • ロジックの簡素化・局所化: 以前は巨大だったSQLが、最長でも80行程度に収まり、規模としては1/10以下になった。
  • 負荷の分離: プロダクトDBと分析基盤が完全に分離されたため、会計都合で本体システムに負荷がかかることがゼロになった。
  • トレーサビリティの向上: Delete / Updateの原則禁止、事実を抽出するレイヤーと加工のレイヤーを分割、集計時にロジックを介入させないことにより明細の追跡が容易になった。
  • 連携の効率化: BigQueryから直接CSVやスプレッドシートを出力できるため、会計SaaSへの連携作業が大幅に楽になった。

どのような成果が得られたか

• 上述の通り、既存の会計システムで感じていた課題を解決出来た。
• 今回構築したアーキテクチャは別事業でも同様の考え方で使い回すことができ、Scrap & Buildが非常に容易になるという副次的効果も得られた。

• 既存の会計システムの考え方からの脱却と、イミュータブルデータモデルへの思想の転換が必要だった。
• プロダクトのエンジニアだけでなく経理チームとも出力レイアウトやデータ要件を事前にすり合わせる必要があった。

• 会計データのように「整合性」が命となる領域において、Dataformとイミュータブルデータモデルの組み合わせは非常に強力である。
• 「事実」と「解釈」を分けることで、システムも心も平穏になる。SQLベースで始められるため、特定の言語にロックインされたくないチームにもおすすめ。

• 今後は、DataformのAssertion機能をより効果的に活用し、データ品質の自動監視を強化したいと考えている。また、ロード時の個人情報削除などの権限・セキュリティ設定の精緻化や、データエンジニア的な考え方を組織全体に浸透させていくことにも取り組んでいきたい。