「コードレビュー・・・うっ頭が」となっているそこのアナタへ。

先週弊社キカガクで人生初の実務コードレビュー体験をしました。
控えめに言って最高すぎました。
お互いが「気持ちよく・効率的に」学びを深められるように組まれた一級品のレビュー構成。
細部に渡る心遣いとテクニックの為せる技だと思いました。

そこで私は考えたー。
真逆のことをしたらどうなるんだろう？

想像してみたらなかなかブラックな開発環境が脳内で出来上がりました ~~（大学時代のコードレビュー現場そっくりだなと思ったのは内緒）~~。
自分がコードレビューに参加する時こうはなるまいぞいう戒めを込めて紹介していこうと思います。

具体的な改善案も5選紹介しています。
共に愛され系コードレビュアー＆レビューイを目指しましょう！

想定している対象読者

「もうすぐ初めてコードレビューを受ける予定で不安・・・」
「コードレビューを行うことになったけれど、どうやったらうまくいくのかよくわからない・・・」
「なんだか最近コードレビューがうまくいかなくてお腹が痛い」

等々でお悩みのコードレビューを行う・受ける機会があるIT従事者。

この記事の目的

よく起きるコードレビュー時のトラブルを

コードレビューを「受ける」人
コードレビューを「行う」人

別に紹介してコードレビュー時の不幸な事故を減らすこと。

コードレビューを「受ける」人編

作業面よりメンタルの問題がメイン。

1．「人格攻撃されている」と思い込む

コードレビューは行う・受ける人の双方が 「成果物を評価しているのであって、人格を否定しているわけではない」 という意識をしっかりと持つ必要があります。
どちらもってところが大事です。受ける側にその意識がない場合・・・

「私のことを攻撃しているんだ！」
「私のことが嫌いだからこんなにダメ出しするんだ！」

と一方的に被害妄想に陥り関係が破綻します。
大丈夫。みんなあなたのことが好きです。安心してコードレビューを受けてくださいね。

2. ダメ出しを受けて落ち込む

「こんなに改善しなきゃいけないところがあるなんて最悪だ。自分はなんてダメな奴なんだ」的ネガティブマインドでコードレビュー中どんどん不機嫌 or 悲しくなっていくタイプ。
コードレビューする側もそれを受けて嫌な気分になる or 落ち込む負の連鎖が始まるハメになります。

図太くいきましょう。

「出来てなくて当たり前」
「本実装前に気づけて良かった」
「伸びしろがたくさんある」

これぐらいの心づもりでOK。
ニコニコご機嫌で聞いてくれる人の方がコードレビューを「行う」人のテンションもアガること間違いなしです。
人の心は連鎖します。受ける人ニコニコ→行う人もニコニコ→それを感じて更にニコニコ→... ニコニコゲシュタルト崩壊。こうなれば最高です。

コードレビューを「行う」人編

コードレビューは概して「行う」人が作業の主導権を握ることがほとんど。
その結果必然的に「受ける」人よりも気をつけなければいけない箇所がタスクレベルでぐんと増えます。
「受ける」人がメンタル面で気をつけなければいけないのに対し、「行う」人はレビュー方法を具体的に洗練していく必要があります。

3. 人格攻撃をする

大事なことなので2回言います。「評価するのは成果物」受けている人自身ではありません。
コードレビューを行う側にこの意識が欠けているとより悲惨なことになります。

パワハラ一直線。
訴訟待ったなし。

この令和の時代にはもういないとは思いますが・・・
「なんでこんなこともできないの？」「そんなことだから何をしても駄目なんだよ」「ハゲ！」みたいなその人を直接攻撃するような発言はNGです。
その言葉で自分自身も更にイライラする上受ける側もストレスでパフォーマンスが地に落ちること間違いなし。
誰も得しませんね！

4. 誤解を与えかねない文体・口調で説明する

「行う」人自身は人格攻撃をしているつもりがないのに、
攻撃していると誤解されやすい文体や口調でコードレビューを「受ける」人にプレッシャーを与えるパターン。

人格攻撃をすることが一発アウトの劇物ならこちらはさながらボディブローのように効いてくるじわじわ系の毒物といったところでしょうか。
コードレビュー現場で最もよく見るBadな光景トップ３にランクインしてます（私調べ）。
直接的な人格攻撃に対しこちらは「攻撃的である」ことの境界線が曖昧で調整が難しいためです。

コードレビューを「受ける・行う」人双方が「受ける人自身を攻撃するつもりがない」認識をはっきり共有した上で、「行う」人がなるべくポジティブな文体・口調でコードレビューを進めていけばよりうまくいきやすくなると思います。

5. なぜ直すべきか説明しない

