転職停滞整理

SESから転職できない?難しい5つの原因と通過率を上げる14日診断

掲載方針:出典・対象条件・広告表示を確認する →
まず結論

SESからの転職は、所属がSESだから一律に難しいのではありません。止まりやすいのは、応募先の対象条件、現在と入社後の工程差、職務経歴書の証拠、面接での再現性、最終条件の五つです。直近十件を選考段階ごとに分け、最初に止まった一層だけを十四日で修正してください。テスト、アプリ運用保守、インフラ運用、PMOにも持ち運べる判断があります。経験を盛らず、現在できる責任と入社後に増やす責任を分け、隣接する求人から市場確認を始めます。

システム構成と案件の判断材料を確認するロボットエンジニア
SESから転職できない?難しい5つの原因と通過率を上げる14日診断の論点を、判断材料と次の行動に分けて表したイメージ。

「SESから転職できない」「何社へ応募しても難しい」と感じたとき、応募数だけを増やすと原因が見えなくなります。対象年齢や実務年数で申込前に外れているのか、求人の必須工程と職務経歴書が合っていないのか、書類では通るが面接の説明が曖昧なのかでは、直す場所が違います。まず直近十件を、相談前、求人提案前、応募前、書類、一次面接、最終面接、条件提示へ分けます。

厚生労働省のjob tagは、ITの仕事を企画・要件定義、設計、開発、テスト、運用・管理など工程別に示しています。運用・管理にも監視だけでなく、障害復旧、問い合わせ、手順見直しが含まれます。受託開発、Webサービス開発、プロジェクト管理も成果物と責任が異なります。転職の難しさは会社分類ではなく、現在証明できる工程と、求人が入社直後に求める工程の距離として測ります。

対象条件に合い、実際に求人・選考支援を利用したい場合だけ公式情報を確認してください。求人紹介、書類通過、面接通過、内定、配属、年収を保証しません。

01

「転職できない」を、最初に止まった選考段階へ分解する

最初に作るのは、企業名の反省表ではなく選考ログです。直近十件について、求人を知った日、対象条件、応募職種、必須経験、応募の有無、止まった段階、返答日、分かった理由、未確認事項を一行ずつ記録します。転職支援へ登録したが求人提案前に止まった件と、企業の書類選考で止まった件を同じ「不採用」へまとめないでください。前者はサービスの対象条件や求人在庫、後者は求人と書類の一致を先に確認します。

求人を紹介されなかった場合は、年齢、実務経験、勤務地、転職時期、希望年収、希望職種のどれが対象外だったかを確認します。「紹介できる求人がない」という回答だけでは、今月の求人在庫、希望条件、経歴の不足、サービス自体の対象外を区別できません。条件を一つだけ緩めた場合に候補が出るか、現在の経歴で隣接職種なら何があるかを聞き、理由を記録します。

書類で止まるなら、応募時に使った職務経歴書の版を保存します。後から直した最新版だけを見ても、落ちた理由は検証できません。求人の必須経験一つずつに対し、どの案件のどの事実が対応するか、未経験かを横へ書きます。必須要件を満たさない求人への大量応募と、満たすのに伝わらなかった応募を分けると、求人選定と書類修正のどちらを先に行うか決まります。

面接で止まるなら、聞かれた質問、回答の要点、深掘りで答えられなかった事実、逆質問で判明した役割差を面接当日に残します。最終条件で辞退したなら、それは「転職できない」ではなく、給与内訳、勤務地、担当工程、働き方などが合わなかった市場確認の結果です。内定数だけで成功を測らず、停止地点が応募前から面接へ移ったかを十四日ごとに見ます。

  • 相談前: 年齢・経験・地域・時期の対象条件
  • 提案前: 希望条件と現在の求人在庫
  • 書類: 必須工程と案件証拠の対応
  • 面接: 担当範囲・判断・結果の再現性
  • 条件: 給与内訳・配属・勤務地・働き方の一致
02

難しい五つの原因を、変えられる順番で診断する

一つ目は対象条件です。転職支援や求人には、実務年数、年齢、勤務地、就業状況、希望時期、職種などの条件があります。対象外のサービスへ登録し続けても書類改善の検証にはなりません。対象条件は自分の価値の判定ではなく、その時点で扱う求人と支援体制の範囲です。条件に合う窓口へ変えるか、直接応募、求人媒体、現職での役割変更など別の経路を比較します。

