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 体制作りで気をつけること

84. 84

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