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
なぜ僕たちは 開発生産性指標を見ていないのか / Our Strategy for Devel...
Search
KAKEHASHI
PRO
July 02, 2024
Technology
24
12k
なぜ僕たちは 開発生産性指標を見ていないのか / Our Strategy for Development Productivity Metrics
開発の生産性を高める新たな視点〜開発生産性フレームワークSPACE〜
での登壇資料です
KAKEHASHI
PRO
July 02, 2024
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
100
"SaaS is Dead" は本当か!? 生成AI時代の医療 Vertical SaaS のリアル
kakehashi
PRO
4
580
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
330
時間がないなら、つくればいい 〜数十人規模のチームが自律性を発揮するために試しているいくつかのこと〜
kakehashi
PRO
25
7.5k
続・やっぱり余白が大切だった話
kakehashi
PRO
4
640
AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話
kakehashi
PRO
2
740
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
2
490
やっぱり余白が大切だった話
kakehashi
PRO
10
3.7k
貧民的プログラミングのすすめ
kakehashi
PRO
2
740
Other Decks in Technology
See All in Technology
cdk initで生成されるあのファイル達は何なのか/cdk-init-generated-files
tomoki10
1
550
クラウド開発の舞台裏とSRE文化の醸成 / SRE NEXT 2025 Lunch Session
kazeburo
1
450
全部AI、全員Cursor、ドキュメント駆動開発 〜DevinやGeminiも添えて〜
rinchsan
3
2.4k
対話型音声AIアプリケーションの信頼性向上の取り組み
ivry_presentationmaterials
2
700
Delta airlines®️ USA Contact Numbers: Complete 2025 Support Guide
airtravelguide
0
350
SREのためのeBPF活用ステップアップガイド
egmc
2
920
アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化
myamashii
1
340
Delegating the chores of authenticating users to Keycloak
ahus1
0
180
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
180
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
250
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
200
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7k
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Bash Introduction
62gerente
613
210k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Side Projects
sachag
455
42k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Building Adaptive Systems
keathley
43
2.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Docker and Python
trallard
45
3.5k
A better future with KSS
kneath
238
17k
Transcript
なぜ僕たちは 開発生産性指標を見ていないのか 株式会社カケハシ 小田中 育生 2024.07.02
小田中 育生(おだなか いくお) 株式会社ナビタイムジャパンでVP of Engineeringを務め、 2023年10月にエンジニアリングマネージャーとして株式会社カケ ハシにジョイン。 薬局DXを支えるVertical SaaS「Musubi」をコアプロダクトに位置
づけ、「しなやかな医療体験」を実現するべく新規事業のプロダ クト開発にコミットしている。 著書: • いちばんやさしいアジャイル開発の教本 • アジャイルチームによる目標づくりガイドブック ブログ: dora_e_m|note X: @dora_e_m
僕たちと開発生産性
© KAKEHASHI Inc. チームyabusame
© KAKEHASHI Inc. 新規事業のプロダクト開発チーム 立ち上げ期のプロダクト PMFまで要求の不確実性がともなう フィージビリティ・スタディが必要 なケースが多く不確実性が高い
© KAKEHASHI Inc. 高速に仮説検証ループを回したい • トランクベース開発 • モビング • スクラム
• インセプションデッキ • ワーキングアグリーメント • プロダクトの小さな変更をすばやくたくさん届けたい • 顧客のニーズなど外部の変化にすばやく対応したい
© KAKEHASHI Inc. DORA Core Model https://dora.dev/research/ Four Keysは組織のパフォーマンスと強い相関をもつことが示されている なお、Four
Keysは技術的ケイパビリティとセットで扱うことを前提としている
© KAKEHASHI Inc. https://dora.dev/research/ Four Keysでは見ていないもの
© KAKEHASHI Inc. SPACE • Satisfaction and well-being • Performance
• Activity • Communication and collaboration • Efficiency and flow 開発生産性を多面的に評価するためのフレームワーク 5つのディメンションから複数選択しメトリクスを取得することを推奨している
© KAKEHASHI Inc. SPACEはFour Keysを補完してくれる Deployment frequency Change lead time
Change fail rate Time to restore service Satisfaction and well being Performance Activity Communication and collaboration Efficiency and flow ※マッピングは個人の見解によるものです
© KAKEHASHI Inc. 僕たちのチームが計測しているもの Deployment frequency Change lead time Change
fail rate Time to restore service Satisfaction and well being FOUR KEYS SPACE
© KAKEHASHI Inc. https://dora.dev/research/ 組織パフォーマンスに影響する指標を見ている
© KAKEHASHI Inc. Four Keys+ウェルビーイング指標を計測 Findy Team+ Wevox
© KAKEHASHI Inc. 指標からは様々なことがわかる Findy Team+ Wevox 3月頃と比べて5月以降に デプロイ数の減少が みられる
5月に少し低下している
© KAKEHASHI Inc. けれど、測ってるけど、あえて見ない Findy Team+ Wevox
© KAKEHASHI Inc. チームは「なりたい姿」に集中 • プロダクトの小さな変更をすばやくたくさん届けたい • 顧客のニーズなど外部の変化にすばやく対応したい Findy Team+
Wevox
© KAKEHASHI Inc. その結果として現れる指標は観測する • プロダクトの小さな変更をすばやくたくさん届けたい • 顧客のニーズなど外部の変化にすばやく対応したい Findy Team+
Wevox
© KAKEHASHI Inc. たとえば、この事象をどう見るか Findy Team+ Wevox 3月頃と比べて5月以降に デプロイ数の減少が みられる
5月に少し低下している
© KAKEHASHI Inc. 開発生産性指標 チームを取り巻く環境 新しいチャレンジがあるか 変化を起こす外部要因 変化を起こす内部要因 チームの取り組み 自分たちのコミットメント
開発生産性指標は変数が多い
© KAKEHASHI Inc. 開発生産性指標 チームを取り巻く環境 新しいチャレンジがあるか 変化を起こす外部要因 変化を起こす内部要因 チームの取り組み 自分たちのコミットメント
指標と各変数を照合する 指標の変動と変数を観察し、変化が内側からのものなのか外部要因のものなのか判 断することができる
© KAKEHASHI Inc. デプロイ頻度減少を読み解く Findy Team+ 3月頃と比べて5月以降に デプロイ数の減少が みられる 4月から、他のチームと連携した開発を
進めている。 チームが裁量をもって開発-デプロイまで 行っていたそれまでとは異なるフロー。 そのためデプロイ頻度が減少。 (想定通り)
© KAKEHASHI Inc. エンゲージメント減少を読み解く Wevox 5月に少し低下している 開発対象プロダクトの変更など 様々な要因で減少。(想定通り)
© KAKEHASHI Inc. Pivot ゴールに向かう途中、 違う道を目指すべきだと 気づくことがある
© KAKEHASHI Inc. チームはゴールAを目指していた チーム ゴールA
© KAKEHASHI Inc. チームは方向転換することになる チーム ゴールA ゴールB
© KAKEHASHI Inc. 僕たちは、方向転換で数値が下がると予測していた Findy Team+ Wevox 3月頃と比べて5月以降に デプロイ数の減少が みられる
5月に少し低下している
© KAKEHASHI Inc. 直接数値をみると減速時に不安になる Findy Team+ Wevox
© KAKEHASHI Inc. 方向転換したくない気持ちが生まれる チーム ゴールA ゴールB
© KAKEHASHI Inc. もしある瞬間に指標が低下していると 開発生産性指標が低下
© KAKEHASHI Inc. すぐ対処したくなってしまう なんとか せな!
© KAKEHASHI Inc. もっと長い目で観察して判断したい ここ最近は こういう傾向か
© KAKEHASHI Inc. だから、測ってるけど、あえて見ない Findy Team+ Wevox
僕たちのチームはこうしている。 でも、常にそれが最適解でもない。
© KAKEHASHI Inc. https://dora.dev/research/ 明確な課題があるなら指標を追いかけたい
© KAKEHASHI Inc. 以前の現場でやりたかったこと • ユーザーの声をスピーディにプロダクトに反映したい • そのため2週間(10営業日)ごとにリリースしたい
© KAKEHASHI Inc. TOBEとASISのギャップ • ユーザーの声をスピーディにプロダクトに反映したい • そのため2週間(10営業日)ごとにリリースしたい • 開発から開始までのリードタイムが31営業日
© KAKEHASHI Inc. https://dora.dev/research/ リードタイムを短くしたい!
© KAKEHASHI Inc. バリューストリームマッピング(VSM)を実施 1. 対象を決定する 2. 対象となる開発サイクルの 概要を確認する 3.
全員でプロセスを書く 4. 手戻り率を書く 5. プロセスをグルーピングす る 6. ムダにマークをつける 7. 改善案を検討する 製品やサービスの価値を生み出す過程(バリューストリーム)を可視化する手法 PRD作成 設計 開発 開発者 テスト 受け入れ テスト mainに マージ リリース ユーザー 手順が煩雑 ミスによる手戻り 属人化 ミスによる手戻り
© KAKEHASHI Inc. https://dora.dev/research/ テストまわりの課題にフォーカスして改善
© KAKEHASHI Inc. ムダをなくすためのペインキラー作戦 Validation Velification ユーザーが満足する価値提供が できているかの検査 自分たちが意図した通りに開発 できているかの検査
fabricでの 一括実行 Jenkinsで ビルド時に 自動実行
© KAKEHASHI Inc. https://dora.dev/research/ 自分たちでどう改善するか選択していった
© KAKEHASHI Inc. TOBEとASISのギャップを埋めた • ユーザーの声をスピーディにプロダクトに反映したい • そのため2週間(10営業日)ごとにリリースしたい • 開発から開始までのリードタイムが31営業日
• 開発から開始までのリードタイムが8.5営業日
© KAKEHASHI Inc. (リードタイムが短縮した結果を見て) 「実際に改善したっていうのも あるけれど、自分たちがこのス ピードで開発できるって自信持 てたのが大きいですね」 今でも覚えている、メンバーの言葉
© KAKEHASHI Inc. https://dora.dev/research/ 結果的にWell-beingにも繋がっていた
© KAKEHASHI Inc. https://dora.dev/research/ このときもFour Keys起点ではなかった 課題が先にあり、その課題解決を示す指標としてChange lead timeがあった
© KAKEHASHI Inc. 理想形とのギャップを見て、指標はその後 チームの 理想形 チームの 現在形 ギャップ ゴールに
集中 ない ギャップ を分析 VSMなどで 現状を分析 指標を 設定 理想形に近づいていることを 示す指標を設定 カイゼン を実施
まとめます
© KAKEHASHI Inc. Four Keysはとても便利な指標 https://dora.dev/research/
© KAKEHASHI Inc. SPACEはFour Keysにないものを補完 • Satisfaction and well-being •
Performance • Activity • Communication and collaboration • Efficiency and flow
© KAKEHASHI Inc. ありたい姿を目指し僕らが測っているもの Deployment frequency Change lead time Change
fail rate Time to restore service Satisfaction and well being FOUR KEYS SPACE
© KAKEHASHI Inc. 大事なのは「なりたい姿」に集中すること • プロダクトの小さな変更をすばやくたくさん届けたい • 顧客のニーズなど外部の変化にすばやく対応したい Findy Team+
Wevox
© KAKEHASHI Inc. カケハシの技術に関連する情報を 発信しています。 𝕏 @kakehashi_dev 是⾮フォローしてください! ありがとうございました!!