ガバナンスを別のチケットシステムとして扱うのをやめよう

フィーチャーが完成しました。コードはビルドされ、テストはグリーン、ステージング環境へのデプロイも正常です。さて、次は何をしますか？多くのチームでは、次のステップはチケットを起票し、変更諮問委員会（CAB）にメールを送り、待つことです。数時間、あるいは数日かもしれません。パイプラインはアイドル状態になり、人々はまったく別のシステムで承認を追いかけ回します。

この技術的な作業とガバナンスの分離は摩擦を生みます。開発者は自分のツールからコンテキストスイッチを強いられます。承認者はテスト結果やデプロイ履歴を見ずに変更をレビューします。監査証跡はメールのスレッド、チケットのコメント、チャットメッセージに散らばります。誰もがプロセスが遅いと感じていますが、チェックを完全になくそうとは誰も思いません。

解決策はガバナンスを排除することではありません。ガバナンスを、作業がすでに行われているパイプラインに直接埋め込むことです。

手動承認ステップ：シンプルで監査可能

最も簡単な統合方法は、パイプラインに手動承認ゲートを設置することです。自動ビルドとテストがステージングで成功した後、パイプラインは一時停止します。人間が証拠をレビューして承認ボタンをクリックし、本番環境へのデプロイを進めるのを待ちます。

次の図は、従来のアプローチと新しいアプローチを対比しています。

このパターンは、人間の判断が必要だが、完全なCABミーティングを必要としない通常の変更に適しています。レビューアはテスト結果、差分、デプロイ状況をすべて一箇所で確認できます。別のチケットを開いたり、チャットログでコンテキストを探したりする必要はありません。

以下は、本番環境へのデプロイ前にパイプラインを一時停止して手動承認を求める、最小限のGitHub Actionsの例です。

name: Deploy to Production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://example.com
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
      - name: Deploy
        run: make deploy

このワークフローが実行されると、GitHub Actionsはproduction環境へのデプロイを作成します。その環境にレビューアが必要な場合、パイプラインは一時停止し、Deployステップを実行する前に承認を待ちます。レビューアはGitHubインターフェースでコミット、テスト結果、差分を確認できます。

重要なのは、承認ステップが誰が、いつ、何を承認したかを記録することです。これが監査証跡になります。GitLab CI/CD、Jenkins、GitHub Actionsなどのツールはすべてこれをネイティブでサポートしています。本番環境へのデプロイを承認できるロール（通常はシニアエンジニアやテックリード）を設定すると、パイプラインがそれを強制します。

しかし、手動承認がすべての変更に適しているわけではありません。すべてのプルリクエストで人間がボタンをクリックする必要がある場合、自動的に流れるべき低リスクの更新が遅くなります。

ポリシー・アズ・コード：パイプラインに判断させる

リスクが予測可能な標準的な変更の場合、手動承認はボトルネックになります。ここでポリシー・アズ・コードの出番です。ガバナンスルールを人々が覚えておかなければならないドキュメントに書く代わりに、パイプラインが自動的に評価するコードとして記述します。

ポリシー・アズ・コードのルールは次のようになります。「フロントエンドの設定ファイルのみに影響する変更は、すべてのテストが成功すれば、人間のレビューなしで本番環境にデプロイできる。」または「データベーステーブルにカラムを追加する変更は、DBAの承認を得てからでなければならない。」

これらのルールは、アプリケーションコードと同様に、リポジトリ内のファイルに保存します。パイプラインはルールを読み込み、現在の変更を評価し、レビューのために一時停止するか、自動的に続行するかを決定します。ルールに違反した場合、パイプラインは「この変更はusersテーブルにカラムを追加しますが、DBAの承認が見つかりませんでした」という明確なメッセージとともに失敗します。

チームは自分の変更が安全かどうかを推測する必要はありません。パイプラインが教えてくれ、毎回一貫してルールを強制します。

両方のアプローチを組み合わせる

手動承認ステップとポリシー・アズ・コードは相互排他的ではありません。これらは一緒に使うことで最も効果を発揮します。ポリシー・アズ・コードはルーチン的な決定を自動的に処理します。手動承認ゲートは人間の判断を必要とする変更をキャッチします。

例えば、パイプラインに次のようなルールを設定できます。

• ドキュメントや静的アセットへの変更：テスト合格後、自動的にデプロイ。
• 完全なテストカバレッジがあり、データベースマイグレーションを含まないアプリケーションコードの変更：ステージング検証後、自動的にデプロイ。
• データベーススキーマを変更する変更：一時停止し、DBAの承認を要求。
• 認証や決済ロジックへの変更：一時停止し、セキュリティチームの承認を要求。
• フリーズ期間（四半期末、ホリデーシーズン）中の変更：一時停止し、エンジニアリングマネージャーの承認を要求。

パイプラインは変更を評価し、該当するルールを適用して、続行するか一時停止するかを決定します。チームはどの変更にどの承認が必要かを覚えておく必要はありません。パイプラインが把握しています。

これが監査を容易にする理由

ガバナンスがパイプライン内に存在する場合、監査は簡単になります。監査人はメールのスレッドからスクリーンショットを収集したり、チケットのコメントを検索したりする必要はありません。特定の変更に関するパイプラインの履歴を見るだけです。記録には次の情報が含まれています。

• 誰が変更を行ったか
• 何が変更されたか
• どのテストが実行され、成功したか
• どのポリシーが評価されたか
• 誰がいつ変更を承認したか
• 変更がいつ本番環境に到達したか

すべてが一箇所にあります。すべての決定にはタイムスタンプと帰属があります。チームが主張したこととパイプラインが記録したことの間にギャップはありません。

ガバナンスをパイプラインに統合するための実践的なチェックリスト

承認ゲートとポリシールールの追加を始める前に、チームでこのチェックリストを実行してください。

• チームが行う変更の種類（設定、スキーマ、アプリケーションコード、インフラストラクチャなど）をリストアップする
• 各タイプについて、リスクレベル（低、中、高）を決定する
• 低リスクの変更には、自動デプロイを許可するポリシー・アズ・コードルールを記述する
• 中リスクの変更には、明確な承認基準を備えた手動承認ステップを追加する
• 高リスクの変更には、複数の承認または文書化された例外プロセスを要求する
• パイプラインツールで各レベルの変更を承認できる人を設定する
• 実際の変更でパイプラインをテストし、ゲートが期待通りに機能することを確認する
• 最初の数回のデプロイ後に監査証跡をレビューし、完全性を確認する

ガバナンスはアドオンではない

ガバナンスがパイプラインに統合されると、全員の速度を落とす余分なプロセスではなくなります。テストの実行やアーティファクトのビルドと同じように、通常のフローの一部になります。チームは低リスクの変更では迅速に動き、高リスクの変更では適切なレベルのレビューを得られます。監査証跡は自動的かつ完全です。

次に誰かが承認を求めてきたら、チケットを開かないでください。代わりにパイプラインにそれを要求させましょう。