受託開発とは｜SES・派遣との違いを契約前の5項目で判断

受託開発とは、自社で必要なシステムやアプリの開発業務を、外部の会社やチームへ委託する進め方の総称です。ただし、「受託開発」という名称だけでは、契約上の完成責任や仕事の進め方まで決まりません。請負契約、準委任契約、両者を工程ごとに分けた契約などがあり、契約書と実際の運用を確認する必要があります。

SESも同じです。業界で使われるサービス名であり、民法上の契約類型そのものではありません。「受託開発だから納品まで全て任せられる」「SESだから発注側が担当者へ直接指示できる」と考えると、契約と現場の実態が食い違うおそれがあります。

発注者が契約前に見るのは、呼び方よりも、成果物と完成条件、受託側が負う責任、指示と意思決定の経路、仕様変更の手続、開発後に引き継ぐものです。この5項目をそろえると、自社が外へ任せたい仕事と、社内に残す判断を分けられます。

受託開発・SES・派遣は、同じ軸では比べられない

受託開発は「システム開発を外部へ委託する」という取引の呼び方です。SESは、技術者の専門的な業務遂行を提供するサービスを指す言葉として使われます。派遣は、派遣先が派遣労働者へ指揮命令することを前提に、労働者派遣法の規律を受ける仕組みです。

三つを並べるときの比較軸は、契約と現場で誰が何を決めるかです。

厚生労働省は、労働者派遣では派遣先の指揮命令を受けて働くと説明しています。一方、請負か派遣かは契約の名前だけではなく、実態に即して判断されます。請負や準委任として委託した会社の担当者へ、発注側が日々の作業方法や配置を直接指示している場合は、契約書の表題だけで整理できません（厚生労働省「労働者派遣・請負を適正に行うためのガイド」）。

発注側が仕様や優先順位を決めることと、受託会社の個々の担当者へ直接指揮命令することも分けます。前者はプロジェクトの意思決定です。後者は仕事の実施方法に関わるため、受託側の責任者を通す運用になっているかを確認します。

請負と準委任では、責任を置く場所が違う

システム開発の外注では、請負と準委任が代表的な契約類型です。民法は、請負を仕事の完成とその結果への報酬を約する契約として定めています。法律行為ではない事務の委託には、委任の規定を準用する準委任があります（e-Gov法令検索「民法」）。

実際の契約では、条文上の分類だけでなく、成果物、完成の定義、検収、契約不適合への対応、報酬の計算、途中終了、知的財産権、データ、秘密情報などを具体化します。IPAの「情報システム・モデル取引・契約書」第二版も、請負契約の契約不適合責任、請負・準委任の報酬請求、複数契約の関係、プロジェクトマネジメント義務とユーザー側の協力義務を主要な論点に挙げています（IPA「情報システム・モデル取引・契約書（第二版）」）。

「請負なら発注者は何もしなくてよい」という意味ではありません。業務要件や受入条件を決めるには、発注者側の情報と判断が必要です。逆に、準委任でも成果物や報告物を契約で定められます。違いは、何を契約上の中心に置き、どの責任を誰が負うかです。

アジャイル開発では、仕様変更を前提に契約を組み立てる

MVPや新規事業の開発では、利用者の反応を見て優先順位を変えることがあります。初回に全仕様を固定しにくい案件を、完成条件が確定した一括請負として扱うと、変更のたびに契約範囲と見積もりの調整が必要になります。

IPAのアジャイル開発版モデル契約は、ベンダーが専門家として業務を遂行することに対価を払う準委任を前提としています。あらかじめ特定した成果物の完成に対価を払う請負とは、契約の中心が異なります。開発対象、初期計画、完了基準、品質基準、初期の範囲を関係者で確認するチェックリストも公開されています（IPA「情報システム・モデル取引・契約書（アジャイル開発版）」）。

準委任を選べば曖昧なままでよいわけではありません。少なくとも次を決めます。

• 一回の開発期間で扱う業務と優先順位
• 発注側で優先順位を決める責任者
• 受託側で作業を管理する責任者
• 完了したと判断する品質基準
• 進捗、課題、変更、テスト結果を残す方法
• 次の期間を継続・変更・終了する判断日

不確実な部分は、調査、試作、初回リリースへ分けられます。確定した機能は請負、調査や要件整理は準委任というように、工程ごとに個別契約を組み合わせる方法もあります。契約名を一つに統一するより、各工程の目的と責任に合っているかを見ます。

契約前の5項目で、頼み方を判断する

受託開発かSESかを先に選ぶと、手段から話が始まります。発注側が必要としているのは、完成したシステムなのか、調査と設計の支援なのか、社内チームに不足する専門業務なのか。以下の5項目から頼み方を決めます。

1. 委託対象と完成条件を一文で書けるか

「顧客管理システムを作る」だけでは、委託対象を特定できません。誰が使い、どの業務を始点から終点まで扱い、初回に何ができれば受け入れるのかを書きます。

完成条件を事前に特定できるなら、請負で検収する範囲を作りやすくなります。現行業務の調査から必要で、試作を見なければ要件を決められないなら、調査・要件整理と実装を分けるほうが責任を置きやすくなります。

2. 完成責任と業務遂行責任を分けたか

