システム開発の受託（受託開発）とは｜SES・派遣・ラボ型との違いと相場が決まる構造

最初に結論を書きます。受託開発とは、開発会社が「決められた成果物を完成させること」に責任を負う形の外注です。発注側が「システムを作ってほしい」と考えたとき、頭の中にあるのはほぼ間違いなくこの形です。

ところが実務では、ここに大きな落とし穴があります。「受託開発」は営業上の呼び名であって、法律上の契約類型ではないということです。実際に交わす契約書は「請負」かもしれないし、「準委任」かもしれないし、実態はSES（技術者の労働力提供）に近いかもしれません。そして、完成に責任を持つのか・持たないのかは、営業担当者の説明ではなく契約書の条文で決まります。

「受託開発をお願いしたつもりだったのに、契約書は準委任で、システムが完成しないまま毎月の請求だけが続いた」——これは、初めて外注する会社が最も踏みやすい失敗パターンの一つです。本記事では、受託開発の実装側であるGXOが、発注者が契約前に知っておくべき契約形態の違い、契約書での見抜き方、そして相場が決まる構造を解説します。

受託・SES・派遣・ラボ型の違い（比較表）

システム開発の外注には、大きく4つの形があります(受託開発は契約類型で2つに分かれるため、次の表では5行に分けています)。呼び名は業界慣行なので会社によって揺れますが、発注者が押さえるべき軸は「何に対してお金を払うのか」「完成の責任を誰が持つのか」「誰がエンジニアに指示を出すのか」の3点です。

この表で重要なのは、「完成責任あり」は請負型の受託開発だけだという点です。SES・派遣・ラボ型・準委任は、いずれも「時間や労務の提供」に対価を払う構造であり、成果物が完成しなくても支払い義務は原則発生します(後述する成果報酬型の準委任だけは例外です)。

なお、労働者派遣について厚生労働省は、派遣元事業主が自己の雇用する労働者を「派遣先の指揮命令を受けて」労働に従事させるものと整理しています。逆に言えば、SESや請負の契約で発注者が現場のエンジニアに直接指示を出すと、契約の名前が何であれ実態は派遣と判断されうる——これが後述する偽装請負の問題です。

そもそも外注すべきか、内製と比べてどう判断するかという手前の論点は、システム開発を外注するメリットと判断軸の整理で扱っています。本記事は「外注する」と決めた後の、契約形態の選び方に軸足を置きます。

請負と準委任の違い——民法上の定義から

受託開発の契約書は、ほぼすべて民法上の「請負」か「準委任」のどちらか（または工程ごとの組み合わせ）です。e-Gov法令検索で条文を確認すると、両者の違いは明確です。

請負（民法632条）は、「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約です。ポイントは2つあります。報酬の対象が「仕事の結果」であること、そして受注者が「完成」を約束することです。完成しなければ、原則として報酬は発生しません。

準委任（民法656条・643条）は、法律行為でない事務の委託です。受注者が約束するのは「業務を善良な管理者の注意をもって遂行すること」(民法644条・656条による準用)であり、完成ではありません。報酬は履行に対して発生し、民法648条3項では、委任が中途で終了した場合でも「既にした履行の割合に応じて」報酬を請求できると定められています。つまり準委任では、システムが完成していなくても、稼働した分の支払い義務が原則生じます。

なお2020年施行の改正民法では、準委任にも「成果に対して報酬を支払う」型（民法648条の2、いわゆる成果報酬型準委任）が明文化されました。IPA（情報処理推進機構）が公開する「情報システム・モデル取引・契約書」第二版でも、この成果報酬型準委任の位置づけや、中途解除時の報酬請求権の扱いが改正民法対応の論点として整理されています。準委任だから必ず時間払い、とは限らなくなった点は知っておく価値があります。

完成しなかったとき・欠陥があったときの違い

発注者にとっての実質的な違いは、トラブル時に表れます。

• 請負で完成しなかった場合: 報酬の全額請求は原則できません。ただし民法634条により、完成前に解除された場合などは、既にできた部分が可分で発注者に利益があるなら、その割合に応じた報酬請求が認められます。「途中解約すれば1円も払わなくていい」わけではない点に注意してください。また民法641条により、発注者は完成前ならいつでも解除できますが、損害賠償が必要です。
• 納品物に欠陥（契約不適合）があった場合: 改正民法では「瑕疵担保責任」が「契約不適合責任」に再構成され、引き渡された目的物が種類・品質において契約の内容に適合しない場合、発注者は履行の追完（修補）請求・報酬減額請求・損害賠償請求・解除ができます（民法562条〜564条・559条による有償契約への準用）。IPAのモデル契約第二版でも、報酬減額請求権が救済手段に追加された点が改正対応として明記されています。
• ただし期間制限があります: 民法637条により、発注者が不適合を知った時から1年以内に受注者へ通知しないと、これらの権利は原則行使できません（受注者が悪意・重過失の場合を除く）。さらに契約書で「検収後○か月に限る」と短縮されているケースが実務では多く、ここは契約書で必ず確認すべき条項です。
• 発注者側の原因なら守られない: 民法636条により、発注者が支給した材料や発注者の指図によって生じた不適合については、原則として受注者の責任を問えません(ただし受注者がその不適当を知りながら告げなかった場合は別です。民法636条ただし書)。要件を曖昧なまま指示した結果の不具合は、発注者側のリスクになりうるということです。

