こんにちは。契約書作成専門・小山内行政書士事務所代表の小山内です。

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

システム等開発業務委託契約は、一般的には、ユーザ(元請けのベンダを含みます)とベンダ(下請けのベンダも含みます)とのシステム等の開発、つまりコーディング・プログラミングの業務に関する契約とされます。

ただ、特に民法や他の法律での定義はなく、契約内容も案件によって様々です。そのうえ、現在では、システム等の開発手法が多様化し、開発プロセスも複雑化しています。

このため、システム等開発業務委託契約は、案件ごとに、コーディング・プログラミングの開発現場の実態を契約内容に反映させなければなりません。

そのうえ、契約実務の観点では、システム等開発業務委託契約は、必ずしもシステム等の完成が保証されていないため、非常にトラブルが発生しやすい、という特徴もあります。

こうした実態があるため、システム等開発業務委託契約を口約束とすることは論外であり、契約書を作成することが鉄則となります。

このページでは、こうしたシステム等開発業務委託契約のポイントや内容について、全般的に解説しています。

なお、システム等開発業務委託契約の業務内容(いわゆる「仕様」)の確定につきましては、詳しくは、以下のページをご覧ください。

ソフトウェア・プログラム・システム・アプリ開発業務委託契約における業務内容(仕様書・要件定義書)の決め方・規定のしかた・書き方とは?

また、業務委託契約の定義や基本につきましては、詳しくは、以下のページをご覧ください。

業務委託契約書とは?その定義とポイントを簡単にわかりやすく解説

スポンサードリンク

ソフトウェア・プログラム・システム・アプリ開発業務委託契約とは?

【意味・定義】ソフトウェア・プログラム・システム・アプリ開発業務委託契約とは?

ソフトウェア・プログラム・システム・アプリ開発業務委託契約とは、文字どおり、ソフトウェア・プログラム・システム・アプリの開発に関する契約です。

これらの契約は、民法では表現・規定がないため、正確には、法律上の定義がある契約ではありません。

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

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

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

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

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

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

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

システム等開発業務委託契約の業務の重要なポイント

  • 何の業務があるのか(何から初めて何をもって終わりにするのか)、という点。
  • 業務を契約当事者(ユーザとベンダ・親事業者と下請事業者など)のどちらが担当するのか、という点。
  • 業務の実施の契約形態は請負契約か準委任契約か、という点(次項で解説)。

システム等開発業務委託契約の業務は請負型と準委任型のいずれか

個々の業務は請負契約か準委任契約のいずれか

システム等開発業務委託契約は、様々な業務があります。

具体的には、要件定義の策定、外部設計(基本設計)、内部設計(詳細設計)、コーディング・プログラミング、実装、保守・メンテナンスなどです。

これらの業務に関する契約は、それぞれが個別の契約として独立したものです。

そして、一般的には、その個別の契約は、請負契約か準委任契約のいずれかです。

請負契約と準委任契約の定義は、それぞれ、次のとおりです。

請負契約と準委任契約の定義

  • 請負契約とは、請負人(受託者)が仕事の完成を約束し、注文者(委託者)が、その仕事の対価として報酬を支払うことを約束する契約。
  • 準委任契約とは、委任者が、受任者に対し、法律行為でない事務をすることを委託し、受任者がこれ受託する契約。

請負契約・準委任契約につきましては、それぞれ、詳しくは、以下のページをご覧ください。

請負契約とは?―請負型の業務委託契約のポイント・当事者の権利義務を解説

委任契約・準委任契約とは?―(準)委任型の業務委託契約のポイント・当事者の権利義務を解説

また、準委任契約と請負契約の違いにつきましては、詳しくは、以下のページをご覧ください。

【保存版】請負契約と(準)委任契約の13の違い

請負型のシステム等開発業務委託契約=ウォーターフォール型

コーディング・プログラミング業務が請負型のシステム等開発業務委託契約は、いわゆる「成果物」を完成させ、納入するタイプの契約です。

コーディング・プログラミングに入る前の工程、つまり、要件定義・外部設計・内部設計の工程によって、いわゆる「仕様」が明確な案件では、請負型とすることが多いです。

これは、仕様=どのようなコーディング・プログラミングが必要なのかが明らかであるため、ベンダが単独で業務がしやすいからです。

