この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ITIL 大好き芸人のかめです。
ITIL 界隈では 今年の 2 月に 8 年ぶりの大型アップデートとなる、 ITIL V4 の発表がありました。
V3 までは、「サービスを通じて顧客に価値を提供する」という考え方だったのが、「顧客とともに価値を創出する」という考え方に変わるなど、色々と気になる変更点が盛りだくさんのようです。
私も、いち早く皆さんに ITIL V4 の変更点や素敵なところなどをご紹介したい気持ちがあるのですが、現在、公式ドキュメントは英語版のみとなっており、日本語版が出るまでは、公式訳と言葉や意味が違ってしまう可能性があるので、グッと堪えております。
日本語版については少し前にレビュアーを募集していたという状況なので、そろそろリリースされるんじゃないかなぁ。
そんなわけで、今回は ITIL V3 時点の情報で変更管理についてご説明します。
ITIL って何？という方は、以下のブログなどをお読みください。
ITIL の変更管理とは？
「すべての変更のライフサイクルをコントロールし、 IT サービスの中断を最小限に抑えながら、有益な変更を実施できるようにすること」
（出典：サービストランジション 4.2.1）
を目的としているプロセスです。
コントロールというところがポイントで、変更管理というプロセスでは、実際に変更までは行いません。
あくまで、全体統括を役割としたプロセスで、以下のようなことを行います。
- 変更要求の受付（ xx してください）
- 変更要求のレビュー
- 変更内容の評価
- 提起したのは誰？
- 理由は何？
- 変更することの見返りは？
- 変更に伴うリスクは？
- 必要なリソースは？
- 変更の構築、テスト、実施の責任者は誰？
- 他の変更との関係は？
- リスクの評価（受容可能なレベルまで低減できている？）
- 変更の許可
- 変更の構築、テスト、実施の調整
- 変更を展開することの許可
- 変更を展開することの調整
- 変更の状況確認（完了したのか？）
実際の変更作業については、「リリースおよび展開管理」というプロセスで実施します。
プロセスって何？という方は、以下のブログをお読みください。
すべての変更のライフサイクルをコントロールすることは現実的なのか
なんらかの変更をする上で、誰かにレビューをしてもらった方がいい、リスクなどの確認をした方がいいというのは、皆さんにも同意いただけると思います。
先ほど紹介した「変更要求の受付」〜「変更の状況確認」までの内容も、なんとなくやった方が良さそうなものに見えますよね。
とはいえ、「 EC2 インスタンスにタグを追加する」みたいなちょっとした変更でも毎回このフローでやるのはちょっと辛そうですよね。
変更管理の目的にある「すべての変更のライフサイクルをコントロール」って現実的なのかしらと思った方もいらっしゃるかもしれません。
答えは、「現実的」ではあるのですが、「変更の種類」と「変更モデル」の定義をすることが重要になります。
変更の種類とは？
ITIL のサービス変更には、以下の 3 種類があります。
| 変更の種類 | 内容 |
|---|---|
| 標準的な変更 | リスクが低く、比較的よくあり、手順または作業指示書に従って行われる事前承認済みの変更 |
| 緊急の変更 | 可能な限り迅速に導入しなければならない変更。例えば、重大なインシデント解決のための変更や、セキュリティに関わるパッチを実装するための変更など |
| 通常の変更 | 標準的な変更でも緊急の変更でもないすべてのサービス変更 |
（出典：サービストランジション 4.2.4.3）
実際にこの分類を使う場合、「標準的な変更」と「通常の変更」は言葉だけで見ると意味がわかりにくいという場合、分類の考え方だけを参考にして、「定型的な変更」と「通常の変更」というような形で名前を再定義してもいいと思います。
大事なのは、実際に運用する方にとってわかりやすいことだと思うので、 ITIL の考え方を活かしつつ、用語については、メンバー間で伝わるものを決めていただくといいのかな。
変更モデルとは？
変更モデルとは、一言で言えば、フローのことです。
ITIL では、繰り返し使える処理の手順などをまとめたものを 「 xx モデル」と呼んでおり、変更モデルの他に、インシデントモデルなんてものもあります。
変更モデルは、必ず用意する必要はありませんが、事前に定義し、該当する変更が発生した際にモデルに沿って対応を行えるようにしておくと便利です。
変更の種類と変更モデルの関係
変更モデルは 1 つである必要はありません。
変更を 3 つに分類し、変更の種類ごとにモデルを定義することや、変更の種類とは別の軸で、特別な手順が必要な作業についてモデルを作ることも可能です。
「標準的な変更」の場合は、変更を定義した際に事前に承認しているから、変更の評価や許可はスキップしたモデルを使うということができます。
このように、変更を 3 つに分類し、最低限、それぞれの種類に応じたモデルを定義しておくことで、「すべての変更のライフサイクルをコントロールし、 IT サービスの中断を最小限に抑えながら、有益な変更を実施できるようにすること」を実現することが現実的になります。
変更の分類についても途中で変更しても良いので、初めは「通常の変更」で対応していたけど、繰り返し作業が発生して、手順も準備できているし、手順の内容についても確認できているというものがあれば、「標準的な変更」に変えることができます。
「標準的な変更」については、リストを作っておいて、変更要求を受け付ける際に、リストを検索すれば、そのまま対応を進められるのか、変更の評価や許可が必要なのかを確認できるとスムーズかもしれませんね。