強いチームと開発生産性

by Takafumi ONAKA

Slide 1

Slide 1 text

強いチームと開発生産性 id:onk 2024-11-15 開発生産性Kaigi 1

Slide 2

Slide 2 text

自己紹介 ● 大仲能史 a.k.a. id:onk ● 芸歴20年目 ○ バックエンドとインフラが得意 ● 株式会社はてな ○ チーフエンジニア ○ いろんな役割があるけど、今日は「開発チームの一員」の立場で話します 2

Slide 3

Slide 3 text

3 開発生産性とは

Slide 4

Slide 4 text

開発生産性とは ● 生産性＝生産する能力 ● アウトプット / インプット ● 突っ込んだ量に対して、返ってくる量の割合 4

Slide 5

Slide 5 text

開発生産性とは ● インプット ○ 労働人数 ○ 労働時間 ○ 開発人件費 ○ 総事業コスト 5

Slide 6

Slide 6 text

開発生産性とは ● アウトプット ○ 書いたコード量 ○ リリースした施策数 ○ リリースした施策の効果 ○ 売上 ○ 新しい体験を提供し、人の生活を豊かにした量 6

Slide 7

Slide 7 text

開発生産性とは ● 単位時間あたりのアウトプット ○ Lv1: 仕事量（書いたコード量〜施策数） ○ Lv2: 期待付加価値（施策数〜施策の想定KPI変化） ○ Lv3: 実現付加価値（KPI変化〜売上） 7

Slide 8

Slide 8 text

開発生産性とは 8 https://qiita.com/hirokidaichi/items/53f0865398829bdebef1

Slide 9

Slide 9 text

9 アウトプットとアウトカム

Slide 10

Slide 10 text

アウトプットとアウトカム ● アウトプット ○ 自分が出力した量 ○ 仕事量〜期待付加価値 ● アウトカム ○ 自分が出力したことによって起きた、対象の変化量 ○ 期待付加価値〜実現付加価値 10

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

15 デュアルトラック https://www.jpattonassociates.com/dual-track-development/

Slide 16

Slide 16 text

デュアルトラック ● 仮説検証サイクルを早く回す ● 仮説検証で最も遅い方法は、製品を作ること ○ コストを掛けて本物を作る前にダメな案を高速に潰す ● ディスカバリートラックで確からしさを検証 ● 検証済みのものをデリバリートラックで作る 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

正しいものを、正しく作る ● シフトレフト ○ 間違ったものを早めに潰す ○ 修正が早い段階であればあるほどコストが掛からない ○ リリース -> テスト -> コードを書く時 -> 企画段階 21

Slide 22

Slide 22 text

22 ディスカバリーとデリバリーは両輪

Slide 23

Slide 23 text

23 と、言われているが開発チーム目線では両輪ではない

Slide 24

Slide 24 text

24 デリバリーが先、ディスカバリーが後

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

開発生産性 26 アウトプットここが低いと話にならない

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

29 アウトプットを評価する

Slide 30

Slide 30 text

30 Four Keys

Slide 31

Slide 31 text

Four Keys ● デプロイの頻度 ● 変更のリードタイム ● 変更障害率 ● サービス復旧時間 31

Slide 32

Slide 32 text

Four Keys 32 https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition

Slide 33

Slide 33 text

33 強いチームはDevOpsが前提

Slide 34

Slide 34 text

DevOps 34 Kharnagy, CC BY-SA 4.0 ● DevOpsツールチェーンの活用 ● 自動化 ● 継続的デリバリー ● 組織文化の転換

Slide 35

Slide 35 text

Four Keys (2021) 35 https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition

Slide 36

Slide 36 text

36 開発生産性を阻害する力

Slide 37

Slide 37 text

ツラみが自然と溜まっていく例 ● データの蓄積によるレスポンス悪化 ● 仕様変更による設計の無理 ● ライブラリの更新への追随を怠る ● 突然応答しなくなるサーバ ● 人の流動によるノウハウの低下 37

Slide 38

Slide 38 text

38 何もしないと開発生産性はどんどん悪化する

Slide 39

Slide 39 text

39 ツラみが溜まってきたのを検知したい

Slide 40

Slide 40 text

ツラみの検知とFour Keys ● デプロイの頻度 ● 変更のリードタイム ● 変更障害率 ● サービス復旧時間 40

Slide 41

Slide 41 text

ツラみの検知とFour Keys ● デプロイの頻度 ○ おそらく変わらないだろう ● 変更のリードタイム ● 変更障害率 ● サービス復旧時間 41

