# 継続的デリバリ ## 定義 継続的デリバリ(continuous delivery)とは、機能の追加、構成の変更、バグの修正、各種試行など、さまざまな変更を、安全かつ迅速かつ持続可能な形で本番環境に組み込んだりユーザーに提供したりする作業を促進する一群のケイパビリティから成る手法である。次の5つの基本原則を柱とする: (1) 品質の概念を生産工程の最初から組み込む、(2) 作業をバッチ処理(小さい単位)で進める、(3) 反復作業はコンピュータに任せて人間は問題解決に当たる、(4) 徹底した改善努力を継続的に行う、(5) 全員が責任を担う。実践のためには、包括的な構成管理(CM)・継続的インテグレーション(CI)・継続的テストという3種の作業の基盤を整備する必要がある。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.1) ## 実証された効果とプラクティス 2014〜2016年の調査で、バージョン管理・テストの自動化・デプロイメントの自動化・継続的インテグレーション・情報セキュリティのシフトレフト・トランクベースの開発・テストデータの管理という7つのケイパビリティを計測し、これらがソフトウェアデリバリのパフォーマンスに強い好影響を与え、デプロイ関連の負荷とチームの燃え尽き症候群を軽減する効果を持つことが判明した。2017年には一次的構成概念を用いた追加分析で、疎結合アーキテクチャとツール選択の自由という2つのケイパビリティも有意な影響を持つと判明し、合計9つの効果の高いケイパビリティが特定された。継続的デリバリの実践度は、組織文化の改善(創造的文化の浸透)・ソフトウェアデリバリのパフォーマンス(リードタイム・デプロイ頻度・MTTR)の向上・変更失敗率の低下・組織への帰属意識の強化とも関連する。品質面では、修正作業や予定外の作業にかかった時間の割合が継続的デリバリの実践度と最も強く相関し、ハイパフォーマーは新たな作業に49%、予定外の作業や修正作業に21%の時間を費やすのに対し、ローパフォーマーはそれぞれ38%・27%だった。個別プラクティスとしては、システム/アプリケーションのコンフィギュレーションをバージョン管理対象にすることがアプリケーションコードのバージョン管理よりデリバリパフォーマンスとの相関が強いこと、開発者主体の承認テスト作成・管理がQA/外注主体の自動化テストより有効であること、トランクベースの開発(アクティブブランチ3つ未満、1日未満でのトランクへのマージ)が長命な機能ブランチより高いパフォーマンスと関連することが示された。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2〜§4.4) ## 横断的知見 - **「継続的デリバリ」と「継続的デプロイ」は、本書の訳語では明確に区別される隣接概念であり、前者は後者を包含する上位のケイパビリティ群である**: [[継続的デプロイ]] concept が扱う『ウェブオペレーション』4章(Eric Ries, 2011)の定義は「コードを書いたらすぐにプロダクションへ反映する」という具体的な実践(継続的な自動デプロイの実行そのもの)を指すのに対し、本ページが扱う Accelerate 第4章の定義は「安全かつ迅速かつ持続可能な形で変更を本番環境に組み込んだりユーザーに提供したりする作業を促進する一群のケイパビリティ」という、より広い能力の集合を指す。実際、Accelerate 第4章が2017年の追加分析で測定し直した継続的デリバリの一次的構成概念の1つは「本番デプロイをオンデマンドで行える」能力であり、これは「常に実行する」ことではなく「いつでも実行できる」ことを要求する——継続的デプロイのように毎回自動的に本番へ反映することまでは求めていない。両概念はバージョン管理・CI・自動化テストといった技術的基盤を共有するが、継続的デプロイはその基盤の上に立つ具体的な運用方針の1つであり、継続的デリバリはその基盤自体を含むケイパビリティの総称である。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.1, §4.2, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.5.1) - **Accelerate 第4章のトランクベースの開発に関する実証データ(3つ未満のアクティブブランチ、1日未満でのマージ)は、『ウェブオペレーション』が理論的に整理した小さなバッチの利点を、独立した大規模調査によって定量的に裏づける**: [[バッチサイズ]] concept は、エリック・ライズが整理する小さなバッチの4つの利点(フィードバックの速さ・問題の局所化・リスクの低減・オーバーヘッドの削減)と、ポール・ハモンドが Flickr の実務から示す「10,000行より10行の方がバグを見つけやすい」という主張を、2011年の実務者コミュニティの理論と経験則として記録してきた。Accelerate 第4章は、これと同じ主張(変更の単位を小さく保ち頻繁に統合する)を、業種・組織規模を問わない調査データによって「トランクベースの開発をしているチームの方がデリバリのパフォーマンスが高い」という統計的な関連として裏づける。ただし Accelerate 第4章は、この関連を支える因果メカニズムについては「より『寿命』の長いブランチを複数使うとリファクタリングとチーム間のコミュニケーションを阻害するのではないか」という仮説(聞き取り調査と著者らの経験に基づく)にとどめており、[[バッチサイズ]] concept が指摘する「バッチサイズをどこまで小さくすれば利点が頭打ちになるか」という未解決の問いには踏み込んでいない。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.4.4, [[バッチサイズ]]) - **継続的デリバリが目指す「複数のフィードバックループの構築」は、[[フィードバック駆動開発]] が扱う本番監視データの開発統合とは異なる層のフィードバックを対象とする**: Accelerate 第4章は、継続的デリバリを「質の高いソフトウェアをより高頻度でより確実にユーザーに提供できるよう、複数のフィードバックループを作ること」と位置づけ、その中心はコミットのたびに実行される単体テスト・承認テストからの品質フィードバックである。一方 [[フィードバック駆動開発]] concept が扱う FDD(Cito ら, 2015)は、本番稼働中のランタイムメトリクス(APMデータ)をIDEへ統合するという、デプロイ後の運用データに基づくフィードバックを対象とする。両者はいずれも「開発サイクルとフィードバックの間隔を縮める」という同じ目的を共有するが、継続的デリバリが対象とするのはデプロイ前のテスト自動化によるフィードバックであるのに対し、FDD が対象とするのはデプロイ後の本番運用データによるフィードバックであり、ソフトウェアデリバリのライフサイクル上で相補的な区間を担う。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.1, [[フィードバック駆動開発]]) - **第4章が7つのケイパビリティの1つとして統計的に効果ありと結論づける「情報セキュリティのシフトレフト」の内実は、第6章が定性的に詳述する**: 本ページが集約する第4章は、2014〜2016年調査で計測した7つのケイパビリティ(バージョン管理・テストの自動化・デプロイメントの自動化・継続的インテグレーション・情報セキュリティのシフトレフト・トランクベースの開発・テストデータの管理)がソフトウェアデリバリのパフォーマンスに強い好影響を与えると統計的に結論づけるが、シフトレフトが具体的に何を指すかには踏み込まない。[[情報セキュリティのシフトレフト]] concept が集約する第6章は、シフトレフトが生む3つの状況(レビューの並走化・ライフサイクル全体への組み込み・開発者向けツール提供)とセキュリティチームの役割転換を詳述し、さらに「デリバリのパフォーマンスが高い組織はセキュリティ問題の修正所要時間が有意に少ない」「ハイパフォーマーの修正時間はローパフォーマーの2分の1」という具体的な効果を示す。両章は同一書籍内の独立した章として、定量的な効果測定(第4章)と質的な機序の説明(第6章)を相補的に提供する。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]] §6.1, [[情報セキュリティのシフトレフト]]) - **第4章が統計的効果として示す「デプロイ関連の負荷とバーンアウトの軽減」の内実は、第9章が測定尺度・原因分析・組織的要因まで分解して詳述する**: 本ページ既出の「実証された効果とプラクティス」節は、第4章の7つのケイパビリティが「デプロイ関連の負荷とチームの燃え尽き症候群を軽減する効果を持つ」という統計的結論を記録するのみで、デプロイ関連の負荷とバーンアウトそれぞれの定義・測定・原因には踏み込まなかった。[[デプロイ関連の負荷]] concept が集約する第9章は、デプロイ関連の負荷を「エンジニアがコードを本番環境にプッシュする際に抱く恐怖感・不安」という尺度として定義し、3つの典型的原因(デプロイ容易性を欠いた設計・手作業による本番変更・チーム間の複雑な引き継ぎ)まで分解する。[[バーンアウト]] concept が集約する同章はさらに、Christina Maslachの6つの組織的危険因子(過重労働・自律性の欠如・不十分な報奨・人間関係の断絶・公平性の欠如・価値観のズレ)と、重症バーンアウトに相関する5つの組織的要因(組織文化・デプロイ関連の負荷・指導者の影響力・DevOps導入への投資・組織のパフォーマンス)を示す。第4章の統計的な「効果あり」という結論(何が効くか)に、第9章は「何に、どのように効いているのか」という測定枠組みと因果の内実を与える。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] §9.1, §9.2, [[デプロイ関連の負荷]], [[バーンアウト]]) - **第7章が推奨する「負担の軽い変更承認プロセス+デプロイメントパイプライン」は、第4章が測定する7ケイパビリティのうち「デプロイメントの自動化」「継続的インテグレーション」を、変更統制という異なる評価軸から再照射する**: 本ページが集約する第4章は、デプロイメントの自動化・継続的インテグレーションを含む7つのケイパビリティがデリバリパフォーマンスに強い好影響を持つと統計的に結論づける。[[リーンマネジメント]] concept が集約する第7章(ソフトウェア管理のプラクティス)は、本番環境への変更承認プロセスを4シナリオで調査し、チーム外の管理者やCABによる承認必須がリードタイム・デプロイ頻度・MTTRを悪化させる一方で変更失敗率は改善しないという結果を示したうえで、ペアプログラミングやチーム内コードレビューといった負担の軽い変更承認プロセスと、望ましくない変更を検知・排除するデプロイメントパイプラインの併用を推奨する。第4章がパフォーマンス向上の観点からデプロイメント自動化を評価するのに対し、第7章はリスク統制・監査証跡の観点から同じ技術基盤(デプロイメントパイプライン)を評価しており、両章は同じ技術的基盤を異なる評価軸(速度対統制)から補い合う。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] §7.2, p.96) - **第8章が明言する「実験的な製品開発アプローチと継続的デリバリの技術的プラクティスとの強い相関」は、第4章の7ケイパビリティと第8章のリーン製品開発の4ケイパビリティとの間に、明示的な相互依存関係があることを示す**: 本ページが集約する第4章は、バージョン管理・テストの自動化・デプロイメントの自動化・継続的インテグレーション・情報セキュリティのシフトレフト・トランクベースの開発・テストデータの管理という7ケイパビリティがソフトウェアデリバリのパフォーマンスに強い好影響を持つと統計的に結論づける。[[リーン製品開発]] concept が集約する第8章は、これとは独立に「製品開発への実験的アプローチと、継続的デリバリに効果的な技術的プラクティスとの間に強い相関がある」と明言し(p.101, p.105)、その経路として「作業を細分化して進めてデリバリするケイパビリティを備えていれば、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) - **本ページ既出の「実証された効果とプラクティス」節が一文で触れる「組織への帰属意識の強化」は、第10章の図10.1と6項目の測定尺度によって、独立した因果図式として詳述される**: 本ページ既出の記述は、継続的デリバリの実践度が「組織への帰属意識の強化」と関連することを、7〜9ケイパビリティの効果の一項目として一文で触れるにとどまる。[[従業員エンゲージメント]] concept が集約する第10章は、これを「継続的デリバリ+リーンなプラクティス→帰属意識の強化→組織のパフォーマンス向上」という独立した因果図式(図10.1)として詳述し、帰属意識をKankanhalli et al. 2005由来の6項目のリッカート尺度で測定する構成概念として定義する。第4章の「関連する」という一文の統計的示唆に、第10章は測定方法と因果の経路という内実を与えており、第4章↔第9章(デプロイ関連の負荷・バーンアウト)で既に確認された「統計的結論と測定枠組みの相補性」という本書に繰り返し現れるパターンが、帰属意識でも成立する。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 10 従業員の満足度、アイデンティティ、コミットメント]] §10.2, [[従業員エンゲージメント]]) - **2019年の学術サーベイは、本ページがAccelerate第4章から抽出する「継続的デリバリ⊃継続的デプロイ」という上位/下位の区別を、概念地図のレベルでは行っていない**: 本ページ既出の知見は、Accelerate第4章の定義(能力の集合としての継続的デリバリ)と『ウェブオペレーション』4章の定義(具体的実践としての継続的デプロイ)を突き合わせ、両者を上位概念/下位概念の関係として整理してきた。Leite et al.(2019)第5章のDelivery概念地図(図7)は、これとは異なり「Continuous Delivery」と「Continuous Deployment」を単一のノードとして扱い、いずれもFrequent and reliable release processによって実現され(implemented by)、Automationを可能にする(enables)ものとして同じ位置に置く。本文(§5.3)もこの2語を区別して定義しない。これは、文献の系統的分析に基づく学術的な概念地図が、デプロイメントパイプラインの自動化という上位の枠組みを優先し、実践レベルでの継続的デリバリ/継続的デプロイの語彙的な区別には踏み込んでいないことを示す——本ページが依拠する2つの実務書(Accelerate・『ウェブオペレーション』)がこの区別を明確に立てているのとは対照的である。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] §5.3 図7, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.1) ## 未解決の問い - Accelerate 第4章はトランクベースの開発が高いデリバリパフォーマンスと関連する理由を仮説(リファクタリングとコミュニケーションの阻害)にとどめており、統計的因果関係までは立証していない。この因果メカニズムを直接検証した後続研究はあるか。 - 継続的デリバリと継続的デプロイの境界(オンデマンドで「できる」ことと実際に「する」ことの違い)は、実務上どこで引かれるべきか。Accelerate 第4章と『ウェブオペレーション』4章の両ソースだけでは、この境界を明確に定義する基準は得られていない。 - 継続的デリバリの9つの効果の高いケイパビリティ(Accelerate 第4章)のうち、疎結合アーキテクチャとツール選択の自由は第5章で詳述されるとされる。第5章 ingest 後、これら2つのケイパビリティと本ページの定義がどう接続するかを追記する必要がある。 - 第9章はデプロイ関連の負荷とバーンアウトの軽減メカニズムを詳述したが、これが継続的デプロイ([[継続的デプロイ]] concept、コードを書いたらすぐにプロダクションへ反映する運用)にどこまでそのまま当てはまるか(オンデマンドで「できる」ことと常に自動で「する」こととの違い)は、第9章自身では区別されていない。[[継続的デプロイ]] concept の同種の未解決の問いも参照。 - Leite et al.(2019)の概念地図が継続的デリバリと継続的デプロイを単一ノードとして扱う理由は、単に概念地図の抽象度が粗いからか、それとも第2章(DevOps定義)や第6章(ツールセット)で両者がより詳細に区別されているのか。第5章・第6章の現ソース群では確認できていない。 ## 関連 - 概念: [[継続的デプロイ]](継続的デリバリの基盤の上に立つ具体的な運用方針) / [[バッチサイズ]](トランクベースの開発の実証データが裏づける理論) / [[ソフトウェア変更管理]] / [[フィードバック駆動開発]](デプロイ後の本番データによる相補的なフィードバック) / [[情報セキュリティのシフトレフト]](7つのケイパビリティの1つの内実を第6章が詳述) / [[デプロイ関連の負荷]](第4章の統計的効果の内実を第9章が測定尺度・原因分析として詳述) / [[バーンアウト]](同じく第9章がMaslachの6因子モデルで詳述) / [[リーンマネジメント]](デプロイメントパイプラインという共通技術基盤を変更統制の観点から評価する第7章のハブconcept) / [[リーン製品開発]](実験的な製品開発アプローチと強い相関を持つ第8章のケイパビリティ群) / [[従業員エンゲージメント]](帰属意識の強化という効果の内実を第10章が図10.1と測定尺度で詳述) - ソース: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 10 従業員の満足度、アイデンティティ、コミットメント]] / [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]](継続的デリバリ/継続的デプロイを単一ノードとして扱う概念地図との対比) - 実体: [[Jez Humble]] / [[W. E. Deming]] / [[Kevin Behr]] - 書籍: [[LeanとDevOpsの科学［Accelerate］]] ## 出典 - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第4章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第6章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第9章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第7章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第8章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第10章 §10.2. - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §5.3 図7)— Delivery概念地図が継続的デリバリ/継続的デプロイを単一ノードとして扱う