# 技術的負債とは：プラットフォームエンジニアの視点から URL: https://upstreamapi.com/ja/journal/technical-debt-toha Type: blog Locale: ja Published: 2026-09-26 Updated: 2026-09-26 --- > プラットフォームエンジニアにとって、技術的負債とはコード品質スコアではない。デプロイのたびに複利で膨らむリスクであり、DORAメトリクスが先行指標となる。 技術的負債とは何かを理解するのに、教科書は必要ない。PagerDutyのアラートが午前3時に鳴った瞬間に、それは全部わかる。 デプロイは20分前に完了した。エラーレートは急上昇し、SLOバジェットは5分で枯渇しようとしている。ロールバックボタンに指を乗せながら、あなたは思う。「このサービス、最後に誰が触ったんだっけ？依存ライブラリのバージョンは？」 その問いへの答えが遅ければ遅いほど、blast radiusは広がる。それが技術的負債の実態だ。 ## 技術的負債はコードの問題ではなく、デプロイリスクの問題だ プラットフォームエンジニアやSREにとって、技術的負債とはコード品質スコアではない。それはデプロイのたびに複利で膨らむリスクであり、blast radiusを拡大させ、インシデントのpost-mortemに繰り返し登場する。 Ward Cunninghamが最初にこの概念を提唱したとき、意図したのは「意図的な設計のショートカット」だった。だが現代の分散システムにおいて、技術的負債はより広い範囲を指す。テスト戦略の欠如、依存関係の放置、ドキュメントのない設定変更、そして誰も理解していないマイクロサービスの連鎖。これらはすべて、次のインシデントへの借金だ。 ## 負債の4分類：運用リスクで見る すべての技術的負債が同じわけではない。以下の分類を使うと、バックログのトリアージが楽になる。 **意図的な負債**: リリース期限に合わせて意識的に選んだショートカット。返済計画があれば問題ない。なければ、それは単なる先送りだ。 **不意の負債**: 設計の甘さや知識不足から生まれる。当時は最善だと思っていた決断が、後になって問題化する。 **腐敗した負債（Bit rot）**: 何もしていないのに環境が変わって負債化する。EOLになったライブラリ、変更されたクラウドAPI、Kubernetesのバージョンアップ。 **連鎖的な負債**: あるコンポーネントの負債が、それに依存するすべてのチームに波及する。blast radiusの計算が最も難しく、最も危険な種類だ。 ![エンジニアリングチームがアーキテクチャを見直し、リファクタリング計画を立てている様子](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/4fe267-img-2.webp) ## 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への影響を想定して優先度を決める。 ![開発者が複数のエラーログを確認しながら複雑なレガシーコードをレビューしている様子](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/311630-img-3.webp) ## 技術的負債を可視化するツール 負債は感覚では管理できない。計測が必要だ。 CodeSceneはコードの「ホットスポット」を特定する。変更頻度が高く、かつ複雑度が高いファイルを可視化する。同社の分析によると、40チームのコードベースでは、全技術的負債の68%がファイル全体の15%に集中していた。返済の優先順位を数値で決められる。 SonarQubeは静的解析でコード品質を継続的に計測する。セキュリティホットスポット、重複コード、複雑度の高い関数を検出し、CIパイプラインに組み込んで負債の増加を継続的に監視するのに向いている。 GitHub Copilotは直接的な負債計測ツールではないが、リファクタリングの摩擦を下げる効果がある。コンテキストを持ったコード補完はレガシーコードへの変更を安全に進める速度を上げ、返済コストを引き下げる。 ## SLOバジェットで負債を前倒し検知する 技術的負債の怖さは、問題が見えにくくなることだ。システムは「まだ動いている」が、その余裕はどんどん失われていく。 SLOバジェットのバーンレートを週次で追跡すれば、インシデントの4〜6週間前に異常を検知できることが多い。変更障害率が15%を超えたとき、それは「負債が高い」という明確なシグナルだ。 DORAメトリクスをダッシュボードに出して終わりにしてはいけない。それは計測器であって、目標ではない。計測器が示す値が、具体的なエンジニアリングアクションにつながっていることを確認する。 ## 技術的負債との正しい向き合い方 技術的負債はゼロにならない。それを目指すのは間違いだ。 目標は「返済計画がある負債」と「把握されていない負債」を分けることだ。把握されていない負債が危険なのは、インシデントのpost-mortemで初めて発見されるからだ。計画された負債なら、返済のタイミングと優先度を自分たちでコントロールできる。 50〜500人規模のエンジニアリング組織では、四半期に一度の「技術的負債レビュー」をDORAメトリクスのレビューと組み合わせることを勧める。問う質問は一つだ。「今の負債レベルで、次のインシデントはどのくらい起きやすくなっているか？」 それがプラットフォームエンジニアリングにおける技術的負債の本質だ。コードの美しさの話ではなく、オペレーショナルリスクの管理の話だ。 ## FAQ ### 技術的負債とは何ですか？ 技術的負債とは、開発の効率化やリリース速度を優先した結果として蓄積される設計・実装上の問題の総称です。コードの問題だけでなく、テスト不足、ドキュメント欠如、依存関係の陳腐化も含まれます。放置するとデプロイリスクが複利で膨らみます。 ### 技術的負債はなぜプラットフォームエンジニアリングで重要なのですか？ プラットフォームエンジニアにとって、技術的負債はblast radiusの拡大とMTTRの長期化に直結します。インシデント発生時の診断速度とロールバックの安全性が低下し、post-mortemで繰り返し同じ原因が登場するようになります。 ### DORAメトリクスはどのように技術的負債を検知しますか？ デプロイ頻度の低下、変更のリードタイムの増加、変更障害率の上昇、MTTRの長期化は、いずれも技術的負債が高まっているサインです。DORAのデータによると、負債の高いチームは変更障害率が平均3倍高く、MTTRは2.5倍長くなります。 ### 技術的負債のトリアージはどうすればいいですか？ インシデントトリアージと同じフレームワークを使います。P0はセキュリティ脆弱性とEOLの依存関係、P1はテストカバレッジがゼロの高頻度変更ファイルと手動ロールバック必要なフロー、P2は重複コードとドキュメント不足です。判断基準は常に「このblast radiusはどのくらいか」です。 ### 技術的負債を測定するためのツールは何がありますか？ Datadogはオブザーバビリティとblast radiusのリアルタイム把握に有効です。CodeSceneは変更頻度と複雑度の高いホットスポットを可視化します。SonarQubeはCIパイプラインに組み込んで静的解析で負債の増加を継続監視できます。GitHub Copilotはリファクタリングの摩擦を下げることで返済コストを引き下げます。 ### SLOバジェットと技術的負債はどのような関係がありますか？ SLOバジェットのバーンレートを週次で監視することで、インシデントの4〜6週間前に技術的負債の影響を検知できることが多いです。変更障害率が15%を超え始めたとき、それは負債レベルが高いという明確なシグナルです。SLOは負債の先行指標として機能します。 ### 技術的負債をゼロにする必要がありますか？ いいえ。技術的負債をゼロにすることは現実的でも目標でもありません。重要なのは「返済計画がある負債」と「把握されていない負債」を分けることです。把握されていない負債こそが危険であり、post-mortemで初めて発見されるタイプの障害原因になります。