いわゆるウォーターフォール型の開発の場合や、比較的仕様を確定しやすい、小規模な案件の場合は、コーディング・プログラミング業務を請負型とします。

準委任型のシステム等開発業務委託契約=非ウォーターフォール型

コーディング・プログラミング業務が準委任型のシステム等開発業務委託契約は、コーディング・プログラミングの作業そのものを提供するタイプの契約です。

仕様が明確でない(=明確にできない・明確にしないほうがメリットが多い)案件では、準委任型とすることが多いです。

これは、仕様が明確でないため、ベンダ単独でのコーディング・プログラミングがしにくく、業務の実施にユーザの協力が必要なためです。

ウォーターフォール型でない開発(アジャイル型、プロトタイプ型、スパイラル型など)の場合は、コーディング・プログラミング業務を準委任型とします(厳密にはプロトタイプ型は別とする考えもあります)。

システム等開発業務委託契約では「完成の義務」が重要となる

ソフトウェア・プログラム・システム・アプリは「完成しない」

ソフトウェア・プログラム・システム・アプリは、実際に開発したとしても、必ずしも「完成する」とは限りません。

というよりも、ソフトウェア・プログラム・システム・アプリが完璧な形で完成することは、ほぼあり得ないことです。

しかも、場合によっては、開発が頓挫してしまい、多額のコストが無駄になることも、よくあります。

問題は、開発が頓挫した場合や、完成度が低い開発だった場合に、それまでに発生したコストをベンダとユーザのどちらが負担するのか、という点です。

ユーザは「未完成」「請負契約」・ベンダは「完成」「準委任契約」

実は、こうした「開発の完成」を巡るトラブルは、システム等開発業務委託契約では、よくある話で、裁判まで発展するケースが多いです。

こうした裁判では、ソフトウェア・プログラム・システム・アプリの完成度と契約形態を巡って、ユーザとベンダが、次のとおり主張します。

完成度に関するトラブル

  • ユーザの主張:ソフトウェア・プログラム・システム・アプリは要件定義のとおり完成していない。よって、報酬・料金・委託料の支払義務はない。
  • ベンダの主張:ソフトウェア・プログラム・システム・アプリは要件定義のとおり完成している。よって、報酬・料金・委託料の請求権はある。
契約形態に関するトラブル

  • ユーザの主張:契約形態は請負契約。よって、ソフトウェア・プログラム・システム・アプリが完成しないと報酬・料金・委託料は支払義務はない。
  • ベンダの主張:契約形態は準委任契約。よって、ソフトウェア・プログラム・システム・アプリが完成しなかったとしても報酬・料金・委託料の請求権がある。

以上の点から、システム等開発業務委託契約では、ソフトウェア・プログラム・システム・アプリの完成度という意味では、次の点が重要となります。

システム等開発業務委託契約での完成度のポイント

  • 何をもってソフトウェア・プログラム・システム・アプリの「完成」といえるのか(=仕様と検査基準・検査方法)。
  • 契約形態は、「完成」を目的とした請負契約なのか、「完成」が目的でない準委任契約なのか。

こうした点も踏まえた上で、コーディング・プログラミング業務に関する契約形態を請負契約とするのか、準委任契約とするのかをシステム等開発業務委託契約書に明記します。

契約形態の条項につきましては、詳しくは、次のページをご覧ください。

業務委託契約の契約形態とは?条項の規定のしかた・書き方・作り方は?

ポイント

  • システム等開発業務委託契約は、ソフトウェア・プログラム・システム・アプリの開発のために、何らかのコーディング・プログラミング業務がある契約。
  • システム等開発業務委託契約の個々の業務は、請負型か準委任型のいずれか。
  • ウォーターフォール型のシステム等開発業務委託契約=請負型のコーディング・プログラミング業務
  • 非ウォーターフォール型のシステム等開発業務委託契約=準委任型のコーディング・プログラミング業務
  • システム等が「完成しない」場合を想定して、請負型にするのか、準委任型にするのかを決める。
スポンサードリンク

システム等開発業務委託契約は原則として多段階契約とする

システム等開発業務委託契約は一括契約と多段階契約の2種類

システム等開発業務委託契約は、一括契約と多段階契約の2種類に分けることができます。