Slide 42

Slide 42 text

ツラみの検知とFour Keys ● デプロイの頻度 ● 変更のリードタイム ○ 徐々に劣化していくはず ● 変更障害率 ● サービス復旧時間 42

Slide 43

Slide 43 text

ツラみの検知とFour Keys ● デプロイの頻度 ● 変更のリードタイム ● 変更障害率 ○ 徐々に劣化していくはず ● サービス復旧時間 43

Slide 44

Slide 44 text

ツラみの検知とFour Keys ● デプロイの頻度 ● 変更のリードタイム ● 変更障害率 ● サービス復旧時間 ○ チームの練度がどこまで下がるか次第 44

Slide 45

Slide 45 text

45 Four Keysでツラみの検知はできそうだけど基準が欲しい

Slide 46

Slide 46 text

46 SLO

Slide 47

Slide 47 text

SLOとは ● サービスレベル目標 (Service Level Objective) ● サービスにおいて目標値とされる「適切な信頼性のレベル」 47

Slide 48

Slide 48 text

適切な信頼性のレベル ● 100%の信頼性を目指すのではなく、見極める ● 信頼性にはコストが掛かる ○ 可用性 99.9% => 43分/月の停止が許容される ○ 可用性 99.99% => 4分/月 ○ 可用性 99.999% => 26秒/月 48

Slide 49

Slide 49 text

SLOと開発生産性指標 ● デプロイ頻度 ○ 毎日なら30日に20回デプロイ ● 変更失敗率 ○ 5%なら20回に1回発生する ● 平均修復時間 ○ 30分なら1回の障害で30分障害になる 49 障害予想時間＝デプロイ頻度×変更失敗率×平均修復時間 → 30日に30分程度障害になると予想

Slide 50

Slide 50 text

SLOと開発生産性指標 ● 可用性 SLO 99.9%なら、43分/30日のダウンタイムが許される ● 変更起因障害の割合 ○ 「Binary Push」と「Conﬁguration Push」が該当 ○ 障害全体の60%が変更起因障害として、26分程度が変更起因で障害にできる許容時間 50

Slide 51

Slide 51 text

SLOと開発生産性指標 ● 障害予想時間：30分/30日 ● 障害許容時間：26分/30日 ● このチームパフォーマンスだと、SLOに違反する可能性がある 51

Slide 52

Slide 52 text

SLOと開発生産性指標 ● ユーザー行動とビジネス価値 → SLO ● SLO → エラーバジェット ● 開発生産性指標 → 障害予想時間 ● エラーバジェット ⇔ 障害予想時間 52

Slide 53

Slide 53 text

SLOと開発生産性指標変更障害率とサービス復旧時間が許容できなくなるところは、決められそう 53

Slide 54

Slide 54 text

54 リードタイム劣化の基準は作れそうか

Slide 55

Slide 55 text

変更リードタイムの目標値 ● 変更リードタイムが劣化＝ベロシティの劣化 ● ベロシティが劣化＝見積もりが外れている ● 見積もりの予実を見ていると検知できる 55

Slide 56

Slide 56 text

見積もり精度のズレを見る 56 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur

Slide 57

Slide 57 text

見積もり精度のズレを見る 57 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur

Slide 58

Slide 58 text

見積もり精度のズレを見る 58 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur

Slide 59

Slide 59 text

見積もり精度のズレを見る 59 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur

Slide 60

Slide 60 text

見積もり精度のズレを見る 60 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur

Slide 61

Slide 61 text

アウトプット量を減らす力を可視化する ● SLOも事業計画も、事業責任者の関心事 ● Four Keysをただの「開発生産性指標」に留めず、事業責任者の関心事に沿った形で負債の量を測る武器にする 61

Slide 62

Slide 62 text

62 「作業」と「仕事」

Slide 63

Slide 63 text

「作業8割、仕事2割」 ● 私の持論 ● 「作業」は今日の飯の種を得るための業務 ● 「仕事」は未来のお金を作るための業務 ● 未来のお金≒時間 ○ 機械にやらせたり、一目で分かるようにしたり、誰でも判断できるようにしたり 63

Slide 64

Slide 64 text

「作業8割、仕事2割」 ● 仕事が1割を切ると生活が良くなっていく未来が見えなくてしんどい ● 逆に3割を超えるとカイゼンにうつつを抜かしてる状態 ● 15〜20%ぐらいを劣化力との戦いに使っているとバランス良いんじゃないか 64

Slide 65

Slide 65 text

