自社開発エンジニアはやめとけ？そう言われる理由と転職前に知っておきたい現実

自社開発企業に転職すれば客先常駐から抜け出せて、新しい技術に触れながら、自分たちのプロダクトを思いどおりに育てられる。そんなイメージを持ったまま求人を探しているなら、一度立ち止まってください。

自社開発がやめとけと言われるのは、自社開発という働き方が悪いからではありません。作ったあとも、その結果と付き合い続ける仕事だからです。リリース後の不具合、ユーザーの反応、売上に合わせた優先順位の変更、何年も前に誰かが書いたコード。SESや受託開発では契約や担当範囲によって切り分けられていたものが、自社開発では自分たちの仕事として残ります。ここを知らずに入社した人が思っていたのと違うと感じ、その声がやめとけという形で広まっています。

この記事では、開発現場で長くコードを書き、エンジニアの採用や新人教育にも関わってきた立場から、自社開発エンジニアが実際に何に苦労するのかを具体的に解説します。先に結論を言えば、見るべきなのは自社開発かどうかではありません。その会社のどのプロダクトで、何を任され、どこまで責任を持つのか。転職前にそこまで確かめられれば、やめとけという言葉に振り回される必要はなくなります。

自社開発は「やめとけ」と言われるのはなぜ？

ネットで見かける自社開発やめとけという声は、中身を分けて読む必要があります。大きく分けると、転職そのものが難しいからやめとけという話と、入社してからがきついからやめとけという話の二つです。

前者は、自社開発企業の中途採用が即戦力を前提にしていて、経験者同士で比べられるという選考の問題です。選考で苦戦している人は自社開発企業に受からない原因と対処法を読んでもらうとして、この記事で扱うのは後者、入社後の現実のほうです。

入社後のやめとけには、知っておきたい性質がもう一つあります。発言している人が経験した一社の状況が、自社開発全体の話として語られていることが多い点です。技術的負債だらけのサービスに配属された人は自社開発は古い技術ばかりだと言い、少人数のスタートアップで夜間対応に追われた人は自社開発は激務だと言います。どちらも嘘ではありませんが、あくまでその人がいた現場の話です。

とはいえ、会社によるで片付けてしまうと何も判断できません。企業ごとの差はあっても、自社サービスで稼ぐというビジネスの構造から生まれる共通の大変さがあるからです。この構造を知らないまま、自社開発なら今より良くなると考えて転職すること。それこそが、やめとけと言われる本当の原因です。

自社開発エンジニアが大変だと言われる6つの理由

自社開発の大変さは、客先常駐がないことの裏返しとして出てきます。常駐先のルールや契約範囲に守られていた部分が、自社開発では自分たちの判断に置き換わるからです。ここでは、転職前に知っておくべき6つの理由を、仕事の中身から見ていきます。

プロダクトの責任を持って開発する必要がある

受託開発には納品と検収があり、契約書に書かれた仕様を満たせば仕事は一区切りつきます。自社開発にはこの区切りがありません。リリースした機能は翌日からユーザーに使われ、使いにくければ問い合わせが増え、不具合があれば売上や会社の信用が直接削られます。

見落とされやすいのが、完了の基準です。誰かが検収してくれるわけではないので、どこまで作り込めばリリースしてよいのかをチームで決めなければなりません。プロダクトマネージャーと開発チームの間に信頼関係があれば、走りながら判断する進め方は納得感のあるものづくりにつながります。期待値のすり合わせができていない現場だとどうなるか。なぜまだ終わらないのかと、延々と詰められ続けることになります。

障害対応も自分たちの問題です。サービスが止まれば、原因が自分の書いたコードでなくても対応するのは開発チームですし、ユーザーの少ない深夜にメンテナンスやリリースを行う会社もあります。

もちろん、エンジニア一人が事業の結果を背負うわけではありません。仕様に曖昧な点があれば放置せずに確認し、将来の変更で壊れやすい箇所を指摘し、リリース後の数字やログまで見に行く。そこまでが自社開発エンジニアの仕事の範囲だということです。仕様どおりに作ったところで手を離したい人には、この働き方はかなり重く感じられます。

事業の都合で開発の優先順位が変わる

