契約書のチェックポイント

IT企業の契約書をチェックする際に、知っておかないといけないポイントを解説します。

 

(前文)

前文で、契約当事者の略称が「甲」「乙」と定められ、その後の本文でも、「甲」「乙」と表記されます。

この独特の文字が、契約書に対するアレルギーを引き起こします。

また、甲と乙を間違えて逆にしてしまった場合、明らかな誤記なら大丈夫ですが、どっちがどっちか微妙な場合には、トラブルになります。

そこで、ワードの置き換え機能を使って、甲乙を、いったん社名に置き換えた上で、チェックしてみましょう

ちょっとした工夫ですが、これだけでぐっと契約書がチェックしやすくなります。

 

(仕様変更)

システム開発契約書では、仕様変更の手続が定められているのが一般的です。

仕様変更というものは、システム開発契約で一番起きやすいトラブルです。
(それが有償の仕様変更か、それとも無償の作業なのか、といった類のトラブルです)

この仕様変更の手続について、「変更契約書を作成する」と記載されていることがあります。

しかし、ベンダー側としては、そこまできっちりやることは困難です。

 

そこで、貴社がベンダーの場合は、仕様変更の手続について、もっと簡単な内容にしておきましょう

 

(表明保証)

ベンダー側で、システムが第三者の知的財産権を侵害していないことを表明して保証するよう、求められることがあります。

表明保証には、ついつい軽い気持ちで応じがちですが、これは危険です。 開発したシステムが、たまたま第三者のシステムと似通っていた場合でも、「侵害」にあたり、表明保証に違反する可能性があります。

あくまでも、盗作・流用をしていないことについて、表明し保証するだけに留めておきましょう

 

(成果保証)

SEO対策や、コンサルティング業務を行う場合に、成果まで保証することは難しいです。 かといって、成果を保証しない、という条項を入れてしまっては、魅力的なサービスにはなりません。

そこで、成果ではなく、目標実現に向けての貴社の取り組みを保証する内容にしておきましょう

それなら、貴社がきちんと取り組みを行えば、例え成果が出なくても、契約違反にはなりません。

 

(知的財産権の帰属)

ユーザー側としては、費用を払った以上、システムの知的財産権を当然に取得できると考えがちです。

しかし、システムは、色々なモジュールで構成されています。

貴社の汎用性モジュールを組み込んで、システムを開発することもあると思います。

もし、システム全体の知的財産権を譲渡してしまうと、今後貴社は、汎用性モジュールを使えなくなってしまいます

ユーザーに知的財産権を譲渡する場合でも、システム全体を対象としないように制限しておきましょう

 

(損害賠償)

システム開発契約や、システム利用契約では、システム障害時のユーザーの損害額が、莫大なものになりがちです。

それにも拘らず、損害賠償について、「相手に生じた損害を賠償する」と単純にしか記載していないと、ベンダー側の賠償責任は、大変なことになります

そこで、賠償額について、「いくらまでしか支払いません」という、上限規定を設けておきましょう

ただし、上限があまりにも低すぎると無効になるので、注意しましょう。

 

(秘密保持)

営業秘密や顧客情報を扱う場合は、秘密保持の義務を定めるのが一般的です。

その際は、貴社が秘密を渡す側か、それとも受け取る側か、注意してください。

渡す側の場合は、秘密を漏らされないよう、できる限り厳しい内容の秘密保持義務にすべきです。

一方、受け取る側の場合は、負担や責任を減らすためにも、できる限り緩い内容の秘密保持義務に留めるべきです。

契約書の雛形は、厳しい内容の場合がほとんどですので、貴社が秘密を受け取る側の場合は、注意しましょう。

以上が契約書のチェックポイントですが、契約書の専門用語や、契約書独特の言い回しは、専門家でない限り、理解するのは難しいです。

契約書のチェックを弁護士に依頼しておくことで、法的なリスクを、最小限に抑えることができます

見積もりだけなら無料ですので、お気軽にお問合せください。