ITILファンデーション試験対策第２章サービスサポート







Ⅰ				サービスサポートとは
				サービスサポートは、ITサービスの日々の運用について記述された書籍であり、1つの機能と5つのプロセスから成り立つものである。具体的には、サービスデスクの機能と、インシデント管理・問題管理・構成管理・変更管理・リリース管理の各プロセスが挙げられる。

Ⅱ				サービスサポートの機能とプロセス
				サービスサポートの中核となるのは、ユーザとの単一窓口として操作方法などの問合せや障害連絡・変更要求を受け付けると共に、ITサービスをユーザが利用する上で有用な情報を発信する、サービスデスクの機能である。機能としてのサービスデスクは、複数のプロセスを担う。一方、インシデント管理は、サービスデスクが受け付けたインシデントについて、その発生を受けて速やかにITサービスを回復させビジネスへの影響を最小限にするプロセスである。問題管理は、インシデントを引き起こしている根本的な原因である問題を発見・除去するプロセスである。構成管理は、ハードウェア・ソフトウェアに限らず文書・手順・スタッフなどITサービスを提供するために必要な構成アイテム（CI）を一元管理する構成管理データベース（CMDB）を構築・維持するプロセスである。変更管理は、変更要求（RFC）に基づきITサービスに関する標準外（マニュアル化の範疇外）の変更を一元的にコントロールするプロセスである。リリース管理は、ハードウェア・ソフトウェアなどのCIを実環境に投入すると共に確定版ソフトウェアの保管庫（DSL）や確定版ハードウェアの保管庫（DHL）の維持・管理を行うプロセスである。



Ⅰ				サービスデスクとは
				サービスデスクは、唯一の窓口であり、インシデントのコントロールを行い最終的な責任を負う。その機能としては、一般的に、顧客やユーザからのコールの受け付けと一次対応窓口、インシデントの記録及び追跡、要求のステータスと進捗情報の継続的な顧客への提供、要求解決若しくは解決し得る者への照会、SLAに基づく要求の初期評価、SLAに準じた監視とエスカレーション、クローズ・検証を含む要求のライフサイクルの管理、計画的・短期的なサービスレベルの顧客への変更連絡などの他、顧客満足度の分析と調査などが挙げられる。サービスデスクの機能は、属人化や品質面の信頼性などのサポート部門が抱える現状への解決策、コスト削減や顧客満足度向上などの組織におけるサービスデスクの有用性、及びサービスサポートの課金の観点から必要とされるが、その最終目標は、インシデント発生時に、単一の窓口を通して、SLAと業務上の優先順位に基づきビジネスへのインパクトを最小限に抑えて通常のサービスへの回復を促進することである。

Ⅱ				サービスデスク・インフラストラクチャの導入
				サービスデスクの導入・定義に際しては、その有効性の測定基準の目標値を予め設定し、継続的なレビューで実績値との比較を行うと共に、ビジネスニーズを特定し明確化すること、簡単なものから段階的にサービスを拡充していくこと、達成目標と成果物のオーナーシップの定義を行うこと、エンドユーザに参画の機会を与えること、新しいサービスのメリットを顧客・ユーザに理解してもらうことなどを検討しつつ、現在のプロセスの自動化や、コスト削減・ITサービス価値向上につながるプロセスの再設計を行うことが求められる。サービスデスクの構造・形態としては、各拠点に同一のスキル・リソースを配置するため最もコストが高いローカルサービスデスク、全てのサービス要求を物理的に中央にあるサービスデスクに記録するため集約化・共有化によるコスト削減や利用率改善が見込める中央サービスデスク、さらにそれを発展させネットワーク経由で世界中どこにでも設置できるようにしたバーチャルサービスデスクのいずれかを、事業・利用の最適化の観点から検討することとなる。また技術面においては、インシデントの状況や既知のエラー・コール履歴・過去の類似事例の解決策などを検索できるようにするコンピュータ化や、サービス時間外や重要度の低いインシデントについてWeb上のFAQなどのツールによりユーザに自己解決を促すセルフサービス戦略などを検討し、生産性や顧客満足度の向上を図ることが求められる。

