システム等開発業務委託契約書の作り方と重要な35の契約条項のポイントについて解説

このページでは、ソフトウェア、システム、アプリ等の開発業務委託契約書（以下、「システム等開発業務委託契約書」といいます）の契約条項のポイントについて解説しています。

システム等開発業務委託契約は、特に大規模な案件ほど、契約内容が複雑となり、分量も多くなりがちです。

これは、それほどシステム等開発業務委託契約にトラブルが多いことを意味します。

このページでは、システム等開発業務委託契約の作成の際に重要となる契約条項のうち、35項目をピックアップして解説します。

なお、システム等開発業務委託契約そのものの解説や定義につきましては、詳しくは、以下のページをご覧ください。

【改正民法対応】ソフトウェア・システム・アプリ開発業務委託契約とは？

システム等開発業務委託契約とは？

【意味・定義】システム等開発業務委託契約とは？

システム等開発業務委託契約は、プログラムの作成がともなうソフトウェア、システム、アプリ等の開発に関する業務委託契約です。

システム等開発業務委託契約は、民法などの法律では、特に定義はありません。

このため、大企業の基幹システムを開発であっても、ウェブサイトで動くようなちょっとしたプログラムの開発であっても、同じような名称（「ソフトウェア開発契約」など）となることがあります。

しかし、その実態は案件ごとに異なりますし、契約内容もまた、案件ごとに調整が必要となります。

規模に関係なくコーディング・プログラミングの業務がある

システム等開発業務委託契約では、「開発」という名称がついていることから、ほとんどの場合は、コーディング、プログラミングの業務があります。

これは、案件の規模の大小に関係なく、必ず受託者・ベンダがしなければならない、共通の業務です。

このほか、案件の規模の大きさに応じて、上流工程（大型の案件では「超上流工程」）から、下流工程のいずれかの幅で、受託者・ベンダの業務があります。

こうした全工程について、システム等開発業務委託契約では、案件の規模に応じて、以下の点が重要となります。

システム等開発業務委託契約の重要な契約条項一覧

システム等開発業務委託契約では、次の契約条項が重要となります。

以下、それぞれ詳しく解説していきます。

【重要な契約条項1】定義

一義的・統一的な解釈となるように用語を定義づける

「定義」の条項では、契約書で使う用語の定義を規定します。

定義条項は、どの契約であっても重要な規定ですが、システム等開発業務委託契約では、特に重要な規定となります。

というのも、システム等開発業務委託契約で使う用語は、ほとんどが法令用語として定義づけられていません。

それどころか、実際のシステム等の開発の現場でも、用語の定義は人それぞれであり、必ずしも一義的・統一的な解釈があるわけではありません。

このため、少なくとも、契約書で使う用語については、一義的・統一的な解釈となるように定義づけます。

実務上はある意味で最も難しい契約条項

ただ、定義条項で用語を定義づける作業は、システム等開発業務委託契約書の作成においては、最も難しい作業といえます。

というのも、すでに触れたとおり、システム等の開発の現場ですら、用語の定義が決まっていません。

このため、用語の定義を決める際に、まずは、ユーザとベンダの間で用語の「内容」についてすり合わせをしなければなりません。

そのうえで、一義的・統一的な解釈となるような、「表現」をしなければなりません。

雛形・モデル契約書の定義を使う

このように、ひとつひとつの用語を丁寧に定義づけると、非常に時間がかかります。

そこで、ひとつの方法としては、すでに触れた雛形・モデル契約書の定義を使う場合もあります。

つまりこれは、とりあえず「雛形・モデル契約書の定義で用語を使う」ことにして、定義のほうに解釈を寄せる方法です。

この場合は、「契約書の作成」の作業自体は、非常に楽になります。

しかしながら、結局、その雛形・モデル契約書の定義を双方がしっかりと理解したうえで使わないと、定義自体が形骸化してしまいます。

そうなると、トラブルとなった際には、契約書の用語としては機能しない、つまり、「そういう意味では使っていない」と主張されるリスクがあります。

【重要な契約条項2】個別契約との関係

個別契約との関係の条項とは？

個別契約との関係の条項では、システム等開発業務委託契約（＝基本契約）と個別契約の関係について規定します。

すでに述べたとおり、システム等開発業務委託契約は、多段階契約となるため、当初に締結する契約は、いわゆる「基本契約」となります。

そして、個々の工程の業務内容等については、個別契約で規定することとなります。

そこで、「個別契約との関係」の条項では、基本契約と個別契約との関係について規定します。

個別契約との関係で優先順位を規定する

個別契約との関係の条項のポイントは以下の2点です。

【ポイント1】につきましては、一般的に、「新しい合意が、古い合意よりも優先する」という原則があるため、ある意味では念のための規定といえます。

【ポイント2】につきましては、口頭やシステム等開発業務委託契約書・個別契約書の取交し以外の合意の有効性を否定するものです。

もっとも、一般的な契約書では、ここまで厳密に規定することは多くはありません。

ただし、システム等開発業務委託契約では、「言った言わない」といった水掛け論が多いため、それだけ厳格な手続きとするように規定します。

【重要な契約条項3】個別契約の内容

「個別契約の内容」の条項では、個別契約で決めるべき内容の「項目」について規定します。

一例として、すでに触れた経済産業省のモデル契約書では、次のように規定されています。

ソフトウェア開発委託基本モデル契約第4条（個別契約）

1　甲及び乙は、個別業務に着手する前に、甲から乙に提示された提案依頼書（RFP）及び乙から甲に提案した提案書、見積書を基礎として、当該個別業務について以下の各号のうち必要となる取引条件を定め、個別契約を締結する。

（1）具体的作業内容（範囲、仕様等）

（2）契約類型（請負・準委任）

（3）作業期間又は納期

（4）作業スケジュール

（5）甲・乙の役割分担（第 8 条で定める作業責任分担の詳細）

（6）連絡協議会の運営に関する事項

（7）甲が乙に提供する情報、資料、機器、設備等（以下「資料等」という。）

（8）作業環境

（9）乙が甲の委託に基づき作成し納入すべき物件（以下「納入物」という。）の明細及び納入場所

（10）委託料及びその支払方法

（11）検査又は確認に関する事項

（12）その他個別業務遂行に必要な事項

2　甲及び乙は、作業スケジュールの進捗に支障を来すことのないように各個別契約の締結交渉に着手し、可能な限り早期に合意に至ることのできるよう双方誠実に協議するものとする。

引用元:情報システム・モデル取引・契約書＜第一版、追補版、モデル取引・契約書活用ツール＞（METI/経済産業省）

【重要な契約条項4】報酬・料金・委託料の支払い

ユーザは下請法違反に注意

「報酬・料金・委託料の支払い」の条項では、ユーザが、ベンダに対して、個別契約の内容にもとづき、報酬・料金・委託料を支払う旨を規定します。

システム等開発業務委託契約では、この条項自体は、格別重要な条項ではありません。

重要となるのは、個別契約での、報酬・料金・委託料の金額または計算方法と、支払期限の規定です。

特に支払期限に関しては、下請法が適用される場合、下請法に違反しないように、委託者・ユーザが設定する必要があります。

なお、下請法が適用されるかどうかにつきましては、詳しくは、以下のページをご覧ください。

下請法の対象かどうかの条件とは？資本金・業務内容（製造委託等）について解説

基本は「納入」から60日以内

請負型の業務は納入（≠検査完了）から60日以内

下請法が適用されるシステム等開発業務委託契約において、個々の業務が請負型の場合は、支払期限は、「納入があった日」から起算して60日以内です。

ポイントは、「納入があった日」から60日以内であって、「検査が完了した日」から60日以内ではありません。

もっとも、いくら「納入があった日」とはいえ、成果物が委託内容の水準に達しているかどうかがわからない場合があります。

この場合、ユーザは、必ずしも支払期日どおりに支払いをする必要はありません。

ただし、これには、以下のとおり、一定の条件を満たしている必要があります。

