Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

『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の科学』を絶対に読みたくなる状態を目指します。

Takeo Imai

March 08, 2024
Tweet

More Decks by Takeo Imai

Other Decks in Technology

Transcript

  1. 今井健男(ぼのたけ) フリーランスアジャイルコーチ • スクラム導⼊⽀援、プロダクトマネジメント ⽀援、開発組織づくり⽀援 • 現在は主に ログラス にてスクラムマスター ソフトウェア⼯学研究者

    • 以前、某電機メーカーの研究所にて企業研究 • 初の国際会議採択はとある指標の研究でした • 現在、国⽴情報学研究所 にてスクラムの研究 2024/1/11 2
  2. 第1章の冒頭 DevOps Research and Assessment (DORA) (2023). "State of DevOps

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

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

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

    DevOps 2023 Report". p. 10. そして 2023年の DORA レポート しかし、そうした指標はチー ムを改善するための⼿段では ありません。このベースライ ンを基に、⼈、プロセス、技 術のケイパビリティといった 幅広い観点からチームの⼒を 評価し、進歩を妨げている可 能性のあるものを特定するこ とが重要です。
  6. 第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から組織のパフォーマンスを評価する」 のを⽌めてしまったようにも⾒える。
  7. 注)僕の RSGT2024での 講演を聴かれ た⽅向け 要はこれのDevOps版 19 チームの 効果性 ステーク ホルダー

    への関⼼ 反応性 継続的改 善 チームの ⾃律性 マネジメン トの⽀援 チーム の⼠気 ステーク ホルダー 満⾜度 2024/1/11 「A Theory of Scrum Team Effectiveness 〜『ゾンビスクラムサバイバル ガイド』の裏側にある科学〜」より
  8. てことで、本のモデルを最新のDORA modelに近 づけてみました デザインセンスなさすぎで草 変革型リー ダーシップ 継続的 デリバリ Westrum 組織文化

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

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

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

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

    (ルール志向の) 組織 創造的な (パフォーマンス 志向の)組織 協⼒態勢が悪い ほどほどの協⼒ 態勢 協⼒態勢が確⽴ 情報伝達を阻⽌ 情報伝達を軽視 情報伝達に熟達 責任逃れ 責任範囲が狭い リスクを共有 仲介を阻⽌ 仲介を許容 仲介を奨励 失敗は責任転嫁 へ 失敗は裁きへ 失敗は調査へ 新規性をつぶす 新規性を問題化 新規性を実装
  13. 11章:変⾰型リーダーシップは、技術とリーンの複数のケイパ ビリティ向上に効果あり 継続的 デリバリ Westrum 組織文化 ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少

    帰属意識 職務満足度 リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック 組織の パフォーマンス 営利組織 非営利組織 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR 変革型リー ダーシップ 技術系 ケイパビリティ テスト自動化 デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験
  14. 変⾰型 リーダー シップと は? 組織のメンバーに信念や価値観を⽰してメン バーから尊敬の念や信頼を引き出し、⾏動変容 を促すようなリーダーシップ のこと ⇔ 取引型リーダーシップ:報酬や懲罰を使って

    メンバーを動かそうとするリーダーシップ 本書では以下の5つの要因で定義している 1. ビジョン形成⼒ 2. ⼼に響くコミュニケーション能⼒ 3. 知的刺激 4. ⽀援的リーダーシップ 5. 個⼈に対する評価
  15. ForsgrenとKerstenがACMの学会誌に寄稿した、実務 も意識して書かれた記事。無料公開されている。 survey data(アンケート調査によるデータ) と system data(インフラ等から⾃動計測できるデータ) は両⽅必要 としている(実務でも)。 •

    ⼯場のラインから様々な指標は system data で計測できるが、「新たに導⼊した ロボットが作業員に過度な負担をかけて いる」みたいな話は survey dataでないと わからない • ⼩さい会社なら「じゃあまずMTTRを測 るところから」といった始め⽅ができる が、⼤企業では system dataを最初から 統⼀的に測るのは困難。survey data から 始めるべき • etc.
  16. 最後に: ⽇本語版の翻訳がイマイチな件について • いくつかのDevOps⽤語、アジャイル⽤語が⼀般的な表現に置 き換えられていたり、訳出されていなかったりする • “value stream”, “kanban”, “batch”

    などなど • けっこう訳に揺れがある • “Lean Practices” など • 「修正」「修正作業」と訳されているところが、原⽂では “rework”(⼿戻り) • 本講演資料はこちらで作成しました
  17. 2章:デリバリのパフォーマンスと組織のパフォーマンス (収益性、市場占有率など)とで強い相関が確認できた 変革型リー ダーシップ 継続的 デリバリ Westrum 組織文化 ウェルビーイング バーンアウトの軽減

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

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

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

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

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

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

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

    デプロイ自動化 トランクベース開発 セキュリティのシフトレフト 疎結合なアーキテクチャ 権限を付与されたチーム 継続的インテグレーション バージョン管理 テストデータの管理 モニタリング プロアクティブな通知 ソフトウェアデリバリの パフォーマンス 変更のリードタイム デプロイ頻度 変更失敗率 MTTR リーン製品開発 小さいバッチでの作業 作業フローの可視化 顧客フィードバックの収 集と活用 チームによる実験 継続的 デリバリ リーンマネジメント WIP制限 軽量な変更の承認 可視化 本番環境からの フィードバック ウェルビーイング バーンアウトの軽減 デプロイの負荷軽減 手戻りの減少 帰属意識 職務満足度 組織の パフォーマンス 営利組織 非営利組織
  25. 2023年版 DORA レポートに おける チームの 4分類 • User-centric • ユーザーのニーズに重きを置く

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