サービスレベルマネジメント

平成28年春季　問56．　サービスレベルマネジメント

問題文「ITサービスマネジメントにおけるサービスレベル管理の説明はどれか。」

解答群
ア．　あらかじめ定めた間隔で、サービス目標に照らしてサービスの傾向及びパフォーマンスを監視する。
イ．　計画が発動された場合の可用性の目標、平常業務の状態に復帰するための取り組みなどを含めた計画を作成し、導入し、維持する。
ウ．　サービスの品質を阻害する事象に対して、合意したサービス目標及び時間枠内に回復させる。
エ．　予算に照らして、費用を監視及び報告し、財務予測をレビューし、費用を管理する。

午後問題のカテゴリにもなっているので、重点的にITIL関連の問題を調査しているがかなり内容が多いので網羅するのは時間がかかってしまう。

まず、ITILのサービスマネジメント等で検索をかけてわかったことは、この分野は今とても業界で注目されている分野みたいでコンサルティング会社などが紹介記事を書いていることが多いみたいだ。

いくつか見た中で詳細は営業上の理由からか、はぐらかしているように思えるものの概要をつかめる読み物としては以下のサイトが良いように感じた。

まずニュートンコンサルティングさんの「用語集」、英国発と謳っているので、ITILのおひざ元とも言える会社さんである。

次に、FL.OPSさんの「クラウド関連ブログ」より「ITIL」。こちらは誤字が多くて閉口してしまうが、通して読むとかなり全体像がつかみやすくなっているように思える。

ここで、FL.OPSさんのサイトを通して読んでみて「ん？変だな？」と思ったのが、可用性管理などに関してはサービスデリバリという項目で述べられていて、インシデント管理とは別で扱われていることだった。

そこで、さらにサービスデリバリ、そしてサービスサポートを調べてみて、ようやく概要をつかめるに至った。

改めてびっくりさせられたのは、Wikipediaさんが一番まとまっていたということである。
「サービスデリバリ」と「サービスサポート」はそれぞれのリンクを見ていただくとわかると思う。

まとめると、サービスデリバリはおもに中長期的なITサービスの計画及び改善手法について述べられていて、サービスサポートはITサービス運営の日々の運用手法について述べられているということだ。それと、それぞれが赤本、青本と呼ばれているそうな。

サービスデリバリを構成するプロセスは5つで、「サービスデリバリプロセス群」と呼ばれ、それぞれサービスレベル管理、ITサービス財務管理、可用性管理、ITサービス継続性管理、そしてキャパシティ管理とに分類されている。中長期的な計画と改善手法という分類に当てはめて、改めて名前だけ見てみても意味するところが理解しやすい。

さらにサービスサポートは5つのプロセスと1つの機能で構成されていて、それぞれインシデント管理、問題管理、構成管理、変更管理、リリース管理、そして機能としてのサービスデスクとなる。これも日々のサポートの運営手法として考えると名前もかなりしっくりくる気がする。

一番混同して理解されてしまいそうなのは、サービスデリバリとサービスサポートを構成する要素、特に構成管理とサービスデリバリプロセス群がそれぞれ密接に結び付くだろうということで、考えれば当たり前なのだが日々の構成管理をしっかりしているからこそ可用性管理やITサービス継続性管理といった計画が立てられるというところだと思う。

実際にサービスサポートの中の機能であるサービスデスクとして今は日々働いているのだが、日々の生活の中で聞く用語がそれぞれ日々行っている作業の中で理解されているためにそれこそ「何が何だか意味が分からない」ように思っていたが、ITILが提唱していることはそれほど難しいことではなく、おそらくは

ビジネスを継続・発展させていくために存在するITサービスを中長期的及び短期的なタイムスパンでとらえた上で、それぞれのプロセスの中で行うべきこと、そしてそれぞれのプロセスがどのように関連付けられるべきかについて述べている

のだと理解した。

ここで、これほどクリアにまとめることのできる概念が色々な場面で難しく解説されているのは多分、コンサルティング会社が儲けるためという意味と、それ以上にこの概念を継続して実践することの難しさから来ているのだと考えた。

