「CSAJ/JCSSA 情報システムの信頼性向上のための取引慣行・契約に関する検討委員会」〜情報システムの取引慣行・契約に関する実施ガイド〜＜保守・運用に関するガイドライン＞

社団法人コンピュータソフトウェア協会（CSAJ）
社団法人日本コンピュータシステム販売店協会（JCSSA）

目 次

1

保守・運用サービスの範囲 .............................................1
1.1
モデル取引・契約書＜第一版＞の範囲 ......................................... 1
1.2
保守運用ワーキング･グループでの討議範囲 ..................................... 2
1.3
保守・運用プロセスの定義 .................................................... 3
1.3.1
運用プロセス ........................................................... 3
1.3.2
保守プロセス ........................................................... 4
1.4
IT サービスマネージメント..................................................... 41.5
保守・運用の管理基準 ....................................................... 52

保守運用の留意事項 .................................................6
2.1
信頼性ガイドラインでの留意事項............................................... 6
2.2
現状の保守運用サービスの問題点と課題........................................ 6
2.3
組織・体制の明確化 ......................................................... 7
2.4
曖昧な契約の排除 .......................................................... 7
2.4.1
契約内容の明確化 ...................................................... 8
2.4.2
コミュニケーションの向上 ................................................. 82.4.3
情報開示（ハードメーカ、ソフトメーカ） ....................................... 8
2.5
セキュリティ・可用性の充実.................................................... 8
2.5.1
セキュリティの重要性 .................................................... 8
2.5.2
バックアップ ............................................................ 9
2.6
ハードウェア保守............................................................ 92.6.1
データ復旧は別メニュー.................................................. 92.6.2
保守対象外部品 ....................................................... 102.6.3
製品寿命や保証期間などの期間管理...................................... 10
2.6.4
事前停止の考慮 ....................................................... 102.6.5
保守機器の管理 ....................................................... 10
2.6.6
ハードウェア保守確認事項............................................... 11
2.7
アプリケーション保守（パッケージソフトウェア） ................................... 11
2.7.1
カスタマイズの定義 ..................................................... 12
2.7.2
フリーソフト及びオープン・ソース・の保守 ................................... 13
2.7.3
保守不能を防止 ....................................................... 13
2.7.4
変更管理の重要性 ..................................................... 14
2.7.5
リリース管理の重要性 ................................................... 14
2.7.6
サポート期間 .......................................................... 14
2.8
繰り返し型開発、アジャイル開発の場合 ........................................ 15
2.9
ＡＳＰ・ＳａａＳモデル ......................................................... 15
2.9.1
通常運用時の保守運用 ................................................. 15
2.9.2
ＳａａＳベンダの選定（保守・運用時） ........................................ 15
2.9.3
内部監査実施状況 ..................................................... 16
2.10
保守タイプと瑕疵との関連 ................................................. 16
2.10.1 脆弱性対策と瑕疵担保責任の区別 ........................................ 17
2.10.2 瑕疵調査費用の取扱い ................................................. 17
2.10.3 事前確認の重要性 ..................................................... 17i

3

ＩＴサービスの現状 ...................................................18
3.1
3.2

4

IT サービスの提供方法の現状................................................ 18
地域企業の求める IT サービス................................................ 18

ユーザ・ベンダの共有すべきガイドライン .................................19
4.1
ＪＩＳ Q 20000 運用保守ガイドライン ............................................ 19
4.2
ＪＩＳ Q 20000 とＩＴサービスの関係 ............................................. 19
4.3
サービスの内容に関する項目 ................................................ 20
4.4
運用面に関する項目 ....................................................... 21
4.5
ＳＬＡ・ＳＬＭに関する項目 ................................................... 21
4.6
ハードウェア保守........................................................... 21
4.6.1
範囲の明確化 ......................................................... 21
4.6.2
ＳＬＡ・ＳＬＭ ........................................................... 22
4.7
アプリケーション保守サービス（パッケージ） ..................................... 22
4.7.1
範囲の明確化 ......................................................... 22
4.7.2
ＳＬＡ・ＳＬＭ ........................................................... 24
4.8
運用支援系（セキュリティ監視サービス） ........................................ 25
4.8.1
範囲の明確化 ......................................................... 25
4.8.2
ＳＬＡ・ＳＬＭ ........................................................... 25
4.9
運用支援系（サーバ運用支援サービス） ........................................ 26
4.9.1
範囲の明確化 ......................................................... 26
4.9.2
ＳＬＡ・ＳＬＭ ........................................................... 26
4.10 ＡＳＰ・ＳａａＳモデル ......................................................... 27
4.10.1 範囲の明確化 ......................................................... 27
4.10.2 ＳＬＡ・ＳＬＭ ........................................................... 27

5

IT サービス仕様書（サンプル） .........................................28
5.1
5.2

6

記載すべき事項 ........................................................... 28「サーバ運用支援サービス」サンプル .......................................... 28

参考資料 ..........................................................30
6.1

参考文献一覧 ............................................................. 30ii

図表 目 次
図 1
図 2
図 3
図 4
図 5
図 6
図 7

情報システム運用保守の範囲図＜第一版＞ ....................................................................1
情報システム保守運用の範囲図＜追補版＞ ....................................................................2
情報システム・レイア別技術 MAP......................................................................................3
共通フレーム２００７（運用プロセス） ...................................................................................4
共通フレーム２００７（保守プロセス） ...................................................................................4システム管理基準..............................................................................................................5
パッケージソフトカスタマイズ分類 ........................................................................... 12

表 1 アウトソーシングサービスの分類........................................................................................1
表 2 JIS X 0161：2008（ソフトウェア保守）...................................................................................4
表 3 情報技術サービスマネージメント（JIS Q 20000-2:2007） ...................................................5
表 4 保守・運用段階における留意事項 ....................................................................................6
表 5 障害対応に関する留意事項..............................................................................................6
表 6 保守運用の留意事項........................................................................................................7
表 7 ハードウェア保守特有の確認事項 .................................................................................. 11
表 8 FOSS の場合の責任範囲の取扱い ................................................................................ 13
表 9 ＳａａＳベンダ選定時のチェックリスト（保守・運用時）......................................................... 15
表 10 保守タイプと瑕疵との関連図 ......................................................................................... 16
表 11 確認時の注意事項 ........................................................................................................ 17
表 12 IT サービス提供形態（保守・運用）................................................................................ 18
表 13 技術者専任・非専任...................................................................................................... 18
表 14 ＩＴサービス業者から受けているサービス（保守・運用系） .............................................. 18
表 15 ＩＴサービスのモデル（保守・運用系サンプル）............................................................... 19
表 16 JIS Q 20000 運用保守ガイドライン ............................................................................ 20

iii

1

保守・運用サービスの範囲
1.1

モデル取引・契約書＜第一版＞の範囲「信頼性向上に関するガイドライン1」（以降、「信頼性ガイドライン」とする）では、「情報システムを求められる水準で安定的に稼動させていくためには、情報システムの供給者及び利用者が協同して適切な保守・運用を実行しなければならない」と述べている。これを受けて「モデル取引・契約書＜第一版＞2」（以下、「第一版」とする）では、検討する保守運用の範囲を、「情報システム運用保守の範囲図3」で示し、サンプル事例がその中でどこに位置づけられているかを網掛けで表示している。（図 1 参照）
図 1

情報システム運用保守の範囲図＜第一版＞

プ ロセス開始の準備
ＩＴ
サービス
マネジメント情報システムの移行

情報システムの運用

情報システ ムの保守

サービスマネジ
メント
導入計画立案

サービス マネジ
メントの 移行

業務運用準備業務 の移行業務運用

業務プロセスの保守

アプリケーション
ソフ トウェア

アプリケーション運用準備

アプリケーションの設定 と移行

アプリケーションの運用

アプリケーションの 保守

システ ム基盤（ハード・ソフト・
ネットワー ク）

基盤運用準備システ ムの移行システム の運用システムの保守業務

サービスデリバリ
サービスサポー ト

モデル取引・契約書＜第一版＞

網掛け部分がサンプルの範囲

また、市場で取引されている多彩な保守・運用サービスの中からサンプル事例として、二つのモデルに関して記述している。
 アプリケーション保守サービス
 オンサイト型アウトソーシングサービス「アプリケーション保守サービス」では、ＩＴサービスマネージメントレベルまでをカバーしたモデルとなっている。またアウトソーシングサービスを下記の二つのモデルに分類・定義し、オンサイト型のフルアウトソーシングをサンプルとして記述している。（表 1 参照）
表 1
データセンター型
オンサイト型

アウトソーシングサービスの分類
保守・運用事業者の施設にユーザの情報システムを設置するサービスを提供する型
ユーザのデータセンターに保守・運用事業者の要員が常駐してサービスを提供する型
モデル取引・契約書＜第一版＞より

1 「情報システムの信頼性向上に関するガイドライン」

経済産業省商務情報政策局情報処理振興課 平
成１８年６月１５日
2 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」〜情報システム・モデル取引・契約書〜（受託開発（一部企画を含む）、保守運用）＜第一版＞ 経済産業省商務情報政策局情報処理振興課 平成１９年４月１３日
3 モデル取引・契約書＜第一版＞の「（４）情報システム保守運用委託基本モデル契約書 ②保守運用業務の全体構成とサンプル事例の対象」 （１３７頁）

1

1.2

保守運用ワーキング･グループでの討議範囲

今回の追補版4をまとめるに当り、契約検討委員会5の下部組織として保守運用ワーキング・
グループ（以降、「本 WG」とする）が設置され討議の結果、「保守・運用ガイドライン」（以降、「本ガイドライン」とする）をまとめた。本ガイドラインでは中堅・中小企業ユーザを想定した保守・運用モデルを体系化し、パッケージソフトウェアやＡＳＰ・ＳａａＳモデルを範囲とした。
第一版の「情報システム保守運用の範囲図」を参考に、本ガイドラインの範囲図を一部修正した。（図 2 参照） 修正した部分は、アプリケーションソフトウェアをオーダソフトとパッケージ
ソフトに二分類化し、パッケージソフトウェアを今回の範囲とした。またシステム基盤もハードウ
ェア、基本ソフト、ネットワーク・通信の三階層とし、ハードウェア保守も明確に範囲とした。
図 2
ＩＴ
サービス
マネジメント情報システム保守運用の範囲図＜追補版＞

プロセス開始の準備

情報システムの構築と移行

サービスマネジメント
導入計画立案

サービスマネジメントの移行

情報システムの運用

情報システムの保守

サービスデリバリ

サービスサポート業務

アプリケーション
ソフトウェア（オーダソフト、パッケージ）

業務運用準備

業務の移行

業務運用

アプリケーション
運用準備

アプリケーションの設定と移行

アプリケーションの運用

業務プロセスの保守

オーダソフトの保守パッケージソフトの保守

システム基盤（ネットワーク・通信）

システム基盤（基本ソフト）システム基盤（ハードウェア）ネットワーク・通信
運用準備

ネットワーク・通信
構築と移行

ネットワーク・通信の運用

ネットワーク・通信
の保守

基本ソフト
運用準備

基本ソフトのj構築と移行

基本ソフト
の運用

基本ソフト
の保守

ハードウェア
運用準備

ハードウェアの構築と移行

ハードウェアの運用

ハードウェアの保守

情報システム保守運用の範囲「情報システムの信頼性向上のための取引慣行・契約に関する研究会」〜情報システム・モデル取引・契約書〜＜第１版＞平成１９年４月発行（経済産業省）を参照し一部変更しています。

各階層に含まれる代表的な技術要素を分類化し、本 WG で共通理解を得るようにした。（図3 参照） 情報システムの技術マップは、各種文献6で報告されているが、今回は保守・運用サービスから見た分類をしている。

4 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」〜情報システム・モデル取引・契約書〜（中小企業、パッケージ活用、保守・運用）＜追補版＞
5 CSAJ/JCSSA 情報システムの信頼性向上のための取引慣行・契約に関する検討委員会（略称：契約検討委員会）
6 参考例：「平成１７年度情報サービス産業における情報技術マップに関する調査報告書」（JISA）

2

図 3

情報システム・レイア別技術 MAP
準備

ＩＴサービス
マネジメント（ITIL）

サービスレベル管理、ITサービス財務管理、キャパシティ管理、可用性管理、
ITサービス継続性管理
サービスデスク、インシデント管理、問題管理、構成管理、変更管理、リリース
管理

