【CNDS2025】共有DBからの脱却とAWS移行に挑んだマネーフォワードのリアーキテクチャの全体像

CloudNative Days Summer 2025にて、マネーフォワードの内西功一氏が登壇したセッション「オンプレからクラウドへ。大規模なAWS移行を支えたリアーキテクチャプロジェクト達」。同社は、単なるクラウド移行ではなく、共有DBに依存していたモノリスな構成から脱却し、各サービスが独立して稼働するアーキテクチャへと再構築を果たした。しかしその裏では、機能の切り出しと撤退、スコープ調整、開発体制の見直しといった「泥臭い」実務が積み重ねられていた。

なぜ共有DBを分離しなければならなかったのか

マネーフォワードが進めたAWSへの大規模移行は、単なるインフラの切り替えではなく、共有DBという技術的負債を解消するためのアーキテクチャ再設計もともなうものであった。本セッションは、その中核を成す「共有DBの依存分離プロジェクト」に焦点をあてている。

同社は創業期から複数のサービスがオンプレミス環境の共通DBを利用する構成をとっていた。人員が限られていた当時は迅速な開発に適した構成であり、「当時の選択肢としては間違っていなかった」と内西氏も振り返る。しかし組織とサービスの成長とともに、構造の歪みが顕在化していく。

「全体障害の数がとても増えていました。本番のデータを検証中に、誤って重いSQLを実行してしまい、全社の障害に繋がってしまうことが当時のアーキテクチャではありました」。共通DBの構造により、一部の障害が他ドメインのサービスにまで波及し、利用者や開発現場に大きな負担を与えていた。またDBの変更には複数チーム間でのリリース調整が必要となり、開発スピードの低下も深刻だった。

こうした課題を背景に、2020年に依存分離を目的とした横断プロジェクトチームが発足し、内西氏は2021年から参加。そしてついに2024年には基盤サービスの分離とAWSへの移行が完了した。

アーキテクチャも大きく刷新された。それまでB2B・B2C両ドメインのデータが1台のDBに集約されていた構成から、サービスごとに独立したDBとユーザー基盤を構築し、API連携によって接続するモデルへと移行した。

ビジネスカンパニーの共有DB分割後のアーキテクチャ

本セッションで取り上げられるのは、こうした移行全体の中でもとりわけ困難をともなった「共有DBの依存を剥がすプロジェクト」であった。とくに、象徴的だった「新しく生まれたサービス」と「役割を終えたサービス」を軸に、移行における知見が語られていく。

顧問先管理サービスの独立に見る、スコープ調整とスキーマ駆動開発の進め方

共有DBからの分離にともない、モノリスに埋もれていた一機能を独立させ、マイクロサービス化したのが「マネーフォワード クラウドパートナー」である。会計士・社労士・税理士向けに顧問先の業務を代行する支援サービスであり、新しいアーキテクチャの象徴的な事例となった。

このリプレースは三度目の挑戦でようやく成功した。一度目は機能を盛り込みすぎ、二度目は想定外の基盤変更に対応できなかった。三度目では「リリースを優先し、スコープを最小限にする」方針のもと、体制も再構築し、関係部門の実務に精通したメンバーが参加した。

この「不確実性を減らす」ために取られた方針が二つある。一つは「スコープを見直す」ことだ。例えば、経費サービスの連携は切り離し、実際に士業が必要とする会計・社会保険・年末調整といった機能に絞り込んだ。「ユーザーの本当のニーズに応えるために、やるべきことを明確にしました」と内西氏は語る。

もう一つは「認識合わせを早いうちに行う」ことだ。開発初期からテストケースの定義とレビューを取り入れ、細かい粒度での検証を重ねることで、手戻りのない進行を実現した。「テストケースを書くところまで一つのレビューに入れています。これにより抜け漏れがなくなり、手戻りが少なくなっています」と、その効果を振り返る。

加えて、開発を支えたのが「GraphQLスキーマ駆動開発」と「OpenAPIスキーマ駆動開発」である。GraphQLでは、複雑なフロントエンドページの部品をAPIスキーマに基づいて整理・分割できたことで、役割分担が明確になり、「得意領域に集中できる」開発体制を実現できた。

スキーマ駆動開発 共通のメリット

OpenAPIについては、英語対応チームとの連携にも威力を発揮した。共通のスキーマに基づく設計で、仕様のすり合わせを短時間で済ませられるだけでなく、APIクライアントの自動生成により、開発効率の向上と属人性の排除も達成された。

内西氏はこのプロジェクトを振り返り、「難易度の高いプロジェクトは、不確実性を先に潰すことが大切です」とまとめる。技術的な設計とチーム運営の両面で不確実性を減らし、持続可能なクラウドネイティブアーキテクチャを構築していく、その実践的な知見が詰まった取り組みであった。

共通管理画面の静かな終幕に見る、撤退を成功させる組織調整と現場の粘り強さ

マネーフォワードが共有DBの分離を進めるなかで、もう一つの重要な取り組みとなったのが、社内向け共通管理画面の廃止である。かつては複数サービスの情報を一括で扱える利便性から重宝されていたが、DBが分離され、サービスが自立するにつれ、古い情報を表示するリスクや運用上の非効率が顕在化していった。

このプロジェクトでは、まず現状を正確に把握することから始められた。どの機能が誰に使われているかを洗い出し、ドキュメント化して説明と合意形成に活用。利用部門ごとにユースケースを確認し、段階的に移行と代替機能の案内を進めていった。地道なヒアリングを繰り返し、利用状況を追いながら最終的なクローズへと導いた。

とくに難航したのが、長く使われていた「商材系」機能の扱いである。顧客への情報共有や契約上の都合により即時廃止が難しく、年単位での対応が求められる。「息の長いものは早く倒すべき」という教訓は、このケースから得られた重要な知見である。

商材系の対応方針

また撤退には技術以上に人との調整が欠かせない。誰が、何の目的で、どのように使っているのか。その理解をもとに、「業務が止まらない移行計画」を組み立てる必要があった。移行先で同等以上の体験を提供し、細かな要望にも応じることで、ユーザーからの協力を得られる関係性を築いていった。

さらに、他部門に機能を引き継いでもらうには、単なる依頼では限界がある。最終的にはプロジェクト達成を組織の評価指標と結びつけ、上司や関係部門の責任者を巻き込んで動かすことが成功の決め手となった。

この取り組みの総括として内西氏は、「息の長いものから着手する」「利用者を明確にする」「協力関係を築く」「上司を巻き込む」という4つのコツを挙げている。派手さはないが、分散した情報と組織を再編していくには欠かせない視点である。クラウド移行を支えたのは、こうした「終わらせる力」であった。

クラウドネイティブ移行を支えた、調整力と現場に根ざした実行力

マネーフォワードが進めたAWSへの移行は、技術的な刷新だけでなく、組織横断のプロジェクト推進や役割の再定義をともなう、複雑で泥臭い取り組みであった。サービスを分離し、新たに生み出し、古いものを閉じていく。その一連の流れを支えたのは、推進チームの粘り強い調整と、現場の声に寄り添う姿勢である。

「クラウドネイティブは、響きは格好良いですが、実際の移行業務はとても泥臭いものです」と内西氏が語ったように、本セッションの本質は、クラウド移行＝組織改革という視点にある。成功の裏には、道を示し、責任を引き受け、落ちているボールを拾いにいく姿勢があった。

技術だけでは変わらない。人とチームと仕組みを動かす力こそが、クラウドネイティブを現実のものにする鍵なのである。