目次


継続的なイノベーションのために DevOps を導入する

Comments

最近のビジネス環境は、組織とそのソフトウェア・デリバリー機能に対し、多くを要求します。現在、ビジネス環境は以下のような状況になっています。

  • 事業主は、アジリティー (俊敏性) を求めている。
  • 開発者は、機能を毎日次々に開発している。
  • 運用担当者は、要求に応じて環境をプロビジョニングできるようになっている。
  • 顧客は、使用中のどのプラットフォームからでも、最新の機能にアクセスし、それらを使用できることを求めている。

以上は、DevOps ムーブメントの原動力となっている要因の一例に過ぎません。現在のアプリケーションは、携帯型端末から複雑な処理を行えるようになっていますが、顧客の要望に合ったビジネス機能を提供するために、エンタープライズ・アプリケーション、レガシー・データウェアハウス、および外部のサード・パーティー API にアクセスする必要もあります。

あらゆる新しいテクノロジーやテクノロジー関係のムーブメントと同じく、「DevOps」は、1 つの流行語になりました。DevOps を実践している企業として、Etsy、Facebook、Netflix が例に挙げられることがよくありますが、これらの組織は DevOps の最適な手法については意見を異にしています。一部の組織は、DevOps を「NoOps」の意味で捉えています。つまり、すべての運用業務を開発者が行うことを前提としています。その一方、そのような仕組みは大企業に適していないと反論する組織もあります。業界が DevOps について定義するなかで、各企業のリスク・アセスメント、必要とする価値、そしてニーズに基づいて、さまざまな手法が進化しています。

この記事では、DevOps の概要を説明し、組織が DevOps によって実現できるビジネス価値を探り、DevOps を導入するためのアプローチを紹介します。

DevOps とは何か

DevOps とは、リーン開発およびアジャイル開発の原則に基づくソフトウェア・デリバリーの手法です。DevOps では、事業部門から、開発、品質保証、および運用に至るまでのすべての利害関係者が協力して、顧客から実際に寄せられたフィードバックに基づいてソフトウェアを提供することを目的としています。DevOps の原則によって、ソフトウェア・アプリケーションをより効率的かつ効果的な方法で提供できるだけでなく、実際の顧客フィードバックに応じてソフトウェアを変更および強化することが可能になります。

デミング、リーン生産方式、カイゼン

DevOps を支える原則は、リーン生産方式のムーブメントが起こった時期に、ウィリアム E. デミング博士などの思想リーダーたちによって広まった原則が基になっています。デミング博士が提唱したのは、継続的な製造品質の改善を目的とした、計画 (Plan)、実行 (Do)、評価 (Check)、そして改善 (Act) または調整 (Adjust) からなる PDCA サイクルです (図 1 を参照)。リーン生産方式のムーブメントは、このコアとなる手法を基に、生産する製品を継続的に改善し、その生産プロセスにおける無駄を常に減らしていくことを目指しています。日本の製造業では、これらの継続的改善のための原則を、「カイゼン」(改善) という手法を用いて数十年前に導入しました。

図 1. デミング博士が提唱した、計画、実行、評価、改善のサイクル
各段階を経るにつれ、品質が改善されていく PDCA サイクル
各段階を経るにつれ、品質が改善されていく PDCA サイクル

近年のソフトウェア開発業界では、これらのリーン原則を基にした、アジャイル方法論を適用しています。図 2 に示すように、アジャイル方法論の基本的な考え方は、一定の期間 (スクラム方法論では「スプリント」と呼ばれます) に区切られた反復作業の中で、実際に機能するソフトウェアの一部を開発して顧客からそれに関するフィードバックをすぐに受け取り、そのフィードバックを基にビルドを繰り返し作成することで、ソフトウェア要件を実装していくというものです。アジャイル方法論は、4 つの重要な価値に基づいています。これらの価値は、アジャイル・マニフェストで以下のように説明されています。

  1. プロセスやツールよりも個人と対話を優先
  2. 包括的なドキュメントよりも機能するソフトウェアを優先
  3. 契約交渉よりも顧客との協調を優先
  4. 計画に従うよりも変化への対応を優先
図 2. DevOps: 小規模なリリースを本番環境に移し、迅速にフィードバックを受ける
DevOps のデプロイとフィードバックのサイクル
DevOps のデプロイとフィードバックのサイクル

DevOps は、このリーンおよびアジャイル手法の適用範囲をソフトウェア・デリバリー・ライフサイクル全体に拡大し、開発および品質保証の部門だけでなく、事業部門と運用チームを含むすべての利害関係者を関与させます。

