開発リソースが足りなくなったとき、選択肢として出てくるのが「SES」です。 SES（システムエンジニアリングサービス）は、準委任契約でエンジニアが開発現場に参画し、技術支援を行うサービスを指します。 ただ、請負や派遣との違いが分かりにくく、「結局何をどこまでお願いできるのか」が曖昧なまま検討が進みがちです。
この記事では、SES事業を営むCoconutWorksが、契約形態の違いをできるだけ平易に整理し、 契約書で確認しておきたい項目、発注側が指揮命令の面で気をつけたい点までまとめます。 なお、契約形態の一般的な整理であり、個別の契約に関する法的助言ではありません。 実際の契約内容については、必要に応じて専門家にご確認ください。
結論: 準委任・請負・派遣の違い
| 比較項目 | 準委任（SES） | 請負 | 派遣 |
|---|---|---|---|
| 報酬の対象 | 業務の遂行（働いた時間・専門性） | 成果物の完成 | 労働力の提供 |
| 成果物の完成責任 | なし（善良な管理者として業務を遂行する義務） | あり | なし |
| エンジニアへの指揮命令 | 受託側（ベンダー） | 受託側（ベンダー） | 派遣先（発注側） |
| 向いているケース | 仕様が変わりうる開発・継続的な保守改修・技術支援 | 要件が明確で成果物単位で発注できる開発 | 発注側の管理下で直接指示して働いてほしい場合 |
ひとことで言えば、「完成品を買う」のが請負、「専門家の働きを買う」のが準委任（SES）、 「自社の指揮下で働く人を借りる」のが派遣です。 SESでは発注側がエンジニアに直接指揮命令する形は取らないため、 業務の依頼やすり合わせは受託側の窓口を通して行う体制が基本になります。
「業務委託」と準委任・請負の関係
混乱しやすいのが「業務委託」という言葉です。実は業務委託は法律上の契約類型の名前ではなく、外部に仕事を頼むことを指す実務上の総称です。 民法上は、成果物の完成を約束する「請負」と、業務の遂行を引き受ける「委任・準委任」に分かれます。
さらに委任と準委任は、委託する事務の性質で区別されます。契約の締結を代理するような法律行為を任せるのが委任、 それ以外の事務を任せるのが準委任です。システム開発の作業や技術支援は後者にあたるため、SESでは準委任が使われます。
実務上ここが重要なのは、「業務委託契約書」という表題でも、中身が請負なのか準委任なのかは読んでみないと分からないからです。 完成責任の有無が変わるため、表題ではなく条文で確認する必要があります。 なお2020年に施行された改正民法では、準委任にも成果の完成に対して報酬を支払う型が明文化されました。 ただしSESの実務で中心となるのは、稼働に対して支払う従来型のほうです。
SES（準委任）が向いているケース
- 仕様が固まりきらない開発 — 作りながら要件が変わる開発は、成果物を最初に確定させる請負より、状況に合わせて柔軟に動ける準委任が向いています。
- 継続的な保守・改修 — 「終わり」が明確でない改善サイクルや運用保守は、期間と稼働率で契約する準委任と相性が良い領域です。
- 繁忙期・欠員の増強 — メンバーの離脱や一時的な負荷増に対して、必要な期間だけ体制を厚くする使い方ができます。
- 社内にない技術の補完 — レガシー移行やBI構築など、社内に知見のない領域を専門性で補う参画の仕方です。
逆に、要件が明確で成果物単位で発注できるなら請負（受託開発）の方が向いています。 どちらで頼むべきかの判断軸はSESと受託開発、どちらで頼むかで詳しく整理しています。弊社はどちらの形も対応しているため、案件の性質に合わせて契約形態からご提案できます。
契約書で確認しておきたい項目
準委任は成果物ではなく業務の遂行を対象にするぶん、「何を、どこまで、どう進めるか」を契約書で具体化しておくことが後のトラブルを防ぎます。 金額以外に目を通しておきたいのは次の項目です。
| 確認する項目 | なぜ確認するか | 見るポイント |
|---|---|---|
| 業務の範囲 | 何を担当するのかが曖昧だと、後から役割が広がっても線引きができない | 担当する工程・作業内容が具体的に書かれているか |
| 稼働時間と精算 | 想定より稼働が増減したときの扱いを決めておかないと揉めやすい | 稼働時間の下限・上限と、超過／不足時の精算方法 |
| 報告の方法と頻度 | 準委任は成果物ではなく遂行を評価するため、状況共有が品質の担保になる | 誰に・どの頻度で・どんな形で報告するか |
| 指揮命令と窓口 | 発注側が直接指示する形になると契約形態と実態がずれる | 業務の依頼を受託側の誰を通して行うか |
| 再委託の可否 | 実際に誰が作業するのかが変わる可能性がある | 再委託を認めるか、認める場合の事前承諾の要否 |
| 秘密保持 | 開発では顧客情報やソースコードなど機微な情報に触れる | 対象範囲と、契約終了後も義務が続く期間 |
| 契約期間と中途解約 | 継続前提でも、終了したいときの手順を決めておく必要がある | 更新の仕方と、解約の予告期間・精算の扱い |
すべてを厳密に詰める必要はありませんが、業務の範囲・稼働と精算・解約の予告期間の3つは、 認識がずれると影響が大きいため、締結前に口頭でも確認しておくと安心です。 長く続く前提の契約ほど、終わり方を先に決めておくほど揉めにくくなります。
指揮命令の線引き — 発注側が気をつけたいこと
SESで発注側が最も気にしておきたいのが、指揮命令の扱いです。 準委任ではエンジニアへの業務指示は受託側が行うため、発注側が直接、労務管理にあたる指示を出すと、契約形態と実態がずれてしまいます。 実態が派遣と変わらない状態は、いわゆる偽装請負として問題になり得ます。
とはいえ、現場で一切話してはいけないという意味ではありません。 仕様のすり合わせや技術的な相談といった、業務を進めるためのやりとりは通常行われます。 線引きの目安は、勤怠の管理・作業の割り当て・残業や休暇の可否といった、 人の働き方そのものを決める指示を発注側が直接行わないことです。
実務的には、受託側の窓口を決めておき、依頼や優先順位の調整はそこを通す形にすると自然に整理できます。 判断に迷う場面が出てきたら、その都度窓口に確認しながら進めるのが安全です。
発注前に確認しておきたい3つのポイント
- ①スキルの中身 — 「Java歴◯年」だけでは実務力は分かりません。スキルシートで、どの工程（要件定義〜運用）を、どんな役割で担当してきたかまで確認するのがおすすめです。
- ②稼働条件 — 稼働率（週数日〜フルタイム）、期間、常駐かリモートか。途中で条件変更が必要になったときの調整のしやすさも、長い付き合いでは効いてきます。
- ③コミュニケーション体制 — 進捗や課題をどう共有するか、窓口は誰か。準委任は「任せて終わり」ではなく、すり合わせの質が成果を左右します。
契約前の面談で何を確認すべきかはSESの面談で発注側が確認すべきことでさらに掘り下げています。
CoconutWorksのSES・技術支援
弊社は、要件定義から設計・開発・テスト・運用保守まで一貫して対応できる体制で、 C#/.NET・Java・PHP（Laravel）・React/TypeScriptなどのWeb系技術、Power BIを用いたBI開発、 VB6等レガシーシステムのマイグレーションに対応しています。 倉庫管理システム（WMS）の構築支援や、1年半以上継続しているBIシステム開発支援などの実績があります（守秘義務により社名は非公開）。 常駐・ハイブリッド・フルリモートいずれも対応し、SES会社・SIer様との協業（パートナー提携）も歓迎しています。
よくある質問
まとめ
SES（準委任）は「専門家の働きを買う」契約で、仕様が動く開発・継続的な保守・体制の増強に向いています。 「業務委託」は総称にすぎないため、契約書では請負なのか準委任なのかを条文で確かめ、 業務の範囲・稼働と精算・解約の予告期間を押さえておくと安心です。 あわせて、指揮命令は受託側の窓口を通す体制にしておくと、契約形態と実態のずれを防げます。 「この案件はSESと請負どちらが合うか」という段階のご相談も歓迎です。SES事業・技術支援サービスのページもあわせてご覧ください。
