アジャイルと DevOps: 敵か味方か

DevOps はソフトウェアチームの枠を超えて導入されるアジャイルです。実際のところ、どちらがより有用なのでしょうか。

Ian Buchanan Ian Buchanan
トピック一覧

一方には、友人にはエクストリームプログラマーとして知られ、子供たちには LeSS、SAFe、DAD、つまりアジャイルとして知られている認定スクラムマスターがいます。

もう一方には、リーンを推進し、インフラストラクチャをコードとして継続的にデリバリーし、左腕には開発、右腕にはオペレーションと名付けた DevOps がいます。

少し誇張しすぎましたが、アジャイルDevOps に関するこの短い説明を読むと両者はまったく異なるアイデアのようにも見えます。少しややこしいですが、どちらのコンセプトも定義を拒絶し、それぞれ独自の用語やスローガンがあるようにさえ見えます。より長い歴史を持つアジャイルはそれほど漠然とはしていませんが、定義だらけの DevOps からしてみればイライラさせられることがよくあります。定義が不足していることで対立が起きることもあります。

多くの人がアジャイルとはスクラムのことで、DevOps とは継続的デリバリーのことだと考えています。このようにコンセプトが単純化されすぎることで、アジャイルと DevOps の間に不必要な緊張関係が生まれ、互いに相性が良いことに気付いて驚かされることになるのです。

DevOps とアジャイルには歴史的な関係があることを否定する人はいません。Patrick DuBois 氏と Andrew Clay Schafer 氏がアジャイル 2008 カンファレンスで「アジャイルインフラストラクチャ」について言及したとき、DevOps との関係が産声を上げました。Patrick 氏はその後「DevOps」という言葉を生み出しましたが、アジャイルカンファレンスでは引き続き DevOps との関係を大切にしています。しかし、ここでは歴史を振り返るのではなく、スクラムと継続的デリバリーの裏に隠されたアジャイルと DevOps との実用的なつながりに焦点を当てましょう。

アジャイルはスクラムがすべてではない

一部のチームはスクラムを、常にイライラさせられる葛藤と、生産性の高いチームの仕事とを区別するものだと捉え、一方で、政治と過度なコミットメントを排して目的と集中をもたらすものだと考えるチームもあります。そして、まるで教義のように受け入れるチームさえあります。ビジネスや仕事の制約から別の手法を採る必要がある場合、アジャイルチームはスクラムの基本原則を活用し、自分たちの仕事のやり方を調査してより効果的に進められるように適応していきます。ソフトウェア開発以外の場面でスクラムを採用する場合は、特にこれが重要になります。

計画外の作業を計画する

DevOps コミュニティのなかでアジャイル経験がある人は、計画済みの作業を追跡するのにスクラムが役立つことを認めています。オペレーションのなかでも次のような一部の作業は事前に計画を立てておくことができます: 大規模なシステム変更のリリース、データセンター間の移動、システムアップグレードの実施。しかし、オペレーションのなかでも次のような作業は事前に計画を立てておくことができません: パフォーマンスの急変、システム障害、セキュリティ侵害。これらのイベントでは迅速な対応が必要です。バックログで項目への優先順位付けや、次回のスプリントの計画セッションまで待つ暇はありません。このため、多くチームが DevOps 思考を受け入れて、スクラムからカンバンの先を思い描いているのです。これによって DevOps とアジャイル双方の作業を追跡し、互いの相互作用を理解することができます。また、スクラムバンやカンプラン (カンバンとバックログの組み合わせ) と呼ばれるハイブリッドなアプローチを採用しています。

さまざまな意味において、スクラムを広く浸透させるには、それによって技術的なプラクティスがもたらされるのではない点を理解することが重要になります。スクラムの軽量な管理プラクティスは多くの場合チームに大きな変化をもたらします。かつては複数のマスターから矛盾する優先順位が指示されていたものが、バックログに優先順位がすべてまとめられるようになります。そして、かつては大量の作業が同時進行していたものが、限られた時間のなかで実現可能なものだけに絞った計画にまとめられます。これらを組み合わせることで、チームの生産性が新たなレベルに引き上げられます。しかし、コードのレビュー自動化された受け入れテスト継続的インテグレーションなど技術的なプラクティスが不足しているという制約があることにチームは気付くことになります。