「ここができてません」おしまい。
「何がいけないのか自分で考えてみてほしい」という理念の元行われがちです。
一理あるとは思うのですが、コードレビューを「受ける」側は既に自身にとってのベストプラクティスを見せてくれているわけで・・・

「そう言われてもわからんものはわからん」
「調べてみたけどわからなかった。落ち込む」
「それっぽい理由を発見したけどこれも間違っていたらどうしよう」

となりがちです。
副作用が強すぎるので直さなければいけない理由はしっかり伝えてあげたほうが良いと思います。

6. 直してほしい箇所を口頭のみで伝える

ここを怠ると双方で「言った・言ってない」事故が起きる原因になります。
文字として残しておくと事故防止に繋がります。
コードレビューを「受ける」人の issues に直してほしい部分を書いてあげると◎。

7. どう直せばいいのか示さない

１から１００まで手取り足取り示す必要はないと思いますが、「これを試してみて」ぐらいの道筋は示してあげると「受ける」人のリファクタリングがよりスムーズになります。
「なるべく試行錯誤してみて、詰まったらこれを見てね」と回答例もプルリクエストしてあげておくと尚良し。

最高のコードレビュー体験にするためのアクションプラン5選

コードレビューを「行う」人がすぐに実践できる、
嫌われる特徴全てを回避した上でより良いコードレビューを実現するための具体的な対策を５つ紹介します。
ソースは弊社キカガクの代表取締役会長@yoshizaki_91のコードレビュー方法（ありがとうございました！）。

このアクションプランは「新人教育時のコードレビュー」を元に作られています。
コード規則を熟知したベテラン同士でコードレビューを行う場合は一部当てはまらないケースもあるかと思いますのでご留意ください。

1. レビュー開始前に「成果物を評価する」認識を必ず共有する

ここでコードレビューが成功するか否か決まるんじゃないかって位大事です。
最重要と言っても過言ではありません。

「アナタとワタシ、トモダチ！ユウコウテキ！ヒョウカしているのはすべてセイカブツ！」であることを必ず共有しましょう。
一緒に３回ぐらい念仏のごとく唱えてもいいかもしれません。

2. issues のタイトルを「～しよう」に統一する

嫌われる特徴「4. 誤解を与えかねない文体・口調で説明する」を回避する具体策。
改善してほしいところをissuesに残す時タイトルを「～しよう/～してみよう」に統一してみましょう。

Bad
「 axios を使用していない」

Good
「axios を使ってみよう」

ほんのちょっと文章を変えただけで印象がガラッと変わりますね。
下の文体で統一するだけで自然とポジティブな印象を与えることができるようになります。

3. なぜ・何を・どう直すか issues へ具体的に書く

期限も設けたい場合は「いつ」も明記してあげましょう。
その際文体を「～でしょう」に統一しておくと自然にポジティブな印象を与えることができ◎です。

1: Not good
「boolean名が不適切」

2: Can be better
「booleanがforUpdatingという名前ではどんな機能なのか判断しづらい。isUpdatingなどに変えること。」

3: Good
「booleanがforUpdatingという名前ではどんな機能なのか判断しづらいため、isUpdatingなどに変えると良いでしょう。」

2でより具体的に。3でよりポジティブに。
2⇔3で言っていることは同じですが、
3の文体の方がぐっと柔らかく明るい印象になります。

4. 回答例を作ってプルリクしてあげる

非同期での作業が多い現場ほど有効。
「ハマったとしてもこれを見れば大丈夫」という精神的安心感は計り知れません。
コードレビューを「受ける」側の時間のかけすぎ防止にもなります。

5. 「良かったところ」もissues に書く（おまけ）

その人が今できているところをしっかり拾って褒めると以下の効果が期待できます。

できていた部分が印象に残って次も意識しやすくなる（※人にもよると思います）
現時点で出来ている部分と改善すべき部分がより明確になる
ついでにその場の空気もよくなる

追記 (最終更新日: 2022/03/23)
皆さんのフィードバックを拝見したところ（ありがとうございました！）
5選の中でも突出して場合によりけりな気がしたのでおまけ扱いとしました。
有効か微妙かもしれない例: チーム全員が気心の知れたバリバリのベテランでゴリゴリ開発しているときなど。

逆に新人教育時などでは絶大な効果を発揮すると思います！

忙しい人のための１秒でわかる結論

コードレビューを「行う」「受ける」人双方が「成果物に対して評価をしている」意識を強く持ち行動すれば大抵うまくいきます。

ここまで読んでくれてありがとうございました。
コードレビューでPTSDになっている人のため、優しさ半分でできている胃薬程度にお役に立てれば嬉しいです。
良きコードレビューライフを！