第8章 技術的負債
技術的負債の例
- 不適切な設計
- 不具合
- 不十分なテストカバレッジ
- 手動テストの横行
- 貧弱なインテグレーション
- プラットフォームに関する経験の欠如
技術的負債がかさんだ結果の例
- 予測不可能な臨界
- 負債が溜まっているところに新たに負債が増えると、増えた負債の量を上回る悪影響を及ぼす可能性がある
- ある段階で臨界点を超えるとそのプロダクトは管理不能な状態になってしまう
- デリバリーに要する時間の長期化
- 負債が増えれば増えるほどベロシティは低下する
- 不具合の多発
- 様々な不具合が絡み合って致命的な障害を起こしてしまうこともある
- 開発及びサポートのコスト増加
- かつてはシンプルで安上がりだった作業が、込み入った高く付く作業になる
- プロダクトの退化
- 新機能の追加や不具合の修正はプロダクトを若返らせる
- それをやめると、徐々に魅力を失い始め退化をしてしまう
- 予測可能性の減少
- 見積もりの精度が悪くなってしまう
- 負債の結果どの程度時間がかかるのか見通せなくなる
- 伸び悩み
- 募る不満
- 開発の楽しさが消えて、誰もやりたがらないような課題の解決に振り回される
- 優秀なメンバーはもっと満足できる環境を求めて去っていく
- 顧客満足度の減少
- 顧客の満足度が下がる
技術的負債の可視化
- ビジネスレベルでの可視化
- ベロシティの変化を追跡
- 負債が増えていくにつれてベロシティが低下する
- ベロシティの変化を追跡
- 技術者レベルでの可視化
- 技術者は負債についての暗黙知を持っていることが多い
- 少なくても最もひどい負債に関しては持っている
- 可視化する方法3つ示すと以下のようになる
- 負債をバグや障害と同様に扱い障害管理システムに示す
- 負債を表すPBIを作ること
- 技術的負債だけを扱うバックログを用意し、個別に管理する
- 技術者は負債についての暗黙知を持っていることが多い
技術的負債の返済
負債の返済について議論する場合に、以下の3つのカテゴリに分類すると便利
- 偶発的な技術的負債
- 開発者が事前に気づけなかった負債
- 新たな開発作業中にその場しのぎで書かれたもの
- 既知の技術的負債
- 可視化されている負債
- 返済対象の技術的負債
- すでに把握しており、返済する方針が固まっている負債
技術的負債は必ずしもすべて返済すべきとは限らない
返済するべきではない場面の例を3つ以下に上げる
- プロダクトの寿命が近づいている場合
- 使い捨てのプロトタイプの場合
- もともと短期間でしか使わないプロダクトの場合
スクラムを使って技術的負債を管理するテクニック
既知の技術的負債をPBIに紐付けて管理する
技術的負債を技術的負債バックログに登録し、それをスプリントバックログの隣に掲げてスプリントプランニングを行う
スプリントプランニングでは、チームのメンバーとPOが協力して、PBIの中から次のスプリントで作業をするアイテムを選び出す
それと合わせて技術的負債バックログのボードも眺める
そして、PBIと関係する負債のカードを探す、見つかったらそのカードをタスクとてスプリントバックログに追加する
ここまでの感想や実際の現場との差異
- うちのチームではプロダクトバックログとは別のバックログに作っているが、負債だけではない
- バックログに乗せいない緊急かつ開発にかかるものや、開発チーム外の作業などがある
- 負債だけを表すバックログを作ってみる？
- 技術的負債の返済がなぜ重要かについてはこれがわかりやすいかもしれない