マネフォの管理会計基盤の紹介〜データ組織を立ち上げたらまずここを握れ〜
イントロダクション
こんにちは。マネーフォワード データ戦略室 分析推進部のササキです。
今回は、マネーフォワードで全社横断のデータ分析組織を立ち上げていく過程で構築した管理会計基盤について紹介させていただきたいと思います。
と言ってもデータモデリング寄りの技術的な話ではなく、構築から4年が過ぎたこの基盤について、どちらかというと運用的な観点でやっておいてよかったことや、やっておけばよかったことがちらほら出てきたので、それらを今回は整理してみます。
補足：分析推進室の成り立ち
最初にちょっとだけ補足すると、全社横断でデータ利活用を推進する分析推進部の前身となる分析推進室が立ち上がったのは、まさにこの管理会計分析におけるデータが散在していたことが元となる課題感からでした。
データ利活用の推進組織がこういった背景で検討され、形になっていくケースは珍しい気もするのですが、当時の室長が経営企画×データ分析という稀有なスキルセットを持っていたこともあり、経営寄りの分析と現場寄りの分析の両立を目指して全社横断のデータ利活用組織が立ち上げられました。
詳細は後述しますが、結果的にこの成り立ちはデータ分析基盤を構築し、データ利活用を推進する上で大きなメリットがあったと感じています。
管理会計基盤を運用する上で握っておくべきこと6選！
管理会計基盤を運用する上でちゃんと握っておくことが大切だと思うことを、6つ挙げてみました。
「握る」というのはあまり一般的な言葉使いではないかもしれないですが（そして”おじさんビジネス用語”かもしれませんが笑）、関係者間で認識を合意しておくこととして使います。響きが面白く、個人的にはなんとなく手を繋いで共に進むような風景も頭に浮かぶため、今回は敢えてこの言葉を使って表現してみようと思います。
1. 上流としての業務データソースを握る
2. 下流としてのレポーティングを握る
3. 全体としてのデータパイプラインを握る
4. 自動化しきれない領域を握る
5. 担当組織の責務を握る
6. 重要な取り組みであるという共通理解を握る
6つだと多いようにも感じられるのですが、カテゴリに分けると、
データ/システム、運用、組織/責務の3つに分けられそうですね。
大枠としてはデータの上流〜下流を意識しつつ、全体のパイプラインマネジメントを行うことが肝要だという話なのですが、取り扱うデータの性質上、いわゆる技術的なエンジニアリングのみでは解決できないことも多く発生します。
その辺りを含め、ここから一つずつ説明していきます。
1.上流にある業務データソースを握る
まずは、上流に存在している業務システムのデータソースを握りにいきましょう。認識を合わせるべきカウンターパートは、主に業務システムの開発組織になります。
ここで意識すべきなのはインプットデータを適切に理解することと、それをいかに壊さないまま管理会計基盤に流し込み続けるか、の二点になります。
管理会計に必要なデータ群には様々なものがあると思います。スキーマやレコードの更新頻度、集計定義のみではなく、仕様の変更可能性についても確認しておくと良いでしょう。
また、仕様が変わった際、適切に情報共有をしてもらう仕組みも構築しておく必要があります。極端な例ですが、業務システムの開発・運用チームがデータを分析利用していることを認識していなかった場合、分析上重要なログテーブルが突然削除されたりする可能性があります。
マネーフォワードのように多くのマイクロサービスを開発・運用している組織だと、この握りがより重要になってきます。複数のサービスで同時にリリースが走った場合、分析基盤チームの対応コストがかさみ一時的に誤ったデータが流れ続けてしまう、もしくはデータ連携自体が止まってしまう危険性があります。
運用の負荷観点では、連携してもらうデータのレイアウトを分析側から指定し、あとはAPI的に流し込むだけという落とし所もあるかもしれません。
ただし、分析基盤側で任意の軸でドリルダウンしたりする場合、いわゆるELT方式でデータを分析チームの管理領域に持ってきておいて、分析組織側で分析用にデータモデリングを行う方が結果的にメリットが大きいように個人的には思います。Modern Data Stackが充実してきていることもあり、分析用データモデリングの実装・運用ハードルが下がっていることもこの方針を加速する一因ではないでしょうか。
2.下流にあるレポーティングを握る
分析基盤の下流にどういうレポーティングが行われているかも出来るだけ網羅的に認識しておくことが望ましいです。
どういった頻度で、どのチームが、どのデータを使ったレポートを、どういった会議体で利用しているかくらいの粒度で把握しておけると良いでしょう。
認識を合わせるべきカウンターパートは、主に経営層や事業部長等組織マネジャー陣に加え、データに感度の高いメンバーが挙げられます。
これは、自分たちで管理しているデータ・指標が独り歩きしてしまうことを防ぐことが目的です。
いわゆる「データの民主化」が進むと、データのみではなく集計後の指標”だけ”を見て意思決定をするメンバーが増えてきます。
これ自体は悪いことではありませんが、誤った定義理解で意思決定が進んでしまうことはデータ組織としても避けるべきですよね。
データの仕様や集計定義、実装内容は明確にドキュメント化しておきましょう。データの整備業務はこういった地道な取り組みが実は重要だったりします（苦手意識を持ってしまう気持ちはとてもわかります笑）。
また、可能であれば、各指標について深掘りができるようにデータモデリングをしておくとなお良しです。この辺りは別の記事でまた改めてちゃんと整理できればと思いますが、スタースキーマの考え方を参考に「集計したい項目（メジャー）」と「分析したい切り口（ディメンション）」の二つとその粒度を意識しながらデータマート生成をすると良いと思います。
3.全体としてのデータパイプラインを握る
上流と下流について握ることに合わせて、自分たちが管理しているデータパイプラインの全体像をしっかり握っておきましょう。
このトピックについては、自組織内でしっかり認識を合わせておければ良いと思います。
認識がずれやすいポイントとしてはエラー発生時の復旧目標や担当体制等、対応方針が挙げられます。
最優先で意識すべきは、”意図せず”データが更新されていないことをどう防ぐかです。
上述の二つを握る過程でデータパイプラインに求められる要件が明確になっているはずなので、ETL（ELT）のタイミングや頻度、エラーキャッチ方法については比較的スムーズに決めていけると思います。
弊社では、基本的にユニークテストと非Nullテストを全てのテーブルについて実装するようにしていることに加え、SaaSビジネスにおけるストック型の売上等、ビジネスモデル上、対前月でマイナスにならないはずのいくつかの指標についてはテストロジックを追加してパイプラインを実装しています。
このトピックはどこまでやっても完璧とは言えない領域なので、また別でまとめたり、他のデータ組織とディスカッションしたいポイントです（我々も悩んでいます）。
4.自動化しきれない領域を握る
例えばiOSアプリの売上等のAPIが提供されていないシステムから得られる情報や、パートナーさん経由での売り上げ等、その作業の更新スケジュールや担当体制を把握し、予め情報共有観点で連携しておくことも重要です。
具体的にはSlackでチャンネルを作っておいたり、何かあった際の問い合わせ先を相互に指定し、作業マニュアルに書いておくところまで業務を定義しておくと非常に安心ですね。
認識を合わせるべきカウンターパートは、各組織で売上管理をしているチームや経理担当者が挙げられます。
ビジネス活動をデジタル化していく取り組みにおいて、情報更新に必要な手作業オペレーションはどうしても一定発生してしまうものです。
根本解決として、手作業オペレーション自体を無くすという大きな方針を目指すべきではありますが、規模の大きな基盤構築では一定の手運用を許容しつつ関係者間の合意や連携でスピード感を保つことも重要です。
5.担当組織の責務を握る
ここまではデータの流れを軸に握るべきことについて整理してきましたが、関連して組織側の責務範囲を明確にしておくことが重要です。
認識を合わせるべきカウンターパートは、ここでも経営層やマネジャー陣が挙げられることに加え、事業企画チームや経営企画チームとも会話しておけると良いでしょう。
理想的には権限と責任を一致させたいところですが、データを分析用途で取り扱うという観点に立つと、キャパシティとケイパビリティを考えたときに理想通りに行かないケースもあるかと思います。また、使っているツールによってもケイパビリティの壁は生まれがちで、関連組織にそのスキルをキャッチアップしてもらう負荷を許容できず、データ組織が浸み出していく必要性がありました。
例えば、Lookerによるレポート提供をしていた際、レポート先の事業部長陣にその使い方をどこまで覚えてもらうかが論点になります。
構築されたダッシュボードに関するドキュメントの整備に加え、フィルタ設定やクリックを通じたドリルダウンまで使いこなせることを求めるのは、決して簡単なことではありませんでした。事業部長陣を含めた弊社メンバーは新しいツールや取り組みに協力的な方が多いため比較的スムーズに進んだ方だとは思いますが、世の中的にはここをどう分担するかで一定の調整コストがかかりそうなイメージがあります。
弊社では、上述のダッシュボード利用までを事業部側メンバーの担当とし、さらにハードルが上がるLookerでいうところのExploreやLookMLによるモデリングについてはデータ組織がビジネスを深くキャッチアップし、ダッシュボードの構築までを担当する体制とすることにしました。
分析推進部では、過去から「輩出」という取り組みを通じて事業部に人を送り出しています。
この取り組みでは、データ基盤やツールに関するナレッジが中央から事業部へ、また、輩出者は中央側に兼務を残すことでビジネスに関する深いナレッジが事業部から中央に流通することを期待しています。ナレッジがもっと流通した場合、現状の担当体制は見直される可能性があるなと個人的には思っており、事業部側でExploreやLookMLによるモデリングまで分担できると、よりスピード感のあるデータ利活用が進むだろうなという予感がしています。
6.重要な取り組みであるという共通理解を握る
データ組織の立ち上げは各社さまざまな課題感からスタートすることが多いかと思いますが、経営レイヤーでの意思決定に活用されるレポーティングを開始点として取り組むのが個人的にはおすすめです。
なぜなら、取り組みの重要度が自明で、リソースを投資することが合理的だという前提でプロジェクトを進められるからです。
偉大なる先人たちの努力の成果として、今ではデータ利活用に至る道のりは想像より険しく長いことが共通認識になってきていますが、データ利活用の初期段階ではデータを計測・集約し、分析用にモデリングしていくことから始まるケースが多いかと思うので、この段階から投資対効果を求められると説明が苦しくなりがちです。
この点において、社長の辻さんからは「データ利活用は当然重要な取り組みなので、費用対効果の説明に時間を使うくらいならもっといろんなものを可視化してほしい（意訳）」と言って背中を押してくださっており、非常に心強かったことをよく覚えています。
唯一想定される反論としては「既に一定の集計・可視化ができているのでその取り組みには協力できない/投資できない」というものでしょうか。もちろん、事業運営において重要なトピックだと思うので、分析組織の不在時点でも全く何の数字も見られていない、という状況にはなっていないはずです。
ここで、私がいつも聞くようにしているのは「その集計・可視化は属人化していないか？」「その集計結果を深掘りしたい時、スピーディかつ誤りなく実施できるか？」の二つの質問です。
属人化していたり、深掘りができない状態になっている際には、やはり体制を組んでSSoTとしてのデータ基盤を構築することが必要です。”今じゃない”ケースはあるかもしれませんが、事業が拡大していく過程で避けては通れない命題だと思うので、なるべく早く取り組み始めることをおすすめします。
最後に
改めて整理するとこういった形になりましたが、もちろん全てを意図的に進められたわけではありません。こういった影響範囲の大きい取り組みは、理想形がなんとなく見えていてもある程度時間をかけて合意形成する必要があることも多く、その都度負債を認識しつつ後から返済することを決めて進んだ部分もあります。
いわばデータ基盤のプロダクトマネジメントとも言える取り組みだったなと感じており、組織長として方針決定をしてきたことをいろいろあったなと振り返りつつまとめてみました。しんどい瞬間もあったとは思うのですが、そんな中でも重要な取り組みであることを共通認識とし、本質的な課題に向き合って前向きに取り組んでくださったチームメンバーには感謝以上に尊敬の気持ちを抱いています。
また、直接的にデータ基盤を利用するわけではなくとも、必要性を理解しオペレーションの変更等を受け入れて下さった関連チームの皆様にも心から感謝をしています。
ちょっとエモーショナルな流れになりましたが、実は上述の「輩出」という取り組みに関連し私自身も直近で異動しており、今は個別事業部のデータ分析/マネジメントに取り組んでいます。
解決しきれなかった課題も残ってしまったにも関わらず後任を引き受けてくださった同僚に重ね重ね感謝しつつ、事業部でのデータ利活用の難しさや面白みについて次回以降また発信していければと思っておりますので、引き続きよろしくお願いいたします。
この記事が気に入ったらサポートをしてみませんか？