完成責任を求める範囲では、納品物と受入条件、不具合や契約不適合が見つかった場合の対応を確認します。業務遂行を求める範囲では、担当する業務、必要な専門性、報告、善管注意義務、精算や途中終了の条件を確認します。

「開発支援一式」のような記載だけでは、完成を約束しているのか、一定期間の業務を提供するのか分かりません。見積書、提案書、契約書で同じ範囲を指しているかを照合します。

3. 指示と意思決定の経路を決めたか

発注側には、業務上の目的、優先順位、予算、受入の判断があります。受託側には、担当者への作業指示、配置、技術的な進め方の管理があります。

発注者と受託会社の窓口を決め、依頼と回答を記録します。常駐の有無だけで判断せず、個々の担当者が誰の指揮命令を受けるのか、契約と実態が一致しているかを確認してください。判断が難しい場合は、労務・法務の専門家へ相談します。

4. 変更を誰が、いつ、いくらで承認するか

システム開発では、要件の追加だけが変更ではありません。既存データの欠損、外部APIの制約、セキュリティ要件、利用部門の追加も、費用と日程へ影響します。

変更の申請者、影響の調査方法、見積もり、承認者、着手条件を決めます。準委任で優先順位を入れ替える場合も、期間と予算の上限、持ち越す作業、次回判断日を記録します。変更手続がなければ、総額の差が仕様差なのか追加請求なのかを後から説明できません。

5. 開発後に何を引き継ぐか

納品物はプログラムだけではありません。ソースコード、設計資料、テスト結果、クラウドや外部サービスのアカウント、データ、監視、バックアップ、障害対応、ライセンス、知的財産権を確認します。

受託会社しか本番環境へ入れない状態や、退任した担当者の個人アカウントに資産が残る状態は避けます。発注者名義にするアカウント、受託側へ付与する権限、契約終了時の削除と返却を、開発開始前に決めておくと引き継ぎを検証できます。

受託開発が向く案件は、任せる単位を切り出せる

受託開発は、外部へ任せる業務と、発注側が決める業務を分けられる案件に向きます。自社に開発者がいない場合でも、目的、利用者、優先順位、受入判断の責任者は必要です。

例えば、次の条件がそろうと相談を始めやすくなります。

• 手作業や表計算から切り出したい業務がある
• 初回に扱う利用者と業務を限定できる
• 現行データと外部サービスを開示できる
• 社内で優先順位と受入を決める人がいる
• 公開後の運用担当と変更の窓口を決められる

一方、発注側に日々の技術判断ができるチームがあり、不足する専門業務を一定期間補いたい場合は、業務遂行を中心とした契約が候補になります。その場合も、SESという名称だけで決めず、受託側の責任者、指示経路、成果物、報告、精算条件を確認します。

cotomuの受託開発は、MVP・プロトタイプ、小規模な業務システム、既存サービスへのAI機能組み込みを対象とし、要件整理から公開条件までを案件ごとに確認します。常駐SESとしての人員提供や、他社が開発したシステムの保守だけの引き継ぎは対象外です。

発注先へ聞く10の質問

初回相談や提案比較では、次の質問を同じ順序で聞くと回答の差を確認できます。

1. 今回の契約は請負、準委任、または工程別の組み合わせですか
2. 契約期間内に完成を約束する成果物は何ですか
3. 納品物ごとの受入条件と検収期間はどう決めますか
4. 要件、優先順位、技術、公開を決める責任者は誰ですか
5. 受託側の担当者への指示は、どの責任者を通しますか
6. 仕様変更の影響を誰が調べ、費用と日程を誰が承認しますか
7. 見積もりに含まれない調査、移行、運用は何ですか
8. 再委託する業務と、再委託先を管理する責任はどうなりますか
9. ソースコード、アカウント、データ、設計・テスト資料は誰に帰属し、どう引き継ぎますか
10. 契約を途中で終了する場合、報酬、作業中の成果、データ、権限をどう扱いますか

総額を比べる前に、質問への回答が見積書と契約書へ反映されているかを確認します。費用を左右する機能、権限、外部連携、移行、品質、運用の見方は、システム開発の費用相場｜種類別・規模別に発注予算を考えるで整理しています。

呼び方より、責任を確認できる頼み方を選ぶ

受託開発、SES、派遣という言葉だけでは、自社に合う頼み方を決められません。まず、完成させてほしい仕事と、専門家に遂行してほしい業務を分けます。次に、発注側に残す意思決定と、受託側が管理する作業を分けます。

契約前にそろえるのは、委託対象と完成条件、責任、指示経路、変更手続、引き継ぎです。この5項目が具体的なら、請負か準委任か、工程を分けるかを発注先と話せます。具体的でなければ、契約名を決める前に調査と要件整理の範囲を切り出すべきです。

契約と労務上の扱いは個別事情で変わります。この記事は一般的な確認事項を示すもので、法的助言ではありません。実際の契約書、指揮命令、再委託、知的財産権、データの扱いは、弁護士や社会保険労務士などの専門家へ確認してください。

参考資料

• e-Gov法令検索「民法」（2026年7月30日確認）
• IPA「情報システム・モデル取引・契約書（第二版）」（2026年7月30日確認）
• IPA「情報システム・モデル取引・契約書（アジャイル開発版）」（2026年7月30日確認）
• 厚生労働省「労働者派遣・請負を適正に行うためのガイド」（2026年7月30日確認）

執筆・編集：株式会社adding 編集部

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る