アジャイル開発はソフトウェア開発の柔軟性を高め、ビジネスニーズに対応しやすくする必要性から生まれた。迅速なプロトタイプ開発、概念実証、インキュベーターなどは、前世代の機械工学的「スカンクワークスプロジェクト」（訳注）のアナログ的アプローチに対するデジタル版となっている。
（訳注）革新的な製品や技術を開発するための独立開発チームのこと。航空機メーカーLockheed Martin（ロッキード・マーチン）の先進開発計画を担った部門の通称に由来する。
循環式のDevOpsモデル
だがプロトタイプを進化させるため、あるいは拡張するために「1回限りの」実験を捨てて最初からやり直さなければならない場合、労力は無駄になる。循環式のDevOpsモデルはその作業を捨ててしまうのではなく、ソフトウェア開発におけるアジャイルアプローチを基盤としてそれを運用的デプロイと組み合わせる。その目的は、計画、開発／コーディング、インテグレーション、テスト、リリース、デプロイ、運用、モニター、フィードバックで構成される閉ループのライフサイクル構築にある。
従来の段階的なアプローチと異なり、DevOpsの要素は継続的インテグレーション、継続的デリバリー、継続的デプロイを通じたライフサイクルの中で継続的に実行される。従ってツールに対しても違ったアプローチが必要になる。そのために「Chef」「Docker」「Puppet」などがDevOpsに関連して定着した。
しかしDevOpsには多くの課題や側面があり、ツールのポートフォリオは人やプロセスの変化に対応することが求められる。
DevOpsの異なる視点
DevOpsは視野を二極化させる傾向がある。リスクを招く危険で混乱に満ちたアプローチとして過度に慎重な見方をするか、ソフトウェア開発とビジネスの両方を変革する聖杯として過度に崇拝する見方のいずれかに分かれる。大抵の場合、どちらも正確には現実を反映していない。
ソフトウェア開発を変革するメリットについて主張したいと思うことは理解できる。だがDevOps採用の過程でありがちな多くの課題があることもよく知られている。
まずコミットメントだ。経営陣が本腰で支持しなければ、あるいは上級幹部が肩入れしなければ、このモデルは崩壊する。開発・運用チーム全体がDevOpsによって活気づけられていると信じなければならない。
“DevOpsとは何か”については誰もが持論を持っていて、組織内や組織間でもさまざまな意見がある。DevOpsチームが従来型のチームやサードパーティーと並行して仕事をすることもある。
共通認識を形成するためには、完全にオープンかつ透明で、完成されたコミュニケーションが欠かせない。だがほとんどの組織は、変化に対する抵抗や惰性があるのが普通だ。
失敗に対する（正当な）不安などの障壁が存在するかもしれない。それが変化を積極的に受け入れる個人さえも妨げ、あるいは思いとどまらせることもある。組織の構造や予算体系が変化を遅らせる可能性もある。完全なアジャイルDevOpsアプローチの活用に際してはそれが最大の課題になる。
経営陣のバックアップ
プロセスを加速し、文化を変え、誰もがメッセージを理解するためには、個々のDevOpsチームを越えた経営陣の十分なバックアップがなければならない。それを基盤として、社内外の運用上の「関係」と手順に関する課題に対応する必要がある。ツールや技術への投資に関する意思決定の分野も重要だ。
摩擦が生じる分野の一つに、役割間の成熟度のミスマッチがある。アジャイルの手順や手法を既に採用している担当者は、他のチームメンバーの先を行っている。運用やテスト、品質保証の担当者は、一見すると急激で構造化されていないアプローチに対するなじみが薄く、自信が持てないこともあって、より多くのサポートを必要とする。
Pulse SecureやArxan Technologiesといった企業のツールは、セキュリティにフォーカスし続ける助けになる。最大限の恩恵を受けるために求められる水準の自動化を前提とすると、運用やテスト担当の技術者は、コーディングスキルを学んだり復習したりする必要があるかもしれない。
従来型のソフトウェア開発との統合も必要になる。ほとんどの組織にとって、真っさらな環境と人材およびリソースを使って何もない所からやり直す余裕はない。DevOpsは、担当者間の協調の仕方にも大きな変化を要求する。マルチクラウドベース開発に対応し、促進させるツールも必要だ。その推進には大手クラウドサプライヤーのAmazonやGoogle、そしてとりわけMicrosoftが力を入れている。他にもAtmoseraやMorpheusなどもDevOpsを効率的に導入する手段を提供している。
必要なスキルやリソースが全て社内にある組織はほとんど存在しないことから、外部のプロバイダーが必要になることもある。だが密接に組み合わされ、ペースが速く、実験的なスタイルのDevOpsは、従来のようなアウトソーシングのコストモデルにはうまく合わない。外部との関係には新たな基盤が必要になる。
DevOpsの「継続的」側面から生まれる大きなメリットは、プロセスの最適化と自動化に左右される。継続的サイクルをサポートしてITをビジネスニーズに近づけるためのツールは、Electric CloudやPlutoraなどが提供しており、ソフトウェアのデリバリープロセスを変革的に加速させることができるかもしれない。
初期のDevOpsは人とプロセスに重点を置く必要がある一方で、技術の採用に影響を及ぼす課題も幾つかある。それは大規模な組織や確立された組織の方が顕著に表れるが、DevOps戦略を採用するどんな企業にも影響を及ぼす。
どんな新興トレンドにもいえることだが、この流行の波に乗って「ソリューション」の提供を持ち掛ける多方面からの参入ラッシュが突如として起きる。多くのサプライヤーが、「これを導入すればDevOpsができる」と位置付けた製品やサービスを売り込む。うまくやるためには、スピードだけでなく品質においても開発者の効率性を向上させる実績を持つサプライヤーを見つける必要がある。
DevOpsツールの選定において、プロプライエタリなソリューションに固執するメリットはほとんどない。DevOpsツールに行き渡っている多くのイノベーションは、草の根的な進展とオープンソースから来ており、CloudBeesのような企業がエンタープライズ向けの「Jenkins」サポートを提供している他、Dockerコンテナ化ソフトウェアはオープンソース版と有料のエンタープライズ版の両方がある。HashiCorpは同社独自のオープンソースツールに対応した自動化ツールを開発している。
ただし、開発者に過剰な選択肢や自由を認めると別の課題が生じ、特に長期的なメンテナンスと有効性が問題になる。サードパーティーと連携する上での課題もある。利用できるツールの幅広さには価値があるものの、優れたガバナンスのための基準や枠組みを構築することが必要になる。
組織はビジネスプロセスの再編にはかなり慣れていて、技術的方向性を変えることにもなじみがある。だが文化を変えることは、よく話題にはなるものの、達成が難しい。それでもDevOpsには頻繁に繰り返されるテーマが多数ある。
1．なぜDevOpsなのか
第一に、何を達成するためにDevOps戦略を導入するのかを定める。目標は開発の迅速化か、品質の向上か、あるいは顧客の需要や期待に近づくことか。包括的な目標は行動の原動力になる。
2．上層部のバックアップ
上層部のサポートによって、チームを活気づけることに貢献してもらう。DevOpsでは実験が許され、これは報いのない失敗を伴う。積極的なステークホルダーを得て、チームに目標を周知させ、経営上層部からの全面的なサポートとバックアップがあることを周知させる。
3．小さく始める
真の特定可能なビジネスニーズを追求し、自己完結型かつ製品化が可能で、顧客への影響が目に見えるプロジェクトから着手する。
4．意思の連携を構築
最も熱心でDevOpsに忠実なチームからスタートする。ただしそれを「スター」、あるいは特別チームとして位置付けるという過ちを犯してはならない。このチームは他の全員と並ぶ存在でなければならない。
5．オーバーコミュニケーション
DevOpsの文化を組織全体に浸透させる必要はない。だがその認識は行き渡らせる必要がある。コミュニケーションは定期的に、広く、はっきりと行う。
6．ペースのための場
チーム全員を1カ所に集める。何らかのにぎわいをつくり出す。コラボレーションの緊密化は、コミュニケーションの質と関連性と即時性の向上を目標とすべきであって、その量を目標とすべきではない。
7．手っ取り早い勝利を収めて共有する
「良い危機を見落としてはいけない」。問題は修正する。だが最も困難で最も大きく、最も影響力の強いプロジェクトを選んではいけない。なぜなら失敗は、懐疑的な相手に立ち止まる口実を与えるからだ。手っ取り早い勝利を追求し、成功を幅広く宣伝する。自己満足のためではなく、再現するために。
8．センター・オブ・エクセレンスの確立
DevOpsを広めるための基礎を築く。そのチームを利用して、学習や他の開発チームとの共有にフォーカスする。人員の入れ替えを行って、誰もが理解し、学習できるようする。ただし最初は小さなチームから始める。
9．標準化
共通のサービスとツールを定める。ペースの遅い、あるいは従来型の開発プロジェクトと共存するために、DevOps用のガバナンスの枠組みを構築する。サードパーティー用の関わり方の標準ルールを定める。
10．障壁の除去
品質、そしてセキュリティの責任をチーム横断で共有する。品質保証に頼って最後に全てをテストするのではなく、プロセス全体を通じて品質を設計する。そうした主要な役割を担う個人は引き続き必要とされるものの、門番ではなく、権限の領域として行動する。
