SESとか受託開発とか自社開発とか、未経験者には違いがわからなすぎる件

◆はじめに｜SES・受託開発・自社開発で迷う人へ。選ぶ基準は「会社タイプの優劣」ではなく積める経験

SES、受託開発、自社開発。求人票でこの3つを見かけても、未経験の段階だと「結局どれがいいの？」で止まりやすいですよね。
この章では、会社タイプを上下で比べるのではなく、入社後に増える経験から選ぶための見方をそろえます。

・この記事の結論｜どれが正解かではなく、入社後にどんな経験を積みたいかで選ぶ

この記事で一番伝えたいのは、SES・受託開発・自社開発のどれかを絶対の正解にしないことです。
同じSESでも、テスト中心の案件もあれば、設計補助や開発補助に入れる案件もあります。受託開発でも、納期に追われるだけの現場と、要件整理からレビューまでチームで学べる現場では、残る経験がだいぶ違います。
自社開発も、自由に新機能を作れる環境ばかりではありません。既存機能の保守、問い合わせ対応、データ調査、障害調査など、地味だけれどサービスを支える作業が多い会社もあります。

未経験者が見るべきなのは、「会社タイプの名前」よりも、最初の半年で何をするかです。
たとえば求人票に「開発」と書いてあっても、実際はテスト仕様書に沿った確認、Excelでの不具合一覧更新、既存画面の文言修正、ログ調査の補助が中心かもしれません。
一方で、その作業が悪いわけでもないんです。テストから仕様を読み、文言修正からGitの流れを覚え、ログ調査からシステムの動きを理解することもできます。
見るポイントは、「コードを書けるか」だけではなく、「コードを書く前後の工程まで見えるか」です。

IPAのデジタルスキル標準でも、DXを推進する人材について、役割や習得すべきスキルを整理しています。エンジニア転職でも同じで、肩書きよりも、任される役割と身につくスキルを分けて見るほうが現実に近いです。
※参考: https://www.ipa.go.jp/jinzai/skill-standard/dss/index.html

・この記事で分かること｜違い・比較・向いている人・入社前チェックまで整理

この記事では、SES・受託開発・自社開発を、未経験者が求人票と面接で使える粒度まで分解します。
単語の意味だけを覚えても、応募先選びではあまり役に立ちません。必要なのは、「その会社に入ったら、誰と働き、どこで働き、どの工程を担当しやすいのか」まで想像できる状態です。

具体的には、契約形態、働く場所、責任範囲、担当工程、スキルアップ、年収や評価、入社難易度、入社前に聞くべき質問まで扱います。
たとえば、SESなら案件内容・商流・待機期間・自社フォローを見ます。受託開発なら、担当工程・納期管理・顧客折衝・チーム体制を確認したいところです。
自社開発なら、開発組織の人数、既存サービスの保守比率、改善サイクル、技術選定に新人や若手がどこまで関われるかを見ていきます。

ここを整理しておくと、求人票の読み方が変わります。
「自社開発あり」と書かれていても、自社サービスなのか、自社内で受託案件を開発しているのかで働き方は変わります。
「案件選択制」と書かれていても、選べるのが業務内容なのか、勤務地なのか、単価帯なのかで意味は変わります。
この違いを見ないまま応募すると、入社後に「思っていた開発と違う」と感じやすいんですよね。

・先に注意｜未経験転職全般やWeb/インフラ比較は別記事で補足する

この記事は、未経験転職のすべてを扱う記事ではありません。
プログラミング学習の始め方、ポートフォリオの作り方、Webエンジニアとインフラエンジニアの細かい違いまで広げると、SES・受託開発・自社開発の比較軸がぼやけてしまいます。

たとえば、Web系を目指すならHTML/CSS、JavaScript、バックエンド言語、GitHubで見せられる成果物が気になります。
インフラ寄りなら、Linuxコマンド、ネットワーク、クラウド、監視や障害対応の流れを知りたくなります。
でも、この記事では「どの技術を学ぶか」より先に、「どんな会社タイプに入ると、どんな経験が増えやすいか」に絞ります。
学習ルートの話まで混ぜると、まるで旅行先を決める前にスーツケースの中身だけ詰め始めるような状態になってしまうからです。

もちろん、未経験者にとって学習や職種選びは避けて通れません。
ただし、ここでは一度、求人票に出てくる会社タイプの見分け方に集中します。
読み終えたあとに、気になる求人を3社並べて「働く場所」「担当工程」「入社後半年の作業」「評価される経験」をメモできる状態を目指してください。

章まとめ: まずは、SES・受託開発・自社開発を勝ち負けで見ない前提をそろえました。次章では、3つの違いを比較表で整理しながら、未経験者が最初に押さえるべき軸を確認していきます。

◆1. まず何が違う？SES・受託開発・自社開発を比較表で整理

この章では、SES・受託開発・自社開発の違いを、未経験者が求人票を読むときに使える形で整理します。
名前だけを覚えるより、「誰のために、どこで、何を作り、何で評価されるのか」を分けて見ると、だいぶ判断しやすくなりますよ。

・3つの違いを一言で整理｜SESは現場支援、受託開発は成果物、自社開発は自社サービス

まず大枠だけで見ると、SESは顧客先や顧客プロジェクトへの技術支援、受託開発は顧客から依頼されたシステムやアプリの開発、自社開発は自社サービスや自社プロダクトの開発です。
同じ「開発」と書かれていても、仕事の主語が変わります。SESは「顧客の現場を支える」、受託開発は「顧客に納品する」、自社開発は「自社のサービスを育てる」と見ると、最初の整理としてはかなりわかりやすいです。

比較軸	SES	受託開発	自社開発
仕事の向き先	顧客先の現場やプロジェクト	顧客から依頼された成果物	自社サービス・自社プロダクト
よくある働き方	客先常駐、リモート参画、自社待機など案件次第	自社内開発、顧客打合せ、納品前対応	社内チームで改善、保守、新機能開発
評価されやすいもの	現場での貢献、勤怠、技術支援、報告	納期、品質、顧客対応、担当工程	サービス改善、障害対応、ユーザー価値
未経験者が見る点	配属案件と自社フォロー	担当工程とチーム体制	既存サービスの保守比率と育成体制

ここで注意したいのは、SES・受託開発・自社開発という言葉が、必ずしも求人票で厳密に使い分けられているとは限らないことです。
契約の話まで踏み込むと、民法上は請負や委任などが別の契約類型として扱われています。IT業界では、受託開発は請負寄り、SESは準委任寄りで説明されることが多いですが、求人票の文言だけで契約実態まで断定するのは危険です。
※参考: e-Gov 法令検索（民法）

未経験者は、法律用語を細かく暗記するより、まず「成果物を納品する仕事なのか」「人やスキルを現場に提供する仕事なのか」「自社サービスを改善する仕事なのか」を見てください。
この3つが分かれるだけで、面接で聞く質問も変わります。SESなら配属先、受託開発なら担当工程、自社開発ならサービスの開発体制を確認する、という具合です。

・初心者が混乱しやすいポイント｜「自社内開発」と「自社サービス開発」は同じとは限らない

未経験者が特に混乱しやすいのが、「自社内開発」と「自社サービス開発」の違いです。
求人票に「自社内開発」と書かれていると、「自社のサービスを作る会社なんだ」と思いがちですが、実際には自社オフィスの中で受託案件を開発しているケースもあります。

たとえば、顧客から依頼された予約管理システムを、自社オフィスでチーム開発している会社があったとします。
働く場所は自社内でも、作っているものは顧客向けの成果物です。この場合、求人票では「自社内開発」「受託開発」と書かれることがあります。
一方で、自社で運営している学習サービス、ECサイト、業務アプリなどを継続的に改善しているなら、自社サービス開発に近いです。

見分けるときは、次の4点を確認してみてください。

• 開発しているサービス名やプロダクト名が求人票に出ているか
• 売上の中心が自社サービスなのか、顧客からの開発依頼なのか
• 入社後の配属先が自社サービス部門なのか、受託案件チームなのか
• 「自社開発あり」が全員対象なのか、一部部署だけなのか

「自社開発あり」という言葉も、だいぶ幅があります。
会社として自社サービスを持っているだけで、未経験者の初配属はSES案件や受託案件ということもあります。逆に、受託開発中心でも、設計、実装、テスト、レビューをチームで経験できるなら、若手にとって学びやすいこともあるんです。

なので、「自社」と付いているかどうかだけで安心しないでください。
求人票を見るときは、「自社の何を作るのか」「顧客は誰なのか」「未経験者はどの部署に入るのか」まで分けると、言葉の雰囲気に流されにくくなります。

・働く場所・関わる相手・評価される成果はどう変わる？

SES・受託開発・自社開発では、働く場所だけでなく、日々関わる相手と評価される成果も変わります。
ここを見落とすと、「リモート可だから働きやすそう」「自社勤務だから安心そう」といった表面だけで判断しやすくなります。

SESでは、顧客先のチームに入って作業することがあります。
自社の社員でありながら、日々の作業指示や相談相手は顧客側のリーダーや現場メンバーになることもあります。評価も、自社の上司だけでなく、現場での勤怠、報告、コミュニケーション、作業の安定感が見られやすいです。

受託開発では、社内チームで開発しながら、顧客との打合せやレビューを重ねることが多いです。
評価されるのは、ただコードを書いた量ではなく、納期に間に合うか、仕様どおりに動くか、不具合を減らせたか、顧客の要望を整理できたかといった点です。未経験者なら、最初はテスト、画面修正、設計書の読み込み、レビュー指摘の修正などから関わることがあります。

自社開発では、自社サービスを運営するチームの中で働きます。
新機能だけでなく、既存機能の改善、問い合わせ調査、障害対応、管理画面の修正、データ確認なども仕事に入ります。評価されるのは、「納品したか」だけではなく、ユーザーが使いやすくなったか、障害が減ったか、運用しやすくなったかという視点です。

たとえば、同じログイン画面の修正でも、見え方は変わります。
SESなら顧客先の開発チームの一員として修正する。受託開発なら納品対象の機能として仕様書と照らし合わせる。自社開発なら問い合わせや利用データを見ながら改善する。作業名は「ログイン修正」でも、見ているゴールが違うんですよね。

未経験者は、「どこで働くか」だけでなく、「誰から作業を受けるか」「成果を誰が判断するか」まで確認してみてください。
この2つが見えると、入社後のギャップを相当減らしやすくなります。

・最初に押さえる比較軸｜契約形態、責任範囲、常駐有無、スキルアップ、入社難易度

最初に押さえる比較軸は、契約形態、責任範囲、常駐有無、スキルアップ、入社難易度の5つです。
私は、未経験者が最初に比較するなら、会社タイプより先にこの5項目を求人票ごとにメモしたほうが現実的だと考えています。

契約形態は、働き方の前提を知るために見ます。
SESなら準委任に近い案件が多いのか、受託開発なら請負として成果物責任を持つのか、自社開発なら自社サービスの運営が中心なのか。ここを聞くと、会社がどこで売上を作っているかも見えてきます。

責任範囲は、未経験者がどこまで任されるかを見る軸です。
要件定義、設計、実装、テスト、運用、問い合わせ対応のうち、最初に担当するのはどこなのか。求人票に「上流から下流まで」と書かれていても、未経験者が初月から全部やるわけではありません。入社後3ヵ月で触る作業を聞くほうが現実的です。

常駐有無は、働く場所だけでなく相談のしやすさにも関わります。
客先常駐でも、自社の先輩と同じチームで入れるなら安心材料になります。一方で、自社勤務でも、教育担当が忙しすぎて質問しづらい環境なら、ちょっと大変です。場所よりも、近くにレビューしてくれる人がいるかを見たいところです。

スキルアップは、「何を経験として話せるようになるか」で見ます。
JavaやPHPなどの言語名だけでなく、Gitを使うか、コードレビューがあるか、設計書を読むか、テストケースを作るか、障害調査に関わるか。1年後の職務経歴書に書ける作業名を想像すると、求人票の見え方が変わります。

入社難易度は、未経験者にとって現実的な応募戦略に関わります。
一般的には、自社開発は人気が集まりやすく、受託開発は開発経験や基礎力を見られやすく、SESは入口が広い求人もあります。ただし、これは会社ごとの差が大きいです。未経験歓迎でも、ポートフォリオ、資格、学習記録、コミュニケーション力のどれを重視するかは企業によって変わります。

この章では、3つの会社タイプの全体像を比較しました。
次章では、その中でも誤解されやすいSESについて、客先常駐、準委任、待機期間まで働く側の視点で整理していきます。

◆2. SESとは？客先常駐・準委任・待機期間まで働く側の視点で理解する

この章では、SESを「なんとなく客先で働く仕事」とだけ見ず、働く側から何を確認すべきかに分解します。
SESは悪い、客先常駐は危ない、と一言で切ると、見えるはずの比較軸まで見えなくなります。

・SESの基本｜企業に所属しながら顧客先のプロジェクトを支援する働き方

SESは、所属会社の社員として雇用されながら、顧客企業のプロジェクトに技術支援として参加する働き方です。
求人票では「システムエンジニアリングサービス」「常駐開発」「プロジェクト支援」「案件参画」などの言葉で説明されることがあります。

