Comments
Description
Transcript
情報システムに係る政府調達への SLA導入ガイドライン
情報システムに係る政府調達への ＳＬＡ導入ガイドライン 平成１６年３月 独立行政法人情報処理推進機構 − 目 次 − はじめに ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 1 第１章 １ ＳＬＡの概要 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 4 ＳＬＭの目的 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 4 (1) 情報システムの外部委託における問題点 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 4 (2) ＳＬＭの重要性 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 5 (3) ＳＬＭの段階的向上 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 6 ２ ＳＬＡとは ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 7 (1) ＳＬＡとＳＬＭの定義 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 7 (2) ＳＬＡの目的と効果 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 7 (3) サービスレベルとは ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 8 (4) ＳＬＡの適用対象 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 9 (5) 契約とＳＬＡとの関係 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 11 (6) 費用とＳＬＡとの関連 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 13 ３ ＳＬＡの内容 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 14 (1) ＳＬＡの一般的な形式 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 14 (2) 前提条件 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 14 (3) 委託業務の範囲 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 15 (4) 役割と責任の分担 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 15 (5) サービスレベルの評価項目 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 15 (6) 結果対応 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 17 (7) 運営ルール ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 19 ４ サービスレベルの具体例 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 23 (1) サービスレベル評価項目の設定例 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 23 (2) サービスレベル評価項目の定義例 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 24 第２章 情報システムの政府調達へＳＬＡを導入する際の考慮点 ・・・・・・・・・・・・・・・・・・・・・ 26 １ 政府調達におけるＳＬＡの検討・作成・締結の時期 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 26 ２ 発注形態に応じたＳＬＡの導入 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 27 (1) 発注形態に応じたＳＬＡの検討・作成・締結のタイミング ・・・・・・・・・・・・・・・・・・・・・ 27 (2) ＳＬＡ導入に適した情報システム ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 28 ３ サービスレベルの位置付けに応じた政府調達プロセス上の取扱い ・・・・・・・・・・・・・・・・・ 30 (1) サービスレベルの位置付け ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 30 (2) 仕様書へのサービスレベルの記載 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 30 (3) 入札評価におけるサービスレベルの取扱い ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 30 第３章 情報システムの政府調達へのＳＬＡ導入ステップ ・・・・・・・・・・・・・・・・・・・・・・・・・・・ 31 １ ＳＬＡ導入のステップ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 31 ２ ＳＬＡの検討・作成 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 32 (1) 前提条件の整理 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 32 (2) 委託業務の範囲の定義 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 35 (3) 役割と責任の分担の定義 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 36 (4) 提供者の免責範囲の明確化 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 38 (5) サービスレベルの定義 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 40 (6) 結果対応の定義 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 42 (7) 運営ルールの設定 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 43 ３ ＳＬＡの提示・締結 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 45 ４ ＳＬＭの運営 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 46 (1) ＳＬＭ委員会の設置 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 46 (2) ＳＬＭ委員会の運営方法 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 46 (3) ＳＬＭ委員会における検討テーマ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 48 (4) ＳＬＭ委員会における資料イメージ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 49 おわりに ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 53 ■参考資料 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 57 参考資料１ 政府による情報システム調達に係る手順 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 58 参考資料２ 政府における情報システム関係業務の分類 ・・・・・・・・・・・・・・・・・・・・・・・・・・・ 60 参考資料３ 発注形態に応じた責任分担の考え方 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 62 参考資料４ 海外における取り組み事例 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 63 参考資料５ サービス料金と課金 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 66 はじめに わが国のＩＴサービス市場（約１４兆円、「平成１４年特定サービス産業実態調査」） における中央政府・地方自治体の調達は、現在約２．２兆円で、ＩＴサービス市場の約２ 割のウエイトを占めるに至っている。ＩＴ（情報技術）が急速に進歩するにつれ、経済社 会システムにおけるＩＴへの依存度はますます高まりつつあるが、このことは政府行政部 門においても例外ではない。 わが国における初めてのＩＴ戦略として策定された「e-Japan戦略」に続く次期ＩＴ戦略 として、２００３年７月に策定された「e-Japan戦略Ⅱ」においては、これまでに整備され つつあるインフラを活用して、国民が便利さを実感できる仕組みの構築が重視されている。 具体的には、国民にとって身近で重要な医療、食、生活、中小企業金融、知、就労・労働、 行政サービスの７つの分野における先導的取り組みが提案されている。 調達制度の改革は、電子政府の取り組みの一つとして行政サービス分野で取り上げられ ており、「業務の外部委託や調達制度の改革等により政府行政部門の業務効率の向上を図 り、財政支出を抑制しつつ、サービスの向上を実現する」とされている。その実現のため の方策としては、「調達に伴う手続きの合理化、透明性の向上、調達費用の低減、ベンチ ャー企業からの調達の一層の促進などを目指した調達制度の改革を促進する」こととし、 評価にあたっての考え方として、「政府行政部門は、住民や企業に対するサービスを低下 させることなくＩＴ導入を推進し、業務効率化と住民や企業に対するサービス改善を両 立」することがあげられている。 経済産業省においては、まず、度重なる安値落札の問題を受けて、２００１年１月に「ソ フトウェア開発・調達プロセス改善協議会」を設置し、同年１２月には「政府調達プロセ ス改善に向けて」と題する報告書をまとめた。これを受け、政府全体としても経済産業省 における検討を踏まえ、政府部内の府省横断的な組織として「情報システムに係る政府調 達府省連絡会議」（以下、本連絡会議という。）を新たに設置し、政府調達改善方策につ いて、２００２年４月２２日には、①「総合評価落札方式をはじめとする評価方式の見直 し」、②「競争入札参加資格制度をはじめとする入札参加資格制度の見直し」、③「調達 管理の適正化」の３項目からなる対策を申し合わせた。 このうち、③「調達管理の適正化」の項目のなかには、官民の責任分担を明確化した契 約書の導入の一つとして、サービスレベル契約（Service Level Agreement；ＳＬＡ）の導 入を検討することが明記されている。これは、調達先を選定するにあたっては価格評価を めぐる問題のみならず、技術やサービス等内容面からの評価を的確に行っていく必要があ - 1 - り、保守・運用段階においても要求されるサービスの品質が確保されているかを監視する ことが重要だとの認識に基づくものである。 ハードウェアの価格低下等を背景として、ソリューションビジネスの重要性が急激に高 まっている。民間業者であろうと政府調達であろうと、ユーザがＩＴサービスの評価を行 うにあたって、サービスの質を定量的に評価する尺度が確立されていないという問題が存 在する。しかしそのなかでも、情報システムの政府調達については、大手ベンダーがシス テム開発における極端な安値応札とその後の保守・運用を随意契約でする一括受注の慣行 とあいまって、保守・運用をはじめとするＩＴサービスの価格硬直化・高騰化を惹起して いるという現実もある。このため、とりわけ政府においては、政府とITサービスプロバイ ダーとの間の実現目標と双方の責任を明確に規定した文書のニーズが高まってきた。 このニーズに対応するため、本連絡会議事務局を担当する経済産業省商務情報政策局で は、ＳＬＡを政府調達に導入すべく、２００３年９月に有識者による「情報システムの政 府調達に係るＳＬＡ導入研究会」を設置し、検討してきた。その成果として、この度、本 ガイドラインをとりまとめるに至ったのである。 本ガイドラインを通じて、情報システム導入に伴うサービスの内容、レベルを確保する ためのＳＬＡの活用が促進され、調達管理の一層の適正化が期待される。さらに、政府調 達におけるユーザー・ベンダー両者による不透明なＩＴサービスサイクルの改善を図るこ とで、民間調達へのＩＴサービス評価が定着することも期待したい。加えて、政府調達に おけるＩＴサービス価格決定の一層の透明化が促進され、これを通じ、中小企業のＩＴサ ービス調達参入機会の増大も期待される。 ＳＬＡは提供されるべきサービスの水準等を定めたものであり、サービスレベル・マネ ジメント（Service Level Management；ＳＬＭ）において重要な役割を果たす。しかし、 その定義が未だ国際的に統一されていないことや、今後ＳＬＭのさらなる発展も想定され る。以上のような状況を勘案すると、本ガイドラインは政府部内はもとより地方自治体に おいても広く参照できる実施手順を示したものではあるが、今後修正されるべき記述を多 く含むものであることに留意する必要がある。 各府省の情報化統括責任者（ＣＩＯ）連絡会議が平成１５年７月に決定した電子政府構 築計画との関連では、エンタープライズ・アーキテクチャ（Enterprise Architecture；Ｅ Ａ）を基礎とした「業務・システム最適化計画」の構築が進められている。 ＥＡは、政府の情報システムの基本図面になるものであり、業務のモデル、業務で使う ためのデータのモデル、業務を円滑に行うためのサービスコンポーネントのモデルとそれ - 2 - らを支える技術のモデルにより構成される。この中のサービスコンポーネントモデルでは、 業務を実行するためにシステムが提供する基本サービス毎にシステムをコンポーネント化 することがＥＡ導入で先行している米国政府において検討されており、そのサービスをも とにシステム機能のサービスレベルを設定することもその検討の中で考えられている。ま た、業務のモデル毎に成果指標を設定する業績測定参照モデルもＩＴアソシエイト協議会 で検討が行われてきており、業務としての業績指標を定義しようとしている。これらの動 きと整合性を取りながら、ＳＬＡについて今後とも検討を進めていくこととしたい。 平成１６年３月 情報システムの政府調達に係るＳＬＡ導入研究会 座長 - 3 - 櫻井 通晴 第１章 １ ＳＬＡの概要 ＳＬＭの目的 (1) 情報システムの外部委託における問題点 近年、情報システムに関する業務の外部委託を行う企業が増加しており、委託内容も システム開発、システム保守、ネットワーク運用、ホスト運用、サーバ運用、ヘルプデ スク、クライアント機器管理など多岐にわたっている。 外部委託が増加するにつれ、サービスの委託者（以下、委託者とする）からは「期待 していた内容や品質のサービスが提供されない」という不満が、サービス提供者（以下、 提供者とする）からは「約束していない過剰な要求をされる」という不満があがってい る。これは、業務、サービス内容、提供範囲、サービス品質、料金体系に関して、委託 者と提供者間の認識が異なることが大きな原因となっているからである。これらは問題 が現実化して初めて認識の相違が明らかになり、トラブルへと発展する例が数多くみら れるようになった。 このように、委託者と提供者の間で認識の相違が生じる原因は、そもそも有体物の製 品とは異なり、サービスはその評価を行うことが難しいなかで、契約の段階で業務の重 要度に応じたサービスの内容や水準などが文書に明確化されておらず、思い込みや担当 者間の口約束への過信、文書化されている場合であっても曖昧な表現が用いられている ことなどにある。情報システムの外部委託における問題点については、以下に述べると おりである。 ① 不透明なサービス範囲と水準から起こる問題 委託者と提供者の役割分担と責任の所在に曖昧な部分が存在すると、具体的な業務の 中でどの部分が外部委託の対象になっているかについて、委託者と提供者の間で食い違 いが生じる場合がある。また、委託者が期待するサービスの水準と、提供者が想定して いる水準が異なっている場合もある。 委託者にとっては、費用を支払うことにより何がどれだけ提供されるのかが、実際に サービスが提供されるまで、あるいは、問題が発生するまで正確にはわからないという ことが問題である。他方、提供者にとっては、契約通りのサービスを提供していると思 っているにもかかわらず、委託者からサービスの追加や想定以上の品質を求められると いう問題が生じる。 ② 不透明なコスト構造から起こる問題 情報システムなど関連するサービス費用の見積りは、サービス項目ごとの単価の積算 による料金算定根拠が明示されない場合には、提供者から提示された費用が適正である か否か（高いのか安いのか）を委託者が検証することは難しい。特に、政府の情報シス テムのように他に同様のシステムが存在しない場合には、費用の検証が困難である。ま - 4 - た、サービス品質の水準と費用の関係について、委託者と提供者の間の共通認識が形成 されていない場合にも、適切な水準に関する合意が難しい。 ③ 不透明な環境変化から起こる問題 長期契約においては、契約期間中にさまざまな状況の変化が起こり得る。外部委託し ている業務の量的変化や、業務システムの更改、人材調達市場の価格変化、技術革新な どは、コストの増加・減少の要因になる。特に重要な要因は「サービス提供者による生 産性向上」である。しかし、これらが契約に明示されない場合、将来的にみて情報シス テムの外部委託が最適な手段なのかどうかを委託者が判断できず、提供者が長期にわた って委託者のために努力を続けてくれるのかどうかも保証されない。 (2) ＳＬＭの重要性 これまで、情報システムの外部委託契約では、委託者と提供者の間で、サービス提供 の前提、サービス品質等について明確に規定されることは稀であった。しかし、前述し たように、契約上の曖昧さが、サービス提供時のトラブルの原因になっている。 そこで、委託者と提供者の間で誤解や不満が起こる原因であった曖昧さの排除を目的 として、契約時に、双方の間でサービス品質の水準を明確にするＳＬＡが取り決められ、 サービス実施期間を通じて、業務の重要性等を踏また上でのＳＬＡに基づいたＳＬＭが 実施されるようになってきた。 適切なＳＬＭは、委託者、提供者の双方にとって、次のような利点をもたらす。 ○ 委託者側にとっては、期待通りのサービスが享受でき、委託者としての権利の確 保が可能となる。 ○ 提供者側にとっては、提供責任を明確にし、これを全うしたことを証明できる。 契約文書として、サービスの内容及びサービスの提供の前提に加え、サービスレベル を明確化することによって、委託者と提供者間の認識の相違をなくし、コスト構造の合 理性を高めることができる。また、ＳＬＭの内容と方法を明確化することによって、継 続的なサービスレベルの改善が容易になることが期待される。ＳＬＭは、一般に、以下 のような４段階を経ることになる（図表１−１）。継続的な管理を行うことを通じて、 サービスレベル改善のための努力を続けることが重要である。 ・ 初期段階 ：ＳＬＭが未導入の段階 ・ 導入段階 ：ＳＬＭが導入された段階（約１年） ・ 定着段階 ：ＳＬＭが定着した段階（導入後約１年以降） ・ 改善段階 ：ＳＬＭが継続的に改善されていく段階 - 5 - 図表１−１ 継続的なマネジメントによるＳＬＭ改善の段階 ＳＬＭ ・改善段階 ・定着段階 ・導入段階 ・初期段階 (3) ＳＬＭの段階的向上 年 初期段階は、ＳＬＭが未導入の段階である。民間企業ではアウトソーシングの進展に 伴ってＳＬＭを導入しつつある。 導入段階は、ＳＬＭが導入された段階であり、そのためには、ＳＬＭを導入するため に様々な準備が必要になる。準備作業には、重要なサービスの洗い出し、そのサービス についてのレベルの設定、サービスレベルの未達時等への対応方法の設定、その他ＳＬ Ａに基づく運営ルールの設定等がある。民間企業の例では、導入準備に半年から１年を 費やすことが一般的であり、特に委託者が理想的なサービスレベルにしようとするのに 対して、受託者が現実的なサービスレベルにしようとする中で、合意点を見出すことに 時間がかかっている。 定着段階は、導入準備で定めたＳＬＡに基づく運営ルールに従った運営がなされて、 ＳＬＭが定着した段階である。この段階では、サービスレベルが定期的に監視され、異 常があった場合は受託者が適切な対応を取り、サービスレベルの状況と異常時対応など が定期的に報告され、その報告について、委託者及び受託者がサービスを改善するため に建設的な議論がなされている状態である。民間企業の例では、このような段階になる までに１年以上かかっている。 改善段階は、ＳＬＭが継続的に改善されていく段階である。この段階では、ＳＬＭ自 体を改善するための議論が委託者及び受託者の間で行われている状態である。このよう にＳＬＭは継続的に向上していくことが重要である。 - 6 - ２ ＳＬＡとは (1) ＳＬＡとＳＬＭの定義 ＳＬＡ(service level agreement)は、提供されるべきサービスの水準等を定めたもの で、ＳＬＭにおいて、最も重要な役割を果たす。ＳＬＡについては、国際的に統一され た定義はなく、さまざまな定義がなされているのが現状であるが、本ガイドラインでは、 ＳＬＡを以下のように定義する。 ■ ＳＬＡの定義 ■ ＩＴサービスの提供者と委託者との間で、ＩＴサービスの契約を締結する際に、提 供するサービスの範囲・内容及び前提となる諸事項を踏まえた上で、サービスの品質 に対する要求水準を規定するとともに、規定した内容が適正に実現されるための運営 ルールを両者の合意として明文化したもの。 ＳＬＡは、委託者と提供者双方による合意の結果として、提供されるサービス品質の 水準を明確に規定するものであり、契約文書の一部もしくは独立した文書として締結さ れる。 ＳＬＭ(service level management)は、ＳＬＡの締結を含むサービスレベルの管理に 関する全体の活動を示すものである。本ガイドラインでは、ＳＬＭを次のように定義づ ける。 「ＳＬＡを締結し、その合意内容が適正に実現され、状況の変化に応じて柔軟に運用 されるように、委託者と提供者の間で取り決められたＳＬＭ、運営の仕組み（ルール、 プロセス、体制）を構築・運営すること」である。 (2) ＳＬＡの目的と効果 ＳＬＡ締結の目的は、サービス提供における不透明さを解消して、適正なＳＬＭを実 現することにある。ＳＬＡ締結時に、以下の点を明確化することによって、不透明さを 取り除くことができる。 ① サービス品質への要求水準の明確化 ② サービス内容・提供範囲・水準と費用との関係の明確化 ③ 運営ルールの明確化 ＳＬＡを締結することは、図表１−２に示すように、委託者と提供者双方にメリット がある。まず、共通のメリットとして、委託者と提供者との間の共通認識のもとで、Ｓ ＬＭを行うことができるようになる。さらに、委託者側は、適切なサービスレベルを確 保することができ、提供者側は、契約したサービスを適切に提供していることを委託者 に説明することができるようになる。 - 7 - 図表１−２ ＳＬＡの目的と委託者・提供者のメリット 委託者側のメリット サービスレベルの妥当性確保 目的 サービス料金の合理性確保 サービス品質への要求水準の 明確化 継続的管理によるサービスレベルの維持 ・向上 サービス内容・提供範囲・水準 と費用との関係の明確化 サービスの内容・提供範囲・要求水準に 関する共通認識の形成 サービス提供の責任範囲の明確化 運用管理ルールの明確化 委託者に対する説明責任の実現 提供者側のメリット (3) サービスレベルとは サービスレベルとは、提供者から委託者に対して提供されるサービスのレベルであり、 サービスレベルはサービスの可用性や納期など利用者の立場から意味のある項目で評価 される。また、サービスレベルを評価する際には、客観的で制御・測定が可能であり、 委託者と提供者の間で合意できる指標を定義する。 ここで、ひとつのシステムを取り上げて、サービスレベルとはどのようなものである かを具体的に説明する。 例えば、次のような要件を持つシステムがあると仮定する。 ① 利用者に対して、１日あたり 24 時間・365 日、提供者が運用するサーバから、オ ンラインでサービスを行う必要がある ② 利用者の業務上の必要性から、利用者が操作してからシステムが応答するまでの 時間（応答時間）は、3 秒以内である必要がある ③ 前日の入力を夜間にバッチ処理し、委託者が指定する場所に、毎日朝 9 時までに 帳票を届ける必要がある このような場合、それぞれの要件に対して、次のようなサービスレベルを設定するこ とになる。サービスレベル達成に必要となるリソースや費用は、システム稼働環境、業 務データ量、ピーク時、ユーザ数等の条件によって異なる可能性が高いので、サービス レベルはこれらの前提条件を明確にした上で設定する必要がある。 ① サーバ可用性 予定された稼働時間のうち、どのくらいの間、正常に利用できたかをサービスレベル として設定する。例えば、1000 時間の計画稼働時間のうち、1 時間だけ、サーバがダウ - 8 - ンして、システムが利用できなかった場合には、サーバ可用性は、99.9％（｛1−（1／ 1000）｝×100）となる。 ② 基準応答時間達成率 利用者からの操作に対するシステムの応答時間を計測し、そのうち、基準応答時間で ある 3 秒以内にどの程度応答できたかを、サービスレベルとして設定する。1000 回の操 作のうち、2 回だけ 3 秒以上かかったとすると、基準応答時間達成率は、99.8％（｛1− （2／1000）｝×100）である。 ただし、端末レベルでの日常的な応答時間の計測が技術的に困難な場合、システムの 内部応答時間により代用することができる｡ ③ 帳票デリバリ時間遵守率 指定された各拠点に対して、内容を間違いなく出力した帳票を、指定時間の午前 9 時 までに配達できた比率を、サービスレベルとして設定する。例えば、365 日のうち、1 日 だけ守ることができなかった場合は、帳票デリバリ時間遵守率は、99.7％（｛1−（1／ 365）｝×100）となる。 (4) ＳＬＡの適用対象 まず、ＳＬＡの適用対象とする情報システム関係業務について述べる。情報システム 関係業務において調達の対象となる業務は、図表１−３に示すように、企画、設計・開 発、保守・運用の３つである（「参考資料２ 政府における情報システム関係業務の分 類」を参照のこと）。これらはＳＬＡ適用の候補となり得る業務と考えられる。 図表１−３ 情報システム関係業務の３つの段階 企画段階 設計・開発段階 情報システム構築 保守・運用段階 ITサービス提供 これら３つの業務のうち、 ＳＬＡの導入は、情報システムによるサービスが実際に提 供され始める保守・運用段階が適している。なぜなら、企画段階や設計・開発段階の業 務は、業務の性格上、同一システムに対して何回も繰り返して行われるものではないた め、サービスの品質を継続的に測定する評価方法が適さないからである。保守・運用段 階の業務は、同一性の高いサービスが反復的かつ継続的に提供されるため、ＳＬＡによ るＳＬＭが有効であるといえる。 次に、保守・運用段階におけるＳＬＡの適用領域について述べる。図表１−４のよう に、情報システムの保守・運用段階における業務を一括外注した場合、個別の業務につ - 9 - いては、提供者の責任により、提供者の内部で管理されることになる。すなわち、委託 者は、システム全体で提供されるサービス（オンラインサービスの稼働率、稼働時間、 帳票到着時間等）を管理すればよいことになる。 図表１−４ 一括で業務を外注した場合のＳＬＡの適用対象（例） 提供者 個別業務サービス データ 入力 システム 運用 データ 出力 委託者 トータルシステム サービス 例） 帳票配達 ・翌日9時到着 ・誤送なし ・内容に誤りなし データ管理 システム資源管理 安全対策 メンテナンス ＳＬＡ 提供者内部の管理 一方、これらの業務を個別に外注した場合には、図表１−５のように、委託者は提供 者ごとにＳＬＡを締結する。 図表１−５ 個別に業務を外注した場合のＳＬＡの適用対象（例） 提供者Ａ システム運用 委託者 ＳＬＡ 提供者Ｂ データ出力（帳票配達） ＳＬＡ 提供者Ｃ ヘルプデスク ＳＬＡ - 10 - (5) 契約とＳＬＡとの関係 ＳＬＡに記載するサービスレベルの項目には、以下の２つの種類がある。 ○ 目標保証型（取り決めたサービスレベルを保証する義務を負う） ○ 努力目標型（取り決めたサービスレベルが努力目標にとどまる） サービスレベルの項目ごとに、目標保証型であるか努力目標型であるかが決められる｡ したがって、ＳＬＡに記載されるサービスレベルの項目は、全てが目標保証型もしくは 努力目標型である場合、目標保証型と努力目標型の両方が含まれる場合がある。 図表１−６に、目標保証型と努力目標型それぞれのメリットとデメリットを示す｡ 図表１−６ 目標保証型 委託者からみた選択の留意点 メリット デメリット ・委託者と提供者の間で目標／評 ・目標値が硬直的になり、サービス レベルの見直しが困難である 価指標が明確になる ・責任とその代償を明確にするこ ・提供者が、適用範囲を制限する、 あるいは、リスク回避のために過 とができる 剰なリソースを前提とした価格を 提示するため、契約金額が高騰す る 努力目標型 ・委託者と提供者の間で目標／評 ・目標値の達成が法的には保証され ない（改善努力の意識は維持可能） 価指標が明確になる ・弾力的な運用が可能である 目標保証型であれ、努力目標型であれ、サービスレベル（評価項目、要求水準）を設 定し、提供者が、サービスレベルの達成・維持に向け、改善努力を継続的に実施する点 は共通している。ただし、目標保証型の場合は、サービスの提供者にサービスレベルの 維持と改善努力をより強く要請することになる。 ＳＬＡは、契約時に附属資料として契約書に添付されることが一般的である。この場 合、契約書（本文）に、件名、金額、納入場所、期間、契約条項など基本的な内容が盛 り込まれ、附属資料として契約内容を詳細に記述した仕様書等を添付する。ＳＬＡは、 次図の点線部分のように、仕様書の中に記述される。 また、契約の時点でサービスレベルを確定できない場合には、契約書にはＳＬＡを締 結する旨を記載し、別途、ＳＬＡを締結することも可能である。 図表１−７にそれぞれの場合の契約書の構成例を示す｡ - 11 - 図表１−７ 情報システムの保守・運用契約書の構成例 ① 契約書の附属資料としてＳＬＡを締結する場合 契約書（本文） ■件名 ■金額 ■納入場所 ■期間 ■契約条項 附属資料 ■前提条件 ■委託業務の範囲 ■役割と責任の分担 ■サービスレベル ■結果対応 ■運営ルール ■実施体制 ■移行ルール ■教育支援・研修 ■ドキュメント作成 ※ＳＬＡは点線で囲まれた部分 ② 契約書とは別途ＳＬＡを締結する場合 契約書（本文） ■件名 ■金額 ■納入場所 ■期間 ■契約条項（ＳＬＡを締結する旨、主要なサービスレベル評価項目等を記載） 附属資料 ■前提条件 ■委託業務の範囲 ■役割と責任の分担 ■実施体制 ■移行ルール ■教育支援・研修 ■ドキュメント作成 ＳＬＡ （■前提条件 ■サービスレベル ■委託業務の範囲 ■役割と責任の分担） ■結果対応 ■運営ルール ※前提条件、委託業務の範囲、役割と責任の分担に関しては、原則として、契約 書（本文）に記載されるが、ＳＬＡを締結するに当たって必要となる補足的な 項目がある場合は、ＳＬＡに記載する。 なお、契約書（本文）には、以下のような契約条項が記載される。 適用対象、権利義務の譲渡等、一括委任又は一括下請負の禁止等、特許権の使 用等、監督、役務行為完了の通知、役務行為完了の検査の時期、所有権移転の 時期、瑕疵担保責任、対価の支払い、遅延利息、違約金、契約の解除、損害賠 償、秘密の保持、資料等の管理、成果の取扱い等、紛争の解決方法 - 12 - (6) 費用とＳＬＡとの関連 提供者は、委託者が要求するサービスレベルをもとに、そのサービスレベルを継続的 に保証するために必要となるリソースの費用を積算し、費用に反映させることになる。 サービスレベルを測定・管理すること自体に費用を要することはもちろん、委託者が 要求水準を高めると、提供者がそのサービスを提供するためのリソースを増強する必要 がある場合には、費用が増加すると考えられる。また逆のケースもある。委託者は、こ のようなサービスレベルと費用の関係を理解した上で、適切なサービスレベルを定めな ければならない。 一方、提供者は、委託者に対して、サービスの内容やサービスレベルに応じた合理的 で適切な料金を提示することが求められる。 - 13 - ３ (1) ＳＬＡの内容 ＳＬＡの一般的な形式 ＳＬＡは、一般的に、次の項目から構成される｡ ○ 前提条件 サービスレベルに影響を及ぼす前提条件 ○ 委託業務の範囲 委託者が提供者に委託する業務の範囲 ○ 役割と責任の分担 委託業務に関する委託者と提供者の役割と責任の分担 ○ サービスレベル ＳＬＭの対象とするサービス、委託者が業務に必要と判 断するサービスレベル及びその測定方法 ○ 結果対応 サービスレベル未達成時の具体的な対応方法 ○ 運営ルール ＳＬＭのための報告・会議体の運営ルール 各項目に関する作業内容を、図表１−８に示す｡ 図表１−８ ＳＬＡの構成 項目 前提条件 作業内容 サービスレベルに影響を及ぼす業務量、端末数、拠点数等 の前提条件を明確にする。 委託業務の範囲 外部委託する業務の分析を行い、具体的にどのような業務 を委託するかを整理する。 役割と責任の分担 サービスを構成する個々の業務プロセスに関して、委託者 と提供者のどちらがどのような役割を果たし、その実施に 対して責任を持つかを明確化した表を作成する。 サービスレベルの評価項目 サービス管理の対象となるサービスを決定し、サービスの 水準を評価するための客観的で測定可能なサービスレベル 評価項目と要求水準を設定する。数値や算定式などを用い た評価項目の定量的な測定方法を定義する。 結果対応 サービスレベルが達成されなかった場合の委託者、提供者 それぞれの具体的な対応方法を設定する。 運営ルール 年度、月次の報告ルール、ＳＬＡを適切に維持するための 会議体運営のルールを設定する。 ※ＳＬＡ締結に必要な前提条件、委託業務の範囲、役割と責任の分担については、 契約書の内容を補完する事項がある場合にのみ、ＳＬＡに記載する。 (2) 前提条件 サービスレベルを決定する際には、サービスレベルに影響を及ぼすと考えられる委託 者側の前提条件を明確にすることが重要である。前提条件には、主に、業務上の前提条 件とシステム上の前提条件がある。業務上の前提条件は、業務量や拠点数、利用者数な どであり、システム上の前提条件は、ハードウェアの構成及び性能、ソフトウェアの構 成や品質などである。 - 14 - (3) 委託業務の範囲 委託者は、外部に委託したい業務を分析し、個々の業務プロセスに分割し、整理する。 これは、委託者が外部に委託する業務の内容を的確に把握し、次項で述べる各業務プロ セスに対する役割と責任を明確にするための準備作業であるため、役割と責任を委託者 と提供者に割り振ることができる程度に分割することが望ましい。 (4) 役割と責任の分担 外部に委託する業務を個々の業務プロセスに分割し、それぞれのプロセスに対して、 誰がどのような役割を担い、責任は誰が負っているのかを明確にしておくことが必要で ある。役割や責任の分担が曖昧な状態では、問題が発生した場合に、迅速で適切な対応 を実施できず、委託者と提供者の間で責任の所在をめぐって問題が生じることも考えら れるからである。具体的には、業務プロセスごとの役割と責任を明確化するために、図 表１−９に示すような責任分担表を作成する。 図表１−９ プロセス システム運用 媒体管理 サブプロセス 稼動管理 ・・・・ 在庫管理 入出庫管理 廃棄 帳票運用 ・・・・ 帳票出力・仕分け 発送 廃棄 ・・・・ (5) ・・・・ ・・・・ 責任分担表の例 アクティビティ スケジューリング JOB登録 オペレーション ・・・・ 在庫調査 保管庫からの出庫 保管庫への入庫 データ消去 廃棄業者への引渡 ・・・・ 帳票出力・仕分け 配送業者への引渡し 配送 シュレッダー廃棄 廃棄済報告連絡 ・・・・ ・・・・ 委託者 提供者A 提供者B ● ● ● ● ● ● ● ● ● ● ● ● ● サービスレベルの評価項目 サービス管理が必要なサービスごとに、達成すべきサービスレベルを定義する。具体 的には、サービスレベルを測定するための評価項目を設定し、各項目が満たすべき水準 を具体的に決定する。 ① ＳＬＭの対象とするサービス 情報システム保守・運用サービスは、実際には、複数の個別サービスから成り立って いる。これらのサービスの中から、ＳＬＭを行う必要がある業務、サービスを決定する 必要がある。 - 15 - サービスにトラブルがあった場合に業務に与える影響等を考慮した上で、優先順位を 決め、重要度の高いものから、対象とするサービスを決定する。多くの評価項目を設定 してサービスレベルを管理することは可能であるが、コスト上昇の原因になるため、重 要度の低いサービスを対象から除外するなど、ある程度絞り込むことが重要である。 ② サービスレベルを測定するための評価項目 ＳＬＭの対象とするサービスを決定した後、そのサービスに対してどの程度のサービ スレベルを要求するかを検討する必要がある。サービスレベルを決定する際に重要なこ とは、曖昧な言葉で記述するのではなく、委託者と提供者の間で認識の相違が起こらな いように、「客観的」で「測定可能」な形で決めておくことである。具体的には、サー ビスレベルを評価するための評価項目を決定し、その測定方法を数式等により定義する ことになる。 例えば、「ＬＡＮが週７日 24 時間常に使用可能であること」が求められる場合は、「Ｌ ＡＮの稼働率」や「障害復旧時間」のような評価項目を設定する。 サービスの実施を客観的かつ定量的に管理するためには、サービスレベル評価項目は、 委託者の要求を可能なかぎり定量的に表現する必要がある。また、提供者にとっても、 サービス提供に必要なリソースやコストの予測をより明確にする必要があるため、定量 的に表現したものでなければならない。 例えば、「ＬＡＮの稼働率」や「障害復旧時間」の場合、以下のように、算定式や数 値で決めておく。 （１ヶ月の稼動予定時間 − 停止時間） ・ＬＡＮの可用性 ＝ × 100 （１ヶ月の稼動予定時間） ・障害復旧時間 ③ ：１時間以内 評価項目に対する要求水準 サービスレベルの評価項目に対して、要求水準をどの程度に設定するか決める必要が ある。サービスレベルの要求水準を高く設定すれば、費用が高くなる可能性も高いため、 必要以上に高い要求をするのではなく、必要性と費用とのバランスを考慮した上で決定 することが望ましい。 サービス内容に対する評価項目と要求水準を設定するにあたっては、委託者、提供者 ともサービスレベルに影響を及ぼす前提条件を記述する必要がある。両者の前提条件を 満たす場合にのみ、サービスレベルの保証が行われるという考え方が基本となっている からである。サービス提供時に、前提条件が大きく異なってしまった場合は、サービス レベルの再検討が必要となる。 また、業務に与える影響の大きさを考慮し、サービス対象に応じた要求水準を設定す - 16 - ることも重要である。 (6) 結果対応 ＳＬＭの目的は、業務に必要とされているサービスのレベルを、委託者と提供者が協 力しながら達成、維持、改善していくことにある。したがって、ＳＬＡで規定されたサ ービスレベルが達成されなかった場合、提供者側に一層の努力を促し、サービスレベル を達成させることが重要であり、必ずしも提供者にペナルティを課すことが優先される べきとはいえない。そのため、サービスレベルを達成するにはどのような対応を提供者 側が行わなければならないかを、あらかじめＳＬＡに盛り込んでおく必要がある。 一方、実際のサービスレベルがＳＬＡで規定されたレベルを上回った場合、連続して 達成した場合、プロセス改善などにより所与のサービスレベルの改善を実現した場合、 インセンティブとして、提供者に対して報奨金等を与えることもある。この場合、イン センティブは、提供者側の一層の企業努力を引き出すことを期待して設定される。また、 インセンティブをペナルティに対しての免責として付与し、インセンティブとペナルテ ィを相殺する場合もある｡ サービスの結果に対する対応には、図表１−１０に示すように、運用上、財務上、契 約上のものがある。 図表１−１０ 結果対応の種類と概要 種類 概要 運用上の対応 サービスレベルが未達成の場合、リソースの増強や代替手段の適用など 具体的な対応方法を規定しておく｡提供者は、業務への影響や緊急性等の 重要性に基づき、暫定的、中長期的に必要な措置を講じる｡ 財務上の対応 サービスレベルが未達成の場合、サービス提供者にサービスレベルの改 善を促すため、金銭的なペナルティを設定することがある｡金額は、問題 の深刻さ、頻度等の要因から算定する｡一般に、ＳＬＡは提供者に改 善行動を促すことを目的としており、提供者の経営に深刻な打撃を与 えない程度に収められることが多い｡ 高いサービスレベルが達成された場合、委託者はインセンティブとし て報奨金を提供者に支払うことがある｡報奨金の算出方法に関して は、ＳＬＡであらかじめ取り決めておく必要がある｡ 契約上の対応 サービスレベルの未達成が頻繁に繰り返される場合や、サービスレベル が極めて低水準となる場合に備えて、契約解除条件を設定しておく。 高いサービスレベルが達成された場合、民間企業の場合、契約の延長 や次期契約の優先的交渉などによって、契約上のインセンティブを与 えることがある｡ 運用上の対応としては、サービスレベルが未達成の場合、リソースの増強や代替手段 の適用などがある。委託者は、業務への影響の緊急性や重要性を踏まえた対応可能な措 - 17 - 置について提供者から提案を受け、その実行を承認、指示する必要がある。 財務上の対応としては、提供者はサービスレベルを達成できなかった提供者に対して、 ペナルティを課すこともできる。ただし、一般には、ペナルティは提供者の怠惰への牽 制手段として用いられる性格のもので、契約書で定められている損害賠償とは別に定め られているが、一方で｢損害賠償の予定｣であるとの解釈も存在する。ペナルティには、 月額費用の何％というような計算方法などが考えられる｡一方、高いサービスレベルを達 成した提供者に対して、インセンティブとして、報奨金を提供する場合もある｡ 契約上の対応としては、次回契約更新時の入札資格停止等のペナルティや、次期契約 の優先的交渉等のインセンティブなどがある。 以下に、財務上の対応として、ペナルティ／インセンティブの金額を計算する方法の 例を示す｡ペナルティあるいはインセンティブを与える場合、ペナルティ／インセンティ ブの対象となるサービスを特定し、ペナルティ／インセンティブ行使の対象となるサー ビスレベルを記述する。各々のサービスについて、「業務への影響度」を設定する。業 務への影響度は、サービスレベルが未達成／達成された場合の業務へに与える影響度を 勘案し、設定する。業務への影響度の合計が 100％となるように按分する。 サービスの月額料金からペナルティを差し引く、あるいはインセンティブを加算する 方式で実施する場合、月額料金に占めるペナルティとインセンティブの上限を設定する。 なお、民間企業の場合のペナルティ／インセンティブの上限は、10∼25％程度といわれ ている。 ＳＬＡで規定した計算方法に基づいて、月毎にペナルティ／インセンティブを計算す る。委託者は、サービス毎にペナルティ／インセンティブ発生の有無をチェックし、そ の結果と、業務への影響度、ペナルティ／インセンティブの上限に基づいて、当月ペナ ルティ／インセンティブ率（サービスの月額料金に対する比率）を算出する。月額サー ビス料金に当月ペナルティ／インセンティブ率が掛け合わされ、ペナルティ／インセン ティブ額が算出される。 ペナルティ／インセンティブの具体的な計算例を示す。図表１−１１で示した例では、 オンライン運用、バッチ運用、帳票デリバリに関して、ペナルティ／インセンティブを 設定している（この例では、ヘルプデスクに関しては設定していない）。 図表１−１１ サービスに対する業務への影響度の設定(例) サービス オンライン運用 バッチ運用 帳票デリバリ ペナルティ／インセンティブの 対象となるサービスレベル 可用性○○％以上 ○時間以上停止月間○回以内 バッチ終了時刻までに完了率○○％ 月間作業ミス○回以内 指定到着時刻での配送完了率○○％ 月間誤配○回以内 業務への影響度(%) 50 30 20 100 - 18 - 図表１−１２は、ペナルティ／インセンティブ計算書である。 図表１−１２ ペナルティ／インセンティブ計算書（○○年○月）(例) サービス 業務への影響度（％） オンライン運用 バッチ運用 帳票デリバリ ヘルプデスク 業務への影響度当月合計 ペナルティ／インセンティブの上限 当月ペナルティ／インセンティブ率 当月サービス料金請求予定額 ペナルティ／インセンティブ額 当月実請求額 50 30 20 − （X） （A） （Y=A×X） （B） （C=B×Y/100） （D=B＋C） ペナルティ・ インセンティブ発生※ ○ × ○ − -30% 20% -6% 10,000千円 -600千円 9,400千円 ※）ペナルティ・インセンティブ発生 通常（ﾍﾟﾅﾙﾃｨ/ｲﾝｾﾝﾃｨﾌﾞ無） ：○ ﾍﾟﾅﾙﾃｨ発生 ：× ｲﾝｾﾝﾃｨﾌﾞ発生 ：◎ ﾍﾟﾅﾙﾃｨ/ｲﾝｾﾝﾃｨﾌﾞ運用対象外 ：― サービスレベルの評価項目については、インフラ災害、電源供給の停止、通信障害等 インフラにおける大きな障害による事由及び委託者側の事由によって、提供者側が要求 水準を達成できなくなる場合が想定されるため、事前に、ＳＬＡの適用対象外となる免 責事項を設定しておく必要がある（図表１−１３）。 図表１−１３ 免責事項の設定例 ■ (7) 顧客への障害告知における免責事項の例： ・ 委託者側の都合によって障害復旧が行えなかった場合 ・ 委託者側の事由によって障害通知を受け取ることができなかった場合 ・ 委託者側の事由によって障害監視ができない場合 運営ルール ＳＬＡを実効性あるものとするためには、サービス稼動後のＳＬＭのための仕組みを 設ける必要がある。そのためには、ＳＬＭ委員会を設置し、その運営ルールを明確化す ることによって、契約期間中の状況変化に対応する体制を整えることが重要である。 図表１−１４に、ＳＬＭ委員会の構成と検討事項の例を示す｡ - 19 - 図表１−１４ ＳＬＭ委員会の構成と検討事項 ＳＬＭ委員会 委託者 ● 情報システム部門 ● サービス受益部門 ※ 提供者との契約の 主管 ＜年度毎の検討事項（例）＞ ・ 過年度実績報告 ・ 過年度実績評価 ・ サービスレベル設定の妥当性確認 ・ 契約更改（期間、費用） ＜月毎の検討事項（例）＞ ・ サービスレベル達成状況報告 ・ 課題の共有 ・ 改善策、対応方針の検討 提供者 ● 統括責任者 ● 各サービス担当責任者 −設計・開発 −保守 −運用 等 外部の第三者 ＜ＳＬＭ委員会の側面支援＞ ・ サービスレベル設定支援 ・ サービスレベルの妥当性評価等 ＳＬＭ委員会は、原則として、委託者と提供者によって構成される。 委託者からは、情報システム部門だけではなく、実際のサービス受益部門（利用者） が参加する必要がある。サービスレベルと費用はトレードオフの関係にあるため、サー ビス受益部門自らによる判断が重要になる。このような理由から、サービス受益部門か らのＳＬＭ委員会への参加は必須なのである。委託者は、ＳＬＭ委員会に臨んでは、モ ニタリングとサービスレベル低下時の原因追求を行うことが役割となる。 提供者からは、サービス提供全体に対して意思決定ができる統括責任者と各サービス 担当責任者が参加する必要がある。提供者は、ＳＬＭ委員会に臨んでは、サービスレベ ルの達成状況を報告するとともに、サービスにおける課題に関する情報を委託者と共有 し、課題解決のための対応方策について提案する役割を担う。 委託者と提供者のほかに、ＳＬＭ委員会にコンサルティング会社など外部の第三者が 参加する場合がある。その役割は、サービスレベルが類似ケースに照らして偏っていな いかどうか（妥当性評価）、サービスレベルの設定が合理的に行われているかどうか（設 定支援）を行うことにある。 ＳＬＭ委員会には、検討内容や目的に応じて、「定例運営会議（管理レベル委員会）」 と「年間評価会議」の２つのタイプがある。 ① 定例運営会議 - 20 - 月１回等定期的に開催し、日々のサービスの状況報告や評価を行い、対応策の提案、 討議、選定と優先順位付け、対応結果評価等を行う。また、特別な変更等が発生した 場合には、それらがＳＬＡに及ぼす影響を分析し、必要に応じて、ＳＬＡの変更の検 討を行う。 定常運営時は、図表１−１５で示すように、サービスレベルの実績の報告を受け、 ＳＬＡと比較、評価し、今後の対応を立案、推進する。 図表１−１５ 定常運営時の検討フロー モニタリング ＳＬＡ 報告・評価 実績 対応 ・サービス実績報告 ・再発防止策提案 ・サービス実績評価 ・再発防止策検討 ・問題対応結果報告 ・計画・予防施策提案 ・問題対応結果評価 ・計画・予防施策実施検討 ・課題事項抽出 ・実施対策の報告・評価 ソフトウェアやハードウェアの変更があるような場合、サービスやサービスレベル の変更の必要を検討する。委託者と提供者の両者が変更の必要を認めた場合は、ＳＬ Ａを変更する。図表１−１６に変更対応時の検討フローを示す｡ 図表１−１６ 変更対応時の検討フロー 変更 ② 検討 ・ソフトウェア変更 ・サービス変更検討 ・ハードウェア変更 ・システム環境変更検討 ・PC追加 等 ・サービスレベル変更検討 ＳＬＡ変更 年間評価会議 年間評価会議では、図表１−１７に示すように、年間あるいは半年を通じてのサー ビスの総括的な実績評価を行うとともに、サービスの重要性の変化等を踏まえ、契約 更改に向けたＳＬＡの見直し等を実施する。 - 21 - 図表１−１７ 契約更改時の検討フロー 実績評価 ＳＬＡ 実績 ＳＬＡ評価 ＳＬＡ及びサービス 料金の見直し ・サービスレベルの妥当性 サービス評価 ＳＬＡ サービスの 重要性等 ・サービスの重要性の変化 ・事業環境の変化 等 - 22 - ４ (1) サービスレベルの具体例 サービスレベル評価項目の設定例 サービスの種類に応じたサービスレベル評価項目の設定例を図表１−１８に示す｡そ れぞれの評価項目に対して、サービス料金とのバランスを考慮しながら適切な要求水準 を設定する｡ 図表１−１８ サービス分類に応じたサービスレベル評価項目及び要求水準の設定（例） サービス分類 サービスレベル評価項目（例） サーバ可用性 アプリケーション可用性 システム運用 （データセンター） LAN／デスクトップ ヘルプデスク ネットワーク セキュリティ ※ ※ ※ 基準応答時間達成率 バッチ処理完了時間遵守率 帳票デリバリ時間遵守率 定時バックアップ率 顧客への障害通知遵守率 重大障害の件数 障害復旧時間 顧客満足度調査結果 LAN可用性 障害の件数 障害復旧時間遵守率 調達納期遵守率 ハード保守完了率 移動、変更、追加作業完了率 顧客満足度調査結果 電話放棄率（電話呼損率） 電話応答待ち時間（平均） 電話保留待ち時間（平均） 回答時間（平均） 一次回答率 問題解決率 顧客満足度調査結果 ネットワーク可用性 重大障害の件数 障害復旧時間遵守率 障害復旧時間 拡張性（拠点数拡大対応時間） ウィルス情報の把握 パターンファイルの更新 重大障害の件数 障害復旧時間 障害復旧時間遵守率 サービスレベル要求水準（例） 99.8%以上 99.8%以上 （ミッションクリティカルなアプリ） 90%以上 （ミッションクリティカルなアプリ以外） 93%以上（基準時間3秒） 95%以上 93%以上 100% 100%（障害発生後15分以内） 2回／年以内 6時間以内 5ポイント中4ポイント以上 99%以上 2回／年以内 95%以上（４時間以内） 95%以上（標準端末の場合、3日以内） 90%以上（オンサイト保守で4時間以内） 95%以上（オンサイトで1日以内） 5ポイント中4ポイント以上 3％以内 20秒以内 30秒以内 5分以内 80%以上 95%以上（１日以内） 5ポイント中4.5ポイント以上 99.9％以上 2回／年以内 95%以上（４時間以内） 6時間以内 2ヶ月以内 ベンダー検知後1時間以内 ベンダーリリースから6時間以内 0回／年 6時間以内 95%以上（４時間以内） ここで示したサービスレベル要求水準は、あくまでも参考値であり、個々の状況に応じて決定さ れるべきものである｡ 顧客満足度調査の結果に関しては、委託者と提供者の間で、顧客満足度調査がサービスの結果を 把握する上で合理的であると合意した場合に実施可能。 なお、平成１５年３月に総務省が公表した「公共ＩＴにおけるアウトソーシングに関するガイド ライン」においては、地方自治体の情報システム及びＩＴサービスにおけるアウトソーシングに 関して、サービスレベルの評価項目とその要求水準が詳細に記載されている。 - 23 - (2) サービスレベル評価項目の定義例 サービスレベル評価項目については、その定義と算出方法に関して明確化し、委託者 と提供者の間で合意しておくことが必要である｡ 以下、前頁の表で示したサービスレベル評価項目の中から、定義の例を示す。 図表１−１９ システム運用（データセンター）サービスの評価項目 （実際の稼働時間） ・ サーバ可用性 ＝ ×100 （当初予定した稼働時間）−（正当な理由のある停止時間） （基準応答時間内に応答したトランザクション数） ・ 基準応答時間達成率 ＝ ×100 （全トランザクション数） （帳票をスケジュール通りにデリバリした回数） ・ 帳票デリバリ時間遵守率 ＝ ×100 （予定帳票デリバリ回数） 図表１−２０ ＬＡＮ／デスクトップサービスの評価項目 （実際の稼働時間） ・ ＬＡＮ可用性 ＝ ×100 （当初予定した稼働時間）−（正当な理由のある停止時間） （標準納入期日までに納入した件数） ・ 調達納期遵守率 ＝ ×100 （発注件数） ※例：標準設定なら３日以内、カスタム設定なら５日以内等 （時間内にハードウェア保守を完了した件数） ・ ハードウェア保守完了率 ＝ ×100 （ハードウェア保守実施件数） ※例：オンサイトで４時間以内、修理･交換の場合は２日以内等 - 24 - 図表１−２１ ヘルプデスクサービスの評価項目 （取ることができなかった電話の本数） ・ 電話放棄率 ＝ ×100 （かかってきた電話の本数） （電話呼損率） ・ 回答時間 ＝ １回の応答にかかった時間の平均値 （１回目の電話で問題が解決できた相談の件数） ・ 一次回答率 ＝ ×100 （全相談件数） ・ 顧客満足度調査結果 ＝ 顧客満足度調査による指標化を規定する｡ ※例えば、ヘルプデスク利用者に対する電子メールによる 年１回のアンケート調査を実施する。顧客満足度に関す る調査項目に対して、ポイント換算（例：非常に良い→ ５、良い→４、普通→３、悪い→２、非常に悪い→１） し、加重平均値を求める。 ※委託者と提供者の間で、顧客満足度調査がサービスの結 果を把握する上で合理的であると合意した場合に実施 可能。 - 25 - 第２章 １ 情報システムの政府調達へＳＬＡを導入する際の考慮点 政府調達におけるＳＬＡの検討・作成・締結のタイミング 政府調達における発注方法は、以下の２通りに大別される（「参考資料１ 政府にお ける情報システム調達に係る手順」を参照のこと）。 ○ 入札による発注 ○ 随意契約による発注 これらの発注方法とＳＬＡの検討・作成・締結及びＳＬＭとの関係は図表２−１のと おりである。 図表２−１ SLA 情報システムの政府調達手続きの流れとＳＬＡの作成時期 凡例： 意見招請手続き等 SLA作成時期の 決定 ②仕様書でＳＬＡを提示しない場合 ①仕様書でＳＬＡを提示する場合 ＳＬＡの 検討・ 作成 全ての調達について実施 仕様書の作成 原則として、80万SDR超の調達額と見込 まれる調達案件 市場調査のための 資料提供招請 原則として、供給者からの資料等の提出 を求めなければ適切な仕様等を決定す ることが困難な案件（80万SDR以上の調 達額と見込まれるものに限る。） 仕様書案に対する 意見招請 入札手続 発注方法 ② 随意契約による発注 ① 入札による発注 ＳＬＡの 提示 ＳＬＡ 締結の 告知 入札公告 入札前説明会 入札締切、入札評価 落札 ＳＬＡの 締結 ＳＬＡの 締結 契約 業務の執行手続き等 業務の執行 ＳＬＡに基づく 管理 - 26 - 随意契約の事前公示 仕様書作成時にＳＬＡの内容を具体的に確定できる場合（例：運用実績がある既存シ ステム等）は、入札候補者に対して提示する仕様書にＳＬＡの内容を明記することがで きる（上図①）。しかし、技術的な問題などから仕様書作成時にＳＬＡの内容を具体的 に確定できない場合（例：新規システム開発）もあるため、その場合は、仕様書にはＳ ＬＡを別途締結する旨を明記し、ＳＬＡを契約書とは独立した文書として締結すること も可能である（上図②）。 ＳＬＡを別途締結する場合においても、入札者が適切な見積りを行えるように、仕様 書の中に、主要なサービスレベル評価項目（確定できるものについては、その水準も記 載する）とＳＬＭのための運営ルール等を記載しておく｡ ２ 発注形態に応じたＳＬＡの導入 (1) 発注形態に応じたＳＬＡの検討・作成・締結の時期 ① ＳＬＡの内容を仕様書の中で提示する場合 ＳＬＡは情報システムの保守・運用段階に適用するが、保守・運用業務の委託の方法 については、以下の３通りが考えられる。 A. 新規システムの開発及び保守・運用一括発注 B. 新規システムの開発及び保守・運用分割発注 C. 既稼働システムの保守・運用契約更改 それぞれの場合におけるＳＬＡ検討・作成・締結の時期を図表２−２に示す｡ＳＬＡの 検討・作成及び締結は、上記の発注形態のいずれにおいても、仕様書の作成から入札手 続の前段階までの間に行われる。委託契約の内容に開発と保守・運用がある場合、開発 以前にＳＬＡを締結することになる。開発の目処がたった段階で保守・運用業務を発注 する場合は、開発の調達時に、情報システムの品質・性能等の要件を定め、開発の検収 時に、情報システムの成果物について品質・性能等の要件を満足するかを検証する。そ して、保守・運用の調達時には、情報システムの品質・性能等を踏まえたＳＬＡを作成 する。 - 27 - 図表２−２ 発注形態に応じたＳＬＡの検討・作成・締結の時期 （ＳＬＡの内容を仕様書の中で提示する場合） A.新規システムの開発及び 保守・運用一括発注 SLA締結 情報システムの 品質・性能要件 C.既稼動システムの 保守・運用契約更改 仕様書作成・ 調達 SLA検討・作成 仕様書作成・ 調達 仕様書作成・ 調達 情報システムの 品質・性能要件 B.新規システムの開発及び 保守・運用分割発注 開発 SLA検討・作成 SLA締結 仕様書作成・ 調達 仕様書作成・ 調達 保守・ 運用 検収 保守・ 運用 開発 検収 SLA検討・作成 SLA締結 保守・ 運用 保守・ 運用 ② ＳＬＡの内容を仕様書の中で提示しない場合 ＳＬＡの内容を仕様書の中で提示しない場合は、仕様書に「ＳＬＡを締結する」旨と 主要なサービスレベル評価項目、ＳＬＭのための運営ルール等を記載し、落札者との協 議の上、ＳＬＡの内容を確定することも可能である。 (2) ＳＬＡ導入に適した情報システム 政府の情報システムの保守・運用の場合、データ処理量が多く、保守・運用の費用が 高い情報システムへのＳＬＡの導入が急がれる。なぜなら、データ処理量が多い情報シ ステムは利用者が多く、社会的影響が大きいと考えられ、保守・運用の費用が高い情報 システムほどＳＬＡ導入による効率化等の成果も大きいと考えられるからである。 データ処理量が少なく、保守・運用の費用が小さい情報システムについては、利用者 が国民であり社会的影響が高い場合にＳＬＡを導入することが適当である。 発注形態別では、導入のしやすさを考慮し、既稼動システムの保守・運用契約の更改 時や、新規システムの保守・運用段階の調達時に導入していくことがより容易である。 新規システムの場合は、一定期間（約 1 年）の保守・運用状況を測定、把握した後に - 28 - ＳＬＡを導入することが想定される。 以上のことを踏まえ、ＳＬＡの導入に適した情報システムと発注形態について、図表 ２−３で整理した｡ＳＬＡの導入に適しているのは、処理量と運用費用が大きい情報シス テムの新規システムの開発・運用分割発注及び既稼動システムの運用契約更改の場合で ある｡ 図表２−３ 発注形態 情報システム ＳＬＡの導入に適した情報システムと発注形態 新規システムの 新規システムの 既稼動システムの 開発・運用一括発注 開発・運用分割発注 運用契約更改 △ ◎ ◎ △ ○ ○ 処理量 大 運用費用 大 処理量 大 運用費用 小 ASP、ｺﾓﾃﾞｨﾃｨｼｽﾃﾑの 場合、導入に適する 【凡例】 ◎： ＳＬＡを導入することが急がれる情報システム ○： 必要性を考慮し、ＳＬＡを導入することが適している情報システム △： ＳＬＡの導入に準備を要する情報システム - 29 - ３ サービスレベルの位置付けに応じた政府調達プロセス上の取扱い (1) サービスレベルの位置付け 「第１章 ２ (5) 契約とＳＬＡとの関係」で述べたように、ＳＬＡに記載されるサ ービスレベルの項目には、目標保証型（取り決めたサービスレベルを保証する義務を負 う）と努力目標型（取り決めたサービスレベルが努力目標にとどまる）がある。いずれ の場合においても、提供者がサービスレベルの達成・維持に向け、改善努力を継続的に 実施する点は共通しているが、情報システムの利用者が国民であり、社会的インフラス トラクチャーになっている場合や、人命に関わる場合などは、提供者にサービスレベル の維持と改善努力をより強く要請する目標保証型とすることが適している。 (2) 仕様書へのサービスレベルの記載 政府調達において、仕様書に記載される事項は遵守されることが前提である。そのた め、サービスレベルの項目を仕様書に記載する場合は、目標保証型が望ましい。 他方、仕様書作成の段階でＳＬＡの内容を具体的に確定できない場合は、仕様書へは、 ＳＬＡを締結する旨を明記することとし、併せて主要なサービスレベル評価項目（確定 できるものについては、その水準も記載する）とＳＬＭのための運営ルール等を記載す る。具体的なサービスレベル評価項目及び要求水準は、落札者との協議等を行った上で 決定し、別途締結するＳＬＡに記載する。 (3) 入札評価におけるサービスレベルの取扱い 仕様書に記載した要求要件に基づいて、入札業者（提供者の候補）は提案書等を作成 して入札し、委託者はその内容を評価する。 入札評価の方法には、以下の２とおりがある。 ○ 最低価格落札方式 ○ 総合評価落札方式 最低価格落札方式において、仕様書に記載されたＳＬＡは必須の要件であるため、入 札業者の提案書等が要件を満足するかを評価する。一方、総合評価落札方式においては、 仕様書の技術的要件に示されるものには、以下の２種類がある。 ○ 必須の要求要件：必要最低限の要件 ○ 必須以外の要求要件：必須要件ではないが、業務上の必要性、重要性に照らし合 わせて設定した要件 必須の要件として仕様書に記載項目については、入札業者の提案内容が要求を満足し ていることを確認する。必須以外の要件として記載した場合は、定義されたサービスレ ベルの妥当性と種類や数、サービスレベルの高さなどについて加点評価する。 - 30 - 第３章 情報システムの政府調達へのＳＬＡ導入ステップ １ ＳＬＡ導入のステップ ＳＬＡを導入するためのステップを図表３−１に示す｡ 図表３−１ ＳＬＡの検討・作成のステップ ＳＬＡの検討・作成 前提条件の整理 ITサービスの品質に著しく影響を及ぼす利用者 側条件（業務要件等）の確認 委託業務の範囲の定義 対象となる業務の構造分析に基づく提供サービ スの設定 役割と責任の分担の定義 ITサービスの業務における委託者と提供者との 責任分担 提供者の免責範囲の明確化 サービスレベルの未達成を提供者に帰責しない 範囲の設定 サービスレベルの定義 具体的なレベル設定、ならびに測定方法（計算 式、数値収集方法等）の検討 結果対応の定義 サービスレベル未達成時の対応手順およびフォ ロー方法の検討 運営ルールの設定 年度／月次の報告ルール、ＳＬＡを適切に維持 するための会議体運営ルールの設定 ＳＬＡの提示・締結 仕様書含等への必要事項の記載 ＳＬＡに基づく管理 委託者・提供者等をメンバーとした会議体の設 置、定期的な報告に基づく運用 前提条件の整理では、ＩＴサービスの品質に著しい影響を及ぼすと想定される委託者 側の前提条件、例えば、業務量や利用者数などを明確化する。委託業務の範囲の定義で は、調達の対象となる情報システム関係業務の範囲を特定する。続けて、委託者と提供 者との責任分担を明確化する。この時、ＯＳやパッケージのバグ等提供者が責任を負え ない部分がある場合、免責範囲を設定する。提供者が責任を持つべき業務を定めた後に、 委託者として要求するサービスレベルを定める。次にサービスレベルが未達成の場合に、 連絡、報告、対応などの方法を定める。この時、サービスレベルが著しく低下した場合、 あるいは低い水準が続いた場合のペナルティを、必要に応じて設定する。最後に、保守・ 運用段階で実施するＳＬＭに関する運営ルールを業務の必要性に応じて定める。 - 31 - ＳＬＡを検討・作成した後、仕様書の中で入札候補者に対してＳＬＡを提示、あるい は、落札後、落札者に対してＳＬＡを提示し、双方の間でＳＬＡを締結する。保守・運 用段階においては、ＩＴサービスが提供される期間にわたり、ＳＬＭを実施する。 ２ ＳＬＡの検討・作成 (1) ① 前提条件の整理 解説 調達の対象である情報システムの保守・運用業務の前提となる諸条件を整理する（図 表３−２）。整理すべき条件には、各々業務上の前提条件、システム上の前提条件があ る。特に、保守・運用業務の品質に著しく影響を及ぼす条件について整理する｡ 業務上の前提条件には、業務量や利用者数、オフィスの拠点数などがある。業務量に ついては、通常時と繁忙時、利用者数や拠点数については、契約期間中の増加、減少な どできるだけ詳細に確認する。システム上の前提条件には、ハードウェア構成や性能、 ソフトウェア構成や品質、ネットワーク回線のスピードなどがある。 - 32 - 図表３−２ ＳＬＡ適用にあたっての前提条件の整理票 ＳＬＡ適用にあたっての前提条件の整理票 システム上の前提条件 ・情報システムの概要 ・システムの構成 −ハードウェア構成 −ソフトウェア構成 −ネットワーク構成 ・委託する情報システムの性能 −オンライン処理性能 −バッチ処理性能 ・委託する情報システムの品質 −ソフト／ハードトラブルの状況 −その他のトラブルの状況 ・システムに求められるセキュリティや安全対策 業務上の前提条件 ・業務の概要 ・業務に係る主要な帳票の量（通常時／繁忙期） ・拠点数および利用者数 等 ・保守・運用にあたって遵守すべき関係法令、コンプライアンス ・保守・運用にあたって遵守すべきセキュリティポリシーや安全対策 その他の前提条件 ・ソフトウェアおよびハードウェア資産の所有 ・ネットワークサービスの提供者 ・コンピューターセンターの指定 ・データの帰属と保全義務（データがソフトウェアと分割できない場合）など - 33 - ② 記載例 Ａ∼Ｄからなる省内にて利用されている情報システムの保守・運用を委託する場合の ＳＬＡ作成上の前提条件を整理した記載例を図表３−３に示す。システム上の前提条件 や業務上の前提条件は、情報システムの調達時の仕様書に記載される内容に等しい。 図表３−３ ＳＬＡ適用にあたっての前提条件の整理票（例） ＳＬＡ適用にあたっての前提条件の整理票 システム上の前提条件（運用を委託する情報システムの概要） 1.情報システムの概要 運用を委託するシステム範囲は、○○○システムである。 ○○○システムは、下記サブシステムにより構成される。 ・Ａシステム ・Ｂシステム ・Ｃシステム ・Ｄシステム 【システム概要図】 2.システムの構成 ・サーバ：本省内約100台、各地方局等各10数台、計約200台 ・クライアントPC：約5,000台 【別紙 【別紙 【別紙 ハードウェア構成図】 ソフトウェア構成図】 ネットワーク構成図】 業務上の前提条件 （運用を委託する情報システムが担う業務の概要） ・業務の概要 ・業務に係る主要な帳票の量 -通常期： -繁忙期： ・拠点数：本省1、地方局10 ・利用者：本省及び各地方局等における職員約5,000名 その他の前提条件 ・ハードウェア／ソフトウェアは○○省の資産である。 ・ネットワーク回線は○○省が用意する。 ・ハードウェアは、△△社へ別途保守委託する。 ・アプリケーションソフトウェアは、□□社へ別途保守委託する。 ・コンピュータセンターは○○省のセンターを利用する。 - 34 - (2) ① 委託業務の範囲の定義 解説 委託者から提供者へ外部委託する業務の範囲を定義する（図表３−４）。 まず、情報システムに係る業務の一覧を作成する。次にその業務を細かい業務へ分解 する。このためには、現行の情報システムや類似した情報システムにおける業務の一覧、 業務フロー等を参考にすることが有効である。 図表３−４ 委託業務範囲の定義表 大分類 小分類 （注） 電子政府構築のために策定している「業務・システム最適化計画」においては、 府省の業務を分類した業務・システム体系が整備されている。この体系にもとづ く一覧を参照することにより、各府省における現行の情報システムや類似した情 報システムの状況を調べることができる。また、情報システムだけではなく業務 まで含んだ外部委託を検討するときにも参考にすることができる。 - 35 - ② 記載例 ある省内の情報システムの保守・運用とそれに伴う利用者支援機能を委託する場合に、 その委託業務の範囲を定義した記載例を図表３−５に示す。 図表３−５ 委託業務範囲の定義表（例） 大分類 システム運用管理 小分類 システムの運用状況の管理 システムの障害状況の管理 システム資源の管理状況の管理 データ入力 スケジュールの作成・入力作業 データ出力 スケジュールの作成・帳票配布 データ管理 機密保護対策 データ資源の管理 システム運用 運用スケジュールの作成 オペレーション 障害対応 状態監視 システム資源管理 ハードウェア資源の管理 ソフトウェア資源の管理 ネットワーク資源の管理 利用者支援 (3) ① ヘルプデスク 役割と責任の分担の定義 解説 各業務に対する役割と責任の分担を明確にする（図表３−６）。 まず、情報システムの保守・運用に関与する組織（企業）をリストにまとめる。 一企業に対し業務を委託する場合は、委託者と提供者の２つの組織が関与することに なるが、提供者以外にハードウェアの保守や、ソフトウェアの保守などを実施する企業 が存在する場合は、それらの業務を行うことになる企業をリストアップする必要がある。 ただし、提供者の指示のもとでその業務を行うようにする場合は、その旨を明記する必 要がある。 次に、業務を分担する組織を特定する。この時、最も細分化された業務が２つ以上の 組織で分担されるような場合は、改めて業務を細分化し、役割分担即ち責任分担が明確 になるようにする必要がある。 業務が細分化され、役割分担が委託者側と提供者側に細かく分かれている場合は、責 - 36 - 任範囲の特定が複雑になり、サービスレベルの取り決めが複雑になるため、極力、委託 範囲を大括りにすることが望ましい。 図表３−６ 大分類 小分類 責任分担表 ○○省 提供者 (他組織) (他組織) 各々の組織の役割は、記号（○：担当、△：支援、−：担当外）により示す、ある いは役割を具体的に記述するなど、適切な表現により記載する。 ② 記載例 ある省内の情報システムの保守・運用とそれに伴う利用者支援機能を委託する場合に、 その委託業務に関係する組織の役割と責任の分担をリストにまとめた例を図表３−７に 示す。 この例では、システムの保守・運用計画と機密保護対策規定は○○省が立案・策定し、 それらを受けたシステムの保守・運用業務の全般を提供者が実施する。また、ハードウ ェア保守は△△社へ、ソフトウェア保守は□□社へ別途委託する。 - 37 - 図表３−７ 大分類 システム運用管理 責任分担表（例） 小分類 システム運用計画 ○○省 提供者 △△社 □□社 立案・決定 ─ ─ ─ 実施 詳細な管理を ─ ─ システムの運用状況の管理 実施・報告 システムの障害状況の管理 システム資源の管理状況の管理 データ入力 スケジュールの作成・入力作業 評価・承認 実施 ─ ─ データ出力 スケジュールの作成・帳票配布 評価・承認 実施 ─ ─ データ管理 機密保護対策 規程策定／ 取扱い手順等 ─ ─ 実施状況の 作成 評価・承認 ／対策の実施 データ資源の管理 評価・承認 実施 ─ ─ 運用スケジュールの作成 評価・決定 立案 ─ ─ オペレーション 評価・承認 実施 ─ ─ 評価・承認 実施 ─ ─ システム運用 障害対応 状態監視 システム資源管理 ハードウェア資源の管理 ソフトウェア資源の管理 ネットワーク資源の管理 安全対策 安全対策の検討／見直し・改善計画 評価・決定 立案・実施 ─ ─ 保守 ハードウェア保守 評価・承認 ─ 立案・実施 ─ ソフトウェア保守 評価・承認 ─ ─ 立案・実施 教育・訓練 評価・承認 ─ ─ 立案・実施 ヘルプデスク 評価・承認 実施 ─ ─ 利用者支援 (4) ① 提供者の免責範囲の明確化 解説 提供者が責任を負う各業務において、提供者がコントロールできない部分での障害に 関する責任を除外するために、提供者の免責範囲を明確化する｡ 情報システムの保守・運用段階における免責については、以下のように考える。まず、 保守・運用段階で提供されるサービスのレベルに影響を及ぼす要素は、図表３−８に示 すように、企画段階に起因するもの、設計・開発段階に起因するものなどがあり得る。 企画、設計・開発、保守・運用の各業務の役割分担により、責任の分担も変わる。 - 38 - 図表３−８ サービスレベルへ影響を及ぼす要因 企画段階 設計・開発段階 保守・運用段階 ・業務要件 ・情報ｼｽﾃﾑ品質 ・ｻｰﾋﾞｽ品質 ・情報ｼｽﾃﾑ仕様 ・情報ｼｽﾃﾑ性能 受託する業務の範囲により、提供者の負う責任範囲が異なる。設計・開発、保守・運 用業務を一括して受託した業者は、その間の業務に起因する不具合による責任を免れな い。保守・運用業務の範囲のみを受託した業者は、上流工程である企画、設計・開発に 起因する不具合からは免責される。 図表３−９のように各々の役割と責任の分担を明確化し、それを踏まえて免責範囲を 設定することが重要である。 図表３−９ • • 情報システム関係業務に関する役割と責任の明確化（例） 担当 委託者 企画段階 ● 業者A 担当 委託者 企画段階 ● 設計・開発段階 ● 設計・開発段階 保守・運用段階 ● 保守・運用段階 業者Aは、企画に起因する不具合からは免責 業者Aは、設計・開発段階、運用段階の不具合に 対し、委託者への責任を負う • • 業者B 業者C ● ● 業者Bは、企画に起因する不具合からは免責 業者Cは、企画、設計・開発に起因する不具合か らは免責 なお、記載のための様式は特に設けない。 ② 記載例 以下は、「(3) 役割と責任の分担の定義 ② 記載例」に示した役割・責任分担表を 踏まえ、提供者の免責事項を記述した例である。 免責事項 システム運用に関し、下記に起因する障害については、免責とする。 ・インフラ災害、電源供給や通信障害 ・ハードウェアに起因する障害 ・ソフトウェアに起因する障害 ・委託者の過失及び故意による障害 - 39 - (5) ① サービスレベルの定義 解説 各サービスに関して、サービスに対する要求水準とサービスレベルの評価項目を設定 する(図表３−１０)。その際、前提条件を記述し、前提条件を満たす場合にのみ、サー ビスレベルが保証されることを明確化する。 サービスレベルの設定では、先ず、利用者にとって分かりやすいサービスを定義する。 システムを利用する様々な場面の中で、一般に分かりやすいものは、オンラインサービ スの時間やそのレスポンスタイム、帳票の配送時間、障害の発生頻度と復旧時間などが 想定される。これらは、すべて利用者が定常的に業務を行っている中で把握することが できる。 次に、その中からさらに、利用者にとって重要なサービスを特定する。重要なサービ スを特定するためには、そのサービスが受けられない場合に、影響を被る組織や人数、 影響の大きさ（被害金額、遅延時間、残業時間など）を考慮する必要がある。 利用者にとって分かりやすく重要なサービスを特定した上で、サービスレベルの要求 水準を設定する。設定にあたっては、実際の利用者の要求を明確化するとともに、実際 の業務への影響を考慮して決定する。必要以上に高いサービスレベルを要求せず、また、 重要度の高いサービスに低いサービスレベルを設定しないように留意して、バランスを 考慮した上でサービスレベルを定義する。 サービスレベル評価項目については、その定義と算出方法を明確化することが重要で ある。「第１章 ４ (2) サービスレベル評価項目の定義例ＳＬＡの項目例」等を参考に して設定する。 それぞれのサービスレベル評価項目について、具体的な測定手段、タイミング、測定 間隔を規定する。 図表３−１０ サービスレベル定義表 サービス サービスレベル 評価項目 要求水準 サービス条件 - 40 - 測定方法 ② 記載例 「(2) 委託業務の範囲の定義 ② 記載例」に示した情報システム保守・運用業務に より、提供されるサービスを定義し、サービスレベルを設定した例を図表３−１１に示 す。なお、サービスレベルは、提供者が責任を負う各業務の範囲の中で設定される。ま た、それを踏まえて免責範囲についても設定することが重要である。 図表３−１１ サービスレベル定義表（例） サービスレベル 評価項目 要求水準 オンライン運用 計画された稼働時間に渡りシ 稼動率 99.8％ ステムが稼動すること レスポンスタイムが基準時間 基準応答時間達成率 93％ 内であること 決められた時間内に障害が復 障害復旧時間 1 時間以内 旧すること バッチ運用 計画された完了時刻までに処 完了時間遵守率 95％ 理が完了すること 決められた時間内に障害が復 障害復旧時間 3 時間以内 旧すること 帳票デリバリ 計画された時刻までに帳票が デリバリ時間遵守率 95％ 到着すること ヘルプデスク オペレータへ電話が繋がるこ 電話放棄率 3％ と （電話呼損率） 当日内に問合せ内容が解決す 問題解決率 95％ ること サービス サービス条件 測定方法 （注） 既稼動システムの保守・運用契約更改等の場合、既稼動システムの提供者や第三者 を交えて、次年度の契約におけるサービスレベルの検討を行うことが可能である。 その場合、先ず委託者は、提供者に対してサービスレベルを取り決めたい旨を明ら かにするとともに、サービスに求める要件を明確化する。次に、委託者と既稼動シス テムの提供者もしくは第三者は、共同で前提条件や委託範囲、役割と責任分担を定め る。これらに基づいて既稼動システムの提供者もしくは第三者は、サービス、サービ ス条件、サービスレベル、測定方法、結果、報告などの運営ルールを策定し、最後に、 委託者がこれらの採否を確定することができる。 このような準備を行うことで、より妥当なサービスレベルの設定が可能となる。 - 41 - (6) ① 結果対応の定義 解説 サービスレベルが所定の水準と異なった場合の対応方法を、運用上の対応、財務上の 対応、契約上の対応の面から、あらかじめ決定する｡サービスレベルの目的は、一定水準 のサービスをサービス提供者が継続することにあるため、運用上の対応が最低限必要と なる。 ＜運用上の対応＞ 合意文書上に、「サービスレベルの未達成の場合は、委託者と提供者が協議の上、改 善を実施する」旨を記載する。 ＜財務上の結果対応＞ 提供者が実際に提供したサービスレベルの結果を、料金に反映させる計算方法を記載 する。年度末に、年度における最終的な金額を算出し、支払い金額の調整を行う｡ ＜契約上の対応＞ サービスレベルの未達成が頻繁に繰り返される場合や、サービスレベルが極めて低水 準となる場合に備えて、合意文書上に、契約解除条件等を設定する。 ② 記載例 結果対応は必ずしも財務上の対応を優先させるというものではないが、財務上の対応 を行うための記載例を図表３−１２に示す。 図表３−１２ 調整金額計算書（○○年○月）(例) サービス オンライン運用 バッチ運用 帳票デリバリ ヘルプデスク 業務への影響度当月合計 調整金額の上限 当月調整金額率 当月サービス料金請求額 調整金額 業務への影響度（％） 50 30 20 − （X） （A） （Y=A×X） （B） （C=B×Y/100） 結果 ○ ■ ○ − -30% 20% -6% 10,000千円 -600千円 ※）サービスレベルが所定の水準であった場合 ：○ サービスレベルが所定の水準と異なった場合：■ 結果対応の運用対象外 ：− - 42 - (7) 運営ルールの設定 ① 解説 ＳＬＡを実効性あるものとするためには、サービス提供後のＳＬＭのための運営ルー ルを設ける必要がある。そのためには、ＳＬＭ委員会を設置し、契約期間中の状況変化 に合わせて対応していることが重要である。 運営ルールとして、以下のものを設定する。 ・ ＳＬＭ委員会の設置 ・ ＳＬＭ委員会の運営方法 ・ ＳＬＭ委員会における検討テーマ - 43 - ② 記載例 ＳＬＭ委員会の運営ルールの例を図表３−１３に示す｡ 図表３−１３ 運営ルール(例) 1.ＳＬＭ委員会 1-1.定例運営会議 ・ 目的 ＳＬＡによって取り決められたサービスレベルの維持管理を行うことを目 的とする。 ・ 開催時期 毎月第２週の月曜日に開催する。当日が休日の場合は、翌営業日とする。 ・ 出席者 ○○省：情報システム企画室 ○○○、○○○ ○○部○○課 ○○○、○○○ ○○社：システム部 部長、運用担当 ・ 主要議題 − サービスレベル達成状況報告 − 課題の共有 − 改善策、対応方針の検討 1-2. 年間評価会議 ・ 目的 当該年度のサービスの実績や結果対応の状況などを踏まえて、現在のＳＬ Ａの妥当性を評価し、次年度のＳＬＡに反映させることを目的とする。 ・ 開催時期 毎年度９月、３月の第３週の月曜日に開催する。当日が休日の場合は、翌 営業日とする。 ・ 出席者 ○○省：情報システム企画室 ○○○、○○○ ○○部○○課 ○○○、○○○ ○○社：システム担当役員 システム部 部長、運用担当 ・ 主要議題 − 過年度実績報告 − 過年度実績評価 − サービスレベル設定の妥当性確認 − 契約更改（期間、費用） 2.ＳＬＭの運営方法 【「第３章 ４ (2) ＳＬＭ委員会の運営方法」を参照のこと】 3.ＳＬＭ委員会における検討テーマ 【「第３章 ４ (3) ＳＬＭ委員会における検討テーマ」を参照のこと】 - 44 - ３ ＳＬＡの提示・締結 仕様書の提示と同じタイミングでＳＬＡを提示する。ＳＬＡの提示にあたり、これま で検討した事項を文書化する。 ＳＬＡは、委託者がＳＬＡの内容を仕様書で提示した場合は契約書の附属文書の一部 として契約時に締結されるが、仕様書の中ではＳＬＡを締結する旨のみを示した場合は、 落札者との協議やシステム運用状況の分析等を通じて、ＳＬＡの内容を確定し締結する。 その際の点検ポイントは図表３−１４の通りである。 図表３−１４ ＳＬＡ文書化に際しての点検ポイント ①外部委託の前提条件 ・サービスレベルに影響を及ぼす条件が定められている。 ・業務委託の範囲が定められている。 ・役割と責任の分担が定められている。 ②サービスレベル ・サービスの範囲・内容が明確になっている。 ・委託者、提供者の責任範囲が明確になっている。 ・サービスレベルがサービスの利用者から見て分かりやすい。 ・サービスレベルがサービスの利用者にとって有効な指標値が用いられている。 ・サービスレベルの測定方法や測定範囲が明示されている。 ・サービスレベルが現実的なレベルである。 ・サービスレベルが過去の実績もしくはサービスの利用者の期待に基づいている。 ・ペナルティ、インセンティブを実施する場合、その説明、および受取方法が 明示されている。 ③ＳＬＭ ・継続的な管理ができるようなサービスレベルが設定されている。 ・契約期間内にサービスレベルの変更ができるようになっている。 - 45 - ４ ＳＬＭの運営 ＳＬＭは、ＳＬＡの遵守状況を確認し、サービスレベルの維持・向上を図ることを主 な目的とする。同時に、円滑なサービス実施を実現するための委託者と提供者間の良好 な関係を築くことも目的とする。 この目的を実現するために、委託者、提供者（情報システム部門及びサービス受益部 門）の責任者、担当者から構成される会議体ＳＬＭ委員会を設置し、定期的に会合を持 つことが必要となる。 (1) ＳＬＭ委員会の設置 ＳＬＭ委員会には、目的によって２つの種類があり、委託者、提供者はそれぞれ適切 なメンバーを選定する。委託者側のメンバーの選定は仕様書作成時に行い、メンバーと して参加してもらう役職や担当を決定しておくことが望ましい。２種類の会議体のメン バーは、原則同一とするが、年間評価会議には上席の意思決定者を加えるなど、必要に 応じてメンバーを加える場合もある。委託者側のメンバーとしては、サービス全体に対 して意思決定を行うことができる統括責任者と各サービスの担当責任者の参加が必要で ある。また、必要に応じて、利用部門の職員の参加も望まれる｡ ① 定例運営会議 ＳＬＡによって取り決められたサービスレベルの維持管理を行うことを目的とする。 通常、月に１回などの定例会議とするが、必要に応じて適宜開催する。 ② 年間評価会議 年間を通じたサービスの実績や結果対応の状況などを確認するとともに、現在のＳＬ Ａの妥当性を評価することを目的とする。会議は、半年に１回など、ある程度間隔を空 けて開催する。 ＳＬＭ委員会の開催時期の例を図表３−１５に示す｡ 図表３−１５ ＳＬＭ委員会の開催時期（例） ① 定例運営会議 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ② 年間評価会議 ※ (2) ○ ○ ○の月に開催 ＳＬＭ委員会の運営方法 ＳＬＭ委員会の設立時に、定例運営会議と年間評価会議ともに、基本的な議事内容及 び開催スケジュールを決定する。また、連絡、資料作成、議事進行、議事録作成等、会 - 46 - 議運営に必要な役割については、担当者を定めておく。 定例運営会議の運営の流れを次の図表３−１６に示す。年間評価会議の運営も、議事 の内容を除いて同様である。 図表３−１６ 定例運営会議の運営の流れ ① 開催通知の送付 開催日時、場所、議事内容を、メンバー全員に送付する。 ② 資料準備依頼 議事に必要な資料の準備をメンバーに依頼する。 「サービス実績報告」と「問題対応結果報告」等、毎回必要と なる資料については、仕様書に明記しておくことが望ましい。 毎回報告する項目以外の資料については、趣旨や必要な内容に ついて詳しく説明する。 ③ 定例運営会議（議事） 提供者からサービスの実績や問題対応結果報告を受け、それに 関する質疑応答及び今後の対応に関して検討する。検討を要す る議題があれば、適宜取り上げる。 ・ 前回の議事内容の確認（議事録を準備） ・ 今回の議事内容の説明 ・ 提供者からのサービス実績報告 ・ 提供者からの問題対応結果報告 ・ 計画・予防に関する検討 ・ その他対応が必要な項目の検討 ④ 議事録の作成、確認 会議で検討された内容、決定した事項を議事録として文書化す るように提供者に依頼する。提供者が作成した議事録の内容を 委託者の側で確認し、委託者と提供者の間で誤解が生じないよ うにする。 - 47 - (3) ＳＬＭ委員会における検討テーマ 定例運営会議では、サービスの実績報告、問題対応に関する提供者側の報告と委託者 側の評価が行われ、計画・予防に関する検討が実施される。また、特別に検討しなけれ ばならないテーマが発生した場合は、適宜取り上げて検討を行う。 年間評価会議では、半年や年間を通じたサービス実績に関する総括的な評価を行い、 次年度に向けたサービスレベルの妥当性に関して検討を行う。 ＳＬＭ委員会における検討テーマ例を図表３−１７に示す｡ 図表３−１７ ＳＬＭ委員会における検討テーマ例 テーマ分類 定例運営会議 実績報告 問題対応 計画・予防 概要 サービス実績報告 サービス実績評価 サービスレベル達成状況の報告、サービスレ ベル未達成時の原因分析、対応策提示 サービス実績に対する評価 問題対応結果報告 障害発生等、問題発生時の対応結果報告 問題対応結果評価 対応結果に対する評価 再発防止策提案 再発防止策検討 提供者による施策提案（施策内容、見積、ス ケジュール等） 提案内容の妥当性検討、施策の実施判断 課題事項抽出 実務者による課題事項の棚卸検討 計画･予防施策提案 提供者によるキャパシティ増強、セキュリティ 強化等（特に緊急対応が必要な）施策の提案 （施策内容、見積、スケジュール等） 提案内容の妥当性検討、施策の実施判断 施策実施検討 その他 サービスの前提条件の確認 サービスレベル変更依頼 サービスレベル変更検討 サービス変更依頼 サービス変更検討 システム環境変更検討 年間評価会議 総括的サービス実績報告 総括的サービス実績評価 サービスレベル妥当性検討 ※ 前提条件の変更予定の確認、変更内容とそ の影響の確認 サービスレベルの切り上げ、切り下げ（廃止） 等の検討依頼 サービスレベルの切り上げ、切り下げ（廃止） 等の検討 サービス内容の追加、変更、廃止の実施検討 依頼 サービス内容の追加、変更、廃止の実施検討 インフラ増強等システム環境変更に向けた計 画策定、実施検討 サービスレベル達成状況等の総括的サービス 報告 サービス実績に対する評価 サービス実績及びサービスの重要性の変化、 事業環境の変化等を踏まえた、次年度におけ るサービスレベルの妥当性の検討 委 託 者 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○印は、それぞれの項目を実施（依頼、検討、資料作成、評価等）する側を示す。 - 48 - 提 供 者 (4) ＳＬＭ委員会における資料イメージ ここでは、ＳＬＭ委員会の運営に必要な以下の資料の例を示す。 ① ① 議事次第 ② 議事録 ③ 実績報告書 ④ 問題対応結果報告書 議事次第 次回の会議の日時、場所、議事内容を記し、事前にメンバーに送付する（図表３−１ ８）。 図表３−１８ 議事次第（例） 第2回 ○○システムの定例運営会議 議事次第 平成16年6月6日 ○○課第１会議室 10:00∼12：00 １． 開会 ２． 議事 １）前回の議事録の確認 （担当：○○課○○） ２）先月の実績報告 （担当：○○社○○） ・ サービス実績報告 ・ 問題対応結果報告 ３）課題事項の抽出 （担当：○○課○○） ・ 利用部門での課題 ４）その他 ３． 閉会 配布資料 資料１ 第１回○○システムの定例運営会議議事録 資料2 サービス実績報告書 資料3 問題対応結果報告書 資料4 ○○システムに関する利用部門から見た課題について - 49 - ② 議事録 毎回の会議における検討内容及び決定事項等を記述した議事録の作成を、提供者に依 頼する。提供者が作成した議事録を委託者が確認することによって、両者の間の誤解を 防ぐ（図表３−１９）。 図表３−１９ 議事録（例） 第2回 ○○システムの定例運営会議 議事録 日時： 場所： 平成16年6月6日 10:00∼12：00 第１会議室 出席者： ○○課 ○○○○ ○○○○ ○○課 ○○○○ ○○○○ ○○社○○課 ○○○○ ○○○○ 議事内容： １）前回の議事録の確認 （担当：○○課○○） ２）先月の実績報告 （担当：○○社○○） ・ サービス実績報告 ・ 問題対応結果報告 ３）課題事項の抽出 （担当：○○課○○） ・ 利用部門での課題 議事概要： １）実績報告 ・ ○○社による４月の実績報告が行われた。 ・ 5月の実績報告に基づき、全てのサービスレベルはＳＬＡに規定さ れた水準を上回ったことが確認された。 ・ 5月28日の５分間のシステム停止に関しては、６月６日時点では原 因は不明であるが、次回の会議までに、○○社が原因を分析し、 対応方法を提示することとなった。 ・ ・ - 50 - ③ サービス実績報告書 委託者は、提供者に対して、サービスの実績を示した報告書を、毎回提出するように 依頼する（図表３−２０）。 図表３−２０ サービス実績報告書（例） ○○システムのサービス実績報告 （平成16年５月1日∼平成16年5月30日） １．サービスレベル達成度 ・ 各サービスレベル項目についての「達成」／「未達成」の確認（一覧表） ２．サービスレベル未達成報告 ①事象 ・ サービスレベル項目概要 ・ サービスレベル未達成状況下でのサービス運用状況 ・ ②原因分析 ・ 原因箇所の切り分け、特定 ・ ③影響度分析 ・ 業務への影響（リスク） ・ システムへの影響（リスク） ・ ④対策（提案） ・ 対策実施方法（業務プロセス改善 or システム改善） ・ スケジュール ３．附属資料 １）各サービスレベルの測定データ ・ 測定データの一覧表 ・ ・ ・ - 51 - ④ 問題対応結果報告書 委託者は、提供者に対して、障害発生等問題発生時の提供者による対応結果を示した 報告書を、毎回提出するように依頼する(図表３−２１)。 図表３−２１ 問題対応結果報告（例） ○○システムの問題対応結果報告 （平成16年５月1日∼平成16年5月30日） １．問題対応概要 ・ 発生した問題の一覧 ・ 対応履歴一覧 ・ 対応結果評価（一覧表） ２．個別問題に関する対応内容 １）問題「○○」 ①事象 ・障害内容 ・障害による損害等影響の測定 等 ②障害復旧経過 ・復旧（暫定対応）方法 ・復旧時間 ・復旧時のサービス運用状況 等 ③対応結果評価 ④再発防止策（提案） ・対策実施方法 ・スケジュール ・コスト 等 ２）問題「○○」 ・ ・ ・ - 52 - おわりに 今後、世界最高水準の電子政府を実現するべく、「e-Japan戦略」、「e-Japan戦略Ⅱ」 が打ち出され、中央政府及び地方自治体において電子政府関連の調達が増加していくこと が予想される。情報システムに係る政府調達制度の見直しが早急に必要となっている所以 である。 政府調達制度の見直しの観点として、調達に伴う手続きの合理化、透明性の向上、調達 費用の低減、ベンチャー企業からの調達の一層の促進があげられている。また、政府行政 各部門は、住民や企業に対するサービスを低下することなくIT導入を推進し、業務効率化 と住民や企業に対するサービス改善を両立しなければならない。そのための施策の一つと して、本「情報システムに係る政府調達へのＳＬＡ導入ガイドライン」を策定した。本ガ イドラインは、まさに政府関係組織が、必要なサービスを適正な価格で調達するために、 考え方や手順を整理したものである。 情報システムに係る政府調達を実施する場合、情報システムの利用者である住民や企業 または政府行政各部門が必要とするサービスとそのレベルを予め定めて、適正な価格で調 達を実現できる基礎となるように、ガイドラインを定めた。言うまでもなく、ガイドライ ンはその策定をもって完結するものではない。ガイドラインは活用されてはじめて効果を 発揮するものである。 本ガイドラインが政府調達において、参照、活用されることによって、サービス内容、 サービスレベルが取り決められ、適正な価格での調達が実現されることが期待される。ま た、情報システムの運用過程で、サービスレベルが政府とベンダーの間で、継続的にモニ タリングされ、改善されるＳＬＭの実施を通して、サービスを低下することなく、住民や 企業に対するサービスを提供することも期待できる。 「情報システムに係る政府調達制度の見直し」では、ライフサイクルコストを基準にし た価格評価や、総合評価落札方式における除算方式の見直しを実施するとともに、ジョイ ント・ベンチャー（ＪＶ）等の企業共同体への競争入札資格の付与や中小企業者からの調 達を促進する等の施策が示されてきた。また、引き続き検討が必要な事項の一つとして、 契約書の見直しがあげられている。 本ガイドラインは、サービスの内容、サービスレベルを予め取り決め、入札の段階で示 すようにガイドしている。すなわち、落札条件の中の一部である価格に関連するサービス レベルに係る要求がより詳細に提示され、情報システムの政府調達プロセスの透明性が高 まることで、ジョイント・ベンチャー等の企業共同体や中小企業者の参入機会が増大する - 53 - ことにつながることが期待される。 より高度な電子政府システムの実現を目指し、ＩＴアソシエイト協議会は、組織全体の 業務とシステム双方を設計・管理する手法であるEnterprise Architecture（EA）策定の方 法論を取り纏め「業務・システム最適化計画について（Ver.1.1）Enterprise Architectur e策定ガイドライン」を公表している。 本ガイドラインは、情報システムの外部委託におけるサービス品質の水準に焦点をあて、 適正なサービスを適正なコストで調達できるようにすることができるようにしたものであ る。しかし、情報システム検討の最上流過程であるＥＡを確立した上で、その調達におい て本ガイドラインが活用されることで、より適正な調達となることが期待される。また、 本ガイドラインでは、保守・運用業務にＳＬＡの適用範囲を絞って記述したが、設計・開 発の段階においても、同様の視点でサービス品質を改善していくことは重要である。 本ガイドラインは、「e-Japan戦略」のもと、中央政府及び地方自治体において電子政府 関連の調達が増加していくことが予想されるなか、早急な対応が必要と考え、取り纏めた ものであり、国際的な動き、国内での活用の進展を見て、修正されることが必要となるこ とも想定される。その動きの一つは、Performance Based Contract（PBC パフォーマンス・ ベース契約 パフォーマンス・ベース・サービス調達 PBSA とも言う）である。ＳＬＡ では、サービスの内容やレベルを明確化しそれらを維持・向上することに焦点を当ててい るが、ＰＢＣでは、成果そのものに着目し、成果そのものと価格の関連付けを明確化する ものである。米国連邦政府調達は、コスト削減ならびにコスト効率化を狙いとして、ＰＢ Ｃによる調達に大きく比重を傾けており、これらの動向を把握し、有効性を評価し、本ガ イドラインの見直しに役立てることが想定される。 国内では「公共調達と競争政策に関する研究報告書について（平成15年11月18日 公正 取引委員会）」において、事業者（ガイドライン中ではサービスの提供者）の発意による 技術提案の活用が適当な案件等については、複数の事業者に提案を行わせ、個別の交渉を 通じて契約者を選定する方法である競争的交渉方式が提案されている。契約者の選定段階 で各事業者から提案を受け交渉できるようになることによって、ＳＬＡに関しても各事業 者から独自の提案がなされることが期待できる｡競争的交渉方式により情報システムの調 達において本ガイドラインが活用されることで、より適正な調達となることが期待される。 本ガイドラインは情報システムの政府調達をスコープとして策定されている。しかし、 政府調達で活用が推進され、定着することを通じ、民間調達にて利用が促進されることも 期待したい。さらに、情報システムのほかサービス一般の政府調達、民間調達において、 サービスの内容とレベル、価格の関係が透明化され、適正な取引が実現するために利用さ - 54 - れるように発展していくことに期待したい。 - 55 - 情報システムの政府調達に係るSLA導入研究会委員名簿（五十音順） ［委 員］ 赤坂 幸彦 池野 泰博 座 長 岡積 小林 小林 櫻井 繁野 瀬尾 永倉 正夫 正一 款 通晴 高仁 隆一 正洋 西野 野中 原田 平本 本廣 弘 雅行 朝夫 健二 隆之 山田 澤明 山田 靖二 山野井 聡 横尾 良明 渡辺 尚生 ［オブザーバー］ 竹之内 修 田中 義之 水上 雅弘 中村 修 瓜生 和久 金子 洋悦 狩野 英司 河野 太志 山田 和伸 株式会社NTTデータ 品質保証部品質保証担当部長 日本アイ・ビー・エム株式会社 サービス事業 テクニカルソリ ューションセンター担当 株式会社流通戦略総合研究所 代表取締役 アウトソーシング協議会 副会長 株式会社エヌ・ティ・ティエムイー 法人営業本部副本部長 専修大学教授、経営学研究科 科長 KDDI株式会社 執行役員、情報システム本部長 富士通株式会社 マーケティング本部企画統括部担当課長 株式会社日立製作所 情報・通信グループアウトソーシング事業 部情報ユーティリティ推進センター長 ITサービスマネジメントフォーラムジャパン 副理事長 株式会社シーエーシー NSM事業本部BPO事業部長 株式会社アルゴ21 執行役員、PMOセンター長 株式会社フューリッジ・コンサルティング 代表取締役 日本電気株式会社 第一ソリューション営業事業本部第一官庁 ソリューション事業部事業推進マネージャー 株式会社野村総合研究所 執行役員コンサルティング部門コン サルティング第三事業本部長 特定非営利活動法人ASPインダストリ・コンソーシアム・ジャパ ン 常務理事 ガートナージャパン株式会社 マネージング・バイス・プレジデ ント 首都圏コンピュータ技術者協同組合 理事長 東京ガス株式会社 情報通信部長 総務省 行政管理局 行政情報システム企画課 専門官 経済産業省 大臣官房 情報システム厚生課 室長 経済産業省 大臣官房 情報システム厚生課 課長補佐 経済産業省 大臣官房 情報システム厚生課 課長補佐 経済産業省 商務情報政策局 情報政策課 課長補佐 経済産業省 商務情報政策局 情報政策課 係長 経済産業省 商務情報政策局 情報政策課 係長 経済産業省 商務情報政策局 情報処理振興課 課長補佐 経済産業省 商務情報政策局 情報処理振興課 係長 ［事務局］ 山地 柳沢 平澤 内田 譲原 和田 杉田 克郎 茂樹 高美 礼 雅一 充弘 道彦 財団法人 財団法人 財団法人 財団法人 株式会社 株式会社 株式会社 ソフトウェア情報センター 専務理事 ソフトウェア情報センター 調査研究部長 ソフトウェア情報センター 調査研究部課長 ソフトウェア情報センター 調査研究部 野村総合研究所 ｼｽﾃﾑｺﾝｻﾙﾃｨﾝﾌﾞ事業本部 野村総合研究所 ｼｽﾃﾑｺﾝｻﾙﾃｨﾝﾌﾞ事業本部 野村総合研究所 ｼｽﾃﾑｺﾝｻﾙﾃｨﾝﾌﾞ事業本部 - 56 - 参考資料 - 57 - 参考資料１ 政府における情報システム調達に係る手順 情報システムに係る政府調達の手続は、基本的には、「物品に係る政府調達手続につい て（運用指針）」（平成６年３月28日）に則って実施される。 また、情報システム調達に固有の事項については、「日本の公共部門のコンピューター 製品及びサービスの調達に関する措置」（平成４年１月20日）に記載がある。 「物品に係る政府調達手続について（運用指針）」を基とし、「日本の公共部門のコン ピューター製品及びサービスの調達に関する措置」に示された情報システムに固有の事項 を反映した、情報システムに係る政府調達の手続の手順を、次頁の図表に示す。 - 58 - 図表１ 情報システムに係る政府調達の調達手続フロー・チャート 凡例： 全ての調達について実施 原則として、80万SDR超の調達額と見込まれる調達案件 原則として、供給者からの資料等の提出を求めなければ適切な仕様等を決定するこ とが困難な案件（80万SDR以上の調達額と見込まれるものに限る。） 上記以外のもの 将来の調達計画等 年度当初の官報公示 調達情報提供（基準額以上） 所定の窓口 意見招請手続等 仕様書の作成 会合の開催 技術委員会、設問グループ、研究会その他同様の会合 市場調査のための資料提供招請 年度開始前／年度開始に資料 提供招請につき官報公示 少なくとも30日 資料提供期限 仕様書案作成完了の旨の官報公示 少なくとも20日 仕様書案に対する意見等の提供期限 少なくとも30日 一般競争契約の実施の徹底 随意契約の場合 入札手続 入札公告 入札前説明会 入札締切 原則として50日 （50日が不可能 な場合であって も最低40日） 随意契約の事前公示 少なくとも20日 最低価格方式に よる評価 総合評価方式に よる評価 落札 落札の官報公示 契約 苦情処理手続等 苦情処理手続 不公正な入札の防止 - 59 - 参考資料２ 政府における情報システム関係業務の分類 図表２ 一括外注の形態 テスト／導入 運用準備 安全対策 メンテナンス 利用者支援 外注管理等 システム資源管理 運用関係業務の一括実施 システム運用 外注管理等 運用段階 データ管理 情報システム関係業務の データ出力 一切を役務サービスとして提供 データ入力 外注管理等 マニュアル作成 外注化可能業務 外注管理等 詳細設計／開発 職員の重点的実施業務 業務の一括実施 設計・ 開発段階 基本設計 情報システム関係業務の一切を役務サービスとして提供 システム分析 企画及び設計・ 開発関係 企画段階 コンピュータ・システムの 調達・整備 一括役務調達型 A 運用役務調達型 B 各種業務一括実施委託型 C 出所：国の行政機関における情報システム関係業務の外注実施ガイドライン （平成12年3月31日 行政情報システム各省庁連絡会議幹事会了承） - 60 - 図表３ 外注の活用が可能な業務と外注を活用した場合における行政機関の職員の実施業務 企画・ 調整段階 1.企画業務 情報システム関係業務 1.情報システム化の中・長期計画策定 2.情報システム化案件の調査・分析 3.最新技術動向の調査・分析 4.安全対策基準の策定 5.予算・機構定員要求 2.外注管理 3.関係部局との連絡・調整 1.プロジェクト管理 2.システム分析 3.基本設計 設計・ 開発段階 4.詳細設計 1.全体計画 2.スケジュール管理 3.品質管理 4.課題管理 1.現状の調査・分析 2.システム要求要件・条件の明確化 3.システムの基本機能、処理概要の明確化 4.ハードウェア・ソフトウェア構成の明確化 1.入出力設計 2.データベース設計 3.ハードウェア構成設計 4.ソフトウェア構成設計 5.システムインターフェース設計 6.システム処理設計 7.システム運用手順設計 8.ネットワーク設計 9.安全対策の設計 1.入出力設計 2.プログラム設計 3.プログラミング 5.プロトタイプ手法による開発 6.総合テスト 1.テストの企画・実施 7.マニュアル作成 1.運用・利用マニュアルの作成 8.運用準備 1.導入・移行 9.外注管理 10.関係部局との連絡・調整 1.システム運用管理 1.システム運用計画 2.システムの運用状況の管理 3.システムの障害状況の管理 4.システム資源の管理状況の管理 2.データ入力 1.スケジュールの作成・入力作業 3.データ出力 1.スケジュールの作成・帳票配布 4.データ管理 1.機密保護対策 運用段階 5.システム運用 6.システム資源管理 7.安全対策 8.メンテナンス 9.利用者支援 監査段階 10.外注管理 11.関係部局との連絡・調整 1.システム監査計画 2.システム監査の実施 3.監査計画の評価 4.改善計画 5.外注計画 2.データ資源の管理 1.運用スケジュールの作成 2.オペレーション 3.障害対応 4.状態監視 1.ハードウェア資源の管理 2.ソフトウェア資源の管理 3.ネットワーク資源の管理 1.安全対策の検討／見直し・改善計画 1.ハードウェア・メンテナンス 2.アプリケーション・メンテナンス 1.教育・訓練 2.ヘルプデスク 情報システム担当職員 立案・承認 評価・承認 外注先業者 ─ 実施 評価・決定 実施 立案 ─ 立案・決定 実施 ─ 詳細な管理を 実施・報告 評価・承認 実施 評価・承認 実施 実施 ─ 立案・決定 実施 ─ 詳細な管理を 実施・報告 評価・承認 実施 規程策定／実施状況 の評価・承認 評価・承認 評価・決定 評価・承認 取扱い手順等作成／ 対策の実施 実施 立案 実施 評価・決定 評価・承認 立案・実施 立案・実施 評価・承認 実施 実施 ─ 立案・決定 評価・決定 実施 評価・承認 実施 ─ 実施 ─ 立案・実施 ─ 出所：国の行政機関における情報システム関係業務の外注実施ガイドライン （平成12年3月31日 行政情報システム各省庁連絡会議幹事会了承） - 61 - 参考資料３ 発注形態に応じた責任分担の考え方 情報システム関係業務の１つの工程につき１社、異なる業者に委託した場合、前工程を 担当した業者は、瑕疵担保責任の考え方に基づいて、発注者に対し、後工程における品質 等について一定の責任を負うと考えることができる。 一定の責任とは、問い合わせへの対応や瑕疵の修正であり、後工程を担当する業者の結 果責任を除く。 図表４ 単純な発注形態でのサービスレベルの責任分担例 設計段階 開発段階 委託者 委託者 契約、 管理 運用段階 委託者 契約、 管理 契約、 管理 業者Ｃ 業者Ｂ 業者Ａ 一定の責任（瑕疵担保） 他方、設計・開発段階を情報システムのインテグレーションを１社に任せ、システムイ ンテグレータが複数の業者へ開発業務を発注するような場合、そのシステムインテグレー タが品質等について包括的な責任を負う。 同様に、保守・運用段階でもインテグレーターが、保守・運用全体のサービスレベルに ついて包括的な責任を負う。（業者ＡおよびＢ、Ｃ、Ｄとの間の責任分担は、業者Ａとの 間の調整事項となる） 図表５ 複雑な発注形態でのサービスレベルの責任分担例 設計段階 委託者 保守・運用段階 開発段階 委託者 一括契約、 管理 委託者 一括契約 一括契約、ＳＬＡ 業者Ａ 業者Ａ（ｼｽﾃﾑ・ｲﾝﾃｸﾞﾚｰﾀ） 業者Ｄ 業者Ｃ 業者Ｂ - 62 - 契約、 管理 業者Ｃ 業者Ｂ 業者Ａ 契約、 管理 参考資料４ 海外における取り組み事例 日本よりアウトソーシングの活用が普及している諸外国においては、ＳＬＡの導入につ いても日本より先行している。そこでは、政府機関がアウトソーシングのフレームワーク を整備し、普及のための活動を行い、また、政府のＩＴ調達におけるＳＬＡのガイドライ ンを作成するといった、日本への大きな示唆に富んだ取り組みが行われている。以下、こ れらの事例を紹介する。 (1) ＩＴＩＬ（英国） ＩＴＩＬ（IT Infrastructure Library）は、英国のＯＧＣ（政府調達庁、旧ＣＣＴＡ） が作成した一連の書籍であり、ＩＴサービスマネジメントのベストプラクティスについ て記述したものである。ＩＴＩＬの目的は、予算上の制約、技術不足、システムの複雑 さ、急激な変化、現在と将来のユーザ要求、日増しに高まるユーザからの期待などに直 面している組織が、品質の高いＩＴサービス提供を支援することである（ｉｔＳＭＦ Ｊ ＡＰＡＮ「ＩＴサービスマネジメント用語集」より）。 ＩＴＩＬには、ＩＴ運用におけるサービスサポートとサービスデリバリーのベストプ ラクティスが記述されている。 図表６ ＩＴＩＬの内容 分類 手法 内容 サービス サービスデスク ユーザコミュニケーションの窓口 サポート インシデント管理 サービスを速やかに回復させる 問題管理 問題の根本原因を突き止める 構成管理 ＩＴ環境の構成要素を把握する 変更管理 ＩＴ環境に対する変更をハンドリングする リリース管理 ＩＴサービスをスムースに実装する サービス サービスレベル管理 ＩＴサービスの品質を定量的に規定する デリバリ ＩＴサービス財務管理 ＩＴとビジネスの財務的なバランスを図る キャパシティ管理 環境の変動をとらえてリソースの最適化を図る ＩＴサービス継続性管理 障害時におけるビジネスの中断を最小限にする 可用性管理 サービス停止を最小限に押さえる ｉｔＳＭＦ（Information Technology Service Management Forum）は、1991 年に英 国で設立され、ＩＴＩＬを用いてＩＴサービスマネジメントのベストプラクティスの普 及を推進する国際的な組織である。イギリス、ドイツ、カナダ、米国、オーストラリア、 南アフリカなど合計 14 カ国に現地法人が設立されている。日本においても、ｉｔＳＭＦ の日本法人であるｉｔＳＭＦ ＪＡＰＡＮが平成 15 年 9 月にＮＰＯ法人として認可され、 各種活動を実施している。 - 63 - ｉｔＳＭＦのビジョンとミッションを以下に示す。 図表７ ｉｔＳＭＦの活動概要 ビジョン ミッション 手段 (2) ＩＴサービスマネジメントの象徴としてＩＴ業界で認知される ・ ＩＴ分野におけるベストプラクティスの推進 ・ ＩＴサービスマネジメントに携わる人々のプロ意識向上 ・ ＩＴサービスマネジメント関連知識の共有の場を提供 ・ 他組織との連携を通じたＩＴサービスマネジメント知識の共有 ・ ＩＴサービスマネジメント関連サービスの向上のための媒体 ・ ＩＴサービス・マネジメント ・ ＩＴインフラストラクチャー・ライブラリ ニューサウスウェールズ州（オーストラリア） オーストラリアのニューサウスウェールズ州政府は、個々のＩＴ調達において、調達 担当者がＳＬＡを締結する際のガイドラインを作成している。このガイドラインは、複 数の部局においてＳＬＡを締結するための実用的なアドバイスを求める声が高まったた め、1999 年に、現場の調達担当者が利用できる共通のガイドラインとして作成された。 ニューサウスウェールズ州政府は、ガイドラインを作成することによって、サービス プロバイダーによるサービスのパフォーマンスの向上と同時に、サービスのユーザであ る各部門の職員の知識と能力の向上を図った。 ガイドラインでは、ＳＬＡの作成に関して、以下の 10 のステップに分けて説明してい る。 図表８ ＳＬＡを作成するための10のステップ ステップ 立ち上げ 重要な関係者の参加 ニーズと期待の特定 サービスレベルの設定 内容 1. ＳＬＡの目的、ＳＬＡ作成のプロセス、期間の決定 2. 重要な関係者の特定、協力体制の構築 3. 各関係者のニーズ特定、問題と目的の明確な定義 4. プロバイダの能力の検討、サービスレベルとその基準の 定義、最も重要なサービス領域の合意 5. 評価指標の決定 サービス・パフォーマンスを測定する指標決定 6. 双方に関わる問題特定 双方の義務の明文化、問題の早期発見のための指標決 定、問題解決プロセスの構築、契約停止の条件 7. 料金と支払条件の決定 料金算出方法の同意、費用付替方法の決定 8. 文書の構成、内容、形式に 文書への双方のパートナーシップの反映、環境変化に対 関する合意 応するための項目記述 9. 評価プロセスの決定 パフォーマンスの評価者の決定、評価委員会の開催頻度 決定、サービス向上のための手法決定 10. ＳＬＡの文書化と締結 最終文書の関係者への確認、適格者による署名 - 64 - ＳＬＡガイドラインは、以下に示すように４章構成になっており、最初にＳＬＡを締 結する目的を説明した後、ＳＬＡ作成のためのステップ、項目の決定と書類の作成方法、 そして、ＳＬＡが満たされたか評価する方法について説明している。 図表９ ＳＬＡガイドライン目次 第１章 同州の公的機関においてＳＬＡを締結する目的の説明 第２章 ＳＬＡを作成するにあたって必要なステップの説明 第３章 ＳＬＡにはどのような項目が含まれるのか、どのような形式の書類 を作成すればいいのかに関する詳細説明 第４章 ＳＬＡが満たされているかどうかを計測する方法と、サービスレベ ルを向上させるための方法に関する説明 付属資料Ａ 広い範囲にわたるＳＬＡに適用できるブランク・フォーマット 付属資料Ｂ ガイドラインの中で使用されている一般的な用語と概念を具体的 な例の中で説明するためのＳＬＡのサンプル 付属資料Ｃ ＳＬＡ作成に役に立つ参考文献及び情報源 付属資料Ｄ ガイドラインの中で使用されている主要な用語の明確な定義 - 65 - 参考資料５ サービス料金と課金 サービス料金の決定方法には、INPUTベース、OUTPUTベース、OUTCOMEベースの３種類が ある。 図表１０ サービス料金の決定方法 料金の 概要 決定方法 メリット 委託者にとって検証がしやすい デメリット INPUT サービスの実現のために提供者 適正量のインプットであり過剰な ベース の投入した人員、物量から料金 投入がなされていないか、委託 を算定し、決定する方法 者に検証の負荷がかかる OUTPUT 提供者の提供するサービスの内 委託者にとって分り易い 委託者にとってサービス料金の ベース 容、品質等 委託者にとって検証負荷がかか 妥当性を説明することが困難で らない ある OUTCOME 提供者の提供するサービスによ 委託者にとって分り易い 成果には当該システム以外の要 ベース り委託者の得た便益から料金を 委託者にとって検証負荷がかか 素の影響があり、委託者にとっ 決定する方法 らない て成果とサービスの関係を説明 することが困難である 上記のようにOUTCOMEベースで取り決めるバリューベースト・プロポジション等があるが、 政府での適用に先んじて、採用の妥当性、現実性を検討する必要がある。 (1) バリューベースト・プロポジションとは バリューベースト・プロポジション（Value Based Proposition ; 価値にもとづく価 格提案）とは、利用者側が実際に納入されたシステムを使用して、そのシステムが目的 としていた価値、利益を生み出している場合に、その価値（利益）に見合った対価を提 供者側が報酬または報酬の一部として受け取る契約形態である。 提供者の提供するサービスの内容について、利用者側に価値や利益が見出されない場 合には、報酬額の減少という形でペナルティが課せられる。 (2) バリューベースト・プロポジションの背景 バリューベースト・プロポジションが生まれた背景には、近年、グローバルな競争環 境におかれた企業や、財政危機により歳出削減が必要な行政部門において、情報システ ムの開発に必要な資金の手当が困難になったことが挙げられる。 このような組織体のために、情報システムのプロジェクトを請け負った提供者側で、 必要な資金手当も準備するという、バリューベースト・プロポジションの仕組みが考案 された。この仕組みでは、利用 0 者側で資金手当をする必要がなくなる。一方、提供者 側で必要資金の手当をする必要が生じるが、システム開発で一定以上の経済的効果が得 られれば、その果実の中から提供者側に利益が返上される。 資料：櫻井通晴「ソフトウェア管理会計」（白桃書房，2001 年，214-216 頁）より作成 - 66 - (3) 情報化コストの課金 ＳＬＭに業務部門が積極的に参加するような仕組みをつくることが重要である。 業務部門のサービスレベルと料金に対する意識を向上するために課金を行うことは望 ましい。ただし、その導入には、的確な原価の把握、合理的な配賦ドライバーの設定、 負荷のかからない実現方法等を検討する必要がある。 図表１１ 情報化コストの課金 企業（委託者） 経営 ・情報化コスト管理 ・料金（課金） 業務部門 ・料金 提供者 システム部門 （受託者） ・サービス ・ＳＬＡ ・サービス ・ＳＬＡ - 67 -