[ITIL4]開発手法を意識した変更実現とは？
IVEさんのFacebookで上記記事が紹介されていたのですが、以下のコメントを見ながら「そういえばITIL4の変更実現プラクティスではどこまで記載があるのかな？」と思い、確認してみました。
「変更の手動での文書化、変更承認の長期化、大規模な隔週の対面式CAB、リスクに関係なくすべての変更をレビューすることなどは、もはや現代の変更実務には不可欠ではなく、適していません。」
変更実現には詳細な記載はないものの、AgileやDevOpsを意識した記載がいくつかあり、プラクティスの冒頭にも「変更の複雑さに応じて、効率性、スループットおよびリスクコントロールの間でバランスをとること」が記載されています。つまり、変更承認のレベル感は状況によりコントロールすべきということです。
変更実現では、（従来からある概念ですが）通常の変更と標準的な変更（事前承認済みで承認不要）をうまく活用して自動化しつつ効率化を図ることを推奨しています。また、従来であれば作業依頼のような変更をワークフローで自動処理する話が中心だったと思いますが、それ以外にも標準的なインシデントや災害についても標準的な変更に含む点について触れています。
他には、変更実現のプラクティスとアジャイル開発のバックログ管理との関連性が非常にハイレベルで記載されておりますが、運用保守フェーズにおいてウォーターフォールと混在する環境で、どのようにプラクティスを具体的に設計するかは１つの大きな論点になります。
最後に、アジャイル開発を意識してだと思いますが、より効率的にスピーディーに変更を実現するためのポイントして以下の記載があります。
・独立した変更の単位を小さくすること
・変更作業の標準化および自動化すること
・期待値、コミュニケーションおよびステータスを可視化すること
・バリューストリームをベースにITILプラクティスとAgile、DevOpsが統合すること
本日は以上です。ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？