③IT契約書コンサルティング

得意先との契約締結を機会に、契約書のひな形一式を整備した事例です。

 事案   A社は、独立系のシステムベンダで、従来はインフラ系中心で業績を伸ばしていましたが、ここ1~2年はアプリケーション開発にも力を入れる方針で来ています。しかし、経験の薄さもあって、RFPが不明確なままの一括請負や、正式契約前の作業開始などの問題が毎回のように起こり、赤字プロジェクトを生んでいました。今回の案件は、得意先からの継続案件でしたが、「なあなあ」の関係が災いして、また同じことの繰り返しとなる危険がありました。そこで、これを機に、正しい契約プロセス、管理プロセスが組み込まれた契約書類・ドキュメントのひな型を整備すべく、ITSに依頼しました。

 解決  まず、A社の状況をベースに、今後最も受注の可能性が高い契約類型を整理してパタン化しました。そして、大きく受注型と再委託型に分けた上、それぞれについて開発契約書、保守契約書、ASP契約書のひな型とその解説マニュアルを作成し、法務担当者とプロマネ担当者に対してセッションを行うところまでを1セットとした、「IT契約書コンサルティング」を実施しました。契約書本体では、再見積を前提とした多段階契約を採用すること、顧客との元請契約と再委託先との下請契約の条件の違いから生じるリスクをなくすこと、マニュアルでは、相手先から良く出る変更要求に対する対処と要求を受け入れる場合の変更案を示すこと、影響を受ける変更箇所が容易に分かるようにすることに留意しました。

 ポイント  契約書に対するリーガルチェックが不十分なままであると、認識しない大きなリスクを背負い込むことがあります。損害賠償や免責の条項など、1個の条項でも大きな違いを生むものがあります。大手のシステムベンダであっても、弁護士によるリーガルチェックを経ていないのか、このようなものが放置されているケースがままあります。契約条件の有利/不利を含めて、最終的にどこまでのリスクを取るかは、相手方との交渉次第という面もありますが、まずリスクを認識しないことには話が始まりません。また、IT系の契約の場合、契約書本体だけでなく、添付の仕様書や契約書の前段階の見積書、提案書(ユーザの場合なら、RFP)から注意が必要となります。

※ この事例は説明用のもので、実際の事件とは一切関係がありません。