Ⅲ				サービスデスクにおける考慮点
				サービスデスクの導入・維持に関する重要成功要因は、顧客のビジネスニーズを理解していること、サービスの達成目標・成果物・最終目標が明確に定義されていること、サービスレベルが実用的で顧客の合意が得られており定期的にレビューを受けていること、サービスデスクの利点をビジネス側が認めておりその協力に対してマネジメントがコミットメントを行っていること、である。このためには、まず、作業場所や関連資料などのサービスデスク環境を準備し、かつ、達成目標を定めた顧客・ユーザ・スタッフそれぞれに対する教育、スタッフに対する技術面・コミュニケーション面のトレーニングを実施することが求められる。また、顧客・ユーザ対応のプロセスにおいて、誰が対応しても要求を汲み取り管理し得るような共通の質問体系や、CRMの観点からの顧客の詳細と識別情報の確保とそれらを含むデータベースの整備・維持、インシデントや問題の傾向分析に基づく新しい参考資料の提供やセミナなどを通じたマーケティングなども求められる。さらにインシデントの報告・レビューについては、スタッフの稼働率を最適化するための作業負荷の効果的な分析を含め、管理者が意思決定できるレポートを作成し、合意されたサービスレベルと成果物に基づいてパフォーマンスを測定できるよう、わかりやすく報告することが有効とされている。なお、サービスデスクスタッフに最も求められるスキルは、ビジネス意識である。



Ⅰ				インシデント管理とは
				インシデント管理は、インシデント発生時、可能で最適なレベルのサービスの品質と可用性を維持し、SLAで合意された時間内に迅速に通常のサービス運用状態まで復旧させることによってビジネスへの影響を最小限に抑えることを最終目標とするプロセスである。具体的には、インシデントの検知と記録、分類と初期サポート、調査と診断、解決と復旧、インシデントのクローズ、及びそれらに共通するオーナーシップ・監視・追跡・コミュニケーションという計6つの活動により構成される。インシデント管理を行うことにより、SLAとの対比でパフォーマンスを測定・監視できること、スタッフの稼働率向上による効率的な組織運営が可能となること、インシデントやサービス要求の喪失・間違いを排除できること、より正確なCMDB（構成管理データベース）情報を利用できること、顧客・ユーザの満足度向上を図ることができること、などの他、ビジネス全体においてもインパクトを減少させられること、SLAに関連してビジネスにフォーカスした管理情報を入手できることといった利点が期待される。

Ⅱ				インシデント管理プロセスの役割と責任
				インシデント管理プロセスは、一次サポートとしてのサービスデスクと、原因調査・解決のための専門家グループなどの二次サポートやそれ以降により構成され、一次で解決できないインシデントは二次、二次で解決できないインシデントは三次、と、機能的エスカレーションが為される。また、合意された時間内や品質での解決結果が出ない場合などには、上司など上位者へ階層的エスカレーションが為される。なお、インシデントの優先度は、ビジネスへのインパクトと、復旧に要する時間的尺度である緊急度により決定される。一次サポートとしてのサービスデスクは、全てのインシデントの登録、初期サポートによる解決及び分類、オーナーシップ・監視・追跡・コミュニケーションの活動としてのインシデントの状態の監視及びクローズについて役割と責任を持ち、専門家グループである二次サポート以降は、サービス要求への対処、インシデントの調査と診断、問題管理チームへの問題の割り当て、割り当てられたインシデントの解決と復旧について責任を負う。また、インシデントマネージャは、インシデント管理プロセスの効率と効果の最適化、インシデントに関する管理情報の生成、スタッフの管理・監督、インシデント管理システムの構築・維持に責任を負う。

Ⅲ				インシデント管理プロセス
				そもそもインシデントは、ITインフラストラクチャで発生した障害・エラーの結果である。このうち原因が解明できないものが問題であり、過去の問題に対するワークアラウンド（回避手順）やRFC（コンポーネントに対する変更要求）が作成されていれば既知のエラーとなる。これを踏まえ、インシデント管理プロセスでは、まず、インシデントや問題や既知のエラーの各データベースでインシデントを照合し、解決策がない場合はワークアラウンドを探す。ワークアラウンドが見つかった場合、それを問題管理チームが分析し、必要に応じて問題レコードを作成し、サービスデスクがインシデントと問題レコードを関連付ける。問題管理チームによる調査の結果、関連するインシデントのワークアラウンドや解決策が発見された場合、ステータスを既知のエラー若しくはクローズに変更するため、インシデント管理チームにその情報を提供する。なお、インシデント管理の活動のうち、調査と診断に際してはビジネスへのインパクトを最小限に抑えるためできる限りワークアラウンドを顧客に提供することが求められ、インシデントのクローズに際しては処置の詳細記録の実施と解決策またはワークアラウンドに関する顧客の合意取得が求められる。

