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
レビューは最優先にするようにしている
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Tomohiko Himura
December 14, 2023
0
330
レビューは最優先にするようにしている
社内でやったLT資料です
Tomohiko Himura
December 14, 2023
Tweet
Share
More Decks by Tomohiko Himura
See All by Tomohiko Himura
Marpでmermaidは簡単だときいたけど
eiel
0
1.9k
バイナリ読むのにElixirしてみた
eiel
0
95
アジャイルはさておきMake People Awesomeしたい
eiel
0
200
再考 Fourkeys メトリクス
eiel
2
700
Test mockをSnapshot testする
eiel
0
150
devenvに入門した
eiel
1
130
関数プログラミングの考え方
eiel
1
350
逆コンウェイ作戦はフィードバックループを作るために 逆向きの流れをつくること (5分版)
eiel
0
470
組織のパフォーマンスを高めるために 第1話 学習と文化
eiel
0
270
Featured
See All Featured
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
210
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
650
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
440
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
360
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
150
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
1k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
860
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
64
52k
Leo the Paperboy
mayatellez
4
1.6k
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
1.9k
Transcript
レビューは最優先で やるようにしている 2023-12-14 ひむらともひこ
自己紹介 ひむら ともひこ 最近遊びたいこと(希望) • Linux Desktopの設定(NixOS) • 要求の管理
レビューはなるべく 最優先でやるようにしている
レビューされない場合は だいたいやり忘れているので 言ってください
なぜ?
組織パフォーマンスを落とす要因
リードタイムを無駄に長くする
私のリードタイムの大体の定義 デリバリー レビュー CI 実装 企画 起案 リードタイム 変更リードタイム 本当に短くしたい時間
でも、メトリクスとしては揺れ幅が大きく使いづらい メトリクスとして代わりに使う時間 完成してからユーザに届くまでの時間 できてるのにユーザに届かないのは無駄
変更のリードタイムと人間の関与 デリバリー レビュー CI 自動化されている 自動化されている 待たせた分だけ長くなる
変更のリードタイムが長くなる要因は レビューしないせいで起きうる CIが長かったり、デリバリーが自動化されてなかったり、 承認が必要だったりする場合は誤差になる場合はある。
まとめ
組織のパフォーマンスをあげたい • 変更のリードタイムは短くなって欲しい ◦ できてるのにユーザに届かないのは、できてないのと同じ • レビューが遅くなると遅くなった分だけ変更のリードタイムが伸びる ◦ 1日で開発したものが2日レビューされないものすごく無駄 •
自分の仕事が遅くなるが組織のパフォーマンスはむしろ良くなる ◦ ほんとに?
レビューはなるべく 最優先でやるようにしている 2
自分の仕事が遅くなっても 組織のパフォーマンスは上がるから
ある種の理想のフロー CD レビュー待ち CI 実装 レビュー Aさん Bさん
X1 ある種の現実。自分の仕事優先 CD レビュー待ち CI 実装 Aさんのレビュー Aさん Bさん 実装
CI Bさんのレビュー レビュー待ち CD Aさんの作業の無駄な時間 = Bさんの実装時間 - Aさんの実装時間 Bさんの作業の無駄な時間 = 0 無駄な時間
O2 現実的なある種の理想 CD レビュー待ち CI 実装 Aさんのレビュー Aさん Bさん 実装
CI レビュー待ち CD Aさんの作業の無駄な時間 = 0 Bさんの作業の遅延 = Aさんのレビュー 実装 Bさんのレビュー
例示は理解の試金石 変更のリードタイムを伸ばすもの(ロス) - Aさんの作業の無駄な時間 - Bさんの作業の遅延 例1 実装時 間 レビュー
に使っ た時間 CIの時 間 CDの時 間 X1 ロス X1リー ドタイム O2 ロス O2 リー ドタイム Aさん 10分 20分 5分 5分 60-10 = 50分 65分 0分 15分 Bさん 60分 5分 5分 5分 0分 30分 5分 35分 合計 95分 50分
例示は理解の試金石 2 例1 実装時 間 レビュー に使っ た時間 CIの時 間
CDの時 間 X1 ロス X1リー ドタイム O2 ロス O2 リー ドタイム Aさん 1日 60分 5分 5分 2日 2日 0分 40分 Bさん 3日 30分 5分 5分 0分 70分 30分 100分 合計 2日 140分
おわかりいただけただろうか
まとめ 変更のリードタイムという観点でみると - レビューが遅くなるのはマジでやばい - なるべく待たさないでやろう