なぜ速く作る必要があるのか？ 何のために開発するのか？―アジャイル、DevOpsをサービス観点で今あらためて問い直す：特集：DevOpsで変わる情シスの未来（8）（1/2 ページ）
2013年までの盛り上がりから一転、国内ではほとんど聞かれなくなった言葉「DevOps」。だがその概念の重要性は、多くの企業に着実に浸透しつつある。「IT＝サービス」という観点から、今あらためてDevOpsの意義とポイントを問い直す。
「DevOps」は、やっぱりバズワードだったのか？
年々激しさを増す市場環境変化を受けて、ビジネスを支えるシステム開発・運用にも一層のスピードと柔軟性が求められている。そうした中、2012年から2013年にかけて、「開発と運用が連携してスピーディにシステムを開発、継続的に改善を重ねる」という概念「DevOps」が大きな注目を集めた。
だが周知の通り、昨今はこの言葉を目にする機会がめっきり減った。DevOpsが明確に定義された「プロセス」や具体的な「ツール」などではなく、あくまで“概念”ということや、開発・運用のプレーヤー、ベンダーによって、発するメッセージ、解釈がまちまちであったことも災いしたのだろう。そのイメージは曖昧なまま一人歩きし、大方にとって「一過性のバズワード」「理想論」と受け止められてしまった印象が強い。
しかし市場環境がシステム開発・運用にスピードを求めているのは事実。DevOpsという言葉こそ聞かなくなっても、「素早くアプリケーションを世に出して反応をうかがい、システムを発展させる、あるいは廃棄する」といった“DevOps的な取り組み”の重要性はさまざまなプレーヤーが異口同音に口にする。現に、DevOpsというとWeb系企業の取り組みといったイメージも強いが、欧米では金融、製造、流通、小売りといった一般的な企業が「顧客満足度を高めるために」、各種ITサービスの開発・運用に進んでDevOpsを適用する例が増えている。では規模を問わずグローバルでの競争が強いられている中にあって、日本国内ではDevOpsを「バズワード」と切り捨ててしまってもいいのだろうか？――
本特集「DevOpsで変わる情シスの未来」は2013年9月にスタート。主にDevOpsという“概念”の輪郭を追ってきたが、アジャイルな開発・運用アプローチが一般的な企業にも求められている今あらためて、この言葉の“中身”にフォーカス。エンタープライズにおける実践のヒントをより具体的な形で探っていく。
特にフォーカスしたいのは、「必要なときに、必要なだけ使える」クラウドの浸透により「サービス」という概念が浸透した今、開発分野においても、「ITをサービスとしてユーザーに届けるにはどうすればよいか」「どうすればビジネス価値につなげられるか」というビジネスゴールを見据えて手法、ツールを選ぶ機運が高まっていることだ。これまでDevOpsというと、どうしても手法やツールの側面が注目されがちだったが、ここであらためて「サービス」という観点から具体的な手段を探ってみたい。
今回は、ITサービスマネジメントに深い知見を持つ、日本IBM サービスマネジメントエバンジェリストの岩村郁雄氏に話を聞いた。
DevOpsもITILもゴールは同じ
編集部 岩村さんはDevOpsが半ばバズワードとして受け止められ、国内では進展していない理由をどのように見ていらっしゃいますか？
岩村氏 多くの人にとって、「DevOpsはWebアプリケーションをメインとし、自社内に開発部門と運用部門を持つWeb系企業の取り組み」といったイメージが強かったのではないかと思います。実際、米国ではそうした企業が多く、開発を外部に委託することが一般的な日本企業とは体制が異なっている点で、自社にとっては現実的ではないと受け取られる傾向が強かったのではないでしょうか。またDevOpsというと開発側の観点が強く、運用部門の立場から見ると、「Ops」の取り組みに対し、しっくりこないという見方も多かったように思います。
編集部 開発と運用が組織的に分断されている問題はこれまでも指摘されてきたところですが、「Ops」に対する違和感とは、具体的に何を指すのでしょう？
岩村氏 以前から運用を担ってきた人たちからすると、DevOpsを実践する仕組みやツールに含まれている「運用」の部分は、変更管理とリリース管理だけなんですね。つまり、アプリケーションを世に出すまでの仕組みであって、「その後の安定運用」を担う視点が抜け落ちている。そう受け止める向きが多かったのでは、という意味です。
DevOpsでは、主に「作る」視点からアプリケーションの継続的改善が語られています。例えば「いかにミスなく迅速にITサービスを世に出し、購買機会を増やしたか、ロイヤルティを高めたか」など、「アプリケーションが提供する機能の向上」で取り組みを評価します。一方、運用側、特に運用管理のベストプラクティス集であるITILの観点からすると、「改善によってどれだけミスがなくなったか、イベントが減ったか、ユーザーからのクレームが減ったか」といったように、リリース後の安定運用が評価指標となります。このように開発と運用で評価指標がずれている点が、DevOpsに対する開発側と運用側の認識のギャップを生みだす一因になったと思います。
しかしITILの念頭にあるのは、「ユーザーにいかに価値を提供するか」という考え方。サービスの創出から廃棄まで、サービスライフサイクル全体を回すことでユーザー価値を実現、向上させることが目的です。つまり、速いペースでアプリケーションをリリースし、改善していくDevOpsと同じことを言っているんですね。本当は開発も運用も同じゴールを見据えていながら、評価指標がうまくかみ合っていない。
とはいえ、ビジネス展開にこれほどのスピードが求められている今、Web系ではない一般的な企業もDevOpsを進んで取り入れていく必要があります。開発部門と運用部門で、「ITサービスによってユーザー価値を高める、ビジネスを推進する」というゴールを見据え、そのためにはそれぞれがどのような評価指標を持つべきか、共に考えることは非常に重要だと思います。
運用部門がリードしなければDevOpsは回らない
編集部 「ITサービスによってユーザー価値を高める」という目的はDevOpsもITILも同じ。そのゴールに向けて評価指標をすり合わせるということは、たとえ開発と運用が組織的に分断されていても、互いの役割を整理し、明確化することにつながりますね。
岩村氏 そうですね。ただ、サービスが世に出てから、何かあれば責任を取るのは運用部門です。その意味で、運用部門が主体でなければDevOpsはうまく回らないと考えます。
例えば迅速にリリースできるよう、あらかじめ「運用の受け入れ基準」を明確化し、それに沿って作ってもらえるよう開発部門と協議する。具体的には「問題が起きたときに自動的にリカバリできる仕組みを入れてください」「ログのフォーマットは統一してください」など、障害に確実かつ効率的に対処できる仕組みをあらかじめ組み込んでもらう。これには「何かが起きたときに、誰に、何を連絡するかをあらかじめ決めておいてください」といったことも含まれます。
従来であれば、リリースに当たって運用受け入れ試験を行うのが通常ですが、それでは何度もリリースするDevOpsのスピードには対応できません。またDevOps型のサービス実装では、変更の規模やリスクが小さい方が一般的です。そこで「標準的なデプロイ」としてリリースに必要な条件をあらかじめ定義しておき、開発成果物に組み込んでもらう。つまりデプロイに関する手続きを簡略化し、さらにリリースプロセスの自動化も取り入れることで、素早く確実なリリースとその後の安定運用を狙うわけです。
また、DevOpsでは何度も変更管理を行う必要がありますが、従来の変更管理では、「変更要求書の起票、優先度の判断、変更計画への組み入れ、評価、承認」といった一連の評価手続きを行います。この点について、ITILでは変更の影響度に応じて、一連の手続きを簡略化する「標準的な変更」、一連の手続きを踏む「通常の変更」、緊急の承認会議を実施する「緊急の変更」の3段階に分けて管理することを推奨しています。
その点、DevOpsにおいて、変更のたびに一連の手続きを踏む「通常の変更」を行っていてはスピードを担保できません。そこで、影響範囲が少なく不備があっても即時に切り戻し可能な変更については、あらかじめ「標準的な変更」とみなして承認手続きを簡略化し、変更プロセスを自動化する。こうした取り組みも、スピードと確実性を担保する上で重要なポイントになります。
Copyright © ITmedia, Inc. All Rights Reserved.