開発者（Developers）と運用者（Operators）の協力体制「DevOps」。なぜふたたび注目を集めるのか？ | 東京エレクトロンデバイス

2012年および2013年と開催され、当時の「DevOps」ムーブメントを牽引してきたイベント「DevOps Days Tokyo」が今年、4年ぶりに「DevOps Days 2017」として開催されるなど、最近になってふたたび、DevOpsへの注目度が急速に高まっています。
なぜいま、DevOpsがブームなのか。その背景を探る前に、改めて「DevOpsとは何か」について説明しておきましょう。

DevOpsの原点とは？

DevOpsの原点は、2009年に米国で行われたイベント「Velocity 2009」においてFlickrのエンジニアが行った講演「10 deploys per day dav&ops cooperation at Flickr」とされています。この講演において、変化の激しいビジネスをITが推進していくためには、開発者（Developers）と運用者（Operators）が共に協力しなければならず、その協力体制をさまざまなIT系のツールと企業のカルチャーで実現していこうという考え方が提唱されたのです。
このカルチャーが「DevとOpsの協力」であり、ツールとは「クラウドのような自動化されたインフラ」「共有されたコードのバージョンコントロール」「ワンステップのビルドとデプロイ」といった例が挙げられています。
こうした考え方に共感したコンサルタントのPatrick Debois氏が、これを「DevOps」というキーワードで表現するとともに、2010年に豪州シドニーでDevOpsの最初のイベントとなる「DevOps Days Sydney」を開催。このイベントが各国で開催されていくに伴いDevOpsという考え方が広まり、2012年にはそれが日本にも届く格好となりました。
DevOpsには基本的な考え方は示されていますが、そこに明確な定義は存在せず、ITを推進するために開発者と運用者が協力していく“ムーブメント”がDevOpsである、という緩やかなコンセンサスが特徴です。
  

著者が2013年に行われたイベント「Developers Summit 2013 Summer」のDevOpsについての講演で使用したスライド。いずれも原点となった「Velocity 2009」のFlickrエンジニアの講演から引用したものです。

当初はネット系企業が注目し始めたDevOps

そもそもDevOpsがFlickrのエンジニアから提唱されたこともあり、この考え方にいち早く注目したのは、いわゆるネット系企業に所属していたエンジニアたちでした。
ネット系企業は常に自社サービスにさまざまな改良を加え、新機能を追加し続けていかなければ厳しい競争に勝ち残っていくことはできません。同時に、改善点や新機能の評価をユーザーから速やかにフィードバックを受け、次の改善へと即座につなげていきます。バグをつぶしたコードをのんびり書いて、運用を開始したらできるだけ変更を加えないなどといったことは許されないのです。
そのため、クラウドのような自動化されたインフラを採用して柔軟なスケーラビリティーや運用手段を確保しつつ、開発者も運用者も開発の進捗やバグの状況をGitHubのようなコードリポジトリーを通じて共有し、自動ビルドや自動デプロイで最新のコードを即座に本番投入できる体制を作ろうとしていたのです。
初期のDevOpsはそうした方法論がネット系企業に支持されて広がっていったと言ってもいいでしょう。
そして最近になって、DevOpsがふたたび注目され始めたのは、DevOpsで実現される“迅速かつ柔軟な開発と運用”がネット企業だけでなく、多くの一般企業にも求められてきたからです。

多くの企業においてソフトウェア開発の重要度が高まっている

いまや多くの企業がソフトウェア開発に向き合わざるを得なくなっています。例えばタクシー業界は、スマートフォンからいつでもタクシーを呼び出せる配車アプリを開発し、タクシーを利用する体験そのものをまるごと改善しなければ、Uberといった新たに登場した競合に市場を奪われてしまう危機に直面しています。
銀行や証券、保険といった金融業界はFinTech（フィンテック）という名のもとに、スマートフォンやAPI、ブロックチェーンといった技術を用いた金融サービスの開発に迫られていますし、自動車産業はビッグデータと人工知能などを用いた自動運転技術において将来を賭けた戦いが始まっています。
もちろん小売業も製造業も例外ではありません。あらゆる分野において、これからはソフトウェアがビジネスの大きなカギを握るようになってきているのです。
こうした新しいソフトウェア開発は、従来の業務アプリケーション開発のような、開発が完了したらコードを固定化し、安定運用を続けていくというスタイルには合致しません。そもそも何をもって完成なのかという要件定義すら、従来の方法論では実現できなくなっています。
だからこそ、開発したコードを常に本番環境へ投入し、運用しながらユーザーに使ってもらい、その結果をフィードバックして、さらに開発や運用を改善していくというサイクルを回し続けなければ、こうしたソフトウェアを正しい方向に進化させていくのは不可能なのです。
必然的に、これらのソフトウェア開発はDevOps的なものにならざるを得ません。
 
 

クラウド、Jenkins、Dockerなど技術的環境も整ってきた

こうしたビジネス面からの要請と同時に、技術的な環境面でもDevOpsを推進する状況が整ってきています。
1つはクラウドです。開発用のサーバー、テスト用のサーバー、そして本番用のサーバーを、文字通り数分から数秒といったスピードで迅速に調達でき、それらを自由に構成できるクラウドは、DevOpsの実現にうってつけなのです。
そしてGitHubのようなコードリポジトリーを中心にしたコラボレーションツールが開発者と運用者の“規律あるコミュニケーション”を促進するようになり、JenkinsやCircleCIのようなビルド、テスト、デプロイの自動化ツールやサービスも進化し、普及するようになってきました。Dockerのような開発からデプロイまで、より軽量でポータブルな環境を構築する技術も充実してきています。
DevOpsが国内で初めて注目された5年前と比べると、こうしたDevOpsを実現するための周辺環境も飛躍的に充実し、簡単に揃えることができるようになってきたのです。

ビジネス部門への変革も迫るDevOps

一般の企業でもDevOpsへの注目度が高まった背景には、前述したようにビジネス環境の変化によりDevOpsへのニーズが高まったことに加え、技術的環境の充実によって導入のハードルが下がってきたという要因も考えられます。
さらにDevOpsを実現していくには、ツールなどを導入するだけでなく、開発と運用が協力してビジネスゴールを目指すというカルチャーの実現が欠かせません。これは従来の企業にありがちな、ビジネスの担当部門が情報子会社や外注企業に開発や運用を丸投げするようなカルチャーからの大きな変革を迫るものです。
開発と運用が協力し、DevOpsとしてビジネスゴールを目指そうとするとき、そこには「ビジネスゴールとは何か」という、実はデリケートな方向性に責任を持つビジネス部門や担当者の存在が不可欠です。しかも彼らとIT部門の協力関係は、従来の発注元と開発を行う下請けのような関係のままでは到底築くことができません。
DevOpsの普及、あるいは普及の背中を押しつつあるビジネス環境の変化は、IT部門やそこに所属するエンジニアだけでなく、ビジネス部門にも変革を強く迫るものと言えるでしょう。