情報システム・モデル取引・契約書(追補版)は情報システム・モデル取引・契約書の簡易版。
情報システム発注に慣れていないユーザと契約を結ぶ場合にかなり使いやすいものになっている。
元々の情報システム・モデル取引・契約書は対象とするユーザが情報システム発注に関して高度な知識やノウハウを持っていることを前提としている。しかし、そこまでの知識を持っているユーザは大企業ぐらいしかあり得ない。
そして、中小企業が情報システムを必要とする状況がますます増える中、モデル契約書が使える状況を拡大するために追補版が作成された模様。
追補版の前提
追補版では以下の前提に基いてモデル契約書を作ってある。
- 契約当事者:ITの専門知識を有しないユーザと業として情報サービスを提供するベンダを想定。
(例) 委託者(ユーザ):民間中小・中堅企業、地方自治体、独立行政法人等、
受託者(ベンダ):情報サービス企業(SIer、ソフト会社、ITコーディネータ等)。 - パッケージソフトウェアについては、ユーザとパッケージソフトウェア製造会社で使用許諾契約、保守契約を別途締結。
- 開発モデル:パッケージ+カスタマイズ型、パッケージ+オプション型。
*モデル取引・契約書第一版「2.(7)パッケージ活用、反復繰り返し型の開発、中小企業等ユーザにおける活用の留意点」を基に、新たに策定したモデル。 - 対象システム:財務会計システム、販売管理システム、電子メール、グループウェア、Webシステム等の導入、構築・設定、カスタマイズ開発、移行、教育、保守、運用支援。
- 対象モデル:パッケージソフトウェアモデル、SaaS/ASPモデル。
- プロセス:共通フレーム2007に準拠したシステムの企画、要件定義段階、開発段階、運用段階、保守段階の定義及びその修正。
- 一括発注の場合に加え、マルチベンダ形態、工程分割発注に対応。
想定するユーザ
ITの専門知識を有しないユーザの具体的な想定は以下のとおり。
一般的な中小企業の実情にかなり近いと思う。
- LAN+Internetへの接続はできており、日常的に電子メール、財務会計、販売管理等のパッケージソフトウェアを利用している。
- 最新の情報システム関連動向、パッケージソフトウェア関連動向は把握しておらず、システムの価格や妥当性を正確に評価することができる人材を有していない。
- 情報システム資産の管理はなされておらず、情報システムに関連するドキュメントは整備されていない。
- 取引上、相手先の機密情報や個人情報を取り扱う場合があるが、セキュリティ確保のための措置はとれていない。
- 競争優位のための情報システムの役割を自ら構想することは困難である。
- バックアップや保守体制の確立、システムライフサイクルの認識などが事業継続に多大な影響があるとは承知していない。
- システム構築の検討に入る場合の多くは、システムの老朽化や処理能力への不満である。
- 法務に精通した担当者が不在である。
- IT精通した担当者が不在である。
追補版の概要
- 情報システム・モデル取引・契約書の思想を踏襲している。
- ユーザがわかりやすいように書式や条文が見直されている。
- 契約は基本契約+重要事項説明書の組み合わせ(契約モデル)に対して行う。
- パッケージカスタマイズ 取引・契約モデル: パッケージソフトウェアを変更したりアドオンを開発したりする場合
- パッケージオプション 取引・契約モデル: パッケージソフトウェアのモディファイやアドオンがない場合
- 重要事項説明書は具体的な作業に対応していて、作業のインプット/アウトプットも規定しているため使いやすそう。
- ユーザが利用できる以下のチェックリストが付いている。
- コンサルティング会社選定のためのチェックリスト
- 提案依頼書(RFP)のチェックリスト
- 業務システム仕様書の記述レベル
- ユーザIT成熟度チェックリスト
- パッケージソフトウェア選定のためのチェックリスト
- SaaS/ASP選定のためのチェックリスト
- 検収事前チェックリスト
- 検収チェックリスト
- セキュリティチェックシート 一般版(上位概念)
- セキュリティチェックシート Webアプリケーション版
- SaaS向けSLAにおけるサービスレベル項目のモデルケース
- 契約遂行用に以下の業務関連サンプルドキュメントが付いている。
- プロジェクト連絡協議会議事録
- 設定等合意書
- 業務完了報告書兼検収依頼書
- 業務完了確認書兼検収書
- 業務完了報告書兼外部設計書承認依頼書
- 業務完了確認書兼外部設計書承認書
- システム構築・設定業務完了報告書兼検収依頼書
- 検査合格通知書兼検収書(構築・設定業務契約)
- 納品書兼検収依頼書
- 検査合格通知書兼検収書(ソフトウェア設計・制作業務契約)
- 著作権は原則ベンダ側の帰属になっている。
- 再委託はモデル取引・契約書第一版第7条 【B案】(ベンダの裁量で決定)を採用している。
- ベンダがプロ意識と誠意を持って取引に当たることを義務としている。
パッケージカスタマイズ 取引・契約モデル
(パッケージソフトウェアを変更したりアドオンを開発したりする場合)
共通フレーム2007 | 取引・契約モデルのフェーズ | 重要事項説明書 |
---|---|---|
1.4 企画プロセス システム化の方向性 システム化計画 |
(1)事業要件定義 (2)プロジェクトゴールの策定 (3)要求品質の明確化 (4)パッケージソフトウェアを利用し実現する業務の新全体像の作成(1.4.2.6~1.4.3.7該当) (5)パッケージソフトウェアベンダに対してシステム、パッケージソフトウェア等の情報提供要求、試算見積依頼(RFI) (6)ユーザに対しRFIに基づくシステム、パッケージソフトウェア等の情報の提供、試算見積の提示 |
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約(カスタマイズモデル) |
1.5 要件定義プロセス 要件定義 |
(8)ベンダに対しパッケージソフトウェア候補選定のための情報提供依頼(RFI) (9)ユーザに対しRFIに基づくパッケージソフトウェア関連情報の提供、概算見積の提示 (10)パッケージソフトウェアの機能要件、非機能要件、使用許諾契約(利用条件、保守等) 、SaaS/ASPにおいてはSLAの検討 (11)パッケージソフトウェア候補の選定 (12)業務要件及び適合するパッケージソフトウェア候補の報告書の提出 (13)受入れ |
|
(14)使用許諾によってはパッケージ、OS、ハードの導入及び保守の開始 (15)パッケージ候補のシステム要件評価 (16)APIの実現性の確認(候補パッケージのAPI、既存システムとの接続性等の評価) (17)パッケージソフトウェアの選定と要件定義、システム要件定義と評価 |
B パッケージソフトウェア選定支援及び要件定義支援業務契約(カスタマイズモデル) | |
1.6 開発プロセス システム要件定義 システム方式設計 ソフトウェア要件定義 ソフトウェア方式設計 |
(21)使用許諾によってはパッケージソフトウェア、OS、ハードウェアの導入及び保守の開始 (22)モディファイの範囲、アドオン等の外部設計範囲の確定、及びそれに伴うユーザI/F・他システムI/F設計 (23)外部設計書の承認(受入れ) |
D 外部設計支援業務契約 |
1.6 開発プロセス ソフトウェア詳細設計、ソフトウェアコード作成及びテスト、ソフトウェア結合、システム結合、システム適格性確認テスト、ソフトウェア導入、受け入れ支援 |
(25)ソフトウェア設計 (26)モディファイ、アドオンの設計、プログラミング、ソフトウェアテスト (27)適格性確認テスト、監査、ソフトウェア導入 (28)納品 (29)検収(受入れ) |
E ソフトウェア設計・制作業務契約 |
(30)構築・設定業務(機器・OS等の設定、納品) (31)システム結合、テスト (32)検収(受入れ) |
F 構築・設定業務契約 | |
1.7 運用プロセス 業務及びシステムの移行 運用テスト 利用者教育 |
(33)データ移行 (34)完了報告(受け入れ) |
G データ移行支援業務契約 |
(35)運用に関わる作業手順の確立 (36)運用テスト (37)完了報告(受け入れ) |
H 運用テスト支援業務契約 | |
(38)利用者導入教育 (39)完了報告(受け入れ) |
I 導入教育支援契約 | |
1.8 保守 問題把握及び修正分析、修正の実施、保守レビュー及び受入れ |
(41)ハードウェア保守、カスタマイズ部分保守開始 | J 保守業務契約 |
1.7 運用プロセス 業務運用と利用者支援 |
(42)運用支援 | K 運用支援業務契約 |
パッケージオプション 取引・契約モデル
(パッケージソフトウェアのモディファイやアドオンがない場合)
共通フレーム2007 | 取引・契約モデルのフェーズ | 重要事項説明書 |
---|---|---|
1.4 企画プロセス システム化の方向性 システム化計画 |
(1)事業要件定義 (2)プロジェクトゴールの策定 (3)要求品質の明確化 (4)パッケージソフトウェアを利用し実現する業務の新全体像の作成(1.4.2.6~1.4.3.7該当) (5)パッケージベンダに対してシステム、パッケージソフトウェア等の情報提供要求、試算見積依頼(RFI) (6)ユーザに対しRFIに基づくシステム、パッケージソフトウェア等の情報の提供、試算見積の提示 |
C パッケージソフトウェア選定支援及び要件定義支援業務契約(オプションモデル) |
1.5 要件定義プロセス 要件定義 |
(7)業務要件定義 (10)パッケージソフトウェアの機能要件、非機能要件、使用許諾契約(利用条件、保守等) 、SaaS/ASPにおいてはSLAの検討 (11)パッケージソフトウェア候補の選定 |
|
(14)使用許諾によってはパッケージソフトウェア、OS、ハードウェアの導入及び保守の開始 (15)パッケージ候補のシステム要件評価 (16)API実現性の確認(候補パッケージのAPI、既存システムとの接続性等の評価) (17)パッケージソフトウェアの選定と要件定義、システム要件定義と評価 |
||
(以降はパッケージカスタマイズ 取引・契約モデルと同じ) |
0件のコメント