フレームワーク活用ガイドひとことで言うと#
「今は時間がないからこの書き方で」という技術的な妥協の蓄積を「負債」と捉え、可視化して計画的に返済するマネジメント手法。放置すると利子（開発速度の低下）が雪だるま式に増える。
押さえておきたい用語#
- 技術的負債（Technical Debt）
- 短期的な速度を優先して蓄積した設計・実装上の妥協のこと。金融の負債と同様に、放置すると「利子」として開発速度の低下が加速する。
- 利子（Interest）
- 技術的負債があることで発生する追加の開発コストや時間のこと。「この修正、本来1日で終わるのに負債のせいで3日かかる」の「追加の2日分」が利子。
- ボーイスカウトルール
- 「来た時よりもきれいにして帰る」という原則を指す。機能開発のついでに、触ったコードの周辺を少し改善する習慣。
- リファクタリング
- 外部から見た振る舞いを変えずに、コードの内部構造を改善する作業のこと。技術的負債の「返済」にあたる具体的な行動。
- 静的解析（Static Analysis）
- コードを実行せずにソースコードの問題点を検出するツール・手法である。SonarQubeやESLintが代表例。負債の可視化に使う。
技術的負債管理の全体像#
こんな悩みに効く#
- 機能追加のたびに予想の2〜3倍の時間がかかるようになった
- 「触ると壊れそうなコード」が増えて、誰も手を出せない
- ビジネス側に「なぜこんなに遅いのか」を説明できない
基本の使い方#
現在の負債を洗い出し、リスト化する。
- コードベースの中で「ここは問題がある」と全員が知っている箇所を集める
- 静的解析ツール（SonarQube等）の結果を活用する
- カテゴリ分け: 設計負債、コード負債、テスト負債、インフラ負債、ドキュメント負債
ポイント: 「なんとなく遅い」を「具体的にどこが問題か」に変換する。
各負債の「利子の大きさ」と「返済の難易度」を見積もる。
- 影響度: この負債があることで、毎週どのくらい追加の時間がかかっているか
- 返済コスト: この負債を解消するのにどのくらいの工数が必要か
- リスク: 放置した場合に障害やセキュリティ問題につながる可能性
ポイント: 影響度が高く返済コストが低いものが、最優先の返済対象。
スプリントの中に負債返済の時間を組み込む。
- スプリントの10〜20%を負債返済に充てるルールを作る
- 大きな負債は段階的に返済する（ストラングラーパターン）
- 新機能開発のついでに、周辺の負債を返済する（ボーイスカウトルール）
ポイント: 「余った時間で返済」は永遠に来ない。予算として確保すること。
具体例#
状況: 従業員40名のBtoB SaaS企業。創業5年目でプロダクトが成長期に入ったが、機能追加のたびに「予想の2.5倍の時間がかかる」状態に。エンジニア12名の体感では「コードベースの30%が触りたくないコード」。
負債の洗い出し:
| # | 負債 | カテゴリ | 影響度 | 返済コスト |
|---|---|---|---|---|
| 1 | 注文処理が1つの2,000行のクラスに集約 | 設計負債 | 高 | 高（3週間） |
| 2 | ユーザー認証がフレームワークの非推奨メソッドに依存 | インフラ負債 | 中 | 中（1週間） |
| 3 | 商品検索のテストカバレッジが10% | テスト負債 | 中 | 中（2週間） |
| 4 | エラーハンドリングがcatch(e) {}で握りつぶし | コード負債 | 高 | 低（2日） |
返済計画:
- 今スプリント: エラーハンドリングの修正（影響度高・コスト低で即効性あり）
- 次の2スプリント: 認証のアップデート（セキュリティリスク解消）
- 今後3ヶ月: 注文処理クラスの段階的分割（新機能追加のついでに少しずつ）
- 継続: 商品検索のテスト追加（新しいコードを書くたびにテストも追加）
| 指標 | Before | After（6ヶ月後） |
|---|---|---|
| 機能追加の平均工数 | 見積もりの2.5倍 | 見積もりの1.2倍 |
| 本番障害（月間） | 3.8件 | 1.1件 |
| エンジニア満足度 | 10点中4.2 | 10点中7.1 |
機能追加の工数、見積もりの2.5倍→1.2倍。本番障害は月3.8件→1.1件。影響度が高くコストが低い負債から手をつけたこと、そしてスプリントの20%を返済に確保したことが効いた。
状況: 従業員25名の医療系スタートアップ。急成長期に「スピード最優先」で開発を進めた結果、テストカバレッジ15%、ドキュメントほぼゼロ、デプロイ手順が属人化。CTOが退職し、残ったエンジニア6名が「何がどう動いているかわからない」状態に。ビジネス側は「新機能を早く出せ」の一点張り。
ビジネス側への説明方法:
- 「機能Aの開発、本来2週間で終わるが負債のせいで5週間かかっている。差分の3週間×人件費 = 月150万円の無駄」
- 「テストがないため本番障害が月4回。障害対応で月40時間（= 2人日/週）が消える」
- 「今の速度低下を放置すると、半年後にはさらに50%遅くなる見込み」
合意した返済計画:
- 毎スプリントの20%（週2日分）を負債返済に確保
- 四半期ごとに「負債ダッシュボード」をビジネス側にレポート
- 3ヶ月後に開発速度の改善を数字で証明する
| 指標 | Before | After（3ヶ月後） |
|---|---|---|
| テストカバレッジ | 15% | 48% |
| 本番障害（月間） | 4回 | 1.5回 |
| 機能開発のリードタイム | 平均5週間 | 平均3週間 |
| デプロイ頻度 | 月2回 | 週1回 |
リードタイム5週間→3週間、デプロイ頻度月2回→週1回。「負債のせいで月150万円の無駄」と金額で説明したことで、ビジネス側から返済の時間と予算を正式に引き出せた。
状況: 従業員350名の金属加工メーカー。IT部門4名で運用する生産管理システムはAccess + VBAで20年前に構築。VBAマクロが1,200個、ドキュメントはゼロ。開発者は退職済みで、現IT部門は「触ると壊れる」と恐れて一切手を入れていない。月間の手動入力ミスによる出荷エラーが平均8件。
負債の分類と返済順序:
| 優先度 | 負債 | 返済方法 | 期間 |
|---|---|---|---|
| 1 | 手動入力がミスの温床 | バーコードスキャン導入 | 2ヶ月 |
| 2 | VBAマクロが属人化 | 主要30個のマクロをPythonに移植 | 4ヶ月 |
| 3 | Accessの同時接続制限 | PostgreSQLに段階移行 | 6ヶ月 |
| 4 | ドキュメントゼロ | 移植しながらドキュメント作成 | 継続 |
| 指標 | Before | After（1年後） |
|---|---|---|
| 月間出荷エラー | 8件 | 1.2件（85%削減） |
| VBA属人化リスク | 1,200マクロ | 残450マクロ（62%移植完了） |
| システム障害 | 月2回 | 月0.3回 |
| ドキュメント化率 | 0% | 主要機能の65% |
出荷エラー月8件→1.2件。VBA 1,200マクロのうち62%をPythonに移植完了。全部作り直すのではなく、最も痛い部分から手をつける——完璧を目指さず「利子が払える範囲に収める」発想が大事。
やりがちな失敗パターン#
- 負債を「見えない問題」のまま放置する — ビジネス側に伝わらないので予算がつかない。「負債のせいで機能Xの開発に追加で2週間かかっている」のように金額や時間で説明する
- 全部一気に返済しようとする — 「リファクタリング週間」を設けて全面書き換え → 新しいバグを大量に生む。段階的に、テストを書きながら少しずつ返済する
- 負債を増やさないルールがない — 返済しながら別の場所で負債を増やしている。新しいコードは負債を増やさない基準（テスト必須、レビュー必須等）を設ける
- 返済の効果を計測しない — 返済に時間を使っているが効果が見えず、ビジネス側から「無駄では？」と言われる。開発速度・障害件数・テストカバレッジを定期的に計測し改善を証明する
まとめ#
技術的負債は避けられないが、管理できる。大事なのは可視化して、ビジネス側と合意の上で計画的に返済すること。「毎スプリント20%は負債返済に使う」 のようなルールを作り、開発速度の低下を防ごう。負債を完全にゼロにする必要はない。利子が払える範囲に収めることが目標。