Looks Good To Me 読書会でレビューの質が向上した話

Transcript

1. © SmartHR, Inc. Looks Good To Me 読書会で レビューの質が向上した話 〜Rails での具体例を添えて〜 新奥 ⼤介 SmartHR プロダクトエンジニア 2025/07/10
2. お話すること 1. Looks Good To Me という本の紹介 2. チームが読書会を始めた理由 3. 読書会前後のレビューコメント⽐較 4. 読書会をやってみてどうだったか
3. Looks Good To Me の紹介 Looks Good To Me • Adrienne Braganza (著) • ⾼⽥新⼭ (翻訳) • 増井敏克 (監修) • 秀和システム • 2025年5⽉30⽇ 発売 3
4. Looks Good To Me 読書会をチームで始めた理由 なぜ LGTM の読書会をチームで始めたか？ • AI活⽤によってPR作成数が相対的に増加 • レビューに費やす時間が多くなってきた • 「レビューの重要性が上がってきてるよね」という認 識がチーム内で⼤きくなってきた • 毎週⾦曜⽇にテックトークという技術ネタ雑談タイム を設けていたが若⼲ネタが枯渇していた 4
5. Looks Good To Me 読書会をチームで始めた理由 なぜ LGTM の読書会をチームで始めたか？ • AI活⽤によってPR作成数が相対的に増加 • レビューに費やす時間が多くなってきた • 「レビューの重要性が上がってきてるよね」という認 識がチーム内で⼤きくなってきた • 毎週⾦曜⽇にテックトークという技術ネタ雑談タイム を設けていたが若⼲ネタが枯渇していた 5
6. 「なんか良さそう」 という興味駆動で 勉強会がスタート！ 6
7. 読書会によって⽣まれた効果 読書会で⽣まれたチーム‧プロセスの変化 • PRオープン前のセルフレビュー項⽬の整備 • コメントシグナルの改善＆チーム内認識の統⼀ • レビュー後にApprove or Request Changeを必ず明⽰ ◦ マージブロックか否かを迷わなくなった • PRタイトルをConventional Commits仕様に統⼀ 7
8. 読書会によって⽣まれた効果 読書会で⽣まれたチーム‧プロセスの変化 • PRオープン前のセルフレビュー項⽬の整備 • コメントシグナルの改善＆チーム内認識の統⼀ • レビュー後にApprove or Request Changeを必ず明⽰ ◦ マージブロックか否かを迷わなくなった • PRタイトルをConventional Commits仕様に統⼀ 8
9. 読書会前後のコメントの⽐較 読書会以前のコメント 9
10. 読書会前後のコメントの⽐較 読書会以前のコメント 10
11. 読書会前後のコメントの⽐較 11 正しくない気がするので確認をお願いします • ⼀⾒問題なさそうな、よくあるやりとりではある • 強いて⾔うのであれば ◦ レビュアーの気になりポイントがやや不明瞭 ◦ PR作成者に求めるNext Actionが少し曖昧 • 結果としてレビュアーの求めることとPR作成者が⾏っ た対応に齟齬が⽣じてしまっている
12. 読書会前後のコメントの⽐較 読書会以前のコメント 12
13. 読書会前後のコメントの⽐較 読書会以前のコメント 13
14. 読書会前後のコメントの⽐較 14 [MUSTだけどnits]ファイル分けたいです！ • これも決して悪いコメントではない • [MUSTだけどnits]というコメントシグナルが ◦ なんとなく⾔いたいことはわかる ◦ ただマージブロックなのかどうか不明確 • 結果として対応はするが「コメントシグナル意味ある かな？」というモヤりが残る
15. 読書会後にチームは どうなれたか？ 15
16. 読書会前後のコメントの⽐較 16 トリプルRパターンでのコメントを意識 • 依頼（Request）： ◦ PR作成者に何をしてほしいのか • 理由（Rationale）： ◦ 依頼が必要な理由の説明 • 結果（Result）： ◦ PR作成者が変更を⽐較できる測定可能な最終状態
17. 読書会前後のコメントの⽐較 トリプルRパターンに沿ったコメント 17
18. 読書会前後のコメントの⽐較 トリプルRパターンに沿ったコメント 18 依頼
19. 読書会前後のコメントの⽐較 トリプルRパターンに沿ったコメント 19 理由
20. 読書会前後のコメントの⽐較 トリプルRパターンに沿ったコメント 20 結果
21. 読書会前後のコメントの⽐較 21 コメントシグナルの統⼀ • マージブロックとするもの ◦ needs change: ▪ 1回のコミットで解決できる⼩さな変更と修正 ◦ needs rework: ▪ ⼤きな⼿直しやリファクタリングを必要とする変更 ◦ align: ▪ 機能的に問題ないが、チーム規約に準拠していない • 未対応でもマージしてよいもの ◦ levelup: ▪ 品質向上のために変更が推奨されるがPRの承認は⽌めない ◦ nitpick: ▪ コードに影響を与えない単なる主観的なコメント
22. 読書会前後のコメントの⽐較 コメントシグナルの活⽤ 22
23. 読書会前後のコメントの⽐較 23 必須ではないがRSpecの保守性も気にしたい コメントシグナルの活⽤
24. 読書会前後のコメントの⽐較 24 規約＆他実装箇所に反した書き⽅は直したい コメントシグナルの活⽤
25. まとめ 1. 気軽な気持ちで始めた読書会だった 2. いざ読み進めていくとアンチパターンに⼼当たりがあった 3. コメントシグナル‧PRタイトルの統⼀などすぐに開始できる 事例が多数あった 4. 本⽂中の事例以外でも、全員で同じ本を読むことによって 「レビュー後は絶対にApproveかRequest Changesのどちら かをつけよう！」などの共通認識が明⽂化された チームのコードレビューの質が向上！
26. Looks Good To Me をチームで読んで  気持ちの良いコード レビューのプロセス を確⽴していこう！ 26
27. ご清聴ありがとうご ざいました！ 27