ソフトウェア（システム）開発委託契約とは？トラブルを防止する委託契約の基本を解説【2024年最新版】

ただでさえイレギュラーな状況が発生しがちなソフトウェア（システム）開発では、キチンとした委託契約を締結しておくことがトラブルを防止するポイント。しかし、経験の浅いIT担当者の方であれば、どのように委託契約を結べばいいのか？以下のような疑問を感じているはずです。

• ソフトウェア（システム）開発委託契約とは？一般的な業務委託契約となにが違う？
• ソフトウェア開発の手法に応じて委託契約の形態が異なる？
• トラブルなくソフトウェア開発委託契約を締結するには？注意ポイントを知りたい

そこで本記事では、契約形態の種類、近年採用されることの多くなった多段階契約と一括契約の違いなど、ソフトウェア開発委託契約の基本を解説！契約書作成の参考になる、ソフトウェア開発委託契約書のひな形も紹介していきます。

※安心してソフトウェア開発委託契約を締結できる、優良なシステム開発会社を探している方はシステム幹事にお問い合わせください。予算や目的などをヒアリングした上で、御社に最適なシステム開発会社を選定します。相談料・紹介料はいっさいかかりません。

【無料】おすすめのシステム開発会社をご紹介します

ソフトウェア開発に役立つ記事もご覧ください ソフトウェア開発の基礎知識をおさらい！基本的な工程や流れ、依頼会社の選び方

ソフトウェア（システム）開発委託契約とは

ソフトウェア（システム）開発委託契約とは、開発を依頼するユーザー企業、およびソフトウェア開発を受託するベンダー / SIer（システムインテグレーター）との間で締結される業務委託契約のこと。ユーザー企業にとっては「委託開発」、ベンダー / SIerにとっては「受託開発」となりますが、契約としては「ソフトウェア開発委託契約」となるのが一般的です。

便宜上「業務委託契約」という言葉を使いましたが、業務委託契約とはそれぞれ性質の異なる「請負契約」「委任契約」「準委任契約」の総称です。民法上に存在する正式名称ではありません。

また、このうちの「委任契約」に関しては法律行為に係る契約となるため、システム開発委託契約は「請負契約」または「準委任契約」のいずれかが該当することになります。以下から、請負契約および準委任契約の概要を解説していきましょう。

▼関連記事
ソフトウェア / システムの受託開発、委託開発の違いについてより詳しく知りたい方は、「受託開発とは？自社開発やSESとの違い・委託側が知っておきたいシステム開発の基本を解説！」をあわせてご覧ください。

請負契約（民法第632条）

請負契約とは、委託業務や仕事の完了に対して報酬が発生する契約形態のこと。受託側は、委託側（ユーザー企業）の指示に従うのではなく、対等の立場で業務・仕事を進めていくのが特徴です。

委託業務・仕事の完了とは、受託側が契約で定められた「成果物」を納品し、委託側が契約通りの品質を満たしているのを確認して「検収」した時点のことです。成果物の形がないソフトウェア開発の場合、プログラム本体が成果物となりますが、納品書とともに設計書 / テスト報告書 / マニュアルなどのドキュメント類を成果物として納品する場合もあります。

成果物の品質を保証する契約不適合責任

ソフトウェアの検収後に品質の問題が発覚した場合、委託側は受託側に対してソフトウェアの改修・修正や損害賠償、契約の解除などを請求できます。これは、受託側に成果物の品質を満足させる「契約不適合責任」の義務があるからです。

従来の請負契約では、成果物の品質を「納品から1年間保証する」瑕疵担保責任という義務がありましたが、2020年4月の民法改正で契約不適合責任へと置き換えられた経緯があります。成果物の品質を保証するという点は瑕疵担保責任と同様ですが、契約不適合責任では「成果物の契約不適合を知ったときから1年間」に変更されているのが大きな違い。委託側であれば知っておきたいポイントです。

準委任契約（民法第656条）

準委任契約とは、委託業務や仕事の遂行に対して報酬が発生する契約形態のこと。委託側 / 受託側が対等の立場で業務・仕事を遂行するという点では請負契約と同じ。ただし時間・日数などの「業務遂行量」に応じて報酬が発生すること、原則として業務・仕事が完了しなくても報酬が発生することが大きな違いです。

ただし、2020年4月の民法改正により、準委任契約には「これまでの履行型（業務の遂行）」に加え「新たな成果型（業務の完了）」が規定されました。

成果型準委任契約とは

