弁護士・情報処理安全確保支援士　石田　優一

※このコラムは、2024年9月に開催したIT企業向け無料セミナーの内容をもとにしたものです。

目次

１　契約書は何のために作るのか？
２　ケーススタディ
３　契約書レビューの進め方
４　プロジェクトの特性を踏まえているか１－要件定義・設計
５　プロジェクトの特性を踏まえているか２－コーディング・納品
６　トラブルから自社を守れるか？
７　自社の知財・ノウハウを守れるか？
８　まとめ

コラムのテーマ

ＩＴベンダーであれば避けて通れないシステム開発紛争の問題。その原因は、初めに結んだシステム開発契約書にあるかもしれません。よりよいシステム開発契約書のレビュー（リーガルチェック）の進め方を、弁護士の視点からケーススタディで解説します。

１　契約書は何のために作るのか？

契約書を作成する目的は？

システム開発契約書の話題に入る前に、そもそも「契約書は何のために作るのか？」について、お話しします。

・取引相手が契約書を求めてきたから、とりあえず作ってみた。
・みんな作っているし、なんとなくあったほうがよいかなと。
・作らないと、社内の稟議を通せないから。

このような消極的な理由で、「とりあえず」契約書を作成する方も、多いかもしれません。ただ、これでは、契約書作成が、「単なる慣例」になってしまい、契約書の「真の実力」を発揮することができません。

契約書には、様々な類型がありますが、一般に、ビジネスの場で契約書を作成する目的として、次のようなことが挙げられます。

１．お互いに何をしないといけないか／何をしてはいけないかを明確にする目的
２．ビジネスにかかわる権利関係を明確にする目的
３．トラブルが起きた際における解決策を明確にする目的

契約当初の段階は契約条件の交渉をしやすい

契約当初の段階には、具体的な法的トラブルが発生していませんので、「将来トラブルが起きたときにどのように解決するか」について、お互いに契約条件の交渉を進めやすいです。

法的トラブルが現実に起きれば交渉が困難に

一方、いざ法的トラブルが起きてしまった後に、交渉によって解決しようとしても、かなりハードルが高いケースが多いです。法的トラブルが具体化しているために、お互いに有利な条件を固持し、利害が衝突してしまうからです。

３時のおやつ事例

ここで、次のような事例を考えてみましょう。

３時のおやつをいつも楽しみしている双子の太郎くんと二郎くん。でも、今日は、お母さんがおやつを買い忘れて、冷蔵庫にはプリンが１個だけ。
太郎くんは、二郎くんに「じゃんけんで買ったほうがプリンを食べることにしない？」と提案しました。

二郎くんは、もしかするとプリンを食べられないかもしれませんが、「悪い話ではないな」と、この提案に乗ってくる可能性が高いです。

どうしてもじゃんけんに勝ちたかった二郎くんは、「後出し」をしました。
太郎くんは、「後出しはずるい！後出しで勝っても、負けたのと同じだから、ぼくがプリンはもらう！」と主張しました。

二郎くんは、太郎くんの主張を受け入れるでしょうか。おそらく、二郎くんは、「そんなルールは聞いていない！」と反論して、２人はけんかになってしまうでしょう。

太郎くんは、二郎くんとのけんかを避けるために、どうすればよかったのでしょうか。それは・・・

じゃんけんをする前に、後出しじゃんけんで買ったら、「負けたのと同じ」ことにする。

という合意を、あらかじめ、太郎くんと二郎くんとの間で取り交わすことです。そうすれば、二郎くんも、後出しじゃんけんの不正をしなくなるでしょうし、万が一、後出しじゃんけんをしてしまえば、不正を認めるでしょう。

ビジネスの場でも同じことが

太郎くんと二郎くんのような問題は、ビジネスの場でもしばしば起こります。契約書において明記していなかったり、別途協議としか定めていなかった事項について法的トラブルが起きた場合に、収拾がつかない事態となるケースは、珍しくありません。

このような問題を避けるために、契約書を作り込む姿勢は、大変重要です。

２　ケーススタディ

さて、ここからは、ユーザー側からシステム開発契約書について、ベンダーの立場からどのようにレビュー（リーガルチェック）を進めればよいか、ケーススタディでご説明します。

ケース

１　株式会社チョットジムは、関西圏を中心に、３０拠点でトレーニングジムを営業しています。
２　これまで、スタッフの労務管理、各店舗の売上げ管理、顧客情報管理を、それぞれ別のシステムで行っていました。
３　ＤＸ施策の一環として、これらを統合して新機能を追加した新クラウドシステム「チョットジムＤＸ」の開発を企画しました。
４　従来のシステムになかった機能は、次のとおりです。
（１）顧客のマシン利用履歴を分析して統計データを生成する機能
（２）顧客がマイページでトレーニング履歴などを確認する機能
（３）他社の経理用クラウドシステムと連携させることができる機能
５　将来的には、他社に「チョットジムＤＸ」を販売する予定です。

