民法改正対応モデル契約見直し検討WG



モデル取引・契約書見直し検討部会

民法改正対応モデル契約見直し検討WG







～情報システム・モデル取引・契約書～

（パッケージ、SaaS/ASP活用、保守・運用）

〈第二版　民法改正を踏まえた、追補版の見直し整理反映版〉

















202019年12月









独立行政法人情報処理推進機構

経済産業省

〈目　　次〉





総論

経緯

平成18年6月に経済産業省より「情報システムの信頼性向上に関するガイドライン」1（以下、「信頼性ガイドライン」という。）が公表された。信頼性ガイドラインは、我が国の情報システムの障害による社会的影響は日々、深刻化していると位置づけ、「システムの信頼性・安全性向上は喫緊の課題」との認識を示した上で、信頼性確保のためにはユーザ、ベンダの円滑な協力が必要なことから、「最大限明瞭な契約」、「契約における重要事項の明確化」、「情報システム構築の分業時の役割分担及び責任関係の明確化」の重要性を指摘した。さらに信頼性ガイドラインは、信頼性確保の実効性を担保するため、情報システムの利用者団体と情報システムの供給者団体による具体的な検討を求めた。

経済産業省は信頼性ガイドラインの指摘を受けて「情報システムの信頼性向上のための取引慣行・契約に関する研究会」(以下、「本研究会」という。)を設置し、ユーザ、弁護士、有識者と各団体による検討を重ね、パブリックコメントを経て ～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守・運用）〈第一版〉2（以下、「モデル取引・契約書第一版」という。）をとりまとめ平成19年4月に公表している。

このモデル取引・契約書第一版の特色は、「対等に交渉力のあるユーザ・ベンダ」、「重要インフラ・企業基幹システムの受託開発」を前提に、ソフトウェアの企画、開発、保守、運用をカバーし、共通フレーム3に準拠したユーザ、ベンダの詳細な役割分担を条文化したことにある。特に、仕様変更などにおける「口頭での合意による曖昧さ」を排除するための詳細な変更管理手続や、大幅な仕様変更に対応するための再見積規定、フェーズごとに異なるベンダの参画を想定したマルチベンダ・多段階契約などを規定した。さらに、機能要件4のみならず従来不明確であった非機能要件5の明確化を求めるとともにセキュリティに関連する条項を設け、ユーザ、ベンダ双方にとって見落としがちであった項目を条項化し、xxかつ透明性の高い合意が得られるよう工夫がなされている。

その後、経済産業省は、平成30年9月7日に「DXレポート～ITシステム「2025年の崖」克服とDXの本格的な展開～」（「DXレポート」）6を公表し、各企業が競争力維持・強化のために新たなデジタル技術を利用してこれまでにないビジネスモデルを展開する、デジタルトランスフォーメーション（DX：Digital Transformation）の推進を開始した。DXを円滑に進めるには、ユーザ企業、ベンダ企業がそれぞれの役割を変化させていく中で、双方の間で新たな関係を構築していく必要がある。DXレポートにおいては、その構築のためには、契約のあり方について見直しを行う必要があると提言している。そこで、経済産業省の依頼を受けた独立行政法人情報処理推進機構（IPA）は、「モデル取引・契約書見直し検討部会」を設置し、モデル取引・契約書第一版の見直しに着手した。見直しは、部会配下に設置した「民法改正対応モデル契約見直し検討WG」において、

①2020年4月1日施行の民法改正に直接かかわる論点

②民法改正には関係しないものの、現行のモデル契約の公表以降の情勢変化に応じて見直した方がよいと考えられる論点

に大別した上でそれぞれ検討された。そして、上記①の検討結果を反映した＜民法改正を踏まえた、第一版の見直し整理反映版＞の公開（令和元年12月）7を経て、～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守・運用）〈第二版〉（以下、「モデル取引・契約書第二版」という。）をとりまとめ、令和2年10月に公表された8。

一方で、モデル取引・契約書第一版作成時今後の検討課題として「パッケージを中心としたシステム導入の場合や反復繰り返し型の開発の場合、中小企業等ユーザにおける活用の場合等」について議論を深めるべきとの指摘があり、この指摘が本書における中核的なテーマとなった。そのため本書は、モデル取引・契約書第一版を元に、「中小企業等におけるパッケージソフト等の活用と保守、運用」を含めた情報システム構築のためのモデル取引と契約のあり方を集約した、～情報システム・モデル取引・契約書～（パッケージ、SaaS/ASP活用、保守・運用）〈追補版〉（以下、「モデル取引・契約書追補版」という。）を平成202008年（2008年）4月に公表した9ものである。

　その後、上述のモデル取引・契約書第一版の見直しと同期してモデル取引・契約書追補版の見直しも行われ、本書はその結果をまとめたものである。

　なお、DXレポートにおいて、DX推進の核となる情報システムの開発では、技術的実現性やビジネス成否が不確実な状況でも迅速に開発を行い、運用時の技術評価結果や顧客の反応に基づいて素早く改善を繰り返すという、仮説検証型のアジャイル開発が有効となるとされている。そのため、アジャイル開発向けの「情報システム・モデル取引・契約書」について、IPAに設置されたモデル取引・契約書見直し検討部会配下の「DX対応モデル契約見直し検討WG」において検討され、令和2年（2020年）3月に公開されている10。

目的

本書策定の目的は以下のとおりである。

（中小企業等におけるパッケージ、SaaS/ASPを活用したモデル取引・契約書の策定）

モデル取引・契約書第二一版同様に、信頼性ガイドラインの遵守、取引関係・役割分担の可視化、オープン化への対応等を踏まえ、新たにIT・法務の専門家がいない中小企業等への配慮、パッケージソフトウェアの活用、共通フレーム2013の活用等を基本的な視点とし、情報システムの信頼性向上、取引可視化に資する理想的な取引・契約モデルを目指す。併せてモデル取引・契約書第二一版で示された取引慣行、契約条項との整合性を確保する。

最終成果物として、①パッケージ、SaaS/ASP取引を活用したシステム構築取引・契約モデル、②モデル契約書（システム基本契約書及び企画、開発、移行、教育、運用、保守の各プロセスの個別契約に関するシステム基本契約書の別紙に相当する重要事項説明書）、③モデルドキュメントを策定する（以下総称して、「モデル取引・契約書第二版追補版」という。）。

モデル取引・契約書第二版追補版の活用にあたっては、以下の点に留意をする必要がある。

  1. 本研究会においては、一定の前提条件をもとに議論を重ね、xxxとxxxの理想的かつ実践的なモデルを提示したものである。パッケージソフトウェアを活用した情報システムのライフサイクルにおいて、ユーザとベンダ相互が参照し、円滑な取引のためのガイドラインとしての機能提供を狙っている。実際の取引においては、多様な取引形態や状況に応じ、モデル取引・契約書第二版追補版上のモデル取引の全部又は一部及び共通フレーム2013を検討して活用することが望まれる。また、主要論点はモデル取引・契約書第二一版を踏襲していることから、契約書の修正にあたっては適宜モデル取引・契約書第二一版11を参照されたい。

  2. モデル取引・契約書第二版追補版においては「中小企業等」を従業員数、資本金の大小などではなく「ベンダと対等の交渉力を有しない」12、ITや情報システム取引、法務の専門家、専従者を設置することが困難な団体、法人、企業等とした。こうした観点から、企業規模を問わず、IT、法務の専門家以外でも、情報システム取引の内容を正確に理解でき使いやすい契約書・重要事項説明書等を用意した。

  3. 「パッケージソフトウェア」「SaaS/ASP」13については、特定の業種又は業務を想定し、そのなかで汎用的に使用されることを前提とした市販ソフトウェアとした。従って、ユーザとパッケージソフトウェア製造会社との間で使用許諾契約、保守契約が個別に締結されることを前提としている。また、SaaS/ASPを利用する場合、ユーザはSaaS/ASPアプリケーション事業者と、場合によってはSaaS/ASPプラットフォーム事業者の間において、個別にサービス契約が締結される事を前提としている。SaaS/ASP事業者のビジネスモデルについては、後述を参照されたい。

  4. これらを踏まえ、モデル取引・契約書第二版追補版で示したモデル取引・契約書は、信頼性確保の観点から、業務要件定義に基づくパッケージソフトウェア、補完製品の選定、パッケージソフトウェアのパラメータ設定、モディファイ・アドオン14などの開発、構築・設定業務、保守、運用支援といった役務や財を提供するベンダとユーザの一連の取引15に対応するためのものである。

  5. 信頼性の高い情報システムの確保は、ユーザとベンダのたゆまない緊密な協働によってのみ得られるとの立場から、取引全般においては、ユーザ自身が役割を理解しベンダとの緊密な協働を行うことを前提とし、その上でユーザの理解を促しギャップを埋めるためのチェックリスト等を用意した。取引にあたってはこれらドキュメントの積極的な活用を前提としている。

  6. ベンダにおいては、情報システムの知識を有しない企業に対して、業として情報サービスを提供する専門家としての十分な配慮と注意を払う必要と一定の責任があり、この点についてはモデル取引・契約書第二一版と同様である。ベンダは、専門家として、コンサルティング能力、エンジニアリング能力を保有していることは当然のこと、善良な管理者の注意義務をもって、ユーザ業務に精通する努力、最新テクノロジーや将来動向を平易に説明する能力、さらにはプロジェクトマネジメントや品質管理能力の強化に日々留意を払っていることを取引の前提としている。

モデル取引・契約書第二一版が示した、デューデリジェンス、契約締結、変更管理手続に至る一連の取引ルールと国際取引慣行との整合性、多段階契約、再見積りの考え方を踏襲した。情報システム取引に多くみられる「ベンダ丸投げ」を排除するため、上流工程から保守、運用に至るまで、取引の透明性の確保に留意した。

モデル取引・契約書第二一版で示されたパッケージソフトウェア活用モデルを拡張・改良し、要件定義、パッケージソフトウェアの選定、カスタマイズ開発の有無、データ移行、運用、保守、要員教育を含めた、パッケージソフトウェア活用のシステム構築プロセスを改めて構想し、モデル取引・契約書第二一版同様にユーザ、ベンダ双方にとって使いやすく、共通理解が促進される取引の目安として機能するように構成した。

各フェーズのタスクは共通フレーム2013を準用しており、必要に応じて共通フレーム2013を参照することによって、目的や相互の役割などを共有、確認することを前提にしている。チェックリストはこれらの解説に努め、取引の節目において何をするべきかの理解が促進されるように構成した。

SaaS/ASPは昨今、新しいソフトウェアの利用形態として注目を浴びており、モデル・契約書第二版追補版においても、一般的なパッケージソフトウェアだけでなく、SaaS/ASPモデルでの活用も想定し全体を構成している。平成20年1月に経済産業省から「SaaS向けSLAガイドライン」16が発表され、同ガイドラインにおいて「インターネット等を経由するサービスであり、また、自社の財務データや顧客データなどをサービス提供者に預けることとなるため、企業が安心して利用するためには、利用者とサービス提供者間で、サービスレベルに関する取り決めが重要である。」との指摘がなされている。このような指摘を踏まえ、同ガイドラインのSLAモデルケースを掲載し、また、保守、運用におけるSLAについてはSLA合意書の記入例を例示した。

また、SaaS/ASPのベンダは運用形態によって、①アプリケーション、認証、利用制限、課金、サーバ管理、データセンタまでを一体として提供するベンダ、②SaaS/ASPのアプリケーションソフトウェアを提供するベンダ、③SaaS/ASPの認証、利用制限、課金、サーバ管理等を提供するSaaS/ASPプラットフォ

ームベンダなどに分かれる。③のプラットフォームベンダがデータセンタと契約し一体として管理する場合もあれば、②のアプリケーションベンダが③のプラットフォームベンダのソフトウェアだけを導入し、データセンタと契約するケースもあり、新たな市場を開拓すべく様々なビジネスモデルが競い合っている状況にある。一方で、利用するユーザにとっては、企業内のサーバ等で動作するパッケージソフトウェアと大きく異なることなく、一体のWebアプリケーションとしてサービスが提供されていることから、ユーザはこれら運用形態の違いや評価が異なる点を見落としがちであるので注意が必要である。そこで、機能、サービス評価の対象として②SaaS/ASPのアプリケーションベンダ、③SaaS/ASPのプラットフォームベンダを対象としたSaaS/ASP選定のためのチェックリストを用意した。また、カスタマイズのためのAPIやツールを整備しているSaaS/ASPのベンダもいるが、上流工程の重要性、ベンダのユーザに対する説明責任、ユーザとベンダの協働等、パッケージソフトウェアを利用する場合と異なる事はない。また、SLAについてはxxxが見落とす可能性が高いため、重要事項説明書でのSaaS/ASP候補選定、SaaS/ASP選定の際にSLAの評価を行うこととしている。

（パッケージソフトウェアをベースとしたシステム開発、導入の問題点）

パッケージソフトウェアをベースとしたシステム開発には、様々なメリットがある反面、ユーザの誤解や問題点の指摘も少なくない。

■xxxが想定するメリット

  1. パッケージソフトウェアの持つ機能や業務の流れを利活用する事で、自社の業務改革を実施する事ができる。

  2. 導入期間とコストを削減することができる。

  3. 導入のための専門要員を確保しなくても、システムを導入する事ができる。

  4. 導入後、即座にシステムを稼働する事ができる。

■現実の問題

  1. パッケージソフトウェア自体は完成しているが、ユーザの目的を達成するシステムとしての導入及び開発期間は短いとは限らない。

  2. 要件にそぐわないパッケージソフトウェアの導入を図ったり、カスタマイズを実施した場合、予想を上回るコスト増大を招く場合がある。

  3. パッケージソフトウェア本来の設計意図に反するカスタマイズを実施した場合、大幅なパフォーマンスの低下や制限事項の増加を招く場合がある。

  4. 既存システムの置き換えまたは刷新において、従来は実現可能だった機能が実現できるとは限らない。場合によっては、機能実現のためにコストの増大や、使い勝手の悪化を招く場合がある。

  5. 既設のシステムとの連携、データ交換は可能であるが、システムのOSや基本構造が異なる場合は、膨大な費用がかかることがあり、また、意図するタイミングで想定する出力が得られるとは限らず、既設システムの大幅な改造が必要となるケースも散見される。

  6. パッケージソフトウェアにカスタマイズを実施した場合、パッケージソフトウェア本体のバージョンアップが困難になる場合や、不具合改修などの保守サポートが受けられない、もしくは、割高のコストを負担しなければならない場合がある。

パッケージソフトウェアをベースに開発したとしても、しっかりとした要件定義が重要であることは、受託開発と何ら変わる事がない。反面、パッケージソフトウェアとして完成しているが故に、要件との適合性評価は、ユーザの要件と評価するパッケージソフトウェアをいかに知悉しているかにかかってくる。また、評価の範囲はパッケージソフトウェアの機能、カスタマイズの実現性と難易度の評価、開発会社のサポート体制、使用許諾契約の内容、将来のバージョンアップの動向など、個々に専門性が高く、幅が広い。このような点を踏まえた実効性のあるモデル契約の策定の必要性が指摘された。

（モデル契約書の策定・逐条解説）

モデル取引・契約書第二一版で併記となった主要論点については、引き続き両論を尊重し逐条解説において併記し、注意を促すように努めている。ただし、モデル契約書本文においては分かりやすさを優先して選択条項は併記していない。主要論点においてかかる部分については注意を促すように努めている。

モデル取引・契約書第二一版は、対等の交渉力を有するユーザ（民間大手企業等）とベンダ（情報サービス企業）を想定しているが、これは、情報システムに対する十分な知識を有している専門家の存在を前提としている。さらに、契約の実態として準委任契約、請負契約という契約類型が多段階に渡り選択されるため、法務及び契約実務の知識も併せて必要としている。

モデル取引・契約書第二版追補版では、これらの情報システム及び法務の専門家がいない中小企業等のユーザと、業として情報システム関連のサービスを提供するベンダとの契約を前提に、パッケージソフトウェアをベースとしたシステム開発、導入の問題点等も踏まえ、現状の取引実態に配慮した構成をとっている。主要論点については後述を参照されたい。なお、本書において参照する民法の条文は2020年4月1日時点のものである。

  1. 上流工程における多様性の確保
    　上流工程は、企業の規模、システムの大小を問わず最も重要な工程であり、その品質は情報システムの成果、信頼性に多大な影響を及ぼす。ところが、中小企業等は社内に情報システムの専門家を配置することができないため、ベンダの行う業務分析に依存せざるを得ない上に、要件定義書、RFP17など成果物の正否の評価が困難であり、結果として信頼性の低下や情報化投資の失敗の原因となるという指摘があった。
    　そこで上流工程においては、共通フレーム2013をベースに、ITコーディネータや中小企業診断士をはじめとする外部専門家やコンサルタントの参画を考慮したモデルを構想した。システムインテグレータ（SIer）やソフト会社だけでなく、さまざまな視点から要件定義を行うことで、システム構築の質を高め信頼性の向上を図る重要なポイントであるといえる。また、パッケージソフトウェアの持つ機能や知見の比較を得て、業務の見直しを図るといったことも多く、上流工程が手戻りを前提としてスパイラル的に進むことも想定しなければならない。このように、パッケージソフトウェアのカスタマイズの有無や、導入する業務の特性によって、上流工程の作業が大きく異なってくることから、多様な導入モデルに対応できるよう配慮した。

  2. システム構築後のプロセスの重視（保守、運用等）
    　企業における情報システムの安定稼働、信頼性の確保は、事業継続性にも大きく関わることであり、特に運用に携わる要員のリテラシの確保や、保守体制の重要性は論をまたない。ところが、情報システム構築においては、業務のシステム化や高度化に関心が集中し、運用や保守からの仕様検討がなされず、あるいは構築費用の確保を優先することから先送りが多く、これらが業務との不一致や運用上の障害解消を困難とする原因となり信頼性を大きく損なっているとの指摘がなされた。本来、情報システムは一定期間、安定稼働することによって企業の業績に寄与するのであって、運用と保守体制が要件として確立されなければならない点に着目し、要員教育、保守、運用支援といったシステム構築後のプロセスも配慮した。また、保守、運用支援については、ハードウェア、OS、ミドルウェア等の構成要素別に保守契約を締結するのではなく、一次的なサポートの窓口が設定されることを前提に、障害の切り分けや問題のエスカレーションがなされることとしている。ユーザ自身が障害切り分けを行なうことができないことから、一次的な窓口は、ソフトウェア設計・制作業務及び構築・設定業務を行ったベンダ、またはその再委託先とし、下流工程からの一貫性を維持することで、信頼性、安定性を確保するものとしている。

  3. 重要事項説明書を用いた契約合意
    　ITの専門知識を有しない中小企業等のユーザにおいては、ベンダの提案するシステムの内容が世の趨勢に従っているか、自社の目的に適合した正しい仕様であるかということを客観的に評価することが難しい。その結果、契約締結後の開発工程において、契約で定められた仕様が望むものでなかったことが判明し、工程の手戻りや、コストの増大、さらにはコスト負担ができずに不完全で信頼性の低いシステムでの稼働、あるいはベンダ側のかかるコストの負担による採算割れなど、様々な問題が発生してきた。体力のない中小企業等が、信頼性が高くかつ目的と合致するシステムを構築するためには、契約の透明性を高める合意プロセスの確保が重要であるとの指摘があった。さらに、大企業であっても情報システム部門や法務部門が関与しない情報システム取引においては、同様のプロセスが必要との指摘があった。
    　そこで、システムの目的、セキュリティを含む仕様、開発、保守、運用といったシステムライフサイクルと、双方の権利、義務について詳細内容を記述し、これらをもとに確認と合意を得るために、重要事項説明書を用いた合意プロセスを策定した。
    　また、重要事項説明書は、個別の業務に関する取引内容をユーザに説明するためのものであると同時に、個別の業務に関する契約条件を定めるものとして基本契約と一体となって契約を構成するものとなり、契約類型、個別の業務に必要となる契約条文を表すとともに、ベンダの作業内容を詳細に明示する役割を担っている。重要事項説明書によって、法的知識が十分でないユーザ企業にとっても契約内容の理解が促進され、開発着手に至る前での仕様の再検討と合意、厳密な変更管理の実施など、モデル取引・契約の実効性が高まることを期待している。また、これによりユーザが外部の弁護士に契約書の確認・アドバイスを依頼する場合も、その効率化・容易化が図れることを期待されている。18
    　一方、重要事項説明書を外形的に整えユーザに強要することで、ベンダが一方的に免責されるなどの懸念が指摘された。そこで、重要事項説明書には告知事項を設け、その内容の理解については、ユーザに対して十分な注意を喚起するよう配慮した。実際の運用においては、理解できた旨を文書で確認するなどによって、より実効性を高めることも考えられる。

  4. パッケージソフトウェア
    パッケージ活用によるシステム構築におけるパッケージソフトウェアの選定ミス（これにより、重大な契約不適合、モディファイ、アドオン開発上のトラブルがしばしば発生する。）は、即システム導入の失敗につながる。モデル取引・契約書第二一版は第48条、第49条の第三者ソフトウェア（パッケージソフトウェア等）・FOSS19の利用について、「ベンダは当該ソフトの選定（利用方法、機能上・利用上の制限、保証期間等）について、専門家としての情報提供義務を契約上の責任として負う」として、ベンダに対して善管注意義務を課し慎重な業務遂行を求めている。他方で、ベンダはパッケージソフトウェアの作成に関与していないので、パッケージソフトウェアの保証をすることができないことから、パッケージソフトウェアの採否の最終的な決定はユーザ責任で行うこととし、パッケージソフトウェア自体については、ユーザとパッケージソフトウェア製造会社との間でライセンス契約を締結し、問題を解決することにしている。
    　モデル取引・契約書第二版追補版では、ベンダはパッケージソフトウェアの契約不適合、バグの対応、使用上の制限等については、重要事項説明書での説明事項として位置づけるとともに、パッケージソフトウェアの選定に関しては、ベンダは善良なる管理者としての責任をもってパッケージソフトウェアに関する情報提供等の業務にあたるとしてベンダの責任を明確化した。

（モデルドキュメント）

ユーザはITや情報システムに精通していないし、他方ベンダは必ずしもユーザの業務に精通していないことから、取引の初期において相互の情報の偏りが著しい。さらにユーザ、ベンダ双方に異なる「当然の常識」や「取引慣行」が存在すると、後々に大幅な仕様変更などが起こりやすい。実態として、ユーザはベンダの選定やドキュメントの内容の正確性、正当性を評価する体制に欠け、ベンダは、ユーザからの情報入手の漏れや、作業都合上による課題や工程の先送りが生じやすく、それらが原因で齟齬が発生する。これらの点に着目し、ユーザ自身が各フェーズの成果を評価ができるようなチェックリスト、さらには具体的なイメージをつかむための詳細サンプルドキュメントを例示した。



モデル取引・契約書第二版追補版の全体像とポイント

（モデル取引・契約書第二版追補版の対象範囲）

本研究会におけるモデル取引・契約書第二版追補版の策定にあたっては、以下のような前提条件をおいている。

  • 契約当事者：ITの専門知識を有しないユーザと業として情報サービスを提供するベンダを想定。
    (例) 委託者（ユーザ）：民間中小・中堅企業、地方自治体、独立行政法人等、
    受託者（ベンダ）：情報サービス企業（SIer、ソフト会社、ITコーディネータ等）。

  • パッケージソフトウェアについては、ユーザとパッケージソフトウェア製造会社で使用許諾契約、保守契約を別途締結。

  • 開発モデル：パッケージ＋カスタマイズ型、パッケージ＋オプション型。
    ＊モデル取引・契約書第二一版｢2.(7)パッケージ活用、反復繰り返し型の開発、中小企業等ユーザにおける活用の留意点｣を基に、新たに策定したモデル。

  • 対象システム：財務会計システム、販売管理システム、電子メール、グループウェア、Webシステム等の導入、構築・設定、カスタマイズ開発、移行、教育、保守、運用支援。

・ 対象モデル：パッケージソフトウェアモデル、SaaS/ASPモデル。

  • プロセス：共通フレーム2013に準拠したシステムの企画プロセス、要件定義プロセス、システム開発プロセス、ソフトウェア実装プロセス、運用プロセス、保守プロセスの定義及びその修正。

  • 一括発注の場合に加え、マルチベンダ形態、工程分割発注に対応。



（パッケージソフトウェアを利用したシステム構築の特殊性、導入戦略による多様性）

パッケージソフトウェアを選択決定することで、大半のソフトウェア要件が決定されるという特色がある。要件を積み上げ、必要な機能を定め開発するのではなく、あらかじめ存在している機能を選択採用することで要件が確定されるともいえる。

パッケージソフトウェアの導入戦略は、(a)自社の業務に適合するようにパッケージソフトウェアをカスタマイズする、(b)自社の業務をパッケージソフトウェアに適合させる、という2つの対極が想定できる。コストという観点からそれぞれを評価すると、(a)はパッケージソフトウェアを開発工数削減のためのツールとして位置づけ、(b)は業務改善の知見や機能を得るツールとしての位置づけとなる。また、導入戦略によってベンダの選択も変化する。

実際には、(a)と(b)の中間に位置しつつ、業務の汎用性、特殊性に基づき取捨選択を行っており、その時点での社会的背景を含むビジネスモデルに大きな影響を受けていると言える。従って、モデル取引・契約書の策定にあたっては、パッケージソフトウェアの利用の目的を(a)と(b)の中間におき、上記導入戦略に左右されない全体像を追求した。

（モデル取引・契約書第二版追補版の全体像）

基本的な考え方や信頼性確保のための手続はモデル取引・契約書第二一版を踏襲した。

基本契約書は、パッケージソフトウェア利用コンピュータシステム構築委託契約書として基本的な14条を策定した。必要と思われる相互の権利と義務を明示するようにしてあり、基本契約書が長大となることで、債権債務が不明瞭になることを避けるとともに、契約に不慣れなユーザが後日「読んでなかった」「知らなかった」といった事態を招かないようにし、契約の実効性を高めることを目的としている。

■パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書（システム基本契約書）

第1条 本契約の構造

第2条 契約内容の変更

第3条 協働と役割分担

第4条 連絡協議会

第5条 ユーザがベンダに提供する資料等及びその返還

第6条 再委託

第7条 秘密情報の取扱い

第8条 個人情報

第9条 報告書の著作権

第10条 損害賠償

第11条 解除

第12条 権利義務譲渡の禁止

第13条 協議

第14条 合意管轄

個別契約書の役割をはたす重要事項説明書は、プロセスに応じて上流工程から保守、運用までの11契約を策定した。重要事項説明書はシステム基本契約書の別紙となり、それぞれに記名押印して一体の契約として機能する。契約当事者が表紙等の基本部分と業務に応じた必要な個別契約を選択し重要事項説明書を構成することで、多段階契約、マルチベンダ契約に対応できる。また、システム基本契約書の第2条（契約内容の確定、変更等）、第4条（連絡協議会）に基づいて仕様の変更に伴う再見積にも対応している。

■重要事項説明書（個別契約書）

（鑑部分）

表紙（契約の表示、受託者、重要事項を説明する契約担当責任者、委託者、告知事項）

契約の一覧（契約名称、受託金額、支払条件、特約条項）

その他本件業務に必要な事項

添付図書（図書名、版、日付）


（要件定義：準委任）

A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）

B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）

C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル）

（外部設計：準委任）

D　外部設計支援業務契約

（内部設計、システム構築・設定：請負）

E ソフトウェア設計・制作業務契約

F 構築・設定業務契約

（移行・運用準備：準委任）

G　データ移行支援業務契約

H　運用テスト支援業務契約

I　 導入教育支援業務契約

（保守・運用：準委任）

J　保守業務契約

K　運用支援業務契約

例えば、保守と運用支援を受託するベンダは、重要事項説明書の「表紙」「契約の一覧」「その他本件業務に必要な事項」「添付図書」に加え、該当する「J　保守業務契約」「K　運用支援業務契約」の契約条項と具体的内容を記述し、システム基本契約書と重要事項説明書の記載事項をすべて説明し合意の上、それぞれに記名押印して契約とする。同一のベンダが複数業務を受託する場合は、各業務開始時に重要事項説明書の内容を確定し説明する。後工程の重要事項の条項は空白とするか、確定していない条項については「予約」として記載し、改めて業務開始までに内容を確定し説明する。

重要事項説明書の表紙には、システム基本契約書との関係、契約の表示、契約の類型、重要事項の説明、受託者、重要事項を説明する契約担当責任者、告知事項、受領書及び契約条件の承認、委託者が記載されている。そして、ベンダ側の重要事項を説明する契約担当責任者が、重要事項説明書と関連図書を交付及び重要事項を説明し、委託者は、重要事項説明書を受領し告知事項と契約の条件を承認した旨の記載がされており、受託者からの契約全般の詳細説明を受けて合意の上契約の締結がなされる様式となっている。このように、契約合意をシステム基本契約書と重要事項説明書を分離し、情報システム取引での個別難解な事項を条文としてではなく、具体的作業内容として説明し、さらに重要と思われる部分については告知事項とすることで、ユーザ、ベンダ双方の契約の可視化を図るものである。

ベンダ側で契約締結にあたる責任者である上記の「重要事項を説明する契約担当責任者」とは別に、重要事項説明書の鑑部分及び各契約項目に、ユーザ側とベンダ側のプロジェクトの管理遂行について責任を有するプロジェクトマネージャとしての「責任者」及びプロジェクトの遂行について円滑な意思疎通を図るための連絡窓口としての「xx担当者」を明記するようにした。ベンダの組織体制、プロジェクトの規模、進め方によって、契約担当責任者とプロジェクトの管理遂行に関する「責任者」が同一の場合もあれば、営業担当者が契約担当責任者となり、技術担当者がプロジェクトの管理遂行に関する「責任者」としてなる場合がある。同様にユーザにおいても、代表者など契約締結に当たる責任者とプロジェクトの管理遂行について責任を有する「責任者」が同一の場合も異なる場合もあり得る。

さらに、各個別契約の具体的作業内容については、できる限り対応する共通フレーム2013該当事項を記述してある。共通フレーム2013をリファレンスとすることで、ベンダと再委託業者間や、マルチベンダ契約での解釈の相違を少なくするためである。20

さらに、表紙の告知事項では、情報システム取引におけるユーザとベンダの役割とともに協働の重要性を告知し、ユーザによる重要事項説明書の精査を促している。ユーザ、ベンダのコミュニケーション不足や協働がなされないことによるシステム構築のリスクを告知した上で、契約条件の確定と承認を得ることで、ユーザの詳細な検討と業務着手前の修正の余地を確保している。また個別業務ごとに、作業の概要、契約類型、契約条項と作業内容（範囲、仕様等）、納期又はサービスの期間、業務の完了、代金、損害賠償の上限、及びその支払方法を明確にしている。また、上流工程では、未決事項の記述欄を設け、ユーザの注意を促すように配慮した。

重要事項説明書の鑑部分の添付図書一覧は、構築システムに関わるすべての記録原簿としての機能を果たすようにし、提案書や見積書等のドキュメントをそのまま重要事項として採用し、重要事項説明書作成の負担を軽減することも可能としている。

上流工程の契約はカスタマイズを前提とした「A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）」、「B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）」と、パッケージソフトウェアのパラメータ設定や補完製品等での対応を前提とした、「C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル）」を策定し、それぞれに該当する2つのモデル取引を策定した。

■カスタマイズモデルとオプションモデルの特徴

モデル取引

カスタマイズモデル(別紙1)

オプションモデル(別紙2)

業務

対象システムの例

生産管理、管理会計等

制度会計、青色申告等

対象業務の汎用性

低い

高い

業務、システムの移行

ある

ある

カスタマイズ

検討範囲

比較的広い

比較的狭い

パッケージ本体の
モディファイ

ありうる

ない
（補完製品の選定、パラメータ設定、外部プログラムで対応）

関連ソフトウェアとの結合

密結合、疎結合

疎結合

既存ソフトウェア側の変更

小

小もしくはない

既存システムとの
結合工数

小

軽微もしくはない



■モデルと契約の関係

モデル取引

カスタマイズモデル(別紙1)

オプションモデル(別紙2)

契約

基本契約

パッケージソフトウェア利用コンピュータシステム構築委託契約書

個別契約

準委任

A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）

B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）

C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル)

D外部設計支援業務契約

請負

Eソフトウェア設計・制作業務契約

F構築・設定業務契約

準委任

G データ移行支援業務契約

H運用テスト支援業務契約

I導入教育支業務援契約

J保守業務契約

K運用支援業務契約



ある程度のプログラム開発が見込まれる場合は、カスタマイズモデルを選択し、プログラム開発が伴わない、または軽微であると見込まれれば、業務要件定義支援業務とシステム要件定義支援業務を分離することなく要件定義支援業務として、一定の手戻りを許容しつつパッケージの選定が行われる方がコスト的にも有利となる。これらの判断に苦しむ場合は、ユーザ、ベンダともに「取引・契約モデルの全体像（別紙1、別紙2）」を利用し、必要と思われるプロセスについて検討し、一定期間での成果とその後の契約内容の見直し特約を合意した上で、いずれかの契約を締結すればよい。

情報システムの信頼性・安全性を確保するためには、機能要件及び非機能要件の文書化が重要であり、こうした考え方もモデル取引・契約書第二一版を踏襲している。特に中小企業等ユーザに対しては、非機能要件としてのセキュリティ仕様をユーザのITリテラシに沿った形で策定、提示されることが望ましいが、ユーザにとってはセキュリティ対策の重要性が理解しづらく、また、個別仕様が難解である。そのため、パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル及びオプションモデル）の重要事項説明書において、告知事項としてセキュリティ対策を明示し、策定した仕様を提示するようにした。併せて、第一版追補版においては、JIS Q 2700121 に基づいたセキュリティチェックシート解説を策定し、個別仕様についてユーザの理解が促進されるよう配慮した。具体的には、セキュリティチェックシート解説で、技術的セキュリティ対策と相当する脅威の内容を具体的に例示し、脅威に対する対策を何も対策していない～高度な対策の実施までを4段階で示していた。ここでは、物理的なセキュリティなどユーザ自身が実施すべき内容を含めて、項目がを例示されていたしてある。これによって、ユーザは詳細な技術内容を知悉しなくても、セキュリティに対する仕様の脅威に対する強度や、堅牢さを把握することができ、コストや状況に応じたシステム仕様をベンダに求め、また、自社のセキュリティ対策を施すことが可能となる。ベンダは業務要件定義の策定段階で、セキュリティチェックシート解説に基づくセキュリティ対策の仕様をユーザに提出し、承認を受けて業務要件に組み込みセキュリティ仕様が策定されることが期待されていたものでとなる。また、データ移行支援業務と運用テスト支援業務においても、ユーザ自身の正誤又は可否判定を求める場合についての、ユーザの確認、精査、最終判断の必要性を告知し、相互の役割を正しく認識するよう配慮していたる。

なお、第二版追補版においては、情報セキュリティに係る最近の状況にそぐわなくなっていたセキュリティチェックシートを削除した。しかしながら、本モデル取引・契約書第二版追補版の主対象である中小企業ユーザにおいても、第二版に記載のセキュリティに関する説明が概ね当てはまる。すなわち、ITシステムへの適切なセキュリティ対策の実装は、企業やシステムの規模に関わらず重要なことであり、ユーザとベンダとは、それぞれの立場やIT成熟度に応じて必要な情報を示しつつ、リスクやコスト等について相互に協議することにより，システムに実装する「セキュリティ仕様」を決めることが必要である。第二版の作成時には、セキュリティの専門家から構成されるセキュリティ検討プロジェクトチームにおいて、Windows Active Directory環境を対象に、セキュリティ仕様を作成する際の脅威分析とその対策を検討するためのOS、デスクトップアプリ、ブラウザーのセキュリティ設定を検討するためのガイドライン及び当該ガイドラインを前提としたセキュリティ仕様策定プロセスの検討が進められ、それぞれ「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」（以下「セキュリティGL」）及び「セキュリティ仕様策定プロセス～「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」対応～」として策定された。そのうちのセキュリティGLの中に、第二版追補版が想定するシステム開発取引においても参考となる、最低限検討するべきデフォルト緩和策について記載されている。その内容を参考に、ユーザ・ベンダで協議の上、実装するセキュリティ仕様を策定することができる。特に、IT成熟度が低いユーザに対しては、ペンタが必要な説明を行うことにより、ユーザの適切な判断をサポートすることが重要である。

モデル取引は、ソフトウェア設計・制作業務及び構築・設定業務を請け負ったベンダが、保守業務契約、運用支援業務契約を締結することを前提としている。一次切り分け窓口を一本化し、ITの専門知識のないユーザの負担を最小限にするとともに、ベンダ同士の責任回避を防ぎ、保守、運用支援プロセスの処置の明確化を確保するためである。さらに、具体的なサービス品質を確保するため、SLA22合意書の添付の有無を重要事項説明書に設けた。SLA合意書では個別具体的な数値目標を明示し、また、SLM23の規定も明確化している。その上で、ハードウェア保守など、ベンダ自身がサービスを提供できない場合に対応するため、「再委託先の表示」を項目として設けた。

ハードウェアの販売契約についての重要事項は、個々のベンダによって内容が大きく異なることから重要事項説明書に組み込んでいない。ただし、業務要件定義や外部設計にあたって、カスタマイズの可否の検討や調査のために、ハードウェア、ソフトウェアの導入が必要となるケースがあるため、重要事項として機器、ソフトウェアの一覧を記述するようにしてある。この中では、ハードウェアの無償保証の条件や、補修用有償部品の保有期限等を明示するようにし、ハードウェアの保守の限界期限を相互に確認できるようにしてある。これは近年、ハードディスクやメモリなどの主要部品の規格が多岐にわたり、かつ、製品として入手可能な期間が短くなっているためである。一般的な電気製品や機械装置に比べ、著しく短い期間で規格の世代交代が進むことに理解を求めるとともに、システムライフサイクルに応じた情報投資を確保するためである。

モデル取引・契約書第二版追補版におけるモデル契約のタスクは、ユーザ、業界関係者、情報システム取引契約に精通した弁護士による議論を経た配置をとっているが、業務要件定義に至るタスクでは、プロジェクト体制によって順序が異なる場合もある。また、パッケージソフトウェアによっては、評価のためであっても有償で使用許諾契約の締結を求められる場合もあり、ユーザの一般的な商習慣と大きくかけ離れる場合もある。いずれも、ユーザへの事前説明と議事録等での合意をもってプロジェクトを推進することが望まれる。

モデル取引・契約書第二版追補版の主要条項の論点整理

（パッケージソフトウェア（候補）の選定支援における善管注意義務）

モデル取引・契約書第二版追補版の検討においては、いわゆる上流工程（業務要件定義支援及びシステム要件定義支援）におけるあるべきビジネスプラクティス及びそれを反映した契約文言の検討に時間をかけた。

