IT・エンジニア転職

自社開発・受託開発・客先常駐を業務条件から比較

2026.09.24

「自社開発なら上流工程に関われる」「客先常駐なら開発できない」と、区分だけで仕事を決め付けるのは早計です。実際に任される仕事は、配属先や案件、契約、チームの構成によって変わります。会社の分類は入口として使い、日々の業務を具体的に確認していきましょう。

開発者が共同で作業する落ち着いたソフトウェア開発オフィスのイメージ

AIで作成したイメージ画像

先に結論

自社開発・受託開発・客先常駐は同じ軸の分類ではありません。雇用主、開発する事業、勤務場所を分け、今回の担当工程、指示や相談の相手、配属変更、労働条件で求人を比較します。

  • 会社全体の事業説明と、本人の配属予定を区別する。

  • 希望する工程は、最近の案件と最初の担当業務から確認する。

  • 勤務場所・業務の変更範囲と、案件終了時の扱いも聞く。

対象:雇用されるエンジニアの求人を比較する人。求人A・Bは架空例で、業態の実態調査ではありません。個人事業の契約判断や、個別案件の適法性の判定は対象外です。

比較する前に、雇用主・事業・勤務場所を三つに分ける

自社開発、受託開発、客先常駐は、同じ軸で区切った三種類の雇用形態ではありません。求人でいう自社開発や受託開発は、何のために、誰から依頼を受けて開発するかの説明に使われます。一方、客先常駐は主に仕事をする場所の説明です。これらを一列に並べて良し悪しを決めると、契約や担当業務の違いを見落としやすくなります。

求人を読むときは、誰と雇用契約を結ぶのか、どの事業・システムへ関わるのか、どこで働くのかを別の欄へ書き出します。受託した仕事を自社のオフィスで進める場合もあれば、顧客の場所でチームとして進める場合も考えられます。自社で運営するサービスでも、今回の募集では一部分の保守を担当するかもしれません。会社全体の特徴と本人の仕事を分けて確認します。

この記事は、エンジニアとして雇用される仕事を比較するための質問と整理方法を扱います。個人事業主として業務委託を受ける場合の契約判断は対象に含めません。派遣や請負の制度については厚生労働省の説明を参照しますが、個別の働き方の適法性をこの記事だけで判定することはできません。契約と実態に疑問があれば、雇用主や公的な相談窓口へ確認してください。

比較のゴールは、一つの分類を正解にすることではありません。今後担当したい仕事と、続けられる勤務条件を明らかにし、候補求人のどこまで確認できたかを把握することです。条件が分からない欄は、悪い条件と決め付けるのでも、希望どおりと埋めるのでもなく、追加で聞く項目として残しておきましょう。

求人の言葉を分解するための確認欄

軸

確認する内容

混同しやすいこと

雇用関係

労働契約を結ぶ相手と雇用条件

勤務場所にある会社が雇用主だと思う

事業・開発対象

今回関わるシステムと募集の背景

会社全体の事業を本人の担当とみなす

勤務場所

雇入れ直後の場所と変更範囲

客先常駐という言葉で契約内容まで判断する

業務体制

作業の指示・技術相談・評価を担う人

全て同じ窓口だと考える

自社開発では、事業の近さと本人の担当範囲を確認する

自社のサービスや製品を開発する求人では、利用者の要望や事業上の優先順位が開発へどう届くかを聞きます。自社サービスに関わるという説明があっても、開発者が直接利用者へ聞くのか、企画担当がまとめるのか、経営の判断で変更するのかは別の話です。自分が希望するのが機能実装か、課題の発見からの参加かによって確認点が変わります。

「裁量が大きい」という言葉も、何を決められるかへ分解します。担当タスクの実装方法を選べること、技術構成を提案できること、何を作るかを決めることは異なります。全部を一人で担いたい人もいれば、まずレビューを受けながら実装経験を積みたい人もいます。裁量の量より、自分の経験に合う責任と相談先があるかを見てください。

サービスの成長段階や担当プロダクトも質問できます。新規開発、既存機能の改善、運用上の安定化では、日々の仕事と評価される行動が違います。求人ページで紹介されている新機能が、今回の配属チームの仕事とは限りません。「最近入った人は最初に何を担当したか」「今回の募集で解決したい課題は何か」を聞くと、募集の背景へ近づけます。

長く同じサービスに関わりたい場合は、改修後の結果を追う機会や、運用への関わりも確認します。一方、異なる業種や技術に触れたいなら、担当変更の仕組みと実例を聞きます。事業に近いという利点が自分の仕事でも得られるか、同じ領域へ継続して関わることが希望に合うかを、両方から比較してください。

