こんにちは！新規事業開発チームでプロダクトエンジニアをしているシンオクです。
突然ですが、皆さんは自身が所属するチームのレビュープロセスを気に入っていますか？
- レビューコメントの意図が分からず、次のアクションに困った経験はありませんか？
- 「レビューの質を上げたい」と思いつつ、具体的に何をすれば良いか悩んでいませんか？
本記事では、コードレビューをテーマにした解説本『Looks Good To Me』の読書会をチームで行い、これらの課題をどのように解決したか、その具体的なプロセスとチームに起きた変化を紹介します。
この記事が同じような課題感を持つチームの皆さんにとって、参考になれば嬉しく思います。
Looks Good To Me とは
この本は、コードレビューの具体的なテクニックだけでなく、その背景にある文化やチームでの仕組みづくりまで、幅広くかつ深く解説しています。コードレビューに関する「なぜ？」と「どうやって？」が詰まった一冊です。
読書会のきっかけ
読書会を提案した私自身、チームの中では一番経験の浅いエンジニアでした。
日々の業務の中で、他のメンバーとの「エンジニアとしてのスキル差」を常に感じており、その具体的な差の一つに「コードレビューの質」があると考えていました。
ただ、「レビューの質」と言っても、それが具体的に何を指すのか、どうすれば質が上がるのかまでは自分の中で言語化できておらず、もどかしさを感じていました。
そんなときに、『Looks Good To Me』の存在を知り、チームでの読書会を提案しました。私たちのチームでは毎週テックトーク（毎週1時間、エンジニア全員で技術的な話題について話す会）を開催していましたが、ちょうどネタが枯渇していた時期でもあったので、読書会の開催に至りました。
読書会の目的
個人的な希望から始まった読書会でしたが、チームの貴重な時間を使うなら、チームとしての目的を明確にすべきだと考えました。
そこで、読書会の第1回では、本格的に本編を読み進める前に、本書のイントロダクションにあたる第1章だけを全員で読み、「なぜこの読書会をチームでやるのか」を議論する時間にしました。
議論の結果、私たちのチームとしての目的は、以下の2つに定まりました。
- メンバー全員でレビューに対する共通言語・共通認識を持つこと
- チームでのレビューを効率化するアイディアを取り入れて既存のレビュープロセスを改善すること
読書会の進め方
読書会は以下の方法で約1.5ヶ月、全6回にわたって実施しました。
1回あたりの読書量
全13章を、全6回で読破しました。序盤は毎週1章ずつじっくりと、慣れてきた後半はペースを上げて3〜4章をまとめて扱いました。
事前準備（非同期）
参加者は、その日の範囲の章を各自で読んできます。このとき、熟読するよりも「チームに活かせそうなエッセンス」を抽出する意識で流し読みする程度がちょうど良い負荷でした。読みながら気づいたことを、FigJam（オンラインホワイトボードツール）の付箋にどんどん書き出します。
読書会当日（同期）
- 週に一度のテックトークの時間に全員で集まります。FigJamに貼られたたくさんの付箋を全員で眺めながら、「できている」「やる」「検討」「やらない・今じゃない」の4つのカテゴリーに分類します。
- 「やる」に分類されたものは、実際にチームで取り組む課題として1週間以内に実行します。
- 「検討」になったものは、チームのTODOリストにストックし、いつでも見返せるようにしました。
チームに起こった変化
読書会を通じて、私たちのチームには大きく2つの変化がありました。「文化・マインドセット」という土台の部分と、「ルール・プロセス」という具体的な仕組みの部分の両方に良い影響があったと感じています。
マインドセットの共有：レビュー文化の土台を築く
まず、技術的なルール以前に、コードレビューに臨む上での心構え、マインドセットをチーム全員で再確認できたことが大きな収穫でした。
あなたのレビューを通過するものは、あなたの責任となる
「レビューに通った時点でレビュワーもそのコードについて責任を負う」というレビュワーとしての責任を再認識したことで、「Pull Request（以下、PR）を承認する」という行為の重みを全員が理解し、一人ひとりのレビューへの真剣味がより一層増しました。
開発者ではなく、コードに焦点を当てる
「レビューはコードに対するものであり、人格攻撃ではない」という大原則を改めて確認することができました。もともと仲の良いチームで、人格攻撃をするようなメンバーは一人もいません。それでもこの当たり前のことを全員で確認できたことで、より率直で建設的な議論ができるようになりました。
敬意はトーン、つまり、コメントの書き方や選ぶ言葉に現れる
相手への敬意を忘れないコメントを心がけることが、チーム全体の心理的安全性をより一層向上させるきっかけになりました。
プロセスの進化：コメントシグナルのルールを統一することでレビューの迷いをなくす
続いて、「ルール・プロセス」という具体的な仕組みについての変化です。
読書会を始める前のチームの課題
レビューコメントの「温度感」を伝えるための明確なルールがなく、レビュワーは [MUST] [IMO] [NITS] といったシグナルを思い思いに使用していました。時には [MUSTだけどNITS] のような合わせ技もあり、PR作成者は「このコメントはマージまでに絶対対応すべき？それとも後続のPRでも良いのかな？」と迷う場面もありました。
また、レビュワーからPR作成者に対して求める具体的なアクションが不明瞭になり、コミュニケーションコストが大きくなるときがありました。
読書会以前のコードレビューの具体例
受け取ったコメントシグナルの温度感の判断がつきにくい例
このコメントでは [MUSTだけどNITS] というコメントシグナルが使われています。「すぐ終わる作業だけど対応してね」という意図は察しがつきますが、文脈によっても意味は変わりそうなので、PR作成者はこのコメントの取り扱いについて迷う恐れがあります。
レビュワーに求める具体的なアクションが曖昧な例
上記のコメントでは「正しくない気がしてきたので、確認お願いしたいです」という若干曖昧なレビュワーのコメントからレビューのやりとりが始まっていました。
結果として、レビュワーとPR作成者間で意図がすれ違い、最初から丁寧にコメントをしていれば避けられたかもしれないコミュニケーションコストが発生しました。
エイドリアンシグナル
前項の課題を解決するため、私たちは本書で紹介されていた5種類のコメントシグナルを導入しました。そして、著者であるエイドリアン・ブラガンザさんの名前にちなんで、このシグナル群を「エイドリアンシグナル」と名付けて運用しています。
マージブロックとするもの
needs change:- 1回のコミットで解決できる、比較的小さな変更や修正を依頼する場合に使います。
needs rework:- 設計の変更や大きなリファクタリングなど、手戻りの大きい変更を依頼する場合に使います。このコメントが付いた場合は、レビュワーとPR作成者が同期でミーティングやペアプログラミングを行うことを推奨しています。
align:- 機能やロジックに問題はないものの、チームで定めたコーディング規約などに準拠していない箇所を指摘する場合に使います。
未対応でもマージしてよいもの
levelup:- PRの承認は止めないものの、より良いコードにするための改善提案や、プラスアルファの知識を共有する場合に使います。
nitpick:- コードの動作に一切影響を与えない、単なる好みや主観的な意見を伝える場合に使います。
コメントシグナルと合わせて、同じく本書で推奨されていた「トリプルRパターン」に沿ってコメントするようになりました。これにより、PR作成者により明確に意図を伝えることができるようになりました。
- 依頼（Request）: PR作成者に何をしてほしいのか
- 理由（Rationale）: 依頼が必要な理由の説明
- 結果（Result）: PR作成者が変更を比較できる測定可能な最終状態
これらのルールを導入した結果、コメントの意図が明確になり、レビュワーとPR作成者の間での認識のズレや、対応要否の確認といったコミュニケーションコストが削減されました。
読書会後のコードレビューの具体例
このコメントではシグナルとして levelup: が付与されており、「必須ではないがテストコードの保守性も鑑みると、このPR内のマージブロックとまではしないものの、近い将来対応しておきたい」という温度感をPR作成者に伝えることができます。
一方、こちらのコメントでは align: が付与されており、「チームのコード規約や、他の実装箇所の書き方などを考慮するとマージ前に確実に対応して欲しい」という先ほどよりも高い温度感のコメントであることがわかります。
また、上記のコメントは needs change: が付いたコメントですが、トリプルRパターンに沿ってコメントできています。
- 依頼（Request）: 特定のパターンでは
valid_atの代わりにcreated_atを値として詰めて欲しい - 理由（Rationale）: NoMethodErrorが発生して処理が途中で終了する恐れがある
- 結果（Result）: コードの差分
このコメントによって、レビュワーとPR作成者の間で認識齟齬が生じることはなく、このPRは順調にマージされました。
まとめ
本記事では、書籍『Looks Good To Me』の読書会を通じて、チームのコードレビュープロセスを改善した具体的な道のりを紹介しました。
チーム全員で同じ本を読み、対話することで、
- レビューの共通言語が生まれ、コミュニケーションコストが削減された
- 自分たちのプロセスを客観的に見直し、主体的に改善するきっかけとなった
- エンジニアとして大切なマインドセットを再確認できた
といった多くのメリットを得ることができました。
もし、あなたのチームがレビュープロセスに少しでも課題を感じているなら、『Looks Good To Me』はその解決のヒントを与えてくれるはずです。
ぜひチームでの読書会を通じて、皆さんも気持ちの良いレビュープロセスを確立してください。
We Are Hiring!
開発プロセスも、プロダクト自体もまだまだ伸びしろたっぷりのSmartHRでは一緒にSmartHRを作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
