Tweet
Tweet

Slide 1

Slide 1 text

© Findy Inc. 2024.08.29 開発⽣産性向上の鍵 〜開発者体験‧効率‧検証改善‧リードタイム短縮の実例〜 1 開発者体験を意識した開発チームの ⽣産性向上の取り組み 浜⽥ 直⼈ Naoto Hamada (ham)

Slide 2

Slide 2 text

© Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア！ Ruby / Rails / React / TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215

Slide 3

Slide 3 text

挑戦するエンジニアの プラットフォームをつくる。 テクノロジーによる社会変革の時代に最も必要なことは、エンジニアの可能性を拡げることです。 Findyは、アルゴリズムとヒューマニティの融合によって、 すべてのエンジニアが不安なく挑戦できる世界共通のプラットフォームをつくります。 個人のチャンスを生み出し、組織の生産性を向上させ、社会の人材資産を好循環させる。 エンジニアプラットフォームが、デジタル社会の発展を加速していきます。 ビジョン © Findy Inc. 3

Slide 4

Slide 4 text

© 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

Slide 5

Slide 5 text

© Findy Inc. 5 Findy Team+(チームプラス)とは？ 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 5 ⽣産性可視化 ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz

Slide 6

Slide 6 text

© Findy Inc. 6 Agenda - 開発⽣産性の可視化について - 開発者体験を意識して開発⽣産性を向上させる事例

Slide 7

Slide 7 text

© Findy Inc. 開発⽣産性の可視化について 7

Slide 8

Slide 8 text

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


Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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


Slide 11

Slide 11 text

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


Slide 12

Slide 12 text

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


Slide 13

Slide 13 text

© Findy Inc. 13
 DORA Core Model v2.0.0 https://dora.dev/research/
 Capabilityから Outcomeまで繋がってこそ 「開発⽣産性が向上した」 と⾔えます！！

Slide 14

Slide 14 text

© Findy Inc. 14
 DORA Core Model v2.0.0 https://dora.dev/research/
 なるほど！ Four Keysを上げれば いいんだな💡

Slide 15

Slide 15 text

© Findy Inc. 15
 DORA Core Model v2.0.0 https://dora.dev/research/
 うおおおおおおおおお Four Keys 上げるぞーーー！！

Slide 16

Slide 16 text

© Findy Inc. 16
 DORA Core Model v2.0.0 https://dora.dev/research/
 Four Keysは 向上したけど 現場はツラそう...

Slide 17

Slide 17 text

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


Slide 18

Slide 18 text

© Findy Inc. 開発者体験を意識して 開発⽣産性を向上させる事例 18
 Four Keys編

Slide 19

Slide 19 text

© 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

Slide 20

Slide 20 text

© Findy Inc. 20
 デプロイ頻度 - 本番環境にデプロイする頻度 ○ 多ければ多いほど良い指標 ○ エリート⽔準は `On demand` ■ 必要に応じて1⽇に何回もデプロイしている

Slide 21

Slide 21 text

© Findy Inc. 21
 デプロイ頻度 これは簡単！！ 何度もデプロイすれば いいだけじゃん！

Slide 22

Slide 22 text

© Findy Inc. 22
 デプロイ頻度 これは簡単！！ 何度もデプロイすれば いいだけじゃん！

Slide 23

Slide 23 text

© Findy Inc. 23
 デプロイ頻度 これは簡単！！ 何度もデプロイすれば いいだけじゃん！ デプロイ頻度が今の頻度になっているのは 現場ごとの理由がある！！ これを解消せずにデプロイ頻度を上げると 現場が疲弊します！！

Slide 24

Slide 24 text

© Findy Inc. 24
 デプロイ頻度 - デプロイ頻度が上げられない理由を考える。例えば... ○ デプロイ作業が煩雑で担当者が⻑時間拘束される ○ デプロイ前に⼿動でリグレッションテストをしないと品 質が担保できない

Slide 25

Slide 25 text

© Findy Inc. 25
 デプロイ頻度 - デプロイ頻度が上げられない理由を考える。例えば... ○ デプロイ作業が煩雑で担当者が⻑時間拘束される ■ デプロイ⾃動化で拘束時間低下 🙌 ○ デプロイ前に⼿動でリグレッションテストをしないと品 質が担保できない ■ ⾃動テストを増やし⼿動テスト軽減🙌

