【SC試験・午前1】サービスマネジメントを攻略！SLAと稼働率計算・インシデント管理と問題管理の頻出パターン完全ガイド

「システムは動いて当たり前」。運用の仕事は、うまくいっている間は誰にも気づかれず、止まった瞬間だけ全社の注目を浴びます。午前1（科目A-1）のサービスマネジメントは、その「当たり前」を契約と数値と手順に落とし込む技術を問う分野です。

出題の中身は驚くほど安定しています。似た名前のプロセスを見分ける問題と、稼働率まわりの計算問題。この2つで大半が片づきます。前回のプロジェクトマネジメントが「有期の活動」を管理する手法だったのに対し、今回は稼働後のサービスという「終わらない活動」を管理する手法です。

なお、SC試験は2026年度からCBT方式へ移行し、試験区分の名称も変更されます。午前Ⅰが科目A-1、午前Ⅱが科目A-2、午後が科目Bという呼び方になります。これはIPAの試験要綱Ver.5.6（2026年10月の試験から適用）に反映済みで、出題範囲・出題数・試験時間に変更はありません。制度変更の詳細は「【2026年度版】情報処理安全確保支援士試験のCBT化で何が変わる？科目A/科目Bの新名称と対策の変え方」で解説しています。本記事では検索でたどり着きやすい「午前1」の呼称を主軸にしつつ、新名称を併記して進めます。

筆者はIT企業でインフラエンジニアとしてサーバーやルーターの設定・設計を担当し、その後、事業会社のCIOとして社内のIT統制の責任を負う立場になりました。運用側から見ても経営側から見ても、サービスマネジメントの用語は現場の会話そのものです。「これはインシデントなのか問題なのか」「復旧を優先するのか原因究明を優先するのか」という判断は、試験の選択肢の中だけでなく、障害対応の会議室で毎回発生します。試験で問われる区別は、実務の判断そのものだと考えて読み進めてください。

本シリーズの全体戦略は導入記事「元CIOが実践するスタミナ温存術！「コスパ極振り」最短エスケープルート・完全版ロードマップ」に、前回のプロジェクトマネジメントは「プロジェクトマネジメントを攻略！EVMとアローダイアグラムの計算パターン完全ガイド」にまとめています。本記事は第9回、マネジメント系（第2部）の2本目です。

この記事で学べること

• 午前1のサービスマネジメントで「取る問題」と「捨てる問題」の線引き
• ITILとJIS Q 20000の関係、サービスライフサイクルとITIL 4の枠組み
• SLA・SLO・SLMの違いと、SLMのPDCAの回し方
• MTBF・MTTR・稼働率の公式と、サービス時間帯を使った計算手順
• インシデント管理と問題管理の違い、ワークアラウンドと既知の誤り
• 変更管理・リリース管理・構成管理（CMDB）の役割分担
• サービスデスクの4つの組織形態とエスカレーションの2種類
• キャパシティ管理、ITサービス継続管理、TCOとチャージバック
• UPS・自家発電装置・免震といったファシリティマネジメントの論点

午前1のサービスマネジメントは「用語の区別」と「稼働率計算」で取り切る

最初に投資先を決めます。この分野は覚える用語が多く見えますが、実際に問われる範囲は狭く固定されています。

午前1は30問中18問で通過する試験

午前1は30問出題され、100点満点中60点以上で通過します。18問取れれば十分です。テクノロジ系・マネジメント系・ストラテジ系の全分野から出題され、マネジメント系は全体でおおむね5問前後、そのうちサービスマネジメント（ITサービスマネジメントとファシリティマネジメントを含む）からは1〜2問というのが標準的な配分です。

問題数は多くありませんが、この分野の費用対効果は高いと言い切れます。理由は2つあります。1つは、問われる論点が「似たプロセスの見分け」に集中していること。もう1つは、計算が稼働率とその周辺しかなく、公式が1本で済むことです。しかもSC試験本体（午前2・午後）でインシデント対応やSLAが繰り返し登場するため、ここで覚えた枠組みがそのまま再利用できます。

取る問題：プロセスの識別、稼働率計算、SLA、サービスデスク

優先して押さえるのは次の4つです。

1つ目はプロセスの識別です。 インシデント管理・問題管理・変更管理・リリース管理・構成管理の5つについて、「目的は何か」を一言で言えるようにします。午前1で最も出るのはここです。

