転職ノウハウ

エンジニアが転職活動を3回経験してわかった、2026年の正しい進め方

転職活動を3回経験したシニアエンジニアが、2026年のAI選考・エージェント活用・技術面接対策を実体験ベースで解説。失敗談も含めた現場目線の転職ノウハウ。

転職キャリアエンジニア転職2026年

先日、後輩エンジニアから「転職活動どう進めたらいいですか？」って相談を受けた。話を聞いていると、就活サイトに登録してエージェントに丸投げ、みたいなフローで動こうとしていて、「あー、2年前の自分もそれで3ヶ月無駄にしたな」って思い出した。

僕は今の会社に来るまでに計3回転職している。1回目は新卒5年目、2回目は30代前半、そして直近が2024年末。毎回やり方が変わっていて、特に今は生成AIの台頭でスクリーニングの仕組みが根本から変わった。2026年6月時点で「これをやっておけばよかった」「これで本当に通過率が上がった」という話を、実体験ベースで書いていく。

2026年のエンジニア転職市場、現実を直視する

正直、2024〜2025年あたりの「エンジニア売り手市場」と言われていた頃と比べると、今は少し変わってきている感じがする。特に感じたのはスクリーニングの高度化だ。

書類選考の段階で、AIによる一次評価が入っている企業がかなり増えた。求人票に書いてないことが多いけど、実際に面接官に聞いたら「まずAIでGitHubのコードと職務経歴書の整合性を見ています」と言われたことがある。つまり、GitHubに書いてあることと職務経歴書に書いてあることが食い違ってると、そこで落とされる可能性がある。

flowchart TD
    A[転職活動開始] --> B[自己分析・市場調査]
    B --> C{書類作成}
    C --> D[履歴書・職務経歴書]
    C --> E[GitHub整備]
    C --> F[ポートフォリオ]
    D --> G[AI一次スクリーニング]
    E --> G
    F --> G
    G --> H{通過?}
    H -- Yes --> I[技術面接フェーズ]
    H -- No --> J[フィードバック取得・修正]
    J --> C
    I --> K[コーディングテスト]
    I --> L[システム設計面接]
    K --> M[最終面接]
    L --> M
    M --> N[オファー交渉]
    N --> O[入社]

市場全体を見ると、こんな感じの動向がある。

領域2024年2026年変化
AI/MLエンジニア求人基準値+65%大幅増
フロントエンド求人基準値-15%やや減少
バックエンド求人基準値+10%微増
SRE/インフラ求人基準値+30%増加
平均年収（経験5年以上）720万円810万円+12.5%

※複数の求人プラットフォームの公開データを元に概算

SREやAI関連は需要が爆発的に伸びてる一方、純粋なフロントエンドは厳しくなってきている。この二極化、個人的にはもう少し早く気づいておきたかったやつだ。IT技術者の市場価値を高める戦略を考える上でも、このトレンドは意識しておく価値がある。

xychart-beta
    title "技術スタック別 求人倍率（2026年6月時点）"
    x-axis ["AI/ML", "SRE", "バックエンド", "モバイル", "フロントエンド"]
    y-axis "求人倍率" 0 --> 8
    bar [7.2, 5.8, 4.1, 3.6, 2.4]

活動開始前にやるべき「仕込み」3ヶ月分

転職活動って、応募し始めてからが本番だと思いがちなんだけど、実際は応募前の3ヶ月が全てを決めると今なら断言できる。2回目の転職のとき、準備なしでいきなり応募し始めて書類通過率が15%くらいだった。3回目は仕込みに2ヶ月かけて、通過率が52%まで上がった。この差はデカかった。

GitHub・ポートフォリオを「採用担当目線」で整備する

採用担当がGitHubを見るとき、実はコードの品質よりも継続性とコミット頻度を最初に見ているらしい。ある採用担当に直接聞いたら「直近6ヶ月のアクティビティが空白だと、エンジニアとしての熱量がないと判断してしまう」と言っていた。地味に怖い話だ。

具体的にやったこと:

# まず現状把握
git log --oneline --since="6 months ago" --author="your@email.com" | wc -l

# contributionグラフを公開設定にする
# Settings > Public profile > Contributions settings
# "Make contributions private" をオフに

