福岡市中央区赤坂2丁目の近江法律事務所。1972年設立。企業法務はお任せ下さい。

ソフトウェアの「瑕疵」とは

ソフトウェア開発契約の多くは請負契約型であると言われています。開発過程が終了し、ソフトウェアがいちおう完成したにもかかわらず、納品されたソフトウェアに不具合があるという場合、請負契約上の瑕疵担保責任の有無が問題となります。もし、ソフトウェアの不具合が「瑕疵」だと評価されれば、ベンダーは、過失がなくても、ユーザーに対して瑕疵担保責任を負うことになります。

ソフトウェアの不具合が「瑕疵」なのかどうかは、契約で予定されていた品質・性能を欠くかどうかを基準に判断することになります。つまり、約束した仕様・性能に仕上がっていない場合に「瑕疵」と評価されることになります。

約束された仕様・性能がどんなものかは、要件定義書や基本設計書などによって確認することが通常です。基本設計書などが改訂されて、複数存在することもあり、そのような場合はどれが最終版かを特定する必要が出てきます。仕様変更があった場合には、打合せ議事録やメールで確認をします。

もっとも、基本設計書等に示された仕様・性能と現状が厳密には一致していなくても、不一致の程度が軽微で、重要な部分ではなく、ユーザーの業務に支障がない場合には、ユーザーの合理的意思に反しないものとして、瑕疵ではないと判断されることもあり得ます。

また、ソフトウェア開発では初期段階で軽微なバグが発生するのは技術的に不可避であるとも言われており、実務的には、納品後もベンダーがバグ対応をしたり、不具合の手直しをしたりすることが一般です。ユーザーからのバグ発生の指摘を受けた後、ベンダーが遅滞なく補修を終え、あるいは代替措置を講じたような場合はソフトウェアの瑕疵にあたらず、それでもバグが残存し、システムの稼働に支障が生じるような場合に瑕疵に当たるとした裁判例があります。

さらに言えば、エラーが、ユーザー側のハードウェアの問題や操作ミスによる場合、初期設定時の基本データの不整合によるものである場合などは、ソフトウェアの瑕疵ということにはなりません。

ユーザーは何を請求できるか

ソフトウェアに瑕疵があった場合にユーザーがベンダーに対して何をいつまで請求できるかについては、予めソフトウェア開発契約で定めていることがあり、そのような場合は契約条項に従うことになります。ソフトウェアの不具合問題が生じたら、まずはソフトウェア開発契約書の契約条項をよく確認しましょう。特に契約で定めていない場合は、通常、次のように考えられます。

瑕疵修補請求

ソフトウェアに瑕疵がある場合、例外的な場合（瑕疵が重要でなく修補に過分の費用を要する場合）を除いて、ユーザーはベンダーに対して瑕疵の修補を請求することができます。

契約解除と代金返還請求

瑕疵が重大で、ソフトウェア開発契約を締結した目的を達成することが出来ない場合には、ユーザーは、瑕疵を理由にソフトウェア開発契約を解除することができます。この場合、ユーザーはベンダーに対して支払済みの代金の返還を求めることができます。

裁判例では、在庫照会の検索処理に30分以上の時間を必要としたために、ユーザーが別途手書きの在庫台帳の作成を余儀なくされたという事案や、一括在庫引当処理に何時間もかかってしまい、しかもその処理中は他の商品マスターを利用する処理が一切できなくなってしまうという事案で解除が認められています。

損害賠償請求

また、バグやシステムエラーによって、業務に支障が出た場合、それが瑕疵に該当すれば、損害賠償の問題となります。

瑕疵を原因として損害が発生したとしても、瑕疵がなければ発生しなかった損害のすべてについてベンダーが賠償するのではなく、相当な範囲に限られます。例えば、修補までの間ソフトウェアが使用できず、その間に得られたはずの利益が得られなかったことによる損害（逸失利益）や、瑕疵の調査費用などは相当な範囲の損害に含まれるものと思われます。

瑕疵担保期間に注意

瑕疵担保責任に基づく修補請求、損害賠償請求、契約解除は、ソフトウェアの引渡しを受けてから1年以内にしなければならないので、注意してください。瑕疵担保期間経過後にバグやシステムエラーが発生した場合は、ベンダーの債務不履行責任を検討することになります。

ユーザーからの情報提供の重要性

ユーザーは、IT関係の専門知識に乏しいことが一般ですが、自らの業務については、当然ながら専門知識を持っています。他方、ベンダーは、ITの専門家ですが、ユーザーの業務に詳しいわけではありません。業界特有の慣行やノウハウ、法的規制など、ユーザーにとっては当たり前の業務内容や前提条件が、ベンダーにちゃんと理解されているとは限らないのです。

納品されたプログラムを使い始めてから、「こんなはずじゃなかった」とならないためには、開発の最初の段階で、双方が十分にコミュニケーションをとり、ユーザーからも積極的に情報提供し、要望をきちんと要件定義や基本設計書に反映してもらうことが重要です。書面化しておくことによって、後日発見されたエラーやバグが、瑕疵にあたるかどうかの判断もしやすくなります。

実際、ユーザーの専門分野の領域に属する事項でユーザーしか知り得ないものについては、ユーザー側に積極的な情報提供が求められるとした上、その伝達がないことを理由に瑕疵を否定した裁判例もありますので注意が必要です。

ソフトウェアは目に見えず、手に取って確認することもできません。だからこそ、よいソフトウェア、よいシステムを開発するには、ユーザーとベンダー双方が協力し合い、イメージをしっかり共有化して、プロジェクトを進めることが不可欠でしょう。