システム開発の外注を検討していると、開発会社から「受託開発で」「SESで対応します」と言われ、その違いがよく分からないまま話が進んでしまうことがあります。どちらも外部の力を借りる点は同じですが、契約の性質も、責任の所在も、発注側がやるべきことも大きく異なります。
結論から言うと、受託開発は「完成した成果物」に対価を払う頼み方、SESは「エンジニアの稼働時間」に対価を払う頼み方です。作りたいものが決まっていて完成品を納めてほしいなら受託開発、自社主導で進めつつ人手を補いたいならSESが向きます。この記事では、受託開発とSESの違いを契約形態・責任・指揮命令権の観点から整理し、発注側が見落としがちな偽装請負のリスク、そしてどちらで頼むべきかの判断軸までを解説します。
この記事のポイント
- 受託開発は成果物に、SESは稼働時間に対価を払う頼み方
- 受託開発は開発会社が完成責任を負い、SESは完成義務を負わない
- SESで発注側がエンジニアに直接指示を出すと偽装請負になり得る
- 仕様が固まっているなら受託開発、柔軟に人手を足すならSESが向く
目次
受託開発とSESの違いと契約・責任
まずは、受託開発とSESが根本的に何を売り買いしているのかを整理します。ここを取り違えると、契約後に「思っていた頼み方と違う」というズレが起きます。
受託開発とSESの基本的な違い
受託開発とSESの最大の違いは、「何に対してお金を払うか」です。受託開発は、発注側が求めるシステムを開発会社が完成させ、その成果物に対して報酬を払います。一方SESは、開発会社のエンジニアが提供する労働力（稼働時間やスキル）に対して報酬を払う頼み方です。
この違いは、成果物の扱いに直結します。受託開発では、完成したシステムを納品してもらうことが目的なので、期日までに動くものが仕上がることが前提です。SESでは、エンジニアが一定期間作業に加わること自体が価値であり、必ずしも「完成品を納める」ことが目的ではありません。だからこそ、システムテストや運用保守のように、明確な完成物というより継続的な作業が中心の業務にはSESが向き、仕様が決まった開発一式を任せたいなら受託開発が向く、という住み分けになります。
発注側の視点でこの違いを言い換えると、受託開発は「完成物を買う」感覚、SESは「専門人材の時間を借りる」感覚に近いといえます。完成物を買うなら、仕様という設計図を渡して仕上がりを受け取る形になり、途中の作り方は開発会社に委ねます。時間を借りるなら、その時間を何に使うかを決めて指示する役割が自社に残ります。同じ「外注」という言葉でも、自社が担う仕事の量がまったく違う点は、受託開発とSESを比べるうえで最初に理解しておきたいところです。
契約形態の違い（請負契約と準委任契約）
受託開発とSESは、法律上の契約形態も異なります。受託開発は「請負契約」、SESは「準委任契約」で結ばれるのが一般的です。
請負契約は、仕事の完成を約束する契約です。開発会社は成果物を完成させる義務を負い、完成しなければ報酬を請求できません。納品後に不具合が見つかれば、契約不適合責任として修正対応も求められます。一方の準委任契約は、業務を誠実に遂行することを約束する契約で、成果物の完成までは約束しません。エンジニアが決められた稼働で誠実に作業すれば、成果物が未完成でも報酬は発生します。
この違いは、発注側のリスクの持ち方を変えます。受託開発は「完成」の責任を開発会社に持たせられる代わりに、要件が固まっていないと見積もりも契約も成立しにくくなります。SESは仕様が固まっていなくても柔軟に人手を確保できる代わりに、完成の責任は発注側が負う構造になります。契約形態ごとの責任範囲は、受託開発とSESのどちらで頼むかを決める土台になるので、最初に押さえておきましょう。
なお、SESと似た形態に「労働者派遣」がありますが、派遣は発注側が直接指示を出せる点で、準委任のSESとは異なります。受託開発・SES・派遣は地続きに見えて、完成責任と指示権の所在がそれぞれ違うと理解しておくと、開発会社の提案を受けたときに混乱しません。
指揮命令権と偽装請負に注意
発注側が特に気をつけたいのが、指揮命令権の違いです。受託開発（請負）でもSES（準委任）でも、現場のエンジニアに直接指示を出す権限は開発会社側にあり、発注側にはありません。発注側が「この作業を先にやって」「今日は残業して」とエンジニアへ直接指示を出すと、実態が労働者派遣とみなされ、偽装請負として法的な問題になり得ます。
これは受託開発でもSESでも共通のリスクですが、SESは発注側の職場でエンジニアが作業するケースが多く、距離が近いぶん直接指示をしてしまいがちで、より注意が必要です。人手を確保したうえで直接指示を出したいなら、労働者派遣契約という選択肢もあります。「誰が指示を出す契約なのか」を理解せずに運用すると、意図せず違法状態になりかねません。窓口を通して開発会社に依頼する、指示は開発会社のリーダーを経由する、といった運用ルールを契約時に握っておくと安心です。厚生労働省も、請負と労働者派遣の区分について労働者派遣・請負を適正に行うための取り組み（厚生労働省）で判断基準を示しています。
受託開発とSESのメリット・デメリット
発注側から見た受託開発とSESのメリット・デメリットを、並べて比較すると選びやすくなります。
| 観点 | 受託開発 | SES |
|---|---|---|
| 対価の対象 | 完成した成果物 | エンジニアの稼働時間 |
| 完成責任 | 開発会社が負う | 負わない（発注側が持つ） |
| 指示を出すのは | 開発会社 | 開発会社（直接指示は不可） |
| 向く場面 | 仕様が固まった開発一式 | 仕様が流動的・人手を補いたい |
| 費用の見え方 | 契約時に総額が決まる | 稼働に応じた月額が続く |
受託開発のメリットは、完成責任を開発会社に持たせられ、契約時に総額が固まるため予算計画を立てやすいことです。デメリットは、要件が固まっていないと契約しづらく、仕様変更に追加費用がかかりやすい点です。SESのメリットは、仕様が固まっていなくても柔軟に人手を確保でき、状況に応じて増減しやすいこと。デメリットは、完成の責任を発注側が負い、管理を怠ると成果が出ないまま費用だけがかさむ点です。受託開発という頼み方そのものをもう少し広く知りたい場合は、受託開発とは何かを発注側目線で解説した記事もあわせて確認すると全体像がつかめます。
受託開発とSESはどちらで頼むべきか
違いが分かったら、次は自社のケースでどちらを選ぶかです。判断はそれほど複雑ではなく、いくつかの問いに答えれば方向性が見えてきます。
仕様が固まっているかで選ぶ
最初の分かれ道は、作りたいものの仕様がどこまで固まっているかです。作る範囲や機能がはっきり決まっていて、「これを完成させて納めてほしい」と言える段階なら、完成責任を持ってもらえる受託開発が向きます。総額も契約時に固まるため、予算が読みやすくなります。
逆に、やりたいことは決まっているが仕様が流動的で、進めながら調整していきたい段階なら、SESで人手を確保するほうが柔軟に動けます。ただしSESは、仕様を決めて指示を組み立てる役割を発注側が担う前提です。仕様が固まっていないからSESにする、という消極的な選び方をすると、結局「何を作ればいいか決まらないまま時間だけが過ぎる」状態になりがちなので注意してください。
判断に迷うときは、「完成の期日と範囲を、いまこの場で開発会社と約束できるか」を自問してみてください。約束できるだけの材料がそろっているなら受託開発、まだ探りながら固めていく段階ならSES、という切り分けが実務的です。仕様の解像度が上がってきたタイミングで、SESから受託開発へ切り替える進め方もあります。
社内に管理・指示できる人がいるか
次の判断軸は、社内に開発を管理できる人がいるかどうかです。SESは、エンジニアの稼働を活かすために、開発の方向性を示し、優先順位を決め、進捗を管理する役割が発注側に求められます。この舵取りができる人が社内にいないと、SESは力を発揮できません。
一方、受託開発は完成物を納めてもらう頼み方なので、社内に専門人材がいなくても進められます。要件定義さえ丁寧に行えば、あとは開発会社が完成まで責任を持ちます。「社内に開発を仕切れる人がいない」なら受託開発、「仕切れる人がいて、手を動かす人手が足りないだけ」ならSES、という見方が実務的です。なお、どちらの頼み方でも発注後の関与は必要で、丸投げにすると失敗します。依頼後にどこを確認し、どう関わるかの勘所は、ベンダーコントロールのパーフェクトガイドに管理の観点がまとまっているので、発注前に目を通しておくと安心です。
コストと期間の考え方の違い
費用の見え方も、受託開発とSESで異なります。受託開発は、契約時に決めた総額を成果物に対して支払う形なので、予算の上限が読みやすいのが特徴です。ただし要件を追加すれば、その都度費用は膨らみます。SESは、エンジニアの人数と期間に応じた月額が継続的に発生する形で、稼働が続く限り費用も続きます。短期間で完成させたい開発は受託開発、期間が読みにくい継続的な開発はSES、という費用感の違いも判断材料になります。
もう一つ見落とされがちなのが、自社側の管理にかかるコストです。SESは費用が月額で見えやすい反面、エンジニアの稼働を活かすための指示出しや進捗管理に、自社の担当者の時間が継続的に取られます。受託開発はその管理を開発会社が担うため、社内の負担は要件定義と検収に集中します。表に出る金額だけを比べると安く見えても、自社の人が割く時間まで含めた総コストで見ると評価が変わることもあるので、受託開発とSESは金額と手間の両面で比較するのがおすすめです。
外注形態には、受託開発・SESのほかに、一定期間チームを確保するラボ型などもあります。頼み方全体の選択肢と、それぞれが向く場面を俯瞰したい場合は、システム開発の外注形態と判断基準を解説した記事を確認すると、受託開発とSESの位置づけがより明確になります。なお費用はあくまで一般的な考え方であり、実際の金額は要件と依頼先によって変わるため、最終判断は個別の見積もりで行ってください。
受託開発とSESのよくある質問
受託開発とSESの選び方でよく聞かれる疑問をまとめました。
- Q. 受託開発とSESは併用できますか？
- A. 併用は可能です。たとえば初期開発は受託開発で完成させ、その後の改修や運用はSESで人手を確保する、という組み合わせもよく使われます。フェーズごとに向く頼み方を選ぶとよいでしょう。
- Q. SESのエンジニアに直接指示を出してはいけないのですか？
- A. 発注側が直接指示を出すと偽装請負とみなされる恐れがあります。指示は開発会社の窓口やリーダーを通す運用にします。直接指示を出したいなら、労働者派遣契約が適切な選択肢です。
- Q. 費用が安いのはどちらですか？
- A. 一概には言えません。仕様が固まった短期開発は受託開発のほうが総額を抑えやすく、長く継続する開発はSESのほうが柔軟です。安さだけでなく、完成責任を誰が持つかまで含めて比較してください。