まず、モデル取引・契約書第二版追補版が想定するビジネスの特色がパッケージソフトウェア（システムの構築に利用する第三者が権利を有するソフトウェア、SaaS/ASP）の利用にあること、パッケージソフトウェアはモデル取引・契約書第二版追補版における成果物となるシステムの技術的中核となるものであり、また、システムの利用に関連し、パッケージソフトウェアに関してはその固有の条件が適用されることからシステムの全体の利用条件にも大きな影響を与え、契約不適合責任等の法的問題の分野においても重要な意味をもつこと、そしてそれが下流工程である設計、構築・設定、保守、運用の契約条件に対しても大きな影響を与えるものであることを認識した。さらに、ITコーディネータや中小企業診断士などの専門家の参画による、上流工程のモデルの多様性を勘案した。

このことに鑑み、上流工程を「業務要件定義」「外部設計」などとするのではなく、過程でパッケージソフトウェアがどのような意味を持つかを検討し、その結果、「業務要件」に基づきパッケージソフトウェア候補の選定が、パッケージソフトウェア候補の詳細なシステム要件の評価に基づく最終選定によって、業務要件とパッケージソフトウェアのシステム要件などの「要件定義」が行われるものと認識し、それぞれの業務の名称をそれぞれ「要件定義支援及びパッケージソフトウェア候補選定支援業務」「パッケージソフトウェア選定及び要件定義支援業務」とした。そして、それぞれにおいてパッケージソフトウェア（候補）の選定業務について対応する条項を入れるべきとの判断を行った。次に、モデル取引・契約書第二版追補版が想定する中小企業等ユーザは、パッケージソフトウェア等に関する専門的知識を有するベンダに比べ、そのようなパッケージソフトウェアに関する知見に欠け、ベンダと対等な交渉能力がないものであること、しかしながらユーザの業務内容及びプロジェクトゴールを熟知しているのはユーザ自身であり、また上流過程における役割分担においてユーザがベンダに頼りきりいわば丸投げ状態を認めることはユーザとベンダのシステム契約についての理解の不一致を招き、こうした契約における契約条件の透明性・明確性の妨げとなることを認識した。

そこでモデル・取引契約書第二版追補版では、最終的にパッケージの選定を行う者をユーザとし、ベンダはユーザに対し、パッケージソフトウェアに関する情報提供をしつつ、採用すべきパッケージソフトウェア候補をユーザに提案する位置づけとしている。そして前述したモデル取引・契約書第二版追補版が想定する中小企業等ユーザのパッケージソフトウェアについての知見の不足に対応するために、当該推奨に係るパッケージの提案に関して、ベンダは業界で一般的に認められる専門知識とノウハウに基づく善良な管理者としての注意義務を負わせるものとした。また、これらの専門知識とノウハウに基づき、ベンダが適切と判断したときは、パッケージソフトウェア候補が存在しない、または、最適なパッケージソフトウェアが存在しない、ことをユーザに進言しなければならない、とした。「善良なる管理者の注意義務を果たした」かどうかは、情報処理技術に関する業界で一般的に要求される専門知識・ノウハウにもとづく注意義務を果たしたかどうかによって決定されるとした。すなわち、ここでの注意義務とは、自らの能力に応じた注意義務の程度という主観的な意味ではなく、業界において一般的・客観的に要求される注意義務を意味し、このような注意義務を欠くときは過失が認められることとした。ここで規定される善管注意義務は準委任契約におけるベンダの善管注意義務に重なるものであるが、上記したとおりパッケージソフトウェア候補の選定支援作業の重要性に鑑み、特に重複して記載している。

（契約不適合責任）

構築されるべきシステムは、パッケージソフトウェア、機器等のハードウェア、OS等の本件パッケージソフトウェア以外のシステム構成物から構成されるシステムである。かかるシステムについて稼働不良などの問題が起きたときに誰が責任を負うべきかの問題は、問題の切り分け自体ができるかの技術的問題、切り分けができたとして誰がどの部分について責任を負うべきかの法的問題を含め難しい問題である。

モデル取引・契約書第二版追補版では、パッケージソフトウェアについて、ベンダはその固有の契約不適合については責任を負わないものとした。パッケージソフトウェアはベンダ以外のものが制作、販売することが多く、契約不適合等の問題はそうした供給者とユーザとの間で解決すべき問題とし、ベンダはユーザがそうした問題を事前に知ること、分析、判断することの支援をするものとした。その結果、モデル取引・契約書第二一版と同様に、ベンダはパッケージソフトウェアの固有の契約不適合について知っていたか、重大な過失により知らなかったことでユーザに告げなかった場合にのみ責任を負うものとした。

次に機器等のハードウェア、OS等のソフトウェアについても、ベンダは責任を負わず、これらの問題についてもユーザと供給者との間で締結される別契約によって処理されるものとした。

（著作権の帰属）

新たに作成されたソフトウェアの著作権をベンダ、ユーザのいずれに帰属させるべきかについては、ベンダは作成したソフトウェアの再利用のために自己のものとして留保したいと考え、ユーザは自己の機密情報が含まれる場合の保護の観点などからベンダから譲り受けて、自己のものとしたいと考えている。モデル取引・契約書第二一版においては、社会的な生産効率の向上の観点などから、汎用性のあるプログラムについてはベンダに帰属させると共に、そのようなプログラムに関してベンダ帰属案、ユーザ帰属案、共有案が記載されている。モデル取引・契約書第二版追補版が前提とする取引は、パッケージソフトウェアを利用することとユーザが中小企業等であることなどに特色がある。

この観点より本論点を検討すると、まず、アドオン等のカスタマイズで新たに作成されるソフトウェアは前提となるパッケージソフトウェアの関連で作成されるものであり、当該パッケージソフトウェアの一般的機能となるべきものが、カスタマイズという形で先行して開発されることも多い。それゆえ、係る部分が将来的には他のユーザにも共通に利用できる部分となるケースもしばしばある。なお、ユーザがベンダから著作権の譲渡を受ける場合には、別途譲渡の対価を支払うことが要請されるため、そのような場合にはユーザの費用負担が増大する。他方、かかる部分にユーザの機密情報が含まれている場合にノウハウの流出防止など当該機密情報の保護をユーザが求めることは当然のことであるが、機密情報の保護のためには、著作権を取得しなくとも別途用意される秘密保持条項で対応できるものと考えられる。

以上のように、カスタマイズ等により作成されたソフトウェアの権利をベンダに帰属させベンダが他のビジネスにおいても再利用できる環境を整えていた方が、総体としては価格を低く抑えることができ、中小企業等が利用するシステムとして比較的合理的な価格で広く普及することに資する結果となると考えられるため、カスタマイズ等により新たに作成されたソフトウェアの権利は原則ベンダに帰属させることとした。

（再委託）

モデル取引・契約書第二版追補版においては、パッケージソフトウェアを利用したシステム開発の取引実態により適合するものとして、モデル取引・契約書第二一版第7条24【B案】を採用している。再委託の可否については、①再委託先の技術力についての保証がなくまた機密保持の観点からも原則禁止とし委託者の承諾を要するとすべき（原則禁止、【A案】）との考えと、②再委託を原則禁止としてしまうことによって業務の遂行における柔軟性が失われ結局提供される技術の質も効率も損なわれてしまうので原則自由とすべき（原則自由、【B案】）との考えの対立があり、モデル取引・契約書第二一版においても、両論が併記されている。

モデル取引・契約書第二版追補版が前提とする取引は、パッケージソフトウェアを利用すること、ユーザが中小企業等であることなどに特色がある。この観点より本論点を検討すると、そもそも多くの場合、第三者製品であるパッケージソフトウェアをシステムのコアの部分に据えるのであるから、再委託を厳しく制限することは現実的ではないこと、また原則再委託自由としてもユーザが要求するときは再委託先を開示させることとし、かかる再委託先を使うことを止めさせることに合理的な理由があるときはかかる再委託を止めさせることができるとすれば弊害も少ないものと考えられる。従って、再委託は原則自由としユーザが要求するときには再委託先を開示し、ユーザは合理的な理由があるときには再委託を中止できることとした。なお、かかる再委託中止に関連して委託料、納期に影響が出る場合には契約変更手続に基づいて行うことが必要となる。

今後の検討課題及びモデル取引・契約書追補版の活用について

（E-Learning等を活用した普及）

経済産業省及び関係業界団体は、E-Learningのトレーニングプログラムの整備、セミナーの開催等を通じてモデル取引・契約書追補版に基づく取引慣行の普及に努める。

（IT取引の適正性を担保するための資格制度の検討）

ITの専門知識を有しないユーザと業として情報サービスを提供するベンダの間では、モデル取引・契約書追補版に基づき契約事項・取引内容について真に合意に至ることが重要である。他方で、モデル取引・契約書追補版を形式的にしか利用せず、ITの専門知識を有さないユーザが実質的に合意していないにも関わらず、合意しているとの外観を整え、ベンダ側の免責の材料として使われる恐れもある。そうした慣行を防止する観点から、経済産業省及び関係業界団体はユーザの視点からのモデル取引・契約書追補版の活用のガイドの整備や、十分なITと法務の知識を有し第三者としてモデル取引・契約書追補版に基づき取引を適正に行われることを担保する専門家を認定する資格制度の創設を含めた総合的な環境整備・制度設計の検討を進める。

（ユーザ・ベンダ間の役割・責任分担の明確化）

　情報システムの信頼性の向上のためには、契約等によるユーザ・ベンダ間の役割・責任分担の明確化が重要である。他方で、ITを巡る紛争については、裁判例及び判例が十分に蓄積されておらず、契約上の文言の個別事例への適用についての予見可能性が小さいとの指摘がある。このような状況を改善するために、経済産業省及び業界団体は指針や準則の策定等も含めた取組について検討する。

（再委託先を含めた品質保証体制の確立）

我が国のソフトウェア産業の生産性については、欧米と比較して高くないといわれており、その原因として「労働集約的な受注ソフトウェア比率が高いこと」「中小企業等が中心で重層的な下請け構造」との指摘25がある。モデル取引・契約書追補版においては、パッケージソフトウェアでの開発であることから、再委託先についてはベンダの裁量を認めることで、柔軟なプロジェクトの推進を確保した。他方、ユーザは、開発形式を問わずプロジェクトに参画する情報サービス企業の品質保証、個人情報保護、情報セキュリティ等の管理体制について、重大な関心があるところであるが、再委託に関する開示情報は一律でなく、品質保証基準も定めがない。今後、業界団体を中心とした元請けと再委託先の品質保証体制の確立及び情報開示について議論が望まれる。

（システム性能の適正性及びシステムライフサイクルを担保するための情報開示）

システムの応答や処理速度などのシステム性能を確保するためには、ハードウェアの適正な選択が重要である。一方、OS、ミドルウェア、パッケージソフトウェア、デスクトップアプリケーションがそれぞれ、CPU速度、必要メモリ、ディスク容量などの動作環境を提示しているところであるが、これらは、ベンダの独自裁定によるものであって、一定基準に沿った応答性能を保証するものなのか、最低限の動作を保証するものなのかは明らかでない。さらに近年、OS、ミドルウェアの様々なバージョンが混在する状況であり、アプリケーションソフトウェアの動作に適切なハードウェアを選択する方法論は確立されていない。

他方、システム構築からシステムの廃棄に至る期間は、ユーザの企画するビジネスモデルなどに深く影響する。激しい市場競争によって、高機能化、多機能化を重ねる情報システム製品、OS、ソフトウェアは、短期間で世代が交代する場合もあり、その結果、補修用部品の提供やサポート期間が、ユーザが想定する償却期間よりも短い期間で打ち切られ、システムの維持が困難となるケースが見受けられる。

今後、メーカーや業界団体等において、ソフトウェアの適正な動作基準の策定とそれに基づくハードウェア要件の開示、また、サポート期間等を考慮したうえで適切にシステムの企画・構築ができるよう、サポート・保守に関する情報の開示等の検討が望まれる。

モデル取引・契約プロセス

概要

企業の規模を問わず、経営の情報システムに対する依存度が高まることにより、システムの信頼性の低下が経営に打撃を与える可能性は比例する。信用や取引環境、財務的な安定度を考慮すると、中小企業等の情報システムの構築から運用、保守に至る信頼性確保は、企業存続のための重要な要件の一つと言える。

システム構築の核となるパッケージソフトウェアは、パッケージソフトウェア製造会社が利用状況と環境を想定し、一定の目的を達成するためのプログラムの体系であることから、構築稼働に至る時間を大幅に節約できるメリットがあるが、ユーザの目的やそれに沿った機能評価に失敗すると、信頼性のみならず適合性をも損ない、経済的な損失を招くことになる。

信頼性を確保し、業務に適合した情報システムを構築するためには、ユーザ自身が自社の事業、業務システムを分析し、パッケージの選定にあたることが重要である。反面、中小企業等ユーザにとっては、自社の業務分析や、パッケージに対する知識、機能評価を自ら自己完結することは困難な場合があり、それに代わる能力を外部に委託する場合がある。また、多くは情報システム構築の経験が少ない、もしくは前回の情報システム構築から年月が経過しているなどにより、近年のIT関連情報に詳しくなく、情報システム取引に関わる法的知識に乏しいことが想定される。

これらを背景として、パッケージ選択に至る上流工程での、ユーザとベンダの役割、責任、義務を明確にするとともに、ベンダ以外のITコーディネータを始めとする外部専門家やコンサルタントが上流工程を担うことを想定する必要がある。

一方で、完成した情報システムの操作運用はユーザが担い、保守については、アプリケーション部分がパッケージソフトウェア製造会社と、モディファイ、アドオンを開発したベンダに分かれ、場合によってはOS製造会社、データベースエンジン製造会社からの保守を受ける必要があり、ハードウェアは各製造会社又は製造会社と契約している保守会社が提供することになる。さらに、通信インフラが加わることになると、一旦、障害が発生した場合には、ベンダ同士ですら障害切り分けや原因の究明が困難となる。

情報システムの取引、構築、維持はこのような複雑かつ多岐に渡る知識と契約実務を、専門的な知識を有しないユーザに要求するため、システムの提供側であるベンダは情報の非対称性に十分に配慮しなければならない。中小企業等における情報システムの信頼性確保のために、これら情報の非対称性の解消を観点として、モデル取引・契約書第二版追補版でのモデル契約プロセスの全体構成、共通フレーム2013とモデル契約の関係を論じる。

モデル契約プロセスの全体構成

（前提とする中小企業等ユーザ像）

対等な交渉力を有しない中小企業等を以下のように想定する。

■LAN＋Internetへの接続はできており、日常的に電子メール、財務会計、販売管理等のパッケージソフトウェアを利用している。

■最新の情報システム関連動向、パッケージソフトウェア関連動向は把握しておらず、システムの価格や妥当性を正確に評価することができる人材を有していない。

■情報システム資産の管理はなされておらず、情報システムに関連するドキュメントは整備されていない。

■取引上、相手先の機密情報や個人情報を取り扱う場合があるが、セキュリティ確保のための措置はとれていない。

■競争優位のための情報システムの役割を自ら構想することは困難である。

■バックアップや保守体制の確立、システムライフサイクルの認識などが事業継続に多大な影響があるとは承知していない。

■システム構築の検討に入る場合の多くは、システムの老朽化や処理能力への不満である。

■法務に精通した担当者が不在である。

■ITに精通した担当者が不在である。

ユーザは業務及び情報システムの課題や問題点に対する説明能力に欠ける。一方で、ベンダが限られた時間と予算の中で、最適な情報システムを提案することに心がけたとしても、ユーザの業務の特性や、現行システムへの不満、業務上の課題をすべて知悉することは困難である。このように、初期段階ではユーザとベンダのシステムに対する情報量と質ともに大きなギャップがあることを前提に、契約締結に至る必要がある。

システム構築の検討に入ったユーザは、ベンダに対して現状と保守、運用を含めた全体予算や人員、リテラシについて早期から可能な限り情報開示する事が望ましい。また、ベンダはユーザに対して、情報システム取引の全体の流れやプロセスの留意点、自社の管理体制を説明することが望ましく、ベンダの選定は、コンサルティング会社選定のためのチェックリスト等を参考に、予算、実績、技術力、経営安定度、委託を含めた業務管理能力、秘密及び個人情報保護の管理体制等を総合的に判断すべきである。

これらを前提に取引モデルを解説する。

（別紙1パッケージカスタマイズ 取引・契約モデル）

A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）

企画、業務要件定義、パッケージソフトウェア候補選定が本契約の具体的作業内容である。情報取引に不慣れなユーザは費用対効果を判断できないため、コストに対して不釣り合いな要求を行う場合がある。このプロセスでは適宜RFI26に基づく価格調査や保守・運用を含めた他社事例を取得することが重要である。パッケージの機能・制限事項の比較や、複数のパッケージを想定し導入後の運用シミュレーションを重ねることで、費用対効果や実現すべき要件の優先順位付けが可能となる。

企画においては、業務の新全体像、業務モデル、システム方式等の策定を求めている。ここでいうシステム方式の策定は、開発内容とアーキテクチャ、データベース、サーバ、ネットワーク構成概要を明確にすることがゴールである。企画段階で具体的な画面イメージや処理の流れを共有し、業務の流れとシステムの動きを策定し、要件の漏れや先送りを防止することを期待している。

業務要件定義については、機能要件とセキュリティを含む非機能要件の定義を行うものとし、さらに、パッケージ候補選定にあたっては、業務要件に対する機能適合評価のみならず、使用許諾契約の内容及び制限事項、SaaS/ASPにおいてはSLAの内容及び制限事項、保守性（バージョンアップポリシー、OSのバージョンアップへの対応等）についての評価を求めている。ここで注意が必要なのは、パッケージ候補の選定だけでなく、適合しない又は適合性が低くパッケージソフトウェア利用の合理性がないと判断される場合である。前述の通り「A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）」、「B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）」では、適切なパッケージソフトウェアがない場合に備え、パッケージ候補、又はパッケージが存在しないことをユーザに進言することも、ベンダの善管注意義務としている。ベンダは、適切なパッケージソフトウェアが存在しない理由または回避策や代替案を提示し、ユーザが最終的に判断するに十分な情報の提供が必須となる。

「A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）」でのセキュリティに関する要件定義は、第一版追補版においては、セキュリティチェックシート等を活用し、ユーザに対して具体的な脅威とあるべき対策を提示し、業務や規程で対応するものと技術で対応するものを検討し、業務要件定義で承認を受け次工程で具体的なシステム仕様が策定されるものとしていたる。従って、「B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）」の契約締結の際に重要事項説明書の＜告知事項＞として「要件定義におけるセキュリティ仕様」をユーザに確認し、これを基に具体的なシステム要件等の検討に入ることを前提としている。

最終報告書となる業務要件定義書は次の工程であるパッケージ選定及び要件定義支援契約での利用を前提に、その内容をユーザが評価しなければならない。特に、ユーザは経営層のみならず現場のオペレータを含め、機能要件並びに非機能要件について十分な検討をが必要である。セキュリティ要件については、システム要件定義支援業務の＜告知事項＞として次の工程で確認事項とされるため、十分な討議と合意が求められる。

業務要件定義書の評価にあたって、ユーザはITコーディネータ、中小企業診断士、システム監査人等の専門家の助言を得ることが望ましい。その際は、共通フレーム2013を用いて相当する業務を示し、用語や業務内容の違いによる誤解を起こさない等の配慮が望まれる。

「A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）」を担当するベンダと、次工程を担当するベンダが異なる場合は、変更管理手続を用い、特約条項として最終報告書提出後も期間を定めてユーザとそれぞれのベンダの連絡協議会を設け、疑義の解消にあたるべきである。また、業務要件の未決事項はシステム化することが不可能となるため、その取扱いについて合意し、以降での対応方法を決定しなければならない。ベンダが異なる場合は、最終報告書に未決引き継ぎ事項を明示する。



B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）

要件定義支援業務は、業務要件定義書に基づき実施されるため、パッケージソフトウェア選定及び要件定義支援契約の重要事項説明(2) 具体的作業内容で、該当する文書を明示する。契約締結にあたっては、業務要件に対するベンダの疑義や不明点が解消されていることが望ましい。業務要件定義を行ったベンダが同一ベンダであっても担当者が異なる事は一般的であるので、連絡体制、疑義に関する解消方法等について、特約条項で定めるのが良い。

パッケージソフトウェア選定支援の各作業は、以降のあらゆる作業、業務に重大な影響を与えるため、重要事項説明書では各作業単位で報告書提出期限を定め、文書化を求めている。将来の保守性向上や信頼性確保に配慮し、さらに詳細な説明を加えることが望ましい。特に移行がある場合、現行システムから新システムへの移行のために、想定以上のコストが発生する場合もあるため、システム要件評価には移行要件を含むとした。前述の通り、最適なパッケージソフトウェアが存在しない場合のベンダの善管注意義務はユーザの十分な理解が必要である。

パッケージソフトウェアのモディファイの範囲を検討や、外部設計をするために、パッケージソフトウェアの使用許諾契約を締結しなければならない場合がある。業務要件定義でパッケージ候補が絞り込まれており、あらかじめ使用許諾契約締結が必要とわかっている場合は本件契約時に、「パッケージソフトウェア選定及び要件定義支援業務契約の重要事項(3)ソフトウェア、機器、ドキュメントの明細及び納入場所」を記載し、実務にあたることとなる。また、パッケージ候補が複数あり、本件契約で最終候補が絞り込まれた後、使用許諾契約締結が必要となった場合は、同様に「パッケージソフトウェア選定及び要件定義支援業務契約の重要事項(3)ソフトウェア、機器、ドキュメントの明細及び納入場所」を用い、変更管理規定に則って必要なソフトウェア、機器の納入、販売等を行うことになる。

前述のように、要件定義の重要説明の一環として、「＜告知事項＞要件定義におけるセキュリティ仕様」の記述を設けている。業務要件定義支援業務でユーザが合意されたセキュリティ要件を詳述し、それに基づいたシステム要件を定めるとともに、ユーザの注意喚起を図るためである。なお、データのバックアップについては、日常のデータバックアップ作業実施はユーザの責任とし、ベンダは機能の実装を担当するものとしているので、留意されたい。

パッケージ選定では、後述のデータ移行支援業務の重要事項を参照し、データ移行について仕様を定めることが望ましい。移行要件は、移行するデータによって見積と運用準備、システム稼働に関するスケジュールに多大な影響を与えるためである。

業務要件定義において選出されたパッケージソフトウェア候補が、すべての要件を満たさない場合に、予算を超さずにモディファイやアドオンによって要件を実現できれば、ユーザの満足度は高まるが、反面、システムの保守性、信頼性は低くなる。また、モディファイにあたっては、パッケージソフトウェア製造会社のサポートや保守体制、将来に渡るバージョンアップ時の対応、経営状況などを十分に考慮する必要がある。

本件契約の具体的成果としてパッケージソフトウェアが選定され、推奨ハードウェア構成等が決定される。さらに、既存システムとの接続等がある場合、その範囲や既存システム側の変更のための仕様をどうするか、なども重要な決定事項となる。次工程である外部設計では、要件の追加や変更が頻発しない完成度を期待している。一連の成果はユーザが最終的な判断をするものとされるが、ベンダの作業は「情報処理技術に関する業界の一般的な専門知識及びノウハウに基づき善良な管理者の注意を持って行うもの」とされている。最適なパッケージソフトウェアが存在しない場合を含め、ベンダの慎重かつ的確な作業と説明責任が求められていることに留意されたい。



（別紙2パッケージオプション取引・契約モデル）

C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル）

この契約は財務会計ソフトウェア等で、不足する帳票を表計算ソフトウェア等で補うような、パッケージソフトウェアのモディファイやアドオンがない場合を想定している。パッケージソフトウェア本体のパラメータ設定および補完製品として販売されている補完製品の適合性をもっとも重視し、作り込みは最小限にすることが主眼であるといえる。小規模企業の財務、販売、人事管理などが相当するであろう。他方、いかに企業規模が小規模であろうとも、何らかの外部プログラムを作成するとなれば、一定の分析と文書化は必須である。従って、プロセスが一部省略されていても、主要な項目については、「A要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）」、「B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）」と変わることはない。プロセスの途中で、＜告知事項＞要件定義におけるセキュリティ仕様がユーザに提示され、承認されることに留意する必要がある。

主要なポイントは前述の契約と変わることなく、それを一つの契約で実施しているところにある。外部設計は含んでいないが、外部プログラムの要件策定に当たっては表計算ソフトウェア等を実施に使用し、画面をその場で作り込んで、全体の流れやイメージをユーザにつかんでもらうことが重要である。

また、パッケージソフトウェアの補完製品選定においては、カタログ等でのスペックでは実現可能となっていても、実際には複数の手順を重ねて実現されるといった場合も散見される。補完製品や外部プログラムで構築が困難となった場合は、変更規定を利用し、契約の範囲を拡大し「B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）」への変更もあり得よう。

情報システムの信頼性確保は選定するパッケージソフトウェア、補完製品の適合性と使用許諾契約、保守契約の内容に依存することになる。パッケージソフトウェア候補の業務への適合性が低い場合、プロジェクトの中止以外に、コスト制限を解除できれば以下の選択肢が考えられる。

(1) 契約を検討し直し、モディファイ、アドオン開発に切り替える
(2) 外部プログラムの作成を行う
(3) 業務をパッケージソフトウェアにあわせシステム化する
(4) 優先順位を下げシステム化をしない

業務システムの信頼性や業務全般の見直しという視点からはどれも正しい選択とは言い難い。さらに、ユーザのリテラシやモラルも大きく関与するところであり、パッケージソフトウェアの適合性が低い場合の戦略は、ベンダだけでなく、ユーザの自立的な判断が重要であるといえる。実際の業務要件の決定にあたっては、ベンダがユーザの環境を総合的に勘案するとともに、パッケージソフトウェアの導入事例を中心に、パッケージソフトウェアの特色を活かした利活用の実例をユーザ、ベンダと協働で分析し、ユーザが自主的にシステム化の優先順位を決定することが望ましい。スパイラル的な検討を重ねることによって、プロジェクトゴールの大幅な修正もありえることを契約時点で確認するとともに、いたずらに期間が費やされることのないように、進捗管理の方法を具体的に合意することが重要である。



RFPについて

上流工程の契約終了時点で、外部設計支援業務、ソフトウェア設計・制作業務、構築・設定業務を異なるベンダに委託する場合は、最終報告書もしくはRFPを提示し、詳細見積を取得することとなる。RFP作成を依頼した場合はRFPに対する疑義解消のための特約を結び、本件契約の業務を受託したベンダによるRFP説明会を開催するのが望ましい。個別にRFPを説明するのではなく、後工程を受託しようとするすべてのベンダの参加を得て、十分な質疑応答を実施することで内容の共有がはかれ、疑義や用語定義の相違などを解消することができ、より精度の高い見積を得ることができるようになる。特約が無くとも複数のベンダから多数の疑義が生じ、または見積作成が困難とされた場合は、業界の一般的な善管注意義務を果たしていない事となり、最終報告書を作成したベンダの債務不履行となる可能性がある。

既存システムとの連携がある場合は、既存システム側の変更を含むのか、他のベンダがそれを担う場合は、最終的にどのベンダが接続、連携部分の責任を負うのかなど、ベンダ間での調整が必要となる。複数のベンダが参加する場合は、ユーザを含めた参加者全員の役割と責任、指揮命令系統を明らかにし、接続部分の成果や品質に対して無責任体制とならないようなプロジェクト体制の確立が求められる。RFPを提示されたベンダのプロジェクトでの役割と責任が明瞭となることが求められる。

システムの大きさ、範囲によってRFP提示から見積提出までの必要な期間は様々であるが、あまりに期間が短いと当然のことながら見積精度は劣ってくる。問い合わせの対応を含め、一定期間を見積作業のために確保することも信頼性確保につながることに留意されたい。



運用手順書、利用者文書について

要件定義書で定義された機能要件はこれ以降ソフトウェアに実装されるが、利用者のための運用手順をどのように規定するか、運用マニュアルをどのように作成するかなど、実運用にかかる作業を最終的に取り決める必要がある。外部設計、ソフトウェア設計・制作業務で実装されたソフトウェアと実際の業務とのすり合わせのプロセスは、H運用テスト支援業務契約で(35)運用にかかわる作業手順の確立として定義されているが、本来はソフトウェア制作と並行して検討、策定されるべき重要プロセスである。要件定義業務から開発プロセス移行にあたっては、これら運用手順の確立について、ユーザの業務規模、運用の複雑さに応じて、しかるべき方策を定めることが望まれる。特に、バックアップ作業については、その範囲、手順、世代管理等について、ユーザの能力に応じたベンダの十分な配慮が必要である。また、開発プロセス以降での各プロセスにおいて、利用者向け文書の作成のための作業や役割について、検討されることが望まれる。



小規模システムへの適用について

これらパッケージソフトウェアを活用した契約モデルは、共通フレーム2013に則りプロセスと契約を分離したモデルであるが、小規模システムで帳票の追加でユーザの要望に対応できるケースや少額取引では、上流工程において要件定義と外部設計を一つの契約で行うことも考えられる。また、業務要件定義の一部がベンダの営業提案で無償で実施され、パッケージソフトウェアとベンダが絞り込まれた状態で、(16)「APIの実現性の確認」(17)「パッケージソフトウェアの選定と要件定義」(22)モディファイ、アドオンの範囲の確定、及びそれに伴うユーザI/F・他システムI/F設計」を契約し、その後、確定見積を取得し、システム構築・設定とソフトウェア開発をする場合も想定される。このように契約モデルに適合しない取引においても、信頼性確保の観点から、重要事項説明書を活用しベンダの十分な説明責任と善管注意義務が果たされ、正しい要件定義がなされることが望まれる。



D　外部設計支援業務契約、E　ソフトウェア設計・制作業務契約、F　構築・設定業務契約

開発工程は、外部設計支援業務と、内部設計にあたるソフトウェア設計・制作業務である。ここでの外部設計支援業務は、画面設計というプロセスの名の下に要件を抽出するということは想定していない27。画面のイメージや画面遷移は十分に検討され、要件定義書を基にすれば、改めてユーザの業務分析を行わなくても外部設計ができる完成度の要件定義書が存在していることを期待している。ユーザがシステムと業務の動きをフローチャートや画面のデザインだけで理解できず、外部設計で要件を定義することも想定されるが、外部設計支援業務での要件の多大な追加や変更の多発は前工程の失敗を意味する。

RFPに基づき詳細見積が得られた段階で、以降の業務を担うベンダの選定が行われる。モディファイ、アドオンが伴う場合は、ソフトウェア設計・制作を実施したベンダに保守を依存することとなる。また、サーバ、クライアント、ネットワークの設定等の構築・設定業務契約と既存システムからのデータ移行支援業務、保守業務、運用支援業務は、運用を含めた信頼性の観点から分離することなく同一のベンダと一貫して契約することが望ましい。それぞれの業務を担当するベンダが異なる場合は、いずれかのベンダを主担当としてプロジェクトの推進調整、進捗管理を担わす必要がある。

RFP又は要件定義書等で示された推奨ハードウェア構成については、外部設計段階で、十分な検討と確認が必要である。万一、性能等を確保できないと判断された場合は、ユーザ及びRFPを担当したベンダへの確認と疑義の解消が必須である。将来の処理増大に伴うスケールアップ、スケールアウトの拡張構成など柔軟性の確保と、稼働時点で過少・過剰設備とならないよう細心の注意をもってハードウェア構成がなされるように、ユーザとプロジェクトに参加しているベンダの検討、合意が望まれる。

ベンダの選定においては、コストだけでなくプロジェクトの管理体制、保守体制を評価すべきである。仕様書に基づいてプログラムを制作する技術と、制作されたプログラムを将来に渡ってメンテナンスするための技術はいずれも別のものである。極端にコストが安い場合は、十分に管理面の評価を行うべきである。

外部設計支援業務は重要事項(2)具体的作業内容で、要件定義書、作業体制、外部設計検討会、委託先等を記述する。(3)パッケージソフトウェアの表示で、バージョン、リビジョン、保守やサポート体制について詳述し、その時点で判明している契約不適合等があれば記載しておく。(4)設計書、付属文書の一覧で、作成する業務フロー、システム構成、実態関連図などの作成する文書を記述する。特に、外部設計検討会は作成文書に基づきインターフェースや基本設計等をユーザ、ベンダが合同で検討評価するものであり、業務の中核をなすものである。ベンダは、作成する文書の内容を詳しく説明するとともに、どのような作業をもとに外部設計検討会で何を決定するかを契約時点で明らかにし、外部設計検討会の成果と品質について十分に合意すべきである。当然のことながら、機能要件、非機能要件に関する疑義解消は極めて重要である。機能要件、非機能要件の最終確認を実施し、ユーザは、ベンダに対し必要な回答、情報提供が必要である。準委任契約であるため、ベンダの善管注意義務が課せられていることに留意する。また、成果物の契約不適合については、パッケージソフトウェア固有の契約不適合はパッケージソフトウェア製造会社とユーザの間で解決されるものとし、モディファイ、アドオン部分の契約不適合は、要件定義書、関連文書との不一致の場合、修正責任を負うこととなっている。この場合、ユーザが要件定義書、外部設計書に記述されていない操作を行った場合の不具合が問題となる。契約にあたってベンダは要件定義書に基づく外部設計上の不明点を十分に解消し、設計にあたるとともに、表記にない場合に備え、操作規約28、開発標準規約29等をユーザと合意することが望まれる。

ソフトウェア設計・制作業務は、重要事項(2)具体的作業内容で要件定義書、外部設計書、開発体制、委託先等を記述する。特に、ベンダの出荷テストである適格性テストについては、テスト体制、合格基準、ユーザデータの仕様の有無についてユーザ、ベンダが合意する必要がある。テスト体制の環境が異なる場合、ベンダ出荷では合格、ユーザ環境では不合格となるケースが想定されるためである。定められたテスト期間で、ユーザが適格性テストを実施し、検収が行われる。期間については、ユーザの受入体制を考慮し決定する。(3)パッケージソフトウェアの表示で、バージョン、リビジョン、保守やサポート体制について詳述し、その時点で判明している不具合等があれば記載しておく。(4)納入物の明細で、納入されるプログラムのほか、物理データ設計書、入出力詳細設計書などの作成する文書を記述する。また、納品形体についてはハードウェアとともに納品するか、個別に承認事項や検収がある場合はその条件を明示する。

構築・設定業務は最終的な納品、現地調整作業と、場合によっては既設のシステムとのシステム結合等がなされる。従って、作業によってはネットワーク設定変更で電子メールやWebへのアクセスが一時的に制限される場合や、電源の関係上、既設の機器を一旦停止するなどの場合がある。構築・設定業務契約の重要事項(2)具体的作業内容で、「関連するシステムの停止等の条件」を明記し、ユーザの業務への影響をあらかじめ合意することが望ましい。さらに、他システムの結合がある場合、ソフトウェア設計・制作業務でシステム結合を実施するか、構築・設定業務で実施するか、結合される側の設定等を含むか、システム結合の際の障害切り分けを含むかなど、業務の範囲と責任体制が明らかになるように(2)具体的作業内容で記述する。構築・設定に関する仕様書、テスト仕様書がある場合は、その仕様書を付属文書として添付し、実施内容を説明しなければならない。構築・設定に関する仕様書と実作業の乖離があった場合、保守、運用に備え、また、運用マニュアルや利用者文書作成においてそれらが反映できるよう、構築・設定業務設定報告書において実際の設定内容が記載され、ユーザに承認されなければならない。仕様との不一致は「契約不適合」となり修正請求を受けることとなるので留意する。



G データ移行支援業務契約

データ移行支援業務は、重要事項「パッケージ候補のシステム要件評価」において移行要件を含むとしてあり評価済みであることから、要件定義に基づく仕様に基づき作業が実施される。データ移行支援業務の重要事項(2)及び(3)具体的作業内容で「移行するデータの範囲」、「移行のための抽出作業」、「移行のための変換作業」、「新システムへの移行」を詳述するが、仕様が記述できない場合は、相当するシステム要件定義書等を指定する。作業に伴うデータのバックアップ等は付帯事項として、移行に伴う現行システムの停止などは特約条項として記述する。

プログラムの納品は、ベンダ側で仕様書に基づく適格性テストを実施した後に納品し、ユーザ側でも同様の適格性テストを実施することを想定している。オープンシステムでの開発は開発環境を全く同一にすることが困難な状況があるためである。構築・設定業務においては、システム結合に備え、仕様書に定めたテストを実施することを想定している。また、業務要件、システム要件に定められたセキュリティ設定は十分な配慮が必要であり、運用において多大な影響を及ぼすため、現場での設定の修正や変更があった場合の変更承認や文書化のルール作りが重要となる。適格性テスト及び構築・設定業務設定報告書でのセキュリティ設定の確認は、ユーザの検収プロセスを含めたチェック体制を検討すべきである。



H 運用テスト支援業務契約、I 導入教育支援業務契約締結

運用テスト支援業務は、直接実運用に供する実運用環境での実施を想定しており、実際の利用者が実施することを想定し、準委任契約としている。実際の利用者がテストを実施することで、利用者文書の改訂や問題の発見につながるためである。テスト実施にあたっては、運用にかかわる作業手順が確立されている必要がある。要件定義書、外部設計書、構築・設定業務報告書等の文書を検討し、実際に運用に資する文書を作成し、その文書を基に、テスト仕様書の策定がなされるべきである。

運用にかかわる作業手順の確立では、日次業務開始から終了、月次、年次など期間特有の処理、停電や異常終了した際の対処方法、記憶領域が不足した場合の対処、バックアップ及び復旧の手順、OSやアプリケーションの修正プログラムの適用がなされた場合など多岐にわたる。併せて、顧客データの一括出力やマスタデータの登録変更など、業務上の権限管理や個人情報、セキュリティに関わる事項についての運用手順、利用者文書は、情報管理規定等の社内規則との整合性も確認されなければならない。また、ウイルスが発見された場合の対応手順や運用にかかる問い合わせなど、運用支援業務との関わりを含めて総合的に検討、策定されることが望ましい。

導入教育支援業務は、個別の操作指導、集合教育、E-learningなどさまざまな提供方法が想定される。また、ユーザのリテラシによって内容が大きく異なることが予想されるため、ユーザリテラシについての事前の合意が重要である。



J 保守業務契約、K 運用支援業務契約

保守業務契約については、外部設計段階やソフトウェア設計・制作段階でパッケージソフトウェアを導入した場合にはすでに開始されている場合がある。いずれも、SLAに基づく保守業務内容の事前合意が重要である。また、ネットワークを含むシステム全体の障害切り分けを委託する場合は、保守業務契約の重要事項(1) において、保守業務の範囲とともに不具合の調査費用についての取り決めが必要となる。ネットワークによって導入したシステムの設定がそれ以外のシステムに影響を及ぼす場合があり、またその逆の例もあり、ユーザとベンダの争いの原因となる。

