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

このページでは、ソフトウェア・プログラム・システム・アプリ開発業務委託契約(以下、これらを総称したものを「システム等開発業務委託契約」といいます)における業務内容の確定方法について解説しています。

システム等開発業務委託契約では、業務内容は、契約書とは別に、要件定義書、外部設計書(基本設計書)、内部設計書(詳細設計書)などの書類(以下、「仕様書等」といいます)を作成して確定させます。

実務上、これらの仕様書等は、契約を締結する前か、契約の締結後、開発のごく初期の段階で作成されることが多いです。

また、契約の性質上、仕様書等の内容が変更されることがあります。

このように、一般的な業務委託契約とは違って、システム等開発業務委託契約は、業務内容を確定しづらい、という特徴があります。

このため、業務内容そのものは当然ながら、業務内容の確定・変更の手続きもまた、重要となります。

また、下請法が適用されるシステム等開発業務委託契約の場合は、下請法第3条により、委託者は、いわゆる「三条書面」を作成して、受託者に対して交付しなければなりません。

この三条書面には、「給付の内容」として、システム等開発業務委託契約の業務内容、つまり仕様書等の内容を記載しなければなりません。

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

なお、この他の、システム等開発業務委託契約の全般的な内容につきましては、以下のページをご覧ください。

これだけは押さえておきたい!ソフトウェア・プログラム・システム・アプリ開発業務委託契約書の作成の35のポイント

スポンサードリンク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

完成度に関するトラブル

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

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

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

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

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

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

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

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

ポイント

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

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

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

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

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

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

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

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

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

一括契約のメリット

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

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

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

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

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

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

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

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

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

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

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

ポイント

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

仕様書で業務内容を確定

「仕様」を細分化して定義づける

システム等開発業務委託契約において、ユーザがベンダに対して要求する、開発されるシステム等の内容のことを、一般的に「仕様」といいます。

この仕様を実現したシステム等を開発することが、システム等開発業務委託契約における業務内容となります。

すでに触れたとおり、仕様は、大きく分けて、要件定義・外部設計(基本設計)・内部設計(詳細設計)の3つに分けることができます。

そして、それぞれ、要件定義書・外部設計書(基本設計書)・内部設計書(詳細設計書)に明記して定義づけます。

実はシステム開発の用語は定義がはっきりしていない

ここでいう要件定義・外部設計(基本設計)・内部設計(詳細設計)は、一般的な用語の使い方です。これらの用語は、法律上の定義はありません。

また、実際にこうした用語を使っている現場でも、用語の定義や解釈は、人それぞれ微妙に違っていて、しばしばトラブルやミスコミュニケーションの原因となります。

このため、こうした用語の定義を標準化・統一化するため、独立行政法人情報処理推進機構により、「共通フレーム」(最新版は「共通フレーム2013」)が決定されています。

ただ、残念ながら、必ずしも普及しているとは言いがたいのが実態です。

ポイント

  • 一般的なシステム等開発業務委託契約では、仕様=要件定義、外部設計(基本設計)、内部設計(詳細設計)。
  • ただし、用語の定義は、組織それぞれ、人それぞれであり、用語の定義や解釈の違いが、しばしばトラブルの原因となる。
スポンサードリンク

【意味・定義】要件定義書とは?

要件定義=ユーザの要求

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

この要件定義を書面にしたのが、要件定義書です。

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

そして、要件定義書の承認により、要件定義が確定します。

要件定義はユーザが決める

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

ベンダは、ユーザによる要件定義の決定にあたって、主導的な立場ではなく、支援をすることになります。

このため、要件定義を確定させる工程の個別契約では、一般的には、請負契約ではなく、準委任契約とします。

ただし、要件定義書を作成する工程の個別契約では、ユーザによって、次のように契約形態は分かれます。

要件定義書の作成の契約形態

  • ユーザが要件定義書を作成する場合:ベンダは作成の支援をする。契約形態は、準委任契約。
  • ベンダが要件定義書を作成する場合:契約形態は、要件定義の支援は準委任契約、要件定義書の作成は請負契約。

一般的に、要件定義書はユーザが作成するものとされがちですが、それは、あくまで社内にIT関係の専門部署がある、大手企業に限った話です。

ユーザが中小零細企業の場合は、そもそも要件定義書を作成すること自体ができませんので、ベンダが作成するか、またはユーザと契約した第三者のコンサルタント(いわゆる「要求エンジニア」)などに作成することが多いです。

ポイント

  • 要件定義とは、わかりやすく言えば、ユーザが要求するシステム等の機能・性能・制約条件等のこと。
  • 要件定義は、あくまでユーザが決める。ベンダはその支援をする。
  • 要件定義書は、ユーザまたはベンダのいずれかが作成する。