開発チームが必要だと考える作業が、そのまま最優先になるとは限りません。何を先に作るかは、売上、解約率、大口顧客の要望、競合の動き、法改正への対応、経営方針で決まります。

典型的なのが、リファクタリングを進めたいタイミングで大口顧客向けの機能追加が割り込んでくる場面です。経営層が技術を軽視しているわけではなく、限られた人数を、いま一番お金につながる場所へ回しているにすぎません。四半期の途中で方針が変わり、作りかけの機能がお蔵入りになることも、自社開発では普通に起こります。

自社サービスでは誰もやったことのない機能に挑むことが多く、見積もりの精度が低いまま走り出す場面も出てきます。工数が読めないことを事業側が理解している会社ならまだいいのですが、そうでなければ遅れの説明に追われて一日が終わります。

だからこそ自社開発では、技術的に正しい主張をするだけでは足りません。技術的負債を放置すると障害のリスクがどれだけ上がり、開発速度がどれだけ落ちるのか。それを事業側が判断できる言葉に置き換えて説明できるかどうかで、エンジニアの意見が通るかどうかが決まります。やりたい技術を自由に試せる環境を想像している人ほど、この制約は重くのしかかります。

事業の業績が給与や雇用に直結する

受託開発は、納品すれば対価を受け取れるビジネスです。自社開発は違います。プロダクトが売れなければ、どれだけ良いコードを書いても会社にお金は入りません。

そのため、プロダクトの業績は賞与や昇給にそのまま響きます。資金調達で開発を続けているスタートアップなら、次の調達が決まらなければ採用凍結や開発縮小もあり得ます。複数のサービスを持つ会社でも、不採算のサービスは統合や撤退の対象になり、チームが解散して別部署へ異動になることもあります。

これを怖いと感じるか、事業が伸びれば自分にも返ってくると捉えるかは人によって分かれます。ただ、どちらのタイプであっても、応募先がどうやって稼いでいるのかを知らないまま入社するのは避けてください。主力プロダクトの売上は伸びているのか、横ばいなのか。受託開発など別の収益の柱はあるのか。IR情報やプレスリリース、面接での質問でここを押さえておけば、入社後に先行きの不安を抱え続ける事態はかなり防げます。

技術的負債や古いコードとも向き合う必要がある

自社開発だからといって、毎日新しい機能をゼロから作っているわけではありません。長く運営されているサービスほど、過去の仕様変更、短納期で入れた暫定対応、歴代の担当者の癖が、コードとデータ構造に積み重なっています。

仕様書と実装が食い違っている。テストがほとんどない。依存ライブラリのバージョンが何年も止まっている。ある処理の意味を説明できるのは、すでに退職した前任者だけ。こうした状態では、画面の文言を一か所変えるような小さな改修でも、影響範囲を調べるのに丸一日かかることがあります。入社してまず求められるのは、新機能を作る力より、既存のコードベースを素早く読み解く力です。

ここでいう技術的負債は、古い技術を使っていることと同じ意味ではありません。将来の変更や運用に余計なコストがかかる状態のことです。新しいフレームワークで書かれていても、設計が場当たり的なら立派な負債になります。

レガシーコードを読み解き、テストを足し、少しずつ安全に作り変えていく経験は、どの現場でも通用する力になります。問題になるのは、その返済に時間を割かせてもらえない会社です。機能追加ばかりが評価され、負債の返済が後回しにされ続ける環境では、エンジニアは調査と障害対応に追われて消耗していきます。

自分で考えて動くことが求められる

自社開発では、要件が最初から細かく決まっているとは限りません。問い合わせを減らしたい、解約率を下げたい、登録完了率を上げたい、といった事業課題の形で仕事が降りてくることがあります。

この場合、指示された画面を作るだけでは仕事になりません。アクセスログやユーザーの行動データを見てどこで離脱しているのかを突き止め、複数の解決策を比べ、実装後に数字がどう動いたかを確かめる。そこまで関わってはじめて、課題に取り組んだと言えます。技術的には作れても、ユーザーの課題を解決しない機能なら、作る意味そのものを問い直す必要があります。

