 |
≫ |
|
|
|
|
|
|
|
|
|
|
|
|
------（eNewsletter編集部）「ITIL」の適用に関して、日本の現状をどう捉えていますか？
久納 ITILへの理解が深まり導入する企業が増えていますが、今はまだ全体的に見ると、まだまだITILが正しく理解されていないと感じますね。ITILはベストプラクティスを集めた「理論本」だということは、すでに多くの方々が認識されているようですが、そこにあるプロセスを「その通りにやらなければいけないもの」と、まるでバイブルのように受け止められている部分も多くあると感じます。
また、そこのベストプラクティスと自社の実際の業務プロセスの“ギャップ”を見るために、アセスメントツールなどもあるわけですが、まず最初にギャップ分析をおこない、プロセス設計全体に渡って構築するところから、ITILをスタートしなければならないなどと思われていて、そこからアプローチしてしまっている風潮があるように感じますね。
松木 ITILは、決して現在動いているITシステムを否定したり、すべてを新たに構築することを目的とするものではないわけです。必要なのは、現状否定ではなく、今できていることを理想形に近づけていく、という考え方なのだと思います。まずは現状を把握し、理想的状態とのギャップを確認しながらPDCA（plan, do, check, act）を行い、徐々に仕組みそのものを改善していく、そのような段階的なステップを踏んでいくのがベターなのですが（図01）、そこが正しく理解されていないのではないかと感じますね。
上野 ITILに記載されている内容に対する解釈もいろいろブレがあると思います。たとえばITILを解説したものの中にはSLA（Service Level Agreement）というのは“契約”だと間違って定義している場合もある。原本が英語なので、言葉の定義で解釈が異なるのはいたしかたない部分もありますが、本来の意味は“合意”です。
ビジネス側とIT側で「こうしましょう」という約束ごとみたいなものなのですが、それを「契約」と言うと、今度は「賠償金」などといった考え方も生じ、これでは「改善する」という視点とは離れてしまうし、松木が言ったPDCAの実践にはつながっていかない。このような間違った解釈も、日本のIT運用でのITIL化を妨げるバリアーの一つになっているのではと感じています。
久納 ITILの中にはSLAは「ビジネス側とIT側が合意する文章だ」と明記されていて、SLAを作る本来の目的は「ビジネス側とIT側の両者の真のパートナーシップを育成すること」であり、「ビジネスとITのwin-winの関係を構築しよう」というものです。
ところが現実には、ユーザ企業のIT部門とITベンダ企業間のIT担当者同士でSLAを作成してしまうケースが多く、ビジネス側とIT側が同じテーブルでビジネス要件と提供するITのサービスについて話し合い、“合意”を得ている場合は少ない。IT側の人同士で話をするとITのスペック的な数値目標ばかりが注目され、ビジネスの本質とはかけ離れたところでの“スペック契約”をすることにもなりかねません。これはITILがいうところのSLAとは全くかけ離れたものなのです。
|
 |
|
------（編集部）「ITIL」の本質が理解されていないということですか。
久納 そうですね。ITILが目指すところは、真のパートナーシップをビジネス側とIT側との間で築いて、その良好な関係をベースに、ITの効率化を目指し、ITを活用してビジネスを伸張させようという考え方なのです。ITILはそのための指針であり、ITのスペック的なことに関する「契約」ではないし、また、「こうしなければいけない」とは一切書かれていません。
上野 ITILは「こうした方がいいですよ」と言っているだけなんですよね。ITを運用する中で、毎回、ビジネス側とIT側がそれをレビューして、「何が悪かったのかを検証して、それを改善していく」のがITILということです。
久納 書かれているのは「ビジネスニーズに合わせて、自分で判断しなさい」ということですよね。ただし、そのためにはSLAがとても大切になってくる。なぜなら正しいビジネス要件が何かを、ビジネス側と話し合って明確にしておかないと、実際に改善していこうとしても、それがビジネスとして適切かどうか判断のしようがない。ビジネス要件に基づいてSLAを作成し、それを軸に「ITILのベストプラクティスがこうだから、自分のところはこうしてみよう」というように、柔軟性のあるやり方でいいと思います。
上野 ITに携わる側は非常に多くの情報を集めて、それを細かく分析したがるものですが、ビジネス側にとってはそうしたことはあまり必要としていなくて、限られた時間できちんと有効なものを提供してくれればいいと考えます。そこにそんなに時間をかけても意味がない、と。その辺で両者に大きなギャップが生じているんですね。
このようにビジネス側とIT側でギャップが生じたまま、ITILを進めると、たとえある程度の人員を割いて作業させ、完璧なシステムができたとしても、それがどれだけビジネスに貢献できるのかわからないという事態になってしまうわけです。
松木 IT側の人間が「なぜITILを導入するのか」を、まずよく考える必要がありますよね。ITILの本質はビジネス要件を実現するための改善手段なのですから、ITILはそのための道具や手段にすぎないわけで、集団無責任的に「導入のための導入」になっていないか、よく議論する必要性があると思います。その意味でも、まず「ITIL」を適用する前に、その必要性について自らに疑問を投げかけてみることがとても重要だと思います。
久納 IT管理者の間では「100％近いアべイラビリティ（可用性）を達成するには」という議論がよくされますが、私の経験では、そのような数値目標を達成したとしても、レビューミーティングをした時に、ビジネス側の人は必ずしも喜んでいないケースが多いのです。
たとえば、ある月にシステムに障害があって５千万円の損失があった場合、翌月からその損失を起こさないためにどうしていこうかという議論がされます。その時に１億円かけてシステムを改修し、さらにアべイラビリティを上げるか、あるいはビジネス側が自分たちの責任でリスクをとり、マニュアル作業による回避策を整え、システムへの１億円の投資を止めるのかによって、サービスレベルは決まりますから、数値目標にそれほどこだわる必要がないことに気づく。
ITILは「ITはビジネスそのものである」という考え方に基づくもので、ITILを考える時にビジネスの視点は不可欠なわけですから、ビジネスを抜きに、ITのシステムやスペックだけで考えることは全く意味がないわけです。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
印刷用画面へ
