「創業当時は良い選択だった」――マネーフォワードのアーキテクチャ変遷、クラウドネイティブに変革した理由：「拡大していく組織を支えるには、適切な責務分担とスモールチームが大切」

2022年3月10〜11日に開催された「ITmedia Cloud Native Week 2022春」の基調講演に、マネーフォワードの取締役執行役員 D&I担当 CTO（最高技術責任者）中出匠哉氏が登壇。「40を超えるサービスを“素早く継続して”生み出し続ける、クラウドネイティブな秘訣（ひけつ）」と題して、マネーフォワードにおけるクラウドネイティブ技術活用のポイントやサービスを迅速提供するための秘訣を紹介した。

[齋藤公二，＠IT]

モノリシックで密結合なアーキテクチャが生まれ、「桃園の誓い」状態に

　「お金を前へ。人生をもっと前へ。」をミッションに、事業者向けバックオフィスSaaS「マネーフォワード クラウド」などを提供するマネーフォワード。事業領域は、創業事業である家計簿、資産管理（PFM）サービスから、バックオフィス向けSaaS、FinTechやDX（デジタルトランスフォーメーション）推進など幅広く手掛けている。近年は、金融サービスを提供するファイナンスサービスやSaaSマーケティング支援も開始している。

マネーフォワード 取締役執行役員 D&I担当 CTO 中出匠哉氏

　「個人向け事業の割合は15.8％で、金融機関向けサービスと合わせて約30％、最も大きな事業は法人向けで、そのうちバックオフィス向けSaaSが約55％を占めています。提供サービスは年を追うごとに増加していて、2022年3月時点では40を超えています。バックオフィス向けSaaS事業、複数のサービスがお互いに連携する形で提供されています。拠点は国内8拠点とベトナムにあり、開発拠点を順次増やしている状況です」（中出氏）

　40を超えるサービスを提供するマネーフォワードだが、創業期のシステムはモノリシックで密結合なアーキテクチャだった。これは創業間もない2012年時点で、銀行やクレジットカード、電子マネーなどの残高や取引情報を金融機関から取得する「アカウントアグリゲーション基盤」を最初に構築したことに由来するという。

　「アカウントアグリゲーションしたデータをユーザーに見せるため、DB（データベース）を共有する形でサービスを作っていました。2013年に『マネーフォワード クラウド会計・確定申告』をリリースしましたが、同じIDでログインできるようにするため、同じDBを利用しました。2015年の『マネーフォワード クラウド請求書』、2016年の『マネーフォワード クラウド給与』をそれぞれリリースするときも同じDBを利用しました。その後も『マネーフォワード クラウド経費』『マネーフォワード クラウド資金調達』とサービスが増えていき、1つの共有DBにさまざまなデータが混在するモノリシックで密結合なシステムになってしまったのです」（中出氏）

　こうしたシステムの問題点は、共有DBが高負荷で停止すると全サービスが同時に停止することにある。同社では密結合した状態を三国志の著名なせりふ「我ら生まれた日は違えども、死す時は同じ日同じ時を願わん」になぞらえ「桃園の誓い問題」と呼んでいるという。

桃園の誓い問題（出典元：中出氏の講演資料より）

疎結合化、責務の再定義、マイクロサービス化、コンテナ化＆クラウド化に取り組む

　創業期のアーキテクチャの問題は、開発組織の問題にもつながった。当初はサービスごとにチームを作り、インフラチームがサービスを横断する形で見るという構成だった。インフラを共通化し、開発チームが機能開発に集中できる体制でメリットも多かった。

　「新規プロダクトの開発スピードが速く、インフラのコスト削減につながる利点がありました。その一方で、サービスの増加と組織の拡大に伴い、開発スピードの低下や増大するユーザーリクエストとデータによる共有DBへの負荷、全プロダクト障害の発生リスクといった課題が生じました」（中出氏）

　こうした状況を変えるために、アーキテクチャの変更やそれに合わせて組織や責務を変えていった。アーキテクチャは大きく分けて4つの取り組みにより変遷した。サービス間の疎結合化、責務の再定義、マイクロサービス化、コンテナ化＆クラウド化だ。

　サービス間の疎結合化では、プロダクト固有のデータを共有DBからプロダクトごとのDBに移行した。アグリゲーションデータにアクセスするためのAPIを開発し、共有DBからアグリケーションデータを抜き出してアグリケーションDBに移設した。ユーザーデータはメインDBから分離した。

サービス間の疎結合化を推進〈クリックで拡大〉（出典元：中出氏の講演資料より）

　責務の再定義は、共通のインフラチームの責務を権限とともに開発チームに渡し、開発のストリームは開発チーム内で完結させた。これにより、開発チームが自律的に活動できるようになったという。

責務の再定義により自律的な開発チームを実現（出典元：中出氏の講演資料より）

