変更におけるリスクを明らかにする
変更・リリース管理の目的は、リスクを軽減させることです。
リスクを減らす活動として、有名なものとして変更諮問委員会（CAB）がありますが、すべての変更でCABを開いていると変更の迅速性（アジャリティ）を下げることになります。これについては、前回のブログで解説しました
今回は、どのようにリスクを明らかにしていけばよいかを考えてみたいと思います。
まず、リスクには「実施するリスク」と「実施しないリスク」があります。
変更を実施する場合、「実施するリスク」＜「実施しないリスク」になっていないといけません。
例えば、Windows11の脆弱性が発表され、実施しないと全社員のPCが乗っ取られるリスクがある場合などは、わかりやすく「実施するリスク」＜「実施しないリスク」となっていると思います。
他の例だと、明日から割引キャンペーンをやると告知しているのに、ECサイトをキャンペーン用に変更するリリース作業をしないと膨大なクレームと機会損失が発生することが容易に予想できるため「実施するリスク」＜「実施しないリスク」であることがわかると思います。
リスクを判断して実施すると決まったら、次はどのようなステップで変更によるリスクを最小化するかという話になってきます。
変更・リリース管理でリスクを軽減するアクティビティには、以下のようなものがあります。
変更登録
変更計画
変更評価
変更承認
サービス・コンポーネントの検証
リリース手順の検証
リリースレビュー
リリース実行
リリース検証
変更のレビューと終結
すべての変更・リリース作業に対して上記のアクティビティをすべて実施していたら、「やってられっか、(ﾟДﾟ)ｺﾞﾙｧ!!」となります。
そもそも、リスクの少ない変更は早ければ早い方が良いです。
できるだけ何か日々の活動で代用したり、自動化したりして迅速性を高めた方が良いに決まっています。
そのためには、リスクの高低を可視化（数値化）する必要があります。
変更におけるリスクを評価する指標としては、以下のようなモノがあります。
発生リスク
影響範囲
過去実績
手順確立
これらの内容を標準化＆数値化して、変更リスクのスコアを数値化してみます。
このような内容を管理できれば、どのようなケースで、どの対応を省略してよいかを判断することができるようになります。
以下は例です。
スコア15以上は、変更諮問委員会を開催してリスクの把握とレビューを行う
スコア15以下は、チーム内での承認で実施判断可とする。
手順確立済み・過去実績ありであれば「サービス・コンポーネントの検証」「リリース手順の検証」「リリースレビュー」は省略してよい
発生リスクや影響範囲などについては、どのような変更内容が多く発生するかなど、企業の特性が出ると思いますし、何を重要視するかによって数値の重みづけは変わってきます。
ただ、変更内容の標準化は企業の変更スピード向上において重要な要素となります。
盲目的で官僚的なCABから脱却するためにも、自社内の変更リスクを標準化して改善してみることをお勧めします。
ITILなどの運用管理も含めて、実践的な運用設計を短期間で学び、トレーニングしたいというときは、私が研修やってますので是非ご参加ください。
運用設計の教科書の改訂版が出ます！
この記事が気に入ったらサポートをしてみませんか？