予兆で検知し、返済の根拠をつくる
冒頭の問い、返済にいくら・何週間かかり、返済すると何が戻るかに答えるには、まず予兆で負債の増え方を捉え、可視化と運用の分け方をそろえる必要があります。測れないのではなく、どこを見て何を説明するかがそろっていない、というのが本回の答えです。
予兆検知・抑制・解消を分けて運用する
技術的負債は、予兆検知・抑制・解消の3つに分けて運用すると整理しやすくなります。予兆検知は、いつ手を打つかを決めるための定点観測です。抑制は、新しい負債の流入を止める仕組みで、スプリントごとにリファクタリングやライブラリ更新の工数が先に確保されているかを見ます。解消は、リプレイスも視野に入れて期限と体制を決め、既存チームで進めるか専門チームを切り出すかを選びます。この3つを混ぜて考えてしまうと、いつも火消しばかりで返済計画が立たないという状態に陥りやすくなります。
4観点で予兆を定点観測する
「技術負債の『予兆検知』と『状況異変』のススメ」ではプロダクトごとに勘所を決めて、次の4観点で検知する整理を示しています。
| 観点 | 読み方 | ||
| 1 | 計画と実績の差分 | 見積もりと実績のズレが四半期を通じて広がるなら、複雑性の蓄積を疑う | |
| 2 | 変更・レビュー時間の増加 | 同じ規模の変更でも開発やレビューに時間が伸びれば、属人化や理解の不足の兆候と考える | |
| 3 | 障害と再発防止策 | 件数だけでなく、再発防止策が追いついているか、同じ箇所を繰り返していないか確認する | |
| 4 | エンゲージメントの低下 | 障害対応やポストモーテムの負荷が士気を削っていないか確認する |
現場でも4つすべてを一度に追うより、プロダクトごとに当たりやすい2つを選んで四半期単位で定点観測するという進め方が現実的です。障害が多いサービスなら障害と再発防止策、リリース遅延が目立つなら計画と実績の差分から始められます。
静的解析と多角的な可視化
可視化の手段として静的解析ツールが使えます。循環的複雑度やコード重複率を自動算出し、修復に必要な工数として負債規模を共有できます。負債の利息を払う以前に、どこにどれだけあるかを把握しようとする活動自体が時間を消費するという点も重要です。静的解析やダッシュボードは贅沢ではなく、返済の議論の前提をそろえるための先行コストとして位置づけられます。
一方で限界もあります。設計の質やドメイン境界の崩れといったアーキテクチャ上の負債は静的解析だけでは捉えきれません。認知的負債も同様で、理解の不足はツールの出力には出てきません。運用が甘いと誤検知でトリアージに時間を取られます。Gitのコミットやプルリクエスト（PR）のライフサイクル、チケット、障害件数、見積もりと実績の差分をあわせて多角的に見る必要があります。レビュー待ち時間の伸びや、リリース直後のバグ割合の変化は、コード品質ツールだけでは説明しきれない予兆になります。
明日からできること
現場で取り組めるのは、次の3つです。
- プロダクトごとに4観点から2つを選び、四半期でトレンドを見る
- スプリント計画に返済工数を行として明示し、抑制が機能しているかを振り返る
- 静的解析や予兆の変化を1枚にまとめ、いま何が失われているかを上長との会話のたたき台にする
可視化は、開発側と事業側が同じ論点を共有するための共通言語です。
開発生産性の誤解について、体系的に解説した書籍が発売中です！
