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

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

リリース管理

第8章

リリース管理はITILの重要な構成要素であり、ITIL出版物改訂版の最新号において抜本的な見直しを行いました。これまでのリリース管理はIT環境へのソフトウェアリリースの管理に関わるものでしたが、現在では、サービスサポートブックのリリース管理の章で示されるているように、リリース管理が適用される範囲は遥かに拡大しています。

配付分散型IT環境においては、様々なサービス・プロバイダやサプライヤがハードウェアやソフトウェアのリリースに関与している。充分なリリース計画立案と管理は、顧客へのリリースを首尾よくパッケージ化し、配付するために重要である。リリース管理は、ITサービスにおける変更を包括的に見渡し、リリースに関するあらゆる面、すなわち技術と技術意外の視点双方を一緒に健闘することを保証するべきである。 (9.1 リリース管理の目標)

「リリース」は、ITサービスに対する認可された変更の集合を表す言葉である。リリースは、それを実装する変更要求（RFC）に基づいて定義される。通常、リリースは複数の問題修正や、サービス拡張から成り立つ。リリースは、許可された変更を実装するために必要な、新しいもしくは変更されたソフトウェアと、新しいもしくは変更されたハードウェアが含まれている。 (9.3.1.リリース)

リリース管理は、今やITILの重要な構成要素となっています。他のITILプロセスと同様、リリース管理には、重要業績評価指標（KPI）の監視と管理報告の2つのタイプの評価指標があります。まず、ITILによって概略が説明されているKPIについて議論していきます。

• スケジュール通りで、かつ予算化されたリソース内で構築、実装されたリリース (しかし、アプリケーション開発の遅れのような、リリース管理のコントロール外もしくは責任外にあるあらゆる問題を分離するように注意するべきである)。
• 容認できないエラーにより切り戻される必要があるリリースの非常に低い発生率 (理想的には発生しない)。(しかしながら、ソフトウェアのリリースは完全にエラーをなくすことまでは要求しない。小規模で、耐障害性の許容範囲内であれば、エラーが存在していてもリリースを先に勧めるという判断も可能である。6章の問題管理を参照)。
• 構築失敗の低い発生率。
• 安全で正確なDSL (Definitive Software Library) の管理。
• 配付充分配付
• DSL内において、品質チェックに合格していないソフトウェアの形跡がないことや、DSLから出されたあらゆるソフトウェアに対し改訂の形跡が無いこと。
• 容量の需要にあったDSLの規模設定、およびタイムリーで正確なDSLの管理。
• 購入されたソフトウェアに関連するすべての法的規制への鎮守。
• 全ての遠隔地に対するリリースの正確な配付。
• 遠隔地を含む、全てのサイトでの予定通りのリリースの実装。
• あらゆるサイトにおいて以前のバージョンへのみ許可の復元の形跡が無いこと。
• あらゆるサイトにおいて未許可のソフトウェアの利用の形跡が無いこと。
• あらゆる特定の場所において、実際には使用されていないソフトウェアに対するライセンス料の支払い、あるいは無駄な保守工数の形跡が無いこと。
• リリースの構築における無駄な重複（例えば、一つの構築コピーで充分な場合の、遠隔地での複数の構築等）の形跡が無いこと。
• 全ての構築、配付、実装活動の正確でタイムリーなCMDB（構成管理データベース）への記録。
• 全てのリリース活動に対して実装後の分析が行われ、全ての必要な是正処置、もしくはフォロー・アップの処置が、あらゆるプロセス改善と合わせて実施されていること。
• 実際の構成に一致している計画されたリリースの構成 (このことは、優れたリリース計画立案を明示している。)
• リリース管理に要求されるITリソースと人的リソースが、現在の有効な将来計画に従っていること。

予想された通り、これらのKPIの一部には変更管理に見られる評価指標と同様の評価指標が含まれています。リリース管理と変更管理は密接に関係しているため、これは必然的です。しかしお分かりのように、いくつかの重要な相違点があります。

