デュアルトラックアジャイルとの向き合い方

by Takafumi ONAKA

Slide 1

Slide 1 text

デュアルトラックアジャイルとの向き合い方 id:onk 2023-03-08 開発生産性の取り組みをオフラインで語り合う LT 1

Slide 2

Slide 2 text

自己紹介 ● 大仲能史 a.k.a. id:onk ● 株式会社はてなチーフエンジニア 2

Slide 3

Slide 3 text

3 今日の話

Slide 4

Slide 4 text

4 デュアルトラックアジャイル

Slide 5

Slide 5 text

ソフトウェア開発の2つのトラック 5 https://www.jpattonassociates.com/dual-track-development/

Slide 6

Slide 6 text

2つのサイクル 6 https://www.scrumatscale.com/scrum-at-scale-guide-online/#the-components-of-scrumatscale

Slide 7

Slide 7 text

2つのサイクル 7 ● デリバリー ○ コーディングを伴う ○ いわゆるスクラムチームの仕事 ○ リリースしてユーザの反応を伺う ● ディスカバリー ○ より仮説検証的なPO側の仕事 ○ 作るものを決める

Slide 8

Slide 8 text

目的地に辿り着くことで例えると ● ディスカバリーは地図 ○ どこに向かうかを見定める ● デリバリーは車 ○ 色んな車があるよね 8

Slide 9

Slide 9 text

どちらも大事 ● 地図が無いと迷子になる ● 速度が遅いと時間が掛かる 9

Slide 10

Slide 10 text

両輪で回す 10 https://www.scrumatscale.com/scrum-at-scale-guide-online/#the-components-of-scrumatscale

Slide 11

Slide 11 text

アウトカムを出す 11 デリバリーディスカバリー

Slide 12

Slide 12 text

12 アウトカムに結びつかないアウトプットは、高速にゴミを作っている

Slide 13

Slide 13 text

13 というのがデュアルトラックアジャイル

Slide 14

Slide 14 text

14 論点ズラしてない？

Slide 15

Slide 15 text

遅い車はとにかく問題 ● 地図が合っていても三輪車じゃ辿り着けない ○ せめてエンジン付き。できれば常に整備しておきたい ● 方向がベクトル90度以内に収まってればいい ○ 象限が合っていれば十分 ■ それ以上の精度が本当に必要？ ○ サイクルを素早く回せば修正できる ■ 回すことすらできない方が問題が大きい 15

Slide 16

Slide 16 text

高速ゴミ製造機をより好む ● もし良い企画に当たったら高速にアウトカムを作れる地力がある ○ 止まった時計も1日2回は正しい時間を指す ● 高速にPDCAを回すことができる ○ PDCAを回した数だけチームとしての強さが増す ○ 改善している実感を手に入れられ、役割分担が自然とされ、目標達成にコミットできるチームになっていく 16

Slide 17

Slide 17 text

アウトプットを出す 17 ここが低いと話にならない

Slide 18

Slide 18 text

もちろん場合による ● 打席に立てる回数には限りがある ● ゴミを作ってる余裕がまったく無いなら当たる企画だけを作るしかない ○ アウトにならないようなヒットを狙う ○ 打率を上げることに注力する必要がある 18

Slide 19

Slide 19 text

19 アウトプットを出すための工夫

Slide 20

Slide 20 text

アウトプットを出すための工夫 ● 手元の工夫 ● チームの工夫 20

Slide 21

Slide 21 text

手元の工夫 ● 生産性が高い＝タイプ数が少ない ○ main[Command+Enter] で public static void main(String[] args) になると、6ストロークで38文字の生産性 ○ 懇親会でお話🔥しましょう ■ おまじないは少ない方が良い v.s. ■ 静的解析のためのヒントは多い方が良い 21

Slide 22

Slide 22 text

手元の工夫 ● 高速に打ち続けることにもこだわっています ○ 思考のスピードで編集しよう！ ■ 懇親会でお話🔥しましょう ○ 考える時間もゼロにして入力し続けたい ■ いかに設計の素振りをしているか、設計の共通化を行っているかが決め手 22

Slide 23

Slide 23 text

アウトプットを出すための工夫 ● 手元の工夫 ● チームの工夫 23

Slide 24

Slide 24 text

チームの工夫 ● バリューストリームマップを作って改善する ○ コスパの良い改善ポイントを見つけられる ○ 開発パフォーマンス指標とバリューストリームマップでチーム改善をする - $shibayu36->blog; 24

Slide 25

Slide 25 text

チームの工夫 ● バリューストリームマップのコツ ○ 成果物の受け渡しポイントに着目する ○ 成果物 (作った PR) がレビューされていない時間 ○ 成果物 (merge した PR) がリリースされていない時間 ○ 職種間、チーム間で、渡した後に着手するまでや戻ってくるまでに待ちが発生していないか ■ 職種横断チームに組み替えることで短くなるかもしれない 25

Slide 26

Slide 26 text

チームの工夫 ● バディ組み替えで生産性向上 ○ チームより小さなバディにタスクをアサインして、どんどん終わらせる目標に ○ バディで終わらせられるタスクが減ったら生産性は戻った 26

Slide 27

Slide 27 text

27 まとめ

Slide 28

Slide 28 text

まとめ ● デュアルトラックアジャイルという考え方 ○ デリバリーとディスカバリーの両輪 ● レベル1生産性の高い良いチームにしたい ○ 両輪なので、片輪であるデリバリーも大事 ● そのために個人やチームで改善していく ○ 僕らの事例を紹介しました 28