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
レビューのつらさを倒したい/To Defeat the Pain of Reviewing
Search
Hiromu Shioya
November 15, 2021
Technology
3
5.2k
レビューのつらさを倒したい/To Defeat the Pain of Reviewing
2021/11/05 SHIOYA, Hiromu / @kwappa
社内向け講演「レビューのつらさを倒したい」
Hiromu Shioya
November 15, 2021
Tweet
Share
More Decks by Hiromu Shioya
See All by Hiromu Shioya
My Generation 年配者がこの先生きのこるには (Developers CAREER Boost 2024 Edition)/My Generation How elder engineers can survive
kwappa
4
1.5k
三大あいまい能力/Three ambiguous abilities
kwappa
1
200
My Generation 年配者がこの先生きのこるには/My Generation How elder engineers can survive
kwappa
3
6.1k
勝ちに不思議の勝ちあり、負けに不思議の負けあり/There is a mystery to win, but there is no mystery to lose
kwappa
0
250
伸び代だらけのチームに 伸びてもらうための施策100連発/100 measures to grow up a team with a lot of growth potential
kwappa
1
180
HIGH OUTPUT Infrastructure Engineering
kwappa
1
25
礼節とHRTと心理的安全性/Civility, HRT and Psychological Safety
kwappa
0
760
エンジニアのキャリアをちょっと楽しくする3本の軸/Three Pillars to Make an Engineer's Career More Enjoyable
kwappa
2
3.5k
デスマーチから身を守るたったひとつの方法
kwappa
2
7k
Other Decks in Technology
See All in Technology
Dapr For Java Developers SouJava 25
salaboy
1
130
Agile TPIを活用した品質改善事例
tomasagi
0
310
新卒エンジニア研修の試行錯誤と工夫/nikkei-tech-talk-31
nishiuma
0
200
Explainable Software Engineering in the Public Sector
avandeursen
0
360
BCMathを高速化した一部始終をC言語でガチ目に解説する / BCMath performance improvement explanation
sakitakamachi
2
1.2k
モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま
panda_program
7
2k
Go製のマイグレーションツールの git-schemalex の紹介と運用方法
shinnosuke_kishida
1
410
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略
ryu955
2
400
Security response for open source ecosystems
frasertweedale
0
100
Javaの新しめの機能を知ったかぶれるようになる話 #kanjava
irof
3
4.9k
20250328_OpenAI製DeepResearchは既に一種のAGIだと思う話
doradora09
PRO
0
150
「ラベルにとらわれない」エンジニアでいること/Be an engineer beyond labels
kaonavi
0
120
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
470
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
BBQ
matthewcrist
88
9.5k
Docker and Python
trallard
44
3.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
31
4.7k
How to train your dragon (web standard)
notwaldorf
91
5.9k
How to Ace a Technical Interview
jacobian
276
23k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
What's in a price? How to price your products and services
michaelherold
245
12k
GraphQLとの向き合い方2022年版
quramy
45
14k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
51
2.4k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.4k
Transcript
レビューのつらさを倒したい 2021/11/05 SHIOYA, Hiromu / @kwappa
レビューとはなんじゃ ここでは「仕事の検証、見直し」 エンジニアは「コードレビュー」をよくやる 他の職種でもあると思うのでよしなに解釈してください
用語の確認 レビュアー レビュー「する」人 レビュイー レビュー「される」人 つまり「レビューをお願いする」人
最近よく聞くつらみ レビュー「する」のがつらい PRが来る→レビューしなきゃ レビュー「してもらう」のがつらい レビューお願いしたい**さんが忙しそう
レビューがつらいことによる害 価値を届けるまでのリードタイムが増える とはいえノーチェックで出すのはまずいが…
そのレビュー意味あんの? トリプルチェックの弊害 #現場猫 実写版 実写版・現場猫その5 トリプルチェック。
レビューの流れ レビュイー なにかコードを書く Pull Requestでレビューを依頼する レビュアー レビューの依頼が届く レビューする Approve する
Approve : 承認? approve 1.〈…を〉よいと認める,〈…に〉賛成する. 2.〈…を〉(正式に)承認する,認可する. レビューにおける approve は「賛成」 LGTM
= Looks Good To Me : 「よさそう」 つい「承認」だと思いがち レビュイー : だってレビュアーが 承認 したじゃん レビュアー : 絶対ヨシ
なぜレビューがつらいのか レビュアーがなんにもうれしくないから レビューの時間は自分のタスクが進まない 承認 する責任がある? 不具合があったら自分の責任? うれしくないから後回しにする レビュイーもつらい プロダクトもつらい
こんなのもうイヤだ 仕事のやり方を変えよう
その1 : 責任所在 レビュイー : タスクの責任者 仕事に責任を持つ 不安を解消するためにレビューを依頼する レビュアー :
タスクのサポーター レビュイーの不安を解消する手助けをする 知識や経験でタスクの品質向上に 貢献 する 承認 じゃないよ
その2 : 時間配分 レビューは必要 なので業務の時間に織り込む なのでリードタイムに織り込む
その3 : プロセス改善 プロセス改善? レビューの目的を明確に レビューのサイクルを短く レビュイーが責任を持つ
レビューの目的を明確に レビュイー : 不安を取り除く タスクを説明する 目的は何か、そのために何をしたか、自分で何を確認したか 確認しやすい粒度でレビューを依頼する 不安を言語化する 見てほしい、知恵を貸してほしいポイントを明示 不安を解消する
レビューをもとにタスクの品質をあげる →手直し上等
レビューの目的を明確に レビュアー : 貢献する レビュイーの不安を取り除く そのための approve = 賛成 知識・経験からのコメント
タスクの品質が向上するために レビュイーが成長するために モヒカンの手斧はいらない
レビューのサイクルを短く レビューが通れば完了 例 : 基本設計→詳細設計→実装→試験→レビュー テストコードまで書いてレビュー依頼 「そのテーブル名いまいちだよね」→ レビューの範囲を小さくする 例 :
基本設計→レビュー→詳細設計→レビュー→… 不安を小さい単位で解消する よりよいやり方を議論する →これがペアプロ / モブプロの原点
レビュイーが責任を持つ タスクをdoneにするのはレビュイーの 責任 レビューの単位を小さくする レビューするべき箇所を明示する そのためのサポートをするのがレビュアーの 貢献 レビューを溜め込まない 当然発生する業務として織り込む 不安を取り除く
知識と経験 態度や言葉遣い
まとめ : レビューをつらくなくしよう レビュイーが責任を持つ レビュアーは貢献する お互い協力する →最適な結果のために