「マネジメントの実績はよく分かりました。それで、直近1年でご自身が書いたコードを見せていただけますか」——二次面接でCTOにそう聞かれた瞬間、画面共有していたGitHubのコミット履歴が2年近く前で途切れていることに、相談者本人が一番驚いていました。
私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、エンジニアリングマネージャー(EM)を一定期間経験した後にIC(個人として実装で価値を出すポジション)へ戻ろうとする相談は、ここ数年で明らかに増えています。今回は、EM経験者がIC復帰の面接で直面する懸念の正体と、マネジメント期間の技術判断を実装力の証明として語り直す具体的な言い換え方を、実際にあった相談事例を交えてお伝えします。
今回は、次の内容に沿ってご紹介します。
- EMからICへの現場復帰で、なぜ転職の面接のハードルが上がるのか
- 面接官がEM経験者に抱く3つの懸念と、それぞれの正体
- マネジメント期間の技術判断(設計レビュー・技術選定・障害対応・負債解消の意思決定)を実装力の言葉に翻訳するBefore/After
- EMからのブランクは何年まで許容されるか、埋め方の具体策
- IC転向で年収が下がりやすい構造と、その対応
目次
- エンジニアリングマネージャーからICへの現場復帰、転職面接で何を聞かれるか
- EMとIC、肩書きではなく役割の違いを面接官はどう見ているか
- 面接官がEM経験者に抱く3つの懸念、その正体
- Rさんが突きつけられた「直近1年で書いたコードを見せてください」
- マネジメント期間の技術判断を実装力の証明に翻訳する、Before/After
- コーディングテスト・技術面接でブランクを指摘されたときの対処
- EMからのブランクは何年まで許容されるか、埋め方の具体策
- IC転向で年収は下がるのか、構造とその対応
- 職務経歴書でマネジメント経験を実装力として書く
- 社内のIC・スペシャリストコースへの転換打診という選択肢
- よくある疑問に答えます
- まとめ、IC復帰の面接で見られているのは翻訳できるかどうか
エンジニアリングマネージャーからICへの現場復帰、転職面接で何を聞かれるか
先に対象読者を絞っておきます。この記事は、現職でマネジメント打診を受けてまだ引き受けていない、あるいは打診自体を辞退したエンジニアではなく、実際にEMとして一定期間チームを率い、そこからICへ戻ろうとしている人を想定しています。打診を辞退する段階の悩みについては、マネジメント打診を断ったエンジニアの面接での語り方で面接官が抱く誤解の切り返し方をまとめているので、状況が近い方はそちらを先に読んでみてください。
打診を辞退した人と、実際にEMを経験してICへ戻る人とでは、面接官が抱く懸念の重さがまるで違います。前者にはハンズオンのブランクがありませんが、後者には実際に何年か実装から離れた期間があり、面接官はそれを具体的な数字と実演で確かめようとしてきます。「向いていないと思った」で通る場面はほとんどなく、コーディングテストや技術面接で実力そのものを試されるのが、この記事で扱う状況の特徴です。
「エンジニアリングマネージャー 技術職 戻る」と調べてこの記事にたどり着いた方の多くは、社内にIC相当のポストが用意されていない、あるいは制度はあっても運用実績が薄いという事情を抱えています。IC(インディビジュアルコントリビューター)という言葉自体、日本語の求人票にはまだ十分に定着しておらず、面接官によって理解の深さにばらつきがある点も、あらかじめ知っておいた方がよいでしょう。
EMとIC、肩書きではなく役割の違いを面接官はどう見ているか
EMは、チームの人員配置・評価・採用・進捗管理といった意思決定を担う役割です。ICは、部下を持たず自分自身の設計・実装によってプロダクトに貢献する役割を指します。どちらも役職名ではなく、日々の時間を何に使っているかという役割の違いにすぎません。
問題は、一度EMという肩書きを名乗ると、市場からの見え方がそこに固定されやすいことです。スカウトを送る側のシステムは直近の職務タイトルに強く反応するため、EM在籍中の経歴のままでいると、届くのはマネジメント職の求人ばかりという状態になりがちです。待っているだけでは、ICの求人には自然には届きません。自分から経歴の見せ方を作り直す必要があるという点は、最初に押さえておいてほしいところです。
面接官の側にも、同じ構造に由来する先入観があります。「一度マネジメントに上がった人は、いずれまた管理職に戻りたがるのでは」という見方は、EMからのIC応募に対してほぼ必ず持たれる前提だと思っておいた方がいいでしょう。これを覆すには、後述するように定着への懸念を先回りして解いておく必要があります。
実際にスカウトの文面を見比べると、この固定化はよく分かります。EM在籍中に届くスカウトの多くは「マネジメント経験を活かして」という書き出しで始まり、ICの求人からのスカウトはほとんど混ざりません。転職サイトのプロフィールを更新しない限り、応募先の候補自体が管理職に偏ったまま動かなくなってしまいます。
面接官がEM経験者に抱く3つの懸念、その正体
EM経験者がIC求人に応募したとき、面接官の頭の中には、おおむね次の3つの懸念が浮かびます。順番に見ていきます。
面接官が抱きやすい3つの懸念です。
- 実装力の摩耗懸念、マネジメント期間で技術のキャッチアップが止まっているのでは
- 定着懸念、数年後にはまたマネジメントの空きを狙うのでは
- 立ち位置懸念、レビューを受ける側に戻れず元マネージャーの感覚を引きずるのでは
一つ目の懸念が最も具体的で、面接の場でも真っ先に検証されます。コーディングテストや実装の詳細を問う質問がここに当たり、記憶頼みの説明や古いバージョンの構文が出てくると、面接官はその場で「やはり離れていたか」と確信を強めます。
二つ目の懸念は、面接の言葉づかいそのものに表れやすいものです。「マネジメントは向いていなかったので」という説明だけで終わると、面接官には「向いていないからやめた人」に見え、業務が忙しくなればまた管理側に押し戻されるのではという不安につながります。実際には向き不向きの話ではなく、どちらの役割で自分の価値を最大化できるかという判断であることを、具体的な経緯とともに伝える必要があります。
三つ目の懸念は見落とされがちですが、現場のエンジニア面接官が特に気にするポイントです。元マネージャーがチームに合流すると、指示する側の癖が抜けず、レビューを素直に受け入れられないのではないかという警戒です。この懸念は、実際のエピソードで解くのが一番効果的なので、後ほどの言い換え例で扱います。
3つの懸念は独立しているようで、実際の面接では一問一答の中で同時に確認されることが多いです。「なぜマネジメントを離れたいのか」という質問一つに、適性・定着・立ち位置の3つの答えを同時に含める意識で回答を組み立てておくと、面接官の頭の中にある懸念を一度にほぐせます。
Rさんが突きつけられた「直近1年で書いたコードを見せてください」
実際にあった相談を紹介します。Rさんは41歳、決済系のBtoB SaaSを開発する自社開発企業に在籍し、2年半ほどEMとしてバックエンドチーム7人をまとめていました。もともとは実装が好きでエンジニアになった人で、マネジメントは会社の要請で引き受けた経緯があります。
チームの成果自体は悪くなく、リリース頻度も改善していました。ただRさん自身は、コードレビューと1on1と採用面接に埋め尽くされた日々の中で、自分の手を動かす時間がほぼゼロになっていることに焦りを感じ、IC復帰を決意して転職活動を始めました。
Rさんが最初に相談してきたときの言葉が印象に残っています。「マネジメントの仕事が嫌いなわけじゃない。ただ、このままだと自分が何のエンジニアだったか、説明できなくなる気がする」。管理業務そのものへの不満ではなく、実装者としての自分を保てなくなる焦りが、転職を決めた本当の動機でした。
一次面接(現場エンジニア)は、マネジメント経験の話が中心で好感触のまま終わりました。ところが二次面接に同席したCTOから、冒頭の「直近1年で書いたコードを見せてください」という質問が飛んできます。Rさんは画面共有でGitHubを開きましたが、目立つコミットは2年近く前のもので止まっており、その場でうまく言葉が続きませんでした。
結果は見送りでした。フィードバックとして戻ってきたのは、「マネジメント能力は申し分ないが、実装力については現時点で判断材料が乏しい」という一文です。Rさんが私に相談してきたのは、この見送り連絡を受け取った直後でした。
マネジメント期間の技術判断を実装力の証明に翻訳する、Before/After
Rさんと最初に取り組んだのは、コードを書く時間を捻出することではなく、すでに持っている経験の説明の仕方を変えることでした。EM期間中にもRさんは、設計レビューの最終判断者として動いていたり、障害対応時に原因を技術的に切り分けていたりと、実装そのものではないものの、実装力と地続きの判断を日常的に下していたからです。
面接で評価されにくいのは、これらの経験を「承認しました」「調整しました」というマネジメント言葉のまま話してしまうことです。同じ経験でも、判断の根拠や具体的な選択肢の比較まで踏み込んで話すと、実装力の証明として十分に機能します。整理すると、次のような対応関係になります。
| 面接官の懸念 | Before(マネジメントの言葉のまま) | After(実装力の言葉に翻訳) |
|---|---|---|
| 設計判断ができるか | 「チームの設計レビューは最終的に私が承認していました」 | 「決済フローの冪等性を守れるかを基準に、非同期化の提案を一度差し戻し、リトライ時の重複処理を潰す設計に直させました」 |
| 技術選定の妥当性 | 「新しいライブラリの導入は私が決裁していました」 | 「移行コストとチームの学習コストを比較し、既存資産をラップする形で段階導入する方針に絞り込みました」 |
| 障害対応での技術力 | 「障害発生時は私が指揮を取っていました」 | 「ログとメトリクスから決済APIのタイムアウトが原因と切り分け、影響範囲をDB接続プールの上限値まで特定しました」 |
| 負債解消の判断力 | 「技術的負債の解消は私が優先順位を決めていました」 | 「新機能開発を1スプリント止めてでも解消すべき負債を、障害発生頻度と修正コストの掛け算で選び、実際に着手する範囲を線引きしました」 |
表を見て分かるとおり、Afterの説明にはどれも判断の根拠になった具体的な基準が入っています。マネジメントの立場でも、技術的な事実に基づいて意思決定をしていたのなら、その基準こそが実装力の証明になります。
Rさんの場合、特に効いたのは障害対応の切り分けの話でした。指揮を取っていたという説明を、ログとメトリクスをどう読んでどこまで原因を絞り込んだかという説明に変えたところ、二社目の技術面接では「実際に手を動かしていなくても、原因究明の解像度は高い」という評価コメントが返ってきています。
似た構図の翻訳作業は、職種が違っても本質は同じです。研究出身のMLエンジニアが実装力を証明できず落ちる理由でも、研究経験を実装力の言葉に翻訳できるかどうかが評価の分かれ目になっていました。経験の中身は違っても、「経験を、相手が評価できる言葉に置き換える」という作業自体は、キャリアチェンジ全般に共通する型だと私は考えています。
コーディングテスト・技術面接でブランクを指摘されたときの対処
言葉の翻訳だけでは埋まらない部分もあります。コーディングテストは実演の場なので、構文を思い出せずに手が止まる場面はどうしても出てきます。ここで取り繕おうとすると、かえって印象を悪くします。
Rさんには、コーディングテストの前に3週間、業務で使っていた言語のリファレンス実装を毎日1〜2時間書き直す習慣を作ってもらいました。目的は完璧に仕上げることではなく、言語のクセを指が覚えている状態を取り戻すことです。実際のテストでは軽微な構文ミスが出ましたが、その場で気づいて自分で直す様子を見せられたことが、かえって評価につながりました。
技術面接で分からない実装の詳細を聞かれた場合も、知ったかぶりで乗り切るより、正直に「その部分は最新の実装を追えていません。ただ、こういう考え方で調べれば答えにたどり着けます」と、調べ方や検証の手順まで話す方が印象は良くなります。面接官が見ているのは、その場の記憶量よりも、分からないことに直面したときの立ち回り方だからです。
コーディングテストで落ちるパターンそのものは、EM経験者に限った話ではありません。技術面接・コーディングテストで落ちる人に共通する準備不足でも触れているとおり、完璧主義に陥って時間切れになるパターンはよく見られ、ブランクのある人ほど手順の確認に時間を使いすぎて同じ失敗をしがちです。事前に本番と同じ制限時間で練習しておくだけでも、失点はかなり減らせます。
EMからのブランクは何年まで許容されるか、埋め方の具体策
相談でよく聞かれるのが、実装から離れた期間がどこまでなら許容されるかという質問です。私が現場で見てきた感覚では、1年以内であればほとんど話題にすら上りません。1〜3年になると、面接官は準備の質を見て判断する段階に入り、3年を超えると、個人開発やOSS活動など、EM在籍中も何らかの形で実装に触れていた証跡がないと厳しく見られやすくなります。
ブランクを埋める手段として効果が高い順にまとめます。
- 個人開発で動くものを1つ完成させ、READMEに設計判断の理由まで書く
- OSSへの小さな貢献(バグ修正・ドキュメント改善)を継続する
- EM在籍中に自分でコードレビューをどこまで深く読んでいたかを、具体的な指摘内容とともに話せるようにしておく
- 技術ブログや社内勉強会での発信を、実務貢献の一部として職務経歴書に載せる
資格取得だけでブランクを埋めようとする人もいますが、面接官が知りたいのは知識の有無ではなく、動くものを作れるかどうかです。資格は補強材料にはなっても、それだけで実装力の証明にはなりません。個人開発かOSSか、どちらか一方でもいいので、実際に手を動かした痕跡を残しておくことをおすすめします。
会社の規模によって、この許容ラインの厳しさも変わります。数十人規模のスタートアップほど、入社してすぐ実装力が必要になるため厳しく見られやすく、逆にエンジニアリング組織が数百人規模の企業では、オンボーディング期間を長めに取れる分、ブランクへの許容度がやや高い傾向があります。応募先の組織規模に応じて、準備にかける熱量の配分を変えるとよいでしょう。
IC転向で年収は下がるのか、構造とその対応
IC復帰でもう一つ避けて通れないのが年収の話です。JAC Recruitmentの市場動向によると、EMの年収相場は一般に700万〜1,500万円、同社の取扱求人では900万〜1,200万円で、年代別では30代平均1,050万円、40代平均1,200万円という水準が示されています(出典:JAC Recruitment「エンジニアリングマネージャー(EM)への転職は未経験でも可能?」)。同社の記事でも、管理業務より技術への情熱を優先してIC転向するケースがあると触れられており、この動き自体は市場でも珍しくなくなっています。
ただし、EM時代のオファー水準がそのままIC求人にも通用するとは限りません。多くの企業ではマネジメント層の給与テーブルの方が上限が高く設定されており、同じ会社の中でもICの等級上限がEMの下限に届かない設計になっていることがあります。Rさんが最初に受けた企業のオファー面談でも、提示額は現年収680万円より40万円低い640万円でした。
この構造への対応は、IC向けの給与テーブルが独立して用意されている企業を選ぶことに尽きます。IC・EM・アーキテクトの3パスで年収曲線がどう分かれるかは、35歳エンジニア限界説は本当か、IC・EM・アーキテクトで分かれる40代の年収曲線で年代別のデータとあわせて詳しく比較しているので、応募先を絞り込む際の参考にしてください。Rさんは2社目でIC・スペシャリスト職掌が明記された企業に絞って応募し、最終的に706万円(現年収比+26万円)のオファーを獲得しています。
面接での交渉材料としては、1社目で提示された640万円という具体的な数字を隠さずに使うのも有効です。Rさんは2社目のオファー面談で「前職の管理職手当を含む年収は680万円だったが、実装専任のポジションとして評価してほしい」と率直に伝え、単純な現年収比較ではなく役割の変化を前提にした交渉に持ち込んでいます。
職務経歴書でマネジメント経験を実装力として書く
面接前の書類選考の段階でも、同じ翻訳作業が必要です。「バックエンドチーム7人のマネジメント」とだけ書かれた職務経歴書は、書類を見た採用担当者にICとしての実装力を疑わせるだけで終わります。
職務経歴書に書き加えたい要素です。
- チーム規模と担当プロダクトの技術スタック(何を作っている組織を率いていたか)
- 自分が最終判断者だった技術的意思決定の具体例(設計レビュー・技術選定・障害対応)
- その判断がもたらした定量的な成果(パフォーマンス改善率・障害件数の減少など)
- EM在籍中も継続していた実装関与(コードレビューの深さ、緊急対応時の実装参加など)
数値化できる成果は、面接前の段階で採用担当者の懸念を先に和らげる効果があります。マネジメント経験を実績の記録として書くのではなく、技術的な判断の記録として書き直すだけで、書類選考の通過率は変わります。
Rさんの職務経歴書も、当初は「バックエンドチーム7人のマネジメント、採用・評価・進捗管理を担当」という一行で終わっていました。書き直した後は「決済APIの障害対応で技術的な原因切り分けを主導、DB接続プール上限の見直しにより月間障害件数を8件から2件に削減」という形で、判断内容と定量成果をセットにしています。書類選考の通過率は、この修正の前後で明らかに変わりました。
社内のIC・スペシャリストコースへの転換打診という選択肢
転職活動を始める前に、現職でIC・スペシャリストコースへの転換を打診する選択肢も検討しておく価値があります。この社内交渉の進め方や、打診を辞退する場面での面接での語り方については、マネジメント打診自体を断ったケースを扱った記事で詳しく触れています。
ただし、現職に明確なICパスが制度として存在しない場合、社内で転換を訴えても、等級テーブルそのものが変わらない限り評価は頭打ちになりがちです。Rさんの現職にもICパスはありましたが、等級上限がマネジメント職の7割程度で、技術的な難易度に見合う評価を受けにくい設計でした。この場合、社内交渉より社外への転職の方が現実的な選択になります。
よくある疑問に答えます
EMを1年未満で辞めてICに戻る場合、経歴として不利になりますか。 短期間であること自体は大きな問題になりません。ただし理由を聞かれる可能性は高いので、「試してみて、自分の強みがどちらにあるか分かった」という検討の経緯を、具体的なエピソードとともに話せるようにしておくとよいでしょう。
技術面接でどうしても答えられない実装の質問が来たら、その場でどう切り返せばいいですか。 分からないことを認めた上で、調べ方や検証の手順まで話すことをおすすめします。最新の実装詳細を追えていなくても、原因の当たりの付け方や検証の順序を示せれば、実務での判断力があることは伝わります。
ICで応募しているのに、面接官から「将来的にまたマネジメントを」と聞かれたらどう答えるべきですか。 可能性を完全に否定する必要はありません。「今はICとして技術的な貢献を最大化したい」という現時点での判断軸を明確にした上で、その判断に至った経緯(EM期間で見えた自分の強み)を具体的に添えると、場当たり的な回答に聞こえずに済みます。
スカウトがEM系の求人ばかり届く場合、どうすればICのスカウトが増えますか。 経歴書・転職サイトのプロフィールで、直近の職務タイトルより先に、担当していた技術領域と実装関与の具体例が目に入るように構成を変えることが効果的です。タイトルだけを見て自動的に送られるスカウトの傾向を、自分から崩しにいく必要があります。
同じ回答でも、面接官が現場エンジニアか役員かで話し方を変えた方がいいですか。 はい。現場エンジニアは技術的な判断の中身そのものに関心を持ちますが、役員クラスは組織や事業への影響を重視する傾向があります。現場エンジニア面接官と人事・役員面接官、評価軸が違う理由でも扱っていますが、同じEM経験を語る場合も、相手に応じて技術的な具体性と事業インパクトの比重を調整すると伝わりやすくなります。
まとめ、IC復帰の面接で見られているのは翻訳できるかどうか
EMからICへの現場復帰でつまずく人の多くは、技術力そのものが本当に落ちているわけではありません。マネジメント期間中に下してきた技術的な判断を、実装力の言葉に翻訳できていないだけのケースがほとんどです。
面接官が抱く懸念は、実装力の摩耗・定着・立ち位置という3つにほぼ集約されます。問われているのは経験の有無ではなく翻訳の有無です。設計レビュー・技術選定・障害対応・負債解消という4つの場面で自分が何を基準に判断したかを言語化できれば、ブランクは弱みではなく、判断力の証明に変わります。
Rさんのように、最初の面接で見送られたことは、決して実装力がないことの証明ではありません。マネジメントの言葉のまま話していただけで、翻訳の作業を一度やり直せば、評価は大きく変わります。EMを経験したこと自体を、IC復帰の障害ではなく、判断力を裏付ける材料として語り直せるかどうかが、この転職の分かれ目です。