2つ目は稼働率の計算です。 MTBF・MTTRから稼働率を求める型と、サービス時間帯と停止時間から稼働率や許容停止時間を求める型の2パターンです。

3つ目はSLAとSLMです。 SLAが何を定める文書で、SLMが何をする活動なのかという役割の違いが問われます。

4つ目はサービスデスクの組織形態と、ファシリティマネジメント（UPSなど）の用語です。 どちらも選択肢を読めば判断できる素直な問題として出ます。

捨てる問題：ITILの全プラクティスとJIS Q 20000の箇条番号

逆に、時間をかけない領域も決めます。ITIL 4の34プラクティスの全暗記、JIS Q 20000-1の箇条番号や要求事項の逐条確認、認証取得の手続き、ITIL資格体系の階層といった論点は、労力に対する見返りが小さい部分です。名称と位置づけだけ押さえ、出たら消去法で当てにいく判断で構いません。

重要なのは、体系の暗記ではなく「このプロセスは何を目的にしているか」を自分の言葉で言えることです。午前1の選択肢は、目的を取り違えさせる形で作られています。

復旧を急ぐか、原因を突き止めるか

障害対応の現場で最初にぶつかるのが、復旧と原因究明のどちらを優先するかという判断です。利用者が困っているのだから一刻も早く戻したい。しかし電源を入れ直せば、原因を示す証拠は消えることがあります。

サービスマネジメントは、この葛藤に対して明確な答えを用意しています。インシデント管理は復旧を最優先し、原因究明は問題管理という別のプロセスに切り出すというものです。同じ人が両方を担当することはあっても、目的と評価指標を分けておく。この設計思想を理解していれば、午前1の選択肢はほぼ迷いません。

ITサービスマネジメントの全体像：ITILとJIS Q 20000

用語の前に、どの枠組みの話をしているのかを整理します。ここが曖昧だと、選択肢の区別ができません。

サービスとサービスマネジメントの定義

ITサービスマネジメント（ITSM：IT Service Management）とは、ITを「システム」ではなく「サービス」として捉え、利用者に対して合意した品質で継続的に提供するための管理活動です。

ポイントは視点の置き方にあります。従来の運用管理が「サーバーが動いているか」というシステム側の視点だったのに対し、ITサービスマネジメントは「利用者が業務を遂行できているか」という利用者側の視点で品質を測ります。サーバーが起動していてもアプリケーションが応答しなければ、サービスとしては停止しているという考え方です。

ITILとJIS Q 20000の関係

この分野には代表的な枠組みが2つあります。

ITIL（Information Technology Infrastructure Library）は、英国政府が実務の成功事例を集めて体系化したガイドラインです。ベストプラクティス集であり、規格でも認証制度でもありません。「こうするとうまくいく」という知見の集合体です。

JIS Q 20000は、ITサービスマネジメントの規格です。国際規格ISO/IEC 20000に対応する日本産業規格で、第1部（JIS Q 20000-1）がサービスマネジメントシステム（SMS）の要求事項、第2部（JIS Q 20000-2）が適用の手引です。現行のJIS Q 20000-1:2020は、ISO/IEC 20000-1:2018に対応しています（2025年に、気候変動への配慮を追加する追補1が発行されています）。要求事項が定められているため、こちらは第三者認証の対象になります。

つまり、「ITILは手本、JIS Q 20000はものさし」という関係です。午前1で問われるのはこの位置づけの違いで、条文の中身ではありません。

サービスライフサイクル：ITIL v3の5段階

ITIL v3（2011 edition）では、サービスを一生涯にわたって管理するという発想から、サービスライフサイクルとして5つの段階が定義されていました。

• サービスストラテジ（戦略）：どのようなサービスを、誰に、どう提供するかを決める
• サービスデザイン（設計）：可用性・キャパシティ・継続性・セキュリティなどの要件を設計する
• サービストランジション（移行）：設計したサービスを本番環境へ安全に移行する。変更管理・リリース管理・構成管理がここに属する
• サービスオペレーション（運用）：日々のサービス提供。インシデント管理・問題管理・サービスデスクがここに属する
• 継続的サービス改善（CSI：Continual Service Improvement）：全段階を通じて改善を続ける

インシデント管理は「運用」、変更管理は「移行」というプロセスの所属を押さえておくと、選択肢の整理がしやすくなります。

ITIL 4の枠組み：サービスバリューシステムと4つの側面

