開発ノート：モノリシックからマイクロフロントエンドへの移行プロジェクトで得た知見と教訓

プロジェクト背景と初期フェーズ

あるBtoB向け業務システム刷新プロジェクトで、私たち開発チームは従来のモノリシック構成からマイクロフロントエンド（MFE）構成への移行を提案しました。背景には、業務部門が機能追加を要望するたびに「開発会社への発注サイクルが長く、費用が膨らんでいる」「UIの更新だけでシステム全体のビルドが必要で、納期遅延が常態化している」という課題がありました。
当初、全社的に使っている受発注管理システムはJavaベースのフレームワークで構築されており、新機能を追加するには毎回ビルドとデプロイ、連携テストが必要であり、予算・費用の確保に苦慮していました。そこで、フロントエンド部分を切り出し、マイクロフロントエンドという手法で独立した複数の小さなシステムとして運用しようというアイデアが出ました。
この初期フェーズでは、まず社内SEやPMO、経営層を巻き込んで「なぜ従来のモノリシックシステムを継続するのではなく、マイクロフロントエンドへ移行するのか」をビジネス視点とコスト視点の両面から説得しました。当初の概算では、モノリシックのまま機能拡張を進めた場合、年間発注コストが約1,500万円に達すると見込まれていました。これに対し、MFE導入によるフロントエンド独立開発であれば、初期開発費用として約800万円、翌年度以降は追加開発や運用保守を合わせても年間600万円程度に抑えられると試算しています。
予算や費用の根拠としては、開発会社に対して同様のMFE案件の費用相場をヒアリングし、過去の請求書や見積書を参考にしました。相見積もりを3社から取り、「マイクロフロントエンド構築の相場は、要件定義・設計・実装・テスト・運用保守を含めて概ね700万～900万円」という情報を得たため、最終的に開発パートナーは予算内で対応可能な実績豊富なベンダーを選定しました。
初期の検討では、要件定義として「既存の業務システムには在庫管理、受注管理、売上分析といった複数の機能モジュールがあるが、それらを独立して開発・運用することで、変更の影響範囲を限定できる」「機能ごとに異なるフレームワークや技術スタックを採用してもよい」といった方針を打ち出しました。この方針がブレると、開発会社選びで後から苦労することになるため、最初に明確にしておくことが肝心でした。
しかし、要件定義時に想定していなかった課題もありました。たとえば、営業部が「今回移行する際にUIを一新したい」「モバイル対応も同時に進めたい」という要望を追加したことで、当初の予算を超過しそうになるケースが発生しました。この失敗から学んだ教訓として、要件定義段階で「機能最優先」「UI刷新は別フェーズで検討」とスコープを明確に区分しないと、後から追加要望で「追加費用」と「納期遅延」が発生するリスクがあるということを痛感しました。

モノリシックからマイクロフロントエンドへの検討過程

要件定義を踏まえたうえで、次にチームはモノリシックアーキテクチャに起因する具体的な課題を洗い出しました。第一に、開発会社に対する発注回数が多く、相場感を把握しづらい点。たとえば既存の開発会社に小さなUI変更を都度依頼すると、その都度「工数5工数で○○円」「テスト費用別途」など費用の内訳が都度変わり、プロジェクト全体の予算管理が複雑化していました。
第二に、フロントエンドとバックエンドが密結合しているため、ちょっとしたCSS変更でも影響範囲が広がり、本番リリースまで時間がかかるという課題がありました。これによりCI/CDの頻度を高められず、結果的に開発スピードが低下し、開発会社に発注したとしても納期調整や費用交渉が難航していました。
そこで、MFEの検討をスタートするにあたり、技術視点だけでなくビジネス視点を重視しました。たとえば、「在庫管理モジュールを内部で試験的にMFE化し、安定稼働を確認できたら、次に受注管理モジュールに拡張する」フェーズ戦略を採用しました。これにより、開発会社には「ステージごとに発注範囲を絞って見積もりを再提出」「納期は3か月ごとのリリースサイクル」といった形で依頼し、予算のつじつま合わせや相場確認を都度行いました。
技術的に決めたポイントは以下のとおりです。

1. フロントエンドはReactによるマイクロフロントエンド：既存社員にReact経験者が増えていたため、開発会社もReact対応可否を重視。

