Loading
|
@IT > 運用管理部門が変わる:開発との関わりを深めながらITサービス提供の主体部門へ |
企業情報システムにおいて、上流工程であるIT戦略立案や開発のシワ寄せを一身に受け、立場上いわれなく泣かされ続けてきたのが運用管理部門だった。しかし、ITILの日本での普及を契機に、ムリ・ムダのない効率的なIT業務のあり方が議論されるようになり、実際、この部門は利用者視点に立ったITサービスの提供主体者として、そのポジショニングが根本から変わりつつある。ITにおける部門間連携を軸とするライフサイクルの観点から、開発、運用管理の間にある垣根は取り払われようとしている。具体的にどうすれば可能になるのだろうか。これからのITシステムにおける運用の理想像を探ってみよう。
これまでITシステムの運用管理というと、“受け身”の体制を余儀なくされてきた。通常、システムは何事もなく動くように作られているものであり、運用管理部隊というのは、何か不測の事態が発生したとき緊急対応するために存在する、いつどこでどのように出動を要請されるか予測ができない職種の代表的なものと認識されていた。 また、いわれなきプレッシャーにさらされる仕事でもあった。カットオーバーされたシステムは、その重要度や品質のいかんに関わらず動き続けているのが当たり前で、あらゆるシステムはダウンタイムゼロでなければならないという利用側の幻想があり、システムの優先順位に応じたサービスレベル管理という概念はなかった。そのため、ひとたび何か“コト”があれば、運用管理部隊はどうなっているのか、いつ復旧するのか、と突き上げを食らう。まるでその事件を引き起こした犯人のように責められるのだ。 しかも、問題を迅速に解決したところで、感謝の言葉が掛けられるわけでもない。これまた元に戻すのが当然の仕事だと思われているからである。運用計画やハードウェア更新を含む前向きなタスクもこなしながら、すべてのシワ寄せを一手に受け止めて持ちこたえる、頼もしい縁の下の力持ちなのだが、これまでは誰がその任に当たってもモチベーションが持続しにくい、不遇な仕事の1つであった。 このような状況を生み出している原因は、置かれている立場の宿命と利用側の勝手な思い込みだけなのであろうか? 他に原因は、そして抜本的な解決法はないのだろうか……。これは、運用管理部門の管理職にとっては世界共通の悩みであった。
しかし、幸いなことに、運用管理のあり方は変えられることが分かってきた。そして、実際に今、変わりつつある。そのキードライバーとなっているのが、ITIL(IT Infrastructure Library)である。ITシステムの運用管理をサービスのマネジメントとしてとらえて、そのベストプラクティスを集めて作られたフレームワークとして英国で生まれたものだが、今では世界的に広く利用されている。 ITILは、企業や組織が「ビジネスの目標に沿った形でITシステムを運用する」とはどういうことなのかを根本から再定義し、ムリ・ムダの少ない、効率的な業務の進め方を世界に示した。つまり「ITシステムの提供」を「ITサービスの提供」へと位置付け直したのだ。これはとりもなおさず、情報システム部門の中に開発、運用管理といった縦割りの組織を持つことを含めて改め、利用者の視点に立った一枚岩の“サービス”として提供すべきだということを示唆している。 さらに、上記のようにITサービスを利用者に提供するに当たっては、さまざまな主要業績評価指標(KPI)を設定することで、例えば「止まらないのが当たり前」、「もし止まっても、すぐに動いて当たり前」をゴールにするのではなく、「どの程度止まらないようにするのか」、「どの程度の時間で復旧させるのか」、などの現実的な目標設定をあらかじめ行った上で現状から改善していくというアプローチを取り、それらを利用側と共有する。つまり、受け身のものを前向きに取り組めるよう、まさに座標軸の転換を行っているのだ。これまで上流工程のシワ寄せを一身に受け、泣かされ続けてきた運用管理部門が、まさに今こそ、前向きに動き始めるときなのである。 実際、ITILを導入する企業は増えている。今までのIT業務を抜本的に洗い直し、全体最適の観点からプロセスを改善または再構築することから、一般には大幅なコスト削減や満足度向上が期待できるからである。また適正なサービスレベル設定による管理やパフォーマンス向上も実現できるため、ITのビジネスへの貢献度が上がるというメリットもある。昨今は、日本版SOX法への対応が求められている中で、内部統制に必要なIT全般統制の確立にITILが有効という見方が広まっており、この観点からITILの導入を決断するところも多いようだ。
実は、ITILがすべてというわけではない。これからの運用管理は何が何でもITILベースでなければならないということではなく、ITサービス提供上、特に課題がなく、すでに自社に成熟したITサービスマネジメントのモデルがあるというのなら、それで十分であろう。ただ、ITILはベストプラクティスの宝庫であり、ニーズがあるならぜひ実践した方が望ましいというものもいくつかある。その1つが“アプリケーションのライフサイクル”という考え方だ(2006年春に日本語版が刊行されたITIL「アプリケーション管理」第5章を参照)。 ITサービスの中核を担うアプリケーションを管理する場合においては、その構想が立ち上がった時点から、使命を終えて正式に廃棄する時点までを通じて見据える必要があり、これをきちんとフォローし続けることが肝要であるとしている。すなわち、ライフサイクルとして、利用側のビジネス「要求」に端を発する「要件」を挙げ、「設計」を行い、それに基づいて「構築」し、完成した後は企業内に「導入」展開し、「運用」を行い、利用に合わせて「最適化」を図り、それをまた「要件」の一部として挙げるといった形で、開発と運用の垣根を越えてアプリケーションがたどる一連の道すじをとらえているのだ。 その際、例えば設計の時点においては、本来考慮すべき「サービスデリバリ」のプロセスのみならず、「サービスサポート」に含まれる運用のプロセスをも考慮して設計を行う、というように、各ステップが必ずすべてのプロセスとの関係を意識するようになっている。これは結果として、そうした考慮を含んだライフサイクルによって開発・運用を全体の中の相互に関連する部分としてとらえることで、真に連携することができるようになるからである(図1)。
英国本国においては、ITILバージョン3と呼ばれる最新版が2007年5月に登場予定だが、そこではさらにライフサイクルの考え方がITサービス全体の次元にまで高められ、推し進められているという。ITサービスをライフサイクルで考えるとはどういうことか、一連のフローの中で各ITサービスマネジメントのプロセスはどういう役割を果たすべきか、といったことが今まで以上に詳しく解説されている。
開発部門と運用管理部門がライフサイクルにより一体となる。それを実現するために、具体的にはどのような手だてがあるのだろう。重要な橋渡しの役目を果たすであろうと容易に想像できるのが、ITILでいうところのCMDB(Configuration Management Database)、構成管理データベースである。 CMDBは、PC、サーバ、ネットワーク機器、パッケージソフトウェアなど、ITを構成するさまざまなアイテム(ITILではCI、Configuration Item=構成アイテム)を捕捉するとともに、その相関関係や関連履歴を一元的に管理するものである。このデータベースをみれば、その企業情報システムの全体像が把握できるという、ITサービスマネジメントを行う上でのセンターピースだ。 現状のITILで記述されているCMDBの要件としては、構成情報履歴の論理データベースであること、構成アイテムの関係が記録されていること、構成アイテム情報へのリンクが張られていること、構成管理プロセスによって維持・管理されていること、すべてのITサービスマネジメントプロセスで使用できることなどがある。現状を常に反映しながら、ITはこうなっているはず、というような変更計画立案の対象として扱える情報を提供する。 しかし、複数の調査会社は、このCMDBが今後さらに重要な役割を担い、進化を果たすべきであるとしている。いわく、構成アイテムとITサービスを定義してモデル化したり、インベントリ管理、変更・構成管理(ソフトウェア配布)などで利用する同種のデータベースとの整合化や一元管理を可能とする連合化を図ったり、アプリケーション間の相互依存度をマッピングしたり、視認性を高める可視化を実現したり、厳密なアクセス権限管理を有していたりすることが求められるというのである。 このようなCMDBをすでに製品化しているのが、日本ヒューレット・パッカードのHP Universal CMDB softwareである。ビジネスサービス指向のCMDBとして、複数ソースから得た現状の構成アイテムに関する状態記録のすべてと、それらの間の相互関係を総合的に維持・管理できる。これを設計、構築段階をも巻き込んだITサービスプロセス全体で共有することで、サービスレベルの向上、リスクとコストの低減など、まさにユニバーサルなCMDBとして高い価値をもたらすものだ。もちろん、調査会社が求める、構成アイテムの発見およびマッピング、情報の整合化・連合化・可視化、構成変更履歴の追跡(同期化)といった先進機能をすべて備えている(図2)。
これら高いレベルの要件を満たしたCMDBを持ち、開発部門、運用管理部門の間で適切に共有することができれば、組織の垣根は越えられる。ITIL実践成功の鍵は、一にも二にもこのCMDBの作り込みにかかっているともいわれていることから、全体最適実現の上からもよくよく考えたいところである。
冒頭、かつて運用管理部門は“受け身”での仕事を強いられてきたものが、ITサービス提供の主体部門として変身するときが来た、と書いたが、そのために必要な要素がいくつかある。なかでも重要なのが、「プロアクティブ」(積極的であること)、そして「プレディクティブ」(予測可能なこと)の2つだ。 プロアクティブというのは、利用者との間で合意を得たサービスレベルを満たし、またそれを持続させるため、課題を自発的に見つけて積極的に取り組む姿勢を意味している。先にITILのところでも、前向きに取り組めるよう座標軸の転換をはかった、と述べたように、ITILの中でも活用されている概念である。そしてプレディクティブというのは、ITサービスの状態が将来どのような変化をたどるのか、悪化が予想されるようなときには、どのように対処すべきかといったことについて前もって考えておこうとすることだ。広義のリスク管理ととらえてもいいかもしれない。人間でいえば、倒れてから治療するのではなく、少々のことがあっても倒れないような体を作る予防医学の考え方である。 すなわち、問題の兆しが発生するはるか以前の時点で、必要な構成アイテムに対し余裕を持って対策を講じる。日本HPのHP Application Mapping softwareという製品は、このことを象徴するようなソフトウェア製品だ。アプリケーションとインフラの動的な関係を可視化し、トポロジマップ(関係図)を自動的に作成。先のHP Universal CMDB softwareと連携してリアルタイムな状態表示により正確な状況判断を促し、ビジネスリスクの軽減とダウンタイムの短縮を実現する。構成アイテムの特性や相互依存関係も一目で把握可能だ。もしあるサーバが停止すると、どのITサービスのどの部分に影響を及ぼすか、といったインパクト分析が容易に行えるのだ。停止する前の段階においてプロアクティブになるためには、まず事前に状況を正しく把握するために正確でわかりやすいデータを得る必要がある。そしてその状況データを元にしてプレディクティブに予見する、という行動パターンに結び付ける。HP Application Mapping softwareは、この過程をHP Software製品群の他のツールとともに支援している。 このような運用管理部門の前向きな取り組み姿勢は、ITサービス品質の向上を促すだけでなく、そこで生まれた実績を、開発部門や経営層に対し建設的な提言を行うための“具体的証拠”とすることも可能にするものだ。 そう、運用管理は変わる。根本から変えられる。そしてさらに、開発との関わりを深めることで、IT全体を変えていく可能性も秘めている。ITILが日本に深く根をおろしつつある今、その機は熟したといえるのである。
提供:日本ヒューレット・パッカード株式会社 企画:アイティメディア 営業局 制作:@IT編集部 掲載内容有効期限:2007年5月7日 |
|