|
|
|
2008.09.11
カテゴリ：勉強
今回紹介する「変更管理」に登場する重要な3文字アクロニム（頭字語）に「RFC」と「CAB」がある。どちらも変更管理を語る上で大変重要な用語であり、考え方である。
「RFC」と「CAB」 まずは「RFC（Request For Change：変更要求書）」から。日本語訳を読んでも分かる通り、これはIT構成を変更する際に記述する書類である。何らかの理由により、ITサービスに必要なハードウエアやソフトウエア、手順や説明を記述した書類など、CMBD（構成管理データベース）に登録されているCI（構成アイテム）を変更したい時に作成する。 RFCを作成する最大の理由は、インシデント管理や問題管理のプロセスの中で、そのインシデントや問題を解決するためにCIの変更が必要だ、と判断されたことである。また、ビジネス目標を達成するためや法律の変更などによってCIの変更が不可欠だと判断された場合にRFCが作成されることもある。例え話でいうと「レンズキャップをしたままシャッターを押したがために写真がとれなかった」というインシデントを根本的に解決するために、レンズキャップのついたカメラから、レンズキャップのついていないカメラに買い替える目的でRFCを作成するわけである。 RFCを作成する目的とメリットは、次の通りである。 誰がどんなビジネス要求に基づいてどんな変更を要求しているかを明らかにする 変更によって影響を受けるCIの範囲や変更のタイムリミットなどを明らかにする 変更を実施することによってどのようなビジネス上のメリットがあるか明らかにする 変更を実施しなかったことによってどのようなビジネス上のデメリットがあるか明らかにする 変更に必要なコスト総額と、そのコストを誰が負担するかを明らかにする このような目的でRFCを作成するため、RFCには次のような内容が盛り込まれている必要がある。なお、「1」および「14～19」は変更管理プロセスの中で埋まっていく項目である。 RFC管理番号 RFCの提出日付 RFC提案者 変更されるCI 変更の理由（ビジネスに対するインパクト） 変更を導入しない場合の負のビジネスインパクト 変更の実装を希望する日時 変更の優先度 変更によって発生する可能性のあるリスク 切り戻し計画 費用を負担する部署 1次レベルの承認者 1次レベルの承認日 RFCのステータス レビューを受けた日 レビューの結果 変更管理において承認した日 変更の実装担当者 実際に変更を実装した日時 CABの召集 RFCを受け取るのは変更管理プロセス、正確には変更管理プロセスを遂行する責任者である変更マネジャーである。変更マネジャーはRFCを受理し、後に触れる変更管理プロセスに従ってRFCに書かれた変更を検討していく。中には、特に必要なわけでもなく「あったらいいな」的な変更要求や、ビジネスにさほどインパクトを与えない変更要求もある。また、その変更は必要だがITサービスを長時間止めないといけないなど負のインパクトが大き過ぎたり、変更にコストがかかり過ぎたりする場合もある。そのようなさまざまな変更をきちんと管理する出発点がRFCである。 RFCに書かれた内容を変更マネジャーだけでは判断できない場合がある。そのような場合に変更マネジャーが召集するのがCAB（Change Advisory Board：変更諮問委員会）である。CABはRFCを評価し、変更の認可や優先順位を決定する組織のことである。CABはRFCをビジネスの観点で評価する。そのRFCがビジネスにどのようにインパクトがあるのか、コストは正当か、変更するならいつが妥当か、あるRFCが別のRFCと重なっていないか（矛盾していないか）、などを検討していくのである。 CABのメンバーには、次のような人を加える。 変更マネジャー（会議の議長も務める） 顧客（経営者層）の代表 ユーザ（ITサービスの利用者）の代表 技術的専門家。社内のITスタッフなど 外部サプライヤ（必要であれば） 他プロセスのマネジャー（問題マネジャー、サービスレベルマネジャー、財務マネジャーなど） サービスデスクのスタッフ（必要であれば） CABの召集は、できれば対面でのミーティングが望ましい。しかし全員がそろわないのなら、電話会議やウェブ会議などでも構わない。重要なのは、その変更がビジネスの観点から見て妥当であるかどうかということを正当に判断する、ということである。重大な問題が生じた時に、本来のCABのメンバが集まらない場合もある。そのような時のために、より少人数で決定を下すための仕組みもあわせて作っておいたほうがいい。必要最小限の面罵だけが集まる緊急会議のことを、CAB／EC（Emergency Committee：緊急会議）という。 変更管理プロセスの役割 変更管理の目的は、ITインフラの変更を効率的かつ効果的に実施するための標準的な方法・手順が確実に使われるようにするようにし、変更が原因で発生するサービス品質の低下を最小限にすることである。 信憑性はともかくとして、ITサービスの低下を招くインシデントの発生原因の90％が、ITインフラの変更に起因しているといわれている。確かに、何らかのトラブルが発生した時「直前に何か変更したか？」ということを疑うのが常である。ITサービスを向上させるはずの変更が、ITサービスを悪くしてしまっては、本末転倒である。そのために、変更プロセスをきちんと標準化しよう、というのである。 軽微な変更、例えばユーザのパスワードを変更するとか、プリンターのトナーを交換する、といった作業は「サービス要求」と呼ばれる。サービス要求にこたえるのは変更管理の仕事ではなく、サービスデスクの範疇である。 前述の通り、変更管理プロセスのスタートはRFCの提出である。RFCはインシデント管理や問題管理などから提出されることが多い。 ー続く ＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 関連リンク： ITILとは（itSMF Japanオフィシャルサイト） ITIL連載講座－1－ITILの成り立ちと現状を知る ITIL連載講座－2－「サービスデスク」導入は即効性アリ！？ ITIL連載講座－3－「構成管理」への理解を深める ITIL連載講座－4－インシデント管理のライフサイクルとKPI ITIL連載講座－5－「問題管理」でITサービスの貢献度を向上させる ITIL連載講座－6－ITインフラの変更管理プロセス_その１ ITIL連載講座－6－ITインフラの変更管理プロセス_その２ ITIL連載講座－7－リリース管理の役割――ITプロセスを円滑に回すために ITIL連載講座－8－サービスレベル管理――「不幸なSLA」を締結しないために_その1 ITIL連載講座－8－サービスレベル管理――「不幸なSLA」を締結しないために_その2 ITIL連載講座－9－可用性管理――SLAに定められたレベルを維持する ITIL連載講座－10－ITサービス継続性管理――災害対策を講じているか？ ITIL連載講座－11－キャパシティ管理――削減するだけがコスト最適化ではない ITIL連載講座－12－ビジネスに対するITの貢献度を証明――ITサービス財務管理 お気に入りの記事を「いいね！」で応援しよう
Last updated
2008.09.12 01:32:04
[勉強] カテゴリの最新記事
|
