DevOps が登場してから、10 年以上の時が経過しています。 システム管理者は、効率性の高い Agile 製品開発チームの動向を追いたいと思っていました。このチームは、本番環境品質のソフトウェアを高い頻度で作成していました。 チームのソフトウェアの提供能力は向上していましたが、事前の計画や本番環境システムの展開および管理など、バリューストリームの他の分野ではボトルネックが残っていました。 その当時、このようなボトルネックが開発チームと運用チームの間に摩擦を生む原因になっていました。これは多くの組織にとって、現在でも直面している問題です。 DevOps という用語は、2008 年に Andrew Clay Shafer と Patrick Debois が考案したとされています。このコンセプトを元に、2009 年、ベルギーにおいて最初の DevOpsDays イベントが開催されました。

DevOps の実装は、ツールだけの問題ではありません。人員の働き方と、使われるプロセスの問題でもあります。 DevOps は、アプリケーションやサービスを作成する技術チームと、そのサービスの本番環境での運用を担当するチームとの間に発生してきたサイロ化を排除します。 プロセスと作業は、製品およびサービスのライフサイクル全体や、その提供と運用に必要なすべての要素に合わせて調整されます。

セキュリティやテスト機能を含めたサービスのすべての側面を 1 つのチームが管理するのが理想的です。 より規模の大きな組織では、機能面で専門チームが作られる場合もありますが、それでもプロセスとコミュニケーションにおいて、サービス全体のエンドツーエンドの提供に注目することは重要です。 この製品中心の視点は、マイクロサービスのような単純なものに基づく場合もあれば、リリースを構成するより複雑な成果物のセットに基づく場合もあります (多くの場合、状況と最終顧客により決まります)。 時間の経過とともに、より小さな変更を継続的に行い、より迅速に反復することが目標です。

新しいプロセスとチームでは、できる限りの自動化と、顧客からチームへの重要なフィードバックループを含む、製品ライフサイクルのエンドツーエンドの接続を促進する技術を活用します。

DevOps が重要なのは、ビジネスの需要に素早く反応し、組織が自らを競合他社と差別化できるポテンシャルがあるためです。 DevOps は、エンドツーエンドでのコラボレーションを改善した、より優れたソフトウェア構築方法です。これは開発チームと運用チームの間だけではなく、他の領域とのコラボレーションも含みます。セキュリティ (DevSecOps と呼ばれることもあります)、テスト (品質保証または QA)、バージョンコントロール、ChatOps などのチームをまたぐコラボレーション機能がその例として挙げられます。 DevOps はソフトウェア製品を改善し、実装を成功に導きます。

DevOps の中核にあるのはベストプラクティスです。 アプリケーションやサービスを提供する組織は、ソフトウェア開発チームが実際に協力し、継続的統合と継続的デリバリー (CI/CD) を行うことで最も効果的に機能するという前提で考えています。 つまり、毎回本番環境に展開されるとは限りませんが、どんなに短くてもすべての反復の終わりには、ソフトウェアは本番環境ですぐに利用できる状態にあるということです。 

大規模な組織が DevOps の変革を行うのは、エンタープライズソフトウェアの作成においてよくある根本的な問題を解決するためです。 開発者は、新しいソフトウェアを作成する際、オフラインの開発者環境でコーディングとテストを行います。この環境では、バグのトラブルシューティング、コードの微調整、要件対応の改善などを、自社のビジネス、政府機関、医療機関、教育機関を危険にさらすことなく行うことができます。

ただし、開発者環境と絶え間なく進化する本番環境は完全に同じではないため、新しいソフトウェアやコードを実際の環境に展開する際には、問題が発生します。 これは悩みの種であり、現実的な問題に発展することもあります。 展開に失敗すると、問題が発生し、修正に時間と予算を大幅に取られる可能性があります。 このような問題は、リリースの頻度が低い中、多数の変更を公開することで悪化するものです。