# READMEを整備する
cat README.md | head -20
# プロジェクト概要、使用技術、セットアップ方法が1分でわかるか確認

ポートフォリオとして機能するリポジトリは1〜2個で十分、ただし質を上げることが大事。OSSへの貢献実績があるなら、それもアピールになる。OSS貢献の始め方については別記事にまとめたので、全くやったことない方はそちらも参考にしてほしい。

職務経歴書は「課題解決の物語」として書く

3回目の転職で転職エージェントにフィードバックをもらったとき、最初の職務経歴書について「何をしたかは書いてあるけど、なぜそれが必要で、どんな成果が出たかが全部抜けてる」と言われた。これは地味に刺さった。

ビフォー（ダメな書き方）:

・Kubernetes クラスターの運用・保守
・CI/CDパイプラインの構築
・性能改善の実施

アフター（伝わる書き方）:

・100+マイクロサービスのKubernetesクラスター運用（チーム5名のリード）
  → デプロイ頻度を週1回から日10回に改善、DORA metricsで測定
・GitHub Actions + ArgoCD によるGitOps CI/CDパイプライン構築
  → 本番障害発生時のロールバック時間を45分→3分に短縮
・JVM/GCチューニングによる決済APIの性能改善
  → P99レイテンシを800ms→120msに削減、サーバーコスト30%削減

数字で語れるかどうかが、エンジニアとしての職務経歴書の質を決める。正直これ、最初から意識してなかったから過去の実績を掘り起こすのに1週間かかった。業務日報やSlackのログを遡る作業が地味にきつかったし、「あのときちゃんとメモしておけばよかった」と何度思ったか。

エージェント・媒体選びで消耗しない方法

転職エージェントって、正直使い方を間違えると時間を大量に浪費する。僕が3回の転職で使ってみた媒体の印象をまとめる。

媒体強み弱み向いている人
ビズリーチ年収600万超の高単価案件が多いスカウトが多すぎて選別が大変経験5年以上の即戦力層
LinkedIn外資系・グローバル企業日本企業の求人が少ない外資転職希望者
FindyGitHub連携で技術力を可視化規模が小さい技術力で勝負したいエンジニア
Greenベンチャー・スタートアップ多め年収水準が低めの案件もスタートアップ志向
転職エージェント（doda等）担当者のサポートが手厚い担当者の質にばらつき転職活動初心者

最初の転職のとき、エージェント任せにしすぎて「希望と全然違う企業を紹介された」「連絡がなくなった」みたいな経験をした。今思うと、エージェントはパートナーではなく、あくまで求人紹介サービスとして使うのが正解だ。担当者に「こういうスキルセットがあって、こういう環境に行きたい」というのを最初に明確に伝えないと、向こうも的外れな求人を紹介し続けるだけになる。

FindyはGitHubのスコアが可視化されるのが面白くて、自分がどのレベルにいるか客観的にわかる。3回目の転職ではここで年収交渉の根拠にもなった。

xychart-beta
    title "転職媒体別 書類通過率（自分の経験ベース・N=小さいので参考程度に）"
    x-axis ["ビズリーチ", "Findy", "LinkedIn", "Green", "エージェント経由"]
    y-axis "書類通過率(%)" 0 --> 70
    bar [52, 61, 38, 44, 47]

これは完全に自分の経験ベースなので、スキルセットや職種によって全然変わる。参考程度に。

技術面接の2026年最新パターンと対策

技術面接は2年前と比べてかなり様変わりしてる印象がある。特に変わったのがコーディングテストとシステム設計面接だ。

コーディングテスト、LeetCodeだけじゃ足りない時代

去年転職した同僚が言っていたんだけど、最近は「AIを使っていいですよ」というスタイルの企業が増えてきているらしい。ただしその場合、なぜそのコードを書いたか説明できることが重要視される。AIに丸投げして出てきたコードを自分で説明できない、みたいなケースで落ちている人が出ているとか。個人的にはこれ、むしろ健全な変化だと思っている。

実際に受けた技術面接の流れ:

# こんな問題が出た（実際に解いたコード）
from typing import Optional
from collections import defaultdict