未経験者がまず押さえたいのは、「所属する会社」と「日々作業する現場」が分かれることがある、という点です。
給与や評価制度、面談、研修は所属会社が担当しつつ、日々の作業は顧客先のプロジェクトで進む場合があります。ここが分かりにくいので、はじめて見ると少しややこしいんですよね。

ただし、SESと客先常駐は完全に同じ意味ではありません。
SESでもリモート中心の案件、自社チームでまとまって入る案件、自社内で研修してから配属される会社があります。逆に、受託開発でも顧客との打合せが多く、外部の人と頻繁に関わることはあります。

見るべきなのは、名前よりも「どの案件に入り、誰と働き、誰に相談できるか」です。
たとえば、同じ未経験歓迎のSESでも、最初の担当がテストなのか、運用監視なのか、開発補助なのかで、身につく経験は変わります。さらに、自社の先輩が同じ現場にいるか、営業や上司との定期面談があるかでも、安心感はかなり違います。

私の経験でも、客先常駐から始まるかどうかは、会社の事業内容によって変わると感じています。
自社製品を持っている会社なら社内開発が多いこともありますし、顧客支援を中心にしている会社なら客先プロジェクトが多くなることもあります。求人票の「SES」という文字だけで判断するより、初配属の流れまで聞いたほうが現実に近いです。

・準委任契約をかみ砕く｜成果物ではなく作業・技術支援が中心になりやすい

SESを理解するときに出てくるのが、準委任契約という言葉です。
ざっくり言うと、成果物そのものを完成させて納品するというより、一定期間、技術者として作業や支援を行うイメージに近いです。

受託開発の請負では、「このシステムを作って納品する」「この機能を完成させる」といった成果物が強く意識されます。
一方でSESでは、「この期間、開発チームを支援する」「この運用チームに参画する」「テストや改修を担当する」といった、作業や技術支援が中心になりやすいです。

ここで大事なのは、法律用語を丸暗記することではありません。
未経験者が見るべきなのは、入社後に自分が何を成果として求められるかです。完成したシステムを納品する責任なのか、顧客先チームの中で安定して作業することなのか。そこを分けるだけでも、働き方のイメージは具体的になります。

また、派遣とSESを混同しないことも大切です。
労働者派遣法では、派遣先の指揮命令を受けて働く労働者派遣の定義が定められています。SESという呼び方だけで実態が分かるわけではないため、指揮命令系統や契約の説明は、面接で確認したほうが安全です。
※参考: e-Gov法令検索（労働者派遣法）

面接では、難しい法律論をぶつける必要はありません。
「日々の作業指示はどなたから受けますか」「自社の上司とはどの頻度で面談しますか」「案件内で困ったときは誰に相談できますか」と聞くだけで、働く実態はけっこう見えます。

・客先常駐は必ず悪い？現場・商流・自社フォローで働きやすさは変わる

客先常駐と聞くと、不安になる人は多いと思います。
自社の人が近くにいない、質問しづらい、現場が変わる、評価されにくい。こうした不安は自然と湧いてくるものです。

ただし、客先常駐そのものが必ず悪いわけではありません。
同じ現場に自社の先輩がいる、チームで参画している、営業や上司が定期的に面談してくれる、案件変更の相談ができる。こういう条件がそろっていると、未経験者でも働きやすい可能性はあります。

一方で、単独で現場に入り、自社の支援が薄い状態だと、しんどくなることがあります。
私自身、客先常駐で自社メンバーがほぼいない状態から働いた経験があります。私の場合は、一人のほうが気楽だと感じる面もありましたが、これは全員に当てはまる話ではありません。新人のうちは、質問先やレビューしてくれる人が近いほうが安心できる人も多いはずです。

確認したいのは、少なくとも次の4点です。

• 自社の先輩や同僚と同じ案件に入れる可能性があるか
• 営業や上司との面談頻度はどれくらいか
• 案件が合わないときに相談や変更の仕組みがあるか
• 商流が深すぎず、現場情報がきちんと共有されるか

商流とは、顧客と自分の所属会社の間に何社入っているかという話です。
商流が深いほど、現場の情報が伝わりにくかったり、自分の評価が所属会社に届きにくかったりすることがあります。もちろん一概には言えませんが、未経験者ほど「現場で誰に見てもらえるか」は大事です。

客先常駐を見るときは、「常駐あり」だけで怖がるより、「一人で放り込まれないか」「困ったときに戻れる相談先があるか」を見てください。
ここを確認できると、SESの不安はかなり具体的になります。

・待機期間で確認すべきこと｜給与、研修、評価、次案件の決まり方

SESでは、案件と案件の間に待機期間が発生することがあります。
これは、前の案件が終わってから次の案件が決まるまでの期間です。未経験者の場合、入社後すぐに案件が決まらず、研修や面談をしながら待機するケースもあります。

待機期間そのものがすぐ悪いわけではありません。
むしろ、研修、資格学習、ポートフォリオ改善、面談練習、次案件の準備に使えるなら、キャリアの助走期間になることもあります。

問題は、待機中に何が起きるかが不透明な会社です。
給与は満額出るのか。研修はあるのか。評価はどうなるのか。次の案件は誰がどう探すのか。面談に落ちたとき、何を改善すればよいのか。ここが曖昧なままだと、不安だけが大きくなります。

面接で確認するなら、次のように聞くと自然です。

• 案件が決まるまでの期間は、どのように過ごしますか
• 待機中の給与や評価はどう扱われますか
• 研修や学習課題はありますか
• 次案件は本人の希望も聞いてもらえますか
• 面談で通らなかった場合、どのようなフォローがありますか

特に未経験者は、「入社できるか」だけに意識が向きがちです。
でも、本当に大事なのは入社後にどの案件へ進み、どんな準備とフォローを受けられるかです。待機期間の扱いを聞くのは、失礼な質問ではありません。むしろ、自分のキャリアを雑にしないための確認です。

・SESでスキルアップできる人と停滞しやすい人の違い

SESでスキルアップできるかどうかは、案件と本人の動き方の両方で変わります。
良い案件に入れれば自動的に伸びる、悪い案件に入ったら終わり、というほど単純ではありません。

伸びやすい人は、目の前の作業を「経験として説明できる形」に変えていきます。
テストを担当するなら、仕様書の読み方、不具合報告の書き方、再現手順の整理、開発者とのやり取りまで学ぶ。運用監視なら、アラートの意味、一次切り分け、ログ確認、障害報告の流れまでメモする。小さな改修なら、Git、レビュー、既存コードの読み方まで吸収する。こういう積み上げが、次の案件や転職時の説明材料になります。

停滞しやすいのは、案件名や会社タイプだけで安心してしまうケースです。
「開発案件」と書かれていても、実際にコードを書く時間が少ないことはあります。「大手案件」と聞いても、任される作業が限定的なこともあります。逆に、地味なテストや運用でも、仕様理解や障害調査まで関われるなら、良い経験になることがあります。

SESで成長したいなら、入社前と配属後で確認することを分けてください。
入社前は、案件例、研修、フォロー体制、初期配属の傾向を聞く。配属後は、自分が触った作業、学んだ技術、読んだ設計書、出した不具合、受けたレビューを記録する。これだけでも、ただ案件に入っているだけの状態から抜けやすくなります。

私は、SESを選ぶかどうかより、「その会社が新人の経験をどう設計しているか」のほうが大事だと考えています。
最初はテストや運用からでも構いません。ただ、そこから開発補助、設計書の理解、コードレビュー、障害調査へ広がる道があるかは確認したいところです。

この章では、SESを働く側の視点で整理しました。
次章では、受託開発について、請負、納期、顧客折衝、チーム開発のメリットときつさを見ていきます。

◆3. 受託開発とは？請負・納期・顧客折衝から見るメリットときつさ

この章では、受託開発を「顧客から依頼されたものを作る働き方」として整理します。
SESより開発工程に入りやすそう、自社開発より幅広く経験できそう、と見える一方で、納期や仕様変更の負荷も出やすい働き方です。

・受託開発の基本｜顧客から依頼を受けてシステムやサービスを開発する働き方

受託開発は、顧客から依頼を受けて、業務システム、Webサービス、アプリ、管理画面などを開発する働き方です。
作る対象は顧客のものなので、「自社サービスを育てる」というより、「顧客が必要としている仕組みを、決められた条件の中で形にする」仕事に近いです。

未経験者がイメージしやすい例で言うと、予約管理システム、社内申請システム、ECサイトの改修、在庫管理画面などです。
顧客が「こういう業務を楽にしたい」「今のシステムを直したい」「新しい機能を追加したい」と依頼し、開発会社が要件を整理して作っていきます。

受託開発では、社内チームで働けることもあります。
同じ会社の先輩、プロジェクトマネージャー、設計担当、開発担当、テスト担当と一緒に動けるなら、未経験者にとっては質問しやすい環境になりやすいです。

一方で、顧客の要望に合わせる仕事なので、自由に好きな技術を選べるとは限りません。
既存システムの改修なら、古いフレームワークや決まった開発ルールに合わせることもあります。華やかな新規開発だけを想像していると、少しギャップが出るかもしれません。

見るポイントは、「受託開発かどうか」よりも、どの工程に入れるかです。
要件定義、設計、実装、テスト、保守のうち、未経験者が最初に担当するのはどこなのか。ここを聞くと、入社後の仕事が具体的になります。

・請負契約をかみ砕く｜成果物・納期・品質への責任が重くなりやすい

受託開発でよく出てくるのが、請負契約という言葉です。
ざっくり言うと、依頼された仕事を完成させ、その成果物に対して報酬を受ける考え方に近いです。

民法でも、請負は仕事の完成と報酬の支払いという関係で定められています。
未経験者が法律を細かく覚える必要はありませんが、「成果物を完成させる責任が強く意識される働き方なんだな」と理解しておくと十分です。
※参考: e-Gov法令検索（民法）

SESが「一定期間、技術支援として現場に入る」イメージになりやすいのに対して、受託開発は「決められたものを作って納める」イメージになりやすいです。
もちろん実際の契約や進め方は会社や案件で違いますが、納期、品質、仕様の合意が重く見られやすい点は押さえておきたいところです。

この違いは、日々の働き方にも出ます。
受託開発では、開発中に「この仕様で本当に合っているか」「納期に間に合うか」「テストで不具合が出ていないか」を何度も確認します。
コードを書くだけでなく、設計書を直す、レビュー指摘を反映する、顧客からの質問に回答する、といった作業も増えやすいです。

私自身も、初めて設計を任されたときはかなり迷いました。
そのときに意識したのは、読み手に伝わることと、決められたフォーマットに沿うことです。設計書は自分のメモではなく、開発者、レビュアー、テスト担当、場合によっては顧客も見る資料だからです。

受託開発では、この「自分以外の人が読んで動ける状態にする」力が大事になります。
未経験者の最初の仕事が小さな画面修正やテストだったとしても、設計書、仕様書、レビューコメントを読む機会があるなら、相当学べる現場だと思います。

・受託開発がきついと言われる理由｜納期、仕様変更、顧客調整の負荷

受託開発がきついと言われやすい理由は、納期、仕様変更、顧客調整が重なりやすいからです。
決められた期限までに成果物を出す必要があるため、予定どおりに進まないと、チーム全体の負荷が上がります。

たとえば、開発途中で「やっぱりこの項目も追加したい」「画面の流れを変えたい」「既存システムとの連携が必要だった」と分かることがあります。
このとき、単にコードを足せば終わりではありません。見積り、設計、実装、テスト、リリース手順まで影響を確認する必要があります。

私の経験でも、工数見積りは長くSEを続けても難しいです。
作業内容を分解しないまま「たぶんこれくらい」と考えると、あとから漏れが出ます。画面を1つ直すだけに見えても、入力チェック、権限、エラー処理、テストデータ、既存機能への影響まで見ると、思ったより作業が広がることがあります。

顧客折衝も負荷になりやすい部分です。
顧客は業務のプロですが、システム開発の細かい前提まで知っているとは限りません。逆に開発側は技術の説明に寄りすぎて、顧客が本当に困っている業務を見落とすことがあります。

このズレを埋めるには、相手の意図を推測で決めつけず、質問して、記録して、合意を残す必要があります。
「多分こういう意味だろう」で進めると、あとで「そういうつもりではなかった」と戻ってくることがあります。これは本当にしんどいです。エスパー能力が欲しくなる場面ですね。

ただし、きつい部分があるから避けるべき、という話ではありません。
納期や顧客調整があるからこそ、要件の聞き方、優先順位の決め方、影響範囲の見方、チームで進める力が鍛えられる面もあります。

・一方で成長しやすい点｜設計、開発、テスト、顧客折衝を経験しやすい

受託開発の良いところは、開発の流れを一通り見やすいことです。
会社や案件によりますが、要件定義、設計、実装、テスト、納品、保守まで、システム開発の工程が比較的はっきり分かれています。

未経験者が最初から全部を担当することは少ないです。
ただ、同じチームの中で先輩が設計している様子、レビューしている様子、顧客と仕様を詰めている様子を見られるなら、それだけでも学びは大きいです。

最初はテスト担当でも、仕様書を読みながら動作確認するなら、業務の流れを覚えられます。
小さな改修でも、既存コードを読み、設計書と照らし合わせ、レビューを受けて直すなら、開発の基本が身につきます。

私自身、プログラマーから始まり、気づけば上流寄りの作業も任されるようになりました。
もちろん全員が同じ順番で進むわけではありません。ただ、受託開発の現場では、案件の中で少しずつ担当範囲が広がることがあります。

