はじめに
私の所属するチームではPRレビューが滞る問題を抱えていました。
チームメンバーがそれぞれ小さなプロジェクトを複数抱えている場合には、要件の把握などでレビューの難易度が上がるため特に顕著でした。
そのため、PRレビューを早めることに関心がありチームで色々試していたのですが、その中でも重要だと感じた2つの要素があります。
それぞれ重要でよく耳にする指標ですが、2つ揃った時にこそ大きな効果を発揮したと感じているので紹介させていただきます。
基本的にはgoogleのコードレビューガイド(日本語版)を参考にしているところが大きいです。
1つ目の鍵: PRの粒度(≒タスクの粒度)を小さくする
PRで重要なことは？と言えばこれってくらいによく耳にしますがやはりこれです！
適切なPRの変更行数は200から400行程度である(※参考)なんて言われていたりもしますね。
私はPRの粒度≒タスクの粒度と考えることもできると思っています。
タスク（チケット）の単位とPRの単位を同一にするまで行うとタスクを切るのも管理するもの大変になってしまうので場合によってはやりすぎに思いますが、
振られたタスクを担当者が各々で適切なサイズに分割するよう心がけることでその問題も解決できます。
大きなタスクとして進めるより、ある程度小さなタスクとして進めて時折フィードバックをもらう方が致命的な手戻りを避けたりといったメリットがあると考えています。
その他にも下記のようなメリットもあります。
- コンフリクト解決がしやすい
- レビュー時に見落としが減る
- Revertしやすい
また私は大き過ぎるPRの目安として、「概要を簡潔に書けないものは分割した方が良い」と考えるのがシンプルで分かりやすいと思っています。
「テストコードが書きにくい場合、テスト対象のコードの見直しから行った方が良い」という考えに似ているかもしれません。
2つ目の鍵: PRレビューを最優先のタスクだと考える
なんだそんなことか..と思うほど単純なことですが、これがめちゃくちゃ重要です！
さらにはこれをチームの共通認識にするのがとても重要です。
ただし、最優先と言っても別のタスクを進行している最中に中断する必要はありません。
私は元々はPRレビューは手すきに行うタスクで、自分のタスクを進めることこそが課せられた最低限の責務だと考えていました。そのためレビューと実装タスクの両方を持っている時は実装を優先していました。どちらかが遅延するなら致命的でないレビューの方を遅延させようと考えてしまっていたからです。
こういった背景もありレビュー優先であるという認識をチーム全体が持つことが重要だと考えています。（その方がチーム全体の生産性が高い感覚もあります）
2つ合わさると…?
PRの粒度を小さくし、レビューを最優先することが組み合わさると..
- PR（タスク）の粒度が小さい
- キリのいいタイミングが増える
- PRレビューの優先度が一番高いため、PRレビューが行われる
という形で効果が現れます。私はこの2つには正の相関があると感じています。
逆もまた然りで、
- PRの粒度が大きい
- なかなかPRがレビューされない
- タスクが滞る
- そのためPRの粒度をなるべく大きくしてまとめて作業を行う
みたいなことも起こりうると考えます。
またPRの粒度が小さい上に積極的にPRを見るようになる事で、副次的な恩恵として自分以外のメンバーのタスク状況や進捗の把握が容易になります。
これによりチーム内での相互理解が希薄になりがちだったところ、お互いの状況ある程度把握が出来る状態になりました。
そのほかTips
主要な2点を中心に、他にも考慮すべき要素はあります。
その中でも私が実施して良かったと思うTipsをいくつかピックアップします！
-
概要を詳細に記載する
- レビューの仕方がわからないというのを減らす
- あとで見返した際に変更を追いやすくする
-
実装とテストコードをセットでレビューに出す
- この方がコードを素早く理解できる
-
参照する資料の概要を引用して記載する
-
粒度の小さいPRはタイトルに [軽微] などの文言を入れる
- 心理的な障壁をできる限り下げる
-
すぐにレビューを開始できない時はスタンプなどでリアクションだけはしておく
- PRに気づいていないケースとの切り分け
まとめ
私の所属するチームでは Findy Teams+ を用いて計測しているのですが、数値としても良い変化が現れていました。
試行錯誤する中でこの2点を押さえた瞬間に劇的な改善を実感しました。
ぜひPRレビューに問題を抱えている方は試してみていただきたいです🔥
Discussion