チームとコードベースの技術的ヘルスをどのように測定し改善しますか?

Question

Accepted Answer

**Technical health** は、チームが持続可能な方法で成果を提供し、コード品質、システム信頼性、デリバリー速度を総合的に実現する能力です。測定しないものは改善できませんが、目標は *改善を促進するインサイト* であり、達成すべき数字ではありません。メトリクスは懐中電灯であり、スコアボードではありません。

## 何を測定するか

```text
DELIVERY (DORA metrics — well-researched, balanced):
  - Deployment frequency        - Lead time for changes
  - Change failure rate         - Time to restore service

QUALITY / RELIABILITY:
  - Production incident rate & severity
  - Test coverage trend (direction, not a vanity %)
  - Escaped-bug rate

TEAM / FLOW:
  - Cycle time, time-in-review (slow review = hidden bottleneck)
  - Recurring pain points (survey the team — they know)
```

## DORA を均衡的に使用

4つの DORA メトリクスが価値があるのは、*速度と安定性のバランス* を取るためです。一方を有利にすると他方が必ず損なわれます。高いデプロイ頻度と高い失敗率は勝利ではなく危険信号です。単一の数字ではなく全体を追跡してください。

## 具体的な例

Changes への Lead Time が徐々に増加しています。調べてみると、PR がレビューに数日滞留していることが分かります。メトリクスが本当のボトルネック、つまりレビュー プロセスの問題を指摘し、直感では気づかなかったはずです。プロセスを修正すれば、メトリクスが *副作用として* 改善します。

## 大きな落とし穴: ゲーミング

メトリクスが目標になった瞬間、人々は結果ではなく数字を最適化し始めます (グッドハートの法則)。カバレッジ目標は無駄なテストを生み、速度目標は水増しされた見積もりを生みます。メトリクスを使って *問題を見つけ* 、その後人々と対話してください。ランク付けや懲罰に使用しないでください。

## なぜ重要なのか

シグナルがないと、技術的ヘルスは目に見えないまま低下し、チームが不可解に遅くなり、誰も理由が分からなくなります。

適切な測定は見えないものを見えるようにし、重要な場所に投資でき、実行したときにその影響を証明できます。