リーンマネジメント - yuuk1's Digital Garden

# リーンマネジメント ## 定義リーンマネジメント(lean management)とは、製造現場発の「リーン生産方式」(トヨタ生産方式に由来)の考え方をソフトウェア開発・デリバリの管理に応用した手法である。『LeanとDevOpsの科学［Accelerate］』第7章は、この応用を一連の著作で先駆的に提唱したのは Mary and Tom Poppendieck であると紹介したうえで、本調査研究がリーンマネジメントとそのソフトウェアデリバリへの応用を次の3つの構成要素でモデル化したと述べる:(1) 進行中の作業(WIP: Work in Progress)の制限、(2) 品質・生産性の数値指標と作業現況(不具合を含む)を一覧できるビジュアルディスプレイの作成・継続管理(可視化/見える化)、(3) アプリケーションパフォーマンスとインフラのモニタリングツールのデータに基づく日常的な意思決定(負担の軽い変更承認プロセスを含む)。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1) ## 構成要素 ### 1. 進行中の作業(WIP)の制限 WIP制限はリーン思考の実践コミュニティで定番の手法で、リードタイムを長引かせる過負荷の予防とワークフロー障害要因の明確化に活用される。ただし「WIP制限が単独ではデリバリのパフォーマンスの有力な予測尺度になりえない」点が本調査研究の注目すべき知見である。WIP制限は、ビジュアルディスプレイと併用したうえで、作業状況のモニタリングツールからデリバリ担当チームや事業部へのフィードバックループを確立して初めて、ソフトウェアデリバリのパフォーマンスに強力な効果を与える。調査ではWIP制限の能力・プロセスの確立状況だけでなく、「WIP制限が業務フローの可視化を妨げていないか」「妨げているならプロセス改善で解消しスループット向上につなげているか」を確認しており、WIP制限は改善努力によるフロー促進につながらなければ意味がないとされる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1) ### 2. 可視化(ビジュアルディスプレイ) ダッシュボードなどによる情報共有、カンバンやストーリーボードを用いた作業の計画立案、品質・生産性情報の随時容易な入手、失策・不具合の発生率の可視化といった実践が対象となる。カギとなるのは「可視性」と「質の高いコミュニケーション」であり、「表示される情報のタイプ」「共有の範囲」「アクセス可能性」が調査の観点である。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1) ### 3. 負担の軽い変更承認プロセス本番環境への変更プロセスを4シナリオ((1) チーム外の管理者やCABの承認必須、(2) ハイリスクな変更のみ承認必須、(3) ピアレビューのみ、(4) 変更承認プロセスなし)で調査した結果、(2)はパフォーマンスと相関せず、(2)より(3)・(4)の方が高いパフォーマンスを示し、(1)が最も低かった。(1)のチーム外承認必須は、リードタイム・デプロイ頻度・サービス復旧所要時間と負の相関を示す一方、変更失敗率とは相関しない——つまり本番システムの安定性は向上させず、作業の遅延だけを招く「見せかけ」のリスク管理である。著者らは、ペアプログラミングやチーム内コードレビューといった負担の軽い変更承認プロセスと、望ましくない変更を検知・排除するデプロイメントパイプラインの併用を推奨する。規制産業で求められる業務の隔離(SOD)についても、変更諮問委員会を新設せずに (a) コミット直前/直後の第三者レビューの記録、(b) デプロイメントパイプラインの完全自動化という2手法で満たせるとされる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.2, p.96-98) ## 実証された効果上記3つのプラクティスを併用すればデリバリパフォーマンスが向上するという仮説が立証されたほか、これらのプラクティスがチームの文化とパフォーマンスに好影響を与えることも判明した。さらに図7.2が示すとおり、リーンマネジメントのプラクティスには、ソフトウェアデリバリのパフォーマンス向上に加え、チームの燃え尽き症候群を軽減する効果(第9章を参照)と、より創造的な組織文化を促進する効果(第3章のWestrumのモデルを参照)がある。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1, 図7.2) ## 横断的知見 - **第9章は、第7章の図7.2が挙げる「燃え尽き症候群の軽減」効果の因果メカニズムを、「作業担当者への裁量とリソースの提供」という第7章の3構成要素にない第4の要諦で説明する**: 本ページが集約する第7章は、リーンマネジメントを WIP制限・可視化・負担の軽い変更承認プロセスの3構成要素でモデル化し、これらのプラクティスが燃え尽き症候群を軽減する効果を持つと図7.2で示すが、その因果メカニズムは説明しない。第9章は、「リーンマネジメントの要諦は、作業担当者に自身の作業を改善するための(時間も含めた)リソースを提供することである」と述べ、これにより実験・失敗・学習を奨励する作業環境が育まれ、担当者が自身の仕事を左右する意思決定を自ら下せるようになり、就業時間内に付加価値のある創造的な仕事をこなす余裕が生まれると説明する(好例: Googleの「20%タイム」、IBMの「THINK Fridayプログラム」)。これは第7章の3構成要素(プロセス改善・可視化・変更統制)とは異なる次元——個人の裁量・時間的余裕という第4の要諦——であり、第7章単体の記述だけでは「リーンマネジメント」の全体像は捉えきれないことを示す。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1, 図7.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] ch.9 §9.2.2 p.116-118) - **WIP制限が「単独では不十分」という本ページの知見は、既存の[[DORA]] concept が集約するデプロイ頻度の理論的位置づけと補い合う**: [[DORA]] concept は、Accelerate 第2章の知見として「デプロイの頻度はバッチサイズ削減というリーン手法由来の目標の代理指標として選ばれた」ことを記録している。本ページが集約する第7章のWIP制限は、まさにこのバッチサイズ削減(スループット増大)を狙う実践プラクティスの一つであり、両章を突き合わせると、第2章が指標として測定する「デプロイ頻度」と第7章が実践プラクティスとして提示する「WIP制限」は、いずれも同じリーン生産方式由来の目標(バッチサイズを絞り込みフローを速める)の異なる側面——測定指標(第2章)と現場の実施手法(第7章)——であることが分かる。ただしWIP制限は単独でデリバリパフォーマンスを予測しないと第7章は明言しており、デプロイ頻度という指標とWIP制限という手段の因果関係を直接検証したデータは本書のいずれの章にも見当たらない。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] ch.2 p.22-23) - **図7.2が名指しする「Westrumが推奨する組織文化の促進」効果は、既存の[[Westrumの組織文化類型]] concept が集約する第3章の測定結果そのものを指す**: [[Westrumの組織文化類型]] concept は、第3章がWestrumの3類型(不健全/官僚的/創造的)をリッカート尺度で測定し、「組織文化によりソフトウェアデリバリのパフォーマンスと組織のパフォーマンスを予測できる」ことを統計的に立証したと記録している。本ページが集約する第7章の図7.2は、リーンマネジメントのプラクティスがこの「創造的な組織文化」を促進する効果を持つと主張するが、その因果メカニズム(なぜWIP制限や可視化が組織文化を変えるのか)までは第7章単体では説明されない。両概念を突き合わせると、リーンマネジメントの実践(独立変数)→組織文化の変化(媒介変数、第3章の測定対象)→デリバリパフォーマンス(従属変数、第2章の測定対象)という因果の連鎖が示唆されるが、この媒介関係を直接検証したデータは本書のいずれの章にも見当たらない。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 図7.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 3 組織文化のモデル化と測定、改善の方法]] §3.3, §3.4) - **第7章が推奨する「負担の軽い変更承認プロセス+デプロイメントパイプライン」の後半は、既存の[[継続的デリバリ]] concept が集約する第4章の7ケイパビリティのうち「デプロイメントの自動化」「継続的インテグレーション」と同じ技術基盤を指す**: [[継続的デリバリ]] concept は、第4章が2014〜2016年調査で計測した7つのケイパビリティ(バージョン管理・テストの自動化・デプロイメントの自動化・継続的インテグレーション・情報セキュリティのシフトレフト・トランクベースの開発・テストデータの管理)がデリバリパフォーマンスに強い好影響を持つと記録する。第7章が推奨する「望ましくない変更を探知・排除するためのデプロイメントパイプライン」は、この7ケイパビリティのうち「デプロイメントの自動化」を変更承認プロセスという別の角度(統制・監査証跡)から再照射したものであり、両章は同じ技術基盤(デプロイメントパイプライン)を、第4章はパフォーマンスへの効果、第7章はリスク統制への効果という異なる評価軸で扱っている。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.2, p.96, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2) - **第8章のリーン製品管理の効果モデル(図8.2)は、本ページが集約する第7章の効果モデル(図7.2)と構造が同型であり、著者らが「リーン思考」の効果を一貫した実証設計で検証していることを示す**: 本ページは第7章の図7.2が、リーンマネジメント(WIP制限・可視化・負担の軽い変更承認プロセス)の効果として「ソフトウェアデリバリのパフォーマンス向上」「Westrumが推奨する組織文化の促進」「燃え尽き症候群の軽減」の3種を示すことを記録してきた。[[リーン製品開発]] concept が集約する第8章は、対象領域が全く異なる4ケイパビリティ(作業の細分化・作業フローの可視化・顧客フィードバックの収集と実装・チームによる実験)を扱いながら、その効果モデル(図8.2)で全く同じ3種の効果を示す。両者を突き合わせると、リーンマネジメントとリーン製品開発という異なるプラクティス群に対して著者らが同一の3種の効果を検証するという一貫した実証設計を採用していることが分かるが、なぜこの3効果に収束するのかという一般化されたモデルの説明は、いずれの章にも見当たらない。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1, 図7.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] ch.8 §8.3, 図8.2) - **第10章の図10.1は、リーンなプラクティスの効果として図7.2・図8.2が示す3効果とは別の第4の効果「帰属意識の強化」を単独の因果経路として示す**: 本ページは既に、図7.2(第7章)と図8.2(第8章)が「ソフトウェアデリバリのパフォーマンス向上」「創造的な組織文化の促進」「燃え尽き症候群の軽減」という同じ3種の効果を、対象領域の異なるプラクティス群(リーンマネジメント/リーン製品開発)について一貫して示すことを記録してきた。[[従業員エンゲージメント]] concept が集約する第10章の図10.1は、「継続的デリバリ」と「リーンなプラクティス」が「帰属意識の強化」を介して「組織のパフォーマンス向上」につながるという、図7.2・図8.2にはない第4の効果経路を単独で示す(図10.2は同じ構図を「職務満足度」で示す)。図7.2・図8.2が3効果を並列に示すのに対し、図10.1・図10.2はそれぞれ単一の媒介変数(帰属意識/職務満足度)を経由する経路として描かれており、リーンなプラクティスの効果を検証する著者らの実証設計が、章によって「複数効果の並列列挙」と「単一の媒介変数を通した経路図」という異なる図式化のスタイルを使い分けていることが分かる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 図7.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 10 従業員の満足度、アイデンティティ、コミットメント]] §10.2, §10.3, [[従業員エンゲージメント]]) - **第16章のオーベヤとキャッチボールは、本ページが第7章から集約した「可視化(ビジュアルディスプレイ)」構成要素を、ING Netherlands という実践事例のレベルで裏付ける**: 本ページは第7章の構成要素2「可視化」を、ダッシュボードやカンバン・ストーリーボードによる情報共有、失策・不具合発生率の可視化といった抽象的な実践一覧として記録してきた。事例研究章である第16章は、この抽象的な構成要素を ING の「オーベヤ(大部屋)」——ホワイトボードで目標・ギャップ・進捗・問題点を赤/緑で色分けして可視化し、企業戦略に直接結びつける仕組み——として具体化する。さらに、第7章では触れられていなかった「可視化された情報をどう組織内で伝播させるか」という運用面についても、第16章はスクワッドのオーベヤ→トライブのオーベヤ→経営幹部のオーベヤへとタテ・ヨコ方向に問題や学びをリレーする「キャッチボール」という具体的な仕組みを示す。このキャッチボールは、戦略のデプロイの一種として「ホウシンカンリ(方針管理)」と呼ばれ、PDCA(Plan-Do-Check-Act)のフィードバックサイクルを全レベルで形成する。抽象的なプラクティス一覧(第7章)と、それを具体的な部屋・ルーティンとして実装した一事例(第16章)という関係にあり、第7章単体では見えなかった「可視化の情報がどう組織を上下・左右に流れるか」という運用設計が、第16章によって初めて具体的に描かれる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 16 ハイパフォーマンスを実現するリーダーシップとマネジメント]] ch.16 p.211, p.214-216, 図16.1, 図16.3) - **第16章の「独自のものを作り上げる」という提言は、第7章・第8章・第10章が示す複数の効果モデル(図7.2・図8.2・図10.1/10.2)への一貫した実証設計とは異なる次元で、リーンなプラクティスの導入方法そのものに制約を課す**: 本ページは既に、図7.2(第7章)・図8.2(第8章、[[リーン製品開発]])・図10.1/10.2(第10章、[[従業員エンゲージメント]])が、対象領域の異なるプラクティス群についてほぼ同型の効果(デリバリパフォーマンス・組織文化・燃え尽き症候群または帰属意識)を検証する一貫した実証設計を採用していることを記録してきた。これらの章はいずれも「何が」効くかを扱うのに対し、第16章は ING の事例を通じて「どう導入すべきか」を扱い、「他社のプラクティスをそのままコピーしたり、専門家がデザインしたモデルをそのまま実行してはならない」「大手コンサルティング会社への委託では独自のプロセスを開発する自信やケイパビリティは身につかない」と明言する。これは、第7章のWIP制限・可視化・変更承認プロセスという構成要素そのものを否定するものではなく、それらを「チェックリストとしてではなくガイドラインとして」実験的に採用すべきだという導入方法上の制約を加えるものであり、効果モデルを検証してきた第7・8・10章と、導入方法を論じる第16章は補完関係にある。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.1, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 16 ハイパフォーマンスを実現するリーダーシップとマネジメント]] ch.16 p.223-224, p.227) ## 未解決の問い - WIP制限とビジュアルディスプレイ、モニタリングツールからのフィードバックループという3要素の「併用」が、単独使用と比べてどの程度パフォーマンスを押し上げるかの定量的な効果量は、第7章の記述からは読み取れない。 - 変更承認プロセスの4シナリオ調査(§7.2)は業種・組織規模を統制した分析結果を示していない。規制産業(金融・医療等)では業務の隔離(SOD)が法的要請であるため、そもそも(3)・(4)を選択できないケースがどの程度あるかは記述がない。 - リーンマネジメントのプラクティスが創造的な組織文化を促進する媒介メカニズム(上記横断的知見)は、本書のいずれの章でも直接検証されていない。第8章(リーン製品開発)・第16章(ING事例)を確認したが、いずれも効果を示すか実践を描写するにとどまり、「なぜオーベヤやキャッチボールが組織文化を変えるのか」という媒介メカニズムには踏み込んでいない。 - 第9章が示す「個人の裁量・時間的余裕」という第4の要諦(Googleの20%タイム等)は、第7章のWIP制限・可視化・変更承認プロセスという3構成要素とどう両立するか。時間的余裕の確保がWIP制限の運用(限られたリソースの配分)とどう整合するかは、両章の記述だけでは接続できない。 - 第16章のオーベヤ・キャッチボールは第7章の「可視化」構成要素を具体化する一事例だが、ING が他の2構成要素(WIP制限・負担の軽い変更承認プロセス)をどう実践しているかは、第16章の記述からは確認できない(第16章はスクワッドのWIP可視化には触れるが、WIP制限の数値目標や変更承認プロセスの具体的な運用には言及していない)。 ## 関連 - 概念: [[DORA]](4指標とハイ/ミディアム/ローパフォーマー分類) / [[Westrumの組織文化類型]](創造的な組織文化の測定) / [[継続的デリバリ]](デプロイメントパイプラインという共通技術基盤) / [[ソフトウェア変更管理]](変更承認プロセスの隣接領域) / [[イテレーションの長さ]](WIP制限とカンバンの関係) / [[リーン製品開発]](効果モデルの構造が同型の姉妹概念) / [[従業員エンゲージメント]](図10.1・図10.2が示す帰属意識・職務満足度という第4の効果経路) / [[スクワッド・トライブ・チャプター]](オーベヤ・キャッチボールを実装するING の組織モデル) - ソース: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]](燃え尽き症候群軽減の因果メカニズム) / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]](効果モデルが同型の姉妹章) / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 10 従業員の満足度、アイデンティティ、コミットメント]](図10.1・図10.2の帰属意識・職務満足度経路) / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 16 ハイパフォーマンスを実現するリーダーシップとマネジメント]](オーベヤ・キャッチボールという可視化の実践事例) - 書籍: [[wiki/entities/LeanとDevOpsの科学［Accelerate］|LeanとDevOpsの科学［Accelerate］]] ## 出典 - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第7章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第9章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第8章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第10章 §10.2, §10.3. - Steve Bell, Karen Whitley Bell 著, 武舎広幸・武舎るみ訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第16章.