情報システム開発の契約は、請負契約になるのが通常です。情報システム開発の契約は、通常の製品の契約と比較して、多様な特徴があり、それによる、発注者と受注者の間でトラブルが発生することが多いのが現状です。→参照：「情報システム調達契約での問題点」
それを回避するには、契約の段階で詳細な合意を得ることが求められます。それには、公平な立場での標準的な契約書のモデルがあると便利です。
経済産業省は『情報システム・モデル取引・契約書』を策定しました（以下、「モデル契約」といいます）。モデル契約では、契約書で明確にすべき事項、実際の契約書モデル、運用管理での留意点などを示しています。
実際の契約においては、このモデル契約をベースにして、個々の状況に合わせてカスタマイズすることが適切です。
『情報システム・モデル取引・契約書』には、
経済産業省『情報システム・モデル取引・契約書（第一版）』平成１９年
経済産業省『情報システム・モデル取引・契約書（追補版）』平成２０年
があります。
第一版は、重要インフラ・企業基幹システムの受託開発情報システムを発注するときの契約を取り扱っており、対等に交渉力のあるユーザ・ベンダ前提にしています。それに対して追補版は、第一版を元に、中小企業等におけるパッケージソフト、ＳａａＳ／ＡＳＰ等の活用と保守、運用を含めた情報システム構築のためのモデル取引と契約のあり方を対象としています。
モデル契約書では、契約本文を逐条的に示していますが、ここでは「どのようなことを契約で明記すべきか」の主要論点について解説するだけにします。
モデル契約（第一版）の特徴
第１版の対象を示します。
- 契約当事者：対等に交渉力のあるユーザ・ベンダを想定
- 対象システム：重要インフラ・企業基幹システムの受託開発、保守・運用
- 開発手法：ウォーターフォールモデル
他の基準類との整合性を重視しています。
- 経済産業省は、「情報システムの信頼性向上に関するガイドライン」（２００６年）により、「情報システムの信頼性向上は、発注者と受注者の双方の責任」であり、「契約における重要事項の明確化」が重要だとの指摘をしましたが、モデル契約は、それを受けたものです。
- 「共通フレーム２００７」によるシステム企画・開発・運用・保守プロセスをベースにして、全体をいくつかのプロセスに区分しています。
- 運用・保守のプロセスでは、ＩＳＯ20000（ＩＴＩＬ）との整合性も考慮しています。
主要な論点
- 対象範囲と多段階契約
- ソフトウェアの開発に関するだけでなく、それ以前の「超上流プロセス」や開発後の「運用プロセス」も含んでいます。
契約形態としては、全プロセスを一括して契約するのではなく、全体を複数のプロセスに分解して、それぞれに応じて、請負型・準委任型の委託契約にすることを推奨しています。
- 再委託におけるユーザの承認の要否
- 請負契約では、成果物を完成させるための手段・方法は、原則として受託者（請負先）に任せられます。それで、情報システムの構築では、
・システムインテグレータが、個別の業務を再委託をする
・プログラミングなどを下請などに再委託をする、あるいは、派遣労働者を使う
ように、再委託が行われることが多い状況です。
そのため、責任関係の明確化の観点等から問題がありますし、システム化対象業務によってはセキュリティ確保が重要なこともあります。
それで、再委託先の選定について事前にユーザの承諾を必要とするかどうかについては、契約において規定しておくことが重要です。
モデル契約では、
・再委託におけるユーザの事前承諾を設ける場合
・再委託先の選定について原則としてベンダの裁量とする場合
の両案について、契約文例を示しています。 - 役割分担、開発環境
- システム開発では、ユーザとベンダがそれぞれ分担する業務があります。それを明確にしておくことが求められます。また、両者の進捗状況や問題点を相互に把握しておく体制を整備することが必要です。
作業内容により、ベンダ社員がユーザの事務所で作業したり、ユーザのコンピュータなどを使ったりすることが必要になります。そのときの遵守規定や費用負担などを契約に明記しておく必要があります。
ベンダ社員がユーザ事務所で作業している場合でも、派遣契約ではありません。ユーザ社員がベンダ社員に直接に作業指示をすることは、労働者派遣法で禁じられており、それを認める契約は無効になります。 - 損害賠償責任
- 情報システムの信頼性の向上の観点からは、障害の種別・当初合意されていた信頼性・安全性水準、損害賠償の範囲・賠償上限額等の損害の負担のあり方によって、情報システム利用者及び情報システム供給者の責任の度合いが大きく異なります。
モデル契約では、損害賠償責任の範囲、限度額について、
・民法の原則に従い相当因果関係の範囲とする
・情報システム構築の特殊性を考慮する
の両案について、契約文例を示しています。 - 著作権の帰属
- 著作権法では、特に定めがない場合は開発プログラムの著作権はベンダに帰属しますが、それではユーザが困る場合があります。また、ユーザに譲渡すると、ベンダが再利用できない問題が生じます。それで、著作権の帰属は契約での大きな問題になります。
汎用的な利用が可能なプログラム等の著作権をベンダへ帰属させることを前提として、３案を提示しています。
・ベンダにすべての著作権を帰属させる場合
・汎用的な利用が可能なプログラム等はベンダへ、それ以外をユーザに帰属させる場合
・汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外を共有とする場合 - 秘密情報の取扱い
- 情報システムでは、対象業務に密接に関係していることから、その開発を依頼するには、業務内容も伝える必要があります。そのなかには、営業秘密に属するものもありましょう。また、システム開発に関するベンダのもつ独自のノウハウをユーザが知る機会も生じます。
モデル契約では、不正競争防止法や営業秘密管理指針と整合性を持った秘密情報の取扱いに関する条項（第４１条）を設けています。
・秘密情報であることを相手側に書面で示すこと
（口頭で伝えたときは、速やかに文書化すること）
・開発を再委託する場合は、同等の守秘義務契約を締結して再委託先することの承認を得ること
などを掲げています。
なお、秘密情報の取扱いに関して、両者が合意すること、あるいはその文書をＮＤＡ（Non DiscLosure Agreement）といいます（これは、システム開発だけでなく、一般に用いられる用語です）。 - 第三者ソフトウェアに関わる瑕疵
- ＯＳや開発言語などは、第三者が作成したものを用いることがほとんどですが、そのソフトウェアに欠陥があり、システムが期待したとおりに動かない場合があります。なかには、ＯＳＳ（オープンソース・ソフトウェア）のように、開発者に責任を追及できないものもあります。個々のソフトウェアには欠陥がなくても、他のソフトウェアやシステムとの組み合わせによって生じる不適合もあります。
このような場合に、
・そのソフトウェア採用をユーザとベンダのどちらが主張したのか
・システムインテグレータが存在するかどうか
などで、多様なケースが考えられます。
一般に、ユーザはベンダよりも第三者ソフトウェアに関する知識が乏しいことから、どのような契約にするのかが大きな問題になります。
モデル契約（追補版）の特徴
追補版は、第１版が対象としなかった環境、特に中小企業での情報システムでの契約について追補したものです。
追補版の対象を示します。
- 契約当事者：ＩＴの専門知識を有しないユーザと業として情報サービスを提供するベンダ（ユーザとベンダが対等ではない）
- 対象システム：一般の業務システム
- 開発手法：パッケージ、ＳａａＳ／ＡＳＰなど、既存の市販システムを活用してシステムを構築する
原則として第１版を踏襲していますが、特に追補版で対象とする分野での論点を掲げます。なお、第１版ではいくつかの選択肢がある場合、それぞれについて併記する形式をとっていますが、増補版のモデル契約書本文においては、分かりやすさを優先して、推奨する方式だけについて、記述しています。
- 外部専門家やコンサルタントの参画
- ベンダにおいては、情報システムの知識を有しない企業に対して、業として情報サービスを提供する専門家としての十分な配慮と注意を払う必要があります。そのために、単にＩＴの技術面だけでなく、コンサルティング能力をもつことが必要だとしています。
ユーザにおいては、特に上流工程での適否が情報システムの成果に大きく影響することから、この工程の検討では、ＩＴコーディネータや中小企業診断士などの外部専門家やコンサルタントの参画が必要であるとしています。 - 重要事項説明書を用いた契約合意
- ユーザがＩＴの専門知識をもたないことから、ベンダが、契約全般に関して重要となる事項をわかりやすく説明する重要事項説明書を作成して提示する必要があるとしています。
- システムの目的、セキュリティを含む仕様、開発、保守、運用といったシステムライフサイクルと、双方の権利、義務について詳細内容を記述し、これらをもとに確認と合意を得ることを目的としています。
- 個別の業務に関する契約条件を定めるものとして基本契約と一体となって契約を構成するものになります。具体的には、ベンダの作業内容と契約条文の対応を明示する役割もあります。
- パッケージソフトウェアの取扱いについてのベンダの責任明確化
- ユーザとパッケージソフトウェア製造会社との間で使用許諾契約、保守契約が個別に締結されることを前提としています。また、ＳａａＳ／ＡＳＰを利用する場合、ユーザはＳａａＳ／ＡＳＰアプリケーション事業者と、場合によってはそのプラットフォーム事業者の間において、個別にサービス契約が締結されることをを前提としています。
しかし、ユーザがパッケージやＳａａＳ／ＡＳＰなどについて十分な知識をもっていないことから、業務要件定義に基づくパッケージソフトウェアの選定や取り扱いに関するベンダの責任について明確にしておくことが重要だとしています。 - システム構築後のプロセスの重視（保守、運用等）
- 情報システムは一定期間、安定稼働することによって企業の業績に寄与するのですから、運用と保守体制に関する事項（要員教育、保守、運用支援など）の要件を契約で明確にしておく必要があります。
保守、運用支援については、ハードウェア、ＯＳ、ミドルウェア等の構成要素別に保守契約を締結するのではなく、一次的なサポートの窓口が設定されることが必要です。ＩＴ能力が低いユーザの場合には、一貫性を維持して信頼性、安定性を確保するために、ソフトウェア設計・制作業務及び構築・設定業務を行ったベンダまたはその再委託先が窓口になるのが適切です。モデル契約ではこれを前提にしています。
なお、ＳａａＳ／ＡＳＰを対象にしたときの保守・運用に関しては、 経済産業省『SaaS 向けSLA ガイドライン』を参照することとしています。 - 著作権のベンダへの帰属
- 著作権をユーザとベンダのどちらに帰属させるべきかは意見がわかれることですが、パッケージの利用を前提とした場合では、原則としてベンダに帰属させるほうが適切だとしています。
- カスタマイズ等により作成されたソフトウェアの権利をベンダに帰属させることにより、ベンダが他のビジネスにおいても再利用できる環境を整えていた方が、総体としては価格を低く抑えることができ、中小企業等が利用するシステムとして比較的合理的な価格で広く普及することに資する結果となるとしています。
- ユーザがベンダから著作権の譲渡を受ける場合には、別途譲渡の対価を支払うことが要請されるため、ユーザの費用負担が増大します。また、ユーザが機密情報の保護をユーザが求めることは当然ですが、秘密保持条項で対応できるので、あえて著作権を取得しなくともよいとしています。