市場ニーズへの対応が、アジャイル開発だけでは難しい理由：DevOpsとは「良いサービスを顧客に“速く届ける”こと」

「市場ニーズへの迅速な対応」はWebサービス系の企業に限らず、顧客が存在する全業種の共通課題。サービスを速く開発するだけではなく、より良いサービスを、より速く市場に届けることにDevOpsの意義がある。

[PR／＠IT]

PR

いかに迅速に市場変化に対応するか？――“顧客”が存在する全業種にDevOpsが必要な理由

　市場環境変化が速い現在、商品・サービスをスピーディに開発し、市場ニーズをくみ取りながら迅速に改善を重ねるアジャイルのアプローチが、企業にとって生き残りのカギとなっている。時間をかけて入念に製品・サービスを企画・開発しても、市場にリリースしたころにはすでにニーズと乖離している、といったことが起こりやすくなっているためだ。

　IBMが毎年行っているアンケート調査「C-Suite Study」を見ても、そうした認識は世界的に広がっているようだ。2013年の同調査によると「CEOが考える自社に影響を及ぼす外部要因」として「テクノロジー」がトップ、2位は「市場の変化」、日本国内でも「市場の変化」がトップ、「テクノロジー」が2位という結果となった。日本IBM ソフトウェア事業 Rational事業部 ITテクニカル・セールス アドバイザリーITスペシャリストの黒川敦氏は、これを次のように解説する。

日本IBMの黒川敦氏

　「年々スピードを増す市場環境変化を、いかに迅速にキャッチアップし、テクノロジーを使っていかにニーズに応えていくか――この調査結果は国内外の多くの経営層がそうした認識を深めていることを表している」

　こうした中で、開発部門（Dev）と運用部門（Ops）が連携することで、サービスの迅速なデプロイ、リリースを狙うDevOpsが注目されている。というのも、これまでもサービスを支えるアプリケーションの開発を加速するために、ビジネス部門と開発部門がともに開発成果物を確認しながら、迅速に開発を進めるアジャイル開発が注目されてきた。だが、アジャイル開発だけではサービスのリリースを加速させることは難しい。「サービスをいち早くリリースしたい開発部門」と、「安定運用のために頻繁なデプロイ、リリースを避けたい運用部門」という、“迅速なサービスリリースを阻む壁”があるためだ。

　「アジャイル開発で開発のスピードを上げても、開発したアプリケーションを本番環境にデプロイするのに手間と時間を要してしまい、結局はサービス投入に遅れを取ってしまう例が多い。その点、開発・運用部門の壁を解消し、アプリケーションの迅速なデプロイ、リリースを狙うDevOpsは、先の調査結果が示す『顧客を見据えた、競争力ある製品・サービスの迅速な提供』を実現する上で欠かせない概念となるわけだ。DevOpsというと、EコマースやゲームといったWebサービス系企業のように『リリースサイクルが速い場合に有効なもの』といった見方もあるが、『顧客を見据えた、競争力ある製品・サービスの迅速な提供』が必要なのはどの業種も同じ。金融、保険、小売り、流通など、“顧客”が存在する全業種に当てはまる」

　実際、ウォーターフォール型のシステム開発のイメージが強い金融業でも、システムの改善や、顧客に直接提供するWebサービスの開発・改善にはニーズへの迅速・柔軟な対応が求められる。タブレット端末を使った営業活動が増えている保険業などでも、モバイルアプリの開発・改善には、やはり市場変化に応じたスピーディな対応が必須だ。また近年、競争が激しい市場の中で、差別化のためにPaaSやSaaSを提供する例が増えつつあるIaaSプロバイダーやSIerの間でも、DevOpsに注目するケースが増えているという。

リリース加速を阻む、2つのハードルとは？

　だがDevOpsを実践する上では大きく2つの課題がある。「開発環境、テスト環境、ステージング環境、本番環境への正確・迅速なデプロイ」と、計画通りの本番リリースに向けて、各環境に開発成果物を正しく展開していく「リリースプロセスの確実な管理」だ。

