はじめに

マネーフォワードの分析推進部のアナリティクスエンジニアの奥野です。

私が携わったプロジェクトにおいて、Salesforceから連携されるデータを扱うのが難しくて困っていました。そこでそのデータをスタースキーマの形式に変換してみたら、シンプルで分かりやすくて好評だったのでそのことを書いていきたいと思います。

想定読者

Salesforceの標準オブジェクトの構成について知っている方で、取り込まれた生データの形式が使いづらいと感じている方。

背景：事業本部との共同プロジェクトでSalesforceのデータを扱うことになる。しかし、このデータの構造が分かりづらくててハマる、、、

まずは前提として、弊社のデータ分析環境についてですが、マネーフォワードには私が所属する分析推進部という中央のデータ組織があり、加えて各事業本部でも事業戦略の組織でデータを扱う組織があります。その構成に対応して、中央、各事業本部はそれぞれデータ分析環境を持っているため、分権的なデータの構成になっています。

とあるプロジェクトで、我々中央組織と事業本部の協業プロジェクトが立ち上がりました。
私はこのプロジェクトで初めてSalesforceのデータを扱うことになりましたが、このプロジェクトを推進するのはとても困難でした。
その理由がSalesforce関連のテーブル構成の理解が難しかったことにあります。

何が難しいかといえば以下の２つでした。

• Salesforceの標準オブジェクトの構成が特徴的でキャッチアップが難しい。（例：リードから商談へコンバートするときの挙動）

• 事業本部側で、それら標準オブジェクトのテーブルから直接データマートが作られており、加えて似たような処理（カラム付与のロジック等）が複数のデータマートで行われていた。
  それにより、目的が似ているデータマートが乱立し、それぞれのロジックが微妙に異なっていて、どれが正しいロジックか判断が難しい状況でした。

この課題に対して、プロジェクト上の時間の制約もあり、私と事業本部の担当者の気合でカバーしました。お互いデータの仕様を何度もやりとりしてなんとかやりきりました。
ただ、お互い度重なるデータの確認の問い合わせで疲弊していました。

データの構造がもっと分かりやすければよいのに、、、
そんな課題を将来に残したくない思いからSalesforceのデータ構造をスタースキーマ化してビジネスユーザーに理解しやすく、メンテナンスしやすくするプロジェクトを立ち上げました。

次で、どのように、Salesforceのデータをスタースキーマのデータとしてモデリングしていったかを説明したいと思います。

負債解消のためSalesforceデータのスタースキーマ化プロジェクトが始動

まず、スタースキーマ化にあたって、関心のあるビジネスイベントを洗い出すということをやりました。
ビジネスイベントの洗い出しは、データモデリングに関する本(*1)やgitlab(*2)のドキュメントでバスマトリックスを作成することで進めやすくなると知り、まずはそれを作成することにしました。

バスマトリックスは必要なビジネスイベントとそれに関連するエンティティを洗い出すことで必要なfact、 dimensionのテーブルを洗い出すことができます。
詳しくはぜひ、The Data Warehouse Toolkit(*1)やKimball Group
の記事を読んでいただくのが良いと思います。

事業本部のメンバーと協力して以下のバスマトリックスを作成しました。

初めてバスマトリックスを作成してみましたがこれが便利でした。バスマトリックスを作ることで必要なビジネスイベントとそれに関連するエンティティが自然に列挙されてきました。
また、バスマトリックスは、ビジネスイベント（ファクト）とディメンションがマトリックス形式で表現されるため、どのファクトをどのディメンション（軸）で見ることができるのかを理解しやすく、事業本部側のメンバーとの議論がしやすい印象を持ちました。

バスマトリックスが完成したら、次にスタースキーマのfact、 dimensionテーブルを作成していきます。これはバスマトリックスに従い淡々と作っていきます。
すでに用意されている標準オブジェクトをどのように加工すればfact、 dimensionのテーブルを作れるのかを確認していきます。ほとんど１つの標準オブジェクトを１つのfact or dimensionテーブルに対応させましたが、fact_opportunity_detailはopporunityとopporunityをジョインしたようなケースもあります。

結果、作成したテーブルが以下です。

スタースキーマ化により使いやすくなったSalesforceのデータ。分析者やビジネスユーザーからわかりやすいと好評をもらった。

このテーブルを作ったことによってかなりポジティブなフィードバックをいただきました。ビジネスユーザーに限らず、事業本部側のデータ関係者にも歓迎されました。
もらったフィードバックは、

• テーブルがどういうビジネスイベントに紐づいているか分かりやすい

• テーブルにカラムを付与するような改良の際にどのテーブルにカラムを付与するのか理解がしやすい。（データマート開発者の立場から）

• これにより開発者のオンボーディングコストが削減された

というものでした。
スタースキーマはずいぶん昔に提唱されたアプローチですが、それが今でも効果を発揮したことを目の当たりにして、スタースキーマのポテンシャルを改めて感じました。

特に、上記の2番目の「テーブル改良の際に、どのテーブルを改良するべきかが分かりやすくなった」というコメントは嬉しかったです。
スタースキーマのテーブルの利用ユーザだけではなく、データマート開発者にも好評価だったのは、個人的にはとても嬉しく感じています。

これまでのデータマート開発時のペインの中でも、なかなか表には見えづらい課題を解決できたことは、アナリティクスエンジニアとして大きな喜びです。

おわりに

読んでいただきありがとうございます！！
面白かったらスキをつけてもらえると励みになります！

この記事を読んで、少しでもマネーフォワードの分析推進部に興味を持ってもらえたら幸いです。
他にもメンバー紹介や日々の取り組みに関する記事が多数ありますので、ぜひご覧ください！
マネーフォワード・データ＆AI｜Money Forward Data｜note

*1 The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling のChapter 4
*2 The GitLab Handbook  Enterprise Data Warehouse Enterprise Dimensional Model GovernanceのModeling Development Process 
https://handbook.gitlab.com/handbook/business-technology/data-team/platform/edw/#modeling-development-process