Ⅳ				インシデント管理における考慮点
				インシデント管理プロセスの重要成功要因は、インパクトと緊急度の判断を早急に行うためCMDBは常に最新の状態に保つこと、解決スピードを向上させるため問題や既知のエラーに関するナレッジデータベースを構築・維持すること、自動化されたインシデント管理の仕組みを用意すること、サービスレベル管理プロセスと密接な関係を保つこと、である。このためには、インシデント管理のみならず他のサービスサポートの機能・プロセスの導入・運用及びそれらとの統合も考慮に入れて計画すること、特にサービスデスクの機能を優先すること、構成管理との連携に際してCMDBが存在しない場合はインシデント管理の仕組みとして構築すること、が求められる。インシデント管理プロセスの重要業績評価指標（KPI）としては、インシデントの総数、解決や回避までの平均所要時間、SLA範囲内で処理された割合、インシデントごとの平均コスト、一次サポートとしてのサービスデスクで完結したインシデントの割合、リモート対応で解決できたインシデントの割合、などが挙げられる。



Ⅰ				問題管理とは
				問題管理は、構成アイテム（CI）の障害の根本原因を調査・追究して解決しワークアラウンドの情報をサービスデスクに提供すること、及びトレンド分析などによりインシデントが起きる前に問題や既知のエラーの識別を行い予防措置を特定・実施することで事前に解決することを最終目標とするプロセスである。前者をリアクティブな問題管理、後者をプロアクティブな問題管理と称するが、これらはいずれも所要時間の優先順位が低く、迅速な解決を目指すインシデント管理とは対極に位置付けられる。問題管理の利点としては、ITサービス品質の改善、インシデント量の削減、未解決の問題数の減少、組織的な学習の改善、解決策やワークアラウンドの蓄積によるサービスデスクの初回問題解決率の向上、などが挙げられる。なお、問題管理では、問題マネージャと問題サポートの役割が設けられている。

Ⅱ				問題管理プロセス
				問題管理プロセスは、問題コントロールの活動とエラーコントロールの活動に大別される。問題コントロールの活動では、まず、問題の識別と記録として様々な契機で識別された全ての問題が問題レコードとしてCMDBに記録され、次に、インパクトや緊急度に応じた問題の分類が為される。その後、問題の調査と診断、問題解決とクローズが為されるが、既知のエラーについてはエラーコントロールへ引き渡されることとなる。エラーコントロールの活動では、まず、エラーの識別と記録が為され、次にエラーの評価が為される。エラーの評価においては、問題管理のスタッフが専門スタッフと協力し、変更管理の手順に則した変更要求（RFC）の作成、ベンダーによる保守製品の場合はベンダーとの是正措置の実施を行う。解決後、エラーの解決策の記録を経て、エラーのクローズとして関連する問題レコードやインシデントレコード共々エラーレコードをクローズする。なお、問題管理プロセスでは問題・エラーの追跡と監視も常時行われるが、解決状況については変更管理から定期的にレポートを受け取るなどしてその進捗状況を監視し、SLAに照らして必要に応じてRFCの優先順位を上げることを変更諮問委員会（CAB）に諮らなければならない。

Ⅲ				問題管理における考慮点
				問題管理プロセスの重要成功要因は、インシデントを自動的に登録・分類し効率良く作業を行うこと、目標が対極に位置付けられるインシデント管理との十分なコミュニケーションを確保すること、達成可能な達成目標を設定して既存スタッフの問題解決能力を活用すること、である。このためには、インシデントコントロール・問題コントロール・エラーコントロールの履歴情報からサービス品質のパフォーマンス指標を導き出すことが有効とされるが、この際、測定基準については測定可能な目標値や基準を定義しそれをコントロールとして使用すること、問題コントロール・エラーコントロールの報告には提起されたRFCや所要時間の他に解決計画・リソース計画や問題解決のためにとるべき処置を含めること、問題管理プロセス全ての運用・手順について定期的な監査を受けること、などが検討されなければならない。



