『LeanとDevOpsの科学』をきちんと解読する〜Four Keys だけじゃ絶対もったいなくなる話〜

by Takeo Imai

Slide 1

Slide 1 text

『LeanとDevOpsの科学』をきちんと解読する〜Four Keys だけじゃ絶対もったいなくなる話〜ぼのたけ今井健男 2024.3.9 @スクラムフェス福岡

Slide 2

Slide 2 text

今井健男（ぼのたけ）フリーランスアジャイルコーチ • スクラム導⼊⽀援、プロダクトマネジメント⽀援、開発組織づくり⽀援 • 現在は主にログラスにてスクラムマスターソフトウェア⼯学研究者 • 以前、某電機メーカーの研究所にて企業研究 • 初の国際会議採択はとある指標の研究でした • 現在、国⽴情報学研究所にてスクラムの研究 2024/1/11 2

Slide 3

Slide 3 text

皆さんに質問です

Slide 4

Slide 4 text

Four Keys を導⼊していますか？

Slide 5

Slide 5 text

『LeanとDevOpsの科学』は読みましたか？はいと答えた⼈、

Slide 6

Slide 6 text

Four Keys利⽤者のうち、同書を読んだ⼈の割合はたった5% ぼのたけ⼼の中調べ（本気にしちゃだめよ）

Slide 7

Slide 7 text

Four Keys って何なのかよくわかってなくないですか？ていうか

Slide 8

Slide 8 text

「ツール⼊れてFour Keysを測ってみたけど、それからどうしていいのかわからない」街の声「ただのアウトプットの指標でしょ？何がそんなに嬉しいの？」「指標を計測することに慣れてない⼈が流⾏ってるからって⾶びついてる」

Slide 9

Slide 9 text

と思っていたら 2022年の DORAレポートによると、Four Keys を使った組織の分析がこの年は機能しなかった DevOps Research and Assessment (DORA) (2022). "State of DevOps 2022 Report". p. 13.

Slide 10

Slide 10 text

第1章の冒頭 DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. そして 2023年の DORA レポート

Slide 11

Slide 11 text

第1章の冒頭 DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. グッドハートの法則：指標を⽬標にすると、良い指標でなくなってしまうそして 2023年の DORA レポート

Slide 12

Slide 12 text

第1章続き DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. そして 2023年の DORA レポート

Slide 13

Slide 13 text

第1章続き DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. そして 2023年の DORA レポートしかし、そうした指標はチームを改善するための⼿段ではありません。このベースラインを基に、⼈、プロセス、技術のケイパビリティといった幅広い観点からチームの⼒を評価し、進歩を妨げている可能性のあるものを特定することが重要です。

Slide 14

Slide 14 text

第1章続き DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. そして 2023年の DORA レポートしかし、そうした指標はチームを改善するための⼿段ではない。このベースラインを基に、⼈、プロセス、そして技術のケイパビリティといった幅広い観点からチームの⼒を評価し、進歩を妨げている可能性のあるものを特定することが重要である。以降このページには、まるまる1ページを費やして「指標のダメな使い⽅」について解説が書かれている。そして毎年恒例の、Four Keys を使った組織の評価はこの年は表1枚が書かれたのみ。 2023年度のレポートは、Four Keysによって測れる「デリバリのパフォーマンス」を特別扱いせずより総合的な視点での分析・評価にシフトした。本家が「Four Keysから組織のパフォーマンスを評価する」のを⽌めてしまったようにも⾒える。

Slide 15

Slide 15 text

もしかして世界中でみんながFour Keysを「ハック」したために Four Keysの意義が失われつつある？ぼのたけ⼼の中の邪推

Slide 16

Slide 16 text

実にもったいないぼのたけ⼼の叫び

Slide 17

Slide 17 text

やっぱり Four Keysの恩恵を得たければ『LeanとDevOpsの科学』をみんなちゃんと読むべき既に読んでる⼈も、いま⼀度

Slide 18

Slide 18 text

ただ、あの本はイマイチ読みづらい 1. 研究者による研究レポートのような体裁を取っていて、とっつきにくい 2. ⽇本語版は、翻訳にいまいちイケてないところがある（後述）

Slide 19

Slide 19 text