(3)　また，情報成果物作成委託においては，親事業者が作成の過程で，委託内容の確認や今後の作業についての指示等を行うために，情報成果物を一時的に自己の支配下に置くことがある。親事業者が情報成果物を支配下に置いた時点では，当該情報成果物が委託内容の水準に達し得るかどうか明らかではない場合において，あらかじめ親事業者と下請事業者との間で，親事業者が支配下に置いた当該情報成果物が一定の水準を満たしていることを確認した時点で，給付を受領したこととすることを合意している場合には，当該情報成果物を支配下に置いたとしても直ちに「受領」したものとは取り扱わず，支配下に置いた日を「支払期日」の起算日とはしない。ただし，3条書面に明記された納期日において，親事業者の支配下にあれば，内容の確認が終わっているかどうかを問わず，当該期日に給付を受領したものとして，「支払期日」の起算日とする。

引用元: 下請代金支払遅延等防止法に関する運用基準第4 2（3）

これをわかりやすくまとめると、次のとおりです。

「やり直し」に該当する場合はやり直し後の受領日から60日後

なお、支払期日の到来の前に、成果物に瑕疵が発見された場合、ユーザは、当初の支払期限ではなく、やり直し後の受領日から60日以内に支払えばよいとされています。

Ｑ104： 受領した情報成果物に，下請事業者の責任による瑕疵等が発見され，やり直しが必要な場合にも，当初の受領日から60日以内に支払う必要があるか。

Ａ： 支払期日が到来する前に瑕疵等が発見され，やり直しをさせる場合は，当初の受領日から60日以内に下請代金を支払う必要はない。この場合，やり直し後の情報成果物の受領日が支払期日の起算日となる。

引用元:下請取引適正化推進講習会テキストp.87

準委任型の業務は例外的に締切計算ができる

個々の業務が準委任型の場合でも、支払期限は、請負型の場合と同様に、原則として、「役務の提供があった日」から起算して60日以内です。

ただし、一定期間に業務を提供する場合については、例外として、いわゆる「締切計算」が認められます。

締切計算が認められる条件は、以下のとおりです。

(4)　役務提供委託にあっては，「支払期日」の起算日は，「下請事業者がその委託を受けた役務の提供をした日（役務提供に日数を要する場合は役務提供が終了した日）」であり，原則として，下請事業者が提供する個々の役務に対して「支払期日」を設定する必要がある。ただし，個々の役務が連続して提供される役務であって，次の要件を満たすものについては，月単位で設定された締切対象期間の末日に当該役務が提供されたものとして取り扱う。

○　下請代金の額の支払は，下請事業者と協議の上，月単位で設定される締切対象期間の末日までに提供した役務に対して行われることがあらかじめ合意され，その旨が3条書面に明記されていること。

○　3条書面において当該期間の下請代金の額が明記されていること，又は下請代金の具体的な金額を定めることとなる算定方式（役務の種類・量当たりの単価があらかじめ定められている場合に限る。）が明記されていること。

○　下請事業者が連続して提供する役務が同種のものであること。

引用元: 下請代金支払遅延等防止法に関する運用基準第4 2（4）

【重要な契約条項5】作業期間または納期（納入期限・納入期日）

「作業期間」や「納入期限」の条項では、作業期間や納期（納入期限・納入期日）について、個別契約で規定する旨を規定します。

もっとも、「個別契約の内容」の規定でも同様の規定がありますので、この規定は省略してもかまいません。

なお、「作業期間」は、個々の業務が準委任型の場合に規定し、納期（納入期限または納入期日）は、個々の業務が請負型の場合に規定します。

また、作業期間・納期（納入期限・納入期日）は、下請法の三条書面の必須記載事項です。

このほか、作業期間や納期（納入期限・納入期日）については、詳しくは、以下のページをご覧ください。

納期（納入期限・納入期日）・作業期間とは？契約条項のポイントを解説

【重要な契約条項6】再委託

準委任型は再委託できない・請負型は再委託できる

「再委託」の条項では、ベンダが、システム等開発業務委託契約の業務内容の全部の一部または全部を再委託（下請負・再準委任）できるかどうかを規定します。

個々の業務内容・個別契約が準委任型であれば再委託はできない

民法上の原則では、個々の業務内容・個別契約が準委任型であれば、再委託（再準委任）ができません。

これは、準委任契約が、ユーザとベンダとの信頼関係が基本となる契約だからです。

このため、ユーザの承諾がない限り、ベンダは、本来は部外者である第三者に対して、再委託ができません。

個々の業務内容・個別契約が請負型であれば下請負はできる

これに対し、個々の業務内容・個別契約が請負型のであれば、再委託（下請負）ができます。

これは、請負契約が「仕事の完成」そのものが目的ですので、誰がその仕事を完成させるかは、問題ではありません。

このため、特にユーザの承諾がなくても、ベンダは、第三者に対して、再委託ができます。

なお、再委託に関する請負契約と委任契約の違いにつきましては、詳しくは、以下のページの中の「【違い6】受託者による再委託」をご覧ください。

請負契約と（準）委任契約の14の違い

システム等開発業務委託契約に再委託の可否を明記する

ただし、これは、あくまで民法上の原則の話です。

一般的なシステム等開発業務委託契約では、ベンダから第三者への再委託（下請負・再準委任）があるのが常態化しています。

よほど小規模な案件でない限り、個々の業務をベンダが単一ですべて完了することは、まずありません。

このため、一般的なシステム等開発業務委託契約では、準委任型であれ請負型であれ、受託者・ベンダが再委託（下請負・再準委任）できる内容とすることが多いです。

ユーザの事前承諾が必要かどうかがポイント

ユーザは必要・ベンダは不要とする

ここで重要となるのが、ベンダが第三者に再委託（下請負・再準委任）をする場合、ユーザの事前承諾が必要かどうか、という点です。

この点については、ユーザとしては、事前に承諾が必要となるように規定するべきです。

逆に、ベンダとしては、事前の承諾が必要とならないように規定するべきです。

もっとも、この場合であっても、ユーザとしては、後から再委託（下請負・再準委任）の中止を求められるようにするべきです。

この他、再委託につきましては、詳しくは、以下のページをご覧ください。

業務委託契約における再委託・下請負（外注）の許可・禁止条項とは？

【重要な契約条項7】協働・役割分担

ユーザにも一定の役割・義務がある

「協働・役割分担」の条項では、個々の業務の実施について、受託者・ベンダだけではなく、委託者・ユーザにも一定の役割がある旨を規定し、あわせて、役割分担についても規定します。

一般的な業務委託契約とシステム等開発業務委託契約の大きく異なる点が、この「協働」「役割分担」という概念がある点です。

一般的な業務委託契約では、委託者は、受託者に対して、報酬・料金・委託料を支払う義務以外には、ほとんど義務はありません。

これに対し、システム等開発業務委託契約では、委託者であるユーザは、受託者であるベンダに対して、報酬・料金・委託料の支払い以外にも、一定の義務があります。

ユーザの協力なしにシステム等の開発は成功しない

システム等の開発は、建設工事等とは違って、事前にシステム等の完成の形が見えません。

このため、システム等の開発では、ベンダは、常にユーザの協力を受けながら、開発を進める必要があります。

逆にいえば、ユーザがベンダに対してシステム等の開発を丸投げし、協力を怠ると、不完全なシステム等ができあがります。

最悪の場合、開発そのものが頓挫することもあります。

ユーザが協力を怠るとベンダの責任を追求できなくなる

このように、システム等の開発では、ベンダによる業務の実施だけではなく、ユーザによる一定の協力が必要となります。

このため、システム等開発業務委託契約では、この「協働・役割分担」の規定で、ユーザ・ベンダ双方の役割や義務について規定します。

なお、ユーザ・ベンダともに、作業や協力を怠った場合は、相手方に対し、責任を負う旨も規定します。

これにより、特に委託者・ユーザの側が受託者・ベンダに対する協力を怠った場合、結果として不完全なシステム等ができあがったときや、開発が頓挫したときであっても、委託者・ユーザは、受託者・ベンダに対し、責任を追求できなくなります。

【重要な契約条項8】責任者

