セキュリティ等について充実を図った「情報システム・モデル取引・契約書」 第二版を公開:
背景
デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタルトランスフォーメーション（DX）」が注目を集めています。経済産業省が2018年9月に公開した「DXレポート」は、DXを円滑に進めるには、ユーザ企業、ITベンダが双方の間で新たな関係を構築していく必要があると提言しています。そのために、DXの進展によるユーザ企業とITベンダのそれぞれの役割の変化等を踏まえたモデル契約の見直しの必要性が指摘されました。モデル契約は、情報システム開発における各局面の取引構造を透明化するためのツールであり、その普及により、ITベンダの産業構造転換、情報システムの信頼性向上、ユーザ・ベンダ一体となった生産性向上の促進が期待されます。
こうした状況を踏まえ、IPAでは、経済産業省が2007年に公開した「情報システム・モデル取引・契約書」、およびIPAが2011年に公開した「非ウォーターフォール型開発用モデル契約書」についての見直しの検討を2019年5月から2020年12月にかけて行いました。この検討では、全体を取りまとめる「モデル取引・契約書見直し検討部会」を設置し、民法改正に対応した「情報システム・モデル取引・契約書」の見直しについては、同部会の下で、ユーザ企業、ITベンダおよび法律専門家から成る「民法改正対応モデル契約見直し検討WG」において検討しました。
同WGでは、2019年度検討の成果として、2020年4月に施行された改正民法に直接関係する論点を見直した 「情報システム・モデル取引・契約書」の民法改正を踏まえた見直し整理反映版 （以下、「民法改正整理反映版」）を、2019年12月に公開しました。その後、民法改正に直接かかわらないものの、2007年のモデル契約の公表以降の情勢変化に応じて見直した方がよいと考えられる論点（後述）について検討しました。なお、論点の一つであるセキュリティに関連する検討については、セキュリティ専門家の意見を求めるため、2019年7月から同WGの配下に「セキュリティ検討PT」を設置して検討しました。
概要
IPAはこれまでの検討を取りまとめ、「民法改正整理反映版」に民法改正に直接かかわらない論点の見直しを加えた「情報システム・モデル取引・契約書」第二版（以下、「第二版」）を、2020年12月22日に公開しました。また、「第二版」から参照されるセキュリティ基準等公表情報の一例として「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」と「セキュリティ仕様策定プロセス」（以下、「セキュリティ仕様関連文書」）を同時に公開しました。
「第二版」は、ユーザ企業、ITベンダ、関連業界団体、および法律専門家の参画を得て議論を重ね、中立的な立場でユーザ企業・ITベンダいずれかにメリットが偏らない契約書作成を目指しているところが特長です。後述のように、民法改正に直接かかわらない論点について、現行のモデル契約条項と解説の修正版、および見直しについての解説を整理しています。
「セキュリティ仕様関連文書」は、セキュリティ専門家、一般社団法人コンピュータソフトウェア協会(CSAJ) Software ISAC等のセキュリティ関連団体の参画を得て議論を重ね、また広く意見募集も行って 、「第二版」から参照されるセキュリティ基準等公表情報の一例として、Windows Active Directory環境用の文書が作成されました。
IPAはユーザ企業・ITベンダ双方が「第二版」を参照することで、契約のタイミングで双方がシステムの仕様やプロジェクト管理方法、検収方法等について、共通理解のもと対話を深め、よりよい関係のもとITシステム開発が行われることを期待しています。
見直しのポイント
- 民法改正に直接かかわらない5つの論点
| 論点 | 概要 | 見直しの対象 |
|---|---|---|
| 見直しの観点・内容 | ||
| (1) セキュリティ | 近年重要性を増しているセキュリティに関して、システム開発の段階においてユーザとベンダがリスクやそれに対応するためのコストについての共通理解をした上で、適切な責任分界点を設定するためのプロセス及び契約条項上の手当をモデル契約で提案できないか。 | 条項 解説 関連文書 |
ユーザとベンダとは、それぞれの立場に応じて必要な情報を示しつつ、リスクやコスト等について相互に協議することにより、システムに実装する「セキュリティ仕様」を決めることが必要である。その観点から以下の見直しを行った。
| ||
| (2) プロジェクトマネジメント義務及び協力義務 | 近年特に問題となっている、ベンダのプロジェクトマネジメント義務及びユーザの協力義務について、モデル契約上の手当てによって、紛争の予防に資することはできないか。また、それぞれの義務について裁判例を踏まえて一定の整理ができないか。 | 条項 解説 |
裁判例で示されたプロジェクトマネジメントや協力義務は、それぞれ個別事案における判断であり、汎用性の高いモデル契約の中にこれらの義務を規定することは難しいことから、条項の形で追記することは見送り、以下のような見直しを行った。
| ||
| (3)契約における「重大な過失」の明確化 | 従前のモデル契約においては、「重大な過失」の有無が損害賠償の責任制限条項の適用の分水嶺となっており、また、昨年12月に公表した民法改正に対応した見直しによって、ソフトウェア開発業務等の請負型の業務における契約不適合責任においても、「重大な過失」の有無が客観的起算点による期間制限の適用の分水嶺となった。この「重大な過失」について、ベンダ側の予測可能性の担保の観点からより明確化することはできないか。 | 解説 |
| 契約条項として重過失については特段の定義をすることはせず、重過失概念に関する一般的な理解とシステム開発に関する裁判例のうち重過失についての判例を逐条解説に追記することで、重過失を考える上での手がかりを提供する。 | ||
| (4)システム開発における複数契約の関係 | 多段階契約においては、しばしば下流工程でトラブルが生じた際にユーザが上流工程まで遡って解除に基づく代金返還請求をしたり、損害賠償責任を追及するという紛争が頻発しているが、そのような紛争の予防・解決のためにモデル契約上何らかの手当ができないか。 | 解説 |
| 複数の個別契約がどのような処理になるのかは、個別契約の関係や問題となった債務不履行次第であることから、契約条項として手当するのではなく、裁判例を整理して得られた共通理解を解除条項の逐条解説に追記し、利用者の理解に資する。 | ||
| (5)再構築対応 | 現行のモデル契約はスクラッチ型の新規開発を念頭においたものであるが、デジタルトランスフォーメーションの実行に向けた既存システムの再構築をも念頭に置いたものになるような見直しが必要ではないか。 | 解説 |
| 要件定義に入る前に、再構築対象の現行システムについての調査を行い、その仕様を明らかにした上で再構築を行う必要があるが、現行システム調査には、専門的な技術も必要で、コストと時間を要する。現在動作している通りのシステムを再構築するだけ（現行踏襲）と考えるユーザにはこの意識が薄い。ITシステム部門向けには再構築に関するガイドブック類が公表されているものの、業務マネジメント層や契約に関わる部署に向けたものは少なく、モデル取引・契約書の中で注意喚起する。 |
- セキュリティ仕様書の作成プロセス
「第二版」では、セキュリティ仕様書の作成プロセスを明確化し、その内容を解説に記載するとともに、そのプロセスを前提とする契約書の条項を整理しました。
セキュリティに関しては、公的機関や業界団体、セキュリティ関連企業等が提供する、脅威分析を行い攻撃への影響と対策（緩和策）等を検討するための参照情報（ここでは「セキュリティ基準等公表情報」と総称）を使用して、ユーザとベンダが以下のような協力をすることにより、セキュリティ仕様書を作成します。
- 必要な情報を相互に出し合う。
- セキュリティ基準等公表情報を参照し、セキュリティの脅威を把握する。
- 開発対象のシステムについて考慮しつつ、脅威の影響についてリスク評価を行う。
- 対策の実装有無を決定・合意し、その結果をセキュリティ仕様書に反映する。
対策を実装しない場合にも、その旨を記録することが重要です。そのため、システム開発の各段階において、ユーザおよびベンダのそれぞれが提供すべき情報や検討すべき事項は何か、各段階の成果物は何か、どの段階でセキュリティ仕様を確定するのか等について整理します。
このようなプロセスにおいて参照するセキュリティ基準等公表情報の一例として、今回、「情報システム開発契約のセキュリティ仕様作成のためのガイドライン ～Windows Active Directory編～」を作成しました。また、対応するプロセスについて、「セキュリティ仕様策定プロセス～「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」対応～」に整理しました。
- システム再構築における企画プロセス
長年運用・保守を続けてきたシステムを再構築する場合、現行システムに関する業務知識（ドキュメントと有識者）が失われていることが多く見られます。そのため、現行システムの状態を正しく認識した上で再構築の方針を決め、実行計画を立てることが肝要です。システム再構築におけるこのような課題と、特に企画段階のプロセスについて、「第二版」では次のような解説を追加しました。
再構築の流れとしては、まず、企画段階・システム化の方向性フェーズにおいて、再構築の目的・要求事項や現行システムの状況から最適な再構築手法を選択しリスクを洗い出します。次に、企画段階・システム化計画フェーズにおいて、選択した手法とそのリスクをもとにリスクの予防策を検討します。
ユーザは、必要に応じて、ベンダとの間で、これらの支援業務（後のシステム開発契約の範囲外）を内容とする準委任契約としてのコンサルティング契約を締結し、これらの作業のための支援を受けることになります。
このようなシステム開発プロセスにおける再構築特有の検討の位置づけは、下図の通りとなります。
- 追補版について
今回、追補版については、時間の関係で、第一版の見直し内容がそのまま妥当する範囲で見直しを行うにとどめております。追補版については、必要に応じて セキュリティ関連のみならず、主に利用者として想定される中小企業にとってより適切なモデル取引・契約書の在り方を含め,現状の取引状況等に関する関係者の意見を踏まえた検討が期待されます。