組織論も技術論も両立しているDevOpsは最高

私は米Microsoftで、DevOpsのエバンジェリストとして啓蒙活動をしています。お客様がDevOpsを実践するための支援をしたり、DevOpsハッカソンを開催したりしています。

Microsoft主催のイベントなのですが、目的はDevOpsを広めることなのでMicrosoftの製品を使って下さいといった制限もほとんど無いです。好きなツールを使い、計画を立てるところから開発や運用の自動化までDevOpsの範囲全てを体験するイベントです。

私、DevOpsというものが大好きなんですよ。超かっこいいと思います。と言うのも、以前はアジャイルを専門にやっていたのですが、どうしても人や組織の話が大半になってしまうんですね。「僕もHackしてぇー！」と思っても、職業上出来ないことも多かった。

一方で、DevOpsエバンジェリストをやっていると組織面の話と技術面の話、両方楽しむことができ、それが最高に楽しいですね。

正しくDevOpsを理解してもらうために活動を行う

DevOpsは日本でも数年前から流行ってきてはいます。ただ、本当の意味でDevOpsを理解出来ている人は少ないと思います。DevOpsを実施しているという企業に話を伺うこともあるのですが、細かい話を聞くと「〇〇というツールを導入しています」というような、技術的な話しか出てこないんです。

本当は「ツールを入れたらDevOpsです」ということでは無いんです。そのツールを作っている会社が製品を売ろうとしてそう言っているだけなので、導入するだけでDevOpsが出来るということはあり得ないんです。

ただ、じゃあ何をしたらDevOpsなのかと言うと、実は明確な定義が無いんです。アジャイルだとアジャイルマニフェストというものがあるのですが、DevOpsにはそれがない。だから混乱を招いていて、みんなが好き勝手に言っているんですよ。Microsoftとしてはそれを一度整理して、DevOpsを正しく認知してもらおうと活動をしています。

アジャイルでもリリースサイクルは改善されない

DevOpsのはじめの一歩は、簡単に言うと「アプリケーションをできるだけ早く、安全にデプロイして、継続的に何度も繰り返したい」という話です。

ソフトウェアのリリースサイクルを改善する取り組みは、DevOpsという言葉が出てくるずっと前から行われていました。アジャイルもそれに貢献する方法のひとつで、一般的なウォーターフォールモデルだとリリースするまでに半年から1年かかってしまうところを、細かいサイクルでリリースすることができます。

アジャイルは1週間から2週間程度で動くものを作り、それを元に仕様のフィードバックやアーキテクチャの再検討を行いましょう、というモデルです。

動くものが出来るまでは早いのですが、残念ながらアジャイルを導入してもリリースのサイクルが劇的に短くなるということは少なかった。動きはするけど中途半端な状態というものはリリースしたくないですよね。

そうなると結局、最後に受け入れテストや負荷テストが必要になます。これをエンドゲームといいます。短期間で動くものを作れたとしても最終的なリリースのタイミングは変わらないんですよ。

DevOps前夜。インフラ技術の進化により継続的デリバリーが可能に

そのアジャイルの問題の解決策として出てきたのが、アジャイルテスティングや継続的デリバリーという考え方です。ポイントは2点あって、まず1つ目がQA担当者と開発者を同じチームに配置しましょうということです。そこで開発と平行してテストを行う。

そして2つめが、受け入れテストや負荷テストなどの自動化です。新しい技術によりそれらのテストの自動化が可能になりました。それによって、次こそ2週間でデプロイができるようになるかと思われた。これで今度こそリリースサイクルの問題が解決されたと思ったら、残念ながらそうもいかなかったんです。

最後に「インフラ引き渡し」というものがあったんですね。特にエンタープライズ系だと、どれだけ自動テストを重ねても、最終的にはインフラを担当される方に引き渡さないといけないんですよ。そのために手順書を書いたり、承認を貰うために3営業日待つとか、そういったものがネックになっていました。

そのような状況の時に、時を同じくしてインフラ構築の自動化、Infrastructure as Codeと呼ばれる技術が登場してきました。

今まではサーバーの構築は、設定手順書やパラメーター定義書を元に手動で構築していました。しかし、それが今では設計をコードに落としておけば自動で出来るようになったんです。これがインフラ構築にとって破壊的なテクノロジーでした。まさにDevOps前夜といったところです。

「10 deploys per day」をも実現するDevOps

そんな中、アメリカのFlickerという会社が「10 deploys per day」という講演をしたんですよ。これが2009年の事です。それまでは優れたアジャイルのチームであっても、リリースサイクルは3ヶ月程度かかることが大半でした。それが1日に10回もデプロイしているという。

衝撃じゃないですか。その講演で彼らは、「同じ考え方で進めていけばみなさんでも1日10回本番環境にデプロイできますよ」という話をしているんです。この考え方が今のDevOpsの原型になっています。

現実的には必ずしも1日に10回デプロイする必要は無いし、デプロイ回数が多いこと自体が価値だとは思わないです。実際にはリードタイムが短くなることの方が重要であるケースも多いです。

ただ、単純化した解りやすい基準として「10 deploys per day」が実現できる能力があるというのは間違いなく価値であり、DevOpsが実現出来ているという証明になると思うんです。

1日に10回デプロイ出来る環境なのにDevOpsじゃない、ということはあまり無いと思うので。定義が難しいものなので、そういった分かりやすさは重要だと思います。

DevOpsは技術だけでは実現できない

ハッカソンを実施したときにすごい悲しい話があって。「自動テストの価値がわからない」という参加者の方がおられました。理由をたずねてみると「自動テストを書いた後にテスト仕様書を作るのが二度手間です」と言われて。

それは意味のないテスト仕様書を作らせている組織が悪いのであって、マネージャーをクビにすべきだとブログに書きました（笑）。

「10 deploys per day」を実現するためには、技術だけでは無理なんです。例えば、デプロイの許可を貰うために1営業日待つというルールなら、もうそれだけで不可能じゃないですか。Opsの人が忙しくて対応が数日後になるとか、もうおしまいなんです。

DevOpsは数年前から日本でも流行っていますが、ツールの導入やインフラ構築の自動化といった、技術的な側面の流行りでしかなかったと思います。DevOpsの本当の意味って、ライフサイクル全体の改善じゃないですか。

そういう意味で実践出来ている企業なんて、エンタープライズ系の企業では、国内ではまだまだ例が少ないです。もっと多くの企業に実践してもらうためには、まずDevOpsというものを正しく認知してもらう必要があります。そういう啓蒙活動を地道に続けていきたいなと思っています。（了）