　DevOpsの核となるアジャイル開発では、各開発者がコミットしたソースコードを自動的にコンパイル・ビルドし、こまめなインテグレーションを継続的に行うことで、開発の品質・スピードを担保する「継続的インテグレーション」（以下、CI）を行う。これについてはJenkinsなどのCIツールを使って自動化し、正確性とスピードを担保している例が多い。

　ただ前述のように、サービスのリリースを速めるためには、CIで完成した開発成果物をテスト環境、ステージング環境、本番環境に継続的、かつ迅速にデプロイする「継続的デリバリー」（以下、CD）も行う必要がある。だが開発成果物をデプロイする上では、各環境に共通／個別の設定を決められた手順に沿って行う必要がある他、各環境の構成に変更があればデプロイ作業をやり直す必要もあるなど、非常に手間の掛かる作業が求められる。

図1　各環境へのデプロイには非常に煩雑な作業が求められる。人手ではミスを誘発する他、作業のスピードも担保しにくい《クリックで拡大》

　「しかもこれをミスなく、スピーディに行えなければ当然リリースは遅れてしまう。従って、人手による作業では時間、手間が掛かる他、ミスも誘発しやすいため、CIと同様、デプロイ作業にも自動化が求められる」

　だがデプロイ作業を自動化するだけでは、まだ十分とは言えない。開発環境とテスト環境は開発部門が管理し、ステージング環境と本番環境は運用部門が管理している例が多い。その結果、多数の開発成果物を継続的、かつ迅速に各環境にデプロイしたくても、開発部門と運用部門のコミュニケーションロスや、知識・スキル、ツールの違いなどによって各環境の構成に不整合が起こり、ある環境では正常に動作したソフトウェアが、別の環境ではうまく動かないといった問題が起こりやすいためだ。

図2　開発環境とテスト環境は開発部門が管理し、ステージング環境と本番環境は運用部門が管理しており、一連のリリースプロセスを一元管理できないために、環境の不整合などさまざまな問題が起こりやすい

　「一連のリリースプロセスの分断は、リリースの遅れやアプリケーションの品質低下を招く他、リリース権限を一元管理できないことによってガバナンスやセキュリティを確実に担保できなくなるリスクも内包している。従って、CDにはテスト環境、ステージング環境、本番環境へのデプロイを、開発、運用部門間をまたがって管理・統制するリリースプロセスの確実な管理も必須となる」

開発・運用部門間の壁を解消し“コラボレーションの場”を作る「IBM UrbanCode」

　こうしたDevOpsに伴う2つの課題解決を支援するのが、IBMが2013年に買収した旧UrbanCode社の技術を生かした製品「IBM UrbanCode」だ。デプロイを自動化する「IBM UrbanCode Deploy」と、リリース管理を行う「IBM UrbanCode Release」の2製品で構成し、CDの実現をサポートする。

　IBM UrbanCode Deployは、テスト環境、ステージング環境、本番環境への開発成果物のデプロイ作業を自動化する。一般に、デプロイ作業を自動化するためには、複雑なスクリプトコードを書く必要がある。しかしこうした方法では、スクリプトを書いた本人以外はその内容を理解・改修できないなどプロセスの属人化を招き、メンテナンスコストも増大させてしまう。

　IBM UrbanCode Deployは、このデプロイプロセスを可視化・標準化する。具体的にはデプロイプロセスを設定する専用のGUIと、インストール、アンインストール、ロールバックなど、よく行う作業を定義したアイコンを用意。このアイコンをGUI上にドラッグ＆ドロップで配置して、線でつないでいくだけで、自社に即したデプロイプロセスをノンプログラミングで定義できる。既存のスクリプトを呼び出すことも可能だ。