二つ目は工程差です。テスト実行だけの経験から、入社初日からWebサービスの要件定義と設計を単独で持つ求人へ応募すれば距離があります。一方、仕様差分からテスト観点を作り、不具合を切り分け、開発と回帰範囲を合意した経験なら、QA、テスト設計、保守開発の隣接求人と接点があります。「開発経験なし」と一括りにせず、入口、判断、成果物、レビュー、結果で現在地を示します。

三つ目は証拠不足、四つ目は説明不足です。職務経歴書に技術名と作業名しかない場合、採用側は入社後に任せられる範囲を判断できません。書類に立派な成果を書いても、面接で目的、制約、自分の判断、他者の責任、失敗、結果を説明できなければ再現性が伝わりません。書類と面接を別々に盛らず、同じ案件事実を文章と九十秒回答へ変えます。

五つ目は条件の不一致です。自社開発、社内SE、ITコンサル、上流工程という名称だけを必須にすると、実際の仕事より会社分類を探す活動になります。希望年収、リモート、勤務地、残業、工程、技術、配属、評価をすべて絶対条件にすれば候補は減ります。譲れない条件、比較する条件、入社後に増やす条件の三段階へ分け、一つを変えた場合の候補差を見ます。

  • 対象条件: 申込前に変えにくい条件を照合する
  • 工程差: 現在の成果物と入社90日の成果物を比べる
  • 証拠不足: 作業名を調査・判断・結果へ変える
  • 説明不足: 同じ事実を深掘りへ耐える回答にする
  • 条件不一致: 必須・比較・将来の条件を分ける
03

現在の担当を、隣接求人へ持ち運べる証拠に変える

テスト中心なら、実施件数より、仕様差分から追加した正常・異常・境界の観点、不具合の再現条件、原因候補、開発へ戻した情報、修正後の回帰範囲を整理します。テスト設計、QA、品質管理、保守開発は隣接しやすい候補です。製品コードを実装していない場合は未経験と明記し、現職または個人学習で作ったコードを本番実務へ混ぜません。

アプリ運用保守なら、問い合わせの受付から、再現、ログ・SQL調査、影響範囲、小改修、リリース確認、再発防止のどこまで持ったかを分けます。厚生労働省の職業情報でも、運用・管理は定常監視だけでなく障害時の復旧、問い合わせ、運用手順の見直しを含みます。保守開発、社内SE、自社サービス運用、SRE・DevOps、導入支援へ接続する証拠を一件作ります。

インフラ運用なら、アラート受信だけでなく、影響、一次切り分け、復旧、変更、切り戻し、構成、可用性、自動化を分けます。監視から設計構築やクラウドへ一度で肩書を変えることより、変更計画、レビュー、実施後確認を持つ求人の方が現在地とつながる場合があります。資格は知識の補助であり、本番で担当していない構築・設計を経験済みにしません。

PMO・進捗管理なら、会議回数や表の更新量ではなく、計画との差、課題、リスク、変更、依存関係、判断者、判断期限、決定後の実行結果を整理します。プロジェクトマネージャ、専門PMO、ITコンサル、社内SE・DX推進へ進む場合も、最終決定を誰が行い、自分はどの判断材料と成果物を持ったかを分けます。四つの担当すべてで、職名より次の求人が求める成果物との距離を比べてください。

  • テスト: 仕様・品質リスク・不具合分析・回帰範囲
  • アプリ保守: 再現・ログ・SQL・変更・再発防止
  • インフラ: 障害影響・変更・切り戻し・可用性
  • PMO: 差分・課題・リスク・変更・意思決定
  • 共通: 自分の判断、他者の決定、未経験を分ける
04

十四日で一層だけ直し、応募結果を比較できる実験にする

一日目と二日目は直近十件の選考ログを作り、最初に止まった段階を数えます。三日目は最も多い一層だけを改善対象にします。対象条件で止まっているのに職務経歴書を全面改稿する、面接で止まっているのに応募数を倍にする、といった原因と違う行動を止めます。件数が少ない場合は結論を出さず、三件以上の同種結果を集める市場確認として扱います。

四日目から七日目は求人三件を選び、必須経験を「工程・技術・業務・責任・年数」へ分けます。自分の案件証拠を一つずつ対応させ、対応なしは未経験とします。完全一致を装わず、近い経験と入社後にレビュー付きで増やす範囲を分けます。求人Aには合うが求人Bには合わないなら、経歴全体が弱いのではなく、応募先との距離が違うと判断できます。