「責任者」の条項では、ユーザとベンダの責任者が誰であるかを相手方に通知することと、それぞれの責任者の権限と責任を規定します。

ここでいう「責任者」とは、一般的には、いわゆる「プロジェクトマネージャー」のことを意味します。

この条項で、わざわざプロジェクトマネージャーの権限と責任を規定するのは、当然ながら、システム等開発業務委託契約におけるプロジェクトマネージャーの権限と責任を明らかにするためです。

ひと言で「プロジェクトマネージャー」といっても、その職務内容・職務権限・責任は企業や案件によって様々で、場合によっては決まっていないこともあります。

このため、最低限、システム等開発業務委託契約での事務手続きや決済ができるように、あらかじめ、「責任者」の条項で、権限を決めておきます。

【重要な契約条項9】主任担当者

主任担当者は相手方とのコミュニケーションを担当する

「主任担当者」の条項では、ユーザとベンダの現場での主任担当者が誰であるかを相手方に通知することと、それぞれの主任担当者の役割を規定します。

ここでいう「主任担当者」とは、一般的には、いわゆる「プロジェクトリーダー」のことを意味します。

システム等開発業務委託契約では、一般的に、プロジェクトリーダーの役割として、次のものを規定します。

このように、システム等開発業務委託契約のうえでは、プロジェクトリーダーは、相手方とのコミュニケーションを担当します。

偽装請負とならないためにもプロジェクトリーダーの選任は重要

なお、プロジェクトリーダーを通じた相手方とのコミュニケーションは、偽装請負とならないためにも、重要です。

この点は、客先常駐型の開発（特にシステムエンジニアリングサービス契約・SNS契約）では、非常に重要となります。

偽装請負とみなされる（または、みなされない）ポイントは、厚生労働省の「37号告示」にまとめられています。

その中のひとつに、受託者・ベンダが「労働者に対する業務の遂行方法に関する指示その他の管理を自ら行う」かどうか、という点があります。

このほか、偽装請負とみなされない条件につきましては、詳しくは、以下のページをご覧ください。

37号告示とは？（労働者派遣事業と請負により行われる事業との区分に関する基準 ）

【重要な契約条項10】業務従事者

当たり前のことでもあえて規定する

「業務従事者」の条項では、主に次の内容を規定します。

これらの内容は、本来であれば、当然のことであり、特に契約実務上は、重要なものではありません。

しかしながら、あえてこれらの内容（特に1～3点目）を規定するのは、これも偽装請負＝労働者派遣法違反とみなされないようにするためです。

個々の内容はそれぞれ37号告示の内容に合致

これらの条項の内容は、それぞれ、37号告示の内容に合致している内容です。

こうした内容を、ベンダ自身がおこなうことにより、偽装請負とみなされる可能性は低くなります（これだけでは不十分ですが）。

逆に、こうした内容をベンダではなくユーザがおこなう場合は、偽装請負とみなされる可能性は高くなります。

こうした、偽装請負とみなされないという視点からも、契約条項として、あえて当然の内容を規定しておく必要があります。

このほか、偽装請負とみなされない条件につきましては、詳しくは、以下のページをご覧ください。

37号告示とは？（労働者派遣事業と請負により行われる事業との区分に関する基準 ）

【重要な契約条項11】連絡協議会の設置

連絡協議会とは？

「連絡協議会の設置」の条項では、連絡協議会の目的、開催頻度、参加者、協議事項、議事録の作成と内容等について規定します。

システム等開発業務委託契約が一般的な業務委託契約と異なる点のひとつが、業務の実施にあたって頻繁に協議をする、ということです。

このため、契約条項の内容としても、協議について、より詳細な内容を規定します。

「連絡協議会の設置」の条項では、こうした協議の詳細な内容について規定します。

連絡協議会の開催目的

すでに触れた、システム等開発業務委託契約の雛形・モデル契約書では、連絡協議会の開催目的を、以下のとおり規定しています。

連絡協議会の協議事項

同様に、システム等開発業務委託契約の雛形・モデル契約書では、連絡協議会における協議事項を、以下のとおり規定しています。

ユーザとベンダとは、連絡協議会において、ベンダからの進捗管理報告にもとづいて、これらの協議事項について協議します。

議事録の作成までが連絡協議会

また、連絡協議会は、開催すればいいというわけではありません。

後日のトラブルの予防のために、議事録の作成や、その内容・手続きについても重要となります。

この点について、以下の内容がポイントとなります（カッコ内は雛形・モデル契約書の内容）。

連絡協議会は開発の実態に応じた内容に修正する

なお、これらの内容は、比較的大規模なシステム開発における連絡協議会のものです。

こうした規模の大きな案件では、丁寧な手続きで連絡協議会を開催することにより、大きなトラブルを予防することができます。

このため、事務負担が大きくても、連絡協議会の開催や議事録の作成は、重要となります。

他方、規模が小さな案件となると、これだけの連絡協議会を開催するのは、事務負担の割に大きなメリットがない場合もあり得ます。

このため、開発の実態に応じて、「連絡協議会の設置」の条項は、修正したほうがいい場合もあります。

ただし、単に「面倒くさい」という理由で、連絡協議会を簡略化したり、連絡協議会を開催しないような内容とすると、トラブルの予防にはなりません。

【重要な契約条項12】プロジェクトマネジメントの責任・義務

ベンダにはプロジェクトマネジメント義務がある

「プロジェクトマネジメントの責任・義務」の条項では、受託者・ベンダによるプロジェクトマネジメントの責任と義務を規定します。

一般的に、システム等開発業務委託契約では、受託者・ベンダにプロジェクトマネジメントの義務があります。

ただし、プロジェクトマネジメント義務は、民法や他の法律で具体的に規定された義務ではありません。

このため、受託者・ベンダに具体的にどのような義務があるのかは、案件ごとに判断されます。

そこで、システム等開発業務委託契約書では、プロジェクトマネジメント義務の具体的な内容を明記しておきます。

ユーザの協力義務も規定する

なお、「プロジェクトマネジメントの責任・義務」の条項には、委託者・ユーザの協力義務も規定します。

受託者・ベンダによるプロジェクトマネジメントがあったとしても、委託者・ユーザからの協力がない場合は、システム等の開発がスムーズに進みません。

このため、システム等開発業務委託契約では、委託者・ユーザによる協力を義務として規定します。

なお、個別具体的な協力の内容については、個別契約において規定します。

【重要な契約条項13】要件定義の決定

要件定義＝ユーザの要求

「要件定義の決定」の条項では、要件定義の「内容」の決定について規定します。

要件定義とは、ユーザが要求するシステム等の機能・性能・制約条件等（いわゆる「要求仕様・要求定義」）を実現するための仕様のことです。この要件定義を書面にしたものが、要件定義書です。

要件定義は、ユーザが要求する内容ですので、ユーザが決めなければなりません。

ベンダはユーザによる要件定義の決定の支援をする

ユーザが要件定義を決めるまで、ベンダは何もしなくてもいいかといえば、そうではありません。

自社でシステム等の開発をしていないユーザは、ベンダが理解できるような要件定義を決められない場合がほとんどです。

このため、実際に要件定義を決める際には、ベンダによる支援（実態は主導）が必要となります。

また、自社でもシステム等の開発をしているユーザであっても、開発をスムーズに進めるために、ベンダは、ユーザの要件定義の決定に関し、何らかの形で関与するべきです。

具体的には、一種のコンサルタントのように、ベンダがユーザの要望を引き出し、要件定義の決定をサポートします。

ベンダによる支援は準委任型の業務

こうしたベンダの支援の契約形態は、準委任型としてます。

このため、請負型の業務とは違って、なんらかの仕事の完成＝結果が求められるものではありません。

しかしながら、業務の実施では、受任者として、善管注意義務を果たすことが求められます。

この善管注意義務を果たしていない場合は、債務不履行（いわゆる契約違反）となり、損害賠償等の責任が発生します。

善管注意義務につきましては、詳しくは、以下のページをご覧ください。

準委任型業務委託契約における善管注意義務とは？定義・具体例と5つのポイントもわかりやすく解説

