SESから自社開発へ転職すると年収は132万円変わる｜選考で問われる本当の実力

「SESから自社開発へ」は、エンジニアのキャリアで最もよく語られる経路です。年収が上がるケースは実際に多いのですが、条件があります。

年収差はどのくらいか

実務3〜5年／東京勤務／スキル中位という条件で、企業タイプだけを動かした推定です。

SES（中央値446万円）と上場・大手（578万円）で 132万円。メガベンチャー・外資（656万円）まで見れば 210万円 の差があります。

同じ人が同じ実力のまま移動しても、この幅の分だけ動く可能性があります。経験年数で言えば、3〜5年から6〜9年へ進むより大きい差です。

差の正体は、実力ではなく構造

この差は、SESで働く人の実力が低いからではありません。2つの構造が効いています。

構造1：売上の作り方が違う

SESの売上は「人月 × 単価」でほぼ決まります。一人が生む売上に構造的な上限があるため、給与にも上限が生まれます。

単価80万円の現場に立っている人に、月80万円の給与は出せません。会社の利益、営業経費、待機期間の人件費が残らないからです。実際には単価の6〜7割程度が給与の上限になります。

自社サービスの売上は人数に比例しません。ユーザーが10倍になっても開発チームが10倍になるわけではないため、一人あたりの利益が大きく、給与に回せる原資が増えます。

構造2：中間マージン

SESでは、発注元から自社までに何社挟まっているかが直接効きます。1社挟まるごとに20〜30%が抜けるため、3次請けなら発注元が出した金額の半分程度しか自社に届きません。

参考として、フリーランス市場の月額平均単価は 78.3万円/月 です。同じ現場に3次請けで入っている場合、この金額と自分の給与の差の多くが、中間マージンとして抜けています。

選考で落ちる3つの弱点

一方で、選考の基準は上がります。SESの現場では評価されていたのに自社開発の選考で落ちる、というケースには共通点があります。

弱点1：「言われた範囲を実装する」以外の経験が薄い

常駐先では、仕様が決まったうえで作業が振られることが多くなります。その環境が長いと、仕様の曖昧さを自分で潰した経験が積みにくい。

自社開発の選考では「なぜその設計にしたのか」を聞かれます。判断した経験がないと、ここで答えが出ません。

対策：いまの現場でも、仕様の穴を見つけて確認・提案した経験は必ずあるはずです。「Aと解釈すると◯◯が壊れるので、Bで実装すべきだと提案した」という粒度で棚卸ししておきます。

弱点2：コードを読む力が問われる

自社開発は既存コードの改修が仕事の大半です。そのため選考でも、書かせるより読ませて説明させる形が増えます。

• 「このコードは何をしていますか」
• 「ここにバグがあります。どこですか」
• 「件数が10倍になったら何が起きますか」

非同期処理の実行順序、参照の共有、計算量。こうした部分の理解が曖昧だと、この工程で止まります。

同じ3〜5年でも、スキルの水準で121万円の差がつきます（スキル別の記事）。選考はこの差を見ています。

弱点3：現場のことを説明できない

常駐先の話は守秘義務で詳しく話せないことがありますが、「何も話せません」で終わると評価しようがありません。

技術的な判断の部分だけを抽象化して話す準備が要ります。「金融系の基幹システム」ではなく「1日数百万件のトランザクションを扱うバッチ処理で、リトライ設計を担当した」という粒度なら、顧客名を出さずに中身が伝わります。

移る前の順番

1. いまの実力が市場のどの水準にあるかを確かめる — 選考で問われるのは年数ではなく読む力です
2. 足りない部分を埋める — 特に言語の土台の理解と、計算量の判断
3. 経験を判断の粒度で棚卸しする — 「実装した」ではなく「こう判断した」で書き直す
4. 商流を確認しながら動く — 自社開発でなくても、商流の浅い受託なら差は縮みます

1つ目を飛ばして応募すると、落ちた理由が分からないまま消耗します。

「自社開発なら何でもいい」ではない

自社開発という言葉には幅があります。上場企業の主力プロダクトも、社員10名のスタートアップの新規事業も、どちらも自社開発です。

上の表でも、上場・大手（578万円）とスタートアップ（525万円）で53万円の差があります。スタートアップはストックオプションで補う設計になっていることが多く、現金だけの比較では低く見えます。

見るべきなのは「自社開発かどうか」ではなく、事業が利益を出しているか、給与テーブルに上があるかです。

中間の選択肢もある

いきなり自社開発に届かない場合、段階を踏む手もあります。

• 商流の浅いSES／受託に移る — 同じ働き方でもマージンが減る分だけ上がる
• SES企業の中でも自社開発部門を持つところへ — 実績を作りながら移る
• 元請けに近い受託開発 — 上流工程の経験が積める

