DevOps（デブオプス）：Dev Basics／Keyword
DevOpsとは「ビジネスの価値を高めることを目的に、製品・サービスを迅速かつ継続的にユーザーへと届けるために、ITシステムの開発チーム（Dev）と運用チーム（Ops）が協調すること」を意味する言葉だ。
DevOps（デブオプス）とは「ビジネスの価値を高めることを目的に、製品・サービスを迅速かつ継続的にユーザーへと届けるために、ITシステムの開発チーム（Dev）と運用チーム（Ops）が協調すること」を意味する言葉だ（ただし、その明確な定義はない）。
DevOpsが生まれた背景
今も述べたように、DevOpsは「（ビジネス部門も巻き込みながら、）開発チームと運用チームが協調して、ビジネス上のゴールに達成しよう、ビジネスを迅速にユーザーへと届けよう」という概念だ。
この概念が生まれた背景には、ITが進化するにつれて、ビジネスとITの関係が変わってきたことがある。以前はITやソフトウェアはビジネスの役に立つ1つの要素だった。それが現在では、ビジネスにITは欠かせないものとなっている。さらにビジネスそのものの変化の速度もITの進化に歩調を合わせるようにして高いものとなっている。
ユーザーのニーズを俊敏に捉え、それに応えるために迅速に自分たちのサービスを（ニーズに合うように改変し）ユーザーへと送り届けることが現在では非常に重要なことになっている。アジャイルなソフトウェア開発はこうした状況によくマッチするが、これを開発面だけではなく運用面にまで広げた思想がDevOpsの考えといってもよいだろう。
その一方で、2009年にオライリーが主催した「Velocity 2009」における「10 deploys per day」というプレゼンテーションでは、John Allspaw氏とPaul Hammond氏によって開発チームと運用チームの間の障壁について指摘されている。簡単にいえばこれは、開発チームの役割である「新機能の追加」と運用チームの役割である「システムの安定稼働」が相反するように捉えられているというものだ（また、開発チームと運用チームがそれぞれの情報を相手と共有しないことが互いにデメリットを生む場合もある）。
「10 deploys per day」のセッションスライド
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
そうではなく本来、開発チームと運用チームの役割は同一、つまり「ビジネスの価値を高め、それを迅速かつ継続的にユーザーに届ける」のはずだ。そして、上述した通り、ビジネスが常に変化する時代となってきた。変化を恐れることなく、安定的にシステムを稼働させることが今のソフトウェア業界では必要なことになってきている。開発面と運用面の両者で、これを実現するためには何が必要か、どんなことを実践すればよいか。そこから、DevOpsという考え方が生まれたといえる。
DevOpsを構成するもの
上述のセッションでは、「開発のことを考えた運用」と「運用のことを考えた開発」というキーフレーズが取り上げられると共に、問題を克服するためのツール／組織文化が述べられている。ツールについては以下が挙げられている。
- 自動化されたインフラ
- バージョン管理システムをDevsとOpsで共有
- ワンステップのビルドとデプロイ
- フィーチャーフラグ
- メトリクスの共有
- IRCロボットやインスタントメッセージングロボット
詳細については触れないが、これらは開発したソフトウェアのデプロイメントまでにかかる手間や時間を最小化、実際のソフトウェアのコードの共有、システムの稼働状況に関する情報の共有（これは将来的な機能追加を検討する際の情報ともなるだろう）、日々の作業で発生したことの共有（ビルドやデプロイのたびにロボットにメッセージを送信させ、それをDevsとOpsで共有）といった面で役に立つ。
DevOpsを実践するのに必要な組織文化としては次のことが挙げられている。
- 相手を尊重する
- 相手を信頼する
- 失敗に対して健全な態度をとる
- 相手を非難しない
これらは同じビジネスゴールを実現しようとする人たちをやたらと敵視するのではなく、相互に尊重し、お互いがベストを尽くしていると信じることが重要であり、失敗を誰かのせいにするのではなく原因を突き止め、それを自分たちのビジネスの価値向上につなげることになることを意味している。
開発チームと運用チームが相互を尊重して、ツールと組織文化で上記のことを実践し、開発チームと運用チームが情報を共有して、双方を受け入れる態度をとることで、運用から得られた情報を基にソフトウェアに改善を施し、それを早期にリリースし続けることが可能になる。
ここで気を付けたいのは「○○をしているからDevOps」ということではないということだ。例えば、継続的インテグレーションを実践していれば、それでDevOpsというわけではない。それはDevOpsの一側面の話であって、ツールやプラクティスにばかり焦点を当てるべきではない（とはいえ、本稿のようにそうした話がどうしても話題に挙がってしまうのではあるが）。
重要なのは「DevOpsとはビジネスゴールを実現するためのもの」ということだ。自分たちがビジネスで何を提供したいのか。そのゴールについて開発チームと運用チームが意識を一致させ、そのためには何が必要かを検討することで、実践すべきことが見えてくる。そして、それはビジネスや組織ごとに異なる。本稿冒頭で「明確な定義はない」と述べたのはそのためだ（本フォーラムっぽくいえば、DevOpsの概念はクラス定義のようなものであり、実際にどんなことを実践していくかは、そのインスタンスのようなものだ。実体は、コンテキストによってさまざまに変化する）。
本稿ではDevOpsの概要について述べた。ただし、これは基本中の基本ともいえる考え方であって、現在ではさまざまな検討が加えられ、さまざまな側面からDevOpsについて述べられている。興味のある方は以下の参考資料にも目を通していただきたい。
特に「なぜDevOpsは正しく理解されてこなかったのか？〜ベンダーキーパーソンが徹底討論〜」（前編／後編）は、日本のDevOpsをリードするキーパーソンによる座談会であり、現在のDevOpsの状況を知るには最適だ。
また、本フォーラムの兄弟サイトであるBuild Insiderの記事「DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い」は本稿で紹介したDevOpsの概要を深く掘り下げた記事である。より深く理解したい方にはお勧めだ。
参考資料
- 「10 deploys per day」： DevOpsの基本となる概念が提示されている
- 「なぜDevOpsは正しく理解されてこなかったのか？〜ベンダーキーパーソンが徹底討論〜」（前編／後編）： 日本のDevOpsをリードするキーパーソンたちによる座談会
- 「国内DevOpsを再定義する」： ＠ITの特集記事
- 「DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い」： DevOpsの本質について深く掘り下げている
Copyright© Digital Advantage Corp. All Rights Reserved.