Ⅰ				構成管理とは
				構成管理は、効果的にITサービスが提供されるためにITインフラストラクチャやITサービスの全ての構成アイテム（CI）を管理し、構成情報からITインフラストラクチャやITサービスの論理的モデルを提供することを通して変更管理・リリース管理・問題管理・インシデント管理といった各プロセスを支援するプロセスである。構成管理では、構成管理で登録されている全てのCIの入庫・識別・保管・破棄のコントロールや、変更に際して影響を受ける可能性のあるCIの評価や情報収集を司る構成司書と、それ以外の計画作成・導入管理全般を司る構成マネージャの役割が設けられている。構成管理の利点としては、既述の各プロセスへの支援の他、変更に対するインパクト分析によるリスク軽減やアクセスコントロール・バージョンコントロールによる悪意のCI変更や誤ったCI適用の回避、特定のCIの問題のトレンド分析と問題管理への情報提供を通したプロアクティブな問題管理への寄与、などが挙げられる。なお、SLAや手順はCIになり得るが、CIの属性に過ぎないステータスはCIにはなり得ない。

Ⅱ				構成管理プロセス
				構成管理プロセスは、構成管理計画立案、構成識別、CIのコントロール、構成ステータスの説明、構成検証と監査、CMDBのバックアップ、という一連の6つの活動に大別される。構成管理計画立案では、既存の手順を参照しつつ当初3～6ヶ月の詳細計画と続く12ヶ月の概要計画を立て、管理下のCIについてキャパシティ計画や作業負荷トレンドから増加の情報を入手しつつ定期的にレビューを行い、ITリソース・スタッフ・CMDBサイズが十分か確認し、必要に応じて再計画を行う。構成識別では、ハードウェア・ソフトウェア・ネットワーク機器・データベース・業務アプリケーション・各種文書・各種計画やインシデントや問題や既知のエラーやRFCなど様々な構成要素であるCIを、事業が必要とするレベルに分解・識別し、CIの関係や属性やライフサイクルについてCMDBに保存し、ある時点で正式に合意された構成情報である構成ベースラインを作成し、CIの命名規則とラベル付けを行う。なお、基本的に同じだがやや容量等の数値が異なるCIをバリアントと言う。続くCIのコントロールでは、「登録済み」「使用中」「廃棄済み」などのCIのステータスについて、発注等の時点からの全ての登録、変更レコードも作成する形でのCMDB上での自動更新、財務とセキュリティの観点からのCIの削除とアーカイブ、構成の完全性の確保、物理アイテムの検査・突合せによる未許可のCI発見時の報告・削除・調査等が行われる。この他、定期的な構成ステータスの説明（レポート）、大規模な変更前及び定期的な構成検証と監査、定期的なCMDBのバックアップが求められる。

Ⅲ				構成管理における考慮点
				構成管理の活動は構成管理計画に沿ったものでなければならず、CMDB上のCIは他のプロセスへの支援を行い得る十分なレベルにあり、ITサービスマネジメントスタッフが完全で最新のデータやレコードへ常にアクセスできなければならない。また、スタッフはトレーニングされており、かつ適切なレベルでツールの自動化が行われていなければならない。具体的なツールとしては、構成管理システム、ソフトウェア構成管理、構成監査などのいずれも自動化されたものが挙げられる。構成管理プロセスの重要業績評価指標（KPI）としては、測定可能な目標値として、発見された未許可の構成、様々な理由で失敗したRFC、変更を許可し実装するサイクル時間、構成監査による例外報告、誤った実装にその原因を遡ることができるインシデント・問題、などが挙げられる。



Ⅰ				変更管理とは
				変更管理は、全ての変更を効率的かつ迅速に取り扱うために、標準化された方法・手順が使われることを確実にすることで、変更に起因するインシデントがサービス品質に与えるインパクトを最小限にし、組織の日々の運用を改善していくことを最終目標とするプロセスである。変更管理チームは、ルーチンワーク的な標準的変更を除く全ての変更要求（RFC）について受付・登録・優先順位付け・場合によっては却下を行い、変更諮問委員会（CAB）または変更諮問委員会緊急会議（CAB/EC）を招集して議長を務め、変更の構築・テストについて進捗やプロセスを監視して必要な調整を行い、事後のレビューを行い、RFCをクローズする他、サービスデスクを介して将来的な変更スケジュール（FSC）を発行したり、変更管理のレポートを顧客・ユーザ・サービスマネージャなどに宛ててそれぞれ用意し発行したりする。

