ITIL 的目标

ITIL の目標

構成管理目標

第 4 章

多くのITIL専門家は、ITILにおいて構成管理は「太陽」であり、その周りを他の「惑星」が回転していると述べています。他のすべてのITILプロセスが構成管理に密接な関係を持っているため、この比喩はまさにその通りと言えます。その結果、ITILを実行したときに構成管理の目標を達成することが成功には不可欠です。あなたはITIL構成管理目標を達成していますか?それらの目標を見てみましょう。

構成管理は、現行の構成品目（CI）のバージョンの特定、コントロール、維持、検証によって、インフラまたはサービスの論理モデルを提供します。

構成管理の目標は以下の通りです。

  • 組織とそのサービスにおけるすべてのIT資産と構成を明らかにする。
  • 構成とそれらの文書を提供し、他の全てのサービス管理プロセスをサポートする。
  • インシデント管理、問題管理、変更管理、およびリリース管理の健全な基盤を提供する。
  • インフラストラクチャに対して構成記録を検証し、いかなる例外も修正する。

ITIL導入の正当性を示す際の助けとなるものが得られるように、構成管理の目標における基本的な構成要素を検討してその目標をさらに徹底的に分析してみましょう。

「構成管理は、現行の構成品目（CI）のバージョンの特定、コントロール、維持、検証によって、インフラまたはサービスの論理モデルを提供する」

この要素を検討するには、構成品目のITIL定義を理解する必要があります。

構成管理のコントロール下の（あるいはコントロール下にあるべき）インフラストラクチャ・コンポーネントまたはアイテム。CIは、複雑性、サイズおよびタイプにおいて、システム全体（すべてのハードウェア、ソフトウェア、および文書を含む）から、ただ一つのモジュールあるいは小さいハードウェア・コンポーネントに至るまで様々です。

構成品目は、IT顧客に対する同意されたサービスの提供に必要なサービス、システム、およびアプリケーションを提供するために必要なインフラストラクチャ・コンポーネントです。CIの複雑性はあなた次第です。例えばワークステーションをひとつのCIとすることもできますし、あるいはワークステーションをコンポーネント（プロセッサ、キーボード、マウス、およびモニタ）に分割し、それぞれをCIとすることもできます。構成管理は主としてCI間のリレーションシップに関係しています。すなわち、一つのCIを調べることによって、それが特定のシステムあるいはサービスのプロセスに必要な他のCIにどう関連するかが分かります。サービスデスクは、CI間のリレーションシップを使用して、影響を特定し優先性を決定することができます。資産管理は上記の資産、それらの事業体、およびそれらの所在地に関する詳細を維持管理しますが、一方構成管理は、資産管理の管轄外の、資産間のリレーションシップの維持管理を行うことに注意してください。

あなたがこの目標要素を満たしているか否かの評価を行う際の第一の問題は、あなたがCI間あるいは資産間のリレーションシップを示すデータベースを持っているかどうかを判断することです。データベースを持っていない場合、どうやって影響を特定することができるでしょうか?遠隔地で起こる災害からどのように回復しますか?　最初に、中心的な資産データベースを持っているかどうか確認してください。データベースがある場合は、アイテム間のリレーションシップを示しているかどうかをチェックし、それに従って根拠を考えてください。中心的な資産データベースを持っていないという事実がそれ自体大きな正当性であることがわかるでしょう。

この目標要素は特に、構成品目のバージョンの特定、コントロール、維持管理、検証に関して説明しています。ここであなたは、構想から終了までのCIのライフサイクルを管理するための標準的アプローチを持っているかどうか判断する必要があります。標準的アプローチがある場合は、それが全てのCIをカバーしているか、そしてその手法が良好に保たれているか確認してください。データが不正確であるかどうかの良い手がかりは、構成／資産データベース上では顧客が持っていないとされているコンポーネントに関して、サービスデスクが顧客から問い合わせを受けるという事実です。例えば、顧客から「スキャナが作動していないのですが」という問い合わせがあったとします。それに対しサービスデスクは、「弊社の記録によると、お客様がスキャナを持っている事実はありませんからそれは当然です」と返答します。(少し馬鹿げているかもしれませんが、ポイントは明白です。)つまり、チェックすべきことは、CIを特定しコントロールするためのプロセスあるいは手続があるかどうか、そしてそれらのCIのステータスを維持するためのプロセスあるいは手続があるかどうかの二つです。その調査結果に従って、根拠を組み立ててください。