保守業務で交換された故障部品は製造会社に戻され、原因の究明や保守用部品として修理、再生されるのが一般的である。このため、交換された故障部品はベンダに無償で譲渡される規定としている。この際、個人情報を含んだハードディスクが故障した場合、個人情報の漏洩につながるおそれがあるとして、ユーザが故障部品の譲渡を拒むケースがある。プライバシーマーク等を取得しているユーザにおいては、個人情報保護規定と保守業務契約の事前の合意との関係に留意する必要がある。

契約条項、告知事項において、日常のデータのバックアップ作業はユーザ責任としており、ベンダはバックアップがないことによって生じる損害賠償等の責めに応じないとしている。データはユーザ資産であり、ユーザが正しく資産を保管することは当然のことであり、また、ベンダは、データの正当性、正確性について、最終的な判断ができないためである。ベンダはバックアップの重要性について、詳しく説明を行い、ユーザの注意喚起をはかる必要がある。

運用支援業務は、操作、運用に関わるヘルプデスク業務や、機器の動作監視、ウイルス除去といった、直接運用に関わる業務ではなく、周辺の支援業務を想定している。当該業務についても保守契約同様にSLAを締結し、支援業務のサービス提供の具体的な内容を取り決める必要がある。

共通フレーム2013とモデル契約の関係

共通フレーム2013とモデル契約の関係を以下の表にまとめた。

別紙1パッケージカスタマイズ 取引・契約モデル

共通フレーム2013

取引・契約モデルのフェーズ

契約

基本

重要事項説明書

2.1 企画プロセス
システム化構想の立案、システム化構想の承認
システム化計画の立案、システム化計画の承認

(1)事業要件定義

(2)プロジェクトゴールの策定

(3)要求品質の明確化

(4)パッケージソフトウェアを利用し実現する業務の新全体像の作成（2.1.1.2.6～2.1.2.2.7該当）

(5)パッケージソフトウェアベンダに対してシステム、パッケージソフトウェア等の情報提供要求、試算見積依頼（RFI）

(6)ユーザに対しRFIに基づくシステム、パッケージソフトウェア等の情報の提供、試算見積の提示

パッケージソフトウェア利用コンピュータシステム構築支援契約書

A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）

2.2 要件定義プロセス
利害関係者の識別、

要件の識別、

要件の評価、

要件の合意、

要件の記録

(7)業務要件定義（2.2.3.1要件の抽出）

(8)ベンダに対しパッケージソフトウェア候補選定のための情報提供依頼（RFI）

(9)ユーザに対しRFIに基づくパッケージソフトウェア関連情報の提供、概算見積の提示

(10)パッケージソフトウェアの機能要件、非機能要件、使用許諾契約(利用条件、保守等) 、SaaS/ASPにおいてはSLAの検討

(11)パッケージソフトウェア候補の選定

(12)業務要件及び適合するパッケージソフトウェア候補の報告書の提出

(13)受入れ

(14)使用許諾によってはパッケージ、OS、ハードの導入及び保守の開始

(15)パッケージ候補のシステム要件評価
(16)APIの実現性の確認（候補パッケージのAPI、既存システムとの接続性等の評価）

(17)パッケージソフトウェアの選定と要件定義、システム要件定義と評価

B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）

2.3 システム開発プロセス
システム要件の定義、システム要件の評価及びレビュー、

システム方式の確立、システム方式の評価及びレビュー


2.4 ソフトウェア実装プロセス
ソフトウェア要件定義、ソフトウェア方式設計

(21)使用許諾によってはパッケージソフトウェア、OS、ハードウェアの導入及び保守の開始

(22)モディファイの範囲、アドオン等の外部設計範囲の確定、及びそれに伴うユーザI/F・他システムI/F設計

(23)外部設計書の承認(受入れ)

D外部設計支援業務契約

2.4 ソフトウェア実装プロセス
ソフトウェア詳細設計、

ソフトウェア構築、

ソフトウェア結合、ソフトウェア適格性確認テスト、

システム結合、テスト準備及びシステム結合の評価、

システム適格性確認テスト、

ソフトウェア導入、受入れ支援

(25)ソフトウェア設計

(26)モディファイ、アドオンの設計、プログラミング、ソフトウェアテスト

(27)適格性確認テスト、監査、ソフトウェア導入

(28)納品

(29)検収（受入れ）

Eソフトウェア設計・制作業務契約

(30)構築・設定業務（機器・OS等の設定、納品）

(31)システム結合、テスト

(32)検収（受入れ）

F構築・設定業務契約

3.1 運用プロセス
運用テスト及びサービスの提供開始

業務及びシステムの移行

利用者教育

(33)データ移行

(34)完了報告(受け入れ)

Gデータ移行支援業務契約

(35)運用に関わる作業手順の確立

(36)運用テスト

(37)完了報告(受け入れ)

H運用テスト支援業務契約

(38)利用者導入教育

(39)完了報告（受け入れ）

I導入教育支援契約

2.6 保守
問題把握及び修正の分析、修正の実施、保守レビュー及び／又は受入れ

(41)ハードウェア保守、カスタマイズ部分保守開始

J保守業務契約

3.1 運用プロセス
業務運用と利用者支援

(42)運用支援

K運用支援業務契約





別紙2パッケージオプション 取引・契約モデル

共通フレーム2013

取引・契約モデルのフェーズ

契約

基本

重要事項説明書

2.1 企画プロセス
システム化構想の立案、システム化構想の承認
システム化計画の立案、システム化計画の承認

(1)事業要件定義

(2)プロジェクトゴールの策定

(3)要求品質の明確化

(4)パッケージソフトウェアを利用し実現する業務の新全体像の作成（2.1.1.2.6～2.1.2.2.7該当）

(5)パッケージベンダに対してシステム、パッケージソフトウェア等の情報提供要求、試算見積依頼（RFI）

(6)ユーザに対しRFIに基づくシステム、パッケージソフトウェア等の情報の提供、試算見積の提示

パッケージソフトウェア利用コンピュータシステム構築支援契約書

C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル）

2.2 要件定義プロセス
利害関係者の識別、

要件の識別、

要件の評価、

要件の合意、

要件の記録

(7)業務要件定義

(10)パッケージソフトウェアの機能要件、非機能要件、使用許諾契約(利用条件、保守等) 、SaaS/ASPにおいてはSLAの検討

(11)パッケージソフトウェア候補の選定

(14)使用許諾によってはパッケージソフトウェア、OS、ハードウェアの導入及び保守の開始

(15)パッケージ候補のシステム要件評価

(16)API実現性の確認（候補パッケージのAPI、既存システムとの接続性等の評価）

(17)パッケージソフトウェアの選定と要件定義、システム要件定義と評価

2.3 システム開発プロセス
システム要件の定義、システム要件の評価及びレビュー、

システム方式の確立、システム方式の評価及びレビュー

2.4 ソフトウェア実装プロセス
ソフトウェア要件定義、ソフトウェア方式設計、ソフトウェア詳細設計、

ソフトウェア構築、

ソフトウェア結合、ソフトウェア適格性確認テスト、

システム結合、テスト準備及びシステム結合の評価、

システム適格性確認テスト、

ソフトウェア導入、受入れ支援

(21)使用許諾によってはパッケージソフトウェア、OS、ハードウェアの導入及び保守の開始

(22)外部プログラムの機能の確定、及びそれに伴うユーザI/F・他システムI/F設計

(23)外部設計書の承認(受入れ)

D外部設計支援業務契約

(25)ソフトウェア設計

(26)外部プログラムの設計、プログラミング、ソフトウェアテスト

(27)適格性確認テスト、監査、ソフトウェア導入

(28)納品

(29)検収（受入れ）

Eソフトウェア設計・制作業務契約

3.1 運用プロセス
運用テスト及びサービスの提供開始

業務及びシステムの移行

利用者教育

(30)構築・設定業務（機器・OS等の設定、納品）

(31)システム結合、テスト

(32)検収（受入れ）

F構築・設定業務契約

(33)データ移行

(34)完了報告(受け入れ)

Gデータ移行支援業務契約

(35)運用に関わる作業手順の確立

(36)運用テスト

(37)完了報告（受け入れ）

H運用テスト支援業務契約

2.6 保守
問題把握及び修正の分析、修正の実施、保守レビュー及び／又は受入れ

(38)利用者導入教育

(39)完了報告（受け入れ）

I導入教育支援契約

2.6 保守
問題把握及び修正の分析、修正の実施、保守レビュー及び／又は受入れ

(41)ハードウェア保守、外部プログラム等保守開始

J保守業務契約

3.1 運用プロセス
業務運用と利用者支援

(42)運用支援


K運用支援業務契約





以下、別紙1パッケージカスタマイズ取引・契約モデルと共通フレームのポイントを解説する。別紙2については、各ポイントを参考し準用されたい。



最初のプロセスである「業務要件定義プロセス」の目的は、共通フレーム2013における「2.1 企画プロセス」と「2.2 要件定義プロセス」の成果を得ることにある。

Frame1

■2.1　企画プロセスの成果：
(1)経営層及び各部門からシステムに関係する要求事項が集められ、かつ、合意される。(2)要求事項に基づいたシステム化の範囲及びシステム構成、基本的なアーキテクチャが定義される。(3)システムを実現する実施計画が策定され、かつ、合意する。

■2.2　要件定義プロセスの成果：
ユーザの利害関係者間で
(1)対象システムを含む業務、組織に関する要件が定義され、かつ合意される。(2)システムに対する要件及び制約事項が定義され、かつ合意される。(3)定義された要件と、プロセスの入力となった要求事項との整合性が保たれる。

■契約の開始：
調査手法、分析手法、範囲とともに場所や設備などの付帯事項が確定しており、途中報告書、最終報告書の様式、量、日程などの全体計画が立案されユーザと合意している状態にある。

■契約の終了：
業務要件定義に基づき、システム化する機能が精査決定され、パッケージソフトウェアが選定され、モディファイやアドオン部分の外部設計が可能な状態にある。RFPを提示することで、開発、保守、運用の費用を含めた全体的な見積が得られる状態にある。

Frame2

プロセス開始に当たっては、以下のドキュメントを参照するとよい。

■参考ドキュメント：
1.コンサルティング会社選定のためのチェックリスト
3.業務システム仕様書の記述レベル
4.ユーザIT成熟度チェックリスト
9.セキュリティチェックシート 一般版（上位概念）
10.セキュリティチェックシート Webアプリケーション版

Frame3

(2)「プロジェクトゴールの策定」から(6)「ユーザに対しRFIに基づくシステム、パッケージソフトウェア等の情報の提供、試算見積の提示」は、共通フレーム2013「2.1.1システム化構想の立案プロセス」、「2.1.2システム化計画の立案プロセス」に相当する。特に、「2.1.1.2.6業務の新全体像の作成」から、「2.1.2.2.6業務モデルの作成」「2.1.2.2.7システム化機能の整理とシステム化方式の策定」「2.1.2.2.8付帯機能、付帯設備に対する基本方針の明確化」がスパイラル的に検討されることを想定している。プロセス初期はユーザに知見が乏しいことから、他社動向やパッケージソフトウェアの機能や知見を得ることで、プロジェクトゴールが随時変更されることを前提としている。ただし、プロジェクトゴールはコストと制約条件でコントロールされるべきで、闇雲な拡大を狙うものではない。結果としてシステム化が実現可能な業務の絞り込みがなされることを期待している。

(3)「要求品質の明確化」はユーザが顧客に提供する業務の品質が上位にあり、それを支えるための情報システムの品質としてとらえるべきである。とはいえ、情報システム構築の経験が少ないユーザは、業務品質を特段に意識していることが少ないといえるので、早期に共通フレーム2013「2.1.2.2.9サービスレベルと品質に対する基本方針の明確化」30 等で要件を明確化するように努める。これらによって非機能要件の先送りを防止することが可能となる。信頼性の観点から、システムの停止が業務に与える影響の評価、セキュリティの観点から個人情報や企業情報の漏洩の影響の評価、保守性の観点から誤操作や障害発生時のユーザの対応できる範囲を具体的に議論することが望まれる。

(4)「パッケージソフトウェアを利用し実現する業務の新全体像の作成」は、最終的に共通フレーム2013「2.1.1.2.6業務の新全体像の作成」に相当する。(4)を作成した後の、(6)「ユーザに対しRFIに基づくシステム、パッケージ等の情報の提供、試算見積の提示」でコスト評価を行い費用対効果についての意識を持つことは、ユーザの過大な要求を適正化することにも寄与し、かつ信頼性向上にも大きく関与する。口頭による曖昧な合意の排除、要件の先送りを防止するため、変更管理手続による未決定事項の管理を実施し、議事録の採番、記述様式、手交の方法を取り決めることが必要である。
　ユーザは利用者からの幅広い聞き取りを実施し、操作性の向上や要求漏れによる手戻りの防止に努めるべきである。その際、ベンダは、具体的な画面イメージや画面遷移などのシステムの流れの説明に努め、業務の流れとシステムの流れをユーザに理解される工夫が必要である。この段階での要件の先送りを極力減らすことは、信頼性確保の重要なポイントとなる。機能比較が行われることで、新たに開発し実装すべき不足部分が明確となっている。また、既存システムとの接続や移行があり得る場合は、既存システムの調査や、接続性、移行性の難易度についても検討を加えておく。「2.1.2.2.8付帯機能、付帯設備に対する基本方針の明確化」は、プロジェクトの範囲、全体の工数に多大な影響を及ぼし、コスト、期間、構築の難易度を左右する。

(7)「業務要件定義」以降のフェーズは、費用対効果に基づく優先順位付けの検討に留意したい。ユーザの業種、業務の特殊性や独自性が高い場合、パッケージソフトウェアの評価段階で、パッケージソフトウェアの機能不足に着目し、モディファイやアドオンの範囲が過大になりがちとなる。一般的にコストをかければパッケージソフトウェアの適合性は高まるが、反面、パッケージソフトウェアを導入する経済合理性が失われてしまう可能性も高くなる。また、過大な要求は、次のフェーズにおいてパッケージソフトウェアの変更費用の増加となって現れる可能性が高くなる。さらには、パッケージソフトウェア本体の根本的改造といった信頼性、経済性を大きく損なう要因になる。業種、業務の特殊性に関わらず、状況が許す限り極力モディファイ、アドオンの作成を避けるという方針の維持が重要である。

(8)「ベンダに対しパッケージソフトウェア候補選定のための情報提供依頼（RFI）」、(9)「RFIに基づくパッケージソフトウェア関連情報、見積の提供」は、パッケージソフトウェアに実装されている機能情報、価格情報をもとに、(10)「パッケージソフトウェアの機能要件、非機能要件、使用許諾契約の検討」31、(11)「パッケージソフトウェア候補の選定」の実施に重大な影響を及ぼす。業務要件定義支援契約全般における品質に関与する事と環境適合を念頭に、必要に応じて繰り返し実行してもよい。共通フレーム2013「2.1.2.2.5 適用技術の調査」及び「2.1.2.2.14 費用とシステム投資効果の予測」が該当する。

(12)「業務要件及び適合するパッケージソフトウェア候補の報告書の提出」は、ユーザの要望を基に、新しい業務のあり方や要員などの運用要件、導入方針やスケジュール、機能要件、セキュリティを含む非機能要件を確定する。さらに、これらの要件を実現すると思われるパッケージソフトウェア候補は、使用許諾契約、バージョンアップ、保守性なども考慮されて選定されることを期待している。運用にあたっての問い合わせ窓口の情報、サポート契約などは、運用コストに直結するため、十分な情報提供が望まれる。

(15)「パッケージ候補のシステム要件評価」以降ではパッケージソフトウェアが要求するシステムの機能及び能力、設計条件、開発環境などの技術的要素だけでなく、利用者の要件やインターフェース、操作及び保守要件など、運用や保守についても詳細な評価がなされることが重要である。SaaS/ASPにおいては、経済産業省SaaS向けSLAガイドラインの別表SaaS 向けSLA におけるサービスレベル項目のモデルケースを参考に、事業者が提供しているSLAについて評価する。この際、可用性、信頼性はもとより、クライアント端末での性能確保について評価が必要である。共通フレーム2013「2.2.3.1 要件の抽出」が該当する。これ以降、口頭による曖昧な合意を排除するため、変更管理手続による未決定事項の管理、議事録の手交を取り決めることが望ましい。なお、この時点でバックアップや、サーバーの構成などすべてのシステム全体の構成を決定するのではないことから「2.3.2システム要件定義プロセス」とは異なることに留意する。

(16）「APIの実現性の確認」は、モディファイやアドオンの実現性の評価となるため、個別具体的な技術的検討が必要である。また、既存システムとの接続がある場合、その接続性の評価、既存システムの改造等の評価も含まれる。ここで、プロジェクト全体の範囲、要素が抽出されるため、既存システム、パッケージソフトウェアに精通したエンジニアの参画、もしくはパッケージソフトウェア製造会社の協力が必要となる。

（17）「パッケージソフトウェアの選定と要件定義、システム要件と評価」では、パッケージソフトウェア候補に対する機能要件、非機能要件の過不足評価だけで終わることなく、コストを前提とした利用者要件、環境適合、セキュリティ、運用、保守、移行、使用許諾契約、SLAなども要件として定義される。特に、使用許諾契約はパッケージソフトウェア製造会社とユーザの個別契約であり、かつ、パッケージソフトウェア本体の使用上の権利や契約不適合の扱いなどが決定されるため、細部にわたる慎重な評価が求められる。パッケージソフトウェアの選定によって手作業部分とシステム要件（機能要件、非機能要件32）のほとんどが決定されるため、様々な視点からの評価が重要となるため、直接的な利用者や利害関係者のレビューが重要である。各評価のポイントは、ユーザとベンダにおいて合意された重み付けがなされていることが望ましい。場合によっては(15)～(17)が繰り返される。(17) 「パッケージソフトウェアの選定と要件定義、システム要件と評価」以降の要件の未決事項は実装が困難となるため、変更管理手続に則り処理を決定する必要がある。外部設計以降に要件の追加や範囲の拡大などが発生しないよう、ユーザ、ベンダの慎重な検討と合意を図るべきである。

この後、(19)「ベンダへの見積要求」によってベンダから見積を得ることとなるが、その際、ベンダにどこまでの業務を依頼するかによって、コスト及び精度が異なってくる。パッケージに関わる開発行為なのか、接続すべき既存システムがある場合や移行を伴うかなどの範囲を明確にし、RFPの内容精度の向上に努めるべきである。RFPの内容が不明確、不明朗であることで、受託後の調査工数が上乗せされ本来不要なコストが発生したり、見積に失敗する大きな原因になることを留意する。

「設計・制作・テスト・移行プロセス」では、共通フレーム2013の「2.4.4 ソフトウェア詳細設計プロセス」から「2.4.9 ソフトウェア受入れ支援プロセス」と、「3.1.2 運用テスト及びサービスの提供開始」、「3.1.3 業務及びシステムの移行」、「3.1.5 利用者教育」を想定しており、「2.4 ソフトウェア実装プロセス」と「3.1 運用プロセス」の成果の一部を得ることにある。

Frame4

■2.4　ソフトウェア実装プロセスの成果：
(1)ソフトウェア開発の要件が収集され、合意されている。(2)ソフトウェア製品及び／又はソフトウェアを中心とするシステムが開発されている。(3)最終製品が要件に基づくことを示す中間作業成果が開発されている。(4)開発プロセスでの製品間で一貫性が確立されている。(5)システム品質要因がシステム要件（例えば、速度、開発費用、使用性など）に照らして最適化されている。(6)最終製品が要求事項を満たすことを示す証拠（例えばテストの証拠）が存在している。(7)最終製品が合意した要求事項に従って導入されている。

■3.1　運用プロセスの成果：
(1)ソフトウェアの正しい運用の条件が、意図された環境下で識別され、評価されている。(2)ソフトウェア及び業務が、意図された環境下で運用されている｡(3)ソフトウェア製品の顧客に援助及び相談が、契約に従って提供されている。

■契約の開始：
要件定義書、外部設計書の実現可能性を含めた総合的な評価が完了し、すべての利害関係者の中で、用語、要求の定義等について疑義が無い状況であることが確認されており、詳細工程の日程を含む全体計画が立案され評価がすんでいる状態にある。

■契約の終了：
要件に従って選択されたパッケージソフトウェア（モディファイ部分を含む）、もしくはアドオンプログラムが、ソフトウェア設計・制作業務で示された適格性テストを合格し稼働する状態でユーザに納品され、既存のシステムからのデータ移行がある場合は、データ移行が完了している状態にある。サーバ、クライアント、ネットワークの構築、設定、システム結合がある場合、これらが完了している状態にある。

Frame5

プロセス開始に当たっては、以下のドキュメントを参照するとよい。

■参考ドキュメント：
3.業務システム仕様書の記述レベル
7.検収事前チェックリスト
8.検収チェックリスト
9.セキュリティチェックシート 一般版（上位概念）
10.セキュリティチェックシート Webアプリケーション版

Frame6

(17) までの要件定義を行ったベンダと、(21)以降の外部設計支援を行うベンダが異なる場合については留意が必要である。(17)までの要件定義を担当したベンダは、(21)以降の外部設計支援を行うベンダが全体計画を策定し作業着手できるまでは、必要な打ち合わせ、問い合わせの対応を業務の責任範囲とし、合理的な範囲で疑義解消を業務範囲とすべきである。また、いずれの契約類型も準委任契約であることから、ユーザはベンダ同士の解決に頼らず自らも疑義解消に努め要件の精度向上を担うべきである。

(21)「使用許諾によってはパッケージソフトウェア、OS、ハードウェアの導入及び保守の開始」は、(22)「モディファイ、アドオンの範囲の確定、及びそれに伴うユーザI/F・他システムI/F設計」を実行する際に、パッケージソフトウェアそのものの導入が必要なケースを想定している。モディファイの範囲決定のためにソースコードの調査が必要で、パッケージソフトウェア製造会社が無償で調査を実施しないケースがこれに該当する。この時点でパッケージソフトウェアと調査のための動作環境を購入しなければならない。この場合、(30)「構築・設定業務」、(31)「システム結合、テスト」、(32)「検収」の一部が発生する。

(22)「モディファイ、アドオンの範囲の確定、及びそれに伴うユーザI/F・他システムI/F設計」33では、パッケージソフトウェア本体へのモディファイを実施する場合の詳細範囲の決定や、不足している入出力機能、画面・帳票のデザイン、画面遷移、操作性、他システムとの接続がある場合は、そのインターフェースなどが要件定義書に基づき設計される。ユーザに対して画面遷移を含むデザインレビューは手戻りを防止する上で重要である。34 この時点で未決定事項の最終的な処理決定が必要となる。共通フレーム2013「2.4.2 ソフトウェア要件定義プロセス」が該当する。また、併せて「2.4.3.1.4 利用者文書(暫定版)の作成」を実施し、ユーザの理解を深めることが望ましい。運用マニュアル作成、運用テストの重要な関連ドキュメントとなる。モディファイが伴う場合は、範囲を最小限にするとともに、契約不適合対応、信頼性、保守性の観点からパッケージソフトウェア製造会社との協業もしくは、サポート契約の締結を検討すべきである。また、将来にわたってのパッケージソフトウェア本体のバージョンアップが困難になる可能性があること、将来にわたって保守のためにソースコードに変更を加える場合の管理方法とコストを慎重に検討し、ユーザと文書で合意すべきである。

重要な留意点として、(22)「モディファイ、アドオンの範囲確定、及びそれに伴うユーザI/F・他システムI/F設計」において、パッケージソフトウェアによる要件の達成が困難又は大幅なコスト超過が判断された場合の手戻り対応が想定される。かかる事態は事実上のプロジェクトの破綻であり、要件定義プロセスの失敗を意味する。そのため要件定義業務とソフトウェア設計・制作業務が異なるベンダで契約される場合は、ソフトウェア設計・制作契約の停止条件や、業務要件定義の見直しなどの手戻りによって発生する費用の負担などの取り決めが重要となる。

(23)外部設計書の承認（受入れ）で、ユーザの画面等の承認を得た後、(25)「ソフトウェア設計」で、要件定義書、外部設計書に基づき、それ以降の開発全体のプロジェクト計画が立案され、各コンポーネント、インターフェース、データベースの詳細設計がなされ、併せて利用者向けのマニュアルの作成とコンポーネントのテスト、結合テストの要求事項がまとめられる。共通フレーム2013「2.4.2 ソフトウェア詳細設計プロセス」が該当する。

(26)「モディファイ、アドオンの設計、プログラミング、ソフトウェアテスト」35は、いわゆるコンポーネントのプログラミング、コンポーネントの結合、テストとシステム結合（ハードウェアへの導入、他システムとの接続等）の一部である。共通フレーム2013「2.4.5ソフトウェア構築プロセス」、「2.4.6 ソフトウェア結合プロセス」、「2.4.7 ソフトウェア適格性確認テストプロセス」、「2.3.5 システム結合プロセス」が該当する。ここでシステム結合の一部と限定したのは、ソフトウェアテストを実現するための環境構築及びシステム結合であり、他システムとの連携を含めた全体のシステム結合は(30)「構築・設定業務（機器・OS等の設定、納品）」～(32)「検収（受入れ）」でなされることを想定しているためである。

それぞれの工程で、業務要件定義書、外部設計書、全体計画が常に参照され、利用者文書のアップデートがなされるとともに、最終的にはシステム適格性テストのテストケースとテストデータまでが準備される。モディファイにあたっては、将来にわたっての保守性を維持することを目的としたソースコード、変更履歴が保存され、履歴と目的がまとめられた変更状況報告書が文書化されることを期待している。

(27)「適格性確認テスト、監査、ソフトウェア導入」では、要件定義書に定められたテスト方法、テストデータを基にシステム要件が実現され納品可能な状態になる。テストは納品実機で実施されることが望ましいが、困難な場合は、実機相当品を準備し、OS等の環境を同一にすることが必要であり、(29)「検収（受入れ）」でも(27)の適格性確認テストの仕様に基づくテストを実施する必要がある。共通フレーム2013「2.4.7 システム適格性確認テストプロセス」が該当する。

(30)「構築・設定業務（機器・OS等の設定、納品）」～(32)「検収（受入れ）」は外部設計、ソフトウェア設計・制作に並ぶ重要なプロセスである。このプロセスによってサーバ、機器、ネットワーク等の設定、構築並びにシステム結合が実施され、運用の一歩手前の状態となる。(30)「構築・設定業務（機器・OS等の設定、納品）」～(31)「システム結合、テスト」では、サーバ、クライアントのOS、ネットワーク、セキュリティの設定、個別の機器の設定、他システムとの結合などが実施される。既設のシステムがある場合は、事前の調査に基づいて、業務の中断や処理の停止等を考慮し、設置計画を立案、承認されることが求められる。また、電源、空調等の環境も併せて考慮されることを期待している。ユーザ、ベンダは合意の上、(29)「検収（受入れ）」、(31)「システム結合、テスト」、(32)「検収（受入れ）」を一つのプロセスとし、システム適格性確認テストを再現し、要件定義書に基づいた条件で検収を受けてもよい。「E ソフトウェア設計・制作契約」の納期とテスト期間、「F 構築・設定業務契約」の構築・設定業務報告書提出期限とテスト期間を同一にすればよい。構築・設定業務契約で留意が必要なのは、構築・設定に関する仕様書通りに設置調整ができなかった場合である。運用マニュアルの作成や、セキュリティに多大な影響を及ぼす可能性もあることから、構築・設定に関する仕様書と異なる設定を行う際の承認方法や、構築・設定業務設定報告書の作成、記述については注意が必要である。共通フレーム2013「2.4.8 ソフトウェア導入プロセス」、「2.4.9ソフトウェア受入れ支援プロセス」が該当する。

(33) 「データ移行」では、データ移行支援契約に基づき、顧客のシステム現況から移行対象となるデータが確定され、抽出、変換、移行の作業が支援される。移行対象のデータについては、十分に事前の打ち合わせを行い、マスタのみとするか、トランザクションも含めるか、慎重な検討がなされるべきである。あわせて、コード体系、外字、異体字の取扱い、半角、全角等の取扱いを定める必要がある。変換のためのプログラミングが必要な場合は、要件定義書を策定し、(25)ソフトウェア設計以降の手順を踏まなければならない。また、トランザクションを含むとすれば、どの時点までのデータとするかが詳細に検討されなければならない。現行システムの停止や保全のためのバックアップ、移行に至る実施手順シミュレーションが必要となる。共通フレーム2013「3.1.3 業務及びシステムの移行」が該当する。

(35)「運用に関わる作業手順の確立」 は共通フレーム2013「3.1.1.3問題管理手続きの確立」「3.1.1.4システム運用に係る事前調整」「3.1.1.5システム運用に係る作業手順の確立」を想定している。運用手順が確立されていないと、運用テスト計画の策定が困難なためである。

(36)「運用テスト」では、一般的な運用状況と例外処理、エラー処理を想定した運用テスト計画書を策定し評価する。運用テスト計画書においては、実際の業務シナリオに基づき、確認項目、実施方法、確認内容、テストデータが定義されなければならない。運用テスト計画書が承認されたら、要件通りの動作（入出力、画面遷移等）がなされることを、運用テスト計画書に基づいて確認する。業務ピークや、月次や年次における特有の処理などがある場合は実際のデータが用意され、実態に即して実行されなければならない。印刷時のエラー処理や通常業務で想定されない処理についても、運用テスト計画書において想定する必要がある。共通フレーム2013「3.1.1.10運用テスト計画の作成」「3.1.2 運用テスト及びサービスの提供開始」が該当する。

(38) 「利用者導入教育」では、実際の環境もしくは同等の環境での操作の習得、障害発生時の対応等の教育である。利用者のITリテラシを考慮し、利用者文書に基づき、日常の操作と、月次・年次処理や障害時の操作、対応、措置、連絡等を習得し、単独で操作が遂行されることを期待している。共通フレーム2013「3.1.5 利用者教育」が該当する。なお、この段階で利用者文書の改訂や見直しを図る場合もあるため、その場合は、教育計画において事前の合意を得ておく。



（別紙1、別紙2共通：「2.6保守プロセス」「3.1運用プロセス」のポイント）

「2.6保守プロセス」「3.1運用プロセス」では、共通フレーム2013の「2.6.2 問題把握及び修正の分析」、「2.6.3 修正の実施」、「2.6.4 保守レビュー及び／又は受入れ」、「3.1.4システム運用」、「3.1.6 業務運用と利用者支援」を想定しており、「2.6 保守プロセス」と「3.1 運用プロセス」の成果の一部を得ることにある。

Frame7

■2.6 保守プロセスの成果：
(1)リリース戦略に従って製品の修正、移行及び廃棄を管理するために、保守の戦略が、作成されている。(2)現行システムへの組織上、運用上又はインターフェース上の変更の影響が、識別されている。(3)影響されたシステム／ソフトウェアの文書は、必要に応じて更新されている。(4)修正された製品が、要件を損ねていないことを示すテストを重ねた上で作成されている。 (5)製品のアップグレードが、顧客の環境へ移行されている。(6)要求に応じて、製品が、顧客の混乱を最小限にする管理された方法で廃棄されている。(7)システム／ソフトウェアの修正が影響を受けるすべての関係者に伝達されている。

■3.1　運用プロセスの成果：
(1)ソフトウェアの正しい運用の条件が、意図した環境下で識別され、評価されている。(2)ソフトウェア及び業務が、意図された環境下で運用されている。(3)ソフトウェア製品の顧客に援助及び相談が、契約に従って提供されている。

■契約の開始：
運用テストが終了し、ソフトウェア要件、システム要件がすべて決定され、契約不適合がない、もしくは解決される状態にある。ただし、これ以前に保守開始となった場合や、個別の判断で開始となった場合はこれに限らない。

■プロセスの終了：
すべてのソフトウェア、システムは適切に運用、保守され正常に動作しており、廃棄のプロセスに移行する直前の段階の状態にある。

Frame8

(41)「ハード保守、カスタマイズ部分保守開始」では、指定されたハードウェア、アドオン、モディファイされたパッケージソフトウェアの保守が開始される。パッケージソフトウェア本体の保守は、パッケージソフトウェア製造会社との契約でなされるため、必要に応じて個別契約を締結する。保守の範囲、期間、金額とともにSLA合意書で受付時間、応答時間、復旧時間等を定義し、測定可能なサービス内容として合意する。共通フレーム2013「2.6.2 問題把握及び修正の分析」、「2.6.3 修正の実施」、「2.6.4 保守レビュー及び／又は受入れ」が該当する。保守を受けた場合の変更履歴は、ベンダ、ユーザともに保管されなければならない。SLA締結において文書様式をあらかじめ合意しておくことが重要である。

(42)「運用支援」では、サーバやネットワーク機器の遠隔監視、ログ取得、ウイルスやセキュリティ関連のサービス提供が想定される。保守同様にSLAを締結し、具体的に測定可能なサービス内容として合意することを期待している。共通フレーム2013の「3.1.6 業務運用と利用者支援」が該当する。

モデル契約書・逐条解説

パッケージソフトウェア利用コンピュータシステム構築委託契約書










【対象・前提】

・ 契約当事者：ITの専門知識を有しないユーザと、業として情報サービスを提供するベンダを想定

(例) 委託者（ユーザ）：民間中小・中堅企業、地方自治体、独立行政法人等

受託者（ベンダ）：情報サービス企業（SIer、ソフト会社、ITコーディネータ等）

※対等に交渉力のあるユーザ・ベンダについてはモデル取引・契約書第二一版を参照。

・ 開発モデル：パッケージ＋カスタマイズ型、パッケージ＋オプション型

※モデル取引・契約書第二一版｢2.(7)パッケージ活用、反復繰り返し型の開発、中小企業等ユーザにおける活用の留意点｣を基に、新たに策定したモデル

・ 対象システム：財務会計システム、販売管理システム、電子メール、グループウェア、Webシステム等の導入、構築・設定、カスタマイズ開発、移行、教育、保守、運用支援

・ 対象モデル：パッケージモデル、SaaS/ASPモデル

※大規模受託開発についてはモデル取引・契約書第二一版を参照。

・ プロセス：共通フレーム2013に準拠したシステムの企画段階、開発段階、運用段階、保守段階の定義による。

・ 一括発注の場合に加え、マルチベンダ形態、工程分割発注に対応。

・ システム基本契約書はプロジェクトごと、ベンダごとに締結。個別契約はシステム基本契約書の別紙である重要事項説明書をもって締結。







パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書

（システム基本契約書）



委託者　　　　　　　　　（以下「ユーザ」という。）と受託者　　　　　　　　　（以下「ベンダ」という。）とは、パッケージソフトウェア、SaaSおよび／もしくはASPを利用して構築するユーザ向けのコンピュータシステム（以下「本件システム」という。）に係る業務の委託に関して、次のとおり契約（以下「システム基本契約書」という。）を締結する。



Frame9

（本契約の構造）

第1条 本契約は、システム基本契約書及び以下の業務のうち左欄に☑が記された業務（以下「本件業務」という。）に関する各個別契約書によって構成される。

A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）

B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）

C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル）

D　外部設計支援業務契約

E　ソフトウェア設計・制作業務契約

F　構築・設定業務契約

G　データ移行支援業務契約

H　運用テスト支援業務契約

I 導入教育支援業務契約

J 保守業務契約

K 運用支援業務契約



2) 前項の各個別契約書は、システム基本契約書と一体となる本件業務に関するそれぞれの別紙重要事項説明書へのユーザ及びベンダによる記名押印をもって締結する。

Frame10

本モデル契約書は、企画フェーズから保守運用フェーズまでに共通して適用されることを想定しており、本契約書（わかりやすい記載にするため個別契約書を含まない本契約書だけに記載された事項についての契約を「システム基本契約書」と定義している。）は、本件業務の種類に関係なく、すべてに適用される契約条項を定めるものであり、全体の基本契約の役割をはたす。それぞれの本件業務を受託するベンダが異なる場合には、システム基本契約書はベンダごとに作成、締結される。

別紙重要事項説明書は各本件業務についての業務の内容及び個別の契約条項を定めるものであって、各本件業務についての個別契約書の役割をはたすものである。別紙重要事項説明書（個別契約書）は、それぞれの本件業務を担当するベンダごとに作成、締結される。



Frame11

（契約内容の確定及び変更等）

第2条 本契約（システム契約並びに選択された本件業務についての別紙重要事項説明書によって構成される契約全体を指す）の内容は、以下のとおり確定し、以下の条件に従って変更することができる。

      1. ベンダ及びユーザが記名押印した、システム契約並びに別紙重要事項説明書に記載された内容は、ひとつの契約を構成し、そのタイトルの部分に「予約」と記載されていない限り、ベンダ及びユーザを法的に拘束する。
      2. 別紙重要事項説明書には、確定した契約条件のほかにまだ確定していない契約条件が記載されていることがあり、このうち確定していない契約条件については、そのタイトルの部分に「予約」と記載される。予約と記載された事項についての記載はベンダ及びユーザを法的に拘束するものではない。
③ ベンダが複数の本件業務を担当する場合、ユーザ及びベンダは、最初に遂行すべき本件業務に係る部分については、すべての契約内容を確定させるものとする。
④ ベンダが複数の本件業務を担当する場合で当初複数の重要事項説明書を作成している場合は、ユーザ及びベンダは、最初に遂行すべき本件業務以外に係る重要事項説明書について、それぞれの本件業務の開始時に、具体的業務内容、個別契約条項等の条項の再確認を行い、その時点までにで確定していなかった条項を確定し、また必要に応じて確定されていた条項についての変更を行った上で、当該本件業務に関する契約条件を確定する。この場合における契約条件の確定は、新たに重要事項説明書（以下「改訂版重要事項説明書」という。）を作成しこれにユーザ及びベンダが記名押印することによって行う。
⑤ 改訂版重要事項説明書は、これが作成され記名押印されたときから、本契約と一体をなすものとして本契約の内容を規定する効力を生じる。
⑥ ④所定の契約条件変更のほか、ユーザ及びベンダの協議により、別紙重要事項説明書（改訂版重要事項説明書を含む。以下同じ。）に記載された条項の変更を行う場合は、ユーザ及びベンダが記名押印した書面によって行うものとする。なお、かかる変更の際には価格及び納期の変更の有無、変更の内容についても協議・合意されるものとする。
⑦ ベンダは、ユーザが前号の変更規定に基づかずに契約条件の変更を行った場合、この変更により生じたことについて、一切の責任を負わない。

Frame12

