目次

はじめに

DevOpsの導入によって業務を加速させる組織が、大企業にもクラウドネイティブ企業にも続々と出てきています。しかし、「DevOps」という用語が正確に何を意味するのかについては、いまだによく理解されていません。DevOpsとは文化なのか、ムーブメントなのか、手法なのか、理念なのか。それとも、こうしたもののいくつかが混じり合ったものなのか。あるいは、人によって意味するところが違う言葉なのでしょうか?

DevOpsをどのように定義するかにかかわらず、DevOpsを成功させるまでには長い道のりが必要なことは疑いありません。そして、あなたが今その道のりのどこにいるとしても、我々は次のようなDevOpsに関する基本をお伝えすることで役に立てればと考えています。

  • DevOpsとは何か?
  • DevOpsはどこで生まれたのか?
  • DevOpsが必要になる背景・問題は何か?
  • DevOpsはどのように「機能」するのか?
  • 現在、DevOpsはどの程度普及しているか?
  • DevOpsが導入される理由は何か?
  • どのようなメリットがあるのか?

第1章：DevOpsとは何か

「DevOps」という用語は、後にこの分野の権威の一人となったPatrick Deboisが2009年に考案した造語です。「development（開発）」と「operations（運用）」を組み合わせた言葉で、一般に「DevOps」と言われたときに、それが正確に何を意味するのかを理解するためには、ここが出発点になります。注意したいのは、DevOpsとは何らかのプロセスやテクノロジー、基準を指すものではないということです。熱心な信奉者の多くは、DevOpsは「文化」だと言い、New Relicもこの考え方に賛成です。また、New Relicでは導入率や将来のトレンドなどのテーマで話をするときに「DevOpsムーブメント」という言い方を使ったり、DevOps文化を導入したIT組織を「DevOps環境」と呼んだりすることもあります。

ここではDevOpsについて詳しく解説していきますが、まずは共通認識となる定義が必要です。New Relicでは、ガートナーによる以下の定義が適切と考えています。

「DevOpsとは、システム志向のアプローチにおいてアジャイル（敏捷）でリーン（無駄がない）な慣行を採用することで、迅速なITサービスを提供することに重点を置いたIT文化の変化を表す。DevOpsは人（と文化）を重視し、運用チームと開発チームとの協働を高めることを目指す。DevOpsの実施ではテクノロジー、特にライフサイクルの観点から見て、プログラム可能性と動性が次第に高まっていくインフラストラクチャを活用できるような自動化ツールを使用する。」

重要なのは、DevOpsの意味が広がってきていることです。現在では、高速のフィードバックループを用いて、機能、修正プログラム、更新プログラムのリリース頻度を高めながら、ソフトウェア開発のライフサイクルを短縮するために使われるプロセス、文化、意識を包括的に表す用語になっています。

第2章：DevOpsの起源

DevOpsの起源については諸説ありますが、DevOpsは決して根拠なくでっち上げられたものではありません。DevOpsはかなり以前にその種が蒔かれ、さまざまな分野の先見性のあるITエキスパートによって育てられてきました。DevOpsの主な起源といえるものは、次の二つの概念です。

  • エンタープライズシステムマネジメント（ESM）： DevOpsの初期の定義にかかわった人々の多くは、システム管理者でした。こうした運用のエキスパートたちは、コンフィギュレーション管理、システム監視、自動プロビジョニング、ツールチェーンアプローチといった重要なESMのベストプラクティスをDevOpsに持ち込みました。
  • アジャイル開発： ある識者は次のように 指摘しています。 DevOpsはアジャイルの副産物と解釈できます。アジャイルソフトウェア開発では、顧客、製品管理部門、デベロッパー、さらに（場合によっては）品質管理部門の密接な協働によって、ギャップを埋め、より良い製品を目指して迅速にイテレーション（反復作業）を行うことが求められます。（中略）［DevOpsで認められていることとして、］サービスのデリバリーと、アプリとシステムがどのように相互作用するかは、顧客への価値提案の基本的な一部でもあり、したがって製品チームはこれらの問題をトップレベルの項目として盛り込む必要があります。この観点から見れば、DevOpsとは単純に、アジャイルの原則をコードの範囲を超えて、提供されるサービス全体にまで拡張したものなのです」。

