TOP
＞
プロジェクト管理
＞ サービスのメニュー化
SLAによるITマネジメントのあり方
第２回：SLAの策定プロセス
著者：
アイ・ティ・アール 金谷 敏尊
2007/3/23
前のページ
1
2
3
次のページ
サービスのメニュー化
それでは、まずサービスのメニュー化について見てみよう。
情報システム子会社は通常、契約書のリファレンスや運用手順書に基づいて業務を遂行している。そこに記載されてるサービスメニューが十分に整備されたものであれば、それをそのままSLAに流用できる。
だが、実際には運用委託業務の内訳が適切にアップデートされていなかったり、実態と違っていたりするケースは少なくない。例えば、営業時間外にも関わらずサポートを提供したり、直接かかってきた電話にSEが対応したりしていないだろうか。
サービスメニューは、サービスレベルを確保するための工数に影響するため、あらかじめ定義して置く必要がある。またサービスメニューには、サービスデスク、メインフレーム運用、サーバ運用、Webサイトやメール管理、PCサポート、ネットワーク管理などに大別し、必要に応じて詳細に定義するとよいだろう。
なお、プロジェクトや開発業務などの非定常業務についてサービスレベルを設定するのはあまり一般的でない。これらはプロジェクト評価や品質管理の標準規格（ISO 9001、PMBOKなど）の適用を通じて品質確保を目指すこととなろう。
補足であるが、開発業務のSLAを策定する場合は、スケジュール遵守率、レビュー実施率などを評価項目とすることができる。しかし、成果物の品質は要件定義や仕様が確定するタイミングに加えて、難易度や技術レベルに依存するため、事前に設定するのは難しい。
評価項目の設定
SLMでは一定の基準にそってサービスレベルを評価・改善することが求められる。それには、設定されたサービスレベルを「測定できること」が条件となる。
やむをえず定性的に「障害発生時には迅速に復旧対応し、再発防止に努める」などと記述することもあるが、そのような場合には「重大障害の復旧時間は2時間以内とし、70%の達成率を目標とする」などと定量的に示した方が評価・改善につなげやすい。
また、評価項目はユーザの期待を反映してサービスの水準を的確にあらわしているものであれば、項目数は少なくてよい。世に出回っているSLAのガイドラインには、大量のサンプル項目を羅列しているものが目立つが、それらはあくまでも目安であってすべてを検討する必要はない。
大量の項目は、SLMの負荷を高めて提供者側の自由度を損ねるばかりか、ユーザから見ても理解に苦しむものになる。また少数の評価項目とは、ユーザが本当に知りたい情報を提供する評価項目ともいえる。例えば、食事をする人は料理そのものを評価するのであり、材料の仕入先や料理人の手際の良し悪しまでは見ることは少ないのと同様である。
情報システム子会社の場合であれば、バックアップ頻度や定期保守の実施率などはベンダーからの報告は受けても、必ずしも親会社に報告する必要はないだろう。
表2にSLAにおいて、よく使用される評価項目の例を示す。
サービス
デスク
一次解決率
全コール数の内、初回コールで解決したものの割合
解決時間
コールの受付から対応完了までの時間
依頼処理時間
依頼に基づく処理（データ抽出など）の対応に要する時間
障害通知時間
センター内で障害を検知後、ユーザに通報するまでの時間
システム
運用
可用性
稼働予定時間に対する実稼働時間の割合
障害復旧時間
障害発生を検知してから復旧するまでの時間
障害発生件数
一定期間内に発生した障害の数
レスポンスタイム
リクエスト後、画面や処理結果が表示されるまでの時間
表2：SLAの評価項目（例）
出典：ITR
前のページ
1
2
3
次のページ
著者プロフィール
株式会社アイ・ティ・アール
金谷 敏尊
シニア・アナリスト
青山学院大学を卒業後、マーケティング会社の統括マネージャとして調査プロジェクトを多数企画・運営。同時にオペレーションセンターの顧客管理システム、CTIなどの設計・開発・運用に従事する。1999年にアイ・ティ・アールに入社、アナリストとしてシステム・マネジメント、データセンター、アウトソーシング、セキュリティ分野の分析を担当する。著書「IT内部統制実践構築法」ソフトリサーチセンター刊。
INDEX
第2回：SLAの策定プロセス
SLAをどのように策定していくのか
サービスのメニュー化
サービスレベルの設定