【重要な契約条項14】要件定義書の作成・確定

ユーザ・ベンダのいずれかが要件定義書を作成する

「要件定義書の作成・確定」の条項では、「要件定義の決定」の条項によって決定した要件定義の「内容」を記載した要件定義書を作成し、確定させる旨を規定します。

要件定義書は、ユーザかベンダのいずれかが作成することになります。

理論上は、要件定義はユーザが決めるものであるため、要件定義書もユーザが作成するべきものです。

ただ、ベンダと認識を共有できるような要件定義書を作成できるのは、社内にIT関係の専門部署があるような大手企業のユーザくらいのものです。

このため、実態としては、ベンダが要件定義書を作成することも多いです。

ベンダによる要件定義書の作成＝請負型の業務

ユーザが要件定義書を作成する場合、ベンダは、要件定義の決定のときと同様に、その支援をすることにあります。

この支援の業務もまた、同様に準委任型となります。

逆に、ベンダが要件定義書を作成する場合、その業務は、要件定義書の完成を目的とした、請負型の業務となります。

これをまとめると、以下のとおりです。

要件定義書はユーザ・ベンダの双方が合意して確定する

ユーザ・ベンダのいずれが要件定義書を作成した場合、双方が合意することで要件定義書の内容は確定します。

このため、要件定義書が作成された場合、ユーザとベンダは、それぞれが内容を確認します。

その結果、要件定義書の記載に異議がある場合は、協議を重ねて、合意に至るまで、要件定義書の修正を繰り返します。

最終的に内容が確定した場合、それぞれの責任者（プロジェクトマネージャー）が記名押印をして、要件定義書を確定させます。

なお、記名押印をするということは、要件定義書が、一種の契約書であることを意味します。

【重要な契約条項15】外部設計（基本設計）

外部設計（基本設計）＝ユーザの目に見える設計

「外部設計（基本設計）」の条項では、外部設計の「内容」の決定について規定します。

外部設計（基本設計）とは、要件定義をもとづいた、人間が識別できるシステム等の設計です。

具体的には、実際に画面に映る画像、操作方法、インターフェイスなど、視覚的に認識できるものを設計します。

また、何をどのようにインプットすれば、何がアウトプットされてくるのか、といった、一連の流れについても設計します。

外部設計（基本設計）はユーザ・ベンダのいずれかが主導する

外部設計（基本設計）は、ユーザ・ベンダのいずれかが主導して決定します。

ユーザが主導して外部設計（基本設計）をする場合、ベンダは、その支援するように規定します。

逆に、ベンダが主導して外部設計（基本設計）をする場合、ユーザは、ベンダの外部設計に協力するように規定します。

そして、最終的な外部設計（基本設計）は、外部設計書（基本設計書）を作成することにより、確定します。

【重要な契約条項16】外部設計書（基本設計書）の作成・確定

外部設計（基本設計）の決定の工程で主導した当事者が引き続き主導する

「外部設計書（基本設計書）の作成・確定」の条項では、「外部設計（基本設計）」の条項によって決定した外部設計（基本設計）の「内容」を記載した外部設計書（基本設計書）を作成し、確定させる旨を規定します。

こちらも、外部設計（基本設計）の決定と同様に、ユーザ・ベンダのいずれかが主導して作成します。

通常、外部設計（基本設計）の決定の工程を主導した当事者が、引き続き、外部設計書（基本設計書）を作成します。

逆に、外部設計（基本設計）の決定の工程と外部設計書（基本設計書）の作成の工程とで、主導する契約当事者が別々になることは、滅多にありません。

ユーザ主導＝準委任型・ベンダ主導＝請負型

なお、外部設計（基本設計）の決定の工程と、外部設計書（基本設計書）の作成の工程の契約形態は、ユーザ・ベンダのどちらが主導するかによって、次のとおりです。

外部設計も、要件定義と同様に、ユーザにIT関係の専門部署がある大手企業の場合は、ユーザが主導して決めることができます。

他方、ユーザにIT関係の専門部署がない場合は、ベンダが主導して決めることがほとんどです。

外部設計書（基本設計書）はユーザ・ベンダの双方が合意して確定する

外部設計書（基本設計書）は、要件定義書と同様に、双方が合意することで確定します。

このため、外部設計書（基本設計書）が作成された場合、ユーザとベンダは、それぞれが内容を確認します。

その結果、外部設計書（基本設計書）の記載に異議がある場合は、協議を重ねて、合意に至るまで、外部設計書（基本設計書）の修正を繰り返します。

最終的に内容が確定した場合、それぞれの責任者（プロジェクトマネージャー）が記名押印をして、外部設計書（基本設計書）を確定させます。

なお、記名押印をするということは、外部設計書（基本設計書）が、一種の契約書であることを意味します。

【重要な契約条項17】内部設計（コーディング・プログラミング業務）

内部設計（コーディング・プログラミング業務のこと）の条項では、確定した外部設計（基本設計）にもとづき、ベンダが実際に開発をおこなう旨を規定します。

ベンダがコーディング・プログラミングをするのは当然のことですから、そのこと自体を規定することは、特に重要ではありません。

この条項において重要な点は、コーディング・プログラミングの業務が、請負型なのか準委任型なのか、という点です。

これは、システム等開発業務委託契約の契約条項のうち、最も重要な内容のひとつです。

【重要な契約条項18】納入

納入＝成果物（有体物・無体物）の引渡し

「納入」の条項では、コーディング・プログラミングの業務が請負型の場合に、ベンダによる成果物の納入について規定します。

請負型のシステム等開発業務委託契約では、ベンダは、ユーザに対し、完成した成果物を引渡します。

ここでいう成果物とは、電子データのような形がないもの（＝無体物）と、書類、CD-R、DVD-R等の記録媒体のような形があるもの（＝有体物）があります。

有体物だけではなく、無体物の成果物であったとしても、その引渡しについては、慣例的に、「納入」と表現します（＝いわゆる実装の工程とは別物です）。

なお、個別具体的な納入期限または納入期日（＝納期）、納入方法、納入場所等については、個別契約で規定します。

納入期日と納入期限は別物

個別契約で納期を設定する場合、必ず納入期限なのか、それとも納入期日なのかを明記します。

納入期限と納入期日は、文字どおり、「期限」なのか「期日」なのかの違いがあります。

成果物の性質によって、「早ければ早いほど良い」ものもあれば、ユーザの受入体制の整備の関係で、「早く納入されるとむしろ困る」ものもあります。

このため、納期を設定する際は、ユーザの受入体制を考慮して、納入期限とするのか、納入期日とするのかを検討します。

電子データの納入方法について詳細に規定する

データ量が少なければ電子メール・サーバへのアップロード等のオンラインで送信する

納入方法を規定する場合、特に重要となるのが、電子データ（無体物）の納入方法です。

製造請負契約や売買契約における物体＝有体物の納入とは違って、電子データは形がない＝無体物ですので、様々な方法での納入が可能です。

データ量が少ない場合は、メールに添付したうえでの送信、サーバへのアップロードで納入できる場合があります。

また、多少データ量が多くても、そうしたデータを送信できるウェブサービスなどもあります。

データ量が多い場合はオンライン以外の方法を検討する

ただ、データ量がかなり多かったり、セキュリティの関係で、このような納入ができない場合があります。

このような場合は、それこそ記録媒体（外付けハードディスクなど）に記録したものを物理的に納入することもあります。

また、ベンダがGitHubのようなオンラインのプラットフォームで開発する場合や、ノーコード・ローコードのツールを使って開発する場合は、そもそも納入の必要がないこともあります。

このように、単に「納入方法」といっても、電子データの納入方法は様々ですので、どのような方法で納入するのかを明記することは、非常に重要です。

この他、システム等開発業務委託契約における納入や下請法に関する問題の解説につきましては、詳しくは、以下のページをご覧ください。

システム等開発業務委託契約における納入のポイントは？下請法の注意点は？

下請法の適用対象の場合は三条書面の必須記載事項

