PowerPoint版 Chapter1（PowerPoint形式：4848KB）

Download Report

Transcript PowerPoint版 Chapter1（PowerPoint形式：4848KB） 

第1章 全体概要
本章では、モデル取引・契約書の作成に至った経緯・
目的について解説します。
システム基本契約書、重要事項説明書、
別紙1・2、モデルドキュメントを
手元に用意してください。
はじめに
(1)
2
 情報システムは、私たちの生活に深く浸透しています。銀行やコンビニエン
スストアのATM、鉄道や航空会社の予約システム、インターネットを通じた
株式取引や通信販売など、情報システムは、豊かな生活と便利な社会を作
るために必要な社会インフラになったと言ってよいでしょう。
 しかし、ひとたび情報システムにトラブルが起きれば、個人、企業を問わず、
様々な弊害を招く社会になったと言う事もできます。オンラインシステムや
決済システムの不具合だけでなく、企業システムのトラブルは、企業活動に
深刻な打撃を与えます。金銭的な損害はもとより、顧客の信頼を損ねたり、
企業活動の停滞を招きかねません。
 情報システムの信頼性の向上は、社会的な要望であり、私たち情報サービ
ス産業に従事するものにとっての使命とも言える重要な課題になっていま
す。
はじめに
(2)
3
 2005年秋、東京証券取引所のシステムトラブルに端を発し、わが国の情報
システムは信頼性、安定性に欠けるのではないか、という批判が国際社会
からも巻き起こりました。
 そこで、日本の産業構造の問題点を検討する経済産業省産業構造審議会
は、こうした情報システムの信頼性について強い危惧を抱き、「情報システ
ムの信頼性向上のためのガイドライン」を2006年4月に発表しました。
 ガイドラインは、①契約における重要事項の明確化、②情報システム構築
の分業時の役割分担及び責任関係の明確化を指摘し、ユーザ団体と業界
団体が協力して標準的な契約のあり方を検討するように求めました。
 そこで、2007年4月に経済産業省「情報システム・モデル取引・契約書＜第
一版＞」が策定され、公表されました。＜第一版＞は、社会インフラ・大企
業基幹システムの受託開発を対象に、対等の交渉力を有するユーザとベン
ダを想定して策定されています。
はじめに
(3)
4
 しかし、ITや契約・法務に詳しい人材がいない中小・中堅企業にとっては、高
度化・複雑化する情報技術を利用した業務システムを導入することは決して
容易なことではありません。
 また、中小・中堅企業の多くは、システム導入にあたってパッケージソフト
ウェアを中核に、モディファイ、アドオン開発を行うのが一般的です。業務に
よっては、パッケージソフトウェアを変更せず業務形態を改善する導入方法
も多数、見受けられます。
 こうした、ITや契約・法務の専門家を配置できない中小・中堅企業、学校、病
院、地方自治体、公的機関を対象に、パッケージソフトウェアを活用したシス
テム構築のための判りやすい契約書の策定が求められました。
 2008年4月にモデル取引・契約書＜追補版＞が策定され、中小企業の取引
の多数を占めるパッケージソフトウェアを活用した業務システムを想定し、対
等の交渉力を有しないユーザとベンダのための契約書が公表されました。
情報システム
取引の特徴
5
 情報システム取引は様々な業務の集合体
 情報システム取引は、業務分析などのコンサルティング業務から、プログラム制
作などの知識集約型の専門業務、保守、運用などのサービス業務と、まったく
性質の異なる取引が、積み重なった複合取引です。それぞれの業務は、深い専
門性と変化が激しいという特徴があります。
 ユーザの興味と価値観
 ユーザは、ITの専門性や、難易度について興味を持っている訳ではありません。
 ITを含めた業務システム全体が正しく運用され、その結果として、仕事の負荷
が減ったり、無駄なコストが削減されることを価値として認めています。そして、
雇用を守り、利益を出し、成長していく事がもっとも重要なことなのです。あくま
でITやコンピュータシステムは、その手段でしかありません。
ユーザとの関係
6
 情報システムのプロとして Win-Winの関係作り
 私たちは、情報システムに携わるプロフェッショナルとして、ユーザの期
