Comments
Description
Transcript
情報システムの信頼性向上 のための取り組み
METI Ministry of Economy, Trade and Industry 情報システムの信頼性向上 のための取り組み 平成１９年１１月 経済産業省 商務情報政策局 情報処理振興課 産業構造高度化のための取り組み∼情報サービス・ソフトウェア産業維新プロジェクト∼ ユーザ 多重構造の中で、 多重構造の中で、 責任分担、利益分 責任分担、利益分 担構造が不透明。 担構造が不透明。 労働法制上の問題、 労働法制上の問題、 下請法上の課題と 下請法上の課題と して顕在化。 して顕在化。 経営 プライム ＩＴ部門 パートナー企業 不透明で閉鎖的な競争環境 ユーザとベンダの役割 ユーザとベンダの役割 分担・責任関係が不透 分担・責任関係が不透 明。情報システムの信 明。情報システムの信 頼性上も問題。 頼性上も問題。 紛争が起きると長期 紛争が起きると長期 化・泥沼化。 化・泥沼化。 経営層・エンドユー 経営層・エンドユー ザとＩＴ部門が遠い。 ザとＩＴ部門が遠い。 経営の視点からのＩ 経営の視点からのＩ Ｔの利活用が遅れ Ｔの利活用が遅れ ている。 ている。 情報サービス・ソフトウェア を巡る取引構造・産業構造の 不透明性が、ベンダ間、ユー ザ・ベンダ間、ユーザ内に存 在。 不透明な取引構造・産業構 造は、ベンダの産業構造転 換の遅れ、情報システムの 信頼性問題の温存、ユーザ・ ベンダ一体となった生産性向 上の阻害の要因となっている。 情報サービス・ソフトウェア産業維新プロジェクト （Ｈ１８．９∼） 下請法ガイドライン 下請法ガイドライン 取引高度化 取引高度化 信頼性ＧＬ： 信頼性ＧＬ： モデル取引・ モデル取引・ 契約書 契約書 ユーザ 経営 プライム パートナー企業 透明でオープンな競争環境 ＡＤＲの活用 ＡＤＲの活用 信頼性ＧＬ： 信頼性ＧＬ： 信頼性評価指標 信頼性評価指標 ＩＴ部門 ＩＴ投資価値 ＩＴ投資価値 評価ガイドラ 評価ガイドラ イン イン 各局面の取引構造を透明 化するツールを整備。 これらを普及することで、ベ ンダの産業構造転換、情報 システム信頼性向上、ユーザ ベンダ一体となった生産性向 上を促進する。 1 情報システムの信頼性向上のための取り組みについて 全体 取引・契約 ８月 産業構造審議会情報サービス小委員会 証券取引所におけるシステムに障害など、 社会インフラを担う情報システムの障害が 我が国の経済活動に大きな影響 ２００５年 6月 「情報システムの信頼性向上に関するガイドライン」 6月 モデル取引・契約書の検討開始 ２００６年 9月 情報サービス・ソフトウェア小委員会中間とりまとめ （情報サービス・ソフトウェア産業維新） 4月 信頼性評価指標試行版 4月 モデル取引・契約書(第一版) 大手航空会社等における情報システム障害 ２００７年 ２００８年 （予定） 9月 情報システムの信頼性向上のための緊急点検 ・「情報システムの信頼性向上に関するガイドライ ン」改正 ・情報共有体制整備（信頼性評価指標見直し） ・重要インフラの所管省庁等との連携 中小中堅取引 （含パッケージ活用型等） パフォーマンスベー ストコントラクト等 政府調達に係る基 本指針（３月） ↓ 実務手引書（９月） ・「情報システムの信頼性向上のための取引慣行・契約に関す る研究会」 3月14日 セミナー開催 4月 モデル取引・契約書(第二版) 公表 モデル取引・契約書 モデル取引・契約書の検討経緯及び体制（１／２） ■平成１８年６月経済産業省に「情報システムの信頼性向上のための取引慣行・契約に関する研究会」、タスクフォース、保 守・運用プロセスに関するタスクフォースを設置。 スケジュール スケジュール 第１回 （平成１８年６月１日） 情報システムの信頼性向上のための取引慣行・契約に 関する論点について（総論） 第２回 （平成１８年７月１４日） ソフトウェア及びシステムライフサイクルプロセスの可視化 海外（ＵＫ／ＵＳ）の取引慣行について 第３回 （平成１８年８月１０日） 情報システムの開発委託モデル契約書に関する論点整理 超上流、企画・開発フェーズにおける論点整理 第４回 （平成１８年９月２８日） 保守・運用フェーズにおける論点整理 情報システムの信頼性向上のための取引慣行・契約に関する研究会 情報システムの信頼性向上のための取引慣行・契約に関する研究会 飯塚 顕治 池原 進 大谷 和子 上山 浩 木内 里美 鈴木 康史 西村 隆 野々垣典男 板東 直樹 第５回 （平成１８年１０月２６日） モデル取引・契約書の検討 第６回 （平成１８年１２月１５日） 中間まとめ（案）について 〈１月１８日∼２月１６日〉パブリックコメント募集 藤原 宏高 松本 美信 御宿 哲也 第７回 （平成１９年２月２７日） パブリックコメントに関する審議 村上 憲稔 第８回 （平成１９年３月２９日） 最終まとめ 平成１９年４月１３日 最終報告書公表 ◎ 吉田 正夫 （社）情報サービス産業協会 取引・契約部会部会員 新日鐵ソリューションズ（株）法務・知財財産部法務グループシニアマネージャー 日興シティグループ証券（株）情報システム本部長マネジングディレクター （社）情報サービス産業協会 取引・市場委員会・契約部会 部会長 （株）日本総合研究所 法務部長 日比谷パーク法律事務所 大成建設（株） 社長室 理事 情報企画部部長 （社）電子情報技術産業協会 ソフト開発モデル契約ＷＧ 主査 富士通（株） 法務・知的財産権本部 法務部 法務部長代理 （社）日本情報システム・ユーザー協会 システムに関する契約問題検討委員会 副委員長 東京海上日動火災保険（株） IT企画部 企画室 IT予算グループ 課長 （社）日本情報システム・ユーザー協会 システムに関する契約問題検討委員会 委員長 （株）ＪＴＢ情報システム グループＩＴ推進室長 （社）コンピュータソフトウェア協会 CSAJ/JCSSA情報システムの信頼性向上の 契約等に関する検討会 副主査 アップデート テクノロジー（株） 代表取締役社長 ひかり総合法律事務所 （社）電子情報技術産業協会 ソリューションサービス事業委員会 幹事 日本電気（株） 法務部 法務主幹(兼)国内営業ＢＵ 契約支援部 部長 あおば法律事務所 （独）情報処理推進機構ソフトウェアエンジニアリングセンター開発プロセス共有化 部会主査 富士通（株）プロフェッショナルサポートビジネスグループエグゼクティブアーキテクト 三木・吉田法律特許事務所 （◎は委員長） 4 モデル取引・契約書の検討経緯及び体制（２／２） 情報システムの信頼性向上のための取引慣行・契約に関するタスクフォース 情報システムの信頼性向上のための取引慣行・契約に関するタスクフォース 委員長 上山 浩 日比谷パーク法律事務所 委 員 稲垣隆一 (社)日本情報システム・ユーザー協会 システムに関する契約問題 検討委員会副委員長 稲垣隆一法律事務所 委 員 今井鉄男 三木・吉田法律特許事務所 委 員 岩村浩幸 ハーバード・スミス ロンドンオフィス 委 員 大谷和子 (社)情報サービス産業協会 取引・市場委員会・契約部会 部会長 (株)日本総合研究所 法務部長 委 員 鈴木康史 (社)電子情報技術産業協会 ソリューションサービス事業委員会 ソ フト開発モデル契約ＷＧ 主査 富士通(株) 法務・知的財産権本部 法務部 法 務部長代理 委 員 御宿哲也 あおば法律事務所 委 員 横山経通 森・濱田松本法律事務所 委 員 芳仲 宏 （独）情報処理推進機構 ソフトウェアエンジニアリングセンター 開発 プロセス共有化部会委員 東京地方裁判所 専門委員 民事調停委員 東京簡 易裁判所 民事調停委員 保守・運用プロセスに関するタスクフォース 保守・運用プロセスに関するタスクフォース 委員長 柚木 勉 富士通(株) 社会基盤ビジネスグループ ソリューション開発セン ター IT デザインセンター長 委 員 岩嵜 潔 日本電気(株) ニューソリューション開発本部エグゼクティブエキ スパート 委 員 岩崎新一 日本電気(株) ソフトウェアエンジニアリング本部長 委 員 菊田志向 富士通(株) システムサポート事業本部 LCMサービス統括部長 委 員 佐野 隆 富士通(株) 生産革新本部 APMサービスセンター長 委 員 篠原郁二 日本電気(株) 日本電気㈱ 政策調査部 担当部長 委 員 高柳祐治 (株)日立製作所 情報・通信・グループ 経営戦略室 販売計画本 部 受注契約管理部支援G部長代理 委 員 寺田 透 富士通(株) 政策推進本部 情報通信企画部 担当課長 5 モデル取引・契約書の考え方 「信頼性向上」の必要性の増大 「信頼性向上」の必要性の増大 オープン化、モジュール オープン化、モジュール 化によるリスクの増大 化によるリスクの増大 情報システムの重要 情報システムの重要 性の増大 性の増大 ネットワーク化・端末 ネットワーク化・端末 の多様化等によるリ の多様化等によるリ スクの増大 スクの増大 ユーザ・ベンダ双方で信頼性を確保するためにシステムライフサイクル全般について取り組む ユーザ・ベンダ双方で信頼性を確保するためにシステムライフサイクル全般について取り組む べき事項を、「情報システムの信頼性向上に関するガイドライン」「ＳＬＣＰ２００７」等をもとにモデ べき事項を、「情報システムの信頼性向上に関するガイドライン」「ＳＬＣＰ２００７」等をもとにモデ ルとして提示。 ルとして提示。 それぞれの項目について、役割分担を「初期」に、「文書ベース」で明確化する それぞれの項目について、役割分担を「初期」に、「文書ベース」で明確化する リスクが顕在化した場合の対応方針・責任分担を「初期」に、「文書ベース」で明確化する リスクが顕在化した場合の対応方針・責任分担を「初期」に、「文書ベース」で明確化する 仕様が変更する場合に、しっかりした合意のプロセスに基づき「文書ベース」で明確化する 仕様が変更する場合に、しっかりした合意のプロセスに基づき「文書ベース」で明確化する → → 変更管理手続の導入 変更管理手続の導入 6 モデル取引・契約書のポインと活用による効果 情報システムの課題 モデル取引・契約書の中での対応 活用による効果 エンドユーザの意向に仕様が左右されるため エンドユーザの意向に仕様が左右されるため 、仕様の変更が頻繁に起こる。 、仕様の変更が頻繁に起こる。 ベンダ・ユーザの役割分担・責任分担を明確化 ベンダ・ユーザの役割分担・責任分担を明確化 仕様変更の手続の整備 仕様変更の手続の整備 役割分担・責任関係の明確化 役割分担・責任関係の明確化 仕様変更の適正な管理 仕様変更の適正な管理 セキュリティ対策の必要性の増大 セキュリティ対策の必要性の増大 セキュリティ要求仕様書の策定 セキュリティ要求仕様書の策定 個人情報保護・コンプライアンスの必要性の 個人情報保護・コンプライアンスの必要性の 増大 増大 セキュリティ対策・個人情報保護関 セキュリティ対策・個人情報保護関 連のコンプライアンスの進展 連のコンプライアンスの進展 再委託についての配慮事項等の提示 再委託についての配慮事項等の提示 マルチベンダを前提とした取引の対応 マルチベンダを前提とした取引の対応 マルチベンダの場合の責任関係の整理 マルチベンダの場合の責任関係の整理 パッケージ・ＯＳＳ等多様な手法への対応 パッケージ・ＯＳＳ等多様な手法への対応 パッケージ・ＯＳＳ活用の場合の配慮事項 パッケージ・ＯＳＳ活用の場合の配慮事項 既存システムへのマイグレーション案件の増 既存システムへのマイグレーション案件の増 大、パッケージの組み合わせ利用等に伴いリ 大、パッケージの組み合わせ利用等に伴いリ スク増大。ライフサイクル全般のマネージメン スク増大。ライフサイクル全般のマネージメン トの必要性増大。 トの必要性増大。 保守運用への対応 保守運用への対応 ライフサイクルマネージメントの進展 ライフサイクルマネージメントの進展 による効率性・信頼性向上 による効率性・信頼性向上 損害賠償に関する取り決め 損害賠償に関する取り決め リスクの可視化、マネージネント向上 リスクの可視化、マネージネント向上 汎用モジュールの著作権をベンダへ留保 汎用モジュールの著作権をベンダへ留保 モジュール化・パッケージ化等による モジュール化・パッケージ化等による 再利用の進展。生産性向上。 再利用の進展。生産性向上。 7 ベンダの側ではモジュール化・再利用の進展 ベンダの側ではモジュール化・再利用の進展 による生産性の向上が急務。 による生産性の向上が急務。 マルチベンダ・多様な情報サービス マルチベンダ・多様な情報サービス 提供・活用の促進による生産性向 提供・活用の促進による生産性向 上 上 モデル取引・契約書の構成 ■モデル取引・契約書は下記の三つのコンポーネントから構成。それぞれについて「情報システムの信頼性向上に関するガ イドライン」（平成１８年６月）の内容を反映： ①モデル契約プロセス：情報システム構築・取引のプロセスと契約のプロセスとの関係を整理 ①モデル契約プロセス：情報システム構築・取引のプロセスと契約のプロセスとの関係を整理 ・・ デューデリジェンスの実施から、契約締結、変更管理手続（仕様変更・契約変更）に至るまでの取引ルール。 デューデリジェンスの実施から、契約締結、変更管理手続（仕様変更・契約変更）に至るまでの取引ルール。 ・・ 見積時期とリスクとの関係を踏まえて、多段階契約と再見積の考え方を採用。 見積時期とリスクとの関係を踏まえて、多段階契約と再見積の考え方を採用。 ②モデル契約書（企画・開発、保守・運用）：契約の雛形及びコンメンタール ②モデル契約書（企画・開発、保守・運用）：契約の雛形及びコンメンタール ・・ 情報システム特有の性質、取引慣行を踏まえた、契約書において決定すべき事項やそれを承認・変更する手続的事 情報システム特有の性質、取引慣行を踏まえた、契約書において決定すべき事項やそれを承認・変更する手続的事 項。 項。 ③ドキュメントモデル：契約以外で利用されるドキュメントのモデル ③ドキュメントモデル：契約以外で利用されるドキュメントのモデル ・・ モデルプロセス・契約書において、関連するドキュメント（RFP、提案書、ｾｷｭﾘﾃｨ要求仕様書、変更提案書管理書等） モデルプロセス・契約書において、関連するドキュメント（RFP、提案書、ｾｷｭﾘﾃｨ要求仕様書、変更提案書管理書等） について、ユーザ・ベンダの双方が具体的なイメージを共有できるように可能な限り詳細に例示。 について、ユーザ・ベンダの双方が具体的なイメージを共有できるように可能な限り詳細に例示。 ■モデル取引・契約書＜第一版＞の前提・対象は下記の通り。パッケージ活用型、反復繰り返し型の開発、中小企業ユーザ との取引等下記の前提と異なる場合の活用については、留意が必要。今後、包括的に検討予定。 ○ ○ 契約当事者：対等に交渉力のあるユーザ・ベンダを想定 契約当事者：対等に交渉力のあるユーザ・ベンダを想定 (例) (例) 委託者（ユーザ）：民間大手企業、受託者（ベンダ）：情報サービス企業 委託者（ユーザ）：民間大手企業、受託者（ベンダ）：情報サービス企業 ○ 開発手法：ウォーターフォールモデル ○ 開発手法：ウォーターフォールモデル ○ ○ 対象システム：重要インフラ・企業基幹システムの受託開発、保守・運用 対象システム：重要インフラ・企業基幹システムの受託開発、保守・運用 ○ プロセス：共通フレーム2007（現在改訂中）による標準化されたシステム企画・開発・運用・保守プロセスによる ○ プロセス：共通フレーム2007（現在改訂中）による標準化されたシステム企画・開発・運用・保守プロセスによる ○ ○ 一括発注の場合に加えて、マルチベンダ形態、工程分割発注に対応 一括発注の場合に加えて、マルチベンダ形態、工程分割発注に対応 8 モデル取引・契約書：今後の検討課題について ・ システムライフサイクルプロセスの体系化 経済産業省及びIPA（独立行政法人 情報処理推進機構）/SEC（ソフトウェア・エンジニアリング・センター）は、 ユーザ・ベンダ間のシステムライフサイクルプロセスの共有化に向けて、研究会の成果を踏まえつつ、保守・運 用プロセスの可視化を含めた共通フレームの体系化を行うことが望まれる。 ・ モデル取引・契約書の定期的な見直し・多様な契約のあり方についての検討 経済産業省は、研究会で策定されたモデル契約プロセス、モデル契約書、モデルドキュメントの定期的な見 直しを行う。また、保守・運用プロセスの体系化を踏まえた保守・運用サービスに対応したモデル取引・契約書 、パッケージ活用型、中小企業ユーザとの契約、ソフトウェアモジュールの再利用を促進する観点、パフォーマ ンスベース契約の観点等の多様な契約のあり方等についても検討を行う。 ・ 多様な開発モデルにおける契約のあり方についての検討 経済産業省は、ウォーターフォールモデル以外の開発モデルが活用されている実態を踏まえて、反復繰り 返し型等の開発モデルに基づいた契約のあり方について、信頼性の向上・取引の可視化の観点から検討を行 う。 ・ ＡＤＲ（裁判外紛争処理）の活用 ユーザ・ベンダの責任分担とその履行等について、専門的・技術的視点による詳細な事実認定、並びに当事 者間の話し合い及び調整といった機能・プロセスが必要となる場合、紛争処理を迅速かつ柔軟に行うことが可 能であるＡＤＲの活用・促進が望まれる。なお、モデル契約書においては、紛争処理方法について、仲裁による ことを原則としている。 9 モデル取引・契約書の活用について ・ 政府調達における活用 経済産業省は、研究会の成果を踏まえて、積極的に調達に活用することに加え、政府調達における 活用方策を検討する。 ・ 信頼性評価指標への活用 経済産業省及びIPA/SECは、現在策定中の情報システムの信頼性評価指標において、モデル契約 書に定める主要事項の準拠に対する取組レベルを診断し、可視化することが望まれる。 ・ 保険制度の創設の検討 モデル契約の活用・普及によるユーザ・ベンダの情報システムに関するリスク認識の向上、顕在化す るリスクへの対応のために、モデル契約書及び前述の信頼性評価指標等を被保険者の個別審査に活 用した保険商品が設計されることが望まれる。 ・ 業界団体等における普及・啓発 ユーザ・ベンダを代表する各業界団体においては、信頼性ガイドラインにおいて定められた対策及び 留意事項の実施、研究会での議論を最大限尊重した取引慣行の確立に向けて、啓発活動を行うことが 望まれる。 また、パッケージを中心としたシステム導入の場合や反復繰り返し型の開発の場合、中小企業ユーザ における活用の場合等、本モデル取引・契約書で十分カバーできていない論点について、業界団体を 中心としてさらに議論が深められることが望まれる。 10 主要論点①フェーズの分類と契約類型…準委任／請負 （論点） 情報システム開発等の委託に係る契約類型としては準委任・請負がある。両者は下記のような法的な違いがあることに加え、例えば、請負 型においてはユーザ側の心理として「丸投げ」という意識が強くなる場合があることが指摘される等役割分担についての意識にも影響を与え るとの指摘がある。これらをふまえて、契約類型を定めることが必要である。 準委任と請負の相違 仕事の完成義務：請負ではベンダは仕事（受託業務）の完成の義務を負うのに対し、準委任ではベンダは善良な管理者の注意をも って委任事務を処理する義務 を負うものの、仕事の完成についての義務は負わない。 瑕疵担保責任：請負では、仕事の完成義務を負うので、例えばユーザに完成されたものとして引き渡された成果物に瑕疵があった 場合、無過失責任としての瑕疵担保責任を負う 。すなわち、このような場合民法（第634条乃至第640条）によれば、注文者であるユ ーザは修補や損害賠償を請求することができる。また、瑕疵により契約の目的を達成することができないときは契約を解除すること ができる。これに対して、準委任の場合、仕事の完成義務はないので、請負のような瑕疵担保責任を負うことはない。ただし、事務処 理に関して善管注意義務違反があった場合には、債務不履行責任（例えば不完全な履行を完全なものにすること や損害賠償責任 など）を負うこととなる （モデル取引・契約書） 理想的なユーザと、ベンダの役割分担としては、ユーザが、企画段階において業務要件及びシステム要件（外部設計に対するインプット）を 主体的に決定・明確化し、その上で開発段階において、ベンダが主体となって業務全体に対する利害関係者の要件のうち、システムに関す る部分（システム要件）についての仕様化を行う。また、外部設計がユーザによる承認を受けた後の要件追加、仕様変更、未決事項等は変 更管理手続に則り、委託料・納期等の協議を実施することが望ましい。このモデルを実現するために、下記の契約類型を基本としながら、各 フェーズにおけるユーザ・ベンダの責任分担を、契約書において詳細に規定する。 ※実際の契約において、準委任型とするか、請負型とするかは、成果物の特定についての当事者同士の経験や役割分担の遂行能力等に基づき、成果物についての 共通理解が事前に十分に成立しているかによる。 超上流 システム化 の方向性 システム化 計 画 要件定義 システム 設計 （外部設計） 11 準委任型 ソフトウェア設計 プログラミング ソフトウェアテスト 運用 テスト （内部設計） 請負型 請負型 システム テスト 請負型 準委任型 運用 保守 準委任型 請負型 主要論点②再委託におけるユーザの承認の要否 （論点） 再委託先の選定について事前にユーザーの承諾を必要とするかどうかについては、責任関係の明確化の観点等から意 見が分かれる。契約において規定しておくことが重要。 （モデル取引・契約書） 再委託におけるユーザの事前承諾を設ける場合（【A案】）と再委託先の選定について原則としてベンダの裁量（但し、ユー ザの中止請求が可能。）とする場合（【B案】）の規定を用意するとともに、両案共通にモデル取引・契約書において下記の 措置を講じる。 ① 再委託先の選定は、情報システムの品質を担保するためにユーザに与えられるべき重要な情報であることから、契約書締結前のプロジェク トのプロポーザル・見積段階において、基本的な大口再委託先やオフショア利用等、プロジェクトの推進体制を事前に提案・見積条件として説 明する ② 再委託先との間で、契約に基づいてプライムベンダがユーザに対して負担するのと同様の義務を、当該再委託先に負わせる契約を締結する ③ ユーザ指定の再委託先との責任関係については、ベンダに故意又は重過失がある場合を除き、再委託先の履行についての責任を負わない ④ ユーザが再委託先に異議がある場合は、具体的な理由 を書面で明示する。 Ａ案 【ユーザの承認は必要とする考え方】 特に大規模システム開発の場合、委託先の決定がプロジェクト成功の成否・品質に大きな影響がでること、情報セキュリテ ィ対策の適切な実施を確保する必要性、従業員管理、多重下請などコンプライアンスの観点からも、ユーザの事前承諾を条 件とすべき。 Ｂ案 【ベンダに一任とする考え方】 開発プロセスにおいて、プライムベンダは、自己の責任において、対象システムに関わるスキル、経験、実績等を踏まえて 再委託先（履行補助者）を選定。そのため、再委託先に対して、プライムベンダと同様の法令遵守、秘密保持等について必 要な措置を講じる義務を課すことで、ベンダに一任されるべき。（法律上は、仕事の完成のために履行補助者を使用するか 否かは請負人の裁量である） 12 主要論点③損害賠償責任（１／２） （論点） 損害賠償責任の範囲、限度額について、民法の原則に従い相当因果関係の範囲（通常損害及び予見可能な 特別事情から生じた特別損害）とすべきか、情報システム構築の特殊性を考慮すべきかについて、議論が分 かれる。 【契約で損害賠償責任の範囲等を規定すべきでなく民法の原則によるべきとの議論】 ①情報システムが、企業活動の本質である「競争優位」を得るためのシステムに移行しており、企業の営業活動に必要不可欠 なインフラとなってきていることから、システム開発の中止、稼働開始時期の遅延あるいは障害等による稼働停止の被害の リスクは、民法の原則に則るべき。 ②実際の紛争においては、特別損害の立証は困難であり、また過失相殺により賠償額は減額されるなど、損害賠償責任は適 切な範囲に限局される。本当に上限設定を設けないとベンダ側が無制限のリスクを負うのか。 【情報システム構築の特殊性を考慮して損害賠償責任の範囲、限度額等を契約で規定すべきとの議論】 ① オープン化の進展により、多数の製造者が提供するハードウェア、ソフトウェアを組み合わせることが一般的となっている情 報システムを構築・運用する上で、それらの整合性等を完全に検証する手段がなく、予防手段が限られている。 ② 情報システムは、ユーザの業務プロセスの変化への対応など、内部的・外部的要因 により、構成するハードウェア、ソフトウェ アの軽微な変更（例えば、機器部品の交換、バージョンアップ、セキュリティ上の脆弱性に対するパッチ等）が加えられていく が、それらをベンダが管理・支配できる要素が他の物品や役務の提供に比べて限定的である。 ③ 一定の委託料と納期の範囲で、通常要求される注意義務を越えてリスクを負担することには限界があり、情報システムの 障害を極小化するためのコスト（例えば、あらゆるパターンを想定したテストを実施するための費用・期間）とのトレードオフ の関係にある。 ④ 海外の取引慣行（米国・英国）でも責任の範囲・上限を契約書で設定していることが多い。また、海外製品を導入している場 合、海外製品の瑕疵によって生じる損害のリスクをベンダがライセンサー（海外製品の供給者）に転嫁することができず、ベ ンダ自身が負わざるを得ないのが実態である。 13 主要論点③損害賠償責任（２／２） （モデル取引・契約書） 情報システムの信頼性の向上の観点からは、「障害の種別・当初合意されていた信頼性・安全性水準に よって、情報システム利用者及び情報システム供給者の責任の度合いが大きく異なる」ことを前提に、「損 害賠償の範囲・賠償上限額等の損害の負担のあり方」等を規定することが重要である（「信頼性ガイドライ ン」を参照。）。 この前提となっているのは、信頼性の向上のためには、ユーザとベンダの双方が、リスクの性質・規模を 的確に認識し、管理の仕方を検討することが重要であるということである。両者が責任の負担を検討する ことにより、リスクを軽減するための具体的な対策（例えば、十分なテスト期間の確保、データの二重化、 運用回避策等）や、保険制度等によるリスクヘッジの必要性・コストを十分に検討することが期待される。 ① 損害賠償責任については、契約書締結前のプロポーザル・見積段階において、事前に提案・見積 条件として説明する。 ② 具体的な損害賠償の上限額、瑕疵担保期間、債務不履行責任による損害賠償請求の期間 につ いては、個々の情報システムの特性等に応じて定められるものであるため、モデル契約書において は、具体的な範囲・限度額・期間を個別に決定できるように記述する。 14 主要論点④著作権の帰属（１／２） （論点） 開発されたプログラムの著作権を、ベンダに留保するか、契約によりユーザに移転するかについて合意する必要がある。 【ユーザに帰属させるべきとの議論】 ①成果物において、開発作業に協力したユーザ情報が含まれており、ユーザのノウハウの流出を防止（特に、ユーザの競合他 社）する必要がある。 ②開発費用をユーザが負担している。 ③ベンダが倒産した場合、破産管財人によりソフトウェア著作権のライセンス契約が解除されるおそれがある 。解除された場合、 ユーザはソフトウェアの使用を中止し、新たにソフトウェアを開発し直さなければならなくなる。 【ベンダに帰属させるべきとの議論】 ①ベンダに著作権を帰属させることにより、社会的な生産効率の向上（ベンダの横展開（パッケージ化、共通モジュールの再利 用等））とともに、プログラムの部品化、標準化等により情報システムの信頼性向上を図ることが可能となる 。 ②ベンダに秘密保持義務を課すことでユーザのノウハウ流出防止を図ることが可能であり、“ノウハウ流出防止＝著作権のユー ザ帰属”ではない。 ③公正取引委員会の役務取引ガイドライン に基づき、著作権の譲渡に関する対価を含めた譲渡契約が成立すれば理論的に は対等な取引条件といえるが、通常は、情報システム構築の委託契約において、明示的に権利移転の対価は含まれていな いので対等な取引条件とはいいがたい。 ④プログラムの著作物についての一定の改変、複製・翻案は、複製物の所有者に対しても著作権法 により許容されており、著 作権を有しないユーザが情報システム子会社その他アウトソーシングベンダに保守運用を委託することは可能である。倒産 における著作権の帰趨については、対抗要件を具備する制度は存在しないものの、ソースコードや付帯するドキュメントの開 示・交付を受けることは、納入物にソースコードを明記するか、エスクロウ制度の活用 により対応可能である。 15 主要論点④著作権の帰属（２／２） （モデル取引・契約書） 汎用的な利用が可能なプログラム等の著作権をベンダへ帰属させることを前提として下記の三案を提示 Ａ案：ベンダにすべての著作権を帰属させる場合 Ｂ案：汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外をユーザに権利を帰属させる場合 Ｃ案：汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外を共有とする場合 各案共通して下記の措置が必要。 ① 著作権を含む知的財産権の帰属について、契約書締結前のプロポーザル・見積段階において、事前に提案・ 見積条件として説明する。 ② プログラムに関する著作権について、ベンダが将来のソフトウェア開発に再利用できるように、同種のプログラ ムに共通に利用することが可能であるプログラムに関する権利（ベンダが従前より権利を有していたもの及び本 件業務により新たに取得したものを含む。）及びベンダが従前から保有していたプログラムに関する権利は、ベ ンダに留保されるものとする。ベンダは、契約に定める秘密保持義務に反しない限り、他のソフトウェア開発にお いても汎用プログラム等を第三者に許諾し、又はパッケージ化して販売することを可能とする。 ③ ユーザは、秘密保持義務の及ぶ範囲を明確化する。 ④ ベンダの秘密保持義務は、情報システム構築後の関連プログラムの権利の再利用にまで及ぶものであり、秘 密保持義務が優先されるものであることを明確化する。 16 主要論点⑤第三者ソフトウェア・ＦＯＳＳの利用 （論点） 第三者ソフト・ＯＳＳの利用については、①当該ソフトウェアそのものの瑕疵に起因するリスク及び②システムと の組み合わせに起因するリスクが存在。そのリスクの分担について契約において規定することが必要。 （モデル取引・契約書） ・ベンダが第三者ソフト及びFOSSの瑕疵の有無を管理することは非常に困難である場合が多いが、取引のパター ンとして、ユーザが特定の製品を予め指定する場合、価格・機能の条件を指定しその中からベンダが選定す る場合、ベンダが自ら選定する場合があり、それぞれの場合でベンダの責任の範囲が異なってくる。 ①第三者ソフト及びFOSS自体の瑕疵に起因するリスクは、当該第三者とユーザとの契約で対処すべき問題。 他方、ユーザに第三者ソフト及びFOSSの選定の知見等がなく、ベンダがユーザに導入の可否について判 断機会及び判断を行うために、合理的に必要とされる情報を与えることなく自主的判断で選択した場合に ついては、ベンダも一定の責任を負う（特に、ベンダは当該ソフトの選定（利用方法、機能上・利用上の制 限、保証期間等）について、専門家としての情報提供義務を契約上の責任として負う。）。 ②他のシステムとの組み合わせに起因するリスクは、システムインテグレーションを担当するベンダが負う べきであるが、原因の特定が困難であることが多く、トラブル原因の切り分けを含めた原因究明の手続き を定めておく必要がある。 17 参考 信頼性向上・ 取引可視化の ため の 「 モデル取引・ 契約書」 の 全体像 《 フェ ーズ 》 (各フェ ーズ におけ る 論点の マッ ピ ング ） （ＳＬＣＰ−２００７） ……アクティビティ名称は検討中 企画プロセス（１．３） 運用プロセス （１．５） 開発プロセス（１．４） 保守プロセス （１．６） （『超上流』） システム化 の方向性 システム化 計 画 要件定義 契約 契約 ＲＦＰ① 見積①（試算） ＲＦＩ ・ プロセス・用語の定義の明確化 ソフトウェア設計 プログラミング ソフトウェアテスト システム テスト 運用 テスト 運用 保守 《契約プロセス・手続き規定》 ・ 多段階契約と再見積りの考え方を採用 ・ ＬＯＩ（仮発注合意書）モデルを策定 ・ マルチベンダ方式、分割発注時の考慮 事項の整理 （外部設計） （内部設計） 《 契約プロ セス 》 （ 例） 契約 システム設計 ＲＦＰ② 見積②（概算） 契約 契約 契約 見積③（確定） 《 モデル契約書雛形》 企画支援サービス業務 要件定義 作成支援業務 外部設計 書作成 業務 ソフトウェア開発業務 システム テスト業務 ソフトウェア 運用準備・ 移行支援業務 ○ 基本契約書 （開発基本契約書） 【準委任型】 【準委任型】 ○ 各フェ ーズ共通事項等 【準委任型】 【請負型】 ・ ・ ・ ・ ・ ・ 【請 負 型】 【準委任型】 【請負型】 【準委任型】 変更管理手続の詳細化（第37条） 検収基準の明確化（第26・27・28条） 中間資料の承認の効果を明確化（第35条） 第三者ソフトに関するベンダの情報提供責任（第48条第1項） 第三者ソフトの瑕疵等に関する責任分担（第48条第4項） ソフトウェア開発期間中の第三者ソフトの保守契約 をユーザが締結することとする（第48条第3項） 保守 業務 （保守・運用基本契約書） 【準委任型】 【請負型】 ・障害発生時の対応手順等の 規定 （第10条） ・ＳＬＡ条項（仕様書において 規定） ・ 個別契約書（サンプル） ・ 業務仕様書（サンプル） （アプリケーション保守、 オンサイトアウトソーシング） ○ 個別契約書 ・業務終了報告書(第23条) ・業務終了確認書(第23条) ・ ＲＦＩ ・業務終了報告 ・外部設計書検収依頼書 ・ ＲＦＰ、セキュリティ要求仕様書 書(第18条) （兼納品書）【請負型】の場合 ・ 提案書 ・業務終了確認 ・外部設計書承認書 書(第18条) 【請負型】の場合 《 モデル ド キュメ ント 》 運用 業務 ・検収依頼書（兼納品書）（第26条） ・検査合格書（第28条） ・業務終了報告書（第32条） ・業務終了確認書（第32条） ・変更提案書・管理書（第34∼37条） 《責任関係》 ・ ユーザ・ベンダの役割分担の明確化 （第8条関係〈作業責任分担〉） ・プロジェクトマネジメントの責任 （第13条） ・未決事項の確定手続・時期の明確化 （第36条） ・ セキュリティ対策の責任の明確化（第50条） 《主要論点整理》 ・ フェーズの分類と契約類型 ・ 再委託におけるユーザ承諾の要否（第7条） ・ 損害賠償責任（第53条） ・ 著作権の帰属（第45・46条） ・ 第三者ソフトウェアに関わる瑕疵（第48条） 《その他》 ・ 工程分割発注分割発注を前提とした規定 （例）要件定義書の精査・修正、変更の協議 不調に伴う契約終了 ・ ドキュメントの定義の明確化（参考：第2条） ・ プロジェクト推進体制図（第9・10条関連） ・ 作成者（ユーザ（内）、ベンダ）役割分担の 明確化 《 契約プロ セス ガ イ ド／条文解説の記載事項》 ・ 超上流工程の重要性 ・ ステークホルダ（経営層、業務部門、情報システム 部門）の合意の可視化の必要性 ・ 運用・保守も見据えた計画・体制・コスト等への配慮 ・ 要件定義における信頼性向上の視点の必要性 ・ 見積書（再見積の必要性、リーガルポリシーの明確化） 18 ・第三者ソフトウェアの利用の際に共有されるべき リスク情報 ・オープンソースを利用する場合のリスク評価 ・ ＩＳＯ20000、ＩＴＩＬ等との関係 の整理 ・ 各フェーズの契約の性質、内容等 ・ 役割分担における留意点（特にグレーゾーン） ・ 請負の瑕疵担保責任の性質（債務不履行の 特則） ・ 第三者による監査の視点、内部統制 政府調達関係 「情報システムに係る政府調達の基本指針」（平成１９年３月１日）における契約の取扱 （以下抜粋、注省略、下線は講演者付加） ３．契 約 契約書に基づかない口頭指示等による不明確な仕様変更等を行った場合、事業者との組織的な意思疎通が阻害され、 また、納期や品質に関するリスク管理がなされないおそれがあるとともに、そうした不明確なやり取りが、潜在的な新規 参入事業者の参入意欲を削いでいる可能性がある。 事業者との意思疎通は、契約書の内容に基づいて行うこととし、それを前提とした的確かつ適正な契約を、落札者の 決定後、速やかに締結することとする。 各府省は、契約書の作成に当たっては、情報セキュリティポリシー等の既存の規定への準拠のほか、以下の事項に留 意する。 （１）知的財産権の帰属 将来の運用、保守及び情報システムの改修に際して、特定事業者への依存を防止する観点に留意しつつ、知的財産 権の帰属について契約書に明記する。 なお、著作者人格権41は、著作者の一身に専属し、仮に、著作者人格権における公表権42を行使された場合は、情報 システムの設計に係る内部情報が公開される等のおそれがあることを踏まえ、情報システムの設計に係る内部情報を秘 匿すること等が必要な場合は、著作者人格権について、権利行使をさせないよう、別紙６に従って、契約書に明記する。 （２）要求仕様等の変更規定 契約書において、要求仕様や実作業の体制等の変更の場合の取り決めがないことが多いため、実作業中の仕様変更 等については、別紙６に従って、契約書上にその手続を明記する。 （３）EVM等の活用による進ちょく管理 実作業を事業者任せとした場合、実作業の進ちょくの把握が困難となり、契約期限間近になって実作業の遅延が発覚 し、契約を延長せざるを得ないといった問題が生じ得る。 このような事態を回避するため、調達担当課室は設計・開発等の各工程においては、WBS44（Work Breakdown Structure）を作成し、EVM（Earned Value Management）等を活用すること等により、定期的な進ちょく管理及び報告を事業 者に義務付け、実作業の進ちょくを管理する旨、契約書に明記する。 なお、最適化対象業務・システムについては、最適化指針に従い、EVMによる管理を行う。 20 「情報システムに係る政府調達の基本指針」（平成１９年３月１日）における契約の取扱 （４）サービスレベル契約の導入 事業者によって提供されるサービスの内容、品質等に係る事業者側、発注者側双方の認識の差異が、トラブルの一因になっているとの指摘を 踏まえ、情報システムに係る工程中、同一性の高いサービスが反復、継続的に提供される運用、保守の工程において、サービスレベル契約 （SLA：Service Level Agreement）を導入する。 SLAの導入に当たっては、受注事業者と発注者側の役割分担、必要な管理項目とサービスレベル管理指標の保証値（例えば、運用時間帯や 障害を検知してから報告するまでの時間）等について、受注事業者と発注者との間で合意し、契約書に明記する。 （５）瑕疵担保責任期間等の設定 瑕疵担保責任期間等についての契約の定めがない場合、検収の日から１年を経過した後は、情報システムの瑕疵が発見された場合にその修 補を府省自らの責任において実施せざるを得ない状況となるため、当該修補を受注事業者に適切に行わせることができるよう、契約書において、 必要に応じて瑕疵担保責任の期間や内容（修補、代金減額、解約条件等）を適切に設定する。 （６）損害賠償範囲の設定 「情報システムに係る政府調達制度の見直しについて」を踏まえ、サービス内容ごとに、当該情報システムが正常に機能しない状況が発生し た場合に想定される損害の程度、国民生活に与える影響等を踏まえつつ、適当と認められる場合には、損害賠償の範囲の限度を設定する等、 契約書において、損害賠償責任の明確化を行う。 （７）資金繰りへの対応 「ベンチャー企業からのIT関連政府調達の拡大方策について」を踏まえ、別紙６に従い、中小企業信用保険法施行令（昭和25年政令第350号） 第1条の2に規定する金融機関及び信用保証協会法（昭和28年8月10日法律第196号）第1項に規定する信用保証協会又は一定の受け皿機関 （資産の流動化に関する法律（平成10年法律第105号）第2条第3項に規定する特定目的会社）に対して債権を譲渡する場合に限り、債権譲渡禁 止特約を解除する旨、契約書に明記する。 （８）調達仕様書関与者等への再委託の禁止等 実作業の工程において、調達仕様書関与者等へ再委託することがないよう、契約書において明記する（別紙６参照）。 （９）法務の観点からの契約内容の確認 会計担当課室は、契約書について、可能な限り法律専門家の助言を受ける。会計担当課室は、可能な限り法律専門家を活用し、知的財産権 や損害賠償等情報システム特有の契約内容の有効性、適法性等、法務面の観点からの確認を行う。 （１０）契約情報の提供 調達担当課室又は会計担当課室は、契約締結後速やかに、別紙７に従い、「情報システムに係る政府調達事例データベース」に必要な情報を 21 登録する。 「情報システムに係る政府調達の基本指針」実務手引書 • 平成１９年９月公表 • 「情報システムに係る政府調達の基本指針に基づき、各府省における調達指針の実施に 資するために作成したもの」であり、「調達実務を遂行するに当たっては、本書を参考とし つつ、調達における課題解決やリスク低減等のための工夫を積み重ねていくことが重要」 とされている。 • 契約については「第五章分離調達における契約」「付属資料３．モデル契約書」で取扱： ＜モデル契約書の構成＞ – 契約書 →各府省で利用している請負契約書の雛形 – 情報システム設計・開発等の請負に関する特約書 →契約書に優先して適用される。 ＭＥＴＩ「情報システム・モデル取引・契約書」をベースに作成 – 協働関係形成に係る取決め書 →特約書の一部として、各事業者の役割分担等の 基本的な事項を示す 22 実務手引書の主要論点①： • 分離に係る論点（取決め書・第4条･第5条）： – 「分割リスク及び情報システムの統合の責任は、基本的に発注者が負うこと となる」（指針） – 「プロジェクト全体の管理責任については調達担当課室が負う」 →ただし、 「工程管理支援の請負に関する特約書」は「請負」型？ＭＥＴＩ版では「準委任 型」 – 「取決書」の導入 →法的効力？受託事業者は契約時点で権利義務関係の 相手方がわからない • 再委託（第6条）： – ＭＥＴＩ版の「再委託におけるユーザの事前承諾を設ける場合」と同様の整理。 ただし、「○日以内に具体的理由を明記した書面による承諾拒否の通知が ない場合、甲（発注者）は当該再委託を承諾したものとみなす」規定はなし。 →個人情報保護法との関係等で再委託そのものをどう考えるかの検討が 必要。 23 実務手引書の主要論点②： • 請負・準委任（第18条）： – ＭＥＴＩ版ではＳＬＣＰをベースにフェーズわけし、上流は準委任、下流は請負 を基本としたが、政府版は未整理（モデル契約は請負型）。 – 本文（ｐ７２）で「今後の検討事項」とされている（会計制度との関係の整理も 必要）。 • 変更管理手続（第24条）： – ＭＥＴＩ版モデル契約書と同様に規定 • 損害賠償（第38条）： – 規定することを推奨 →具体的な範囲は今後の検討事項 • 著作権の帰属（第31条）： – 発注者側への帰属を前提。 – バイドール活用の場合は「ソフトウェアに係る日本版バイ・ドール制度に係る 運用ガイドライン」（平成19年8月、経済産業省）＜既存のバイドールの運用 をソフトウェアの観点から見直し、特に不要な報告義務等を簡素化＞を参照。 →著作権については、秘密保持や将来の保守運用の確保と著作権の保 有とがイコールでないことを前提にＢＤの活用の検討が必要。 24 （別添） 情報システムの信頼性向上のた めの緊急点検結果 緊急点検の実施について 重要インフラのシステム障害がかねてより発生していることを受け、平成１９年５月２９日、 甘利経済産業大臣の指示により、情報システムの信頼性向上のための緊急点検を実施。 重要インフラ等システム（※１）、及びそれに準ずる企業基幹システムを対象に、平成１９年６ 月６日∼１８日でアンケート調査を実施。 その結果、ユーザ企業２５社とベンダ企業６６社、合計１３３件（※２）の有効回答を取得。 ※本調査では、２００５年度の売上高ベースで、情報サービス産業約１１兆円の３５％程度 をカバー（※３）。 重要インフラ等システムの事業分野別の回答数は以下の通り。 物流 5% 水道 3% 情報通信 14% 医療 5% 政府・行政 サービス 18% 金融 19% ガス 3% 電力 9% 鉄道 13% 航空 11% 全体：１９６（※４） ■重要インフラ等システムにおける事業分野別回答状況 【留意点】 （※１）重要インフラ等システム 他に代替することが著しく困難なサービスを提供する事業が形成する国民生 活・社会経済活動の基盤であり、その機能が低下又は利用不可能な状態に 陥った場合に、我が国の国民生活・社会経済活動に多大の影響を及ぼすお それが生じるもの、人命に影響を及ぼすもの及びそれに準ずるもの。 （※２）１社から複数の回答シートが提出された場合、各回答シートを１件とカウント （※３）カバー率は、ハードウェアベンダ分を除く。 （※４）重要インフラ等システムのみカウント。複数の事業分野をチェックした場合、重 複カウント。 緊急点検項目について 緊急点検項目は、以下の５つの観点から実施。 （１）システム移行又はリリース時の作業の確実な実施 システム移行又はリリースの際には、情報システムの安定稼働に関する主要項目について、 十分なテスト及びレビューを実施すること。 （２）システムの信頼性・安全性水準の確認 システム移行又はリリース後の運用水準に関するサービスレベルを明確化することにより、 情報システムが具備すべき信頼性・安全性の水準及び目標とする品質水準を確定すること。 （３）システム障害発生時の緊急対応体制の確認 障害発生時の指揮命令系統及び対応手順を整備し、周知徹底すること。 システム障害を他の業務系に波及させない仕組みを確立すること。 –バックアップシステムの整備 –システム構成要素の二重化・多重化 –人的資源の投入等による代替手段の確保 （４）セキュリティ対策 稼働システムについて、システム不具合の原因のほか、情報セキュリティを含めて、システ ム全体の信頼性・安全性を確保する対策を再確認する。 （５）組織体制の確立 上記措置を講じるための経営層以下の体制整備及び関係者の連絡体制の確立 緊急点検結果について 情報システムの信頼性向上に関する取組について、回答企業全体 として概ね良好な結果が得られたが、以下の３項目について取組が 不十分であることが判明。 取組が不十分な項目は以下の通り。 （１）情報システムに潜むリスクの分析に基づく、信頼性・安全性に関する目標水 準の設定が、約２５％の企業で不十分。 （２）事故や災害など不足の緊急事態に陥った場合、重要業務が中断しない、あ るいは最小限の被害にとどめて事業を継続するための事業継続計画（BCP： Business Continuity Plan）が、約３１％の企業で不十分。 （３）第三者（専門家、品質保証部門／技術専門部門、企業・機関等）による情報 システムのレビュー及びシステム監査が、約２２％の企業で不十分。 【参考資料】緊急点検結果 全体集計 質問項目概要 質問項目概要 （１）システム移行時又はリリース時の作業の確実な実施 （１）システム移行時又はリリース時の作業の確実な実施 （２）システムの信頼性・安全性水準の確認 （２）システムの信頼性・安全性水準の確認 （３）システム障害発生時の緊急対応体制の確認 （３）システム障害発生時の緊急対応体制の確認 （４）セキュリティ対策 （４）セキュリティ対策 （５）組織体制の確立 （５）組織体制の確立 ※質問項目詳細については、【参考資料】緊急点検項目を参照 ※質問項目詳細については、【参考資料】緊急点検項目を参照 ■回答企業全体の実施状況 0% 10% 20% (1-1) 回答企業全体（１３３件）では、３つの点検項目を除いて、残り 全ての点検項目において、８０％以上の企業が、「１．具体的 かつ十分なレベルで実施している。」及び「２．重要性を認識し ており、一般的な取組レベルで実施している。」と回答。 上記の実施率が８０％を下回る点検項目は以下の３つ。（そ れぞれ７５％、６９％、７８％） 「（２−２）上記評価に基づく、信頼性・安全性の水準及 び目標とする品質基準等の設定状況。また、設定した 品質基準等に関しての情報システム利用者及び供給 者間での合意。」 「（４−１）「事業継続計画策定ガイドライン」を踏まえた 事業継続計画（BCP：Business Continuity Plan）の策 定状況。」 「（５−３）企画・開発及び保守・運用段階全体における 各局面において、品質保証部門及び技術専門部門等、 情報システム関係者から見て第三者（専門家、部門、 企業・機関等）によるレビュー及びシステム監査の実 施状況。」 (1-3) 8 02 9 01 76 9 02 18 70 20 66 32 8 11 11 33 53 15 87 55 21 9 53 66 77 １．具体的かつ十分なレベルで実施している ２．重要性を認識しており、一般的な取組レベルで実施している ３．重要性を認識しているが、十分な取組が出来ていない ４．取組を実施していない 無回答 22 6 2 62 34 38 11 72 76 (5-2) 41 66 46 16 31 19 57 (4-2) 7 74 (3-4) 03 66 51 (3-5) 12 75 35 02 30 56 31 01 71 35 (5-3) 101 79 (3-1) 100% 76 30 (3-3) 90% 74 34 (3-2) 80% 66 46 (2-3) (5-4) 70% 52 (2-2) (5-1) 60% 47 (2-1) (4-1) 50% 58 (1-2) (1-5) 40% 65 (1-4) 集計結果 30% 16 16 8 1 10 22 21 3 30 全体：１３３ 【参考資料】緊急点検項目 １．システム移行時又はリリース時の作業の確実な実施 （１−１）システム移行又はリリースの際、システムの業務要件、性能・容量等 の要件及び他システムとの連携など情報システムの安定稼働に影 響を与える要件に対する適合性を確認するためのテスト及びレビュ ー等の実施状況。 （１−２）システム移行又はリリースの際、実運用環境（関連する他の情報シ ステムとの関係、システム運用形態、システム運用スケジュールな ど）の確認状況。 （１−３）実運用環境でのテストの実施状況。 （１−４）検収基準あるいはサービス開始の判定基準等による品質担保措置 の実施状況。 （１−５）システム移行又はリリースの際のリリース手順及び問題発生時の対 応手順・マニュアルの作成状況。更に、これらマニュアル類に基づく 教育訓練など現場への周知徹底の状況。 （３−３）情報システム障害の内容、影響（大きさ、範囲、継続期間、二次三次 の関連障害の可能性等）及びその原因等に関する情報の情報シス テム利用者及び供給者、経営層まで含めた周知の状況。 （３−４）情報システム障害発生に関する報告・記録の手順とこれを共有する 仕組みの整備状況。 （３−５）各種障害に対して発生時の業務・サービスへの影響の防止及び最 小化のための取組状況。（バックアップシステムの整備、システム構 成要素や機能の二重化・多重化など技術的取組、及び人的資源の 投入等による代替手段の確保状況など。） ４．セキュリティ対策 （４−１）「事業継続計画策定ガイドライン」を踏まえた事業継続計画（BCP： Business Continuity Plan）の策定状況。 （４−２）「情報セキュリティマネジメントシステム（ISMS）適合性評価認証制度 」に基づく認証の取得、情報セキュリティ監査、情報セキュリティ対策 ベンチマークの実施状況。 ２．システムの信頼性・安全性水準の確認 （２−１）情報システムに関して発生の可能性のある潜在的な危険要素の洗 い出しと分析・評価（リスク分析・評価）の実施状況。 （２−２）上記評価に基づく、信頼性・安全性の水準及び目標とする品質基準 等の設定状況。また、設定した品質基準等に関しての情報システム 利用者及び供給者間での合意状況。 （２−３）システムライフサイクル全体を通じて、業務を取り巻く環境の変化及 び技術的問題（機能、性能、容量、拡張等）に関するリスク管理の実 施状況。 ３．システム障害発生時の緊急対応体制の確認 （３−１）情報システム障害発生時の経営層まで含めた指揮命令系統及び影 響度に応じた対応手順の周知徹底の状況。 （３−２）情報システム障害発生時の対応に対する教育・訓練の実施状況。 ５．組織体制の確立 （５−１）情報システム利用者及び供給者における、保守・運用に係る活動全 般について双方の推進体制（指揮命令系統、役割分担、責任権限 等）と業務フローの共有状況。 （５−２）事業部門から独立し、品質基準・開発標準・管理標準類の整備及び 品質監査・システム監査・プロジェクト監査等の機能を持つ品質保証 部門の設置状況。 （５−３）企画・開発及び保守・運用段階全体における各局面において、品質 保証部門及び技術専門部門等、情報システム関係者から見て第三 者（専門家、部門、企業・機関等）によるレビュー及びシステム監査 の実施状況。 （５−４）人に起因する情報システムの障害を防止するための、適切な知識及 びスキルを備えた人材の配置等の実施状況。