客先常駐(きゃくさきじょうちゅう)は、開発会社に所属したまま、契約先の企業に出向いてその現場で働く形態を指します。IT業界ではSES(システムエンジニアリングサービス)と呼ばれる準委任契約で運用されることが多く、検索では「やめとけ」「派遣と何が違う」といった働く側の疑問が上位を占めるのが実情です。この記事では読み方と契約の仕組みから入り、派遣・請負(受託開発)との違いを指揮命令権と成果責任で切り分けます。そのうえで、民法と37号告示の条文で自社の常駐体制がどちらに当たるかを点検し、偽装請負で発注者側に生じる直接雇用のみなし、アジャイル型開発で守るべき線引き、受託開発に任せる判断条件までを発注者の目線で示します。
まとめ:客先常駐(SES)と受託開発の違い・発注側の使い分けの判断軸
客先常駐は「人を送る」契約、受託開発(請負)は「成果物を仕上げる」契約です。前者はSES(準委任)が一般的で、開発会社が自社エンジニアを客先に常駐させ、指揮命令はあくまで開発会社側に残ります。後者は完成責任を負い、納品物に問題があれば契約不適合責任を問える点が決定的に異なります。働く側で語られる「やめとけ」の多くは、上流工程に関われない・スキルが偏るというキャリア面の話であり、発注側の損得とは論点が別です。
発注する立場で選ぶ基準はシンプルです。要件が固まらず自社主導で進めたい、社内に指示できる技術者がいるなら常駐(SES)で工数を借りる。仕様を渡して成果物ごと任せたい、完成の責任を負ってほしいなら受託開発に切り替える。判断を誤りやすいのは、実態は自社が指示しているのに準委任契約のままにして、偽装請負のリスクを抱える場面でしょう。
そのリスクは「注意される」程度では終わりません。偽装請負と判断されると、発注者が常駐エンジニアに対して直接雇用の労働契約を申し込んだものとみなされる制度が働きます。契約書の型と現場の運用を一致させておくことが、発注側にとっての最大の自衛策になるでしょう。常駐で回している運用保守を成果物単位で切り出したい段階なら、費用の内訳を提示する保守運用・内製化支援の相談窓口を起点にすると、常駐と受託のどちらが自社に合うかを整理しやすくなります。
客先常駐とは|常駐先で働くSES契約が成り立つ仕組みと読み方
まず言葉の意味と、なぜIT業界でこの働き方が広がったのかを押さえます。契約の型を理解すると、後半の「派遣との違い」「発注側の使い分け」がすべて同じ軸で読めるようになります。
客先常駐の意味と読み方、IT業界で常駐という働き方が広がった背景
客先常駐は「きゃくさきじょうちゅう」と読みます。開発会社に籍を置いたまま、取引先の開発現場に机を借りて働くスタイルです。システム開発は案件ごとに必要な人数と期間が大きく変動するため、発注企業が全員を正社員で抱えると、閑散期に人件費が固定費として重くのしかかります。そこで、必要な時期に必要な技術者を外部から借りる仕組みとして常駐が定着しました。SES事業者やSIerの下請け構造のなかで供給されることが多く、エンジニア個人にとっては複数の現場を渡り歩くキャリアになりやすい形態です。似た調達手段として国内外の拠点にチームを置く方式もあり、常駐との比較はオフショア開発とは(メリット・デメリットと国内受託開発との使い分け)やニアショア開発とは(国内委託が向くケース)で整理しています。
客先常駐で働くエンジニアが実感するメリットとデメリットの中身
働く側の評価は割れます。メリットは、未経験でも現場に入りやすく、実務経験を短期間で積める点、そして残業が現場の管理下で抑えられやすい点です。一方で不満として語られるのが「上流工程に関われない」「案件が変わるたびに技術がバラつき、専門性が積み上がらない」という声で、これが「やめとけ」「やばい」という検索につながっています。ただし、これらは発注側が受け取る価値の話ではなく、エンジニアのキャリア設計上の論点にとどまります。発注企業が調達手段を選ぶときは、この求職者視点の評判をそのまま持ち込まず、契約としての性質で判断してください。雇用形態そのものの仕組みは派遣社員とは(仕組み・正社員との違い・3年ルール)と読み比べると輪郭がはっきりします。
客先常駐と派遣・SES・請負(受託開発)の違いを責任範囲で整理
客先常駐は働き方の呼び名であって、契約の種類ではありません。同じ「客先に常駐する」でも、その裏にある契約が準委任(SES)か、労働者派遣か、請負かで、誰が指示を出せて誰が完成の責任を負うかが変わります。ここが発注側の判断の土台となる違いです。契約・サービスとしてのSESそのものはSESとは(発注者視点の解説)、契約類型としての中身は準委任契約とは(請負・派遣との違いと使い分け)で詳しく整理しています。
客先常駐と労働者派遣・請負を指揮命令権と成果責任で見分ける観点
三つの型は、指揮命令権(誰が作業指示を出すか)と成果責任(完成を約束するか)の二軸で見分けられます。SES(準委任)は開発会社が指示権を持ち、労務の提供に対して報酬が発生し、完成義務は負いません。労働者派遣は派遣先企業が直接指示を出せる代わりに、派遣元が厚生労働大臣の許可を受けている必要があります。請負は完成した成果物に対して報酬を払う契約で、作り方の指示は受注側に委ねられます。
| 契約の型 | 指揮命令権 | 成果責任 | 報酬の対象 |
|---|---|---|---|
| 客先常駐・SES(準委任) | 開発会社側 | 完成義務なし | 労務・工数 |
| 労働者派遣 | 派遣先企業 | 完成義務なし | 労務・工数 |
| 請負(受託開発) | 受注(開発)側 | 完成義務あり | 成果物 |
この一覧の要点は、常駐かどうかと指揮命令権は別物だという一点です。派遣だけが発注側に直接の指示権を認め、その分だけ派遣元は許可制という規制を受けます。なお「特定派遣」という言葉を目にしたら、情報の古さを疑ってください。届出制だった特定労働者派遣事業は2015年9月30日施行の改正で一般労働者派遣事業との区別ごと廃止され、経過措置も2018年9月29日で切れています(平成27年労働者派遣法改正法の概要・厚生労働省)。開発を丸ごと任せる発注の全体像はシステム開発の依頼方法と工程の解説でも整理しており、常駐で工数を借りる場合と請負で任せる場合の位置づけを対応づけられます。
準委任(SES)と請負(受託開発)で異なる完成責任と契約不適合責任
発注側にとって最大の差は、成果物に問題があったときの責任追及の可否です。請負は仕事の完成を約束する契約なので、納品物が種類または品質について契約の内容に適合しなければ、注文者は履行の追完・報酬の減額・損害賠償・契約の解除を求められます。ただし期間の縛りがあり、不適合を知った時から1年以内にその旨を通知しないと、これらの請求ができなくなります(民法637条1項)。準委任は事務の遂行そのものが債務で、善良な管理者の注意をもって作業すれば、狙った機能が完成しなくても契約違反にはなりません(民法644条)。要するに、常駐(SES)で人を借りている限り「動くものが必ず仕上がる」保証は契約上ないという理解が出発点になります。委任・委託・受託という言葉の使い分けは委託とは(委任・請負・受託との違い)で切り分けています。
民法と37号告示の条文で客先常駐が請負か派遣かを見極める判断観点
ここは既存の解説記事がほとんど踏み込まない領域です。契約書の表題が「準委任契約書」でも、実態が違えば労働者派遣と判断されます。判断の物差しは行政が公開しており、条文を開けば自社の常駐体制を自分で点検できます。
民法632条と656条が分ける仕事の完成義務と善管注意義務の境目
請負は「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約と定義されています(民法632条・e-Gov法令検索)。一方で準委任は、法律行為でない事務の委託について委任の規定を準用する形で成り立ちます(民法656条)。報酬の根拠が「結果」か「事務の処理」かが分かれ目になるわけです。ここで見落とされやすいのが、準委任にも成果に報酬をひも付ける型があるという点でしょう。委任事務の履行により得られる成果に対して報酬を支払うと約した場合は、成果の引渡しと同時に報酬を支払うと定められています(民法648条の2第1項)。IPAの情報システム・モデル取引・契約書(第二版)も、この履行割合型と成果完成型の区別を前提に条項を組み立てています。
37号告示の二つの要件で自社の常駐体制が適正な請負かを点検する
労働者派遣か請負かは、契約形式ではなく実態で判断されます。その基準が「労働者派遣事業と請負により行われる事業との区分に関する基準」、いわゆる37号告示(昭和61年労働省告示第37号・最終改正 平成24年厚生労働省告示第518号)です。第二条は、受注者が次の二つをどちらも満たす場合にだけ請負として扱うと定めています。片方でも欠ければ、契約書の表題にかかわらず労働者派遣事業を行う事業主とみなされます。
| 告示第二条の柱 | 満たすべき中身 | 常駐現場で崩れる場面 |
|---|---|---|
| 一号・労働力を自ら利用 | 遂行方法と評価の指示 | 発注者が直接作業を指示 |
| 一号ロ・労働時間の管理 | 始業終業や休日の管理 | 発注者が残業を命じる |
| 一号ハ・秩序の維持と配置 | 服務規律と配置の決定 | 発注者が要員を指名する |
| 二号・独立して処理 | 資金と法的責任を自ら負う | 専門性なく人だけ出す |
点検した結果ずれていたなら、運用を直すか契約の型を変えるかの二択になります。運用側から直すときに効くのが、指揮命令のルートを個別契約書に書き切ってしまう方法です。以下は自社の契約書へそのまま組み込める条項の骨組みで、告示第二条の一号イからハまでと二号に対応させています。
【個別契約書に書き足す指揮命令ルートの条項例】
第X条(指揮命令および管理責任者)
1 乙は、本業務に従事する乙の従業員に対する業務の遂行方法の指示、
評価、労働時間および服務規律の管理を、乙が選任する管理責任者を
通じて自ら行う。
2 甲は、乙の従業員に対して直接、作業の割付け、順序、緩急の調整
その他業務の遂行に関する指示を行わない。指示の必要が生じた場合
は、乙の管理責任者に対してこれを行う。
3 甲は、本業務に従事する特定の者を指名せず、また特定の者の就業を
拒否しない。要員の配置の決定および変更は乙が行う。
4 前各項に反する運用を認めたときは、甲および乙は速やかに是正措置
を協議し、必要に応じて契約の型を見直す。
【発注者視点】客先常駐で確保するか受託開発に任せるかの判断軸
ここからが競合記事に無い、発注する側の意思決定です。求職者向けのメリット・デメリット論とは切り離し、自社の状況で常駐(SES)と受託開発のどちらが合理的かを条件付きで言い切ります。
客先常駐(SES)で人材を確保すべき場面と任せると失敗する場面
常駐(SES)が向くのは、要件が動き続けていて、自社のリーダーが日々指示を出しながら開発を進めたい場面です。既存システムの改修や運用保守のように、優先順位が週単位で変わる作業では、工数を柔軟に足し引きできる常駐の相性が良い。逆に失敗しやすいのは、丸投げに近い形で常駐エンジニアに任せながら、成果物の完成責任まで期待してしまうケースでしょう。準委任には完成義務がないため、「言った機能が動かない」ときに責任の所在が宙に浮きます。自社に指示できる技術者がいないのに常駐で人だけ借りると、管理不全に陥り、総コストはかえって膨らみがちです。社内で回すか外に出すかの線引きは内製化のメリットとデメリットの比較も併せて見ておくと、常駐に頼る範囲を決めやすくなります。
受託開発(請負)へ切り替える判断条件と人月単価から見るコスト構造
受託開発に切り替えるべきなのは、仕様がある程度固まり、成果物ごと責任を持って仕上げてほしい段階です。この請負としての受託の意味や委託・準委任との違いは受託とは何か(受託開発の定義と契約の違い)の解説で整理しています。要件定義・設計・テストまで含めて任せられるため、社内に専任のマネージャを置けない中小企業ほど利点は大きいでしょう。コスト構造も見え方が変わります。常駐(SES)は「人月単価×人数×期間」で費用が積み上がり、稼働が延びれば青天井になりがちですが、請負は成果物に対する総額で握るため予算が読みやすい。ただし請負側は完成リスクを織り込むぶん単価を高めに設定します。費用の全体像はシステム開発費用の内訳と相場の考え方、人月という数え方そのものは工数単位の基本定義と全体像で押さえておくと、常駐の見積書と請負の総額見積もりを同じ物差しで比較できます。
客先常駐(SES)で発注側が注意する偽装請負のリスクと契約実務
常駐という形態は、契約と実態がずれると法的リスクに直結します。発注側が知らずに一線を越えると、偽装請負として指導・是正の対象になり得ます。ここは調達担当が必ず押さえるべき実務です。偽装請負そのものの4類型・罰則・契約前のチェックリストは偽装請負とは?4類型と37号告示の判断基準を解説した記事にまとめています。
指揮命令を出すと偽装請負になる境界線と発注側が守るべき線引き
偽装請負とは、契約は準委任や請負なのに、実態として発注企業が常駐エンジニアへ直接、日々の作業指示や勤怠管理を行っている状態を指します。この場合、労働者派遣法(e-Gov法令検索)や職業安定法に抵触し、是正勧告や取引停止のリスクを負います。線引きの要点は、SES(準委任)で借りている技術者への指示は、必ず開発会社側の責任者を通すという運用を守ることです。発注側の担当者が席まで行って「この画面を先に直して」と直接命じ始めた時点で、契約は準委任でも実態は派遣に近づきます。直接指示を出したいなら、最初から労働者派遣契約を結ぶのが筋であり、派遣先としての義務は労働者派遣法とは(派遣元・派遣先の義務)で確認できます。
偽装請負で発注者が直接雇用を申し込んだとみなされる制度の条件
発注側が負うリスクの本体は、行政指導ではなく労働契約申込みみなし制度です。禁止業務への従事、無許可事業主からの受入れ、期間制限違反、そして偽装請負のいずれかに当たる違法派遣を受け入れた場合、その時点で、発注者が当該労働者に対し、派遣元における労働条件と同一の労働条件を内容とする労働契約の申込みをしたものとみなされます。2015年10月1日から施行されている仕組みです。偽装請負については、労働者派遣法などの規定の適用を免れる目的で請負その他の名目の契約を結んだ場合が対象とされ、違法であることを知らず、知らなかったことに過失がなかったときは除かれます。人を借りたつもりが雇用契約の申込みをした扱いになり得るという一点で、常駐の運用管理は総務や法務まで巻き込む話になります。
客先常駐から受託開発への切り替えで社内の管理コストを下げる進め方
常駐の管理に手が回らなくなってきたら、業務の切り出しから受託開発へ移す進め方が現実的です。いきなり全体を請負にするのではなく、仕様が安定している機能から成果物単位で切り出し、そこだけを請負契約に置き換えます。
- 常駐で回している作業のうち、仕様が固まった範囲を洗い出す
- その範囲を成果物として定義し、完成基準と検収条件を文書化する
- 固まった単位から請負契約に切り替え、指揮命令を受注側に委ねる
- 要件が流動的な残りの作業だけを常駐(SES)で継続する
段階的に移すことで、社内の指示・進捗管理という見えにくいコストを減らしながら、完成責任を受注側に持たせられます。常駐と請負を対立ではなく併用の設計として捉えるのが、発注側にとって無理のない着地点になるでしょう。
アジャイル型開発を常駐体制で回すときに守る協働と指揮命令の線引き
常駐で困るのは、スクラムのように発注側と受注側が毎日会話する進め方が偽装請負に見えないか、という点でしょう。この不安に行政が直接答えた資料があり、システム開発を請け負う場合の判断が具体例つきで示されています。
疑義応答集第3集が示す協働と指揮命令の分かれ目と管理責任者の役割
厚生労働省の37号告示に関する疑義応答集(第3集)は、アジャイル型開発を題材に八つの問答を示しています。発注側と受注側の関係者が対等な関係で協働し、受注側の開発担当者が自律的に判断して開発を進めていると認められるなら、密に連携して情報共有や技術的な助言・提案を行っていても偽装請負とは判断されないという整理です。会議やチャット、プロジェクト管理ツールに双方の関係者が全員参加していても同じ扱いになります。逆に、発注側から受注側の担当者へ直接、業務の遂行方法や労働時間の指示が行われていれば偽装請負と判断されます。仕事の割付けや順序、緩急の調整を指示する必要が生じた場面では、受注者が管理責任者を選任して自ら指揮命令を行う体制を整える必要があるでしょう。開発手法そのものの違いはウォーターフォール・アジャイル・スクラムの違いで確認してください。
スキルシートの提出要求と個人の指名・就業拒否を分ける実務の境界
常駐の商談でよく問題になるのが要員の見極め方です。疑義応答集第3集は、発注者が特定の者を指名して業務に従事させたり、特定の者について就業を拒否したりする場合は、受注者の労働者の配置等の決定と変更に発注者が関与しているとして、適正な請負とは認められないとしています。一方で、受注者の技術力を判断する一環として、技術・技能レベルと経験年数を記した「スキルシート」の提出を求めること自体は、個人を特定できるものでなく、それによって指名や就業拒否ができるものでなければ、直ちに偽装請負とは判断されません。ここは第3集の適用範囲にも注意が要ります。もともとアジャイル型開発を前提に整理された問答ですが、同じ考え方が他の開発にも当てはまるかを扱うQ8が厚生労働省の疑義応答集ページで令和8年(2026年)5月25日に追加され、アジャイル型以外のシステム開発を請負業務とする場合にも当てはまると明示されました。第1集のQ10・Q11をシステム開発に適用してよいことは、令和3年5月13日付の都道府県労働局宛て事務連絡で先に示されています。
よくある質問
客先常駐(SES)と派遣・受託開発の違い、発注側の判断でつまずきやすい点を、実際の検索質問に沿って答えます。
客先常駐とはどのような働き方ですか?
開発会社に所属したまま、取引先の企業に出向いてその現場で働く形態です。IT業界ではSES(準委任契約)で運用されることが多く、指揮命令は所属する開発会社側に残ります。案件ごとに常駐先が変わることもあり、必要な時期に必要な技術者を外部から確保する仕組みとして定着しました。読み方は「きゃくさきじょうちゅう」で、契約の種類ではなく働き方の呼び名にあたります。
客先常駐と派遣・SESの違いは何ですか?
客先常駐は働き方の呼び名で、その裏の契約がSES(準委任)か労働者派遣かで性質が変わります。SESは開発会社が指示権を持ち完成義務を負いません。派遣は派遣先企業が直接指示を出せる代わりに、派遣元が厚生労働大臣の許可を受けている必要があります。同じ常駐でも、誰が作業を指示できるかが決定的に異なるわけです。なお届出制だった特定派遣は2015年の改正で廃止されており、現在の派遣事業はすべて許可制です。
客先常駐はなぜ「やめとけ」と言われるのですか?
働くエンジニア側から、上流工程に関わりにくい、現場が変わるたびに技術が偏り専門性が積み上がりにくい、という不満が出やすいためです。これはキャリア設計上の論点であり、発注企業が受け取る価値やコストの話とは別軸になります。発注側が調達手段を選ぶ際は、この評判をそのまま持ち込む必要はありません。判断すべきは、自社に指示を出せる技術者がいるかどうかという一点です。
発注側は客先常駐と受託開発のどちらを選ぶべきですか?
要件が動いていて自社主導で指示しながら進めたいなら常駐(SES)で工数を借り、仕様を渡して成果物ごと責任を持って仕上げてほしいなら受託開発(請負)を選びます。社内に指示できる技術者がいるかどうかが分かれ目で、いない場合に常駐だけで進めると管理不全に陥りやすくなります。仕様が固まった機能から順に請負へ切り出し、流動的な範囲だけ常駐で残す併用も有効な設計です。
客先常駐で偽装請負にならないために発注側は何に注意すべきですか?
SES(準委任)で借りている技術者へ、発注側が直接、日々の作業指示や勤怠管理を行わないことです。指示は必ず開発会社側の責任者を通します。要員を指名したり特定の人の就業を拒否したりする行為も、配置の決定への関与とみなされる行為です。偽装請負と判断されると発注者が直接雇用を申し込んだものとみなされる制度があるため、契約の型と現場運用を一致させることがリスク回避になります。
関連記事
- 準委任契約とは?請負・派遣との違いとシステム開発での使い分けを解説:常駐の裏にある契約類型を条文レベルで確認したいとき
- SESとは?契約形態と派遣・SIerの違いを発注者視点で解説:常駐を支えるSESという商流そのものの解説
- システム開発の費用相場は?内訳・人月単価と見積もりの妥当性を発注者視点で解説:常駐と請負のコストを内訳から比較したいときの費用ハブ
- システム開発とは?種類・工程・依頼方法までの全体像をわかりやすく解説:受託・依頼形態の全体像から常駐の位置づけを確認できる
- プロジェクト担当者が最初に押さえるべき工数単位の基本定義と全体像:SESの人月単価と請負総額を同じ物差しで比べる前提知識