第3章：DevOpsが必要になる背景・問題

デベロッパーとシステム管理者は常に意見が合うとは限りませんが、会社のビジネス面を担当する顧客に振り回されることがよくあるという点では意見が一致しています。ビジネスユーザーは、一方では新しい機能、サービス、利益などにつながる変更をできる限り早く実現するように要求します。しかしそれと同時に、システムが安定していて、故障や稼働停止がないことも望みます。このため供給側の企業は、変更を迅速に提供しながら不安定な実稼働環境に対処するか、安定はしていても陳腐化した環境を維持するかのどちらかを選ばざるを得ない心境になるという問題が生じます。

当然ですが、企業の経営陣にとってはどちらの選択肢も受け入れられません。さらに重要なのは、どちらの選択肢も、可能な限り最善のソリューションを顧客に提供することができないということです。

デベロッパーは、ソフトウェアのリリースをどんどん加速させたいと考えるものです。そもそも、それが与えられた職務であるのが普通です。他方、運用側は、適切な安全対策がないまま矢継ぎ早に変更を行えば、システムが不安定になり、自分たちの仕事の逆風になりかねないことを知っています。

DevOpsは、このジレンマを解消する目的で考案されました。システム全体の統合性と安定性を維持しながら、すべてのユーザー要件を満たす高品質のソフトウェアを迅速に提供するという共通の目的をもって、ソフトウェアの開発とデプロイメントにかかわるすべての人々――ビジネスユーザー、デベロッパー、テストエンジニア、セキュリティエンジニア、システム管理者など――を高度に自動化された単一のワークフローに統合しようとするものです。

では、こうしたさまざまな異質な集団が協力し合うにはどうすればいいのでしょうか? それは、従来の分野間の境界や役割を越えた、 一連の共通原則に従うことです。例えば、次のような原則です。

  • 期待事項や優先事項と、その指針となる基本的な信念を設定する。
  • チーム内およびチーム間で協働して問題解決に当たる。
  • 共通のプロセスや反復的なプロセスを自動化し、もっとレベルの高い業務に充てる時間をつくる。
  • 本番環境に移行するすべてのものを評価しながら、フィードバックを業務に取り入れる。
  • 関係者全員にデータを共有し、スキルや専門知識の違いを越えて協力して仕事ができる効果的な文化を醸成する。

第4章：DevOps、アジャイル、SREについて

DevOpsにシフトし、システム信頼性エンジニア（SRE）を雇用し、アジャイル性を高めたいという声が企業からよく聞かれます。しかし、これらの用語はどのように相互に関連するのでしょうか?

アジャイル（敏捷）でリーン（無駄がない) とは、各チームが短い開発サイクルと迅速なフィードバックで イテレーション（反復・繰り返し）を行うやり方を指します。アジャイル開発では文化を重視し、どのツールを使用するかにはとらわれません。

DevOpsとは、各エンジニアリング組織が部門横断的なチームを活用して協働することです。DevOpsは文化から始まり、ツール使用へと進んでいきます。

システム信頼性エンジニアリング（SRE） とは、エンジニアリング組織が、ソフトウェアエンジニアリングの意識を持つ人に拡張性の高い運用を任せ、 自動化 を進めることです。SREはツール使用に始まり、文化へと進んでいきます。

DevOpsの変形 （「SecDevOps 」など）では、ソフトウェア開発ライフサイクル（SDLC）の早い段階で、別の組織や慣行が挿入されたり、追加されたりします。こうしたさまざまな形態のDevOpsが広まっていることは、現代の組織において部門間の統合が高まっている証拠です。

