技術的負債

技術的負債は、早く出すために後回しにした設計の歪みです。借金と同じで、すぐに困るわけではありませんが、放置すると「利子」として変更が遅くなり、障害が増えます。早く出すための負債は悪いことではなく、借りていることを知っていて、返す計画があるかどうかが大切です。

負債はユーザーからも経営からも見えにくいので、放っておくと必ず後回しになります。見える形にする（一覧にする・症状を数字にする・バックログに並べる）のが PdM の役目です。種類・説明の聞き方・投資の判断は、この章の続くトピックで扱います。

SLO とエラーバジェット

SRE の「ライブラリ・ランタイムのバージョン管理」

PdM と一緒に作るべきなのは右上の「慎重・わざと」の負債です。期限のために近道を選ぶなら、何を借りたかを記録し、返す時期を決めておきます。右下の「後から分かった」負債は、どれだけ気をつけても生まれるものです。

「負債を返したい」と言われたときは、反対も賛成もせず、症状と効果を聞きます。数字で比べられると、機能と同じ土俵で優先順位を付けられます。

経営に説明するときは、技術の言葉ではなく速さ・障害・費用・リスクの言葉に直します。「リファクタリングしたい」ではなく、「この改善で新機能を出す速さが倍になり、月2回の障害がなくなる」です。

返済の割合に公式の基準はなく、チームの状態で変わります。よく見られるのは、開発の時間の一定の割合（例えば1〜2割）を返済に充て続け、障害が続くときや SLO のエラーバジェットを使い切ったときは一時的に増やす、という形です。

負債も機能と同じバックログに並べ、効果の大きいものから選ぶと、「いつか直す」のまま残り続けるのを防げます。

SLO とエラーバジェット

負債が大きいと「全部作り直したい」という話が出ます。しかし一気の作り直しは、終わるまで新機能が止まり、古い仕組みの隠れた仕様を取りこぼし、予定よりずっと長引くことが多い、危険の大きいやり方です。

作り直しの提案には、「途中でやめたら何が残るか」「その間の機能開発はどうするか」を聞きます。少しずつ置き換える案なら、途中でやめても移した分の価値は残ります。

言語・フレームワーク・OS・DB などのソフトウェアにはサポート期間があり、終わること（EOL：End of Life）が事前に発表されます。EOL を過ぎると、脆弱性が見つかっても直されず、クラウドのサービスによっては古い版が使えなくなります。

バージョンアップはユーザーから見えにくい仕事ですが、遅れるとセキュリティ事故や急な作業になります。早めに枠を取るのが PdM の役目です。