QCon London 2015においてDave Farley氏は，これまでのソフトウェア開発の状況が最適とは言えないものであったことを認めた上で，それが継続的デリバリの実践によって著しく改善されることが調査の結果から明らかになった，という見解を発表した。継続的デリバリはソフトウェア開発の経済を変える，と氏は言う。ビジネスアイデアのより迅速な評価を可能とし，欠陥率を低減し，障害発生時のサービス復旧時間を短縮化するというのだ。
これまでのソフトウェア開発の状況は必ずしも最適ではなかった，という議論から始まったFarleyｓ氏の講演では，KPMGやLogicaによる一連のレポートやMcKinseyレポートが，状況を定量化した統計値とともに紹介された。ソフトウェア産業はこの20年間，開発方法論を改善するためにさまざまな努力を払ってきた。ウォーターフォールのようなシーケンシャルなアプローチから，スクラムなどの反復的アプローチへの移行もそのひとつだ。しかしながらFarley氏は，我々は根本的な過ちから何ひとつ学んでいない，という。
ソフトウェアデリバリの最大の目的は，ビジネスアイデアの検証としての製品提供であり，最終的にはエンドユーザに対する価値の提供である。ユーザとビジネスとの間にはフィードバックが存在しなければならない。しかもこの反復的プロセスは迅速で安価，かつ確実に実施する必要がある。
人類の為し得た最大の発明は科学と科学的手法である，と氏は指摘する。ソフトウェアデリバリにおける高速なフィードバックループの実現においても，この手法は重要だ。科学的手法の基本的なステップは，問題の特性評価，仮説の定義，推論，実験である。
特性評価 – 経験と観察に基づく推測。
仮説 – 理由の提案。
推論 – 仮説から予測を実施。
実験 – 予測のテスト。
繰り返し！
続いて氏はリーン思考の原則として，‘品質の作り込み’や‘全体最適化’，‘学習の増幅’といったものがソフトウェアデリバリのサイクルタイムを劇的に短縮する，といった内容を説明した。その上で，従来型の方法論の典型的な例として，103日のサイクルタイムを持つソフトウェア開発を紹介し，サイクルタイムを57日としたリーン型の継続的デリバリ方法論と比較してみせた。サイクルタイムの短縮はアイデアの素早い実証を可能にし，ソフトウェアデリバリに経済面での変化をもたらす。システムに何らかの欠陥が発生した場合，サイクルタイムが短ければ，ソフトウェア修正の検証が短時間で可能になるため，結果としてMTTR(平均修復時間)を短縮できるのだ。
Farley氏は，“顧客満足を最優先し、価値のあるソフトウェアを迅速かつ継続的に提供する”という，アジャイルソフトウェア開発宣言の第1の原則を引用し，継続的デリバリの重要性を強調した上で，継続的デリバリの概念を定義するものとして，次のような宣言を提案する。
アジャイル宣言の第一原理。
継続的インテグレーションの論理的拡張。
開発に対する包括的なアプローチ。
コミット毎のリリース候補作成。
完了すなわち製品版のリリース！
氏は継続的デリバリの根本原則として，再現性と信頼性を備えたソフトウェアリリースプロセスの構築，プロセスのほぼ全面的な自動化，すべてをバージョン管理，品質の作り込み，‘完了’をリリースを意味するものとして再定義，全員がリリースプロセスに責任を持つ，継続的改善の実現などを挙げた。
修正がユーザにとって価値のあるものであると同時に，実運用での問題につながるようなすべての変更を検出し，防止するという点において，開発者がコードに対して責任を負うためには，デプロイメントパイプラインの実施において，これら基本原則が尊重される必要がある。デプロイメントパイプラインは，ソフトウェア提供に関与するさまざまなグループ間のコラボレーションを可能にするとともに，すべての人たちに対して，システムの変更フローに関する可視性を提供するものでなければならない。
組織内での継続的デリバリの実現に対しては，誤った反対意見が続けざまに挙げられることが少なくない，とFarley氏は言う。代表的な反対意見である“小規模なプロジェクトではうまくいっても，スケールアップはできないだろう”に対しては，Googleの構築プロセスを確認することで反論できるはずだ。Googleはモノシリックな単一のコードリポジトリを運用して，コミット毎の年間6,000万回のビルドとテストを，数億ステップのコードに対して定常的に実行している。コミット毎にすべてのテストが実行されるため，１日に実行されるテストケースの数は１億件に達する，と氏は述べている。
それに次ぐ反対意見として議論された“頻繁にリリースするのはリスクが大き過ぎて，障害発生の原因になる”に対しては，Amazonの構築プロセスを再確認すれば反論できる。氏によると，Amazonは継続的リカバリの実施によって，2006年から2011年の期間において，デプロイを起因とするシステム停止の75%削減，デプロイを起因とする停止時間の90%削減を実現した。
継続的デリバリ導入に反対する最後の意見は，“単純なWebサイトならうまくいくかも知れないが，私のテクノロジは複雑過ぎる”というものだ。氏はこれに対して，HPがLasetJet用ファームウェアの開発に導入した開発アプローチ転換を例として反論する。この開発は複数の製品を対象としたハードウェアベースの高度なプロジェクトで，４年のタイムフレームで実施されたものだ。このプロジェクトでは，継続的デリバリを導入した結果，開発者の生産性が10倍向上した。
最後にFarley氏は，継続的デリバリの実施によるビジネスへのプラスの効果に言及し，継続的デリバリによるソフトウェア開発の経済性の変革を提案して，自身の講演の結論としている。ここでの氏は，EMA(Enterprise Management Associates)による2014年の報告書 'DevOps and Continuous Delivery'を引用して，“優秀”と評価された開発および運用機能を備えた企業の87%が，2013年の収益が10%以上増加したことを紹介した。これとは対照的に，開発および運用機能について“標準”ないしそれ以下の評価を受けた企業では，同じ伸び率は13%に留まっているという。
氏はPuppet Labsの ‘2014 State of DevOps Report’からも，継続的デリバリの効果によってスループットと信頼性が向上し，障害発生時のサービス復旧時間が12倍早くなったことを紹介した。さらに同じレポートから，組織文化こそが，組織のITパフォーマンスと全般的なパフォーマンスのいずれにおいても，最強の予測因子である，と述べている。
私たちは今，高度なITパフォーマンスと強力なビジネスパフォーマンスは相関関係にあって，生産性，収益性，市場シェアの向上に貢献するものだと，確信を持って断言できます。
Dave Farley氏の講演 “The Rationale for Continuos Delivery (The culture and practice of good software development)”のスライド資料は，QCon London 2015 Webサイトのスケジュールページにある。