一括契約・多段階契約の定義

  • 一括契約とは、すべてのシステム等開発業務について、最初に包括的に合意する形式の契約をいう。
  • 多段階契約とは、最初にすべてのシステム等開発業務委託契約に共通して適用される基本契約を締結し、個々のシステム等開発業務(要件定義・外部設計・内部設計・コーディングなど)に関する契約は、個別契約として、その都度締結する形式の契約をいう。

この点について、よほど規模が小さい案件でない限り、他段階契約としたほうが、契約上のトラブルの発生リスクは低くなります。

一括契約・多段階契約のメリット・デメリット

一括契約・他段階契約は、それぞれ、次のようなメリット・デメリットがあります。

一括契約のメリット

  • 初期の段階で、あくまで「契約上は」仕様、工数、報酬・料金・委託料の総額を確定させることができる。
  • 契約締結の手続きが1回で済む。
  • ユーザとしては、初期の報酬・料金・委託料の枠・上限を設定できる(少なくとも見込める)。
  • ベンダとしては、初期の段階ですべての業務に関する売上が確定する(少なくとも見込める)。
一括契約のデメリット

  • 初期の段階ですべての契約内容を決めるため、開発の実態と適合した契約内容とすることが困難である。
  • 開発が進むに従って、当初の想定どおりにはいかず、仕様変更、工数・費用負担が増える可能性が高い。
  • 開発が進むほど、仕様変更に必要な工数・費用負担が大きくなる。
  • ユーザとしては、1.ベンダが仕様変更に対応しない可能性がある、2.対応したとしても工数・費用負担の増加により報酬・料金・委託料の追加請求があり得る、3.他のベンダへの乗換えがしづらい。
  • ベンダとしては、1.ユーザからの仕様変更の要求がある可能性が高い、2.当初予定していたよりも工数や費用負担が増える、3.これらの対応のための報酬・料金・委託料の追加請求が認められないことがあり得る。
多段階契約のメリット

  • 個々の工程のつど個別契約を締結するため、開発の実態と適合した契約内容としやすい。
  • 開発が進んでも、そのつど仕様の確認・見直しがなされるため、修正の幅や手戻りが少なく、工数・費用負担が増えにくい。
  • ユーザとしては、1.仕様変更の可能性が比較的低い。2.仕様変更があったとしても、比較的しやすい、3.他のベンダへの乗換えがしやすい。
  • ベンダとしては、1.仕様変更の可能性が比較的低い。2.ユーザからの仕様変更の要求にも、比較的対応しやすい。
多段階契約のデメリット

  • 初期の段階で、すべての契約内容を確定させないため、相互に法的に拘束することができない。
  • 契約手続きが煩雑となり、事務的なコストがかかる。
  • ユーザとしては、初期の段階で、ベンダを囲込み、システム等の完成の保証を取付けることができない。
  • ベンダとしては、初期の段階で、売上の確保ができない。

以上のように、非常に流動性が高いシステム等の開発の契約としては、多段階契約のほうが実態に合っています。

このため、一般的な契約実務の専門家や、経産省や各種業界団体が作成したモデル契約書では、多段階契約を推奨しています。

仕様の確定までの工程とそれ以降のコーディング・プログラミングの工程は契約を分ける

ただ、多段階契約によるシステム等の開発は、非常に手間がかかるため、規模が小さな案件では現実的ではありません。

それでも、少なくとも、次の2つの工程を別々の契約として、2段階に分けるべきです。

  1. 仕様の確定=要件定義・外部設計(基本設計)・内部設計(詳細設計)までの工程
  2. それ以降のコーディング・プログラミングの工程

このように、仕様の確定の工程とコーディング・プログラミングの工程の契約を分けることにより、仕様の変更を最小限にとどめることができます。

ポイント

  • システム等開発業務委託契約には、一括契約と多段階契約の2種類がある。
  • 事務手続きのコストはあるものの、多段階契約のほうが仕様変更などのリスクは低い。
  • よほど小規模な案件でない限り、システム等開発業務委託契約は多段階契約とする。
  • 最低限、仕様確定までの工程と、コーディング・プログラミングから先の工程は、契約を分ける。

システム等開発業務委託契約書の雛形・モデル契約書について

システム等開発業務委託契約書は、官公署や各種業界団体によって、ひな形・モデル契約書が作成されています。

一例を挙げますと、次のとおりです。

システム等開発業務委託契約書の雛形・モデル契約書

