採用面接に関わる側と、転職活動をする側、両方の現場を見てきた立場から書く。
技術面接を終えたエンジニアが「手応えがあった」と感じているのに通過しない。逆に、深掘りされるほど採る側の目が冷めていく。そういうパターンには共通点がある。「最新技術を使ってきました」という訴求が、採る側に刺さっていないのだ。
この記事では、なぜそのフレーズが響かないのかを採る側の判断ロジックから解剖する。そして、面接で本当に見せるべきは何かを、具体的な言語化まで落とし込む。
「最新技術を使ってきました」が面談で刺さらない理由
採用面接でこのフレーズを使うエンジニアは多い。しかし採る側の反応が鈍い理由は、採用を事業の数字として考えれば自然と見えてくる。
採る側が面接で確認したいのは、技術を「使ったかどうか」ではない。なぜその技術を選んだのか、あるいはなぜ選ばなかったのかという判断プロセスを見ている。
「知っている」「現場で使える」「使うべき場面を判断できる」の3段階を考えると、採る側が評価するのは3段階目だ。最新技術を使ってきたという訴求は、1段階目か2段階目の話であることが多い。
採用コストという観点でも、この警戒は合理的だ。技術選定の判断基準がない人が入社すると、チームの意思決定速度が落ちる。「流行っているから試してみましょう」という提案が入ると、検討コストが発生し、既存の仕組みとの整合性を取る作業が増える。採用は一人あたり数百万円規模のコストがかかるプロセスだ。その投資に見合う人材かどうかを、採る側は面接の短い時間の中で判断しようとしている。
多くの技術面接攻略記事は「最新技術への積極的なキャッチアップ姿勢を見せよう」と推奨している。これは半分正しく、半分誤解を招く。キャッチアップすること自体は問題ではない。問題は、キャッチアップした技術を事業判断に接続できているかどうかだ。この一段深い評価軸が、既存の攻略記事では語られていない。
採る側が本当に評価しているもの：「使わない判断」ができるか
技術面接で採る側が深掘り質問を使う目的は、選定の根拠を確認することだ。「なぜその技術を選んだか」という問いへの回答が「流行っていたから」「チームで使っている人がいたから」で止まる候補者は、一段評価が下がる。
対照的に評価が上がる回答がある。事業フェーズ、チーム規模、運用コスト、将来の引き継ぎやすさを踏まえた判断を語れる人だ。
具体例を挙げる。
事業立ち上げ直後でビジネスモデルが検証段階にあるとき、マイクロサービスアーキテクチャを意図的に見送った経験を語れるエンジニアがいる。「サービスの境界線がまだ定まっていない段階で分割すると、後から結合し直すコストが大きい。モノリスで素早く仮説検証を回すことを優先した」という理由を言語化できる人は、採る側に強く評価される。
なぜか。採る側は入社後に同じ判断を求める現場があることを知っているからだ。技術を導入する判断だけでなく、導入しない判断もできるエンジニアは、チームの意思決定を助ける存在として映る。
「使わなかった」という経験は、一見するとアピールになりにくい。しかし実際には、事業フェーズとチームの状況を踏まえた判断力の証明になる。これを言語化できる候補者は少ない。だからこそ差がつく。
「使わなかった」経験が面談で武器になる場面
採用面接での具体的な評価シーンがある。「マイクロサービスを検討しましたが、今回はモノリスで十分と判断しました。理由は、まだユーザー数が少なくサービスの責務が明確でなかったためです」と話した瞬間、採る側の目が変わる。
これは珍しいことではない。技術選定の話を深掘りしていくと、「なぜ使わなかったか」を説明できる候補者が少ないことに気づく。使った技術の話は流暢にできるが、検討して見送った経験は語られない。
選定経緯を面接で話す際の構造は以下の4つで整理できる。
- 何を検討したか
- なぜ採用しなかったか（または撤退したか）
- 代わりに何を選んだか
- その判断の結果どうなったか
この4つを揃えて話せると、採る側は「この人は入社後も同じ思考で判断できる」と確信する。技術スタックの一致よりも、この判断プロセスの再現性を採る側は重視している。
同じ罠に繰り返し引っかかるパターン
SNSで話題になった技術を順番に試すだけのキャリアがある。職務経歴書を見ると、毎年のように「最新技術を導入しました」という記載が並ぶ。採る側にこのパターンが見えると、警戒が走る。
「振り回されやすい人」という印象だ。事業の課題から技術を選んでいるのではなく、技術への興味から逆算して業務に持ち込もうとしている人に見える。このタイプが入社すると、チームが技術評価のコストを負担し続けることになる。
いくつか代表的な罠のパターンを見ておく。
LLM
プロンプトを試した経験を「LLMを活用した開発経験あり」と職務経歴書に書くケース。プロダクトへの組み込みをどう判断したか、LLMを使わないほうがよい場面をどう判断したか、という問いで止まる候補者が多い。使ったことと、使うべき場面の判断ができることは別だ。
Kubernetes
小規模サービスにK8sを導入して複雑性だけが上がったケース。なぜコンテナオーケストレーションが必要だったのかを説明できない候補者は多い。「Dockerを使っていたのでK8sも」という流れで導入した経験は、採る側に適切な規模感の判断ができないシグナルとして読まれる。
マイクロサービス
事業フェーズを無視して分割した結果、デプロイコストと認知負荷だけが増えた経験。このパターンは採る側に「チームの生産性を下げる可能性がある」と判断される。分割の失敗を語ることより、なぜ分割が必要だったのかを語れないことが問題だ。
ノーコードツール
話題になるたびに乗り換えてきたが、コードを書くべき場面とそうでない場面の判断基準がない候補者。ツールを使いこなすことと、ツールの適用範囲を判断することは別のスキルだ。
AIツールへの「同じ問い」：Cursor・GitHub Copilot・Claude Codeも例外ではない
現在の採用市場では、AIコーディングツールの使用経験は有効なアピールになる。しかし評価されるのは「使ってみた」という事実ではなく、どこまで作り込んでいるかという深度だ。
GitHub CopilotやCursorを使っているだけでは差別化にならない。すでに多くのエンジニアが日常的に使っている。評価されるのは、カスタムルールやプロジェクト固有のコンテキストをどう設計して運用しているか、AIに任せる領域と自分が固める領域をどう切り分けているかだ。
Claude Codeを使って開発フローが変わった候補者は、その変化を言語化できるかどうかが問われる。「コード生成が速くなった」という答えと、「レビューとアーキテクチャ設計の密度を上げられた。ルーティンな実装をAIに委ねることで、設計判断に集中できる時間が増えた」という答えでは、採る側の評価がまったく違う。
AIツールも最新技術と同じ罠に引っかかる場合がある。流行だから使っているのか、自分の開発フローに本当に必要だから使い込んでいるのか。この問いに答えられる人が、AI時代の技術選定ができるエンジニアとして評価される。
採る側が見ているのは、AIツールを使えるという事実ではなく、どのように使うかを判断できる思考だ。この点は、最新技術一般に対する評価軸とまったく同じだ。
採られる側への自問：「必要だから使ったか、使いたかったから使ったか」
技術面接の前に、自分の職務経歴書を読み返してほしい。それぞれの技術選定について、以下の問いに答えられるか確認する。
- その技術がなければ事業課題は解決できなかったか
- 代替手段を真剣に検討したか
- 使わない選択肢を考えたか
答えられない選定が職務経歴書にある場合、その箇所は面接で深掘りされると危ない。採る側は職務経歴書を見ながら「この技術を選んだ理由を聞いてみよう」と思っている。答えが「流行っていたから」で止まると、それ以降の評価が下がる。
採られる側の戦略として、一つのエピソードを準備するだけで面談の密度が変わる。「最新XXを検討したが、今回はYYで十分と判断した。理由は……」という形だ。このエピソードが一つ語れると、採る側の評価軸に乗ることができる。
キャリアの棚卸しで確認すべきは技術の名前ではない。判断の根拠と、その結果どうなったかという事実だ。技術の羅列ではなく、判断の記録として職務経歴書を整理することが、面接での差別化につながる。
もちろん当てはまらないケースもある
ディープテックやR&D職では、最新技術への精通と最新論文のキャッチアップが直接評価される。この場合は最新技術への関心そのものが職務能力の証明になる。
技術ブランディングが採用戦略の柱になっている企業では、最先端技術の導入経験が求心力になる場合もある。エンジニアのコミュニティでの発信力や、技術的な先進性が組織の採用競争力に直結するポジションも存在する。
線引きの軸は一つだ。プロダクトを事業として成長させる役割か、技術そのものを研究・推進する役割か。
スタートアップの事業開発ポジションと、ディープテック企業の研究者ポジションに同じ訴求をするのは戦略ミスだ。前者には「使わない判断ができるか」という軸で話し、後者には技術への精通と探求の深さを前面に出す。
採られる側の実践として、求人票と面接官のバックグラウンドを確認してから訴求軸を決める。相手が事業側のエンジニアか、研究開発側のエンジニアかによって、評価される答えが変わる。応募するポジションの性質を見極めることが、技術面接の戦略の出発点になる。
