ＩＴＩＬ

ＩＴＩＬの概要

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

ＩＴサービスは、従来は運用管理、保守管理といわれていました。
　情報システムは利用している間に，利用者からの改善要望,環境変化に伴う情報システムの改訂，アクセス増大へのハードウェア対策，セキュリティ強化，予期しない事故など多様な問題が発生します。これらへの対応が不適切だと，対応に時間や労力がかかる，改訂により新しいエラーが発生するなどの問題が生じます。
　ＩＴ活用が高度化・広範囲化してきたため、情報システムのトラブルは、企業活動だけでなく、社会的にも大きな影響を及ぼすようになりました。しかも、情報システムの開発者、運用者、利用者の関係が複雑になっていました。
　このような状況の変化により、運用・保守の重要性が認識されるとともに、ＩＴの利用環境の整備，情報システムの有効性の確保など，従来の保守・運用の概念を広げることが必要になり、「ＩＴサービス」というようになりました。そして、ＩＴサービスを経営や業務の観点からとらえて、総合的に継続的な改善活動としてマネジメントすることをＩＴサービスマネジメントといいます。

ＩＴＩＬ

ＩＴＩＬ（IT Infrastructure Library）とは、ＩＴサービスマネジメントを企画し運営するためのベストプラクティス（グッドプラクティス）集です。英国基準になり、現在は ISO/IEC 20000（JIS Q 20000）になりました （詳細説明）。

ここでは、ＩＴＩＬｖ３（２００７年）をベースにして、その概要を説明します。ＩＴＩＬとはどのようなものかの説明を目的としているので、厳密な用語の定義には従っていません。

ＩＴＩＬは、次の５つの書籍（ステージ）からなっています。
　・サービス戦略
　・サービス設計
　・サービス移行
　・サービス運用
　・継続的なサービス改善
　そして、それぞれの関係は、サービス戦略をベースに、サービス設計→サービス移行→サービス運用のステージを、継続的サービス改善によりＰＤＣＡサイクルとしてマネジメントするようになっています。これをＩＴＩＬライフサイクルといいます （図示）。

ＩＴＩＬｖ２では、ＩＴサービスの日常管理の分野をサービスサポート、長期的対策の分野をサービスデリバリとしていました（図示）。
　なお、ＩＴサービスの提供者と利用者の間で、サービスレベルに関して合意をすることをＳＬＡ（Service Level Agreement）といいますが、ＳＬＡはＩＴサービスマネジメントの一部分であり、それを詳細にしたものだといえます。

ステージの関係は、次のようになります。すべてのステージでの情報がデータベースに保管され、ＳＫＭＳ（Service Knowledge Management System：サービス・ナレッジ管理システム）として、統合的に管理されます。

（拡大図）

このうち、日常的なＩＴサービスに関する部分（サービス移行とサービス運営の一部分）は、ＩＴＩＬｖ２ではサービスサポートと呼ばれていました。インシデント発生から解決までの流れは、このほうがわかりやいので、その概念図を掲げます。

（拡大図）

サービス戦略（Service Strategy）

ベンダ（ＩＴサービスのプロバイダ）の経営戦略に関する分野を扱っています。どのような顧客（ユーザ企業）に対して、どのような価値のあるＩＴサービスを、どのように提供するかについて、基本的な方針を策定します。
　顧客に対して、有用性のあるＩＴサービス（機能、操作性、品質など）を保証するために、サービス資産（要員、資金、インフラ、アプリケーションなどのリソース（経営資源）と、それを活用するマネジメント能力など）を確保して適切に運用することが重要です。

サービス・ポートフォリオ管理

計画中（サービス・パイプライン）、稼働中（サービス・カタログ）、完了済（廃止したサービス）のＩＴサービスのすべてについて、それぞれのライフサイクル（要件分析、対応経過、運用、廃止などの流れ）における情報を、データベースに格納して管理する必要があります。

需要管理

ＩＴサービスに必要な要員やコンピュータなどのキャパシティを確保したり調整したりすることです。これには、顧客の需要動向の予測やＩＴサービスの活動パターンの理解が必要になります。

財務管理

安定したＩＴサービスを行うためには、健全な財務状態にしておくことが必要です。それには、予算管理（原価把握など）や会計管理（予実管理、資金管理など）が必要ですが、特にＩＴサービスでは、課金が重要になります。課金対象となるサービス項目の設定、ＳＬＡでのインセンティブやペナルティの設定、保守作業での契約内容などが対象になります。