2. バックエンドは既存Java APIを継続利用：当面はフロントエンドのみ分離し、バックエンドはモノリシックを維持。予算を抑えるため、バックエンド改修工数を最小化。

3. ヘッドレスCMSの導入は見送る：事業部から要求が出なかったため、当初はCMSなしのAPI連携で進め、後から追加する可能性は残す（機能追加時に別途発注）。
   これらを決定した背景には、限られた予算と相場情報をもとに、開発会社の得意分野を見極めたという事情がありました。仮にヘッドレスCMSを全部導入した場合、予算が一気に1,000万円を超える見込みでしたが、段階的に導入することで初期費用を約600万円に抑え、その後の保守や運用費用も月額10～15万円程度を想定していました。
   ここで失敗談をひとつ挙げるなら、検討段階で「マイクロフロントエンドならユーザー認証もフロント側で統一できる」と考え、Auth0などの外部認証サービスを導入する計画を立てていたことです。しかし、認証情報のトークン管理やCookieポリシー、CORS設定などで想定以上に工数が膨らみ、最初のフェーズでは認証機能を分離せず、既存サーバーサイド認証をそのまま流用することでコストを抑えました。この判断により、当初見積で50万円想定の認証機能が工数30工数（約90万円相当）に膨れ上がる事態を回避できたことが大きな学びでした。

技術選定の経緯と開発会社選び

移行方針が固まった後、次は具体的にどの技術を使ってどの開発会社へ発注するかを決定しました。ここでのポイントは「自社メンバーとのスキルマッチ」「過去実績」「予算・費用相場」の3点です。
まず、自社の技術スタックを棚卸し、React経験者やTypeScript経験者が社内にどれだけいるかを確認しました。その結果、フロントエンドはReact＋TypeScriptで進めるのが無理なく進行できると判断。次に、過去にモノリシックからマイクロフロントエンド移行を行った実績がある開発会社を探し、相見積もりを依頼しました。
相見積もりは合計で4社に依頼し、内訳には要件定義・設計・実装・テスト・運用保守をそれぞれ分けて提示してもらいました。その中で、A社はReact中心のMFE移行実績が豊富で、単価も30,000円／工数と相場の中間レンジ。B社はTypeScriptに強いがMFE実績が少なく、単価も35,000円／工数と高め。C社は小規模案件の実績が多く、MFEは初めてだが予算内に収める提案をしてきた。D社は海外オフショアを含めたハイブリッド体制で価格を抑えられるが、コミュニケーションにやや懸念があったため、最終的にはA社を選定しました。
A社を選定した理由は、以下の通りです。

• React＋TypeScriptを使ったMFE案件の成功事例が3件以上あること。

• 小・中規模のマイクロフロントエンドプロジェクトでの費用相場が600万～800万円程度に収まる見込みを提示してくれたこと。

• 認証やAPIゲートウェイに関する技術的な相談にも柔軟に応じ、カスタムミドルウェアの実装方法を具体的に提案してくれたこと。

• プロジェクト体制として、PMO1名、フロントエンドエンジニア2名、バックエンドエンジニア1名、QAエンジニア1名というチーム構成が明示されており、コミュニケーションツール（Slack、Jira）の運用方法も事前に説明してくれたこと。

具体的な発注内容としては、以下のとおりです。

1. 要件定義・技術調査フェーズ（予算：80万円、工数：約25工数）

   • 既存モノリシックシステムの依存関係調査、必要なAPIエンドポイントの洗い出しを行い、MFE構成図を作成。

2. 設計フェーズ（予算：120万円、工数：約40工数）

   • Reactコンポーネント設計、TypeScript型定義、プロジェクト構成（ディレクトリ構造、CI/CD設計）を詳細化。

3. 実装フェーズ（予算：300万円、工数：約100工数）

   • MFE各モジュール（在庫管理、受注管理、売上分析）のReact実装、APIゲートウェイ連携、認証周りの共通ライブラリ設計。

4. テスト・QAフェーズ（予算：100万円、工数：約30工数）

   • ユニットテスト、結合テスト（Cypress）、E2Eテストを実施し、不具合を洗い出して修正。

