DevOpsは言葉だけが普及し、理解が共有されていない
皆さんはDevOpsという言葉を聞いたことがあるでしょうか。
本記事をご覧になっている方々の中には「チームをよりよいものにしたい」「なんとかしたい」という気持ちをお持ちの方が多いと思います。そうした課題に対して何らかの解決策を提示するのが、DevOpsという概念でありアプローチです。
しかし、チームにDevOpsを導入するといっても、それが何なのかを具体的かつ端的に説明するのは非常に難しいと感じている方もいらっしゃるのではないでしょうか。あるいは、説明できたとしても、チームのメンバーがDevOpsという言葉に対して同じ理解を持っていると断言できないかもしれません。それは、DevOpsという言葉が明確に定義されていないことが原因です。正しい理解と共有がなされないまま、言葉だけが世の中に普及しているのです。
では、DevOpsという言葉をチームで共有することはできないのでしょうか。そんなことはありません。DevOpsに明確な定義がなかったとしても、なぜこのような考え方が生まれ、何を目的としているのか、そしてどのような手法やツールによって支えられているのかを学ぶことは可能です。『DevOps導入指南 Infrastructure as codeでチーム開発・サービス運用を効率化する』の執筆は、こうした想いから始まりました。
なぜあなたのチームのDevOps化は進まないのか
本書を執筆するにあたり、国内外を始めとしてDevOpsに関する様々な記事、発表、文献を調査しましたが、その定義は人それぞれであり、まったく統一されていないことがわかりました。
このような状況であるからこそ、DevOpsという言葉がなんとなく浸透し、人によってはそれが取り組みであったり、ツールであったり、文化であったりと、様々な解釈を含む「曖昧な」言葉として存在していることがわかっています。
その曖昧さこそが、DevOpsが「なんとなく状況を打開してくれるもの」という無責任な期待を含むものとして発展した理由であり、現在もその状況が続いているのだと考えられます。もし皆さんのチームの中でDevOps化が進まない状況があるのだとすると、原因はそこにあると考えられます。
チームにDockerを導入したらDevOpsでしょうか。インフラをAWSにしたらDevOpsでしょうか。継続的インテグレーションの仕組みを導入したらDevOpsになるのでしょうか。あるいは、そのような仕組みを導入したいのにうまくいかないときは、頑として重い腰を上げない上司や同僚が悪いのでしょうか。
こうした現状に嫌気が差してしまうかもしれませんが、その前に考えてみてください。DevOpsにとってツールや文化は、パーツや手段であって目的ではありません。ツールを導入したり文化を変えたりする前に、そもそもDevOpsを運用する目的は明らかになっているでしょうか。そしてその目的はチームにおいて共有・理解されているでしょうか。
皆さんのチームの「DevOps化」がうまくいかない場合、DevOpsに関する理解と目的がチームで共有されることで、導入と運用がうまくいく可能性があるのです。
誕生の背景にこそDevOpsが必要となった状況が読み取れる
DevOpsの理解を深めるには、DevOpsが生まれることになった背景を知ることが近道です。なぜなら、そこにこそチームにDevOpsが必要となる状況が示唆されているからです。
たとえば皆さんが、昨今の環境変化の大きなWebサービス開発に従事した経験があるなら、こんなことに悩まされたことはないでしょうか。
- 新規開発を終えたあと、開発チームが機能の追加や修正をしようとすると、運用チームがいつも文句を言ってリリースを待たされる。
- 開発チームが安定運用のことを考えず、ろくな情報共有もせずに新機能を追加して障害が発生する。
誰でも一度は経験のある悩み――開発と運用の対立です。このような悩みはDevOpsという概念が生まれる前から長く存在していました。
5年前、あるいは10年前の世界では、システムは基本的にウォーターフォール開発による作りきりだったので、開発と運用の対立があったとしても、開発の終盤、特にリリース前後に起きるごく短期間のトラブルでしかありませんでした。
しかし、近年ではウォーターフォール開発のような作りきりの開発から、環境変化にも柔軟に対応するアジャイル開発のように、小さくスピーディに作り始めて改善を重ねてサービスを育てていくような開発スタイルに様変わりしてきました。
継続的に機能追加や改善が求められるようになった結果、「開発」は継続的な成果物を仕上げられるようなスタイルへと急速に進化を遂げることになりました。一方で、「運用」はそうした継続的な開発スタイルには適応できておらず、次々と生み出される成果物を受け入れられる体制ができていません。両者の差は拡がるばかりでした。
そのため、繰り返し行われるリリースのたびに開発チームと運用チームは衝突して疲弊します。サービスも更新のたびに安定さを失うだけでなく、常に潜在的な不安定さを抱え込むことになっていきます。
DevOpsとは何なのか
このような背景から、「開発」だけでなく「運用」も含めた形で継続的な開発や改善を繰り返していける仕組みが模索され、DevOpsが誕生しました。検索するとわかるように、DevOpsというキーワードに関連する領域は非常に広く、その定義も様々です。そこで本書では「Dev（開発）とOps（運用）が密に協調・連携して、ビジネス価値を高めようとする働き方や文化」を指すことにします。
本書はこのフレーズを前提として、様々な側面から順を追ってDevOpsについて解説しています。読み進めていくうちに、DevOpsが単純に最新の技術やツールを取り入れればよいものではなく、それらを取り巻く組織や文化のあり方を含む「働き方から継続的な改善を続けられる運用の仕組みまで」を広く取り入れるものであるということを徐々に理解していただけると思います。
また、この定義からすれば、特定の何かを行うことが「DevOpsを実践している」と言えるわけではないことがわかります。それゆえにDevOpsを学んだり実践したりすることが難しくなっていたのだと、はっきりわかるのではないでしょうか。
DevOpsとInfrastructure as Code
DevOpsという考え方は、開発の専門家と運用の専門家の存在を否定したり、それぞれのチームを一気に取り壊して一つのチームにしたりしようとするものではありません。むしろ、専門家は専門家としてお互いに得意分野を認めたうえで同じ目標に向かって進み、密に連携を行います。それによってより円滑な開発や運用を実践してビジネスを加速させていきます。
しかしながら、開発と運用の相互理解を育むには、お互いが専門とする技術を概要だけでも把握していく必要があります。そのためにはそれなりの対価を払うことになりますが、昨今ではそれぞれの領域の垣根を下げるような技術も登場しています。
その一例が「Infrastructure as Code」です。Infrastructure as Codeとは、最近注目を集めているインフラの構成や設定をソフトウェアのようにコード化する技術をまとめた総称で、本書ではもう一つのキーワードとして取り上げています。
この技術を導入することで、ソフトウェア開発者は自分たちのコードが最終的にどのように構成されるのかなど、インフラ運用を意識しながら開発を行うことができるようになります。また、インフラのコード化による別の恩恵として、ソフトウェア開発において利用されてきた手法やツールをインフラの構築や設定変更へ応用できるようにもなります。これもまた、開発と運用の理解の垣根を下げる助けになります。
開発と運用の連携が促進されれば、DevOpsらしい考え方や文化をぐっと取り入れやすくなるわけです。
DevOpsを正しく理解しビジネスの価値を高める
DevOpsの概要を知り、個人で仕組みを理解しながら少しずつツールを導入し、やがてチームに展開して実際の業務に反映し、組織全体にDevOpsを波及させていくにはどうすればよいのか。『DevOps導入指南』では、そのために踏んでいくべきステップを詳しく解説しました。
ツールの適用はDevOpsを実践する手段の一部でしかなく、実はチームメンバーや組織の風土、考え方、個人の意識までも変えていかないといけません。そうでないとDevOpsは成り立たず、定着しないものです。
DevOpsを目指すのであれば、どこかのタイミングにおいて従来常識としていた考え方を変えて、全員で同じ目標に向かって進みながら、必要となる考え方やツールなどの学習を始める必要があります。
組織においては、DevOpsの考え方とそれを支える技術を現場で理解してもらいながら新しい技術の導入や改革をトップダウンで一気に進めることは大変な困難をともないます。しかし、DevOpsを組織に波及させていきたい場合、いくつかのパターンがあります。自分の所属するチームや組織にとってどのようなパターンが好ましく、好ましくないのかについても学ぶことができます。
もし皆さんが開発と運用が対立する現場にいるのでしたら、DevOpsを実際の業務レベルにまで取り入れていくにはどうしたらいいのか、少しでも前進するには何をしたらいいのかを、ぜひ本書を通じて学んでいただけたらと思います。
