IT運用の将来像を考える 〜標準化と自動化の進展〜(第4回)

IT・IT製品TOP > Key Conductors > 松本 浩彰(BMCソフトウェア株式会社) > IT運用の将来像を考える 〜標準化と自動化の進展〜(第4回)
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

IT運用の将来像を考える 〜標準化と自動化の進展〜(第4回)

開発 2013/02/04

前回は、クラウドの発展に伴って IT 運用が現在より簡素化して行く可能性がある点について述べたが、今回はこの点について、さらに踏み込んで述べてみたい。

パブリッククラウドの可能性

正直に言えば、以前の私はパブリッククラウドというキーワードについて慎重な考え方を持っていた。
「実際どの程度商用に耐えるのか?」「大企業レベルが活用する上で十分な機能性・堅牢性を確保出来るのか?」こう言った懸念が強く、「実際にはそれ程浸透しないだろう。」或いは「浸透する為には相当の時間を要するだろう。」と考えていた。

ところが、私自身の仕事上の理由で Force.com(SalesForce社が提供する PaaS)上で開発を行う事になり、これを決起として私の考え方は大きく変わった。  
Force.com を使った事がある方はご存じだろうが、Force.com上では、社内用、B to B、B to C 等、様々なアプリケーション開発を行う事ができる。且つ、開発にさいしてミドルウェアや OS について全く意識する事が無い。予め提供される部品を組み合わせる感覚で開発を進めるのだが DB 設計等ないし、驚くほど簡単にアプリケーションの開発が可能である。実際に使ってみると、開発の利便性だけでなく、セキュリティの堅牢性や開発物のリリースを行う仕組み等、とても良く考えられた開発基盤であると痛感した。(一般的に通常のスクラッチ開発に比べて5倍の生産性があると言われている。)

開発時にインフラやミドルウェア等を意識しないだけでなく、Force.com 上で稼働するアプリケーションに関しては、運用に入った後でもユーザ側にそれらを管理する業務は存在しない。サーバ監視もキャパシティ監視もサーバ障害の復旧作業もユーザは行う必要がない。(そもそもユーザには OS やミドルウェア等の仕組みが分からないので実施しようが無い)
Force.com では、通常運用部門が面倒をみる作業はサービス提供ベンダー側(Salesforce)が行ってくれる。Force.comのサービス費用には日常的に発生する筈の運用コストが含まれているのである。
ベンダー側が管理責任を広く持つタイプのクラウドを利用する場合は、ユーザ企業から IT 運用自体を外部化するという事になるのだ。

勿論、そうでないクラウドもある。現在国内で提供されている IaaS 等の中には仮想サーバ環境を提供するだけで、そこに搭載されるミドルウェアやアプリケーションの運用管理責任は全てユーザに負わせているものがある。これはらホスティングやハウジングの古い事業形態からクラウドに乗り込んだだけの単純なサービスモデルである。このような場合はクラウド利用を行う運用上のメリットはオンプレミスの場合と比べても劇的には変化しないだろう。

市場で淘汰を勝ち抜くクラウドベンダーは、オンプレミスでは得られなかった価値を新たに提供するものだけであると私は考えている。経営の観点から見て、本来 IT サービスとはどのように企業に提供されるべきかという視点で変革を起こせるベンダーだけが生き残るのである。一方で、ユーザ企業がクラウドを利用する場合は、新たな付加価値を提供するクラウドサービスの提供者を選択してパートナーシップを構築し、IT サービスを企業経営上のインフラとして活用するという発想が必要になってくるだろう。

とは言え、いくらそのような世界が現実化しようとも、全ての企業が全ての IT が外部化するわけではない。前回の記事で紹介した通り、現実的にはハイブリッドクラウド型が最も多く発生する筈である。しかし、私達はこのような混在を今より複雑化したものと捉えるのではなく、正しくクラウドに移行できたシステムでは従来のオンプレミスよりも運用負荷が軽減されると捉えるべきである。