5. 運用保守フェーズ（年間予算：150万円、月額約12万5千円、工数：毎月10工数相当）

   • リリース後の監視、セキュリティアップデート、問い合わせ対応、機能追加要望のヒアリング・見積作成。

一方、自社内でも並行して開発会社の選び方や費用相場、発注スキルを向上させるため、PMO主導で開発会社の過去実績調査や価格交渉ノウハウの社内勉強会を開催しました。これにより、次回以降のシステム発注に際しても、相場観を社員全体で共有できるようになり、開発会社との交渉力が向上しました。

要件定義の落とし穴と失敗談

マイクロフロントエンド移行プロジェクトで、最も大きな躓きは要件定義段階でした。以下に具体的な失敗事例と教訓を示します。

1. 共通UIライブラリの粒度が不明確だった

   • 当初、在庫管理と受注管理は「共通UIを使いまわせる」と考え、共通コンポーネントの設計作業を要件に含めました。しかし、実際に設計してみると、在庫管理モジュールでは「リアルタイム在庫反映の要件」があり、受注管理モジュールでは「複雑なフィルタリング機能」が求められ、それぞれでボタン配置やフィールド定義が微妙に異なるケースが多数発生。

   • 結果として、共通ライブラリを作り直す工数が膨れ上がり、当初想定より30工数（約90万円）多くかかりました。

   • 教訓として、「要件定義時に共通コンポーネントの粒度をしっかり詰める」「実際の画面イメージをモックツールで作成し、差分を洗い出す」ことが大切だと学びました。

2. 業務フローの認識ズレによる追加要件

   • モノリシックシステムでは、在庫数を更新する際に社内のバッチ処理が裏で自動実行される設計でした。MFE化にあたり、フロントエンドから直接APIを叩く要件に変更したところ、在庫更新タイミングが深夜バッチと競合し、データ不整合が発生するリスクが浮上しました。

   • 結果として、バックエンドのバッチ設計を変更して、API更新時に即時バッチ連携ができる仕組みを追加開発し、予算15万円、工数5工数の追加費用が発生しました。

   • 教訓として、「フロントエンド要件変更時には、必ずバックエンドバッチ設計を再確認し、システム全体のデータフローを俯瞰する」必要があると実感しました。

3. ベンダー間のコミュニケーションミス

   • 当初はA社とメインで調整を進めていましたが、サーバーレス認証部分のみB社にも依頼しようと考え、並行して進めた結果、認証APIのインターフェース仕様が微妙にずれていたことに気づかず、結合テストで大幅なリファクタリングが必要になりました。

   • このリファクタリングにより、A社とB社それぞれに再度テスト費用を請求することになり、合計20万円の追加費用が発生しました。

   • 教訓として、「複数ベンダーを使う際には、インターフェース設計書を最初に自社で作成し、ベンダー間で共有・合意を得る」ことが必須だと学びました。

以上の失敗談からわかるように、要件定義の段階で業務フローや共通コンポーネントの範囲をしっかり固め、ベンダー間のコミュニケーションルールを徹底することで、追加費用や予算超過リスクを最小化できます。
前半パートでは、プロジェクト背景から要件定義の失敗談までを詳しく紹介しました。後半では、開発フェーズでの手法やテスト・QAの進め方、運用保守体制の構築、さらに最終的に得られた成果や今後の展望について深掘りして解説します。
次の投稿で、開発フェーズ以降の具体的な進め方や運用フェーズのノウハウを共有いたします。

開発フェーズ：実装の詳細と課題解決

