継続的デリバリによるITパフォーマンスの改善

継続的デリバリのもたらす大きなメリットのひとつはリリースのリスク低減である – 包括的な自動テスト(Comprehensive test automation)と継続的インテグレーションとは、ITのパフォーマンスに最も大きな影響を与えるプラクティスだ。継続的デリバリとITパフォーマンスに関する調査から、継続的デリバリのプラクティスの実践はより高いITパフォーマンスにつながるだけでなく、ハイパフォーマによるテンポの向上と高レベルの安定性を実現することが明らかになった、とJez Humble氏は言う。

Jez Humble氏はLean IT Summit 2017で、継続的デリバリに関して講演を行なう予定である。このカンファレンスの様子は、InfoQのQ&Aや要約，特集記事などでお伝えしていく。

Lean IT Summit 2017はフランスのパリで、3月14、15日に開催される。

Lean ITではディジタルが職場にもたらすさまざまな課題を解決するための、実証済みの管理プラクティスが提供されます。IT/ディジタルにおけるリーンが実現するものとして、サミットでは３つのテーマを探求する予定です。

• 顧客およびユーザの満足
• 競争優位性の獲得手段としてのベロシティとアジリティの向上
• Taylor主義を超越した、顧客と従業員と取引先の高度なコラボレーション

InfoQはJez Humble氏にインタビューして、継続的デリバリとその適用を通じて企業が手にするITのパフォーマンスとメリット、パフォーマンス面での継続的デリバリの影響について聞くとともに、継続的デリバリの導入を望む企業へのアドバイスを求めることにした。

InfoQ: 継続的デリバリとITパフォーマンスの関係を調査しようと考えたきっかけは何だったのですか？

Jez Humble: 2010年に書籍で紹介された継続的デリバリは、議論の対象からメインストリームへと移り、現在は大手金融サービス企業や政府機関が取り上げるまでになりました。しかし私は、継続的デリバリのどの部分がなぜ重要なのかを理解したいと思い、そのメリットを探求する定量的な枠組みを構築しようと考えたのです。ビジネスパートナであるNicole Forsgren博士とGene Kim氏、Puppetの素晴らしいチームとの“DevOps Research and Assessment”の取り組みは、私のこの野心的な期待をはるかに越えたものになりました。

私たちは、ITパフォーマンスをモデル化するための統計的に有意な方法を確立し、それを用いることで、継続的デリバリのプラクティスの導入がより高いITパフォーマンスを実現すること、それがより高いテンポ – リリース頻度とリードタイムによる測定値 – とより高度な安定性を並立すること、この２つを示しました。

InfoQ: 継続的デリバリの導入は、企業にどのようなメリットがあるのでしょう？

Humble: 私が継続的デリバリのWebサイトで説明しているように、最大のメリットであり、継続的デリバリを企業が取り入れる元々の動機となっているのは、リリースのリスクが低いことです。Dave Farleyと私が本を書いた時の大きな目標のひとつは、高度なエンタープライズシステムの新バージョンのリリース作業を、普通のビジネス時間内に可能なものにすることでした。複雑に構成された(一般的には)手作業を、ダウンタイムが必要な夜間や週末に実施する必要をなくしたかったのです。

さらに、これと同じテクニックは、ソフトウェア品質の向上や市場提供時間の短縮、リリース頻度の向上、実施中のデリバリコスト低減なども可能にします。変更のプッシュアウトに関するトランザクションコストを大幅に削減することで、ソフトウェアデリバリプロセスの経済性は大きく変化し、小規模のバッチによる作業で十分なものになりました。このようにして継続的デリバリの原則とプラクティスは、A/Bテストや迅速なデリバリ、ユーザのフィードバックに基づくMVPの急速な発展といったリーンスタートアップ運動が提供するものとして、多くのテクニックにおいて必要不可欠になったのです。

その中でも興味深いのは、継続的デリバリがバーンアウトを削減し、より幸福なチームを作り、組織の文化を向上させるものであるということを、私たちの調査が示している点です。万能薬だと言うつもりはありません – 継続的デリバリには相当量の投資が必要ですし、ライフタイムに渡って大きく進化する可能性のある製品やサービスにのみ適したものなのです。

InfoQ: ITのパフォーマンスに最も大きな影響があるのは、どのプラクティスですか？