受託開発では、顧客との接点と変更への対応を見る

受託開発の求人では、何を誰から依頼され、どの工程まで担当するかを確認します。「要件定義から対応」と会社紹介に書かれていても、応募者本人が要件を整理する仕事へ参加するとは限りません。顧客との打合せ、設計の承認、実装、テスト、納品後の支援という流れの中で、今回の担当がどこからどこまでかを具体的に聞きましょう。

顧客との距離も、契約階層の名称だけで判断しないようにします。直接話す機会があっても決定権がない場合や、窓口を通じていても仕様の論点を十分に提案できる場合があります。自分が経験したいのが顧客へのヒアリングなのか、曖昧な要望の整理なのか、提案書の作成なのかを伝えると、必要な接点を確認しやすくなります。

納期のある仕事をどう進めるかも比較点です。仕様が変わったとき、追加の作業を誰が見積もり、日程や範囲を誰と調整するのかを聞きます。変更が多いという情報だけで職場を評価せず、無理な条件が生じた際の相談経路や、品質の確認に必要な時間をどう確保するかまで確認します。直近の案件での対応例があると、運用を想像できます。

案件ごとに経験を広げたい場合は、新しい案件への移り方と、前の案件の保守をどの程度並行するかも尋ねます。次々に別の開発へ進めるという期待があっても、過去案件の問い合わせ対応が長く残るかもしれません。反対に、納品後も改善へ関わりたいなら、継続して参加できる仕事があるかを聞きます。希望する経験の時間軸を合わせることが大切です。

客先常駐では、働く場所から契約内容を推測しない

客先で働くという説明から分かるのは、勤務場所の一部です。それだけでは、雇用主、契約の種類、業務上の指示をする人、開発の担当工程は判断できません。「SES」という呼び方が使われていても、その名称だけで自分の雇用条件や実際の業務体制がすべて決まるわけではありません。採用窓口には、今回の働き方を具体的に説明してもらいます。

厚生労働省は、労働者派遣では派遣元に雇用される労働者が派遣先の指揮命令を受けて働くと説明しています。また、派遣と請負の区分は契約の名称だけでなく、実態に基づいて判断されるとしています。求人を比較するときも、勤務場所と指揮命令の関係を分けて把握することが出発点になります。 (出典:厚生労働省|労働者派遣・請負を適正に行うためのガイド)

実務上の質問としては、「日々の作業の割当てと優先順位は誰が決めるか」「勤務や業務の相談はどこへ連絡するか」「所属会社の上司とはいつ話せるか」があります。契約書の専門用語を知っているだけでは、日常の相談先は分かりません。答えが部署名だけなら、どんな場面でどう連絡するかまで聞くと、入社後の動きを想像できます。

契約の説明と実際の運用が違うように感じても、短い面談情報だけで違法かどうかを断定しないでください。聞いた内容、示された文書、疑問点を整理し、雇用主へ確認します。解決しない場合は、都道府県労働局などの適切な窓口に相談するための記録になります。分類の印象で安心・不安を決めず、分からない関係を言葉にして確認しましょう。

担当工程は、最近の一件を最初から最後まで聞く

工程を確認するときは、要件定義、設計、実装、テストという単語の有無だけで比較しないようにします。同じ設計でも、既存仕様に沿った画面項目の整理と、システム全体の構成の検討では経験が違います。自分が担当したい仕事を一つ伝え、それに近い最近の案件がどう進んだかを聞くと、言葉の意味を合わせやすくなります。

例えば、「新しい機能の要望を受けてからリリースするまで、開発者はどの打合せに参加しますか」と質問します。誰が課題を整理し、実装方針を決め、受入れを確認するかを順に聞きます。各場面で今回の採用者に期待される役割も加えると、会社の一般的な工程と本人の初期業務を区別できます。

運用まで関わりたいなら、リリース後の問い合わせ、不具合調査、利用状況の確認が誰へ届くかを尋ねます。作って終わりなのか、結果を見て次の改修へつなげるのかで、経験の積み方は変わります。ただし、運用へ関わることには、緊急対応や定型作業が含まれる場合もあるため、魅力的な改善活動だけを想定せず、日常の業務も確認します。

経験の浅い人が段階的に工程を広げる場合は、最初の担当、レビューの方法、次の仕事を任せる判断を聞きます。「いずれ設計もできる」という将来像と、現時点で予定された担当は分けて記録します。到達時期が未定でも、必要な経験や判断者が分かれば、入社後の学び方を考える材料になります。

