SESから自社開発に転職するには？難しい理由と受かるための準備をロードマップで解説

「SESから自社開発に行きたいけど、自分でも本当に通用するのか不安」
「客先常駐では経験できないことが多くて、選考で不利なのではと思っている」
こう感じているSESエンジニアは少なくありません。

結論から言うと、SESから自社開発への転職は十分可能です。 ただし、“SES経験があるだけ”では受かりにくく、プロダクト志向・学習実績・GitHubやポートフォリオでの補強が必要です。

この記事では、SESから自社開発への転職が難しいと言われる理由、逆にSES経験が評価されるポイント、受かるための具体的な準備手順を整理します。 「自分は今すぐ動くべきか」「何から始めるべきか」まで判断できる内容にしています。

SESから自社開発への転職は可能。ただし“準備なし”だと厳しい

まず押さえたいのは、SESから自社開発に転職できる人は普通にいるということです。 その一方で、落ち続ける人がいるのも事実です。

この差は、単純な能力差というより、自社開発企業が見ているポイントを理解して準備しているかどうかで決まることが多いです。

自社開発企業は、単に開発経験年数だけを見ているわけではありません。 特に見られやすいのは、次のような点です。

• プロダクトを良くする視点があるか
• 指示待ちではなく、自分で考えて動けるか
• モダンな技術や開発文化にキャッチアップできるか
• GitHubやポートフォリオで実力を確認できるか
• チーム開発に馴染めそうか

つまり、SESから自社開発への転職で重要なのは、「SESだったこと」そのものよりも、「SES経験をどう変換して見せるか」です。

なぜSESから自社開発は難しいと言われるのか

1. プロジェクト視点とプロダクト視点が違うから

SESは、顧客先のプロジェクトを期間内に進める働き方になりやすいです。 一方、自社開発は自社サービスや自社プロダクトを継続的に改善していく働き方です。

この違いにより、自社開発では次のような視点が求められます。

• この機能は本当にユーザーに必要か
• どう改善すれば継続率や使いやすさが上がるか
• リリース後にどう運用・改善するか

SESでは案件単位で仕事が区切られやすいため、作って終わりではなく、育て続ける視点を面接で示せないと弱くなります。

2. 技術スタックにギャップがあることが多いから

SESでは、配属先によって触れる技術が大きく変わります。 そのため、業務経験があっても自社開発企業でよく見られる技術とズレていることがあります。

よくあるギャップは以下です。

• JavaやC#中心で、ReactやTypeScriptの経験が薄い
• オンプレ中心で、AWSやDockerの経験がない
• テストや運用はあるが、CI/CDの経験が薄い
• 保守案件中心で、新規開発の経験が少ない

これは不利ではありますが、ここで大事なのは業務経験がない技術を個人開発や学習実績で補えるかです。

3. 主体性を見せにくいから

SESでは、配属先の方針や役割の範囲が決まっていることが多く、評価も「指示されたことを正確にこなす」方向に寄りやすいです。

一方、自社開発では次のような姿勢が重視されます。

• 課題を自分で見つける
• 改善案を出す
• 必要なら周囲を巻き込む
• プロダクトに対して当事者意識を持つ

そのため、面接で「言われたことはやれます」だけだと弱いです。 自分で考えて改善した経験を言語化できるかが重要です。

逆に、SES経験が自社開発で評価されるポイント

「SES経験しかないから厳しい」と思い込みすぎる必要はありません。 実際には、SES経験の中にも自社開発で評価される要素はかなりあります。

1. 環境適応力がある

SESは現場ごとに開発体制、ドキュメント文化、人間関係、ツールが違います。 その中で動いてきた経験は、環境適応力として評価されやすいです。

2. 顧客視点や調整力がある

顧客折衝、要件調整、認識合わせ、進捗報告などの経験は、自社開発でも無駄になりません。 むしろ、プロダクトマネージャーやデザイナー、営業と連携する場面で活きます。

3. 基本的な開発プロセスを理解している

要件定義、設計、実装、テスト、運用保守のどこかを経験しているなら、それは十分な土台です。 自社開発企業が見ているのは、完璧な経験よりも、その経験をどう再現性ある強みに変えているかです。

SESから自社開発に行きやすい人の特徴

SESから自社開発への転職で通りやすい人には、共通点があります。

学習履歴を見せられる人

• GitHubに個人開発を置いている
• READMEを書いている
• 学習内容をZennやQiitaに残している
• 未経験技術でも実際に手を動かしている

SES経験を自社開発向けに言い換えられる人

例えば、ただ「テストを担当しました」と書くのではなく、次のように変換できます。

• 品質担保の観点で不具合傾向を把握し、再発防止に貢献した
• 保守運用経験を通じて、リリース後を見据えた実装の重要性を理解している
• 顧客要望の整理や仕様確認を通じて、要件の曖昧さを詰める力がある

