こんにちは。
FL.OPSの中の人その2、DAO（だお）です。
第6回の今回もITIL (アイティル)について解説します。
今回はリリース管理について詳しく解説をします。
ITILのサービスサポートについては今回で最後となります。
今回のBLOGを読了すれば、あなたもITILマスターです（多分…）
(1) リリース管理とは
ITサービス（システム、ハードウェア、ソフトウェアなどを含む）に関する
変更を確実に実施するプロセスのことです。
ITILのサービスサポートでは、以下のように定義してあります。
「確実に許可されたソフトウェア、モジュールが利用されるようにすること」
「変更のリリースを構築する手段を提供すること」
「ソフトウェアのリリースを自動化すること」
(2) リリースの定義と分類
リリース管理におけるリリースとは
「ITサービスに対する許可された変更の集合」
のことを指し、以下の3つに分類されます。
①大規模リリース
⇒広範囲な新機能を含み先行した小規模なアップグレードや、緊急時の
修正を全て入れ替えるリリースのこと。
②小規模リリース
⇒小さな機能拡張を行うリリースのこと。
③緊急リリース
⇒少数の既知の問題に対する修正を含むリリースのこと。
(3) リリース管理を導入するメリット
оハードウェア・プラットフォーム、またはソフトウェア環境に関するリリース
プロセスの一貫性を保つことが可能となる。
о異なるプラットフォームや環境のハードウェアおよびソフトウェアコンポーネ
ントを含む、パッケージ内でリリースが同期されることにより、事業に対する
サービス中断を最小化することが可能となる。
о変更がリリースに統合されることにより、個別実装が少なくなり、テスト環境
および稼働環境が安定する。
оリリーススケジュールの事前公表による、組織内での適切な期待値の設定を
行うことが可能となる。
о稼働環境に対するハードウェアおよびソフトウェアのコントロールされた
リリースを通じた、エラーの削減。
о稼働環境に対する変更、つまりソフトウェア配布およびハードウェアの変更
の両方に関する完全なレコードの維持が可能となる。
оソフトウェアの不正コピーが存在する可能性の低減。
о組織が大いに依存しているハードウェアおよびソフトウェア資産の適切な
コントロールと保護を行うことが可能となる。
о整合性のとれたソフトウェアを多数の拠点に渡って維持する能力を通じた、
サポートコストの節約を図ることが可能となる。
(4) リリース管理を導入するには
リリース管理は以下の6つの活動から成り立っています。
①計画の立案
о変更管理プロセスにおいて承認されたRFCを元に計画を立案します。
оスタッフの役割および責任をはじめとして、使用するリソースの見積もり、
また、新しいハードウェアやソフトウェアが必要な場合は、サプライヤとの
交渉などを検討し、その結果を文書化する。
оリリースが失敗した場合の切り戻し手順を以下の2つの観点にて検討する
必要があります。
ⅰ）失敗したリリースを完全に破棄しITサービスを以前の状態に戻すための
計画立案。
ⅱ）リリースが失敗し、ITサービスの復旧が不可能である場合に実施される
緊急事態対策
※これらの対策は利用者の業務継続に大きな影響を及ぼすことから、サービ
ス提供者と利用者側との間にて検討し、合意されている必要があります。
②リリースの設計、構築および設定
リリースにて必要となるコンポーネントの設計・構築・設定を行う活動のこと
⇒必要となるコンポーネント（ハードウェアおよびソフトウェア）を調達し
組み立て、テスト計画や切り戻し手順書を作成する。
③リリースの受け入れ
оコンポーネントを利用したテストを実施する活動のこと。
⇒最終的な品質チェックであり、この活動によってリリースが要求どおりに
インストールおよび稼動することが証明されます。
о活動のアウトプットは以下の3つのドキュメントとなります。
ⅰ）テスト済みインストール手順書
ⅱ）テスト済みリリースコンポーネント
ⅲ）全ての当事者によって署名されるテスト結果文書
оテストはインストール手順と最終的なシステム機能の完全性を対象に実施され、
テストの各段階で承認される必要があります。
оこの活動は変更管理プロセスの最終ステップでもあることから、最終的な合意は
リリース管理および変更管理の両方にて行うことになります。
оテストにおいて失敗し却下されたリリースについては、変更管理を通して再スケ
ジュールされます。
о却下されたリリースは失敗した変更として、変更管理プロセスによってリソース
へのインパクトなどが追跡、評価されることになります。
④投入計画立案
оリリースの投入に向けた詳細な計画の立案を実施する活動のこと。
оこの活動にて立案される計画は以下の4つになります。
ⅰ）投入する際の性格で詳細なタイムテーブルと誰が何を行うかという情報
ⅱ）複数拠点が存在する場合は、拠点ごとの行動計画
ⅲ）インストールおよび破棄するべきCIのリスト
ⅳ）利用者への情報伝達方法
⑤コミュニケーション・準備・トレーニング
о利用者への対応準備のこと。
о操作等が変更されると操作に慣れるまでの間、利用者は混乱をきたしてしまう
可能性があるため、利用者目線に立ったサポートを準備し、トレーニング資料を
作成しておく必要があります。
о利用者とのコミュニケーションとして、リリースの仕組みを公開し、併せて利用者
に対する制約事項を公開することが望ましいです。
制約事項…予定通りに作業が完了しない可能性など
⑥配布とインストール
оリリースコンポーネントをテスト環境から本番環境に移し、導入する活動のこと。
оテスト環境から本番環境に移動する際、機器については破損、ソフトウェアに
ついては遠隔地への自動配布の仕組みを利用する場合があるため、完全性維持
に対して特に注意を払う必要があります。
о本番環境においてリリースコンポーネントの導入完了後に、CMDBを更新すること
を以って、リリース管理は完了となります。
今回はリリース管理について解説を行いましたが、いかがでしたか。
この解説を以って、ITILのサービスサポートに関する解説は完了となります。
ITILはあくまでも「ベストプラクティス」つまり「参考にすべき優良な事例」に過ぎません。
従って、これまでの解説どおりに運用をまわすのではなく、各々の業務に即した形に、
採用する範囲やレベルを変えて柔軟に適用を行う必要があることを覚えておいて下さい。
