はじめに

株式会社Good Labでエンジニアをしているコータローです。
日々、Java・SQL・Gitなどの技術情報や、新人エンジニア向けの学習ノウハウ、
AI活用についての情報を発信しています。

Good Labについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト

「Java用語、結局なんだっけ？」シリーズの 最終回（第7回） です。

回	テーマ
#1	環境・基盤編
#2	DB接続編
#3	Web/サーバー編
#4	環境・DB・Web・例外スレッド
#5	モダンJava編
#6	フレームワーク編
#7（本記事・最終回）	ビルド・運用編

今回は ビルド・運用編 です。Maven / Gradle といったビルドツール、JUnit / Mockito といったテストツール、そして JAR / WAR / EAR の使い分けを整理します。

この記事のゴール

Maven と Gradle の違いを説明できる
「プラグイン」「依存性」が何を指すか分かる
JUnit と Mockito の役割を区別できる
JAR / WAR / EAR を使い分けられる

① Maven ― 「XML設定のビルドツール」

一言で言うと

Javaプロジェクトのビルド・依存解決・パッケージングを行うツール です。
設定は pom.xml に XML で記述します。

`pom.xml` の最小例

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0.0</version>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.2.0</version>
        </dependency>
    </dependencies>
</project>

主なコマンド

コマンド	用途
`mvn compile`	ソースをコンパイル
`mvn test`	テスト実行
`mvn package`	JAR / WAR にパッケージング
`mvn install`	ローカルリポジトリにインストール
`mvn clean`	ビルド成果物の削除

Maven のライフサイクル

validate → compile → test → package → verify → install → deploy

たとえば mvn package を実行すると、内部で validate → compile → test → package がすべて走ります。

よくある誤解

「Maven は Java を実行するツール」：違う。ビルド時の補助。実行は java -jar 等で行う。
「pom.xml は手で書かないといけない」：IDEやSpring Initializrが自動生成してくれる。

② Gradle ― 「Groovy / Kotlin DSL のビルドツール」

一言で言うと

XML ではなく Groovy または Kotlin のスクリプトで書ける、Mavenの後継的なビルドツール です。
設定ファイルは build.gradle（Groovy）または build.gradle.kts（Kotlin）。

`build.gradle` の最小例（Groovy）

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.2.0'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

主なコマンド

コマンド	用途
`gradle build`	ビルド全体
`gradle test`	テスト
`gradle bootRun`	Spring Boot を起動
`gradle jar`	JAR作成
`gradle clean`	クリーン

Maven vs Gradle

観点	Maven	Gradle
設定	XML	Groovy / Kotlin スクリプト
記述量	多い	少ない
学習コスト	低い（直感的）	やや高い
ビルド速度	普通	高速（インクリメンタルビルド）
採用率	中〜大規模で根強い	Spring Boot / Androidで主流

新規Java案件では Gradle が増加中。SpringのチュートリアルもGradleがデフォルトになっています。

よくある誤解

「Gradle は Maven の置き換え」：実態は 共存中。レガシーは Maven、新規は Gradle が多い。
「Gradle はAndroid専用」：違う。汎用のJavaビルドツール。

③ 依存性（Dependency） ― 「外部ライブラリの参照」

一言で言うと

自分のプロジェクトが使う外部ライブラリ（JARファイル） のことです。
「Spring Bootを使う」「JUnitを使う」は、すべて依存性を追加することで実現されます。

依存性の指定方法

Maven：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>3.2.0</version>
</dependency>

Gradle：

implementation 'org.springframework.boot:spring-boot-starter-web:3.2.0'

両方とも groupId:artifactId:version の 3つの組 で1つのライブラリを特定します。これを GAV座標 とも呼びます。

依存性のスコープ

Maven	Gradle	意味
`compile`（旧）	`implementation`	コンパイル＋実行時に使用
`test`	`testImplementation`	テスト時のみ使用
`provided`	`compileOnly`	コンパイルのみ（実行時は別途用意）
`runtime`	`runtimeOnly`	実行時のみ

