※当サイトはアフィリエイトプログラム等を利用した広告を掲載しています。

受託開発と客先常駐の違いは?契約・働き方・キャリアを比較

受託開発チームと客先常駐エンジニアを契約・勤務場所・責任範囲の3軸で比較する構図 判断する

「受託開発なら安心、客先常駐なら不安」と求人票の言葉だけで判断しかけている人へ。両者は、そもそも比較している軸が違います。

受託開発は「仕事をどう引き受けるか」、客先常駐は「どこで働くか」を示す言葉です。転職先を選ぶなら、勤務場所だけでなく契約・担当工程・責任範囲まで分けて見る必要があります。

受託開発と客先常駐の違いとは?

結論からいえば、受託開発は「仕事をどう引き受けるか」、客先常駐は「どこで働くか」を表す言葉です。

そのため、「受託開発の反対が客先常駐」という理解は正確ではありません。受託した案件を顧客先で進めることもあれば、準委任などの案件をリモートで行うこともあります。

まず、両者の違いを整理します。

比較項目受託開発客先常駐
基本的な意味顧客から開発業務を引き受ける事業・案件形態顧客先などで勤務する働き方
働く場所自社、リモート、顧客先など顧客先や指定拠点が中心
契約の典型例請負、準委任など準委任、派遣、請負など契約次第
完成責任請負なら仕事の完成を負う「常駐」というだけでは決まらない
指揮命令契約形態と実態によって決まる派遣なら派遣先が指揮命令する
案件終了後自社で別案件へ移る場合がある別の常駐先へ移る場合がある
キャリアへの影響上流から納品まで経験できる可能性がある案件によって経験できる工程の差が大きい

とくに押さえておきたいのは、「受託開発=自社勤務」「客先常駐=SES」ではないことです。

客先常駐という言葉自体は、民法上の請負・準委任や、労働者派遣法上の労働者派遣のような法律上の契約区分ではありません。あくまで、所属会社とは異なる顧客側の拠点などで働いている状態を表す実務上の呼び方です。

したがって、求人票に「受託開発」と書かれていても勤務地を確認する必要があります。「客先常駐」と書かれていても、それだけでは契約関係や担当業務、指揮命令の仕組みまでは判断できません。

私は、転職先を見る最初の段階でこの定義を切り分けるべきだと考えます。「受託」「SES」「客先常駐」というラベルだけで企業を分類すると、本当に確認すべき仕事内容を見落としやすいからです。


受託開発と客先常駐では働き方・案件の進め方がどう違う?

受託開発では、顧客から依頼されたシステムやアプリケーションなどの開発を、受託企業側のプロジェクトとして進めるのが典型です。

要件定義、設計、実装、テスト、納品、保守まで一連の工程を担当する会社もあれば、特定工程だけを切り出して受託する会社もあります。

請負であれば、契約で定めた仕事を完成させるため、受託側には進捗・品質・工数を管理する力が求められます。

開発方法やチーム編成について一定の裁量を持つ企業なら、レビュー手順や設計ルール、開発環境などを社内で標準化しやすく、案件で得た知識を組織に残しやすい点も特徴です。

同じ会社のPM・PL・設計者・開発者が複数案件に関わる体制であれば、個人の経験だけではなく、設計や品質管理のノウハウを社内へ蓄積できる可能性もあります。

一方、客先常駐では所属会社とは異なる顧客のプロジェクトに入り、その現場で決められた業務を担当します。

業務内容はプログラミングだけではありません。要件整理、設計、テスト、インフラ構築、監視運用、ヘルプデスク、PMOなど、配属される案件によって大きく変わります。

そのため、客先常駐のキャリアを評価するときは「常駐している」という事実だけでは情報が足りません。

たとえば同じ3年間の客先常駐でも、要件定義や基本設計、クラウド移行、顧客折衝まで経験した人と、定型的なテスト実行だけを担当した人では、次の転職で説明できる経験が異なります。

「客先常駐を3年経験した」では、採用側から見れば具体的な能力が分かりません。「基本設計から実装、レビューまで担当した」「顧客との仕様調整を任されていた」まで分解して、初めて経験の中身が見えてきます。

逆に、受託開発であっても工程が強く分業され、担当範囲が限定されている会社なら、必ず幅広いスキルが身につくとは限りません。

つまり、キャリア形成で見るべきなのは勤務場所より、どの工程を担当し、どこまで判断を任されるのかです。

※画像はAIによるイメージ

