スケールし続ける事業とサービスを支える組織とアーキテクチャの生き残り戦略 / The survival strategy for Money Forward’s engineering.

2024年12月17日開催の『モノタロウCTOとマネーフォワードVPoEが語る「大規模リアーキテクチャ」』で発表した内容となります。
https://findy-tools.connpass.com/event/337021/

Transcript

1. スケールし続ける事業とサービスを支える 組織とアーキテクチャの生き残り戦略 2024年12月17日 FindyTools様イベント
2. 黒田 翔太 2017 マネーフォワード入社 2022 マネーフォワードビジネスカンパニー VPoE 2017年にマネーフォワード入社後、 CTO室で 共通基盤を構築。その後クラウド会計開発や 組織マネジメントを担当。現在はビジネスカン パニーのVPoEとして、B2Bシステムとエンジ ニア組織の課題解決に取り組む。
3. 今日お話すること 今年9月20日に開催されたマネーフォワー ドのテックカンファレンスで「マネーフォワー ドのエンジニアリング進化論」と題してキー ノートスピーチを行いました。今日はその 内容をベースに、より掘り下げた内容をお 伝えしようと思います。
4. 今日お話すること • マネーフォワードとは？ • マネーフォワードの生き残り戦略
5. マネーフォワードとは？
6. 会社概要 • 設立 ◦ 2012年(13年目) • 社員数 ◦ 2,400人(24年5月末/連結) エンジニア・デザイナーが 約4割 • 開発拠点 ◦ 国内: 5拠点 東京、名古屋、大阪、京都、福岡 ◦ 海外: 3拠点 ベトナム(ハノイ、ホーチミン)、インド 

