ビルド環境刷新による開発スピード向上

まとめ

観点	内容
課題	Webpack 前提の大規模モノレポで、HMR の遅さ・初回/CI ビルドの重さ・キャッシュの不安定さが慢性化。 結果として、レビュー待ちが発生しやすく、変更の反映・検証に時間がかかっていた。
対応	Webpack とほぼ互換のある Rspack に段階的に切り替え。 変換・SourceMap・コード分割などの設定を整理し、キャッシュが安定して効く構成に再設計。 自動テストや E2E で互換性を確認しながら、無停止で移行。
運用	各 PR で Webpack / Rspack の二重ビルドを回し、差分（特にバンドルサイズ）を自動チェック。 ビルド時間やキャッシュ効率などの指標を可視化し、継続的に改善できる状態を維持。
結果・成果	HMR の体感速度とビルド時間が明確に改善。（例：差分ビルド -81%, 初回ビルド -67%）。 レビューが滞留しにくくなり、開発サイクルが軽く安定。 SSR / Storybook / Sentry など既存の仕組みを壊さずに効果を段階的に獲得できた。

背景と課題

プロダクトの前提

• Webpack 5 ベースの大規模フロントエンド（Monorepo、複数アプリ／共有 UI ライブラリ）
• TypeScript＋React。CSS は既存のグローバル CSS / Sass と Tailwind の併用（className / cx() ベース）
• ビルドは TS 変換 → CSS → 圧縮 → Source Map と段階が多く、周辺ツール（Sentry 等）も Webpack 前提で最適化されていた

表面化した問題

• HMR や初回ビルドが遅く、UI 改修の反復速度が低下
• CI ビルドがレビュー〜マージのリードタイムを圧迫し、リリースが後ろ倒しに
• 新規参画・端末性能への依存が大きく、開発体験とオンボーディングに負担
• 結果としてリリース頻度と MTTR に悪影響、運用コストも増加

遅延の根本要因

• Webpack の単一スレッド処理とローダー多段化により変換コストが高い
• キャッシュの粒度が粗く、小変更でも広範囲リビルドが発生
• モノレポ横断依存により「小さな改修 → 大きな再ビルド」になりやすい

既存改善の限界

• persistent cache / thread-loader / swc-loader などは導入済みで、局所的な改善は実施済み
• Vite / esbuild などへの全面置換は、プラグイン互換と段階移行性の観点でリスクが高かった

改善の目的（非機能要求）

• 変更 → 反映 のサイクルを短くし、UI 改修の反復速度を高める
• ビルド処理のムダを削減し、ローカル／CI ともに安定して速い 開発環境を維持する
• 小さな差分が大きな再ビルドを誘発しないよう、キャッシュと局所ビルドを有効に活用できる構成 にする
• 段階的に導入でき、必要に応じて即座にロールバックできる移行手順 を持つ

対応方針

基本方針

• ビルド基盤を Webpack から Rspack へ一括切り替えした。
• 並走運用は採用せず、ビルドの基準系を一本化することで、成果物の整合性・CI 設定・キャッシュ設計をシンプルに保った。

一括切り替えが可能だった理由

• 自動テスト・E2E テストが十分に整備されていたため、切り替え後の動作差分を機械的に検証できた
• Storybook・SSR・i18n 抽出・監視連携など、主要パスに対して 再現性のある回帰チェック が実施できた
• 既存ビルド設定の依存関係やプラグイン使用箇所を事前に棚卸しし、互換性ギャップの影響範囲を明確化していた

一括切り替えを選んだ理由（並走しなかった理由）

• Webpack と Rspack を併存させると、成果物の差異検証・CI キャッシュ管理・依存の二重化 など、運用負荷が増大するため
• モノレポ環境では、並走よりも 基準系をひとつに統一した方が安定しやすい
• 「止めずに改善する」ことを優先し、切替点を明確にして影響を局所化できる形を選択した

進め方

1. Rspack 設定を Webpack 設定と機能パリティが取れるところまで再現
2. CI 上で Dev / Prod / E2E / Storybook を対象に差分検証
3. 一括切り替え → 直後に 自動テスト＋E2E の全件実行で安全性を確認
4. 影響が出た箇所は ローダー／プラグインレベルで局所修正

結果（Before / After 比較）

測定条件

• 同一マシン・同一ブランチ・同一コミット（依存ロック固定）
• 計測対象：Dev（HMR/差分）、Prod（初回/差分/ソースマップ）、CI（フルパイプライン）
• 各指標は 平均値 を掲載（括弧内に P95 を併記）

指標一覧

指標	Before: Webpack	After: Rspack	改善	備考
差分ビルド（Dev）	2.1s	0.4s	-81%	TS1ファイル変更
初回ビルド（Prod）	60s	20s	-67%	Minify+SourceMap

補足

• 「改善」は 短縮率（%） または 短縮時間（秒） のいずれかで統一
• ばらつきが大きい項目は ワーストケース を脚注に明記
• 互換性差分（未置換プラグイン等）がある場合は備考に記載

定性効果（開発体験・運用の変化）

• UI 改修の試行回数が増えた
  レイアウト調整や細かなインタラクション改善をためらわずに実施できるようになり、
  “動かしながら考える” スタイルが戻った。

• レビューの待ちが減り、会話が前向きになった
  「ビルドが終わるのを待つ」時間が減ったことで、PR が小さくこまめに出るようになり、
  議論が仕様・設計に集中するようになった。

• 新規参画者のオンボーディング負担が軽減
  ローカル初回ビルドの重さが解消され、開発に入るまでの心理的な壁が下がった。

• 緊急対応（不具合修正）のリードタイムが短縮
  修正 → 確認 → デプロイ までの反復が軽くなり、MTTR の実質的な改善につながった。

• CI の遅延が “気にするべきこと” から外れた
  チーム内で「CI を見て待つ」ではなく、「CI は通る前提で進める」空気に変わった。

• 開発体験が “疲れるもの” から “流れが途切れないもの” へ
  思考の連続性が保たれ、取り組んでいる問題への集中が維持されやすくなった。

まとめ

本取り組みは「ビルドを速くすること」自体が目的ではなく、開発の流れを止めないことを重視したものだった。

Webpack の最適化余地が頭打ちになっていた状況に対して、一括切り替えを選択できたのは、自動テスト・E2E による回帰確認の基盤がすでに整っていたことが前提にある。

結果として、ビルド処理は軽くなり、待ち時間は減った。
しかしより本質的な変化は、UI 改修・レビュー・検証といった日々の判断が“迷わず行えるようになった”ことにある。

• 開発者が考えている最中に余計な中断が入らない。
• 小さな改善がためらわれない。
• 不具合対応における初動が早い。

この「流れの良さ」は、プロダクトの品質、変更のスピード、そしてチームが継続的に改善を続けられる状態に直結する。

今回の改善によって、プロダクトを前に進めるための“連続性”を取り戻すことができた。

関連ブログ

https://shinagawa-web.com/ja/blogs/webpack-react-typescript