関わる相手も変わります。営業、カスタマーサポート、マーケティング、デザイナーなど、技術の前提を共有していない人と仕様を詰める場面が増えます。少人数の会社であれば、問い合わせの一次調査やリリース告知の文面チェックのような、開発以外の仕事がエンジニアに回ってくることもあります。

誤解されやすいのですが、ここで求められる主体性は、何を作るかを自分の好みで決めてよいという意味ではありません。事業の目的に対して技術者として具体的な選択肢を出し、関係者と合意をつくることです。指示を待って担当範囲だけを片付けたい人には、負荷の高い働き方になります。

一つのプロダクトに深く関わるからこその難しさがある

一つのプロダクトに長く関わると、技術だけでなく、その業界の商習慣、顧客の業務フロー、社内の運用ルール、過去の意思決定の経緯まで理解する必要が出てきます。会計、人事、医療、不動産のように業務知識が品質を左右する分野では、言語やフレームワークに詳しいだけでは戦力になりません。

SESや受託開発であれば、案件が変われば環境も人間関係もリセットされます。自社開発ではそれが起きません。自分が過去に書いたコードの不具合は何年後であっても自分たちで直すことになりますし、チームの人間関係や上司との相性も、異動がない限り変わりません。

プロダクトそのものへの関心も無視できない要素です。同じサービスと何年も向き合うので、その領域に興味が持てないと、日々の改善を続ける動機が持ちません。技術は好きでも扱うサービスに関心がないまま入社し、1〜2年で気持ちが切れてしまう。これはよくある失敗パターンです。

同じ領域を掘り下げるからこそ得られる専門性は確かにあります。反対に、担当が固定されれば別の業界や技術に触れる機会は減ります。応募する前に、そのプロダクトの領域と自分が何年付き合えそうかを考えてみてください。

6つの理由に共通しているのは、どれも客先常駐がないこととは関係のない大変さだという点です。自社開発は楽になる働き方ではなく、苦労の種類が変わる働き方だと捉えてください。

「自社開発ならスキルが伸びる」とは限らない

自社開発企業に入っただけで、エンジニアとしての市場価値が上がるわけではありません。転職市場で見られるのは所属企業の業態ではなく、担当した仕事の難しさと、そこで何を判断し、どんな結果を出したかです。

特に注意したいのが、成熟期に入ったプロダクトです。主要な機能が出そろい、仕事の大半が軽微な修正と問い合わせ対応になっている現場では、設計や技術選定を経験する機会がほとんどありません。納期に追われることもなく、落ち着いて働ける環境ではあります。ただ、その居心地の良さに慣れて何年も過ごすと、いざ外に出ようとしたときに説明できる経験が残っていない、という事態になります。

社内独自の仕組みにも気をつけてください。長く続くサービスでは、自社製のフレームワークや社内専用のデプロイツールが使われていることがあります。社内では第一人者になれても、その知識は他社ではほとんど通用しません。加えて、ずっと同じ会社のやり方しか見ていないと、社内の常識を業界の標準だと思い込みやすくなります。コードレビューの基準やテストの書き方が外の現場とずれていても、気づくきっかけがないのです。

では、何が経験の差になるのでしょうか。地味に見えても、既存コードの改善、データ移行、障害の原因調査、性能改善、テスト基盤の整備といった仕事は、実務の力がはっきり身につきます。たとえば、APIを追加しましたと説明するより、高負荷時のボトルネックを特定し、キャッシュの持ち方を見直して応答時間を改善しましたと説明できるほうが、経験の中身ははるかに伝わります。

自社開発で積める経験は、課題を見つけ、設計し、実装し、結果を検証したその範囲で決まります。自社開発に行けばスキルアップできる、という理由だけで転職するのは危険です。社外の勉強会や技術ブログなどで外の空気を入れ続けられるかも含めて、入社後に自分がどんな経験を積めるのかを具体的に描いてから、応募先を選んでください。

自社開発企業なら「モダンな技術」が使えると思ったら危険

自社開発とモダンな技術環境は、まったく別の話です。自社サービスを持つ企業でも、十年以上前に作られたシステムを慎重に保守しながら動かしている現場はいくらでもあります。

