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

スクラムフェス福岡2024での講演資料です。

---
皆さん、職場でFour Keysを導入していますか？

Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？

あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いのですが、そのうち、出典である『LeanとDevOpsの科学』をきちんと読んだ人はかなり少ないようです。

そして、ここで敢えて強めの主張をするのですが 『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。 Forsgrenらは徹底した研究の結果として4つのメトリクス（指標）を見出すのですが、その裏には彼女らの沢山の思いが詰まっています。その思いや彼女らの思考を理解し、彼女らの考えをきちんとトレースして始めて、Four Keysは意味を持ちます。

そして『LeanとDevOpsの科学』をちゃんと読めば、ただツールを導入してFour Keysだけ測っても何の意味もないことがわかります。 Four Keysが生まれた背景にこそ、この研究の真の価値があるのです。
また、彼女らの研究結果にはFour Keys以外にも沢山の知見が含まれていて、それらを知らないのはとてももったいないことです。

Forsgrenらがやったのは、ソフトウェア開発の何がIT企業のパフォーマンスに効果があるかを科学的手法を使って徹底的に調べ上げることでした。そして彼女らが発見した、DevOps組織のパフォーマンスを上げるために必要な24（現在は27。4どころではない！）のケイパビリティには、継続的デリバリは当然のこと、組織文化やリーダーシップ、リーンといったものも含まれていて、それらに対する研究結果の多くはスクラム／アジャイルの実践の上でもとても参考になるものです。（実際、書籍の中にアジャイルへの言及もあります。）

このセッションでは、Four Keysやそれらの計測には敢えて焦点を当てず、背後の考え方をきちんと解説することを目指します。また付随して、現在・過去とソフトウェアメトリクスの研究・実践をしてきた研究者の立場から、Forsgrenが学会誌で過去に発表している記事なども参考に、こうした（Four Keysに限らない）チームのパフォーマンスを測るにはどうしたらいいか、の一般的な解説も含めていきます。

結論としては「『LeanとDevOpsの科学』をちゃんと読もう！」なのですが、なにぶん研究者が書いた書籍なので少し堅苦しいところも多く、慣れない人には読みづらい本かもしれません。そういった点を、同じ研究者の立場からなるべく平易に紐解き、皆さんが『LeanとDevOpsの科学』を絶対に読みたくなる状態を目指します。

Transcript

