「SESから脱出したい」と思ったら最初にやること｜自社開発に転職した現役エンジニアが解説

SESから脱出したいと思ったとき、最初にやるべきことは勢いで退職届を出すことではありません。まずは、自社開発企業へ転職して何を身につけたいのかを整理し、これまでの実務経験を職務経歴書やポートフォリオで伝えられる状態に整えることが大切です。

SESでは案件によって担当工程や使用技術が変わるため、経験がどうしても分散しやすくなります。だからこそ、転職活動では何を経験したかだけでなく、その経験を次の環境でどう活かせるかまで整理しておく必要があります。

【筆者プロフィール：現役フロントエンドエンジニア】

私は新卒でSES企業に入社し、約3年半勤務したのち、幅広い開発スキルを身につけたいと思い受託開発の会社へ移りました。受託開発で2年ほど経験を積んだあと、大阪の自社開発企業へ転職し、現在はフロントエンドエンジニアとして3年目を迎えています。自社開発未経験の状態では、実務経験の見せ方やポートフォリオの作り方に迷う場面もありましたが、準備するものを一つずつ整理して転職活動を進めました。

この記事では、SESから脱出すること自体を目的にせず、自社開発企業へ転職するために必要な経験の棚卸し、職務経歴書、ポートフォリオ、面接対策、転職時期、退職の実務まで順番に解説します。

「SESから脱出したい」と感じるのは、あなたの能力の問題ではない

SESで働いていると、経験年数のわりにスキルが身についていないのではないか、このまま今の案件を続けていていいのかと、ふと不安になる瞬間があります。

SESでは参画する案件によって担当工程や使用技術、開発環境が変わります。設計や開発を経験できる案件もあれば、テストや運用保守が中心になる案件もあります。

案件が変われば、開発ルールやドキュメント、ツール、人間関係まで覚え直さなければなりません。幅広い環境に適応する力は身につきますが、一つの技術やプロダクトを長期間掘り下げる経験は、どうしても積みにくくなります。

その結果、転職活動を始めようとしても「自分には何をアピールすればいいのか分からない」という状態になりやすいのです。

ここで重要なのは、SESで経験したことを無価値だと決めつけないことです。

たとえば、複数の現場で異なる開発ルールに適応した経験、顧客や他部署と調整した経験、障害対応や手順改善を行った経験は、そのままでは伝わりにくくても、整理すれば転職時の材料になります。

まずは「自分には何もない」と考えるのではなく、これまでの案件で何を任され、どんな課題に対応してきたのかを分解してみましょう。

脱出そのものを目的にすると同じ場所に戻ってくる

SESから離れることだけを目的に転職活動を始めると、転職先で結局は別の不満を抱えることになりかねません。

自社開発企業でも、既存サービスの運用保守が中心の会社、新機能開発を積極的に進める会社、開発の一部を外部へ委託している会社など、仕事の進め方はさまざまです。

SESではないという条件だけで応募先を選ぶと、客先常駐ではなくなったとしても、思っていたより開発に関われない結果になりかねません。

そこで、求人を探す前に「SESを辞めた先で何を身につけたいのか」を決めておきます。

たとえば、一つのプロダクトを長期間担当したいのか、設計から実装まで経験したいのか、ユーザーの反応を見ながら改善したいのか。ここが決まれば、求人票を見るときの基準も変わります。

現在の会社に残る可能性も含めて確認しておきたいポイントがあります。

今のSES企業で希望する経験を積めるか確認する

転職を決める前に、上司や営業担当へ「今後どのような案件に入りたいか」を具体的に伝えてみる方法があります。

たとえば、案件を選ぶ際にどこまで希望を出せるのか、プライム案件に入る機会があるのか、平均的なアサイン期間はどのくらいなのかを確認します。

ここで重要なのは、AWSを使いたい、開発をしたいと伝えるだけで終わらせないことです。

「今後1〜2年でWeb開発の経験を増やしたい。そのために次回の案件では実装工程まで担当したい」のように、目指す方向と希望する経験をセットで伝えます。