なお、システム等開発業務委託契約が下請法の適用対象となる場合、納入に関する条項としては、以下のものが三条書面の必須記載事項となります。

このほか、三条書面につきましては、詳しくは、以下のページをご覧ください。

下請法の三条書面とは？12の法定記載事項や契約書との違いは？

【重要な契約条項19】検査仕様（検査項目・検査方法・検査基準）

検査仕様（検査項目・検査方法・検査基準）が決まっていないとユーザの主観で判断される

「検査仕様」の条項では、納入された成果物に関する、検査項目・検査方法・検査基準を規定します。

システム等開発業務委託契約では、納入された成果物が要件定義を満たしているかどうか、つまり、検査に合格したかどうかを巡って、トラブルになることがよくあります。

これは、客観的な検査仕様（検査項目・検査方法・検査基準）が決まっていない、あるいは、検査方法が曖昧であるために起こるトラブルです。

こうした検査仕様（検査項目・検査方法・検査基準）が決まっていないと、ユーザの主観的な価値判断によって、成果物の合格・不合格が判断されます。

必ず事前に客観的な検査仕様（検査項目・検査方法・検査基準）を決めておく

このため、客観的な検査仕様（検査項目・検査方法・検査基準）を決めておくことが重要となります。

ここでいう「客観的な」とは、委託者・ユーザの主観が入る余地がない、という意味です。

なお、検査仕様（検査項目・検査方法・検査基準）は、成果物の検査の前、できれば納入の前までに、事前に決めておきます。

これは、委託者・ユーザが恣意的に検査仕様（検査項目・検査方法・検査基準）を決めることを防止するためです。

検査仕様書はユーザ主導で作成する

具体的な検査仕様（検査項目・検査方法・検査基準）は、ユーザが主導し、ベンダと協議のうえ決定します。

また、決定した検査仕様（検査項目・検査方法・検査基準）は、ユーザがまとめて検査仕様書を作成します。

そのうえで、要件定義書や外部設計書と同様に、検査を経て、それぞれの責任者が記名押印のうえ、相互に取交します。

この場合、ベンダは、契約の内容次第で、何もしなくてもいい場合もありますし、ユーザから支援を求められる場合もあります。

もっとも、ベンダとしては、ユーザが恣意的な検査仕様（検査項目・検査方法・検査基準）を設定しないように、何らかの形で関与するべきです。

【重要な契約条項20】検査の実施

検査結果が不合格の場合は修正後再検査

「検査の実施」の条項では、ユーザによる検査の実施について規定します。

検査結果が合格の場合は、コーディング・プログラミングの業務は完了とします。

また、検査結果が不合格の場合は、その不合格となった部分について、ベンダは修正をします。

そのうえで、再度納入と検査があり、その後、合格まで同様の流れになります。

検査仕様（検査項目・検査方法・検査基準）が明確であればトラブルにならない

システム等開発業務委託契約では、よく成果物の検査結果が合格か、不合格かを巡って、ユーザとベンダの間で意見が対立します。

これは、すでに触れた、検査仕様（検査項目・検査方法・検査基準）が不明確だからこそ生じるトラブルです。

こうしたトラブルを防止するためにも、検査仕様（検査項目・検査方法・検査基準）は、なるべく客観的かつ明確にしておくべきです。

なお、下請法が適用されるシステム等開発業務委託契約において、ユーザが恣意的に厳しい検査基準を設定した場合は、「受領拒否」、「返品」「不当な給付内容の変更及び不当なやり直し」に該当する可能性があるため、注意が必要です（下請代金支払遅延等防止法に関する運用基準第4 1（2）（イ）、第4 4（2）イ、第4 4 4-3、第4 8（3）ウ、第4 8 8-3）。

検査期間・検査期限を明記する

また、「検査の実施」条項には、検査の期限を設定します。この検査期限の設定は、特にベンダの立場の場合は重要な規定です。

というのも、成果物の納入があっても、いつまでたってもユーザが検査しないことがあります。

その結果、納入された成果物が合格なのか不合格なのかがわからない、という状態が続くことがあります。

この点について、検査期限を設定することで、ユーザがいつまでも検査をしない、ということを予防できます。

検査期限までに検査しなければどうなるのかも規定する

ただし、検査期限は、単に設定するだけでは意味がありません。

検査期限は、その期限を過ぎても検査がされない場合はどうなるのか、という効果を規定します。

より具体的には、ベンダの立場としては、検査期限を過ぎた場合は、納入された成果物は自動的に検査に合格したものとみなすこととします。

こうすることで、ユーザが検査を怠った場合でも、特に問題とはなりません。

「検査期限経過＝みなし合格」とする場合のユーザの注意点

逆に、ユーザの立場としては、こうした「検査期限経過＝みなし合格」という検査期限の条項が設定された場合は、注意が必要です。

このような条項は、どんな事情があるにせよ、検査期限を過ぎてしまえば、納入された成果物が検査に合格したものとみなされてしまいます。

このため、検査期限経過＝みなし合格とはせずに、可能であれば、検査期限経過＝みなし不合格とします。

もっとも、これではベンダが納得しないでしょう。

このため、検査期限を長めに設定する、検査期限を延長できる手続を規定する、というような対応も検討するべきです。

検査のスケジュールは三条書面の記載事項

下請法が適用されるシステム等開発業務委託契約では、ユーザが成果物の検査をする場合は、「検査を完了する期日」が、三条書面の必須記載事項となっています。

ですから、検査があるにもかかわらず、三条書面≒個別契約書を作成した際に「検査を完了する期日」を記載しない場合は、下請法違反となります。

このため、ユーザは、検査そのものの実施を規定しているにもかかわらず、検査のスケジュールを規定しないことにより、検査を引き伸ばす、ということはできません。

なお、三条書面につきましては、詳しくは、以下のページをご覧ください。

下請法の三条書面とは？12の法定記載事項や契約書との違いは？

【重要な契約条項21】契約不適合責任・善管注意義務

請負型のシステム等開発業務委託契約における契約不適合責任とは？

請負型のシステム等開発業務委託契約では契約不適合責任を規定する

コーディング・プログラミングの業務が請負型のシステム等開発業務委託契約では、「契約不適合責任」の条項を規定します。

「契約不適合責任」の条項は、成果物に欠陥（＝契約不適合）があった場合における、ベンダの責任について規定します。

システム等開発業務委託契約では、一般的に、検査に合格した後に発覚した成果物の欠陥＝契約不適合について、ベンダが、期限を区切って契約不適合責任を負います。

契約不適合責任は無償でのバグ対応のみ

一般的な請負型の業務委託契約において、検査合格後に請負人（受託者）が負う契約不適合責任には、大きく分けて、以下の4種類があります。

ただ、システム等開発業務委託契約では、通常は、金銭による損害賠償は免責とすることが多く、ベンダの対応は、無償でのバグ対応のみとすることが多いです。

というのも、システム等開発業務委託契約で開発されるシステム等は、バグの内容によっては、膨大な損害が発生する可能性があります。

そういった損害までベンダに負担させるのは、非現実的なため、損害について免責とするか、上限を設定することが多いです。

契約不適合責任の期間を設定する

受託者・ベンダが契約不適合責任を負う期間は、民法上は、委託者・ユーザが契約不適合を「知った時から1年」とされています。

このため、委託者・ユーザが契約不適合を知らないままであれば、消滅時効となる、「目的物の引渡しまたは仕事の完成の時点から10年後」まで契約不適合責任が存在することとなります。

ただ、当事者の合意があれば、契約不適合責任の期間は、自由に変えることができます。

このため、一般的なシステム等開発業務委託契約では、契約不適合責任を民法の期間＝「知った時から10年」とは異なるを設定します。

契約不適合責任の期間の起算点を規定する

なお、契約不適合責任の規定では、契約不適合責任の期間の起算点、つまり、どの時点から契約不適合責任が発生するのか明らかにします。

具体的には、納入があった日や、検査に合格した日のいずれかが考えられます。

契約不適合責任の請求の手続きを明記する

また、契約不適合責任の条項では、ユーザによる契約不適合責任の請求の手続きも明記します。