推移的依存性（Transitive Dependencies）

自分のプロジェクトが A を依存
A が B を依存
→ B も自動でクラスパスに入る

これによって「Spring Boot を入れたら、Tomcat も Jackson も JSON も付いてくる」状態が実現されています。

依存性の確認方法

# Maven
$ mvn dependency:tree

# Gradle
$ gradle dependencies

よくある誤解

「依存性は手動でJARをダウンロードする」：違う。Maven Central などのリポジトリから自動取得。
「Spring Boot を compile スコープに」：現代Mavenは dependency だけでOK（スコープのデフォルトは compile）。

④ プラグイン ― 「ビルドツールの拡張機能」

一言で言うと

Maven / Gradle に「特定の作業」をさせるための拡張機能 です。
Spring Boot のJAR作成、コードフォーマット、Dockerイメージ生成、すべてプラグインが担います。

Maven プラグイン例

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
</plugin>

このプラグインを入れると、mvn package で 実行可能JAR（依存JARをすべて含むFat JAR） が作られます。

Gradle プラグイン例

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.2.0'
    id 'io.spring.dependency-management' version '1.1.3'
}

よく使うプラグイン

プラグイン	用途
`spring-boot-maven-plugin`	Spring Boot の実行可能JAR作成
`maven-surefire-plugin`	テスト実行
`maven-shade-plugin`	Fat JAR の作成
`jacoco-maven-plugin`	コードカバレッジ計測
`checkstyle-maven-plugin`	コーディング規約チェック

よくある誤解

「プラグインはIDEの機能」：違う。ビルドツールの機能拡張。IDEのプラグインとは別物。
「プラグインなしでもビルドできる」：基本的なコンパイルはできる。ただし Spring BootのJAR作成等はプラグイン必須。

⑤ JUnit ― 「Javaのユニットテストフレームワーク」

一言で言うと

Javaコードの単体テストを書くための標準的なフレームワーク です。
最新は JUnit 5（JUnit Jupiter）。

コード例

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

public class CalculatorTest {

    @Test
    void add_正常系() {
        Calculator calc = new Calculator();
        assertEquals(5, calc.add(2, 3));
    }

    @Test
    void add_ゼロ加算() {
        Calculator calc = new Calculator();
        assertEquals(0, calc.add(0, 0));
    }
}

実行すると、@Test が付いたメソッドが自動で実行されます。

よく使うアノテーション

アノテーション	用途
`@Test`	テストメソッドの宣言
`@BeforeEach`	各テストの前に実行（旧 `@Before`）
`@AfterEach`	各テストの後に実行
`@BeforeAll` / `@AfterAll`	クラス全体の前後（static必須）
`@DisplayName`	テストの表示名
`@ParameterizedTest`	パラメータ化テスト
`@Disabled`	テストの無効化

よくある誤解

「JUnit は Java の標準機能」：違う。外部ライブラリ。pom.xml または build.gradle への追加が必要。
「JUnit 4 と JUnit 5 は互換」：APIが大きく違う。org.junit.Test（4）と org.junit.jupiter.api.Test（5）は別物。

⑥ Mockito ― 「モックを作るライブラリ」

一言で言うと

テスト対象が依存している外部オブジェクトを「偽物（モック）」に差し替えるライブラリ です。
DBやAPIに実際にアクセスせずにテストを書けます。

コード例

import static org.mockito.Mockito.*;
import org.junit.jupiter.api.Test;

public class UserServiceTest {

    @Test
    void findUserName_存在する場合() {
        // モックを作る
        UserRepository mockRepo = mock(UserRepository.class);
        when(mockRepo.findById(1L)).thenReturn(Optional.of(new User("田中")));

        // テスト対象に注入
        UserService service = new UserService(mockRepo);

        // 検証
        assertEquals("田中", service.findUserName(1L));

        // モックが呼ばれたか検証
        verify(mockRepo).findById(1L);
    }
}

よく使うメソッド