def find_duplicate_transactions(
    transactions: list[dict],
    time_window_seconds: int = 60
) -> list[tuple]:
    """
    同一ユーザーの重複決済を検出する
    実務に近い問題として出されたやつ
    """
    # ユーザーごとにトランザクションをグループ化
    user_txns = defaultdict(list)
    for txn in transactions:
        user_txns[txn['user_id']].append(txn)
    
    duplicates = []
    for user_id, txns in user_txns.items():
        # タイムスタンプでソート
        txns.sort(key=lambda x: x['timestamp'])
        
        for i in range(len(txns)):
            for j in range(i + 1, len(txns)):
                time_diff = txns[j]['timestamp'] - txns[i]['timestamp']
                if time_diff > time_window_seconds:
                    break
                # 同額・同時間窓内は重複とみなす
                if txns[i]['amount'] == txns[j]['amount']:
                    duplicates.append((txns[i]['id'], txns[j]['id']))
    
    return duplicates

# テストケース
transactions = [
    {'id': 'tx1', 'user_id': 'u1', 'amount': 1000, 'timestamp': 1000},
    {'id': 'tx2', 'user_id': 'u1', 'amount': 1000, 'timestamp': 1045},  # 重複
    {'id': 'tx3', 'user_id': 'u1', 'amount': 1000, 'timestamp': 1080},  # 重複
    {'id': 'tx4', 'user_id': 'u2', 'amount': 500, 'timestamp': 1000},
]

result = find_duplicate_transactions(transactions, time_window_seconds=60)
print(result)  # [('tx1', 'tx2'), ('tx1', 'tx3'), ('tx2', 'tx3')]

「実務に近い問題」が増えているのは間違いない。アルゴリズムの教科書問題より、「実際のシステムで起きそうなことをどう実装するか」を見たい、という意図なんだろうと思う。LeetCode一辺倒の練習だと本番でちょっと面食らうかもしれない。

システム設計面接はトレードオフを語れるかどうか

システム設計面接で最も大事なのは「正解を出すこと」よりトレードオフを言語化できることだと感じた。例えば「短縮URLサービスを設計してください」という問題なら:

flowchart LR
    subgraph Client
        A[ブラウザ / API クライアント]
    end
    subgraph Application
        B[API Gateway]
        C[URL短縮サービス]
        D[リダイレクトサービス]
    end
    subgraph Storage
        E[(Redis キャッシュ)]
        F[(PostgreSQL)]
    end
    A --> B
    B --> C
    B --> D
    C --> F
    D --> E
    E -- キャッシュミス --> F

これを書いた上で「Redisキャッシュを入れると読み取り性能は上がるが、更新頻度が高い場合はキャッシュ無効化の複雑さが増す。今回のシステムはリダイレクト頻度が書き込みの100倍以上想定なので、読み取りキャッシュを優先した」みたいな説明ができると、面接官の反応が全然違う。

面接官が見ているのは、あなたがそのシステムを本番で運用した経験があるかどうかなんですよね。ここはSREやDevOps的な知識も絡んでくるので、業務で触れてないとなかなか厚みが出ない部分でもある。

採用側からのぶっちゃけ話

僕自身、今の会社で採用面接に入ることがあって、面接官側の経験もある。採用側が本当に見ているポイントについては別記事にまとめているけど、正直なことを言うと、技術力が高くても、なぜこの会社を選んだのかが薄い人は通過させにくい。「年収が高いから」「技術スタックが面白そうだから」は別に悪くないんだけど、それだけだと同じくらいの技術力の候補者との差別化ができない。これは面接官をやって初めて実感したことだ。

年収交渉と内定後のリアル

転職活動の最後の山場が年収交渉。ここで遠慮して損をするエンジニアをたくさん見てきた。

交渉する前に「相場」を数字で握る

xychart-beta
    title "職種・経験年数別 年収中央値（2026年）"
    x-axis ["3年", "5年", "7年", "10年", "15年以上"]
    y-axis "年収（万円）" 400 --> 1400
    bar [520, 680, 820, 1020, 1250]
    line [480, 640, 790, 980, 1180]

※棒グラフ=バックエンド/インフラ系、折れ線=フロントエンド系の概算。複数媒体・転職サービスの公開データから推計。