「成果型」とは、仕事の遂行に対して報酬が発生する「履行型（従来の準委任契約）」と異なり、委託業務・仕事の完了に対して報酬が発生する準委任契約のこと。ただし、成果型準委任契約は「請負契約とは別物」です。

もっとも大きな違いは、成果型準委任契約には請負契約の義務である「成果物に対する契約不適合責任」がないこと。また、受託側が「成果物の納品（仕事の完了）と同時に報酬を請求できる」という違いもあります。請負契約に比べ、成果物に対する受託側の責任範囲が限定されているのが、成果型準委任契約の特徴だといえるでしょう。

善管注意義務 / 債務不履行責任

責任範囲が限定されているとはいえ、準委任契約も民法の1つです。委託者側の権利 / 利益を守るために、受託側が果たすべき「義務」「責任」が民法で定められています。具体的には以下の通り。

• 善管注意義務・・・受託者の職業・能力・社会的地位から通常期待される注意義務
• 債務不履行責任・・・受託者の仕事の遅滞・不履行が生じた場合、委託者は損害賠償を請求できる

履行型については善管注意義務のみ適用されますが、成果型については善管注意義務に加えて債務不履行責任も適用されます。

【無料】開発委託契約について相談する

ソフトウェア開発委託は請負契約？準委任契約？

ここまでで、ソフトウェア開発委託に利用される「請負契約」「準委任契約」の基本を紹介してきました。両者の違いを整理したものが以下の表です。

それぞれの契約に異なる特性であることがお分かりでしょう。ソフトウェア開発委託契約では、開発手法の違いに応じて「請負契約」または「成果型準委任契約」を使い分けることが一般的です。

▼関連記事
システム / ソフトウェア開発の手法についてより詳しく知りたい方は、「システム開発の手法4つの特徴・メリット・デメリットを解説！」をあわせてご覧ください。

ウォーターフォール型と相性のいい請負契約

はじめからソフトウェアの完成形を目指してプロジェクトをスタートさせる「ウォーターフォール型」は、成果物の納品・検収をもって仕事の完了となる「請負契約」と相性のいい開発手法です。

ウォーターフォール型とは、水が上流から下流に流れるように「要件定義」「設計」「開発」「テスト」の各プロセスを順序立てて進めていく開発手法のこと。各開発プロセスでドキュメントなどの成果物が納品されることはありますが、本来の成果物であるソフトウェアが納品されるのは、すべての開発プロセスが完了した後です。その意味でも、請負契約と馴染みやすい特徴があるといえるでしょう。

多段階契約と一括契約

ただし、ソフトウェア開発委託を1つの請負契約で締結する従来型の「一括契約」は、近年になって見直される動きが強まっています。上述したように、ウォーターフォール型開発は複数の開発プロセスに分割されますが、一部の開発プロセスは請負契約と馴染まない業務 / 特徴を持つこともあるからです。

特に、企画から納品までの期間が長期化する大規模プロジェクトの場合、各開発ステップごとに適切な契約を個別締結する「多段階契約」を採用するケースが増えています。IPAのモデル契約書で紹介されている、多段階契約例を紹介しておきましょう。

多段階契約であれば、委託側は必要な開発プロセスだけ依頼できるメリットが、受託側は開発プロセスごとに報酬を請求できるメリットが得られます。開発プロセスごとに適切な契約を締結することによって、トラブル防止の効果も得られるでしょう。

一方、複数の契約を締結することになるため、手続きは煩雑化します。特に、社内の理解を得る必要のある委託側にとっては、多段階契約の採用は難しい決断になるかもしれません。ソフトウェア開発プロジェクトの規模・特性を考慮に入れながら、適切な契約形態を選択していくことが重要です。

アジャイル型と相性のいい準委任契約

必要最小限のソフトウェアを開発 / リリースし、ユーザーの反応を見ながら機能を追加する「アジャイル型」は、成果物に品質の責任を負わない「成果型準委任契約」と相性のいい開発手法です。

アジャイル型とは、「企画」「設計」「開発」「テスト」をひとまとめにした「イテレーション」を繰り返し、ユーザーの声を反映させながらソフトウェアの完成を目指す開発手法のこと。1つのイテレーションで開発・リリースされたソフトウェアは、成果物ではありますが、委託業務・仕事が完了したとはいえません。その意味でも、成果型準委任契約と馴染みやすい特徴があるといえるでしょう。

ソフトウェア開発の委託トラブルの要因は契約

