リスクベース承認：変更に本当に承認が必要なのはどのような場合か
同じ日に2つの変更が届いたと想像してみてください。1つは内部ダッシュボードのボタンの色を変更するものです。もう1つはチェックアウト機能の背後にあるデータベーススキーマを変更するものです。両方の変更が同じ承認プロセス（CABミーティング、マネージャーの承認、長い待機キュー）を通過しなければならないとしたら、チームはすぐに忍耐を失うでしょう。小さな変更は遅延し、リスクの高い変更が必ずしも適切な注目を集めるとは限りません。
これは多くのエンジニアリング組織で発生しています。すべての変更に単一の承認プロセスを適用すると、それは保護ではなく官僚主義になることがよくあります。人々は待ち、コンテキストは古くなり、最も危険な副作用が静かに現れます。チームは各変更のリスクについて明確に考えることをやめてしまうのです。
すべての変更を承認することの問題点
すべての変更に同じ承認が必要な場合、チームはオーナーシップを失う可能性があります。開発者は「後で誰かがチェックしてくれるだろう」と考えてしまうかもしれません。しかし、変更に最も近い人物が通常、それを最もよく理解しています。承認が唯一の品質管理メカニズムになると、チームはより注意深くなるどころか、逆に不注意になります。
過剰な承認は安全性の幻想を生み出します。レビュアーはあまりにも多くの変更を短時間で検査することを強いられます。高リスクの変更は浅いレビューしか受けられず、低リスクの変更は同じキューで待機することになります。プロセスは管理されているように見えますが、実際のリスクは適切に管理されていません。
リスクベース承認の原則
リスクベース承認はシンプルな原則から始まります。リスクが高いほど、承認経路は強固であるべきです。低リスクの変更は迅速に進めることができます。高リスクの変更は、その影響を理解している人々によってレビューされるべきです。
多くのチームはすでにこれを非公式に行っています。問題は、明確なフレームワークがないと、「承認が必要」と「承認が不要」の境界があいまいになることです。決定は、誰が変更をリクエストしたか、誰が当直か、その週の組織の不安の度合いに依存します。より良いモデルは、承認経路を変更の実際のリスクに結び付けます。
承認しきい値の定義
承認しきい値とは、変更が自動的に進められるか、人間の承認を待つ必要があるかを決定する線です。その線は、明示的で、一貫性があり、変更の観察可能な特性に結び付けられている必要があります。
有用な基準は以下の通りです：
- 変更はユーザーデータに触れるか？
- データベーススキーマやマイグレーションパスを変更するか？
- サービスの可用性に影響を与える可能性があるか？
- 決済、認証、セキュリティ、またはその他の重要なフローを含むか？
- 多くのシステムが依存するインフラストラクチャを変更するか？
- 脆弱な動作の履歴があるコンポーネントに影響を与えるか？
最良のしきい値は自動的に検出できます。パイプラインは、プルリクエストにデータベースマイグレーションファイル、Terraformの変更、モバイル署名設定、または本番環境のシークレットポリシーの変更が含まれていることを確認できます。そして、推測に頼ることなく、適切な承認経路にデプロイをルーティングできます。
3つの実用的な変更カテゴリ
多くのチームは3つのカテゴリから始めることができます。
標準変更は低リスクで反復可能です。例としては、コンテンツの更新、十分にテストされた設定変更、または既知の安全なパターンに従うデプロイなどがあります。これらの変更は正式な承認なしで進めるべきです。品質に対する責任はチームにあります。
通常変更は中程度のリスクを伴います。影響を受ける領域を理解している1～2人からのレビューが必要になる場合があります。これは通常、非同期で行うことができます。正式なミーティングはほとんど必要ありません。
緊急変更は、インシデントを解決したり、即時の損害を防ぐために行われます。摩擦を最小限に抑えた迅速な経路と、その後の事後ドキュメントが必要です。目標は復旧を遅らせることではありません。目標は、組織が何が変更され、なぜ変更され、インシデント後に何を改善すべきかを確実に把握することです。
これがチームの行動をどう変えるか
承認が意味のあるリスクのために予約されると、チームはより注意深くなります。小さな変更は自分たちの責任であることを認識します。また、大きな変更は、盲点を発見できる人々から追加の注目を集めることも認識します。
これは、引き継ぎの文化ではなく、オーナーシップの文化をサポートします。開発者は承認の背後に隠れることができません。レビュアーは些細なリクエストに埋もれることはありません。組織は、注意が本当に重要な場所に注意を向けます。
実践的なチェックリスト
- データベース、決済フロー、認証、インフラストラクチャ状態、共有サービスなどの重要なコンポーネントを特定する。
- 各リスクカテゴリの客観的なしきい値を定義する。
- 標準、通常、緊急の各変更にどの承認経路が適用されるかを文書化する。
- 可能な場合はパイプラインにリスク指標を検出させる。
- 承認と証拠をデプロイメント記録の一部として記録する。
- システムとチームの進化に伴いリスクが変化するため、しきい値を定期的に見直す。
デリバリーを促進するガバナンス
リスクベース承認により、ガバナンスはデリバリーの妨害者ではなく、デリバリーの支援者になります。低リスクの変更には迅速な経路を提供し、高リスクの変更にはふさわしい注意を提供します。
重要なのはすべてを承認することではありません。重要なのは正しいものを承認することです。健全なCI/CDシステムは、ルーチンの動きと実際の危険を区別する必要があります。その区別が明確になれば、チームはすべての変更が同じように安全であるふりをすることなく、より迅速に動くことができます。
具体的な takeaways: まず、あなたの環境で本当に高リスクな変更は何かを特定してください。ルーチンの変更には迅速な経路を提供してください。リスクの高い変更には、より強力なレビューを提供してください。効果的な承認とは、すべての動きをコントロールすることではありません。実際の損害を引き起こす可能性のある変更が、本番環境に到達する前に適切な注意を確実に受けられるようにすることです。