チーム開発を学びやすいのもポイントです。
受託開発では、別チームとの打合せ、設計レビュー、テスト担当とのやり取り、リリース前の確認など、他の人と連携する場面が増えます。
一人で黙々とコードを書くより、周囲と認識を合わせながら進める力が求められます。

この経験は、次のキャリアでも使いやすいです。
職務経歴書に書くときも、「Javaで開発しました」だけでなく、「設計書をもとに実装し、レビュー指摘を反映し、テストまで対応しました」と言えると、経験の見え方が変わります。

・チーム開発や上流工程を経験したい人が見るべきポイント

受託開発を選ぶときは、チーム開発や上流工程に関われるかを確認してください。
ただし、求人票に「上流工程あり」と書かれているだけで安心しないほうがいいです。

見たいのは、未経験者がどの段階から、どの深さで関われるかです。
要件定義に同席できるのか、設計書の作成補助ができるのか、レビューを受けながら実装できるのか、テスト仕様書を作れるのか。ここを分けて聞くと、かなり現実的になります。

面接では、次のように確認すると聞きやすいです。

• 未経験者は最初にどの工程を担当することが多いですか
• 設計書や仕様書を読む機会はありますか
• コードレビューはどのように行われますか
• 顧客との打合せに若手が同席することはありますか
• テストだけでなく、改修や実装へ進む流れはありますか
• チーム体制は何名くらいで、質問先は誰になりますか

特に見たいのは、レビュー文化です。
レビューがある会社は、最初は指摘されてつらく感じることもあります。でも、指摘の理由を学べる環境なら、独学だけでは気づきにくい書き方、設計の考え方、テスト観点を吸収できます。

逆に、いきなり一人で任されるだけの環境は注意が必要です。
「若手にも裁量があります」という言葉が、成長機会なのか、放置なのかは見極めたいところです。裁量と放置は、見た目が少し似ているのでややこしいんですよね。

受託開発が向いているのは、顧客の要望を整理しながら、チームでシステムを作る流れを学びたい人です。
納期や調整の大変さはありますが、設計、実装、テスト、レビュー、顧客対応をつなげて経験できるなら、未経験者にとって濃い入口になります。

この章では、受託開発の基本、請負、きつさ、成長しやすい点を整理しました。
次章では、自社開発について、おすすめされやすい理由と、入社後に感じやすいギャップを見ていきます。

◆4. 自社開発とは？おすすめされやすい理由と入社後に感じやすいギャップ

この章では、自社開発を「自社サービスや自社プロダクトを継続的に育てる働き方」として整理します。
未経験者から見ると魅力的に見えやすい一方で、実際には保守、問い合わせ対応、事業都合、技術選定の制約もあります。

・自社開発の基本｜自社サービスや自社プロダクトを育てる働き方

自社開発は、自社で運営しているサービスやプロダクトを、社内の開発チームで作り、改善し続ける働き方です。
たとえば、学習サービス、予約サービス、ECサイト、業務管理ツール、SaaSなどを自社で持っている会社がイメージしやすいです。

受託開発では、顧客から依頼されたものを作って納品する流れが中心になりやすいです。
一方で自社開発では、作ったあとも自分たちで運用し、問い合わせを受け、利用状況を見ながら改善していきます。
「作って終わり」ではなく、「出してから育てる」仕事に近いんですよね。

たとえば、ログイン画面を改善する場合でも、受託開発なら顧客の要望や仕様書に沿って修正することが多いです。
自社開発なら、ユーザーがどこで離脱しているのか、問い合わせがどこに集中しているのか、運用チームがどこで困っているのかまで見ながら直すことがあります。
同じ画面修正でも、見ている先が少し変わります。

私の経験でも、自社製品を持っている会社かどうかで、日々の会話はだいぶ変わると感じています。
自社サービスがある会社では、技術の話だけでなく、売上、利用者、問い合わせ、改善要望、サポート対応まで開発の文脈に入ってきます。
コードだけを見たい人には面倒に感じるかもしれませんが、サービス全体を見たい人には学びが多い環境です。

・自社開発が人気の理由｜プロダクトへの愛着、改善サイクル、裁量の持ちやすさ

自社開発が人気になりやすい理由は、プロダクトへの愛着を持ちやすいからです。
自分が直した機能が継続的に使われ、ユーザーの反応を見ながら改善できると、仕事の意味を感じやすくなります。

受託開発では、納品後に次の案件へ移ることがあります。
SESでは、参画している案件の範囲内で作業することが多くなります。
自社開発では、同じサービスに長く関わり、過去の判断や設計の良し悪しをあとから振り返る機会があります。

これはけっこう大きな違いです。
自分で書いたコードが半年後、1年後にどう運用されているかを見ると、「その場で動けばよい」だけでは済まないことが分かります。
将来の修正しやすさ、問い合わせの減らし方、データの持ち方、リリース後の監視まで考えるようになります。

改善サイクルを回しやすいのも、自社開発の魅力です。
ユーザーの声、アクセス解析、問い合わせ内容、営業やカスタマーサポートからの要望を受けて、次の改善を決めることがあります。
小さな修正でも、サービスの使いやすさや運用負荷に直接つながることがあります。

経済産業省のデジタルガバナンス・コードでも、企業がデジタル技術を経営ビジョンや企業価値向上と結びつけて考える視点が示されています。
自社開発も同じで、技術だけを見ているというより、事業や利用者にどう価値を返すかまで見える仕事です。
※参考: 経済産業省「デジタルガバナンス・コード」

裁量を持ちやすい会社があるのも、人気の理由です。
自社サービスを小さなチームで運営している場合、若手でも改善案を出したり、管理画面の修正を任されたり、問い合わせの原因調査から改修まで担当したりすることがあります。
ただし、裁量があるかどうかは会社によります。
「自社開発＝自由に技術選定できる」と考えると、少し期待が先走るかもしれません。

・注意したいギャップ｜保守中心、技術の偏り、事業都合に左右される可能性

自社開発で注意したいギャップは、思ったより保守中心になることです。
求人票では「自社サービス開発」と書かれていても、入社後すぐに新機能をどんどん作れるとは限りません。

既存機能の不具合修正、問い合わせ調査、データ確認、管理画面の改修、ログ調査、運用手順の整備など、地味な仕事も多いです。
でも、この地味な仕事がサービスを支えています。
ユーザーが困っている原因を調べ、再発を防ぎ、運用チームが迷わないようにする作業は、実務では相当価値があります。

技術が偏りやすいこともあります。
自社サービスは、すでに使っている言語、フレームワーク、インフラ、データベースに合わせて開発するため、流行の技術を自由に触れるとは限りません。
レガシーなコードを読み、既存仕様を壊さずに直す力が求められることもあります。

事業都合に左右される点も見ておきたいところです。
サービスの売上が伸びていると新機能開発に投資しやすいですが、事業状況によっては保守やコスト削減が優先されることもあります。
競合対応、法改正、料金プラン変更、営業方針の変更などで、開発の優先順位が変わることもあります。

自社開発は、技術だけで完結しません。
プロダクトマネージャー、営業、CS、マーケティング、経営側の判断とつながりながら開発することがあります。
ここを面白いと感じる人もいれば、「もっと純粋にコードを書きたい」と感じる人もいます。

・未経験・若手が自社開発を狙うときに見られやすいポイント

未経験・若手が自社開発を狙うなら、まず開発組織の人数を見てください。
エンジニアが数名しかいない会社と、数十名いる会社では、任され方も教育体制も変わります。

少人数の会社では、早くから幅広い作業に触れられる可能性があります。
ただし、教育担当が固定されていなかったり、質問先が少なかったりすることもあります。
大きめの開発組織では、レビュー体制やオンボーディングが整っている可能性がありますが、最初の担当範囲は細かく分かれるかもしれません。

面接で確認するなら、次のように聞くと自然です。

• 未経験者や若手は、入社後どの作業から担当することが多いですか
• 既存サービスの保守と新機能開発の割合はどれくらいですか
• コードレビューはどのように行われますか
• 問い合わせ調査や障害対応に若手も関わりますか
• プロダクト改善の提案は、若手でも出せますか
• 技術選定は誰がどのように決めていますか

特に見たいのは、レビューと質問の仕組みです。
自社開発は人気がある分、未経験者に求める基礎力が高い会社もあります。
ポートフォリオ、GitHub、学習記録、基本情報技術者などの資格、チーム開発経験を見られることもあります。

ただ、完璧なポートフォリオがないと無理、という話ではありません。
大事なのは、自分で調べて作った経験を、なぜその設計にしたのか、どこで詰まったのか、どう改善したいのかまで説明できることです。
ここが話せると、ただ学習教材をなぞっただけではないことが伝わります。

・「自社開発なら必ず成長できる」と言い切れない理由

自社開発なら必ず成長できる、とは言い切れません。
理由は、成長できるかどうかが、サービスの状態、チーム体制、任される作業、本人の動き方で変わるからです。

自社開発でも、長く同じ保守作業だけを担当することがあります。
問い合わせ対応ばかりで、設計や実装に進む機会が少ないこともあります。
逆に、受託開発やSESでも、レビューを受けながら実装し、設計書を読み、障害調査まで経験できるなら、十分に成長できます。

自社開発の強みは、同じサービスを継続的に見られることです。
でも、それを成長につなげるには、目の前の作業をサービス全体と結びつけて考える必要があります。
「この修正は誰の困りごとを減らすのか」「この不具合はなぜ起きたのか」「次に同じ問題を起こさないにはどうするか」まで見ると、経験の濃さが変わります。

未経験者にとっては、自社開発という名前だけで安心しないことが大事です。
見るべきなのは、サービス名、開発組織、担当工程、レビュー体制、保守と新機能の割合、若手の育成方針です。
このあたりを確認できると、入社後のギャップはかなり減らせます。

自社開発が向いているのは、自分たちのサービスを長く育てながら、ユーザーや事業の反応も見ていきたい人です。
逆に、いろいろな業界や案件を短期間で経験したい人には、受託開発やSESのほうが合う場面もあります。
会社タイプの名前より、積める経験で見てください。

この章では、自社開発の基本、人気の理由、注意したいギャップ、未経験者が見るべきポイントを整理しました。
次章では、SES・受託開発・自社開発をメリット・デメリットで比較し、何が得られて何に注意すべきかを並べて見ていきます。

◆5. メリット・デメリットで比較｜SES・受託開発・自社開発は何が得られて何に注意すべきか

この章では、SES・受託開発・自社開発を、メリットとデメリットで横並びにして見ていきます。
ここまで個別に整理してきましたが、実際の応募先選びでは「どれが良いか」より、「自分が何を得たいか」「何を避けたいか」で比べるほうが現実的です。

・SESのメリット・デメリット｜経験の幅は広がるが案件差が大きい

SESのメリットは、入れる案件の幅が広いことです。
開発、テスト、運用、保守、ヘルプデスク寄りの業務、インフラ寄りの業務など、会社や案件によって入り口が変わります。

未経験者にとっては、IT業界に入る間口が比較的広いこともあります。
最初から理想の開発案件に入れなかったとしても、現場での報告、仕様書の読み方、障害時の一次対応、チーム内のやり取りを覚えられるなら、次につながる経験になります。

一方で、デメリットは案件差が大きいことです。
同じSESでも、自社の先輩と一緒に入れる現場もあれば、一人で客先に入る現場もあります。
開発補助から始められる場合もあれば、最初は監視やテストが中心になる場合もあります。

ここは、求人票だけでは見えにくいです。
それだけに、面接では次のように聞くと判断しやすくなります。

• 未経験者の初配属で多い案件は何ですか
• 開発、テスト、運用の割合はどれくらいですか
• 自社の先輩と同じ現場に入れる可能性はありますか
• 案件が合わないときの相談先は誰ですか

SESは、会社タイプだけで良し悪しを決めるより、案件の質とフォロー体制を見る働き方です。
ここを確認できれば、入社後のギャップはかなり抑えやすくなります。

・受託開発のメリット・デメリット｜開発経験は積みやすいが納期負荷に注意

受託開発のメリットは、システム開発の流れを経験しやすいことです。
顧客から依頼を受け、要件を整理し、設計し、実装し、テストし、納品する。
案件によって範囲は違いますが、開発工程のつながりを見やすいのが特徴です。

未経験者が最初から要件定義や顧客折衝を担当することは少ないです。
ただ、同じチームの中で先輩が顧客と話している様子、設計書を作っている様子、レビューで指摘している様子を見られるなら、学びはけっこう大きいです。

デメリットは、納期負荷が出やすいことです。
顧客との約束があるため、仕様変更、不具合、見積り漏れが重なると、チーム全体が忙しくなります。
「この日までに出す」「この品質で出す」というプレッシャーは、受託開発ならではの相当な重さです。

私自身、工数見積りは長くSEを続けても難しいと感じています。
画面を1つ直すだけに見えても、入力チェック、権限、テストデータ、既存機能への影響を見ていくと、思ったより作業が広がることがあります。

受託開発を選ぶなら、開発経験を積めるかだけでなく、チーム体制とレビュー体制を見てください。
納期のある現場でも、質問できる先輩、設計書の読み方を教えてくれる人、レビューで理由まで説明してくれる人がいるなら、経験の質は変わります。

・自社開発のメリット・デメリット｜事業に深く関われるが経験範囲が偏ることもある

