Special
» 2015年09月01日 10時00分 UPDATE

DevOpsの目的は「現場の効率化」ではなく、サービスの「スピーディな」差別化:既存資産を“ビジネスに役立つDevOps環境”に変えるには

ビジネス展開にスピードが求められている今、あらためてDevOpsが注目されている。すでに取り組んでいる企業もあるが、「各開発・運用現場の効率化」という部分最適でとどまっていて、本来の目的である「リリースサイクル短縮によるビジネスの差別化」にうまくつながっていないケースが多いという。その理由とは何か? 確実に「成果」を獲得できるDevOps成功のポイントを聞いた。

[PR/@IT]
PR

従来型企業こそ、DevOpsが必要な理由

 市場環境変化が速く先を見通せない今、システム開発にはビジネスニーズへのスピーディな対応が求められている。これを受けて、「システムの市場投入までの時間をいかに短縮するか」「サービスの変更をスピーディに反映させていかに差別化を図るか」というテーマが、企業にとって収益・ブランド向上の大きなカギとなっている。

 こうした中、「DevOps」が今あらためて注目されている。2013年ごろ、国内で関心を集め始めた当初は、「開発と運用の連携」「協力し合う文化」といった局所的な理解が中心だった。だが、前述のような市場環境や導入事例の蓄積を受けて、「リリースサイクル向上による新サービス展開により差別化を図るための手段」という認識が浸透し、国内でも実践に乗り出す企業が着実に増えつつある。

 特に重要なのは、単に「速く開発・テスト・リリースすること」ではなく、ニーズを受けてスピーディに開発、テスト、リリースし、市場の反応を迅速に開発にフィードバックする――すなわち、改善のフィードバックループを迅速かつ安定的に回すことで、「ビジネスの差別化につなげる」というDevOps本来の目的が浸透してきたことだろう。

 その一方で、DevOpsの適用領域に対する理解も広まりつつある。例えば、基幹システムなど「規模が大きく依存関係が複雑である上に、非常に高度な信頼性やデータの保全性が求められるシステム」の場合は、従来型のウォーターフォールのような開発手法が適している。だが、例えばバンキングやEコマース、モバイルアプリなど、「市場変化に柔軟に対応すべきシステム」「ニーズに応じてスピーディに改善する必要があるシステム」については、アジャイル的なアプローチや、継続的にデリバリーを行うようなDevOpsのような考え方がより適しているという認識も一般化してきた。

 これまで日本国内では、DevOpsというと「一部のWebサービス系企業のもの」といったイメージを持つ向きが多かった。だがB to C、B to Bを問わず、アプリケーションが重要な顧客接点となり、ビジネスの推進上、重要な役割を果たしている今、「システムの目的と変化への対応スピード」を基準に考えれば、「DevOpsを適用すべきシステム」を持つのはWebサービス系企業に限らない。流通、小売り、製造、金融、保険など、従来型企業が差別化を図る上でも、DevOpsは不可欠な手段となっているのだ。

DevOpsの目的は「現場の効率化」ではなく「ビジネスの差別化」

 だが、すでにDevOpsに取り組んでいる企業の間では、一つの大きな課題が持ち上がっているという。前述のように、DevOpsの目的はビジネスの差別化――すなわち「全社的なビジネスゴールの達成」にある。しかし、すでにDevOpsを導入している企業では、DevOpsが“部分最適”に陥っている例が多いのだという。HPソフトウェア事業統括 ITマネジメント統括本部 戦略推進本部 ADM製品担当マネージャーの石坂浩之氏は、次のように語る。

alt 日本HP HPソフトウェア事業統括 ITマネジメント統括本部 戦略推進本部 ADM製品担当マネージャーの石坂浩之氏

 「これまでDevOpsに取り組んできた企業では、現場主導で実践してきたケースが数多くあります。その結果、各プロジェクト単位では効率を向上できても、DevOps本来の目的である『企業としての差別化、競争力の向上』にはうまくつながっていない例が目立つようです。つまり、現場主導で“部分最適のDevOps”を進めてきた結果、『現場の効率向上』が目的化してしまい、『ビジネスの差別化』という本来の目的が見失われている状況です」(石坂氏)

 こうした場合、開発のスピードやコスト効率にも影を落とすことになる。特に問題となるのは、「各プロジェクトが現場の判断で、多種多様な開発支援ツールを導入している点」だという。

 「各プロジェクトチームが、それぞれ独自にDevOps実践のためのツールを一つ一つ選定・評価し、導入しています。この作業自体が全社単位で見ると非効率と言わざるを得ません。さらにプロジェクトメンバー全員が各ツールの使い方を一から覚える必要があり、余計な工数を取られてしまう上、プロジェクトごとに採用しているツールが異なるため、他のプロジェクトチームのノウハウが流用できないなどのデメリットが生じるケースも少なくありません」(石坂氏)

