ＩＴＩＬ

ＩＴＩＬの概要

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

ＩＴサービスは、従来は運用管理、保守管理といわれていました。
　情報システムは利用している間に，利用者からの改善要望,環境変化に伴う情報システムの改訂，アクセス増大へのハードウェア対策，セキュリティ強化，予期しない事故など多様な問題が発生します。これらへの対応が不適切だと，対応に時間や労力がかかる，改訂により新しいエラーが発生するなどの問題が生じます。
　ＩＴ活用が高度化・広範囲化してきたため、情報システムのトラブルは、企業活動だけでなく、社会的にも大きな影響を及ぼすようになりました。しかも、情報システムの開発者、運用者、利用者の関係が複雑になってきました。

このような状況の変化により、運用・保守の重要性が認識されるとともに、ＩＴの利用環境の整備，情報システムの有効性の確保など，従来の保守・運用の概念を広げることが必要になり、「ＩＴサービス」というようになりました。そして、ＩＴサービスを経営や業務の観点からとらえて、総合的に継続的な改善活動としてマネジメントすることをＩＴサービスマネジメントといいます。

なお、ＩＴサービスの提供者と利用者の間で、サービスレベルに関して合意をすることをＳＬＡ（Service Level Agreement）といいますが、ＳＬＡはＩＴサービスマネジメントの一部分であり、それを詳細にしたものだといえます。

ＩＴＩＬ

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

企業（主にベンダ）がISO/IEC 20000に準拠しているかを第三者が認定するＩＴＳＭＳ適合性評価制度（ＩＴＳＭＳ：IT Security Management System）があります。
　ＩＴサービスを提供する企業にとって、顧客の要求事項を満たすために、適切に運営管理されたサービスを効果的に提供することが必要ですが、ＩＴＩＬはそのためのチェックリストとして適切ですし、ＩＴＳＭＳ適合性評価制度の認定を受けることは信用の向上に役立ちます。

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

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

ステージの関係は、次のようになります。すべてのステージでの情報がデータベースに保管され、ＳＫＭＳ（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）

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

サービス運用のプロセス

プロセスとは、目標を達成するための一連の活動のことです（ここでは、それを「○○管理」と表現しています）。
　サービス運用でのインシデント発生から解決までのプロセスとその流れの概念図を掲げます（この図は旧版ＩＴＩＬｖ２に掲載されていたもので、「サービス移行」の一部も含まれていますが、本質的にはＩＴＩＬｖ３でも同じです）。

（拡大図）

サービス運用の基本は、システムの異常により業務が中断する期間を短縮することにあります。そのためには、異常による影響度の大小による適切な対応、解決までの時間短縮のための過去の類似ケース記録の有効活用がポイントになります。以下のプロセスは、それを体系的に示したものです（なお、「アクセス管理」などセキュリティ対策分野の管理は、この体系から独立させています）。

イベント管理

実際にシステムを運用する間に発生する異常事態、あるいは改善要求をイベントといいます。その発生は、利用者からの通知や要求もありますし、ＩＴＩＬ運営者が自ら監視や検討して発見することもあります（ここでは、記述を単純にするため、利用者からの要求に絞ります）。
イベント発生を認知して、その影響を分析するプロセスをイベント管理といいます。サービスデスク（ヘルプデスク）が担当します。
イベントのうち、パソコン操作の質問や新規ユーザの登録など、他への影響度が小さく単純に答えられるものは、記録にとどめるだけ完了します。

インシデント管理

イベントのうち、発生の原因を調査する必要があるものや影響が大きくなる（エスカレートする）ものをインシデントといいます。インシデントが発生したら、それを台帳（ＣＭＤＢ）に記録します。これはその後の解決や利用者への連絡のインデクスになります。
インシデント管理とは、インシデントに対して、影響を最少化し、迅速な回復を図るプロセスです。そのために、インシデントを障害回復要求／サービス要求／情報照会などに分類し、緊急性などによる優先度の決定などが必要になります。
インシデント管理は臨床的な解決が目的で、原因調査などは行いません（問題管理で行う）。既知のエラー（過去に同様なインシデントがあり、解決方法がわかっているもの。ＫＥＤＢを照合）については、それを伝えて記録して完了します。

