SES契約とは？準委任との関係・派遣との違いと発注側の注意点

Webサービスやスマホアプリの開発で外部エンジニアを活用する発注企業にとって、SES契約の判断は契約名称だけでは完結しません。完成させたい成果物があるのか、変化する要件に対応しながら業務を進めたいのか、また誰が日々の業務を管理するのかを分けて考える必要があります。

この記事では、SESと準委任・請負・派遣の関係、発注側が設計すべき連絡経路、費用比較の方法を整理します。案件に合う契約・体制を選び、直接的な業務管理に近づかない受入運用を設計できるようになります。

SESは実務上の呼称です。契約名称だけでなく、契約目的、責任分担、日常の管理・連絡の運用を合わせて確認します。

01SectionSES契約とは：準委任・請負・派遣をどう整理するか

SESは、開発・保守などで技術支援を受ける取引を指す実務上の呼称として用いられることがあります。ただし、SESという名称そのものが契約類型や責任分担を決めるわけではありません。個別契約の目的、役割、指揮命令の経路、日常の運用実態を確認することが出発点です。

完成責任と業務遂行支援の違いで考える

民法第632条では、請負は仕事の完成を約し、その結果に対して報酬を支払う契約として定められています。一方、第656条の準委任は、法律行為ではない事務の委託に委任の規定を準用する契約です。開発・保守・技術調査などでは、合意した業務を継続して遂行する目的で準委任が用いられることがあります。

準委任の基本的な考え方は、準委任契約の解説も参照してください。

個別契約・発注条件で優先して決める事項

02Section派遣との違い：発注側は何を共有し、何を管理しないか

発注側は必要な事実・要望を責任者へ共有し、個人ごとの担当決定や作業配分、勤務管理は受託側の管理経路に置く設計が基本です。

派遣では、派遣元に雇用される労働者が派遣先の指揮命令を受けて就業します。請負・準委任型の体制では、受託側が業務遂行、作業配分、勤怠、評価、配置を管理できることが重要です。制度上の区分と運用上の留意点は、厚生労働省のガイドで確認できます。

技術質問・変更・障害時の連絡経路

発注側は、事業目的、仕様、制約、受入基準、障害の発生事実、優先順位の希望を共有します。これに対し、誰が対応するか、どの順番で進めるか、どのように勤務を調整するかは、受託側責任者が判断・管理する設計にします。

会話・会議・ツール利用は一律に止めない

技術者本人との会話、会議参加、チケットやチャットの利用だけで、直ちに派遣と判断されるものではありません。情報サービス取引における実務上の留意点は、情報サービス産業協会（JISA）の情報サービス産業における適正な業務委託契約運用のためのガイドライン（2016年3月）にも整理されています。

受託側責任者が、作業配分、勤怠、評価、配置を実質的に管理できることが重要です。技術者本人に連絡する場合も、責任者を同報に含める、共有チケットに記録する、定例で対応計画を確認するといった方法で、管理経路を維持します。

緊急時は例外連絡の範囲を決める

障害時には、技術者本人へ発生事実を一次連絡する必要が生じることがあります。その場合は、受託側責任者への共有先と共有期限、事後記録、通常の連絡経路へ戻す条件をあらかじめ定めます。緊急対応を理由に、個人への継続的な作業配分や勤務管理へ移行しないことが重要です。

03Section偽装請負を避けるために点検したい日常運用

請負・準委任型の体制では、契約書に責任者を置くだけでは十分ではありません。日々の朝会、チケット、チャット、勤怠、会議、権限設定で、実際に誰が業務を管理しているかを確認します。厚生労働省の区分基準では、業務遂行、評価、労働時間、休暇、配置などの管理主体が確認観点とされています。

点検したい5つの場面

棚卸しから再点検までの是正手順

04SectionSESと受託開発はどう選び分けるか

請負か準委任型かは優劣で決めるのではなく、完成条件をどこまで定義できるか、変更をどの程度見込むかで範囲ごとに整理します。

