IT転職 自社開発・SES・受託の違い｜仕事内容で選ぶ方法

01自社開発・SES・受託の違いを比較表で整理

POINT

三つの違いは契約と指揮命令、関われる工程、働く場所、評価の材料の4点で比べると整理できます。

契約形態と指揮命令の違い

最初に見るのは「誰が自分に仕事の指示を出すのか」です。ここがはっきりすると、残りの項目も読み解きやすくなります。

SESと受託は契約の考え方が異なります。SESは準委任契約で業務の遂行に対して報酬が支払われ、受託は請負契約で納品した成果物に責任を負う、と説明されることが多いです。

契約名と実態は別物です。厚生労働省の資料では、請負は注文主と労働者の間に指揮命令関係がない点が労働者派遣と異なるとされています。形式が請負でも、実態として注文主が直接指揮すれば派遣に当たる（いわゆる偽装請負）と整理されています。

求人に「受託」「SES」と書かれていても、日々の指示が誰から出るのかは入社前に確かめてください。

IT転職で自社開発を狙う場合、この指揮系統が自社で完結するかどうかが大きな分かれ目です。ただしSESでも、常駐先でどんな作業を任されるかは案件で大きく変わります。判断の材料は「SESかどうか」ではなく、配属予定の現場で誰が指示を出し、どの範囲を任されるかです。

開発範囲と関われる工程の違い

工程の関わり方は、キャリアの伸び方に直結します。厚生労働省の職業情報提供サイト（job tag）は、SIerの開発の流れを「要件定義、基本設計、詳細設計、プログラミング、テスト、納品」と整理しています。

自社開発では、企画から設計、開発、運用、改善までを自社内でつなげて担当することが多いです。受託は要件定義からテストまでを自社で担うケースが中心で、納期と要件が決まったプロジェクト型の進め方になります。

SESは常駐先の体制に組み込まれるため、担当するのは指定された一部分になる傾向があります。

• 自社開発：企画から運用まで一貫して関わりやすい
• 受託開発：要件定義からテストまでを担当しやすい
• SES：現場が決めた範囲を担当することが多い

上流と下流は立場の上下ではありません。job tagも、上流・下流は仕事内容や必要なスキルが異なるための区別だと説明しています。下流のプログラマーから上流のSEへキャリアを移す道もあるとされています。

決められた仕様を正確に実装する力は、どの体制でも土台になります。自分が今どの工程にいて、次にどの工程へ広げたいのかを言葉にすると、体制ごとの向き不向きが見えてきます。

働く場所・チーム体制の違い

働く場所は、日々の暮らしに響く項目です。自社開発は自社オフィスやリモートが中心で、チームも自社メンバーで構成されます。SESは常駐先のルールと環境に従うため、勤務時間や場所の自由度は現場次第です。

受託は自社で開発するケースもあれば、顧客先に常駐するケースもあります。「受託は常駐なし」と決めつけるのは危険です。

job tagによると、インターネット分野の組織は他企業と比べてフラットで、Webディレクターのもと比較的少人数のチームで動くのが一般的です。

同じメンバーと長く働く分、人間関係は固定されやすくなります。信頼関係を築きやすい反面、相性が合わないと逃げ場が少なくなります。これはデメリットとして頭に置いてください。

SESの場合、現場が変わるたびにチームも変わります。新しい人間関係に慣れやすい人には強みになりますが、腰を据えて同じ仲間と作りたい人には落ち着かない環境です。

求人に「フルリモート可」とあっても、案件によって出社が必要になることがあります。実際に、ハローワークの求人でも、就業場所が本社または各プロジェクト先で案件により変動すると明記された例があります。

IT転職で自社サービスの企業を探すときは、働く場所が固定か変動かを必ず確認してください。

評価と収入の決まり方の違い

評価は「何を見て決まるか」で比べると実用的です。自社開発ではプロダクトへの貢献やスキルが材料になりやすく、受託ではプロジェクトの実績、SESでは契約条件や現場での評価が影響しやすいと言われます。

年収の水準を体制別に断定することはできません。厚生労働省の2024年3月の調査報告書では、ITスキルレベルが高いほど賃金水準が高くなる傾向があるとされています。企業は採用時にITスキルレベルを最も重視する、という結果も示されています。

この調査から読み取れるのは、収入が体制の名前よりスキルの水準と相関しやすいことまでです。自社開発に移れば自動的に年収が上がる、という話にはなりません。

自社開発は事業の成否が給与や賞与に反映されます。伸びれば報酬が改善する可能性がありますが、業績が振るわなければ逆に響きます。

• 評価基準が文書で示されているか
• 昇給の仕組みが説明されるか
• 固定残業代の金額と時間数が明記されているか

この3点は、体制を問わず確認できる項目です。求人票の読み方や面接での聞き方については、後の章で詳しく扱います。

02自社開発企業の仕事内容は？企画から運用まで続く改善サイクル

