コードレビューと不安の管理

コードレビューをなんのためにするのかと考えてみると、「不安をコントロールするためなのかな」と思ったのでブログにまとめます。


自分が一番好きな方針、そして説明のベースにしているのが、こちらのブログです。

iwashi.co

コードレビューについて考えたり、議論する際には、必ず確認するようにしています。 時には、チームに新規に参加するメンバーに対して、「読んでほしい」と共有することもあります。

より構造的に整理されているものが良ければ、Googleのプラクティスもいいものです。

shuuji3.xyz

上のブログを読んで「なるほど」となり「そうしよう」となるならば、ここで読むのを終えて大丈夫です。


以下、「なぜコードレビューが重要だと思うか」について。

twitter.com

もしも「自動テストがコードレビューの代わりになる」ようなケースであれば、コードレビューを省いてしまって良いと思っています。 なので、とはいえそれはそうだけれどもと感じるケースを想定して、続けていきます。

コードレビュー

コードレビューには、コストがかかります。

私ごとではありますが、最近では、150~250件/月ぐらいコードレビューをしています。 これは同僚が「スモークテストをしている」ことを前提に、「設計やデータフローに問題がないか」といった観点でレビューしているものが大半なため、実現できている数です。 逐一ビルドしてデバイス上でチェックして、Figmaと1つ1つ見比べて……とやる必要があれば、多分時間的に対応ができなくなるハズです。

言いたいこととしては、コードレビューを「厚く」運用しようとすればするほど、そこには工数がかかる。つまり人件費がかかるってことです。 他にも、CIツールを利用していればそれらの運用費がかかるし、運用待ちの時間もかかります。 たぶん、各種ドキュメントを整備したり周知する必要もあるので、計上しにくいが明確に必要となる工数もたくさんあります。

コードレビューというプロセスを採用するということは、これらのコストに対して「我々は、こういったメリットを得たい」という合意を取ること、と言えます。 もし、コードレビューがうまく回っていないのであれば、そういった合意が取れていないのではないかなと。コードレビューの運用ではなく、コードレビューの前提を疑ってみた方が、きっと良いと思います。

プロセスの意味

プロセスが儀礼的になっているということは、プロセスの意味がないということを意味しません。

「よくわからないけれど続いている慣習」が何らかの品質を守っていることは時たまあります。もしかしたら、実は、本質的な取り組みかもしれません。 言い換えると、プロセスがブラックボックスであること自体は、そのまま悪いと言い切れません。 しかし、ブラックボックスなプロセスは、そのプロセスが適切かどうかを判断できません。

プロセスの意味が明確になっていないと、プロセスの評価や改善ができません。 プロセスの評価ができないということは、今ある問題を適切に言語化できない、ということです。

コードレビューの問題でよくあるのは、コードレビューが溜まってしまう。コードレビューに時間が取られ過ぎてしまう。レビューそのものが負担になる、という声です。 では、このとき、「何が問題なのか」は明確になっているでしょうか。

前述の通り、コードレビューというステップが不要という共通見解が取れていれば、省いても構いません。 そのような状態であるのに、省けないことに対して不満が上がるということは、何を意味しているのでしょうか?

コードレビューを常に最高のプライオリティにおいているチームであれば、問題は明確になります。つまり、チームで定めたプライオリティと、メンバーのプライオリティの間に、差異があるということです。 当然、「現実的に、レビューするのが大変なコードが多い」場合には不満は残るでしょう。しかし、この時に解決するべきは、コードやPRのであるハズです。

不安のコントロール

コードレビューは「不安のコントロール」に対して、非常に強い効果を持っていると感じます。 具体例を挙げると、下記のようになります。

  • コードが正しく動くことを保証できるか
  • コードが変更内容が必要十分であることを保証できるか
  • コードが重大な問題を引き起こさないことを保証できるか

これらは、コードで記述されている内容に対して向けられたものです。

  • コードの可読性が十分であることを保証できるか
  • コードの意図が筆者以外に読み取れることを保証できるか
  • コードの改修のしやすが許容できるレベルであることを保証できるか

これらは、コードの記述そのものに対して向けられたものです。

  • 書かれたコードが、チームとして出荷することに同意されているか
  • レビューのプロセスを通じて、チームの目標に対して前進しているか
  • コードレビューそのものが、HRTが尊重された行為だったか

これらは、コードを書いているメンバーに対して向けられたものです。


コードレビューに全員が参加すると、こういった「不安のコントロール」に強い効果を発揮することができます。 もしコードレビューが形骸化しているならば、これらの「不安のコントロール」手段を1つ失っている状態だと、私は思います。

長々と書いたけれども、コードレビューは重視する理由はここにあると思います。 チームメンバーが、チームの「不安」をコントロールできるツール、それがコードレビューなのではないでしょうか。

rework.withgoogle.com

チームとしてどうあるべきかを考えた時、「効果的なチーム」を目指すのは、ある程度当然の話だと思います。 だからこそ、コードレビューのあり方は、世にある知見を参考にするべきです。 知見を参考に「効果的なチーム」を目指し続けることが、不安に対応できるチームを作ると信じています。