65 アウトプットを作るチーム

Slide 66

Slide 66 text

66 グループからチームへ

Slide 67

Slide 67 text

グループとチーム 67 『組織行動のマネジメント』スティーブン P.ロビンス著、髙木晴夫訳、2009年、ダイアモンド社

Slide 68

Slide 68 text

グループとチーム 68 https://asana.com/ja/resources/group-vs-team

Slide 69

Slide 69 text

69 毛づくろい

Slide 70

Slide 70 text

毛づくろい ● 社会的グルーミング ○ サルはお互いに毛づくろいを行う ○ 毛づくろいは、集団の絆を維持するための「社交」 ○ 集団のサイズが大きくなると毛づくろい時間も増えることが知られている 70

Slide 71

Slide 71 text

毛づくろい ● サルにおけるお互いの毛づくろい ○ 自分の時間を相手のために使うよ ○ 相手から触られることが不快じゃないよ ○ 信頼の土台を築いていく ● 人間における毛づくろい ○ 雑談は毛づくろいに当たると言えるのではないか ○ 関係性を構築する行為 71

Slide 72

Slide 72 text

72 得意を知る

Slide 73

Slide 73 text

得意を知る 73

Slide 74

Slide 74 text

得意を知る ● ボケ、ツッコミ、客のどの役割を持つか ○ こういう発言をするとこういう拾い方をしてくれるだろうという安心感 ● 「心理的安全性」 ○ お互いが相手の得意に合わせて、想定しながら動く 74

Slide 75

Slide 75 text

得意を知る ● 相手がどういうやり方が得意なのかを知る ○ 具体で伝えるか、抽象で伝える方が良いか ○ マイクロマネジメントが良いか、放任が良いか ○ 瞬発的に考えて話すか、じっくり考えてから話すか ○ 物理出社したいか、リモートが良いか 75

Slide 76

Slide 76 text

76 阿吽の呼吸のチームを作るのは時間がかかる

Slide 77

Slide 77 text

77 ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ。 ──アラン・ケリー、『Project Myopia』

Slide 78

Slide 78 text

78 得意を組み合わせるよう座組を考える

Slide 79

Slide 79 text

座組を考える ● 役割を網羅することを考える 79

Slide 80

Slide 80 text

座組を考える ● PdM、PjM、TL、… ○ サービス開発に必要な各役割 ● 問題発見、課題化、遂行 ○ 問題を見つけられる人、タスクに落とし込める人、タスクを遂行する人 ○ 考える人だけ集めても、手を動かす時間が取れなかったら問題は解決しない 80

Slide 81

Slide 81 text

座組を考える ● 専門家 ○ 深く掘らないと解決できない問題を、解決まで持って行ける人 ● ジェネラリスト ○ 複数の領域が必要な問題を、人と人を繋げたり、両方の仕事をやったりして、解決まで持って行ける人 81

Slide 82

Slide 82 text

座組を考える ● ムードメーカー ○ ハードな状況でもチームをポジティブなムードに持って行ける人。提案に対して第一声が「面白そう」な人 ● 気が利く人 ○ なんか漏れてるものを拾ってくれたり、ムラがあるので解消しませんか or 私がやりますって言い出したり 82

Slide 83

Slide 83 text

83 体制作りで気をつけること

Slide 84

Slide 84 text

Slide 85

Slide 85 text

「年老いた組織」 85 『技術の創造と設計』畑村洋太郎著、2006年、岩波書店

Slide 86

Slide 86 text

ドイツ人の仕事、日本人の仕事。 86 https://www.huffingtonpost.jp/toru-hisai/post_b_11478870.html

Slide 87

Slide 87 text

個人技は必要 ● 個人技が足りないと、手を伸ばす余力を持てない ● 領域を重複するよう設計できず、穴だらけになる 87

Slide 88

Slide 88 text

個人技は必要 88

Slide 89

Slide 89 text

個人技は必要 ● 低レベルクリアは戦い方が限られる ○ バラモスよりも素早くベホイミを撃てないと詰むとか ● 今の戦力で限られた戦い方を探すよりも、個人技を鍛える方が楽になることは多い 89

Slide 90

Slide 90 text

90 まとめ

Slide 91

Slide 91 text

まとめ ● アウトプットとアウトカム ○ 開発チームとしてはアウトプットで80点をまず目指す ● アウトプットを阻害する力 ○ 負債を見える化。SLOを決めて対応を判断する ● 強いチームは生産性が高い ○ コミュニケーションと体制設計と個人技で強くする 91