巨大SPAを分割する前に読む本：マイクロフロントエンドの設計思想と現実のコスト

バックエンドをマイクロサービスに分割したのに、フロントエンドは依然としてモノリスのまま。チームが増えるほど、デプロイのたびに調整コストだけが積み上がっていく。

Luca Mezzalira の『マイクロフロントエンド』（オライリー・ジャパン、2022年）は、そうした状況に置かれたテックリードやアーキテクトに向けた一冊だ。著者は動画配信サービス DAZN のチーフアーキテクトとして大規模フロントエンドの刷新を主導した経験を持ち、概念の紹介にとどまらず、実際のトレードオフと失敗の両面を本書に持ち込んでいる。

1. 組織図を変えるだけでは何も変わらない——逆コンウェイ戦略という発想

「ドメイン駆動設計を導入した」「クロスファンクショナルチームに再編した」——それでもデプロイ調整の会議が減らない場合、原因はシステムの境界が組織の境界と一致していないことにある。

本書が中心的なテーマに置くのが、コンウェイの法則を逆手に取る「逆コンウェイ戦略」だ。システムのアーキテクチャは組織の構造を反映する傾向があるなら、望むアーキテクチャに合わせて組織を再設計すればよい——という発想の転換である。データベースからUIまでの全責任を一つのチームが持つ自律的なクロスファンクショナルチームを構成し、そのチームの境界とマイクロフロントエンドの境界を対称に保つことで、他チームの進捗を待たずにデプロイできる環境が整う。組織図だけ変えてコードの境界はそのままにしていれば、調整コストは形を変えて残り続ける。

2. 垂直分割と水平分割——どちらを選ぶかで難易度が大きく変わる

フロントエンドをどう切り分けるかで、設計の難易度は大きく変わる。本書はこの切り分け方を「垂直分割」と「水平分割」の二軸で整理している。

垂直分割は、画面（ページ）ごとにチームを完全に独立させる方法だ。ある画面は完全にチームAが所有し、別の画面はチームBが担当する。一度に読み込まれるモジュールが一つに限られるためUXの一貫性を維持しやすく、実装の難易度も相対的に低い。DAZN がアプリシェルを外殻として垂直分割を採用しているのは、この扱いやすさが理由の一つだ。

一方の水平分割は、単一ページの中に複数チームが開発したフラグメントを混在させる方法で、ドメイン単位のコンポーネント再利用に向いている反面、CSSや状態管理の衝突リスクが常につきまとう。複数チームが同じ画面に同居するため、UIの一貫性を保つための調整コストが別の形で発生する。どちらが優れているというわけではなく、ビジネスドメインの特性と組織の規模に応じて選択する判断が求められる。

3. Module Federationが実現したこと、そしてその先にある現実

従来の方法でフロントエンドを分割しようとすると、npm パッケージとしてモジュールを共有するビルドタイム統合が一般的だった。この方法では、一つのモジュールを修正するたびに親アプリケーションの再ビルドと全体デプロイが必要になり、独立したリリースサイクルを実現できない。

webpack 5 で導入された Module Federation は、ブラウザがコードを実行するタイミングでモジュールを動的にダウンロードするランタイム統合を可能にした。各チームが異なるデプロイパイプラインを持ち、任意のタイミングで自分のコンポーネントをリリースできる——それが実現する。本書はこのメカニズムを本番運用に載せるための設定やバージョニング、TypeScript での型共有まで詳しく扱っている。

ただし、本書が評価される理由の一つは、この技術の限界についても率直に書いていることだ。各モジュールが独自のライブラリを重複ロードすることで初回読み込みのパフォーマンスが悪化するリスク、E2E テストの管理負荷の増大、分散したログによる観測性の低下——こうした「影のコスト」について包み隠さず言及されている。また、Vite や Rspack といった webpack 以外のビルドツールが普及した現在、本書の解説をそのまま適用しにくい部分も出てきている。マイクロフロントエンドを検討する際は、本書が対象とするような数百人規模の大規模組織でなければ、導入コストがメリットを上回る場面も多いと理解した上で読む必要がある。

DevBookPathのマップで確認する

この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。

フロントエンドの地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。