そのうえで、希望する経験を今の会社で積むことが難しいと分かったなら、自社開発企業への転職を具体的に考えていけばいいでしょう。

SESだから悪い、自社開発だから正解という話ではありません。自分が積みたい経験と、現在の環境で積める経験が一致しているかを確認することが先です。

いきなり自社開発を目指さず、受託開発を経由する道もある

自社開発企業を目指す場合、SESから直接応募するだけが選択肢ではありません。

私自身、SESを離れる際に自社開発企業への応募も検討しましたが、当時の実務経験だけでは開発の幅が足りないと感じ、いったん受託開発の会社に移りました。

受託開発は、お客さんから依頼を受けてシステムを作る仕事です。要件を聞き取る打ち合わせから設計、実装、テスト、リリース後の運用・保守まで、SESの案件よりも広い範囲を任されることが多く、限られた人数で回すぶん裁量も大きくなります。

顧客の要望を整理して仕様に落とし込む力、納期を意識して進める力、リリース後の保守まで見据えて設計する力は、そのまま自社開発でも使える武器になります。モダンな技術に触れる機会が少なかったとしても、こうした力があれば自社開発企業への転職で不利になるとは限りません。

もちろん、受託開発を経由すれば必ず有利になるという話ではありません。SES時代よりも幅広い経験を積みたいのか、あるいはすぐにでも一つのプロダクトに腰を据えたいのかによって、選ぶべき道は変わります。

今のスキルのまま自社開発に応募して通用するか迷いがあるなら、受託開発で経験の幅を広げてから改めて自社開発を目指すという順番も、選択肢の一つとして持っておいてください。

自社開発への転職準備は経験の言語化から始まる

自社開発企業への転職では、使用した言語やツールを並べるだけでは、これまでの経験が十分に伝わりません。

採用側が知りたいのは「何を使ったか」だけではなく、「その環境で何を担当し、どんな課題に対してどう動いたのか」です。

SESと受託開発、両方の経験を自社開発企業向けに整理するなら、まずは職務経歴書の作り方を変えるところから始めます。

①スキルシートと職務経歴書は別物と心得る

SESで使うスキルシートと、転職活動で提出する職務経歴書は目的が違います。

スキルシートは、経験した技術や工程を短時間で確認できるようにする資料です。使用言語、OS、DB、担当工程、経験年数などを一覧にしておけば、案件とのマッチングに使えます。

職務経歴書では、それだけでは足りません。

採用担当者が知りたいのは、その経験を通じてどんな仕事ができる人なのかという部分です。担当した作業だけを書くのではなく、課題、行動、結果まで整理しておきます。

たとえば、次のような記載では業務内容は分かっても、本人がどのような工夫をしたのかまでは伝わりません。

これを、課題・行動・結果まで掘り下げます。

実績を数字で示せる場合は、さらに具体的になります。

「作業時間を月10時間削減した」「障害対応の手順を整理して初動対応を短縮した」のように、結果まで書けるものを探してください。

顧客名やプロジェクト名を出せない場合でも、システムの規模、チーム人数、自分の担当範囲、扱った技術などは表現できます。

②SESと受託開発の経験を案件ごとに棚卸しする

職務経歴書を書き始める前に、これまで参画した案件を一つずつ振り返ります。

最初から「すごい実績」を探す必要はありません。案件ごとに、どんな仕事をしていたのかを細かく分解していきます。

• どのようなシステムやサービスだったか
• プロジェクト全体と所属チームの人数
• 使用した言語、フレームワーク、DB、クラウドなど
• 担当した工程と具体的な業務
• トラブルや課題が発生したときの対応
• 顧客や他部署、チームメンバーとの調整内容
• 自分から提案して改善したこと

「テストしかしていない」「監視しかしていない」と感じる場合も、そこで終わらせません。

テストケースの不備を見つけた、障害の切り分け手順を改善した、手順書の不足に気づいて修正したといった行動があれば、それも実務経験です。

SES時代は、複数の現場で異なる開発ルールに適応してきた経験が財産になります。環境が変わるたびにどのように仕事を立ち上げてきたのかまで掘り下げてみてください。

