ソフトウェア開発工程
中心となる活動
ソフトウェア ソフトウェア開発 要求分析 ソフトウェアアーキテクチャ ソフトウェア設計 ソフトウェアエンジニアリング プログラミング ソフトウェアテスト デバッグ ソフトウェアデプロイメント ソフトウェア保守
パラダイムとモデル
アジャイルソフトウェア開発 ソフトウェアクリーンルーム 反復型開発 ソフトウェアプロトタイピング スパイラルモデル V字モデル ウォーターフォール・モデル
ソフトウェア開発方法論とフレームワーク
適応型ソフトウェア開発（英語版） DevOps ディシプリンド・アジャイル・デリバリー（英語版） 動的システム開発手法（英語版） ユーザー機能駆動開発 反復型開発 かんばん リーンソフトウェア開発（英語版） LeSS（英語版） モデル駆動工学 Microsoft Solutions Framework（英語版） パーソナルソフトウェアプロセス（英語版） 高速アプリケーション開発 ラショナル統一プロセス Scaled agile framework スクラム SEMAT（英語版） Team software process（英語版） OpenUP（英語版） 統一プロセス エクストリーム・プログラミング
開発支援
ソフトウェア構成管理 ソフトウェアドキュメンテーション ソフトウェア品質保証 ソフトウェアプロジェクト管理 ユーザーエクスペリエンス
プラクティス
受け入れテスト駆動開発（英語版） ビヘイビア駆動開発 Collective code ownership（英語版） 継続的インテグレーション 継続的デリバリー ドメイン駆動設計 ペアプログラミング 実例による仕様（英語版） スタンドアップ・ミーティング（英語版） テスト駆動開発
プログラミングツール
コンパイラ デバッガ リンケージエディタ 性能解析 GUIビルダ UML tool 統合開発環境 ビルド自動化 アプリケーションリリース自動化 Infrastructure as code カテゴリ:ソフトウェアテストツール
標準と機関
BABOK Capability Maturity Model Integration IEEE Standards Association ISO 9001 ISO/IEC JTC 1/SC 7（英語版） PMBOK SWEBOK ITIL
用語集
人工知能の用語集（英語版） コンピュータ科学の用語集（英語版）
ソフトウェア工学
表 話 編 歴

DevOps（デブオプス^[1]）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす^[1]。ソフトウェアを迅速にビルドおよびテストする文化と環境により、確実なリリースを、以前よりも迅速に高い頻度で可能とする組織体制の構築を目指している^[2]。

従来の機能別に分離された組織では、このような開発部門とIT部門の部門間統合はほとんどない。しかし、DevOpsでは、開発部門、IT運用部門、あるいは品質保証（QA）部門が協力するプロセスと方法を推進している。CI/CD が自動テストや頻繁な統合などソフトウェア開発そのものに着目するのに対して、DevOps は CI/CD のような技術的な側面に加えて、開発や運用といった組織的・文化的な側面をも内包する。

DevOpsにビジネス部門を追加したBizDevOpsや、セキュリティを融合させたDevSecOpsというワードも広がりつつある。

学術的な観点から、CSIROとソフトウェア工学研究所の3人のコンピュータサイエンス研究者であるLen Bass、Ingo Weber、Liming Zhuは、DevOpsの定義を「高い品質を確保しつつ、システムへの変更をコミットしてから通常の運用に移るまでの時間を短縮することを目的とした一連のプラクティス」とすることを提案している^[3]。しかし、2015 年現在、DevOpsという用語は複数の文脈で使われている^[4]。

2008年のアジャイルカンファレンスにおいて、アンドリュー・クレイ・シェーファーとパトリック・デボイス が「アジャイル・インフラストラクチャ」について議論した。そして、DevOpsという用語は2009年ベルギーで初めて開催された「DevOpsDays」から普及し、以後、世界中の多くの国々で「DevOpsDays」カンファレンスが開催されている。^[5]

DevOpsは文化的な移行と（開発、運用、テストの部門間の）協力の概念であることから、単独での「DevOpsツール」というようなものはなく、複数のツールで構成される「DevOpsツールチェーン」となる。DevOpsツールは、主にソフトウェア開発とデリバリー・プロセスの側面を有しており、一般的には1つ以上のカテゴリに分類される。^[6][7]

1. コード ： コードの開発とレビュー、バージョン管理ツール、コードのマージ
2. ビルド ： 継続的インテグレーションのツール、ビルドステータス
3. テスト ： パフォーマンスを決定するためのテストと結果
4. パッケージ ： 案件リポジトリ、アプリの展開前ステージング
5. リリース ： 変更管理、リリース承認、リリース自動化
6. コンフィギュレーション ： インフラストラクチャの設定と管理、インフラストラクチャとしてのコードのツール
7. モニター ： アプリの性能監視、エンドユーザーエクスペリエンス