開発フェーズでは、前半で決定した要件定義や技術設計をもとに、実際にコードを書き進めていきました。まず、在庫管理モジュールと受注管理モジュールのフロントエンドをそれぞれ独立したリポジトリで立ち上げ、ReactとTypeScriptを用いたプロジェクト構成を行います。プロジェクト構成では、ディレクトリを「components」「pages」「utils」「hooks」「styles」に分け、機能ごとにファイルを整理しました。この段階で、共通部分となるUIパーツは別リポジトリのデザインシステムライブラリとして切り出し、両モジュールから参照できるようにしました。
具体的には、ボタンや入力フォーム、モーダルなどのUIコンポーネントを「@our-org/ui-library」としてNPMにパッケージ化し、バージョン管理を行いました。これにより、各モジュールでUIのデザイン変更があった場合、UIライブラリのバージョンアップのみで対応できるため、開発工数の削減に成功しました。ただし、初回のライブラリ化には20工数ほどかかり、デザインシステム策定と実装を合わせて約60万円のコストが発生しました。この投資により、後続モジュール開発では約15％の工数削減を達成できました。
次に、APIゲートウェイ連携の設計です。既存バックエンドはJavaのSpring Bootで構築されており、RESTfulなエンドポイントが提供されていました。在庫管理モジュールでは「GET /api/inventory」「POST /api/inventory/update」などをフロントエンドから呼び出します。ここで失敗したのは、エンドポイントのレスポンスフォーマットを最初に十分詰めずに実装を進めたため、後から「在庫単位が「個数」ではなく「箱換算」も必要」「在庫引当時にバッチ処理との整合を必ずチェックする」など追加要件が出た点です。この対応で、API設計を再検討し、エンドポイントにクエリパラメータとして「unit=box or piece」を追加し、バックエンド側でも在庫計算ロジックを修正しました。その結果、約30工数（約90万円相当）が余計にかかりました。
React実装では、状態管理にRedux Toolkitを採用しました。MFE構成では各モジュールごとにReduxのストアを持つ形とし、共通した認証情報やユーザー情報のみをCookie経由で共有する設計としました。認証部分は当初Auth0を検討していましたが、前半で述べた通りコストと工数が膨大になったため、既存のサーバーサイド認証JWTをそのまま利用し、フロントエンドではJWTをローカルストレージに格納して管理する方式を採用しました。この変更により、認証機能実装工数が当初想定の50万から約10万に抑えられ、プロジェクト全体の予算調整に貢献しました。
フロントエンドとバックエンド間の通信では、TypeScriptの型安全性を活かすためにaxiosとともに自動生成したOpenAPI Clientを導入し、エラー時のハンドリングやレスポンスタイプの型チェックを徹底しました。特に在庫更新APIはSSL通信のタイムアウト設定などを細かく調整し、UI側でトースト通知を出すことで、ユーザーが操作結果を確実に把握できるようにしました。結果として、UI操作時のエラー率が従来の10％から2％に低減しました。
環境設定では、開発／ステージング／本番の3環境をGitブランチとVercelのPreview環境で連携させました。ブランチ名を「feature/～」「develop」「main」などで運用し、GitHub Actionsでプルリク時に「develop」へマージされるとステージング環境、自動マージで「main」へ反映されると本番環境へデプロイが走るように設定しました。デプロイ後には自動的にSlack通知が飛ぶ仕組みとし、QAチームへの連携がスムーズになりました。

テストとQAの進め方、ツールと工数

実装と並行してテスト計画を立て、ユニットテスト、結合テスト、E2Eテストを実施しました。まずユニットテストについてはJestとReact Testing Libraryを導入し、主要なコンポーネントの動作検証を行いました。具体的には「在庫一覧のソート機能」「在庫詳細画面での数量変更ボタン」「APIエラー時のモーダル出力」の3つを重点的にテストしました。このユニットテストにかかった工数は約15工数（約45万円相当）ですが、後に結合テスト段階でのバグ検出率が70％→90％に向上したため、コスト対効果は高いと判断しています。
結合テストでは、ステージング環境上でCypressを用いて在庫管理と受注管理間の連携シナリオを自動化しました。テストケース例としては以下のような流れをシミュレートしました。

1. 在庫管理画面で特定商品の在庫数を10→5に変更し、APIで更新

2. 受注管理画面で同商品を注文しようとした際に「在庫不足アラート」が表示されることを確認

3. 注文確定ボタンをクリックし、バックエンドで在庫が再度減算されることを検証
   結合テスト用のスクリプト作成には約10工数（約30万円）がかかりましたが、本番環境リリース前に重大なデータ不整合を発見できたため、リリース後の障害対応工数削減に寄与しました。
   E2Eテストでは、ユーザー視点での操作検証を行うため、Cypress Dashboardを導入してテスト結果を可視化しました。テスト対象は「ログイン→在庫一覧→詳細→更新→受注作成→ダッシュボード反映」の一連フローで、実際のブラウザ操作に近い形で検証しました。このE2Eシナリオ作成には約15工数（約45万円）かかりましたが、リグレッションによるUI崩れをリリース直前に発見でき、リリース延期のリスクを最小化できました。
   QAフェーズでは、QA専任担当者がテスト結果を検証し、不具合発見リストをJiraで管理。重要度・優先度を付与し、開発チームにフィードバックしました。これに伴い、修正工数の見積もりとスプリントバックログの調整が発生しますが、「修正漏れによるリワーク発生率」を10%以下に抑えることができました。
   テスト全体の工数合計は約40工数（約120万円相当）でしたが、「リリース後の障害対応工数を約50工数（約150万円）削減」できたため、費用対効果は非常に良好でした。

