SESから自社開発へ転職するには？経験別の準備ロードマップ

SESから転職を考えたとき、「次は自社開発に行きたい」と思うことはありませんか。自分たちのサービスを作って、同じプロダクトを継続して改善する。なんか良さそうに見えるんですよね。

ところが求人を開くと、設計、クラウド、コードレビューと、求められる経験がずらり。「わたし、全然足りなくない……？」と、読むだけでちょっと疲れてしまうかもしれません。

でも、SES経験を全部リセットして、未経験からやり直す必要はありません。今の仕事を具体的に振り返り、応募先に対して足りないものを補うところから考えてみましょう。この記事では、テスト中心、運用保守中心、開発経験あり、顧客調整・上流寄り、経験が浅い、という5つのパターンに分けて準備を整理します。

そもそも社内SEと自社開発、どっちが合う？

まず考えたいのは、転職したあとに何をやりたいかです。ここが曖昧なままだと、求人を見ているうちに目的地が増えていきます……。

自社サービスの機能を作り、改善を続けたいなら、自社開発の開発職が一つの方向です。社内の利用者を支え、システム全体の運用・調整に関わりたいなら、社内SEも候補になります。実際の担当業務は求人ごとに確認しましょう。

まだ迷っている人は、社内SEと自社開発の仕事内容・働き方・向き不向きの比較から、自分が続けたい仕事を整理してみてください。ここから先は、自社開発のエンジニアを目指す場合の話を進めます。

「運用保守3年」を、仕事の中身まで分解する

「運用保守を3年やっています」だけでは、任されていた仕事が相手に伝わりにくいです。たとえば、その中に次のような業務が含まれていたらどうでしょう。これは経験を整理するための一例なので、自分が担当したものに置き換えてみてください。

Javaでの軽微な改修
SQLによるデータ調査
障害ログの確認と原因の切り分け
バッチ修正と修正後のテスト
利用者からの問い合わせ対応、手順書の改善

こうして並べると、コードに触れた経験や、問題を調べて直した経験が見えてきます。さらに何を作ったか、どこまで自分で判断したか、どんな技術を使ったか、何を改善したかの4つを確認すると、職務経歴書に書く材料を探しやすくなります。

改修なら、影響範囲をどう調べ、どう動作確認したかも材料になります。チームの成果と自分の担当は分けて書きましょう。

書き方に迷ったら、SES経験を職務経歴書で伝える、業務別の言い換え例も参考にできます。社内SE向けの記事ですが、作業名を具体的な役割や工夫に置き換える整理方法は、自社開発への応募書類にも使えます。

パターン1：テスト中心なら、実装を説明できる材料を作る

テストの実施が中心だった場合は、「どこまでコードを書けるか」を伝える準備をしたいところです。仕様理解、不具合の再現・報告、テストケースの作成といった経験も、実際に担当した範囲で整理しましょう。

実装を補うなら、小さなWebアプリを一つ作る方法があります。たとえば、データの登録・表示・更新・削除ができるアプリを作り、DBにつなぎ、Gitで変更を管理する。APIの利用が応募先に関係するなら、それも試す、といった進め方です。

TODOアプリを宇宙規模にする必要はないです……。「この処理は何をしているか」「不具合をどう直したか」を説明できるところまで仕上げましょう。テスト経験を活かして入力ミスがある場合も確認すると、取り組みの中身を伝えられます。

パターン2：運用保守中心なら、調査から改善までをつなげる

たとえば、障害ログとSQLの調査結果から原因を絞り、バッチを修正して、再実行の手順を見直したとします。この例なら、調査、改修、確認、運用改善という流れで説明できます。「障害対応を担当」だけで終わらせると、その途中で考えたことが見えなくなってしまいます。

実際に担当した対応を一つ選び、どこまで自分で進めたかを書き出してみてください。性能調査やリリース対応も、確認したことや判断したことを添えると具体的になります。

今の現場で範囲を広げられるなら、改修案の検討やレビューへの参加を相談するのも一案です。ログ集計の自動化やSQL調査手順の整理も、実施した内容と確認できた結果を残しておきましょう。

パターン3：開発経験があるなら、応募先との違いを具体化する

