アジャイル開発契約は契約不適合責任を負うか？

「ソフトウェア開発における請負契約と準委任契約の違い」で請負契約と準委任契約の選択をわけるのはなにか、ということを書きました。

その中で、「準委任契約は主に善管注意義務を負い、請負契約は完成義務と瑕疵担保責任を負います。」と書きましたが、これはいったい何なのか、ということを書こうと思います。

なお瑕疵担保責任は民法改正で「契約不適合責任」に改められました。

民法の構造

はじめに、民法は以下のような構造になっており、上位の階層の定めは下位の階層すべてに適用されます。

編
└章
　└節
　　└款
　　　└目

請負契約、準委任契約の位置づけは以下のようになっています。

第3編　債権（399条〜724条）
└第2章　契約（521条〜696条）
　└第9節　請負（632条〜642条）
　└第10節　委任（643条〜656条）
※準委任と委任は同じものと捉えてください。

瑕疵担保責任・契約不適合責任とはなにか？

両者はともに「契約の内容に適合しないことに関する責任」であり、同じ意味です。しかし、責任のとりかたが変わっていますので注意が必要です。

改正前は瑕疵担保責任を負う結果、瑕疵があった場合は３つの手段が取れました。
・634条1項による修補請求（直させる）
・634条2項による損害賠償請求（瑕疵によって発生した損害を賠償させる）
・635条による解除（契約をなかったことにする）
これらの手段は「引き渡しから1年間（工作物によってはもっと長い）」行使できました。

改正後は4つに増え、適用条文も、行使できる条件も変わっています（細かくは省略します）。
・562条による修補請求
・563条による減額請求（代金をまけろ）
・415条による損害賠償請求
・541条、542条による解除
最も大きな変更はこれらの手段が「不適合を知った時から1年間（時効で最長10年）」行使できるようになり、起算点が予測できなくなり、かつ責任期間が長くなる可能性が出てきました。

以上から、主に責任を負う期間の有無により、契約不適合責任を負うかどうかは死活問題になる可能性があります。

なお後述のため、瑕疵担保責任、契約不適合責任は
・責任の内容
・責任を負う期間
の区別が非常に重要であることを頭に入れておいていただきたいと思います。

準委任契約でも契約不適合責任を負う？

改正前において、準委任契約では瑕疵担保責任は生じないとされてきました。それは民法の請負契約について定める第9節の中、第634条に「請負人の担保責任」として瑕疵担保責任が定められている一方、準委任契約について定める第10節にはこのような定めがなかったからです。また改正前は売買契約にも瑕疵担保責任についての定め（570条）があり、契約の類型ごとに散在している状態でした。

ところが民法改正で、この634条は削除され、以下のような定めによりお金をもらう契約全般に適用が拡大するように一本化されました。

（買主の追完請求権）
第562条　引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。（以下略）

（買主の代金減額請求権）
第563条　前条第一項本文に規定する場合において、買主が相当の期間を定めて履行の追完の催告をし、その期間内に履行の追完がないときは、買主は、その不適合の程度に応じて代金の減額を請求することができる。
２　（略）

（目的物の種類又は品質に関する担保責任の期間の制限）
第566条　売主が種類又は品質に関して契約の内容に適合しない目的物を買主に引き渡した場合において、買主がその不適合を知った時から一年以内にその旨を売主に通知しないときは、買主は、その不適合を理由として、履行の追完の請求、代金の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、売主が引渡しの時にその不適合を知り、又は重大な過失によって知らなかったときは、この限りでない。

（有償契約への準用）
第559条　この節（555条〜585条）の規定は、売買以外の有償契約について準用する。ただし、その有償契約の性質がこれを許さないときは、この限りでない。

これらの条文がいわゆる契約不適合責任のことを指しています。
※ちなみに562条だけ「数量」も対象になっています。

559条を素直に読むと、企業間の契約で用いられている準委任契約で目的物のやりとりを伴う場合は契約不適合責任を生じそうです。
しかも改正により、成果の発生を伴う準委任契約というものが明文化されています。

（成果等に対する報酬）
第648条の2　委任事務の履行により得られる成果に対して報酬を支払うことを約した場合において、その成果が引渡しを要するときは、報酬は、その成果の引渡しと同時に、支払わなければならない。
２　（略）