開発手法に応じて適切な契約形態が異なるなど、ソフトウェアの開発委託契約は複雑になりがちです。ソフトウェア開発プロジェクトに慣れていない担当者の方であれば、ベンダー / SIerが用意した契約書に安易にサインしてしまうことも考えられます。しかし、トラブルが少なくないソフトウェア開発委託の場合、要因の多くが契約にあることを覚えておくべきです。

たとえば、ベンチャー・中小企業を対象とした調査では、ソフトウェア開発委託契約でトラブルを経験したことのある担当者が全体の約4割にも達しており、約8%の方は10回以上のトラブルを経験しています。

参照元：PRTIMES

また驚くことに、全体の約34%、およそ3人にひとりが「契約内容をまったく理解していなかった / あまり理解していなかった」と回答しています。これではトラブルが生じて当然です。

参照元：PRTIMES

ベンダー / SIerの契約書を利用する、自社で契約書を準備する、いずれの場合でも、請負契約 / 準委任契約の特徴を把握した上で、内容を慎重に吟味しなければなりません。

【無料】開発委託契約について相談する

ソフトウェア開発委託契約条項のチェックポイント

それでは、実際にソフトウェア開発委託契約を提携する際は、契約書のどのような条項を確認すればいいのか？以下から、特に重要だと思われるチェックポイントを解説していきます。

契約は当事者の意思表示が優先される

まず大前提として知っておきたい重要なポイントは、契約は「民法よりも当事者の意思表示が優先される」ということ。つまり、契約の当事者同士が合意しているのなら、民法の定めと異なる内容の契約書でも問題ないということです。

本来、契約は口頭でも成立するものではありますが、契約書という形に残すことが重要なのはこのため。契約内容が自社の不利益にならないよう、民法と照らし合わせながら内容をすりあわせていくことになります。

ソフトウェアの開発範囲 / 仕様 / 仕様の変更

委託開発の対象となるソフトウェアの仕様が、委託する範囲とともに特定できているかをチェックします。どのようなソフトウェアか？どの程度の品質を満たす必要があるか？受託側の責任が明確でなければ、委託業務・仕事の完了を明確にできないからです。

採用する開発手法や契約対象の開発プロセスによっても異なりますが、最低限求める機能要件、機能以外に求める非機能要件を明らかにし、契約書に添付しておきたいところ。ウォーターフォール型であれば、要求定義フェーズで作成した「RFP / 要求定義書」を契約書に添付するなどの方法があります。

また、開発中にソフトウェアの仕様変更が生じた際の対応が、契約書に明記されているかもチェックしておきたいポイント。仕様変更は、ソフトウェアの委託開発でもっともトラブルにつながりやすい要因です。「仕様の変更は書面をもって確定する」などの条項を追加するのがおすすめです。

▼関連記事
RFP（提案依頼書）についてより詳しく知りたい方は、「RFPとは？システム開発の質を高める提案依頼書の作り方を解説！」をあわせてご覧ください。

ソフトウェアの成果物 / 納品 / 検収

開発したソフトウェアが、なにをもって納品 / 検収されたとみなされるのか？契約書に明記されていることをチェックします。形のないプログラムが成果物となるソフトウェア開発では、委託業務の報酬が発生する納品 / 検品のタイミングが曖昧になりがちだからです。

具体的には、仕様書 / テスト報告書 / マニュアルなど、ソフトウェア本体を含む成果物を明確にした上で「納入期限」「成果物の納品方法」が契約書に記載されているかを確認します。

また、受入テストを入念に実施したい委託側としては、納品から検収までの期間を長めに取りたいところですが、あまり長期になると受託側の負担になります。契約書に記載された「検査期間」「検査基準」「検査期間満了時の取り扱い」を確認し、受託側とすり合わせしていく必要があるでしょう。

委託費用 / 支払い方法

ソフトウェア開発の委託費用 / 支払い方法が、契約書に明確に記載されていることをチェックします。民法上の請負契約の場合、委託業務の完了をもって報酬の支払い義務が発生しますが、一般的には、受託側の負担を軽減するため手付金を含めた段階的支払いを採用することがほとんど。当事者同士の認識の違いがトラブルに発展しないよう、すり合わせが必須のポイントです。

また、委託開発費用の変更が生じた場合に備え、「甲と乙が委託料の変更について協議するものとする」などの一文を契約書に加えておきましょう。上述した「仕様の変更」など、費用が変動する可能性のある条件を挙げておくのもおすすめです。

ソフトウェアの所有権 / 知的財産権（著作権）

