フレームワーク活用ガイドひとことで言うと#
技術的負債がコードの問題なら、プロダクト負債はプロダクト全体の問題。使われない機能、一貫性のないUI、過去の妥協的な設計判断など、放置するとユーザー体験と開発スピードの両方を蝕むものを特定し、計画的に返済していく考え方。
押さえておきたい用語#
- 機能負債（Feature Debt）
- 使われていない機能や中途半端に実装された機能がプロダクトの複雑さとメンテナンスコストを増やしている状態を指す。
- UX負債（UX Debt）
- 一貫性のないUI、古いデザインパターン、壊れた導線などユーザー体験を損なう設計上の妥協が蓄積した状態を指す。
- 技術的負債（Technical Debt）
- 短期的な開発速度を優先して生まれたコードや設計の品質的な借金のこと。プロダクト負債とは別概念だが密接に関連する。
- 負債返済（Debt Repayment）
- 機能の削除・統合・改善を通じて蓄積した負債を計画的に解消していく活動のこと。スプリントの20%を充てるのが目安。
プロダクト負債の全体像#
こんな悩みに効く#
- 機能は増え続けているのに、ユーザー満足度が上がらない
- 新機能を追加するたびに、既存機能との整合性で苦労する
- 設定画面が迷路のようになってしまった
基本の使い方#
プロダクト内に潜む負債を洗い出す。以下のカテゴリで分類する。
- 機能負債: 使われていない機能、中途半端に実装された機能
- UX負債: 一貫性のないUI、古いデザインパターン、壊れた導線
- データ負債: 不正確な分析、計測されていない行動、不整合なデータ定義
- 戦略負債: プロダクトビジョンと矛盾する機能、ターゲット外のユーザー向け機能
利用データを使う: 過去90日で利用率5%未満の機能をリストアップするだけでも多くの負債が見つかる。
各負債が「今、どのくらいのコストを生んでいるか」を評価する。
- ユーザーへのコスト: 混乱、学習コスト、操作ミス
- 開発へのコスト: 新機能追加時のテスト工数、互換性維持、バグ発生頻度
- ビジネスへのコスト: サポート問い合わせ数、チャーン率への影響
定量化が難しくても概算で構わない。「この機能の存在によってサポートチケットが月20件発生している」レベルの見積もりで十分。
負債の返済方法を決める。
- 削除: 使われていない機能を廃止する（最も効果的だが最も抵抗が大きい）
- 統合: 似た機能を1つにまとめる
- 改善: 中途半端な実装を完成させる
- リデザイン: 設計をゼロからやり直す
「毎スプリントの20%をプロダクト負債の返済に充てる」 というルールが実践的。新機能開発と負債返済のバランスを明示的に管理する。
機能を削除する際の手順を標準化する。
- 利用データで影響範囲を確認する
- 影響を受けるユーザーに事前通知する（最低30日前）
- 代替手段を提示する
- 段階的に廃止する（まず非表示→一定期間後に削除）
「機能を追加するより削除するほうが勇気がいる」 が、長期的にはプロダクトをシンプルに保つことが最大の競争優位になる。
具体例#
棚卸し結果:
| カテゴリ | 負債 | 利用率 | 月間コスト |
|---|---|---|---|
| 機能負債 | CSV一括インポート（v1） | 3% | テスト工数: 毎月8時間 |
| 機能負債 | レガシーレポート機能 | 7% | バグ対応: 月2件 |
| UX負債 | 3種類の設定画面（統合されていない） | - | サポート問い合わせ: 月30件 |
| 戦略負債 | 個人ユーザー向け無料プラン機能 | 12% | インフラコスト: 月15万円 |
返済計画:
- CSV一括インポートv1: 新バージョンに移行済みのため削除（影響ユーザーに個別連絡）
- レガシーレポート: 新レポートへの移行ガイドを出して3ヶ月後に廃止
- 設定画面: 次のクォーターで1つに統合（デザインスプリントで設計）
- 個人向け機能: BtoBに集中する戦略なので段階的に縮小
結果（6ヶ月後）: 開発チームの「メンテナンス工数」が35%削減。新機能のリリースサイクルが2週間短縮。負債を返済した分だけ、新しい価値を届けるスピードが上がった。
ダウンロード数50万のフィットネスアプリが、リテンションの低下に対処した事例。
問題の発見:
- Day 30リテンション: 18%→12%に低下（6ヶ月間）
- App Storeレビュー: 「前より使いにくくなった」が増加
- 3年間で機能追加を重ねた結果、画面遷移パターンが5つに分散
UX負債の棚卸し結果:
| 負債 | 影響 | コスト |
|---|---|---|
| ナビゲーションが3パターン混在 | ユーザーが迷う | サポート問い合わせ月45件 |
| トレーニング記録UIが新旧2種類ある | 古いUIを使うと一部データが欠損 | バグ報告月12件 |
| 設定項目が42個（半分は使われていない） | 初期設定で離脱 | 新規ユーザーDay 1離脱率22% |
| 過去のキャンペーン導線が残っている | デッドリンクでエラー画面 | 月800回のエラー発生 |
返済アクション:
- ナビゲーションを1パターンに統一（2スプリント）
- 旧トレーニング記録UIを完全廃止し新UIに統一
- 設定項目を42→18に削減（使用率3%未満を削除）
- 過去のキャンペーン導線をすべて削除
結果（3ヶ月後）:
- Day 30リテンション: 12% → 20%
- 新規ユーザーDay 1離脱率: 22% → 11%
- サポート問い合わせ: 月45件 → 月12件
- App Storeレーティング: 3.8 → 4.3
新機能を足すのではなく、UX負債を引き算することでリテンションが回復した。ユーザーは「新しい機能」より「わかりやすい体験」を求めていた。
従業員35名の不動産会社が、10年間改修を重ねた社内物件管理システムの負債を整理した事例。
現状:
- 物件登録の入力項目: 128項目（業界標準は約50項目）
- 使われていない検索フィルター: 22個中14個が過去3ヶ月利用ゼロ
- 「以前の担当者が追加した」謎の機能が12個存在
- 新人が操作を覚えるまでに平均3週間（業界平均1週間）
負債の棚卸し:
- 機能負債: 物件登録の78項目は過去5年間一度も入力されていない
- UX負債: 画面レイアウトが5年前と3年前と現在で3パターン混在
- データ負債: 物件ステータスの定義が部署ごとに異なる（「商談中」「交渉中」「折衝中」が別ステータス）
返済計画:
- 入力項目を128→52に削減（過去1年間未使用の項目を非表示化）
- 検索フィルターを22→8に絞る
- 物件ステータスを12種類→6種類に統合（部署横断で定義を統一）
- 画面レイアウトを最新パターンに統一
結果（4ヶ月後）:
- 物件登録にかかる時間: 平均25分 → 平均8分
- 新人の業務習熟期間: 3週間 → 1週間
- データ不整合による確認作業: 月40時間 → 月5時間
- 営業担当の「システムへの不満」が全社アンケートで82% → 28%に低下
「壊れていないから触らない」は最大の罠。10年分の負債を棚卸しただけで、日常業務の効率が劇的に改善した。
やりがちな失敗パターン#
- 「いつか使うかもしれない」で機能を残す — データが証明しているなら削除する勇気を持つ。残すコストは見えにくいが、確実にプロダクトを重くしている
- 負債返済を「余裕があるとき」にやる — 余裕は永遠に来ない。スプリントの一定割合を負債返済に明示的にアロケーションする
- 技術的負債とプロダクト負債を混同する — コードのリファクタリングだけでは解決しない。「この機能は本当に必要か」というプロダクト視点の判断が必要
- 負債の棚卸しを一度きりで終わらせる — プロダクトは日々進化するため負債も増え続ける。四半期に一度の定期棚卸しをプロセスに組み込む
まとめ#
プロダクト負債は「目に見えない重り」。放置するとプロダクトは複雑になり、ユーザーは混乱し、開発チームは疲弊する。四半期に一度の棚卸しと、毎スプリントの計画的返済で、プロダクトを軽くシンプルに保つことが長期的な成長の鍵だ。「機能を足す」だけでなく「機能を引く」こともプロダクトマネジメントの重要な仕事。