自社開発のメリットは、同じサービスを長く育てられることです。
自分が直した機能がその後どう使われたのか、問い合わせが減ったのか、ユーザーの反応がどう変わったのかを追いやすいです。

受託開発やSESでは、案件が終わったり現場が変わったりすると、その後の運用まで深く見られないことがあります。
自社開発では、リリース後の不具合、改善要望、売上や利用状況、サポート部門からの声まで開発に返ってくることがあります。

これは、サービス全体を見たい人には魅力です。
一方で、デメリットは経験範囲が偏る可能性があることです。

自社サービスで使っている技術が固定されていると、触れる言語やフレームワークが限られます。
担当が保守や問い合わせ調査に寄ると、新規開発をどんどん経験できるとは限りません。
サービスの事業状況によって、攻めの開発よりもコスト削減や安定運用が優先されることもあります。

自社開発を狙うなら、次の点を確認したいところです。

• 既存機能の保守と新機能開発の割合
• 若手が任される最初の作業
• コードレビューや設計レビューの有無
• 問い合わせ調査や障害対応への関わり方
• プロダクト改善の提案ができるか

自社開発は人気がありますが、名前だけで選ぶと危険です。
サービスに深く関われる一方で、経験の幅は会社の事業とチーム体制に左右されます。

・年収だけで比べると危険｜初年度より「評価される経験」が増えるかを見る

年収だけでSES・受託開発・自社開発を比べるのは危険です。
もちろん収入は大事です。
ただ、未経験転職では初年度の年収だけでなく、次の評価につながる経験が増えるかを見たほうがいいです。

たとえば、初年度の年収が少し高くても、担当作業がずっと限定的で、職務経歴書に書ける内容が増えにくいなら、次の転職や昇給で説明に困ることがあります。
逆に、最初の年収が高くなくても、設計書を読み、実装し、レビューを受け、テストや障害調査まで経験できるなら、その後の選択肢は広がります。

評価される経験とは、面接や職務経歴書で具体的に説明できる経験です。

• どんなシステムに関わったか
• どの工程を担当したか
• どんな技術を使ったか
• どんな課題を解決したか
• 誰と連携して進めたか
• レビューや改善をどう受け止めたか

このあたりを話せるようになると、会社タイプの名前よりも説得力が出ます。
「自社開発にいました」だけでは弱いですし、「SESでした」だけで不利になるわけでもありません。

大事なのは、どの環境で、何を担当し、何を学び、次に何ができるようになったかです。
年収は結果として上げていくものなので、最初の選択では、評価される経験が増える環境かどうかを見てください。

・働き方の違い｜リモート、残業、裁量は会社タイプだけでは決まらない

働き方も、会社タイプだけでは決まりません。
SESだから必ず客先常駐、受託開発だから必ず残業が多い、自社開発だから必ずリモートで自由、とは言えません。

SESでもリモート案件はあります。
受託開発でも、工程管理がうまい会社なら無理な残業を避けられることがあります。
自社開発でも、障害対応やリリース前には忙しくなることがあります。

残業については、労働基準法でも時間外労働や労働時間に関するルールが定められています。
求人票で「残業少なめ」と書かれていても、平均時間、繁忙期、障害対応、リリース前の働き方まで確認したほうが安全です。

※参考: e-Gov法令検索（労働基準法）

確認するなら、次の質問が使いやすいです。

• 平均残業時間はどれくらいですか
• 繁忙期はいつですか
• リモート勤務は制度としてあるだけか、実際に使われていますか
• リリース前や障害時の対応は誰が担当しますか
• 若手のうちは、どの程度の裁量がありますか

働き方は、会社タイプよりも、案件、チーム、顧客、サービス状況、マネジメントで変わります。
リモートや残業だけで決めると、見誤りやすいです。

この章では、SES・受託開発・自社開発のメリットとデメリットを並べて整理しました。
次章では、目的別にどの会社タイプが向いているかを診断しながら、未経験者が応募先を絞るための見方を整理していきます。

◆6. どれがいい？目的別に向いている会社タイプを診断

この章では、目的別にSES・受託開発・自社開発の向き不向きを整理します。

結論から言うと、会社タイプだけで「これが正解」と決める必要はありません。
未経験の段階では、自分が何を優先したいかを先に置いたほうが、応募先を絞りやすくなります。

・未経験からIT業界に入りたい人｜入口の広さだけでなく配属後の経験を見る

未経験からIT業界に入りたい人は、入口の広さだけで判断しないほうがいいです。

SESは未経験歓迎の求人が見つかりやすいことがあります。
ただし、入社しやすさだけで選ぶと、配属後に「思っていた開発ではなかった」と感じることがあります。

見るべきなのは、入社後にどんな経験を積めるかです。

たとえば、最初がテストでも、仕様書を読み、不具合を報告し、開発者とやり取りできるなら次につながります。
運用監視でも、ログ確認、障害の一次切り分け、報告書作成まで関われるなら、システムの動きを理解する経験になります。
逆に「未経験歓迎」と書かれていても、研修後の配属先や担当作業が曖昧なままだと、判断しにくいです。

受託開発は、チームで開発工程を見やすい可能性があります。
ただし、未経験者に求める基礎力が高い会社もあります。
ポートフォリオ、学習記録、Gitの利用経験、基本的なプログラミング理解を見られることもあります。

自社開発は人気が集まりやすく、未経験から狙うには準備が必要なことが多いです。
でも、最初から諦める必要はありません。
サービスへの関心、自分で作ったものの説明、改善したい点を話せるなら、評価につながることもあります。

入口を見るなら、次の順番で確認してください。

• 未経験者の初配属で多い作業は何か
• 研修後にどの部署や案件へ進むのか
• レビューや質問の仕組みはあるか
• 半年後にどんな作業を担当している人が多いか
• 職務経歴書に書ける経験が増えそうか

未経験者にとって大事なのは、「入れる会社」ではなく「入ったあとに経験が増える会社」です。

・早く開発経験を積みたい人｜SES・受託・自社開発で確認すべき担当工程

早く開発経験を積みたい人は、会社タイプより担当工程を確認してください。

求人票に「開発」と書かれていても、実際の最初の仕事がテスト中心、運用中心、問い合わせ対応中心ということはあります。
それ自体が悪いわけではありません。
ただ、早くコードを書く経験を増やしたいなら、どのタイミングで実装に進めるのかを聞く必要があります。

SESの場合は、案件によって差が出ます。
開発補助から入れる案件もあれば、テストや運用から始まる案件もあります。
確認したいのは、案件例とキャリアの広がり方です。

「最初はテストが多いです」と言われた場合でも、その後に小さな改修、設計書の読み込み、コードレビューへ進む流れがあるなら、開発経験につながります。
一方で、担当範囲が固定されやすいなら、自分で学習や異動相談を進める必要が出ます。

受託開発は、開発工程に入りやすい可能性があります。
設計、実装、テスト、納品の流れが見えやすいからです。
ただし、納期があるため、未経験者がゆっくり学べる環境とは限りません。
教育体制が薄いまま忙しい案件に入ると、質問しづらくなることもあります。

自社開発は、既存サービスの保守や改善から入ることがあります。
新機能開発だけを想像しているとギャップが出ますが、既存コードを読み、不具合を直し、リリース後の反応を見る経験はけっこう実務的です。

早く開発経験を積みたいなら、面接では次のように聞いてください。

• 未経験者が最初にコードを書くのはどのような作業ですか
• テストから実装へ進む流れはありますか
• コードレビューはありますか
• 既存コードを読む機会はありますか
• 小さな改修を任されるまでの目安はありますか
• 設計書や仕様書を読む機会はありますか

「開発経験を積める」と言われたときは、実装だけでなく、設計書、レビュー、テスト、リリースまで見えるかを確認しましょう。

・上流工程や顧客折衝を経験したい人｜受託開発で得られる経験と注意点

上流工程や顧客折衝を経験したい人は、受託開発が候補に入りやすいです。

受託開発では、顧客の要望を聞き、要件を整理し、仕様に落とし込み、チームで開発していく流れがあります。
未経験者がいきなり顧客の前に立つことは少ないですが、打合せへの同席、議事録作成、設計書の修正補助、レビュー対応などから学べることがあります。

上流工程と聞くと、かっこよく見えます。
でも実際は、顧客の言葉をそのまま受け取るだけでは足りません。
何に困っているのか、どの業務を変えたいのか、どこまでが今回の範囲なのかを整理する必要があります。

この仕事は相当泥くさいです。
「こういう意味だと思います」で進めると、あとから認識違いが出ることがあります。
だから、質問して、記録して、合意を残す力が求められます。

SESでも、参画先によっては上流工程に近い作業を経験できることがあります。
ただし、契約や立場によって関われる範囲が限られる場合があります。
上流に関わりたいなら、「案件によって可能です」だけでなく、過去の未経験者や若手がどこまで担当したかを聞くとよいです。

自社開発でも、事業部やCS、営業と話しながら要望を整理する場面があります。
ただし、顧客折衝というより、自社サービスの改善要望を社内で整理する形になりやすいです。

上流工程を経験したい人は、次を確認してください。

• 若手が要件定義や設計に同席する機会はあるか
• 議事録や仕様整理を任されることはあるか
• 顧客との打合せに参加できるか
• 設計書の作成補助やレビュー対応はあるか
• 顧客要望と開発範囲を整理する場面があるか

上流工程を目指すなら、最初から全部を任されるかではなく、横で見て学べる環境があるかを見てください。

・自社サービスを育てたい人｜自社開発で求められる事業理解と改善視点

自社サービスを育てたい人は、自社開発が向いている可能性があります。

自社開発では、同じサービスに継続的に関わりやすいです。
自分が直した機能がどう使われたのか、問い合わせが減ったのか、ユーザーの反応がどう変わったのかを追いやすいからです。

これは、受託開発やSESとは違う面です。
受託開発では納品後に別案件へ移ることがあります。
SESでは参画先が変わることがあります。
自社開発では、同じプロダクトを長く見ながら、改善を積み上げることがあります。

ただし、自社サービスを育てる仕事は、コードだけでは完結しません。
売上、利用者数、問い合わせ内容、営業からの要望、サポート部門の声、運用負荷なども開発判断に入ってきます。

技術だけに集中したい人にとっては、少し面倒に感じる場面もあると思います。
でも、サービス全体を見たい人には学びがあります。

たとえば、ボタンの位置を変えるだけでも、ユーザーの操作、問い合わせ数、管理画面の運用、データ集計に影響することがあります。
「動けば終わり」ではなく、「使われ続けて問題が減るか」まで見るのが、自社開発らしいところです。

自社開発を選ぶなら、次を確認してください。

• 自社サービスの内容を自分の言葉で説明できるか
• 開発チームは何名くらいか
• 若手は保守と新機能のどちらを担当しやすいか
• ユーザーの声や問い合わせ内容を開発者も見るか
• 改善提案はどのように採用されるか
• 事業側との打合せに開発者も参加するか

厚生労働省の職業情報提供サイト（job tag）では、職業について、仕事内容、就労する方法、求められる知識・スキル、向いている人などを調べられます。
自社開発を狙う場合も、サービスへの関心だけでなく、職業として求められる作業やスキルを具体的に調べておくと、応募先選びの軸が作りやすくなります。
※参考: 厚生労働省「職業情報提供サイト（job tag）」

・将来転職しやすい経験を積みたい人｜会社名より「語れる実績」で判断する

将来転職しやすい経験を積みたい人は、会社タイプより「語れる実績」で判断してください。

転職で見られるのは、「SESだったか」「受託開発だったか」「自社開発だったか」だけではありません。
むしろ、どの環境で、何を担当し、どんな成果や学びを説明できるかが見られます。

語れる実績とは、派手な成果だけではありません。

• 既存機能の不具合を調査して修正した
• テストで不具合を見つけ、再現手順を整理した
• 設計書を読んで小さな改修を担当した
• レビュー指摘を受けてコードを改善した
• 障害時にログを確認し、一次切り分けを行った
• 問い合わせ内容から原因を調査した
• ユーザーや顧客の要望を整理してチームに共有した

こうした経験でも、背景、担当範囲、工夫、結果を説明できれば、職務経歴書に書ける材料になります。

SESでも、案件の中で実装、テスト、運用、障害対応を経験できれば、次につながります。
受託開発でも、顧客折衝や設計補助、レビュー対応まで関われれば、経験の見え方は強くなります。
自社開発でも、保守や問い合わせ対応だけで終わらせず、改善提案や再発防止まで考えられれば、かなり良い実績になります。

逆に、会社タイプの名前が良く見えても、自分の担当範囲を説明できないと転職時に困ります。
「何をしていましたか」と聞かれたときに、会社名やサービス名だけでなく、自分の作業を具体的に話せるかが大事です。

将来の転職を考えるなら、入社前から次の視点で求人を見てください。

• 半年後に説明できる作業が増えそうか
• レビューを受けながら改善できそうか
• 設計書や仕様書を読む機会がありそうか
• チームで開発する経験が積めそうか
• 障害対応や問い合わせ調査まで見られそうか
• 自分の担当範囲を職務経歴書に書けそうか

この章では、目的別に向いている会社タイプを整理しました。
次章では、求人票の言葉から実態を見抜くために、「自社開発あり」「案件選択制」「未経験歓迎」「研修あり」などの見方を確認していきます。

