Slide 1

Slide 1 text

スケールし続ける事業とサービスを支える 組織とアーキテクチャの生き残り戦略 2024年12月17日 FindyTools様イベント

Slide 2

Slide 2 text

黒田 翔太 2017 マネーフォワード入社 2022 マネーフォワードビジネスカンパニー VPoE 2017年にマネーフォワード入社後、 CTO室で 共通基盤を構築。その後クラウド会計開発や 組織マネジメントを担当。現在はビジネスカン パニーのVPoEとして、B2Bシステムとエンジ ニア組織の課題解決に取り組む。

Slide 3

Slide 3 text

今日お話すること 今年9月20日に開催されたマネーフォワー ドのテックカンファレンスで「マネーフォワー ドのエンジニアリング進化論」と題してキー ノートスピーチを行いました。今日はその 内容をベースに、より掘り下げた内容をお 伝えしようと思います。

Slide 4

Slide 4 text

今日お話すること ● マネーフォワードとは? ● マネーフォワードの生き残り戦略

Slide 5

Slide 5 text

マネーフォワードとは?

Slide 6

Slide 6 text

会社概要 ● 設立 ○ 2012年(13年目) ● 社員数 ○ 2,400人(24年5月末/連結) エンジニア・デザイナーが 約4割 ● 開発拠点 ○ 国内: 5拠点 東京、名古屋、大阪、京都、福岡 ○ 海外: 3拠点 ベトナム(ハノイ、ホーチミン)、インド 


Slide 7

Slide 7 text

ミッション / ビジョン Mission お金を前へ。人生をもっと前へ。 Vision すべての人の、「お金のプラットフォーム」 になる。

Slide 8

Slide 8 text

事業領域・プロダクト 法人向け バックオフィス向け  SaaS SaaSマーケティング支援 ファイナンスサービス 個人向け 金融機関等向け PFM(家計簿・資産管理)サービス Fintech推進・DX支援 法人・個人・金融機関向けに60を超える多数のプロダクトを展開

Slide 9

Slide 9 text

技術スタック 開発言語 Language バックエンド Backend Ruby / Go / Kotlin / Java / Python / Rust フロントエンド Frontend TypeScript / JavaScript モバイル Mobile Android: Kotlin / Java iOS: Swift / Objective-C CrossPlatform: Dart(Flutter) インフラ Infrastructure AWS / EKS / ECS / Kubernetes(On- Premises) / GCP Database MySQL / MongoDB / BigQuery

Slide 10

Slide 10 text

その他トピック ● 英語化、グローバル化 ○ エンジニア組織の公用語は英語 ○ エンジニアの40%超がグローバルメンバー、30を超える国籍のメンバーが活 躍 ● 共通基盤 ○ アカウントアグリゲーションや、認証基盤など、 60を超えるプロダクトを支える基 盤 ● マイクロサービス ○ 大規模なプロダクトはマイクロサービス化を進めている

Slide 11

Slide 11 text

マネーフォワードとは? - まとめ ● 国内海外を含む8つの開発拠点で、 ● 約1000人の多国籍なメンバーが、 ● 複数の事業領域にて、 ● 約60のプロダクトと、 ● それらを支える共通基盤、マイクロサービスを、 ● 日々開発している会社 なおかつ、創業以来今現在もスケールし続けている会社

Slide 12

Slide 12 text

マネーフォワードの 生き残り戦略

Slide 13

Slide 13 text

生き残り戦略 マネーフォワードは、順調にスケールしてきたように見えますが、過去に様々な課題 に直面しながらも、ダイナミックに変わる事業環境に結果として適応できたため、ここ まで生き残ることができました。 会社にとって生き残ることは非常に重要です。 どんなに素晴らしいミッションやビジョンを掲げていても、優れたアーキテクチャや組織 があったとしても、事業が存続できなければ、世の中に価値を届け続けることはでき ません。 マネーフォワードの過去直面してきた課題と、当時の生き残り戦略を共有することで、 皆様の今後の意思決定の一助となれば幸いです。

Slide 14

Slide 14 text

年表 MF Unit for ○○ スタートアップ期 充電期 拡大期 再編期

Slide 15

Slide 15 text

年表 MF Unit for ○○ スタートアップ期 充電期 拡大期 再編期

Slide 16

Slide 16 text

スタートアップ期 (2012年-2016年) 状況 ● 資金、人の不足💸 ● コア技術のアカウントアグリゲーション を活用した多角化🚀 ● B2B SaaS市場の急激な拡大💥

