本記事では、サービスマネジメント活動を管理する「サービスマネジメントシステム」と、その中で登場するさまざまな管理プロセスについて解説します。インシデント管理や変更管理など、似たような用語が多く登場しますが、グループごとに整理しながら説明しますので、全体の関係をイメージしながら学んでいきましょう。
1. サービスマネジメントシステムの全体像
この章では、「サービスマネジメントシステムとは何か」という大枠と、サービスに対してどのような要求事項が決められるのかを確認します。サービスレベルやサービスカタログ、報告といった言葉も、ここでまとめて押さえておきます。
サービスマネジメントシステム
サービスマネジメントシステムとは、組織がサービスマネジメント活動を計画・実行・監視・改善するための仕組み全体を指します。組織の方針、ルール、手順書、担当者の役割分担、必要なツールや記録などをまとめて管理し、安定したサービス提供を支える枠組みです。
このシステムがしっかり整っていると、担当者が変わってもサービスの品質を維持しやすくなり、トラブル発生時も決められた手順で落ち着いて対応できるようになります。
サービスの要求事項
サービスの要求事項とは、顧客がサービスに対して求める内容を整理したものです。たとえば、「平日の日中に安定して利用できること」「一定時間内に処理が完了すること」「問い合わせ窓口があること」などが要求事項の例です。
サービスマネジメントシステムでは、まずこの要求事項を正しく把握し、それを満たすために必要なサービス内容や運用方法を設計していきます。要求事項があやふやなままだと、あとで「思っていた内容と違う」という不満につながるため、最初にきちんと整理することが重要です。
サービスレベル管理（SLM）
サービスレベル管理（SLM：Service Level Management）は、サービスの品質レベルを決め、そのレベルを維持・改善していくための管理プロセスです。SLA（サービスレベル合意書）を作成・見直ししながら、どの程度の稼働率や応答時間を目標とするのかを合意し、その達成状況を監視します。
サービスレベル管理によって、サービスの品質が「なんとなく」ではなく、数値や指標に基づいて管理されるようになります。これにより、顧客との間で品質に関する認識のズレを減らすことができます。
サービスカタログ
サービスカタログとは、組織が提供しているサービスの一覧と、その概要を分かりやすく整理した文書やデータベースのことです。どのようなサービスが利用できるのか、利用条件や申込方法、サポート窓口などがまとめて記載されます。
サービスカタログがあることで、利用者は自分が使えるサービスを一目で確認でき、IT部門側もサービスの範囲を明確に示すことができます。新しいサービスを追加したり、古いサービスを廃止したりする際も、このカタログを更新していきます。
サービスの報告
サービスの報告とは、サービスの稼働状況や障害発生状況、サービスレベルの達成度などを、定期的な報告書としてまとめる活動です。報告先は、社内の管理者や顧客担当者などが想定されます。
この報告によって、「サービスがどれくらい安定して提供されているのか」「合意したサービスレベルが守られているのか」を客観的に把握できます。問題があれば、報告結果をもとに改善策を検討するきっかけにもなります。
2. サービス提供前後の計画・構成・変更の管理
この章では、サービスの需要を予測し、必要な資源を用意し、構成や変更を管理しながら、本番環境に展開していくまでのプロセスを整理します。サービスの移行や受入れ基準も、この流れの中で登場します。
需要管理
需要管理は、サービスがどのくらい利用されるかを予測し、その需要に応じて資源を準備する活動です。たとえば、アクセスが集中する時間帯や時期を予測して、サーバの性能や回線容量、人員配置を調整します。
需要を適切に見積もれないと、サービスが混み合って応答が遅くなったり、逆に過剰な設備を用意してムダなコストがかかったりします。需要管理は、サービスの品質とコストのバランスを取るうえで重要な役割を果たします。
サービス要求管理
サービス要求管理は、ユーザーからの「サービスに関する正式な依頼」を受け付け、評価し、対応するプロセスです。たとえば、新しいアカウントの発行依頼や、オプション機能の追加申請などがサービス要求の例です。
この管理を通じて、どの要求をどの順番で処理するのか、どの部署が対応するのかを明確にし、抜け漏れなく、合理的に対応できるようにします。サービスカタログにある内容と結びつけて運用されることが多いです。
構成管理
構成管理は、サービスを構成している機器・ソフトウェア・設定情報などを、ひとまとまりの「構成アイテム」として管理するプロセスです。サーバ名、IPアドレス、ソフトウェアのバージョン、接続関係などを記録し、いつでも把握できるようにします。
構成情報が整理されていると、障害発生時に原因調査をしやすくなり、変更作業の影響範囲も見積もりやすくなります。逆に構成がわからない状態だと、ちょっとした変更が思わぬ障害を招くことがあります。
変更管理
変更管理は、システムやサービスに対する変更を、計画的かつ安全に実施するためのプロセスです。変更の内容・理由・影響範囲・実施日時・実施手順・戻し手順（元に戻す方法）などを事前に検討し、必要に応じて承認を得てから実施します。
この管理により、「誰かが勝手に設定を変えてサービスが止まってしまった」といった事態を防ぐことができます。リスクが高い変更は、通常より慎重なレビューやテストを行うなど、優先度や重要度に応じた扱いをします。
リリース及び展開管理
リリース及び展開管理は、テストが完了した新機能や修正を、本番環境にまとめて導入するプロセスです。「どのバージョンを、いつ、どの手順で展開するか」を計画し、必要なバックアップや利用者への告知を行ったうえでリリースします。
このプロセスが整っていると、新バージョンの導入でサービスが大きく乱れるリスクを減らすことができます。また、問題が発生した際に、素早く前の状態に戻せるよう準備しておくことも重要です。
サービスの移行
サービスの移行は、新しいサービスやシステムを導入するときに、旧環境から新環境への切り替えを行う活動です。たとえば、旧サーバから新サーバへのデータ移行や、新しいクラウドサービスへの乗り換えなどが該当します。
移行では、データの整合性や業務への影響を最小限に抑えるための計画が欠かせません。テスト移行や段階的な切り替えを行うなど、利用者にとってできるだけスムーズな移行になるよう工夫します。
サービス受入れ基準
サービス受入れ基準は、「この条件を満たしたら、本番サービスとして受け入れてよい」と判断するための基準です。たとえば、テストで重大な不具合が残っていないこと、必要なマニュアルや教育が完了していること、バックアップや監視の仕組みが整っていることなどが含まれます。
明確な受入れ基準を定めることで、準備が不十分なままサービスを開始してしまうリスクを減らすことができます。また、開発側と運用側の間で「どこまで整っていればリリース可能か」を共有できる点も重要です。
3. 日々の運用・トラブル対応と継続性の確保
この章では、サービス運用中に発生するインシデントや問題への対応、エスカレーション、そしてサービスの可用性・継続性を守るための管理について説明します。日々の安定運用に直結する内容です。
インシデント管理
インシデント管理は、サービス利用中に発生した障害や問い合わせなどの「インシデント」に対応し、できるだけ早く通常状態に戻すためのプロセスです。ここでの目的は、原因を深く追及することではなく、まず利用者にとっての影響を最小限に抑えることです。
たとえば、「システムにログインできない」「画面が固まってしまった」といった事象がインシデントにあたります。インシデント管理では、受付、分類、優先度付け、対応、記録、クローズといった流れで処理を進めていきます。
問題管理
問題管理は、インシデントの根本原因を特定し、再発を防ぐための対策を検討・実施するプロセスです。インシデントが繰り返し発生している場合や、重大な障害につながりそうな要因が見つかった場合に、原因調査や恒久対策を行います。
インシデント管理が「早く復旧すること」を重視するのに対し、問題管理は「同じことが起きないようにすること」を重視します。両者は連携して運用され、サービスの安定性向上に貢献します。
エスカレーション
エスカレーションとは、対応が難しいインシデントや問題について、より上位の担当者や専門部署に引き継いで対応を依頼する仕組みです。対応時間が長引きそうな場合や、影響範囲が大きい場合に、あらかじめ決められたルールに従ってエスカレーションを行います。
これにより、現場担当者だけで抱え込まず、必要な権限や知識を持つメンバーが適切なタイミングで対応に参加できるようになります。サービスマネジメントシステムでは、このエスカレーションルートを事前に決めておくことが重要です。
サービス可用性管理
サービス可用性管理は、サービスが「必要なときに利用できる状態」であることを目標に、可用性（利用可能時間）を計画・監視・改善するプロセスです。稼働率の目標設定や、冗長構成の設計、監視の仕組みづくりなどが含まれます。
可用性管理では、SLAやSLOで定めた稼働率を達成するために、どの部分が弱点になっているかを分析し、対策を講じていきます。これにより、サービスの「止まりにくさ」を継続的に高めることができます。
サービス継続管理
サービス継続管理は、大きな災害や重大障害などが発生した場合でも、重要なサービスを継続したり、できるだけ早く復旧させたりするための仕組みを準備するプロセスです。バックアップサイトの準備や、災害時の対応手順書、非常時の連絡体制などを整備します。
この管理が不十分だと、万一のトラブルでサービスが長期間停止し、事業に大きな影響が出るおそれがあります。平常時から継続計画を立て、定期的に訓練や見直しを行うことが重要です。
4. 継続的改善とPDCAサイクル
この章では、サービスマネジメントシステム全体をより良くしていくための「継続的改善」と、その基本となるPDCAサイクルについて説明します。
継続的改善
継続的改善とは、サービスマネジメント活動の結果を定期的に振り返り、問題点を見つけて少しずつ良くしていく取り組みのことです。インシデントの件数や復旧時間、サービスレベルの達成状況、利用者からのフィードバックなどをもとに、改善案を検討して実行していきます。
一度仕組みを作って終わりではなく、実際に運用した結果を踏まえて見直し続けることで、サービスの品質や効率を段階的に高めていくことができます。
PDCA
PDCAは、Plan（計画）、Do（実行）、Check（評価）、Act（改善）の頭文字を取った、継続的改善の基本サイクルです。
- Plan：目標を定め、具体的な計画を立てる
- Do：計画に沿って実行する
- Check：結果を測定し、目標とのギャップを確認する
- Act：問題点を分析し、次の改善策を決める
サービスマネジメントシステムでは、このPDCAサイクルを回し続けることで、サービスレベルの向上や業務の効率化を図ります。PDCAはITに限らずさまざまな分野で用いられる改善手法ですが、サービスマネジメントの世界でも重要な考え方となっています。
まとめ
サービスマネジメントシステムは、サービスマネジメント活動を組織的に管理するための仕組み全体を指し、その中には多くの管理プロセスが含まれています。サービスの要求事項やサービスレベル管理、サービスカタログや報告といった仕組みにより、「どんなサービスを、どのレベルで提供するのか」を明確にし、関係者の認識をそろえることができます。
一方で、需要管理やサービス要求管理、構成管理、変更管理、リリース及び展開管理、サービスの移行、サービス受入れ基準などは、サービス開始前後の準備や変更を安全に進めるためのプロセスです。これらが適切に機能することで、サービスは計画的かつ安定的に利用者へ届けられます。また、インシデント管理・問題管理・エスカレーション、サービス可用性管理・サービス継続管理といった運用プロセスが、日々のトラブル対応やサービス継続性を支えています。
そして、それらすべてをより良くしていくために、継続的改善とPDCAサイクルが用いられます。サービスマネジメントシステムは、多数の用語やプロセスから成り立っていますが、「安定した価値あるサービスを提供し続けるための仕組み」という一本の軸でつながっています。この軸を意識しながら用語同士の関係を整理しておくと、学習内容がぐっと理解しやすくなるはずです。
コメント