基幹系、情報系など

ユーザー用に独自開発したソフトウェア。（部品としてパッケージソフトを利用する場合はある。）

サービスデリバリ
サービスｻﾎﾟｰﾄオーダソフト

基幹系

アプリケー
ション
ソフトウェア パッケージ

情報系

ネットワーク・通信

システム基盤 基本ソフト

ERP系、PDM系、CAD系、業務系（販売、購買、在庫、生産、財務、会計、人事、給与、など）、ECサイト系、SFA、CRM、青色申告、など
グループウェア、掲示板、Information Portal、情報公開WEB、ブログ、E-Mail、E-learning、ワープロ、表計算、など

構築

移行

運用

是正

保守タイプ
予防
適応

○

○

○

○

○

○

○

○

○

○

完全化

監視系

ウィルス系、セキュリティ系、運用監視系、障害監視系、トラフィック系

○

○

○

○

○

部品・ツール系

外部のWebサービス利用、部品・ツール（フォント、OCX、印刷系ソフト、画像処
理系ソフト、OLAPツール、検索エンジン、バックアップソフト、など）

○

○

○

○

○

機器

通信機器（PBX、ハブ、ルーター、TA、帯域制御装置、FAX、無線、ネットワー
クカード、通信カード、など）、通信機器付属ソフト（ドライバ、ファームウェア、
設定ソフト、（但し、無償サンプルソフトは除く））、ケーブル類

○

○

○

○

○

通信業者

電気通信業者（公衆、専用、携帯、PHS）、インターネットプロバイダ

○

○

○

○

○

開発支援系

コンパイラ、アセンブラ、リンカ、ローダー、デバッカ、テストツール、CASEツー
ル、文書化ツール

ミドルウェア系

シミュレータ、エミュレータ、VMウェア、メタフレームなど

○

○

○

○

○

OS系

オペレーティングシステム、データーベース管理システム（OLTP系、DWH系、文書系、XML系）

○

○

○

○

○

○

○

○

○

○

メインフレーム
サーバー、クライアント、プリンタ、増設記憶装置、バックアップ装置、その他周辺機器（通信機器以外）、ハードウェア付随ソフト（ファームフェア、ドライバ、
ハードウェア設定ソフト、（但し、無償サンプルソフトは除く））、UPS、など

ハードウェア

ファシリティ

建物・関連設備

建物、電気設備、空調機器、障害対策、監視設備、など○印の部分が今回の討議対象（案）

また検討範囲を網掛けと○印で記した。対象範囲外としては、最上位の階層「ＩＴサービス
マネージメント」、及び「オーダーソフト」、「開発系ソフト」、「メインフレーム」とした。また階層に「ファシリティ」を追加し、対象外を明確にした。
横軸のプロセスでの対象範囲外は、プロセス開始の準備および移行とした。共通フレーム２
００７では保守プロセスに「システム又はソフトウェアの廃棄」が定義されているが、第一版と同様にこのプロセスは対象外とした。しかし、ＡＳＰ・ＳａａＳモデルでは、ユーザ側の事情での解約やＳａａＳベンダ側の事情でのサービス停止や倒産等が発生したとき、特有の問題が発生するため一部言及している。
1.3

保守・運用プロセスの定義
保守・運用のプロセスの定義は「共通フレーム２００７」で詳細に定義されている。
1.3.1

運用プロセス

運用プロセスは、「開発プロセスからの資産の引き継ぎ」から始まり、「要員確保」、「上流工程で定義された運用要件の確認」、「運用テスト」、「移行」、「教育」、「評価」などを「共通フレーム２００７」で定義している。
２００７年度版で変更された部分は、「プロセス開始の準備」アクティビティの中を、「システム運用」と「業務運用」に分けてタスク表記している。また「利用者教育」アクティ
ビティも新たに定義された。
運用プロセスのアクティビティとタスクの一覧を図 4 に示した。２００７年度版で変更された部分を太字で、また JIS X 0160 には無い部分を点線の枠で表した。

3

図 4

共通フレーム２００７（運用プロセス）

1.7 運用プロセス
1.7.1 プロセス開始の準備
1.7.1.1 運用プロセス実施計画の作成
1.7.1.2 運用のための資産の引継ぎ
1.7.1.3 運用時の問題管理手続きの確立
1.7.1.4 システム運用にかかわる事前調整
1.7.1.5 システム運用にかかわる作業手順の確立
1.7.1.6 システム運用評価基準の設定
1.7.1.7 業務運用にかかわる事前調整
1.7.1.8 業務運用にかかわる作業手順の確立
1.7.1.9 業務運用評価基準の設定
1.7.1.10 運用テスト計画の作成

1.7.3 業務及びシステムの移行
1.7.3.1 移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守
1.7.3.2 移行計画の作成及び実行
1.7.3.3 関係者全員への移行計画等の通知
1.7.3.4 新旧環境の並行運用と旧環境の停止
1.7.3.5 関係者全員への移行の通知
1.7.3.6 移行評価のためのレビュー
1.7.3.7 旧環境関連データの保持と安全性の確保

1.7.1.11 プロセス開始のためのレビュー実施

1.7.4 システム運用
1.7.4.1 システムの運用
1.7.4.2 運用監視及び運用データの収集
1.7.4.3 問題の識別、記録及び解決
1.7.4.4 運用環境の改善

1.7.2 運用テスト
1.7.2.1 運用テストの準備
1.7.2.2 運用テストの実施
1.7.2.3 運用テスト結果の確認
1.7.2.4 システム運用の訓練

1.7.5 利用者教育
1.7.5.1 システム利用教育環境の構築
1.7.5.2 利用者への周知
1.7.5.3 利用者の教育

1.3.2

1.7.6 業務運用と利用者支援
1.7.6.1 業務の運用
1.7.6.2 利用者の支援
1.7.6.3 保守プロセスへの引継ぎ
1.7.6.4 回避策の提供

1.7.7 システム運用の評価
1.7.7.1 システム運用の評価

1.7.8 業務運用の評価
1.7.8.1 業務運用の評価

1.7.9 投資効果及び業務効果の評価
1.7.9.1 投資効果及び業務効果の評価

保守プロセス「共通フレーム２００７」で定義されている保守プロセスを図 5 に示す。
図 5

共通フレーム２００７（保守プロセス）

1.8 保守プロセス
1.8.1 プロセス開始の準備
1.8.1.1 開発プロセスからの引継ぎ
1.8.1.2 計画及び手続きの作成
1.8.1.3 修正手続きの確立
1.8.1.4 修正作業の管理
1.8.1.5 保守のための文書作成

1.8.2 問題把握及び修正分析
1.8.2.1 問題報告又は修正依頼の分析
1.8.2.2 問題の再現又は検証
1.8.2.3 修正実施の選択肢の用意
1.8.2.4 文書化
1.8.2.5 修正案の承認

1.8.4 保守レビュー及び受け入れ
1.8.4.1 修正システムのレビュー
1.8.4.2 完了の承認
1.8.4.3 保守のための文書の更新

1.8.3 修正の実施
1.8.3.1 分析と修正部分の決定
1.8.3.2 修正の実施
1.8.3.3 購入パッケージの修正実施

1.8.5 移行
1.8.5.1 移行のためのソフトウェア製品及びデータ移行時の共通フレームの遵守
1.8.5.2 移行計画の作成と実行
1.8.5.3 移行計画等の利用者への通知
1.8.5.4 新旧環境の並行運用と旧環境の停止
1.8.5.5 関係者全員への移行の通知
1.8.5.6 移行評価のためのレビュー
1.8.5.7 旧環境関連データの保持と安全性の確保

1.8.6 システム又はソフトウェアの廃棄
1.8.6.1 廃棄計画の立案
1.8.6.2 廃棄計画等の利用者への通知
1.8.6.3 新旧ソフトウェア製品の並行運用と利用者への教育訓練
1.8.6.4 関係者全員への廃棄の通知
1.8.6.5 廃棄関連データの保持と安全性確保

ソフトウェア保守に関しては、ＪＩＳ X 01617でも定義されている。２００８年度版（予定）では緊急保守が是正保守の一部として定義される。（表 2 参照）
表 2
保守分類
訂正保守

保守のタイプ
是正保守
緊急保守
予防保守

改良保守

1.4

JIS X 0161：2008（ソフトウェア保守）

corrective
maintenanceemergency
maintenancepreventive
maintenancemaintenanceenhancement

適応保守

adaptivemaintenance

完全化保守

perfective
maintenance

説明 （JIS X 0161:2007）
ソフトウェア製品の引渡し後に発見された問題を訂正 するために行う受身の修正。
（注記）この修正によって、要求事項を満たすようにソフトウェア製品を修復する。
是正保守実施 までシステム運用を確保するための、計 画外で 一時的な修正。
（注記）緊急保 守は是正保守の一部である。
引渡し後 のソフ トウェア製品の潜在 的な障害が運用障害になる前に発見 し、是正を行
うための修正。
新しい要求を満 たすために既存のソ フトウェア製品への修正（注記）改良保 守はソ フトウェアの訂正ではない。
引渡し後 、変化した又は変化している環境において、ソフトウェア製品を使用できるよ
うに保ち続けるために実施するソフ トウェア製品 の修正。
（備考）適応保 守は、必す（須）運用 ソフトウェア製品の運用環境変化に順応するために必要な改良を提供する。これ らの変 更は、環境 の変化に歩調を合わせて実施する必要がある。
引渡し後 のソフ トウェア製品の潜在 的な障害が、故障として現 れる前に、検出し訂正するための修正。
（注記）完全化 保守は、利 用者のための改 良、プログラム文書の改善を提供し、ソフト
ウェアの性能強 化、保守性 などのソフトウェア属性の改善に向けての記録を提供する。

IT サービスマネージメント
運用管理を効果的に提供するための規格として、「情報技術−サービスマネージメント」（JIS Q 20000-1 及び-2）が２００７年４月に制定された。（表 3 参照）

7「ソフトウェア保守」JIS X 0161:2008 年度版（予定）4

運用サービスのモデルを考慮するに当り、JIS Q 20000 を参考とした。
表 3

情報技術サービスマネージメント（JIS Q 20000-2:2007）
目的(JIS Q 20000:20 07)

6 サービス提供プロセス
6.1 サービスレベル管理
6.2 サービスの報告
サービス継続及び可用性の管理サービスの予算業務
6.4
及び会計業務6.3

6.5 容量・能 力管理
6.6 情報セキュリティ管理
7 関係プロセス
7.2 顧客関係管理
7.3 供給者管理
8 解決プロセス
8.2 インシデント管理
8.3 問題管理

サービスレベルを定義、合意、記録及び管理するため。
十分な 情報に基づいた意思決定及 び効果的な伝達のための、合意に基づく、適時の、信頼できる、正確な報告書を作成するため。
合意したサービス継 続及び可用 性について の顧客に対するコ ミットメントを、あらゆる状況のもとで 満たすことを確実にするため。
サービス提供費用の予算を管理し、かつ、会計を行うため。
顧客の事業において必要な 、現在及び将 来の合意された需要を満たすために、サービス提供者が十分な容量・能力を常にも っていることを確実にするため。
すべてのサービス活動内で、情報セキュリティを効果 的に管理するため。
顧客及びその事業推進要因に対する理 解に基づき、サービス 提供者 と顧客との間に良好な関係を確立し、かつ、維持す るため。
均質な サービスが確 実に提供されるように、供給者を管理するため。
顧客への合意したサービスを可能な限り迅速 に回復するため、又はサービス要求に対応するため。
インシデントの原因を事前予防的に識別 し、かつ、分析することによって、及び問題の終了まで管理することによって、顧客の事業に対する中断を最小限に抑えるため。

9 統合的制御 プロセス
9.1 構成管理9.2 変更管理
10 リリースプ ロセス
10.1 リリース管理 プロセス

1.5

サービス及びｲﾝﾌﾗストラクチャのｺﾝﾎﾟｰﾈﾝﾄを定義し、制御し、かつ、正確な 構成情報を維持するため。
すべての変更を、制御された方法で、アセス メント、承 認、実装及びレビューすることを確実にするため。
リリースにおける一つ以上の変更を、稼働環 境に配送し、配布し、かつ、追跡 するため。