◆7. 求人票で見抜く！SES・受託開発・自社開発の実態チェック

この章では、求人票に出てくる言葉から、SES・受託開発・自社開発の実態を見抜くための確認ポイントを整理します。
求人票は入口として大事ですが、書かれている言葉だけで働き方を決めつけると、入社後のギャップがだいぶ大きくなります。

・「自社開発あり」の注意点｜自社サービスなのか、自社内で受託しているのかを確認する

「自社開発あり」と書かれている求人を見ると、未経験者は「自社サービスを作れる会社なんだ」と受け取りやすいです。
でも、ここは必ず分けて確認したほうがいいです。
自社開発あり、という言葉には、少なくとも次のようなパターンがあります。

• 自社サービスや自社プロダクトを開発している
• 自社オフィス内で受託案件を開発している
• 一部部署だけが自社サービスを担当している
• 会社として自社サービスはあるが、未経験者の初配属はSESや受託案件になる
• 将来的に自社開発へ異動できる可能性がある、という意味で書かれている

どれも求人票では似た言葉に見えますが、入社後の経験はけっこう変わります。
自社サービスを開発するなら、ユーザーの反応、問い合わせ、改善要望、事業側との会話が仕事に入ってきます。
自社内で受託開発をするなら、働く場所は自社でも、作っているものは顧客向けの成果物です。
SESから始まるなら、日々の作業場所や相談相手は参画先によって変わります。

確認するなら、「自社開発ありですか」だけでは足りません。
次のように聞くと、実態が見えやすくなります。

• 開発している自社サービス名やプロダクト名は何ですか
• 未経験者の初配属は自社サービス部門ですか
• 自社内開発と自社サービス開発の割合はどれくらいですか
• 受託案件を自社内で開発するケースもありますか
• 自社開発に関われるのは全員ですか、一部部署ですか
• 入社後すぐに関われるのか、経験を積んでから異動する形なのか

「自社」という言葉が入っているだけで安心しないことです。
求人票では魅力的に見えても、自分が最初にどこへ配属され、何を担当するかまで確認してはじめて判断できます。

・「案件選択制」はどこまで本当？選べる範囲・営業担当・商流を確認する

SES系の求人では、「案件選択制」「希望案件に参画可能」「エンジニアの希望を尊重」といった言葉を見ることがあります。
この言葉も、見た瞬間に安心しないほうがいいです。
案件選択制といっても、何をどこまで選べるのかは会社によって違います。

たとえば、次のような違いがあります。

• 複数案件の中から本人が選べる
• 営業担当が候補を出し、本人の希望も聞く
• 勤務地やリモート可否は相談できる
• 技術領域の希望は出せるが、最終判断は会社が行う
• 単価や経験年数の条件で、未経験者が選べる案件は限られる
• 希望は聞くが、実際には参画可能な案件から決まる

未経験者の場合、案件を自由に選べる範囲は相当限られることがあります。
企業側から見ても、現場が求めるスキル、経験年数、面談結果、単価、勤務地、稼働開始日が合わないと参画できません。
だから、「案件選択制」と書かれているかより、選ぶまでの流れを確認するほうが大事です。

確認したいのは、次の4点です。
まず、選べる範囲です。
開発、テスト、運用、インフラ、勤務地、リモート可否、業界、言語のうち、どこまで希望を出せるのかを聞きます。

次に、営業担当の関わり方です。
営業担当が案件の内容をどこまで説明してくれるのか、面談前に現場情報を共有してくれるのか、参画後も定期的に状況を聞いてくれるのかを確認します。

3つ目は、商流です。
商流が深いと、現場情報が伝わりにくかったり、評価が自社に戻りにくかったりすることがあります。
「商流はどのくらいですか」と聞くのが難しければ、「案件情報はどの程度詳しく共有されますか」と聞いても大丈夫です。

4つ目は、案件変更の相談先です。
参画後に合わないと感じたとき、誰に相談し、どのような流れで変更を検討するのかを確認してください。
案件選択制は、選ぶ前だけでなく、入った後のフォローまで見て判断する言葉です。

・「未経験歓迎」「研修あり」で見るべき中身｜研修後の配属先まで聞く

「未経験歓迎」「研修あり」は、未経験者にとって魅力的な言葉です。
ただし、この2つも中身を確認しないと判断できません。
未経験歓迎といっても、完全にゼロから育てる意味なのか、学習済みの人なら応募可能という意味なのかで、求められる準備は変わります。

研修ありも同じです。
研修期間、内容、講師、課題、レビュー、研修後の配属先によって、経験の残り方が変わります。
動画教材を見るだけの研修もあれば、課題を作ってレビューを受ける研修もあります。
現場配属を前提に、テスト観点、Git、SQL、Linux、報告の仕方まで扱う研修もあります。

見るべきなのは、研修の有無ではなく、研修後にどこへ進むかです。
研修でJavaを学んでも、配属先が運用監視中心なら、すぐにJava開発へ進むとは限りません。
Webアプリを作る研修を受けても、現場では既存システムのテストや問い合わせ調査から始まることがあります。
それが悪いわけではありませんが、期待と違うとしんどくなります。

面接では、次のように聞くと自然です。

• 未経験者向け研修は何週間ほどありますか
• 研修では何を作りますか
• コードレビューや質問対応はありますか
• 研修後の配属先で多い業務は何ですか
• 最初の担当は開発、テスト、運用のどれが多いですか
• 配属後もメンターや定期面談はありますか
• 研修で学んだ技術と配属先の技術はつながっていますか

職業安定法でも、求人等に関する情報を的確に表示する考え方や、労働条件等の明示に関する規定が置かれています。
未経験者側も、求人票の言葉をそのまま受け取るだけではなく、仕事内容、就業場所、担当工程、研修後の配属まで確認したほうが安全です。
※参考: e-Gov法令検索（職業安定法）

・開発経験を積める求人か判断するためのチェック項目

開発経験を積める求人かどうかは、「開発」という言葉だけでは判断できません。
大事なのは、実装の前後まで経験できるかです。
コードを書く時間があるかだけでなく、設計書を読むか、レビューを受けるか、テストを書くか、リリース後の不具合を調べるかまで見てください。

開発経験として見えやすいのは、次のような経験です。

• 既存コードを読んで小さな修正をする
• 設計書や仕様書をもとに実装する
• コードレビューを受けて修正する
• 単体テストや結合テストに関わる
• 不具合の原因を調査する
• Gitでブランチを切り、レビュー後に反映する
• 問い合わせ内容から再現手順を整理する
• 障害時にログを確認する
• リリース後の反応を見て改善する

求人票で「開発案件多数」と書かれていても、自分がどの作業を担当するかは別です。
逆に、最初はテストや保守と書かれていても、仕様理解、改修、レビュー、障害調査へ広がるなら、実務経験としてはかなり意味があります。

私なら、求人票を見るときに次のようにメモします。
「最初の作業」「半年後の作業」「レビューの有無」「設計書を見る機会」「チーム体制」「職務経歴書に書けそうな経験」です。
この6つを書き出すだけで、求人の見え方が変わります。

たとえば、A社は自社開発と書いているけれど、最初の1年は問い合わせ調査が中心。
B社は受託開発で納期は厳しそうだけれど、設計書を読みながら改修し、レビューもある。
C社はSESで案件差はあるけれど、自社の先輩と同じ現場に入れて、テストから小さな改修へ進む流れがある。

この場合、会社タイプだけでは優劣を決められません。
自分がどの経験を積みたいかによって、選び方が変わります。
求人票は、社名や待遇だけでなく、半年後に語れる作業が増えるかを見る資料として使ってください。

・口コミを見る前に知っておきたい判断基準｜一人の体験談を全体化しない

求人票を見たあと、口コミサイトやSNSで評判を調べる人も多いと思います。
これは悪いことではありません。
ただし、一人の体験談をその会社全体や会社タイプ全体に広げすぎないように注意してください。

SESでつらかった人の体験談を読むと、SES全部が危険に見えることがあります。
受託開発で納期に追われた話を読むと、受託開発は全部きついと感じることがあります。
自社開発で成長できなかった話を読むと、自社開発も結局だめなのかと思うかもしれません。

でも、口コミは多くの場合、その人がいた部署、その時期、その案件、その上司、その顧客、その事業状況の話です。
もちろん参考になります。
ただ、それをそのまま自分が応募する会社にも当てはめると、判断が荒くなります。

口コミを見るときは、次のように分解してください。

• いつ頃の口コミか
• どの職種や部署の口コミか
• 未経験者の配属に関する話か
• SESならどの案件や商流の話か
• 受託開発ならどの顧客や納期の話か
• 自社開発ならどのサービスや開発組織の話か
• 退職理由が個人事情なのか、構造的な問題なのか
• 同じ内容の口コミが複数あるか

特に未経験者は、強い言葉の口コミに引っ張られやすいです。
「やめとけ」「最高」「地獄」「神企業」みたいな言葉は目立ちますが、そのまま判断材料にすると危険です。
見るべきなのは、感情の強さより、具体性です。

具体的な口コミは、判断に使いやすいです。
たとえば、「未経験者は最初にテスト案件へ入り、半年後に小さな改修へ進む人が多かった」「自社の営業とは月1回面談があった」「コードレビューはあるが、担当者によって差があった」といった情報なら、面接で確認できます。

一方で、「成長できない」「人が悪い」「案件が微妙」とだけ書かれている口コミは、背景が分かりません。
そのまま信じるより、「何が原因だったのか」を面接で確認する材料にしてください。

この章では、求人票の言葉から実態を見抜くポイントを整理しました。
次章では、入社前に聞くべき質問リストとして、SES・受託開発・自社開発それぞれで確認したい内容をまとめていきます

◆8. 入社前に聞くべき質問リスト。後悔しない会社選びの確認ポイント

この章では、入社前に聞いておきたい質問を、SES・受託開発・自社開発に分けて整理します。
質問は、相手を疑うためではなく、入社後に自分がどんな経験を積めるかを具体化するために使います。

・SES企業に聞くべきこと｜案件内容、商流、待機期間、自社フォロー

SES企業を見るときは、最初に案件内容とフォロー体制を確認してください。
「未経験歓迎」「案件多数」と書かれていても、初配属で多い作業が開発補助なのか、テストなのか、運用監視なのかで、入社後の経験は変わります。

聞くなら、次のような質問が使いやすいです。

• 未経験者の初配属では、どのような案件が多いですか
• 開発、テスト、運用、保守の割合はどれくらいですか
• 自社の先輩と同じ現場に入れる可能性はありますか
• 商流や現場情報は、面談前にどの程度共有されますか
• 案件が決まるまでの待機期間は、どのように過ごしますか
• 待機中の給与や評価はどう扱われますか
• 参画後に困ったとき、誰に相談できますか

特に見たいのは、「案件が選べます」よりも「案件情報をどこまで説明してもらえるか」です。
未経験者の場合、選べる案件の幅は限られることがあります。それでも、作業内容、チーム体制、現場で使う技術、相談先まで事前に聞ける会社なら、判断材料はだいぶ増えます。
逆に、「入ってから決まります」「現場次第です」だけで終わる場合は、追加で確認したほうが安全です。

・受託開発企業に聞くべきこと｜担当工程、納期管理、顧客折衝、チーム体制

受託開発企業では、担当工程とチーム体制を重点的に確認します。
受託開発は、顧客から依頼されたものを作るため、設計、実装、テスト、納品、保守の流れを経験しやすい一方で、納期や仕様変更の影響も受けやすい働き方です。

面接では、次のように聞くと具体的になります。

• 未経験者は最初にどの工程を担当することが多いですか
• 設計書や仕様書を読む機会はありますか
• コードレビューはどのように行われますか
• 顧客との打合せに若手が同席することはありますか
• 納期が厳しいとき、チームではどう調整していますか
• 仕様変更が出た場合、誰が影響範囲を整理しますか
• 1案件あたりのチーム人数はどれくらいですか

「上流工程あり」と書かれていても、未経験者が最初から要件定義を任されるとは限りません。
ただ、打合せに同席できる、議事録を作る、設計書を読む、レビュー指摘を受けながら修正する、といった経験があるなら、開発全体の流れはけっこう見えます。
私自身も、最初から何でもできたわけではなく、設計書を読み、指摘を受け、少しずつ担当範囲が広がっていきました。
受託開発では、「どの工程を担当するか」だけでなく、「誰がレビューしてくれるか」まで聞くと、成長しやすさを判断しやすいです。

・自社開発企業に聞くべきこと｜開発体制、改善サイクル、技術選定、保守比率

自社開発企業では、サービスの内容だけでなく、開発体制と改善サイクルを確認してください。
自社サービスに関われるのは魅力ですが、入社後すぐに新機能をどんどん作れるとは限りません。既存機能の保守、問い合わせ調査、障害対応、管理画面の改修から始まることもあります。

確認したい質問は、次のとおりです。

• 開発チームは何名くらいですか
• 未経験者や若手は、最初にどの作業を担当することが多いですか
• 新機能開発と既存機能の保守の割合はどれくらいですか
• 問い合わせ内容やユーザーの声を開発者も見ますか
• 改善提案は、どのような流れで採用されますか
• 技術選定は誰がどのように決めていますか
• 障害対応や運用改善に若手も関わりますか

