エンジニア面接の逆質問：開発体制と技術判断を確かめる

エンジニア面接の逆質問は、印象のよい質問をたくさん並べる時間ではありません。入社後に自分が関わる開発、レビュー、障害対応、技術選定について、実際にどのような判断が行われているかを確かめる会話です。「裁量があります」という答えを聞いて終わるより、最近の一例と、その判断を誰がどう決めたかを聞く方が、仕事を具体的に理解できます。

準備するのは、自分に重要な論点を二、三個、それぞれの最初の質問と短い追問です。この記事では質問の選び方、相手ごとの聞き分け、答えが曖昧だったときの進め方を扱います。一つの返答から会社の良し悪しを採点するリストでも、内定後の条件交渉を代わりに行うものでもありません。

自分の経験を聞き返されたときの準備には、Senior Project Deep Dive: Design Rationale, Your Most Complex Project, Questions for the HMが使えます。英語の練習問題で、特定の日本企業の面接形式を示すものではありません。

エンジニア面接でレビュー、リリース、担当範囲のカードを見ながら具体的な判断を確かめるイラスト

質問を作る前に自分の判断軸を決める

何を知りたいかが決まっていないと、使っている言語や開発手法を聞いても判断材料になりません。まず「この回答によって、何が分かれば自分の準備や応募判断が変わるか」を一文にします。

たとえば、実装経験はあるが本番運用を学びたい候補者なら、誰が障害対応をするかだけでなく、参加前の準備や支援を知る必要があります。複数チームのAPIを担当したい候補者なら、技術名より変更の承認と互換性の責任を知りたいはずです。新卒なら、最初の仕事の範囲とレビューで受けられる支援が重要になるでしょう。

公開済みの情報も先に読みます。求人票にある言語をもう一度聞くより、「求人票にはJavaとありますが、新しいコンポーネントで別の選択を検討した最近の例はありますか」と、分かっている点と知りたい点を分けます。公開の技術記事は全社の現在の運用を保証しないため、対象チームにも当てはまるかを確認します。

自分の判断軸	最初の質問	回答から得たい具体例
レビューで設計を学びたい	実装前の設計相談とPRレビューはどう使い分けていますか	最近、設計やテストが変わった変更
運用まで責任を持ちたい	新しいメンバーが本番対応へ参加するまで、どんな準備がありますか	同行、手順、判断できる範囲
技術選定に関わりたい	最近、複数の実装案から一つを選んだ例を教えていただけますか	制約、比較案、決定者、見直し条件
チームを越えて開発したい	他チームのAPI変更で合意が必要なとき、どう進めますか	依存先、互換性、意見が割れた場合の決め方
入社後の期待を知りたい	最初の数か月で任せたい仕事と、良い進捗の目安は何ですか	実際の成果物と支援の方法

この表を全部聞く必要はありません。自分の優先順位と、その面接で既に説明された内容から選びます。評価を狙って難しい単語を増やすより、回答を受けて次の一問を変えられる方が会話として自然です。

Googleのコードレビュー基準は、改善を進めることとコードの健全性を保つことの両方を扱い、必須ではない学習上のコメントを区別しています。この公開例を参考に、「必ず直す指摘と学習のための提案をどう分けていますか」と聞けます。応募先が同じ基準を採用していると推定するのではなく、相手の実例を確かめるための問いです。

相手が答えられる範囲に質問を合わせる

エンジニアには、レビュー、変更の検証、開発環境、最近の技術的な判断を聞きやすいでしょう。マネージャーには、仕事の優先順位、担当範囲、他チームとの調整、期待する成果を確認できます。採用担当には、選考の次の段階、配属の確認方法、条件に関する正式な窓口を聞きます。これは聞き分けの目安であり、役職だけで回答できる範囲を断定するものではありません。

