ITIL 的目标
スポンサー:
ITIL の目標
リリース管理目標
第 5 章
リリース管理はよく変更管理の一部と考えられますが、実際は変更のリリースが失敗することが多いため、リリースはむしろ変更自体より重要なITIL要素です。このテーマに関するITIL目標は、包括的であり正確性が必要です。
- ソフトウェアおよび関連したハードウェアの効果的な普及を計画・監督する。
- 変更の配置・導入のためにITシステムに対し効率的な手続を設計し実行する。
- 変更されているハードウェアとソフトウェアが追跡可能で管理されている状態であること、そして認可・検査済みの適正バージョンのみのインストールを確実にする。
- 新しいリリースの計画と普及の間、顧客の期待を伝え管理する。
- 変更管理との連絡を通して、リリースの正確な内容と普及計画に同意する。
- 構成管理と変更管理のコントロール・プロセスを使用して、運用環境に新しいソフトウェア・リリースあるいはハードウェアを実行する－リリースは変更管理の下にあるべきであり、ハードウェア、ソフトウェア、ファームウェア、および文書CIのいかなる組み合わせで構成することもできる。
- 全てのソフトウェアのマスターコピーがDefinitive Software Library（DSL）に確実に保管され、また構成管理データベース（CMDB）が確実に更新されるようにする。
- 構成管理のサービスを使用して、発表あるいは変更されるすべてのハードウェアの安全が保証され、かつ追跡可能であることを確実にする。
通常8つも要素があると目標が分かりにくくなりますが、リリース管理は慎重な処理を必要とするので、ここでは正確性が重要です。一つ一つ各要素を見ていきましょう。
「ソフトウェアおよび関連したハードウェアの効果的な普及を計画・監督する」ここでのキーワードは、「計画」と「監督」です。「ソフトウェアとハードウェアの普及を統括するための明確な計画がありますか?」 普及させる間、通常のフィードバックが確実に関係者に与えられていますか？標準の計画／プロジェクトをテンプレートとして使用しますか?これら全ての質問に「はい」と答えることができれば、この要素を満たしていることになります。これらの質問に「はい」と答えることができない場合、あなたがおそらく経験しているであろう失敗が、基本的にこの要素を満たしていないことを証明しています。計画が使用されているかどうか不明であるなら、使用されていないと考えるべきでしょう。疑わしい場合は、普及に関わっている、あるいはそれについて相談されている、または知らされているかどうかサービスデスクなどの鍵となるチームに尋ねてください。
「変更の分配・導入のためにITシステムに対し効率的な手続を設計し実行する」通常、効率的な手続としては「チェックリスト」か「作業指示書」が知られています。これらの手続により、プロセスに必要な処理が事前に定められたサービスレベルと基準に合わせて実行されるのが確実になります。手続は、可能な限り正確であることが確実になるよう、不断の調整と修正が必要です。例えば、新しいワークステーションを検査する際、従うべき10の指示のリストがあるとします。しかしサービスデスクが新しいワークステーションの問題に関する問い合わせを受けているため、問題をその源で取り除くためにリストに別の指示を加えることができます。あなたには効率的な手続がありますか? そして継続的にそれらの有効性をモニタしていますか? 手続きが不充分であると考えられる場合、手続を改善しますか?この要素を満たすためには、これらの手続を管理するべきです。そうでない場合は、サービスデスクの記録を調べ、これらの手続がしかるべき場所にあればインシデントはより少ないだろうということを検証してください。
「変更されているハードウェアとソフトウェアが追跡可能でセキュアであること、そして認可・検査済みの適正バージョンのみのインストールを確実にする」この要素が示唆するのは、ライセンシングに関することです。ライセンス契約に従っているという確信をはれほどありますか?この要素は、アイテムが追跡可能でセキュアでなければならず、そして認可・検査済みの適正バージョンのみがインストールされると述べています。追跡可能になるには、アイテムはCMDBに適切なCIがなければなりません。セキュアとなるには、適正レベルのアクセシビリティがなければならず、またソフトウェアに関しては、セキュアなロケーションにコピーがなければなりません。適正となるには、アイテムは、生産環境から余分なバージョンが除外されなければなりません。認可されるには、アイテムに適正な署名がなければならず、またアイテムはライセンシング条件を満たしていなければなりません。検査済みとなるには、あらかじめ決められた基準と照らし合わせて独立して検査されていなければなりません。かなりのリストです。あなたの組織はこれらの要素をどれほど満たしていますか。これらをうまく実行できていないなら、それが正当性となります。あなたがそれらを実行していない、あるいは実行しているのがITの部分だけなら、その証拠をあなたのサービスデスク記録から探してください。場合によっては、組織がライセンシング条件を完全に遵守していることを誰かに文章で確認するように頼むなど、ダイレクトな呼びかけが功を奏することがあります。
「新しいリリースの計画と普及の間、顧客の期待を伝え管理する」この要素をチェックするのは極めて簡単です。まず、新しいリリースの計画がありますか?次に、顧客が満足するまで顧客の期待を伝え管理していますか？計画と手続きに組み込まれた伝達手段を持っているなら、この要素の「顧客の期待を伝える」という部分を満たしていることになります。「管理する」の部分に関しては、計画だけを考えないで下さい。提供されているフィードバックに満足であるかどうか、また期待が満たされていることに満足しているかどうか顧客に聞いてください。この情報により、あなたがこの目標要素を満たしているかどうか判断することができます。
「変更管理との連絡を通して、リリースの正確な内容と実施計画に同意する」以前述べたように、ITILの成功はプロセスの統合にあります。ここで、変更管理とリリース管理の関係を見直す必要があります。実施計画に変更管理が含まれることが不可欠です。これにより、他の変更のスケジューリングが可能になり、実施することによって他の変更が衝突あるいは遅れをきたさないようにすることができます。あなたは、実施計画を変更管理に提出してチェックしてもらいますか？そうでなければ、変更の衝突と潜在的遅延をこうむり、この要素の要件を満たさなくなるでしょう。
「構成管理と変更管理のコントロール・プロセスを使用して、運用環境に新しいソフトウェア・リリースあるいはハードウェアを実行する-リリースは変更管理の下にあるべきであり、ハードウェア、ソフトウェア、ファームウェア、および文書CIのいかなる組み合わせで構成することもできる」さらなる統合。この要素が、リリースがハードウェア、ソフトウェア、ファームウェア、および文書のいかなる組み合わせで構成することもできると述べていることに注意してください。確実に実施計画を成功させるには、実施計画の間、全CIの現在のステータスを反映するようCMDBを更新しなければなりません。また、変更管理はCIのステータスを管理する媒体となります。そのために構成管理と変更管理が、リリースと実施に完全統合されることが重要となるのです。このレベルまで統合されていれば、この要素を満たしていることになります。そうでない場合、このレベルの統合の重要性の根拠を明らかにしなければなりません。ここでも、サービスデスクの記録がこのポイントの証明の助けとなるデータを提供するかもしれません。
「全てのソフトウェアのマスターコピーがDefinitive Software Library（DSL）に確実に保管され、また構成管理データベース（CMDB）が確実に更新されるようにする」ITにはそもそもソフトウェアのマスターコピーを確保する必要性がありますが、それが効果的に行われることはあまりありません。ソフトウェアマスタの全てが安全なロケーションに確保されているかどうか、また生産環境で使用されているのがコピーだけであるかどうかチェックしてください。このチェックは簡単なはずです。
「構成管理のサービスを使用して、発表あるいは変更されるすべてのハードウェアの安全性が確実で、かつ追跡可能であることを確実にする」この最後の要素は、CMDBが常に全てのCIの現在のステータスを反映し、CMDBにあるすべてのアイテムが実際に存在するのを確実にするということです。これは、監査あるいはストック・チェックを行い、特定のロケーションにある実際のハードウェアとCMDBにリストアップされているハードウェアを比較することにより、容易にチェックすることができます。全てのチェックで正しいという結果が得られれば上出来です。正しい結果が得られない場合は、この要素を満たしていないことになり、正式な監査を受けなければならなくなります。
リリース管理は、ITがさらにビジネスの構造とプロセスに浸透するに従いますます重要になっているキー・プロセスです。リリース管理を滅多に行われないものとして拒否してはいけません。それは終始行われる活動なのです。組織が将来ITから充分な利益を確実に得たいと望むなら、効果的なリリース管理が不可欠です。