2019年に登場したITIL 4では、ライフサイクル中心の構成から、価値の共創を軸とする構成へと大きく変わりました。中心にあるのがSVS（Service Value System：サービスバリューシステム）という考え方で、その中核にサービスバリューチェーン（計画、改善、エンゲージ、設計および移行、取得・構築、提供およびサポートの6活動）が置かれています。

さらに、SVSを支える7つの従うべき原則（ガイディングプリンシプル）と、サービス全体を見る観点である4つの側面（組織と人材、情報と技術、パートナとサプライヤ、バリューストリームとプロセス）、v3のプロセスにあたる34のプラクティスがあります。v3の「プロセス」はITIL 4では「プラクティス」と呼ばれ、インシデント管理・問題管理などは一般的管理プラクティス／サービス管理プラクティス／技術管理プラクティスに分類されています。

午前1の対策としては、「ITIL 4ではプロセスではなくプラクティスと呼び、SVSとサービスバリューチェーンが軸になった」という変化の事実を知っていれば十分です。個々のプロセスの中身自体はv3から大きく変わっていないため、以降の解説はプロセス名で進めます。

SLAとSLM：合意した品質を測って回す

サービスの品質を「感覚」ではなく「合意した数値」で扱うための仕組みです。SC試験では午後の事例にもそのまま登場します。

SLA・SLO・SLMの違い

3つの略語が並ぶため、ここで整理します。

• SLA（Service Level Agreement：サービスレベル合意書）：サービス提供者と利用者の間で、提供するサービスの範囲と品質水準を合意した文書
• SLO（Service Level Objective：サービスレベル目標）：SLAの中に定める個々の数値目標（稼働率99.5%以上、など）
• SLM（Service Level Management：サービスレベル管理）：SLAで合意した水準を維持・改善するために、測定・報告・レビュー・改善を継続的に回す活動そのもの

「SLAは文書、SLOは数値目標、SLMは活動」という3点セットで覚えます。午前1では特にSLAとSLMの混同を狙った選択肢が出ます。「サービス品質を維持・向上させるための一連の活動はどれか」と問われたらSLM、「合意内容を明文化したものはどれか」ならSLAです。

なお、社内の情報システム部門と利用部門との間で結ぶ場合もSLAと呼びますが、法的拘束力のある契約とは限りません。外部委託の場合は契約書の一部として位置づけられることが一般的です。

SLAに定める代表的な項目

SLAには、少なくとも次のような項目を定めます。

• サービス時間帯：サービスを提供する曜日と時間（例：平日8時から20時）。計画停止（定期保守）の扱いもここで定める
• 可用性：稼働率の目標値。どの時間帯を分母にするかまで明記する
• 性能：オンライン応答時間、バッチ処理の完了時刻、同時接続数など
• サポート：障害受付の窓口と受付時間、一次回答までの時間、重大度別の目標復旧時間
• セキュリティ：脆弱性対応の期限、ログの保存期間、監査への協力範囲
• 報告と改善：報告の頻度と項目、レビュー会議の開催頻度
• ペナルティと免責：未達時の対応（料金減額など）と、免責となる事象の範囲

つまずきやすいのは、目標復旧時間や停止許容時間が「サービス時間帯」を前提に定義されるという点です。24時間365日のサービスと、平日日中のみのサービスでは、同じ「稼働率99.5%」でも許容される停止時間の絶対値がまったく違います。

SLMはPDCAで回す

SLMは、次のサイクルで継続的に回します。

• Plan：業務要件から必要なサービス水準を定め、SLAとして合意する
• Do：合意した水準でサービスを提供し、実績値を測定する
• Check：実績とSLOを比較し、達成状況をサービスレベル報告として提示する
• Act：未達の原因を分析して改善する。要件と実態が乖離していればSLA自体を見直す

Actに「SLAの見直し」が含まれる点が重要です。SLAは一度結んだら固定するものではなく、業務の変化やコストとのバランスに応じて改定していく前提の文書です。

つまずきポイント：SLAは高ければよいものではない

学び始めの人がよく誤解するのが、SLAの水準は高いほど良いという考え方です。実際には、稼働率の目標を1桁上げるには冗長構成や監視体制の強化が必要になり、コストは非線形に増えます。

SLMの要点は、業務上必要な水準を見極め、それに見合ったコストで合意することにあります。すべてのシステムに最高水準を求めるのではなく、業務停止の影響度に応じて水準を分ける。試験でも「SLAの目標値を設定する際に考慮すべきこと」として、コストとのバランスや業務要件との整合が正解になる形で問われます。