この講演では、皆さんが『LeanとDevOpsの科学』を読むためのガイドを⽰しますということで、

Slide 20

Slide 20 text

皆さんに Four Keysの裏にある「こころ」をお伝えします本の内容の詳細には⽴ち⼊りません

Slide 21

Slide 21 text

ここで、皆さんにクイズです

Slide 22

Slide 22 text

この本のどこが⼀番重要だと思いますか？全部で320ページ、3部構成、17章あります

Slide 23

Slide 23 text

正解は付録の図A.1 です

Slide 24

Slide 24 text

これは、ソフトウェア開発組織がパフォーマンスを発揮するための理論モデルです

Slide 25

Slide 25 text

注）僕の RSGT2024での講演を聴かれた⽅向け要はこれのDevOps版 19 チームの効果性ステークホルダーへの関⼼反応性継続的改善チームの⾃律性マネジメントの⽀援チームの⼠気ステークホルダー満⾜度 2024/1/11 「A Theory of Scrum Team Effectiveness 〜『ゾンビスクラムサバイバルガイド』の裏側にある科学〜」より

Slide 26

Slide 26 text

そしてこれが最新版（DORA Core Model）

Slide 27

Slide 27 text

そしてこれが最新版（DORA Core Model）技術・プロセス・⽂化それぞれの側⾯でのケイパビリティ（チームの能⼒）デリバリのパフォーマンスと、その指標（いわゆる Four Keys) 組織のパフォーマンスとウェルビーイングからなる outcome

Slide 28

Slide 28 text

Four Keysのすごいところデリバリのパフォーマンスを⽰す4つの指標が、組織のパフォーマンスを意味するoutcomeと強い相関を持つことが学術的に実証されている（いた？）

Slide 29

Slide 29 text

Four Keysの気をつけないといけないところ Four Keys はこのモデルとともに効果が実証されたもので、このモデルを念頭に置かないと喧伝されているような効果は期待できない

Slide 30

Slide 30 text

推奨されるFour Keysの使い⽅（1）チームのケイパビリティを改善する

Slide 31

Slide 31 text

推奨されるFour Keysの使い⽅（2）改善できたかどうかをFour Keys経由で観測する

Slide 32

Slide 32 text

推奨されるFour Keysの使い⽅（3）そこまでやれば、組織のパフォーマンス（outcome）は上がると期待できる

Slide 33

Slide 33 text

推奨されるFour Keysの使い⽅継続利⽤編（1）継続的に計測し、変化がないかを観察する

Slide 34

Slide 34 text

推奨されるFour Keysの使い⽅継続利⽤編（2）変化があったら、何が原因かを考える

Slide 35

Slide 35 text

推奨されるFour Keysの使い⽅継続利⽤編（2）変化があったら、何が原因かを考えるこの過程をすっとばす⼈がとても多いが、めっちゃ⼤事。原因を探ってみると、その組織にとっては無視できるものだったり、むしろ良いことである場合もある。組織にとっては良いことのはずなのに、「Four Keysが悪くなる」というだけで潰してしまうようなことは絶対あってはならない。

Slide 36

Slide 36 text

推奨されるFour Keysの使い⽅継続利⽤編（3）課題が⾒つかったらがんばって改善する

Slide 37

Slide 37 text

推奨されるFour Keysの使い⽅継続利⽤編（4）改善できたかどうかを改めて観測する

Slide 38

Slide 38 text

Four Keysの気をつけないといけないところその2 Four Keys はウェルビーイング系 outcome との相関は直接持たない

Slide 39

Slide 39 text

最新のDORA Core modelは整理されていてわかりやすい⼀⽅、本の内容と微妙にずれている今の話を元に本の内容を説明したいが、

Slide 40

Slide 40 text

てことで、本のモデルを最新のDORA modelに近づけてみましたデザインセンスなさすぎで草変革型リーダーシップ継続的デリバリ Westrum 組織文化ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度組織のパフォーマンス営利組織非営利組織ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR 技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック

Slide 41

Slide 41 text

Slide 42

Slide 42 text

第1部はこのモデル上にマッピングできる変革型リーダーシップ継続的デリバリ Westrum 組織文化ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度組織のパフォーマンス営利組織非営利組織ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR 技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック 2章 2章 3章 4章 4, 5. 6章 (+13章) 9章 7章 8章 10章 11章 ※ 1章は「ケイパビリティとは何か」の話