問題管理

同様なインシデントが再発しないようにするには、根本的な対策が必要になります。それをインシデントが問題にエスカレーションしたといい、その管理を問題管理といいます。
問題管理では、病理学的に根本原因を特定します。これにより類似の問題発生を予防できます。
根本原因が特定したら、変更管理に変更要求を出します。その変更要求のことをＲＦＣ（Request For Change）といいます。

変更管理

変更管理では、インシデント管理や問題管理からのＲＦＣの内容（変更には、「問題発生への解決対策」と「改善」の２つがあります）について、変更の緊急性や影響度、それにかかるコストや時間などを評価して、認可／却下の決定、優先度の決定をします。
認可したものは、実際の変更作業はリリース管理が行なうのが通常ですが、変更方法の決定、実装の確認などは変更管理の任務です。
変更内容は障害原因などの究明にも役立つので，必ず記録することが重要です。

リリース管理

リリース管理では、変更管理で計画した変更を実施、テストして、実装し利用者への周知などを行います。リリース管理は変更管理の一部で、変更管理が変更に伴う多様な決定をするのに対して、リリース管理は変更が決定してからの作業手順管理です。通常は情報システム部門が担当します。 なお、変更したシステムなどの稼働環境へ移行の管理を展開管理といいます。リリース管理に展開管理も含めることもあります。

機能に関する事項

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

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

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

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

データベースの重要性

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

サービスデスク

サービスデスクとは、利用者からの問い合わせ、障害報告、改善提案、クレームなどＩＴサービスに関する総合窓口です。
　イベント管理やインシデント管理を担当して、早急に利用者が業務を継続するように支援するのが主任務ですが、問題管理やリリース管理の状況やその結果を利用者に伝えるのも任務です。
　サービスデスクで解決できない場合は、問題管理や技術管理など専門的な知識をもつグループに連絡して解決を依頼しますが、あくまでも利用者との窓口はサービスデスクに集中して一元化する（タライ回しをしない）ことが必要です。

サービスデスクは利用者との唯一の接点ですから、その応対如何がＩＴサービス全体への評価に直結します。サービスデスクのサービスレベルを向上させることが必要です。利用者満足を得るためには、利用者の立場にたって業務をすることが求められます。また、限られた人数で対処するために、
・サービスデスクの可用性：業務時間の検討、電話待ち時間の短縮など
・問題解決までの時間：たらいまわしをせず初回コールでの解決、電話時間の短縮など
がサービスレベルの尺度になります。
消費者対象での受注や問合せに応じる電話窓口をコールセンターといいます。コールセンターでは、これらの尺度の改善のために多様な工夫をしています。

サービスデスクの設置場所や組織構造は多様です。大きく次のように区分されますが、その中間的なものや組み合わせたものがあります。

ローカルサービスデスク

客先の事業所あるいはその近辺に設置。ユーザとのコミュニケーションが密接になりユーザの特性に応じたサービスができる、迅速に対応できるなどの利点があります。全体として多数のスタッフが必要になります。大規模な客先の場合に採用されます。

中央サービスデスク

スタッフを一か所に集中する形態です。効率が良いだけでなく、質の高いスタッフを待機させることができます。また、豊富な情報を蓄積し検索する機能を構築しやすい効果があります。しかし、ユーザへのきめの細かい迅速なサービスをするには不向きです。

バーチャルサービスデスク

Ｗｅｂ上に構築したサービスデスクです。スタッフを在宅勤務させたり、外部にアウトソーシングすることができるので、柔軟な運用体制が可能です。適切に運用できれば、ローカルサービスデスクと中央サービスデスクの長所が生かせますが、不適切な場合は、サービスの品質や客先の信頼を低下させる危険性があります。

フォロー・ザ・サン

多国籍企業などが地球規模で構築したサービスデスクです。昼夜の時間差を吸収することにより２４時間体制ができます。各国の言語や習慣などの違いに対応する必要があります。

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

ＩＴサービス全般について、効率性・有効性、および費用対策を向上するために、ＩＴサービス提供者のパフォーマンスを継続的に測定し、報告し、改善を加えるプロセスです。

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

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