いずれもよく作り込まれている契約書ですが、契約内容の分量が多く、内容も複雑なため、使いこなすには、専門知識が必要です。

また、これらの雛形・モデル契約書は、作成されてから一定の期間が経過しているため、一部の内容につきましては、最新のものに更新する必要があります(例:「共通フレーム2007」を「共通フレーム2013」とする、など)。

なお、これらの雛形・モデル契約書を使用する場合は、実際の契約内容や開発現場の実態に合わせて、適宜修正しながら対応する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ポイント

  • システム等開発業務委託契約では、他の契約以上に、特に用語の定義が重要となる。
  • システム等の開発では、現場レベルですら用語の定義・解釈が一致していない。
  • 差し当たり、雛形・モデル契約書の定義を使うことも検討する。

【重要な契約条項2】適用範囲・個別契約との関係

「適用範囲・個別契約との関係」の条項では、適用範囲=契約の全体像と、システム等開発業務委託契約(=基本契約)と個別契約の関係について規定します。

適用範囲で契約の全体像を明記

適用範囲=契約の全体像では、システム等開発業務委託契約として、どのような業務があるのかを規定します。

システム等開発業務委託契約は、案件によって、業務の種類や分量がまったく違ってきます。

いずれの場合も、コーディング・プログラミングの業務はありますが、その他の業務(要件定義の策定、実装、保守、運用等)の業務があるかどうかは、案件によります。

このため、適用範囲の条項では、どのような業務があるのかを具体的に列挙して規定します。

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

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

この条項のポイントは以下の2点です。

「個別契約との関係」条項のポイント

  • 【ポイント1】個別契約でシステム等開発業務委託契約とは異なる内容や矛盾した内容が規定された場合、個別契約の規定を優先する。
  • 【ポイント2】書面であれ、口頭であれ、システム等開発業務委託契約書と個別契約書に規定されていない内容については、法的拘束力がないようにする。

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

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

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

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

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

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

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

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

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

(1)具体的作業内容(範囲、仕様等)

(2)契約類型(請負・準委任)

(3)作業期間又は納期

(4)作業スケジュール

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

(6)連絡協議会の運営に関する事項

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

(8)作業環境

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

(10)委託料及びその支払方法

(11)検査又は確認に関する事項

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

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

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

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

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

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

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

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

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

下請法が適用される4つの業務委託契約のパターン

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

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

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

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

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

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

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

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

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

システム等開発業務委託契約の支払期限の起算日・受領日

  • 注文品(=成果物)が委託内容の水準に達しているかどうか明らかではない場合
  • あらかじめ親事業者と下請事業者との間で、親事業者の支配下に置いた注文品の内容が一定の水準を満たしていることを確認した時点で受領とすることを合意している場合
  • ―以上の2点を満たしていれば、ユーザは、その確認の時点まで(ただし、最長で三条書面に記載した納期日まで)は、受領を留保することができる。

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

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

Q64: 受領した情報成果物に,下請事業者の責任による瑕疵等が発見され,やり直しが必要な場合にも,当初の受領日から 60 日以内に支払う必要があるか。
A: 支払期日が到来する前に瑕疵等が発見され,やり直しをさせる場合は,当初の受領日から60日以内に下請代金を支払う必要はない。この場合,やり直し後の情報成果物の受領日が支払期日の起算日となる。
ポイント

  • 下請法が適用される場合は、ユーザは、報酬・料金・委託料の支払いで下請法に違反しないよう、注意する必要がある。
  • 下請法では、支払期限を納入の日(≠検査合格の日)から60日以内に設定する必要がある。
  • 一定の条件を満たせば、納入=受領を納期まで留保することができる。この場合は、支払期限を最長で納期から60日以内に設定できる。
  • 支払期日までに下請法上、適法な「やり直し」がある場合は、ユーザは、そのやり直しの受領から60日以内の支払いとすることができる。
  • 準委任型の業務は、一定の条件を満たせば、例外的に締切計算ができる。

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

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

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

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

● 役務提供委託における支払期日の起算日

(ア)(省略)

(イ)…個々の役務が連続して提供される役務の場合には,次の要件を満たせば,月単位で設定された締切対象期間の末日に当該役務が提供されたものとする。

①  下請代金の支払は,下請事業者と協議の上,月単位で設定される締切対象期間の末日までに提供した役務に対して行われることがあらかじめ合意され,その旨が3条書面に明記されていること。 (例:支払期日欄に「毎月○日締切,翌月(翌々月)○日支払」と記載する。)