受託開発の経験は、また違う切り口で棚卸しできます。要件を聞き取る打ち合わせから設計、実装、テスト、リリース後の保守まで一気通貫で関わっていたなら、その規模感やチーム人数、自分が担った役割を具体的に書き出します。長く運用しているシステムの保守に関わっていたなら、最初の設計判断が数年後の保守性や機能追加にどう影響するかを実務から学べた、という書き方もできます。

そして、棚卸しが終わったら「転職先で何を積み上げたいのか」につなげます。

たとえば、SES時代に案件ごとに技術が変わることへ課題を感じ、受託開発で幅広い経験を積んだのであれば、「次は一つのプロダクトに長期的に関わり、設計や改善まで経験したい」という志望理由に自然につながります。

実務経験の不足はポートフォリオで補う

自社開発企業を目指す場合、実務だけでは足りない部分をポートフォリオで補う方法があります。

ここで大切なのは、見た目の豪華さではありません。採用側が確認したいのは、どんな課題を想定し、なぜその技術を選び、どのように設計・実装したのかです。

私も自社開発未経験のまま転職活動を始めたとき、同じ壁にぶつかりました。SESと受託開発ではバックエンド寄りの業務が多く、フロントエンドの実装経験は限られていたので、ポートフォリオでその部分を補うことにしました。技術はReactとTypeScriptを選び、認証やデータの保存にはFirebaseを使っています。理由は単純で、フロントエンド単体でも動くものを作りやすく、選考でも話題にのぼりやすい組み合わせだったからです。

①技術選定は求人の多さで決めていい

ポートフォリオを作るとき、「誰も作っていないサービスを作ろう」「最新技術を全部入れよう」と考える必要はありません。

転職が目的なら、志望する求人で使われている技術を選ぶ方法もあります。

フロントエンドを目指すのであれば、React、Vue.js、Next.js、TypeScriptなど、応募したい求人で採用されている技術から選ぶのも一つの考え方です。

重要なのは、技術の名前を並べることではありません。

なぜこのフレームワークを選んだのか、なぜこの状態管理の方法を選んだのか、別の方法ではなくこの構成にした理由は何か。こうした質問に答えられる状態を作ります。

READMEにも、アプリの概要だけでなく、技術選定の理由、画面構成、状態管理の方針、API連携、デプロイ方法、今後の改善点まで整理しておくと、コードだけでは伝わりにくい考え方を補足できます。

②動くものができたら転職活動を始める

ポートフォリオを完璧にしてから応募しようとすると、転職活動の開始がどんどん遅くなります。

まずはコアとなる機能が動く状態まで作り、READMEに概要と技術構成をまとめたら、求人探しや応募を並行して進めていきます。

選考を受けると、自分では気づかなかった不足部分が見えてきます。

私の場合、なぜこのアプリを作ったのか、何を解決したいのか、工夫した点はどこかという3つを、面接のたびに問われました。最初のうちはうまく答えられず、面接のあとに自分のポートフォリオを見返して、機能ごとに答えを書き出す作業をしました。振り返ると、この作業こそが、面接でいちばん具体的に話せる材料になっています。

ポートフォリオでは、成功した部分だけを見せようとする必要はありません。どこでつまずき、何を調べ、どのように解決したのか。そこまで整理しておけば、面接では「自分で考えて問題を解決した経験」として話せます。

③コミット履歴は第三者が読む前提で整える

GitHubを選考で提出するなら、ソースコードだけでなくコミット履歴も整理しておきます。

「fix bug」「update」のようなコミットが大量に並んでいると、何を変更したのか後から確認しにくくなります。私が最初につけていたコミットメッセージも、正直ほとんどがこの状態でした。ある程度書き溜めたあとに見返して、恥ずかしくなって書き直した経緯があります。

次のように変更内容が分かる形にしておくと、履歴そのものが開発記録になります。

• feat: ログイン画面のフォームバリデーションを実装
• fix: 画面幅が狭い端末でレイアウトが崩れる不具合を修正
• refactor: 一覧表示のコンポーネントを共通化
• test: フォーム入力のバリデーションに単体テストを追加