請負契約との違いでいうと、成果完成型の準委任契約における成果の概念はあくまでも「報酬」としか紐付いていないので、成果を「完成させる」義務は準委任契約では引き続き負いません。

では契約不適合責任はどうでしょうか？少し考えてみました。

準委任では契約不適合責任はないとする理屈

①これまで準委任では瑕疵担保責任はなかったのだから、この規律を変更する意図はないはずである。
②上記の慣習は559条にある「有償契約の性質がこれを許さないときは、この限りでない。」によって肯定される。
③IPAのアジャイル開発契約モデル解説では準委任契約の帰結として契約不適合責任を否定している（後述）。
④準委任契約の適用場面において契約不適合責任を負うとするのは契約不適合責任の効果とバランスを欠く。

準委任でも契約不適合責任はあるとする理屈

①言葉の違いで言えば契約不適合責任は「目的物」に存在することが要件であり、成果完成型準委任は「成果」という違いはあるが、両者に実質的な違いはない。そもそも成果完成型準委任の規定自体が請負の規律を参考に作られている。
②「ない理由①」は条文の一本化から否定される。
③「ない理由②」は契約不適合責任以外の規律を念頭に置いている。「民法(債権関係)の改正に関する論点の検討(15)」などでも、代金減額請求権や予約などの規律が559条により準用されることが想定として議論されている※。
④プログラム開発において「契約時に」要件が未定のまま開発を委託する場合（特にアジャイル開発において）、契約類型の差異によって成果物に関する責任に違いがでるのは不合理である。

※この検討の過程での準用される規定の範囲については以下のように、現在・未来の想定していないような契約が登場したときのために一般抽象的な規定を残しておく、となったため、解釈の問題になってしまいました。

確かに，民法第５５９条には，ある契約に売買の規定が準用されるか否かや，準用される規定の範囲が必ずしも一義的に明確でないとの問題がある。このような不明確さをできる限り除去する観点から，準用の可否が具体的に問題とされているケースについては，個別的な規定を整備することが必要であると考えられる。しかし，そのような不明確がなお残るとしても，有償の無名契約への対応の必要性等を考えると，現行民法第５５９条のような包括的な準用規定を設けておくことは，必要かつ有益なのではないかと考えられる。そして，準用元として位置付けるのにふさわしい契約類型は，売買契約以外に見出し難いように思われる。

アジャイル開発とは

プログラム開発手法の1つ（というよりは類型）で、アジャイルソフトウェア開発宣言が発祥です。

それまでウォーターフォールといわれていた要件定義→設計→開発→テスト→導入・運用という一連の工程ではなく、期間と要員を先に決め、短いサイクルを回しながら都度都度必要な要件を策定・選択しながら開発を進めていきます。

契約的に重要なのは以下の３つです。
①契約締結時点で完成すべきプログラムの仕様が定められない（機能要件、非機能要件は頻繁に変更される可能性がある）こと。
②要件の取捨選択があるため全ての成果が完成する（全ての機能の実装を完了させる）保証はできないこと。
③期間と要員を先に決める場合は予算（対価）は先に決まり、請負のような実工数と見積工数との差異が発生する確率は相対的に低い。あるいは期間のみ決め、要員や投入工数は要件の選択により変動するならば、柔軟な対価算定・変更方法を定めておく必要がある。

上記のような特徴を持つ一方で、契約期間中に発注者（プロダクトオーナー）と合意された要件・仕様に基づき確実にプログラムは出来上がり、それは検査され、「完成」が認定されれば引き渡されます。

また発注者を含めた要員が入り交じるので偽装請負にあたる状況が発生する危険もあります。

IPAのアジャイル開発契約モデルは準委任契約

IPAがアジャイル開発におけるモデル契約書を公表しています。解説では契約の類型について以下のように述べています。