契約締結に向けたミーティング（2024年1月）

ミーティングで、チョットジムから、次のような要望が伝えられました。

・2025年4月より、新システムの運用を開始したい
・2025年1月末日を納期とし、3月上旬までに運用テストを完了させたい
・システムの仕様については、協議しながら、2024年6月末日までに確定させたい
・報酬額は、2,200万円（消費税込）とする

その後、チョットジムから、システム開発契約書の案が提示されました。

システム開発委託契約書の内容

※こちらの契約書は、解説用に作成した簡易なものです。実際の取引でのご利用を想定したものではありません。

　株式会社チョットジム（以下「委託者」という。）と株式会社令和システム（以下「受託者」という。）とは、委託者が受託者に委託するシステム（以下「本件システム」という。）の開発（以下「本件業務」という。）につき、次のとおりシステム開発委託契約（以下「本契約」という。）を締結する。
第１条（業務内容）
委託者は、受託者に対し、本件業務を委託し、受託者はこれを受託する。
第２条（納期）
本件システムの納期は、2025年1月末日とする。
第３条（委託料）
委託者は、受託者に対し、本件業務の対価として、本件業務の検収完了後30日以内に、受託者の指定する金融機関口座に、金2,200万円を振込によって支払う。なお、振込手数料は委託者の負担とする。
第４条（再委託）
１　受託者は、委託者から事前の書面又は電磁的記録による承諾を得た場合に限り、本件業務の一部を第三者に再委託することができる。
２　前項の規定に基づいて本件業務の一部を第三者に再委託する場合、受託者は、本契約に基づいて委託者が負うものと同等の義務を第三者に課さなければならない。
３　前項の規定に基づいて本件業務の一部を第三者に再委託する場合、受託者は、第三者の行為について、一切の法的責任を負う。
第５条（仕様の確定）
受託者は、委託者と協議のうえで、2024年6月末日までに、委託者が提示する要件を満たすように、本件システムの仕様を確定しなければならない。
第６条（納品）
受託者は、委託者に対し、第2条（納期）に定める納期までに、本件システムを納品しなければならない。
第７条（検収）
委託者は、納品物を受領した後、当該納品物が仕様のとおりであることを検査し、その合否を受託者に通知する。受託者は、委託者から不合格の通知を受けた場合は、委託者の指示に従って、納品物が仕様に適合するように、無償で修正しなければならない。
第８条（契約不適合責任）
１　受託者は、納品物に契約不適合があった場合は、委託者の選択に従い、当該納品物の無償による修繕その他の方法による履行の追完、代金の減額その他の措置を講じなければならない。
２　前項の規定は、委託者から受託者に対する損害賠償請求及び解除権の行使を妨げない。
第９条（納品物の所有権及び知的財産権）
１　納品物の所有権は、納品と同時に、受託者から委託者に移転する。
２　納品物の著作権（著作権法第27条及び第28条の権利を含む。）、特許権、意匠権その他の知的財産権は、委託者に帰属する。受託者は、納品物について、著作者人格権を行使しない。
第１０条（秘密保持）
１　委託者及び受託者は、相手方から秘密であることを明示されたうえで開示を受けた秘密情報を、厳に管理し、本件業務の目的以外に使用し、又は、第三者（弁護士、税理士、公認会計士その他法令上守秘義務を負う者、及び、第４条（再委託）第１項に基づいて再委託をした第三者を除く。）に開示してはならない。ただし、秘密情報が次のいずれかに該当する場合は、この限りでない。
(1) 秘密保持義務を負わずにすでに保有している情報
(2) 秘密保持義務を負わずに第三者から正当に入手した情報
(3) 相手方から提供を受けた情報によらずに、独自に開発した情報
(4) 公知となった情報
２　前項の規定は、法令の規定に基づき、又は、権限のある官公署の求めにより秘密情報を開示する場合には、適用しない。
３　本条の規定は、本契約が終了した後３年間に限り存続する。
第１１条（解除）
１　委託者又は受託者は、相手方が本契約に違反し、相当期間を定めて催告しても是正されない場合、本契約を解除することができる。
２　委託者又は受託者は、相手方が本契約に違反し、その程度が重大である場合、催告をせずに、本契約を解除することができる。
３　前2項の規定は、損害賠償の請求を妨げない。
第１２条（損害賠償）
委託者及び受託者は、本契約の履行に関し、相手方の責めに帰すべき事由により損害を被った場合、相手方に対し、すべての損害（逸失利益に関する損害及び弁護士費用を含む。）の賠償を請求することができる。
第１３条（合意管轄）
本契約に関する訴えは、大阪地方裁判所を第一審の専属的合意管轄裁判所とする。

