2025年5月30日に発売された秀和システムの『Looks Good To Me』を読み終わったので、読後の感想を書く。実はTwitterで募集されていた読者レビュアーに応募して選ばれたので、自分で買ったわけではないことは明記しておく（ステルスマーケティング回避）。金を払っていないのでレビューとしては信頼性に欠けるかもしれないが、忖度なくめっちゃいい本だったので普通に紹介したい。アフィリエイトリンクは無い。
量的構成
まずは量的構成について。この本は4つの部と付録から成り、そのページ数は下図のような配分になっている。
- Part 1 コードレビューの基本
- Part 2 高度なコードレビューに必須の要素
- Part 3 ジレンマへの対処
- Part 4 コードレビューとその他の開発プラクティスを組み合わせる
もっとも文量が多いのはPart 1「コードレビューの基本」で、次いで Part 2「高度なコードレビューに必須の要素」も同じくらいある。付録を除けば3分の2くらいがこの2つの部で占められる。
次に章の単位で見てみると、下図のような配分になっている。
- Part 1
- Chapter 1 コードレビューの重要性
- Chapter 2 コードレビュー徹底解剖
- Chapter 3 チームの最初のコードレビュープロセスの構築
- Part 2
- Chapter 4 チームワーキングアグリーメント
- Chapter 5 自動化のメリット
- Chapter 6 効果的なコードレビューコメントの作成
- Part 3
- Chapter 7 コードレビューがダメになる理由
- Chapter 8 コードレビューの遅延を減らす
- Chapter 9 プロセスの抜け穴を取り除く
- Chapter 10 緊急時対応プレイブック
- Part 4
- Chapter 11 コードレビューとペアプログラミング
- Chapter 12 コードレビューとモブプログラミング
- Chapter 13 コードレビューとAI
明らかに紙幅が割かれているのはChapter 2「コードレビュー徹底解剖」、次いでChapter 3 「チームの最初のコードレビュープロセスの構築」とChapter 5「自動化のメリット」だ。これは「はじめに」で書かれている対象読者像とマッチしている。まだチームにコードレビュープロセスを構築できていない人、構築されているがうまくいっていないと感じている人、もっとコードレビュープロセスを改善したい人のための本だ。そのために、まずはコードレビューとはいったい何なのか、何が目的なのかという根幹について徹底解剖している。
あなたは、コードを書いてレビューしていますか？そうであれば、あなたこそ本書を読むべきです。 もう少し具体的に言えば、「Looks Good To Me」は、現在のコードレビュープロセスを改善したい開発者、チームの新しいコードレビュープロセスを確立したい開発者、 非効率的なレビューに疲れ果てて、それを変える方法についてのインスピレーションを必要としている開発者にとって価値があります。特に、「人的ボトルネック」によってコードレビュープロセスに不満を持ち、それを解決してプロセスに対する考えを変えたいと思っている人のためのものです！また、チームの最適なコードレビュープロセスの構築を支援し、実現したいと考えているテックリードやソフトウェア開発マネージャーにとっても、本書は価値があります。
またこの本の特徴は、そのような概念的・理念的なことばかりではなく具体的なコードレビュープロセスの構築方法についてのハウツー的な要素もたっぷり書かれていることだ。Part 2以降はチームですぐに使えそうなドキュメントテンプレートや、役立つツールの紹介、うまくいかないときの対処方法など、読者のアクションにつながる内容が多い。理念と実践の両方を学べる本だ（それだけ分厚くはあるが）。
質的構成
この本の質的構成を、各章の主題となる問いから整理する。全部読み終わったうえで、各章は次のような問いに対する答えが書かれているように感じられた。特に著者の主張・問題意識が強く出ていた問いは太字にしている。
- Chapter 1 コードレビューの重要性
- Q. コードレビューとは何か？
- Q. コードレビューはなぜ重要なのか？
- Chapter 2 コードレビュー徹底解剖
- Q. コードレビューには何が必要か？
- Q. コードレビュー参加者には何が求められるのか？
- Chapter 3 チームの最初のコードレビュープロセスの構築
- Q. チームがコードレビューを始めるにはどうすればいいのか？
- Q. コードレビューのガイドラインはどのように設定されるべきか？
- Chapter 4 チームワーキングアグリーメント
- Q. チームワーキングアグリーメントとは何か？
- Q. プロセスに関する明確な期待がないとどのような問題が起こるのか？
- Chapter 5 自動化のメリット
- Q. コードレビュー作業をできる限り自動化すべきなのはなぜか？
- Q. コードレビューはどのように自動化できるのか？
- Chapter 6 効果的なコードレビューコメントの作成
- Q. コードレビューコメントがなぜ重要なのか？
- Q. 効果的なコードレビューコメントとはどのようなものか？
- Q. 有害なコードレビューコメントとはどのようなものか？
- Chapter 7 コードレビューがダメになる理由
- Q. コードレビュープロセスはなぜ機能しなくなるのか？
- Chapter 8 コードレビューの遅延を減らす
- Q. コードレビューはなぜ長引くのか？
- Q. コードレビューが長引かないようにするにはどうすればいいのか？
- Chapter 9 プロセスの抜け穴を取り除く
- Q. コードレビュープロセスの抜け穴はどのように発生するのか？
- Q. 抜け穴を取り除くにはどうすればいいのか？
- Chapter 10 緊急時対応プレイブック
- Q. 通常のプロセスでは対応できない緊急事態にはどうすればいいのか？
- Chapter 11 コードレビューとペアプログラミング
- Q. ペアプログラミングによりコードレビューは不要になるのか？
- Q. どのようなペアプログラミングが効果的なのか？
- Chapter 12 コードレビューとモブプログラミング
- Q. モブプログラミングによりコードレビューは不要になるのか？
- Q. どのようなモブプログラミングが効果的なのか？
- Chapter 13 コードレビューとAI
- Q. コードレビューにAIを使うメリットは何か？
- Q. コードレビューにおけるAIの（現状の）限界は何か？
- Q. コードレビューはこれからどのように変わっていくか？
全体を通じて著者のエイドリアン氏が強調しているのは、「プロセスを形骸化させない」ということだと感じた。コードレビュープロセスをチームが「良いもの」と実感しながら実践し続けられるためにはどうすればいいのか？ということが書かれている。逆に言えば、コードレビューは一般的に「良いもの」とされているのに、現場では悩みの種になってしまうことが多いということだ。なぜそうなってしまうのか、どうすれば落とし穴に入りこまずコードレビュープロセスの恩恵を受けられるのか。そのあたりが本書の中心的なテーマだと思う。この問題設定に共感できた人、思い当たる節がある人はぜひ読んでほしい。
本筋とは関係ないが、翻訳本あるあるとして著者のジョークや比喩がよくわからんというのがあるが、本書もその点は多分にある。特にエイドリアン氏は音楽が好きそうで、よく洋楽の歌詞に引っ掛けた例え話が出てくるが、読み飛ばして何の問題もない（苦労したであろう翻訳者には申し訳ない）。
気に入ったフレーズ
ここからは本書の中で気に入ったフレーズをいくつか引用したい。
p53 Chapter 2 コードレビュー徹底解剖
理由が何であれ、レビューを流し読みすべきではありません。 状況に関係なく、適切なレビューを確実に行うことは、 レビュー担当者としての責務です。多くのレビュー担当者は都合よく忘れてしまいがちですが、自分がレビューを通過させたものは、 その後も自分の責任なのです。PRを手短に済ませて承認した後に本番環境が停止した場合、反射的に、コードの作者や「十分にテストをしなかった」QAチームのせいにしてしまいます。 実際には、問題のあるコードを承認したレビュー担当者は、「なぜ見逃してしまったのか?」と自問するべきです。
p136 Chapter 4 チームワーキングアグリーメント
設定するべき最も馬鹿馬鹿しいけれども必要なガイドラインは、「互いに礼儀正しく接する」ことです。「公式ドキュメントに『意地悪するな！』と明記する必要は本当にあるのか？」と思うかもしれません。私は自信を持って「はい！」と答えます。コードレビューが、時として人々の否定的な面を引き出すことがあるのは周知の事実です。
p187 Chapter 6 効果的なコードレビューコメントの作成
妥協点を見つけることは、どちらのコードが「優れている」かを議論して選ぶことではなく、互いに、そして、実際は、将来の全ての開発者にとって、明確でメンテナンスしやすい解決策を見つけることです。
（中略）
結局のところ、目標は、それがどちらの開発者の当初の好みと完全に一致していなくても、当初の目的を達成するような、明確でメンテナンスしやすい解決策のバランスを見 つけることなのです。
p229 Chapter 8 コードレビューの遅延を減らす
あまり知られていませんが、 PR作成者は、 PRの準備に少し努力する必要があります！結局、そこに行き着くのです。変更の背景や正当性を追加することから、作業を管理しやすい単位に整理すること、そして、コミット履歴やドキュメントで明確なストーリーを伝えることまで、全てはPR作成者次第なのです。
これは大変なように思えるかもしれませんが、そうではないと私は考えます。これは、「適切なPRを準備する労力を費やすことは負担だ」というソフトウェア開発に長年根付いた思い込みの1つです。ユニットテストやドキュメントの作成と同様に、一部の開発者は、こうした必須項目がもたらす不便さを嘲笑います。しかし、この態度は、「ただコードを書くだけ」の人の考え方のように聞こえます。
（中略）私たちははるかに多くのことをしており、その「より多くのこと」こそが最も価値をもたらすことを知っている開発者です。私たちの役割の大部分を占め、かつ、重要で価値ある要素は、コードを取り巻く知識の集約、整理、伝達です。それは、思いやりの部分であり、気配りの部分です。それこそが、私たちをよりよいソフトウェア開発者にするのです。
（中略）プロのソフトウェア開発者と名乗りたいのであれば、プロのソフトウェア開発に内在する当然の責務を果たさなければなりません。
ここはかなり痺れる書きっぷり。エイドリアン氏の魂を感じる。
p242 Chapter 8 コードレビューの遅延を減らす
• よいコードレビューは時間がかかるが、かかりすぎることはない。コードレビュープロセスにおける不要な遅延を排除することで、コードレビューに対する恐怖を軽減できる
• ほとんどの遅延は、明確さの欠如や当然の責務を果たしていないことに起因する
まとめ
『Looks Good To Me』は間違いなく良書。あらゆるソフトウェア開発者にとって、コードレビューで困ったらまず読むべき一冊と言っていいと思う。