← 透明性メディア
キャリア・働き方

SESから自社開発転職で
後悔しない3条件

野沢営業アシスタント

Heyday営業サポート野沢が転職相談を何十件も支援してきた現場視点で執筆

この記事でわかること

  • SESから自社開発転職で後悔する人の共通点は『自社開発ラベル』を確認しなかったこと
  • 転職できない人の主要因:チーム開発経験がない・GitHubに実績がない・ポートフォリオが業務コードのみ
  • 年収は『上がる人・下がる人』両方いる。SES単価基準でなく市場全体と比較することが重要
  • 後悔しない3条件:技術スタック確認・単価の市場比較・開発プロセスへの適応力確認
  • 今すぐ転職しなくていい人もいる。SESのまま自社開発スキルを積む選択肢がある

この記事の対象: SESに在籍しており自社開発転職を検討しているエンジニア(20代後半〜30代前半)

この記事にはHeydayの独自データが含まれています

SESから自社開発に転職して後悔した人の話は、「自社開発だと聞いていた」というところから始まる。

入社してみたら、自社開発という名前の保守専任だった。最新技術を使うと聞いたのに、実態は10年前のフレームワークだった。コードレビューのない環境に、チーム開発の経験がない自分が入ってしまった——こういう話は珍しくない。

営業サポートとして転職相談を何十件も受けてきた。「自社開発に行きたい」という相談は多い。しかし、「自社開発なら絶対に良くなる」という前提で動いている人ほど、後から後悔しやすい傾向がある。

この記事では、転職できる人・できない人の判断軸、年収変化の実態、後悔した人のパターン、そして後悔しない3条件を正直に解説する。SESから自社開発転職を検討しているなら、動く前に読んでほしい。


目次

  1. SESから自社開発へ転職できる人・できない人 — 判断軸を整理する
  2. SESから自社開発に転職した人の年収はどう変わったか
  3. 後悔した人に共通する3つのパターン
  4. SESから自社開発に転職して後悔しない3条件
  5. SESのまま自社開発スキルを積む選択肢もある
  6. SESから自社開発への転職活動の進め方
  7. まとめ

SESから自社開発へ転職できる人・できない人 — 判断軸を整理する

多くの転職記事は「SESから自社開発に転職できる」という前提で書かれている。できない人の話はほとんど出てこない。しかしHeydayへの転職相談ベースで見ると、「自社開発に行きたい」と言う人全員が転職できているわけではない。

正直に書く。現状のスキルセットによっては、自社開発転職に必要な水準を満たしていないケースがある。

転職できない人に多いパターン

最も多いのは、チーム開発経験がないケースだ。SES環境では、案件によって開発プロセスがバラバラだ。Gitを個人で使っているが、プルリクエストを出してコードレビューを受けた経験がほとんどない——これは自社開発企業の面接で明確に不利になる。

自社開発企業が欲しいのは「コードが書ける人」だけではなく、「チームの開発フローに入れる人」だ。プルリクエスト・コードレビュー・CI/CDの文化に慣れていない人材は、即戦力として評価されにくい。

次に多いのが、GitHubに実績がないケースだ。業務コードは公開できない。しかし、個人プロジェクト・OSSへのコントリビューション・ポートフォリオ用のリポジトリが一切ない状態では、「業務外でも技術と向き合っている」という意欲を示せない。

Heydayへの相談で自社開発転職に苦戦しているケースを見ると、以下の共通点がある。

状態転職難易度
GitHubにポートフォリオ3本以上・コードレビュー経験あり比較的スムーズ
GitHubはあるが個人学習コードのみ・業務Gitは使用企業・ポジションを選べば可能
GitHub実績なし・コードレビュー経験なし苦戦する可能性が高い

Heydayの相談データを匿名化して振り返ると、上記の「GitHubに実績なし・コードレビュー経験なし」の状態で自社開発転職を目指した方のうち、内定取得まで6ヶ月以上かかったケースが複数あった。期間が短ければよい・長ければ悪いという話ではないが、準備の必要性を示している。

スキル要件の実態

自社開発企業が面接で見るポイントは、経験年数よりも実際の開発プロセスへの理解度だ。

