開発者体験を意識した開発チームの生産性向上の取り組み

2024/08/29
開発生産性向上の鍵
〜開発者体験・効率・検証改善・リードタイム短縮の実例〜

https://sansan.connpass.com/event/326409/

こちらのイベントで登壇したスライドです。

Transcript

1. © Findy Inc. 2024.08.29 開発⽣産性向上の鍵 〜開発者体験‧効率‧検証改善‧リードタイム短縮の実例〜 1 開発者体験を意識した開発チームの ⽣産性向上の取り組み 浜⽥ 直⼈ Naoto Hamada (ham)
2. © Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア！ Ruby / Rails / React / TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215
3. 挑戦するエンジニアの プラットフォームをつくる。 テクノロジーによる社会変革の時代に最も必要なことは、エンジニアの可能性を拡げることです。 Findyは、アルゴリズムとヒューマニティの融合によって、 すべてのエンジニアが不安なく挑戦できる世界共通のプラットフォームをつくります。 個人のチャンスを生み出し、組織の生産性を向上させ、社会の人材資産を好循環させる。 エンジニアプラットフォームが、デジタル社会の発展を加速していきます。 ビジョン © Findy Inc. 3
4. © Findy Inc. ファインディが展開するエンジニアプラットフォーム サービス紹介 ToC / ToB 正社員エンジニアの採用 約12万人のエンジニアと880社以上のテック 企業をマッチング。 マッチングサービス フリーランスエンジニアの採用 5万人以上のフリーランスエンジニアの成功報 酬型の人材紹介サービス。 外国籍エンジニアの採用 インドを中心とした海外のハイスキルエンジニ アと日本企業をマッチング。 SaaS / ToB エンジニア組織の見える化 GitHubやJiraを解析し、エンジニア組織の見 える化と生産性向上をサポート。 組織分析SaaS ToC / ToB 開発ツールのレビューサイト 実際に利用している企業の声を元に、開発 ツールの導入や検討に必要な情報を集約。企 業の技術選定をサポート。 開発ツールメディア ※ 各種数値は、2024年6月時点のFindy転職、Findy Freelance、Findy Team+、Findy Globalの4サービスの累計での社数及び登録者数です。 
 　 なお、1社又は1名の方が複数のサービスに登録している場合は、そのサービスの数に応じて複数のカウントをしています。 β版 4
5. © Findy Inc. 5 Findy Team+(チームプラス)とは？ 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 5 ⽣産性可視化 ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz
6. © Findy Inc. 6 Agenda - 開発⽣産性の可視化について - 開発者体験を意識して開発⽣産性を向上させる事例
7. © Findy Inc. 開発⽣産性の可視化について 7
8. © Findy Inc. 8
 DORA Core Model v2.0.0 https://dora.dev/research/

9. © Findy Inc. 9
 DORA Core Model v2.0.0 https://dora.dev/research/
 影響 影響
10. © Findy Inc. 10
 DORA Core Model v2.0.0 https://dora.dev/research/

11. © Findy Inc. 11
 DORA Core Model v2.0.0 https://dora.dev/research/

12. © Findy Inc. 12
 DORA Core Model v2.0.0 https://dora.dev/research/

13. © Findy Inc. 13
 DORA Core Model v2.0.0 https://dora.dev/research/
 Capabilityから Outcomeまで繋がってこそ 「開発⽣産性が向上した」 と⾔えます！！
14. © Findy Inc. 14
 DORA Core Model v2.0.0 https://dora.dev/research/
 なるほど！ Four Keysを上げれば いいんだな💡
15. © Findy Inc. 15
 DORA Core Model v2.0.0 https://dora.dev/research/
 うおおおおおおおおお Four Keys 上げるぞーーー！！
16. © Findy Inc. 16
 DORA Core Model v2.0.0 https://dora.dev/research/
 Four Keysは 向上したけど 現場はツラそう...
17. © Findy Inc. 17
 DORA Core Model v2.0.0 https://dora.dev/research/

18. © Findy Inc. 開発者体験を意識して 開発⽣産性を向上させる事例 18
 Four Keys編
19. © Findy Inc. 19 2023 State of DevOps Report
 https://cloud.google.com/devops/state-of-devops
 https://book.impress.co.jp/books/1118101029
 Four Keys