可用性の計算パターン：稼働率・MTBF・MTTR

この分野で唯一の計算論点です。公式は1本で、あとは分母の取り方を間違えないことが勝負になります。

MTBFとMTTRの定義

• MTBF（Mean Time Between Failures：平均故障間隔）：故障が復旧してから次に故障するまでの、正常に動作していた時間の平均。信頼性の指標
• MTTR（Mean Time To Repair：平均修復時間）：故障してから復旧するまでの、修理に要した時間の平均。保守性の指標

MTBFは長いほど、MTTRは短いほど良い状態です。混同しやすいので、**BはBetween（間隔・動いている時間）、RはRepair（修理・止まっている時間）**と頭文字で紐づけておくと安全です。

MTBFとMTTRを足すと1回の故障サイクル全体の時間になり、そのうち動いていた割合が稼働率（アベイラビリティ、可用性）です。

稼働率 ＝ MTBF ÷ （MTBF ＋ MTTR）

分母がMTBFだけではない点、分子がMTTRではない点に注意します。なお、複数台の機器を直列・並列に組み合わせたときの稼働率計算は、第5回「システム構成要素の稼働率計算を攻略！直列・並列・RAIDの頻出パターン完全ガイド」で詳しく扱っています。本記事では単体および運用実績からの計算に絞ります。

例題1：MTBFとMTTRから稼働率を求める

あるシステムのMTBFが480時間、MTTRが20時間でした。稼働率を求めます。

手順1：1サイクルの全体時間を求めます。480 ＋ 20 ＝ 500時間

手順2：稼働していた割合を求めます。480 ÷ 500 ＝ 0.96

答え：稼働率は0.96（96%）

この形の応用として、MTTRを半分（10時間）に短縮できた場合を考えます。480 ÷ 490 ≒ 0.9796 となり、稼働率は約98.0%に改善します。MTBFを延ばす（壊れにくくする）だけでなく、MTTRを縮める（早く直す）ことでも可用性は上がるという点は、選択肢の判断で問われることがあります。

例題2：運用実績から MTBF・MTTR を求める

1,000時間の運用期間中に4回の故障が発生し、修復に要した時間の合計が40時間でした。MTBF、MTTR、稼働率を求めます。

手順1：実際に稼働していた時間を求めます。1,000 － 40 ＝ 960時間

手順2：MTBFは稼働時間を故障回数で割ります。960 ÷ 4 ＝ 240時間

手順3：MTTRは修復時間の合計を故障回数で割ります。40 ÷ 4 ＝ 10時間

手順4：稼働率は 240 ÷ （240 ＋ 10） ＝ 0.96（96%）

ここでのつまずきポイントは手順1です。MTBFは「故障と故障の間隔」なので、分子には修復時間を含めない稼働時間を使います。1,000 ÷ 4 ＝ 250時間としてしまうのが典型的な誤りです。なお、稼働率は 960 ÷ 1,000 ＝ 0.96 と直接求めることもでき、検算に使えます。

例題3：サービス時間帯から許容停止時間を求める

SLAで「サービス時間帯は平日8時から20時、稼働率99.5%以上」と合意しました。営業日が月20日の場合、1か月に許容される停止時間は何分でしょうか。

手順1：月間のサービス時間を求めます。1日12時間 × 20日 ＝ 240時間

手順2：許容される停止の割合を求めます。100% － 99.5% ＝ 0.5%

手順3：許容停止時間を求めます。240 × 0.005 ＝ 1.2時間 ＝ 72分

もしこの月に3時間の停止が発生した場合、稼働率は （240 － 3） ÷ 240 ＝ 0.9875、すなわち98.75%となり、SLA未達です。

つまずきポイント：分母に何を入れるか

この計算での失点は、ほぼ分母の取り違えです。

第1に、サービス時間外の停止を数えてしまう誤りです。 平日8時から20時のサービスであれば、深夜に発生した停止はSLA上の停止時間に含めないのが原則です（SLAでそう定めている場合）。分母も分子も、合意したサービス時間帯の中だけで数えます。

第2に、計画停止の扱いです。 定期保守などの計画停止をサービス時間から除外するのか、停止時間として算入するのかは、SLAの定め次第です。試験では問題文に条件が書かれているので、必ず問題文の定義に従います。自分の常識で判断しないことが重要です。