スポンサードリンク

【意味・定義】外部設計書(基本設計書)とは?

外部設計(基本設計)=ユーザの目に見える設計

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

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

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

この外部設計が書面にしたのが、外部設計書です。

そして、外部設計書の承認により、外部設計が確定します。

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

外部設計(基本設計)は、ユーザ・ベンダのいずれかが主導して決定します。そして、どちらが主導するのかにより、契約形態も変わってきます。

外部設計の主導と契約形態

  • ユーザの主導:ユーザが外部設計書(基本設計書)を作成する。ベンダはその支援をする。契約形態は準委任契約。
  • ベンダの主導:ベンダが外部設計書(基本設計書)を作成する。ユーザはその協力をする。契約形態は請負契約。

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

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

ポイント

  • 外部設計(基本設計)とは、要件定義をもとづいた、人間が識別できるシステム等の設計のこと。
  • 外部設計書(基本設計書)は、ユーザまたはベンダのいずれかが主導して作成する。
  • ユーザが外部設計書(基本設計書)を作成する場合は、契約形態は準委任契約。
  • ベンダが外部設計書(基本設計書)を作成する場合は、契約形態は請負契約。
スポンサードリンク

【意味・定義】内部設計書(詳細設計書)とは?

内部設計(詳細設計)=コンピュータ・サーバ等の中の設計

内部設計(詳細設計)とは、外部設計にもとづいた、コンピュータ・サーバ等のハードウェアを動かすための設計をいいます。

この後の工程が、コーディング・プログラミングの工程ですので、内部設計は、エンジニア・プログラマーがコーディング・プログラミングができる内容とする必要があります。

つまり、外部設計をコーディング・プログラミングにつなげるための橋渡し役となるのが、内部設計です。

この内部設計を書面にしたのが、内部設計書です。

ユーザによる内部設計書の承認は必要ない

内部設計書は、要件定義書や外部設計書とは違って、ユーザの承認は必要ではありません。

というのも、コーディング・プログラミングの工程が請負契約である場合、内部設計書は、いわばベンダの「社内資料」のようなものです。

請負契約は、あくまで「仕事の目的」=結果=成果物が重要なのであって、ユーザは、その仕事の過程である内部設計書までは関与するべきではありません。

他方、コーディング・プログラミングの工程が準委任契約である場合、通常は、ユーザ自身が内部設計書を作成しますので、ユーザの承認は必要になりません。

ポイント

  • 内部設計(詳細設計)とは、外部設計にもとづいた、コンピュータ・サーバ等のハードウェアを動かすための設計のこと。
  • 通常は、要件定義書や外部設計書(基本設計書)とは違って、内部設計書は、ユーザによる承認は必要ない。
スポンサードリンク

コーディング・プログラミング以外の業務内容の重要なポイント

ユーザの義務・責任も明らかにする

システム等開発業務委託契約の大きな特徴として、委託者であるユーザに、報酬・料金・委託料の支払い以外にも、一定の責任・義務が課されます。

これは、一般的な業務委託契約では、あまり見られない特徴です。

具体的には、以下のものがあります。

ユーザの責任・義務

  • 要件定義の決定の工程における、要求仕様・機能要件の提示。
  • 外部設計(基本設計)の工程における、要求仕様・機能要件の提示。
  • ベンダのプロジェクトマネジメント(次項で解説)に対する協力義務。

このように、システム等の開発では、ユーザとベンダが協働してシステム等を開発します。

このため、一般的なシステム等開発業務委託契約書では、ユーザの責任・義務が明記されていることが多いです。

また、過去の判例では、ユーザがこうした責任・義務を果たさないことによるトラブルも起きています。

プロジェクトマネジメントの義務を明記する

プロジェクトマネジメントの具体的な義務は案件ごとに異なる

プロジェクトマネジメント義務とは、文字どおり、プロジェクトのマネジメントに関する義務です。

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

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

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

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

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

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

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

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

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

要件定義が確定しないうちは開発=コーディング・プログラミングを始めてはいけない

要件定義の確定前の作業は大幅修正の原因となる

システム等開発業務委託契約ではありがちなトラブルですが、要件定義が確定しないうちから、コーディング・プログラミングの作業を始めてしまうことです。

また、よりトラブルになりやすいのはが、正式な契約の締結前にコーディング・プログラミングの作業を始めてしまうことです。

当然ながら、要件定義が確定しないうちに、また、正式な契約を締結する前に作業を始めてしまうと、後から大幅な修正が発生することがあります

この場合、その費用の負担を巡って、トラブルになります。

