自社開発エンジニアへの転職で後悔している人に話を聞くと、企業選びの前に「自社開発か否か」だけを見て応募を決めたケースが目立ちます。
後悔するかどうかは、自社開発を選んだかどうかよりも、どのフェーズ・規模・開発文化の企業を選んだかで決まります。
求人票に「自社開発」と書かれていても、入社後の業務が保守中心なのか、コードレビュー文化があるのか、実態が受託に近くないかは、応募前に確かめないと分かりません。
後悔が起きる場面・自分が当てはまるかの判断材料・入社前に何をどう確認するかをここで整理します。
自社開発エンジニアへの転職で後悔する人に多い場面
同じシステムの保守・改修に5年携わったあと転職市場に出て、他社に通用するスキルが何も残っていないと気づく。自社開発への転職で後悔する人の話は、こうした場面から始まります。後悔は技術の偏りだけにとどまらず、入社してから初めて気づく場面から始まります。
同じシステムの保守が続きスキルが古くなる
同じシステムの保守・改修だけが何年も続きます。
ある会社で同一システムの保守・改修に5年携わったあと、世の中の新しい技術トレンドから取り残されていたと気づく場面があります。プロダクトの成長が鈍化し、リリース後の保守や小規模な改善が中心になると、新しい言語に触れる機会は増えません。
レガシーシステムや技術的負債を抱えた開発チームでは、古い技術を刷新できないまま使い続け、業界のトレンドとの距離が広がります。手元の仕事はこなせても、転職市場に出たときに他社で通用するスキルが残っていないという状況になりがちです。
もっとも、自社のプロダクトに最適化されたスキルが深く積み上がるのは確かです。ただ、その深さは特定の技術スタックに偏りやすく、市場で普遍的に通じる経験とは限りません。
保守中心の現場から抜け出す動き方は、現職での交渉から転職先の選び方まで別記事で解説しています。
▶ SESから脱出するには？保守中心の2〜4年目が開発へ移る方法を解説！
入社直後のコードレビューで消耗する
納品を優先してコードレビューが薄かったSESや受託から移ると、自社開発の密度に入社直後からつまずく人が出てきます。プルリクエストには細かい指摘が飛び、設計思想をめぐって議論になり、テストコードの書き方まで問われるからです。SES時代にコードを書けるようになりたいと思っていた気持ちが、実際の密度に押しつぶされることもあります。
スキルそのものよりも、環境のレベルと自分のレベルの開きが先に来ます。自社開発という言葉の幅は広く、どこでも同じ密度というわけではありません。
雑務が増えて開発に集中できない
コードを書く時間が、想定より減っていく場面があります。サービスの問い合わせ対応、障害発生時の顧客への報告、社内PCのセットアップ、採用活動の手伝い。客先常駐の時代には回ってこなかった仕事が、自社にいると次々と手元に来ます。
企業規模にもよりますが、常駐していた頃より雑務が増えるとはっきり感じる人もいます。開発に全集中できると思って移ったのに、開発以外に時間を取られて戸惑う後悔です。
上司との関係が固定され評価に響く
SESや受託は、プロジェクトや客先が変わるたびに人間関係がいったんリセットされます。一方で自社開発は、同じチーム・同じ上司の下で長期間働くことが基本です。この差が、上司との相性が悪かったときに効いてきます。
常駐なら次の現場で関係を作り直せますが、自社開発では合わない上司のもとに留まり続けることになりやすく、成果が正当に評価されないと感じても逃げ場は少なくなります。常駐時代には当たり前だった人間関係のリセットが、ここでは効きません。
求人は自社開発でも実態は常駐・受託だった
公式サイトで自社サービスをアピールしていても、研修後すぐに客先常駐を命じられる。こうした話は複数共有されています。
自社開発を謳いながら、実態としては客先常駐や受託案件が事業の中心になっている企業も存在します。求人票の表記と中身が食い違っていると、入社して配属が決まって初めて、聞いていた働き方と違うと分かります。ふたを開ければこれまでと変わらない常駐生活だった、というのが求人の言葉だけで応募して直面する入社後のギャップです。
なお、客先常駐が続く環境で何がきついのか、辞めるか案件を変えるかの判断については別記事で解説しています。
▶ SES客先常駐がきつい理由とは？辞めるか案件を変えるか解説！
後悔しやすい人・後悔しにくい人の違い
同じ場面でも、つらいと感じる人と、面白いと感じる人に分かれます。保守の繰り返し、入社直後のコードレビュー、開発以外の雑務。
後悔するかどうかは、能力が高いか低いかではありません。何をしたくて、どんな環境を心地よく感じるか。その相性で分かれます。
開発だけに集中したい人は後悔しやすい
コードを書く時間だけを増やしたくて移った人ほど、入社後に戸惑います。なぜか。中小やスタートアップでは役割の線引きが薄く、開発以外の業務が次々と手元に来るからです。
たとえば、問い合わせ対応、障害が起きたときの報告、社内PCのセットアップ、採用の手伝い。客先常駐の時代には回ってこなかった仕事が、自社にいると割り振られます。コードを書く時間は想定より大幅に減ります。開発に全集中できる環境を求めて移った人ほど、この落差を後悔として受け取りやすくなります。
受け身で会社が育ててくれると思う人は後悔しやすい
入社初日に「とりあえずこのリポジトリを読んでおいて」と言われた、という話があります。研修も丁寧な引き継ぎもなく、採用側は開発経験が薄い人を、いきなり開発メインで使うリスクを取りません。
ところが、会社が育ててくれると構えていると、現実との落差に直面します。周囲のスピードについていけず、毎日のように残業してもタスクが終わりません。
質問できる相手もいない、あるいは聞きづらい雰囲気で、一人で問題を抱え込む。研修で教えてもらえると期待して入った人ほど、この孤立が効いてきます。待っているのは育成ではなく、入社日から実務です。
サービスを育てる過程を楽しめる人は後悔しにくい
自分の書いたコードが、実際のサービスとして動く。リリースして、改善を重ねて、利用者の数字が動くのを見る。この手応えがあれば、雑務やレビューの密度は割に合います。
もっとも、その実感はフェーズによって形が違います。0→1フェーズなら、まだ世に出ていない機能をゼロから作り、作っては壊しを繰り返します。プロダクト改善のフェーズなら、すでに動いているサービスを少しずつ伸ばす。
地味な作業が続くことは変わりません。問い合わせ対応も障害対応も、自分が育てているプロダクトのためだと思えれば、苦になりにくい。雑務やレビューの受け取り方そのものが変わってきます。
サービスを伸ばすこと自体に面白さを感じる人は、後悔しにくいです。
周囲のレベルを学びの機会と捉えられる人は後悔しにくい
経験の浅い同僚が高度な実装をこなしていたり、議論についていけなかったり。少数精鋭の現場では、周囲のレベルの高さを突きつけられる場面が必ず来ます。
ここで分かれます。劣等感で潰れる人と、追いつく目標として使う人に。後者は、分からないことをそのまま質問して吸収します。サービスを成長させるために必要な知識を、自分から取りに行く。
一方で、周囲のレベルの高さは、見上げて消耗する材料にもなれば、引き上げてもらう材料にもなります。同じ顔ぶれに囲まれて、伸びる人と疲弊する人が分かれます。
後悔する会社・しない会社の違い
20〜30人のスタートアップと200人超のSaaS企業では、自社開発という言葉でくくられていても現場の景色がまるで違います。どの自社開発企業を選ぶかで、後悔するかどうかが変わります。
開発フェーズが0→1か1→100かで業務が変わる
配属されたチームでは障害対応と細かな改修ばかりだった、という話が出やすいのは、新規開発を期待して入ったのに1→100フェーズのプロダクトに配置されたケースです。1→100は既存サービスを伸ばす段階で、業務の大半は保守・運用と小規模な改善に向かいます。一方、0→1フェーズなら、仕様が固まっていない中で機能をゼロから作り、作っては壊しを繰り返します。
求人票に書かれた「自社開発」だけでは、入った会社がどちらのフェーズにあるかまでは読み取れません。新規開発がしたいのか、ひとつのサービスを長く育てたいのか。先にその問いに答えておかないと、フェーズの確認を怠ったまま入社することになります。
企業規模でレビュー文化と任される範囲が変わる
企業規模によってレビューの密度と任される範囲が変わります。少人数のスタートアップでは、一人が設計から実装、運用まで広く受け持ち、レビューの体制が整っていないこともあります。社員数が200人を超えてくると、プルリクエストへの指摘や設計の議論が密になり、一つの機能を仕上げるまでに通る関門は増えます。
広く任されて自分で判断したいのか、レビューを受けながら設計の型を身につけたいのか。求められるスキルレベルも文化も規模で変わります。
自社開発比率が低く実態は受託の企業がある
自社サービスを持っていても、売上の大半を客先常駐や受託案件が支えている企業があります。求職者を集めるために「自社開発」という言葉を前に出しているだけで、比率まで見ないと実態は読み取れません。
自社開発比率が低い会社に入ると、自社プロダクトに関わる時間はごく一部で、メインの業務は受託や常駐だったということになりかねません。確かめたいのは、自社開発を掲げているかではなく、自社開発が業務のどれくらいを占めるかです。比率まで踏み込んで確かめないと、求人票の言葉と中身のズレに気づきません。
零細自社開発は技術レベルが低いことがある
コードレビューの文化がなく、品質の低いコードが放置されたまま動いている自社開発企業があります。テストが手動でしか行われておらず、誰もそれを問題にしていない現場です。規模が小さく資金力の乏しい会社では、モダンな開発プロセスを導入するよりも動くものを出し続けることが優先され、そうなりやすい傾向があります。
スキルアップは個人の努力任せになり、年数だけが過ぎます。自社開発を選んだのに、入った先で伸びない技術に時間を費やす羽目になります。
入社前に後悔を防ぐための確認方法
聞いておけばよかったと気づくのは、たいてい内定を承諾したあとです。「開発チーム配属予定」とだけ書かれた求人票からは、配属後の担当業務が新規開発なのか、保守や社内調整なのかまでは読み取れません。
後悔の多くは、この担当業務の中身が見えないまま入社を決めたところから始まります。配属チームの担当業務、コードレビューの体制、自社開発の比率。求人票に載らないこれらを、面接やエンジニアブログ、口コミサイトといった手がかりから入社前に確かめておきます。
面接で配属チームと担当業務の中身まで聞く
面接では、配属予定チームが直近でどんな開発をしているのかまで踏み込んで聞きます。「開発チーム配属予定」という言葉だけを信じて入社し、実際には保守や他部署との調整業務が中心だった、という落差はここで防げます。
たとえば、技術スタックとツール、コードレビューの体制、残業時間の実態、リモートワークの比率、有給取得率。この5つは求人票にほぼ書かれていません。面接で聞いて初めて分かる部分です。
配属先のチーム構成と、自分が担う業務の内容まで踏み込んで質問できれば、入社後に思っていた仕事と違うと感じる場面はかなり減ります。聞きにくいと感じる質問ほど、入社後のミスマッチに直結しやすい部分でもあります。
疑問に感じた点はその場で必ず質問しておきます。面接は、応募者の側が企業を確かめる数少ない機会。聞き残せば、確かめる場はもうありません。
入社後3〜6ヶ月で期待される成果レベルを確認する
入社後3〜6ヶ月で、どのレベルの成果を期待されるのか。この一点を面接で確かめておくと、現職とのスキル差が大きすぎないかを入社前に測れます。
たとえば、少人数のスタートアップと、利用者数が桁違いのSaaS企業とでは、同じ自社開発でも求められるスキルの水準が違います。SES時代にコードを書く機会が少なかった人が、初日からプルリクエストへの細かい指摘や設計議論を求められる環境に入ると、現場の密度に押しつぶされかねません。
入社後3〜6ヶ月でどのレベルの成果を期待されるかを事前に確かめておくことが、入社前にできる一番の準備です。環境のレベルと自分のレベルが合っていなければ、成長どころか消耗するだけです。
エンジニアブログやGitHubで開発文化を読む
企業のエンジニアブログ。公開されているGitHubのリポジトリ。技術カンファレンスでの登壇資料。社外への発信は、面接以外で開発文化をのぞける数少ない窓口です。
リポジトリからは、レビューの粒度やテストコードの有無まで読み取れます。コードレビューの文化がなく品質の低いコードが放置されている会社は、発信の中身からも見当がつきます。
逆に、設計思想や運用の工夫を丁寧に言語化している企業なら、入社後のレビューや議論の密度もそれに近くなります。求人票の文面だけでは届かない、現場の手触り。それがここに残っています。
求人票以外から自社開発比率の実態を集める
「自社開発」と書かれた求人を、そのまま信じてよいのでしょうか。求人を集めるために自社開発という言葉だけを掲げ、実態はSESや受託が中心という企業があります。
口コミサイトや現役社員のSNS、カジュアル面談。求人票に載らない自社開発比率は、こうした経路から確認できます。残業時間や人間関係、配属の実態まで含めて、入社前に複数の情報源から確かめておきます。
すでに転職して後悔しているときの立て直し方
辞めたいと感じたら、まず会社に配置転換や新しい技術に触れる機会を相談してみる。これが転職後の後悔に対する最初の一手になります。退職や再転職に動く前に社内で解決できる余地が残っていることは多く、いきなり次の会社を探すより手数が少なくて済みます。
社内で動いて、それでも変わらなければ社外で経験を積み、さらに変わらなければ再転職に動く。この順番で進めると、勢いだけで動いて二度目の後悔を重ねるリスクを抑えられます。
会社内で配置転換や新しい技術の機会を交渉する
最初に試みるのは、保守チームから新規開発チームへの異動や、新しい技術を触る機会を上長に相談することです。特定の技術に偏りすぎていることが不満の原因なら、別の分野に取り組む役割を会社に求めることで状況が変わる場合があります。
相談する際は、どの点に不満を感じているのか、どんなスキルや経験を積みたいのかを細かく伝えます。成長できないという漠然とした訴えでは会社側も打ち手を考えにくい。クラウド周りの新規案件に関わりたいと踏み込むほど、配置転換や新しい役割という形で応えてもらえる余地が広がります。自社開発の環境は同じ会社内でも柔軟性を持たせられることが多く、次の会社を探す前にまず社内のリソースを使い切る価値があります。
社外コミュニティや副業で足りない経験を補う
社内の交渉だけで状況が動かないこともあります。そのときは、社内で触れない技術を技術コミュニティや勉強会、副業で経験する方法があります。
オンラインの学習プラットフォームや勉強会で新しいスキルを身につける、副業のフリーランス案件で別の言語やライブラリを使う。こうした社外の経験を重ねると、いまの会社で停滞していても市場で通用する技術を手元に残せます。会社を辞めずに次の判断を待てるのが、この動き方の利点です。ただし残業時間が多ければ業務と勉強の両立は難しく、社外で経験を積む時間の余白がなければ続きません。
再転職を決めるタイミングの目安を持つ
社内の交渉も社外での経験積みも試したうえで、現職で不満の解決が難しいと分かった時点が、再転職に動くタイミングです。
転職活動は準備から入社まで3〜6ヶ月が目安です。後悔したからとすぐ辞めるのではなく、社内と社外の手を打ちながら在職中に動き出すと、次の会社を比較で選ぶ時間を確保できます。特定の技術に偏ったキャリアへの不安が消えないなら、より幅広い技術やプロジェクトに挑戦できる環境を探す段階に入っています。
後悔せず自社開発に転職するためのルート
再転職を検討するにしても、はじめから入社後の後悔を減らすにしても、求人の選び方は変わりません。自社開発の求人は、最低でも数年の実装経験が求められるものが目立ちます。Web系の開発言語を使った実装経験が2年以上あると、応募できる求人の幅が大きく変わってきます。
どこから転職するかによって、後悔しにくい入り方は変わります。SES・SIer・自社開発の経験者では、武器になる経歴も、覚悟しておくべき条件も違うからです。
SESや受託で実装経験を2年以上積んでから狙う
Web系の開発言語を使った実装経験が2年以上あると、自社開発の選択肢が大きく広がります。経験が1年程度だと、より経験を積んだエンジニアと比較され、スキルシートだけでポテンシャルを伝えるのは難しくなります。書類選考の段階でふるいにかけられやすいのも、この層です。
また、SESや受託からの転職では、客先常駐でどんなプロジェクトに携わり、どこまでのスキルを身につけたかが直接見られます。自社開発で使われる技術と近い経験を積んでいれば、有力な候補になります。在籍年数より先に見られるのは、自分で手を動かした開発実績をスキルシートで示せるかどうか。保守ばかりで実装を任されてこなかった人ほど、この2年を意識して案件を選ぶ価値があります。
SESから自社開発への転職で動くべき時期と準備の進め方については、別記事で詳しく解説しています。
▶ SESから自社開発への転職は難しい？動く時期と準備を解説！
SIerからは一時的な年収ダウンも視野に入れる
SIerからの転職も十分に可能ですが、年収が一時的に下がる可能性は覚悟しておいたほうがよさそうです。大規模なウォーターフォール開発の経験や顧客との折衝力は評価される一方、Web系の高速なアジャイル開発ではそのまま通じない場面が出てきます。
とくにプロジェクト管理が中心だった人が開発職を目指す場合、実装に必要なプログラミングスキルを改めて問われます。基本設計以上の経験は強みになりますが、Web系のモダンな技術を自分で学び直す覚悟は不可欠です。上流の肩書きが、そのまま実装力の評価につながるとはかぎりません。
転職エージェントで実態の情報を引き出す
求人票には、自社開発の比率も、残業の実態も、コードレビューの文化も書かれていません。研修後すぐに客先常駐を命じられたというケースは実際にあり、HPだけでは本当の中身を見抜くのは難しいです。
そこで使えるのが、IT特化型の転職エージェントです。使っている技術スタック、コードレビューの体制、残業時間、有給取得率、自社開発の比率といった、応募者からは聞きづらい点を、エージェント経由で企業に確認してもらえます。
優良求人に詳しいアドバイザーであれば、エンジニア職と謳いながら別職種に配属するような企業を、事前に外してくれることもあります。エージェントの選び方や使い方は、転職エージェントの記事で詳しくまとめています。
まとめ：自社開発への転職で後悔しないために
自社開発企業を選ぶ際の判断軸は「どこに転職するか」ではなく「どの規模・フェーズ・開発文化の企業か」です。同じ「自社開発」という名称でも、小規模スタートアップと数百人規模のSaaS企業では、開発の密度もコードレビューの体制も全く異なります。
転職活動に入る前に、自分のエンジニアリングの志向を見ておきます。自走して開発に集中したい人と、開発以外の業務も含めて貢献したい人とでは、向いている会社のタイプが変わります。面接では技術スタック・コードレビュー体制・自社開発比率を数字で確認する準備をしておきます。
すでに転職して後悔しているなら、まず社内で配置転換・技術機会の相談をします。それでも変わらなければ、在職中から転職活動を始めます。IT特化型の転職エージェントなら、求人票では読み取れない開発実態を企業に直接確認してもらえます。
自社開発エンジニアの転職と後悔に関するよくある質問
未経験から自社開発に転職すると後悔しやすい？
自社開発企業の採用は開発経験を持つ人材を想定しているケースが多く、未経験者を受け入れる場合でも、何らかの開発経験や技術的な下地を問われます。
ただし、入社後に設計の議論やコードの品質基準についていけないと感じる場合、スキル面だけでなく企業が想定していた人物像とのズレが原因になっていることがほとんどです。自分の現時点のスキルと企業が求める水準が合っているかを事前に確かめておくことが、後悔を防ぐ最初の一手になります。
30代から自社開発に転職するのは遅い？
30代からでも自社開発への転職は可能で、SESや受託で積んできた実装経験や設計の知識が直接評価されます。
ただし、技術スタックが自社開発企業の現場と離れている場合は、学び直しに使える時間をどれだけ確保できるかで、転職後の定着が変わります。年齢よりも、現職でどこまで手を動かしてきたかが先に見られる選考がほとんどです。
自社開発からSESに戻る人はいる？
自社開発に移ったあとSESに戻るケースは実際にあります。レビュー体制の密度、開発以外の業務量、評価の見えにくさ。これらが思っていた環境と違ったと感じたときに、常駐時代のほうが自分に合っていたと判断する人もいます。
自社開発が合わなかった経験をもとに、今度はSES企業の中でも技術力を伸ばせる案件を選ぶという動き方をとる人もいます。戻ることは失敗ではなく、どちらが自分のキャリアに合うかを確かめた結果です。