- 技術的負債の概念
- より時間がかかるかもしれない、より良いアプローチを採る代わりに、簡単だが制約のあるソリューションを選んだときに必要となる、将来の手戻りの暗黙的なコスト
- 最も効果的なソリューションではなく、最も速いソリューションを選んだことで発生する追加作業コスト
- ソフトウェアエンジニアのマーティン・ファウラーが分類した技術的負債の種類
- 慎重かつ意図的な技術的負債（Prudent & Deliberate）
- チームは負債を負っていると分かっているが、「より速いリリースの見返りが負債返済コストより大きいか」を検討する
- 軽率で意図的な技術的負債（Reckless & Deliberate）
- 良い設計プラクティスを知っており実践もできるが、きれいなコードを書く時間がなく、「速くて雑に」進めることにした結果
- 慎重だが意図しない技術的負債（Prudent & Inadvertent）
- 良いソフトウェアを開発し、コードもきれいだったが、時間が経ってからようやく「設計はどうあるべきだったか」に気づいた結果
- 軽率だが意図しない技術的負債（Reckless & Inadvertent）
- 技術的負債の解決方法
- 技術的負債リストの管理
- プロジェクトを振り返って技術的負債を一覧化し、共有する
- 技術的負債が発生するたびに、その負債の解消に必要な作業を、想定される工数・スケジュールとともに記録する
- チームで技術的負債を解消するかどうか、いつ解消するかを議論し、解決策を立てる
- 良い技術的負債と悪い技術的負債を区別する
- このように技術的負債を区別すると、最も大きな問題の優先順位を決めるのに役立つ
- リファクタリング
- 業務を進めながら必要な部分を整理し、少しずつリファクタリングする
- 大規模なリファクタリングを行うときは、チームに状況を共有し、技術的負債のリスクとコストを知らせる
- テストコードを書く
- コードが複雑であるほど、またリファクタリングの規模が大きいほど、バグなく一度でコードを修正するのは難しい
- 副作用を防ぐにはテストコードを書く
- 品質基準を設定し、順守する
- 品質基準を設定して、開発者が雑なコードをデプロイできないようにする
- 突然の規定・日程変更はしない
- 開発者に関する規定を継続的に変更したり、締め切りを変えたりすると、技術的負債を避けるのは難しい
- 現実的なスケジュール、方法論、作業量を提供して、技術的負債を管理できるようにする
- 技術的負債は常に悪いものなのか？
- クリス・リコミニ、ドミトリー・リアボイの著書『必読！ 開発者オンボーディングガイド：持続可能なソフトウェアと円滑な協業文化を理解するプロフェッショナル開発者の誕生』「後からでもチームが解決できるよう訓練された負債なら、それは『良い負債』と言える」
- しかし技術的負債はビジネスに否定的な影響を与えうるため、解決する必要がある
- これはバグとして現れ、ユーザー体験を低下させる
- 技術的負債が悪化すると、開発者は既存のコードベース内で作業するのがより難しくなる
- 新機能の開発や既存機能の修正に時間を割かれることで、ソフトウェア開発ライフサイクルが遅くなり、市場投入の時期も遅れる
まだコメントはありません。