保守・運用の管理基準
システム全体の管理基準は、「システム管理基準解説書8」で２８７項目が定義されている。（図 6 参照）
この中で「Ⅳ．運用業務」の基準項目として７３項目ある。「Ⅴ．保守業務」はソフトウ
ェア保守を中心に１９項目、「Ⅵ．共通項目」として７６項目が、保守・運用に関連する管理基準となっている。ハードウェア保守に関しては運用業務の中の「７．ハードウェア
管理」の中にまとめて記述されている。
図 6システム管理基準システム管理基準（２８７項目）
Ⅰ 情報戦略（４７項目）
1 全体最適化
2 組織体制3 情報化投資
4 情報資産管理の方針
5 事業継続計画
6 コンプライアンス

18
9
6
4
5
5

Ⅱ 企画業務（２３項目）
1 開発計画
2 分析
3 調達

9
8
6

Ⅲ 開発業務（４９項目）
1 開発手順2 システム設計
3 プログラム設計
4 プログラミング
システムテスト・ユー
5
ザ受入れテスト
6 移行

4
15
5
4
13
8

Ⅳ 運用業務（７３項目）
1 運用管理ルール
2 運用管理3 入力管理4 データ管理5 出力管理6 ソフトウェア管理
7 ハードウェア管理
8 ネッ トワーク 管理
9 構成管理10 建物・関連設備

4
16
5
10
7
9
6
6
4
6

Ⅴ 保守業務（１９項目）
1 保守手順
2 保守計画
3 保守の実施
4 保守の確認
5 移行
6 情報システムの破棄

3
3
3
5
3
2

8 「システム監査基準／システム管理基準

局／発行

Ⅵ 共通業務（７６項目）
1 ドキュメント管理
2 進捗管理3 品質管理4 人的資源管理
5 委託・受託
6 変更管理7 災害対策情報セキュリティ監査
情報セキュリティ監査基準
情報システム安全対策基準
コンピュータウィルス対策基準
コンピュータ不正アクセス対策基準
ソフトウェア管理ガイドライン
etc．

解説書」平成１６年基準策定版
財団法人日本情報処理開発協会（JIPDEC）

5

9
6
4
13
25
6
13

監修

経済産業省情報政策

2

保守運用の留意事項
2.1

信頼性ガイドラインでの留意事項
信頼性ガイドラインで保守・運用段階における留意事項が１０項目示されている。
（表 4 及び表 5 参照）

これらの留意事項は「システム管理基準」および「システム監査基準」と補完関係にある9。
表 4

保守・運用段階における留意事項

留意事項

実施例

保守・運用に関する体制等の利用者・供給
運用保守体制図及び運用フロー図を作成し、合意する者間での合意企画・開発・保守・運用の全体を通じたリス リスクマネジメントのためのチェックリストを作成し、リスク2
ク管理
レビュー会議等で定期的にチェックを行う
不具合や保守の重要性を段階的に定め、それぞれのラン
保守・不具合の取扱方針の利用者・供給者
3クに応じた対応内容を文書化しておく（訂正保守と改良保間での合意
守を峻別し合意）システムの稼動状況を日・週・月・年単位で取得し、分析
4 恒常的な運用状況の把握を行い、情報システム利用者に対して報告するマニュアルに基づくシステムの導入訓練や緊急対応訓練
5 リリース手順等の整備と訓練を情報システム関係者間で実施する構成管理ツールや不具合管理ツール等を活用し、問題追
6 問題追跡性の確保
跡性を確保する1

表 5

障害対応に関する留意事項

留意事項

実施例

事業継続計画に基づき情報システム障害発生時の対応
1 緊急時対応の利用者・供給者間での合意
手順・マニュアルを整備し、定期的な訓練等をしておく
情報システム障害に対する原因究明手順書及び様式類
2 原因追求手順等の明確化を整備し、情報システム利用者及び情報システム供給者間で共有する
情報システム障害に関する情報の利用者・ 情報システム障害管理データベースを整備し、情報シス
3
供給者間での共有化
テム関係者間で共有化する
情報システム障害管理データベースに、関連する情報シ
4 関連・類似システムの障害情報収集
ステム障害を登録する

しかしこの留意事項は、大企業、大規模、重要インフラも範囲とした留意事項であるため、今回の範囲である中堅・中小企業向けには、一部補足説明をする必要がある。また保守・運用に言及するため、より具体的な記述も含めて次節で行う。
2.2

現状の保守運用サービスの問題点と課題「保守・運用に関する現状の問題点抽出のための調査」10を行った。その内容と「信頼性ガイドラインでの留意事項」も合わせて、課題を抽出し留意事項として表 6 にまとめた。

9 「情報システムの信頼性向上に関するガイドライン（案）へのパブリックコメント結果表」の項番７より引用
10 本ＷＧで「保守・運用サービスに関するトラブル事例」を平成１９年６月に調査。
調査対象は同ＷＧのメンバー。

6

表 6
ＮＯ
１

留意事項
組織・体制の明確化

２

曖昧な契約の排除

３

セキュリティ・可用性の充実

４

ハードウェア保守

５

アプリケーション保守（パッケージソフトウェア）

６
７

繰り返し型開発、アジャイル開発の場合
ＡＳＰ・ＳａａＳモデル

８

保守タイプと瑕疵との関連

保守運用の留意事項
内容
運用責任者の明確化
運用フローの明確化
問題解決手順の明確化、など
契約内容の明確化（保守範囲の明確化）
コミュニケーション向上（契約担当者と実務担当者など）情報開示（ハードメーカ、ソフトメーカ）
セキュリティの重要性
入退出管理（特に一般人の出入りが多い施設）
ID/パスワード管理
バックアップ、事業継続計画の策定、など
保守範囲の明確化、保守対象外部品
製品寿命、部品提供期間などの期間管理
事前停止の考慮、保守機器の管理、など
保守範囲の明確化、カスタマイズの定義、
ＦＯＳＳの保守、保守不能の防止、変更管理・リリース管理の重要性、サポート期間の確認
瑕疵基準の合意（訂正保守、改良保守）、など
開発モデルに合わせた変更管理、リリース管理

節番
2.3

通常時の保守運用
ＡＳＰ・ＳａａＳベンダの選定
内部監査実施状況、など
脆弱性対策と瑕疵担保責任
瑕疵調査費用の取扱い
事前確認の重要性、など

2.9

2.4

2.5

2.6

2.7

2.8

2.10

節番：留意事項を説明している本文の節の番号

特に、組織・体制の明確化、契約時の事前確認、契約内容の明確化などが重要となる。
2.3

組織・体制の明確化
信頼性ガイドラインでは、「利用者及び供給者は、保守・運用に係る活動全般について、双方の推進体制及び承認手順を文書化し両者で合意すること」とし、運用保守体制図や運用業務フローを作成し合意することを求めている。
「システム監査基準」でも「ユーザ責任者、運用管理責任者、保守責任者などに対して役割と権限を明確に定義する必要がある」と規定している。
企業規模が小さくなるほど運用管理責任者や保守責任者などの責任者を設置していないユーザがあり、保守・運用上のトラブルを正しく対処できなく損失が増大する傾向にある。責任者設置の重要性を認識し、運用フローや問
題解決手順などを明確化しておくことが強く望まれる。

2.4

曖昧な契約の排除
保守・運用上のトラブルを分析すると、「契約内容の曖昧さ」や「ユーザとベンダー間での契約時の確認不足」、「利害関係者間のコミュニケーション不足」による問題が多かった。
7

2.4.1

契約内容の明確化
信頼性ガイドラインでは、契約における重要事項の明確化を求めている。
「情報システム利用者と情報システム供給者が明確化・共有すべき事項については、原則として契約において規定する」としている。
保守・運用サービスの範囲、責任、役割分担、体制などの明確化が重要である。中堅・中小企業においても、最大限明確な契約の内容とするよう心掛けることが必要である。

2.4.2

コミュニケーションの向上
契約当事者と実務担当者が異なるときの注意として、契約内容を実務担当者に周知徹底させておく必要がある（ユーザ側、保守側ともに）。特に契約地より遠い出先機関でのトラブルを未然に防ぐためにも必要となる。

2.4.3

情報開示（ハードメーカ、ソフトメーカ）
保守・運用サービスの、より進んだ内容の情報開示が求められる。特にソフトウェアパッケージでは、製品機能に関する情報開示に傾注するのは販売戦略上必要となるが、保守・運用面で考えると実施可能な範囲、注意制限事項など、より進んだ情報の公開が望まれる。（レスポンス、推奨ユーザ数、参照整合性、
トランザクション処理、など）

2.5

セキュリティ・可用性の充実
2.5.1

セキュリティの重要性① 入退出管理
個人情報や機密情報を取り扱う一般人の出入りが多い施設（例：病院や公共施設など）ほど、セキュリティ管理の重要性が望まれる。施設の運用の一部をアウトソーシングするときは、特にセキュリティ管理が重要となる。
② ＩＤ／パスワード管理
パスワードは、あらゆる機器（サーバー、クライアント、ハードディ
スク、ネットワーク機器、など）やソフトウェア（ＯＳ、データベース、
業務アプリケーション、など）に設定されている。セキュリティ面からは、ユーザ個々人のユーザＩＤ、パスワード以外に、あらゆる機器のＩ
Ｄとパスワード、ソフトウェアのＩＤとパスワードを運用や保守などの責任者が管理する必要がある。
しかし、責任者が不明確なユーザではパスワードの管理が出来なくな
り、保守・運用会社の担当者に安易に依頼する場合がある。担当者レベ
ルでの管理ではなく、第三者に依頼するなど、セキュリティの向上が望
8

まれる。
2.5.2

バックアップ
データ及び、システムのバックアップは事業継続性の観点からも重要事項となる。バックアップ方針に基づきバックアップ計画を策定し、確実に実行することとともに、リストア計画の策定及びその実行・評価も重要となる。

2.6

ハードウェア保守「システム管理基準」の「Ⅳ-７-（3）運用業務・ハードウェア管理」で「ハードウェアは定期的に保守を行うこと」と規定されている。また、「想定されるリスクの管理」や「障害対策を講じること」と記述されている。実際のハードウェア保守は、各メーカーによって詳細は異なっており、契約時に事前確認が必要となる。
「問題点抽出のための調査」で寄せられた代表的な意見を解説する。また、
この節の最後に確認事項としてまとめている。
2.6.1

データ復旧は別メニュー① 工場出荷状態に戻すのが一般的
ハードウェア保守は、故障修理が原則であり、工場出荷状態または導入当初の初期状態に戻すのが一般的となっている。ディスク内のデータ復旧や、最新の設定内容にするのは、ユーザ側の責任作業となっている場合が多い。
しかし運用面から見ると、故障発生時直前の状態に戻らないと、運用上の問題が発生する場合が少なくない。保守運用会社に、故障発生直前の状態に戻すことを依頼するためには、「別メニューの契約」や「復旧支援サービス付きのハードウェア保守契約」が必要となる。
② データバックアップはユーザ責任が一般的
データのバックアップはユーザ責任で行うのが一般的である。バックアップも保守運用会社に依頼するときは、「バックアップ運用支援サービス」などを契約する必要がある。これらをパック化したサービス商品も見られる。
③ 交換したディスク内のデータは秘密保持条項で保護
ハードディスク等の外部記憶装置が故障（クラッシュなど）して、部品交換行ったとき、その故障部品の所有権は、保守会社に帰属するのが一般的である。保守料金の設定も、これを前提に設定されている。このとき、故障した部品の中に記憶されているデータ（個人情報や機密情報など）の保護は、保守契約書にある機密保持義務条項で保護される。記憶されている情報の確実な破棄を保守会社に要求するときは、別契約が必要となるのが一般的である。

9

2.6.2

保守対象外部品
ハードウェア保守契約を締結しているにもかかわらず、部品代の請求が発生するがある。これは保守対象外部品（有寿命交換部品、有償部品、消耗部品などとも言う）が存在するためであり、契約前の事前確認が必要となる。（例：内臓バッテ
リー、内蔵ハードディスク、インクリボン、トナーなどの消耗品、など）

2.6.3

製品寿命や保証期間などの期間管理
アプリケーションソフトウェアのライフサイクルに合わせて、システム基盤となる
ハードウェア、ＯＳ、ミドルウェア、ネットワーク機器などの製品寿命や保障期間、部品提供期間などを管理する必要がある。
長期間に渡りアプリケーションソフトウェアを稼動させるためには、システム基盤の各種期間を細かく管理し、期限到達前には代替機種の検討や適用保守などを十分な期間をかけて検討する必要がある。また、費用が発生する場合が殆どなので予算化しておく必要がある。

