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
5.6k
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
レビューのつらさを倒したい/To Defeat the Pain of Reviewing
2021/11/05 SHIOYA, Hiromu / @kwappa
社内向け講演「レビューのつらさを倒したい」
Hiromu Shioya
November 15, 2021
More Decks by Hiromu Shioya
See All by Hiromu Shioya
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
4
1k
礼節とHRTと心理的安全性(2025年9月版)/Civility, HRT and Psychological Safety(Sep. 2025 edition)
kwappa
0
290
はじめての転職講座/The Guide of First Career Change
kwappa
6
5.7k
My Generation 年配者がこの先生きのこるには (Developers CAREER Boost 2024 Edition)/My Generation How elder engineers can survive
kwappa
5
2.1k
三大あいまい能力/Three ambiguous abilities
kwappa
1
420
My Generation 年配者がこの先生きのこるには/My Generation How elder engineers can survive
kwappa
3
6.8k
勝ちに不思議の勝ちあり、負けに不思議の負けあり/There is a mystery to win, but there is no mystery to lose
kwappa
0
430
伸び代だらけのチームに 伸びてもらうための施策100連発/100 measures to grow up a team with a lot of growth potential
kwappa
1
340
HIGH OUTPUT Infrastructure Engineering
kwappa
1
100
Other Decks in Technology
See All in Technology
ローカルLLMとLINE Botの組み合わせ その3 / LINE DC Generative AI Meetup #8
you
PRO
0
130
最近評価が難しくなった
maroon8021
0
260
知見・人・API・DB・予算 ─ ナイナイ尽くしだった人事データ整備 with dbt、5年間の学び
ken6377
1
170
AWS Blocks を触ってみた/first-tach-aws-blocks
fossamagna
2
150
なぜ人は自分のプロジェクトを 「なんちゃってアジャイル」と 自嘲するのか
kozotaira
0
260
Terraform共通モジュールをチーム横断で“変えられる”運用へ ― リリースと適用の分離
kekke_n
1
2k
なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜 / Why our SRE practices aren't really working
vtryo
2
2.8k
AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤
sakajunquality
2
2.8k
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
550
『AIに負けない』より『AIと遊ぶ』」〜ワクワクが最強のテスト・QA学習戦略_公開用
odan611
2
520
アカウントが増えてからでは遅い? ~ マルチアカウント統制の勘所 ~
kenichinakamura
0
190
AIに「使われる」時代のSaaS戦略 〜既存WebAPIのMCPサーバー化における開発ノウハウ〜
ekispert_api
0
300
Featured
See All Featured
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
330
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
55k
YesSQL, Process and Tooling at Scale
rocio
174
15k
The Cult of Friendly URLs
andyhume
79
6.9k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Designing Experiences People Love
moore
143
24k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
200
The Language of Interfaces
destraynor
162
27k
Marketing to machines
jonoalderson
1
5.6k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
960
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にするのはレビュイーの 責任 レビューの単位を小さくする レビューするべき箇所を明示する そのためのサポートをするのがレビュアーの 貢献 レビューを溜め込まない 当然発生する業務として織り込む 不安を取り除く
知識と経験 態度や言葉遣い
まとめ : レビューをつらくなくしよう レビュイーが責任を持つ レビュアーは貢献する お互い協力する →最適な結果のために