複雑性削減を継続的な取り組みとして組み込む
ルール
複雑性削減を「いつかやる技術的負債」として先送りにしない。以下のように組み込む：
- スプリントの**20%**を複雑性削減（リファクタリング・削除・統合）に割り当てる
- 新しいコンポーネントを追加するときは「削除できるものはないか」を先に問う
- 「コードを追加したPR」と同等の評価で「コードを削除したPR」を称賛する文化をつくる
理由
複雑性には「外部性（externality）」の問題がある。新機能を追加した開発者はそのコストを払わず、後でそのシステムを運用・修正する人がコストを払う。
インセンティブのミスマッチを放置すると、複雑性は加速度的に増大する：
- 変更の影響範囲が読めなくなる
- 変更を恐れてリファクタリングを避ける
- 回避の結果さらに複雑になる
実践
- アーキテクチャレビュー：新コンポーネント追加時に「この責任は既存のどこかに置けないか」を必ず確認
- 定期的な依存関係の可視化：循環依存・不必要な依存を定期的にグラフ化
- 「削除OK」の判断基準を明文化：使われていないコード・設定を削除するための合意基準
例外
- 急速な成長フェーズでは複雑性が一時的に増えることを許容する（ただし「負債として認識する」こと）
- 外部ライブラリの複雑性は直接コントロールできない（インターフェース層で隔離する）
関連概念
- システム複雑性 — 複雑性の定義と計測方法
出典
Google SRE Workbook（Betsy Beyer他）第7章「Simplicity」