情報システムが稼動してから,多様な理由により利用できない状況になったり,改訂が必要になったりします。そのときのサービスレベルを維持したり,さらに向上するためのマネジメントをITサービスマネジメントといいます。
本章では,ITサービスマネジメントの標準であるITILについて,その概要を理解します。
2020年現在、ITILの最新版はV4です(参照:ITIL(V4))が、ITサービスマネジメントとの関係、ITサービスの内容などは、本ページのほうがわかりやすいので、このままにしておきます。
ITサービスマネジメント(ITSM),ITIL,5つの分野.サポートデスク
ITサービスは、従来は運用管理、保守管理といわれていました。
情報システムは利用している間に,利用者からの改善要望,環境変化に伴う情報システムの改訂,アクセス増大へのハードウェア対策,セキュリティ強化,予期しない事故など多様な問題が発生します。これらへの対応が不適切だと,対応に時間や労力がかかる,改訂により新しいエラーが発生するなどの問題が生じます。
IT活用が高度化・広範囲化してきたため、情報システムのトラブルは、企業活動だけでなく、社会的にも大きな影響を及ぼすようになりました。しかも、情報システムの開発者、運用者、利用者の関係が複雑になってきました。
このような状況の変化により、運用・保守の重要性が認識されるとともに、ITの利用環境の整備,情報システムの有効性の確保など,従来の保守・運用の概念を広げることが必要になり、「ITサービス」というようになりました。そして、ITサービスを経営や業務の観点からとらえて、総合的に継続的な改善活動としてマネジメントすることをITサービスマネジメントといいます。
なお、ITサービスの提供者と利用者の間で、サービスレベルに関して合意をすることをSLA(Service Level Agreement)といいますが、SLAはITサービスマネジメントの一部分であり、それを詳細にしたものだといえます。
ITIL(IT Infrastructure Library)とは、ITサービスマネジメントを企画し運営するためのベストプラクティス(グッドプラクティス)集です。英国基準になり、現在は ISO/IEC 20000(JIS Q 20000)になりました (詳細説明)。
OGC(Office of Government Commerce:英国商務省)は,1989年に,政府官公庁の情報化推進のためにITサービスマネジメントのベストプラクティスを収集する計画をたてました。それに応えて,1991年にitSMF(ITサービスマネジメントフォーラム)というNPO組織が設立され,そこがまとめた書籍(ドキュメント)集がITILです。2000年にITILv2にバージョンアップされ、2007年にITILv3になりました。ITILの著作権はOGCにあり、その普及をitSMFが行っています。
ITILの普及の一環として、「ITILファンデーション」と「ITILマネージャ」の資格認定試験があります。
この間に、ITILは英国規格BS 15000になり、さらに ISO/IEC 20000(JIS Q 20000)になりました。
ISO/IEC 20000-1 第1部:要求事項
ISO/IEC 20000-2 第2部:実践規範
ISO/IEC 20000-2は、実際にITサービスマネジメントを実践するときに参考にすべきベストプラクティスです。それで、ISO/IEC 20000-2とITILは、似たような内容になっています。
企業(主にベンダ)がISO/IEC 20000に準拠しているかを第三者が認定するITSMS適合性評価制度(ITSMS:IT Security Management System)があります。
ITサービスを提供する企業にとって、顧客の要求事項を満たすために、適切に運営管理されたサービスを効果的に提供することが必要ですが、ITILはそのためのチェックリストとして適切ですし、ITSMS適合性評価制度の認定を受けることは信用の向上に役立ちます。
ここでは、ITILv3(2007年)をベースにして、その概要を説明します。ITILとはどのようなものかの説明を目的としているので、厳密な用語の定義には従っていません。
ITILは、次の5つの書籍(ステージ)からなっています。
・サービス戦略
・サービス設計
・サービス移行
・サービス運用
・継続的なサービス改善
そして、それぞれの関係は、サービス戦略をベースに、サービス設計→サービス移行→サービス運用のステージを、継続的サービス改善によりPDCAサイクルとしてマネジメントするようになっています。これをITILライフサイクルといいます。
ステージの関係は、次のようになります。すべてのステージでの情報がデータベースに保管され、SKMS(Service Knowledge Management System:サービス・ナレッジ管理システム)として、統合的に管理されます。
ベンダ(ITサービスのプロバイダ)の経営戦略に関する分野を扱っています。どのような顧客(ユーザ企業)に対して、どのような価値のあるITサービスを、どのように提供するかについて、基本的な方針を策定します。
顧客に対して、有用性のあるITサービス(機能、操作性、品質など)を保証するために、サービス資産(要員、資金、インフラ、アプリケーションなどのリソース(経営資源)と、それを活用するマネジメント能力など)を確保して、適切なサービスを提供できる体制が求められます。
サービス設計とは、ITサービスに関するビジネスからの要件を満足させるために、どのような設計、開発をすればよいかの方法を検討する分野です。一般的に、中長期にITサービスに関する計画と改善についてまとめたものになります。
ベンダが顧客にITサービスを提供するとき、あるいは、現行のITサービスを変更するときに、提供できるITサービスの詳細を示した一覧リストのことをサービス・カタログといい、それを作成するプロセスをサービス・カタログ管理といいます。
カタログに関しては、あまりITに詳しくない利用者にもサービス内容が理解できるようにすることが必要です。
サービス・カタログの項目を取捨選択し、ITサービスのレベルに関して、ベンダと顧客の間で合意をすることをSLA(Service Level Agreement)といいます。SLAを適切に管理するのがサービスレベル管理です。
SLAの内容は多様です。例えば、対象業務の開発者がベンダである場合、その情報システムの保守は自社で行えるでしょうが、ネットワークの故障などは専門のベンダに依頼することになりましょう。ハードウェアやソフトウェアのベンダ、アウトソーシングやSaaSのプロバイダなど、ITサービスのプロバイダとは異なる企業をサプライヤといいます。ITサービスを行うには、サプライヤが提供するサービスや製品に関する情報、サプライヤとの契約などを管理することが必要になります。それをサプライヤ管理といいます。
ITサービスで重要になる項目には、次のようなものがあります。
ITサービスをビジネス環境で運用するのにあたり、長期的な視点で変更管理の役割や変更実行をするとき、リスクや利点、提供の仕組みやサービス運用の容易化に関する分野を取り扱います。
日常的なITサービスの運用に関する分野を対象に、発生から解決までのプロセスと、それために必要となる機能について解説しています。
プロセスとは、目標を達成するための一連の活動のことです(ここでは、それを「○○管理」と表現しています)。
サービス運用でのインシデント発生から解決までのプロセスとその流れの概念図を掲げます(この図は旧版ITILv2に掲載されていたもので、「サービス移行」の一部も含まれていますが、本質的にはITILv3でも同じです)。
サービス運用の基本は、システムの異常により業務が中断する期間を短縮することにあります。そのためには、異常による影響度の大小による適切な対応、解決までの時間短縮のための過去の類似ケース記録の有効活用がポイントになります。以下のプロセスは、それを体系的に示したものです(なお、「アクセス管理」などセキュリティ対策分野の管理は、この体系から独立させています)。
上記のプロセスを円滑に行うために必要な組織や能力を機能といいます。
ジョブスケジュールやデータのバックアップ/リストアなど、日常的な情報処理の運用を行う組織をIT運用管理といいます。システムに異常が発生せず、利用者からの要求もなければ、IT運用管理だけでよいのですが、実際には、これらが発生するので、その対処のための組織が必要になります。
ITサービスで重要な組織がサービスデスクです。すべてのプロセスに関する利用者への総合窓口になります(後述)。
専門的知識・能力を必要とする事項を支援するためのサポートグループに、ITのインフラに関する技術管理、と実務に適用されているアプリケーションに関するアプリケーション管理があります。
インシデント管理を例にして、その開始から終結までの作業手順(ライフサイクル)を示します。他のプロセスでもほぼ同様です。
インシデントが発生したとき、その対処を容易にするためには、過去の同様な事象に対して行った情報を適切に活用することが重要です。それには、各作業において、その情報をデータベースに記録する必要があります。
問題管理を例にすれば、インシデントを引き起こす未知の原因を「問題」といい、解決した問題を「既知のエラー」といいます。問題管理とは、問題を既知のエラーにするプロセスだといえます。問題が発生したとき、その対策のことを「回避策」といい、回避策を講じた結果、適切な解決ができた対策方法を「問題モデル」といいます。これらの情報をデータベースにしたものを、KEDB(Known Error Database:既知のエラーのデータベース)といいます。KEDBに適切な情報が入力されており有効に活用できれば、インシデント管理も容易にできます。問題管理とは、KEDBの構築、維持、活用の方法だともいえます。
このようなデータベースは、構成管理でのCMDBのように、いくつかのデータベースがあります。それらが統一した観点から設計され、相互に連携できるようにすることが重要です。
サービスデスクとは、利用者からの問い合わせ、障害報告、改善提案、クレームなどITサービスに関する総合窓口です。
イベント管理やインシデント管理を担当して、早急に利用者が業務を継続するように支援するのが主任務ですが、問題管理やリリース管理の状況やその結果を利用者に伝えるのも任務です。
サービスデスクで解決できない場合は、問題管理や技術管理など専門的な知識をもつグループに連絡して解決を依頼しますが、あくまでも利用者との窓口はサービスデスクに集中して一元化する(タライ回しをしない)ことが必要です。
サービスデスクは利用者との唯一の接点ですから、その応対如何がITサービス全体への評価に直結します。サービスデスクのサービスレベルを向上させることが必要です。利用者満足を得るためには、利用者の立場にたって業務をすることが求められます。また、限られた人数で対処するために、
・サービスデスクの可用性:業務時間の検討、電話待ち時間の短縮など
・問題解決までの時間:たらいまわしをせず初回コールでの解決、電話時間の短縮など
がサービスレベルの尺度になります。
消費者対象での受注や問合せに応じる電話窓口をコールセンターといいます。コールセンターでは、これらの尺度の改善のために多様な工夫をしています。
サービスデスクの設置場所や組織構造は多様です。大きく次のように区分されますが、その中間的なものや組み合わせたものがあります。
ITサービス全般について、効率性・有効性、および費用対策を向上するために、ITサービス提供者のパフォーマンスを継続的に測定し、報告し、改善を加えるプロセスです。
ITサービスを、PDCAサイクルにより、継続的に改善する方法を、7つの改善ステップとして示しています。