アジャイル開発の特徴からすれば、あらかじめ内容が特定された成果物を予定したとおりに完成させることに対して対価を払う請負契約よりも、業務を受託したベンダ企業が専門家としての注意義務を果たしながら業務を遂行す
ることそれ自体に対価を支払う準委任契約の方が馴染み易いと考えられる。
（中略）
・本契約を準委任契約とした趣旨
アジャイル開発では開発プロセスの中で、開発する機能の追加・変更や、その優先順位の変更が生じる。そのため、当初は開発予定となっていた機能も、ビジネス環境の変化やユーザ企業内部のニーズの変化などに応じて、プロダクトの内容に責任を持つユーザ企業の判断で開発対象から外す場合もある。また、プロダクト（一部の場合もある）を一旦リリースした後も、利用者からのフィードバックに対応するなどして、さらなる機能追加や改善が行われることもある。このようなアジャイル開発の特徴からすれば、あらかじめ内容が特定された成果物を予定したとおりに完成させることを義務付ける請負契約より、専門家としての注意義務を果たしながら業務を遂行することを義務付ける準委任契約の方が、その性質上、アジャイル開発契約には馴染み易い。
（中略）
アジャイル開発の強みは、その時々にユーザ企業が真に必要としている価値を優先して実現できることにあり、開発する機能のタイムリーな追加・変更ができる点にあるところ、対価を固定した請負契約を締結した場合、ベンダ企業には工数を増やさないよう、追加・変更を抑制するインセンティブが生じうる。そのため、請負契約は両当事者間の利害対立を招くリスクがある。
こうした点を考慮すると、外部委託によりアジャイル開発を行うに当たっては、請負契約ではなく準委任契約を用いるのがより適当と考えられたため、本契約では準委任契約を前提とすることとした。

アジャイル開発モデルは準委任における契約不適合責任を真っ向否定

IPAのアジャイル開発モデルは、契約不適合責任について以下のようにはっきりと準委任契約における契約不適合責任責任を否定しています。

準委任契約であることの帰結として、開発対象プロダクトに不具合があったり、セキュリティ等の非機能要件の不備があったりしたとしても、ユーザ企業はベンダ企業に対して、成果物に関する契約不適合責任を追及することはできない。もっとも、それらの問題がベンダ企業の善管注意義務違反によるものである場合には、ユーザ企業はベンダ企業に対して損害賠償請求をすることができる。アジャイル開発に限らず、システム開発における準委任の場合、ユーザ企業は、ベンダ企業が情報システムやソフトウェアに関する専門家としての知識・技能を有しているからこそ業務を委託するのであり、ベンダ企業が専門家として通常要求される水準を下回る仕事をした場合には、善管注意義務に違反しうることになる。また、ベンダ企業は「委任の本旨」に従って善管注意義務を果たすことが求められているので（民法第 644条）、契約書本体及び別紙で表された委任の内容に反する行為を行った場合も善管注意義務違反となる。

ただし「もっとも」以下も重要です。
あくまでも「民法で定めるデフォルトの契約不適合責任は負わない」といっているにすぎず、開発遂行については「プロとしての水準」が求められ、これを満たせなければ以下の債務不履行責任を取らなければなりません。
・415条による損害賠償請求
・541条、542条による解除（ただし652条、620条により原状回復義務は負わない）
また559条のスコープは不透明ですが、
・562条による修補請求
・563条による減額請求（代金をまけろ）
も法律上準用される可能性はあるし、実務対応としてもアジャイル開発したソフトウェアがイマイチな品質だった場合は「すいませんでした、すぐに直します」「すいませんでした、少し安くします」という対応を取ることも十分が得られます。

「あれ？準委任契約には契約不適合責任がないとしても責任はかわらない！？」

はい、結論、「契約不適合責任」にこだわって、準委任契約書から「契約不適合責任」の条項の削除を勝ち取っても、取らなければならない責任はほとんど変わらないと思われます。違いは「目的物を完成させる義務があるか」「責任をどの期間負わなければならないか」となります。

完成責任に関して言えば、ソフトウェア開発における「完成」とは「当初予定していた最後の工程まで終えること」と裁判上判断（改正前民法下での東京地判平14・4・22、東京高判平26・1・15ほか）されています。（そしてこの最後の工程が終了したことの確認として「ユーザー企業による検収」がされているかが重要視されています。東京地判平25・9・30、東京高判平27・6・11）
これも、仮にアジャイル開発だとすると、スプリントと呼ばれる期間を消化するという意味では工程は終えますし、各スプリント内での開発も都度合意された要件を満たすプログラムのテスト・検収という行為が実質的にあるので、「完成」と評価できそうな時点はありそうです。