DevOps ムーブメントの当初の目的は、開発チームと運用チームの間を隔てる障害を取り除くことでした。これらのチームの間にコミュニケーションや信頼関係がなかったことが、ソフトウェアをデプロイする際の課題となっていたからです。効果的なコミュニケーションの欠如は、開発チームとビジネスの利害関係者が、ユーザーからのフィードバックを入手するのを困難にします。有効なユーザー・フィードバックのメカニズムがなければ、開発チームはフィードバックに対処して、フィードバックを有効に活かすことはできません。

DevOps ムーブメントを後押ししたのは、Systems of Engagement (人と関わりあうシステム) アプリケーションに対するニーズです。Systems of Engagement アプリケーションでは、迅速かつ継続的に変更を適用し、市場に製品を適合させることに焦点を絞る必要があります。これらのアプリケーションを使用するのは顧客自身であり、企業の従業員ではありません。従って、これらのアプリケーションは企業が顧客に直接、革新的な機能を提供する機会をもたらします。例えば、銀行の場合、顧客が携帯電話から自身の口座を直接管理できるようにする機能を提供するなどです。

DevOps のすべての原則に共通する目的は、開発チームと運用チームの間にある障壁を取り除くことです。これにより、チーム間のコミュニケーションと信頼を確立し、小規模な機能セットをできるだけ早く本番環境および顧客に提供し、顧客からのフィードバックを受け取り、そのフィードバックに対処することが可能となります。それと同時に、ソフトウェア・デリバリー・プロセスを改善して、無駄、やり直し、過剰生産を抑えることにもなります。このように、DevOps を導入することで、組織はイノベーション、高品質の実現、価値を生み出すまでの時間の短縮、そしてコスト低減に焦点を絞れるようになります。

DevOps に対する IBM の見解

DevOps が成熟するに従って、その原則はソフトウェア・デリバリー・ライフサイクル全体に適用されるようになっていきました。今では、事業主や事業部門の利害関係者にもフィードバックが送信されます。このことから、PDCA サイクルは、ソフトウェアの機能だけでなく、リリース計画、要件、テスティング、環境、そしてソフトウェア・デリバリーのプロセスにも影響を与えるようになっています。DevOps の原則も成熟し、Systems of Engagement アプリケーションに加え、従来の Systems of Record (基幹システム) アプリケーションにも、これらの原則が適用されています。市場が急速に進化し、競争が激化する中で、企業は顧客に提供する無数のアプリケーションにおいて、イノベーションと安定性のバランスを維持しようと格闘しています。

IBM が定義する DevOps とは、「継続的ソフトウェア・デリバリーによって、ソフトウェアの利用者が市場機会を捉え、顧客からのフィードバックを受け取るまでの時間を短縮するためのエンタープライズ機能」です。

4 つの DevOps 導入アプローチ

DevOps の機能は、ソフトウェア・デリバリー・ライフサイクル全体に及びます。組織が DevOps をどの部分からどのようにして実装するかは、ビジネスの目標、最終目的、課題、そして組織に欠けているソフトウェア・デリバリー機能に基づいて決定します。

組織が DevOps を導入する際に役立つよう、IBM では次の 4 つの導入アプローチを提案しています。

  • 計画と測定
  • 開発とテスト
  • リリースとデプロイ
  • モニターと最適化

「計画と測定」導入アプローチ

「計画と測定」導入アプローチは、事業部門とその計画プロセスに重点を置いた「継続的なビジネス計画」という 1 つのプラクティスからなります。企業は顧客からのフィードバックに迅速に対応しなければならないことから、多くの企業ではリーン・スタートアップ手法を採用しています。リーン・スタートアップ手法は、スモール・スタートで行われ、ビジネス上のビジョンや価値をテストするために必要な成果とリソースを明らかにした後、顧客からのフィードバックに基づいて継続的に変更に適応して調整を行います。

これらの目標を達成するには、組織が進捗状況を測定し、顧客が本当に必要としているものを明らかにした後、それに従ってビジネス計画を更新して、方向性を決定していきます。このアプローチでは、組織はリソースが限られた環境で意思決定を行うことができます。

「開発とテスト」導入アプローチ

開発とテストの導入アプローチには、「コラボレーティブ開発」と「継続的テスト」という 2 つのプラクティスがあります。この 2 つが、開発および品質保証機能の中核となります。

コラボレーティブ開発