技術環境は、使えるものと変更できるものを分ける

求人の技術一覧を見るときは、会社全体で使っているもの、配属予定先で使うもの、今後導入する予定のものを区別します。新しい技術名が載っていても、今回の募集で触れるとは限りません。「最初の案件で使う言語と開発環境」「既存システムの主な制約」を聞き、現在の仕事と将来の方向性を別の欄へ記録しましょう。

技術を変更する提案ができるかを知りたい場合は、直近の変更例を尋ねます。誰が提案し、どんな検証を行い、費用や運用の影響を誰が判断したかが確認点です。提案できることと、本人が自由に導入できることは違います。承認の段階があるから悪いとは限らず、責任の範囲と必要な手続きを理解できることが重要です。

開発の道具についても、エディターや言語だけでなく、コードレビュー、テスト、リリースの流れを確認します。自動化があるという説明なら、どの処理が自動で、失敗したときに誰が対応するのかまで聞きます。ツールの数を比較するより、変更を安全に確認し、問題があれば戻せる仕事の進め方があるかを見てください。

希望する環境と違う点があっても、すぐ候補から外す前に、その制約が本人の仕事へどう影響するかを考えます。古い構成でも改善を担える仕事と、変更する機会がほとんどない仕事は同じではありません。学びたい技術の名前と、身に付けたい設計・検証・運用の能力を分けると、比較対象を狭めすぎずに済みます。

配属の決め方と、希望が合わない場合の手順を聞く

配属について確認したいのは、希望を聞いてもらえるかだけではありません。いつ候補が提示され、本人が何の情報を見て意見を伝え、最終的に誰が決めるかまで聞きます。配属先が入社後に決まる場合は、応募時点で確定している条件と、まだ調整中の条件を区別します。面接で紹介された案件を、そのまま自分の配属先と考えないことが大切です。

「希望を考慮する」という回答には、優先順位が合わなかった事例を聞いてみます。例えば、希望する技術の案件がない場合に、近い仕事を提案するのか、準備期間を設けるのか、別の場所で働く可能性があるのかです。すべての希望が通ることを求めるより、判断の前提と相談の手順を知る方が、入社後の認識の違いを減らせます。

案件が終わった後の流れも重要です。次の仕事を探す期間に何をするのか、所属チームはどうなるのか、勤務場所や勤務条件へどんな影響があるのかを確認します。この間の賃金や契約上の扱いは一般化せず、雇用条件と会社の説明を文書で照合してください。「案件が切れないから大丈夫」という見通しだけでは、もし変化が起きた場合の判断材料が不足します。

配属後に希望との違いが分かった場合は、誰に何を伝え、どのタイミングで見直すのかも質問できます。仕事内容の認識違い、通勤の負担、技術的な支援不足は、必要な相談が異なります。変更をすぐ確約できない場合でも、相談窓口と検討手順が分かるかを見ます。回答が抽象的なら、最近の対応例を聞いてみましょう。

育成とレビューは、制度名より日常の支援を見る

研修制度や勉強会の名前が多くても、日常の業務で困ったときに相談できるとは限りません。誰が最初の作業を一緒に確認するか、レビューはどの段階で行うか、質問が止まったときにどこへ相談するかを尋ねます。経験の浅い人ほど、入社直後の環境構築から小さな改修までの具体的な流れを聞くと、支援の実態を想像できます。

レビュー担当者がいる場合は、その人の業務との関係も確認します。いつでもすぐ返答があると期待するのではなく、依頼方法、通常の待ち時間、急ぎの変更の扱いが分かれば準備しやすくなります。レビューの目的が不具合の確認だけなのか、設計や保守性について学ぶ機会もあるのかを聞くと、自分の成長目標と結び付けられます。

客先や離れた拠点で働く場合は、所属会社の技術者と日常的に相談できる方法を確認します。現場の情報を社外へ出せない場合に、どこまで質問を共有できるかも関係します。単にチャットの場所があるだけでは解決できない問題もあるため、技術的な支援と労務上の相談を分けて考えます。担当者が変わったときの引継ぎも聞けると安心です。

自学を支援する費用制度は、申請条件、対象、業務時間内外の扱いを確認します。ただし制度の多さだけで職場を選ばず、実際に担当する仕事が学びたい内容に近いかを併せて見ます。研修で触れる技術と、配属後に使う技術が違う場合もあるため、研修後にどの仕事へ進んだ例があるかを尋ねると判断しやすくなります。

