【2026年版】現役バックエンドエンジニアが書く SES脱出完全ガイド

SESを抜け出したい——そう思いながら、何から始めればわからず、気づけば同じ現場に3年いた。

これは過去の自分の話だ。Javaでバッチ処理を書き続け、Spring Bootのバージョンアップ対応を繰り返し、「自分には何のスキルがあるんだろう」と夜中に検索しては閉じる日々。

今は自社開発の会社に移り、年収は450万から750万になった。転職活動でやってよかったこと、やらなくてよかったことが明確になったので、この記事にすべて書く。

この記事の対象読者

• SES企業に在籍中のバックエンドエンジニア（経験2〜7年目）
• 転職を考えているが何から始めればいいかわからない
• GitHubがほぼ空で「ポートフォリオがない」と悩んでいる
• 面接で「自分が作ったものを語れない」問題を抱えている

逆に、経験10年以上でアーキテクト/マネージャー候補として転職する方は、この記事よりも専門のハイクラス転職支援を使った方がいい。

なぜバックエンドエンジニアはSESから抜け出しにくいのか

構造的な問題：スキルが「現場依存」になる

SESの最大の問題は、スキルが現場の文脈に閉じ込められることだ。

たとえばこういうことが起きる。

• 3年間、某金融系の基幹システムのJava保守をしてきた
• 現場独自の自社フレームワークと業務ルールは把握している
• しかし「何が作れますか？」と聞かれると言葉が出ない

転職市場で問われるのは「汎用的なスキル」だ。Spring Bootで認証付きREST APIを設計できる、Dockerでコンテナ化できる、DBのクエリを最適化できる——こういった「どの現場でも通じる技術力」が評価される。現場固有のノウハウは、転職市場ではほぼ評価されない。

単価構造がスキルアップを妨げる

SES企業のビジネスモデルは「エンジニアの稼働時間を売ること」だ。あなたが80万円/月の単価で客先に出ていても、会社が50万円取って手元に30万円しか残らない——というのはよくある話だ。

さらに問題なのは、高単価現場に行けるかどうかは運と営業力次第という点だ。本人のスキルアップ意欲とは無関係に、「手が空いている」「すぐ入れる」という理由でアサインされる。

転職市場の実態：2026年版データ

日本のIT人材は2025年時点で100万人超、そのうち70%以上がSES・客先常駐系の働き方をしているとされる。一方で、自社開発・自社サービス企業への需要は年々高まっており、優秀なバックエンドエンジニアは売り手市場が続いている。

年収の実態をざっくり示す。

自分の転職は450万→750万だったが、これはほぼ「業界標準」の範囲内だ。スキルと実績の見せ方次第でもう50〜100万は上乗せできたと、今は思っている。

STEP 1：転職を決意する前に「自分棚卸し」をする

転職エージェントに登録する前に、必ずこれをやってほしい。棚卸しなしでエージェントと話すと、「とりあえず求人を見せます」モードで流されてしまう。

スキルシートを自分で書く

以下のフォーマットで、自分のスキルを書き出す。

【言語・フレームワーク】
- Java 8/11/17（業務経験 5年）
- Spring Boot 2.x/3.x（業務経験 4年）
- Python（業務外・個人開発 1年）
- SQL（MySQL・PostgreSQL、業務経験 5年）

【インフラ・ミドルウェア】
- AWS（EC2, RDS, S3, Lambda）業務経験 2年
- Docker（業務経験 1年）
- Linux（CentOS/Ubuntu、業務経験 5年）

【開発手法・ツール】
- Git / GitHub
- Jenkins（CI/CD）
- Agile/Scrum（業務経験 1年）

ポイントは「業務経験年数」と「業務外の自習」を分けて書くこと。業務経験は採用担当に「本当に使える？」と検証されるが、個人学習はGitHubで補強できる。

語れるエピソードを3本用意する

面接で必ず聞かれる「あなたが技術的に貢献した経験を教えてください」に答えるエピソードを、事前に用意する。

SES出身者がよく失敗するのが「チームで〜しました」という語り方だ。採用側は「あなたが何をしたか」を知りたい。

フォーマットはSTAR法が使いやすい。

• Situation（状況）：どんなプロジェクトで、どんな問題があったか
• Task（役割）：自分は何を担当していたか
• Action（行動）：具体的に何をしたか
• Result（結果）：数字で語れる成果は何か

例：APIのレスポンスタイムを50%改善した話

S: ECサイトの商品検索APIが遅く、平均レスポンス2.3秒でユーザーの離脱が増えていた
T: バックエンドのパフォーマンス改善を1人で担当
A: ①EXPLAINでスロークエリを特定 → 複合インデックス追加
   ②N+1問題をJPQLのJOIN FETCHで解消
   ③頻繁にアクセスされる商品データをRedisにキャッシュ