待に正しく応え、その結果として利益を上げなくてはなりません。
 そして、プロフェッショナルとしての知見を高め、より高度なソリューショ
ンを提供し続けなければなりません。
 ユーザの視線と期待
 ユーザは情報システムの専門家ではなく、かつ、情報システム取引の
経験が豊富な訳ではありません。
 情報システムに関連する業務に従事している私たちは、ユーザからみ
れば、ITやコンピュータシステムの専門家です。
 病気にかかれば医師に、税金で判らない事があれば税理士に相談す
るように、ユーザは、ITについて専門家である私たちの助言や、手助け
を必要としています。
7
情報システム
取引の課題
 情報の量
 私たちは、日常生活で買い物をする際に、様々な知識や経験を活かして買い物を
しています。例えば、「事務用のボールペンを買う」という事は難しい事ではありま
せん。
 では、「仕事用のパソコンを買う」という場合は、どうでしょうか？
私たちは、日常の業務の中でパソコンの販売やシステムの構築を通じて、様々な
専門知識を有しており、「仕事用のパソコンを買う」ことについて、必要な条件や問
題を検討する事が可能です。CPUの性能、メモリの容量、OS、アプリケーション、
通信環境、デザイン、セキュリティ、そしてこれらの機能に対する価格の妥当性は、
比較的簡単に決める事ができるでしょう。
 一方で、中小企業のユーザにとって、「仕事用のパソコンを買う」という行為は、決
して簡単なものではありません。自分の業務に適合するノートパソコンの要件をま
とめ、価格の妥当性を検討するための、知識と情報量が圧倒的に少ないのです。
?
?!
情報システム
取引の課題
8
 情報の非対称性
 専門的な知識と情報量が少ないという事は、何が妥当かという判断基準を持っ
ていない、と言い換える事ができます。判断基準が無ければ、要件の優先順位
をつける事も困難ですし、価格が適正であるかも判断しにくいと言えます。
 こうした、情報システムに関わる専門的な知識と情報量は、私たちベンダとユー
ザに大きな違いがあります。
 専門家としての説明責任義務
 知識を豊富に持つ専門家として私たちは、ユーザとの間にある知識や情報の溝
を埋めていかなくてはなりません。専門家として分かりやすい説明をする責任義
務があるのです。
 情報ギャップのない正しい契約
 こうしたことから、ユーザとベンダの思い違いや、ボタンの掛け違いが起きない
正しい契約が求められています。
 ベンダの説明責任を果たすためにも、取引の可視化、重要事項や互いの責任
が明らかとなるモデル取引・契約書を活用した取引が望まれています。
9
第一版策定の
経緯
 「情報システムの信頼性向上に関するガイドライン」で、契約書の策定が指摘され、
2007年4月「情報システム・モデル取引・契約書＜第一版＞」が公表されました。
2005年秋
2006年6月
証券取引所におけるシステム障害など、社会インフラを担
う情報システムの障害が我が国の経済活動に大きな影響
情報システムの信頼性向上に関する
ガイドラインの策定
情報サービス・ソフトウェア産業維新
2006年9月
■モデル契約の策定・活用
情報システム利用者団体及び情報システム供給
者団体は、協力して本ガイドラインの考え方を反
映した標準的な契約のあり方を検討する。
2007年4月
産業構造審議会情報サービス・
ソフトウェア小委員会
■「ユーザ・ベンダ間の取引関係・役割分担」の可視化
情報システムベンダと情報システムユーザの間で協同
してモデル契約・契約プロセスを策定する。
モデル取引・契約書（第一版）http://www.meti.go.jp/policy/it_policy/keiyaku/index.html
 対象：
社会インフラ、大企業基幹系のウォーターフォール型の受託開発
対等の交渉力を有するユーザとベンダ、共通フレーム2007準拠
一括発注、マルチベンダ、工程分割発注に対応
10
追補版策定の
経緯
 第一版では「中小企業・パッケージ活用型のモデル取引・契約書」の検討が指摘さ
