マネーフォワードで分析推進室/室長をやってます、酒井と申します。

今回は、マネーフォワードの管理会計を実現している、データ構造/管理会計分析フレームワーク「MF on SSOT」の「MF = Management by Fractal」部分について詳しくお話しします。

端的に言うと何か、どう考えて具体的にどんな実装をしているのか、といった内容を、データ分析/管理会計をアップデートしたい実務者の皆様にお伝えしたいと思います。

過去記事はこちら

Fractalを端的に説明すると…

KPIや管理会計を、あたかも「フラクタル」な図形のように、同じ定義のKPIをあらゆる解像度で見られるようにし、あらゆる「マネジメント＝管理」に活かすことです。

例えば、あなたの会社は売上高を

グループ全体
→ グループ各社
→ 各事業部
→ 各部
→ 各チーム
→ 各個人

と分解することはできますか？

売上高ではなく、顧客数や客単価についてはどうでしょう？ おそらく多くの会社では分解できていないか、Excelで都度頑張って加工をしないと出てこないケースが多いと思います。

これを実現するために、必要とあらばいくらでもブレークダウンできるよう「フラクタルに」情報を保持しておくことが重要になります。

※ ちなみに「フラクタル」な図形とは、こういうやつを言います。
(英語版WikipediaのDinoさん, CC 表示-継承 3.0, https://commons.wikimedia.org/w/index.php?curid=3872598)

具体的にどんな粒度でレコードを持っているか

結論から言うと、当社の実装におけるレコードの粒度は、

月次(month)                   ：2020-06, 2020-05, 2020-04…
顧客(account)                 ：テスト産業, テスト建設, テスト電工…
プロダクト(product)      ：クラウド会計, クラウド給与, クラウド勤怠…
プラン種別(plan_type)   ：定額プラン, 従量プラン…
課金種別(payment_type)：クレカ払い, 請求書払い…
売上種別(revenue_type) ：Stock売上, Flow売上…

ごとに売上高を集計するテーブルを作成し、活用しています。
これがあれば、顧客別やプロダクトに応じて担当者や対応部署を判定することができるので、前述のようなフラクタルなデータ分析が可能です。

この粒度が month × account × product × 3 types であることから、僕らはこのデータ形式を、便利にmap3tフォーマットと呼んでいます。

基本的にデータ粒度はmap3tにしておけば問題ないとも思いますが、顧客(account)のところは商談/案件に置き換えても良いかも知れません。というのも、取引によっては、顧客Aに対してプロダクトによって複数の営業担当者が紐づくことなどがあるからです。

このときの1レコードは、管理会計/データ分析における「原子」のようなものです。これら「会計原子」適切に集計することで、各KPIを簡単に様々な解像で確認できます。

例えば、月次MRRの計算は下記SQLを記述するだけで済みます。

SELECT month, sum(revenue)
FROM table
WHERE revenue_type = “Stock売上”
GROUP BY month

あなたの会社でやるときの考え方

map3tはあくまで当社の現状にフィットした粒度なので、会社ごとにこれは工夫したほうが良いです。

例えばD2Cベンチャーであれば、

月次(month)                   ：2020-06, 2020-05, 2020-04…
顧客(account)                 ：マネフォ太郎, マネフォ次郎, マネフォ花子…
プロダクト(product)      ：クラウド会計, クラウド給与, クラウド勤怠…
チャネル(channel)          ：Amazon, 楽天市場, 自社EC…
課金種別(payment_type)：クレカ払い, 銀行振込, 代引き…
売上種別(revenue_type) ：Stock売上, Flow売上…

のような「会計原子」の粒度がいいかもしれません。

とにかく、現在/過去/未来において、どんな粒度で分析・管理会計しうるか想像してデータの粒度を決めてください。

これは、会社のKPIや管理会計を実務的にやっている人や、事業責任者などにヒアリングしながら決めるのがいいでしょう。理想的には、そういった人自身が実装するのが良いです。

実装のポイントとデータフローのイメージ

フラクタル実現のポイントは、生の売上データを使わずに、一度、map3tフォーマットなど一定の「会計原子」の型にはめるということです。

一般に、企業は複数の売上計上ソースを持っています。課金方法や、商品、チャネルごとかもしれません。そして、それぞれ売上計上のための生データが存在するはずですが、それらフォーマットはバラバラです。

このとき、まず一度フォーマットを揃えきって「会計原子」を作ることが重要で、その時のデータフローは下図のようなイメージです。

Bigquery等データウェアハウス環境にて、SQLを活用して行うのが理想ですが、最初はExcelで行っても構いません。「まず、粒度を揃えて統合する」ということが最重要です。

ちなみに、このとき難しいのが、各データソース別の売上高をmap3t粒度で計算することです。もともと、map3t以上の解像度で集計されていればいいのですが、一般に経理部門は財務会計を目的としていますので、そこまで気の利いたことはしていません。

なので、いま売上計上に使っているExcelからロジックを丁寧に紐解いて、途中計算で情報量を落とすこと無く、map3t粒度で出力されるよう再現する(しかも理想的にはSQLで)、というタスクが発生します。
本気でやるならば、#2_次世代の管理会計分析環境「MF on SSOT」までの道のりを参考にするなどして、組織として本腰を入れるのがおすすめです。

まとめ

「Management by Fractal」とは、KPIや管理会計を、あたかも「フラクタル」な図形のように、同じ定義のKPIをあらゆる解像度で見られるようにし、あらゆる「マネジメント＝管理」に活かすことでした。

これを実現するのが、適切な「会計原子」の設定で、マネーフォワード社の場合はmap3tという粒度を採用しています。

重要なのは、まず一度各売上計上をmap3tなどの「会計原子」フォーマットに落とし込むことで、この要件定義と実装はExcelでやるにしても、ある程度タフなものになるでしょう。

最後に

「Management by Fractal」が一定完成したら、今度はこれを「SSOT＝Single Source of Truth」環境に乗せていくのがおすすめです。そこまでやりきることで、可用性高く安心して使える、管理会計/分析環境が完成します。(でないと、いつまでも「神Excel」止まりです)

この詳細な実装については、次回 『#4_マネフォが実践する「MF on SSOT」な分析基盤の構成』でご説明します。

なにかご不明点やご質問あれば、Twitterからお声掛けください！