現在所属している株式会社ログラスでは技術的負債を貯めにくい組織運営をしており、その取り組みを紹介します。
https://qiita.com/advent-calendar/2021/present-calendar#kaonavi
また今年のアドベントカレンダーでは特定のトピックに関して記事を書くと、副賞がいただけるようなのでコッソリ狙っています。
基本方針は「技術的負債は大きくなる前に叩く」です。
技術的負債に対応する予算を取る
ログラスではあらかじめ技術的負債に対応するための予算SP（ストーリーポイント）を積んでいます。
下の図はチームのベロシティをトラッキングしているシートですが、毎週技術的投資（技術的負債）する予算を積んでいます。
ログラスでは技術的負債とは呼ばずに技術的投資と呼んでますが、似た概念なのでこの記事内では技術的負債と呼ぶことにします。
技術的負債のリファインメントを行う
毎週技術的負債に取り組むので、チケットの整理する時間（技術的投資検討会と呼んでいます）を毎週30分積んでいます。
内容は新しい技術的負債チケットの確認と受入基準を定義です。その週に切られたチケットを確認し、受入基準を決めます。
今後数週間分のチケットが詰まっていることがわかっている場合は開かないこともあります。その都度柔軟に判断しています。
バージョンアップ会
使用しているライブラリにバージョンアップがある場合はDependabotが自動的にPRを作ってくれます。
下図は過去に使っていたAngularのバージョンアップしたときのPRです。
(現在はログラスではAngularは使っておりません。Angularからの移行に関してはこちらの記事を参照ください。)
作られたPRはマージする必要がありますが、その時間もライブラリバージョンアップ会として毎週30分確保しています。
バージョンアップといっても新しいバージョンに互換性があるものも多いです。そういったものは開発者が手元で動かしてこの時間内でマージしてしまいます。
中にはビルドが通らなくなったり、テストがこけるものがあり、それらの修正も軽ければこの30分で対応します。
バージョンアップは最新のバージョンと使用しているバージョンの差分が大きくなればなるほど大変になり、時間もかかります。
日頃からこまめにバージョンアップをしておけば、何かがあった時もサクッとバージョンをあげれるものです。
昨今のLog4jの問題も検知し、サクッとバージョンを上げることができました。これは日頃のバージョンアップ会の成果と言えるでしょう。
もっと大きい技術的負債はどう扱うか
事業のコアの部分だったり、影響範囲が大きくなることがあらかじめわかっている場合は、OKRに組み込んで3ヶ月ぐらい長期的に取り組みます。
今クオータで言うとDBのテーブル名を10テーブルほど書き換える目標を積んでいます。
まとめ
長々と書いてきましたが、まとめます。
1. 技術的負債を改善する時間をスプリントに組み込む
2. そのために日頃から技術的負債を
3. 小さいバージョンアップ系は開発陣全員が毎週30分「ライブラリバージョンアップ会」を行う
4. 大きめな負債はチケットを積んでスプリント内で行う
5. さらに大きいものはOKRとしてクオータの目標とする
こまめに返済していく仕組みづくりの共有でした。