コードや設計を批判的にレビューすることの重要性
とある本を読んで、先行研究の調査に「批判的であること」が重要と説かれていました。これをエンジニアリングに当てはめて考えてみました。
Table of Contents
批判的であることが何故大事なのか
私のこれまでの経験則に基づいている考えでもあるのですが、コードやdesign doc（設計書）を批判的にレビューすることはより良いアイディアの発見やパフォーマンス改善に繋がるし、生成AIのハレーションを見抜く端緒になるからです。
私が所属しているチームでは他メンバーの実装したコードやAPI定義書、ドメインモデリングなどを複数人でレビューするモブレビューを定期的に行っています（1日の朝晩1回ずつ）。レビュー対象がコードであれば「やりたいことが実現できる実装になっているか」、「実現できているが他に良い実装の仕方は無いか」、「データを破壊してしまうような致命的な欠陥は無いか」、「テストケースは網羅できているか」、etc…。ただ漫然とコードを読むだけだと見落としてしまいますが、「批判的であること」を意識してコードを読むことで、欠けているものを見抜く力が多少なりとも増幅される実感があります。もちろんある程度の技術力や気づけるだけの知識をレビューアが持っている前提ではあるのですが。
他メンバーの成果物だけでなく自分が用意したものにも有効です。「私はこう考えたけど他に良いアイディアがあるかもしれない」という視点があることで、他メンバーに相談してみたりするので地雷を踏み抜く確率が減ります。最近はChat-GPTやCopilotを業務で使わない日はありませんが、生成AIから得られる情報も完璧ではないと念頭に置いておくだけでもかなり違うのでは無いでしょうか。
当然レビューを受ける側もコメントや指摘に対して批判的に咀嚼して良くて、テックリードがそうしろと言ったからとか、この本にはこう書いていてあるからこうすべきとか言われても、その考えでは解決しない/納得できない場合は自分の考えを素直に伝えて意見を擦り合わせます。レビューしてもらった上で有益な指摘であれば「確かに！ご指摘ありがとうございます！」と受け入れるし、直す必要がないものなら「xxxxなので大丈夫です！」と根拠を提示して意見を伝えれば良いだけだと思っています。しかし実際のやり取りでは双方納得する形で意見がまとまらないことも多々あって、そういう時にどうしているかとか、どの方向に倒すかの判断基準などは別の記事で整理しようと思います。
批判的にレビューする/受ける際に気をつけること
- 他メンバーの成果物をレビューする/他メンバーのコメントに対して反論する際は攻撃的にならないこと。批判 ≠ 攻撃。
- 自分の成果物をレビューする際は自虐的にならないこと。なんでもホイホイ受け入れないこと。
あくまで新しい視点を提供するためなので、口から発するまたは文字に起こして相手に伝える際は攻撃的になっていないか、自分の考えを押し付けていないかを意識しています。批判的にレビューしつつも成果物とそれを用意したエンジニアに対しては常にリスペクトの気持ちを忘れないこと。そしてレビューする側も完璧ではないので、納得いかない/指摘内容がわからない指摘の場合、レビューを受ける側はレビューアに説明を求めるのが重要です。
まとめ
「批判的であること」の重要性について述べました。そもそも批判的にレビューせずにどうレビューするのかという話なのですが、言語化することでより解像度が深まりました。この記事ではまとめきれなかった具体的なレビューの仕方や判断基準などについては別記事でまとめようと思います。