human systems versus technical systems diagram

第5章：DevOpsはどのように「機能」するのか

あらゆる文化がそうであるように、DevOpsにも同じ目的を目指す多くのバリエーションが含まれます。しかし、いくつかの機能はほぼすべてのDevOps文化に共通しているという点では、大部分の識者の意見が一致しています。それは、協働、自動化、継続的統合、継続的デリバリー、継続的テスト、継続的監視、迅速な改善といった機能です。

協働

開発チームとIT運用チームは、互いに責任をなすりつけ合うのではなく、協力して仕事をします。この二つのチームの間には、仕事の推進力となる要因が異なるため意識のずれがありましたが、DevOpsはIT組織の枠をはるかに越える範囲に広がります。協働する必要があるのは、ソフトウェアのデリバリーに関わる全員（開発と運用だけでなく、テスト、製品管理、経営陣を含むすべてのチーム）だからです。

「DevOpsの成功の基盤は、より迅速に、効率的に、効果的に物事を成し遂げるために、企業全体の各チームや個人がいかにうまく協力するかにある。」

—トニー・ブラッドリー「DevOpsにおける協働の拡張」（DevOps.com）

自動化

DevOpsは自動化に大きく依存します。つまり、ツールが必要だということです。独自に構築するツール、購入するツール、オープンソースのツールなど。そして、これらのツールがばらばらに散在しているだけではありません。DevOpsでは、ソフトウェアの開発とデプロイメントのプロセスの最初から最後までの広い範囲を自動化するためのツールチェーンが必要になります。

注意：DevOps関連のツールは実に素晴らしいので、DevOpsは単なるツールの集まりとみなされてしまう傾向があります。ツールに依存するのは確かですが、DevOpsとは決してそれだけのものではありません。

継続的な統合

DevOps文化においては継続的な統合がみられるのが普通です。DevOpsはアジャイル文化から生まれたものであり、継続的な統合はアジャイル手法の基本原理だからです。

「DevOpsの基本は継続的統合（CI）です。CIとは、グレイディ・ブーチが考案、命名した手法で、チーム内のすべてのデベロッパーからのソースコード更新を、共有のメインラインに継続的にマージしていくものです。この継続的なマージにより、各デベロッパーが持つソフトウェアプロジェクトのローカルコピーが、他のデベロッパーが新しいコードを追加していく間に大きくかけ離れたものになり、深刻なマージ競合が生じるのを防ぐことができます。」

—アーロン・コイス「DevOpsにおける継続的統合」（カーネギーメロン大学ソフトウェア工学研究所のDevOpsブログ）

アジャイル開発における継続的統合の原則は、開発チームに文化的な影響を及ぼします。デベロッパーに自分の成果物を他のデベロッパーの成果物と高い頻度で（少なくとも1日1回）統合させるようにすれば、統合に関する問題や競合を、ウォーターフォール開発の場合よりもはるかに早い段階で見つけることができます。ただし、このメリットを実現するには、デベロッパーがコミュニケーションを取り合う頻度を飛躍的に高める必要があります。一つのモジュールをたった一人で何週間も、あるいは何カ月もかけて書き上げてから、満を持して世界に送り出す――という、孤独な天才プログラマーのイメージとは正反対の行動です。オープンで頻度の高いコミュニケーションは、DevOpsの環境で効果を発揮します。

継続的テスト

DevOpsのテストの部分は見過ごされがちですが、おろそかにしていると痛い目にあってしまいます。ガートナーは次のように注意を呼びかけています。「ソフトウェアエラーが招くコストと影響が拡大していることを考えれば、既存のユーザー体験を破綻させかねないバージョンをリリースしたり、セキュリティや信頼性やコンプライアンスに関わる新たなリスクに組織をさらしかねない新機能を導入したりすることは許されません」。継続的統合と継続的デリバリーがDevOpsで扱われる範囲の大部分を占めている現状の中で、継続的テストはその陰に隠れながら、DevOpsの重要な要素としての位置をつかみつつあります。

