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