DevOps（デブオプス）とは？　概要と開発手法、導入のメリット・デメリットを解説

目次

DevOpsとは

DevOpsは、「Development（開発）」と「Operations（運用）」を組み合わせてつくられた造語です。別々に分かれている開発チームと運用チームが密接に連携して協力することで、ソフトウェア開発を迅速かつ柔軟に行う手法のことを指します。

一見、「ソフトウェアやサービスを提供するにあたって、開発チームと運用チームが協力するのは当たり前のことでは？」と思うかもしれません。しかし、DevOpsという言葉が生まれた背景には、“ソフトウェア開発における開発チームと運用チームの対立”という伝統的な問題がありました。

そもそも開発チームと運用チームでは、それぞれに課せられた目的が大きく異なります。開発チームの主な目的はソフトウェアに新機能を追加し、ソフトウェアをより良くしていくことです。一方で運用チームの主な目的は、現在動いているシステムを維持し、サービスを安定して継続的に提供することです。

開発チームがリリースした新機能によって何らかのトラブルが発生した場合、運用チームにも負担がかかるため、意見の対立構造が生まれやすくなります。意見の対立が積み重なり、チーム間の溝が深まることを「サイロ化」とも言います。

開発チームは「新しい変化」を追求し、運用チームは「安定」を求めます。どちらかが正解・間違いといったものではありませんが、ニーズの移り変わりが激しい現代において「変化しない」という選択肢をとることは基本的にないでしょう。

急速に変化するビジネスシーンに対応するために、より迅速なソフトウェア開発も求められています。これらの目的を達成するために「開発チームと運用チームは密接に協力し、円滑に開発を進めよう」という考えが、DevOpsの根本にあるものです。

【関連記事】

DevOpsの開発手法（ベストプラクティス）

DevOpsでは、開発チームと運用チームが密接に協力し、ソフトウェア開発を迅速かつ柔軟に進めます。その実現のためにはさまざまな自動化ツールの導入が推奨されます。

また、開発を迅速化する一方で、運用の安定が損なわれては元も子もありません。開発期間を短縮し短期間で新機能をリリースする体制を整えつつも、問題発生のリスクを最小限に抑えるにはどうすればいいのか。DevOpsではそのために実践すべき手法がいくつか提示されています。ここではその手法について紹介していきます。

継続的インテグレーション

継続的インテグレーション（Continuous Integration、以下CI）とは、開発者が作成した新規コードを共有ソースコードリポジトリにコミットすると、自動的にビルドとテストを実行するソフトウェア開発手法です。

ビルドとテストが自動化されていることで、開発者はより手軽に、より頻繁に新規コードを試すことができます。CIの目的やメリットは以下のとおりです。

• 問題の早期発見/修正
• 開発品質の向上
• 開発サイクルの短縮

「問題の早期発見/修正」は、コード変更を頻繁に統合できることによる恩恵です。問題を早期発見/修正することでリリースリスクの低減にもつながります。

「開発品質の向上」は、自動化されたテストによる恩恵です。頻繁にテストを実施することでコード品質の向上が期待できます。

「開発サイクルの短縮」も同様に、コード変更を頻繁に統合して試せることから生じるメリットです。

CIの実行には専用のCIツールが必要となります。代表的なCIツールには以下のようなものが挙げられます。

• Azure Pipelines（https://azure.microsoft.com/ja-jp/products/devops/pipelines）
• CircleCI（https://circleci.com/ja/）
• GitLab CI/CD（https://about.gitlab.com/ja-jp/）
• Jenkins（https://www.jenkins.io/）
• Travis CI（https://www.travis-ci.com/）

継続的デリバリー

継続的デリバリー（Continuous Delivery、以下CD）とは、CIのテストに合格したプログラムを本番環境へ導入可能な状態にする作業を自動化する仕組みです。実際の稼働環境でより高レベルな結合とテストを行うことで不具合がないかをチェックし、サービスリリース開始可能な段階まで自動的に進めてくれます。CDはCIの延長線上に位置する仕組みで、CIとセットで「CI/CD」と扱われます。

CDの目的やメリットは、以下のとおりです。

• 迅速なリリース
• 生産性の向上
• 運用コスト削減

「迅速なリリース」は、リリース段階まで自動化されることによる恩恵です。新機能やバグ修正を迅速にリリースできるので、顧客満足度の向上にもつながります。

「生産性の向上」も同様に、自動化の恩恵のひとつです。開発者の手を煩わせること無くリリース可能になることで、開発者はより創造性の高い作業に集中できます。

