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

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

ただ、システム等開発業務委託契約は、特に民法や他の法律での定義はなく、契約内容も案件によって様々です。

そのうえ、現在では、システム等の開発手法が多様化し、開発プロセスも複雑化しています。

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

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

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

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

システム・アプリ開発業務委託契約における業務内容の決め方・書き方とは?

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

業務委託契約書とは?書き方・注意点についてわかりやすく解説




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

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

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

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

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

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

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

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

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

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

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

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

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

システム等開発業務委託契約の重要なポイント
  • 業務内容は何か(何から初めて何をもって終わりにするのか)、という点。
  • 個々の業務を契約当事者(ユーザとベンダ、親事業者と下請事業者など)のどちらが担当するのか、という点。
  • 契約の目的がシステム等の完成を目的としたウォーターフォール型開発の請負契約なのか、それとも必ずしもシステム等の完成を保証しないアジャイル型開発の準委任契約なのか、という点。
ポイント
  • システム等開発業務委託契約は、ソフトウェア・システム・アプリの開発のために、何らかのコーディング・プログラミング業務がある契約。





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

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

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

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

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

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

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

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

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

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

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

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

請負契約とは?委任契約や業務委託契約との違いは?

委任契約・準委任契約とは?請負契約や業務委託契約との違いは?

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

請負契約と(準)委任契約の14の違い

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

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

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

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

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

【意味・定義】ウォーターフォール開発とは?

ウォーターフォール開発とは、開発の前に使用や設計を確定させ、原則として開発の途中でこれら変更せず、分割された工程ごとに作業を完了し、落ちた水のように前の工程には戻らずに開発する手法をいう。契約形態は、主に請負契約となる。

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

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

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

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

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

【意味・定義】アジャイル開発とは?

アジャイル開発とは、「開発の途中で仕様や設計の変更があるとの前提に立って、最初から厳密な仕様を決めずにおおよその仕様だけで開発に着手し、小単位での『実装→テスト実行』を繰り返しながら、徐々に開発を進めていく手法を指す。」契約形態は、主に準委任契約となる。

システムエンジニアリングサービス契約・SES契約=準委任契約

この他、純粋にコーディング・プログラミングの作業のみを提供する契約に、システムエンジニアリングサービス契約・SES契約があります。

【意味・定義】システムエンジニアリングサービス契約・SES契約とは?

システムエンジニアリングサービス契約(SES契約)とは、プログラムのコーディング・プログラミングの作業のみを提供する準委任契約型の契約をいう。

システムエンジニアリングサービス契約・SES契約は、アジャイル開発型のシステム等開発業務委託契約と同様に準委任契約です。

両者の違いは、システム等の完成を目指すかどうか、という点です。

システムエンジニアリングサービス契約・SES契約では、単にコーディング・プログラミングの作業を提供する契約です。

これに対し、アジャイル開発型のシステム等開発業務委託契約では、コーディング・プログラミングの作業に加えて、システム等の完成を目指すことを目的とした契約です。

ただし、アジャイル開発型のシステム等開発業務委託契約は、あくまで準委任契約であり請負契約ではありませんので、システム等の完成そのものを目的とはしていませんので、完成は保証されません。

ポイント
  • システム等開発業務委託契約の個々の業務は、請負型か準委任型のいずれか。
  • ウォーターフォール型のシステム等開発業務委託契約=請負型のコーディング・プログラミング業務
  • アジャイル型のシステム等開発業務委託契約=準委任型のコーディング・プログラミング業務
  • システムエンジニアリングサービス契約・SES契約=準委任型のコーディング・プログラミング業務





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

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

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

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

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

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

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

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

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

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

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

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

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

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

契約形態とは?その種類・一覧や書き方・規定のしかたについても解説

ポイント
  • システム等が「完成しない」場合を想定して、請負型にするのか、準委任型にするのかを決める。





システム等開発業務委託契約は一括契約か多段階契約のいずれか

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

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

【意味・定義】一括契約・多段階契約とは?
  • 一括契約とは、すべてのシステム等開発業務について、最初に包括的に合意する形式の契約をいう。
  • 多段階契約とは、最初にすべてのシステム等開発業務委託契約に共通して適用される基本契約を締結し、個々のシステム等開発業務(要件定義・外部設計・内部設計・コーディングなど)に関する契約は、個別契約として、その都度締結する形式の契約をいう。
この点について、ウォーターフォール型開発の場合は多段系契約、アジャイル型開発の場合は一括契約とすることが多いです。

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

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

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

アジャイル型開発のシステム等開発業務委託契約では、仕様については明確に決まっていないことを前提とします。

このため、当初の仕様(プロダクトバックログ)による契約締結の手続きこそ1回で済みますが、仕様確定や仕様変更の手続き(スプリントバックログの作成)は、その都度おこなうこととなります。

なお、下請法が適用される場合は、この手続を怠ると、親事業者であるベンダーが、いわゆる「三条書面」で業務内容を確定させる義務(下請法第3条)に違反することとなります。

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

アジャイル型開発のシステム等開発業務委託契約では、こうしたデメリットをあらかじめ織り込みつつ、仕様変更を繰り返すことを前提とした契約内容とします。

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

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

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

以上のように、非常に流動性が高いシステム等の開発や大規模なシステム等の契約としては、開発手法はウォーターフォール型開発とし、契約は多段階契約としたほうが実態に合っています。

このため、特に規模が大きいシステム等の開発の契約については、経産省や各種業界団体が作成したモデル契約書では、多段階契約を推奨しています。

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

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

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

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

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

