（20160222版）システム開発における瑕疵担保・契約解除・損害賠償 私の日常業務の中では、ＩＴ・情報システム・インターネットに関連する法律問題の比率が非常に多いです。そのためシステム開発での瑕疵担保・契約解除・損害賠償に関する御相談をよくお受けします。 ユーザー側からの御相談も、ベンダー側からの御相談も多いのですが、色々な御相談をお受けしていると、法律家（弁護士・裁判官）の考え方と、開発の現場の方の感覚がかなり違っているなと思われる部分が多いです。そこで、・瑕疵担保の請求をしたい／瑕疵担保の請求をされた・契約解除をしたい／契約解除をされた・損害賠償を請求したい／損害賠償を請求されたという時に、まず調査・検討してもらいたいことをメモしておきます。私に限らず、トラブルが発生して弁護士に相談に行く前には、あらかじめこれらの事項を検討しておくと、相談がスムーズに進み、より有意義なアドバイスを受けやすくなると思います。
仕様
瑕疵担保や損害賠償が問題になるときには、仕様の中身が問題になることが多いです。というのも、ユーザーサイドとしては、自分の要望通りにシステムが動作しないことをシステムの欠陥として扱うことが多く、そうすると仕様にその要望が含まれている事が、瑕疵かどうか、損害賠償の原因となるかどうかが決まるからです。ここでの仕様とは、ユーザーとベンダーがどのようなシステムを作るかを合意した内容です。ただ多くのシステム開発では、仕様が抽象的なことが多く、ユーザー側の要望が、仕様内なのか、仕様外なのかがすぐには判断できないことがあります。ここでベンダー側の論理としては、「仕様に明示的に書かれていないものは無い」ということでユーザーを納得させていることが多いのではないでしょうか。法的に見ても、「ある要望に応じた機能を作ってくれ」というのはユーザーの権利の問題で、権利が存在することの立証は権利を主張する側が行わないといけません。つまりユーザーが仕様の範囲内にあると立証できない限りは、ベンダー側の論理が通ることになります。ただここで気をつけて欲しいのは、紙である仕様書にかかれていない要件でも、要件になり得ることがあり得るということです。たとえば同種のシステムであれば通常持っている機能、例えば住所録システムであいうえお順に並べ替えるといった機能は、仕様に明示されていなくても、要件に含まれているという「解釈」がされる可能性があります。 いわゆる性能的要件についても、明示が無ければパフォーマンスが低くてもよいということではなく、そのシステムを利用するにあたって支障が無い程度の性能が出ている必要があります。もちろんパフォーマンスが低いことを仕様に明示していた場合は別ですが。そして仕様がはっきりしない場合には、仕様書以外の、メール、企画書、見積書、議事録等のすべての資料が、その要望が契約に含まれるかどうかの判断資料となります。そのため関係する可能性があるすべての資料は保管し、弁護士に見せないといけません。 つまりユーザー側からすれば、仕様に無いからといって泣き寝入りをする必要があるわけでは無いけれども、仕様に無い部分の対応責任を求めようとすると、・業界における標準水準を立証しなればいけない・やりとりのすべてを立証しなければいけないという負担を負わないといけないことにあります。 同じ事はベンダー側からすれば、仕様に明記されていなくても、ユーザー側が上記の立証に成功するのであれば、責任を負う可能性があるということです。
検収
ユーザー・ベンダーのよくある誤解として、「検収は終わっているから瑕疵担保の請求はできない」があります。そもそも瑕疵担保という制度は納品が終わってからの仕事の成果に対する責任の問題ですから、検収をしているかどうかと、瑕疵担保責任が無くなるかどうかは関係がありません。法的には商事の売買であれば検収によって責任の程度は大きく変わりますが、瑕疵担保はそうでは無いということです。ただ検収を経た場合、仕様の不確定さの問題については、ベンダー側に有利に働きます。というのも成果としてのシステムの状態を認めたということですので、その内容に納得したという形を残すことになるからです。ユーザーとしてシステムの内容に文句がある状態の場合で、それでも諸般の事情により検収をしないといけない場合には、留保付きの研修であることの明示をしないといけません。そして紛争になった際には、その留保がなされていることの記録が重要になってきます。
解除
契約を遡ってなしにするということを言いたい場合、日本の場合は、「キャンセル」という言葉をつかうことが多いと思います。このキャンセルのことを法的には解除と呼びます。システム開発でも、契約をキャンセルしたいという話しはよく聞きます。ユーザー側からすると、システムの納品が遅いだとか、品質が低いといった理由が多いでしょう。システムの納品が遅い場合は、十分な催告期間（いついつまでに完成させないと解除するとという通知における「いついつ」までの期間）をおいて通知をすれば、解除できるケースが多いでしょう。一方、品質が低いという理由では、解除が認められるとは限りません。というのも法律上、瑕疵を原因とする解除は、「契約の目的を達することができない」という条件があるからです。システムの本来的な動作に関係の無い小さいバグがいくつかあったとしても、それのみを原因として解除する事はできないということです。その上、裁判例上システム開発の解除は要件が加算されています。「バグが発生してもそれがすぐに修補されたのであればそのバグを原因としての解除はできない」という考え方です。情報システムの性質上、どれだけ注意を払っても、一定数のバグは避けられないという現状があります。バグを一切許さないということになると、最初からシステム開発を行ってはいけないことと同じになってしまいます。そこで裁判所はこの現実を見て、ちゃんと修補される場合には、それを原因に契約を解除するまではできないとしました。そうするとユーザー側としてシステム開発契約を解除できるのは、・システムの利用目的が達成できなくなるバグが発生し・ベンダーがそれを修補できない状況が続いている場合となります。ベンダー側からは、ユーザーの要望が余りにもきついので、お金を返すからこの契約から離れたいという相談を受けることがあります。しかしこれは法的には困難で、契約上ユーザーの要望が義務の範囲外である場合には、それをきちんと伝えて要望を断るしかありません。
アジャイル開発
日本の場合、発注側の体質から、本来のアジャイル開発を実施する事は難しいことが多いです。というのも一般企業でも国・地方公共団体でも、システムに対して「いくらで完成するのか」という予算枠を予め設定して、その予算内で開発することが至上命題となっています。そうすると必要な部分から順に完成させる、いつの時点を完成とするかはその時の判断で決めるというアジャイル的なシステム開発とは前提が異なることになってしまいます。しかしシステム開発業界で「アジャイル開発」がバズワードのように扱われ、ユーザー側も、「古い体質が払拭された新しい開発手法」というイメージが先行し、「なんとなくアジャイル」でプロジェクトに着手してしまっているケースが多いように思います。仕様の確定が苦手な日本のユーザー・ベンダーの逃げ・問題先送りの正当化文句として「アジャイル開発」が使われているだけという状態です。こういった「なんちゃってアジャイル」は、ベンダーとユーザーとの関係が良好である限りはよいのですが、ひとたび関係が悪化すると、先の「仕様は何か」問題が発生することになります。この場合は結局、ベンダー、ユーザー両方が仕様の確定のための立証の負担をしなければいけません。そしてその準備にはかなりの時間がかかります。
賠償金額
裁判で損害賠償というと、莫大な賠償金を取れる、取られると誤解されることが多いです。しかし日本の損害賠償制度は、実損を回復させるためだけにしか機能しません。たとえばアメリカであれば懲罰的な賠償として、悪質性の高い加害者に最高で300%の賠償を命じることがあります。しかし日本の損害賠償制度では、実際に発生した損害分だけです。そしてその実損分を「金銭として評価した場合にいくらか」という考え方をしますから、金銭に評価できないような損害、たとえば信用毀損とかは、法的には損害として評価されず、実際には賠償されないことが多いです。ユーザーサイドとしては「もしこのシステムがちゃんと完成していたならこれだけの利益が発生していたはずだ」という、いわゆる逸失利益を請求したいことがあります。
弁護士を活用するために
最近はシステム開発の現場に詳しい弁護士が増えてきていますので、紛争の実体を捉えた紛争処理が行える事が多くなってきていると思います。ただ弁護士は、依頼者から情報に基づいて最大限を尽くして戦うことはできるのですが、依頼者から必要な情報が出てこない限りは、実際の所ほとんど何もできません。どんな情報が必要なのかは遠慮せず弁護士に尋ねればいいと思います。システム開発に詳しい弁護士なら、ポイントを押させて示唆をくれるはずです。あとはそのヒントを元に、勝つための情報を社内で徹底的に探索することです。無いものは無いことは仕方ありませんが、担当者の気合いが満ちていれば、いろいろな情報が出てくることが多いと感じます。