Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ham
August 28, 2024

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

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

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

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

ham

August 28, 2024
Tweet

More Decks by ham

Other Decks in Technology

Transcript

  1. © Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア! Ruby / Rails / React

    / TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215
  2. © 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
  3. © Findy Inc. 5 Findy Team+(チームプラス)とは? 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 5 ⽣産性可視化

    ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー・配置・ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz
  4. © Findy Inc. 13
 DORA Core Model v2.0.0 https://dora.dev/research/
 Capabilityから

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

    Keysは 向上したけど 現場はツラそう...
  6. © Findy Inc. 20
 デプロイ頻度 - 本番環境にデプロイする頻度 ◦ 多ければ多いほど良い指標 ◦

    エリート⽔準は `On demand` ▪ 必要に応じて1⽇に何回もデプロイしている
  7. © Findy Inc. 25
 デプロイ頻度 - デプロイ頻度が上げられない理由を考える。例えば... ◦ デプロイ作業が煩雑で担当者が⻑時間拘束される ▪

    デプロイ⾃動化で拘束時間低下 🙌 ◦ デプロイ前に⼿動でリグレッションテストをしないと品 質が担保できない ▪ ⾃動テストを増やし⼿動テスト軽減🙌
  8. © Findy Inc. 29
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ◦ プルリクが⼤きいため実装&レビューに時間がかかる ◦

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

    レビュアーを分散することで負荷分散🙌 • 分散するためにレビュアーを育成する ▪ レビューに権威性を持たせすぎない • どんだけ頑張っても⽬視チェック • ⾒落としもある前提で他で担保
  10. © Findy Inc. 32
 変更のリードタイム - リードタイムが短くできない理由を考える。例えば... ◦ レビュー指摘が多く⼿戻りが多い ▪

    Linterなどで最低限の品質を担保🙌 ▪ 下記を実施して⼿戻りを減らす🙌 • 設計レビューなど事前に⼤⽅針は固めておく • プルリクサイズを⼩さくする
  11. © Findy Inc. 38
 変更障害率 - 変更障害率が低くならない理由を考える。例えば... ◦ 予期せず既存処理を壊してしまうことが多い ▪

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

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

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

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

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

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

    デプロイ前に全機能リグレッションテストをやる ▪ (デプロイを減らす) ▪ ⾃動テストで既存処理の振る舞いを担保する🙌 ▪ 過度な共通化を減らすなどアーキテクチャ刷新🙌
  18. © Findy Inc. 48
 平均修復時間 - 平均修復時間が短くできない理由を考える。例えば... ◦ デプロイに時間がかかる ◦

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

    デプロイを⾃動‧簡素化してデプロイ時間短縮🙌 • デプロイ頻度やリードタイムの向上にも繋がる!