スケジュール通りで、かつ予算化されたリソース内で構築、実装されたリリース (しかし、アプリケーション開発の遅れのような、リリース管理のコントロール外もしくは責任外にあるあらゆる問題を分離するように注意するべきである)。このKPIを実行可能にするためには、「前月までの、予算内のリソースで、スケジュールどおりに構築・実行されたリリースの数」にまで記述内容を拡張しなければなりません。

元来の記述内容には、KPIが適用される期間が記載されていません。「暦月」は、測定される期間を特定しなければならないことを示しているに過ぎません。また、正確を期し混乱を抑えるために、「リリース管理のコントロールまたは責任が及ばない」ことの明確な定義付けがなければなりません。

事実上、このKPIは、所定の期間にリリースがうまく行われているかを迅速に確かめるためのチェックリストとなります。このように重要なKPIですが、レポートは各リリースについて1行に充分おさえるべきです。通常、レポートにはリリースの予定日時、リリースが実際に行われた日時、リリースの照会番号、リリースの所有者、およびコントロールが及ばない場合のコメントが含まれます。このレポートを充分有効活用するには、不具合が生じたリリースに関する以下のレポートと比較してください。このKPIの成功率は、高ければ高いほど理想的です。

• ビジネス連携の指標 – これは多くのビジネスマネージャ、特に所定の期間にリリースを受けるビジネスマネージャにとって不可欠のレポートです。リリース管理のコントロールまたは責任が及ばないと考えられるリリースから生じるいかなる問題についても、ビジネスマネージャと議論するよう備えてください。

容認できないエラーにより切り戻される必要があるリリースの非常に低い発生率 (理想的には発生しない)。(しかしながら、ソフトウェアのリリースは完全にエラーをなくすことまでは要求しない。小規模で、耐障害性の許容範囲であれば、エラーが存在していてもリリースを先に勧めるという判断も可能である)。前述のように、このKPIは前のKPIと併せて評価に用いられます。このKPIがより低く、前のKPIがより高いと、総合的なパフォーマンスは向上します。既知のエラー（対策を講じていて根本原因が特定されているエラー）と、不測のインシデントを発生させるエラー（重度の大小に関わらず）を区別するようにしてください。不測のインシデントを発生させるエラーは、問題管理プロセスを経なければなりません。容認できないエラーによって起きた不具合について常に分析を行い、それぞれの不具合のレポートを作成し、将来のリリースにおいて同じエラーが決して繰り返されないために講じた対策について説明してください。

• ビジネス連携の指標 – このKPIが発行される前に、すべての不具合が生じたリリースのステータスが既に確認され検討されているかもしれません。そうであったとしても、このレポートは、不測のエラーがビジネスに与える影響に関する詳細を提供できるビジネスマネージャと知識を共有するための重要なレポートです。 このレポートは、責任分担のために使用するためのものではなく、むしろより良い未来を確立するための手段であると考えることが重要です。

構築失敗の低い発生率。このKPIを測定する前に、「低い」の目標値を決定する必要があります。それはゼロですか? 100分の1未満ですか? 理想的なKPI目標はゼロですが、どのようなKPIを設定したとしても、構築失敗はすべて完全に調査しなければなりません。またここでは、「不測のエラー」を扱った前のKPIに記載された基準の大部分が適用されます。

• ビジネス連携の指標 – また、「不測のエラー」に関する前のKPIに対する議論がここにも適用されます。

安全で正確なDSL (Definitive Software Library) の確実管理。このKPIは私たちが以前に議論したものとは完全に異なります。この指標はベースラインデータのみから得られるものではなく、DSLの調査、レビュー、および監査を必要とします。事実、DSL内のソフトウェアリリースとインフラ機器にインストールされたソフトウェアを監査、レビュー、および比較をするだけで、DSLのの正確な管理を確実に行うことができます。