自社開発を選ぶなら、「そのサービスが好きか」だけでは少し足りません。
サービスを長く育てるには、ユーザー、売上、問い合わせ、運用負荷、既存コードまで見る必要があります。
たとえば、ボタンを1つ直すだけでも、ユーザーの操作、CSへの問い合わせ、管理画面の集計に影響することがあります。
この視点を面白いと感じるなら、自社開発は相当合う可能性があります。
一方で、いろいろな業界や技術を短期間で経験したいなら、受託開発やSESのほうが合う場面もあります。

・年収・評価制度で確認すべきこと｜単価や売上ではなく何で評価されるか

年収や評価制度は、聞きにくくても必ず確認したいところです。
ただし、「年収はいくら上がりますか」だけで終わらせると、判断材料としては弱いです。
大事なのは、何をすると評価されるのか、どの経験が昇給や昇格につながるのかです。

確認するなら、次の質問が使えます。

• 評価はどの頻度で行われますか
• 評価項目には、技術力、勤怠、顧客評価、チーム貢献のどれが含まれますか
• 未経験者の場合、最初の評価では何を重視されますか
• 資格取得や学習記録は評価に入りますか
• SESの場合、現場での評価は自社評価にどう反映されますか
• 受託開発の場合、納期や品質はどう評価されますか
• 自社開発の場合、改善提案や障害対応は評価対象になりますか

労働契約法では、労働契約について、労働者と使用者が対等の立場で合意により締結・変更すべきものとされています。
法律の条文を面接で持ち出す必要はありませんが、働く条件や評価の考え方を曖昧なままにしない意識は持っておきたいです。
※参考: e-Gov法令検索（労働契約法）

年収は、会社タイプだけでは決まりません。
SESでも、顧客評価や案件単価との関係を見る会社があります。受託開発でも、納期や品質、担当工程が評価に影響することがあります。自社開発でも、サービス改善や障害対応、チームへの貢献が見られることがあります。
その分、入社前に「何を頑張れば評価されるのか」を聞いておくと、入社後の動き方がかなり変わります。

・聞きにくい質問を自然に確認するコツ

聞きにくい質問ほど、聞き方を変えると確認しやすくなります。
「ブラックですか」「案件を選べますか」「残業は本当に少ないですか」と直球で聞くと、相手も答えにくくなります。
代わりに、過去の例や具体的な流れを聞くと、自然に実態を確認できます。

たとえば、次のように言い換えます。

• 残業は多いですか
  → 繁忙期やリリース前は、どのような働き方になることが多いですか
• 本当に開発できますか
  → 未経験者が最初に担当する作業と、半年後に担当しやすい作業を教えてください
• 案件は選べますか
  → 案件候補はどのように提示され、本人の希望はどの段階で伝えられますか
• 教育体制はありますか
  → 配属後に質問できる相手や、レビューを受ける機会はありますか
• 評価は公平ですか
  → 評価項目と、直近で評価された若手の行動例を教えてください

ポイントは、「制度がありますか」ではなく、「実際にどう運用されていますか」と聞くことです。
制度名だけなら、どの会社でもきれいに見せられます。実例、頻度、担当者、過去の若手の流れまで聞くと、実態が見えやすくなります。
聞く側の姿勢も大事です。
疑う口調ではなく、「入社後に早くキャッチアップしたいので確認したいです」と前置きすると、だいぶ聞きやすくなります。
この章では、入社前に確認すべき質問を会社タイプ別に整理しました。
次章では、実際の現場で起きやすいギャップや失敗例から、会社選びで避けたいパターンを見ていきます。

◆9. 現場で感じやすいギャップと失敗例から選び方を考える

この章では、入社後に感じやすいギャップを、SES・受託開発・自社開発ごとに整理します。
ギャップを知る目的は、怖がることではありません。よくある失敗例を先に見ておくと、求人票や面接で確認すべきことが具体的になります。

・SESで起きやすいギャップ｜開発希望なのに運用・監視・テスト中心になるケース

SESで起きやすいギャップは、「開発エンジニアとして入ったのに、最初の仕事が運用・監視・テスト中心だった」というものです。
求人票に「開発案件あり」「Java案件多数」「Webシステム開発」と書かれていると、入社後すぐにコードを書く姿を想像しやすいです。
でも実際には、未経験者の初配属では、テスト、運用監視、問い合わせ対応、資料更新、ログ確認などから始まることがあります。

ここで大事なのは、運用・監視・テストが悪いという話ではないことです。
テストなら仕様書の読み方、不具合報告、再現手順の整理を学べます。運用監視なら、システムが止まらないように見る視点、障害時の一次切り分け、報告の流れを学べます。
問題は、その経験が次に広がる道筋が見えないまま、同じ作業だけが続いてしまうことです。

たとえば、入社前には「最初はテストからでも、その後は開発へ進めます」と聞いていたとします。
ただ、入社後に具体的な目安がなく、コードレビューもなく、開発案件へ移る条件も説明されないと、「いつ開発経験を積めるのか」が見えなくなります。
この状態が続くと、本人の努力不足というより、経験設計が曖昧な会社だった可能性があります。

SES企業を見るなら、次のように確認してください。

• 未経験者の初配属で多い作業は何ですか
• テストや運用から開発補助へ進む人はいますか
• 開発へ進むために必要な条件は何ですか
• 自社の先輩と同じ現場に入れる可能性はありますか
• 案件変更やキャリア相談は誰にできますか
• 半年後、1年後に担当している作業の例を教えてください

「最初から開発だけをやらせてください」と言う必要はありません。
むしろ、「最初の作業から次の経験へどうつながるか」を聞くほうが自然です。
ここが見える会社なら、最初がテストや運用でも、次につながる入口として考えやすくなります。

・受託開発で起きやすいギャップ｜技術より納期・仕様変更対応に追われるケース

受託開発で起きやすいギャップは、技術をじっくり学べると思って入ったのに、実際は納期や仕様変更への対応に追われるケースです。
受託開発は、顧客から依頼されたものを作る働き方なので、納期、品質、仕様の合意が大事になります。
そのため、技術的にきれいな実装を考えたい場面でも、期限や予算、顧客都合とのバランスを取る必要があります。

未経験者から見ると、受託開発は「開発経験を積みやすそう」「チームで教えてもらえそう」と見えやすいです。
もちろん、設計書を読み、実装し、レビューを受け、テストまで経験できるなら学びは多いです。
ただし、納期が近い案件では、先輩も忙しく、質問のタイミングを選ぶ必要が出ることがあります。

失敗例として多いのは、「技術を学べる環境」だと思って入ったのに、実際には仕様変更、顧客確認、テスト不具合、リリース準備が重なり、目の前の対応でいっぱいになるパターンです。
特に、見積りや影響範囲の確認が甘い現場では、後半で作業が膨らみやすくなります。
画面を少し直すだけに見えても、入力チェック、権限、既存データ、テスト観点、リリース手順まで見ると、作業量は相当増えることがあります。

受託開発を選ぶなら、納期があること自体を避けるのではなく、チームがどう支えているかを見てください。
確認したいのは、次のような点です。

• 未経験者が最初に担当する工程はどこですか
• レビューはどの頻度で行われますか
• 納期が厳しいとき、チームではどう調整しますか
• 仕様変更が出たとき、影響範囲は誰が整理しますか
• 顧客との打合せに若手が同席する機会はありますか
• 忙しい案件でも質問できる仕組みはありますか

受託開発は、きつい場面がある一方で、開発全体の流れを学べる可能性があります。
顧客の要望を受け、仕様を整理し、チームで形にし、テストして納める。この流れを横で見られるだけでも、独学では得にくい感覚が身につきます。
だからこそ、「納期があるか」だけでなく、「納期の中で新人をどう育てるか」を聞くことが大事です。

・自社開発で起きやすいギャップ｜華やかな新規開発より保守改善が多いケース

自社開発で起きやすいギャップは、華やかな新規開発を想像していたのに、実際は保守改善や問い合わせ調査が多いケースです。
自社開発という言葉には、自由に技術選定をして、新機能をどんどん作るイメージがあります。
でも実務では、既存機能の修正、障害調査、管理画面の改善、データ確認、問い合わせ対応、運用手順の見直しも大事な仕事です。

このギャップは、自社開発に期待している人ほど感じやすいです。
「自社サービスを作れる」と思って入ったのに、最初は古いコードを読み、細かい不具合を直し、ユーザーからの問い合わせを調べる日が続くことがあります。
ただ、それはつまらない仕事という意味ではありません。

自社サービスは、作ったあとも使われ続けます。
だから、ユーザーがどこで困っているのか、問い合わせがなぜ発生しているのか、運用チームがどこで手間を感じているのかを見る必要があります。
保守改善は地味に見えますが、サービスを長く続けるうえではだいぶ重要です。

たとえば、入力フォームのエラー表示を直すだけでも、問い合わせ数が減ることがあります。
管理画面の検索条件を少し改善するだけで、社内の確認作業が楽になることもあります。
障害の原因を調べ、再発防止策を入れることは、利用者から見れば大きな価値です。

自社開発を狙うなら、次のように確認してください。

• 新機能開発と保守改善の割合はどれくらいですか
• 若手は最初にどのような作業を担当しますか
• 問い合わせ調査や障害対応に若手も関わりますか
• ユーザーの声や利用データを見る機会はありますか
• 技術選定は誰がどのように決めていますか
• 改善提案はどのような流れで採用されますか

自社開発が向いているのは、コードだけでなく、サービス全体を見たい人です。
新規機能だけを期待するとギャップになりますが、保守改善や問い合わせ調査もサービスを育てる仕事だと捉えられるなら、学びはけっこう大きいです。

・「やめとけ」と言われる会社を避けるために見るべき共通点

「SESはやめとけ」「受託はきつい」「自社開発でも成長できない」といった言葉は、SNSや口コミでよく見かけます。
ただ、その言葉だけで会社タイプを切り捨てるのは危険です。
見るべきなのは、会社タイプそのものより、避けたい共通点があるかどうかです。

避けたい会社には、いくつか共通点があります。

• 入社後の初配属が曖昧
• 研修後の担当作業が説明されない
• 質問先やレビュー体制が見えない
• 評価基準が抽象的
• 残業や繁忙期の説明がぼんやりしている
• 若手のキャリア例を具体的に話せない
• 「現場次第」「案件次第」だけで終わる
• 不安を相談する窓口が見えない

こうした会社は、SESでも受託開発でも自社開発でも注意が必要です。
反対に、会社タイプが不安に見えても、初配属、担当工程、フォロー体制、評価、キャリア例を具体的に説明してくれる会社なら、判断材料は増えます。

厚生労働省の「確かめよう労働条件」では、労働基準関係法令や相談先など、労働条件の悩みを解消するための情報が掲載されています。
入社前の会社選びでも、仕事内容や経験だけでなく、労働条件、相談先、働き方の説明が曖昧ではないかを見ておくと安全です。
※参考: 厚生労働省「確かめよう労働条件」

面接では、強い言葉で詰める必要はありません。
「入社後のイメージを具体化したいので、過去の未経験者の配属例を教えてください」
「早くキャッチアップしたいので、質問やレビューの流れを確認したいです」
このように聞けば、自然に実態を確認できます。

最終的には、「やめとけ」と言われているかどうかより、自分がそこで経験を積める根拠を持てるかです。
求人票、面接、口コミを見たうえで、半年後に何を説明できるようになりそうかを考えてください。
この章では、現場で感じやすいギャップと失敗例を整理しました。
次章では、未経験者、若手、経験者などキャリア別に、会社タイプを選ぶ基準がどう変わるかを見ていきます。

◆10. キャリア別に考える。未経験・若手・経験者で選ぶ基準は変わる

この章では、キャリアの段階ごとに、SES・受託開発・自社開発を見る基準を整理します。
同じ会社タイプでも、未経験者、経験1〜3年の若手、すでに現場経験がある人では、見るべきポイントがかなり変わります。

・未経験者はどこを見る？入りやすさより「最初の1年で何を経験できるか」

未経験者が最初に見るべきなのは、入りやすさだけではありません。
もちろん、未経験から応募できるか、研修があるか、選考で何を見られるかは大事です。

ただ、入社しやすい会社と、入社後に経験が増える会社は必ずしも同じではありません。
最初の1年で、何を任され、誰からレビューを受け、どんな作業を職務経歴書に書けるようになるかを見てください。

未経験者が確認したいのは、次のような点です。

• 研修後の初配属で多い作業は何か
• 最初の半年で担当しやすい工程はどこか
• テスト、運用、保守から開発補助へ進む流れはあるか
• 質問できる先輩やレビュー担当はいるか
• 学習内容と現場作業がつながっているか
• 1年後に説明できる経験が増えそうか

SESなら、初配属の案件内容と自社フォローを見ます。
受託開発なら、未経験者がどの工程から入り、レビューを受けながら実装やテストへ進めるかを見ます。
自社開発なら、既存サービスの保守改善からでも、コードを読み、問い合わせを調べ、改善につなげる機会があるかを見ます。

最初から理想の開発ばかりできるとは限りません。
それでも、経験が次につながる設計になっている会社なら、入口としては十分候補になります。

・経験1〜3年の若手は何を重視する？担当工程と技術スタックを確認する

経験1〜3年の若手は、入りやすさよりも担当工程と技術スタックを重視したほうがいいです。
この時期は、「何となくIT業界に入りたい」から、「自分は何を担当できる人なのか」を作っていく段階です。