れ、第一版をベースに2008年4月に「追補版」として策定・公表されました。
2007年4月
モデル取引・契約書（第一版）
http://www.meti.go.jp/policy/it_policy/keiyaku/index.html
■今後の検討課題（第一版）
経済産業省は、研究会で策定されたモデル契約プロセス、モデル契約書、モデルドキュメントの定
期的な見直しを行う。また、保守・運用プロセスの体系化を踏まえた保守・運用サービスのモデル
取引・契約書、パッケージ活用型開発の契約のあり方、中小企業ユーザとの契約のあり方、ソフト
ウェアモジュールの再利用を促進する契約のあり方及びパフォーマンスベース契約等の多様な契
約のあり方についても検討を行う。
2008年4月
モデル取引・契約書（追補版）
～重要事項を中心とした中小企業の取引の多数を占めるパッケージ活用型のモデル取引・契約書～
 対象：
パッケージ/SaaS/ASP活用、カスタマイズ、オプション
ITの専門知識を有しないユーザと、業として情報サービスを提供するベンダ
共通フレーム2007準拠、一括発注、マルチベンダ、工程分割発注に対応
追補版の役割
(1)
11
 ユーザとベンダの理想的かつ実践的なモデルを提示したもので、パッケー
ジソフトウェアを活用した情報システム構築において、ユーザとベンダが相
互に参照し、円滑な取引のためのガイドライン的な役割も果たします。
 追補版の前提条件
 「中小企業」を従業員数、資本金の大小ではなく、「ベンダと対等の交渉力を有
しない」、ITや情報システム取引・法務の専門家、専従者を設置することの困難
な団体、法人、企業としました。
 「パッケージソフトウェア」「SaaS/ASP」は、特定の業種または業務を想定し、そ
の中で汎用的に使用されることを前提とした市販ソフトウェアとしました。パッ
ケージソフトウェアの使用許諾契約、保守契約は、ユーザとパッケージソフトウェ
アメーカーとの間で交わされるものとしています。
 信頼性の高い情報システム構築には、ユーザとベンダの緊密な協力が必要で
す。ユーザ自身が役割を理解し、ベンダと緊密な協働を行なうものとしています。
 ベンダは、業として情報サービスを提供する専門家としての十分な配慮と注意
を払う必要と一定の責任があります。
ベンダは専門家として、コンサルティング・エンジニアリング能力は当然のこと、
ユーザ業務に精通する努力、最新テクノロジーを平易に説明する能力、プロ
ジェクトマネジメントや品質管理能力の強化に留意しているものとしています。
追補版の役割
(2)
12
 モデル取引・契約書第一版が示した、デューデリジェンス、契約締結、品質
管理手続きに至る取引ルールと国際取引慣行との整合性、多段階契約、
再見積の考え方を踏襲しています。
 ユーザの「ベンダ丸投げ」を排除するため、上流工程から保守に至る取引
の透明性を確保しています。
 要件定義、パッケージソフトウェアの選定、カスタマイズ開発の有無、データ
移行、運用、保守、要員教育を含めたパッケージソフトウェア活用のシステ
ム構築を想定し構成しています。
 企業規模を問わず、IT、法務の専門家以外でも、情報システム取引の内容
を正確に理解でき使いやすい契約書、重要事項説明書、ユーザ、ベンダが
相互に利用できるチェックリストを用意しました。
注意：＜追補版＞が対象とならない業務
中小・中堅企業が、パッケージを利用せず、ゼロから独自システムを構築する際の、企画・
開発等を委託する業務には、＜追補版＞は適合しません。第一版を参考に、IT法務に詳し
い弁護士の助言を得て策定することをお勧めします。
＜追補版＞の
内容・成果物(1)


モデル取引・契約書追補版は、モデル契約書、契約書に関連するモデルド
キュメントと業務の進捗や内容を確認するためのチェックリストで構成され
ています。
モデル契約書
契約書の本体です。以下の2つの契約書を必ずペアで利用します。




13
パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書（シス
テム基本契約書）
重要事項説明書
システム基本契約書は秘密保持や個人情報などの一般的な規程をまとめ
ています。
重要事項説明書は、要件定義から開発、保守、運用支援など、個々の業
務の実態に即した規程を定めた契約書です。
＜追補版＞の
内容・成果物(2)

14
モデルドキュメント
議事録や検収依頼書のひな形です。個別契約書に記載されている事項を
網羅しています。