Ⅱ				変更管理プロセス
				変更管理プロセスは、順に、運用プロセスの導入計画立案、変更の登録とフィルタリング、変更への優先度の割り当て、変更のカテゴリ化、CABミーティング開催、インパクト評価とリソース評価、変更の許可、変更のスケジュール化、変更の構築・テスト及び実装、変更のレビュー、変更管理プロセスの効率及び有効性に対するレビュー、といった活動により構成される。このうち、変更の登録においてはRFCと問題レコード（PR）の関連を保持すると共に関係する全ての構成アイテム（CI）とデータとCI間の関係をも保存できるツールを用意することが求められ、変更への優先度の割り当て・変更のカテゴリ化・インパクト評価においては変更がビジネスに与えるインパクトの多寡を以て決定することが求められる。変更に正式な認可を与える変更許可委員は、変更マネージャ、サービスマネージャ、若しくはその指名を受けた者のいずれかである（CABなどではない）が、変更のインパクトや複雑さ如何でメンバーのレベルは変わる。なお、CABは、変更マネージャ、顧客・ユーザ、ユーザマネージャ、ユーザグループの代表、技術専門家、必要に応じて契約事業者・外部組織や他プロセスの代表・サービススタッフにより構成され、CAB/ECはより少人数で構成される。

Ⅲ				変更管理における考慮点
				変更管理プロセスを経ずに変更が行われることや、構成管理無しで変更管理を導入してしまうこと、切り戻しが未定義・未テストで実際に発生した場合にコストがかかること、マネジメントのコミットメントが不十分であるためスタッフが変更管理コントロールに抵抗しやすく形骸化することなどが懸念材料として挙げられる。対応策としては、変更管理スタッフ・サポートスタッフ・ユーザが変更管理プロセスを遵守しているか否かの定期的な監査の実施、構成管理が把握していない未知の構成アイテム（CI）のサービスデスクを介した検知、スタッフのトレーニングなどが挙げられる。なお、変更のテストは、実際に当該変更に関わる者ではなく、それらから影響を受けない独立したテスト担当者がこれを行うことが望ましい。変更管理プロセスの重要業績評価指標（KPI）としては、測定可能な目標値として、実装に成功・失敗した変更数、実装後レビューされた変更数、切り戻された変更数、承認・却下されたRFCの数とトレンド、変更に関するインシデント数、などが挙げられる。



Ⅰ				リリース管理とは
				リリース管理は、変更管理の監視・コントロール下で、変更管理で承認された変更要求（RFC）に対する変更を確実に実装するプロセスである。実装されるCIの変更は変更管理がコントロールするが、標準的な構築・実装方法が定義されている場合、都度変更管理に照会せずともリリース活動を行うことができる。

Ⅱ				リリース管理プロセス
				リリース管理プロセスは、順に、リリース計画立案、リリースの設計・構築及び設定、リリースの受け入れ、投入計画立案、コミュニケーション・準備及びトレーニング、配布とインストール、といった活動により構成され、それぞれが構成管理データベース（CMDB）や確定版ソフトウェアの保管庫（DSL）、確定版ハードウェアの保管庫（DHS）とやり取りを行う。DSLやDHSはあくまでも場所・保管庫であり、各構成内容や情報は全てCMDBに記録される。そもそもリリースは、大規模・小規模・緊急の修正に分類され、大規模は小規模を、小規模は緊急の修正を、それぞれ包含する。またリリースのタイプは、全コンポーネント一括のフルリリース、前回リリースからの差分のみのデルタリリース、複数のリリースを同時に行うパッケージリリースに分けられる。

Ⅲ				リリース管理における考慮点
				リリース管理プロセスの重要業績評価指標（KPI）としては、予め定められたスケジュール・予算内で構築・実装されたリリースの数、構築・実装・配布活動における正確なCMDBの更新数、違法に使用されているソフトウェア数、未許可で使用されているソフトウェア数、以前のバージョンの未許可の復元の形跡がないものの割合、DSL内で品質チェックに合格しているソフトウェア数、DSLから出されたソフトウェアに対して改変の形跡がないものの割合、などが挙げられる。

Copyright(C)2006,2007 増田剛三 <msd@masmas.jp> ［注意事項］［目次・一覧］　次［第３章・サービスデリバリ］　前［第１章・一般知識］