092-771-1200

ソフトウェア開発委託契約:瑕疵担保責任

瑕疵担保責任とは?

 なかなか一般生活において「瑕疵担保責任」なんて言葉は使いませんし、なじみのある言葉ではないと思います。
 ただ、法律を勉強したことがある方、仕事上、契約書に関わる方であれば、必ず聞いたことがあるのが「瑕疵担保責任」です。

 この「瑕疵担保責任」の「瑕疵」とは、誤解をおそれずに平たく言えば「目的物を引き渡した際に、本来有すべき性能がないなどの不具合」のことであり、「瑕疵担保責任」とは、瑕疵がある場合の責任ということになります。

 たとえば、中古車を購入したらエンジンが壊れていた場合、中古建物を購入したところ、床下がシロアリだらけだった場合、建物を建設してもらったら欠陥住宅だったという場合に「瑕疵がある」といいます。
 瑕疵担保責任には、売買契約の場合と請負契約の場合で民法の規程が異なるので、区別して考えたほうがいいと思われます。

 先ほどの例ですと、中古車や中古建物の場合は売買ですので、売買契約における瑕疵担保責任の問題となり、建物を建設するという請負契約の場合には、請負契約における瑕疵担保責任の問題となります。
 ソフトウェア開発契約は請負契約に近いので、民法上瑕疵があることを理由に、①修補請求、②損害賠償請求、③解除・代金返還請求を行うことができるとされます。

どのような不具合がソフトウェア契約における瑕疵になるのか

次のうち、どのようなものが瑕疵とされるのでしょうか。

  1. ソフトウェアに簡単に修正できるバグがあった
  2. 特定のソフトと同時に操作することができない不具合が判明した
  3. システムに欠陥があり、セキュリティホールとなりうることが判明した
  4. 発注条件どおりに作成されているが、その発注内容が誤っており不具合が生じた

瑕疵の基準

 私見では、瑕疵に該当するかは、契約で予定された品質・性能を欠くかという点を基準として考えるべきです(これに対し、一般的な水準をもって判断すべきという考え方もあります)。

  1. 「瑕疵」になりえそうです。ただし、バグの程度を考慮しなければならないことは後述します
  2. そもそもの発注内容によるところが大きいです。たとえば、特定のソフトと同時に操作することが前提として考えられているソフトであれば、瑕疵となりえます(動作環境として指摘をしていたかどうか)。一方で、想定をしていないような特殊なソフトとの関係で動作しないのであれば、瑕疵とは評価できないと思われます。動作環境について、どのように定義をしていたのかが重要となりそうです。
  3. 当事者間で合意をした内容に定めがなくとも、やはり、「瑕疵」となる場合があると思われます。もっとも、その「瑕疵」は、1のバグの例と同じく、程度を考慮すべきと考えます。
  4. 注文者の注文通りのシステムを提供している以上、瑕疵とは言えないものと考えます。民法にも、注文者の指図による場合には、瑕疵担保責任を制限する条項があります。ただし、一般的には、システム開発者のほうがシステムに詳しいのですから、トラブル防止の観点から、注文者の指図に問題があるとわかっているような場合には、受注者の責任も生じる可能性があります。

瑕疵とバグ、不具合の程度

 瑕疵があるということであれば以下をなしうることを前回述べました。

  • 修補請求
  • 損害賠償請求
  • 解除・代金返還請求

 また、ソフトウェアにバグがあった場合に瑕疵となりうることを指摘しました。

簡単に修正できるようなバグでも契約解除や損害賠償請求となるのか?

 やはり常識的に考えて、あまりに軽微なバグしか生じていないのに、解除や損害賠償を認めることには違和感があります。
 裁判においても、バグが瑕疵といえるためには、損害賠償請求や解除とすることが相当という程度のバグに限る傾向があるようです。

 ということで、前回の1.ソフトウェアに簡単に修正できるバグがあった、という場合には、瑕疵にならないケースも多いと考えます。一方で、3.システムに欠陥がありセキュリティホールとなりうる、という場合には、重大な問題と言えそうです。1の例よりも瑕疵と評価すべき場合は多いでしょう。

 ただし、欠陥が発覚し即座に対応をした結果、被害が無かったというような場合にまで瑕疵があったといえるかというと、そうはならないと考えます。

瑕疵担保責任に関する損害

 たとえばシステムに不具合がある場合、そのシステムがどうにも使えないという場合には、開発費用は損害となるでしょうし、そのシステムのために導入したコンピュータ等の機材の費用も損害となります。あるいは、そのシステムの不具合のために3日間営業ができなかった場合には、その営業ができなかったことによる損害も請求しうることになります。
 また、セキュリティホールとなりえ、実際にウイルスに感染したとなると、更なる損害が生じる可能性があります。

請求する側の注意点

 システムの不具合が発覚⇒何らの対策もとらずに2日経過⇒その後ベンダーに連絡⇒不具合を解消 と言った場合、3日間の損害が生じたと主張しても、損害はせいぜい1日分に減らされると思います(過失相殺)。

システム開発者側の注意点

 害意はなく作成したソフトについて、どこまでも損害が拡大する可能性があるため、あらかじめ契約上、損害賠償額の上限を定めておくことが考えられます。
 このような合意も、あまりにも非常識な上限額でなければ、有効な規程となります。

契約条項の例

 前項のとおり、システム開発者側にとって瑕疵担保責任は大きなリスクがあります。そこで、その責任を制限する観点から、損害賠償額の上限、請求期間の制限を加えることが考えられます。
 以下、契約条項の例です。

(瑕疵担保責任)
 第○条 要件定義書での決定事項との不一致又は論理的誤り、バグ(以下本条において「瑕疵」という。)が発見された場合、甲は乙に対して当該瑕疵の修正を請求することができ、乙は、当該瑕疵を修正するものとする。但し、乙がかかる修正責任を負うのは、納品後○ヶ月以内に甲から請求がなされた場合に限るものとする。
  2. 第1項の規定は、瑕疵が甲の提供した資料等又は甲の与えた指示によって生じたときは適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。
  3. 甲が乙に対し、瑕疵担保責任により損害賠償を請求する場合には、納品から○か月以内に書面にて請求をすることとし、その損害賠償額の上限を本契約に基づく支払い済みの代金を上限とする。
以上

本コラムはリスク法務実務研究会にて当事務所の弁護士小川剛が担当している内容を、一部改訂して掲載しております。