2.6.4

事前停止の考慮システムが運用プロセスに入っても、ハードウェアやソフトウェアの保守のために、システムの一部や全体の停止が発生する。企画や要件定義のプロセス時に、製品（ハードウェア、ソフトウェア）の特性や耐久性、安定稼動対策などを考察し、事前停止を考慮しておく必要がある。また、運用時の対応方法（決定
ルールや事前通知方法など）も検討しておく必要がある。事前停止には、下記の二つが考えられる。
① 計画停止１年３６５日２４時間稼動が求められる業務が近年増加している。しかしハードウェアやソフトウェアは定期保守が必要であり、そのための計画停止が必要となる。無停止稼動時間を長くするほど（計画停止時間を短くするほど）、システムの全体価格（導入価格および運用コスト）は上昇する。
導入時には費用対効果も検討し、計画停止時間、間隔を決定する必要がある。
② 緊急停止システムが安定稼動しているときでも、ＯＳの緊急パッチやウィルスチェ
ック強化などのソフトウェア保守が発生する。その時は、システムの一部や全体を、一時的に緊急停止する必要がある。緊急度や影響度などを総合的に判断して、システムの一部又は全体を停止する。

2.6.5

保守機器の管理
保守対象機器の管理は、機種機番、設置場所などの情報がコンピュータ
管理され、対象機器には目印となるシールなどが張ってあるのが一般的である。
10故障時には、代替機や機器交換などにより、筐体が変更される場合がある。その時は交換された機器に新しいシールの張替えや、機番変更などを行う。これらの処理を正しく行わないと保守対象機器の特定が困難となる。
ハードウェアの設置場所の移設や廃棄をユーザが行った時には、保守会
社への連絡が必要となり、ユーザの管理が重要となる。
数多くのクライアントや周辺機器の保守を行う場合は、管理が特に煩雑となる。きめ細かな管理を実施しないと、保守対象機器の特定が出来なくなり支障をきたす。ハードウェアの破棄時、どの保守契約を解約したら良いかの判断も出来なくなり、解約手続きが遅延する。解約するまでは、破棄したハードウェアにも保守料金が発生しているので注意が必要となる。
2.6.6

ハードウェア保守確認事項
アプリケーションソフトウェアを正常に稼動させるには、その構成品目
である各種ハードウェア（サーバ、クライアント、プリンター、ルーター、回線、など）の特性、保守状況などを細かく管理することが必要となる。
ハードウェア保守での特有の確認事項を表 7 にまとめた。
表 7

ハードウェア保守特有の確認事項

項目名
ベンダー側
製品耐久性

表示例
印刷２０万枚、液晶バックライト時間 40,000 時間、ハードディスク 50,000 時間、など
動作時温度・湿度、保管時温度・湿度、結露しないこと、設置スペース、など
半年、１年間、３年間、など
製造中止後７年、販売終了後５年、ユーザ設置後５年、など
内臓ディスク、バッテリー、プリンター・ローラー、消耗品（インク、トナーなど）、など
リサイクルトナーやリサイクルインクは不可、など
停止日、期間、サイクル、など
保守機器の確認方法、など

設置環境
無償保証期間部品提供期間（部品保有期間）
保守対象外部品（有寿命部品）
純正部品のみ保証
計画停止・緊急停止時期
保守機器の管理
ユーザ側
業界上の制約法律や業界で規定されている事項
ワイヤレスＬＡＮ使用規制、携帯電話使用規制、など
アセット管理（設置場所など）
機器別保守会社の把握

保守機器の管理

2.7

アプリケーション保守（パッケージソフトウェア）
アプリケーションソフトウェアは、オーダソフトとパッケージソフト（基幹系、情報系、監視系、部品・ツール系）に大別される。
（図 3 参照） ここではパッケージソフトに絞った形で言及するが、オーダソフトと共通している部分もある。
ソフトウェア保守をアプリケーション保守と言い換えているのは、基本ソフトを含めてない形を明確にするためである。基本ソフトの保守は、ライセンス11

保守として契約されるケースが一般的である。また、パッケージソフトの本体部分はライセンス契約で、カスタマイズした部分はアプリケーション保守契約で行われる場合もある。
留意事項としては、ハードウェア保守と共通している項目も多い。「契約の曖
昧さの排除」や、「サービス内容の範囲を明確化」などである。ソフトウェアの特性としては、瑕疵担保の取扱いが重要となるため、次節（2.10）で詳しく述べ
る。
2.7.1

カスタマイズの定義
パッケージソフト保守のときは、カスタマイズの有無やカスタマイズの大きさによって保守性が異なる。また保守を担当する会社が、そのパッケージのカスタマイズが出来るかどうかによっても保守性が異なる。
パッケージソフトカスタマイズの一般的な分類をした。（図 7 参照）

アプリケー

ションソフトウェアは、オーダソフトとパッケージソフトに大別される。またパッケージ
ソフトの、カスタマイズを３分類した。カスタマイズは、パラメータ設定部分とアドオ
ン部分、モディファイ部分に分けて考える必要がある。以下に、著作権も含めた一
般的な考え方を記した。
図 7
アプリケーション

パッケージソフトカスタマイズ分類
分類

提供 システムの構成図
パッ
ケージ

オーダ

オーダソフト説明
ユーザー用に独自開発したソフトウェアを パッケー
使用する場合。部品としてパッケージソフジのトウェアを利用する場合はある。例 えば、 バージョン
部品として通信ソ フトを利用する場合な
アップ
ど。
容易度

疎 結合
プログラム
改修無し

パラメータ
設定

Ⅰ

オーダ

パッケージ

アプリケー
ション
ソフトウェア

疎結合
アドオン
有り

パッケージ
ソフト

Ⅱ

パッケージ

アド
オン

オーダ

プログラム
改修有り

パッケージソフトウェアを主体に無修正で利用し、カスタマイズはパラメータ設定の範囲に限定される。外付けで作成された
オーダソフトと一緒に利 用する場合もある。（表計算ソ フトとの連携 も含む）○

パッケージソフトウェアを主体に利用する。分類Ⅰとの違いは、ユーザー向けにアドオン開発された部分 が存在する。こ のアドオン部分はパッケージ本体と密結合で作成されている。

△

パッケージソフトウェアを主体に利用する。分類Ⅱとの違いは、パッケージ本体のソースコ ード をユーザー向けに修正したモディファイ部分が存在する。

×

カスタマイズモ ディファイ
有り

Ⅲ

パッケージ

ﾓﾃﾞｨ
ﾌｧｲ

アド
オン

疎結合

オーダ

疎結合 ：システム間連携を、ＣＳＶファイルなどの別フ ァイルを介して行ったり、ＡＰＩ（Application Programming Interface）関数やＷＥＢサービスなどを利用して行う場合。
密結合 ：パッケージ本体のフ ァイルやテーブルを直接参照したり、更新する。また、ファイルやテーブル変更もありえる。

① 図 7 はアプリケーションソフトウェアをオーダーとパッケージとに大別し、さらにパッケージソフトはプログラム改修有無などで３分類している。
② カスタマイズはユーザ要件により実施され、プログラム改修がともなわない場
合とプログラム改修がともなうアドオンとモディファイに分類される。
③ プログラム改修（ソースコードの追加・変更・削除）をしないで、パラメータ設
定のみでユーザ要件が満たされる場合を分類Ⅰに区分した。
④ パッケージのソフトウェア保守を行うときは、対象パッケージが分類Ⅰ〜Ⅲのいずれかであるかを明確にしておく必要がある。
12

⑤ 将来、頻繁にバージョンアップが必要なときは、プログラム改修無し（分類Ⅰ）で利用する方が良い。
⑥ カスタマイズが大きくなるほど、バージョンアップが困難になる傾向にある。
⑦ 分類ⅡやⅢで利用しているときにバージョンアップを行うと、別途、開発費用が発生する場合が多い。
⑧ パッケージメーカー以外が、アドオンやモディファイを開発するときには、パッケージ内部の開示や著作権の問題を解決しておく必要がある。
⑨ パッケージ本体及びカスタマイズ部分の著作権は、パッケージメーカーに存在する場合が多い。
2.7.2

フリーソフト及びオープン・ソース・の保守
FOSS11の場合の保守は事前の確認や契約が特に重要となる。ベンダが主体で選定する場合や、ユーザが主体で選定する場合によって責任範囲や保守性が異なる。第一版での取扱いを表 8 にまとめた。
表 8
前提条件

ライセンス契約
ベンダが主体で選定
ユーザが主体で選定

FOSS の場合の責任範囲の取扱い
ベンダが瑕疵及び権利侵害の有無を把握することは困難
ベンダが主体で提案した場合でも、ユーザは自らの責任で採用決定をする
ユーザがライセンサーと直接、ライセンス契約をする
ユーザと第三者間で問題解決を図る
ベンダは説明義務を契約上の責任として負う
ベンダは故意重過失で説明しなかったときは免責されない
ベンダは一定の説明責任を負う
ベンダは悪意重過失で説明しなかったときは免責されない。
モデル取引・契約書＜第一版＞より

フリーソフトウェアは低コストで便利に利用できる反面、ウィルスの混入や知的財産権侵害、製品の品質保証などの問題点も多い。採用に当たっては、実績や安全性など十分に検討する必要がある。またシ
ステム管理基準では、「Ⅳ・６・（９）フリーソフトウェアの利用に関し、組織体としての方針を明確にすること」と規定している。
2.7.3

保守不能を防止開発メーカーの倒産等により、パッケージ保守が出来なくなる問題が発生する場合がある。ユーザを保護する制度として、ソフトウェア・エスクロ制度12がある。ユーザは利用を含めて検討する必要がある。

11

Free and Open Source Software の略。
ライセンサー（ソフトメーカ等）が倒産等した場合に、予め設定されている開示条件でソースコード等をライセンシー(利用者等)に開示することにより、ライセンシーの保護を図る制度。この制度は平成９年７月より（財）ソフトウェア情報センター（SOFTIC）が運営している。
12

13

オープン・ソース・サポート（OSS13）の中で、開発者やコミュニティがしっかりしていて、バージョン管理などが行われている場合は問題が少ない。しかし、オープン・ソース・サーポート・サービスを提供する会社が保守停止する時のことも考慮しておく必要がある。
2.7.4

変更管理の重要性
第一版の「ソフトウェア開発委託基本モデル契約書」第３７条に変更管理手続
きが記述されており、この手続きによってのみ変更が出来ると規定されている。手続きとは、「変更提案書」に基づき、「変更管理書」を交付し、「連絡協議会」で可否を審議するとなっている。
中堅・中小企業においても、これらの手続きを踏むことが望ましいが、ユーザ・ベンダの体制上や該当アプリケーションパッケージの重要度等の問題で実行困
難なときは、別途、簡易手順を事前に取り決めておく必要がある。安易な変更管理は、品質・スケジュール・費用面で問題が発生する可能性が大きくなる。口頭での曖昧な合意は避け、書面による合意が必須となる。

2.7.5

リリース管理の重要性
リリース管理プロセスは「情報技術−サービスマネジメント」（JIS Q 20000）で規定されている。目的は「リリースにおける一つ以上の変更を、稼働環境に配送し、配布し、かつ、追跡するため」としている。また、リリース方針14を決め、手順に従って検証、受入れ、文書化、リリース、事後の評価、などを取り決めることが重要と規定している。
本番環境に近いテスト環境で十分な受入れテストを実施し、リスクを最小限にして本番環境に移行させるのが重要となる。しかし、リスクを最小限にするためには、テスト期間やそれなりのコストが必要となる。テスト期間が十分にとれない緊急性のある保守の場合や、本番環境に近いテスト環境がない場合などは、テストが不十分になる可能性がある。これらの時の対応方法やリスクなどを、ユーザ・ベンダ間で事前協議しておく必要がある。
また、リリース直前のバックアップや障害が発生したときの対処方法なども含めたリリース管理方法を双方で確認しておく必要がある。

2.7.6

サポート期間ハードウェアと同じく、アプリケーション・パッケージソフトにもサポート期間が設定されている場合がある。この期間を超えて利用するためには、バージョンアップ
やデータ移行作業が発生する場合がある。システム基盤の期間管理と同じく、ア
プリケーション・パッケージソフトのサポート期間の把握も重要となるが、メーカー

