IT・Webサービスに関わる契約・規約

業種別活用法アドバイス

  • 契約書の内容によってはその他必要書類があります。

IT・Web関連における契約書・規約の注意点について弁護士が解説(雛形有り)

いまやビジネスに欠かせないものとなったIT。ソフトウェア開発やシステム開発、アプリ開発、Webサービスなど、多くの企業でさまざまなIT活用が広がっています。うまく事業を成長させて、新たなサービスやシナジーを生み出していくためには、企業間のスムーズな契約締結が不可欠といえるでしょう。

IT企業においては、自社開発のソフトウェアを販売あるいはリースしたり、企業間で技術やノウハウを持ち合わせて共同開発を行ったりと、多方面でのビジネス展開が期待されます。その分、企業としてのさまざまなメリットが期待できますが、同時に思わぬトラブルや不利益を被るリスクも潜んでいます。

ソフトウェアやWebなどのIT分野は、商品として目に見えない無体物のため、契約内容やその詳細について明確化・文書化しづらいという側面があります。実際に、契約書の条項や文言ひとつで、当事者間の認識に齟齬が生じ、紛争に発展するケースも少なくありません。

法律を遵守しつつも、自社にとって有利な契約を進めていくためには、提示された契約書をそのまま受け入れるのではなく、当事者間で交渉を行いながら、条項や文言など綿密に調整していくプロセスが重要です。このようなIT・Web分野は、法律やビジネスに関する専門的な知識が求められるため、IT法務に精通した弁護士に実務的なサポートを受けることをおすすめします。

IT・WEB関連での注意点

システム開発やWebサービス提供を行うIT関連の企業では、ソフトウェア開発委託契約やプログラムリース契約など、さまざまな契約が取り交わされます。IT・Web関連は高度の専門性を伴う分野のため、契約に際しては十分な注意が必要です。

よく精査せず契約を結んでしまうと、自社に一方的に不利な条件を設定されていたり、トラブルが起きた際に自社に多大な損害が及ぶ可能性があります。大規模なシステム開発であれば、取引額が100万円~1,000万円以上に及ぶケースもあるため、IT・Web関連の契約時にはその内容について十分注意が必要です。

契約書を使用しないリスク

IT企業の取引では、ソフトウェアやWebサービスなどのシステム開発を企業に委託するとき、発注書や注文書のやり取りだけでプロジェクトが進められることも珍しくありません。商慣習により、口頭のみで開発がスタートすることもあるほどです。

しかし、契約書を作成せず、お互いが契約内容をよく知らないままプロジェクトに着手したことにより、「双方の意見が食い違っていた」「想定していた完成品とは異なっている」など、認識に齟齬が生じるリスクがあります。開発途中や完成後の成果物を巡ってトラブルに発展するケースも少なくありません。

従来から取引のある企業であっても、信頼関係だけでシステム開発を依頼・受託することは避けることが重要です。契約書を作成することで、プロジェクトに対する目的や開発内容が明確化され、トラブルのリスクを抑えることにつながります。

イメージ共有・文書化の難しさ

IT分野の取引においては、システム開発の完成形・開発内容などを当事者間で共有するのが難しいという要素があります。目に見える商品の開発であれば、設計図や仕様書などから完成形をイメージしやすいですが、ソフトウェアやWebサービスなどは形がありません。

プロジェクトの最初の段階で完成形を明確に定義したり、必要な機能や性能、スペックなどを文書化することは非常に難しいといえます。契約書を作成したものの、開発内容や完成形について明確に定義できておらず、双方の主張が食い違うことも考えられるでしょう。

開発されたシステムが発注者の想定と異なれば、仕様変更や追加作業が必要になるため、納期や開発コストを巡ってトラブルに発展することも珍しくありません。開発側の企業としても、契約どおりにシステムを完成させたにもかかわらず、不備・不十分で差し戻しされたり、瑕疵を訴えられる可能性があります。

契約書を作成する際は、想定されるリスクを考慮して、掲載内容に具体性を持たせるとともに、必要な事項を漏れなく盛り込むことが重要です。

著作権等の権利が誰に帰属するか

IT関連の契約においては、成果物であるプログラムの著作権等の保有を巡って交渉が難航するケースが多く見られています。開発者であるベンダーは、自社開発したプログラムを再利用するために、自社の権利として保有したいと考えるのが妥当です。一方で、ユーザーである発注者は、自社の機密情報を保護する観点や、プログラムを自由に利用するために、幅広い権利を取得したいと考えることが一般的です。