工程別の使い分け——全部請負が正解ではない

「完成責任があるなら全工程請負にすればいい」と考えたくなりますが、実務はそう単純ではありません。IPAの「情報システム・モデル取引・契約書」は、ユーザ企業とITベンダの取引構造を透明化するため、各開発段階で双方が担うべき責務を整理し、契約書のひな型を提供するという思想で作られています。開発をひとかたまりの契約にせず、工程ごとに性質に合った契約を結ぶ、という考え方です。

実務上の典型的な使い分けはこうなります。

• 要件定義・企画: 準委任が向く工程です。何を作るかを一緒に決める段階では「完成」の定義がまだ存在せず、請負には馴染まないためです(IPAのモデル契約でも要件定義工程は準委任が想定されています)。ここを無理に請負にすると、受注者は自分が完成保証できる範囲に要件を狭めるインセンティブを持ちます。
• 設計・実装・テスト: 要件が固まっていれば請負が向きます。成果物と検収基準を明確に定義できるからです。
• 保守・運用・改善: 業務が継続的で「完成」がないため、準委任（または成果報酬型準委任）が自然です。

つまり発注者が見るべきは「請負か準委任か」の二者択一ではなく、「この工程にこの契約類型は合理的か」です。要件定義から丸ごと一括請負の見積もりが出てきたら、むしろ「要件が曖昧なまま金額を固定して大丈夫か」を疑うべきですし、実装工程まで全部準委任なら「完成責任を誰も負わない構造になっていないか」を疑うべきです。

「受託のつもりがSESだった」——契約書のどこで見抜くか

初回発注の失敗談として最も多い型が、これです。営業段階では「弊社が責任を持って開発します」と聞いていたのに、実際の契約は月額×人数の準委任で、半年経ってもシステムは完成せず、しかし請求は毎月満額——契約上は受注者に完成義務がないため、法的には受注者に非がない、という事態です。

これは受注者が常に悪意で仕組むものではありません。「受託」という言葉が完成責任の有無を含まない曖昧な業界用語であるために、双方が違うものを想像したまま契約に至るのです。防ぐ方法は一つで、契約書を営業トークではなく条文で読むことです。見るべき箇所は5つあります。

1. 契約類型の明示: 「本契約は民法上の請負契約とする／準委任契約とする」という条項があるか。書いていない場合も、以下の実質で判断します。
2. 報酬の定め方: 「成果物の完成に対して総額○円」なら請負型、「1人月あたり○円、毎月精算」なら準委任・SES型です。月額精算の契約に完成責任はまず付いていません。
3. 検収条項の有無と具体性: 検収の手順・期間・合格基準が定義されているか。検収条項がない、または「甲の確認をもって完了とする」程度しか書いていない契約で完成責任を問うのは困難です。何を納品物として受け取り検収すべきかは、システム開発の納品物と検収チェックの解説で詳しく整理しています。
4. 契約不適合責任の条項: 検収後に見つかった不具合への対応義務（追完・期間）が書かれているか。この条項が丸ごと無い契約は、請負を名乗っていても実質は労務提供に近い設計です。
5. 要員・稼働の管理方法: 「作業報告書」「要員名簿」「発注者オフィスへの常駐」「時間単位の稼働精算」が中心の契約は、SES型の徴表です。

発注者側にもある偽装請負リスク

もう一つ、経営者が見落としがちなのは、SES・請負の現場に発注者が直接指示を出すこと自体が法令リスクになる点です。厚生労働省の「労働者派遣・請負を適正に行うためのガイド」では、偽装請負を「実態として、労働者派遣事業であると判断されるもの（労働者派遣法に違反）」等と定義し、労働者派遣事業と請負との区分は契約の形式ではなく実態に即して判断されると整理しています。

