• 主要なページ
• ITIL の本
• 著者について

サービスサポート評価指標

変更管理

第7章

問題管理と同様に、ITILは変更管理に対して2段階の監視レベルを提案しています。第1段階の管理報告は、問題管理と同様です。第2段階は少し異なります。ITILでは「ITサービス管理（PD0005）のための作業標準」というBSI出版物を相互参照しています。つまり、この第2段階レベルは、変更管理の詳細な報告に焦点を置いています。双方の段階でも以下の変更管理における最終目標を留意しておいてください。

変更管理プロセスの最終目標は、すべての変更を効率的かつ迅速に取り扱うために、標準化された方法、手順が使われる事を確実にすることと、それによって変更に起因するインシデントがサービス品質にあたえるインパクトを最小限にし、組織の日々の運用を改善させることである。

変更管理は、監視、測定、および評価指標のために膨大なデータ量を提供します。ITILは以下の主要な問題に焦点を置いています。

• 実装された変更の数。期間中、合計、変更アイテム（CI）毎、構成タイプ毎、サービス毎など。
• 変更理由の内訳 (ユーザ要求、拡張、業務要件、サービスコール／インシデント／問題の修正、手順／トレーニングの改善など)。
• 成功した変更の数。
• 切り戻された変更の数とその理由 (例えば、不正確な評価や構築不良)。
• 変更に起因するインシデントの数（問題の深刻さのレベル毎）とその理由 (例えば、不正確な評価、構築不良)。
• RFCの数 (と起源のトレンド)。
• 実装後、レビューされた変更の数、および（経過時間で分類された）レビューの未処理量。
• 1つのCIに関連したRFC／PRの高い発生率（これらは注目に値する）とその理由 (例えば、変わりやすいユーザ要求、故障しやすいコンポーネント、構築不良)。
• 前の期間（直前期間、前年度）の数字との比較。
• 却下されたRFCの数。
• 実装に失敗した変更の割合 (全体、CI毎に分類)。
• CI毎、および変更管理プロセスの段階毎に分類された未処理の変更。

ご覧の通り、推奨されているる管理報告は、含まれる範囲が非常に広範ですが、報告内容としては、変更内容の詳細ではなく、より高いレベルの測定に焦点を合わせています。これらの報告のポイントはそれぞれ、さらに検討する価値があります。

実装された変更の数。期間中、合計、変更アイテム（CI）毎、構成タイプ毎、サービス毎など。これは率直な数字であり、カテゴリに細分化された変更の総数を示しています。したがって、これは、変更のバロメータとはなりえません。なぜなら、変更の数とそのカテゴリは共にITと業務変更の両方に依存しているため、かなりい不安定なのです。ITILでは、いかなる構成アイテム（資産）へのいかなるステータスの変更も変更管理プロセスを経なければならないと推奨されているため、このレポートは構成（資産）管理のマネージャにとって重要です。どのカテゴリがあなたの組織に適用されるかを決めるわけですが、あまりに細かく細分化しないよう注意が必要です。細分化しすぎると、情報が得られるよりむしろ混乱を招くでしょう。

• ビジネス連携の指標 – 大概の変更管理レポートには業界が関心を示しますが、このレポートは、特にビジネスエリアに従って分類すれば、ビジネスマネージャが特に注目するでしょう。

変更内容の内訳 (ユーザ要求、拡張、業務要件、サービスコール／インシデント／問題の修正、手順／トレーニング改善など)。このレポートは有用なデータを提供します。しかも高いレベルでのデータです。ITILはこのレポートの期間については提案していませんが、直前期間の詳細レポートや、長い期間を網羅した累積レポートとして、例えば、過去12月間などのレポートとしてどんな傾向も強調することができます。

• ビジネス連携の指標 – このレポートは、変更の理由に興味をもつビジネスマネージャに提出されるべきでしょう。特に、自社が属する業界の要求でない変更理由には有用です。

成功した変更の数。ITILでは、何が「成功」を意味するのかを定義していませんが、結論としては、それがすべての「変更」がうまく導入されたことを意味することはあきらかです。しかし、うまく導入されたものの遅れてしまった変更、取り消された後に再導入された変更、または新たなインシデントを生成させなかった変更はどうでしょうか?このレポートを役立たせるには、まずあなたの組織にとって「成功した」変更とは何かを定義しなければなりません。定義することで、それぞれの成功した変更のタイプ別にこのレポートを分類することができるでしょう。この重要な変更管理という要素に対しては、1つの総合的な数だけを示すレポートはほとんど役に立ちません。

