IT鑑定

 IT鑑定は、システム開発、コンピュータ、インターネット等に関する専門的な知見、あるいは、これらを具体的な事案に適用した場合の評価・判断を、「専門家の鑑定意見」として提供するものです。例えば、次のような場合にご利用頂けます。

・訴訟提起した場合の見込み、あるいは回収可能な損害額を知りたい
・相手方との交渉や社内での意見形成のため、専門的な見解を参考にしたい
・訴訟での重要な争点について、専門家の意見を鑑定証拠として提出したい

 IT分野は、他の専門分野と比べて、標準的な見解が整理されていないうえ、これらが法的フィルターを通った場合にどうなるかは、なおさら不透明です。逆に、ITの世界では誰もが当たり前と考えている常識が、かえって一般の文献・資料に載っておらず、訴訟での立証に苦慮することもあります。IT鑑定では、これらの問題に的確に対応します。

「IT鑑定」概念図

※ 「IT鑑定」では、鑑定としての性質上、鑑定結果についてはご要望にお応えできない場合があります。

相手方との交渉を始める前に、事案の見極めをするために鑑定を行った事例です。

 事案   システムベンダであるA社は、十年来のつき合いのあるB社の新ウェブシステムの構築を5000万円で請け負い、本稼働にこぎ着けました。ところが、本稼働に入ってみると、画面遷移やデータ更新といった基本的なところで次々とバグが見つかり、業務に大きな影響を与えました。原因は、納期に間に合わせるために急遽投入した再委託先の担当者の能力が十分でなく、テストに大きな漏れがあったことで、A社の責任は明らかでした。B社の担当役員は怒り心頭で、A社に1億円の損害賠償を求めてきました。A社は、B社に迷惑をかけたこと、相当の損害を与えたことは事実だとしても、賠償額の1億円はあまりに途方もない金額だったので、何度もA社と話し合いを持ちました。しかし、B社の担当役員は、「倍返しだ」、「これくらい当たり前だ」と言うばかりで解決の糸口すらつかめませんでした。そこで、A社はITSに、賠償すべき損害額として幾らが妥当なのか、鑑定を依頼しました。

 解決  ITSは、簡易鑑定として、要件定義書や障害一覧などの必要資料の提出を求めたうえ、A社の責任者と主担当者へのヒアリングを2回行いました。そして、法的に賠償すべき損害を、データ補正のための外注費と逸失利益の一部を中心とする450万円~600万円と算定しました。A社は、この簡易鑑定を基に、「法的に責任を負うべき損害については、支払う用意がある」として、再度B社と交渉しました。結局、A社は、トラブルに対して正式に謝罪するとともに、損害賠償として500万円を支払うだけで済みました。B社の言い値の20分の1だったわけです。また、ITSの指導の下、品質管理・再委託先管理を中心とした再発防止策を構築したところ、間もなく、その成果を評価したB社との関係も回復し、新たに拠点間販売管理システムを受注する運びとなりました。

 ポイント  ベンダに責任のあるトラブルによってユーザに損害が発生したことが明らかな場合でも、法的に賠償すべき損害が幾らであるかは、実は極めて難しい問題です。交通事故に伴う損害賠償のように、一般的な基準(相場)が形成されている分野と異なり、IT紛争では損害賠償も「カスタムメイド」なのです。トラブル対応に追われた従業員の慰謝料のようなものは入るのか、逸失利益はどこまで含まれるのか、当事者同士での交渉を難しくします。そのような場合に鑑定サービスによって「もし裁判したとすれば、結局幾らになるのか」という落とし所を知っておけば、交渉にもブレがなくなりますし、訴訟など次のステップに進む必要性やタイミングも計りやすくなります。

※ この事例は説明用のもので、実際の事件とは一切関係がありません。

