システム複雑性
定義
SREの文脈での「複雑性」とは、システムを理解・変更・運用することの困難さ。以下のいずれかが当てはまる状態：
- コンポーネントの依存関係が多く、変更の影響範囲が読めない
- 同じ設定が複数箇所に分散していて、どこが真実かわからない
- 新しいメンバーがシステムを理解するのに数ヶ月かかる
- 機能追加のたびに予期しない場所が壊れる
なぜ重要か
複雑性には「外部性（externality）」という問題がある。複雑性を導入した人（例：新機能を追加した開発者）はそのコストを払わず、別の人（例：オンコール担当のSRE）がコストを払う。
このインセンティブのミスマッチが、意図しない複雑性の蓄積を招く。
複雑性は放置すると指数的に増大する：
- 依存関係が増えるほど、各変更の影響範囲が広がる
- 広い影響範囲が怖くて小さなリファクタリングを避けるようになる
- 避けた結果さらに複雑になる（悪循環）
複雑性の計測方法
定性的な指標：
- 新しいエンジニアがオンコールできるようになるまでの期間
- ある変更を加えたとき、影響を受ける可能性のあるコンポーネント数
- 設定ファイルの数と種類の多様性
適用場面
- アーキテクチャレビューで「追加してよいか」を判断するとき
- オンボーディングが長期化しているとき
- 障害の根本原因が「複雑すぎて予測できなかった」であったとき
複雑性削減の戦略
- 定期的な複雑性負債の返済をスプリントに組み込む
- 追加時にコストを払わせる — 新コンポーネント追加には設計レビューを必須にする
- シンプルさを評価する — 「機能を削除した」PRをポジティブに評価する文化
- 依存関係グラフを可視化して循環依存を定期的に解消する
関連ルール
出典
Google SRE Workbook（Betsy Beyer他）第7章「Simplicity」