サービスマネジメントの全体像と SLA

結論：この分野は「誰に・何を・どの水準で届けるか」を管理する話

サービスマネジメントとは、ITサービス（例：社内システムやクラウドサービス）を、約束した品質で安定して提供し続けるための管理の仕組みです。作ること（開発）ではなく、**動かし続けて利用者に届けること（運用）**が中心です。

この分野の教科書にあたるのが次の2つです。

• ITIL（アイティル）：ITサービス運用の成功事例（ベストプラクティス）を集めたフレームワーク（考え方と進め方のひな形）
• JIS Q 20000-1（国際規格 ISO/IEC 20000-1 の日本版）：サービスマネジメントの国内規格。満たすべき要求事項（やらなければならないこと）を定める

JIS Q 20000 では、組織がサービスを管理する仕組み全体を SMS（サービスマネジメントシステム）と呼びます。試験の選択肢で「サービスの設計，移行，提供及び改善のために…指揮し，管理する，一連の能力及びプロセス」と出てきたら、それは SMS の説明です。

最頻出：サービスデスクの3つの形態

サービスデスクは、利用者からの問い合わせや障害の報告を一か所で受ける単一窓口（SPOC）です。ITIL ではプロセス（手順）ではなく「機能」（組織・役割）に分類されます。この分野で最も多く出題されている論点が、サービスデスクの置き方の違いです。

たとえるなら、ローカル＝各店舗にいる店員、集中＝本社のコールセンター、バーチャル＝在宅オペレーターが各地にいるのに、電話番号は1つのコールセンターです。

見分け方のコツ

• 「近く」「言語・文化」「VIP」があればローカル
• 「集中」「効率的」「大量」があれば集中
• 「分散しているが単一のように見える」「通信技術」があればバーチャル

ひっかけとして、「分散拠点の要員も含めて全員を中央で統括して管理する」（統制の説明で、どの形態の定義でもない）や、「専任スタッフを置かず他の業務の担当者が兼任する」といった、もっともらしい作文の選択肢が混ざります。この2つは3形態のどれにも当てはまらないので、キーワード表に照らして消します。

SLA：サービス目標についての提供者と顧客の「合意」

SLA（Service Level Agreement、サービスレベル合意書）は、サービスの内容とサービス目標（例：稼働率99.9%、問い合わせへの初回応答は30分以内）について、サービス提供者と顧客が交わす合意です。要件定義でいう「非機能要件の数値目標」を、運用段階の約束として文書にしたもの、と考えると分かりやすいです。

似た文書との区別（ここがひっかけの中心）

SLAの作り方で正しい方針は「顧客と提供者のニーズ、そして費用を考慮して水準を決める」です。次のような極端な選択肢は誤りです。

• 考えられる全ての項目に水準を設定する（費用が膨らみ、管理しきれない）
• 全ての項目にペナルティ（補償）を付ける
• 将来も変更不要な水準にする（SLAは定期的に見直すもの）

**サービスレベル管理（SLM）**は、SLAを作り、守れているか監視し、見直すプロセスです。JIS Q 20000 での要求事項は「サービスカタログとSLAを作成し、顧客と合意する」です。紛らわしい選択肢の正体は、リスク評価＝サービス継続・可用性管理、容量・能力の計画＝キャパシティ管理、予算と費用の管理＝予算業務及び会計業務です。

また、「ITサービスマネジメントの管理プロセスはどれか」と聞かれたら、答えはサービスレベル管理です。スケジュール管理・品質管理・リスク管理はプロジェクトマネジメント側の言葉なので選びません。

サービスサポートの5プロセス：インシデント管理と問題管理を分ける

ITIL v2 では、日々の運用をまとめたサービスサポートを「5プロセス＋1機能」で整理しています（中長期の計画側はサービスデリバリと呼び、サービスレベル管理・可用性管理・キャパシティ管理・ITサービス継続性管理などが入ります）。

たとえると、天井から水漏れしたとき、バケツを置いてとりあえず生活できるようにするのがインシデント管理、配管のどこが壊れたかを突き止めて再発を防ぐのが問題管理です。

ひっかけの典型

• 「障害報告を既知のエラー（原因と回避策が分かっている既存の不具合）と照合する」はインシデント管理です。早く直すための作業なので、問題管理ではありません。
• 「ディスクの空き容量がしきい値に近い」はキャパシティ管理、「プログラム変更の影響度を調べる」は変更管理、「顧客満足度がサービスレベルを満たしているか評価する」はサービスレベル管理です。
• 根本原因を問われているのに、選択肢に可用性管理やサービスレベル管理（どちらもサービスデリバリ側）を置いて迷わせることがあります。

PDCA：どの活動がどの段階かを当てる

JIS Q 20000-1 では、SMSのあらゆる場面で PDCA（Plan→Do→Check→Act の改善サイクル）を回すことを求めています。

flowchart LR
  P["Plan: 確立・文書化・役割の枠組み"] --> D["Do: 導入・運用"]
  D --> C["Check: 監視・測定・レビュー"]
  C --> A["Act: 改善の処置"]
  A --> P

ひっかけ：「改善についての計画を作成し、改善を実施する」は「計画」という言葉が入っていても Act です。言葉の表面ではなく、何を目的にした活動かで判断します。

可用性の定義：「合意された時点・期間に、要求された機能を実行する能力」

可用性は、JIS Q 20000 の定義では「あらかじめ合意された時点又は期間にわたって、要求された機能を実行するサービスの能力」です。つまり「使いたいときにちゃんと使えるか」です。

「中断なしに、又は合意した可用性を一貫して提供する能力」も可用性に似ていますが、これは継続性寄りの表現なので誤りです。「要求された機能を実行する」という言葉が入っているかどうかで見分けます。