同一のベンダが複数の本件業務を受託する場合であっても、システム基本契約書は１通のみを作成することになる。一方、重要事項説明書については、同一のベンダが複数の本件業務を受託する場合は、各本件業務の開始時に、それぞれの本件業務についての内容を確定して作成する。これは、同一のベンダが複数の本件業務を一括して受託する場合であっても、各本件業務の内容は、前工程となる本件業務が実施された結果を反映して決定すべきものであるから、本件業務の区切りごとにその内容を確認する機会を設ける必要があるからである。このような建付けとすることにより多段階契約方式を実現している。

同一のベンダが複数の本件業務を受託する場合に複数の本件業務についての重要事項説明書を当初から作成してしまう場合も考えられる。その際、最初に遂行すべき本件業務についての重要事項説明書にはすべて確定された条項が記載されることになるが、後工程の本件業務についてのいくつかの条項は、暫定見積りを行うためのものであって、これらの条項は確定条項として当事者を拘束するものではない。こうした確定していない条項について暫定的な記載をする場合はかかる条項について「予約」と記載する。、ベンダがこのように予約として記載された条項も、そうした条項が含まれる本件業務が始まる前には前項で説明したようにユーザとベンダがその内容を確認し改訂版重要事項説明書を作成、記名押印することによって確定されていく。

上記のとおり本件業務を開始する時点で、当該本件業務に関する条件はすべて確定しているが、これを当該本件業務の途中で変更する場合は、本条⑥に規定する契約内容変更の手続によることになる。

Frame13

（協働と役割分担）

第3条 ユーザ及びベンダは、双方による共同作業及び各自の分担作業を誠実に実施するとともに、相手方の分担作業の実施に対して誠意をもって協力するものとする。

2) ユーザ及びベンダ双方による共同作業及び各自の分担作業は、別紙重要事項説明書においてその詳細を定めるものとする。

3) ユーザ及びベンダは、共同作業及び各自の実施すべき分担作業を遅延し又は実施しない場合若しくは不完全な実施であった場合、それにより相手方に生じた損害の賠償も含め、かかる遅延又は不実施若しくは不完全な実施について相手方に対して責任を負うものとする。

Frame14

「信頼性ガイドライン」において、「商慣行・契約・法的要素に関する事項」として、「情報システム構築の分業時の役割分担及び責任関係の明確化」が重要である旨指摘されているが、これは、情報システム構築取引の特徴を反映したものである。ソフトウェア開発は、ユーザの業務をコンピュータで処理可能にするものであるところ、その業務はユーザ毎に異なり、ユーザこそがその内容の確定についての権限と責任を負っている。但し、「ユーザの業務」といっても、システム開発業務の着手段階ではユーザの責任者自身も完成形をイメージできていないこともしばしばである。この点で、よくたとえられる建物の建築とは大きな違いがある。ソフトウェア開発業務は建物の建築とは似て非なるものであることを十分理解しておく必要がある。

こうした理由から、ソフトウェア開発は、ユーザとベンダが意思の疎通を図りつつ共同作業及び分担作業を適切に行うことが重要である。しかし、その対象となる業務の範囲は広範で多様なため、しばしば作業項目自体の漏れが生じるし、ユーザ・ベンダ間で互いに「この業務は相手方の責任範囲である」という思惑違いも生じる。これがシステム開発におけるトラブルの原因となる場合も多い。そのため、本モデル契約には、ユーザ・ベンダの役割分担を別紙重要事項説明書において具体的に文書化することとしている。

なお、近時の裁判例ではベンダのプロジェクトマネジメント義務及びユーザの協力義務が問題となることが多い。東京地判平成16年3月10日判例タイムズ1211号129号では、ベンダに対して納入期限までにシステムを完成させるように、契約書及び提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対応すべき義務を負い、また、ユーザのシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることにないようユーザに働きかける義務を負うと判示している。反面、同判決では、オーダーメイドのシステム開発においてはベンダのみではシステムを完成させることはできないのであって、ユーザが開発過程において内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するかを明確にベンダに伝え、ベンダとともに要望する機能について検討して、最終的に機能を決定し、さらに、画面や帳票を決定し、成果物の検収をするなどの役割を分担することが必要である旨判示している。

裁判例上問題となるプロジェクトマネジメント義務及び協力義務は、システム開発及びユーザの業務内容についての一定の情報の非対称性を前提とするものである。すなわち、システム開発についてはベンダが専門性を有しているのに対し、ユーザには必ずしも十分な知識がない一方、当該システムが取り扱うユーザの業務については、当然ユーザ自身はそれに精通しているのに対し、ベンダは必ずしも知識がないことから、そのようなユーザとベンダが共同でシステム開発におけるプロジェクトマネジメント（プロジェクトマネジメントの標準知識体系として、米国PMI（Project Management Institute）が制定した「PMBOKガイド」によれば、「プロジェクトの要求事項を満たすために、知識、スキル、ツール及び技法をプロジェクトの活動へ適用すること」とされる。）を行っていくに当たって、それぞれが負わなければならないとされている義務が裁判例上プロジェクトマネジメント義務と協力義務として表現されているのであり、その表現から感得されるような「ベンダが主、ユーザが従」という関係ではないということに注意が必要である。また、これらの情報の非対称性の程度は案件ごとに異なり、それに応じてベンダ及びユーザがそれぞれ負うこれらの義務の内容及び程度も自ずと異なるものと思われる（その意味で、上記平成16年東京地判も当該事案における判断に過ぎない）。また、これらの非対称性がもたらす影響も各フェーズにより異なり、要件定義や外部設計などの上流工程では、業務の内容に専門性を有するユーザが特に主体的な役割を担う必要があるし、内部設計やシステム開発といった下流工程では、開発に専門性を有するベンダがより重要な役割を担うことになる。もっとも、事後的に紛争になった場合に裁判所において双方が実際にどのような義務を負うと判示されるかの予測可能性は高くない。そのような事後的な紛争を回避する観点でも、本条及び個別契約に基づきシステム開発についてのユーザの習熟度／ユーザの業務内容についてのベンダの習熟度に応じて、事前に双方で役割分担を適切に行うとともに実際にシステム開発を進めるにあたって、その役割を確実に果たしていくことが重要である。

第1項は、システム開発は、ユーザとベンダの共同作業であるという基本認識を確認している。ソフトウェア開発に関する紛争は、このような基本認識の欠如に起因するところが大きい。上記の通り、システム開発においては、ユーザとベンダそれぞれの役割を果たす必要があるが、各自の役割を果たすためには、相手方の協力が不可欠である。もっとも、ここでいう「協力」というのはただ単に相手方のやりたい事を進めるための前向きな推進だけを意味するのではなく、そのまま開発を進めた場合に生じるリスクに関する情報提供や、進捗状況によっては計画の見直しを提案することも含まれると解される。
　第2項は、詳細な役割分担については、ユーザ・ベンダ間の個別の状況に応じて、別紙重要事項説明書において定めることとしている。
　第3項は、各当事者が実施すべき共同作業又は分担作業を怠った場合には、それぞれ責任を負うことになることを確認している。例えば、ユーザが実施すべき共同作業又は分担作業に関して債務不履行があった場合には、結果としてソフトウェアが完成しなかったとしてもベンダは債務不履行責任を負わないことや、ベンダの債務不履行責任に関する損害賠償請求においてユーザ側の過失相殺事由として勘案すること、さらに場合によってはベンダよりユーザに対する損害賠償請求を行うことなどが考えられる。

Frame15

（連絡協議会の設置）

第4条 ユーザ及びベンダは、本件業務が終了するまでの間、その進捗状況、リスクの管理及び報告、ユーザ及びベンダ双方による共同作業及び各自の分担作業の実施状況、システム仕様書に盛り込むべき内容の確認、問題点の協議及び解決その他本件業務が円滑に遂行できるよう必要な事項を協議するため、連絡協議会を開催するものとする。但し、システム基本契約及び別紙重要事項説明書の内容の変更は第2条（契約内容の確定及び変更等）に従ってのみ行うことができるものとする。

2) 連絡協議会は、原則として、別紙重要事項説明書で定める頻度で定期的に開催するものとし、それに加えて、ユーザ又はベンダが必要と認める場合に随時開催するものとする。

3） 連絡協議会には、ユーザ及びベンダ双方の責任者、主任担当者及び責任者が適当と認める者が出席する。また、ユーザ及びベンダは、連絡協議会における協議に必要となる者の出席を相手方に求めることができ、相手方は合理的な理由がある場合を除き、これに応じるものとする。

4） ベンダは、連絡協議会において、別途ユーザ・ベンダ間にて取り決めた様式による進捗管理報告を作成して提出し、当該進捗管理報告に基づいて進捗状況を確認するとともに、遅延事項の有無、遅延事項があるときはその理由と対応策、推進体制の変更（人員の交代、増減、再委託先の変更など）の要否、セキュリティ対策の履行状況、別紙重要事項説明書の変更を必要とする事由の有無、別紙重要事項説明書の変更を必要とする事由があるときはその内容などの事項を必要に応じて協議し、決定された事項、継続検討とされた事項並びに継続検討事項がある場合は検討スケジュール及び検討を行う当事者等を確認するものとする。

5) ユーザ及びベンダは、本件業務の遂行に関し連絡協議会で決定された事項について、システム基本契約及び別紙重要事項説明書に反しない限り、これに従わなければならない。

6) ベンダは、連絡協議会の議事内容及び結果について、書面により議事録を作成し、これをユーザに提出し、その承認を得た後に、ユーザ及びベンダ双方の責任者がこれに記名押印の上、それぞれ1部保有するものとする。ベンダは、議事録の原案を原則として連絡協議会の開催日から○日以内に作成して、これをユーザに提出し、ユーザは、これを受領した日から○日以内にその点検を行うこととし、当該期間内に書面により具体的な理由を明示して異議を述べない場合には、ベンダが作成した議事録を承認したものとみなすものとする。

7) 前項の議事録は、少なくとも当該連絡協議会において決定された事項、継続検討とされた事項及び継続検討事項がある場合は、検討スケジュール及び検討を行う当事者の記載を含むものとする。

Frame16

本条は、ユーザ及びベンダによる連絡協議会の開催を定期的に開催することを定める。

連絡協議会は、プロジェクトの重要事項を検討し、決定していく重要な場であり、ほとんどのソフトウェア開発プロジェクトで設けられている。こうした会議体の運営で重要なことは、その場で議論された内容を明確に記録に残しておくことである。具体的には議事録を作成し、それに必要な事項を明確に記載することが求められる。しかし、上手くいかないプロジェクトでは、こうした運用が適切になされていない場合がしばしばある。

第1項は、協議会で協議すべき事項について定めた。本モデル契約書では、進捗状況・リスクの管理及び報告、ユーザ及びベンダによる共同作業及び各自の分担作業の実施状況、問題点の協議・解決その他本件業務が円滑に遂行できるよう必要な事項について協議会を開催することとした。
　第2項は、連絡協議会の開催頻度について、別紙重要事項説明書に基づくことを定める。
　第3項は、ユーザ及びベンダの責任者及び主任担当者36以外の者、例えば、開発担当者やユーザ内の従業員等の出席を認め、相手方の出席要請に応じる義務も明記している。
　第4項は、ベンダの責任者が、連絡協議会の席上、「進捗管理報告」に基づいて報告を定期的に行う進捗管理を義務づけている。システム開発においては、想定外の事象が生じることがままあり、当時事象を早期にユーザ・ベンダ間で共有した上で、その事象にどう対応していくかを協議の上で決定し、実行することが重要である。東京高判平成25年9月26日金融商事判例1428号16頁では、当初の想定と異なる要因が生じる等の状況の変化が明らかとなり、想定していた開発費用、開発スコープ、開発期間等について相当程度の修正を要すること、更にはその修正内容がユーザの開発目的等に照らして許容程度を超える事態が生じることもあるから、ベンダとしては、プロジェクトマネジメント義務の具体的な内容として、そのような局面に応じて、ユーザのシステム開発に伴うメリット、リスク等を考慮し、適時適切に開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説明義務を負う、と判示している。また、東京地判平成28年4月28日判例時報2313号29頁でも、ベンダは、解決すべき必要がある懸案事項等の発生の徴候が認められた場合には、それが本格的なものとなる前に、そのような予防や回避について具体的にユーザに対して注意喚起をすべきであるし、懸案事項等が発生した場合は、それに対する具体的な対応策及びその実行期限を示し、対応がされない場合に生ずる支障、複数の選択肢から一つを選択すべきには、対応策の容易性などそれらの利害得失等を示した上で、必要な時期までに原告において対応することができるように導く義務があると判示している。これらの裁判例では、ベンダが判示されているような事項を必ずしも十分説明しなかったことによって責任を負うとされているが、これらの事項については本項に基づく進捗管理報告においてユーザに示すことができるものであり、都度履践をしていけば、後に紛争の原因となるような大きなトラブルへの発展を防ぐことができる。
　第5項は、連絡協議会で決定した事項が当事者により遵守されなければ無意味であるので、これに従うことを義務づけている。
　第6項は、協議会の議事録の作成をベンダに義務づけるとともに、ユーザが記名押印を怠る場合に備えてみなし承認規定を設けている。
　第7項は、議事録の必要的記載事項として、連絡協議会において決定された事項、継続検討とされた事項、継続検討事項がある場合は検討スケジュールと検討を行う当事者の記載を義務づける。

Frame17

（ユーザがベンダに提供する資料等及びその返還）

第5条 ユーザは、ベンダに対し、本件業務に必要な資料、機器、設備等（以下「資料等」という。）の開示、貸与等を行うものとする。

2) ユーザが前項に基づきベンダに提供した資料等の内容に誤りがあった場合又はユーザが提供すべき資料等の提供を遅延した場合、これらの誤り又は遅延によって生じた費用の増大、完成時期の遅延、契約不適合などの結果について、ベンダは責任を負わない。

3) ベンダは、ユーザから提供を受けた資料等を善良なる管理者の注意義務をもって管理し、双方が合意した返還日又はユーザから請求があったときに、これらを返還する。

4) 資料等の提供及び返還にかかる費用は、ユーザが負担する。

Frame18

システム開発においては、ユーザからベンダへの情報提供が不可欠であり、ユーザはベンダにさまざまな資料等を提供することになる。また、ベンダは、ユーザに対し、必要な資料等の提供を要求できることを明確に規定しておく必要がある。

本条では、ユーザからベンダに提供される資料等の提供、保管、使用、返還について定める。
　第1項は、ユーザは、ベンダに対し、受託業務遂行に必要な資料等の開示、貸与等を行うことを定める。
　第2項は、資料等の提供について、ユーザが一定の役割を負担することを明確にするために、ユーザが提供する資料等の内容の誤りがあった場合又はユーザが資料等の提供を遅延した場合は、それによって生じた開発費用の増大、完成時期の遅延、契約不適合などの結果について、ベンダは責任を負わないものと定める。
　第3項は、ベンダの資料等の保管義務及び返還義務について定める。
　第4項は、資料等の提供がユーザの責務であることから、返還にかかる費用がユーザの負担となることを定め、これにより、返還費用に関するトラブル予防を図ることとした。

Frame19

（再委託）

第6条 ベンダは、ベンダの責任において、本件業務の一部を第三者に再委託することができる。但し、ベンダは、ユーザから請求があった場合には、再委託先の名称及び住所等、再委託先を特定しうるだけの情報をユーザに通知しなければならない。当該第三者に再委託することが不適切となる合理的な理由が存する場合、ユーザは、その理由を書面によりベンダに通知することにより、当該第三者に対する再委託の中止を請求することができる。なお、ユーザから再委託の中止の請求をベンダが受けた場合は、作業期間、納期または委託料等の内容の変更について、第2条⑥に準じて協議を行い、合理的な範囲で合意するものとする。

2) ベンダは、再委託先との間で、再委託に係る業務を行わせる場合、本契約に基づいてベンダがユーザに対して負担するのと同様の義務を、再委託先に負わせる契約を締結するものとする。

3) ベンダは、再委託先の履行についてユーザに帰責事由がある場合を除き、自ら業務を遂行した場合と同様の責任を負うものとする。

Frame20

本モデル契約書においては、パッケージを利用したシステム開発の取引実態により適合するものとして、モデル取引・契約書第二一版第7条37【B案】を採用している。再委託の可否については、①再委託先の技術力についての保証がなく、また機密保持の観点からも原則禁止とし委託者の承諾を要するとすべき（原則禁止【Ａ案】）との考えと②再委託を原則禁止としてしまうことによって業務の遂行における柔軟性が失われ結局提供される技術の質も効率も損なわれてしまうので原則自由とすべき（原則自由【Ｂ案】）との考えの対立があり、モデル取引・契約書第二一版においても、両論が併記されている。

本モデル契約書が前提とする取引は、パッケージソフトウェアを利用すること、ユーザが中小企業等であることなどに特色がある。この観点より本論点を検討すると、そもそも多くの場合第三者製品（パッケージソフトウェア）をシステムのコアの部分に据えるのであるから、再委託を厳しく制限することは現実的ではないこと、また原則再委託自由としてもユーザが要求するときは再委託先を開示させることとし、かかる再委託先を使うことを止めさせることに合理的な理由があるときはかかる再委託を止めさせることができるとすれば弊害も少ないものと考えられる。

従って、第1項においては、再委託は原則自由とし、ユーザが要求するときには再委託先を開示し、ユーザは合理的な理由があるときには再委託を中止できることとした。ここで、「合理的な理由」とは、例えば、現に再委託先がユーザと競合する企業のソフトウェア開発業務に関与し、ユーザ独自の業務ノウハウが競合先に流出しかねない危険があること、再委託先の情報セキュリティ確保の措置が不十分であること、以前に当該再委託先に業務を委託したが適切に業務が遂行されなかった実績があること、再委託先の経営権に関する紛争の存在、再委託先の業務内容が不健全であること、ユーザにおいて制定している委託先選定基準への不適合等の状況が想定される。

ユーザからのかかる再委託の中止請求については、特に再委託先での作業が既に進んでいるときなど、作業期間、委託料、納期等に影響が出ることが予想されるので、そのような場合には、契約変更手続（システム基本契約書第2条⑥）に準じて契約条件の変更に係る協議を行い、ユーザ及びベンダは、合理的な範囲での変更合意を行う義務を負うこととしてある。例えば、ユーザがベンダからの合理的な委託料増額案に対して応じないときは、ベンダに対して債務不履行責任を負うことになり、増額分について損害賠償責任を負うこともあり得る。なお、ユーザは合理的な範囲の契約変更を受け容れられない場合には、各本件業務にかかる契約の解約を選択することもできる。この場合、ユーザは、原則としてベンダに対し、既になされた業務の対価を支払い、発生した損害を賠償しなければならないものと考えられる。

第2項は、ユーザとベンダ間の本契約に基づくベンダの義務を、再委託先にも負わせることを義務づけている。

第3項は、ユーザが再委託について承諾したとはいっても、ベンダは自らが業務を遂行した場合と同様の責任を負うものとする。この場合においても、再委託先の履行に関し、ユーザに帰責事由がある場合についてまでベンダに責任を負わせることは酷なのでベンダの責任の範疇から除かれている。

Frame21

（秘密情報の取扱い）

第7条 ユーザ及びベンダは、本件業務の遂行のため、相手方より提供を受けた技術上又は営業上その他業務上の情報のうち、相手方が書面により秘密である旨指定して開示した情報、又は口頭により秘密である旨を示して開示した情報で開示後○日以内に書面により内容を特定した情報（以下あわせて「秘密情報」という。）を第三者に漏洩してはならない。但し、次の各号のいずれか一つに該当する情報についてはこの限りではない。また、ユーザ及びベンダは秘密情報のうち法令の定めに基づき開示すべき情報を、当該法令の定めに基づく開示先に対し開示することができるものとする。

① 秘密保持義務を負うことなくすでに保有している情報
② 秘密保持義務を負うことなく第三者から正当に入手した情報
③ 相手方から提供を受けた情報によらず、独自に開発した情報
④ 本契約に違反することなく、かつ、受領の前後を問わず公知となった情報

2) 秘密情報の提供を受けた当事者は、当該秘密情報の管理に必要な措置を講ずるものとする。

3) ユーザ及びベンダは、秘密情報について、本契約の目的の範囲内でのみ使用し、本契約の目的の範囲を超える複製、改変が必要なときは、事前に相手方から書面による承諾を受けるものとする。

4) ユーザ及びベンダは、秘密情報を、本契約の目的のために知る必要のある各自（本契約に基づきベンダが再委託する場合の再委託先を含む。）の役員及び従業員に限り開示するものとし、本契約に基づきユーザ及びベンダが負担する秘密保持義務と同等の義務を、秘密情報の開示を受けた当該役員及び従業員に退職後も含め課すものとする。

5) 秘密情報の提供及び返還等については、第5条（ユーザがベンダに提供する資料等及びその返還）に準じる。

6) 秘密情報のうち、個人情報に該当する情報については、第8条が本条の規定に優先して適用されるものとする。

7) 本条の規定は、本契約終了後、○年間存続する。

Frame22

ソフトウェア開発においては、ユーザ、ベンダが互いに相手方の秘密情報に接することが想定されることから、本条では、それぞれの秘密保持義務を定める。

第1項では、秘密保持義務の対象となる情報を特定している。本項では、対象となる情報を明確にするため、相手方が書面により秘密である旨指定して開示した情報であるか、または口頭により秘密である旨通知して開示した情報は、開示後○日以内に書面により内容を特定することを必要としている。第1号から第4号は、秘密情報の例外規定である。
　第2項は、秘密情報の提供を受けた当事者は、秘密情報の管理に必要な措置を講ずることとしている。秘密情報の秘密管理性及び非公知性を維持するためには、提供を受けた当事者に秘密情報を適正に保護する体制の構築を義務づけておく必要がある。秘密情報の管理については、物理的、技術的、人的、組織的管理措置を実効的に構築しなければならない。
　第3項は、秘密情報の目的外使用を禁止し、複製、改変については相手方の承諾を要件としている。
　第4項は、システム基本契約書及び個別契約に基づき乙が再委託する場合の再委託先も含め、秘密情報の開示を受けた役員、従業員、退職者へも秘密保持義務を負わせるよう求めている。開示を受けた者が退職してしまった場合に、第三者に秘密情報が出て行くことのないよう退職者についても秘密保持義務を課すことを義務づけている。秘密情報の開示を受ける担当者等に秘密保持の誓約書を義務づけるなど、より具体的な方策を定めておくことも考えられる。退職者に対して秘密保持義務を課す場合には、一般的に秘密保持契約を締結する必要がある。特に、現職の従業者等及び退職者と秘密保持契約を締結する際には、秘密保持義務が必要性や合理性の点で公序良俗違反（民法第90 条）とならないよう、その立場の違いに配慮しながら、両者がコンセンサスを形成できるようにすることが重要である。
　本条で定める秘密情報と次条で定める個人情報は、公知情報でない個人情報について適用が重複する場合もありうるので、第6項でその優先関係について取り決めている。
　第7項は、秘密保持義務は通常契約期間より長期の存続が必要であるため、本契約終了後一定期間（秘密情報の性質から鑑みて合理的な期間）、存続させるものとしている。

Frame23

（個人情報）

第8条 ベンダは、個人情報の保護に関する法律（本条において、以下「法」という。）に定める個人情報のうち、本件業務遂行に際してユーザより取扱いを委託された個人データ（法第2条第6項に規定する個人データをいう。以下同じ。）及び本件業務遂行のため、ユーザ･ベンダ間で個人データと同等の安全管理措置（法第20条に規定する安全管理措置をいう。）を講ずることについて、別紙重要事項説明書その他の契約において合意した個人情報（以下あわせて「個人情報」という。）を第三者に漏洩してはならない。なお、ユーザは、個人情報をベンダに提示する際にはその旨明示するものとする。また、ユーザは、ユーザの有する個人情報をベンダに提供する場合には、個人が特定できないよう加工した上で、ベンダに提供するよう努めるものとする。

2) ベンダは、個人情報の管理に必要な措置を講ずるものとする。

3) ベンダは、個人情報について、本契約の目的の範囲内でのみ使用し、本契約の目的の範囲を超える複製、改変が必要なときは、事前にユーザから書面による承諾を受けるものとする。

4) 個人情報の提供及び返還等については、第5条（資料等の提供及び返還）を準用する。

5）　　第6条第1項の規定にかかわらず、ベンダはユーザより委託を受けた個人情報の取扱いを再委託してはならない。但し、当該再委託につき、ユーザの事前の承諾を受けた場合はこの限りではない。

Frame24

個人情報保護法第22条に基づいて委託者は、委託先に対する監督の責任を負うことから、ソフトウェア開発委託契約においても、委託先の監督について取り決めておく必要がある38。また、個人情報は、秘密保持義務の対象となる秘密情報とは対象、契約で定めることが望まれる事項が異なるので、個人情報保護に関する条項を秘密保持とは別途規定してある。

第1項は、ベンダに個人情報保護を義務づける。「その他の契約」とは、システム基本契約書及び別紙重要事項説明書以外に、個人情報の取扱いに関する委託契約を別途締結するケースを想定している。また、ユーザ保有の個人情報については、当該個人に対し責任を持っているユーザ自身がより安全な取扱いにつき配慮すべきである。例えば、テスト時に使用するデータをユーザ側がダミー化する等してベンダに渡す等の配慮を行う必要がある。
　第2項は、ベンダに必要な安全管理措置を義務づける。
　第3項は、ベンダに個人情報の目的外の使用を禁止し、複製、改変についてはユーザの承諾を要件としている。
　第4項は、個人データの提供、返還・消去・廃棄に関する事項については、第5条（資料等の提供及び返還）を準用する。
　第5項は、再委託がベンダの裁量で可能な場合にも、個人情報の取扱いの再委託についてはユーザの事前承諾を要するものとしている。個人情報保護委員会が公表している「個人情報の保護に関するガイドライン（通則編）」においても、委託先が再委託を行う際に、委託元は、委託先が再委託する相手方、再委託する業務内容、再委託先の個人データの取扱方法等について、委託先から事前報告を受け又は承認をすることが望ましいとされており、この趣旨に対応する39。

個人情報をどのように取り扱うのかについては、個人情報保護委員会やユーザの事業分野に関する所管官庁が公表しているガイドライン等を踏まえた上で、事前に具体的内容について十分協議して、委託者と受託者の責任分担を明確にしておく必要がある。

Frame25

（報告書の著作権）

第9条 ベンダがユーザに対して提出する報告書に関する著作権（著作権法第27条及び第28条の権利を含む。）は、ユーザ又は第三者が従前から保有していた著作物の著作権を除き、ベンダに帰属するものとする。

2) ユーザは、前項の報告書又はその複製物を、本件システムを利用するために必要な範囲で、複製、翻案することができるものとする。

Frame26

本条は、全ての各本件業務に共通して問題となりうる報告書に関する著作権の帰属について規定する。

なお、本契約における成果物となるべきソフトウェア等に関する著作権については、ソフトウェア設計･制作業務に関する別紙重要事項説明書で定める。

Frame27

（損害賠償）

第10条 ユーザ及びベンダは、本契約の履行に関し、相手方の責めに帰すべき事由により損害を被った場合、相手方に対して、法令に基づく損害賠償を請求することができる。但し、別紙重要事項説明書に請求期間が定められている場合は、法令に基づく請求期間にかかわらず重要事項説明書に定める期間の経過後は請求を行うことができない。

2) 本契約及び個別契約の履行に関する損害賠償の累計総額は、債務不履行、（契約不適合責任を含む。）不当利得、不法行為その他請求原因の如何にかかわらず、帰責事由の原因となった業務に係る別紙重要事項説明書に定める損害賠償限度額を限度とする。

3) 前項は、損害が損害賠償義務者の故意又は重大な過失に基づくものである場合に　　は適用しないものとする。

Frame28

本条は、債務不履行責任（契約不適合責任を含む。）、不法行為責任等に基づく損害賠償責任の制限について規定する。情報システム開発の特殊性を考慮して、損害賠償責任の範囲・金額・請求期間について、これらを制限する規定をおくべきかどうか、またその内容をどのようにすべきかについては、ユーザ・ベンダ間で対立するところであるが、本モデル契約書では、具体的な損害賠償の上限額、損害の範囲・請求期間の制限については、個々の情報システムの特性等に応じて、個別に決定できるように記述している。

第1項では、損害賠償責任の成立を、帰責事由のある場合に限定している。なお、損害の範囲について制限を設ける場合には、通常損害のみについて責任を負い、特別事情による損害、逸失利益についての損害や間接損害を負わないとする趣旨から、直接の結果として現実に被った通常の損害に限定して損害賠償を負う旨規定することが考えられる。
　また、本項では損害賠償請求を行う場合一般について請求期間を重要事項説明書で定めることができると定めている。当該期間をどのように設定するかは、個別具体的な事情を勘案して定められるべきである。

第2項は、損害賠償の累積総額の上限額を設定する規定で、請求原因の構成如何に関わらず上限が設定されている。なお、解除に伴う原状回復としての委託料の返還は、損害賠償とは異なることに注意が必要である。例えばベンダ側に重大な債務不履行があり、ユーザから本件業務にかかる契約を解除され、原状回復として委託料全額を返還したとしても、委託料の返還は損害賠償の支払いではないので、損害賠償の上限を決める累計総額には加算されないことになる。すなわち、委託料250万円が上限となる規定があり、委託料が支払い済みである場合でベンダの債務不履行で解除となったとき、ベンダは250万円の委託料の返還に加え、250万円を上限とする損害賠償を請求される可能性が出てくることになる。

第3項は、第2項の免責は、損害賠償義務者に故意重過失ある場合には適用されないことを明記する場合の規定である。損害発生の原因が故意による場合には、判例では免責・責任制限に関する条項は無効となるものと考えられているし、重過失の場合にも同様に無効とするのが、支配的な考え方になっていることから設けられた規定である。重過失については、必ずしもその意義について統一的な理解がされているわけではないものの、どのような理解の分かれ方については一定のコンセンサスがあるところである40。

一つは重過失とは「ほとんど故意に等しい注意欠如の状態」であるという考え方である。最高裁の判例においても失火責任法における重大な過失について、「通常人に要求される程度の相当な注意をしないでも、わずかの注意さえすれば、たやすく違法有害な結果を予見することができた場合であるのに、漫然これを見過ごしたような、ほとんど故意に近い著しい注意欠如の状態を指す」としたものがある（最判昭和32年7月9日民集11巻7号1203頁）これは重過失は故意と同様に心理状態として捉えられる。

もう一つは、重過失は「注意義務違反の程度が著しい場合」と捉える考え方である。ただ、こう考える場合であっても、そこには義務違反の結果が重大である（義務からの乖離が著しい）という類型と違反した義務自体が重大である（当該義務が基本的なものであり、それすら怠っていた）という類型の2つが含まれている。

裁判例においては、後者の考え方に準じて重過失について結果の予見が容易に可能でありかつ結果の回避も容易に可能であることを要件とした著しい注意義務違反であるとするものがあり（東京高判平成25年7月24日判例時報2198号27頁）、またシステム開発により即して「通常のベンダとしての裁量を逸脱して社会通念上明らかに講じてはならない不合理な対応策を取った」か、あるいは「ベンダとして社会通念上明らかに講じなければならない対応策を怠った」かを判断するものもある（東京地判平成31年3月20日公刊物未掲載（平成25年（ワ）第31378号・平成26年（ワ）第9591号））。また、システム開発に関連して実際に重過失が認定された例はまだ多くはないが、ベンダがSQLインジェクション対策を講じなかったことで個人情報が流出したという事案について、経済産業省及びIPAがウェブアプリケーションに対する代表的な攻撃手法としてSQLインジェクション攻撃を挙げ、対策するよう注意喚起していたことから結果の予見が容易であり、かつ、具体的な対策に多大な労力や費用はかからず、結果回避も容易であったとして、重過失を認定した例がある（東京地判平成26年1月23日判例時報2221号71頁。）

なお、遅延損害金についてシステム基本契約書では定めをおいていない。法定利率である年3%（民法第404条。但し、3%は令和2年4月1日時点のもので、3年ごとに変動しうる。）を超える割合の遅延損害金を定める場合は、別紙重要事項説明書上の各本件業務における「特約条項」欄に記載されたい。

Frame29

（解除）

第11条 ユーザ又はベンダは、相手方に次の各号のいずれかに該当する事由が生じた場合には、何らの催告なしに直ちに本契約の全部又は一部を解除することができる。

① 重大な過失又は背信行為があった場合
② 支払いの停止があった場合、又は仮差押、差押、競売、破産手続開始、民事再生手続開始、会社更生手続開始、特別清算開始の申立があった場合
③ 手形交換所の取引停止処分を受けた場合
④ 公租公課の滞納処分を受けた場合
⑤ その他前各号に準ずるような本契約を継続し難い重大な事由が発生した場合

2) ユーザ又はベンダは、相手方が本契約のいずれかの条項に違反し、相当期間を定めてなした催告後も相手方の債務不履行が是正されない場合、又は是正される見込みがない場合は、本契約の全部又は一部を解除することができる。

3) ユーザ又はベンダは、第1項各号のいずれかに該当する場合又は前項に定める解除がなされた場合、相手方に対し負担する一切の金銭債務につき相手方から通知催告がなくとも当然に期限の利益を喪失し、直ちに弁済しなければならない。

Frame30

本条は、本契約の解除に関する条項である。本契約は、システム基本契約書と重要事項説明書から構成されるが、本条はその全部又は一部について解除する場合の要件を定めている。

第1項は、取引上の重大な事由について、無催告解除事由として規定する。
第2項は、個別の契約違反についての催告解除及び無催告解除について定める。
第3項は、期限の利益喪失に関する特約である。民法にも期限の利益の喪失事由（民法第137条）が規定されているが、その他の信用不安事由等も加えたものである。事由の軽重により、当然に期限の利益を喪失する第１項所定の場合と解除により期限の利益を喪失する第２項の場合とに分けた。

システム開発をめぐる紛争においては、システム開発の案件について、特定の個別契約に債務不履行がある場合に、一連の流れの中にある別の個別契約を解除したり、その個別契約に基づいて支払った委託料を損害として請求できるかが問題となることがある。

システム開発をめぐる紛争においては、大きく分けて、①同時並行的な履行によって達成されることが予定されていた複数の契約間で問題となるケースと、②本モデル契約のような多段階契約における前工程の契約と後工程の契約との間で問題となるケースが　ある。

①の類型のケースでは、最判平成8年11月12日民集50巻10号2673頁において「同一当事者間の債権債務関係がその形式がその甲契約又は乙契約といった二個以上の契約から成る場合であっても、それらの目的とするところが相互に密接に関連づけられていて、社会通念上、甲契約又は乙契約のいずれかが履行されるだけでは契約を締結した目的が全体としては達成されないと認められる場合には、甲契約上の債務の不履行を理由に、その債権者が法定解除権の行使として甲契約と併せて乙契約を解除することができるものと解するのが相当である」と判示されており、この判例の規範に照らして判断されているものが多い。具体的には、ソフトウェア開発契約を締結した後に当該開発の対象となるシステムに新たな機能を追加するために要する負担に関する合意があった場合に、もともとの契約が瑕疵担保責任（現行法では契約不適合責任。以下同じ）に基づいて解除されたときに当該合意も解除できるか問題となったケース（東京地判平成25年5月28日判例タイムズ1416号234頁・積極）、ソフトウェア開発契約の後に締結された導入支援契約について開発契約が瑕疵担保責任に基づいて解除された場合に導入支援契約も解除できるか問題となったケース（東京高判平成26年1月15日公刊物未掲載（平成25年（ネ）第3952号・平成25年（ネ）第5742号）・消極）、旧システムのマイグレーション作業に関する委託契約を締結した後に、当該マイグレーション作業による成果物に関するシステムテストや旧システムになかった新機能を付加するためのプログラム開発を行うための契約、新システムとの連携のために市販のソフトをカスタマイズするための契約及び新システムの機能を追加・変更するための要件定義作業を行うための契約を締結したケースで当初のマイグレーションに係る契約が履行不能解除されるときにその後の契約も解除できるのか問題となったケース（東京地判平成28年10月31日公刊物未掲載（平成23年（ワ）第10498号・平成23年（ワ）第11230号）・積極）、システム開発の請負契約と当該システムを作動させるためのソフトウェア・ハードウェアの売買契約が締結された場合に、前者の履行遅滞解除に伴い、後者の契約の解除も認められるか問題となったケース（東京地判平成28年11月30日公刊物未掲載（平成25年（ワ）第9026号・平成27年（ワ）第25003号）・積極）などがある。

一方、②の類型では、東京地判平成31年3月20日公刊物未掲載（平成25年（ワ）第31378号・平成26年（ワ）第9591号）において、明確に上記平成8年最判との関係について検討が加えられており、当該事案においては各個別契約の共通の契約目的は各契約の締結と履行の終了の積み重ねを通じて、順次段階的に達成されていくことが予定されているものであって、数個の契約の同時並行的な履行によって達成されることが予定されていた上記平成8年最判の事案とは異なる旨判示し、後工程の履行不能により、前工程の契約を解除することを認めなかった。多段階契約では、ユーザ及びベンダが各工程における成果を検収等によってその目的の達成を確認した上で、次工程に進んでいく構造を取る以上、後工程における結果自体をもって前工程の契約を解除等することを当事者としても意図しないものと考えられる。もっとも、後工程でトラブルが生じた際に、当該トラブルが前工程に起因するというケースはあると思うが、このような場合には正面から前工程の契約について債務不履行等があったかを検討し、当該前工程の契約上の期間制限の範囲内で追及すれば足りる（例えば、ソフトウェア制作の段階にトラブルが生じた場合に、当該トラブルが要件定義支援又は外部設計支援に起因する場合には、それらのフェーズにおいてベンダに善管注意義務がなかったかを検討することとなる。）。

Frame31

（権利義務譲渡の禁止）

第12条 ユーザ及びベンダは、互いに相手方の事前の書面による同意なくして、本契約上の地位を第三者に承継させ、又は本契約から生じる権利義務の全部若しくは一部を第三者に譲渡し、引き受けさせ若しくは担保に供してはならない。

Frame32

本条は、契約上の地位の移転、債権譲渡、担保化の禁止に関する規定である。なお、民法上当事者が債権譲渡を禁止又は制限する旨の意思表示をしたとしても、債権譲渡の効力は妨げられない（民法第466条第2項）が、譲受人その他の第三者が当該意思表示の存在を知り、又は重過失により知らなかった場合に、債務者は当該第三者に債務の履行を拒むことができ、かつ、譲渡人に対する弁済その他の債務を消滅させる事由をもってその第三者に対抗することができる（民法第466条第3項）ため、制限する旨の規定を置くことはなおも有効である。

Frame33

（協議）

第13条 本契約に定めのない事項又は疑義が生じた事項については、信義誠実の原則に従いユーザ及びベンダが協議し、円満な解決を図る努力をするものとする。

Frame34

本条は、一般の取引基本契約に定められているのと同様の協議解決条項である。

Frame35