第3に、24時間365日運用との混同です。 24時間365日で稼働率99.9%なら、年間の許容停止時間は 8,760時間 × 0.001 ＝ 8.76時間です。同じ99.9%でも、サービス時間帯が短ければ許容される絶対時間は短くなります。

運用プロセスの区別：インシデント管理から構成管理まで

午前1で最も出る論点です。「目的は何か」の一言を、5つのプロセスすべてについて用意します。

インシデント管理：とにかく早く元に戻す

インシデント管理の目的は、サービスの中断や品質低下を、可能な限り迅速に復旧させることです。原因の究明ではありません。

ここでいうインシデントとは、サービスの計画外の中断、または品質の低下を指します。利用者から見て「使えない」「遅い」という状態はすべてインシデントです。実際に障害に至らなくても、サービス品質の低下につながりうる事象を含みます。

根本原因が分からなくても、サーバーの再起動や代替系への切り替えで業務が回復するなら、それで一旦クローズします。この一時的な回避策をワークアラウンド（暫定処置）と呼びます。

問題管理：二度と起こさないために原因を潰す

問題管理の目的は、インシデントの根本原因を究明し、再発を防止することです。時間軸はインシデント管理より長く、急ぎません。

用語として押さえるべきは次の2つです。

• 問題：1つ以上のインシデントを引き起こした、または引き起こす可能性のある未知の根本原因
• 既知の誤り（Known Error）：根本原因が特定されているか、またはサービスへの影響を低減・除去する方法（ワークアラウンド）がある問題。実務では両方がそろっている状態を指すことが多い。既知の誤りデータベース（KEDB）に登録し、同じインシデントが再発したときの即時対応に使う

問題管理は、まだ発生していない障害の原因を先回りで除去する予防的（プロアクティブ）な活動も含みます。インシデントの傾向分析から潜在的な問題を見つける、といった動き方です。

つまずきポイント：ワークアラウンドはどちらのプロセスか

午前1の定番の引っかけがここです。整理すると次のようになります。

• ワークアラウンドを「適用してサービスを復旧させる」のはインシデント管理
• ワークアラウンドを「特定・確立して記録する」のは問題管理

つまり、暫定回避策を見つけ出して既知の誤りとして登録するのが問題管理、それを使って目の前の障害を復旧させるのがインシデント管理です。

もう1つの定番は、インシデント管理の目標を「根本原因の究明」とする選択肢です。これは問題管理の目的なので誤りです。逆に「サービスの早期復旧」を問題管理の目的とする選択肢も誤りになります。「復旧はインシデント、原因は問題」と唱えて即答できる状態にします。

変更管理とリリース管理：決めるのと届けるのは別

インフラや業務システムに手を入れる場面のプロセスも、目的で分かれます。

変更管理は、変更要求（RFC：Request For Change）を受け付け、変更に伴うリスクと影響を評価し、実施の可否を承認するプロセスです。ITIL 4では変更コントロール／変更実現（change enablement）と呼ばれます。承認機関として変更諮問委員会（CAB：Change Advisory Board）が置かれることがあります。

リリース管理（リリース及び展開管理）は、承認された変更を本番環境へ計画的に展開し、稼働させるプロセスです。テスト、展開手順の作成、利用者への教育、切り戻し手順の準備などを担います。

区別は明快で、「変更管理は承認する側、リリース管理は届ける側」です。試験では「変更の可否を決定するのはどのプロセスか」→変更管理、「本番環境への導入を計画・実施するのはどのプロセスか」→リリース管理、という形で問われます。

実務上のつまずきは、緊急変更の扱いです。障害復旧のために急いで設定を変えるとき、承認プロセスを飛ばしてしまいがちです。緊急変更には簡略化された承認ルートを事前に定義しておき、事後に必ず記録するという運用が求められます。「急ぐから記録しない」を許すと、次の障害時に何が変わったのか誰も分からなくなります。

構成管理とCMDB：今どうなっているかを持ち続ける

構成管理（サービス資産管理及び構成管理）の目的は、ITサービスを構成する要素の正確な情報を維持し、必要なときに提供することです。

管理対象の一つひとつをCI（Configuration Item：構成要素、構成品目）と呼び、ハードウェア、ソフトウェア、ライセンス、文書、さらにはSLAのような契約文書までを含みます。これらの属性とCI間の関連（どのサーバーがどの業務システムを支えているか、など）を格納するデータベースがCMDB（Configuration Management Database：構成管理データベース）です。