（議事録、変更規程用）
プロジェクト連絡協議会議事録、設定等合意書
（準委任契約用）
業務完了報告書兼検収依頼書（ベンダ→ユーザ）
業務完了確認書兼検収書（ユーザ→ベンダ）
（外部設計支援業務契約用）
業務完了報告書兼外部設計書承認依頼書（ベンダ→ユーザ）
業務完了確認書兼外部設計書承認書（ユーザ→ベンダ）
（構築・設定業務契約用）
システム構築・設定業務完了報告書兼検収依頼書（ベンダ→ユーザ）
検査合格通知書兼検収書（ユーザ→ベンダ）
（ソフトウェア設計・制作業務契約用）
納品書兼検収依頼書（ベンダ→ユーザ）
検査合格通知書兼検収書（ユーザ→ベンダ）
＜追補版＞の
内容・成果物(3)

15
チェックリスト
システム取引に不慣れなユーザのために、業務の内容や進捗状況を確認
するためのチェックリストです。
 コンサルティング会社選定のためのチェックリスト
 提案依頼書(RFP)のチェックリスト
 業務システム仕様書の記述レベル（JUAS）
 ユーザIT成熟度チェックリスト
 パッケージソフトウェア選定のためのチェックリスト
 SaaS/ASP選定のためのチェックリスト
 検収事前チェックリスト
 検収チェックリスト
 セキュリティチェックシート 一般版

セキュリティチェックシート Webアプリケーション版

SaaS向けSLAにおけるサービスレベル項目のモデルケース
情報システム取引の勘
所
上流工程(1)
16
 上流工程の重要ポイント
 情報システム取引では、「情報システムはどうあるべきか」、「情報システムに備
えるべき機能や性能は何か」という「要件定義」が、最も重要なポイントと言えま
す。「共通フレーム2007」では、要件定義を次のように解説しています。
 要件定義
 新たに構築する（あるいは再構築する）業務、システムの仕様を明確化し、それ
をベースにIT化範囲とその機能を具体的に明示すること。
 関連する組織およびシステムに対する制約条件を明確にし、定義された内容に
ついて取得者側の利害関係者間で合意することである。
 言い換えれば以下のようにまとめることができます。
①業務の流れ（人・モノ・金・データ）の動きを明確化して、②その中でIT
化すべき範囲と、③ITで実現される各種機能・性能を、④具体的に分か
りやすく文書化する、⑤「ITで出来ること、出来ないこと」「人が作業する
こと」「例外的な措置」などをまとめ、⑥それらをユーザ関係者全員が理
解し納得すること。
情報システム取引の勘
所
上流工程(2)
17
 ユーザは上流工程に不慣れ
 本来、要件定義はユーザの責任です。しかし、情報システム構築に不慣れな
ユーザは、コンピュータシステムを導入してしまえば「何もかもが自動化され人
は煩わしい業務からすべて解放される」と考えがちです。また、コンピュータシス
テムは「何でもできる」、「素早くできる」という漠然とした期待があります。
 また、ユーザは「こうしてほしい」、「こんな風に」という漠然とした要望はあっても、
具体的にシステムの仕様を明確化したり、IT化の範囲を設定することはできま
せん。さらに、仕様変更がコストや納期に及ぼす影響について知識がありませ
ん。
 要件定義はもっとも重要
 要件定義が完成しないと、①適合性の高いパッケージソフトウェアの選定ができ
ない、②カスタマイズが発生する際の、設計・開発以降の費用見積や納期算定
が正確にできない、③設計・開発工程で大幅な仕様変更が発生する可能性が
高まる、などの問題を引き起こします。
 コスト、納期、信頼性を確保するためには、要件定義をしっかり行なうことがもっ
とも重要です。
情報システム取引の勘
所
上流工程(3)
18
 要件定義を担当するベンダの責任
 要件定義を担当するベンダは、設計・開発以降のすべての工程、作業に対して




