「新しいソフトウェア開発委託モデル契約書」における主要条項の策定趣旨について
平成15年5月
(社)情報サービス産業協会
平成14年度 法的問題委員会企画部会
ソフトウェア取引検討ワーキンググループ
「新しいソフトウェア開発委託モデル契約書」における主要条項の策定趣旨について
再委託、権利帰属、第三者ソフト・フリーソフト、保証と賠償、セキュリティ、ユーザの責任
JISAでは、平成14年5月に、今日のソフトウェア開発委託取引における問題点を整理し、論点とこれに対するJISAとしての考え方を「JISAポジションペーパー」として公表した。また、これをもとに、新しいソフトウェア開発委託モデル契約書とその逐条解説を作成し公表した。
この新しいモデル契約書は、Web対応・分散処理型ソフトウェアを対象としたものであり、他に類のないものであることから、公表以来、各方面から様々な関心（意見や質問等）が寄せられている。
そこで、これらの意見や質問等に回答することにより、新しいモデル契約書における主要条項の策定趣旨を正確に理解していただくことが、今日のソフトウェア開発委託取引をより円滑化する上で重要であると考え、本ワーキンググループにおいて検討を行った結果を取りまとめ、公表するものである。なお、表記基準及び関連公表資料については、本文の末尾に記している。
再委託
１．ベンダが再委託をする場合、ユーザの事前の承諾を得る必要性があるか（第18条第1項関連）
近年、開発形態がシステムインテグレーション的になり、ベンダにはプロジェクトの企画・管理力や幅広い技術などが求められている。一方では、開発期間の短期化や開発代金の低価格化などと相俟って、ソフトウェア開発に求められる幅広い専門技術全てをベンダが保有することは極めて困難なため、これらを補完するために様々な専門業者に対して再委託することが不可避となっている。このため、本モデル契約書第18条では、ベンダは、再委託先の行為に全責任を負うことを条件としてユーザの承諾なしに再委託ができるようにしている。
しかし、近時の再委託先による情報漏洩などのセキュリティ事故の増加などにより、ユーザが自己の情報の取扱いに対して不安を抱くことがある。このような不安を少しでも解消するために、ベンダが再委託をする場合には、事前承諾を得るように、ユーザに要望することが多い。
確かに、再委託により秘密情報などがいったん外部に漏洩してしまうと取り返しのつかない事態になるという不安をユーザが抱いていることをベンダは十分認識している。
しかし、ベンダとしては、ベンダが最適候補として選んだ再委託先である専門業者についてユーザの事前承諾が得られない場合には、ベンダが仕様書通りにソフトウェアを開発することが困難な事態や再委託先の再選定などの問題が生じ、開発が遅延することになりかねない。また、ユーザの承諾を得たからといってベンダが責任を軽減されるわけではない。
従って、ベンダが全責任を負う以上、ユーザの承諾まで得る必要はないと考える。もちろん、ベンダは、ユーザからの要請があった場合には再委託先名等必要事項を通知すべきであろう。
２．ベンダが再委託をする場合、再委託先の選定と管理は直接的にベンダが行うべきか（第18条第1項関連）
本モデル契約書では、ベンダが秘密保持義務を負っている情報についてベンダと同等の秘密保持義務を再委託先に課し、再委託先の再委託業務遂行について全責任を負うことになっている。しかし、実際にどのように再委託先の管理をしているのか、契約書に規定された通りの秘密保持義務が守られているのか等について不安を抱くユーザも多い。
このようなユーザの不安を解消すべく、ベンダとしてはまず再委託先の選定において十分な注意を払うべきである。再委託先において適切な情報管理が行われていることを示す客観的な選定基準として、具体的には、プライバシーマーク、ISOやISMSなどの公的認証を取得していることが挙げられる。更に、再委託先の社内で適切なセキュリティ対策を講じていることなども基準となるが、この場合には、実際に、再委託先においてその基準に則った運用がなされているかについて確認することが必要である。
そして、ベンダが秘密保持義務を負っている情報に係る作業は、できる限り再委託しないようにすべきであるが、再委託する場合には、秘密情報を適切に管理するためにベンダが再委託先に対し直接的な指示や監督を行うべきである。再委託先の従業員がベンダの事業所内で作業をするような場合には、秘密情報の漏洩防止のために誓約書を入手し、使用する機器の持ち込みや持ち出しを禁止するなどの適切なセキュリティ措置が必要である。
３．再委託先がユーザの指示に従わないようにする義務規定を設けなかったのはなぜか（第18条2項関連）
ベンダは、再委託先の行為については全責任を負うが、ユーザが直接再委託先に指示したことについてはベンダは責任を負えない。再委託先はベンダが管理監督しているものであり、ユーザから直接指示を与えてしまうとベンダの管理監督が及ばず、委託業務（ソフトウェア作成業務）全体の工程管理に支障をきたすばかりか、システム仕様書で定められた通りのソフトウェアの完成が望めなくなる。このため、ユーザは再委託先に直接指示をしてはいけない旨を規定する第18条第2項が設けられた。
従って、ユーザが第18条第2項に違反しなければ再委託先はユーザの指示に従うことはありえないので、あえて再委託先に対してユーザの指示に従わないようにする義務を課す必要はない。また、再委託先もベンダ以外の者の指示に従ってはいけないことは当然であるため、本モデル契約書では再委託先にこのような義務を課す条項を設けていない。
権利帰属
１．ユーザに開発成果のプログラムの著作権を移転させるべきか（第30条第1項関連）
ユーザから｢委託料を支払っているのであるから、ベンダが新規開発したプログラム部分についてだけでも、その著作権をユーザに移転すべきである｣という要求がなされることが多い。このことは、ユーザがプログラムの著作権（特に、複製権と改変権）を有していないと、将来のシステム変更に伴う改変等に支障をきたすのではないかという不安に起因したものといえよう。
一般的なソフトウェア開発委託取引においては、ユーザはソフトウェアの開発費用に応じて設定された委託料を支払い、プログラム等の納入物(プログラムの複製物や各種ドキュメント等)の引渡しを受けることになる。この場合、納入物(プログラムの複製物等)の所有権は、契約上明記されていなくても当事者の暗黙の合意により移転すると解されるが、本モデル契約書では、第29条で納入物（この中には､もちろん､プログラムの複製物も含まれている。）の所有権の移転を明示的に規定している。
また、プログラム(複製物)の所有者は、著作権法第47条の2によって｢そのプログラムを自ら利用するために必要な限度内で、複製･翻案(改変)することができる｣ので、本モデル契約書第30条1項但書にも、その旨を規定している。
このように、ユーザがプログラムの複製物の所有者としての権利を有するならば、ユーザは自己使用の範囲内で必要なプログラムの複製･改変ができるので、この不安は解消する。
もっとも、ソフトウェア開発行為により新規に作成されたプログラム(新規開発部分)の著作権は、原則として当該開発行為によりベンダが原始取得するが、著作権法第61条に基づき、ユーザへの著作権譲渡は可能である。ただし、これは次に掲げる取引･開発の実態上の問題を解決することが前提となっている。
| 1. | ソフトウェア開発委託対価の設定は一般的にコスト･ベイスド方式が採られているが、新規開発部分に関する著作権の対価が委託料に含まれていないのが通常(取引慣行)であること。 |
| 2. | 開発したプログラムの新規開発部分を他のプログラム（第三者ソフトが権利を有するコンテンツや技術ノウハウ等を含む。）と切り分けられるかという実態上の問題があること。 |
これらのことを踏まえた上で検討すると、本モデル契約書で開発対象としたソフトウェアは、Web対応･分散処理型ソフトウェアであるから、この開発には、一般的に様々な第三者ソフトが数多く利用（カスタマイズを含む。）されるのが通常であり、かつ、新規開発部分といえども第三者のコンテンツや技術ノウハウ等が取り込まれる場合が多いことがその特徴として挙げられる。このため、新規開発部分を第三者ソフトから切り分けることが難しいばかりか、仮に切り分けられたとしても、新規開発部分に第三者の権利（コンテンツや技術ノウハウ等）が少しでも含まれるようであれば、ユーザは当該ソフトウェアを自由に改変等することができない。従って、改変等ができるようにするためには、当該第三者と交渉して権利処理を行う必要があるから、当該ソフトウェアの一部分（新規開発部分）のプログラムの著作権だけをユーザに移転しても有効ではない。
そして、新規開発部分（著作権のみならず、その技術ノウハウ等を含む。）のうち以後のソフトウェア開発に再利用できるものについては、ベンダに著作権を留保させ、その再利用を促進する方がソフトウェア開発技術の向上や開発コストの低減が図れ、最終的には社会全体の利益となって還元されることになる。
もちろん、上記の第三者ソフト等を含まず、かつ、再利用に適さないソフトウェアについては、の譲渡対価問題をクリアできれば「新規開発部分の著作権を移転する」と契約上で取り決めることは可能である。
２．ベンダに著作権が留保されると、ベンダは同一のソフトウェアを開発･転売することができ、その結果、それに含まれたユーザの業務ノウハウ等情報がユーザの競合会社等第三者に提供されてしまうのではないか（第30条第1項関連、第24条から第27条関連）
ベンダにソフトウェアの著作権を留保させると、著作権法上、ベンダが当該ソフトウェアを自由に複製して第三者に転売することができる。その結果、ユーザの業務ノウハウ等情報が当該ソフトウェアに含まれている場合、その情報がユーザの競合会社等第三者に提供されることによって、ユーザが不測の損害（不利益）を被るかもしれないという問題が指摘されている。この問題は、権利帰属の問題というよりもむしろユーザの秘密情報の管理上の問題といえる。
そこで、本モデル契約書では、このような問題をあらかじめ想定した上で、第24条(資料等の提供及び返還)から第27条(個人情報の取扱い)までの規定によって、ベンダに対して厳格な情報管理の義務を課している。
ベンダが本モデル契約書を遵守してソフトウェア開発を行うならば、厳格な情報管理が実現できることから、ベンダがユーザの業務ノウハウ等の秘密情報をそのままの形で当該ソフトウェアの中に取り込む可能性は少ない。
仮に、このような情報がソフトウェアに取り込まれる場合があったとしても、その情報を含んだルーチン･モジュール等は限定されるので特定することが容易であり、かつ、当該ルーチン・モジュール等の機能もユーザに特化したものであるので、そのままでは他のソフトウェア開発に再利用することはできない。
更に、万一、そのルーチン･モジュール等が再利用可能であり、これを他のユーザ（ユーザの競合会社等第三者）のソフトウェア開発に再利用する場合でも、ユーザ固有の情報を削除して他のユーザ固有の情報に置き換えるなどの手直しが不可避である。従って、ユーザの業務ノウハウ等の情報が、その後、他のユーザ用に開発されたソフトウェアに含まれることにより、他のユーザに開示･提供される可能性は事実上なくなることになる。
ベンダが以上の措置をとらず、万一、ベンダが秘密保持義務を負っている情報が含まれたソフトウェアを転売等により第三者に提供･開示し、その結果、ユーザが損害を被れば、本モデル契約書第38条によりベンダは損害賠償責任を負うのは当然である。
本モデル契約書では、ベンダが当該ソフトウェアと類似のソフトウェアを開発し、ユーザの競合会社等第三者に対して提供することを禁止したものではない。しかしながら、本モデル契約書では、開発実態に合わせた情報管理上の措置を講ずることがベンダに求められていることから、ソフトウェアに含まれたユーザの業務ノウハウ等の情報がユーザの競合会社等第三者に提供されるなどの不利益をユーザが被ることを回避することができるように定められている。
３．ユーザに不利益とならぬように、ベンダが著作者人格権を行使しないように規定しなかったのはなぜか（第30条関連）
著作権法第59条は、｢著作者人格権は、著作者の一身に専属し、譲渡することができない。｣と規定している。そこで、ベンダがユーザに対して開発したソフトウェアの著作権譲渡を行う場合であっても、著作者人格権まで併せて譲渡できないことになる。このため、著作権譲渡を約定する場合においては、著作権者が相手方(著作権譲受人)の意に反する形で著作者人格権を行使すると相手方の不利益になることが予想されるので、この事態を回避するため当該契約書に｢著作者人格権不行使条項｣を盛り込むことが通例となっている。
しかし、本モデル契約書第30条では、ユーザにプログラムの著作権は移転せず、ベンダに留保されることになっている。そこで、同じソフトウェアについての著作権と著作者人格権とが衝突する形で行使される事態は生じ得ないので、｢著作者人格権不行使条項｣を盛り込む必要はない。
なお、ソフトウェア開発委託契約は、その特性上､当事者(ユーザ･ベンダ)の強固な信頼関係を前提にしていることから、ベンダには、信義則に則った著作権行使をすることが求められる。このことは、ベンダが著作者人格権を行使する場合においても同様であることから、本モデル契約書のようにベンダに著作権が留保されている契約においては、｢著作者人格権不行使条項｣を盛り込む必要はないと考えられるが、規定しても差し支えない。
第三者ソフト・フリーソフト
１．ベンダが第三者ソフトやフリーソフトの利用をユーザに提示した場合、その利用に関する責任をベンダが負うべきではないか（第19条第1項、第20条第1項関連）
第三者ソフトは従来型の開発でも利用されていたが、フリーソフトについてもJISAポジションペーパーで述べている通り、Web対応・分散型ソフトウェアの開発では今やその利用は避けて通れないほど一般的になっている。従って、ベンダがシステム提案書によりフリーソフトを開発に利用する提案をすることは珍しいことではない。
しかしながら、本モデル契約書が想定している取引のプロセスを見ると、ベンダが提出するシステム提案書は、あくまでユーザの概念的な要求（本モデル契約書では「システム要求事項」）に対するシステム概要についての提案である。そして、契約締結後、システムの仕様の詳細を詰める（本モデル契約書では「システム仕様書作成業務」）段階で、ユーザの使用環境の実態と照らし、かつユーザの具体的な要望なども踏まえながら、最終的に利用される第三者ソフトやフリーソフトがユーザの同意の下に決定されていくことになる。
このプロセスを前提として、第三者ソフトおよびフリーソフトの利用をユーザにおいて決定するべきとするのは、それぞれ次に掲げる理由からである。
（１）第三者ソフトの場合
開発されたソフトウェアの一部として第三者ソフトを使用するのはユーザであるため、使用許諾契約は、ユーザとその第三者ソフトのライセンサとの間で締結されるのが殆どである。また、その使用許諾契約においてライセンサから認められる使用方法も、厳格な条件が付けられており、しかも、そこで提示する保証等についても、しばしば次に示すように非常に限定的である。
| 1. | 一定の環境での限定的な動作保証であり、特定の使用目的（実際のユーザの使用環境等）に適合することは保証しない。 |
| 2. | エラーがない、動作が中断しないことを保証しない。 |
| 3. | 不具合については、バージョンアップや修正パッチのリリースなどの方法で、開発元の裁量でしか対応してもらえないことが一般的である。ユーザやベンダの勝手な補修は認めないか、それができてもその後の保証がなくなってしまう。 |
| 4. | 権利侵害に関する保証も限定的もしくは無保証である。 |
| 5. | 医療、原子力等重大な結果を惹き起こしかねない分野への使用については完全な免責としている。 |
このため、ユーザは、場合によっては、ライセンサとの間で当該第三者ソフトがユーザの使用目的に適合することを保証してもらうなどの特約の交渉を行う必要がある。また、その交渉次第では、当該開発そのものに影響が出てくるため、当該第三者ソフトを利用するかどうかについての選択は、ユーザが決定する必要がある。
（２）フリーソフトの場合
フリーソフトの場合は、使用許諾契約の締結という行為こそないものの、本モデル契約書第20条の解説（報告書）にもある通り、フリーソフトを開発に利用する場合には、フリーソフト特有のリスク、すなわちフリーソフトは無保証であることや、ものによっては商用への利用に制限があったり、配布について厳格な条件がある等、事前に確認して採用するかどうかを決定するステップを踏むことが必要となる。
特に最近では、ユーザは「開発期間の短期化」と「低価格」を求めることが一般的であり、その実現のためにはフリーソフトの利用が避けられなくなっていることから、無保証などのフリーソフト特有の条件から生じ得るリスクを負ってでもフリーソフトを利用するかどうかを決定する責任は、このフリーソフトのメリットを享受すべきユーザにあると考えるのが合理的である。というのも、もし、仮にベンダが決定し、その決定の責任をベンダが負わなければならないとなれば、ベンダはフリーソフトの利用の適否を事前確認するための十分な時間的余裕を求めたり、提供価格を高くするなど、フリーソフトの無保証に対するリスクヘッジを講ずることになる。そのようになると、ユーザはフリーソフトを利用するメリットを殆ど享受できなくなってしまうからである。
以上、（１）および（２）で論述した理由により、ベンダがシステム提案書に第三者ソフトやフリーソフトの利用を提示したことだけをもってベンダに責任があるというのは早計である。
２．第三者ソフトやフリーソフトの利用に関する全ての責任をベンダが負うべきではないか（第19条第1項、第20条第1項関連）
ソフトウェア開発委託取引においてベンダが負うべき責任は、ユーザとの契約に基づき、一定の機能を実現するためのシステムを開発してユーザに納入することである。もちろん、個別の受託状況や取引条件によりこの責任の程度にも幅があるが、この履行において、具体的には以下のような責任をベンダは負うべきと考えられる。
（１）第三者ソフトやフリーソフトに関するユーザへの説明責任
ソフトウェア開発に第三者ソフトやフリーソフトを利用する場合のベンダの責任は、その利用に関する事項がベンダが提出したシステム提案書中にあったものか、ユーザから提出されたシステム要求仕様書中にあったものかによって根本的に変わることはない。ベンダが提出したシステム提案書中にあったとしても、システム仕様書作成の段階で、ユーザとベンダの間で使用すべき第三者ソフトやフリーソフトを確認し合い、ユーザの責任において決定するということは上記１．で述べた通りである。
しかしながら、一般に、ベンダは、ソフトウェアやシステム開発に関してユーザに比べ圧倒的に多くの情報や知識を持っており、またこれらの情報を知り得る立場にあることから、これらの情報を事前にユーザに提供し、説明すべきである。
特に、フリーソフト特有のリスクに関しては、必ず事前に説明しておくべきであり、提供した情報や説明内容如何によっては、ユーザの決定に影響を与えることにもなる。そこで、この決定までの手続が重要となるため、本モデル契約書第20条第1項第2号において、ベンダがユーザの協力を得て、事前にフリーソフトの機能・性能等の調査を行い、当該調査結果についてユーザの確認を得ることが盛り込まれたのである。従って、ベンダが知っていた或いは予測できたにもかかわらず、当該情報をユーザに提供しなかったがために発生した問題については、ベンダは責任を免れ得ないであろう。
（２）第三者ソフトやフリーソフトを利用して開発されたソフトウェアが一定の機能を実現することへの責任
ベンダは、第三者ソフトやフリーソフトを利用して開発したソフトウェアが、ユーザの使用環境で動作し、一定の機能を実現させるための基本的な責任を負っていると考えられる。従って、動かない、或いは思うような機能が実現できないという原因が、第三者ソフトやフリーソフトの選定に関わる基本的な誤りによる場合（たとえば当該ソフトウェア所定の仕様書中の動作保証を誤解した場合、あるいは、ユーザが求める重要な機能が当該仕様書に明記されていない場合）には、仕様確認における明らかなミスであり、ベンダの責任である。
しかしながら、そのようなミスはなかったときでも、開発するシステムへの実際の組込み、あるいは、結合の段階で、またはユーザの他のシステムとの連携動作を行う段階で、第三者ソフトやフリーソフトが動作しない場合があり、その原因としては以下が考えられる。
| 1. | 第三者ソフトの場合は自由に試用できないこと。つまり、実際の使用環境で試用することができないため、ベンダとしても使用実績（経験）に頼るほかないが、それぞれユーザごとに使用環境が異なるため、適合するかどうかは実際に使ってみないとわからない。また、第三者ソフトのライセンサが保証する仕様書に記載されている使用環境は、ライセンサにおいて現実に確認できた環境であり、多数のサブシステムや多数の第三者ソフト / ハードが使われている実際のユーザの統合的な使用環境まで考慮されているわけではない。 |
| 2. | 専らライセンサのコントロールの中でしか利用できないこと。つまり、第三者ソフトの多くは内容がブラックボックスとなっているので、不具合があったからといって、ベンダやユーザが自由に不具合箇所を修正したり、代替品と手軽に交換したりするわけにはいかない。不具合への対応は、修正パッチのリリースなどライセンサの裁量によるとされているため、ライセンサに要求しても、特定の使用環境に関わる不具合について、タイミングのよい解決が期待できない。（開発途中に致命的な問題が発生しても、対応してもらえない場合がある。） |
| 3. | ユーザの複合的な使用環境において、連携する他のシステムとの関係により、使用する第三者ソフトやフリーソフトがうまく動作しない場合があること。 |
以上、1.3.に掲げたようなシステムがうまく動かない等の問題の原因は、第三者ソフトに内在する問題であることやベンダのコントロールだけでは変更できない事情にある。従って、たとえユーザの使用環境で動くソフトウェアを開発するという履行責任がベンダにあるとしても、問題解決のための調査を行い、解決手段を提示するなどの限定的な責任に留まり、ベンダの負担での作り直しや第三者ソフトの再調達といったような過大な責任までを負うものではない。
また、それらのソフトウェアの機能的な原因とは別に、開発に利用する第三者ソフトやフリーソフトに権利侵害の問題が発生し、そのままでは開発が続行できなくなる場合も考えられる。この場合のベンダの責任については、それぞれ本モデル契約書第19条および第20条に規定している通りであり、フリーソフトであれば、無保証のリスクを承知でユーザが使用を決定しているという事情、第三者ソフトについては、ユーザとライセンサとの契約に基づいて処理されるべきものであるという考え方から、ベンダが負うべき責任としては、代替ソフトウェア情報の提供程度になると思われる。
保証責任と賠償
１．瑕疵修補の請求期間はどのように設定すべきか（第31条関連）
ソフトウェア開発の成果であるプログラム及びドキュメントについては、納入時の検査で発見されなかったバグや仕様との不適合などをいわゆる「隠れた瑕疵」として一定期間内は無償で修補に応ずることが慣行として確立しているが、この期間をどの程度とするかは、プログラムの種類、用途、開発目的、利用目的、利用形態など納入物の特性に応じて適切な期間を設定する必要がある。
例えば、本モデル契約書が想定したモデル事例の取引において、ユーザの社内会計業務ソフトウェアを開発した場合では、これを用いた決算処理が適切に実行できるかどうかを確認するには、決算期を含む期間設定をすることが一般的であろう。ユーザが3月末決算の企業とすると、当該ソフトウェアを10月末に検収した場合、少なくとも翌年の4月までをカバーする6ヵ月間の瑕疵担保期間を定めることが合理的である。しかしながら、この期間でもプログラムの用途等に照らし短すぎる場合もあれば、ベンダの負担が過大となる場合もあるので、一律に6ヵ月とすべきとは断定できない。
なお、本モデル契約書に定める契約条件が複数のソフトウェア開発委託契約に適用される共通の取引条件になるような場合、本モデル契約書第31条に定めるような責任の期間を6ヵ月など一定の期間としたうえで、必要に応じて個別契約で特約をするという方法もあり得る。
何が「瑕疵」であるかは、いわゆるプログラムのバグのほかシステム仕様書の記述を基準としてこれに対する不適合が該当すると考えられるため、上記例における会計制度の改定やユーザの都合による変更の要請は、本モデル契約書第31条の対象とはならない。
２．損害賠償の限度額を委託料所定の金額としたのはなぜか（第38条、第31条第3項関連）
ソフトウェア開発に関連して損害が発生する場面では、多数の関係者の副次的な要素が絡み合い、原因の特定や損害との因果関係の究明が困難であり、相互に莫大な額の損害を主張し、問題解決が長期化することが多いものと考えられる。
この場合、合理的な範囲で賠償限度額を設定することにより、因果関係が稀薄な損害に関する賠償請求に見切りをつけ、問題解決を迅速に図ることは請求者にとっても決して不利益にはならない。なお、一般的に、取引関係に入る場合、契約金額を上回るリスクを想定することは極めて少ないと考えられるため、契約金額を損害賠償の限度額とすることは合理的と考えられる。また、同様の問題を抱える他業界においても、賠償限度額を設ける慣行が定着している。
ユーザとベンダとの間では、損害賠償の請求については、双方向であるべきと考える。賠償限度額をはずすべきとの意見も聞かれるが、これは専らユーザがベンダに対して損害賠償を請求することを念頭に置いたものであるとすれば、賠償限度額の設定がユーザのリスク管理にも資するものであることを考慮する必要がある。
なお、一方当事者の故意又は重大な過失により相手方に被らせた通常の損害（特別事情により生じた損害でも予見可能なものを含む。）については、賠償限度額に関する合意を援用することはできない。
セキュリティ
１．秘密保持義務の対象となる情報を秘密である旨特定したものに限定したのはなぜか（第26条関連）
ソフトウェア開発業務の遂行過程で、ユーザ・ベンダ双方が互いに相手方の秘密情報を取扱うことがある。もとより、企業の営業秘密は一定の要件を満たせば不正競争防止法により保護されるが、営業秘密に該当しない情報の中にも企業として秘密管理を必要とする情報があり、これが契約上、秘密情報として認識されている。この秘密情報については、信義則上、当然に適切な取扱いをすることが求められている。
しかしながら、秘密の対象・範囲の捉え方は当事者間において必ずしも一致するわけではなく、秘密とすべき情報の内容・範囲が不明確であることに起因したユーザ・ベンダ間のトラブルに発展することがある。
また、ユーザから預託された情報全てをベンダが秘密情報として適切に管理するためには、それ相応のコストを要する。このような場合、受益者負担の原則から、その分の費用負担はユーザが負うことになり、一般的に、ユーザが応分の費用負担をしない場合においては、実効性の確保の観点から問題となる（管理不能に陥る危険性がある）。
このようなことから、本モデル契約書第26条第1項では、「本件業務遂行のため相手方より提供を受けた技術上又は営業上その他業務上の情報のうち、相手方が特に秘密である旨書面で指定した情報」のみを秘密保持義務（第三者への開示又は漏洩の禁止）の対象となる「秘密情報」として取扱うこととした。
なお、営業秘密として不正競争防止法で保護されるための判断基準として、2003年1月、経済産業省から「営業秘密管理指針の概要」が公表された。同指針では、「秘密情報をその他の情報から区別すること」、「秘密性のレベルを区別すること（「極秘」「厳秘」「秘」等）」が営業秘密の「望ましい管理水準」として掲げられており、同指針上でも、秘密情報についてはその旨を特定した上で適切な秘密管理を行うことが求められている。
２．「秘密情報の取扱い」の他に「個人情報の取扱い」に関する規定を設けたのはなぜか（第27条関連）
今日、ソフトウェア開発を行う上で個人情報を取扱う機会が増えつつある。このような状況の中、個人情報保護の重要性を認識し、個人情報を適切に管理することは、契約当事者双方にとって共通した課題となっており、ベンダとしてもそのことを強く認識する必要がある。
個人情報はユーザが収集し保有している情報の中でも、本人の基本的人権にかかわる重要な情報であり、かつ、時間の経過とともに秘密性を喪失するような性質のものではないことから、秘密情報とは性格を異にしている。そこで、本モデル契約書では、従来から一般的な契約書に盛り込まれている秘密保持条項とは別に、個人情報の取扱いについての条項（第27条）を設け、ユーザ・ベンダ双方が履行すべき義務の一環としてこれを位置付けている。
３．納入したプログラムに実施するセキュリティ対策については、ユーザ・ベンダ双方で協議の上取り決める旨定めたのはなぜか（第32条関連）
Web対応・分散処理型ソフトウェアのようなインターネットを利用するソフトウェア開発においては、ウィルス、ハッカー、セキュリティ・ホールなどの様々なセキュリティ･リスクがあり、これらについて対策を講ずることの重要性は、ソフトウェア開発を行うベンダとしても強く認識しているところである。セキュリティを確保するためには、システムの保守、運用などを通じて継続的にセキュリティ対策を施すことが不可欠であるが、一般的に、これらについては相応のコストを要するものである。
しかしながら、ソフトウェア開発に利用された第三者ソフト等が内包している不具合の問題もあり、たとえ、最新のセキュリティ対策を講じたとしてもセキュリティ･リスクを100%回避するということは、不可能といっても過言ではない。
このような状況を踏まえて、予め、「システム仕様書」の中にユーザが求めるセキュリティ・レベルについて明記することより、「ソフトウェア作成業務」の範疇でベンダが保証責任を負うべきものと、システムの保守契約等の範疇で解決されるべき問題とを契約上で明確に区分することが求められる。このように区分して対応することが、様々なセキュリティ･リスクを伴うWeb対応・分散処理型ソフトウェアの開発においてはより重要となる。
情報システムのセキュリティ･リスクに対する耐性強化のための対策は、開発対象であるソフトウェアの内容、使用環境、ユーザが求めるセキュリティ・レベル等により異なるため、本モデル契約書第32条では、講ずべき具体的な措置についてはあえて規定せず、「納入した本件プログラムにセキュリティ対策を実施する必要がある場合は、ユーザ・ベンダの双方で協議の上その対応を取り決めるもの」としている。
加えて、JISA報告書「14-J001 新しいソフトウェア開発委託取引のあり方（ソフトウェア開発委託モデル契約と解説）」では、具体的なセキュリティ対策を講ずる際の参考として、具体的条文例を提示している。
ユーザの責任
１．ソフトウェア開発上ユーザに求められる役割は何か(第4条関連)
ソフトウェア開発について「専門家であるベンダに任せたのだから、後は、ベンダがきちんと作業をすればユーザが要求するソフトウェアが完成するはずだ」との声をユーザから聞くことがある。しかしながら、"無"から"有"を作り出すソフトウェア開発においては、その内容(機能･性能等)を明確にした仕様を特定することが前提であり、特に、ユーザの業務処理用ソフトウェア(アプリケーション･プログラム)の開発においては、当該ソフトウェアの内容についてユーザ･ベンダ間で確認しながら作業を進めざるを得ないという特性があることから、開発作業に対するユーザの協力等が絶対的に必要とされる。この協力等がユーザに求められる役割であるが、これは次の二つに大別される。
第一の役割は、開発対象ソフトウェアの仕様を確定することである。
ユーザは、自らの業務をコンピュータ処理するためのソフトウェアの開発をベンダに委託するのであるから、ユーザが保有している当該業務処理に関する必要かつ十分な資料や情報をベンダに提供しなければならない。また、作成を希望するソフトウェアの内容(機能･性能等の仕様)についても、できるだけ明確･具体的に要求することが重要である。
第二の役割は、一連の開発作業の節目毎及びテスト･検収段階で、開発されたソフトウェアの内容が要求した仕様通りになっているかを確認することである。
特に、本モデル契約書が想定しているWeb対応・分散処理型ソフトウェアは、ユーザの利用部門の利用者(一般的にはITの非専門家)が直接使用するためのソフトウェアであるから"使い勝手"が重視される。この使い勝手という抽象的･主観的なユーザの要求内容をベンダに正確に伝え、開発されるソフトウェアに反映させることが重要である。このためには、ユーザがソフトウェア開発作業の節目毎に積極的に参画し、ユーザでなければできない作業を分担する方が、作業効率が上がるばかりか、ユーザ要求に合致した使い勝手のよいソフトウェアが開発できることになる。
そこで、本モデル契約書は、第1条第3項で｢本件業務の遂行には、ユーザ･ベンダ双方の共同作業及び分担作業が必要であることを認識した上で、自らが分担する作業を誠実に実施すると共に、相手方の分担作業にも協力すべき｣旨を規定し、これを更に具体化して第4条で「ユーザの役割分担」を盛り込んでいる。
この第4条に規定されているユーザの役割分担の内容は、上記のユーザに求められる二つの役割を開発作業プロセス毎に具体明確化したものである。このほかにもベンダの開発作業を進める中で、ユーザにも協力等を求める場合が生じ得る。この場合の協力内容は、ユーザの力量によって実行レベルに差が生ずると思われるが、少なくともユーザにとって実行可能な範囲内のものとすべきである。
そして、共同作業や分担作業を円滑に進めるための作業推進体制について、第2章(第8条から第11条)の4ヵ条をもって細かく規定している。特に、第10条第2項は、ユーザの責任者の権限及び責任を明確に規定しているが、これは、ユーザの利用部門の意見要望等を反映して短期間でソフトウェア開発を可能とするためには欠かせない規定といえる。
２．ユーザへの危険負担の移転時期は検収完了時点とすべきではないか(第5条第3項関連)
危険負担は、売買や請負等の双務契約において、当事者の一方の債務が相手方の責任にすることができない事由により、履行不能となって消滅した場合に、その相手方の債務も消滅するかどうかという問題である。ソフトウェア開発委託契約においては、ベンダが開発し､ユーザに納入するソフトウェアが、第三者又は不可抗力等によって滅失･毀損等した場合にこのことが問題となる。
一般的には、ベンダの債務は開発したソフトウェアをユーザに納入･引渡した時点で終了するが、実務的には危険負担を、ソフトウェアに生じた滅失･毀損等の損害をユーザ･ベンダのどちらが負担するかということとして捉え、この負担がベンダからユーザへ移転する時期を納入時点又はユーザによる検収完了時点と約定することが多い。
本モデル契約書第5条第3項は｢納入物を納入した後の危険は、甲がこれを負担するものとする｣と危険負担の移転時期を納入時点に定めている。
本モデル契約書でベンダが負う一番重要な債務は、プログラムの納入･引渡しであるが、第21条で｢所定の動作環境下において稼働可能な状態にすることをもって納入｣と定めている。この場合の納入物としてのプログラムは、別紙2「納入物一覧」に記載されたサーバー用とクライアント用の2種類のプログラムであるが、これらがユーザの支配管理領域にあるサーバーやクライアントといったコンピュータにインストールされ、ユーザがこれらを使える状態になったことをもって納入･引渡されたと解される。
納入・引渡し後、第23条により、ユーザが当該プログラムにつき所定の検査期間内に検査を行い、その検査合格をもって検収完了となるが、プログラム納入後は、ユーザが自由に使用できる状態にあり、かつ、ユーザの支配管理下に置かれることを考慮すると、本モデル契約書第5条第3項の危険負担移転時期は合理的であり妥当といえる。
３．ベンダが所定の期間内に業務を終了できず又は所定の納入期限内に納入物を納入できないと判断した場合に本契約を変更できる旨定めたのはなぜか (第7条第2項関連)
納期変更は契約における重要事項の変更であり、軽々しく行われるべきではない。とはいえ、ソフトウェア開発はユーザ･ベンダの相互信頼・協力関係をベースとしており、ユーザも所定の共同作業や分担作業を誠実に実施しなければ、スケジュール通り円滑に作業が進まないという特性を有している。
納期遅延となる事態を発生頻度順に見ると、仕様が決まらない（ユーザがユーザ社内の意見をまとめきれない、仕様の決定をしきれない等）、ユーザの都合により途中で仕様が変更する、利用を予定していた第三者ソフトが使えない等の外部要因に起因して仕様や設計の変更が余儀なくされる、等を挙げることができる。
しかしながら、納期を重視するあまり、十分な仕様検討がなされないままプログラムの作成作業を急がざるを得なくなったために、開発されたソフトウェアが粗悪で使い物にならなかったという事態は回避せねばならない。
そこで、本モデル契約書では第7条第2項に、｢ベンダが所定の作業期間内に業務を終了できず、又は所定の納入期限内に納入物を納入できないと判断した場合には、ユーザに申入れて契約(作業期間や納期)を変更ができる｣旨規定している。もちろん、この変更は、第35条所定の手続に従って、ユーザはベンダの申入れを受けて協議決定し、それを内容とした変更契約を締結することによってのみ実行することができる。
ベンダは、作業の進捗状況について日々チェックをすることで、予期せぬ仕様変更や外部要因等の発生をいち早くキャッチし、それがスケジュールに影響を与えることが明らかになったときには、遅滞なくユーザに報告し､必要であれば納期を延期してもらう等の申入れを行うべきである。
これについて、本モデル契約書では、主任担当者（第9条）、責任者（第10条）、連絡協議会（第11条）という作業推進体制の確立について定めており、これらを通して日頃から契約当事者双方が意思疎通を円滑化し、意思決定を迅速に行い、双方の業務に支障･影響ができるだけ生じないように努めることが現実的な対応である。
また、本モデル契約書第7条第2項はベンダを免責するための規定ではないかという批判もある。しかし、ベンダがユーザに対し損害賠償等の責任を免れるのは、あくまでもベンダに帰責事由がない場合における納期変更に限られる。従って、ベンダに帰責事由がある場合の第7条第2項による変更は、第38条によりベンダが損害賠償等の責任を負うことはいうまでもない。
４．ユーザ・ベンダ双方において責任者を定める旨規定した意義は何か(第10条関連)
ソフトウェア開発における作業推進体制としては、従来から｢主任担当者｣と｢連絡協議会｣の設置が必須とされてきた。本モデル契約書第10条第1項では、主任担当者とは別に、ユーザ･ベンダ双方に｢責任者｣を設置することを規定している。このような条項は､従来の契約には見られない新しい条項である。
従来のソフトウェア開発においても設置されていた主任担当者は、本モデル契約書第9条第2項に規定されているように、相手方との間で日常的に発生する連絡･確認等を行う窓口としての役割を担っている。主任担当者には、一般的には当該ソフトウェア開発に従事又は深く関与する者が選任されることになるが、このように連絡等の窓口を一本化することで、ユーザ･ベンダ相互の意思疎通を円滑化でき双方の齟齬を防ぐことができる。
Web対応・分散処理型ソフトウェアの開発は、従来のホスト・コンピュータ用のアプリケーション開発に比べて小規模であるから、開発期間の短期化、低価格という特徴をもつほか、フリーソフトを含む第三者ソフトの利用や再委託が不可避であり、従来以上に開発作業へのユーザの積極的な参画が求められる。
そこで、開発内容等に係る重要事項についても、双方の意思決定を迅速に行う必要が生じ、この役割を担う責任者の設置が必要となる。とりわけ、Web対応・分散処理型ソフトウェアの開発は、ユーザの責任者の役割が特に重要となることから、本モデル契約書第10条第2項では、ユーザの責任者の権限と責任が規定されている。
ソフトウェア開発作業を円滑に進めていくためには、作業に伴って次々と作り出される成果について、ユーザによる確認･承認等もスピーディに行う必要があり、特に、開発プロセスの流れの中で、ユーザによる確認･承認等が求められる場面として代表的なものには、システム仕様書の承認、中間成果(特に、画面などのユーザインターフェース)の確認などがある。これらの確認･承認等をその都度、ユーザが社内に持ち帰り検討していては、開発作業の流れが中断・停滞してしまう。
以上の理由から、ユーザの責任者の権限と責任の内容については、本モデル契約書第10条第2項の各号に例示的に規定されている。
５．ソフトウェア作成業務の実施に際して、ベンダがユーザに対し協力を要請できる旨定めたのはなぜか(第16条第2項関連)
本モデル契約書によりユーザがベンダに委託する業務は、｢システム仕様書作成業務｣と｢ソフトウェア作成業務｣である。このうちソフトウェア作成業務は、システム仕様書に基づき本件ソフトウェアを設計・製造し、テストを行い所定の動作環境下で本件プログラムが稼働可能な状態にするまでの作業をいう（第3条第1項第2号）。
従って、この業務の遂行は、ベンダがITの専門家として責任をもって行うことが基本となる。このことから、本モデル契約書第16条第3項は、ソフトウェア作成業務について「ベンダによる作業は請負形態で行われるものとする」旨規定している。
しかしながら、ソフトウェア作成業務の遂行過程では、画面イメージを決めるときにユーザの意見を求めたり、プロトタイプ版の評価を行う際にユーザの判断を必要とするなどの様々な作業等が発生し、これらの作業の性質上、ユーザの協力等がなければベンダは作業を進めることができない。そこで、本モデル契約書第16条第2項では、「ベンダはユーザに対して必要な協力を要請することができ、ユーザはこれに応ずる」旨、ベンダがユーザに求める協力について包括的に規定されている。
もっとも、ベンダがユーザに協力を要請できるのは、本来、ベンダが責任をもって作業を進めるために欠かせない範囲内での必要事項に限られ、この範囲を超えてユーザに過度な負担を負わせるような事項は、当然に除かれることになる。
なお、ソフトウェア作成業務において、絶対的に欠かせないユーザの協力事項として、本モデル契約書では、具体的に、中間成果の確認（第17条）、第三者ソフト･フリーソフト利用の協議と必要な措置（第19条、第20条）、納入物の納入･据付調整における必要な協力（第21条）、検査仕様書作成の協議と承認（第22条）、本件プログラムの検収（第23条）、必要な資料等の提供（第24条）などが個別に規定されている。
また、上記以外で必要に応じベンダがユーザへ協力を要請できる事項の例としては、以下が考えられる。
| 1. | データベース作成作業、テスト作業に必要となるデータ、作業環境等の提供 |
| 2. | 画面設計等に必要となる実際に使用している帳票等の提供 |
| 3. | 実際の運用を想定したコンピュータ環境やネットワーク環境の調査 |
| 4. | ユーザが保有している開発機材(第三者ソフトを含む)で、作業に必要となるものの貸与 |
| 5. | ユーザの事務所内でベンダの作業が必要となる場合における作業スペース等の提供 |
６．ユーザが提供した資料等に起因する納入物の瑕疵等の結果について、ベンダはその責任を免れるか(第24条第3項関連)
ソフトウェア開発委託契約の最大の目的は、ユーザが希望するソフトウェアを作成し納入･引渡すことであるから、納入物としては、プログラムと操作マニュアル等のドキュメントは絶対に欠かせない。
特に、プログラムはユーザの業務処理内容･手順等をコンピュータ処理できるように表現した著作物であるから、そのプログラムが所定の機能･性能を発揮できない場合には、物理的瑕疵があるといえる。また、そのプログラムが、他人の著作権を侵害しているとしたら権利的瑕疵があるとみなされる。
このように、プログラムの瑕疵は、大きくは物理的瑕疵と権利的瑕疵とに分けることができるが、ベンダはいずれの瑕疵についても担保責任を負う。この瑕疵の範囲をどのように捉えるかによって、ユーザ･ベンダの負担の範囲が決定するので、しばしば契約当事者間で問題とされるところである。特に、プログラム作成において必ず生ずるといってよいバグを瑕疵とみるかが難問とされている。
一方、プログラムは、ユーザが提供した資料等に基づき設計され、作成されたものであるから、瑕疵の中には、この資料等に起因するものも当然ながらあり得る。ベンダの担保責任については、民法第634条により、原則としてベンダには瑕疵修補義務が課せられているが、その例外として、民法第636条に「目的物ノ瑕疵カ注文者ヨリ供シタル材料ノ性質又ハ注文者ノ与ヘタル指図ニ因リテ生シタルトキハ之ヲ適用セス」と規定されていることから、ユーザの資料等に起因する瑕疵については、ベンダは担保責任を負わなくてよいと解される。
以上の事情を背景として、本モデル契約書第24条第3項では、ユーザが提供した資料等の誤りなどによって生じた瑕疵等の結果について、ベンダは免責されることを規定している。
７．システム仕様書の変更に伴う手続を厳格に定めたのはなぜか(第34条関連)
本モデル契約書で想定した取引においては、開発されるソフトウェアの内容は、ユーザのシステム要求事項に基づいてベンダが作成し提出したシステム提案書によって合意がなされ、契約が締結されることになる。
契約の締結後、ベンダは、システム提案書に基づいてシステム仕様書を作成することになるが、システム仕様書は、最終成果であるプログラム作成の基準書であり、かつプログラムの機能・性能にも直接影響するほど重要なものである。
従って、システム仕様書を変更することは、ソフトウェア作成業務に大きな影響をもたらし、場合によっては、ソフトウェア作成業務のやり直しや中止などの重大な支障をきたすこともある。このようなことから、システム仕様書については、確定以後、特別の事情がない限り変更してはならない。
そこで、システム仕様書確定後にこれを変更することを防ぐために、本モデル契約書では、システム仕様検討会を開催し、この場を通して、ユーザ･ベンダ双方が、システム仕様書の記載内容を慎重に調整・確認していくことが定められている。また、本モデル契約書では、最終的にはユーザの承認をもってシステム仕様書を確定することとしている。
しかしながら、契約当時の事情とユーザの環境が大きく変わることにより、当初の内容と異なるプログラムを作成しなければならなくなり、システム仕様書の変更が余儀なくされることもある。このような事態への対処としては、契約継続に重大な支障をきたさない限り、これを認める方が当事者双方の意に適うことになる。
そこで、本モデル契約書第34条は、その影響が委託料や作業期間等に影響を及ぼさない程度までであれば、システム仕様書の変更を認めることとし、この変更手続を厳格にすることで、これが乱用されないようにしている。
以上、システム仕様書が確定されるまでのプロセスにおいて、システム仕様検討会を開催し、ユーザ・ベンダ間でシステム仕様書の記載内容を慎重に調整・確認していることを考慮すると、システム仕様書の変更に厳格な手続を要することは妥当性があるといえる。
８．ユーザはどのような検査を行うべきか(第22条、第23条関連)
ユーザは、納入･引渡しを受けたソフトウェア(中心はプログラム)について、ユーザの要求が適切に反映され、ユーザの使用環境･方法等に適合しているかを検査しなければならない。この検査では、ユーザは、できるだけ実際の使用環境のもとで当該ソフトウェアを実際に動かし、画面や操作性などについて確認することになる。
この検査のためには、いわゆる"物差し"の役割を果たす基準が必要であるので、通常、検査仕様書を予め作成しておくことになる。検査仕様書は、システム仕様書の記載事項をベースに作成される必要があり、本モデル契約書第22条では、ユーザがベンダに検査仕様書作成を委託する場合について定めている。もっとも、検査仕様書は、ユーザが自ら使用するシステムを確認するためのものであることから、ユーザがこれを作成する旨規定してもよい。
検査仕様書の作成をベンダに委託する場合、ユーザは検査仕様書作成に必要となるテストデータやテスト項目等の情報を提供しなければ、検査仕様書の作成は望めず、この場合においても、ユーザは必ず、検査仕様書の内容がユーザの要求事項を満たしていることについて確認した上で承認しなければならない。
また、本モデル契約書第23条では、検査は、ユーザ自身が行うことになっているが、この作業の一部をユーザはベンダに委託することは可能である。しかし、検査は、いわば一種の監査であるので、検査の一部を委託する場合であっても、必ずユーザ自身がその検査結果の確認を行うべきである。
以 上
表記基準
| 1. | 関連条文の明記 本文では、それぞれの課題が、新しいモデル契約書のどの条項に関連したものであるかを示すために、括弧書きで関連する条項番号が記されている。 |
| 2. | 表記方法 本文では、それぞれ右のように用語を統一している。 |
| 新しいモデル契約書 | ： 本モデル契約書 |
| 委託者 | ： ユーザ |
| 受託者 | ： ベンダ |
関連公表資料
| 1. | 提言 「新しいソフトウェア開発委託取引のあり方（JISAポジションペーパー）」 |
| 2. | モデル契約 ソフトウェア開発委託モデル契約（平成14年5月版） |
| 3. | 報告書（（社）情報サービス産業協会） 「14-J001 新しいソフトウェア開発委託取引のあり方（ソフトウェア開発委託モデル契約と解説）」報告書概要 |
| 4. | 関連書籍 『新しいソフトウェア開発委託取引の契約と実務』（社）情報サービス産業協会 法的問題委員会契約部会編、(株)商事法務、平成14年7月 「新しいソフトウェア開発委託取引の契約と実務」と「報告書：14-J001新しいソフトウェア開発委託取引のあり方」との相違について」 |