SESから抜けたいと思ったときに検討した選択肢

SESの現場で3年ほど経験を積んだ頃、私は「このままでいいのか」という問いをよく自分に向けていました。仕事が嫌いだったわけではありません。客先の現場でエンジニアと直接話しながら作業できること、さまざまな業界のシステムを間近で見られることは、むしろ自分に合っていた部分もありました。ただ、「次に何ができるようになるか」というイメージが持ちにくく、そこに漠然とした不満がありました。

この記事では、私がSESから離れることを本格的に考えた時期に整理した内容をもとに、取りうる選択肢とその実態を書きます。最初に言っておきたいのは、SES自体を否定したいわけではないということです。客先常駐で得た経験、特に複数の現場で見た組織の動かし方や障害対応の文化は、いまでも設計や提案の場面で活きています。ただ、「何が不満で、何を変えたいのか」を整理しないまま動くと、転職先で同じ閉塞感を感じる可能性があります。

SESで感じる不満を分解する

「SESを抜けたい」と感じている人に、具体的に何が嫌かを聞くと、答えはいくつかに分かれます。それぞれ根っこが違うので、解決策も変わります。

案件が選べない

客先常駐で一番多い不満がこれです。入社時に「希望を出せる」と聞いていたのに、実際は空きのある案件に入ることになる。技術スタックが自分の希望と合わない現場に入り続けると、履歴書に書ける技術が偏ります。

ただ、これは「SES全般の問題」というより「その会社の規模や営業力の問題」である場合も多い。規模の大きいSES会社では選択肢があっても、小規模では実質ゼロというケースがあります。不満の対象が「SESという業態」か「いまの会社」かを区別することが最初のステップです。

技術が偏る・成長が止まる

特定の現場に長く入り続けると、その環境の技術スタックしか触れなくなることがあります。私が感じていた不満もここに近く、「このシステムの専門家にはなれるが、潰しが効くスキルが増えていない」という感覚でした。

これは案件の性質によって大きく変わります。同じSESでも、構築・移行フェーズが続く案件に入れるか、安定稼働中のシステムの監視運用だけになるかで、数年後の経歴はかなり変わります。

評価が見えにくい

客先から評価を受けても、それが自社での処遇に直結しないことがあります。客先での貢献が高くても、自社での昇給・昇格の基準が不明瞭な場合、努力が報われている実感を持ちにくい。これは業態固有の構造的な問題です。

その他：通勤・人間関係

毎回通勤先が変わる案件変更の多さを嫌う人もいます。また、自社に出社する機会がほとんどないため、会社への帰属意識が薄く、孤立感を感じるという声も聞きます。ただしこれらは、現場によっては解決できる問題でもあります。

選択肢1：同じ会社で案件を変える

最初に検討すべきなのは、同じ会社にいながら案件を変えることです。転職より確実に負担が低く、リスクもありません。

有効なのは、不満の本質が「業態」ではなく「いまの案件の内容」や「営業担当との関係」にある場合です。「このシステムにずっと入り続けたくない」「もう少し上流工程に関わりたい」という希望は、社内の営業担当に明確に伝えることで動く場合があります。特にある程度の実績がある人材であれば、会社側も別の案件に動かす理由があります。

私が試みたときの経験を正直に書くと、最初は「なんとなく変えてほしい」という伝え方をしていて、まったく動きませんでした。「半年後に設計の経験がある案件に入りたい。それができないなら転職を考える」と具体的かつ明確に伝えたとき、初めて話が進みました。伝え方の問題が大きかったと思っています。

ただし、会社の案件の傾向そのものが問題の場合——たとえば、監視運用案件しか受注していない、特定の業界に特化しすぎている——は、社内で解決が難しいです。そこは会社を変える話になります。

選択肢2：自社開発・事業会社に移る

「自社サービスを持っている会社に移りたい」という人は多い。SESから自社開発の会社に移ることは、転職市場で一般的な動きになっています。

メリットとして言われることは、開発したサービスの成果が見えやすい、技術選定に関われる場合がある、同じ組織の人たちと継続的に働ける、といった点です。これらは確かに魅力です。ただ実際には、自社開発といっても環境は会社によって大きく異なります。

