アイロベックスメールマガジン　携帯版

もし、あなたがITシステムで訴訟を起こされたら裁判に勝つ自信がありますか？

「きちんと仕事をしていれば訴訟にまでなるはずがない」「だからIT訴訟に関して興味がない」
なるほど、おっしゃる通りかもしれません。

ただ、あなたが経営者であったり、部門長のような立場ならば、今回の情報をスルーするのは大変なリスクではないでしょうか。

最近の景況感やご時世では、訴訟の数は確実に増えています。

いくら「格好悪いから裁判をしたくない」といっても、相手が訴訟を起こしたら受けて立たなければいけません。

たとえ、どんなに自分は正しいと思っていてもです。

なぜなら、起こされた訴訟に対して何もしなければ「100% 裁判に負ける」からです。

知っておくべきことを知らないといざというときに大変なことになります。

そこで、今回のシリーズはとても過激なテーマですが、「都合の悪いことは考えたくない」という気持ちを抑えて、ITシステム訴訟について考えます。

とは言っても、私は法律について「素人」です。

弁護士が後ろについているわけでも、監修しているわけでもありません。

このテーマをお読みになる上では、その点をご留意願います。

まず、ITシステムで訴訟に発展する内容として考えられるものは、

　1）システム要件を満たさなかったから契約を解除したい。ユーザーがお金を支払う気が無い。

　2）追加要件でオーバーした費用を払わない。追加要件なのか、元々の仕様なのか、バグなのかが問題となる。

　3）システム障害で生じた被害額を保障してほしい。

　4）著作権など知的財産権を侵害している。自社（ユーザー）に著作権が所属していると考えるシステムをベンダが他社に収めた。

ざっと書き出すとこのような内容が挙げられますが、まだまだありそうです・・・。

しかし、いずれの項目についても、基本的には「契約書」がとても重要です。

契約書に、その事項についてどう書かれているかが問題になったときの1つの指針になります。

例えば、3)のシステム障害、セキュリティ事件などの弁償となると多額の賠償を請求されることもあり得ます。

そのため、契約書には保障金額の限度額を明記しておくことが必要です。

しかし、このメルマガの趣旨は決して、システム開発を請け負う側（ベンダ側）がうまい契約書を作成し、問題をすり抜けるということではありません。

なぜなら、下記リンク先に記載されているようにITシステムにおける「裁判」は、勝っても負けてもどちらにも勝者はいないのです。（勝つのは弁護士だけ・・・）

・IT訴訟に「勝者」などいない
http://www.ciojp.com/contents/?id=00001038;t=12

この事例は、圧倒的にベンダが悪い例ですが、ユーザーが勝っても、本来の勝者に与えられるべきものを何ひとつ得ることにはなりません。

「ITシステム訴訟を起こされたら」を考える手はじめはどんな事態がITシステム訴訟になっているのか？を知ることです。

このテーマ、次回に続きます。

もし、あなたがITシステムで訴訟を起こされたら裁判に勝つ自信がありますか？

今回は、前回の「もし、ITシステムで訴訟を起こされたら」の続きです。

まず、ITシステムで訴訟に発展する内容として考えられるものの一番として挙げた

1）システム要件を満たさなかったから契約を解除したい。
ユーザーがお金を支払う気が無い。

について取り上げます。

今回の内容は、いつもにも増して真面目で固い（？）ので覚悟してください。

ユーザーが求める「システム要件」とは何を指すのかを考えます。

現在のシステム構築のガイドラインとなっている、共通フレームワーク2007（※）の開発プロセス1.6.2に
※解説　http://www.atmarkit.co.jp/aig/04biz/slcpjcf.html
システム要件定義について以下のように書かれています。

*------------------------------------------------------*
業務全体に対して定義された利害関係の要件のうち、
システムに関する部分について技術的に
実現可能であるかを検証し、システム設計が可能な技術要件に
変換することである。
*------------------------------------------------------*

また、このようにも書かれています。

