DevOpsは、ソフトウェア開発チームとIT運用チームの作業を統合して自動化し、高品質なソフトウェアを迅速に提供できるようにします。

DevOpsという言葉の原義は、これまでばらばらに業務を遂行していた開発チームとIT運用チームという2つのグループの取り組みを自動化し統合することで、ソフトウェア開発プロセスと組織文化の変化の道筋を示し、高品質なソフトウェアを迅速に提供することです。   

実際には、非常に優れたDevOpsのプロセスと文化は、開発と運用を超えて拡張し、すべてのアプリケーションの利害関係者（プラットフォームとインフラストラクチャーのエンジニアリング、セキュリティー、コンプライアンス、ガバナンス、リスク管理、基幹業務、エンド・ユーザー、顧客を含む）からの情報をソフトウェア開発ライフサイクルへと組み込みます。  

DevOpsは、過去20年以上にわたるソフトウェア・デリバリー・サイクルの進化の現状を表しています。対象には、数カ月または数年ごとのアプリケーション全体の巨大なコード・リリースから、毎日または1日に数回の頻度でリリースされる小さなフィーチャーや機能の反復的な更新までが含まれます。

究極的には、DevOpsとは、頻繁にリリースされる革新的な新機能と、中断のないパフォーマンスと可用性を求める、ソフトウェア・ユーザーの高まり続ける需要に応じることを指します。

2000年の直前まで、大半のソフトウェアは、大規模な開発プロジェクトへの線形アプローチである、ウォーターフォール型の手法を用いて開発・更新されていました。 ソフトウェア開発チームは数カ月をかけて新規コードの巨大な本体を開発していました。このコードはアプリケーションの大部分またはすべてに影響を与えるものであり、  その変更はあまりにも広範囲に及ぶため、開発チームは新規コードをコード・ベースに統合するために、さらに数カ月を費やしていました。 

次に、品質保証（QA）、セキュリティー、運用の各チームがさらに数カ月かけてコードのテストを実施しました。 その結果、ソフトウェアのリリース間隔は数カ月から数年に達し、多くの場合でリリースの合間にいくつかの重要なパッチ提供やバグ修正も行われました。 機能提供に対するこのビッグバン型アプローチには3つの特徴があります。複雑でリスクの高いデプロイメント計画、スケジュール設定が困難な上流システムと下流のシステムでの連動、実稼働までの数カ月間にビジネス要件が大きく変化しないというITの「大きな期待」、の3つです。

開発を速めて品質を向上させるために、開発チームはアジャイル・ソフトウェア開発手法を採用し始めました。この手法は線形ではなく反復型であり、より小さくて頻繁な更新をアプリケーションのコード・ベースに加えることを重視しています。 これらの手法の中心となるのが継続的インテグレーション と継続的デリバリー、つまりCI/CDです。   CI/CDの新規コードの小さなチャンクは、1週間または2週間ごとにコード・ベースにマージされてから、自動的に統合・テストされ、実稼働環境にデプロイされる準備が整います。 アジャイル手法は、ビッグバン型アプローチを一連の「より小さく簡単な仕事」に進化させ、さらにリスクも細分化させました。

これらのアジャイル開発プラクティスがソフトウェアの開発とデリバリーをより効果的に加速させるほど、未だにサイロ状態であるIT運用（システム・プロビジョニング、構成、受け入れテスト、管理、監視）が、ソフトウェア・デリバリー・ライフサイクルの次のボトルネックであることが、さらに明らかになりました。 

このような経緯で、DevOpsはアジャイル手法から生まれました。 DevOpsは、新規のプロセスとツールを追加して、CI/CDの継続的な反復と自動化をソフトウェア・デリバリー・ライフサイクルの他の部分にも拡張しました。 また、プロセスのあらゆる段階において、開発と運用との緊密な連携を実現しました。