Humble: 包括的な自動テストと継続的インテグレーションが最も大きく、その次に重要なのがコードとインフラストラクチャのバージョン管理です。継続的デリバリもITパフォーマンスに対する影響が大きく、約1/3が差異を生じると言っています。

しかしながら、これらの技術的プラクティスには投資が必要であり、XP(Extreme Programming)の重要性が喧伝されて15年以上経った現在でさえ、大部分のチームが採用していません。多くのチームが、自分たちのミッションクリティカルなサービスに対して、いまだ包括的な自動テストの信頼性と保守性を活用できていないのが現状です。継続的インテグレーションを実践していると言うチームの多くは、実はそうではありません。実際に継続的インテグレーションを実践しているかどうかを確認するテストがあります – 開発者が最低でも1日1回、共有trunkないしmasterにプッシュしているか？コミット毎に自動ビルドとテストが実行されているか？ビルドが失敗したとき、通常は10分以内にフィックスされているか？この３つの質問に“はい”と答えられる人はほとんどいません。継続的インテグレーションと自動テストは難しく、多くの投資が必要ですが、ソフトウェアデリバリのパフォーマンスに大きな影響があることはデータが明確に示しています。

InfoQ: あまり、あるいはまったく影響しないプラクティスもあるのでしょうか？そうだとすれば、なぜなのでしょう？

Humble: 開発チームに対して外部から変更を行なう承認プロセスは、チームの作業テンポを大幅に減少させるだけでなく、安定性に対してもほとんど肯定的な影響のないことが分かっています。ペアプログラミングやコードレビューといった、内部的な承認プロセスの方がはるかに効果的なのです。これはつまり、インスペクションを通じてコード変更の影響を理解することは非常に難しい、ということだと思っています。ライトウェイトなチーム内承認プロセスによって補完する形で自動テストを活用する方が、リスク管理という面ではるかに優れているのです。

意外に思われるもうひとつの事実は、主に受け入れテストの作成とメンテナンスを行なうQAと、ITのパフォーマンスの間には相互関係がない、ということです。開発者自身が行なうか、あるいはテスタと共同で行なった方がずっといいのです。ここでの私たちの仮説は、開発者が自動テストの作成とメンテナンスに関わることが、ソフトウェアのテスト性を高めるための力となって、結果的にテストの信頼性が向上する、というものです。私の個人的な経験では、開発者が自動テストに関与しない場合、そのテストはメンテナンスが非常に難しいために開発者が意識しなくなり、結果としてフェールが多くなった、ということがありました。

InfoQ: 継続的デリバリの採用を考えている企業に、何かアドバイスはありますか？

Humble: 継続的デリバリは目的地ではなく過程であり、基本的には継続的な改善のためのものです。最初はあなたが達成したいと思う測定可能なビジネス目標を定義し、話し合うことから始めてください。その上で、成功のために必要な時間とリソースをチームに確保するのです。デリバリの改善には一般的に、テストとデプロイメントの自動化に対する相応の投資に加えて、ビルドシステムの再設計とも関わっています。開発者のワークステーション上で容易にテスト可能で、(いわゆる)多大なオーケストレーションを伴わない、簡易な方法でデプロイできるビルドシステムが必要です。ですから、そのための準備をしなくてはなりません。モノリシックなアーキテクチャから継続的にデプロイ可能なサービス指向アーキテクチャに移行するために、Amazonは４年間を費やしています。

そうは言っても、継続的デリバリで最も大きいのは、たくさんの作業をしなくても、大きな改善がローカルで実行できるケースの多いことです。私が継続的デリバリを初めて体験したのは2005年に、少人数のチームで大規模アプリケーションのデプロイの自動化に従事していた時です。そこでは数日のプロセスであったデプロイメントを1時間以内で可能にすると同時に、1秒に満たないダウンタイムと、青/緑デプロイメントパターンを用いた1秒未満のロールバックの実現に取り組んでいました。私たちはすべてbashとcvsを用いて、これを数ヶ月で達成しました。ここで私はもうひとつの点に気付きました。“ツーリングに過度の焦点を置く傾向がある”、ということです。悪いツールを避けることが重要なのは間違いありませんが、よいツールはたくさんあります(しかも無料で！)から、どれを使うかということについて、あまり多くの時間や注意を払うべきではありません。それよりも、アーキテクチャや文化に目を向けてください。