担当工程では、実装だけでなく、設計書を読む、テスト観点を作る、レビューを受ける、不具合を調査する、リリース作業に関わるといった経験を見ます。
技術スタックでは、言語名だけでなく、フレームワーク、データベース、クラウド、Git、CI/CD、監視、ログ調査まで見たいところです。

若手が転職先を選ぶときは、次の質問が使えます。

• 直近の若手はどの工程を担当していますか
• 既存コードの改修だけでなく、新規機能に関わる機会はありますか
• コードレビューでは、どのような観点で指摘されますか
• 技術スタックはどのように決まっていますか
• 設計や顧客折衝に進む流れはありますか
• 障害対応や問い合わせ調査に若手も関わりますか

SESの場合、案件によって技術スタックが変わるため、現場で使う技術と次案件への広がりを確認します。
受託開発の場合、複数案件を通じて設計、実装、テストを経験できる一方、納期負荷も見ておきたいです。
自社開発の場合、同じ技術を深掘りしやすい一方で、技術の幅が固定されやすいこともあります。

経験1〜3年は、けっこう分岐が大きい時期です。
「何でもできます」より、「この工程なら説明できます」「この技術なら実務で触りました」と言える経験を増やすほうが、次の選択肢につながります。

・SESから受託・自社開発へ移りたい人が棚卸しすべき経験

SESから受託開発や自社開発へ移りたい人は、まず自分の経験を棚卸ししてください。
「SESだったから不利」と考える必要はありませんが、「SESにいました」だけでは説明として弱いです。

棚卸しするときは、会社タイプではなく、実際にやった作業で分けます。

• どんなシステムやサービスに関わったか
• 担当工程は何だったか
• 使った言語、ツール、環境は何か
• 設計書や仕様書を読んだか
• コードを書いたか、修正したか
• テストや不具合調査をどこまで担当したか
• 障害対応やログ調査に関わったか
• 顧客や現場メンバーとどのように連携したか
• 自社への報告や評価面談で何を話していたか

たとえば、運用監視中心だったとしても、アラート対応、一次切り分け、ログ確認、障害報告まで経験しているなら、システムを安定稼働させる視点を説明できます。
テスト中心だったとしても、仕様書を読み、不具合を起票し、再現手順を整理し、開発者とやり取りしていたなら、品質を支える経験として話せます。

受託開発へ移りたいなら、設計書、実装、レビュー、テスト、納期意識に近い経験を強調します。
自社開発へ移りたいなら、保守改善、問い合わせ調査、障害対応、ユーザーや運用側への影響を考えた経験を整理します。

大事なのは、今の経歴を否定しないことです。
SESで積んだ経験を、受託開発や自社開発で使える言葉に翻訳できれば、次の選択肢は見えやすくなります。

・将来PL・PM・管理職を目指す人が見たい顧客折衝とチーム経験

将来プロジェクトリーダー（PL）、プロジェクトマネージャー（PM）、管理職を目指す人は、技術だけでなく顧客折衝とチーム経験を見てください。
リーダー寄りのキャリアでは、自分が作れるだけでは足りません。
人と認識を合わせ、スケジュールを見て、リスクを早めに拾い、関係者に説明する力が必要になります。

SESなら、現場での報告、顧客先リーダーとの会話、自社への状況共有、後輩のフォロー経験が材料になります。
受託開発なら、顧客打合せ、仕様整理、見積り補助、進捗管理、レビュー、納期調整に関わる機会が重要です。
自社開発なら、事業部、CS、営業、運用チームと会話しながら、改善の優先順位を決める経験が役立ちます。

将来PL・PMを目指すなら、面接では次のように確認するとよいです。

• 若手が顧客打合せや社内調整に同席する機会はありますか
• 議事録、仕様整理、影響範囲の確認を任されることはありますか
• チーム開発では、どのように進捗を管理していますか
• レビューやタスク分担は誰が行っていますか
• 後輩や新人をフォローする機会はありますか
• 障害や炎上時に、誰がどのように判断しますか

私自身、技術だけを追っている時期と、周囲との調整まで見る時期では、仕事の見え方が大きく変わりました。
自分の作業だけなら完了できても、他の人の作業、顧客の期待、納期、品質まで見始めると、難しさは相当上がります。

ただ、その経験があると、将来のキャリアは広がります。
管理職まで目指すかどうかに関係なく、チームで成果を出す力は、SES・受託開発・自社開発のどれでも評価されやすい経験です。

・迷ったときの判断軸｜今の不満ではなく次に増やしたい経験から選ぶ

迷ったときは、今の不満だけで会社タイプを選ばないことです。
「SESが嫌だから受託開発」「受託が忙しいから自社開発」「自社開発なら楽そう」という選び方をすると、別のギャップにぶつかることがあります。

大事なのは、次に増やしたい経験から逆算することです。

• コードを書く経験を増やしたいのか
• 設計書や仕様書を読む力を伸ばしたいのか
• 顧客折衝や上流工程に関わりたいのか
• 自社サービスを長く改善したいのか
• チームをまとめる経験を積みたいのか
• 技術の幅を広げたいのか、1つの技術を深めたいのか

キャリアを考えるときは、IPA「デジタルスキル標準」のように、役割とスキルを分けて見る資料も参考になります。
会社タイプの名前だけではなく、どの役割に近づきたいのか、どのスキルを増やしたいのかを考えると、判断がだいぶ整理しやすくなります。

たとえば、未経験者なら「最初の1年で何を経験できるか」。
経験1〜3年なら「担当工程と技術スタック」。
SESから移りたい人なら「経験の棚卸しと言語化」。
将来PL・PMを目指す人なら「顧客折衝とチーム経験」。

このように、今の立場によって見る軸は変わります。
会社タイプを先に決めるより、自分が次に増やしたい経験を先に決めてください。

この章では、キャリア別に会社タイプを選ぶ基準を整理しました。
次章では、SES・受託開発・自社開発を選ぶ前に知っておきたい注意点として、会社タイプだけでホワイト・ブラックを判断しない見方を整理していきます

◆11. SES・受託開発・自社開発を選ぶ前に知っておきたい注意点

この章では、SES・受託開発・自社開発を選ぶ前に、最後に見落としやすい注意点を整理します。
ここまで会社タイプごとの違いを見てきましたが、最終的な判断では「どのタイプか」より、「その会社で自分の経験がどう増えるか」を見る必要があります。

・会社タイプだけでホワイト・ブラックを判断しない

SESだからブラック、自社開発だからホワイト、受託開発だから忙しい。こうした決めつけは、応募先選びではあまり役に立ちません。
もちろん、会社タイプごとに起きやすい傾向はあります。SESは案件差が出やすく、受託開発は納期や仕様変更の影響を受けやすく、自社開発は事業状況や開発組織の成熟度に左右されやすいです。
ただ、それは「そのタイプなら全部同じ」という意味ではありません。

同じSESでも、自社の先輩と同じ現場に入り、定期面談があり、案件変更の相談ができる会社もあります。
同じ受託開発でも、無理な納期を受けすぎず、見積りや仕様変更の整理をチームで行う会社もあります。
同じ自社開発でも、レビュー体制が薄く、若手が保守だけを抱え込む会社もあります。

見るべきなのは、会社タイプの名前ではなく、働き方の運用です。
具体的には、初配属、担当工程、レビュー体制、残業の出方、評価制度、相談先、若手のキャリア例を確認します。
ここが説明できる会社なら、会社タイプに関係なく判断材料は増えます。逆に、どの質問にも「現場次第です」「入ってから決まります」だけで終わる会社は、慎重に見たほうがよいです。

・SESを避けるより先に見るべきこと｜案件内容・評価制度・フォロー体制

SESを避けるかどうかを考える前に、まず案件内容・評価制度・フォロー体制を見てください。
SESで不安になりやすいのは、入社後の案件が見えにくいことです。
未経験者の場合、開発を希望していても、最初はテスト、運用監視、問い合わせ対応、資料作成から始まることがあります。

このとき大事なのは、その作業が次の経験につながるかです。
テストから仕様理解や小さな改修へ進めるのか。
運用監視から障害調査やログ分析へ広がるのか。
問い合わせ対応から原因調査や改善提案に関われるのか。
この流れが見えるなら、最初の作業が地味でも経験として残ります。

評価制度も確認したいところです。
SESでは、現場での評価と自社での評価が分かれることがあります。
現場で頑張っても、自社の上司に伝わらなければ評価につながりにくいです。
そのため、現場評価を誰が回収するのか、月次面談で何を話すのか、資格や学習記録は評価に入るのかを聞いておきます。

フォロー体制では、自社の営業や上司との関係を見ます。

• 参画後の面談頻度はどれくらいか
• 案件が合わないときに相談できるか
• 自社の先輩と同じ現場に入れる可能性はあるか
• 一人で現場に入る場合、誰に質問できるか
• 次の案件へ進む条件は説明されるか

SESそのものを避けるより、放置される構造がないかを見るほうが現実的です。
案件内容、評価制度、フォロー体制の3つが曖昧な会社は、入社後に不安が大きくなりやすいです。

・受託開発で確認したいこと｜納期管理と炎上時の支援体制

受託開発で確認したいのは、納期管理と炎上時の支援体制です。
受託開発は、顧客から依頼されたものを作る働き方なので、期限や品質への意識が強くなります。
そのぶん、開発工程を学びやすい一方で、納期が厳しい案件では負荷が高くなることがあります。

未経験者や若手が受託開発を見るときは、「開発できるか」だけでなく、「忙しいときにどう支える会社か」を確認してください。
普段はチームで教えてくれる会社でも、リリース前や仕様変更が重なったときに、質問しづらくなることがあります。
ここで支援体制が弱いと、若手だけが抱え込んでしまいます。

確認したい質問は、次のようなものです。

• 納期が厳しいとき、チームではどう調整していますか
• 仕様変更が出た場合、影響範囲は誰が整理しますか
• 見積りはどのような流れで行っていますか
• 若手が担当した作業は誰がレビューしますか
• 炎上しそうな案件では、追加メンバーや上長の支援はありますか
• 顧客との認識違いが出たとき、誰が窓口になりますか

受託開発は、顧客折衝、仕様整理、設計、実装、テスト、納品までを見られる可能性があります。
これは若手にとって大きな経験です。
ただし、納期管理が個人任せになっている会社では、学びよりも消耗が先に来ることがあります。

私なら、受託開発企業を見るときは「納期があるか」ではなく、「納期がある中でチームがどう動くか」を見ます。
忙しい場面をどう乗り切るかに、その会社の開発組織の考え方が出やすいからです。

・自社開発で確認したいこと｜事業フェーズと開発組織の成熟度

自社開発で確認したいのは、事業フェーズと開発組織の成熟度です。
自社開発は人気がありますが、入社すれば自由に新機能を作れるとは限りません。
サービスの状態によって、任される仕事は変わります。

立ち上げ期のサービスなら、新機能開発や仕様変更が多く、スピード感があります。
一方で、手順や教育体制が整っていないこともあります。
成長期のサービスなら、機能追加、障害対応、運用改善が同時に走りやすいです。
成熟期のサービスなら、保守、安定運用、問い合わせ削減、コスト改善が中心になることがあります。

どのフェーズが良い悪いではありません。
自分が何を経験したいかと合っているかが大事です。
新規開発を期待しているのに、実際は古い管理画面の保守が中心だとギャップになります。
逆に、保守改善や運用改善からサービス全体を理解したい人には、成熟した自社サービスのほうが学びやすいこともあります。

開発組織の成熟度も見てください。

• 開発チームは何名くらいか
• レビューや設計相談の仕組みはあるか
• 問い合わせや障害対応の担当は決まっているか
• 技術選定は誰が決めているか
• 事業部、営業、CSとの連携はどのように行うか
• 若手が改善提案を出せる場はあるか

厚生労働省「職場情報総合サイト（しょくばらぼ）」のように、企業の職場情報を検索・比較できる公的サイトもあります。
すべての判断をそこで済ませる必要はありませんが、求人票や面接だけで分からない職場情報を補助的に見る材料になります。

自社開発は、会社の事業そのものと近い距離で働く環境です。
それだけに、サービスのフェーズと開発組織の状態を見ないまま選ぶと、期待とのズレが出やすくなります。

・比較表だけで決めず、求人票・面接・口コミをセットで見る

最後は、比較表だけで決めないことです。
比較表は、SES・受託開発・自社開発の違いを整理するには便利です。
ただし、実際の会社選びでは、比較表だけでは足りません。

求人票、面接、口コミをセットで見てください。
求人票では、会社が見せたい情報がまとまっています。
面接では、求人票に書かれていない運用や過去の若手の例を確認できます。
口コミでは、実際に働いた人の声が見えます。
ただし、口コミは部署、時期、案件、上司、本人の状況によって内容が変わるため、そのまま全体化しないことが大事です。

見る順番としては、次の流れが使いやすいです。
まず求人票で、会社タイプ、担当工程、研修、働き方、評価制度を拾います。
次に面接で、初配属、若手の担当例、レビュー体制、残業の出方、相談先を聞きます。
最後に口コミで、求人票や面接で聞いた内容とズレがないかを確認します。