上の表で言えば、SES（446万円）から中小の受託・SIer（499万円）へ移るだけでも53万円の差があります。

SES経験を自社開発向けに翻訳する

SESでの仕事を「指示された開発」とだけ説明すると、選考側はどこまで任せられるかを判断できません。顧客から来た要望に曖昧さがあった場面、納期と品質が衝突した場面、既存仕様と矛盾した場面を思い出し、自分がどう確認し、何を提案したかを書きます。契約上の決裁権がなくても、判断材料を作った経験は示せます。

たとえば、仕様の不足を見つけて質問票を作り、関係者の認識を揃えた経験は、プロダクト開発の要件整理にもつながります。障害の原因を調べて恒久対応を提案した経験は、運用を含めて品質へ責任を持った実績です。顧客名や機密の数字を出さなくても、問題、行動、結果の順で説明できます。

面接では「自社サービスをやりたい」という希望だけで終わらせず、SESで得た力を次の会社の課題へ接続します。複数組織の進め方を見たこと、制約の違う現場へ適応したこと、短期間で業務知識を学んだことも強みです。環境への不満ではなく、持ち運べる経験と今後広げたい責任を話します。

移る前に現職で作れる実績

転職を決めた後でも、現在の案件で準備できることはあります。小さな改善の提案、レビュー基準の文書化、障害対応の振り返りなど、担当範囲の一歩外にある仕事を引き取ります。実装量を増やすより、誰かの判断や作業を減らした経験のほうが、上の役割を任せる根拠になります。

顧客との直接の会話が制限されているなら、自社のリーダーを通じて確認事項や提案を出し、その過程を記録します。権限がないことと、考えなくてよいことは別です。自分ならどう判断するかを用意し、決裁者の結論との差を振り返るだけでも、次に同じ場面を任されたときの精度が上がります。

ただし、役割を広げる機会が構造的にない場合、長く待ち続ける必要はありません。三か月など期限を決め、経験を作れなければ応募を進めます。現職への貢献と転職準備を対立させず、今の環境で得られる最後の材料を持って次へ進む考え方です。

入社後のギャップを避ける

自社開発企業でも、すべてのエンジニアが企画から関われるわけではありません。会社が自社サービスを持っていても、配属チームが保守だけを担当することや、仕様が事業側から完成形で渡されることがあります。面接では、配属予定チームが直近で自ら決めたことを具体的に聞きます。

「エンジニアの裁量が大きい」という説明には、誰が優先順位を決め、技術的負債への時間をどう確保し、リリース後の数値を誰が見るかを重ねます。実例が返れば仕事の流れを想像できます。理念だけで具体例がない場合は、担当者やチームによって運用が違う可能性を考えます。

また、自社開発では利用者や事業の結果まで追える一方、正解が決まっていない難しさがあります。顧客から明確な要件が来る環境より、自分で問いを作る場面が増えます。その働き方を望んでいるかを考え、単に常駐を離れたいという理由だけで選ばないことが、次の不満を防ぎます。

移った後の最初の半年

入社直後は、技術力を示すより、プロダクトの判断基準を理解することが先です。利用者、収益、障害時の影響、開発速度のどれを優先する会社なのかを、過去の意思決定から学びます。背景を知らずに正論だけを提案すると、技術的には正しくても事業に合わないことがあります。

最初の改善は、既存メンバーが困っていて、影響範囲を測れる小さなものを選びます。大規模な刷新を提案するより、手作業を減らす、監視を補う、判断の記録を残すといった改善で信頼を作るほうが、その後に広い責任を任されやすくなります。

半年後には、入社前に広げたかった責任を実際に持てているかを確認します。仕様や優先順位へ関われているか、成果を利用者の反応まで追えているか、次の等級に必要な行動が分かるかを見ます。会社の種類を変えただけで満足せず、転職の目的が仕事の中で実現したかを検証します。

もし期待した範囲を任されていなければ、すぐに会社選びの失敗と決めず、上司と役割の認識を合わせます。入社直後に信頼を作る期間が必要なのか、配属チームの構造上その役割が存在しないのかを分けるためです。期限と期待を具体化しても状況が変わらないなら、異動を含む次の判断材料になります。

SESから移ったという経歴より、移った後に何を決められるようになったかが次の評価を作ります。転職前後の変化を記録し、仕事の種類ではなく責任の広がりでキャリアを説明できる状態を目指してください。

まとめ

• SESと自社開発の132万円の差の正体は、ビジネスモデルと中間マージン
• 選考では書く力より読む力が問われる。ここで落ちる人が多い
• 「実装した」ではなく「こう判断した」の粒度で経験を棚卸しする
• 「自社開発かどうか」より、事業の利益と給与テーブルの上限を見る