米HPE、「DevOpsで“やるべきこと”は、はっきりしている」：伝統的な大企業でも、変化に対応できなければ必ず破綻する（2/2 ページ）

[構成:編集部／協力:斎藤公二，＠IT]

既存のDevOps環境をパイプライン化することが大切

　ただ、既にDevOpsに取り組んでいる企業の場合、さまざまなOSSや商用ツールを組み合わせて、独自にDevOps環境を構築している例が多い。例えば、継続的インテグレーションツールの「Jenkins」、構成管理ツールの「Chef」「Puppet」などだ。

　だが継続的インテグレーションツール、継続的デリバリツール、構成管理ツール、テスト自動化ツールなどを、それぞれバラバラに使っている状態だと、前述した4つのバリューストリームを連携させることは難しい。加えて、開発部門、運用部門、あるいはプロジェクトチームごとに独自にツールを選定・使用していることも珍しくない。そこで同社では、既存のツールにAPI経由で連携させることで、「一連のフィードバックループを構築する上で、足りない部分を埋める」製品群を用意しているという。

　例えば、その中の一つが「HP CODAR」という製品だ。HP CODARは、アプリケーション開発における各フェーズで必要となるリソースをサービスメニュー化し、リソースプールから自動で切り出して提供する製品。いわゆる“Infrastructuer as code”を実現する構成管理ツールで、Chefなどで使った構成管理のワークフローをトポロジカルに画面に表示し、ドラッグ＆ドロップ操作で可能とする。これによりスピーディで確実な構成管理を実現する。

　この他、アプリケーションのGUI機能部分とバックエンドサービス部分の両方に対応した自動テストを作成し、繰り返し実行できるテスト自動化ツール「HP UFT（Unified Functional Testing）」、リリース後の運用監視を担い、改善のフィードバックに役立つ情報を提供するアプリケーション監視ソフトウエア「HP Site Scope」、ビジネスプロセスからシステム要件、テスト結果、不具合、ソースコード、ビルド情報まで、開発ライフサイクル全体にわたる情報を一元管理できるアプリケーションライフサイクル管理の「HP ALM（ Application Lifecycle Management）」などを用意。

　つまり、部門やチームによって既存のツールが異なる中でも、その上にかぶせるようなイメージで製品を組み入れる。これにより、開発、テスト、リリース、運用、フィードバックに至る「4つのバリューストリームをエンドツーエンドで連携させる」とともに、一連のフィードバックループを迅速かつ安定的に回せる“標準化されたDevOps環境”を整備するという考え方だ。

変化に対応できない企業は、いずれ破綻する

「外部の変化はコントロールできません。生き残るためには変化していかなければなりません」

　タン氏は、「Fluid ITの領域は、Webサービス系のみならず、従来型の大企業にもあります。DevOpsによってFluid ITに対応していくことは、あらゆる業種の企業にとって欠かせない取り組みになります」と力説する。

　実際、これまでも変化への対応ができずに事業継続が困難になったケースは多い。例えば米国出版業の例が挙げられる。電子書籍への対応を積極的に進めたバーンズ・アンド・ノーブルは業容を拡大させる一方、対応に消極的だったボーダーズ・グループ（Borders Group）は経営破綻に追い込まれた。伝統的な産業であっても、変化への対応を怠れば破綻する。

　「著名な経営学者のマイケル・ポーターは、戦略を作る五つの力として、新規参入業者、代替品、供給業者、買い手、競争業者を挙げました。注意していただきたいのは、これらは全て外部の力であり、内部からはコントロールできないということです。変えるとすれば社内です」（タン氏）

　DevOpsの取り組みは、企業を内部から変える取り組みの一つ。タン氏は、「業界、テクノロジは大きく変わっており、人々の生活も変わっています。生き残るためには変化していかなければなりません。もし変化を拒否すれば、5年後には存在していない――そうした覚悟を持って、DevOpsに取り組んでほしいと思います」と力強く訴えた。