すでに作ったリポジトリの履歴をすべて作り直す必要はありません。これから追加するコミットを整理し、READMEやコードそのものも第三者が読む前提で整えていけば十分です。

面接で聞かれること、答えられないと落ちること

自社開発企業の技術面接では、ポートフォリオが動くかどうかだけでなく、なぜその実装にしたのかが掘り下げられます。

なぜこのフレームワークを選んだのか、状態管理はどう設計したか、画面構成で意識したことは何か。再レンダリングが起きる条件や、パフォーマンスを意識して工夫した点、開発中に発生したエラーをどう調査したかまで聞かれることもあります。

特に注意したいのが、ポートフォリオを動かすことだけで終わらせることです。

私自身、最初の面接でuseContextを使わなかった理由を聞かれて、その場でうまく答えられなかったことがあります。感覚的には、状態を更新するたびに関係のないコンポーネントまで再レンダリングされるのが気になっていたのですが、それを言葉にする準備ができていませんでした。その日のうちに、再レンダリングが起きる条件や、状態管理をどう設計したのかを整理し直しました。ポートフォリオを作る段階から、動くかどうかだけでなく、なぜその設計にしたのかまで確認しておいたほうがいいです。

面接前には、自分のコードを初めて見る人へ説明するつもりで、一つずつ確認してみてください。なぜこの処理を入れたのか、別の書き方では何が変わるのか、この設計にしたことで何が良くなったのか。この3つに声を出して答えられるかどうかを、事前に試しておくといいです。

ここまで説明できれば、ポートフォリオは単なる成果物ではなく、自分の技術的な考え方を伝える材料になります。

分からない質問をされたときは、無理に答えを作る必要もありません。知識が不足していることを認めたうえで、どのように調べて理解するかを伝えるほうが、曖昧な回答を続けるより誠実です。

転職理由は不満ではなく、次に求める経験につなげる

案件が選べない、希望する技術に触れられない、現場が変わるたびに経験がリセットされるといった不満が、転職を考えるきっかけになることはあります。

ただし、面接でそのまま話すと、現職への不満だけが残ってしまいます。

転職理由は、「現職で何が課題だったのか」から「次の環境で何を実現したいのか」までつなげてください。

次のように整理すると、転職の目的が伝わりやすくなります。

現職が嫌だから辞めるという話だけで終わらず、これまでの経験を次の環境でどう伸ばしたいのかまで話せるようにしておきましょう。

脱出のタイミングと退職の実務

①経験年数によって見られるポイントは変わる

自社開発企業への転職では、経験年数によって選考で確認されやすいポイントが変わります。私が求人票を見比べていたときも、年次によって求められる内容がはっきり違うと感じていました。

私自身も、SESを3年半、受託開発を2年経験してから自社開発企業に転職しました。合計5年半という数字そのものよりも、SES時代に感じていた技術の分散を、受託開発で意識的に補ってから動いたことのほうが、選考では効いた実感があります。

転職市場で重視されるのは、経験年数そのものより、その期間に何を経験したかです。同じ年数でも、担当範囲を少しずつ広げてきた人と、同じ作業を繰り返してきた人では、書類の通過率がまったく違ってきます。

そのため、「3年経つまで転職しない」「5年経てば大丈夫」と年数だけで判断する必要はありません。自社開発企業の求人を確認し、自分に足りない経験が何なのかを把握したうえで、転職時期を決めていきます。

②「3年働かないと辞められない」という決まりはない

SESでは、同じ現場に3年以上いられない、3年働かないと次へ行けないといった話を耳にすることがあります。

ここは、SESと労働者派遣を混同しないように注意が必要です。

労働者派遣には、派遣先の同一の組織単位に同じ派遣労働者を派遣できる期間について、原則3年という期間制限があります。これは派遣労働に関するルールであり、SESエンジニアが3年間働かなければ転職できないという意味ではありません。厚生労働省も、同一の組織単位への派遣について原則3年の期間制限を設けていると説明しています（出典：厚生労働省「平成27年労働者派遣法改正法の概要」）。

