マルチビジネス企業におけるデータ分析基盤の責務と分担

2025年7月4日に開催されたData Modeling Nightでの登壇資料です

Transcript

1. マルチビジネス企業における データ分析基盤の責務と分担 @Data Modeling Night_20250704
2. 自己紹介 - 名前：佐々木江亜（ささきえあ） - Xアカウント @0610esa - 略歴 - 2019年11月~ マネーフォワードジョイン 分析推進室立ち上げ → その後室長 → データ戦略室立ち上げ → 異動 - 2024年3月~ マネーフォワードビジネスカンパニー HR事業戦略本部 DataOps部 - 風音屋ではアドバイザーとしてアジャイルデータ モデリングの翻訳プロジェクトに参画 - 好きなものは音楽、落語、深夜ラジオ、猫
3. • マルチプロダクトでビジネスを展開している企業における、分析用データマネジメントの プラクティス（ベストと言えるかはわからないですが …）を共有します • 現在の姿をいきなり理想形として語るのではなく、そこに向けての山ののぼり方についても 触れようと思います⛰ • 価値が出ている部分と、苦戦しつつなんとかやっている部分があるので、 ぜひそのあたり皆様のプラクティスも教えていただけますと嬉しいです 🙏 今日お話しすること
4. CORP OUTLINE
5. 社名 設立 代表者 上場市場 本社所在地 従業員数 株式会社マネーフォワード 2012年5月18日 代表取締役社長 グループCEO 辻庸介 東京証券取引所 プライム市場 〒108-0023 東京都港区芝浦3-1-21 msb Tamachi 田町ステーションタワーS 21F 2,634人 (25年2月末時点/連結)エンジニ ア・デザイナーが全体の約4割
7. 売上構成 出典元 : Business Overview for Investors（2025年4⽉） ※ グラフならびに売上⾼構成⽐率は、2024年11⽉期累計売上⾼（その他売上を除く）に占める内訳
8. サービス一覧 　BtoC、BtoBに限らず、数多くのサービス、プロダクトを提供しています。 POINT 出典元 : 株式会社マネーフォワード 会社紹介資料 法人向け バックオフィス向け　 SaaS SaaSマーケティング支援 ファイナンスサービス 個人向け 金融機関等向け PFM（家計簿・資産管理）サービス Fintech推進・DX支援
9. サービス年表 MF Unit for ◦◦ 現在 創業 一部抜粋 2012〜 2014〜 2016 2017 2018 2019 2020 2021 2022 2023 2024
10. 本題
11. 例えば（粒度もバラバラで網羅性もないが …） - 誰がどういう体制で管理する？ - データ分析基盤のアーキテクチャどうする？ - 技術スタックは何を使う？ - 前処理は何をする？ - データの品質テストは何をどうテストする？ - メタデータ管理どうする？ - データを提供した先のガバナンスどうする？ - データマート - アドホックな集計 - ダッシュボード - データコネクタ - リバースETL - モニタリングどうする？ - テーブル利用状況、クエリ、コスト管理どうする？ 分析用データマネジメントの営みは考える事が多い🤔
12. 加えて、MFWには複数の課金体系、販売チャネルが混在󰷺 - 課金体系 - サブスクリプション - ショット（導入支援サービスなど） - フリーミアム - バンドル契約 - 個別契約（直販、パートナー経由） - その他（手数料ビジネスなど） - 販売チャネル - The Model型の直販 - Web経由の直販 - 会計士・税理士・社労士事務所等のパートナー経由 ※便宜的に単純化したが、実際はこのそれぞれが同居しているケースも有
13. ビジネスモデルが複雑だと、組織体制も複雑🤯 （※イメージ図）
14. 複雑さをどうマネジメントするか 管理会計指標を整理した上でいくつかのレイヤーでビジネスを抽象化して捉え、 その抽象度ごとに担当体制を切り分ける形でデータ分析基盤をマネジメントすることにしました
15. 抽象度の線引きはステークホルダーで設定 抽象度 高 抽象度 低
16. データ分析基盤の概観🦅 各プロダクト DB ダッシュボード構築 アドホック・探索的分析 データエンジニア アナリティクスエンジニア データアナリスト fractal基盤と呼ばれている 以降はこの基盤について詳解 Looker is a trademark of Google LLC. SFAツール 契約管理基盤
17. fractal基盤の中身をもう少し詳しく👀
18. この再利用がポイント☝
19. レイヤーを分けることによるメリット🙆 1. 汎用性の高いアセットは中央で整備・管理してもらえるため事業部側ではその巨人の肩に乗っかる ことができる 2. 事業本部内での固有ニーズに合わせたモデリング、命名、メタデータ管理ができる a. ここは後述します 3. 担当組織ごとの技術レベルに合わせたツール選定が可能 a. 中央はdbtがメインである一方、非エンジニアメインでのデータマネジメントを担う 事業本部側ではdataformを利用
20. レイヤーを分けることによるデメリット🙅と対策💪 1. 本部を跨いだ時に、相互に動きをキャッチアップするコストがかかる →体制拡張の軸になるメンバーを元中央組織から輩出することで、 　元チームメンバー間での思想の共有と強固なコネクションを前提とした 2. 各個別組織のモデリングや命名規則に差分が生まれることによる相互理解の難しさ →中央側でモデリング等のガイドラインを引いてもらうことを検討中 3. ゴリっとしたエンジニアリング知見と適用の不足（これは非エンジニア組織のため） →Google Cloud資格の取得を通じて底上げ &中央からのナレッジシェアにて担保 →厳密なディメンショナルモデリングではなく、ゆるく用途特化のモデリングで実用（ごめんなさい）
21. 私の事業本部内データパイプラインをチラ見せ🫣
22. とはいえ、理想型に一足飛びには辿り着けない - 人材輩出モデルはいかんせん時間がかかる - 中央側での思想整備 →同チームで協働しつつ体得 →事業ニーズの高いところに輩出 →本部個別要件のインストール →データ分析基盤構築 - 時間がかかる取り組みであることを（特に経営層と）合意するのはとても大変 - 王道だと、成果が明確なアウトプットを出しつつ並行して体得していくことに なると思う - 我々の場合は管理会計数字のレポートという事業優先度の高い業務を担っていたた め、経営層からの支援もあり、この思想体得 →輩出の時間軸を担保することができた - データ活用観点で、業務オペレーションの標準化にも入る必要がある - データマネジメントのみではなく事業モニタリング側とビジネスプロセス最適化の 両方を推進する必要がある - 大変な点でもあり、面白い点でもあり … - 採用難易度が跳ね上がるという課題もある
23. 「プロセス指標に関しても横並びで見ないとだめだよね」 データコネクタしんどい（リバース ETLはもっとしんどい） そろそろMDMとちゃんと向き合わないとダメなんじゃないか with AI、どうする？ 全てをフラグ管理すべきなのか問題 LookMLとmetrics領域、セマンティックレイヤーはどちらで管理する？ （APPENDIX）今後の継続検討テーマ
24. Data&AI Blog マネーフォワード・データ ＆AI｜Money Forward Data｜note SNS X（Twitter）／LinkedIn Interview タイムズマネフォ／公式note 共に創り、実現しよう！