Slide 17

Slide 17 text

スタートアップ期 (2012年-2016年) 生き残り戦略 ● Rails + モノリスアーキテクチャを採用🏎 ● 権限委譲された自律的なスモールチーム(2 pizza rule)によるリーン開発🍕 ● 共有DBと共有ライブラリによる複数プロダクト展開🚀 ● コストが嵩むためAWSから脱却、半オンプレ環境に👋 ● 共通インフラチームが全プロダクトのインフラをメンテナンス󰞵 成功するかどうかわからないスタートアップとして、生き残るために何よりも スピード重視、技術的負債と引き換えにスピードを手に入れる

Slide 18

Slide 18 text

スタートアップ期の開発体制 ● 共通のインフラチームが機能開発以外を全て見る ● プロダクトの開発チームは機能開発に集中

Slide 19

Slide 19 text

アグリゲーションデータ、ユーザーデータを含 む数百億レコードのデータ 共有DB 2016年頃のアーキテクチャ アカウント アグリゲーション

Slide 20

Slide 20 text

桃園の誓いアーキテクチャ 共有DB アカウント アグリゲーション 我ら生まれた日は違えども、死す時は同じ日同じ時を願わん

Slide 21

Slide 21 text

年表 MF Unit for ○○ スタートアップ期 充電期 拡大期 再編期

Slide 22

Slide 22 text

充電期(2017年-2019年) 状況 ● 上場による資金調達💰 ● プロダクト数、ユーザー数、データ量 の増加📈 ● 桃園の誓いアーキテクチャのデメリッ トがメリットを上回る🍑 ● 共通インフラチームがボトルネックに 🚫

Slide 23

Slide 23 text

充電期(2017年-2019年) 生き残り戦略 ● 桃園脱却プロジェクトの開始🍑 ● インフラ構築・運用のセルフサービス化🤖 ● 地方拠点・ベトナム拠点の設立⛳ 引き続き自律的なスモールチームでスピード感のある開発をするために、技術的負 債の解消や基盤の整備、将来に向けての仕込みを実施

Slide 24

Slide 24 text

桃園脱却プロジェクト 共有DB アカウント アグリゲーション 桃園の誓いアーキテクチャの辛さ ● 全社障害の増加(給料日、月末月初、確定申告期間) ● 開発スピードの低下、影響範囲調査やテスト工数の増加 ● キャパシティの限界、スケールアップで逃げられない規模に アグリゲーションデータ、ユーザーデータを含 む数百億レコードのデータ

Slide 25

Slide 25 text

● 2017年頃 アグリゲーションAPIの導入 ○ 1000万を超えるユーザーの金融機関から取得したデータが日々蓄積され るため、データ量が多くキャパシティ上の懸念になっていた 桃園脱却プロジェクト 共有DB アカウント アグリゲーション Aggregation API

Slide 26

Slide 26 text

● 2018年頃 認証基盤の導入 ○ OpenID Connect準拠の認証基盤 ○ 他にも事業者・従業員基盤や、課金基盤などを導入 共有DBを使わずに新規プロダクト立ち上げが可能に => AWSが利用可能に 桃園脱却プロジェクト 共有DB アカウント アグリゲーション Money Forward ID Aggregation API

Slide 27

Slide 27 text

桃園脱却プロジェクト 共有DB アカウント アグリゲーション DB DB Money Forward ID Aggregation DB Aggregation API User DB ● 2019年頃~ 共有DBから個別DBへの移行 2017年のプロジェクト開始から、かれこれ8年かけて、2024年12月に主要なプロダ クトの桃園脱却が完了しました🎉

Slide 28

Slide 28 text

● 4年で積み上げた技術負債を返すのに8年かかった ○ ユーザーや、プロダクトの追加機能開発にできるだけ影響を与えず、根幹のアーキテク チャーを変更していくのは技術的にも難易度が高かった ○ プロダクト開発チームからすると桃園脱却の優先度は下がりがち ■ 桃園脱却専用チームを組成し、各プロダクト開発チームの桃園脱却を支援 ● 桃園の誓いは創業当時は良い選択だった ○ ベストではないが、スタートアップ期を生き残るためには必要な選択だった ● プロジェクトの中で主要な基盤が生まれ、後のプロダクト開発に良い影響を与えた 桃園脱却プロジェクトの振り返り

Slide 29

Slide 29 text

