アジャイル型ソフトウェア開発委託契約書の検討（ウォーターフォール型との比較から）

１．はじめに

本記事では、アジャイルでのソフトウェア開発をベンダに委託する場合に、アジャイルの特徴を業務委託契約書にどのように反映するか、ウォーターフォール型との比較という観点から検討したいと思います。

２．ソフトウェア開発の手法

ソフトウェアの開発の手法としては、伝統的なウォーターフォール型と近年普及しているアジャイル型と呼ばれるものがあります。

ウォーターフォール型は、開発対象となるソフトウェア全体の要件や仕様を開発当初の要件定義の段階で確定した後、外部設計（画面や帳票などのインターフェースの設計）、内部設計（機能要件等のハードウェア、ソフトウェア等による実現方式の設計、処理の内部ロジックの設計）、プログラミング、運用テストといった各工程を計画的に進めていく手法です。滝が上から下に流れ落ちるように、開発工程をいくつかの段階に分け、その段階での作業が終わると前段階に逆戻りすることなく、順序通りに開発を進める点が特徴です。また、契約という観点からいうと、要件定義段階、外部設計段階、内部設計段階、運用テスト段階といった各段階で個別契約を締結する方式（多段階契約）が一般的です（注1）。

ウォーターフォール型は、開発当初の段階で、ソフトウェア全体の要件や仕様を確定する必要があるため、ユーザ（開発を委託する側）は、ベンダ（委託を受けて開発する側）から支援を受けて要件定義を確定し、その後の段階に進んでいきます。ベンダ側としては、要件定義を確定することで、その後の作業にどの程度の人員や時間が必要かの見通しを立てやすいというメリットがあります。また、個別契約を多段階で結ぶことにより、一旦その段階での業務が終了すれば、ベンダは、再度その段階での業務をする義務を負わないので、例えば、ユーザから要件定義終了後に仕様変更を求められた場合に、追加の業務に対する追加料金を請求しやすい、というメリットがあります。ユーザ側としても、要件定義が確定することで、ソフトウェアの完成形をイメージしやすいですし、多段階契約であれば、例えば、要件定義が終わった段階で、作りたいソフトウェアのイメージと違った場合やその後のソフトウェア開発に要する費用が想定より多額になった場合に、その後の契約を結ばない（開発プロジェクトを終了する）、という選択をとれる、というメリットがあります。

一方で、ウォーターフォール型の場合、開発当初で要件や仕様を固める必要があるため、開発完了までに時間がかかりますし、途中で仕様を変更することが難しいというデメリットがあります。

このようなウォーターフォール型に対し、開発当初から要件や仕様を確定するのではなく、要件定義が不完全なまま、プログラミングやテストをしていき、上手くいかなければ、その機能や仕様を変更するなどして改善をしていき、ソフトウェアを開発完了までもっていく手法がアジャイル開発と呼ばれるものです。アジャイル開発では、1週間から1か月程度の一定の期間（「スプリント」、「イテレーション」と呼ばれています）が設定され、その期間の中で要件定義、プログラミング、テストを行います。第1スプリントで要件定義、プログラミング、テストを行い、第2スプリントでは、第1スプリングで上手くいかなかった機能や第1スプリントで開発しなかった機能について、要件定義、プログラミング、テストを行っていく、というように、短期間でのトライ＆エラーを繰り返しながら必要な機能を徐々に実装していき、ソフトウェアの完成を目指すイメージです。

アジャイル開発では、ウォーターフォール型に比べて、スピード感のある開発ができますが、ユーザとベンダが密接なコミュニケーションをとりながら開発を進めていく必要があることから、ユーザとしては、ベンダを選定するだけでは足りず、ソフトウェア開発の方向性や内容に主体的かつ積極的な関与が必要となり、ユーザとしても一定の知見やスキルが求められます。

以上のウォーターフォール型とアジャイル開発の特徴からすると、ウォーターフォール型開発に向いた開発とアジャイル開発に向いた開発は以下の通りとなります。

〇ウォーターフォール型開発
・当初からユーザの要求事項がある程度明確な場合（例．企業の基幹システム）
・ユーザにソフトウェア開発の知見が少なく、ベンダに開発を頼りたい場合

