ＩＴコンサルタント出身の弁護士がＩＴ紛争を予防・解決します
ＩＴ鑑定は、ＩＴ法、システム開発、コンピュータ、インターネット等に関する専門的な知見、あるいは、これらを具体的な事案に適用した場合の評価・判断を、「専門家の鑑定意見」として提供するものです。例えば、次のような場合にご利用頂けます。
ＩＴ分野は、他の専門分野と比べて、標準的な見解が整理されていないうえ、それらが法的フィルターを通った場合にどのようになるのかは、なおさら不透明です。逆に、ＩＴの世界では誰もが当たり前と考えている常識が、かえって一般の文献・資料に載っておらず、訴訟での立証に苦慮することもあります。ＩＴ鑑定では、こうした問題に的確に対応します。
システム障害についての交渉を始める前に、事案の見極めをするために鑑定を行った事例です。
事案 システムベンダであるＡ社は、十年来のつき合いのあるＢ社の新ウェブシステムの構築を５０００万円で請け負い、本稼働にこぎ着けました。ところが、本稼働に入ってみると、画面遷移やデータ更新といった基本的なところで次々とバグによる障害が発生し、業務に大きな影響を与えました。原因は、納期に間に合わせるために急遽投入した再委託先の担当者の能力が十分でなく、テストに大きな漏れがあったことで、Ａ社の責任は明らかでした。Ｂ社の担当役員は怒り心頭で、Ａ社に１億円の損害賠償を求めてきました。Ａ社は、Ｂ社に迷惑をかけたこと、相当の損害を与えたことは事実だとしても、賠償額の１億円はあまりに途方もない金額だったので、何度もＡ社と話し合いを持ちました。しかし、Ｂ社の担当役員は、「倍返しだ」、「これくらい当たり前だ」と言うばかりで解決の糸口すらつかめませんでした。そこで、Ａ社はＩＴＳに、賠償すべき損害額として幾らが妥当なのか、鑑定を依頼しました。
解決 ＩＴＳは、簡易鑑定として、要件定義書や障害一覧などの必要資料の提出を求めたうえ、Ａ社の責任者と主担当者へのヒアリングを２回行いました。そして、法的に賠償すべき損害を、データ補正のための外注費と直接的な売上キャンセルによる逸失利益を中心とする４５０万円～６００万円と算定しました。Ａ社は、この簡易鑑定を基に、「法的に責任を負うべき損害については、支払う用意がある」として、再度Ｂ社と交渉しました。結局、Ａ社は、トラブルに対して正式に謝罪するとともに、損害賠償として５００万円を支払うだけで済みました。Ｂ社の言い値の２０分の１だったわけです。また、ＩＴＳの指導の下、品質管理・再委託先管理を中心とした再発防止策を構築したところ、間もなく、その成果を評価したＢ社との関係も回復し、新たに拠点間販売管理システムを受注する運びとなりました。
ポイント ベンダに責任のあるトラブルによってユーザに損害が発生したことが明らかな場合でも、法的に賠償すべき損害が幾らであるかは、実は極めて難しい問題です。交通事故に伴う損害賠償のように、一般的な基準（相場）が形成されている分野と異なり、ＩＴ紛争では損害賠償も「カスタムメイド」なのです。トラブル対応に追われた従業員の慰謝料のようなものは入るのか、逸失利益はどこまで含まれるのか、当事者同士での交渉を難しくします。また、訴訟となった場合に、賠償の対象となる損害を立証することは、思いのほか困難であることも考慮に入れておかなければなりません。そのような場合に鑑定サービスによって「もし裁判したとすれば、結局幾らになるのか」という落とし所を知っておけば、交渉にもブレがなくなりますし、訴訟など次のステップに進む必要性やタイミングも計りやすくなります。
裁判で主張された「プロトタイピング」の争点についての証拠とするために、ＩＴ鑑定を行った事例です。
事案 新進のアパレル企業であるＡ社は、本社システムと接続できる店舗でのリアルタイム商品管理システムの開発をシステムベンダのＢ社に委託しました。開発では若干の打合せも行われましたが、明確な工程感や確認のないまま進み、実際の画面等が出来上がってくる段階となりました。ところが、Ａ社の担当者がこれを試用してみると、細部以前に必要な機能、あるいは考え方そのものが要求と異なっていることが分かりました。そのため、テストを中止し、Ｂ社に要件定義からやり直すよう求めました。しかし、Ｂ社はこれに応じず、現実に出来ている画面等の確認を求めるばかりで、議論はすれ違いのままでした。２か月ほどの音信不通の後、Ｂ社は「実質的に完成している」として、開発代金４０００万円を求めて提訴してきました。訴訟の中で、Ｂ社は「プロトタイプが完成し、Ａ社の確認を求めていたのにＡ社がこれに応じなかった」と主張し、これが争点となりました。Ａ社では、裁判所からの示唆もあり、プロトタイピングについての鑑定をＩＴＳに依頼しました。
解決 開発時にはプロトタイピングのような話はまったく出ていなかったので、それ自体が「主張のための主張」と思われましたが、実際に鑑定作業を進めてみると、その通りでした。そこで、プロトタイピングは本来は上流工程でユーザ要求を把握するものである、これを繰り返して完成に至らせる場合でも、最終化までのロードマップが必要である、開発方法の如何によらずテストはいずれにしても必要である、という基本的な考え方を述べたうえ、本件での具体的事情から、計画的にプロトタイピング手法が用いられたものとは考えられないとの鑑定意見を出しました。訴訟は結局、判決まで行きましたが、きちんとした工程計画のない中で、十分な設計やテストを欠いたシステムが作成されただけということで、完成とは認められず、Ｂ社の請求は棄却となりました。判決理由がかなりはっきりしたものであったこともあり、Ｂ社が控訴してくることもありませんでした。
ポイント 訴訟では、証拠と事実の間を経験則で埋めますが、ＩＴ関係の訴訟の場合、その経験則がＩＴの専門性に隠れてしまって、有効な立証がしにくい場合があります。この事案では、「テストやユーザ確認が未了のシステムが一応できている」という同じ状態が、ウォーターフォールでの作業が途中で止まってしまった状態なのか、プロトタイピングでの作業が一段落した状態なのかが争われたわけですが、「プロトタイピングとはどのようなもので、どのような場面でどのように行われるか」が前提として与えられないと判断がつかないのです。ＩＴ関係者であれば、あるレンジでは共通理解に立てそうですが、実務でも極端な考え方（の持ち主）がないわけではありません。ましてや、裁判での厳密な立証となると、理解の溝を埋める客観的なものが必要になってきます。このような場合にも、ＩＴ鑑定は役立ちます。
共同開発に関する訴訟と並行して、和解を進めるためにＩＴ鑑定を行った事例です。
事案 ウェブ系の開発ベンダであるＡ社とＢ社は、懸賞ビジネス向けポータルサイト・フレームを共同開発することにしました。それぞれの強みを生かす形で、Ａ社は主にウェブ制御技術を、Ｂ社は主にデザイン・コンテンツを持ち寄って開発を進めていましたが、次第に製品コンセプトに関する見解の違いが広がり、それぞれが独自の開発を進める事態となってしまいました。その後、両社はそれぞれの特長を持った独立の製品を完成・販売し、ニッチ市場ながらマーケットを二分するに至りました。しかし、当初の共同開発契約は事実上破棄されており、互いが利用し合っている技術やコンテンツについての（主に著作権の）許諾も消滅した状態です。Ａ社はＢ社の製品の販売差し止めと損害賠償を求めて提訴、Ｂ社もＡ社に対して同様の反訴を提起しました。訴訟は泥沼化しましたが、判決に至れば本訴・反訴とも認容となって、ビジネスの停止を来すことは目に見えています。そのため、訴訟の内外で和解のための話し合いが進められていましたが、その中で、Ａ社がＩＴＳに和解のための鑑定を依頼しました。
解決 両社の製品は、同一市場ながら基本的なコンセプトが異なっており、それぞれの顧客を獲得していた状況であったため、いまさら共同開発に戻して製品を一本化する選択肢はありませんでした。つまり、両製品の将来にわたっての併存を認めたうえで、双方が拠出した技術やコンテンツの価値をライセンス料として評価し、これを授受し合う以外に解決はありません。そこで、ＩＴＳでは、問題となっている技術やコンテンツの客観的価値、これが各製品に占める寄与度を算定して、売上規模に応じたライセンス料に引き直しました。同時にＢ社側でも、同様の鑑定意見を出してきましたが、差異は調整できないほど大きいものではありませんでした。両社は、これらの鑑定意見を基に協議を重ね、結果的に、Ａ社側の鑑定意見に近い水準のライセンス料を授受することで裁判上の和解に至りました。
ポイント 和解交渉に鑑定が用いられたわけですが、早期和解に漕ぎ着けてビジネス停止を避けるため、双方がより納得し易い客観性・合理性が特に重視された事例です。鑑定では、単なるライセンス料の算定だけでなく、ビジネス的な視点を加えて、両社の理解と納得を得易いものになるよう、工夫がなされました。例えば、両製品の市場シェアに応じて、当初の共同開発が継続していたと仮定した場合と比較して利益がどのように変わるか、といった試算もなされました。両製品とも市場でそれなりに成功しており、「プラスのパイ」が目の前に見えていたことも、和解協議においては幸いしました。両社は、同一市場でそれぞれの製品をもって「我が道を往く」競合企業ではあり続けたものの、相手製品の売上によってもライセンス収入が上がるようになったことから、その後一定程度の協力関係を回復したようです。