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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【PR】

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

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

ウォーターフォール型のシステム等開発業務委託契約には、次の35の重要な契約条項があります。

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

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

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

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

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

システム等開発業務委託契約では、どのような点に気をつけるべきですか？

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

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

システム等開発業務委託契約には、どのような種類がありますか？

システム等開発業務委託契約には、以下のものがあります。

• ウォーターフォール型のシステム等開発業務委託契約（請負契約）
• アジャイル型のシステム等開発業務委託契約（準委任契約）
• システムエンジニアリングサービス契約・SES契約（準委任契約型）

システム等開発業務委託契約では、システム等の完成については、どのような点に注意するべきですか？

システム等の「完成」については、以下の点が重要となります。

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

システム等開発業務委託契約では、どのような契約の締結のしかたがありますか？

システム等開発業務委託契約では、次の2種類の契約の締結のしかたがあります。

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