結局のところ、
・「契約締結時点」で『完成』工程がはっきりしない
・「契約締結時点」で『不適合』の基準となる仕様がはっきりしない
から準委任契約が適切、と言っているにすぎません。

なお担保期間は、準委任契約書から「契約不適合責任」の条項を削除したために、「引渡しから1年」と民法の修正ができず、むしろ不利になる可能性もあります。（もっとも慣習からいって合理的な意思解釈から難しいと判断されそうですが）

ソフトウェア開発における瑕疵とは「バグ」ではない

準委任契約では契約不適合責任を負わないとしても、「契約不適合責任責任は負わない＝バグが生じても修正する義務を負わない」ではありません。

そもそも請負においても、引渡し後に発見されても、指摘後遅滞なく（本稼働まで）修正できるか代替措置が取れるバグは瑕疵ではないと裁判上判断（改正前民法下での東京地判平9・2・18）されています。
いわゆる
ユーザー「これはバグだ！」
ベンダー「バグではないです！仕様です！」
じゃないですが、すぐ修正できる「思ってた動きとの不一致」は法律上は瑕疵・不適合ではないということです。

ソフトウェア開発における瑕疵とは「軽微とはいえない支障を生じさせるうえ、遅滞なく修補できないもの」「その数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合」のことをいうと上記の裁判は述べています。

考えてみれば、もし法律上の瑕疵だと認定されれば、ベンダーは無過失で責任を負い、契約の解除までされ、お金は一銭も払われないばかりか、原状回復義務まで負うのでオンプレミスシステムの場合はすでに構築したサーバーからの撤去まで発生してしまいます。よほどのバグでないかぎり認められないと判断したのも、ある意味納得がいきます。

アジャイル開発においては、都度発注者と「完成すべきものの姿」のイメージが共有されるので、このイメージとのギャップ（仕様の未達やバグ）があれば、それは契約不適合責任というのではなく、善管注意義務違反として咎められるに過ぎず、結局は修正対応、バグフィックスをしなければならないという結論は変わらないといえます。

契約の類型にこだわるよりも、契約の中身を議論しよう

前回記事とあわせてソフトウェア開発における請負・準委任の違いを書いてきました。

そして結論的に、私見を述べると、「請負」や「準委任」と契約書に題することや、「この契約は準委任契約だから契約不適合責任は負いません！」とこだわるのはあまり意味がないと思っています。

おもいっきりちゃぶ台返し
　　　　　　　　∧∧　　　　　　　
　　　　 　　ヽ(･ω･)/　 　ｽﾞｺｰ　　
　　　　 　＼(.＼ ノ
　　　　､ﾊ,,､　￣

なぜかというと、前回も書きましたが契約の中身は自由なんです。

ではなぜ世の中の人は請負か準委任かに揉めるかというと、どちらかの契約類型であると割り切ったほうが権利義務の中身の把握がラクだから、そしてその権利義務の中身が現場の実態と折り合わないからです。

契約類型は選択により条項セットを適用する（プログラムにおけるライブラリのインポートのように）と捉えることができます。
python的に書くとこんな感じ。

from 民法 import 請負

print(請負.責任)

＞完成責任、契約不適合責任

しかし、フルスクラッチでプログラムを書いてもいいように、契約書も法律が定める方式にとらわれずに作っても構いません。

そして何より大事なのは「何が大事で、何を目指しているのか、何に責任を持ち、何は二の次にしてよいか」です。

ユーザーはソフトウェアの開発を委託するとき、「こんなことが実現できるソフトウェアがほしい」「もしバグやほしい機能が実装されていなかったら直してもらおう」としか思っていません。
これを、法的に、裁判所で争おうとすると、契約不適合責任とか善管注意義務違反とかで翻訳されますが、求められることは何も変わりません。

契約はトラブルが起こったときの解決策を示すものですが、現場で合意したことがあとから言った言わないの水掛け論になったり、解釈で揉めたり、トラブル寸前になったときの解決方法を、契約書（提案書、見積書、仕様書などの関連文書も含め）で残しておき、その内容が開発現場で共有され、トラブルを回避するためのツールとして使ってほしいと思います。