八日目から十日目は、重点案件一件を職務経歴書と九十秒回答へ変えます。背景、目的、体制、担当工程、受け取った情報、調査、判断、成果物、他者の責任、結果、次に変えることを埋めます。顧客名、製品名、内部データ、画面、障害詳細を持ち出しません。根拠のない削減率やチーム全体の成果を自分一人の実績にしないでください。

十一日目から十四日目は、修正前と近い条件の求人二〜三件へ、同じ版の書類で応募または求人相談します。一件ごとに文章を変えすぎると原因を比較できないため、職務要約と重点案件の順序だけを求人へ合わせます。結果が書類通過へ動けば次は面接回答、変わらなければ求人距離と必須条件を再確認します。十四日で内定を約束する計画ではなく、停止地点を一層先へ動かす実験です。

  • 1〜3日: 十件を段階別に数え、最多の一層を選ぶ
  • 4〜7日: 求人三件と案件証拠の対応表を作る
  • 8〜10日: 一案件を書類と90秒回答へ変える
  • 11〜14日: 同条件・同じ書類版で二〜三件を比較する
  • 判定: 通過率より、停止地点が一層動いたかを見る
05

転職先は、会社名ではなく現在から増やす責任で五つ比較する

一つ目は別のSES・受託開発です。客先常駐を続けるかだけでなく、案件の決め方、一次・二次請け、チーム参画、担当工程、レビュー、待機給与、評価日、案件変更期限を確認します。現在と同じ技術を使いながら、テスト実行から設計、不具合分析、保守改修へ一段広げられるなら、会社分類が同じでもキャリア上の差があります。

二つ目はSIer・受託開発、三つ目は自社サービスです。受託開発では顧客要求、設計、品質、納期、責任分界を持つ範囲を確認します。自社サービスでは企画と近いことを期待しがちですが、入社後もテスト専任、外注管理、保守だけの求人はあります。公開後の利用・障害・改善へどこまで関わり、製品コードや設計を誰がレビューするかを聞きます。

四つ目は社内SE・情シスです。利用部門との要求整理、導入、受入、問い合わせ、障害対応、ベンダー管理、セキュリティ、運用改善のどれを持つかを求人ごとに確認します。「客先常駐ではない」「楽そう」を選定理由にせず、内製と外注、夜間当番、拠点対応、入社九十日の成果物、評価を比べます。運用保守や調整経験と接続しやすい一方、技術実装が減る求人もあります。

五つ目はITコンサル・PM・PMOです。業務課題、要求、選択肢、合意、計画、リスク、変更、導入結果へ責任を広げる方向です。上流という言葉だけで技術経験や意思決定権が増えるとは限りません。現在の担当で課題を構造化し、技術・業務の影響を示した証拠があるか。入社直後にどの規模・工程・成果物を持ち、誰がレビューするかを確認し、現在から二段以上飛ばす求人だけに絞らないでください。

  • 別SES: 案件選択・工程・レビュー・待機・評価
  • SIer: 顧客要求・設計・品質・責任分界
  • 自社サービス: 公開後の運用・改善・製品責任
  • 社内SE: 利用部門・導入・受入・障害・外注
  • ITコンサル/PMO: 課題・選択肢・計画・意思決定
06

職務経歴書と面接を、同じ案件事実から作る

ハローワークの職務経歴書案内は、具体的な職務内容、処理方法、責任の範囲などを整理する作成手順を示しています。SESでは所属会社名だけでは担当が伝わりにくいため、案件ごとに期間、業界・用途、体制、担当工程、技術、行動・結果を書きます。顧客名を一般化しても、担当範囲を曖昧にする必要はありません。

変換前が「金融システムの保守を三年担当」なら、変換後は一件の出来事へ寄せます。問い合わせの再現条件、ログ・SQLで確認した範囲、原因候補、影響機能、変更方針、レビュー担当、本番確認、再発防止を並べます。自分が改修していないなら調査と引き渡しまで、最終判断を顧客が行ったなら自分が作った判断材料までを書きます。大きな成果より境界が明確な事実の方が深掘りへ耐えます。

面接では「なぜ必要だったか」「最初に何を確認したか」「選択肢は何か」「自分が決めたことは何か」「誰が最終判断したか」「失敗・未確認は何か」「結果をどう確かめたか」「次は何を変えるか」の八問へ答えます。暗記した自己PRを長く話すより、一つの案件を時系列で説明し、質問に応じて工程と責任を広げます。