企業でのソフトウェア・デリバリーの取り組みには、部門の枠を超えた多数のチームが関与します。関係者には、基幹業務の所有者、ビジネス・アナリスト、エンタープライズ・アーキテクト、ソフトウェア・アーキテクト、開発者、品質保証担当者、運用担当者、セキュリティー専門家、サプライヤー、パートナーなどが含まれます。これらのチームの作業担当者は、複数のプラットフォームで作業を行うことから、別々の場所に分散して配置される場合があります。コラボレーティブ開発のプラクティスを使用すれば、これらの作業担当者は、ソフトウェアを作成してデリバリーするための、一連の共通プラクティスおよび共通プラットフォームを提供するために協力して作業を行うことができます。

コラボレーティブ開発に伴う 1 つの側面は、継続的インテグレーションです。継続的インテグレーションとは、ソフトウェア開発者が成果物を継続的または頻繁に、開発チームの他のメンバーの成果物と統合する手法のことです (図 3 を参照)。

図 3. 継続的インテグレーション
個々のコンポーネント・ビルドが 1 つの統合ビルドになります
個々のコンポーネント・ビルドが 1 つの統合ビルドになります

継続的インテグレーションのプラクティスは、アジャイル・ムーブメントによって広まった手法で、開発者が定期的に自らの成果物を開発チームの他の開発者の成果物と統合し、その統合された成果物をテストするという考え方に基づいています。複数のシステムまたは複数のサービスから構成される、複雑なシステムの場合、開発者はその成果物を他のシステムおよびサービスとも定期的に統合します。成果物を定期的に統合することで、統合によるリスクを早い段階で検出して明らかにすることができます。複雑なシステムでは、継続的インテグレーションによって、技術とスケジュールの両方に関する既知のリスクが確認され、未知のリスクが明らかになります。

継続的テスト

継続的テストには、以下のようないくつかの目的があります。

  • 継続的なコードのテストと検証を可能にする
  • 個々の開発者が作成したコードを、他の開発者が作成したコードや他のコンポーネントのコードと統合できることを検証し、設計通りに動作することを確実にする
  • 開発中のアプリケーションを継続的にテストする

継続的テストとは、そのライフサイクル全体にわたり、早い段階から継続的にソフトウェアをテストすることを意味します。継続的テストは、コストの削減、テスト・サイクルの短縮、さらにはコード品質に関する継続的なフィードバックを得られるという結果をもたらします。このような継続的テストの効率を向上させるのが、自動化されたテストとサービスの仮想化です。サービスの仮想化は、本番環境をシミュレートできるようにするとともに、継続的テストを実行できるようにし、テスト対象のアプリケーションがやりとりする必要のある外部サービスおよびアプリケーションのインスタンスをシミュレートして提供します。これらのシミュレーションまたは仮想インスタンスは、いつでも使用可能で、ほとんどコストをかけずに実行することができます。また、サービスの仮想化によって、継続的テストは外部サービスおよびアプリケーションに依存しなくなり、テストのコストが削減されます。

「リリースとデプロイ」導入アプローチ

DevOps の基本機能のほとんどは、この「リリースとデプロイ」導入アプローチで開発されたものです。継続的リリースおよびデプロイの原則は、継続的インテグレーションの概念を次のステップに引き上げます。継続的リリースとデプロイのアプローチを採用するには、デリバリー・パイプラインを作成する必要があります。このパイプラインによって、デリバリー・ライフサイクル全体でソフトウェアの継続的なリリースおよびデプロイが効率化され、自動化されます。継続的なリリースおよびデプロイの目的は、顧客とユーザーが新機能をできるだけ早く使用できるようにすることです。

図 4 に、デリバリー・パイプラインを作成するために必要な機能を示します。デリバリー・パイプラインを支援するコア機能は、継続的デリバリーです。継続的デリバリーとは、デリバリー・パイプラインに含まれるさまざまな環境 (開発環境、品質保証環境、結合テスト環境、ユーザー・アクセプタンス・テスト環境、本番環境など) に、開発中のアプリケーションを定期的に提供する機能のことです。繰り返し可能で自動化された信頼できる手法によって、ソフトウェアをこれらの環境に提供して検証し、可能な場合は顧客にリリースします。このデリバリーは、アプリケーション全体である場合も、変更されたコンポーネント、または構成やコンテンツの変更だけである場合もあります。継続的デリバリーは、単純にファイルを転送するだけのことではありません。コード、コンテンツ、アプリケーション、ミドルウェア、環境の構成、プロセスの変更を調整してデプロイする必要があります。

図 4. デリバリー・パイプライン
開発、ビルド、パッケージング、デプロイ、テスト、本番
開発、ビルド、パッケージング、デプロイ、テスト、本番