インフラ構築・運用のセルフサービス化 共通インフラチームの課題 ● プロダクトの数が増えるに従って、共通インフラチームの負担が増加。各チームか らの依頼に対応するだけで精一杯の状況に。 ● プロダクト開発エンジニアに比べ、インフラエンジニアは増えにくい状況。 ● 半オンプレ環境は、インフラエンジニア以外が扱うには難易度が高い。

Slide 30

Slide 30 text

インフラ構築・運用のセルフサービス化 ● AWS上でプロダクト開発チームがアプリケーショ ン実行環境を構築・運用できるセルフサービス型 のプラットフォームを提供(サービス・プラットフォー ム) ● 共通のインフラチームの責務を権限と共にプロダ クト開発チームに委譲 ○ アプリケーション実行環境の管理 => Docker ○ サーバーリソースの管理 => Kubernates ○ ミドルウェア(DB等)の管理 => AWS

Slide 31

Slide 31 text

サービス・プラットフォーム ● マルチアカウント+マルチテナントEKSクラスタ構成 ● k8sクラスタ運用や、セキュリティ・ガバナンスはインフラチーム ● 個別のサービスの実行環境・リソース・ミドルウェア管理は開発チーム

Slide 32

Slide 32 text

サービス・プラットフォーム ● インフラ構築・運用のためのマニュアル・テンプレートを整備 ● 開発チームは、Terraform/Kubernetesのマニフェストを作成し、適用 ● 必要に応じてインフラチームでレビュー

Slide 33

Slide 33 text

年表 MF Unit for ○○ スタートアップ期 充電期 拡大期 再編期

Slide 34

Slide 34 text

拡大期(2020年-2022年) 状況 ● 共通基盤整備によりサービス立ち上 げが容易に💪 ● B2Bの中堅企業領域への進出🚀 ● 個々のプロダクトの大規模化📈 ● 事業拡大の上でエンジニア採用がボ トルネックに🚫

Slide 35

Slide 35 text

拡大期(2020年-2022年) 生き残り戦略 ● 海外拠点の拡大󰑜󰏝 ● エンジニア組織の英語化、グローバル採用開始🌏 ● プロダクトチームに権限委譲して、次々にプロダクト立ち上げ🚀 ● 大規模プロダクトのマイクロサービス化🌐 充電期の取り組みと、海外拠点・グローバル採用による人材拡充が上手く組み合わ さり、スモールチームによるプロダクト立ち上げ、マイクロサービス化が爆発的に進ん だ

Slide 36

Slide 36 text

年表 MF Unit for ○○ スタートアップ期 充電期 拡大期 再編期 爆発的なプロダクト数の伸び 🚀

Slide 37

Slide 37 text

年表 MF Unit for ○○ スタートアップ期 充電期 拡大期 再編期

Slide 38

Slide 38 text

再編期(2023年-) 状況 ● サービス数の爆発的増加📈 ● 行き過ぎた個別最適によるUX、開発 効率の低下📉 ● グローバル化の進展、多拠点開発の 増加🌏 ● スモールチーム間のコミュニケーショ ンコスト増加🔀

Slide 39

Slide 39 text

再編期(2023年-) 生き残り戦略 ● 標準化や共通化の推進🧭 ● 横断組織の強化、プラットフォームエンジニアリングの導入💪 ● チーム間のコミュニケーションの再編・役割定義🌏 プロダクトが爆発的に増えた結果、スモールチームで個別最適にプロダクト開発を進 めるデメリットが無視できなくなってきた。中長期視点での全体最適と個別最適のバラ ンスを探ることが必要になっている。

Slide 40

Slide 40 text

まとめ

Slide 41

Slide 41 text

まとめ マネーフォワードの生き残り戦略を振り返ると、スピード重視、権限委譲、自律的なス モールチームという勝ちパターンがあり、それをどう維持するかを考えて、取り巻く状 況に応じてアーキテクチャや組織を変えてきた会社と言えると思います。スタートアッ プで信用も資金力もなかった私達が他のプレイヤーに対抗しうる唯一の武器はス ピードであり、それを最大限に発揮するために上記の勝ちパターンを拠り所にしてい ました。結果として、変化の激しい事業環境にも対応し、生き残ることができました。 会社により事業環境は異なりますが、その環境の中で持続的に発展するための勝ち パターンを見極め、それを支えるアーキテクチャや組織を考えることが、生き残り戦 略につながると考えています。

Slide 42

Slide 42 text

Thank you!