システム開発上のバグ・不具合と請負人の瑕疵担保責任

システム開発契約を巡るトラブルの一つに、検収後に発覚するバグを巡るトラブルがあります。

納品したシステムに発生するバグがあまりに多い、これをベンダーに求めても補修・是正されない、といった場合、訴訟トラブルにまで発展することもあります。

その場合、ベンダー側が往々にして追及されるのは、「請負人」の「瑕疵担保責任」という責任です。

請負人の瑕疵担保責任とシステム開発の法的性質

ベンダーが「請負人」の「瑕疵担保責任」を負うか否かを検討するため、まず「請負人」の「瑕疵担保責任」に関する法律上の規定を確認してみましょう。

請負人の瑕疵担保責任とは

民法６３４条は、請負人の瑕疵担保責任について、次のように定めています。

この規定の１項前段及び２項によれば、請負契約に基づき、「請負人」が仕事を完成させたとしても、その仕事の目的物に欠陥がある場合、受注者は、それを修補したり損害賠償をしたりといった責任を負うことになります。

請負契約の典型例である建物新築工事に引き直して言えば、新築工事を請け負った「請負人」（施工業者）は、完成させた建物に欠陥がある場合、それを修補したり、発注者に生じた損害を賠償をしたりする責任を負う、ということになります。

これが民法が定める「請負人」の「瑕疵担保責任」です。

システム開発の法的性質

では、次に、システム開発契約においてベンダーは「請負人」と扱われるのでしょうか。

そもそもベンダーが「請負人」に該当するか否かの問題ですが、これは、個別の契約毎に考えることになります。

請負人に該当する場合

請負人とは、発注者に対して、仕事の完成を約した者をいいます。

そのため、ユーザー・ベンダー間でシステム開発という「仕事の完成」を目的とする内容の契約が成立し、その実態がある場合には、ベンダーは請負人に該当します。

この場合、当該契約のもと完成された仕事に欠陥があれば、ベンダーは上記「請負人」の「瑕疵担保責任」を負います。

請負人に該当しないケース

ただ、一口にシステム開発契約といっても、その内容は実際には多種多様です。

システム開発契約・システム開発委託契約等の形式をとっていても、当該契約が請負契約と判断されない場合もあります。

たとえば、単なる技術支援が契約内容となっているといったケースです。ベンダー側に求められる業務が、仕事の完成ではなく、技術支援（準委任）にすぎない場合、ベンダー側には請負人の瑕疵担保責任は発生しません。

また、当事者間でシステム開発契約という形式をとっていても、その実態が労働者（プログラマー・エンジニア）の派遣にすぎない、というケースもあり得ます。

システム開発契約の形式をとっていても、これが仕事の完成を目的としたものではなく、単なる労働者派遣に過ぎないと評価される場合には、やはり請負人としての責任は発生しません。

システム開発契約・システム開発委託契約は、請負と評価されるケースが多いのは事実ですが、システム開発契約・システム開発委託契約といった形式をとっていても、一概に請負に該当するとは限りません。

そのため、システム開発契約において、ベンダー側が請負人に該当するか否かは、個別ケースごと（実際にはシステム開発の各過程における場面ごとの検討も必要）に考えることになります。

システム開発におけるバグと瑕疵

ベンダーが請負人に該当するとした場合、仕事の目的物に「瑕疵」があれば、ベンダーは瑕疵担保責任を負います。

では、完成させたシステムに、「バグ」があれば、常にベンダーは瑕疵担保責任を負うのでしょうか。

この点、新規システム開発において、検収時点において、何らの不具合もないものを作り上げるのは非常に困難とされています。

ユーザー側の環境にも左右されるため、本稼働しなければ分からないといったことも考えられます。

そうすると、単にバグがあるだけで瑕疵があるとされれば、およそシステム開発には瑕疵があるということにもなりかねません。

そのため、単にバグがある、というだけでは、通常、「瑕疵」とは判断されません。

この点に関して参考になるのが、東京地方裁判所平成９年２月１８日判決です。少し長くなりますが、引用しておきます。

＜東京地方裁判所平成９年２月１８日判決＞

いわゆるオーダーメイドのコンピューターソフトのプログラムで、本件システムにおいて予定されているような作業を処理するためのものであれば、人手によって創造される演算指示が膨大なものとなり、人の注意力には限界があることから、総ステップ数に対比すると確率的には極めて低い率といえるが、プログラムにバグが生じることは避けられず、その中には、通常の開発態勢におけるチェックでは補修しきれず、検収後システムを本稼働させる中で初めて発現するバグもありうるのである。

多数の顧客が実際に運用することによりテスト済みの既成のソフトウエアを利用し、又はこれを若干手直ししてコンピューターを稼働させる場合には、そのような可能性が極めて低くなるが、顧客としては、そのような既成ソフトのない分野についてコンピューター化による事務の合理化を図る必要がある場合には、構築しようとするシステムの規模及び内容によっては、一定のバグの混入も承知してかからなければならないものといえる。

コンピューターソフトのプログラムには右のとおりバグが存在することがありうるものであるから、コンピューターシステムの構築後検収を終え、本稼働態勢となった後に、プログラムにいわゆるバグがあることが発見された場合においても、プログラム納入者が不具合発生の指摘を受けた後、遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたときは、右バグの存在をもってプログラムの欠陥（瑕疵）と評価することはできないものというべきである。

これに対して、バグといえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、又はその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合には、プログラムに欠陥（瑕疵）があるものといわなければならない。

この判決は、新規システム開発のバグ不可避的な特徴から、単にバグがあると言うだけではベンダーに瑕疵担保責任が課されない旨判断した判決です。

この判決は、瑕疵を肯定しうるケースとして、バグが①システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができない場合と、②その数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合に瑕疵が肯定されるとしています。

その後の裁判例をみると、バグを理由に瑕疵が肯定されるケースは必ずしもこの二つのケースに限られませんが（判例の射程の問題）、単にバグがあるというだけでは瑕疵は肯定されない、という当該判決の趣旨は、その後の裁判例でも共通の考え方になっているように思われます。