Rate this page   Save this item Print this page Email this page

ITIL v2 のサービスサポートはどうなったの?

Vol.002 - 2008年10月21日(月2回発行)

前回は、「ITIL v2 と ITIL v3 はどう違う?」というテーマでお話しを進めました。ITIL Version 2(以下 ITIL v2)の7冊の書籍が、5冊にまとめなおされた、というお話でしたね。しかし実際は、このコラムを読んでくださっているみなさんがご存知の ITIL v2 といえば、「サービスサポート」と「サービスデリバリ」の2冊の書籍のことを指している、という認識でおられるのではないでしょうか。

その「サービスサポート」と「サービスデリバリ」で紹介され、活躍していたそれぞれのプロセスは、ITIL Version 3(以下 ITIL v3)ではどうなったのでしょうか。どの書籍に含まれたのか、どう変わったのか、それとも変わっていないのか、新しく追加された部分があるのかなど、気になるところです。そこでしばらくは、ITIL v2(特に「サービスサポート」と「サービスデリバリ」)で述べられていたプロセスが、ITIL v3 ではどうなったのか、ということに焦点をあててお話をすすめていきましょう。まずは今回と次回で、ITIL v2の各プロセスが、ITIL v3 の5冊の書籍の中の、何処に振り分けられたのか、ということを中心にお話しを進めます。今回はサービスサポートのお話しです。

まず ITIL v2 の復習をかねて、ITIL v2のサービスサポートに含まれていた1つの機能と5つのプロセスを確認しておきましょう(表1)
表1:サービスサポートの構成

要素 説明
機能 サービスデスク ユーザの問い合わせに対する単一の窓口機能
プロセス インシデント管理 インシデント(障害やサービス要求)に迅速に対応し、一刻も早く業務を通常の状態に戻すためのプロセス
問題管理 インシデントの根本原因を追究して恒久的な対策を講じ、インシデントの発生件数を減らすためのプロセス
構成管理 ハードウェアやソフトウェア、文書などのITインフラストラクチャの構成要素を適切に管理するプロセス
変更管理 IT環境の構成要素に対する変更を効率的に管理し、変更が原因のインシデントを未然に防ぐプロセス
リリース管理 変更管理で承認された変更作業を、本番環境に確実に実装するプロセス

これらの機能やプロセスは、ITIL v3では「サービストランジション」「サービスオペレーション」という分野に散らばりました。例えば(前回も書きましたが)唯一の機能であったサービスデスクは、ITIL v3の「サービスオペレーション」に含まれました。その考え方そのものは、ITIL v2のときとあまり変わっていません。しかし ITIL v3 になって少し増えた部分もあります。そんな変更部分に関しては、第4回目以降で詳しく説明をしていく予定です。

さて、プロセスに関してですが、

  • インシデント管理
  • 問題管理

の2つは、サービスデスクと同じく「サービスオペレーション」に含まれます。
さらに

  • 構成管理
  • 変更管理
  • リリース管理

は、「サービストランジション」に含まれることになりました。

分野が分かれただけではありません。いくつかの変更点が見られます。例えば ITIL v2 では、インシデントは障害とサービス要求が含まれていました。しかし ITIL v3 では、インシデントは「ITサービスに対する計画外の中断、または品質の低下」であると定義しなおされ、サービス要求とは別に扱うことになりました。また問題管理では、問題コントロールとエラーコントロールという分け方をやめました。調査の段階で根本原因がわかれば、いつでも既知のエラーとなりうるという柔軟な考え方に修正されたのです。さらに、「サービスオペレーション」での問題管理はリアクティブな問題管理のみを取り扱うことになりました。従来のプロアクティブな問題管理は、「継続的サービス改善」の分野での取り扱いになったのです。構成管理や変更管理、リリース管理なども同様に変化が見られます。これらも今後、プロセス毎に詳しく説明していく予定です。

ところで、「サービスサポート」という分野は ITIL v3 においてなぜそんなふうに分かれたのでしょうか。
そもそも「サービストランジション」や「サービスオペレーション」は、ITサービスマネジメントライフサイクルのどういった部分をポイントにまとめられた書籍なのでしょうか。

それを説明する前に、前回説明した ITIL V3 コア をもういちど復習しておきましょう(図1)。

図1:ITIL v3 構成図
ITIL v3 構成図

ITIL v3 では、ITサービスマネジメントをライフサイクルという観点で5冊の書籍にまとめなおしたもの、でしたね。それぞれの分野のおおざっぱな説明は前回のコラムを読んでいただくこととして、もっと乱暴にひとことでまとめてしまえば、

  • サービスストラテジ:事業ニーズに合ったITサービスを計画する
  • サービスデザイン:費用対効果の高いITサービスを設計する
  • サービストランジション:設計済みのITサービスを確実に導入する
  • サービスオペレーション:安定したITサービスを提供するための運用を行う
  • 継続的サービス改善:ライフサイクルの各段階の改善を図る

ということになるでしょう。

ITIL v2 の「サービスサポート」を色濃く受け継いでいるのは、この中の「サービストランジション」と「サービスオペレーション」だ、というわけです。これらをもう少し紐解いてみましょう。

まずは「サービストランジション」の主な目的から説明します。

「サービストランジション」の目的は、社内に新しいITサービスを導入するときや、既存のITサービスに何らかの変更(インフラストラクチャやアプリケーションの変更、運用の手順の変更など)が発生したときに、それらを本番環境へ導入するため能力を開発したり、能力を向上させたりすることです。

