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

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

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

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

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

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

なお、このページでは、ウォーターフォール型の開発形態を想定した内容となります。

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

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

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

【2022年最新版】業務委託契約書とは?意味・定義・注意点についてわかりやすく解説




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

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

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

システム等開発業務委託契約は、民法では特に定義がないため、正確には、法律上の定義がある契約ではありません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【意味・定義】請負契約とは?

請負契約とは、請負人(受託者)が仕事の完成を約束し、注文者(委託者)が、その仕事の対価として、報酬を支払うことを約束する契約をいう。

【意味・定義】準委任契約とは?

準委任契約とは、委任者が、受任者に対し、法律行為でない事務をすることを委託し、受任者がこれ受託する契約をいう。

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

【改正民法対応】請負契約とは?委任契約や業務委託契約との違いは?

【改正民法対応】委任契約・準委任契約とは?請負契約や業務委託契約との違いは?

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

【改正民法対応版】請負契約と(準)委任契約の13の違い

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

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

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

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

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

準委任型のシステム等開発業務委託契約=アジャイル型

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

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

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

アジャイル型の開発の場合は、コーディング・プログラミング業務を準委任型とします。

厳密には、プロトタイプ型は、プロトタイプの開発については請負型とする考えもあります。

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

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

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

というよりも、ソフトウェア・システム・アプリがバグが存在しない状態=完璧な形で完成することは、実質的にはありません。

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

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

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

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

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

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

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

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

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

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

業務委託契約における契約形態の種類とは?契約条項の規定のしかた・書き方は?

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




ウォーターフォール型のシステム等開発業務委託契約は多段階契約とする

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

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

【意味・定義】一括契約・多段階契約とは?
  • 一括契約とは、すべてのシステム等開発業務について、最初に包括的に合意する形式の契約をいう。
  • 多段階契約とは、最初にすべてのシステム等開発業務委託契約に共通して適用される基本契約を締結し、個々のシステム等開発業務(要件定義・外部設計・内部設計・コーディングなど)に関する契約は、個別契約として、その都度締結する形式の契約をいう。
この点について、よほど規模が小さい案件でない限り、他段階契約としたほうが、契約上のトラブルの発生リスクは低くなります。

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

一括契約は、次のようなメリット・デメリットがあります。

一括契約のメリット
  • 初期の段階で、あくまで「契約上は」仕様、工数、報酬・料金・委託料の総額を確定させることができる。
  • 契約締結の手続きが1回で済む。
  • ユーザとしては、初期の報酬・料金・委託料の枠・上限を設定できる(少なくとも見込める)。
  • ベンダとしては、初期の段階ですべての業務に関する売上が確定する(少なくとも見込める)。
一括契約のデメリット
  • 初期の段階ですべての契約内容を決めるため、開発の実態と適合した契約内容とすることが困難である。
  • 開発が進むに従って、当初の想定どおりにはいかず、仕様変更、工数・費用負担が増える可能性が高い。
  • 開発が進むほど、仕様変更に必要な工数・費用負担が大きくなる。
  • ユーザとしては、1.ベンダが仕様変更に対応しない可能性がある、2.対応したとしても工数・費用負担の増加により報酬・料金・委託料の追加請求があり得る、3.他のベンダへの乗換えがしづらい。
  • ベンダとしては、1.ユーザからの仕様変更の要求がある可能性が高い、2.当初予定していたよりも工数や費用負担が増える、3.これらの対応のための報酬・料金・委託料の追加請求が認められないことがあり得る。

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

多段階契約には、次のようなメリット・デメリットがあります。

多段階契約のメリット
  • 個々の工程のつど個別契約を締結するため、開発の実態と適合した契約内容としやすい。
  • 開発が進んでも、そのつど仕様の確認・見直しがなされるため、修正の幅や手戻りが少なく、工数・費用負担が増えにくい。
  • ユーザとしては、1.仕様変更の可能性が比較的低い。2.仕様変更があったとしても、比較的しやすい、3.他のベンダへの乗換えがしやすい。
  • ベンダとしては、1.仕様変更の可能性が比較的低い。2.ユーザからの仕様変更の要求にも、比較的対応しやすい。
多段階契約のデメリット
  • 初期の段階で、すべての契約内容を確定させないため、相互に法的に拘束することができない。
  • 契約手続きが煩雑となり、事務的なコストがかかる。
  • ユーザとしては、初期の段階で、ベンダを囲込み、システム等の完成の保証を取付けることができない。
  • ベンダとしては、初期の段階で、売上の確保ができない。

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

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

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

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

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

システム等開発業務委託契約の2段階の分け方
  1. 仕様の確定=要件定義・外部設計(基本設計)・内部設計(詳細設計)までの工程の契約
  2. それ以降のコーディング・プログラミングの工程の契約

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

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




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

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

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

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

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

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




システム等開発業務委託契約の契約条項のポイント

システム等開発業務委託契約には、次の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. 損害賠償責任

こうしたシステム等開発業務委託契約のポイントにつきましては、詳しくは以下のページをご覧ください。

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