「組織とそのサービスにおけるすべてのIT資産と構成を明らかにする」すべてのCIが資産であるとは限らないため、これは重要な目的です。例えば、内部で書かれたプログラム、手続き上の文書、および人員は通常資産とはみなされませんが、それらはすべて構成品目です。この目標要素は、全ての潜在的CIが構成管理データベース（CMDB）に確実に含まれているようにチェックを行うべきであることを意味します。この要素を満たしているかどうかを判断するのは簡単です。あなたはチェックしていますか？もちろん、あなたがCMDBを持っていなければ、チェックも何もないでしょう。

「構成とそれらの文書を提供し、他の全てのサービス管理プロセスをサポートする」CMDBのデータが正確であるとすると、問題は、どのようにそれを他のサービス管理プロセスで利用可能にすることができるかということです。サービス管理プロセス同士の統合が重要です。サービスデスクがインシデントレコードにデータを入力しているとき、例えば、CIデータベースは構成と文書情報を用いて自動的に記録を入力していきますか?あるいは、サービスデスクの担当者は手動でその情報を入力しなければなりませんか?さらに悪いことに、それが利用できないために、データは全く記入されませんか?この目標要素を満たしているかどうかチェックするためには、他のサービス管理プロセスをチェックし、CMDBデータが使用されるとしたときにそれが使用されていない領域があるかどうかを特定してください。もちろん、あなたが構成データベースを持っていなければ、チェックも何もないでしょう。

「インシデント管理、問題管理、変更管理、およびリリース管理の健全な基盤を提供する」インシデント管理、問題管理、および変更管理は、情報としてCMDBを使用するプロセスであり、そしてもっと重要なのは意思決定目的のためにCMDBを使用するプロセスであるということです。正確で完全なCMDBにより、詳細な情報を得た上で、問題あるいはインシデントの影響を特定するための決断を行うことができます。それによって潜在的変化に対してより適正にコストを計算することができます。さらに、拡大化の正確性も向上します。

サービス管理は認識ツールと大きな関係があります。おそらく最も重要な認識は、資産として持っているもの、それらの位置、およびそれらの相互関係の認識です。すなわち、CMDBに含まれている情報です。しかし、そのCMDBの重要性は見落とされがちです。この目標要素は、CIに含まれている属性に焦点を合わせています。CMDBを持っているだけではその有効性を充分利用することはできません。 各CI含まれているデータは、サービス管理プロセスに重要な情報を提供するものでなければなりません。データが他のサービス管理プロセスに有用な情報を提供するかどうかを決定するには、CIの属性あるいはフィールドをチェックします。あなたは他のプロセスのオーナーに、彼らが必要とするデータが得られているかどうか聞かなければなりません。そして、もし得られていない場合、彼らがどんな追加データを必要とするかを聞く必要があります。これにより、あなたがこの目標要素を満たしているかどうか判断することができます。もちろん、あなたがCMDBを持っていなければ、チェックも何もないでしょう。

「インフラストラクチャに対して構成記録を検証し、いかなる例外も修正する」前述したように、構成管理は他のすべてのプロセスに情報とデータを提供します。この目標に必要なものが、すべてのCIがCMDBに存在していることではなく、CIの内容の正確性であることを除いて、この要素は前の要素に関連しています。前の要素の場合と同様、あなたがこの要素を満たしているかの検証は簡単です。つまり、チェックしているか、していないかの問題です。もちろん、あなたがCMDBを持っていなければ、チェックも何もないでしょう。

この「もちろん、あなたが・・・・を持っていなければチェックも何もないでしょう」というセリフはこれまで何度も目にしてきたと思います。しかし、このメッセージは見落とされがちです。Y2Kに費やされた財源の70パーセントは、資産とそれらのリレーションシップの追跡だけに費やされたと見積もられています。中心的で正確かつ完全なCMDBを持っていないなら、すぐに警戒を呼びかけるべきです。

> > 第 5 章 - リリース管理目標