DevOpsライフサイクル（線形で描かれる場合は継続的デリバリー・パイプラインとも呼ばれます）とは、反復的な自動化された一連の開発プロセスです。または、高品質なソフトウェアの迅速な提供を最適化するように設計された、より大規模で、自動化された反復型開発ライフサイクルの中で実行されるワークフロー を指します。 ワークフローの名称と数は、場合によって異なりますが、通常は次の6つに要約されます。

• プランニング（または構想）。 このワークフローでは、チームは次のリリースに盛り込むフィーチャーと機能を詳しく検討します。このとき、優先順位付けされたエンド・ユーザーのフィードバックとお客様事例、すべての内部ステークホルダーからの意見を取り入れます。 このプランニング段階での目標は、提供時に価値ある望ましい成果を生み出す機能のバックログを作成して、製品のビジネス価値を最大化することです。
  
  
• 開発。 これはプログラミング段階であり、開発者がバックログ内のユーザー・ストーリーや作業項目に基づいて、新規機能と拡張機能のテスト、コーディング、ビルドを行います。 テスト駆動開発（TDD）、ペア・プログラミング、ピア・コード・レビューなどの手法を組み合わせることは一般的です。 多くの場合、開発者は、ローカル・ワークステーションを使用してコードの作成とテストを繰り返し実行し、その後、継続的デリバリー・パイプラインに送信します。
  
  
• 統合（ビルド、または継続的インテグレーションと継続的デリバリー（CI/CD））。 上述のとおり、このワークフローでは、新規コードが既存のコード・ベースに統合され、次いでテストされ、デプロイメント用の実行可能ファイルにパッケージ化されます。 一般的な自動化作業には、コード変更の「マスター」コピーへのマージ、ソースコード・リポジトリーからのコードのチェックアウト、さらにはコンパイル、単体テスト、実行可能ファイルへのパッケージ化の自動化などがあります。 ベスト・プラクティスは、次のフェーズのために、CIフェーズの出力をバイナリー・リポジトリーに保管することです。
  
  
• デプロイメント（通常は継続的デプロイメントと呼ばれています）。 ここでは（統合からの）ランタイム・ビルド出力がランタイム環境（この環境は通常、品質、コンプライアンス、セキュリティーのためにランタイム・テストが実行される開発環境を指します）にデプロイされます。 エラーや障害が検出された場合、開発者はエンド・ユーザーが問題を確認する前にインターセプトして修復する機会があります。 一般的には開発、テスト、実稼働のための環境が存在し、各環境では段階的に「厳格さを増す」品質ゲートが求められます。 実稼働環境へのデプロイメントのための適切な手法は通常、エンド・ユーザーのサブセットに最初にデプロイし、その後、安定性が確立した後にすべてのユーザーにデプロイするというものです。
  
  
• 運用。 機能を実稼働環境に提供することを「1日目」と見なす場合、機能が実稼働の「2日目」で実行されると運用が発生します。  機能のパフォーマンス、動作、可用性をモニターすると、これらの機能がエンド・ユーザーに付加価値を提供できるようになります。 ネットワーク、ストレージ、プラットフォーム、計算およびセキュリティー態勢がすべて正常であることを確認することで、運用によって、機能がスムーズに実行すること、サービス内に障害がないことが保証されます。 何か問題が生じた場合、運用では、インシデントの特定、適切な担当者へのアラート通知、問題の判別、修正の適用が確実に行われるようにします。
  
  
• 学習（フィードバックと呼ばれることもあります）。 フィーチャー、機能、パフォーマンス、ビジネス価値に関するエンド・ユーザーと顧客からのフィードバックを収集して、次にリリースする機能拡張や機能のプランニングに戻すことを指します。 これには、運用アクティビティーからの学習とバックログ項目も含まれ、将来的に再発する可能性のある過去のインシデントを開発者がプロアクティブに回避できるようにします。 この時点でプランニング・フェーズへの「ラップアラウンド」が発生するため、「継続的な改善」が実現します。

その他3つの重要な継続的ワークフローは、これらのワークフローの合間に発生します。