（和解による紛争解決・合意管轄）

第14条　本契約に関し、ユーザ及びベンダに紛争が生じた場合、ユーザ及びベンダは、次項の手続をとる前に、紛争解決のため第4条に定める連絡協議会を開催し協議を充分に行うとともに、次項及び3項に定める措置をとらなければならない。

2）　　　前項所定の連絡協議会における協議でユーザ・ベンダ間の紛争を解決することができない場合、本条第４項に定める紛争解決手続をとろうとする当事者は、相手方に対し紛争解決のための権限を有する代表者又は代理権を有する役員その他の者との間の協議を申し入れ、相手方が当該通知を受領してから○日以内に（都市名）において、本条第4項に定める紛争解決手続以外の裁判外紛争解決手続（以下「ADR」という。）などの利用も含め誠実に協議を行うことにより紛争解決を図るものとする。
3）前項による協議又はADRによって和解が成立する見込みがないことを理由に当該協議又はADRが終了した場合、ユーザ及びベンダは、法的救済手段を講じることができる。

4）　　　本契約に関し、訴訟の必要が生じた場合には、○○地方裁判所を第一審の専属的合意管轄裁判所とする。

Frame36

本条第1項、第2項は、本契約に関し、紛争が生じた場合、法的救済手段を講じる前段階として、当事者間でまず十分協議し、解決に尽力すべきことを規定している。

第3項は、当事者間による解決が不可能な場合、当事者は、法的救済手段（仲裁又は訴訟）による解決を求めることができることを規定している。

第4項は、裁判所に訴訟提起する場合を前提に、専属的な合意管轄（民事訴訟法第11条）について規定する。なお、特許権、実用新案権、回路配置利用権又はプログラムの著作物についての著作者の権利に関する訴えについては、東京高等裁判所、名古屋高等裁判所、仙台高等裁判所又は札幌高等裁判所の管轄区域内に所在する地方裁判所については東京地方裁判所の管轄、大阪高等裁判所、広島高等裁判所、福岡高等裁判所又は高松高等裁判所の管轄区域内に所在する地方裁判所については大阪地方裁判所の管轄とされる（民事訴訟法第6条第1項）が、合意管轄も認められている（民事訴訟法第13条第2項）ので、本条の適用範囲に含まれる。

Frame37



○○○○年○○月○○日



ユーザ：

ベンダ：

重要事項説明書

重要事項説明書は、契約によって構成が異なるため、別冊に代表的なパターンを掲載してある。ここでは、重要事項説明書記載の契約条項について解説する。

要件定義～導入教育支援業務までの契約約定一覧は以下の通りである。

A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）

B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）

C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル）

D　外部設計支援業務契約

E　ソフトウェア設計・制作業務契約

F　構築・設定業務契約

G　データ移行支援業務契約

H　運用テスト支援業務契約

I　導入教育支援業務契約

J　保守業務契約

K　運用支援業務契約



契約条項の一覧

A

B

C

D

E

F

G

H

I

契約の成立

○

○

○

○

○

○

○

○

○

パッケージソフトウェア候補の選定支援における善管注意義務

○









パッケージソフトウェアの選定支援における善管注意義務


○

○







ベンダの善管注意義務

○

○

○

○



○

○

○

業務終了の確認

○

○

○

○



○

○

○

機器の売買等


○

○

○

○

○

○

○

○

本件システムの納入





○

○




本件システムの検収





○

○




本件パッケージ固有の契約不適合





○

○




本件システムについての契約不適合責任





○

○




危険負担





○

○




特許権等の帰属





○

○




著作権の帰属





○

○




知的財産侵害の責任





○

○






保守業務～運用支援業務までの契約約定一覧は以下の通りである。

J　保守業務契約

K　運用支援業務契約

契約条項一覧

J

K

契約の成立

○

○

機器等の売買等

○

○

保守業務の範囲

○


運用支援業務の範囲


○

サービスの範囲（サービス仕様書による）

○

○

設置場所への立ち入り等

○

○

遠隔操作によるサービス

○

○

製造打ち切り、保守部品提供の中止の際の取扱い

○


老朽化装置の取扱い

○


交換部品の所有権

○


秘密保持

○


設置場所の変更

○

○

設置場所の整備

○

○

不具合の調査費用

○


使用地域の制限

○

○

パッケージ本体の不具合

○


有効期間

○

○

支払い遅延

○

○



A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）Frame38

別紙１のパッケージカスタマイズ取引契約モデルの上流工程前半に対応する規定である。

第1条は契約の成立についての規定である。

第2条はパッケージソフトウェアの候補選定支援における善管注意義務についての規定である。
　本モデル契約書のいわゆる上流工程における最も重要な作業は、パッケージソフトウェア（本件システムの構築に利用する第三者が権利を有するソフトウェア、SaaS/ASP。以下「本件パッケージ」という。）の選定である。本モデル契約書においては「A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）」において本件パッケージ候補の選定が、「B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）」、「C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル）」において本件パッケージの選定がユーザによって行われ、ベンダはその支援業務を行う。本件パッケージは本モデル契約の成果物となる本件システムの技術的中核となるものであり、また、利用・契約不適合責任等の法的問題の分野においても広い範囲にわたってその固有の条件が適用されることにより重要な意味をもつ。そして下流過程である設計、構築・設定、保守、運用の契約条件に対しても大きな影響を与えるものである。

本モデル契約書が想定する中小企業等ユーザは、パッケージソフトウェア等に関する専門的知識を有するベンダに比べ、そのようなパッケージソフトウェアに関する知見に欠けている。しかしながらユーザの業務内容及びプロジェクトゴールを熟知しているのはユーザ自身である。また上流過程における役割分担においてユーザがベンダに頼りきり、いわば丸投げ状態を認めることはユーザとベンダのシステム契約についての理解の不一致を招き、こうした契約における契約条件の透明性・明確性の妨げとなる。

そこで本モデル契約書では、最終的に本件パッケージの選定を行う者をユーザとし、ベンダはユーザに対し、パッケージソフトウェアに関する情報提供をしつつ、推奨するパッケージをユーザに提案する建付けとしている。そして前述した本モデル契約が想定する中小企業等ユーザのパッケージソフトウェアについての知見の不足に対応するために、当該推奨に係るパッケージの提案に関してベンダは、業界で一般的に認められる専門知識とノウハウにもとづく善良な管理者としての注意義務を負わせるものとした。また、これらの専門知識とノウハウに基づき、ベンダが適切と判断したときは、本件パッケージ候補が存在しないことをユーザに進言しなければならないとした。

「善良なる管理者の注意義務を果たした」かどうかは、情報処理技術に関する業界で一般的に要求される専門知識・ノウハウにもとづく注意義務を果たしたかどうかによって決定される。すなわち、ここでの注意義務とは、自らの能力に応じた注意義務の程度という主観的な意味ではなく業界において一般的・客観的に要求される注意義務を意味し、このような注意義務を欠くときは過失が認められる。ここで規定される善管注意義務は第３条のベンダの善管注意義務に重なるものであるが、上記したとおり本件パッケージの候補の選定支援作業の重要性に鑑み、再度確認して記載している。

第3条はベンダの善管注意義務一般についての規定である。ベンダは、ユーザに対し、各本件業務（請負契約であるソフトウェア設計・制作及び構築・設定業務を除く。）の履行に関し、準委任契約上の善良なる管理者の注意義務を負うことを確認する（民法第656条、第644条）。前述したとおり「善良なる管理者の注意義務を果たした」かどうかは、情報処理技術に関する業界で一般的に要求される専門知識・ノウハウにもとづく注意義務を果たしたかどうかによって決定される。すなわち、ここでの注意義務とは、自らの能力に応じた注意義務の程度という主観的な意味ではなく業界において一般的・客観的に要求される注意義務を意味し、このような注意義務を欠くときは過失が認められる。
　逆に言うと、ベンダは、ユーザに対し、善良な管理者の注意義務をもって本件業務を履行している限り、各業務の内容、結果等について責任を負わない。

第4条は業務終了の確認についての規定である。
本条では、準委任としてベンダが善管注意義務に基づき業務を適切に行ったかどうかの確認を行う手続を定める。

第1項は、ベンダはユーザに対し、業務終了後所定の期間内に業務完了報告書を提出することとする。業務完了報告書兼検収依頼書の例については、別添のドキュメントモデルを参照のこと。
　第2項は、点検期間を明確にした上で、ユーザが業務完了報告書の確認を行うことを定める。
　第3項の業務完了確認書兼検収書の例については、別添ドキュメントモデルを参照のこと。
　第4項は、ユーザが業務完了確認を怠った場合のみなし確認を定める。



B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）Frame39

別紙１のパッケージカスタマイズ取引契約モデルの上流工程後半に対応する規定である。

第1条、3条、4条、5条は、基本的にAパッケージソフトウェア選定・要件定義支援業務契約のものと変わらない。

第2条は機器等の売買等についての規定である。本件業務においては機器等の販売が行われる場合があり、その際ユーザは、本件システムを構成する機器等（ハードウェア機器、電子媒体、OS）をベンダ又は第三者から購入し、またはリースすることとなるが、ベンダ又は第三者は、ユーザとの間において別途売買等に関する契約を締結することが多い。そうした契約が存在するときは、契約の対象となる当該機器等に関しては、本契約に優先して適用される旨を定める。



C　パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル）Frame40

別紙2のパッケージオプション取引契約モデルの上流工程に対応する規定である。条項は別紙1のパッケージカスタマイズ取引契約モデルに対応する「A　要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）」、「B　パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）」のものと同じである。



D　外部設計支援業務契約Frame41

契約の成立、機器等の売買等、ベンダの善管注意義務、業務終了の確認の4条項から成り、各条項の説明は前述のとおりである。



E ソフトウェア設計・制作業務契約、F 構築・設定業務契約

Frame42

第1条は請負契約の成立に関する規定である。

第2条は本件システムの納入および出荷テストについての規定で、基本的にモデル取引・契約書第一版の規定と同じである。ソフトウェア設計・制作業務の場合はベンダによる適格性（出荷）テストの実施を定めている。

第3条では本件システムに関する検収を行う手続について定める。

第1項については、本件パッケージについて検査期間内に適格性（出荷）テスト条件（構築・設定の場合は「受入れテスト条件」）に基づき検査し、システム要件定義書、関連する文書と本件システムとが合致することを点検することを規定する。構築・設定業務の場合、現地調整の都合上、仕様書通りとならない場合があるため、構築・設定業務報告書が加わっている。
　第2項は、本件パッケージがシステム要件定義書、関連する文書と本件システムに適合しないことが判明した場合、ベンダがこれを修正して修正版をユーザに納入することを義務付けている。検査合格通知書兼検収書の例は、別添のドキュメントモデルを参照のこと。
　第3項は、みなし検査合格に関する規定を定めることにより、ユーザの都合により検収が引き延ばされることを防ぐものである。
　第4項は、検査合格をもって本件ソフトウェアの検収完了とすることを明記する。

第4条は機器等の売買等がある場合の規定であり、文言は、他の業務における規定と同じである。
　機器等の売買について別契約が存在する場合はかかる契約が本契約に優先して適用されるので、当然契約不適合責任についても優先される。本件パッケージについても通常は本契約とは別の使用許諾契約書等が存在し、当該契約書に契約不適合責任の規定が存在することが多いと考えられるので本条と本件パッケージ固有の契約不適合の規定は重複する点もあるが、本モデル契約書における本件パッケージの役割の重要性に鑑み個別の条項において権利関係を明確にすることが重要であることから重複して規定してある。

第5条は、本件パッケージの固有の契約不適合に関する規定である。

第1項は、ソフトウェア設計・制作業務においてベンダが、ユーザに対し、本件パッケージに固有の契約不適合（本件パッケージそのものについての契約不適合）についてベンダがそれらの存在を知り、または重過失によりこれを知らず結果としてユーザにこれを告げなかった場合を除いて、原則として責任を負わないことを規定する。
　
　第2項は、前項によって責任を負う場合であっても、本体の請負契約の契約不適合責任における契約不適合によっても契約の目的が達することができる場合で、対応に過分の費用を要する場合に無償での対応をベンダに求めるのは酷であるとの考え方から、免責を定めたものである。

第6条は、本件システム（ただし、本件パッケージソフトウェア及びハードウェア機器部分を除く。）に関する契約不適合責任について定める。ソフトウェア設計・製作業務や構築・設定業務を請負型で行う場合には、ベンダは仕事の完成義務を負う。。システム開発についてシステムを完成させたと認められるか否かは、仕事が当初の請負契約で予約していた最後の工程まで終えているか否かを基準にすべきであるとする裁判例がある（東京地判平成14年4月22日）。具体的には、当初仕様書にて予約されている業務の最後の工程まで終えて納品及び検収完了後、契約不適合が発見された場合には、原則として本条の契約不適合責任が適用されることになると考えられる。
　前述したように本件システムを構成するものであっても、本件パッケージソフトウェアについてはベンダは当該パッケージの固有の契約不適合や権利侵害等の存在を知り、または重大な過失によりこれを知らず結果としてユーザにこれを告げなかった場合にのみ責任を負うものであって、本件パッケージソフトウェアについての本条の適用はない。さらに本件システムを構成する機器等であっても、係る機器等について別の契約が存在する場合はやはり本条の契約不適合責任の規定の適用はない。

第1項は、パッケージシステム利用コンピュータソフトウェア開発業務において生じた「本件システムについてシステム要件定義書及び／もしくは関連する文書等の仕様との不一致（バグを含む。）」を契約不適合と定義した上で、契約不適合が発見された場合には、ベンダはその修正等の追完義務を負うことを規定する。本件システムに関するセキュリティ対策についてはシステム仕様書等に含まれているのであればその仕様書との不一致があれば、「契約不適合」に該当する。なお第1項但書では、民法第562条の規定に準じて、ユーザに不相当な負担を課するものではないときは、ベンダはユーザが請求した方法と異なる方法による追完を行うことができる旨定めている。もっとも、どの方法がユーザに不相当な負担を課すものであるかは必ずしも明らかではないから、ベンダが一方的に選択した方法により追完することは現実的ではなく、ベンダとしては、まずはユーザと協議の上、ユーザ・ベンダ双方においていかなる対応が望ましいかという観点から方法を決定することが期待される。
　第2項では、契約不適合があった場合に、それによってもなおが個別契約の目的を達することができる場合であっても、追完に過分の費用を要する場合に無償での追完をベンダに求めるのは酷であることから、この場合にはベンダは追完義務を負わないものとしている。

第3項は、契約不適合責任に基づく損害賠償請求について規定している。損害賠償についてはシステム基本契約書第10条に一般規定があるものの、契約不適合責任には他の債務不履行等に基づく損害賠償責任一般とは異なる期間制限が存すること、また、納入物に契約不適合があった場合の救済を一つの条文で整理した方が本モデル契約の利用者にとってわかりやすいことから本条において規定している。もっとも、契約不適合責任に基づく損害賠償額の上限についてはシステム基本契約書第10条の定めが適用されることになる。

第4項は、民法第559条で準用される、第564条、第541条及び第542条に準じ、契約不適合が生じた際に、追完の請求をしても相当期間に追完がされない場合、又は追完の見込みがない場合において、個別契約の目的が達することができない場合には、当該契約を解除することができる旨規定している。

第5項は、契約不適合責任について、重要事項説明書の記載の契約不適合責任の存続期間内に限って、ユーザが権利行使を行うことができるものとしている。

請負における民法上の契約不適合責任は、注文者が契約不適合を知った時から1年以内にその旨を通知すれば権利行使が可能であり（民法第637条第1項）、当該契約不適合を注文者が認識しない限りは、消滅時効の一般規定に基づき、完成物の引渡し又は仕事の終了時から10年間は権利行使しうる状況となる（民法第166条第1項第2号）。

権利行使の期間制限の起算点をユーザが契約不適合を知った時からとすると、ユーザにとっての検査の位置づけが軽くなり、適切な検査を行うことについてのインセンティブが失われることから、本モデル契約では、民法上のデフォルトルールにかかわらず、契約不適合責任の期間制限の起算点を検収完了時という客観的なものとした。また、契約不適合に基づく権利行使の期間の長さについては、｢○ヶ月／○年以内｣としているが、これは、１年というように一律に固定の期間とするのではなく、後述する観点から開発対象のシステムの特性に応じて、当事者が適切な期間を定めることを想定している。

なお、仮に権利行使の期間を1年以上の長期に設定した場合には、ユーザが契約不適合の存在に気付いたときに、その期間内に権利行使すればよいというのではなく、速やかにベンダに対して通知を行うことが適当であると考えられることから、ユーザが契約不適合を知った時から〇ヶ月という主観的な起算点を重ねて設定することも考えられる。

本項の期間制限は、契約に適合した納品を完了したとのベンダの期待を保護するものであるから、検収完了時においてベンダが契約不適合を認識していたとき、または通常の注意を尽くしていればそれを容易に認識できた場合にまで期間短縮の恩恵を享受させることは、やはり怠慢なベンダを保護することになり、妥当ではない。したがって、民法第637条第2項に準じて、この場合には契約で定めた期間制限を適用しないこととした。

また、本項の期間制限は、基本的には検収完了時という客観的な起算点から一定期間に権利行使を制限するものであるが、契約不適合を知った時という主観的起算点から１年と定める民法第637条と比べると、民法のデフォルトルールによればユーザの権利行使が可能であるような場合にもこれを制限する、一種の免責ないし責任制限としての効果を有する条項と評価することができる。しかし、基本的な注意義務を尽くしていれば容易に回避することが可能であった契約不適合についてまでベンダに免責的な効果を享受させることは、怠慢なベンダを保護することになり望ましくない。そこで、ベンダに契約不適合を生じさせたことについて故意または重過失がある場合についても、契約で定めた期間制限を適用しないこととした。

なお、契約不適合がベンダの故意または重過失に起因して生じたものであるという要件と、検収完了時における契約不適合が存したことについてのベンダの悪意または重過失という要件とは、実際上重複して充足が認められる場合もありうるが、上記のような異なる観点から要請されるものであり、必ずしも常に重なるものではない。

さらに、重要事項説明書の「契約不適合責任の存続期間」欄では、第3条の検査によってもユーザが契約不適合を発見することがその性質上合理的に期待できない場合には、検収完了日を起算点とする期間制限の例外として、ユーザが当該契約不適合を知った時から〇ヶ月以内にその旨を通知することにより権利行使することができることを当事者が定めることができる旨のオプションを記載している。長期間にわたるデータの蓄積によって初めて発現する著しい性能低下など、その発現に一定期間の一定以上の時間の経過を要する契約不適合等については、その性質上、第3条に定める検査によってはユーザが契約不適合を発見することが合理的に期待することができない場合がありうる。特に、検収完了日を起算点とする契約不適合責任の期間制限が比較的短期に設定された場合等には、このような場合について契約不適合責任に基づくユーザの権利行使を当該期間内に限定制限することが合理性に欠ける場合がありうることから、このような契約不適合が想定されるような場合には、ユーザ及びベンダの合意によって、契約不適合についてベンダに故意・重過失がある場合のほか、ユーザが検査によって発見することが合理的に期待できない性質の契約不適合についても、検収完了時からの期間制限の例外を認める適用を除外することを定めることも考えられるため、そのような定め方をオプションとして用意した。もっとも、この場合でも、ユーザが契約不適合を発見したときは、速やかな行動をとることが期待されることから、主観的な起算点から一定の期間内に権利行使を制限することが適切であり、ユーザが契約不適合を知った時から○ヶ月以内に通知することを要件としている。上記のとおり、このオプションが適用されるかどうかは、当該契約不適合の性質上、ユーザが適切な検査を行ってもそれを発見することが合理的に期待できないか次第であることから、例えば、単にユーザに時間的余裕がないなどの事情により検査が不十分なものとなり契約不適合を発見できなかった場合や、テスト条件の策定において、ユーザが適切な協力を怠ったために契約不適合が発見できなかった場合などは、適用対象とならないと解されるので注意が必要である。

なお、期間の長さについては、以下のような諸要素についてベンダ・ユーザ間で考慮し共通理解を得た上で定めることが考えられる。

①　どのようなシステムを作るのか（どの程度の期間維持されるべきものなのか、ユーザが本当に求めている要件は何なのか等）

開発対象のシステムとしてどのようなものを作るかは、言うまでもなくそもそも何が契約不適合かを考える上で最も重要であるが、契約不適合責任の存続期間を考える上でも重要である。

例えば、対象のシステムが稼働後X年間維持されるべきものなのかということにおける「X年」というのは、それ自体契約不適合責任に基づく権利行使の期間制限とは性質が異なる。「X年維持されるべきシステム」が契約の目的である以上は、X年以内に不具合が出た場合には（個別の内容によるものの）契約不適合が生じていることにほかならないので、それについてベンダに対応してもらうことが可能となるような期間の設定が必要となる。

②　どのような環境で開発が行われるのか

　　事後的に追完を求められたとしても、当時の開発環境が再現できなければ事実上追完できないこともありうるところである。契約締結時点において、当該環境がどの程度の期間維持されるのかをすべて予想することは困難ではあるが、可能な限りで情報を共有し、期間決定の考慮要素とすべきである。

③　契約不適合責任の存続期間に応じてどのようにコストが見積もられるのか

　　ベンダ側としては、契約不適合責任の存続期間が長ければ長いほど対応要員の維持コストが上がり、それを当初の開発費用に上乗せする必要があるようにも思われる。一方でユーザ側から見れば、検収完了後何も問題がない場合には一切作業を行わない人員についてのコストを追加的に負担することについての抵抗感やその見積もりの適切性についての疑念を持つこともありうる。したがって、ベンダとしては、契約不適合責任の存続期間に応じたコストの見積もりについての説明を尽くし、ユーザの納得を得た上で、どの程度の存続期間を定めるべきかを決することが望ましい。

④　契約不適合とは言えない不具合への対応も対象とする保守との役割分担をどうするのか

　　見直しの議論において、システム開発契約において何が契約不適合かを決することが難しいという意見が多く出されたところである。例えば、確かに不具合は生じたものの、それがシステム検収完了後にOSがバージョンアップしたことに伴うものであれば、契約時点において前提となるOSとは異なっている以上、当該不具合は契約不適合ではないとされることもある。

　　ユーザとしては、契約不適合が生じた場合には、無償で追完請求ができるし、その期間が延びればそれ自体はユーザにとっては有利なものの、契約不適合該当性についてユーザ・ベンダ間で争いとなるケースも少なくなく、余計なコストが生じることも考えられるところである。

　　上記③の通り、契約不適合責任の存続期間の伸長によってユーザが一定程度の追加負担を避けられないということであれば、契約不適合責任の存続期間自体は短くした上で、その期間経過後は、契約不適合に該当するかしないかを問わず対応してもらう保守契約を締結する方がかえってユーザにとって経済的である局面もあると思われるので、この点についても③と併せて対話をすることが望ましい。

なお、検収完了時までに可能な限り契約不適合を洗い出し早期に問題解消を図ることがユーザ・ベンダ双方にとって望ましいことは言うまでもなく、そのためには十分な検査が実施される必要がある。ただ、「十分な検査が実施された」といえるためには、要件定義書や外部設計書に記載の機能が実装されていることの確認だけではなく、納入物であるシステムの性質や用途によっては、多様なテストケースやテストデータによる確認が必要とされるケースも想定される。そのため、検査の基準となるテスト条件の作成に際しては、ユーザとベンダがシステムの性質や用途に関する認識を共有し、相互にテスト条件の作成に必要となる情報の提供などで協力することが望ましい。

なお、期間内にユーザが契約不適合に基づく権利行使をするためにとる行動は、民法第637条第1項に準じて、契約不適合がある旨をベンダに通知することとしている。もっとも、改正民法の立案担当者によれば、この通知は、単に契約不適合がある旨を抽象的に伝えるのみでは足りず、細目にわたるまでの必要はないものの、契約不適合の内容を把握することが可能な程度に、契約不適合の種類・範囲を伝えることを想定しているとされており（前掲筒井＝村松285頁）、システム開発の局面でも、ベンダが契約不適合の内容を把握できるように、契約不適合の内容や当該契約不適合の発生した状況（画面等）を具体的に示すことが求められる。
　第6項は、民法第636条に準じ、契約不適合がユーザの指示や提供した資料等に起因する場合にはベンダは契約不適合責任を負わないが、ベンダがかかる資料等又はユーザの指示が不適当であることを知って指摘しない場合には契約不適合責任を免れないとする規定である。
　第7項は、契約不適合責任の範囲を定める。実務上、契約不適合責任による修補と保守業務とが区別されずにいたため、本来であれば、ベンダがユーザに対して有償で提供する保守サービスが契約不適合責任の名の下に無償にて提供されている場合がよくある。このような現状を整理するため、本項では契約不適合責任の対象は、本契約のもとでテストが行われた本件システムのみであって、当該システムがアップグレードされたことに起因する問題等については、ベンダは、有償による保守サービスによってこれに対応するものとする。

なお、民法上、注文者には契約不適合責任に基づき、追完がされない場合等に不適合の程度に応じて報酬減額請求権を行使することも認められている（第559条による第563条の準用）。しかし、システム開発において「不適合の程度」が明確ではなく、また契約においても明確にすることが難しいこと、システム開発で問題が生じた場合、報酬の減額を請求するというより、他のベンダに作業を依頼したときに支出した費用等を損害として請求することが多く、システム開発においてユーザが報酬減額請求権を行使することはあまりないと考えられることから、本契約に積極的に盛り込むことはしていない。もっとも、これは報酬減額請求権を排除する趣旨ではなく、その行使の要件及び効果は民法の規律に委ねられることになる。ただ、仮にユーザが報酬減額請求権を行使する場合であっても、他の救済方法と同様本契約で定めた期間制限に服させる必要があることから、第5項の期間制限の対象については、「本条に定める責任その他の契約不適合責任」としている。なお、ユーザから履行の追完の請求をされた際に、担当者がその対応を熟慮せずに履行の追完を拒否した場合、民法上の報酬減額請求権が行使されることになり、当事者間の紛争につながりかねない。したがって、契約不適合が生じた場合における追完の請求に関する判断を責任者に集中することが望ましい。

第7条は有体物の納入がある場合の危険負担について定めたものである。

第8条は特許権の帰属についての規定である。ベンダが開発したソフトウェア等の納入物に関しては、特許権、著作権、ノウハウ等の知的財産権が発生する場合がある。知的財産権の帰属については、ユーザ、ベンダ双方の利害が対立することから、契約で明確に規定しておくべきである。本条は、ソフトウェア設計・製作業務及び構築・設定業務の遂行過程で生じる特許権等に関する権利の帰属及び実施権について定める。
　第1項は、発明者主義に従い、当事者のいずれか一方の発明者が単独で発明考案した場合には、特許権等は当該当事者に帰属するものとする。なお、モデル取引・契約書第一版におけるモデル契約書第44条第2項のようにベンダ及びユーザが共同発明を行うことは、本件システムがパッケージソフトウェアを前提としているものである以上、考えにくく、ベンダのみが発明者となる場合が圧倒的に多いであろう。
　第2項は、ベンダが特許権等を保有する場合においても、ユーザが開発されたソフトウェアを使用するのに必要な範囲では、特許権等を使用する必要があるため、通常実施権を許諾するものとしている。また、一定の第三者に使用せしめる旨を個別契約の目的として特掲した上で開発された特定ソフトウェアについては、当該第三者に対しても許諾するものとする。なお、かかる許諾についての対価は委託料に含まれることを明記すべきである。

第9条では、納入物の著作権の権利帰属及び利用について規定する。
新たに作成されたソフトウェアの著作権をベンダ、ユーザのいずれに帰属させるべきかについては、ベンダは作成したソフトウェアの再利用のために自己のものとして留保したいと考え、ユーザは自己の機密情報が含まれる場合の保護の観点などからベンダから譲り受けて、自己のものとしたいと考えている。モデル取引・契約書第一版においては、社会的な生産効率の向上の観点などから、汎用性のあるプログラムについてはベンダに帰属させると共に、その余のプログラムに関してベンダ帰属案（A案）、ユーザ帰属案（B案）、共有案（C案）が記載されている。
　本研究会が前提とする取引は、パッケージソフトウェアを利用すること、ユーザが中小企業等であることなどに特色がある。この観点より本論点を検討すると、まず、アドオン等のカスタマイズで新たに作成されるソフトウェアは前提となるパッケージソフトウェアの関連で作成されるものであり、当該パッケージソフトウェアの一般的機能となるべきものが、カスタマイズという形で先行して開発されることも多い。それゆえ、かかる部分が将来的には他のユーザにも共通に利用できる部分となるケースもしばしばある。なお、ユーザがベンダから著作権の譲渡を受ける場合には、別途譲渡の対価を支払うことが要請されるため、そのような場合にはユーザの費用負担が増大する。他方、かかる部分にユーザの機密情報が含まれている場合にノウハウの流出防止など当該機密情報の保護をユーザが求めることは当然のことであるが、機密情報の保護のためには、著作権を取得しなくとも別途用意される秘密保持条項で対応できるものと考えられる。
　以上の次第で、カスタマイズ等により作成されたソフトウェアの権利をベンダに帰属させベンダが他のビジネスにおいても再利用できる環境を整えていた方が、総体としては価格を低く抑えることができ、中小企業等が利用するシステムとして比較的合理的な価格で広く普及することに資する結果となると考えられるため、カスタマイズ等により新たに作成されたソフトウェアの権利は原則ベンダに帰属させることとした。
　勿論、当事者の合意により、B案又はC案を採用することも可能である。第1項は、納入物に関する著作物の著作権については、ユーザ又は第三者が従前から保有していた著作権を除き、ベンダに全ての著作権を帰属させる。
　第2項は、本件ソフトウェアに関して、ユーザが行う自己使用のための複製又は翻案について定める。また、一定の第三者に使用せしめる旨を個別契約の目的として特掲した上で、開発された特定ソフトウェアについては、当該第三者に対しても利用許諾できるものとし、ベンダは、著作者人格権（著作権法第59条）を行使しないことを定める。なお、一定の第三者に使用せしめる旨を個別契約の目的として特掲した上で開発された特定ソフトウェアについては、当該第三者に対しても許諾するものとする。なお、かかる許諾についての対価は委託料に含まれることを明記すべきである。

第10条では、納入物が、著作権及び特許権その他の知的財産権を侵害した場合のベンダの責任について規定する。著作権侵害についてはクリーンルーム手法等による回避の可能性もあるが、特許権は未公開中のものもあるし、公開済みの出願であっても、ベンダにおいて侵害の有無をすべてを完全に調査検証することは事実上困難であるし、海外も含め調査検証にかなりの費用を要することもある。また、ベンダが、第三者の知的財産権に関する納入物の非侵害を保証することは現実的ではないため、侵害時の責任分担を定めておくことも必要となる。個別取引の実情にあわせて規定を設けることになるが、本契約では、以下の案を提示する。
　本条では、パッケージソフトウェア等の選定についてベンダがユーザに提案することから、ユーザが権利者に対して支払うこととなった損害賠償額等をベンダが負担することとしている。但し、ベンダがかかる責任を負う前提として、ベンダに必要な情報が提供され、防御に関する適切な権限が与えられることが必要である。そこで、ベンダが責任を負う要件として、①申立ての事実及び内容のすみやかな通知、②ベンダが交渉又は訴訟の決定権限を有すること、③ユーザの敗訴判決確定又は和解成立などによる確定的解決で損害賠償の支払義務が確定することを規定する。ユーザに生じた損害賠償額及び合理的な弁護士費用の上限は、システム基本契約書第10条に従う。41 第1項但書は、侵害の申立がユーザの帰責事由による場合、本件パッケージソフトウェア及びシステム基本契約書に優先する契約の対象となる機器等を原因とする場合には、ベンダが免責される旨規定する。例えば、特許権侵害等がユーザの指示した仕様に関する部分である場合、納入した本件ソフトウェアをユーザが他のソフトウェアと組み合わせるなどして第三者の特許権を侵害した場合、ユーザが本件ソフトウェアをベンダとの事前の合意に反して本邦外で使用し本邦外の特許権を侵害した場合、ユーザが本件ソフトウェアをベンダとの事前の合意なく変更した場合、ユーザが本件ソフトウェアを自己利用の範囲又は第三者に使用せしめる旨を特掲した特定ソフトウェアの範囲を超えて配布した場合などが想定されている。
　第2項は、ベンダは、本条に基づく責任を主体的に負うことになるので、ユーザは、防御方法等の一切をベンダに委ねなければならない旨を定める。
　第3項は、ベンダの帰責事由により納入物の使用が不可能となるおそれがあるような場合には、ベンダの判断と費用負担で、ユーザが第三者の知的財産権を侵害することなく情報システムを継続使用できるように措置を講じることができる旨を規定する。第三者の知的財産権を侵害するものとして損害賠償額が拡大し、プログラムの継続使用ができなくなる事態を考慮したものである。



G データ移行支援業務契約、H 運用テスト支援業務契約、I 導入教育支援業務契約

Frame43

契約の成立、機器等の売買等、ベンダの善管注意義務、業務終了の確認の4条項から成り、各条項の説明は前述のとおりである。



J 保守業務契約

Frame44

第1条は、準委任契約の成立に関する規定である。

第2条は、保守業務の範囲についての規定である。本件システムに対する保守業務には、ハードウェア保守及びアプリケーション保守（パッケージソフトウェアに関する保守を除く。）があり、本条はこの双方について定めるものである。共通フレーム2013によれば、保守業務には、(1)不良や不具合を修正する業務（是正保守）、(2)あらゆる環境の変化に対応させる業務（適応保守）、(3)本件システムの性能又は保守性を改善する業務（完全化保守）及び(4)引渡後潜在的な不具合が顕在化する前に発見し修復する業務（予防保守）が挙げられる。本条にてベンダが行う保守とは、(1)のみであり、(2)、(3)及び(4)の業務は、既に本件システムの変更でありこれを通常の保守業務としてベンダに行わせるのは酷との考えから、対象外であるとした。

第3条は、サービスの範囲についての規定であり、保守サービスの内容は、別途ベンダとユーザとの間で取り交わされるサービス仕様書による旨を定めた。

第4条は設置場所への立ち入り等についての規定であり、保守業務の便宜のために、ベンダによる本件システムの設置場所への立ち入り、ユーザによる作業場所及び消耗品の提供について定めた。

第5条は、遠隔操作によるサービスについての規定である。事前の合意がある場合、ベンダが遠隔地からユーザのサーバにログインして保守サービスが実行できる。遠隔保守を実行する都度、ユーザの個別承認を得るかは、個別に重要事項説明書の付帯事項で定める。

第6条は、製造打ち切り、保守部品提供の中止の際の取扱いについての規定であり、本件システムを構成するハードウェアの製造会社の都合によってハードウェアの製造が中止された場合、又は保守部品の提供を中止した場合、ベンダは、ユーザに対し、ハードウェア保守を行うことは不可能である。そこで、ベンダは、ユーザに対し、ハードウェア自体を有償にて交換することを請求することができる。当該請求に応じなかったユーザについては、当該ハードウェアを保守業務の対象から外すことができる。この場合の保守料金は、当該保守料金体系に従って処理されるものとする。

第7条は、老朽化装置の取扱いについての規定である。前条と同様の趣旨から、本件システムを構成するハードウェアの保守部品がハードウェア製造会社の定める耐用年数（設計標準使用期間）を超えた場合、当該保守部品が老朽化し、保守業務が適切に行われなくなる可能性が高いので、ベンダは、ユーザに対し、当該保守部品を有償にて交換することを請求することができる。当該請求に応じなかったユーザについては、当該保守部品を保守業務の対象から外すことができる。この場合、ユーザがベンダに対して支払う保守料金については変更しない。

第8条は、ソフトウェアのサポート中止がなされた際の取扱いの規定である。ソフトウェアの製造会社がサポートを中止した後、機能の不具合やセキュリティ等の欠陥が発見された場合、ベンダはそれを改修することが不可能である。また、ソフトの製造会社が不具合を修正しないことで、ソフトウェアの安定稼働を維持することが困難になり、それによって、カスタマイズ部分に影響が及び、保守業務が適切に行われなくなる等の場合がある。ベンダはこのような場合、保守の継続について検討し、その内容をユーザに提示した上で、保守内容の変更交渉を開始することができる。この場合、ユーザはベンダと保守契約の見直し交渉に応じなくてはならない。

第9条は、交換部品の所有権についての規定である。交換された保守部品については、従来はユーザに所有権がある。ただ、本条は、保守業務の履行の際の実務上の慣行に基づき、交換された保守部品の所有権が交換によってベンダに帰属する旨を定める。

第10条は、秘密保持についての保守契約独自の規定である。契約書の秘密保持義務の規定と矛盾せず、その前提での規定である。前条により、交換された保守部品についてはベンダの所有となるが、ユーザの使用により、当該保守部品にはユーザの情報が記憶されている。本条は、ベンダが当該ユーザ情報を本契約第7条に定める秘密情報として取扱い、保護する旨を定めた。

第11条は、設置場所の変更についての規定である。ユーザが本件システムの設置場所を変更した際、ベンダがこれを知らなければ円滑な保守業務が行われることはないので、ユーザに対し、ベンダに変更の30日前までにこれを通知することを求めた規定である。仮に、ユーザがこれを怠った場合、ベンダによる保守業務を受けられなくてもこれをベンダの債務不履行であると主張することはできない。

第12条は、設置場所の整備についての規定である。ユーザが本件システムを所有及び管理しているので、ユーザが本件システムの設置場所を整備しておかなければベンダによる適切な保守が受けられない。そこで、ユーザは、ハードウェア製造会社が定める数々の使用環境条件に適合するよう本件システムの設置場所を整備しなければならないことを定める。

第13条は、不具合の調査費用についての規定である。本件システムのハードウェア、ソフトウェアの不具合については、原則としてシステム保守の専門家であるベンダがその費用負担にてこれを調査する。しかしながら、調査の結果、当該不具合がユーザの重過失により発生したことが判明した場合、調査の費用をベンダに負わせることは公平ではない。また、保守業務の対象に含まれないハードウェア、ソフトウェアが原因になって保守業務の対象であるハードウェア、ソフトウェアに不具合が発生した場合、調査の費用をベンダに負わせることは公平ではないことから、本件システムの不具合の際の調査費用について定めた。

第14条は、使用地域の制限についての規定である。本件システムは、もともと日本国内においてのみ使用することが予約されており、仮にユーザがこれを一回でも日本国外にて使用した場合本件システムに何らかの影響が発生する可能性が大きく、ベンダは、当該システムについては適切な保守業務を行うことはできないため、本件システムの使用地域の制限について定めた。

第15条は、パッケージ本体の不具合についての規定である。ベンダは、パッケージソフトウェアの固有の不具合について、適切な保守業務を行うことは不可能であるから、これは保守業務の対象外であることを定めた。パッケージソフトウェアの固有の不具合については、パッケージソフトウェアの使用許諾書に従うものとする。