②  3条書面に,当該期間の下請代金の額(算定方法も可)が明記されていること。

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

したがって,この場合には,締切後 60 日(2か月)以内に下請代金を支払うことが認められる。

なお,個々の役務が連続して提供される期間が1か月未満の役務提供委託の場合には,当該期間の末日に役務が提供されたものとする。

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

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

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

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

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

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

業務委託契約の納期(納入期限・納入期日)・作業期間とは?条項の規定のしかた・書き方・作り方は?

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

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

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

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

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

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

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

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

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

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

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

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

【保存版】請負契約と(準)委任契約の13の違い

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

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

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

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

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

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

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

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

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

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

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

なお、すでに触れた雛形・モデル契約書では、後者の方式が一般的です。

ユーザからの「指名」がある場合を除いて再委託先の責任はベンダの責任

もっとも、ユーザの承諾の有無に関係なく、再委託先の行動によって発生した損害等の責任は、原則としてベンダが負わなければなりません。

ただし、ユーザからの「指名」があった場合は別です。

この場合は、ユーザ自身が責任を負わなければならない場合もあります。

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

業務委託契約の再委託・下請負とは?条項の規定のしかた・書き方・作り方は?

ポイント

  • 民法の原則では、準委任型=再委託不可、請負型=再委託可。
  • システム等開発業務委託契約の特約として、再委託・下請負について、民法とは異なる内容とする合意はできる。
  • 一般的なシステム等開発業務委託契約では、準委任型であっても。請負型であっても、再委託ができる内容とすることが多い。
  • 再委託ができる内容とした場合も、ユーザの承諾が必要か不要かがポイントとなる。
  • ユーザの「指名」による再委託・下請負の場合は、再委託先の行動による損害等は、ユーザの負担となる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

もっとも、個別具体的・詳細な役割分担については、個別契約で規定します。

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

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

ポイント

  • システム等開発業務委託契約では、他の業務委託契約とは違って、ユーザは、ベンダに対し協力する義務がある。
  • ユーザが協力を怠った場合、ユーザは、ベンタの責任を追求できなくなる可能性もある。

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

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

ここでいう「責任者」とは、いわゆるプロジェクトマネージャーのことです。

この条項で、わざわざプロジェクトマネージャーの権限と責任を規定するのは、当然ながら、プロジェクトマネージャーの権限と責任を明らかにするためです。

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

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

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

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

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

ここでいう「主任担当者」とは、いわゆるプロジェクトリーダーのことです。

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

プロジェクトリーダーの役割

  • 連絡確認
  • 必要な調整
  • 相手方からの要請、指示等の受理
  • 相手方への依頼
  • その他日常的な相手方との連絡、確認等

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

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

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

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

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

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

偽装請負とみなされるかどうかのポイント

  • 適法なシステム等開発業務委託契約:ベンダのプロジェクトリーダーが、自社の労働者に対して、業務の遂行方法に関する指示その他の管理をおこなう場合
  • 偽装請負:ベンダがプロジェクトリーダーを選任せず、ユーザのプロジェクトリーダー等が、ベンダの労働者に対して、業務の遂行方法に関する指示その他の管理をおこなう場合

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

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

ポイント

  • 主任担当者=プロジェクトリーダーを選任しないと偽装請負=労働者派遣法とみなされる可能性がある。
  • 現場でのユーザ・ベンダ間のコミュニケーションは、必ず主任担当者同士でおこなう。

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

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

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

業務従事者の条項の内容

  1. ベンダの業務従事者の選定は、ベンダ自身がおこなうこと。
  2. ベンダが、ベンダの労働者に関する労働法等の法令を遵守し、労働者に対し責任を負うこと。
  3. ベンダが、ベンダの労働者の指揮命令をおこなうこと。
  4. ベンダの労働者が業務の実施のためにユーザの事業所に立ち入る場合は、ベンダが、ユーザが定めた防犯・安全衛生等のルールをベンダの労働者に遵守させること。

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

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

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

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