たとえば日々のオンコールを担当していない面接官が、詳細な回数を答えられないことはあり得ます。「分からない」だけで悪い会社と判断するのではなく、「担当チームの方に確認できる機会はありますか」と情報の取得先を聞きます。逆に制度の概要を知っている人の回答でも、自分の配属予定チームに適用されるかは別途確認が必要です。

勤務条件や報酬について重要な不明点を残す必要はありません。ただし技術面接官に正式条件の確約を求めるより、採用担当との確認に分けた方が、誰の回答が何を示すのか明確になります。技術の逆質問を、条件確認を避けるための作法と捉えないでください。

時間が短い場合は「二点伺いたいです。まず、配属予定チームのレビューについて」と最初に絞ります。答えが長くなれば追問を一つに留め、別の論点は次の面談へ持ち越します。用意した質問を全部消化することが目的ではありません。

技術選定は採用技術より判断の経緯を聞く

「どんな技術を使っていますか」は事実確認には有効ですが、それだけでは自分がどう働くか分かりません。「直近で選択肢を比較した変更」「判断に使った制約」「採用しなかった案」を聞くと、技術判断の進め方が見えてきます。

公開された一例として、GitLabのArchitecture Design Workflowは、設計の文脈、決定、結果、比較した代替案を記録する軽量なADRを紹介しています。これはGitLabの文書であり、全ての会社にADRが必要だと示すものではありません。自分の逆質問には「判断の理由が後から分かるか」という観点だけを持ち込みます。

最初の質問は「最近、既存の仕組みを残すか置き換えるかで迷った例はありますか」。答えに応じて、「最終的に何を優先しましたか」「その選択を見直すとしたら、どんな状況ですか」と続けます。文書形式の名称を聞くより、実際の決定に戻れる情報が残っているかを確認しましょう。

面接官が「エンジニアが自由に決めます」と答えたら、「チームを越える影響がある場合も同じでしょうか」と範囲を絞れます。「全てマネージャーが決めます」なら、候補者が提案できる段階と、比較の材料をどう出すかを確認できます。どちらも一文だけで裁量の有無を判定するには不十分です。

「週一回リリースします」から会話を進める

以下は会話練習用に作った架空の例です。実在企業の面接回答ではありません。「どのようにリリースしますか」という質問に、面接官が「通常は週一回です」と答えたとします。知りたいのは頻度だけでなく、変更のリスクと責任をどう扱うかです。

まず「予定外の修正が必要になった最近の例では、誰がリリースの可否を判断しましたか」と聞きます。そこから三つの分岐を考えます。

回答のタイプ	自然な追問	その場で分かること／残ること
具体例がある	その後、検証や手順で何が変わりましたか	対応と学習の一例。通常時にも同じかは未確認
「柔軟に対応します」と抽象的	差し支えない範囲で、直近の変更を一つ教えていただけますか	実務の例を追加できるか。機密で話せない可能性もある
自分の担当外だと言う	この点を確認できる担当者や面談はありますか	情報の取得先。制度そのものの有無は未確認

具体的な話があれば、「失敗した人は誰ですか」ではなく、検証、切り戻し、引き継ぎがどう変わったかに焦点を当てます。Google SREのポストモーテム章が説明する、個人を責めずシステムの改善へつなげる考え方は、質問を作る参考になります。ただし、この章の存在は応募先にも同じ文化がある証拠ではありません。

答えが曖昧でも、問いを変える余地があります。「障害」という大きな言葉が機密性の高い話を連想させたなら、「本番で想定と違ったときに、通常どの役割へ相談しますか」と具体的な相談経路へ移れます。非公開の顧客名、数値、内部文書の開示を求める必要はありません。

具体例、抽象的な回答、担当外の回答ごとに追問を変える逆質問の分岐図

自分の経験を聞き返されたときの短い接続

「あなたのチームではどうしていましたか」と返されることもあります。準備すべきなのは立派な制度の解説ではなく、自分が参加した一つの変更です。「当時は二人で確認していました」だけで終わらず、何が問題で、何を自分が変え、どこまで確かめたかを話します。