セキュリティを見直すことはもっと困難です。それでもなお、DSLへのすべてのアクセスはパスワードで管理されなければなりません。したがって、最初に行うべきことはパスワードトラフィックのレビューです。セキュリティのレビューは、ITアナリストが行うよりも、独立したセキュリティアナリストが行う方が良いでしょう。一般的に、このレビューはIT管理の依頼に基づいて不定期的に行われます。セキュリティに問題あるいは不正確な点が発見された場合は、リリース管理からそれらの弱点を取り除き、再発を防ぐための処置を即座に取らなければなりません。

• ビジネス連携の指標 –これはDSLに対する業界の関与に完全に依存します。ビジネスマネージャがDSLのいずれかのソフトウェアを「所有している」場合は、例外なく彼らをレビューに参加させてください。また、ソフトウェアのバージョン番号を確認するためにビジネスマネージャを訪問しなければならない時は、ビジネスマネージャに必ず相談してください。

DSL内において、品質チェックに合格していないソフトウェアの形跡が無いことや、DSKから出されたあらゆるソフトウェアに対し改訂の形跡が無いこと。前のKPIと同様、ベースラインデータからこの評価を得ることはできません。DSLの調査、レビュー、および監査が必要です。DSL内のソフトウェアリリースとインフラ機器にインストールされたソフトウェアを監査、レビュー、および比較をするだけで、品質と完全性を証明することができます。 監査レビューは、DSLの管理者が行うよりも、独立したアナリストが行う方が良いでしょう。一般的にこのレビューは、IT管理の依頼に基づいて不定期的に行われます。品質あるいは完全性に対して問題が発見された場合は、リリース管理からそれらの弱点を取り除き、すぐに再発防止策を講じなければなりません。

• ビジネス連携の指標 – これも、DSLに対する業界の関与に完全に依存します。ビジネスマネージャがDSLのいずれかのソフトウェアを「所有している」場合は、例外なく彼らをレビューに参加させてください。また、ソフトウェアのバージョン番号を確認するためにビジネスマネージャを訪問しなければならない時は、ビジネスマネージャに必ず相談してください。

充分容量の需要にあったDSLの規模設定、およびタイムリーで正確なDSLの管理。この重要なKPIは、ITILプロセス「キャパシティ管理」の見解とサポートに依存しています。現行のソフトウェアのアップグレードのため、ならびに新たに計画されたソフトウェアの追加のために必要なスペースに現在のデータベースのサイズを加算して、DSLのスペース要求を測定してください。その後、DSLが利用可能なスペースの量と比較します。新しいソフトウェアのためのスペースが充分に確保されていないような場合は、DSLのスペースを増やすか、またはDSLから古い／使用していないソフトウェアを取り除いてください。スペース不足のためにソフトウェアの追加ができないと、このKPIを満たすことができません。

DSLは適時的かつ正確な整理を定期的に行うべきであり、すべての行動はトランザクションログに記録されなければなりません。このKPIは、トランザクションログと同様にDSLの監査にかかわります。整理が行われなかったり不正確であった形跡がある場合は、このKPIを満たしていないということです。適時性あるいは正確性に関する問題の形跡がある場合、すぐにリリース管理からそれらの弱点を取り除き、すぐに再発防止策を講じなければなりません。

• ビジネス連携の指標 – これも、DSLに対する業界の関与に依存します。ビジネスマネージャがDSLのいずれかのソフトウェアを「所有している」場合は、例外なく彼らをレビューに参加させてください。また、ソフトウェアのバージョン番号を確認するためにビジネスマネージャを訪問しなければならない時は、ビジネスマネージャに必ず相談してください。

購入されたソフトウェアに関連する全ての法的規制への鎮守。これは極めて重要なKPIです。これが満たされないと、会社は訴訟問題に直面するかもしれません。通常、このKPIはソフトウェアのライセンス制限、更新、および有効期限に関係しています。 すべてのソフトウェアの契約事項をリストアップし、すべての法的要件を確実に満たすように検査を行い、無違反を実行しなければなりません。既存ソフトウェアに新規ユーザを追加する際、あるいは既存ソフトウェアのアップグレードを行う際には、特に注意を払うことが必要です。