とくに、お互いの技術やノウハウを持ち合わせる「技術共同開発契約」においては、成果物の著作権のみならず、開発に用いられた技術・ノウハウ・購入設備などの著作権等の帰属について争われるケースも多く見られます。

ソフトウェア等の開発をめぐる契約においては、ベンダー側が著作権を保有しつつ、ユーザーに使用許諾権(ライセンス)を 付与したり、成果物の新規開発部分のみユーザーに帰属させる、双方が権利を共有するといったパターンが考えられます。

大切な自社の技術・ノウハウなどの知的財産権が不本意に利用されないよう、著作権等の範囲を明確化し、双方で疑義が生じないよう合意しておくことが重要です。

システム会社でよくある法律トラブル

ITにまつわる契約では、さまざまな法律トラブルが起こり得ます。よくあるトラブルには、以下が挙げられます。

納品・検収に関するトラブル

システム開発を伴う契約においては、以下のようなトラブルがあります。

  • 開発途中で何度も改修を依頼され、追加費用を払ってもらえない
  • 成果物を納品したものの、無償で改修を依頼された
  • 成果物が不十分として検収を完了せず、代金を支払ってもらえない

ソフトウェアやWebサービスなどのシステム開発の契約では、開発途中に仕様変更や改修要望がなされるケースも少なくありません。その際に、発注者から追加費用を支払ってもらえない、無償での改修を要望されるなどといったトラブルが発生しやすくなります。

成果物の定義が難しいITの分野では、お互いの完成形のイメージが一致しておらず、「想定していたシステムと違った」「求めている機能が備わっていなかった」などと主張されることも多くあります。こうしたトラブルを防ぐために、契約書には開発内容や仕様について具体的に定め、こまめに当事者間で進捗をチェックすることが重要です。

瑕疵(契約不適合)によるトラブル

成果物を納品したあとに、動作不良やシステム障害などが発生した場合、発注者からベンダーに対して瑕疵担保責任(契約不適合責任)を追及されるケースがあります。瑕疵(契約不適合)によるトラブルには以下が挙げられます。

  • 納品後に不具合があると主張され、契約解除を希望される
  • 契約内容どおりの成果物でなかったため、ベンダーに損害賠償を請求する
  • 引き渡しから1年以上経ってから、瑕疵(契約不適合)を主張されている

システム開発関連の取引で問題になりやすいのが、「どのような不具合や支障が瑕疵にあたるか」という点です。発注者としては、動作不良やバグなどの不具合が見つかったとき、補修や代替措置、損害賠償請求をしたいと考えるのが通常です。しかし、その不具合の原因がベンダーの責めに帰すべき事由でない場合には、瑕疵(契約不適合)にあたらない場合もあります。

また、ベンダー側として考えると、問題なく成果物を納品したものの、長期にわたって瑕疵担保責任(契約不適合責任)を負うことは不合理と考えられます。瑕疵(契約不適合)の修復や損害賠償請求によって多大なコスト損失を生まないためには、瑕疵担保責任(契約不適合責任)の保証期間や代替措置について定めておくことが重要です。トラブルに発展すると長期化するケースも多いため、弁護士相談のもと契約書の事項を検討しましょう。

IT・WEB関連で弁護士がサポートできること

ソフトウェアやWebサービスなどのIT分野では、成果物が目に見えにくいこと、専門的な知識を要することなどから、当事者間で意見の食い違いが生じることも少なくありません。訴訟に発展すると複雑化・長期化するケースもあるため、企業にとって大きなリスクとなります。

また、IT関連の取引に用いる契約書には、権利帰属や免責規定などのさまざまな条項を盛り込む必要があります。契約条件やサービス・開発内容によっても必要な規定は異なるため、自社のみで対応するのは危険といえます。法律的に有効かつ企業に実態に即した契約書を作成するためには、IT関連の契約に強い弁護士のサポートを受けることをおすすめします。

弁護士法人キャストグローバルでは、ITトラブルによく見られる納品・研修をめぐるトラブルや、瑕疵担保責任(契約不適合責任)、著作権等の権利問題について、リスクを最大限軽減した契約書作成をサポートいたします。交渉が難航しやすい取引においても、貴社に有利な条件での契約締結を目指します。

万が一、当事者間でトラブルに発展した際には相手企業との交渉にあたるため、紛争の長期化・複雑化を防ぎ、企業の損失を最低限に抑えることにもつながります。ITにかかわる契約書の作成やトラブル相談は、弁護士法人キャストグローバルまでご連絡ください。

ページ上部へ
CLOSE

Copyright© 契約に強い弁護士の知恵袋 , 2024 All Rights Reserved Powered by AFFINGER5.