契約締結前に作業を始めるとユーザに「契約不成立」を主張される

また、正式なシステム等開発業務委託契約を締結する前にコーディング・プログラミングが始まると、最悪の場合、ユーザ・ベンダのどちらかが「契約は成立していない」と主張します。

特に多いパターンが、ベンダが契約締結前にコーディング・プログラミングを始めた結果、完成したシステム等がユーザに受け入れられない場合です。

こうした場合、ユーザから、報酬・料金・委託料の支払いを拒否されることもあります。

このため、特にベンダの側は、少なくとも正式な契約を締結してから、そしてなるべく仕様が確定してから、コーディング・プログラミングの作業に入るべきです。

ポイント

  • システム等開発業務委託契約では、委託者であるユーザにも、報酬・料金・委託料の支払い以外の一定の責任・義務が課される。
  • システム等開発業務委託契約では、ベンダには、プロジェクトマネジメントの義務が課される。
  • 要件定義が確定しないうちは開発=コーディング・プログラミングを始めると、開発が失敗した際に、ユーザから「契約不成立」を主張される。
スポンサードリンク

仕様の変更手続きを契約書に明記する

システム等開発業務委託契約では仕様=業務内容が変わる方が当たり前

一般的な業務委託契約では、業務内容そのものは、契約を締結する前に確定していますし、業務内容が変わることは、滅多にありません。

ところが、システム等開発業務委託契約では、必ずしも、契約を締結するまえに業務内容が確定しているとは限りません。

また、業務内容=仕様が変わらないことのほうが滅多になく、ほとんどの場合は、途中で仕様が変わります。

このため、一般的な業務委託契約とは違って、システム等開発業務委託契約では、仕様を変更する手続きが重要となります。

非ウォーターフォール型の開発では仕様変更手続きは特に重要

特に、開発手法によっては、仕様の確定とコーディング・プログラミングを平行しておこなうこともあります。

これは、非ウォーターフォール型の開発手法で採用されている方法です。

こうした開発手法では、ウォーターフォール型とは違って、そもそも「事前に仕様が確定している」ということがありません。

このため、非ウォーターフォール型のシステム等開発業務委託契約では、仕様の確定・変更の手続きは、特に重要となります。

仕様変更のつど書面で承認・合意をする

具体的な仕様変更の手続きは、一般的には、変更内容について協議を重ねて、協議の結果を書面にまとめます。

そのうえで、ユーザ・ベンダの責任者がその書面に署名押印することで、仕様変更を確定させます。

つまり、一般的な要件定義や外部設計(基本設計)の確定と、手続き自体は変わりません。

当然ながら、記録媒体自体は、必ずしも書面である必要はありません(ただし、下請法が適用される場合は別です。後述)。

内容と時間が改ざんできないものであれば、電子媒体で記録を残しておいてもかまいません。

あくまで「手続き」であるためトラブルは防げない

なお、仕様変更の手続きは、あくまでトラブルとなる確率・可能性を軽減するためのものです。

いわば、「言った・言わない」の水掛け論を防ぐ程度のものであり、トラブルそのものを完全に防ぐことはできません。

システム等開発業務委託契約でトラブルが多いのは、以下のような理由があります。

システム等開発業務委託契約にトラブルが多い理由

  • 契約内容が動的(仕様変更がよくある)であり、本来契約書が果たすべき、契約内容を静的に確定させる、という機能が発揮しづらいから。
  • 一般的な業務委託契約に比べて、報酬・料金・委託料の金額の規模も多いため、仕様変更によって大幅な追加費用が発生するから。
  • 必ずしもシステム等の開発が成功するとは限らないから。

しかし、だからといって、システム等開発業務委託契約書を作成しなくてもいい、あるいは、仕様変更の手続きを規定しなくてもいい、というわけではありません。

こうしたトラブルが多いからこそ、少しでもトラブル発生の可能性・リスクを下げるためにも、システム等開発業務委託契約書を作成するべきです。

ポイント

  • システム等開発業務委託契約では、仕様=業務内容が変わる方が当たり前。
  • システム等開発業務委託契約では、仕様=業務内容が変わることを前提に、仕様の変更手続きを明確に規定しておく。
  • 特に非ウォーターフォール型の開発手法を採用する場合は、仕様の変更手続きが重要となる。
  • 仕様の変更の際には、必ず書面を取交わす。
  • 仕様変更手続きを明記したとしても、システム等開発業務委託契約では、トラブルを防げない。だからといって、仕様変更手続きを軽視すると、トラブルの可能性は高くなる。
スポンサードリンク

下請法では業務内容を書面化する義務がある