現在の経験がJava・Spring・Oracle、求人がJava・Spring Boot・AWS・Dockerだったとします。比較の一例ですが、共通する技術と未経験の部分を分けると、学ぶ順番を決めやすくなります。技術名だけでなく、求められる担当範囲も確認しましょう。

職務経歴では「Javaで3年」から一歩進めて、実装以外に関わった工程も整理します。設計、コードレビュー、テスト設計、リリース、障害対応のうち、どこを担当したか。性能改善やリファクタリングをしたなら、変更の理由や影響範囲も説明できるようにしておきたいです。

学習では、小さなアプリをDockerで動かし、構成を説明するといった課題を設定できます。クラウドやCI/CDも応募先での使われ方を見て選び、個人で試した経験は実務経験と分けて書きましょう。

パターン4：顧客調整・上流寄りなら、希望する役割をはっきりさせる

顧客との打ち合わせや要件整理が中心だった人は、まず「転職後は自分で実装したいのか、調整やプロジェクト推進を中心にしたいのか」を考えておきましょう。自社開発という言葉だけでは、希望する仕事の配分まで伝わりません。

要望を仕様に落とした経験は、どんな制約があり、どう合意したかを整理します。打ち合わせの回数よりも、そこで自分が解決したことを説明してみてください。

実装を担うエンジニアとして応募するなら、小規模改修、設計レビュー、個人開発など、最近の技術との接点も示したいところです。PMやテックリードを希望する場合も、調整経験に加えて何を求められるか確認しましょう。

パターン5：経験が浅いなら、今の現場で増やせる経験を見る

経験が浅いと、「早くSESから出ないと」と焦るかもしれません。けれど、在籍年数だけで結論を出す前に、今の現場で次に何を任せてもらえそうかを確認してみてもいいと思います。

開発案件への異動や、小規模改修への参加を相談する
テスト実施から、テストケースの作成へ担当を広げる
SQLを使った調査や、Gitでの変更管理に関わる
繰り返し作業の自動化を提案する

希望を出したあとは、実現する見込みや時期も確認しましょう。「そのうち開発に行けるかも」で待ち続けるのは、ちょっとつらいです。今後も担当が変わる見込みがないなら、転職先を調べながら、自分でも実装を学ぶ進め方があります。

「半年後に何ができるようになっていたいか」と考えるのも一例です。転職まで待つ期限ではなく、今の環境で得たい経験と、外で探す機会を比べる区切りにしてみてください。

今の現場で担当を広げられそうにないなら、現場変更や社内異動も含めて比べてみてください。開発経験が積めないときの現場変更・社内異動・転職の選び方で、相談する内容と待つ見込みの確かめ方を整理しています。

SESから自社開発までの4ステップ

自分に近いパターンが見えたら、応募に向けて動いてみましょう。途中で分かったことを、前のステップに戻して調整しても大丈夫です。

STEP 1：現在地を棚卸しする

言語、フレームワーク、DB、クラウド、担当工程、開発規模、改善経験を書き出します。それぞれに「実務で担当」「補助として参加」「個人で学習」を添え、職務経歴書で説明する仕事を選びましょう。規模や成果の数字は、確認できるものだけを使います。

STEP 2：求人を20件くらい見て、共通点を探す

最初は、気になる求人を20件くらい並べて比べる方法をおすすめします。20件は筆者の目安で、必要件数を示す統計ではありません。希望に合う募集が少なければ、件数を埋めるために興味のない求人まで集めなくて大丈夫です。

仕事内容、必須条件、歓迎条件を分け、共通する技術と、志望する会社が特に重視する条件を拾います。「その技術で何を任されるか」まで見ると、学ぶ内容を絞りやすくなります。

STEP 3：応募先に合わせて、学習課題を決める

「クラウドを勉強する」だけだと、終わりが見えにくいです。たとえば小さなアプリを動かし、構成と設定の理由を説明できるようにする、といった課題に落としてみてください。求人を見て選んだ課題を一つ仕上げ、動かし方やつまずいた点も記録しておきます。

STEP 4：応募して、伝わった点と不足した点を見直す

