疎結合で得た柔軟性と運用のリアル　READYFORのマイクロフロントエンド現在地

READYFOR株式会社は、「みんなの想いを集め、社会を良くするお金の流れをつくる」というパーパスのもと、日本初・国内最大級のクラウドファンディング事業や、寄付・補助金のマッチング事業を展開しています。
マイクロフロントエンド導入当時の開発組織はスクワッド体制を採用しており、各スクワッドがミッションに基づき、少人数の職能横断型チームで自律的に意思決定・遂行していました。現在は、スクワッドというよりも、より機能や領域にフォーカスしたフィーチャーチームに近い体制へと移行しています。

フロントエンド構成図

マイクロフロントエンド導入について

導入前の背景・課題と狙い

私たちが運営するクラウドファンディングプラットフォームでは、約3年前に「実行者向け管理画面」の全面リニューアルを行いました。この管理画面には、 プロジェクト管理・支援者管理・活動報告投稿・リターン発送管理など、複数の機能が集約されており、構造上モノリシックなアプリケーションになりやすいものでした。
過去の開発経験から、モノリシックな構成には以下のような課題を感じていました。

• チーム間での変更が衝突しやすく、責任範囲も曖昧になりがち
  
• コードベースが肥大化し、開発者の認知負荷が高まる
  
• 特定機能の変更が他機能に思わぬ影響を及ぼす可能性がある
  
• 初期に選ばれた設計や技術スタックが全体に波及してしまうため、機能ごとの要件に合わせた最適な技術や構成を採用しにくくなる
  
• ライブラリやフレームワークのバージョン管理が一元化されることで、大規模なアップグレードが必要になりやすい
  

さらに、当時はサービス拡大を見据え、開発組織のスケールに向けた体制づくりを進めていました。
エンジニア採用強化や、一部の機能については外部パートナーへの開発委託の可能性も検討されていたことから、開発体制はより流動的な方向へと移行しつつありました。こうした背景から、スケーラブルな開発体制や、機能ごとの独立性がより強く求められるようになっていました。

こうした状況を踏まえ、私たちはマイクロフロントエンドの導入を決断しました。
ベータ版リリース時には、まず三つの独立したフロントエンドアプリケーションを統合し、ひとつのアプリケーションとして提供していました。その後の機能追加を通じてフロントエンドアプリケーションの数は増え、現在では六つのアプリケーションを統合して提供しています。

結果的には、開発組織のスケーラビリティと技術的柔軟性を高めるうえで、大きな効果を得ることができたと実感しています。

導入時の課題と工夫

マイクロフロントエンド導入にあたっては、まず組成方法の選定から着手しました。
ビルドタイムやクライアントサイド、サーバーサイドなど様々な方式がある中で、今回の管理画面の要件や今後の拡張・保守方針まで見据えて総合的に判断し、クライアントサイド組成を採用しました。
導入前にはPoCも実施し、技術的な実現可能性や運用面での課題を洗い出した上で、本採用に踏み切っています。
qiankunというマイクロフロントエンドフレームワークを利用することで、アプリ間の独立性を保ちつつ、シームレスな画面遷移を実現しています。また、各マイクロアプリは静的にホスティングされ、基本的には統合レイヤー側の設定だけで統合や差し替えが可能なため、将来的な統廃合や再構成も容易です。

また、当時、すでに社内向けの共通コンポーネントライブラリは存在していましたが、そこにはドメインに依存しない汎用的な UI コンポーネントが中心に揃えられていました。しかし「実行者向け管理画面」では、実行者特有のデザインルールや UI パターン、ロジックを伴うユーティリティが多く存在し、こうしたドメイン固有の要素をどのように整理・再利用可能にするかが新たな課題となりました。
そこで、実行者ドメインに依存する UI コンポーネントやロジックを切り出し、専用のプライベート npm パッケージとして管理する方針を採用しました。このパッケージにより、複数のマイクロフロントエンド間での一貫性を保ちながら、必要な要素を効率よく共有・更新できるようになりました。さらに、プルリクエストごとに自動で npm パッケージがリリースされる仕組みを整備することで、各アプリケーションからの動作確認を容易にし、開発・レビューの効率化にもつなげています。

設計・運用における工夫

複数のマイクロフロントエンドを効率的に扱うため、それらをまとめて管理・実行できる統合リポジトリを設けています。
各アプリは個別リポジトリとして独立していますが、統合リポジトリはGitサブモジュールでこれらを参照し、ローカル環境のセットアップや起動を一元化しています。
さらに、アプリの最新のコードを自動で取り込む仕組みや、複数アプリを開発や本番環境へ一括デプロイできるCIの整備により、運用の効率化を行いました。
また、マイクロフロントエンドにおいて、複数のアプリケーションを同時に起動して統合した状態で開発や動作確認を行うケースも少なくなく、開発サーバーの起動速度やコード変更反映速度といった開発効率の向上が課題の一つでした。従来のwebpackベースの環境では開発サーバーの起動やコード変更時の反映に時間を要し、開発生産性を阻害していました。
この課題解決のため、各アプリケーションのビルドツールをViteに移行しました。qiankunとViteの互換性問題により独自プラグインの開発が必要でしたが、結果として起動時間・反映時間を大幅に短縮でき、マイクロフロントエンド開発における快適な開発体験を実現しています。
詳細はこちらの記事をご参照ください。

現在の課題や今後の展望について

マイクロフロントエンド導入当時は開発組織のスケールを見据えていましたが、その後、事業や組織の方針が変化し、現在では当初想定していたほどの規模拡大はなく、比較的安定したチーム体制に落ち着いています。そのため、現在は、実行者向け管理画面を1つのチームが横断的に担当しており、複数チームでの分担は発生していません。
マイクロフロントエンドによる疎結合化の技術的な恩恵は今でも大きい一方で、現状の体制では組織的な恩恵はあまり発揮されない状況となりました。

また、独立性を高めるためにマルチリポジトリで管理していることから、以下のような運用上の課題も生じています。

• 社内向けのライブラリの変更を反映する際、ライブラリ側で PR 作成・マージ・リリースを行った後、プロダクト側でも手動でバージョンを更新する必要がある
• 共通の開発系パッケージのアップデートがリポジトリごとに必要
• Linter や CI の設定変更を各リポジトリに個別で適用する必要がある
  

このように、似たような対応を複数のリポジトリで繰り返す必要があり、日々の運用負荷が課題となっています。

こうした背景から、マイクロフロントエンドの構成は維持しつつ、リポジトリを統合して作業の一元化を図るモノレポ化を計画しています。これは組織フェーズに応じた自然な変化であり、構成自体は今も尚有効に機能していると考えています。今後も組織の方針や現場の状況に応じて柔軟に最適化を重ねていく方針です。

◆執筆：菅原 弘太郎（スガワラ コウタロウ)　プロダクト＆エンジニアリング部　フロントエンドテックリード　 @kotarella1110

テックブログURL
https://zenn.dev/p/readyfor_blog
https://tech.readyfor.jp