*------------------------------------------------------*
開発者が契約に従って、実施または支援する
*------------------------------------------------------*

どういった要件を記述するかということも書かれていますが、一番注目したい個所はそのあとです。

*------------------------------------------------------*
1.6.2.2 システム要件の評価

次の基準を考慮して、システム要件を評価する。
評価結果は文書化する。

(a)取得ニーズへの追跡可能性
(b)取得ニーズとの一貫性
(c)テスト計画性
(d)システム方式設計の実現可能性
(e)運用及び保守の実現可能性
*------------------------------------------------------*

つまり、システム要件については、
●利用・運用・保守を含めて示す。
●ユーザーが期待する効果を技術的に実現できるかどうかの根拠と可能性を示す必要がある。
●ニーズを実現したかどうかの評価方法を前もって決めておく。

こう書かれているのです。
これは、当たり前といえば当たり前のことです。
しかし、開発側は、
・要件定義の肝がこういったものだということをユーザーに提示していないのではないか？
・本来のシステム要件の目的をきちんと理解してユーザーに説明していないのではないか？
なぜなら、開発側には数多くの「本当のことが言い難い」理由があるからなのです。

そこで、
・お決まりのドキュメント雛型に収めてごまかして通してしまうことが多いのではないか。
・言い難いと曖昧にしたことが、トラブルを引き起こすひとつの原因になっているのではないか。
と考えるのです。

開発側が考える「システム要件」とユーザー側が考える「システム要件」の違い、これを次回は考えてみたいと思います。

開発側（ベンダー）が考える「システム要件」と顧客（ユーザー）が考える「システム要件」の違い、これが先週お約束した今回のテーマです。

ユーザーは、システム要件をどのように考えているのでしょうか。

確実に言えることは、ユーザーはシステムを使うことによって

・今以上に便宜を得たい
・利益を得たい

と考えています。

具体的には、

・在庫を減らす
・人手を減らす
・ミスを減らす
・顧客満足度を上げる

といった目的もあるでしょう。

しかし、ユーザーにとってシステムを使うことの最終目的は、企業の利益の追求です。

一方、ベンダーの最終目的も、ユーザーの利益の追求なのでしょうか？

もちろん、そう考えていることには間違いはありませんが、残念なことに、ベンダーにとって一番大事なことは“プロジェクトを赤字にしないこと”なのです。

そのため、ベンダーはシステム要件定義書を作成するにあたって「ユーザー側が描いた理想のシステム」の実現の不可能性についてとうとうと説得を始めるのです。

そして、技術レベルを自分たちの能力で楽々と作成できるところまで落とし、時間と人の制約の中で、実現可能な提案をする、これがベンダーの作成するシステム要件定義書なのです。

結果として、受注後の最初の納品物である「システム要件定義書」は、提案書とイコールのものであることは滅多にないのです。

もし、提案書とイコールであっても、金額がイコールではないのです。

つまり、提案書の金額のまま、システム要件定義書が顧客の要望を網羅していることは非常に少ないのです。

なぜなら、提案書を作るときにベンダーの頭の中にあることはいかに競合相手に勝てる金額を提示するかだからです。

また、その金額におけるプロジェクトの詳細は、ベンダーが勝手に描いたものなのです。

これらの思惑から作成されたシステム要件定義書が、曖昧でどのようにでも解釈できるものなら後々、大きな問題を引き起こすことになります。

例えば、開発途中にベンダーからユーザーに対して金額交渉が入るなどです。

実際に、裁判などでベンダーとのトラブルに至るユーザーは、自分たちが最重要だと考えていることを、ベンダーが当然実行してくれるものだ考えていますが、これは違います。

ベンダーは、自分たちが最重要だと考えていること（例えば、打ち合わせをしっかりしようとすればするほど比例して経費がかかること）をユーザーにはなかなか伝えません。

ユーザーがこういったことを簡単に受け入れてくれない、説明するのは難しいとベンダーは思うのです。