第16条は、有効期間についての規定であり、保守業務の期間を1年間とし、当事者から申し出がなく、また保守業務の対象機器であるハードウェアの部品が市場において供給される限り、自動更新されることを定める。

第17条は、支払遅延についての規定である。保守業務は、継続的な保守サービスを供給することをその内容とするため、仮にユーザが代金債務の支払を怠った場合においてもベンダにサービスの提供を要求することは酷であるため、このような場合、ベンダは、ユーザに対し、支払遅延日以後の保守サービスを行う必要がない旨を定めた。



K 運用支援業務契約

Frame45

保守業務契約の規定とほぼ同様であるのでそちらを参照されたい。








ドキュメントモデル

本契約書、重要事項説明書、モデル取引のプロセスに合致するサンプルドキュメントを準備した。適宜、全部または一部を参考し活用されたい。

また、チェックシートは、取引の端緒にあたって、ベンダからユーザに配布し、プロセスの理解を深めるための資料として活用されることを期待している。





業務関連サンプルドキュメント

1.プロジェクト連絡協議会議事録
2.設定等合意書
3.業務完了報告書兼検収依頼書
4.業務完了確認書兼検収書
5.業務完了報告書兼外部設計書承認依頼書
6.業務完了確認書兼外部設計書承認書
7.システム構築・設定業務完了報告書兼検収依頼書
8.検査合格通知書兼検収書（構築・設定業務契約）
9.納品書兼検収依頼書
10.検査合格通知書兼検収書（ソフトウェア設計・制作業務契約）



チェックリスト

1.コンサルティング会社選定のためのチェックリスト
2.提案依頼書(RFP)のチェックリスト
3.業務システム仕様書の記述レベル
4.ユーザIT成熟度チェックリスト
5.パッケージソフトウェア選定のためのチェックリスト
6.SaaS/ASP選定のためのチェックリスト
7.検収事前チェックリスト
8.検収チェックリスト
9. セキュリティチェックシート 一般版（上位概念）
10.セキュリティチェックシート Webアプリケーション版
11.SaaS向けSLAにおけるサービスレベル項目のモデルケース





提出日：○○○○年○○月○○日

本紙を含む全○枚

1.第○回 ○○○○プロジェクト連絡協議会議事録（記入例）



（委託者）株式会社○○商事 御中

（受託者）△△システム株式会社
○○事業部
作成者 ○○○○ 印



パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書第4条6項に基づき、議事録を提出いたします。精査の上、ご承認をお願い申し上げます。

開催日時： ○○○○年○○月○○日　○○時○○分～○○時○○分

開催場所： 株式会社○○○○○○○ 本社会議室

出席者： 株式会社○○○○○○○

責任者○○、○○、○○

　　　　 ○○○○○株式会社

責任者○○、○○、○○

議事：（契約書第4条7項により、決定事項、継続検討事項がある場合は検討スケジュール及び検討当事者を記載の事。）















以上、議事の内容に相違ないことを確認し、本議事録を承認いたします。

（委託者）株式会社○○商事 責任者　○○○○　印

（受託者）△△システム株式会社 責任者　○○○○　印

2.設定等合意書（記入例）



○○○○年○○月○○日付けパッケージソフトウェア利用コンピュータシステム構築委託契約書第2条⑥に基づき、下記の通り別紙重要事項説明書記載の設定等及びもしくは条件の変更について合意し決定しました。



  • 合意した設定等（設定の変更、仕様の修正、追加事項、未決定事項等）の内容：







  • 必要な措置、付帯事項、特約条項：







  • 条件の変更（委託料金、納期等）：







  • 添付資料（議事録、提案書、見積書等）：







以上の合意に相違ありません。　　　　○○○○年○○月○○日



（委託者）株式会社○○商事 責任者　○○○○　印



（受託者）△△システム株式会社 責任者　○○○○　印

○○○○年○○月○○日

3.業務完了報告書兼検収依頼書（記入例）



（委託者）株式会社○○商事　御中

（受託者）△△システム株式会社
○○事業部





○○○○年○○月○○日付けパッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）の業務が完了いたしましたので、下記の通り報告書をご提出申し上げます。
　つきましては、○○○○年○○月○○日までにご精査頂き、ご検収をお願い申し上げます。



記



件名： 　　　○○○○システム


期間： 　　　○○○○年○○月○○日～○○月○○日


報告書： ○○○○年○○月○○日付け
○○○○システム　要件定義書 第○○版 一式
（文書明細は別添の通り）


提出場所：　　東京都千代田区○○○○○○○○
　　　株式会社○○商事営業本部


作成責任者：　△△システム株式会社○○事業部 ○○○○
　　　〒○○○-○○○○ 東京都千代田区霞が関○○-○○
　　　TEL. 03-○○○○-○○○○


契約金額： ○○○○円

以上



○○○○年○○月○○日

4.業務完了確認書兼検収書（記入例）



（受託者）△△システム株式会社　御中

（委託者）株式会社○○商事





○○○○年○○月○○日付けパッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）の業務完了を確認し、報告書を検収いたしました。



記

件名： 　　　○○○○システム


期間： 　　　○○○○年○○月○○日～○○月○○日


報告書： ○○○○年○○月○○日付け
○○○○システム　要件定義書 第○○版 一式
（文書明細は別添の通り）


提出場所：　　東京都千代田区○○○○○○○○
　　　株式会社○○商事営業本部


作成責任者：　△△システム株式会社○○事業部 ○○○○
　　　〒○○○-○○○○ 東京都千代田区霞が関○○-○○
　　　TEL. 03-○○○○-○○○○


契約金額：　　○○○○円

以上

○○○○年○○月○○日

5.業務完了報告書兼外部設計書承認依頼書（記入例）



（委託者）株式会社○○商事　御中

　（受託者）△△システム株式会社



○○○○年○○月○○日付け外部設計支援業務契約の業務が完了いたしましたので、下記の通り報告書をご提出申し上げます。
　つきましては、○○○○年○○月○○日までにご精査頂き、ご承認をお願い申し上げます。



件名： 　　　○○○○システム


期間： 　　　○○○○年○○月○○日～○○月○○日


報告書： ○○○○年○○月○○日付け
○○○○システム　外部設計書 第○○版 一式
○○○○システム　外部設計支援作業実績一覧表 一式
（文書明細は別添の通り）


提出場所：　　東京都千代田区○○○○○○○○
　　　株式会社○○商事営業本部


作成責任者：　△△システム株式会社○○事業部 ○○○○
　　　〒○○○-○○○○ 東京都千代田区霞が関○○-○○
　　　TEL. 03-○○○○-○○○○


契約金額： ○○○○円

以上



○○○○年○○月○○日

6.業務完了確認書兼外部設計書承認書（記入例）



（受託者）△△システム株式会社　御中

（委託者）株式会社○○商事



○○○○年○○月○○日付け外部設計支援業務契約の業務完了を確認し、報告書を承認いたしました。



件名： 　　　○○○○システム


期間： 　　　○○○○年○○月○○日～○○月○○日


報告書： ○○○○年○○月○○日付け
○○○○システム　外部設計書 第○○版 一式
○○○○システム　外部設計支援作業実績一覧表 一式
（文書明細は別添の通り）


提出場所：　　東京都千代田区○○○○○○○○
　　　株式会社○○商事営業本部


作成責任者：　△△システム株式会社○○事業部 ○○○○
　　　〒○○○-○○○○ 東京都千代田区霞が関○○-○○
　　　TEL. 03-○○○○-○○○○


契約金額： ○○○○円

以上







○○○○年○○月○○日

7.○○○○システム構築・設定業務完了報告書兼検収依頼書（記入例）



（委託者）株式会社○○商事　御中

（受託者）△△システム株式会社
○○事業部



○○○○年○○月○○日付け構築・設定業務契約に基づく作業が完了いたしましたので、下記の通り構築・設定業務報告書及び納品書をご提出申し上げます。
　つきましては、○○○○年○○月○○日までに検査の上、ご検収をお願い申し上げます。



記

件名： 　　　 ○○○○システム


期間： 　　　 ○○○○年○○月○○日～○○月○○日


作業内容：　　 ○○○○年○○月○○日付け構築・設定業務契約に基づく 一式

報告書： ○○○○年○○月○○日付け
○○○○システム　構築・設定業務設定報告書 第○○版 一式
（文書明細は別添の通り）


納品書： 別添の通り


提出場所： 東京都千代田区○○○○○○○○
株式会社○○商事営業本部


担当責任者： △△システム株式会社○○事業部 ○○○○
〒○○○-○○○○ 東京都千代田区霞が関○○-○○
TEL. 03-○○○○-○○○○


契約金額： ○○○○円

以上





○○○○年○○月○○日

8.検査合格通知書兼検収書（記入例）



（受託者）△△システム株式会社　御中

（委託者）株式会社○○商事



○○○○年○○月○○日付け構築・設定業務契約の受け入れ検査に合格し、報告書を検収いたしました。



記



件名： 　　　○○○○システム


期間： 　　　○○○○年○○月○○日～○○月○○日


作業内容：　　○○○○年○○月○○日付け構築・設定業務契約に基づく 一式


報告書： ○○○○年○○月○○日付け
○○○○システム　構築・設定業務報告書 第○○版 一式
（文書明細は別添の通り）


提出場所： 東京都千代田区○○○○○○○○
株式会社○○商事営業本部


担当責任者： △△システム株式会社○○事業部 ○○○○
〒○○○-○○○○ 東京都千代田区霞が関○○-○○
TEL. 03-○○○○-○○○○


契約金額： ○○○○円

以上



○○○○年○○月○○日

9.納品書兼検収依頼書（記入例）



（委託者）株式会社○○商事　御中

（受託者）△△システム株式会社
○○事業部





○○○○年○○月○○日付けソフトウェア設計・制作業務契約に基づくソフトウェア設計・制作作業が完了いたしましたので、下記の通り納品申し上げます。
　つきましては、○○○○年○○月○○日までに検査の上、ご検収をお願い申し上げます。



記

件名： 　○○○○システム

期間： 　○○○○年○○月○○日～○○月○○日

作業内容：　○○○○年○○月○○日付け○○○○システム要件定義書に基づく
ソフトウェア設計・制作、適格性テスト実施、ドキュメント作成 一式

納品物：　　システム設計書 印刷物2部
　適格性テスト仕様書及び報告書 印刷物2部
　運用マニュアル 印刷物2部
　ユーザマニュアル 　　　　　印刷物2部
　オブジェクト及びソースコード、ドキュメント一式 　　　　　CD-ROM2部
（上記ファイル明細は別添通り）

納品場所：　東京都千代田区○○○○○○○○
　株式会社○○商事本社ビル3F　サーバールーム内
　○○社製 型番○○○○○○ サーバ（IPアドレス：192.168.○○.○○）

担当責任者：△△システム株式会社○○事業部 ○○○○
　〒○○○-○○○○ 東京都千代田区霞が関○○-○○
　TEL. 03-○○○○-○○○○

契約金額：　○○○○円

以上



○○○○年○○月○○日

（委託者）株式会社○○商事　御中

（受託者）△△システム株式会社
○○事業部

納品ファイル明細書

媒体ボリューム名：

ディレクトリ名

ファイル名

形式

バージョン

日付

サイズ









































































































































※○○○○年○○月○○日付けソフトウェア設計・制作業務契約に基づくソフトウェア設計・制作作業の納品明細書です。

○○○○年○○月○○日

10.検査合格通知書兼検収書（記入例）



（受託者）△△システム株式会社　御中

（委託者）株式会社○○商事







○○○○年○○月○○日付けソフトウェア設計・制作業務契約に基づくソフトウェア設計・制作作業の受け入れ検査に合格し、報告書を検収いたしました。

記



件名： 　○○○○システム

期間： 　○○○○年○○月○○日～○○月○○日

作業内容：　○○○○年○○月○○日付け○○○○システム要件定義書に基づく
ソフトウェア設計・制作、適格性テスト実施、ドキュメント作成 一式

納品物： 　システム設計書 印刷物2部
　適格性テスト仕様書及び報告書 印刷物2部
　運用マニュアル 印刷物2部
　ユーザマニュアル 　　　　　印刷物2部
　オブジェクト及びソースコード、ドキュメント一式 　　　　　CD-ROM2部
（上記ファイル明細は別添通り）

納品場所：　東京都千代田区○○○○○○○○
　株式会社○○商事本社ビル3F　サーバールーム内
　○○社製 型番○○○○○○ サーバ（IPアドレス：192.168.○○.○○）

担当責任者：△△システム株式会社○○事業部 ○○○○
　〒○○○-○○○○ 東京都千代田区霞が関○○-○○
　TEL. 03-○○○○-○○○○

契約金額：　○○○○円

以上



1.コンサルティング会社選定のためのチェックリスト

コンサルティングを導入するには、コンサルティング会社もしくはコンサルタントのポリシーや信頼性について評価を行う必要がある。コンサルタント選定にあたって、解説を参考に、以下の評価軸で評価を行う。
◎：期待以上である　○：十分なレベルである　△：不十分なレベルである　×：記述レベルが明らかに不足もしくは記述がない　ＮＡ：該当しない、不明

コンサルティング会社

記述項目

解説

評価

経営安定性

コンサルティング会社の経営は安定しているか


コンサルティングポリシー

どのようなコンサルティングを目指しているのかを確認。堅実な解答、積極的な解答


実績

類似コンサルティング業務の実績（最近1年間のコンサルティング内容、期間、フェーズ、業種、企業規模などを記述する）


品質失敗実績

最近3年間の品質が損なわれた失敗実績を説明してもらう


得意分野

得意の業務分野を記述してもらう


コンサルタントの人数

所属するコンサルタントの人数、資格保持者の数


コンサルタントの入れ替え

所属するコンサルタントの平均滞在年数


担当コンサルタント

記述項目

解説

評価

担当コンサルタント

担当コンサルタントの略歴


担当コンサルタントのスキルレベル

ITスキル標準、情報システムユーザスキル標準、情報処理技術者試験などによる証明


チームバランス

チーム内のスキルの充足度


コミュニケーション力

提案などに来たときに、きちんと質疑応答ができている、一方的に話していないか


業務分野提案力

提案内容に筋が通っていて、依頼内容に沿っている


論理性

提案や説明の内容が論理的である


人柄

会話をしていて不快感を与えないか、高圧的ではないか


他ユーザからのコンサルティング会社に対する評価

記述項目

解説

評価

満足度

使い勝手、投資効果について悪い評価はないか


提案書

記述項目

解説

評価

背景

説明した背景などを理解して記述している


業界の環境などを理解して記述している


目的

説明された目的を理解し記述している


方針

説明された目的を踏まえた上で検討方針を明確に提示している


アプローチ

企画作成、提案依頼書（RFP）作成、プロジェクト・マネジメント・オフィス（PMO）支援などの目的を達成するための方法論を提示している


企画作成、RFP作成、PMO支援などの目的を達成するためのタスクを提示している


アウトプットイメージ

成果物の構成や記述レベル、分量、サンプルなどを提示する


スケジュール

全体のスケジュールが詳細化され、報告方法やマイルストンが明示されている


体制

プロジェクトの意思決定体制、チーム構成などを記述している


プロジェクトメンバのスキル、実績などを記述している


実績

類似プロジェクトの概要を記述する。


2.提案依頼書(RFP)のチェックリスト

当該システム構築の前提として、「ユーザ企業の現況及び環境」を示す必要がある。ユーザ企業が有するEA、IT ガバナンスの方針、情報セキュリティ基本方針、情報資産管理の方針、事業継続計画、コンプライアンス方針等の中から、当該システム構築の前提として、必要と思われる部分をベンダに開示する必要がある。作成したRFPを、解説を参考に、以下の評価軸で評価を行う。
◎：内容は期待以上のレベルで記述されている　○：十分なレベルで記述されている　△：記述が曖昧もしくは不足　×：レベルが低いもしくは記述がない　NA：該当しない、不明

システムの概要(基本方針)

記述項目

解説

評価

システム化の目標・方針

提案依頼に関し、システム化規模が企業の全体・部分・改造なのか、システム形態が集中型・分散型・ネットワーク型なのか、システム構築が新しい生産環境の構築や技術の大規模な再編成なのか、既存ソフトウェア資産の継続なのか、切り換えなのか、業務の効率化・生産性向上・高付加価値サービスの開発なのか、国内外のネットワークの拡大や情報化ニーズの高度化・複雑化の解消なのか等、今回のシステム化の目的・方針等を具体的に明示する。これらの明示のためには、ユーザ内において、システム化構想にかかわるステークホルダの意思統一を図り、経営層が明確な意思決定を行った上で、明示しなければならない。


狙いとする効果

企業の戦略等機密事項も含まれるので、抽象的表現にならざるを得ないが、ユーザのシステム化の狙い、例えば、ダウンサイジング化や低価格化、事務や業務の効率化や生産性向上、情報処理の迅速化によるサービスの向上、システム資源の集約化や再利用化等、システム化の狙いと効果の特微を明示する。


運用対象者

システムを運用管理する人やシステムを日常的に利用し操作する人が専任なのか、不慣れな人なのか、また同時に何人がこのシステムを利用するのか等を明示する。


既存システムとの関連

現在稼働中のシステム機器類の構成、取り扱うデータの種類や量や処理サイクル等、既存システムと今回依頼システムとの情報処理の関連を明示する。また、既存システムと接続する場合の実環境の技術的制約事項があればそれを明示する。


提案依頼手続

記述項目

解説

評価

説明会の日程

提案依頼の具体的スケジュール、例えば、システム導入時期、導入説明会の場所や日時、提案書提出期限、提案システムのヒアリング日時、入札日、ベンダ決定時期等を明示する。


対応窓口

ベンダ決定までの対応窓口組織や責任者等の氏名・職制・電話番号・FAX 番号等を明確にし、質問や問い合わせに関する対応方法について明示する。


提供する資料

提案依頼に際して提供する会社案内書、システム関連資料、提案依頼の日程等の案内のほか、各種提供した資料の機密性の有無、返還の必要性等を明示する。


参加資格条件

提案や入札に参加できる条件、例えば、ISO 9000 やIS014000 シリーズ認証、プライバシーマーク認定、ISMS 認証等の取得の有無、企業規模、業務知識や専門技術の有無、開発実績の有無、情報処理技術に関わる試験合格・資格者の人数や、支社店や支援組織体制が近くにある等、独占禁止法に抵触しない範囲での各種参加資格要件を明示する。


提案手続

提案依頼に対応して、今回の提案書や見積書の提出によって、即刻業者選定を実施するのか、最初は提案書提出の意志や技術の確認等を第1 次審査で行い、提案要求をさらに詳細に明確にして、再度、提案依頼を出し、これに対応する提案書や見積書によって業者選定を行うのか等の業者決定の手順を明示する。


ベンダ選定方法

ベンダ選定を行う組織・決定機関等、決定までのプロセス等をわかる範囲で明示する。


依頼事項

記述項目

解説

評価

システム化の依頼範囲

システム化依頼の業務や機能の範囲を明確にする。具体的には、システム全体の構造や、既存システムや今後の開発計画と今回開発予約部分との関連を明確にする。特に、範囲外の部分については詳細を明示する。

明示に当たっては、機能要件（インターフェース）を示すシステム間関連図、システム間インターフェース定義書等のドキュメントが有効である。


依頼内容・業務の詳細

機能要件①プロセス

機能情報関連図：業務機能間の情報（データ）の流れを明確にする。

業務流れ図：業務がどのような組織、手段、手順で処理されるかを明確にする。

業務処理定義書：業務流れ図の各業務処理機能の内容を明確にする。

システム機能関連図：業務機能を実現する情報システムの機能を明確にする。


依頼内容・業務の詳細

機能要件②データ

概念ER 図：情報システムにおける概念レベルのデータ構造を明確にする。

データ項目定義書：データ項目の要件を明確にする。


依頼内容・業務の詳細

機能要件③インターフェース

システム間関連図：検討対象システムと既存システム又は周辺システムとのデータの流れを明確にする。

システム間インターフェース定義書：検討対象システムと既存システム又は周辺システムとのデータのやりとりを明確にする。

画面、帳票一覧表：検討対象のビジネス機能で必要となる画面・帳票を業務フローごとに洗い出し、画面・帳票一覧として整理し、基本的なビジネスデータの所在を明確にする。

画面、帳票レイアウト：各画面、帳票のレイアウトサンプルを集め、整理し、基本的なビジネスデータを収集することで、画面・帳票を処理する業務設計条件を明確にする。


システム構成

システムに必要なソフトウェアの機能を明示する。また、国内外の流通ソフト等があれば例示して、具体的な業務機能を明示する。さらにシステムに必要なハードウェア及び周辺装置及びネットワーク等の概念図や構成事例を例示する。また、必要な容量、機能、性能、ネットワークの接続性については、特記すべき事項を明示する。


納期

ソフトウェア、ハードウェア等の導入時期、試運転時期、テスト時期、並行処理時期、運用時期等それぞれの納期を明示する。


必要な技術・技術者の資格

提案依頼に伴って、システムの開発、運用、データベースの取扱いに関し、必要な技術や技術者の資格要件があれば明示する。


成果物・納入物

今回のシステム依頼に関する成果物、納入物を明示する。特に文書類は、記述方法、記述の詳細さ、印刷等で作業工程が大きく変わる場合があるので、所定の書式なのか、ベンダ側の書式で可なのか、記述事例等をつけて明示する。


開発標準類の確認

提案依頼するシステム開発の開発標準類をベンダと確認し、開発標準類の変更が必要な場合には、共通フレームの修整プロセスを適用するので、ベンダの参加の有無及び方法を明示する。


共同レビュー

提案依頼するシステム開発における節目を定義し、ユーザとベンダの双方が参加する共同レビューの進め方を明示する。また、契約レビューの有無と方法についても明示する。


工程計画

提案依頼物件の作業スケジュールの概要(ユーザ側のチェックポイント時期)を明示する。また工程を管理する上で必要となる会議や報告の周期や方法についても明示する。


開発推進体制

システムを推進するユーザ側の組織体制の概要を提示する。例えば、調査段階、開発段階、運用段階等それぞれの段階で協力・管理・監査・検収する部門の支援体制を、必要に応じて明示する。


非機能要件

①品質要件

システムに対する品質に関する要件

・品質、性能条件

システムの品質、性能に関し、相互に確認をするための保証、例えば、納入時の品質、テストの方法、テストツールの例示等の品質・性能保証に関する要求を明示する。


非機能要件

②技術要件

ソフトウェアの開発、維持管理（保守管理）、支援及び実行のための技術・環境に関連した要件

・開発モデル・開発言語：システム開発に必要な開発モデル、開発標準や開発ツール等の指定がある場合はそれを明示する。また、開発に必要な言語や特定用途向け言語等があれば、これを明示する。

・支援ツール：ユーザが持つ支援ツールやベンダに求める支援ツール等について、ツール機能の仕様や性能について明示する。

・ソフトウェア製品の使用：ユーザが使っているソフトウェア製品、ベンダに新規に求めるソフトウェア製品等について、類似するソフトウェア製品名称、使用条件、個数等の要求を一覧の形で例示する。

・保守条件：ソフトウェアの保守体制の有無、無償保守期間、ハードウェア保守の体制や組織、夜間休日保守の可能性、時間外保守の単価や条件リモート保守等の条件を明示する。


③セキュリティ要件

セキュリティに関する要件

・セキュリティチェックシートに基づく条件：セキュリティチェックシートをもとに具体的に明示する。・たとえば、○○○に基づく条件：「情報システム開発契約のセキュリティ仕様作成のためのガイドラインに記載されている最低限検討するべきデフォルト緩和策など、セキュリティ基準等公表情報をもとに、具体的に明示する。


非機能要件

④運用・操作要件

安定したシステム運用を行うための検討対象のビジネス機能を実行するシステムについての運用要件（含む、SLA、BCP）と操作要件（エンドユーザ操作方法等）

・運用条件：システムの稼働時間や稼働環境に関する運用条件を明示する。例えば、情報システム部門の稼働体制や稼働時問、利用者部門の利用時間や利用方法等を明示する。


非機能要件

⑤移行要件

現行システムから新システムへの移行対象、移行方法などの移行に関する要件

・移行条件：移行対象業務・プログラム・ハードウェア、移行手順、移行時期等を明示する。


非機能要件

⑥付帯作業

システム構築に付帯する作業に関する要件


非機能要件

⑦その他

上記に該当しない要件（導入教育等）


開発体制・開発環境

記述項目

解説

評価

役割分担

ユーザとベンダ双方の作業進捗や費用負担の責任を明確にするため、作業推進の工程毎に発生する各種作業のそれぞれの役割や完了時期を明示する。役割分担の表示に際しては、責任者の明示と共に、機能要件（インターフェース、プロセス、データ）、非機能要件（品質要件、技術要件、その他の要件）の担当者名も明示する。


作業場所

システム開発に伴い、工程別に必要となる作業場所、例えば、作業室、会議室、開発用計算機や端末や通信装置等の設置場所の提供が可能か否か、これらはユーザ、ベンダのいずれが準備すべき事項なのかを明示する。


開発機器・使用材料費の負担

システム開発に必要な資材、例えば、開発用電子計算機費用の負担方法、端末や周辺装置の導入時期や負担方法、また、備品や消耗品類の有償・無償等の提供条件を明示する。


貸与物件・資料

システム開発に必要な資料・伝票・書類・機器類等の貸与の条件や、機密保持条件、返還の必要性、持ち出し禁止条件等について明示する。



保証要件

記述項目

解説

評価

システム

ソフトウェアのバグ等に関する保証期間、ハードウェア装置の機能・性能に関する保証要件や限界性能、ネットワークの機能や接続台数等に関するシステムとしての保証要件を明示する。


品質保証基準

ソフトウェア・ハードウェア・ネットワークの機能や性能の保証基準を明示する。また、文書類の記述方法の基準や標準等があれば、それら基準を具体的に明示する。


記述項目

解説

評価

システムの性能

ソフトウェア機能、性能に関する安全性、ハードウェア装置の機能・性能、容量等に関する信頼性や、ネットワークの機能・性能に関する応答性、その他システム全体の信頼性、安全性・応答性等の保証に関する要求を明示する。


セキュリティ

計算機や端末に関する可用性の確保、利用者に関する個人情報の安全管理、業務システムの利用に関する機密性の確保等、システムに必要なセキュリティ上の対策（機密性、可用性及び完全性の確保）や障害発生に対する状況別対応策の必要性を明示する。また、「情報システムの構築等におけるセキュリティ要件及びセキュリティ機能の検討に関する解説書」（内閣官房情報セキュリティセンター）42を参考にすること。


デモ・テスト計画

システムモデルの提示やシステム機能確認のためのデモの必要性、その他テストの時期等について明示する。


契約事項

記述項目

解説

評価

発注形態

システム開発の発注形態が、例えば、基本契約と個別サービス契約、SI 包括契約、部分請負契約、ソフトウェアのみの契約等、発注に関する形態を明示する。


その他、契約書中に盛り込むべき重要事項

契約類型（準委任／請負）、再委託、損害賠償責任（範囲・限度額・期間）、知的財産権の帰属、第三者ソフトウェアの利用、検収・支払い条件等について、これらの条件、あるいは要求について予め明らかにしておく。


その他

記述項目

解説

評価

用語

提案依頼書に使用している用語の定義を明示する。共通フレーム2013の用語を使用することが望ましい。また、ベンダに対し提案書で使用する用語と共通フレーム2013の用語との読み替え表が必要ならその旨明示する。


外部委託に関する管理

ベンダが、システム、ソフトウェア製品の開発又はソフトウェアサービスを外部委託しようとする場合の外部委託の管理方法（事前通知の要否等）を明示する。


リスクに対する相互認識

システムの開発に関しユーザとベンダの双方が、新技術適用のリスクや詳細仕様決定の遅れあるいは開発作業の遅れ等のリスクの予測や費用増大に対する原価意識を持ち、双方の立場を尊重し合いながら、予測されるリスクの抑制を徹底して管理していく必要があることを明示し、相互認識とする。


仕様変更・機能追加等の条件

大きなシステム開発に関しては、開発契約締結後にシステム仕様の補正(機能追加)や仕様変更等が生じるので、これを管理する変更管理プロセスを契約書において明示する。





3.業務システム仕様書の記述レベル

システム発注にあたっては、業務システム仕様書を作成する必要がある。そのときの記述レベルを明確にすることで、合意レベルも明確になり、トラブルを防止することができる。以下は日本情報システム・ユーザ協会「ビジネスシステム定義研究2004」（https://www.juas.or.jp/cms/media/2017/01/03businesssystemteigi.pdf）で作成したレベルである。A-Dのドキュメントはユーザ部門には必要であるが、見積もり時に必ずしも添付する必要はない業務システム仕様書であり、ドキュメント1-10が見積要求仕様書となる。

仕様の責任と記述項目

レベル1

レベル2

レベル3

レベル4

レベル5

ビジネス機能提示

ビジネスプロセス提示

業務フロー提示

業務処理提示

業務処理/データ項目提示

責任分担

1

ユーザ側責任

RFPレベルでベンダ提案書をベースに要求仕様書を明確にしシステム構築

既存システム再構築ではビジネスプロセス定義と既存システム仕様提示で発注

As-Isベース機能拡張で業務フローを通常業務/例外業務処理につき提示

To-Beベースの業務処理方法の提示による効果的な発注

To-Beベースのシステム構築の発注によるシステム構築効率追及

要求仕様承認の責任

基本設計承認の責任

詳細設計/機能性能の承認

納品仕様/成果物の仕様承認

システム設計の効率化推進

2

ベンダ側責任

RFPのビジネス機能からTo-Beのあるべき姿のシステム機能を提案

提示ビジネスプロセスの改革を実現するシステム構築を実現

更なるTo-Be機能への展開とシステム設計と納品物のQCD追求

To-BeベースのIT処理方式からの改善改革と構造的で明快なシステム構築

To-Beベースのシステム機能強化と最適化の追求

納入/契約仕様の実現

設計、納入品の契約不適合責任

システム設計開発の合理化/コスト低減

きれいな構造設計/コスト低減

システム設計開発の合理化/コスト低減

A

ビジネス機能関連図



IS部門で企業/事業全体機能定義

IS部門で企業/事業全体機能定義

IS部門で企業/事業全体機能定義

B

ビジネス連携図



業務と対外系/他部門間との連携

業務と対外系/他部門間との連携

業務と対外系/他部門間との連携

C

ビジネスルール定義書



企業/業務上の戦略ルール

企業/業務上の戦略ルール

企業/業務上の戦略ルール

D

システム化目標定義書

業務システム化の目標設定

業務システム化の目標設定

業務システム化の目標設定

業務システムのIT効果定義

業務システムのIT効果定義

1

ビジネス機能構成表

ビジネス機能の大分類定義

ビジネス機能の中小分類定義

ビジネス機能の細分類定義

ビジネス機能の細分類定義

ビジネス機能の細分類定義

2

ビジネスプロセス関連図


ビジネスプロセス間の関連定義

ビジネスプロセス間の関連定義

ビジネスプロセス間の関連定義

ビジネスプロセス間の関連定義

3

業務流れ図



業務処理フロー指示
（含む例外処理）

業務処理フロー指示
（含む例外処理）

業務処理フロー指示
（含む例外処理）

4

業務機能関連図




DFD方式での
上位DFDとして作成

DFD方式での
上位DFDとして作成

5

業務ルール定義書




業務処理上の社内ルールを定義

業務処理上の社内ルールを定義

6

業務処理手順書




個別の業務処理手順を定義

個別の業務処理手順を定義

7

画面／帳票一覧



基本的に必要な画面/帳票一覧

基本的に必要な画面/帳票一覧

基本的に必要な画面/帳票一覧

8

画面／帳票レイアウト



画面/帳票レイアウトを定義

画面/帳票レイアウトを定義

画面/帳票レイアウトを定義

9

データ項目定義書





データ項目の属性を定義

10

運用・操作要件所



業務システムの
運用・操作の条件設定

業務システムの
運用・操作の条件設定

業務システムの
運用・操作の条件設定

該当仕様書評価









　　　　　　　　 上記評価欄にチェックとコメントを記載



4.ユーザIT成熟度チェックリスト

ITを導入するときに、ユーザのITに対する準備状況（成熟度）が結果に大きな影響を与えることがあり、ベンダにとって重要な情報である。よって、ＲＦＰを出すときなどにユーザ自身が自分のレベルについて評価を行うことが望ましい。また、ＲＦＰに第三者評価を行う場合にも公正なチェックリストがあることが望ましい。ここでは、経済産業省IT経営力指標43を活用する。IT導入にあたってのユーザ成熟度を、以下の評価軸で評価を行う。
◎：期待以上である　　　 ○：十分なレベルである　△：不十分なレベルである　×：できていない　
ＮＡ：該当しない、不明

ユーザ評価チェックシート Ⅰ．経営戦略とIT戦略の融合

　

ステージ1

ステージ2

ステージ3

ステージ4

評価項目

◆経営層は解決すべき自社の経営課題を把握していない。

◆不十分なところはあるが経営層は解決すべき自社の経営課題を把握している。

◆経営層は解決すべき自社の経営課題を十分把握している。

◆経営層は解決すべき自社の経営課題を十分把握している。

評価

　

　

　

　

評価項目

◆経営戦略が策定されていない。あるいは経営戦略は策定されているが実行不可能な非現実的なものである。

◆策定された経営戦略が、経営層のみの周知に留まっており全社的に浸透していない。
◆経営戦略の想定対象期間が比較的短期（概ね1年程度の将来）である。
◆経営戦略としての全社的な視点に欠ける部分はあるものの、事業部門、機能別組織単位では効率化の促進や付加価値を創造している。

◆策定された経営戦略が、全従業員に周知されている。あるいは経営層及び管理者層に周知され、管理者層の指揮命令の下に従業員が業務を遂行している。
◆経営戦略の想定対象期間が比較的中長期（概ね３年以上）を見据えている。

◆経営戦略は、業務改革の実行が中心である。

◆経営戦略が、企業全体あるいは企業グループ全体の視点から、事業部門、機能別組織の部門戦略に横串を刺した形で策定されている。この結果、企業全体あるいは企業グループ全体での効率化の促進や付加価値を促進するかどうかが経営戦略の具体的な実行にあたっての判断基準となっている。

◆策定された経営戦略が、全従業員に周知されている。あるいは経営層及び管理者層に周知され、管理者層の指揮命令の下に従業員が業務を遂行している。
◆経営戦略の想定対象期間が比較的中長期（概ね３年以上）を見据えている。

◆経営戦略には、ビジネス環境の変化を見極め、業務改革の実行及び新しいビジネスモデルの展開を織り込んでいる。

◆垂直型の企業間連携（調達先から販売先に至るまでの連携）や、水平型の企業間連携（同一産業内での連携）での実現可能性を考慮に入れた上で、企業全体、あるいは企業グループ全体の視点から経営戦略が策定されている。この結果、企業間連携全体で最適な効果を得られるかどうかが経営戦略の具体的な実行にあたっての判断基準になっている。

評価

　

　

　

　

評価項目

◆IT戦略が策定されていない。あるいはIT戦略は策定されているが実行不可能な非現実的なものである。

◆IT戦略は経営戦略と整合性が取れている。

◆IT戦略の決定プロセスには、経営層が参画している。

◆IT戦略が事業部門、機能別組織の単純合計となっている。あるいは全社的な視点からIT戦略は策定されているが、企業内部での周知が十分ではない。

◆全社的な視点からのITの活用やIT投資判断を下すまでには至っていないが、事業部門、機能別組織単位では効率化の促進や付加価値を創造するようなIT活用、IT投資を行っている。

◆IT戦略は経営戦略と整合性が取れている。

◆IT戦略の決定プロセスには、経営層が参画している。

◆IT戦略が企業全体あるいは企業グループ全体の視点から事業部門、機能別組織のIT活用方針に横串を刺した形で策定されている。この結果ITの活用やIT投資の判断を下すにあたり、企業全体あるいは企業グループ全体での効率化の促進や付加価値を促進するようなIT活用、IT投資を行っている。

◆IT戦略は経営戦略と整合性が取れている。

◆IT戦略の決定プロセスには、経営層が参画している。

◆IT戦略の策定にあたり、ITを活用した垂直型の企業間連携（調達先から販売先に至るまでの連携）や、水平型の企業間連携（同一産業内での連携）の実現可能性を考慮に入れた上で、企業全体、あるいは企業グループ全体の視点から事業部門、機能別組織のIT活用方針に横串を刺した形で策定されている。この結果、企業間連携全体で最適な効果を得られるかどうかがITの活用、投資の判断基準になっている。

評価

　

　

　

　

評価項目

◆IT導入の目的が不明確であり、効果が得られていない。

◆事業部門、機能別組織内部の効率化や付加価値の創造、あるいは事業部門、機能別組織が直接的に接する外部組織との取引関係、情報共有などがIT戦略の中心となっている。

◆企業、企業グループにおける情報の共有化や取引プロセスの効率化、あるいは顧客の視点に立った付加価値の創造などがIT戦略の中心となっている。

◆垂直型企業間連携、水平型企業間連携における情報の共有化や取引プロセスの効率化、あるいは顧客の視点に立った付加価値の創造などがIT戦略の中心となっている。

評価

　

　

　

　

基礎的事項

評価

◆自社の社風、企業規模、業種、製品やサービスなどと、ITとの親和性を経営者が理解している。

　

◆ITを適材適所に導入し活用することによって、新価値創造、競争優位性獲得をより効率的、効果的に実現できる可能性を経営者は理解している。

　

◆IT戦略の策定においては、ITに関する新規技術や新規のソリューション動向を随時把握し、それらを適切に活用する視点が織り込まれている

　

◆経営層は、CIOやCIOの機能を有する者と定期的・継続的にITの活用に関する意見交換を実施している。

　

Ⅱ．現状の可視化による業務改革の推進とITの活用による新ビジネスモデルの創出、ビジネス領域の拡大

　

ステージ1

ステージ2

ステージ3

ステージ4

評価項目

◆社内の業務プロセスの可視化が行われていない。◆無駄・重複・非効率・属人性がどの部分から生じているのか把握していない。

◆社内の業務プロセスが全従業員に理解できるほどに可視化（フローチャートによる“見える化”や業務の文書化）されており、事業部門、機能別組織単位で無駄・重複・非効率・属人性の排除に取り組むための業務改革が行われている。

◆社内の業務プロセスが全従業員に理解できるほどに可視化（フローチャートによる“見える化”や業務の文書化）されており、無駄・重複・非効率・属人性の排除に取り組むために、事業部門、機能別組織単位だけではなく、各組織、部門間にまたがる企業全体、企業グループ全体での業務改革が行われている。
◆可視化によって作成された文書は文書管理システムの導入などによって、更新履歴管理も行われている。

