SESから事業会社への転身は、単に「応募先を変える」だけでは成功しにくい。評価される経験を能動的に作り、言語化し、合う企業を選ぶ──この三段構えが必要だ。本記事では、実際に現場で効いた3ステップを、編集部の取材ベースで整理する。
なぜSESからの転身は難易度が上がるのか
SESでの経験がそのまま事業会社で評価されにくい理由は、主に三つあるとされる。第一に、担当領域が「実装の一部」に限定されがちで、設計判断や要件定義の経験が職務経歴書から読み取りにくい。第二に、プロジェクトの期間が短く、長期運用やプロダクト改善のサイクルに関わった経験を語りにくい。第三に、技術選定や意思決定の裁量が顧客側にあるため、「自分が何を決めた経験」なのかが曖昧になる。
逆に言えば、この三つを埋める動きを意識的に作れば、評価は変わりうる。以下では現場に入ったままでもできる3ステップを紹介する。
ステップ1：現場の中で「評価される経験」を能動的に作る
最初のステップは、今いる現場で獲得できる経験の質を上げることだ。転職活動の前に、半年〜1年はこのフェーズに投資する価値がある。
設計・レビュー側に関わる
実装者としてアサインされていても、設計ドキュメントのレビューに自発的に参加したり、自分の担当機能の設計判断の理由を言語化してチームに共有する動きは取れる。小さくても「設計に関与した」事実が積み上がれば、職務経歴書の書き方が変わる。
運用・改善サイクルに入る
開発完了後の運用・障害対応・改善提案までを担当したプロジェクトを、できれば1つは作りたい。プロダクト視点の会話ができるかは、事業会社の面接で繰り返し聞かれる観点とされる。
数値で語れる成果を持つ
レスポンスタイムを何msから何msに改善した、バッチの実行時間を半分にした、テストカバレッジを何%引き上げた──といった「前後で比較できる数字」を意識的に記録しておく。後からの捏造はできないので、日々のメモが重要になる。
ステップ2：職務経歴書で「意思決定の跡」を可視化する
次のステップは、持っている経験の棚卸しと翻訳だ。ここで多くの候補者がつまずく。
やりがちな失敗は、プロジェクト概要と使用技術だけを羅列してしまうこと。書類で見られているのは、「あなたが何を考え、何を選び、どう動いたか」だ。以下のような項目を各案件に1〜3行で添えると、読み手の印象は大きく変わる。
- チームの中での自分の役割（実装、レビュー、設計、リード）
- 直面した課題と、選択肢の中で自分がどれを選んだか
- 選んだ理由と、結果としての変化（数値・定性どちらでも）
- うまくいかなかったこと、そこから学んだこと
「SESだから裁量がなかった」と感じる場合でも、小さなタスク単位では必ず選択はしている。その粒度まで降りて言語化するのが、棚卸しの本質だ。
ステップ3：「合う事業会社」を解像度高く選ぶ
最後のステップは応募先の選定だ。「自社開発」と一括りにされがちだが、実態はかなり幅がある。SES出身者が馴染みやすい会社と、ギャップが大きい会社の両方が存在する。
見るべき観点
- 開発プロセスの成熟度：CI/CD、コードレビュー、テスト文化が定着しているか
- エンジニア組織の規模と階層：1人目エンジニアに近い環境か、既に数十名規模のチームか
- プロダクトのフェーズ：0→1か、1→10か、10→100か。求められる動き方が違う
- 技術的負債との向き合い方：リファクタに投資する余地があるか
求人票だけで判断するのは難しいため、カジュアル面談や技術ブログ・登壇資料からチーム文化を読み取る作業が欠かせない。ITエンジニア特化のエージェント（求人10,000件以上を扱うTechGoのようなサービス）を併用すると、内部事情の共有や年収交渉のサポートが得られ、判断の精度が上がりやすい。
転身までの現実的なタイムライン
ステップ1の経験づくりに6〜12ヶ月、ステップ2の棚卸しと応募書類整備に1〜2ヶ月、ステップ3の選考に2〜3ヶ月というのが、現場で見かける標準的なペース感とされる。焦って書類を出してしまうより、現場で1つ大きな成果を作り切ってから動いた方が、結果的に短い期間で転身できるケースが多い。
まとめ
- SES経験が評価されにくいのは「設計・運用・意思決定」が見えにくいため。現場の中で能動的に埋める動きを取る
- 職務経歴書は技術の羅列ではなく「何を考え、何を選んだか」を書く。小さな選択まで降りて言語化する
- 応募先は「自社開発」で一括りにせず、プロセス成熟度・組織規模・プロダクトのフェーズで解像度高く選ぶ
- 転身には合計1年前後を見込み、現場で成果を作ってから動いた方が結果的に近道になる
（本記事は一般的な市場情報をもとにした編集部の見解です）