継続的テストとは、単なる品質管理（QA）機能とは違います。それはむしろ、開発環境で始まります。デベロッパーがQAチームにコードを渡して、「よろしく」といえば済む時代は終わりました。DevOps環境では、品質は全員の責任です。デベロッパーは品質を十分に意識したコードを構築し、テストデータを提供します。QAエンジニアは自動化テストケースを作成し、テスト環境を構築します。

QA側に求められる重要な要素は、スピードです。そもそもQAサイクルに何日も、何週間もかかっていては、ウォーターフォール開発時代の延々と長い開発スケジュールに逆戻りです。テストエンジニアは、テストプロセスの大部分を自動化するだけでなく、テスト方法論の見直しも行いながら、短納期という課題に対応しています。

「継続的テストは、各アプリケーションが組織に与えるビジネス上のリスクの評価に役立つ意思決定の中枢システムを作り出します。継続的テストは、一貫して適用することで、開発チームがビジネス上の期待に応え、経営陣に可視性のある情報を提供するための指針となります。それによって経営陣は、十分な情報に基づいて妥協点を探った意思決定をし、リリース候補版のビジネス価値を最大限に引き出すことができるのです。」

—「ITリーダーのための継続的テスト」 パラソフト

意外かもしれませんが、テストとQAに関しては運用チームにも重要な役割があります。運用チームは、監視ツールが導入され、テスト環境が適切に構築されていることを確認する役割を担うことができます。また、機能テスト、負荷テスト、ストレステスト、リークテストに参加し、本番環境にある類似のアプリケーションの使用経験に基づく分析を提供することもできます。

継続テストから得られるメリットには、そのために努力する価値が十分にあります。DevOps環境において、テストチームはデベロッパーが品質とスピードのバランスをとるのを助けます。自動化ツールを利用することで、テストのコストが抑えられ、テストエンジニアが時間を有効に使えるようになります。何より大きいのは、継続テストを行えば、統合テストをプロセスの早い段階で実施できるため、テストサイクルが短縮されることです。

継続的テストでは、従属サービスを仮想化することでテストのボトルネックをなくすことができます。さらに、システムの変更に応じて容易にデプロイ、共有、更新ができる仮想化テスト環境の構築が簡素化されます。こうした機能によってテスト環境のセットアップとメンテナンスのコストが低減し、統合テストをライフサイクルの早い段階で実施できるようになることで、テストサイクルが短縮されます。

継続的デリバリー

アマゾン・ウェブ・サービス（AWS）の担当チームは、DevOpsにおける継続的デリバリーを次のように定義しています。「ソフトウェア開発手法の1つで、コード変更が発生すると、自動的に本番環境へのリリース準備が実行されるというものです。継続的デリバリーは、継続的インテグレーションを拡張したもので、すべてのコード変更が、ビルド段階の後にテスト環境または運用環境（あるいはその両方）にデプロイされます。適切に実装すると、開発者は、標準化されたテストプロセスに合格し、デプロイ準備の整ったビルド成果物を常に手元に持つことになります」。

実際のリリース頻度は、各企業のレガシーや目標によって大きく異なります。DevOpsを活用するパフォーマンスの高い組織は、1日に複数回のデプロイメントを実施しますが、これに対して平均的なパフォーマンスの組織のリリース頻度は、週1回から月1回というところです。

リリースされる内容も大きく異なります。組織によっては、QAチームや運用チームがリリース候補版の優先順位を決めているところもあります。多くはユーザーに直接提供されますが、開発チームに戻されるものや、少数とはいえ全くデプロイされないものもあります。一方、デベロッパーから出てきたものをすべてユーザーに提供し、リアルタイム監視や迅速な改善を通じて、まれに起こるエラーの影響を最小限に抑えようとする企業もあります。各更新プログラムの規模が比較的小さいため、そのうちの一つがエラーを発生させる可能性は大幅に低くなるという点が重要なポイントです。