◆連携先企業とのやりとりを含め、業務プロセスが全従業員に理解できるほどに可視化（フローチャートによる“見える化”や業務の文書化）されており、無駄・重複・非効率・属人性の排除に取り組むために、企業全体、企業グループ全体だけではなく、連携範囲全体にまたがった業務改革が行われている。
◆可視化によって作成された文書は文書管理システムの導入などによって、更新履歴管理も行われている。

評価

　

　

　

　

評価項目

◆業務改革を行っていない。

◆業務改革の主たる要素が無駄の排除や効率化であり、ITの活用も省力化、自動化が中心であって、情報共有という観点からのIT活用は事業部門、機能別組織単位に限られている。

◆業務改革の主たる要素が無駄の排除や効率化から情報の共有に移っており、ITの活用も省力化、自動化だけにとどまらず情報共有による新しい価値の創造が中心となっている。

◆業務改革の範囲が企業全体、あるいは企業グループ全体での無駄の排除や効率化、情報の共有に移っており、ITの活用も垂直型、水平型企業間での省力化、自動化、情報共有による新しい価値の創造が中心となっている。

評価

　

　

　

　

評価項目

◆ITの導入による効果が得られていない。

◆事業部門、機能別組織内部の情報共有がITを活用することによって促進された結果、新規顧客の開拓や新たなサービスの創出など収益の向上につながった。

◆企業全体、あるいは企業グループ全体での情報共有がITを活用することによって促進された結果、新たな業務プロセスを生み出すようなビジネスモデルやサービスが生まれ、顧客満足度の向上につながった。

◆取引先、同業他社も含めた企業間連携内での情報共有がITの活用によって促進された結果、既存の企業間連携を深化させる、あるいは新たな企業間連携を生み出すようなビジネスモデルやサービスが生まれ、顧客満足度の向上につながった。

評価

　

　

　

　

評価項目

◆自社にとっての脅威を把握できていない。

◆自社にとっての脅威を把握している。

◆自社にとっての脅威を把握し、発生可能性、発生した場合の損害の程度などをもとに優先順位を付けた上で、損害を発生させないための仕組みを構築する。

◆ITの活用によって、損害の実現を防止、発見するための機能を効率的に対応策に組み込む。

◆自社にとっての脅威を把握し、発生可能性、発生した場合の損害の程度などをもとに優先順位を付けた上で、同業他社、取引先等との連携によって損害の発生を防ぐとともに、そのためのコストシェアなどを実現する。

◆ITの活用によって、損害の実現を防止、発見するための機能を効率的に対応策に組み込む。

評価

　

　

　

　

評価項目

◆職務権限や職務分掌が明確に定められていない。

◆業務が属人的になっている。

◆職務権限と職務分掌が定められており、定期的に見直されている。

◆職務権限と職務分掌が定められ、定期的に見直されている上に、システム化された業務部分については、職務権限、職務分掌を超えた権利行使ができないよう、ITを利用したアクセス制限やログ管理といった予防的な措置が施されている。

◆情報へのアクセスや利用・活用に関する連携企業相互間での契約や覚書などが取り交わされており、かつシステム化された業務部分については、契約で取り決めた範囲や権限を逸脱しないよう、ITを利用したアクセス制限やログ管理といった予防的な措置が施されている。

評価

　

　

　

　

評価項目

◆業務プロセスの中の不正や誤りを防止、発見するため手続が仕組みとして定められていない。

◆業務プロセスの中の不正や誤りを防止、発見できるような相互チェックの仕組みを取り入れている。

◆業務プロセスの中に不正や誤りを防止、発見できるような相互チェックの仕組みを取り入れ、内部監査部門など直接的に業務と関連しない部門や担当者が継続してモニタリングしている。

◆業務プロセスの中に不正や誤りを防止、発見できるような相互チェックの仕組みを取り入れた上で、各企業の業務範囲を内部監査部門など直接的に業務と関連しない部門や担当者が継続してモニタリングしているとともに、システムが企業間の連携の中心にある場合にはシステム全体のシステム監査などを実施している。

評価

　

　

　

　


Ⅲ．標準化された安定的な*IT基盤の構築
*ハードウェア、ネットワーク設備、基本ソフトウェアなど、アプリケーションに左右されにくい汎用性の高い部分

　

ステージ1

ステージ2

ステージ3

ステージ4

評価項目

　

　

◆エンタープライズ・アーキテクチャの概念を導入し、経営資産のポートフォリオを分析し、業務プロセスの標準化を推進する。

◆エンタープライズ・アーキテクチャの概念を導入し、経営資産のポートフォリオを分析し、業務プロセスの標準化を推進する。

評価

　

　

　

　

評価項目

◆自社のシステム構成をよく理解していない

◆個別のアプリケーションごとに、ネットワーク、サーバー、ストレージ、ミドルウェア、データベース、認証フレームワークなど（以下、システム基盤）を構築している。

◆自社内に多数存在するアプリケーションに共通して求められる、システム基盤の要件を抽出し、集中、統合化すべきコンポーネントを見極め、共通的なシステム基盤として標準化を実施することで、開発・運用の生産性を向上させ、堅牢で安価なシステム基盤を構築するとともに、ビジネス環境の変化にも容易に対応できている。

◆企業間、産業内で共通化、標準化されたシステム基盤を導入し、開発・運用の生産性を向上させ、堅牢で安価なシステム基盤を構築し、ビジネス環境の変化にも容易に対応できる。

評価

　

　

　

　

評価項目

◆全社横断的なシステム基盤の構築ポリシーが作成されていない。あるいは作成されていても遵守がなされていない。

◆全社横断的なシステム基盤の構築ポリシーが作成されていない。あるいは作成されていても遵守がなされていない。

◆全社横断的なシステム基盤の構築ポリシーを定め、システム基盤の中で共通化すべき部分と差別化すべき部分を明確にする。

◆企業間、あるいは産業内でのシステム基盤の構築ポリシーが作成され、企業横断的、産業横断的システムの構築にあたっては構築ポリシーが遵守されている。

評価

　

　

　

　

評価項目

◆社内の利害調整を行うことができず、システム基盤の標準化が行われていない

◆社内の利害調整を行うことができず、システム基盤の標準化が行われていない

◆全社横断的な統制管理組織を編成するなど、設計思想・ポリシーに沿ったIT基盤の構築を行うために、社内の利害調整を行い、全社的な観点からのIT投資計画の推進が行われている。安定化を図ることで、ビジネス環境の変化に安定的に柔軟に対応できる。

◆企業横断的に統制管理組織を編成してIT構造（アーキテクチャ）の安定化を図ることで、取引先も含めて、ビジネス環境の変化に安定的に柔軟に対応できる。

評価

　

　

　

　

基礎的事項

評価

◆自社の経営資産と経営環境を把握し、将来を見越した情報化モデルを構築する。

　

◆導入済みのシステムを定期的に棚卸しし、利用状況やトータルコストを把握し、ソフトウェア資産としての価値を評価する。

　



Ⅳ．ITマネジメント体制の確立

　

ステージ1

ステージ2

ステージ3

ステージ4

評価項目

◆IT戦略を策定していない

◆ 自社のIT戦略の立案にあたっては、経営層及びIT利用部門のトップが参画している。

◆経営層及びIT利用部門のトップが参加する企業全体のIT戦略の立案・管理に関する協議機関、会議体を有しており、経営の観点からIT投資の判断をしている。

◆経営層及びIT利用部門のトップが参加する企業全体のIT戦略の立案・管理に関する協議機関、会議体を有しており、購買・調達先の情報を社内で共有し、経営の観点からIT投資の判断をしている。

評価

　

　

　

　

評価項目

◆ITの導入や活用について理解しておらず、コンサルタントやベンダーに結果的に丸投げとなっている。

◆CIO、もしくはCIOの機能を有する担当者、担当部門を有しており、自社のIT投資、IT資産管理に関する方向性を定め、ITの活用によって自社の業務改革に貢献している。

◆CIO機能を有する担当者はいないが、外部のコンサルタント等の助言を受けた上で、経営層が自社のIT投資、IT資産管理に関する方向性を定め、ITの活用によって自社の業務改革を推進している。

◆CIO、もしくはCIOの機能を有する担当者、担当部門を有しており、自社のIT投資、IT資産管理に関する方向性を定め、ITの活用によって自社の業務改革に貢献している。

◆グループCIO・グループIT部門を設置し、あるいは同様の機能を有する担当者、担当部門を有しており、企業グループ全体でのIT投資、IT資産管理に関する方向性を定め、ITの活用によって企業グループ全体の業務改革に貢献している。

◆CIO機能を有する担当者はいないが、外部のコンサルタント等の助言を受けた上で、経営層が自社のIT投資、IT資産管理に関する方向性を定め、ITの活用によって自社の業務改革を推進している。

◆グループCIO・グループIT部門を設置し、あるいは同様の機能を有する担当者、担当部門を有しており、企業間連携の可能性を視野に入れながら、企業グループ全体でのIT投資、IT資産管理に関する方向性を定め、ITの活用によって企業グループ全体の業務改革に貢献している。

◆CIO機能を有する担当者はいないが、外部のコンサルタント等の助言を受けた上で、経営層が自社のIT投資、IT資産管理に関する方向性を定め、ITの活用によって自社の業務改革を推進している。

評価

　

　

　

　

評価項目

◆アウトソーサー・ベンダーの評価は行っていない。

◆評価基準は定めていないが、アウトソーサー・ベンダーの評価を行っている。

◆アウトソーサー・ベンダーの定量的な評価基準（SLAなど）を定めている。

◆アウトソーサー・ベンダーの定量的な評価基準（SLAなど）を定めており、評価結果に対する賞罰を実行している。

評価

　

　

　

　

基礎的事項

評価

◆CIO（CIOの機能を担う人材）のミッションは明確に定められている

　

◆CIO（CIOの機能を担う人材）は経営層と頻繁に情報交換を行っている。

　

◆CIO（CIOの機能を担う人材）はITに関する新技術、価格動向、将来動向を定期的に把握している

　

◆CIO（CIOの機能を担う人材）は自社に必要なITは何か、またそのITの利用・活用のタイミングを常に意識している

　

◆自社IT部門（情報システム部門等）、子会社IT部門、IT子会社（情報システム子会社等）、外部ベンダー・アウトソーサーなどのそれぞれの役割や機能、責任などが明確になっている。

　

◆自社IT部門（情報システム部門等）、子会社IT部門、IT子会社（情報システム子会社等）、外部ベンダー・アウトソーサーなど、それぞれの役割や機能、責任分担に従った行動によって、適正な価格でシステム導入の高い効果を実現している。（CIOのみを置いて、自前でのIT部門を持たず全てアウトソースするという選択もあり得る）。

　

◆CEOは自社の経営戦略の実現に向けたIT戦略の位置づけとIT活用の有効性についてよく理解し、対外的に説明ができる。

　

◆プロジェクトごとにアウトソーサー・ベンダーに求める水準を定めて選定している。

　

◆重要なアウトソーシング契約については、弁護士、法務部など法的知識を有している者によってチェックされている。

　

Ⅴ．IT投資評価の仕組みと実践 *1（コンピュータシステムの導入、維持・管理などにかかる総経費を表す指標）

　

ステージ1

ステージ2

ステージ3

ステージ4

評価項目

◆IT投資によって得られる効果を明確に理解しないまま投資を決断している。

◆プロジェクトごとのIT投資の効果を投資前に定量（指標を含む）的に予測している

◆プロジェクトごとのIT投資の効果を投資前に定量（指標を含む）的に予測している

◆プロジェクトごとのIT投資の効果を投資前に定量（指標を含む）的に予測している

評価

　

　

　

　

評価項目

◆IT投資の効果を感じていない。あるいは導入したITを使いこなしていない。

◆IT投資後の投資効果測定を行っていない。

◆プロジェクトごとのIT投資の効果を投資後に定量（指標を含む）的に測定し、投資前の評価と比較した上で内容の改善やシステムの続行の是非などを判断し、PDCAサイクルを確立している。

◆プロジェクトごとのIT投資の効果を投資後に定量（指標を含む）的に測定し、投資前の評価と比較した上で内容の改善やシステムの続行の是非などを判断し、PDCAサイクルを確立している。

評価

　

　

　

　

評価項目

◆IT資産の導入コスト、維持・管理コストなどを把握していない。あるいは把握しているが、それが適当であるかどうか検討していない。

◆IT資産の導入コスト、維持・管理コストなどは次年度の予算ベースでは把握しているが、システムの使用期間トータルでは把握していない。

◆IT資産のTCO（コンピュータシステムの導入、維持・管理などにかかる総経費を表す指標）を分析し、自社のコスト構造を把握している

◆定期的にIT資産のTCO*1を分析し、自社のコスト構造を把握した上で、常に最適なポートフォリオの管理を行っている。

評価

　

　

　

　

基礎的事項

評価

◆ IT投資に対する考え方や判断基準が定められており、経営課題の優先度・緊急度・期待される効果・リスクを整理して、総合的に判断している

　

◆ IT投資実施においては、考え方や判断基準を提示した上で経営層・IT利用部門の合意を得ている

　

◆ IT投資の評価には、定量的な評価とともに定性的な効果も重視している

　

◆CIOとCFO（最高財務責任者）が定期的にIT投資の効果について意見交換しており、その結果が他の経営層に報告されている

　

Ⅵ．IT活用に関する人材の育成

　

ステージ1

ステージ2

ステージ3

ステージ4

評価項目

◆経営層や社員のITスキル向上につながるような取り組みは特段行っていない。あるいは行っている場合であっても不定期であり、次回の開催予定は定まっていない。

◆経営層や社員のIT活用能力を向上させるために、マニュアルを整備している。

◆経営層や社員のIT活用能力を向上させるための研修会や啓蒙活動を定期的に行っている。

◆経営層や社員のIT活用能力を向上させるために、マニュアルを整備している。

◆経営層や社員のIT活用能力を向上させるための研修会や啓蒙活動を定期的に行っている。

◆経営層や社員のIT活用能力を向上させるために、ヘルプデスクの設置など、社内外を問わず疑問点についての問い合わせ窓口を用意している。

◆経営層や社員のIT活用能力を向上させるために、マニュアルを整備している。

◆経営層や社員のIT活用能力を向上させるための研修会や啓蒙活動を定期的に行っている。

◆経営層や社員のIT活用能力を向上させるために、ヘルプデスクの設置など、社内外を問わず疑問点についての問い合わせ窓口を用意している。

◆調達先や販売先など連携先企業との間で共通システムを使いこなすための研修会（共同開催も含む）を定期的に行っている。

評価

　

　

　

　

基礎的事項

評価

◆CIO（CIOの機能を担う人材）に求められる要素と水準が明確になっている

　

◆CIO（CIOの機能を担う人材）の育成プログラムがある。あるいは、将来のCIO候補をある程度絞ってキャリアを積ませている。

　

◆社内IT部門のミッション・職務機能・スキルミックス・責任分界を明確にしている

　

◆ITスキル標準などを活用して、社内IT部門の社員の技術力・スキルを客観的・数量的に把握する仕組みを持っている

　

◆社内IT部門の社員のスキルを外部の評価基準（第三者など）を参照して評価している

　

◆社内IT部門の社員のスキル獲得は、人事評価やキャリアパスとリンクされている

　

◆社内IT部門の社員に対して、経営戦略とIT戦略の関係について、CIO自らが定期的に説明している

　

◆経営戦略及びIT戦略に沿って、自社IT部門の社員の採用計画（人数、スキル等を考慮）、採用方針を設定している

　

◆自社IT部門の社員が、一定期間、IT利用部門に異動する仕組みがあり、IT利用部門の求めるニーズを把握したうえでITの活用方策を検討している。

　

◆社内IT部門の社員のスキル獲得のための教育プログラムを整備している

　

◆自社IT部門の社員が新技術や不足するスキルを獲得するために、定期的に、社外のプログラムに参加したり、先進企業で研修を受けたりさせている

　


Ⅶ．ITに起因するリスクへの対応

　

ステージ1

ステージ2

ステージ3

ステージ4

評価項目

◆ 経営層はITに関連・起因するリスク（情報漏洩・ウィルス・不正アクセス等）の脅威について理解していない。

◆ 経営層はITに関連・起因するリスク（情報漏洩・ウィルス・不正アクセス等）の脅威を認識している。

◆ 経営層はITに関連・起因するリスク（情報漏洩・ウィルス・不正アクセス等）の脅威を認識している。

◆ ITに関連・起因するリスクの潜在・顕在要因を網羅的に把握し、発生の可能性、発生した場合の影響などを予測し、対応策について検討を行っている。

◆ 経営層はITに関連・起因するリスク（情報漏洩・ウィルス・不正アクセス等）の脅威を認識している。

◆ ITに関連・起因するリスクの潜在・顕在要因を網羅的に把握し、発生の可能性、発生した場合の影響などを予測し、対応策について検討を行っている。

評価

　

　

　

　

評価項目

◆従業員に対してITに関連・起因するリスクについて説明を行っていない。

◆従業員に対してITに関連・起因するリスクについての情報を提供している。

◆従業員に対して適切な情報セキュリティ対策や情報管理についての教育・研修・訓練を実施している。

◆従業員（パートタイマー・アルバイト、派遣社員を含む）に対してITに関連・起因するリスクについての情報を提供している。

◆従業員（パートタイマー・アルバイト、派遣社員を含む）に対して適切な情報セキュリティ対策や情報管理についての教育・研修・訓練を実施している。

◆従業員（パートタイマー・アルバイト、派遣社員を含む）及び調達先や販売先など連携先企業に対してITに関連・起因するリスクについての情報を提供している。

◆従業員（パートタイマー・アルバイト、派遣社員を含む）に対してに対して適切な情報セキュリティ対策や情報管理についての教育・研修・訓練を実施している。

評価

　

　

　

　

評価項目

◆システムの改ざん・不正アクセスを防ぐ仕組みは特にない。

◆アクセス権限やプログラムの登録管理の設定などにより、事前にシステムの改ざんや不正アクセスを防ぐ仕組みがある。

◆アクセス権限やプログラムの登録管理の設定などにより、事前にシステムの改ざんや不正アクセスを防ぐ仕組みがある。

◆アクセスログをとってモニタリングするなど、システムの改ざんや不正アクセスの発生を発見できる仕組みがある。

◆アクセス権限やプログラムの登録管理の設定などにより、事前にシステムの改ざんや不正アクセスを防ぐ仕組みがある。

◆アクセスログをとってモニタリングするなど、システムの改ざんや不正アクセスの発生を発見できる仕組みがある。

評価

　

　

　

　

基礎的事項

評価

◆ 情報セキュリティの推進体制を整備している

　

◆ 情報セキュリティポリシーや情報セキュリティ管理規定を定めている

　

◆ 機密情報・重要情報が外部に漏洩した際の対応マニュアルが整備されており、従業員は常時閲覧できる

　

◆ システム停止などに伴う事業継続計画を策定し、災害をはじめとする物理的リスクに対応できる体制・システムとなっている

　

◆ 内部統制が良好に整備され運用されている

　

◆ CISO（情報セキュリティ統括専任担当）を設置している

　

◆保管データの改ざん防止策として、電子署名とタイムスタンプ（時刻認証）を活用している

　



Ⅷ.「IT経営力指標」ステージの考え方

　

ステージ1

ステージ2

ステージ3

ステージ4

評価項目

○システムによる在庫管理は行っていない。過剰在庫となるリスクはあるものの、材料や製品を多めに在庫しておき、いつでも対応できるようにしている。

○製造工程毎に在庫情報をリアルタイムに把握して、在庫圧縮によるコスト削減を実現している。

○製品に関して部品の調達から営業・販売に直接関わる一連の業務プロセスにおいて在庫情報等を共有し、これを基に業務改革を通じてコスト削減・売上高増大を図っている☆あらゆるサービスにおいて顧客情報を共有することで、重複業務の排除によるコスト削減、利便性の高いサービス提供による売上高増大を図っている。

○調達先・販売先など複数企業とともに、サプライチェーン全体で在庫情報等の製品の生産・販売に係る情報を共有し、企業横断的に在庫圧縮によるコスト削減を図っている。☆提携先など複数企業とともに、企業横断的に顧客に対するサービス提供状況等の情報を共有し、重複業務の排除等によるコスト削減を図っている。

評価

　

　

　

　

評価項目

☆情報は各個人が属人的に保有しており、ナレッジの共有が図られていない。

☆サービス毎・顧客毎の情報管理により、サービス提供を円滑化している。

○製品の調達から営業・販売に関わる責任者（経営層も含む）が、担当部門以外の部門の情報（在庫情報、販売状況、購買先・販売先等）を必要なときに迅速に共有でき、担当部門以外での現状をみながら担当部門の業務改善を図っている☆あらゆるサービスの責任者は、担当部門以外の部門の情報（どの顧客が、いつどんなサービスを受けているか等）を必要なときに迅速に共有でき、担当部門以外での現状をみながら担当部門の業務改善を図っている。

○調達先・販売先などのサプライチェーンと自社のサプライチェーンの両者の最適化に向けて、定期的に関係企業と共同で検討する機会を設け、業務改善を図っている☆提携先などのサービス提供に係る複数企業の最適化に向けて、定期的に関係企業と共同で検討する機会を設け、業務改善を図っている。

評価

　

　

　

　

評価項目

◆各製品・サービスの責任者に適時的確な情報が上がってこない。このため何らかの問題が発生した後でなければ何を改善すべきか把握できない。

◆各製品・サービスの責任者は、必要なときに迅速に担当部門の情報を得ることで、担当部門の業務改善を図っている。

○製品の販売動向を必要なときに全社で共有し、商品企画・開発等の担当者が新製品の開発にあたって迅速に対応している☆サービスの利用動向を、必要なときに全社で共有し、商品企画・開発等の担当者が新サービスの企画にあたって迅速に対応している。

○CEOあるいはCIOは、販売先・調達先のCEO、CIOと定期的に自社・販売先・調達先全体のサプライチェーンの最適化に向けた情報交換を行っている☆CEOあるいはCIOは、販売先・調達先のCEO、CIOと定期的にサービス提供に係る複数企業の最適化に向けた情報交換を行っている。

評価

　

　

　

　

評価項目

◆購買先・販売先に関する必要な情報を、経営者が把握することができない。

◆購買先・販売先に関する必要な情報は、各部門ごとに取りまとめられた上で、定期的に経営者に伝達され、経営判断の材料として活用されている。

◆ITを活用したシステムにより、購買先・販売先に関する必要な情報を、必要なときに（迅速に）経営者が共有し、経営判断の材料として活用している。

◆顧客などから得られる自社にとってのネガティブ情報が、顧客と接する社員・従業員によって共有され、解決に至るまで状況がフォローされるとともに、業務や製品・サービスの改善に繋がっている。

◆自社が調達した製品や部品・サービスに対するネガティブ情報・課題点は、調達先に迅速に伝え、自社と調達先が共同で改善・高度化している。

評価

　

　

　

　

評価項目

◆職務分掌や職務権限が不明確で業務が属人的になっているため、担当者が不在だと業務が滞ってしまう。

◆業務の不正や間違いを防止し、発見する仕組みが不十分であり、従業員による不正や大きなミスがたびたび発生する。

◆職務権限と職務分掌が定期的に見直されている。

◆業務の不正や間違いを防止し、発見する仕組みを取り入れているが、部門によって取り組みに温度差があるなど、不正や大きなミスの撲滅には至っていない。

◆職務権限と職務分掌が定期的に見直されている。

◆各業務領域におけるデータが適切に収集、処理され、財務報告に反映されている。

◆業務の不正や間違いを防止し、発見する仕組みを全社的に取り入れ、経営層から従業員に至るまでに徹底されている。

◆職務権限と職務分掌が定期的に見直されている。

◆各業務領域におけるデータが適切に収集、処理され、財務報告に反映されている。

◆業務の不正や間違いを防止し、発見する仕組みを全社的に取り入れ、経営層から従業員に至るまでに徹底されている。

◆連携先企業との間での取り決めに従って、適正な取引を行っている。

評価

　

　

　

　


5.パッケージソフトウェア選定のためのチェックリスト

パッケージソフトウェアを導入するには、パッケージ製造企業、流通企業、導入支援企業などがかかわるが、それぞれのポリシーや信頼性について評価を行う必要がある。合わせて、パッケージソフトウェアを導入する側の企業の状況やスタンスについて調べ、導入可能か確認する必要がある。パッケージソフトウェア検討にあたって、解説を参考に、以下の評価軸で評価を行う。
◎：期待以上である　○：十分なレベルである　△：不十分なレベルである　×：記述レベルが明らかに不足もしくは記述がない　ＮＡ：該当しない、不明

パッケージソフトウェアベンダ

記述項目

解説

評価

備考

経営安定性

パッケージソフトウェアベンダの経営は安定しているか



出荷履歴

当該製品の初期バージョンとバージョンアップの出荷時期の履歴


海外製品の場合は国内外を分けて提示

出荷累計

初版から累計と提供バージョンの双方の出荷累計


導入企業

当該パッケージソフトウェアを導入している企業の実績を提示


バージョンの明示が必要

導入規模

利用人数や端末数などの導入の規模を提示



海外製品の日本語化

設計時からUnicode対応していたか、表示機能のみ改造か



カスタマイズポリシー

カスタマイズの可否、アドオンへの対応



サービス・保守支援能力

コールセンター・サービス・保守支援拠点があるか



日本語サポート

サポートが日本語で行われているか



パフォーマンス

対応可能台数など



性能

トランザクションの処理スピードなど



バージョンアップの影響

基盤ソフトのバージョンアップの影響を受けやすいか



バージョンアップ
ポリシー

下位互換、上位互換を図る方針か、料金方針はどうか、保守・サポート停止に関する方針



販売店

記述項目

解説

評価

役割分担

パッケージソフトウェアベンダとの役割分担は明確か。


経営安定性

経営は安定しているか


サポート安定性

サポートに長期展望を持っているか


システムインテグレータ

記述項目

解説

評価

経営安定性

経営は安定しているか


該当パッケージソフトウェア使用経験

そのパッケージや関連製品に関する経験を持っているか


該当パッケージソフトウェア使用経験者の確保

今回のプロジェクトに専門家を配置できるのか


パッケージソフトウェアベンダのサポート

SIerはベンダとパートナー契約などをしているのか


代替ソリューションへの対応力

当該パッケージソフトウェア以外にもサービスを提供できるのか


他ユーザからのパッケージソフトウェアに対する評価

記述項目

解説

評価

満足度

使い勝手、投資効果について悪い評価はないか


サポート評価

サポートについて悪い評価はないか


発注者

記述項目

解説

評価

該当パッケージソフトウェアの使用経験

そのパッケージソフトウェアや関連製品に関する経験を持っているか


該当パッケージソフトウェア使用経験者の確保

今回のプロジェクトに専門家を配置できるのか


カスタマイズ交渉経験

投資対効果などを考えて交渉できる担当者がいるか


今回の導入に関する評価

記述項目

解説

評価

業務適合性

パッケージソフトウェアの業務に、現状の業務を合わせることができるか



パッケージソフトウェアをそのまま使うのではなくパラメータの設定が必要か



パッケージソフトウェアに追加開発を実現するアドオン機能があるのか



パッケージソフトウェア本体の機能を改造するカスタマイズができるか


既存システムとの整合

データ連携があるか



インターフェース連携があるか



現行システムとの不整合が発生する可能性は確認したか



データ連携があるか


規模適合性

実績のある規模か



規模の柔軟性はあるか


機器適合性

予定された機器構成で稼動するか


6.SaaS/ASP選定のためのチェックリスト

SaaS/ASPを導入するには、SaaS/ASP提供企業、SaaS/ASPプラットフォーム提供企業などがかかわるが、それぞれのポリシーや信頼性について評価を行う必要がある。合わせて、SaaS/ASPを導入する側の企業の状況やスタンスについて調べ、導入可能か確認する必要がある。SaaS/ASP検討にあたって、解説を参考に、以下の評価軸で評価を行う。
◎：期待以上である　○：十分なレベルである　△：不十分なレベルである　×：記述レベルが明らかに不足もしくは記述がない　ＮＡ：該当しない、不明

SaaS/ASPベンダ

記述項目

解説

評価

利用の継続性

経営安定性

SaaS/ASPベンダの経営は安定しているか。


サービス提供時間帯

サービスの提供時間は十分か。


定期メンテナンス

定期メンテナンス等による停止時間、停止時期、告知方法等は明確か、停止による業務への影響は軽微か。


災害・障害時対応

災害、障害時の対応方法（告知方法、説明方法等）は明確か、システム復旧体制は十分か、停止時間に対する課金方針は妥当か。


サービス廃止時の対応

（倒産・廃止等）

サービスが廃止となった場合であっても代替ソフトの提供、ソースコードの開示等、継続の手段があるか。計画的廃止の場合、告知は何ヶ月前か、何年間使用可能か。データは保全されるか、データの対応はどうなるか。


実績

サービス履歴

当該製品の初期バージョンとバージョンアップの出荷時期の履歴（海外サービスの場合は国内外を分けて提示）


ユーザ累計

初版から累計と提供バージョンの双方の出荷累計（海外サービスの場合は国内外を分けて提示）


導入企業

当該SaaS/ASPを導入している企業の実績を提示（導入企業規模ではなく、導入の規模を提示）


導入規模

利用人数や端末数などの導入規模を提示


ライセンス

業務スケール

ライセンスの増減などが自由にできるか。増減した場合の価格の扱いはどうなるか


価格改定

価格改定のポリシーは開示されているか


途中解約

解約した場合の料金の扱いはどうなるか

データの対応はどうなるか


機能変更

（バージョンアップ）

バージョンアップポリシーは明確か。（強制的に適用されるか、任意か。移行の猶予期間はどの程度か）。下位互換か、上位互換を図る方針か

バージョンアップの際の価格はどうなるか。


機能・パフォーマンス

機能

機能は十分か。クライアント側の推奨環境は提示されているか（推奨環境に合致するか）。実使用環境での試用は可能か（試用期間は十分か）


カスタマイズポリシー

カスタマイズの可否、アドオンへの対応


パフォーマンス

推奨環境下で使用した場合のパフォーマンスは十分か（応答速度、同時接続数、転送量等）。保証はあるか


稼働率

稼働時間が開示されるもしくは稼動目標を示しているか


基盤ソフトの影響

基盤ソフトのバージョンアップの影響を受けやすいか


データの取扱い

データの機密性

ユーザのデータにアクセスできる場合、できる人間が限定されているか


データの権利

データの権利はユーザになっているか（サービスを終了した場合、データの取り出し等が可能か）


データの移行

（必要な場合）データ移行ツールは用意されているか


データのダウンロード

（必要な場合）データのダウンロードは可能か


SaaS/ASPベンダ（続き）

記述項目

解説

評価

セキュリティ

セキュリティ

セキュリティ内容は開示されており十分なレベルか

（暗号強度、サーバの防犯設備、入退室管理、災害対応、ポート監視等）


アプリケーションのセキュリティ

アプリケーションのセキュリティは十分か。（使用DBの種類およびそのバージョン、セキュリティパッチの適用ポリシー等）


アカウント設定

利用者ごとにIDが付与できるか


アクセス権設定

利用者ごとにアクセス権限を設定できるか


ログ管理

ログの保管期間、種類は十分か


バックアップ

バックアップ

バックアップのポリシーと方法は十分か

（世代、復旧方法、保持期間、解約後の対応等）


データ多重化

サービス中のデータは多重化して管理されているか


複数サイトによるバックアップ

災害対策などのため、複数拠点でデータを管理しているか


ローカルバックアップ

ユーザ企業側にローカルバックアップは可能か


サポート

コスト

別途費用がかかるか


サポート時間

サポート時間はユーザの業務時間と合致しているか


サポート方法

サポートの方法は十分か（電話か、メールか等）


その他

応答時間（特にメールの場合、2営業日以内に返答されるか等）は十分か。日本語サポートが受けられるか


SaaS/ASPプラットフォームベンダ

記述項目

解説

評価

利用の継続性

（経営安定性）

SaaS/ASPベンダの経営は安定しているか


サービス提供時間帯

サービスの提供時間は十分か


定期メンテナンス

定期メンテナンス等による停止時間、停止時期、告知方法等は明確か

停止による業務への影響は軽微か


災害・障害時対応

災害、障害時の対応方法（告知方法、説明方法等）は明確か

システム復旧体制は十分か

停止時間に対する課金方針は妥当か


実績

サービス履歴

当該製品の初期バージョンとバージョンアップの出荷時期の履歴（海外サービスの場合は国内外を分けて提示）


ユーザ累計

初版から累計と提供バージョンの双方の出荷累計（海外サービスの場合は国内外を分けて提示）


導入企業

当該SaaS/ASPを導入している企業の実績を提示


導入規模

利用人数や端末数などの導入規模を提示（導入企業規模ではなく、導入の規模を提示）


パフォーマンス

パフォーマンス

推奨環境下で使用した場合のパフォーマンスは十分か（応答速度、同時接続数、転送量等）

保証はあるか


稼働率

稼働時間が開示されるもしくは稼動目標を示しているか


セキュリティ

バックアップ

セキュリティ

セキュリティ内容は開示されており十分なレベルか（暗号強度、サーバの防犯設備、入退室管理、災害対応、ポート監視等）


バックアップ

バックアップのポリシーと方法は十分か（世代、復旧方法、保持期間、解約後の対応等）


データ多重化

サービス中のデータは多重化して管理されているか


複数サイトによるバックアップ

災害対策などのため、複数拠点でデータを管理しているか


ローカルバックアップ

ユーザ企業側にローカルバックアップは可能か


サポート

コスト

別途費用がかかるか


サポート時間

サポート時間はユーザの業務時間と合致しているか


サポート方法

サポートの方法は十分か（電話か、メールか等）


その他

応答時間（特にメールの場合、2営業日以内に返答されるか等）は十分か

日本語サポートが受けられるか


他ユーザからのSaaS/ASPに対する評価

記述項目

解説

評価

満足度

使い勝手、投資効果について悪い評価はないか


サポート評価

サポートについて悪い評価はないか


発注者

記述項目

解説

評価

該当SaaS/ASPの使用経験

そのSaaS/ASPや関連製品に関する経験を持っているか


該当SaaS/ASP使用経験者の確保

今回のプロジェクトに専門家を配置できるのか


今回の導入に関する評価

記述項目

解説

評価

導入目的意識

導入に当たっての目的意識は明確になっているか


業務適合性

SaaS/ASPの業務に、現状の業務を合わせることができるか



SaaS/ASPをそのまま使うのではなくパラメータの設定が必要か



SaaS/ASPに追加開発を実現するアドオン機能があるのか



SaaS/ASP本体の機能を改造するカスタマイズの必要があるのか


既存システムとの整合

データ連携があるか



インタフェース連携があるか



現行システムとの不整合が発生する可能性は確認したか



データ連携があるか


規模適合性

実績のある規模か



規模の柔軟性はあるか


7.検収事前チェックリスト

検収を確実に行うために、事前に検収準備状況について確認しておく必要がある。以下の項目の確認を行う。

チェック項目

結果

検収計画は、プロジェクト責任者の承認を得ていますか？


システム関連資料は既に運用スタッフに渡されていますか？


品質（バグ、ユーザビリティ、開発基準適合）に関するテストは終了していますか？


セキュリティ項目に関するテストは終了していますか？


検収にあたっての評価基準は決まっていますか？（ミッションを達成していればよい等）


事業継続計画は考えられていますか？


サポートスタッフは既に決まっていますか？


サポートと業務の関係は整理されていますか？（業務時間とサポート時間の関係等）


検収計画が要求仕様を元にしているか確認していますか？


検収計画は、構成管理されていますか？


運用書類や検収書類は、検収チームに配布されていますか？


検収チームは、検収に関する知識や経験はありますか？


ベンダ側総合テストは終わっていますか


8.検収チェックリスト

ベンダが開発したシステムを受け入れるかどうかのチェックポイントである。以下の項目をチェックする必要がある。

チェック項目

結果

ユーザ教育は終わっていますか？


既存システムがある場合、データ移行は終わっていますか？


支所等、各導入場所の準備はできていますか？


システム導入に関して、関係者全体の同意はできていますか？


ハードウェアの納品と基本動作の確認はできていますか？


初期データの導入は終わっていますか？


必要なソフトウェアのインストールは全て終わっていますか？


問題点や是正処置は書面で管理されていますか？


テスト後に修正したソフトウェアなどは再テストされていますか？


総合運転テストの結果はファイルされていますか？


教育資料は承認され、構成管理されていますか？


テスト環境は全体の試験をする上で十分なものでしたか？


検収テストで行う項目は、関係者の間で調整されていましたか？


検収計画に従って試験は行われましたか？


全てのテストは正確に実行されましたか？


問題のあった部分は記録され、修正の上、再テストしましたか？


検収報告書はできていますか？


検収テストの結果はファイリングされていますか？


運用準備のレビューが行われましたか？


もしもシステムの拡張や変更が必要であったならば、運用に対する必要な対策は打たれていますか？


検収後に全てのドキュメントがアップデートされていますか？


完成した運用関連ドキュメントが各部門に配布されていますか？


正式な検収完了ドキュメントを書面で作成していますか？


負荷試験は終わっていますか？


教育や資格や認定が必要な場合の処置はできていますか？


保守計画はできていますか？


移行期間と役割が明確にされていますか？


アクセスルールは適用されていますか？


将来の拡張計画が、サポート要員に伝えられていますか？


最終プログラムがライブラリ化し、テストプログラムなどが消されていますか？


プロジェクト関連資料が、メンテナンス可能な形で運用要員に渡されていますか？


運用コストや性能予測など各種データはプロジェクト計画に反映されていますか？


今後に向けてプロジェクト計画がウォークスルーされていますか？



9.セキュリティチェックシート　一般版（上位概念）

■技術的セキュリティ対策

技術的
セキュリティ対策

脅威の内容

参考情報（上位レベルは下位レベルの内容を含む）

役割

本件業務での対応

レベル1

レベル2

レベル3

レベル4

ユーザ

ベンダ

対応レベル

仕様又は
候補製品等

■認証
情報を参照している人が本人なのかを証明をする。

情報を参照している人が、本人なのかを管理していないと、他人に重要な情報を見られる可能性がある。

■何も決められていない
情報を誰が参照しているか特定できない状態。

■個人を認識できる
パスワードを利用して、個人を認識できるようにする。

■本人認証の強化
特定のカードやログインの二重化などで、本人認証を強化する。

■絶対的な本人認証
生体認証等を組み合わせ、定期的なポリシー変更を実施する。



　

　

■アクセス権
個人情報、企業情報によって、アクセスできる人を制限・管理する。

誰でも情報アクセスできるようになっていると、削除、改ざん、複製、持ち出しされたりする。

■何も決められていない
情報に誰でもアクセスできてしまう。

