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

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

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

他方で、アジャイル型のシステム等開発業務委託契約では、業務内容は、各スプリントの開始前にプロダクトバックログの中から選ばれ、スプリントバックログで確定させます。アジャイル開発の場合は、ウォーターフォール型の開発以上に、業務内容が変更されやすいです。
（なお、このページでは、特に言及がない場合は、スクラム開発によるアジャイル型のシステム等開発契約について解説いたします）

このように、一般的な業務委託契約とは違って、システム等開発業務委託契約は、業務内容を確定しづらい、という特徴があります。このため、業務内容そのものは当然ながら、業務内容の確定・変更の手続きもまた、重要となります。

また、取適法（旧下請法）が適用されるシステム等開発業務委託契約の場合は、取適法第4条（旧下請法第3条）により、委託者は、いわゆる「4条明示（旧3条書面）」を作成して、受託者に対して交付しなければなりません。この4条明示には、「給付の内容」として、システム等開発業務委託契約の業務内容、つまり仕様書等の内容を記載しなければなりません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ウォーターフォール開発・アジャイル開発とは？

ソフトウェア、プログラム、システム、アプリ等の開発は、主にウォーターフォール開発とアジャイル開発のいずれかの方法があります。それぞれの定義は、以下の通りです。

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

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

具体的には、ウォーターフォール型の開発の場合は、以下の業務があります。

また、アジャイル開発の場合は、以下の業務があります。

そして、一般的に、ウォーターフォール型の開発業務委託契約は請負契約、アジャイル型の開発業務委託契約は準委任契約となります。

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

なお、単なるコーディング作業を委託する契約（SES契約＝システムエンジニアリングサービス契約等）の場合は、準委任契約となります。

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

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

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

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

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

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

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

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

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

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

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

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

仕様が明確でない（＝明確にできない・明確にしないほうがメリットが多い）案件では、準委任型とすることが多いです。これは、仕様が明確でないため、ベンダ単独でのコーディング・プログラミングがしにくく、業務の実施にユーザの協力が必要なためです。

ウォーターフォール型でない開発（アジャイル型の開発業務委託契約やシステムエンジニアリングサービス契約）の場合は、コーディング・プログラミング業務を準委任型とします。

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

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

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

というよりも、ソフトウェア・プログラム・システム・アプリが完璧な形で完成することは、現実的ではなく、継続して開発や改善をしていくものです。

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

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

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

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

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

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

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

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

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

仕様書・スプリントバックログで業務内容を確定

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

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

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

すでに触れたとおり、ウォーターフォール型の開発の仕様は、大きく分けて要件定義・外部設計（基本設計）・内部設計（詳細設計）の3つに分けることができます。そして、それぞれ、要件定義書・外部設計書（基本設計書）・内部設計書（詳細設計書）に明記して定義づけます。

他方で、アジャイル型の開発の仕様は、大きく分けてプロダクトバックログ、スプリントバックログの2つに分けることができます。こちらも、何らかの記録として明記して定義づけます。特に、スプリントバックログについては、契約同様に、当事者の合意が必須となります。

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

なお、ここでいう要件定義・外部設計（基本設計）・内部設計（詳細設計）、プロダクトバックログ・スプリントバックログは、システム開発の現場の専門用語ですが、法律上の定義はありません。

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

このため、こうした用語の定義を標準化・統一化するため、独立行政法人情報処理推進機構により、「共通フレーム」（最新版は「共通フレーム2013」）が決定されています。ただ、残念ながら、必ずしも普及しているとは言いがたいのが実態です。

また、プロダクトバックログやスプリントバックログについては、一般的な定義は明確ですし、契約書においても定義づけは比較的簡単です。ただし、あまり普及していないため、特に委託者（ユーザ）の理解が重要となります。

請負型（ウォーターフォール型）システム等開発業務委託契約における業務内容の決め方

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

要件定義＝システム等を動かす仕様

