ガバナンスがパイプラインを遅くするとき（そしてその修正方法）

パイプラインはグリーン。テストは自動でパス。ビルドは数分で完了。しかし、リリースしようとするたびに、誰かが別のチームからの承認を待っている。セキュリティ部門のチェックが必要。コンプライアンス部門の承認が必要。DBAからまだ返事が来ない。

これこそ、高速なパイプラインが低速なガバナンスと衝突する瞬間だ。そして、ボトルネックはパイプラインではなくなる。人間がボトルネックになるのだ。

本当の問題はガバナンスではない

どの組織にもルールは必要だ。実際のユーザーが使うアプリケーションを無造作に変更することはできない。ユーザーデータは保護されなければならない。データベーススキーマの変更にはレビューが必要だ。インフラストラクチャの変更は標準に従うべきである。

問題はルールの存在ではない。問題は、それらがどのように実施されるかにある。

ほとんどのチームでは、ガバナンスはパイプラインの外側に存在する。ルールはドキュメントに書かれ、チェックは手動で行われる。誰かがメールを送り、返信を待ち、それからようやくリリースを続行できる。手動チェックのたびに、数時間から数日の待ち時間が追加される。毎日リリースできるパイプラインが、週次または隔週のリリースになってしまう。

このパイプラインとガバナンスの分離は、隠れたキューを生み出す。パイプラインは「準備完了」と言っているが、実際のゲートはまだ受信箱を確認していない人間なのだ。

ガバナンスをパイプラインに組み込む

統合デリバリー運用モデルでは、ガバナンスはパイプラインの外側に立たない。パイプライン自体の一部となる。ルールは自動化された検証ゲートとなり、機能テストと並行して実行される。

実際の例を見てみよう。

次のフローチャートは、従来の手動ガバナンスモデルと統合パイプラインモデルを対比している：

あなたのチームには「データベーステーブルに影響する変更にはDBAのレビューが必要」というポリシーがあるとする。従来のモデルでは、開発者がメールを送り、返信を待ち、リリースが止まる。統合モデルでは、パイプラインがスキーマ変更を自動検出する。マイグレーションをdry-runモードで実行し、潜在的なデータ損失をチェックし、分析結果を添付してDBAに通知する。DBAは出力をレビューし、別のメールスレッドではなく、パイプライン内で直接承認する。

同じパターンは他の一般的なルールにも適用できる：

以下は、GitHub Actionsでデータベースマイグレーション承認ゲートを実装する実用的な例である：

name: Deploy
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and test
        run: make build test

  db-review:
    needs: build
    if: ${{ hashFiles('migrations/**') != '' }}
    runs-on: ubuntu-latest
    environment: db-approval
    steps:
      - uses: actions/checkout@v4
      - name: Run migration dry-run
        run: make migrate-dry-run
      - name: Check for data loss
        run: make check-data-loss
      - name: Notify DBA
        run: echo "Migration analysis complete. Waiting for approval."

  deploy:
    needs: [build, db-review]
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: make deploy

このワークフローでは、db-reviewジョブはmigrations/ディレクトリ内のファイルが変更された場合のみ実行される。dry-runマイグレーションを実行し、データ損失をチェックした後、db-approval環境を介して手動承認のために一時停止する。デプロイジョブは、ビルドとDBA承認の両方が完了するのを待つ。

• 依存関係に深刻な脆弱性が含まれていないこと
• コンテナイメージはデプロイ前にスキャンされていること
• 設定がセキュリティ標準に準拠していること
• インフラストラクチャの変更は最初にプランステージを通過すること
• シークレットがコードにハードコードされていないこと

これらのそれぞれが自動的に実行されるゲートになる。ゲートが失敗するとパイプラインは停止し、チームは何を修正すべきかを正確に把握できる。コンピュータがチェックできることを、誰かに手動レビューを依頼する必要はない。

リスクベースのガバナンス

このアプローチは、しばしばリスクベースのガバナンスと呼ばれる。チェックのレベルは変更のリスクに応じて調整される。

ドキュメントの更新？最小限のゲートで通過させる。ユーザーデータやコアビジネスロジックに触れる変更？より多くのゲートを通過させる。パイプラインは、誰が変更を行ったかではなく、何が変更されたかに基づいて審査のレベルを決定する。

これは、よくある緊張関係を解決するため重要だ。チームは迅速に動きたい。セキュリティとコンプライアンスのチームは問題を発見したい。すべての変更に同じ重いレビューを適用すると、両方の側が損をする。開発者はリリースの遅さに不満を感じる。セキュリティチームは手動レビューが多すぎて圧倒され、本当の問題を見逃す。

リスクベースのガバナンスは、両方の側が勝利できるようにする。低リスクの変更は迅速に進む。高リスクの変更は適切な審査を受ける。そしてパイプラインはルールを毎回一貫して実施する。

検証はテストよりも広い

「検証」と聞くと、多くの人は単体テストや統合テストを思い浮かべる。それらは検証の一部だが、全体像ではない。

このモデルにおける検証には、変更が安全で、準拠しており、本番環境に準備ができていることを保証するすべてが含まれる：

• 機能テスト：変更が正しく動作することを証明する
• セキュリティスキャン：脆弱性をチェックする
• ポリシーチェック：組織のルールを実施する
• コンプライアンスゲート：規制要件を検証する
• インフラストラクチャ検証：設定が正しいことを確認する

これらすべてが同じパイプライン内で、同じフレームワークの下で実行される。チームは別々のチェックを実行することを覚えておく必要はない。パイプラインが自動的に処理する。

各ロールの変化

ガバナンスがパイプラインの一部になると、全員の仕事が少し変わる。

開発者は承認を追いかける必要がなくなる。コードをプッシュし、パイプラインがチェックを実行し、何かが失敗すれば即座にフィードバックを得る。自動化できたはずのセキュリティレビューを何日も待つ必要はもうない。

セキュリティおよびコンプライアンスチームは、すべての変更を手動でレビューするのをやめる。ルールを定義し、検証ゲートとして記述し、ダッシュボードから結果を監視する。彼らの時間はルールの改善と例外処理に使われ、すべてのコード行を読むことには使われない。

DBAは分析結果が添付された構造化された通知を受け取る。すべてのマイグレーションを手動で検査する必要はない。パイプラインの出力をレビューし、明確な証拠に基づいて承認または拒否する。

エンジニアリングマネージャーは、リリースがなぜブロックされているかを可視化できる。パイプラインはどのゲートが失敗し、何を修正すべきかを正確に示す。遅延が技術的なものなのか手続き上のものなのかを推測する必要はもうない。

始めるための実践的なチェックリスト

ガバナンスをパイプラインに移行したい場合、最初のステップは次の通り：

• リリースを遅くしている上位3つの手動承認ゲートを特定する
• 各ゲートについて、「このチェックは自動化できるか？」と問いかける。できるなら、パイプラインステップとして記述する
• 人間の判断が必要なゲートについては、単なる通知ではなく、構造化された証拠を提供するようにパイプラインを設計する
• パターンが機能することを証明するために、低リスクの変更から始める
• リスクベースのロジックを徐々に追加する：単純な変更は重いゲートをスキップし、複雑な変更はより多くのゲートを通過する

まとめ

ガバナンスと検証は同じフレームワークに属する。それらが分離されると、ガバナンスはボトルネックになる。それらが結合されると、ルールは一貫して実施され、リリースはより速く進み、すべてのチームメンバーは待つ時間を減らし、構築する時間を増やす。パイプラインはソフトウェアを届けるだけではない。自信も届けるのだ。