メソッド	用途
`mock(クラス)`	モックを作成
`when(...).thenReturn(...)`	「このメソッドが呼ばれたらこれを返す」と定義
`when(...).thenThrow(...)`	例外を投げる挙動を定義
`verify(モック).メソッド(...)`	モックのメソッドが呼ばれたか検証

JUnit と Mockito の役割分担

ツール	役割
JUnit	テストの実行・検証の枠組み
Mockito	テスト対象が依存するオブジェクトの差し替え

新人〜2年目のうちは、「JUnit でテストを書く、Mockito で外部依存を切り離す」 という関係を押さえておけばOKです。

よくある誤解

「Mockito は JUnit の機能」：違う。別のライブラリ。組み合わせて使う。
「全部モックすればテスト書ける」：モックが多すぎると テストが実装の詳細を縛りすぎる ことに。バランスが重要。

⑦ JAR / WAR / EAR ― 「Javaの3つのアーカイブ形式」

一言で言うと

形式	用途	中身
JAR（Java Archive）	ライブラリ・通常のアプリ	`.class` + リソース
WAR（Web Application Archive）	Webアプリ	JAR + `WEB-INF/` + 静的ファイル
EAR（Enterprise Application Archive）	エンタープライズアプリ（複数モジュール）	JAR + WAR + 設定

構造の比較

my-lib.jar               my-web.war               my-app.ear
├── META-INF/            ├── META-INF/            ├── META-INF/
│   └── MANIFEST.MF      │   └── MANIFEST.MF      │   └── application.xml
└── com/example/         ├── WEB-INF/             ├── my-web.war
    ├── App.class        │   ├── classes/         ├── my-ejb.jar
    └── Util.class       │   │   └── *.class      └── lib/
                         │   ├── lib/                 └── *.jar
                         │   │   └── *.jar
                         │   └── web.xml
                         ├── index.jsp
                         └── css/
                             └── style.css

現代の使い分け

シーン	形式
ライブラリを作る・配布する	JAR
Spring Boot で Web アプリを作る	JAR（実行可能JAR）
既存のTomcatにデプロイする	WAR
大規模なエンタープライズアプリ（複数モジュール統合）	EAR

Spring Boot の登場以来、新規案件でWARを作ることは激減しました。EARはさらに稀。

よくある誤解

「Webアプリ=WAR」：違う。Spring Boot は実行可能JARを使う。
「JARの中身は暗号化されている」：違う。ただのZIP。unzip で展開可能。
「EAR は大規模アプリで必須」：違う。マイクロサービス化により、EARを使う案件は激減。

用語まとめ早見表

用語	一言で
Maven	XML設定のビルドツール
Gradle	Groovy/Kotlinスクリプトのビルドツール
依存性	プロジェクトが使う外部ライブラリ
プラグイン	ビルドツールの拡張機能
JUnit	Javaのテストフレームワーク
Mockito	モック生成ライブラリ
JAR	Java の標準アーカイブ
WAR	Webアプリ用アーカイブ
EAR	エンタープライズアプリ用アーカイブ

現場あるある誤解集

❌ 誤解	⭕ 正しい理解
「Maven は Java の実行ツール」	ビルドツール。実行は `java -jar` 等で行う
「Gradle は Android 専用」	汎用のJavaビルドツール
「依存性は手動でJARを置く」	Maven Central から自動取得
「JUnit は Java 標準機能」	外部ライブラリ
「Mockito は JUnit の機能」	別のライブラリ
「Spring Boot は WAR」	実行可能JAR が現代の標準
「JAR の中身は暗号化されている」	ただのZIP

演習問題

問題1：Maven / Gradle ⭐

次のうち、Gradle のコマンド はどれですか？

A. mvn package
B. gradle build
C. mvn dependency:tree
D. gradle bootRun

模範解答

正解：B と D

解説：

B、D：gradle で始まるのは Gradle のコマンド
A、C：mvn で始まるのは Maven のコマンド

ポイント：プロジェクトのトップに pom.xml があれば Maven、build.gradle があれば Gradle。

問題2：JUnit と Mockito の役割 ⭐

次の説明のうち、Mockito の役割 はどれですか？

