DevOpsとは？その意味と“よくある誤解”を分かりやすく解説

「開発と運用の一体化」「迅速かつ継続的なリリース」といった文脈で語られることの多いDevOps。「そうはいっても、なんだか曖昧でいまいちピンとこないな……」と感じている方も多いのではないでしょうか。

この記事では、分かるようで分からなかったDevOpsの意味を詳しく解説していきます。

DevOpsという概念のはじまりや、よくある誤解などについても解説しているので、DevOpsのイメージを具体化するのにぜひ役立ててみてください。

DevOpsとは

DevOpsは「衝突の発生しがちな“開発サイド”と“運用サイド”の一体化を図ることで、高品質なシステムを迅速にユーザーへ提供し続けるための取り組み」を示す概念です。

「DevOps」という言葉のはじまり

▲出典：Devopsdays Ghent 2009

言葉そのものの始まりは2009年頃。オライリー主催のカンファレンス『Velocity Conference』に関連するツイートでハッシュタグ「#devops」が数件確認できます。このカンファレンスでは、DevOpsの源流となるFlickr社が「開発と運用の協力」という取り組みを発表していました。

ハッシュタグ「#devops」の件数が大きく増加するきっかけとなったのは、同年にPatrick Debois氏がベルギーで開催した『DevOpsDays』というカンファレンスです。「開発と運用の一体化」をテーマに開催されたこのカンファレンスは大成功し、その波は各国へと広がっていきました。それにともないDevOpsという言葉も世界中に広まっていったのです。

DevOpsには明確な定義が存在しない

DevOpsには、公式の組織や仕様書は存在しません。「開発と運用の一体化」というテーマを根本としているため、それを成し遂げるためのすべての行動がDevOpsに該当します。技術的な用語というよりも、ある種の「取り組み」や「運動」に近い言葉です。

それゆえMicrosoftやGoogle、IBMなど各社がDevOps向けのツールを提供する現在でさえ、DevOpsという言葉の公式的な定義は存在していません。

【DevOps向けのツール】

• Microsoft Azure
• オペレーション（旧：Google Stackdriver）
• IBM DevOps
• Docker

DevOpsは認識のズレが生じやすい

明確な定義が存在しないからこそ、DevOpsに関して認識のズレが生じることもしばしば。

たとえばDevOpsを「最新のツールを導入することだと考えている人」と「組織全体の文化的な取り組みだと考えている人」とでは、決してDevOpsについて有益な討論をできません。

また「開発と運用」という言葉の捉え方もそれぞれです。「“プログラミングをする人”と“LINUXサーバをいじる人”」と認識している人もいるでしょうし、「システム開発・運用に直接的もしくは間接的に関わる全部門」と捉えている人もいます。

明確な定義づけがされていないからこそ、このような認識のズレが生じてしまうこともあるのです。

DevOpsの表記や拡張概念

なお「DevOps」という表記もまた、絶対的なものではありません。たとえば、ITエンジニア向けの技術書籍で権威のあるO’Reilly社の出版『Effective DevOps』では、意図的に「devops」という表記が使われています。

またDevOps普及のきっかけとなったカンファレンス『DevOpsDays』も、公式サイトでは自身の名前を一部で「devopsdays」と表記しているのです。（日本の『DevOpsDays Tokyo』公式サイトでは「DevOpsDays」）

さらに、DevOpsの拡張的な概念を示す言葉として『DevSecOps』『DevQAOps』などもあり、解釈によってはこれらがDevOpsに含まれることもあります。

こうした拡張概念があることも、DevOpsのイメージが具体化しにくい原因となっています。

再入門：DevOpsとは

▲出典：Google Cloud

明確な定義の存在しないDevOps。その理解を深めていくために、DevOpsがどのように語られ、どのような実践をされているのかを見ていきましょう。

さまざまな側面を持つDevOps

まず、DevOpsがどのように説明されているかを、さまざまなWebサイト／著作から抜き出してみました。

• 「devopsは文化運動だ」「devopsは文化のための処方箋だ」
  （Jennifer Davis, Ryn Daniels 著 (2018)『Effective DevOps』株式会社オライリー・ジャパン）
• DevOpsは「組織的で文化的な仕組み」だ
  （Google Cloud | DevOpsとは: 研究とソリューション）
• DevOpsは「開発（Dev）と運用（Ops）を組み合わせたもの」
  （Microsoft Azure | DevOpsとは何ですか？）
