アジャイル開発版モデル契約のバリエーションに関する議論について
2022 年 3 月 14 日
IPA 社会基盤センター
1. 一部完成保証付契約例と関係者への意見照会(1) 一部完成保証付契約例（骨子）の提示と意見募集の経緯
2021 年 3 月に IPA が公表したアジャイル外部委託開発モデル契約（以下「モデル契約」という。）1は、その契約類型として（履行割合型）準委任契約を採用しており、成果物の完成は保証されていない。これは、開発対象プロダクトの内容を固定せず柔軟に変更することが想定されるアジャイル開発の特徴をふまえたものである。しかし、成果物の完成が保証されないことは、発注側にとってリスクになり得るものであり、何らかの完成保証がないと、予算を確保できず、発注を躊躇せざるを得ないケースも存在する（特に、官公庁による公共調達においては、成果物の完成保証がない場合には調達プロセスにおいて支障が生じることがある。）。
そこで、このようなリスクを軽減してアジャイル開発の導入を一層促進することを目的とし、モデル契約の考えうるバリエーションの一つとして、主として導入初期やユーザ/ベンダ間の信頼関係が十分確立されていない状況等における利用を想定した、実用最小限のプロダクト（MVP: Minimum Viable Product）について完成保証を行う契約の一例（以下「MVP 完成保証付契約例」という。
）を別紙のとおり想定し、主としてモデル契約策定にご協力いただいた関係者（策定のための検討部会及び WG の委員、オブザーバー団体等）に提示して、任意で意見をいただいた。
(2) 意見の概要
いただいた意見を総合すると、まず、成果物の完成が保証されないと予算が確保できず発注が難しいケースが存在するという現状認識については一定の理解が得られた（もっとも、アジャイルの導入を妨げる主たる要因は、成果物の完成保証の不存在ではなく他にあるとの意見もあった。
）。
しかし、完成保証のニーズへの対応として、契約で MVP 完成保証を行うことについては、①成果物の完成保証の考え方は、アジャイルの本質と整合せず、正しいアジャイル開発が行われなくなる、②MVP について費用を固定して完成保証をすることは、ユーザにとってそれほどメリットはない、③そもそも MVP の要件を確定できるならアジャイル開発を選択する必要性がない等、否定的なものがほとんどであった。

1

アジャイル開発版「情報システム・モデル取引・契約書」 https://www.ipa.go.jp/digital/model/agile20200331.html

1また、MVP 完成保証付契約例に対しては、①完成保証対象部分と通常のアジャイル部分で体制や運用を分ける必要が生じうる、②費用が固定される MVP の内容を決める際、ユーザとベンダの間で利害が衝突して交渉に時間を要し、結果的にアジャイル開発の迅速性が失われるおそれがある、③MVP 部分を固定できるような開発案件は限られているため、適用対象が限定されるといった意見があった。
さらに、成果物の完成保証のニーズへの対応としては、①ウォーターフォール開発に用いられる多段階契約や複合契約（要件定義（準委任）＋MVP 部分（請負）＋アジャイル開発部分（準委任））をアレンジしてアジャイル手法を部分的に取り入れるアプローチや、②成果完成型準委任契約を用いる方法、また、③（完成保証ではないものの、ベンダによる適切な業務遂行を担保する方策として）現在のモデル契約のスキームを維持しつつ、ベンダの義務内容を契約別紙に詳細に記述してユーザが善管注意義務違反を追及しやすくしたり、成果報酬を設定してベンダのインセンティブを高めたりする方策が示された。
今回関係者からいただいた意見は、今後、IPA がモデル契約の改訂やバリエーションの追加を検討する際の貴重な資料となるのみならず、アジャイル開発にかかわる事業者が自社の契約を検討する際にも参考になると考えられたため、以下、主な意見の要旨を紹介する。
2. 関係者の意見（要旨）(1) アジャイル開発における一部成果物の完成保証(a) アジャイルの導入を妨げる主たる要因は、成果物の完成保証の不存在ではない：⚫

アジャイルの導入が進まないのは、失敗を許さない企業風土や顧客の品質に対する寛容度の問題、アジャイル開発を進めるための開発体制の未整備（ビジネスサイドと IT部門が協業する体制、IT 部門内の人材不足など）、アジャイル開発が適用できない基幹系レガシーシステムの存在等が主な要因であり、アジャイル開発では成果物の完成が保証されないことが主な要因ではない。
（事業者団体）(b) 成果物の完成保証の考え方は、アジャイルの本質と整合せず、正しいアジャイル開発が行われないおそれがある：⚫

完成保証の考え方は、「アジャイルソフトウェア開発宣言」に記載された精神と相いれない部分があり、アジャイル開発を正しく理解せずに採用するリスクがある。
（事業者団体）⚫