具体的に言うと、「Agile・スクラム・カンバン等のワークフローを経験しているか」「コードレビューの視点でコードを書けるか」「CI/CDの概念を理解し、自分でパイプラインを組んだことがあるか」——こうした実務経験が問われる。

これはSES出身者が不利という話ではない。SES環境でもモダンな開発フローを経験できる案件はある。問題は、同じSES歴5年でも「チーム開発文化がある現場を経験したかどうか」で、転職活動の難易度が大きく変わる点だ。


SESから自社開発に転職した人の年収はどう変わったか

「自社開発に転職すれば年収が上がる」——この認識は半分正しく、半分は誤解だ。

Heydayが関わった事例では、SES正社員から自社開発正社員に転職した後の年収変化は大きく3パターンに分かれる。

年収が上がるケース

自社開発企業の年収が高いケースは、主に以下の条件が重なった時だ。

  • SES時代の商流が2次・3次以下で、マージンが大きく取られていた
  • 転職先がスタートアップ〜中堅のプロダクト企業で、技術スタックへの市場評価が高い
  • React・TypeScript・Go・Python等のニーズが高い言語のスキルがある

この場合、年収換算で+100〜200万円の上昇が起きているケースがある。ただしこれは「SES側のマージン構造から抜け出した」効果が大きく、転職先が特別に高給というより、元の水準が抑えられていたという側面がある。

年収が下がるケース

下がるケースのほうが、相談現場では意外と多い印象だ。

自社開発企業の年収テーブルは、エンジニア職全体の市場水準に基づいて設定されている。SES案件の月単価(60〜90万円台)を基準にしていると、自社開発企業の正社員年収が低く見えることがある。

たとえば、SESで月単価75万円(年換算900万円相当)の案件に参画していたエンジニアが、自社開発企業に転職すると年収550〜650万円になる——というケースがある。これはSES会社のマージン分も含めた単価と、正社員年収を単純比較しているための錯覚だ。

社会保険・賞与込みの実効比較が重要

比較する際に必ず考慮してほしいのが、社会保険・賞与・福利厚生の差だ。

SES正社員の場合、社会保険はSES会社が半分負担している。フリーランス的な単価比較をするのではなく、同じ正社員同士で年収・賞与・福利厚生を比較することが正確な判断につながる。

「SES単価で年収を語る」と、転職先の年収が実際より低く見えがちだ。転職を検討する前に、自分の現在の実効年収と転職先の提示年収を同じ基準で比較することが前提条件だ。自分の市場単価を把握するには、Heydayの単価診断ツールが役に立つ。


後悔した人に共通する3つのパターン

SESから自社開発転職後に後悔している人の話は、共通のパターンに収束する。後悔の構造を知っておくと、同じ失敗を避けやすくなる。

SES転職後悔の全体像はSES転職して後悔した3つの理由で整理しているが、自社開発転職特有のパターンを3つ追加で解説する。

後悔パターン1: スタックが合わなかった(「自社開発」でも古い技術の保守だった)

「自社開発」という言葉は、実態を保証しない。自社プロダクトを持っている企業であっても、エンジニアが担当する業務が「10年前に構築したシステムの保守・運用」というケースは珍しくない。

あるCさん(Java・経験6年・30代前半)のケースでは、「自社開発エンジニア」として転職したが、実際の業務の大部分がStruts1系の保守だった。「モダンな開発環境で働きたい」という動機で転職したが、結果として前のSES現場より技術スタックが古い環境になった。

面接段階で「どのフレームワークを主に使っているか」「新規開発の割合は何割か」「古いコードのリファクタリング計画はあるか」——このあたりを聞いていれば回避できた後悔だ。

後悔パターン2: 裁量ゼロの受託紛いだった(名前だけ「自社開発」)

名目上は自社開発企業だが、実態は特定の大手企業から発注される仕事だけをこなしている——いわゆる「受託紛い」の形態もある。

自社のプロダクトではなく、特定クライアントの要件に従うだけでは、エンジニアとして「プロダクト思考」を身につけることが難しい。「要件をもらって実装するだけ」という構造はSES時代と変わらないか、むしろ選択肢が少ない分だけ制約が増えているケースもある。

