サービスマネジメント 重点教科書

みなさんが普段使っているスマホのアプリや会社の業務システムは、作って終わりではありません。「今日もちゃんと動くか」「困ったときにすぐ助けてもらえるか」「使いにくいところは改善されていくか」——こうした一つひとつの積み重ねがあって、はじめて安心して使い続けられます。この「作ったあとも、利用者にとって価値のあるものであり続けるように面倒を見続ける活動」全体を指す言葉がサービスマネジメントです。

サービスマネジメントとは何か

ここでいうサービスとは、情報システムそのものというより「情報システムを使うことで利用者が得られる価値」だとイメージすると分かりやすいです。たとえば銀行のATMというシステム自体ではなく、「いつでもお金を引き出せる」という価値のほうがサービスです。この価値を利用者にきちんと届けるために、組織が持っている人・モノ・お金・情報といった資源を上手に指揮し、管理していく一連の能力とプロセスの集まりが、サービスマネジメントという考え方の正体です。技術者が個人の頑張りでシステムを支えるのではなく、組織として仕組み化して継続的に価値を提供し続けようとする点がポイントです。

価値を生み出す5つのステップ

サービスは思いつきで運用されるものではなく、価値を生み出すために順序立てて扱われます。具体的には、どんなサービスを提供するかを考える計画立案、その中身を具体的に決める設計、実際の運用環境へ切り替える移行、日々利用者に届ける提供、そして提供しながら見えてきた課題をより良くしていく改善という流れです。この「計画→設計→移行→提供→改善」という一連の活動を指揮し管理することこそが、サービスマネジメントの中身だと理解しておきましょう。ここで大切なのは、改善は一度きりで終わらず、提供と改善を行ったり来たりしながらサービスの質を高め続けていくという点です。

世界標準のやり方集「ITIL」

サービスマネジメントを「どうやって実践すればよいか」を一から自分で考えるのは大変です。そこで、世界中の企業が長年の経験から積み上げてきたベストプラクティス（優れたやり方の集まり）をまとめた枠組みがITIL（Information Technology Infrastructure Library）です。ITILはサービスマネジメントのための代表的なフレームワークとして広く使われており、これから紹介するインシデント管理や変更管理といった個々のプロセスの多くも、もとをたどるとITILの考え方に基づいています。試験では「ITIL＝サービスマネジメントのフレームワークの名前」という結びつきをまず覚えておけば十分です。

品質の約束を交わす「サービスレベル合意書（SLA）」

サービスを提供する側と使う側の間で、「どのくらいの品質のサービスを提供するか」をあらかじめ言葉にして約束しておかないと、後になって「思っていたのと違う」というすれ違いが起きてしまいます。そこで、サービスの内容と、合意されたパフォーマンス（性能や品質の水準）を明確にした、提供組織と顧客との間の合意文書としてサービスレベル合意書（SLA：Service Level Agreement）が結ばれます。たとえば「システムの稼働率は月間99.9%以上を保証する」「問い合わせへの一次回答は8時間以内に行う」といった具体的な数値が、SLAには盛り込まれます。

SLAに関連して覚えておきたい用語がもう2つあります。ひとつはSLO（サービスレベル目標）で、これはSLAの中で定められる個々の達成目標そのものを指します。もうひとつはSLI（サービスレベル指標）で、これはSLOが達成できているかどうかを測るための具体的な指標（稼働率や応答時間の実測値など）です。関係を整理すると、「SLAという契約の中に、SLOという目標が書かれていて、その達成度をSLIという物差しで測る」というイメージになります。3つの言葉が似ていて混同しやすいので、契約文書そのもの（SLA）、目標の値（SLO）、測定する指標（SLI）という役割の違いをセットで覚えておくと得点につながります。

SLAが日常の運用にどうつながるか

