TOPICS

TOP

>

TOPICS

>

システム開発

システム開発における業務委託の基本|請負契約・準委任契約の違いと注意点を解説

更新日: 2025年8月13日

03-49_システム開発の業務委託とは?請負契約・準委任契約の違いと注意点を解説

外部の企業にシステム開発を依頼したいけれど、「どんな契約形態があるのか」「後からトラブルにならないか」と不安を感じたことはありませんか?新規システムの開発や保守を外部ベンダーに委託する企業が増加しています。しかし、契約形態には複数の種類があり、選択を誤ると期待した成果が得られなかったり、思わぬトラブルに発展したりするおそれがあります。

適切な業務委託契約を結ぶためには「請負契約」と「準委任契約」のといった契約形態の違いを正しく理解することが重要です。この記事では、それぞれの契約の特徴と、選び方のポイントをわかりやすく解説します。契約トラブルを避けたい方や、初めて委託契約を結ぶ方は、ぜひ参考にしてください。

システム開発の業務委託とは?契約形態ごとの違い

業務委託とは、特定の業務を外部の企業や個人に任せる契約全般を指す言葉です。
法的には、「請負契約」や「準委任契約」といった契約形態が含まれており、システム開発を外部に委託する際は、業務内容や責任範囲に応じた契約形態を選ぶ必要があります。主な契約形態は3種類あり、それぞれに特徴があります。ここでは、委任契約・準委任契約・請負契約の違いについて解説します。

4347_複雑な契約・契約書のイメージ

委任契約|法律行為の代理を任せる契約

委任契約は、法律行為の代理を外部に任せる契約です。たとえば、契約締結や登記など、法的な効果をともなう行為の実行を第三者に依頼する場合に用いられます。システム開発は法律行為に当たらないため、準委任契約や請負契約が結ばれることが一般的です。

準委任契約との違いは、委任契約の目的が「法律行為」であるのに対し、準委任契約は「実務作業」が対象です。

準委任契約|作業や業務の遂行を依頼する契約

準委任契約は、特定の作業や業務の遂行を委託する契約です。成果物の完成は求めず、業務を着実に実行すること自体が契約の対象となります。業務の進め方については基本的に委託先に一任され、発注側が細かく指示を出すことはできません。

報酬は作業時間や進行状況に応じて支払われ、たとえ成果が形にならなくても、契約通り作業していれば報酬が発生します。

請負契約|成果物の完成を目的とする契約

請負契約は、あらかじめ取り決めた成果物を完成させることを目的とする契約です。受託側は、合意した仕様や納期に従い、完成品を納品する義務を負います。発注者は、成果物が契約条件を満たしていれば、その完成度に関係なく報酬を支払う仕組みです。

作業の進め方は基本的に受託側に任されており、発注側が途中で業務の進行に介入することはできません。

請負契約と準委任契約のメリット・デメリット

システム開発で多く用いられる請負契約と準委任契約には、それぞれにメリット・デメリットがあります。ここでは、両者の特徴を踏まえた上で、実務で注意すべきポイントを整理して解説します。

請負契約と準委任契約のメリット・デメリット比較
契約形態 メリット デメリット
請負契約 成果物や完了条件が明確で、品質や責任の所在がはっきりする 仕様変更が発生すると追加契約や費用が必要で、柔軟な対応が難しい
準委任契約 仕様変更に柔軟に対応でき、進行中のすり合わせも可能 成果物の完成が契約対象でないため、品質や進捗の確認体制が必要

請負契約|成果が明確だが仕様変更に弱い

請負契約では、納品すべき成果物や完了条件があらかじめ明確に決められます。そのため、完成後の品質や責任の所在が明確になりやすいのがメリットです。一方で、途中で仕様変更が発生した場合は、追加契約や費用が必要となるため、柔軟な対応が難しくなります。契約前に要件を十分に詰め、後工程で修正コストを最小化する工夫が求められます。

準委任契約|柔軟に進められるが成果保証はない