運用チームは、展開の信頼度を確保するため、製品の適切なチェックとバランス調整を行い、本番環境で確実に稼働させる責任を負います。 開発チームは、反復作業によりコード変更をできるだけ早く本番環境に実装しようとするため、運用チームとの間に摩擦が発生する場合があります。

DevOps ベースのデリバリーパイプラインでは、開発スタッフと運用スタッフを以下のような状況に置くことが重要です。

• 協力体制を改善する

• 思考と行動の波長を合わせる

• 障壁やサイロ化した構造を撤廃する

• 責任を共有する

• QA、バージョンコントロール、構成管理、リリース管理に注力し、オンラインによる継続的デリバリー活動を行います (これは一般的にバリューストリームと呼ばれます)。

開発チームと運用チームを統合し、さらに自動化を加えることで、組織はコラボレーションや仕事の文化を改善し、最終的には生産性を向上させることができます。 DevOps 統合は、インフラストラクチャとワークフローの自動化に基づいており、アプリケーションの本番環境への継続的デリバリーと、アプリケーションのパフォーマンスの定期的測定を可能にします。

DevOps モデルを使用する組織の鍵となるベストプラクティスは、自動化です。 できる限り多くのタスクを自動化すべきでしょう。特に以下の自動化が重要です。

• コードの機能、ユーザー、セキュリティのテスト

• ステージゲートやリリースを含むワークフロー

• インフラストラクチャの実装および変更

• 構成管理の変更の検証

DevOps は、ソフトウェア開発ライフサイクルを通じて動作する自動コード機能により、大きな競争優位性を提供します。 ただし、自動化機能が利用可能になっていることや、ITIL Change Management などの以前は手動だった機能の多くが次々と自動化されているということがチームに周知されない限り、自動化は実現しません。 自動化は、開発者を管理タスクから解放することで、開発者のエクスペリエンスを大幅に改善します。

DevOps のもう 1 つのベストプラクティスは、統合、テスト、モニタリング、ロールアウトを数時間でできるように、開発者がソフトウェアを小規模な単位で記述することです。 これにより、従来のような、大量のソフトウェアコードの記述やテストに数週間または数ヶ月を費やしていた状況を改善できます。開発チームは、ビジネスのニーズにより対応しやすくなり、多数の変更を含む大型リリースによる大規模な停止の可能性を低減することが可能です。 また、変更が小規模であるため、本番環境で不具合が発生した場合に元に戻すことがより簡単になります。 このベストプラクティスは、新しいクラウドネイティブのテクノロジーや、従来のインフラストラクチャを問わず適用することができます。

すべてのプロジェクトで、小規模な単位を何度も提供する手法が使えるわけではありません。より大きな DevOps のライフサイクルで、変更をまとめて、より大規模または頻度の低いリリースを行う方が合理的な場合もあります。 ただし、DevOps チームは、コードがただちに展開可能であるという原則の下に運用します。

多くの企業では、Agile 開発でかなりの経験を積み、DevOps の原則を実験的に適用するか、本格的な投資を行っていますが、DevOps はまだ大規模な組織で主力となるほどの効果はないと考える企業もあります。 このように考えるのは、DevOps の採用には人員、プロセス、テクノロジーの編成に大規模な変更が要求されるなど、多数の要素が必要になることが原因となっています。 もう 1 つの要素は、特にシステムで金融、個人識別情報 (PII)、医療データを扱う場合、大規模な企業のほぼすべてが広範囲にわたる規制の対象となることです。 大規模な組織を規制する環境があるため、IT 運用においてアプリケーションのアップデートをリリースする際に、強力な管理を行う必要があります。 この管理作業は、手動のプロセスを基にしてきたため、自動化に移行するにはよい時期であると言えます。

DevOps 実装が継続し、経験を積み、自動化が進むにつれて、DevOps は現実世界の問題やビジネス上の問題を解決するため、より頻繁に使用されるようになります。 そして、規制や管理と、スピードおよびアジリティのバランスを取ることができるようになれば、本当に新しいソフトウェアの機能を作り出す準備が整ったと言えます。DevOps 導入の成功は、この事実を正しく理解することにかかっています。これは、システムをより効率的に運用するには「計画、構築、実行」が必要であるためです。

