強いチームと開発生産性

2024-11-15 開発生産性Kaigi
https://developer-productivity-engineering.connpass.com/event/332852/

Transcript

1. 強いチームと開発生産性 id:onk 2024-11-15 開発生産性Kaigi 1
2. 自己紹介 • 大仲 能史 a.k.a. id:onk • 芸歴20年目 ◦ バックエンドとインフラが得意 • 株式会社はてな ◦ チーフエンジニア ◦ いろんな役割があるけど、今日は 「開発チームの一員」の立場で話します 2
3. 3 開発生産性とは
4. 開発生産性とは • 生産性＝生産する能力 • アウトプット / インプット • 突っ込んだ量に対して、返ってくる量の割合 4
5. 開発生産性とは • インプット ◦ 労働人数 ◦ 労働時間 ◦ 開発人件費 ◦ 総事業コスト 5
6. 開発生産性とは • アウトプット ◦ 書いたコード量 ◦ リリースした施策数 ◦ リリースした施策の効果 ◦ 売上 ◦ 新しい体験を提供し、人の生活を豊かにした量 6
7. 開発生産性とは • 単位時間あたりのアウトプット ◦ Lv1: 仕事量（書いたコード量〜施策数） ◦ Lv2: 期待付加価値（施策数〜施策の想定KPI変化） ◦ Lv3: 実現付加価値（KPI変化〜売上） 7
8. 開発生産性とは 8 https://qiita.com/hirokidaichi/items/53f0865398829bdebef1
9. 9 アウトプットとアウトカム
10. アウトプットとアウトカム • アウトプット ◦ 自分が出力した量 ◦ 仕事量〜期待付加価値 • アウトカム ◦ 自分が出力したことによって起きた、対象の変化量 ◦ 期待付加価値〜実現付加価値 10
11. 開発生産性とは 11 アウトプット
12. 開発生産性とは 12 アウトカム
13. アウトプットとアウトカム • アウトプットが凄くてもアウトカムが無い ◦ 結果に結びついていない無駄な努力 ◦ 高速にゴミを作っている ◦ 「ビルドトラップ」 13
14. 14 デュアルトラック
15. 15 デュアルトラック https://www.jpattonassociates.com/dual-track-development/
16. デュアルトラック • 仮説検証サイクルを早く回す • 仮説検証で最も遅い方法は、製品を作ること ◦ コストを掛けて本物を作る前にダメな案を高速に潰す • ディスカバリートラックで確からしさを検証 • 検証済みのものをデリバリートラックで作る 16
17. デュアルトラック • ディスカバリー ◦ プロダクトマネージャー寄りの仕事 ◦ 作るものを決める ▪ ユーザーインタビュー等 • デリバリー ◦ コーディングを伴う ◦ いわゆるスクラムチームの仕事 ▪ 作って、リリースして、ユーザの反応を伺う 17
18. 目的に辿り着くことで例えると • ディスカバリーは地図、カーナビ ◦ どこに向かうかを見定める • デリバリーは車 ◦ いろんな車があるよね ◦ 速い車、遅い車 18
19. どちらも大事 • 地図が無いと迷子になる • 速度が遅いと時間が掛かる 19
20. 20 正しいものを、正しく作る
21. 正しいものを、正しく作る • シフトレフト ◦ 間違ったものを早めに潰す ◦ 修正が早い段階であればあるほどコストが掛からない ◦ リリース -> テスト -> コードを書く時 -> 企画段階 21
22. 22 ディスカバリーと デリバリーは両輪
23. 23 と、言われているが 開発チーム目線では 両輪ではない
24. 24 デリバリーが先、 ディスカバリーが後
25. 遅い車はとにかく問題 • 地図が合っていても三輪車じゃ辿り着けない ◦ せめてエンジン付き。できれば常に整備しておきたい • 方向がベクトル90度以内に収まってればいい ◦ 象限が合っていれば十分 ▪ それ以上の精度が本当に必要？ ◦ イテレーションを素早く回せば修正できる ▪ 回すことすらできない方が問題が大きい 25
26. 開発生産性 26 アウトプット ここが低いと話にならない
27. 高速ゴミ製造機をより好む • もし良い企画に当たったら高速にアウトカム を作れる地力がある ◦ 止まった時計も1日2回は正しい時間を指す • 高速にPDCAを回すことができる ◦ PDCAを回した数だけチームとしての強さが増す ◦ 改善している実感を手に入れられ、役割分担が自然と され、目標達成にコミットできるチームになっていく 27
28. もちろん場合による • 打席に立てる回数には限りがある • ゴミを作ってる余裕がまったく無いなら当た る企画だけを作るしかない ◦ アウトにならないようなヒットを狙う ◦ 打率を上げることに注力する必要がある 28
29. 29 アウトプットを評価する
30. 30 Four Keys
31. Four Keys • デプロイの頻度 • 変更のリードタイム • 変更障害率 • サービス復旧時間 31
32. Four Keys 32 https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
33. 33 強いチームはDevOpsが前提
34. DevOps 34 Kharnagy, CC BY-SA 4.0 • DevOpsツールチェーンの活用 • 自動化 • 継続的デリバリー • 組織文化の転換
35. Four Keys (2021) 35 https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
36. 36 開発生産性を阻害する力
37. ツラみが自然と溜まっていく例 • データの蓄積によるレスポンス悪化 • 仕様変更による設計の無理 • ライブラリの更新への追随を怠る • 突然応答しなくなるサーバ • 人の流動によるノウハウの低下 37
38. 38 何もしないと開発生産性は どんどん悪化する
39. 39 ツラみが溜まってきたのを 検知したい
40. ツラみの検知とFour Keys • デプロイの頻度 • 変更のリードタイム • 変更障害率 • サービス復旧時間 40
41. ツラみの検知とFour Keys • デプロイの頻度 ◦ おそらく変わらないだろう • 変更のリードタイム • 変更障害率 • サービス復旧時間 41
42. ツラみの検知とFour Keys • デプロイの頻度 • 変更のリードタイム ◦ 徐々に劣化していくはず • 変更障害率 • サービス復旧時間 42
43. ツラみの検知とFour Keys • デプロイの頻度 • 変更のリードタイム • 変更障害率 ◦ 徐々に劣化していくはず • サービス復旧時間 43
44. ツラみの検知とFour Keys • デプロイの頻度 • 変更のリードタイム • 変更障害率 • サービス復旧時間 ◦ チームの練度がどこまで下がるか次第 44
45. 45 Four Keysでツラみの 検知はできそうだけど 基準が欲しい
46. 46 SLO
47. SLOとは • サービスレベル目標 (Service Level Objective) • サービスにおいて目標値とされ る「適切な信頼性のレベル」 47
48. 適切な信頼性のレベル • 100%の信頼性を目指すのではなく、 見極める • 信頼性にはコストが掛かる ◦ 可用性 99.9% => 43分/月の停止が許容される ◦ 可用性 99.99% => 4分/月 ◦ 可用性 99.999% => 26秒/月 48
49. SLOと開発生産性指標 • デプロイ頻度 ◦ 毎日なら30日に20回デプロイ • 変更失敗率 ◦ 5%なら20回に1回発生する • 平均修復時間 ◦ 30分なら1回の障害で30分障害になる 49 障害予想時間＝ デプロイ頻度×変更失敗率×平均修復時間 → 30日に30分程度 障害になると予想
50. SLOと開発生産性指標 • 可用性 SLO 99.9%なら、43分/30日のダウ ンタイムが許される • 変更起因障害の割合 ◦ 「Binary Push」と「Configuration Push」が該当 ◦ 障害全体の60%が変更起因障害として、26分程度が 変更起因で障害にできる許容時間 50
51. SLOと開発生産性指標 • 障害予想時間：30分/30日 • 障害許容時間：26分/30日 • このチームパフォーマンスだと、SLOに違反 する可能性がある 51
52. SLOと開発生産性指標 • ユーザー行動とビジネス価値 → SLO • SLO → エラーバジェット • 開発生産性指標 → 障害予想時間 • エラーバジェット ⇔ 障害予想時間 52
53. SLOと開発生産性指標 変更障害率とサービス復旧時間が 許容できなくなるところは、決められそう 53
54. 54 リードタイム劣化の基準は 作れそうか
55. 変更リードタイムの目標値 • 変更リードタイムが劣化＝ベロシティの劣化 • ベロシティが劣化＝見積もりが外れている • 見積もりの予実を見ていると検知できる 55
56. 見積もり精度のズレを見る 56 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
57. 見積もり精度のズレを見る 57 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
58. 見積もり精度のズレを見る 58 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
59. 見積もり精度のズレを見る 59 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
60. 見積もり精度のズレを見る 60 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
61. アウトプット量を減らす力を可視化す る • SLOも事業計画も、事業責任者の関心事 • Four Keysをただの「開発生産性指標」に留 めず、事業責任者の関心事に沿った形で負債 の量を測る武器にする 61
62. 62 「作業」と「仕事」
63. 「作業8割、仕事2割」 • 私の持論 • 「作業」は今日の飯の種を得るための業務 • 「仕事」は未来のお金を作るための業務 • 未来のお金≒時間 ◦ 機械にやらせたり、一目で分かるようにしたり、 誰でも判断できるようにしたり 63
64. 「作業8割、仕事2割」 • 仕事が1割を切ると生活が良くなっていく未来 が見えなくてしんどい • 逆に3割を超えるとカイゼンにうつつを抜かし てる状態 • 15〜20%ぐらいを劣化力との戦いに使ってい るとバランス良いんじゃないか 64
65. 65 アウトプットを作るチー ム
66. 66 グループからチームへ
67. グループとチーム 67 『組織行動のマネジメント』スティーブン P.ロビンス著、髙木晴夫訳、2009年、ダイアモンド社
68. グループとチーム 68 https://asana.com/ja/resources/group-vs-team
69. 69 毛づくろい
70. 毛づくろい • 社会的グルーミング ◦ サルはお互いに毛づくろいを行う ◦ 毛づくろいは、集団の絆を維持するための「社交」 ◦ 集団のサイズが大きくなると毛づくろい時間も増える ことが知られている 70
71. 毛づくろい • サルにおけるお互いの毛づくろい ◦ 自分の時間を相手のために使うよ ◦ 相手から触られることが不快じゃないよ ◦ 信頼の土台を築いていく • 人間における毛づくろい ◦ 雑談は毛づくろいに当たると言えるのではないか ◦ 関係性を構築する行為 71
72. 72 得意を知る
73. 得意を知る 73
74. 得意を知る • ボケ、ツッコミ、客のどの役割を持つか ◦ こういう発言をするとこういう拾い方をしてくれるだ ろうという安心感 • 「心理的安全性」 ◦ お互いが相手の得意に合わせて、想定しながら動く 74
75. 得意を知る • 相手がどういうやり方が得意なのかを知る ◦ 具体で伝えるか、抽象で伝える方が良いか ◦ マイクロマネジメントが良いか、放任が良いか ◦ 瞬発的に考えて話すか、じっくり考えてから話すか ◦ 物理出社したいか、リモートが良いか 75
76. 76 阿吽の呼吸の チームを作るのは 時間がかかる
77. 77 ハイパフォーマンスなチームを解散す るのは、単なる破壊行為では済まな い。企業レベルのサイコパスと呼ぶべ きものだ。 ──アラン・ケリー、『Project Myopia』
78. 78 得意を組み合わせるよう 座組を考える
79. 座組を考える • 役割を網羅することを考える 79
80. 座組を考える • PdM、PjM、TL、… ◦ サービス開発に必要な各役割 • 問題発見、課題化、遂行 ◦ 問題を見つけられる人、タスクに落とし込める人、 タスクを遂行する人 ◦ 考える人だけ集めても、手を動かす時間が取れなかっ たら問題は解決しない 80
81. 座組を考える • 専門家 ◦ 深く掘らないと解決できない問題を、解決まで持って 行ける人 • ジェネラリスト ◦ 複数の領域が必要な問題を、人と人を繋げたり、両方 の仕事をやったりして、解決まで持って行ける人 81
82. 座組を考える • ムードメーカー ◦ ハードな状況でもチームをポジティブなムードに持っ て行ける人。提案に対して第一声が「面白そう」な人 • 気が利く人 ◦ なんか漏れてるものを拾ってくれたり、ムラがあるの で解消しませんか or 私がやりますって言い出したり 82
83. 83 体制作りで気をつけること
85. 「年老いた組織」 85 『技術の創造と設計』畑村 洋太郎著、2006年、 岩波書店
86. ドイツ人の仕事、日本人の仕事。 86 https://www.huffingtonpost.jp/toru-hisai/post_b_11478870.html
87. 個人技は必要 • 個人技が足りないと、手 を伸ばす余力を持てない • 領域を重複するよう設計 できず、穴だらけになる 87
88. 個人技は必要 88
89. 個人技は必要 • 低レベルクリアは戦い方が限られる ◦ バラモスよりも素早くベホイミを撃てないと詰むとか • 今の戦力で限られた戦い方を探すよりも、個 人技を鍛える方が楽になることは多い 89
90. 90 まとめ
91. まとめ • アウトプットとアウトカム ◦ 開発チームとしてはアウトプットで80点をまず目指す • アウトプットを阻害する力 ◦ 負債を見える化。SLOを決めて対応を判断する • 強いチームは生産性が高い ◦ コミュニケーションと体制設計と個人技で強くする 91