Slide 26

Slide 26 text

© Findy Inc. 26
 デプロイ頻度 デプロイ時にやることが 減ったので デプロイ頻度を増やせるぞ！ ⾯倒だった⼿動テストや 煩雑なデプロイ作業が なくなって 開発者体験も向上！

Slide 27

Slide 27 text

© Findy Inc. 27
 デプロイ頻度 デプロイ時にやることが 減ったので デプロイ頻度を増やせるぞ！ ⾯倒だった⼿動テストや 煩雑なデプロイ作業が なくなって 開発者体験も向上！

Slide 28

Slide 28 text

© Findy Inc. 28
 変更のリードタイム - 本番環境に変更が反映されるまでの時間 ○ 短ければ短いほど良い指標 ○ エリート⽔準は `Less than one day`

Slide 29

Slide 29 text

© Findy Inc. 29
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ○ プルリクが⼤きいため実装＆レビューに時間がかかる ○ 特定メンバーにレビューが集中する ○ レビュー指摘が多く⼿戻りが多い ○ プルリクの⽣存時間が⻑くなりコンフリクトが頻繁に発 ⽣する

Slide 30

Slide 30 text

© Findy Inc. 30
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ○ プルリクが⼤きいため実装＆レビューに時間がかかる ■ プルリクサイズを⼩さくすることで時間短縮🙌

Slide 31

Slide 31 text

© Findy Inc. 31
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ○ 特定メンバーにレビューが集中する ■ レビュアーを分散することで負荷分散🙌 ● 分散するためにレビュアーを育成する ■ レビューに権威性を持たせすぎない ● どんだけ頑張っても⽬視チェック ● ⾒落としもある前提で他で担保

Slide 32

Slide 32 text

© Findy Inc. 32
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ○ レビュー指摘が多く⼿戻りが多い ■ Linterなどで最低限の品質を担保🙌 ■ 下記を実施して⼿戻りを減らす🙌 ● 設計レビューなど事前に⼤⽅針は固めておく ● プルリクサイズを⼩さくする

Slide 33

Slide 33 text

© Findy Inc. 33
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ○ プルリクの⽣存時間が⻑くなりコンフリクトが頻繁に発 ⽣する ■ ここまでに書いたことを実施してリードタイムを短 くするとコンフリクトも減る🙌

Slide 34

Slide 34 text

© Findy Inc. 34
 変更のリードタイム さくさくプルリクが マージできるので リードタイムが短くなった！ ⼿戻りやコンフリクトなど 煩わしい作業からの解放！ 開発者体験向上！

Slide 35

Slide 35 text

© Findy Inc. 35
 変更のリードタイム さくさくプルリクが マージできるので リードタイムが短くなった！ ⼿戻りやコンフリクトなど 煩わしい作業からの解放！ 開発者体験向上！

Slide 36

Slide 36 text

© Findy Inc. 36
 変更障害率 - 本番環境に変更を反映した際、障害が発⽣する確率 ○ 低ければ低いほど良い指標 ○ エリート⽔準は `5%以下`

Slide 37

Slide 37 text

© Findy Inc. 37
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ○ 予期せず既存処理を壊してしまうことが多い

Slide 38

Slide 38 text

© Findy Inc. 38
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ○ 予期せず既存処理を壊してしまうことが多い ■ デプロイ前に全機能リグレッションテストをやる ■ デプロイを減らす ■ ⾃動テストで既存処理の振る舞いを担保する ■ 過度な共通化を減らすなどアーキテクチャ刷新

Slide 39

Slide 39 text

© Findy Inc. 39
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ○ 予期せず既存処理を壊してしまうことが多い ■ デプロイ前に全機能リグレッションテストをやる ■ デプロイを減らす ■ ⾃動テストで既存処理の振る舞いを担保する ■ 過度な共通化を減らすなどアーキテクチャ刷新

Slide 40

Slide 40 text

© Findy Inc. 40
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ○ 予期せず既存処理を壊してしまうことが多い ■ デプロイ前に全機能リグレッションテストをやる リグレッションテスト多すぎ... ● 毎回全部やるとかマジ？！ ○ 変更障害率⤵ ○ デプロイ頻度⤵ ○ 開発者体験⤵

