レビューの時間というと、PRを出してからレビューされるまでの時間、レビューを行うのにかかる時間、この2つがあるのかなと思う。
どちらも短ければ短いだけ良いのはわかるが、なかなか思うようにいかない。
PRからレビューまでの時間に関して言えば、レビュワーのリソース確保が大きな問題になってくる。レビュワーも開発を行っているエンジニアで、さらにベテランになってくるのでエンジニア業務以外もこなしている中でレビューを行う時間を多く取ることができない現実がある。
本来、書かれたソースコードが本番環境へマージされるまでの速度を早めることは生産性を高めることにもなるので、優先して取り組むべきではあるが、そうなっていない。これが問題。
ではどうすべきか。人を採用する。何かをなくす。などなどあるが、そもそものレビュー時間を短くすることができればいいのかもしれない。
こういう時ついつい人を増やせば解消すると考えてしまうが、人を増やしても速くならないを常に心に留めておく。
ちょうど見つけたFindy CTOの佐藤さんのスライドが参考になりそう。
PRのレビュー改善は先日ブログにも書いた開発生産性を改善することになりそう。なんでもかんでもやるのではなくて、ユーザーへのデリバリースピードにこだわったみたい。（GoQのデリバリースピードはマジで早いと思ってるけど、やっぱりここなのかな、）CICDの改善。うちもこれだよな。まずは静的コード解析したい。そしてテスト書きたい。
PRの改善。すごい、、、PR作成計画はすごいな。でもPRで手戻りやコミュニケーションが増えるなら事前に確認もある程度しないといけないのかなー、この辺はペアプロ的なことで解決できないだろうか。やっぱりサイズ感のルール作りは必要だよな。
レビュー最優先のマインド作りや環境は整えたい。とはいえ、現状こなしているタスクではなかなか難しいと思っている。そのためにチーム分けをして、1-2週で役割を分けて開発と運用を進めていけないかと考えている（これもなかなかできてないんだよなー
やること山積み、、、まずはチーム分けして、チームで役割をローテーションさせたい。それと同時にPRの出し方とかサイズの共通認識というかルール作りかな。そしてCICD改善。毎日コツコツやるしかない。
おわり。
人が増えてもなぜ速くならないか興味があればこの本がおすすめ