• ビジネス連携の指標 – これはビジネスマネージャにとって重要なレポートです。ビジネスマネージャには、「成功した変更」に関して、ITとは全く異なった視点があるかもしれません。ビジネスマネージャは、このレポートに添付する形で、あるいは可能ならばオンラインで、それぞれの成功した変更の概要を見たいと希望するかもしれません。このレポートでは、「成功した」変更に関して、彼らからの意見やコメントがあることを予期していてください。

切り戻された変更の数とその理由 (例えば、不正確な評価、構築不良)。ITIL用語では、「切り戻された」とは、変更が実行された後除去されオリジナルの状態に復旧されたことを意味します。変更が切り戻される理由としては、パフォーマンスが低い、新たなインシデントの発生があまりに多い、変更により別のコンポーネントがマイナスの影響を受けた、または変更が変更要求（RFC）で述べられている要件を満たさなかったなどさまざま考えられます。特に変更管理のためのITILの目標が、変更は組織の毎日の業務を改善させるべきものであると述べていることを考慮すると、これは非常に重要なレポートとなります。明らかに、切り戻された変更はこの必要条件を満たしていません。このレポートと共に、変更が取り消された理由、失敗を修正するために取られた措置、および将来同じあるいは同様の失敗を防ぐために行われたいかなる変更を含む、それぞれの切り戻された変更の説明を示してください。

• ビジネス連携の指標 – このレポートもビジネスマネージャにとって新たに重要なレポートです。ビジネスマネージャは、彼らのビジネスエリアに関連した切り戻された変更のひとつひとつに対し、説明を求めるでしょう。ビジネスマネージャの多くは、このレポートを使用して、切り戻される変更による業務環境に対するコスト、影響、および効果を判断します。ビジネスマネージャは、このレポートだけでなく、変更管理プロセスにより切り戻されなければならないどのような変更も決まり次第、それがすぐに通知されなければなりません。

変更に起因するインシデントの数（問題の深刻さのレベル毎）とその理由 (例えば、不正確な評価、構築不良)。これは、変更管理目標に直接関連するため、もう1つの重要な評価指標です。つまり、変更に関連したインシデントの影響を最小にするために重要となります。インシデントの大多数は失敗したあるいは切り戻された変更のためですが、これはすべてのインシデントに当てはまるわけではありません。また、成功した変更によりインシデントがもたらされる場合も多く見られます。例えば、変更はRFC単位ではうまくいくかもしれませんが、顧客は変更のいくつかの側面を理解せず、何らかのジャストインタイムトレーニングを必要とするかもしれません。これは、変更自体よりも変更プロセスの失敗です。

変更の結果、引き起こされたどんなインシデントも追跡し報告することが重要です。これは、インシデントと変更を管理するソフトウェアが、スピーディかつ容易にこの情報を追跡することができるように密に統合されなければならない、ということを意味します。また、変更に関連したインシデントが認識できるよう、サービスデスクスタッフのトレーニングが必要です。また、サービスデスクスタッフは、追跡目的のために変更参照番号を含む詳細を正しく記録しなければなりません。

このレポートは極めて重要です。また、同じあるいは同様のインシデントが将来発生するのを防ぐための知識を確実に得られるように、このレポートには確認されたインシデントの理由が含まれなければなりません。

• ビジネス連携の指標 – ビジネスマネージャあるいは彼らのスタッフはインシデントを認識しているため、おそらくビジネスマネージャの多くがこれらのインシデントを強く意識するでしょう。またビジネスマネージャは、このレポートを受けとるだけでなく、変更に関連したすべてのインシデントをいつでも、望ましくはオンラインで検討できなければなりません。

RFCの数 (と起源のトレンド)。RFCの数はシンプルで明白な評価指標です。難しいのは、「起源のトレンド」です。まずRFCの数は必ずしも実行される変更の数と等しいというわけではありません。例えば、拒否されるRFCもあるでしょうし、1つの変更に対し複数のRFCがあるかもしれません。つまり、RFCの数は常に、実行された変更の数より等しいか、それより大きくなるでしょう。このレポートの最初の部分では、RFCの数が述べられていなくてはなりません。さらに、「受理された」RFCと「拒否された」RFCに分割した総数を含む簡単な要約があるとなお良いでしょう。

トレンドを示さなければならない場合は、その組織に対する知識と関与で決定される領域に入ります。ITILは、どんなトレンドを探すべきかは断定していません。これは各組織で決定しなければなりません。通常、トレンドとしては、事業部門からのRFCの増加／減少、特定のソフトウェアに関するRFCまたは新技術を求めるRFCの増加／減少が含まれます。これらの傾向は、単に情報を収集して分析すれば見つけることができます。この分析から作成されるレポートはすべて、報告期間中のみとなります。

• ビジネス連携の指標 – RFCの実際の数はあまり関心を集めることはないでしょうが、トレンドはビジネスマネージャがもっとも注目するところです。