ALT 図1 現場主導のDevOpsでは、プロジェクトごとに異なるツール、ドキュメントにより、各現場の効率アップは図れても、大局的に見るとスピード、品質は上がらず、「ビジネスの差別化」という真の目的にはつながっていないケースが多い《クリックで拡大》

 また、現場主導のDevOpsの場合、オープンソースソフトウェア(以下、OSS)のツギハギとなりがちであり、開発環境が複雑化してしまう問題も目立つという。HPソフトウェア事業統括 ITマネージメント統括本部 戦略推進本部の桑本謙介氏は次のように解説する。

ALT 日本HP HPソフトウェア事業統括 ITマネージメント統括本部 戦略推進本部の桑本謙介氏

 「例えば、継続的インテグレーションツールの『Jenkins』や、リポジトリ管理ツール『Git』、構成管理ツール『Chef』といったOSSが部分最適で導入されており、プロジェクトごとにデータのフォーマットや粒度が異なるなど、全社的に標準化されていないようなケースです。この場合、他のプロジェクトチームではツールを再利用できなかったり、プロジェクトチームを越えてOSSを機能連携させたりすることも難しくなってしまいます。連携部分を自社開発する方法もありますが、相当なスキルと手間が必要で現実的とは言えません」(桑本氏)

 “OSSのツギハギ”はシステムの品質にも影を落とす。部分最適化した開発ツールやOSSによって、開発からビルド、単体でのテスト、リリースまでDevOps環境を構築できたとしても、リリース後の「安定運用」「開発へのフィードバック」まではカバーできていないケースがほとんどであるためだ。

 「特にテストについては、各プロジェクトが個別にテスト環境を用意するなど、膨大な工数を掛けている企業も少なくありません。一方でテスト工数を軽減するために、テスト作業を十分に行っていないケースがあることも見逃せない課題となっています」(桑本氏)

 こうした現場主導のDevOpsを放置しておくと、開発効率や開発品質の低下を招き、ひいては企業全体のビジネススピードを落としてしまう。いわばDevOps本来の目的とは逆効果をもたらす恐れも出てくるのだ。

既存資産を生かしながら、システム改善のフィードバックループを構築する

 日本HPでは、こうした課題を解消すべく、「Continuous Everything(全てを継続的に)」をコンセプトに掲げたDevOpsソリューション「HP DevOps」を用意している。桑本氏は次のように解説する。

 「HP DevOpsは、部分最適ではなく、ビジネス視点で全体最適を実現するためのDevOpsソリューションとしています。既存のDevOps環境を全て置きかえるのではなく、既存の開発支援ツールや各種OSSを補完・連携・管理するソリューションとすることで、開発からビルド、デプロイ、テスト、運用まで、アプリケーションライフサイクル全てをつないだDevOps環境の構築を実現します」

ALT 図2 HP DevOpsの全体像。ソリューションを構成する各種ツールは、Git、Subversionなど既存のOSSなどの資産を補完する形態により、アプリケーションライフサイクル全般における双方向のフィードバックを実現し、ビジネスの差別化に向け企業全体のアプリケーションライフサイクルの一貫性や可視性を向上させる《クリックで拡大》

 例えば、開発フェーズでは「Visual Studio」や「Eclipse」、「TFS」や「Subversion」、ビルドフェーズでは「Jenkins」や「Git」、デプロイフェーズでは「vCenter」や「Chef」といったツールが使われている。こうした他社の開発支援ツールやOSSと、HP DevOpsの各種ソリューションをAPI経由で連携し、足りない機能を補完する。これにより、アプリケーションライフサイクルを包括的にカバーする、エンド・ツー・エンドの統合DevOps環境を実現するという。