R: レスポンスタイムが平均2.3秒→1.1秒（52%改善）、直帰率が8%改善

この粒度で語れれば、「バックエンドエンジニアとして何ができる人か」が明確に伝わる。

STEP 2：GitHubを「見せられる状態」にする

2026年現在、バックエンドエンジニアの転職においてGitHubは実質的に「第二の職務経歴書」だ。特にFindy・Green・スタートアップ系の採用担当は、書類よりGitHubを先に見るケースがある。

まずプロフィールを整える

最低限やること：

1. アイコン画像を設定する（デフォルトのアイコンは印象が薄い）
2. 自己紹介を書く（使える言語・興味領域・現在の状況）
3. README.mdをプロフィールに設置する（<username>/<username> リポジトリを作成）

プロフィールREADMEの例：

## Hi, I'm a Backend Engineer 👋
 
**Languages & Frameworks:** Java / Spring Boot / Go / Python / SQL
**Infrastructure:** AWS / Docker / PostgreSQL / Redis
**Interests:** Distributed Systems, API Design, DDD
 
Currently looking for backend roles in product companies.

「見せられるリポジトリ」を最低2本作る

業務コードは出せないが、個人で作ったプロジェクトを公開する。重要なのは「完成している」ことと「READMEがちゃんとある」こと。

バックエンドエンジニアのポートフォリオとして評価されやすいのは：

• REST APIサーバー（認証・CRUD・テスト付き）
• CLI ツール（実用的な問題を解決するもの）
• データ処理バッチ（CSVを読んで集計してDBに入れる、など）

フロントエンドがなくても全く問題ない。むしろ「バックエンドに特化している」という印象になってプラスだ。

良いREADMEの構成：

# プロジェクト名
 
一言でなにをするものか説明する。
 
## 技術スタック
- Java 21 / Spring Boot 3
- PostgreSQL 16
- Docker / Docker Compose
 
## セットアップ
docker-compose up -d で起動します。
 
## APIエンドポイント
| Method | Path | 説明 |
|---|---|---|
| POST | /api/auth/login | ログイン |
| GET | /api/users/{id} | ユーザー取得 |
 
## 設計のポイント
なぜこの設計にしたか（思想）を書く。これが面接での会話につながる。

コミット頻度を上げる

採用担当がGitHubで見るのは「コントリビューショングラフ（緑のマス）」だ。転職活動中は週に3〜5コミットを目標にする。これは「継続的に学習している」というシグナルになる。

STEP 3：使うべき転職サービスを選ぶ

転職エージェントと求人媒体は「複数使い分ける」のが鉄則だ。それぞれ強みが違う。

レバテックキャリア：ITエンジニア転職の軸にする

特徴

• ITエンジニア・デザイナー特化のエージェント
• 担当者がエンジニア職に詳しく、技術的な話が通じる
• 年収交渉を代行してもらえる（これが最大のメリット）
• 非公開求人が多い

こんな人に向いている

• しっかり年収を上げたい
• エージェントに相談しながら転職活動を進めたい
• 大手〜中堅の自社開発企業への転職を考えている

Findy：GitHubを整えたら登録する価値あり

特徴

• GitHubのアクティビティからスキルスコアを算出して企業とマッチング
• エンジニアに優しい企業（技術スタックが新しい・モダン開発）が多い
• スカウト型なので受け身で情報収集できる

注意点

• GitHubがほぼ空だとスコアが低くなり、良い企業からスカウトが来にくい
• まずGitHubを整備してから登録するのが正解

Green：スタートアップ・ベンチャー系はここ

特徴

• IT/Web業界のスタートアップ・ベンチャー企業が多い
• 「気になる」ボタンで企業側にシグナルを送れる（カジュアル面談に発展しやすい）
• エンジニアに直接メッセージを送ってくる採用担当が多い

こんな人に向いている

• フラットな組織文化のスタートアップに行きたい
• カジュアルに話を聞きながら転職先を探したい

doda：求人数が多いが精度は落ちる

特徴

• 求人数No.1クラス（20万件超）
• IT特化ではないため、担当者の技術理解度にばらつきがある
• サブ的な使い方（求人情報の情報収集）には使える

ユニゾンキャリア：IT特化・SES脱出の転職支援に強い

特徴

• IT/Web系エンジニア専門の転職エージェント
• キャリアアドバイザーがIT業界出身で、技術的な強み・弱みを正確に把握した上で求人を紹介
• SES・受託開発からの転職支援実績が豊富で、SES出身者の事情をよく理解している
• レバテックキャリアと並行して使うことで、紹介求人の選択肢を広げられる

こんな人に向いている