20. © Findy Inc. 20
 デプロイ頻度 - 本番環境にデプロイする頻度 ◦ 多ければ多いほど良い指標 ◦ エリート⽔準は `On demand` ▪ 必要に応じて1⽇に何回もデプロイしている
21. © Findy Inc. 21
 デプロイ頻度 これは簡単！！ 何度もデプロイすれば いいだけじゃん！
22. © Findy Inc. 22
 デプロイ頻度 これは簡単！！ 何度もデプロイすれば いいだけじゃん！
23. © Findy Inc. 23
 デプロイ頻度 これは簡単！！ 何度もデプロイすれば いいだけじゃん！ デプロイ頻度が今の頻度になっているのは 現場ごとの理由がある！！ これを解消せずにデプロイ頻度を上げると 現場が疲弊します！！
24. © Findy Inc. 24
 デプロイ頻度 - デプロイ頻度が上げられない理由を考える。例えば... ◦ デプロイ作業が煩雑で担当者が⻑時間拘束される ◦ デプロイ前に⼿動でリグレッションテストをしないと品 質が担保できない
25. © Findy Inc. 25
 デプロイ頻度 - デプロイ頻度が上げられない理由を考える。例えば... ◦ デプロイ作業が煩雑で担当者が⻑時間拘束される ▪ デプロイ⾃動化で拘束時間低下 🙌 ◦ デプロイ前に⼿動でリグレッションテストをしないと品 質が担保できない ▪ ⾃動テストを増やし⼿動テスト軽減🙌
26. © Findy Inc. 26
 デプロイ頻度 デプロイ時にやることが 減ったので デプロイ頻度を増やせるぞ！ ⾯倒だった⼿動テストや 煩雑なデプロイ作業が なくなって 開発者体験も向上！
27. © Findy Inc. 27
 デプロイ頻度 デプロイ時にやることが 減ったので デプロイ頻度を増やせるぞ！ ⾯倒だった⼿動テストや 煩雑なデプロイ作業が なくなって 開発者体験も向上！
28. © Findy Inc. 28
 変更のリードタイム - 本番環境に変更が反映されるまでの時間 ◦ 短ければ短いほど良い指標 ◦ エリート⽔準は `Less than one day`
29. © Findy Inc. 29
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ◦ プルリクが⼤きいため実装＆レビューに時間がかかる ◦ 特定メンバーにレビューが集中する ◦ レビュー指摘が多く⼿戻りが多い ◦ プルリクの⽣存時間が⻑くなりコンフリクトが頻繁に発 ⽣する
30. © Findy Inc. 30
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ◦ プルリクが⼤きいため実装＆レビューに時間がかかる ▪ プルリクサイズを⼩さくすることで時間短縮🙌
31. © Findy Inc. 31
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ◦ 特定メンバーにレビューが集中する ▪ レビュアーを分散することで負荷分散🙌 • 分散するためにレビュアーを育成する ▪ レビューに権威性を持たせすぎない • どんだけ頑張っても⽬視チェック • ⾒落としもある前提で他で担保
32. © Findy Inc. 32
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ◦ レビュー指摘が多く⼿戻りが多い ▪ Linterなどで最低限の品質を担保🙌 ▪ 下記を実施して⼿戻りを減らす🙌 • 設計レビューなど事前に⼤⽅針は固めておく • プルリクサイズを⼩さくする
33. © Findy Inc. 33
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ◦ プルリクの⽣存時間が⻑くなりコンフリクトが頻繁に発 ⽣する ▪ ここまでに書いたことを実施してリードタイムを短 くするとコンフリクトも減る🙌
34. © Findy Inc. 34
 変更のリードタイム さくさくプルリクが マージできるので リードタイムが短くなった！ ⼿戻りやコンフリクトなど 煩わしい作業からの解放！ 開発者体験向上！
35. © Findy Inc. 35
 変更のリードタイム さくさくプルリクが マージできるので リードタイムが短くなった！ ⼿戻りやコンフリクトなど 煩わしい作業からの解放！ 開発者体験向上！
36. © Findy Inc. 36
 変更障害率 - 本番環境に変更を反映した際、障害が発⽣する確率 ◦ 低ければ低いほど良い指標 ◦ エリート⽔準は `5%以下`
