SESと受託開発・準委任の違いは？発注者が知るべき区別を解説

システム開発を外注しようと調べると、「SES」「受託開発」「準委任」「請負」「派遣」といった言葉が次々に出てきて、違いが分からず戸惑う方は多いはずです。これらは単なる呼び方の差ではなく、誰が何に責任を負い、成果物を受け取れるのか、指示を出せるのかが根本から異なります。ここを取り違えると、「動くシステムがほしかったのに人手だけ来た」「指示を出したら偽装請負を指摘された」といった事故につながります。この記事では、発注者の立場で知っておくべき区別を、契約・責任・成果物の観点で表を交えて整理し、どちらが自社に向くかまでを分かりやすく解説します。

受託開発・SES・派遣の違いを一覧で比較

まず全体像をつかみましょう。同じ「開発の外注」でも、性質はまったく異なります。

観点	受託開発（請負）	SES（準委任）	派遣
提供されるもの	完成した成果物	技術者の作業（労働）	技術者の労働
完成の責任	ある（会社が負う）	ない（善管注意義務のみ）	ない
指揮命令	受注側（開発会社）	受注側（開発会社）	発注側（派遣先）
働く場所	開発会社側が多い	客先常駐が多い	派遣先に常駐
費用の形	案件ごとの総額	技術者ごとの月額単価	時間・月額単価
成果物の権利	契約で発注者に渡せる	原則は作業提供のみ	作業提供のみ
向くケース	完成物がほしい	人手・技術力を足したい	人手を足したい

大づかみに言えば、**受託開発は「モノ（完成品）を買う」、SESと派遣は「ヒト（労働力）を借りる」**という違いです。そして「借りる」二つのうち、指示を誰が出すかで準委任（受注側が指示）と派遣（発注側が指示）が分かれます。この三点さえ押さえれば、大半の混乱は解けます。

判断に迷ったら、次の問いに答えてみてください。

1. ほしいのは完成したシステムか、それとも人手か：動く成果物がほしいなら受託、社内チームに人を足したいならSESや派遣。
2. 社内に開発を指示・管理できる人がいるか：いないなら受託が安全。いるならSESで人手を借りる選択も現実的。
3. 成果物の権利を自社で持ちたいか：持ちたいなら、権利譲渡を契約できる受託開発が向きます。

受託開発（請負）とは

受託開発は、開発会社が「仕事の完成」を約束し、動くシステムを成果物として納品する契約形態です。法律上は請負契約にあたり、完成責任と、納品後に不具合が見つかったときに直す責任（契約不適合責任）を開発会社が負います。発注者は完成物を受け取ることに集中でき、開発中の細かな作業指示や進行管理は開発会社側が担います。

受託開発で任せられることの例は次の通りです。

• 要件のヒアリングと整理：やりたいことを聞き取り、必要な機能へ落とし込む
• 設計・開発・テスト：画面や機能の設計から実装、動作確認まで一貫して行う
• 成果物の納品：動くシステムと、契約によってはソースコードや仕様書を渡す
• 納品後の修正対応：不具合の是正など、契約範囲の手当て

受託が向くのは、「社内に開発を指揮できる人がいない」「とにかく完成した業務システムがほしい」というケースです。中小企業が在庫管理や受発注、顧客管理などの業務システムを新しく作る場面は、ほぼここに該当します。費用は案件ごとの総額で提示されるのが一般的で、開発の流れは発注から納品までの流れ、費用の考え方はシステム開発の費用相場も参考になります。

受託開発で発注者が負う手間が小さいのは、進行管理と品質管理を開発会社側が引き受けるからです。発注者の主な役割は、やりたいことを伝え、要所で内容を確認し、完成物を検収することに絞られます。日々の作業指示や技術者の勤怠を管理する必要はありません。「本業が忙しく、システム開発に手をかけられない」中小企業ほど、この負担の小ささが効いてきます。要件をどこまで固めるべきかは要件定義とはも参考にしてください。

SES（客先常駐・準委任）とは

SESは「システム・エンジニアリング・サービス」の略で、技術者が発注者の職場に常駐し、労働（作業時間）を提供する契約です。法律上は準委任契約にあたり、開発会社が約束するのは「専門家として業務を遂行すること」であって、成果物の完成そのものではありません。技術者は誠実に作業する義務（善管注意義務）を負いますが、「システムが完成しなかった＝契約違反」とはならないのが受託との決定的な差です。

SESの費用は、技術者一人あたりの月額単価で決まるのが一般的です。単価は技術者の経験やスキルで幅がありますが、目安として次のようなイメージです（あくまで幅のある相場感です）。

