サービスマネジメントプラクティス② サービスデスク・SLM・展開

ITIL 4は34のマネジメントプラクティスを定義するが、ファンデーション試験の公式シラバスはその扱いを二層に分けている。継続的改善、変更実現、インシデント管理、問題管理、サービス要求管理、サービスデスク、サービスレベル管理の7プラクティスは目的・用語・活動まで詳細に問われ(シラバス学習成果6)、リリース管理、展開管理、サービス構成管理、IT資産管理、モニタリングおよびイベント管理、関係管理、サプライヤ管理、情報セキュリティ管理の8プラクティスは「目的の想起」のみが問われる(学習成果7)。本章で扱うサービスデスクとサービスレベル管理(SLM)は前者に、展開管理とリリース管理は後者に属する。試験はCBT四肢択一40問・26問(65%)以上で合格であり、各プラクティスの「目的」の定型文を選ばせる問題が毎回複数出題されるため、公式書(ITIL Foundation: ITIL 4 Edition)の原文に近い形で目的文を押さえることが得点に直結する。

サービスデスクの目的は「インシデントの解決およびサービス要求に関する需要を捕捉すること」であり、あわせて「サービスプロバイダとそのすべてのユーザーにとっての入口(エントリポイント)および単一の窓口(シングル・ポイント・オブ・コンタクト、SPOC)となるべき」とされる。試験では、サービスデスクが日常的に向き合う相手は「ユーザー」であり、SLMが主に向き合う「顧客」と区別される点がひっかけとして問われる。また、サービスデスクの本質は技術的解決そのものではなく、需要の受付・分類・自己解決の支援・適切なチームへのエスカレーションであり、インシデント管理やサービス要求管理のプラクティスと密接に連携して機能するという位置づけの理解も頻出論点である。

サービスデスク要員に求められる中核スキルとして、公式書は共感(empathy)、感情的知性(emotional intelligence)、優れたコミュニケーション能力、インシデントの分析と優先度付けなどを挙げ、「技術的な問題よりも、人とビジネスに焦点を当てるべき」と明記している。したがって「高度な技術力が最も重要」とする選択肢は誤りである。アクセスチャネルは電話に限らず、サービスポータル、モバイルアプリ、チャット(チャットボットを含む)、電子メール、ウォークイン(対面)、SNS、公開のディスカッションフォーラムなど多様化している。さらに自動化・AIの活用により定型的な要求は人手を介さず処理され、サービスデスクは複雑・例外的な事案への対応に集中できるようになる、という近代化の文脈もITIL 4らしい出題ポイントである。

サービスレベル管理(SLM)の目的は「サービスレベルについてビジネスに基づく明確な目標を設定し、これらの目標に照らしてサービスの提供が適切に評価され、モニタされ、管理されることを確実にすること」である。中核用語のサービスレベルアグリーメント(SLA)は「サービスプロバイダと顧客との間の文書化された合意であり、要求されるサービスと期待されるサービスレベルの両方を特定するもの」と定義される(公式用語集)。SLMはSLAを締結して終わりではなく、サービスレビューの実施、サービス実績の評価とレポート、顧客からのフィードバック収集までを含む継続的な活動であり、関係管理やサプライヤ管理のプラクティスと連携して機能する点も併せて押さえたい。

公式書はSLAを成功させるための要件として、(1)定義された「サービス」に関連付けられていること、(2)単なる運用メトリクスの束ではなく、定義された「アウトカム(成果)」に関連付けられていること、(3)サービスプロバイダと顧客の間の「合意」を反映していること、(4)平易に書かれ、関係者全員にとって理解しやすいこと、を挙げる。個々の運用メトリクス(稼働率・応答時間など)はすべて目標を達成し報告上は「緑」なのに、顧客の実際の体験や満足度は「赤」である状態を「スイカSLA(watermelon SLA)効果」と呼び、アウトカムを軽視したSLAの典型的失敗として出題される。SLMの情報源は、顧客エンゲージメント(傾聴・ヒアリング)と顧客フィードバック(調査・ビジネス関連指標)の両輪である。

展開管理の目的は「新規のまたは変更されたハードウェア、ソフトウェア、ドキュメンテーション、プロセス、その他あらゆるコンポーネントを稼働環境(本番環境)に移行すること」である。テスト環境やステージング環境など他の環境へのコンポーネントの移行に関与する場合もある。公式書が挙げる代表的アプローチは、(1)フェーズ(段階的)展開:ユーザー群や地域ごとに順次展開する、(2)継続的デリバリー:コンポーネントを頻繁に統合し必要な時に展開する、(3)ビッグバン展開:全ターゲットへ一斉に展開する、(4)プル展開:利用者が必要な時に自らダウンロードして導入する、の4つであり、アプローチの名称と特徴の対応付けが問われる。

リリース管理の目的は「新規のおよび変更されたサービスとフィーチャーを利用可能にすること」である。展開管理が「本番環境へ技術的に移すこと」であるのに対し、リリース管理は「ユーザーが使える状態にすること」であり、両者の目的文を入れ替えたひっかけが本章で最も頻出する。従来型(ウォーターフォール)の環境では展開とリリースは通常同時に行われるが、DevOps・継続的デリバリーの環境では、コンポーネントを本番環境に展開した後、フィーチャーフラグ(機能の有効化スイッチ)やブルー/グリーン・リリースなどの技法によって、リリースのタイミングを展開と切り離して制御できる。「展開された=直ちに利用可能」とは限らないという理解が問われる。