ポイント
  • システム等開発業務委託契約には、一括契約と多段階契約の2種類がある。
  • 事務手続きのコストはあるものの、多段階契約のほうが仕様変更などのリスクは低い。
  • アジャイル型開発のシステム等開発業務委託契約では、事務手続きのコストと仕様変更をあらかじめ織り込んだ契約内容とする。
  • ウォーターフォール型開発のシステム等開発業務委託契約は、多段階契約とする。
  • トラブルを避けるために、最低限、仕様確定までの工程と、コーディング・プログラミングから先の工程は、契約を分ける。





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

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

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

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

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

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





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

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

システム等開発業務委託契約書における収入印紙・印紙税の扱い
  • ウォーターフォール型開発=契約形態が請負契約の場合:印紙税が発生し、収入印紙を貼る必要がある=2号文書
  • アジャイル型開発・システムエンジニアリングサービス契約(SES契約)=契約形態が準委任契約の場合:原則として印紙税が発生せず、収入印紙を貼る必要はない=非課税文書
  • 知的財産権の譲渡がある場合:印紙税が発生し、収入印紙を貼る必要がある=1号文書

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

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





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

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

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

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

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

印紙税を節税する方法
  1. コピーを作成する:原本を1部のみ作成し、一方の当事者のみが保有し、他方の当事者はコピーを保有する。
  2. 契約形態を変更する:節税のために準委任契約のような非課税の契約にする。
  3. 7号文書を2号文書・1号文書に変更する:取引基本契約に初回の注文書・注文請書や個別契約を綴じ込むことで7号文書から2号文書・1号文書に変える。

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

印紙税の節税のデメリット
  • コピーを作成する:契約書のコピーは、原本に比べて証拠能力が低い。
  • 契約形態を変更する:節税のために契約形態を変えるのは本末転倒であり、節税の効果以上のデメリットが発生するリスクがある。
  • 7号文書を2号文書・1号文書に変更する:7号文書よりも印紙税の金額が減ることはあるものの、結局2号文書・1号文書として課税される。

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

電子契約サービスのメリット
  1. 電子契約サービスを利用した場合、双方に証拠として電子署名がなされた契約書のデータが残るため、コピーの契約書よりも証拠能力が高い。
  2. 電子契約サービスは印紙税が発生しないため、印紙税を考慮した契約形態にする必要がない。
  3. 電子契約サービスは印紙税が発生しないため、7号文書に2号文書や1号文書を同轍する必要はなく、そもそも契約書を製本する必要すらない。

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

【PR】

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

ウォーターフォール型開発のシステム等開発業務委託契約の契約条項のポイント

ウォーターフォール型のシステム等開発業務委託契約には、次の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の契約条項のポイントについて解説

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

アジャイル型のシステム等開発業務委託契約には、次の21の重要な契約条項があります。

アジャイル型開発のシステム等開発業務委託契約の重要な契約条項
  1. 定義
  2. アジャイル開発手法
  3. 開発体制
  4. 契約形態
  5. 善管注意義務
  6. 業務内容
  7. 開発スケジュール
  8. 発注者およびプロダクトオーナーの責任および義務
  9. プロダクトバックログの確定
  10. 個々のスプリントバックログの確定
  11. 連絡協議会
  12. 第三者ソフトウェアの利用
  13. FOSSの利用
  14. 作業の終了
  15. 検査仕様(検査項目・検査方法・検査基準)
  16. 検査の実施
  17. 知的財産権の取扱い
  18. 報酬・料金・委託料の支払い
  19. 再委託
  20. 秘密保持義務
  21. 損害賠償責任





システム等開発業務委託契約に関するよくある質問

システム等開発業務委託契約では、どのような点に気をつけるべきですか?
システム等開発業務委託契約では、主に以下の点が重要となります。

  • 業務内容は何か(何から初めて何をもって終わりにするのか)、という点。
  • 個々の業務を契約当事者(ユーザとベンダ、親事業者と下請事業者など)のどちらが担当するのか、という点。
  • 契約の目的がシステム等の完成を目的としたウォーターフォール型開発の請負契約なのか、それとも必ずしもシステム等の完成を保証しないアジャイル型開発の準委任契約なのか、という点。
システム等開発業務委託契約には、どのような種類がありますか?
システム等開発業務委託契約には、以下のものがあります。

  • ウォーターフォール型のシステム等開発業務委託契約(請負契約)
  • アジャイル型のシステム等開発業務委託契約(準委任契約)
  • システムエンジニアリングサービス契約・SES契約(準委任契約型)
システム等開発業務委託契約では、システム等の完成については、どのような点に注意するべきですか?
システム等の「完成」については、以下の点が重要となります。

  • 何をもってソフトウェア・プログラム・システム・アプリの「完成」といえるのか(=仕様と検査基準・検査方法)。
  • 契約形態は、「完成」を目的とした請負契約なのか、「完成」が目的でない準委任契約なのか。
システム等開発業務委託契約では、どのような契約の締結のしかたがありますか?
システム等開発業務委託契約では、次の2種類の契約の締結のしかたがあります。

  • 一括契約:すべてのシステム等開発業務について、最初に包括的に合意する形式の契約。アジャイル型開発や小規模なウォーターフォール型開発で採用されることが多い。
  • 多段階契約:最初にすべてのシステム等開発業務委託契約に共通して適用される基本契約を締結し、個々のシステム等開発業務(要件定義・外部設計・内部設計・コーディングなど)に関する契約は、個別契約として、その都度締結する形式の契約。大規模なウォーターフォール型開発で採用されることが多い。