言葉の定義だけを覚えても、試験問題の中では場面ごとの判断を問われることが多いので、具体的な流れをイメージしておきましょう。たとえば「稼働率99.9%以上」というSLOを含むSLAを結んでいるクラウドサービスがあったとします。運用担当者は毎月の実際の稼働時間を集計してSLIとして算出し、目標の99.9%を下回っていないかを確認します。もし下回っていれば、原因を調べて改善策を講じ、場合によっては利用料金の一部を返金するなどSLAに定めた対応を行います。このように、SLAは結んで終わりではなく、SLIによる実測と、SLOとの比較という形で日々のサービス運用に組み込まれていく点を押さえておきましょう。

サービスマネジメントの考え方を、組織として実際に回していくための仕組みがサービスマネジメントシステム（SMS）です。「良いサービスを提供しよう」という気持ちだけでは長続きしません。誰が何をいつ行うかというプロセスを組織全体のルールとして定め、それを回し続ける体制を作ることで、はじめてサービスの品質が安定します。この章では、SMSを構成する具体的な管理プロセスと、利用者との接点である窓口の仕組みを見ていきます。

サービスマネジメントシステム（SMS）の全体像

SMSとは、サービスマネジメントという活動を組織的に管理するために、組織に対して求められる要求事項をまとめたものです。ここでいうサービスの要求事項とは、利用者がサービスに何を期待しているか（求める品質・機能・対応スピードなど）を明確にしたものを指します。この要求事項を満たすために、組織はさまざまな専門プロセスを組み合わせてサービスを管理していきます。以下では、そのプロセス群を「日々のトラブルに対応するもの」「変化を安全に取り込むもの」「安定運用を支えるもの」の3つのグループに分けて整理します。

日々のトラブルに向き合うプロセス群

サービスを利用していると、利用者から「使い方を教えてほしい」「新しい機能を使わせてほしい」といった要望や、「動かなくなった」というトラブルの連絡が日々寄せられます。こうした利用者からの要望をまとめて受け付け、記録・分類・優先度付け・実現・終了・対応結果の記録までを一貫して管理する活動をサービス要求管理と呼びます。利用者から見て「どのくらいサービスが必要とされているか」の見通しを立て、需要に見合った供給ができるよう調整する活動が需要管理です。

トラブルが起きたときにまず行うのが、サービスを一刻も早く通常の状態に戻すことに専念するインシデント管理です。応急処置でとにかく復旧させることが目的で、根本原因の追及は後回しにします。それに対して、同じトラブルが繰り返し起きないように根本的な原因を突き止めて解決する活動が問題管理です。インシデント管理は「今すぐ止血する」、問題管理は「二度と同じ傷を作らない」とイメージすると、両者の役割の違いがはっきりします。

変化を安全に取り込むプロセス群

システムは一度作ったら終わりではなく、機能追加や不具合修正のために変更が加えられ続けます。しかし、思いつきで変更を加えるとかえって障害を招きかねません。そこで、変更によるリスクを評価し、計画的かつ安全にシステムへ変更を反映させる活動を変更管理と呼びます。変更を加える前提として、サーバやソフトウェアなど「何がどう構成されているか」という情報を正確に把握・維持する活動が構成管理です。構成情報が正しく管理されていなければ、変更の影響範囲を正しく見積もることもできません。

変更が承認されたら、実際に本番環境へ反映していく作業が必要になります。新しいバージョンのソフトウェアや修正プログラムを、計画的に準備し実際の環境へ展開していく活動をリリース及び展開管理と呼びます。「変更管理で計画を承認し、構成管理で影響範囲を把握し、リリース及び展開管理で実際に反映する」という3つの流れをセットで理解しておくと、試験問題の順序整理にも役立ちます。

安定運用を支えるプロセス群

利用者が安心してサービスを使い続けられるように、あらかじめ合意した水準でサービスが利用できることを管理する活動がサービス可用性管理です。稼働率の目標を定め、それを維持するための対策を講じます。また、災害やシステム障害など重大な事態が起きても、サービスの提供を継続または早期に復旧できるよう備える活動がサービス継続管理です。日常のちょっとした不具合に対応するインシデント管理よりも、もっと大規模な非常事態を想定している点が特徴です。

