業界知識：技術的負債と銀行の信用

技術的負債は、単なる汚いコードではない

技術的負債は、短期的な価値を先に得る代わりに、将来の変更・保守・障害対応で継続的な追加コストを払う状態を説明する比喩です。借金と同じように、元本だけでなく『利息』があります。

利息は、機能追加が遅くなる、変更のたびに障害が増える、担当者しか直せない、監査説明に時間がかかる、といった形で現れます。負債があること自体より、把握せず利息を払い続けることが危険です。

AI時代に増える、理解負債と認知負債

指定されたTechnical Debt Conference 2026の公開概要では、AIが解決手段になる一方で、『理解負債』『認知負債』を生む可能性がテーマとして挙げられています。カンファレンスは2026年9月開催予定のため、ここでは講演結果ではなく公開済みの問題提起を扱います。

業界では、負債を金額ではなくリスクで並べる

すべての負債を同時には返せません。金融システムでは『事故時の影響』『発生可能性』『検出しにくさ』『復旧しにくさ』『変更頻度』で優先順位を付けます。

SREの考え方：信用を測れる約束に変える

『安定している』という感覚だけでは運用判断ができません。業界では、利用者にとって重要な状態をSLIで測り、目標をSLOとして決めます。SLAは未達時の結果まで含む外部との合意です。

100%を無条件に目指すのではなく、許容できる失敗量をerror budgetとして定義します。budgetを消費しすぎたら新機能より安定性改善を優先するため、開発速度と信頼性を同じ数字で話せます。

金融システムに現れる、7種類の負債

負債はソースコードだけに発生するものではありません。データ、権限、運用、組織、外部サービスにも発生します。1つの対策だけでは返せないため、種類を分けてownerを決めます。

負債の『利息』を、観測できる数字にする

負債は抽象的なままだと、機能開発に負け続けます。そこで『この負債のために、毎月どれだけ時間・障害・手作業・待ち時間が増えているか』を測ります。厳密な金額でなくても、傾向が見えれば意思決定に使えます。

大量取引の業界知識：速さより、過負荷時の振る舞い

通常時に速いシステムでも、限界を超えると一気に遅くなるperformance cliffがあります。重要なのは最大件数だけでなく、限界へ近づいたときに待たせるのか、拒否するのか、後で処理するのかを事前に決めることです。

金融処理ではtimeout後に利用者が再送するため、過負荷がさらにretryを生み、障害を増幅するretry stormにも注意します。冪等性は二重計上を防ぎますが、無制限のretry負荷そのものを消すわけではありません。

変更を安全にする業界の手順

大規模障害の多くは、壊れていた機械より『変更』をきっかけに表面化します。金融システムでは、正しい完成形だけでなく、旧versionから新versionへ移る途中も安全に保つ必要があります。

1. 01ADR/RFCで目的・選択肢・risk・戻し方を記録
2. 02先に現在動作を固定するcharacterization testを作る
3. 03DB変更を後方互換にし、旧新両方が動く期間を設ける
4. 04少量の利用者・trafficから段階的にrelease
5. 05SLIと照合結果を見ながら拡大し、異常ならrollback
6. 06移行完了後に古い経路・権限・feature flagを削除

障害対応は、犯人探しではなく学習装置

incident responseは、影響を止め、利用者へ伝え、復旧し、データを検証する一連の活動です。復旧後にはpostmortemを作り、『誰が失敗したか』ではなく『なぜその操作が事故につながり、なぜ防御・検知・復旧が十分でなかったか』を調べます。

人は必ず間違えるため、注意力だけに頼る対策は長続きしません。二人承認、権限分離、自動制約、安全な既定値、訓練可能なrunbookへ変えることが再発防止です。

外部サービスとvendor lock-inも負債になる

Supabase、Vercel、認証provider、決済網など、外部サービスは開発を速くします。一方で、障害・値上げ・仕様変更・サービス終了・地域要件が自社だけでは制御できません。これは利用を避ける理由ではなく、依存を把握する理由です。

経営と現場が、同じ言葉で判断する

『コードをきれいにしたい』だけでは投資判断ができません。現場は負債を、顧客影響・事故risk・開発速度・運用費・規制対応へ翻訳します。経営は、受け入れるriskと投資優先順位を明示します。

3つの事故シナリオで考える

負債を返す、現実的な5段階

1. 01負債台帳へ、症状・影響・owner・期限・根拠を登録
2. 02利用者影響と金融不変条件からriskを評価
3. 03先にcharacterization testと観測点を追加
4. 04小さく分割し、互換性を保ちながら置き換える
5. 05SLO・incident・変更時間が改善したかを測定

Minibankで今から持つべき負債台帳

この台帳はコードの悪口一覧ではありません。事業と技術が、どのriskを受け入れ、いつ見直すかを共有するための意思決定記録です。