• ビジネス連携の指標 – 特に、(恐らく気付かずに) 規則を破っている者がビジネスマネージャであることのないように、法的規制についてビジネスマネージャが熟知することを徹底させてください。例えば、ビジネスマネージャがあるソフトウェア製品について10台のワークステーションで使用するライセンス料支払い契約を結んだにもかかわらず、恒常的に10人以上が同時にそのソフトウェアを使用するということのないようにしてください。このような状況があった場合は、ソフトウェアが違法に使用されていることをビジネスマネージャに知らせるべきです。また、契約管理部門や購買部門など、非IT部門との折衝を行わなければならない場合もあります。

配付配付配付全ての遠隔地に対するリリースの正確な配付。監査によりこのKPIを測定することができます。より一般的には、インシデントと問題の両方のデータベースに対して定期的なレビューを行うことで、不正確なソフトウェア配付の形跡を見つけます。また、変更管理におけるRFCも参照してください。不正確なソフトウェアリリースを原因として変更を求めているRFCも見られます。例えば、ユーザが、既にインストールされている筈のアップグレードあるいは機能を求めている場合などです。リリースの配付が不正確である形跡がある場合は、このKPIを満たしていません。

• ビジネス連携の指標 – ビジネスマネージャの中には、彼らの部門にインストールされるべきソフトウェア（バージョン／リリースのレベル）を熟知していない者があります。ビジネスマネージャがソフトウェアリリースプロセスの一環として充分な知識を持つよう徹底してください。

遠隔地を含む、全てのサイトでの予定通りのリリースの実装。リリースは定刻通り行われるか遅れるかのどちらかしかないので、このKPIを監視するのは簡単です。リリースが遅れるということは、このKPIを満たしていない証拠です。しかし、リリースが遅れた理由を特定し、同じ理由による将来のリリースの遅延を防ぐための対策をとらなければなりません。「遅延リリース」レポート（月次などの）を定期的に発行して、すべてのITマネージャにレビューとコメントを求めるようにするべきです。

• ビジネス連携の指標 – ビジネスマネージャは「遅延リリース」レポートの入手を望むでしょう。またリリースが遅延しているときにはそれを通知してくるでしょうから、すべてのリリースの進捗状況に関して彼らに最新情報を提供してください。

あらゆるサイトにおいて、以前のバージョンへの未許可の復元の形跡が無いこと。このKPIは監査とレビューを必要とします。「検索」ユーティリティを使用することで復帰されたソフトウェアを検出できるかもしれません。あるいは、インシデントまたは問題のデータベースをレビューする際に発見することもあります。ユーザがソフトウェアリリースの復帰のために変更を要求したかどうかを確認するために、変更管理のRFCを見直す必要もあります。例えば、ユーザが、既にインストールされている筈のアップグレードあるいは機能を求めている場合などです。どのような形であれ無許可の復帰の形跡がある場合は、このKPIを満たしていないということです。

• ビジネス連携の指標 – ビジネスマネージャの担当エリアで違反が発生した場合は、彼らと相談してください。また、発見された違反をセキュリティ担当責任者あるいはセキュリティ部門に報告する必要もあるかもしれません。

あらゆるサイトにおいて、未許可のソフトウェアの利用の形跡が無いこと。このKPIも監査とレビューを必要とします。まず、「無許可のソフトウェア」とは何か、そしてそれを使用・実行するとどのような処罰が課されるのかを明確にしておかなくてはなりません。そして、すべてのITマネージャとビジネスマネージャが「無許可のソフトウェア」の定義とそれにかかわるペナルティを完全に理解していることを徹底させてください。「検索」ユーティリティを使用することにより、あるいはインシデントデータベースまたは問題データベースのレビューを行うことにより、無許可のソフトウェアを検出することができる場合があります。無許可のソフトウェアを使用した形跡がある場合は、このKPIを満たしていません。

• ビジネス連携の指標 – 無許可のソフトウェアがビジネスマネージャの担当エリアで使用されていることが判明した場合は、彼らと話し合う必要があります。無許可のソフトウェアを使用していると、他のソフトウェアの新しいリリースをインストールする際に重大な問題を引き起こす場合があります。より重要なことは、無許可のソフトウェアは、ウイルス感染や他のコンピュータソフトウェアの権利侵害の原因となる恐れがあるということです。したがって、無許可のソフトウェアの使用は、セキュリティ部門あるいは監査役に報告する必要があります。

