変更管理とリリース管理など ITIL プロセス間の
関連付けを効率化したい

現状の課題

ITインフラ環境の変更は、新規アプリケーションの開発、既存アプリケーションの保守開発、セキュリティパッチ適用、障害に伴うプログラム不具合修正など、さまざまなことがきっかけで行う。変更作業は、非常に大規模なものから、ルーターの設定変更といった軽微なものまで多種多様である。
変更は、変更要求（RFC）という形で起案され、変更諮問委員会（CAB）などの会議体や書面での承認を通じて承認された後、実行に移される。
一方、リリースは、変更を実際に本番環境に適用するための一連の作業として計画され、同様に受け入れ会議や書面を通じて承認された後、実行に移される。
変更とリリースは密接に関連しているが、必ずしも1対1に対応付けられるわけではない。変更はどちらかといえば業務・サービス面との関連が強く、リリースは本番環境における構成アイテムとの関連が強い。一つの変更が複数のリリースとして行われるケースもあれば、複数の変更をまとめて一つのリリースとして実行するケースもある。また、変更は一般に開発部門がオーナーシップをもつケースが多いのに対し、リリースは運用部門がオーナーシップをもつケースが多い。
このように変更とリリースは密接に関連するものの、オーナーシップが異なることから、コミュニケーションギャップによる以下のような課題があげられる。

・開発部門のスケジュールを優先した無理なリリース計画によるリリースの失敗
・開発部門の優先順位を考慮しない運用部門の都合によるリリースの実施
・別の変更による影響を考慮せず実施したリリースによるインシデントの発生

解決策

上記のような課題を解決するには、変更管理とリリース管理をシームレスに連携するとともに、関係者間で密接にコミュニケーションするための仕組みや基盤を構築すべきである。
大規模な変更要求（RFC）が起案される場合、一般的に、いくつかのサブRFCに階層的に分割され、管理されるケースが多い。例えば、大規模なアプリケーション開発の場合は、サブシステム開発プロジェクトが複数並行して進行することになる。こうしたサブRFCを相互に関連付けて管理する必要がある。
リリースを行う場合、リリース要求はサブシステム単位、アプリケーション単位、サーバー単位など、ある程度独立してリリース可能な単位で起案される。RFCやサブRFCとリリース要求は相互に関連付けて管理する必要がある。
複数拠点への同一アプリケーションのリリースのように、一つのリリース要求を複数のサブリリース要求に分割して管理した方がよいケースもある。その場合は、リリース要求とサブリリース要求を関連付けて管理する必要がある。
このように関連するRFCやリリース要求をお互いに関連付けて管理することで、あるRFCがどのようなサブRFCから構成されるかが可視化される。また、それらがどのようなリリース要求としてリリースされるかということも可視化されるので、リリースの漏れを防止できるだけでなく、ある変更による別の変更やリリースへの影響が把握しやすくなる。
変更やリリースの予定日を関係者で共有することで、リリース計画の見通しを立てやすくなる。重要なシステムのリリースや大規模なシステムのリリースが重なると、万一リリースに失敗した際の復旧に必要な人的リソースが不足したり、重大なインシデントにつながったりする危険性が高くなる。
RFCやリリース要求と、それらの対象となる構成アイテムを相互に関連付けて管理することも重要である。こうすることで、構成アイテムを起点に関連するRFCやリリース要求を把握することができ、相互影響を考慮したリリース計画やテストを行うことが可能となる。

Senju Familyでの実践方法

プロセスの技 資料一式ダウンロード ツール活用術一覧へ戻る