現在地

第3回 サービスレベル管理とは?(前編)


サービスレベル管理とは?

前回のコラムでは、サービス提供品質の妥当性を証明するものとして「SLA」を紹介した。
今回は、「SLA」を検討・管理するプロセスとして、「サービスレベル管理(Service Level Management)」を中心に紹介する。

サービスレベル管理とは、ITサービスプロバイダー(*1)にとって重要なプロセスのひとつである。
前回同様、ITIL®のコア書籍(*2)「サービスデザイン」で「サービスレベル管理」の達成目標を調べてみると、以下のように記載されている(一部抜粋)。

サービスレベル管理の達成目標

  • 提供されるITサービスのレベルを定義、文書化、合意、モニタ、測定、報告、およびレビューして、必要な場合は常に是正対策を推進する。
  • 合意された目標値がすべて満たされた場合でも、提供されるサービスのレベルが、プロアクティブで費用対効果の高い継続的改善の対象となるようにする。

(Lou Hunnebeck.“サービス(service)”.ITIL®サービスデザイン(2011 edition)、TSO(The Stationery Office)、2012、p.106)

*1:顧客(orユーザー)にITサービスを提供する組織のこと。
*2:ITIL®は、「コア書籍」と呼ばれる5冊の書籍により、主に構成されている。

上記より、サービスレベル管理の達成目標のポイントは、2つある。
1つめのポイントは、合意だけではなく、モニタリングや報告も実施している点。
もう1つのポイントは、プロアクティブな対応が求められている点だ。

まず、1つめのポイントだが、サービスレベル管理は、顧客とSLAを交渉・合意して任務完了ではない。その後も継続的にモニタリングを行い、定期的に状況を顧客に報告する必要がある。
もちろん、報告内容は、けしてよいものばかりとは限らない。仮にSLAを遵守できていたとしても、モニタリングの結果、潜在的なトラブルが見つかるケースもある(下図のサービスレベル状況報告書を参照)。


20XX年度 第XX四半期 サービスレベル状況報告書
1. 目標と実績 3. 分析評価
  • 項目名:平均サーバー切替時間
  • 目標値:平均6分以内
  • 実績値:4分以内(計4件)
  • サービスレベル目標締結時に合意していない「高トラフィック時のシステムのリカバリー処理時間の増加」が判明した。
  • 40000TPS以上の高トラフィック時にサーバー故障が発生すると、ミドルウェアのリカバリー処理時間だけで30分を越える見込み。
2. 見込み状況 4. お願い事項
  • 見込み:達成見込み
  • 根 拠:切替は計4件発生
  • すべて目標水準をクリアしたため
  • 「今後の対応について」
    ミドルウェア設定について、チューニングおよびディスク等の増設の検討をお願いします。
  • 「次年度のサービスレベル目標について」
    切替時間の内、システムの処理時間を除いた切替時間として頂くようお願いします。

よい内容も悪い内容も定期的に顧客と情報共有することで、サービス品質の観点から事業要件と整合性を図っている。このように、サービスレベル管理は、サービスレベルに関するすべての課題について、顧客に対して一貫したインターフェースを提供している。もう1つのプロアクティブに関しては、次項で紹介する。

リアクティブとプロアクティブ

みなさんは、「プロアクティブ(proactive)」という言葉からどのようなものを思い浮かべるだろうか?ニキビのCMを思い浮かべる人もいるかもしれない。
英和辞書には様々な訳語が記載されているが、今回のコラムと一番リンクするものは、「事前対処」という言葉であろう。システム運用や保守の現場では、「予防保全」「予防保守」等の用語で利用されることが多い。なお、プロアクティブの対義語として「リアクティブ(reactive)」という言葉があるが、これは「事後対処」と訳される。(ということは、ニキビのCMでは、ニキビの「予防」を訴求しているのかもしれない)
プロアクティブとリアクティブについては、以下にHondaの事例を元に紹介する。