あらゆる特定の場所において、実際には使用されていないソフトウェアに対するライセンス料の支払い、あるいは無駄な保守工数の形跡が無いこと。このKPIは、「適切な整理」と考えることができます。どのソフトウェアがどのロケーションで使用されているかを判断するために、定期的に監査を行うことを計画してください。これは、ソフトウェアが使用されているかどうかではなく、ソフトウェアを使用するためにどれだけのライセンス契約が必要であるのかを判断することを意味します。

例として、40人の職員がいる部門で、すべてのワークステーションに職員数と同数のソフトウェアライセンス契約が結ばれていましたが、部門の方針変更に伴いライセンス契約を結んだソフトウェアを実際に使用するのは10人だけになった場合、が挙げられます。 もはや使用されないソフトウェアのライセンス数を減らし、ソフトウェアをワークステーションから削除することによって、そのライセンスと保守にかかるコストを減少させることができます。

使用されていないソフトウェアは、ソフトウェア管理ユーティリティによって検出したり、インシデントまたは問題のデータベースをレビューすることで発見できることがあります。上述の例のように環境に変化が起きる場合があるため、このKPIは他のものと多少異なります。

• ビジネス連携の指標 –ソフトウェアの使用（または非使用）の判断支援技術を用いることができますが、それでもビジネスマネージャはライセンスの数の削減に同意しなければなりません。したがって、ライセンスが使用されていないことを見つけた場合は、ライセンスの数を減らす前に常に担当ビジネスマネージャと相談してください。また、ビジネスマネージャに対して、スタッフによって使用されるソフトウェアライセンスについて年間ベースで見直しを行い、ライセンスのすべてが必要であるのかどうかを判断するように依頼してください。

リリースの構築における無駄な重複（例えば、１つの構築コピーで充分な場合の、遠隔地での複数の構築等）の形跡が無いこと。無駄な複製を特定して報告するためにはリリースに取り組むITスタッフの手を借りる必要があるため、これは測定するのが比較的難しいKPIの1つです。時には、リリースがインストールされるまで複製の証拠が明らかにならないことがあります。将来のリリースがより効率的に行えるように、どのような複製でも報告するようにスタッフを奨励してください。また、リリースが予期された以上の時間を要したり、予期した以上の実施コストがかかる時は、無駄な複製の存在を示唆している場合があります。

定期的な監査やレビューはこの場合必要ではありませんが、無駄な複製の特定はリリースの完了後のリリース評価の一部であるべきです。無駄な複製が特定された場合は、再発を防止するためにリリース管理プロセスの改善を目指した処置を取るべきです。無駄な複製があることは、このKPIを満たしていないことを意味します。

• ビジネス連携の指標 – エンドユーザがリリース期間に関与する機会が多ければ多いほど、複製の存在に気付いて貰う可能性が高くなります。エンドユーザとビジネスマネージャの両者とも、無駄な複製を特定し報告することで会社に貢献することができます。例えば、エンドユーザとビジネスマネージャは、同じことをすることを何度も頼まれていることに気付くかもしれません。いかなる場合でも、リリースの構築において複製を見つけた場合はビジネスマネージャに通知してください。

配付全ての構築、配付、実装活動の正確でタイムリーなCMDBへの記録。まず、「正確性」と「適時性」についての定義付けと説明とが必要です。それがなければ、このKPIを測定することはできません。それから後に、不具合を特定する方法を決定してください。「正確性」に関して言えば、構成管理チームはCMDBを監査することに対して責任があり、リリース管理により生じたエラーに起因するCMDBのすべての不正確性を報告しなければなりません。「適時性」の測定はさらに困難です。適時性は、リリースにより変更された後のCMDBのアイテムを更新するのにかかる時間に関わります。CMDBの監査によって適時性に不具合があるかどうかが分かります。その他の適時性の不具合は、問題またはインシデントのデータベースをレビューすることによって、あるいはサービスデスクから、発見される場合があります。例えば、サービスデスクはインシデントを扱っているけれども、CMDBは顧客のロケーションにおける実際と構成に一致しない場合、リリース管理が適時的にCMDBの更新を行っていなかったことが原因です。