志望先を広げすぎない人

最初から超人気の大手メガベンチャーや、即戦力要求が強い企業だけに絞ると厳しくなりやすいです。 まずは以下のような企業も含めて見る方が現実的です。

• SES出身者が多い会社
• 若手育成の文化がある会社
• Web系だがポテンシャル採用もしている会社
• 自社サービスを持つ中小〜成長企業

SESから自社開発に転職するためのロードマップ

ここからは、実際にどう進めるべきかを順番に整理します。

ステップ1：まずは「なぜ自社開発に行きたいのか」を明確にする

ここが曖昧だと、学習も応募先選びもブレます。

整理すべきなのは、次の3点です。

• なぜ今のSES環境を変えたいのか
• 自社開発で何を得たいのか
• どんな会社なら納得できるのか

例えば、動機は以下のように分かれます。

• 客先常駐ではなく自社内で腰を据えて働きたい
• ユーザーに近い開発がしたい
• 技術選定や改善提案にも関わりたい
• 将来的にテックリードやPdM寄りにも広げたい

ここで大事なのは、「SESが嫌だから」だけで終わらせないことです。 それだけだと逃避に見えます。

“自社開発で何をしたいか”まで言える状態にしておく必要があります。

ステップ2：今の経験を棚卸しして、足りないものを特定する

次にやるべきは、感覚ではなく事実ベースで現状を整理することです。

棚卸しする項目

• 経験した言語、FW、DB
• 担当した工程
• チーム人数、役割
• 顧客折衝の有無
• 改善提案や主体的に動いた経験
• 運用保守や障害対応の経験
• Git、レビュー、チケット管理ツールの経験

足りないことが多い項目

SESから自社開発を狙う場合、特に不足しやすいのは以下です。

• モダンなWeb技術の実務経験
• GitHubで見せられる成果物
• 自分で設計して作った経験
• コードレビュー文化への理解
• テスト自動化やCI/CDの理解

この段階で、「自分には何もない」と考える必要はありません。 正しくは、業務経験だけでは見せきれない部分を補強する必要があるということです。

ステップ3：ポートフォリオを作る

SESから自社開発を目指すなら、ポートフォリオはかなり重要です。 特に、業務で書いたコードを見せにくい人ほど必要です。

どんなポートフォリオが評価されやすいか

評価されやすいのは、単に動くものではなく、次の要素があるものです。

• 誰のどんな課題を解決するのかが明確
• 使った技術の理由を説明できる
• READMEが丁寧
• デプロイされている
• GitHubの履歴がきれい
• 改善履歴や今後の課題も書いている

ありがちなNG例

• チュートリアルそのまま
• ToDoアプリを作っただけで終わる
• READMEがほぼ空
• ソースコードだけ置いてある
• なぜその機能を作ったか説明できない

テーマ選びの考え方

SES経験を活かすなら、現場で感じた不便をテーマにするのがおすすめです。

例えば、以下のような方向性があります。

• 勤怠やタスク整理を楽にする小さな業務支援ツール
• 議事録整理や進捗管理の補助ツール
• 学習ログや資格勉強を管理するWebアプリ
• 現場で感じた「こういうのがあれば便利」を形にしたサービス

派手さよりも、課題設定が自然で、自分の言葉で語れることの方が重要です。

ステップ4：GitHubを整える

自社開発企業では、GitHubの見られ方もかなり重要です。 単にリポジトリを置くだけでは弱いです。

最低限やるべきこと

• READMEに概要、機能、使用技術、工夫点を書く
• セットアップ手順を書く
• 画面キャプチャを入れる
• 今後の改善点を書く
• コミットメッセージを雑にしない
• 不要な秘密情報を含めない

採用側が見ているポイント

• 継続して手を動かしているか
• 命名や構成が極端に雑ではないか
• 学びながら改善した痕跡があるか
• チーム開発を意識した書き方になっているか

すごいOSS実績が必要というわけではありません。 大事なのは、「この人は自走して学べそうか」が伝わることです。

ステップ5：応募書類を“自社開発向け”に直す

SES向けの職務経歴書のままだと、通りにくいことがあります。

修正すべきポイント

1. 参画案件の羅列で終わらせない

案件名、期間、作業内容だけでは弱いです。

2. 成果や工夫を書く

• 何を改善したのか
• どんな課題に対応したのか
• どの部分で価値を出したのか

3. 自社開発で活きる強みに変換する

例えば、以下のように表現できます。

• 仕様の曖昧な部分を整理し、認識齟齬を減らした
• 障害対応を通じて、運用しやすい実装の重要性を学んだ
• 複数関係者との調整を行い、進行上のボトルネックを減らした

