№2139 IT契約，寛容と忍耐が肝要
システム開発契約は特殊なことばかり
IOTの発達がめざましいが，契約方面はなかなか追いつかない。ソフトウェアなどのシステムはベンダー側（提供側）もユーザー側も専門性があって，弁護士は理解するのが大変だ。中には，ITというだけでいやになっている人もいるかもしれない。
ソフトウェアなどのシステム開発契約の最大の特徴は①契約時に仕様が未確定であることが多いこと，②ベンダー，ユーザー双方の共同作業によって仕事が完成していくこと，③完成後も調整が必要になることがある。一般的な契約はこの逆で，仕事の内容は図面などで最初から決まっているし，買い主が義務を負うことはきわめて少ない。
契約時だけでは解決つきません。その後のプロセスが大切です。
このような契約にあっては，契約時作成される契約書の工夫もさることながら，契約が履行されるプロセスも法的関係を視野にいれつつ律せられていく必要がある。この動的なプロセスはこれまで契約などの法律文書であまり検討されてこなかった分野ではないかと思う。
何をもって欠陥という言うかわからなくなる
契約時の仕様があいまいだと，何をもって完成といいうるか分からないことになってしまう。一般には不具合があると債務不履行責任となるが，そもそも，不具合と言っていいのか，当初契約された内容と異なった履行がされたと言いうるのか問題になってしまう。この当たりは，契約履行のプロセスでたえず確認作業が求められることになる。双方が議事録やメールのやりとりについてできるだけ確定的な文書を取り交わすのが望ましい。
期待した効果がないというのは説明義務の問題
完成時，システムソフトウェアで約束された性能が実現していないということがしばしば問題になる。しかし，これはソフトウェアの欠陥というのではなく，システム化の結果として期待された内容を実現できていないという意味になる。この場合，ベンダーは依頼者の期待を裏切ったことになるが，どのような期待を抱かせていたかという，説明義務にかかわる問題ということになる。
ユーザー側、買主の協力義務というのも特徴的
システム開発にはユーザー側の協力が不可欠だ。しかし，システムには全くシロウトのユーザーであるからベンダー側がプロフェッショナルとして協力を引き出す義務もある。契約全体のプロセスを管理する責任がベンダーにはある。
ベンダー側は担当窓口ばかりでなく，実際に現場で利用する従業員からの事情聴取も必要な場合があろう。一方で，担当窓口がうまく社内で意思統一を図り，事情聴取が適切に行われるようにしたり，個々に一貫性のない要求にならないよう注意する必要が出てくる。こうしたコミュニケーションプロセスが重要になる。
ソフトウェア開発契約の心構え
① 提案依頼書，契約書，要求仕様書，要件定義書，基本設計書など
契約時の一般的手順を軽視しないこと
② ユーザーはシステムに対して過剰な期待をいだかないこと
③ ユーザーはしかるべき協力が必要である。
スケジュール通り実行しなければ双方に大きな傷を負わせることになること
④ ベンダーは現場を重視すること
⑤ ベンダーは相手にボールをなげて遅延を相手のせいにしないこと
⑥ スケジュールより遅れている場合など、早い段階で問題を改善すること
⑦ 導入直後は必ずしもうまくいかず，調整が必要と理解すること
名古屋Ｅ＆Ｊ法律事務所へのお問い合わせはこちら