POINT

自社開発の仕事は、リリースがゴールではなく、公開後に改善を重ね続ける点にあります。

サービスを育てる日々の業務の流れ

自社開発では、公開したサービスを使い続けてもらうために手を入れ続けます。企画、設計、開発、運用、改善という流れを、同じ社内で何周も回すイメージです。

SIer/SESの受託開発は、要件定義から納品までの流れで進みます。一方、自社開発中心のインターネット分野では、納品で終わらず運用しながら育てる仕事が軸になります。厚生労働省の職業情報提供サイトによると、両者はビジネスモデルが大きく異なり、求められるスキルや働き方も違います。

日々の動きを大まかに挙げると、次のとおりです。

• ユーザーの声や利用状況を見て課題を拾う
• 改善案を出し、優先順位をチームで決める
• 設計と実装を行い、コードレビューを受ける
• テストしてリリースし、挙動を見守る
• 不具合や要望に対応し、次の改善へつなげる

業界団体のインタビュー記事には、社内コンテストから生まれた自社プロダクトの開発リーダーが登場します。2019年6月にリリースした後も、ユーザーの改善要望に応じたアップデートや不具合修正を随時行っているそうです。

つまり、リリース日は仕事の区切りになりません。公開後の数字や反応が次の作業を決めるため、「作って渡して終わり」の働き方に慣れた方は、この感覚の違いに驚くかもしれません。

既存サービスの技術更新も、欠かせない仕事です。別のインタビューでは、約10年運用された勤怠管理サービスをクラウドへ移行する業務が紹介されています。1万人以上が同時にアクセスするサービスを、少人数のチームで主体的に進めているとのことです。

新機能を足す仕事に加えて、土台を入れ替える仕事もあります。派手さはなくても、サービスを止めずに支える力が評価されやすい領域です。

IT転職で自社開発を検討する方は、募集職種の説明文で「運用」「改善」の言葉がどれだけ具体的か見てください。仕事の中身を想像しやすくなります。

エンジニアが担う役割（フロント・バックエンド・SREなど）

自社開発の現場では技術領域ごとに役割が分かれますが、どこまで細かく分けるかは会社の規模によってかなり違ってきます。

代表的な役割は次のとおりです。

表はあくまで分担の一例です。職業情報提供サイトによると、インターネット分野は比較的小規模な事業者が中心で、組織はフラットな傾向があります。

Webディレクターのもと、少人数のチームで活動することが一般的です。Webエンジニアが企画・設計、プログラミング、保守・運営を兼ねることも多いとされています。

小さな会社では、肩書きが「バックエンド」でも画面側やインフラに触れる場面が増えます。専門を深めたい方は、役割がどこまで分かれているかを求人票や面談で聞いてください。

使う技術は職種によって違います。同サイトはWebエンジニアの使う言語として、Java、JavaScript、PHP、Ruby、Python、C言語などを紹介しています。

SREは、サービスを止めない仕組みをつくる役割です。障害が起きたときの対応や、リリースの自動化などを受け持つ会社が多い傾向にあります。SESや受託の現場では運用担当が別会社になることもあり、運用まで関われる点は自社開発ならではの広がりです。

職種の違いそのものは、別の記事で整理しています。フロント、バック、SREの境目を詳しく知りたい方は、Webエンジニアの職種地図｜フロント・バック・SREの違いをご覧ください。

開発以外に求められる業務（企画への意見・問い合わせ対応など）

自社開発のエンジニアは、コードを書く時間がすべてではありません。サービスの成長に関わる周辺業務が、仕事の一部になる場合があります。

具体的には、次のような業務です。

• 企画段階での実現性の確認と、改善案の提案
• 営業やカスタマーサポートなど他部署との調整
• 問い合わせの調査と、不具合の切り分け
• リリース後の数字の確認と振り返り

職業情報提供サイトは、BtoCの自社開発企業ではIT技術力に加え、マーケティングの知識やトレンドを読むセンスが求められると説明しています。

仕様どおりに作る仕事から一歩進んで、「なぜこの機能が必要か」「使う人にとって分かりやすいか」まで考える場面が増えます。前述のインタビューでも、利用者のITリテラシーが異なる点を意識して使いやすさを重視していると語られていました。

この働き方には向き不向きがあります。コードに専念したい方には、会議や調整が負担になる場合があります。プロダクトの方向性に関わりたい方には、意見が反映される機会として魅力になります。

インタビュー事例の中には、開発リーダーが他プロジェクトと兼務しており、プロダクトだけに集中できないという悩みも出ていました。

自社開発だから専任で打ち込めるとは限りません。応募先の兼務状況や、問い合わせ対応が当番制か専任窓口かは、面談で聞いてください。

03自社開発は「やめとけ」「きつい」と言われる理由とデメリット

POINT

自社開発のつらさは、選考の高さ、事業リスク、技術の偏り、役割の広さの4点に集約されます。

