tech-debt-prioritizer

技術的負債の優先順位付け

技術的負債を体系的に優先順位付けし、解消します。

スコアリング基準

影響度スコア（1～10）

10 - 重大：

• 新機能の開発を妨げる
• 本番環境で頻繁にインシデントを引き起こす
• 複数のチームの作業を妨げる

7～9 - 高：

• 開発を大幅に遅らせる
• インシデントを時折引き起こす
• 1つのチームに大きな影響を与える

4～6 - 中：

• 開発にある程度の支障がある
• インシデントはまれ
• 回避策がある

1～3 - 低：

• 軽微な不便がある
• インシデントはない
• 簡単な回避策がある

リスクスコア（1～10）

10 - 重大：

• セキュリティの脆弱性
• データの整合性に関する問題
• 法務／コンプライアンス上のリスク

7～9 - 高：

• データ損失の可能性
• システムの不安定化
• ベンダーのサポート終了が近い

4～6 - 中：

• パフォーマンスの低下
• 障害が時折発生する
• 非推奨だが動作している

1～3 - 低：

• コード品質の問題
• 軽微なバグ
• スタイルの不統一

工数スコア（1～10）

10 - 莫大：

• 3か月以上
• 複数のチーム
• 高リスクの変更

7～9 - 大：

• 1～3か月
• 1つのチーム
• 中リスク

4～6 - 中：

• 1～4週間
• 開発者1～2名
• 低リスク

1～3 - 小：

• 数日
• 開発者1名
• ごく低リスク

優先順位の計算式

Priority Score = (Impact * 2 + Risk * 1.5) / Effort

Higher score = Higher priority

技術的負債の一覧

| ID     | Title                  | Impact | Risk | Effort | Score | Owner     |
| ------ | ---------------------- | ------ | ---- | ------ | ----- | --------- |
| TD-001 | Legacy auth system     | 9      | 10   | 8      | 3.7   | Auth Team |
| TD-002 | No database indexes    | 8      | 7    | 3      | 7.8   | Backend   |
| TD-003 | Monolithic build       | 7      | 4    | 6      | 4.0   | DevOps    |
| TD-004 | Duplicate API logic    | 6      | 3    | 4      | 4.1   | Backend   |
| TD-005 | Outdated dependencies  | 5      | 8    | 2      | 9.0   | All Teams |
| TD-006 | Missing error handling | 4      | 6    | 3      | 5.7   | Backend   |
| TD-007 | Poor test coverage     | 4      | 5    | 7      | 2.3   | All Teams |
| TD-008 | Inconsistent naming    | 3      | 2    | 5      | 1.6   | Frontend  |

**Sorted by Priority Score:**

1. TD-005: Outdated dependencies (9.0)
2. TD-002: No database indexes (7.8)
3. TD-006: Missing error handling (5.7)
4. TD-004: Duplicate API logic (4.1)
5. TD-003: Monolithic build (4.0)
   ...

詳細評価テンプレート

## TD-002: No Database Indexes

### Description

Critical queries lack indexes, causing slow response times and high CPU usage.

### Impact (8/10)

- Search queries take 2-5 seconds (should be <500ms)
- Database CPU at 85% during peak hours
- User complaints about slow searches
- Blocks performance optimization work

### Risk (7/10)

- Database may crash under load
- Losing customers to slow experience
- Cannot scale without addressing

### Effort (3/10)

- Identify missing indexes: 2 days
- Add indexes: 1 day
- Test performance: 1 day
- Deploy: 1 day
  **Total: 5 days**

### ROI Analysis

**Cost:** 5 developer-days = $5,000
**Benefit:**

- 80% faster queries
- 50% less DB CPU
- Better user experience
- Enables scaling

**ROI:** Very High

### Implementation Plan

1. Run EXPLAIN on slow queries
2. Identify missing indexes
3. Add indexes in development
4. Test query performance
5. Deploy to production (off-peak)
6. Monitor impact

### Dependencies

- None (can start immediately)

### Owner

Backend Team

### Status

Backlog → Prioritized for Q1

四半期ごとの解消計画

# Q1 2024 Tech Debt Paydown

**Budget:** 20% of engineering time (4 weeks total)

## Week 1-2: High Priority

- TD-005: Update dependencies (2 days)
- TD-002: Add database indexes (5 days)
- TD-006: Add error handling (3 days)

## Week 3: Medium Priority

- TD-004: Eliminate duplicate logic (5 days)

## Week 4: Quick Wins

- TD-012: Fix broken tests (2 days)
- TD-015: Remove dead code (2 days)
- TD-018: Update README (1 day)

## Success Metrics

- Reduce P1 incidents by 30%
- Improve deployment confidence
- Decrease development friction
- Team morale improvement

判断の枠組み

負債を解消するタイミング

今すぐ解消する場合：

• セキュリティの脆弱性がある
• 頻繁にインシデントを引き起こしている
• 重要な機能の妨げになっている
• 影響度が高く、工数が少ない

早めに解消する場合：

• 開発を大幅に遅らせている
• リスクが中～高程度である
• 工数が妥当である

先送りする場合：

• 影響度とリスクがともに低い
• 工数が非常に大きい
• より良い代替案がある

予算を増やすタイミング

**Indicators debt budget needs increase:**

- Velocity declining
- Incident rate increasing
- Developer satisfaction down
- Onboarding time increasing
- "It's too hard to..." complaints

技術的負債の台帳

interface TechDebt {
  id: string;
  title: string;
  description: string;

  // Scoring
  impact: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10;
  risk: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10;
  effort: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10;

  // Metadata
  owner: string;
  createdAt: Date;
  targetQuarter?: string;
  status: "backlog" | "prioritized" | "in-progress" | "done";

  // Context
  affectedSystems: string[];
  relatedDebt: string[];

  // Plan
  implementationPlan?: string;
  roi?: "low" | "medium" | "high" | "very-high";
}

四半期ごとのレビュー手順

1. **Collect new debt** (Week 1)

   - Team submits tech debt items
   - Engineering leads review and score

2. **Prioritize** (Week 2)

   - Calculate priority scores
   - Review high-priority items
   - Assign owners

3. **Plan quarter** (Week 3)

   - Allocate 10-20% capacity
   - Schedule work
   - Set success metrics

4. **Review results** (End of quarter)
   - Measure impact
   - Adjust process
   - Celebrate wins

ベストプラクティス

1. 体系的に記録する：記憶に頼らない
2. 客観的に評価する：基準を一貫して適用する
3. 定期的にレビューする：最低でも四半期ごとに実施する
4. 時間を確保する：スプリントのキャパシティの10～20％
5. 早く成果が出る項目を含める：士気を保つため、簡単な項目も含める
6. 影響を測定する：改善状況を追跡する
7. 可視化する：ダッシュボードやレポートを活用する
8. 責めない：技術的負債はあって当然

出力チェックリスト

• 技術的負債の項目を一覧化した
• 影響度／リスク／工数のスコアを割り当てた
• 優先順位スコアを計算した
• 優先順位に従って項目を並べた
• 上位10項目を詳しく記載した
• 四半期計画を作成した
• 予算（時間の割合）を割り当てた
• 担当者を割り当てた
• 成功指標を定義した
• レビューの頻度を設定した