こんにちは！日々のJava開発、本当にお疲れ様です。
大きめのプロジェクトになると、ビルドボタンを押した瞬間にコーヒーを淹れに行きたくなるくらい、待ち時間が長くてうんざりすることってありますよね。「たった1行変えただけなのに、なぜ全モジュールをビルドし直すんだ……！」と、心の中で絶叫した経験はないでしょうか。
今回は、そんな大規模Mavenマルチモジュールの地獄のような待ち時間を劇的に解消する『Maven Incremental Build（インクリメンタルビルド）』の核心に迫ります。
「ネットに書いてある通りにやったのに、なぜか全部ビルドされちゃうんだよな」というあなた。それはあなたのせいではなく、Mavenの内部メカニズムとマルチモジュールの構造的罠に原因があります。
これをマスターすれば、あなたの毎日のコーディングとビルドの待ち時間は劇的に変わり、開発のフローが驚くほどスムーズになりますよ。さあ、一緒にその仕組みを解き明かしていきましょう！
—
1. なぜ、標準のMavenはすべてのモジュールをビルドしてしまうのか？
まず、Mavenの基本思想からお話しさせてください。Mavenは設計思想として「再現性とクリーンネス」を最優先します。つまり、「いつ、誰が、どんな環境で実行しても、完全に同じ成果物が作れること」が正義なのです。
そのため、デフォルトのMavenは「安全のために、前回から何が変わったか分からないなら、とりあえず全部作り直そう（Clean & Build）」というアプローチをとります。
マルチモジュールにおける「依存関係の連鎖」という罠
例えば、以下のようなよくある構成を想像してください。
[root-project]
├── core-module (共通基盤)
├── user-module (ユーザー機能) -> core-moduleに依存
└── web-module (WebAPI) -> user-moduleに依存
ここで、`user-module` のソースコードを1行だけ修正したとします。開発者の頭の中では、「`user-module` と、それに依存する `web-module` だけビルドし直せばいいよね」と思いますよね。
しかし、素のMaven（標準コマンド）は、モジュール間の境界線をまたいだソースコードレベルの変更検知をデフォルトでは行っていません。そのため、依存関係グラフのトポロジカルソートに従い、結局 `core-module` から全モジュールの再ビルドを走らせてしまうのです。これが、ビルドが遅くなる真の原因です。
—
2. インクリメンタルビルドを正しく機能させるための設計思想
インクリメンタルビルド（差分ビルド）を成功させるためには、次の2つのアプローチを組み合わせる必要があります。
1. タイムスタンプとハッシュの正確な比較（プラグインの活用）
Maven本体任せにするのではなく、「前回のビルド以降にソースが変化したか」を正確に判定するプラグインを導入します。
2. モジュール間の結合度を下げる（設計の工夫）
不要な推移的依存（Transitive Dependencies）を排除し、必要なモジュールだけがピンポイントで反応する依存関係のグラフを構築します。
これから、実際に手を動かして、このインクリメンタルビルドの世界を体験してみましょう。
—
3. 【実践】最小にして最強のマルチモジュール環境を作る
百聞は一見にしかずです。実際にインクリメンタルビルドが機能するマルチモジュールプロジェクトの「HelloWorld」を作ってみましょう。
ディレクトリ構造は以下のようにします。
incremental-demo/
├── pom.xml (親POM)
├── module-a/
│ ├── pom.xml
│ └── src/main/java/com/example/A.java
└── module-b/ (module-aに依存)
├── pom.xml
└── src/main/java/com/example/B.java
ステップ1: 親POMの設定（ビルド効率化の基盤）
親となる `pom.xml` です。ここでは、コンパイルプラグイン（`maven-compiler-plugin`）にインクリメンタルビルドの挙動を有効化する設定を組み込みます。
- 解説: `useIncrementalCompilation` を明示的に `true` にすることで、Javaコンパイラは前回コンパイル時からのソースコードのタイムスタンプを比較し、変更のあったファイルだけを選択的にコンパイルします。
ステップ2: module-a の作成
次に、基礎となる `module-a` を作ります。
`module-a/pom.xml`
`module-a/src/main/java/com/example/A.java`
package com.example;
public class A {
public static String getMessage() {
return “Hello from Module A!”;
}
}
ステップ3: module-b の作成（module-aへの依存）
次に、`module-a` を利用する `module-b` です。
`module-b/pom.xml`
`module-b/src/main/java/com/example/B.java`
package com.example;
public class B {
public static void main(String[] args) {
// module-aのメソッドを呼び出す
System.out.println(A.getMessage() + ” and Hello from Module B!”);
}
}
—
4. 動作確認：インクリメンタルビルドの魔法を体感する
それでは、実際にコマンドを叩いて、インクリメンタルビルドがどのように動くのかを確認してみましょう。
初回ビルド（フルビルド）
プロジェクトのルートディレクトリで、以下のコマンドを実行します。
mvn clean compile
実行ログ（イメージ）:
[INFO] Reactor Summary for incremental-demo 1.0-SNAPSHOT:
[INFO]
[INFO] incremental-demo …………………………….. SUCCESS
[INFO] module-a ……………………………………. SUCCESS [ 1.234 s]
[INFO] module-b ……………………………………. SUCCESS [ 0.456 s]
[INFO] BUILD SUCCESS
初回なので、すべてのモジュールがしっかりとコンパイルされます。
2回目のビルド（何も変更していない状態）
ここで、ソースコードを一切変更せずに、もう一度コンパイルコマンドを実行してみます。（※ `clean` はつけません）
mvn compile
実行ログ（イメージ）:
[INFO] Reactor Summary for incremental-demo 1.0-SNAPSHOT:
[INFO]
[INFO] incremental-demo …………………………….. SUCCESS
[INFO] module-a ……………………………………. SUCCESS [ 0.120 s]
[INFO] module-b ……………………………………. SUCCESS [ 0.050 s]
[INFO] BUILD SUCCESS
お気づきでしょうか？ 実行時間が劇的に短くなっています。Maven内部で「おっと、前回のコンパイルからソースコードは1ミリも変わっていないな」と判断され、コンパイル処理がスキップ（あるいは極限まで省力化）されました。
差分ビルドの真骨頂（片方だけ変更した場合）
それでは、`module-b` の `B.java` だけを少し書き換えてみましょう。
`module-b/src/main/java/com/example/B.java` を修正:
package com.example;
public class B {
public static void main(String[] args) {
// メッセージを少し変更
System.out.println(A.getMessage() + ” -> Updated Module B!”);
}
}
この状態で、再びビルドを実行します。
mvn compile
実行ログがどうなるか、想像してみてください。
`module-a` は何も変更されていないため、コンパイル対象から外されます。そして、変更のあった `module-b` のみがピンポイントで再コンパイルされるのです！
—
5. さらに高速化するための「裏技」と現場の知見
ここまでの設定でも十分速くなりますが、大規模なエンタープライズ開発（数十〜数百モジュール）の現場では、さらに以下のテクニックを組み合わせることで、爆速のビルド環境が手に入ります。
1. 変更のあったモジュールだけをビルドする（Reactorの絞り込み）
もし `module-b` だけを開発していて、他のモジュールを一切巻き込みたくない場合は、Mavenの `-pl`（–projects）オプションを使います。
module-bとその依存関係のみをターゲットにして高速ビルド
mvn compile -pl module-b -am
- `-pl module-b`: 指定したモジュール（module-b）だけを対象にする
- `-am` (also-make): 指定したモジュールが依存している親・関連モジュール（module-aなど）も含めてビルドパスを通す
これを知っていると、巨大なプロジェクトでも数秒で自分の作業中モジュールの確認ができるようになります。
2. 並列ビルド（Parallel Builds）の導入
もしマルチモジュール間で依存関係が綺麗に分離されており、独立したモジュールが複数あるなら、マルチスレッドで同時にビルドを走らせるのが極めて有効です。
CPUコアをフル活用して4スレッドで並列ビルド
mvn compile -T 4
「もし依存関係が複雑に絡み合っているとデッドロックやビルドエラーの原因になるのでは？」と思われるかもしれませんが、そこを綺麗に整理整頓するのがアーキテクトの腕の見せ所です。循環依存（Circular Dependencies）は絶対に排除しましょう。
—
まとめ
今回は、Mavenマルチモジュールにおけるインクリメンタルビルドの仕組みと、それを正しく機能させるための設計思想について解説しました。
- なぜ遅かったのか: デフォルトではモジュール間の変更検知が曖昧で、安全のために全体を巻き込んでいたから。
- どう解決するか: `useIncrementalCompilation` を有効にし、変更のあったファイル・モジュールだけを正確にターゲットにする。
- さらなる効率化: `-pl` や `-am`、そして `-T`（並列ビルド）を使いこなす。
これをマスターすれば、ビルドの待ち時間という日々のストレスから解放され、より本質的なコードを書くことに集中できるようになりますよ。
あなたの毎日の開発が、劇的に快適で楽しいものになりますように！