リリース管理の役割――ITプロセスを円滑に回すために：初心者歓迎！ ITIL連載講座（3/3 ページ）

[谷誠之，ITmedia]

リリースタイプ

　リリースのタイプは、次のように分類できる。

• フルリリース

　関連するリリースユニット（ハードウェアやソフトウェア）全体をすべて更新するリリースである。テストや切り戻し計画もこの単位で行われるので、リリース後のインシデントが発生する可能性が低い。

• デルタリリース

　リリースユニットの中の変更が発生する部分のみをリリースする方法である。テストや配布の工数を削減できる可能性があり、緊急度が高いリリースに向いている。

• パッケージリリース

　関連する複数のリリースを同時に行う方法である。パッケージリリースの中には、複数のフルリリース、またはデルタリリースが含まれる。ITサービス環境を長時間安定させたい場合に有効であるが、大規模になりがちで、その大規模なリリースを確実に実装できる技術力が必要である。

　リリースは大小を問わず、必ずITサービスに何らかの影響を与える。リリース中はITサービスを一時的に止めなければならなかったり、新しい環境にユーザが慣れるのに時間がかかったりする。そのため、リリースの回数はできるだけ減らすのが望ましい。とはいえ、緊急性の高いリリースは一刻も早く導入しなければならない、という場合もある。上記の3つのリリース・タイプを念頭において、バランスのよいリリース計画を立てることが必要である。

リリース管理のKPI

　リリース管理がうまくいっているかどうかを評価するためのKPI（重要業績評価指標）には、次のようなものが考えられる。

• スケジュール通りにリリースできた件数
• リリース後にCMDBが正確である割合
• テストされずにリリースされた件数
• リリースが原因で発生したインシデントの件数
• リリース前のテストの段階で見つかった不具合の件数
• リリース後に見つかった不具合の件数
• 未許可のソフトウェアが使用されている割合
• DSLやDHSに保管されていない、実環境に存在するソフトウェアやハードウェアの件数
• 顧客満足度、ユーザ満足度

　変更管理、リリース管理は、慣れなければ面倒な手順である。周知徹底されなければ、社内の反抗もあるだろう。しかし、成熟した変更管理、リリース管理は、実環境でのITサービスのインシデントや問題を確実に減らし、未許可のソフトウェアを減らし、サポートコストを減らす。その結果、ITサービスのビジネスに対する貢献度が増し、ITサービスに対する信頼度が増し、顧客満足度やユーザ満足度が増す。管理のための管理になってはいけないが、可能な範囲で、できるところから、プロセスをきちんと回していく努力を重ねよう。そのためには、経営者層の理解も必要不可欠である。

※本連載の用字用語については、ITILにおいて一般的な表記を採用しています。