CI/CDパイプライン構築とデプロイ運用

開発フェーズが進む中で並行して進めたのがCI/CDパイプラインの整備です。前半でも触れましたが、VercelとGitHub Actionsを組み合わせた自動デプロイ環境を構築しました。
具体的には、GitHubリポジトリにプルリクエストが作成されると、GitHub Actionsがトリガーされ、以下のジョブを順次実行します。

1. lintチェック（ESLint/Prettier）

2. ユニットテスト（Jest実行）

3. 結合テスト（Cypressヘッドレスモード実行）

4. ステージング環境デプロイ（Vercel CLI経由）

5. デプロイ完了通知（Slack連携）
   Lintチェックやユニットテストはマージ前に必須とし、これらが失敗するとレビューが通らずマージできない仕組みとしました。結合テストはステージング環境デプロイ後に実行することで、実際の環境に近い条件での確認を行い、問題なければステージング環境へのアクセスが可能となります。ステージング環境でOKサインが出たら、mainブランチへマージし、本番環境へ自動デプロイされる流れを構築しました。
   CI/CD構築工数は約20工数（約60万円）でしたが、リリース作業が手動でマンパワーを消費していた従来体制と比べ、デプロイにかかる時間が70％削減されました。また、人為的ミスによるバージョン不一致やキャッシュ漏れのリスクも大きく下がり、本番リリース時の安定性が向上しました。
   ただし、CI/CDパイプラインにはトラブルもありました。例えば、ステージング環境でのみ発生するサードパーティAPIの認証エラーが、本番環境では発生しないことを想定しておらず、結合テストが毎回失敗する事象が発生しました。この原因は、ステージング環境ではAPIキーを別のサービスIDで発行していたため、スコープ（許可範囲）が異なっていたというものでした。
   対策として、テスト用APIキーも本番環境と同等のスコープを付与し、GitHub Actionsで環境変数として読み込む際に、自動でステージング用と本番用のキーを切り替える仕組みに修正しました。これにより、ステージングでも本番同様の動作を確認できるため、結合テストの信頼性が向上し、デプロイ時のエラー発生率が大幅に低減しました。

運用保守フェーズでのコスト管理と改善

本番リリース後は、運用保守チームが中心となってシステム安定稼働と機能改善を進めました。運用保守フェーズでのポイントは「定常運用と改善提案を両立させること」「コストを可視化し、最適化を図ること」です。
まず定常運用については、バックエンドのJava APIおよびサーバーレス関数の監視をAWS CloudWatchで行い、フロントエンドのエラーログやパフォーマンス監視をVercel Analyticsで可視化しました。たとえば、APIレスポンスタイムが500msを超える場合にアラート発報、またフロントエンドではページロード時間が2秒を超えた場合にSlack通知を仕掛けるなど、閾値を細かく設定して問題を検知する仕組みを整えました。
次に、費用管理については月次で「ホスティング費用（Vercel帯域料）」「サーバーレス関数実行回数」「サードパーティAPI利用料」をまとめてダッシュボード化し、開発会社との定例ミーティングで報告しました。特にサーバーレス関数の呼び出し回数は月間で約100万回ほど発生しており、無料枠を超えた部分は都度請求が発生するため、不要な関数呼び出しや頻度の見直しを行い、呼び出し数を15％削減しました。これにより年間約25万円ほどコストを削減できました。
運用保守においては、機能追加要望の優先順位を定期的に見直し、スコープを明確化して開発会社に見積もりを依頼することで、予算超過を防ぎました。たとえば、売上分析レポートのUI拡充要望が上がった際、「詳細なドリルダウン機能は別途大規模開発が必要」と判断し、UI改善を先行し、ドリルダウンは次期投資案件として切り出すことで、当初予算の150万円を80万円に抑えた事例があります。
また、開発会社とのコミュニケーションをスムーズにするため、運用保守用のチャットチャンネルを立ち上げ、軽微なバグ報告や改善要望を都度投稿し、スプリントバックログに反映してもらう体制を整えました。これにより「小さなUI調整でもいちいちメールで見積もり依頼する手間」を省き、開発会社の対応スピードが向上し、保守コストの増加を抑えられました。

