ストーリー
田
田中VPoE
標準パイプラインとセキュリティの設計ができた。次は「ガバナンス」だ。20チームがこの基盤を使う以上、ルールと自由のバランスを取る仕組みが不可欠だ
あなた
ガバナンスというと、ルールを決めて守らせる、ということですか？
あ
田
田中VPoE
それは半分正解、半分不正解だ。ルールを決めるだけではチームは従わない。従いたくなる仕組みを作るんだ。ガバナンスの本質は「制約」ではなく「イネーブルメント」だ
あなた
チームが自発的に基準を守る状態を作る、ということですね
あ
田
田中VPoE
その通り。基準を守ることでチームの生産性が上がるなら、強制しなくても自然に採用される。そういう設計を目指す
なぜCI/CDガバナンスが必要か
ガバナンスなしの組織で起きること
| 時期 | 症状 | 影響 |
|---|---|---|
| 初期 | 各チームが自由にパイプラインを構築 | イノベーション速度は高い |
| 6ヶ月後 | ツールとプラクティスが多様化 | ナレッジの共有が困難に |
| 1年後 | セキュリティ基準のばらつき | インシデントリスクの増大 |
| 2年後 | 重複投資の蓄積 | コストが制御不能に |
| 3年後 | 組織全体の技術負債 | 変革が極めて困難に |
ガバナンスの3つの目的
| 目的 | 説明 | 例 |
|---|---|---|
| 一貫性 | 組織全体で統一された品質基準 | 全チームがセキュリティスキャンを実施 |
| 効率性 | 重複投資の排除と知識の共有 | 共有パイプラインライブラリ |
| コンプライアンス | 規制要件への自動的な準拠 | SOC2の監査要件を自動チェック |
ガバナンスモデルの選択
3つのモデル
| モデル | 特徴 | 適したケース | リスク |
|---|---|---|---|
| 中央集権型 | プラットフォームチームが全パイプラインを管理 | セキュリティ要件が厳格、チーム数が少ない | ボトルネック化、チームの不満 |
| 分散型 | 各チームが完全な裁量を持つ | チームの技術力が均一に高い | 標準化の欠如、セキュリティリスク |
| フェデレーション型 | 共通基盤 + チーム裁量の組み合わせ | 大規模組織、チームの成熟度にばらつき | 設計が複雑 |
推奨：フェデレーション型ガバナンス
フェデレーション型ガバナンス:
┌──────────────────────────────────────┐
│ プラットフォームチーム（中央） │
│ - 共通基盤の提供 │
│ - セキュリティポリシーの定義 │
│ - 共有ライブラリの管理 │
└────────────┬─────────────────────────┘
│ 提供
┌────────┼────────┬────────┐
↓ ↓ ↓ ↓
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│Team A│ │Team B│ │Team C│ │Team D│
│裁量: │ │裁量: │ │裁量: │ │裁量: │
│テスト │ │テスト │ │テスト │ │テスト │
│戦略 │ │戦略 │ │戦略 │ │戦略 │
│ビルド │ │ビルド │ │ビルド │ │ビルド │
│ツール │ │ツール │ │ツール │ │ツール │
└──────┘ └──────┘ └──────┘ └──────┘ガバナンスの実装レイヤー
レイヤー1: 必須（Must Have）
全チームが例外なく遵守すべきルール。
| ルール | 実装方法 | 強制度 |
|---|---|---|
| セキュリティスキャンの実施 | Reusable Workflowに組み込み | 自動強制 |
| 2名以上のPRレビュー | Branch Protection Rules | 自動強制 |
| シークレットスキャン | Organization設定 | 自動強制 |
| 監査ログの記録 | 共通基盤で自動収集 | 自動強制 |
レイヤー2: 推奨（Should Have）
チームに推奨するが、段階的に導入可能なルール。
| ルール | 実装方法 | 強制度 |
|---|---|---|
| テストカバレッジ80%以上 | CI品質ゲートで警告 | 警告 |
| Conventional Commits | commitlint | 推奨 |
| ドキュメント更新 | PRテンプレート | 推奨 |
レイヤー3: 任意（Nice to Have）
チームの裁量に委ねる領域。
| 領域 | 例 |
|---|---|
| テストフレームワーク | Jest, Vitest, pytest など |
| ビルドツール | Webpack, Vite, esbuild など |
| デプロイタイミング | 日次、週次 など |
| 追加の品質チェック | パフォーマンステスト、a11yチェック |
ガバナンスの成功指標
| 指標 | 目標 | 計測方法 |
|---|---|---|
| 標準パイプライン採用率 | 3ヶ月後80%、6ヶ月後100% | Reusable Workflow利用状況 |
| セキュリティゲート通過率 | 95%以上 | パイプライン実行ログ |
| パイプライン実行時間 | 30分以内 | CIメトリクス |
| 開発者満足度 | 7/10以上 | 四半期サーベイ |
| コンプライアンス監査工数 | 従来の50%削減 | 工数記録 |
「ガバナンスの成功は、チームが『使わされている』ではなく『使いたい』と感じているかどうかだ。定量指標だけでなく、開発者の声にも耳を傾けよう」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| ガバナンスの目的 | 一貫性、効率性、コンプライアンスの3つ |
| 推奨モデル | フェデレーション型（共通基盤 + チーム裁量） |
| 3レイヤー | 必須、推奨、任意で段階的に適用 |
| 成功指標 | 採用率、通過率、実行時間、開発者満足度 |
チェックリスト
- CI/CDガバナンスの必要性を理解した
- 3つのガバナンスモデルの違いを理解した
- フェデレーション型ガバナンスの設計を理解した
- ガバナンスの成功指標を理解した
次のステップへ
次は「共有パイプラインライブラリ」です。フェデレーション型ガバナンスを実現する技術的な基盤として、共有ライブラリの設計方法を学びましょう。
推定読了時間: 30分