こんにちは。
FL.OPSの中の人その2、DAO（だお）です。
第5回の今回もITIL (アイティル)について解説します。
今回は変更管理について詳しく解説をします。
ITILのサービスサポートの内容も佳境に入ってきました。
残り2回ですが、しっかり学んでいきましょう。
(1)変更管理とは
変更を確実にかつ効率よく処理するプロセスのことです。
ITILでは以下のように定義してあります。
「すべての変更を効率的かつ迅速に取り扱うために、標準化された方法、手順を確立し、それを
用いることで効率よく確実な変更を実施するための方法」
すなわち、変更管理とは変更を処理する標準的な方法、手順を確立し、それを用いることで効率
よく確実な変更を実施するための活動といえます。
(2)変更管理が適用される範囲
о変更の提起と記録
о変更のインパクト、コスト、利点およびリスクの評価
о事業上の正当性の明確化と許可の取得
о変更の実装と管理と調整
о変更の監視と報告
о変更要求（RFC）のクローズとレビュー
(3)変更管理を導入するメリット
о事業要件とITサービスの整合性の改善
о業務スタッフとサービスサポートスタッフ双方に対する変更の可視化とコミュニケーションの
向上
оリスク評価の改善
оサービス品質やSLA(サービスレベル契約)に対する変更の悪影響の低減
о提案された変更のコストに対する事前評価の改善
о切り戻すべき変更の減少と必要時に切り戻しをより簡単に行うための能力の向上
о変更管理プロセスを通じて蓄積された変更に関連する有益な管理情報の活用による、問題管理
と可用性管理の改善
оサービス中断の減少とサービス品質改善によるユーザの生産性向上
о緊急的な変更の実装や誤りのある変更の切り戻しのために、計画された職務を離れる必要性を
減少させることによる、主要な人員の生産性の向上
о大量の変更を扱う能力の強化
оサービス品質の改善および専門的なアプローチを通したITに関する事務サイドの認識の向上
(4)変更管理の活動
変更管理の活動は、以下の7つのプロセスより構成されます。
「変更の登録とフィルタリング」⇒「優先度の割り当て」⇒「変更のカテゴリ化」⇒
「インパクト評価とリソース」⇒「変更の認可」⇒「変更のスケジュール」⇒
「変更のテストおよび実装」
①変更の登録とフィルタリング
様々な場所から様々な理由で発生する変更の要求を先のステップで検討できるように
するため、一箇所に取りまとめる作業。
まずは変更要求（RFC）(*1)の作成からはじめます。
(*1)変更要求に含まれる内容
⇒変更の内容、変更の理由、変更の効果、変更提案者、変更対応スケジュール案
②優先度の割り当て
どの要求を最初に検討し評価すべきかを判断するために使用する「優先度」を影響度や
緊急度に基づいてRFCに割り当てます。
優先度の例は以下のとおりです。
ⅰ)即時(Immediate)
о多くのユーザに対するサービスの停止や深刻な問題を引き起こす可能性のある問題
の場合
о迅速な処置が要求され、リソースを直ちに割り当てて変更を実施する必要がある
可能性が高い場合
ⅱ)高(Hight)
о数人のユーザに深刻に影響する、あるいは多くのユーザにインパクトを与える可能
性が高い場合
оリソースに対してもっとも高い優先度が与えられる場合
ⅲ)中(Middle)
о深刻なインパクトはないが次にスケジュールされたリリース、またはアップグレー
ドまで、修正を延期できない場合
оリソースに対して中程度の優先度が与えられた場合
ⅳ)低(Low)
о変更は必要だが次にスケジュールされたリリース、またはアップグレードまで待つ
ことが可能な場合
③変更のカテゴリ化
変更が組織に与えるインパクト、変更を達成するために必要なリソース、両方の観点からRFCを
評価してカテゴリ分けを行う活動のこと。
カテゴリの例は以下のとおりです。
ⅰ)軽微な影響のみであり、実施にあたりリソースをほとんど必要としない
ⅱ)深刻な影響があり、実施にあたりある程度のリソースを必要とする
ⅲ)重大な影響があり、大量のリソースを必要とする
カテゴリⅰの場合は、次のステップには進まず、サービスデスク要員などの関係者に
権限が委譲され変更管理プロセスは、その結果を記録することになります。
④インパクト評価とリソース評価
変更の実施について最終的な検討を行う活動のことです。
変更諮問委員会（CAB）が、変更の実施に際して、RFCの検討を行います。
以下の観点にてRFCの検討を行います。
ⅰ)利用者のビジネスに与える影響度
ⅱ)利用者のシステムに与える影響度
ⅲ)ほかのサービスへの影響度
ⅳ)変更の実施に必要なリソース、コスト
⑤変更の認可
評価を行った変更に対する認可を行います。
変更管理プロセスでは、認可が以下のように分類されます。
ⅰ)財務上の認可
変更のコストが認可された予算内であることを示します。
ⅱ)技術上の認可
変更が実現可能であり、利用者へ提供しているサービスに不適当な影響を与える
ことなく実行可能であることを保証します。
ⅲ)事業上の認可
上記2点の認可が考慮されて最終的におりる認可
⑥変更のスケジュール化
組織から認可がおりた変更については、実施に向けてスケジュールが組まれ、その一方
で、実施に向けての準備を開始します。
実施に向けての主な準備は以下のとおりです。
ⅰ)新たなモジュールの開発
ⅱ)外部からの機器またはサービスの調達
ⅲ)新規、あるいは修正文書の作成
⑦変更のテストおよび実装
準備が整ったら、以下の観点にて変更に関するテストを実施します。
ⅰ)パフォーマンス
ⅱ)セキュリティ
ⅲ)保守性
ⅳ)サポート性
ⅴ)信頼性／可用性
ⅵ)機能性
テストにおいて変更が問題なく実施されることが確認されると、変更管理のプロセスは
完了となり、変更の実施は次回に解説予定のリリース管理のプロセスにて行うこととな
ります。
今回は変更管理について解説を行いましたが、いかがでしたか。
次回解説予定のリリース管理と混同しやすい部分が多々あるため、なかなか難しいプロ
セスですが、しっかりと覚えてください。
ITILのサービスサポートも、次回のリリース管理で最後となります。
次回もしっかりと学んでいきましょう。