〇アジャイル開発
・ユーザの要求事項が当初から明確でなく、開発を進めていきながら、機能や仕様を確定したい場合
・ユーザにソフトウェア開発の知見やスキルがあり、ベンダと協力してスピード感のある開発を進めたい場合

なお、アジャイル開発の中にもスクラム、カンバンといった分類の開発手法がありますが、短期間に活動を繰り返しながら段階的に開発を進めていき、その繰り返しの中でベンダとユーザのコミュニケーションを密に行うという本質的部分は共通しています。

３．アジャイル開発の特徴を踏まえたソフトウェア開発委託契約書の検討

(1)　モデル契約

ソフトウェア開発の契約書については、いくつかのモデル契約が公表されています。

〇ウォーターフォール型
・一般社団法人電子情報技術産業協会（JEITA）
「ソフトウェア開発モデル契約（2020年版）
https://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=1137
・独立行政法人情報処理推進機構（IPA）、経済産業省（2019年12月24日公開）
「ソフトウェア開発委託基本モデル契約書」
https://www.ipa.go.jp/ikc/reports/20191224.html

〇アジャイル開発
・独立行政法人情報処理推進機構（IPA）、経済産業省（2020年3月31日公開）
「アジャイル開発外部委託モデル契約」
https://www.ipa.go.jp/ikc/reports/20200331_1.html
・一般社団法人情報処理学会「情報処理に関する法的問題」研究グループ（LIP）
「アジャイル開発向けソフトウェア開発委託契約書（準委任型）」（2020年6月7日公開版）
http://www.ipsj.or.jp/sig/lip/

ソフトウェア開発委託契約書を作成する場合は、上記のモデル契約が参考になります。ただ、アジャイル開発に関するモデル契約は、プロジェクト体制や進め方についてかなり具体的に定めている一方で、ベンダやユーザの体制や開発の進め方は、プロジェクトによって異なりますので、モデル契約をそのまま使用すると実態に沿わない契約書になる可能性があります。

そこで、上記モデル契約を理解し、実際のプロジェクトに沿った契約書にアレンジできるように、アジャイル開発の特徴について、検討していきたいと思います。

(2)　契約形態（請負か準委任か）

ソフトウェア開発の契約形態としては、請負契約とする方法と準委任契約とする方法が考えられます。請負契約の場合、注文者（ユーザ）が、請負人（ベンダ）に、仕事の完成（成果物の完成）を依頼し、完成した仕事（成果物）に対して代金を支払うことが契約の本質的な内容となります。そのため、事前に成果物の内容を具体的に特定することができ、ベンダが主体となって業務を進める場合に選ばれることが多いといえます。例えば、JEITAのモデル契約では、ウォーターフォール型におけるソフトウェア開発フェーズの契約について、それまでのフェーズで確定した仕様書に基づきソフトウェアを作ることは、請負的作業であるとしています（注2）。

一方、事前に成果物を特定できず、ベンダが自身の有する知見やノウハウをユーザに提供することが目的となる場合は、役務提供型の契約類型である準委任契約がなじむと言えます。例えば、JEITAのモデル契約では、ウォーターフォール型における要件定義フェーズの契約について、要件定義はユーザが社内の利害関係者との調整のうえ、必要な機能要件を分析、整理、決定するプロセスであり、ベンダは、ユーザがこれらの作業をする過程で、技術的アドバイスを提供するものにすぎないことから、準委任としています（注3）。

なお、準委任契約には、役務の提供を対価の条件とする履行割合型準委任（例．コンサルティング業務のタイムチャージ）と、役務提供に基づく一定の成果の達成を対価の条件とする成果報酬型準委任（例．弁護士の成功報酬、不動産仲介業者の報酬）がありますが、JEITAでは、上記の要件定義フェーズの契約について履行割合型準委任を前提としています（注4）。

アジャイル開発の場合、開発を進めながら仕様を決定していくという性質上、事前に特定された成果物を作成する、という請負契約や成果完成型準委任よりも、専門的知見に基づく役務を提供し、それに対し対価を受け取る役務提供型準委任がなじむと考えられます（注5）。IPAやLIPのモデル契約でも準委任契約を採用しています。