勤務時間・出社・緊急対応を通常時と例外時に分ける

働き方の比較では、通常の勤務時間や出社頻度に加え、繁忙期、リリース、障害対応のときに何が変わるかを聞きます。平均的な説明だけでは、生活への影響を判断しにくい場合があります。自分が対応できない曜日や時間があるなら、その条件を早めに伝え、業務の運用と両立するかを確認します。

残業の情報は、対象チームと期間を確認します。会社全体の数字と、今回の配属先の状況は同じとは限りません。直近の繁忙時にどのような作業が増え、誰が優先順位や増員を判断したかを聞くと、負荷が高くなったときの対応が見えます。数字だけを比べるのではなく、予測できる忙しさか、急な変更へどう対応するかも検討します。

リモート勤務については、自宅で働ける日数だけでなく、対象業務、利用できる場所、入社時の出社、機材の受渡し、ルール変更の可能性を確認します。客先の場所で仕事をする案件では、所属会社の制度と現場の運用を分けて聞く必要があります。自社開発でも全員が同じ条件とは限らないため、今回の募集に適用される内容を確かめましょう。

緊急時の当番がある場合は、担当範囲、連絡手段、対応を判断する人、記録と手当などの扱いを尋ねます。存在するかだけで応募を決めず、どのような頻度と条件で担当するかを確認します。制度上の説明と個別の契約条件に疑問があれば、正式な窓口へ確認してください。生活に影響する重要な条件は、口頭の印象だけで残さないようにします。

評価制度は、誰が仕事を見て何を判断するかを確かめる

給与や昇格を考える際には、働く場所と評価する人の関係が重要です。日常の仕事を見ている人、目標を決める人、最終評価を決める人が同じとは限りません。離れた場所で勤務する場合は、成果や課題が所属会社へどう伝わるかを聞きます。評価面談があるという事実だけでは、普段の仕事が十分に把握されるかは分かりません。

評価項目には、実装の完了、品質、チームへの協力、顧客との調整などが考えられますが、実際の制度は会社ごとに確認します。自分が増やしたい仕事と評価対象が一致しているかを見ると、入社後の期待を合わせやすくなります。例えば設計を担当したいのに、当面は定型作業の処理量を中心に評価する仕事なら、役割を広げる段階を質問できます。

「成果を正当に評価」という説明には、目標の決め方と、途中で業務が変わった場合の見直し方を尋ねます。本人が選べない配属や案件の都合で目標へ取り組めなくなるとき、評価をどう調整するかが分かると比較の材料になります。過去の具体例を聞く場合も、個人の給与や評価の詳細を求めず、手続きや考え方を説明してもらいましょう。

技術を深める役割と、チームを管理する役割の進み方も、希望に応じて確認します。名称だけで将来像を決めず、実際の仕事内容、求める経験、選択の機会を聞きます。年収の提示を比較するときは、固定部分、変動部分、前提条件を揃える必要があるため、働き方の分類だけから待遇の良し悪しを推測しないようにしてください。

求人票・面談の説明・正式な労働条件を突き合わせる

厚生労働省は、二〇二四年四月から募集時などの明示事項に、業務と就業場所の変更の範囲、有期労働契約の更新基準に関する事項が追加されたと案内しています。求人を読む際は、雇入れ直後に何をどこで行うかに加え、将来どこまで変更され得るかも確認してください。自分が生活上受け入れられる条件との比較に関わる部分です。 (出典:厚生労働省|募集時等に明示すべき事項の追加)

また、厚生労働省の労働条件の明示に関する説明は、契約期間、就業場所・業務、労働時間、賃金、退職などの条件を契約時に確認するための基礎になります。求人票の記載と、内定後に示された条件を見比べ、違いがあれば入社を判断する前に正式な回答を求めましょう。資料の名称だけで安心せず、対象者と適用される内容を読みます。 (出典:厚生労働省|労働条件の明示)

「勤務地は相談」「配属は状況による」といった記載は、その範囲を質問します。対象地域、決定時期、希望を伝える手順が分からなければ、通勤や転居の見通しが立ちません。確認できた説明は、担当者と日付を添えて保存します。口頭で聞いた希望に近い条件が正式な文書と違う場合は、自分で都合よく読み替えず、相違を示して確認してください。