成果と得られたビジネスインパクト、学び

このマイクロフロントエンド移行プロジェクトを通じて、複数の成果とビジネスインパクトが得られました。まずは、システム全体のリリースサイクルが短縮された点です。従来のモノリシック構成では、新機能をリリースするたびに全コードのビルド・統合テストが必要で、約4週間要していました。MFE移行後は、在庫管理機能のみの更新であれば約1週間程度で本番反映できるようになり、リリースサイクルが75％短縮されました。これにより、市場の変化に迅速に対応できるようになり、営業部門からも高評価を得ました。
次に、コスト削減効果です。初年度開発費用は約800万円（設計・実装・テスト含む）、運用保守費用は年間約600万円（月額約50万円）でした。これに対し、モノリシック構成のまま継続して機能追加を行った場合の概算が年間1,500万円以上と試算していたため、初年度だけで約700万円のコスト削減効果が得られたことになります。2年目以降も削減効果が継続し、3年間でトータル約1,500万円の予算節減となりました。
さらに、ユーザー満足度の向上も大きな成果です。在庫管理画面の表示速度が平均3秒→1秒に改善し、受注管理画面では操作性向上によりユーザーの作業時間が1日あたり平均30分短縮されました。これを金額換算すると、年間で社員工数削減効果が約200万円相当となり、定量的な成果として経営層にも報告できました。
学びとしては、以下の3点が特に重要でした。

1. 要件定義段階でプロジェクトのスコープを明確化し、追加要望は別フェーズで扱うこと。これにより、コスト管理と納期管理が安定し、ビジネス部門との認識齟齬を防げる。

2. UIの共通部分を独立ライブラリ化することで、保守コストが大きく削減できる。ただし、共通コンポーネントの粒度を事前に詰めないと、再設計による予算超過リスクがある。

3. 開発会社とのコミュニケーションルールを徹底し、仕様書やインターフェース設計書、APIドキュメントをしっかり共有することで、ベンダー間の齟齬を最小限に抑えられる。

今後の展望とまとめ

本プロジェクト成功後、次の段階として検討しているのが「ヘッドレスCMS導入によるコンテンツ管理機能の強化」と「Edge Functionを活用したリアルタイム通知機能の実装」です。ヘッドレスCMSを導入することで、非エンジニア部門でも商品マスターの更新やキャンペーンページの更新をWebブラウザ上で行えるようになり、開発会社への発注回数をさらに減らすことが期待されます。費用見積もりとしては、ヘッドレスCMS導入で初期設計・実装が約150万円、月額利用料が10～15万円程度を想定しています。
Edge Functionについては、Vercelのエッジネットワークを活用し、在庫残数が閾値を下回った際に即時に営業担当へSlack通知を行う仕組みを検討中です。これにより、ユーザー体験と業務効率のさらなる向上が見込めます。Edge Function実装費用は概算で約50万～70万円ですが、ROIを考慮すると投入価値は高いと判断しています。
まとめると、本記事ではモノリシックからマイクロフロントエンドへの移行プロジェクトを開発ノートとしてまとめ、要件定義から実装、テスト、CI/CD、運用保守、成果と学びまでを共有しました。特に「開発会社の選び方」「予算・費用相場」「発注」時の具体的注意点を実例ベースで紹介したことで、同様の課題を抱える開発プロジェクト担当者にとって有益な情報となるはずです。
マイクロフロントエンドへの移行は、初期投資や学習コストがかかる一方で、長期的な開発スピードとコストパフォーマンスの向上が見込めます。社内SEや技術リーダーとしては、ぜひ今回の事例を参考にして、自社の状況に合わせた最適なアーキテクチャ選定と開発会社選びを進めていただければと思います。