充分実装後、レビューされた変更の数、および（経過時間で分類された）レビューの未処理量。ITILは、「変更管理は、変更が効果的でないことによって変更管理のしくみそのものの中で生じた問題、または非効率性を修正するために、追跡を開始するべきである」と述べています。したがって、変更の再調査、記録の再調査、および未処理に関連するレポートの作成が重要です。例えば、大量の変更未処理は、変更管理がリソース不足であることを示唆していると考えられます。失敗の変更が多い場合は、変更の評価や変更の構築が満足に機能していないことを示しているのかもしれません。

また、変更記録を再調査すると、他のプロセスにおける問題が浮上する場合があります。再調査によって、問題管理が間違った根本原因を特定した、技術要素の信頼性が低い、または手続きそして／またはトレーニングが不充分であることが示されるかもしれません。このレポートは準備に時間がかかり、熟練した分析を必要としますが、それは変更管理の成功のためには重要です。また皮肉にも、このレポートの結果、変更管理改善のために追加のRFCが提起されることも充分考えられます。

• ビジネス連携の指標 – このレポートはビジネスマネージャにとって、特に彼らの手続きあるいはトレーニングがうまくいっていない場合に重要です。ビジネスマネージャのためにこのレポートを作成するときは、業界によって必要とされる改善エリアに必ず注意を向けてください。

1つのCIに関連したRFC／PRの高い発生率（これらは注目に値する）とその理由 (例えば変わりやすいユーザ要求、故障しやすいコンポーネント、構築不良)。この記述をより良く理解するために、かっこ内の情報を取り除き、「1つのCIに関連したRFC／PRの高い発生率とその理由」としてみます。こうすれば分かりやすくなるでしょう。RFCと問題記録の数を使用して構成アイテム（資産コンポーネント）の欠点を識別できるようにしてください。

CIの欠点をより早く識別することができれば、より迅速にそれらを解決することができ、結果として顧客サービスを向上させることができるため、不可欠のレポートです。このレポートを作成するには、構成（資産）データベースに対し、問題データベースと変更データベースを照合してください。そのためには、問題、変更、および構成の互換性のあるデータベース (または1つの統合型データベース)、そして必要なアウトプットが得られる報告書作成ルーチンが必要です。時間がかかる作業ですが、このレポートはすべてのITマネージャが必ず読まなければならないものなのです。

• ビジネス連携の指標 – これはすべてのビジネスマネージャにとって重要なもう1つのレポートです。このレポートの内容について、ビジネスマネージャと議論しなければなりません (彼らに送るだけでは駄目です)。ビジネスマネージャは、RFCとPRが高発生率である理由について更なる洞察を重ねるかもしれません。

前の期間（直前期間、前年度）の数字との比較。これは、別個のレポートとしてではなく、上記の管理レポートそれぞれの必須成分となるべきものです。

• ビジネス連携の指標 – ビジネスマネージャと共同して、このレポートに

されたRFCの数。これは簡単なレポートであり、RFCが却下された理由の内訳を含めればより良くなるでしょう。コントロールの欠如、能力不足、またはRFCの内容を理解していないなどのさまざまな理由のため、組織があまりに多くのRFCを提起することがあります。RFC却下のための基準が特定され発表されなければなりません。

• ビジネス連携の指標 – ビジネスマネージャは、却下されたRFCの内訳と共にこのレポートを手に入れなければなりません。却下されたRFCのほとんどが業界で起こり得るため、このレポートは、ビジネスマネージャが不要なRFCの数を減少させるために手続きとプロセスを改良する際の助けとなるでしょう。

実装に失敗した変更の割合 (全体、CI毎に分類)。以前、取り消された変更に関する同様のレポートについて説明しましたが、それとちょうど同じ原則をここに適用することができます。1つの重要な違いがあります。失敗した変更のすべてが取り消されるというわけではないということです。失敗した変更は切り戻すのが非常に難しく、次善策あるいは回避措置が取られることがあります。 それでも、レポートの本質と構造は同様であるべきです。

• ビジネス連携の指標 – このレポートはビジネスマネージャに配付されなければなりません (このセクションの初めのほうで述べた「切り戻しレポート」の概要を参照してください)。

CI毎、および変更管理プロセスの段階毎に分類された未処理の変更。 未処理の変更に関する同様のレポートに関しては、以前説明しました。ただし、そのレポートで扱ったのは総計だけでしたが、このレポートでは未処理の変更の内訳が必要です。それぞれの組織によってカテゴリをカスタマイズすることができます。ただ、このレポートの主要な目的が、未処理の原因となるボトルネックを明らかにし、排除することであることに留意してください。未処理の変更の排除は重要ですので、このレポートはすべてのITマネージャに出すべきです。