要件定義とは、ユーザが要求するシステム等の機能・性能・制約条件等（いわゆる「要求仕様・要求定義」）を実現するための仕様のことです。この要件定義を書面にしたものが、要件定義書です。

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

要件定義は、ユーザが要求する内容ですので、本来はユーザが決めなければなりません。ベンダは、ユーザによる要件定義の決定にあたって、主導的な立場ではなく、支援をすることになります。

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

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

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

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

【意味・定義】外部設計書（基本設計書）とは？

外部設計（基本設計）＝ユーザの目に見える設計

外部設計（基本設計）とは、要件定義をもとづいた、人間が識別できるシステム等の設計です。この外部設計（基本設計）を書面化したものが、外部設計書（基本設計書）です。

具体的には、実際に画面に映る画像、操作方法、インターフェイスなど、視覚的に認識できるものを設計します。また、何をどのようにインプットすれば、何がアウトプットされてくるのか、といった、一連の流れについても設計します。

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

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

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

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

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

【意味・定義】内部設計書（詳細設計書）とは？

内部設計（詳細設計）＝コンピュータ・サーバ等の中の設計

内部設計（詳細設計）とは、外部設計にもとづいた、コンピュータ・サーバ等のハードウェアを動かすための設計をいいます。この内部設計（詳細設計）を書面にしたものが、内部設計書（詳細設計書）です。

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

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

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

内部設計書は、要件定義書や外部設計書とは違って、ユーザの承認は必要ではありません。というのも、コーディング・プログラミングの工程が請負契約である場合、内部設計書は、いわばベンダの「社内資料」のようなものです。

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

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

準委任型（アジャイル型）システム等開発業務委託契約における業務内容の決め方

全体の業務内容は「プロダクトバックログ」で決まる

プロダクトバックログ＝ユーザの要求事項のリスト

「プロダクトバックログ」とは、ユーザが要求するシステム等の全体に関する機能・性能・制約条件等の要求事項をリストアップし、優先順位をつけたもののことです。

アジャイル型におけるプロダクトバックログは、ウォーターフォール型の要件定義と似ています。

ただし、アジャイル型の開発では、開発を進めながら仕様を確定していくため、プロダクトバックログをあまり詳細には決めません。
（もちろん、なるべく詳細なほうが望ましいです）

これに対し、ウォーターフォール型の開発は、完成を目的とした請負契約であるため、要件定義も、なるべく完成に近づけた詳細なものとします。

詳細な業務内容は「スプリントバックログ」で決まる

スプリントバックログ＝個々のスプリントにおけるユーザの要求事項

プロダクトバックログによってリストアップされたシステム等の全体の機能・性能・制約条件等は、詳細に分割・選定をされ、個々の開発工程のタスクに落とし込まれます。

この分割された機能・性能・制約条件等とタスクを「スプリントバックログ」といい、個々の開発工程のことを「スプリント」といいます。

バックログは内容とともに確定させる手続きが重要

すでに記載したとおり、プロダクトバックログ・スプリントバックログは、内容が明確であることが重要ですが、それと同様に、確定させる手続きも重要となります。

というのも、アジャイル開発では、「開発の途中で仕様や設計の変更がある」ことが前提となります。これは、債権の要件のひとつである「確定可能性」と相反する考え方です。

委託者が要求するバックログは、委託者にとっては、受託者に対して「開発を要求できる権利」＝債権となります。よって、本来は、「確定可能性」が求められる債権の性質により、開発内容は、なるべく確定されていなければなりません。

ただ、アジャイル開発の性質上、その債権が変更されることが前提となります。このため、債権の変更にともなう「確定可能性」の確保の手続きが重要となります。

特に、アジャイル型の業務委託契約に取適法が適用される場合は、取適法第4条（旧下請法第3条）の遵守の観点からも、手続きは重要となります。

詳細につきましては、後述します。

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

ウォーターフォール型では役割分担とプロジェクトマネジメントの責任を明記する

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

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

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

具体的には、ウォーターフォール開発では、ユーザには、以下の責任・義務があります。

