Javaエンジニアのフリーランス面談でよく聞かれる質問と答え方｜面談官が確かめたいこと

Javaエンジニアのフリーランス面談でよく聞かれるのは、直近の案件の構成と担当範囲、設計で自分が決めたこと、遅い処理や障害をどう調べて直したか、レビューとテストをどう進めてきたかの4つです。面談官は、言語の知識の量より「このチームに入ってすぐに動けるか、任せた機能を自分で確かめながら仕上げられるか」を確かめようとしています。

答えるときは、模範解答を覚えるより、自分の経験から「技術の判断をした場面」と「問題を解いた場面」を3つほど選び、どの質問にもそこから答えられるようにしておくのが近道です。面談全般の答え方の型は業務委託の面談でよく聞かれる質問と答え方で解説しているので、この記事ではJavaの面談に固有の質問に絞ります。

Javaの面談で面談官が見ていること

Javaの案件の面談に出てくるのは、参画先のリーダーやアーキテクト、受託開発の会社の管理職であることが多く、本人もJavaで開発してきた人です。そのため、用語を知っているかより、話の中に出てくる判断の根拠と、調べ方の順番を聞いています。

面談官が知りたいのは、おおむね次の3点です。

1. 任せられる範囲：どの工程を、どの規模のチームで、どこまで一人で担えるか
2. 問題が起きたときの動き方：動かない・遅い・壊れた場面で、何を見て、何を直したか
3. チームとの相性：レビューの受け方や報告の仕方が、自分たちの進め方に合うか

以下の質問は、この3点のどれかを確かめるためのものです。質問の意図が分かれば、答えの中心に何を置くかも決まります。

よく聞かれる質問と答え方の考え方

ここで示す答えの例は、組み立て方を伝えるための架空の例です。そのまま使うのではなく、ご自身の経験に置き換えて準備してください。

1. 「直近の案件の構成と、あなたの担当範囲を教えてください」

確かめたいのは、任せられる範囲です。Javaとフレームワークのバージョン、データベース、クラウドの有無、チームの人数、担当した工程と機能を短く伝えます。「Spring Bootで開発」だけで終わらず、どの層のどの機能を、設計から担ったのか、実装だけなのかを分けて話すと、後の質問との食い違いが起きません。

架空の例：「Java 17とSpring Boot 3系、PostgreSQLの構成で、受注管理の機能を詳細設計から担当しました。全体は15名、私のチームは4名です。APIの設計と実装、単体テストまでを担い、基本設計は社員のリーダーが担当していました」

2. 「設計で、あなた自身が決めたことは何ですか」

Javaの面談に多い質問です。トランザクションの範囲、テーブルの切り方、APIの形、例外の扱い、ライブラリの選び方など、自分で決めた点と、決まっていたことに従った点の線を示します。決めた点については、ほかの選択肢を捨てた理由まで話せると、設計に関われる人として伝わります。

架空の例：「注文の確定と在庫の引き当てを一つのトランザクションにするか迷い、在庫の更新が外部のシステムと連携していたため分け、失敗時の補正処理を設けました」

3. 「遅い処理や本番の障害を、どう調べて、どう直しましたか」

最も掘り下げられる質問です。答えは次の順番で組み立てると伝わりやすくなります。

• 何から異常に気づいたか（監視、ログ、問い合わせ）
• 原因をどう絞ったか（実行計画、スレッドダンプ、プロファイラ、ログの突き合わせ）
• どんな対策を並べ、なぜそれを選んだか（SQLの書き換え、インデックス、キャッシュ、設定の変更）
• 直した後に何で確かめたか
• 再発を防ぐために何を残したか

「インデックスを追加して直りました」だけで終わると、原因にたどり着くまでが見えません。どの情報を見て原因を絞ったかを話せると、調査を任せられる人として受け止められます。

4. 「コードレビューで指摘されたこと、指摘したことを教えてください」

チームとの相性を確かめる質問です。指摘を受け入れて直した経験と、ほかの人のコードに気づいた点を一つずつ話します。面談官は、正しさよりレビューを通じてチームの決まりに合わせられるかを見ています。自分の流儀を押し通した話は避けたほうが無難です。

5. 「テストはどのように書いていましたか」

JUnitやMockitoでの単体テスト、Spring Bootのテストの仕組みを使った結合テスト、テスト仕様書で管理する進め方のうち、経験した型を話します。業務システムの案件では、自動テストだけでなく、テスト仕様書と結果の記録を求められる現場が多く残っています。両方の経験があれば、どちらの文化にも入れることを伝えましょう。

6. 「古いバージョンや、独自のフレームワークの経験はありますか」

Java 8以前や、社内で作られたフレームワークで動くシステムの保守・移行の案件で聞かれます。古い環境の経験は、新しい環境の経験と同じくらい価値がある場面です。移行の経験があれば、移行前後のバージョン、影響の調べ方、起きた問題と対処を順に話します。経験がなくても、「新しい機能を使わずに、現場の決まりに合わせて書けること」を伝えれば十分です。

7. 「業務の知識はどのように身につけましたか」