継続的監視

継続的デリバリーを実践する企業でのリリース件数の多さを考えれば、ウォーターフォール開発で求められる類の厳格なリリース前テストを行うのは不可能です。DevOps環境ではリアルタイムでエラーを発見し、修復しなければなりません。では、どうすればそれができるのか。その大きな部分を占めるのが、継続的監視です。

継続的監視では、ソフトウェアのパフォーマンスと可用性を評価し、安定性の向上につなげます。継続的監視を行えば、問題の根本原因を迅速に突き止め、システム停止を事前に防ぎ、ユーザー側で生じる問題を最低限に抑えることができます。監視機能のエキスパートの中には、サービスの定義に監視を含めるべきだと主張する人もいます。監視はサービスの提供に不可欠な一部だと考えているのです。

テストと同様に、監視も開発段階で始まります。本番環境で監視に使うのと同じツールを開発環境に導入し、本番に移行する前にパフォーマンスに関する問題を検出することができます。

DevOpsでは、2種類の監視が必要になります。一つはサーバー監視、もう一つはアプリケーションパフォーマンス監視です。監視についての話をすれば、必然的にツールについての具体的な話が出てきます。適切なツールがなければ効果的な監視はありえないからです。DevOps関連のツールの一覧（およびその他のDevOps関連コンテンツ）については、 New Relic DevOps Hubをご覧ください。

第6章：DevOpsを導入している企業

DevOpsは、起業したばかりのスタートアップ企業から創業100年の老舗企業まで、至る所のIT企業に浸透しつつあります。 ある調査によれば 、74%の企業が何らかの形でDevOpsを導入しています。

では、どんな種類の企業がDevOpsを取り入れているのでしょうか?　DevOpsのリーダーとして挙げられることが多いのは、Etsy（エッツィー）、フェイスブック、アマゾン、ネットフリックスなど、最初からオンライン企業として創業した「ユニコーン」と呼ばれる企業ですが、現在ではあらゆる種類の企業がDevOpsに参入しています。主流メディア企業のソニー・ピクチャーズ、巨大金融機関のバークレー銀行、建材メーカーのUSGなども、DevOpsの成功事例として大きく取り上げられています。

意外かもしれませんが、先頭に立っているのは大企業で、 81% が組織内の少なくとも一部でDevOpsを採用していると報告しています。中小企業（SMBs）もDevOpsのメリットを享受していて、70%がDevOpsを採用していると答えています。証拠を見る限り、企業の規模そのものはDevOpsの成否を決める要因ではないようです。

政府機関や政府系機関もDevOpsを取り入れています。例えば、アメリカの連邦住宅抵当公庫（通称ファニー・メイ）は、DevOpsを活用した事業変革に乗り出し、「遅々として変わらない組織から素早く変化できる組織」への転換を図っています。

アメリカ政府の特許商標庁もDevOpsに移行し、現在では平均で 週に1,000件の自動ビルド を実行しています。一般調達局（GSA）では、プロダクション・コンテナ、自動ワークフロー、マイクロサービスなどを導入し、 プロジェクトの質向上とデリバリーの迅速化を目指して局内のIT運用を最新化しようとしています。

しかし、クラウド技術やコンテナ技術の隆盛によって世界中でDevOps導入が進んだとしても、DevOpsのエキスパートで、関連著書もあるジーン・キムは、DevOpsにはまだ大いに成長の余地があると言います。そうした成長は多くの場合、すでに足掛かりを築いている組織において、DevOpsが新たな開発の取り組みの推進力になるという形で進みます。

「現在では、DevOpsは決してグーグルやアマゾン、フェイスブック、ネットフリックスなどのユニコーン企業だけのためのものではなく、むしろ、あらゆる技術系組織、特に大規模で複合的な組織のためのものであることを示す証拠があります。私が非常にうれしく思っているのは、そうした組織が、これまではユニコーン企業だけに典型的にみられていたのと同じ種類の成果を上げていることです。」

