近年のIT市場ではAIやキャッシュレス、X-Techなどの新規サービスが次々と生まれています。しかし同時に類似する競合サービスも次々と生まれており競争は激化しています。このような状況において、サービスで得られる収益や契約者数の増加といったビジネス価値を継続的に維持・向上するには、エンドユーザのフィードバックに基づいた機能の追加や改善を迅速に行う必要があります。これを実現するための概念の一つとしてDevOpsがあります。

DevOpsという単語はDeveloper（開発者）とOperation（運用者）の頭文字を合わせたもので、Velocity 2009というカンファレンスにおいて当時Flickrだったエンジニアの発表の中で使われたのが世の中に広まったきっかけと言われています（※1）。この発表以降、さまざまなカンファレンスや書籍においてDevOpsが語られてきていますが、まだこれといったDevOpsの明確な定義は存在していません。ですが、総じて「サービスが提供するビジネス価値をエンドユーザへ迅速に届けるために、開発者と運用者が協調・連携して行う活動」といった内容が語られています。

図：DevOpsでは開発者と運用者の壁を取り除き、連携・協調して活動する

DevOpsの実践状況について、Nicole Forsgren博士をはじめとする研究チームは2013年からの4年間で2,000社、23,000件を超えるソフトウェア開発プロジェクト事例の調査を行っています（※2）。調査レポートでは、DevOpsの効果を測定するためには「リードタイム」、「リリース頻度」、「平均修復時間」、「変更失敗率」の4つの尺度が適切であると述べられ、それらの指標に応じて各プロジェクトは「ハイパフォーマー」「ミドルパフォーマー」「ローパフォーマー」の3つに分類されると報告しています。中でも2017年のデータでは、ハイパフォーマーはローパフォーマーに比べてリードタイムが440分の1、リリース頻度が46倍、平均復旧時間が170分の1、変更失敗率が5分の1という驚異的な差があると報告しています。

DevOpsを実現していくには具体的にどのように取り組んでいけばよいのでしょうか。私は業務におけるプロジェクトでの支援活動を通して、トップダウンとボトムアップの両方でのアプローチが必要であると考えています。例えばリードタイムの短縮を目的とした継続的インテグレーションや継続的デリバリーの導入は、開発者が主導のボトムアップで提案・実施がしやすい活動です。しかし、同じくリードタイムの短縮を目的とした運用手順や承認プロセスの簡易化といった抜本的なプロセスの変更や、開発チームや運用チームの統合といった組織をまたぐ対応は、ボトムアップだけでの対処が難しいことが多いため、権限を持った人によるトップダウンのアプローチも併せて行う必要があります。

DevOpsの実践に関しては近年カンファレンスでの事例発表や書籍も多く出ており、それらを参考にすれば今すぐにでも取り組める状態にあります。しかし、実際はそれぞれのプロジェクトが置かれている状況が異なるため、他社の成功事例をそのまま実践したとしても同じ結果が得られるとは限りません。実際にNTTデータにおいてDevOpsを実践し成果を上げているプロジェクトを分析したところ、以下の表のようなプロジェクト特性に応じて効果的なプラクティスやアプローチが異なることが分かってきています。DevOpsを実現するにはDevOpsを単なる手法ではなく目指すべき状態と捉え、まず自身のプロジェクトが置かれている状況からDevOpsで目指すべき目標を具体的に定義し、目標達成のために必要なプラクティスを選定・実践し、地道に改善を積み重ねていくアプローチが有効ではないかと私は考えています。