「DevOps」の仕組みやメリット、課題とは？

DevOpsに関する技術解説の記事を紹介します。製品／サービス選定の参考にご覧ください。

DevOpsとは

　アジャイル開発はソフトウェア開発の柔軟性を高め、ビジネスニーズに対応しやすくする必要性から生まれた。迅速なプロトタイプ開発、概念実証、インキュベーターなどは、前世代の機械工学的「スカンクワークスプロジェクト」（訳注）のアナログ的アプローチに対するデジタル版となっている。

（訳注）革新的な製品や技術を開発するための独立開発チームのこと。航空機メーカー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には頻繁に繰り返されるテーマが多数ある。