ブログ記事
巨大SPAを分割する前に読む本：マイクロフロントエンドの設計思想と現実のコスト
バックエンドをマイクロサービスに分割したのに、フロントエンドは依然としてモノリスのまま。チームが増えるほど、デプロイのたびに調整コストだけが積み上がっていく。
Luca Mezzalira の『マイクロフロントエンド』（オライリー・ジャパン、2022年）は、そうした状況に置かれたテックリードやアーキテクトに向けた一冊だ。著者は動画配信サービス DAZN のチーフアーキテクトとして大規模フロントエンドの刷新を主導した経験を持ち、概念の紹介で終わらせず、実際のトレードオフと失敗の両面を本書に持ち込んでいる。
1. 組織図を変えるだけでは何も変わらない——逆コンウェイ戦略という発想
「ドメイン駆動設計を導入した」「クロスファンクショナルチームに再編した」——それでもデプロイ調整の会議が減らない場合、原因はシステムの境界が組織の境界と一致していないことにある。
本書が中心的なテーマに置くのが、コンウェイの法則を逆手に取る「逆コンウェイ戦略」だ。システムのアーキテクチャは組織の構造を反映する傾向があるなら、望むアーキテクチャに合わせて組織を再設計すればよい——という発想の転換である。データベースからUIまでの全責任を一つのチームが持つ自律的なクロスファンクショナルチームを構成し、そのチームの境界とマイクロフロントエンドの境界を対称に保つことで、他チームの進捗を待たずにデプロイできる環境が整う。組織図だけ変えてコードの境界はそのままにしていれば、調整コストは形を変えて残り続ける。
2. 垂直分割と水平分割——どちらを選ぶかで難易度が大きく変わる
フロントエンドをどう切り分けるかで、設計の難易度は大きく変わる。本書はこの切り分け方を「垂直分割」と「水平分割」の二軸で整理している。
垂直分割は、画面（ページ）ごとにチームを完全に独立させる方法だ。ある画面は完全にチームAが所有し、別の画面はチームBが担当する。一度に読み込まれるモジュールが一つに限られるためUXの一貫性を維持しやすく、実装の難易度も相対的に低い。DAZN がアプリシェルを外殻として垂直分割を採用しているのは、この扱いやすさが理由の一つだ。
flowchart TD
SHELL["アプリシェル（共通ナビ・認証）"] --> V1["ページA\nチームAが担当\n（垂直分割）"]
SHELL --> V2["ページB\nチームBが担当\n（垂直分割）"]
V2 --> H1["コンポーネント X\nチームC"] & H2["コンポーネント Y\nチームD"]
style SHELL fill:#e8f4fd,stroke:#4a9eda
style V1 fill:#e8f8e8,stroke:#4caf50
style V2 fill:#e8f8e8,stroke:#4caf50
style H1 fill:#fff8e1,stroke:#f5a623
style H2 fill:#fff8e1,stroke:#f5a623
一方の水平分割は、単一ページの中に複数チームが開発したフラグメントを混在させる方法で、ドメイン単位のコンポーネント再利用に向いている反面、CSSや状態管理の衝突リスクが常につきまとう。複数チームが同じ画面に同居するため、UIの一貫性を保つための調整コストが別の形で発生する。どちらが優れているというわけではなく、ビジネスドメインの特性と組織の規模に応じて自分たちで判断して選ぶことになる。
3. Module Federationが実現したこと、そしてその先にある現実
従来の方法でフロントエンドを分割しようとすると、npm パッケージとしてモジュールを共有するビルドタイム統合が一般的だった。この方法では、一つのモジュールを修正するたびに親アプリケーションの再ビルドと全体デプロイが必要になり、独立したリリースサイクルを実現できない。
webpack 5 で導入された Module Federation は、ブラウザがコードを実行するタイミングでモジュールを動的にダウンロードするランタイム統合を可能にした。各チームが異なるデプロイパイプラインを持ち、任意のタイミングで自分のコンポーネントをリリースできる——それが実現する。本書はこのメカニズムを本番運用に載せるための設定やバージョニング、TypeScript での型共有まで詳しく扱っている。
ただし、本書が評価される理由の一つは、この技術の限界についても率直に書いていることだ。各モジュールが独自のライブラリを重複ロードすることで初回読み込みのパフォーマンスが悪化するリスク、E2E テストの管理負荷の増大、分散したログによる観測性の低下——こうした「影のコスト」について包み隠さず言及されている。また、Vite や Rspack といった webpack 以外のビルドツールが普及した現在、本書の解説をそのまま適用しにくい部分も出てきている。マイクロフロントエンドを検討する際は、本書が対象とするような数百人規模の大規模組織でなければ、導入コストがメリットを上回る場面も多いと理解した上で読む必要がある。
4. この本が効く場面
「ビルドに10分以上かかる巨大SPAを運用していて、1カ所の変更が思わぬデプロイ時バグを生むから、リリースのたびにチーム全員が身構える」——本書が最も効くのはこの状況だ。問題はコードの書き方ではなく、変更の影響範囲とビルド境界が一致していないことにある。ランタイム統合の仕組みを理解すると、影響を自チームのモジュール内に閉じ込めたまま、モノリスを画面単位で漸進的に移行する道筋を立てられるようになる。
もう一つは、「マイクロフロントエンドの検討を任されたが、採用可否を判断する物差しがない」という状況。本書は完璧なアーキテクチャは存在しないという前提に立ち、デプロイ可能性・モジュール性・簡素性・テスト容易性・パフォーマンス・開発者体験という評価指標でトレードオフを測る枠組みを示している。読後は、流行への追従ではなく自社の状況の採点結果として、導入も見送りも説明できるようになる。
5. 読むべき人、まだ読まなくていい人
向いている人：
- 数十人から数百人規模の開発組織で、SPAベースの巨大なフロントエンドを共有モノリスとして維持しているリードエンジニアやアーキテクト
- バックエンドのマイクロサービス化は完了したのに、フロントエンドのデプロイ競合がビジネス価値提供のボトルネックになっている人
- DDDやクロスファンクショナルチームへの組織再編を進めたが、コード境界が旧来のまま割れていて調整コストが減らない技術責任者
向いていない人：
- 小規模なチームで、当面スケールの課題に直面していない人。本書のアプローチは数百人規模・長期運用のプラットフォームを主な対象としており、それ以外では初期の環境構築や認証・認可の共通化といったコストがメリットを上回るという評価が多い
- 単一アプリケーション内のコンポーネント設計をまだ経験していない人。複数チームにまたがる分割の判断は単一アプリでの設計経験が土台になるため、順序としてはコンポーネント設計の習熟が先だ
6. 読み方ガイド：立場で重点章が変わる
A5判404ページ・全10章と付録という分量だが、頭から通読する必要はない。導入の可否を判断する立場なら、原則と課題を扱う第1〜4章、組織への導入を扱う第10章、そして巻末付録の実務家インタビューを先に読む。付録には8人の専門家による証言が収められており、マイクロフロントエンドの威力と、実務で遭遇した障害や想定外のコストの両面が語られる。意思決定前に目を通す価値が大きいのはここだ。
導入を決めて実装フェーズに入ったら、技術的実装からデプロイ・自動化パイプラインの事例までを扱う第5〜7章と、BFFやAPIゲートウェイなどバックエンドとの協調パターンを扱う第8章に進む。モノリスからの移行を控えているなら、第9章の移行事例が計画の下敷きになる。
7. 読んだ後のステップ
読後の進路は関心の向きで分かれる。フロントエンドの分割がバックエンドの分散設計と同じ根を持つことに気づいたら、Sam Newman の『マイクロサービスアーキテクチャ』へ。境界の切り方・自律的なデプロイ・組織との対応をサーバー側から扱っており、本書と同じ問題意識を反対側から捉え直せる。一方、「そもそも良い分割とは何か」という判断基準を掘り下げたくなったら『A Philosophy of Software Design』が次の一冊になる。モジュールの深さや認知負荷という観点から、分割の良し悪しを見極める語彙が手に入る。
実務での最初の一歩は、導入を即断する前に、本書の評価軸で現状のモノリスと組織を採点することだ。マイクロフロントエンドは銀の弾丸ではない——その前提を自分の文脈で確かめてから動く。
筆者の体験から
チームが見ていたSPAは年々肥大化し、1箇所直しただけで関係ない画面までデプロイ確認が必要になっていた。バックエンドは分割済みなのにフロントは一枚岩のままという非対称さが引っかかり、チーム分割の話が出始めた頃にこの本を買った。
読後は、デプロイ可能性やテスト容易性といった評価指標で現状を採点し、感覚ではなく項目ごとの◯△✕で議論するようになった。逆コンウェイ戦略は、組織図だけ先に変える案に「まずコードの境界を決めてから」と待ったをかける根拠になった。正直なところModule Federationの解説はwebpack 5前提でズレがあり、考え方だけの参考に留まった。想定読者も数百人規模の組織に寄り、数人規模には導入後のコストの話ばかりが目についた。
検討会で画面ごとにリポジトリを分ける案が出た際、検索結果と詳細画面が状態を共有する作りを理由に「割れる保証はない」と指摘し、評価指標の表でテスト容易性の悪化を示した。結局1リポジトリのままオーナーシップだけ明確にする、という着地になった。
DevBookPathのマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有