37. © Findy Inc. 37
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い
38. © Findy Inc. 38
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い ▪ デプロイ前に全機能リグレッションテストをやる ▪ デプロイを減らす ▪ ⾃動テストで既存処理の振る舞いを担保する ▪ 過度な共通化を減らすなどアーキテクチャ刷新
39. © Findy Inc. 39
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い ▪ デプロイ前に全機能リグレッションテストをやる ▪ デプロイを減らす ▪ ⾃動テストで既存処理の振る舞いを担保する ▪ 過度な共通化を減らすなどアーキテクチャ刷新
40. © Findy Inc. 40
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い ▪ デプロイ前に全機能リグレッションテストをやる リグレッションテスト多すぎ... • 毎回全部やるとかマジ？！ ◦ 変更障害率⤵ ◦ デプロイ頻度⤵ ◦ 開発者体験⤵
41. © Findy Inc. 41
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い ▪ デプロイ前に全機能リグレッションテストをやる リグレッションテスト多すぎ... • 毎回全部やるとかマジ？！ ◦ 変更障害率⤵ ◦ デプロイ頻度⤵ ◦ 開発者体験⤵
42. © Findy Inc. 42
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い ▪ デプロイ前に全機能リグレッションテストをやる ▪ デプロイを減らす ▪ ⾃動テストで既存処理の振る舞いを担保する ▪ 過度な共通化を減らすなどアーキテクチャ刷新
43. © Findy Inc. 43
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い ▪ デプロイ前に全機能リグレッションテストをやる ▪ デプロイを減らす ▪ ⾃動テストで既存処理の振る舞いを担保する ▪ 過度な共通化を減らすなどアーキテクチャ刷新 Four Keysは4つの全指標が⾼い状態を⽬指すべき →過剰にデプロイ頻度が上がっているとの判断ならあり
44. © Findy Inc. 44
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い ▪ デプロイ前に全機能リグレッションテストをやる ▪ (デプロイを減らす) ▪ ⾃動テストで既存処理の振る舞いを担保する🙌 ▪ 過度な共通化を減らすなどアーキテクチャ刷新🙌
45. © Findy Inc. 45
 変更障害率 不意に既存を壊すことが 減ったので 変更障害率が低下したぞ！ アーキテクチャ刷新で 影響範囲の調査が楽になって 開発者体験も向上！
46. © Findy Inc. 46
 変更障害率 不意に既存を壊すことが 減ったので 変更障害率が低下したぞ！ アーキテクチャ刷新で 影響範囲の調査が楽になって 開発者体験も向上！
47. © Findy Inc. 47
 平均修復時間 - 本番環境で障害が発⽣した際、修復までにかかる時間 ◦ 短ければ短いほど良い指標 ◦ エリート⽔準は `Less than one hour`
48. © Findy Inc. 48
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ◦ デプロイに時間がかかる ◦ 変更量が多くエラーの特定に時間がかかる ◦ エラー監視できておらず検知に時間がかかる
49. © Findy Inc. 49
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ◦ デプロイに時間がかかる ▪ デプロイを⾃動‧簡素化してデプロイ時間短縮🙌 • デプロイ頻度やリードタイムの向上にも繋がる！
50. © Findy Inc. 50
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ◦ 変更量が多くエラーの特定に時間がかかる ▪ プルリクサイズを⼩さくすることで変更量減少🙌
51. © Findy Inc. 51
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ◦ エラー監視できておらず検知に時間がかかる ▪ 監視の仕組みを⼊れることで素早く検知🙌
52. © Findy Inc. 52
 平均修復時間 エラーの検知や特定が 早くなって 平均修復時間が短縮したぞ！ すぐに修復できるので 安⼼してデプロイできる！ 開発者体験向上！
53. © Findy Inc. 53
 平均修復時間 エラーの検知や特定が 早くなって 平均修復時間が短縮したぞ！ すぐに修復できるので 安⼼してデプロイできる！ 開発者体験向上！
54. © Findy Inc. 54
 まとめ 開発者体験に注⽬することで 持続可能な⽣産性向上を 実現していきましょう！
55. © Findy Inc. 55
 プロダクトエンジニア ‧エンジニアをターゲットとした  プロダクト開発 ‧技術はモダンが当たり前 ‧⾼い開発⽣産性 ‧開発者体験の追求 ‧CI/CDや⾃動テストが  整備された開発環境 We are hiring！