コード品質やレビュー効率が改善された結果、PR作成数が増えると思っていました。ですが、実際は逆でした。
PR数を増やそうとする（つまり、 PRサイズを小さくする）ことで、レビュー効率が改善され、コード品質も高まっていくのです。
スクラム開始以降は適切にタスク分割でき、PRサイズを小さくできていることが分かりました。しかし、実際にデータを見ると、1PRあたりの変更行数は200行くらいあります。
他社の取り組みを見ていると、「1PRの変更行数は100行以下」を目安とする会社が多いようです。さらなる生産性改善のため、まずはこの水準を目指したいと思います！！！
チケット分割においてかなり手応えは感じているものの、現状のやり方ではある程度限界も見えているので、他の打ち手も検討しています。
具体的な方法の一つとしては、「フィーチャーフラグを使ったトランクベース開発」に挑戦したいと思っています！