第8章 技術的負債
本章では、ソフトウェア開発において避けては通れない「技術的負債」という考え方と、それがなぜ起きるのか、そしてスクラムを用いてどのように管理・返済していくべきかについて解説します。
8.1 概要
Section titled “8.1 概要”「技術的負債」という考え方は、Ward Cunninghamによって初めて提唱されました。
- 最初のコードを世に出すことは、負債を抱えることに似ています。すぐに返済（リファクタリングなど）できるなら、開発速度を上げるのに役立つ「戦略的な負債」となり得ます。
- しかし、正しくないコードを放置すれば「利息」がつき、未整理の作業が貯まり続ければ、組織全体が身動きの取れない状態に陥ってしまいます。
技術的負債には、以下のようなものが含まれます。
- 不適切な設計
- 不具合（バグ）の放置
- 不十分なテストカバレッジ
- 手動テストの横行（本来は自動化すべき部分）
- 貧弱なインテグレーションやリリース管理
- プラットフォームや対象領域に関する経験の欠如
8.2 技術的負債の行く末
Section titled “8.2 技術的負債の行く末”技術的負債が増えれば増えるほど、その影響はより深刻になり、以下のような事態を引き起こします。
- デリバリーに要する時間の長期化: 負債が増えれば増えるほど、機能追加にかかる時間が増大し、チームのベロシティは著しく低下します。
- 不具合の多発: システムが脆くなり、変更を加えるたびに別の場所で致命的な障害（デグレード）を引き起こすようになります。
- 開発およびサポートのコストの増加: かつてはシンプルだった作業が複雑になり、トラブルシューティングや顧客サポートに莫大なコストがかかるようになります。
- 予測可能性の減少: 隠れた負債の影響により、作業の見積もりがまったく当たらなくなります。
- 募る不満: プロダクトの品質低下は、顧客の不満だけでなく、技術者から働く楽しみを奪い、開発チームの士気とモチベーションをどん底まで下げてしまいます。
8.3 技術的負債を生む要因
Section titled “8.3 技術的負債を生む要因”技術的負債は、主に以下のような原因から生み出されます。
- 納期を守るためのプレッシャー: 経営層などからの「指定の納期までにすべてを終わらせろ」という強い圧力が、無理な開発を強要します。
- ベロシティの偽装: スコープを削ることが許されない状況で、チームは意図的に「テストや設計を省く」という決断（手抜き）をしてしまいます。これにより、見かけ上のベロシティは維持されますが、背後で巨大な負債が蓄積します。
- 「テストを減らせばベロシティが向上する」という神話: テストを減らすことで短期的にはコストを抑えられるという誤った信念です。実際にはテスト駆動開発（TDD）などの優れた手法を用いた方が、不具合の修正コストが激減し、結果的に高いベロシティを保つことができます。
- 負債が生む新たな負債: 既存の技術的負債の上に乗っかる形で新機能を開発すると、さらに負債が雪だるま式に膨れ上がります。
8.4 技術的負債の管理（予防と認識）
Section titled “8.4 技術的負債の管理（予防と認識）”技術的負債の管理は、ビジネスの要求と技術的な品質のバランスを取るための重要な作業であり、まずはナイーブな（無自覚な）技術的負債を増やさないための予防措置をとります。
- 優れた技術的プラクティスの活用: 継続的インテグレーション（CI）、自動テスト、テスト駆動開発（TDD）、リファクタリングなどを標準のプロセスとして組み込みます。
- 厳しい「完成の定義」の使用: チーム全体で合意した強固な「完成の定義（DoD）」を適用し、テストが不十分なコードや要件を満たしていないコードがスプリントを通過するのを防ぎます。
- 技術的負債の経済的意味についての適切な認識: 負債を戦略的に有効活用するには、それがもたらす「利息（将来のコスト増）」を正しく認識する必要があります。最初は開発が早く進んでも、数ヶ月後にはバグ対応やコードの複雑化により、結果的に総コストが大きく跳ね上がることを理解すべきです。
8.5 技術的負債の可視化
Section titled “8.5 技術的負債の可視化”技術的負債という見えにくいものを、組織やチームが認識できるように可視化する必要があります。
- ビジネスレベルでの可視化: 経営陣には「コードが汚い」と言っても伝わりません。負債が原因で低下したベロシティや、サポート対応にかかる遅延コストなど、ビジネスへの影響を時間や金額（財務諸表のような形式）で可視化して伝えます。
- 技術者レベルでの可視化: 開発現場では、技術的負債をバグトラッキングシステムに記録するか、プロダクトバックログに「技術的負債のアイテム（PBI）」として追加することで、他の機能開発と同じように視覚化し管理します。
8.6 技術的負債の返済
Section titled “8.6 技術的負債の返済”抱えてしまった技術的負債をどのように返済（リファクタリングなど）していくべきか、いくつかの重要なルールがあります。
すべての技術的負債を返済すべきというわけではない
Section titled “すべての技術的負債を返済すべきというわけではない”以下のようなケースでは、負債を返済するための投資が経済的に無意味になるため、返済しなくてよいと判断されます。
- 製品の寿命が近づいており、間もなくリプレイスされるシステム。
- 検証のためだけに作られた使い捨てのプロトタイプ。
- イベント用など、短期間しか使われないプロダクト。
ボーイスカウトのルールに従う
Section titled “ボーイスカウトのルールに従う”「キャンプ場を去るときは、来たときよりも美しくして去る」というルールです。開発中に見つけた小さな負債（コードの乱れなど）は、別途チケットを切るのではなく、その作業のついでにその場で返済（リファクタリング）してしまいます。
技術的負債の返済はインクリメンタルに
Section titled “技術的負債の返済はインクリメンタルに”「リファクタリング専用スプリント」のような、負債の返済しかしない期間を設けるのは危険です。代わりに、各スプリントのキャパシティの一定割合（例えば10%など）を負債の返済に割り当て、毎回のスプリントで少しずつ（インクリメンタルに）返済していくべきです。
金利の高い技術的負債から返済する
Section titled “金利の高い技術的負債から返済する”すべての負債が同じ利息を生むわけではありません。頻繁に新機能を追加する箇所や、不具合が多発している箇所にある負債は「金利が高い」ため、優先的に返済することで今後の開発スピードを大きく改善できます。
顧客価値とのバランス
Section titled “顧客価値とのバランス”スプリント内では、技術的負債の返済だけを行うのではなく、顧客にとって価値のある新機能の開発（フィーチャーの作成）も同時に行い、両者のバランスを取ることが求められます。
8.7 終わりに
Section titled “8.7 終わりに”本章では、技術的負債の概念、放置した際の結末、発生要因、そして発生の予防・可視化・返済という管理手法について解説しました。次章の第1部（第9章〜）では、スクラムにおける「役割（プロダクトオーナーなど）」について深く掘り下げます。