裁判で争点についての証拠とするために鑑定を行った事例です。

 事案   新進のアパレル企業であるA社は、本社システムと接続できる店舗でのリアルタイム商品管理システムの開発をシステムベンダのB社に委託しました。開発では若干の打合せも行われましたが、明確な工程感や確認のないまま進み、実際の画面等が出来上がってくる段階となりました。ところが、A社の担当者がこれを試用してみると、細部以前に必要な機能、あるいは考え方そのものが要求と異なっていることが分かりました。そのため、テストを中止し、B社に要件定義からやり直すよう求めました。しかし、B社はこれに応じず、現実に出来ている画面等の確認を求めるばかりで、議論はすれ違いのままでした。2か月ほどの音信不通の後、B社は「実質的に完成している」として、開発代金4000万円を求めて提訴してきました。訴訟の中で、B社は「プロトタイプが完成し、A社の確認を求めていたのにA社がこれに応じなかった」と主張し、これが争点となりました。A社では、裁判所からの示唆もあり、プロトタイピングについての鑑定をITSに依頼しました。

 解決  開発時にはプロトタイピングのような話はまったく出ていなかったので、それ自体が「主張のための主張」と思われましたが、実際に鑑定作業を進めてみると、その通りでした。そこで、プロトタイピングは本来は上流工程でユーザ要求を把握するものである、これを繰り返して完成に至らせる場合でも、最終化までのロードマップが必要である、開発方法の如何によらずテストはいずれにしても必要である、という基本的な考え方を述べたうえ、本件での具体的事情から、計画的にプロトタイピング手法が用いられたものとは考えられないとの鑑定意見を出しました。訴訟は結局、判決まで行きましたが、きちんとした工程計画のない中で、十分な設計やテストを欠いたシステムが作成されただけということで、完成とは認められず、B社の請求は棄却となりました。

 ポイント  訴訟では、証拠と事実の間を経験則で埋めますが、IT関係の訴訟の場合、その経験則がITの専門性に隠れてしまって、有効な立証がしにくい場合があります。この事案では、「テストやユーザ確認が未了のシステムが一応できている」という同じ状態が、ウォーターフォールでの作業が途中で止まってしまった状態なのか、プロトタイピングでの作業が一段落した状態なのかが争われましたが、「プロトタイピングとはどのようなもので、どのような場面でどのように行われるか」が前提として与えられないと判断がつかないのです。IT関係者であれば、あるレンジでは共通理解に立てそうですが、裁判での厳密な立証となると足りません。このような場合にも、IT鑑定は役立ちます。

※ この事例は説明用のもので、実際の事件とは一切関係がありません。

訴訟と並行して、和解を進めるために鑑定を行った事例です。

 事案   ウェブ系の開発ベンダであるA社とB社は、懸賞ビジネス向けポータルサイト・フレームを共同開発することにしました。それぞれの強みを生かす形で、A社は主にウェブ制御技術を、B社は主にデザイン・コンテンツを持ち寄って開発を進めていましたが、次第に製品コンセプトに関する見解の違いが広がり、それぞれが独自の開発を進める事態となってしまいました。その後、両社はそれぞれの特長を持った独立の製品を完成・販売し、ニッチ市場ながらマーケットを二分するに至りました。しかし、当初の共同開発契約は事実上破棄されており、互いが利用し合っている技術やコンテンツについての(主に著作権の)許諾も消滅した状態です。A社はB社の製品の販売差し止めと損害賠償を求めて提訴、B社もA社に対して同様の反訴を提起しました。訴訟は泥沼化しましたが、判決に至れば本訴・反訴とも認容となって、ビジネスの停止を来すことは目に見えています。そのため、訴内外で和解のための話し合いが進められていましたが、その中で、A社がITSに和解のための鑑定を依頼しました。

 解決  両社の製品は、同一市場ながら基本的なコンセプトが異なっており、それぞれの顧客を獲得していましたから、いまさら共同開発に戻して製品を一本化することはあり得ませんでした。つまり、両製品の将来にわたっての併存を認めたうえで、双方が拠出した技術やコンテンツの価値をライセンス料として評価し、これを授受し合う以外に解決はありません。そこで、ITSでは、問題となっている技術やコンテンツの客観的価値、これが各製品に占める寄与度を算定して、ライセンス料に引き直しました。両社は、この鑑定結果を基に協議を重ね、結果的に、ほぼ同水準のライセンス料を授受することで裁判上の和解に至りました。

 ポイント  和解交渉に鑑定が用いられたわけですが、早期和解に漕ぎ着けてビジネス停止を避けるため、双方がより納得し易い客観性・合理性が特に重視された事例です。鑑定では、単にライセンス料の算定だけでなく、両製品の市場シェアに応じて、当初の共同開発が継続していた場合と比較して利益がどのように変わるかなど、ビジネス的な視点を加えて、両社の理解と納得を得易いものになるよう、工夫がなされました。両社は、同一市場でそれぞれの製品をもって「我が道を往く」競合企業ではあり続けたものの、相手製品の売上によってもライセンス収入が上がるようになったことから、その後一定程度の協力関係は回復したようです。

※ この事例は説明用のもので、実際の事件とは一切関係がありません。