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

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

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

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

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

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

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

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

ソフトウェア・プログラム・システム・アプリ開発業務委託契約書の作成の35のポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ウォーターフォール型の業務委託契約の業務の具体例
  • 要件定義の決定
  • 外部設計(基本設計)
  • 内部設計(詳細設計)
  • コーディング・プログラミング
  • 実装
  • 運用
  • 保守・メンテナンス

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

アジャイル型の業務委託契約の業務の具体例
  • プロダクトバックログの決定
  • スプリントバックログの決定
  • 各種会議の開催
  • スクラムの実施(コーディング・プログラミング)
  • スプリントバックログの決定・スクラムの繰り返し
  • 実装
  • 運用
  • 保守・メンテナンス

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

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

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

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

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

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

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

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

請負契約とは?―当事者の権利義務・ポイントについて解説

委任契約・準委任契約とは?―当事者の権利義務・ポイントについて解説

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

契約形態とは?契約条項の規定のしかた・書き方は?

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

ウォーターフォール型=多段階契約・アジャイル型=一括契約

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

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

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

この点について、ウォーターフォール型のシステム等開発業務委託契約では、よほど規模が小さい案件でない限り、他段階契約としたほうが、契約上のトラブルの発生リスクは低くなります。

他方で、アジャイル型のシステム等開発業務委託契約やシステムエンジニアリングサービス契約の場合は、一括契約とします。

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

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

一括契約のメリット
  • 初期の段階で、あくまで「契約上は」仕様、仕様の決め方、工数、報酬・料金・委託料の総額を確定させることができる。
  • 契約締結の手続きが1回で済む。
  • ユーザとしては、初期の報酬・料金・委託料の枠・上限を設定できる(少なくとも見込める)。
  • ベンダとしては、初期の段階ですべての業務に関する売上が確定する(少なくとも見込める)。
一括契約のデメリット
  • 初期の段階ですべての契約内容を決めるため、開発の実態と適合した契約内容とすることが困難である。
  • 開発が進むに従って、当初の想定どおりにはいかず、仕様変更、工数・費用負担が増える可能性が高い。
  • 開発が進むほど、仕様変更に必要な工数・費用負担が大きくなる。
  • ユーザとしては、1.ベンダが仕様変更に対応しない可能性がある、2.対応したとしても工数・費用負担の増加により報酬・料金・委託料の追加請求があり得る、3.他のベンダへの乗換えがしづらい。
  • ベンダとしては、1.ユーザからの仕様変更の要求がある可能性が高い、2.当初予定していたよりも工数や費用負担が増える、3.これらの対応のための報酬・料金・委託料の追加請求が認められないことがあり得る。
多段階契約のメリット
  • 個々の工程のつど個別契約を締結するため、開発の実態と適合した契約内容としやすい。
  • 開発が進んでも、そのつど仕様の確認・見直しがなされるため、修正の幅や手戻りが少なく、工数・費用負担が増えにくい。
  • ユーザとしては、1.仕様変更の可能性が比較的低い。2.仕様変更があったとしても、比較的しやすい、3.他のベンダへの乗換えがしやすい。
  • ベンダとしては、1.仕様変更の可能性が比較的低い。2.ユーザからの仕様変更の要求にも、比較的対応しやすい。
多段階契約のデメリット
  • 初期の段階で、すべての契約内容を確定させないため、相互に法的に拘束することができない。
  • 契約手続きが煩雑となり、事務的なコストがかかる。
  • ユーザとしては、初期の段階で、ベンダを囲込み、システム等の完成の保証を取付けることができない。
  • ベンダとしては、初期の段階で、売上の確保ができない。

ウォーターフォール型は多段階契約のほうが実態に適合する

以上のように、流動性が高いウォーターフォール型のシステム等開発業務委託契約としては、多段階契約のほうが実態に合っています。

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

アジャイル型は一括契約だが契約履行中の手続きが重要

他方で、ウォーターフォール型よりもさらに流動性が高いアジャイル型のシステム等開発業務委託契約としては、契約は一括契約とします。

ただし、これは、あくまで厳格な手続きによって業務内容をリアルタイムで確定させることで、一括契約のデメリットを解消することが前提となります。

つまり、アジャイル型のシステム等開発業務委託契約は、一括契約であるため、契約成立までの手続きは簡単ですが、契約履行中の手続きが煩雑となります。この契約履行中の手続き(特にスプリントバックログの確定)を怠ると、業務内容が曖昧になり、トラブルの原因となります。

