モデル契約、アジャイル開発、スクラム、準委任契約、プロダクトオーナー、スクラムマスター、プロダクトバックログ、スプリントバックログ、偽装請負、変更管理、損害賠償責任、著作権の帰属、ＦＯＳＳ
これまで情報システムの外部開発に関する契約のモデルとして、
経済産業省『情報システム・モデル取引・契約書（第一版）』平成１９年
経済産業省『情報システム・モデル取引・契約書（追補版）』平成２０年
が策定されていました。
第一版は、重要インフラ・企業基幹システムの受託開発情報システムを発注するときの契約を取り扱っており、対等に交渉力のあるユーザ・ベンダ前提にしています。それに対して追補版は、第一版を元に、中小企業等におけるパッケージソフト、ＳａａＳ／ＡＳＰ等の活用と保守、運用を含めた情報システム構築のためのモデル取引と契約のあり方を対象としています。
これらに関しては、「情報システム・モデル取引・契約書」を参照してください。
近年、ＡＩや５Ｇなど情報通信技術の変革が進んでおり、それらの変化をビジネスに取り込むことが従来以上に重要だとされ、情報システムでのＤＸ（Dijital Transformaition）の導入が緊急関心事になってきました。 ＩＴの発展や社会の変化に即応するには、情報システムはクラウド環境でのアジャイル開発が求められます。アジャイル開発ではウォータフォール開発とは異なる開発方法になるので、取引・契約もそれに合致したものであるべきです。
このような動向により、経済産業省・ＩＰＡは、２０２０年に、
「アジャイル開発外部委託モデル契約～情報システム・モデル取引・契約書＜アジャイル開発版＞～」
（https://www.ipa.go.jp/files/000081484.pdf）
を策定しました。
モデル契約
第１条（目的）
第２条（アジャイル開発方式）
第３条（体制）
第４条（甲（ユーザ企業）の義務）
第５条（乙（ベンダ企業）の義務）
第６条（変更管理）
第７条（問題解消協議）
第８条（契約期間及び更新）
第９条（文書作成）
第１０条（実施業務の確認）
第１１条（委託料及び支払方法）
第１２条（甲が乙に提供する資料等及びその返還）
第１３条（再委託）
第１４条（秘密情報の取扱い）
第１５条（個人情報の取扱い）
第１６条（特許権等の帰属）
第１７条（著作権の帰属）
第１８条（第三者ソフトウェアの利用）
第１９条（ＦＯＳＳ（フリーソフトウェア又はオープンソースソフトウェア）の利用）
第２０条（知的財産権侵害の責任）
第２１条（損害賠償）
第２２条（解除）
第２３条（権利義務譲渡の禁止）
第２４条（協議）
第２５条（和解による紛争解決・合意管轄）
別紙
１ 本プロジェクト（開発すべきシステムの概要と留意事項）
２ 開発対象プロダクト
３ スケジュール
４ 体制（スクラムチーム構成）
（プロジェクトマスター、スクラムマスター、チームメンバの必要な経験・スキルと要員数など）
５ 会議体（スクラムの実施、各種レビューの頻度や参加者）
６ 本件業務の内容及び役割分担（準備フェーズ、開発フェーズでの、甲・乙・共同の担当業務）
７ 本契約の有効期間
８ 委託料及び支払方法
第１条（目的）
本契約は、甲が本プロジェクトの目的達成のためにアジャイル開発方式を用いたプロダクト開発を行うにあたり、準委任によりその開発支援を乙に委託し、乙がこれを受託することに関し、甲と乙がお互いに協力して行う業務の内容や、甲と乙の権利及び義務について定めることを目的とする。
さらに第２条では、「アジャイル開発方式として、最も広く用いられているスクラムを用いる」としています。
これらに関しては、「システム開発技法」を参照してください。
契約の種類については、「契約の種類」を参照してください。
ウォータフォールでのシステム開発では、要件と対価を固定した請負契約にするのが通常ですが、追加・変更が生じたとき、ユーザ企業は見積のうちだから追加費用は不要だと主張し、ベンダ企業は契約になかった新要件だとして追加費用を要求するなど、両当事者間の利害対立を招くリスクがあります。変更が前提であるアジャイル開発では不適切です。
準委任契約とは、「受任者は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う。」契約です。専門家としての注意義務を果たしながら業務を遂行することを義務付ける準委任契約の方が、その性質上、アジャイル開発契約には馴染み易いとしています。
ベンダ企業は成果物の完成義務は負わないものの、本件業務の履行に当たり善管注意義務（民法第６４４条）を負うことになります。開発対象プロダクトに不具合があったり、セキュリティ等の非機能要件の不備があったりしたとしても、ユーザ企業はベンダ企業に対して、成果物に関する契約不適合責任を追及することはできません。もっとも、それらの問題がベンダ企業の善管注意義務違反によるものである場合には、ユーザ企業はベンダ企業に対して損害賠償請求をすることができます。
体制については、第３条（体制）、第４条（甲の義務）、第５条（乙の義務）などで示しています。
開発体制は、プロダクトオーナー、スクラムマスター、チームメンバで構成されます。
プロダクト（開発システムの成果）に関する責任者です。ユーザ企業が選任します。ユーザ企業がアジャイル開発に慣れておらず、適任者がいないときは、ベンダ側にプロダクトオーナー補佐を出してもらうこともあるが、プロダクトオーナーの職務自体をベンダ側に委ねてはなりません。
プロダクトオーナーの任務は次のとおりです。
スクラムのマネージャのような役割で、ベンダ企業が選任します。
アジャイル開発においては、プロジェクトマネジメントはスクラムチーム全体で担うべきものであり、スクラムマスターがプロジェクトマネージャーとしてプロジェクトの進行に責任を負うわけではありません。
例えば外部による割込みから開発チームを守ったり、スクラムチームが悩んでいる問題を解消するための相談に乗り、外部と交渉を行ったりすることが求められます。
ユーザ企業、ベンダ企業の双方からメンバを選任するのが通常ですが、ベンダ企業メンバだけのこともあるとされています。
スクラムチームを構成し、密接にコミュニケーションを取りながら開発を進めるので、両者の信頼関係が極めて重要です。
ユーザ企業が自ら再委託先を指定するのは、再委託も準委任契約ですから、ベンダ企業への影響は少ないと考えられます。
それに対して、ベンダ企業が再委託を行う際には、ベンダ企業が再委託先の能力を慎重に検討した上で、ユーザ企業による評価・承認を得て、再委託を行うこととすべきだとしています。
第１４条（秘密情報の取扱い）、第１５条（個人情報の取扱い）においても、再委託については、別途ユーザ企業の事前承諾を必要になります。
アジャイル開発においては、進め方を固定してしまうのではなく、スクラムチームが自らの特性やプロジェクトの内容に合わせて最適な進め方を模索し、柔軟かつ自律的に改善を行っていくことが推奨されます。
開発の管理は、常にバックログ（未完成要件）を確認し、それを解決して減らすという手続きで行います。
開発システムでの未完成の要件のことです。開発直前では要件定義に相当し、機能要件、非機能要件を含みます。スクラムの進行により、削除・追加が行われます。プロダクトバックログがなくなったときが開発完了になります。
プロダクトバックログには、新規機能の開発だけでなく、業務を行う前の実現性調査等、非機能要件への対応や、リファクタリング（一旦開発された機能について、保守性や拡張性を高めるため、外的な動作は変えないまま内部構造を作り変えること）、文書作成等の関連業務なども含みます。
プロダクトバックログの作成権限と管理責任はプロダクトオーナーが、開発チームと協議の上作成します。
また、プロダクトバックログの変更は、責任の所在を明確にするために、本項では要求事項の追加を含む変更をユーザ企業の権限としています。
スクラム開発では、短期間で反復しながら効率的に開発を進めますが、その１サイクルをスクラム開発ではスプリントといいます。
スプリント開始時点で、このスプリントで達成すべき事項をスプリントバックログとしてリストに作成します。スプリント内で達成したものはリストから削除されますが、新規に追加、変更されることもあります。スプリント終了時には成果確認を行ないます。
スプリントバックログは、ユーザ企業がベンダ企業と合意の上作成します。その変更も同様です。
変更は短時間で決定する必要があるので、その都度管理者の承認を得るのが困難なことがあります。合意があった事実を後から証明できるよう、両当事者のメールのやりとりで確認を行い記録に残したり、両当事者がスプリントバックログの備考欄等に内容を了解した旨記載したりする必要があります。
スクラム開発では、ユーザ企業とベンダ企業の双方が一緒に作業をします。本来は両者は対等な立場であるべきですが、とかくユーザメンバが優位な立場になりベンダメンバを指揮するようなことが発生します。これは、派遣労働者法での偽装請負に抵触します。
あくまでも提案や助言であるり指示ではないことを認識する必要があります。
また、両社間の連絡や確認を明確にするために、連絡窓口として両社が選任した「実施責任者」を通して全ての連絡を行うのが基本ですが、スクラムでは各メンバが互いに提案や助言を行い合意すれば直ちに対応するので、対等な立場での提案や助言まで、実施責任者を通さなければならないとすることは、アジャイル開発の実態にそぐわないという意見もあります。
アジャイル開発では、変更が頻繁に発生します。
日常的な変更管理は、第６条で次のように示しています。
第６条（変更管理）
定例の連絡協議会を設置し、変更合意の明確な証拠を残し後日のトラブルを避けるため、両当事者の記名押印のある変更合意書を作成します。
この変更管理が円滑に行われないとき、スクラムチーム内では当該問題の解消が困難なときは、第７条で「問題解消協議」を開催することを示しています。
要求事項の未実現、誤動作、納期遅れなど、開発途中や開発完了後でトラブルが発生することがあります。
準委任契約であることから、ベンダ企業は契約不適合責任を負いません。しかし、善管注意義務違反を問われることはあります。
本契約では、具体的な損害賠償の上限額、損害の範囲・請求期間の制限については、個々の情報システムの特性等に応じて、個別に決定できるとしています。
ソフトウェア（文書も含む）の著作権は、格別の取り決めがない場合は、直接の作成企業に帰属することになっていますが、アジャイル開発では、ユーザメンバとベンダメンバのどちらが作成者かを明確にできず「共同」となることがあります。
モデル契約では、一つに決めることは無理があるとして、Ａ・Ｂ・Ｃの３案を示し、Ａ案を原則とするが別案も採用できるとしています。
乙作成 甲乙共同作成 甲作成
汎用プロ それ以外 汎用プロ それ以外 汎用プロ それ以外
グラム グラム グラム
Ａ案 乙 甲 甲 甲 甲 甲
Ｂ案 乙 乙 共有 共有 甲 甲
Ｃ案 共有 共有 共有 共有 甲 甲
アジャイル開発では、短期間開発でクラウド環境での開発も多いことから、ＦＯＳＳ（フリーソフトウェアやオープンソースソフトウェア）の利用が多くなります。このとき、ＦＯＳＳの著作権、利用制限、品質保証などが問題になります。