技術的負債の返済の優先順位についてメモ
メモ程度です。
そもそも機能開発の優先順位付けは悩み続けるもので、
その中でも技術的負債の返済はRICEスコアのような指標をもとに優先度判断、などがしにくいと思う。
結局、返済のために一定枠設けてその中でチーム内（開発がリード）で判断、重厚長大なものはロードマップに乗せて各所と合意しか現状ない気がする。
なお、「一定枠」が適切かどうかは運用してみてDevとPMで判断が良いかと。適切かどうかを考慮する観点は↓。
・障害発生リスクと発生時の影響が大きくなるリスク
・エンジニアのモチベーション度合い（負債が溜まりすぎると低下する、採用にも影響）
・負債が負債を呼んでいるか（割れ窓理論、秘伝のタレ化）
・ベロシティの低下（基本的には負債は溜まっていくものなので、ベロシティは低下していく。それを見ながら返済度合いを変えていく）
返済方法について
・フルタイムで開発できるエンジニアが数人以上
→毎スプリントのN%を返済に割く、改善デーを設ける、ということができそう
・そうでないとき（副業多いとかスタートアップフェーズとか）
→毎スプリントのN％を割く、というのは大きめの改善作業がしにくいので、ロードマップ系タスクの合間に改善週間を設けて対応、という方法を取れる。（不定期になるので、強い意志で継続する必要がある。。）
補足
経営学まわりの研究（Founder Premiumとか）みたいに、プロダクトのフェーズが…でコードの指標が〜のときはN%をリファクタリングやリアーキテクチャに当てると良い、みたいな研究があると参考になるのにと思った（あるかもしれないが）。
関連
・プロダクトの急成長の裏側で、PMはどんな機能開発の優先度づけをしてきたか？
イベントでリファクタリングなどは「一定枠」を設けていると聞いた。
そういうチーム結構ありますよね
・https://qiita.com/erukiti/items/9cc7850250268582dde7
技術的負債の問題が網羅的で参考になる