「自社開発」は本物か？求人票で見分ける5つのチェックポイント
「自社開発」と書いてあるのに、入ってみたら違った
転職活動をしていると「自社開発」というワードをよく目にする。SESや受託開発から抜け出したいエンジニアにとって、自社開発は魅力的に映る。自分たちのプロダクトに向き合えて、技術選定にも関われて、ユーザーのフィードバックを直接受けられる。そんなイメージを持っている人は多いと思う。
ただ、求人票に「自社開発」と書いてあっても、実態は様々。本当に自社プロダクトを持っている会社もあれば、受託案件を「自社案件」と呼んでいるだけの会社もある。SIerの下請けを「自社開発チーム」と表現しているケースすらある。入社してから「思ってたのと違う」と気づいても遅い。
この記事では、求人票と企業情報から本物の自社開発企業を見分ける方法を整理する。面接で確認すべき質問も含めて、転職前にできるチェックを全部まとめた。
そもそも「自社開発」の定義がゆるすぎる問題
最初に知っておくべきなのは、「自社開発」に業界共通の定義がないということ。転職サイトでの使われ方を見ていると、大きく3パターンに分かれる。
1つ目は、自社でプロダクトを企画・開発・運用しているケース。SaaS企業やWebサービス企業がこれにあたる。ユーザーに直接サービスを提供していて、売上もそのプロダクトから上がっている。多くのエンジニアがイメージする「自社開発」はこのパターン。
2つ目は、受託開発だけど自社内で開発しているケース。クライアント先に常駐するSESとは違い、自社オフィスで開発する。ただし作っているのは他社のシステムで、プロダクトオーナーはクライアント側にいる。求人票では「自社開発」と書かれることがあるが、エンジニアが期待する裁量や技術選定の自由度はプロダクト企業とは異なる。
3つ目は、SES企業が自社サービスを1つ持っているケース。メイン事業はエンジニア派遣だけど、片手間で社内ツールやメディアを運営している。「自社開発あり」と求人票には書けるが、配属されるのはSES案件のほうが圧倒的に多い。
求人票の「自社開発」がどのパターンを指しているかは、書いてある文面だけでは判断できない。だからこそ、具体的なチェックポイントを使って見極める必要がある。
求人票で確認すべき5つのチェックポイント
求人票を見るとき、以下の5つを意識すると本物の自社開発かどうかの精度がかなり上がる。
まず、プロダクト名やサービス名が具体的に書かれているかどうか。本当に自社プロダクトがある会社は、「〇〇（プロダクト名）の開発」と明記する。「自社サービスの開発」とだけ書いてプロダクト名がない場合は要注意。プロダクトの名前を出せない理由があるか、そもそも主力プロダクトが存在しない可能性がある。
次に、技術スタックの具体性。「React / TypeScript / Go / AWS」のように明確に書かれていれば、実際にそのスタックで開発しているチームが存在する可能性が高い。一方、「Java, PHP, Python, Ruby, JavaScript...」と羅列されている求人は、案件ごとに技術が異なるSESや受託の特徴。自社開発なら技術スタックは基本的に1セットに絞られる。
3つ目はチーム構成の記載。「PdM 2名、デザイナー 1名、バックエンド 3名、フロントエンド 2名」のようにプロダクトチームの構成が書かれていれば、自社開発の可能性が高い。「プロジェクトに応じてチームを編成」と書かれている場合は、受託やSESの案件配属型を示唆している。
4つ目は開発プロセスへの言及。スクラムやカンバンといったアジャイル手法、CI/CDの整備状況、コードレビューの文化など、開発プロセスに関する記述があるかどうか。自社開発企業はプロダクトを継続的に改善するから、こうしたプロセスへの投資を積極的にアピールする。納品型の開発ではこの手の情報は出てきにくい。
5つ目は事業モデルの記載。「toBのSaaSで、導入企業数は〇〇社」「MAU〇〇万のtoCサービス」のように、プロダクトの事業規模や成長性に言及があるかどうか。自社のプロダクトで収益を上げている会社は、事業の成長を採用の売りにする。ここがぼかされている場合は、プロダクトの収益性が弱いか、メイン事業が別にある可能性を疑ったほうがいい。
企業サイトで裏を取る3つの確認先
求人票だけで判断するのはリスクがある。必ず企業のWebサイトでも裏付けを取りたい。確認すべきは3つ。
まずプロダクトページ。自社開発企業なら、自社サイトにプロダクトの紹介ページがあるのが普通。サービスの機能説明、料金プラン、導入事例が掲載されていれば、実際に運用されているプロダクトが存在する証拠になる。企業サイトのトップが「受託開発・SES」のサービス紹介になっている場合は、そちらがメイン事業だと考えるのが自然。
次にテックブログやエンジニア向けの発信。テックブログで「〇〇のアーキテクチャをリプレースした話」「パフォーマンス改善で応答速度を30%短縮した」のような記事が定期的に出ていれば、継続的にプロダクト開発に投資していることがわかる。ブログの更新が1年以上止まっている場合は、開発組織に余裕がないか、エンジニア文化の優先度が低い可能性がある。
3つ目は採用ページのエンジニア情報。社員インタビューやチーム紹介で「どのプロダクトに関わっているか」「技術的にどんな挑戦をしているか」が語られているかどうか。エンジニアが顔出しで登場している会社は、エンジニア組織に自信を持っている傾向が強い。採用ページがあっても営業職や管理職の紹介ばかりで、エンジニアの情報が出てこない場合は注意したほうがいい。
面接で確認すべき質問と、その回答の読み方
求人票と企業サイトで「おそらく本物の自社開発だろう」と判断できても、面接でもう一段掘り下げておきたい。聞くべきポイントは3つある。
1つ目は「開発チームの技術選定はどこで意思決定されますか」という質問。自社開発企業なら「CTOとテックリードで議論して決める」「チームで提案してADR（Architecture Decision Record）に残す」といった回答が返ってくる。「クライアントの要件に合わせて選定します」「案件ごとに異なります」という回答なら、受託色が強い。
2つ目は「直近半年で一番大きかった技術的なチャレンジは何ですか」。この質問への回答で、そのチームが実際にどんな開発をしているかが一発でわかる。「マイクロサービスへの移行を進めている」「認証基盤をリプレースした」など、プロダクトの進化に関する回答が出てくれば本物。「新しいクライアント案件で〇〇を導入した」のような回答なら、実質は受託開発の可能性が高い。
3つ目は「エンジニアはプロダクトの方向性にどう関わっていますか」。自社開発の醍醐味は、作るものを自分たちで決められること。PdMとの協業の仕方、スプリントプランニングでのエンジニアの発言権、ユーザーフィードバックへのアクセス。こうした情報が具体的に返ってくるかどうかで、エンジニアの裁量の実態がわかる。
自社開発でも注意すべき3つのパターン
本物の自社開発企業に入れたとしても、すべてが理想的とは限らない。転職後に「こんなはずじゃなかった」となりやすいパターンが3つある。
1つ目は保守運用がメインのプロダクト。リリースから何年も経っていて、新機能の開発がほぼなく、バグ修正と既存機能の維持がメイン。自社開発には違いないが、技術的なチャレンジは少ない。面接で「今後のロードマップ」を聞いて、新機能の開発計画があるかどうかを確認するといい。
2つ目はレガシーが塩漬けになっているケース。PHP 5系やRails 4系のまま動いていて、リファクタリングの予算も人員もつかない。「技術的負債を返済したい」という意志はあるけど、ビジネス優先で手が回らない。これは入社前にテックブログや技術スタックの情報から推測できることもあるが、面接で「技術的負債にどう向き合っていますか」と直接聞くのが確実。
3つ目はプロダクト撤退が近いケース。赤字が続いていて、事業としての先行きが不透明。入社して半年でプロダクトがクローズ、開発チームは解散ということもありえる。企業の資金調達状況やプレスリリースの頻度、Wantedlyなどでの採用ポジションの変化から、事業の健全性を推測することはできる。成長フェーズの指標として、直近1年で社員数が増えているかどうかも参考になる。
まとめ
求人票の「自社開発」は、そのまま受け取ると痛い目を見ることがある。プロダクト名の明記、技術スタックの具体性、チーム構成の記載、開発プロセスへの言及、事業モデルの説明。この5つを求人票で確認し、企業サイトのプロダクトページ・テックブログ・採用ページで裏を取る。面接では技術選定の意思決定プロセスとエンジニアの裁量を掘り下げる。ここまでやれば、「自社開発」の看板に騙される確率はかなり下がる。
受託開発と自社開発の違いをもっと整理したい方は受託開発と自社開発どっちがいい？判断軸を整理を、求人票の読み方を体系的に学びたい方はエンジニア求人票の読み方ガイドもあわせて読んでみてほしい。