攻めの「ビジネス視点DevOps」ってどんなもの？：企業システムだってスタートアップ企業並みに機動力を高められる
新興サービス企業が群雄割拠する中、エンタープライズレベルで彼らの機動力を手に入れるには？運用と開発が一体となりビジネス価値に貢献する情報システム部門であるために、DevOpsというムーブメントはどう取り込むべきだろうか？
DevOpsってスタートアップ企業で小さくやっているだけのもの？
開発系の技術者の間で注目されている「DevOps」。サーバ仮想化やそれに伴う管理運用ツール類の共通化・自動化などの後押しもあり、いままさにIT技術者の注目を集めている言葉でもある。さて、このコトバ、運用者にとっては「ちょっと関係がない話」だと思っているのではないだろうか？
そもそも、DevOpsという言葉はアジャイル開発に代表されるビジネスニーズに即した形でソフトウェア開発の品質を高める議論の中から生まれてきた言葉といえる。むろん、そこにサーバ仮想化、システムの構成と運用の管理効率化の波に乗って、ある程度の自動化が進んだこともその背景にあるだろう。
継続的に開発を行い、迅速に反映していくこの手法は、Webサービス企業やスタートアップ企業のような、比較的「身軽な」――言いようによってはシステム運用人員に余裕が持てない――スタートアップ企業で実践されている印象だ。
さて、このDevOpsというムーブメント、エンタープライズシステムの、しかも運用側の人間にとってはまったく関係のない話に見えるが、マイクロソフトは「Enterprise DevOps」というキーワードを企業情報システム部門の運用者／開発者向けに発信している。エンタープライズシステムで、運用と開発の新たな取り組みが本当に可能なのだろうか？
本稿では、Scrum Alliance認定スクラムマスターでもあり、アジャイル開発の手法にも詳しく、企業への啓発も積極的に行っている日本マイクロソフト デベロッパー＆プラットフォーム統括本部 エバンジェリスト 長沢智治氏に、その意図を聞く。
情報システム部門の立ち位置が変わってきた
なぜ、企業情報システム部門においてDevOpsの採用が必要なのだろうか。長沢氏はその理由として、企業のIT戦略を取り巻く環境の変化を挙げる。
「新しい技術やサービスがどんどん出てきていて、企業と顧客の距離は非常に緊密になり、直接対話ができるようになってきました。例えば、スマートデバイスから製品の直接購買やレビューもできます。また、突然ビジネスが拡大したとしても、クラウド環境で運用していればスケールさせることは簡単。つまり、IT技術の革新によって、ビジネススピードが以前と比較にならないほど加速しているのです」（長沢氏）
情報システム部門としては、従来のような重厚長大な開発を行っていては顧客ニーズ獲得のチャンスを逃してしまうことになりかねない。より、早いスピードでの開発とサービスローンチを、きちんとビジネス価値を創出できる形で展開する必要性に迫られていると長沢氏は分析する。
サーバ仮想化による集約やシステム管理ツールによる効率化、リソースの柔軟な再配置については、多くの＠IT読者が、自社内システムで何らかの形で仮想化環境を導入、クラウド環境を導入していることだろう。過去に実施した読者調査からも、仮想化環境の導入は一定程度進んでいることが分かっている（参考記事）。
「例えばマイクロソフトテクノロジでいえば、Windows Server 2012が提供する仮想化技術Hyper-Vを使ったサーバ集約や、それらの物理／仮想サーバ群を一括で管理する製品System Centerがあります。多くの企業ではこうしたサーバ集約と運用効率化、リソースの効率的な配分によって大きなコスト削減を実現しつつあると考えられます」（長沢氏）
しかし、現段階で、クラウド移行による柔軟でスケールしやすいシステム構成やDR対応、メンテナンス効率化などを実現したとしても、いまや不十分といわれる時代になってきているのだという。
「技術革新が次々と起こる中、それに追随できなければ事業そのものがドライブしないことに、多くの企業が気付き始めています。それを象徴するように、IT予算や意思決定がCIOからCMO移ってくるのではないかとも言われています。というのも、情報システム部門は単独で成立するものではなく、ビジネスを動かす要素として認知されつつあるからです」（長沢氏）
運用部門が次に打つべき「手」は？
そうは言っても、今までも運用側はかなりの努力をしてきたはずだ。さらにもう一手ビジネスに貢献する施策を、と言われたときにあなたならどうするだろうか？
長沢氏は、その答えを「開発と運用の“壁”を取り払うこと」だとする。
現在のエンタープライズシステムについて、長沢氏は「ユーザーと開発者、開発者とテストチーム、テストチームと運用チームの間のコミュニケーションパスが分断している状況」と分析する。
ユーザー側が求める機能に、開発者はともすると関心がなく、テストチームと開発チームの間も、運用チームとの間も縦割りの役割分担が出来上がっている。こうした体制の課題は、ユーザーニーズへの的確なタイミングでの対応ができないこと、部門間連携が不十分で迅速な対応ができないこと、これに起因してシステムエラーに対しての対策が遅れがちになることなどが挙げられる。
これこそが、今後、情報システム部門が克服しなければならない「壁」＝阻害要因なのだという。そして、その壁を克服するための手法として、まずは運用と開発の距離を埋める仕組みが必須だと、長沢氏は強調する。
「いま、開発系の技術者を中心にこうした課題への取り組みとして“DevOps”が注目を集めていますが、今後は企業システムにおいても対応は必須となるでしょう」（長沢氏）
運用側の本番環境が整わなくてアプリケーションのデプロイができない、あるいは開発側が勝手なアプリケーションをリリースした結果、運用側がトラブル対応に忙殺される、などという話はどこの企業でも多少はあるものだろう。
運用側がトラブルに直面して原因究明を進めても、開発側が開発しデプロイするまでの間、何をどう構築していたかなどという情報がない以上、開発側に問い合わせるしかない。ここで、開発側の担当者が忙しくてつかまらない、あるいはそもそもアプリケーション側の情報が全く取れないといった状況では、コンシューマニーズをみすみす逃してしまうことになりかねない。
そこで、運用側も開発側との積極的な協調・連携を進めることで“ビジネスに貢献する”情報システム部門を立ち上げていく必要があるのだという。この発想がDevOpsだ。“ビジネスに貢献する”とは、ITにおける2つの課題に取り組むということだ。ビジネスアイデアを動くソフトウェアにするサイクルタイムの適正化と、本番稼働中のアプリケーションの障害にいち早く対応するMTTRの短縮化だ。これを実現するためにもDevOpsの発想が大切だ。
統一プラットフォームだからできるエンタープライズレベルでのDevOps
長沢氏は、エンタープライズシステムにおいては、マイクロソフトプラットフォームが圧倒的に優位だと説明する。どこに利点があるのだろうか？
長沢氏はこの問いに対して、「アーキテクチャ／プラットフォームの統一性と利便性」を強調する。いわく、開発環境も運用環境もトータルで提供するマイクロソフトならではの仕掛けでより効率のよいDevOpsスタイルを実現できる点が最大の特徴になるのだという。
「システムアーキテクチャが比較的一本化できていて、開発もそのアーキテクチャに従うようなスタートアップ企業であれば、開発と運用の両方のスキルのある人材がいればOSSで構築することも良いでしょう。しかし、複雑なシステムを管理している運用部門と、目的ごとに開発している開発部門があるエンタープライズレベルでは、運用と開発の規模や粒度が一定にならないため、必ずしもスタートアップ企業のやり方が適しているとは言えません」（長沢氏）
マイクロソフトでは、運用向けにはSystem Centerを、開発向けにはVisual Studio製品群を提供している。管理・運用面で効率のよい標準化が実現するのはもちろんだが、マイクロソフトプラットフォームでDevOpsを実施することの最大の利点は、運用・開発の両部門のワークフローに影響を与えないこと、両製品群が持つ機能を相互に利用できることが挙げられるだろう。
Visual Studioのデバッグツール、System Center Operations Manager／Orchestratorはいずれも、ユーザーの評価が高いツールと言われているが、それらを相互に利用できるのだ。以降では実際のシナリオを例に、その有効性を見ていこう。
シナリオ1：運用エラーの問い合わせプロセス改善
運用場面で問題が発生した場合、通常であれば開発ツール側でのデバッグが必須となる。運用側は把握できる範囲のエラー発生状況を開発側に渡すくらいしかできないことがほとんどだ。これが、System Center 2012製品群＋Visual Studio 2012製品群の組み合わせであれば、まず、Operations Managerで障害を検知すると、Team Foundation Server側に自動的に情報を提供できる。
ここで、ログなどの情報提供はもちろんだが、運用側のSystem Centerから本番稼働中のシステムのデバッグ情報を収集できるIntelliTraceを走らせて、問題があるプログラムのおおよその当たりをつけるところまでの作業が、運用側でも実現できるのが、この「合わせ技」の大きなメリットになっている。
IntelliTraceはもともと、Visual Studio 2010から実装されているデバッグ支援ツールだ。Visual Studio 2012からIntelliTraceを本番環境で起動できる機能が追加された。Visual Studio 2012とSystem Centerの組み合わせであれば運用ツールのインターフェイスからこの機能を利用できるようになっている。
問題の情報はSystem Centerから直接開発コラボレーション環境であるTeam Foundation Server側に送られるため、開発側も詳細情報を得たところからデバッグを進められる。
まず、問題への認識の課程がこれで自動化されることになる。開発側は対処が終わり次第Team Foundation Server側でステイタス変更を行えば、System Center側にその情報がリアルタイムで通知されるようになる。
「この連携では、両部門とも使い慣れたインターフェイスから相手部門の情報をリアルタイムで取得できます。担当者が不在でも、海外にいても、問題の共有はツール側で集約されていますから、対応のスピード感が違ってくるはずです」（長沢氏）
相手側が何らかの操作をすると、こちら側のツールもリアルタイムでそのステイタス変更を確認でき、すぐに次のアクションに取り掛かることができる。このため、実運用環境で何らかのエラーが出てすぐに対応しなくては機会損失になる、といった緊迫した状況でも迅速に対応が図れる仕掛けだ。
この連携では、運用側と開発側のワークフローが統一されているわけではないのが特徴だ。運用では運用のワークフロー、開発では開発のワークフローの中で、お互いが共有認識するフローを共有することができる。したがって、運用と開発の異なる時間軸、価値観をツールの仕組みが吸収してくれるため、人に負担をかけず効率よく問題の解決にあたれるのだ。
シナリオ2：運用側視点で開発環境の自動展開を推進
両ツールを活用することの利点はこれだけではない。System Center側ではOrchestratorを使って、いわゆる「Runbook」も設定できるため、開発側に対して運用側の要望や要件を加味したRunbookを提供すれば、どんなスキルの開発者であっても検証済みの環境を立ち上げられるようになる。
Runbookで開発側もテスト側も共通したシナリオでインフラの構成を配布できることから、ローンチ前に一定程度の品質の向上が可能だ。
このようなシナリオは、両ツールが共にマイクロソフトによって連携を考慮した実装が行われているからこそ可能になる仕掛けだ。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
運用側が開発側の環境にコミットし、開発側が運用側の課題にコミットできるこの環境は、ビジネスニーズにマッチじた速度でIT戦略を推進しなければならないこれからの企業情報システム部門の在り方に一石を投じる可能性がある。
既にHyper-V環境のインフラを持っているならば、Visual StudioやTeam Foundation Serverなどの開発環境との合わせ技を効果的に採用することで、有利な環境でDevOpsを推進できるチャンスとなるだろう。
また、Visual Studio製品群でのアプリケーション開発を推進しているならば、インフラ側の運用をSystem Centerに集約し、開発と運用の壁を取り払い、効果的に「攻め」の開発・運用プロセスを採用することを検討してみたいところだ。
エバンジェリストに解説を依頼するには？
本稿で取材に対応いただいた、日本マイクロソフト 長沢智治氏は、エバンジェリストとして企業向けに最新の開発環境の動向やアジャイル開発、DevOpsなどの講演を積極的に行っている。
本稿では誌幅の都合で詳述できなかった、より現場視点でのDevOpsプロセスの話題などはぜひ直接聞いてみてほしい。詳細はソフトウェア開発環境の最新動向で確認できる。
Visual Studio 2012 についてもっと知るには？
Copyright © ITmedia, Inc. All Rights Reserved.
関連リンク
提供：日本マイクロソフト株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2013年5月31日