ALT 図3 既存資産とHP DevOpsの各種ソリューションをAPI経由で連携し、アプリケーションライフサイクルを回す上で足りない部分を補完する《クリックで拡大》

 HP DevOpsの中でも、部分最適のDevOps」を解決する上で重要な役割を担うのが、以下の5製品だ。以下では、それぞれのポイントを簡単に説明しよう。

  • アジャイルプロジェクト管理ソリューション「HP Agile Manager」
  • デプロイソリューション「HP CODER」
  • 自動機能テストソフトウェア「HP UFT(Unified Functional Testing)」
  • アプリケーション管理ソリューション「HP ALM(Application Lifecycle Management)」
  • アプリケーション監視ソフトウェア「Site scope」

 アジャイルプロジェクト管理ソリューション「HP Agile Manager」は、複数のアジャイルプロジェクトを計画、実施、追跡するための統合管理ソリューション。オープンソースのツールも含めて、すでに利用中の開発支援ツールや、構築済みの各種リポジトリに接続・連携することで、既存資産(ツール、データ、スキル)を活用しながら、サイロ化していた各プロジェクトを一元管理できる。例えば、Visual StudioやEclipse、Jenkinsなどと連携し、イテレーションの迅速化を図ることが可能だ。

 各ツールの管理情報を収集し、開発作業のトレーサビリティを担保したり、それを元にした各種レポーティングをしたりすることも可能。タブで管理情報の項目を切り替える、ドラッグ&ドロップで操作できるなど、扱いやすいUIを備えており、マネージャー層が複数のプロジェクトの状況を効率的に把握できる。

 テスト基盤自動化ソリューション「HP CODER」は、アプリケーション開発やテストにおける各フェーズで必要となるリソースをサービスメニュー化し、OSSツールなどからのトリガーによりリソースプールから自動でリソースを切り出して提供する製品。

 例えば「APサーバーの統合テスト」など、開発のライフサイクルの各フェーズで必要とされるインフラリソースをモデル化し、目的に応じたサービスメニューを作成してJenkins上に設定しておけば、実際にAPサーバーの統合テストを行う際、Jenkinsでビルドが実行されると「HP CODER」が自動的に最適なリソースを切り出して配備する。本来、テスト対象が100あれば100パターンのテスト環境を手動で用意する必要があるが、「HP CODER」を利用してリソースをメニュー化することで、その工数を大幅に軽減することができる。

 テストの効率化は自動機能テストソフトウェア「HP UFT」が担う。視覚的な操作で、アプリケーションのGUI機能部分とバックエンドサービス部分の両方に対応した自動テストを作成し、繰り返し実行できる。単一のGUIを使用して、入力と出力の組み合わせや画面遷移のパターンを登録することで、あらゆるタイプの機能テストを自動化することが可能だ。

 そして、アプリケーションライフサイクル全体の情報の一元管理を実現するのが、アプリケーションライフサイクル管理の「HP ALM」だ。ビジネスプロセスからシステム要件、テスト結果、不具合、ソースコード、ビルド情報まで、開発ライフサイクル全体にわたる情報を一元管理できる。

 他社製品や、ソースコード管理のSubversionやGit、継続的インテグレーションツールのJenkinsなど、オープンソースソフトウエアとの連携し、例えば要件のトレーサビィティ(追跡可能性)を提供することによるアプリケーションの品質向上に貢献も可能。既存の資産、既存のノウハウを無駄にすることなく、短期間・低コストでアプリケーションライフサイクル管理基盤の構築を支援する。

 リリース後には運用管理が必要であるが、これらのソリューションと連動してアプリケーション監視ソフトウェア「Site Scope」による自動での監視が可能となっている。軽量でカスタマイズ性に優れたWebベースのアーキテクチャを通じて、100種類を超えるITコンポーネントを継続的に監視できる。エージェントレスのため、異機種混在のハイブリッド環境の監視をサポートする。

 ポイントは、各システム構成要素の稼働状況を監視するのに加えて「ユーザー視点によるサービスラインでの監視」も可能なことだ。今までの監視は、一般的にはサーバーやアプリケーションを監視ネットワークから監視するのが一般的だった。しかしWebアプリケーションが増えてきた現在は、「サイレント障害」と呼ばれる“監視ネットワーク上は問題がなさそうに見えても実際にユーザーが使えていない”といった障害が多発している。そのため従来の監視に加えて「サービスラインからの監視」が必須となるわけだが、「Site Scope」による自動監視では、サービスラインからの監視に加え、運用者に「障害の切り分けのしやすさ」と「プライオリティ付け可能な情報」を提供する。