• SESからの転職でどのエージェントを選べばいいか迷っている
• 担当者に技術の話が通じるエージェントを使いたい
• レバテックキャリアと掛け持ちして求人の幅を広げたい

自分の場合、レバテックキャリアをメイン・Greenをサブで使って転職した。ユニゾンキャリアやFindyも組み合わせると、紹介される求人の幅が広がって比較検討しやすくなる。

STEP 4：職務経歴書で「自社開発企業に刺さる」書き方をする

職務経歴書は「読んで事実を確認する書類」ではなく、「面接で話したいことのアジェンダ」だと思うといい。採用担当が「ここ詳しく聞きたい」と思う部分を意図的に作る。

やってはいけないこと

NG例：

・○○銀行の基幹システム保守・開発に従事
・Javaを用いたバッチ処理の実装
・テスト設計・実施

これは「何をしたか」しか書いていない。SES出身者の職務経歴書あるある。

伝わる書き方

OK例：

【担当業務】ECサイトの受注・在庫管理システムのバックエンド開発

【技術環境】
Java 17 / Spring Boot 3 / MySQL 8 / Docker / AWS (EC2, RDS, S3)

【主な実績】
① 商品検索APIのパフォーマンス改善
  - スロークエリの分析（EXPLAIN）→複合インデックス追加
  - キャッシュ戦略をDBキャッシュ→Redisに変更
  - 結果：レスポンスタイム 2.3秒→1.1秒（52%改善）

② CI/CDパイプラインの構築
  - Jenkins → GitHub Actions への移行を主導
  - デプロイ所要時間：45分→12分に短縮
  - 自動テストカバレッジ：0%→68%に向上

数字・技術名・自分が担当した範囲——この3点セットを意識するだけで、読み手の印象がまったく変わる。

STEP 5：面接で「SES出身ならではの詰まり」を回避する

自社開発企業の面接でSES出身者がよく詰まるのは以下の3パターンだ。

パターン1：「何を作りましたか？」

SES出身者は「保守・運用」が長いと、新規開発の経験が薄いことが多い。正直に言いつつ、自分が判断・設計した部分を強調する。

「新規機能の設計・実装よりも保守・改善が中心でした。
ただ、○○の場面では自分でDB設計を見直し、△△という問題を解決しました。
個人開発でREST APIサーバーを作っており、設計思想は○○を意識しています」

保守経験は「既存コードを読む力」「品質への意識」として正の側面があるので、そこも言語化する。

パターン2：「なぜ弊社に応募しましたか？」

「SESを脱出したい」は正直だが、それだけでは刺さらない。相手企業のプロダクト・技術への興味を具体的に言う。

事前にやること：

1. 会社のテックブログを全部読む
2. 使っている技術スタックをJobポスティングから把握する
3. プロダクトを実際に使ってみる

「御社の技術ブログで、マイクロサービス分割の意思決定について書かれた記事を読みました。
現在の現場では一枚岩のモノリスで運用コストが問題になっています。
その設計判断のプロセスに興味があり、自分も経験したいと思い応募しました」

パターン3：「現在の職場の不満は？」

「SES構造が嫌だ」「給与が上がらない」は正直だが、採用担当は「うちでも不満を言う人かな」と思う。ポジティブな理由に言い換える。

NG：「SESで給与が上がらず、将来が不安なので転職したい」

OK：「自社プロダクトの成長にコミットしたい。
    現職では客先の要件に沿う開発が中心で、プロダクトの意思決定に
    関わる機会がほぼない。設計・アーキテクチャの議論に参加しながら
    成長できる環境に移りたい」

よく聞かれる技術質問への準備

バックエンドエンジニアの面接でよく出るテーマ：

設計・アーキテクチャ系

• RESTful APIの設計原則（べき等性、HTTPメソッドの使い分け）
• DBの正規化と非正規化のトレードオフ
• キャッシュ戦略（どこに何をキャッシュするか、TTLの考え方）
• マイクロサービス vs モノリスの判断基準

コード品質系

• テストの種類と使い分け（Unit / Integration / E2E）
• SOLID原則（特にSingle Responsibility・Open/Closed）
• 例外処理の設計（checked vs unchecked、どこで握り潰すべきでないか）

インフラ・運用系

• Dockerを使う理由・使い方
• N+1問題とその解決策
• インデックスの仕組みと使いどころ

これらを「自分の言葉で説明できる」状態にしておく。暗記ではなく、自分のプロジェクトでどう判断したかを語れると強い。

STEP 6：年収交渉で損をしない

転職時の年収交渉は、多くの人が「言いにくい」と感じて流してしまう。これが一番もったいない。

現年収を基準に交渉しない

SES企業の年収は市場価値より低いことが多い。「現年収450万なので500万で」ではなく、市場価値ベースで要求する。

