NTT DATA

DATA INSIGHT

NTTデータの「知見」と「先見」を社会へ届けるメディア

絞り込み検索
キーワードで探す
カテゴリで探す
サービスで探す
業種で探す
トピックで探す
キーワードで探す
カテゴリで探す
サービスで探す
業種で探す
トピックで探す
2019年8月29日技術ブログ

DevOpsによるビジネス価値向上の実践に向けて

近年の変化の激しいIT市場においては、他社に先駆けて顧客に魅力的なITサービスを提供し、継続的に改善していくことで市場競争力を高めていく必要がある。そのために、市場や顧客からのフィードバックに迅速に対応してサービスを開発・運用していく概念としてDevOpsに注目が集まっている。

DevOpsでビジネス価値を高める

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

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

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

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

DevOpsによる驚異的な効果

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

指標指標の定義ハイパフォーマーミドルパフォーマーローパフォーマー
リードタイムソースコードのコミットから本番稼働までの所要時間1時間未満1週間から1か月1週間から1か月
リリース頻度ソフトウェアの本番環境へのリリースの頻度1日複数回週1回から月1回週1回から月1回
平均修復時間サービスダウンが発生してから復旧するまでの時間1時間未満1日未満1日から1週間
変更失敗率本番環境へリリースした時のサービスダウン発生率0-15%0-15%31-45%

DevOpsの実現にはボトムアップとトップダウンの両輪が鍵

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

実施内容例
ボトムアップのアプローチ
  • 継続的インテグレーションの導入
  • 継続的デリバリーを行うデプロイパイプラインの構築
  • プロアクティブなシステム監視の導入
  • 開発と運用の迅速な情報共有
  • など
トップダウンのアプローチ
  • 運用・承認を含む抜本的なプロセスの変更
  • 開発、運用、品質保証などの組織体制の再編
  • 失敗から学ぶ組織文化の醸成
  • など

プロジェクト特性に合ったDevOpsを求めて

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

プロジェクト特性の例内容
提供しているサービスの種別Webサービス、ECサイト、スマートフォンアプリ、業務システムなど
開発・運用体制シングルベンダ、マルチベンダ、オフショア開発など
開発フェーズ新規開発、追加開発、マイグレーションなど
開発規模や開発期間短期開発、少人数開発、大規模開発など
実行環境オンプレミス、プライベートクラウド、パブリッククラウドなど
※2

Forsgren, N., J. Humble, G. Kim. (2018). Accelerate: The Science of Lean Software and DevOps - Building and Scaling High Performing Technology Organizations. IT Revolution Press.

お問い合わせ