「SES で人を出せます」と「受託で一括でお受けします」を比べる前に
開発を外に出すことが決まり、ある会社からは「SES で技術者を出せます」、別の会社からは「受託で一括でお受けします」と提案を受けることがあります。どちらも開発を外部に任せる話に聞こえますが、契約の中身は大きく違います。上司や購買部門から「何が違うの、うちはどっちがいいの」と聞かれて、説明に詰まる人も少なくありません。
すでに SES の技術者が自社に常駐している場合は、別の不安もあります。社員と同じようにタスクを振ってよいのか、「偽装請負」という言葉を見かけて気になった、という不安です。
本記事では、受託開発と SES の違いを「完成の責任を誰が持つか」「作業の指示を誰が出すか」の 2 点で整理します。根拠には民法の条文と、厚生労働省が公開している 37 号告示・疑義応答集を使い、発注側の社員がしてよいこと・いけないことを行動ごとに示します。最後に、上司にそのまま回せる形で、選び方の 5 つの質問をまとめます。契約書の条項の確かめ方は AI 開発の契約は準委任と請負どちらが正解か で扱っています。
注意
本記事は公開されている法令と行政の資料をもとにした一般的な整理であり、法律相談の代わりにはなりません。労働者派遣と請負のどちらに当たるかは、個別の実態で判断されます。自社の契約や運用に当てはめて判断するときは、契約書と実際の運用を持って弁護士か、管轄の都道府県労働局に相談してください。
結論 — 違いは「完成の責任」と「指示を出す人」。社内に判断する人がいるかで選ぶ
上司への説明に使えるよう、結論を 3 行にまとめます。
- 受託開発は「完成物を納めてもらう」取引で、完成の責任は受注側が持ちます。SES は「技術者の作業に対価を払う」取引で、完成の責任は受注側にありません
- どちらの契約でも、受注側の技術者に作業の指示を出すのは受注側の会社です。発注側の社員が直接指示すると、偽装請負と判断されます
- 何を作るかと優先順位を決める人が社内にいて、手だけが足りないなら SES、そうでなければ受託開発が候補になります。工程ごとに契約を分ける選び方もあります
以下で、それぞれの根拠を順に説明します。
受託開発と SES の違い
受託開発とは
受託開発は、システムやアプリの開発を外部の会社に任せ、完成したものを納めてもらう取引です。契約は請負が多く、受注側は仕事を完成させる義務を負い、発注者は完成した結果に対して報酬を払います。
ただし、受託開発がすべて請負とは限りません。要件定義の工程や、継続して改善していく開発は、準委任で切り出すことがあります。「受託開発 = 請負」と覚えると、手元の契約書と食い違うことがあります。
SES とは
SES (システムエンジニアリングサービス) は、技術者の作業に対して対価を払う取引を指す業界用語です。法令上の定義はありません。e-Gov 法令検索で「システムエンジニアリングサービス」を語句検索しても、該当する法令は見つかりません (2026 年 10 月 3 日に確認)。
多くの SES は準委任で結ばれます。一方で、SES の名前で労働者派遣の契約を結ぶ会社もあります。SES という言葉だけでは契約の中身が決まらないため、提案を受けたら、契約書が準委任なのか派遣なのかを必ず確かめてください。
比較表で見る違い
受託開発で多い請負と、SES で多い準委任を並べると次のとおりです。
| 観点 | 受託開発 (請負が多い) | SES (準委任が多い) |
|---|---|---|
| 完成の責任 | 受注側が負う | 受注側は負わない (注意して作業する義務は負う) |
| 報酬の対象 | 完成した仕事の結果 | 作業の遂行 (成果に払う形もある) |
| 作業の指示を出す人 | 受注側の会社 | 受注側の会社 |
| 何を作るかを決める人 | 契約時に双方で合意する (変更は契約の変更) | 発注側に残る |
| 作業場所 | 受注側・発注側の事務所のどちらもありうる | 受注側・発注側の事務所のどちらもありうる |
| 費用の決まり方 | 総額の見積もり | 単価 × 人数 × 期間 |
| 要件の変更 | 追加の見積もりと契約の変更になりやすい | 優先順位を入れ替えやすいが、期間が延びた分だけ費用が増える |
| 途中でやめるとき | 完成前なら、発注者は損害を賠償していつでも解除できる | 各当事者がいつでも解除できる (時期によっては損害賠償) |
| 向く場面 | 要件が固まっていて、進行も任せたい | 社内に判断する人がいて、手が足りない |
表で見落とされやすいのは「作業の指示を出す人」の行です。SES でも、技術者に指示を出すのは発注側ではありません。ほかの解説記事には、SES を技術者の派遣と説明したり、受託開発では常駐しないと書いたりしているものもありますが、どちらも正確ではありません。作業場所では区別できず、決め手になるのは完成の義務と指揮命令の関係です。
派遣・ラボ型開発との違い
労働者派遣は、派遣元に雇われた人が、派遣先の指揮命令を受けて働く形です (労働者派遣法 2 条 1 号)。派遣先は作業の進め方を直接指示できますが、派遣元は厚生労働大臣の許可を受ける必要があり (同法 5 条)、許可を持たない会社から派遣を受けることは禁じられています (同法 24 条の 2)。技術者に社員と同じように直接指示を出したいなら、選ぶべきは準委任の SES ではなく、許可を持つ会社との派遣契約です。
ラボ型開発は、一定期間、特定のチームを確保して開発を進める形で、チーム単位の準委任で結ぶことが多いとされます。SES との違いは、個々の技術者ではなくチームとして体制を組む点にあります。費用の組み立て方は ラボ型開発・チーム貸しの見積構造と使いどころ で扱っています。
民法で見る請負と準委任
比較表の根拠を、民法の条文で確かめます。条文は e-Gov 法令検索の民法 で読めます。
| 論点 | 請負 | 準委任 |
|---|---|---|
| 契約の中身 | 仕事の完成を約束し、その結果に報酬を払う (632 条) | 法律行為でない事務を委ね、委任の規定を準用する (656 条) |
| 受注側の義務 | 仕事を完成させる | 善良な管理者の注意をもって処理する (644 条) |
| 成果に払う形 | 前提として完成した結果に払う | 成果に払うと約束し、引渡しが必要なら引渡しと同時に払う (648 条の 2) |
| 途中で解除するとき | 完成前なら、注文者はいつでも損害を賠償して解除できる (641 条) | 各当事者がいつでも解除できる。相手に不利な時期の解除などは損害賠償が要る (651 条) |
| 途中までの作業の報酬 | 切り分けられる部分で注文者が利益を受けるなら、その割合に応じて払う (634 条) | すでに履行した割合に応じて払う (648 条 3 項) |
発注者にとっての違いは、次の 2 点に集約されます。
1 つ目は、完成しなかったときの扱いです。請負なら、完成させる義務は受注側にあります。準委任では、受注側は注意して作業する義務を負いますが、完成は約束していません。SES で開発が予定どおりに終わらなかったとき、完成していないことだけを理由に支払いを止めることは、契約に特約がない限り難しくなります。
2 つ目は、やめ方です。請負では、完成前なら発注者からいつでも解除できますが、損害の賠償が前提になります。準委任は双方からいつでも解除できるため、受注側から契約を終えられることもあります。実際の解約の予告期間や精算の方法は契約書で決まるので、知的財産・再委託・解約の条項は 準委任と請負の比較記事の条項チェックリスト で確かめてください。
SES の技術者に指示を出すときの線引きと偽装請負
契約の名前ではなく実態で判断される
労働者派遣と請負のどちらに当たるかは、労働者派遣事業と請負により行われる事業との区分に関する基準 (昭和 61 年労働省告示第 37 号。以下、37 号告示) で判断します。37 号告示の第 2 条 1 号は、受注側が自分の技術者に対して次の管理を自ら行っていることを、請負と認められる条件に挙げています。
- 業務の遂行方法の指示と、業務の評価 (イ)
- 始業・終業の時刻、休憩、休日、休暇、残業や休日労働の指示と管理 (ロ。単なる把握は除く)
- 服務規律の指示と、配置の決定・変更 (ハ)
この基準は準委任にも当てはまります。厚生労働省の 37 号告示に関する疑義応答集 (第 3 集) の A1 は、準委任で契約していても、実態として発注者と受注側の技術者の間に指揮命令の関係があれば、契約の形式を問わず労働者派遣事業に当たるとしています。同じ A1 の注記は、請負などの形式を取りながら発注者が受注側の技術者に直接具体的な指揮命令をしている状態を「いわゆる偽装請負」と呼び、労働者派遣法に違反するとしています。
第 3 集はアジャイル型開発を題材にしていますが、2026 年 5 月 25 日に追加された A8 で、Q1〜Q7 の考え方はアジャイル以外のシステム開発を請負業務とする場合にも当てはまると明記されました (疑義応答集の一覧ページ)。
発注側の社員がしてよいこと・いけないこと
疑義応答集 (第 3 集・第 2 集) と、厚生労働省の 労働者派遣・請負を適正に行うためのガイド の Q&A をもとに、発注側の社員の行動ごとに整理します。表の「第 3 集」「第 2 集」は疑義応答集、「ガイド」はガイドの Q&A 第 1 集を指します。
| 発注側の社員の行動 | 偽装請負との関係 | 該当する箇所 |
|---|---|---|
| 何を作るか、どれを先に作るかを説明する | それだけでは該当しない | 第 3 集 A4 |
| 開発に必要な業務の情報を提供する | それだけでは該当しない | 第 3 集 A4、第 2 集 問 1 |
| 技術的な議論・助言・提案を対等に行う | それだけでは該当しない | 第 3 集 A5 |
| 双方が参加する会議・チャット・プロジェクト管理ツールで共有する | それだけでは該当しない | 第 3 集 A6、第 2 集 問 9・10 |
| 受注側の会社に、作り直しや作業工程の見直しを求める | それだけでは該当しない | ガイド Q2 |
| 仕様の変更を受注側の責任者に伝える | それだけでは該当しない | ガイド Q11 |
| 業務に関係のない日常の会話をする | それだけでは該当しない | ガイド Q1 |
| 個人を特定できないスキルシートで、会社としての技術の水準を確かめる | それだけでは該当しない | 第 3 集 A7 |
| 職務経歴書の提出や事前の面談を求める | 避ける | 第 2 集 問 13 |
| 作業の進め方・順序・割り振り・急ぎの調整を技術者に直接指示する | 該当する | 第 3 集 A3、37 号告示 イ |
| 技術者に直接、作り直しや仕様の変更を指示する | 該当する | ガイド Q2・Q11 |
| 始業・終業・休憩・休日・残業を指示して管理する | 該当する | 37 号告示 ロ |
| 技術者個人の査定 (勤惰点検・出来高の査定) を発注側で行う | 該当する | 37 号告示 イ |
| 特定の人を指名する、特定の人の就業を断る、交代を求める | 該当する | 第 3 集 A7、37 号告示 ハ |
「それだけでは該当しない」の行は、発注側と受注側が対等な関係で協働し、受注側の技術者が自律的に判断して作業している限り、という前提つきです。同じ会議やチャットでも、発言の中身が技術者への作業の指示になっていれば、偽装請負と判断されます (第 3 集 A4〜A6)。
第 2 集の会議とメールの例は、受注側の責任者の判断や了解のもとで技術者が同席する、または cc で受け取る場合です。技術者に直接返信を求めると、指示と判断されることがあります。
職務経歴書や事前面談は配置の決定に影響するため、労働者派遣事業などと判断されることがあります。特に、その結果として特定の人を指名したり、特定の人の就業を断ったりすれば、配置に関与していると判断されます (疑義応答集 (第 2 集) 問 13)。
ガイドの Q&A 第 1 集に収録された疑義応答集の Q10・Q11 の考え方は、厚生労働省の 事務連絡 (令和 3 年 5 月 13 日) で、システム開発を請負業務とする場合にも当てはまるとされています。仕様の軽微な変更が日常的に出る開発ほど、変更を技術者に直接伝えたくなる場面が増えるため、伝える先を受注側の責任者に揃えておくことが大切です。
FIXIT同じ部屋で働いてるなら、社員と同じように頼んでもいいんじゃないの？
Shiori整理すると、発注側が決めるのは何を作るかと優先順位までです。進め方の指示は受注側が出します。
FIXITじゃあ、急ぎの修正が出たときはどうするの？
Shiori受注側の責任者に優先順位の変更として伝えます。誰がいつ手を付けるかは、責任者が決めます。
面談・スキルシート・個人の指名
SES の商談では、技術者との面談やスキルシートの提出を求められることがよくあります。ここは発注者が判断を誤りやすいところです。
疑義応答集 (第 2 集) 問 13 は、発注者が技術者の職務経歴書を求めたり事前に面談したりすると、一般に技術者の配置の決定に影響するため、労働者派遣事業などと判断されることがある、としています。特に、その結果として特定の人を指名したり、特定の人の就業を断ったりすれば、受注側の配置に発注者が関与していると判断されます。
一方で、第 3 集 A7 は、個人を特定できないスキルシートで受注側の技術の水準を確かめることは、それだけで直ちに偽装請負とは判断されないとしています。技術力を確かめたいなら、人を選ぶのではなく、受注側の会社がどの水準の技術者を揃えられるかを確かめる、という考え方にします。入館の手続きのために、従事する予定の人の氏名を事前に出してもらうことも、受注側が配置を決めている限り、それだけでは問題になりません。この点は疑義応答集 (第 2 集) 問 12 が扱っています。
偽装請負と判断されたら発注者に何が起きるか
偽装請負は、受注側だけの問題ではありません。労働者派遣法には、派遣を受ける側の責任を定めた規定があります。
労働者派遣法 40 条の 6 第 1 項 5 号は、派遣法などの適用を免れる目的で、請負その他労働者派遣以外の名目で契約を結び、派遣契約で定めるべき事項を定めずに労働者派遣の役務の提供を受けた場合を挙げています。この場合、発注者はその時点で、その技術者に対して、その時点と同じ労働条件で労働契約の申込みをしたものとみなされます。この申込みは、その行為が終わった日から 1 年が経つまで撤回できません (同条 2 項)。
ただし、該当することを知らず、かつ知らなかったことに過失がなかったときは、この規定は適用されません (同条 1 項ただし書)。「免れる目的」があったかどうかも含めて、適用されるかは個別の事情で判断されます。本記事では、どの場合に適用されるかを断定しません。判断に迷う状態が続いているなら、運用を見直すとともに、冒頭の Callout のとおり専門家に相談してください。
偽装請負を避ける体制の決め方
疑義応答集 (第 3 集) A2 は、偽装請負を避けるために、発注側と受注側の役割・権限・開発の進め方を事前に決めて合意しておくことを挙げています。A3 は、受注側が管理責任者を置いていても、発注側が技術者に直接指示すれば偽装請負になるとしています。管理責任者を置くだけでは足りず、実際の指示の流れが問われる、ということです。
契約の前に、次の 4 点を決めておくと運用がぶれにくくなります。
- 受注側の責任者を 1 人決め、作業の割り振り・順序・急ぎの調整はその人が行う
- 発注側から伝えるのは、要件・優先順位・受け入れの基準に限る
- 仕様の変更や作り直しの依頼は、受注側の責任者に伝える
- 勤怠や残業の管理は受注側が行い、発注側は入退館などの把握にとどめる
どちらを選ぶか — 判断の 5 つの質問
ほかの解説記事の多くは、完成品がある業務は受託、ない業務 (テスト・保守) は SES という基準で分けています。ただ、テストも成果物を定義すれば請負にできますし、開発でも要件が途中で変わるなら準委任のほうが合います。完成品の有無だけでは決まりません。社内で判断するときは、次の 5 つの質問に答えてみてください。
| 質問 | 「はい」なら | 「いいえ」なら |
|---|---|---|
| 1. 何を作るか、優先順位をどうするかを決める人が社内にいるか | SES も候補 | 受託開発が候補 |
| 2. 作るものの要件が、契約の時点で固まっているか | 受託開発が候補 | SES も候補 |
| 3. 一時的に人手を足したいだけか | SES が候補 | 受託開発が候補 |
| 4. 開発のノウハウを社内に残したいか | SES も候補 (内製化支援も検討) | 受託開発が候補 |
| 5. 予算を総額で固定したいか | 受託開発が候補 | SES も候補 |
最初の質問がもっとも重要です。SES では完成の責任が受注側にないため、何を作るか、どこで妥協するかの判断は発注側に残ります。社内にその判断を担う人がいないまま SES で人を入れると、作業の時間だけが積み上がり、完成に向けた判断を誰もしていない体制になりがちです。
FIXIT人を足せば、そのぶん早く終わるんじゃないの？
Shiori人を足しても、何を作るかを決める人がいなければ早くは終わりません。SES の多くは完成を約束しない準委任です。
FIXITえっ、じゃあ社内に決める人がいないと進まないってこと？
Shiori分かれ目はそこです。決める人がいなければ、完成の責任ごと受託開発で任せるほうが合います。
受託開発が合うケース
社内に専任の PM がいない、作るものの要件が固まっている、予算を総額で固定したい、という場合は受託開発が合います。完成の責任と進行の管理を受注側に任せられるため、発注側は仕様の確認と受け入れに集中できます。
デメリットは 2 つあります。要件を変えるたびに追加の見積もりと契約の変更が要ること、そして開発のノウハウが社内に残りにくいことです。後者は、ソースコードや設計書の権利と引き渡しを契約で決めておくことで一部を補えます。確かめる項目は システム開発の著作権は誰のものか にまとめています。
SES が合うケース
社内に何を作るかを決める人がいて、手だけが足りない場合は SES が合います。優先順位を入れ替えやすく、必要な期間だけ技術者を確保できます。
デメリットは、完成に向けた判断が社内に残ることです。また、社内のシステムや情報に触れる人が増えるため、秘密保持の契約とアクセス権限の範囲を先に決めておく必要があります。これは契約形態を問わず必要です。ここまで見てきた指揮命令の線引きも、日々の運用で守り続けなければなりません。
工程ごとに契約を分ける
請負と準委任のどちらか一方に決める必要はありません。要件定義は準委任で進め、要件が固まった実装は請負にする、というように工程ごとに契約を分ける形もあります。IPA の 情報システム・モデル取引・契約書 (アジャイル開発版) は、機能の追加・変更や優先順位の変更に柔軟に対応するアジャイル開発について、準委任契約を前提にしています。
外部の会社と組みながら、開発の進め方そのものを社内に移していきたい場合は、内製化支援の進め方 も選択肢になります。外注の全体の流れは Web システム開発の依頼の判断ガイド で扱っています。
費用の比べ方
受託開発の見積もりは総額で、SES は単価・人数・期間の掛け算で出てきます。形が違うので、金額をそのまま並べても比べられません。次の 4 つを揃えてから比べます。
- 範囲。受託開発の見積もりに入っている設計・テスト・リリース作業が、SES の期間の中でも行われる前提になっているかを確かめます
- 期間。SES は期間が延びればそのまま費用が増えます。要件が途中で変わる前提なら、延びる可能性も見込みます
- 発注側の管理の工数。SES では、何を作るかの判断と進行の確認を社内の誰かが担います。その人の時間も費用に含めます
- リリース後の保守。どちらの形でも、保守を別の契約にするのか、誰が担うのかで総額が変わります
SES の単価の相場は、公的な統計で確かめられる数字が見当たらないため、本記事では金額を書きません。受託開発の見積書の内訳と妥当性の確かめ方は システム開発の見積もり完全ガイド で、チーム単位の準委任の費用の組み立ては前述のラボ型の記事で扱っています。
上司に回すときは 1 枚にまとめる
発注者の隣で説明役を担う技術者に向けて、社内の説明資料に転記しやすい形でまとめます。1 枚に入れるのは次の 4 つです。
- 結論の 3 行 (本記事の冒頭のとおり)
- 比較表 (完成の責任・報酬の対象・指示を出す人・費用の決まり方・やめ方)
- 判断の 5 つの質問と、自社の答え
- 偽装請負を避ける体制 (受注側の責任者・発注側が伝える範囲・変更の伝え方・勤怠の管理)
技術の話に詳しくない相手に説明するときは、「完成を約束してもらうか、作業の時間を買うか」の違いだと伝えると通じやすくなります。そのうえで「時間を買う場合でも、社員と同じように指示はできない」と添えれば、後から運用で問題になる点まで共有できます。
候補の会社を 3〜5 社に絞る段階であれば、業務システムの受託開発の比較ガイド で、発注先のタイプごとの強み・弱みと面談で確かめる項目を扱っています。発注前に押さえる要件整理・費用感・進め方は、AI 駆動開発 発注ガイド にもまとめています。
FIXIT の運用 — 契約の形を工程ごとに決める
FIXIT は AI 駆動開発のクリエイティブスタジオとして、プロダクト開発を請負と準委任のどちらでもお引き受けしています。MVP のように作るものが明確な工程は請負、要件が固まりきらない探索の工程や継続的な改善は準委任と、局面で使い分けるのが標準です。1 つのプロジェクトの中で、前半を請負、後半を準委任にする形も取ります。
開発の途中では、何を作るか、どれを先に作るかを週次のデモの場で発注者の皆さまとすり合わせます。どの会社に頼む場合でも、受注側の責任者を窓口にして作業の指示の流れを 1 本にする体制をおすすめします。契約の形を決める前のご相談では、要件がどこまで固まっているか、社内で判断を担う方がいるかを伺ったうえで、工程ごとの契約の分け方をご提案します。詳しくは AI 駆動開発 のページをご覧ください。
契約書の法的な解釈は弁護士の領域なので、私たちが代わりに判断することはありません。担当するのは、工程と体制の組み立てです。
まとめ
受託開発と SES の違いは、完成の責任を誰が持つかと、作業の指示を誰が出すかの 2 点で整理できます。受託開発では完成の責任を受注側が持ち、SES では受注側は持ちません。そして、どちらの契約でも、受注側の技術者に指示を出すのは受注側の会社です。SES は法令上の用語ではないので、名前ではなく契約書の種類を確かめ、発注側の社員の行動を表の線引きに合わせます。
次の一歩は 1 つです。判断の 5 つの質問のうち、最初の「何を作るかと優先順位を決める人が社内にいるか」に、具体的な名前で答えてみてください。名前が挙がるなら SES も候補に入り、挙がらないなら受託開発で完成の責任ごと任せる形が候補になります。
自社の場合にどちらが合うか、工程ごとにどう分けるかを相談したい場合は、お問い合わせ からご連絡ください。