最近身の回りで DevOps について話し合う機会が多くなりました。そこで、自分自身でも色々考えてみたので、考えの整理を含めてブログに記したいと思います。

今更か・・・

DevOpsの起源は Velocity2009 でflickr技術者の語った「10 deploys per day」であるとされています。
そう、現在が2016年・・・7年も前の出来事です。と同時にまだ7年前の出来事です。
オブジェクト指向について考えてみれば、オブジェクト指向プログラミング言語の元祖的存在であるSmallTalkは1972年生まれです。そんなオブジェクト指向も2016年現在、いまだに新卒エンジニアが最初に勉強する要素であり、熟練エンジニアの中にもエセOOな人間が多数いる状況だと思います。
こんなに、技術の進歩が速いソフトウェア業界においても、クラスライブラリの流行り廃りのようなレベルの問題ではなく、もう少し上のレベルのソフトウェア開発・運用テクノロジーに位置する DevOps は、その可否判断、広まりには時間がかかるものだと思います。

www.youtube.com

そもそもDevOpsとは何者か？

DevOpsには厳密なる定義がありません。
対してアジャイルには厳格なる「アジャイルソフトウェア開発宣言」が存在します。

agilemanifesto.org

また、オブジェクト指向には「３大要素」や「SOLID原則」といった、厳格な定義が存在します。

しかし、DevOpsには厳格な宣言や定義はなく、長らくモヤモヤ感（今も？）を持った存在であり続けました。
DevOpsの代表的なキャッチフレーズは、その起源である「10 deploys per day」に事を発する内容であり、「コマンド一つで数千コンテナにデプロイできちゃう」とか「１ヶ月に数万デプロイできちゃう」とか「数千のサイトを１人で数分でデプロイできちゃう」とかいう話があがります。
このような話は派手なのですが、反論として、「1日に何回もデプロイする必要はないんだけど」という話が出てきます。確かに、特にエンプラ系開発では1日数回のデプロイとか必要ないし、顧客（エンドユーザー）は嫌悪感を示すでしょう。1日10回デプロイするよりも、じっくりテストして1週間に1回デプロイでいいよ、もしくは不具合が出るまでアップデートデプロイしないでほしい、な感覚なのだと思います。
DevOpsにおいて、私個人的にはデプロイ回数にフォーカスする必要はないのだと思います。デプロイ回数の実現は「目的」ではなく「結果」なのだと思うのです。

DevOps実現でもたらされるもの

10 deploys per dayを実現するためにはDevとOpsのプロセスの自動化が必須です。手でビルド、手でテスト、上司がエビデンスを目で確認、社内稟議承認を受ける、運用管理者が手でデプロイ・・・こんなことをやっていては高速なデプロイサイクルは実現できません。つまり、自動化できる部分は自動化して作業効率を上げ、自動化可能な単純作業工数を削減しようよ、なのだと思います。

高速自動デプロイできるということは、イコールロールバックも自動で高速にできることを表します。
問題があったら、すぐに戻せる状態を担保します。もちろん、気軽にデプロイしてエラー発生→顧客のビジネスが停止→ロールバックデプロイ、ということを繰り返していては、高い顧客満足度を得ることはできません。そして、デプロイサイクルを早くするより、厳密なテストをしてからデプロイしてよ、となるのは非常によくわかる話です。しかし、ネガティブに考えるのではなく、ポジティブに考えると、正しきDevOpsな環境においては「ビルド・テスト・デプロイ」を自動化することで、一定以上の品質のソフトウェアを担保しているはずです。ですから手動で行ったら、もっとミスが出る、もしくは、もっと長いサイクルでのデプロイしかできないのだと思います。
それから「本番環境からの学び」という言葉がDevOpsでは取り上げられます。実際のところ、それは大いにあると思います。でもお堅いエンプラ顧客なシステムにおいては、本番環境で学ぶなよ！開発・検証環境でしっかり学んでから本番に来いよ！ではあるとも思います・・・でも本番でしか学べないことがあるのも確かだと思います。そんな本番で深刻な事態が発生したら高速ロールバックでご勘弁を的な・・・
それから、私が属する会社のプロダクトでいうと、それらは社内システムとしても利用しています。このようなケースは世の中ではレアケースだと思いますが、自社環境には高速なデイリーデプロイで不具合の早期発見を促す、その後ウィークリー顧客環境にデプロイ、とかも考えられるかと思います。それからWindows10のInsiderPreview的な考えで、早期実装公開を求める顧客とそうでない顧客とでデプロイ計画を異なるものにする等もあるでしょう。いずれにしても、しっかりした自動テスト化が構成されていれば、一定レベル以上の品質は担保しているという前提を考えることもできます。

DevOpsするためにはOO（オブジェクト指向）にまで遡った「知」が必要である

DevOpsは、デプロイまでのプロセスを自動化することが前提といえます。Chefを使ったりPowerShell DSCを使ったり、そのような先進的なツールを使って、デプロイを自動化します。
そして、デプロイに限らずDevOpsのCI（continuous integration）を実現するには、本質的にはビルドからテスト、デプロイまでの一連のプロセスに対し、継続的な自動化を行う必要があります。
そこでアジャイルにつながります。デプロイ以前の「テスト」に関しては、アジャイル開発の下支えとなる要素の1つです。テストコードが用意されている（TDD開発等）事により、アジャイルの「柔軟な変更を受け入れる」思想に対して、一定の品質を保ったままのプログラムが維持可能となります。
そして自動テストが可能なプログラムというのは、OO（オブジェクト指向）の世界に通じていきます。つまりデザインパターンでGoFが語った「プログラムはオブジェクトに対してではなくインターフェイスに対し行え」であったりSOLID原則に即した実装を行うことで、テスタブルなコードとなります。テスタブルなコードとは、個々のクラス・メソッドは最適な責務を担当しており、適度の粒度であり、適度な疎結合であり、DIなテクニック等をサポートしたものです。
つまり、「すべての道はローマに通ずる」ではないけれど、DevOpsという概念の下支え要素は40年近く前のOO技術にまでさかのぼっていきます。

DevOpsが実現できるケース

マイクロソフト牛尾氏は「米国では普通に金融機関でもDevOpsだよ！」と語っておられますが、やはり日本の現場においては、典型的な請負開発ではDevOpsは難しいと思います。要件定義段階、もしくはもっと早い段階で、実装すべきものをコミットすることを求められてしまいます（いや、これがウォーターフォールなんだけど；；）。

私が属する会社の場合、自社プロダクトサービスの提供、になります。このようなケースでは、比較的、十分にアジャイルやDevOpsできる環境なのだと思います。

通常の顧客システムの構築においては、顧客も含めDevOpsへの理解、そして顧客とDevとOpsが信頼関係を築くことが重要なのだと思います。そして現場レベルで「俺が責任取るから」と言ってくれる、変化を望み、受け入れ、責任をもって会社や上司を動かしてくれる一定以上の権力を持った存在が必要な気もします。

ウォーターフォールが前提のクライアントに対して、どのようにDevOps・アジャイルな開発スタイルと契約を求めるべきかは・・・残念ながら私も学ばせていただきたい分野なのです・・・