契約・責任範囲はどう違う?請負・準委任・派遣を整理

受託開発と客先常駐を正確に理解するうえで、最も重要なのが契約形態です。

ここは企業ブログや求人票に書かれた「SES」「受託」といった表現だけで判断するより、民法と厚生労働省の資料を基準に分けて考えたほうが誤解を避けやすくなります。

まず請負について、民法第632条では、一方が「ある仕事を完成すること」を約し、相手方がその仕事の結果に対して報酬を支払う契約として規定されています。

システム開発の請負であれば、契約内容に基づいて仕事を完成させることが中心です。そのため、受託企業には納期や品質、工数を含めてプロジェクトを管理する必要が生じます。

これに対し、準委任は民法第656条に規定され、法律行為ではない事務を委託する契約について委任の規定を準用する仕組みです。

民法第644条には委任を受けた側の善管注意義務も定められています。つまり準委任は「成果物を完成させる契約ではないから何をしてもよい」という意味ではなく、契約に基づいて適切に業務を遂行することが求められます。

IT業界で「SES」と呼ばれる取引では、実務上、準委任契約が用いられるケースがよく見られます。

ただし、SESは民法や労働者派遣法に規定された契約名称ではありません。SESという看板だけを見て法的な関係を判断せず、実際の契約が請負・準委任・派遣のどれなのかを見る必要があります。

労働者派遣はさらに性質が異なります。

厚生労働省は労働者派遣について、派遣元が雇用する労働者を、派遣先の指揮命令を受けて派遣先のために働かせる仕組みとして説明しています。

ここでポイントになるのが、「誰がエンジニアへ業務上の指示を出しているのか」です。

厚生労働省の「労働者派遣・請負を適正に行うためのガイド」では、派遣と請負のどちらに該当するかは契約書の名称だけではなく、実態に即して判断されるとされています。

たとえば書面上は請負や準委任であっても、実態として注文主側が受託会社の労働者を直接指揮命令している場合、労働者派遣との区分が問題となり、いわゆる偽装請負と判断される可能性があります。

ただし、顧客側とエンジニアが会話しただけで直ちに偽装請負になる、という単純な話ではありません。

業務遂行の方法、労働時間、配置などを誰が管理しているのかを含め、厚生労働省が示す区分基準に沿って個別の実態から判断する必要があります。

したがって、「顧客先で働いている=派遣」「請負だから顧客とは直接会話してはいけない」といった理解も正確ではありません。

転職希望者が整理しておきたいのは、次の3軸です。

  • 場所:自社・顧客先・リモートのどこで仕事をするのか
  • 契約:請負・準委任・派遣など、企業間ではどの形で取引しているのか
  • 責任と指示系統:誰が仕事を管理し、誰が成果に責任を持ち、誰が指示を出すのか

この3軸で考えれば、「受託開発なのに客先常駐」という形も矛盾ではありません。

受託企業が請け負ったプロジェクトを、セキュリティや開発環境などの事情によって顧客拠点で実施するケースはあり得るからです。

反対に、自宅や自社からリモートで作業しているからといって、その企業が必ず受託開発を行っているとも限りません。勤務場所と契約形態は別々に確認する必要があります。

※画像はAIによるイメージ

受託開発と客先常駐のメリット・デメリットは?

受託開発の利点になりやすいのは、自社側でプロジェクトを管理する会社なら、開発の全体像を理解しやすいことです。

要件定義から設計、実装、テスト、納品まで担当する企業では、「与えられた作業を終わらせる」だけでなく、見積もり、進捗管理、品質管理、顧客折衝まで経験できる可能性があります。

同じ会社のメンバーで複数案件を進める体制なら、設計ルールやレビュー方法などを共有し、ノウハウを組織内へ残しやすい点も利点です。

ただし、これはあくまで条件がそろった場合です。

受託開発でも、下流工程だけを切り出して受けている会社や、慢性的に見積もりが厳しい会社なら、希望するキャリアを築きやすいとは限りません。

請負では仕事の完成が契約の中心になるため、仕様変更への対応や見積もり、納期・品質管理が不十分だと、現場の負担が大きくなる可能性もあります。

その意味で、「受託開発なら客先常駐より必ず働きやすい」という見方もできません。案件管理が適切なのか、開発工程のどこを受注しているのかまで確認する必要があります。

一方、客先常駐の利点は、複数の企業・業界・システムへ関われる可能性があることです。