「運用コストの削減」も同様で、自動化によって運用コストが削減されます。

CDもCIと同じように、実行には専用のCDツールが必要となります。ただ基本的にCIとCDはセットなので、先に紹介したCIツールにCDの機能が含まれていることが多いです。

また、類似語として継続的デプロイメント（Continuous Deployment、CD）という言葉もあります。こちらは継続的デリバリーよりもさらに一段階先までを自動化、つまり実際のリリース開始までを含めて自動化しているものになります。

継続的デリバリーは最終的なリリース開始までは自動化されず、最後に人の手による承認が必要な状態で止まります。どちらも処理内容的には同一で、どちらも「CD」と訳すことから同一視されることも多いですが、最後の一手に違いがある点は気をつけておきましょう。

Infrastructure as Code

Infrastructure as Code（以下IaC）は、サーバーやストレージ、ネットワークといったインフラ構成をコードで定義し、インフラストラクチャプロビジョニングを自動化する仕組みです。IaCの利用には、以下のようなメリットが挙げられます。

• 迅速かつ効率的なインフラストラクチャプロビジョニング
• 一貫性のあるインフラストラクチャ
• 再現性の高いインフラストラクチャ
• 変更管理の容易化
• 運用コストの削減
• 開発チームと運用チームの連携強化

「迅速かつ効率的なインフラストラクチャプロビジョニング」は、コードを記述するだけでサーバー構成やネットワーク設定などの作業を自動化できることによる恩恵です。テンプレートを用いれば同一環境を迅速に構築できますし、クラウド/オンプレミスを問わずさまざまな環境へ迅速にデプロイできます。

「一貫性のあるインフラストラクチャ」は、コード化することで、異なる環境にも同じインフラストラクチャを構成できることを指します。環境差異による問題を回避してデプロイの失敗を低減し、トラブルシューティングを容易にします。

「再現性の高いインフラストラクチャ」は、コードをバージョン管理することで、過去の状態を簡単に再現できることを指します。テストやデプロイに失敗したときも迅速に復旧することが可能です。

「変更管理の容易化」も、インフラストラクチャをコードのバージョンで管理できることによる恩恵です。コードを比較することで、インフラストラクチャの変更履歴を容易に確認できます。

「運用コストの削減」は、以上に挙げてきたメリットから生じる恩恵です。自動化で余計な労力を割かずにリソースに無駄のないインフラを構築できる点や、エラーの削減やトラブルシューティングの容易化など、手間を省けることは運用コストの削減につながります。

「開発チームと運用チームの連携強化」は、IaCのコードを共有することで、開発チームと運用チームが同じ情報に基づき作業できることを指します。従来、サーバーなどのインフラ管理は運用チームが責任を持つことが多い分野でした。

しかし、DevOpsでは開発チームの要望によるインフラ変更へ迅速に対応するため、開発チームもインフラ管理に参加することが求められます。そのような場合でもインフラ管理を容易にしつつトラブルを未然に防ぐことができるIaCは、DevOpsにとって不可欠なツールと言えます。

IaCの導入には、CI/CD同様に専用ツールが必要です。代表的なIaCツールには次が挙げられます。

• Ansible（https://www.ansible.com/）
• AWS CloudFormation（https://aws.amazon.com/jp/cloudformation/）
• Chef（https://www.chef.io/）
• Puppet（https://www.puppet.com/）
• Terraform（https://www.terraform.io/）

アジャイル

アジャイルはソフトウェア開発手法のひとつです。ソフトウェア全体の大まかな骨子ができたら機能ごとに小さく分割し、その小さな機能単位での設計、実装、テストという工程を短い開発期間（イテレーション）で繰り返しながら開発を進めていきます。

アジャイルのメリットには以下のポイントが挙げられます。

• 開発スピードの速さ
• 仕様変更やトラブルへの対応力が高い
• 顧客の要望を取り入れやすい

「開発スピードの速さ」は、大まかな骨子ができた時点で機能ごとの開発に取り掛かる、フットワークの軽さによるメリットです。素早く形にできる点が強みです。

「仕様変更やトラブルへの対応力が高い」という点は、イテレーションという短い開発サイクルによるメリットです。短期間で区切る開発であれば、仕様変更があった際の手戻り量も最小限ですむため、方針転換への対応も容易になります。

「顧客の要望を取り入れやすい」という点も同様に、短いイテレーションからもたらされるメリットです。ひとつのイテレーションが終了するたびに顧客との意見のすり合わせを行えるので、その際に要望を取り入れていくことができます。

