技術的負債の分類

「Managing Technical Debt: Reducing Friction in Software Development」より

技術的負債の定義

ソフトウェア集約型システムにおいて、技術的負債とは、短期的には便利であるが、将来の変更をより高価なものにしたり、不可能にしたりするような設計や実装の構成要素からなる。技術的負債は偶発的な負債であり、その影響はシステム内部の品質に限定されるが、主に保守性と進化性だけではない。

1. 早くて汚いif-then-else

リリースを優先し、開発の速い代替案を選択する。

episode

カナダで作った国内向けのパッケージが売れて、シェア拡大のためフランス語版も作ることになった。そこで、コードの文言表示箇所にif-then-elseを加えて対応をした。プロダクトとしては成功し、国外へも販路を広げることになり、日本語版などを作る段階になって、元のif-then-elseでは立ち行かなくなりif-then-elseを削除し、メッセージリソースファイルを作ってちゃんとしたi18n対応することになった。

フランス語版の段階でi18n対応をすることもできたが、そうすると市場投入タイミングが遅れ商機を逃したかもしれず、一概にif-then-elseの判断が間違っていたとは言い難い。

2. 壁にぶつかる

全体を俯瞰した設計が出来ないまま、フィーチャー実装優先で開発をすすめる。

episode

銀行の統合にともなう、システム再構築プロジェクトで、スプリントごとに見せていたデモは順調に開発されよいパフォーマンスを示していたが、いざ統合しようとするとスケーラビリティ、データ管理、システムの配布、セキュリティの問題が表面化し、大部分を作り変えることになった。

3. 重さで崩壊する

長年、同じやり方を継続してビジネス的にうまく行っていたものが、時代の流れ/競合参入によって、スピード勝負に対応できなくなる。大きな改修もコストが膨大にかかる状態になってしまっている。

4. 千の切り傷で死ぬ

専門性が軽視され、チームメンバーが交換可能なものとして扱われると、本来回避可能である設計やテスト、コード品質の小さな問題が積み重なって、メンテナンスコストが上がる。