Slide 41

Slide 41 text

© Findy Inc. 41
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ○ 予期せず既存処理を壊してしまうことが多い ■ デプロイ前に全機能リグレッションテストをやる リグレッションテスト多すぎ... ● 毎回全部やるとかマジ？！ ○ 変更障害率⤵ ○ デプロイ頻度⤵ ○ 開発者体験⤵

Slide 42

Slide 42 text

© Findy Inc. 42
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ○ 予期せず既存処理を壊してしまうことが多い ■ デプロイ前に全機能リグレッションテストをやる ■ デプロイを減らす ■ ⾃動テストで既存処理の振る舞いを担保する ■ 過度な共通化を減らすなどアーキテクチャ刷新

Slide 43

Slide 43 text

© Findy Inc. 43
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ○ 予期せず既存処理を壊してしまうことが多い ■ デプロイ前に全機能リグレッションテストをやる ■ デプロイを減らす ■ ⾃動テストで既存処理の振る舞いを担保する ■ 過度な共通化を減らすなどアーキテクチャ刷新 Four Keysは4つの全指標が⾼い状態を⽬指すべき →過剰にデプロイ頻度が上がっているとの判断ならあり

Slide 44

Slide 44 text

© Findy Inc. 44
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ○ 予期せず既存処理を壊してしまうことが多い ■ デプロイ前に全機能リグレッションテストをやる ■ (デプロイを減らす) ■ ⾃動テストで既存処理の振る舞いを担保する🙌 ■ 過度な共通化を減らすなどアーキテクチャ刷新🙌

Slide 45

Slide 45 text

© Findy Inc. 45
 変更障害率 不意に既存を壊すことが 減ったので 変更障害率が低下したぞ！ アーキテクチャ刷新で 影響範囲の調査が楽になって 開発者体験も向上！

Slide 46

Slide 46 text

© Findy Inc. 46
 変更障害率 不意に既存を壊すことが 減ったので 変更障害率が低下したぞ！ アーキテクチャ刷新で 影響範囲の調査が楽になって 開発者体験も向上！

Slide 47

Slide 47 text

© Findy Inc. 47
 平均修復時間 - 本番環境で障害が発⽣した際、修復までにかかる時間 ○ 短ければ短いほど良い指標 ○ エリート⽔準は `Less than one hour`

Slide 48

Slide 48 text

© Findy Inc. 48
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ○ デプロイに時間がかかる ○ 変更量が多くエラーの特定に時間がかかる ○ エラー監視できておらず検知に時間がかかる

Slide 49

Slide 49 text

© Findy Inc. 49
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ○ デプロイに時間がかかる ■ デプロイを⾃動‧簡素化してデプロイ時間短縮🙌 ● デプロイ頻度やリードタイムの向上にも繋がる！

Slide 50

Slide 50 text

© Findy Inc. 50
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ○ 変更量が多くエラーの特定に時間がかかる ■ プルリクサイズを⼩さくすることで変更量減少🙌

Slide 51

Slide 51 text

© Findy Inc. 51
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ○ エラー監視できておらず検知に時間がかかる ■ 監視の仕組みを⼊れることで素早く検知🙌

Slide 52

Slide 52 text

© Findy Inc. 52
 平均修復時間 エラーの検知や特定が 早くなって 平均修復時間が短縮したぞ！ すぐに修復できるので 安⼼してデプロイできる！ 開発者体験向上！

Slide 53

Slide 53 text

© Findy Inc. 53
 平均修復時間 エラーの検知や特定が 早くなって 平均修復時間が短縮したぞ！ すぐに修復できるので 安⼼してデプロイできる！ 開発者体験向上！

Slide 54

Slide 54 text

© Findy Inc. 54
 まとめ 開発者体験に注⽬することで 持続可能な⽣産性向上を 実現していきましょう！

Slide 55

Slide 55 text

© Findy Inc. 55
 プロダクトエンジニア ‧エンジニアをターゲットとした  プロダクト開発 ‧技術はモダンが当たり前 ‧⾼い開発⽣産性 ‧開発者体験の追求 ‧CI/CDや⾃動テストが  整備された開発環境 We are hiring！