DevOpsの価値: DevOps=自動化、ツールだけでは無い

DevOpsとアジャイル 、CI/CDについて説明する機会があり、私なりに整理してみたので書き残しておきたいと思います。まずは、「DevOpsってなんだっけ？」からまとめました。特に事業会社の発注側であったりビジネス側のみなさんには、ツールや自動化、プロセスありきのエセDevOpsに惑わされないよう、正しくDevOpsを理解してほしいと願っています。

下図が、私のDevOpsの理解です。ここに至った流れとどのようにDevOpsを捉えているかを解説します。

この記事のターゲット読者

・これからDevOps導入を考えている方々(特に事業会社の発注側であったりビジネスサイド)
・DevOpsについて調べ始めた方々

DevOpsってなんだっけ？

DevOpsの定義を調べてみましょう。すると、アジャイルの「アジャイルソフトウェア開発宣言」やスクラムの「スクラムガイド」のように、一つの決まった明確な定義や原則があるわけでは無いことがわかりました。

GoogleのDevOpsのサイトではDevOpsが次のように解説されています。

DevOps とは、ソフトウェア デリバリーの速度とサービスの信頼性の向上、ソフトウェアの関係者間で共有するオーナー権限の構築を目的とする、組織的で文化的な仕組みです。（https://cloud.google.com/devops）

Googleは、DevOpsをデリバリースピードとサービス信頼性の2つの目的であると謳っています。また、組織・文化のムーブメントと言っています。自動化やツールのことは定義には言及されておらず、テクノロジーのムーブメントではないことがポイントです。

AWSでは、どのように解説されているでしょうか。

DevOps では、従来型のソフトウェア開発と、インフラストラクチャ管理プロセスを使用するよりも速いペースで製品の進歩と向上を達成し、企業がアプリケーションやサービスを高速で配信できるように、文化的な基本方針、プラクティス、ツールが組み合わされています。この高速化により、企業は顧客により良いサービスを提供し、市場競争力を高めることができます。（https://aws.amazon.com/jp/devops/what-is-devops/）

AWSは、カルチャー、プラクティス、ルーツによりソフトウェア開発のスピードを向上し、より良いサービスを提供することで企業の競争力を高めることと定義しています。目的はビジネス志向であるということです。

最後に、ガートナーのDevOpsの解説を見てみましょう。

DevOpsはITカルチャーの変化であり、高速なITサービスの提供をシステム指向のアプローチであるアジャイル 、リーンのプラクティスに焦点を当てている。DevOpsは人（および文化）を強調し、運用チームと開発チームのコラボレーションの向上を目指している。DevOpsの実装にはテクノロジーを利用します。 — 特に、ライフサイクルの観点でプログラマブルで動的なインフラストラクチャーを活用できる自動化ツールです。（https://www.gartner.com/en/information-technology/glossary/devops）

ガートナーもやはり、DevOpsはカルチャーであると言っています。また、それはチームのコラボレーションと自動化ツールと言ったテクノロジーによって実装されると言っています。

まとめると、「DevOpsは、ビジネス目標を達成するために、より良いプロダクトやサービスを高速、 高頻度、 高品質でマーケットにタイムリーに提供し続ける、伝統的なDev（開発）とOps（運用）を超えた組織／文化に変革する活動」と定義できると思います。

DevOpsの実現の要素としては、「 カルチャー × プロセス × テクノロジー（ツール）」の３つが重要であることがわかります。

DevOpsの定義であるように、DevOpsは方法論や管理手法ではないと思っています。これまでの伝統的なウォーターフォール型の開発方法論やITILの管理手法に対して、DevOpsをより優れてた開発方法論や管理手法として採用しようとすると、具体的に何をすれば良いか分からず、大変戸惑うことになると思います。そういった中から出てくる”DevOpsあるある”のありがちな誤解をいくつか確認しておきましょう。
・「DevOpsは、自動化である」と言った論調の記事やツールベンダーの提案があります。当然、テクノロジー（ツール）もDevOpsの要素の一つですが、それだけではありません。ツールを導入することが目的になってしまう魂の無いDevOpsは失敗します。
・「他でうまくいっているDevOpsのプロセスを導入すれば成功する」こともありません。方法論ではなく考え方なので、それをもとに各組織にあった独自の方法を自分たちで作り出さないといけません。他でうまくいった事例をそのまま自分たちに当てはめてもうまくいかないと思っていた方が良いです。
・「DevOpsはウォーターフォールやITILといった古いやり方と対立する」ということもないのです。なぜなら、DevOpsは、手法ではなく考え方・文化なので旧来の方法論や管理手法と対比する軸にはないと思っています。
・「DevOpsは、スタートアップのためのものである」といったことはありません。既存の事業を持った企業でも、DevOpsへの変革に成功している例はいくらでもあります。