３　契約書レビューの進め方

さて、ケーススタディについて、ベンダーの立場から、契約書レビューをどのように進めていくか、ご説明します。
システム開発委託契約書をレビューする際に意識すべきポイントは、次の３つです。

・プロジェクトの特性を踏まえているか？
・トラブルが起きたときに自社を守れるか？
・自社の知的財産権やノウハウを守れるか？

４　プロジェクトの特性を踏まえているか１－要件定義・設計

（パッケージ）ソフトウェア販売契約と何が違う？

システム開発におけるプロジェクトの特性を考えるために、（パッケージ）ソフトウェア販売と比較してみましょう。システム開発には、ソフトウェア販売と比較して、大きく次のような特徴があります。

・納品物の仕様が契約時には確定していないケースが多い
・ユーザー側の協力がなければ進められない
・ユーザー側が途中で仕様変更を求めるケースが多い

仕様確定のためのプロセス

システム開発においてシステムの仕様が確定するまでの流れについて、代表的なウォーターフォールモデルに沿って説明します。契約当初の段階でシステムの仕様が決まっていない場合、まずは、ユーザーにおいて要件定義書を作成し、ベンダーに提示します。ベンダーは、要件定義書の内容に沿って、基本設計・詳細設計を進めて、ユーザーと協議しながらシステムの仕様を確定させます。

典型的な流れは以上のとおりですが、実際のプロジェクトにおいては、いったん要件定義書がユーザーから提出された後、ベンダーが設計を進めている段階で、要件定義の変更をユーザーが求めるケースも珍しくありません。要件定義の変更がある程度生じることはやむを得ませんが、このようなことが繰り返されれば、プロジェクトが大きく遅延してしまいます。

ユーザーとベンダーとの間で円滑な連携体制が維持できなければ、プロジェクトの進行が停滞し、最悪の場合、中途で頓挫してしまいます。システム開発委託契約書をレビューするうえでは、(1)このような問題の発生を予防するための条項が入っているか、(2)万が一問題が起きた際に自社のリスクを減らすための条項が入っているか、以上２点の検討が必要です。

ケーススタディの検討１－ユーザーの協力義務

システム開発においては、ユーザーとベンダーとの間で円滑な連携体制を維持することが重要です。そのためには、ユーザーにも、プロジェクトの進行上必要な協力をする義務があることを、契約書で明記することが適切です。

特に、ケースにおいては、次の点について、チョットジム（ユーザー）側の協力が不可欠です。

・チョットジムの従業員が感じている旧システムの問題点を整理し、新システムに求める仕様を明らかにすること
・マシン利用履歴分析機能や顧客向けマイページ機能に対して、チョットジムが求めるものを明らかにすること
・経理用クラウドシステムとの連携について、どの範囲でデータを共有し、どのように業務で活用するかを明らかにすること

このような視点で、チョットジム（ユーザー）側が提示した契約書の問題点を考えてみましょう。

修正前の条項

第５条（仕様の確定）
受託者は、委託者と協議のうえで、2024年6月末日までに、委託者が提示する要件を満たすように、本件システムの仕様を確定しなければならない。

仕様を確定するためには、ユーザー側の協力が不可欠です。それにもかかわらず、仕様確定までの期限が明確に定められており、たとえユーザー都合でプロジェクトの進行が遅延しても、ベンダーが責任を問われかねない条項になっています。

このような問題を解消するためには、要件定義段階でユーザーに求められる協力義務を明確にして、ユーザーの非協力によって仕様を確定させることができない場合に、ベンダーが不利益ないし法的責任を負わないようにしておくことが重要です。また、ユーザーからの要求によってプロジェクトが後退しないようにしておくことも重要です。

簡易な修正例

