【コラム】絶対レビューしてもらうべきレビュアー

2024年3月4日

エンジニア歴7年の人間です。

皆さんはレビューを依頼する相手にはどんな人を選んでいますか？

仕様について把握しているプロジェクトリーダー？
コーディングに精通したテックリード？

これらの人にレビューしてもらうのはもちろん大切です。
しかし、上記以外にも絶対にレビューをしてもらうべき人物がいます。

それは自分自身です。

そして自分自身のレビューは他者にレビュー依頼を投げる前に実施する必要があります。

理由

自分自身を一番最初のレビュアーにすると良いことが2つあります。

1つ目がレビュー依頼をした相手の労力を下げられることです。

これまでたくさんのレビューをしてきましたが、正直レビューはとても疲れます。仕様の理解、パフォーマンスへの影響、可読性など確認すべき点が多くあります。またどうすればレビューイへの心の負担が少ない指摘の仕方になるかなど、頭をものすごく使うためへとへとになります。

なのでできるだけ自分で直せる部分は直すことで、レビュアーの負担を減らしてあげましょう。

2つ目の良いことが自身の成長にも役立つことです。

自分でレビューせずに出したコードには指摘が大量にあるはずです。その結果、本当に自分に不足している知見・技術に気づきにくくなります。

自分のレビューを終え、自分の中では完璧だと考えたコードをレビューしてもらうことで、本当に自分に不足している部分のみを指摘してもらうことができます。ピンポイントで自分に不足している内容を把握できるので、レビューを繰り返すごとに大きく成長できるでしょう。

実現できていない理由

自分自身がレビューを行うことは当然だと思われる方も多いと思います。しかし実際私が経験したプロジェクトではできていない方が大半でした。もちろん私もできていませんでした。

理由を考えてみたところ、2つ見つかりました。

一つ目が単純に面倒だから。大半のエンジニアは動くものができればおっけーという気持ちがあるので、動いている以上完成品と考えてとりあえずレビューに出しがちです。

あとは早く実装を終わらせたと言いたいことが大きな理由としてあるのではないかと思いました。

エンジニアの業務は作業時間の見積もりを行ってから実装に入ります。大体の場合よくわからない挙動になったり、エラーが発生したりで見積もりよりも長い時間が実装にかかります。リーダーに報告するとき「まだ終わってません、」と言うことはストレスです。進捗報告の時間が憂鬱になります。自分の進捗を少しでも良く見せたい、そんな思いから動くものができた段階ですぐにレビューに出してしまうのではないでしょうか？

これらの理由も踏まえて自分のレビューを徹底させる方法を考えてみます。

徹底する方法

自分自身でのレビューを徹底させるためには「自己レビュー」フェーズを業務フローに盛り込むのが良いです。

「実装→レビュー」というフローを「実装→自己レビュー→他者レビュー」にします。

このようにすることで、自己レビュー自体が業務であると認識でき"面倒でもやらないといけない"という気持ちにさせられますし、動くものが出来上がった段階で実装自体は終わったと報告できるので、報告時のストレスも減らせます。

またフローに組み込むことで作業時間の見積もりの時間に組み込みやすくなり、精度の高い見積もりにもつながります。

まとめ

ごく簡単な改善ですが、チームと個人の両方にリターンが大きな施策だと思います。レビューで困っているチームにはぜひ取り入れてみてください。