転職理由と志望動機も同じ事実へつなげます。「SESが嫌だから自社開発」ではなく、現職で増やそうとした責任、増やせなかった構造、次の求人で入社九十日に持つ成果物、その企業である理由を分けます。現職の悪口、未経験の誇張、会社分類への憧れを減らし、求人票と面接で確認した役割へ回答を合わせます。

  • 背景: 業界・用途・体制・制約を一般化する
  • 担当: 工程・技術・成果物・レビューを具体化する
  • 境界: 自分・上位者・顧客・別チームを分ける
  • 結果: 根拠のある数字か観察できた変化だけ使う
  • 志望: 入社90日に増やす責任へつなげる
07

対象条件に合う相談先へ同じ経歴と七問を渡す

転職支援を使う場合は、登録社数を増やす前に、年齢、実務経験、勤務地、希望職種、転職時期が対象条件に合う候補を選びます。同じ日付の職務経歴書、必須条件、比較条件、除外条件、求人七問を渡し、求人を選んだ理由と不足する証拠を比較します。サービスごとに違う希望を伝えると、求人差が担当者によるものか条件差によるものか分かりません。

TechGoは、主な利用対象が実務経験二年以上のITエンジニアで、二十代後半から三十代の支援を中心に案内されています。現在の案件事実から、次に任せられる工程と年収内訳を確認する候補です。STRATEGY CAREERは、エンジニア経験者、主に二十〜三十代、東京・大阪エリアでの就職希望が対象の目安です。掲載事例を自分への結果保証にせず、現在紹介できる職種と選定理由を聞きます。

社内SE転職ナビは、ITエンジニア経験者、二十〜四十四歳、関東・関西・北海道での転職希望などが主な利用対象です。社内SE・情シスへ進みたい場合も、求人ごとの内製・外注、問い合わせ、障害当番、入社九十日を確認します。TechClipsエージェントは、ITエンジニア経験を使い、自社サービスを持つ事業会社などを比較したい場合の候補です。自社開発への配属や年収を保証するものではありません。

比較中の全社へ申し込む必要はありません。条件に合う二社までへ同じ七問を渡し、七日間など回答期間をそろえます。紹介数だけでなく、現在の経歴で紹介可能な求人、その求人を選んだ経験上の理由、入社後の工程、足りない証拠、配属、給与内訳、応募同意を比べます。求人が合わなければ断り、相談、応募、内定承諾、退職を別々に判断してください。

  • 現在紹介できる求人と、経歴上の選定理由は何か
  • 必須経験に対応する案件事実と、不足は何か
  • 入社30・60・90日の工程・成果物・レビューは何か
  • 配属・案件変更・待機・勤務場所はどう決まるか
  • 基本給・固定残業・賞与・評価日はどうなるか
  • 企業ごとの応募前に本人同意を取るか
  • 求人がない場合、次に増やす責任は何か
変換例

職務経歴書の変換例

変換前

SESで三年働きましたが、開発経験が少なく、何社受けても転職できません。コミュニケーション力と向上心には自信があります。

変換後

業務システムのアプリ運用保守で、問い合わせ内容を権限・入力データ・発生時刻へ分け、ログとSQLから原因範囲を特定しました。影響機能と暫定回避を開発担当へ共有し、小改修後の結合テストと本番確認まで担当しました。製品コードの設計・実装は未経験です。まず保守開発・社内SE求人を対象に、入社90日で小改修、受入、再発防止のどれをレビュー付きで持てるか確認します。

「転職できない」という結論を、現在の担当範囲、持ち運べる判断、未経験、隣接求人、入社後に増やす責任へ変換します。

確認

行動前チェックリスト

  • 直近十件を相談前・提案前・書類・面接・条件へ分けた
  • 最初に止まった段階が最も多い一層を選んだ
  • 求人三件の必須経験を工程・技術・業務・責任へ分けた
  • 必須経験と案件事実を一つずつ対応させた
  • 担当していない工程と自己学習を実務へ混ぜていない
  • 重点案件を背景・判断・境界・結果へ変えた
  • 同じ案件を面接の八問で説明できる
  • 十四日間は一つの条件または書類版だけを変える
  • テスト・保守・インフラ・PMOの専用記事で証拠を確認した
  • 入社90日の工程・成果物・レビュー担当を求人へ聞く
  • 対象条件に合う二社までへ同じ経歴と七問を渡す
  • 相談・応募・内定承諾・退職を別々に判断する
参照元

参照した公式情報