ITILは、正確なCMDBがITサービス管理の重要な要素であると述べています。このKPIを達成していないのは重大な問題であり、正確なCMDBを維持するために処置を取らなければなりません。

• ビジネス連携の指標 – CMDBの不正確性の情報を、特に財務部門、契約管理部門、および購買部門のビジネスマネージャなど、CMDBを使用するビジネスマネージャに知らせてください。また、CMDBを使用していないビジネスマネージャに対しても、不正確性の情報を知らせなければならない場合があります。間違った優先順位をインシデントに割り当てた場合など、不正確あるいは情報の古いCMDBに起因した不充分なサービスによって、彼らが影響を受ける可能性があるためです。ビジネスマネージャと相談して、CMDBの不正確性に関するフィードバックを必要とする人を判断してください。

全てのリリース活動に対して実装後の分析が行われ、全ての必要な是正処置、もしくはフォロー・アップの処置が、あらゆるプロセス改善と合わせて実施されていること。このKPIはあまり明確ではありません。事後分析が実行されるということでしょうか? あるいはすべての事後分析の結果がリリース問題を全く示さないということでしょうか? 確かに、事後分析はあらゆるリリースに対して実行されるべきです。それが不可能な場合は、最低限、問題または不具合のあったすべてのリリースに対して事後分析を行ってください。事後分析のレポートがなければ、KPIは達成されていないことを意味します。また、プロセスの改善と同時に、すべての必要な修正およびフォローアップが実行されていることを確認するチェックを行ってください。チェックを行っていないことは、KPIが達成されていないことを意味します。また、事後分析によって、このセクションで説明された他の多くのKPIに関するデータが得られます。

• ビジネス連携の指標 – ビジネスマネージャはすべての事後分析の結果を見る必要はありません。しかし、ビジネスマネージャに、自身のビジネスエリアにインストールされるリリースに関連した問題を示す事後分析のコピーを送付してください。

実際の構成に一致している計画されたリリースの構成 (このことは、優れたリリース計画立案を明示している)。理想的には、リリースに計画された構成が実際の構成に完全に一致するほど、徹底された計画であるべきです。想定外の状況が生じることもありますが、計画の改善方法はこれらの変則的事象から得られるのです。計画改善のための戦略の実行方法については言及していませんが、これが重要なKPIである理由です。すべてのリリースの完了時に、計画された構成が実際のリリース構成に一致しているかどうかを確認してください。これは、事後分析の一部として調査することができます。計画されたリリース構成が実際の構成に一致しない場合は、このKPIを満たしていません。

• ビジネス連携の指標 – ビジネスマネージャが変更諮問委員会（Change Advisory Board、CAB）のメンバーである場合、特に不一致が報告された時には、彼らはこのKPIに関心を持つでしょう。また、自分の担当エリアで計画された構成とは異なる構成が見られたビジネスマネージャなら皆注目するでしょう。

リリース管理に要求されるITリソースと人的リソースが、現在の有効な将来計画にしたがっていること。これは別の「計画」KPIであり、リリース管理の間に必要とされるすべてのリソースが適所にあることを保証することを目的としています。「優れた」目標に対してKPIを測定するのは困難であるため、例えばリソース不足のため遅延するリリースは5パーセント以下というような、客観的な目標を立てたいと思われるかもしれません。どのような目標を立てたとしても、それを達成できないということは、KPIが達成されない可能性があることを意味します。

