# リーン製品開発 ## 定義 リーン製品開発(lean product development)とは、製造業発のリーン思考をソフトウェア製品開発に応用し、不確実な状況下で新たなビジネスモデルと製品アイデアを模索するための負担の軽いアプローチを指す。『LeanとDevOpsの科学［Accelerate］』第8章は、この考え方が Eric Ries の著書『The Lean Startup』[Ries 2011]によって広く知られるようになったと紹介する。Ries が提唱した考え方はリーン思考とデザイン思考、起業家 Steve Blank の理論[Blank 2013]を統合したもので、製品開発への実験的アプローチ(製品ライフサイクルの最初期からのプロトタイプ構築と検証の継続、作業の細分化、製品とその基盤となるビジネスモデルの早期からの頻繁な展開と進路変更)を重視する。本書はこうしたプラクティスが組織のパフォーマンス(生産性・市場占有率・収益性)に直接影響するかを調査した。第8章は§8.1・§8.2で「リーン製品開発」、§8.3で「リーン製品管理」というほぼ同義の呼称を用いており、本ページはいずれも同一の対象を指すものとして扱う。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] ch.8 冒頭, §8.1, §8.3) ## 構成要素: 4つのケイパビリティ 調査で対象にした4つのケイパビリティ(機能・能力)は次のとおりである(図8.1)。 1. **作業の細分化**: 1週間未満で製品と機能を完成して頻繁にリリースできるよう関連作業を細分化して進める能力。MVP(実用最小限の製品, minimum viable product = 製品自体とそのビジネスモデルの「検証による学び」が可能な規模の機能だけから成るプロトタイプ)の実践の度合いなどで測る。「ブランチを使って複雑な機能を開発し低頻度でリリースするのではなく、迅速な開発が可能な機能に分割する」ことがコツであり、機能レベルでも製品レベルでも応用できる。作業をMVPに細分化することでリードタイムとフィードバックループの両方を短縮できる。 2. **作業フローの可視化**: 開発の最初期から顧客関連業務に至る作業フロー全体に対するチームの理解度と、製品や機能の状況も含めたこのフローの可視化の度合い。 3. **顧客フィードバックの収集と実装**: 組織が顧客フィードバックを積極的・定期的に収集し、それを製品デザインに盛り込む能力。実践すべきプラクティスは「顧客満足度を定期的に測定する」「製品や機能の品質について顧客の意見を積極的に収集し、それを製品や機能のデザインに盛り込む」などであり、フィードバックに応じる権限をチームがどの程度有しているかも重要である。 4. **チームによる実験(承認不要な仕様変更権限)**: 承認不要な開発プロセスの一部として、開発チームが有する製品仕様の作成・変更権限。チームが開発プロセスにおいて、チーム外の人々の承認を得なくても新たなアイデアを試したり仕様を作成・更新したりできる度合いは、収益性・生産性・市場占有率を尺度に測定した組織のパフォーマンスを予測する重要な要因となることが立証されている。ただしこれは開発者に気に入ったアイデアを何でも自由に使わせてよいという提言ではなく、他の3つのケイパビリティと並行して実現して初めて、しかるべき効果を上げる。アジャイル手法を採り入れていると称する組織でも、開発チームが他チームから課された要件を満たさなければならない制約を抱えている場合が少なくなく、これは顧客を喜ばせ魅了できる製品を作れず期待される事業成果を上げられない深刻な問題を招くと第8章は警告する。 (Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] ch.8 §8.1, §8.2) > 図8.1「リーン製品開発の構成要素」(作業の細分化・管理の可視化・顧客フィードバックの収集と実装・チームによる実験)は、著作権のある書籍の図のため source ページ側にのみ置いている。[[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] を参照。 ## 実証された効果 4つのケイパビリティには、ソフトウェアデリバリのパフォーマンス・組織のパフォーマンス・組織文化を向上させ、チームの燃え尽き症候群を軽減するという統計的に有意な効果があることが、既に各種調査・分析で立証されている。さらに数年にわたる調査研究から、ソフトウェアデリバリのパフォーマンスによりリーン製品管理プラクティスの実践状況を予測できることも判明しており、複数の調査結果から、ソフトウェアデリバリの効率を高めることで作業を細分化して進める能力と常に顧客フィードバックを盛り込む能力とが向上するという好循環が読み取れる。 リーン製品管理に関わるケイパビリティの分析は2016年から2017年まで2年間にわたって行われた。2016年のモデルでは「リーン製品管理のプラクティスは、ソフトウェアデリバリのパフォーマンスに好影響をもたらし、創造的な組織文化を促進し、燃え尽き症候群を軽減する」との結果が出た。翌2017年は逆方向、すなわち「ソフトウェアデリバリのパフォーマンスが、リーン製品開発のプラクティスの促進要因となること」を確認する分析を行った。ソフトウェアデリバリのケイパビリティを高めると、作業の細分化と全工程を通してのユーザーリサーチの実施が促進され、より良い製品が生まれる。2つのモデルを組み合わせると相補的な(「好循環」の)モデルが得られ、このモデルで「リーン製品管理のプラクティスが、組織のパフォーマンスの予測要因となりうる点」も明らかになった(図8.2)。ソフトウェア関連の組織で特に重要なのは作業を細分化して進めてデリバリするためのケイパビリティであり、これを備えていればチームはユーザーリサーチの成果を製品の開発とデリバリに盛り込める。また、実験的なアプローチで製品開発を進める能力と、継続的デリバリに効果的な技術的プラクティスとの間には強い相関関係がある。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] ch.8 §8.3) > 図8.2「リーン製品管理の効果」(リーン製品管理はソフトウェアデリバリのパフォーマンス向上を介して組織のパフォーマンス向上をもたらすほか、Westrum が推奨する組織文化の促進とバーンアウトの軽減にもつながる)は、著作権のある書籍の図のため source ページ側にのみ置いている。[[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] を参照。 ## 横断的知見 - **リーン製品開発(第8章)とリーンマネジメント(第7章)は、同一書籍内で構成要素は異なるが効果モデルの構造(図8.2と図7.2)が同型であり、著者らが「リーン思考」という上位概念のもとで一貫した実証方法論を反復適用していることを示す**: [[リーンマネジメント]] concept が集約する第7章は、WIP制限・可視化・負担の軽い変更承認プロセスという3構成要素をモデル化し、その効果を図7.2で「ソフトウェアデリバリのパフォーマンス向上」「Westrumが推奨する組織文化の促進」「燃え尽き症候群の軽減」の3つとして示す。本ページが集約する第8章は、作業の細分化・作業フローの可視化・顧客フィードバックの収集と実装・チームによる実験という異なる4構成要素をモデル化するが、その効果を図8.2で全く同じ3種類(ソフトウェアデリバリのパフォーマンス向上→組織のパフォーマンス向上、Westrumが推奨する組織文化の促進、燃え尽き症候群の軽減)として示す。両者を突き合わせると、著者らは「リーンマネジメント」と「リーン製品開発/製品管理」という対象領域の異なる2つのプラクティス群に対して、同一の3種の効果(デリバリパフォーマンス・組織文化・燃え尽き症候群)を検証するという一貫した実証設計を採用しており、「リーン思考をソフトウェア組織に応用すると、対象領域によらずこの3種の効果が現れる」という本書全体の一般化されたモデルの存在が示唆される。ただし、この一般化されたモデルそのもの(なぜリーン思考の実践は領域によらずこの3効果に収束するのか)を明示的に論じた記述は、第7章・第8章のいずれにも見当たらない。(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) - **第8章が明言する「実験的な製品開発アプローチと継続的デリバリの技術的プラクティスとの強い相関」は、[[継続的デリバリ]] concept が集約する第4章のケイパビリティ群と、本ページの4ケイパビリティとが、独立した調査でありながら相互に補強し合う関係にあることを示す**: [[継続的デリバリ]] concept は、第4章がバージョン管理・テストの自動化・デプロイメントの自動化・継続的インテグレーション・情報セキュリティのシフトレフト・トランクベースの開発・テストデータの管理という7ケイパビリティを扱い、これらがソフトウェアデリバリのパフォーマンスに強い好影響を持つと統計的に結論づけたことを記録する。第8章は、これとは独立に「製品開発への実験的アプローチと、継続的デリバリに効果的な技術的プラクティスとの間に強い相関がある」と明言する(p.101, p.105)。この相関の具体的な因果メカニズム(なぜ技術的なデリバリ能力が製品開発の実験能力と結びつくのか)は第8章では説明されないが、示唆される経路の1つは、作業を細分化して頻繁にデプロイできる技術的基盤(第4章)が備わっていて初めて、A/Bテストなどによる迅速な顧客フィードバック収集(第8章)が可能になるというものである。第8章はこの経路を「作業を細分化して進めてデリバリするケイパビリティを備えていれば、A/Bテストなどの技法を駆使してユーザーフィードバックをすばやく収集できる」と述べており、技術的ケイパビリティ(第4章)が製品開発ケイパビリティ(第8章)の前提条件になっていることを示唆する。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] ch.8 p.101, p.105) - **第9章が「リーン思考のプラクティス」の一部として言及する「リーン製品管理のプラクティス」は、本ページが集約する第8章の実証データそのものを指す**: [[バーンアウト]] concept が集約する第9章は、「技術的プラクティス(継続的デリバリを促進するプラクティス)とリーン思考のプラクティス(リーンマネジメントやリーン製品管理のプラクティス)の実践を促進すると、バーンアウトの症状が緩和することが明らかになった」と述べる。この「リーン製品管理のプラクティス」が燃え尽き症候群を緩和するという主張は、本ページが集約する第8章・図8.2が示す「リーン製品管理→バーンアウトの軽減」という効果と同一の実証結果を指しており、第9章はこれを「リーン思考のプラクティス」という上位カテゴリでリーンマネジメント(第7章)と並置する形で要約している。第9章単体では「リーン製品管理のプラクティス」の内実(4ケイパビリティ)には触れておらず、本ページが第8章から集約する構成要素の定義が、第9章のこの一文を具体化する役割を果たす。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] §9.2.1, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] ch.8 §8.3, 図8.2) ## 未解決の問い - 図8.2が示す「リーン製品管理→Westrumが推奨する組織文化の促進」という効果の媒介メカニズム(なぜ作業の細分化や顧客フィードバックの収集が組織文化を変えるのか)は、第7章の同型の未解決の問い([[リーンマネジメント]] concept を参照)と同じく、第8章の記述だけでは特定できない。 - 4つのケイパビリティ(作業の細分化・可視化・顧客フィードバック・承認不要の実験)を統合してどの程度の重みづけでパフォーマンスを予測するかの定量的なモデル(回帰係数等)は、第8章の記述からは読み取れない。 - 第8章は「ソフトウェアデリバリのパフォーマンス→リーン製品管理プラクティス」という2017年の逆方向の因果と、2016年の「リーン製品管理プラクティス→ソフトウェアデリバリのパフォーマンス」という順方向の因果を組み合わせた「好循環」モデルを提示するが、この双方向因果を検証した統計的手法(構造方程式モデリング等)の詳細は本章に示されていない。 - 第16章(ING の事例)がこの好循環モデルを実践レベルでどう体現するかは未確認。第16章 ingest 後に追記する必要がある。 - チームが承認不要で仕様変更できる度合い(4つ目のケイパビリティ)と、第7章が扱う「負担の軽い変更承認プロセス」([[リーンマネジメント]] concept)は、いずれも「外部承認の重さ」を扱うが対象(製品仕様の変更か、本番環境への変更か)が異なる。両者の関係(製品仕様の裁量権と本番変更の裁量権は独立に機能するのか、相関するのか)は本書のいずれの章でも直接検証されていない。 ## 関連 - 概念: [[リーンマネジメント]](同一書籍内の姉妹概念。効果モデルの構造が同型) / [[継続的デリバリ]](実験的な製品開発アプローチと強い相関を持つ技術的プラクティス群) / [[Westrumの組織文化類型]](図8.2が参照する組織文化の促進効果) / [[バーンアウト]](第9章が本ページの実証データを要約引用) / [[DORA]](ソフトウェアデリバリのパフォーマンスという共通の測定対象) - ソース: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] - 書籍: [[wiki/entities/LeanとDevOpsの科学［Accelerate］|LeanとDevOpsの科学［Accelerate］]] ## 出典 - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第8章.