ポイント
  • システム等開発業務委託契約には、一括契約と多段階契約の2種類がある。
  • ウォーターフォール型の開発の場合は、事務手続きのコストはあるものの、多段階契約のほうが仕様変更などのリスクは低い。
  • アジャイル型の開発の場合は、契約の履行中に厳格な手続きで業務内容を確定させることを前提とした一括契約とする。

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

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

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

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

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

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

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

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

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

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

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

ポイント
  • ウォーターフォール型のシステム等開発業務委託契約では、仕様=要件定義、外部設計(基本設計)、内部設計(詳細設計)。
  • ただし、用語の定義は、組織それぞれ、人それぞれであり、用語の定義や解釈の違いが、しばしばトラブルの原因となる。
  • アジャイル型のシステム等開発業務委託契約では、仕様=プロダクトバックログ・スプリントバックログ。
  • これらの用語の定義は比較的明確だが、委託者(ユーザ)の理解が重要となる。

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

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

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

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

【意味・定義】要求仕様・要求定義とは?

要求仕様・要求定義とは、ユーザが要求するシステム等の機能・性能・制約条件等の仕様・定義をいう。

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

要件定義とは、要求仕様・要求定義をシステム等で実現するための仕様の定義をいう。

請負型(ウォーターフォール型)のシステム等開発業務委託契約では、まずは、この要件定義の決定と要件定義書の作成から始めることになります。そして、要件定義書の承認により、要件定義が確定します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【意味・定義】プロダクトバックログとは?

プロダクトバックログとは、ユーザの要求事項をリスト化して優先順位をつけたものをいう。

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

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

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

ポイント
  • プロダクトバックログとは、ユーザの要求事項をリスト化して優先順位をつけたもの。
  • プロダクトバックログは、詳細に作成されることが望ましいが、ウォーターフォール型開発の要件定義のように詳細には決定しない。

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

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

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

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

【意味・定義】スプリントバックログとは?

スプリントバックログとは、「プロダクトバックログの中から選定される、次のスプリントでの開発対象となる要求事項と、それらを実現するために必要なタスクを列挙したリストをいう。」

【意味・定義】スプリントとは?

スプリントとは、「開発業務を実施するための一定の区切られた期間をいう。」

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

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

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

【意味・定義】債権の確定可能性とは?

債権の確定可能性とは、債権の要件のひとつで、債権は確定できるものでなければならないことをいう。

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

ただ、アジャイル開発の性質上、その債権が変更されることが前提となります。このため、債権の変更にともなう「確定可能性」の確保の手続きが重要となります。特に、アジャイル型の業務委託契約が下請取引に該当する場合は、下請法第3条の遵守の観点からも、手続きは重要となります。

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

ポイント
  • スプリントバックログとは、プロダクトバックログの中から選定される、次のスプリントでの開発対象となる要求事項と、それらを実現するために必要なタスクを列挙したリストのこと。
  • スプリントとは、「開発業務を実施するための一定の区切られた期間のこと。
  • バックログは内容とともに変更の手続きが重要

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

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

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

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

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

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

ウォーターフォール型のシステム等開発業務委託契約におけるユーザの責任・義務
  • 要件定義の決定の工程における、要求仕様・機能要件の提示。
  • 外部設計(基本設計)の工程における、要求仕様・機能要件の提示。
  • ベンダのプロジェクトマネジメント(次項で解説)に対する協力義務。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アジャイル型のシステム等開発業務委託契約におけるユーザのプロダクトオーナーの責任・義務
  • スクラムチームに対してプロダクトのビジョンや意義を示し、プロダクトの価値を最大化するよう努めること
  • プロダクトバックログの作成及び優先順位の変更を行うこと
  • 出席を要する会議に出席すること
  • プロダクト(開発途中のものも含む。)に対するステークホルダー(プロダクトの利用者、出資者等の利害関係者)からのフィードバックを提供すること
  • プロダクトの完成確認及びプロダクトバックログに含まれる個々の要求事項の完了確認を行うこと
  • 開発を遂行するためにベンダが必要とする情報提供及び意思決定を適時に行うこと
  • 開発が円滑に遂行されるよう、ステークホルダーとの調整を行うこと

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

ポイント
  • システム等開発業務委託契約では、委託者であるユーザにも、報酬・料金・委託料の支払い以外の一定の責任・義務が課される。
  • ウォーターフォール型システム等開発業務委託契約では、ベンダには、プロジェクトマネジメントの義務が課される。
  • アジャイル型システム等開発業務委託契約では、ユーザやそのプロダクトオーナーに、開発に関与する責任・義務が発生する。

業務委託契約において仕様の変更手続きを契約書に明記する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェア・プログラム・システム・アプリ開発業務委託契約書の作成の35のポイント

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