②裁判資料としての鑑定

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

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

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

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

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