Contract
モデル取引・契約書見直し検討部会
DX 対応モデル契約見直し検討 WG
～情報システム・モデル取引・契約書＜アジャイル開発版＞～
2020 年 3 月
（2021 年 10 月 6 日 更新）
独立行政法人情報処理推進機構経済産業省
〈 目 次 〉
I. はじめに | ……………… | 1 |
II. 本モデル契約が想定するアジャイル開発 | ……………… | 3 |
III. 本モデル契約の使い方 | ……………… | 3 |
IV. 本モデル契約条項解説 | ……………… | 7 |
（付録 1）ノウハウ事例 | ……………… | 59 |
（付録 2）委員名簿 | ……………… | 63 |
Ⅰ. はじめに
経済産業省は、各企業が競争力維持・強化のために新たなデジタル技術を利用してこれまでにないビジネスモデルを展開する、デジタルトランスフォーメーション（DX： Digital Transformation）を推進している1。DX 推進ガイドライン2によれば、DX は次のように定義されている：
「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」
DX の時代では、これまで以上に激しくなるビジネス環境の変化に、俊敏に対応することが求められる。そして、DX 推進の核となる IT システムでは、市場のニーズやビジネス環境の変化に迅速かつ柔軟に対応し、利用者が真に必要としている価値を提供するプロダクトをタイムリーに開発する必要がある。
そのために有用な開発手法が、利用者にとって優先度の高いものからxx開発・リリースを進め、運用時の技術評価結果や顧客の反応に基づいて素早く改善を繰り返すというアジャイル開発であり、本アジャイル開発外部委託モデル契約（以下「本モデル契約」という。）は、アジャイル開発を外部事業者に委託する際の契約の在り方について、一つの具体案を示すものである3。
まず、本モデル契約は、準委任契約を前提としている。開発対象全体の要件及び仕様を確定してから開発に進むウォーターフォール方式とは異なり、アジャイル開発では、開発プロセスの中で、開発する機能の追加・変更やその優先順位の変更が行われる。そ
1 経済産業省「産業界におけるデジタルトランスフォーメーションの推進」
xxxxx://xxx.xxxx.xx.xx/xxxxxx/xx_xxxxxx/xx/xx.xxxx
2 経済産業省 2018 年 12 月 12 日付ニュースリリース
3 IPA では、平成 22 年度「非ウォーターフォール型開発 WG 契約問題 PT」において、非ウォーターフォール型開発に適したモデル契約書を作成・公表した（平成 23 年度に改訂）。当該モデル契約書は、準委任契約のみならず請負契約も想定に入れた基本／個別契約モデルと、ベンダ企業とユーザ企業がジョイントベンチャーを構成する組合モデルの二つを含むものであった。これに対し、本モデル契約は、DX レポートにおける議論を踏まえ、より使いやすさに配慮して作成された新たな契約案であり、準委任契約を前提とするものである（従前のモデル契約との関連性はない。）。もし準委任契約ではなく、請負契約や組合契約を用いるのであれば、従前のモデル契約が参考になると思われる。
IPA 2012 年 3 月 26 日付ニュースリリースに伴う公開文書類を含むアーカイブ
xxxxx://xxx.xxx.xx.xx/xxxxxxx/xxxxxxx/xxx-xx-xx/xxxxxxx/xxx00-x.xxxx
のため、当初は開発予定となっていた機能を、ビジネス環境の変化やユーザ企業内部のニーズの変化などに応じて開発対象から外す場合もある。さらに、プロダクトを一旦リリースした後に、利用者からのフィードバック等に対応した機能追加や改善が継続的に行われることもある。こうしたアジャイル開発の特徴からすれば、あらかじめ内容が特定された成果物を予定したとおりに完成させることに対して対価を払う請負契約よりも、業務を受託したベンダ企業が専門家としての注意義務を果たしながら業務を遂行することそれ自体に対価を支払う準委任契約の方が馴染み易いと考えられる。
次に、本モデル契約では、アジャイル開発手法のうち最も普及していると思われるス クラムを前提とし、スクラムチームの構成員（プロダクトオーナー、スクラムマスター 及び開発者）の役割やバックログの作成、変更等といったアジャイル開発特有の内容に ついて規定を設けている。但し、スクラムチームが自らの特性やプロジェクトの内容に 合わせて最適な進め方を模索し、柔軟かつ自律的に改善を行うというアジャイル開発の 特徴を生かすため、具体的な開発の進め方については契約上細かい規定を置いていない。その代わり、開発の進め方の基本的な部分について、予め両当事者の認識を合致させる ことができるよう、両当事者が認識合わせを行うための資料として「アジャイルxxx め方の指針」（以下「進め方指針」という。）を用意し、それを開発の進め方の指針とし て参照することとしている。
アジャイル開発の中で生じる開発対象の変更については、開発対象の大枠の変更を行う場合には、契約内容の変更として変更管理手続の対象となり、スクラムチーム以外の責任者も含めた変更協議を行い書面で変更合意書を締結することとしている。他方、大枠を変えない程度の変更は、バックログの追加・変更というアジャイルプロセスの中で行われることになる。
また、相手方の業務従事者（プロダクトオーナー、スクラムマスター、開発者）がそ の役割を十分に果たさない場合や、スクラムチームの体制に不足がある場合など、プロ ジェクトの遂行が困難となる問題が生じ、スクラムチーム内での解消が困難な場合には、相手方に対してスクラムチーム以外の責任者も含めた問題解消のための協議を求める ことができることとし、いわばエスカレーションによる問題解消の促進を図ることとし ている。
以上のように、本モデル契約の作成に当たっては、アジャイル開発特有の概念やプロセスを契約に反映しつつも、契約で規定することによりアジャイル開発の柔軟xx自律性が損なわれないよう配慮を行った。
なお、本モデル契約を使えば、誰でも簡単にアジャイル開発の外部委託ができるというわけではない。効果的で効率的なアジャイル開発を外部委託で行うためには、プロジェクトの実施主体であり、開発するプロダクトについて責任を持つユーザ企業が、主体
的かつ積極的に開発に関与しなければならない。ユーザ企業が自らの今後のビジネスにどのようなプロダクトが必要なのか、なぜ必要なのかを十分検討し、利害関係者（ステークホルダー）と調整のうえ、開発プロセスの中でタイムリーな意思決定をしなければ、開発は期待通りには進まない。また、実際に開発を進める際には、ベンダ企業とユーザ企業の緊密な協働が必須である。相互に敬意を払い、密にコミュニケーションしながらプロダクトのビジョンを共有して開発を進めることが求められる。
アジャイル開発の外部委託を行うにあたっては、こうした点を踏まえて適切な契約のもとで開発を行うことが重要であり、そのために本モデル契約を大いに活用されたい。
Ⅱ. 本モデル契約が想定するアジャイル開発
項目 | 想定 |
ユーザ企業の準備 | 経営上のニーズや解決すべき課題（プロジェクトの目的）、開発 対象プロダクトのビジョンが明確 |
ユーザ企業の知識 | アジャイル開発及びスクラムに関する基礎的な理解あり |
契約 | 単一の準委任契約 |
開発手法 | スクラム |
開発体制 | 単一のスクラムチームであり、プロダクトオーナーはユーザ企業 が、スクラムマスターはベンダ企業がそれぞれ選任 |
開発チーム | ベンダ企業のみ、又はベンダ企業とユーザ企業の混成 |
開発規模 | 1 つのスクラムチームで開発できるような、比較的小規模なもの |
開発の進め方 | IPA「アジャイル開発の進め方」4をベースとした「アジャイル開 発 進め方指針」による |
開発プロセス | 初期開発～運用時の開発。開発に入る前にプロダクトオーナーと 開発チームの間で協議を行い、初期バックログを作成 |
開発期間 | 有期（必要に応じて延長） |
システム稼働環境 | 特に限定しない |
Ⅲ. 本モデル契約の使い方
1. 本モデル契約の構成と使い方
本モデル契約は、契約書本体と別紙、進め方指針で構成されている。
(1)契約書本体及び別紙
4 IPA「アジャイル開発の進め方」
xxxxx://xxx.xxx.xx.xx/xxxxxx/xxxxx-xxxxxxxx/xxxx-xx-xx/xxxxxxxx/xxxxx.xxxx
契約書本体は、本契約の当事者となるユーザ企業及びベンダ企業の権利義務に関す る規定を列挙しており、（一部のオプション条項を除き）個別具体的な案件の内容に 合わせて取り決める必要がある部分については、全て別紙に記載することとしている。そのため、基本的には案件に合わせて別紙の内容を記載すれば、契約書として用いる ことができる（もちろん、両当事者の意向により、契約書本体の内容を変更して用い ることもできる。）。
なお、契約書の中ではスクラムに関する用語が用いられており、これらの用語は進め方指針の中にも説明がある。
(2)進め方指針
本モデル契約では、アジャイル開発の進め方について、進め方指針を指針として参照することとしている。
アジャイル開発においては、進め方を固定してしまうのではなく、スクラムチームが自らの特性やプロジェクトの内容に合わせて最適な進め方を模索し、柔軟かつ自律的に改善を行っていくことが推奨される。また、アジャイル開発の捉え方も派生的な部分については企業によって異なり、企業ごとの創意工夫が加えられていることが想定される。そのため、契約において進め方を明記し、固定してしまうことは、アジャイル開発の柔軟xx個別性を減殺してしまうことになる。もっとも、アジャイル開発の進め方の基本的な部分については、予め両当事者の認識を合わせておかなければ、スムーズな進行ができず、トラブルになるおそれがある。
そこで、本モデル契約においては、両当事者が認識合わせを行うための資料として進め方指針を用意し、スクラムによる開発の進め方については、当該進め方指針を参照することとしている。この進め方指針は、進め方に関する両当事者の認識を共有するためのものであり、進め方に関して契約を解釈する際に、当事者の合理的な意思を推測させるものとして機能することになる。進め方指針については、IPA において基本的な内容を入れたサンプルを用意しているが、必要に応じてプロジェクトごとにカスタマイズされることを想定している。また、各社がこれに類するものを既に保有していれば、それに差し替えることもできる。
2. 契約前チェックリスト
アジャイル開発を円滑に進めるにあたっては、契約締結に先立ち、プロジェクトの目的・ゴールは明確か、開発対象プロダクトのビジョンは明確か、ユーザ企業及びベンダ企業がそれぞれアジャイル開発の内容を理解しているか、開発対象プロダクトが真にアジャイル開発に適したものであるか、開発にあたり必要な初期計画ができているか、開発のために必要な体制を整えることができるか等、スムーズな開発のための条件を充足しているか否かを確認し、不足している部分はそれを補うための対策をしておくべきで
ある。
本書別紙の契約前チェックリストは、本モデル契約を用いることを前提に、こうした条件の充足について事前に確認するためのツールであり、次のような項目とチェックポイントが記載されている。契約を締結する前にチェックを行い、不足があれば対応策を講じるべきである。
項目 | チェックポイント |
1. プロジェクトの目的・ゴール | プロジェクトの目的（少なくとも当面のゴール）が明確で あるか |
ステークホルダーの範囲が明確になっているか | |
目的についてステークホルダーと認識が共有されている か | |
2. プロダクトのビジョン | 開発対象プロダクトのビジョン（あるべき姿、方向性等） が明確であるか |
開発対象プロダクトのビジョンについてステークホルダ ーと認識が共有されているか | |
3. アジャイル開発に関する理解 | プロジェクトの関係者（スクラムチーム構成員及びステー クホルダー）がアジャイル開発の価値観を理解しているか |
プロジェクトの関係者がスクラムを理解しているか | |
4. 開発対象 | 開発対象プロダクトがアジャイル開発に適しているか |
１チーム（最大で 10 名程度）の継続的対応にて、開発可 能な規模であるか | |
5. 初期計画 | プロジェクトの初期計画が立案されているか |
プロジェクトの基礎設計が行われているか | |
完了基準、品質基準が明確になっているか | |
十分な初期バックログがあるか（関係者間で初期のスコー プの範囲が合意できているか） | |
6. 本契約に関する理解 | 本契約が準委任契約であることを理解しているか |
7. 体制（共通） | ユーザ企業とベンダ企業の役割分担を理解しているか |
今回のプロジェクトにおける体制を理解しているか | |
8. ユーザの体制 | 適切なプロダクトオーナーを選任し、権限委譲ができるか |
ユーザ企業としてプロダクトオーナーへの協力ができる か | |
9. ベンダの体制 | アジャイル開発の経験を有するスクラムマスターが選任 |
できるか | |
必要な能力を有する開発チームを構成できるか | |
開発チームを固定できるか |
Ⅳ. 本モデル契約条項解説
〇〇（以下「甲」という。）と〇〇（以下「乙」という。）は、別紙第 1 項記載のプロ
ジェクト（以下「本プロジェクト」という。）における、アジャイル開発方式を用いたプロダクト開発に関し、本契約（以下「本契約」という。）を締結する。
本アジャイル開発外部委託モデル契約（以下「本契約」という。）は、特定のプロジェクトを遂行するために、外部委託により、アジャイル開発方式を用いたプロダクト開発を行うための契約であり、プロジェクトの目的及び開発対象プロダクトの概要については、別紙第 1 項及び第 2 項において記載することとしている（別紙に記載する内容の詳細は別紙の解説を参照されたい。）。前文においてアジャイル開発方式を用いることを明記することで、ユーザ企業及びベンダ企業がアジャイル開発によるプロダクト開発に合意していることが明確になる。これにより開発方式を巡る当事者間の意思に齟齬が生じることを予防できるとともに、紛争発生時に本契約が前提とする開発方式が何かが争点となる事態を避けることができる。
・本契約の構成と別紙の位置付け
本契約は、契約書本体と別紙とで構成されており、個別の案件ごとに内容が異なる項目を別紙に集約している。別紙も契約の一部であるから、別紙に記載された内容も法的な拘束力を生じる。当事者の一方が別紙記載の内容を変更しようとする場合には、契約書本体と同様、第 6 条第 1 項から第 7 項に定める変更管理手続の対象となり、変更を有効とするためには両当事者が記名押印した変更合意書が必要となる。
第 1 条（目的）
本契約は、甲が本プロジェクトの目的達成のためにアジャイル開発方式を用いたプロダクト開発を行うにあたり、準委任によりその開発支援を乙に委託し、xがこれを受託することに関し、甲と乙がお互いに協力して行う業務の内容や、甲と乙の権利及び
義務について定めることを目的とする。
本契約は、ユーザ企業がアジャイル開発方式を用いたプロダクト開発を行うために、ベンダ企業に対し、準委任契約の形態でその開発支援を委託することを前提としている。本条は、そのような前提に基づき本契約の目的を定める規定である。
・本契約を準委任契約とした趣旨
開発対象全体の要件及び仕様を確定してから開発を行う、いわゆるウォーターフォール方式とは異なり、アジャイル開発では開発プロセスの中で、開発する機能の追加・変更や、その優先順位の変更が生じる。そのため、当初は開発予定となっていた機能も、ビジネス環境の変化やユーザ企業内部のニーズの変化などに応じて、プロダクトの内容に責任を持つユーザ企業の判断で開発対象から外す場合もある。また、プロダクト（一部の場合もある）を一旦リリースした後も、利用者からのフィードバックに対応するなどして、さらなる機能追加や改善が行われることもある。このようなアジャイル開発の特徴からすれば、あらかじめ内容が特定された成果物を予定したとおりに完成させることを義務付ける請負契約より、専門家としての注意義務を果たしながら業務を遂行することを義務付ける準委任契約の方が、その性質上、アジャイル開発契約には馴染み易い。
また、請負契約は特定の成果物の完成に対して対価を支払うものであることから、対価は事前の見積もりに基づき契約において取り決められる固定金額となるのが一般的である。しかし、アジャイル開発の強みは、その時々にユーザ企業が真に必要としている価値を優先して実現できることにあり、開発する機能のタイムリーな追加・変更ができる点にあるところ、対価を固定した請負契約を締結した場合、ベンダ企業には工数を増やさないよう、追加・変更を抑制するインセンティブが生じうる。そのため、請負契約は両当事者間の利害対立を招くリスクがある。
こうした点を考慮すると、外部委託によりアジャイル開発を行うに当たっては、請負契約ではなく準委任契約を用いるのがより適当と考えられたため、本契約では準委任契約を前提とすることとした。
なお、準委任契約における受任者の義務について、民法第 644 条（第 656 条で準用）は、「受任者は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う。」と定めており、ここで「委任の本旨に従い」とは、（準）委任契約の内容とその事務の性質に応じて最も合理的に処理することと解釈されている5。したがって、準委任契約を基礎にアジャイル開発を進める場合でも、受任者であるベンダ企業には、本契約の本体及び別紙で定められた範囲内で誠実に自らの役割を果たしてプロダクト開発を進める義務がある。そして、機能の追加・変更や優先順位の変更が、結果として代金の増減やスケジュールの延長・短縮を招くときには、第 6 条の変更管理の手続により両当事者の合意によって契約書本体や別紙の内容を変更することになる。
・請負契約のリスク
なお、開発すべき具体的な機能が確定していないにもかかわらず、アジャイル契約に
5 xxx「債権各論中巻二」（1962、岩波書店）670 頁、「新注釈民法(14) 債権(7)」（2018、有斐閣）250 頁（xxxx執筆部分）
おいて一括で請負契約を締結してしまうことには、次のようなリスクがあることに留意されたい。
①対価と実際の工数が大きく乖離するリスク
前記のとおり、請負契約は、成果物の完成を約束し、それに対して対価が支払われる契約類型であり、その対価は固定され、発生した工数に連動しないのが一般的である。そのため、完成すべき成果物の内容につき、変動が見込まれるにもかかわらず、当初の大まかな見積もりに基づきベンダ企業側が対価を固定して開発を引き受けてしまうと、開発対象が想定以上に膨らんだ場合や、仕様が変更され手戻りが生じた場合に、ベンダ企業側の負担が大きくなるリスクがある（ウォーターフォール開発における一括請負もこのようなリスクはあるが、アジャイル開発の場合、開発対象が変動する可能性が高い点でよりリスクが大きい。）。
②ユーザ企業とベンダ企業の利害が対立するリスク
前記のように、対価を固定した請負契約を締結した場合、ベンダ企業は工数を増や さないよう、開発対象の変動をなるべく抑制しようとする方向に傾くおそれがある。アジャイル開発はユーザ企業とベンダ企業が互いに協力し、開発対象を柔軟に変更す ることでユーザ企業にとって価値の高いプロダクトを開発するための手法であるに もかかわらず、対価を固定した請負契約を締結することで当事者間に利害対立が生じ、アジャイル開発を選んだ目的が達成できないリスクがある。
・請負契約を用いる場合の注意点
もしアジャイル開発の外部委託において請負契約を用いるのであれば、開発を予定しているプロダクト全体を成果物とするのではなく、仕様が比較的明確で、開発することが確定している部分だけに限定して請負の対象とする方法が望ましい。仕様の確定が進んだ時点で、その部分に限定した個別の請負契約の締結を繰り返す方式を採用したものとして、IPA が 2012 年に公開した「基本/個別契約モデルの個別契約書案（請負型）【平成 23 年度改訂版】」がある。以下のサイトからダウンロードできる。 https://www.ipa.go.jp/archive/digital/iot-en-ci/process/ent02-c.html
第 2 条（アジャイル開発方式）
1. 甲及び乙は、本プロジェクトにおけるアジャイル開発の方式としてスクラムを用いるものとし、別紙第 4 項記載のとおり、主にプロダクトオーナー、スクラムマスター及び開発者からなるチーム（以下「スクラムチーム」という。）を組成して開発を行う。
2. 本契約における開発の対象は、別紙第 2 項記載のプロダクト（以下「開発対象プ
ロダクト」という。）とし、甲及び乙は別紙第 3 項記載のスケジュールに従って開
発を行う。
3. 甲は、開発対象プロダクトに関する甲の要求事項（開発する機能のほか、非機能要件への対応、リファクタリング、文書作成等の関連業務を含む。）及びその優先順位について乙と協議を行い、プロダクトバックログ（甲の要求事項を列挙して優先順位を付けたリストをいう。）を作成する。
4. 甲は、乙と協議の上、自らの責任において、プロダクトバックログに記載された要求事項及びその優先順位を変更することができる。
5. 甲及び乙は、スプリント（開発業務を実施するための一定の区切られた期間をいう。）を反復することにより、開発対象プロダクトを開発する。甲及び乙は、各スプリントの開始前に、両当事者の合意によりスプリントバックログ（プロダクトバックログの中から選定される、次のスプリントでの開発対象となる要求事項と、それらを実現するために必要なタスクを列挙したリストをいう。）を作成してそれを対象とする開発を行い、各スプリントの終了時にその成果の確認を行う。
6. 甲及び乙は、本プロジェクトにおけるスクラムによる開発の進め方については、本契約における定め又は当事者間での別段の合意がない限り、本契約に添付する
「アジャイル開発 進め方の指針」（以下「進め方指針」という。）を指針として参
照する。
本条は、本契約におけるアジャイル開発方式及びその進め方に関する規定である。アジャイル開発方式の詳細については、当事者やプロダクトの特性に応じて差違があるため、本契約に明記して固定することはせず、「アジャイル開発 進め方の指針」（以下「進め方指針」という。）に記載することとしている。しかし、スクラムによるアジャイル開発においておよそ共通するであろうと思われる基幹的な要素については、契約書本体で明確に定めておくべきであることから、本条を置いた。ただし、本条も絶対に変更できないという性質の条項ではないので、他の条項との整合性に配慮しながら、当事者やプロダクトの特性に応じて適宜変更することも可能である。
・第 1 項 アジャイル開発方式
第 1 項では、本契約が前提とするアジャイル開発方式として、最も広く用いられているスクラムを用いることとしている。本契約では、プロダクトオーナーはユーザ企業が、スクラムマスターはベンダ企業が、それぞれ選任することを想定しており（第 4 条及び
第 5 条）、開発チームについては、ベンダ企業の人員だけから構成されるケースと、ベンダ企業とユーザ企業の双方の人員から構成されるケースを想定している（開発チームがユーザ企業の人員のみというケースは想定外である。）。
・第 2 項 開発対象プロダクト
第 2 項では、別紙第 2 項記載のプロダクトを、本契約における開発対象プロダクトと
規定した上、別紙第 3 項記載のスケジュールに従って開発を行うこととしている。別紙
第 2 項及び第 3 項については、別紙の解説を参照されたい。
・第 3 項 プロダクトバックログの作成
第 3 項では、プロダクトバックログの作成について規定している。バックログ枯渇によるプロジェクトの停滞を避けるためには、開発を開始する前に、十分な初期バックログを作成しておくべきである。
本契約では、プロダクトバックログの作成権限と管理責任はユーザ企業が持つこととしている。契約の文言上は、契約当事者であるユーザ企業とベンダ企業が協議の上プロダクトバックログを作成することとなっているが、具体的には、ユーザ企業が選任するプロダクトオーナーが、開発チーム（ベンダ企業の人員だけで構成される場合もあれば、ベンダ企業とユーザ企業の双方の人員で構成される場合もある）と協議の上作成することになる。ユーザ企業がプロダクトバックログを作成するにあたっては、ベンダ企業や外部コンサルタントとの間で、そのための契約を締結し、ワークショップ等を行って作成を進めることもある。
また、アジャイル開発においては、新たな機能の開発のみならず、非機能要件への対応や、リファクタリング（一旦開発された機能について、保守性や拡張性を高めるため、外的な動作は変えないまま内部構造を作り変えること）、文書作成等の関連業務が行われることがある。本項では、これらの関連業務（業務を行う前の実現性調査等も含む。）についても、プロダクトバックログの項目として明示的に取り上げることで、必要な業務が漏れてしまうことを防ぎ、ユーザ企業とベンダ企業が共通の認識を持ってプロダクト開発を進めることとしている。
プロダクトバックログの項目になりうる非機能要件の中には、例えばセキュリティの確保などがある。ベンダ企業は自らの専門知識及びノウハウを用いて、開発対象プロダクトが備えるべきセキュリティ（その実装のために必要となる期間や費用等も含む。）に関し、ユーザ企業に適切な助言を行い、プロダクトバックログの内容に載せるべき項目を提案すべきであり、それを全く怠っていたような場合には、善管注意義務違反となるおそれがある6。なお、もし契約締結時点において、プロダクトが備えるべき非機能要件が確定していれば、別紙に項目を設けて記載することで、当該非機能要件を備える
6 東京地裁平成 26 年 1 月 23 日判決（判時 2221 号 71 頁）では、ベンダ企業が受託開発して納品したウェブ受注システムに対し、SQL インジェクション攻撃がなされ、ユーザ企業に損害が生じた事案において、ベンダ企業には、受託開発の契約時点において既に広く知られ、経産省から注意喚起、IPA から具体的対策が公表されていた SQL インジェクション攻撃について、対策措置を施したプログラムを提供すべき義務があったと認定された。
ことを契約上明らかにしておくことも考えられる。
リファクタリングには、その内容により、軽微なものもあれば、相当な時間がかかるものもある。本項においてプロダクトバックログの項目として取り上げるリファクタリングは、日々の開発の中で対応できないような、軽微でない規模のものを想定している。
プロダクトに関する仕様書等の文書作成をユーザ企業が求める場合には、第 9 条によ り、要求事項の一つとしてプロダクトバックログに加えることとしており、本項もそれ に合わせた規定をしている。もし契約締結時点において作成する文書が確定していれば、別紙に項目を設け、予め作成文書を明記しておくことも考えられる。
・第 4 項 プロダクトバックログの変更
第 4 項では、プロダクトバックログに含まれる要求事項及びその優先順位の変更につ いて、ユーザ企業が権限と責任を有することを規定している。具体的には、ユーザ企業 が選任するプロダクトオーナーがプロダクトバックログの管理を行うことになる。なお、スクラムにおいては、プロダクトバックログへの要求事項の追加はユーザ企業に限らず 誰でもできることとされているが、責任の所在を明確にするために、本項では要求事項 の追加を含む変更をユーザ企業の権限としている。もちろん、ユーザ企業以外の者が、プロダクトの価値を高めるためにプロダクトバックログの要求事項の追加を提案する ことは自由であり、提案があれば、バックログリファインメントなどの際にスクラムチ ーム内で協議することになるが、その採否と優先順位の最終決定はユーザ企業（具体的 にはプロダクトオーナー）に委ねられる。
・第 5 項 スプリントバックログの作成
スクラムではスプリントを反復することによってプロダクト開発が行われるが、第 5
項第一文では、そのことを念のため規定している。
第二文では、プロダクトバックログの要求事項の中から、あるスプリントにおける開発の対象を選定して作成するスプリントバックログについて、ユーザ企業がベンダ企業と合意の上作成すること、当該スプリントバックログに基づいた開発を行うこと、スプリント終了時には成果確認を行うことを規定している。
スプリントバックログは、具体的には、スプリントプランニングにおいてプロダクトオーナーと開発チームが協議し、開発チームが提示する業務量見積り等をもとに作成される。もし協議を行っても合意ができず、スプリントを開始できないような場合には、第 7 条の問題解消協議等により解決を図ることになる。
なお、ユーザ企業とベンダ企業が（実務的にはスクラムチームが）スプリントバックログについて合意をした場合は、合意があった事実を後から証明できるよう、両当事者のメールのやりとりで確認を行い記録に残したり、両当事者がスプリントバックログの
備考欄等に内容を了解した旨記載したりするなどの方法も考えられる。
・第 6 項 アジャイル開発の進め方の指針
第 6 項では、アジャイル開発の進め方について、進め方指針を指針として参照する旨規定している。アジャイル開発においては、進め方を固定してしまうのではなく、スクラムチームが自らの特性やプロジェクトの内容に合わせて最適な進め方を模索し、柔軟かつ自律的に改善を行っていくことが推奨される。そのため、契約において進め方を明記し、固定してしまうことは、アジャイル開発の柔軟さや自律性を減殺してしまうことになる。もっとも、アジャイル開発の進め方の基本的な部分については、予め両当事者の認識を合わせておかなければ、スムーズな進行ができず、トラブルになるおそれがある。そこで、本契約においては、両当事者が認識合わせを行うための資料として進め方指針を用意し、スクラムによる開発の進め方については、当該指針を「参照」することとしている。
当該指針について、本項で「開発の指針として参照する」こととした趣旨は、進め方指針が現場レベルでの認識合わせに用いられる、比較的技術的な内容の文書であることから、記載された内容について契約書本体と同様の拘束力を持たせるべきではないものの、そこに記載されている進め方と大きく異なる方法をとる場合には、第 6 条第 8 項に定められた協議及び変更の手続を経ることで両当事者が明示的に再度の認識合わせを行い、進め方に関する両当事者の認識に齟齬を生じさせないようにするためである。これにより、当該指針は、契約を解釈する際に当事者の合理的な意思を推測させるものとして機能する。すなわち、進め方に関連して生じた両当事者間のトラブルが、問題解消手続で解決せずに紛争に発展した場合には、契約書本体及び別紙の記載と併せて、当該指針が進め方に関する当事者の意思を合理的に解釈するための指針としても機能することになる。仮にいずれかの当事者が進め方指針を大幅に逸脱する進め方を行っているような場合には、スクラムチーム内での協議により補正を行い、それができない場合には第 7 条の問題解消協議を用いて解決を図ることになる。
なお、この進め方指針は、プロジェクトごとに必要に応じてカスタマイズすることを想定している。また、各社がこれに類するものを既に保有していれば、それに差し替えることもできる。
第 3 条（体制）
1. 甲及び乙は、開発対象プロダクトを開発するにあたり、別紙第 6 項で定めた業務
（以下「本件業務」という。）を、それぞれ同項記載の役割分担に従って行うとともに、相手方の担当業務についても誠意をもって協力する。
2. 甲及び乙は、本件業務を遂行するにあたり、別紙第 4 項の体制に基づき、それぞ
れ業務従事者を選任する。
3. 甲及び乙は、それぞれ本件業務の実施責任者を選任し、本件業務に関する指示、要請、依頼等の連絡を行う場合には、双方の実施責任者を通じて行う。
4. 甲及び乙は、労働関係法令及びその他の適用のある法令に基づき、自らの業務従事者に対する雇用主としての一切の義務を負い、自らの業務従事者に対して本件業務の遂行、労務管理及び安全衛生管理等に関する一切の指揮命令を行う。
5. 甲又は乙が、自らの業務従事者を変更する場合は、委託業務の遂行に支障を及ぼさないよう、事前に相手方に対し、新旧の業務従事者の氏名及び交替理由を書面
により通知するものとし、変更に当たって十分な引継ぎを行わせるものとする。
本条は、開発対象プロダクトを開発する体制について定めた規定である。
・第 1 項 役割分担と協力義務
本契約では、別紙第 6 項にベンダ企業とユーザ企業の担う業務を記載し、両者の役割 分担を決めることとなっている。ベンダ企業及びユーザ企業は、それぞれ同項に記載さ れた業務を履行する契約上の義務を負う。また、システム開発、特にアジャイル開発に おいては、ベンダ企業とユーザ企業の密接なコミュニケーションと協働関係が重要であ ることから、それぞれ相手方が担当する業務についても協力する義務を規定している。そのため、もし一方当事者が相手方の協力を必要としているにもかかわらず、全く協力 しなかったり協力を拒んだりしたような場合には、契約上の義務違反として責任を負う おそれがある。もっとも、本契約においては、協力義務に含まれる義務7について、他 のより具体的な義務を定めた条項でカバーされている。例えばユーザ企業が負う、ベン ダ企業が開発を行うために必要な情報や資料等の提供を行う義務は、第 4 条（甲の義務）第 1 項及び第 3 項第 6 号並びに第 12 条（甲が乙に提供する資料等及びその返還）に具 体的に記載されているため、もしユーザ企業が情報や資料等を提供しなかった場合には、本項よりも先に、これらの義務への違反が問題となると思われる。
・第 2 項 業務従事者の選任
本契約における業務の体制は、別紙第 4 項に記載されているが、各当事者がそれぞれ
7 東京地裁平成 16 年 3 月 10 日判決（判タ 1211 号 129 頁）では、システムの開発過程において、ユーザ企業がベンダ企業から資料等の提供その他システム開発のために必要な協力を求められた場合、これに応じて必要な協力を行うべき契約上の義務を負うとしている。また、東京地裁八王子支部平成 15 年 11 月 5 日判決（判時 1857 号 73 頁）では、ユーザ企業も、一つの企業体として事業を営み、その事業のためにシステムを導入する以上、自己の業務の内容等ベンダ企業がシステムを構築するにあたり必要とする事項について、正確な情報をベンダ企業に提供すべき信義則上の義務を負うとしている。
の業務従事者の選任を行うこととしている。特に、発注者であるユーザ企業が、受託者であるベンダ企業の業務従事者を選ぶことは、「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和 61 年労働省告示第 37 号）8第 2 条第 1 号ハ(2)に抵触し、労働者派遣事業と評価されうるため注意を要する。
・第 3 項及び第 4 項 実施責任者の選任、業務従事者に対する指揮命令
「労働者派遣事業と請負により行われる事業との区分に関する基準」第 2 条第 1 号によれば、受託者が自己の労働者に対する「業務の遂行に関する指示その他の管理」、「労働時間等に関する指示その他の管理」、「企業における秩序の維持、確保等のための指示その他の管理」を自ら行わなければ、労働者派遣事業として扱われることになる。そのため、第 3 項は、両当事者が、本件業務の遂行に関しこうした指示等の連絡窓口となる実施責任者を選任して、本件業務に関する指示、要請、依頼等の連絡は双方の実施責任者を通じて行うこととしている。なお、実施責任者を通さなければならない指示等を減らすためには、本件業務の開始前に本件業務の遂行方法の詳細をあらかじめ取り決めて明確にしておき、各業務従事者がそれに従って業務を遂行するようにしておくことが考えられる。
次に、第 4 項では、自らの業務従事者に対する指揮命令は自ら行うこととして、ユーザ企業からベンダ企業の業務従事者に対し、上記基準記載の指示等が行われないようにしている。実施責任者は、上記のとおり指示等の連絡窓口となることから、スクラムチームのメンバから選定されることが想定され、例えばベンダ側は開発者のうち一名が兼務し、ユーザ企業はプロダクトオーナーが兼務するといったケースが考えられる。
なお、DX 対応モデル契約見直し検討 WG での議論では、実施責任者に関して、特にアジャイル開発の場合には、実施責任者の業務量が多い場合や、現場に不在となる場合にも対応できるよう、主たる実施責任者に追加してサブの実施責任者を選任することも考えられるとの意見が出た。また、アジャイル開発の開発チームでは、各メンバが互いに対等な関係で提案や助言を行い合うことで開発を進めるため、そうした提案や助言まで「実施責任者」を通さなければならないとすることは、アジャイル開発の実態にそぐわないのではないかといった意見も出た。こうした意見も含め、アジャイル開発で想定される様々なコミュニケーションが、上記基準の「業務の遂行に関する指示その他の管理」に該当するか否かについては、次の「偽装請負」の項目に記載のとおり、複数の委員から様々な意見が出された。
8 「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和 61 年労働省告示第 37 号）
https://www.mhlw.go.jp/bunya/koyou/dl/h241218-01.pdf
・偽装請負
アジャイル開発におけるユーザ企業側のベンダ企業に対するコミュニケーション如何によって、ベンダ企業の関与がいわゆる「偽装請負」と評価されるのではないか（ここでいう「偽装請負」は、あくまでも、雇用や労働者派遣ではない契約形態であるにもかかわらず、実質的には、雇用や労働者派遣でなければできないことをしているという趣旨であるので、本契約が準委任であることは、この問題が存在しないことを意味しない。）という議論がなされることがある。ここで、いわゆる偽装請負該当性そのものの判断については、「モデル取引・契約書見直し検討部会」の領分ではないと理解されるところであり、最終的には、「労働者派遣事業と請負により行われる事業との区分に関する基準」や「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37号告示）に関する疑義応答集」9、「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37 号告示）に関する疑義応答集（第 2 集）」10等に基づき、所管官庁（及び裁判所）が判断する事柄である。11
但し、DX 対応モデル契約見直し検討WG での議論では、ある委員から、本契約で想定されるアジャイル開発におけるコミュニケーションは「①ベンダ企業内部」「②ユーザ企業内部」「③ベンダ企業からユーザ企業」「④ユーザ企業からベンダ企業」の 4 つがあるが、偽装請負との関係ではこのうち、④のみが問題となるところ、④においては Aユーザ企業のプロダクトオーナーがベンダ企業（ベンダ企業側開発メンバ等）とコミュニケーションする場合、B ユーザ企業側開発メンバがベンダ企業（ベンダ企業側開発メンバ等）とコミュニケーションする場合、C （ユーザ企業が連れてきた）スクラムマスターがベンダ企業（ベンダ企業側開発メンバ等）とコミュニケーションする場合の 3つが挙げられ、以下のように整理できるのではないか、という意見が出された。
コミュニケーション | ◯ アジャイルの本来の姿に合致しており、かつ、偽 装請負ではない | × アジャイル的ではない対応である（偽装請負の懸念も 否定できない） |
9 厚生労働省「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37 号告示）に関する疑義応答集」
https://www.mhlw.go.jp/bunya/koyou/dl/haken-shoukai03.pdf
10 厚生労働省「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37 号告示）に関する疑義応答集（第 2 集）」
https://www.mhlw.go.jp/bunya/koyou/dl/haken-shoukai03_02.pdf
11 【2021 年 10 月 6 日更新による追記】本書の初版公開後、厚生労働省「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37 号告示）に関する疑義応答集（第 3 集）」が策定・公表されている。
https://www.mhlw.go.jp/content/000834503.pdf
プロダクトオーナーからベンダ企業（ベンダ企業側開発メンバ等） | 契約上認められた本来の権能の行使としてプロダクトオーナーがプロダクトバックログの並べ替え等の決定を行い、ベンダ企業に連絡 する | プロダクトオーナーが個別のベンダ企業側開発メンバの行うべき個別具体的な対応について指示する |
ユーザ企業側開発メンバからベンダ企業（ベンダ企業側開発メン バ等） | ユーザ企業側開発メンバがその業務に対する知見を元に、ベンダ企業（ベンダ企業側開発メンバ）に対して 提案する | ユーザ企業側開発メンバがベンダ企業側開発メンバに対して指示する |
（ ユーザ企業が連れてきた）スクラムマスターからベンダ企業（ベンダ企業側開発 メンバ等） | （ ユーザ企業が連れてきた）スクラムマスターがベンダ企業（ベンダ企業側開発メンバ等）に対して助言する | （ユーザ企業が連れてきた）スクラムマスターがベンダ企業側開発メンバに対して指示する |
この意見に対し、複数の法曹資格を有する有識者委員から、賛同の声が上がり、以下のようなコメントがなされた。
✓ ユーザ企業がベンダ企業（ベンダ企業側開発メンバ等）に対し「業務の遂行に関する指示その他の管理」（「労働者派遣事業と請負により行われる事業との区分に関する基準」第 2 条第 1 号イ）を行うことは、そもそも「対等な当事者の協働」というアジャイルの本質に反している。第 3 項の「実施責任者」が行う「本件業務に関する指示、要請、依頼等の連絡」は、対象として、主に労働時間や休日、職場環境の制約といった労働関係に影響を与える事項が想定されるべきであって、開発チームのメンバ間での助言、提案等を想定すべきではない。
✓ 商品の製造の文脈では、偽装請負への該当性について、次のような整理がなされている。
⮚ 「発注者から請負事業主に対して、作業工程の見直しや欠陥商品を製作し直すことなど発注に関わる要求や注文を行うことは、業務請負契約の当事者間で行われるものであり、発注者から請負労働者への直接の指揮命令ではないので労働者派遣には該当せず偽装請負にはあたりません。」（「労働者派遣事業と請負
により行われる事業との区分に関する基準」（37 号告示）に関する疑義応答集
Q2）
⮚ 「新商品の製造着手時において、発注者が、請負事業主に対して、請負契約の内容である仕様等について補足的な説明を行う際に、請負事業主の監督の下で労働者に当該説明(資料等を用いて行う説明のみでは十分な仕様等の理解が困難な場合に特に必要となる実習を含む。)を受けさせる場合のもの」（は偽装請負ではない）（「労働者派遣事業と請負により行われる事業との区分に関する基準」（37 号告示）に関する疑義応答集 Q10 イ）
こうした整理を考慮すると、アジャイル開発の本質に即したコミュニケーションは、ユーザ企業の注文主としての意思決定の伝達等の契約の当事者間で行われる要求や注文、又はベンダ企業の監督の下でユーザ企業がベンダ企業（ベンダ企業側開発メンバ等）に対して提案・助言・説明をする範囲内に収まり、偽装請負となる指揮命令には該当しないこととなるはずである。
✓ 「発注者・請負事業主間の打ち合わせ等に、請負事業主の管理責任者だけでなく、管理責任者自身の判断で請負労働者が同席しても、それのみをもって直ちに労働者派遣事業と判断されることはありません。」（「労働者派遣事業と請負により行われる事業との区分に関する基準」（37 号告示）に関する疑義応答集（第 2 集）問 9）ともされているところ、例えばプロダクトオーナーからベンダ企業にプロダクトバックログ並べ替え等の決定が伝達され、その際にベンダ企業側開発責任者だけではなく、ベンダ企業側開発メンバ等が同席している場合というのは、このような状況として取り扱えるのではないか。
他方、こうした意見に対して、アジャイル開発といえども、受発注関係を前提とする以上、発注者であるユーザ企業側の立場が強いため、実施責任者を介さない直接のコミュニケーションが指揮命令に当たらないといえる場合は、本当に対等な、ある意味例外的な場合に限られるのではないか、との意見もあった。
【2021 年 10 月 6 日更新による追記】
本モデル契約の初版公開後、アジャイル開発と偽装請負の問題について厚生労働省の検討会で議論が行われ、その結果が「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37 号告示）に関する疑義応答集（第 3 集）」として取りまとめられ、2021 年 9 月 21 日に公表された12。
この疑義応答集（第 3 集）Q2 では、「発注者側と受注者側の開発関係者が相互に密に
12 労働者派遣事業と請負により行われる事業との区分に関する基準（37 号告示）関係疑義応答集
https://www.mhlw.go.jp/bunya/koyou/gigi_outou01.html
連携し、随時、情報の共有や、システム開発に関する技術的な助言・提案を行っていたとしても、実態として、発注者と受注者の関係者が対等な関係の下で協働し、受注者側の開発担当者が自律的に判断して開発業務を行っていると認められる場合であれば、偽装請負と判断されるものではありません」との考え方が示されている。これは、DX 対応モデル契約見直し検討 WG での議論で出された、対等な当事者の協働というアジャイル開発の本質に即したコミュニケーションは、指揮命令に該当せず、偽装請負に該当しないという意見を基本的に是認するものと考えられる。
他方で、同 Q2 は、「実態として、発注者側の開発責任者や開発担当者が受注者側の開発担当者 に対し、直接、業務の遂行方法や労働時間等に関する指示を行うなど、指揮命令があると認められるような場合には、偽装請負と判断されることになります」としており、そのような事態が生じないようにするための方策として、「例えば、発注者側と受注者側の開発関係者のそれぞれの役割や権限、開発チーム内における業務の進め方等を予め明確にし、発注者と受注者の間で合意しておくことや、発注者側の開発責任者や双方の開発担当者に対して、アジャイル型開発に関する事前研修等を行い、開発担当者が自律的に開発業務を進めるものであるというようなアジャイル型開発の特徴についての認識を共有しておくようにすること等が重要」としている。
こうした示唆をふまえると、本モデル契約及び関連資料（契約前チェックリスト及び進め方指針）を用いて、ユーザ企業とベンダ企業がアジャイル開発に関する認識を共有し、開発に関わるメンバの役割分担、権限、開発の進め方等の明確化を行うことは、偽装請負となるリスクを低減するために有用と考えられる。
・第 5 項 業務従事者の交代
アジャイル開発では、スクラムチーム内で緊密な協働が行われる分、スクラムチームの人員の交代がプロジェクトに大きな影響をもたらすため、スムーズに稼働しているチームの人員を交代することはなるべく避けることが望ましい。もっとも、何らかの理由で交代をしなければならない場合もあるため、本項では、プロジェクトのスムーズな遂行に支障を及ぼさないため、交代に向けた準備ができるよう事前に相手方に対して交代を知らせることとし、交代する業務従事者には十分な引継ぎを行わせなければならないことを規定している。
第 4 条（甲の義務）
1. 甲は、本プロジェクトの実施主体として、本件業務のうち自らの担当業務を遅滞なく行うとともに、本件業務が円滑に行われるよう、スクラムチームに対する情報提供及び必要な意思決定を適時に行う。
2. 甲は、本件業務を開始する前に、プロダクトオーナーを選任する。
3. 甲は、プロダクトオーナーに次の役割を担わせる。なお、プロダクトオーナーの行為（不作為も含む。）に関する責任は全て甲が負う。
① スクラムチームに対して開発対象プロダクトのビジョンや意義を示し、開発対象プロダクトの価値を最大化するよう努めること
② プロダクトバックログの作成及び優先順位の変更を行うこと
③ 別紙第 5 項記載の会議体のうち、出席を要するものに出席すること
④ 開発対象プロダクト（開発途中のものも含む。）に対するステークホルダー（開発対象プロダクトの利用者、出資者等の利害関係者）からのフィードバックを提供すること
⑤ 開発対象プロダクトの完成確認及びプロダクトバックログに含まれる個々の要求事項の完了確認を行うこと
⑥ 本件業務を遂行するために乙が必要とする情報提供及び意思決定を適時に行うこと
⑦ 本件業務が円滑に遂行されるよう、ステークホルダーとの調整を行うこと
本条は、本契約におけるユーザ企業の義務について定めるものである。
・第 1 項 準委任契約に基づく義務
ユーザ企業はプロジェクトの実施主体であり、開発対象プロダクトの方針・内容を決める立場にある。開発チームが円滑に本件業務を進めるためには、ユーザ企業によるタイムリーな情報提供及び意思決定が必要であるため、第 1 項では、別紙第 6 項記載の担当業務に加えて、これらを行う義務を規定している。
・第 2 項 プロダクトオーナーの選任
前記のとおり、ユーザ企業は開発対象プロダクトの方針・内容を決める立場にあるため、ユーザ企業がプロダクトに関する責任者であるプロダクトオーナーを選任することとしている。
なお、ユーザ企業がアジャイル開発に慣れておらず、社内にプロダクトオーナーの役割を全うできる人員がいないといった場合には、ベンダ側にプロダクトオーナー補佐の人員を出してもらい、補助してもらうことも考えられる。但し、その場合であっても、アジャイル開発はユーザ企業にとって価値の高いプロダクトの開発にあり、そのためにはユーザ企業が主体的に開発対象の管理・変更に関わる必要があるから、プロダクトに対して責任を持つプロダクトオーナーの職務自体をベンダ側に委ねるべきでない。
・第 3 項 プロダクトオーナーの役割
ユーザ企業は、プロダクトオーナーに対して、本項に列挙した役割を担わせることとしている。開発対象プロダクトのビジョンや意義の提示、プロダクトバックログの作成等を通じた開発対象プロダクトの方針・内容の管理のほか、必要な会議への出席、ステークホルダーからの（スクラムチームへの）フィードバックの提供、スクラムチームが必要とする情報や意思決定のタイムリーな提供が求められる。これらを実現するには、ユーザ企業からプロダクトオーナーに対する権限委譲が必要となるが、本項はそうした権限をプロダクトオーナーに付与する趣旨も含んでいる。
ステークホルダーからのフィードバックや協力は、プロダクトの価値向上のために重要であるから、具体的にどのような者がステークホルダーであるかについて、予め当事者間で認識を合わせておくことが推奨される。そうすることで、ステークホルダーを具体的にイメージしながらプロダクト開発を進めることができる。なお、第 2 条（アジャイル開発方式）第 3 項において、ユーザ企業がプロダクトバックログを作成すると規定
したが、その作業は本項第 2 号によりプロダクトオーナーに担わせることが想定されている。
また、プロダクトオーナーがスクラムチーム内においてユーザ企業としての意思決定を提供するにあたっては、その前提として、ユーザ企業内部においてニーズや意見をとりまとめることも含め、ステークホルダーとの調整を行う必要があり、これも重要な義務の一つである。
なお、プロダクトオーナーの行為の責任については、プロダクトオーナー個人ではなく、選任したユーザ企業が負うことを注意的に記載している。プロダクトオーナーは契約当事者ではないため、ベンダ企業がプロダクトオーナー個人に対して契約上の責任を追及することはできないが、そのことを明記することにより、プロダクトオーナー個人の懸念を低減する趣旨である。
第 5 条（乙の義務）
1. 乙は、情報処理技術に関する専門知識及びノウハウに基づき、善良な管理者の注意をもって、本件業務のうち自らの担当業務を行う。なお、甲及び乙は、本契約は準委任契約であり、乙が開発対象プロダクトの完成義務を負うものではないことを確認する。
2. 乙は、前項の善管注意義務を果たすために、乙の有する専門知識及びノウハウを活用し、甲に対して、プロダクトバックログの内容及び優先順位に関する助言、開発スケジュールの見通し、並びに開発対象プロダクトの技術的なリスクに関する説明を行うなど、開発対象プロダクトの価値を高めるよう努める。
3. 乙は、本件業務を開始する前に、スクラムマスターを選任する。
4. 乙は、スクラムマスターに、本件業務が円滑に遂行されるよう、本件業務の遂行
の妨げとなりうる事象を積極的に把握し、それを排除するよう努める役割を担わ
せる。なお、スクラムマスターの行為（不作為を含む。）に関する責任は全て乙が負う。
本条は、本契約におけるベンダ企業の義務について定めるものである。
・第 1 項 準委任契約に基づく義務
本契約は準委任契約であることから、受任者であるベンダ企業は成果物の完成義務は 負わないものの、本件業務の履行に当たり善管注意義務（民法第 644 条）を負うことを 規定している。準委任契約であることの帰結として、開発対象プロダクトに不具合があ ったり、セキュリティ等の非機能要件の不備があったりしたとしても、ユーザ企業はベ ンダ企業に対して、成果物に関する契約不適合責任を追及することはできない。もっと も、それらの問題がベンダ企業の善管注意義務違反によるものである場合には、ユーザ 企業はベンダ企業に対して損害賠償請求をすることができる。アジャイル開発に限らず、システム開発における準委任の場合、ユーザ企業は、ベンダ企業が情報システムやソフ トウェアに関する専門家としての知識・技能を有しているからこそ業務を委託するので あり、ベンダ企業が専門家として通常要求される水準を下回る仕事をした場合には、善 管注意義務に違反しうることになる。また、ベンダ企業は「委任の本旨」に従って善管 注意義務を果たすことが求められているので（民法第 644 条）、契約書本体及び別紙で 表された委任の内容に反する行為を行った場合も善管注意義務違反となる。
・第 2 項 開発対象プロダクトの価値を高めるべく努める義務
アジャイル開発はプロダクトの価値を高めるための手法であるから、情報処理技術に関する専門知識とノウハウを有するベンダ企業は、前項の善管注意義務の一環として、プロダクトの価値を高めるべく努める義務を負う旨規定している。その例として、ユーザ企業による適切な判断・決定を支援するため、必要な情報を提供すること（開発対象プロダクトの内容を決するプロダクトバックログの項目やその優先順位を検討する際の、専門家の観点からの助言、開発スケジュールの見通し、開発対象プロダクトの技術的なリスクに関する説明）を挙げている。
なお、本項に基づきベンダ企業が開発スケジュールの見通しを示すことは、ベンダ企業がプロジェクトマネジメントの責任を負うことを意味するものではない。アジャイル開発におけるプロジェクトマネジメントは、あくまでスクラムチーム全体で行われるものであり、ベンダ企業だけがプロジェクトマネジメントに関する責任を負うわけではない。アジャイル開発では開発対象が変化するところ、それに伴ってスケジュールの見通しも変わりうることから、ベンダ企業がその技術的な専門知識に照らし、開発対象の変
化に応じた最新の見通しを伝えることで、ユーザ企業による適切な判断・決定を支える趣旨である。
・第 3 項 スクラムマスターの選任
本契約では、ベンダ企業がスクラムマスターを選任することとしている。ベンダ企業が自ら雇用している人員から選任する場合のほか、ベンダ企業の再委託先から選任する場合も想定される。
なお、スクラムマスターをユーザ企業側から選任することも十分考えられるが、その場合は本契約の想定と異なるため、関連部分を修正する必要がある。
・第 4 項 スクラムマスターの役割
スクラムマスターは、本件業務が円滑に遂行されるよう、障害となる事象を積極的に把握し、それを排除する努力義務を負う。上記のとおり、アジャイル開発においては、プロジェクトマネジメントはスクラムチーム全体で担うべきものであり、スクラムマスターがプロジェクトマネージャーとしてプロジェクトの進行に責任を負うわけではない。スクラムマスターは、スクラムのプロセスが円滑に進み、チーム全体が自律的に動けるよう、スクラムチームを支援する役割を担う。例えば外部による割込みから開発チームを守ったり、スクラムチームが悩んでいる問題を解消するための相談に乗り、外部と交渉を行ったりすることが求められる。
なお、第 4 条（甲の義務）第 3 項と同様、スクラムマスターの行為の責任については、スクラムマスター個人ではなく、選任したベンダ企業が負うことを注意的に記載している。
第 6 条（変更管理）
1. 甲と乙は、本契約及び別紙に規定された内容について変更の必要が生じた場合には、その変更の具体的内容及び理由を示した書面を相手方に交付して、変更の協議（以下「変更協議」という。）の開催を要請することができる。
2. 甲と乙は、相手方より前項の要請があったときは、速やかに協議に応じなければならない。
3. 変更協議においては、変更の目的、変更の対象、変更の可否、変更の影響等を検討し、変更を行うか否かについて両当事者とも誠実に協議する。
4. 変更協議には、甲と乙双方の責任者（変更協議の対象事項に関する意思決定を行う権限を有する責任者をいう。本条において以下同じ。）及び責任者が適当と認める者が出席することができる。また、甲と乙は、変更協議に必要となる者の出席
を相手方に求めることができ、相手方は合理的な理由がある場合を除き、これに
応じる。
5. 変更協議の結果、本契約の内容を変更することが合意された場合には、甲と乙は、変更内容が記載された変更合意書に記名押印しなければ、当該変更は有効とならない。
6. 変更協議を行っても協議が調わないまま、最初の変更協議の日から【 】日間が経過した場合又は変更協議が開催されることなく第 1 項の要請があった日から
【 】日間が経過した場合は、甲又は乙は、書面によって相手方に通知することにより、本契約を将来に向かって解除することができる。この場合、甲は乙に対し、当該解除までに乙が実施した本件業務に対応する委託料を支払う。
7. 前項により本契約が解除された場合であっても、相手方に対する第 21 条（損害賠償）に基づく損害賠償の請求は妨げられない。
8. 甲及び乙は、進め方指針の内容について変更の必要が生じた場合には、スクラムチームにおいて変更を行うか否かについて誠実に協議を行う。当該協議の結果、変更することが合意された場合には、甲と乙は、議事録を作成して変更内容を記
録し、当該協議に参加した両当事者の業務従事者が署名を行う。
本条は、契約書本体及び別紙の変更（第 1 項から第 7 項）並びに進め方指針の変更（第
8 項）を行う場合の手続を定めるものである。本契約は準委任契約であり、別紙第 2 項で定める開発対象プロダクトにはある程度の幅があるので、その範囲内で、開発する機能の追加・変更や、その優先順位の変更が柔軟に行われることが想定されている。しかし、場合によっては、契約書本体又は別紙に明記した内容を変更せざるを得ないような事態が生ずることもある。そのような場合にも、協議によって本契約を柔軟に変更して開発を継続することを可能にするとともに、協議で解決できず開発の継続が困難となった場合は速やかに契約関係から離脱することができるよう本条を設けた。
・第 1 項 変更協議の申入れ
第 1 項では、契約書本体及び別紙の内容について変更の必要性が生じた場合には、相手方に対してその変更の具体的内容及び理由を示した書面を交付して、変更協議を求めることができることとしている。本契約のうち、特に別紙には案件固有の内容が記載されており、契約締結後の事情の変更により、一方当事者が、開発対象、体制、スケジュール等の変更が必要と判断する場合がありうる。そうした場合には、本項に基づき変更協議の申入れを行うことができる。なお、申入れを書面で行うこととしたのは、変更協議の申入れから一定期間が経過した場合には第 6 項により本契約の解除が可能となることから、その申入れの時点を両当事者が明示的に把握し、事後的に証明できるようにするためである。
・第 2 項、第 3 項 協議の実施
第 2 項では、第 1 項に基づく要請があった場合には、速やかに協議を開き、変更の可否を協議することとしている。
・第 4 項 協議の出席者
変更協議においては、契約の変更という重要事項が対象となるところ、迅速かつ効率的な意思決定を求めるため、両当事者は、相手方に対して、変更に関する意思決定を行う権限を有する責任者の出席を求めることができることとしている。
・第 5 項 変更合意書
協議の結果、契約の内容を変更する場合には、変更合意の明確な証拠を残し後日のトラブルを避けるため、両当事者の記名押印のある変更合意書を締結しなければ、変更は有効にならないこととしている。
なお、両当事者が契約の変更について予め合意している場合には、すぐに本項に基づく変更合意書を作成すればよく、わざわざ本条第 1 項から第 4 項に基づく協議の手続を行う必要はない。
・第 6 項 解除
変更協議を行っても協議が調わない場合や、申入れにもかかわらず一定期間変更協議が開催されない場合には、いずれの当事者も本契約を将来に向かって解除することができるものとしている。協議がまとまらないまま、プロジェクト全体が膠着状態となる事態を回避する趣旨である。契約が終了するにあたり、ユーザ企業はベンダ企業に対し、既履行分の委託料を支払うことになる。
なお、本項における解除権に関する議論では、債務不履行となる行為をした当事者や、自らの一方的な都合で契約からの離脱を望む当事者が、本項の解除権を利用することで機会主義的に契約から離脱することを認めることは、反対当事者の履行請求権を不当に奪うことになるので許されるべきではないとの意見があった。具体的には、本項の解除権行使につき、当事者が債務不履行をしていないことや、求める変更について合理的な理由があることを要件とすべきであるとの提案がなされた。しかし、他方で、そのような要件を付加した場合には、(i)債務不履行の有無や変更理由が合理的であるか否かを巡って当事者間で解釈の違いが生じ、解除の可否が不明確となって、プロジェクトが膠着状態に陥り、アジャイル開発の利点であるスピードが損なわれるおそれがある、(ii)アジャイル開発は両当事者の信頼関係に依拠するものであるところ、一方当事者がそうした機会主義的な解除を求めている時点で、そのような当事者と信頼関係を維持し正常な
開発を継続することは困難な場合も多いと考えられる等、アジャイル開発の特質に即した懸念が示された。その他、債務不履行責任を負うにもかかわらず解除を主張する当事者に対しては、債務不履行を理由とする損害賠償責任を負わせることにより均衡が保たれるとの意見や、プロダクトが完成間近であるにもかかわらず、ベンダ企業が合理的な理由もなく本項を利用して契約を解除するような場合には、信義則や権利濫用といった一般条項による制限が適用されうるとの意見もあった（この場合、ユーザ企業は解除の無効及び債務不履行に基づく損害賠償を主張することになると考えられる。）。
この問題は、一方当事者が契約の変更を求めているにもかかわらず、他方当事者が変更に同意しないという状況において、契約をできる限り存続させて既存の当事者による開発を継続させるべきか、それとも契約を終了させて新しい当事者との開発に移るべきか、という選択に関わる問題と考えられる。アジャイル開発においては当事者間の信頼関係が重要な基礎となるところ、協議が不調に終わった場合や協議自体が行われないような場合、また一方当事者が解除をするために本条を利用するような場合には、既に信頼関係が失われていることが多いものと想定され、そのような場合には無理に契約に拘束し続けるのではなく、契約を終了させて、信頼関係を構築できる他のベンダ企業と開発を行う方が、結果的により良いプロダクトの開発につながると考えられたことから、結論としてはそうした要件の付加は見送られた。
・第 7 項 損害賠償
第 7 項は、本契約の履行に関し、相手方の責めに帰すべき事由による損害がある場合
には、第 6 項により本契約が解除された場合でも、当事者はその責任を免れるわけでは
なく、第 21 条（損害賠償）に基づき当該損害の賠償請求を行うことができる旨を注意的に規定したものである。
・第 8 項 進め方指針の変更
進め方指針は、契約と異なり、前記のとおり開発の進め方に関する技術的な内容が記載されているものであるから、スクラムチーム内の合意により変更することができることとしている。但し、変更についてスクラムチーム内での合意があったことを明確にするために、議事録を作成し、当該協議に参加した両当事者の業務従事者の署名を求めることとしている。
・連絡協議会
システム開発においては、現場担当者以外の関係者を集めた定例の連絡協議会を設置し、その中で進捗確認やリスク管理を行うことがある。本契約ではスクラムチーム以外の関係者を集めた定例の連絡協議会は定めていないが、これは、アジャイル開発におい
てスクラムチーム以外を集めた会議を開催することは負担が大きく、アジャイルの迅速さを減殺してしまうおそれがあるためである。大規模な開発を行うような場合で、プロジェクト全体の進捗確認やリスク管理を行うために必要な場合には、定例の連絡協議会を設置することも考えられる。
第 7 条（問題解消協議）
1. 甲と乙は、本件業務の円滑な遂行を困難ならしめる問題（相手方が自らの役割を十分に果たさない場合や、スクラムチームの体制に不足がある場合等を含む。）が生じ、スクラムチーム内では当該問題の解消が困難な場合には、その問題の具体的内容等を示した書面を相手方に交付して、問題解消のための協議（以下「問題解消協議」という。）の開催を要請することができる。
2. 甲と乙は、相手方より前項の要請があったときは、速やかに問題解消協議に応じなければならない。
3. 問題解消協議においては、問題の解消に向けて両当事者とも誠実に協議する。
4. 問題解消協議には、甲と乙双方の責任者（問題解消協議の対象事項に関する意思決定を行う権限を有する責任者をいう。本条において以下同じ。）及び責任者が適当と認める者が出席することができる。また、甲と乙は、問題解消協議に必要となる者の出席を相手方に求めることができ、相手方は合理的な理由がある場合を除き、これに応じる。
5. 問題解消協議を行っても協議が調わないまま、最初の問題解消協議の日から【 】日間が経過した場合又は問題解消協議が開催されることなく第１項の要請があった日から【 】日間が経過した場合は、甲又は乙は、書面によって相手方に通知することにより、本契約を将来に向かって解除することができる。この場合、甲は乙に対し、当該解除までに乙が実施した本件業務に対応する委託料を支払う。
6. 前項により本契約が解除された場合であっても、相手方に本契約に基づく義務の違反があるときは、第 21 条（損害賠償）に基づく損害賠償の請求は妨げられない。
本条は、プロジェクトの円滑な遂行を困難ならしめるような問題が発生し、スクラムチーム内ではその解消が困難な場合の手続を定めるものである。
・第 1 項 問題解消協議の申入れ
第 1 項では、本件業務の円滑な遂行を困難ならしめる問題が生じ、スクラムチーム内 での解消が困難な場合には、その問題の具体的内容等を示した書面を相手方に交付して、問題解消協議を求めることができることとしている。問題の性質は限定していないが、例えばプロダクトオーナー等の人選に問題があり、本来果たすべき役割が果たされない
ためにプロジェクトが停滞するような場合には、スクラムチーム内での問題解消は難しい。こうした場合には、スクラムチーム外の関係者を含めた協議で解決を図ることが望ましいため、本項ではその協議を求める手続を定めている。なお、もし問題を解消するために別紙第 4 項に記載された体制枠組みを変える必要があるなど、本契約の変更が必
要となる場合には、第 6 条（変更管理）の手続を用いることになる。もっとも、契約の変更を要する問題とそうでない問題が複合的に生じている場合には、責任者が共通している限り、わざわざ二つの協議を別々に開催する必要もないため、本条の問題解消協議を第 6 条の変更協議も兼ねるものとして扱い、第 6 条に準じて契約変更を検討しても差し支えないと考えられる。
申入れを書面で行うこととしたのは、第 6 条（変更管理）と同じ趣旨である。
・第 2 項、第 3 項 協議の実施
第 2 項では、第 1 項に基づく要請があった場合には、速やかに協議を開き、問題解消に向けた協議をすることとしている。
・第 4 項 協議の出席者
問題解消協議においては、迅速かつ効率的な意思決定を求めるため、両当事者は、相手方に対して、対象事項に関する意思決定を行う権限を有する責任者の出席を求めることができることとしている。
・第 5 項 解除
前条第 6 項と同じ趣旨で、問題解消協議を行っても協議が調わない場合や、申入れにもかかわらず一定期間内に問題解消協議が開催されない場合には、両当事者は本契約を将来に向かって解除することができるものとしている。なお、本項についても、前条第 6 項の解説に記載したのと同じ議論があった。
・第 6 項 損害賠償
第 6 項は、本契約の履行に関し、相手方の責めに帰すべき事由による損害がある場合
には、第 5 項により本契約が解除された場合でも、当事者はその責任を免れるわけでは
なく、第 21 条（損害賠償）に基づき当該損害の賠償請求を行うことができる旨を注意的に規定したものである。
第 8 条（契約期間及び更新）
1. 本契約の有効期間は、別紙第 7 項において定める。
2. 甲及び乙は、書面による合意により、本契約の有効期間を延長することができる。
■別案 自動延長とする場合
2. 本契約の有効期間満了日の【 】か月前までにいずれの当事者からも契約終了の意思表示がない場合には、本契約は、同一条件で更に【 】か月間更新されるものとし、その後も同様とする。
本契約の有効期間については、個別の案件によるため、別紙第 7 項において定めた上、必要に応じて書面による合意で延長できることとしている。また、別案として自動延長する案も用意している。詳細は別紙第 7 項の解説を参照されたい。
第 9 条（文書作成）
甲は、乙に対して仕様書等の開発対象プロダクトに係る文書の作成を求める場合には、要求事項の一つとしてプロダクトバックログに加える。
本契約に基づきベンダ企業が作成する文書に関する規定である。アジャイル開発では文書を作成しないというのは誤解であり、プロダクトの内部構成の把握や将来的なメンテナンス等のために必要な設計書等が作成されることも多い。本契約では、ユーザ企業がベンダ企業に対してドキュメントの作成を求める場合には、要求事項の一つとしてプロダクトバックログに加え、作成に必要な時間を明示的に確保することとしている。なお、文書作成を行う場合には、一通りの開発が終わった段階で、まとめて作成する方法や、文書作成専任の業務従事者を置いて、開発と並行して文書作成を行う方法などがある。
第 10 条（実施業務の確認）
1. 乙は、当月に実施した本件業務について、その概要や稼働時間数等、甲乙間で予め協議の上取り決めた事項を、翌月【 】日までに甲に報告する。
2. 甲は、前項の報告を受けた場合には、【 】日以内（以下「点検期間」という。）にその内容を確認し、異議がない場合には乙に確認した旨の通知を行う。
3. 甲が、点検期間内に書面で具体的な理由を明示して異議を述べないときは、点検
期間の満了をもって確認の通知をしたものとみなす。
本条は月ごとの実施業務の確認についての規定である。本条では、準委任としてベンダ企業が善管注意義務に基づき業務を適切に行ったかどうかの確認を行う手続を定める。
・第 1 項 実施業務の報告
第 1 項は、ベンダ企業がユーザ企業に対し、月ごとに所定の期間内に実施業務の報告を行うこととしている。報告対象となる事項については、甲乙間で予め協議の上取り決めることとしているが、実施業務の詳細についてはスプリントレビュー等により既にユーザ企業に共有されていることが多いと思われることから、報告対象としては、実施業務の概要や稼働時間数等が想定される。
・第 2 項 報告内容の点検・確認
第 2 項は、点検期間を明確にした上で、ユーザ企業が報告内容の確認を行うことを定める。ユーザ企業は、報告内容について異議がある場合（例えば、記載された実施業務の内容や稼働時間数が実態と異なるなど）には、点検期間内に書面で具体的な理由を明示して異議を述べることになる。この場合、報告内容の確認が完了せずペンディングとなるため、ベンダ企業は異議を解消するために必要な対応（業務報告の修正など）を行うことになる。なお、別紙第 8 項記載のサンプルでは、本項における実施業務報告の確認後に委託料の請求を行うこととしている。
・第 3 項 みなし確認
第 3 項は、ユーザ企業が報告内容について異議を述べなかった場合のみなし確認を定める。
第 11 条（委託料及び支払方法）
乙が実施した本件業務に係る委託料及び支払方法等の詳細は、別紙第 8 項において定める。
本契約に基づきユーザ企業がベンダ企業に支払う委託料に関する規定である。詳細は別紙 8 項の解説を参照されたい。
第 12 条（甲が乙に提供する資料等及びその返還）
1. 甲は、乙に対し、本件業務に必要な資料、機器、設備等（以下「資料等」という。）の開示、貸与等を行う。
2. 甲が前項に基づき乙に提供した資料等の内容に誤りがあった場合又は甲が提供すべき資料等の提供を遅延した場合、これらの誤り又は遅延によって生じた追加費用その他の損害について、乙は責任を負わない。
3. 乙は、甲から提供を受けた資料等を善良なる管理者の注意義務をもって管理し、
双方が合意した返還日又は甲から請求があったときに、甲の指示に基づきこれら
を返還又は廃棄（デジタルデータについては削除）する。
4. 資料等の提供及び返還にかかる費用は、甲が負担する。
システム開発においては、ユーザ企業からベンダ企業への資料、機器、設備等の提供が必要となる場合があるが、本条項はその扱いについて定めたものである。この「資料等」には、ベンダ企業による開発作業に必要な機器、設備等（開発機等）のほか、必要に応じて開発対象プロダクトで用いられる第三者ソフトウェアのライセンスや稼働環境（クラウド）等も含まれ、これらの費用はユーザ企業が負担することが想定される（ベンダ企業がユーザ企業に代わってこれらを第三者から調達する場合には、別途、調達のための契約書を締結することが望ましい。）。
なお、本条項以下の規定内容は、ウォーターフォールモデルに関する経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版
＞」13（以下「WF モデル契約」という。））と共通する部分も多いため、適宜そちらの解説も参照されたい。
第 13 条（再委託）
1. 乙は、事前に甲の書面による承諾を得た場合又は甲が指定した再委託先に再委託する場合には、本件業務の一部を第三者に再委託することができる。但し、甲は合理的な理由がない限り、当該承諾を拒否することはできない。
2. 乙は、前項の再委託を行う場合には、本契約に基づいて乙が甲に対して負担するのと同様の義務を、再委託先に負わせる契約を締結する。
3. 乙は、再委託先による業務の遂行について、甲に帰責事由がある場合を除き、自ら業務を遂行した場合と同様の責任を負う。但し、甲の指定した再委託先による
業務の遂行については、乙に故意又は重過失がある場合を除き、責任を負わない。
本条は再委託に関する規定であり、WF モデル契約第 7 条14の A 案を修正して採用している。
再委託の可否については、①再委託先の技術力についての保証がなく、また機密保持の観点からも原則禁止とし委託者の承諾を要するとすべき（A 案 原則禁止）との考え
13 情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）
＜第二版＞
https://www.ipa.go.jp/digital/model/model20201222.html
14 WF モデル契約「3．モデル契約書・逐条解説 (1)ソフトウェア開発委託基本モデル契約書 第 7 条」。A 案：再委託先におけるユーザの事前承諾を設ける場合、B 案：再委託先の選定について原則としてベンダの裁量（但し、ユーザの中止請求が可能）とする場合。
と、②再委託を原則禁止としてしまうことによって業務の遂行における柔軟性が失われ、結局提供される技術の質も効率も損なわれてしまうので原則自由とすべき（B 案 原則 自由）との考えの対立があり、WF モデル契約においても、両論が併記されている。
本契約が対象とするアジャイル開発では、ユーザ企業のメンバとベンダ企業のメンバがスクラムチームを構成し、密接にコミュニケーションを取りながら開発を進めるものであり、両者の信頼関係が極めて重要である。再委託先の人員がスクラムマスターや開発者となる場合、それら人員もスクラムチームの一員としての役割を担うことになる。そのため、ベンダ企業による再委託は、ユーザ企業にとって開発の成否に影響する重大な事項であるといえ、ユーザ企業が自ら再委託先を指定した場合を除き、ベンダ企業が再委託を行う際には、ベンダ企業が再委託先の能力を慎重に検討した上で、ユーザ企業による評価・承認を得て、再委託を行うこととすべきである。
第 14 条（秘密情報の取扱い）
1. 甲及び乙は、本件業務の遂行のため、相手方より提供を受けた技術上又は営業上その他業務上の情報のうち、相手方が書面又は電子メールにより秘密である旨指定して開示した情報、又は口頭により秘密である旨を示して開示した情報で開示後【 】日以内に書面又は電子メールにより内容を特定した情報（以下あわせて
「秘密情報」という。）を第三者に漏洩してはならない。但し、次の各号のいずれか一つに該当する情報についてはこの限りではない。また、甲及び乙は秘密情報のうち法令の定めに基づき開示すべき情報を、当該法令の定めに基づく開示先に対し開示することができる。
① 秘密保持義務を負うことなくすでに保有している情報
② 秘密保持義務を負うことなく第三者から正当に入手した情報
③ 相手方から提供を受けた情報によらず、独自に開発した情報
④ 本契約に違反することなく、かつ、受領の前後を問わず公知となった情報
2. 秘密情報の提供を受けた当事者は、当該秘密情報の管理に必要な措置を講じる。
3. 甲及び乙は、秘密情報について、本契約の目的の範囲内でのみ使用し、本契約の目的の範囲を超える複製、改変が必要なときは、事前に相手方から書面又は電子メールによる承諾を受ける。
4. 甲及び乙は、秘密情報を、本契約の目的のために知る必要のある各自（本契約に基づき乙が再委託する場合の再委託先を含む。）の役員及び従業員に限り開示するものとし、本契約に基づき甲及び乙が負担する秘密保持義務と同等の義務を、秘密情報の開示を受けた当該役員及び従業員に退職後も含め課す。
5. 秘密情報の提供及び返還等については、第 12 条（甲が乙に提供する資料等及びそ
の返還）に準じる。
6. 秘密情報のうち、個人情報に該当する情報については、次条（個人情報の取扱い）が本条の規定に優先して適用される。
7. 本条の規定は、本契約終了後、【 】年間存続する。
プロダクト開発においては、ユーザ企業、ベンダ企業が互いに相手方の秘密情報に接することが想定されることから、本条では、それぞれの秘密保持義務を定める。
・第 1 項 秘密情報
第 1 項では、秘密保持義務の対象となる情報を特定している。本項では、対象となる情報を明確にするため、相手方が書面又は電子メールにより秘密である旨指定して開示した情報であるか、または口頭により秘密である旨通知して開示した情報は、開示後一定の期間内に書面又は電子メールにより内容を特定することを必要としている。第 1
号から第 4 号は、秘密情報の例外規定である。
もし電子メール以外にユーザ企業とベンダ企業の間で用いられるコミュニケーションツールがある場合には、（それが事後的に確認可能な記録が残るものである限り）本項を修正し、電子メールとともに、当該ツールによる秘密指定等もできるようにすることが考えられる。
・第 2 項 管理のために必要な措置
第 2 項では、秘密情報の提供を受けた当事者は、秘密情報の管理に必要な措置を講ずることとしている。秘密情報の秘密管理性及び非公知性を維持するためには、提供を受けた当事者に秘密情報を適正に保護する体制の構築を義務づけておく必要がある。秘密情報の管理については、物理的、技術的、人的、組織的管理措置を実効的に構築しなければならない。
・第 3 項 使用制限
第 3 項では、秘密情報の目的外使用を禁止し、複製、改変については相手方の承諾を要件としている。
・第 4 項 再委託
第 4 項では、本契約に基づき乙が再委託する場合の再委託先も含め、秘密情報の開示を受けた役員、従業員、退職者へも秘密保持義務を負わせるよう求めている。開示を受けた者が退職してしまった場合に、第三者に秘密情報が出て行くことのないよう退職者についても秘密保持義務を課すことを義務づけている。秘密情報の開示を受ける業務従
事者等に秘密保持の誓約書を義務づけるなど、より具体的な方策を定めておくことも考えられる。退職者に対して秘密保持義務を課す場合には、一般的に秘密保持契約を締結する必要がある。特に、現職の従業者等及び退職者と秘密保持契約を締結する際には、秘密保持義務が必要性や合理性の点で公序良俗違反（民法第 90 条）とならないよう、その立場の違いに配慮しながら、両者がコンセンサスを形成できるようにすることが重要である（「営業秘密管理指針」（平成 15 年 1 月 30 日、平成 31 年 1 月 23 日改訂、経済産業省）参照）。
・第 5 項 秘密情報の提供及び返還等
秘密情報の提供及び返還等については、第 12 条（甲が乙に提供する資料等及びその返還）に準じて行うことととしている。
・第 6 項 秘密情報が個人情報に該当する場合の適用関係
本条で定める秘密情報と次条で定める個人情報は、公知でない個人情報について適用が重複する場合もありうるので、その優先関係について取り決めている。
・第 7 項 契約終了後の存続
第 7 項は、秘密保持義務は通常契約期間より長期の存続が必要であるため、本契約終了後一定期間（秘密情報の性質から鑑みて合理的な期間）、存続させるものとしている。
第 15 条（個人情報の取扱い）
1. 乙は、個人情報の保護に関する法律（本条において、以下「法」という。）第 2 条第 1 項に定める個人情報のうち、本件業務の遂行に際して甲より取扱いを委託された個人データ（法第 2 条第 6 項に規定する個人データをいう。以下同じ。）及び本件業務の遂行のため、甲乙間で個人データと同等の安全管理措置（法第 20 条に規定する安全管理措置をいう。）を講ずることについて、別途合意した個人情報（以下あわせて「個人情報」という。）を第三者に漏洩してはならない。なお、甲は、個人情報を乙に提示する際にはその旨明示する。また、甲は、甲の有する個人情報を乙に提供する場合には、個人が特定できないよう加工した上で、乙に提供するよう努める。
2. 乙は、個人情報の管理に必要な措置を講じる。
3. 乙は、個人情報について、本契約の目的の範囲内でのみ使用し、本契約の目的の範囲を超える複製、改変が必要なときは、事前に甲から書面又は電子メールによ
る承諾を得なければならない。
4. 個人情報の提供及び返還等については、第 12 条（資料等の提供及び返還）を準用する。
5. 第 13 条（再委託）第 1 項の規定にかかわらず、乙は甲より委託を受けた個人情報の取扱いを再委託してはならない。但し、当該再委託につき、甲の事前の承諾を
受けた場合はこの限りではない。
個人データの取扱いの委託を行う場合、個人情報保護法第 22 条に基づいて、委託者は委託先に対する監督の責任を負うことから、本契約においても、委託先の監督について取り決めておく必要がある15。
・第 1 項 個人情報の保護
第 1 項は、ベンダ企業に個人情報保護を義務づける。ユーザ企業保有の個人情報については、当該個人に対し責任を持っているユーザ企業自身がより安全な取扱いにつき配慮すべきである。例えば、テスト時に使用するデータをユーザ企業側がダミー化する等してベンダ企業に渡す等の配慮を行う必要がある。
・第 2 項 安全管理措置
第 2 項は、ベンダ企業に必要な安全管理措置を義務づける。
・第 3 項 使用制限
第 3 項は、ベンダ企業に個人情報の目的外の使用を禁止し、複製、改変についてはユーザ企業の承諾を要件としている。
・第 4 項 提供、返還等の手続
第 4 項は、個人データの提供、返還・消去・廃棄に関する事項については、第 12 条
（資料等の提供及び返還）を準用することとしている。
15 個人データの取扱いを委託する場合に契約書への記載が望まれる事項について、「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」（平成 28 年 8 月、経済産業省）において、委託者及び受託者の責任の明確化、個人データの安全管理に関する事項、再委託に関する事項、個人データの取扱状況に関する委託者への報告の内容及び頻度、契約内容が遵守されていることの確認、契約内容が遵守されなかった場合の措置、セキュリティ事
件・事故が発生した場合の報告・連絡に関する事項が挙げられている。同ガイドラインは、平成 28 年 1 月 1 日に設立された個人情報保護委員会の設立に伴い、平成 29 年 5 月 30 日に廃止
されたが、同委員会により平成 28 年 12 月に公表された「個人情報の保護に関するガイドライン（通則編）」（以下「個人情報ガイドライン」という。）では契約書への記載が望まれる事項について詳細な列挙はされていない。その意味では、廃止はされたものの、従前のガイドラインの記載が現在においても参考になるものと思われる。
・第 5 項 再委託の禁止
第 5 項は、ベンダ企業が第 13 条（再委託）に基づき本件業務を再委託することが可能な場合にも、個人情報の取扱いの再委託については、別途ユーザ企業の事前承諾を要するものとしている。個人情報ガイドラインに、再委託を行う際に委託者への文書による報告を契約上規定すべきとされている趣旨に対応する16。
個人情報をどのように取り扱うのかについては、個人情報保護委員会（及び関連する所管省庁）のガイドライン等を踏まえた上で、事前に具体的内容について十分協議して、委託者と受託者の責任分担を明確にしておく必要がある。
第 16 条（特許権等の帰属）
1. 本件業務遂行の過程で新たに生じた発明その他の知的財産又はノウハウ等（以下、あわせて「発明等」という。）に係る特許権その他の知的財産権（特許その他の知的財産権を受ける権利を含む。但し、著作権は除く。）、ノウハウ等に関する権利
（以下、特許権その他の知的財産権、ノウハウ等に関する権利を総称して「特許権等」という。）は、当該発明等を行った者が属する当事者に帰属する。
2. 甲及び乙が共同で行った発明等から生じた特許権等については、甲乙共有（持分割合は貢献度に応じて定める。）とする。この場合、甲及び乙は、共有に係る特許権等につき、それぞれ相手方の同意及び相手方への対価の支払いなしに自ら実施し、又は第三者に対し、通常実施権を許諾することができる。
3. 乙は、第 1 項に基づき特許権等を保有することとなる場合、甲に対し、甲が開発対象プロダクトを使用するのに必要な範囲について、当該特許権等の通常実施権を許諾する。なお、開発対象プロダクトに、本契約において一定の第三者に使用せしめる旨を目的として特掲した上で開発されたプロダクト（以下「特定プロダクト」という。）が含まれている場合は、本契約に従った第三者による特定プロダクトの使用についても同様とする。なお、かかる許諾の対価は、委託料に含まれる。
4. 甲及び乙は、第 2 項、第 3 項に基づき相手方と共有し、又は相手方に通常実施権
を許諾する特許権等について、必要となる職務発明に関する特許権等の取得又は承継の手続（職務発明規程の整備等の職務発明制度の適切な運用、譲渡手続など）を履践する。
16 委託者が受託者について「必要かつ適切な監督」を行っていない場合で、受託者が再委託した際に、再委託先が適切とはいえない取扱いを行ったことにより、何らかの問題が生じた場合は、元の委託者がその責めを負うことがあり得るので、再委託する場合は注意を要する。（「個人情報ガイドライン」参照）
本条は、本件業務の遂行過程で生じる特許権等に関する権利の帰属及び実施権について定める。条項の内容及び以下の解説とも、WF モデル契約第 44 条に準じたものである。
・第 1 項、第 2 項 特許権等の帰属
第 1 項は、発明者主義に従い、当事者のいずれか一方の発明者が単独で発明考案した
場合には、特許権等は当該当事者に帰属し、第 2 項はベンダ企業、ユーザ企業が共同で発明考案した場合には特許権等はベンダ企業、ユーザ企業でその貢献度に応じて共有することとしている。
・第 3 項 通常実施権の許諾
第 3 項では、ベンダ企業が特許権等を保有する場合でも、ユーザ企業が開発対象プロダクトを使用するのに必要な範囲では、特許権等を使用する必要があるため、通常実施権を許諾するものとしている。また、一定の第三者に使用せしめる旨を目的として特掲したうえで開発された特定プロダクトについては、当該第三者に対しても許諾するものとしている。なお、かかる許諾についての対価は委託料に含まれることも明記している。
特定プロダクトの具体例としては、例えば、ユーザ企業が一般公衆向けに提供するゲームやアプリ等が考えられる。この場合には、別紙の「本プロジェクト」及び「開発対象」において、エンドユーザである一般公衆に使用させる目的で開発される旨明記することになる。
・第 4 項 必要な手続の履践
第 4 項では、ベンダ企業又はユーザ企業は、特許法第 35 条に基づく職務発明規程により職務発明についての特許権等を原始的に取得するか又は発明者から職務発明について特許権等を承継することが本条第 1 項乃至第 3 項の前提となっているので、その旨規定している。
第 17 条（著作権の帰属）
1. 開発対象プロダクト（その一部又は未完成のものを含む。）及び第 9 条（文書作成）に従い作成された文書（以下あわせて「開発対象プロダクト等」という。）のうち、本件業務遂行の過程で乙が新たに作成した著作物に関する著作権（著作権法第 27条及び第 28 条の権利を含む。以下同じ。）は、乙が作成した汎用的な利用が可能なプログラムの著作権を除き、当該著作物の作成に係る要求事項につきプロダク
トオーナーによる完了確認が行われ、かつ、甲から乙に対して当該著作物の作成
に係る業務に関する委託料が支払われた時点をもって、乙から甲へ移転する。なお、本項による乙から甲への著作権移転の対価は、委託料に含まれる。
2. 乙は、開発対象プロダクト等に含まれる著作物のうち、乙が著作権を有するものにつき、甲に対し、開発対象プロダクト等を必要な範囲で利用することを許諾し、これについて著作者人格権を行使しない。また、開発対象プロダクト等に特定プロダクトが含まれている場合は、甲は、本契約に従い第三者に対し特定プロダクトの利用を許諾することができる。なお、本項による許諾の対価は委託料に含まれる。
■別案 1：乙帰属案
1. 開発対象プロダクト（その一部又は未完成のものを含む。）及び第 9 条（文書作成）に従い作成された文書（以下あわせて「開発対象プロダクト等」という。）のうち、本件業務遂行の過程で乙が新たに作成した著作物に関する著作権は、乙に帰属する。
2. 乙は、開発対象プロダクト等に含まれる著作物のうち、乙が著作権を有するものにつき、甲に対し、甲が開発対象プロダクト等を必要な範囲で利用することを許諾し、これについて著作者人格権を行使しない。また、開発対象プロダクト等に特定プロダクトが含まれている場合は、甲は、本契約に従い第三者に対し特定プロダクトの利用を許諾することができる。なお、本項による許諾の対価は委託料に含まれる。
3. 開発対象プロダクト等のうち、本件業務遂行の過程で甲乙が共同で新たに作成した著作物に関する著作権（著作権法第 27 条及び第 28 条の権利を含む。以下同じ。）は、当該著作物の作成に係る要求事項につきプロダクトオーナーによる完了確認が行われ、かつ、甲から乙に対して当該著作物の作成に係る業務に関する委託料が支払われた時点をもって、甲及び乙の共有（持分割合は別途協議により定める。）とし、いずれの当事者も相手方への支払いの義務を負うことなく、第三者への利用許諾を含め、かかる共有著作権を行使することができる。但し、甲及び乙は、相手方の同意を得なければ、著作権の共有持分を処分することはできない。なお、本項による甲乙間での著作権移転の対価は委託料に反映されているものとする。
4. 甲及び乙は、本契約をもって、前項の共有に係る著作権の行使について法律
上必要とされる共有者の合意をあらかじめ行うものとする。
■別案 2：共有案
1. 開発対象プロダクト（その一部又は未完成のものを含む。）及び第 9 条（文書
作成）に従い作成された文書（以下あわせて「開発対象プロダクト等」という。）のうち、本件業務遂行の過程で乙が新たに作成した著作物及び甲乙が共同で新たに作成した著作物に関する著作権（著作権法第 27 条及び第 28 条の権利を含む。以下同じ。）は、当該著作物の作成に係る要求事項につきプロダクトオーナーによる完了確認が行われ、かつ、甲から乙に対して当該著作物の作成に係る業務に関する委託料が支払われた時点をもって、甲及び乙の共有（持分割合は別途協議により定める。）とし、いずれの当事者も相手方への支払いの義務を負うことなく、第三者への利用許諾を含め、かかる共有著作権を行使することができる。但し、甲及び乙は、相手方の同意を得なければ、著作権の共有持分を処分することはできない。なお、本項による甲乙間での著作権移転の対価は委託料に反映されているものとする。また、乙は、甲によるかかる利用について著作者人格権を行使しない。
2. 甲及び乙は、本契約をもって、前項の共有に係る著作権の行使について法律
上必要とされる共有者の合意をあらかじめ行うものとする。
3. 乙は、開発対象プロダクト等に含まれる著作物のうち、乙が著作権を有するものにつき、甲に対し、甲が開発対象プロダクト等を必要な範囲で利用することを許諾し、これについて著作者人格権を行使しない。また、開発対象プロダクト等に特定プロダクトが含まれている場合は、甲は、本契約に従い第三者に対し特定プロダクトの利用を許諾することができる。なお、本項による許諾の対価は委託料に含まれる。
本条は、本件業務の遂行の過程で新たに生じた著作権の権利帰属及び利用について規定する。
・ベンダ企業が新たに作成した著作物に関する著作権の帰属
本件業務により開発されたプロダクト（未完成のものを含む。）及び第 9 条に従い作成された文書（以下「開発対象プロダクト等」という。）に関する著作権のうち、ベンダ企業が新たに作成した著作物の著作権については、ユーザ企業に帰属させる案（A 案）を原則としつつ、事案に応じて個別の交渉により、ベンダ企業に帰属させる B 案（別案 1）、共有とする C 案（別案 2）も選択できることとした。但し、ベンダ企業が作成した、同種のプログラムに共通に利用することが可能なプログラム（汎用利用可能プログラム）については、社会的な生産効率の向上の観点から、A 案の場合でも、ベンダ企業が将来のソフトウェア開発に再利用できるように、ベンダ企業に留保されるものとした
（但し、ベンダ企業単独でなく、ベンダ企業がユーザ企業と共同で作成した汎用利用可能プログラムについては、A 案ではユーザ企業帰属、B 案（別案 1）及びC 案（別案 2）
では共有となる。また、ユーザ企業が単独で開発した著作物については、全てユーザ企業帰属となる。帰属の詳細は以下の表参照。）。なお、ベンダ企業はユーザ企業に対し、秘密保持義務（第 14 条）を負うことから、開発対象プロダクト等の著作権がベンダ企業に帰属したとしても、ユーザ企業は保護対象としたいノウハウ等を秘密情報に含めることで、流出防止を図ることが可能である。
開発対象プロダクト等に含まれる著作物（新規作成分）の帰属先
乙作成 | 甲乙共同作成 | 甲作成 | ||||
汎用プロ グラム | それ以外 | 汎用プロ グラム | それ以外 | 汎用プロ グラム | それ以外 | |
A 案 | 乙 | 甲 | 甲 | 甲 | 甲 | 甲 |
B 案 （別案 1） | 乙 | 乙 | 共有 | 共有 | 甲 | 甲 |
C 案 （別案 2） | 共有 | 共有 | 共有 | 共有 | 甲 | 甲 |
※ 既存著作物に関する著作権はどの案でも本契約による移転は生じない。
・A 案
A 案は、開発対象プロダクト等に関する著作権のうち、本件業務遂行の過程でベンダ企業が新たに作成した著作物の著作権については、ベンダ企業からユーザ企業に移転させる案である。但し、ベンダ企業が単独で作成した汎用的な利用が可能なプログラムの著作権については、再利用の便宜のためにベンダ企業に留保される。また、「新たに作成した著作物」と規定していることから、開発対象プロダクト等に含まれる、ベンダ企業が従前から保有していた著作物（既存著作物）に関する著作権については、そのままベンダ企業に留保される。
第 1 項では、著作物の作成に係る（プロダクトバックログの）要求事項につきプロダクトオーナーによる完了確認が行われ、かつ、著作物の作成に係る業務に関する委託料が支払われた時点で著作権が移転することとし、その対価は委託料に含まれるものとしている。第 4 条（甲の義務）第 3 項第 5 号では、プロダクトオーナーの役割の一つとして、「開発対象プロダクトの完成確認及びプロダクトバックログに含まれる個々の要求事項の完了確認を行うこと」が定められており、プロダクトオーナーは、スプリント実施にあたって適宜プロダクトバックログの要求事項の完了確認を行うところ、その完了確認が行われ、かつ、対応する委託料が支払われた時点をもって著作権を移転させる趣旨である。なお、ベンダ企業がユーザ企業と共同で作成した著作物については、一旦両者の共有となるところ、ベンダ企業の共有持分も本項によりユーザ企業に移転すること
になる。
また、著作権法第 27 条（翻訳権、翻案権等）及び第 28 条（二次的著作物の利用に関する原著作者の権利）の権利については、特掲されていなければ譲渡した者に留保したものと推定される（著作権法第 61 条第 2 項）ので、著作権の移転の際にはこれらの権利も譲渡されることを明記している。著作権の移転については、開発に関する委託料とは別に対価を定める方法もあり得るが、本契約では開発に関する委託料に含める方法をとっている。
第 2 項では、開発対象プロダクト等の中に含まれる、ベンダ企業が著作権を有する著作物（ベンダ企業の既存著作物と、ベンダ企業が作成した汎用的な利用が可能なプログラム）は、ユーザ企業に権利が移転しないところ、ユーザ企業が開発対象プロダクトを差し支えなく利用できるよう、ベンダ企業はユーザ企業が必要な範囲での利用を許諾することとしている。また、開発対象プロダクト等の中に特定プロダクトが含まれている場合には、本項により、ユーザ企業による第三者への利用許諾も行えることとしている。
・B 案（別案 1 乙帰属案）
B 案は、開発対象プロダクト等に関する著作権のうち、本件業務遂行の過程でベンダ企業が新たに作成した著作物の著作権については、ベンダ企業に帰属させるというものである。また、この B 案では、ベンダ企業がユーザ企業と共同で作成した著作物については両者の共有とし、それぞれが自由に利用できることとしている。
第 1 項では、本件業務遂行の過程でベンダ企業が新たに作成した著作物の著作権がベンダ企業に帰属することを定めている。ベンダ企業の既存著作物の著作権もベンダ企業に留保される。
第 2 項では、開発対象プロダクト等の中に含まれる、ベンダ企業が著作権を有する著作物は、ユーザ企業に権利が移転しないところ、A 案第 2 項と同様、ユーザ企業が開発対象プロダクトを差し支えなく利用できるよう、ベンダ企業はユーザ企業が必要な範囲での利用を許諾することとしている。また、開発対象プロダクト等の中に特定プロダクトが含まれている場合には、本項により、ユーザ企業による第三者への利用許諾も行えることとしている。
第 3 項では、本件業務遂行の過程でベンダ企業とユーザ企業が共同で新たに作成した著作物の著作権が、両者の共有となることを定めて、両当事者が相手方への支払いを要することなく、第三者への利用許諾を含め、自由に共有著作権を行使することができることとしている。但し、共有著作権については、その持分を譲渡又は質権の目的とするためには他の共有者の同意を得なければならない（著作権法第 65 条第 1 項）ので、これを確認している。
また、共有著作権の持分割合は、別途協議により定めることとしている。理論的には、
共有著作権の持分割合は各当事者の寄与度によるところ、本項によりその持分割合が変動し持分の移転が生じた場合であっても、その移転の対価は、委託料に反映されているものして扱うこととしている。
第 4 項では、共有著作権の行使は全員の合意が必要であるところ（著作権法第 65 条
第 2 項）、本契約をもってあらかじめ合意を行うものとしている。
・C 案（別案 2 共有案）
C 案は、開発対象プロダクト等に関する著作権のうち、本件業務遂行の過程でベンダ企業が新たに作成した著作物及びベンダ企業とユーザ企業が共同で新たに作成した著作物の著作権については、ベンダ企業とユーザ企業が共有するというものである。
第 1 項では、本件業務遂行の過程でベンダ企業が新たに作成した著作物及びベンダ企業とユーザ企業が共同で新たに作成した著作物について、それらの作成に係る要求事項に関するプロダクトオーナーによる完了確認及び対応する委託料の支払いが行われた時点をもって著作権が共有となることを定めた上、B 案第 3 項同様、両当事者が相手方への支払いを要することなく、第三者への利用許諾を含め、自由に共有著作権を行使することができることとしている。また、本項により持分割合が変動し持分の移転が生じた場合であっても、その移転の対価は、委託料に反映されているものして扱うこととしている点も、B 案第 3 項と同じである。
第 2 項では、共有著作権の行使は全員の合意が必要であるところ（著作権法第 65 条
第 2 項）、B 案第 4 項同様、本契約をもってあらかじめ合意を行うものとしている。
第 3 項では、開発対象プロダクト等の中に含まれる著作物のうち、ベンダ企業が著作権を有するもの（具体的には、ベンダ企業が有する既存著作物を想定）について、ユーザ企業が開発対象プロダクトを差し支えなく利用できるよう、ベンダ企業は必要な範囲での利用を許諾することとしている。また、開発対象プロダクト等の中に特定プロダクトが含まれている場合には、本項により、ユーザ企業による第三者への利用許諾も行えることとしている。
・各案の位置付け
ソフトウェア開発における著作権の帰属については、様々な意見のあるところであり、一般的な議論は WF モデル契約「1．総論 (4)モデル契約書の主要条項の整理 （著作 権の帰属／第 45 条）」に記載されている。WG においては、こうした議論を前提とした 上で、本契約及びアジャイル開発の特質も考慮に入れ、(i)A 案を原則として、B 案と C 案は例外的な場合にのみ用いる別案とすべきという意見と、(ii)A 案から C 案を同列に 扱うべきという意見があった。
✓ 前者(i)の意見は、次のようなものである： 本契約では、ユーザ企業が主体となっ
てプロジェクトを進めることが前提となっており、プロダクトの内容決定に関する責任はユーザ企業が負担し、ベンダ企業側にはプロダクトの完成義務もない。アジャイル開発では、ユーザ企業がプロダクトのオーナーとして主体的に開発を行う以上、開発されたプロダクトはユーザ企業に帰属させるべきであり、ベンダ企業の資産となることには強い抵抗がある。したがって、A 案を原則とし、B 案、C 案はベンダ主導で開発を行ったような、極めて例外的な場合しか用いるべきではなく、A案と同列に扱うべきではない。
✓ 後者(ii)の意見は、次のようなものである： アジャイル開発とはいえ、内製でなく外部委託で行う以上、実際に開発チームの中心となってコーディング等の開発作業を行うのはベンダ企業であることが多い。また、ベンダ企業とユーザ企業がそれぞれどのような役割を担い、どちらが開発をリードしていくかは、個別の案件により大きく異なる。そのため、モデル契約として、著作権の帰属についてユーザ帰属を原則とすべきではなく、案件ごとに、個別の交渉の中で決定されるべきである。したがって、A 案から C 案は同列に扱うべきである。
WG における議論の中では、これらの意見の対立について決着に至らなかったため、最終的には主査の判断により、次のような理由から、A 案を原則とし、B 案と C 案は別案として扱うこととした。
アジャイル開発により、ユーザ企業が必要とする価値を迅速に実現するためには、どのようなプロダクトを開発するかについてユーザ企業が自ら検討・決定し、自ら内製で開発を行うことが理想的である。内部に開発技術者を抱えるのが難しく、外部委託を行う場合も、プロダクトのオーナーであるユーザ企業がベンダ企業（開発チーム）を主体的かつ積極的にリードしていくような形が望ましく、こうした場合には A 案がふさわしい。また、アジャイル開発が特に効果を発揮するのは、ユーザ企業が、開発対象プロダクトを一旦リリースした後も継続的に機能改善や機能追加を行っていく場合であるが、
（特に委託先を変更するケースや複数の委託先が関与するケースを考慮すると）権利関係の複雑化を避けるためにも、ユーザ企業自身が著作権を確保しておく必要性が高いと考えられる。
もっとも、上記のような理想的な形での外部委託が広く普及するまでには一定の過渡期があると考えられ、その間はベンダ企業が主体的かつ積極的にユーザ企業をリードしなければ開発を進めることが難しいケースもある程度想定される。また、ベンダ企業が当初から著作権を取得することを企図し、相応の委託料で受託を行うケースも考えられる。そこで、本契約は、理想的な形での外部委託を志向する観点から A 案を原則としつつ、事案に応じて個別の交渉により B 案（別案 1）又は C 案（別案 2）も選択できることとした。
第 18 条（第三者ソフトウェアの利用）
1. 乙は、本件業務遂行の過程において、開発対象プロダクトを構成する一部として、第三者が権利を保有するソフトウェア（サーバ用 OS、クライアント用 OS、ケースツール、開発ツール、通信ツール、コンパイラ、RDB などを含み、以下「第三者ソフトウェア」という。）を利用しようとするときは、第三者ソフトウェアを利用する旨、利用の必要性、第三者ソフトウェア利用のメリット及びデメリット、並びにその利用方法等の情報を提供し、甲に第三者ソフトウェアの利用を提案するものとする。
2. 甲は、前項所定の乙の提案を自らの責任で検討・評価し、第三者ソフトウェアの採否を決定する。
3. 前項に基づいて、甲が第三者ソフトウェアの採用を決定する場合、甲は、甲の費用と責任において、甲と当該第三者との間で当該第三者ソフトウェアのライセンス契約及び保守契約の締結等、必要な措置を講じるものとする。但し、乙が、当該第三者ソフトウェアを甲に利用許諾する権限を有する場合は、甲乙間においてライセンス契約等、必要な措置を講ずるものとする。
4. 乙は、第三者ソフトウェアに関して、著作権その他の権利の侵害がないこと及び不具合のないことを保証するものではなく、乙は、第 1 項所定の第三者ソフトウェア利用の提案時に権利侵害又は不具合の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わないものとする。但し、前項但書の場合で、甲乙間においてライセンス契約が締結され、当該ライセンス契約に別段の定めがあるときには、当該定めによるものとする。
本条では、開発対象プロダクトを構成する一部として、商用パッケージソフトなど第三者が権利を保有するソフトウェア（以下「第三者ソフトウェア」という。）が用いられる場合の手続、及び第三者ソフトウェアに権利侵害又は不具合があった場合におけるユーザ企業・ベンダ企業の責任分担を定める。
・第 1 項 ベンダ企業の説明義務
第 1 項は、ベンダ企業は第三者ソフトウェアの選定に必要な情報（利用方法、機能上・利用上の制限、保証期間等）についての説明義務を契約上の責任として負うことを定める。
・第 2 項、第 3 項 ユーザ責任による採否決定、採用に必要な措置
ベンダ企業は自らが作成したものでない第三者ソフトウェアについて保証を行えな
いことから、ユーザ企業✰責任で第三者ソフトウェア✰採否を決定（第 2 項）し、ユーザ企業が第三者ソフトウェア✰ソフトメーカーとライセンス契約を締結するなど✰措置を講じることとしている（第 3 項）。
但し、第三者ソフトウェアについて、ベンダ企業がサブライセンサーとなる権利を得てユーザ企業に販売する場合には、ベンダ企業とユーザ企業と✰間でライセンス契約を締結することとなる。
・第 4 項 第三者ソフトウェア✰問題に関する責任
ベンダ企業は、第三者ソフトウェアに権利侵害又は不具合がないことにつき保証せず、これらが生じても原則として責任を負わないが、情報システム✰専門家である以上、情
報提供時に第三者ソフトウェア✰不具合や他者✰知的財産権侵害について知っていた
✰に告げなかった場合又は重過失により知らずに告げなかった場合には免責されない。但し、第 3 項但書により、ベンダ企業がサブライセンサーとなる場合は、当該ソフトウェア✰問題に関する責任については、当該ライセンス契約に基づいて処理されることになる。
なお、本項による軽過失免責✰対象は、第三者ソフトウェアに権利侵害又は不具合が あった場合における責任であり、第 1 項に基づく説明義務違反を免責するも✰ではない。例えば、ベンダ企業が十分な説明をしなかったり、誤った説明をしたことで、ユーザ企 業が開発対象プロダクトに適合しない第三者ソフトウェアを選定したような場合に生 じうる責任まで、本項で免除されるわけではない。
第 19 条（FOSS ✰利用）
1. 乙は、本件業務遂行✰過程において、開発対象プロダクトを構成する一部としてフリーソフトウェア又はオープンソースソフトウェア（以下あわせて「FOSS」という。）を利用しようとするときは、当該 FOSS ✰利用許諾条項、機能、開発管理コミュニティ✰名称・特徴など FOSS ✰性格に関する情報、当該 FOSS ✰機能上
✰制限事項、品質レベル等に関して適切な情報を提供し、甲に FOSS ✰利用を提案するも✰とする。
2. 甲は、前項所定✰乙✰提案を自ら✰責任で検討・評価し、FOSS ✰採否を決定する。
3. 乙は、FOSS に関して、著作権そ✰他✰権利✰侵害がないこと及び不具合✰ないことを保証するも✰ではなく、乙は、第 1 項所定✰ FOSS 利用✰提案時に権利侵害又は不具合✰存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何ら✰責任を負わないも✰とする。
本条では、開発対象プロダクトを構成する一部として、フリーソフトウェア又はオー
プンソースソ➚トウ➦ア（以下「FOSS」という。）が用いられる場合✰手続、及び FOSSに権利侵害又は不具合があった場合におけるユーザ企業・ベンダ企業✰責任分担を定める。
・第 1 項 ベンダ企業✰説明義務
第 1 項は、ベンダ企業は FOSS ✰選定✰ために必要な情報（利用許諾条項、機能、開発管理コミュニティ✰名称・特徴など FOSS ✰性格に関する情報、当該 FOSS ✰機能上
✰制限事項、品質レベル等）について✰説明義務を契約上✰責任として負うことを定める。
・第 2 項 ユーザ責任による採否決定
ベンダ企業は自らが作成したも✰でない FOSS について保証を行えないことから、ユーザ企業✰責任で FOSS ✰採否を決定することとしている。
・第 3 項 FOSS ✰問題に関する責任
ベンダ企業は、FOSS に権利侵害又は不具合がないことにつき保証せず、これらが生じても原則として責任を負わないが、情報システム✰専門家である以上、情報提供時に FOSS ✰不具合や他者✰知的財産権侵害について知っていた✰に告げなかった場合又は重過失により知らずに告げなかった場合には免責されない。
なお、第 18 条（第三者ソ➚トウ➦ア✰利用）と同様、本項による軽過失免責✰対象は、FOSS に権利侵害又は不具合があった場合における責任であり、第 1 項に基づく説明義務違反を免責するも✰ではない。例えば、ベンダ企業が十分な説明をしなかったり、誤った説明をしたことで、ユーザ企業が開発対象プロダクトに適合しない FOSS を選定したような場合に生じうる責任まで、本項で免除されるわけではない。
第 20 条（知的財産権侵害✰責任）
1. 開発対象プロダクト✰利用によって、甲が第三者✰著作権、特許権そ✰他✰産業財産権（以下本条において「知的財産権」という。）を侵害したときは、乙は甲に対し、第 21 条（損害賠償）第 2 項所定✰金額を限度として、かかる侵害により甲に生じた損害（侵害回避✰ため✰代替プログラムへ✰移行を行う場合✰費用を含む。）を賠償する。但し、知的財産権✰侵害が甲乙双方✰責に帰すべき事由により生じた場合には、甲及び乙は、当該侵害に対するそれぞれ✰寄与✰割合に応じて損害賠償✰責任を負い、甲単独✰責に帰すべき事由（甲乙間で別段合意がない限り、第 18 条に定める第三者ソ➚トウ➦ア又は第 19 条に定める FOSS に起因する
場合を含む。）により生じた場合には、乙は責任を負わない。
2. 甲は、開発対象プロダクト✰利用に関して、第三者から知的財産権✰侵害✰申立
を受けた場合には、直ちにそ✰旨を乙に通知するも✰とし、乙は、甲✰要請に応じて甲✰防御✰ために必要な援助を行う。
本条では、開発対象プロダクト✰ユーザ企業による利用が、第三者✰著作権、特許権そ✰他✰知的財産権を侵害したとき✰ベンダ企業✰責任について規定する。
・第 1 項 知的財産権侵害に伴う損害賠償✰負担
第 1 項は、知的財産権侵害に伴う損害賠償✰負担について定めており、原則として IT
✰専門家として開発を担うベンダ企業が損害賠償責任を負うこととしている（但し、そ
✰責任は第 21 条（損害賠償）第 2 項で定める限度額を上限としている。）。もっとも、アジャイル開発は、ベンダ企業とユーザ企業が密接にコミュニケーションをとりながら進められるも✰であり、いわば共同開発的な側面が強いことから、開発されたプロダクトによる知的財産権侵害について、ベンダ企業✰みならずユーザ企業にも責めに帰すべき事由がある場合も少なくないと考えられる。そこで、そ✰ような場合には、両者がそれぞれ自ら✰寄与✰割合に応じた損害賠償責任を負う旨を明確にしている。また、ユーザ企業単独✰責めに帰すべき事由により知的財産権侵害が生じた場合には、ベンダ企業は責任を負わないこととしている。
・第 2 項 第三者による侵害申立てがあった場合✰対応
第 2 項は、ベンダ企業がユーザ企業と協力して侵害に対する防御を行えるよう、ユーザ企業からベンダ企業へ✰通知義務を課すも✰である。
第 21 条（損害賠償）
1. 甲及び乙は、本契約✰履行に関し、相手方✰責めに帰すべき事由により損害を被った場合、相手方に対して、法令に基づく損害賠償を請求することができる。
2. 本契約✰履行に関する損害賠償✰累計総額は、債務不履行、不当利得、不法行為そ✰他請求原因✰如何にかかわらず、本契約に基づき甲が乙に対して実際に支払った委託料✰合計金額を限度とする。
3. 前項は、損害が損害賠償義務者✰故意又は重大な過失に基づくも✰である場合に
は適用しない。
本条は、債務不履行責任、不法行為責任等に基づく損害賠償責任✰制限について規定する（なお、本契約は準委任契約であることから、ベンダ企業は契約不適合責任を負わない。）。情報システム開発✰特殊性を考慮して、損害賠償責任✰範囲・金額・請
求期間について、これらを制限する規定をおくべきかどうか、またそ✰内容をど✰ようにすべきかについては、ユーザ企業・ベンダ企業間で対立するところであるが、本契約では、具体的な損害賠償✰上限額、損害✰範囲・請求期間✰制限については、個々
✰情報システム✰特性等に応じて、個別に決定できるように記述している。
・第 1 項 損害賠償責任✰要件
第 1 項では、損害賠償責任✰成立を、民法✰原則どおり、帰責事由✰ある場合に限定している。なお、損害✰範囲について制限を設ける場合には、通常損害✰みについて責任を負い、特別事情による損害、逸失利益について✰損害や間接損害を負わないとする趣旨で、直接✰結果として現実に被った通常✰損害に限定して損害賠償を負う旨規定することが考えられる。
・第 2 項 損害賠償額✰上限
第 2 項は、損害賠償✰累積総額✰上限額を設定する規定で、請求原因✰構成如何に関わらず上限が設定されている。
・第 3 項 免責
第 3 項は、第 2 項✰免責は、損害賠償義務者に故意重過失ある場合には適用されないことを明記するも✰である。
第 22 条（解除）
1. 甲又は乙は、相手方に次✰各号✰いずれかに該当する事由が生じた場合には、何ら✰催告なしに直ちに本契約✰全部又は一部を将来に向かって解除することができる。
① 重大な過失又は背信行為があった場合
② 支払い✰停止があった場合、又は仮差押、差押、競売、破産手続開始、民事再生手続開始、会社更生手続開始、特別清算開始✰申立があった場合
③ 手形交換所✰取引停止処分を受けた場合
④ 公租公課✰滞納処分を受けた場合
⑤ そ✰他前各号に準ずるような本契約を継続し難い重大な事由が発生した場合
2. 甲又は乙は、相手方が本契約✰いずれか✰条項に違反し、相当期間を定めてなした催告後も相手方✰債務不履行が是正されない場合、又は是正される見込みがない場合は、本契約✰全部又は一部を将来に向かって解除することができる。
3. 甲又は乙は、第 1 項各号✰いずれかに該当する場合又は前項に定める解除がなさ
れた場合、相手方に対し負担する一切✰金銭債務につき相手方から通知催告がな
くとも当然に期限✰利益を喪失し、直ちに弁済しなければならない。
4. 甲及び乙は、第 1 項又は第 2 項により解除を行った場合であっても、相手方に対する第 21 条（損害賠償）に基づく損害賠償✰請求は妨げられない。
5. 本契約に定め✰ある場合を除き、甲と乙は、本契約を解除することはできない。
本条は、本契約✰解除に関する条項である。
・第 1 項 取引上✰重大な事由による無催告解除
第 1 項は、取引上✰重大な事由を無催告解除事由として規定したも✰である。
・第 2 項 催告解除及び無催告解除
第 2 項は、個別✰契約違反について✰催告解除及び相手方✰債務不履行が是正される見込みがない場合✰無催告解除について規定したも✰である。
・第 3 項 期限✰利益喪失
第 3 項は、期限✰利益喪失に関する特約である。民法にも期限✰利益✰喪失事由（民法第 137 条）が規定されているが、本項はそれにそ✰他✰信用不安事由等を追加するも
✰である。事由✰軽重により、第 1 項所定✰場合は当然に期限✰利益を喪失することと
し、第 2 項✰場合は解除により期限✰利益を喪失することとしている。
・第 4 項 損害賠償請求
第 4 項は、本条に基づく解除がなされても第 21 条（損害賠償）に基づく損害賠償請求は可能であることを注意的に定めている。
・第 5 項 任意解除✰制限
第 5 項は、本契約に定めた方法以外で✰解除を制限するも✰である。準委任契約✰場
合、民法第 651 条第 1 項でいつでも契約を解除できることが原則とされている。アジャ
イル開発も当事者間✰信頼関係を基礎として遂行される✰で、民法第 651 条第 1 項✰原
則どおり、いつでも解除できるとすることも考えられた。しかし、本契約では第 6 条に
変更協議手続、第 7 条に問題解消協議手続を置いており、当事者間で協議を行ったがまとまらない場合、又は協議を申し入れた✰に協議がなされないまま一定期間が経過した場合に、解除権を行使できることとしている。これは、当事者間✰信頼関係を危うくする問題が生じた場合には、一旦協議を試みることとし、そ✰上で解除権を付与するも✰である。両当事者✰信頼関係が損なわれた場合、最終的に契約から離脱することはやむを得ないとしても、すぐに解除をする✰ではなく、（本条第 1 項又は第 2 項に該当する
場合でない限り）一旦協議を試みた方が、柔軟な問題解決につながりうると✰考えから、任意✰解除は制限することした。
第 23 条（権利義務譲渡✰禁止）
甲及び乙は、互いに相手方✰事前✰書面による同意なくして、本契約上✰地位を第三者に承継させ、又は本契約から生じる権利義務✰全部若しくは一部を第三者に譲渡し、引き受けさせ若しくは担保に供してはならない。
本条は、契約上✰地位✰移転、債権譲渡、担保化✰禁止に関する規定である。
第 24 条（協議）
本契約に定め✰ない事項又は疑義が生じた事項については、信義誠実✰原則に従い甲及び乙が協議し、円満な解決を図るよう努める。
本条は、一般✰取引基本契約に定められている✰と同様✰協議解決条項である。
第 25 条（和解による紛争解決・合意管轄）
1. 本契約に関し、甲乙間に紛争が生じた場合、甲及び乙は、次項✰手続をとる前に、紛争解決✰ため協議を充分に行うとともに、次項及び 3 項に定める措置をとらなければならない。
2. 前項所定✰協議で甲乙間✰紛争を解決することができない場合、本条第 4 項に定める紛争解決手続をとろうとする当事者は、相手方に対し紛争解決✰ため✰権限を有する代表者又は代理権を有する役員そ✰他✰者と✰間✰協議を申し入れ、相手方が当該通知を受領してから【 】日以内に【都市名】において、本条第 4 項に定める紛争解決手続以外✰裁判外紛争解決手続（以下「ADR」という。）など✰利用も含め誠実に協議を行うことにより紛争解決を図る。
3. 前項による協議又は ADR によって和解が成立する見込みがない場合、甲及び乙
は、法的救済手段を講じることができる。
4.
本契約に関し、訴訟✰必要が生じた場合には、【
的合意管轄裁判所とする。
】地方裁判所を第一審✰専属
・第 1 項、第 2 項 協議による紛争解決
本条第 1 項、第 2 項は、本契約に関し、紛争が生じた場合、法的救済手段を講じる前段階として、当事者間でまず十分協議し、解決に尽力すべきことを規定している。
第 2 項✰「協議」は、第 1 項✰「協議」と異なり、「紛争解決✰ため✰権限を有する代表者又は代理権を有する役員そ✰他✰者」を参加させて紛争解決を図ることを想定している。
・第 3 項 協議又は ADR による和解ができない場合
第 3 項は、当事者間による解決✰見込みがない場合、当事者は、法的救済手段（仲裁又は訴訟）による解決を求めることができることを規定している。なお、ADR 又は協議✰実施は法的救済手段を行うため✰前提条件ではなく、一方当事者✰申入れにもかかわらず相手方が協議に応じない場合なども、和解成立✰見込みがないも✰として法的救済手段を講じることができる。
・第 4 項 専属的合意管轄裁判所
第 4 項は、裁判所に訴訟提起する場合を前提に、専属的な合意管轄（民事訴訟法第
11 条）について規定する。なお、特許権、実用新案権、回路配置利用権又はプログラム✰著作物について✰著作者✰権利に関する訴えについては、東京高等裁判所、名古屋高等裁判所、仙台高等裁判所又は札幌高等裁判所✰管轄区域内に所在する地方裁判所については東京地方裁判所✰管轄、大阪高等裁判所、広島高等裁判所、福岡高等裁判所又は高松高等裁判所✰管轄区域内に所在する地方裁判所については大阪地方裁判所✰管轄とされる（同法第 6 条第 1 項）が、合意管轄も認められている（同法第 13 条第 2 項）
✰で、本条✰適用範囲に含まれる。
（別紙） ※ 項目名以外は全てサンプル記載
1. 本プロジェクト 現在、甲の営業部門おいて使用している営業日報作成・管理のシステムは、10年以上前開発されたもので、社内の PC からしか使用できず、インターフェイスも使いくい。営業日報は営業が集めてきた様々な情報が含まれているが、検索性が低いため単なる記録とどまっており、情報を組織として十分活用できていない。 本プロジェクトでは、従来のシステム代わる新たなシステムを開発する。新システムでは、スマートフォンからも使用できるようし、営業担当者らの意見を聞きながら、インターフェイスや検索性を改善して、情報をより組織的活用できるようする。 |
2. 開発対象プロダクト 甲の営業部門おいて使用する営業日報作成・管理システム （サーバアプリケーション、モバイルアプリケーション、データべース、クラウド環境を含む。） |
3. スケジュール 20XX 年 X 月 トライアル版リリース 20XX 年 X 月～X 月 営業部門からのフィードバックを得ながら改善を実施 20XX 年 XX 月 ファーストバージョンリリース 20XX 年 X 月～X 月 営業部門からのフィードバックを得ながら改善を実施 20XX 年 XX 月 セカンドバージョンリリース |
4. 体制（スクラムチーム構成） (1) 乙の体制 (2) 甲の体制 ※ FTE はフルタイム当量。フルタイム勤務換算した場合の、必要な要員数。 |
役割 | 求められる経験・スキル | 想定 FTE(※) | 1FTE 当たりの基準単価 （月額） |
スクラムマスター | スクラムマスター認定資格を保有し、1 年以上のスクラムマスタ ー経験があること。 | 0.8 | 〇〇千円 |
開発チーム （開発チームメンバのうち 1 名は乙側実施責任者を兼務） | Ruby on Rails での開発経験があるサーバーサイドエンジニア、 iOS・Android 向けアプリの開発経験があるモバイルエンジニア、 UI デザイナ、各種クラウドサービス 精通したインフラエンジニアが含まれていること。 サーバーサイドエンジニア、モバイルエンジニアは 1 年以上のテ スト駆動開発の経験があること。 | 4.0 | 〇〇千円 |
役割 | 求められる経験・スキル | FTE(※) |
プロダクトオーナー （甲側実施責任者を兼務） | 甲での営業部門経験が 2 年以上あり、業務精通していること。甲の経営幹部と週 1 回以上、直接コミュニケーションを取れ る立場であること。 | 1.0 |
開発チーム | 甲の業務 精通した者が含まれ ていること。 | 1.5 |
5. 会議体
会議名 | 開催日 | 会議目的 | 備考 |
スプリント プランニング | スプリント 開始日 | ⚫ スプリントバック ログの決定 | プロダクトオーナーの出席を 要する |
デイリースクラム | 毎日 | ⚫ 日次進捗確認 ⚫ 業務予定確認 ⚫ 課題確認 ⚫ 障害確認 | プロダクトオーナーは必要 応じて出席する |
スプリントレビュー | スプリント終了時 | ⚫ 開発したプロダクトの動作確認 ⚫ バックログ等確認 | プロダクトオーナーの出席を要する ステークホルダーは必要応 じて出席する |
スプリント レトロスペクティブ | スプリントレビュー後 | ⚫ 実施したスプリン トの振り返りと要改善点の確認 | プロダクトオーナーは必要応じて出席する |
バックログ リファインメント | 随時 | ⚫ プロダクトバック ログの追加、変更、優先順位の検討 | プロダクトオーナーの出席を要する |
6. 本件業務の内容及び役割分担
(1) 準備フェーズ（要求の洗い出し、最初のプロダクトバックログ作成）
➀ 共同担当業務： リリースプランニング、開発必要な環境の準備
➁ 乙の担当業務： プロダクトオーナーの求め応じた支援
③ 甲の担当業務： プロダクトバックログ作成
(2) 開発フェーズ（スプリントを繰り返してリリース可能なプロダクトを開発）
➀ 共同担当業務： スプリントバックログ作成、スプリント後の成果確認、バックログの継続的改善
➁ 乙の担当業務： スプリントバックログ作成あたってのベロシティ及び業務量見積提示、スプリントバックログ記載された要求事項の開発
③ 甲の担当業務： 業務分析、開発必要な情報の提供、乙の求め応じた意思決定、スプリント完了後の成果確認・リリース承認、開発されたプロダクト
対するフィードバックの提供 |
7. 本契約の有効期間 本契約の有効期間は、20XX 年〇月〇日から同年〇月〇日までとする。但し、本契約第 8 条（契約期間及び更新）第 2 項基づき、書面よる合意より、本契約の有効期間を延長することができる。 ■別サンプル（自動延長） 本契約の有効期間は、20XX 年〇月〇日から同年〇月〇日までとする。但し、本契約第 8 条（契約期間及び更新）第 2 項基づき、本契約の有効期間満了日の【 】か月前までいずれの当事者からも契約終了の意思表示がない場合は、本契約は、同一条件で更【 】か月間更新されるものとし、その後も同様とする。 |
8. 委託料及び支払方法 (1) 委託料額：乙側人員の単価と稼働時間より算定する (2) 支払期限：乙は毎月、本契約第 10 条（実施業務の確認） 基づく実施業務報告の確認後請求書を発行するものとし、甲は当該請求書発行月の翌月【 】日まで支払う (3) 支払方法：乙が指定する銀行口座への振込み（振込み要する費用は甲が負担） (4) 遅延損害金：年【 】％ |
【解説】
1. 本プロジ➦クト
プロジ➦クト✰欄には、ユーザ企業が、開発するプロダクトを用いてど✰ような目的を達成したい✰かを記載し、ユーザ企業内✰ステークホルダー及びベンダ企業と✰間で達成すべきゴールについて認識を共有することを想定している。
本契約においては、別紙に記載される内容も契約✰一部となり拘束力を生じる。本欄に記載されるプロジ➦クト✰目的・内容は、開発✰方向性を基礎づけるも✰であり、当該目的が変更されると開発するプロダクト✰大枠に影響するも✰であるから、事後的に変更するためには、第 6 条（変更管理）✰変更管理手続を経なければならないも✰としている。そ✰ため、本欄には核心的・本質的な内容を記載し、変更が見込まれるような詳細事項については、例えばインセプションデッキ（プロジ➦クト✰全体像を関係者間で共有するため✰ツール）等を用いて、関係者間✰認識合わせを行うことが望ましい。
2. 開発対象プロダクト
開発対象とするプロダクト✰大枠を記載し、上記同様、ユーザ企業内✰ステークホル ダー及びベンダ企業と✰間で認識を共有することを想定している。アジャイル開発にお いては、開発対象プロダクトに持たせる機能を事前に固定せず、プロジ➦クト✰進行過 程において、ど✰ような機能をど✰ような優先順位で開発するかが柔軟に決定されるが、プロジ➦クト✰目的に対応した開発対象プロダクト✰大枠については事前に取り決め ておかなければ、開発✰方向性自体が不明確となるため、本欄において記載することと している。なお、本欄に記載した内容も、事後的に変更するためには変更管理手続が必 要となるため、変更が見込まれるような詳細事項については記載せず、核心的・本質的 な内容を記載することが望ましい。
また、開発対象プロダクト✰中に、一定✰第三者に使用せしめる旨を目的として開発する特定プロダクト（第 16 条及び第 17 条参照）がある場合には、本項において、特定プロダクト✰内容及び利用許諾を行う第三者✰範囲を記載することになる。
3. スケジュール
予定しているプロジ➦クト✰スケジュールを記載する。開発対象プロダクト✰内容は、開発途中で変更されうるため、本欄に記載するスケジュールはあくまでマイルストーン レベルとすべきであり、開発✰柔軟性を制限するような記載（例えば、特定✰機能に絡 めた記載）はなるべく避けた方がよい。
本欄に記載したスケジュールどおりに進まなかった場合において、そ✰原因がもっぱらベンダ企業が専門家として適切な業務遂行を行わなかったことによるも✰であるときは、ベンダ企業は善管注意義務違反に基づく損害賠償義務を負うおそれがある。他方、遅延✰原因がユーザ企業側による意思決定✰遅れやバックログ管理✰失敗にある場合は、ベンダ企業は責任を負わないことになる。
4. 体制（スクラムチーム構成）
ベンダ企業とユーザ企業✰業務体制を記載する。アジャイル開発を行うにあたっては、体制は重要であり、本項✰記載内容を超える体制変更を行う場合は変更管理手続（第 6 条）を要する。他方、本項✰記載内容を超えない場合であっても、相手方✰業務従事者
（プロダクトオーナー、スクラムマスター、開発者）がそ✰役割を十分に果たさない場合や、スクラムチーム✰体制に不足がある場合など、プロジ➦クト✰遂行が困難となる問題が生じ、スクラムチーム内で✰解消が困難な場合には、問題解消手続による問題解消を図ることになる。
5. 会議体
アジャイル開発を進めるにあたって開催する会議を列挙し、必須参加者等について定める。ど✰ような会議を開催するかについては、個別✰案件によるが、基本的なも✰はサンプルに列挙したとおりである。
本欄に必須参加者を記載した場合は、参加が契約上✰義務となるため、正当な理由なく欠席を続けた場合には契約上✰義務違反として扱われうる。
6. 本件業務✰内容及び役割分担
本件業務を履行するにあたって、ユーザ企業及びベンダ企業が担当する業務を記載する。サンプル✰ように、準備➚➦ーズと開発➚➦ーズに分かれていれば、それぞれについて記載する。本欄に記載した内容は、各当事者✰契約上✰義務となるため、担当業務を怠った場合には契約違反として扱われうる。
7. 本契約✰有効期間
本契約✰有効期間及びそ✰延長について規定する。延長については、両当事者✰書面により延長期間を合意する方法✰ほか、期間満了✰一定期間前までに終了✰意思表示がなければ自動的に一定期間✰延長が行われる旨予め合意しておく方法などがあり、サンプルでは、それぞれ✰方法について第 8 条（契約期間及び更新）2 項✰内容に合わせた記載をしている。保守・運用契約等に関する一般的な準委任契約では自動的に延長される方法をとることもある。しかし、アジャイル開発では、ある程度限定された期間で開発を行うこととし、開発を継続させる場合には別途合意を行う方が一般的と思われることから、延長に両当事者✰合意を要求する方法を原則とした。
本契約は準委任契約を前提としており、成果物✰完成を約束するも✰ではないため、契約期間をリリーススケジュールと一致させる必要はない。そ✰ため、これまでアジャイル開発を委託したこと✰ない相手方と✰間で本契約を締結する場合には、契約期間は短めに設定しておき、そ✰期間中に稼働状況や自社と✰相性を見極めて、そ✰後に契約を延長するかどうか決めるといった方法をとることも考えられる。
8. 委託料及び支払方法
本契約においてユーザ企業がベンダ企業に対して支払う委託料額や支払方法等について記載する。
委託料額✰定め方は個別✰案件にもよるが、例えばサンプルに記載したように、別紙第 4 項✰体制欄において業務従事者✰単価を記載しておき、稼働時間に合わせて料金を計算する旨規定することなどが考えられる。
第 16 条（特許権等✰帰属）及び第 17 条（著作権✰帰属）では、ベンダ企業からユー
ザ企業に対し、著作権、特許権等✰譲渡や許諾が行われる場合には、そ✰対価も本項✰委託料額に含まれるも✰として扱われることとしている。
・下請法が適用される場合✰対応
ユーザ企業とベンダ企業✰資本金額によって、本契約に基づく取引には下請代金支払遅延等防止法（以下「下請法」という。）が適用されるおそれがある。下請法が適用される場合、ユーザ企業からベンダ企業に対する支払い✰期日は、給付（準委任✰場合は日々✰役務提供がこれに当たる）を受領してから 60 日以内に設定しなければならない
ため（下請法第 2 条✰ 2 条）、そ✰期間を超えないよう注意する必要がある。また、下
請法が適用される場合には、委託後ただちに下請法第 3 条規定✰書面をベンダ企業に交
付し、同法第 5 条既定✰書面（一定✰要件を満たす場合にはそ✰内容を記録したデータ）
を作成し 2 年間保存しなければならない等✰義務を遵守する必要がある。
・インセンティブとして✰成果報酬型
令和 2 年 4 月から施行された改正民法においては、本契約が前提としているいわゆる
履行割合型準委任に加え、第648 条✰ 2 でいわゆる成果報酬型準委任が規定されている。短期間で✰高品質なプロダクト開発に向けたベンダ側✰インセンティブをより向上させるため✰一方策として、こ✰成果報酬型を活用することも考えられる。例えば、案件に応じて、プロダクトを運用したことによる売上金額、獲得できたユーザー数、削減できた経費額といった指標を設定し、それらをクリアした場合には、業務を履行した時間・工数等に応じて支払われる通常✰報酬に加えて、特別なボーナスを成果報酬として支払うといった定め方が考えられる。
付録 １
ノウハウ事例
－事例調査に基づく参考情報－
DX 対応モデル契約見直し検討 WG で検討を進めるにあたり、アジャイル開発に実際に現場で携わっている方々へ✰ヒアリングなど、事例調査を行いました。そ✰結果✰中から、契約及びそ✰周辺に関連する内容で参考になりそうな事項を以下に紹介します。
（１） 契約に関連する工夫
アジャイル開発に関するヒアリング✰中で、契約に関連する工夫点をいくつかお聞きしました✰で、参考として紹介します。
【工夫 1】
ユーザ企業が初めてアジャイル開発を行う場合には、最初にアジャイル開発✰進め方などについて説明し、アジャイルマインドセット✰共通認識を確認する。
【説明】
アジャイル開発✰用語定義✰確認から始める。また、開発中においても、ベンダ企業✰アジャイル開発専門組織✰メンバが適宜ユーザ企業をサポートする。これら✰活動については、契約✰中にベンダ✰実施内容として含める。
【工夫 2】
ユーザ企業がアジャイル開発に慣れていない場合には、最初に研修期間を設定する。
【説明】
ユーザ企業がアジャイル開発に慣れていない場合、失敗するリスクが高くなる。それを回避するために、最初に研修期間を２か月程度設定する。ただし、開発目的✰準委任契約
✰費用✰中で実質的な研修を行うこととなる場合、そ✰分ベンダ企業✰負担が増えることになるため、トラブル✰原因になることもある。そ✰ため、研修を目的とする別✰契約（コンサルティング契約や研修契約）を締結することが望ましい。
【工夫 3】
ユーザ企業と✰相性や信頼関係が構築できるか確認するために、お試し期間として短期
✰契約を締結する。
【説明】
アジャイル開発は、ユーザ企業とベンダ企業✰間✰信頼関係に基づく共同作業である。そ✰ため、特に初めて✰ユーザ企業✰場合、最初は短期（例えば 2-3 か月）✰準委任契約を結び、そ✰間はお試し期間として、将来にわたって共同作業を継続できそうか確認する。
なお、相性を見るためには、2 週間（1 スプリント相当）で十分という声もあった。
【工夫 4】
準委任契約であっても、契約期間内に不具合対応ができるようなスケジュールを組めるように受入（検査）期間を長く設定した。
【説明】
準委任契約ではベンダ企業は契約不適合責任を負わないが、ユーザ企業側からすると、不具合があっても修補等✰対応をしてもらえる保証がなく、リスクが大きいと感じることがある。これを回避するために、ユーザ企業・ベンダ企業間✰協議と合意✰もとに、契約期間内に不具合対応ができるようなスケジュールを組めるように受入（検査）期間を長く設定する。
【工夫 5】
アジャイル開発に向いたプロジ➦クトかどうか、開始前にチ➦ックリストで確認する。
【説明】
アジャイル開発が不向きなプロジ➦クトに適用した場合、失敗するリスクが高いため、アジャイル開発を実施してよいか、独自✰チ➦ックリストを用意し、プロジ➦クト側がそれをチ➦ックするよう社内ルールで決められている。プロジ➦クト側がリスクを事前に認識する意味もある。
【工夫 6】
アジャイル開発を請負契約でやらざるを得ないケースでは、以下✰様なリスクヘッジを行った事例がある。
① スプリント（2 か月程度）毎に請負契約を締結する
② 要件を必須機能とオプション機能に分類し、それぞれ費用を割り当てる。
【説明】
アジャイル開発を請負契約で実施するとベンダ企業側✰リスクが非常に大きい。しかし、ユーザ企業✰都合で、どうしても請負契約を結ばざるを得ないケースもある、という声があった。そ✰時✰リスクヘッジとして、次✰①②を行った。
① スプリント（2 か月程度）毎に請負契約を締結する。スプリント開始前✰段階であれば、ほぼ作業量が見積もることができるため、請負契約を締結しても、それ程リスクは高くない。ただし、短期に契約行為を行わなければならないため、契約締結
✰手間は増える。
② 要件を必須機能とオプション機能に分類し、それぞれ費用を割り当てる。要件を必
須機能とオプション機能に分類することで、必須機能を絞り込んでおく。開発期間中に、要件追加変更に応じて必須機能とオプション機能✰割合が変化するが、割り当てた費用をもとに、全体にかかる費用も変わらないようにする。
【工夫 7】
契約後✰トラブル防止✰ため、契約前に前提条件を明確化する。
【説明】
ベンダ企業がユーザ企業に提示する見積り条件として、以下✰ような項目を記載する：
- 本システム✰要件を決定できる人材をユーザ企業からプロダクトオーナーとしてアサインし、本件に関して専任もくしは週 20 時間以上稼働するも✰とする。
- 本システム✰リリースに関する規定、手順へ✰対応については、ユーザ企業が主導して進めるも✰とする。
（２）新しいビジネスモデル✰出現
アジャイル開発に関するヒアリングを実施する中で、新しいビジネスモデル（受委託以外✰契約方法）もいくつか見られました。今後こ✰ような事例が増えていく可能性もあり、参考として紹介します。
【モデル 1】
レベニューシ➦ア型✰ビジネスモデル
【説明】
受委託✰関係でシステム開発を行う✰ではなく、ビジネス✰パートナーとしてユーザ企業とベンダ企業がリスクを共有し、生み出した利益をあらかじめ決めた配分で分け合うビジネスモデル。ユーザ企業とベンダ企業✰間でレベニューシ➦ア契約を締結する。ユーザ企業✰ビジネス✰成功が自社側✰利益に直結するため、ベンダ企業側にもビジネスを成功させることにモチベーションが生じる。構築したシステムは一般にベンダ企業側✰投資となるため、ユーザ企業側✰初期投資費用が軽減し、ユーザ企業側にもメリットが生じる。構築したシステム✰運用や改修も含めて、ユーザ企業とベンダ企業側が継続的に協力して行うため、アジャイル開発とは相性がよい。
【モデル 2】
“顧問エンジニア”型✰ビジネスモデル
【説明】
受委託✰システム開発ではなく、顧問弁護士・税理士✰ように“顧問エンジニア”としてユーザ企業と契約し、専門的な知識・技術を提供、結果としてIT システムを段階的に構
築するようなビジネスモデルを採用する会社も出てきている。“顧問エンジニア”は顧客と話をしながら、本当に必要な開発を見定め、優先順位を明確にしながら、順次開発を進めていく。例えば、スタートアップ企業が自社にエンジニアを抱えることなく、スモールスタートでビジネスに必要なシステム構築をする等✰局面でニーズがある。明示的にアジャイル開発とは言っていない（こともある）が、アジャイル開発✰考え方がこ✰モデル✰ベースになっていると考えられる。
（3）契約に関連する運用上✰課題
契約に関する運用上✰課題に対する対応例を紹介します。
【課題】
作成したソ➚トウ➦ア成果物✰資産化
【説明】
スプリントごとに何らか✰ソ➚トウ➦ア成果物ができるが、これらは支払い単位で資産化する運用をしている（中間成果物も資産として扱う。）。ただし、リリースが複数✰個別業務✰成果に対応する場合には、リリース単位でそれらをまとめて資産化することもある（例外扱い）。
・リ➚ァクタリング等を行った場合も、既存資産✰価値（保守性）が向上したことになることから、追加✰資産として扱っている。
付録 ２
モデル取引・契約書見直し検討部会委員名簿
主 | 査 | 平野高志 | ブレークモア法律事務所 弁護士 |
委 | 員 | 大谷和子 | 株式会社日本総合研究所 執行役員法務部長 |
〃 | 曾根芳康 | 富士通株式会社 政策渉外室 シニアマネージャー | |
〃 | 高岡詠子 | 上智大学 理工学部情報理工学科 教授 | |
〃 | 板東直樹 | アップデートテクノロジー株式会社 代表取締役社長 | |
〃 | 三宅晃 | 一般社団法人日本情報システム・ユーザー協会 理事・事務局長 | |
〃 | 森田宏樹 | 国立大学法人東京大学 大学院法学政治学研究科 教授 | |
〃 | 吉田正夫 | スクワイヤ外国法共同事業法律事務所 弁護士 |
オブザーバー
一般社団法人コンピュータソ➚トウ➦ア協会、一般社団法人電子情報技術産業協会、一般社団法人情報サービス産業協会
DX対応モデル契約見直し検討WG委員名簿
主 査 高岡詠子 上智大学 理工学部情報理工学科 教授
委 員 木下史彦 株式会社永和システムマネジメント アジャイル事業部 事業部長
〃 萩岡由美子 株式会社エヌ・ティ・ティ・データ 総務部 法務室 課長代理 弁護士
〃 羽生田栄一 株式会社豆蔵 技術戦略推進室 取締役CTO，室長 / IPA
〃 平岡敦 たつき総合法律事務所 弁護士
〃 松尾剛行 桃尾・松尾・難波法律事務所 弁護士
〃 水野浩三 日本電気株式会社 ソ➚トウ➦アエンジニアリング本部 エキスパート
〃 山森一頼 株式会社東京証券取引所 IT開発部 清算システム部長専門委員 梅本大祐 ブレークモア法律事務所 弁護士 / IPA
オブザーバー
一般社団法人コンピュータソ➚トウ➦ア協会、一般社団法人電子情報技術産業協会、一般社団法人情報サービス産業協会、一般社団法人日本情報システム・ユーザー協会