求められるスキル水準が高く、選考の難易度が上がりやすい

IT転職で自社開発を目指すとき、最初にぶつかるのが選考のハードルです。自社サービス企業は即戦力を中心に採るところが多く、開発力に加えて課題解決力やチームで動く力も見られます。

厚生労働省の調査報告書（令和6年3月公表）では、企業は採用時にITスキルレベルを最も重視し、次いで経験・成果を重視すると整理されています。つまり、「何年やったか」より「何を作り、どう改善したか」を問われやすいということです。

選考で確認されやすい点は、次のようなものです。

• 要件定義や設計への関与の経験
• チーム開発の経験（Git運用、コードレビューなど）
• テストや品質への意識
• 設計判断の理由を説明する力
• コーディングテストへの対応

SESや受託の現場で下流工程が中心だった方は、設計や仕様決定に関わった実績が薄くなりがちです。そこが書類で見えにくく、通過率が伸びない原因になることがあります。

もう一つ見逃せないのが、求人数の事情です。国内の開発会社は受託やSESが多く、自社サービスの会社は相対的に限られるという見方が一般的です。応募先が少ないぶん、人気企業に応募が集まりやすくなります。

「落ちたから向いていない」と結論づけるのは早計です。経験の見せ方と応募の幅を見直してみてください。具体的な準備は「未経験・SES経験者が自社開発の選考を通るための準備」の節で扱います。

事業の成否が処遇や雇用に響くリスク

自社開発では、プロダクトの成長がそのまま会社の成長になります。うまくいけば給与や賞与に反映され、スタートアップならストックオプションのようなリターンもあります。

一方で、同じ仕組みが逆に働く場面もあります。主力サービスの売上が落ちれば、賞与の減少、投資の縮小、組織の再編につながりかねません。

SESや受託では、案件が終わっても別の案件に移れることが多いのが実情です。それに対して自社開発は、「会社の一本柱」が揺らぐと影響が直接届きやすい構造です。

特に単一のプロダクトに依存している会社は、次の点で不安定になる場合があります。

• 主力サービスの売上が一部の顧客に偏っている
• 資金調達に頼って運営している
• 競合の台頭で市場が急に変わる

IT分野は技術の革新や新しいトレンドが生まれるサイクルが非常に速いとされています。人気だったサービスが数年で陳腐化することも珍しくありません。

対策は、入社前に事業の中身を見ておくことです。上場企業ならIR資料で売上の推移や、事業の柱が複数あるかを確認できます。非上場なら、資金調達の状況や市場規模、競合との違いが判断材料になります。

年収の上下も、この事業の勢いに左右されます。「自社開発だから安定」とは限らない点を、あらかじめ頭に入れておきましょう。

使用技術が固定化してスキルが偏る可能性

自社サービスは、同じプロダクトを長く育てていきます。そのため、使う言語やフレームワーク、インフラ構成が数年単位で変わらないことがあります。

複数の現場を渡り歩くSESとは対照的で、新しい技術に触れる機会は会社の方針に左右されます。たとえば10年近く運用してきたサービスを抱える会社では、古い構成を保守する時間が長くなる場合があります。逆に、その技術を深く扱える人材としての価値は高まります。

ここは、メリットとデメリットが表裏一体の部分です。整理すると次のようになります。

表のとおり、固定化は一方的な欠点ではなく、深さと引き換えの性質を持っています。ただし、その技術が市場で需要を保てるかどうかは、会社選びの時点で見ておきたいところです。

モダンな環境を導入する文化の会社は多いとされますが、会社ごとに差があります。技術ブログや登壇資料を継続的に出している会社は、エンジニア主導で学習や改善が回っていることが多いです。

社内の勉強会や副業・自己学習の制度があるかどうかも、偏りを補う手段として確認しておくと安心です。IT業界では、業務時間外の自己研鑽も求められるとされています。

担当範囲が広がり、人間関係も固定されやすい

自社開発の現場では、コードを書くだけで一日が終わらないことがあります。サービス改善の企画提案、他部署との調整、リリース後の運用対応まで担うケースがあるためです。

インターネット分野では、Webエンジニアが企画・設計、プログラミング、保守・運営など複数の業務を担当することも多いとされています。

「開発に専念したい」という方には、負担に感じられるかもしれません。一方で、プロダクトマネージャーやテックリードを目指す方にとっては、経験を積む機会にもなります。

少人数のチームでは任される範囲が広く、意見や提案が取り入れられやすいという声が、自社サービスのエンジニアのインタビューにも見られます。裁量が大きいことは、責任の重さと隣り合わせです。

人間関係の面では、所属チームがほぼ固定されます。プロジェクトごとに顔ぶれが変わるSESと違い、同じメンバーと長く働くのが基本です。

信頼関係を築きやすい反面、相性が合わないと逃げ場が少なくなります。グループ会社の場合は、親会社の意向に左右されやすいという指摘もあります。