金融、製造、通信、流通など異なる業界の案件を経験したり、大規模システムや自社では保有していない技術環境へ触れたりできる場合があります。

経験の浅いエンジニアにとっては、テストや運用保守から実務に入り、その後に開発・設計へ担当範囲を広げていく選択肢にもなります。

問題は、案件による振れ幅です。

扱う技術、担当工程、勤務時間、リモート可否、チーム構成、教育方法まで常駐先によって変わるため、所属会社がどのように案件を選び、社員のキャリアを管理しているかが重要になります。

とくに注意したいのは、常駐先での評価と所属会社での評価が別に存在することです。

現場で求められる役割と、所属会社が人事評価で見ている項目との間に距離が生じることがあります。

個別企業によって制度は異なるため一括りにはできませんが、常駐先で高く評価されたことが、そのまま所属会社での昇給や次の案件選択へ結びつくとは限りません。

もう一つ、商流も無視できません。

同じ「業務システム開発」「設計業務」という案件名でも、エンド企業や元請に近い立場なのか、複数企業を挟んだ立場なのかによって、顧客との距離や任される範囲が変わる場面があります。

多重下請けのSESから事業会社側へ移った人たちの話を整理していても、案件名や使用技術だけでは、実際の権限や顧客との距離を判断しにくいことが分かります。

だからこそ、求人票の「開発案件多数」「上流工程あり」という言葉だけではなく、何次請けが中心なのか、顧客と直接会話する機会があるのかまで確認する価値があります。

「上流工程あり」でも、一部の社員しか担当できないのか、入社後に段階的に任されるのかでは意味が違います。求人票に書かれた単語より、実際の配属実績を聞いたほうが判断材料として具体的です。


受託開発と客先常駐はどちらを選ぶべき?

受託開発と客先常駐を比較するとき、「どちらが上か」を決めることに私は意味がないと考えています。

転職後のキャリアを左右しやすいのは会社の分類より、商流・担当工程・案件選択・評価制度・顧客との距離だからです。

受託開発を選ぶメリットが大きくなりやすいのは、自社側が案件全体を管理し、要件定義や設計から納品まで継続して経験できる場合です。

社内にPMやPL、設計者、開発者がそろい、プロジェクトで得た知識を共有できる会社なら、技術だけでなく見積もりや顧客折衝、プロジェクト管理まで経験を広げやすくなります。

反対に、受託企業でも担当工程が固定されていたり、二次請け・三次請けの一部分だけを繰り返したりする環境なら、「受託」という言葉だけで優位とは判断できません。

客先常駐についても同じです。

大手企業の基幹システム、クラウド基盤、セキュリティ、上流設計などに関われる案件なら、次の転職でも説明しやすい経験になる可能性があります。

一方、本人の希望とは無関係に案件が決まり、長期間同じ定型作業だけを担当する会社では、在籍年数が増えてもスキルの棚卸しが難しくなることがあります。

転職時には、少なくとも次の点を確認しておきたいところです。

  • 直請け・一次請け・二次請け以降のどこが中心か
  • 要件定義・基本設計・詳細設計・実装・テストのどこを担当するか
  • 顧客と直接仕様や課題について話せるか
  • 案件変更を希望した場合の仕組みがあるか
  • 常駐時は一人なのか、自社チームで参画するのか
  • レビュー担当者や相談先が明確になっているか
  • 現場で得た経験が所属会社の評価へどう反映されるか

面接でも「どんな案件がありますか」だけではなく、「直近のエンジニアはどの工程からどの工程へ移ったか」「案件変更を希望した場合、どのような手続きになるか」まで聞くと、会社のキャリア支援を具体的に判断しやすくなります。

案件選択制を掲げている会社でも、実際に選択できる案件数や待機時の扱いは企業ごとに異なります。言葉だけではなく、制度がどう運用されているかを見ることが重要です。

経済産業省の「IT人材需給に関する調査」では、需要の伸びを年平均約2.7%、労働生産性上昇を年0.7%と置いた試算で、2030年のIT人材需給ギャップを約45万人としています。

ただし、この数字は一定の前提を置いた試算であり、「ITエンジニアならどんな経験でも市場価値が上がる」という意味ではありません。

人材不足と、自分が担当している仕事の価値は分けて考える必要があります。

「受託か客先常駐か」という看板ではなく、次の2〜3年で任される工程と責任範囲を見て転職先を決めるべきです。

