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
120
Looks Good To Me 読書会でレビューの質が向上した話
DaisukeShinoku
July 10, 2025
Tweet
Share
More Decks by DaisukeShinoku
See All by DaisukeShinoku
Roppongi.rbへの会場提供を始めて1年が経ちました
daisukeshinoku
0
33
create_tableをしただけなのに〜囚われのuuid編〜
daisukeshinoku
0
540
最短リリースの壁を超えろ!チーム立ち上げから71営業日でプロダクトリリースした話
daisukeshinoku
1
1.8k
Ruby と Rails の小ネタ集
daisukeshinoku
3
2.1k
受託開発から人事労務SaaSに転職して1年間でやったこと
daisukeshinoku
2
2k
今の SmartHR にエンジニアで入社するとどうなるの?
daisukeshinoku
8
6.8k
テンショク・ジャーニー —航海士だった僕が、SaaS企業でエンジニアとして働き始めるまで—
daisukeshinoku
1
2k
仕事観がアップデートされた読書体験 「エンジニアリング組織論への招待」を読んで
daisukeshinoku
2
1.9k
はじめてのアジャイル・スクラム開発での新鮮な発見
daisukeshinoku
2
2.7k
Other Decks in Programming
See All in Programming
CSS Linter の現在地 2025年のベストプラクティスを探る
ryo_manba
10
3.2k
iOSDC.pdf
chronos2500
2
640
ABEMAモバイルアプリが Kotlin Multiplatformと歩んだ5年 ─ 導入と運用、成功と課題 / iOSDC 2025
akkyie
0
300
プログラミングどうやる? ~テスト駆動開発から学ぶ達人の型~
a_okui
0
190
iOSエンジニア向けの英語学習アプリを作る!
yukawashouhei
0
170
CSC305 Lecture 02
javiergs
PRO
1
260
いま中途半端なSwift 6対応をするより、Default ActorやApproachable Concurrencyを有効にしてからでいいんじゃない?
yimajo
2
260
CSC509 Lecture 01
javiergs
PRO
1
430
AccessorySetupKitで実現するシームレスなペアリング体験 / Seamless pairing with AccessorySetupKit
nekowen
0
210
ポスターセッション: 「まっすぐ行って、右!」って言ってラズパイカーを動かしたい 〜生成AI × Raspberry Pi Pico × Gradioの試作メモ〜
komofr
0
880
エンジニアとして高みを目指す、 利益を生み出す設計の考え方 / design-for-profit
minodriven
23
11k
iOSアプリの信頼性を向上させる取り組み/ios-app-improve-reliability
shino8rayu9
0
120
Featured
See All Featured
Designing for Performance
lara
610
69k
The World Runs on Bad Software
bkeepers
PRO
71
11k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Agile that works and the tools we love
rasmusluckow
330
21k
The Power of CSS Pseudo Elements
geoffreycrofte
78
6k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
What's in a price? How to price your products and services
michaelherold
246
12k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
We Have a Design System, Now What?
morganepeng
53
7.8k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
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