結局、システム要件についての問題は、明らかにベンダーが曖昧に対応し続けることがトラブルとなり裁判となるのです。

自分たちが、誇りをもってシステム開発を行っているのであれば「システム要件」をユーザーの視点できちんと開示して固めることが必要です。

それがユーザーにとっては厳しい現実でも早めからきちんと丁寧に折衝しなければいけません。

それでも、プロとして「挑戦」すべきシステム要件には、逃げないで立ち向かう覚悟と度胸が必要ですし、どんなリスクが起こりうるかについてはユーザーの視点でユーザーにわかるように説明する責任があります。

無責任に「なんでもできる」と言って、契約してから考えよう、後から「うまく金をとろう」などというトンデモナイ営業方法は今の時代には、ハイリスク以上のリスクであり確実にシステム訴訟の種となるのです。

しかし、今やベンダーにとって悪夢の時代がやってきました。

開発費3億円を、1億円でやらざるを得なくなってしまう・・・。

次回は別の視点から契約について考えてみます。

日本人は訴訟を嫌う、と言われてきました。

「裁判になってはいけない。可能であれば示談のほうがよい」という考え方が、長い間、世間の常識を作ってきました。

この“臭いものにはふたをする”という考えが、『オレオレ詐欺』という日本発の犯罪を生む土壌になったのも事実でしょう。

オレオレ詐欺は「自分は大丈夫」という気持ちが被害に繋がるようです。

『オレオレ詐欺』と『システム訴訟』（失敗したプロジェクト）を比較するのはおかしなことだと思われるでしょう。

しかし、システム開発を発注する側も、請け負う側も「自分は大丈夫」と走りだしたプロジェクトでトラブルが起こったときに焦って重ねて地雷を踏んでしまうことがあるのです。

どうも人間の脳は「想定範囲外」のことが起こると固まってしまい、様子を見よう、保留しようとするならともかく、自分ひとりの一存で、できれば隠してしまおうとする傾向もあるようです。

そこでベンダーだけでなくユーザーも、前もってシステム開発プロジェクトがうまくいかない場合を考えておくことが必要です。

もちろん「プロジェクトは、うまくいって当たり前」という考えは間違っていません。

しかし、実際には、大規模なプロジェクトになるほど順調に進むことが滅多になくなるのです。

これは敢えて口に出さないまでも、この業界の常識です。

だからこそ「万が一」を考えておく。

それが契約の基本です。

システム要件を決めるための要件定義や外部設計では、ユーザーが、どれだけ時間を割いて打ち合わせに参加し要件を確定したかといったことが費用のかかり具合を大きく左右します。

プロなんだから「かゆいところまで手が届くように」「言わないこともわかってほしい」といったユーザー側の甘えの論理は、システム開発では、なかなか通用しません。

一方、プロジェクトを請け負う側のベンダーは、「契約書」に書かれていなくても、システム開発のプロとしてプロジェクトマネジメントを適切に行う義務を負うことが求められています。

事実、システム訴訟の判例では、システム開発の失敗の原因の一部がプロジェクトマネジメントにあれば、契約に無くともベンダーに損害を賠償する責任を命じています。

ベンダー側のプロジェクトマネジメント義務として以下のようなことが挙げられています。

・決められた開発の手順、手法を守る。

・プロジェクトの進捗を管理し、問題を発見したら適切に対処する。

・ユーザーに課題を示し、ユーザーが納期までに決定できるように指導する。

・ユーザー要望による機能追加・変更が請負金額、納期に影響する場合は、タイムリーに説明し、要望の断念または、金額の増額、納期の延期を求める。

〔参考：日経コンピューター　2007/10/15　トラブルを招く契約、防ぐ契約より〕

このようなことがプロとしての義務であると判決は判示しています。

つまり、どんなに煩がれても、また、ユーザーの機嫌を損ねることになったとしても、なるべく早く、根拠を明示して金額交渉することがベンダーの義務なのです。