組織レベルで技術的負債をどのように管理しますか?

Question

Accepted Answer

組織レベルでは、技術的負債は「排除すべきバックログ」ではなく、**管理すべきポートフォリオ**です。目標はゼロの負債ではなく、負債がベロシティ、信頼性、戦略を実行する能力を脅かさないレベルに保つことです。

## なぜ重要なのか

```text
MAKE DEBT VISIBLE AND PRIORITIZED
- Inventory the debt that actually hurts (slows delivery, causes incidents)
- Classify: strategic (deliberate) vs accidental vs decay/rot
- Quantify impact in business terms (velocity, downtime, churn risk)
- Allocate a steady % of capacity to paydown (commonly 15-25%)
```

すべての負債が返済に値するわけではありません。安定していてめったに変更されないシステムの負債は放置できます。一方、ホットで急速に変化する領域の負債は最優先で返済すべきです。

## 具体例

CTOがルールを制定し、すべてのチームのキャパシティの20%を信頼性と負債に充てます。その後、すべてに薄く広げるのではなく、インシデントの80%を引き起こしている3つのシステムに焦点を当てます。

## トレードオフと落とし穴

- **落とし穴:** すべての負債をクリアするための「大規模な書き直し」。通常はスケジュール超過となり、新たな負債を再び生み出します。
- **落とし穴:** 負債をまったく返済しないこと。ベロシティが低下するまで。
- 負債をエンジニアリングのみの懸念として位置づけることは失敗します。ビジネス成果と結びつけることで、経営陣の買い入れを得られます。

## なぜ重要なのか

または管理されていない技術的負債は静かに蓄積され、機能の実装に数ヶ月かかり、インシデントが増加します。

これを意図的なポートフォリオとして管理することで、組織は数年間にわたって速度と信頼性を保つことができ、抽象的なエンジニアリングの懸念を、リーダーシップが検討できる定量化されたビジネス上のトレードオフに変えることができます。