すでに利用者がいて売上を生んでいるシステムを作り変えるのは、簡単ではありません。移行期間中は新旧の二重運用が発生しますし、既存データとの互換性、障害のリスク、チームの学習コスト、採用のしやすさまで考える必要があります。古い構成が理想的だとは言いません。とはいえ、安定して稼いでいる仕組みを無条件に置き換えない判断には、十分な合理性があります。新技術の導入より事業の継続が優先されるのは、自社サービスを運営する会社として当然のことです。

求人票の技術スタック欄にも読み方があります。あそこに並んでいる技術名は、会社全体で使っている技術を合算したものであることが多く、配属されるチームの技術とは限りません。新規事業のチームだけがモダンな構成で、主力サービスは古いフレームワークのまま。こうした二層構造の会社はよくあります。

技術選定の考え方についても触れておきます。使いたい技術と会社が必要としている技術は、一致しません。会社がエンジニアを採用するのは事業の課題を解決するためであって、個人が新しい技術を試すためではないからです。技術を選ぶ権利は、その技術を入れたあとの運用や障害対応に責任を持つ人にあります。

逆の見方もできます。古いフレームワークを使っている会社でも、段階的な刷新計画があり、テストの自動化や監視の改善に関われるなら、技術者として得るものの大きい環境です。技術名の一覧で求人を選ぶのではなく、その技術で何を開発し、今後どう変えていこうとしているのか。見るべきはそちらです。

こんな理由だけで自社開発へ転職するのはやめたほうがいい

ここまで読んで、自社開発はやめたほうがいいのかと感じた人もいるでしょう。ただ、自社開発に惹かれる理由そのものが間違っているわけではありません。客先常駐をやめたい、技術を深めたい、年収を上げたい。どれも転職のきっかけとしては自然なものです。

危ないのは、その理由だけで応募先を決めてしまうことです。次の5つは、採用する側から見て、入社後のギャップにつながりやすいと判断する志望理由です。

SESより楽そうだから

客先常駐がなくなれば、常駐先ごとに変わるルールや、契約範囲の外には口を出せないもどかしさからは解放されます。これは確かに大きな変化です。ただ、代わりに生まれるのが当事者としての重さです。障害が起きても、仕様が曖昧でも、それを引き取る先は自分たちのチームしかありません。

常駐先の人間関係に疲れた、今の環境を変えたい、という動機自体は十分に成り立ちます。環境を変えるために何から手をつけるかはSESから脱出したいと思ったら最初にやることで解説しています。問題は、常駐がなくなることと仕事が楽になることを同じだと考えている場合です。苦労の種類が変わるだけだと理解したうえで、その苦労なら引き受けられるかを考えてください。

自社サービスなら自由に開発できそうだから

自社開発で自由になるのは、多くの場合、作り方のほうです。何を作るかは事業の優先順位で決まります。設計の方針やコードの書き方、ツールの選び方にはエンジニアの意見が通りやすい会社でも、どの機能を作るかについては事業側の判断が上に来ます。

自由度を求めて転職するなら、どの範囲の自由が欲しいのかをはっきりさせてください。作り方に口を出したいのか、作るもの自体を決めたいのか。後者を求めるなら、エンジニア職よりもプロダクトマネージャーに近いポジションを探したほうが、期待とのずれは小さくなります。

モダンな技術を使えそうだから

技術スタックは、事業の状況、既存システム、チームの体制で決まります。モダンな技術が並んだ求人でも、配属先が主力の古いシステムということは普通に起こります。

技術を理由に選ぶなら、今使っている技術より、技術を入れ替えるときの意思決定の仕組みを見てください。現場のエンジニアが提案し、導入まで進んだ事例があるかどうか。そこが確認できれば、入社時点の技術が古くても、自分の手で変えていける余地があると判断できます。

市場価値が上がりそうだから

自社開発にいたという経歴だけで、市場価値は上がりません。評価されるのは、そこで何を担当し、どんな課題をどう解決したかです。

市場価値を理由にするなら、入社して2〜3年後の職務経歴書に何を書けるかを想像してみてください。要件の整理、設計、実装、リリース、運用、効果測定のうち、どこまでを自分の経験として語れるのか。書ける行が増えない環境であれば、自社開発であっても市場価値は伸びません。

