そのシステム変更、大丈夫？：ITILを深める！ サービスサポート編（2/2 ページ）

[インフォリスクマネージ，ITmedia]

　まだ、変更管理手法・体制を確立できていないという場合は、第一段階として「変更管理マネジャー(責任者)」を選任することが重要である。変更管理を誰が責任をもって担当するのか明確にすることで、変更管理プロセスをスムーズに遂行する体制を整えるためだ。実際に体制を整える際には、責任者のほかに、技術的な担当者も選任することをお勧めする。これにより、主に変更手順・テスト計画の監査においてスムーズな変更管理が可能となる。変更管理マネジャーは、まず、RFCの受け入れ・拒絶の判断、変更の承認などに対し責任を持つことになる。

　変更管理マネジャーとともにもう1つ体制面で設置が必要となるのが、変更諮問委員会(CAB：Change Advisory Board)である。これは、重要な変更(複合的、または、多大なインパクトがある変更)に対して決定権を持つメンバーから構成される。その際には、IT部門・ビジネス部門それぞれの代表者が選任されるべきである。変更管理マネジャーにより、重要な変更と判断された場合、このCABにより変更時のインパクトや問題、変更による追加リソース割り当てなどを審議する。ただし、CABはこれらの審議結果に責任を負わない。変更に対する責任はあくまで変更管理マネジャーとなる。また、CABの一部として緊急変更の際に召集される緊急委員会(CAB/ED：Change Advisory Board Emergency Committee)も併せて設置しておく必要がある。

CAB構成例

　第二段階としては変更の分類を定義する必要がある。これは、変更に対する影響の重要度に基づき分類される。分類するにあたり、主に以下の要素が考慮される必要がある。

• 変更時にサービス停止の有無
• サービスの影響範囲（全ユーザーか、一部対象ユーザーか）
• 緊急度
• 追加リソースの有無
• 過去の変更実績（標準手順化の有無）

　このほかにも部門や業務の必要に応じて、分類要素を設定し、変更の分類を定義する必要もある。変更管理マネジャーは、この変更の分類に基づいて、受け付けたRFCに対して変更手続き方法を決めるわけだ。例えば、サービス停止が発生しせず、影響度合いの低い標準手順化された日常的な変更については、変更管理マネジャーの承認のみで変更実施を行うのが一般的だ。反対に、インパクトの大きい深刻な変更の場合は、前述のCABによる審議が必要になり、さらに重大な変更と判断された場合は、経営会議で審議される。

　第三段階としては、変更管理プロセスの各サブプロセスにおける成果物(文書)や基準を定める必要がある。以下は一例である。

変更管理サブプロセス成果物一覧例

サブプロセス	変更要求者提出文書	記録文書
RFC受付	変更要求書	RFC管理表
優先順位割り当て	―	RFC管理表
変更の分類	―	RFC管理表
インパクトとリソースの評価	変更計画書	RFC管理表、CAB（CAB／EC）議事録、変更計画評価表
変更の承認	―	RFC管理表、変更計画評価表
変更スケジュールの設定	変更計画書、スケジュール	RFC管理表
方法・手順の監査、テスト・実施の調整	本番移行計画書、変更手順書、テスト計画書	RFC管理表、本番移行計画評価表、変更手順評価、テスト計画評価表
変更レビュー	変更結果報告書	RFC管理表、変更管理報告書

このようにサブプロセスにおける基準や文書を明確化しておくことにより、変更管理プロセス全体の円滑な遂行が可能となる。

　最後に、実施が承認または提案された変更の詳細なスケジュールを把握する必要がある。このスケジュールは、「将来的な変更スケジュール」(FSC：Forward Schedule of Change)と呼ばれる。これは、計画上のサービスの可用性(PSA：Projected Service Availability)を作成する上で必要となるものだ。また、PSAは、合意されたSLAとサービスの可用性に対する、現在計画されているFSCに基づく文書になるのである。