最近は、大半のクルマにカーナビゲーションシステムが装備されており、目的地へのルート案内だけでなく渋滞予測にも役立てられている。渋滞予測には、通常、高速道路や主要幹線道路を対象にしたVICS(*3)情報を利用することが多いが、今回紹介するHondaのインターナビ(*4)では、日本中のインターナビ装着車の走行データ(フローティングカーデータ)をセンタシステムに集約することで、よりキメの細かい渋滞状況を分析・提供している。まさにビックデータ分析の世界である。

*3:VICS(Vehicle Information and Communication System / 道路交通情報通信システム)
*4:インターナビ・フローティングカーシステム インターナビは本田技研工業株式会社の登録商標です
     <http://www.honda.co.jp/internavi/about/floating/>

また、フローティングカーデータ(急ブレーキ発生個所)を活用することで、渋滞予測だけではなく、交通事故の未然防止対策にも役立てている。

以下の写真を見比べて欲しい。左側が対策前、右側が対策後である。

急ブレーキ多発個所対策前:国道254号(和光市)

対策前後の違いがお分かりだろうか?
右側の写真では、街路樹の剪定が行われている。これまでは(左側の写真)、街路樹により側道との見通しが悪く、歩行者や自転車の飛び出しにドライバーがヒヤリとブレーキを踏む機会が多かったのだろう。幸い大きな事故には至っていなかったようだが、このまま放置しておくと事故に繋がる恐れがあるため、事前に街路樹の剪定を行った。これらの対処はプロアクティブな対応といえる。

一方、以下は新座市のケースである。同様に写真を見比べて欲しい。(正解は、本コラム最後にて)

急ブレーキ多発個所対策前:国道254号(和光市)

Honda ニュースリリース(2009年03月31日)

最近、通学路に自動車が衝突した等の忌まわしい事故のニュースを目にすることも多い。これらの事故が発生すると、警察や学校が現場検証を行い、ガードレールやカーブミラーの設置、通学時間帯の走行規制等の対策を検討・実施する。こちらのケースは、プロアクティブではなくリアクティブな対応(事後対処)といえるだろう。

他にも、火災発生時に消防署に連絡を受けて消火活動を行うものも、リアクティブな対応といえる。なお、消防署はプロアクティブな対応も実施しており、例えば、夜間に実施する見回り(火の用心)は、プロアクティブな対応である。プロアクティブとリアクティブは、どちらかに優劣をつけるものではなく、お互いに「バランス」が求めらる。もし、プロアクティブに重きをおくあまり、見回り(火の用心)に消防署員を動員し過ぎると、いざ119番に通報しても消防車を出動できないリスクが生じてしまうだろう。

プロアクティブな対応とリアクティブな対応は、それぞれのバランスが大事

さいごに

さて、1つめのポイント(モニタリングおよび報告)で紹介したサービスレベル状況報告書の図をもう一度見返して欲しい。
「4. お願い事項」にある「チューニングおよびディスクの増設」は、プロアクティブな対応である。まだ、インシデントが発生していないが、モニタリングした結果、その予兆が発見できたため、予防保守(プロアクティブ)の一環としての対応可否を顧客に打診している。プロアクティブな対応は投資的な側面もあるため、対策の実施にあたり、その根拠をステークホルダーに示す必要があるが、その際に、このようなモニタリング結果が有効だ。
(先ほどのインターナビの事例では、カーフローティングデータをモニタリング・分析した結果、急ブレーキを踏む箇所(危険であろう箇所)が特定できたため、プロアクティブな対応(樹木の剪定・道路標識の設置)を実施する上での根拠となりえた)
また、「4. お願い事項」には、予防保守(プロアクティブ)の打診とあわせて次年度のSLAの見直しを顧客と交渉している。SLAの交渉に関しては、第5回のコラムでも、ゲーミフィケーションのワークショップ内容と共に紹介する予定だ。

今回(前編)は、サービスレベル管理の概要について、いくつかの事例をまじえながらポイントを絞って紹介した。次回(後編)は、架空の小売店を題材にして、サービスレベル管理について引き続き紹介する。

クイズの答え

正解:「路面表示による速度抑制の注意喚起」
街路樹が落葉しているが、これは季節の違いによるもの。剪定したわけではないようだ。