CMDBの価値は、影響範囲の即時把握にあります。あるサーバーに脆弱性が見つかったとき、それがどの業務システムに使われ、どの利用部門に影響するかが即座に分かるかどうかで、対応スピードが変わります。変更管理の影響評価もCMDBを前提に行われます。

つまずきやすいのは、構成管理と資産管理の混同です。資産管理は主に会計上の資産価値や購入・償却の管理が目的であるのに対し、構成管理はサービス提供に必要な構成と関連の把握が目的です。管理対象が重なっていても、目的が違います。

サービスデスク、キャパシティ、継続性、コスト

残りの管理プロセスを、出題される粒度で押さえます。

サービスデスクの4つの組織形態

サービスデスクは、利用者からの問い合わせや障害連絡を受ける単一の窓口（SPOC：Single Point Of Contact）です。プロセスではなく機能（組織）である点が、他と異なります。

組織形態は4つに分類されます。

• 中央サービスデスク：拠点が複数あっても、窓口を1か所に集約する形態。要員の効率的な活用とノウハウの集約がしやすい
• ローカルサービスデスク：利用者のいる拠点ごとに窓口を配置する形態。言語や文化、現地固有の事情に対応しやすいが、コストは高くなる
• バーチャルサービスデスク：要員は地理的に分散しているが、通信技術によって利用者からは1か所に見える形態
• フォロー・ザ・サン（Follow the Sun）：時差のある複数の拠点を連携させ、それぞれの拠点の日中帯で対応をリレーすることで、24時間サービスを夜勤なしで実現する形態

出題されるのは、この4つの説明文と名称の対応です。特にフォロー・ザ・サンは、「時差を利用して24時間対応を実現する」という説明で頻出します。

エスカレーションの2種類

サービスデスクで解決できない案件は、上位へ引き継ぎます。この引き継ぎ方には2種類あります。

• 機能的エスカレーション（水平方向）：より高度な技術知識を持つ担当者や専門チームへ引き継ぐ
• 階層的エスカレーション（垂直方向）：権限や判断が必要な場合に、管理者や責任者へ引き上げる

技術力が足りないときは機能的、判断や権限が必要なとき（重大障害の対外公表判断など）は階層的です。試験ではこの2つの区別が問われます。

キャパシティ管理と可用性管理

キャパシティ管理は、現在および将来の需要に対して、費用対効果の高い形で十分な能力を確保するプロセスです。CPU使用率、メモリ、ディスク容量、ネットワーク帯域といった資源の利用状況を監視し、傾向から将来の需要を予測して増強計画を立てます。

ここでの要点は、過剰でも過小でもいけないという点です。過小なら性能問題が起き、過剰ならコストの無駄になります。「性能が出ないので常に最大構成にする」は、キャパシティ管理としては誤りです。

可用性管理は、合意した可用性を実現するために、冗長化や監視、保守体制を設計・維持するプロセスです。前述のMTBF・MTTR・稼働率は、この可用性管理で使う指標です。

ITサービス継続管理とRTO・RPO

ITサービス継続管理（ITSCM）は、災害や大規模障害が発生した場合でも、合意した期間内にITサービスを復旧できる能力を維持するプロセスです。事業継続計画（BCP）のIT部分に相当します。

ここで使う代表的な指標が次の2つです。

• RTO（Recovery Time Objective：目標復旧時間）：障害発生からサービス復旧までに許容される時間
• RPO（Recovery Point Objective：目標復旧時点）：障害発生時にさかのぼって復旧できるデータの時点。どこまでのデータ損失を許容するか

RPOを短くするほどバックアップの頻度を上げる必要があり、コストが増えます。この2つの詳細と、BCPとDR（災害復旧）の関係は「BCPとDRの違いを比較表で解説｜RPO・RTOと情報処理安全確保支援士の出題」と「RPOとRTOの違いとは？システムを救うバックアップ戦略の決定版」で詳しく扱っています。午前1では定義の識別が中心です。

ITサービスの費用：TCOとチャージバック

サービスの財務管理では、次の用語が問われます。

TCO（Total Cost of Ownership：総所有費用）は、システムの導入費用（イニシャルコスト）だけでなく、運用・保守・教育・廃棄までを含めたライフサイクル全体の費用です。運用費（ランニングコスト）を含めて評価する点が要点で、「導入時は安いが運用費が高い」構成を見抜くための考え方です。