エクストリームプログラミングなどのアジャイルプロセスには、持続可能なペースを維持して上層部とステークホルダーに対する透明性と視認性をチームが実現するための技術的プラクティスに関する指示が充実しています。スクラムチームのなかにはバックログに技術的なタスクをまとめているところもあります。このやり方でもスクラムのガイダンスにはフィットしますが、フィーチャーに対するプロダクト所有者のバイアスという現実的な問題にすぐに直面することになります。プロダクト所有者が技術に精通していない限り、技術的プラクティスのコスト/メリットを評価するスキルは持ち合わせていないでしょう。技術的なタスクは信頼性やパフォーマンス、セキュリティを支えるオペレーションにも影響するため、プロダクト所有者にとってより難しい状況を生むことになります。

プロダクト所有者とサービス所有者

アトラシアンでは、取り組んでいるプロダクトに 2 つの異なる役割を設けることにメリットを感じています。プロダクト所有者はユーザーが必要とする機能を理解するのに長けていますが、パフォーマンスや信頼性、セキュリティといった、機能とは直接関係ない部分と実際の機能のバランスをとることは苦手としています。アトラシアンの一部の SaaS 製品ではサービス所有者を配置して、機能とは直接関係ない部分を担当しています。2 人のオーナーが巧みな駆け引きを演じなければならない場面も時にはありますが、その大半は個々のチームが自分たちで対応できます。これによってオペレーションからのフィードバックを増幅できるだけでなく、プロダクト所有者の機能に対するよくありがちな偏見を克服することができます。この「2 人のオーナーを置く」アプローチだけが DevOps を実現するための唯一の方法ではありません。重要なのは、機能と直接関係しない部分も「機能」として捉え、他の機能的なユーザーストーリーと同じように計画を立てて優先順位を付けるようにすることです。

結局のところ、スクラムに対するこうした批判はいずれもスクラムそのものにだけあるのではありません。他のすべてのアジャイル手法同様、スクラムにはふりかえりという「プロセス改善」メカニズムが組み込まれています。そのため、DevOps からインスピレーションを得て、スクラムのふりかえりを DevOps に向けた調整として利用しているスクラムチームがいても不思議ではありません。しかし、大半のチームが外部からのアイデアを取り入れる必要があるのもはっきりとした事実です。DevOps が主流になるまで (学校で教えられるようになるくらいまで)、DevOps はスクラムの有機的な結果にはなり得ないでしょう。チームにアジャイルコーチや DevOps コーチを迎え入れるかどうかはおそらく重要ではなく、ソフトウェアの構築、テスト、デプロイの自動化に関する経験を持ち込める人であれば誰でもよいのです。

DevOps にあるのは継続的デリバリーだけではない

デプロイの自動化では制約が厳しくなるのに対して、継続的デリバリー (CD) の原則をうまく実施すれば、同時進行の作業を制限することができます。つまり、CD では、高頻度のデリバリーと高品質の二者択一ではなくその両方をソフトウェアチームが実現できるのです。しかし、スクラムだけに集中しているチームはアジャイルの広範な意味を理解できず、継続的デリバリーに集中しているチームは DevOps の広範な意味を理解できません。

CD のプラクティスでは上層部とソフトウェアチームの間のコミュニケーションに関する問題に直接対処することはできません。上層部に年単位の予算主導型の計画サイクルがあると、各コミットを本番環境にデリバリーするチームは上層部が動きだすまで何か月も待つことになります。ほとんどの場合、これによってプロジェクトが取り消されたり、もっと悪いケースだとプロジェクトチームの数が 2 倍になったりといった事態を招くことになります (新しい人材の流入は問題を引き起こすため)。

Agile Fluency モデルでは流暢性の 1 つ目のレベルを、チームの透明性と意思統一へのこだわりである「価値へのこだわり」としています。CD にこの流暢性がないと、ビジネスにインパクトを与えるような価値を何も生み出さない技術改善の無限サイクルに簡単に陥ってしまいます。チームは短期間で高品質なものをデリバリーすることはできても、エンドユーザーやビジネスには大した価値をもたらさない製品ができ上がってしまいます。前向きな意見を言うユーザーが多くいたとしても、このように低い価値の製品は大規模なビジネスポートフォリオのレベルでしか生き残れないでしょう。この重要な流暢性がないと、技術的なプラクティスと機能を比較検討することもできません。自動化されたテストや頻繁なデプロイに適したデザインが用意されていないレガシーのコードベースを持つチームにとって、これは特に重要な意味を持ちます。従来のやり方では、CD の変革に何年もかかってしまうことでしょう。だからこそビジネス上のメリットを示すことが何よりも重要になってくるのです。

3 つの方法

DevOps とはデプロイパイプラインを自動化するだけではありません。John Allspaw 氏の発言によると、DevOps とは「開発者の思考を持ったオペレーション。オペレーションのように考える開発者」ということになります。この考え方を基に、Gene Kim 氏は DevOps の原則として 3 つの方法を示しています。

