技術的負債とは：プラットフォームエンジニアの視点から

技術的負債とは何かを理解するのに、教科書は必要ない。PagerDutyのアラートが午前3時に鳴った瞬間に、それは全部わかる。

デプロイは20分前に完了した。エラーレートは急上昇し、SLOバジェットは5分で枯渇しようとしている。ロールバックボタンに指を乗せながら、あなたは思う。「このサービス、最後に誰が触ったんだっけ？依存ライブラリのバージョンは？」

その問いへの答えが遅ければ遅いほど、blast radiusは広がる。それが技術的負債の実態だ。

技術的負債はコードの問題ではなく、デプロイリスクの問題だ

プラットフォームエンジニアやSREにとって、技術的負債とはコード品質スコアではない。それはデプロイのたびに複利で膨らむリスクであり、blast radiusを拡大させ、インシデントのpost-mortemに繰り返し登場する。

Ward Cunninghamが最初にこの概念を提唱したとき、意図したのは「意図的な設計のショートカット」だった。だが現代の分散システムにおいて、技術的負債はより広い範囲を指す。テスト戦略の欠如、依存関係の放置、ドキュメントのない設定変更、そして誰も理解していないマイクロサービスの連鎖。これらはすべて、次のインシデントへの借金だ。

負債の4分類：運用リスクで見る

すべての技術的負債が同じわけではない。以下の分類を使うと、バックログのトリアージが楽になる。

意図的な負債: リリース期限に合わせて意識的に選んだショートカット。返済計画があれば問題ない。なければ、それは単なる先送りだ。

不意の負債: 設計の甘さや知識不足から生まれる。当時は最善だと思っていた決断が、後になって問題化する。

腐敗した負債（Bit rot）: 何もしていないのに環境が変わって負債化する。EOLになったライブラリ、変更されたクラウドAPI、Kubernetesのバージョンアップ。

連鎖的な負債: あるコンポーネントの負債が、それに依存するすべてのチームに波及する。blast radiusの計算が最も難しく、最も危険な種類だ。

DORAメトリクスは技術的負債の先行指標だ

DORAの4指標、つまりデプロイ頻度、変更のリードタイム、変更障害率、MTTRは、インシデントが起きる前に負債の蓄積を教えてくれる。

DORAが40チームを対象に分析したところ、技術的負債が高いチームは変更障害率が平均3倍高く、MTTRは2.5倍長かった。数字は明確に語る。

具体的なシグナルを見る。デプロイ頻度が落ちているのは、エンジニアが何かを恐れているからだ。その「何か」は十中八九、技術的負債だ。変更のリードタイムが伸びているのは、変更を安全に加えることが難しくなっているサインだ。MTTRが30分を超え始めたとき、それは「理解可能性の負債」がある証拠だ。誰もそのサービスを素早く診断できない。

Datadogはインフラとアプリケーションのオブザーバビリティを提供する。デプロイのblast radiusをリアルタイムで把握し、SLOバジェットの燃焼レートを監視するのに向いている。技術的負債の「結果」を計測するツールとして位置づける。

技術的負債をインシデントと同じようにトリアージする

技術的負債をバックログに放置するのは、クリティカルアラートをsnoozeするのと同じだ。インシデントトリアージと同じフレームワークを使う。

P0（今すぐ対処）: セキュリティ脆弱性、EOLの依存関係、単一障害点となっているモジュール。これらは放置するたびに次のインシデントが起きやすくなる。

P1（次のスプリントで対処）: テストカバレッジがゼロの高頻度変更ファイル、手動でしかロールバックできないデプロイフロー。MTTR直結の問題だ。

P2（計画的に対処）: コードの重複、不要な抽象化、ドキュメント不足。blast radiusへの影響は小さいが、放置すれば積み上がる。

判断基準は「これが原因でインシデントが起きたとき、どのくらいのblast radiusになるか」だ。MTTRへの影響を想定して優先度を決める。

技術的負債を可視化するツール

負債は感覚では管理できない。計測が必要だ。

CodeSceneはコードの「ホットスポット」を特定する。変更頻度が高く、かつ複雑度が高いファイルを可視化する。同社の分析によると、40チームのコードベースでは、全技術的負債の68%がファイル全体の15%に集中していた。返済の優先順位を数値で決められる。

SonarQubeは静的解析でコード品質を継続的に計測する。セキュリティホットスポット、重複コード、複雑度の高い関数を検出し、CIパイプラインに組み込んで負債の増加を継続的に監視するのに向いている。

GitHub Copilotは直接的な負債計測ツールではないが、リファクタリングの摩擦を下げる効果がある。コンテキストを持ったコード補完はレガシーコードへの変更を安全に進める速度を上げ、返済コストを引き下げる。

SLOバジェットで負債を前倒し検知する

技術的負債の怖さは、問題が見えにくくなることだ。システムは「まだ動いている」が、その余裕はどんどん失われていく。

SLOバジェットのバーンレートを週次で追跡すれば、インシデントの4〜6週間前に異常を検知できることが多い。変更障害率が15%を超えたとき、それは「負債が高い」という明確なシグナルだ。

DORAメトリクスをダッシュボードに出して終わりにしてはいけない。それは計測器であって、目標ではない。計測器が示す値が、具体的なエンジニアリングアクションにつながっていることを確認する。

技術的負債との正しい向き合い方

技術的負債はゼロにならない。それを目指すのは間違いだ。

目標は「返済計画がある負債」と「把握されていない負債」を分けることだ。把握されていない負債が危険なのは、インシデントのpost-mortemで初めて発見されるからだ。計画された負債なら、返済のタイミングと優先度を自分たちでコントロールできる。

50〜500人規模のエンジニアリング組織では、四半期に一度の「技術的負債レビュー」をDORAメトリクスのレビューと組み合わせることを勧める。問う質問は一つだ。「今の負債レベルで、次のインシデントはどのくらい起きやすくなっているか？」

それがプラットフォームエンジニアリングにおける技術的負債の本質だ。コードの美しさの話ではなく、オペレーショナルリスクの管理の話だ。