も、重大な責任を負っています。
ベンダは、ユーザに対して上流工程の作業が設計・開発以降のすべての工程
に影響を及ぼす重要性とその責任を説明し、ユーザの理解を得なければなりま
せん。
誰が・何を・どのようにして・いつまでに・決定するかをユーザとあらかじめ取り
決めて、作業実施にあたる必要があります。
定期的なミーティングを実施し進捗を報告するとともに、その都度、議事録を作
成し、ユーザの承認を得なければなりません。
ベンダは、要件定義に関してユーザが正しい判断を行うための材料を、業界の
一般的な知識、ノウハウをもとに提供しなければなりません。
情報システム取引の勘所
上流工程(4)
19
 ユーザの責任
 ユーザはパッケージの選定や仕様の最終決定に責任を負います。ベンダにす




べてを委ねるのではなく、ベンダと一緒に自社のシステムを構築しなければなり
ません。
要件定義は現状の業務フローの見直しであり、業務合理化のチャンスです。反
面、現場の作業は大幅な変更が求められたり、負担が増える場合もあります。
担当者のみならず、システムに関わる利害関係者の参加と調整が必須です。
不明な点や、判らない用語をそのままにせず、納得のいく説明を求めるとともに、
決定事項、未決事項などをまとめた議事録を点検、承認し、プロジェクトの進行
に努めなければなりません。
要件定義後の仕様変更は、①選定したパッケージが使えなくなる、②カスタマイ
ズ工数に多大な影響を及ぼす、③信頼性の低下の原因になる、などの悪影響
があり、納期の延長や増大する費用の負担をしなければなりません。
このため、要件定義の最終決定に際しては、未決事項の先送りを避けるととも
に、社内の利害関係者の十分な合意を得ておかなければなりません。
モデル取引の
企画・要件定
義
プロセス
＜追補版＞では、パッケージソフトウェアを活用したシステム導入の＜取引・契約モデルの全体像
＞を想定し、上流工程の作業内容を定めました。全体像をユーザ、ベンダが共有することで、実
際に何をなすべきか、何を決めなければならないかが明らかになり、実際の作業に対する理解が
深まります。他方、既存システムとの密結合があるERP導入と、小規模な会計システム導入では、
上流工程の作業内容が異なるため、 ＜取引・契約モデルの全体像＞は規模、目的によって別紙
1・2の2つのモデルに分けています。下図は別紙1の上流工程をクローズアップしたものです。
20
A 要件定義支援及びパッケージ
ソフトウェア候補選定支援契約
(1) 事業要件定義
(8) ベンダに対しパッケージ候補選
定のための情報提供依頼 (RFI)
(15) パッケージ候補の
システム要件評価
(16) APIの実現性の確認（候補
(2) プロジェクトゴールの策定
(3) 要求品質の明確化
(4) パッケージを利用し実現する
業務の新全体像の作成
(5) ベンダに対しシステム、パッ
ケージ等の情報提供要求、試算
見積依頼(RFI)
(6) ユーザに対しRFIに基づくシ
ステム、パッケージ等の情報の
提供、試算見積の提示
(9) ユーザに対しRFIに基づくパッ
ケージ関連情報の提供、概算見積
の提示
(10) パッケージの機能要件、非機
能要件、使用許諾契約（利用条件、
保守等）の検討
(11) パッケージ候補の選定
(12) 業務要件及び適合するパッ
ケージ候補の報告書の提出
(13) 受入れ
(7) 業務要件定義
Bパッケージソフトウェア選定支援
及び要件定義支援契約
パッケージのAPI、既存システムとの接
続性等の評価）
(17) パッケージソフトウェアの
選定と要件定義
システム要件定義と評価
(18) 受入れ
D 外部設計支援契約
(19) ベンダへの見積要求
(20) ユーザへの見積提出
E ソフトウェア設計・制作契約
F 構築・設定業務契約
G データ移行支援契約
H 運用テスト支援契約
I 導入教育支援契約
(14) 使用許諾によってはパッケー
ジ、OS、ハードの導入及び保守の
開始（一部保守開始）
J 保守契約
K 運用支援契約
情報システム取引の勘
所設計・開発・移行(1)
21
 開発・設計・構築の重要ポイント
 一旦、設計・開発業務がスタートすると、仕様変更や新たな要望追加はコス