利用可能なツールは多数あるが、会社・組織でDevOpsツールチェーンを利用するには、カテゴリの特定が必要となる。その基本的なツールを特定する方法は既存の文献で探すことができる。DevOpsの実現には構成管理ツールであるDocker（コンテナリゼーション）、Jenkins（継続的インテグレーション ）、Puppet（インフラストラクチャとしてのコード）、またはVagrant（仮想化プラットフォーム）などが用いられることもあり^[8]、DevOpsツールの検討で頻繁に参照される。DevOpsという語句からこうしたツールがイメージされることもある。

DevOpsの概念はアジャイルソフトウェア開発といった概念とも関連している。ただし似てはいるが、方法は異なる。アジャイルソフトウェア開発は考え方と学びを変えることが組織改革につながるという手法であり、DevOpsは組織改革を強化することで目標を達成する手法である。^[9] 小さな変更を頻繁にリリースすることの多いアジャイルソフトウェア開発においては、開発担当者と運用担当者の連携を密にする必要があり、こうした開発手法の普及とともにDevOpsの考え方が広まることとなった。アジャイルソフトウェア開発が拡がるにつれて、リリース回数が増加する傾向のなかでDevOpsが開発された。 DevOpsの目標の一つは、より信頼性の高いアプリがより早く頻繁にリリースされる環境を作ることである。この目標を達成するために、リリース管理者は継続的なデリバリー方法を取りながら、アプリケーションリリースの自動化や継続的な統合ツールなどを利用し始めている。 DevOpsに関わる多くの考え方や関係者は、エンタープライズシステムの管理とアジャイルソフトウェア開発の潮流のなかから生まれた。

DevOpsと継続的デリバリーはともにアジャイルメソッドとリーン生産方式を背景としているため、間違われやすい。似てはいるが、異なる概念である^[9] DevOpsはより広い範囲を対象にしており、主なポイントは：

• 組織改革：ソフトウェアデリバリーに関わるさまざまなチーム（開発、IT運用、品質保証・QA、管理など）の協力を育む
• 自動化：ソフトウェアデリバリー・プロセスを自動化する

継続的デリバリーはデリバリー・プロセスを自動化することを目的にしているだけで、主なポイントは：

• 異なるプロセスの組み合わせ
• プロセスの迅速かつ頻繁な実行

DevOpsと継続的デリバリーは共通の目標を達成するために、一緒に使用されることもある。社内に小さくて速い変化がよく伝達され、協力体制がある場合、リスクを低減しながら、迅速な市場投入を支援し、エンドユーザーの価値にフォーカスすることができる。

DevOpsが特定する目標はデリバリー・パイプラインの全体にまたがる。例えば、展開頻度を改善する場合の目標は、^[10]

• 市場投入までの時間短縮
• 新しいリリース時の失敗率低減
• 修正の間にリードタイムを短縮
• 回復時間の短縮（新しいリリースでクラッシュしたり、現在のシステムを無効にすることがある場合）

DevOpsアプローチを使用することで、シンプルなプロセスであってもよりプログラムの可用性が高まり、ダイナミックなプロセスになる。DevOpsは運用プロセスの予測可能性、効率性、セキュリティ、又は保守性を最大化することを目指している。しばしば、自動化がこの目標を支援する。 また別の目標として、信頼性とセキュリティを改善しながら、迅速な開発と展開サイクルを提供することがある。そのために、DevOpsの統合は、製品の出荷、継続的なテスト、品質テスト、機能開発、又はメンテナンスリリースを対象としている。 開発環境を標準化することで、DevOpsは組織のソフトウェア・アプリケーション・リリース管理を支援する。リリースイベントを簡単に追跡することができ、文書化されたプロセス制御と細かいレポートの問題を解決できる。DevOpsアプローチにより、開発者は環境をより詳細に制御することができ、インフラストラクチャによりアプリケーション中心的な理解を反映することができる。

DevOpsを試している会社・組織からは、大きなメリットが報告されている。

• 市場投入までの時間の短縮
• 高い顧客満足度
• 改良された製品の品質
• 改良されて、信頼性の高いリリース
• 改良された生産性・効率
• 迅速な実験によって、適切な製品を構築する能力

DevOpsの実現には単なるツールやプロセスの変更だけではなく、本質的な組織文化の転換が必要となる。以下のように各部門の持つ役割と性質が相反するため、組織文化の変化は特に困難である。

