開発プロジェクトの失敗しない契約書とは、そして現場も契約書を読もう――『システム開発 受託契約の教科書』著者 池田聡氏インタビュー

ビジネスはギブ＆テイク――裁判沙汰はかえって不利益

　ビジネスの現場では、さまざまな場面で交渉事が発生すると思います。銀行は交渉事がとても多い。それは弁護士も同じです。ただし、その姿勢は大きく違います。

　一般のビジネスでは、お互いにどこで折り合いをつけるかを最初から考えながら交渉します。無茶なことを言って相手を怒らせてしまったり、交渉のテーブルを潰してしまうようなことはあまり言いません。

　ところが、弁護士の交渉は必ずしもそうではありません。後ろに裁判があるからです。相手は裁判をされたら困るだろうと考えて、話し合いが壊れてしまうようなことを平気で言うことがある。そういう意味で交渉のプロセスが違います。

　もちろん、すべての弁護士がそんな「高めのボール」ばかりを投げるわけではありません。やはり交渉はケースバイケースです。

　個人の話でしたら相手とケンカすればそれで済んでしまうかもしれませんが、企業間の場合はそうはいきません。特に、利害関係がある仕事上のパートナーとのケンカは、かえって不利益になってしまう。いくつも商談がある取引先と、この件について揉めているからといって、他の商いまで潰すわけにはいきません。

　争いはあるかもしれない。けれども、本当に大ゲンカしていいのかは考えなくてはならない。ビジネスはギブ＆テイクですから。案件によってやり方は考えなければいけないし、大ケンカも避けなければならないのです。

契約を解除してもゼロではすまない

　実は、裁判になって“良いこと”ってあまりないんです。とりわけ、システム開発はそうだと思います。まず開発会社は客を失います。ではユーザーから見るとどうなのか。

　例えば、請負契約では、開発側が納期に間に合わせることができなくて債務不履行で契約解除したとしても、ユーザーが利益を受けた範囲は代価を支払わざるを得ません。つまり、ゼロでは済まないんです。

　しかも、システム開発は人に依存しているところが大きいもの。そのため、ドキュメントがきちんとしていたとしても、他の人が引き継ごうとしてもかなり手戻りが発生してしまう。そうすると、大きなロスが出ます。だから、ケンカしてそれで終わりというのは、経済的にも合理的な決断にはなりません。

　システム開発では、当初の期限を過ぎてしまうことは多々あります。そして、遅れてしまったら、遅れの幅を少なくして完成させるしかありません。ユーザーもベンダーもこれに異論はないはずです。それができなかったとしても、いきなり紛争になるのではなくて、費用負担をどうするかというところで大体は終わります。

　銀行もそうですが、大企業には法務部があります。彼らは、裁判例などはよく勉強しています。そのため、契約を考える上で、最終的に紛争になったらというところに目が行ってしまう。しかし、実際の現場はそうではありません。法務部が出てくるようなレベルの紛争から後のことを前提にしている契約もありますが、その前にもっとやることがあるんです――まず、どうやって作ればいいかを考えることです。

プロセスを契約書に明記することで失敗を減らす

　システム開発をうまくやるためには、プロセスをきちんと踏んでいくのが重要です。前半のプロセスがいい加減だと、後でそのしわ寄せが来て失敗します。ポイントは、このプロセスを踏むということを、契約書に書面化するところにあります。これをおろそかにしないため、このプロセスを契約書に明記し、契約上の義務にすることで失敗を減らせます。

　もちろん、紙に書くこと自体が目的ではありません。大事なのは、契約書に何を盛り込むのかを決めることです。何もないと決めることをサボりがちなので、意識を強く持って、役割分担、体制、課題管理、仕様管理のルールなどを、契約する前に必ず詰めるようにします。このような習慣をつけることで、失敗を減らすことができるのです。