• ビジネス連携の指標 – これは、どの未処理部分が変更を遅らせている原因なのか知りたいビジネスマネージャに絶対必要なもう1つのレポートです。さらに、ビジネスマネージャが要求された変更のどれかが目標期限を逃がすような場合は、すぐにビジネスマネージャに通知しなければなりません。

これらの管理レポートは、変更管理問題を幅広くカバーしています。IT変更を管理できないと混乱が発生する可能性があり、また実際に発生するため、これらのレポートは重要となります。このセクションの始まりで、ITILは「ITサービス管理（PD0005）のための作業標準」というタイトルのBSI出版物を相互参照していると述べました。以下の項目は、この作業標準が推奨しているものです。

• 変更要求の数。
• 却下されたRFCの数と％。
• 非常時の変更。
• 変更におけるステータス。
• 実装を待つ変更の数。
  • カテゴリ毎
  • 未解決の時間毎
• 実装された変更の数。
  • 構成コンポーネント毎
  • サービス毎
• 未処理の変更とボトルネック。
• ■ 変更毎のコストとコストの概要。
• 変更の事業へのインパクト。
• 事業領域毎の変更。
• CIへの変更の頻度。

これらの項目の大部分は、既に議論した管理レポートでカバーされています。重要な例外は以下のとおりです。

• 非常時の変更。
• 変更毎のコストとコストの概要。
• 変更の事業へのインパクト。

以下、これらの例外について説明します。

非常時の変更。非常時の変更が多いということは、変更管理プロセスが適切に機能していない、またはあるサポートグループでは飛ばされているということを明確に示しています。非常時の変更は、インシデントの間に顧客の機能を復活させる唯一の方法が、変更の実行による根本原因の排除である時などの特殊事情に備えて用意されていなければなりません。非常時の変更は、変更作成者が以前に要求された変更に取り組むのを忘れていたなどの落ち度を原因として開始されるべきではありません。このレポートには、サポートグループあたりの数、事業部門あたりの数、そして／またはCIあたりの数などのカテゴリへ細分化した、非常時の（緊急の）変更の全般的な総計が記されているべきです。また、非常時の（緊急の）変更の理由がレポートに含まれていなくてはなりません。

• ビジネス連携の指標 – 非常時の変更は、事業部門に直接的な影響を持つので、ビジネスマネージャにこのレポートを出すべきです。事業部門があまりに多くの非常時変更を請求している場合は、どうすればより効率的にこれらの非常時変更を計画することができるかを話し合うためのミーティングのスケジュールを立ててください。

変更毎のコストとコストの概要。財務上の内訳は、組織の特徴と本質に依存します。例えば、割戻しがある組織は、割戻しがない組織よりもさらに詳細なものを要求するでしょう。しかし、割戻しのあるなしにかかわらず、あらゆる組織が変更のコストを知り、それを発表するべきです。このレポートはすべてのITマネージャに提出されなければなりません。進行中の変更に対する変更記録には、それぞれの変更のこれまでのコストを示すコストの現在高が含まれなくてはなりません。

• ビジネス連携の指標 – ビジネスマネージャは、自ら要求した変更あるいは自らのビジネスエリアに影響する変更のコストはすべて配付確認したいと望むでしょう。また、割戻しはこれらのレポートの内容に影響を及ぼします。これらのレポートは、ビジネスマネージャが自ら要求した変更あるいは自らの事業領域エリアに影響を及ぼす変更のコストを見ることができるよう、配付されなければなりません。

変更の事業へのインパクト。多くの場合、変更がビジネスに与える影響は、その変更の性質と緊急性に依存してそれぞれ異なります。その結果、これはレポートとして作成されませんが、この情報は変更管理プロセスにおけるあらゆる変更タイプに対して変更記録が開かれるときはいつも利用できるようにするべきです。

• ビジネス連携の指標 – このレポートは、一見した時よりもビジネスマネージャにとって重要です。ビジネスへの影響あるいは緊急性は、さまざまな理由により、変更のライフサイクルの間修正される場合があります。それが、ビジネスマネージャがすべての変更の事業へのインパクトを見直すことが重要である理由です。

前述したように、変更管理には膨大な数の測定と監視が必要となることがあります。変更管理の別のITIL目標を見てみましょう。

変更管理プロセスは、変更が発生した時、円滑な移行を促進するために、高い可視性とオープンな情報伝達経路を持つことが重要である。

キーワードは、「高い可視性とオープンな情報伝達経路を持つ」です。このフレーズは、これらのレポートがとても重要であることと、ビジネス連携の優先度が高くなるべきである理由を強調しています。変更管理は、ビジネスとITの統合が成功するための土台です。したがって、上記で説明したすべてのレポートが重要なのです。

> > 第8章 - リリース管理