具体的には、ユーザが、契約不適合責任の期間内にベンダに対して何をしなければいけないのか、ということを明記します。

典型的な例では、契約不適合があることを通知する、という規定があります。

また、このような通知だけでは足りず、契約不適合責任の請求も必要とする、という規定もできます。

このほか、契約不適合責任につきましては、詳しくは、以下のページをご覧ください。

【改正民法対応】業務委託契約における契約不適合責任とは？「知った時から1年」の修正方法は？

準委任型のシステム等開発業務委託契約における善管注意義務とは？

コーディング・プログラミングの業務が準委任型のシステム等開発業務委託契約では、「善管注意義務」の条項を規定します。

もっとも、善管注意義務自体は、準委任契約では、民法上、当然にベンダに課される義務です。

このため、契約形態をハッキリと「準委任契約」である旨が規定されていれば、あえて善管注意義務そのものをシステム等開発業務委託契約に規定する必要はありません。

なお、ベンダの立場としては、準委任型のシステム等開発業務委託契約で善管注意義務がないからといって、善管注意義務が免責されるわけではありませんので、注意が必要です。

このほか、善管注意義務につきましては、詳しくは、以下のページをご覧ください。

準委任型業務委託契約における善管注意義務とは？定義・具体例と5つのポイントもわかりやすく解説

【重要な契約条項22】運用準備・移行支援

規模が大きなシステム等では必須

「運用準備・移行支援」の条項では、成果物であるシステム等の運用・移行についての業務について規定します。

作成された成果物が、ごく簡単なソフトウェア・プログラム・システム・アプリである場合は、単に納入するだけ、あるいは実装するだけで運用できる場合もあります。

しかし、規模が大きなシステム等となれば、その運用準備・移行支援まで、ベンダが関わる必要が出てきます。

こうした案件の場合、ベンダによる、システム等の運用準備・移行支援についても、システム等開発業務委託契約の業務の一部として規定します。

なお、個別具体的な業務内容については、個別契約で規定します。

契約形態は外部設計（基本設計）に合わせる

運用準備・移行支援の業務に関する契約形態は、外部設計（基本設計）の業務の契約形態と同じものにします。

これは、品質保証の観点では、外部設計（基本設計）をおこなった当事者が、運用準備・移行支援を主導しておこなうべき、という考え方にもとづきます。

このため、ユーザ主導の外部設計（基本設計）・運用準備・移行の場合は、ベンダの業務は、あくまでその支援（＝準委任型）にとどまります。

逆に、ベンダ主導の外部設計（基本設計）・運用準備・移行の場合は、ベンダが運用準備・移行まで責任をもって完了させます（＝請負型）。

【重要な契約条項23】契約内容・仕様等の変更

「契約内容・仕様等の変更」の条項では、契約内容や仕様等に変更があった場合の対応について規定します。

もっとも、規定できる内容は、せいぜい、ユーザとベンダが協議により合意した場合は、書面により契約内容や仕様等を変更できる、という程度のものです。

こうした内容が契約書に明記されていなくても、協議が成立した場合は、契約内容や仕様等を変更できるのは当然であり、あえて規定する意味は、ほとんどありません。

逆にいえば、こうした条項は、契約内容や仕様等の変更について、トラブルの抑止には繋がりません。

ただし、「書面により」という規定により、口頭での合意を排除できる、という程度の効果はあります。

【重要な契約条項24】変更管理手続

「変更管理手続」の条項では、契約内容・仕様等の変更、未確定事項の決定などについての手続きを規定します。

契約内容・使用等の変更をする場合や、未確定事項を決定する場合、口頭で変更・決定をしてしまうと、後に変更・決定の内容を巡ってトラブルになります。

このため、書面による変更・決定の協議の申入れや、協議が成立した場合の記名押印など、厳格な手続きを経ることで、変更・決定を確定させることが重要となります。

なお、このような変更管理手続は、あくまで協議が成立した場合のトラブルを防止するためのものです。

このような規定があるからといて、そもそも契約内容や仕様等が変更となるという、根本的な問題を抑止することはできません。

【重要な契約条項25】協議不調による契約終了

「協議不調による契約終了」の条項では、「変更管理手続」の条項での協議が不調に終わった場合の契約解除について規定します。

すでに触れた雛形・モデル契約書では、ユーザが、それまでの開発に関する報酬・料金・委託料、費用、損害を負担することにより、契約を解除できる内容となっています。

もっとも、事前に報酬・料金・委託料、費用、損害の金額や計算方法を規定するのは不可能です。

このため、ユーザは、これらの金額についてもベンダと協議をしなければなりません。

つまり、この協議が不調に終わった場合は、ユーザは契約解除ができないわけですから、この条項も、実務上は、ほとんど意味がありません。

【重要な契約条項26】資料等の提供および返還

「資料等の提供および返還」の条項では、システム等の開発に必要な資料等の提供・返還について規定します。

システム等の開発には、ユーザから提供される情報が必要不可欠となります。

このため、システム等開発業務委託契約では、ユーザに情報提供の義務を課しつつ、個別具体的な提供される情報については、個別契約で規定します。

また、ベンダは、ユーザに対して、情報の提供の請求できる権利を規定します（ただし、通常はユーザとの協議事項とします）。

【重要な契約条項27】資料等の管理

「資料等の管理」の条項では、ユーザから開示を受けた情報について、ベンダの管理について規定します。

一般的には、次のような内容を規定します。

このほか、資料等の目的外使用を禁止する場合もあります。

ただし、善管注意義務と目的外使用の禁止は、通常は秘密保持義務の内容として規定しますので、必ずしもこの条項で規定する必要はありません。

【重要な契約条項28】秘密保持義務

「秘密保持義務」の条項では、ユーザ・ベンダ双方の秘密保持義務を規定します。

すでに触れた雛形・モデル契約書では、この秘密保持義務の条項で、次のような内容を規定しています。

小規模なソフトウェア・プログラム・システム・アプリの開発であれば、この程度の項目で十分かと思います。

ただし、雛形・モデル契約書の内容では、個々の内容については修正が必要な部分があります。

また、大規模なシステム開発の案件であれば、この項目・内容では不十分です。

このため、一般的な、大規模なシステム開発の案件では、別途で、より詳細な内容の秘密保持契約を締結することが多いです。

なお、秘密保持義務につきましては、詳しくは、以下のページをご覧ください。

業務委託契約における秘密保持義務・守秘義務に関する条項のまとめ

【重要な契約条項29】成果物の所有権・危険負担の移転

「成果物の所有権・危険負担の移転」の条項では、有体物の成果物がある場合における、所有権と危険負担の移転について規定します。

システム等開発業務委託契約にける有体物の成果物は、物体そのもの（＝所有権）に価値があるわけではなく、その物体に記録されたデータ（≒著作権）に価値があります。

このため、成果物である物体そのものに価値がある、製造請負契約、建設工事請負契約、売買契約などとは違って、所有権・危険負担の移転で、ユーザとベンダが揉めることは、まずありません。

一般的には、所有権・危険負担の移転は、両者とも公平な形となる、納入の時期とすることが多いです。

このほか、所有権の移転と危険負担の移転につきましては、詳しくは、以下のページをご覧ください。

所有権の移転の時期とは？業務委託契約における成果物の取扱いを解説

【改正民法対応】危険負担の移転の時期とは？規定のしかた・書き方は？

【重要な契約条項30】著作権の権利処理

著作権の権利処理は4パターン

一般的にはユーザに全部または大半の著作権を移転させる

「著作権の権利処理」の条項では、システム等の開発によって生じたプログラム等の著作権の権利処理について規定します。

著作権の権利処理については、主に次の4パターンに分類されます。

パターン1が最もユーザにとって有利であり、下にいくに従って、ユーザにとって不利となります。

ユーザとベンダの契約交渉上の立場にもよりますが、一般的なシステム等開発業務委託契約では、パターン1かパターン2が多いです。

それぞれ、詳しく見ていきましょう。

【パターン1】ユーザにすべての著作権を移転させる

