ブログ

• 技術的負債とは、現在の進捗のために、将来のキャパシティ(ソフトウェアの開発能力)を犠牲にすることである
• もうちょっと具体的に言えば、技術的負債とは、ソフトウェアの内部的な問題（見つかっているか見つかっていないかは関係はない）、要求の明確化の欠如、ダメな設計、ビジネスの要求に適していない設計、自動化できるはずの箇所の手動処理などを指す
• **利子の支払いは時間のムダである。**例えば欠陥を直すのに時間を取られる、要求が明確になった後に再度作りなおす、複雑なコードを理解するために余計な時間を取られる、などなど
• 技術的負債の悲惨なサイクルがある
  • テストを書く時間がない、リファクタリングする時間がない、設計レビューする時間がない、問題の本質を解決しないで表面的に解決する
  • 結果的に品質が下がる。急いで無理やり直して、やはりテストがない。自動化されていない。設計がダメなまま
  • バグがさらに増える。テストされていないコードの増加、重複コード、タコな設計のコード、リファクタリングされていないコード、チームのモラルの低下、健康被害
  • 付け焼刃な対応によるファイル数やコード量の増加。そして最初に戻る
• 負債の可能性は右の式で表現できる：（変更頻度×複雑度）÷ 品質のコントロールの度合い
• 技術的負債にどう取り組むか
  • 実際の症状を見つける
  • なぜそれが発生したのか？なにが原因なのかを確認する
  • 根本原因にたどりつくまで「なぜ？」を繰り返す
  • 自分がコントロールできる範囲になったら直す
  • 影響があって手に負えない場合は全体で方針を決める
  • 以降に負債を増やさないように、品質を作りこむ
• Chris Sterlingの「Technical Debt Mapping」の手法を使って技術的負債をコントロールする手もある
  • まず主要なアプリケーションのコンポーネントをホワイトボードに書き出す
  • ポストイットに技術的負債を書いて、書きだしたコンポーネントの該当箇所に貼る
  • これらの負債を、「品質向上のストーリー」としてINVESTを意識して記述し、プロダクトオーナーに説明する。その際、価値は投資対効果で記述する
  • プロダクトオーナーはROI等を見ながら優先順位を決める

※ここでの品質はソフトウェアの外部品質ではなく、内部品質を指す。