「SESから自社開発に転職するなんて、自分には無理だろう」。32歳、SES歴10年になる少し前まで、私自身もそう思っていました。
結論から言うと、それは思い込みでした。30代でも自社開発企業への転職は十分可能です。
ただし、コーディング試験の対策なしに突破するのは、想像していた以上に厳しい道でした。
面接で実際に何を問われたか。対策なしで試験に臨み、頭が真っ白になった話。
そして転職後に待っていた「良かった点」（残業激減・技術環境の刷新）と「大変だった点」（評価軸の変化・キャッチアップの厳しさ）。
そのすべてを、実際に経験した通りに書きます。
「自分にもできるだろうか」。そう思っているなら、今から何を準備すればいいのか、この先に答えがあります。
SESと自社開発の違いとは？
SES（System Engineering Service）とは、エンジニアが自社に所属したまま客先常駐で業務を行う契約形態です。一方自社開発とは、自社で企画・開発したプロダクトやサービスに携わる働き方を指し、客先常駐は発生しません。この2つの違いが、本記事で紹介する転職の背景にあります。
なぜ30代で転職を決意したか？SI/SES時代の停滞感
私が本格的に転職を考え始めたのは、32歳の時でした。新卒から約10年間、SI/SES企業に勤務し、メイン言語のJavaを使ってきました。
客先常駐として、さまざまな現場を経験したのです。
一見、順調なキャリアに思えるかもしれません。しかし、私の心の中には「このままでいいのだろうか」という強い焦りがありました。
一番の理由は、知識の停滞と成長の鈍化を肌で感じていたためです。
長年同じ環境にいると、どうしても使う技術や考え方が固定化してきます。私が担当する現場の多くは、残念ながらレガシーな環境でした。
古いJavaのバージョンを使い続け、独自に作り込まれたフレームワークの保守が主な業務です。
担当していた現場からはなかなか異動できず、同じ保守作業を繰り返す日々が続きました。
「知識の停滞」というのは、私にとって決して大げさな表現ではなかったのです。
新しい技術をキャッチアップしようにも、業務で使う機会はほとんどありません。
クラウド技術やコンテナ技術といったモダンな技術は、遠い世界の出来事のように感じられました。
また、SI/SES特有の環境も、私の危機感を強めました。現場では、言われたことだけを正確にこなすことが評価されます。
自発的な改善提案よりも、仕様書通りに動くプログラムを納期までに作ることが最優先されるのです。
もちろん、それはそれでプロフェッショナルな仕事です。しかし、私には「言われたことだけやる」環境が、自分の成長を止めているように思えてなりませんでした。
このまま40代、50代を迎えた時、自分はエンジニアとして市場価値を保てているだろうか。
技術の進歩から取り残され、調整業務ばかりのエクセル職人になってしまうのではないか。
そんな強い危機感が、私を転職へと突き動かしたのです。新しい技術やモダンな開発プロセスに挑戦したい。エンジニアとして、もう一度本気で成長したい。
転職前の労働環境｜フルリモートは本当に楽だったのか？
転職を考え始めた当時、私の働き方はフルリモートでした。働き方改革やリモートワークの普及もあり、数年前から在宅勤務が基本となっていたのです。
「フルリモートなんて、うらやましい」
「働きやすい環境だったのでは？」
そう思われるかもしれません。確かに、通勤時間がなくなったメリットは大きかったです。
しかし、実態は決して楽なものではありませんでした。
フルリモートになったことで、かえって労働時間があいまいになった面があります。
客先常駐（SES）の形態は変わらないため、複数のプロジェクトや現場との調整業務に追われる日々でした。
チャットツールは常に通知が鳴りやまず、日中は会議と調整で手一杯。自分の開発作業ができるのは、周りが静かになった夕方以降という日も珍しくありません。
そして、最も負担だったのが深夜の会議です。
さまざまなステークホルダーの都合を合わせようとすると、どうしても夜遅い時間に会議が設定されがちでした。
フルリモートだから参加できてしまう、という側面もあったかもしれません。22時から始まる会議が、常態化していたのです。
深夜会議が常態化した背景には、要件定義があいまいなまま見切り発車したプロジェクトの存在もありました。
あるプロジェクトでは、リリース直前になって仕様が3割ほど変わるということがあり、その調整のために深夜まで関係者を集める会議が続いたのです。
孤独感も、当時の私を蝕んでいました。ある現場では、客先常駐のフロアに自社のメンバーが自分ひとりという環境で、1年近くを過ごしたことがあります。
ランチも相談相手も常にひとり。技術的な悩みを気軽に話せる相手がいないという状況は、想像以上にこたえるものでした。
SI業界特有の多重下請け構造の中で、私が求められる役割も変化していました。
純粋な開発スキルよりも、顧客への報告資料作成や、上位の会社への進捗報告、他部署との調整といった管理業務の割合がどんどん増えていったのです。
それでいて、評価が上がるわけではありませんでした。会社側から相応の説明はあったものの、私はこの時期に2年連続で減給を経験しています。
管理業務が増え、負担は明らかに大きくなっているのに評価はむしろ下がる。このギャップに、正直かなりメンタルをやられました。
「自分はエンジニアとして、本当に成長できているのだろうか」
深夜まで続く会議のモニター画面を見ながら、私は何度も自問自答していました。肉体的には自宅にいますが、精神的には常に仕事に縛られている感覚。
この環境から抜け出したいという思いが、転職決意の最後の一押しとなりました。
転職活動のリアル｜業務系SEでも自社開発は目指せるか
転職を決意し、私はまずいくつかの転職エージェントに登録しました。私の武器は、約10年間のJavaでの開発経験です。
エージェントからは「Javaの経験、リーダー経験があれば、紹介できる案件は多いですよ」と言われ、少し安心したのを覚えています。
実際、SIerやSES企業からのオファーは、すぐにもらえそうでした。しかし、私の目標はあくまで「自社開発企業」への転職です。
ここで、私は最初の現実に直面しました。
私のメイン言語はJavaでしたが、Web系の自社開発企業ではRubyやGo、Pythonといったモダンな言語も使われています。
それらにも興味があり、「あわよくばスキルチェンジもできないか」と淡い期待を抱いていました。
しかし、30代スキルチェンジでの転職は、想像以上に厳しいものでした。
企業側からすれば、30代のエンジニアに求めるのはポテンシャルではなく、即戦力としてのスキルです。
未経験の言語をこれから学ぶ人よりも、今ある技術（私の場合はJava）でいかに貢献できるかを問われます。
結局、私は「Javaエンジニア」として転職活動の軸足を固め直しました。
幸い、自社開発企業の中にもJavaをメインで使っている企業は多くあります。（例えば、大規模なECサイトや金融系のWebサービスなど）
しかし、ここでもSI/SES時代とのギャップに気づかされます。
面接で深く問われるのは、「Javaのフレームワークを使って何を作ったか」だけではありません。
- なぜその技術を選んだのか？
- 大規模なトラフィックをどうさばいたか？
- パフォーマンスチューニングの経験はあるか？
- テストコードはどのように書いているか？
面接でよく聞かれた質問一覧
選考が進むにつれ、技術的な深掘り以外にも定番の質問が繰り返し出てきました。事前に自分の言葉で答えを用意しておくと、当日の余裕が大きく変わります。
- なぜSESから自社開発を目指すのか？
- SESでの経験をどう活かせるか？
- 将来的にどんな技術・キャリアを目指したいか？
- チームでの開発経験・コミュニケーションで意識していたことは？
単にJavaが書けるだけでは不十分。自社のサービスを継続的に成長させ、安定的に運用していくための、より深い知識と経験が求められたのです。
SI/SES時代にはあまり意識してこなかった視点も多く、知識不足を痛感しました。
最大の壁「コーディング試験」の難易度
転職活動の中で、私にとって最大の壁となったもの。それがコーディング試験です。
SI/SES企業に勤務していた約10年間、いわゆる「アルゴリズムとデータ構造」を意識してコードを書く機会は、正直に言ってほとんどありませんでした。
業務で求められるのは、仕様書通りに動くロジックの実装です。既存のフレームワークやルールに則ることが最優先されました。
しかし、私が応募した自社開発企業の選考プロセスには、ほぼ例外なくコーディング試験が含まれていたのです。
その形式はさまざまでした。
- Webテスト式：制限時間内に、オンライン上で出題される複数のお題を解く。（例：AtCoderのようなプラットフォームを使う）
- ライブコーディング形式：面接官と画面を共有しながら、その場で出されたお題を解いていく。
なお、これは2026年8月時点の情報ですが、コーディング試験に生成AIの利用を許可する自社開発企業も増えてきています。
応募する企業がAI利用OKなのか、素の実装力を見たいのかは事前に確認しておくと、当日戸惑わずに済みます。
出題される問題は、「〇〇フレームワークを使って××の機能を作ってください」といった業務的なものではありません。
「この文字列の中から、特定の条件を満たす部分文字列を見つけなさい」といった、計算量や効率的なアルゴリズムを問うものが中心でした。
最初、何の対策もせずに試験に臨んだ私は、まったく歯が立ちませんでした。
「えっ、こんなに難しいの？」
「業務でこんなコード書いたことない…」
頭が真っ白になり、制限時間だけが過ぎていく。SI/SES時代に、もっと日常的に基礎体力トレーニングを積んでおくべきだったと、心から後悔しました。
その後、私はAtCoderや競技プログラミングの問題集を使い、アルゴリズムとデータ構造を基礎から学び直しました。
毎日少しずつ練習を積み重ねることで、数ヶ月後にはようやく手応えを感じられるようになり、最終的に内定につなげることができました。
これから自社開発企業を目指す方は、技術面接の対策と並行して、コーディング試験の対策にも十分な時間を割くことを強くお勧めします。
これは、対策していないと本当に厳しいと感じた、私の偽らざる実感です。
転職は早いほうがよい？30代でも挑戦は可能か
結論から言えば、転職を考えているなら1日でも早く動き始めるべきです。
転職活動を進める中で、私は何度も「もっと早く行動しておけばよかった」と感じました。
「新しい技術、現場に挑戦したい」
もしあなたが今、そう思っているならば、転職活動（あるいは学習）は1日でも早く始めたほうがよいです。
これは、脅しでも何でもありません。現実的な理由があります。
年齢が上がるほど、転職市場で求められるものが変わってくるためです。
20代であれば「ポテンシャル」や「学習意欲の高さ」が評価され、未経験の分野でも採用されるチャンスが多くあります。
しかし、30代、特に30代半ば以降になると、企業側は「即戦力」を求めます。
ポテンシャル採用の枠はぐっと減り、その分野での高い専門性や、チームを率いたマネジメント経験が要求されることが一般的です。
実際、2026年の転職市場でも「経験があれば誰でも採用される」時代は終わりつつあり、即戦力人材への需要が一段と強まっています。
私の場合、30代前半（32歳）だったことが、ギリギリ「ポテンシャル＋即戦力」の両面で見てもらえた要因の一つだったかもしれません。
とはいえ、30代だからもう遅い、とあきらめる必要は全くありません。
私自身が30代前半で、レガシーなSI/SES環境から自社開発企業への転職を成功させました。
大切なのは、年齢を嘆くことではなく、「何をやりたいか」を明確にすることです。そして、その目標に対して、今すぐ行動（学習・対策）を始めること。
今日から始められる3つの行動
コーディング試験の対策を始める。クラウド（AWSやGCP）の認定資格の勉強をしてみる。GitHubで自分のポートフォリオ（製作物）を公開する。
何でも構いません。小さな一歩を踏み出すことが、未来を変えることにつながります。
もう一つ、私が実際に効果を感じた行動がエンジニア 副業です。
在職中に週末や平日の夜だけ小さな案件を受けてみると、SI/SES時代とは違う技術要件や納品スピード感に触れられます。
転職の可否を判断する材料になるだけでなく、面接で語れる「実務外の開発経験」としてもそのまま使えました。
いきなり大きな案件を狙う必要はなく、まずは週1〜数時間の小さな仕事から試すので十分です。
また、SI/SESでの経験がすべて無駄になるわけでもありません。
- 大規模システムの運用・保守経験
- 顧客との折衝や要件定義のスキル
- 障害発生時の冷静な対応力
- ドキュメント作成能力
これらの経験は、自社開発企業においても必ず活きる場面があります。「自分にはモダンな技術がないから…」と卑下する必要はありません。
あなたの10年の経験は、見せ方次第で強力な武器になるのです。
転職先を選ぶときにチェックすべき自社開発企業の特徴
「自社開発」と一口に言っても、実態は企業によって大きく異なります。
私自身、複数社の選考を受ける中で、内定後に後悔しないための判断軸がいくつか見えてきました。
- 自社開発の割合：受託開発と自社開発を両方手がける企業もあるため、実際にどの案件にどの程度アサインされるかを面接で確認する
- コードレビュー文化の有無：「コーディング規約に沿っているか」程度の形式的なチェックなのか、設計思想まで踏み込んだレビューが行われるのかで、入社後の成長速度が変わる
- テストコードを書く文化があるか：プルリクエストの必須条件になっているか、それとも任意なのかで、品質に対する組織の本気度がわかる
これらの基準は、私が転職後に「当たり前」が通用しないと痛感した項目そのものです。
選考段階でここまで確認できれば、入社後のギャップはかなり小さくできるはずです。
転職後の現実①｜技術レベルの差にどうついていったか
結論から言うと、転職後は技術レベルの高さと意思決定スピードの両方で、想像以上のカルチャーショックを受けました。
数ヶ月にわたる転職活動の末、私は無事に第一志望群だった自社開発企業から内定をいただきました。
入社してまず感じたのは、周りのメンバーの技術レベルの高さです。
新卒数年目の20代のエンジニアが、私よりもはるかに深い技術的知識を持っている。
アーキテクチャやパフォーマンスチューニングについて、日常的に活発な議論が交わされている。そんな環境でした。
正直に告白すると、入社してからの数ヶ月間は、ついていくのがやっとでした。
技術レベルの高さ以上に衝撃だったのは、意思決定のスピードでした。会議で出たアイデアが、翌週にはもう実装されて動いている。
SI/SES時代は、ちょっとした改善提案ひとつが承認を得るまでに何週間もかかるのが当たり前だったので、このスピード感は文字通りカルチャーショックでした。
SI/SES時代に「当たり前」だと思っていたことが、まったく通用しないのです。
例えば、コードレビューの文化。
転職前は、いわゆる「コーディング規約」に沿っているか、明らかなバグがないか、程度のチェックが中心でした。しかし、転職先のレビューは違います。
「なぜこの設計にしたのか」「もっと効率的な書き方はないか」「テストコードが不十分ではないか」といった、非常に本質的で厳しい指摘が日々飛んできます。
例えば、テストコードの重要性。
転職前は、テストコードを書く文化が（現場によっては）希薄でした。しかし、転職先ではテストコードを書くのは当たり前。
むしろ、テストコードがなければプルリクエスト（修正依頼）を出すことすらできません。
そして、CI/CDの整備。
CI/CD（継続的インテグレーション/継続的デリバリー）のパイプラインは整備され、開発からデプロイまでのスピード感が圧倒的に違います。
転職前はレガシーなJava環境でしたが、転職後はモダンなJavaのバージョンを使うようになりました。
コンテナやマイクロサービスといったクラウドネイティブな技術に触れる機会も、一気に増えました。
毎日が勉強の連続です。キャッチアップしなければならない知識が山のようにあり、正直「大変だ」と感じることも多いです。
しかし、この「大変さ」は、SI/SES時代に感じていた「停滞感」とはまったく質が異なります。
これは、前向きな「成長痛」です。
日々新しい知識を吸収でき、自分がエンジニアとして確かに成長している実感がある。優秀な同僚たちからもらえるフィードバックが、何よりの刺激になっています。
転職後の現実②：評価軸の変化と残業時間
転職して、働き方そのものも劇的に変化しました。
最も大きな変化は、残業がほぼゼロになったことです。
転職前は常態化していた深夜の会議や、休日出勤（障害対応以外）は、転職してから一度もありません。
定時になれば、ほとんどのメンバーがさっと仕事を終えて帰宅します。
会社として「生産性高く働き、プライベートも充実させる」という文化が根付いているのです。
その結果、私には「時間」が生まれました。
平日の夜や週末に、自分のための時間ができたのです。その時間を、私は技術書のキャッチアップや、趣味、家族との団らんに充てています。
ワークライフバランスは、転職前に比べて劇的に改善しました。
ただし、良いことばかりではありません。
もう一つの大きな変化、それは「評価軸の変化」です。
転職前のSI/SES企業では、極端に言えば「言われたことだけを、ミスなく期限内にやれば」評価されました。
受け身の姿勢でも、ある程度の評価は得られたのです。
しかし、今の自社開発企業は違います。
自発的に行動し、自ら仕事を見つけることが強く求められます。
「サービスをより良くするために、何ができるか？」
「今、チームが抱えている技術的な課題は何か？」
「その課題を解決するために、自分はどう動くべきか？」
これらの問いを常に考え、周りを巻き込みながら提案し、実行していく力が求められるのです。
言われたことを待っているだけでは、まったく評価されません。
「あなたは会社に、どんな付加価値をもたらしたのですか？」という問いに、常に向き合い続ける必要があります。
これは、受け身の働き方に慣れていた私にとって、残業がなくなること以上に大きなカルチャーショックでした。
レベルの高い環境で自走し続ける厳しさはありますが、それこそが自社開発企業で働く醍醐味なのだと感じています。
自社開発企業への転職を成功させるポイント
振り返ってみると、選考を通過できた面接には共通点がありました。
まず、志望動機は「自社開発だから」という漠然とした理由では通用しません。
「なぜその会社のプロダクト・技術でなければならないか」まで踏み込んで語れるかが見られていると感じました。
企業のプロダクトを実際に触ってみた上での感想や、技術ブログを読んで気になった記事を志望動機に盛り込むと、説得力が格段に変わります。
また、コーディング試験や実務経験について問われた際は、「なぜその技術を選んだのか」「他にどんな選択肢があったのか」まで説明できるようにしておきましょう。
単なる作業者ではなく、設計判断ができるエンジニアだという印象を与えられます。
ポートフォリオの効果は、私自身の過去の転職活動でも実感しています。
以前の転職活動でポートフォリオなしで応募していたときは書類通過率が10%以下でしたが、GitHubにコードを公開するようになってからは約50%まで改善しました。
「今日から始められる3つの行動」で触れたポートフォリオ公開は、決して気休めの助言ではありません。
最後に、逆質問の時間は自走力をアピールする貴重な機会です。
「入社後のオンボーディングで技術的に苦労したことは何ですか？」といった質問は、単に情報を得るだけでなく、キャッチアップへの意欲を伝えることにもつながります。
よくある質問
Q. 30代でSESから自社開発への転職は本当に厳しいですか？
厳しさはありますが不可能ではありません。
企業は即戦力を求めるため、未経験分野へのスキルチェンジより、今ある技術（本記事の場合はJava）を軸にした転職活動が現実的です。
Q. コーディング試験の対策はどれくらいの期間が必要ですか？
本記事の著者の場合、AtCoderや競技プログラミングの問題集を毎日少しずつ学習し、数ヶ月で手応えを感じられるようになりました。
Q. SI/SESでの経験は自社開発企業でも活きますか？
大規模システムの運用・保守経験、顧客折衝力、障害対応力、ドキュメント作成能力は自社開発企業でも活きます。
ただしテストコードの記述やコードレビュー文化など、評価軸そのものは大きく変わります。
Q. SESと自社開発の違いは何ですか？
SESはエンジニアが自社に所属したまま客先常駐で働く契約形態で、自社開発は自社のプロダクト・サービスを開発する働き方です。
自社開発では客先常駐が発生せず、評価軸も「言われたことをこなす」から「自発的に課題を見つけて動く」に変わります。
Q. 自社開発企業を選ぶときに確認すべきことは？
自社開発の割合（受託と両方手がける企業もあるため）、コードレビュー文化の有無、テストコードを書く文化があるかの3点を面接で確認するとよいです。
これらは入社後のギャップを左右する重要な判断軸です。
Q. ポートフォリオは転職に本当に必要ですか？
必須ではありませんが効果は大きいです。
本記事の著者の場合、ポートフォリオなしでは書類通過率10%以下だったのが、GitHubにコードを公開してからは約50%まで改善しました。
Q. コーディング試験に生成AIを使ってもよいですか？
企業によります。
2026年時点では生成AIの利用を許可する自社開発企業も増えていますが、素の実装力を見たい企業もあるため、応募先に事前確認するのが確実です。
【総括】SESから自社開発への転職は成功したか
結論として、30代でのSI/SESから自社開発への転職は「十分可能」であり、私自身「転職して本当によかった」と断言できます。
ただし、その道のりは決して平坦ではありませんでした。
コーディング試験の壁にぶつかり、自分の実力不足を痛感しました。
転職後も、周りのレベルの高さに圧倒され、必死にキャッチアップする日々が続いています。
では、結論として「転職してよかったか？」
答えは、心の底から「転職して本当によかった」です。
転職には、良いところも、悪いところ（大変なところ）もありました。
【転職してよかった点】
- 残業が激減し、ワークライフバランスが劇的に改善した。
- モダンな技術環境（レガシー脱却）で開発できるようになった。
- 優秀な同僚たちに囲まれ、日々成長を実感できる。
【転職して大変だった点（悪い点）】
- コーディング試験など、選考対策が非常に大変だった。
- 求められる技術レベルが高く、入社後のキャッチアップが続く。
- 評価軸が「受け身」から「自発的」に変わり、自走する力が求められる。
すべてが楽園というわけではありません。自ら学び、動き続けないと、あっという間に取り残されてしまう厳しさがあります。
しかし、何よりも大きいのは、SI/SES時代に感じていた「キャリアの停滞感」や「将来への漠然とした不安」が、完全に解消されたことです。
今、私は「エンジニアとして成長している」と胸を張って言えます。
もし、私がこの体験記で一つだけ後悔を述べるとすれば、それは「できれば20代のうちに転職しておけばよかった」という、ありきたりな言葉に尽きます。
もっと早くこの環境に身を置いていれば、今頃はもっと違う景色が見えていたかもしれません。
もし今、あなたが30代でSI/SESからの転職を迷っているなら。
もし、かつての私と同じように「停滞感」や「焦り」を感じているなら。
まずは、小さな一歩からで構いません。
転職エージェントに登録してみる。
コーディング試験の勉強を始めてみる。
気になる企業の技術ブログを読んでみる。
その小さな行動が、あなたの未来を大きく変えるきっかけになるはずです。
※本記事は2026年7月時点の体験に基づく実録です（2026年8月に情報を一部更新）。