業務従事者の条項の内容

  1. ベンダの業務従事者の選定は、ベンダ自身がおこなうこと=「労働者の配置等の決定及び変更を自ら行うこと」
  2. ベンダが、ベンダの労働者に関する労働法等の法令を遵守し、労働者に対し責任を負うこと=「労働者の服務上の規律に関する事項についての指示その他の管理を自ら行うこと」
  3. ベンダが、ベンダの労働者の指揮命令をおこなうこと=「労働者に対する業務の遂行方法に関する指示その他の管理を自ら行うこと」

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

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

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

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

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

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

連絡協議会とは?

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

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

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

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

連絡協議会の開催目的

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

連絡協議会の目的

  • 業務の進捗状況、リスクの管理及び報告のため
  • 共同作業及び各自の分担作業の実施状況、システム仕様書に盛り込むべき内容の確認のため
  • 問題点の協議及び解決のため
  • その他業務が円滑に遂行できるよう必要な事項を協議するため

連絡協議会の協議事項

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

連絡協議会の協議事項

  • 遅延事項の有無
  • 遅延事項があるときはその理由と対応策
  • 推進体制の変更(人員の交代、増減、再委託先の変更など)の要否
  • セキュリティ対策の履行状況
  • 個別契約の変更を必要とする事由の有無
  • 個別契約の変更を必要とする事由があるときはその内容などの事項

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

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

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

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

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

連絡協議会における議事録の作成のポイント

  • 作成当事者はユーザ・ベンダのどちらか(ベンダ)。
  • 記録媒体は書面か、それ以外の媒体か(書面)。
  • 議事録を作成しない当事者が議事録の内容を承認する手続きは記名押印か、それ以外の方法か(記名押印)。
  • 議事録の作成の期限は、連絡協議会が終わってから何日以内か(◯日以内)。
  • 議事録を作成しない当事者が議事録を確認する期限は、議事録を受領してから何日以内か(◯日以内)。
  • 上記の期限内に議事録について異議がない場合は、議事録は承認されたものとみなされるか、または議事録は承認されなかったとものとみなされるかどうか(議事録は承認されたものとみなされる)
  • 議事録に記載するべき内容は何か(少なくとも当該連絡協議会において決定された事項、継続検討とされた事項並びに継続検討事項がある場合は検討スケジュール及び検討を行う当事者の記載)。

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

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

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

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

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

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

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

ポイント

  • 規模が大きなシステム等開発業務委託契約では、いわゆる「打ち合わせ」も厳格な手続きのもとでおこなう。
  • 議事録の作成も厳格におこない、記名押印した書面を取交わす。
  • より小さなシステム等開発業務委託契約では、簡略化した連絡協議会を開催する。

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

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

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

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

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

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

システム等開発業務委託契約に具体的な義務を明記する

プロジェクトマネジメント義務は、わざわざシステム等開発業務委託契約書に明記する必要はありません。

というのも、一般的に、プロジェクトマネジメント義務は、システム等開発業務委託契約に付随する義務として、ベンダには当然に課されるものだからです。

ただ、すでに触れたとおり、プロジェクトマネジメント義務の具体的な内容は、案件ごとに異なります。

このため、なるべく具体的にプロジェクトマネジメントの内容を規定しておかないと、義務を果たしたかどうかを巡って、トラブルになる可能性があります。

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

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

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

ベンダによるプロジェクトマネジメントがあったとしても、ユーザからの協力がない場合は、システム等の開発がスムーズに進まず、最悪の場合、開発が頓挫することがあります。

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

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

ポイント

  • システム等開発業務委託契約では、ベンダにプロジェクトマネジメントの義務が発生する。
  • 逆に、ユーザには、ベンダのプロジェクトマネジメントに協力する義務が発生する。
  • 個別具体的なそれぞれの義務の内容は、システム等の開発の実態に応じて、個別契約で規定する。

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

要件定義=ユーザの要求

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

要件定義とは、わかりやすく言えば、ユーザが要求するシステム等の機能・性能・制約条件等のことです。

システム等開発業務委託契約では、まずは、この要件定義の決定から始めることになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

業務委託契約における善管注意義務とは?その定義と4つのポイントを解説

ポイント

  • 要件定義とは、ユーザが要求するシステム等の機能・性能・制約条件等のこと。
  • 要件定義はユーザが決めるもの。
  • ベンダはユーザによる要件定義の決定の支援をする。
  • ベンダの支援業務の契約形態は準委任型。

【重要な契約条項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】瑕疵担保責任・善管注意義務

