変更管理について、いま再び考える
システムに対して変更すると、良い結果だけでなく悪い結果をもたらす可能性があります。
悪い結果のことを一般的にはリスクと言います。（厳密には、良い結果もリスクらしいのですが、ここでは悪い結果にフォーカスします）
リスクを軽減するために、「更作業をする場合はちゃんとチェックして承認しなきゃ！」となり、変更諮問委員会（CABs）をやろうとなります。
しかし、ちゃんとチェックと承認は継続されるのでしょうか？
時間が経つにつれ、官僚的で何となく開催されているだけになってないでしょうか？
それはITIL4の「Change enablement」のプラクティスにも以下として記載されています。
このため、組織は、複雑で、多くの場合官僚的な、変更承認システムを確立することにな る。これらは、変更諮問委員会 (Change Advisory Board:CABs) として知られ、組織の価値の流れのボトルネックになることが多い。このような委員会は、遅れをもたらし、変更実現活動のスループットを制限する。
リソース、コスト、優先順位を考慮し、変更が許可されるようにすることが重要である。これは一般に官僚的な手順である必要はない。開発チーム、技術専門家、サービスオーナー、プロダクトオーナーなど、適切なレベルに変更権限の役割を委譲する。
このボトルネックを解消するためには、まずは適切な対象に対して変更チェックを行うというのが必要になってきます。
企業における変更には、以下のようなものがあります。
まず、「通常の業務」は予測可能なことが多いので、チェックリストやテンプレートを作って、定型的に変更におけるリスクを減らすことができます。
また、作業も標準化できることが多いので、多くは自動化できるでしょう。
それに対して、災害や大規模組織変更は、定型化や標準化が難しくなります。
そういった不確実性の高い変更に対しては、緊急体制や災害に対するルールを決めて、訓練することで事態が発生した際に迅速に対応できるようになります。
運用として一番注力しなければならないのは、中間ぐらいの「新しい規制要件」や「重大インシデント」などをどれだけ迅速に変更対応できるか、ということでしょう。
ここは標準化とルール制定と訓練の合わせ技になります。
運用の成熟度がもっとも問われるのはこのあたりでしょう。
変更作業によって発生するリスクによって、変更管理内容を変える必要があります。
まずはその選別をすることが、変更管理改善の第一歩だと思います。
ITILなどの運用管理も含めて、実践的な運用設計を短期間で学び、トレーニングしたいというときは、私が研修やってますので是非ご参加ください。
運用設計の教科書の改訂版が出ます！
この記事が気に入ったらサポートをしてみませんか？