1. 価値創造と開発生産性 2024/6/28 株式会社アトラクタ 吉羽 龍太郎
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー ▸ X(Twitter): @ryuzee / https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. アトラクタのアジャイルコーチングで 持続的に成果を出し続けるアジャイルチームを作る 「あなたのゴールは、他人から押し付けられるアジャイルの行動規範に依存するのではなく、 自分たちで考えることのできる、生産的なアジャイルチームを育てることです」 書籍『アジャイルコーチング』（Rachel Davies、Liz Sedley 著、永瀬美穂、角征典 訳、オーム社、2017） なぜアジャイル開発では「コーチ」なのか 変化に気づき、対応するを養う 顧客志向の目的と行動様式を獲得する コーチの経験と知見の力を借りた素早い立ち上がり
5. ゲームに勝つのは、フィ ールドに集中する選手 であって、スコアボード に釘付けになっている選 手ではない ウォーレン・バフェット
6. 価値創造と開発生産性 プロダクトマネージャーやエンジニアリングマネージャーの重要なつとめ ▸ プロダクトチームや開発チームがゲームに勝てるようにする ▸ プロダクトチームや開発チームが「スコアボード」ではなく「フィールド」に集中できるようにする 6
7. 価値創造と開発生産性 「開発生産性」という言葉はなぜこんなに流行しているのだろうか？ ▸ 高額の投資に見合っているかどうかを明らかにしたい？（経営者や幹部） ▸ 自分たちの存在意義を証明したい？（エンジニアやエンジニアリングマネージャー） ▸ 開発者の従業員満足度を向上したい？（エンジニアリングマネージャー） ▸ エンジニアの採用は難しいがやりたいことがたくさんある？（プロダクトマネージャー） ▸ 流行が流行を呼んでいる？ ▸ …… ▸ ほかにも色々ありそう ▸ 正直なところ、いろいろなところですれ違いがある気がする…… 7
8. 価値創造と開発生産性 「生産性」とは何か？ ▸ 生産性 = 産出 ÷ 投入 ▸ つまり「数字」で表せる ▸ 生産性は大きく2つに分けられる ▸ 物的生産性……生産したものの数や量を元にしたもの ▸ 付加価値生産性……生産したものが生み出した付加価値（金銭など）を元にしたもの ▸ ひとことで「生産性」というと誤解を招く 8
9. 価値創造と開発生産性 9 「開発生産性」とは何のことなのかという疑問 ▸ A. 「チームが所定の期間内で作れるモノの量」（つまり物的生産性。効率） ▸ B. 「チームが所定の期間内で生み出せる価値の量」（つまり付加価値生産性。効果） ▸ どっちなのだろうか？両方なのだろうか？ ▸ それとも会話の文脈（コンテキスト）によるのだろうか？ ▸ 海外だとDeveloper Productivity（開発者生産性？）という単語が主流に見えるが、開発生産性と開発 者生産性は違うのだろうか？ ▸ 有名な指標をもとにいろいろ考えてみよう
10. 価値創造と開発生産性 「開発生産性」の文脈でよく出てくる指標 ▸ Four Keys ▸ SPACEフレームワーク ▸ 「Yes, you can measure software developer productivity」（McKinsey） 10
11. 価値創造と開発生産性 11 Four Keys ▸ DORAが「開発組織のパフォーマンス」を計測する尺度として提唱したもの。現在は5つめの「信頼性」 が追加されている ▸ デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 ▸ 変更のリードタイム - commitから本番環境稼働までの所要時間 ▸ 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） ▸ サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 ▸ これを見ると「デリバリー」に焦点が当てられていることがわかる 出典: https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
12. 価値創造と開発生産性 Four Keysは「生産性」ではなく「パフォーマンス」と言っている 出典: 『LeanとDevOpsの科学』 Nicole Forsgren Ph.D., Jez Humble, Gene Kim (著), 武舎広幸, 武舎るみ (訳) 2018 p.18 12
13. 価値創造と開発生産性 13 SPACEフレームワーク ▸ 『LeanとDevOpsの科学』の著者の1人Nicole Forsgren氏らによる論文で公表 ▸ 「開発者の生産性」（生産性と言っている）を計測する上で、5つのカテゴリから複数のメトリクスを選ぶ ことを提唱している ▸ Satisfaction ▸ Performance ▸ Activity ▸ Communication and Collaboration ▸ E ciency and Flow 出典: Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. 2021. The SPACE of Developer ffi Productivity: There's more to it than you think. Queue 19, 1, Pages 10 (January-February 2021), 29 pages. https://doi.org/10.1145/3454122.3454124
14. 価値創造と開発生産性 SPACEの指標の例 14 出典: 同論文、日本語訳は吉羽による S 従業員満足度、自分のチームに他の人を推薦するか、必要なツールやリソースがある か、燃え尽きやストレスを抱えていないか…… P 信頼性、バグがないこと、サービスの健全性、顧客満足度、顧客増加やリテンション、機能 の利用状況、コスト削減…… A プルリクエストやコミット数、コードレビュー回数、ビルド/テスト/リリース回数、インフラ 利用率、インシデント回数、オンコール対応数、インシデント対応回数…… C ドキュメントや専門知識の見つけやすさ、統合の速さ、レビューの質、人同士の繋がりを 示すネットワーク指標、新メンバーのオンボーディングにかかる時間や体験の質 E 受け渡し回数、フローを維持する能力、割り込みの回数/タイミング/インパクト、作業時 間、付加価値時間、待ち時間…… ※複数のカテゴリから指標を選ぶこと、システムではなく感覚や感情に由来する指標を含めることを推奨している
15. 価値創造と開発生産性 SPACE - アクティビティ 15 出典: 同論文、日本語訳は吉羽による
16. 価値創造と開発生産性 SPACE - パフォーマンス 16 出典: 同論文、日本語訳は吉羽による
17. 価値創造と開発生産性 17 Yes, you can measure software developer productivity（McKinsey） ▸ ●がDORA/SPACEに追加されたもの ▸ Inner Loop（コーディング、ビルド、ユニッ トテスト）に使っている時間の割合 ▸ バックログに対する個人の貢献度スコア ▸ 同業他社との比較 ▸ タレントケイパビリティスコア ▸ 個人的にはまったくお勧めしない ▸ これは「開発者生産性」？ 出典: Yes, you can measure software developer productivity https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-youcan-measure-software-developer-productivity 2023
18. 価値創造と開発生産性 18 How Developers and Managers De ne and Trade Productivity for Quality ▸ マイクロソフトが社内で調査した結果をもとにした論文 ▸ 1 「開発者とマネー ャーは、生産的 あることの意味に対する考え方 一致していない」 を修正する、 ルリク ▸ 3.1.1 「開発者はマネー ャーよりも、生産性をアクティ ティ（コー を書く、 エストを発行する、一定期間内に完了したその他のタスク）の観点から考える傾向 強い」 ▸ 3.1.2 「マネー ャーは、自分たちのチームの生産性を、活動よりもむしろ フォーマンスや効率性の観 点から定義する傾向 強い」 プ が グ バ パ fi が ド ビ fi で ジ が ジ ジ 出典: Margaret-Anne Storey, Brian Houck, and Thomas Zimmermann. 2022. How developers and managers de ne and trade productivity for quality. In Proceedings of the 15th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE '22). Association for Computing Machinery, New York, NY, USA, 26–35. https://doi.org/10.1145/3528579.3529177, 日本語訳は吉羽による
19. 価値創造と開発生産性 19 ここまでの話を踏まえると？ ▸ 確固たる「開発生産性」の定義はなさそう ▸ 現場で取り組めるという点で「物的生産性」（アウトプット、物量、効率）を指して使っていることが多 い（これを「狭義の開発生産性」と呼ぶのが良さそう） ▸ 昨今の議論では「開発生産性」を分類して考えようという流れが見られる（広義の開発生産性） ▸ SPACEフレームワークでは「アウトカム」に注目 ▸ 「開発者生産性」と「開発生産性」もごっちゃに使われている ▸ 全体として「生産性」「開発生産性」「開発者生産性」「パフォーマンス」単語の使い方や意図がまちまち ▸ 「開発生産性」の意味するところの認識の違いが問題を生み出す
20. 価値創造と開発生産性 「開発生産性」の取り組みはどこから来るのか？ ▸ 「開発チームの外側から降ってきた」場合は要注意 20
21. 価値創造と開発生産性 どこかで見た景色な気がする ▸ 「アジャイル」 ▸ 「ビッグデータ」 ▸ 「MVP」 ▸ 「DX」 ▸ …… ▸ ふわっとした単語をふわっと使うと、意図しない結果になる ▸ 最初にやるべきことはわかりますよね？ 21
22. 価値創造と開発生産性 22 どちらのチームがよいでしょうか？ ▸ Four Keysの計測結果を2つ挙げます。計測結果AとBではどちらがよいチームですか？ 計測結果 デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間 A 15/week 0.5h 7% 2h B 5/week 4h 2% 0.5/h
23. 価値創造と開発生産性 そんなの比べられない ▸ この問いには重要な前提が抜けている ▸ 「同じチームが同じものを作っている」のかどうか ▸ 同一チームの変化を比較するのは容易（だし、そのために使うのは改善に役立つ） ▸ では比較対象のチームが違うと？ ▸ ゴミを高速に開発するチームと、価値あるものを普通の速度で作るチームはどちらがよいのか？ 23
24. 価値創造と開発生産性 24 どちらの時間の使い方がよいでしょうか？ ▸ 2つのチームの時間の使い方は以下のようになっています。どちらがよい時間の使い方ですか？ チーム 設計・開発・テストの時間の割合 それ以外の時間の割合 A 70% 30% B 50% 50%
25. 価値創造と開発生産性 25 そんなのわからない ▸ 単純な時間の使い方だけでは良し悪しはわからない ▸ 純粋な開発作業に使う時間が少ないのは悪いことなのか？ ▸ 計画づくり、教育や学習、仮説検証やインタビュー、実験、調査に時間を多く使うのは悪いことなのか？ ▸ 「スクラムだと、開発に使える時間が少なくなる」と言われることも ▸ 「開発時間が増えれば成果が出る」は単なる仮説
26. 価値創造と開発生産性 すべてはコンテキストによる ▸ 自分たちが置かれているコンテキストを明確にする ▸ 解決したい課題を明確にする ▸ 関係者の間でこれらについて合意する ▸ そのうえで意味のある数字を使う ▸ コンテキストが先、数字が後 26
27. 何も測らないよりは、何か測っ た方がいい？そんなことはな い！ 重要でないものの正確な 尺度よりも、価値あるもののあ いまいな尺度の方がいい ジム・ハイスミス 出典 https://jimhighsmith.com/productivity-measures-are-a-myth-held-over-from-the-1980s/
28. 測定できないものは管 理できない、と考えるの は誤りである。 これは代 償の大きい誤解だ エドワーズ・デミング
29. 価値創造と開発生産性 個人単位で計測すると？ ▸ 開発者生産性？ ▸ 個人の評価に使えば、誤ったインセンティブを与えることになる ▸ 会社は「個人の評価には使わない」と言うかもしれない（実際に使わないかもしれない） ▸ それでも、開発者は「評価に使われる」のではないかと疑う ▸ 結果的に正しい行動を阻害し、間違った行動を誘発する ▸ 実は組織単位でも同じことは起こる 29
30. 管理のために用いられ る測定はすべて信頼で きない グッドハートの法則
31. あなたが私をどう評価 するか教えてくれたら、 どう私が行動するか教 えましょう エリヤフ・ゴールドラット
32. 価値創造と開発生産性 32 ケント・ベックの事例 出典: Measuring developer productivity? A response to McKinsey https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity 2023、日本語訳は 吉羽による
33. 価値創造と開発生産性 つまり ▸ 計測できるからといって計測すべきとは限らない ▸ 計測できたからといって他と比較すべきとは限らない ▸ 数字は考える材料に過ぎない ▸ ただし数字を使うと論理的に見えてしまう ▸ 誤った行動を誘発する危険性がある 33
34. 価値創造と開発生産性 （参考） SMART ▸ 目標設定のときによく言われる ▸ Speci c 具体的 ▸ Measurable 計測可能 ▸ Achievable 達成可能 ▸ Related 関連性がある ▸ Time-bounded 期限がある ▸ Measurable（計測可能）ばかりが強調されるが、Related (関連性がある) が重要 fi ▸ 何と関連性があればいいのか？ 34
35. 価値創造と開発生産性 35 原点に立ち戻る ▸ 企業が存続するためには、顧客との価値交換システ ムを維持しなければいけない（ビルドトラップ本） ▸ つまり顧客のペインや仕事を解決する。それによっ て対価をもらう ▸ 価値創造と開発生産性のどちらが重要か？ ▸ 何よりもまず価値創造 $$$
36. 価値創造と開発生産性 まず計測すべきは「価値を創造できているか」 ▸ これがなければプロダクトは持続できない（会社も持続できないかもしれない） ▸ 「価値とは何か」は自分たちで定義しなければいけない ▸ プロダクトマネージャーなどが中心になって、ステークホルダーと協力して定義する ▸ それを全員に何度でも伝える ▸ 計画セッション、レビューセッション、報告会、定例会などなど ▸ うまくいっていない組織やチームほど、理解がバラバラ ▸ そして価値が提供できていることを示す指標を考える 36
37. 価値創造と開発生産性 37 価値を創造できていることを示す指標 ▸ プロダクトに関する指標（NSMなど）を見る ▸ ただしプロダクト関連の指標は遅行指標になりがちなので、もう少し工夫が必要 ▸ プロダクト開発を時間に区切る（後述） fl ▸ 組織やチームごとに別の指標を中心に据えると、個別最適化とそれに伴うコンフリクトが起こる Net ix Attention 月間N時間以上視聴しているユーザーの数 Spotify Attention 有償顧客の月間楽曲再生時間の合計 Amazon Transaction 1プライムユーザーあたりの購入金額の合計 Walmart Transaction 顧客の1回あたりの購入点数 Salesforce Productivity アカウントあたりの平均レコード作成数 Adobe Productivity エンゲージメントが高いサブスク購入者数
38. 価値創造と開発生産性 ゴールを定める ▸ ある期間内で何にフォーカスすべきかを決める（プロダクトチームとステークホルダーが協力） ▸ スクラムでいえば「プロダクトゴール」 ▸ シェイプアップメソッドでいえば「ベッティング」 ▸ ビルドトラップ本でいえば「オプション目標」 ▸ ゴールを達成できたのか、できていないのかを判断するための基準を決める（定量、定性） ▸ これは具体的な数字で示せることが多い（例: CVRとか離脱率とか応答速度とか） ▸ ゴールを達成できたかどうかは頻繁に検査する ▸ 1つのゴールを達成（または破棄）したら次のゴールに取り組む 38
39. 価値創造と開発生産性 ゴールの達成こそが目指すべきところ ▸ ゴールが達成できればタスクはすべて終わらなくてもいいし、アウトプットの量も気にしなくてよい ▸ 逆にゴールが達成できなければ、速さも量も関係ない ▸ まずは「効果」。それを達成したら「効率」 ▸ 効率ばかり重視したらビルドトラップ 39
40. 価値創造と開発生産性 「どれだけ作るか」より「何を作るか？(作らないか？)」「それはなぜか？」 ▸ 一般的に、ソフトウェアの機能を作るにはお金と時間がかかる ▸ それなりに不発率が高い ▸ 何を作るか（作らないか）を雑にすると、どんどんお金と時間がなくなる ▸ ソフトウェアは機能追加によってコストが非線形に増えやすい ▸ だんだん身動きが取れなくなっていく ▸ 不要な機能はガンガン消せ（「開発生産性」より重要） ▸ 「何を作るか」を検証する時間は、コードはあまり書かないかもしれない ▸ だが、それは本質に集中しているからなので問題ではない 40
41. 価値創造と開発生産性 「開発生産性」の前にPDMやEMがチームに問うべき質問 ▸ 自分たちのプロダクトのビジョンは何ですか？ ▸ 自分たちのプロダクトは顧客に価値を提供していますか？その根拠は何ですか？ ▸ 自分たちは今どんなゴールを目指していますか？それはビジョンや顧客とどう関係ありますか？ ▸ 自分たちがゴールを達成できたかどうかはどうすればわかりますか？ ▸ 自分たちが今やっている作業はゴールの達成にどう役立ちますか？ ▸ 自分たちがゴールを達成する上で問題は何ですか？どうしてそれが問題ですか？ ▸ これらを踏まえて今何を改善するとよさそうですか？ 41
42. 価値創造と開発生産性 「開発生産性」の前にPDMやEMがチームに問うべき質問 ▸ 自分たちのプロダクトのビジョンは何ですか？ ▸ 自分たちのプロダクトは顧客に価値を提供していますか？その根拠は何ですか？ ▸ 自分たちは今どんなゴールを目指していますか？それはビジョンや顧客とどう関係ありますか？ ▸ 自分たちがゴールを達成できたかどうかはどうすればわかりますか？ ▸ 自分たちが今やっている作業はゴールの達成にどう役立ちますか？ ▸ 自分たちがゴールを達成する上で問題は何ですか？どうしてそれが問題ですか？ ▸ これらを踏まえて今何を改善するとよさそうですか？ チームがこの質問に答えられたら、「効率」の話をしてもよい 42
43. 価値創造と開発生産性 プロダクトのフェーズと「開発生産性」の関心度合い（1） ▸ プロブレムソリューションフィット ▸ 課題が存在していること、ソリューションが課題を解決することを重視する ▸ 作業はプロトタイプとインタビューが中心 ▸ 開発生産性（狭義）は関心外 ▸ プロダクトマーケットフィット ▸ 検証可能なプロダクトを作る→市場に投入する→効果を計測する ▸ バーニングニーズの特定に注力する（顧客の火がついた問題を解決する） ▸ リテンションとチャーンレートを重視 ▸ ここで開発生産性（狭義）を気にしすぎるとビルドトラップ 43
44. 価値創造と開発生産性 プロダクトのフェーズと「開発生産性」の関心度合い（2） ▸ プロダクトの成長フェーズ（物的生産性が重視される時期） ▸ プロダクトが成功し始める。やりたいことはたくさんあるが人や時間が足りない ▸ 投資が大きくなるので妥当性が気になるし、ステークホルダーからも色々要求されやすい ▸ このタイミングは開発生産性（狭義・広義とも）が話題になりやすい ▸ まずは本当に解決したい問題を明らかにするところから！（いきなり「開発生産性」の話にしない） ▸ プロダクトの衰退フェーズ（新たに開発しても焼け石に水） ▸ 開発生産性（狭義・広義とも）は関心外 自分たちのプロダクトの状況を踏まえて「開発生産性」に取り組むのがよさそう 44
45. 価値創造と開発生産性 結論と提言 ▸ 「開発生産性」に関心を持つ理由も、「開発生産性」の定義もさまざま ▸ 重要なのはコンテキスト ▸ 数字だけで全てを表せるわけではない ▸ 個人単位や部門単位で定量化しても、所詮恣意的で余計な分断を生むだけ ▸ その努力をもっと本質的なところに ▸ 「開発生産性」に取り組む「目的」そのものを考えるべき ▸ 顧客に価値を届けなければビジネスは存続しないのだから、全員がそこを気にすべき ▸ 全員がビジネス上の成果を出すことにフォーカスする ▸ 「効果」が出てから「効率」を考える 45