• 運用担当者は組織の安定性を求めている。
• 開発者は変化を求めている。
• テスターはリスク削減を求めている。

DevOpsの原則は強力な部門間のコミュニケーションを要求するため、チームビルディングや他の従業員参加活動がしばしば利用される。チームビルディング活動にはボードゲーム、信頼活動、従業員参加セミナーなどがある。強力な部門間のコミュニケーションを育むことで、文化の変化を促進する環境を作り出すことができる。

非常に多くのリリースを有する企業では、DevOpsの意識啓発プログラムが必要になる場合がある。例えば、DevOpsという単語は2009年のオライリー主催のイベント「Velocity 2009」において、画像ホスティングWebサイトFlickrのエンジニアにより初めて公の場で用いられた。このプレゼンテーションでは「開発と運用が協力することで、1日に10回以上のペースでのリリースが可能になる」という発表とともにDevOpsという単語が用いられた。毎日の展開サイクルは、マルチフォーカスまたはマルチファンクションアプリケーションを作成する組織では多いだろう。それは、継続的な展開又は継続的なデリバリーと呼ばれて、リーンスタートアップ方法論に関連付けられている。 2009年の会議以降、ワーキンググループ、プロフェッショナルな協会やブログ上で話題となっている。

DevOpsを効果的に実践するためには、ソフトウェア・アプリケーションはアーキテクチャ上重大な要求（ASR）と呼ばれている要求を満たす必要がある。展開性、修正可能性、テスト容易性、と監視性などASRは高い優先度を必要とする^[11] 基本的には、どのようなアーキテクチャ・スタイルでも、DevOpsを実践することは可能である。しかし、展開されるシステムを構築する場合のマイクロ・サービスのアーキテクチャ・スタイルが標準になりつつある。各サービスのサイズが小さいため扱いやすくなり、そして、継続的な編集を通じて、各サービスのアーキテクチャが見えるようになる。そのため、大きな初期設計が不要となり、ソフトウェアを早期に継続的にリリースすることができる。

DevOpsの文献には、組織のIT部門以外からのDevOpsイニシアチブへの重要な参加が必要だと勧めている記事がある。例えば、「DevOpsは、企業全体にもたらされたアジャイルの原則である」というメッセージがある。^[12]もう一つの広い範囲からの参加の例は、内部資金調達プロセスへの変更：「資金調達は通常滝のように提供される。しかし、継続的デリバリー・モデルには、適していない確定日付（月、四半期、会計年度、など）というゲートがあるので、資金調達も継続的でなければならない。」^[13] DevOpsの導入は、以下のような多くの要素によって推進されている。

1. アジャイルなどの開発プロセス・方法の使用
2. （アプリケーションとビジネスユニットの利害関係者からの）生産リリースの増加に対する需要
3. （内部と外部の提供者からの）仮想とクラウドインフラストラクチャの幅広い利用可能性
4. データセンターの自動化と構成管理ツールの使用の増加
5. テストの自動化と継続的な統合方法の重点
6. 公開されている大量の最善の措置

制約の理論は、DevOpsの導入に適用される。単一の制約とは、企業内の部門の変更に対する先天的な嫌悪感である。増分導入では、制約の理論の方法論を具現化し、「5つの焦点のステップ」として知られている制約を克服するためのステップを提供する。 増分導入のアプローチは、企業全体に広範な実装を成功させるために、必要な社内のスキルセットと勢いを構築しながら、DevOps導入のリスクとコストを最小限に抑えるという考えを中心にしている。ジーン・キムの「3 つの基本原則」は、さまざまな方法でDevOpsを増分的に導入している。

特定のひとつの部門（または個人）のパフォーマンスではなく、システム全体のパフォーマンスに重点を置いている。重点はITを扱うすべてのビジネスバリューストリーム上にある。このプロセスは線形に流れるため、欠陥が通過しないことを保証する。

関係しているすべてのチームのフィードバックと理解の向上に重点を置いている。その結果として、顧客（内部と外部）へのコミュニケーションと応答を向上させ、フィードバックループを短縮、増幅し、知識を必要な場所に伝える

実験と実践が同様に重要である。リスクから学ぶこと、反復、又は練習を職場文化に組み込むことは、熟練への鍵である。リスクを取って実験したり、改善と習得を促進したりすることで、間違いを取り返すために必要なスキルを身につけることができる。

• ソフトウェア開発方法論
• アジャイルソフトウェア開発
• 継続的インテグレーション
• BizDevOps

• ITpro - キーワード「DevOps」