今あえて問い直す、DevOpsが必要な理由と、国内事例に見る実践の現実解：「本当は、終わってなどいないし始まってすらいない」
2012年から2013年にかけて大きな注目を集めたDevOps。だが国内での冷めた視線とは裏腹に、欧米ではWeb系以外の企業でも取り組みが活発化しているという。この違いは何なのか？ バズワードとして片付けられつつある今あらためて、国内での実践者の声も交え、その意義と現実解を探る。
欧米ではWeb系以外の企業にも浸透が進むDevOps
開発と運用が連携し、短いスパンでシステムをリリース、改善を重ねる概念「DevOps」。国内でもWeb系の企業を中心に浸透が進んだが、一般的な企業においては“一過性のバズワード”と捉えられている傾向が強い。だが米国では、金融、製造、流通といったエンタープライズ一般で適用される動きが活発化しているという。この日米の違いは何なのか？ 国境を越えた市場競争が展開されている中で、これをバズワードとして切り捨ててしまってよいものなのか？
本稿ではこうした問題意識に基づき、CA TechnologiesのDevOps&アプリケーション・デリバリ シニア・プリンシパル・ソリューション・セールスの渡辺隆氏にインタビュー。さらにCA Technologiesのサービス仮想化ツール「CA Service Virtualization」のユーザーで、DevOpsの実践者である大手SIer、クオリカに話を聞くことで、今あらためて、DevOpsに取り組むべき理由と実践の現実解を探った。
「“DevOps”は終わっていないし、始まってすらいない」
──昨今の日本における、システム開発・運用の現況をどう見ていらっしゃいますか？
渡辺氏 クラウドやモバイルの浸透といったトレンドを受けて、システム開発・運用の現場は複雑化の一途をたどっていると思います。特に大企業の間では、ビジネス要求を受けて、迅速にシステムを開発することが年々強く求められるようになっています。開発、運用の現場にとっては、「スピードと品質の両立」というテーマが一層シビアに要求される、厳しい状況にあるといえるのではないでしょうか。
──2012〜2013年にDevOpsという言葉が注目を集めたのも、そうした背景からだと思います。今あらためて、企業はDevOpsという言葉をどう捉えるべきだと思いますか？
渡辺氏 確かにDevOpsという言葉はメディアなどで頻繁に取り上げられる中で、イメージだけがひとり歩きをしてしまったように思います。「捉えどころがない」と感じている人も多いかもしれません。実際、業界標準ではありませんし、ツールでもありません。ITILのような標準のプロセスでもありません。加えて、ベンダーや開発・運用のプレーヤーごとに捉え方がバラバラです。それが誤解を招く一因になっていると思います。
もともとDevOpsとは、米国の写真共有サービス企業、Flickrが2009年頃から実践したのが始まりです。クラウドを活用してサービスを展開し、顧客ニーズに合ったサービスを迅速に提供するために、1日に10回デプロイしようとした。「新機能のデプロイを1日に10回以上するために、開発と運用は何をすればよいか」を考えたことからこの概念が生まれました。そのキモとなるのは、「開発から運用にどうすればスムーズに成果物を渡していけるか」ということです。今この言葉を見直す上では、ここをあらためて認識することが大切だと思います。
──その点、国内でWeb系企業からDevOpsが浸透していったのは、開発と運用が同じ会社の中にいて、そもそも連携しやすかったこともあるのでしょうか。
渡辺氏 そうですね。また、そうした企業は自社開発しているサービスが収益に直結しています。この点でもDevOpsに対する親和性が高かったといえると思います。ただ、DevOpsはネット系の企業だけのものというわけでは決してありません。実際、米国では今や製造やサービス、銀行といった一般的な企業にまで取り組みが浸透し始めているのです。
──どのような事例があるのでしょうか。
渡辺氏 例えば米国では、消費者向けモバイルアプリを使ったオンラインバンキングが浸透しており、「いつでもどこでも、ベッドの上でもバンキングしたい」といったニーズが強い。銀行としては、そうしたニーズに応えるために、アプリケーションの機能や品質をどんどん改善していく必要がある。そこである大手銀行では、1カ月にどのくらいデプロイするかというと、1年前は数十回だったそうですが、現在ではサブシステムを含めて1万7000回を超えているそうです。これは2014年11月9〜12日にラスベガスで行われた「CA World '14」で発表された事例です。
──単純計算で1時間に20回以上デプロイしていることになりますね。
渡辺氏 当然手動では不可能ですから自動化されています。ナイトリービルドから、リグレッションテスト、インテグレーションなどまで自動化されており、担当者が1クリックするだけで、本番環境にデプロイできるようになっているそうです。
注目すべきは、モバイルアプリとはいえ “System of Engagement”と呼ばれる情報系システムだけでなく、“System of Records”と呼ばれる勘定系システムとも連携していることです。それもバンキングのアプリケーションですから、誤動作やレスポンスの遅延などがあってはならない。現在はこうした銀行に限らず、メーカー、流通といった伝統的な業態の企業が変化する顧客ニーズに応え続けるために、積極的にDevOpsを実践しています。日本とはここまで認識に差があるのかというのが正直な感想です。
──アプリケーション開発・運用の在り方が企業価値に直結している、という認識が強いのでしょうか？
渡辺氏 そうですね。実際、サービスを支えるアプリケーションの質が、収益をはじめブランド、カスタマーリレーションシップなど、あらゆる企業価値を左右する時代になっています。従って、課題があればすぐにシステムを改善してリリースする必要がある。
エンタープライズでは、たとえば開発はアプリケーションライフサイクルマネジメント、運用はITILという具合に、それぞれの領域において手法は比較的確立しているケースはあります。ただ、開発と運用を橋渡しする部分がすっぽり抜け落ちてきた。そこを埋める具体的な方法、実装手段としてDevOpsが重要になってきたわけです。多くの日本企業では、この点がまだ十分に認識されていないのではないでしょうか。ブームは去ったどころか、まだ始まってもいないというのが実情だと感じています。
迅速・確実にデプロイできる仕組み、プロセスの整備が必要
──では日本企業において、開発と運用の連携を阻む課題として何が挙げられるでしょう？
渡辺氏 欧米企業のように内製ではなく、開発の外部委託によって、開発と運用が組織的に分断される例が多いことだと思います。特に日本企業は、複数のSIerに開発を依頼し、並行開発をする例が一般的です。この解決のアプローチとしては、運用を担うユーザー企業側がイニシアティブをとり、開発から運用に成果物をスムーズに流す仕組みを作ることです。逆にSIerの一社や中立的なコンサルティング会社などがイニシアティブをとって、開発と運用の橋渡しをするプロセスを作ることも有効かと思います。
いずれにせよ、開発はSIerが担い、結合テスト辺りからユーザー企業が担うことが一般的な中で、デプロイ方法がSIerによってばらばらであるなど、成果物をスムーズに流す統一された仕組みがないことが連携を阻む要因となっています。こうした中で、ステークホルダーの一社がイニシアティブを取り、“迅速・確実に成果物をデプロイできる仕組みやプロセス”を整備、統一することが重要なポイントとなります。
──そうした 「品質とスピードを両立しながら成果物を何十回、何百回とデプロイできる仕組み」を作る上で、CA Technologiesは何を提供しているのですか?
渡辺氏 弊社がDevOpsに対して注力しているのは、「継続的デリバリ」と「サービス仮想化」「テストの自動化」と「運用中システムの分析」の4つですが、今日は継続的デリバリとサービス仮想化についてご紹介します。
まず継続的デリバリです。この考えのキモは、開発・変更したアプリケーションが、開発環境、テスト環境、ステージング環境、そして本番環境という異なる環境であっても均質にデプロイされることです。これを実現するには、アプリケーションのリリース作業を自動化することはもちろんのこと、異なる環境の構成を抽象化して管理できること、そして、リリース自動化のみならず、ソフトウェア構成管理やテスト自動化、ALM、サービス管理などのツールと連携できることが必要です。
弊社の継続的デリバリツールである「CA Release Automation」はこれらの要件を全て満たしているツールです。さらに、連携するミドルウェアや開発・テストツールに対するアクションを毎月増やしており、現時点では1400ものアクションをサポートしています。
例えば、米国のある銀行では、Git、Maven、Nexus、Selenium、Jenkinsといったオープンソースの開発ツールとCA Release Automationとを連携させ、継続的インテグレーション、継続的デリバリーを実現しています。今や、開発系ツールは前述のようなオープンソースを活用されるお客さまが世界中で主流になっています。商用ツールだけではなく、オープンソースとの連携をサポートしているCA Release Automationは、今日のお客様のニーズにフィットしているといえます。
「継続的デリバリ」を支援するCA Release Automation、「サービス仮想化」を実現するCA Service Virtualization、さらに「テストの自動化」を行うCA Application Testで、「品質とスピードを両立しながら成果物を何十回、何百回とデプロイできる仕組み」を整備することができる
次にサービス仮想化です。開発の後工程、例えば、結合テスト辺りから課題となるのはテスト制約の問題です。複数のSIerで並行開発をしていると、アプリケーションの依存関係によってテストに待ち時間が発生し、ボトルネックが生じることがよくあります。ここで他のSIerとコミュニケーションを取りながら連携していく必要が出てきます。
つまり、「テストの待ち時間を抑制して、迅速・確実にテストを行い、セキュアにデプロイできるプロセス」を整備し、それに沿って成果物を開発から運用に確実に受け渡していく、連携するための仕組みが重要になるわけです。弊社が用意しているサービス仮想化ツール「CA Service Virtualization」も、そうしたプロセス整備を支援することを目的としています。
テスト制約を、サービス仮想化で解消するCA Service Virtualization
──CA Service Virtualizationでは、具体的にどのようなことができるのですか？
渡辺氏 CA Service Virtualizationは、大きく分けて以下の機能をもっています。
- 対向先システムの振舞いやデータのシミュレーション。これをサービスの仮想化と言っています。
- テストの自動化機能。最近はiPhoneやAndroidなどモバイルデバイスのUI自動化を強化しています。
- 負荷テスト機能。テスト先アプリケーションに対して負荷をかけるだけではなく、テスト先アプリケーションが連携するアプリケーション側が負荷を受け、応答するという仮想化機能も有しています。
特筆すべきは「サービスの仮想化」です。テストにおける「制約」とは、前述のような待ち時間だけではなく、例えば次のような制約が挙げられます。
- クラウドサービスやメインフレームなどは、使いたいときに使えない。使うに当たってはコストが発生する。本番と同等の負荷をかけるなどの利用が不可能。
- 開発工程において、テスト環境の準備が間に合わない。テスト環境、つまり、物理サーバーや仮想マシン、ミドルウェア、テストデータなどの準備に多大な時間とコストがかかる
- 連携先アプリケーションやコンポーネントが完成していないため待ち時間が発生する。全てがそろってからテストを実施すると、インターフェースエラーが続出し、手戻りが発生する。あるいは、最終工程で負荷テストを実施したら、満足のいくパフォーマンスが得られず、手戻りが発生する
CA Service Virtualizationは、連携先アプリケーションの動作・振る舞い、データ、応答時間などをシミュレーション、つまり「仮想化」するためのツールです。企業システムは、単一のアプリケーションから構成されるのではなく、オープン系システム、メインフレーム、パッケージ、SaaSなどの複数のアプリケーションが連携してビジネス機能を実現しています。この複雑な連携をシミュレーションすることで、以下のようなメリットを享受できるのです。
- 結合テストの早期実施によるテストカバレージの増加
- 負荷テストの早期実施による、パフォーマンス問題の特定
- テスト環境の購入コスト削減
1によって、より多くのテストを実施できるようになり、結果として品質が高まることが期待できます。3については、米国のある銀行では数億円以上のコスト削減に成功した事例も出ています。
“迅速に成果物をデプロイできる仕組み・プロセス”を作る――CA Technologiesは、以上の製品によって、そうしたプロセス整備を支えるという。では実際の開発・運用現場ではどのように適用しているのだろうか？ 続いて、同製品のユーザーであるSIer、クオリカのITサービス事業本部開発技術センター長 坪口智泰氏に話を聞いた。
並行開発を確実・迅速に進められる“仕組み”を整備
──まずは御社のプロフィールを教えていただけますか？
坪口氏 弊社は1982年にコマツの情報システム会社として創業し、2000年にTISグループに、2008年にITホールディングスグループの一員になりました。外販による収益も伸びつつあり、コマツの基幹システム、業務アプリケーションを30年にわたって作り続けてきたノウハウを基に、コマツをはじめ、製造業、流通・サービス業などに、あらゆるシステムを提供しています。またパッケージソフトの開発・販売も行っています。
──CA Service Virtualizationを導入された背景を教えて下さい。
坪口氏 従来の考え方や方法論では、ユーザー企業の要望に応えられなくなってきたことが大きな要因です。以前は「要件定義に半年、そこからテストを行い、運用まで約2年」といったスパンで開発を行うことが一般的でした。しかしここ数年は「稼働までに1年以内」という要望がほとんどです。「期限を提案に組み込んだ上でRFPを提出してほしい」と言われるケースも増えています。
また近年は、オフショア、ニアショアを活用したマルチサイトでの開発が進んでいますが、ユーザー企業側もクラウドや複数のSIer、ベンダーを使うことでリスク分散できる並行開発を望んでいます。加えて、情報保護の観点から、ユーザー企業の連携先システムや、他のSIerが並行開発しているシステムについて、その中身やデータを見ることも難しくなっています。つまり開発のスピードと品質を担保するためには、単純に人的リソースを増やしても実現は難しく、システム開発の在り方そのものを変える必要が出てきたのです。
──具体的には、どのような開発体制が求められるのでしょうか？
坪口氏 並行開発を進める中で、他のベンダー、パートナーといかにコミュニケーションを取り、品質を確保していくかが課題となりました。例えば「他のSIerが開発しているサブシステムの動きを知るために、データの構造を知りたい」という場合、発注元であるユーザー企業を経由して「データを見たい」と頼んだとしても教えてはくれません。つまり連携先システムの動きすら分からない中で開発し、最後の結合テスト、受け入れテストの段階になって問題が噴出するケースが目立つようになってきたのです。
そんな中、「できるだけ開発初期の段階から品質を作り込めないか」と考えたのが、CA Service Virtualizationに注目したきっかけでした。約1年前から検証を開始し、今年5月に本格導入し、その後、実際のプロジェクトに適用しました。
品質は、“チェック”するものではなく“作り込む”もの
──どのようにCA Service Virtualizationを適用したのですか？
坪口氏 ツール導入以前に、弊社では「連携先システムの中身を見られないなら、システムの振る舞いを見て開発すればよい」という発想に切り替えました。「振る舞い」とは「どのシステムに何を投げれば何を返してくるか」「どのように返すか」といったことです。そこでサービス仮想化ツールに注目したわけです。
つまりCA Service Virtualizationのスタブを使って、ベンダーやパートナーが開発するシステムの振る舞いを真似させることで、互いのシステムがブラックボックスのままでも随時テストを行える環境を整えたのです。これにより、テスト制約の問題を解消しながら効率的に並行開発を進めることを狙いました。
また、導入したプロジェクトでは国内外合わせて計10カ所の拠点があったため、業務インフラとしてVDI(仮想デスクトップ環境)を導入し、開発もVDI上で行っています。そうした弊社のVDI環境にスタブを用意しておき、開発パートナーである他のSIerにもリモートでアクセスしてもらうことで、スムーズに並行開発を進める仕組みを整えたのです。
スタブは当初は簡単なものでしたが、振る舞いをどんどん本番システムに近付けていきました。スタブというと、テストスタブのように後工程での利用を想定しがちです。しかし後工程で利用するだけでは、テストが積み上がるだけでトータルコストは変わりません。また、システムの作り込みの段階でバグが増えてしまっても、テストがふくらみ、コスト・期間がオーバーしてしまいます。しかし、“より本番に近い振る舞いができるスタブ”があれば、始めからそれを使ってシステムの品質を作り込むことができるのです。
――つまりCA Service Virtualizationを核として、並行開発で“品質を作り込むためのプロセス”をデザインしたことで、テスト工程の効率化を実現させたわけですね？
坪口氏 その通りです。その意味で、興味深かったのはバグの発生率です。通常、バグは最初に一気に噴出して、その後修正されていくため、発生率は時間とともに減っていきます。しかし今回のプロジェクトでは、発生率は直線を描きました。つまり最初から本番に近い環境でテストするため、検出され修正されても、すぐに異なるバグが見つかる。つまり、本番に近いシビアなテストで、より高度な品質が作り込まれていく様子が具体的な数字として確認できたわけです。
本番システムの振る舞いを容易に再現できるCA Service Virtualization
──“本番に近いスタブ”はどのように作り込んでいったのですか？
坪口氏 VDIを使ってパートナー間でコミュニケーションを取りつつ、少しずつ本番に近いスタブに仕上げていきました。便利だったのは、CA Service Virtualizationは、スタブのレスポンス時間や負荷などをパラメーターとして容易に設定できることです。また、CA Service Virtualizationの設定はXMLで記述されているため、そのXMLファイルを加工して数千万件のデータを作成し、より本番環境に近づけるといったことも簡単にできます。
導入に当たっては、いくつかのサービス仮想化ツールを評価しましたが、ほとんどの製品はテストドライバーとテストスタブを提供するツールという位置付けでした。「品質のチェック」ではなく「品質を作り込む」という観点では、より本番に近い振る舞いを再現できるCA Service Virtualizationが最適と判断しました。
──開発の初期段階から品質を作り込み、手戻りを防いで迅速に開発を進める、という点はまさしくDevOpsの核であるアジャイル開発ですね。ツールを使うことで、テスト結果をナレッジとして蓄積できる点もメリットなのではないでしょうか。
坪口氏 テストケースはこれまでMicrosoft Excelで管理していましたが、再利用することは困難でした。CA Service Virtualizationは結果をリポートとして蓄積できる点で、「どの機能で、どんなバグが発生し、どう処理されたか」といった知見を、類似したプロジェクトに再利用することができます。
また、ナレッジが人に依存すると、慣れによる品質トラブルも発生しがちです。例えば一定の顧客企業から複数の開発案件を請け負っていると、開発の習熟度が上がり、早くリリースできるようにもなりますが、開発部門の慣れのせいでテストが不十分なままリリースしてしまうリスクも高まります。その点、開発とは異なるチームがこうしたテストツールを使うことで、より確実に品質を担保することができます。加えて、そうしたテスト結果は次の改善につながる気付きを得る土壌にもなり得ると思うのです。
──今後の展開を教えて下さい。
坪口氏 リリースまでの期間を短く、リスクを分散しながら並行開発するというニーズは今後ますます強まるはずです。そうした中、よりスピーディに高品質なシステムを作る上では、DevOpsという言葉に象徴される開発と運用の連携が欠かせません。その点、CA Service Virtualizationでは、「連携先システムが未完成」「中身が分からない」といったテスト制約の問題を回避しながら、開発初期段階から品質を作り込むことで、運用への受け渡しをスムーズに行う仕組みを整えることができます。これによりトータルでの工期・工数を削減する――すなわち「シフトレフト」を狙うことができるわけです。
弊社には、自分たちのやり方に合うものであれば、新しい技術を積極的に採用し、会社の付加価値を高めていこうという文化があります。現在はCA Service Virtualizationの全社展開を進めていますが、こうした取り組みによって“次世代の新しい開発スタイル”を開拓し、多くの企業のニーズに寄り添える新たな付加価値を今後も提供し続けていきたいと考えています。
Copyright © ITmedia, Inc. All Rights Reserved.
提供：日本CA株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2015年1月31日