つまり、契約書が「業務委託」でも、発注者側の社員が受注側エンジニアに日々の作業指示や労働時間の管理を行っていれば、実態は派遣と判断され、無許可の派遣受け入れとして発注者側もコンプライアンス上の問題を抱えます。「常駐してもらって、うちの社員と同じように指示して動かせば早い」という運用は、便利に見えて発注者自身のリスクです。エンジニアへの指示は受注側のPMを通す——この規律は、契約形態の整合性を守る意味でも重要です。

受託開発の相場が決まる構造——「人月×工数×リスク」

相場の話に入ります。ここで先にお伝えしたいのは、「受託開発の相場は○○万円」という一発回答は構造的に存在しないということです。相場を知るには、金額がどう組み立てられるかの構造を知る方が実用的です。受託開発の見積もりは、ほぼ例外なく次の掛け算でできています。

見積金額 ＝ 人月単価 × 想定工数（人月） ＋ リスク・管理の上乗せ

人月単価——「誰が」の値段

1人月とは、エンジニア1人が1か月稼働する作業量の単位です。単価はエンジニアのスキルレベル（PM、上級SE、若手プログラマ等）と、受注会社の体制（自社正社員か、下請・フリーランスへの再委託か）で大きく変わります。多重下請構造では、間に入る会社ごとにマージンが乗るため、同じエンジニアでも発注ルートによって単価が変わります。スキル帯ごとの具体的な単価水準はSES単価の相場と内訳の解説に譲りますが、発注者として知るべきは「単価の高低」より「その単価の人が実際に手を動かすのか」です。見積書の単価が妥当でも、実働が二次請け・三次請けなら、払った金額と受け取る品質は一致しません。

想定工数——「どれだけかかるか」は発注者の準備で変わる

工数は機能の数と複雑さで決まりますが、発注者側の要因でも大きく増減します。増える方向に働くのは、要件が文書化されていない（ヒアリング・要件定義工数が膨らむ）、既存システムや外部サービスとの連携が多い、例外業務フローが多い、決裁者のレビューが遅く手戻りが出る、といった要因です。逆に、業務フローが整理されている・画面イメージや帳票サンプルが揃っている・意思決定者が明確、という発注者は工数を確実に圧縮できます。同じシステムでも、発注者の準備次第で見積もりは大きく変わる——これは実装側の実感として言えることです。規模帯ごとに何ができるかの目安は、中小企業向けシステム開発の費用相場ガイドで整理しています。

契約形態で変わるリスクプレミアム

見落とされがちな第三の変数が、契約形態そのものが金額に織り込むリスクです。

• 一括請負（固定金額）: 受注者は完成責任・契約不適合責任・仕様の揺れによる手戻りリスクをすべて負うため、想定工数にバッファ（リスクプレミアム）を上乗せして見積もります。要件が曖昧なほどこの上乗せは大きくなります。つまり「要件が固まっていない案件の一括請負見積もり」は、不確実性の保険料を発注者が前払いする構造です。
• 準委任（実費精算型）: 受注者はリスクを負わない分、単価ベースでは割安に見えます。しかし総額の上限が確定しないため、予算超過リスクは発注者側に移転しています。「準委任の方が安い」のではなく、「リスクの置き場所が違う」のです。
• 多段階の組み合わせ: 要件定義を準委任で行って不確実性を潰し、固まった要件で実装を請負に切り替える方式は、請負のリスクプレミアムを小さくしつつ完成責任を確保する、双方にとって合理的な構造です。見積もりが2段階に分かれることを「面倒」ではなく「保険料の節約」と捉えるのが発注側の正しい読み方です。

この構造が分かると、「A社は800万円、B社は450万円。B社が安い」という比較が危険な理由も見えてきます。契約形態・責任範囲・工数前提が違えば、その2つの金額は同じ商品の値段ではないからです。

見積もりを受け取ったときの確認観点

見積書が届いたら、金額の前に次の6点を確認してください。

1. 契約類型はどちらか: 請負か準委任か、工程ごとに分かれているか。見積書に書いていなければ質問し、回答を書面で残す。
2. 内訳の粒度: 「システム開発一式 ○○円」の一行見積もりは比較も交渉もできません。工程別・機能別の工数内訳を求める。
3. 前提条件の明記: 「画面数○枚まで」「要件変更は別途」等の前提はどこか。前提が書かれていない見積もりは、後の追加請求の火種です。
4. 検収と支払いの関係: 支払いは検収合格後か、着手金・中間金の割合は妥当か。完成前に大半を支払う条件は、請負の完成責任を実質的に骨抜きにします。
5. 契約不適合責任の期間と範囲: 検収後の不具合対応は何か月・どこまで無償か。
6. 再委託の有無: 実働は誰か。再委託する場合の承諾条項と責任の所在。

複数社の見積もりが揃ったら、金額の絶対値ではなく「同じ前提に揃えたら差はどこから来るのか」を見ます。差の正体は通常、工数見積もりの精度、単価、リスクプレミアム、そしてスコープ解釈の違いのどれかです。