計画段階での過大評価は、過小評価と同じくらい有害なものとなり得ることを覚えておいてください。例えば、あるタスクに100時間の労働時間が必要と見積もったものの、実際には25時間しかかからなかったら、それ以外に必要とされていたスタッフの作業負荷を無にしてしまうことになります。あらゆるリリースの終了時点で計画を評価し、実際に使用されたリソースに対して計画されたリソースを見直してください。リリース遅延の一般的な理由が不完全なリソース計画であることを考えると、これは重要なKPIです。リリース計画が将来確実に向上するようなすべての処置だけでなく、いかなるリソース不足についても完全に説明しなければなりません。

• ビジネス連携の指標 – ビジネスマネージャは、通常、不適切なリソース計画がリリースの実施を延期させる場合について検討しますが、リリースの実施を速くする計画について検討することはありません。多くのビジネスマネージャは、リソース計画について熟知しているのですから、多くの質問に対応する心構えをしておいてください。また、予定より早く終了したプロジェクトに関して、疑問を持つようにしてください。例えば、新しい高速道路が予定より9ヵ月も早く開通した場合、まず、「素晴らしい計画だ」と感じるでしょうか、それとも「道路工事業者にだまされたのか？」と感じるでしょうか。どのようなケースであっても、リソースで起きたすべての矛盾点の詳細をビジネスマネージャに報告しなければなりません。

これらのKPIから、監査と事後分析という2つの課題が提起されます。どちらも、リリース管理において継続的に向上し続けることを確実にする上で大変重要な業務です。しかし、これらを実施する際には注意が必要です。もし監査および事後分析をスタッフ並びに彼らの行動に対して適用してしまうと、これらのツールは彼らの効率性を急速に損なわせてしまうことになるでしょう。最後の1点として付け加えるなら、この場合の「監査」とは、正確性と適時性について監督することであり、ビジネスや法的監査を実行することではありません (ライセンス管理では、この限りではありません)。

配付それでは、管理情報評価指標に移りましょう。これらは主に、リリース管理の全体的なパフォーマンスに関わります。以下は、ITILで推奨される管理情報です。

• 報告期間内における大規模および小規模のリリースの数。
• 新しいリリースに起因する可能性がある稼働環境内の問題の数。これは、新しいリリースの運用期間の最初の数ヶ月間だけを測定し、根本原因によって分類される必要がある（例えば、「ファイルのバージョンの誤り」や「ファイルの紛失」等）
• 新しいリリースで実装された新規、変更および削除されたオブジェクト数。例えば、モジュールやプログラム数
• 合意した期間内に完了したリリースの数。これには、ソフトウェアの配付や他の共通のタスクに対して事前に定義された目標値「サービスレベルすなわちSLA」を、中央のリリース管理機能が公表する必要がある。

KPIの巨大な数値を見た後では、管理報告のほんの僅かな評価指標を見ても驚くことはないでしょう。

リースの数。残念ながらこの評価指標は、結局何を報告するべきかについてあまり明確ではありません。その期間に完了したリリースですか? その期間に開始したリリースですか? 構築中のリリースですか? あるいは、これらすべてですか?定期レポートにこれらすべてが記されていることが理想的です。配付レポートは、完了、開始、そして進行中（構築中）のステータスによって、3つのセクションに分割することができます。さらに各セクションを、メジャーとマイナーの2つのサブセクションに分割することができます。このレポートにより、すべてのITマネージャが彼ら自身あるいは彼らのスタッフにかかわるすべてのリリースを追跡することが可能となるため、ITマネージャ全員にこのレポートを配付するべきです。

• ビジネス連携の指標 – すべてのビジネスマネージャが彼らのビジネスエリアに影響するリリースを追跡することができるため、このレポートはビジネスマネージャ全員にとって重要です。このレポートを配付すれば、ビジネスマネージャからのリリースのステータスに関する質問の数が減少するでしょう。リリースが遅延しているすべてのビジネスマネージャから質問されることを想定していてください。

