ここから本文です

ユーザーの要件が間違ってるのはベンダーの責任です!――全ベンダー涙目の民法改正案を解説しよう その1

@IT 9/14(水) 11:57配信

●民法がシステム開発の現場に沿って改正

 民法が約120年ぶりに改正されることとなった。IT開発の契約にも大きな影響を与えるこの改正案は、2017年の国会で成立し、2019年ごろ施行となる見込みだ。

【俺たちは、いつまでバグを修正し続ければいいんだ? 永遠にか? 永遠にか!(イメージ画像)】

 この改正がIT開発の現場に与える影響は、主に以下の3点だ。


1. 成果物の「瑕疵(かし)担保責任」という考え方がなくなる
2. 請負契約において、約束した成果物を納めなくても、請負人が支払いを受けられる場合が出てくる
3. 成果物の納品を前提とした準委任契約ができるようになる

 一見、今までの考え方を大きく変えなければならない改正にも見える。しかし、長くIT紛争解決の支援を行い、その和解案や判決を数多く見てきた筆者からすると、今回の改正案の内容には、そう驚くべき点があるようには思えない。

 どの点も今まで裁判所が出してきた判決や開発現場の実態からすると目新しいものではなく、むしろ「現実に法律がようやく追いついた」と見る方が妥当だ。

 そこで、今回から3回に分けて、改正のポイントを実際の判決と見比べて考える。今回は、「1」で挙げた「瑕疵担保責任」についてだ。

●消えた「瑕疵担保責任」

 現行の民法で瑕疵担保責任について端的に記述してあるのは、以下の部分だ。

---
第六百三十五条
仕事の目的物に瑕疵があり、そのために契約をした目的を達することができないときは、注文者は、契約の解除をすることができる。(後略)

第六百三十七条
前三条の規定による瑕疵の修補又は損害賠償の請求及び契約の解除は、仕事の目的物を引き渡した時から一年以内にしなければならない。(後略)
---

 これをシステム開発に当てはめて考えると、「ベンダーが作ったソフトウェア(目的物)に瑕疵(バグなどの不具合)があって、役に立たないものであれば、ユーザーなど注文者は契約を解除できるし、無償の修正作業も請求できる。損害が出れば、その賠償も請求できるが、その解除や損害賠償請求は引き渡しから1年以内でなければならない」ということになる。

 この「1年間の瑕疵担保責任」は、請負契約書などにもよく書かれるので目にしたことがある読者も多いだろう。

※引き渡しから1年とは限らない場合の条文もあるが、ここでは割愛する。

 改正案では、「瑕疵担保責任」という言葉が消えてなくなっている。改正案のこれに対応する部分は、以下の条文だ。

---
(請負人の担保責任の制限)

第六百三十六条

請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき(中略)は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。

(目的物の種類又は品質に関する担保責任の期間の制限)

第六百三十七条(前略)注文者がその(目的物の)不適合を知った時から1年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。
---

 この文を読むと、「ユーザーの提供したモノや情報、ユーザーの指示による不具合であれば、ユーザーは損害賠償も契約解除請求もできない」とある。これを逆に考えると、「そうでない場合には、ユーザーは損害賠償や契約解除請求を引き渡しからの期間に関係なくできる」ということになる。

 詳しく説明していこう。

○ポイント1:修補や損害賠償、契約解除の期限がなくなる

 従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、11年後まで請求可能なのだ。

 もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。

 その意味で今回の改正は、システム開発の「現実」に沿ったものといえる。

○ポイント2:瑕疵という考え方そのものが変わる

 今回の改正で最も気を付けるべきは、「瑕疵」という言葉がなくなり、代りに「契約の内容に適合しない仕事の目的物」という言葉が用いられている点だ。

 ソフトウェアの瑕疵といえば、通常はプログラムのバグなど「明確な不具合」を指すことが多い。例えば、ユーザーが「経費精算業務の効率化」を目的としてベンダーと請負契約を結んだが、出来上がったシステムは、余計な機能が付いただけで、現行業務の効率化に向けた機能や性能はほとんど考慮されていなかった場合、これを瑕疵としてベンダーに責任を問えるのかは議論を呼ぶところだった。バグなどの明らかな不具合がないと、瑕疵担保責任を問うことは難しいという条文だったのだ。

 ところが改正案だと、「経費精算業務の効率化」という契約の「目的」達成を期待できるシステムを作ったかが問題になる。効率化に資することが期待できると「客観的」に思えるものを一定の「品質」を持って納めることが必要なのだ。

 バグや不具合を示す瑕疵の有無は問われない。というよりも、バグであれ要件の取り違えであれ、「効率化」に資すると思われるものを作らなければ「アウト」なのだ。