原則としてシステム等開発業務委託契約書の作成義務はない

現行法では、システム等開発業務委託契約は、法律上の規制がないので、特に契約書を作成する必要はありません。

ただし、下請法が適用されるシステム等開発業務委託契約の場合は、契約書(いわゆる「三条書面」)を作成する必要があります。

システム等開発業務委託契約は、下請法が適用される、典型的な契約です。

システム等開発業務委託契約において、下請法が適用されるかどうかにつきましては、以下のページをご覧ください。

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

下請法が適用される場合はユーザに三条書面の作成義務がある

下請法が適用される場合は、ユーザ=親事業者ということになります。

この場合、ユーザ=親事業者は、三条書面にベンダ=下請事業者の「給付の内容」を記載しなければありません。

この「給付の内容」が、いわゆる要件定義書や外部設計書(基本設計書)になります。

なお、一定の条件を満たした場合は、電磁的方法で三条書面を交付することもできます。

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

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

ポイント

  • システム等開発業務委託契約は、典型的な下請法の規制対象の契約。
  • 下請法が適用される場合は、委託者(ユーザ、元請けのベンダ等)が親事業者となり、受託者(ベンダ、下請けのベンダ等)=下請事業者に対して、三条書面を交付する義務がある。
スポンサードリンク

システム等開発業務委託契約書は実務は極めて作成が難しい契約書

システム等開発業務委託契約書は屈指の難易度の契約書

システム等開発業務委託契約は、非常に複雑で難しい契約で、契約書を作成には、最も知識や技術が必要となります。

個人的には、システム等開発業務委託契約は、一般的な企業間契約の中では、最も作成が難しい契約書のひとつと考えています。

これには、様々な理由がありますが、特に代表的な理由は、以下の2点です。

それぞれ、簡単に見ていきましょう。

【理由1】用語の定義が決まっていない

技術上の用語の定義を規定する必要がある

システム等の開発の現場では、実は、使われている用語の定義が定まっていないことがほとんどです。

これは、企業間で用語の定義が違う、というレベルの話ではなく、同じ組織内の個人間であっても、用語の定義が違うことが当たり前です。

このような実態であるため、当然ながら、法令上の定義が決まっている用語など、ほとんどありません。

つまり、システム等開発業務委託契約書を作成する際には、ひとつひとつの用語を定義づけなければなりません。

しかも、ある意味では法令用語とは最もかけ離れた、IT関係の技術的な用語を定義づけるのですから、その作業は、非常に難しくなります。

定義・認識の違いによりミスコミュニケーションが起こりやすい

こうした定義づけ自体、非常に大変な作業ですが、ただ単に用語を定義づければいい、というわけではありません。

定義づけラてた用語は、開発の現場のレベルまで、共通認識として共有されなければなりません。

ただ、残念ながら、こうした契約書に書かれた用語の定義が、現場レベルまで浸透することは、まずありません。

このため、結局、用語の定義が統一されることはなく、用語の定義・認識の違いによって、現場レベルでミスコミュニケーションが発生しやすくなります。

【理由2】広範囲な専門知識が必要

システム等開発業務委託契約の作成には、一般的な契約に比べて、非常に広範囲な専門知識が必要となります。

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

システム等開発業務委託契約書の作成に必要な専門知識

  • 契約書作成の基本的な知識
  • 民法の知識
  • 知的財産権(特に著作権)の知識
  • 下請法・独占禁止法の知識
  • 労働者派遣法の知識(偽装請負とみなされないため)
  • システム開発全般に関する基礎的な知識

これらの幅広い知識を持つ専門家が、現場の開発の実態や契約内容をヒアリングすることによって、まともに機能するシステム等開発業務委託契約書が作成されます。

逆にいえば、こうした幅広い専門知識がある専門家が作成し、運用しなければ、システム等開発業務委託契約は、まともに機能しません。

なお、このほか、システム等開発業務委託契約書につきましては、詳しくは、以下のページをご覧ください。

これだけは押さえておきたい!ソフトウェア・プログラム・システム・アプリ開発業務委託契約書の作成の35のポイント

ポイント

  • システム等開発業務委託契約は、契約実務上、最も難しい契約のひとつ。
  • システム等開発業務委託契約では、契約書でも、現場でも、使用する用語の定義が決まっていないため、それらすべてを定義づける必要がある。
  • システム等の開発では、用語の定義・解釈を巡って、しばしばトラブルとなる。このことも、システム等開発業務委託契約の難しさの原因。
  • システム等開発業務委託契約では、広範囲の専門知識が必要。
  • 広範囲の専門知識がある専門家が作成し、運用しなければ、システム等開発業務委託契約はまともに機能しない。