パターン1は、ユーザにすべての著作権を移転させる権利処理です。

これは、ユーザの立場が優位な場合に利用される権利処理です。

この権利処理は、非常にシンプルであり、他の方法に比べて、（ユーザにとっては）デメリットやリスクはほとんどありません。

いわゆる、「フルスクラッチ」での開発の際に採られる著作権の権利処理の方法です。

ベンダにとっては、従前から保有しているプログラムや、汎用的なプログラムの著作権まで譲渡することになるため、注意が必要です。

【パターン2】従前保有の著作権・汎用的な著作権はベンダが留保、残りの著作権はユーザに移転させる

パターン2は、原則として、著作権はユーザに移転されるものの、例外として、ベンダが従前から保有しているプログラムや、新規開発の汎用的なプログラムについては、ベンダに留保される権利処理です。

ベンダに留保された著作権については、なんらかの形で、ユーザに対し、使用許諾（ライセンス）することが多いです。

この際、ユーザによる、第三者に対する著作権の再使用許諾（サブライセンス）を認めるかどうかが重要となります。

この権利処理は、システム等開発業務委託契約では、最も一般的な権利処理です。

なお、特に使用許諾（ライセンス）がなかったとしても、ユーザは、著作権法第47条の3にもとづき、複製や翻案はできます。

著作権法第47条の3（プログラムの著作物の複製物の所有者による複製等）

1　プログラムの著作物の複製物の所有者は、自ら当該著作物を電子計算機において利用するために必要と認められる限度において、当該著作物の複製又は翻案（これにより創作した二次的著作物の複製を含む。）をすることができる。ただし、当該利用に係る複製物の使用につき、第113条第2項の規定が適用される場合は、この限りでない。

2　前項の複製物の所有者が当該複製物（同項の規定により作成された複製物を含む。）のいずれかについて滅失以外の事由により所有権を有しなくなつた後には、その者は、当該著作権者の別段の意思表示がない限り、その他の複製物を保存してはならない。

引用元:著作権法 | e-Gov法令検索

【パターン3】従前保有の著作権・汎用的な著作権はベンダが留保、残りの著作権は共有とする

パターン3は、原則として、著作権はユーザとベンダの共有として、例外として、ベンダが従前から保有しているプログラムや、新規開発の汎用的なプログラムについては、ベンダに留保される権利処理です。

この権利処理では、共有著作権の使用・利用について、あらかじめ相手方の合意する旨を規定しておきます。

また、パターン2と同様に、ベンダに留保された著作権については、なんらかの形で、ユーザに対し、使用許諾（ライセンス）することが多いです。

同じく、この際、ユーザによる、第三者に対する、著作権の再使用許諾（サブライセンス）を認めるかどうかが重要となります。

この権利処理は、著作権を共有するため、ユーザとベンダが複雑な権利関係となってしまうため、まず採用されません。

【パターン4】ベンダがすべての著作権を留保する

パターン4は、ベンダにすべての著作権を留保させる権利処理です。

ユーザは、ベンダからの著作権の使用許諾（ライセンス）を受けることにより、著作権の使用・利用ができます。

同様に、ベンダからの許諾を受けることにより、ユーザから第三者への著作権の再使用許諾（サブライセンス）もできます。

つまり、システム等の開発に関するシステム等開発業務委託契約と、その成果物である著作権のライセンス契約が、完全に分離するとなります。

このため、実務上は、ライセンス契約の部分を別途の契約とする場合があります。

この権利処理は、よほどベンダの立場が強くないと、採用されない方法です。

「著作権法第27条および第28条の権利」の譲渡も規定する

なお、著作権をユーザに移転させる場合、特約として、「著作権法第27条および第28条の権利」の移転も明記します。

著作権法第27条および第28条の権利とは、「翻訳権、翻案権等」（第27条）と「二次的著作物の利用に関する原著作者の権利」（第28条）のことです。

これらの権利は、特約がない限り、譲渡した者＝ベンダに留保されたものと推定されます（著作権法第61条第2項）。

著作権法第61条（著作権の譲渡）

1　（省略）

2　著作権を譲渡する契約において、第27条又は第28条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。

引用元:著作権法 | e-Gov法令検索

このため、ユーザに著作権を移転させる場合、特に著作権法27条と第28条の権利について言及がなければ、これらの権利は移転していないと推定されます。

ただし、「推定」であるため、仮に特約がない場合であっても、反証を挙げて覆すことはできます。

著作者人格権の不行使特約を規定する

また、ユーザの立場としては、ベンダが著作者人格権を行使しないように、著作者人格権の不行使特約を明記する必要があります。

著作者人格権や著作者人格権の不行使特約については、詳しくは、以下のページをご覧ください。

業務委託契約（請負契約）で著作権はどのように発生・帰属・譲渡・処理をする？

下請法違反に注意

著作権の権利処理は三条書面の必須記載事項

下請法が適用されるシステム等開発業務委託契約の場合、著作権の権利処理は、いわゆる「三条書面」の必須記載事項とされています。

著作権の移転・使用許諾のいずれの場合も、三条書面に記載しなければなりません。

（途中省略）また，主に，情報成果物作成委託に係る作成過程を通じて，情報成果物に関し，下請事業者の知的財産権が発生する場合において，親事業者は，情報成果物を提供させるとともに，作成の目的たる使用の範囲を超えて知的財産権を自らに譲渡・許諾させることを「下請事業者の給付の内容」とすることがある。この場合は，親事業者は，3条書面に記載する「下請事業者の給付の内容」の一部として，下請事業者が作成した情報成果物に係る知的財産権の譲渡・許諾の範囲を明確に記載する必要がある。

引用元: 下請代金支払遅延等防止法に関する運用基準第3 1（3）

このため、下請法が適用されるシステム等開発業務委託契約では、ユーザは、三条書面＝システム等開発業務委託契約書に著作権の権利処理を規定したうえで、ベンダに対し、交付しなければなりません。

三条書面につきましては、詳しくは、以下のページをご覧ください。

下請法の三条書面とは？12の法定記載事項や契約書との違いは？

下請法が適用される業務委託契約につきましては、詳しくは、以下のページをご覧ください。

下請法の対象かどうかの条件とは？資本金・業務内容（製造委託等）について解説

不当に低い報酬・料金・委託料は下請法・独占禁止法違反

また、システム等開発業務委託契約において発生した著作権の対価が無償の場合、または不当に低い場合は、独占禁止法や下請法に違反することになります。

このため、特にユーザの側は、著作権を移転させるにせよ、使用許諾とするにせよ、対価は慎重に決定するべきです。

逆にベンダのの側は、ユーザから著作権の対価を無償にされたり、不当に低い金額とされた場合は、独占禁止法違反や下請法違反を主張できます。

報酬・料金・委託料と独占禁止法・下請法の関係につきましては、詳しくは、以下のページをご覧ください。

無償・不当に低い対価の知的財産権の譲渡・使用許諾は独占禁止法違反・下請法違反

著作権法についての関連記事

この他、著作権については、関連記事が多数ありますので、詳しくは、それぞれの記事をご覧ください。

著作権・著作物・著作者人格権とは？業務委託契約との関係についても解説

業務委託契約（請負契約）で著作権はどのように発生・帰属・譲渡・処理をする？

業務委託契約における著作権の譲渡5つのポイント【買取り方式】

業務委託契約における著作権のライセンス6つのポイント【ライセンス方式】

【重要な契約条項31】特許権等の権利処理

「特許権等の権利処理」の条項では、著作権以外の知的財産権の権利処理について規定します。

ここでいう著作権以外の知的財産権とは、主に特許権と営業秘密に関する権利のことです。

この点について、すでに触れた雛形・モデル契約書では、次のような内容が規定されています。

しかし、この内容では、ノウハウ等の定義がなく、仮に営業秘密だったとしても、著作権との切り分けが難しい、という問題があります。

また、「共同」での発明等についても、何をもって「共同」とするのかの定義が不明です。

このため、雛形・モデル契約書での特許権等の権利処理はトラブルになる可能性があります。

