日本人は訴訟を嫌う、と言われてきました。
「裁判になってはいけない。可能であれば示談のほうがよい」という考え方が、長い間、世間の常識を作ってきました。
この“臭いものにはふたをする”という考えが、『オレオレ詐欺』という日本発の犯罪を生む土壌になったのも事実でしょう。
オレオレ詐欺は「自分は大丈夫」という気持ちが被害に繋がるようです。
『オレオレ詐欺』と『システム訴訟』（失敗したプロジェクト）を比較するのはおかしなことだと思われるでしょう。
しかし、システム開発を発注する側も、請け負う側も「自分は大丈夫」と走りだしたプロジェクトでトラブルが起こったときに焦って重ねて地雷を踏んでしまうことがあるのです。
どうも人間の脳は「想定範囲外」のことが起こると固まってしまい、様子を見よう、保留しようとするならともかく、自分ひとりの一存で、できれば隠してしまおうとする傾向もあるようです。
そこでベンダーだけでなくユーザーも、前もってシステム開発プロジェクトがうまくいかない場合を考えておくことが必要です。
もちろん「プロジェクトは、うまくいって当たり前」という考えは間違っていません。
しかし、実際には、大規模なプロジェクトになるほど順調に進むことが滅多になくなるのです。
これは敢えて口に出さないまでも、この業界の常識です。
だからこそ「万が一」を考えておく。
それが契約の基本です。
システム要件を決めるための要件定義や外部設計では、ユーザーが、どれだけ時間を割いて打ち合わせに参加し要件を確定したかといったことが費用のかかり具合を大きく左右します。
プロなんだから「かゆいところまで手が届くように」「言わないこともわかってほしい」といったユーザー側の甘えの論理は、システム開発では、なかなか通用しません。
一方、プロジェクトを請け負う側のベンダーは、「契約書」に書かれていなくても、システム開発のプロとしてプロジェクトマネジメントを適切に行う義務を負うことが求められています。
事実、システム訴訟の判例では、システム開発の失敗の原因の一部がプロジェクトマネジメントにあれば、契約に無くともベンダーに損害を賠償する責任を命じています。
ベンダー側のプロジェクトマネジメント義務として以下のようなことが挙げられています。
・決められた開発の手順、手法を守る。
・プロジェクトの進捗を管理し、問題を発見したら適切に対処する。
・ユーザーに課題を示し、ユーザーが納期までに決定できるように指導する。
・ユーザー要望による機能追加・変更が請負金額、納期に影響する場合は、タイムリーに説明し、要望の断念または、金額の増額、納期の延期を求める。
〔参考：日経コンピューター 2007/10/15 トラブルを招く契約、防ぐ契約より〕
このようなことがプロとしての義務であると判決は判示しています。
つまり、どんなに煩がれても、また、ユーザーの機嫌を損ねることになったとしても、なるべく早く、根拠を明示して金額交渉することがベンダーの義務なのです。
Vol.00185