すべての変更が同じではない：標準変更、通常変更、緊急変更

ある開発者が会社の「About Us」ページのタイポ修正のためにプルリクエストを開きました。3日経っても、修正はまだ承認待ちです。一方、別のチームは決済データベースのスキーマ移行を準備していますが、同じ承認プロセスを待っています。タイポ修正とデータベース移行がまったく同じように扱われています。どちらもミーティング、承認、そして次のリリース枠へのスケジュールが必要です。

この状況は苛立たしいものですが、よくあることでもあります。すべての変更が同じ承認パイプラインを通ると、小さな修正は重いプロセスの後ろで詰まり、リスクの高い変更は本来必要な精査を受けられない可能性があります。問題はガバナンス自体ではありません。問題は、すべての変更が同じリスクを持つかのように扱うことです。

なぜ一律の承認は失敗するのか

すべての変更を管理しようとする本能は良い意図から来ています。誰も本番環境を壊したくはありません。しかし、承認プロセスがテキスト更新とスキーマ移行を区別しない場合、2つのことが起こります。第一に、低リスクの変更が、実際の安全性を追加しない承認を待って積み上がります。第二に、チームがプロセスに対して無感覚になります。すべてに承認が必要になると、人々は承認が実際に重要かどうかを考えなくなります。ただチェックボックスを待つだけになります。

結果として、安全な変更を遅くする一方で、リスクのある変更をより安全にすることのないシステムができあがります。解決策はガバナンスをなくすことではありません。解決策は、ガバナンスをリスクに比例させることです。

3つの変更カテゴリ

成熟したチームの多くは、リスクと習熟度に基づいて変更を3つのカテゴリに分類します。標準変更、通常変更、緊急変更です。各カテゴリには異なる承認パスがあります。

次のフローチャートは、変更がパイプラインに入り、その分類に基づいて適切な承認プロセスにルーティングされる様子を示しています。

flowchart TD A[変更リクエスト] --> B{緊急か？} B -->|はい| C[緊急変更] C --> D[すぐに変更を実施] D --> E[ドキュメント化と事後レビュー] B -->|いいえ| F{手順は文書化され、実績があるか？} F -->|はい| G[標準変更] G --> H[自動パイプライン承認] H --> I[デプロイ] F -->|いいえ| J[通常変更] J --> K{リスクレベルを評価} K -->|低| L[ピアレビュー] K -->|高| M[CABまたはマルチステークホルダーレビュー] L --> N[承認してデプロイ] M --> N

標準変更

標準変更とは、チームが何度も実行したことのある変更です。手順は既知で、結果は予測可能であり、リスクは十分に理解されています。例としては、マーケティングページの静的コンテンツの更新、トラフィックスパイクに対処するためのサーバー追加、一時的なネットワーク問題で失敗したパイプラインの再実行などがあります。

チームは何が起こるかを正確に把握しており、実績のある手順があるため、標準変更には手動レビューや承認は必要ありません。チームは文書化された手順に従うだけです。重要な要件は、手順が文書化され、監査可能であることです。何か問題が発生した場合、チームはトレースバックして、手順が正しく守られたかを確認できます。

標準変更こそ、自動化が真価を発揮する領域です。手順が本当に予測可能であれば、CI/CDパイプラインにコード化されるべきです。パイプライン自体が承認メカニズムになります。自動チェックに合格すれば、変更は通過します。

通常変更

通常変更とは、チームがこれまでに行ったことのない変更、またはリスクが完全に理解されていない変更です。例としては、ビジネスロジックを変更する機能の追加、データベースバージョンのアップグレード、セキュリティ設定の変更などがあります。

通常変更にはレビューが必要です。レビューアは、リスクレベルに応じて、ピア開発者、セキュリティチームメンバー、または変更諮問委員会（CAB）の場合があります。しかし、レビューが遅いプロセスを意味するわけではありません。低リスクの通常変更の場合、1～2人による迅速なレビューで十分です。高リスクの通常変更の場合、レビューにはより多くのステークホルダーと追加のテストが含まれる可能性があります。

重要な点は、通常変更がデフォルトでブロックされないことです。リスクに比例してレビューされます。何が低リスクで何が高リスクかを明確な基準を持つチームは、各変更を適切なレビューの深さに自動的にルーティングできます。

緊急変更