まず、おそらくはサービスデリバリとサービスサポートを実践していくうえで一番のカギを握っているのはサービスサポートのプロセスの内、構成管理だと思う。構成アイテム（Configuration Item）と呼ばれるIT資産には、おそらく多くの場合管理がしやすいサーバやネットワーク機器が一番登録されやすいと思われ、これに関するインシデント管理や変更管理は技術的な難易度はかなり高いもののITILの手法を取り入れた会社であればどこでも行えているのではないかと推測できる。

代わりに、構成要素の中で末端に位置するPCやプリンタ、それぞれに利用されているアプリケーションなどについては末端に行くほど管理はないがしろにされ、それが故に可用性管理やITサービス財務管理、キャパシティ管理を机上の空論にさせてしまうきらいがあるのではないだろうか。

では、それら一つ一つの構成要素（Configuration Item）を管理、つまり構成管理する主体はどこになるかというと、ITILで謳われているところのサービスデスクという機能、つまり人間が行うことになるわけだが、このサービスデスクという機能はSPOC（Single Point of Contact）と同時に呼ばれ、全ての問い合わせを一手に引き受けながらインシデント管理などの記録やハードウェア障害対応も同時に行うべき部署になっている。

つまり、サービスデスクという機能はITILが謳っているITサービスの根幹を担っており、全ての窓口でありITサービスの末端（一番数の多いPCなど）にあるCI（構成要素）の管理主体であるわけである。

まとめてしまうとかなり簡単に聞こえるこの仕事は、世の中のクラウド化が進むにつれてサーバやアプリケーションの管理は単価の安い海外に移行しているために英語などの共通言語でのやり取りができることが必須になり、さらに問い合わせの総合窓口であるがゆえにPCのハードウェアからOS、利用されている基幹システムを含めたアプリケーションで起こっているインシデントの問い合わせ先を即座に判断し、時に主体となってトラブルシューティングを行いながらインシデントの場合は解決に至った経緯をアナウンスしつつ、恒久的な解決策のための変更管理において時にはユーザとのコミュニケーション窓口となりながら、合間を縫って末端の機器のメンテナンスや交換対応に追われる日々を送らなければならなくなっている。

では、サービスデスクになんでもできるスーパーマンを雇うか？と言われると多くの企業は英語が喋れてちょっと技術力があるぐらいの使い捨て要員を雇っているのが現実で、かと言ってビジネスの要望に応えて行うアプリケーションの変更が多くまともに資料も作成せずにリリースしたら「後は窓口はサービスデスクで」と言ったおざなりな対応を行っているのが現実ではないだろうか。

ITILのサービスマネジメントを成功させるカギであり、土台となる構成管理とサービスデスクという部分に関して、ほとんどの場合クローズアップされることもなく日々が進んでいると思われるが、この点を解決するのは非常に難しいのではないかと推測する。

何故なら、上に述べたような毎日を永久に継続していけるような人間になれば、他でもっと良いお金を出してくれるところに行ってしまうからである。そして、それが人材の枯渇を生み出し、最終的に土台を支える人間をとっかえひっかえしながら日々の要請に応えるだけの毎日を繰り返す悪循環を迎えることになると思われる。

ここまで愚痴に近いことを述べてきて、じゃあどうやれば成功するのか？という点について末端で働くサービスデスクとして思うのは、「Knowledge base」の構築と維持、そして人の教育に尽きるのではないかということだ。

かつて武田信玄は「人は城、人は石垣、人は堀」と言っていると言われているが、まさに末端の兵隊であるサービスデスクを強力な兵隊に仕立て上げる（最初から雇うのはコスト的にまず無理である）ことにこそ、成功のカギがあるのではないかと偉そうに言ってみる。

ここで問題にさかのぼって改めて解答群を見つめてみると、解答は当たり前のようにア．であることがわかった。
この分野について初めての人は用語がいっぱいで分かりにくいと思うが、中長期的な計画と改善の手法が「サービスデリバリ」であり、日々のサービスの継続・維持が「サービスサポート」であることを念頭に置いて、再度それぞれのプロセスの用語を見つめ返してもらうとわかりやすいのではないかと思う。