ストーリー

技術負債とは

Martin Fowler の定義

“Technical Debt is a metaphor, coined by Ward Cunningham, that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”

技術負債は、短期的には楽だが長期的には追加コストを生む技術的判断の蓄積です。

負債のアナロジー

技術負債の四象限（Martin Fowler の分類）

技術負債を「意図的か/無意識か」と「慎重か/無謀か」の2軸で分類します。

graph TD
    subgraph Quadrant["技術負債の四象限（Martin Fowler）"]
        DP["意図的×慎重
Deliberate × Prudent
「出荷を優先し
後でリファクタリングする」"]
        IP["無意識×慎重
Inadvertent × Prudent
「後から振り返って
もっと良い方法があったと気づく」"]
        DR["意図的×無謀
Deliberate × Reckless
「設計する時間がないから
そのまま出す」"]
        IR["無意識×無謀
Inadvertent × Reckless
「レイヤリングって何？」"]
    end

    style DP fill:#d1fae5,stroke:#059669,color:#065f46
    style IP fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style DR fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style IR fill:#fee2e2,stroke:#dc2626,color:#991b1b

各象限の詳細

「組織として許容すべきは”意図的×慎重”だけだ。他の3つは、プロセスや教育で減らしていく必要がある」 — 佐藤CTO

技術負債の種類

コードレベルの負債

code_debt:
  - type: "設計の負債"
    examples:
      - "God Class（巨大クラス）"
      - "循環依存"
      - "レイヤー違反"
    detection: "静的解析ツール（SonarQube, CodeClimate）"

  - type: "コードの負債"
    examples:
      - "重複コード"
      - "マジックナンバー"
      - "過度に長いメソッド"
    detection: "Lintルール、コードレビュー"

  - type: "テストの負債"
    examples:
      - "テストカバレッジの不足"
      - "フレイキーテスト"
      - "テストの保守コスト"
    detection: "カバレッジレポート、CI失敗率"

アーキテクチャレベルの負債

architecture_debt:
  - type: "構造的負債"
    examples:
      - "モノリスの肥大化"
      - "不適切なサービス境界"
      - "データベースの共有"
    impact: "新機能追加の工数が指数的に増大"

  - type: "インフラの負債"
    examples:
      - "手動デプロイ"
      - "EOLのミドルウェア"
      - "スケーリングの限界"
    impact: "障害頻度の増加、復旧時間の増大"

  - type: "依存関係の負債"
    examples:
      - "古いライブラリバージョン"
      - "セキュリティパッチの未適用"
      - "非推奨APIの使用"
    impact: "セキュリティリスク、互換性問題"

プロセスレベルの負債

process_debt:
  - type: "ドキュメントの負債"
    examples:
      - "READMEが古い"
      - "APIドキュメントが未整備"
      - "設計書が現状と乖離"

  - type: "知識の負債"
    examples:
      - "特定の人しか理解していないコード"
      - "暗黙知への依存"
      - "オンボーディングの困難さ"

技術負債の可視化

技術負債レジストリ

組織の技術負債を一元管理するレジストリを作成します。

## 技術負債レジストリ

| ID | タイトル | 種類 | 象限 | 影響度 | 返済コスト | 利子率 | 優先度 |
|----|---------|------|------|--------|----------|--------|--------|
| TD-001 | 注文サービスのGod Class | コード | 無意識×慎重 | 高 | 3人週 | 高 | P1 |
| TD-002 | Jenkins CI/CD | インフラ | 意図的×慎重 | 中 | 5人週 | 中 | P2 |
| TD-003 | Python 3.8（EOL） | 依存関係 | 意図的×慎重 | 高 | 2人週 | 高 | P1 |
| TD-004 | APIドキュメント未整備 | ドキュメント | 無意識×無謀 | 中 | 4人週 | 低 | P3 |

利子率の定義

「利子率」は負債が日々どれだけの追加コストを生んでいるかの指標です。

技術負債のヒートマップ

コードベース全体を俯瞰し、負債の集中箇所を可視化します。

graph LR
    subgraph Heatmap["モジュール別の技術負債ヒートマップ"]
        O["注文サービス
負債: 高 / 変更頻度: 高 / 影響度: 高
← 最優先"]
        K["決済サービス
負債: 中高 / 変更頻度: 中 / 影響度: 高"]
        U["ユーザーサービス
負債: 中 / 変更頻度: 低 / 影響度: 中"]
        T["通知サービス
負債: 低 / 変更頻度: 低 / 影響度: 低"]
        R["レポートサービス
負債: 最高 / 変更頻度: 高 / 影響度: 低
← 変更頻度×負債で判断"]
    end

    style O fill:#fee2e2,stroke:#dc2626,color:#991b1b
    style K fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style U fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style T fill:#d1fae5,stroke:#059669,color:#065f46
    style R fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e

まとめ

チェックリスト

• 技術負債の四象限分類を理解した
• コード・アーキテクチャ・プロセスの各レベルの負債を理解した
• 技術負債レジストリの作成方法を把握した
• 利子率と優先順位付けの考え方を理解した

次のステップへ

次は「技術負債の定量化」を学びます。「なんとなく負債がある」を「具体的にXX人日のコスト」に変換する方法を見ていきましょう。

推定読了時間: 40分