もし不安な口コミがあれば、面接でそのままぶつけるのではなく、具体的な質問に変えます。
「残業が多いと見ました」ではなく、「繁忙期やリリース前は、どのような働き方になりますか」と聞く。
「教育が薄いと見ました」ではなく、「配属後の質問先やレビューの流れを教えてください」と聞く。
この聞き方なら、相手も答えやすく、自分も判断しやすくなります。

会社選びで大事なのは、完璧な会社を探すことではありません。
自分が受け入れられるリスクと、そこで増やせる経験を見比べることです。
SES、受託開発、自社開発のどれを選んでも、良い面と注意点はあります。
そのため、比較表で全体像をつかみ、求人票で候補を絞り、面接で実態を確認し、口コミで補助的に照合する。
この順番で見ると、会社タイプの印象だけに流されにくくなります。

この章では、会社タイプを選ぶ前に知っておきたい注意点を整理しました。
次章では、よくある質問として、SES・受託開発・自社開発で読者が最後に迷いやすい不安をまとめて解消していきます。。

◆12. よくある質問｜読者が最後に迷いやすい不安を解消

ここまでSES・受託開発・自社開発の違いを、働き方、担当工程、求人票、面接、キャリア別の選び方まで整理してきました。

最後に、読者が迷いやすい質問をまとめて確認しておきます。ここで大事なのは、短い答えで決めつけず、応募先ごとの実態に落とし込んで考えることです。

・Q1. SES・受託開発・自社開発の違いを一言でいうと何ですか？

一言でいうなら、SESは顧客先や顧客プロジェクトを技術支援する働き方、受託開発は顧客から依頼されたシステムや機能を作る働き方、自社開発は自社サービスや自社プロダクトを育てる働き方です。

ただし、この一言だけで会社を判断するのは危険です。

SESでも開発補助や設計支援に入れる会社があります。受託開発でも保守や改修が中心の案件があります。自社開発でも新機能ばかりではなく、問い合わせ調査や障害対応、既存機能の改善が多い会社もあります。

つまり、違いを覚えたあとは、「自分はその会社で何を担当するのか」まで確認してください。

・Q2. 未経験ならSES・受託開発・自社開発のどれを選ぶべきですか？

未経験なら、どれを選ぶべきかより、最初の1年で経験が増える会社を選ぶべきです。

SESが向いているのは、入口の広さを活かしつつ、案件内容や自社フォローを確認しながらIT実務に入っていきたい人です。最初がテストや運用でも、仕様理解、ログ確認、不具合報告、小さな改修へつながるなら経験として残ります。

受託開発が向いているのは、チームで開発工程を見ながら、設計、実装、テスト、顧客対応の流れを学びたい人です。ただし、納期があるため、質問できる体制やレビューの有無は必ず見たいところです。

自社開発が向いているのは、同じサービスを長く改善し、ユーザーや事業の反応も見ながら働きたい人です。ただし、未経験から入るには基礎学習や自作物の説明を求められることがあります。

迷ったら、会社タイプではなく「入社後に職務経歴書へ書ける作業が増えるか」で比べてください。

・Q3. SESはやめとけと言われますが、本当に避けたほうがいいですか？

SESを一括で避ける必要はありません。ただし、避けたほうがよいSES企業はあります。

注意したいのは、案件内容が曖昧、研修後の配属が説明されない、自社の面談やフォローが薄い、現場評価が自社評価にどう反映されるか分からない、案件変更の相談先が見えない会社です。

反対に、初配属の傾向、自社の先輩と入れる可能性、面談頻度、評価制度、次の案件へ進む条件を具体的に説明してくれる会社なら、判断材料は増えます。

「SESだからやめとけ」ではなく、「放置される構造がないか」「次に増やしたい経験へつながるか」を見てください。

・Q4. 自社開発は本当におすすめですか？

自社開発はおすすめされやすいですが、誰にでも正解とは限りません。

自社開発の魅力は、同じサービスを継続的に改善できることです。ユーザーの反応、問い合わせ、障害、運用負荷を見ながら、サービスを育てる経験ができます。

一方で、事業フェーズによっては保守改善や問い合わせ調査が中心になることもあります。使う技術が固定され、技術の幅が広がりにくいこともあります。開発組織が小さい会社では、教育体制が整っていない場合もあります。

自社開発を選ぶなら、サービス名だけでなく、開発チームの人数、保守と新機能の割合、レビュー体制、若手が任される作業、改善提案の通り方まで確認してください。

・Q5. SESから自社開発へ転職することはできますか？

できます。ただし、「SESから自社開発へ行きたいです」だけでは弱いです。

必要なのは、SESで経験した作業を自社開発でも伝わる言葉に変えることです。

たとえば、テスト経験なら、仕様書を読み、不具合を見つけ、再現手順を整理し、開発者とやり取りした経験として説明できます。
運用監視なら、アラート対応、ログ確認、一次切り分け、障害報告の経験として整理できます。
問い合わせ対応なら、ユーザーや現場の困りごとを整理し、原因調査につなげた経験として話せます。

自社開発側が見たいのは、会社タイプではなく、既存サービスを読み解き、改善し、チームで動ける人かどうかです。

経験を棚卸しするときは、厚生労働省「マイジョブ・カード」のように、職務経験やスキルを整理する公的なツールも参考になります。自分の経験を言語化しておくと、転職時の説明がしやすくなります。

・Q6. 受託開発は納期がきついのでしょうか？

受託開発は、納期がきつくなることがあります。ただし、すべての受託開発が常に厳しいわけではありません。

納期が大変になるのは、仕様変更、見積り漏れ、不具合、顧客確認の遅れ、リリース前の作業が重なったときです。顧客に納める仕事なので、期限と品質への意識は強くなります。

受託開発を見るときは、納期があるかどうかではなく、納期に対してチームがどう動くかを確認してください。

「納期が厳しいとき、誰が調整しますか」「仕様変更の影響範囲は誰が整理しますか」「若手の作業は誰がレビューしますか」「忙しい案件でも質問できる仕組みはありますか」と聞くと、会社の支援体制が見えやすくなります。

・Q7. SESの待機期間中は給料が出ますか？

待機期間中の給与は、会社の雇用契約や就業規則、待機の扱いによって変わります。この記事だけで断定はできません。

ただ、入社前に確認すべき内容ははっきりしています。

• 待機中の給与は通常どおり支払われるのか
• 待機中は研修、学習、面談準備のどれを行うのか
• 待機期間は評価にどう影響するのか
• 次案件は誰がどのように探すのか
• 本人の希望はどの段階で聞いてもらえるのか
• 面談で通らなかった場合、どのようなフォローがあるのか

聞きにくい場合は、「入社後の過ごし方を具体的に把握したいので、案件決定前の期間について教えてください」と聞くと自然です。

待機期間があること自体より、待機中の給与、学習、評価、次案件の決まり方が曖昧なままになっているほうが問題です。

・Q8. 入社前の面接では何を聞けば失敗しにくいですか？

失敗しにくくするには、会社タイプの一般論ではなく、自分が入社した場合の具体例を聞くことです。

特に聞きたいのは、初配属、担当工程、レビュー体制、質問先、評価制度、残業の出方、若手のキャリア例です。

質問例としては、次のような形が使いやすいです。

• 未経験者の初配属では、どのような作業が多いですか
• 半年後、1年後に担当している作業の例を教えてください
• コードレビューや設計レビューはどのように行われますか
• 配属後に質問できる相手は誰になりますか
• 評価では、技術力、勤怠、顧客評価、チーム貢献のどれを見ますか
• 繁忙期やリリース前は、どのような働き方になりますか
• 直近で若手が成長した例を教えてください

聞くときは、疑う言い方ではなく、「入社後に早くキャッチアップしたいので確認したいです」と前置きすると、相手も答えやすくなります。

この章では、最後に迷いやすい質問を整理しました。次章では、記事全体のまとめとして、SES・受託開発・自社開発を「どこが良いか」ではなく「何を積めるか」で選ぶ考え方を整理します。

◆まとめ｜SES・受託開発・自社開発は「どこが良いか」より「何を積めるか」で選ぼう

ここまで、SES・受託開発・自社開発の違いを、働き方、担当工程、求人票、面接、キャリア別の視点から見てきました。

最後にもう一度、結論を整理します。選ぶ基準は「どこが良い会社タイプか」ではなく、「自分がそこで何を経験として積めるか」です。

・3つの違いを整理して、自分が重視する経験を決める

SES・受託開発・自社開発は、単なる会社分類ではありません。働く場所、関わる相手、成果の見られ方、経験しやすい工程が変わる言葉です。

SESは、顧客先や顧客プロジェクトに入り、現場を支援する働き方です。案件差はありますが、テスト、運用、保守、開発補助など、IT実務へ入る入口になりやすい面があります。

受託開発は、顧客から依頼された成果物をチームで作る働き方です。納期や仕様変更の大変さはありますが、設計、実装、テスト、レビュー、顧客対応の流れを見やすい環境でもあります。

自社開発は、自社サービスや自社プロダクトを継続的に改善していく働き方です。サービスへの愛着を持ちやすい一方で、保守、問い合わせ調査、障害対応、事業都合への対応も仕事に入ります。

つまり、どれにも良い面と注意点があります。

未経験者が最初に決めるべきなのは、「自分は何を経験したいのか」です。コードを書く経験を増やしたいのか、設計やレビューを学びたいのか、顧客折衝を見たいのか、自社サービスを育てたいのか。ここを決めないまま会社タイプだけを選ぶと、入社後に「思っていた働き方と違う」と感じやすくなります。

・求人票と面接で、入社後に任される仕事を確認する

会社選びでは、求人票と面接をセットで使ってください。

求人票では、会社タイプ、仕事内容、研修、勤務地、働き方、評価制度を確認します。ただし、求人票はあくまで入口です。「開発」「自社開発あり」「案件選択制」「未経験歓迎」「研修あり」といった言葉は、会社によって中身が違います。

面接では、その言葉の運用を確認します。

• 未経験者の初配属では、どのような作業が多いか
• 研修後はどの部署や案件に進むことが多いか
• コードレビューや設計レビューはあるか
• 配属後に質問できる相手は誰か
• 半年後、1年後に担当している作業の例は何か
• 評価では何を重視されるか
• 繁忙期やリリース前はどのような働き方になるか

こうした質問をすると、求人票の言葉が実際の仕事に落ちてきます。

たとえば「開発案件あり」と書かれていても、自分の初配属がテスト中心なのか、小さな改修から入れるのか、レビューを受けられるのかで経験の残り方は変わります。「自社開発あり」と書かれていても、自社サービス部門に入れるのか、自社内で受託案件を開発するのかで働き方は変わります。

聞きにくい質問でも、「入社後に早くキャッチアップしたいので確認したいです」と前置きすれば、自然に聞けます。会社を疑うためではなく、自分がそこで経験を積めるかを確認するための質問です。

・未経験転職・職種選び・Web/インフラ比較は関連記事で補う

この記事では、SES・受託開発・自社開発の違いに絞って説明しました。

ただ、実際の転職では、会社タイプだけでなく、未経験転職そのものの進め方、ITエンジニアの職種選び、Webエンジニアとインフラエンジニアの違いも関係してきます。

たとえば、「そもそも未経験からITエンジニアを目指して大丈夫か」と不安な人は、未経験転職の厳しさと成功しやすい準備を別で整理したほうがよいです。

「どの職種を選べばよいか」で止まっている人は、フロントエンド、バックエンド、インフラ、社内SE、ヘルプデスク、テスターなど、職種ごとの入口と将来性を比べる必要があります。

「Webとインフラで迷う」という人は、作る対象、学ぶ技術、向いている作業、未経験から入りやすい求人の違いを見たほうが判断しやすくなります。

関連記事は、その足りない部分を補うために使ってください。

この記事で会社タイプの違いを整理し、関連記事で職種や転職準備を補う。そうすると、「SESか受託か自社開発か」だけではなく、「自分はどの職種で、どんな経験を積み、次にどう進みたいのか」までつながって見えるようになります。

・迷ったら、応募前に第三者へ相談して会社選びの軸を整理する

最後に、迷ったら一人で抱え込まないことも大事です。

求人票を読み込んでいると、どの会社も良く見えたり、逆にどの会社も不安に見えたりします。口コミを見れば見るほど、判断が揺れることもあります。
そんなときは、応募前に第三者へ相談して、自分の会社選びの軸を整理してください。

相談するときは、「どの会社が良いですか」と丸投げするより、次のように材料を出すと整理しやすいです。

• 自分が今いちばん増やしたい経験
• 応募先で最初に任されそうな作業
• 求人票で気になった言葉
• 面接で確認したい質問
• 不安に感じている点
• 半年後、1年後に説明できるようになりたい経験

これを並べるだけでも、感情ではなく経験軸で判断しやすくなります。

職業能力開発促進法でも、職業に必要な能力を開発し、向上させる考え方が扱われています。細かい条文を覚える必要はありませんが、キャリアを考えるときは「今の会社名」より「次に伸ばす能力」を見る意識が大切です。
※参考: e-Gov法令検索（職業能力開発促進法）

SES、受託開発、自社開発のどれを選んでも、入社しただけでキャリアが完成するわけではありません。最初の現場で何を学び、どの経験を記録し、次にどんな役割へ進むかで、キャリアの見え方は変わります。
だから、会社タイプの優劣で決めるのではなく、積める経験で選んでください。

入社後に「自分はこの環境で何を学べるか」を説明できる会社なら、未経験からの一歩として十分に検討する価値があります。