• DevOpsは「人、プロセス、およびテクノロジを結び付けるソフトウェア開発手法」
  （Microsoft Azure | DevOps とアジャイル）
• DevOpsは「無駄のない俊敏なソフトウェア・デリバリー・アプローチ」
  （IBM DevOps | DevOpsとは）
• DevOpsは「企業文化、自動化、およびプラットフォームの設計に対するアプローチ」
  （RedHat | DevOpsについて理解する）
• DevOpsは、「開発と運用で役立つさまざまな手法」
  （VMware | DevOpsとは）

これらのどれが間違いで、どれが正解といったものはありません。もっとも大切なのは、これらがすべて顧客への継続的な価値提供の実現を目指しているということです。

DevOpsは「顧客への継続的な価値提供の実現」を目指すもの

顧客の最新の課題は、常に変化し続けるもの。したがって、その変化をいち早くシステムに取り込み、迅速にリリースを行い続ける必要があります。

DevOpsの取り組みは、このような「継続的な価値提供の実現」を目指しています。そのため、以下のようなさまざまなアプローチはすべてDevOpsに該当する取り組みです。

• 組織の体質を変える文化的な運動
• 開発と運用のコラボレーション
• プロダクトの品質を担保し続けるための自動化ツール群の活用

DevOpsに関する調査結果

▲出典：The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling

DORA（DevOps Research and Assessment）が行った2019年の調査では、以下4つの観点から、DevOpsのエリートパフォーマーとローパフォーマーを比較しました。

• デプロイ頻度
• 変更のリードタイム
• サービス復元時間
• 変更失敗率

その結果、エリートパフォーマーはローパフォーマーと比べ、以下の倍率でのパフォーマンスを発揮していることが判明しました。

このようにDevOpsに積極的に取り組み、うまく活用することができた企業は、そうでない企業と比べて極めて高い水準のパフォーマンスを発揮できています。

では、DevOpsのエリート企業はどのような取り組みによって、高水準のパフォーマンスを維持しているのでしょうか。DORAの調査では、以下の取り組みを行なっていると評しています。

• クラウドコンピューティングの特性を適切に活用
• 障害復旧テストの実施
• テスト自動化による継続的インテグレーション（CI）の改善
• 疎結合アーキテクチャによる継続的デリバリー（CD）の改善
• システムに変更を加えるプロセスの明確化
• 信頼・敬意を重視する心理的安全性の高い組織文化づくり

こういった取り組みによる生産性向上は、組織にビジネス上の成功をもたらすだけではありません。生産性は、メンバーの「仕事からの回復力（※）」にもプラスの影響を与えます。仕事からの回復力が高まることで、ワークライフバランスを改善したり、燃え尽き症候群を防止できたりすることも判明しています。

（※ 仕事でのストレスに対処し、仕事をしていないときには仕事のことを切り離す能力）

DevOps成功事例の共通点

▲出典：What is DevOps? | VMware Tanzu

「こうすれば必ず成功する」というベストプラクティスは、DevOpsに存在しません。組織ごとに課題があり、解決の鍵は常に同じではないためです。

しかし、写真共有サービスを提供するFlickr社や、ハンドメイド品のWebショップを展開するEtsy社など、DevOpsの取り組みに成功した企業の事例には3つの共通点があります。

共通点1. 対話や共感を重視

組織にはメンバー間／チーム間の摩擦がつきもの。その摩擦が大きいなかでは、開発・運用が協力してプロジェクトを勧めたり、学習しあったりすることは不可能です。

DevOpsの取り組みに成功した企業は、対話や共感を重視しています。対話や共感を重視することで、多様な背景をもつメンバー・チームがうまく連携できるようになるのです。

共通点2. リリース回数の増加に伴う品質保証上の諸課題をツールで解決

開発・運用の協力で短期間に何度もプロダクトのリリースを行う場合、課題となるのはプロダクトの品質です。

短期間でのリリースによるバグの混入や障害の発生を防ぐには、以下のような取り組みが有効になります。

• ツールによる自動テスト
• コンテナ技術による、本番環境とテスト環境の差異の最小化
• 手作業を極力減らすためのインフラストラクチャ自動化

このようにツールを有効活用することで、リリース回数が増えても顧客に高品質のプロダクトを提供し続けられます。