—DevOpsエキスパート　ジーン・キム氏

第7章：DevOpsが受け入れられている理由

DevOpsは、開発、運用、テストの各部門を含めたソフトウェアチェーンに連なる全員のためのものです。さらに、DevOpsは、ソフトウェアを収益につなげようとする管理職や、最終損益が気になる経営陣など、企業のビジネス面に携わる人々にも関係します。それぞれの部門から挙げられたメリットを以下に紹介しましょう。

デベロッパー

プログラマーにとっては、自動プロビジョニングが大きな利点です。文書業務も、長い承認手続きも、ITチームがサーバーを用意してくれるのを待つ必要もなく、時間を一切無駄にせずに自分で開発環境を立ち上げられるからです。すべての適切なリソース（演算能力、記憶領域、ネットワーク、アプリケーション）を備えた作業環境をほんの数分で用意できれば、デベロッパーの仕事のしかたが変わります。創造力とイノベーション能力をこれまでよりはるかに大きく発揮できるようになるのです。複数の選択肢を試したり、さまざまな異なるシナリオを実行したり、コードを徹底的にテストしたりする作業がずっと簡単になります。

初めてDevOps環境で仕事を始めたときに、多くのデベロッパーが目を開かれた思いになるのは、これまで謎だった「運用」と書かれたブラックボックスの中で何が起きるのかがわかるためです。これを理解できたことで、デベロッパーは運用チームと協力しながら効果的に問題解決に当たれるようになります。問題の解決が早くなり、他のことに気を取られることが少なくなります。何より有り難いことに、突然サイトがダウンして、夜中に運用チームから大慌てで電話がかかってくることはもうありません。そのおかげでデベロッパーは仕事に対する満足度が上がり、生活の質も向上します。

運用

システム管理者とは、いつもシステムの安定性ばかり気にしているものだと広く信じられています。実際、その通りです。彼らにとっての悪夢のシナリオは、リリース版のソフトウェアが実環境にデプロイしてからわずか数秒でシステムダウンを引き起こし、デベロッパーは責任逃れ（「もう渡したんだから、そっちのものだろう?」）、ユーザーは多かれ少なかれサービスを利用できなくなり、すぐに適用できる効果的な解決策はどこにも見つからない――というものです。

DevOpsの手法を初期に採用した人々は、デベロッパーが関わることが増えれば、実際にシステムの安定性が高まることを発見しました。重要なのは、個々のプログラムを小さくし、リリースの回数を増やせば、システム内の変動が少なく抑えられ、取り返しのつかないエラーが発生するリスクが低くなるということです。さらに良いことに、比較的小規模なリリース版であれば、夜間や週末を使わなくても、皆が職場にいる昼間のうちに作成できるため、すぐに問題解決に当たることができます。

自動化も、手作業で起こりがちな人的ミスをなくすのに役立つ上、定型的な作業にかける時間が減るというメリットがあります。システム管理者にも生活の質に関連する問題があり、決まりきった作業にとられる時間が減れば、新しいスキルを習得したり、キャリアアップのチャンスをつかんだりする余裕が生まれ、睡眠時間やプライベートな時間を邪魔されることも少なくなります。DevOps環境では、運用チームがツールに依存する範囲が従来の環境よりはるかに広く、デプロイプロセスの各部分を自動化するためのツールやスクリプトを独自に構築することがよくあります。

以上のようなメリットを考え合わせれば、最近のDevOpsエンタープライズ・サミットの参加者に「運用責任者」の肩書を持つ人が最も多いのもうなずけます。

テストエンジニア

DevOpsが企業のテスト部門に与える影響は、非常に大きなものがあります。ある評者は次のように述べています。