こうしたズレを減らすには、面接で次の点を聞いておくのが有効です。

• 開発以外の業務の割合と内容
• チームの人数と役割分担
• コードレビューやスクラムの運用方法
• 他部署との連携の頻度

担当範囲の広さを「成長の場」と受け取れるか、「負担」と感じるかは、ここは人によって判断が分かれるところです。

04求人票の読み方～「自社開発」の表記で確認したい項目～

POINT

「自社開発」の四文字より、事業内容・勤務地・契約形態の具体的な記載で判断するほうが、入社後のずれを減らせます。

事業内容欄で自社サービスの有無を確認する

IT転職で自社開発の求人を見るなら、最初に読むのは事業内容欄です。自社サービスの名前や提供先が具体的に書かれているかを確かめます。

たとえば、自社プロダクトの名前を挙げて運営していると書かれていれば、実態を調べる手がかりになります。一方、「幅広いITソリューションを提供」とだけある場合は、何を自社で持っているのかが読み取れません。

前述の通り、インターネット分野ではBtoCの事業を自社開発中心で進める企業が多い傾向があります。ただし、これはあくまで傾向の話です。すべての企業に当てはまるわけではありません。

事業内容欄で見ておきたい点は次のとおりです。

• 自社サービス名の記載
• サービスの利用者（個人か企業か）
• 受託・SES・自社開発の事業が併記されていないか

求人には「SES事業、受託開発事業、自社開発事業を幅広く展開」と書き、参画先を経験やスキルに応じて決める会社もあります。この場合、自分が自社開発事業に入れるのか、受託や常駐側に回るのかは、事業の並びだけでは判断できません。

複数の事業が併記されているときは、自分の配属先がどれに当たるのかを仕事内容欄とあわせて読みます。面談で確認する前提にしておくと安心です。

仕事内容と開発体制（チーム人数・担当範囲）を読む

自社サービスの存在を確認したら、次は仕事内容欄です。そのサービスのどこを担当するのかを読みます。「Webアプリの開発」という一行だけでは、新機能の設計から運用までを担うのか、既存機能のテストだけなのかが分かりません。

目安になるのは、工程と人数の書き方です。先ほど触れたとおり、この分野では少人数のチームで企画から運営まで幅広く担当することが多いため、求人票でも担当範囲の広さがどう書かれているかを見ましょう。

読むときの観点を挙げます。

• 担当工程（要件定義、設計、実装、運用）の明記
• チーム人数と職種構成
• コードレビューやスクラムなど進め方の記載
• 担当するサービスや機能の具体名

工程の書き方にも注意が必要です。「要件定義、設計、開発、テスト等」と並んでいても、実際の割り当ては現場で変わる場合があります。「運用保守が中心」「テスト業務」とだけある求人は、上流の経験を積みたい人には合わない可能性があります。

仕事内容が曖昧だと感じたら、そのこと自体が確認事項です。応募前に気づいた点を書き出しておくと、面接で質問しやすくなります。

勤務地・常駐の有無・契約形態の書き方に注意する

「自社開発」と書かれていても、勤務地がどこかは別の問題です。就業場所の欄に「本社または各プロジェクト先」とあれば、客先で働く可能性があります。SES職の求人には、就業場所を本社または各プロジェクト先とし、案件により変わると記載する例があります。

見るべき項目を表にまとめます。

2024（令和6）年4月1日以降、ハローワークの求人票には、雇い入れ直後の就業場所・業務内容を明示する必要があります。将来の配置転換などで変わり得る場合は、変更後の内容も明示が必要です。ただしこれはハローワークの求人票の扱いで、民間の求人媒体すべてに同じ記載があるとは限りません。

契約の面では、請負は注文主と労働者の間に指揮命令関係がない点が派遣と異なります。ただ、どちらに当たるかは契約の名称ではなく実態で判断されます。求人票の言葉だけで客先での働き方を決めつけず、誰の指示で働くのかを面談で聞くほうが安心です。

つまり、常駐があること自体を一律に避ける必要はありません。自分の希望する働き方と記載が合っているかどうかが、判断の軸になります。

想定年収・固定残業・評価制度の記載を見る

年収欄は、金額の高さより内訳を読みます。固定残業代を含む場合は、基本給と分けて、対象時間数・金額・超過分の割増賃金を明示する必要があるとされています。

求人によっては、月給の幅の中に固定残業代の金額が含まれ、40時間を超える時間外労働は追加支給と書かれている例があります。月給の下限だけで比べると、固定残業代を含む額と含まない額を取り違えるおそれがあります。

確認する点を並べます。

• 月給に固定残業代が含まれるか
• 固定残業の対象時間数と金額
• 超過分の支給の記載
• 経験者と未経験者で賃金が異なる場合の条件