やり方は簡単で、以下を事前に調べる。

1. 同じ技術スタック・経験年数の求人の想定年収レンジを確認する
2. レバテックキャリアなどのエージェントに「自分の市場価値」を直接聞く
3. オファーが複数ある場合は「他社から○○万のオファーがあります」と言う

エージェント経由は年収交渉しやすい

エージェントを使う大きなメリットの一つが、年収交渉の代行だ。自分で直接言いにくいことを、エージェントが代わりに企業側に伝えてくれる。

エージェントに伝えるべきこと：

• 現在の年収（正直に）
• 希望年収（少し高めに設定する）
• 年収以外の優先事項（フルリモート希望・技術的成長環境など）

STEP 7：転職活動のタイムライン

実際に動き始めてからオファーまでにかかる期間は、平均3〜4ヶ月だ。以下は現実的なスケジュール感。

Month 1：準備
  - スキル棚卸し・STAR法でエピソード整理
  - GitHubプロフィール整備・ポートフォリオリポジトリ作成
  - 転職エージェントへの登録・初回面談

Month 2：書類選考
  - 職務経歴書を書く・エージェントにレビューしてもらう
  - 10〜15社に書類を出す
  - カジュアル面談を3〜5件こなす（緊張しない練習）

Month 3：面接
  - 1次〜最終面接を進める
  - 技術面接対策（設計系の質問・コーディングテスト）
  - 週末もGitHubに何かコミットして活動を止めない

Month 4：交渉・入社
  - オファーを比較する
  - 年収・働き方・技術環境のトレードオフを整理する
  - 内定承諾・退職交渉・引き継ぎ

現職在籍中に転職活動するのが基本だ。SESの場合、退職の意思を伝えた後も現場への影響を考えて「あと3ヶ月いてほしい」と言われるケースがある。内定承諾後に退職交渉を始めることを前提に、余裕を持ったスケジュールを組む。

転職後に「よかった」と思ったこと

参考までに、転職してから実感した変化を書いておく。

技術的な変化

• コードレビューのレベルが上がった（SESより厳しく、最初はきつかったがすぐ慣れた）
• 設計の議論に参加できるようになった
• 自分が書いたコードがプロダクトに直結することの達成感

待遇面の変化

• 年収450万→750万（転職時）
• フルリモート勤務になった
• 副業が解禁になった（SESの現職は副業禁止だった）

キャリア面の変化

• 「○○社のエンジニア」という明確なアイデンティティができた
• Findy・Twitterのエンジニアコミュニティで繋がりが増えた
• 次の転職・独立を視野に入れた設計ができるようになった

SES脱出のよくある失敗パターン

最後に、相談を受けてきた中で見たよくある失敗をまとめる。

失敗1：「スキルが足りない」と思い込んで動かない

バックエンド経験3年以上あれば、転職市場に出る価値は十分ある。「まだ実力が足りない」と思いながら5年経っている人は多い。まず動いてみて、書類で落とされることで「何が足りないか」がわかる。

失敗2：SESの次もSESに入る

「自社開発」と書いてあっても実態はSES、という会社がある。見分けるチェックリスト：

• 「お客様先への常駐あり」「客先での作業あり」という記述がある
• 採用ページに具体的なプロダクト名がない
• 「エンジニアのご経験を活かす」など曖昧な表現ばかり
• Glassdoorや転職会議で「SES」「常駐」「派遣」という口コミが多い

必ず口コミサイトを確認し、面接で「社員は全員自社で働いていますか？」と直接聞く。

失敗3：エージェントの言いなりになる

エージェントも商売だ。あなたに早く転職してもらう方がインセンティブが発生する。「この求人はお勧めですよ」と押してくる案件が自分に合うとは限らない。

エージェントに求めるのは「情報」と「交渉代行」に絞り、最終的な判断は自分でする。

失敗4：退職を先に決める

SESは「辞めます」と言うと引き止めが激しかったり、退職前に仕事を急に押し付けられたりすることがある。必ず内定後に退職交渉を始める。先に辞めると、プレッシャーから焦って妥協した転職先を選んでしまうリスクがある。

まとめ：今日からできるアクション

SESからの転職は「実績の言語化」と「GitHubの整備」が8割だ。

今日からできること：

1. スキルシートを書く（30分でできる）
2. STAR法でエピソードを1本作る（1時間でできる）
3. GitHubのプロフィールを整える（30分でできる）
4. レバテックキャリアに登録して初回面談をする（エージェントと話すだけで市場価値がわかる）

転職活動を「いつか」と言い続けている間にも、自社開発企業の採用枠は埋まっていく。今の自分の市場価値を知るだけでも、動いてみる価値はある。