「ここは、ほぼ連続した複数の反復的なリリースが、数日間隔で、場合によっては分単位の間隔で行われる世界です。そのすべてが最終的な実稼働環境にデプロイされ、要求の多い有料ユーザーの手に渡ります。それほど多くのソフトウェアが、テスト時間がほとんどなく、しかも高品質を求めるプレッシャーが大きい中でリリースされる――理論的に見て、自動化テストがこれほどふさわしい事例がかつてあったでしょうか?」

DevOpsではソフトウェアの新しいテスト方法が求められ、テストエンジニアのイノベーション能力が試されます。自動プロビジョニングを利用すれば、テストエンジニアは実稼働環境とほぼ同じテスト環境を用意できるため、より正確なテストを実施でき、新しいリリース版のパフォーマンスをより的確に予測できます。他の部門と同様に、テストエンジニアも自動化と協働の効果で生産性が高まります。

プロダクトマネージャー

厳密にいえば、DevOpsは企業のIT部門だけに関するものです。しかし、プロダクトマネージャーや、マーケティングやビジネス部門の責任者も、 非常に大きなメリットを得ることができます。

  • フィードバックが早くなる：新しい製品や機能が顧客にデリバリーされると、すぐにプロジェクトマネージャーのもとに実際的なフィードバックが届き始めます。
  •  対応が早くなる： DevOpsでは継続的デリバリーによって、顧客のニーズに対応した新機能が市場に投入されるまでの時間が大幅に短縮されます。
  •  無駄やリスクが減る： 次回の大規模リリースを待たずに問題の修正や新機能の開発ができるため、開発リソースを効率的に使えます。

では、少し詳しく解説しましょう。DevOps環境では、ビジネス面のステークホルダーが開発プロセスに及ぼす影響が大きくなります。DevOpsの協働の精神のおかげで、デベロッパーはビジネス面の要件に気を遣い、プロダクトマネージャーと関係を深めるようになります。また、DevOpsの効果で、プロダクトマネージャーのもとには、新しい価格設定や機能、製品バンドルについてのフィードバックが即座に帰ってくるため、さまざまなバリエーションをテストして、それぞれの有効性を評価することができます。

各製品ラインの責任者は、DevOpsを大いに気に入っています。ソフトウェアの市場投入までの時間が短くなり、競争上の優位性を得られるからです。また、DevOpsによってシステムの安定性が高まるため、ユーザーがサービスを利用できない状態になる回数が減り、それによって顧客忠誠度が向上します。高い解約率に悩んでいる企業には、願ってもない解決策です。

経営陣

パトリック・デボイスを始めとするITの達人たちがDevOpsムーブメントを始めたときには、この概念が企業の経営陣にどう受け止められるかはもちろん気にしていませんでした。しかし、今やDevOpsは、その経営陣の間で注目の話題になっています。

経営陣はDevOpsのどこが気に入っているのでしょうか?　一つには、質の高い製品を、従来のソフトウェア開発手法に頼っている競合他社よりはるかに早く市場に投入できることがあります。これは最終損益に影響し、ブランド価値の強化にもつながります。もう一つは、有能な人材を引きつけ、会社に定着してもらうことができる点です。優秀なデベロッパーやシステム管理者、テストエンジニアは、先進的で、できる限り生産性の高い環境で仕事をしたいと考えているのです。さらにもう一つ、開発・運営・QAの各部門が協力して仕事をすれば、経営陣が部門間の対立に巻き込まれるような事態はほとんど起きないため、重点的な事業目標の設定に時間を割くことができ、全員でその目標の達成に向けて邁進することができます。

「業績の高い（DevOpsを採用した）部門の社員は、自社を素晴らしい職場として友人に勧める確率が2.2倍高く、自分の部署を素晴らしい職場環境として友人に勧める確率が1.8倍高い。調査が示すところでは、『従業員エンゲージメントの高い企業は、エンゲージメントの低い企業と比べて収益増加率が2.5倍高い』ことを考えれば、これは意味のある調査結果である。」

—パペット、DORAによる「2016年DevOps状況報告」より

