グラム氏が継続的インテグレーション／継続的デリバリー（CI/CD）に取り組み始めたのは2016年だった。DevOpsの理念の一要素として、CI/CDはコードをできるだけ早く本番環境に持ち込むことに重点を置く。大きなまとまりのコードを長期間かけて開発し、テストには時間がかかるが確実性は低下するウオーターフォール方式を含む、それまでのソフトウェア開発のアプローチとは対照的だ。

　「もしもテスターのための大規模なレグレッション計画があるとして、相互に依存する100万もの機能がある場合、それがどのコンポーネントに依存するかを予測するのは難しい。だが小さな機能を1つだけデプロイするのであれば、テストを行って依存関係を簡単に予測できる」とグラム氏は話す。

　そのメリットは非常に大きい。Ciklumは欧州の小売業者Metroと組んで電子商取引プラットフォームを構築した。このプロジェクトでは、本番環境の変更にかかるデプロイリリーススケジュールを、標準的な3カ月から1時間に短縮した。

　「その違いは絶大だ。ただし3カ月間でリリースするのと同じ量の変更を1時間ごとにデプロイしているわけではない。開発者は3カ月のリリーススケジュールよりもずっと早く、ユーザーと本番環境からのフィードバックを得ることができる」（グラム氏）

機能デリバリーの高速化

　カリフォルニア大学バークリー校講師でDevOps Research and Assessment（DORA）共同創業者のジェズ・ハンブル氏は、2010年にCI/CDに関する著書を執筆した。同氏はCI/CDを次のように定義する。「新機能、設定の変更、バグ修正、実験を含むあらゆる種類の変更を、安全かつスピーディーに持続的な形で本番環境あるいはユーザーの手に届けられること」

　ソフトウェアのテストを手掛けるMablが500人を対象に実施した調査によると、回答者の53％がCIを使っていて、25％は導入を計画していた。一方、CDを使っているという回答は38％、導入の計画があるという回答は30％だった。

　DORAが開発者3000人を対象に実施した調査結果報告書「2019 Accelerate State of DevOps」によると、エリートグループと実績の悪いグループを比較した結果、前者がコードをデプロイする頻度は208倍、コードの受注からデプロイまでのリードタイムは106倍、インシデントからの復旧スピードは2604倍だった。

クラウドへの競争

　DevOpsとCI/CDは関係しているものの、この両者を混同してはならないとKPMG Internationalの筆頭DevOpsエンジニア、アリアン・ガッド氏は言う。「DevOpsはどちらかというと、企業文化や思考、働き方に関係している。CI/CDはツールと自動化が主導するオーケストレーションのアプローチだ。組織はCI/CDを使ってDevOps的なやり方で技術プロジェクトを遂行する。CI/CDなしでDevOpsはできない」

CI/CD導入の落とし穴

　CI/CDの導入には問題もある。

　例えば451 Researchが北米と欧州で350社のIT意思決定者を対象として2018年5月に実施した調査によると、半数の組織は一切のセキュリティテストの要素なしにCI/CDを導入していた。

　ガッド氏によると、問題は開発チームがデリバリーのスピードを準備不足と混同する際に起こり得る。「多くの人が、迅速な開発と高速デリバリーが全てだと考える過ちを犯す。だがそうした人は、適切な記録を忘れているので、自分たちが実際に何をしたのかが誰にも分からない」

　ガッド氏は、事前のインフラ最適化と適切なスクリプトの開発に時間をかけるよう勧告する。そうでなければ、チームが後戻りして変更を行う必要が生じ、メリットが失われて、自分たちが推進しようとしているアプローチの評判に傷がつく。

　「最初のうちは、自動化とスクリプトの作成に時間がかかる。だがそれがうまくできれば、それを何度でも好きなだけ繰り返すことができる」（ガッド氏）

スピード調整

　Cytoraは、保険会社による保険契約引き受けの正確化を支援する技術プラットフォームを開発している。エンジニアリング担当ディレクター、ダン・トラン氏は約1年前にCI/CDの導入に着手した。

　最大の教訓は、スピードが全てではなかったことだと同氏は話す。「最初は超高速化してスピードを解き放つことが全てだと思っていた。だが実際には、現時点でできる限り速くすることの方が、それ以上速くすることよりもはるかに大切だった」

　開発チームが使うインフラやツールはさまざまで、DevOpsのどの段階にあるかもそれぞれ異なる。もしもチームのサイクルが2週間から1週間に短縮されたのであれば、それを前進と見なすべきだとトラン氏は言う。「それがその時点で最大限のスピードなら、それで構わない。それを繰り返して次のレベルに上がることができる。準備が整う前に速く行き過ぎたチームは、物事を壊すのも早く、それを修正することができない。大切なのは、できるだけ速くすることであって、それ以上速くすることではない。それが私の学んだ最大の教訓だった」

適切なツール

　CI/CDに対するチームの理解の向上に伴い、ツールも向上する。そうしたツールは「Slack」のような汎用（はんよう）コラボレーションソフトウェアから、開発チームによるモジュール式コンポーネントのワークフロー設計を支援する「Pivotal Concourse」のような技術ツールまで多岐にわたる。

　CI/CDの人気が上昇しているといっても、ソフトウェア開発手法の事実上の標準となるまでの道のりはまだ長い。「ソフトウェア開発者はCDに由来する多くの事柄を融合させて使っている。だがエンタープライズITは包括的で極めて大きく、このコンセプトはまだ非常に新しい。これは初期の段階にある」とトラン氏は話す。

　CI/CDは、従来型の手法よりもソフトウェア開発を飛躍的に加速する。だがこのアプローチを検討しているチームがその恩恵を受けるためには、開発者を教育し、ITチームの企業文化を変えさせ、ツールとインフラに投資する必要がある。