○ポイント3:ユーザーの要件が間違っているのもベンダーの責任

 これを当然と思う方は、考えてほしい。この条文は仮にベンダーが要件通りにシステムを作っても、そして、そこにバグがなくても、契約の目的とズレたものを作ってしまったら、損害賠償を請求される危険があるということだ。

 「契約の目的」と「要件」そしてプログラムなどの「成果物」が整合していることをベンダーが担保する必要があるといってもよい。ユーザーが契約の目的に対して整合しない要件を提示したとき、あるいは十分な要件を提示しなかったとき、それを指摘しユーザーに要件定義をやり直させるのもベンダーの「責務」ということになる。

 そういう改正なのだ。随分とベンダーに厳しいようにも思えるが、条文はそのように読める。

※ただしベンダーに「結果責任」があるわけではない。つまり、契約の目的に、「経費清算業務の時間を半減させる」とあり、新システムの導入によって、それが叶わなかったとしても、ベンダーはそこまでの責任は負わない。

●ベンダーの責任は以前からあった

 もっとも、「ベンダーは契約の目的に責任を持つべきで、仮にユーザーの示す要件が不足していればそれを補うべき」という考えは、現行の民法下で行われた裁判でも示されている。その意味でこの改正は、法律の方が現状を鑑みて寄ってきたともいえる。

 以下の裁判例を見ていただきたい。

---
●東京地裁 平成16年12月22日判決より抜粋して要約

 あるユーザーがベンダーに販売管理システムの開発を委託したが、開発が遅延し、また成果物にも多くの不具合があるとして本格稼働は見合わされた。ユーザーはシステムには瑕疵があり、契約の目的が達成できないとして、契約を解除し、損害賠償として約4100万円を請求した。
---

 この裁判の争点は多かったが、今回は以下の点を説明する。

---
ユーザーが主張する不具合

 当日入荷の引当処理が、移行データを使用したテストでは4時間を要し、その間は、他端末で受注登録ができない状態となった。テストデータ300件の場合でも44分を要した。
---

 これに対しベンダーは、「在庫引当に時間がかかることは、両者が合意していた」と反論したが、裁判所は以下のように述べて、その主張をしりぞけた。

---
 コンピュータ処理を導入する以上は大幅な時間短縮を期待するのが通常であり、従来の手作業と時間的に変わらないようなシステムをわざわざ数千万円もの多額の費用を投じて開発するとはおよそ考え難い。

(中略)

 本件程度のシステムにおける一括在庫引当処理に要する時間は、せいぜい数分程度が一般的に要求される内容であったということができ、テストデータ300件ですら処理時間に44分も要するようなシステムは、およそ本件契約の内容に適合しないものというほかない。
---

 この判決では不具合を「瑕疵」と述べているが、ここで言っているのは、いわゆるバグではなく、「時間短縮」というユーザーの「目的との不適合」のことだ。

 ベンダーの言い分を信じるならば、両者の間では引当処理の時間について合意があったとのことだが、裁判所は、そうした合意(要件)に対して不具合があったかではなく、ユーザーの目的に資すると期待できるものづくりをしなかったことを問題視している。

 もちろん、裁判所は要件を軽視するものではない。システムは要件を満たす必要があり、要件は契約の目的達成に資すると期待できるものでなければならない。ベンダーは専門家として、これらの間の「整合性」と「追跡可能性」に責任を持たなければならないと、この判決は述べている。

 まさに、今回の改正と意図を同じくするものである。

 システムはユーザーの業務のためにあり、契約の目的に沿ったものでなければならない。本連載で、何度も何度も申し述べてきたことだ。

 しかし、紛争事例の数々を見ていると、ベンダー側が契約書にある目的を枕言葉程度にしか考えず、ユーザーが示したヌケモレや不整合を含む要件を精査もせずにうのみにし、開発してしまった(そして失敗した)例は後を絶たない。

 今回の改正を機に、ベンダーの方は「自分の開発してきたシステムが、契約の目的通りであったか」「今後そうあるためには、要件定義をどのようにすべきなのか」を、ぜひ考えていただきたい。

最終更新:9/14(水) 11:57

@IT

なぜ今? 首相主導の働き方改革