開発・運用間の諸課題を文化的な仕組みやツールの利用で解決し、継続的な価値提供を可能にするDevOpsの取り組みには、対話や協調、変化を重視するアジャイル開発手法と役割上の類似点が見られます。
今回は、まずはじめに『DevOpsとは何か』『アジャイルとは何か』について解説した上で、両者の違いやDevOpsで必要なことなどを紹介していきます。
1. DevOpsとアジャイル開発の違いとは？
DevOpsとアジャイル開発には類似する点があります。そのため意味合いを混合してしまう人や、両者の違いが分からないという人は多いのではないでしょうか。
これらの違いを理解するために、まずDevOpsとアジャイル開発それぞれの言葉の意味を解説します。
1.1 DevOpsとは
DevOpsは、開発チーム（Development）と運用チーム（Operations）が協力しあってシステムを開発・運用することでビジネスの価値を高めるための『組織的・文化的な仕組み』もしくは『開発手法』を示す用語です。
明確な定義のない用語であるため、利用される場面に応じて意味合いに誤差がありますが、基本的には『チームを越えたコラボレーションによる、顧客への継続的な価値提供』を重視するという特徴があります。
DevOpsの詳細について、こちらの記事で解説しているので興味のある方はご覧ください。
1.1.1 運用サイドと開発サイドのコンフリクトの解消が目的
開発者と運用者にはそれぞれ異なるミッションがあり、そのために対立構造が生まれるケースがあります。
例えば開発サイドが『システムに新たな機能を追加する』ことに比重を置いている一方で、運用サイドが『サービスの安定稼働』を重視している組織の場合、次のようなコンフリクトが生まれがちです。
新規機能の追加をするには運用サイドを納得させなければならず、そのために『自分たちの仕事の邪魔をされている』と運用サイドに対して不満を抱く
機能改修にはリスクがあり、障害の度に自分たちの仕事が増えるので、『新規機能を頻繁にリリースしたい』と要望する開発サイドに対して不満を抱く
しかし元を辿れば、開発も運用もビジネス上の最終的な目標は同じはずです。両者とも『顧客に価値あるプロダクトを届け続けること』が本来目指している到達点であるはずなのに、その手段の食い違いで対立しているのは、あまり良い状況とは言えません。
DevOpsはこういった対立構造を解消することを目的に、様々なアプローチから組織に働きかけを行います。
1.2 アジャイル開発とは？
アジャイルは『個人との対話』『動くソフトウェア』『顧客との協調』『変化への柔軟な対応』に重点を置く一連のソフトウェア開発手法を示す用語です。
アジャイルに属する開発手法は『スプリント』と呼ばれる1～4週間の開発プロセスを反復しながらリリースを繰り返すことを特徴としており、『メンバー間のコラボレーション』『変化への柔軟な対応』を重視する傾向にあります。
参照元：Manifesto for Agile Software Development
1.2.1 アジャイル開発とウォーターフォール開発の違い
アジャイルが導入されるまでソフトウェア開発の主流とされていた『ウォーターフォール開発』では、開発のステージを要求・設計・実装・テスト・保守など複数の段階に分割し、より上位の工程から下位の工程へと順に開発を進めていくという方式が採用されていました。
一方アジャイルでは、ソフトウェア開発の流れを『上流から下流へ』という単一的な流れではなく、顧客や状況の変化を考慮した『反復的な流れ』として捉えることにより、ウォーターフォールより柔軟に『変化』への対応を行うものとしています。
2. DevOpsとアジャイル開発は共存可能？
DevOpsは『開発』と『運用』でサイロ化した組織に働きかけ、効率的なコラボレーションを実現する『文化的な仕組み』です。
一方でアジャイルは、あくまで『ソフトウェア開発手法』のひとつです。
そのため両者は、用語としては別の領域をターゲットとしています。
異なる概念である『DevOps』と『アジャイル』は共存可能な概念なのでしょうか。
2.1 DevOpsとアジャイル開発は共存可能
『文化的な仕組み』と『開発手法』の双方を内包するDevOpsと『開発手法のひとつ』であるアジャイルとの間には以下の共通点があります。
- 『対話による変化への柔軟な対応』を重視すること
- 『迅速な価値提供』を目的とすること
またアジャイルが採用されがちなマイクロサービスアーキテクチャでは、リリース回数の増大により、運用面での課題が生じやすいです。
しかしこの問題にDevOpsの手法を適用することで、課題を解決し、スムーズな価値提供を実現できるようになります。
こういった点から両者は相性が良く、併用することで『単一のソフトウェア開発のプロセス』というミクロな視点と、『顧客・プロダクト間の継続的な関係』というよりマクロな視点の双方でより一掃の改善効果を狙うことができます。
3. DevOpsを実現するために必要なこと
開発や運用といったチームの枠を越えた組織改善を行うDevOpsは、その広範なターゲットのため、実現のために多くの施策を必要とします。
これには単なるツールの導入だけではなく、メンバー間の尊重や信頼など明確な形のない『文化』に関わるものも含まれます。
ここでは、DevOpsを実現するために何が必要なのかについてひとつずつ紹介していきます。
3.1 組織文化
エンドユーザーへの継続的な価値提供のためには、組織内の情報の流れが良好である必要があります。
開発・運用間で必要な情報を滞ることなくスムーズに連携するためには、組織の文化が重要な役割を果たすとされています。
DevOpsの先駆けとなったFlickr社では、組織文化として次の4つのことを重視しています。
- 互いを尊重する
- 互いを信頼する
- 失敗に対し健全な態度を取る
- 失敗した相手を非難しない
参照元：10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
互いを尊重する
メンバー同士が互いを人として思いやり尊重することは、組織内の共感や親密さに繋がります。
またメンバー間の積極的な協力のためにも、互いを尊重する人間らしい関係が大切です。
互いを信頼する
信頼のない組織では、メンバー間・チーム間のコミュニケーションが阻害され、仕事の品質がそうでない組織と比べて下がってしまうことがあります。
特に開発と運用の間で信頼が欠如している場合、顧客への迅速かつ継続的なプロダクト提供の流れに滞りが生じてしまいます。
失敗に対し健全な態度を取る
失敗、特にヒューマンエラーは必ず発生します。失敗に対して無責任になったり感情的になったりするのではなく、組織やチームの構造上の『課題』と捉えることで、今後同じミスを繰り返さないための仕組み作りに活かすことができます。
失敗した相手を非難しない
失敗に非難や処罰で対処する組織では、メンバーの多くが非難を避けるために情報を隠したり、新しいことに挑戦するのを避けようとします。するとチームやメンバー間の協力がうまく機能しなくなるばかりか、組織から変化に対応する力が失われます。
組織内で情報の流れが常にスムーズであり、変化に対応しながら価値を提供できる土台づくりのためには、非難以外のアプローチで失敗に対処することが大切です。
3.2 ツール
ツールがDevOpsの取り組みで果たす役割は、単なる仕事の効率化ではありません。
ツールは適切に利用することでチーム・メンバー間のコラボレーションを実現して、プロダクトのリリース頻度を増やしたり、品質の担保を継続的に行うことができる組織づくりに活かすことができます。
4. まとめ
DevOpsとアジャイル開発は、対話や変化への対応を重視するなど複数の共通点があります。
開発手法のひとつであるアジャイル開発と、組織を改善する文化的な仕組みという側面をもつDevOpsは、併用することで価値を高め合います。
文化的な取り組みとツールの利用で開発と運用の諸課題を解決するDevOpsは、サイロ化により情報の流れが滞るようになった組織を改善し、顧客への継続的な価値提供を実現します。
