Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Looks Good To Me 読書会でレビューの質が向上した話
Search
DaisukeShinoku
July 10, 2025
Programming
0
68
Looks Good To Me 読書会でレビューの質が向上した話
DaisukeShinoku
July 10, 2025
Tweet
Share
More Decks by DaisukeShinoku
See All by DaisukeShinoku
create_tableをしただけなのに〜囚われのuuid編〜
daisukeshinoku
0
480
最短リリースの壁を超えろ!チーム立ち上げから71営業日でプロダクトリリースした話
daisukeshinoku
1
1.7k
Ruby と Rails の小ネタ集
daisukeshinoku
3
2k
受託開発から人事労務SaaSに転職して1年間でやったこと
daisukeshinoku
2
1.9k
今の SmartHR にエンジニアで入社するとどうなるの?
daisukeshinoku
8
6.7k
テンショク・ジャーニー —航海士だった僕が、SaaS企業でエンジニアとして働き始めるまで—
daisukeshinoku
1
2k
仕事観がアップデートされた読書体験 「エンジニアリング組織論への招待」を読んで
daisukeshinoku
2
1.8k
はじめてのアジャイル・スクラム開発での新鮮な発見
daisukeshinoku
2
2.6k
スクラム & アジャイル本をまとめてみた
daisukeshinoku
0
770
Other Decks in Programming
See All in Programming
A2A プロトコルを試してみる
azukiazusa1
2
1.4k
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
650
Team operations that are not burdened by SRE
kazatohiei
1
310
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
650
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
170
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
130
Discover Metal 4
rei315
2
130
チームのテスト力を総合的に鍛えて品質、スピード、レジリエンスを共立させる/Testing approach that improves quality, speed, and resilience
goyoki
5
870
Deep Dive into ~/.claude/projects
hiragram
14
2.5k
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
140
VS Code Update for GitHub Copilot
74th
2
640
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
2
640
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Code Review Best Practice
trishagee
69
18k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
510
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
KATA
mclloyd
30
14k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Statistics for Hackers
jakevdp
799
220k
Transcript
© SmartHR, Inc. Looks Good To Me 読書会で レビューの質が向上した話 〜Rails
での具体例を添えて〜 新奥 ⼤介 SmartHR プロダクトエンジニア 2025/07/10
お話すること 1. Looks Good To Me という本の紹介 2. チームが読書会を始めた理由 3.
読書会前後のレビューコメント⽐較 4. 読書会をやってみてどうだったか
Looks Good To Me の紹介 Looks Good To Me •
Adrienne Braganza (著) • ⾼⽥新⼭ (翻訳) • 増井敏克 (監修) • 秀和システム • 2025年5⽉30⽇ 発売 3
Looks Good To Me 読書会をチームで始めた理由 なぜ LGTM の読書会をチームで始めたか? • AI活⽤によってPR作成数が相対的に増加
• レビューに費やす時間が多くなってきた • 「レビューの重要性が上がってきてるよね」という認 識がチーム内で⼤きくなってきた • 毎週⾦曜⽇にテックトークという技術ネタ雑談タイム を設けていたが若⼲ネタが枯渇していた 4
Looks Good To Me 読書会をチームで始めた理由 なぜ LGTM の読書会をチームで始めたか? • AI活⽤によってPR作成数が相対的に増加
• レビューに費やす時間が多くなってきた • 「レビューの重要性が上がってきてるよね」という認 識がチーム内で⼤きくなってきた • 毎週⾦曜⽇にテックトークという技術ネタ雑談タイム を設けていたが若⼲ネタが枯渇していた 5
「なんか良さそう」 という興味駆動で 勉強会がスタート! 6
読書会によって⽣まれた効果 読書会で⽣まれたチーム‧プロセスの変化 • PRオープン前のセルフレビュー項⽬の整備 • コメントシグナルの改善&チーム内認識の統⼀ • レビュー後にApprove or Request
Changeを必ず明⽰ ◦ マージブロックか否かを迷わなくなった • PRタイトルをConventional Commits仕様に統⼀ 7
読書会によって⽣まれた効果 読書会で⽣まれたチーム‧プロセスの変化 • PRオープン前のセルフレビュー項⽬の整備 • コメントシグナルの改善&チーム内認識の統⼀ • レビュー後にApprove or Request
Changeを必ず明⽰ ◦ マージブロックか否かを迷わなくなった • PRタイトルをConventional Commits仕様に統⼀ 8
読書会前後のコメントの⽐較 読書会以前のコメント 9
読書会前後のコメントの⽐較 読書会以前のコメント 10
読書会前後のコメントの⽐較 11 正しくない気がするので確認をお願いします • ⼀⾒問題なさそうな、よくあるやりとりではある • 強いて⾔うのであれば ◦ レビュアーの気になりポイントがやや不明瞭 ◦
PR作成者に求めるNext Actionが少し曖昧 • 結果としてレビュアーの求めることとPR作成者が⾏っ た対応に齟齬が⽣じてしまっている
読書会前後のコメントの⽐較 読書会以前のコメント 12
読書会前後のコメントの⽐較 読書会以前のコメント 13
読書会前後のコメントの⽐較 14 [MUSTだけどnits]ファイル分けたいです! • これも決して悪いコメントではない • [MUSTだけどnits]というコメントシグナルが ◦ なんとなく⾔いたいことはわかる ◦
ただマージブロックなのかどうか不明確 • 結果として対応はするが「コメントシグナル意味ある かな?」というモヤりが残る
読書会後にチームは どうなれたか? 15
読書会前後のコメントの⽐較 16 トリプルRパターンでのコメントを意識 • 依頼(Request): ◦ PR作成者に何をしてほしいのか • 理由(Rationale): ◦
依頼が必要な理由の説明 • 結果(Result): ◦ PR作成者が変更を⽐較できる測定可能な最終状態
読書会前後のコメントの⽐較 トリプルRパターンに沿ったコメント 17
読書会前後のコメントの⽐較 トリプルRパターンに沿ったコメント 18 依頼
読書会前後のコメントの⽐較 トリプルRパターンに沿ったコメント 19 理由
読書会前後のコメントの⽐較 トリプルRパターンに沿ったコメント 20 結果
読書会前後のコメントの⽐較 21 コメントシグナルの統⼀ • マージブロックとするもの ◦ needs change: ▪ 1回のコミットで解決できる⼩さな変更と修正
◦ needs rework: ▪ ⼤きな⼿直しやリファクタリングを必要とする変更 ◦ align: ▪ 機能的に問題ないが、チーム規約に準拠していない • 未対応でもマージしてよいもの ◦ levelup: ▪ 品質向上のために変更が推奨されるがPRの承認は⽌めない ◦ nitpick: ▪ コードに影響を与えない単なる主観的なコメント
読書会前後のコメントの⽐較 コメントシグナルの活⽤ 22
読書会前後のコメントの⽐較 23 必須ではないがRSpecの保守性も気にしたい コメントシグナルの活⽤
読書会前後のコメントの⽐較 24 規約&他実装箇所に反した書き⽅は直したい コメントシグナルの活⽤
まとめ 1. 気軽な気持ちで始めた読書会だった 2. いざ読み進めていくとアンチパターンに⼼当たりがあった 3. コメントシグナル‧PRタイトルの統⼀などすぐに開始できる 事例が多数あった 4. 本⽂中の事例以外でも、全員で同じ本を読むことによって
「レビュー後は絶対にApproveかRequest Changesのどちら かをつけよう!」などの共通認識が明⽂化された チームのコードレビューの質が向上!
Looks Good To Me をチームで読んで 気持ちの良いコード レビューのプロセス を確⽴していこう! 26
ご清聴ありがとうご ざいました! 27