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
13k
なぜ僕たちは 開発生産性指標を見ていないのか / Our Strategy for Development Productivity Metrics
開発の生産性を高める新たな視点〜開発生産性フレームワークSPACE〜
での登壇資料です
KAKEHASHI
PRO
July 02, 2024
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
生成AIと余白 〜開発スピードが向上した今、何に向き合う?〜
kakehashi
PRO
0
52
開発チームが信頼性向上のためにできること
kakehashi
PRO
3
78
他言語経験者が知っておきたいTypeScriptのクラスの注意点
kakehashi
PRO
1
29
「外部仕様書をDevinくんにやってもらってみた」に関連した色々話
kakehashi
PRO
2
45
複数チームでの並行開発を改善する取り組み
kakehashi
PRO
1
41
産業的変化も組織的変化も乗り越えられるチームへの成長 〜チームの変化から見出す明るい未来〜
kakehashi
PRO
1
1.2k
自己管理型チームと個人のセルフマネジメント 〜モチベーション編〜
kakehashi
PRO
5
4.4k
なりたかった自分となりたい自分
kakehashi
PRO
2
790
そのアウトプットは世界とつながっている
kakehashi
PRO
2
260
Other Decks in Technology
See All in Technology
SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント
rvirus0817
0
320
20260208_第66回 コンピュータビジョン勉強会
keiichiito1978
0
180
15 years with Rails and DDD (AI Edition)
andrzejkrzywda
0
200
モダンUIでフルサーバーレスなAIエージェントをAmplifyとCDKでサクッとデプロイしよう
minorun365
4
220
生成AIを活用した音声文字起こしシステムの2つの構築パターンについて
miu_crescent
PRO
3
210
ブロックテーマ、WordPress でウェブサイトをつくるということ / 2026.02.07 Gifu WordPress Meetup
torounit
0
190
Red Hat OpenStack Services on OpenShift
tamemiya
0
120
Cosmos World Foundation Model Platform for Physical AI
takmin
0
940
Tebiki Engineering Team Deck
tebiki
0
24k
Codex 5.3 と Opus 4.6 にコーポレートサイトを作らせてみた / Codex 5.3 vs Opus 4.6
ama_ch
0
180
セキュリティについて学ぶ会 / 2026 01 25 Takamatsu WordPress Meetup
rocketmartue
1
310
Agile Leadership Summit Keynote 2026
m_seki
1
650
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.7k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.1k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
How STYLIGHT went responsive
nonsquared
100
6k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
110
Designing for humans not robots
tammielis
254
26k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
1.9k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
51k
Ruling the World: When Life Gets Gamed
codingconduct
0
140
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.6k
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 是⾮フォローしてください! ありがとうございました!!