システム開発の取引トラブルを防ぐために | 青山システムコンサルティング株式会社

TEL:03-3513-7830|お問い合わせ

コラムカテゴリー:

 ITの進歩はめざましく新たな技術や応用方法が次々と生み出されていますが、企業のシステム開発においては、失敗やトラブルはなかなか減らず頭の痛い問題になっています。

 うまくいかない原因は様々ですが、ユーザー(発注企業)とベンダー(受注企業)の取引内容を明確にしないまま、開発に着手してしまっていることがよくある原因の1つです。

 取引内容を明確にするにはシステム開発を始める前に最低限契約書の中身を双方吟味することが必要ですが、不十分なまま始めてしまうことが多いようです。

 契約書にどのような条項を入れるべきか分からない場合は、まずは経済産業省が公表している契約書のサンプルを参考にすると良いと思います。

■参考:モデル取引・契約書<第一版>及び<追補版>

 上記の中で、しっかりと詰めておかないと特にトラブルが起こりやすい3点をご説明します。

 

1.納入物の著作権の権利帰属及び利用について

 権利関係を曖昧なまま、もしくは意識しないまま開発を進めるケースがありますが、事前に決めておくべきです。

 ユーザーは納入後の改変や業務ノウハウ流出防止のため著作権を保有したいと考えますが、ベンダーは他社向けの開発で流用し開発効率を上げるべく著作権を保有したいと考えることが多いようです。

 プロジェクトの事情によりますが、一般的な民間企業の業務システムの開発であれば、ベンダーが保有するのが妥当と言えます。
 理由は、ユーザーが著作権を保有するとベンダーの見積金額が増加することが多いので、ベンダーが保有した方が全体のコストを抑えられるからです。
 また、業務ノウハウの流出は著作権を保有しなくても機密情報保持条項やNDAで防止できるからです。

 ただし、ユーザーが自己使用の範囲において自由に複製や改変することを必要とするのであれば、所有権はユーザーが保有することを明記する必要があります。

 それでも業務ノウハウを含むプログラムが流用されないか不安に感じることがあるかと思います。その場合は、可能であれば流用可能な「汎用的なプログラム」と流用不可能な「業務ノウハウを含んだユーザー固有のプログラム」を双方で明確にしておくと良いです。
 更に、ベンダーが業務ノウハウが何であるか理解しないまま無意識に流用してしまうことに不安に感じるのであれば、業務ノウハウの該当部分を書面に起こし取り交わすことも有用です。

 

2.ユーザー、ベンダー相互の協力義務について

 システム開発はユーザーとベンダーとの共同作業なので、相互の協力義務が必要になります。

 ユーザーの協力とは、プロジェクトが滞りなく進むよう人員体制を整備することや、期日迄に要件を提示すること等を指します。
 一方、ベンダーの協力とは、計画していたプロジェクトがユーザーにより進行が阻害される場合に働きかけを行うこと等を指します。
 例えば、ユーザーが仕様変更や機能追加を依頼した場合、その要求が委託料や納入期限等に影響を及ぼすものであった場合にユーザーに対し適時その旨説明して、要求の撤回や追加の委託料の負担等を求めるといった事が該当します。

 契約書においては、これらを明記して双方が負うべき義務を認識するようにした方が良いです。
 更に、違反をした場合は結果の責任を負うことも明記し、ただの努力義務ではなく契約上の義務とすることが重要です。

■モデル取引・契約書の記載例

  • (協働と役割分担)
  • 第8条 甲及び乙は、本件業務の円滑かつ適切な遂行のためには、乙の有するソフトウェア開発に関する技術及び知識の提供と甲によるシステム仕様書の早期かつ明確な確定が重要であり、甲乙双方による共同作業及び各自の分担作業が必要とされることを認識し、甲乙双方による共同作業及び各自の分担作業を誠実に実施するとともに、相手方の分担作業の実施に対して誠意をもって協力するものとする。
  • 2. 甲乙双方による共同作業及び各自の分担作業は、別添○のとおりとし、各個別契約においてその詳細を定めるものとする。
  • 3. 甲及び乙は、共同作業及び各自の実施すべき分担作業を遅延し又は実施しない場合、それにより相手方に生じた損害の賠償も含め、かかる遅延又は不実施について相手方に対して責任を負うものとする。

■参考:コンサルタントコラム「準委任契約でITベンダーが負う義務とは」

 

3.業務範囲の明確化について

 ユーザーとベンダーの業務範囲の認識が異なるために後々になってもめるケースが良くありますので、契約書に明記しておく必要があります。

 通常は要件定義書や役割分担表に明記します。作成前の段階であればRFPを作成して要求を文書化し契約書の基礎資料にします。

■参考:役割分担表の例(情報システム・モデル取引・契約書 参考文書2【P118】)

 提案書の内容を基に発注先を決め契約する場合、提案書の内容がどこまで契約範囲に含まれるかという議論をされることがあります。
 提案書に記載されていても契約書に記載が無ければ、通常は契約範囲外としてみなされます。契約書の別紙として提案書を添付する方法がありますが、通常提案書は費用や委託内容を交渉する以前の最大範囲の内容であることが多いので、契約書に適しません。
 よって、提案書の内容のうちどこか契約範囲なのかを指し示す記載を入れると良いです。

 

最後に

 契約書の内容は軽視されることが多いですが、事前にしっかりと認識を合わせることで後々のトラブルをかなり減らすことができます。

 ユーザー側はシステム開発の取引に不慣れのため、業界慣習や商法や民法とかけ離れてないか、内容の妥当性を判断できないケースがあると思います。その際は外部のコンサルタント等の意見を参考にして契約することをお勧めします。

 

関連サービス

プロジェクトマネジメント
システムアドバイザリーサービス

この投稿をシェア

2015年05月19日 (火)

青山システムコンサルティング株式会社

池田洋之