チャージバックは、ITサービスの費用を、利用実績に応じて利用部門へ課金・配賦する仕組みです。利用部門にコスト意識が生まれ、無駄な資源要求が抑制されるという効果があります。一方で、課金を嫌って必要な利用まで抑制されることや、配賦ルールの設計と測定に手間がかかることが課題として挙げられます。

ファシリティマネジメント：設備で守る可用性

システムが載っている建物と電源の話です。午前1では用語の識別として、素直な問題が出ます。

UPSと自家発電装置の役割分担

ファシリティマネジメントは、施設や設備を最適な状態で維持・管理する活動です。ITの文脈では、データセンターやサーバー室の電源・空調・入退室管理などが対象になります。

電源対策の主役がUPS（Uninterruptible Power Supply：無停電電源装置）です。ここで押さえるべきは、UPSの目的が長時間の電力供給ではないことです。UPSが担うのは、停電した瞬間から数分から数十分程度、バッテリーで給電を継続し、その間に安全なシャットダウンを行うか、自家発電装置への切り替えを完了させることです。

長時間の停電に備えるのは自家発電装置（非常用発電機）です。燃料が続く限り給電できますが、起動から安定までに時間がかかるため、その空白をUPSが埋めるという役割分担になります。

つまずきポイントは、「UPSがあれば停電しても業務を継続できる」という誤解です。UPSは時間を稼ぐ装置であり、稼いだ時間に何をするかを決めておかなければ意味がありません。

電源品質の異常と対策

電源のトラブルは停電だけではありません。

• 瞬時電圧低下（瞬低）：落雷などで、ごく短時間だけ電圧が下がる現象。機器が誤動作や再起動を起こす
• サージ：落雷などによる異常な過電圧。サージプロテクタ（避雷器）で機器を保護する
• 電圧変動・ノイズ：UPSの種類によっては、常時インバータ給電方式のように電源品質を整える機能を持つものがある

雷対策としては、電源線だけでなく通信線からの雷サージ侵入にも備える必要があります。

建物と設置形態

• 免震構造：建物と地盤の間に免震装置を入れ、地震の揺れを建物に伝えにくくする構造。耐震構造（揺れに耐える）、制震構造（揺れを吸収する）との違いが問われる
• コロケーション：事業者のデータセンターに、自社が所有する機器を設置してもらう形態。設備（電源・空調・回線・物理セキュリティ）を借り、機器は自社資産のまま運用する
• ハウジング：日本ではコロケーションとほぼ同義で使われる。場所と設備を借り、機器は自社のもの
• ホスティング：事業者が所有する機器を借りて利用する形態。機器は事業者の資産

自社設備の運用を外部に任せるアウトソーシングとの違いも含め、「誰の機器か」「誰が運用するか」の2軸で整理すると混同しません。

電力効率とゾーニング

データセンターの電力効率を示す指標がPUE（Power Usage Effectiveness）です。データセンター全体の消費電力を、IT機器の消費電力で割った値で、1.0に近いほど効率が良いことを示します。空調などIT機器以外の消費が大きいほど値が大きくなります。

物理セキュリティ側では、重要度に応じて区域を分けるセキュリティゾーニング、共連れを防ぐマントラップや、入退室記録の矛盾を検知するアンチパスバックといった論点があります。これらは「【物理的セキュリティ完全ガイド】入退室管理とクリアデスクで情報漏えいを防ぐ鉄則」で詳しく扱っています。

SC試験での出題パターンと対策

ここまでの内容が、実際の試験でどう問われるかを整理します。

午前1で繰り返される3つの型

第1の型はプロセスの識別です。「インシデント管理の目的として適切なものはどれか」「サービスの根本原因を分析し再発防止を図るプロセスはどれか」「本番環境への展開を計画・実施するのはどれか」といった形式で問われます。復旧と原因究明、承認と展開という対比を押さえていれば即答できます。

第2の型は稼働率とMTBF・MTTRの計算です。MTBFとMTTRから稼働率を求める素直な問題のほか、運用実績（総運用時間・故障回数・修復時間合計）からMTBFを求めさせる問題、SLAの稼働率から許容停止時間を求める問題が出ます。分母の取り方だけ気をつければ確実に取れます。

第3の型はSLA・サービスデスク・ファシリティの用語識別です。「フォロー・ザ・サンの説明はどれか」「UPSの導入目的はどれか」「TCOに含まれるものはどれか」といった問い方をされます。

出題形式は安定しており、午前1では類似の問題が繰り返し出題されています。この分野に絞って過去問を解き、用語の対応関係を体に入れておくのが最短の対策です。