このように考えていくと、ユーザ企業内での IT 運用業務は現在よりも縮小化・局所化すると考えられる。将来的には自社内に残存する IT の管理と、それらとクラウド上の IT とのインターフェースの管理といったものになっていく可能性がある。では、IT 運用管理者は不要になるのだろうか?私はそうは思わない、むしろクラウドの発展に伴って今までにない開発者と運用者の関わりが生まれてくると考えている。

DevOps

ここで、私が今回取り上げたいキーワードが「DevOps」である。
ご存じの方もいるかもしれないが、これは開発組織と運用組織を一体化していくという概念である。日本でも開発部門と運用部門の間には壁があるが、これを取り払い、ビジネスからの要求をITサービスとして実現する為に、開発部門と運用部門相互の協力関係・依存関係を変えていく必要があるという事が、ここ数年世界的に論じられている。  

この DevOps の背景の一つにはアジャイル開発があると思う。
クラウド上でも開発はアジャイル型で行われる事が多いが、開発手法がアジャイル型にシフトして来ている要因には、ビジネス環境の変化がある。
グローバル化に伴ってビジネス環境が急激に変化するような状況では、ビジネス環境の変化にタイムリーに対応する事がより重要になる。半年かけて要件を取りまとめ、1年かけて開発する(つまり実現される要件は1年半前のビジネス要求)といったウォーターフォール型の開発ではビジネスに追随できなくなって来ているのだ。

アジャイル型で開発が行われると、本番システムへの反映もタイムリー且つ頻繁に行えなければならない。従って、統制・牽制重視の古い変更・リリース管理のスタイルではこれに対応出来ない。手順書をゼロから起草し、形骸化した階層的承認を何回も経て、人海戦術でリリース作業を休日に行うという運用手法では歯が立たない。実際、パブリックの IaaS を使って開発側がアジャイルを展開する一方で、運用部門側ではシステムの構成管理や変更・リリース管理等に混乱を来している例も出てきている。

このような動的なリリース管理といった、新たなテーマに取り組むにはIT運用においても新たな手法を取り入れる必要がある。それが「DevOps」である。DevOpsでは変更管理やリリース管理の仕組みは極度に自動化されており、開発側のリリース要求に対して最少限の人的介在のみでリリースがシステムに反映する。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

ただし、このような仕組みが成立する為には、幾つかの前提がある。

■前提1(標準化と自動化)

まず、リリースの仕組み自体が簡素化されていなければならないが、その為にはITインフラ自体が制御し易くなければならない。
旧来のようにシステム単位でバラバラに設計されたインフラでは、リリースの簡素化は出来ない。しかし、優れたパブリッククラウド上ではこれが可能になる。
企業として利用するパブリッククラウド基盤を厳選し、横断的に利用する事でインフラの管理を極端に簡素化できるし、さらにクラウドが提供する自動的なリリース機構を使って迅速にリリースを展開する事も可能だ。パブリックを応用する過程で、企業内に残存するシステムについてもプライベートクラウド化等によってインフラの標準化を推進し、プロビジョニング機構等を利用して(第2回記事参照)自動的なリリースを推進する事も重要である。

■前提2(組織の一体化)

次に、運用者が開発者と一体化しITサービスの調達に参画する必要がある。
ここで重要な事はビジネスに対して提供すべきは「IT機能」ではなく、「ITサービス」であるという事だ。
ITILではUtility(有用性・機能性)+Warranty(条件)=Value(ITサービスの価値)であると説いている。  
*詳細は、Key Condactors 杉谷氏の記事を参照。

ここでUtility(有用性・機能性)を、開発者が構築する機能そのものとした場合、Warranty(条件)は運用者が提示する運用条件である。 SLAを満足させる為の可用性やセキュリティ等の条件、或いは維持メンテナンスを自動化する為の変更・リリースの制御方法など、様々なITサービス利用時の条件を分析し、最適な基盤を選択し、開発者に提示するのである。つまり、IT運用組織はITサービスを提供する際の条件を提示する為の能力を身につけたエキスパート集団であり、IT機能の開発に対して従的な存在ではなく、ITサービスの調達において同等な存在であるべきなのだ。