図3　IBM UrbanCode Deployの画面イメージ。事前定義された作業部品を左カラムのリストの中から選び、GUI上にドラッグ＆ドロップで配置して線でつなぐだけでデプロイプロセスを定義できる。プロセスが視覚化されるためメンテナンスやチーム内での共有が容易になる他、人手によるプロセス定義ミスも削減できる《クリックで拡大》

　各作業の細かい定義も、アイコンオブジェクトのプロパティとして入力することで設定可能。また、一般的によく行われるアプリケーションサーバー、データベース、テストツール、シェルなどについては、定義済みのテンプレートも用意しているため、これをベースに必要な部分だけ設定変更することで、定義作業を簡略化できるという。

　「プロセスを定義したら、後はボタンを押すだけでデプロイプロセスを自動実行できる。デプロイプロセスを可視化し、属人化を防ぐことで、知識・スキルが異なる開発、運用部門間で連携できる環境が整う仕組みだ。既存プロセスのメンテナンス効率も大幅に高まる」

　リリースのスピードとともにアプリケーションの品質を担保する上では、確実な品質チェックも欠かせない。この点にも配慮し、各環境に任意のリリース基準を設定しておけば、基準に満たないものは自動的にリリースを止める品質ゲート機能も備えている。

　また、DevOpsでは「連携」とともに、「本番環境へのリリースは運用部門がリリースする」「リリースには上長の承認を得る」など、明確な役割・権限設定によるセキュリティやガバナンス面への配慮も不可欠となる。IBM UrbanCode Deployはこうしたリリース権限や承認プロセスも設定可能とすることで、リリースプロセスの標準化、ルールの徹底も確実に行える仕組みとしている。

　一方、IBM UrbanCode Releaseは、「いつ、どの環境に、どの開発成果物をデプロイするのか」というリリース計画を一元管理するツールだ。一般的には、Excelを使って管理している例が多いが、開発するアプリケーションや稼働環境が多様化している現在、人手だけで確実に管理することはもはや難しくなっている。IBM UrbanCode Releaseは、複数の環境にまたがった複数のアプリケーションのリリースを管理し、リリースの状況をリアルタイムで可視化する。これにより、リリースの進捗を随時正確に把握できるとともに、リリースの平準化やテスト計画の見直しを図るなど、プロセスの合理化・効率化を狙うことも可能だ。

　「このようにIBM UrbanCodeを使うことで、テスト環境からステージング環境、そして本番環境へと連なる一連のデプロイ／リリースプロセスを可視化・標準化し、開発部門と運用部門の双方で共有可能となる。これによってお互いの知識・スキルの違いによるデプロイ／リリース作業の問題を防ぎ、高品質なアプリケーションを迅速・確実にリリースできる体制が整う。しかし何より大きなポイントは、分断されていたデプロイ／リリースプロセスを標準化・共有化することで、開発部門と運用部門のコラボレーション基盤ができること。お互いに同じものを見て、対話ができる“場”を設けることで、相互理解が醸成され、ひいてはDevOpsのカルチャーが育まれる。DevOpsの成否を占う上では、このカルチャーをいかに醸成できるかが極めて重要だ」（黒川氏）

Jenkins、Chef、Selenium……。使い慣れたツールを使い続けながら、リリースサイクルを加速

　なお、CI、CDを行う上では、オープンソースソフトウェアも含めたさまざまなツールがすでに多くの開発現場で使われている。中でも先のJenkinsや構成管理ツールの「Chef」、テストツールの「Junit」「Selenium」などはなじみ深いところだろう。IBM UrbanCodeはそうしたOSSも含めた多数のツールとの連携機能も特徴としている。

　つまり個々の作業、例えばコードのビルドやテスト、サーバー環境の設定作業などは、これまで使ってきたツールを使いながら、IBM UrbanCodeと連携させることで一連のデプロイ／リリースプロセスを定義、自動化できる仕組みだ。Jenkinsも同様だ。JenkinsによるCIプロセスと連携させれば、CIで開発した開発成果物を、続けてテスト環境、ステージング環境、本番環境にデプロイ／リリースするプロセスを定義することで、開発から本番環境へのリリースに至る一連のCI、CDプロセスを迅速化・確実化できる。

