「モダンな技術環境」「裁量のある開発」。求人票のこの手の言葉が、入社後にまるで違って見える。
エンジニア転職でよくある落差です。原因ははっきりしていて、判断に必要な情報が求人票に書かれていないからです。
言語名より、開発体制で決まる
求人票には言語やフレームワークが並びます。ただ、入社後の満足度を左右するのはそこではありません。
テストが書かれているか。コードレビューの文化があるか。リリースは週次か、半年に一度の大型リリースか。設計から関われるのか、決まった仕様を実装するだけか。ドキュメントは残っているか。障害対応は当番制か、特定の人に集中しているか。
同じ「Java」の求人でも、この中身が違えば毎日はまったく別物になります。そしてどれも求人票には書かれていません。
面談で聞くべき5つ
だからこそ、面談で直接確かめます。遠慮する必要はありません。
- 開発の進め方を教えてください。スプリントの単位、朝会の有無、仕様が決まるまでの流れ
- コードレビューはどのくらいの粒度でやっていますか。必須か任意か、誰がレビューするか
- テストコードの方針は。カバレッジを追っているか、そもそも書く文化があるか
- 直近1年でリリースした回数は。開発サイクルの実態が一番よく出ます
- 技術選定は誰が決めていますか。現場に裁量があるかどうかが分かります
答えが曖昧だったり、質問の意図が伝わらなかったりする場合、それ自体が情報になります。
SES・客先常駐から自社開発へ
移っている人は珍しくありません。ただし選考の見られ方が変わります。
「何を作ったか」より「どう作ったか」を問われる。使った言語を並べるだけでは通りにくく、設計をどう判断したか、レビューで何を指摘されたか、障害にどう対応したかを言語化できるかが分かれ目です。
職務経歴書では、担当した工程を明確に書いてください。要件定義に関わったのか、実装だけか、テストはどこまでか。ここが曖昧だと、書類の段階で判断できずに落ちます。職務経歴書の書き方に、実績を数値化する方法をまとめています。
数値化しにくい職種に見えますが、使える数字はあります。担当したシステムの利用者数、処理速度の改善幅、障害件数の推移、レビューした件数。どれかは拾えるはずです。
年収は「担当できる範囲」で決まる
言語の種類より、どこまで見られるかで変わる傾向があります。
要件定義から関われるか。インフラや運用まで見られるか。チームを率いた経験があるか。人に説明できるか。
提示された年収は、必ず内訳で確認してください。基本給、賞与（何か月分で業績連動か固定か）、固定残業代（何時間分か）。ここを見ずに総額だけで判断すると、月々の手取りが増えていないことがあります。
エージェントを使うなら、担当者の理解度を測る
エンジニア領域では、担当者がコードや開発プロセスの話をどこまで理解できるかが、そのまま提案精度に出ます。
面談の最初に「この領域はどれくらい担当されていますか」と聞いてください。そして紹介された求人について「なぜこの求人を私に？」と聞く。経歴のどこが要件に対応しているかを具体的に説明できるなら、企業側のことも理解しています。
特化型と総合型の使い分けでも触れましたが、IT領域は特化型の情報量が効く分野です。ただし特化型は「その領域に行かない」という結論を出しにくいので、方向を迷っているなら総合型も併用してください。
相場を知らないと、提示額の評価ができない
自分の経歴でいくらが妥当なのか。これは求人票を眺めても分かりません。同じ経歴の人がどこに決まっているかを知っている相手に聞くのが早い。
面談は無料で、応募の義務もありません。質問リストを開いたまま1本受けるだけで、自分の市場価値の輪郭がつかめます。
在職中なら、時間の作り方から
エンジニアは業務が読みにくい職種でもあります。日程調整の現実的な組み方は在職中の転職活動の進め方にまとめました。オンライン面接を軸にすれば、半休の回数をかなり減らせます。
求人票で分かるのは言語名まで。その先は聞かないと分かりません。上の5つを持って面談に行けば、入社後の落差はかなり減らせます。