請負型のシステム等開発業務委託契約における瑕疵担保責任とは?

請負型のシステム等開発業務委託契約では瑕疵担保責任を規定する

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

「瑕疵担保責任」の条項は、成果物に欠陥(=瑕疵)があった場合における、ベンダの責任について規定します。

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

このため、こうした検査合格後に発覚した瑕疵は、「隠れたる瑕疵」と表現されることもあります。

瑕疵担保責任は無償での瑕疵≒バグ対応のみ

一般的な請負型の業務委託契約において、検査合格後に請負人(受託者)が負う瑕疵担保責任には、大きく分けて、以下の3種類があります。

3つの瑕疵担保責任

  • 瑕疵の修補
  • 損害賠償
  • 瑕疵の修補とともに損害賠償

ただ、システム等開発業務委託契約では、通常は、損害賠償は免責とすることが多く、ベンダの対応は、無償での瑕疵の修補(≒バグ対応)となります。

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

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

瑕疵担保期間を設定する

請負人(受託者)が瑕疵担保責任を負う期間=瑕疵担保期間は、民法等の法律で決まっています。

ただ、当事者の合意があれば、その瑕疵担保期間を自由に変えることができます。

このため、一般的なシステム等開発業務委託契約では、瑕疵担保期間を民法等の法律とは別の期間を設定します。

この際、瑕疵担保期間の起算点、つまり、どの時点から瑕疵担保期間を計算するのかを明らかにします。

例えば、納入があった日や、検査に合格した日などが考えられます。

瑕疵担保責任の請求の手続きを明記する

また、瑕疵担保責任の条項では、ユーザによる瑕疵担保責任の請求の手続きも明記します。

具体的には、瑕疵担保期間内に、何をしなければいけないのか、ということも明記します。

典型的な例では、瑕疵があることを通知する、という規定があります。

また、このような通知だけでは足りず、瑕疵担保責任の請求も必要とする、という規定もできます。

このほか、瑕疵担保責任につきましては、詳しくは、以下のページをご覧ください。

業務委託契約における瑕疵担保責任とは?その意味・内容・期間は?

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

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

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

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

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

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

業務委託契約における善管注意義務とは?その定義と4つのポイントを解説

ポイント

  • 一般的な請負型のシステム等開発業務委託契約における瑕疵担保責任は、期間限定(つまり瑕疵担保期間内)の無償での瑕疵の修補のみ。
  • 金銭的な損害賠償は、全額免責か、あったとしても上限が設定された一部のみ。
  • 必ず瑕疵担保期間を設定する。
  • 瑕疵担保責任の請求手続き明記する。
  • 「準委任契約」であることが明記されていれば、必ずしも善管注意義務の記載は必要ではなく、契約書に明記がなくても、ベンダには善管注意義務は課される。

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

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

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

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

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

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

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

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

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

運用準備・移行支援

  • ユーザ主導の外部設計(基本設計)=外部設計(基本設計)が準委任型=運用準備・移行支援も準委任型
  • ベンダ主導の外部設計(基本設計)=外部設計(基本設計)が請負型=運用準備・移行支援も請負型

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

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

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

ポイント

  • 案件によっては、「検査完了=契約終了」ではなく、運用準備・移行まで契約内容・業務となることがある。
  • 運用準備・移行は、外部設計(基本設計)を主導した当事者が主導しておこなう。
  • ユーザ主導の外部設計(基本設計)=外部設計(基本設計)が準委任型=運用準備・移行支援も準委任型。
  • ベンダ主導の外部設計(基本設計)=外部設計(基本設計)が請負型=運用準備・移行支援も請負型。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

資料等の管理の内容

  • 資料等について、善良な管理者の注意をもって管理する義務(=善管注意義務)。
  • 資料等の複製・改変の取扱い(可能とするか、または禁止する)

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

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

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

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

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

モデル契約書での秘密保持義務の内容

  • 秘密情報の定義
  • 秘密情報または秘密保持義務(どちらかは必ずしも明らかではありません)の例外
  • 法令等にもとづく開示が必要な場合の秘密保持義務の例外(証券取引所等からの開示請求には対応していません)
  • 秘密情報の管理(「必要な措置を講ずる」としか規定されていません)
  • 目的外使用の禁止
  • 複製・改変の事前承諾の義務
  • 役員・従業員への情報開示の許諾および役員・従業員に対し秘密保持義務を課す義務
  • 秘密情報の提供および返却
  • 個人情報の除外
  • 残存条項

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

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

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

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

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