DevOps の手法は、組織全体にインテリジェントに拡散することで、仕事のリスクを素早く排除し、IT 運用チームと開発チームの間の摩擦を最小化できます。 事業継続性のために強力な管理を必要とする大規模な企業では、バリューストリーム管理 (VSM) などの新たなテクノロジーを活用して、移行を支援することができます。

運営が順調な DevOps チームでは、反復作業を迅速に行い、小規模で頻度の高いリリースを予定通りか予定より早く公開し、本番環境での問題を低減するという、ごく基本的な形でメリットを提供します。 本番環境でバグが発見された場合でも、迅速に修正できます。またチームは、コラボレーションやバリューストリーム管理を通じて利用可能なデータを活用することで経験を積み、改善を行います。

優れた DevOps チームは、パフォーマンスの劣る他社チームの何倍もの早さでコードを展開し、失敗の回数も少なくなります。 DevOps への移行により、関係者全員が完全なライフサイクルの情報にアクセスできるようになるため、組織全体のマインドセットの継続的な改善が促進されます。 また、DevOps の新しい AI 機能により、自動化と信頼性の改善が進み、さらに効率性を高めることができます。

DevOps が適していることが明らかなビジネスケースであっても、それを実行しようとすれば、予想外の課題に直面することもあります。 企業が、ウォーターフォールから Agile ソフトウェア開発、さらに DevOps の採用に至るには、入念な準備と忍耐が必要とされます。 ただし、その見返りはかなりのものです。

安定性

DevOps の多くのベストプラクティスが、安定性の改善に役立ちます。 例えば、小規模な変更に注力することで、大規模な停止を引き起こす可能性を低減します。何か問題が発生しても、自動で素早く、何度でも元に戻すことができるのです。 DevOps の継続的な統合プロセスにより、コードの変更を適切に組み合わせ、テストを実行し、ポリシーやツールを適用して、できる限りサイクルの早期で問題を排除することができます。

セキュリティ

2019 年の Puppet 社 State of DevOps レポートでは、DevOps の強固な基盤により、セキュリティを簡素化でき、実装の信頼度が向上すると伝えられています。 セキュリティは DevOps チームと切り離せないものです。これは開発、運用、テストにおいてコードを切り離すことができないのと同様です。 コラボレーションが改善される場合、そのプロセスにはセキュリティが必ず含まれます。

速度

統合されたエンドツーエンドのチームにより、反復作業を小規模で行うと、変更点の実装をより素早く行うことができるため、チームはビジネスのニーズへの対応がしやすくなります。 構想から実際に本番環境で変更に至るまでの全体の時間が大幅に短縮され、価値実現までの時間が加速します。

コラボレーション

DevOps のメリットは、コラボレーションとコミュニケーションの改善によって一層高まります。 開発者は、本番環境でのソフトウェアのパフォーマンスに対するフィードバックを直接得ることができ、運用担当者は、サービスで提供されている内容とその理由を知ることができます。 セキュリティや品質保証の担当者など、すべての関係者が、チーム全体のサポートを通して情報を共有し、ポリシーを見直す機会を得られます。

開発チームと運用チームを協働させて、迅速にソフトウェアを構築し、コードを本番環境にリリースすることは容易ではありません。 DevOps では、文化とプロセスの変更が非常に重要です。また、適切な DevOps ツールを利用する必要もあります。 無理もないことですが、大規模組織の IT、技術、ビジネスユニットのリーダーは、多くの場合、そのような移行を計画することに不安を覚えます。 しかし、DevOps のためのビジネスケースは注目せずにはいられないでしょう。ServiceNow DevOps などの製品は、ワークフローを簡素化します。 どの組織にとっても、DevOps の展開を渋る理由などないのではないでしょうか。