サービス設計（Service Design）

サービス設計とは、ＩＴサービスに関するビジネスからの要件を満足させるために、どのような設計、開発をすればよいかの方法を検討する分野です。一般的に、中長期にＩＴサービスに関する計画と改善についてまとめたものになります。

ベンダが顧客にＩＴサービスを提供するとき、あるいは、現行のＩＴサービスを変更するときに、提供できるＩＴサービスの詳細を示した一覧リストのことをサービス・カタログといい、それを作成するプロセスをサービス・カタログ管理といいます。
　サービス・カタログの項目を取捨選択し、ＩＴサービスのレベルに関して、ベンダと顧客の間で合意をすることをＳＬＡ（Service Level Agreement）といいます。ＳＬＡを適切に管理するのがサービスレベル管理です。
　ＳＬＡの内容は多様です。例えば、対象業務の開発者がベンダである場合、その情報システムの保守は自社で行えるでしょうが、ネットワークの故障などは専門のベンダに依頼することになりましょう。ハードウェアやソフトウェアのベンダ、アウトソーシングやＳａａＳのプロバイダなど、ＩＴサービスのプロバイダとは異なる企業をサプライヤといいます。ＩＴサービスを行うには、サプライヤが提供するサービスや製品に関する情報、サプライヤとの契約などを管理することが必要になります。それをサプライヤ管理といいます。

ＩＴサービスで重要になる項目には、次のようなものがあります。

• ＩＴサービスでは、情報セキュリティ管理により、機密性、可用性、完全性を高めることが重要なのはいうまでもありません。
• 利用者がいつでもシステムを利用できるようにするため、ＢＣＭ（Business Continyuity Management：事業継続管理）の観点から、復旧を迅速に行なうために、機器の二重化やデータのバックアップなどの運用が必要になります。それが可用性管理とＩＴサービス継続性管理です。
• ハードウェアやネットワークなどの能力を、費用対効果の視点から最適なレベルで提供するキャパシティ管理が求められます。

サービス移行（Service Transition）

ＩＴサービスをビジネス環境で運用するのにあたり、長期的な視点で変更管理の役割や変更実行をするとき、リスクや利点、提供の仕組みやサービス運用の容易化に関する分野を取り扱います。

変更管理

インシデントの発生や利用者の要求により、システムへの変更要求があったとき、円滑に変更が行える仕組みにすることが必要です。変更要求を検討し、承認／却下の決定をするための変更諮問委員会の設置、変更手続き、その記録の維持と活用などを示しています。

リリース管理および展開管理

変更が行われたとき，テストを行い，改訂後のシステムを運用に移します。変更を許可された構成アイテム（ハードウェア、ソフトウェア、文書など）をリリースといい、それを全面的に適用することを展開といいます。リリースされた内容の記録、展開の方法の選択などを対象にしています。

サービス資産管理および構成管理

サービス資産とは、ＩＴサービスの対象になるものの総称で、それを構成するハードウェア、ソフトウェア、要員、ＳＬＡ文書などのことをＣＩ（Configration Item：構成アイテム）といいます。それぞれのＣＩについて、基本事項、インシデントの内容、変更を行った記録などを記録したデータベースをＣＭＢＤ（Configuration Management Data Base : 構成管理データベース）といい、それを活用するシステムをＣＭＳ（Configuration Management System）といいます。

サービス運用（Service Operation）

日常的なＩＴサービスの運用に関する分野を対象に、発生から解決までのプロセスと、それために必要となる機能について解説しています。

プロセスに関する事項

プロセスとは、目標を達成するための一連の活動のことです。サービス運用では、次のプロセスがあります。

実際にシステムを運用する間に発生する異常事態をイベントといい、影響度が大きくなる（エスカレートする）ものをインシデントといいます。イベント発生を認知して、その影響を分析するプロセスをイベント管理といい、インシデントにエスカレートしたときに、影響を最少化し、迅速な回復を図るプロセスをインシデント管理といいます。
　インシデント管理は臨床的な対応ですが、同様なインシデントが再発しないようにするには、病理学的に根本原因を特定して除去することが必要です。それを問題管理といいます。