■JenkinsとIBM UrbanCodeの違い

	Jenkins	IBM UrbanCode
種類	オープンソース	商用ツール
機能の焦点	ビルドに焦点	リリースに焦点
視点	開発者視点	開発者＋運用者の視点
権限設定範囲	ビルド単位の権限	デプロイ先環境の管理単位による権限
ツールの用途	継続的インテグレーション	継続的デリバリー

　「ユーザー企業と話していると、CIツールのJenkinsと、CDツールのUrbanCodeが混同して捉えられていることも多い。だが前者はビルド、後者はリリースに重点を置いており、適用領域はまったく異なる。また、これまではCI、CDを行う上で個別のツールの存在感が大きかったが、DevOpsが注目される中で、そうした各種ツールのインテグレーションを、いかに手間なくコストを掛けずに行うかも関心事となっている。そうした課題に応えている点もIBM UrbanCodeの大きな強みといえるだろう」

リリース時間を94％削減した例も。だがDevOpsの真の意義は「速さ」だけではなく、「顧客により良いサービスを届ける」こと

　このIBM UrbanCodeを採用してDevOpsを行い、大きな成果を挙げている企業は多数存在する。例えば、英国の医療系情報サービス業、WebMD社では、200を越える自社開発アプリケーションの開発・リリースプロセスを効率化するためにUrbanCodeを導入。その結果、それまで頻発していたリリースのトラブルや、開発成果物の品質に起因する問題が激減し、リリースに要する時間が平均55分から3分にまで短縮された。また、リリース時間の短縮により、4週間に一度のリリースを安定的に実施可能となった。これにより“現在の市場ニーズ”に沿った情報サービスをタイムリーに提供できるようになったという。

　提供開始して間もない日本国内でも、各業種から引き合いがあるという。中でも開発・リリースに高度な品質とセキュリティ担保が求められる金融・保険業からは、デプロイ／リリースの権限管理機能や証跡管理機能が特に評価されているそうだ。こうした点はDevOpsの意義はスピードだけではなく、プロセスの標準化・共有化による開発成果物の品質やセキュリティ担保にもあることの証左といえるだろう。

　「結局、DevOpsは自社の顧客――すなわち、一般消費者やエンドユーザーが望むサービスを、より速く、より品質の高い状態で届けることが最終目的。つまり、企業にとって重要なのは、顧客に優れたサービスを提供するためのビジネスモデルであり、DevOpsはそれを支える手段である以上、開発部門と運用部門が、ともに顧客やビジネスゴールを見据えて、より良いサービスを、より速く提供できるよう連携することが大切だ。例えば『デプロイを自動化すると仕事がなくなる』という声もあるが、定型作業を自動化することで、その分の時間をリリースプロセスの効率化など、よりビジネスに寄与する問題に振り向けることもできる」

　とはいえ、いざDevOpsに取り組むといっても具体的に何から手を付けたらいいか分からないというケースも多いのが現実だ。そこでIBMでは「DevOps成熟度モデル」を用意。壁の解消に向けた第一歩をスムーズに踏み出せるよう、コンサルティングも実施しているという。

図4　DevOpsプラクティスをベースにした成熟度モデル。これを基にユーザー企業におけるDevOpsの進展度を判定し、次に何をすればよいか、具体的な改善目標を提案する《クリックで拡大》

　「弊社では、DevOpsを実施するためのさまざまなプラクティスを蓄積しており、DevOps成熟度モデルを使って、まずはユーザー企業におけるDevOpsの進展度を判定し、次に何をすればよいか、具体的なプラクティスを提案している。DevOpsはビジネスの問題であり、文化の問題でもある。弊社ではそうしたDevOpsの本質と、ユーザー企業の顧客やビジネスゴールをともに見据えながら、プロセス整備、収益向上への施策を提案していきたい」