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
64
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
Is Xcode slowly dying out in 2025?
uetyo
1
270
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
390
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.1k
NPOでのDevinの活用
codeforeveryone
0
830
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
効率的な開発手段として VRTを活用する
ishkawa
0
140
Discover Metal 4
rei315
2
130
Python型ヒント完全ガイド 初心者でも分かる、現代的で実践的な使い方
mickey_kubo
1
120
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
760
Team operations that are not burdened by SRE
kazatohiei
1
310
ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質の マネジメント
takuya542
1
13k
XP, Testing and ninja testing
m_seki
3
240
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Optimizing for Happiness
mojombo
379
70k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
What's in a price? How to price your products and services
michaelherold
246
12k
Being A Developer After 40
akosma
90
590k
Visualization
eitanlees
146
16k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Navigating Team Friction
lara
187
15k
Making Projects Easy
brettharned
116
6.3k
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