そもそも、著作権と他の知的財産権について、権利処理のしかたを分ける必要があるのか、という点から検討し、特に分ける必要がないのであれば、著作権と同様の権利処理とするべきです。

【重要な契約条項32】ベンダによる著作権の再利用

「ベンダによる著作権の再利用」の条項では、ベンダに留保された著作権について、秘密保持義務に反しない範囲で、利用できる旨を規定します。

また、第三者に対する使用・利用の再許諾、パッケージ化した複製物の販売の許諾についても規定します（すでに触れた雛形・モデル契約書ではそのような内容になっています）。

もっとも、ユーザとしては、特に後者のパッケージ化した複製物の販売については、自社の製品と競合するリスクがあります。

このため、ユーザの立場では、パッケージ化した複製物の販売については、禁止することもあります。

【重要な契約条項33】知的財産権侵害の責任

ベンダが第三者の著作権・特許権を侵害した場合の規定

「知的財産権侵害の責任」の条項では、ベンダによる第三者の知的財産権の侵害があった場合における、ベンダの責任について規定します。

システム等開発業務委託契約では、第三者の著作権や特許権を侵害してしまう場合があります。

もちろん、意図的に侵害した場合は、ベンダには損害賠償責任が発生します。

しかし、結果的に、意図せずに侵害することもあります。

意図しない著作権・特許権の侵害の責任をベンダが負うべきか

特に特許権については、未公開のものもありますし、出願公開されたものについても、世界中のシステム等に関する特許をすべて把握するのは不可能です。

このため、一般的には、意図しない第三者の著作権・特許権の侵害については、すべてをベンダの責任とはしません。

この点について、すでに触れた雛形・モデル契約書では、次の2つのうちの、いずれかとする内容としています。

【重要な契約条項34】第三者ソフトウェア・FOSSの利用

【意味・定義】第三者ソフトウェア・FOSSとは？

「第三者ソフトウェア・FOSSの利用」の条項では、システム等の開発にあたって、第三者が権利を有するプログラム等の使用について規定します。

ここでいう第三者ソフトウェアとは、すでに存在する（主に）商用のパッケージソフトを意味します。

また、FOSSとは、フリーソフトウェアとオープンソースソフトウェアの両者を意味します。

いわゆるライブラリなどの利用についても、この規定で対応することになります。

選定主体とベンダの責任について規定する

「第三者ソフトウェア・FOSSの利用」の規定では、選定主体、つまり、ユーザとベンダのどちらが主導して選定するのかについて規定します。

ユーザが主導して第三者ソフトウェア・FOSSを選定する場合、ベンダは特に何もする必要はありません。

ベンダが主導して第三者ソフトウェア・FOSSを選定する場合、一般的には、ベンダがユーザに対して、その第三者ソフトウェア・FOSSに関する提案をするように規定します。

また、いずれの場合も、ベンダの責任は、故意または重過失がある場合に限ります。

つまり、第三者ソフトウェア・FOSSに権利侵害やバグがあることを知りながら、または知ることについて重過失がある場合は、ベンダは、その責任を負うことになります。

これらは、すでに触れた雛形・モデル契約書にも、そのように規定されています。

【重要な契約条項35】損害賠償責任

システム等の開発では膨大な損害が発生するリスクがある

「損害賠償」の条項では、システム等開発業務委託契約にもとづいて、何らかの損害が発生した場合における、損害賠償について規定します。

というよりも、実質的には、「損害賠償の制限」について規定します。

システム等の開発に起因する損害は、ときに膨大な金額になることがあります。

このため、一般的な業務委託契約のように損害賠償の金額に制限を設定しないと、ベンダに過大な負担が発生します。

この点から、一般的なシステム等開発業務委託契約では、何らかの形で、特にベンダ側の損害賠償の負担に上限を設定します。

損害賠償の金額または計算方法を規定する

このように、どのような開発形態のシステム等開発業務委託契約であれ、一般的には、損害賠償の負担について上限を設定します。

上限の設定のしかたは、具体的な金額を指定して規定する方法と、計算方法を規定する方法があります。

計算方法としては、例えば、「報酬・料金・委託料の累計の◯パーセント」のような計算方法があります。

また、準委任型の契約のように、月額固定の報酬・料金・委託料の場合は、「報酬の◯ヶ月分」のような計算方法もあります。

損害賠償の請求ができる期限を設定する

また、金額以外にも、損害賠償の請求ができる期限を設定することもあります。

つまり、損害賠償の請求ができる期限を消滅時効の期限よりも短く設定します。

これにより、契約が終了してから、相当に期間が経過した後で、突然、損害賠償の請求をされる、ということがなくなります。

これは、特にベンダの側にとっては、長期間損害賠償のリスクを抱えたまま事業を続ける、というリスクがなくなります。

損害賠償の対象となる損害の種類を限定する

この他、損害の種類を限定する方法により、さらに損害賠償の金額を制限することもできます。

代表的な例としては、次のものがあります。

故意・重過失による損害は上限から除外する

なお、いくら上限が設定されているとはいえ、故意または重過失によって損害が発生した場合は、一般的には、上限からは除外するように規定します。

すでに触れたとおり、’故意による損害は、意図的発生させられた損害のことを意味します。

また、重過失による損害は、故意と同等とみなせるレベルの著しい過失によって発生させられた損害を意味します。

このような規定がある場合、どのような損害であっても、上限が適用されるわけではありません。

このため、特にベンダの側は注意が必要です。

補足：システム等開発業務委託契約書には印紙税が発生し収入印紙が必要？

システム等開発業務委契約書は、開発モデルや契約形態によって、収入印紙・印紙税の取扱いが異なります。

これらのシステム等開発業務委託契約書の印紙税・収入印紙につきましては、詳しくは、以下のページをご覧ください。

ソフトウェア・システム・アプリ開発業務委託契約書の印紙（印紙税・収入印紙）はいくら？

印紙税の節税は電子契約サービスがおすすめ

印紙税の節税には、電子契約サービスの利用がおすすめです。

というのも、電子契約サービスは、他の方法に比べて、デメリットがほとんど無いからです。

印紙税を節税する方法は、さまざまあります。

具体的には、以下のものが考えられます。

しかし、これらの方法には、以下のデメリットがあります。

これに対し、電子契約サービスは、有料ではあるものの、その料金を上回る節税効果があり、上記のようなデメリットがありません。

このように、印紙税の節税には、電子契約サービスの利用が、最もおすすめです。

ウォーターフォール型システム等開発業務委託契約の重要な契約条項に関するよくある質問

システム等開発業務とは何ですか？

システム等開発業務委託契約とは、ソフトウェア、システム、アプリ（アプリケーションプログラム）等のプログラムの開発に関する業務委託契約のことです。

システム等開発業務委託契約では、どのような契約条項が重要となりますか？

システム等開発業務委託契約では、主に次の契約条項が重要となります。

1. 定義
2. 個別契約との関係
3. 個別契約の内容
4. 報酬・料金・委託料の支払い
5. 作業期間または納期（納入期限・納入期日）
6. 再委託
7. 協働・役割分担
8. 責任者
9. 主任担当者
10. 業務従事者
11. 連絡協議会の設置
12. プロジェクトマネジメントの責任・義務
13. 要件定義の決定
14. 要件定義書の作成・確定
15. 外部設計（基本設計）
16. 外部設計書（基本設計書）の作成・確定
17. 内部設計（コーディング・プログラミング業務）
18. 納入
19. 検査仕様（検査項目・検査方法・検査基準）
20. 検査の実施
21. 契約不適合責任・善管注意義務
22. 運用準備・移行支援
23. 契約内容・仕様等の変更
24. 変更管理手続
25. 協議不調による契約終了
26. 資料等の提供および返還
27. 資料等の管理
28. 秘密保持義務
29. 成果物の所有権・危険負担の移転
30. 著作権の権利処理
31. 特許権等の権利処理
32. ベンダによる著作権の再利用
33. 知的財産権侵害の責任
34. 第三者ソフトウェア・FOSSの利用
35. 損害賠償責任