技術者の目安	月額単価の目安
経験の浅いエンジニア	40〜60万円ほど
中堅エンジニア	60〜90万円ほど
上級・専門性の高い技術者	90〜120万円ほど

SESが向くのは、自社にすでに開発チームや管理者がいて、一時的に人手や特定の技術力を足したいケースです。逆に、社内に開発を管理できる人がいない状態でSESだけを頼むと、「来てもらった技術者に何を作らせるか」を自社で設計・指示できず、成果につながりにくくなります。

SESでもう一つ意識したいのが、費用が「使った期間ぶんだけ積み上がる」性質です。受託が総額固定なのに対し、SESは技術者が常駐している間ずっと月額が発生します。開発が長引けばそのぶん費用も膨らむため、「いつまでに何を仕上げるか」を自社で設計・管理できないと、コストが読みにくくなります。この管理を自社で担えるかどうかが、SESを使いこなせるかの分かれ目です。

派遣との違い（指揮命令は誰が出すか）

SESと派遣は「技術者が客先で働く」点が似ているため混同されがちですが、決定的に違うのは指揮命令を誰が出すかです。

観点	SES（準委任）	派遣
指示を出す人	受注側（開発会社）	発注側（派遣先）
勤怠・労務の管理	受注側	発注側
必要な許可	不要	労働者派遣事業の許可が必要
契約の性質	業務の遂行	労働力の提供

派遣では、派遣先（発注者）が技術者へ直接「これをやってください」と指示を出せます。一方SESでは、発注者は技術者へ直接業務指示を出してはいけません。指示は開発会社を通じて行うのが原則です。ここを守らず、SESなのに発注者が直接細かく指示・管理してしまうと、次に述べる偽装請負の問題が生じます。

なお、派遣は労働者派遣事業の許可を持つ会社しか行えません。この許可なしに「常駐で技術者を貸し、発注者が指示する」形をとると、それ自体が違法な労働者供給になり得ます。発注者としては、常駐型で人手を借りる際に「これは準委任（SES）なのか派遣なのか」を契約書で確認し、指示を出す相手を取り違えないことが大切です。呼び方が似ていても、守るべきルールはまったく違います。

契約・責任・成果物の考え方

三つの形態を、発注者がもっとも気にすべき「責任」と「成果物」の軸で整理します。

観点	受託開発（請負）	SES（準委任）	派遣
約束するもの	仕事の完成	業務の遂行	労働力の提供
完成しなかったら	契約違反になりうる	直ちには違反でない	完成は約束外
成果物の権利	契約で発注者へ譲渡可	原則は労働の提供のみ	労働の提供のみ
発注者の管理負担	小さい	大きい	大きい

ここで重要なのは、「完成した動くシステム」と「その権利」を確実に手に入れたいなら、受託開発（請負）を選ぶ必要があるという点です。SESや派遣は労働力の提供が本質なので、「作ってもらったものが自社の資産として残るか」は契約次第で曖昧になりがちです。成果物の権利や契約条項の確認ポイントは開発の契約で確認すべきことにまとめています。

もう一つ、発注者の管理負担の差も見逃せません。受託は完成物を受け取ることに集中できるため負担が小さい一方、SESや派遣は「技術者に何をどう作らせるか」を発注者側で設計・指示し続ける必要があり、負担が大きくなります。つまり同じ「外注」でも、受託は任せて待てる形、SES・派遣は自社が主体となって動かす形だと理解しておくと、契約後のギャップを避けられます。「頼んだのに思ったように進まない」という不満の多くは、この形態の取り違えから生まれます。

発注者にとってどちらが向くか

結論から言えば、選び方はシンプルです。

• 完成したシステム（モノ）がほしい → 受託開発
• 人手・技術力（ヒト）を足したい → SESまたは派遣

業種やシーン別に、向く形態を具体化すると次のようになります。

• 中小の小売・卸で在庫や受発注を仕組み化したい：完成物がほしいので受託。関連は在庫管理システム、受発注システム。
• サービス業で顧客情報や予約を一元管理したい：受託で業務システムを新規開発。顧客管理システムの自作も参考に。
• 自社に開発チームがあり、繁忙期だけ人を増やしたい：SESで人手を足す。
• 特定技術（データ分析など）の専門家を一定期間借りたい：SESや派遣で技術力を補う。

導入効果の目安として、受託で業務システムを入れると、Excelや手作業で回していた集計・転記が自動化され、月に数十時間かかっていた作業が数時間に減る、入力ミスや二重登録が大幅に減る、といった改善が見込めます。効果は業務内容や規模で変わりますが、「人手を増やす」より「仕組みで回す」ほうが継続的なコスト削減につながりやすいのが一般的です。

