開発者体験を定量的に把握する手法と活用事例

2025/03/06 開催イベント「DevEx専門チームに学ぶ！定性・定量からみた、開発効率を最適化させる開発者体験」の登壇資料

Transcript

1. © Findy Inc. 1 開発者体験を定量的に把握する ⼿法と活⽤事例 2025.03.06 DevEx専⾨チームに学ぶ！定性‧定量からみた、開発効率を最適化させる開発者体験 浜⽥ 直⼈ 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
5. © Findy Inc. 5 Findy Team+(チームプラス)とは？ 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 5 ⽣産性可視化 ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz
6. © Findy Inc. 6 Agenda - なぜ開発者体験(DevEx)を把握したいのか？ - DevExについて - DevExの測定⽅法 - DevExの測定結果 - まとめ
7. © Findy Inc. なぜ開発者体験(DevEx)を 把握したいのか？ 7
8. © Findy Inc. 8 「3⼈のレンガ職⼈」 - 旅⼈が3⼈のレンガ職⼈に「何をしているのですか？」 - 1⼈⽬の職⼈は「レンガを積んでいる」と答え、ただ⽬の前 の作業をしているだけだと答えます - 2⼈⽬の職⼈は「壁を作っている」と答え、⾃分の仕事が⽬ 的を持っていることを理解していると答えます - 3⼈⽬の職⼈は「歴史に残る偉⼤な⼤聖堂を造っている」と 答え、⾃分の仕事がより⼤きな意義を持つことを理解して いると答えます
9. © Findy Inc. 9 「3⼈のレンガ職⼈」 - 旅⼈が3⼈のレンガ職⼈に「何をしているのですか？」 - 1⼈⽬の職⼈は「レンガを積んでいる」と答え、ただ⽬の前 の作業をしているだけだと答えます - 2⼈⽬の職⼈は「壁を作っている」と答え、⾃分の仕事が⽬ 的を持っていることを理解していると答えます - 3⼈⽬の職⼈は「歴史に残る偉⼤な⼤聖堂を造っている」と 答え、⾃分の仕事がより⼤きな意義を持つことを理解して いると答えます - 同じ仕事でも⽬的意識を持つことで、モチ ベーションや幸福度が向上 - ⼤きな⽬標やビジョンを持つことで⽇々の仕 事にやりがいや充実感を⾒出すことができる - ⾃らの仕事に責任と誇りを持つことで、積極 的な姿勢で仕事に取り組むことができる
10. © Findy Inc. 10 エンジニアに当てはめる - EMが3⼈のエンジニアに「何をしているのですか？」 - 1⼈⽬のエンジニアは「コードを書いている」と答え、ただ ⽬の前の作業をしているだけだと答えます - 2⼈⽬のエンジニアは「プロダクトを作っている」と答え、 ⾃分の仕事が⽬的を持っていることを理解していると答え ます - 3⼈⽬のエンジニアは「エンジニアのプラットフォームを 創っている」と答え、⾃分の仕事がより⼤きな意義を持つ ことを理解していると答えます
11. © Findy Inc. 11 エンジニアに当てはめる - EMが3⼈のエンジニアに「何をしているのですか？」 - 1⼈⽬のエンジニアは「コードを書いている」と答え、ただ ⽬の前の作業をしているだけだと答えます - 2⼈⽬のエンジニアは「プロダクトを作っている」と答え、 ⾃分の仕事が⽬的を持っていることを理解していると答え ます - 3⼈⽬のエンジニアは「エンジニアのプラットフォームを 創っている」と答え、⾃分の仕事がより⼤きな意義を持つ ことを理解していると答えます - エンジニアも同様！ - 開発する⽬的が明確かつ共感していることで、 やりがいを⾒出すことができ、モチベーション ⾼く、積極的な姿勢で開発に取り組むことがで きる
12. © Findy Inc. 12 エンジニアに当てはめる - EMが3⼈のエンジニアに「何をしているのですか？」 - 1⼈⽬のエンジニアは「コードを書いている」と答え、ただ ⽬の前の作業をしているだけだと答えます - 2⼈⽬のエンジニアは「プロダクトを作っている」と答え、 ⾃分の仕事が⽬的を持っていることを理解していると答え ます - 3⼈⽬のエンジニアは「エンジニアのプラットフォームを 創っている」と答え、⾃分の仕事がより⼤きな意義を持つ ことを理解していると答えます - 開発する⽬的を理解していると、⽬的に沿っ ていないものを作っていることに気づいた り、⽬的を達成のための⼯数が少ない代替案 を提案することができる - ビルドトラップにハマりづらい - ⼯数とインパクトをトレードオフした提 案ができる
13. © Findy Inc. 13 アウトプット量も⼤事 - どれだけビジョンに共感していてモチベーションが⾼くて も、開発環境や開発プロセスが整っていなかったり、個々 のスキルが不⾜しているとアウトプット量が少なくなり開 発が進まず何も⽣み出せません
14. © Findy Inc. 14 モチベーション && アウトプット量 - 両⽅を⾼めていくことが重要 - 開発者のモチベーションや幸福度 - 開発者のアウトプット量 両⽅を測れる 良い指標ないかな？
15. © Findy Inc. 15 モチベーション && アウトプット量 - 両⽅を⾼めていくことが重要 - 開発者のモチベーションや幸福度 - 開発者のアウトプット量 両⽅を測れる 良い指標ないかな？ 両⽅を把握するための指標 DevEx: 開発者体験 (Developer Experience)
16. © Findy Inc. DevExについて 16
17. © Findy Inc. 17 DevExの参考記事 https://queue.acm.org/detail.cfm?id=3595878 - DevEx: What Actually Drives Productivity - 2023年3⽉にソフトウェ アエンジニア向け雑誌 [acm queue]に寄稿 - DevEx in Action - 2024年1⽉にソフトウェ アエンジニア向け雑誌 [acm queue]に寄稿 https://queue.acm.org/detail.cfm?id=3639443
18. © Findy Inc. 18 DevExとは？ - 開発者が⾃分の仕事についてどのように感じ、考え、価値 を⾒出すかをまとめたもの - DevExを改善することは、⽣産性だけではなく、満⾜度、エ ンゲージメント、従業員の定着率を⾼める - DevExの改善がもたらす効果 - 開発者:より⾼い⽣産性と創造性 - チーム: より良いコード品質とイノベーション - 組織: より⾼い定着率と利益
19. © Findy Inc. 19 DevExの三次元 - DevExに影響を与える3つの要素 - フロー状態 (Flow State) - 認知負荷 (Cognitive Load) - フィードバックループ (Feedback Loops) https://queue.acm.org/detail.cfm?id=3595878
20. © Findy Inc. 20 フロー状態(Flow State) - 活⼒に満ちた集中、楽しみを伴う精神状態 - フローに⼊ると、⽣産性の向上、イノベーション、成⻑に つながる - 仕事を楽しむことでより良いパフォーマンスを発揮して、 より⾼品質な製品を開発する
21. © Findy Inc. 21 フロー状態(Flow State) - 活⼒に満ちた集中、楽しみを伴う精神状態 - フローに⼊ると、⽣産性の向上、イノベーション、成⻑に つながる - 仕事を楽しむことでより良いパフォーマンスを発揮して、 より⾼品質な製品を開発する - 深く集中して業務を⾏う時間を⼤幅に確保し た開発者は、⽣産性が50%向上 - 仕事に魅⼒を感じている開発者は、⽣産性を 30%⾼く感じている
22. © Findy Inc. 22 認知負荷(Cognitive Load) - 開発者がタスクを実⾏するために必要な精神的処理の量 - 認知負荷が⾼い場合、タスクの完了に追加の時間と労⼒を 費やす必要がある
23. © Findy Inc. 23 認知負荷(Cognitive Load) - 開発者がタスクを実⾏するために必要な精神的処理の量 - 認知負荷が⾼い場合、タスクの完了に追加の時間と労⼒を 費やす必要がある - コードの理解度が⾼いと答えた開発者は、低 いか全くないと答えた開発者よりも、42%⽣ 産性が⾼いと感じる - ツールや作業プロセスが直感的で使いやすい と感じる開発者は、理解しにくいと感じる開 発者に⽐べて、50%⾰新的だと感じている
24. © Findy Inc. 24 フィードバックループ (Feedback Loops) - 作業中のものに関するフィードバックと学習のループ - 迅速なフィードバックループは、開発者が迅速に作業を完 了することを可能にする - 遅いフィードバックループは、開発プロセスを中断させ、 タスク切り替えによりフラストレーションや遅延を引き起 こす
25. © Findy Inc. 25 フィードバックループ (Feedback Loops) - 作業中のものに関するフィードバックと学習のループ - 迅速なフィードバックループは、開発者が迅速に作業を完 了することを可能にする - 遅いフィードバックループは、開発プロセスを中断させ、 タスク切り替えによりフラストレーションや遅延を引き起 こす - コードレビューが早いと答えた開発者は、遅 いと答えた開発者より、20%⾰新的だと感じ ている - 開発者の質問に迅速に回答できるチームは、 回答が遅いチームと⽐較して、技術的負債が 50%少ない
26. © Findy Inc. DevExの測定⽅法 26
27. © Findy Inc. 27 DevExの三次元の測定⽅法 ”DevEx: What Actually Drives Productivity”から引⽤
28. © Findy Inc. 28 DevExの三次元の測定⽅法 ”DevEx: What Actually Drives Productivity”から引⽤
29. © Findy Inc. 29 DevExの三次元の測定⽅法 - PERCEPTIONS:開発者の定性情報 - 開発者の認識を開発者サーベイなどで抽出 - WORKFLOWS:開発の定量情報 - システムやプロセスのデータから抽出 - KPIS - 上記2つだけを測定すると個別最適になってしまう可能 性がある - 個別最適にならないように開発組織が⽬指すべき⽬標を 定義して達成状況を確認
30. © Findy Inc. 30 DevExの三次元の測定⽅法 ”DevEx: What Actually Drives Productivity”から引⽤
31. © Findy Inc. 31 PERCEPTIONS フィードバックループ 認知負荷 フロー状態 バリューストリームにおける プロセス課題を定期的に発⾒ ‧改善できている 開発タスクは適切なサイ ズに分割されていて、レ ビュー負荷は⼩さい ミーティングによる作業 の中断は少なく、開発に 集中できている チームにおける、デプロイ頻 度について満⾜している バグや障害対応による通 常の開発タスクへの影響 は少ない 予定外や割り込みのタス クは少なく、計画通りに 作業を進められている チームが実現した成果が、 ユーザーの期待に応えている 実感がある ドキュメントが整備され ており、すぐに参照でき る チームのプロジェクト は、概ね予定納期通りに 完了している - ⾃分たちの開発チームの沿った形にカスタマイズ
32. © Findy Inc. 32 PERCEPTIONS - Findy Team+のサーベイで抽出
33. © Findy Inc. 33 DevExの三次元の測定⽅法 ”DevEx: What Actually Drives Productivity”から引⽤
34. © Findy Inc. 34 WORKFLOWS フィードバックループ 認知負荷 フロー状態 CIの平均実⾏時間 マージ済みプルリクエス ト数 / ⼈ / ⽇ ミーティング時間 / ⼈ / ⽇ レビュー依頼からレビュー完 了までの時間 リリースPRが作られてか らデプロイするまでの時 間 勤務時間あたりのトイ ル対応時間の割合 変更のリードタイム (Four Keys) ドキュメントの改善の プルリクエスト数 インシデント数 / ⽉ - ⾃分たちの開発チームの沿った形にカスタマイズ
35. © Findy Inc. 35 WORKFLOWS - Findy Team+やGitHub Actionsなどの利⽤サービスのデー タから抽出する
36. © Findy Inc. 36 DevExの三次元の測定⽅法 ”DevEx: What Actually Drives Productivity”から引⽤
37. © Findy Inc. 37 KPIS 開発組織のKPIとして3つ定義 - ソフトウェアを提供するプロセスが容易であること - Findy Team+で測定 ▪ 定量: Four Keys、定性: サーベイ - 従業員のエンゲージメントや満⾜度が⾼いこと - 従業員サーベイで測定 - 計画していた開発がデリバリーされていること - ⽉次の開発計画の予実
38. © Findy Inc. DevExの測定結果 38
39. © Findy Inc. 39 DevExの測定 フィードバックループ 認知負荷 フロー状態 PERCEPTIONS バリューストリームにおけるプロセ ス課題を定期的に発⾒‧改善できて いる 開発タスクは適切なサイズに分 割されていて、レビュー負荷は ⼩さい ミーティングによる作業の中断 は少なく、開発に集中できてい る チームにおける、デプロイ頻度につ いて満⾜している バグや障害対応による通常の開 発タスクへの影響は少ない 予定外や割り込みのタスクが少 ない チームが実現した成果が、ユーザー の期待に応えている実感がある ドキュメントが整備されてお り、すぐに参照できる チームのプロジェクトは、概ね 予定納期通りに完了している WORKFLOWS CIの平均実⾏時間 プルリクエスト数 / ⼈ / ⽇ ミーティング時間 / ⼈ / ⽇ レビュー依頼からレビュー完了まで の時間 リリースPRが作られてからデ プロイするまでの時間 勤務時間あたりのトイル対応時 間の割合 変更のリードタイム(Four Keys) ドキュメントの改善のプルリク エスト数 インシデント数 / ⽉ KPIS Four Keys / 開発者サーベイ 従業員サーベイ 開発計画の予実
40. © Findy Inc. 40 DevExの測定 フィードバックループ 認知負荷 フロー状態 PERCEPTIONS バリューストリームにおけるプロセ ス課題を定期的に発⾒‧改善できて いる 開発タスクは適切なサイズに分 割されていて、レビュー負荷は ⼩さい ミーティングによる作業の中断 は少なく、開発に集中できてい る チームにおける、デプロイ頻度につ いて満⾜している バグや障害対応による通常の開 発タスクへの影響は少ない 予定外や割り込みのタスクが少 ない チームが実現した成果が、ユーザー の期待に応えている実感がある ドキュメントが整備されてお り、すぐに参照できる チームのプロジェクトは、概ね 予定納期通りに完了している WORKFLOWS CIの平均実⾏時間 プルリクエスト数 / ⼈ / ⽇ ミーティング時間 / ⼈ / ⽇ レビュー依頼からレビュー完了まで の時間 リリースPRが作られてからデ プロイするまでの時間 勤務時間あたりのトイル対応時 間の割合 変更のリードタイム(Four Keys) ドキュメントの改善のプルリク エスト数 インシデント数 / ⽉ KPIS Four Keys / 開発者サーベイ 従業員サーベイ 開発計画の予実 - 全体を把握しやすくするため3段階で⾊分け - PERCEPTIONS ◦ ⾚: 3.0未満、⻩: 3.0-3.9、緑: 4.0以上 - WORKFLOWS / KPIS ◦ 項⽬ごとに閾値を設定
41. © Findy Inc. 41 DevExの測定 フィードバックループ 認知負荷 フロー状態 PERCEPTIONS バリューストリームにおけるプロセ ス課題を定期的に発⾒‧改善できて いる 開発タスクは適切なサイズに分 割されていて、レビュー負荷は ⼩さい ミーティングによる作業の中断 は少なく、開発に集中できてい る チームにおける、デプロイ頻度につ いて満⾜している バグや障害対応による通常の開 発タスクへの影響は少ない 予定外や割り込みのタスクが少 ない チームが実現した成果が、ユーザー の期待に応えている実感がある ドキュメントが整備されてお り、すぐに参照できる チームのプロジェクトは、概ね 予定納期通りに完了している WORKFLOWS CIの平均実⾏時間 プルリクエスト数 / ⼈ / ⽇ ミーティング時間 / ⼈ / ⽇ レビュー依頼からレビュー完了まで の時間 リリースPRが作られてからデ プロイするまでの時間 勤務時間あたりのトイル対応時 間の割合 変更のリードタイム(Four Keys) ドキュメントの改善のプルリク エスト数 インシデント数 / ⽉ KPIS Four Keys / 開発者サーベイ 従業員サーベイ 開発計画の予実
42. © Findy Inc. まとめ 42
43. © Findy Inc. 43 まとめ - DevExの定義と向上した際の効果を明確にしました ◦ フロー状態 / 認知負荷 / フィードバックループ - DevExの測定⽅法を明確にしました ◦ 定性データと定量データの組み合わせて、⽚⽅だけでは 埋もれてしまいがちな問題を検知 - DevExを可視化して改善サイクルを回すことで、開発者が やりがいや充実感をもって積極的に業務に取り組める環境 にしていきましょう！