ITインフラの変更管理プロセス：初心者歓迎！ ITIL連載講座（1/4 ページ）

今回紹介する「変更管理」に登場する重要な3文字アクロニム（頭字語）に「RFC」と「CAB」がある。どちらも変更管理を語る上で大変重要な用語であり、考え方である。

[谷誠之，ITmedia]

このコンテンツは、オンライン・ムック「運用管理の過去・現在・未来」のコンテンツです。関連する記事はこちらでご覧になれます。

「RFC」と「CAB」

　まずは「RFC（Request For Change：変更要求書）」から。日本語訳を読んでも分かる通り、これはIT構成を変更する際に記述する書類である。何らかの理由により、ITサービスに必要なハードウエアやソフトウエア、手順や説明を記述した書類など、CMBD（構成管理データベース）に登録されているCI（構成アイテム）を変更したい時に作成する。

　RFCを作成する最大の理由は、インシデント管理や問題管理のプロセスの中で、そのインシデントや問題を解決するためにCIの変更が必要だ、と判断されたことである。また、ビジネス目標を達成するためや法律の変更などによってCIの変更が不可欠だと判断された場合にRFCが作成されることもある。例え話でいうと「レンズキャップをしたままシャッターを押したがために写真がとれなかった」というインシデントを根本的に解決するために、レンズキャップのついたカメラから、レンズキャップのついていないカメラに買い替える目的でRFCを作成するわけである。

　RFCを作成する目的とメリットは、次の通りである。

• 誰がどんなビジネス要求に基づいてどんな変更を要求しているかを明らかにする
• 変更によって影響を受けるCIの範囲や変更のタイムリミットなどを明らかにする
• 変更を実施することによってどのようなビジネス上のメリットがあるか明らかにする
• 変更を実施しなかったことによってどのようなビジネス上のデメリットがあるか明らかにする
• 変更に必要なコスト総額と、そのコストを誰が負担するかを明らかにする

　このような目的でRFCを作成するため、RFCには次のような内容が盛り込まれている必要がある。なお、「1」および「14〜19」は変更管理プロセスの中で埋まっていく項目である。

1. RFC管理番号
2. RFCの提出日付
3. RFC提案者
4. 変更されるCI
5. 変更の理由（ビジネスに対するインパクト）
6. 変更を導入しない場合の負のビジネスインパクト
7. 変更の実装を希望する日時
8. 変更の優先度
9. 変更によって発生する可能性のあるリスク
10. 切り戻し計画
11. 費用を負担する部署
12. 1次レベルの承認者
13. 1次レベルの承認日
14. RFCのステータス
15. レビューを受けた日
16. レビューの結果
17. 変更管理において承認した日
18. 変更の実装担当者
19. 実際に変更を実装した日時