準委任契約では、業務の実施そのものに対して報酬が支払われるため、仕様変更などにも比較的柔軟に対応しやすいことがメリットです。発注者が細かな指示を直接出すことはできないものの、対応内容をすり合わせながら進める運用は可能です。一方で、成果物の完成は契約の対象ではないため、品質や進捗の確認体制を整えておくことが重要です。

開発スタイルに応じた適切な業務委託契約の選び方

契約形態の種類や特徴について解説しましたが、実際に契約を結ぶ際には、開発スタイルに合った形式を選ぶことが欠かせません。ここでは「アジャイル型」と「ウォーターフォール型」の特徴も踏まえ、契約形態の考え方についても解説します。

アジャイル型|準委任契約が適正とされるケースが多い

アジャイル型は、要件や仕様を柔軟に変えながら、短いサイクルでシステムを改善する手法です。完成形を最初から固めないため、契約時点で成果物を明確に定めるのが難しく、準委任契約が用いられる傾向にあります。

進行状況に応じて対応が必要となるため、進捗共有や報酬の算出方法を明確にさせておくことが重要です。

ウォーターフォール型|請負契約が適正とされる場面が多い

ウォーターフォール型は、要件定義からテストまでを順番に進める従来型の開発手法です。仕様が初期段階で明確に定まるため、成果物ベースで契約しやすく、請負契約が結ばれるケースが多いといえます。ただし、開発途中での変更に制約があるため、事前の要件精査や契約内容のすり合わせが特に重要です。

業務委託でシステム開発を依頼する際の契約のポイント

業務委託でシステム開発を依頼する際、契約内容を十分に詰めておかなければ、認識にズレや予期せぬトラブルに発展するおそれがあります。ここでは、プロジェクトを円滑に進めながらシステム開発を成功に導くために、契約書で押さえておくべき実務上のポイントを解説します。

業務委託でシステム開発を依頼する際の契約ポイント
契約上のポイント
再委託の可否・条件を明記し、承諾や秘密保持義務などのルールを設定する
開発仕様や要件を明確にし、仕様書を添付して契約書と一体管理する
仕様変更時の手続きや費用精算ルールを契約段階で取り決めておく
検収の基準や手続き、保証期間や瑕疵対応の条件を明確にする

外注先を管理するために再委託のルールを決めておく

再委託とは、受託先が業務の一部をさらに第三者へ委託することを指します。再委託があると、情報漏洩のリスクが増え、品質管理が難しくなるおそれがあるため、契約書で可否や条件を明記しておくことが重要です。

再委託を認める場合は、事前の書面による承諾や秘密保持義務の徹底など、具体的なルールを設定しておきましょう。

開発仕様を明確に定めてトラブルを防ぐ

契約する際、開発するシステムの仕様や要件を明確にしておかなければ、納品後に「思っていたものと違う」といったトラブルにつながることがあります。曖昧な表現は避け、成果物の内容・範囲・条件をできるだけ詳細に記載することが大切です。認識のズレを防ぐために、仕様書を添付し契約書と一体で管理する方法も有効です。

途中で仕様変更が起きたときの対応を定めておく

開発途中にやむを得ず仕様を変更するケースは少なくありません。トラブルを防ぐには、変更時の手続きや費用精算ルールを契約段階で明確にしておく必要があります。たとえば、変更は書面で合意する、追加工数に応じて費用を再計算するなどの取り決めがあると、後々の混乱を避けやすくなるでしょう。

納品後のトラブルを避けるために検収の基準を決める

システムの納品後にトラブルを防ぐには「いつ」「どのように」完成とみなすかを明確にしておくことが重要です。検収の基準や手続きが不明確では、完成の認定や支払いタイミングを巡って揉める可能性があります。

機能の合致や動作確認の条件を明記し、検収後の瑕疵対応や保証期間についても取り決めておくと安心です。

成果物の権利を適切に管理するための契約のポイント

システム開発では、完成したプログラムや設計図などの成果物に関する権利を誰が持つのか、事前に明確にしておく必要があります。契約内容が曖昧だと、納品後のトラブルや二次利用の制限につながるおそれがあります。ここでは、成果物の権利管理で注意すべき契約上のポイントを解説します。