DevOpsは「ITの新たなガバナンスモデル」

 石坂氏はHP DevOpsについて、「個別最適化された既存のDevOps環境がある企業でも、既存の開発ツールやOSSの上にかぶせるようにして、HP DevOpsの各ソリューションを必要に応じて導入することで、それぞれが機能連携してアプリケーション開発ライフサイクル全体で最適化されたDevOps環境へと無理なく移行できる」と解説する。すなわち、既存の投資/資産を無駄にすることなく、「ビジネスの差別化」というDevOps本来の目的に向けて、システム改善のフィードバックループを高速かつ安定的に回せる「仕組み」が整えられるわけだ。

 「DevOpsは開発・運用現場の効率化ではなく、あくまで企業のビジネスを加速させることが目的。従ってHP DevOpsも、ビジネスサイドの要望や市場の意見を素早く取り入れて、効率的にアプリケーションに落とし込んでいける仕組みを合理的に作ることを目的としている。ちなみに、DevOpsには弊社のR&D部門も取り組み続けている。HP DevOpsには、実践者としての知見とノウハウを今後も取り込んでいく予定だ」(石坂氏)

 一方、桑本氏は、「全社的なビジネスゴールに向けて、スピーディかつ安定的にシステムを開発するDevOpsは、“ITの新たなガバナンスモデル”だと考えている。自社の差別化には何が必要で、それをどのように開発、リリース、運用し、改善していくのか。一つのビジネスゴールに向けて、アプリケーションライフサイクル全体を統制できていない現場主導のDevOpsは、本来のDevOpsの姿ではないといえるのではないか」と指摘。ビジネスのスピーディかつ安定的な差別化を図るためにも、ぜひガバナンスの効いた“全体最適化したDevOps導入”を検討してほしい」と述べる。

ALT 図4 スピーディな差別化という全社単位での目標に向けて、確実にガバナンスを効かせながらフィードバックサイクルを回す「全体最適のDevOps」を実現する《クリックで拡大》

 また、開発やテスト環境は一般的には共通化でき、利用しないときにはリソースプールに返却するといったクラウド本来の使い方ができる分野である。桑本氏は「開発・テスト環境のクラウド化と、開発・テストに必要な環境のリソース切り出しと自動プロビジョニングの仕組みを作ることで、ツールやプロセスの標準化を進めるというガバナンスアプローチがあるが、ボトムアップの文化が根強い日本では個別最適が進み、ここ数年で欧米や他のアジア諸国と比較しても生産性の面で大きく後れをとってしまっている」と指摘している。

 これまではDevOpsというと「開発と運用の連携」「協力し合う文化」といった局所的な理解が多く、その目的も「現場の効率化」に閉じているケースが多かった。だが、目的はあくまで「ビジネスの差別化」にある。現在の自社のビジネスとシステムを見据え、DevOpsを適用すべきシステム領域は何か、実践するならどのような仕組みが必要か、ぜひ見直してみてほしい。

関連ホワイトペーパーをダウンロードする

dlbanner.jpg

本記事に関連したホワイトペーパーをダウンロードしていただけます。ダウンロードしていただいた方の中から抽選で3名様にAmazonギフト券5000円分をプレゼントいたします。

※ダウンロードの際に、簡単なアンケートのご協力をお願いしております。


Copyright© 2017 ITmedia, Inc. All Rights Reserved.


提供:日本ヒューレット・パッカード株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2015年9月30日

ホワイトペーパーダウンロード

本記事に関連する資料はこちらからダウンロードできます。

DevOpsについて理解を深める上記ホワイトペーパーをこちらからダウンロードしていただけます。またダウンロードしていただいた方の中から抽選で3名様にAmazonギフト券5000円分をプレゼントいたします。
※ダウンロードの際に、簡単なアンケートのご協力をお願いしております。

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。