コードレビューの心理的負荷から見るルール整備の大切さ
この記事について
最近あったことをベースにこうすれば良かったのかなということをまとめています。
現場で実践したり検証したものではないのであらかじめご認識ください。
もし実体験などありましたらぜひ教えていただきたいです！🙇♂
きっかけ
レビュアーとしてプルリクエストにコメントをしていた時のことです。
私はライブラリの非推奨な利用をしている部分を指摘し、推奨される使い方を提案しました。
するとコメントへの返信で独自の見解を展開されて一度拒否されました。
ここで指摘した「ライブラリの非推奨な利用」というのは、使用しているライブラリの公式ドキュメントにて明確に記載されているものでした。
つまり私個人の見解によるもの(いわゆる宗教的なもの)ではありませんでした。
またコメントには公式ドキュメントの該当箇所へのリンクも記載していました。
この反応を受けた後、もう一度公式ドキュメントベースでなぜ非推奨な使用方法とされているのかを説明したうえで変更リクエストを投げかけました。
それによりどうにかリクエストを受け入れて修正していただけましたが、プルリクエストのコメントの返信で『納得はいっていないがレビュアーの指摘なのでしょうがなく受け入れる』といった趣旨のものを残されていきました😞
課題
この事例では、お互いに納得しない、プルリクエストの承認を得ることが目的となったコードレビューとなってしまいました。
こういったことが続くと以下のような課題が出てくると考えています。
- チーム内不和
- レビュアー・レビュイー双方の心理的負荷増大
- 特にやり取りが長くなるほどお互いに疲弊していく
- 別のところで自分の意見を通そうとする可能性がある
- これによりソースコード全体を俯瞰したときにコーディングスタイルにムラが生じる。
対策案
月並みなことになりますが、ルール整備をして機械的に進められるようにすることが重要なのだと考えます。
ルールをチーム全体で議論して合意を取り、準拠しないといけないものとします。
今回の事例ではタスク実施時にメンバー間で信じているものに隔たりがあったためすれ違いが起きてしまいました。
事前のルール整備によりレビュワーとレビュイー双方のストレスを緩和できるのではないかと考えます。
すぐに思いつくところでは以下のようなルールがあります。
-
レビュールールをきめておく
変更の提案をした後、やりとりを2往復しても結論が出なかった場合に他メンバーや上位者などの第三者にコメントしてもらうなど。
ルール化することで議論の着地点までの道のりが見えるようになり、いつまでやり取りが続くのかという不安やストレスの軽減につながるのではないでしょうか。 -
コーディングルールをきめておく
命名に関する規則や禁止事項など。
また、今回の事例に当てはめると、ライブラリやフレームワークのベストプラクティスに従わない部分について明示するなど。
まとめ
レビューは開発において品質を向上させるための大切なタスクの一つです。
しかしこれが原因でチーム内不和が発生する危険性も孕んでいます。
あらかじめ意見の分かれるような部分については方針を決めておき、メンバー間の衝突の火種となるものはつぶしておくことがチームビルディングで大切なのだと思いました。
すべての開発チームの職場環境がより良くなり働きやすくなることを願います！🙏
Discussion