(3)　当事者の役割（業務）

前述の通り、アジャイル型の場合、ユーザによる開発プロセスへの主体的・積極的な関与が必要とされます。具体的には、以下のように開発を進めていきます。

ユーザからは、プロダクトの方向性や意思決定に対する責任者（プロダクトオーナー）を選任します。ベンダからは、開発の責任者（スクラムマスター）と、開発作業を遂行するメンバー（開発チーム）を選任することになります。ユーザの社内にシステム開発部門がある場合、開発チームはユーザとベンダそれぞれの人員で構成されることもあります。そして、プロダクトオーナー、スクラムマスター、開発チームから構成されるチーム（スクラムチーム）で協力して開発を進めていきます（注6）。

①まず、開発作業に入る前に、ユーザとベンダで、どのようなプロダクトを作りたいか（ビジネスゴール）、そのためにはどのような要求事項が必要か、要求事項が複数ある場合、優先順位をどうするかを話し合い、ユーザの要求事項をリスト化します（プロダクト・バックログ）。②続いて、開発段階に入りますが、アジャイル開発では、スプリントという期間（1週間から4週間程度）を区切った開発を繰り返して開発を進めることになります。スプリントの最初に、開発チームでミーティングを行い（スプリント計画ミーティング）、ユーザ（プロダクトオーナー）とベンダ（スクラムマスター）でプロダクト・バックログのうち、そのスプリントで開発対象とするものと完成基準について認識を擦り合わせて決定します（スプリント・バックログ）。③スクラムマスターはそのスプリントでの作業（タスク）を開発チームのメンバーに割り振り、各メンバーは、それぞれ割り振られたタスクを仕上げていきます（スプリントの期間中も定例の朝会などを行い、開発チームの進捗状況を確認します）。④一つのスプリントの終わりには、プロダクトオーナー、スクラムマスター、開発チームでタスクの処理を確認、評価し（スプリントレビュー）、その次のスプリントでの課題や改善方法を確認します（スプリントレトロスペクティブ）。こうしたスプリント（②～④）を繰り返してプロダクトを完成させていきます（その他、必要に応じて随時、ユーザとベンダで協議を行います）。

以上を踏まえると、ユーザとベンダの役割（業務）としては、以下の通り整理することができます。

〇共通の役割（業務）
・スクラムチームを構成し、互いに協力のうえ、ソフトウェアの開発に尽力する

〇ユーザの役割（業務）
・専門的知識、ノウハウを有した適切なプロダクトオーナーの選任
・スプリント計画ミーティング等の会議体への出席
・プロダクト開発に必要な情報提供や意思決定（プロダクト・バックログ、スプリント・バックログの作成を含む）の実施
・ベンダが開発したプロダクト（スプリント・バックログを含む）の完了確認
・その他、ベンダから開発対象となるプロダクト（プロダクト・バックログ、スプリント・バックログを含む）や開発方針に関する質問への回答等

〇ベンダの役割（業務）
・専門的知識、ノウハウを有した適切なスクラムマスター、開発チームの選任
・スプリント計画ミーティング等の会議体への出席
・スプリント計画ミーティング等の会議体で合意した内容に従ったプロダクト開発の遂行
・その他、開発対象となるプロダクトや開発スケジュールに関する援助、助言、提案

準委任契約では、ベンダは、善良なる管理者の注意義務をもって、上記のベンダの役割（業務）を果たす必要があります（民法644条）。特に、ソフトウェア開発においては、システム開発の専門家としてプロジェクトマネジメント義務（注7）が課せられることが一般的ですので、アジャイル開発であっても、プロダクトの開発について、積極的な説明やアドバイスをすることが求められます。

一方で、準委任契約におけるユーザの義務は、第一に業務委託料（開発費）の支払義務ですが、システム開発はユーザ側の協力（適時適切な要望・情報の提供、ベンダとの合意事項の遵守等）も必須であることから、プロジェクトの遂行についてユーザにも協力義務（注8）が課せられることには注意が必要です。

(4)　具体的な業務内容

ウォーターフォール型の場合は、フェーズごとに行う業務の内容や成果物を契約書に記載していくことになります。