需要が高まる領域へ移れる経験を積んでいるのか、それとも同じ作業の年数だけが増えているのか。ここを確認すれば、会社の分類だけを見るより具体的に自分のキャリアを判断できます。


今後のキャリアでは「勤務場所」より何を見るべきか?

受託開発と客先常駐を比べる際、「自社で働けるか」だけを最優先にするのはおすすめしません。

リモートワークの普及もあり、勤務場所そのものとプロジェクト上の立場は必ずしも一致しないからです。

自宅から仕事をしていても、担当範囲が限定されていれば上流経験が増えるとは限りません。

反対に顧客先へ常駐していても、顧客と直接課題を整理し、要件をまとめ、設計方針まで提案できるなら、技術以外の能力も磨けます。

私はSESからの脱却を、単純な「客先常駐から逃げること」だとは考えていません。

重要なのは、自分のキャリアを配属先任せにする状態から抜け、どの技術・工程・役割を積むかを判断できる状態へ移ることです。

その意味では、条件の整った受託開発には利点があります。自社で案件全体を管理していれば、開発工程を横断して経験できる可能性があるためです。

ただし、「受託」という名称そのものに価値があるわけではありません。

転職先を比較するときは、「受託か客先常駐か」の二択で終わらせず、自分が2〜3年後に説明できる経験が何になるのかまで考えたほうが合理的です。

たとえば「Javaを3年経験した」より、「顧客への要件ヒアリングから基本設計、実装、レビューまで担当した」のほうが、何を任されていたのかが明確です。

同様に、クラウド案件であってもサービス名に触れただけなのか、設計・構築・移行・運用改善まで担ったのかで経験の意味は変わります。

ここで、もう一つ見落とされやすい視点があります。それが「次の案件でも再現できる経験か」です。

特定の現場でしか通用しない独自手順を長く担当していても、転職市場でそのまま評価されるとは限りません。一方で、要件整理、設計、SQL、クラウド構築、レビュー、障害切り分けなど、別の会社や案件でも説明できる経験は職務経歴書へ落とし込みやすくなります。

転職を考えるときは、「今の仕事が嫌か」だけでなく、「今やっていることを次の会社へ持っていけるか」という視点を加えると、感情とは別の軸でキャリアを判断できます。

勤務場所ではなく、責任範囲と担当工程を具体化する。受託開発と客先常駐をキャリアの観点から比較するときは、ここまで分解して求人を見ることが重要です。


まとめ

受託開発と客先常駐は、そもそも同じ軸の言葉ではありません。

受託開発は顧客から開発業務を引き受ける事業・案件の形です。一方の客先常駐は、所属会社とは異なる顧客先などで業務を行う勤務形態を表します。

契約については、民法第632条の請負、同656条の準委任、労働者派遣法上の派遣などを分けて考える必要があります。

さらに厚生労働省が示すように、派遣と請負の区分は契約書の名称だけでなく実態から判断されます。客先常駐という勤務場所だけを見ても、契約関係や指揮命令の仕組みは判断できません。

転職では「受託」「SES」「客先常駐」というラベルだけで会社を選ばず、商流、担当工程、技術領域、顧客との距離、案件変更制度、評価制度まで確認するのが現実的です。

数年後に「どの工程を、どこまで任されていたか」を具体的に説明できる環境なのか。そこまで確認すれば、受託開発と客先常駐の違いを、自分のキャリア選択へ落とし込めます。


よくある質問

受託開発と客先常駐の一番大きな違いは何ですか?

受託開発は「顧客から仕事を引き受ける事業・案件の形」、客先常駐は「顧客先などで働く勤務形態」です。

そのため、受託開発でも顧客先へ常駐するケースはあり、両者は反対語ではありません。

客先常駐とSESは同じですか?

完全な同義語ではありません。

客先常駐は勤務場所・働き方を表す言葉で、SESはIT企業が技術支援を提供するサービス・事業を指して使われる言葉です。SES自体は法律上の契約名称ではないため、実際には請負・準委任・派遣など契約形態を確認する必要があります。

受託開発と客先常駐ではどちらが転職に有利ですか?

名称だけでは判断できません。

要件定義・設計・実装など何を担当できるのか、顧客との距離は近いのか、案件を変更できるのか、経験が社内評価へ反映されるのかまで確認したほうが、将来のキャリアとの相性を判断しやすくなります。

執筆:新海 智也

この記事を書いた人

SESや客先常駐から抜け出したい人に向けて、退職・転職の仕組みと、各サービスの中身を調べてまとめています。

新海智也をフォローする