アジャイルと DevOps の連携方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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