1. 『LeanとDevOpsの科学』 をきちんと解読する 〜Four Keys だけじゃ 絶対もったいなくなる話〜 ぼのたけ 今井健男 2024.3.9 @スクラムフェス福岡
2. 今井健男（ぼのたけ） フリーランスアジャイルコーチ • スクラム導⼊⽀援、プロダクトマネジメント ⽀援、開発組織づくり⽀援 • 現在は主に ログラス にてスクラムマスター ソフトウェア⼯学研究者 • 以前、某電機メーカーの研究所にて企業研究 • 初の国際会議採択はとある指標の研究でした • 現在、国⽴情報学研究所 にてスクラムの研究 2024/1/11 2
3. 皆さんに質問です
4. Four Keys を導⼊して いますか？
5. 『LeanとDevOpsの科学』 は読みましたか？ はいと答えた⼈、
6. Four Keys利⽤者のうち、 同書を読んだ⼈の割合は たった5% ぼのたけ ⼼の中調べ（本気にしちゃだめよ）
7. Four Keys って何なのか よくわかって なくないですか？ ていうか
8. 「ツール⼊れてFour Keysを測ってみたけど、 それからどうしていいのかわからない」 街の声 「ただのアウトプットの指標でしょ？ 何がそんなに嬉しいの？」 「指標を計測することに慣れてない⼈が 流⾏ってるからって⾶びついてる」
9. と思っていたら 2022年の DORAレポートによると、Four Keys を使った組織の分析が この年は機能しなかった DevOps Research and Assessment (DORA) (2022). "State of DevOps 2022 Report". p. 13.
10. 第1章の冒頭 DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. そして 2023年の DORA レポート
11. 第1章の冒頭 DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. グッドハートの法則： 指標を⽬標にすると、 良い指標でなくなって しまう そして 2023年の DORA レポート
12. 第1章 続き DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. そして 2023年の DORA レポート
13. 第1章 続き DevOps Research and Assessment (DORA) (2023). "State of DevOps 2023 Report". p. 10. そして 2023年の DORA レポート しかし、そうした指標はチー ムを改善するための⼿段では ありません。このベースライ ンを基に、⼈、プロセス、技 術のケイパビリティといった 幅広い観点からチームの⼒を 評価し、進歩を妨げている可 能性のあるものを特定するこ とが重要です。
14. 第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から組織のパフォーマンスを評価する」 のを⽌めてしまったようにも⾒える。
15. もしかして 世界中でみんながFour Keysを 「ハック」したために Four Keysの意義が 失われつつある？ ぼのたけ ⼼の中の邪推
16. 実にもったいない ぼのたけ ⼼の叫び
17. やっぱり Four Keysの恩恵を得たければ 『LeanとDevOpsの科学』を みんなちゃんと読むべき 既に読んでる⼈も、いま⼀度
18. ただ、あの本はイマイチ読みづらい 1. 研究者による研究レポートのような体裁を取っていて、 とっつきにくい 2. ⽇本語版は、翻訳にいまいちイケてないところがある （後述）
19. この講演では、皆さんが 『LeanとDevOpsの科学』 を読むための ガイドを⽰します ということで、
20. 皆さんに Four Keysの裏にある 「こころ」 をお伝えします 本の内容の詳細には⽴ち⼊りません
21. ここで、 皆さんにクイズ です
22. この本のどこが ⼀番重要だと思 いますか？ 全部で320ページ、3部構成、17章あります
23. 正解は 付録の図A.1 です
24. これは、ソフトウェア開発組織がパフォーマン スを発揮するための理論モデルです
25. 注）僕の RSGT2024での 講演を聴かれ た⽅向け 要はこれのDevOps版 19 チームの 効果性 ステーク ホルダー への関⼼ 反応性 継続的改 善 チームの ⾃律性 マネジメン トの⽀援 チーム の⼠気 ステーク ホルダー 満⾜度 2024/1/11 「A Theory of Scrum Team Effectiveness 〜『ゾンビスクラムサバイバル ガイド』の裏側にある科学〜」より
26. そしてこれが最新版（DORA Core Model）
27. そしてこれが最新版（DORA Core Model） 技術・プロセス・⽂ 化それぞれの側⾯で のケイパビリティ （チームの能⼒） デリバリのパフォーマ ンスと、その指標 （いわゆる Four Keys) 組織のパフォーマ ンスとウェルビー イングからなる outcome
28. Four Keysのすごいところ デリバリのパフォーマンスを⽰す4つの指標が、組織の パフォーマンスを意味するoutcomeと強い相関を持つこと が学術的に実証されている（いた？）
29. Four Keysの気をつけないといけないところ Four Keys はこのモデルとともに効果が 実証されたもので、 このモデルを念頭に置かないと 喧伝されているような効果は期待できない
30. 推奨されるFour Keysの使い⽅（1） チームのケイパビリティを改善する
31. 推奨されるFour Keysの使い⽅（2） 改善できたかどうかをFour Keys経由で観測する
32. 推奨されるFour Keysの使い⽅（3） そこまでやれば、組織のパフォーマンス（outcome）は上がる と期待できる
33. 推奨されるFour Keysの使い⽅ 継続利⽤編（1） 継続的に計測し、変化がないかを観察する
34. 推奨されるFour Keysの使い⽅ 継続利⽤編（2） 変化があったら、何が原因かを考える
35. 推奨されるFour Keysの使い⽅ 継続利⽤編（2） 変化があったら、何が原因かを考える この過程をすっとばす⼈がとても多いが、 めっちゃ⼤事。 原因を探ってみると、 その組織にとっては無視できるものだったり、 むしろ良いことである場合もある。 組織にとっては良いことのはずなのに、 「Four Keysが悪くなる」というだけで 潰してしまうようなことは絶対あってはならない。
36. 推奨されるFour Keysの使い⽅ 継続利⽤編（3） 課題が⾒つかったらがんばって改善する
37. 推奨されるFour Keysの使い⽅ 継続利⽤編（4） 改善できたかどうかを改めて観測する
38. Four Keysの気をつけないといけないところ その2 Four Keys は ウェルビーイング系 outcome との相関は 直接持たない
39. 最新のDORA Core modelは 整理されていてわかりやすい ⼀⽅、本の内容と 微妙にずれている 今の話を元に本の内容を説明したいが、
40. てことで、本のモデルを最新のDORA modelに近 づけてみました デザインセンスなさすぎで草 変革型リー ダーシップ 継続的 デリバリ Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック
41. てことで、本のモデルを最新のDORA modelに近 づけてみました デザインセンスなさすぎで草 変革型リー ダーシップ 継続的 デリバリ Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック デリバリの パフォーマンス (with Four Keys) Outcome： 組織のパフォーマンス と ウェルビーイング リーンと DevOps 組織⽂化 リーダーシップ
42. 第1部はこのモデル上にマッピングできる 変革型リー ダーシップ 継続的 デリバリ Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック 2章 2章 3章 4章 4, 5. 6章 (+13章) 9章 7章 8章 10章 11章 ※ 1章は「ケイパビリティとは何か」の話
43. ここからは 実際に本を読む時のための 補⾜です
44. 3章：組織⽂化から、デリバリのパフォーマンスと組織のパ フォーマンスを予測できる 変革型リー ダーシップ 継続的 デリバリ 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR
45. Westrum モデル 組織⽂化を３つのタイプに分 類したもので、この分類で組 織のパフォーマンスの良し悪 しが予測できるとされている 不健全な （権⼒志向の） 組織 官僚的な （ルール志向の） 組織 創造的な （パフォーマンス 志向の）組織 協⼒態勢が悪い ほどほどの協⼒ 態勢 協⼒態勢が確⽴ 情報伝達を阻⽌ 情報伝達を軽視 情報伝達に熟達 責任逃れ 責任範囲が狭い リスクを共有 仲介を阻⽌ 仲介を許容 仲介を奨励 失敗は責任転嫁 へ 失敗は裁きへ 失敗は調査へ 新規性をつぶす 新規性を問題化 新規性を実装
46. 11章：変⾰型リーダーシップは、技術とリーンの複数のケイパ ビリティ向上に効果あり 継続的 デリバリ Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR 変革型リー ダーシップ 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験
47. 変⾰型 リーダー シップと は？ 組織のメンバーに信念や価値観を⽰してメン バーから尊敬の念や信頼を引き出し、⾏動変容 を促すようなリーダーシップ のこと ⇔ 取引型リーダーシップ：報酬や懲罰を使って メンバーを動かそうとするリーダーシップ 本書では以下の5つの要因で定義している 1. ビジョン形成⼒ 2. ⼼に響くコミュニケーション能⼒ 3. 知的刺激 4. ⽀援的リーダーシップ 5. 個⼈に対する評価
48. 第2部はこの研究で使われ ている調査⽅法について 書かれています 「アンケート調査って本当に頼り になるの？」という問いに対し、 「むしろ⾃動計測したデータだけ では調査が困難」としている （第14章）
49. ForsgrenとKerstenがACMの学会誌に寄稿した、実務 も意識して書かれた記事。無料公開されている。 survey data（アンケート調査によるデータ） と system data（インフラ等から⾃動計測できるデータ） は両⽅必要 としている（実務でも）。 • ⼯場のラインから様々な指標は system data で計測できるが、「新たに導⼊した ロボットが作業員に過度な負担をかけて いる」みたいな話は survey dataでないと わからない • ⼩さい会社なら「じゃあまずMTTRを測 るところから」といった始め⽅ができる が、⼤企業では system dataを最初から 統⼀的に測るのは困難。survey data から 始めるべき • etc.
50. 最後に： ⽇本語版の翻訳がイマイチな件について • いくつかのDevOps⽤語、アジャイル⽤語が⼀般的な表現に置 き換えられていたり、訳出されていなかったりする • “value stream”, “kanban”, “batch” などなど • けっこう訳に揺れがある • “Lean Practices” など • 「修正」「修正作業」と訳されているところが、原⽂では “rework”（⼿戻り） • 本講演資料はこちらで作成しました
51. みんな 『LeanとDevOpsの科学』 を読もう！ 無理やりなまとめ
52. Four Keys（に限らず指標⼀般）はあくまで観測 のためのもので、改善の道具ではない。 数値が悪くなったら、まず原因を考え、必要なら その原因のほうを改善する。 Four Keys そのものを改善⽬標にしてはならない。 最後に、念押し
53. おしまい
54. 以下資料 第⼀部 各章の紹介
55. 2章：デリバリのパフォーマンスと組織のパフォーマンス （収益性、市場占有率など）とで強い相関が確認できた 変革型リー ダーシップ 継続的 デリバリ Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR
56. 4, 5章：継続的デリバリとかアーキテクチャとか 変革型リー ダーシップ リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック 組織の パフォーマンス 営利組織 非営利組織 Westrum 組織文化 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR 継続的 デリバリ 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 帰属意識 職務満足度 手戻りの減少
57. 6章：セキュリティのシフトレフト 変革型リー ダーシップ 継続的 デリバリ Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知
58. この本でのリーンのプラクティス ＝ リーンマネジメント＋リーン製品開発（7, 8章） 変革型リー ダーシップ 継続的 デリバリ 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック
59. 7章：リーンマネジメントは組織⽂化、デリバリのパフォーマンスの向上、 およびバーンアウトの軽減に効果あり 変革型リー ダーシップ 継続的 デリバリ 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 組織の パフォーマンス 営利組織 非営利組織 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR Westrum 組織文化 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック
60. 8章：リーン製品開発は組織⽂化、デリバリのパフォーマンス、組織のパ フォーマンス向上やバーンアウトの軽減に効果あり 変革型リー ダーシップ 継続的 デリバリ 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック 組織の パフォーマンス 営利組織 非営利組織 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 Westrum 組織文化 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR
61. 9章：継続的デリバリとリーンのプラクティスは、デプロイ関 連の負荷やバーンアウトの軽減に効果あり 変革型リー ダーシップ Westrum 組織文化 組織の パフォーマンス 営利組織 非営利組織 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR 継続的 デリバリ リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度
62. 10章：継続的デリバリとリーンのプラクティスは、メンバーの 帰属意識や職務満⾜度を向上させ、それによって組織のパ フォーマンスを上げる効果がある 変革型リー ダーシップ Westrum 組織文化 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 継続的 デリバリ リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 組織の パフォーマンス 営利組織 非営利組織
63. その他、おまけ
64. 2023年版 DORA レポートに おける チームの 4分類 • User-centric • ユーザーのニーズに重きを置く • 組織のパフォーマンスは最⾼レ ベル • デリバリのパフォーマンスも運 ⽤のパフォーマンスも⾼い • でもBalancedよりはバーンアウ トの傾向が⾼い • Feature-driven • 機能（feature）のリリースに重 きを置く • チーム/組織のパフォーマンス は最低 • ユーザー中⼼性や運⽤のパ フォーマンスは低い • バーンアウトの傾向が最も⾼く、 職務満⾜度は最も低い • Developing • PMFをまだ終えておらず、技 術のケイパビリティもまだ向上 の途上 • たいてい組織の規模が⼩さい • デリバリのパフォーマンス、運 ⽤のパフォーマンスとも低め • ⾃動化しきれていない • バーンアウトの傾向が⾼め • Balanced • チーム/組織のパフォーマンス もそれなりに⾼く、職務満⾜度 もそれなりに⾼い • バーンアウトの傾向が最も低い • デリバリのパフォーマンス、運 ⽤のパフォーマンス、ユーザー 中⼼性それぞれがバランス良く ⾼い
65. 第3部は改善の 事例紹介です オランダのING社が Spotifyモデル＋ 「オーベヤ」 （⼤部屋⽅式）を導 ⼊した話が載ってい ます