賃金欄の下限は、応募基準を最低限満たす人を採用した場合に支払う予定の金額を書く決まりです。経験が浅い人は下限に近い額になる場合もあります。自分の経験での想定額は、面談で聞いておくとよいでしょう。

評価制度は、求人票で触れられないことも多い項目です。「プロダクトへの貢献」「スキル」のどれを見るのか、昇給の時期や仕組みが書かれていれば参考になります。書かれていなければ、面接の質問に回しましょう。

自社開発かどうかだけで、年収が上がる・下がると決まるわけではありません。会社ごとの条件と自分の経験で変わります。

要注意な表現と、確認が必要なサインの例

「自社開発」の語が目立つ求人でも、確認を重ねたほうがよい記載があります。次のような組み合わせは、実態を聞く優先度が高いサインです。

• 「自社開発」と書きながら、就業場所がプロジェクト先
• 案件により働き方が変わるという表現
• 自社サービス名が書かれていない
• 業務内容が一行で終わっている
• 運用保守・テスト中心でスキル要件が極端に低い

これらがあるから不適切な求人だと決まるわけではありません。ただ、入社後に思っていた仕事と違うと感じる原因になりやすい記載です。

求人情報では、職種や業務内容について実際の業務と著しく離れた名称を使ってはならないとされています。グループ企業と混同させる表示も禁止です。表示に疑問を持ったら、求人を出した会社と実際の勤務先が同じか、事業内容欄の主体はどこかも読み返しましょう。

検索結果の一覧では、同じ「自社開発」の語でも、自社勤務、社内SE、パッケージ開発、受託開発などが混ざる場合があります。ひとつの求人を読むときは、この表記が何を指しているのかを考えながら、事業内容、仕事内容、就業場所を照らし合わせてみてください。

気になる記載にはメモを付け、面接での質問に変えておきます。IT転職で自社サービスの開発に進みたい場合、こうした確認が応募先を絞る手がかりになります。

05「自社開発」を名乗る企業をどう見抜く？公式情報での裏取り

POINT

求人票の「自社開発」は自己申告です。採用ページ、技術ブログ、IRの3点と面談の質問で、実態を照合できます。

採用ページ・技術ブログ・IR情報で事業の実態を確認する

IT転職で自社開発の求人に応募する前に、企業が自前で運営するサービスの実体があるかを確かめておきたいところです。求人票は企業の自己申告にすぎません。公開情報と見比べると、表記の確かさがかなり見えてきます。

たとえば、同じ求人に「SES事業、受託開発事業、自社開発事業を幅広く展開」と書かれている例があります。ハローワークの公開求人にも、そうした書き方をする企業が実際にあります。

率直に言うと、この書き方だけでは判断がつきません。応募先の配属が自社サービスなのか、他の事業なのかは、求人票からは読み取れないのです。

確認する情報は、次の3つが中心です。

• 採用ページ：自社サービス名、エンジニアの所属部署、チーム構成
• 技術ブログ・登壇資料：継続的な発信の有無、設計や改善の中身
• IR資料（上場企業）：主力事業、売上の内訳、単一サービスへの依存度

技術ブログは、更新が続いているかどうかだけでなく、書き手が開発チームのメンバーかどうかも見どころです。サービスの改善や移行の経緯が具体的に書かれていれば、エンジニアが主導して運用している可能性が高まります。逆に、技術以外の話題ばかりなら、開発の実態は別の方法で確かめましょう。

非上場企業にはIRがありません。そのぶん、プレスリリースやサービスの更新履歴、資金調達の発表などから事業の継続性を確かめます。エンジニアの在籍人数や、中堅からベテランまで層が揃っているかも、採用ページから読み取れる場合があります。

公的な職業情報でも、BtoBの受託開発とBtoCの自社開発ではビジネスモデルが大きく異なり、求められるスキルや働き方も違ってくるとされています。応募先がどちら寄りなのかを公開情報で先に見当づけておくと、面談での質問が具体的になります。

受託や客先常駐の割合を面談で聞く

公開情報で見当がついたら、残りは面談やカジュアル面談で本人に確認します。聞きにくいと感じる方もいるでしょう。ただ、入社後の認識違いを防ぐための質問なので、企業側も受け慣れているはずです。

質問のコツは、答えが数字や具体名で返ってくる形にすることです。「自社開発ですか」と聞くと「はい」で終わってしまいます。

• 自社プロダクトの開発に携わるエンジニアは全体の何割か
• 受託開発や客先常駐の案件は、事業全体でどの程度の割合か
• 自分が配属される予定の担当サービス名とチームの人数
• 配属後に、客先常駐やプロジェクト先への異動が発生する可能性

同じ会社でも、事業部によって実態が異なる場合があります。事業の一部が自社開発なら、自分の配属先がそこかどうかが肝心です。実際に、就業場所を「本社または各プロジェクト先で、案件により変動」と記載する求人もあります。

配属が確約されるのか、変更の可能性があるのかは、言葉にして確認しておいてください。

