事業企画(FP&A)の立ち上げと打ち手としてのデータ基盤整備の話
はじめに
はじめまして！
マネーフォワードのクラウドERP本部事業企画部（FP＆A）・分析推進部兼務の佐野です！
2024年4月にNIKKEIリスキリングに記事が掲載されました！
クラウドERP本部事業企画部は、成長企業・中堅企業向けクラウド型ERPのビジネス戦略や短期の販売戦略、予算策定を担当する部署です。その中でも私はビジネスの計画を策定し、どのような損益が生まれるのかの見立ての作成から実際の検証までを現在担当しています。
今までを振り返りデータアナリストから事業部に異動した際に、当初どのような組織課題があり、なぜ打ち手としてデータ分析基盤整備を選択したかを整理しました。
事業企画：FP＆Aの設立を検討している方や、データドリブンな事業推進を志向している方々に参考になれば幸いです。
具体的には、下記のような方を想定読者としています。
事業企画：FP＆Aという仕事に興味のある方
データ基盤を事業推進上どのように活かすか悩んでいる方
横断組織から事業部へ
マネーフォワードの横断組織である分析推進部では、「輩出」という取り組みを通じて事業部に人を送り出す取り組みを行っています。私は「分析推進部」から事業部の「クラウドERP本部」に「輩出」されることになりました。「輩出」の目的としては、スピーディーに事業コンテクストを理解したり、スケールする組織で全体最適な分析の仕組みを整えるなどです。
詳しくは下記のnoteを御覧ください。
「輩出」にあたり、本部長との役割期待をすり合わせたところ、計数管理を全般的におまかせしたいと言っていただきました。また、データ分析だけでなく、本部のPL数値管理もスコープに入りました。
私の前職では会計を主軸に活動していたため、強みも活かせるポジションに行けると感じました。一方で、会計とデータ分析をつなげてどのように事業に具体化させるのかはあまり経験がなかったため、チャレンジングな領域だと感じました。
現状把握
異動してしばらくは計数管理を任されました。ちょうど組織は拡大期にあり、多くの部門と多種多様な指標が作成されていることを知りました。組織内ではthe model型の組織を取り、それぞれの部門内では日々計画や施策が行われ、現場が主体的に活動していました。
しかし、下記のような問題も見えてきました。
個別の施策が全体方針と整合していない
標準化した指標やオペレーションがなく、運用が属人化している
部門ごとに特化した施策が増え、全体の方針との整合性が問題となりました。その結果、一見良さそうな行動でも全体としては効果が薄いケースが見られるようになりました。
また、指標やオペレーションも部門ごとに異なり、属人化が進行していました。アドホックに指標を出すにしても、SQLの読み解き、定義のすり合わせから毎度始まり１週間かかっていました。その結果、事業環境の急速な変化の中で、施策の方向性や実行スピードが問題となっていたのです。
今後の方針
理想としては、シンプルに事業活動が正しい方向に向き、施策実行にスピードがでる組織状態がベストです。すでに現場は強い組織であったので、中央で取りまとめする機能があるとより強くなるのではと考えました。本稿では、重要度の高かった事業活動が正しい方向に向くことについてフォーカスしていきたいと思います。
では、事業活動が正しい方向を向くための要素を以下のように３つに分解します。
計画
統制
蓋然性
1.計画
まず、正しい方向性とは何かを決めるために、ミッション・中長期計画・短期計画を作成します。他社も同様のやり方かと思いますが全社方針→ドメイン方針→本部方針と中長期計画・短期（年度や月次）計画を逆算的に作成していきます。
一方で、当時は本部方針を作成するときに、本部内の各部長がそれぞれの部門計画を作成してそれらを統合していました。このため各部門の計画を調整・統合する必要があり、すり合わせにかなりのコストが掛かっていました。そこで初手として、本部方針のたたき台を作成して部長陣と調整するところから始めました。
2.統制
次に、正しい方向性が決まり進行していくときに、道がそれていないかをチェックする機能が必要となります。道がそれていればその要因調査をして、元の正しい方向に進行するか、元の計画自体に問題なかったかを考え、いずれかを改善していきます。
実際これらの統制機能については、部門内で短期計画内の範囲で継続的かつ反復的に行われていました。
一方で、本部目標やPLなど鷹の目の視点から部門・個人単位の虫の目の振り返りは定期的にはおこなわれていませんでした。これには次の2つの理由があります。
PLから各部のKPIにブレイクダウンするときの情報の入手がカオスで、コストがかかっていた
PLを専門的に扱う部署がなく、PL自体を普段から扱うことがなかったため、この読み解き自体が一部の担当者しかしていない状態だった
この統制の方法も、全体→部分と予実比較ができるようにする仕組みを整えられるようにしていこうと考えました。
3.蓋然性
上述した計画と統制に加えて3番目に重要な要素として蓋然性を加えました。蓋然性を簡単に言うと、計画と統制の成功確率を上げていくことです。通常、計画と統制を行う場合は定性だけではなく定量情報を扱っていきます。ただ、定量情報は整備しないとある程度粗い情報でとどまってしまうため、見切りをつけていく対象でもありました。現在だと、データウェアハウスなどのデータ整備の分野が確立され始めており、統計や機械学習などのデータサイエンスがビジネスにも適用され始めています。マネーフォワードのビジネス環境でも同じくROI高くデータ活用ができるのではと考えていました。
実際に、事業部ではSQLを使って部門内の指標を算出しているところがありました。一方で、同じ受注と言っても定義・算出方法が異なりサイロ化した状態だったり、受注率やリード経路別売上のような部門を跨ぐ指標算出には大きく伸びしろがありました。データアナリストたるもの、統計など使いたい気持ちがありましたが、まずはしっかりデータ整備をして、適切なクロス集計をできる状態を目指しました。その結果、計画と統制の正確さをあげていければと考えました。
打ち手
これらの方針を継続的に達成していくために、以下の3つにまず取り組みました
組織体制の構築
SSoTなデータ基盤整備
オペレーション最適化
1.組織体制の構築
計画と統制を継続的に行っていくため、部門を設立していこうと考えました。なぜならば、ナレッジをため、人材を育成する仕組みがあると長い目でスケールしていくのではと考えたためです。ただ、個人でやるより部格化すると育成コストや人事評価、その他事務などの作業などのコストが発生します。一方で、長い目で見るとそれを超えるメリットがあると感じ、経営陣との相談のもと事業企画部を組成しました。
冗談のようですが部の名前については悩みました。計画と統制を専門的に扱うため、事業サイドの経営企画的なポジションを検討しました。このため、「事業企画」が既に世にあったため、それを使用させていただきました。英語名はFP＆A（Financial Planning and Analytics）です。
最初は私1名からはじまる部門でした。その後SQLが使えるマーケターやデータ整備をメインで担当してくれる方がジョインしてくれて、今では事業戦略担当やオペレーション担当などの様々なタレントの方々が所属する部門となりました。
2.SSoTなデータ基盤整備
計画と統制を行う上で、ある程度精度の高い情報を低コストで入手できる環境を作りました。ところが、計画や施策の重要性を判断する情報が様々なところに散らばっており、定義もバラバラとなっていました。こういった背景からSSoT:Single Source of Trustなデータ基盤をチームで整備していきました。
まずデータ基盤の目的として、各部門の成果が最終的にはPLに影響するものだと仮定して、PLを分解していくとセールスの商談やマーケティングのリード、そして市場白地がわかるようにする状態にするとしました。そのため、まず地道にKPIの言葉の定義からすり合わせしてドキュメント化しました。
さらに、SQLにて売上データマート・コストデータマート・商談データマート・リードデータマート・市場データマートをチームで開発していきました。その後、それぞれのデータを紐づけていき、市場・セールスとマーケティングの社内活動・PLのファネルのデータマートを整備していきました。
より標準化と低コストを意識して、BigQueryにプロジェクトを作成し、ワークフローエンジンで自動でデータマートを更新する仕組みを整えていきました。SQLについてはgithubでversion管理しています。こちらは、チームと横断組織である分析推進部の手を借りながら徐々に整えていきました。
分析基盤の変遷はこちらで詳細に述べております。
また、事業部内にデータ基盤を作成するため、非エンジニアでも継続的に運用できる仕組みもスコープに入れました。具体的にはツールの選定と人材育成の仕組みを整えていきました。なぜならば、事業部にはデータのスペシャリストがいるわけではなかったためです。
当時は横断組織ではAirflowを使用していており、私自身too much感を抱いていました。このため、開発がほぼSQLとGUIで行えて、品質担保のためのassertionを簡易に設定できるDataformを採用しました。
なお、基本的には分析推進部のテーブルを元にデータマートを作成して、SSoTを担保しました。
さらに、私が明日いなくなっても続けていける仕組みを作るために、SQLとDataformを扱える人材育成に取り組みました。すでにSQLを使えた人材にデータ整備のナレッジトランスファーを行ったり、非エンジニア向けの教育コンテンツの整備や集中特訓講座などを行いました。 その結果、最初は１名と兼務の方のみで整備した環境も、今では複数人のチームで基盤運用をするに至りました。
3.オペレーション最適化
オペレーションについても、以下の観点から全体最適での仕組みを整えるようにしました。
「動かす」
実態と合ったデータのインプットをするため
計画や個別の施策を行うにせよ、オペレーションまで入らないと物事を「動かす」ことが難しいと感じました。なぜなら、オペレーションの負荷を検討せずに施策を企画すると現場がスタックしてしまうからです。また、複雑なオペレーションのまま進行してしまうと属人化する傾向にあり、中途入社や部署異動のオンボーディング期間が伸びてしまい、結果的に実行段階で時間がかかるといったことがあります。全体の計画を負う部署がオペレーション全体を折に触れて見直すように、まずはチーム内外の力を借りて業務プロセスの設計をしました。
また、マーケティングデータとは違い、セールスの大半のデータは人の手を介在して非機械的に入力されることに今更ながら気づきました。このため、計画と統制のための正しい情報を取得するために、適切なオペレーションを組んでデータを入力する必要があります。それでも全てのデータを取得しようとすると今度は手入力の負荷が増えてきます。重要な情報だけをとるスコープマネジメントを行う、営業デスクを設置して入力負荷を分散する、入力するインターフェースの改善するなど、これらを継続的に実施しました。
結果
打ち手を実行していった結果、事業企画が計画と統制を中心に行うようになりました。具体的には、短期事業計画・年度予算作成の担当を担い、各部単位の月次KPIの目標の作成と予実比較を行うようになりました。
また、SSoTなデータ基盤やオペレーションが整ってきて、事業計画を作成する情報を迅速に取得できるようになりました。以前だと、各部門に依頼→定義の確認→ツギハギデータの取得で計画に用いていたのを、データ基盤にアクセスして事業企画内で計画を完結できるようになりました。
もともと、１週間かかって算出していたKPIも、定義がすりあっているBigQueryにアクセスするだけで、数秒で情報を得られるようになり、要因調査のスピードが圧倒的に早くなりました。
このため、事業運用でPL不調だった場合に、各種KPIの要因調査を定量的に早く行うことができ、迅速に打ち手を検討できるようになりました。また施策の見立を作成するときでも、その結果PLにどれくらいのインパクトが有るのかといった議論もできるようになり、まだまだ道半ばですが重要性の判断も徐々に可能になりました。
おわりに
多事業展開しているマネーフォワードにおける事業企画&データ活用の取り組みはチャレンジングですが、世の中でこの経験ができる企業はそんなに多くないのではないでしょうか。
もし、少しでも興味のある方はコミュニケーションできればと思いますので、ご応募心よりお待ちしております！
この記事が気に入ったらサポートをしてみませんか？