「請負的な成果物の完成保証を求めるユーザには、アジャイルの趣旨を説明して準委任形態でのモデル契約に合わせる説得をする」というのが理想。ただ、現実には請負形式のニーズもあり、現実との折り合いをつけるという意味では MVP 完成保証付契約例にも合理性はある。（委員）2(c) MVP について費用を固定して完成保証をすることは、（特に完成保証がバグ修正を含まない場合）ユーザにとってそれほどメリットはない：⚫

MVP について費用を固定する場合、ベンダ側はバッファやオーバーヘッドなどを加味して、MVP のコストをむしろ高く見積もるおそれがあり、アジャイルの普及にとって逆効果となりうる。また、実務上、ユーザ側は成果物の完成保証の有無にかかわらず予算取りの際に MVP だけでなくそれ以外の機能も含めた全体予算を確保すると思われるため、MVP だけは（いくらかかるかわからないが）作り上げてくれる、という保証があっても、それ以外の部分が想定より減るのであれば発注側にとってそれほどメリットはないように思われる。（委員）⚫

MVP 部分に生じたバグ修正の工数をアジャイル開発で吸収するのであれば、ユーザ側にも、MVP 部分に完成保証があることのメリットがあまり感じられないのではないか。
契約不適合責任と仕事完成義務は表裏一体のものであり、MVP の追完等を求めることができない完成保証にユーザの理解を得られるか疑問が残る。（事業者団体）(d) MVP の要件を確定できるならアジャイル開発を選択する必要性がない：⚫

アジャイル開発は、完成すべきアプリケーション等のプロダクトバックログが不明瞭
でも開発を開始でき、試行錯誤の中で仕様が定まっていくところに特徴がある。MVPの要件が明確に定義できるのであれば、ウォーターフォール開発で MVP 部分を請負契約によって開発することが近道であり、あえてアジャイル開発を選択する意味は少ないのではないか。
（事業者団体）⚫

成果物の完成保証が必要な部分は請負型で契約すべきであり、あえてアジャイル開発とする必要性が見いだせない。
（事業者団体）⚫

MVP についてはアジャイル開発を行う必要性が低く、いったん MVP を開発した上でその機能追加や改善においてアジャイル開発を適用することが適当。
（委員）⚫

サービスやシステムによっては MVP が巨大になるケースもあり、今までのウォーターフォール開発との差異がなくなるケースがあり得る。（事業者団体）(2) MVP 完成保証付契約例を運用する際の問題⚫

開発対象のうち、完成保証部分と通常のアジャイル部分で、指揮命令系統やチーム編成などが異なることになり、全体として体制を作って回していくことや、タスクの優先順位付けが難しくなることが予想される。
（事業者団体）⚫

MVP の範囲を広げたいユーザと、Lean 開発の理念（贅肉をそぎ落としたシンプルな原型を MVP とするもの）に忠実に MVP を限定的にしようとするベンダとの間のせめぎ合いで、MVP の要件定義に時間をかけざるを得なくなり、アジャイル開発の迅速性という利点が失われるのではないか。具体的には、「実用最小限の範囲」での完成保証に3

おけるユーザの期待値とベンダの期待値にギャップが生じ、実務的な部分で折り合いをつけることが困難となる。（事業者団体）⚫

そもそも何をもって実用最小限とするのか、ユーザ・ベンダ間で認識を合致させることも困難ではないか。（事業者団体）⚫

MVP 完成保証付契約例では、MVP 部分については、契約レベルである程度の固定性を持った合意がなされることを前提に、MVP 部分の変更を行う場合には契約の変更協議・合意を要するものとしている。MVP 部分を固定するということ自体がアジャイル開発の本質からは外れていると言わざるを得ないので、MVP 完成保証付契約例を適用できる開発類型はやはりある程度限られているようには思う。（委員）(3) 一部成果物の完成保証のニーズへの対応(a) 請負契約を用いた対応：⚫ 一部ユーザからの成果物の完成保証を求める声に対しては、ウォーターフォール開発に用いられる多段階契約や複合契約（要件定義（準委任）＋MVP 部分（請負）＋アジャイ
ル開発部分（準委任））をアレンジしてアジャイル手法を部分的に採り入れるアプローチが適しているのではないか。
（事業者団体）⚫ 請負契約で MVP の完成保証をする場合、発注者が、事前に複数業者に MVP の仕様を提示し、調達仕様案の妥当性と参考見積りを入手のうえ、MVP 仕様とコストの妥当性を担保することが必要となる。また、その上で、調達仕様書ではあいまいな文言を排除し、MVP の必須機能を明確に記載する必要がある。
（事業者団体）⚫ 何らかの理由により一括請負契約でアジャイル開発を行う場合は、発注者は最低限の必須機能のみを MVP に規定し、それをあらかじめ示した上で調達を行い、受注者は必須機能の範囲にのみ成果物責任を持つことを示すべき。また、必須機能以外の機能により必須機能が影響を受ける場合は、必須機能の範囲と規定されていても、成果物責任の対象範囲からその機能は外れることを明確にする、または契約変更を行う必要があることを明記すべき。（事業者団体）⚫

