技術的負債の返済の優先順位についてメモ

メモ程度です。

そもそも機能開発の優先順位付けは悩み続けるもので、
その中でも技術的負債の返済はRICEスコアのような指標をもとに優先度判断、などがしにくいと思う。

結局、返済のために一定枠設けてその中でチーム内（開発がリード）で判断、重厚長大なものはロードマップに乗せて各所と合意しか現状ない気がする。

なお、「一定枠」が適切かどうかは運用してみてDevとPMで判断が良いかと。適切かどうかを考慮する観点は↓。
・障害発生リスクと発生時の影響が大きくなるリスク
・エンジニアのモチベーション度合い（負債が溜まりすぎると低下する、採用にも影響）
・負債が負債を呼んでいるか（割れ窓理論、秘伝のタレ化）
・ベロシティの低下（基本的には負債は溜まっていくものなので、ベロシティは低下していく。それを見ながら返済度合いを変えていく）

返済方法について

・フルタイムで開発できるエンジニアが数人以上
　→毎スプリントのN%を返済に割く、改善デーを設ける、ということができそう
・そうでないとき（副業多いとかスタートアップフェーズとか）
　→毎スプリントのN％を割く、というのは大きめの改善作業がしにくいので、ロードマップ系タスクの合間に改善週間を設けて対応、という方法を取れる。（不定期になるので、強い意志で継続する必要がある。。）

補足

経営学まわりの研究（Founder Premiumとか）みたいに、プロダクトのフェーズが…でコードの指標が〜のときはN%をリファクタリングやリアーキテクチャに当てると良い、みたいな研究があると参考になるのにと思った（あるかもしれないが）。

関連

・プロダクトの急成長の裏側で、PMはどんな機能開発の優先度づけをしてきたか？
　イベントでリファクタリングなどは「一定枠」を設けていると聞いた。
　そういうチーム結構ありますよね
・https://qiita.com/erukiti/items/9cc7850250268582dde7
　技術的負債の問題が網羅的で参考になる