30代のエンジニアを採用するとき、まず技術スタックの一致を確認する。それは当然だ。しかし、採用の可否を最終的に動かすのはスタックではない。
見ているのは、この3〜5年で何を選んで、何を捨ててきたかという判断の軌跡だ。
同じReact歴5年でも、「なんとなく現場で使っていた」人と、「Vue.jsとの比較で、プロジェクトの規模と採用市場の観点からReactを選んだ」と語れる人では、採用判断が変わる。30代は経験が積み重なっている分、この差がはっきり見える。
採る側の視点——面談で確認する4つの問い
なぜ前職に入り、なぜ転職したのか
節目の判断理由を聞く。「成長したかった」「環境を変えたかった」という答えは、出てきた瞬間に解像度が低いと判断する。
「当時のフェーズで、バックエンド全体の設計を自分で一通り責任を持って実装できるようになりたいという気持ちが強かった。前職ではそれができなかった」くらいの解像度があれば、話が前に進む。転職を複数回繰り返してきた人でも、各ステップに自分の判断が乗っていれば評価は変わる。よく転職回数が多いと面接で不利だという人がいるが、きちんとした理由があれば全く問題にならない。自分で自分の行動に意味づけが言語化出来ていればOKだ。
逆に「上司が変わったので」「会社の方針が変わったので」という受け身の理由が並ぶと、年次が高いほど印象が厳しくなる。経験が長ければ長いほど、自分の意思で動いた履歴があるはずだからだ。
なぜその技術スタックを選んだのか
技術選定の理由を聞く。「プロジェクトで使っていたので」「チームが使っていたので」という答えは、深掘りが必要なサインだ。もちろん自分が選んで技術ではなくて、エバンジェリスト的に技術を推進する人がいて、その人に続いてその技術を選択するということはよくある話ではある。
採りたいのは、技術選定に自分なりの判断軸を持っている人だ。「チームの習熟度と運用コストを考えると、最初はモノリシックな構成の方が合理的だと判断した」と言えるか。「流れでKubernetesを導入したが、今思えばオーバーエンジニアリングだった」と自分の言葉で振り返れるか。
最近では、Claude CodeやCursorのようなAI開発支援ツールの活用状況も確認するようになった。ツール名を羅列できる人は多い。「どこは任せて、どこは自分で判断するか」の切り分けを設計できている人は、まだ少ない。その差が、AI時代の設計力を測る指標になってきている。
失敗したプロジェクトから何を学んだか
「チームのコミュニケーションが課題でした」という総括は情報量がほぼゼロだ。
「スプリント設計の粒度が大きすぎて、完了の定義が曖昧なまま走り続けた。テストが後回しになり、リリース直前に品質の問題が出た。次のプロジェクトでは、完了定義をPRマージではなくステージング確認まで含めるよう変えた」くらいの粒度が欲しい。
失敗そのものは評価に影響しない。失敗をどう言語化して、どう次に活かしたかが見えるかどうかを確認している。
次の3年で何をやろうとしているか
「御社の状況に合わせて頑張ります」という答えは、情報がほぼゼロだ。
「バックエンドの設計力は積めてきた。次の3年はプロダクト全体のアーキテクチャを持つ経験を作りたい。そのために、フロントエンドとインフラの両方に関与できるポジションを探している」と言えるかどうか。自分のキャリアを主体的に設計していると伝わる人は、面談の場で一段上に見える。
採られる側の視点 「判断の軌跡」を今から言語化する
この記事を読んでいるあなたが30代の転職検討者なら、一つお願いがある。
転職活動を始める前に、過去の仕事で「自分が選んだ判断」を5つ書き出してほしい。技術選定でも、転職のタイミングでも、社内のポジション移動でも何でもいい。
書き出してみると、「自分で決めた」と言えるものと、「成り行きだった」と認めざるを得ないものに分かれる。多くの場合、成り行きの方が多い。それは問題ではない。問題は、その後を自分の言葉で語れるかどうかだ。私だって大抵の選択は成り行きであるが、それもそれが今の自分にどのような影響を与えているのかの言語化は自分のこれからの将来のためにやってみてほしい。
「成り行き」を資産に変える語り方
「成り行きで使うようになった」技術でも、その後の数年間でどう深めたか、どんな失敗をしてどう立て直したかがあれば、語れる軌跡になる。
「PHPを使い始めたのは現場に入ったからだったが、途中でフレームワークの設計思想に触れて、技術選定の観点を自分なりに整理するようになった。特にデータベース周りで設計の甘さから実装時に大変な思いをしたので、今では新規プロジェクトでは必ずORMとマイグレーション管理の設計から始める」という語り方は、出発点が成り行きでも、その後の判断が見える。出発点は関係ない。積み上げた判断が問われる。
面談前に準備すべき3つのこと
職務経歴書を磨く時間の半分を、以下の言語化に使ってほしい。
– キャリアの節目ごとの判断理由（入社・転職・ポジション変更、それぞれになぜその選択をしたか）
– 技術選定で捨てた選択肢（採用した技術だけでなく、検討して却下した選択肢とその理由）
– 失敗した経験とその後の変化（結果の総括ではなく、何を変えたかまで）
この3つが語れれば、技術スタックが完全に一致していなくても、採用の天秤は大きく傾く。「面接の練習」より、自分の経験を言語化する練習の方が、効果がはるかに高い。
一緒に働きたいと思う30代の共通点
採用面談で30代のエンジニアと話してきて、印象に残っている人には一つ共通点がある。自分のキャリアを「選んできた結果」として語れることだ。
使っている技術も、在籍してきた会社も、関わってきたプロジェクトも、すべてが「なんとなくそうなった」ではなく、「こういう判断でここに来た」という文脈がある。それが年次相応の厚みを作る。
採用の経営判断として考えると、エンジニア一人を採用して数ヶ月以内に離脱された場合の損失は、給与額をはるかに超える。教育コスト、チームへの影響、穴埋めの工数、次の採用にかける時間——これらを合算すると、ミスマッチ採用一件の損失は相当になる。
だからこそ、技術スタックの一致よりも、判断の軌跡の確認に時間をかける。スタックは入社後に習得できる。判断の姿勢は短期では変わらない。
「30代は職務経歴書が命」は半分しか正しくない
転職エージェントや人材会社系のメディアには、「30代は職務経歴書の完成度が採否を分ける」という話が繰り返し出てくる。間違いではないが、半分だ。
職務経歴書は面談の前フィルターとして機能する。スクリーニングを通過するために必要だ。しかし面談に進んだ後、採用を動かすのは書類ではなく、話した内容だ。
書類で通過した後に、面談で一段上の印象を残せる準備の方が、最終的な採用率を上げる。
職務経歴書を整える時間を削れとは言わない。ただ、その半分を判断の言語化に充てることを勧める。
FAQ
Q. 30代エンジニアの転職は、技術スタックが古いと難しいですか？
A. スタックの新旧より判断の軌跡が問われる。5年前の技術しか使っていなくても、「なぜその環境にいたか、そこで何を選んで深めたか」を語れれば評価は変わる。最新技術を使っていても「流れで使った」としか語れない人は、同じ評価にはならない。もちろん jQueryしか絶対にやりません！のような人はいわずもがな。
Q. 採用面談で「成り行きで転職した」と正直に話すと評価が下がりますか？
A. 成り行きであること自体より、その後の行動と振り返りが見られる。「成り行きだったが、入ってからこう動いた」という文脈があれば評価には影響しない。語れる判断がゼロだと苦しいが、出発点を問題にはしない。さらにいえば、どんな直感を感じたのか、そしてその判断を今振り返るとどう判断しているのか、について言語化できていればOK。
Q. 30代エンジニアを採用するとき、コーディングテストは実施しますか？
A. ポジションによる。設計力が必要なポジションなら、コーディングテストよりアーキテクチャの議論をすることが多い。「なぜこの設計にしたか」という判断の説明ができるかを確認している。また、当然ゼロからプロダクトを作ることよりもすでにあるプロダクトのコードを触ることが多いわけで、情報が限られていたり、決してきれいとは言えないコードを変更しなければいけない場合の現実的なアプローチについて議論する方が採用する側としては良いと考えている。
Q. 転職回数が多い30代エンジニアは不利ですか？
A. 本文にも書いたが回数より、各ステップに自分の判断が乗っているかを見る。3年以内の転職が3回あっても、「こういう判断でここに来て、ここを出た」と語れれば不利にはならない。逆に言えば、理由を語れなければ、回数が少なくても印象が変わる。
Q. 面談でキャリア設計を聞かれたとき、「御社に合わせます」はNGですか？
A. 採られる側としては最も安全に見える答えだが、採る側には情報がほぼゼロに映る。「自分はこういうキャリアを作りたい。その方向と御社の課題が合っていると思って応募した」と語れる人の方が、はるかに印象に残る。少なくともスタートアップにおいては個人の成長が会社の成長となるので、個人の成長の軸がない人は採用できない。