第8章：DevOpsのメリットを得るには

さまざまな信頼できる情報源から、DevOpsで実現された非常に注目すべきメリットが報告されています。しかし、注意が必要です。例えば、誰かが「僕の車はリッター13キロで走る」と言うのを耳にしたとしましょう。もしその車がオフロードを走る小型トラックなら、信じられないほど燃費がいいと言えます。一方、新車のプリウスでほぼ高速道路だけを走っているとすれば、1リットルにつきたった13キロというのはかなり期待外れでしょう。どういう状況での数字かが重要なのです。DevOpsに関しても、改善がみられたという話を耳にしたら、自分の環境では結果は違うかもしれないことを頭に入れておきましょう。

とはいえ、DevOps Research and Assessment（DORA）の2018年DevOps状況報告によれば、DevOpsで高い業績を上げている組織は、業績の低い組織に比べてソフトウェアのリリース頻度が46倍高く、リリースまでに要するリードタイムは2,555倍も速いとされています。ソフトウェアの品質も高く、変更によるエラー率は7倍低くなっています。さらに、システムの安定性への正味の影響は圧倒的にプラス寄りです。プラットフォームがダウンしたとき、業績の高い組織は低い組織より2,604倍も速くサービスを復旧させています。

一つ確かなことがあります。DevOpsを採用したIT専門職は、その熱心な信奉者になる傾向があるということです。Puppet Labsの調査で挙げられている次のような効果を考えれば、その理由に気づくのは難しくないでしょう。

  •  安定性： 業績の高い組織は、計画外の作業や修正作業にかける時間が22%少ない。その結果、新しい機能やコードなど、新規の作業にかけられる時間が29%多い。
  • セキュリティ：業績の高い組織は、セキュリティ問題の修正にかける時間が業績の低い組織と比べて50%少ない。
  • アプリのデプロイメントの速度： 業績の高い組織は1日に複数回のデプロイメントを要求に応じて実施しているのに対し、業績の低い組織が実施するデプロイメントは1カ月から6カ月に1回である。

結論

「DevOpsは目的ではなく、終わりのない継続的な改善のプロセスである。」

—DevOps Research and Assessment創業者兼最高技術責任者（CTO）　ジェズ・ハンブル氏

壮大なDevOps実験が始まってから10年、データは明らかに、DevOpsがすっかり浸透していることを示しています。それには十分に納得できる理由があります。無理だと考える人も当初は少なくありませんでしたが、DevOpsはビジネスユーザーとデベロッパー、テストエンジニア、セキュリティエンジニア、システム管理者を、顧客の要求を満たすことに重点を置いた単一のワークフローに統合することに成功しました。では、なぜ彼らはその気になったのでしょうか?　それは、どの部門にとっても、利益になる何かがDevOpsにはあるからです。デベロッパーとシステム管理者は言い争うのをやめてサポートし合うようになり、誰にとっても血圧が落ち着く環境になります。ビジネス面の責任者は、製品やサービスを販売するのに必要なソフトウェアが手に入るので文句はありません。経営陣は、お気に入りのダッシュボードに表示された収益や顧客満足度、システムの安定性などの指標が、どれも安定して上向きなのを満足気に眺めます。そして、誰もが最高の成果を挙げ、可能な限り最高のユーザー体験を提供することができます。

しかし、このような成果は簡単に手に入るものではありません。システムを順調に稼働させながら、高い頻度でのコードのデプロイメントを成功させるには、システム環境に加えるあらゆる変更を正確に監視する必要があります。 New Relicのプラットフォームは、統合型のアラートとダッシュボードを通じて、デジタルな顧客体験からアプリケーションと動的インフラストラクチャまで、フルスタックの可視性をデベロッパーと運用チームに提供します。これによって、ソフトウェアがどのようにデプロイされ、どんなパフォーマンスをしているかについての理解を、組織内の全員がリアルタイムで共有できるのです。