サービスの品質や達成状況を数値化して関係者にわかりやすく伝える活動がサービスの報告であり、SLAで約束した水準が守られているかどうかを確認するための重要な材料になります。そして、日々のサービス提供や報告から見えてきた課題をもとに、サービスの質を継続的に高めていく活動が継続的改善です。この継続的改善を実践するための代表的な手法が、計画（Plan）・実行（Do）・評価（Check）・改善（Act）を繰り返すPDCAサイクルです。PDCAは1回まわして終わりではなく、Actの気づきを次のPlanに反映させることで、らせん状にサービスの質を高め続けていく点がポイントです。

このほか、利用者が選んで申し込めるサービスの一覧をまとめたサービスカタログ、現場の担当者では対応しきれない問題を、より詳しい知識を持つ上位の担当者や管理者に引き継ぐエスカレーション、新しいサービスや変更されたサービスを本番環境へ安全に移していくサービスの移行、そして移行したサービスが実際に受け入れ可能な品質を満たしているかを判断するためのサービス受入れ基準もあわせて覚えておきましょう。

利用者との最初の接点「サービスデスク」

サービスを使っていて困ったとき、利用者はどこに連絡すればよいのでしょうか。その答えがサービスデスク（ヘルプデスク）です。サービスデスクは、利用者からのあらゆる問い合わせに対して単一の窓口機能（SPOC：Single Point of Contact）を提供します。「困ったらまずここに連絡すればよい」という一本化された窓口があることで、利用者はたらい回しにされずに済みますし、組織側も問い合わせを一元的に管理できます。サービスデスクでは、先ほど紹介したサービス要求管理の流れ（記録と分類、優先度付け、実現、終了、対応結果の記録）に沿って、日々寄せられる問い合わせが処理されていきます。

よくある質問と回答をあらかじめまとめておくFAQは、利用者が自己解決できる機会を増やし、サービスデスクの負担を減らす効果があります。近年では、簡単な問い合わせに自動応答するチャットボットの活用や、AI技術を運用管理業務に取り入れて障害の予兆検知や対応の自動化を図るAIOpsなど、AIを活用したサービスデスクの運用方法が広がりつつあります。人手による対応とAIによる自動対応を組み合わせることで、利用者を待たせず、かつ担当者がより高度な問題解決に集中できる体制づくりが進んでいます。

一連の流れをストーリーでつかむ

最後に、ここまで紹介したプロセスがどうつながっているのか、具体的な場面で確認しておきましょう。ある社員が「業務システムにログインできない」とサービスデスクに連絡したとします。サービスデスクはSPOCとして電話やチャットを受け付け、まずはインシデント管理の一環として応急処置（パスワードの再発行など）を試み、できるだけ早く業務を再開できるようにします。担当者だけでは解決できない込み入った不具合であれば、より詳しい専門チームへエスカレーションして対応を引き継ぎます。同じ症状の問い合わせが複数の社員から相次いだ場合には、問題管理のプロセスに引き継がれ、認証サーバの設定ミスといった根本原因が調査されます。原因が特定されれば、構成管理の情報をもとに影響範囲を確認したうえで変更管理によって修正内容が承認され、リリース及び展開管理を通じて本番環境に安全に反映されます。対応が終わった後はサービスの報告としてSLAの達成状況とあわせて振り返りが行われ、継続的改善によって同様のトラブルを未然に防ぐ仕組みづくりへとつながっていきます。このように一つのトラブルの裏側には、サービスマネジメントシステムを構成する複数のプロセスが連携して動いていることがわかります。

また、利用者が新しくパソコンやソフトウェアの利用を申し込みたいときは、あらかじめ用意されたサービスカタログから選んで申請するのが一般的です。サービスカタログには利用できるサービスの種類や申込方法、対応にかかる目安の時間などがまとめられており、利用者は何を頼めばよいのかを迷わずに済みますし、サービスデスク側も定型的な依頼として効率よく処理できます。