契約前チェックリスト

契約書に押印する前の最終確認として使ってください。

• 契約類型（請負／準委任）が条文上明確で、営業時の説明と一致している
• 報酬の定め方（完成対価か月額精算か）が、期待する責任範囲と整合している
• 成果物の一覧（ソースコード・設計書・テスト結果等）と権利帰属が明記されている
• 検収の手順・期間・合格基準が具体的に定義されている
• 契約不適合責任の期間・範囲が明記されている（民法637条の「知った時から1年」を短縮していないか確認した）
• 仕様変更時の手続き（変更管理）と追加費用の決め方が定義されている
• 中途解約時の精算方法（民法634条・641条・648条3項・651条の扱い）を確認した
• 再委託の可否と承諾手続きが定義されている
• エンジニアへの指示系統が受注側PM経由に設計されている（偽装請負の実態を作らない）
• 準委任工程がある場合、月次の報告内容と「何をもって順調とするか」を合意した

よくある質問（FAQ）

Q1. 受託開発とSESは、結局何が一番違うのですか。

お金を払う対象です。受託開発（請負型）は「完成した成果物」に、SESは「エンジニアの稼働時間」に対価を払います。前者は完成しなければ原則報酬が発生せず、後者は成果物がなくても稼働分の支払いが発生します。契約書の報酬条項が「総額固定・検収後払い」か「人月単価・月次精算」かで見分けるのが確実です。

Q2. 準委任契約は発注者に不利な契約ですか。

不利なのではなく、リスクの置き場所が違う契約です。要件が固まっていない段階で無理に請負にすると、受注者は大きなリスクプレミアムを上乗せするか、要件を狭く固定しようとします。要件定義は準委任、実装は請負という組み合わせが、多くの初回発注では合理的です。問題なのは準委任そのものではなく、「完成責任があると誤解したまま準委任で契約すること」です。

Q3. 契約書に「請負」とも「準委任」とも書いていません。どう判断すればいいですか。

報酬と検収の条項で実質を判断します。完成物への総額対価と検収条項があれば請負型、月次の工数精算と作業報告が中心なら準委任・SES型です。判断がつかない契約書は、それ自体が紛争リスクなので、締結前に契約類型の明記を求めてください。応じない相手とは契約しないのが安全です。

Q4. 納品後に不具合が見つかった場合、いつまで対応を求められますか。

民法637条では、契約不適合を知った時から1年以内に通知しなければ、追完請求・報酬減額請求・損害賠償請求・解除ができなくなるのが原則です（受注者が悪意・重過失の場合を除く）。ただし実務の契約書では期間を「検収後○か月」等に変更している例が多いため、法律の原則より先に、自社の契約書の条項を確認してください。

Q5. ラボ型開発は初めての外注に向きますか。

原則向きません。ラボ型は完成責任のない月額チーム契約なので、発注側に「何を作らせるかを継続的に判断できる体制」がないと、稼働だけが消化されます。初回発注で作りたいものが1つ明確なら、要件定義（準委任）＋実装（請負）の組み合わせから始める方が安全です。

GXOに相談すべきケース

GXOは受託開発の実装側の会社です。だからこそ、見積書のどこにバッファが乗るか、どの契約形態が受注者に有利にできているか、検収条項のどの欠落が後で効いてくるかを、発注者側に立って開示できます。

次のいずれかに当てはまるなら、契約前の段階で一度ご相談ください。

• 手元の見積書が請負か準委任か判別できない、または金額の妥当性を判断する材料がない
• 複数社の見積もりが2倍以上開いていて、差の理由が説明できない
• 「常駐で対応します」「月額での精算になります」と言われたが、完成責任の所在が不明
• 要件定義から一括固定金額の見積もりを提示され、進めてよいか迷っている

他社の見積書を持ち込んでいただければ、契約形態・工数前提・リスクの置き場所を第三者として分解します。見積もりセカンドオピニオン（見積レビュー相談）からお申し込みいただくか、要件整理の段階からであればお問い合わせ（無料相談）へどうぞ。契約書に押印する前が、発注者が最も強い交渉力を持てる唯一のタイミングです。

参考（一次ソース）

• 情報システム・モデル取引・契約書（IPA 独立行政法人情報処理推進機構）
• 情報システム・モデル取引・契約書（第二版）（IPA）
• 民法（明治二十九年法律第八十九号）第632条・634条・636条・637条・641条・643条・644条・648条・648条の2・651条・656条・559条・562条〜564条（e-Gov法令検索）
• 「労働者派遣・請負を適正に行うためのガイド」について（厚生労働省）