13 Open Source Software の略。ソースコードが公開されているソフトウェアのこと。代表的なものとして、Linux や Apache などがある。
14 リリース方針：頻度及び種類、役割及び権限、識別及び説明、検証及び受入れ、等

14

側がバージョンアップするまでなど、期日が明確でないケースも多い。突然のサポート打ち切り通告も存在するため、利用者側の立場に立ったサポート期間の設定が望まれる。
2.8

繰り返し型開発、アジャイル開発の場合共通フレーム２００７では開発モデルに依存していない。繰り返し型開発モ
デルやアジャイル型開発モデルは反復型開発モデルに含まれ、ウォーターフォ
ール型開発モデルと区別される。それぞれの開発モデルで開発されたソフトウ
ェアを保守・運用する場合も、開発モデルの特性によって、保守性・運用面で多少の違いがあると考える。

開発の最終プロセス
開発期間
保守の発生頻度システムの規模

ウォータフォール型
検収（受入れ）
長い
少ない
大規模向き

反復型
検収（受入れ）
短い
多い
小規模向き

反復型開発モデルの特性として、開発期間の短サイクル化と機能向上のための開発が繰り返されるのが前提となっている。したがって、保守・運用面でも、
短サイクル化に対応しなければならない。
2.9

ＡＳＰ・ＳａａＳモデル
2.9.1

通常運用時の保守運用
ソフトウェア・サービスを提供するモデルであるため、システム基盤の内訳（ＯＳやＤＢＭＳの種類など）を、ユーザは詳しく知る必要がない。サービス機能やＳ
ＬＡがどのように実現されるのかを確認する程度にとどまる。保守プロセスはＳａ
ａＳベンダが責任をもって行うため、ユーザは管理コストの低減につながる。
しかし新しいモデルとしてＳａａＳプラットフォームを利用して、業務アプリケー
ションを構築する場合は、一般の開発手法と同じく、ＳａａＳ用言語15での開発と
なる。

2.9.2

ＳａａＳベンダの選定（保守・運用時）
ＳａａＳベンダの選択基準は、企画・開発プロセスでのチェック項目の他に、保守・運用プロセス面からのチェック項目を示した。
表 9

ＳａａＳベンダ選定時のチェックリスト（保守・運用時）チェック項目運用状況の通知機能は？

説明
いつでも閲覧できるか？（平均応答時間、稼動実績、トランザクション処理量、など）
問題追跡性の確保、原因追及の手順は？
必要と認められるものは公開問題発生時の対応は？
障害に関する情報公開は？
15

ＳａａＳプラットフォームに特化した言語

15

メンテナンス通知のタイミングは？
定期メンテナンスのタイミングは？
データ保全（保全期間、バックアップ）
データ・ダウンロード機能
改良保守・訂正保守の手順
保険制度に加入しているか？
内部監査実施状況

2.9.3

十分な期間をもって事前通知されるか？
サイクル、時間帯、時間、など
いつまで保全されているか？（３年間、など）
レイア ウト、項 目、な どが 公 開さ れているか？
一般的には公開していない
コンピュータ総合保険、など
どのように確認するか？

内部監査実施状況
利用者はＳａａＳ事業者の内部統制の整備状況をチェックする必要がある。しかし、個々の利用者がＳａａＳ事業者に立ち入り調査することは現実的ではない。
第三者による監査報告書で代用することが考えられる。委託業務に関する監査基準には、ＳＡＳ７０16や日本版ＳＡＳ７０17がある。またＳａａＳ事業者が、ＩＴＩＬの導入や、ＩＳＭＳ、ＩＳＯ／ＩＥＣ２００００の認証を受けているか、また監査報告書が存在し、利用者から閲覧できる仕組みがあることが望まれる。

2.10 保守タイプと瑕疵との関連「JIS X 0161 ソフトウェア保守」では、ソフトウェア保守を大きく二つに分類（訂正
保守と 改良保守）し ている（ 表 2 参照 ）。また保守 は修正依頼（ Modification
Request）18から発生すると定義している。しかし、瑕疵担保との関連には言及していない。
保守タイプごとに、修正依頼の起因をユーザとベンダ、第三者に分類し、瑕疵かの判定を示したのが表 10 である。訂正保守時の修正依頼が瑕疵担保期間中に発生し、かつその起因（発生原因元）がベンダのときは瑕疵としているが、改良保守のときは瑕疵ではないとした。
第三者が起因するものとして、システム基盤のバージョンアップ（OS やドライバーなど）に対応するための保守や、セキュリティホール対策などが考えられる。第三者が起因する修正依頼は、契約書などで事前確認が必要と考える。
表 10

保守タイプと瑕疵との関連図

保守分類
修正依頼の起因
保守のタイプ
ユーザ
ベンダ
第三者
訂正保守
是正保守
×
○
△
予防保守
×
○
△
改良保守
適応保守
×
×
×
完全化保守
×
×
×
○：瑕疵である、×：瑕疵ではない、△：契約によって異なる

16

SAS70(Statement on Auditing Standards) 米国公認会計士協会（AICPA）の監査基準委員会によって定められた監査基準書の第７０号
17 日本公認会計士協会が２０００年に策定した「監査基準委員会報告書第１８号（委託業務に係る内部統制の有効性の評価）」
18 保守対象となるソフトウェア製品への変更提案を識別するために使われる総称用語（JIS X 0161）

16

現実には起因（発生原因元）が特定できない場合が発生する。これは上流工程（企画･要件定義・開発プロセス）での品質に起因する場合が多い。契約書やドキュ
メント（ソフトウェアカタログ、提案書、要件定義書や設計書、など）に記述されている機能や性能が、実現されていない時は、「是正保守」となり、起因がベンダである
ため、瑕疵と考えられる。
契約書やドキュメントに明示されてないときや、曖昧さがあるときに瑕疵かの特定が困難となる。解決は一般的に話し合いで行われることが多く、交渉のための多大な工数や損失が発生する場合がある。
2.10.1 脆弱性対策と瑕疵担保責任の区別
セキュリティ対策などは「予防保守」に分類され、瑕疵ではない場合が多い。
事後のトラブルを防止するためにも、脆弱性対策と瑕疵担保責任の区別の明確化が必要となる。19
2.10.2 瑕疵調査費用の取扱い
瑕疵担保期間中の瑕疵調査費用はベンダ側負担で行うのが一般的である。しかしアプリケーション保守契約が締結されていない場合で、かつ調査結果が瑕疵でなかったとき、調査費用の請求が発生する場合がある。
特に多額の調査費用を要したときに表面化する。
トラブルを未然に防ぐためにも、事前に取扱いを協議しておくことが望まれる。
2.10.3 事前確認の重要性
トラブルを未然に防ぐためには、ユーザ・ベンダ双方が確認時の注意する項目を列挙した。（表 11 参照） ユーザが正しく判断できないときは、第三者機関20の利用も検討する必要がある。
表 11
ユーザが注意することベンダが注意すること

確認時の注意事項
・曖昧な要求の排除
・ユーザ内での同意を得る（ＴＯＰと現場、部署間、など）
・ベンダ任せにしない
・第三者機関の利用も検討
・自己責任による文書チェック
・運用テスト、受入れテストの充実、など
・確認文書はより詳細に具体的に、分かり易く、誤解のない文書の作成・ユーザの業界特性を加味した内容
・利害関係者に説明し確認を得る
・口答を排除し文書で確認
・目標品質の確保、など

19 「SI 事業者における脆弱性関連情報取扱に関する 体制と手順整備のためのガイダンス」2005 年 8 月

JISA JEITA
20 ユーザとベンダとの利害関係を有しない第三者機関が、システムの要求品質が保たれているかを監視す
る。

17

3

ＩＴサービスの現状
現在、市場には多種多様な IT サービスが存在する。また、その IT サービスの契約形
態も多種多様となっている。
3.1

IT サービスの提供方法の現状
市場で IT サービスはさまざまな形で提供されているものを分類しまとめたのを「ＩＴサービス提供形態」で表示している。（表 12 参照）

一般的には、IT サービスの特性や保守・運用会社が採用するビジネスモデルにより、複数の組み合わせで提供される場
合が多い。
また技術者を、特定の IT サービスに専任化（技術者の氏名を特定）させるサービスの提供形態も存在する。（表 13 参照）
表 12
常駐型
待機型

IT サービス提供形態（保守・運用）

保守運用会社の技術者をユーザーに常駐させてＩＴサービスを提供する。
技術者は保守運用会社に待機しており、必要に応じてユーザーに訪問する。訪問型との違いは、特定の技術者がほぼ１００％当該契約に占有される。

訪問型

イベント発生時（障害発生や定期点検、監視など）ごとに技術者がユーザーに訪問しＩＴサービスを提供する。

リモート型

イベント発生時（障害または定期点検、監視、ユーザーの理由など）に、ユーザーの設置環境にリモートで接続しＩＴサービス（リモートメンテやリモート監視など）を提供する。

センドバック型
ユーザーが故障したハードウェアを保守会社に宅急便などで送り、修理後返送される保守サービス／持込型
電話FAX型障害の対処方法や操作方法などを電話やFAX、E-Mailで回答するＩＴサービス。コールセンターは、このサービス提供形態をとって
いる。

情報提供型

障害情報や操作・運用方法、パッチ情報などをＷＥＢやメールなどで提供したり、ダウンロードできるＩＴサービス。

運用サービス（帳票デリバリーや計算センター利用など）は除く

表 13

技術者専任・非専任

専任型

ＩＴサービスを提供する技術者の氏名が、事前にユーザーとの間で決められている。イベント発生時は特殊な事情がない限り、その技術者が対応する。特定技術者が複数名割り当てられる場合もある。

非専任型

イベントが発生するたびに別の技術者が割り当てされる場合がある。一般的に保守運用会社ではグループで対応するケースが多い。

3.2

地域企業の求める IT サービス
「地域企業の求める IT サービスの利活用21」の調査結果を参照すると、多種多様な
IT サービスが存在する。大きくは開発系の IT サービスと保守・運用系の IT サービスに大別される。
表 14

ＩＴサービス業者から受けているサービス（保守・運用系）

21 「地域企業の求める IT サービスの利活用と費用対効果調査研究」（社）日本コンピュータシステム販売

店協会（JCSSA）平成１９年２月

18ＩＴサービス
サンプル数
アプリケーション保守サービス
修理復旧サービス
統合保守サービス
運用支援サービス
メールサーバー管理サービス

全体
148
49%
49%
42%
38%
35%

地域別
大都市 地 方都市
96
51
57%
35%
48%
51%
38%
49%
42%
31%
38%
31%

保守・運用系の IT サービスの中で最も多く利用されているのは「アプリケーション保守サービス」である。ついで「修理復旧サービス」、「統合保守サービス」「運用支援サービス」と続いている。（表 14 参照）
今回のモデルは、このアンケート調査の内容を踏まえて上位から選別した。しかし、フルアウトソーシングに近いＩＴサービス（例：統合保守サービス）は、第一版の範囲と重複する可能性が高いため、より単純化（サービス範囲が限定）されたＩＴサービスをサ
ンプルモデルとした。（表 15 参照）
表 15
サービス名称
ハードウェア保守
アプリケーション保守
セキュリティ監視
サーバ運用支援
ＳａａＳモデル

ＩＴサービスのモデル（保守・運用系サンプル）
区分
保守
保守
運用支援
運用支援
ＳａａＳ

主なサービス内容
サーバの保守、復旧支援は含まない
パッケージの保守
ファイアウォールを主体とした監視
障害の自動検知を主体とした監視

節番
4.6
4.7
4.8
4.9
4.10

節番：サービ内容を説明している本文の節の番号

4

ユーザ・ベンダの共有すべきガイドライン
ベンダが提供しているＩＴサービスは多種多様であり、ユーザとベンダが事前に取り決めるべき事項を一様に定義することは現実的ではない。そこで、当ＷＧは、情報
シス テムの運用 保守に関す る国際標準 となった JIS Q 20000-1:2007（ ISO/IEC
20000-1:2005）をベースに、ユーザ・ベンダが共に参照し活用できるガイドラインを提供することを目指す。
4.1

ＪＩＳ Q 20000 運用保守ガイドライン
当ＷＧでは、JISQ20000-1:2007 が要求する管理プロセスに則って、各プロセスで管理することが想定される項目について検討した。例えば、インシデント管
理プロセスにおいて、そもそもインシデントとして取り扱う事象にユーザ・ベン
ダ間に差異があっては、適切なインシデント管理は実現されない。したがって、
まず、ユーザ・ベンダは、当該ＩＴサービスにおけるインシデント及び運用面について取り決めをする必要がある。

