リリース管理の役割――ITプロセスを円滑に回すために:初心者歓迎! ITIL連載講座(3/3 ページ)
今回は「リリース管理」を紹介する。「リリース管理」に関連登場する重要な3文字アクロニム(頭字語)には「DSL」と「DHS」がある。ITILの書籍を読むとDSLについてのみ書かれている場合が多いが、DHSも重要な考え方である。
リリースタイプ
リリースのタイプは、次のように分類できる。
- フルリリース
関連するリリースユニット(ハードウェアやソフトウェア)全体をすべて更新するリリースである。テストや切り戻し計画もこの単位で行われるので、リリース後のインシデントが発生する可能性が低い。
- デルタリリース
リリースユニットの中の変更が発生する部分のみをリリースする方法である。テストや配布の工数を削減できる可能性があり、緊急度が高いリリースに向いている。
- パッケージリリース
関連する複数のリリースを同時に行う方法である。パッケージリリースの中には、複数のフルリリース、またはデルタリリースが含まれる。ITサービス環境を長時間安定させたい場合に有効であるが、大規模になりがちで、その大規模なリリースを確実に実装できる技術力が必要である。
リリースは大小を問わず、必ずITサービスに何らかの影響を与える。リリース中はITサービスを一時的に止めなければならなかったり、新しい環境にユーザが慣れるのに時間がかかったりする。そのため、リリースの回数はできるだけ減らすのが望ましい。とはいえ、緊急性の高いリリースは一刻も早く導入しなければならない、という場合もある。上記の3つのリリース・タイプを念頭において、バランスのよいリリース計画を立てることが必要である。
リリース管理のKPI
リリース管理がうまくいっているかどうかを評価するためのKPI(重要業績評価指標)には、次のようなものが考えられる。
- スケジュール通りにリリースできた件数
- リリース後にCMDBが正確である割合
- テストされずにリリースされた件数
- リリースが原因で発生したインシデントの件数
- リリース前のテストの段階で見つかった不具合の件数
- リリース後に見つかった不具合の件数
- 未許可のソフトウェアが使用されている割合
- DSLやDHSに保管されていない、実環境に存在するソフトウェアやハードウェアの件数
- 顧客満足度、ユーザ満足度
変更管理、リリース管理は、慣れなければ面倒な手順である。周知徹底されなければ、社内の反抗もあるだろう。しかし、成熟した変更管理、リリース管理は、実環境でのITサービスのインシデントや問題を確実に減らし、未許可のソフトウェアを減らし、サポートコストを減らす。その結果、ITサービスのビジネスに対する貢献度が増し、ITサービスに対する信頼度が増し、顧客満足度やユーザ満足度が増す。管理のための管理になってはいけないが、可能な範囲で、できるところから、プロセスをきちんと回していく努力を重ねよう。そのためには、経営者層の理解も必要不可欠である。
※本連載の用字用語については、ITILにおいて一般的な表記を採用しています。
関連記事
- 【特集】運用管理の過去・現在・未来
システム管理者がノウハウを蓄積し、自らの評価につなげるために「システムアナリスト」としてステップアップする道を探る。システム管理者よ、今こそ起て!
Copyright © ITmedia, Inc. All Rights Reserved.