アジャイルでは、これらの方針を実現する実際の開発手法として、スクラムやエクストリーム・プログラミング（XP）を提示しています。これらはいずれも開発者のチームワークや顧客とのコミュニケーションが重要視されている開発手法です。そのため、DevOpsのように開発チームと運用チームの協力を主題とした開発で用いる手法に、アジャイルはもってこいと言えるでしょう。

マイクロサービス

マイクロサービスとは、複数の独立した小規模なサービスを組み合わせることで、アプリケーションやサービスを構築する開発手法です。マイクロサービスアーキテクチャとも呼ばれます。

Webブラウザなどのユーザーインターフェイス上からはあたかも1つのアプリケーションのように見えますが、備わる各機能は、個々で成り立つ独立したサービスとして実装されており、サービス間はAPIで通信を行う仕組みになっています。各サービスはコンテナ化されているので、可搬性、互換性、拡張性に優れており、これは迅速な開発をモットーとするDevOpsとも相性が良い方式です。

マイクロサービスの主な利点は以下のとおりです。

• 開発の迅速化
• スケーラビリティの向上
• 変更が容易

「開発の迅速化」は、各サービスを独立して開発できることによる恩恵です。またサービスを個別にデプロイできるため、新機能リリースも迅速に行えます。

「スケーラビリティの向上」は、個々のサービスがコンテナで独立していることによるメリットです。各サービスを個別にスケーリングできるため、負荷へ柔軟に対応できます。

「変更が容易」も、各サービスが独立していることによる恩恵です。他のサービスに影響を与えることなく変更を加えることができます。

このように、マイクロサービスは特にサービスリリース後の随時改修が容易であるという点が、DevOpsの目的と合致する開発手法です。

DevOpsのライフサイクル（プロセス）

DevOpsのソフトウェア開発と運用を統合した一連のライフサイクル（プロセス）は、一般的に「プラン」「コード」「ビルド」「テスト」「デプロイ」「運用」「モニター」の7つのステップで構成されます。ここでは、各ステップの内容を見ていきましょう。

1.プランビジネスニーズや顧客の要望を理解し、プロジェクト全体のタスク管理や開発要件を定義します。

2.コード開発者が要件に従ってコードを作成し、共有ソースコードリポジトリにコミットします。

3.ビルドコードを実行可能なファイルに変換し、テスト環境などへデプロイします。

4.テスト自動化されたテストを実施してバグが無いかチェックを行い、品質を保証します。

5.デプロイテストを通過したビルドを本番環境にリリースし展開します。

6.運用システムを監視し、パフォーマンスを維持します。必要に応じてセキュリティパッチやソフトウェア更新を行います。

7.モニターユーザーからのフィードバックやシステムパフォーマンスなどを分析し、ソフトウェアやプロセスの改善点を探ります。

これらのステップは線形に進むのではなく、連続的かつ反復的に行われます。DevOpsはこれらのステップを通じて開発チームと運用チームが密接に連携し、迅速なフィードバックループを通じて、ソフトウェア品質とリリース速度を向上させることを目的としています。

また、DevOpsのライフサイクルを支えるツールやプラクティスとして、CI/CDツールやIaCツール、アジャイル開発手法などを活用していきます。これらの自動化ツールによって、より効率的で信頼性の高いソフトウェア開発のライフサイクルが実現できるようになります。

DevOpsとアジャイル開発との違い

アジャイル開発は、「短期間のイテレーションによる迅速な開発」「顧客フィードバックを取り込みながらの開発」「チームワークやコミュニケーションが重要」といった特徴を持つソフトウェア開発手法です。DevOpsの特徴と被る部分が多いため、混同されることがあるかもしれません。

先述したアジャイルの説明にもあるように、DevOpsとアジャイル開発は密接に関連しています。しかし根本的には異なるものです。

アジャイル開発はソフトウェア開発のプロセスに焦点を当てた具体的な開発手法ですが、DevOpsは開発チームと運用チームが協力して、迅速かつ柔軟にソフトウェア開発を行うための文化と一連のプラクティスを示すものです。

そしてDevOpsを実現する手段として、開発手法にアジャイル開発を組み込むことが多くあります。ただ、組み込む開発手法は必ずしもアジャイル開発に限定されるものではありません。

アジャイル開発はDevOpsを実現するために用いる、あくまで手段のひとつだと捉えると良いでしょう。

【関連記事】

DevOpsを導入するメリット