1 つ目の方法 システム思考 特定の作業や部門のサイロ (部門単位のこともあれば個人単位のこともある) のパフォーマンスではなく、システム全体のパフォーマンスに着目します。
2 つ目の方法 フィードバックループを増幅する フィードバックの一方通行のループを作成します。大半のプロセス改善活動の目標は、フィードバックループを短くしながら増幅し、必要な修正が継続してなされることです。
3 つ目の方法 継続的な実験と学習の文化 継続的な実験と、リスクを取って失敗から学ぶという 2 つの事柄を発展させ、専門的な知識を得るには繰り返しと実践が大切だということを理解できる文化を形成します。

継続的デリバリー (CD) では開発からオペレーションまでのフローを自動化する 1 つ目の方法に特化しています。自動化には、デプロイシステムを加速させるという明確な役割がありますが、システム思考にあるのは自動化だけではありません。

2 番目の方法は「開発者にもポケベルを身に付けてほしい」という一言に落とし込むことができます。ポケベルをそのまま使うという意味ではありませんが、開発者にもオペレーションの問題に関わってほしいということです。これによって開発者は、開発の結果何が起きているのかを理解できます。たとえば、開発者がログメッセージを見つけやすい場所に置くようになったり、メッセージをもっとわかりやすいものにしたりするというような効果が得られます。その効果は気付きだけではありません。開発者はシステム内部のことを理解したうえでトラブルシューティングに対応するので、解決と実装までの時間が短縮されます。

3 つ目の方法は、(パイプラインを通じてアプリケーションに変更を加えるだけではなく) 新たな手法を少しずつシステム全体に取り入れることです。つまり、自動化にどれくらいかかるかが比較的簡単にわかり、強力になっていくインフラストラクチャを使って改善を続けられるということです。ロールと組織の間のやり取りによってどれくらい遅延が発生するかを理解するのは簡単ではありません。つまり、チームはデリバリーワークフロー全体にわたって「調査を行って適応」し、人間のコラボレーションを改善できる余地を探すことになります。これに関して言うと、CD でも適応と改善を習慣にする必要があります。もしチームが効率性を上げる方法を検討していない場合は、それができるように適応しながら行動を変えていかない限り、CD の成長も繁栄もありません。チームは自分たちで問題を解決できるのだと自覚できるようになる必要があります。

スクラムでは、ふりかえりごとにプラクティスとツールの使い方を改善していきます。しかし、短期的および長期的な技術上の問題解決のためにチームがこの機会を活用しなければ、プロダクト所有者が CD タスクをバックログにおいてくれるまで待つほかありませんが、実際にこれが起こることはありません。

DevOps とはソフトウェアチームの枠を超えて導入されるアジャイル

スクラムは「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます」というアジャイル原則に沿ったものです。

継続的デリバリーは「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」というアジャイル原則に沿ったものです。

つまり、アジャイルとはスタンドアップやスプリント計画などの形式にこだわるのではなく、出たり入ったりする変更を受け入れることなのです。アジャイルマニフェストにはほかにも 10 個の原則があります。原則のなかからどれかを選ぶのではなく、すべての原則で 1 つの塊だと考えるようにしましょう。これらの原則が一体となってアジャイルと DevOps に共通する、変化に対する姿勢を形成しているのです。

このようなことを考えている人たちは、ビジネスにとって最も重要でありながら脆弱なシステムを実行するところで行き詰まっています。ビジネスにとって最も重要であるからこそ、最も緊急性の高い変更が発生する場所にもなるのです。そのため、変更を受け入れるというアジャイルの考え方は「変更のための変更」とは異なります。それは、変更の品質については開発側に責任を持たせながら、ビジネス価値を生み出すための全体的なキャパシティを改善することです。このビジネス価値に焦点を当てるという見方はアジャイルと DevOps に共通するものです。

最後になりますが、アジャイルも DevOps もそれ自体がビジネスの目標ではありません。いずれも目標を達成するための、より良い手段を組織にもたらして企業文化に変革を起こすものです。アジャイルと DevOps は両者を組み合わせることでより高い効果を発揮します。2 つのコンセプトの対立を防ぐには、両者の価値と原則をより深く理解する必要があります。単純で範囲の狭い定義ではサイロ的な思考に陥ってしまいます。アジャイルとはスクラムだけではなく、DevOps とは CD だけではないことがわかったところで、アジャイルと DevOps という強力な組み合わせに実際に取り組んでみましょう。

次の記事
Agile Teams