一方で、アジャイル開発の場合、プロダクトオーナー、スクラムマスター、開発チームが協力して、スプリントを繰り返していくことから、そのような業務の実施手順を定めることで、双方の業務の内容をより具体化し、開発を円滑に進めることができると思います。

アジャイル開発での具体的な進め方は前述した通りですが、整理すると、以下の通りとなります。

〇業務の実施手順
・プロジェクト開始時にユーザとベンダでスクラムチームを組成する。
・開発段階（スプリント）が始まる前に、開発チーム（主にプロダクトオーナーとスクラムマスター）でプロダクトに関するユーザの要求事項（プロダクト・バックログ）、優先順位について協議する。
・開発段階では、スプリント（1週間から4週間程度）を繰り返すことで開発を進める。
・一つのスプリントが始まる際に、開発チームで、そのスプリントで開発するユーザの要求事項（スプリント・バックログ）について協議し（スプリント計画ミーティング）、合意する。その後、ベンダは、タスク（プログラミング、テスト）を実施する。スプリントの終わりに、スクラムチームでタスクの確認、評価を行い（スプリントレビュー）、課題や改善方法を確認する（スプリントレトロスペクティブ）。
・次のスプリントでは、最初に、開発チームで協議を行い（スプリント計画ミーティング）、前回のスプリントの結果を踏まえ、今回のスプリングで開発する要求事項（スプリント・バックログ）を合意したうえで、そのスプリントでのタスクの実施、確認（スプリントレビュー、スプリントレトロスペクティブ）を行う。
・以上の作業を契約で定められた期間繰り返し行う。
・その他、開発チームでは必要に応じて協議を行う（定例の朝会、臨時会等）。

なお、アジャイル開発では、トライ＆エラーを繰り返しながら、完成に向けて開発を進めていきますが、その過程で当初プロダクトオーナーから提示された要求事項を変更することもあります。その場合、ベンダとしては、変更についてプロダクトオーナーから合意を得たことを記録として残しておくことが肝要です（スピード感の重視や手間の削減の観点から議事録を作らないことも多いでしょうから、管理ツールやチャットツールなどを利用して形に残るようにプロダクトオーナーの合意を得ることが考えられます）。

(5)　契約期間

アジャイル開発の場合、開発チームが密接なコミュニケーションを取りながら開発を進めていきますので、各メンバーのスキルはもちろん、人間関係も重要になってきます。そのため、当初から長期の契約を結ぶよりも、最初は、短期の契約とし、ベンダのスキルや相性を確認したうえで、契約期間を延ばしていくことを検討しても良いと思います。

(6)　業務委託料

ウォーターフォール型の場合、ベンダがフェーズごとに必要な費用を見積もり、確定額（例えば、内部設計費用として○○万円といった請求）で発注することが多いですが、アジャイル開発の場合、ベンダの人員単価と稼働時間により算定することが一般的です。これも完全なタイムチャージ方式から、事前に一定の基準時間で業務委託料を算出し、基準時間を超過または過少した場合に、業務委託料を精算する方式（例えば、1か月の作業時間として120時間～150時間を基準とし、その時間を超過または過少した場合は、30分当たり○○円を加算または控除するといった計算方法）が考えられます。

(7)　ベンダの債務不履行、不法行為責任

準委任契約に基づくベンダの義務は、仕事の完成ではなく、善良なる管理者の注意義務をもって業務を遂行すること（及び契約上または信義則上のプロジェクトマネジメント義務の履行）ですので、これを怠ると債務不履行責任、不法行為責任が生じることになります。具体的にどのような場合にベンダの責任が認められるかについてここでは触れませんが、近似、プロジェクトが頓挫した事案でベンダの損害賠償責任を認める判決が何件か出ていることには留意が必要です。スルガ銀行・日本IBM事件（注7参照）では、第一審は日本IBMに対し74億円の支払義務を認めています（控訴審では減額されましたが、それでも41億円の支払義務を認めました。この事件は上告不受理により確定しているようです）。

(8)　偽装請負（偽装準委任）の問題