成果物の権利を適切に管理するための契約ポイント
契約上のポイント
知的財産の帰属先を契約で明確にする(通常実施権なども取り決め)
著作権移転条項を盛り込み、第27条・28条の権利も移転対象に含める
第三者ソフト使用時の承諾取得義務や責任範囲を明記する

知的財産の帰属先を契約で明確にしておく

開発されたプロダクトやシステムに関する特許やノウハウなどの知的財産は、契約でどちらに帰属させるかを明確に定めておく必要があります。特に、成果物に受託者が保有する技術や資産が含まれる場合は、通常実施権の承諾などもあわせて取り決めておくと安心です。曖昧なままでは、利用制限やトラブルの原因となりかねません。

著作権を確実に移転できるよう条文を整備する

納品物に関する著作権は、契約で明示しない限り原則として受託者に帰属します。そのため、著作権の移転条項を盛り込み「納品と同時に著作権を移転する」と定めることが重要です。加えて、翻訳権・翻案権など著作権法第27条・28条に基づく権利も移転対象に含める旨を明記しておくと、後々の利用制限を防げます。

第三者ソフトを使うときの責任範囲を定めておく

外注先がフリーソフトやオープンソースなどの第三者ソフトを使用する場合は、ライセンス違反や権利侵害のリスクがあります。契約書には、事前の承諾取得義務や性能・権利状況の調査義務を明記し、責任の所在を整理しておくことが重要です。調査を怠った場合の責任限定条項も設けておくと安全です。

トラブル発生時に備えた契約のポイント

システム開発では、想定外のトラブルが発生することも少なくありません。納品物の不具合や知的財産権の侵害などに備えて、契約段階で責任の所在や対応フローを明確にしておくことが重要です。ここでは、万が一の事態にも慌てず対応できるようにするための契約上のポイントを解説します。

納品物に不備があった場合の責任を明確にする

納品後に不具合や仕様との相違が発覚するケースに備え、契約書には検収の基準と瑕疵対応の範囲を明記しておく必要があります。完成品の定義や検収期間、対応すべき不備の内容を明確にし、保証期間や再修正の可否も取り決めておくと安心です。

責任範囲が曖昧なままでは、補修対応や費用負担を巡ってトラブルに発展する可能性があるため、注意しましょう。

第三者からの権利侵害請求にどう対応するか決めておく

万が一、納品物が第三者の著作権や特許権を侵害していた場合の対応も契約で定めておくべき重要な項目です。申立てがあった際の通知義務や、受託者の帰責事由がある場合の保証条件を具体的に記載しておくと、トラブル時の対応がスムーズになります。訴訟に発展した際の対応や損害賠償の費用負担についても、責任の範囲を明確にしておくとよいでしょう。

まとめ

システム開発を業務委託する際には、契約形態や契約内容の詰め方によって、成果やトラブルのリスクが大きく変わります。請負契約と準委任契約の特徴を理解し、開発スタイルに合った契約を選ぶことが重要です。成果物の権利や再委託、検収基準も事前に明文化しておきましょう。

特にアジャイル開発では、要件が曖昧なまま進行し、仕様のブレやコスト増に悩むケースが少なくありません。こうした課題を避けるには、初期段階で「何を、どこまで定めるか」を整理することが大切です。

Sun Asteriskではアジャイル開発に重要な要件定義のチェックリストを用意しています。合意形成のタイミングや優先順位の整理など、アジャイル開発に欠かせない観点をリストで確認可能です。アジャイル開発の注意点などを整理したい場合は、以下の資料を活用してみてください。

>>【チェックリスト】現場で使える 要件定義のチェックリスト(無料ダウンロード)

アジャイル開発で最低限抑えておきたいポイントをチェックリスト化いたしました。

本ガイドでは、複雑になりがちなシステム開発の見積もりの基本構造や比較のポイントをわかりやすく解説いたしました。