緊急変更とは、稼働中の問題を修正するために即座に実行しなければならない変更です。例としては、本番サーバーのダウン、データの破損、セキュリティ脆弱性の活発な悪用などがあります。これらの状況では、レビューや承認ミーティングを待つと問題が悪化します。

緊急変更にはファストトラックがあります。チームはすぐに変更を実行できますが、条件があります。変更は文書化され、事後に評価されなければなりません。チームは、何を変更したか、誰が変更したか、なぜ緊急だったか、影響は何かを記録する必要があります。インシデントが解決した後、チームは緊急変更が適切だったか、さらなる修正が必要かを評価します。

ファストトラックは無料パスではありません。これはトレードオフです。今のスピードと、後での説明責任です。日常的な変更を緊急として分類することで緊急トラックを乱用するチームは、最終的に信頼を失い、真のリスクを生み出します。

変更を分類する方法

3つのカテゴリは、チームがそれぞれに明確な基準を持っている場合にのみ有用です。基準がなければ、分類は恣意的になります。ある人にとっての標準変更が別の人にとっては通常変更となり、システム全体が崩壊します。

まず、何が標準変更かを定義することから始めます。良い経験則は次の通りです。チームが同じ変更をインシデントなく少なくとも5回実行し、手順が完全に文書化されている場合、それは標準ステータスの候補です。不確実性がある場合は、通常カテゴリに属します。

通常変更については、何が高リスクで何が低リスクかを定義します。一般的な要素には次のものがあります。変更はデータベーススキーマに触れるか？認証または認可に影響するか？金銭の扱い方を変更するか？ロールバック計画が必要か？「はい」が多いほど、リスクが高くなります。

緊急変更については、何が緊急事態に該当するかを定義します。ランディングページのタイポは緊急事態ではありません。有料顧客に影響する本番停止は緊急事態です。チームは、真の緊急事態の例と、緊急に見えるが実際にはそうでない状況の例について合意すべきです。

パイプラインへの分類の統合

基準が明確になったら、次のステップは分類をCI/CDパイプラインに統合することです。これは複雑な承認システムを構築することを意味しません。変更リクエストまたはデプロイメントチケットに、開発者に変更を分類させるシンプルなフィールドを追加することを意味します。パイプラインはその後、変更を適切なレビューパスにルーティングできます。

例えば、GitHub Actionsワークフローは、プルリクエストがドキュメントや設定ファイルのみに触れる場合に自動的に standard ラベルを付け、手動承認ステップをスキップできます。

name: Classify Change
on: pull_request

jobs:
  classify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v5
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          configuration-path: .github/labeler.yml

  deploy-standard:
    if: contains(github.event.pull_request.labels.*.name, 'standard')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy without manual approval
        run: echo "Deploying standard change..."

そして、付随する .github/labeler.yml ファイルは、どのパスが standard ラベルにマップされるかを定義します。

standard:
  - changed-files:
      - any-glob-to-any-file: ['docs/**', 'config/**', '*.md']

標準変更の場合、パイプラインは通常のテストに合格した後、自動的に進むことができます。通常変更の場合、パイプラインは一時停止し、適切なレビューアに通知できます。緊急変更の場合、パイプラインはデプロイを許可しますが、デプロイ後のドキュメント作成要件をトリガーします。

目標は官僚機構を構築することではありません。目標は、パイプラインがチームのリスクに対する理解を反映させることです。パイプラインが自動的に分類を処理するとき、チームはプロセスに費やす時間が減り、実際の作業に多くの時間を費やすことができます。

実用的なチェックリスト

次のデプロイの前に、これらの質問を自問してください。

  • この変更は、文書化された手順で以前に行ったことがあるものか？はいの場合、標準として扱い、承認を自動化する。
  • この変更は新しいもの、または不確実なものか？はいの場合、リスクレベルを特定し、適切なレビューアを割り当てる。
  • この変更は稼働中の問題を修正するために必要か？はいの場合、今すぐ変更を実行するが、すべてを文書化し、インシデント後のレビューをスケジュールする。

まとめ

ガバナンスとは、全員を遅くすることではありません。適切な変更に適切な量の制御を適用することです。標準変更は迅速に進むべきです。通常変更は比例したレビューを受けるべきです。緊急変更はスピードと説明責任を両立させるべきです。チームが基準に合意し、それをパイプラインに組み込むとき、承認はよりスマートになり、重くはなりません。