Slide 1

Slide 1 text

レビューは最優先で やるようにしている 2023-12-14 ひむらともひこ

Slide 2

Slide 2 text

自己紹介 ひむら ともひこ 最近遊びたいこと(希望) ● Linux Desktopの設定(NixOS) ● 要求の管理

Slide 3

Slide 3 text

レビューはなるべく 最優先でやるようにしている

Slide 4

Slide 4 text

レビューされない場合は だいたいやり忘れているので 言ってください

Slide 5

Slide 5 text

なぜ?

Slide 6

Slide 6 text

組織パフォーマンスを落とす要因

Slide 7

Slide 7 text

リードタイムを無駄に長くする

Slide 8

Slide 8 text

私のリードタイムの大体の定義 デリバリー レビュー CI 実装 企画 起案 リードタイム 変更リードタイム 本当に短くしたい時間 でも、メトリクスとしては揺れ幅が大きく使いづらい メトリクスとして代わりに使う時間 完成してからユーザに届くまでの時間 できてるのにユーザに届かないのは無駄

Slide 9

Slide 9 text

変更のリードタイムと人間の関与 デリバリー レビュー CI 自動化されている 自動化されている 待たせた分だけ長くなる

Slide 10

Slide 10 text

変更のリードタイムが長くなる要因は レビューしないせいで起きうる CIが長かったり、デリバリーが自動化されてなかったり、 承認が必要だったりする場合は誤差になる場合はある。

Slide 11

Slide 11 text

まとめ

Slide 12

Slide 12 text

組織のパフォーマンスをあげたい ● 変更のリードタイムは短くなって欲しい ○ できてるのにユーザに届かないのは、できてないのと同じ ● レビューが遅くなると遅くなった分だけ変更のリードタイムが伸びる ○ 1日で開発したものが2日レビューされないものすごく無駄 ● 自分の仕事が遅くなるが組織のパフォーマンスはむしろ良くなる ○ ほんとに?

Slide 13

Slide 13 text

レビューはなるべく 最優先でやるようにしている 2

Slide 14

Slide 14 text

自分の仕事が遅くなっても 組織のパフォーマンスは上がるから

Slide 15

Slide 15 text

ある種の理想のフロー CD レビュー待ち CI 実装 レビュー Aさん Bさん

Slide 16

Slide 16 text

X1 ある種の現実。自分の仕事優先 CD レビュー待ち CI 実装 Aさんのレビュー Aさん Bさん 実装 CI Bさんのレビュー レビュー待ち CD Aさんの作業の無駄な時間 = Bさんの実装時間 - Aさんの実装時間 Bさんの作業の無駄な時間 = 0 無駄な時間

Slide 17

Slide 17 text

O2 現実的なある種の理想 CD レビュー待ち CI 実装 Aさんのレビュー Aさん Bさん 実装 CI レビュー待ち CD Aさんの作業の無駄な時間 = 0 Bさんの作業の遅延 = Aさんのレビュー 実装 Bさんのレビュー

Slide 18

Slide 18 text

例示は理解の試金石 変更のリードタイムを伸ばすもの(ロス) - 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分

Slide 19

Slide 19 text

例示は理解の試金石 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分

Slide 20

Slide 20 text

おわかりいただけただろうか

Slide 21

Slide 21 text

まとめ 変更のリードタイムという観点でみると - レビューが遅くなるのはマジでやばい - なるべく待たさないでやろう