このように、ウォーターフォール開発であっても、ユーザとベンダが協働してシステム等を開発します。

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

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

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

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

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

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

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

システム等開発業務委託契約にプロジェクトマネジメントの義務を規定する

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

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

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

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

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

アジャイル型では役割分担とプロダクトオーナーとしての責任を明記する

アジャイル開発ではウォーターフォール開発よりもユーザの責任は重くなる

アジャイル型のシステム等開発業務委託契約では、委託者であるユーザは、いわゆる「プロダクトオーナー」に該当します。

アジャイル開発は、仕様や設計の変更が前提となる性質があるため、その変更に関するユーザ＝プロダクトオーナーの協力がなければ、開発が進みません。

つまり、あらかじめ仕様や設計が固まっているウォーターフォール開発に比べて、ユーザの責任は重くなります。

具体的には、アジャイル開発では、ユーザ＝プロダクトオーナーには、以下の責任・義務があります。

このように、アジャイル開発では、ウォーターフォール開発以上に、ユーザとそのプロダクトオーナーには、開発に関与する責任・義務が発生します。

業務委託契約において業務内容の変更手続きを規定する

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

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

ところが、システム等開発業務委託契約では、必ずしも、契約を締結する前に業務内容が確定しているとは限りません。それどころか、アジャイル開発に至っては、業務内容が確定していないことが前提となります。

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

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

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

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

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

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

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

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

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

なお、仕様変更の手続きは、あくまでトラブルとなる確率・可能性を軽減するためのものです。いわば、「言った・言わない」の水掛け論を防ぐ程度のものであり、トラブルそのものを完全に防ぐことはできません。

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

しかし、だからといって、仕様変更の手続きを規定しなくてもいい、というわけではありません。

こうしたトラブルが多いからこそ、少しでもトラブル発生の可能性・リスクを下げるために、確実に手続きを進めるべきです。

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

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

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

ただし、取適法が適用されるシステム等開発業務委託契約の場合は、契約書（いわゆる「4条明示」）を作成する必要があります。

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

以下の6パターンのいずれかに該当する場合、取適法が適用されます。

これらのうち、システム等開発業務委託契約は、パターン1、パターン2、パターン3のいずれかの場合が該当する可能性があります。

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

取適法（旧下請法）が適用される条件とは？

取適法が適用される場合はユーザに4条明示（旧3条書面）の作成義務がある

取適法が適用される場合は、ユーザ＝委託事業者（旧親事業者）ということになります。

この場合、ユーザ＝委託事業者は、4条明示にベンダ＝中小受託事業者（旧下請事業者）の「給付の内容」を記載しなければありません。

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

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

取適法4条明示（旧下請法3条書面）とは？12の法定記載事項について解説

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

その他の業務内容を決める全行程は？

この他の業務内容につきましては、以下の行程で決定し、契約書の記載することとなります。

この業務内容の決め方・書き方の全行程につきましては、詳しくは、以下のページをご覧ください。

業務委託契約書における業務内容の決め方・書き方と全行程を解説

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

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

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

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

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

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

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

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

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

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

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

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

システム・アプリ開発における業務内容に関するよくある質問

システム開発、アプリ開発等の契約では、どのように業務内容を決めるのですか？

ウォーターフォール型開発では、要件定義書、外部設計書などの、いわゆる「仕様書」等で業務内容を決めていきます。
アジャイル型開発では、プロダクトバックログでプロダクト全体の機能等を決定し、スプリントバックログで、個々のスプリントに関する業務内容を決めていきます。

システム開発、アプリ開発等の業務内容で気をつけるポイントは何ですか？

システム・アプリの開発では、開発手法にかかわらず、仕様が変更されることが非常に多いです。これは、ウォーターフォール型開発でもそうですが、特にアジャイル型開発では、仕様が変更されることが前提となります。
仕様が変更された場合に備えて契約条項を規定しておく必要があります。特に、仕様変更に伴う手続きに関する条項をしっかりと規定し、そのとおりに契約を履行することが重要となります。