インフラの観点で言うと、スタートアップや中小規模の事業会社では、インフラエンジニアが1〜2名しかおらず、設計から構築、運用まで全部一人でやる、という環境も珍しくありません。良い面もありますが、相談できる人がいない、技術的な判断を自分で全部行わなければならない、という負荷もあります。SESで大規模環境に関わっていた人が、小規模な事業会社に移ってギャップを感じるケースは聞きます。

一方、ある程度の規模の事業会社では、インフラチームが組織化されていて、専門性を高めながらキャリアを積める環境もあります。「自社開発なら何でもいい」ではなく、会社の規模・チームの構成・技術スタックを確認することが重要です。

転職先の選び方については、ITエンジニアの転職エージェントの選び方で求人の読み方を整理しています。

選択肢3：SIerの元請け側に移る

SESで客先常駐をしていた人が次のステップとして検討するのが、SIerの元請け側、つまりPMやアーキテクトとして上流から携わる立場です。

これは、SESでの現場経験が評価される典型的なキャリアパスです。客先の現場で何年も運用・構築に携わった経験は、元請けが要件定義や設計をするときに直接役立ちます。「現場を知っている人材」として、発言に重みが出る。

ただし、元請けSIerに移ると仕事の性質が変わります。手を動かす機会が減り、文書を書く、会議を仕切る、協力会社の管理をするという業務が増えます。自分で環境を作ることに充実感があった人は、この変化を窮屈に感じることがあります。

また、元請けSIerにも規模や文化の差があります。入ってから担当する案件が何かによって、実際にできることは大きく変わります。「元請けに移れば自由になる」というイメージは、必ずしも実態と一致しません。案件の内容と、チームの体制を確認することが大事です。

選択肢4：フリーランスという選択

エンジニアのフリーランスは、選択肢として現実的な位置にあります。SESの経験がある人なら、客先常駐という働き方自体には慣れているため、フリーランスへの移行は構造的には近い。ただ、決定的な違いがあります。

フリーランスになると、収入の保証がなくなります。案件の契約期間が終わったあと次が見つからなければ、収入がゼロになる期間が生まれます。会社員であれば会社が案件を埋めてくれますが、フリーランスでは自分で動く必要があります。エージェントを使えばある程度は埋められますが、それでも不確実性は残ります。

社会保険の自己負担も増えます。会社員時代は厚生年金・健康保険の保険料を会社と折半していましたが、フリーランスでは全額自己負担になります。この差は月単位で見ると数万円規模になることがあります。節税のための青色申告、消費税の申告なども自分で管理することになります。

フリーランスとして働いている人の話を聞くと、技術力よりも「どう仕事を取り続けるか」「収入の波をどう管理するか」の能力が生活を安定させる鍵になっている、と感じます。これはSES時代に会社が担っていた部分を、自分で引き受けることを意味します。

SESからフリーランスに移るタイミングを検討しているなら、まず転職エージェントに「フリーランス支援もしているか」を聞いてみることをおすすめします。フリーランス案件専門の仲介も存在しますし、正社員転職と比較しながら話を聞けるサービスもあります。

何を基準に選択肢を絞るか

4つの選択肢を整理しましたが、どれを選ぶかは「何が不満の根っこか」に戻ります。

案件の内容が問題なら、まず社内の案件変更を試みる。会社の構造が問題なら、転職を考える。その転職先として自社開発か元請けSIerかフリーランスかは、自分がどういう働き方をしたいかによります。

私が整理したときに使った軸は次の3つでした。

1. 手を動かすことへのこだわりがどの程度あるか

コードを書く、設計図を描く、環境を作るという作業が好きか。それとも、仕事の全体を動かすことのほうが向いているか。元請けに移ると後者の比率が上がります。

2. 安定と自由のどちらを優先するか

フリーランスは自由度が高い代わりに、収入の安定性が下がります。家族の状況、ローンの有無、リスクへの耐性など、個人の状況によって正解が変わります。

3. 5年後にどういうエンジニアでいたいか

転職の判断は短期的な不満の解消だけでなく、5年後の状態を見据えてするほうが後悔が少ない。自社開発で深いプロダクト知識を持つか、元請けで幅広い顧客経験を積むか、フリーランスで特定領域の専門性を高めるか。いずれも方向性として間違っていませんが、それぞれが積み上げる経験は違います。