ここまで、DevOpsがどのようなツールや手法を用いてソフトウェア開発を支援するのかについて解説してきました。それらのツールや手法の導入によって最終的にどのような恩恵を得られるのか、DevOpsを導入するメリットについてまとめておきましょう。

主なメリットには、以下のものが挙げられます。

• 開発スピードの向上
• 生産性の向上
• 信頼性の向上
• 拡張性の向上
• 顧客満足度の向上

「開発スピードの向上」は、開発手法にアジャイルを組み込むことによる恩恵です。機能ごとのリリースを迅速に行うことができるので、市場の変化に即座に対応し競争優位の確保に貢献します。

「生産性の向上」は、開発チームと運用チームの連携強化から生じるメリットです。両者の連携により効率的な情報のやり取りが可能になり、ムダな作業を削減できます。これにより開発プロセス全体の生産性が向上します。

「信頼性の向上」は、アジャイル開発やマイクロサービス、自動化ツールによる恩恵です。小規模な開発の繰り返しを基本とするので、バグや不具合を見つけやすく、迅速に対応できます。またCI/CDツールによる自動テストにより、信頼性の高いサービスを提供できるようになります。

「拡張性の向上」は、インフラストラクチャをコードとして管理するIaCによる恩恵です。インフラやサーバーを標準化されたパターンで迅速にデプロイできるので、システムの拡張も容易になります。

「顧客満足度の向上」は、開発チームと運用チームの連携強化や、フィードバックを迅速に反映させやすいアジャイル開発やマイクロサービスといった開発手法による恩恵です。継続的な改善を続けることで、ユーザーの要求に柔軟に対応し続けることが、DevOpsの大きな目的と言えます。

【関連記事】

DevOpsのデメリット

DevOpsの導入には、いくつかのデメリットや課題も存在します。一般的に考えられるデメリットは以下のとおりです。

• 複雑性の増大
• コストの増加
• セキュリティ対策
• 困難な組織文化変革

「複雑性の増大」は、DevOpsがさまざまなツールやプロセスを統合することによる弊害です。多くのツールを併用するためにITインフラストラクチャの複雑性が増し、管理やトラブルシューティングが困難になることがあります。

「コストの増加」は、新しいハードウェアやツールの購入、専門家の雇用などでコスト負担が増加する問題です。

「セキュリティ対策」は、新機能を迅速にリリースできることの弊害になります。DevOpsは高頻度のソフトウェア改修を可能にしますが、一発で自動的に本番環境をアップデートできるため、セキュリティの脆弱性が存在しないかどうか毎回十分気をつける必要があります。

「困難な組織文化変革」は、DevOpsの実施に不可欠な組織文化変革が難しいことを意味します。DevOpsで最も重要となるのは開発手法や専用ツールの導入ではなく、チームスタッフや管理者の意識改革にあります。個々人がDevOpsの意義を汲み取り、自己組織化を果たして開発に取り組まなければ、DevOps本来の効力は発揮できません。そのために組織文化そのものを変える必要も出てくるのですが、このような変革は一朝一夕で達成できるものではありません。

また、企業や組織によって条件はバラバラなので、これといった正解をすぐに出せない点も、困難さを増大させます。

以上のように、DevOps導入には超えなければならない壁がいくつか存在します。

DevOpsで最も重要なのは一人ひとりの考え方

DevOpsは開発チームと運用チームの連携を強化することで、インフラストラクチャの管理を容易にしたり、運用時の問題点や要望といったフィードバックを吸い上げやすくして、新機能開発を迅速に行うことを大きな目的としています。

そのための支援ツールとして、CI/CDやIaCといった自動化ツールの利用が推奨されています。

そして、DevOpsで最も重要なのは組織全体にわたる一人ひとりの考え方です。チームの連携を強化するには他メンバーへのリスペクトとコミュニケーション能力が不可欠ですし、トップダウンで指示を待つのではなく、自己組織化により自ら問題解決へ動き出せる開発者が求められます。

そのようなメンバーが生まれる環境をつくるには、組織の文化そのものを変革する必要もあるでしょう。ある意味、DevOps導入にとって一番難しい部分とも言えるかもしれません。

また、その組織文化についても規模や形態がバラバラなために目指すゴールに明確な答えはなく、何度も試行錯誤したり経験豊富なDevOpsコンサルタントの協力を得る必要があるかもしれません。

IT系の技術となるとツールや手法に強い関心が向きますが、ソフトウェア開発で重要なのはやはり人であるということをDevOpsは再認識させてくれます。

【関連記事】

【関連記事】