管理会計オペレーションを支えるデータエンジニアリング

https://analytics-and-intelligence.connpass.com/event/402535/ で登壇した資料です。

Transcript

2. 自己紹介 ファインディ / データエンジニア 田頭啓介 / @tagasyksk 2024年5月〜 CTO室データソリューションチームにジョイン マルチプロダクトのデータ基盤の開発に従事 経営管理部門のデータ整備もやっている 2
3. 話すこと・話さないこと ✅ 話さないこと: 技術スタックの詳細について 🚫 話すこと: 会計指標をデータ基盤に集約するデータモデリング 業務担当者とのヒアリングを起点にした実績集計の再設計と、見通しの計算ロジックをBigQueryに入れて推移と振り返りを可能にした話 個別ツールの設定・実装の詳細にはあまり触れません 3
4. 管理会計の現状と課題 4
5. 管理会計とは 経営判断のための会計 財務会計（外部報告）とは別に、社内の意思決定に使う会計 事業部別・プロダクト別の損益・KPI・予実管理 経営層・事業部長が毎月参照する、実務に直結する数字 データエンジニアリングとの接点 集計ロジックと業務定義が密に絡む領域 ソースが多岐にわたる（会計SaaS・スプシ・組織マスタ等） 5
6. オペレーションの実態 📑 スプシのリネージが50件超 🕸️ ロジックの重複と乖離 🔁 月次締めの遅延 ⏳ スプレッドシート中心の集計 月次で関数・ピボットを手作業で組み直す運用 IMPORTRANGEやVLOOKUPで絡み合い、どこか1枚崩れると全体が連鎖的に壊れる 同じKPIの計算式がスプシごとに存在し、担当者ごとの手元計算もあり、数字が合わない 毎月集計完了まで2〜3日かかり、意思決定が後追いになる 6
7. データモデリングで解けること 🕸️ 🧹 ロジックを整理する 新たに生まれるユースケースに対応する 🌱 リネージを明らかにする スプシで絡み合っていた依存関係を、データの流れとして可視化できる 業務担当者の頭の中に散らばった計算式を、再利用可能なパーツに集約する 予実分析・AIによる会計分析など、新しい要求にも柔軟に応えられるように設計する 7
8. データモデリングによる再設計 8
9. モデリングはヒアリングから始まる 勘定元帳やマクロを眺めるだけでは始まらない 「計上組織」「補助科目」「配賦」「予算番号」...専門用語が飛び交う 業務担当者の頭の中にある集計粒度・分析軸を引き出す必要がある 業務担当者との対話で輪郭を掴む 何を集計したいのか（売上？粗利？受注？） どの軸で切りたいのか（事業部・プロダクト・月・顧客） どの粒度で見たいのか（月次？日次？契約単位？） → ヒアリングを重ねるうちに、モデリングに必要な情報が集まっていく 9
10. 参考にした書籍 『アジャイルデータモデリング 組織にデータ分析を広める ためのテーブル設計ガイド』 業務担当者との対話を起点にディメンショナルモデルを立 ち上げる手法（BEAM✲）を体系化した一冊 ヒアリングで「誰が・何を・いつ・どこで」を引き出 し、ファクトとディメンションに落とす流れ この本のアプローチをなぞる形で、経営管理部の担当 者とのヒアリングとモデリングを進めた 10
11. ヒアリングから立ち上げたファクト設計 経営管理部の担当者と何度もMTGを重ね、業務の流れと集計の意図を整理 総勘定元帳を起点に、売上・費用・原価を月次粒度のファクトとして分離 💰 費用ファクト 💸 原価ファクト 🏭 売上ファクト 事業別の売上実績を月次で管理 事業別・費目別の費用実績を月次で管理 事業別・科目別の原価実績を月次で管理 11
12. 業績見通しの計算ロジックもBigQueryに入れる 📥 計算ロジックはBigQueryへ移す 🪞 入力は担当者のシートのまま 各事業部の入力が必要なものは一旦これまでどおりスプシで行い、ソースとして利用 見通しの計算ロジックをマート側で再現し、スプシと同じ結果になるように揃えて信頼を得る 12
13. データの一致は都度のテストで保証する ロジックが一発で合うことはない 積み上げ・手動上書き・費目付替え等の細部で必ずズレが出る ズレが元のシート側が原因なのか、dbtのロジックがズレているのかは担当者と膝 を突き合わせて確認する フィードバックを元にdbtのテストを育てていく ズレの指摘をもらう → 直す → 同じズレを検知するdbtのテストを足す、の繰り返 し レイヤー間の整合（月次サマリー = 明細ファクトの合計）、縦の整合（組織別合計 = 費目別合計 = 全社合計）をCI・日次ジョブで実行 13
14. 見通しの履歴を継続的に蓄積する スプシでも履歴は残せるが、保守がキツい GASと関数を駆使して、見通しを複製して保持する運用 見通しロジックを修正すると、複製の仕組み側にも追従が必要になる 見通しの履歴を毎日自動で残す 定期スナップショットファクトとして見通しを毎日保存 各月ごとの見通しの推移に答えられるようになった → 見通し精度の改善サイクルをデータ基盤の中で回せるようになった 14
15. 全体構成 会計データソースをDriveにアップロード&TROCCOのジョブを起動してもらう 会計実績値・見通しがdbtで集計され、Looker・スプシから参照できる 15
16. 得られた効果 16
17. オペレーションの変化 🔘 🚨 イレギュラーな科目の可視化 数字の一本化 🎯 ワンボタンで月次集計が完了 dbtを流すだけで月次の実績値・見通しが揃う。スプシ再構築の手作業はゼロに 想定外のレコードを自動で検出できるようになった スプシごと・担当者ごとに別計算だったKPIが、同じファクトを起点にする一つの数字に揃った 17
18. 今後やっていくこと 事業KPIと経営数値をつなぐ いまの見通しは、実績と担当者の入力から算出している 今後は事業KPIと実績値を結びつけ、より根拠の強い見通しをデータ基盤上で算出 できるようにしていく AIエージェントによるデータ抽出 Lookerの会話分析をセットで提供することで、自然言語での会計分析を行えるよ うにしていく 18
19. まとめ 19
20. データエンジニアリング = プロダクトのためのもの、ではない バックオフィス業務はスプシと手作業で回っていることが多い 集計ロジックの設計・整理・自動化は、まさにデータエンジニアの得意領域 バックオフィスにはデータ整備の余地がたくさんある 業務が長年積み重なり、構造が複雑化している 数字が経営判断に直結するため、整備のインパクトが大きい 20
21. ご清聴 ありがとうございました 21