成果物であるソフトウェアの所有権 / 知的財産権（著作権）が、契約書に明確に記載されていることをチェックします。ソフトウェアを含む著作物は著作物の制作者に、ソフトウェア開発のベースにパッケージなどを利用しているなら、パッケージ自体の所有権はメーカーに帰属します。こうした状況は、ソフトウェアの利用や改修 / 改善に大きな影響をおよぼす要因です。

開発するソフトウェアにもよりますが、将来的な弊害が生じるようであれば、受託側と協議した上で以下の一文を加えておくといいでしょう。

• 成果物の所有権は、甲が乙に委託料を全額支払った時点で乙から甲に移転する（所有権の移転）
• 成果物の著作権は、甲が乙に委託料を全額支払った時点で乙から甲に移転する（著作権の移転）
• 乙は、甲および甲が指定した者に対して、当該著作物の使用を許諾する（著作権移転が困難な場合）

再委託の可否

受託側（ベンダー / SIer）の再委託・下請に関連する条項が、契約書に明確に記載されていることをチェックします。再委託自体が悪いこととはいい切れませんが、開発時の多重下請け構造はソフトウェアの品質に悪影響を与える場合があるからです。

ただし、ソフトウェア開発の規模などによっては、再委託が必須の場合も考えられます。再委託を事前承認制にする、再委託先の義務と責任を受託側が負う、委託側に再委託の撤回・取消のできる権利を設ける、などの条項を記載しておくのがおすすめです。

契約不適合責任の期間 / 範囲

請負契約の場合は、契約不適合責任の期間 / 範囲が、契約書に明確に記載されていることをチェックします。民法改正によって、契約不適合責任の期間は「契約不適合を知ってから1年間」となりましたが、この期間をなるべく短縮したいのが受託側の立場。契約書に「納品から1年間」などと記載されていることもあり得ます。

ただし、民法を根拠に強く訂正を求めるのも考えものです。契約不適合が発覚した場合の「対応方法 / 範囲」を含め、受託側と協議を重ねて妥協点を見つける方法がおすすめです。

損害賠償の範囲 / 制限

「どのような場合に損害賠償できるのか」「損害賠償の上限金額はいくらなのか」損害賠償の制限・範囲が、契約書に明確に記載されていることをチェックします。損害賠償の上限は「ソフトウェア開発の委託費用と同等」にすることが一般的ですが、金額の妥当性も含め、弁護士などの専門家にチェックしてもらうことがおすすめです。

【無料】開発委託契約について相談する

ソフトウェア開発委託契約書のひな形

ソフトウェア開発の委託契約を締結する場合、受託側が契約書を用意し、委託側が内容を確認した上でサインすることが一般的です。ただし、ベンダー / SIerが独自に契約書を作成していることはまれ。通常は、契約書のひな形を自社向けにアレンジし、利用している場合がほとんどです。

つまり、ベンダー / SIerが利用している契約書のひな形を入手できれば、委託契約前にある程度のチェックポイントを把握できます。以下から、ソフトウェア開発委託契約書の主なひな形を紹介しておきましょう。

ウォーターフォール型開発委託のモデル契約書

以下は、IPA（独立行政法人 情報処理推進機構）および、JISA（一般社団法人 情報サービス産業協会）が公開する、ウォーターフォール型委託開発のモデル契約書です。

https://www.ipa.go.jp/ikc/reports/20201222.html

https://www.jisa.or.jp/Portals/0/report/contract_model2020.pdf

アジャイル型開発委託のモデル契約書

以下は、IPA（独立行政法人 情報処理推進機構）が公開する、アジャイル型委託開発のモデル契約書です。準委任契約が基本となっていることが、ウォーターフォール型開発との違いです。

https://www.ipa.go.jp/ikc/reports/20200331_1.html

【無料】開発委託契約について相談する

ソフトウェア開発の委託契約について紹介しました

本記事では、契約形態の種類、近年採用されることの多くなった多段階契約と一括契約の違いなどソフトウェア開発委託契約の基本を解説するとともに、契約書のひな形も紹介しました。

ソフトウェア開発を委託する場合、委託側と受託側で利害関係が対立することが少なくありません。民法上の請負契約 / 準委任契約を理解し、自社に寄り添ってくれる優良なシステム開発会社と契約することが重要です。

※安心してソフトウェア開発委託契約を締結できる、優良なシステム開発会社を探している方はシステム幹事にお問い合わせください。予算や目的などをヒアリングした上で、御社に最適なシステム開発会社を選定します。相談料・紹介料はいっさいかかりません。

コンサルタントのご紹介 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます！
初心者の方でも安心してご相談いただけます。

【無料】おすすめのシステム開発会社を選んでもらう