金融・会計・物流などの業務システムの案件で、業務のルールを理解して設計に反映できるかを確かめる質問です。業務の担当者への聞き方、用語の整理の仕方、設計書への落とし方を話します。同じ業界の経験がない場合は、知らないことをどう確かめるかの進め方を話すと、未経験の業界でも任せられる印象になります。

8. 「開始できる時期、稼働日数、出社できる日を教えてください」

条件の確認ですが、答え方で印象が変わります。現在の案件の終了時期と引き継ぎの見込み、週の稼働日数、出社できる曜日や頻度を、あいまいにせず伝えます。Javaの業務システム案件では、結合テストやリリースの時期に出社を求められることがあるため、その可否も添えておくと話が早く進みます。

9. 「なぜフリーランスで、なぜこの案件なのですか」

長く続けてもらえるか、案件の中身を理解して応募しているかを確かめる質問です。働き方の希望だけでなく、その案件のシステムの種類や工程のどこに自分の経験が合うのかを添えると、案件との合い方が伝わります。

技術テストやコーディングテストがある場合

Webサービスの案件では、面談と合わせて短いコーディングテストや、コードを見ながらの質問がある場合があります。業務システムの案件では、設計書やSQLを見せて考えを聞く形もあります。

対策は、難しい問題を解く練習より、自分が書いたコードについて、なぜそう書いたかを説明できるようにしておくことです。公開できる範囲の個人のコードがあれば、面談の前に見直しておきましょう。課題の提出を求められたときの線引きや備え方は技術面談・コーディングテストへの備え方で解説しています。

準備は「判断の場面」と「問題を解いた場面」を3つに絞る

上の質問は数が多く見えますが、答えの材料は共通しています。準備は次の手順で進めると効率的です。

1. 場面を選ぶ：設計の判断、性能の改善、本番障害の対応、移行やレビューなど、性質の違う場面を3つ選ぶ
2. 場面ごとにメモをつくる：構成、気づいたきっかけ、調べた順番、選択肢、選んだ理由、確かめ方、学びを書き出す
3. 構成の数字をそろえる：JavaとSpringのバージョン、チームの人数、担当した期間を、どの場面でも同じ数字で言えるようにする
4. 2分版と5分版をつくる：最初は2分で話し、掘り下げられたら詳しく話せるようにする
5. スキルシートと照らし合わせる：シートの担当内容と話の内容が一致しているかを確かめる

スキルシートとの一致は特に大切です。面談官はシートを見ながら質問するため、シートに「設計」と書いてあるのに話が実装だけだと、どちらも信用されにくくなります。シートの書き方はJavaエンジニアのスキルシートの書き方、冒頭の自己紹介の組み立て方は面談の自己紹介の記事で解説しています。

面談の相手によって重心が変わる

Javaの面談は、相手によって聞かれる内容の重心が変わります。

受託側の案件で、元請けの会社と発注元の両方と面談することもあります。その場合、元請けの面談では工程と成果物、発注元の面談では業務の理解と報告の仕方に重心を置くと、限られた時間を有効に使えます。

Javaならではの逆質問

面談の終わりには、こちらから質問できる時間があります。逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。Javaの案件では、次の点を聞いておくと判断がしやすくなります。

• JavaとSpringのバージョン、移行の予定の有無
• 設計書の有無と形式、レビューの流れ
• 自動テストとCIの整備の状況、テスト仕様書の運用
• 開発環境の入り方（クラウド上か、閉じたネットワークか、仮想デスクトップか）
• 結合テストやリリースの立ち会いの頻度と時間帯
• 自分が担当する機能の範囲と、基本設計を担う人

一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。逆質問で聞いた内容は、契約前の確認にもそのまま使えます。案件を選ぶときの確認点はJava案件の選び方で整理しています。

よくある質問

実装だけの経験で、設計の経験がない場合はどう話せばよいですか？

実装の中で自分が決めたことを話します。クラスの分け方、例外の扱い、SQLの書き方、テストの組み立てなど、小さな判断にも理由があります。設計書を書いた経験がなくても、「なぜそう書いたか」を説明できれば、設計に近づける人として見てもらえます。設計の経験を広げる考え方は上流工程の案件に入るために必要な経験で解説しています。

新しいJavaの機能を知らないと不利になりますか？

案件によります。新しい環境の案件では、仮想スレッドやレコードなど新しい機能の理解を聞かれることがありますが、古い環境の保守や移行の案件では、むしろ古い書き方に慣れていることが強みになります。知らない機能を聞かれたら、取り繕わず「使ったことはないが、こう理解している」と答えるほうが信用されます。2026年10月時点のJavaとSpringの前提はJavaのスキルの記事で整理しています。

面談で見送られたとき、Javaの案件で多い理由は何ですか？

担当範囲の説明があいまいで任せられる範囲が見えなかった、調査の話が結果だけで過程が見えなかった、スキルシートと話の内容がずれていた、といった理由が多く見られます。技術が足りないというより、伝え方で見送られることが少なくありません。見送られる理由と次に生かす方法は面談で見送られる理由の記事で解説しています。