主要な業務と経験が合い、応募条件を確認できたら、応募を進めてみましょう。面接でうまく説明できなかった点や、詳しく聞かれた経験を記録して、書類や準備を修正します。不採用の理由が分からない場合は、一社の結果だけで「この経験では無理」と結論づけなくて大丈夫です。

求人票の「必須条件」を全部満たす必要はある？

必須条件が長く並んでいると、読むだけで身構えますよね。とはいえ、「全部そろっていないから諦める」「必須と書いてあっても気にしない」のどちらかに決める前に、応募先へ確認したいところです。選考で譲れない条件は、こちらの判断で消せません。

近い技術の実務経験があるなら、何を担当していたかを伝えたうえで、応募対象になるか問い合わせてみましょう。個人開発で触っている技術も、その範囲を説明します。実務未経験を隠さず確認すれば、応募するか、先に準備するかを判断する材料になります。

「7割くらい合っていれば候補に入れる」は、筆者の大まかな目安です。採用確率や企業共通の合格基準ではありません。項目数で7割合っても、中心となる業務の経験が足りなければ話は変わります。

転職エージェントには、最初に希望を具体的に伝える

紹介がSES中心だったり、自社開発の候補が少なかったりする場合は、希望の伝わり方と紹介できる求人の範囲を確認しましょう。最初に、作りたいもの、使いたい技術、避けたい働き方まで伝えておくと、すり合わせやすくなります。

たとえば「自社サービスの機能開発をしたい」「Java経験を使いたい」「客先常駐は希望しない」という伝え方です。譲れない条件と相談できる条件を分け、紹介時には実際の配属先や業務も確認します。

各エージェントが紹介できる求人を比べるために、複数を併用する方法もあります。連絡の管理で疲れない範囲に絞り、直接応募も含めて探しましょう。重複応募を避けるため、応募状況は手元にまとめておくと楽です。

ポートフォリオは、何を伝えるために作る？

まずは応募先が提出を求めているか確認します。そのうえで、実務の開発経験を説明できるなら職務経歴書を整え、実装を示す材料が少ないなら個人開発で補う、という順番で考えるとよさそうです。ポートフォリオを作ること自体をゴールにしないようにしたいですね。

作品には、使用技術、作った理由、工夫した点、動かし方をREADMEにまとめておきましょう。見た目を整えるだけでなく、設計の理由や、まだ改善したい部分も説明できるようにします。業務のコードやデータをそのまま公開せず、公開できる自作の内容で準備してください。

自社開発だから良い会社、とは限らない

自社開発というだけで、自分に合う働き方まで決まるわけではありません。自社開発という属性に、ホワイト企業補正は付いていないので……。給与や勤務条件に加えて、日々の開発がどう回っているかも面接で聞いておきたいです。

レビュー体制：誰がレビューし、困ったときは誰に相談できるか
リリース頻度：どのくらいの間隔で、どんな確認を経てリリースするか
技術負債：保守しづらい部分をどう把握し、改善の時間を確保しているか
開発人数：配属チームは何人で、自分にどの範囲を任せる予定か
障害対応：誰が初動を担当し、復旧や再発防止をどう分担するか
オンコール：勤務時間外の待機・呼び出しはあるか。当番、頻度、手当や代休の扱いはどうか

リリースが多ければ良い、技術負債があれば悪い、と単独で判断する必要はありません。無理なく対応できる体制があるか、自分がやりたい仕事に時間を使えそうかを、回答をつなげて見ていきましょう。

質問の組み立て方は、SESから社内SEへ転職する面接・逆質問の例も参考になります。職種は異なりますが、担当範囲や支援体制を具体的に聞き、入社後の仕事を確かめる考え方は、自社開発の面接にも使えます。

まとめ：今の経験から、次にやることを決めよう

SESから自社開発を目指すときも、これまでの経験を全部リセットする必要はありません。仕事の中身を整理し、希望する求人と照らし合わせて、足りないものを補っていく。その準備は、テスト中心の人と、すでに開発や設計を担当している人では変わります。

まずは担当した仕事を一つ、調べたことや判断したことまで書き出してみてください。そこから気になる求人を見れば、次に学ぶことや、応募前に確認したいことが少し具体的になるはずです。何から始めるか分からないときは、そこからでいいと思います。