共通点3. 非難をせず、失敗を適切に扱う

プロダクトに関して何らかの障害が発見されたとき、いわゆる「犯人探し」に時間を費やしたり、懲罰を加えたりすることは望ましくないです。

人格攻撃やプレッシャーを与えるよりも、落ち着いた状況で失敗についての適切な分析を行い、今後のための学習に時間を費やしましょう。

DevOpsにまつわる誤解

DevOpsを誤解していると、かえってプロダクトの開発・運用サイクルを悪化させてしまうことがあります。

以下では、よくあるDevOpsについての誤解を4つ紹介していきます。

誤解1. DevOpsは「DevOpsエンジニア」をひとり雇えば大丈夫だ

DevOpsは組織全体で実践する取り組みです。そのため、開発から運用まで全てをこなすことができるロックスター的な人材や、DevOpsエンジニアをひとり雇って解決することはありません。

大切なのは、チームや組織の全員がプロジェクトの最終目標を共有し、そのための協力体制について共通的な意識を持つことです。特別な人材をひとり雇って専用の部署や役職を設けるだけでは、開発・運用間の壁は壊せません。

誤解2. DevOpsは最新のツールだ

DevOpsは「最新の自動化ツールを導入すること」と誤解されることがあります。

しかし、DevOpsの本質はツールではありません。提供するサービスやプロダクト、組織の規模などに応じて最適なツールは異なるので、常に最新のツールが優れているとは限らないのです。

また同じツールを導入するにしても、ツールを利用するチームやメンバーがそれを活かしきれない状態では意味がありません。

たとえ継続的デリバリーを実現するためのクラウドコンピューティングや、品質を担保するための自動テストツールを利用していたとしても、開発・運用間が異なる方向を向いている状態では、それらツールの能力を十全に発揮することはできないのです。

誤解3. DevOpsはシステム部門だけの問題だ

DevOpsは、開発部門と運用部門だけに関係のある用語だと勘違いされがちです。しかしDevOpsは、単にこの取り組みが「開発と運用の一体化」というテーマから始まったことを示すに過ぎません。

実際、プロダクトの開発・運用サイクルを高速化するためには、必ずしも開発／運用部門のいずれかにある問題を解決すればいいとは限りません。それらの部門を管理する企業の上層部や、組織文化そのものにもっとも大きな課題がある場合もあります。

ある調査によると、DevOpsを取り入れた企業の従業員うち、60%が「DevOpsに関する適切な研修を受けていない」と述べています。これではDevOpsの実施に支障をきたしかねません。

そのためDevOpsを取り入れるには、企業そのものの文化的な変化が必要です。DevOpsの取り組みを最大限に生かすためには、チーム内だけでなく、企業の上層部までDevOpsの文化を共有し、サポート体制を築いていくのがベストです。

誤解4. DevOpsはレガシーな環境に適用できない

大企業や政府機関など、長年に渡りサービスを提供してきた組織では、古くて生産性の悪いシステムが現在も使われ続けている場合があります。DevOpsはそのようなレガシーな環境に適用できないという説がありますが、これは誤解です。

「開発・運用が協力し、顧客への継続的な価値提供を行う」というDevOpsの本質は、その環境の規模や新旧に左右されません。たとえば米国特許商標庁は、公の政府組織でありながらDevOpsに取り組み、特許や商標についての日常業務の効率化を行なっています。

組織には組織ごとに異なる課題があり、解決のアプローチもまた組織ごとに異なることは、どの企業も同じです。

先述したとおり「全ての企業に通用するベストプラクティス」は、DevOpsにはありません。規模や新旧を問わず、自分の組織にあった取り組みを行い続けましょう。

おわりに

DevOpsという概念は、明確な定義がないことや、一部の側面が強調されたことから、多くの誤解や異なる解釈が生まれました。

それゆえ具体的なイメージの湧きづらい用語となったDevOpsですが、本質はあくまで「開発・運用が協力して、顧客への継続的な価値提供を実現する」ことです。組織ごとに課題は異なるので、その実現のためのアプローチは常に同じではありません。

クラウドコンピューティングやテスト自動化、変更プロセスの明確化や心理的安全性の確保など、DevOpsのエリートパフォーマーの実践傾向を参考にしながら、自らの組織の改善のためにどんな取り組みが必要かを検討してみましょう。

（執筆：sig_Left　編集：Kimura Yumi）