アジャイル開発は、必ずしも準委任契約で行わなければならないわけではなく、また、公共調達においては、請負以外の契約方式は使いにくいという声もあるため、一部成果物の完成保証がある契約を提言するのであれば、請負契約も選択し得ることを念頭に規律を整理してはどうか。
（官公庁）

⚫

請負契約でアジャイル開発を行う場合は、契約締結時に設定する完成すべき仕事の内容をある程度抽象的に設定しておき、その範囲内で成果物のあり方を自由に変更し、アジャイル開発を進めていく中で徐々に精緻化していく方法が考えられる。
（委員）(b) 準委任契約を用いた対応：⚫ 成果物の完成保証のニーズが、準委任契約ではベンダによる業務遂行が不充分になると4

の懸念によるものであれば、現状のモデル契約のスキームは変えず、契約別紙においてベンダの義務の内容を詳細に記述することで善管注意義務違反を追及しやすくする方策や、成果報酬を設定しベンダにインセンティブを与える方策が考えられる。
（委員）⚫ （是非は別として）もし準委任契約を前提に MVP 完成保証の条項を入れるなら、シンプルに「成果完成型準委任」として、その MVP は完成させないと報酬は出ないが、それ以外の責任は負わないというのがわかりやすいのではないか。
（委員）(4) モデル契約体系に含めた公開⚫

部分的に成果物の完成保証を行う契約モデルを公開することがアジャイル開発の導入を促進することになるかどうか疑問。アジャイル開発を導入しやすくするために完成保証を盛り込むことよりも、アジャイル開発の意義となぜ準委任が適しているのかを広く伝えることに優先的に取り組むべきではないか。（事業者団体）⚫

現行モデル契約では、請負とアジャイル開発の相性の悪さから準委任契約を採用しているにもかかわらず、MVP 完成保証付契約例を公開すると、MVP を定義すればアジャイル型開発でも一括請負型契約を採用できるという認識が広まる可能性が高い。
（事業者団体）⚫

一旦 MVP 完成保証付契約例が公式に公開されれば、たとえ「完成保証がなければそもそも発注自体がままならない限定的な場合を想定したもの」との注意喚起がなされたとしても、本来のアジャイル開発を導入すべき場合にまで、MVP 完成保証付契約例の適用可否の交渉に時間をとられることが危惧される。（事業者団体）
以上5

（別紙）
アジャイル開発における MVP 完成保証付契約例
1. 前提
 契約締結前に、概算見積りが可能な程度に、想定 MVP の概要と規模感が明確であること。
 単一契約の下、同じチームがスクラムによる MVP 開発と継続的な機能追加や改善を実施できること。（MVP 開発を含め、特段の問題が発生しない限り全てスクラムにより実施。）
 保証なしの場合に比べ、プロジェクトマネジメント（特に保証困難となる兆候の監視と対応等のリスク管理）の強化が必要であることが受発注者間で認識されていること。
2. 想定フロー （下図参照）(1) 契約締結段階： (i)想定 MVP の概要、(ii)プロジェクト予算、(iii) MVP の概算見積り金額について受発注者間で合意し、契約書に記載。
(2) 完成保証対象の固定： アジャイル開発プロセスを開始後、MVP に対応するプロダクトバックログが出揃った時点で、受注者がその部分の開発に要する確定見積金額（上限調整あり。
後掲の図*1 参照）及び完成時期を算定し、受発注者間での合意によりそれらを固定。
(3) 完成保証対象の変更： 変更要求時には、変更協議及び変更合意が必要。
(4) 完成確認： MVP 完成時、必要に応じ、発注者による特別な完成確認のプロセスを実施。
(5) 残予算での追加開発・改善： 完成保証対象の検収後、残予算により開発を継続。
3. 契約形態
現行モデル契約（準委任契約）に関連条項を追加し、必要箇所を調整。準委任が前提であるため、請負の契約不適合責任は課さないか、課すとしても（事後の追加開発やリファクタリングにより責任範囲が不明確になることを避けるため）当該契約期間内での変更等による MVP 部分の最初の修正までの期間に限定して設定。

6