本記事では、ITIL 4の「バリューストリーム」という考え方を軸に、ユーザーサポート業務のサービスデスクや問題管理、ナレッジ管理、サービスレベル管理といった主要プラクティスがどのように連携してユーザーに価値を届けるのかを書いてみます。
バリューストリームとは何か
バリューストリームとは、ユーザーの需要やニーズを認識して価値を届けるまでの一連のステップのことです。
一つの組織には複数のバリューストリームが存在します。ユーザーサポート業務だけを見ても、「インシデント解決」と「サービスリクエスト対応」では、関わるプラクティスの比重や活動の流れが異なります。それぞれのシナリオに合わせてバリューストリームを設計することが必要です。
ユーザーサポートを支える主要プラクティス
バリューストリームの具体的な流れに入る前に、ユーザーサポート業務で中心的な役割を果たすプラクティスを確認します。
サービスデスク
ユーザーとIT組織の間の主要な接点として機能します。問い合わせの受付、初期対応などユーザーサポートの最前線を担います。ITIL 4では、サービスデスクは単なる「受付窓口」ではなく、需要の入り口としてユーザーとの関係性を構築し、価値を共創するための重要なエンゲージメントポイントと位置づけられています。
サービスカタログ管理
組織が提供するITサービスの一覧とその詳細情報を整備・維持するプラクティスです。ユーザーが「どのサービスを利用できるのか」「どこに問い合わせればよいのか」を明確にすることで、サポート業務の入口を整理し、ユーザーの自己解決やスムーズな問い合わせにつなげます。
サービスレベル管理
ITサービスの品質目標を定義し、合意し、その達成状況を測定・管理するプラクティスです。サービスプロバイダとユーザー（または顧客）の間でSLA（Service Level Agreement：サービスレベル合意書）を締結し、対応時間や解決時間、可用性などの具体的な目標値を設定します。SLAはバリューストリーム全体を貫く「品質の物差し」として機能し、各ステップで適切な優先度判断やリソース配分の基準を提供します。
インシデント管理
サービスの計画外の中断や品質低下に対して、できるだけ早く通常のサービス運用を回復させることを目的としたプラクティスです。
サービスリクエスト管理
ユーザーからの定型的な依頼に対応するプラクティスです。パスワードリセット、新規アカウントの作成、ソフトウェアのインストール申請、情報の問い合わせなど、サービスの障害ではなく「あらかじめ定義されたサービスの提供」を求めるリクエストが対象となります。
問題管理
インシデントの根本原因を特定し、再発を防止することを目的とします。問題管理は「インシデントが起こらないような環境を作る」活動です。繰り返し発生するインシデントのパターンを分析し、根本的な解決策や回避策を導き出します。
ナレッジ管理
組織内の知識や情報を体系的に収集・整理・共有・活用するプラクティスです。過去の対応事例や既知のエラーとその回避策をナレッジベースとして蓄積することで、サービスデスクの対応速度が向上するだけでなく、ユーザー自身によるセルフサービスでの解決も可能になります。
モニタリングおよびイベント管理
ITインフラやサービスの状態を継続的に監視し、異常（イベント）を検知・分類・対応するプラクティスです。ユーザーが障害に気づく前にシステム側で異常を検知し、予防的な対応を可能にすることで、インシデントの発生を抑制する役割を担います。
バリューストリーム①：インシデント解決
まずは、ユーザーサポートの代表的なシナリオである「インシデント解決」のバリューストリームを見ていきます。
[需要の発生] → [エンゲージ] → [提供およびサポート] → [価値の実現] → [改善]
Step 1：需要の発生
この起点には二つのパターンがあります。
- ユーザー起点：ユーザー自身がシステム障害に気づき、サービスデスクに問い合わせるケース。ユーザーはサービスカタログを参照して適切な問い合わせ先を特定し、連絡します。
- システム起点：モニタリングおよびイベント管理による検知。監視ツールがサーバーの異常やネットワークの遅延といったイベントを検知し、自動的にアラートを発行します。ユーザーが影響を感じる前にIT側が問題を把握できるため、予防的な対応が可能になります。
Step 2：エンゲージ
サービスデスクが対応の中心を担います。ユーザーからの問い合わせであれば、状況のヒアリング、影響範囲や緊急度の確認を行います。モニタリングからのアラートであれば、影響を受けるユーザーの特定と事前通知を行います。
ここで「サービスレベル管理」が重要な役割を果たします。SLAに定められた優先度分類の基準に基づいて、インシデントの優先度を判断します。たとえば「基幹業務システムの全面停止は最優先、個人端末の軽微な不具合は通常対応」といった判断がSLAによって明確になるため、サービスデスクの担当者は迷うことなく適切な対応レベルを選択できます。
また、「ナレッジ管理」もこの段階で活躍します。過去に同様の事象がなかったかをナレッジベースで検索し、既知の回避策があれば迅速に案内できます。
Step 3：提供およびサポート
「インシデント管理」が中心となり、実際の復旧活動を行います。サービスデスクでの一次対応で解決できない場合は、専門チームが対応します。
この段階でもSLAが活きてきます。SLAで定めた目標解決時間を意識しながら対応を進めることで、チーム全体が同じ時間軸で動けるようになります。目標時間に近づいてもなお解決の目処が立たない場合は、上位へのエスカレーションを判断するトリガーにもなります。
Step 4：価値の実現
障害が解消され、ユーザーが再び業務に集中できるようになった瞬間、このバリューストリームの「価値」が生まれます。
ここで大切なのは、単にシステムが技術的に復旧したことではなく、ユーザーの生産性が戻ることに価値があるという視点です。
サービスデスクからユーザーへの完了報告と満足度確認も重要なステップです。
Step 5：改善
解決に至るまでの過程を振り返り、改善活動につなげます。
- 問題管理：同じインシデントが繰り返し発生していないか、パターンを分析し、根本原因を特定。恒久的な対策を講じることで再発を防止します。
- ナレッジ管理：対応の中で得られた新しい知見や解決手順をナレッジベースに追加し、次回以降の対応品質向上に役立てます。
- モニタリングおよびイベント管理：監視項目やしきい値を見直し、より早い段階での異常検知を目指します。
- サービスレベル管理：SLAの達成状況を定期的にレビューします。目標解決時間を満たせたか、ユーザーの期待と合意した水準にギャップはないかを確認し、必要に応じてSLA自体の見直しも行います。SLAの達成率が低下している領域は、バリューストリームのどこかにボトルネックがある可能性を示すシグナルとなります。
プラクティス同士の連携が価値を最大化する
ここまでの流れを振り返ると、バリューストリームの中で複数のプラクティスが密接に連携していることがわかります。
| プラクティス | 役割 |
|---|---|
| モニタリングおよびイベント管理 | インシデントの早期発見 |
| サービスデスク | ユーザーとの接点の一元管理 |
| サービスカタログ管理 | ユーザーの適切なアクセスの支援 |
| サービスレベル管理 | 品質基準と時間目標の提供 |
| インシデント管理 | 迅速なサービス復旧の実行 |
| サービスリクエスト管理 | 定型的な依頼の効率的な処理 |
| ナレッジ管理 | 対応スピードと品質の底上げ |
| 問題管理 | 再発防止による将来のインシデント削減 |
これらが個別に機能するのではなく、バリューストリームという流れの中で有機的につながることで、ユーザーに届く価値が最大化されるのです。
なぜバリューストリームの視点が大切なのか
バリューストリームの視点を取り入れると、すべての活動が「ユーザーへの価値提供」につながっているかを意識できるようになります。サービスデスクの担当者が、自分の業務がバリューストリームのどこに位置し、SLAという約束の中でどのような価値につながるのかを理解することで、対応の質は大きく変わると思います。
バリューストリームとプラクティスのつながりが見えてくると、どこにボトルネックがあるのか、どこを改善すればユーザーへの価値が高まるのかが見えてきそうだと思いました。
※ ITIL® はPeopleCert Group Limited の登録商標です。
※ 本記事はITIL 4の学習内容をもとに筆者の理解と解釈をまとめたものであり、公式見解を代表するものではありません。