4.2

ＪＩＳ Q 20000 とＩＴサービスの関係
JIS Q 20000-1:2007 で要求される 13 個の管理プロセスから、ＩＴサービスにおいて管理すべきと考えられる主要な項目について抽出した。
（表 16 参照） ユ19

ーザ・ベンダは、適用する管理プロセスを選択し、そのプロセスにおいて管理していく項目を相互に協議することになる。
また、ＳＬＡ項目も、各種ＩＴサービスの特性やユーザ・ベンダ間の取り決めで異なってくるものと考える。ここでは、代表的なものをサンプルとして列挙した。尚、L1〜L4 は他章の管理レベルと同様の設定とする。
表 16

JIS Q 20000 運用保守ガイドライン

JIS Q 20000-1:2007

項目の説 明L1
L2
L3
L4
6 サービス提供 プロセス
6.1 サービスレベル 管理
ＳＬＡの 締結
提供サ ービスに対する品質を保証するための ＳＬＡを締結しているか
規定なし
部分的 に締結
提供サービス毎に締結
ＳＬＡの 監視ＳＬＡの遵 守状況を確認するために監視されているか
規定なし
部分的 に監視
提供サービス毎に監視
定期的に見直しＳＬＡの 見直し
ＳＬＡが引 続き妥 当かを判断するための 見直しが実施されているか
規定なし
部 分的に見直し
6.2 サービスの報告
定期的に実施
報告会の実施ＳＬＡの遵 守状況を確認するための報告会 は実施されているか
規定なし
場当たり的に実施
報告内容の定義報告される内容は定義されているか
規定なし
場当たり的
定義済み
6.3 サービス継続及び可用性 の管理
要求事項の定義
サービス継続及び可 用性を担保するための 要求事項が定義されているか 規定なし
部分的 に定義
提供サービス毎に定義統合された計 画が策定
計画策定
サービス継続及び可 用性を担保するための 計画が策定されているか
規定なし
部分的 に策定
定期的に実施計画のレビュー
計画の 妥当性を確認するためのレビューが実施 され ているか
規定なし
場当たり的に実施
定期的に実施計画の試験
計画の 実効性を確認するための試験が実 施されているか
規定なし
場当たり的に実施
6.4 サービスの予算業務及び会計業務
予算計画の策定
ＳＬＡを維持するために必要となるリソ ース の予算計 画を策定しているか 規定なし
部分的 に策定
提供サービス毎に策定
予実の管理
策定された 予算計画 の執行状況を確認するために予実を管理しているか 規定なし
部分的 に管理
定期的に管理6.5 容量 ・能 力管理
提供サービス毎に定義
監視対象の定義
ＳＬＡを遵守するために監視すべき対象 を定義しているか
規定なし
部分的 に定義
定義された対象を監 視
容量･ 能力の監 視
ＳＬＡを遵守するために定義された対象を監視しているか
規定なし
場当り的に監 視
需要管理
ＳＬＡを遵守するために監視すべき対象 の需要を管理しているか
規定なし
部分的 に管理定義された対象を管 理
6.6 セキュリティ管理
統一的な基本方針が定義
基本方針の定義
セキュリティを管 理するための基本 方針が定 義されているか
規定なし
部分的 に策定
全社的に実施
リスクアセスメント
守るべき情報資産 に対してリスクアセスメントが実施されているか
規定なし
部分的 に実施
変更諮 問会議で 変更毎に評価変更による評価
変更要 求に関 わるセキュリティ障害を防止するために変更を評価しているか
規定なし
部分的 に評価
7 関係 プロセス
7.2 顧客 関係管理
サービスレビュー会 議
サービスを改 善するためのサービスレビュー会議（対顧客）を実施しているか
規定なし
不定期 に実施
定期的に実施責任者により実施
苦情処理
顧客に対して苦情を処理 するための方法を定義しているか
規定なし
担当者により実施
責任者により実施
顧客満足度の測 定
提供サ ービスに対する顧客満足 を把握するための測定 を実施しているか 規定なし
担当者により実施
7.3 供給 者管理
契約管理
提供するサービスの品質を担保するため供給者と契約を締 結しているか 規定なし 一部の供給者と締結関係する全ての 供給者と締結
監査
供給者 との契約が遵守 されているかを監査しているか
規定なし 一部の 供給者に実施関係する全ての供給者に実施
8 解決 プロセス
8.2 インシデント管理
サービス要 求まで定義
インシデントの定義
記録すべきインシデント（サービス要求含む）が定 義され ているか
規定なし インシデントの み定義
インシデントの検知と記録
定義された 全てのインシデントが 検知・記録されているか
規定なし
全て 手動
一部自動
全て自動
インシデントの分類
対応の 優先順位を判断 するために分類 して いるか
規定なし 事 業インパクトで分類
事業インパクト×緊急 度で分類
インシデントのライフサイクル管理 インシデントはライフサ イクルに沿って管 理されているか
規定なし
ク ローズのみ 管理
複数の ステータス で管理
8.3 問題 管理
手順が定 義されている問題コントロール問題の 根本原因を追究 するための手順が 定義されているか
規定なし
場当り的な作業
手順が定 義されている
エラーコントロール
既知の エラーを取り除くための手 順が定義されているか
規定なし
場当り的な作業
常に参照可 能な状態で管理
既知のエラーデータベース
既知になったエラー情 報を共有するための仕 組みはあるか
規定なし
部分的 な実施
傾向分析
エラーの傾向を把握するために問題 を分 析して いるか
規定なし
場当り的な作業
定期的に実施
プロアクティブな活動
問題を事前予防的に発生させないための 仕組みは あるか
規定なし
場当り的な作業
予防処置あり9 統合 的制御プロセス
9.1 構成 管理方針が定 義されている構成識別管理すべき構成品 目が明確にされているか
規定なし 部分的な資産台帳あり
構成コントロール
構成品 目を適切に管理するための手順 が定義されているか
規定なし
台 帳のみ作成
手順が定 義されている
履歴管理
構成品 目に対 する変更 を追 跡できるよう履歴管 理しているか
規定なし
手動管理
一部自動
自 動管理
構成監査
構成品 目の完全性を維 持するために監 査しているか
規定なし
年次監査
部分的な資 産棚卸し
月 次監査
9.2 変更 管理
全て記 録されている
変更要求の記録
全ての変 更要求は証跡を残すために記録されているか
規定なし 部分 的な記録 がある
事業インパクト×緊急度× 難易度で分類
変更要求の分類対応の 優先順位を判断 するために分類 して いるか
規定なし
部分的 な分類
変更要求の評価
変更によるリスクを低減するために変更要求を評価しているか
規定なし
部分的 な評価
変更諮問会議で評価
切戻し計画
変更の 失敗による障害を低減 するために切 戻し計画を作成しているか
規定なし
部分的 な作成
変更諮問会議で評価
傾向分析
変更の 傾向を把握するために変更要求 を分析しているか
規定なし
部分的 な実施
定期的に実施変更諮問 会議でレビュー
変更要求のレビュー
変更による効 果を測定するために変更要求 をレビューしているか
規定なし
部分的なレビュー
10 リリースプロセス
10.1 リリース管理 プロセス
リリース方針本番環 境を維持するためのリリース方針は 定義されているか
規定なし
場当り的な作業
方針が定 義されている
リリース計画
計画的 なリリースを実現 するための計画書は作成されているか
規定なし
部分的 に作成
リリース毎に計画書が作成されている
リリース毎に手順書が作成されている
リリース手順計画的 なリリースを実現 するための手順書は作成されているか
規定なし
部分的 に作成
リリース毎に関係者に連 絡して いる
コミュニケーション
リリース作業に伴う混乱を避けるため、事前連絡を実施 しているか
規定なし
部分的 に連絡※ＳＬＡ（service level agreement）：サービスレベル合意書※当ガイドラインへの準拠が、JISQ20000-1:2007 の認証取得を保証するものではない。

4.3

サービスの内容に関する項目
ＩＴサービスの内容を特定するにあたり、代表的な項目を下記に列挙した。
項目
サービス名称
サービス内容
対象外
対象環境
契約年月日
契約期間
更新・解除条件
料金
受付方法及び時間
保守時間
定例協議会

説明
サービス内容を詳細に記載
対象外の条件や、注意制限事項などを記載
システム基盤（ハード、OS、など）、環境
契約の日付
サービス開始年月日及び終了年月日
自動更新などの更新条件、解約条件、など
月額や年額、など
平日、土日、祝祭日の対応
実際の保守作業を行う時間帯
開催の有無やサイクルなど

20

秘密保持
再委任
ＩＴサービス提供形態
技術者専任・非専任

4.4

再委任の条件
常駐、訪問、リモート、電話／ＦＡＸ、情報提供、など
技術者を氏名で特定、非特定運用面に関する項目
ユーザ・ベンダ双方の運用体制や運用フローを事前に取り決めされていることが望まれる。

会社名・部署名
責任者
担当者名
問い合わせ先
役割分担
緊急連絡先

ベンダー側
（再委託先名も含む）
営業・技術者・氏名・連絡先
営業・技術者・氏名・連絡先
電話/FAX 番号、URL、メールアドレス等を記す。サービス提供
部署のほか、一般問合せ先がある場合、その連絡先も記す。
サポート範囲、責任範囲、など
ユーザ側

部署名
責任者・連絡先担当者・連絡先
役割分担
緊急連絡先

4.5

サービス連絡先と一般連絡先が異なる場合、両方を記す。
作業範囲、責任範囲、など

ＳＬＡ・ＳＬＭに関する項目
各種ＩＴサービスごとにＳＬＡやＳＬＭの設定がされることが望まれる。また、アプリケ
ーションパッケージの特性や重要性などにより、ユーザ・ベンダ間の協議の上、ＳＬＡのレベルが決定される。下記の項目は、ＳＬＡ設定時に必要と思われる項目を列挙した。
項目
サービスレベル項目
内容
測定方法
測定単位
目標/保証
値

説明
ＳＬＡの項目名
ＳＬＡの内容を説明
測定の方法を説明
分・時・日・週・月・年
目標・保証

尚、以降の章において、具体的なＩＴサービスを対象としたサービスレベル項
目をサンプルとして示していく。
4.6

ハードウェア保守
4.6.1

範囲の明確化
ハードウェア保守を契約する場合、契約作業と契約外作業を明確にする必要がある。また、訂正保守（是正・予防）
・改良保守（適応・完全化）のどれを含むのかも明確にする必要がある。
ハードウェア保守サービスには、出張修理保守（定期点検付、定期点検なし）、引き取り保守、持込保守がある。また、障害復旧にあたり、データ
21

復旧、保守対象外部品の交換、データバックアップ、交換したディスク内のデータの消去の各サービスが別メニューとなる場合が一般的であるが、これらのサービスがひとつのサービスメニューとなっている場合もある。
そのため、サービスの範囲を明確化する必要がある。
項目
サービス提供形態
対応範囲
期間管理
事前停止
契約外作業
報告

4.6.2

ＳＬＡ・ＳＬＭ

サービス
レベル項目
サービス
提供時間
サービス
提供時間
サービス
提供時間
定期点検

4.7

説明
出張対応、引き取り対応、持込対応、定期点検の可否を確認
データ復旧、保守対象外部品、データバックアップ、ディスク内のデータの取り扱いなど
契約期間、製品寿命、保障期間、部品提供期間
定期点検時の計画停止時間、間隔契約対応範囲外の作業内容と実施した場合の料金
対応実績の報告の有無、報告内容、定例会開催の有無など

内容

測定
単位

目標
保証

レベル
1

レベル
2

電話受付時間

時間

目標

出動時間

時間

目標

翌日

当日

4Ｈ

復旧時間

時間

目標

翌日

当日

契約毎個別

実施回数

回数

保証

なし

1 回/年

営業時間内

レベル
3
時間外

2 回/年

レベル
4
365 日
24Ｈ
2Ｈ

3 回/年

アプリケーション保守サービス（パッケージ）
4.7.1