トや納期に多大な影響を与え、トラブル発生の原因になります。
■要件定義の合意不足
×検収段階で「こんなつもりではなかった」、「使い勝手が悪い」などのクレームが出た
○要件定義は、ユーザとベンダだけでなく、ユーザの利用者全員の合意が重要です。
■要件抽出の不足
×設計のために詳細な打ち合わせを実施したら、大幅な変更と新たな要望が追加された
○要件の変更、追加については、事前に費用、納期の見直しを定めておくことが重要です。
■記述レベルのばらつき
×一般的な作業量で見積もったが、実際の作業量は格段に多くコストが増大した
○要件定義の内容をユーザ、ベンダ双方でしっかりと確認することが重要です。
情報システム取引の勘
所設計・開発・移行(2)
22
 トラブルを未然に防ぐ
 設計・開発以降のトラブルの原因の大半は、作業着手前に解決できることと
いっても過言ではないでしょう。しかし、一旦、契約を交わしてしまうとベンダに
はシステムを完成させる責任が発生します。
 RFP（Request For Proposal：提案依頼書、見積依頼書）を入手したら、疑問点
や不明な点をとりまとめ、ユーザに疑義解消を求めます。要件定義が曖昧だっ
たり、不正確と思われる場合は、ユーザにその旨を報告し、要件定義を行った
ベンダを交えて打ち合わせを行い、疑義解消に努める必要があります。
 ユーザは上流工程を担当したベンダの協力を得て、設計・開発・構築を担当す
るベンダにRFPを説明する責任があります。
 RFPの提示から見積・提案書提出の期間が短い場合、ベンダ側の検討が不十
分なまま見切り発車的に見積が提出される可能性があります。予算執行やプロ
ジェクトゴールの都合を優先するなどのしわ寄せは、後工程の信頼性に大きく
影響を及ぼします。
情報システム取引の勘
所設計・開発・移行(3)
23
 設計・開発・移行を担当するベンダの責任
 ベンダは設計・開発・移行を請け負った以上、見積通りに完成し、納品
する義務があります。（完成義務）
 何をもって完成とするかを明らかにするためにも、設計・開発に着手す
る前に、要件定義書の疑義は解消して契約にあたらなければなりませ
ん。
 要件定義書の疑義解消がユーザだけで困難と思われる場合は、ユー
ザに要請して、要件定義を実施したベンダに質問し、問題点の改善を求
める必要があります。
 仕様の変更や追加は、納期、費用に重大な影響を及ぼします。口頭で
の合意は避け、必ず、文書化しなければなりません。
 ミーティングの議事録の作成と報告承認を得なければなりません。
情報システム取引の勘
所設計・開発・移行(4)
24
 ユーザの責任
 要件定義書の決定者はユーザであることから、要件定義に疑義がある
場合は、要件定義を担当したベンダとともにその解消に努めなければ
なりません。
 万一、要件の変更を行なう場合は必要最小限に止めるとともに、再見
積に伴う費用の追加や、納期の延長を受入れなければなりません。
 未決事項がある場合は、その費用、納期の取扱いについて、ベンダと
事前に十分な合意をする必要があります。
 不明な点や、判らない用語をそのままにせず、納得のいく説明を求める
とともに、決定事項、未決事項などをまとめた議事録を点検、承認し、プ
ロジェクトの進行に努めなければなりません。
まとめ
25
 情報システムの社会的重要性と責任は極めて重大になっています。
 そのために、経済産業省は情報システムの信頼性確保の観点から、責任
の所在と重要事項が明らかになる契約書策定に取り組み、モデル契約書
＜第一版＞＜追補版＞を公表ました。
 情報システム構築は、専門性の異なる業務の集合であり、また、ユーザと
ベンダは情報量が大きく異なります。
 ユーザとベンダは協働してシステム構築にあたらなくてはなりません。
 ユーザは業務の専門家として、ベンダはITの専門家の立場で業務に当たる
責任があります。
 パッケージソフトウェアを選定にあたる前の「要件定義」が重要です。
 モデル契約書は、ユーザとベンダが協働して、しっかりとした「要件定義」を
策定することを重要視しています。
26
以上で第1章の解説は終了です。
eラーニングメニューに戻り 「第１章のセルフチェック」を選択して、
理解度の確認テストを受けてください。