ここで意識したいのが、SESと受託の費用構造の違いです。SESは人手を借り続ける限り月額が発生し続けますが、受託で作った仕組みは一度完成すれば、その後は人を増やさずに業務を回せます。目先の人手不足をSESで埋めるか、仕組みを受託で作って恒久的に解決するか——短期の穴埋めなら前者、根本的な効率化なら後者、という使い分けで考えると判断しやすくなります。

SESで気をつけること（偽装請負）

SESでもっとも注意すべきなのが偽装請負です。これは、契約上はSES（準委任）や請負なのに、実態として発注者が常駐技術者へ直接指揮命令している状態を指します。形は業務委託でも、中身が「労働者を使っている」状態になっているため、労働者派遣法などに違反するおそれがあります。

偽装請負と見なされやすい典型を挙げます。

• 発注者が常駐技術者へ直接、日々の作業指示を出している
• 発注者が技術者の勤怠（出退勤・残業）を管理している
• 開発会社の責任者が現場におらず、指揮系統が発注者に一本化されている
• 技術者が発注者の一員のように扱われ、業務の切り分けが曖昧

これらを避けるには、SESでは指示を開発会社の責任者経由で行い、勤怠や労務管理も開発会社側に委ねるのが原則です。「自社で直接指示して人を動かしたい」なら、それは準委任ではなく派遣（または雇用）で対応すべき領域だ、と理解しておきましょう。契約形態と実態を一致させることが、発注者側のリスク回避になります。

中小が業務システムを作るなら基本は受託

ここまでを踏まえると、社内に開発チームや管理者がいない中小企業が新しく業務システムを作る場合、**基本の選択は受託開発（請負）**になります。理由は明快で、SESや派遣は「自社で技術者を指揮・管理できること」が前提だからです。管理できる人がいないままSESを頼むと、来てもらった技術者に的確な指示が出せず、成果につながりにくいうえ、偽装請負のリスクまで背負うことになります。

依頼前のチェックリストとして、次を確認しておきましょう。

• ほしいのは「完成物」か「人手」か、社内で明確になっている
• 完成物がほしいなら、請負（受託）契約になっているか
• 成果物（ソースコード等）の権利を自社で受け取れるか
• 「どこまでで完成か」と追加費用の扱いが書面で決まっているか
• SESを選ぶ場合、社内に指示・管理できる担当者がいるか

一般化した例で見てみましょう（実在の企業ではなく、よくある型です）。

例：受託のつもりがSESだったケース 「システムを作ってほしい」と依頼したのに、実際には技術者が月額単価で常駐する契約になっていた。完成の責任は開発会社になく、指示は自社で出す必要があったが社内に分かる人がおらず、半年経っても動くものが仕上がらなかった。契約形態を最初に確認していれば防げた失敗です。

例：受託で総額を固めて発注したケース 別の会社では、受託（請負）で着手前に総額と「どこまでで完成か」を確定。追加費用が出ない形で開発し、完成した動くシステムとソースコードの権利を受け取れた。社内に開発者がいなくても、完成物を安心して受け取れた典型です。内製と外注の比較は内製と外注どっち？も参考になります。

一律料金の受託という選択

「受託がよいのは分かったが、費用が読めないのが不安」という声はよくあります。受託開発は本来、案件ごとの見積りで総額が変わり、追加要望のたびに費用が積み上がって総額が膨らみやすいからです。この不安に応える形が、総額を最初に固定する一律料金の受託です。

D-oneAppは受託開発（請負）として体制を持ちつつ、料金は一律100万円（大規模なプロプランは一律200万円）。着手前に総額が確定し、追加費用はなし、完成したソースコードの権利もお渡しします。だから、SESのように「人手だけ来て完成しない」心配も、受託にありがちな「総額が読めない」不安もなく、動く業務システムを固定額で手に入れられます。100万円でどこまで作れるかは100万円でできること、業務システムの費用感は業務システムの費用相場もあわせてどうぞ。

まとめ

受託開発（請負）は「完成物（モノ）」を、SES・派遣は「労働力（ヒト）」を提供する契約で、責任の対象がそもそも違います。準委任（SES）は業務の遂行を、請負（受託）は仕事の完成を約束し、成果物と権利を確実に得たいなら受託が基本です。社内に開発を管理できる人がいない中小企業なら、なおさら受託が安全で、SESでは偽装請負にも注意が必要です。契約形態と自社の目的が一致しているかを、発注前に必ず確認しましょう。迷ったら無料相談で、あなたの目的に合った進め方を整理しましょう。