なお、求人票にある「就業場所・業務の変更の範囲」は、令和6年4月1日施行の職業安定法関連の改正で、示すべき労働条件に加わった項目です。面談で答えが曖昧だったときは、書面に明記してもらえるかを尋ねると安心です。

答えを聞いたあとは、内容が採用ページや技術ブログと合っているかを見直します。数字を出すのを避ける、担当サービス名が出てこない、といった反応は判断材料の一つになります。ただし、一度の面談だけで決めつけないでください。複数の担当者に確認できる場があれば、そこでも聞いてみるとよいでしょう。

口コミは一次情報と照らして参考程度にとどめる

口コミサイトやSNSの書き込みは、手軽に内部の空気を知れる反面、扱いに注意が必要です。投稿者の立場や在籍時期、担当部署が分からないことが多く、現在の状況と一致する保証がありません。

特に、事業部ごとに体制が違う会社では、ある部署の評価が全社の実態とは限りません。高評価も低評価も、一人の経験にすぎない点は変わりません。

使い方の目安は次のとおりです。

• 書き込みの内容を、そのまま事実として受け取らない
• 気になった点は、採用ページや面談の回答と照合する
• 複数の情報源で同じ指摘が出ているか確認する
• 在籍時期や職種が分かる場合も、現在との差を考える

たとえば「客先に出された」という書き込みがあれば、面談で客先常駐の有無と割合を質問する材料にします。口コミは結論を決めるものではなく、質問を作るきっかけと位置づけると、判断を誤りにくくなります。

転職の情報収集は、信頼できる情報を選び分ける手間がかかる作業です。それでも、IT分野では企業の公式サイトや技術発信で確かめられる点が多く、一次情報を優先すれば無理なく裏取りができます。IT転職で自社サービスを持つ企業を探すときは、口コミに振り回されず、公式情報と面談で確かめた事実を軸に比べてください。

06未経験・SES経験者が自社開発の選考を通るための準備

POINT

選考で見られるのは経験の量より、何をどう考えて動いたかを説明できるかどうかです。

スキルの棚卸しで経験を言語化する

IT転職で自社開発を狙うなら、最初の作業は応募先探しではなく、自分の経験の書き出しです。SES経験者は「指示された作業をしていただけ」と感じがちですが、工程と役割に分解してみると、意外に語れることが見つかります。

厚生労働省の職業情報提供サイト（job tag）は、開発の流れを要件定義、基本設計、詳細設計、プログラミング、テスト、納品と整理しています。上流・下流は立場の上下ではなく、仕事内容とスキルの違いだという説明です。下流工程の経験も、そのまま誇ってよい経歴です。

職務経歴書に書き出す項目の例です。

• 使った言語・DB・ツールと、それぞれの使用期間
• 関わった工程（設計、実装、テスト、運用保守など）
• チームの人数と自分の役割
• 改善提案や効率化など、指示以外で動いた場面
• 成果を示せる数字（処理時間、不具合件数など）

数字は、実際に把握できるものだけを書いてください。盛った数字は、面接で深掘りされると崩れやすくなります。

自分の強みは、自分では見えにくいものです。勉強会やエンジニア向けのイベントで現役の人に職務経歴を見てもらうと、書き方の癖に気づきやすくなります。

job tagによると、自社開発が中心になりやすいBtoC分野では、IT技術力に加えてマーケティングの知識やトレンドを読むセンスも求められます。普段使っているサービスへの改善案を言葉にしておくと、志望理由の裏付けになります。

ポートフォリオはどこまで作り込むべきか

巨大なサービスを作る必要はありません。小さくても動いていて、読める状態に整っている成果物のほうが評価されやすい傾向があります。

実務経験が浅い人にとって、ポートフォリオは「自走して作れる」ことの証拠です。仕様が固まらない段階で仮説を立てて動けるか、という自社開発で求められやすい姿勢も、成果物から伝わります。

作り込みの目安は次のとおりです。

• 公開URLまたはGitHubのリポジトリがある
• READMEに目的、使用技術、動かし方がある
• コードが読みやすく、変更しやすい構成になっている
• なぜその技術を選んだか説明できる
• 改善した履歴（コミットやIssue）が残っている

見た目の派手さより、後半の2点が効きます。面接官は「なぜそう作ったか」を聞いて、判断の筋道を確かめたいからです。

求人が求める技術に寄せるのも有効です。応募先がReactやTypeScript、クラウド環境を使っているなら、同じ領域で小さな機能を作ると話が通じます。

一方で、作り込みに半年かけて応募が遅れるのは本末転倒です。完成度7割でも公開し、面接のフィードバックで直していくほうが、結果として質も上がります。

実務で書いたコードは守秘義務の対象になるため、そのまま載せるのは避けてください。個人で作り直した題材を使うのが安全です。

スクールで学んだ直後でも選考に挑める？

