コードレビューに限らず、いろいろなレビューがいろいろなプロセスに組み込まれている。
だが、レビューにおいて、たとえ内容に瑕疵があっても承認されるなら、そのレビューは単なる形式・儀式に過ぎない。 "何かを保障するためのプロセス"としてのレビューを機能させることを目的とするなら、そこには却下の可能性があることが必要条件だ。
保障: ある状態がそこなわれることのないように、保護し守ること。(https://kotobank.jp/word/%E4%BF%9D%E9%9A%9C-630029)
却下と批判的立場
そのようなレビューにおいて、レビュアーは「これは承認しても大丈夫か」と思考する。 「承認しても大丈夫だ」という確信を得るということは、裏返せば「却下すべき理由がない」という確信を得ることである。 その確信が得られるのは「却下すべき理由を探したが見つからなかった」ときである。
つまりレビュアーに承認を求めることは、「却下すべき理由を探す」ことを求めているのである。 そして「却下すべき理由を探す」ということは、その事柄に対して批判的・悲観的な立場に立つことと同じである。 「保障プロセスとして機能するレビュー」において、レビュアーは間違いなく批判者である。 レビューで批判的立場から却下されるということは、そのレビューが保障プロセスとして機能していることの表れともいえる。
※あくまでも＜事柄＞に対しての批判であり、レビュイーの＜人格＞への批判は求められることではない。
レビュイーの気の持ちよう
たとえば専門家のような権威勾配のあるレビュアーからの批判的な意見は、レビュイーにとってプレッシャーとなることは容易に想像できる。 だが、専門家も専門家であるからこそ自身の承認の重さを自覚しているために、いっそう批判的立場を緩めないように気を張っている。 そのレビューが保障のプロセスであるため、専門家が専門家であるために、そこに「お手柔らかに」は通用しないのである。
その前提を踏まえた上で、レビューを依頼するときには「承認をもらいにいく」（支持してほしい）のではなく、自分とは違う視点から「検証してもらいにいく」（見落としを見つけてほしい）というマインドでいること、それがレビュアーに対して優しさを期待することに諦めがつく気の持ちようではないかと思う。
また、レビュアー側も「保障プロセスとして機能するレビュー」にするために批判的立場からコメントすることをあらかじめエクスキューズしておくことで、不都合な衝突を起こすリスクを減らすことはできるだろう。
コードレビューは「誰かのコード」を「みんなのコード」にする工程
— lacolaco👑 (@laco2net) 2019年12月18日