たとえば、店舗に新しいPOSレジを導入する際、置いておしまい、というわけにはいきません。置く場所はあるか、電源容量は足りているか、操作は今までと違うのか、取扱説明書はあるのか、などといった準備段階から、新しいPOSレジの動作テストはどのようにするのか、新しいPOSレジにいつ切り替えるのか、従業員の教育はいつどのような手順で行うのか、などといった導入段階まで、それらが滞りなく行われるような手引きや手順を提供しているのです。

次に「サービスオペレーション」の目的です。

「サービスオペレーション」の目的は、事業ユーザと顧客に合意済みレベルのサービスを提供することです。サービス品質を落とすもの、それはすなわちインシデントです。インシデントを取り除いたり、インシデントを未然に防いだりするためのものだ、と考えればわかりやすいでしょうか。ちなみに事業ユーザとはサービスの利用者のこと、顧客とはサービスにお金を払う人のことで、ITIL v2 のユーザと顧客にほぼ等しいと思ってさしつかえないでしょう。「サービスオペレーション」は、企業が事業活動を行う際に現場で実際に利用しているITサービスを管理したり、そのITサービスの管理に必要な活動やプロセスが滞りなく提供され続けることに重点を置いて編成されました。

このほかにもサービスオペレーションには、

  • 効果的かつ効率的なサービスの提供
  • 顧客およびサービス・プロバイダにとっての価値の保障
  • プロセスを効果的に計画および実施することで、日々のサービス運用を支援

といった役割も担っています。 

さて、ここでまとめておきましょう(図2)。

図2:ITIL v2 の「サービスサポート」と ITIL v3 との関係
ITIL v2 の「サービスサポート」と ITIL v3 との関係

ITIL v2のサービスサポートに含まれていた1つの機能と5つのプロセスがITIL v3では何処に含まれたのかを一覧にしたものです。 繰り返しになりますが、「サービストランジション」はサービスの新規追加、変更の内容が顧客要件と一致することを保証するための機能が集約され、「サービスオペレーション」は合意されたレベルのサービスを事業ユーザや顧客に提供し続けることを保証するための機能が集約されました。

その結果、従来の「サービスサポート」は図2のような分類に分けられたのです。

さてさて、話は少し変わりますが、ここでとても大事なことをひとつ申し上げておかなければなりません。それは、ITIL v3 は ITIL v2 ほど強いプロセス中心的な記述ではなくなった、ということです。

前回でも触れましたが、多くの人が ITIL v2 に対して

「ITIL v2 の構成要素は『サービスサポート』と『サービスデリバリ』である」

という誤った(しかし市場を席巻した)思い込みがあります。
そして

「『サービスサポート』は1つの機能と5つのプロセス、『サービスデリバリ』は5つのプロセスから構成されている」

というように見えます。

しかし、ITIL v2 がそのように見えるので(書籍にもそう書いてあるので)、ITIL v2 を導入しようとする企業には

「サービスサポート」と「サービスデリバリ」のプロセスさえ導入すれば、ITサービスマネジメントは成功する

と思っていたところも多かったようです。しかし実際に重要なのはプロセスを導入することではなく、ITIL の考え方を導入することなのです。考え方を具現化したものがプロセスです。考え方を導入せずにプロセスだけを導入するのでは、まさに「仏作って魂入れず」のような状態になってしまいます。

ITIL v3 ではこれを払拭するために、プロセス中心的なまとめ方ではなくなりました。

まずプロセスとは、

特定の達成目標を実現するために設計された、体系的な一連の活動

であると定義されています。プロセスそのものの詳しい説明はまた別の機会に譲るとして、ここで重要なのは、「プロセスには達成目標がある」ということです。プロセスは導入するために存在するのではありません。達成目標を実現するための手段なのです。

ITIL v3 はこの点が大変強調されています。もっとも重視すべきは、ITが提供するサービスが支援する事業目的、事業内容です。この部分は、次のようにまとめることができます。

  1. サービスは事業、および事業を遂行する顧客に価値を提供するものである。
  2. 価値とは、様々な資源を材料にして作り上げられる。
  3. プロセスは、価値を創造するために必要な資源のうちのひとつである。

ITIL書籍では「資源」という言葉が使われていますが、ここは「材料」と「道具」と考えたほうがわかりやすいでしょう。「材料」とはすなわち ITインフラストラクチャであり、「道具」は組織とかプロセスなどの、「材料」を価値に変換するために必要なものです。プロセスとは、サービスが事業に価値を提供するのに必要な「道具」の一種なのです。
ITIL v2 を勉強なさった方々には、ITILとはプロセスの集合体である、というように見せたほうがわかりやすいと思います。なのでこのコラムもはじめの数回は、ITIL v3 もまるでそのように構成されているように見せながら進めてまいります。
しかし ITIL v3 の本質は、プロセスではありません。サービスが事業にどのように価値を提供するか、そのためにはどうすればいいか、という概念そのものが重要なのです。連載を重ねるにつれて、だんだん ITIL v3 の本来の考え方にシフトしていく予定です。

さて今回は、ITIL v2 の「サービスサポート」が ITIL v3 ではどうなったのか、ということを中心にお話を進めてきました。次回は、ITIL v2 の「サービスデリバリ」が ITIL v3ではどのように変わったのか、ということについてお話を進めていく予定です。お楽しみに。