第５条（仕様の確定）
１　委託者は、別紙に定めるスケジュールに従い、受託者の専門的な支援を受けながら、2024年※月※日までに、本件システムが満たすべき要件をとりまとめた文書（以下「要件定義書」という。）を策定し、受託者に提示しなければならない。
２　受託者は、委託者から要件定義書の提示を受けた日から※日以内に、当該要件定義書に基づき、本件システムの仕様を確定しなければならない。
３　委託者は、要件定義書を受託者に提示した後、やむを得ずその内容を変更しなければならない事情が生じた場合は、受託者に対し、その内容の変更を申し入れることができる。この場合において、委託者と受託者とは、協議のうえ、要件定義書の変更、並びに、それに伴う仕様書の確定期限（前項に定める期限をいう。）及び納期の変更を決定する。
４　委託者は、前項に定めるところにより要件定義書の変更を申し入れる場合においては、それによって本件業務の遂行を遅延させることがないように、留意しなければならない。

［第１項］
要件定義の確定が、主としてユーザーの担うべき役割であることを明確化しました。また、要件定義書の作成期限を明確にすることで、ユーザー事情によりプロジェクトが遅延することを防ぎやすくしました。
［第２項］
要件定義の確定があって、初めて、仕様の確定を進められることを考慮した内容に修正しました。これにより、ユーザー事情によりプロジェクトが遅延しても、ベンダーが責任を転嫁されないようにしました。
［第３項］
要件定義を提示した後の内容変更について、プロセスや要件を明確化しました。これにより、ユーザーがやみくもにプロジェクトを後退させることを防ぎやすくしました。
［第４項］
要件定義の変更が繰り返されて、プロジェクトが遅延することを抑止するための規定を入れました。

ケーススタディの検討２－仕様の確定

ユーザー側が要件定義書において求める内容について、ベンダー側から見れば、次のような事情で実現困難なことがあります。

・そもそも技術的に実現が難しい
・予算に照らしてコストが過大になる
・納期に照らして開発工数が過大になる
・情報セキュリティ上の脆弱性や動作不良の発生リスクなど、専門家の立場から採用できない

このような視点で、チョットジム（ユーザー）側が提示した契約書の問題点を考えてみましょう。

修正前の条項

第５条（仕様の確定）
受託者は、委託者と協議のうえで、2024年6月末日までに、委託者が提示する要件を満たすように、本件システムの仕様を確定しなければならない。

ユーザーが提示する要件は、例外なく仕様に反映しなければならない条項になっています。これでは、ベンダー側から見て実現困難な仕様を盛り込まなかったことについて、ユーザーから責任追及を受けるおそれがあります。

簡易な修正例

第５条（仕様の確定）
・・・
５　受託者は、要件定義書の内容に沿って、本件システムの仕様を検討する。ただし、要件定義書において示される内容のうち、次の各号のいずれかに該当するものについては、委託者と協議したうえで、本件システムの仕様に反映しないことがある。
（１）実現が技術的に困難であり、又は、委託料と比較して過大な費用を要し、若しくは納期に照らして開発工数が過大となりうるもの
（２）その他、専門的な知見に照らして、実現することが不相当であると判断したもの（本件システムの動作不安定、情報セキュリティ上のリスク等が例示されるが、これらに限られない。）

ベンダー側の立場から仕様に反映することができないケースを明示し、トラブルの発生を回避しています。

ケーススタディの検討３－資料等の提供

システムの仕様を検討するうえでは、既存システムや連携予定のシステムの仕様について、資料が必要です。また、既存システムを改変して新システムに流用する場合には、旧ベンダーとユーザーとの契約において、改変に制限がないかを確認する必要があります。

これらの資料等がベンダーに提供されなければ、プロジェクトを進行することができません。そこで、次のような条項の追加を求めることが適当です。

簡易な修正例

第※条（資料等の開示）
１　受託者は、委託者に対し、要件定義書の策定支援又は本件システムの仕様の検討のために必要な範囲において、資料等（既存のシステムの仕様に係る資料等、本件システムとの連携を予定しているシステムの仕様に係る資料等、これらのシステムの使用条件に係る資料等をいうが、これらに限られない。）の開示を求めることができる。この場合において、委託者は、受託者に開示することができない正当な理由があるときを除き、当該資料を受託者に遅滞なく開示しなければならない。
２　受託者は、委託者が前項の資料を遅滞なく開示しなかったことによって本件業務を予定どおり進行することができなかった場合であっても、一切の法的責任を負わない。

ユーザーに対して必要な資料の提供を義務づけるとともに、ユーザー側の事情でベンダーがプロジェクトを進行することができなくても法的責任を負わないようにしました。

ケーススタディの検討４－窓口の明確化

このケースでは、労務管理・売上げ管理・顧客管理を統合するために、ユーザー側の各部門から要望が出ることが想定されます。ユーザー側の各部門から要望を受け付けなければならない場合とりまとめに疲弊してしまいます。そのような問題を防ぐためには、ユーザー側の窓口を一本化して、責任者を明確化することが求められます。

簡易な修正例