年収や待遇が良さそうだから

年収を決めるのは、自社開発という形態ではなく、その会社の稼ぐ力と評価制度です。プロダクトの利益率が高く、エンジニアの貢献を給与に反映する仕組みがある会社なら待遇は良くなります。反対に、プロダクトが伸び悩んでいる会社では、責任と業務範囲だけが広がって年収は変わらない、という転職にもなりかねません。

条件面を重視するなら、求人票の給与レンジだけで判断せず、等級ごとの評価基準、昇給の実績、夜間対応やオンコールへの手当の有無まで聞いてください。ストックオプションのように将来の業績次第で価値が変わる報酬は、あてにしすぎないほうが安全です。

5つに共通しているのは、自社開発という看板に、今の不満の解決を期待している点です。看板ではなく、その会社で実際に任される仕事で判断する。そのための具体的な確かめ方を次に解説します。

自社開発へ転職するなら求人票でここを確認する

求人票の自社サービス、自社プロダクトという言葉からわかるのは、その会社が自社サービスを持っていることだけです。入社後に何を任されるのかまでは書かれていません。求人票は良い面を中心に書かれるものなので、書かれている言葉を手がかりにしつつ、足りない部分は面接で具体的に聞き出す必要があります。

なお、自社開発を掲げながら実際は客先常駐が中心という求人の見分け方は、自社開発企業に受からないときの対処法の中で触れています。ここでは自社サービスが実在する前提で、入社後の仕事を見極めるポイントに絞ります。

配属されるプロダクトとその成長段階

複数のサービスを持つ会社では、まず配属予定のプロダクトを特定します。そのうえで見ておきたいのが、プロダクトがどの段階にいるかです。立ち上げ直後なら仕様が固まっておらず、作っては捨てる開発が続きます。成長期なら機能追加と負荷対策に追われます。成熟期に入っていれば、保守と小さな改善が中心です。縮小や統合が検討されているサービスだと、開発そのものが止まる可能性もあります。

同じ自社開発でも、段階が違えば求められる動き方も、身につく経験もまったく別物です。面接では、このプロダクトは今どのフェーズにあり、1年後にどうなっていたいか、と聞いてみてください。答えが具体的な会社ほど、エンジニアに任せたい仕事もはっきりしています。

新規開発と保守運用の比率

新規機能の開発ありと書かれていても、それが業務の何割を占めるのかはわかりません。新規開発、既存機能の改修、問い合わせ対応、障害対応、定型の運用作業に、それぞれどのくらいの時間を使っているのかを聞きましょう。

割合を答えにくそうにしていたら、直近の半年でこのチームがリリースした機能を教えてもらう方法もあります。具体的な機能名が次々に出てくるなら、開発がきちんと回っている証拠です。保守中心の現場が悪いわけではありません。期待していた仕事と実態のずれを、入社前に知っておけるかどうかが分かれ目です。

エンジニアの担当範囲

実装だけなのか、要件の整理、設計、コードレビュー、テスト、リリース、監視、障害対応まで持つのか。担当範囲は会社によってかなり幅があります。自分が伸ばしたい工程と求人の担当範囲が重なっているかを軸に判断してください。

フルスタック歓迎という表現を見かけたら、少し立ち止まる必要があります。幅広い技術を学べる環境という意味のこともあれば、人が足りないので一人で全部やってほしいという意味のこともあるからです。どちらなのかは、チームの人数と役割分担を聞けば見えてきます。

要件定義・設計にどこまで関われるか

プロダクトマネージャーや事業部が決めた仕様を実装する体制なのか、エンジニアも課題の整理や仕様の検討に加わるのか。ここで仕事の性質は大きく変わります。

求人票にある裁量が大きいという言葉は、この点で確かめます。面接では、直近の開発案件でエンジニアがどの段階から参加したか、エンジニアの指摘で仕様が変わった例はあるか、を聞いてみてください。例がすぐに出てこないなら、その会社の裁量とは実装方法を選べる程度の意味だと考えておくほうが安全です。

技術選定の決定権はどこにあるか

技術選定に関われるという求人でも、実際にはCTOやテックリードが一人で決めている場合があります。提案はどこでできるのか、レビューは誰がするのか、導入したあとの運用責任を誰が持つのか。ここまで聞くと、裁量の実態がつかめます。