配付新しいリリースに起因する可能性がある稼働環境内の問題の数。これは、新しいリリースの運用期間の最初の数ヶ月間だけを測定し、根本原因によって分類される必要がある (例えば、「ファイルのバージョンの誤り」や「ファイルの紛失」等)。これは明確な評価指標であり、さらに拡張して、ユーザによって報告される新リリースに起因した新たなインシデントのすべてに対しても適用することができます。新しい問題もインシデントもないのが理想です。しかし実際は、有効に行われているリリースにおいてでさえ、問題やインシデントが起こることがあります。理想に近づくための唯一の方法は、新たな問題とインシデントをすべて調査し、それらが将来のリリースで再発するのを防ぐために適切な処置をとることです。この評価指標は、問題の分類として「根本原因」を挙げています。同様に、インシデントに「カテゴリ」を適用することができます。問題とインシデントはすべて、リリースの照会番号を使用するなどにより、それらが適用されるリリースと相互参照されるべきです。最終的には、挙げられた問題とインシデントそれぞれに対し、将来のリリースにおける問題とインシデントの再発を防ぐための修正処置がなければなりません。このレポートは定期的に編集し、すべてのITマネージャに配付するべきです。

• ビジネス連携の指標 – これはすべてのビジネスマネージャにとって不可欠のレポートです。彼らはリリースの結果生じた問題あるいはインシデントのすべての情報を望んでいます。結局は、ビジネスマネージャが最終的な失敗によって影響を受けてしまうということです。また彼らは、同じ問題やインシデントが将来生じるのを防ぐために取られるいかなる修正処置にも注目するでしょう。

新しいリリースで実装された新規、変更および削除されたオブジェクト数。例えば、モジュールやプログラム数。この評価指標は単に、一連の段階的カテゴリで細分化した量的指数です。新規のオブジェクト、あるいは変更または削除されたオブジェクトの数量からは影響や作業負荷に関するデータは全く得られないため、それらの数量はそれほど有効ではありません。しかし、この評価指標をKPIや他の管理情報と併用すれば、すべての期間における作業量が示されます。オブジェクトとその数量のリストを提供すると良いでしょう。 このレポートはすべてのITマネージャに配付してください。

• ビジネス連携の指標 – ほとんどのビジネスマネージャはこのレポートに関心を持たないでしょうが、事業開発、契約、購買、および変更諮問委員会（CAB）に属するビジネスマネージャなど、ある専門的ビジネスマネージャはいくらか注目するでしょう。このレポートのコピーを必要とするビジネスマネージャを特定してから、それに基づいてレポートを配付してください。

配付合意した期間内に完了したリリースの数。これには、ソフトウェアの配付や他の共通のタスクに対して事前に定義された目標値（サービスレベルすなわちSLA）を、中央のリリース管理機能が公表する必要がある。一見、この管理評価指標と、「スケジュール通り構築され実施されたリリース」と述べているこのセクションの最初のKPIとの違いを見極めることは困難に思われます。実際は、成功するリリースよりも、失敗するリリースから多くを学ぶことができます。SLAについてより深く検討することにより、この評価指標と最初のKPIの違いが見えてくることが分かります。例えば、SLAの中で、すべてのリリースの95パーセントが同意されたスケールの中で実行されるとする表明を行ったとします。その場合、このレポートはリリース管理の総合的パフォーマンスを示すことになるため、重要になります。つまり、リリースの実施の成功を目的として設定し、報告期間を決定し、次にすべてのITマネージャにこのレポートを発行しなければなりません。

• ビジネス連携の指標 – リリースを有効的かつ適時的に実行するためにSLA目標に同意した場合は、すべてのビジネスマネージャ、あるいは最低限SLAに署名した人たちに、このレポートを配付しなければなりません。

これでリリース管理のためのKPIと管理情報評価指標という最強の組み合わせが手に入りました。報告期間ごとにこれらすべてのカテゴリに関するレポートを作成するのは、難し過ぎるあるいは時間がかかるのがお分かりでしょう。ITILはフレームワークであるということを忘れないでください。自分の組織にとって最も重要なKPIと評価指標を選択し、そしてそれに関することだけを報告することができます。

最後に、ITの成功は有効な変更管理とリリース管理に依存することを忘れないでください。そして評価指標には手を抜かず、常に変更管理とリリース管理を改善する新たな方法を探し求めてください。

> > 第9章 - 構成管理