第※条（責任者）
１　委託者及び受託者は、それぞれ本件業務に係る責任者を選任し、本契約の締結後、速やかに、当該責任者の氏名及び連絡先を、相手方に通知しなければならない。
２　委託者の責任者は、要件定義書の策定、受託者が作成した仕様書の確認、納品物の受領及び検収その他本件業務における委託者の一切の行為につき、権限及び責任を有する。委託者は、このような権限及び責任を有する者として適当な役員又は従業員を、責任者として選任しなければならない。
３　委託者及び受託者は、責任者を変更する場合は、あらかじめ、相手方に通知しなければならない。

責任者の立場を明確にして、窓口の分散を防ぐように工夫しました。

ケーススタディの検討５－報酬の定め方

ユーザー側の非協力で、プロジェクトが仕様確定前に頓挫してしまうことも想定されます。そのような場合に、報酬の支払を受けられない事態に発展しないよう、報酬の発生時期を細分化しておくことが望ましいです。また、プロジェクトの中途終了時における報酬の処理を明確にしておくことも、重要です。

簡易な修正例

第３条（委託料）
１　委託者は、受託者に対し、本件業務の委託料として、次の各号に定める期限までに、それぞれ当該各号に定める額の報酬を支払う。なお、振込手数料は、委託者の負担とする。
（１）本契約を締結した時　　　　　　　　　　　　　　　　　　　　　　※※円（消費税込）
（２）第５条第１項に定める要件定義書の策定支援が完了した時　　　　　※※円（消費税込）
（３）本件業務の仕様が確定した時　　　　　　　　　　　　　　　　　　※※円（消費税込）
（４）納品物の検収が完了した時　　　　　　　　　　　　　　　　　　　※※円（消費税込）
２　納品物の検収が完了する前に本契約が中途で終了した場合においては、委託者は、当該終了日から※日を経過する日までに、受託者が本件業務を履行した割合に応じて、前項に定める委託料の一部を支払わなければならない。

［第１項］
それぞれの段階での報酬請求を認めることで、プロジェクトの中途終了によって生じるリスクを緩和しました。
［第２項］
プロジェクトが中途終了した場合における処理を明確にして、トラブルが生じるリスクを低減しています。

５　プロジェクトの特性を踏まえているか２－コーディング・納品

コーディングから納品までのプロセス

コーディングから納品までのプロセスでは、例えば、次のような問題が生じえます。

・途中で仕様変更を余儀なくされて、スケジュールの遅延やコストの増加が発生する問題
・コーディングの過程で当初の想定よりも工数が大幅に増えて、スケジュールの遅延が発生する問題
・人員不足、災害、感染症のまん延などによって、スケジュールの遅延が発生する問題

このような様々な理由によってスケジュールが遅延しうることを想定して、契約条項を検討する必要があります。

簡易な修正例１－仕様の変更

第※条（仕様の変更）
１　委託者又は受託者は、第５条に定めるところにより本件システムの仕様を確定した後に、その仕様を変更しなければならない事情が生じた場合は、相手方に、変更の理由及び変更後の仕様を明示したうえで、書面又は電磁的記録によって変更の提案をすることができる。ただし、当該提案においては、本件業務の遂行を不当に遅延させることがないように、留意しなければならない。
２　委託者及び受託者は、前項の提案があった際には、速やかに協議のうえ、仕様の変更の可否について決定する。この場合において、仕様の変更を可とする場合は、その旨及び変更後の仕様を明示した仕様変更書を書面又は電磁的記録で作成し、双方がその内容を承認することで、仕様の変更が確定する。
３　前項の場合において、仕様の変更によって本件業務の遂行に要する期間が当初の想定よりも長くなり、又は、その費用が増加した場合は、その程度に応じて、納期の延長又は委託料の増額についてもあわせて検討し、仕様変更書に変更後の納期又は委託料を明示しなければならない。

［第１項・第２項］
進行状況によって当初予定していた仕様を見直すべき必要が生じうることを踏まえて、柔軟に仕様を変更できるようにしました。ただし、口頭のやりとりで仕様変更が繰り返されないように、プロセスを明確化しました。
［第３項］
ユーザー側の仕様変更に応じる場合に、委託料の増額や納期の延長などを求めやすくしました。

簡易な修正例２－納期の変更

第※条（納期の変更）
１　受託者は、本件業務の進捗状況に照らして、納期までに納品物を完成させることが困難となるおそれが生じた場合は、速やかに、委託者に対してその理由を示したうえで、納期の変更を求める。
２　前項の場合において、委託者は、速やかに受託者との協議に応じ、納期の変更の可否について決定する。この場合において、納期の変更を可とする場合は、その旨及び変更後の納期を明示した納期変更書を書面又は電磁的記録で作成し、双方がその内容を承認することで、納期の変更が確定する。

