大規模Mavenマルチモジュールを高速化せよ！『Maven Incremental Build』を正しく機能させるための設計思想
テックリードの皆さん、日々のビルド待ち時間にどれだけの開発者リソースをドブに捨てているか意識したことはあるだろうか？
数百万行規模のエンタープライズJavaアプリケーション。数十、数百に膨れ上がったMavenマルチモジュール構成。`mvn clean install` を実行した瞬間からファンが唸りを上げ、コーヒーブレイクが日常化する。そしてCI/CDパイプラインでは、わずか1行のJavaファイルの変更のために全モジュールが再ビルドされ、ビルドサーバーのCPUクレジットが溶けていく。
「Mavenは遅い。Gradleに移行すべきだ」
そんな短絡的な議論をする前に問いたい。あなたたちは、Mavenの真の姿を正しく使えているだろうか？
Mavenは、正しく設計・設定すれば十分に高速である。その鍵を握るのが、「Maven Incremental Build（インクリメンタルビルド）」 の本質的な理解と実践だ。本記事では、なぜ標準のMavenビルドが「全モジュールビルド病」に陥るのかを技術的に解剖し、真のインクリメンタルビルドを成立させるためのモジュール設計とプラグイン戦略を、プロの実践知見として余すところなく伝授する。
—
1. なぜ標準のMavenは「遅い」のか？（技術的解剖）
多くの開発者が誤解しているが、Mavenのコアエンジン自体は、変更されたリソースやコンパイル対象を検知する仕組み（タイムスタンプ比較）を本来持っている。Javaの標準コンパイラ（`javac`）も、出力先 `.class` ファイルとソースコード `.java` の更新日時を比較し、変更のないファイルの再コンパイルをスキップする機能（スマートコンパイル）を備えている。
では、なぜ大規模マルチモジュールにおいて、このインクリメンタルビルドが完全に崩壊するのか？ 理由は主に3つある。
① `mvn clean` の安易な常用
「クリーンナップしないとゴミが残ってバグる気がする」という恐怖から、多くのCIスクリプトや開発者のローカルエイリアスには `clean` が含まれている。`clean` を叩いた瞬間、`.m2` のローカルリポジトリ外にある各モジュールの `target/` ディレクトリが跡形もなく消滅する。これにより、コンパイラが持っていたタイムスタンプの文脈（前回のビルド成果物）が完全にリセットされ、全ファイルの強制再コンパイルが引き起こされる。
② 不適切なプラグイン設定による成果物の「ダーティ化」
多くのビルドプラグイン（例: `maven-resources-plugin` やコード生成系プラグイン）は、デフォルトの状態では「モジュール内のあらゆるリソース変更」を検知できず、ビルドのたびに全ファイルを `target/` へコピーし直す。これがトリガーとなり、依存関係にある上位モジュールが「下位モジュールの成果物が変わった」と誤認し、芋づる式にビルドが伝播していく。
③ 密結合したモジュール依存グラフ（DAGの崩壊）
これが最大の問題である。「モジュールAのサービスクラスにちょっと手を入れただけ」なのに、モジュールAがモジュールB, C, Dと循環参照に近い密結合をしており、さらに `maven-jar-plugin` や `maven-shade-plugin` が重いパッケージングを毎回実行するため、実質的にプロジェクト全体を再構築せざるを得なくなる。
—
2. 真のインクリメンタルビルドを成立させるための設計思想
Mavenでインクリメンタルビルドを極限まで効かせるためには、単に設定ファイルをいじるだけでは不十分だ。アーキテクチャレベルで以下の原則を死守する必要がある。
- 原則1: `clean` を日常のビルドから排除する
- ローカル開発において `clean` は「ビルドがおかしくなった時の最終手段」としてのみ使う。日常は `mvn compile` や `mvn test-compile` をベースにする。
- 原則2: ビルドの有向非巡回グラフ（DAG）を最小化する
- モジュール間の依存関係は常に単方向（上位から下位へ）に保ち、共通ユーティリティ層への無駄な逆依存を断ち切る。
- 原則3: プラグインの実行条件（Goal Execution）を限定する
- 「毎回動く必要のないプラグイン」を明示的にライフサイクルから切り離し、必要なとき（リリース時など）だけプロファイル経由で発火させる。
—
3. 開発スピードを激変させる神プラグインと設定のベストプラクティス
ここからが本題だ。マルチモジュールのビルド時間を劇的に短縮するために、ルートの `pom.xml` および各モジュールに組み込むべき「最強の設定構成」を公開する。
ルート `pom.xml` の最適化構成
以下の設定は、Mavenマルチモジュールにおけるビルドの無駄を削ぎ落とし、並列ビルドとインクリメンタル性を最大限に引き出すための決定版だ。
—
4. チーム全体の生産性を底上げする「プロの実践テクニック」
設定を整えただけでは、チームメンバーが `mvn clean install -DskipTests` を連打していれば意味がない。組織として開発スピードを維持するための実践的ノウハウを共有しよう。
① 変更のあったモジュールだけをピンポイントでビルドする（Reactorの活用）
Mavenには、特定のモジュールとその依存関係（あるいは逆）だけをビルドする強力なReactorオプションがある。これを使いこなすのがテックリードの嗜みだ。
- 特定のモジュールと、それに依存する上位モジュールを一網打尽でビルドする
# service-layer とそれに依存する webapp-api のみを再ビルドする（無関係な infrastructure-db は触らない）
mvn test-compile -pl :service-layer -am
- `-pl` (`–projects`): 対象モジュールを指定（artifactIdや相対パス）
- `-am` (`–also-make`): 指定したモジュールが依存している「下位モジュール」も自動的にビルドチェーンに含める
- 逆に、特定のモジュールを変更した際に、それに依存する上位モジュールを自動検知してビルドする
# core-domain を変更した際、それに依存する全てのモジュールを連鎖的にビルドする
mvn compile -pl :core-domain -amd
- `-amd` (`–also-make-dependents`): 指定モジュールより上に位置する依存モジュールをすべてビルド
② IDE（IntelliJ IDEA）との完全なる同期
Mavenのインクリメンタルビルドをローカルで最速で回すためには、IntelliJ IDEA自体のビルドシステムをMavenに委譲せず、「IntelliJ IDEA Compiler」に独自のインクリメンタル機構を持たせつつ、依存関係の解決だけをMavenに同期させるのが鉄則だ。
- IntelliJ設定手順:
`Settings` -> `Build, Execution, Deployment` -> `Build Tools` -> `Maven` -> `Importing`
- 「Keep project files up-to-date on external changes」にチェック。
- 「Use Maven output directory」のチェックを外し、IDEA独自の高速なメモリ内インクリメンタルコンパイルをヒットさせる。
—
5. テックリードが仕込むべき「共有化ルール」とCI/CDの最適化
個人のローカル環境だけでなく、チーム全体のCI/CDパイプライン（GitHub Actions, GitLab CI, Jenkins等）でもインクリメンタルな思想を取り入れる必要がある。
CIにおけるローカルキャッシュの戦略的利用
MavenのインクリメンタルビルドをCIで活かす最大のカギは、 `.m2/repository` のキャッシュ維持ではない。実はマルチモジュール間における `target/` のキャッシュこそが鍵となる。
GitHub Actionsを例に、モジュール間の依存関係と成果物を考慮したキャッシュ戦略のベストプラクティスを示す。
.github/workflows/build.yml の抜粋
name: Accelerated Maven Build
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout Source Code
uses: actions/checkout@v4
- name: Set up JDK 17
uses: actions/setup-java@v4
with:
distribution: ‘temurin’
java-version: ’17’
# Mavenの依存関係をキャッシュ
cache: ‘maven’
- name: Build with Incremental Optimization (Dev Profile & Parallel)
# -T 1C はCPUコア数に応じた並列ビルド（Core数自動割り当て）
# cleanを排除し、変更のあったモジュール群のみ、または全体でインクリメンタルコンパイルを走らせる
run: |
mvn compile test-compile -T 1C -Pdev-fast
ここで注目してほしいのは、CIであっても `clean` を外し、`compile test-compile` に留めている点だ。テストの実行（`surefire`）やパッケージング（`jar` / `war`）は、PRのマージ前検証やリリース時など、真に必要なフェーズでのみ走らせることで、CIのフィードバックループを劇的に短縮できる。
—
6. おわりに：ビルド待ち時間という名の「技術的負債」を断ち切れ
「ビルドが終わらないからコーヒーを飲む」
そんな開発風景は、今日のスピードがすべてを制するソフトウェアエンジニアリングにおいて、静かなる経営リスクであり、チームのモチベーションを蝕む癌である。
Mavenは古いツールではない。使いこなせていないのは、ツール側ではなく、我々人間の「お作法（`clean install` 依存症）」の方だ。
本記事で解説したモジュールの依存関係整理、プラグインのスマートコンパイル設定、そしてReactorオプション（`-pl`, `-am`）を駆使したピンポイントビルドをチームに導入せよ。
明日から、いや、今この瞬間から、あなたのプロジェクトのビルド時間は劇的に変わる。無駄な待ち時間を削ぎ落とし、コードを書く純粋な歓びをチームに取り戻してほしい。