見極め方は「自社で意思決定した機能はどれか」「ロードマップを誰が決めているか」を面接で確認することだ。これを答えられない面接担当は、プロダクト開発の裁量が薄い可能性がある。

後悔パターン3: チーム開発・コードレビュー文化に慣れていなかった

スキルが十分あっても、開発文化への適応に苦労するケースがある。

SES環境では、コードレビューなしで開発を進める現場も多い。自社開発企業に転職すると、全コードにレビューが入り、品質基準を学びながら開発スピードを維持することが求められる。

「コードを書くこと」と「チームのコードレビュー文化に入ること」は別のスキルだ。後者に慣れていない状態で転職すると、最初の3〜6ヶ月を消耗しやすい。これは克服できる課題だが、「自社開発に入れば楽になる」という期待と現実のギャップが大きいと後悔につながる。


SESから自社開発に転職して後悔しない3条件(核心コンテンツ)

後悔した人のパターンを踏まえると、転職前に確認すべき条件が3つに絞れる。この3点を確認してから動くかどうかで、後悔の確率は大きく変わる。

条件1: 「自社開発かどうか」より「技術スタックが合うか」を先に確認する

「自社開発」というラベルより、使っている技術スタックと自分のスキルの一致度が重要だ。

確認すべき具体的な質問:

  • 現在のバックエンド/フロントエンドの主要フレームワークは何か
  • 直近1年で新規開発に当てている工数の割合はどのくらいか
  • 古いシステムのリプレイス計画はあるか、その担当にアサインされる可能性はあるか

これらに具体的に答えられる会社なら、技術スタックの実態を把握した上で判断できる。答えが曖昧な場合は「聞けなかった」ではなく、実態が不明確だと認識して判断材料にしてほしい。

条件2: 単価(年収)をSES基準でなくエンジニア市場全体で比較してから判断する

SES案件の月単価と自社開発企業の正社員年収を単純に比較すると、ほぼ必ず自社開発企業のほうが低く見える。これは比較の基準が違うからだ。

正しい比較の手順:

  1. 自分の現在の実効年収(額面年収+賞与+各種手当)を計算する
  2. 転職先の年収テーブルと賞与・福利厚生を含めた実効年収を計算する
  3. 同スキル・同経験年数のエンジニアの市場年収レンジと比較する

SES単価を基準にするのではなく、「エンジニア市場全体でこのスキルセットの年収はいくらか」という視点で評価することが重要だ。自分の市場単価を把握するために、Heydayの単価診断を活用してほしい。

条件3: 「転職できるスキルか」より「自社開発の開発プロセスに入れるスキルか」で評価する

「このスキルで転職活動を通過できるか」という視点ではなく、「入社後、自社開発の開発フローにスムーズに入れるか」という視点で自己評価してほしい。

面接を通過することと、入社後にパフォーマンスを出すことは別の話だ。面接では過去の経験を語れば通過できても、入社後にプルリクエスト・コードレビュー・スプリント計画・振り返りといった開発フローに適応できないと、3〜6ヶ月で苦しくなる。

転職前チェック:

  • Gitのブランチ戦略(feature branch・git-flow等)を実務で使ったことがあるか
  • コードレビューをレビュイー・レビュワー両方の立場で経験したことがあるか
  • スプリント計画・バーンダウンチャート等のアジャイル指標を業務で見たことがあるか

1つも経験がない場合、まずSES現場でこれらを経験するか、個人プロジェクトで体験してから転職活動に入ることを勧める。


SESのまま自社開発スキルを積む選択肢もある

多くの転職記事が見落としている視点を書く。今すぐ自社開発転職をしなくていい人が、一定数いる。

以下のいずれかに当てはまる場合、今すぐの転職より先にスキルを積む戦略のほうが合理的かもしれない。

  • 現案件の技術スタックがモダンで、チーム開発文化もある
  • GitHubポートフォリオが十分でなく、転職活動を始めても通過率が低い可能性がある
  • 転職後の年収が現状を下回ることが試算でわかっている
  • 副業やOSSへの貢献でスキルを積みつつ市場評価を高める余地がある

SES現場でGitHub・OSSへのコントリビューション・副業での個人開発を並走させれば、1〜2年で転職活動の戦力を整えられるケースがある。「今すぐ行動しない」ことが最善の選択である場合もある。