プロジェクトの進行により、ベンダー側から納期の変更を求めやすいように、プロセスを明確化する条項です。単に、ベンダー側の都合で一方的に納期を変更可とする条項では、ユーザー側から拒絶される可能性が高いため、妥協案として、このような条項を提案することが、双方納得しやすいように思います。

納品から検収完了までのプロセス

ユーザーから検収を先延ばしにされたり、繰り返し修正対応を求められたりすることで、プロジェクトの遅延や、想定外の負担が発生するリスクがあります。このようなリスクを解消するためのポイントは、大きく３つです。

・検収基準の明確化
・検収期日を過ぎた場合におけるみなし検収規定の明示
・検収不合格の場合に「具体的な理由」を明示すべき義務の明示

簡易な修正例

第７条（検収）
１　委託者は、納品物を受領した後、３０日以内に、当該納品物が、第５条に定めるところにより確定した仕様のとおりであることを検査し、その合否を受託者に通知する。
２　委託者は、前項の検査の結果、不合格の通知をする場合は、その具体的な理由を明示した書面又は電磁的記録を受託者に交付しなければならない。
３　受託者は、前項に定めるところにより委託者から不合格の通知を受けた場合は、委託者と協議して定めた合理的な期間内に、納品物が仕様に適合するように、無償で修正しなければならない。
４　委託者が、第１項の期限までに検査の結果を通知しない場合は、受託者に対して合格の通知をしたものとみなす。

［第１項］
検収基準や検収期日を明確にして、ユーザーから検収を先延ばしにされたり、繰り返し修正対応を求められたりすることを防いでいます。
［第２項・第３項］
ユーザーが不合格通知をする場合に具体的な理由を示すことを義務づけて、ユーザーが不用意に修正対応をしないようにしています。
［第４項］
ユーザーが、不当に検収を先延ばしにできないようにしました。

まとめ

システム開発のプロジェクトは千差万別ですので、「万能なひな形」はありません。プロジェクトの特性を踏まえて、契約条項を創意工夫する必要があります。

６　トラブルから自社を守れるか？

システム開発においては、プロジェクトの進行、納品物、情報管理などをめぐって、ユーザー・ベンダー間でトラブルが発生することが多々あります。ここでは、納品物をめぐるトラブルについて、契約条項の工夫によって回避する方法をご紹介します。

他システム連携時における不具合の発生

ユーザーからベンダーに対してしばしば求められるのが、他システムの連携に伴って発生した不具合に対する修正対応です。ベンダーの立場であれば、このような修正について無償対応を求められることは納得しづらいですが、ユーザーはそのように考えません。お互いの認識のズレは、紛争を招く要因となります。

修正前の条項

第８条（契約不適合責任）
１　受託者は、納品物に契約不適合があった場合は、委託者の選択に従い、当該納品物の無償による修繕その他の方法による履行の追完、代金の減額その他の措置を講じなければならない。・・・

修正前の条項は、契約不適合の範囲が不明瞭なため、他システムの連携に伴う問題が契約不適合の範囲かどうかを巡り、紛争になるおそれがあります。

簡易な修正例１

第８条（契約不適合責任）
１　受託者は、納品物に契約不適合（第５条に定めるところにより確定した仕様を満たさないことをいう。ただし、次の各号のいずれかに該当する不具合があることを除く。）・・・。
（１）本件システムと他のシステムとの連携に伴って生じる不具合であって、本件システムの設計又はプログラムの誤りに起因しないもの
（２）本件システムを動作させる機器にインストールしたオペレーティング・システム、ファームウェア、アプリケーションその他のソフトウェアのアップデートによって生じた不具合・・・

契約不適合に含まれるかどうかをめぐってユーザー・ベンダー間でトラブルになりそうな問題について、契約不適合の範囲外であることを明確にして、トラブルの発生を防ぐ修正例です。

その他、契約不適合責任については、民法改正によって、ユーザーが「不具合を知ってから１年間」にわたって主張できるようになりました。ベンダーの立場からは、長期間にわたって無償修正を対応させられるリスクを回避するために、次のような修正を求めることが望ましいです。

簡易な修正例２

第８条（契約不適合責任）
・・・
３　民法の規定にかかわらず、委託者は、検収完了日から１年以内に限り、納品物に契約不適合があったことを理由に、修正その他の追完、委託料の減額若しくは損害賠償の請求、又は、本契約の解除をすることができる。

