契約書のチェックでトラブルを
未然に防ぐ
日常的に他社と契約を交わす必要のあるIT企業やベンチャー企業では、トラブルを未然に防ぐために、契約書作成や、締結前のリーガルチェックが重要となります。

システム開発をめぐる紛争

システム開発をめぐる紛争を避けるためには、実際、いかなる原因により紛争が生じているかが重要となっていますが、トラブルの元になるのは、正式なシステム開発契約書を締結していないにもかかわらず、システム開発作業に着手し、紛争に発展するというものです。実は、私たちもホームページを発注した際、「ドメインエイジ」が大事ですからと、契約内容を詰めないで、着手・納品され、その後のPDCAサイクルに支障が出たというケースを経験しました。

私たち利用する側からみますと、開発工程のフェーズごとに契約を分ける多段階契約を採用するよりも請負とした方が有利となります。ユーザーとしては、要件定義から運用テストまでは全ての工程につき、一括の請負契約を締結することにより発注するのが有利といえそうです。

当局の見解は異なるようですが、システムといっても、開発期間も1年程度ですし永年的に使用するわけでもありません。当局がいうような段階ごとに重要事項説明をして個別契約を締結するという契約形態になってしまいますと、私たち利用する側はほとんど供給者の契約条件を「約款ですから」という理由で受け入れざるを得なくなってしまいます。外部設計について、請負か、準委任かという契約交渉上のポイントがあります。製造者の仕事の完成責任の有無や瑕疵担保責任の有無などがありますが、特に外部設計を準委任としなければならない、という理由はありません。

実際に、私たち利用者が行ったコンペでシステム開発案件を勝ち取り、初めてそのユーザーのシステム開発案件を製造者が担当する場合であっても、外部設計を請負契約で行っている事例は稀です。安易に準委任にしてしまいますと、開発業務終了後のシステムテストフェースにおいても準委任で行うことが要求され、新たな請求がされる可能性があるといえます。しかしながら、道徳的にいえば、システムはある程度の不具合は織り込み済みになっていますので、その後のことは一定程度、製造者に面倒をみさせる内容になっていなければ道徳的におかしく、それを法的判断に落とし込むのが商道徳として正しいのではないでしょうか。