4. GitHubやポートフォリオへの導線を入れる

書類で伝わらない部分を、GitHubで補完できる状態にしておきます。

ステップ6：面接対策は「志望動機」「GitHub」「コード面接」に絞って準備する

志望動機で見られること

自社開発企業が見ているのは、次の2つです。

• なぜSESではなく自社開発なのか
• なぜこの会社なのか

ここで弱い答えは以下です。

• 客先常駐が嫌だから
• 年収を上げたいから
• 安定していそうだから

もちろん本音としてはあってもいいですが、それだけだと弱いです。

良い答えの方向性は、例えば以下です。

• ユーザーの反応を踏まえて改善を回す開発がしたい
• 開発だけでなく、プロダクトの成長に継続的に関わりたい
• 技術選定や運用改善にも関わりたい
• その会社のサービス領域や開発文化に納得感がある

GitHub・ポートフォリオで聞かれやすいこと

• なぜこのテーマにしたのか
• 技術選定の理由は何か
• どこが難しかったか
• どこを改善したいと思っているか
• もしチームで作るならどう設計を変えるか

ここで詰まると、「作っただけ」と見られやすいです。 コードの中身だけでなく、意思決定の理由を説明できるようにしておきましょう。

コード面接の対策

コード面接がある企業では、正解だけでなく思考プロセスを見られます。

対策としてやるべきことは以下です。

• 配列、文字列、ハッシュ、ソートなど基本問題を解く
• 時間計算量をざっくり説明できるようにする
• 声に出して考える練習をする
• 書いたコードを自分で説明する練習をする

上手く見せようとするより、考え方を丁寧に共有することの方が重要です。

SESから自社開発に転職するときの注意点

自社開発なら何でもいいで選ばない

「自社開発」という言葉だけで選ぶと失敗しやすいです。 実際には、かなり働き方が違います。

確認したいポイントは以下です。

• 自社サービスが主軸か
• 受託の比率が高すぎないか
• 開発文化があるか
• コードレビューがあるか
• エンジニアが改善提案しやすいか
• 技術負債とどう向き合っているか
• エンジニア評価が曖昧すぎないか

年収だけで決めない

SESから自社開発で年収が上がるケースはあります。 ただし、年収だけで決めると、入社後に苦しくなることがあります。

見るべきなのは、年収だけでなく以下です。

• 自分が伸ばしたい技術に触れられるか
• チーム文化が合うか
• プロダクトに共感できるか
• 長く経験を積める環境か

こんな状態なら転職を急いだ方がいい

次に当てはまるなら、社内改善より転職優先で考えた方がいいです。

• 現場を変えてもらえない
• 学習しても任せてもらえる業務が広がらない
• 評価基準が曖昧
• ずっと運用保守やテスト中心で、今後も変わる見込みが薄い
• 自社開発に行きたいのに、その準備を会社が全く後押ししてくれない

この場合、今の会社に残っても“時間だけが過ぎる”可能性があります。

逆に、すぐ転職しなくてもいい人

一方で、以下に当てはまるなら、今すぐ転職しなくてもよいです。

• すでに開発経験を積める現場にいる
• モダン技術に触れるチャンスがある
• 上司や会社にキャリア相談がしやすい
• 半年〜1年で経験の幅を広げられそう
• 業務外でも学習を継続できている

この場合は、焦って動くより、経験を作ってから転職した方が条件が良くなることもあります。

よくある質問

Q1. SES経験しかなくても自社開発に行けますか？

行けます。 ただし、業務経験だけで足りない部分を、個人開発やGitHubで補う意識は必要です。

Q2. 未経験の言語でも応募できますか？

可能です。 ただし「未経験です」だけでは弱いです。 学習履歴、個人開発、技術記事などでキャッチアップ力を見せる方が通りやすくなります。

Q3. ポートフォリオは必須ですか？

必須とまでは言いませんが、かなり重要です。 特にSESで見せられる成果物が少ない人ほど、あった方が有利です。

Q4. 自社開発に行けば必ず満足できますか？

必ずではありません。 プロダクトや会社によって、文化も負荷もかなり違います。 「自社開発だから良い」ではなく、会社ごとの開発体制まで確認することが大切です。

まとめ：SESから自社開発への転職は、勢いより準備で決まる

SESから自社開発への転職は、簡単ではありません。 ただ、無理でもありません。

大事なのは、以下を順番に進めることです。

1. 自社開発に行きたい理由を明確にする
2. 今の経験を棚卸しする
3. 足りない部分を個人開発で補う
4. GitHubを整える
5. 応募書類と面接を自社開発向けに直す

特にSES出身者は、経験がないのではなく、経験の見せ方が弱いだけというケースが多いです。 逆に言えば、そこを整えれば十分に勝負できます。