こんにちは。
私、RubyKaigi 2025 in Matsuyamaに参加したのですが、そこで以下の書籍を購入しました。（結構、購入されている方が多いようで！）

GW中に読もうと思って読んでいるのですが、なかなか進まず…
やっとPart1の「心構え編」を読み終わったので、ここまでのお話をまとめておきたいと思います。
（所々、自分なりの解釈が入っていたり、引用させていただいている部分があります。）

この書籍が目指すゴール

まず、この書籍が目指しているゴールは、「コードレビューに関わる全てのメンバーが、レビューを通じたコミュニケーションによってより良い開発を行えるようになること」です。

そして、以下のような効果が現場にもたらされることを目指しています。

チーム間でのスムーズな知識共有
効率的な課題解決
高品質な成果物
チームが持つ力の最大化

コードレビューの利点

現在の主流となっているのは、Gitを使用したプルリクエストを使用したコードレビューです。

コードレビューには、以下の利点があります。

コードの挙動を確認し、バグの混入を防ぐ
より良いコードの書き方や設計をチームで議論し、コードベースを健全に保つ
開発チームのメンバー間で知識・経験を伝達し、全体の実装力を向上させる
開発チームのメンバー間でプロダクトの仕様を共有する
よりコードについての議論を通じ、開発チームの文化を醸成する

たしかに、インターンの時や新卒入社したばかりの時って、コードレビューの効果は「コードの挙動を確認し、バグの混入を防ぐ」だけだと思っていましたが、今では開発メンバー間でのコミュニケーションを通じてより良いものを実装していったり、新たな気づきを得ることができる良い機会だなぁと思っています。

コードレビューの難しさ

本質的に「批判」

コードレビューの難しさは、コードレビューが本質的に「批判」「批評」であることです。

レビューを受ける側の開発者は、レビューコメントをもらった時に「自分の書いたコードがダメだったんだ…」と思います。そのコメントの量が多かったりすると、「うわぁ…」ってなりますよね。自分も経験者です。

レビュイーに問題がある場合も…

本書の筆者は、「レビュイーに問題がある場合がある」と述べています。

過剰に防衛的な態度
- レビューを「攻撃」と捉えて警戒するあまり、どんなコメントも懐疑的に受け取ったり、情報を出し惜しみしたりする
過剰に受動的な態度
- レビューコメントを無条件で受け入れ、自分の意見や考えを持とうとしない

自分はレビューを攻撃と捉えたことはないのですが、完全に受動的になっていた時期はありました。新卒入社したての頃は「自分の技術力は全然だからとにかく先輩の考えに合わせてみよう」と考えていたので、受けたレビューの内容は全て反映させるというような行動をとっていました。

レビュアーに問題がある場合も…（こっちの方が多いイメージ）

独善的な指摘
- レビュアーの個人的な観点からの批判で、客観的な根拠が示されていない
持って回った表現
- 攻撃的と思われないように気を使うあまり、回りくどくなり、コメントの意図が掴みづらい
人格の攻撃
- コードの不備を指摘する際に、実装者の態度や人格について言及してしまう

人格について言及してくる人が世の中にはいるのか…

レビュイーが持つべきスタンス、意識

まず、レビュイーに求められるのは、「レビュー対象である実装の情報を過不足なく提示すること」です。（ワタシコレデキテイナイカモ…）

プルリクエストの詳細欄に以下の内容を記載していくと良いらしいです。

このコードによって実現されるべき状態・仕様
変更の前後での違い
なぜこのような実装にしたのかの設計判断
レビューで検討してほしい点
動作確認方法

GithubやBacklogで言えば、IssueとPullRequestを対応させておけば、Issueを細かくチケット化しておけば、レビューすべきスコープが少なくなるので良いかもしれないですね。

レビュアーが持つべきスタンス、意識

まず、レビュアーに求められるのは以下です。（チームや組織によって異なります。）

動作が正常であるか
仕様との乖離がないか
コード品質は問題ないか
設計の良し悪しの検討
パフォーマンスは問題ないか
セキュリティは問題ないか

しかし、コードレビューをコミュニケーションとしてみた時、以下の点が重要です。

指摘事項について明瞭な根拠を示す
質問する際は「なぜそれを知りたいか」を示す

こうすることで、レビュイーはレビューの意図を理解し、健全で建設的な議論を行うことができます。健全で建設的な議論を行うことができれば、より良いコードを実装することができます。

つまりコードレビューとは？

コードレビューという言葉から、レビュアーが大事だと思われがちですが、実際には「受け入れ可能なコードの状態を目指して、レビュアーとレビュイーが二人三脚でコードを改善していくもの」がコードレビューなのです。とのことです。

レビューがすれ違うときってどんな時？
これは「相手の意図が掴めない時」です。

まず、レビュイーがプルリクエストの詳細に「バグを修正しました」とだけ記述したとしましょう。そうするとレビュアーからは「何のバグ？」「原因は？」というような根本的な疑問点がたくさん出てきますよね。

一方で、レビュイーが十分な情報を記載したプルリクエストを出したとしましょう。その内容を読んだレビュアーが「どうしてこのメソッド？」とコメントしたとしましょう。このコメントを読んだレビュイーはからは「このメソッド使ったら良くないかな？」「他にも適切なメソッドがある？」などの不安が発生します。そして、これでは健全で建設的な議論を行うことはできません。

健全で建設的な議論を行うことはできなければ、良いコードを実装できないのはもちろんのこと、チーム間の関係性もギクシャクし始める可能性があります。

あくまでもコードレビューは二人三脚

あくまでもコードレビューは二人三脚なので、二人が向き合ってしまったらダメです。実際の二人三脚でも二人が向き合ったら競技終了ですよね。

なので、「レビュイー&レビュアー vs コードで解決すべき問題」という関係性を築く必要があります。
この関係性を築くためには、コードレビューの過程で以下の点が前提としてあるべきです。

レビュアーはレビュイーを攻撃していない
レビュアーのコメントに余計な意図が含まれていない

つまり、「些細な言葉の行き違いや認識の齟齬が少ないコミュニケーションが、些細な言葉の行き違いや認識の齟齬を問題としない関係性を作る」のです。

そのためにも、健全で建設的なコードレビューが行われている必要がありますね。

今回はここまで！