Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
Search
ham
September 17, 2024
Technology
5
1.8k
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
2024年9月18日、デブサミ関西で登壇したスライド
https://event.shoeisha.jp/devsumi/20240918/session/5296
ham
September 17, 2024
Tweet
Share
More Decks by ham
See All by ham
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
ham0215
9
1.5k
アジャイルを始めるための基礎を固める
ham0215
1
85
開発者体験を意識した開発チームの生産性向上の取り組み
ham0215
3
890
MySQLのViewを活用した安全なマルチテナントの実現方法
ham0215
2
920
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.6k
今こそ思い出すGraphQLの特徴
ham0215
0
170
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
530
CIは5分以内!素早い開発サイクルを支えるCI
ham0215
1
4k
現場主導で取り組む継続的な技術的負債の解消
ham0215
4
4.6k
Other Decks in Technology
See All in Technology
DevOps視点でAWS re:invent2024の新サービス・アプデを振り返ってみた
oshanqq
0
180
ガバメントクラウドのセキュリティ対策事例について
fujisawaryohei
0
530
日本版とグローバル版のモバイルアプリ統合の開発の裏側と今後の展望
miichan
1
130
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
2
2.3k
Storage Browser for Amazon S3
miu_crescent
1
140
LINEヤフーのフロントエンド組織・体制の紹介【24年12月】
lycorp_recruit_jp
0
530
1等無人航空機操縦士一発試験 合格までの道のり ドローンミートアップ@大阪 2024/12/18
excdinc
0
160
サービスでLLMを採用したばっかりに振り回され続けたこの一年のあれやこれや
segavvy
2
410
GitHub Copilot のテクニック集/GitHub Copilot Techniques
rayuron
34
13k
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
13
3.7k
10個のフィルタをAXI4-Streamでつなげてみた
marsee101
0
170
[Ruby] Develop a Morse Code Learning Gem & Beep from Strings
oguressive
1
150
Featured
See All Featured
Faster Mobile Websites
deanohume
305
30k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
32
2.7k
Docker and Python
trallard
42
3.1k
GraphQLとの向き合い方2022年版
quramy
44
13k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.4k
Mobile First: as difficult as doing things right
swwweet
222
9k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
How STYLIGHT went responsive
nonsquared
95
5.2k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Transcript
© Findy Inc. 1 開発者の定量・定性データを 組み合わせて開発者体験を 把握するための取り組み 2024.09.18 Developers Summit
2024 KANSAI 浜田 直人 Naoto Hamada (ham)
© Findy Inc. 2 開発生産性が向上する方法を探求しているエンジニア! Ruby / Rails / React
/ TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜田 直人 Naoto Hamada (ham) @hamchance0215
挑戦するエンジニアの プラットフォームをつくる。 テクノロジーによる社会変革の時代に最も必要なことは、エンジニアの可能性を拡げることです。 Findyは、アルゴリズムとヒューマニティの融合によって、 すべてのエンジニアが不安なく挑戦できる世界共通のプラットフォームをつくります。 個人のチャンスを生み出し、組織の生産性を向上させ、社会の人材資産を好循環させる。 エンジニアプラットフォームが、デジタル社会の発展を加速していきます。 ビジョン © Findy
Inc. 3
© 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
© Findy Inc. 5 Findy Team+(チームプラス)とは? 開発生産性の可視化、開発プロセスの伸びしろの発見、継続的 な改善をサポート 生産性可視化 生産性向上
事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー・配置・ツールの伸びしろを可視化・最適化) 文化づくり・自己組織化 (メンバーの自発的な改善促進、改善を称賛する文化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発生産性が高い組織で働きたい) Recruit Biz
© Findy Inc. 6 Findy Team+(チームプラス)とは? ※2024年9月時点
© Findy Inc. 7 Agenda - なぜ開発者体験(DevEx)を把握したいのか? - DevExについて -
DevExの測定方法 - DevExの測定結果 - やってみた感想と今後の伸びしろ
© Findy Inc. なぜ開発者体験(DevEx)を 把握したいのか? 8
© Findy Inc. 9 「3人のレンガ職人」 - 旅人が3人のレンガ職人に「何をしているのですか?」 - 1人目の職人は「レンガを積んでいる」と答え、仕事に不満 を抱えています
- 2人目の職人は「壁を作っている」と答え、家族を養うため に働いていることを誇りに思っています - 3人目の職人は「歴史に残る大聖堂を建てている」と答え、 自分の仕事が社会に貢献することに喜びを感じています
© Findy Inc. 10 「3人のレンガ職人」 - 旅人が3人のレンガ職人に「何をしているのですか?」 - 1人目の職人は「レンガを積んでいる」と答え、仕事に不満 を抱えています
- 2人目の職人は「壁を作っている」と答え、家族を養うため に働いていることを誇りに思っています - 3人目の職人は「歴史に残る大聖堂を建てている」と答え、 自分の仕事が社会に貢献することに喜びを感じています - 同じ仕事でも、意義や目的意識を持つことで、 モチベーションや幸福度が向上 - より大きな目標やビジョンを持つことで、 日々の仕事にやりがいや充実感を見出すこと ができる - 自らの仕事に責任と誇りを持つことで、積極 的な姿勢で仕事に取り組むことができる
© Findy Inc. 11 エンジニアに当てはめる - EMが3人のエンジニアに「何をしているのですか?」 - 1人目のエンジニアは「コードを書いている」と答え、仕事 に不満を抱えています
- 2人目のエンジニアは「プロダクトを作っている」と答え、 家族を養うために働いていることを誇りに思っています - 3人目のエンジニアは「エンジニアのプラットフォームを創 っている」と答え、自分の仕事が社会に貢献することに喜 びを感じています
© Findy Inc. 12 エンジニアに当てはめる - EMが3人のエンジニアに「何をしているのですか?」 - 1人目のエンジニアは「コードを書いている」と答え、仕事 に不満を抱えています
- 2人目のエンジニアは「プロダクトを作っている」と答え、 家族を養うために働いていることを誇りに思っています - 3人目のエンジニアは「エンジニアのプラットフォームを創 っている」と答え、自分の仕事が社会に貢献することに喜 びを感じています - エンジニアも同様! - 開発する目的が明確かつ共感していることで、 やりがいを見出すことができ、モチベーショ ン高く、積極的な姿勢で開発に取り組むこと ができる
© Findy Inc. 13 エンジニアに当てはめる - EMが3人のエンジニアに「何をしているのですか?」 - 1人目のエンジニアは「コードを書いている」と答え、仕事 に不満を抱えています
- 2人目のエンジニアは「プロダクトを作っている」と答え、 家族を養うために働いていることを誇りに思っています - 3人目のエンジニアは「エンジニアのプラットフォームを創 っている」と答え、自分の仕事が社会に貢献することに喜 びを感じています - ビルドトラップにハマりづらい - 工数とインパクトをトレードオフした提案が できる - 開発する目的を理解しているので、目的に沿 っていないものを作っていることに気づいた り、目的を達成のための工数が少ない代替案 を提案することができる
© Findy Inc. 14 アウトプット量も大事 - どれだけビジョンに共感していてモチベーションが高くて も、開発環境や開発プロセスが整っていなかったり、個々 のスキルが不足しているとアウトプット量が少なくなり開 発が進まず何も生み出せない
© Findy Inc. 15 モチベーション && アウトプット量 - 両方を高めていくことが重要 -
開発者のモチベーションや幸福度 - 開発者のアウトプット量 両方を測れる 良い指標ないかな?
© Findy Inc. 16 モチベーション && アウトプット量 - 両方を高めていくことが重要 -
開発者のモチベーションや幸福度 - 開発者のアウトプット量 両方を測れる 良い指標ないかな? 両方を把握するための指標 DevEx: 開発者体験 (Developer Experience)
© Findy Inc. DevExについて 17
© Findy Inc. 18 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
© Findy Inc. 19 DevExとは? - 開発者が自分の仕事についてどのように感じ、考え、価値 を見出すかをまとめたもの - DevExを改善することは、生産性だけではなく、満足度、
エンゲージメント、従業員の定着率を高める - DevExの改善がもたらす効果 - 開発者:より高い生産性と創造性 - チーム: より良いコード品質とイノベーション - 組織: より高い定着率と利益
© Findy Inc. 20 DevExの三次元 - DevExに影響を与える3つの要素 - フロー状態 (Flow
State) - 認知負荷 (Cognitive Load) - フィードバックループ (Feedback Loops) https://queue.acm.org/detail.cfm?id=3595878
© Findy Inc. 21 フロー状態(Flow State) - 活力に満ちた集中、楽しみを伴う精神状態 - フローに入ると、生産性の向上、イノベーション、成長に
つながる - 仕事を楽しむことでより良いパフォーマンスを発揮して、 より高品質な製品を開発する
© Findy Inc. 22 フロー状態(Flow State) - 活力に満ちた集中、楽しみを伴う精神状態 - フローに入ると、生産性の向上、イノベーション、成長に
つながる - 仕事を楽しむことでより良いパフォーマンスを発揮して、 より高品質な製品を開発する - 深く集中して業務を行う時間を大幅に確保し た開発者は、生産性が50%向上 - 仕事に魅力を感じている開発者は、生産性を 30%高く感じている
© Findy Inc. 23 認知負荷(Cognitive Load) - 開発者がタスクを実行するために必要な精神的処理の量 - 認知負荷が高い場合、タスクの完了に追加の時間と労力を
費やす必要がある
© Findy Inc. 24 認知負荷(Cognitive Load) - 開発者がタスクを実行するために必要な精神的処理の量 - 認知負荷が高い場合、タスクの完了に追加の時間と労力を
費やす必要がある - コードの理解度が高いと答えた開発者は、低 いか全くないと答えた開発者よりも、42% 生産性が高いと感じる - ツールや作業プロセスが直感的で使いやすい と感じる開発者は、理解しにくいと感じる開 発者に比べて、50%革新的だと感じている
© Findy Inc. 25 フィードバックループ (Feedback Loops) - 作業中のものに関するフィードバックと学習のループ -
迅速なフィードバックループは、開発者が迅速に作業を完 了することを可能にする - 遅いフィードバックループは、開発プロセスを中断させ、 タスク切り替えによりフラストレーションや遅延を引き起 こす
© Findy Inc. 26 フィードバックループ (Feedback Loops) - 作業中のものに関するフィードバックと学習のループ -
迅速なフィードバックループは、開発者が迅速に作業を完 了することを可能にする - 遅いフィードバックループは、開発プロセスを中断させ、 タスク切り替えによりフラストレーションや遅延を引き起 こす - コードレビューが早いと答えた開発者は、遅 いと答えた開発者より、20%革新的だと感 じている - 開発者の質問に迅速に回答できるチームは、 回答が遅いチームと比較して、技術的負債が 50%少ない
© Findy Inc. DevExの測定方法 27
© Findy Inc. 28 DevExの三次元の測定方法 ”DevEx: What Actually Drives Productivity”から引用
© Findy Inc. 29 DevExの三次元の測定方法 ”DevEx: What Actually Drives Productivity”から引用
© Findy Inc. 30 DevExの三次元の測定方法 - PERCEPTIONS:開発者の定性情報 - 開発者の認識を開発者サーベイなどで抽出 -
WORKFLOWS:開発の定量情報 - システムやプロセスのデータから抽出 - KPIS - 上記2つだけを測定すると個別最適になってしまう可能 性がある - 個別最適にならないように開発組織が目指すべき目標を 定義して達成状況を確認
© Findy Inc. 31 DevExの三次元の測定方法 ”DevEx: What Actually Drives Productivity”から引用
© Findy Inc. 32 PERCEPTIONS フィードバックループ 認知負荷 フロー状態 自動テストの速度と出 力に対する満足度
コードベース の複雑さの認 識 集中して中断を避け る能力の認識 ローカル変更を検証す るのにかかる時間に対 する満足度 本番テストの デバッグの容 易さ タスクやプロジェク ト目標の明確さに対 する満足度 本番に変更をデプロイ するのにかかる時間に 対する満足度 ドキュメント 理解の容易さ オンコールの際の中 断性の認識
© Findy Inc. 33 PERCEPTIONS - 5段階のサーベイ(Googleフ ォーム)を作成 - 開発者に回答してもらう
© Findy Inc. 34 DevExの三次元の測定方法 ”DevEx: What Actually Drives Productivity”から引用
© Findy Inc. 35 WORKFLOWS フィードバックループ 認知負荷 フロー状態 CI結果を生成するのに かかる時間
技術的質問に対す る回答を得るのに かかる時間 会議や中断なし でブロックする 時間の数 コードレビューのター ンアラウンドタイム 変更をデプロイす るために必要な手 動ステップ 計画外のタスク やリクエストの 頻度 デプロイリードタイム ドキュメントの改 善頻度 インシデントの 頻度
© Findy Inc. 36 WORKFLOWS フィードバックループの項目を定量指標へ置き換え - CI結果を生成するのにかかる時間 - CIの平均実行時間
- コードレビューのターンアラウンドタイム - レビュー依頼からレビュー完了までの時間 - デプロイリードタイム - 変更のリードタイム(Four Keys)
© Findy Inc. 37 WORKFLOWS 認知不可の項目を定量指標へ置き換え - 技術的質問に対する回答を得るのにかかる時間 - マージ済みプルリクエスト数
/ 人 / 日 - 変更をデプロイするために必要な手動ステップ - リリースPRが作られてからデプロイするまでの時間 - ドキュメントの改善頻度 - ドキュメントの改善のプルリクエスト数
© Findy Inc. 38 WORKFLOWS フロー状態の項目を定量指標へ置き換え - 会議や中断なしでブロックする時間の数 - 1日あたりのミーティング時間
- 計画外のタスクやリクエストの頻度 - 勤務時間あたりのトイル対応時間の割合 - インシデントの頻度 - インシデント数 / 月
© Findy Inc. 39 DevExの三次元の測定方法 ”DevEx: What Actually Drives Productivity”から引用
© Findy Inc. 40 KPIS 開発組織のKPIとして3つ定義 - ソフトウェアを提供するプロセスが容易であること - 従業員のエンゲージメントや満足度が高いこと
- 計画していた開発がデリバリーされていること
© Findy Inc. 41 KPIS 開発組織のKPIとして3つ定義 - ソフトウェアを提供するプロセスが容易であること - Four
Keys - 開発者サーベイ - 従業員のエンゲージメントや満足度が高いこと - 従業員サーベイの結果 - 計画していた開発がデリバリーされていること - 月次の開発計画の予実 - 開発者サーベイ
© Findy Inc. DevExの測定結果 42
© Findy Inc. 43 DevExの測定 私が所属している開発チームの8月のDevExを測定
© Findy Inc. 44 DevExの測定 ”DevEx: What Actually Drives Productivity”から引用
© Findy Inc. 45 DevExの測定 フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 自動テストの速度と出力に対する
満足度 コードベースの複雑さの認識 集中して中断を避ける能力 の認識 ローカル変更を検証するのにかか る時間に対する満足度 本番テストのデバッグの容易 さ タスクやプロジェクト目標 の明確さに対する満足度 本番に変更をデプロイするのにか かる時間に対する満足度 ドキュメント理解の容易さ オンコールの際の中断性の 認識 WORKFLOWS CI結果を生成するのにかかる時間 技術的質問に対する回答を得 るのにかかる時間 会議や中断なしでブロック する時間の数 コードレビューのターンアラウン ドタイム 変更をデプロイするために必 要な手動ステップ 計画外のタスクやリクエス トの頻度 デプロイリードタイム ドキュメントの改善頻度 インシデントの頻度 KPIS ソフトウェアを提供するプロセスが容易であること 従業員のエンゲージメントや満足度が高いこと 計画していた開発がデリバリーされていること
© Findy Inc. 46 DevExの測定 フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 自動テストの速度と出力に対する
満足度 コードベースの複雑さの認識 集中して中断を避ける能力 の認識 ローカル変更を検証するのにかか る時間に対する満足度 本番テストのデバッグの容易 さ タスクやプロジェクト目標 の明確さに対する満足度 本番に変更をデプロイするのにか かる時間に対する満足度 ドキュメント理解の容易さ オンコールの際の中断性の 認識 WORKFLOWS CI結果を生成するのにかかる時間 技術的質問に対する回答を得 るのにかかる時間 会議や中断なしでブロック する時間の数 コードレビューのターンアラウン ドタイム 変更をデプロイするために必 要な手動ステップ 計画外のタスクやリクエス トの頻度 デプロイリードタイム ドキュメントの改善頻度 インシデントの頻度 KPIS ソフトウェアを提供するプロセスが容易であること 従業員のエンゲージメントや満足度が高いこと 計画していた開発がデリバリーされていること 開発者 サーベイ 指標 指標 & サーベイ
© Findy Inc. 47 DevExの測定 フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 自動テストの速度と出力に対する
満足度 コードベースの複雑さの認識 集中して中断を避ける能力 の認識 ローカル変更を検証するのにかか る時間に対する満足度 本番テストのデバッグの容易 さ タスクやプロジェクト目標 の明確さに対する満足度 本番に変更をデプロイするのにか かる時間に対する満足度 ドキュメント理解の容易さ オンコールの際の中断性の 認識 WORKFLOWS CIの平均実行時間 マージ済みプルリクエスト数 / 人 / 日 ミーティング時間 / 人 / 日 レビュー依頼からレビュー完了ま での時間 リリースPRが作られてからデ プロイするまでの時間 勤務時間あたりのトイル対 応時間の割合 変更のリードタイム(Four Keys) ドキュメントの改善のプルリ クエスト数 インシデント数 / 月 KPIS Four Keys 開発者サーベイ「ソフトウェアを提供するプロセスが容易だと感じますか」 従業員サーベイ 開発計画の予実 開発者 サーベイ 指標 指標 & サーベイ
© Findy Inc. 48 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 自動テストの速度と出力に対する 満足度 コードベースの複雑さの認識 集中して中断を避ける能力 の認識 ローカル変更を検証するのにかか る時間に対する満足度 本番テストのデバッグの容易 さ タスクやプロジェクト目標 の明確さに対する満足度 本番に変更をデプロイするのにか かる時間に対する満足度 ドキュメント理解の容易さ オンコールの際の中断性の 認識 WORKFLOWS CIの平均実行時間 マージ済みプルリクエスト数 / 人 / 日 ミーティング時間 / 人 / 日 レビュー依頼からレビュー完了ま での時間 リリースPRが作られてからデ プロイするまでの時間 勤務時間あたりのトイル対 応時間の割合 変更のリードタイム(Four Keys) ドキュメントの改善のプルリ クエスト数 インシデント数 / 月 KPIS Four Keys 開発者サーベイ「ソフトウェアを提供するプロセスが容易だと感じますか」 従業員サーベイ 開発計画の予実
© Findy Inc. 49 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 赤: 1.0〜3.0 黄: 3.0〜3.5 緑: 3.5〜5.0 自動テストの速度と出力に対する満 足度 3.7 コードベースの複雑さの認識 3.3 集中して中断を避ける能力 の認識 3.9 ローカル変更を検証するのにかかる 時間に対する満足度 4.0 本番テストのデバッグの容易 さ 3.1 タスクやプロジェクト目標 の明確さに対する満足度 4.1 本番に変更をデプロイするのにかか る時間に対する満足度 4.2 ドキュメント理解の容易さ 3.1 オンコールの際の中断性の 認識 3.4 - 3未満はなく全体的に良い状態 - コードベースの複雑さはコードが増加すると落ちるので継 続的にリファクタを入れている - 本番監視やドキュメントやオンコールなどは伸びしろあり
© Findy Inc. 50 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 WORKFLOWS CIの平均実行時間 Frontend: 10分 / Backend: 5分 緑: 〜3分 黄: 3〜5分 赤: 5分〜 マージ済みプルリクエスト数 / 人 / 日 3.7件/人/日 緑: 4件〜 黄: 2〜4件 赤: 〜2件 ミーティング時間 / 人 / 日 1.6h 緑: 〜2.0h 黄: 2.0〜4h 赤: 4h〜 レビュー依頼からレビュー完了ま での時間 1.7h 緑: 〜1.0h 黄: 1.0〜4.0h 赤: 4.0h〜 リリースPRが作られてからデ プロイするまでの時間 1.1h 緑: 〜1.0h 黄: 1.0〜4.0h 赤: 4.0h〜 勤務時間あたりのトイル対 応時間の割合 5.58% 緑: 〜5% 黄: 5〜10% 赤: 10%〜 変更のリードタイム(Four Keys) 14.2h 緑: 〜24.0h 黄: 24.0〜120.0h 赤: 120h〜 ドキュメントの改善のプルリ クエスト数 29件 緑: 5件〜 黄: 1〜5件 赤: 0件 インシデント数 / 月 5件 緑: 〜4件 黄: 4〜12件 赤: 12件〜
© Findy Inc. 51 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 WORKFLOWS CIの平均実行時間 Frontend: 10分 / Backend: 5分 緑: 〜3分 黄: 3〜5分 赤: 5分〜 マージ済みプルリクエスト数 / 人 / 日 3.7件/人/日 緑: 4件〜 黄: 2〜4件 赤: 〜2件 ミーティング時間 / 人 / 日 1.6h 緑: 〜2.0h 黄: 2.0〜4h 赤: 4h〜 レビュー依頼からレビュー完了ま での時間 1.7h 緑: 〜1.0h 黄: 1.0〜4.0h 赤: 4.0h〜 リリースPRが作られてからデ プロイするまでの時間 1.1h 緑: 〜1.0h 黄: 1.0〜4.0h 赤: 4.0h〜 勤務時間あたりのトイル対 応時間の割合 5.58% 緑: 〜5% 黄: 5〜10% 赤: 10%〜 変更のリードタイム(Four Keys) 14.2h 緑: 〜24.0h 黄: 24.0〜120.0h 赤: 120h〜 ドキュメントの改善のプルリ クエスト数 29件 緑: 5件〜 黄: 1〜5件 赤: 0件 インシデント数 / 月 5件 緑: 〜4件 黄: 4〜12件 赤: 12件〜 赤文字は開発速度にダイレ クトに影響を及ぼすので、 高い目標を設定! →改善サイクルを回す
© Findy Inc. 52 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 WORKFLOWS CIの平均実行時間 Frontend: 10分 / Backend: 5分 緑: 〜3分 黄: 3〜5分 赤: 5分〜 マージ済みプルリクエスト数 / 人 / 日 3.7件/人/日 緑: 4件〜 黄: 2〜4件 赤: 〜2件 ミーティング時間 / 人 / 日 1.6h 緑: 〜2.0h 黄: 2.0〜4h 赤: 4h〜 レビュー依頼からレビュー完了ま での時間 1.7h 緑: 〜1.0h 黄: 1.0〜4.0h 赤: 4.0h〜 リリースPRが作られてからデ プロイするまでの時間 1.1h 緑: 〜1.0h 黄: 1.0〜4.0h 赤: 4.0h〜 勤務時間あたりのトイル対 応時間の割合 5.58% 緑: 〜5% 黄: 5〜10% 赤: 10%〜 変更のリードタイム(Four Keys) 14.2h 緑: 〜24.0h 黄: 24.0〜120.0h 赤: 120h〜 ドキュメントの改善のプルリ クエスト数 29件 緑: 5件〜 黄: 1〜5件 赤: 0件 インシデント数 / 月 5件 緑: 〜4件 黄: 4〜12件 赤: 12件〜 赤文字は無意識に時間を 取られがちなので定量的 にウォッチすることで意 識する
© Findy Inc. 53 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 WORKFLOWS CIの平均実行時間 Frontend: 10分 / Backend: 5分 緑: 〜3分 黄: 3〜5分 赤: 5分〜 マージ済みプルリクエスト数 / 人 / 日 3.7件/人/日 緑: 4件〜 黄: 2〜4件 赤: 〜2件 ミーティング時間 / 人 / 日 1.6h 緑: 〜2.0h 黄: 2.0〜4h 赤: 4h〜 レビュー依頼からレビュー完了ま での時間 1.7h 緑: 〜1.0h 黄: 1.0〜4.0h 赤: 4.0h〜 リリースPRが作られてからデ プロイするまでの時間 1.1h 緑: 〜1.0h 黄: 1.0〜4.0h 赤: 4.0h〜 勤務時間あたりのトイル対 応時間の割合 5.58% 緑: 〜5% 黄: 5〜10% 赤: 10%〜 変更のリードタイム(Four Keys) 14.2h 緑: 〜24.0h 黄: 24.0〜120.0h 赤: 120h〜 ドキュメントの改善のプルリ クエスト数 29件 緑: 5件〜 黄: 1〜5件 赤: 0件 インシデント数 / 月 5件 緑: 〜4件 黄: 4〜12件 赤: 12件〜 サーベイでは「ドキュメント理解の容易さ」 に伸びしろがあったが、ドキュメント改善プ ロジェクトの成果が数値に出ている
© Findy Inc. 54 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 KPIS サーベイ 赤: 1.0〜3.0 黄: 3.0〜3.5 緑: 3.5〜5.0 Four Keys 開発者サーベイ「ソフトウェアを提供するプロセスが容易だと感じますか」 Four Keys: All Elite / サーベイ: 4.2 緑: All Elite / 黄: High以上 / 赤: その他 従業員サーベイ wevoxの結果より判定 開発計画の予実(月次で計画している開発機能一覧の予実とサーベイから判断) 予実: 7機能リリース(予定: 8機能) /サーベイ: 3.8 緑: 8割以上リリース / 黄: 5〜8割リリース / 赤: 5割未満リリース - KPIは全面的に良好!
© Findy Inc. 55 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 緑: + 3 黄: + 2 赤: + 1 3 2 3 3 2 3 3 2 2 WORKFLOWS 緑: + 3 黄: + 2 赤: + 1 1 2 3 2 2 2 3 3 2 PERCEPTIONSとWORKFLOWSの合計 15 13 15 最大100になるように調整 ↑の合計 / 最大値(18) * 100 83 72 83 KPIS 緑: × 1.0 黄: × 0.9 赤: × 0.8 ×1.0 ×1.0 ×1.0 合計 83 72 83 DevEx 238
© Findy Inc. 56 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 緑: + 3 黄: + 2 赤: + 1 3 2 3 3 2 3 3 2 2 WORKFLOWS 緑: + 3 黄: + 2 赤: + 1 1 2 3 2 2 2 3 3 2 PERCEPTIONSとWORKFLOWSの合計 15 13 15 最大100になるように調整 ↑の合計 / 最大値(18) * 100 83 72 83 KPIS 緑: × 1.0 黄: × 0.9 赤: × 0.8 ×1.0 ×1.0 ×1.0 合計 83 72 83 DevEx 238 PERCEPTIONSとWORKFLOWSに スコアをつけて加算する
© Findy Inc. 57 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 緑: + 3 黄: + 2 赤: + 1 3 2 3 3 2 3 3 2 2 WORKFLOWS 緑: + 3 黄: + 2 赤: + 1 1 2 3 2 2 2 3 3 2 PERCEPTIONSとWORKFLOWSの合計 15 13 15 最大100になるように調整 ↑の合計 / 最大値(18) * 100 83 72 83 KPIS 緑: × 1.0 黄: × 0.9 赤: × 0.8 ×1.0 ×1.0 ×1.0 合計 83 72 83 DevEx 238 指標として使いやすいように 0~100の値に調整
© Findy Inc. 58 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 緑: + 3 黄: + 2 赤: + 1 3 2 3 3 2 3 3 2 2 WORKFLOWS 緑: + 3 黄: + 2 赤: + 1 1 2 3 2 2 2 3 3 2 PERCEPTIONSとWORKFLOWSの合計 15 13 15 最大100になるように調整 ↑の合計 / 最大値(18) * 100 83 72 83 KPIS 緑: × 1.0 黄: × 0.9 赤: × 0.8 ×1.0 ×1.0 ×1.0 合計 83 72 83 DevEx 238 KPI未達は全体を押し下げると判断 達成状況に応じて1.0 / 0.9 / 0.8 倍する
© Findy Inc. 59 DevExの測定 (赤 < 黄 < 緑)
フィードバックループ 認知負荷 フロー状態 PERCEPTIONS 緑: + 3 黄: + 2 赤: + 1 3 2 3 3 2 3 3 2 2 WORKFLOWS 緑: + 3 黄: + 2 赤: + 1 1 2 3 2 2 2 3 3 2 PERCEPTIONSとWORKFLOWSの合計 15 13 15 最大100になるように調整 ↑の合計 / 最大値(18) * 100 83 72 83 KPIS 緑: × 1.0 黄: × 0.9 赤: × 0.8 ×1.0 ×1.0 ×1.0 合計 83 72 83 DevEx 238 238
© Findy Inc. やってみた感想と今後の伸びしろ 60
© Findy Inc. 61 やってみた感想 - 定性データが入っているので、定量データだけでは埋もれ てしまいがちな燃え尽きや定量的には問題になっていない 潜在的な問題が検知できて良い -
色分けすることで伸びしろポイントが一目でわかって良い フィードバックループ 認知負荷 フロー状態 PERCEPTIONS WORKFLOWS KPIS 伸びしろポイント 発見!
© Findy Inc. 62 今後の伸びしろ - 今回、論文からえいやーで指標を作成したので、採用する 指標や評価基準をブラッシュアップしたい - 繰り返し見たいので手軽にDevEx指標が取得できるように
したい - チームごとに一覧表示でき、健康状態が一目でわかる状態 を目指したい 全チームDevEx ヨシッ!!
© Findy Inc. 63 プロダクトエンジニア ・エンジニアをターゲットとした プロダクト開発 ・技術はモダンが当たり前 ・高い開発生産性 ・開発者体験の追求
・CI/CDや自動テストが 整備された開発環境 We are hiring!