Slide 43

Slide 43 text

ここからは実際に本を読む時のための補⾜です

Slide 44

Slide 44 text

3章：組織⽂化から、デリバリのパフォーマンスと組織のパフォーマンスを予測できる変革型リーダーシップ継続的デリバリ技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック Westrum 組織文化ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度組織のパフォーマンス営利組織非営利組織ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR

Slide 45

Slide 45 text

Westrum モデル組織⽂化を３つのタイプに分類したもので、この分類で組織のパフォーマンスの良し悪しが予測できるとされている不健全な（権⼒志向の）組織官僚的な（ルール志向の）組織創造的な（パフォーマンス志向の）組織協⼒態勢が悪いほどほどの協⼒態勢協⼒態勢が確⽴情報伝達を阻⽌情報伝達を軽視情報伝達に熟達責任逃れ責任範囲が狭いリスクを共有仲介を阻⽌仲介を許容仲介を奨励失敗は責任転嫁へ失敗は裁きへ失敗は調査へ新規性をつぶす新規性を問題化新規性を実装

Slide 46

Slide 46 text

11章：変⾰型リーダーシップは、技術とリーンの複数のケイパビリティ向上に効果あり継続的デリバリ Westrum 組織文化ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック組織のパフォーマンス営利組織非営利組織ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR 変革型リーダーシップ技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験

Slide 47

Slide 47 text

変⾰型リーダーシップとは？組織のメンバーに信念や価値観を⽰してメンバーから尊敬の念や信頼を引き出し、⾏動変容を促すようなリーダーシップのこと ⇔ 取引型リーダーシップ：報酬や懲罰を使ってメンバーを動かそうとするリーダーシップ本書では以下の5つの要因で定義している 1. ビジョン形成⼒ 2. ⼼に響くコミュニケーション能⼒ 3. 知的刺激 4. ⽀援的リーダーシップ 5. 個⼈に対する評価

Slide 48

Slide 48 text

第2部はこの研究で使われている調査⽅法について書かれています「アンケート調査って本当に頼りになるの？」という問いに対し、「むしろ⾃動計測したデータだけでは調査が困難」としている（第14章）

Slide 49

Slide 49 text

ForsgrenとKerstenがACMの学会誌に寄稿した、実務も意識して書かれた記事。無料公開されている。 survey data（アンケート調査によるデータ）と system data（インフラ等から⾃動計測できるデータ）は両⽅必要としている（実務でも）。 • ⼯場のラインから様々な指標は system data で計測できるが、「新たに導⼊したロボットが作業員に過度な負担をかけている」みたいな話は survey dataでないとわからない • ⼩さい会社なら「じゃあまずMTTRを測るところから」といった始め⽅ができるが、⼤企業では system dataを最初から統⼀的に測るのは困難。survey data から始めるべき • etc.

Slide 50

Slide 50 text

最後に：⽇本語版の翻訳がイマイチな件について • いくつかのDevOps⽤語、アジャイル⽤語が⼀般的な表現に置き換えられていたり、訳出されていなかったりする • “value stream”, “kanban”, “batch” などなど • けっこう訳に揺れがある • “Lean Practices” など • 「修正」「修正作業」と訳されているところが、原⽂では “rework”（⼿戻り） • 本講演資料はこちらで作成しました

Slide 51

Slide 51 text

みんな『LeanとDevOpsの科学』を読もう！無理やりなまとめ

Slide 52

Slide 52 text

Four Keys（に限らず指標⼀般）はあくまで観測のためのもので、改善の道具ではない。数値が悪くなったら、まず原因を考え、必要ならその原因のほうを改善する。 Four Keys そのものを改善⽬標にしてはならない。最後に、念押し

Slide 53

Slide 53 text

おしまい

Slide 54

Slide 54 text

以下資料第⼀部各章の紹介

Slide 55

Slide 55 text

2章：デリバリのパフォーマンスと組織のパフォーマンス（収益性、市場占有率など）とで強い相関が確認できた変革型リーダーシップ継続的デリバリ Westrum 組織文化ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック組織のパフォーマンス営利組織非営利組織ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR

Slide 56