どの選択肢が自分に合うか迷っている場合、転職AGENT Navi は「どのエージェントを選ぶか」の相談から受け付けている形式です。SESから出たい理由と、自分の経歴をもとに、どういう選択肢があるかを整理する壁打ちの相談から始めることができます。公式サイトの記載を読む限り、無料で相談できるとのことです。

転職活動のスケジュールをどう組むかは、転職活動のスケジュール｜情報収集から入社までに整理しました。

転職活動を始めるならどこから

選択肢が絞れたら、情報収集と並行して動き始める段階です。私が実際にやってよかったのは、転職エージェントへの登録より先に自分の経歴を棚卸しすることでした。

SESでの経験は、案件ごとに書くことが多く、職務経歴書の体裁に整えるのが手間です。逆に言うと、複数の現場での経験を丁寧に書くと、経歴書として情報量が豊富になります。「運用しかやっていない」と感じていても、監視設計、手順書整備、障害対応のフロー改善、後輩指導など、書けることは意外と多い。

これをやってから転職エージェントの初回面談に臨むと、話が早く進みます。何もない状態で面談に行くと、エージェントに経歴を聞き出してもらう時間に使ってしまい、本質的な話をする余裕がなくなります。

エンジニア専門の転職支援サービスとして、レバテックキャリアのような専門特化型のサービスは、技術用語で話が進みやすく、求人票の技術情報が細かい傾向があります。公式の説明を見る限り、インフラやクラウドの求人も扱っているようです。

在職しながら転職活動を進めるための時間の作り方は、在職中の転職活動の進め方に詳しく書きました。

SESから移る先として年収レンジがどう変わるかを把握したい場合は、実際に求人票を複数読んで傾向を掴むか、エージェントに直接聞くのが確実です。インフラエンジニアの年収相場でも年収データの読み方を整理しています。

SESでの経験を棚卸しする方法

転職活動に向けて最初にやるべきことのひとつが、経歴の棚卸しです。SESの経験は案件が複数にわたるため、書き出し方にコツが必要です。

基本的な整理の単位は「案件ごと」です。各案件について、在籍期間、現場の業種と規模、使った技術スタック、担当した役割（監視・運用・構築・設計）、そこで自分が判断したことや改善したことを書き出します。「運用しかやっていない」と感じていても、障害対応の手順を整備した、新しく入ってきたメンバーに作業を教えた、監視項目の見直しを提案した、といった経験は書ける実績になります。

次に、案件をまたいだ「技術の重複」を確認します。複数の案件で使っている技術は、その人の核になるスキルです。たとえば「Linuxサーバの運用を3年」「ネットワーク機器の設定変更を2年」「障害時のエスカレーション対応を継続的に担当」というパターンが見えてきたとします。これは特定のスキルを継続的に積んできた経緯として、職務経歴書で有効に使えます。

私がSESから転職する際に経歴を書き直したとき、一番変わったのは「規模を数字で書く」という点でした。「サーバーの運用保守」という書き方を「Linuxサーバー約80台の運用保守（3名チーム）」と変えただけで、経歴書の印象が大きく変わりました。面接担当者が規模から難易度を推し量れるようになるからです。インフラ系の職務経歴書の書き方についてはインフラ・クラウド職の職務経歴書の書き方に詳しく書きました。

また、SES時代の現場経験は「社内の状況を調べなくても動ける」という強みにもなります。事業会社や元請けのエンジニアが「どういう現場でどんな問題が起きるか」を知らないまま設計・提案することは多い。そこへ実際の運用の現場を知っている人間が入ることで、設計の実現性を高めたり、現場側の視点で抜けを指摘したりできます。これは経歴書には書きにくいが、面接で伝えると実際に評価が変わることがあります。

SESから移ったあとのキャリアパスを考える

SESから出たあとのキャリアをどう描くかも、転職先を選ぶ判断に影響します。移った先で何年かした後に「次はどこへ行けるか」を考えておくと、転職先の選択が変わることがあります。