架空の練習回答なら、次のように組み立てられます。「私のプロジェクトでは、変更後に戻す手順が曖昧でした。私は手順のチェック項目を追加し、開発環境で切り戻しを試しました。本番の運用方針はリーダーが決めたため、私が全体を設計したとは言えません」。自分の担当とチームの決定を分けることで、追問を受けても説明できます。

実務経験がなければ授業や個人開発の例で構いません。「本番障害を経験していないので、学生チームでの不具合対応の例です」と範囲を示します。小さな経験を企業の運用責任と同じ規模に見せる必要はありません。

自分の話をした後は、相手の回答へ戻ります。「御社では、新しいメンバーがその判断に参加するとき、どのような支援がありますか」。自己紹介を長く追加する時間ではなく、共通の論点を理解するための接続です。

質問を具体的にする言い換え

「成長できますか」は、成長の意味も支援の種類も広すぎます。「最初に担当した変更に対して、誰からどのようなフィードバックを受けることが多いですか」なら、実際の仕事を確認できます。「技術的負債はありますか」より「機能追加と既存の改善が競合した最近の例で、優先順位をどう決めましたか」の方が、ゼロか有るかを聞く二択から離れられます。

「評価制度は公平ですか」と聞いても、短い肯定だけでは公平さを検証できません。「この役割で良い成果と判断された最近の仕事は、どんなものでしたか」と成果の例を聞き、その範囲が自分に期待される仕事と一致するかを確認しましょう。

質問の前置きは、自分の関心を一文で示す程度にします。「私はAPIの変更で他チームと調整した経験があるため、合意の進め方を知りたいです」。長い仮説や業界批判を先に並べると、相手が実例を答える時間を使ってしまいます。

面談後は事実、解釈、未確認を分けて残す

メモには回答の要旨だけでなく、誰が何の範囲について話したかを残します。「週一回」という数字を全社のリリース頻度へ広げないことが重要です。次のように整理すれば、別の面談で同じ点を聞く目的も明確になります。

区分	架空の記録例
聞いた事実	配属予定チームのエンジニアが、直近の緊急修正で二人が確認したと説明
自分の解釈	少なくともその修正では単独判断ではなかった
未確認	夜間も同じ体制か、新人が参加する前の準備は何か
次の確認	マネージャー面談で参加範囲と支援を聞く

複数の回答が違ったときも、すぐに矛盾と決めず、部署、時期、通常時と例外時の違いを確かめます。逆質問の答えは判断材料の一部です。重要な正式条件は、適切な担当者から書面や指定の手続きで確認してください。

PracHubで自分の短い経験談を練習する

以下は面接官へ聞く逆質問そのものの一覧ではありません。聞き返されたときに、自分の判断と経験を説明するための練習です。他社・一般の質問を含み、日本の特定企業で出ることを保証しません。

PracHubの問題	逆質問への接続
Senior Project Deep Dive: Design Rationale, Your Most Complex Project, Questions for the HM	設計の理由を話して、相手チームの判断方法へ戻る
Behavioral: Handling a Conflict, Feedback, and On-Call Incidents	対立や運用経験を、相手への批判なしに説明する
Pushing Back on a Decision That Hurt Your Team: Process, Review and Delivery Impact	反対意見の出し方と意思決定の範囲を整理する
Make decisions with limited data	不確実な状況で何を確認して決めたかを話す
Staff Engineer Hiring-Manager Round: Platform Ownership, AI Adoption, and Cross-Team Influence	シニア層が自分の責任と他チームとの境界を説明する

まずプロジェクトの判断を深掘りする問題で、自分の例を短く話し、その後に聞きたい逆質問を一つ付けてみてください。よい準備の目安は、質問を暗記できたことではなく、答えを聞いて次の問いを変えられることです。