条件に不明点があることを、その場で全部拒否する理由にする必要はありません。ただし、入社判断に必要な条件が未定のままなら、何がいつ決まり、その結果をどの段階で確認できるかを聞きます。個別の契約上の権利や紛争の判断は専門的な確認が必要になるため、重要な問題が残るときは公的な労働相談なども利用して整理しましょう。

架空の二求人を、会社の分類を隠して比べてみる

ここでは架空の求人Aと求人Bを使います。Aは自社サービスの既存機能改修で、入社直後は実装とテストが中心、設計レビューは週次、勤務先は一拠点という設定です。Bは受託した業務システムの改修で、要望整理への参加が予定され、案件ごとに勤務場所を確認する設定です。これは各業態の典型例や実態調査ではなく、比較方法を説明するための条件です。

「早く要望の整理を経験したい人」なら、Bの参加範囲を詳しく聞く理由があります。一方、「まず決まった環境で実装の基礎を固めたい人」なら、Aのレビュー体制を詳しく聞く理由があります。どちらも名称だけで選ぶことはできません。Bで誰が支援するか、Aで次の工程へ進む機会があるかなど、希望によって追加の質問が変わります。

通勤できる場所が限られる人にとっては、Bの勤務場所の変更範囲が重要です。ただし、Aも将来変更がないと決め付けず、正式な条件を確認します。仕事内容が魅力的でも、続けられない勤務条件を他の長所の点数で埋め合わせないようにします。必須条件を先に判定し、その後で希望条件の違いを比較する順序が役立ちます。

表へ記入するときは、確認済みの条件、担当者の見通し、未確認の点を区別します。採用ページに書かれた一般的な会社紹介を、今回の配属条件として転記しないでください。曖昧な欄が多い場合は、点数を付けて結論を急ぐより、判断に影響が大きい質問から回答を集めます。同じ項目を両社へ聞くと、条件を揃えて比較できます。

架空求人A・Bの比較例:未確認の条件を残す

比較項目

求人Aの設定

求人Bの設定

開発対象

自社サービスの既存機能改修

受託した業務システムの改修

最初の担当

実装・テストが中心

要望整理への参加を予定

レビュー・支援

週次の設計レビュー。日常の相談先は要確認

支援する担当者と確認頻度は要確認

勤務場所

当初は一拠点。将来の変更範囲は要確認

案件ごとに確認。変更対象地域は未確認

次に聞くこと

仕様検討へ進む機会と判断方法

参加範囲・支援体制・勤務地の決定時期

次の面談では、最初の仕事と変更時の扱いを聞く

面談へ持っていく質問は、多ければよいわけではありません。最初の担当業務、相談とレビューの相手、働く場所、変更が起きた場合の手順から、自分の応募判断に必要なものを選びます。質問の目的も添えると、相手が回答しやすくなります。例えば「設計経験を増やしたいので、入社直後に仕様を検討する機会があるか知りたい」と伝えられます。

回答が「人による」「案件による」だった場合は、今回の募集ではどう考えているかへ戻します。それでも未定なら、決定する人と時期を聞きます。分からないと回答すること自体を悪く受け取るのではなく、判断に必要な時点までに確認できるかを見ます。現場の話が必要なら、採用窓口へ担当チームと話す機会を相談する方法もあります。

面談後は、印象が新しいうちに条件表を更新します。魅力を感じた発言だけでなく、残った疑問、資料との違い、次に確認する人を書きます。入社後に期待する経験が、確定した担当なのか、条件が整ったら検討する希望なのかを分けると、過度な期待を避けられます。判断できない条件を放置せず、応募を進める前の質問へつなげてください。

自社開発、受託開発、客先常駐という言葉は、求人を探し始める入口には使えます。応募先を選ぶ段階では、その先にある具体的な仕事へ進んで比較しましょう。自分が何を担当し、誰と判断し、どう支援され、条件が変わるときに何を確認するかが分かれば、会社の分類だけに頼らず選ぶ理由を説明できるようになります。

比較するときの確認項目

  • 雇用主と実際の配属先を区別したか

  • 担当工程を最近の案件例で確認したか

  • 案件・配属の変更方法を聞いたか

  • 就業場所と業務の変更範囲を確認したか

次に進めること

気になる求人を二つ選び、会社の区分を一度隠して業務条件だけで比べてみましょう。違いが分からない欄が、面談で確認すべき質問になります。

参照先

あわせて読む

CODE SHIFT

IT・エンジニア転職の判断材料を整理するコラム。

各記事の画像はAIで作成したイメージです。特定の企業・サービス・利用者の実例を示すものではありません。

© 2026 CODE SHIFT