相場感を掴んだ上で、交渉の際に使ったフレーズをそのまま書くと:

「現職での年収は○○万円です。今回の転職では
 同等以上を希望していますが、貴社でのポジション・
 裁量範囲を考えると、○○万円〜○○万円のレンジで
 ご検討いただけると嬉しいです。
 もちろん、入社後に価値を証明した上で改めて相談できれば」

最初から希望額を言わずにいると、企業側の言い値でほぼ決まってしまう。これは本当にもったいない。3回目の転職では、最初のオファーから100万円上積みしてもらえた。交渉は勇気がいるけど、やって損はない。

複数社から内定をもらうと交渉の立場が強くなるので、できれば3〜5社並行して進めるのが理想。ただし正直、「並行しすぎると一社あたりの準備が薄くなって面接で落ちる」というリスクもあって、まだ自分の中で最適解は見えていない。自分の処理能力と相談してほしい。

入社前に確認すべき技術環境チェックリスト

内定後に後悔しないために、必ず確認していること:

## 技術スタック確認
- [ ] 本番環境の主要言語・フレームワーク
- [ ] インフラ構成（クラウド比率、オンプレ有無）
- [ ] CI/CDの現状（回ってる？手動デプロイが残ってる？）
- [ ] テストカバレッジの現状（正直に教えてもらう）

## チーム・文化確認  
- [ ] コードレビューのプロセス
- [ ] 1on1の頻度・文化
- [ ] 技術的負債の現状と改善への意欲
- [ ] リモート/出社の実態（求人票と違うことが多い）

## 個人成長環境
- [ ] 学習支援制度（書籍購入、資格取得補助）
- [ ] 社外登壇・OSS貢献への姿勢
- [ ] テックブログの有無と更新頻度

これ、面接のときに全部確認しようとすると重い雰囲気になるので、カジュアル面談や最終面談で「実際のチームの話を聞かせてください」という流れで自然に聞いていくのがコツだ。

ITエンジニア向けのサブスク学習サービスを入社前に活用して、新環境で使う技術スタックをキャッチアップしておくのもおすすめ。入社してから「知らなかった」で遅れをとるのは避けたい。

まとめ

3回の転職経験と、採用側に入った経験を踏まえて、2026年の転職活動で本当に大事だと思うことを整理する。

要点3つ:

  1. 書類作成の前に3ヶ月の仕込みを：GitHubのアクティビティ整備、職務経歴書の数値化、ポートフォリオの品質向上。これを怠ると書類通過率が半分以下になる体感がある

  2. 技術面接はトレードオフを語る練習を：コーディングより「なぜそう設計したか」を言語化できる練習が今は重要。AIが普及した分、自分の思考プロセスを言語化できることの価値が上がっている

  3. 年収交渉は必ずやる：遠慮する必要はない。相場データを持った上で、最初のオファーに対して一度は交渉するだけで結果が変わる可能性がある

次のアクション:

転職を半年以内に考えているなら、今すぐGitHubのアクティビティを確認して、過去3ヶ月の草が生えてない日を埋める計画を立ててみてほしい。職務経歴書は業務日報やSlackのログを漁って、数字で語れる実績を3つだけでも掘り起こすだけで質が変わる。

転職は「決断してから3ヶ月で完結させる」というイメージの人が多いけど、本当は6〜9ヶ月のプロジェクトだと思って動いた方がうまくいく。みなさんはどう進めてますか？特に書類通過率を上げた工夫があれば、コメントで教えてほしい。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

転職ノウハウ

採用側が見てる職務経歴書の落とし穴｜100件面接して気づいたこと

転職ノウハウ

転職エージェント7社を3度の転職で試した結果、地獄を避ける選び方がわかった

転職ノウハウ

エンジニア転職2026年完全ガイド｜AI時代の成功戦略とスキル選定

転職ノウハウ

職務経歴書で落ちるのは経歴じゃなく「これ」が見えてないから

転職ノウハウ

未経験からIT転職して3年半、当時知りたかった「本当のこと」を書く【2026年】

転職ノウハウ

退職手続きで失業保険が1ヶ月遅れた話。実体験から見えた落とし穴

← 記事一覧に戻る