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!