SESで働いている人が転職する際は、自分の雇用契約や就業形態を確認したうえで考える必要があります。

③契約途中でも退職できるという前提を知っておく

客先との契約期間が残っているから退職できないと考えている人もいます。

ただし、客先と自社との契約と、エンジニア本人と勤務先との労働契約は別のものです。

期間の定めのない雇用契約を結んでいる場合、民法第627条第1項では、退職の申し入れから2週間を経過することで雇用契約を終了できるとされています（出典：e-Gov法令検索「民法」）。

有期雇用契約の場合などは扱いが異なることがあります。就業規則や引き継ぎ、有給休暇の消化についても、実務上あわせて確認しておいたほうがいいでしょう。

法律上の扱いだけを見て強引に退職するのではなく、自分の雇用契約や就業規則を確認し、必要に応じて公的な相談窓口や専門家へ相談してください。

転職活動は、基本的に先に次の勤務先を決めてから退職手続きを進めるほうが安全です。

先に退職すると収入が途切れ、転職活動に焦りが生まれます。結果として「SESから抜けられるならどこでもいい」という判断になれば、転職先で別の問題を抱えることになりかねません。

転職エージェントは「登録するだけ」で終わらせない

転職エージェントを利用するなら、とりあえず登録して求人を送ってもらうという使い方だけではもったいありません。

自社開発企業への転職を目指す場合は、エージェント側がどのような求人を持っているのか、自分の経験をどう評価しているのかまで確認します。

私が転職活動をしていたときも、初回の面談で意識して聞くようにしていた質問がいくつかありました。自社開発・自社プロダクト企業の求人をどの程度扱っているか、紹介される求人は自社内開発なのか客先常駐を含むのか、そして現在の経験で応募する場合に足りない経験は何か。この3つを聞くだけでも、そのエージェントが自社開発への転職をどこまで支援できるのかは、だいたい見えてきます。エンジニア向けのスカウト型サービスに登録しておくと、自社開発企業から実際にどう評価されるのかを、面談の前段階でつかめることもあります。

特に確認したいのは、自社開発に行きたいと伝えたあとに、どのような求人が紹介されるかです。

SES求人ばかり紹介される場合は、なぜその求人を勧めるのかを確認してください。自社開発求人の取り扱いが少ないのか、現在の経験では書類通過が難しいと判断されているのかによって、次に取るべき行動は変わってきます。1社に相談しただけで判断がつかない場合は、複数のエージェントに同じ質問をぶつけて比較するのも一つの方法です。

求人票を見るときも、自社開発という言葉だけで判断しないことが大切です。自社プロダクトの事業内容やエンジニア組織の規模はもちろん、自社内開発と受託・客先常駐の割合、使用している言語やインフラ、担当する開発工程、エンジニアの評価方法まで、できる範囲で確認しておきます。

ここまで確認しておけば、自社開発企業に転職したのに想像していた仕事と違ったというミスマッチは、かなり減らせるはずです。

まとめ

「SESから脱出したい」と感じたとき、最初にやることは退職ではありません。

まず、自社開発企業へ転職して何を経験したいのかを決めます。そのうえで、これまでの案件を棚卸しし、職務経歴書とポートフォリオで自分の経験を伝えられる状態にしていきます。

今日から始めるなら、次の3つです。

• これまでの案件を振り返り、課題・行動・結果の順番で経験を整理する
• 志望する求人で使われている技術を参考に、説明できるポートフォリオを作る
• 転職エージェントや求人票を使って、自分に足りない経験と応募先の条件を確認する

SESで経験した案件が多く、技術が分散していることは、それだけで転職のマイナス材料になるわけではありません。

異なる現場に適応してきた経験、チームや顧客と調整してきた経験、障害対応や業務改善に取り組んだ経験など、掘り下げれば転職先でも活かせる材料があります。

「SESを辞めたい」で止めず、「辞めたあとに何を積み上げたいのか」まで決めておくこと。それが、自社開発企業への転職準備を始める最初の一歩です。