業務委託契約の秘密保持義務・守秘義務とは?条項の規定のしかた・書き方・作り方は?

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

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

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

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

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

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

業務委託契約の所有権の移転の時期とは?条項の規定のしかた・書き方・作り方は?

業務委託契約の危険負担の移転の時期とは?条項の規定のしかた・書き方・作り方は?

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

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

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

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

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

システム等開発業務委託契約における著作権の権利処理

  • 【パターン1】ユーザにすべての著作権を移転させる。
  • 【パターン2】従前保有の著作権・汎用的な著作権はベンダが留保、残りの著作権はユーザに移転させる。
  • 【パターン3】従前保有の著作権・汎用的な著作権はベンダが留保、残りの著作権は共有とする。
  • 【パターン4】ベンダがすべての著作権を留保する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

著作権法第61条(著作権の譲渡)

1 (省略)

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

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

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

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

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

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

業務委託契約書における著作権・著作者人格権―その帰属・使用許諾・使用制限の問題点とは?

下請法違反に注意

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

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

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

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

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

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

下請法の三条書面とは?―業務委託契約書の12の必須事項

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

下請法が適用される4つの業務委託契約のパターン

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

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

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

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

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

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

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

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

著作権・著作物・著作者人格権とは?業務委託契約との関係をわかりやすく解説

業務委託契約書における著作権・著作者人格権―その帰属・使用許諾・使用制限の問題点とは?

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

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

ポイント

  • システム等開発業務委託契約における著作権の権利処理は、主に4パターン。
  • 著作権の全部をユーザに移転させる(=パターン1)場合か、従前保有のものと汎用的なものをベンダに留保し、それ以外をユーザに移転させる(=パターン2)場合が多い。
  • 必ず「著作権法第27条および第28条の権利」の譲渡も規定する。
  • 著作者人格権の不行使特約を規定する。
  • 著作権の権利処理は下請法の三条書面の必須記載事項。
  • 不当に低い報酬・料金・委託料は下請法・独占禁止法違反。

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

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

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

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

雛形・モデル契約書における特許権等の権利処理

  • 対象となるものを「発明その他の知的財産又はノウハウ等」としている(ノウハウ等の定義は不明)。
  • 単独で発明等がおこなわれた場合は、その発明等をおこなった当事者の単独の権利となる。
  • 共同で発明等がおこなわれた場合は、権利は共有となり、持ち分は「貢献度に応じて定める」とされる(貢献度の定義は不明)。
  • ベンダが特許権等を単独保有した場合は、その特許権等については、著作権の権利処理のパターン4と同様のライセンスとする。
  • ユーザ・ベンダともに、職務発明の整備をしなければならない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第三者の知的財産権を侵害した場合のベンダの責任

  • ベンダが権利者である第三者との交渉・訴訟等を主導して、結果=損害についてはベンダがすべて負担する。
  • ユーザが権利者である第三者との交渉・訴訟等を主導して、結果=損害についてはベンダが一部=一定の上限までを負担する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

損害賠償の金額の上限を設定する

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

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

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

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

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

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

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

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

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

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

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

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

損害の種類の限定のしかた

  • 直接発生した損害=直接損害に限定し、間接的に発生した損害(二次的損害など)は対象としない。
  • 現実に発生した損害に限定し、現実に発生していない損害(逸失利益など)は対象としない。
  • 通常損害(通常予見しうる損害)に限定し、特別損害(通常予見しえない損害)は対象としない。

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

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

故意とは、文字どおり意図的に損害を発生させた場合のことを意味します。

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

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

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

ポイント

  • システム等の開発では膨大な損害が発生するリスクがある。
  • この膨大な損害のすべてをベンダの責任とするのは、ベンダにとっては過大な負担となる。
  • 一般的なシステム等開発業務委託契約では、損害賠償の金額の上限を設定することにより、ベンダの責任を限定する。
  • 同じく、損害賠償の請求ができる期限を設定することにより、ベンダの責任を限定する。
  • 損害賠償の対象となる損害の種類を限定するこにより、ベンダの責任を限定することもできる。
  • ただし、ベンダに故意または重過失があった場合は、ベンダは免責されずに、損害を負担しなければならないことが多い。