自動化された世界における変革諮問委員会の新たな役割

絶えず変化する世界では、少し前まではうまく機能していたプロセスが、もはや意図した通りに機能しなくなることがあります。そのようなプロセスの一つが、変更諮問委員会（CAB）の運営方法です。

次のようなフレームワークを採用する目的は DevOps 価値を加速させることで 継続的インテグレーションと継続的デリバリー（CI/CD）)。しかし、すべての変更を CAB に提出してレビューと承認を受ける必要があるため、プロセスのアジャイルな意図が損なわれます。

CABを用いてあらゆる変更を評価すると、貴重な従業員リソースが拘束されてしまいます。CABメンバーは組織のトップレベルのITおよび技術リーダーであることが多く、彼らの時間と才能は貴重です。

組織は、変更プロセスにおけるCABの役割をシフトすることで、メンバーの負担を軽減できます。すべての変更を評価するのではなく、CABは必要に応じてアドホックに会議を開催できます。特定の標準変更については、個々のCABメンバーによるレビュー対象として指定し、導入段階に先立ち、事前承認または詳細な議論を行うようにマークを付けることができます。CABの重点をシフトすることで、CABが必要に応じて機能し続ける一方で、より迅速な価値創造とリソースの効率的な活用が可能になります。

これら 4 つのステップにより、CAB への依存がさらに軽減され、IT 運用における価値創造が加速されます。

1. 手動承認を必要としない標準的な変更のモデルを開発する
2. 変更リスクを明らかにする主要な指標を特定し監視する 人工知能（AI）と機械学習（ML）を活用した分析
3. 可能な場合は変更承認を自動化する機会を特定し、低レベルのリスクを管理する変更有効化マネージャーを 1 人配置します。
4. CAB は、リスクの高い状況やトップレベルの戦略的な電話会議の場合にのみ呼び出し、チームは対面ではなく仮想的に会議を行うようにします。

これらのアクションにより、CAB メンバーの時間が解放され、価値創造が加速され、組織内の CI/CD 目標にプラスの影響がもたらされます。

より多くの変更を行うための変更モデルの開発標準的な変更

以内 ITIL v3 および v4 変更には主に3つの種類があります。

1. 標準的な変更はリスクが低く、事前に承認されており、解決手順も周知されている。
2. 重大なインシデントが発生した場合など、直ちに実施する必要がある緊急の変更
3. 通常の変更、または標準または緊急の変更カテゴリに含まれない変更

失敗のリスクが低い変更は、標準的な変更として扱うべきです。組織内の変更の大部分は標準化され、問題が発生した場合の解決手順とロールバック手順が整備されているべきです。既知の手順に従った標準的な変更は、CABを介さずに事前に承認・解決できます。これにより、CABは緊急の変更やその他の業務に時間を費やすことができます。

通常の変更は頻繁に発生するべきではありません。発生した場合、必ずしもCABレビューで解決する必要はありません。変更は、将来的に標準的な変更と同様に機能するように評価およびモデル化する必要があります。場合によっては、変更をより小さなコンポーネントに分割することで、プロセスが円滑になることがあります。そうすることで、変更の可能な限り多くのコンポーネントを標準モデルに適合させながら、真に新しいコンポーネントは個別に検討することができます。

目標は モデルの変更 事前承認を迅速に取得し、実装することができます。標準変更の量が増えるにつれて、CABの関与を減らしながら、変更の自動化を進める機会が増えます。

CAB が当初組織内のすべての変更をレビューしていたとしても、そのように運用し続ける必要はありません。

「過去には、すべての変更要求にCABの承認を得ることが、組織が監査要件に対処する唯一の方法だったかもしれない」 言う DevOps コンサルタント カイマー・カル「これは明らかにITILガイダンスのアドバイスではありませんでした。」

分析を使用して変更リスクを監視する

組織はデータを活用して、リスク源となる変更を分析できます。変更リスクのモデルを開発することで、IT運用リーダーは、 メトリックを監視する 変化を「適切に評価する」リーダーシップは、リスクを迅速に評価し、変化の評価と解決の遅れをなくし、 より直感的なIT変更リスク管理を実現 組織内で。

一部の指標はデータから直接導き出せますが、複雑な機械学習モデリングの結果として得られる指標もあります。機械学習は、与えられた変更リスク要因の予測力を評価し、最適な予測因子に焦点を当てた因果関係モデルを段階的に構築します。時間の経過とともに、機械学習モデリングはインシデントや問題とリスク要因を相関させ、より正確な結果を生成し、どの要因と開発プラクティスが変更リスクを引き起こすのかを特定するためのナラティブを構築できるようになります。

Numerifyの顧客は、「リスク信用スコアの変更組織内の各変更管理者に「変更管理者の行動と成果」という指標を付与しました。この数値スコアは、複数のリスク要因から算出され、管理者の行動と成果によって改善が期待できます。この行動KPIによって因果関係が明らかになり、変更関連の問題への対応にかかる時間、費用、労力を削減し、より迅速な解決を実現しました。

組織は、機械学習とAIを活用して追加の予測モデルとKPIを開発し、プロセスを強化できます。モデル化されたリスク要因に基づいて客観的なリスクスコアを割り当てることで、対応が効率化され、変更管理部門は迅速に意思決定を行うことができます。このシナリオでは、次のようになります。

• 低～中程度のリスクは許容できる
• 高リスクはCABによって審査され、凍結、分割、または必要に応じて他の戦略を使用して対処されます。

その 変更リスクモデル 明確な視覚化を用いて評価を容易に行えるようにし、フォローアップ調査のためのセルフサービスダッシュボードも備えるべきである。これにより、数日、場合によっては数週間の意思決定の遅れにつながる可能性のある、労働集約的な手作業によるデータ抽出と分析を削減できる。

変更承認を得るための CAB 会議の必要性の低減

CABは変化を意味することを覚えておくことが重要です アドバイザリー 変更承認委員会ではなく、変更委員会です。CABの目的は、すべての変更をCABに通すことでも、標準的な変更にCABを使用することでもありませんでした。

リスク管理は、分析、指標の監視、スコアリングシステム、そして低レベルの変更の自動化を活用することで効率化できます。CABは定期的な戦略アップデートのためだけに招集し、会議はオンラインで開催する必要があります。

この移行により、緊急CAB会議の必要性も軽減されます。代わりに、変更支援マネージャーが積極的に変更を監視できます。リスクの高い変更については、実施時にロールバック対策を講じ、トップレベルのITエキスパートが対応にあたります。

IT組織におけるCABの戦略的役割の付与

CABのこの新しい役割は戦略的であり、 グーグル は次のように示唆しています。「詳細なコードレビューを専門家や自動化された手法に移行することで、リーダーシップやマネジメント層の時間と注意力が解放され、より戦略的な業務に集中できるようになります。ゲートキーパーからプロセス設計者、そして情報提供者へと移行するこの方法は、ソフトウェアデリバリーのパフォーマンスに優れた組織の実践と一致しています。」

戦略的な焦点を当てることで、貴重な人的資源への負担を軽減し、CI/CDの継続的な流れを確保できます。これは、組織のチームの大多数がリモートワークを行っている世界的な危機の時期には特に重要になります。

組織は、IT分析と過去の成功事例に基づいたプロセスに基づいた戦略的思考を活用することで、苦痛ではなく、容易なCABレビューモデルを構築できます。このモデルを必要な場合にのみ活用することで、製品と顧客満足度を向上させる継続的なアップデートの提供を通じて、価値を維持しながら創造を加速させることができます。