システム開発における受注者、発注者間のトラブルは、大きく分けて3つある。それらはときに訴訟問題に発展する恐れがある。それを回避するためには、個別の案件ごとに、受注側、発注側双方の創意や工夫を盛り込んだ、詳細な契約が不可欠である。本講座では6回にわたって、契約・法律の基礎を解説する。
筆者は、日本IBMに在籍した21年余りの間、社内弁護士、法務・セキュリティ・知的所有権担当取締役、同常務取締役として、情報産業の中で発生するほとんどの法的トラブルに直面、対決、処理してきた。日本IBM退職後も、弁護士としての主たる活動領域は、情報と通信の領域である。
活動を通じて痛感しているのは、現在の立法が、情報産業内に起こる法律問題に十分に対応しきれていないことであり、法律による対応不足から生じる法的リスクは、自らの手で管理し、防御する以外に効果的な方法がないということだ。そして、自衛的管理に最も効率的な手段は契約である。本連載は、その観点からの筆者の提案である。
仕様書、プロジェクト管理、著作権が御三家
システム開発は、ユーザー企業にとってもシステム開発会社にとっても、長いビジネスプロセスである。単に開発技術の優劣や開発するシステムの難易度、ユーザーのビジネスニーズという技術やビジネス上の問題にとどまらず、開発に携わる発注者、受注者双方の多数の関係者の人間関係のマネジメントも重要な要素になる。その上、ITは個々の成果物の内容がそれぞれ異なるという特徴がある。そのことが、システム開発において法律問題が頻発する要因でもある。
システム開発において、しばしば発生するトラブルは、大きく分けて3つある（図）。（1）仕様書が存在しない、もしくは仕様書の欠陥に起因する開発トラブル、（2）システム開発プロセスの不十分な管理や、システムの受け入れテストの方法や期間、テストデータに関する明確な事前合意が存在しないなど、プロジェクト管理に関するトラブル、（3）システム開発によって創出されたプログラムやその他の著作物上に成立する権利の帰属に関するトラブル──である。
 |
| 図●システム開発契約におけるトラブルの“御三家” |
筆者は、これらのトラブルをシステム開発における「トラブルの御三家」と呼んでいる。これらの法律問題は、ときにシステム開発業者を訴訟その他の法的トラブルに巻き込む危険性がある。
日本のみならず、ほかの欧米諸国においても、情報取引に関する立法や判例の生成は立ち遅れている。システム開発の成果物であるプログラムその他の創作物に関しては、改正著作権法や特許法、トレードシークレット法（不正競争防止法の一部）などがある。しかし、情報取引そのものに関する特別立法は、インターネット関連および通信販売などを取り扱う特定取引法があるぐらいである。
実際、ほとんどの情報取引は、民法および商行為法（商法第一編（第1条～61条））、および商行為法総則（商法第三編（第501条～第558条））によって規制されているだけである。そしてこれらの法律はいずれも、コンピュータやそのためのシステム開発などが存在しなかった19世紀後半に制定された取引法である。これらの立法がコンピュータおよびソフトウエアの取引、その他の情報サービス取引を規制するのである。
結局、立法、司法における情報取引判例法確立の遅れと業界におけるビジネス実態との間のかい離、その結果起こる前述のシステム開発におけるトラブルの御三家の多くは、現状では、契約の規定に従って解決する以外に効果的な対処法が存在しない。
そこでは、契約当事者間によるトラブル回避のためのリスク管理が要求される。取引の自由（契約自由の原則と呼ばれている）を前提として、取引両当事者の創意と工夫により、適切なルール規範を考え出し、その規範を1つに文書にまとめたものが契約書である。
契約による詳細な合意が必要
契約書を作成する際に「国家が制定した法律に任せればよい」という考え方は、しばしば起こる失敗の1つだ。法律に契約に関する規定があるとしても、個々の契約のためのものではなく、同種もしくは異種のたくさんの契約を抽象化して、広く適用されるように一般化されたものである。
それに対して、実際の契約は、対象となる具体的な取引関係を規制するための個別の法律となる。システム開発契約はいわば、契約の両当事者を拘束する「自治法」を制定する行為なのだ。そのため、取引内容を詳細に特定し、各当事者が相手方に対して、どういう義務（相手方から言えば権利）を有するかを明確に規定しておかなければならない。
例えば仕様書のトラブルには、本来発注者が作るべきものを、実際には受注者が作成することが、発生原因につながるケースが多い。そして発注者は、その仕様が自分の意図と違っていることを把握できずトラブルへと発展する。だが、発注者がいくら「そんなはずではなかった」といっても、法律上、発注者が合意した仕様書に沿って作ってあれば、受注者は責務を果たしたことになる。
それだけに、仕様書の作成義務がどちらにあるのかを、契約に明記しておくことが不可欠だ。開発だけでなく、成果物の製品検査においても、どこをチェックするのか、検収のためのテスト方法や合格の条件は何かを、開発契約で明確にしておくことが重要になる。
また、システム開発は、当初の請負契約通りに完了することはまれで、実際には開発途中で仕様に変更が生じることがほとんどだ。そうした変更は、変更契約を結び、常に文書化しておく必要がある。文書化といっても、必ずしも「契約書」そのものだけを示すのではない。合意書、確認書といった書類も、法律上は、契約書として認められる。
本連載では6回にわたって、前述の御三家を中心に、システム開発契約におけるトラブルを回避する様々なリスク管理について、具体的に解説していく。次号では、請負型や受任型など、開発契約の形式別のリスク管理について取り上げる。
|