結局のところ、「ビジネス目標の達成というゴールに対して、より効果的と思える活動をするために、カルチャー、プロセス、テクノロジーの３つの要素（どのようなプロセス（方法）で、どういったテクノロジー（ツール）を活用し、どのようなカルチャー（組織とその文化）を浸透させるか）の観点から改善をつづけ」ねばなりません。

なぜDevOpsが生まれたのか？

いったん、DevOpsの成り立ちと歴史を簡単におさらいしておきたいと思います。最初にDevOpsの考えが発表されたのは、2009年の「Velocity 2009」というイベントでFlickrのスタッフが行ったプレゼンテーション「10 deploys per day : Dev&Ops cooperation at Flickr」と言われています。

今、DevOpsのムーブメントが起きているのは、デジタルネイティブカンパニーの出現により、彼らだけでなく既存の企業も含めて顧客やマーケットの変わっていくスピードへの追従を求められていることにあります。VUCAの時代と呼ばれていますが、今までのようにしっかりと計画を立ててビックバンでプロダクトやサービス、システムをローンチする手法では対応できなくなっています。素早く作って、市場に投入し、試して、フィードバックを元にさらに改善するサイクルを高速に回せないと生き残っていけないのです。

※VUCA（ブーカ）：Volatility（不安定さ）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧さ）

その素早いサイクルの阻害要因として、「運用」と「開発」の対立問題、「運用」から「開発」へのフィードバックができないことがあります。それに対する答えとしてDevOpsの考え方が広まりました。

DevOpsはどのようにして機能するか？

実際に、DevOpsを自分たちのチームに適用した時に感じたポイントを紹介したいと思います。以下の図を私は、「教科書DevOps」と呼んでいます。開発・運用のサイクルと各ステップがあわらされています。それ自身に違和感は覚えないのですが、このプロセスとそのためのツールを実装すればDevOpsが実現できるかというと、それは難しいです。

私たちが、実際にDevOpsをインプリする中で感じたポイントを強調したサイクルが以下の図になります。

（１）Dev（開発）→Ops（運用）方向のソフトウェアの開発・デリバリー
効果的な開発、QA、デプロイ、リリースでプロセス、ツールを実装する時に、QA（品質保証）が肝になります。QAには、機能が正しく動くことだけでなく、性能、セキュリティ、コンプライアンスも含みます。QAの視点を常に持ち、CI／CDのパイプラインのたゆまぬ改善がDevOpsの成功に導きます。

（２）Ops（運用）→Dev（開発）方向のフィードバックループ
開発チームに価値のあるプロダクトバックログを供給するためには、運用で収集したメトリックとその分析によるビジネスゴールに向けたフィードバックループが必須です。DevOpsの目的は、あくまでもビジネスの成功であって、ITはそれを支えます。どれだけ高速に高品質に開発ができたとしても、プロダクトバックログの質が悪ければ、高速にゴミの山を開発しているだけで、全くビジネス価値を生んでいないことになります。

というわけで、上記のような「Biz Dev QA Ops」の捉え方に至っています。

DevOpsを支える要素

DevOpsを支える要素として、CLAMS（クラムズ）を紹介します。CLAMSは、Culture（文化）、Lean（リーン）、Automation（自動化）、Measurement（測定）、Sharing（共有）です。

Culture（文化） – コラボレーションとコミュニケーションを推進するための変革を負う
Automation（自動化） – バリューチェーン内から手作業のステップをなくす
Lean（リーン） – リーン原則の採用により，サイクル周期を高める
Measurement（測定） – すべてについて計測し，データをサイクルの洗練化に活用する
Sharing（共有） – 他者が学べるように，経験や成功の可否を共有する

DevOpsのサイクルは、CLAMSの要素に支えられます。

次回予告：
続いて、以下の内容のコンテンツを追加していきたいと思っています。

・どこから手をつけたら良いのか？
・DevOps、アジャイル、CI／CDの関係

最後まで、お読みいただきありがとうございました。