SC試験の午前2・午後との接続

サービスマネジメントは、SC試験本体では姿を変えて頻繁に登場します。

午前2・午後で最も直結するのがインシデント対応です。セキュリティインシデントの対応も、まず被害の拡大防止と復旧、その後に原因究明と再発防止という流れをとります。これはインシデント管理と問題管理の分担そのものです。CSIRTの役割分担については「CSIRTとSOCの違いとは？情報処理安全確保支援士試験で問われるセキュリティ組織の役割分担」で扱っています。

変更管理と構成管理も午後で頻出です。脆弱性が公表されたときに、影響を受ける資産を特定できるか（構成管理・CMDB）、パッチ適用の影響を評価して承認できるか（変更管理）という形で、事例の中に埋め込まれます。資産管理の観点は「システム運用セキュリティ完全ガイド｜インシデント対応・脆弱性管理・BCP戦略を徹底解説」も参考になります。

SLAは委託先管理の文脈で登場します。クラウドサービスや運用委託先に対して、セキュリティ要件（脆弱性対応の期限、ログの提供、インシデント時の報告義務）をSLAや契約にどう盛り込むか、という論点です。午前1で覚えた「SLAに定める項目」の枠組みが、そのまま午後の記述の骨格になります。

なお、次回扱うシステム監査は、これらのプロセスが「定めたとおりに運用されているか」を独立した立場で確かめる仕組みです。両者の関係は「【図解】システム監査と情報セキュリティ監査の違いを徹底解説」でも整理しています。

【演習】サービスマネジメント 理解度チェック（全10問）

午前1では、インシデント管理と問題管理をはじめとする運用プロセスの目的の識別、MTBF・MTTRを使った稼働率計算、SLAやサービスデスクの用語識別が定型で問われます。午後では、セキュリティインシデント対応や委託先とのSLAという形で同じ枠組みが事例に埋め込まれます。定番の引っかけは、インシデント管理の目的を「根本原因の究明」としてしまう誤り、MTBFの計算で修復時間を含めた総時間を故障回数で割ってしまう誤り、稼働率の分母にサービス時間帯外を含めてしまう誤りの3つです。以下の練習問題で本記事の理解度を確認してみましょう。

まとめ：終わらない活動を、数値と手順で回し続ける

午前1のサービスマネジメントは、覚えるべき軸が少ない分野です。「復旧はインシデント管理、原因は問題管理、承認は変更管理、展開はリリース管理、実態の把握は構成管理」。この1行と、稼働率＝MTBF÷（MTBF＋MTTR）という1本の公式、そして「分母は合意したサービス時間帯」という注意点。これだけで出題の大半に手が届きます。

事業会社でIT統制の責任を負っていた立場から振り返ると、この分野の本質は「属人的な頑張りを、仕組みに置き換えること」にあります。障害が起きたときに誰が対応するか、どこまで戻せばよいのか、誰が承認するのか。これらが決まっていない組織では、同じ障害のたびに同じ議論が繰り返され、対応時間は担当者の熟練度に依存します。SLAで水準を合意し、プロセスで役割を分け、CMDBで実態を持つというのは、その依存を減らす作業です。

新卒エンジニアにインフラを教えていた頃の実感として、運用の用語は暗記しようとすると混ざりますが、「誰が困っていて、何を優先するのか」という順に考えれば自然に整理できます。利用者が困っている今この瞬間を助けるのがインシデント管理、同じ困りごとを二度と起こさないようにするのが問題管理、その修正を安全に本番へ届けるのが変更管理とリリース管理、届けた結果を正しく記録するのが構成管理です。この物語の順番で覚えておけば、選択肢を見た瞬間に判断できます。

次回はマネジメント系の最終回、第10回としてシステム監査を扱います。今回学んだプロセスが「定めたとおりに運用されているか」を、独立した立場で確かめる仕組みです。監査の目的と手順、監査証拠と監査調書、内部統制とITガバナンスの関係が中心になります。SC試験の午後でも、統制の不備を指摘する形で登場する分野です。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• IPA 試験要綱・シラバスについて
• IPA 情報処理技術者試験 過去問題
• 日本産業標準調査会 JIS検索（JIS Q 20000-1 サービスマネジメントシステム要求事項）
• Axelos ITIL（英語）
• IPA 「情報処理安全確保支援士試験（レベル4）」シラバス（Ver.2.1）