■コンピュータ単位で設定できる
サーバ単位、フォルダ単位で、個人・グループが情報単位にアクセスできように設定する。

■認証情報に基づき資源単位でアクセス権が設定できる
ファイル単位で、個人・グループが情報単位にアクセスできるように設定する。

■資源単位でアクセスした内容の収集、分析ができる
アクセスされた情報（ログ）を収集・分析できる。



　

　

■暗号化
情報を暗号化して、紛失・盗難・盗聴の対策を施す。

情報機器（コンピュータやUSBメモリなど）が盗難又は紛失することにより、情報が漏えいするおそれがある。

■何も対策されていない
社外に持ち出すデータ、社内のコンピュータのデータに暗号化が実施されていない。

■モバイルコンピュータやUSBメモリ単位で暗号化で持ち出す
社外に持ち出すコンピュータ、USBメモリなどの中に入っているデータを暗号して持ちだす。

■全てのコンピュータについて、データを暗号化する
社内のコンピュータ、社外に持ち出すコンピュータ、業務で使用するUSBメモリ、外付けHDD、CD/DVDなど情報を書き込めるものに対して暗号化をする。

■暗号化されたものを復号する都度、認証をおこなう
暗号化されたデータを復号するたびに、認証を行い履歴を取得する。



　

　

■ウイルス等の悪意あるプログラムの取り扱い及び検出する機能の導入
悪意あるプログラムから情報資産を守る。

コンピュータに誤動作を起こさせる悪意のあるプログラムにより、システムが利用できなくなる、データが消去される、情報が外部に漏えいしてしまう、などのおそれがある。

■何も決められていない
ウイルス対策を実施していない。

■ウイルス等を検出し侵入を停止・警告できる
コンピュータ上で悪意のあるプログラムを検出して削除し、警告できる。

■全システムに対するウイルス対策と集中管理
ネットワーク機器やコンピュータなど複数の対象に対して、悪意のあるプログラムを検出、削除するための機能を導入し、被害状況の収集や定義ファイルの更新を集中的に管理できる。

■不審な通信やコンピュータをシステムから隔離できる
悪意のあるプログラムが検出されたコンピュータをネットワークから遮断する。



　

　

■ネットワークの運用
ネットワークを流れるデータ量の管理をする。

ネットワーク障害や大量のデータ転送により、ネットワークが正常に利用できなくなるおそれがある。

■何も決められていない
ネットワーク管理ツールもしくはサービスを導入していない。

■管理ツールを導入する
障害検知やネットワーク負荷を検知するツール、サービスを導入する。

■冗長化する、使用状況を監視して記録できるようになる
ネットワーク機器を冗長化して大量データに備えたり、ネットワーク障害時にネットワークが利用できなくなるのを回避したりする。

■トラフィックに応じた柔軟な制御ができる
ネットワークの使用状況に応じて、機器の設定を容易に変更できる。



　

　

■保守
ＯＳやアプリケーション、ハードの保守を行なう。

ハードウェア保守がされていないと、不具合の発生や、故障が発生するおそれがある。

■何も決められていない
メンテナンス作業をやっていない。

■障害発生時に対応する
障害が発生した時点で、保守作業を実施する。

■定期保守を実施する
定期的に機器の点検、整備を行い、耐用期間を過ぎた部品は交換する。

■予防的に対応する
定期的に機器の点検、整備を行い、耐用期間を過ぎる前に部品を交換する。





OS、ミドルウェアの保守がされていないと、不具合の発生や、セキュリティホールによって情報が漏洩するおそれがある。

■何も決められていない
メンテナンス作業をやっていない。

■障害発生時に対応する
障害が発生した時点で、不具合修正版の適用を実施する。

■定期保守を実施する
定期的に不具合修正版を取得し、予備機でテストをおこない、適用する。

■予防的に対応する
計画的に不具合修正版を取得し、不具合の発生を検討の上、予備機でテストを行い適用する。





アプリケーション保守がされていないと、不具合や期待する正しい結果が得られないおそれがある。

■何も決められていない
メンテナンス作業をやっていない。

■障害発生時に対応する
障害が発生した時点で、修正版の適用を実施する。

■定期保守を実施する定期的に修正版を取得し、予備機でテストをおこない、適用する。

■予防的に対応する
計画的に修正版を取得し、不具合や運用変更などの発生を検討の上、予備機でテストを行い適用する。



　

　

■機器運用監視
サーバ、ネットワーク機器の稼働監視を行う。

システムの状況を把握できないことにより、障害の対応が遅れて情報システムへのアクセスが長時間停止するおそれがある。

■何も決められていない
サーバ、ネットワーク機器の稼働状況を監視していない。

■運用状況を遠隔で、手動で把握できる
遠隔で稼働状況を手動で確認する。

■運用状況を自動で把握、記録ができる
稼働状況を常時把握し、異常があれば通知する。

■運用状況に異常があれば、自動的に設定された状態に切替わる
異常を通知するとともに、代替手段に自動的に切替わる。



　

　

■障害発生時の対応
障害時の対応マニュアルの整備をする。

システム障害時の対応手順が決められていないと、適切に対応できず、復旧が遅延するおそれがある。

■何も決められていない
システム障害時の対応を決めていない。

■障害発生時は代替機を手配する
代替機を手配し、到着後交換する。データはバックアップを利用する。

■障害発生時は予備システムに手動で切り替える
障害が発生した場合は、予備機に手動で切替える。データはバックアップを利用する。

■障害発生時は予備システムに自動的に切り替わる
障害を通知するとともに、自動的に切替る。データは自動的に保持される。



　

　

■データの保護
データが改ざんされないように防御する。

データが保護されていないと、データが改ざんされたり、漏えいしたりするなどの恐れがある。

■何も決められていない
データの改ざんや、漏えいの対策を施さない。

■特定のデータ、情報が保護されている
データ・情報をパスワードや暗号で保護する。

■すべてのデータ、情報が保護されている
すべてのデータを暗号化やアクセス権で保護する。

■第三者が利用できないようになっている
データに対して、アクセス権と暗号の両方で保護している。



　

　

■ログ管理
情報の持ち出し履歴をとって監査の証跡資料として管理する。

情報システムの適切な監査ログが管理されていないと不正な出来事に気づく事ができない恐れがある。

■何も決められていない
ログを取得していない。

■ログの取得のみ
ログを保存する。

■ログを取得し、定期的なレポートを行う
ログを保存し、内容を分析し報告する。

■取得ログのレポートに加え、常時監視を行う
自動的にログを分析し、異常があれば通知する。



　

　


■物理的セキュリティ対策

物理的
セキュリティ対策

脅威の内容

参考情報（上位レベルは下位レベルの内容を含む）

役割

本件業務での対応

レベル1

レベル2

レベル3

レベル4

ユーザ

ベンダ

対応レベル

仕様又は
候補製品等

■作業領域（場所）
マシンルームやコンピュータを置いておく環境を管理する。

部外者が、簡単に会社や部屋に入れてしまうと、情報を盗まれる恐れがある。

■何も決められていない
施錠管理、入退室管理されていない。

■隔離する
マシンルームは施錠する。第三者のオフィスへの入退出を制限する。

■立ち入りを制限する
常時、暗証番号、ICカード、生体認証等により、部屋の入退室を制限する。

■立ち入りを監視して記録する
防犯カメラを設置し、部屋の入退室を記録する。



　

　

■データの保管
データのバックアップを行なう。

システムの緊急停止や不慮の災害の発生時に、システムを業務可能な状態に復旧できなくなる。

■何も決められていない
データをバックアップしていない。

■複製を保管するための機能を持つ
日次で複製する。障害発生時には、前日までのデータが復旧できる。

■複製を世代管理する
一定期間、遡って復旧できるように複製する。

■離れた拠点で複製が保管されている
世代管理された複製が遠隔地で保管され、被災してもデータを復旧できる。



　

　

■作業環境管理（空調等）
適切な温度、湿度を保つ。

高温、多湿になると、コンピュータが正確に作動しなくなるおそれがある。

■何も決められていない
空調設備がない、又は、管理していない。

■手動で適切な環境を維持する
人が判断して、空調を調節する。

■自動で適切な環境を維持する
自動的に適切な温度、湿度に調節される。

■停電でも適切な環境が維持される
非常用発電装置で作業環境が適切に維持される。



　

　

■停電時の機器運用
停電時の稼動性を確保する。

停電などにより、コンピュータが稼動せずに業務が中断される、データを喪失するおそれがある。

■何も決められていない
停電時には利用できない。データが失われることがある。

■停電発生時に安全に停止できる
無停電電源装置により、停電を検知し、自動的に機器を停止する。

■障害発生時にも一定時間稼動できる設備がある
無停電電源装置により、一定時間稼働し、データを保護の上、機器を停止する。

■システムを常に稼動し続けられる設備が整っている
非常用発電装置により、停電中もシステムを安定稼働する。



　

　

■資産の管理
資産台帳を作成し、資産を管理する。

資産（情報機器・電子媒体・紙）の資産管理がされていないと紛失・盗難の検知ができない。

■何も決められていない
資産管理されていない。

■紙面上で管理している
人が資産を確認し、管理台帳を作成して管理する。

■ツール等によりコンピュータ上で管理している
資産管理ソフトを使い、機器情報を取得し資産台帳を作成、管理する。

■定期的に見直しがかけられている
資産管理ソフトを使い、定期的に実査監査をおこなう。



　

　


■管理的セキュリティ対策

管理的
セキュリティ対策

脅威の内容

参考情報（上位レベルは下位レベルの内容を含む）

役割

本件業務での対応

レベル1

レベル2

レベル3

レベル4

ユーザ

ベンダ

対応レベル

仕様又は
候補製品等

■資産分類
資産を重要度に応じて分類し、取扱いを定め管理する。

情報資産が取扱い基準（極秘・社外秘など）によって分類されていないと、権限のない者から情報が漏えいする可能性がある。

■何も決められていない
分類基準がない。

■分類基準がある
情報資産の分類基準によって分類し、取扱いが定められている。

■分類基準ごとに管理されている
情報資産の所在が管理されている。

■分類基準ごとにアクセスできる人が決まっていて、履歴がとられている
情報を参照した際は、記録が残る。



　

　

■システム受入れ管理
コンピュータシステムの受入れ基準を定め管理する。

受け入れたシステムの不備に気づかず稼動したり、ネットワークに接続すると、不具合が発生する可能性がある。

■何も決められていない
受入れ方法がない。

■ベンダのテスト基準に従う
ベンダが作成したデータとテスト方法でテストする。

■自社のデータを使用しテストを行う
自社の実際に使用するデータと、ベンダが作成したテスト方法でテストする。

■自社で受入れ検査基準を定め、システムを網羅するテストを行う
自社でテストデータ、テスト方法を定め、テストする。



　

　

■運用体制
社員または社員以外の組織に運用させる場合の管理方法を定める。

情報システムの運営を部外者に行わせる場合、管理基準がないと、情報が漏えいする。

■何も決められていない
管理基準がない。

■運用契約、SLAを締結する、運用操作や機器、情報の操作履歴を記録する操作や情報持ち出しを記録する。

■運用契約、SLAを締結する、SLMを実施する、操作ログを取得する
誤操作や情報持ち出しを監視する。

■運用契約、SLAを締結する、操作ログを取得して、定期的に外部組織で監査する
規定違反者へは、警告が自動的に送られる。



　

　

■情報漏えい時の対策体制
情報漏えいが発生した場合の手順、組織を定める。

漏えい事故などが発生した場合の管理体制が決まっていないと、対応がおくれ被害が大きくなるおそれがある。

■何も決められていない
情報漏えい時の対策がない。

■体制は決められている
責任者、外部対応窓口など対策実施組織を定める。

■漏えい事故のレベルによって対策体制が決められてる
漏えいした情報の内容に応じて、対策実施組織を定め、想定訓練を行なう。

■漏えい事故のレベルを判断し、全社に指揮命令をする組織体制がある
漏えいした情報の内容に応じて、対策実施組織を定め、想定訓練を行なう。



　

　

10. セキュリティチェックシート Webアプリケーション版

■技術的セキュリティ対策

技術的
セキュリティ対策

脅威の内容

参考情報（上位レベルは下位レベルの内容を含む）

役割

本件業務での対応

レベル1

レベル2

レベル3

レベル4

ユーザ

ベンダ

対応レベル

仕様又は
候補製品等

■認証
情報を参照している人が本人なのかを証明をする。

情報を参照している人が、本人なのかを管理していないと、他人に重要な情報を見られる可能性がある。

■何も決められていない
情報を誰が参照しているか特定できない状態。

■個人を認識できる
パスワードを利用して、個人を認識できるようにする。

■本人認証の強化
特定のカードやログインの二重化などで、本人認証を強化する。

■絶対的な本人認証
生体認証等を組み合わせ、定期的なポリシー変更を実施する。



　

　

■アクセス権
情報よって、アクセスできる人を制限・管理する。

誰でも情報アクセスできるようになっていると、削除、改ざん、複製、持ち出しされたりする。

■何も決められていない
情報に誰でもアクセスできてしまう。

■利用者と管理者のアクセス権限の設定
利用者がアクセスできる情報と、管理者だけがアクセスできる情報を区別し、管理する。ログを取得する。

■グループ単位のアクセス権限の設定
利用者が所属するグループごとにアクセスできる情報を区別し、管理する。ログを取得する。

■アクセス権の集中管理機能を有する
利用者・グループ毎のアクセス権限を管理する機能を使って、最新のアクセス権を維持することができる。ログを収集し、問題発生時に参照できる



　

　

■暗号化
情報を暗号化して、紛失・盗聴・改ざんの対策をする。

通信経路やパスワードが暗号化されていない場合は、紛失・盗聴・改ざんや成りすましの可能性がある。

■何も決められていない
通信経路やシステムで保存するパスワードが暗号化されていない。

■パスワードの暗号化を実装する
パスワードを暗号化し、容易に第三者にパスワードが漏えいしないようにする。

■個人、決済等に関わる情報の暗号化を実装する
個人情報、決済情報をすべて暗号化し、漏えい、改ざん、紛失しても悪用されないようにする。

■全ての情報について高度な暗号化を実装する
あらゆる情報を暗号化し、第三者に悪用されないようにする。



　

　

■ページ間のデータ授受
Webのページをまたがってデータのやり取りをする際の対策をする。

ページ間のデータ授受が正しくなされない場合は、情報が漏えいしたり、成りすましされたりする可能性がある。

■何も決められていない
ページ間のデータ授受について、何もルール化されていない。

■データの取り扱いがルール化されている
データの有効期限や取り扱い方法が部分的にルール化されている。

■データの取り扱いルールの強化
データの有効期限や取り扱い方法が規定されている。

■ページ間でやり取りするデータの種類を規制する
個人を特定できる情報、決済に関わる情報をページ間でやり取りをしないなどを規定する。



　

　

■悪意のあるコードの侵入阻止
悪意のあるコードがWebサーバに埋め込まれるのを阻止する。

悪意のあるコードがWebサーバ上で実行されると、フィッシング詐欺やユーザの成りすまし、パスワード漏えい等の可能性がある。

■何も決められていない
悪意のあるコードに対して、なにも対策がない。

■悪意のあるコードの対策
悪意のあるコードを排除する仕組みがある。必要最少限のアクセス権限設定をする。不要なファイルを公開しない。

■悪意のあるコードの対策の強化
悪意のあるコードを排除する仕組みがあり、対策方法、管理権限がシステム全体で規定されている。

■Webアプリケーション以外の対策の併用
Webアプリケーション内の悪意のあるコード対策に併せて、WAF（Web Application Firewall）等を使用した対策を実施する。



　

　

■システム連携
他のシステムや他のアプリケーションとの連携を行う際に連携の仕組みを悪用されるのを阻止する。

連携の仕組みを悪用されると、フィッシング詐欺やユーザの成りすまし、パスワード漏えい等の可能性がある。

■何も決められていない
連携の仕組みを悪用されるのを阻止する対策がない。

■システム連携悪用の対策
システム連携悪用を排除する仕組みがある。

■システム連携悪用の対策の強化
システム連携悪用を排除する仕組みがあり、対策方法がシステム全体で規定されている。

■Webアプリケーション以外の対策の併用
Webアプリケーション内のシステム連携悪用の対策に併せて、WAF等を使用した対策を実施する。



　

　

■Webサーバの設定
Webサーバの設定内容について、最適な設定がされているか。

Webサーバの設定が正しく設定されていない場合、攻撃のために必要とするシステム情報が漏えいする。

■何も決められていない
セキュリティ基準が決められていない。

■セキュアな設定
Webサーバの設定が外部からの攻撃などを防ぐセキュリティを意識した設定になっている。

■セキュアな設定の強化
Webサーバの設定がセキュリティを意識した設定になっており、設定内容が規定されている。

■侵入検知
Webサーバの設定に対する侵入・攻撃の際に、検知し、管理者へ通知する



　

　

■内因的な情報漏えい
運用ミスなど内部側の原因で情報が漏えいする。

重要な情報が漏えいしたり、攻撃のために必要とする情報が漏えいする。

■何も決められていない
Webサーバの運用について規定が何も設けられていない。

■Webサーバの運用規約
Webサーバの運用について一部の規定だけが設定する。（アクセス、メンテナンス等）

■Webサーバの運用規約を強化
網羅的にWebサーバの運用（アクセス、メンテナンス、ログイン等）について規定が設定されている。

■情報表示の制限
個人情報等の重要情報は、一覧表示を禁止する、一括してCSVファイル出力を禁止する、などを規定する。



　

　

■アプリケーションへの攻撃対策
機能の悪用、負荷攻撃、多重登録等のアプリケーションに対する攻撃対策。

アプリケーションに対する攻撃により、サービスの停止や情報漏えい、改ざん、踏み台化などの可能性がある。

■何も決められていない
攻撃の対策は特に用意されていない。

■暫定的な攻撃の対策
アプリケーションへの攻撃に対する暫定的な対策が施されている。

■根本的な攻撃の対策
アプリケーションへの攻撃に対する根本的な対策が施されている。

■重複した攻撃の対策
根本的対策に加え、異なる方法を使用して、複数の攻撃対策を施す。



　

　

■ネットワーク構成
ネットワークの構成により、攻撃されやすさが変わる。

不適切な構成の場合、サーバの乗っ取りの可能性がある。

■何も決められていない
サーバに乗っ取り対策がなされていない。

■簡易なネットワーク構成
サーバが乗っ取られない為の最低限の対策が講じられている。

■基本的なネットワーク構成
サーバが乗っ取られない為の対策が講じられている。

■セキュアなネットワーク構成
サーバが乗っ取られない為のセキュアな対策が講じられている。



　

　

■電子商取引
電子商取引におけるセキュリティ対策の実施。

取引に関係する情報が漏えい、改ざんされる可能性がある。

■何も決められていない
電子商取引におけるセキュリティ対策はなにもしない。

■取引データに対する最低限の保全性
取引関連情報に誤りが無いことを保証する為の、最低限の保全機能を実装する。

■取引データの保全性
取引関連情報に誤りが無いことを保証する為の、保全機能を実装する。

■取引データの保全性の強化
複数の手段を講じて保全性の強化を図る。



　

　

■ログ管理
情報の持ち出し履歴を取得し監査の証跡資料として管理する。

情報システムの監査ログが適切に管理されていないと不正な出来事に気づく事ができない恐れがある。

■何も決められていない
ログを取得していない。

■ログの取得のみ
ログを保存する。

■ログを取得し、定期的なレポートを行う
ログを保存し、内容を分析し報告する。

■取得ログのレポートに加え、常時監視を行う
自動的にログを分析し、異常があれば通知する。



　

　

■Webアプリケーション開発
導入したパッケージをカスタマイズする業者を選定する基準。

セキュリティに対する対策を考慮しない業者に開発を委託すると、多くのセキュリティホールを作り込まれてしまう可能性がある。

■何も決められていない
セキュリティ対策基準なしに開発を行う。

■セキュリティテストの実施
セキュリティに関するテストを実施する。

■開発ルールの規定
開発標準、セッション管理など決められた規定に従って開発を行う。

■セキュリティ対策機能の使用と専門部門の品質管理
実績あるセキュリティ対策機能を使用し開発する。専任者が品質管理を行う。



　

　

911.SaaS向けSLAにおけるサービスレベル項目のモデルケース http://warp.da.ndl.go.jp/info:ndljp/pid/281883/www.meti.go.jp/press/20080121004/20080121004.html参照。

    • 本モデルケースでは、基幹系業務の場合と販売管理やグループウェアなどそれ以外の業務の場合に分けて、サービスレベル設定例を示している。

    • 実際の設定値は、以下の設定例を参考として、業務内容など個々の状況に応じて決定されるべきものである点に留意されたい。

◆アプリケーション運用

種別

サービスレベル項目例

規定内容

測定単位

設定例

備考

可用性

サービス時間

サービスを提供する時間帯（設備やネットワーク等の点検／保守のための計画停止時間の記述を含む）

時間帯

24時間365日

（計画停止／定期保守を除く）

計画停止時間は提供者が個々に設定。

計画停止予定通知

定期的な保守停止に関する事前連絡確認（事前通知のタイミング／方法の記述を含む）

有無

30日前にメール／ホームページで通知


サービス稼働率

サービスを利用できる確率（（計画サービス時間－停止時間）÷計画サービス時間）

稼働率
（%）

99.9%以上（基幹業務）

99%以上（上記以外）

対象業務の重大性を考慮しつつサービス内容／特性／品質に応じて個々に検討。

ディザスタリカバリ

災害発生時のシステム復旧／サポート体制

有無

遠隔地のバックアップ用データセンタで保管している日次バックアップデータと予備システムへの切り替え

データセンタ構成、復旧までのプロセス／時間、費用負担についても明示されていることが望ましい。また、適用する業務の重要性に応じた「ディザスタリカバリ」のレベルにより設定内容は変わる。

重大障害時の代替手段

早期復旧が不可能な場合の代替措置

有無

バックアップデータの取得が可能なホームページを用意


代替措置で提供する
データ形式

代替措置で提供されるデータ形式の定義を記述

有無（ファイル形式）

CSVあるいはExcelファイルで提供


アップグレード方針

バージョンアップ／変更管理／パッチ管理の方針

有無

年2回の定期バージョンアップを実施

頻度、事前通知方法、履歴管理／公開、利用者の負担についても明示されていることが望ましい。

信頼性

平均復旧時間

障害発生から修理完了までの平均時間（修理時間の和÷故障回数）

時間

1時間以内（基幹業務）

12時間以内（上記以外）

対象業務の重大性を考慮しつつサービス内容／特性／品質に応じて個々に検討。

システム監視基準

システム監視基準（監視内容／監視・通知基準）の設定に基づく監視

有無

1日4回のハードウェア／ネットワーク／パフォーマンス監視

詳細な監視項目は提供者が個々に設定。

障害通知プロセス

障害発生時の連絡プロセス（通知先／方法／経路）

有無

指定された緊急連絡先にメール／電話で連絡し、併せてホームページで通知

初期対応後の経過報告の方法・タイミングについても明示されていることが望ましい。

障害通知時間

異常検出後に指定された連絡先に通知するまでの時間

時間

15分以内（基幹業務）

2時間以内（上記以外）

営業時間内／外で異なる設定を行う場合がある。

障害監視間隔

障害インシデントを収集／集計する時間間隔

時間

（分）

1分以内（基幹業務）

15分（上記以外）

営業時間内／外で異なる設定を行う場合がある。

サービス提供状況の報告方法／間隔

サービス提供状況を報告する方法／時間間隔

時間

月に一度ホームページ上で公開

報告内容／タイミング／方法は提供者が個々に設定。

ログの取得

利用者に提供可能なログの種類（アクセスログ、操作ログ、エラーログ等）

有無

セキュリティ（不正アクセス）ログ／バックアップ取得結果ログを利用者の要望に応じて提供

提供内容／方法は提供者が個々に設定。

性能

オンライン応答時間

オンライン処理の応答時間

時間
（秒）

データセンタ内の平均応答時間3秒以内

対象業務の重大性を考慮しつつサービス内容／特性／品質に応じて個々に検討。

バッチ処理時間

バッチ処理（一括処理）の応答時間

時間
（分）

4時間以下

対象業務の重大性を考慮しつつサービス内容／特性／品質に応じて個々に検討。

拡張性

カスタマイズ性

カスタマイズ（変更）が可能な事項／範囲／仕様等の条件とカスタマイズに必要な情報

有無

利用画面上の項目配置変更や新規項目の追加が設定画面より可能

サービス仕様（機能仕様）として契約書／利用マニュアルに記載されている場合は必ずしもSLAで定義される必要はない。

外部接続性

既存システムや他のSaaS等の外部のシステムとの接続仕様（API、開発言語等）

有無

API（プログラム機能を外部から利用するための手続）を公開

APIがインターネットの標準技術で構成され、仕様が公開されており、APIの利用期限や将来の変更可能性が明記されていることが望ましい。

同時接続利用者数

オンラインの利用者が同時に接続してサービスを利用可能なユーザ数

有無

（制約条件）

50ユーザ（保証型）

同時接続の条件（保証型かベストエフォート（最善努力）型か）、最大接続時の性能について明示されていることが望ましい。

◆サポート

サービスレベル項目例

規定内容

測定単位

設定例

備考

サービス提供時間帯
（障害対応）

障害対応時の問合せ受付業務を実施する時間帯

時間帯

24時間365日（電話）

受付方法（電話／メール）や営業時間外の対応は対象業務の重大性およびサービス内容／特性／品質に応じて状況が異なる。

サービス提供時間帯
（一般問合せ）

一般問合せ時の問合せ受付業務を実施する時間帯

時間帯

営業時間内（電話）

（年末年始・土日・祝祭日を除く）

24時間365日（メール）

受付方法（電話／メール）や営業時間外の対応は対象業務の重大性およびサービス内容／特性／品質に応じて状況が異なる。

◆データ管理

サービスレベル項目例

規定内容

測定単位

設定例

備考

バックアップの方法

バックアップ内容（回数、復旧方法など）、データ保管場所／形式、利用者のデータへのアクセス権など、利用者に所有権のあるデータの取扱方法

有無／

内容

有 （日次でフルバックアップ。遠隔地のデータセンタにテープ形式保管。アクセス権はシステム管理者のみに制限。復旧／利用者への公開の方法は別途規定）

保証要件を設定している場合は、具体的に明示。バックアップ内容は対象業務の重大性およびサービス内容／特性／品質に応じて状況が異なる。

また、SaaSベンダの民事再生、破産等によりサービス継続が出来ない場合についても明示されていることが望ましい。

サービスレベル項目例

規定内容

測定単位

設定例

備考

バックアップデータの保存期間

データをバックアップした媒体を保管する期限

時間

5年以上（基幹業務）

3ヶ月以上（上記以外）

対象業務の重大性を考慮しつつサービス内容／特性／品質に応じて個々に検討。

データ消去の要件

サービス解約後の、データ消去の実施有無／タイミング、保管媒体の破棄の実施有無／タイミング、およびデータ移行など、利用者に所有権のあるデータの消去方法

有無

サービス解約後1ヶ月以内にデータおよび保管媒体を破棄。

解約時には、CSVなどの一般的なフォーマットでデータ出力ができることが望ましい。

◆セキュリティ

サービスレベル項目例

規定内容

測定単位

設定例

備考

公的認証取得の要件

JIPDECやJQA等で認定している情報処理管理に関する公的認証（ISMS、プライバシーマーク等）が取得されていること。

有無

ISMS認証取得

プライバシーマーク取得

ITサービスマネジメントのベストプラクティスであるITILやJIS Q20000等の取得状況も確認することが望ましい。

アプリケーションに関する第三者評価

不正な侵入、操作、データ取得等への対策について、第三者の客観的な評価を得ていること。

有無／実施状況

有（年1回、外部機関によりサービスの脆弱性に関する評価を受け、速やかに指摘事項に対して対策を講じる。）

セキュリティ監査、システム監査、ペネトレーションテスト等ネットワークからの攻撃に対する検証試験、ウェブアプリケーションの脆弱性検査、データベースセキュリティ監査などを想定。

情報取扱者の制限

利用者のデータにアクセスできる利用者が限定されていること。

有無／設定状況

有（利用者のデータにアクセスできる社員等はセキュリティ管理者の許可を得た者に限る。）


情報取扱い環境

提供者側でのデータ取扱環境が適切に確保されていること。

有無

有 （オフィスはICカードによる運用で執務室に入室可能な社員等を最小限に制限しており、PCはすべてシンクライアントである）


通信の暗号化レベル

システムとやりとりされる通信の暗号化強度。

有無

SSL、あるいはVPN

SSLの場合は、SSL3.0/TLS1.0（暗号強度128ビット）以上に限定。



2 http://www.meti.go.jp/policy/it_policy/softseibi/index.html#2

3 「共通フレーム2007～経営者、業務部門が参画するシステム開発および取引のために～」 独立行政法人 情報処理推進機構編、オーム社刊。ソフトウェア開発とその取引の適正化に向けて、ソフトウェアライフサイクルプロセス規格（ISO/IEC 12207）を基盤に、システム企画、要件定義、開発、運用、保守の作業項目を定義し、標準化したもの。その後、共通フレーム2013 として改訂された。

4 ユーザの要求を満足するために、ソフトウェアが実現しなければならない機能に係る要件。システム機能及びデータにより定義される。〈例〉システム機能：業務フロー、業務処理定義、システム機能（階層、体系等）等。データ：データ構造（階層、関係等）、データ項目定義等。

5 機能要件以外のすべての要素に係る要件。業務内容及びソフトウェアの機能と直接的な関連性を有さない品質要件、技術要件、移行要件、運用要件、操作性及び付帯作業等からなり、それぞれに対する目標値及び具体的事項により定義される。（例）品質要件：効率性（平均レスポンスタイム、ピーク時性能等）、信頼性（平均故障間隔、平均復旧時間等）、保守性（解析、変更等）、操作性（処理時間、処理容易性、操作理解性など）、セキュリティ要件等。技術要件：実現方式（処理方式、通信プロトコル等）、システム構成（ネットワーク構成、ソフトウェア構成、ハードウェア構成等）、開発方式（開発言語等）等。移行要件：移行対象業務、移行対象データ、移行時期、移行体制等。運用要件：運用体制、運用形態、運用スケジュール、運用管理方式（監視、バックアップ等）、災害対策等。付帯作業：ハードウェア展開、ソフトウェア展開、ユーザ教育等。

6 https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.htm

7 https://www.ipa.go.jp/ikc/reports/20191224.html

8 https://www.ipa.go.jp/ikc/reports/20201222.html

9 http://www.meti.go.jp/policy/it_policy/softseibi/index.html#2

10 https://www.ipa.go.jp/ikc/reports/20200331_1.html

11 https://www.ipa.go.jp/ikc/reports/20201222.html http://www.meti.go.jp/policy/it_policy/keiyaku/index.html

12 第二一版では「対等の交渉力のあるユーザ・ベンダ」、「ウォータフォールモデル」、「重要インフラ・企業基幹システムの受託開発」を想定している。

13 SaaS：サースもしくはサーズ読む。経済産業省SaaS向けガイドラインでは、「インターネット経由でアプリケーション機能を提供するサービスの形態」を指す。最も一般的なSaaS の形態は、SaaS 提供者が提供するウェブアプリケーションを利用者がウェブブラウザを通じて利用する形態である。」と定義されている。ASP：Application Service Provider。アプリケーションソフトをインターネットを介してユーザに提供するサービス形態。またはサービス提供事業者を指す場合もある。

14 モディファイ：パッケージソフトウェアのソースコードの変更を伴うカスタマイズ。
アドオン：パッケージソフトウェアのソースコードの変更を伴わず、API（Application Program Interface）、外部I/F、ファイル交換等を利用した外部プログラム。単独で動作するものと、パッケージソフトウェア本体とともに動作するものがある。

15 パッケージソフトウェアの取引モデルについては、15ページを参照。

16　経済産業省「SaaS向けSLAガイドライン」公表についてhttp://warp.da.ndl.go.jp/info:ndljp/pid/281883/www.meti.go.jp/press/20080121004/20080121004.htmlを参照のこと。

17 RFP：Request for Proposal、「提案依頼書」、「提案要望書」、「見積依頼書」などと言う。情報システム調達の際に、ベンダに詳細なシステム提案を行うよう要求すること、またはその調達要件をまとめた仕様書等をいう。モデル取引・契約書第二一版、25p「２．モデル契約プロセス(1)モデル契約プロセス（RFPの概要と記載項目）」参照。

18 ただし、法務の専門家が関与しないでよいということではない。むしろ、法務の専門スタッフを内部に抱える大企業よりも、そのような人材がいない企業の方が外部の弁護士の支援を受けるべき必要性は高い。モデル取引・契約書第二一版のような詳細な契約書に基づく取引の場合と比較すれば、本報告書のモデル契約書・重要事項説明書は簡潔かつ平易な内容となっているので、弁護士との間の検討の効率化も期待される。

19 FOSS：Free and Open Source Softwareの略称。「オープンソース」「オープンソースソフトウェア」「フリーソフトウェア」などととも言う。

20 これによってすべての取引がJIS、ISOに対応するものではない。「共通フレーム2013」31 ページを参照。

21 JIS Q 27001：情報技術―セキュリティ技術―情報セキュリティマネジメントシステム―要求事項、あらゆる形態の組織（例えば，営利企業，政府機関，非営利団体）を対象にする。その組織の事業リスク全般に対する考慮のもとで、文書化したISMS（Information Security Management System）を確立、導入、運用、監視、レビュー、維持及び改善するための要求事項について規定。

22 SLA：Service Level Agreement、サービスレベルに関する合意書、サービス品質契約書。

23 SLM：Service Level Management、サービスレベル管理、サービスレベルの維持向上を目的とした管理活動。

24 モデル取引・契約書第二一版59～60p「３．モデル契約書・逐条解説 (1)ソフトウェア開発委託基本モデル契約書 （再委託）第7条」。A案：再委託先におけるユーザの事前承諾を設ける場合、B案：再委託先の選定について原則としてベンダの裁量（但し、ユーザの中止請求が可能）とする場合。

25 峰滝・元橋、2007。http://www.rieti.go.jp/jp/publications/dp/07j018.pdf

26 RFI：Request For Information、情報提供依頼書。モデル取引・契約書第二一版24p「２．モデル契約プロセス (1)モデル契約プロセス （RFIの概要と記載項目）」参照。

27 外部設計業務以降の、ユーザ・ベンダの作業役割、留意点については、モデル取引・契約書第二一版外部設計諸書作成業務（準委任型）サンプル（118ページ「３．モデル契約書・逐条解説 (2)ソフトウェア開発委託基本モデル契約書ドキュメントモデル【参考文書 2】」）を十分参照されたい。

28 操作で割り当てられていないキーボードを無効にしておく、画面遷移の定義が無い場合は直前の画面にのみ戻る等の措置。

29 ファイルの命名法、コーディングにおける変数の制限・使用法、コメントの規約など、開発上の作法をまとめたもの。

30 共通フレームは工程や時間に依存して定義されたものではない。共通フレームの項番は順序や時間関係を規定していないことに留意する。（共通フレーム2013、27ページ参照）

31 SaaS/ASPにおいては、SLAの詳細な検討、回線の冗長化等の信頼性確保の検討等が含まれることに留意する。

32 SaaS/ASPにおいてはSLAも含む。

33 別紙2パッケージオプション 取引・契約モデルでは、「(22)外部プログラムの範囲の確定、及びそれに伴うユーザI/F・他システムI/F設計」となる。

34 モデル取引・契約書第一版においても、外部設計から内部設計にかけての仕様の「深化」「詳細化」に伴う前提条件の変動が指摘されている。

35 別紙2パッケージオプション 取引・契約モデルでは、「(26)外部プログラムの設計、プログラミング、ソフトウェアテスト」となる。

36 責任者とは、個別契約におけるユーザ及びベンダ双方のプロジェクトの管理遂行責任者をいう。ユーザにおいては、中間資料等の承認、仕様・設計等の確定、検収、変更管理書の交付などの権限と責任を負う。ベンダにおいては、個別業務の遂行、ユーザからの要請・請求に対する対応、変更管理書の交付などの権限と責任を負う。主任担当者とは、各責任者の下に、窓口として円滑な意思疎通を図るため、連絡確認及び必要な調整を行う者をいう。（第二一版第9条63ページ、第10条65ページ「３．モデル契約書・逐条解説 (1)ソフトウェア開発委託基本モデル契約書 （責任者）第9条、（主任担当者）第10条」参照）

37 モデル取引・契約書第二一版59～60p「３．モデル契約書・逐条解説 (1)ソフトウェア開発委託基本モデル契約書 （再委託）第7条」。A案：再委託先におけるユーザの事前承諾を設ける場合、B案：再委託先の選定について原則としてベンダの裁量（但し、ユーザの中止請求が可能）とする場合。

38 個人データの取扱いを委託する場合に契約書への記載が望まれる事項について、「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」（平成28年8月、経済産業省）において、委託者及び受託者の責任の明確化、個人データの安全管理に関する事項、再委託に関する事項、個人データの取扱状況に関する委託者への報告の内容及び頻度、契約内容が遵守されていることの確認、契約内容が遵守されなかった場合の措置、セキュリティ事件・事故が発生した場合の報告・連絡に関する事項が挙げられている。同ガイドラインは、平成28年1月1日に設立された個人情報保護委員会の設立に伴い、平成29年5月30日に廃止されたが、同委員会により平成28年12月に公表された「個人情報の保護に関するガイドライン（通則編）」（以下「個人情報ガイドライン」という。）では契約書への記載が望まれる事項について詳細な列挙はされていない。その意味では、廃止はされたものの、従前のガイドラインの記載が現在においても参考になるものと思われる。

39 委託者が受託者について「必要かつ適切な監督」を行っていない場合で、受託者が再委託した際に、再委託先が適切とはいえない取扱いを行ったことにより、何らかの問題が生じた場合、委託者が受託先に対して再委託の状況についても必要な把握等を行っていない場合は、元の委託者が委託先に対する「必要かつ適切な監督」を行っていないものとして、その責めを負うことがあり得るので、再委託する場合は注意を要する。（「個人情報ガイドライン」参照）

40 以降の説明は潮見佳男『新債権総論Ⅰ』（信山社、2020年）523頁以降も参照。

41 モデル取引・契約書第二一版では上限は規定されていない。

42 現在、政府機関統一基準適用個別マニュアル群の一つとして、内閣サイバーセキュリティセンターより、改訂版が公開されている（DM6-07）： https://www.nisc.go.jp/active/general/kijun_man_index.htm

43 「IT経営力指標」は、「DX 推進指標」にその趣旨・内容等が発展的に引き継がれている。（https://www.meti.go.jp/press/2019/07/20190731003/20190731003.html）

1

Document Metadata

Filed: December 21st, 2020