DevOps テクノロジーのツールとプロセスの大半は、継続的インテグレーション、継続的リリース、継続的デプロイの促進を目的としています。

「モニターと最適化」導入アプローチ

「モニターと最適化」導入アプローチには、2 つのプラクティスが含まれています。これらのプラクティスによって、企業はリリースしたアプリケーションが本番環境でどのように動作するかをモニターし、顧客からのフィードバックを受け取ることができます。このデータは、企業がアジャイルに対応し、要件およびフィードバックに応じてビジネス計画を調整する上で役立ちます。

継続的モニター

継続的モニターにより、デリバリー・サイクルのさまざまな段階で、運用担当者、品質保証担当者、開発者、基幹業務の所有者、そしてその他の利害関係者にアプリケーションに関するデータとメトリクスが提供されます。これらのメトリクスが提供されるのは、本番環境に限定されません。利害関係者はこうしたメトリクスに応じて、提供する機能を強化または変更したり、ソフトウェア・デリバリーに必要な変更をビジネス計画に反映させたりすることができます。

継続的な顧客からのフィードバックと最適化

ソフトウェア・デリバリー・チームが入手する情報のうち、最も重要な情報のタイプは、顧客がどのようにアプリケーションを使用するかを示すデータ、そしてアプリケーションを使用した顧客からのフィードバックの 2 つです。企業では、新しいテクノロジーを使用することによって、顧客がアプリケーションを使用する場合に、顧客の振る舞いを捕捉することや、顧客の問題を特定すること、顧客の感情を測ることが可能になります。このフィードバックに基づき、さまざまな利害関係者が適切な対応を取ることによって、アプリケーションを改善し、カスタマー・エクスペリエンスを強化することができます。具体的には、基幹業務の所有者はビジネス計画を調整し、開発部門は提供する機能を調整し、運用部門はアプリケーションのデプロイ先となる環境を最適化することができます。この継続的なフィードバック・ループは、DevOps に不可欠の要素です。フィードバックによって、企業はアジリティーを高め、顧客の要求に迅速に対応できるようになります。

まとめ

DevOps は組織に、リーン手法およびアジャイル手法に基づく一連のプラクティスを提供します。組織はこれらの手法を使用して、開発したソフトウェアが要件を満たしていないというリスクを軽減し、ソフトウェア開発およびデプロイメントの有効性と効率性を高めることで、顧客に最適なタイミングでイノベーションを提供し、顧客からのフィードバックを迅速に適用して、提供するイノベーションを強化できるようになります。ほとんどの組織では、自社のソフトウェア・デリバリー機能を利用して、顧客のニーズに対処し、顧客が必要とするビジネス機能の安定性と市場が求めるイノベーションとのバランスを取っています。そのような組織に対し、DevOps はこのバランスを実現するための機能を提供します。


ダウンロード可能なリソース


関連トピック

  • Sanjeev Sharma の著書『DevOps For Dummies』を読んで、DevOps について、さらには組織が DevOps からビジネスの真の利益を得る方法について理解してください。
  • Sanjeev Sharma のブログ投稿を読んで、リーン思考とは何か、そしてこの考え方が DevOps にどのように適用されるのかを学んでください。
  • IBM developerWorks の DevOps セクションで、IBM DevOps の詳細を探り、DevOps 開発者向けのリソースを見つけてください。
  • このアジャイル・マニフェストを読んでください。
  • The Software Project Manager's Bridge to Agility』(Michell Sliger、Stacia Broderick 共著、Addison-Wesley、2008年) を読んでください。
  • User Stories Applied For Agile Software Development』(Mike Cohn 著、Addison-Wesley、2004年) を読んでください。
  • developerWorks の Rational ゾーンで、技術リソース、ベスト・プラクティス、そして Rational のコラボレーティブで統合化されたソフトウェアおよびシステム・デリバリー・ソリューションに関する情報を調べてください。
  • さまざまな IBM 製品や IT 業界のトピックに焦点を絞った developerWorks テクニカル・イベントで最新の技術情報を入手してください。
  • developerWorks 最新イベント情報のページで、IBM の製品およびツールについての情報や IT 業界の動向についての情報を迅速に把握してください。
  • スキルを磨くために、Rational カタログで、多種多様なトピックについて学べるさまざまなタイプのコースを調べてください。コースの一部は、いつでもどこででも受けられます。また、「入門」コースの多くは無料です。
  • Rational ソフトウェアの試用版をダウンロードしてください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=978195
ArticleTitle=継続的なイノベーションのために DevOps を導入する
publish-date=07242014