最近現場で成果物のレビューをする機会があるので、私が意識していることを書いてみました。
意識していること
ルールを決め、セルフチェックを徹底させる
レビュー観点を明確にする
順序を決める
指摘点を伝える際は具体的に
横展開を徹底させる
レビューのタイミングを意識する
ルールを決め、セルフチェックを徹底させる
レビューは面倒な作業で、出来るだけ指摘をしたく無いのでメンバーにはセルフチェックをしてもらいます。
例えばドキュメント類であれば、
- 誤字、脱字
- フォントや罫線等のレイアウトの統一
- 粒度を合わせる
ソースコードであれば、
- 警告は潰す
- 変数名の命名
- 適切な量でメソッド分割する
- 動作確認
などです。
チーム内でルールを決め、メンバーにはこれらを依頼前にチェックしてもらうことで指摘を出来るだけ減らします。
誤字、脱字などの指摘は出来るだけしたくないし、大量の行数のメソッドが来ると気が遠くなります。
レビュー観点を明確にする
自分の好みで指摘をするのはよくないと思います。現場にあった観点を見極めます。
既存の指摘表等があれば参考にして、今までどんな指摘が上がっているのかを確認するのも良いです。
ソースコードであれば、基本的にはコーディング規約に従います。
動作はするが明らかに非効率だったり可読性が悪い場合は指摘します。
こっちの方が効率良いとかはメンバーの成長の為にアドバイスしても良いと思います。
順序を決める
システム開発には要件定義→設計→実装→試験という風に順序がありますが、レビューもある程度順序を決めておかないと途中でよくわからなくなって戻って確認し直したりと、無駄な工数が発生しかねません。
私の場合は、レビュー対象機能の仕様を大まかに確認した後にレビューを始めます。
機能要件と合っているか、網羅出来ているか（漏れがないか）を確認し、その後に可読性等の品質周りを確認します。
仕上げに誤字脱字等をザーッと確認。
指摘点を伝える際は具体的に
レビューイに伝わらないと、指摘の再指摘が発生してしまいます。
極力は一往復で終わらせたいので、出来るだけ具体的に伝えます。
私は
- 指摘箇所
- 指摘理由
- 修正方法
を伝えるように意識しています。
横展開を徹底させる
同じ指摘が出ないように、メンバーには依頼前に横展開をしてもらうようにしています。
指摘数がそのまま品質の指標となるので、減らせるところは減らしておきたいですね。
レビューのタイミングを意識する
レビューイの手が止まらないように、優先してレビューを実施するのが理想です。
ですが、自分の作業もあると思うので優先度を考えて判断します。
また、自分の作業が中途半端な時は切りの良いところでレビュー作業に切り替えます。無理に切り替えると戻った時に整理しなおす無駄な工数が発生するためです。
最後に
レビューはとても面倒な作業で、責任も感じてしまい漏れなく完璧にしようと思いがちです。
その結果時間がかかってしまう事もありました。
ですが、完璧なレビューは無いと思うので漏れなく指摘するという意識ではなく、成果物を良くするという意識で今後もレビューに臨みたいです。