ここまではソフトウェアやプロセスといった「目に見えにくい仕組み」の話でしたが、情報システムは結局のところ、サーバやネットワーク機器という「物理的なモノ」の上で動いています。どんなに優れたサービスマネジメントの仕組みを作っても、電源が落ちたり、機器が熱で壊れたりすれば元も子もありません。この章では、情報システムを支える建物や設備そのものを健全に保つための考え方を学びます。

システム環境整備の必要性

コンピュータやネットワーク機器は、電源や空調が整った適切な環境で初めて安定して動作します。こうしたシステム環境や、それを収める施設・設備を良好な状態に維持し保全していく活動をシステム環境整備と呼びます。停電やほこり、温度・湿度の急激な変化などは、いずれもシステムの停止や故障につながる要因であり、日頃からの点検・保守がサービスの安定提供を支える土台になります。

システム環境整備の代表的な設備のひとつが無停電電源装置（UPS：Uninterruptible Power Supply）です。UPSは、停電が起きた瞬間に内蔵のバッテリーから電力を供給することで、サーバなどの機器が突然シャットダウンしてしまうのを防ぎます。ただしUPSでまかなえる電力には限りがあるため、長時間の停電に備えるには、自前で電気を作り出す自家発電装置が用意されることもあります。UPSが「一瞬の停電をしのいで安全に終了させる、あるいは自家発電への切り替えまでのつなぎ役」であるのに対し、自家発電装置は「停電が長引いても稼働を続けるための備え」という役割の違いを意識しておくと理解しやすいでしょう。

もうひとつ重要なのがサージ防護です。落雷などが起きると、瞬間的に異常に高い電圧（サージ）が電源ラインや通信ラインに流れ込むことがあり、これが精密なコンピュータ機器を一瞬で壊してしまうことがあります。サージ防護は、こうした異常な電圧の侵入から機器を守るための対策であり、UPSや自家発電装置が「電気が来なくなること」への備えであるのに対し、サージ防護は「異常な電気が来てしまうこと」への備えである、という対比で覚えておくと整理しやすくなります。

ファシリティマネジメントという考え方

システム環境整備が個々の設備・機器を維持保全する活動であるのに対し、建物や設備といった資源全体をより広い視点でとらえ、常に最適な状態になるよう改善し続けていく考え方がファシリティマネジメントです。オフィスビルやデータセンターといった施設は、一度建てて終わりではなく、利用状況やコスト、環境負荷などを踏まえて継続的に見直していく必要があります。個々の機器の保守がいわば「対症療法」だとすれば、ファシリティマネジメントは施設全体の使い方や配置、更新計画までを含めた「経営的な視点での資源管理」だとイメージすると、システム環境整備との違いがつかみやすくなります。

環境に配慮した設備運用「グリーンIT」

ファシリティマネジメントを進めるうえで近年欠かせない視点が、環境への配慮です。情報システムの運用にともなう消費電力やCO2排出量を抑え、環境負荷を減らしながらITを活用していこうという考え方をグリーンIT（Green of IT）と呼びます。たとえば、データセンターの空調効率を高めて余分な電力消費を抑えたり、省電力性能の高いサーバに更新したりすることは、ファシリティマネジメントの一環であると同時に、グリーンITの実践でもあります。コスト削減と環境保全の両方につながる取り組みとして、企業の設備投資の判断基準にも組み込まれるようになってきています。

ファシリティマネジメントとサービスマネジメントのつながり

ここで改めて1章・2章とのつながりを整理しておきましょう。2章で学んだサービス可用性管理やサービス継続管理は、「合意した水準でサービスを止めずに使い続けられるようにする」活動でした。しかし、どれだけプロセスを整えても、停電で電源が落ちてしまえば元も子もありません。UPSや自家発電装置、サージ防護といったファシリティマネジメントの取り組みは、いわばサービス可用性管理やサービス継続管理を物理面から支える土台だといえます。試験対策としては、「サービスマネジメント（ソフト面の仕組み）」と「ファシリティマネジメント（ハード面・設備面の備え）」は別々の分野に見えて、実は同じ「サービスを止めない」という目的でつながっている、という関係性を意識しておくと理解が深まります。