範囲の明確化
パッケージのアプリケーション保守を契約する場合、パッケージ本体とカスタマ
イズ部分を明確にする必要がある。また、訂正保守（是正・予防）・改良保守（適応・完全化）のどれを含むのか、問題解決プロセスを組み込んでいるのかも明確にする必要がある。
アプリケーション保守サービスには、コールセンター、ライセンス保守、障害対応、カスタマイズ保守、導入教育・指導の各サービスに分かれる場合がある。これらが一つのサービスメニューとなっている場合や、分かれる場合、含まれていないサービスなどが考えられる。いずれにしても、サービスに関しての範囲の明確化が必要となる。
［コールセンター・サービス］項目
カスタマイズ分類
問合せの範囲
ＩＴサービス提供形態
技術者専任区分

説明
・パッケージ本体部分の対応か、カスタマイズ部分も含めた対応かを確認
機能、操作、不具合、など
電話ＦＡＸ型、情報提供型、リモート型
専任（技術者氏名特定）対応、非専任（技術者氏名非特定）対応かの確認

22

［ライセンス保守サービス］項目
保守種別（JIS X 0161）
各種権利の確認バージョンアップ関連
法律改正対応問合せ窓口
トラブル発生時

説明
含まれる保守タイプ（是正、予防、適応、完全化）の確認
著作権、利用許諾権利、複製権、再許諾権など
バージョンアップの有無、範囲、サイクル、方法、時間帯、など
予測可能な法律改正（給与所得税率、消費税率などの変更）⇒一般的には含めている場合が多い。
予測不可能な法律改正（新会社法、など）⇒一般的には含めない場合が多い。
コールセンター、部署、電話番号、FAX 番号、など
窓口、ＢＵＧ発生時などの対応方法、など［障害対応サービス］項目
保守種別（JIS X 0161）
サービスマネージメント（JIS Q 20000-1、-2）
対応範囲

提供形態

説明
含まれる保守タイプ（是正、予防、適応、完全化）の確認
解決プロセス（インシデント管理、問題管理）
原因調査、原因排除、再インストール（プログラム）、再設定（プログラム）、データリストア（バックアップデータがある場合）
常駐型、待機型、訪問型、リモート型、電話ＦＡＸ型、情報提供型［カスタマイズ保守サービス］（別途、保守開発契約を締結する場合もある）
項目
保守種別（JIS X 0161）
サービスマネージメント（JIS Q 20000-1、-2）
カスタマイズの範囲
カスタマイズの対応
新しくカスタマイズした成
果物の権利の確認
ＩＴサービス提供形態
技術者専任区分テスト環境
変更管理プロセス
リリース管理プロセス
コールセンター対応
教育・指導
トラブル発生時
精算方法

説明
含まれる保守タイプ（是正、予防、適応、完全化）の確認
プロセスは何を含むのか？（サービス提供、関係、解決、
統合的制御、リリース）
ユーザ要件変更時のカスタマイズの対応方法。
一定条件（人月で設定する場合、など）を設定
モディファイかアドオンまで対応するのかなど
著作権、利用許諾権利、複製権、再許諾権など
常駐型、待機型、訪問型、リモート型、電話ＦＡＸ型、情報提供型
専任、非専任
個別ユーザ環境、一般環境
方針、手順、緊急時、など
リリース方針、手順、など
カスタマイズ部分の対応は？ 個別対応？
訪問型、電話・FAX 型、集合教育・個別教育
窓口、対応方法、など
途中解約や、設定回数未達時の対応、など［導入教育・指導サービス］
項目
指導タイミング及び回数、場所、規模
カリキュラムの範囲
ＩＴサービス提供形態
技術者専任区分
コールセンター
トラブル発生時

説明
初期指導または再指導、個別または集合指導、E-learning、場所、対象人員、レベル、など
カスタマイズを含めた教育、または基本部分のみ、など
常駐型、待機型、訪問型、リモート型、電話ＦＡＸ型、情報提供型
専任、非専任有無
窓口、対応方法、など

23

4.7.2ＳＬＡ・ＳＬＭ［コールセンター・サービス］（例）JISQ20000との対応
8.2 インシデ
ント管理
8.2 インシデ
ント管理

サービス
レベル項目
サービス提供時間
即応率

8.2 インシデ
ント管理
8.2 インシデ
ント管理

電話ビジー率8.2 インシデ
ント管理

コールバック率

放棄率

内容

測定
方法

電話受付時間--電話が鳴ってから基準時間内に応答した率
着信電話に出られなかった率
電話がビジー（話中）でつながらなかった率即答できずに折り返しをした
率

測定
単位
時間
帯

目標
/保証

レベ
ル1

レベル
2

レベル
3
時間外
特約

レベル
4
契約毎
個別

保証

営業時間内

月

％

目標

規定
無し

80％以
上

90％以
上

95％以
上

月

％

目標

規定
無し

20％未
満

10％未
満

5％
未満

月

％

目標

規定
無し

20％未
満

10％未
満

5％
未満

月

％

目標

規定
無し

20％未
満

10％未
満

5％
未満

測定
単位

目標
/保証

レベ
ル1

レベル
3

レベル
4

目標

未定

レベ
ル2
１回
／数
年

１回／
年

数回／
年

［ライセンス保守サービス］（例）JISQ20000との対応
10.1 リリース管理
10.1 リリース管理
10.1 リリース
管理

サービス
レベル項目

内容

測定
方法

バージョンアップサイクルバージョンＵＰ
回数を規定

年

バージョンＵ
Ｐ範囲

バージョンＵＰ
対応の範囲

保証

未対
応

特定バージョン
のみ対応

全ての
バージ
ョン

媒体要求

バージョンＵＰ
媒体の要求方法

目標

未対
応

ユーザのリクエ
スト

自動

提供方法

媒体の提供方
法

目標

未対
応

リアル
タイム
（ダウン
ロード
時）

ダウン
ロード
または
郵送

リードタイム

媒体要求が発生してから、ユーザの手元に届くまでの時間

10.1 リリース管理

10.1 リリース
管理

郵送

日

時間

目標

未定

数日

測定
方法

測定
単位

目標
/保証

レベ
ル1

レベ
ル2

レベル
3

レベル
4

月

時間

目標

規定
無し

翌日

半日以
内

１時間
以内

月

時間

目標

規定
無し

１週
間以
内

１日以
内

１２時
間以内

測定
方法

測定
単位

目標
/保証

レベ
ル1

レベ
ル2

レベル
3

レベル
4

月

日

目標

規定
無し

１月
以内

１週間
以内

翌日

月

日

目標

規定
無し

数日

翌日

当日

月

日

目標

規定
無し

２ヶ月
以内

１ヶ月
以内

１週間
以内

月

日

保証

［障害対応サービス］（例）JISQ20000との対応
8.2 インシデン
ト管理
8.2 インシデン
ト管理

サービス
レベル項目
応答時間

復旧時間

内容
着手有無の決定を回答する時間
障害が発生してから復旧するまでの平均時間［カスタマイズ保守サービス］（例）JISQ20000との対応
9.2 変更管理

サービス
レベル項目
応答時間

9.2 変更管理

9.2 変更管理

9.2 変更管理

着手時間（緊急保守）
着手時間（改良保守）
作業ボリューム

内容
着手有無の決定を回答する
時間
作業が着手されるまでの時間作業が着手されるまでの時間１回当りの最大
作業工数

24

個別契約で設定

9.2 変更管理
作業回数

単位期間のリクエスト最大回
数

月

日

保証

測定
方法

測定
単位

目標
/保証

個別契約で設定［導入教育・指導サービス］（例）JISQ20000との対応
6.5 能力管理
6.5 能力管理
6.5 能力管理
6.5 能力管理
6.5 能力管理

4.8

サービス
レベル項目
実施回数
実施間隔
実施場所
対象人数
対象レベル

内容

レベ
ル1

レベ
レベ
ル2
ル3
個別契約で設定
個別契約で設定
個別契約で設定
個別契約で設定
個別契約で設定レベ
ル4

運用支援系（セキュリティ監視サービス）
4.8.1

範囲の明確化

セキュリティ監視サービスで最も一般的である、ファイアウォールの管理を代行するファ
イアウォールマネージメントサービスをサンプルとして例示する。セキュリティ関連のサービスとして、IDS22や IPS23を利用した不正侵入検知サービス、ウイルス対策やセキュリティ
パッチを代行するサービス等が考えられるが、適宜サービスレベル項目を定め、予めユーザと合意を取ることが望ましい。
別途、ユーザで不正侵入等緊急を要するセキュリティインシデントが発生した場合に備え、緊急対応サービス(エマージェンシーレスポンスサービス)を提供することが望まし
い。
4.8.2

ＳＬＡ・ＳＬＭ［セキュリティ監視サービス：ファイアウォールマネージメントサービス］（例）JISQ20000との対応
6.5 容量・能力管理

サービスレベル項目
稼動監視

6.5 容量・能力管理

不正アクセス検知報告

6.6 セ キュリ テ
ィ管理
6.2 サービスの報告
9.2 変更管理

ログアーカイブ

8.2 インシデン
ト管理

ハードウェア保守

6.2 サービスの報告

稼動状況報告ログ分析
ポリシー変更

内容

測定方法

リモートから
定期的に稼
動を監視す
る
不正アクセ
スを常時監
視し異常発
生時に報告
する
アクセスログを保管する
ログレポート
を提出する
ユーザから
のポリシー
設定変更依
頼に対応す
る
機器故障時
の交換作業
を行う
稼動状況に
ついて報告
する

稼動停止検知から通報までの時
間
ファイアウォール
がブロックしたしたアクセスを検知
する

測定
単位
分

目標
/保証
目標

レベル 1

レベル 3

60 分以内

10 分以内分

保証60 分以内

10 分以内

保証

(未対応)

保証

(未対応)

過去 3 ヶ月分
翌日

ユーザの変更要求から作業完了
までの時間

日

保証

1 週間

翌日

故障検知から交
換までの時間

時

目標

翌営業日

2 時間

月次で稼動状況のサマリ報告を
行う

月

保証

(未対応)

翌月月初
10 営業日以内

22不正侵入検知システム(Intrusion Detection System)：第三者からの攻撃や不正アクセスをリアルタイム

で検知するシステム
23不正侵入防御システム(Intrusion Prevention System)：第三者からの攻撃や不正アクセスからリアルタ
イムで検知・遮断し、公開サーバ等を防御するシステム

25

[運用フロー図：ファイアウォールマネージメントサービス(一部抜粋)]

ファイアウォールマネージメントサービスの運用フロー図(一部抜粋)を例示する。サービス提供に当たっては、運用フローに基づいた対応を確実にするために、予め要員への訓練を実施することが望まれる。
4.9

運用支援系（サーバ運用支援サービス）
4.9.1

範囲の明確化

システム運用支援サービスとして、サーバ運用支援サービスを例示する。近年、エント
リサーバの分野にも障害の自動検知機能等、可用性を向上する機能が実装されてきた。
サービスベンダもこのような機能を積極的に活用し、ユーザシステムの可用性を高めることや保守効率の向上を図ることが望まれる。
また、システム導入時点において、処理する業務の重要度に応じて、ハードウェア部
品の二重化、システムの二重化等、可用性を高める手段を提案することが望ましい。
4.9.2

ＳＬＡ・ＳＬＭ[サーバ運用支援サービス]（例）JISQ20000との対応
6.5 容量・能力
管理

サービスレ
ベル項目
稼動監視

6.5 容量・能力管理

障 害自動 通報6.5 容量・能力管理

システムリソ
ース監視

内容

測定方法

リモートから定期的に稼動を監視する
ハードウェア障害
を 自 動検 知 し 、メールや snmp プロ
トコル を 利 用 して通報する

稼動停止検知から通報までの時間
ベンダ側のサポート部署で、通報メール、
snmp トラップ受
信を検知する
までの時間
ベンダ側のサポート部署で、通報メール、
snmp トラップ受
信を検知するまでの時間

ディスク空き容量
CPU 負荷率を監視し、閾値を超えた場合、メールや
snmp プロトコルを利用して通報する

26

測定
単位
分

目標/
保証
目標

分

分

レベル 1

レベル 3

60 分
以内

10 分
以内

目標

60 分
以内

10 分
以内

目標

(未対応)

10 分
以内

8.2 インシデン
ト管理

ハードウェア
障害復旧

ハードウェアの故障部位を特定し、復旧する

8.2 インシデン
ト管理

サ ーバ 運 用
問合せ対応

6.2 サービスの報告

稼 動状況 報告OS レベルハード
ウェアレベルでの操作方法や設定についての問い合
わせ対応を行う
稼動状況について定期的に報告を行う