継続的テスト：古典的なDevOpsライフサイクルには、統合とデプロイメントの間に発生する個別の「テスト」フェーズが含まれます。  しかし、進化したDevOpsでは、プランニング（ビヘイビアー駆動開発）、開発（単体テスト、契約テスト）、統合（静的コード・スキャン、CVEスキャン、リンティング）、デプロイメント（スモーク・テスト、ペネトレーション・テスト、構成テスト）、運用（カオス・テスト、コンプライアンス・テスト）、学習（A/Bテスト）において、テストの特定の要素が発生するようになっています。 テストは、リスクと脆弱性の特定のための強力な形式であり、IT部門には、リスクの受け入れ、緩和、修正のための機会が提供されます。

セキュリティー：ウォーターフォール手法とアジャイルな実装は、デリバリーまたはデプロイメント後にセキュリティー・ワークフローを「追加」します。一方でDevOpsは、セキュリティー問題の解決が最も容易で最もコストがかからない最初（プランニング）の段階から、さらに開発サイクルの残りの段階全体を通じて、セキュリティーを組み込むことを目指しています。  セキュリティーに対するこのアプローチは、シフト・レフト（図1を参照）と呼ばれます。 一部の組織は、他の組織と違ってシフト・レフトに成功していないため、これがDevSecOpsの台頭につながりました（以下を参照）。

コンプライアンス： 法規則の遵守（ガバナンスとリスク）に対する取り組みも、開発ライフサイクルの初期および全体を通して行うことが最善となります。  規制を受ける業界は頻繁に、特定レベルの可観測性、追跡可能性、ランタイムの稼働環境での機能の提供方法と管理方法へのアクセスを提供するように義務付けられています。 そのためには、継続的デリバリー・パイプラインとランタイム環境でのプランニング、開発、テスト、ポリシー適用が求められます。 コンプライアンス測定の監査能力は、サード・パーティーの監査員にコンプライアンスを実証する上で極めて重要です。

DevOpsメソッドは、DevOps文化という、これまでと違うソフトウェア開発への組織的・技術的なアプローチへのコミットメントなしには機能しないというのが一般的な見識です。

組織レベルでは、DevOpsは、すべてのソフトウェア・デリバリー・ステークホルダー（具体的に言うと、ソフトウェア開発チームとIT 運用チームのことですが、セキュリティー・チーム、コンプライアンス・チーム、ガバナンス・チーム、リスク・チーム、基幹業務チームも含みます）間での継続的コミュニケーション、コラボレーション、共有責任を必要とします。これにより、迅速かつ継続的なイノベーションと、初期段階からソフトウェアに品質を組み込むことが可能になります。

ほとんどの場合、これを実現する最善の方法は、サイロ化した各チームを解体して、機能横断的で自律型のDevOpsチームに再編成することです。DevOpsチームは、コード・プロジェクトに最初から最後まで（プランニングからフィードバックまで）、他のチームへの引き継ぎや他のチームからの承認を待機する必要がありません。 アジャイル開発のコンテキストにおいては、共同の説明責任とコラボレーションは、共有された製品フォーカス の基盤であり、価値ある成果が得られます。

テクニカル・レベルでは、DevOpsは、プロジェクトをワークフロー内とワークフロー間で移動させ続ける自動化、フィードバック、チームが継続的にサイクルを加速させ、ソフトウェアの品質とパフォーマンスを向上させることを可能にする測定 へのコミットメントを必要とします。  

DevOpsとDevOps文化による要求では、非同期コラボレーションをサポートし、DevOpsワークフローをシームレスに統合し、DevOpsライフサイクル全体をできる限り自動化するツールが重視されます。 DevOpsツールのカテゴリーは次のとおりです。