挑めます。job tagでも、IT業界は特別な資格がなくても働き始められ、未経験者を積極採用する企業もあるとされています。ただし、採用側は入社後の学びに期待できるかを見ているため、準備の中身が問われます。

注意したいのは、スクールの課題をそのまま出さないことです。同じ課題の成果物は他の応募者と似通い、差がつきません。

課題で身につけた技術を使い、自分で題材を決めた個人開発を1つ足してください。身近な不便を解消する小さなWebアプリで十分です。

志望動機では、次の流れを意識すると説得力が出ます。

• 学習で気づいたこと
• 自社サービスの運営に長く関わりたい理由
• 入社後に伸ばしたい領域

「自社開発がかっこいいから」では弱いままです。そのサービスの何に惹かれ、どこを改善したいかまで話せると、熱意が具体的に伝わります。

求人票では、必須条件に実務経験が入っているかを確認してください。実務経験必須の求人にスクール直後で応募しても、書類で止まる可能性が高くなります。未経験歓迎やポテンシャル採用を明記している求人から検討するほうが現実的です。

なお、国の資料ではIT人材の需給は逼迫していると整理されています。ただ、それが未経験者の通過しやすさを保証するわけではありません。

チーム開発経験が少ない場合の補い方

SESでは担当範囲が限定され、チーム開発の流れを経験しにくいことがあります。自社開発の選考ではここを突かれやすいので、補う手段を持っておくと安心です。

補い方の候補は次のとおりです。

• GitHubでプルリクエストとコードレビューを自分で回す
• 個人開発でブランチ運用を実践する
• スクラムなどアジャイル開発の進め方を学ぶ
• OSSの小さな修正に参加する
• 現職で改善提案を出し、記録を残す

現職での提案は、特に説得力があります。「指示されたことだけでなく、改善案を出した経験」は、自社サービスを育てる仕事への適性として伝わるからです。

関連するエピソードがあれば、面接では次の形に整理して話してください。

• 状況：どんな課題があったか
• 行動：自分が何を提案・実施したか
• 結果：何が変わったか

実務での関与が薄いなら、無理に「リードしました」と盛らないことです。「レビューを受けて設計を直した」といった事実のほうが、面接では信頼されます。

自社開発の現場でも、少人数のチームで任される範囲が広く、意見や提案が取り入れられやすい例が公開されています。経験の少なさは、学び方と動き方で補える部分が大きいと考えてください。

07在職中に自社開発へ転職活動を進めるスケジュールの組み方

POINT

在職中の転職は、応募数と通過率から期間を逆算し、平日の固定枠を決めて進めるのが現実的です。

準備から内定までの流れと期間の目安の立て方

IT転職で自社開発を狙うなら、期間は「何か月かかるか」ではなく、応募数と通過率から逆算して決めます。通過率は人によって大きく違うため、月数を一律に言い切ることはできません。

流れは、大きく次の4段階です。

• スキルの棚卸しと職務経歴書の下書き
• ポートフォリオやGitHubの整備
• 企業研究と面接対策
• 応募、選考、内定、退職交渉

前の段階が固まらないまま応募すると、書類で落ちたときに原因が分からなくなります。最初に経歴書の型をつくっておくと、その後の微調整が軽く済みます。

逆算の考え方は、次のように置くと整理しやすいです。

通過率については、取材で「書類通過は10%あれば良いほう」とエージェントに言われたという個人談もありました。あくまで一人の例です。ただ、自社サービス系は人気が高く、数を打つ前提で見積もる人が多い傾向があります。

最初は低めに仮置きし、5社ほど応募した時点で実際の通過数に合わせて見直してください。応募数が足りなければ期間を延ばし、通過率が高ければ短縮できます。

選考期間そのものも会社次第です。たとえばハローワークの求人例では、書類選考の結果は書類到着後7日以内、面接結果は面接後5日以内の通知と記載されています。この例では面接が2回で、結果待ちの日数だけでも数週間の幅が出ます。

複数社を同時に走らせ、結果待ちの時間を他社の準備に充てると、全体の期間が縮みます。

なお、退職の申し出から実際の退社までの期間は、就業規則や引き継ぎ量で決まります。内定後に慌てないよう、規則の確認はこの段階で済ませておくと安心です。

働きながら進めるときの時間の確保

在職中は、使える時間がそもそも限られます。気合で捻出するより、平日と週末の枠を先に固定するほうが続きます。

時間の置き方の一例です。

• 平日の夜に30〜60分、求人確認と応募書類の微調整
• 週末の午前に2時間、ポートフォリオと学習
• 面接用の枠は、有給や半休を数日分あらかじめ確保

作業は種類で分けると進みます。思考が要る職務経歴書の改善は集中できる日に、求人のチェックや企業のブログ読みは通勤中や隙間時間に回します。

