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

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


iwashi.co

自分が一番好きな方針、そして説明がこのブログです。 実践したり、設計するときには、いつも確認することに。 場合によっては、新規に参加してもらうメンバーに、上のブログを「読んで欲しいっす」と送ることも。

もしも、より構造的にされているものが良ければ、Googleのプラクティスも良いと思います。

shuuji3.xyz

「コードレビューで1日が終わってしまって困る」みたいな困りは各所で見かけつつ、上のブログはそれらを『そういうものだ』と教えてくれるものなのかなと。 今ブログに考えをまとめ直してみているけれど、正直なところ、上の2リンク以上の価値はないハズ。。

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


以下、「なぜ良いと考えるか」について。

twitter.com

上のツイートに書いたように、もしも「自動テストがコードレビューの代わりになる」ようなケースであれば、コードレビューを省いてしまって良いと思う。 *1 なので、とはいえそれはと感じるケースについて。

コードレビュー

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

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

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

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

プロセスの意味

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

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

そして、プロセスの意味が明確になっていないと、プロセスの評価や改善ができません。 プロセスの評価ができないということは、今ある問題を適切に言語化できない、ということです。 コードレビューの問題でよくあるのは、コードレビューが溜まってしまう。コードレビューに時間が取られ過ぎてしまう。レビューそのものが負担になる、という声です。

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

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

コードレビューだけに限らないが、さまざまなプロセスの意味自体を明確にする努力は、欠かすべきではないと思います。

不安のコントロール

コードレビューは「不安のコントロール」に対して、非常に強い効果を持っていると感じます。

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

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

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

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

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

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


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

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

rework.withgoogle.com

チームとしてどうあるべきかを考えた時、「効果的なチーム」を目指すのは、ある程度当然の話だと思います。 この「効果的なチーム」であるために、コードレビューにチームが取り組むことは、良い効果を発揮するでしょう。 だからこそ、コードレビューのあり方は、世にある知見を参考にするべきです。 そして、常に、チームの重要課題として取り組むべきだと思っています。

*1:詳しくはないけれど、DDDでTDDをしっかりやると、そういう世界観になるのではないかなとかとか