チームにガバナンスが必要な理由（たとえその言葉が嫌いでも）
あなたのチームは、かつてないスピードで変更をリリースしている。週に数回だったデプロイが、今では1日複数回になっている。ユーザーは増え、プロダクトは改善され、順調に見える。
そんなある日、デプロイ後にログインページの読み込みが遅くなる。検索機能が突然使えなくなり、顧客からの報告で初めて気づく。こうしたインシデントが一度起きれば、ユーザーは許してくれる。しかし二度目が起きれば、信頼は揺らぎ始める。
一方で、別の側面もある。チームが「壊すこと」を過度に恐れ、すべての変更にシニアエンジニアのレビュー、ミーティング、3つの承認が必要になったとする。アバウトページのタイポ修正が本番に届くまで2日かかる。小さなバグ修正がレビュアーの忙しさでキューに滞留する。イノベーションは鈍り、チームはフラストレーションをためる。ユーザーは必要な修正を得られない。
これこそが、ガバナンスが解決しようとしているジレンマだ。官僚主義を増やしたり、すべてを遅くするようなガバナンスではない。変更を制御しつつ、スピードを犠牲にしないためのガバナンスである。
ワンサイズフィットオールの罠
多くのチームが陥るパターンがある。すべての変更に同じプロセスを適用することだ。すべてのプルリクエストにシニアレビューが必要。すべてのデプロイにミーティングが必要。すべての変更に複数人の承認が必要。
その論理は一見もっともに聞こえる。「慎重にやろう。壊したくない」。しかし結果は予測可能だ。小さな低リスク変更が、大規模なデータベースマイグレーションと同じパイプラインで詰まる。チームメンバーはプロセスを回避する方法を探し始める。公式ルートが遅すぎるため、金曜の夕方に直接本番にプッシュする。あるいは変更をため込み、何も壊れないことを願いながら一度に大量リリースする。
どちらの結果も良くない。前者は誰もレビューしていない無管理の変更を生む。後者はロールバックが困難な高リスクデプロイを生む。
リスクは変更ごとに異なる
アバウトページのタイポ修正とデータベーススキーマの変更は同じではない。ログレベルの設定変更と認証フローの修正は同じではない。これらを同じように扱うことは、必要のないことに時間を浪費し、本当に注意すべきことを無視することになる。
良いガバナンスはシンプルな考え方から始まる。変更にはそれぞれ異なるリスクレベルがあり、そのリスクレベルによって必要な精査の度合いが決まる。
低リスクの変更は迅速に進められる。テキスト修正、CSSの微調整、ドキュメントの更新。これらの変更が実際に深刻な問題を引き起こす可能性は低い。自動チェックに十分な自信があれば、軽量レビューや直接プッシュでも構わない。
中リスクの変更には、もう一人の目が必要だ。フィーチャーフラグの背後にある新機能、パフォーマンス最適化、振る舞いを変えないリファクタリング。これらの変更はコードレビューと自動テストの恩恵を受けるが、委員会は必要ない。
高リスクの変更には、より構造化されたプロセスが必要だ。データベースマイグレーション、インフラ変更、セキュリティパッチ、決済や認証ロジックの変更。これらの変更には、徹底的なレビュー、クリティカルパスをカバーする自動テスト、そして段階的なロールアウト計画が求められる。
重要なのは、これらのカテゴリを明確に定義し、チームが推測せずに行動できるようにすることだ。基準があいまいだと、人はすべてを過剰承認するか、逆に過小承認するかのどちらかになる。
ガバナンスの実際の姿
ガバナンスとは、共有ドライブに置かれたドキュメントではない。チームが日常的に直面する質問に対する実践的な答えの集合体だ。
- どの変更を直接デプロイできるか？
- どの変更が、誰かの確認を必要とするか？
- どの変更に、特定の人物やチームの承認が必要か？
- 変更をリリースする前に、どの自動チェックを通過しなければならないか？
- デプロイ後に問題が発生した場合、どう対処するか？
答えは複雑である必要はない。シンプルな表や決定木は、20ページのポリシードキュメントより効果的だ。目標はプロセスを予測可能にし、人が推測せずに迅速に動けるようにすることだ。
例えば、チームは次のように合意するかもしれない。データベーススキーマに触れる変更は、データモデルを理解している人のレビューが必要。デプロイパイプラインを変更する場合は、プラットフォームチームのレビューが必要。それ以外は通常のコードレビューと自動チェックで問題ない。
重要なのは、これらのルールが明示的であり、全員に知られていることだ。ルールが暗黙的だと、人は異なる前提を持ち、衝突が生じる。
本当の目標：信頼とスピード
ガバナンスとは、誰が最も権限を持つかではない。チームが、変更がユーザーに届く前に十分なチェックを経たことを確信できるかどうかだ。プロセスを信頼すれば、チームはより速く動く。信頼しなければ、速度を落とすか、プロセスを迂回するかのどちらかになる。
うまく設計されたガバナンスプロセスは、二つのことを同時に達成する。ユーザーを悪い変更から守り、チームを不必要な摩擦から守る。ログインページを高速に保ち、検索機能を可視化し続けながら、タイポ修正を数分でリリースできるようにする。
チームのための実践的チェックリスト
初めてガバナンスを設定するなら、次の質問から始めよう。
- 変更のリスクカテゴリは何か？（低、中、高）
- 各カテゴリに必要なチェックは何か？（自動テスト、コードレビュー、特定の承認者）
- 変更がどのカテゴリに属するかは誰が決めるか？（作成者、レビュアー、自動システム）
- 変更が問題を引き起こした場合、どうするか？（ロールバック手順、インシデント対応）
- これらのルールをどのくらいの頻度で見直し、更新するか？（四半期ごと、インシデント後）
これらの質問に答えることで、実用的なガバナンスモデルが得られる。初日から完璧である必要はない。全員が何をすべきか明確にわかることの方が重要だ。
まとめ
ガバナンスはスピードの障壁ではない。信頼を損なわずに高速に進むための仕組みだ。チームが各変更に必要なチェックを正確に理解していれば、推測も待ちもプロセスの迂回もなくなる。結果として、ユーザーを守りつつ、チームのデリバリー能力も保護するシステムができる。