応募書類は、毎回ゼロから作らないのがコツです。共通部分を一本化し、志望動機と強調する経験だけを企業ごとに差し替えると、1社あたりの負担が減ります。

面接後は、聞かれた質問と答えにくかった点をその日のうちにメモに残してください。次の面接の精度が上がります。

SESなど客先で働いている方は、案件の繁忙期と面接日程がぶつかりやすい点にも注意してください。リリース直前の時期は避け、先に候補日を複数出しておくと調整が楽です。

オンライン面接に対応している企業なら、移動時間を削れます。ハローワークの求人例にも、オンライン面接が可能と記載されたものがあります。応募時に面接形式を確認しておくと、日程が組みやすくなります。

職場の人に知られないための配慮も欠かせません。会社の端末やネットワークで応募や連絡をしない、連絡手段は私用のメールと電話に統一する、といった基本は押さえましょう。

働きながらでも焦る必要はありません。収入が途切れない状態で、自社開発かどうかを落ち着いて見極められるのが在職中の強みです。条件が合わなければ見送る余裕を持てるよう、期限は厳しく区切りすぎないことをおすすめします。

08自分に合う開発体制を選ぶための最終チェックリスト

POINT

自社開発かSESかは名前でなく、指揮命令者・工程・配属・評価の10項目を求人ごとに確かめて決めます。

仕事内容・配属・評価で比べる10項目

IT転職で自社開発を狙うときも、SESや受託を検討するときも、使う物差しは同じです。

「誰の指示で、どこで、何を作るか」を10項目に分けて、応募先ごとに埋めてみてください。空欄が多い企業は、情報が足りていない企業です。

• 契約形態と指揮命令者（雇用か、常駐先の指示か）
• 勤務地（客先常駐の有無と頻度）
• 自社プロダクトを開発する時間の割合
• 関われる工程（要件定義から運用まで）
• 技術選定にどこまで関われるか
• チーム人数、コードレビューやスクラムの有無
• 評価基準（成果、プロダクト貢献、スキル）
• 配属の固定性（所属チーム固定か、案件ごとか）
• 働き方（リモート、フレックス、出社頻度）
• 事業の安定性（主力事業、単一プロダクトへの依存）

求人票の段階で確認しやすいのは、①②③です。ハローワークの求人票では、就業場所や業務の変更範囲の明示が2024年4月1日以降に必要になっています。

将来の配置転換で業務や勤務地が変わり得るかどうかも、ここで読み取れます。ただし、民間の求人媒体まで同じ義務かは分かりません。

④〜⑩は、面接や面談で聞かないと見えにくい項目です。「自社開発」と書かれていても、実際の業務が下流工程中心という例はあり得ます。

逆に、SESだから成長できないと決めつける必要もありません。現場ごとに技術や業界が変わる点は、強みになります。大事なのは、その現場で何を担当できるかです。

契約面を見極めるときは、実態で判断されるという原則が役立ちます。請負でも発注者が直接指揮命令すれば、偽装請負として労働者派遣にあたるとされています。

自分の働き方がどちらの形に近いかを知るためにも、①の指揮命令者は必ず聞いておきたい項目です。

職種の違いも確認する～Webエンジニアの職種地図～

開発体制が決まっても、職種が合わなければ入社後に戸惑います。同じ「Webエンジニア」でも、役割の幅は企業ごとに違うからです。

公的な職業情報では、インターネット分野の組織は比較的フラットで、少人数チームが一般的とされています。Webエンジニアが企画・設計、プログラミング、保守・運営を兼ねることも多いようです。

つまり、自社開発の求人では「フロントだけ」「バックだけ」と割り切れない場合があります。得意分野に加えて、隣の領域をどこまで担うかを確認しておくと安心です。

また、BtoBの受託開発では顧客の要件整理や業界知識が、BtoCの自社開発ではマーケティング知識やトレンドを読む力が求められるとされています。

自分の強みは、技術の深さでしょうか。顧客理解でしょうか。それともサービス改善の発想でしょうか。ここを整理すると、職種の選び方が絞れます。

フロントエンド、バックエンド、SREの違いは、次の記事で整理しています。応募先の求人票にある職種名と見比べる際の地図として使えます。

• Webエンジニアの職種地図｜フロント・バック・SREの違い

職種名が同じでも業務範囲が違うことは珍しくありません。気になる求人があれば、チーム内の役割分担まで聞いてみてください。

参考にした公式情報と確認日

本章の確認日は2026年10月24日です。制度や求人票の運用は変わる場合があるため、応募前に各公式サイトで最新の内容を確かめてください。

参照した公的資料と、そこから使った内容は次のとおりです。

表のうち、年収差や離職率のような数値は、公的資料で自社開発とSESを同じ条件で比べたものを確認できていないため、本章では扱っていません。

数字で比べたくなる気持ちは自然です。ただ、条件の違う数値を並べても判断を誤りやすいので、まずは10項目で応募先の中身を確かめることをおすすめします。