SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

翔泳社 新刊紹介(AD)

DevOpsを正しく理解しビジネスの価値を高める――なぜあなたのチームのDevOps化は進まないのか

  • X ポスト
  • このエントリーをはてなブックマークに追加

 作りきりのウォーターフォール開発から、継続的に開発・改善していくアジャイル開発のようなスタイルが普及するにつれ、開発チームと運用チームの対立が生まれるようになりました。両者を連携させるためにはどんな考え方や手法が必要なのでしょうか。10月13日に刊行された『DevOps導入指南』から、その要点を紹介します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

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を実際の業務レベルにまで取り入れていくにはどうしたらいいのか、少しでも前進するには何をしたらいいのかを、ぜひ本書を通じて学んでいただけたらと思います。

DevOps導入指南

Amazon   SEshop   その他

DevOps導入指南
Infrastructure as codeでチーム開発・サービス運用を効率化する

著者:河村聖悟、北野太郎、中山貴尋、日下部貴章、株式会社リクルートテクノロジーズ
発売日:2016年10月13日(木)
価格:3,240円(税込)

本書について

本書はDevOpsを実際のチーム開発へ導入する方法はもちろん、具体的な事例にもとづいた技術(Ansible / Docker / Vagrant等)についても解説します。DevOpsを導入したい方には特に役立つ実践的な指南書です。

 

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
翔泳社 新刊紹介連載記事一覧

もっと読む

この記事の著者

中山 貴尋(ナカヤマ タカヒロ)

1988年生まれ。三重県出身。大学で数学を学んだ後、新日鉄住金ソリューションズ株式会社に入社。社内ではインフラ系事業部に所属し、構築・運用自動化案件の支援を通じて本書の執筆に参画。HadoopやOpenStackなど、大規模分散システムを実現するインフラ技術に興味がある。現在は構成管理ツールなどを用...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

渡部 拓也(ワタナベ タクヤ)

 翔泳社マーケティング課。MarkeZine、CodeZine、EnterpriseZine、Biz/Zine、ほかにて翔泳社の本の紹介記事や著者インタビュー、たまにそれ以外も執筆しています。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/9717 2016/10/21 08:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング