コードレビューには魅力がいっぱいです。コードレビューを取り入れていきたいのは山々だけど、重い腰の企業は恐らくいっぱいあるのかと。
自分も今の環境になるまで、1度もコードレビューが当たり前の会社に出会ったことはありませんでした。
ただ、コードレビューは時により、人間関係をこじらせると思います。（少数精鋭のチームで実際にこじれたことはないんだけど。多分大人数だと色んな人がいるという観点から）コードレビューはあくまでも、「コードをレビュー」するものです。それ以上でもそれ以下でもありません。
でも、コードレビューの仕方によって「あいつになんかそっけない指摘されたわー、キー」っていう感情が先走って、しばらく仕事が手に就かないような人もいるのではないかと思います。
さて、前置きが長くなりそうなので、いつかは技術編をやりたい気持ちはあるけれど、今のコードレビュー観点から伝えれることもあろうかと。早速見ていきましょう。
コードレビューのメリット
まず、まだコードレビュー文化を取り入れたいけれども、取り入れることに重い腰を感じているチームリーダーや、管理職系の人、はたまたちょっと声が大き目のエンジニアさんに向けてコードレビューのメリットについて、述べていきます。
細かい環境や、プルリクの粒度、コミットの粒度などは、別記事を参考にしてください。まずは、「コードレビューええやんけ」とは漠然と思っているけれども、実際のメリットって、取り入れていない限りは肌で感じにくい部分もあるかと思います。
そこで現段階で僕が感じているコードレビューのメリットです。
- コードの品質が圧倒的に上がる（バグ発見）
- 社内でのコードスタイルの統一がしやすい（コードに対する意識統一）
- スキル向上の教育になる（勉強会不要説）
- システムが属人的になりにくい
一つずつ見ていきましょう。
コードの品質が圧倒的に上がる（バグ発見）
まず、コードレビューの目的は主に「品質の向上」が目的とされると思います。
レビュワーは実装者の案件の意図に沿って、「期待通りの機能実装が出来ているのだろうか？」また、コードをレビューする意味では実装者よりも頭を使います。それは色んなテストケースや背景なども考慮しなければいけないからです。なので、本当の所、プログラミングをするよりレビューをする方が奥が深く、難しいと思います。（レビューもしなければ、上達しないので無論やりますが、ベテランにはまだほど遠い...）
なので、例えば、僕が10のコミットをしてプルリクを出したとします。すると、ベテランにレビューしてもらうと、結果的に指摘事項がいくつも出てきて、30コミットぐらいになる。
そんなケースはザラです。で、ここで大事なのは、指摘されることが悪いのではなく（初心者はここをネガティブに捉えてしまうと思う）、結果論として「圧倒的にコードの品質が上がっている」ということです。これがコードレビューの目的です。
なので、目的達成できれば、一つの成果なので、肩を落とすことなど何もありません（まつり by 藤井風）。（ま、一発でいける方が実装者/レビュワーも楽なのでは置いといて）
そして、持論ですが、組織にコードレビュー文化があれば、テストチームは不要だと感じています。なぜなら、機能のパターンや当該システムのバックグラウンドを熟知しているメンバーがいれば、プルリクの時点でテストケースも含め、網羅されているはずだから。です。（絶対は人である以上あり得ないですが、それはテストチームも同じ。）
もちろん、コードレビュー文化がない、そもそもいつも納期優先で次から次へと実装するしか方法がない。（で、結果バグだらけ）というような体制ならテストチームは必要かもしれませんが。
でも、そんな状態だと香ばしい臭いがするので、人間関係もくすぶってきそうですね（お疲れさまとしか...）
基本的なベストなコードレビュー体制を挙げるとすると、常に「達人がレビュワー、それを目指す者が実装」がベストでしょうね。（達人はおもんないけど）
でも、そんなわけにはいかない（達人も開発案件進めなければいけない）ので、初級、中級エンジニアもレビューをしなければいけません。
なので、初心者レビュワーに大事になってくることは、
- 期待した通りの機能の動作確認
- コードの誤字脱字（コードスタイル含む）
- 自分が思いつく例外パターン
この三つの基本を必ず守る。ぐらいの気持ちでやるのが良いのかなと思います。根底としては「バグがないこと」です。ある意味それが達成できていれば、とりあえずOKかと。なぜなら、エンドユーザーに迷惑をかけることがないからです。ただ、バグがない、といっても表面上はないように感じても、特定のパターンによって、期待した通りに動かないことが往々にしてあります。そのパターンをできるだけ思考して試す。これがまず第一歩なのかな、と感じています。
それと、コードの誤字脱字もキチンとチェックしましょう。達人も人間です。コードは当該アプリケーションの背景も考慮した意図の洗練された実装に仕上げているけれども、ちょっとした誤字などがあるものです。それは人だから当然です。それを拾い上げる様にチェックすることが初心者には必要だと思います。
一方、達人は「どの様にして作るべきか？」という観点でも、レビューしてくれます。コードレビューの深さ、醍醐味はここからだと思います。
自分では想定していないことを指摘してもらったり、「こんな作り方をすればもっと理に適っている」とか、そもそも意図が違っているケースもあります。そんな実装自体を拾い上げてくれます。（感謝）
結果として、コードの品質が圧倒的に上がるというわけでございます。
社内でのコードスタイルの統一がしやすい（コードに対する意識統一）
コードスタイルは人それぞれです。でも、「人それぞれだから、期待通りに動作していればそれでいいじゃん」というのは少々お粗末かな。と思います。
開発業務は常にチーム戦です。一人一人がある程度の協調性を持たなければ、コードもすぐに腐っていくことになると思います。なので、コードスタイルに対する統一も必要だと思います。
成果物は常に「誰が作ったコードでも、同じようなコードスタイルだから読みやすい、理解しやすい」ことが大事です。
コードレビュー時に、ｵﾚｵﾚスタイルは指摘する必要はあると思います。
で、社内独特のコーディングスタイルだとある意味で汎用性のないものになってしまうと思うので、例えば、PSRの基準に沿う、利用しているフレームワークが採用している規約に沿う、といったものを採用するのが良いと思います。
そうした基準に沿った指摘なら、ガンコ者も「大多数がそうなら仕方ないか..」という気持ちにさせやすいと思います。
スキル向上の教育になる（勉強会不要説）
コードレビュー体制はスキル向上に最適だと思います。なぜなら、「自分の書いたコードを人に見てもらうことによって、新たな発見が多いから」です。
過去に別の職場で勉強会など開催した経験がありますが、きちんとしたプルリク体制、コードレビュー体制があれば、プログラムについての勉強会は不要なんじゃないかな？と思うようになりました。
勉強会と称して、開発業務は人との会話が少なくなるので、コミュニケーションの場、共通の話題を用いたレクリエーション的なものならアリだとは思いますが。
プログラミングは、やはり具体的なプログラム上でやり取りするのが一番スキルに直結すると感じています。
システムが属人的になりにくい
コードレビュー体制のメリットの一つとして、「システムが属人的になりにくい」というのも一つあると思います。
実装者がいて、いかなる場合も常にレビュワーを通さなければマージすることはできない。
ということは、自分の他にもう1人、その案件について関与している人がいるということです。それと、実際にソースコードを見て「どういう実装になっているか」を知っているわけです。システムは複雑なものなので、すぐに属人的になりやすいです。でも、コードレビュー体制があれば、少しは属人を和らげることができます。
それと、基本的にSlackやChatworkなどのコミュニケーションツールでやり取りする中で、プルリクのやり取りも見えるわけですから（※GitHubなどと連携していれば）管理者やリーダーもチームのやりとりを見ることができます。
「何かおかしいな？」とクンカクンカと臭いを嗅ぎつけたらCTOなども駆けつけてくれます。なので、コードレビューはシステムが属人的になりにくいと感じています。
さて、読むのがつらたんになってきましたか？でも話は更に続きます。
コードレビューは時に人間関係をこじらせる
不慣れなコードレビュー体制は、時に人間関係をこじらせる原因になる可能性があります。なぜなら、コロナ禍もあり、働き方改革もあり、テレワークが増えた中で相手の顔が見えない、相手の空気が読めない、などといった原因は少なくともあるのかもしれません。
今の職場環境はありがたいことに、自分に関する課題だけで（ヒューマンスキル的にも）優秀なエンジニアに囲まれているので、ありがたいことにそんな気持ちになったことはありません。ただ、コードレビューにしても「言いたいことを言う」というのは、時に大事だし、時に不要だと思うのは自分の持論です。
誰もが当然分かりきっていることだけど、人には心があります。自分が思っていることを話すことは常に相手への考慮が必要だと僕は感じているし、それが出来ない人は自分の言いたいことをただ言う「独りよがりな人」です。
でもそういう人は、自分のことを独りよがりだと気付いていないのも、世の常。いろーんな職場環境があって、それに苛まれている人はエンジニアに他ならず、いつも大変ですよね...（自分を深く傷つけちゃってるなら、次の転職先決めてやめちゃえ！）
と、ちょっと脱線しましたが、エンジニアにとって、自分の書いたコードは「自分の所有物」みたいに捉える人もいると思います。そこにコードレビューが入って、指摘されると「自分が傷つけられた」と勘違いする人もいるでしょう。
こうなるとちょっと話は職場環境によりケースバイケースによるので一概には言えなくなってくるのは心もとないですが、コードレビュー文化はプロダクトにとっても、チームにとっても、はたまた個人にとっても必要なものです。エンジニアリーダー格の人はそうした信念を持って、多少、人間関係がこじれても、コードレビュー体制を諦めないでもらいたいです。
という経緯で、世の中には色んなエンジニア（人）がいるわけですから、「コードレビュー体制は時に人間関係をこじらせる」ことになると思います。
管理者・リーダーがそうした「ねじれ」を時に正していかなければいけません（大変じゃな）。
「コードの指摘は人間を否定するものではない」と各メンバーに馴染ませる社風を作らなければならないと思います。
コードはコード。それ以上でもそれ以下でもない。コードレビューも同じです。人は関係ありません。
コードレビュー時に気を付けていること
では、具体的に人間関係をこじらせないために一体何が必要なんでしょうか？まだ、自分もコードレビュー体制を経験して約1年半程と短いクソ野郎ですが、自分なりに気を付けていることをリストにします。
- 誰であっても常に敬語を使う
- 「ダメ」とか否定語は極力使用しない
- ～と思いました（和らげる表現。決めつけばかりしない）
誰であっても常に敬語を使う
敬語を使うのはどの社会でも気を使っていくべき事柄だと思います。それは、年上であろうと、年下であろうとも、です。人は出会い方によって敬語使う空気と使わない空気はあるとは思いますが、コミュニケーションツールで文字列でのやりとりが主流の場合は特に気を付けた方がよいと思います。（丁寧過ぎるのもアレですがね...その辺は空気読んでネ）
コードレビューの指摘となると、センシティブな場面も多々出てくるので（相手が嫌な気持ちにならないという意味でも）誰であっても基本は敬語が無難だと思います。
「ダメ」とか否定語は極力使用しない
「ダメ」とかの否定語は極力使用しないことです。なぜなら、繰り返し「ダメ」というキーワードを見る度「またダメか・・」というネガティブな気持ちになりやすいからです。何かバグなどが発見された場合は「NG」というキーワードを使うことにしています、「OK」の場合は「OK」ですが（社風的に現在でも暗黙でそうなっている）。多分、人との会話で使う言葉で否定につながる言葉はあまり使わない方が、気分を害する可能性は低くなるのかな、と感じています。例えば、「OK」の反対は「NO」ですが、「NO」と言われるより、多分「NG」の方が「コードとしてNG」という意味合いが強く表現することができる、と主観ですが思っています。
～と思いました。（決めつけない）
コードレビューすることによって、「もっとこうした方がいいだろうな」というコードが出てきた場合、「こんな感じでするのが良いと思いました」という方が、「こうすべきです」とかよりも、優しく、柔らかく感じると思います。
コードレビューは決して人を否定するものではないですが、それでも「当然人が作った」という矛盾はあります。コードの先には人がいるので、こうすべきという考えがある場合、具体的なコードを記した上で「～する方が良いと思いました。」で相手も受け入れやすいと思います。
以上、細かくはまだあるかもですが、コードレビュー時に気を付けていることは、基本的に職場のメンバーは全て実行しています。
始めてのコードレビュー体制に最初は戸惑いもありましたが、今では気持ち良く業務を進めることができています。
コードレビューは社風に大きく依存する
以上の事柄から推察すると、コードレビュー体制って社風に大きく依存すると感じます。やはりキーはCTO、管理者クラスのチームリーダーがコードレビューに対しての、認識、また、チームメンバーとの関係性によって変わるかもしれません。
個人的に率直に感じるのは、リーダーの人間性の割合が高いと思います。もちろん技術があることは大切なことですが、各個人が自立しているようなチームがあり、あえてマイクロマネジメントはしない、これは今の時代にとって、大切なことだろうと思います。そうなってくると、採用するべき人材も大切になってくるし、例えば横暴なメンバーがいてとしても、社風で手なずけてしまうような良い意味での「つおい社風」が良いと思います。
職場なんてものはそもそも人間関係の塊であって、人間関係のない職場などあり得ないのですが、良い社風を作り上げることが出来る上で、プルリク体制やコードレビュー体制があるとすると、良いコードレビュー体制の構築は凄まじく難しいものなのかもしれません。
さりとて、やらなければ何も前に進まないのも現実です。まだ、コードレビュー体制を作っていなければ、率先して提案し、四苦八苦しながらチームメンバー全員でやり遂げることが、各エンジニアがスキル的にも個人としても成長につながると思います。
最後に
長らくコードレビューの仕方（人間関係編）を見ていきましたが、コードレビューのメリットも理解していただけたのではないでしょうか？
自分は今エンジニアの人生で一番エンジニアらしく向き合っていますが（笑）、何でもいきなり成長するものではないけれど、コードレビュー体制を約1年半経験するだけでも、現在進行形で理解力が増してきていることを実感しています。
周りの優秀なエンジニアの人達は、まあ、それを何年も続けてるわけです。そら伸びますわねー。と納得です。自分もいずれそうなれるように、少しずつ前に進めればな、と日々思いながら。
最後にもう一度繰り返しますが、コードレビュー体制は確実に各メンバーのエンジニア力を高めてくれる代物だと思います。迷っているならどうぞ取り入れて見てください。