Slide 56 text

4, 5章：継続的デリバリとかアーキテクチャとか変革型リーダーシップリーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック組織のパフォーマンス営利組織非営利組織 Westrum 組織文化ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR 継続的デリバリ技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知ウェルビーイングバーンアウトの軽減デプロイの負荷軽減帰属意識職務満足度手戻りの減少

Slide 57

Slide 57 text

6章：セキュリティのシフトレフト変革型リーダーシップ継続的デリバリ Westrum 組織文化ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック組織のパフォーマンス営利組織非営利組織ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR 技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知

Slide 58

Slide 58 text

この本でのリーンのプラクティス＝リーンマネジメント＋リーン製品開発（7, 8章）変革型リーダーシップ継続的デリバリ技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知 Westrum 組織文化ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度組織のパフォーマンス営利組織非営利組織ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック

Slide 59

Slide 59 text

7章：リーンマネジメントは組織⽂化、デリバリのパフォーマンスの向上、およびバーンアウトの軽減に効果あり変革型リーダーシップ継続的デリバリ技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知組織のパフォーマンス営利組織非営利組織リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR Westrum 組織文化リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック

Slide 60

Slide 60 text

8章：リーン製品開発は組織⽂化、デリバリのパフォーマンス、組織のパフォーマンス向上やバーンアウトの軽減に効果あり変革型リーダーシップ継続的デリバリ技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバック組織のパフォーマンス営利組織非営利組織ウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度 Westrum 組織文化リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR

Slide 61

Slide 61 text

9章：継続的デリバリとリーンのプラクティスは、デプロイ関連の負荷やバーンアウトの軽減に効果あり変革型リーダーシップ Westrum 組織文化組織のパフォーマンス営利組織非営利組織技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR 継続的デリバリリーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験リーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバックウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度

Slide 62

Slide 62 text

10章：継続的デリバリとリーンのプラクティスは、メンバーの帰属意識や職務満⾜度を向上させ、それによって組織のパフォーマンスを上げる効果がある変革型リーダーシップ Westrum 組織文化技術系ケイパビリティテスト自動化デプロイ自動化トランクベース開発セキュリティのシフトレフト疎結合なアーキテクチャ権限を付与されたチーム継続的インテグレーションバージョン管理テストデータの管理モニタリングプロアクティブな通知ソフトウェアデリバリのパフォーマンス変更のリードタイムデプロイ頻度変更失敗率 MTTR リーン製品開発小さいバッチでの作業作業フローの可視化顧客フィードバックの収集と活用チームによる実験継続的デリバリリーンマネジメント WIP制限軽量な変更の承認可視化本番環境からのフィードバックウェルビーイングバーンアウトの軽減デプロイの負荷軽減手戻りの減少帰属意識職務満足度組織のパフォーマンス営利組織非営利組織

Slide 63

Slide 63 text

その他、おまけ

Slide 64

Slide 64 text

2023年版 DORA レポートにおけるチームの 4分類 • User-centric • ユーザーのニーズに重きを置く • 組織のパフォーマンスは最⾼レベル • デリバリのパフォーマンスも運⽤のパフォーマンスも⾼い • でもBalancedよりはバーンアウトの傾向が⾼い • Feature-driven • 機能（feature）のリリースに重きを置く • チーム/組織のパフォーマンスは最低 • ユーザー中⼼性や運⽤のパフォーマンスは低い • バーンアウトの傾向が最も⾼く、職務満⾜度は最も低い • Developing • PMFをまだ終えておらず、技術のケイパビリティもまだ向上の途上 • たいてい組織の規模が⼩さい • デリバリのパフォーマンス、運⽤のパフォーマンスとも低め • ⾃動化しきれていない • バーンアウトの傾向が⾼め • Balanced • チーム/組織のパフォーマンスもそれなりに⾼く、職務満⾜度もそれなりに⾼い • バーンアウトの傾向が最も低い • デリバリのパフォーマンス、運⽤のパフォーマンス、ユーザー中⼼性それぞれがバランス良く⾼い

Slide 65

Slide 65 text

第3部は改善の事例紹介ですオランダのING社が Spotifyモデル＋「オーベヤ」（⼤部屋⽅式）を導⼊した話が載っています