聞き方としておすすめなのは、最近導入した技術と、逆にやめた技術を一つずつ教えてもらうことです。導入や廃止に至った経緯を具体的に語れる会社は、技術選定のプロセスが機能しています。

開発チームの人数と役割

人数だけでなく、プロダクトマネージャー、デザイナー、QA、インフラ担当がいるかどうかを確かめます。少数精鋭という言葉は、裏を返せば一人あたりの守備範囲が広いという意味です。QAがいなければテスト設計はエンジニアの仕事になりますし、インフラ担当がいなければサーバーの面倒も自分たちで見ることになります。

少人数のチームは幅広い経験を積める環境でもあります。とはいえ、特定の人に仕事が集中し、その人が休むと誰も対応できない状態に陥りやすいのも事実です。コードレビューをしてくれる人がいるか、困ったときに相談できる相手がいるかまで聞いておいてください。

リリース後の運用・障害対応の体制

障害が起きたとき、一次対応は誰がするのか。夜間や休日の当番制はあるのか、あるならどのくらいの頻度で回ってくるのか。オンコールへの手当、エスカレーションの流れ、障害後の振り返りのやり方も確認の対象です。

運用経験を積めるのは強みになりますが、体制が曖昧なまま入社すると、いつ呼び出されるかわからない状態で働くことになります。振り返りの場で個人を責めず、仕組みの改善を話し合う文化があるかどうかも、長く働けるかを左右します。

技術的負債を改善する時間があるか

技術的負債を課題だと認識している会社は多くても、実際に改善へ時間を割いている会社は限られます。直近で行ったリファクタリングやテスト整備の事例と、改善作業に使っている時間の目安を聞いてみてください。

改善のためのタスクを誰が起票し、どうやって優先順位をつけているのかまで答えられるなら、機能開発以外の仕事も評価される文化があると判断できます。いつかやりたいとは思っている、という答えしか返ってこないなら、その負債は入社後もあなたの前に積まれたままです。

ここまでの内容を、求人票の表現ごとに整理すると次のようになります。

これだけの質問を面接の限られた時間で全部ぶつけるのは難しい、と感じる人もいるでしょう。求人票に載らない開発体制や配属先の情報は、企業とやり取りを重ねている転職エージェントを通すと、応募前に確かめやすくなります。どのエージェントを使うか迷う場合は、自社開発企業への転職に強いエージェント・サイトを比較してみてください。

質問項目を埋めること自体が目的ではありません。自分がその会社で、どのプロダクトに、どの範囲まで関わるのか。それを入社前に具体的な言葉で説明できる状態にすることが、この確認のゴールです。

まとめ｜自社開発エンジニアを目指すなら「会社」ではなく「仕事」を見る

自社開発への転職は、客先常駐から抜け出すことや、流行の技術を使うことをゴールにするものではありません。そのプロダクトが解決している課題に関心を持ち、作った機能を長く運用し、結果を見ながら改善し続ける仕事です。

この記事で見てきた大変さを引き受けたうえで、それでもこのプロダクトを育てたいと思えるなら、自社開発は迷わず目指していい働き方です。反対に、自社開発という肩書きに今の不満の解決を期待しているだけなら、転職先がどこであっても同じ不満を抱えることになります。

判断の基準は、自社開発企業に入りたい、ではなく、このプロダクトで、この課題に対して、この範囲の仕事をしたい、です。応募する前に、この一文を自分の言葉で埋められるか試してみてください。埋められないなら、会社名や業態で応募先を選んでいるサインです。

自社開発だからやめておけ、という話ではありません。ただ、自社開発なら今より良くなる、という期待だけで転職するのはやめたほうがいい。仕事内容を確かめてから、その会社を選ぶ。この順番を守れば、やめとけという言葉に振り回されることはなくなります。

SESや受託開発から自社開発を目指す場合の、経験の棚卸しや職務経歴書のまとめ方はSESから自社開発へ転職する方法で詳しく解説しています。この記事で仕事の中身を見極める視点を持ったうえで、具体的な転職準備に進んでください。

もう一度「」を読む ↑