情報漏えい等をめぐる問題

システムの脆弱性に起因して情報漏えいやランサムウェア被害等のインシデントが発生した場合、ベンダーがユーザーから多額の損害賠償請求を受けることがあります。契約条項をレビューする際には、情報漏えい等の事故が発生した場合にベンダーが過大な責任を負う内容になっていないか、チェックすることも重要です。

修正前の条項

第１２条（損害賠償）
委託者及び受託者は、本契約の履行に関し、相手方の責めに帰すべき事由により損害を被った場合、相手方に対し、すべての損害（逸失利益に関する損害及び弁護士費用を含む。）の賠償を請求することができる。

修正前の条項であれば、逸失利益も無限定で損害賠償の対象になります。例えば、情報漏えいによってシステムを停止しなければならない期間の営業損害等も、損害賠償の対象となります。結果、ベンダーがおよそ許容しづらいような、多額の損害賠償を請求されるおそれがあります。

修正例

第１２条（損害賠償）
委託者及び受託者は、本契約の履行に関し、相手方の責めに帰すべき事由により損害を被った場合、相手方に対し、通常生ずべき損害（委託料の総額を上限とする。）の賠償を請求することができる。
第※条（情報セキュリティ対策）
１　受託者は、本件システムについて、本契約の締結当時の水準に照らして一般に講じられる合理的な情報セキュリティ対策を講じる。
２　受託者は、前項の義務を履行したにもかかわらず、本件システムが情報セキュリティ上の脅威によって被害を受けた場合において、損害賠償その他の法的責任を負わない。

まず、損害賠償責任の範囲を限定することで、ベンダーが許容しづらいレベルの過大な損害賠償責任をユーザーから追及されるリスクを回避しました。もし、ユーザーから、このような修正に対して反論を受けた場合には、損害賠償責任の範囲を広げることで、委託料の増額を求めざるを得なくなることを、丁寧に説明してください。
また、情報セキュリティ対策については、修正例のように、保証する水準を明瞭にしておくことが望ましいです。

知的財産権の侵害をめぐる問題

ベンダーがシステム上で実装した機能が、特許権や意匠権を侵害していることが事後に発覚し、法的責任の所在が問題になるケースがあります。ベンダーとしては、過大なリスクを負わないように、知的財産権の侵害をめぐる責任の範囲を契約上限定するように求めることが望ましいです。もし、ユーザーから、このような修正に対して反論を受けた場合には、責任の範囲を広げることで委託料の増額を求めざるを得なくなることを、丁寧に説明してください。

修正例

第※条（知的財産権侵害の責任）
［例１］
受託者は、納品物に関し、受託者が把握する限りにおいて、特許権、意匠権、著作権その他の知的財産権を侵害するものではないことを保証する。
［例２］
受託者は、納品物に関し、受託者が容易に調査することができる範囲において、特許権、意匠権、著作権その他の知的財産権を侵害するものではないことを保証する。

７　自社の知財・ノウハウを守れるか？

著作権、特許権、意匠権などの知的財産権やノウハウの帰属についても、自社のビジネスチャンスを失わないために留意が必要です。

著作権の帰属

まず、著作権に関わる問題について、ケースを例に考えます。

１　本件システムを他社に販売することについて、一切のライセンス料を受け取らないことに問題はないか？
・・・ベンダーとして新機能の開発に一定の貢献をしている以上、一定のライセンス料を受け取ることがフェアです。
２　他の開発案件に流用可能なプログラムの著作権を、ユーザー側に譲渡してもよいか？
・・・著作権を譲渡せずに自社に留保しておかなければ、今後のビジネスにおいて支障になってしまいます。
３　納品物の中に、第三者が著作権を有するプログラムその他のコンテンツは含まれていないか？
・・・第三者が著作権を有するコンテンツまで著作権を譲渡してしまえば、その第三者との間でトラブルになります。

修正前の条項

第９条（納品物の所有権及び知的財産権）
１　納品物の所有権は、納品と同時に、受託者から委託者に移転する。
２　納品物の著作権（著作権法第27条及び第28条の権利を含む。）、特許権、意匠権その他の知的財産権は、委託者に帰属する。受託者は、納品物について、著作者人格権を行使しない。

修正前の条項は、上に挙げた問題点を生じさせるものです。修正例を、いくつかご説明します。

簡易な修正例１－原則として著作権を譲渡する場合