アプリケーションのインストール、新規ユーザの登録、利用者からの問い合わせへの応答など日常的に発生するサービスに応えることを要求実現といいます。頻度が大きく、リスクが小さいのが特徴です。
　特に、利用者のアクセス権限に関する管理は、情報セキュリティ対策の観点から重要な事項です。そのため、これをアクセス管理として独立させています。

機能に関する事項

上記のプロセスを円滑に行うために必要な組織や能力を機能といいます。
　ジョブスケジュールやデータのバックアップ／リストアなど、日常的な情報処理の運用を行う組織をＩＴ運用管理といいます。システムに異常が発生せず、利用者からの要求もなければ、ＩＴ運用管理だけでよいのですが、実際には、これらが発生するので、その対処のための組織が必要になります。
　ＩＴサービスで重要な組織がサービスデスクです。すべてのプロセスに関する利用者への総合窓口になります。
　専門的知識・能力を必要とする事項を支援するためのサポートグループに、ＩＴのインフラに関する技術管理、と実務に適用されているアプリケーションに関するアプリケーション管理があります。

プロセスのライフサイクル

インシデント管理を例にして、その開始から終結までの作業手順（ライフサイクル）を示します。他のプロセスでもほぼ同様です。

1. 開始：インシデント管理は、イベント管理からのエスカレーションやサービスデスクを通して利用者からの伝達により開始される。
2. インシデントの識別と記録：状況を正確に把握して、ハードウェアの故障、ソフトウェアのエラー、利用者からの問い合わせなどに分類して記録する。
3. 優先度の決定：緊急度と影響の大小により決定
4. 初期診断：過去の同様なインシデントなどにより、サービスデスクで解決可能か、専門スキルをもつサポートグループに依頼すべきかを決定する。
5. 対応策の検討：サービスデスクあるいはサービスグループは、早期復旧を目的とした臨床的な解決策を検討する。
6. 解決と復旧：対応策により復旧作業を行う。このとき、復旧作業の状況を利用者に連絡することが必要である。
7. 終結：復旧作業が完了し、利用者が満足した時点で、インシデント管理が終結する。

データベースの重要性

インシデントが発生したとき、その対処を容易にするためには、過去の同様な事象に対して行った情報を適切に活用することが重要です。それには、各作業において、その情報をデータベースに記録する必要があります。
　問題管理を例にすれば、インシデントを引き起こす未知の原因を「問題」といい、解決した問題を「既知のエラー」といいます。問題管理とは、問題を既知のエラーにするプロセスだといえます。問題が発生したとき、その対策のことを「回避策」といい、回避策を講じた結果、適切な解決ができた対策方法を「問題モデル」といいます。これらの情報をデータベースにしたものを、ＫＥＤＢ（Known Error Database：既知のエラーのデータベース）といいます。ＫＥＤＢに適切な情報が入力されており有効に活用できれば、インシデント管理も容易にできます。問題管理とは、ＫＥＤＢの構築、維持、活用の方法だともいえます。
　このようなデータベースは、構成管理でのＣＭＤＢのように、いくつかのデータベースがあります。それらが統一した観点から設計され、相互に連携できるようにすることが重要です。

サービスデスク

サービスデスクとは、ヘルプデスクやコールセンターと似た任務ですが、利用者からの問い合わせ、障害報告、改善提案、クレームなどＩＴサービスに関する総合窓口です。サービスデスクで解決できない場合は、技術管理やアプリケーション管理など専門的な知識をもつサポートグループに連絡しますが、あくまでも利用者との窓口はサービスデスクに集利用者との窓口を一元化することにより、どのような事項にも責任をもって対応し、サービスを確実に提供することができます。

継続的サービス改善（Continual Service Improvement）

ＩＴサービスを、ＰＤＣＡサイクルにより、継続的に改善する方法を、７つの改善ステップとして示しています。

1. 測定対象の定義：ＩＴサービスの改善のためには、何をどのレベルまで向上させるのかを検討して決定する必要があります。
2. 測定できる内容の定義：選択した項目が測定できるか検討します。
3. データの収集：測定に必要なデータを収集するための方法を決定して、実際の収集を開始します。
4. データの処理：収集したデータを処理して、適切な情報にします。
5. データの分析：その情報を分析して、目標達成度の測定、不達成の場合の原因分析などを行います。
6. 情報の提示、活用：分析結果を関係者に報告します。
7. 是正措置の実施：報告により是正措置が必要と判断された場合には、それに応じてＩＴサービスを改善します。