そもそも、これから発展するクラウドの世界では、開発自体の位置づけが低下する可能性がある。今回記事の冒頭ではPaaS(Force.com)上での開発作業を例示したが、SaaSの場合では、出来あいの「ITサービス」をそのまま(或いは少しだけ修正して)提供するレベルになる。そうなるとUtility(有用性・機能性)は予め出来あがっており、サービス調達の検討ポイントはWarranty(条件)のみになる。その際には、クラウドベンダーのサービスに対して十分な情報収集をし、自社の要件に対して適切なサービスレベルとコストを提供できるベンダーの目利きを行う運用組織の力量が最も重要になるのだ。
一概に目利きと言っても、既存のITインフラの管理経験・スキルのない者がそれを担える筈もない。クラウドベンダーの内部には、やはりサーバ・ネットワーク・ストレージ・ミドルウェアが存在するのだ。クラウドベンダーが成熟していく過程では、様々な運用上の制約が契約条件の背後に隠れている事だろう。信頼できるパートナーを選びだすには、IT運用に関する横断的で高度な理解が必要なのである。

ただし、ITインフラやIT運用に詳しいだけの人材ではDevOpsを実現できない。開発と運用が一体となってビジネス部門に向き合う場合には、運用組織が恒常的にビジネスニーズに直面し提案をする能力が必要になる。つまり、ビジネス自体に対する理解を深める必要があるし、コミュニケーション能力や提案力等が総合的に求められてくる。  

将来求められるIT組織の姿は、企画→開発→運用(所謂、上流から下流へ)というセクショナリズムに縛られた硬直的なものではなく、それぞれのエキスパートが集って如何に素早くITサービスをビジネスに届けるかをタイムリーに提案するというオープンで柔軟なものである。機能を開発する事自体に自身のアイディンティティを求める開発組織は時代遅れになるだろうし、自ら運用する事にアイディンティティを求める運用組織も時代遅れになる。
これからは、ビジネスを満足させる為に、市場で使える最良の技術を利用する事を目標にするエキスパートの集団のみが生き残るであろう。 

さて、今回はクラウドの展開に伴う将来のIT運用の在り方を、技術的な観点と組織的な観点から述べてみた。特に後半の組織についての言及は、現在の国内のIT組織の在り方からかなりギャップがあるので、実際どのように組織転換を図る事ができるのか悩む方が多いと思う。組織に関する変革は企業それぞれに事情が異なる為、共通の解決策というものを提示する事は難しいのだが、変化を恐れずに敢えて自らを変えるという意識を持って、IT運用に携わる皆さんには将来を見据えて考えて欲しいと思う。

第2回の記事と締めくくりは共通になるが、これからのIT運用者は、作業者ではなく「よりよいサービスをビジネスに届ける為の」戦略家になるべきなのだ。
今までと同じような仕事をしたいと考える方が危険である。変化をしない事自体がリスクであるという時代に私達は身を置いている。敢えて自らを変えられる技術者はクラウドの世界でも活き々と活躍できるだろう。  

次回は、第2回の際に読者の皆さんからフィードバック頂いたSNSの活用についてクラウド技術とからめて少しだけ言及し、その後に当記事の最終的な目的である将来のIT運用の姿について、今までの内容を総括しながら記載して行きたいと思う。是非次回もご覧頂きたい。

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30005892


IT・IT製品TOP > Key Conductors > 松本 浩彰(BMCソフトウェア株式会社) > IT運用の将来像を考える 〜標準化と自動化の進展〜(第4回)

このページの先頭へ

キーマンズネットとは
1997年BMCソフトウェア株式会社に入社。以降15年に渉り、IT運用に関する様々な領域でソリューションの提案やコンサルティング業務を行ってきました。2004年以降数年間 itSMF の分科会活動(事例研究分科会・SLA分科会・ガバナンス分科会)にも参加させて頂きました。

ページトップへ