7. ミッション / ビジョン Mission お金を前へ。人生をもっと前へ。 Vision すべての人の、「お金のプラットフォーム」 になる。
8. 事業領域・プロダクト 法人向け バックオフィス向け　 SaaS SaaSマーケティング支援 ファイナンスサービス 個人向け 金融機関等向け PFM（家計簿・資産管理）サービス Fintech推進・DX支援 法人・個人・金融機関向けに60を超える多数のプロダクトを展開
9. 技術スタック 開発言語 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
10. その他トピック • 英語化、グローバル化 ◦ エンジニア組織の公用語は英語 ◦ エンジニアの40%超がグローバルメンバー、30を超える国籍のメンバーが活 躍 • 共通基盤 ◦ アカウントアグリゲーションや、認証基盤など、 60を超えるプロダクトを支える基 盤 • マイクロサービス ◦ 大規模なプロダクトはマイクロサービス化を進めている
11. マネーフォワードとは？ - まとめ • 国内海外を含む8つの開発拠点で、 • 約1000人の多国籍なメンバーが、 • 複数の事業領域にて、 • 約60のプロダクトと、 • それらを支える共通基盤、マイクロサービスを、 • 日々開発している会社 なおかつ、創業以来今現在もスケールし続けている会社
12. マネーフォワードの 生き残り戦略
13. 生き残り戦略 マネーフォワードは、順調にスケールしてきたように見えますが、過去に様々な課題 に直面しながらも、ダイナミックに変わる事業環境に結果として適応できたため、ここ まで生き残ることができました。 会社にとって生き残ることは非常に重要です。 どんなに素晴らしいミッションやビジョンを掲げていても、優れたアーキテクチャや組織 があったとしても、事業が存続できなければ、世の中に価値を届け続けることはでき ません。 マネーフォワードの過去直面してきた課題と、当時の生き残り戦略を共有することで、 皆様の今後の意思決定の一助となれば幸いです。
14. 年表 MF Unit for ◦◦ スタートアップ期 充電期 拡大期 再編期
15. 年表 MF Unit for ◦◦ スタートアップ期 充電期 拡大期 再編期
16. スタートアップ期 (2012年-2016年) 状況 • 資金、人の不足💸 • コア技術のアカウントアグリゲーション を活用した多角化🚀 • B2B SaaS市場の急激な拡大💥
17. スタートアップ期 (2012年-2016年) 生き残り戦略 • Rails + モノリスアーキテクチャを採用🏎 • 権限委譲された自律的なスモールチーム(2 pizza rule)によるリーン開発🍕 • 共有DBと共有ライブラリによる複数プロダクト展開🚀 • コストが嵩むためAWSから脱却、半オンプレ環境に👋 • 共通インフラチームが全プロダクトのインフラをメンテナンス󰞵 成功するかどうかわからないスタートアップとして、生き残るために何よりも スピード重視、技術的負債と引き換えにスピードを手に入れる
18. スタートアップ期の開発体制 • 共通のインフラチームが機能開発以外を全て見る • プロダクトの開発チームは機能開発に集中
19. アグリゲーションデータ、ユーザーデータを含 む数百億レコードのデータ 共有DB 2016年頃のアーキテクチャ アカウント アグリゲーション
20. 桃園の誓いアーキテクチャ 共有DB アカウント アグリゲーション 我ら生まれた日は違えども、死す時は同じ日同じ時を願わん
21. 年表 MF Unit for ◦◦ スタートアップ期 充電期 拡大期 再編期
22. 充電期(2017年-2019年) 状況 • 上場による資金調達💰 • プロダクト数、ユーザー数、データ量 の増加📈 • 桃園の誓いアーキテクチャのデメリッ トがメリットを上回る🍑 • 共通インフラチームがボトルネックに 🚫
23. 充電期(2017年-2019年) 生き残り戦略 • 桃園脱却プロジェクトの開始🍑 • インフラ構築・運用のセルフサービス化🤖 • 地方拠点・ベトナム拠点の設立⛳ 引き続き自律的なスモールチームでスピード感のある開発をするために、技術的負 債の解消や基盤の整備、将来に向けての仕込みを実施
24. 桃園脱却プロジェクト 共有DB アカウント アグリゲーション 桃園の誓いアーキテクチャの辛さ • 全社障害の増加(給料日、月末月初、確定申告期間) • 開発スピードの低下、影響範囲調査やテスト工数の増加 • キャパシティの限界、スケールアップで逃げられない規模に アグリゲーションデータ、ユーザーデータを含 む数百億レコードのデータ
25. • 2017年頃 アグリゲーションAPIの導入 ◦ 1000万を超えるユーザーの金融機関から取得したデータが日々蓄積され るため、データ量が多くキャパシティ上の懸念になっていた 桃園脱却プロジェクト 共有DB アカウント アグリゲーション Aggregation API
26. • 2018年頃 認証基盤の導入 ◦ OpenID Connect準拠の認証基盤 ◦ 他にも事業者・従業員基盤や、課金基盤などを導入 共有DBを使わずに新規プロダクト立ち上げが可能に => AWSが利用可能に 桃園脱却プロジェクト 共有DB アカウント アグリゲーション Money Forward ID Aggregation API
27. 桃園脱却プロジェクト 共有DB アカウント アグリゲーション DB DB Money Forward ID Aggregation DB Aggregation API User DB • 2019年頃~ 共有DBから個別DBへの移行 2017年のプロジェクト開始から、かれこれ8年かけて、2024年12月に主要なプロダ クトの桃園脱却が完了しました🎉
28. • 4年で積み上げた技術負債を返すのに8年かかった ◦ ユーザーや、プロダクトの追加機能開発にできるだけ影響を与えず、根幹のアーキテク チャーを変更していくのは技術的にも難易度が高かった ◦ プロダクト開発チームからすると桃園脱却の優先度は下がりがち ▪ 桃園脱却専用チームを組成し、各プロダクト開発チームの桃園脱却を支援 • 桃園の誓いは創業当時は良い選択だった ◦ ベストではないが、スタートアップ期を生き残るためには必要な選択だった • プロジェクトの中で主要な基盤が生まれ、後のプロダクト開発に良い影響を与えた 桃園脱却プロジェクトの振り返り
29. インフラ構築・運用のセルフサービス化 共通インフラチームの課題 • プロダクトの数が増えるに従って、共通インフラチームの負担が増加。各チームか らの依頼に対応するだけで精一杯の状況に。 • プロダクト開発エンジニアに比べ、インフラエンジニアは増えにくい状況。 • 半オンプレ環境は、インフラエンジニア以外が扱うには難易度が高い。
30. インフラ構築・運用のセルフサービス化 • AWS上でプロダクト開発チームがアプリケーショ ン実行環境を構築・運用できるセルフサービス型 のプラットフォームを提供(サービス・プラットフォー ム) • 共通のインフラチームの責務を権限と共にプロダ クト開発チームに委譲 ◦ アプリケーション実行環境の管理 => Docker ◦ サーバーリソースの管理 => Kubernates ◦ ミドルウェア(DB等)の管理 => AWS
31. サービス・プラットフォーム • マルチアカウント+マルチテナントEKSクラスタ構成 • k8sクラスタ運用や、セキュリティ・ガバナンスはインフラチーム • 個別のサービスの実行環境・リソース・ミドルウェア管理は開発チーム
32. サービス・プラットフォーム • インフラ構築・運用のためのマニュアル・テンプレートを整備 • 開発チームは、Terraform/Kubernetesのマニフェストを作成し、適用 • 必要に応じてインフラチームでレビュー
33. 年表 MF Unit for ◦◦ スタートアップ期 充電期 拡大期 再編期
34. 拡大期(2020年-2022年) 状況 • 共通基盤整備によりサービス立ち上 げが容易に💪 • B2Bの中堅企業領域への進出🚀 • 個々のプロダクトの大規模化📈 • 事業拡大の上でエンジニア採用がボ トルネックに🚫
35. 拡大期(2020年-2022年) 生き残り戦略 • 海外拠点の拡大󰑜󰏝 • エンジニア組織の英語化、グローバル採用開始🌏 • プロダクトチームに権限委譲して、次々にプロダクト立ち上げ🚀 • 大規模プロダクトのマイクロサービス化🌐 充電期の取り組みと、海外拠点・グローバル採用による人材拡充が上手く組み合わ さり、スモールチームによるプロダクト立ち上げ、マイクロサービス化が爆発的に進ん だ
36. 年表 MF Unit for ◦◦ スタートアップ期 充電期 拡大期 再編期 爆発的なプロダクト数の伸び 🚀
37. 年表 MF Unit for ◦◦ スタートアップ期 充電期 拡大期 再編期
38. 再編期(2023年-) 状況 • サービス数の爆発的増加📈 • 行き過ぎた個別最適によるUX、開発 効率の低下📉 • グローバル化の進展、多拠点開発の 増加🌏 • スモールチーム間のコミュニケーショ ンコスト増加🔀
39. 再編期(2023年-) 生き残り戦略 • 標準化や共通化の推進🧭 • 横断組織の強化、プラットフォームエンジニアリングの導入💪 • チーム間のコミュニケーションの再編・役割定義🌏 プロダクトが爆発的に増えた結果、スモールチームで個別最適にプロダクト開発を進 めるデメリットが無視できなくなってきた。中長期視点での全体最適と個別最適のバラ ンスを探ることが必要になっている。
40. まとめ
41. まとめ マネーフォワードの生き残り戦略を振り返ると、スピード重視、権限委譲、自律的なス モールチームという勝ちパターンがあり、それをどう維持するかを考えて、取り巻く状 況に応じてアーキテクチャや組織を変えてきた会社と言えると思います。スタートアッ プで信用も資金力もなかった私達が他のプレイヤーに対抗しうる唯一の武器はス ピードであり、それを最大限に発揮するために上記の勝ちパターンを拠り所にしてい ました。結果として、変化の激しい事業環境にも対応し、生き残ることができました。 会社により事業環境は異なりますが、その環境の中で持続的に発展するための勝ち パターンを見極め、それを支えるアーキテクチャや組織を考えることが、生き残り戦 略につながると考えています。
42. Thank you!