Spring Bootの依存関係を面接で答えるコツを解説。starter、BOM、parent POM、exclusion、競合解決まで整理して理解できるので、追質問にも強くなります。
Spring Boot の面接対策をしている候補者の多くは、`spring-boot-starter-web` と `spring-boot-starter-data-jpa` を迷わず挙げられます。ですが、実際に候補者を見分ける Spring Boot の依存関係に関する面接質問は、「starter を挙げてください」ではありません。むしろ、「その starter はクラスパスに何を追加し、2つの starter が同じライブラリの競合するバージョンを引っ張ってきたら何が起こるのか」です。そこで、暗記した答えは尽きます。
このガイドは、starter 名は知っていても、その仕組みを説明する必要がある候補者向けです。つまり、starter が実際に何を束ねているのか、dependency management がどのようにバージョンを揃えているのか、BOM と parent POM が本当に何をしているのか、そして exclusion をどう説明すればいいのかを解説します。これらを平易な英語で答えられれば、技術面接の Spring Boot 依存関係の質問の大半には対応できます。
なぜ面接官は最初の1分を過ぎると starter 名に興味を失うのか
暗記回答の問題
よくある流れがあります。面接官が「Spring Boot は依存関係をどう扱いますか？」と尋ね、候補者が「`pom.xml` に starter を追加すれば、あとは Spring Boot がやってくれます」と答える。間違いではありませんが、その答えは入門チュートリアルを読んだ人の答えであって、リリース前の夜11時にクラスパスの競合をデバッグしたことがある人の答えではありません。
問題は、候補者が starter 名を知らないことではありません。問題は、少しでも追質問が来ると答えが崩れることです。「`spring-boot-starter-web` は実際に何を引っ張ってきますか？」「なぜ Jackson のバージョンを指定しなかったのですか？」「同じ logging ライブラリの異なるバージョンを必要とする2つの starter があったら、何が起こりましたか？」この3つすべてに対して、間を置いてから「Spring Boot が自動的に処理します」と返すなら、その面接は実質終了です。
これが Spring Boot の依存関係面接における暗記回答の失敗パターンです。候補者は用語は知っていても、その背後にある理由を理解していません。
本当の面接回答に求められること
求められているのは、フレームワークの深い内部実装ではありません。理解すべきなのは3つです。候補者が依存関係の組み立て方を理解していること（starter は魔法ではなく、選別された artifact の集合です）、バージョンの整合性を理解していること（クラスパス上の Jackson のバージョンを決めるのは何か、そしてそれが BOM です）、そしてトレードオフを理解していること（starter を追加するとトランジティブな影響があり、不要なものを管理する手段が exclusion です）。
Spring の starter に関する公式ドキュメント では、starter を明確に「便利な dependency descriptor のセット」と説明しています。面接ではこの表現が重要です。仕組みを理解していて、単なるショートカットだと思っていないことが伝わるからです。 SHRM の技術選考に関する調査でも、面接官は一貫して「ツール選定の理由を説明する力」を事実の暗記より高く評価しています。依存関係管理は、まさにその違いが表れるテーマです。
Spring Boot Starter は魔法のパッケージではなく、依存関係の descriptor として扱う
starter が実際に束ねているもの
starter は、特定の用途ごとにまとめられた Maven 依存関係の一覧です。starter レベルに魔法はありません。互換性のあるライブラリを、手で寄せ集めてバージョンの整合性を推測しなくて済むように、あらかじめ定義した pom ファイルにすぎません。Web 用の starter は Web アプリケーション構築に必要なものを取り込み、JPA 用の starter はリレーショナルデータベースとやり取りするために必要なものを取り込みます。ポイントは一貫性です。同じ starter を使うプロジェクトは同じ依存関係グラフを持つため、チーム内でのバージョンのばらつきが起きにくくなります。
ここで「curated（選別された）」という言葉が重要です。Spring Boot チームがこれらの starter を保守し、組み合わせをテストしています。`spring-boot-starter-web` を追加すると、Spring MVC だけではありません。Spring MVC、JSON シリアライズ用の Jackson、組み込み Tomcat、そして validation サポートのテスト済み組み合わせが入ります。どれも魔法ではなく、誰かが保守している一覧にすぎないのです。
実際にはどう見えるか
2つの starter を使った `pom.xml` は次のようになります。
バージョン指定はありません。Jackson の artifact も、Hibernate の artifact も、Tomcat の artifact もありません。面接で安全な説明をするなら、こうです。「各 starter は dependency descriptor です。つまり、その用途に必要な artifact を列挙した pom です。`starter-web` は Spring MVC、JSON シリアライズ用の Jackson、組み込み Tomcat を取り込みます。`starter-data-jpa` は Spring Data JPA、JPA のデフォルトプロバイダである Hibernate、そして JDBC サポートを取り込みます。バージョンを指定しないのは、BOM で管理されているからです。」
この最後の一文が次の話題への橋渡しであり、多くの候補者が飛ばしてしまう部分です。
Dependency Management はバージョン混乱からあなたを救う仕組みです
なぜ通常の Maven 宣言だけでは不十分なのか
素の Maven プロジェクトでは、各 dependency 宣言は自分でバージョンを指定するか、親から継承する必要があります。依存関係が10個あり、それぞれがトランジティブに Jackson を引っ張ってくると、最終的なクラスパス上に異なる Jackson のバージョンが3つ存在することもあります。Maven の nearest-wins 解決ではそのうち1つが選ばれますが、「nearest」が「正しい」を意味するわけではありません。その結果、バージョンのばらつきが起きます。モジュール間で挙動が不一致になったり、原因不明の `NoSuchMethodError` が出たり、見た目は問題なさそうなのにクラスパスのデバッグに何時間もかかったりします。
Spring Boot の dependency management は、互換性のあるバージョンを1か所に集約することでこれを解決します。Boot の managed dependencies を使うと、BOM が把握している artifact についてはバージョンを指定しません。BOM が、どの Spring のバージョンとどの Jackson のバージョンが合うのかをすでに決めており、その判断がその依存関係を使うすべての箇所で一貫して適用されます。これは、素の Maven 宣言では得られない構造的な解決策です。
実際にはどう見えるか
`spring-boot-starter-web` をバージョンなしで追加すると、Maven は BOM を通じてバージョンを解決します。effective pom には次のような内容が表示されます。
このバージョンを自分で書いたわけではありません。BOM が決めたのです。面接では次のように簡潔に説明できます。「BOM は bill of materials の略で、選別された依存関係バージョンを定義する pom ファイルです。`spring-boot-starter-parent` を継承するか、BOM を直接 import すると、バージョンを指定しない dependency にはそのバージョンが適用されます。自分でバージョンを組み立てるのではなく、Spring Boot チームの互換性テストを信頼しているということです。」
この答えなら、結果だけでなく仕組みを理解していることが示せます。
BOM と starter parent は実際には何をしているのか
`spring-boot-starter-parent` と Spring Boot の BOM（`spring-boot-dependencies`）は、どちらも同じ種類の問題を異なる角度から解決しています。BOM はバージョン一覧です。数百のライブラリに対する互換バージョンを定義します。親 POM は BOM を import し、さらに plugin の設定、文字エンコーディングのデフォルト、コンパイラ設定も追加します。すでに社内標準の parent POM があるプロジェクトでは、`spring-boot-starter-parent` を親にできないため、代わりに `<dependencyManagement>` セクションで BOM を直接 import します。バージョン整合性は同じで、継承のボイラープレートが減るだけです。
親 POM、BOM、そしてトランジティブ依存関係を一緒に説明できるようにする
spring boot starter parent がデフォルト設定をどう変えるか
プロジェクトの親として `spring-boot-starter-parent` を追加すると、すぐに3つの恩恵があります。BOM で管理されたバージョン、Maven plugin の妥当なデフォルト設定（compiler version、resource filtering、test 設定）、そして各モジュールで繰り返すボイラープレートの削減です。トレードオフは、親の枠を1つ使うことです。社内の parent POM を使うチームは、代わりに BOM を直接 import します。バージョン整合性は同じで、plugin 設定は自分たちで管理します。
実際にはどう見えるか
親 POM を使った最小構成の `pom.xml` は次のようになります。
このプロジェクトで `mvn dependency:tree` を実行すると、トランジティブ依存関係が明示的な宣言なしで入ってきていることがわかります。
これらの artifact はどれも自分で宣言していません。starter が列挙していたから一緒に入ってきたのです。
なぜトランジティブ依存関係が面接回答で重要なのか
ここが、面接官が本当に聞いている部分です。`spring-boot-starter-web` を追加しているとき、あなたは1つの artifact を追加しているのではありません。依存関係グラフ全体を追加しているのです。もし別の starter が `jackson-databind` の異なるバージョンを引っ張ってくるなら、競合が発生します。競合がトランジティブ依存関係から来ていると理解していなければ、修正できません。理解している候補者は「依存関係ツリーを見て、競合の発生源を調べました」と答えます。理解していない候補者は「exclusion を追加したら直りました」と答えます。後者は理解の証明ではなく、たまたまうまくいっただけです。
面接官が本当に期待している starter を説明する
Web、JPA、Security、Test、Actuator が中核の5つです
この5つの starter は、ほぼすべてのバックエンド面接で出てきます。何が入っていて、なぜ使うのかというレベルで知っておくのが最低ラインです。
`spring-boot-starter-web` は REST API や Web アプリケーションを作るためのものです。Spring MVC、Jackson、組み込み Tomcat、validation サポートが入ります。データベースアクセスを担当すると言ってはいけません。それは別の starter です。
`spring-boot-starter-data-jpa` は、JPA を使ったリレーショナルデータベースアクセス用です。Spring Data JPA、Hibernate、JDBC サポートが入ります。面接で安全に言うなら、Hibernate はデフォルトの JPA プロバイダですが、差し替え可能です。
`spring-boot-starter-security` は認証と認可のためのものです。Spring Security とデフォルトのセキュリティフィルタチェーンが入ります。「アプリを自動的に安全にしてくれる」と言いがちですが、それは誤りです。基盤はセットアップされますが、設定はあなたの責任です。
`spring-boot-starter-test` はテスト用です。JUnit 5、Mockito、AssertJ、Spring のテストユーティリティが入ります。デフォルトで test スコープなので、本番の artifact には入りません。
`spring-boot-starter-actuator` は本番監視用です。ヘルスチェック、メトリクス、環境情報のエンドポイントが入ります。本番サービスでは、これは任意ではありません。アプリが生きているかを知るために必要です。
実際にはどう見えるか
シンプルな CRUD API では、通常 `starter-web`、`starter-data-jpa`、`starter-test` を使います。サービスが本番に向かう段階で `starter-actuator` と `starter-security` を追加します。選んだ starter が依存関係グラフを定義し、auto-configuration 層がそのグラフを読み取って bean を組み立てます。starter は入力、組み上がった application context は出力です。
競合をスマートに見せるためではなく、修正するために exclusion を使う
なぜ競合はそもそも発生するのか
トランジティブ依存関係は、Spring Boot プロジェクトで起こる依存関係競合のほぼすべての原因です。2つの starter が同じライブラリを異なるバージョンで引っ張ってくることがあります。Maven の nearest-wins 解決では1つに決まりますが、「nearest」は「正しい」ではありません。結果として、片方の starter には合っていても、もう片方を壊してしまうバージョンが選ばれがちです。その失敗はコンパイル時ではなく、実行時に `ClassNotFoundException` や `NoSuchMethodError` として表れます。
きれいな修正方法は exclusion です。トランジティブに引っ張ってきている starter から問題のバージョンを外し、代わりに本当に使いたいバージョンをトップレベルで宣言します。
実際にはどう見えるか
よくある競合の例として、`spring-boot-starter-web` とサードパーティのライブラリが、異なるバージョンの `commons-logging` をそれぞれ引っ張ってくるケースがあります。修正は次のとおりです。
exclusion の後に `mvn dependency:tree` を実行すると、その artifact がその枝から消えていることを確認できます。アプリがそのライブラリをまだ必要とするなら、希望するバージョンを直接宣言します。不要なら、そのまま外しておきます。
曖昧に聞こえない説明の仕方
面接で安全な説明は3段階です。「依存関係ツリーを実行して、どの artifact が競合を起こしているのか、そしてどこからトランジティブに入ってきているのかを確認しました。次に、間違ったバージョンを引っ張っている dependency に exclusion を追加しました。最後に、アプリがそのライブラリをまだ必要としているかを確認し、必要なら正しいバージョンを直接宣言しました。」この答えなら仕組みを理解していることが伝わります。「ただ除外しました」では伝わりません。
Maven の dependency exclusion に関する公式ドキュメント には、構文と考え方が説明されています。Spring Boot のリファレンスドキュメントにも、特に logging ライブラリについて既知の exclusion パターンが載っています。
Auto Configuration と Dependency Management を混同しない
これは別々の問題を解決しています
Spring Boot の依存関係面接で最も多い概念ミスです。はっきり言うと、dependency management はクラスパスに何を載せるかを決めるもので、auto-configuration はすでにあるものから Spring Boot が何を組み立てるかを決めるものです。両者は別の仕組みです。これを混同すると、面接官には危険信号です。つまり、候補者が Boot の実際の動きを理解しておらず、「動くことは知っている」だけだと見えるからです。
dependency management はビルド時に起こります。BOM と starter が、コンパイル済み artifact にどの artifact が入るかを決めます。auto-configuration はアプリ起動時に起こります。Spring Boot はクラスパスをスキャンして存在するライブラリを見つけ、その存在を確認する `@Conditional` アノテーションに基づいて bean を作成します。
実際にはどう見えるか
`spring-boot-starter-data-jpa` を追加すると、Hibernate と Spring Data JPA がクラスパスに載ります。これは dependency management です。アプリケーションが起動し、Spring Boot がクラスパス上に Hibernate を見つけると、`DataSource`、`LocalContainerEntityManagerFactoryBean`、`JpaTransactionManager` を自動構成します。あなたがそれらの設定を書く必要はありません。これが auto-configuration です。
面接での簡潔な答えはこうです。「dependency management はビルド時の話で、クラスパスに何が入るかを管理します。auto-configuration は実行時の話で、クラスパス上のものを使って Spring が何を組み立てるかを管理します。starter を追加しても、それだけで何かが設定されるわけではありません。ライブラリを使えるようにするだけで、auto-configuration が仕事をできるようにするのです。」
Spring Boot の auto-configuration に関するドキュメント では、この違いが明確に説明されています。技術面接の前に読んでおく価値があります。
バズワードの寄せ集めに陥らずに面接質問へ答える
候補者がすぐ答えられるべき短い回答
以下の質問は、Spring Boot の依存関係面接でほぼ毎回出てきます。それぞれに対して、1段落で簡潔に答えられるようにしておくのが最低限の準備です。
Spring Boot starter とは何ですか？ 「starter は dependency descriptor です。Web、永続化、Security、テストといった特定の用途に対して、互換性のあるライブラリ群をまとめた pom ファイルです。`spring-boot-starter-web` を追加するとき、魔法を追加しているのではありません。Spring MVC、Jackson、組み込み Tomcat のテスト済み組み合わせを追加しているのです。要するに、どのバージョンが一緒に動くかを、誰かがすでに調べてくれているということです。」
Spring Boot の dependency management は何をしますか？ 「BOM にバージョンの判断を集約します。バージョンを指定せずに dependency を宣言すると、BOM が互換性のあるバージョンを提供します。これでプロジェクト全体のバージョンのばらつきを防げますし、自分でライブラリのバージョンを突き合わせなくて済みます。」
`spring-boot-starter-parent` はなぜ重要ですか？ 「Spring Boot の BOM を継承しているので、数百のライブラリに対して managed versions が使えます。さらに、Maven plugin の適切なデフォルト設定も入るので、毎回同じ設定を書かなくて済みます。親として使えない場合は、代わりに `<dependencyManagement>` で BOM を直接 import します。」
exclusion はどう機能しますか？ 「まず依存関係ツリーを見て、どの artifact が競合していて、どの dependency がそれをトランジティブに引っ張ってきているかを調べます。次に、その dependency に exclusion を追加して、悪いバージョンをその枝から外します。必要なら、正しいバージョンを直接宣言します。」
実際にはどう見えるか
暗記回答と本物の回答の違いは、追質問が来た瞬間にすぐ表れます。「`spring-boot-starter-web` は何を含みますか？」という質問に、暗記回答は「Web 用の依存関係です」と答えます。本物の回答は「Spring MVC、JSON シリアライズ用の Jackson、組み込み Tomcat、validation API です」と答えます。どちらが実際に依存関係ツリーを見たことがあるかは、面接官には一目瞭然です。もう一方は、要約を読んだだけだとわかります。
採用担当者は、候補者が思うよりずっと早く本当の理解を見抜きます
採用担当者にとって強い回答とはどう聞こえるか
バックエンド面接を担当する採用担当者や技術面接官は、百科事典のような知識を求めているわけではありません。単純な3点テストを見ています。概念を定義できるか、結果を言えるか、1つトレードオフを説明できるかです。Spring Boot の依存関係なら、starter とは何か（定義）、クラスパスに何をするか（結果）、2つの starter が競合したらどうなるか（トレードオフ）を答えられるかどうかです。会話の中で2分あれば、この3つをすべて説明できる候補者は、面接の依存関係セクションを通過できます。
実際にはどう見えるか
赤信号は一貫しています。starter 名を列挙するだけで、それが何を引っ張ってくるのか説明しない。追質問のたびに「Spring Boot が自動的にやってくれます」と答える。競合の説明なしに、exclusion は「ただ追加するもの」と述べる。auto-configuration と dependency management を同じ文で混同する。
好印象のサインも同様に一貫しています。候補者は推測する前に dependency tree を見る。特定の starter が何を含むかを、その場で調べずに言える。実際に遭遇した競合を説明し、どう解決したかを話せる。BOM と parent POM の違いを理解しており、片方だけを使う場面も説明できる。この組み合わせ――定義、結果、トレードオフ、そして実例――こそが、バックエンド候補者を評価する人にとっての「強い答え」です。
FAQ
Q: Spring Boot の starter 依存関係とは何ですか？通常の Maven dependency とどう違うのですか？
starter は、Web、永続化、Security、テストなど特定の用途に対して、互換性のあるライブラリ依存関係をまとめた curated な pom ファイルです。通常の Maven dependency は、あなた自身が宣言する単一の artifact で、バージョンも自分で管理します。違いは、starter ならライブラリの組み合わせやバージョンを自分で手作業で組み立てなくても、テスト済みの組み合わせを使えることです。一方、通常の dependency ではその責任を自分で負います。
Q: Spring Boot の dependency management は内部で実際に何をしているのですか？
BOM に載っているすべてのライブラリに対して、互換性のあるバージョンを提供します。Boot プロジェクトでバージョンなしの dependency を宣言すると、Maven は effective pom の managed-versions セクションからバージョンを探します。これは BOM 由来です。これによりプロジェクト全体のバージョンのばらつきが防がれ、自分でバージョンを組み立てるのではなく、Spring Boot チームの互換性テストを信頼する形になります。
Q: `spring-boot-starter-parent` はバージョン整合性とトランジティブ依存関係にどう役立ちますか？
親 POM は Spring Boot の BOM を継承しており、数百のライブラリに対する managed versions を定義します。バージョンを指定せずに宣言した dependency には、その managed version が自動的に適用されます。starter が引っ張ってくるトランジティブ依存関係にも、何かが上書きしない限り BOM のバージョンが使われるため、手動のバージョン指定なしでもクラスパスの整合性が保たれます。
Q: 面接で説明できるようにすべき starter はどれで、それぞれ何を含みますか？
特によく出るのは、`starter-web`（Spring MVC、Jackson、組み込み Tomcat）、`starter-data-jpa`（Hibernate、Spring Data JPA、JDBC）、`starter-security`（Spring Security、デフォルトの filter chain）、`starter-test`（JUnit 5、Mockito、AssertJ）、`starter-actuator`（health、metrics、environment の各エンドポイント）です。各 starter が高レベルで何を含むか――すべてのトランジティブ artifact ではなく、主要なもの――を知っておくのが最低ラインです。
Q: 依存関係競合が起きたとき、exclusion はどう機能し、どう説明すればよいですか？
`mvn dependency:tree` を実行して、どの artifact が競合していて、どの dependency がそれをトランジティブに引っ張ってきているかを確認します。次に、その dependency の `pom` に exclusion を追加して、その枝から悪いバージョンを外します。アプリケーションがそのライブラリをまだ必要とするなら、正しいバージョンを直接宣言します。面接向けの答えでは、識別・除外・必要なら置き換え、の3ステップを明確に言うのが重要です。
Q: Spring Boot における auto-configuration と dependency management の違いは何ですか？
dependency management はビルド時の話で、クラスパスに何の artifact が載るかを管理します。auto-configuration は実行時の話で、クラスパス上に何があるかに基づいて Spring がどの bean を作るかを管理します。starter を追加するとライブラリがクラスパスに載ります。auto-configuration は起動時にクラスパスを見て、条件付きで bean を組み立てます。これは役割の異なる、別々の仕組みです。
Q: 候補者が Spring Boot の依存関係質問でよく犯すミスは何ですか？
一貫して見られるのは3つです。auto-configuration と dependency management を混同すること、競合の発生源をどう特定したかを説明せずに exclusion を語ること、そして追質問に対して「Spring Boot が自動的にやってくれます」と答えることです。どれも、候補者が用語は知っているが、仕組みを理解していないことを示します。
Q: 採用担当者は、候補者が本当に Spring Boot の依存関係を理解しているのか、それとも starter 名を暗記しただけなのかをどう見分けますか？
1つ追質問をすれば十分です。「その starter は実際に何を含みますか？」と聞くのです。スタックを理解している候補者なら、主要なトランジティブ依存関係を調べなくても挙げられます。starter 名を暗記しただけの候補者にはできません。2つ目の手がかりは、概念を抽象的に語るのではなく、実際に解決した競合――dependency tree、exclusion、修正――を説明できるかどうかです。
Verve AI は Spring Boot の依存関係面接対策をどう支援できるか
Spring Boot の依存関係面接に向けた準備の構造的な問題は、内容を読むのは簡単でも、プレッシャーのかかる場面で再現するのが難しいことです。BOM を紙の上では完全に理解していても、実際の面接で「dependency management と auto-configuration の違いは何ですか？」と聞かれると、話が回りくどくなってしまうことがあります。読むことは受動的です。予想していなかった追質問に、その場で口頭で答えることは、まったく別のスキルです。
Verve AI Interview Copilot は、まさにそのギャップのために作られています。練習セッション中のあなたの回答を リアルタイムで聞き取り、用意された定型文ではなく、実際にあなたが話した内容に反応します。starter の説明を暗記した形で答え、トランジティブ依存関係の詳細を飛ばした場合でも、Verve AI Interview Copilot は、本物の面接官のようにその抜けを露わにする追質問を提示します。さらに、質問とあなたの回答に応じて ライブで回答案を提案 するため、フィードバックは一般的な評価基準ではなく、あなたの実際の答えに合わせて調整されます。そして、その間も 検知されません。デスクトップアプリは OS レベルで画面共有に検出されないので、本番と同じ環境で練習できます。Spring Boot の依存関係のように、真の試験内容が「プレッシャー下で理由付けを再構成できるかどうか」であるテーマでは、こうしたライブで応答性の高い練習こそが、実際に本番へつながる準備です。
まとめ
面接で問われる Spring Boot の依存関係知識は、外から見るよりずっとシンプルです。starter が何か、何を含むのかを説明できること。BOM がどのようにバージョン整合性を保つのかを説明できること。トランジティブ依存関係のツリーをたどれること。そして、実際の exclusion 修正を3ステップで語れること。この4つができれば、バックエンド面接でこのテーマについて出される質問の大半に対応できます。Spring エコシステムのすべての artifact を暗記する必要はありません。未知の質問にも筋道立てて考えられるだけの仕組み理解が必要です。
次の面接の前に、2つのことを練習してください。1つは、starter-BOM-parent の関係を平易な英語で簡潔に説明すること。もう1つは、dependency tree を実行して問題を見つけ、exclusion で修正した競合の実例を語ることです。この2つの答えを迷わず言えれば、starter 名の一覧よりもずっと面接で役立ちます。
Verve AI
アーカイブ