例えばAmazon.comは、平均で11.7秒ごとにコードをリリースすることで、同時に起きる障害の件数を減らして収益を増やした。対照的に、Netflixはそれほど速いペースではない（開発者がコードをリリースするのは1日に数回程度）にもかかわらず顧客のニーズに対応できていると、ビジュアルコンテンツプロバイダーDresmaの共同創業者シッダールタ・シンハ氏は指摘する。

　「つまり、CI/CDは定期的な機能の更新や継続的な不具合の修正を必要とする製品に最も大きな影響を与える」とシンハ氏は言う。

　同氏によると、コードの変更が日常的な作業になる場合、CI/CDはソフトウェア開発の効率的な手段であり、より頻繁で有意義かつペースの速い開発を実現し、どんなときでも持続的にアップデートをリリースできるようになる。

　ジュラブリョフ氏によると、CI/CDパイプラインを他の手法と組み合わせれば、本番環境で途切れのない変更の流れを保証する一助となる。それは翻って、新しい製品やサービス機能の迅速な展開を可能にするとともに、ビジネスに新しいチャンスをもたらす。

　だが、新技術は新しいIT管理の手段を必要とする。「この分野では複数の動きがある。組織は仕事や組織構造、能力、品質を管理するために新しいアプローチを採用している」と同氏は話す。

　シンハ氏によると、ソフトウェア開発とデプロイのプロセスを一連の段階に分解することは、開発者がすぐにフィードバックを得る助けになる。CIはこのパイプラインの最初の段階として、CI/CDのための基盤を構築する。

　「成功を収めるCIは、個々のソフトウェア開発者がアプリの新しいコードの変更を頻繁に（あるいは毎日）行って、そのアプリケーションの既存コードの破壊や衝突を引き起こすことなく共有リポジトリにそうした変更を統合する手助けができる」とシンハ氏。

　ツールのパイプラインを統合する必要性に加えて、CI/CDは企業文化の変化も要求する。開発者や運用担当者に働き方をどう変えてもらうかは、IT管理者にとっての大きな障壁になる。

　継続的テスト製品を提供するSauce Labsの技術サービス担当ディレクター、マーカス・メレル氏によると、ほとんどの開発チームではソフトスキルと無形の要素が成否を左右することがある。例えば、組織構造やビジネスの優先順位は常に変化するものであり、市場の変化に伴って顧客の行動や製品へのニーズも同じように変化が繰り返される。

　「こうした変化の中で不可欠な変化のサイクルに順応できない、あるいは（さらに悪いことに）順応したがらない優秀なコードの書き手や開発者のチームを持つことよりも、新しいプロセスにうまく順応でき、集団エゴを排除し、同僚からの建設的な批判を受け入れる開発チームを持つことの方が重要になる。だからこそ、CI/CDチームの結成に当たっては、コーディングの才能と同じくらい（それ以上とは言わないまでも）ソフトスキルが重視される」（メレル氏）

　英労働年金省（DWP）は幅広いアジャイルプロジェクトの一部として、コードの変更を加速する目的でCI/CDを使ってきた。

　ロンドンで開かれたカンファレンス「GitLab Commit 2019」で講演したDWPのエンジニアリング戦略担当責任者のアダム・モス氏は、「不具合の修正や政府の政策変更に伴い、われわれのシステムは年間1万以上の変更を行っている」と語った。

　こうした変更はガバナンス構造を伴うウオーターフォール型をベースとしているが、同氏によると、DWPはアジャイル性を高めるためにCDへと移行しつつある。DWPの文化の変化は、同組織がかつて全てをアウトソーシングしていたという事実に起因する。モス氏によると、ビジネスが主導権を持つ必要性が生じ、ITサプライヤーとの契約ではリスクを回避できなくなった。

　DWPは人為ミスを排除するためにInfrastructure as Codeを活用し、コードとしての構成（Configuration as Code）を利用している。このおかげで事前の静的テストが容易になったとモス氏は言う。サーバが同じ構成で運用されていることを確認するために、イミュータブルも利用する。モス氏によると、これによってサーバドリフトのような複雑性の多くを解消できる。

　CI/CDがチームでの取り組みであることを前提として、DWPはスタッフの評価方法を変更した。「スタッフの実績評価はかつて、チームよりも個人の動機付けになっていた。4月の時点でわれわれは、チームのみを評価している」とモス氏は話す。この評価ではチーム全体としての成否が問われる。

　同様にモス氏はIT意思決定者に対し、懲罰規定の再考を勧めている。例えば開発者が作成したコードがITインフラの混乱を引き起こした場合、開発者個人を責めるべきではなくCI/CDプロセスが問題の原因だった可能性がある。

　Sauce Labsのメレル氏は、顧客や同僚の課題をCI/CDチームが認識して共感を深めるほど、そのチームの順応性は高まると語る。

　「自分たちの開発デリバリーチームでさまざまな見方や人生経験を持つことがいかに大切かは、どれほど言っても言い切れない。顧客にはいろいろな人がいる。従って開発チームもそうでなければならない。経歴や人生経験が自分と全く異なる相手の身になって考えることはできない。顧客のニーズにかなうソフトウェアを開発して届けるためには、そのニーズを理解しなければならない。そうしたニーズを理解するためには、そうした相手と同じ見方ができるメンバーがチーム内にいる必要がある」

ビジネスの支持

　AXELOSのジュラブリョフ氏はビジネスに対し、単なるITプロセス以上の存在としてCI/CDに目を向けるよう促している。CI/CDは身軽で機敏な原則、ソフトウェア開発と管理技術、製品管理の手法を含め、もっと幅広い組織的変化を実現するための技術を提供する。

　「デジタル製品の管理は、昔ながらのITシステムの管理とは違う。さらに重要なことに、現代においてそれはITチーム単独の責任ではない。デジタル製品は、技術とビジネスのノウハウが合わさり、製品とサービスのライフサイクルを通じて適用されたときにのみ、効果を発揮する」とジュラブリョフ氏は言う。

　CIO（最高情報責任者）はCI/CDにもっと目を向ける必要がある。Forresterのアナリストが市場動向分析の中で指摘している通り、CI/CDの一つの側面を担うソフトウェアツールは豊富に存在するものの、それを全て組み合わせ、シームレスで自動化されたソフトウェアデリバリープロセスを提供するのは大部分が手作業のプロセスになる。

　必然的に、CI/CDツールチェーンを横断するインテグレーションがいずれは登場する。だがCIOは同時に、ビジネスを横断するCI/CD思考を支えるために、ソフトウェア開発と運用において必要とされる大きな文化的シフトについても考慮しなければならない。