ユーザからの連絡や監視システムからの通報時点から、
復旧するまでの時間
メールや電話等でのユーザの問合せから
回答までの時間
月次で稼動状況のサマリ報告を行う

時

目標

24 時間以
内(ベンダ
側の休日
は除く)

4 時間
以内

日

目標

翌日
(ベンダ側
の休日は
除く)

即日
(ベンダ側
の休日は
除く)

月

保証

(未対応)

翌月月初
10 営業日以内

4.10 ＡＳＰ・ＳａａＳモデル
4.10.1 範囲の明確化
ＡＳＰ･ＳａａＳモデルのＩＴサービスを契約する場合、基本サービスとオプション
サービス（カスタマイズ等を含む）を明確にする必要がある。また、ベンダとの契約を締結した段階で、提供されるサービスレベルにユーザが同意したことになるので、ユーザは、利用するＩＴサービスを価格だけでなく、サービスレベルの項目・水準によっても判断しなければならない。
4.10.2 ＳＬＡ・ＳＬＭ
ここでは汎用的なサンプルを提示するに留め、詳細は総務省や経済産業省
からも資料24が公開されているので参照されたい。
［ＡＳＰ・ＳａａＳモデルのＳＬＡ］（例）
JISQ20000との対応
6.5 容量・能力管理
6.5 容量・能力管理
6.5 容量・能力管理
6.5 容量・能力管理
6.5 容量・能力管理
6.5 容量・能力管理
6.5 容量・能力管理
6.5 容量・能力管理
6.5 容量・能力管理
6.5 容量・能力管理6.6 情報ｾｷｭﾘﾃｨ管理
6.6 情報ｾｷｭﾘﾃｨ管理
6.5 容量・能力管理8.2 インシデ ント管 理
8.2 インシデ ント管 理

ＳＬＡ項目

L1

信頼性
稼働 率
目標 復旧時間(RTO)
目標 復旧時点時 間(RPO)
バッ クアップ間 隔
冗長 化
障害 監視間隔性能
シス テム応答時 間※１
処理 時間（ﾊﾞｯﾁ、ｵﾝﾗｲﾝﾄﾗﾝｻﾞｸｼｮﾝ等）
域内 回線帯域
キャパシテ ィディ スク容量
セキュリテ ィ不正 侵入対策※ ２
ウイ ルス対策※ ３
脆弱 性診断間隔
サポート
受付 時間
受付 要員

97.50%
設定な し
設定な し
設定な し
ミラーリ ング
60秒
設定な し
設定な し

L2

L3

L4

99.00%
99.90%
99.99%
24時 間
個別契約で設定
24時 間
個別契約で設定
24時 間
個別契約で設定
ミラーリング＋ ホットスワ ップ
レプリケ ーション
30秒
10秒
5秒
8秒

5秒
個別契約 で設定
個別契約で設定1秒

個別契約で設定
ＦＷの み
ホストのみ
1回／ 年

ＦＷ＋ＮＩＤＳ
ＧＷ＋ ホスト
1回／半年
1回／3ヶ月

FW+NIDS+HIDS
GW+ﾎｽﾄ+ﾏﾙﾁﾍﾞﾝﾀﾞ
毎月平 日9:00‑17:00
専任者なし

平日9:00‑20:00
9:00‑20:00×7D
一部専任者あり24h×7D
完全 専任者制※１：システム応答時間は、ベンダが直接契約等でコントロールできない要因（ユーザ側のアクセス回線等）も含まれる
ため、ＳＬＡ項目に設定する場合は、ベンダの責任範囲を明確に定義する必要がある。
※２：不正侵入対策には各種ソリューションがあるが、ここでは、FW（ﾌｧｲｱｳｫｰﾙ）＋NIDS（ﾈｯﾄﾜｰｸﾍﾞｰｽの侵入検知ｼｽﾃﾑ）＋HIDS（ﾎｽﾄﾍﾞｰｽの侵入検知ｼｽﾃﾑ）の組み合わせを L4 の対策と想定した。
※３：ウイルス対策には各種ソリューションがあるが、ここでは、GW（ｹﾞｰﾄｳｪｲ型ｳｲﾙｽ対策）＋ﾎｽﾄ（ﾎｽﾄｲﾝｽﾄｰﾙ型ｳｲﾙｽ対策）＋ﾏﾙﾁﾍﾞﾝﾀﾞ（複数ベンダのウイルス対策ソリューションを併用）の組み合わせを L4 の対策と想定した。

24「ＡＳＰ・ＳａａＳの情報セキュリティ対策に関する研究会」 総務省 平成１９年１０月１７日「ＳａａＳ向けＳＬＡガイドライン（案）」経済産業省 （独）情報処理推進機構 平成１９年１１月２１
日

27

略語
ＦＷ：Firewall
ＮＩＤＳ：ﾈｯﾄﾜｰｸ型 Intrusion Detection system
ＨＩＤＳ：ﾎｽﾄ型 Intrusion Detection system
ＧＷ：Gateway
RTO：Recovery Time Objective
RPO：Recovery Point Objective

5

IT サービス仕様書（サンプル）5.1

記載すべき事項
記載すべき内容は、IT サービスの種類により異なる。以下は共通に発生する項目を列挙する。

サービス名称

5.2

サービス内容可能な限り詳細に記述

サービス目標SLM、SLA

注意事項

注意制限事項、対象外、例外事項、など

受付時間

受付時間、対応時間、時間外対応、など

連絡先

通常時、緊急時「サーバ運用支援サービス」サンプル
以下に「サーバ運用支援サービス」のサービス仕様書（サンプル）を記載した。このサービス仕様書の中に書かれている内容は、あくまでもサンプルであり実際にサービス提供するためには、各ベンダのビジネスモデルとユーザ要求に合わせてさらに細かく調整し記述されるべきと考える。

28

サービス仕様書（サンプル）
サービス名称

サーバ運用支 援サービス

サービス内容① 電 話問い合わせサービス
・ ご契約いただいて いるサーバに関する技術的問合 せを、
フリーダイヤル、E-Mail、およびFAXにて 対応させていただきます。
② 障害切り分けサービス
・ ご契約いただいて いるサーバのトラブル発生時に、電話または必要に応じて、リモートにより接続して障害の切り分けをおこないます。
・ 監視ツールでエラーやアラートが検知された場合は、インターネットメー ルにて弊社コールセンターに通報します。
③ オンサイトサービス
・ ②の内容で障害の切り分けが解決しない場合、技術者の訪 問により障害の切り分 けを行います。
（注意）障害復旧に関しては、別途 契約「障害復旧支援サービス」などが必要となります。
対象サーバー ＜対象ＯＳ＞
および対象ＯＳ・ Windows 2000 Server（SP4以降）
・ WindowsServer2003StandardEdition
・ WindowsServer2003R2Standard Edition、2003EnterpriseEdition＜対象ハード環境＞（以下のサーバ管理エージェ ントが必須）
・ HP Proliantシリーズ
HPマネジメントエージ ェント・ NEC Express5800/100シリー ズ
NEC ESMPRO/ServerAgent
・ 富士通 PRIMERGY
富士通 Systemwalker
監視・通報項 目 ① ハードウェア障害監 視（サーバ管理エー ジェントによるハードウェアの監視）② オペレーティングシステム稼 動監視（CPU負荷状況、ディスク、メモリの空き容量監視）③ アプリケーション障害監 視（バックアップソフト、ウィルスソフト、BackOffice製品など）
注意事項① 1サイト環 境に限りの対応範囲 といたします。
② 障 害の切り分けまでとし、復旧及び ハードウェア修理またはそれらの支援は含みません。
③ サーバとネットワークインフラ環境 との障害は、原因の切り分けまでを対応とします。
④ サーバ以外のインフラの障害対応は、範 囲外となります。
⑤ サーバパッケージで無償提供 されている、以 下のサービスサポートは対 応範囲とします。
「WINS」、「DHCP」、「RRAS」、「IIS」、「DNS」、「Index」、「ターミナルサービス」⑥ ⑤以外のサービスは、対応 範囲外とします。
⑦ 以 下の項目は対応範囲外とします。
・弊社技術 者が対応、設定した箇所以外のトラブルおよび技術的問い合わせ・言語、開発、コンサルティングに関わるトラブルおよび技術的問い合わせ⑧ ハードウェア保守契 約をいただいているハー ド（サーバ）が対象となります。
⑨ リモートメンテナンスする場合、事 前にお客様のご了承をいただいて から接 続させていただきます。
⑩ インターネットや お客様ネットワークに通信障害が発生した場 合の通報不達
お よび連絡漏れに対 する責任は負いかねます。
⑪ このサービス ではお客様 のサーバで障害が発生した場合、障害の原因を究 明するためにお客様のイベントログファイルをいただいております。
ＳＬＡ・ＳＬＭ
別途「ＳＬＡ合意書」に記載
電話受付 時間 月〜金 9:00〜18:00（日曜日・祝祭日・弊社休業日は除 く）及び対応 時間 土
9:00〜12:00 13:00〜17:00
オンサイト
月〜金 9:00〜17:00（土・日曜日・祝祭 日・弊社休業 日は除く）
対応時間※上記時間外の対応の場合は別途有償作業となります。
連絡先
通常時： 弊社コールセンター・フリーダイヤル（電 話番号な どはご契約時にお知 らせします。）
緊急時： 弊社営業所 ｘｘ-ｘｘｘｘ-ｘｘｘｘ

29

6

参考資料
6.1

参考文献一覧

1. 『情報システムの信頼性向上のための取引慣行・契約に関する研究会〜情報システム・モ
デル取引・契約書〜（受託開発（一部企画を含む）、保守運用＜第１版＞』 経済産業省
商務情報政策局情報処理振興課 平成１９年４月１３日
http://www.meti.go.jp/policy/it̲policy/keiyaku/index.html
2. 『新「システム監査基準」、「システム管理基準」』 経済産業省商務情報政策局 平成１６
年１０月８日http://www.meti.go.jp/policy/it̲policy/press/0005668/
3. 『情報システムの信頼性向上に関するガイドライン』 経済産業省商務情報政策局 平成１
８年６月１５日
http://www.meti.go.jp/press/20060615002/20060615002.html
4. 『公共 IT におけるアウトソーシングに関するガイドライン』 総務省 平成１５年３月
http://www.soumu.go.jp/denshijiti/pdf/060213̲03.pdf
5. 『 JIS Q 20000-1:2007』 情報技術―サービスマネジメント―第１部：仕様
6. 『 JIS Q 20000-2:2007』 情報技術―サービスマネジメント―第２部：実践のための規範
7. 『共通フレーム２００７− SLCP-JCF２００７ −』 （独）情報処理推進機構（ＩＰＡ） 平成１９
年１０月１日8. 『JIS X 0161:2008（予定）』 ソフトウェア保守
9. 『サービスレベル契約（ＳＬＡ）に関する調査報告書』 （財）ソフトウェア情報センター（SOFTIC） 平成１７年３月
10. 『民間向けＩＴシステムのＳＬＡガイドライン＜第３版＞』 （社）電子情報技術産業協会（ＪＥＩ
ＴＡ） 平成１８年１０月２日
11. 『ＩＴアウトソーシングで失敗しないＳＬＡチェックポイント２９４』 （社）電子情報技術産業協会（ＪＥＩＴＡ） 平成１９年８月１３日
12. 『ＩＴサービス・リスクマネジメントとＳＬＡ −ＩＴサービスリスクのコントロール手段としてのＳＬ
Ａ− 』 （社）電子情報技術産業協会（ＪＥＩＴＡ） 平成１９年３月
13. 『地域企業の求めるＩＴサービスの利活用と費用対効果調査研究』 （社）日本コンピュータ
システム販売店協会（ＪＣＳＳＡ） 平成１９年２月
14. 『SI 事業者における脆弱性関連情報取扱に関する 体制と手順整備のためのガイダンス』（社）情報サービス産業協会（JISA） （社）電子情報技術産業協会（ＪＥＩＴＡ） 2005 年 8 月
http://www.jisa.or.jp/report/2004/vulhandling̲guide.pdf
15. 『ASP・SaaS の情報セキュリティ対策に関する研究会』資料 総務省 平成１９年１０月１７日
16. 『ＳａａＳ向けＳＬＡガイドライン（案）』

経済産業省 （独）情報処理推進機構 平成１９年１

１月２１日
http://search.e-gov.go.jp/servlet/Public?Pcm1010&BID=595207044

30