A. @Test を付けたメソッドを自動で実行する
B. データベースに実際にアクセスせずに、リポジトリの動きを偽装する
C. テストの期待値と実際の値を比較する
D. テスト前のセットアップ処理を @BeforeEach で定義する

模範解答

正解：B

解説：

B が Mockito の役割：外部依存（DB、API等）を「偽物（モック）」に差し替える
A、C、D は JUnit の役割：テストの実行・検証・ライフサイクル制御

ポイント：JUnit がテストの「枠組み」を提供し、Mockito が「依存切り離し」を提供する、という分業関係。

問題3：JAR / WAR / EAR ⭐

次のシーンで、最適なパッケージング形式 はどれですか？

「Spring Boot で REST API を開発し、Docker コンテナで本番運用したい」

A. JAR
B. WAR
C. EAR

模範解答

正解：A

解説：

A の JAR が最適：Spring Boot は実行可能JARで動かすのが標準。java -jar app.jar で起動でき、Docker コンテナでも軽快に動く
B の WAR：外部Tomcatにデプロイする場合に使う。Spring BootならJARで完結する
C の EAR：エンタープライズ WildFly / JBoss EAP 等の大規模システム向け。マイクロサービス時代では稀

ポイント：「Spring Boot + Docker」の組み合わせは、現代の典型的なクラウドネイティブ構成。WAR / EAR はレガシー・特殊用途と理解してOK。

まとめ

ビルド・運用編の9用語のおさらいです。

Maven：XML設定のビルドツール
Gradle：Groovy/Kotlinスクリプトのビルドツール
依存性：プロジェクトが使う外部ライブラリ
プラグイン：ビルドツールの拡張機能
JUnit：Javaのテストフレームワーク
Mockito：モック生成ライブラリ
JAR：Javaの標準アーカイブ
WAR：Webアプリ用アーカイブ
EAR：エンタープライズ用アーカイブ

これらは 開発フロー全体の理解 に必要な基礎です。
「コードを書く → ビルドする → テストする → パッケージングする → 本番に配る」という流れの中で、どのツールがどこで動いているかを掴んでおくと、CI/CD や Docker といった次のステップにスムーズに進めます。

シリーズ全7回のまとめ

本シリーズで扱った全用語を、テーマ別に振り返ります。

回	テーマ	扱った用語
#1	環境・基盤編	JDK / JRE / JVM、クラスパス、JAR、アノテーション、ジェネリクス、リフレクション
#2	DB接続編	JDBC、ドライバー、Connection、コネクションプール、DataSource、トランザクション
#3	Web/サーバー編	サーブレット、JSP、Tomcat、WAR、フィルタ、Webコンテナ、ステートフル/ステートレス
#4	例外・スレッド編	checked / unchecked、try-with-resources、スレッド、synchronized、volatile、デッドロック
#5	モダンJava編	ラムダ、関数型インターフェース、メソッド参照、Stream、Optional、record
#6	フレームワーク編	Spring、Spring Boot、DI / IoC、Bean、AOP、Lombok、JPA、Hibernate
#7	ビルド・運用編	Maven、Gradle、依存性、プラグイン、JUnit、Mockito、JAR/WAR/EAR

合計約50の用語 を整理しました。
すべて「人に説明できる」レベルになっていれば、新人〜2年目を卒業して、現場で頼られるエンジニアへの第一歩を踏み出せます。

おわりに：シリーズを終えて

「聞いたことあるけど結局なんだっけ」は、現場で誰もが直面する壁です。
私自身、SES でJavaを書き始めた頃は、「JDBC」「DI」「コネクションプール」といった言葉に何度も詰まりました。

このシリーズで扱った用語は、1つ1つは難しくないけれど、全体を体系的に学ぶ機会が少ない ものばかりです。
新人〜2年目のうちに頭の中で繋がっていれば、Spring Boot やマイクロサービスといった次のステップが格段に楽になります。

質問・感想・「うちの現場ではこう呼んでいる」というフィードバックがあれば、Xでお気軽にどうぞ。

参考

@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！