システム開発における瑕疵担保責任
IT・情報セキュリティ
当社は、営業システムの刷新をすることを決めて、ベンダーとの間で、新システムを開発する請負契約を締結しました。納期にベンダーからシステムの納入を受けて、新システムを稼働させたのですが、バグが多数残っており、処理速度も遅いなどの不具合があることが判明しました。当社は、ベンダーに対して、どのような請求をすることができるのでしょうか。
仕事の完成後に判明した不具合は、瑕疵担保の問題として処理され、当該不具合が瑕疵であると評価できる場合には、ユーザーは、①瑕疵修補請求、②損害賠償請求、③契約解除（契約の目的を達成することができない場合）の方法をとることができます。
バグについては、ベンダーが遅滞なく補修を終え、またはユーザーと協議のうえで相当と認められる代替措置を講じたときは、そのようなバグは瑕疵ではないと評価されることになります。
また、処理速度等の非機能要件については、通常有すべき品質・性能を満たしているかという基準が用いられるため、当該システムの導入目的や当該機能を使用する業務の内容などを勘案して、当該不具合が瑕疵であるといえるかが判断されることになります。
解説
瑕疵担保責任とは
請負契約では、請負人が仕事を完成させたあとは、請負人は債務不履行責任を負わないとされており、仕事の目的物に瑕疵がある場合には、瑕疵担保責任の問題として処理されることになります。設例のケースでは、新システムが稼働しており、請負人の仕事は完成していると考えられるので、請負人に対して瑕疵担保責任を追及することができるかが問題となります。
参照：「システム開発における仕事の完成の判断基準」
瑕疵担保責任に基づき、ユーザー（注文者）が行使することができる権利には以下の3つがあります。
- 瑕疵修補請求権
- 損害賠償請求権
- 契約の解除権
ただし、①の瑕疵修補請求については、瑕疵が重要でなく、その修補に過分の費用を要するときは請求することができないとされています。
また、③の契約の解除が認められるためには、当該瑕疵のために契約をした目的を達することができないことが必要とされています。
さらに、瑕疵担保責任の権利行使期間は、民法の規定では仕事の目的物（システム）の引渡時から1年とされています。
＊契約解除の要件は、平成29年の民法改正により変更され、平成32年4月1日の施行後は、通常の債務不履行と同様の要件を満たせば解除ができることになります。また、権利行使期間についても、契約不適合（瑕疵から名称が変更）を知ったときから1年以内と変更されます。
システム開発における瑕疵
バグと瑕疵
一般的に、瑕疵とは、契約で予定されていた品質や性能を欠くこととされています。システムにバグ（プログラムの誤り）があった場合には、まさに瑕疵の典型例として、ただちにベンダーの瑕疵担保責任が認められるように思えます。
しかし、情報システムというものは極めて複雑なものであり、いかにテストを行ったとしても、バグを完全に防ぐことは不可能です。このような情報システムの特徴から、バグが発見された後に、ベンダーが遅滞なく補修を終え、またはユーザーと協議のうえ相当と認める代替措置を講じたときは、バグの存在をもってプログラムの欠陥（瑕疵）と評価することはできないと考えられています。この点について東京地裁平成9年2月18日判決・判タ964号172頁は、以下のように述べています。
- いわゆるオーダーメイドのコンピューターソフトのプログラムで、本件システムにおいて予定されているような作業を処理するためのものであれば、人手によって創造される演算指示が膨大なものとなり、人の注意力には限界があることから、総ステップ数に対比すると確率的には極めて低い率といえるが、プログラムにバグが生じることは避けられず、その中には、通常の開発態勢におけるチェックでは補修しきれず、検収後システムを本稼働させる中で初めて発現するバグもありうるのである。多数の顧客が実際に運用することによりテスト済みの既成のソフトウエアを利用し、又はこれを若干手直ししてコンピューターを稼働させる場合には、そのような可能性が極めて低くなるが、顧客としては、そのような既成ソフトのない分野についてコンピューター化による事務の合理化を図る必要がある場合には、構築しようとするシステムの規模及び内容によっては、一定のバグの混入も承知してかからなければならないものといえる。
- コンピューターソフトのプログラムには右のとおりバグが存在することがありうるものであるから、コンピューターシステムの構築後検収を終え、本稼働態勢となった後に、プログラムにいわゆるバグがあることが発見された場合においても、プログラム納入者が不具合発生の指摘を受けた後、遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたときは、右バグの存在をもってプログラムの欠陥（瑕疵）と評価することはできないものというべきである。これに対して、バグといえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、又はその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合には、プログラムに欠陥（瑕疵）があるものといわなければならない。
したがって、納入されたシステムにバグがあった場合には、まず、ベンダーに対して、当該バグを通知し、修補を求める必要があります。バグが多数であるまたは修補が困難であるなどの理由で、修補に時間を要する場合には、ベンダーのユーザーに対する瑕疵担保責任が認められることになります。
性能・セキュリティ等の非機能要件について
（1）非機能要件とは
システムが備えるべき要件のうち、ユーザーがシステムによって実現したいことを機能要件といいます。たとえば、「商品Aを購入した顧客の情報を検索する」などが機能要件に当たります。
一方、設問で問題となっている処理速度のような機能要件以外の要件を非機能要件といいます。独立行政法人情報処理推進機構（IPA）では、非機能要件を、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分類しています（参考：独立行政法人情報処理推進機構（IPA）「非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開」）。
（2）非機能要件に関する瑕疵の判断方法
非機能要件についても、契約で予定されていた品質や性能を欠いていれば、瑕疵担保責任が認められます。
当該システムが備えるべき品質・性能がどのようなものかは、主観的・客観的な事情を総合的に勘案して判断されることになります。
たとえば、その日の取引のデータを夜間のうちに処理し、翌日に別の処理に利用できるようにすることが予定されていた場合、夜間のデータ処理に24時間以上かかってしまい、翌朝に前日データが利用できないというのでは、「契約で予定されていた品質や性能を欠く」ことになります。このように、当該システムの導入目的や当該機能を使用する業務の内容などを勘案して、瑕疵であるといえるかが判断されることになります。
もっとも、何か障害が起きたときに、個別の機能について備えるべき品質・性能を評価するというのは適切とはいえません。この処理は何秒以内に完了させる、このバッチ処理は何時間以内に完了させるというように、可能な限り当事者間の間で、定量的な合意をしておけば、不要なトラブルを防止することができます。
もちろん、あらゆる機能や処理について、非機能要件を明確化するのは、労力や時間を考えると難しいと思われますが、業務に影響の大きい機能や問題が発生すると致命的な問題となりかねないセキュリティなどの重要なポイントについては、できる限りの明確化を図るべきといえます。
まとめ
バグについては一定程度の許容をしているという点が、システム開発契約における瑕疵担保責任の特殊な点といえます。また、非機能要件については、可能な限り、契約段階で明確化をすることが、トラブル防止のための対策となります。
- 参考文献
- 裁判例から考えるシステム開発紛争の法律実務
- 著者：難波修一、中谷浩一、松尾剛行、尾城亮輔
- 定価：本体4,600円＋税
- 出版社：商事法務
- 発売年月：2017年2月
無料会員にご登録いただくことで、続きをお読みいただけます。
90秒で登録完了
尾城法律事務所