• プロジェクト管理ツール：チームが、コーディング・プロジェクトを形成するユーザー・ストーリー（要件）のバックログを作成し、プロジェクトをより小さなタスクに分割し、タスクを完了まで追跡できるようにするツールです。  多くのツールで、Scrum、Lean、Kanbanなど、開発者がDevOpsに導入しているアジャイル・プロジェクト管理手法をサポートしています。 人気のあるオープンソース・オプションには、GitHub IssuesとJiraがあります。
  
  
• コラボレーティブなソースコード・リポジトリー：バージョン管理されたコーディング環境です。複数の開発者が同じコード・ベースで作業できます。  コード・リポジトリーは、CI/CD、テスト、セキュリティーの各ツールと統合されるため、コードがリポジトリーにコミットされる際には、自動的に次のステップに進むことができます。 オープンソースのコード・リポジトリーには、GiHubとGitLabがあります。
  
  
• CI/CDパイプライン：コードのチェックアウト、ビルド、テスト、デプロイメントを自動化するツールです。  Jenkinsは、このカテゴリーで最も人気のあるオープンソース・ツールです。CircleCIなど、多くの従来型オープンソース・ツールの選択肢は、今は商用バージョンでのみ利用可能です。 継続的デプロイメント（CD）ツールに関しては、Spinnakerが、コード・レイヤーとしてアプリケーションとインフラストラクチャーの間にまたがって存在するツールです。 ArgoCDも、KubernetesのネイティブCI/CDで人気のあるオープンソースの選択肢です。
  
  
• テスト自動化フレームワーク：ユニット・テスト、契約テスト、機能テスト、パフォーマンス・テスト、ユーザビリティー・テスト、ペネトレーション・テスト、セキュリティー・テストを自動化するための、ソフトウェア・ツール、ライブラリー、ベスト・プラクティスが含まれています。  最高クラスのツールでは、複数の言語をサポートしています。一部はコード変更に対応してテストを自動的に再構成するために、人工知能（AI）を使用しています。 テスト用のツールとフレームワークの範囲は実に広大です。 人気のあるオープンソースのテスト自動化フレームワークには、Selenium、Appium、Katalon、Robot Framework、Serenity（旧称Thucydides）などがあります。
  
  
• 構成管理（Infrastructure as Code）ツール：DevOpsエンジニアが、スクリプトを実行して、完全なバージョン管理と文書化が行われたインフラストラクチャーを構成・プロビジョニングできるようにします。  オープンソースの選択肢にはAnsible（Red Hat）、Chef、Puppet、Terraformなどがあります。 Kubernetesは、コンテナ化されたアプリケーションに対して同じ機能を実行できます（下記の「DevOpsとクラウドネイティブ開発」をご参照ください）。
  
  
• モニタリング・ツール：DevOpsチームがシステムの問題を特定・解決するのに役立ちます。また、リアルタイムでデータを収集して分析し、コード変更がアプリケーションのパフォーマンスにどのように影響しているかを明らかにします。  オープンソースのモニタリング・ツールには、Datadog、Nagios、Prometheus、Splunkなどがあります。
  
  
• 継続的フィードバック・ツール：ヒートマッピング（画面上のユーザーのアクションを記録）、調査、セルフサービス型の問題チケット発行を通じて、ユーザーからのフィードバックを収集するツールです。 

クラウドネイティブ は、基礎的なクラウド・コンピューティング・テクノロジーを活用するアプリケーションを構築するためのアプローチです。 クラウドネイティブの目標は、パブリッククラウド、プライベートクラウド、マルチクラウドの環境で、一貫性のある最適なアプリケーション開発、デプロイメント、管理、パフォーマンスを可能にすることです。 

今日のクラウドネイティブ・アプリケーションには通常、次のような特徴があります。

• マイクロサービス による構築：マイクロサービスは、疎結合の、独立してデプロイ可能なコンポーネントです。コンポーネントは、独自の自己完結型のスタックを持ち、REST API、イベント・ストリーミング、メッセージ・ブローカーを介して相互に通信します。
  
  
• コンテナ でデプロイ：アプリケーションの実行に必要なすべてのコード、ランタイム、オペレーティング・システム依存関係を含むコードの実行可能なユニットです。 （ほとんどの組織では、「コンテナ」はDockerコンテナと同義です。しかし、他のコンテナ型も存在します。） 
  
  
• Kubernetes を使用する大規模な運用：Kubernetesはオープンソースのコンテナ・オーケストレーション・プラットフォームです。コンテナ化されたアプリケーションのデプロイメント、管理、スケーリングをスケジューリング・自動化します。