SES・準委任と受託開発・請負は、優劣ではなく案件条件で選びます。情報システム開発・保守運用の契約検討では、IPAの情報システム・モデル取引・契約書が参照資料になります。両者の比較は、受託開発とSESの違いもあわせて確認すると整理しやすくなります。

完成条件を定義できる範囲は請負を検討する

成果物、品質、納期、受入条件を発注前に比較的明確に定義でき、完成責任を契約上管理したい範囲は、請負を検討しやすい領域です。発注側には、要件と受入条件を定め、変更時の影響を確認・合意する体制が求められます。

変更を前提に継続支援を受ける範囲は準委任を検討する

要件探索、技術調査、優先順位の見直し、保守改善のように、作業内容が継続的に変わり得る範囲では準委任型の体制を検討します。発注側は優先順位や事業上の制約を示し、受託側責任者と継続的に調整します。

工程ごとに性質が違う場合は境界を分ける

05Section発注から受入れ・履行確認までの進め方

発注は、候補比較だけでなく、受入準備と開始後の確認までを一続きで設計します。仕様、プロジェクト管理、検収方法などの共通理解を形成する論点は、IPAのモデル契約見直しのポイントも参考になります。

候補比較では必須条件を先に確認する

価格比較の前に、要件を満たせない候補を除外するための条件をそろえます。

発注から更新・終了までを完了条件で進める

準委任の履行確認と請負の検収を混同しない

準委任では、業務報告、稼働実績、課題管理、会議記録、合意済みの提出物によって、契約上の業務が遂行されているかを確認します。請負では、完成物が受入条件に適合しているかを検査・検収する設計が中心です。

提出物があることだけで、契約類型は決まりません。完成物として検収する対象なのか、業務遂行を確認するための提出物なのかを、個別契約で区別します。委託先のセキュリティについては、責任分界、契約、確認資料を結び付けるIPAの実務例も参考になります。

06SectionSESの費用はどう比較するか

見積額だけで比較せず、自社で発生する受入・管理工数や環境費、交代・引継ぎ費も費用層をそろえて合算します。

SESの費用は、役割、経験、稼働率、契約期間、勤務形態、支援範囲、精算条件、受入要件によって変わります。市場相場を推定するのではなく、取得済みの見積と自社で発生する費用を同じ条件で合算して比較することが、稟議や予算化では実務的です。

契約対価以外の費用も分けて把握する

契約対価に加え、要件説明、オンボーディング、定例、レビュー、購買・法務・情報システム対応といった社内工数が生じます。端末、ID、ライセンス、VPN、教育、監査、ログ保管は初期費用と継続費用を分け、交代・引継ぎは終了時に備えた費用として別建てにします。

取得済み見積で総費用を比較する

前提を「1名・稼働率80％・4か月」とし、月額見積80万円、社内受入・管理工数は月12時間・社内工数単価5,000円、環境実費は初期2万円と月額5,000円、交代・引継ぎ予備費8万円と置くと、総費用は356万円です。

比較前提をそろえて費用差の理由を残す

07Section発注前に確認したい項目

発注前の確認では、契約目的、受託側責任者を中心とした運用、総費用と終了条件を一つの判断としてそろえます。未確定事項を残す場合は、決定者と確認先を定め、契約・受入準備へ持ち越さないことが重要です。

SES契約を検討するときは、まず依頼目的を「完成させる範囲」と「継続して支援を受ける範囲」に分けます。そのうえで、受託側責任者が実質的に業務管理できる連絡設計、契約類型に合った履行確認、条件を固定した総費用比較までを一貫して整えることが、発注後の認識違いを抑える基礎になります。

開発体制や依頼先を比較したい場合

要件の確定度、変更の頻度、必要な役割、受入体制を整理したうえで、Webアプリ・SaaS開発の対応会社を比較できます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発の会社を探す