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
4.7k
レビューのつらさを倒したい/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
エンジニアのキャリアをちょっと楽しくする3本の軸/Three Pillars to Make an Engineer's Career More Enjoyable
kwappa
0
2.7k
デスマーチから身を守るたったひとつの方法
kwappa
2
6.2k
メタエンジニアリングという選択肢/The choice named meta-engineering
kwappa
1
1.6k
リモートワーク時代のコミュニケーションデザイン : コーチングに学ぶ1on1の基礎/Learn Basics of 1on1 from Coaching
kwappa
1
1.7k
The Show Must Go On 終わりのない道のなかばでふりかえる俺とDevLOVE / The Show Must Go On Looking back of me and DevLOVE in the middle of the endless road
kwappa
0
540
プロフェッショナルなエンジニアのためのコミュ力概論/Overview of communication skills for professional engineers
kwappa
2
3k
登壇は最強の生存戦略である / Speaking in conferences is the best survival strategy
kwappa
0
3.9k
礼節から育てるチームの健康と信頼性 / Improve team health and reliability starting with civility
kwappa
8
25k
塹壕よりDevOpsとSRE / DevOps and SRE from the Trenches
kwappa
4
5.6k
Other Decks in Technology
See All in Technology
require(ESM)とECMAScript仕様
uhyo
1
230
EMとして2023年度に頑張ったこと / What we did well in FY2023 as a EM
pauli
1
170
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
3
550
長期間TiDBを使ってきた話 @ 私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT / Experiences with TiDB Over Time
chibiegg
2
890
Vertex AI を中心に 生成AIのアップデートを共有します
kaz1437
0
300
エンジニア候補者向け資料2024.04.24.pdf
macloud
0
3.3k
現代CSSフレームワークの内部実装とその仕組み
poteboy
8
3.6k
反実仮想機械学習とは何か
usaito
PRO
11
4.5k
アクセシビリティを考慮したUI/CSSフレームワーク・ライブラリ選定
yajihum
2
1k
本当のAWS基礎
toru_kubota
0
510
GraphQL 成熟度モデルの紹介と、プロダクトに当てはめた事例 / GraphQL maturity model
mh4gf
7
1.3k
Gitlab本から学んだこと - そーだいなるプレイバック / gitlab-book
soudai
4
270
Featured
See All Featured
Debugging Ruby Performance
tmm1
70
11k
Making the Leap to Tech Lead
cromwellryan
124
8.5k
Git: the NoSQL Database
bkeepers
PRO
422
63k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
648
58k
What's in a price? How to price your products and services
michaelherold
237
11k
Writing Fast Ruby
sferik
621
60k
Designing on Purpose - Digital PM Summit 2013
jponch
110
6.5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
Building Applications with DynamoDB
mza
88
5.6k
[RailsConf 2023] Rails as a piece of cake
palkan
23
3.9k
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にするのはレビュイーの 責任 レビューの単位を小さくする レビューするべき箇所を明示する そのためのサポートをするのがレビュアーの 貢献 レビューを溜め込まない 当然発生する業務として織り込む 不安を取り除く
知識と経験 態度や言葉遣い
まとめ : レビューをつらくなくしよう レビュイーが責任を持つ レビュアーは貢献する お互い協力する →最適な結果のために