第９条（納品物の所有権及び知的財産権）
１　納品物の所有権は、納品と同時に、受託者から委託者に移転する。
２　納品物の著作権（著作権法第27条及び第28条の権利を含む。）は、受託者が本件業務の開始以前から保有していた著作権、第三者が保有する著作権、及び、汎用的な利用が可能なプログラムの著作権を除き、委託料の全額が支払われた時点で、受託者から委託者に移転する。
３　委託者は、前項の規定に基づき受託者に留保された著作権の対象となる著作物を、本件システムを自社で使用し、又は、第三者に販売して利用させる目的のために、複製し、又は、翻案することができる。

［第２項］
著作権の譲渡する範囲を制限することで、上に挙げた問題が生じないようにしています。
［第３項］
著作権の譲渡する範囲を制限したことと引き換えに、ユーザーが通常の業務でシステムを利用する際に支障が生じないようにしています。

簡易な修正例２－原則として著作権を譲渡しない場合

第９条（納品物の所有権及び知的財産権）
１　納品物の所有権は、納品と同時に、受託者から委託者に移転する。
２　納品物の著作権（著作権法第27条及び第28条の権利を含む。）は、受託者に帰属する。
３　受託者は、委託者が本件システムを自社で使用し、又は、自社で使用する目的で改変する場合において、著作権を行使しない。
４　委託者は、受託者と協議したうえで、委託者と受託者との間で合意した条件のもとで、本件システムを第三者に使用させることができる。この場合において、委託者は、受託者に対し、相当額の対価を支払うものとし、当該対価の額又は計算方法については、委託者と受託者との協議によって定める。

［第２項］
著作権について、原則としてベンダーに帰属するようにしています。
［第３項］
著作権をベンダー帰属とすることに対してユーザーから反論を受けないように、ユーザーが通常の業務で使用するうえで制約が生じないようにしています。
［第４項］
ユーザーが第三者にシステムを販売する際に、ライセンス料の交渉ができるようにしています。

簡易な修正例３－他社販売のライセンス料を明示する場合

第９条（納品物の所有権及び知的財産権）
１　納品物の所有権は、納品と同時に、受託者から委託者に移転する。
２　納品物の著作権（著作権法第27条及び第28条の権利を含む。）は、受託者に帰属する。
３　受託者は、委託者が本件システムを自社で使用し、又は、自社で使用する目的で改変する場合において、著作権を行使しない。
４　委託者は、受託者に対して第5項に定めるライセンス料を支払うことを条件に、本件システムを第三者に使用（本件システムの改変を伴う行為は除く。）させることができる。
５　〔ライセンス料の計算方法について規定〕

［第４項・第５項］
「簡易な修正例２」をベースに、ライセンス料についてあらかじめ条件を明示するパターンです。

特許権・意匠権の帰属

システム開発においても、これまで世の中になかった新しい機能を実装する場合は、特許権が問題になります。また、斬新なデザインを発案した場合には、意匠権が問題になります。システムの企画において、ベンダーが積極的にアイデアを出して貢献したのであれば、特許権・意匠権についても、それに見合った権利を主張することがフェアです。

修正前の条項

第９条（納品物の所有権及び知的財産権）
１　納品物の所有権は、納品と同時に、受託者から委託者に移転する。
２　納品物の著作権（著作権法第27条及び第28条の権利を含む。）、特許権、意匠権その他の知的財産権は、委託者に帰属する。受託者は、納品物について、著作者人格権を行使しない。

簡易な修正例

第※条（特許権等）
特許権、実用新案権及び意匠権（特許、実用新案登録及び意匠登録を受ける権利を含む。）のうち、本件業務の遂行過程で生じた発明、考案及び意匠に係るもの（以下、総称して「特許権等」という。）は、すべて委託者と受託者との共有とし、その共有持分は、双方の貢献度に応じて委託者と受託者との協議によって定める。

こちらは、簡易な条項例です。ユーザー・ベンダー間で特許権等の帰属について具体的な意見がまとまっていないことを想定して、「共有持分は、双方の貢献度に応じて委託者と受託者との協議によって定める」としました。もちろん、すでにユーザー・ベンダー間で意見が一致していることがあれば、確実に契約条項に落とし込むことが重要です。

８　まとめ

システム開発契約書は、「ひな形探し」ではなく、「オーダーメイド」を目指すべきものです。ユーザーが納得できる水準を見極めながら、それぞれの契約条項について創意工夫を重ねることで、「法律トラブルに強いシステム開発契約書」を完成させることができます。

システム開発契約書の作成やレビューについてお困りの際は、ぜひ当事務所にご相談ください。また、システム開発紛争についての交渉・訴訟案件も承ることができます。

初めてのご相談者様は、弁護士との無料相談（６０分）をご利用いただけます。ぜひ、お気軽にお問い合わせください。