DevOps とアジャイルの比較

2000 年代初頭にアジャイル手法が広く採用されると、ソフトウェアやその他の製品の開発方法が大きく変わりました。しかし、業界標準になってから数年のうちに、重大な見落としが明らかになりました。つまり、ソフトウェア製品をデプロイして管理する運用チームのプロセスと要件がこの変革から取り残されていました。

これによって、開発チームと運用チームを連携させるアプローチである DevOps が考え出されました。では、DevOps はアジャイルに取って代わったのでしょうか? それとも互いに補完し合うものなのでしょうか? 両者の間には相違点と類似点がそれぞれあることがわかりました。アジャイルと DevOps は排他的でも包括的でもあり、両方が同じ組織内に存在できます。

アジャイルについて

アジャイルは、コラボレーション、顧客からのフィードバック、迅速なリリースに重点を置いたプロジェクト管理とソフトウェア開発のための反復型アプローチです。2000 年代初頭にソフトウェア開発業界から発生した手法で、これによって開発チームは変化する市場状況や顧客の要求に対応しやすくなります。

アジャイル アプローチでは、一部の計画と設計が前もって行われますが、開発は小さなバッチ単位で進行して、関係者との緊密なコラボレーションを伴います。変更は継続的に組み込まれるため、ウォーターフォール手法で開発した製品と比較して、多くの場合、製品の使用可能なバージョンがより早くリリースされます。これには多くのメリットがあります。おそらく最も重要なメリットは、ソフトウェアが顧客のニーズや期待を満たさない場合は、リアルタイムで修正できる点です。

アジャイルはさまざまな手法の集まりであり、単一の開発アプローチではありません。スクラムやエクストリーム プログラミング (XP) のほか、開発者が数年前に使用していたその他の実践システムを集めたもので、これらのアプローチを単一の原則セットにまとめようとそれぞれの実践者が意見を合わせた結果です。この統一に向けた取り組みの結果がアジャイル マニフェストであり、4 つのコア バリューに基づいた 12 の原則で構成されています。

アジャイル マニフェストの 4 つのコア バリュー

1. プロセスやツールよりも個人と対話を

2. 総合的なドキュメントよりも動作するソフトウェア

3. 契約交渉よりも顧客とのコラボレーション

4. 計画に従うよりも変化への対応を

DevOps を開始

DevOps はソフトウェア開発のアプローチであり、自動化の強化、開発チームと運用チーム間のコラボレーションの改善など、アジャイルの原則とプラクティスを組み込むことにより、チームがよりすばやく信頼できる方法でソフトウェアを構築、テスト、リリースできるようにします。開発、テスト、デプロイは、アジャイルと DevOps の両方で進められます。従来のアジャイルは運用までは入らないため、この点で DevOps が不可欠になります。

DevOps の目標は、アプリケーション ソフトウェアを記述する開発者と、そのソフトウェアを本番環境で実行する運用チームを結び付けることです。また、ソフトウェアを実行するインフラストラクチャを構築して保守することも目標です。DevOps はアプリケーションを記述する開発チームが、アプリケーションの開発経緯をほとんど知らない運用チームにアプリケーションのデプロイと管理を丸投げする従来のアプローチに代わるものです。DevOps 環境では、アプリケーションの開発、デプロイ、管理のプロセス全体を通して、開発者チームと運用チームが協力して作業します。

DevOps を理解するための基本的なフレームワークには、「Three Ways (3 つの方法)」と「CALMS」の 2 つがあります。CALMS は、Culture (文化)、Automation (自動化)、Lean (リーン)、Measurement (測定)、Sharing (共有) を表します。文化とは、開発と運用がより結合するための文化的なシフトを指します。自動化とは、ベロシティを高めてより高い品質を確保することを指します。リーンとは、継続的な改善と失敗の受け入れを原則とした実験的な考え方の基盤です。測定とは、プロセスを改善するために結果を測定することを指します。共有とは、グループの取り組みやベスト プラクティスの採用など DevOps の重要性を強調することです。

DevOps の 3 つの方法

1. システム思考 - ソフトウェア アプリが複雑なシステムであることを理解する

2. フィードバック ループの増幅 - チーム メイト間の双方向コミュニケーションを改善する

3. 文化の変化 - 継続的な実験と学習の文化

アジャイルと DevOps が連携するタイミング

DevOps は、アジャイル プラクティスが発展したもの、またはアジャイルで不足している部分と考えられます。これは、アジャイル アプローチの革新的な部分を運用プロセスに適用する取り組みです。同時に、アジャイルの欠けている部分でもあります。というのも、アジャイルの一定の原則は、DevOps プラクティスが採用されている場合にしか最も完全な形で実現されないからです。たとえば、アジャイル ドキュメントにはソフトウェアの継続的なデリバリーに関する複数の言及がありますが、デリバリー パイプラインは運用上の懸念事項を含むため、通常、継続的なデリバリーは DevOps プラクティスとみなされます。フィードバック ループを増幅するには、チーム全体そしてチーム間のコミュニケーションを改善する必要があります。アジャイル、特にスクラムは、毎日のスタンドアップ、計画会議、ふりかえりなどのさまざまなセレモニーを通じて、このコミュニケーションを促進できます。

アジャイルと DevOps の類似点と相違点

• アジャイルは開発者と製品管理のコラボレーションを重視 — DevOps は運用チームを含む

• アジャイルはアイデア化からコードの完成までのソフトウェアのフローが中心 — DevOps はデリバリーと保守にまで広げて重点を置く

• アジャイルは反復的な開発と小規模なバッチを重視 — DevOps はテストとデリバリーの自動化を重視

• アジャイルは開発者の計画作業に構造を追加する — DevOps は運用チームに共通の計画外の作業を組み込む

アジャイル マニフェストでは、個人とインタラクション、ソフトウェアの作業、顧客コラボレーション、変化への対応が明示的に優先されています。これらは DevOps の優先事項とまったく同じですが、開発プロセスだけでなく、システムや実行中のアプリケーションの管理にまで拡張されています。

さらに、アジャイル ソフトウェアの 12 原則には、DevOps の原則への言及が含まれています。たとえば、継続的インテグレーション/デリバリー、頻繁なリリースを伴う小さなバッチでの作業、自動化の使用に重点を置くことは、すべてアジャイル ソフトウェアの 12 原則で言及されています。

つまり、アジャイルと DevOps を組み合わせること

究極的には、アジャイルと DevOps の目標は同じです。つまり、ソフトウェア開発のスピードと品質を向上させることです。どちらか片方だけではほとんど意味がありません。多くのチームがアジャイル手法を使ってみてその効果がわかっていますが、一方でアジャイル アプローチで見込まれるメリットの実現に苦労しているチームもあります。これには、チームがアジャイル プラクティスを完全に理解していない、または正しく実施していないなど、さまざまな理由が考えられます。また、DevOps アプローチを組み込むことで、アジャイルに苦戦している組織のギャップが埋まり、期待していた成功を収めるのに役立つかもしれません。

アトラシアンは、アトラシアンの製品とサードパーティ ツールをまとめるオープン ツールチェーンによって、開発、IT オペレーション、アジャイル チームをつなぎます。Atlassian DevOps は、チームがソフトウェアの開発と運用に必要なものをすべて提供します。今すぐ試してみましょう。