アジャイル開発では、ユーザとベンダが開発チームとして一体となりコミュニケーションをとっていきながら開発を進めることから、ユーザ側の人員であるプロダクトオーナーがベンダの開発メンバーに直接指揮命令をしているとして、実質的な労働者派遣に該当するのではないか（偽装請負または偽装準委任）が問題となり得ます。

これについては、IPAのモデル契約の解説にも少し記載されていますが（注9）、最終的には所管官庁（及び裁判所）が判断する事柄である、として結論は示されていません。ただ、アジャイル開発は、ユーザとベンダが密接なコミュニケーションをとって開発を進めていくものですし、ベンダがユーザに従属しているような関係でもない限り、開発チームのメンバー間での助言、提案、意見交換等は、直接の指揮命令に該当しないと考えてよいかと思います。

(9)　知的財産権の帰属

開発したソフトウェアについての知的財産権の帰属をどうするかは、ウォーターフォール型と同様の検討になると思いますので、ここでは省略します。

４．終わりに

本記事では、ソフトウェア開発委託契約を作成するうえで考慮すべきアジャイル開発の特徴について、ウォーターフォール型との比較という観点から、検討を試みました。アジャイル開発での契約書の作成を検討されている方は、上記のモデル契約やその解説も参考に、そのプロジェクトの実態に沿った契約書を作成されると良いと思います。

最後にその他の参考文献として以下をご紹介します。
・梅本大祐「アジャイル開発の特性と契約のポイント」（ビジネスロージャーナル2013年7月号40頁以下）
・北岡弘章「中小企業における開発契約発注時の留意点」（ビジネスロージャーナル2011年12月号30頁以下）

（注1）一般社団法人電子情報技術産業協会「ソフトウェア開発モデル契約の解説【2020年4月1日施行 改正民法対応版】」（以下「JEITA解説」）でも、要件定義フェーズ、外部設計フェーズ、ソフトウェア開発フェーズ、ソフトウェア運用準備・移行フェーズの4つに分けて、それぞれのフェーズにおいてユーザがベンダに委託する業務について、個別契約書を締結する多段階契約の構造をとっています（9頁）。

（注2）JEITA解説（注1）67頁参照

（注3）JEITA解説（注1）40頁参照

（注4）JEITA解説（注1）5頁参照。JEITAは要件定義を完成させる主体はユーザであり、ベンダが要件定義書を作成・納品することを目的とする取引ではないこと等を理由としていますが、これには異論もあります。

（注5）IPA解説（注1）8頁参照。

（注6）IPAやLIPのモデル契約では、このような名称を用いていますが、必ずしも、そのプロジェクトにおいて、プロダクトオーナー、スクラムマスター、スクラムチームといった名称を用いているとは限りませんし、契約書に実際に使っている名称と異なる名称を記載するのも変ですので、個人的には、「ユーザの開発責任者」（プロダクトオーナー）、「ベンダの開発責任者」（スクラムマスター）、「プロジェクトチーム」（スクラムチーム）といった一般的な名称の方が分かりやすいのでは、と思っています。ただし、本記事では、IPAやLIPのモデル契約の定義にならって「プロダクトオーナー」、「スクラムマスター」、「スクラムチーム」という名称を用いています。

（注7）プロジェクトマネジメント義務の内容について、スルガ銀行・日本IBM事件高裁判決（東京高判平成25年9月26日金融・商事判例1428号16頁）は、「契約文言等から一義的に定まるものではなく、システム開発の遂行過程における状況に応じて変化しつつ定まる」としたうえで、「想定していた開発費用、開発スコープ、開発期間等について相当程度の修正を要すること、更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから、ベンダとしては、そのような局面に応じて、ユーザーのシステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説明義務を負うものというべきである。」と判示しています。

（注8）旭川医大・NTT東日本事件高裁判決（札幌高判平成29年8月31日判例時報2362号24頁）は、仕様凍結合意後もユーザから新たな要件や仕様変更の要望の提出が相次いだためにプロジェクトが頓挫したとして、ユーザの協力義務違反という債務不履行を認め、代金支払義務を認めています。

（注9）独立行政法人情報処理推進機構「アジャイル開発外部委託モデル契約（解説付き）」16頁以下参照。