　マイクロサービス化は、スケール可能な開発組織を作る狙いもあった。モノリシックなサービスの場合、エンジニアを増やしてもチームの開発力は増えない。サービスを分割し、小さくして開発チームに割り当て、開発の相互の影響を局所化することで、エンジニアが増加しても開発生産性を維持できるようにした。

　最後のコンテナ化＆クラウド化は、開発チームの自律化を助ける狙いがある。自律的な開発チームは多くの責務を担うことになるが、コンテナ化＆クラウド化で、責務を担うことが容易になるという。

　「『インフラ部分だけクラウド化すればよい』という話でありません。サービス間の疎結合化からコンテナ化＆クラウド化までそれぞれが関係し合っており、同時に進めていくことが重要です」（中出氏）

一つ一つの制約を考え、将来にわたってその制約を許容できるかを考えることが大切

　中出氏は、クラウドネイティブの恩恵をこう話す。

　「クラウドネイティブの恩恵は、インフラの難易度を下げて開発チームの自律化を促進できること、クラウドの機能を利用することで自律化した開発チームの生産性を向上させられること、方針展開を容易にし、新しい取り組みに挑戦するためのハードルを下げることにあります」（中出氏）

　その他にもさまざまなメリットが得られる一方で、課題も残る。まず、全てのチームが自律化できるわけではなく、生産性の向上は一部にとどまるという。

　「自律化を容易にはするものの、何も考えずに実現できるわけではありません。クラウドだからチームが自律化するわけではないのです。しっかり責務の分解点を意識しないとクラウドネイティブであっても、自律的なチームにはならないと考えています。変化を恐れないカルチャーや意識を持つことも重要です」（中出氏）

　また従来の環境を維持し続けることでもたらされる制約もある。マネーフォワードの場合、密結合したモノリシックなシステムをそのままクラウドに持っていくことはできないという「桃園の誓い問題」が制約になった。

　また「津軽海峡レイテンシ問題」もあったという。北海道にあるデータセンター内のインフラと、東京にあるAmazon Web Services（AWS）のインフラをつなぐ通信は津軽海峡を渡る過程で往復20ミリ秒の遅延が発生する。この遅延によりサービスをAWSに移行できないのだという。そもそも、アグリゲーションデータを含めてAWSに移行しようとすると膨大なコストが発生するという事情もあった。

　「桃園の誓いや津軽海峡レイテンシを生んだ構成は、構築当時は正しい選択でした。開発速度が速く、インフラのコストを抑えることが、成長の源泉となりました。重要なことは、柔軟性を残しながら将来の選択を容易にすることです。柔軟性に優れるからといえクラウドを利用する理由として十分ではありません。クラウドを利用することで生まれる制約も少なからずあります。それぞれの制約を考え、将来にわたってその制約を許容できるかを考えていくことが大切です」（中出氏）

アーキテクチャやテクノロジーと組織風土やカルチャーを一緒に考えていく

　そのうえで中出氏は「持続的なプロダクト成長を実現する組織」をテーマに、マネーフォワードが推進する組織の在り方を紹介した。

　「持続的なプロダクト成長を実現する組織のポイントは『自律的なサービス開発チーム』が存在し、そのチームをなるべく『スモールチームとして維持』できること。大きくなったら、組織を分けたり、マイクロサービス化できたりするように備えること。その上で、自律的なサービス開発チームを孤立させないために『開発チームの負担を削減する横断的なチーム』を作ることです」（中出氏）

　自律的なサービス開発チームとは、企画、設計、開発、テスト、リリース、運用までの全工程に主体的に取り組むチームのことだ。全ての開発ストリームを担うことで、高速なフィードバックと意思決定を実現できるようになる。また、プロダクトを開発するだけでなく、技術的な負債の解消にも責任を負い、その両方を考えた意思決定ができる。

　スモールチームの維持でポイントになるのは、開発するサービスを小さくすると同時にチームも小さくすることだ。チームが効果的に働くためには、高い信頼関係が不可欠だが、そうした信頼関係を築ける人数には限界がある。そのためチーム自体を小さくするわけだ。

　開発チームの負担を減らす横断的なチームは、大きくプラットフォームチームとイネイブリングチームがある。プラットフォームチームは、自律的な開発を容易にするプラットフォームを提供し、APIやドキュメントを通して支援する。イネイブリングチームは開発ストリームを担う上で能力のギャップを埋めることを支援する。

チーム細分化のポイント（出典元：中出氏の講演資料より）

　最後に中出氏は、次のように話し、講演を締めくくった。

　「拡大していく組織を支えるためには、適切な責務分担とスモールチームが大切です。その2つが有効に機能していれば、コンテナ化＆クラウド化を進めるのは難しいことではありません。サービス開発チームの自律性を持たせることが開発速度を上げる秘密です。クラウドネイティブを目指すためには、アーキテクチャやテクノロジーも確かに重要です。しかし、より重要なのは組織風土やカルチャーです。アーキテクチャやテクノロジーと組織風土やカルチャーを一緒に考えていくのです」（中出氏）