多くの点で、クラウドネイティブ開発とDevOpsの相性は最高です。 

たとえば、マイクロサービスの開発と更新は、小さなコード・ユニットを小さなコード・ベースへ反復的にデリバリーする作業ですが、DevOpsの迅速なリリースと管理のサイクルに完璧に適合します。  また、DevOpsのデプロイメントや運用なしに、マイクロサービス・アーキテクチャーの複雑さに対処することは困難です。 開発者やITエグゼクティブに対して行った最近のIBMの調査によると、現在のマイクロサービス・ユーザーの78％が、アーキテクチャーに投資してきた時間、資金、労力が増えると予想しており、また非ユーザーの56％が今後2年以内にマイクロサービスを導入する見込みです。 

すべてのOS依存関係をパッケージ化して永続的に修正することにより、すべての統合、テスト、デプロイメントが同じ環境で行われるため、コンテナでは迅速なCI/CDとデプロイメントのサイクルが可能になります。 また、Kubernetesのオーケストレーションは、Ansible、Puppet、Chefが非コンテナ化アプリケーションに実行するのと同様に、継続的な構成タスクをコンテナ化されたアプリケーションに対して実行します。

主要なクラウド・コンピューティング・プロバイダー（AWS、Google、Microsoft Azure、IBM Cloudなど）は何らかのマネージドDevOpsパイプライン・ソリューションを提供します。

DevSecOpsとは、DevOpsライフサイクル全体（最初から最後まで、つまりプランニングからフィードバックを介し、プランニングへ戻すまで）にわたって、セキュリティーを継続的に統合して自動化するDevOpsです。

別の言い方をすると、DevSecOpsとは、DevOpsの最初からあるべき姿です。 しかし、DevOps採用の初期段階での2つの大きな（そして当面は克服が難しい）課題は、セキュリティーの専門知識を機能横断的チームに統合するという文化的課題と、DevOpsライフサイクルにセキュリティー自動化を実装するという技術的課題でした。 セキュリティーは、「ノーを言うチーム」として、また多くのDevOps手法でコストのかかるボトルネックとして認識されるようになりました。

DevSecOpsは元来意図されていたとおり、セキュリティーを統合・自動化するための具体的な取り組みとして出現しました。 DevSecOpsでは、セキュリティーは開発と運用に並ぶ「第一級」市民・ステークホルダーであり、製品にフォーカスして開発プロセスにセキュリティーをもたらします。 

「DevSecOpsとは」をご覧になり、 DevSecOpsの原則、メリット、お客様事例

サイト信頼性エンジニアリング（SRE）は、ソフトウェア・エンジニアリングを使用して、他の方法ではシステム管理者 が手動で行うIT運用作業（実動システム管理、変更管理、インシデント対応、緊急対応など）を自動化します。 SREは、従来型のシステム管理者をエンジニアに変えることを目指しています。

SREの最終目標はDevOpsの目標に似ていますが、より具体的です。SREは、迅速なアプリケーション開発という組織の要求と、顧客やエンド・ユーザーとのサービス・レベル・アグリーメント（SLA）で規定されたパフォーマンスと可用性の水準を満たすニーズとのバランスを取ることを目指しています。 

サイト信頼性エンジニアは、アプリケーションに起因する運用リスクの許容レベル（「エラー・バジェット」と呼ばれます）を決定し、またその水準を満たすように運用を自動化することで、このバランスを実現します。 

SREは、機能横断的DevOpsチーム内で開発と運用の橋渡し役となります。組織のSLAの条件を「破壊」することなく、DevOpsパイプラインを通じてできる限り迅速にコード変更や新機能を導入するために、チームが必要とするメトリックと自動化を提供します。 

サイト信頼性エンジニアリングの詳細はこちら