変更諮問委員会が安全性を損なう代わりに開発を停滞させるとき
チームリーダーがグループチャットにメッセージを送る。「データベースマイグレーションの変更リクエストのレビュー準備ができました」。CABミーティングは3日後だ。マイグレーション自体の実行時間は10分。しかしチームは、20件もの変更が議論される週次ミーティングの枠を72時間待つ。そのうち半分は自動処理可能なルーチン設定更新である。
この光景は、毎週あらゆる組織で繰り返されている。変更諮問委員会（CAB）は本番システムを保護するために設計された。しかし実際には、チームを苛立たせ、実質的な安全性をほとんど高めないボトルネックになっていることが多い。
CAB本来の意図
変更諮問委員会はITILフレームワークから生まれ、本番システムへの変更が実装前に適切な専門知識を持つ人々によってレビューされることを保証する手段として登場した。その考え方は理にかなっていた。ユーザーに影響を与えるものを変更しようとしているなら、同様の状況を経験したことのある別の視点から確認を得る、というものだ。
しかし実装は本来の意図から逸れた。多くの組織はCABを、リスクレベルに関係なくすべての変更が枠を必要とする週次ミーティングに変えてしまった。ミーティングは処理ラインと化した。設定値を更新するような低リスク変更が、コアデータベーススキーマを変更するような高リスク変更と隣り合わせに並ぶ。議題の大半が注意を必要としないため、参加者は集中力を失う。
核心の問題：すべての変更を同じように扱うこと
すべての変更に同じ承認プロセスが必要な場合、二つのことが起こる。第一に、チームはシステムをゲーム化することを覚える。CAB提出回数を減らすために小さな変更をまとめるが、各バッチに含まれる可動部品が増えるため、実際にはリスクが高まる。第二に、本当に人間の判断が必要な高リスク変更が、ルーチン業務の量に埋もれてしまう。委員会メンバーは疲弊する。注意が20件の項目に散らばり、実際に重大インシデントを引き起こす可能性のある2〜3件に集中できなくなる。
結果として、重厚だが浅い保護しか提供しないガバナンスプロセスが生まれる。チームは遅延に不満を募らせる。委員会は過重労働を感じる。そして本番インシデントは依然として発生する。なぜなら真のリスクが適切な注意を受けていないからだ。
モダンCABが実際に行うこと
モダンな変更諮問委員会はすべての変更を承認しない。二つのことを行う：高リスク変更を処理し、インシデントから学習する。
以下のフローチャートは、従来の週次CABプロセスとモダンなリスクベースアプローチを対比している。
高リスク変更の処理
高リスク変更とは、自動化パイプラインと事前定義ポリシーだけでは不十分なものである。例としては以下が挙げられる：
- 複数のサービスが依存するデータベーススキーマの変更
- ロードバランサールールなどコアネットワーク設定の変更
- 本番環境でのデータベースバージョンアップグレード
- 全ユーザーに影響する新しい認証フローのデプロイ
これらの変更には、依然として人間の判断が重要である。しかしレビューは週次ミーティングで行う必要はない。チームは変更内容、影響分析、ロールバック計画の説明を含めて非同期で変更を提出する。CABメンバーは都合の良いときにレビューし、不足があればコメントし、情報が十分であれば承認する。プロセス全体が数時間で完了し、数日かかることはない。
鍵となるのは、CABが週に一度しか開かないゲートではなく、いつでも相談できる存在であることだ。チームはいつでもレビューを依頼できることを理解している。委員会メンバーは、自分の役割がすべてのリクエストにスタンプを押すことではなく、エッジケースに対して判断を下すことだと理解している。
インシデントからの学習
モダンCABの第二の機能はしばしば見落とされるが、第一の機能よりも価値がある。本番インシデント発生後、委員会はインシデント後レビューを実施する。目的は責任の追及ではない。ガバナンスプロセスが見逃したものを理解することだ。
レビューが答えるべき質問：
- この変更は高リスクに分類されるべきだったのに、低リスクと分類されていなかったか？
- レビュー時に提供された情報に重要な見落としはなかったか？
- 異なるチーム間で同様の障害パターンが見られるか？
- 自動化パイプラインは将来この種の問題を捕捉すべきか？
これらのレビューから、CABはリスク分類ルール、承認しきい値、さらにはパイプライン設定自体の変更を推奨する。委員会はデプロイ前のチェックポイントではなく、配送システム全体を改善するフィードバックループとなる。
週次ミーティングへの影響
週次CABミーティングは完全にはなくならないが、その目的は変わる。個々の変更を一つずつレビューする代わりに、ミーティングはパターンを議論するための定期的な同期の場となる。議題には以下が含まれる可能性がある：
- 自動承認された変更のサマリー
- 非同期でレビューされた高リスク変更
- 直近の期間に観察されたインシデントパターン
- リスク分類ルールの更新提案
ミーティング頻度は低下する。焦点は処理から改善へと移る。委員会メンバーは、実際に自分の経験と判断を必要とする作業に時間を費やす。
前提条件：監査証跡
このモデルは、すべての決定が痕跡を残す場合にのみ機能する。変更がパイプラインによって自動承認されたか、CABによって非同期レビューされたか、ポリシー違反で却下されたかにかかわらず、システムは決定、コンテキスト、タイムスタンプを記録しなければならない。監査証跡はオプションではない。それらは委員会が過去の決定をレビューし、パターンを特定し、外部監査人に対してガバナンスが遵守されたことを証明することを可能にする。
証拠がなければ、モダンCABはカオスに見える。証拠があれば、人間の判断が本当に必要な場面にのみ適用される、適切に文書化されたシステムに見える。
CAB評価のための実践的チェックリスト
現在のCABプロセスに調整が必要かどうかを検討している場合、以下がクイックチェックリストである：
- 変更は委員会に到達する前にリスクレベルで分類されているか？
- 委員会はすべての変更をレビューしているか、それとも高リスクのものだけか？
- チームはスケジュールされたミーティング以外でもレビュー用に変更を提出できるか？
- 委員会はプロセス改善に焦点を当てたインシデント後レビューを実施しているか？
- すべての決定は監査目的に十分な詳細で記録されているか？
これらのほとんどに「いいえ」と答えた場合、CABは安全性を高めることなく遅延を追加している可能性が高い。
まとめ
週次ミーティングですべての変更をレビューする変更諮問委員会はガバナンスではない。それはお茶を濁す行為である。真のガバナンスは、人間の注意を本当に必要とする変更に集中させ、インシデントをシステム改善の機会として活用する。委員会はボトルネックではなく、学習メカニズムとなる。チームはより速く動く。本番環境はより安全になる。そして週次ミーティングは、ついに誰もが嫌うものではなくなる。