自社開発の会社に移った場合、そのサービスへの深い関わりが強みになります。ただし、特定のプロダクトに長年関わると、そのプロダクト特有の経験として評価される部分と、外に出たときに汎用性がないと見られる部分が出てきます。転職市場で評価されやすいのは「同じような規模・構成のインフラを設計・構築した経験」「パフォーマンス改善やコスト削減を数字で説明できる実績」「IaCや自動化に取り組んだ経験」といった、汎用性のある要素です。

元請けSIerに移った場合、複数の顧客案件を経験できます。SES時代と構造は似ていますが、立場が変わります。調整力やドキュメント作成のスキルが鍛えられる反面、手を動かす機会は減ります。5年後10年後にプロジェクトマネジメントや提案側に軸足を置くつもりなら、この道筋は合っています。

フリーランスとして独立した場合、専門性の深さが直接収入に影響します。広く浅く対応するより、特定の領域（たとえばAWSのインフラ構築、Terraformを使ったIaC整備、セキュリティ設計）に特化したほうが、案件を取りやすいという話を聞きます。

クラウドエンジニアのキャリアパスについてはクラウドエンジニアのキャリアパスで詳しく書いています。運用から設計へどう移るか、オンプレの経験がクラウドでどう活きるかを整理しました。

転職先を決める前に聞いておきたいこと

転職先を選ぶときに後悔が少ない人は、面接を「自分が評価される場」だけでなく「自分が評価する場」として使っている印象があります。

具体的に面接や内定後の面談で聞いておくといいのは次のような点です。

インフラの担当者は何人いるか、どういう体制か
チームの人数と構成によって、入った後の経験が大きく変わります。1人体制なら何でも自分でやる必要があり、裁量は大きいが孤立しやすい。複数名で役割が分かれている場合は、自分がどこに入るかで経験の幅が変わります。

設計から関われるか、運用保守がメインか
求人票に「設計・構築担当」と書かれていても、実態は既存システムの維持管理がほとんどというケースがあります。面接で「入社直後は何から担当することになりますか」と聞くと、現実に近い答えが返ってきます。

使っている技術スタックと、今後の変化の方向
いまの環境だけでなく、2〜3年後にどう変えようとしているかを聞きます。クラウド移行を進めている会社では、オンプレとクラウド両方の経験を積む機会が生まれます。逆に「特に変える予定はない」という会社では、入った後も環境が変わらない可能性があります。

勤務形態と案件の変わり方
「常駐はあるか」「チームは固定か、プロジェクトごとに変わるか」「リモートの比率はどれくらいか」といった点は、日々の生活に直結するので事前に確認しておきたい項目です。

これらは聞きにくい質問に見えますが、面接官からすると「入社後のことをきちんと考えている人」という印象を与えます。準備ができていれば聞いて構いません。

まとめ

「SESを抜けたい」と感じたとき、まず何が不満かを分解することが先です。案件の内容が問題なのか、業態の構造が問題なのか、会社の規模や営業体制が問題なのかによって、取るべきアクションは変わります。転職が必要なのか、社内の案件変更で解決できるのかも、この整理から見えてきます。

選択肢は「同じ会社で案件変更」「自社開発・事業会社」「元請けSIer」「フリーランス」の4つです。それぞれ仕事の性質が変わるため、5年後にどういう経験を積みたいかをある程度見据えてから選ぶほうが、後悔が少ないです。

SESで得た現場経験は、転職先でもキャリアの土台になります。「SESにいたこと」がマイナスになるわけではなく、そこで何を経験し、何を判断してきたかが問われます。複数の現場を渡り歩いた経験は、「さまざまな現場を知っている人材」として有効に使えます。

情報収集は、転職を決意する前から始めても構いません。求人票を読む、エージェントに話を聞く、という行為は情報収集であって、すぐに決断しなければいけないわけではありません。動き始めることと今すぐ決断することは別の話です。選択肢の解像度を上げながら、自分のペースで進めることができます。気持ちが落ち着いて「やはり転職しないほうがいい」という結論になることもあります。それはそれで、きちんと考えた結果として価値があります。転職を迷っている段階でも、エージェントへの相談や求人票の閲覧から始めて情報を集めておくことは有益です。動き始めることと決断することは別の行動です。