転職のタイミング判断についてはSES転職タイミングの見極め方でも詳しく解説している。焦りで動いて後悔するより、タイミングを計って動く方が長期的には有利だ。

現案件でスキルを積む具体的な方法

今の現場で自社開発企業転職に向けたスキルを積む方法として、実績として積みやすいのは以下だ。

  • 個人プロジェクトをGitHubで公開する(完成度より継続的なコミットの記録を残す)
  • OSSのバグ修正や日本語ドキュメントのPRを1本でも出しておく
  • 技術ブログやZennでの発信を週1本のペースで続ける

これらは業務外の時間を使うが、転職活動での書類選考・面接評価を大きく変える。「業務でしか技術に触れていない」という状態は、自社開発企業の面接では弱くなりやすい。


SESから自社開発への転職活動の進め方

具体的に動き始める際の手順を整理する。

ポートフォリオの準備

自社開発企業の書類選考で最も重視されるのはGitHubのポートフォリオだ。最低限として、以下を用意してほしい。

  • README.md に技術スタック・動かし方・工夫した点を書いたリポジトリを2〜3本
  • アプリケーションとして動作するもの(学習用の写経ではなく、自分で考えた機能がある)
  • コミット履歴から「継続的に開発した」ことが読み取れる構成

1ヶ月で作り上げた「完成品」より、3〜6ヶ月かけてコミットが積まれたリポジトリのほうが評価されやすい。

面接対策

自社開発企業の面接では、コーディングテスト・技術課題・システム設計の質問が含まれることが多い。SES転職の面接とはかなり異なる。

準備として有効なのは:

  • LeetCodeやAtCoderでアルゴリズム問題を週3問解く習慣
  • 「このシステムをどう設計するか」という設計質問への回答フレームワークを持つ
  • 「チームでの開発で苦労したこと・工夫したこと」を具体的に語れるエピソードの準備

SES時代の業務経験を「チームの文脈で語る」訓練をしておくことが重要だ。

タイムライン

転職活動の開始から内定まで、自社開発企業向けであれば3〜5ヶ月を目安にしてほしい。SES転職の2〜3ヶ月より長くなる理由は、書類選考・コーディングテスト・複数回の技術面接というステップが加わるからだ。

現案件の終了タイミングに合わせてスケジュールを組むことが重要だ。詳細なスケジュール設計の考え方はSES転職タイミングの見極め方で解説している。

転職活動の相談はキャリア相談から気軽に連絡してほしい。自社開発転職に向けた準備状況を確認した上で、具体的なアドバイスをする。


まとめ

SESから自社開発転職で後悔しないための3条件を改めて整理する。

  1. 「自社開発かどうか」より「技術スタックが合うか」を先に確認する — 自社開発ラベルより実際のスタックと新規開発比率を確認することが先だ。
  2. 単価(年収)をSES基準でなくエンジニア市場全体で比較してから判断する — SES月単価との比較は間違いの元だ。同スキル・同経験年数の市場年収を基準にしてほしい。
  3. 「転職できるスキルか」より「開発プロセスに入れるスキルか」で評価する — 面接通過ではなく、入社後の適応力を基準にスキルを評価することが後悔を防ぐ。

30代での自社開発転職についてはSES30代転職の現実でも詳しく解説している。年齢固有の判断軸が参考になるはずだ。

また、SES・自社開発・受託の違いについて改めて整理したい場合はSES・自社開発・受託開発の違いを正直に解説を参照してほしい。

まず必要なのは「自分の現在の市場単価を把握する」ことだ。今の単価が市場水準と比べてどのポジションにあるかを把握した上で、転職すべきかどうかの判断ができる。

転職の判断を一人で抱えるより、現場の視点から一緒に整理するほうが早い。キャリア相談に気軽に相談してほしい。

案件例を見てみる

技術スタック・単価帯・勤務形態がわかる具体的な案件情報

この記事の著者

野沢

Heyday株式会社 営業アシスタント

Heyday営業サポート野沢が転職相談を何十件も支援してきた現場視点で執筆

Heyday株式会社 営業アシスタント。SES業界8年。エンジニアの現場入り支援・契約実務・待機期間のフォローを担当する。

シェア:XB!

次に読む