サービスマネジメント

1. サービスマネジメントの全体像 ― SMS の PDCA と改善

サービスマネジメントの目的は、サービスを通じて顧客に価値を届けることです。IPA 応用情報技術者試験 シラバス Ver.7.2 は、サービスマネジメントを「価値を提供するため、サービスの計画立案、設計、移行、提供及び改善のための組織の活動及び資源を、指揮し、管理する、一連の能力及びプロセス」と定義しています。ここに並ぶ計画立案・設計・移行・提供・改善の 5 語がサービスライフサイクルの段階で、本章の節の並びもおおむねこの順序です。

登場人物を先に固定しておきます。サービスを提供する側がサービス提供者、対価を払って受け取る側が顧客、実際に画面を触る人が利用者、提供者へ部品や役務を納める側が供給者です。顧客と利用者が別組織になること（情報システム部門が顧客、現場社員が利用者）は普通にあり、科目 B ではこの区別が設問の前提になります。サービスを構成する部品（ハードウェア・ソフトウェア・要員・文書など）はサービスコンポーネント、要求事項に対する充足度がサービス品質です。

JIS Q 20000 と SMS の PDCA

SMS（サービスマネジメントシステム、Service Management System）は、サービスマネジメントを回すための仕組み一式（方針・目的・計画・プロセス・資源・文書化した情報）を指します。その要求事項を規定した規格が JIS Q 20000-1 で、ISO/IEC 20000 シリーズに対応する規格群です。-1 が要求事項（認証の基準）、-2 が適用の手引という役割分担です。認証を受けるのは組織であって、製品や個人ではありません。

SMS は PDCA（Plan-Do-Check-Act）で回します。科目 A はこの 4 段階のうちどの段階の説明かを選ばせます。特に Do は「サービスの設計、移行、提供及び改善のために SMS を導入し、運用する」で、直近 10 年では 2 回、正解肢の文言までほぼ同一で出題されています（いずれも設問が JIS Q 20000-1:2012 と版を明示しています。現行の JIS Q 20000-1:2020 はマネジメントシステム規格共通の上位構造を採用し、PDCA の図と記述そのものを削除しているので、実務では箇条 4〜10 で読み替えます）。図 16-1 で、この章の各節が PDCA のどこに載るのかを確認してください。

パフォーマンス評価 ― Check で何をするか

Check は 2 つの活動に分かれます。監視・測定・分析及び評価は、サービスマネジメントの目的に照らして SMS のパフォーマンスと有効性を評価し、サービスの要求事項に照らしてサービスの有効性を評価する活動です。サービスの報告は、報告の要求事項と目的を決め、SMS とサービスのパフォーマンス・有効性に関する報告を作る活動で、単発の数値ではなく傾向情報を含めることが求められます。これらに加えて内部監査とマネジメントレビュー（トップマネジメントによる見直し）が Check に置かれます。監査の詳細は第 17 章の担当です。

改善 ― 直近 3 年の最重要ポイント

JIS Q 20000-1 の「改善」の章は、直近 3 年で 3 回連続して出題されています（継続的改善の定義・改善処置の考え方・改善の機会に適用する評価基準）。狙われるのは似た 4 語の弁別です。表のとおり、境目は「症状だけを消したか／原因を取り除いたか／まだ起きていないことに備えたか」です。

継続的改善では、改善の機会に適用する評価基準を決めます。この基準には SMS の目的との整合性を含めることが求められており、R6 秋にこの点が問われました。改善案を「工数が小さいから」だけで選ぶのではなく、SMS の目的に沿うかどうかで優先順位を付けるという趣旨です。改善を測る道具として、CSF（Critical Success Factors、重要成功要因）＝目的を達成するために欠かせない条件、KPI（Key Performance Indicator、重要業績評価指標）＝CSF の達成度を測る先行指標（結果を示すアウトプット KPI は遅行指標に当たり、KPI すべてが先行指標とは限りません）、KGI（Key Goal Indicator、重要目標達成指標）＝最終的な目標値そのもの、という 3 段の関係を押さえます。プロセスの成熟度を段階で測るのがプロセス能力水準（プロセス成熟度水準）とプロセスアセスメント、あるべき姿と現状の差を洗い出すのがギャップ分析です。

ITIL ― フレームワークとしての語彙

ITIL（Information Technology Infrastructure Library）は、サービスマネジメントの実践知をまとめた事実上の標準です。規格である JIS Q 20000-1 が「何を満たすべきか」を書くのに対し、ITIL は「どう進めるか」を書きます。科目 A では ITIL 2011 edition の用語定義が直近 10 年で 4 回出題されました（最後は R3 春で、それ以降は 0 回）。頻出は次の包含関係です。

ITIL 2011 のライフサイクルはサービスストラテジ → サービスデザイン → サービストランジション → サービスオペレーションの 4 段階を、継続的サービス改善（CSI）が取り巻く 5 段階構成です。CSI の 7 ステップの改善（ITIL 4 では「継続的改善モデル」に置き換わっています）は「① 改善戦略の識別 → ② 測定対象の定義 → ③ データの収集 → ④ データの処理 → ⑤ 情報とデータの分析 → ⑥ 情報の提示と利用 → ⑦ 改善の実施」で、R1 秋は④〜⑥の順序（処理 → 分析 → 提示）が空欄補充で問われました。「集めた生データをまず使える形に整え、分析してから見せる」という順序で覚えます。

最新版の ITIL 4 では、ライフサイクル 5 段階に代えてサービスバリューシステム（SVS）という全体像を置き、その中核に 6 つの活動（計画・改善・エンゲージ・設計及び移行・取得／構築・提供及びサポート）からなるサービスバリューチェーン（SVC）を据えます。従来「プロセス」と呼んでいた個々の管理活動はプラクティスという名前になりました。応用情報の出題は JIS Q 20000-1 のプロセス名（インシデント管理・問題管理など）で書かれるので、ITIL 4 は用語の存在を知っておく程度で足ります。

2. SLA とサービスレベル管理 ― 誰と何を合意するか

SLA（Service Level Agreement、サービスレベル合意書）は、サービスとその合意されたパフォーマンスを特定した、組織と顧客との間の合意文書です。「顧客との合意文書」という一点が定義の核で、社内の運用部門と結ぶ取決めや外部委託先との契約は SLA とは呼びません。相手が誰かで名前が変わるところを図 16-2 で押さえます。

社内の運用部門やデータセンタ部門は内部供給者で、ここと結ぶ取決めが OLA（Operational Level Agreement、運用レベル合意書）です。外部委託先やクラウド事業者は外部供給者で、こちらは契約を結びます。ITIL ではこの契約を SLA を下支えするものという意味で UC（Underpinning Contract、基盤となる契約）と呼びます。SLA で「4 時間以内に復旧」と顧客に約束するなら、内部供給者の OLA と外部供給者の契約はそれより短い目標になっていなければ約束が守れません。この整合を取るのが供給者管理の仕事です。

SLA に載せるサービスレベル項目

SLA に何を書くかは決まっています。過去問はここから「適切なレベル項目の組合せ」を選ばせ、科目 B は「この SLA に足りない項目は何か」を書かせます。

関連する 3 つの略語を整理します。SLI（Service Level Indicator、サービスレベル指標）は「何を測るか」、SLO（Service Level Objective、サービスレベル目標）は「その指標をいくつにするか」、SLAは「その目標を顧客と合意し、未達のときどうするかまで文書化したもの」です。たとえば SLI が「月間の正常応答率」、SLO が「99.9% 以上」、SLA が「99.9% を下回った月は利用料の 10% を減額する」という関係になります。

ペナルティ（減額）の計算

SLA には未達時の措置を書きます。多いのは利用料の減額（サービスクレジット）で、未達の幅に応じた区分表が付きます。計算自体は単純ですが、どの区分に入るかの判定で落とします。

サービスレベル管理と隣接プロセスの弁別

サービスレベル管理は直近 10 年で 4 回出題され、正解肢は 2 パターンしかありません。ひとつは「顧客と提供するサービスについて SLA を合意する」、もうひとつは「あらかじめ決められた間隔で、サービスレベル目標に照らしたパフォーマンスと実績の周期的な変化を監視・レビュー・報告する」です。「あらかじめ定めた間隔で」という言い方が出たらこのプロセスだと判断できます。誤答肢は隣のプロセスの活動をそのまま置いてきます。

クラウド利用と責任分界

供給者管理の用語例には SaaS・PaaS・IaaS が入っています。ここは「クラウドへ移行するとどの運用作業が不要になるか」という読解型で直近 10 年に 2 回、しかも正解肢まで同一で出題されました。図 16-3 の境界線の位置を覚えるだけで確実に取れます。

3. サービス可用性管理と稼働率の計算

サービス可用性管理は、可用性のリスクをアセスメントし、要求事項と目標を決め、可用性を監視して結果を記録し目標と比較し、計画外のサービス可用性の喪失を調査して処置をとるプロセスです。「計画外の」という限定が入っているのがポイントで、計画停止は調査対象ではありません。可用性の計算は直近 10 年で 4 回出題され、この中分類の計算問題の柱です。

まず用語を層別します。信頼性は「壊れにくさ」、保守性は「直しやすさ」、可用性は「使える割合」で、この 3 つが別の指標で測られることが問われます（直近 10 年で 2 回）。冗長構成の組み方や直列・並列の稼働率計算は第 5 章の担当なので、本章はサービスから見た指標と SLA との結び付きに絞ります。単一障害点（SPOF：Single Point Of Failure）を洗い出して冗長化するのが可用性設計の基本で、これも第 5 章を参照してください。

可用性管理の KPI として問われるのは「サービスの中断回数及びインパクトの削減率」です。「稼働率」そのものではなく、中断を減らせているかという改善の度合いを測るところが選択のポイントになります。

稼働率の計算 ― 分母は合意サービス時間

計算で落ちる原因はほぼ 2 つです。分母を暦時間にしてしまうことと、計画停止（メンテナンス）を停止時間に足してしまうことです。図 16-4 で帯の関係を見てください。

4. インシデント管理・サービス要求管理・問題管理

問題管理はこの中分類の最頻出テーマで、直近 10 年に 5 回出題されています（うち 4 回が R3 以降）。しかも正解肢は「根本原因を特定する」「再発を防止する恒久的な解決策を決める」「インシデントのデータ及び傾向を分析する」の 3 通りしかありません。誤答肢はインシデント管理（迅速な復旧・回避策）や変更管理・構成管理の活動を混ぜてきます。つまりプロセスの役割分担が言えれば取れる 1 問です。

インシデントとは、サービスに対する計画外の中断、サービスの品質の低下、または顧客・利用者へのサービスに影響していない事象です。「影響していない事象」も含む点が定義の特徴で、冗長構成の片系が落ちてサービスは継続している状態もインシデントに当たります。インシデント管理の対応手順は次の 5 段階です。

1. 記録し、分類する（あとで傾向分析に使うため、対応しながら必ず残す）
2. 影響及び緊急度を考慮して優先順位付けをする
3. 必要であればエスカレーションする
4. 解決する（根本原因が分からなくても、回避策で使える状態に戻せば解決）
5. 終了する（利用者に回復を確認してから閉じる）

優先度は影響度（何人・どの業務が止まるか）と緊急度（どれだけ早く直す必要があるか）の組合せで決めます。この 2 語のどちらかだけで決めると、「影響は小さいが締切直前で緊急」という案件を取りこぼします。よく起きるインシデントの対応手順を型として登録したものがインシデントモデルです。重大なインシデントについては、それを特定する基準をあらかじめ決め、文書化された手順に従って分類・管理し、トップマネジメントに通知することが求められます。

サービス要求管理は、障害ではない定型的な依頼（アカウントの発行、パスワードの再発行、機器の貸出しなど）を扱います。手順はインシデントと似て「記録・分類 → 優先順位付け → 実現 → 終了」ですが、解決ではなく実現という言葉を使うところが違います。実現に関わる要員が使える指示書を用意しておくのがこのプロセスの要求事項です。

インシデント管理と問題管理の役割分担

2 つのプロセスは目的が違うので同時に走ります。インシデント管理は「早く戻す」、問題管理は「二度と起こさない」。この分担を図 16-5 で確認してください。

エスカレーションの 2 方向

エスカレーションには 2 種類あり、科目 B ではどちらを行うべきかを書かせます。機能的エスカレーションはより高い技術力や権限をもつ別の担当・部署へ横に渡すこと、階層的エスカレーションは上位の管理者へ縦に上げることです。判断基準は、技術的に手が足りないなら機能的、解決目標時間を超えそう・重大なインシデントである・顧客への通知や資源投入の判断が要るなら階層的です。

5. 変更管理とリリース及び展開管理

変更管理は、直近 10 年の科目 A で正解テーマとして1 度も出ていません。しかし科目 B のサービスマネジメント問では直近 10 年に 6 回題材になっており（RFC の優先度、CAB の構成員、切り戻し計画、PIR の理由など）、放置できないプロセスです。科目 A 対策としては流れを 1 度たどれば十分、科目 B を選ぶなら各段階で何を決めるかまで押さえます。

変更管理方針では、変更管理が扱うサービスコンポーネントと他の品目、緊急の変更を含む変更のカテゴリと管理の方法、そして顧客又はサービスに重大な影響を及ぼす可能性のある変更を判断する基準を定義します。次に変更管理の開始で、サービスの追加・廃止・変更の提案を含む変更要求（RFC：Request For Change）を記録・分類し、この変更を「サービスの設計及び移行」で管理するか「変更管理の活動」で管理するかを決めます。大がかりな新規サービスは前者、既存サービスの手直しは後者という振り分けです。

変更管理の活動は、① 変更要求の優先度を決定する、② リスク・事業利益・実現可能性・財務影響を考慮して変更要求を承認する、③ 承認された変更を計画・開発（構築）・試験する、④ 成功しなかった変更を戻す又は修正する活動を計画し、可能であれば試験する、⑤ 試験された変更をリリース及び展開管理に送り稼働環境に展開する、の 5 つです。④ を落とすと「展開計画に何が欠けているか」という科目 B の定番設問を取れません。承認を審議する会議体が CAB（Change Advisory Board、変更諮問委員会）で、IT 部門だけでなく影響を受ける業務部門の代表を入れるのが原則です。展開後の振り返りが PIR（Post Implementation Review、変更実施後レビュー）です。

サービスの設計及び移行／リリース及び展開管理

新規サービスや大きなサービス変更は、計画 → 設計 → 構築及び移行の順に進みます。設計ではサービス受入れ基準と非機能要件を明確にし、サービス設計書にまとめ、あわせて SLA・サービスカタログ・契約書の新設や更新を行います。構築及び移行では、設計に適合する構築を行い、受入れ基準を満たすことを検証するために試験します。移行に固有の用語は次のとおりです。

リリース及び展開管理は、新規サービス・サービス変更・サービスコンポーネントを稼働環境へ展開することを計画し実施します。あわせてリリースの成功又は失敗を監視し、分析結果をレビューして改善の機会を特定し、成功・失敗の情報と将来のリリース期日を他のサービスマネジメント活動が使えるようにします。リリースの受入れ基準、受入れ試験環境と稼働環境の分離、緊急リリースを含むリリースの種類の定義が要求事項です。

構成管理と資産管理 ― 変更管理の土台

構成管理は直近 10 年で 2 回出題されています。活動は「構成品目（CI：Configuration Item）を識別・記録・制御・追跡・検証し、サービスに関連する構成情報を管理する」ことで、記録先がCMDB（Configuration Management Database、構成管理データベース）です。定められた間隔で構成情報の正確性を検証する（構成監査）ことと、構成情報を他のサービスマネジメント活動が利用可能にすることが規格の要求事項です。CI を正確に把握できていれば、変更管理は影響範囲を、インシデント管理は影響を受ける利用者を、問題管理は同じ構成の他機器への波及を即座に判断できます。これが「構成管理は他のプロセスを支援する」という正解肢の意味です。

ある時点の構成を確定させて基準とするのが構成ベースライン、CI にどの識別子を付けるかを決めるのが構成識別、CI の改訂番号が版（バージョン）です。よく似た資産管理（ITAM：IT Asset Management）は、資産の取得から廃棄までを費用・契約・ライセンスの観点で管理するプロセスで、ソフトウェアに限った活動が SAM（Software Asset Management）とライセンスマネジメントです（関連規格は JIS X 0164 シリーズ。ただし同シリーズはソフトウェアに限らず IT 資産管理全般を対象とする規格です）。構成管理は「サービスを成り立たせている関係」を、資産管理は「持ち物としての価値と契約」を管理すると区別します。

6. 容量・能力管理／需要管理／予算業務及び会計業務

科目 A ではこの 3 プロセスの出題は合計 2 問（容量・能力管理 1 問、逓減課金方式 1 問）にとどまります。一方で科目 B のサービスマネジメント問はキャパシティと需要予測を題材に直近 10 年で 4 回、予算・会計を 3 回扱っています。用語の定義と計算の型を押さえるところまでで十分です。

需要管理は、あらかじめ定めた間隔で現在の需要を決定し、将来の需要を予測し、需要と消費を監視して報告するプロセスです。予測の材料は IT 部門の中にはありません。営業の販売計画、キャンペーンの実施予定、人事の採用計画、繁忙期のカレンダーといった事業部門の情報を定期的にもらう仕組みを作ることが、科目 B での定番の解答になります。

容量・能力管理（キャパシティ管理）は、資源の容量・能力の要求事項を決定し、需要に基づいて現在と予測の容量・能力を計画し提供するプロセスです。あわせて利用状況を監視し、容量・能力とパフォーマンスのデータを分析してパフォーマンス改善の機会を特定します。監視する管理指標は CPU 使用率・メモリ使用率・ディスク使用率・ネットワーク使用率が代表で、それぞれにしきい（閾）値を設定します。しきい値は「超えたら即障害」ではなく「増設の検討を始める合図」として、余裕をもった水準に置くのが実務です。

監視で上がるメッセージは、放置してよい情報、しきい値超過などの警告、即対応が必要な例外（エラー）に分類し、分類ごとに通知先と対応手順を決めます。この分類を怠ると、本当のエラーが大量の情報メッセージに埋もれます。運用の自動化を機械学習で支援する考え方が AIOps です。

サービスの予算業務及び会計業務

費用はサービスごとに予算化し、あらかじめ定めた間隔で予算に照らして実際の費用を監視・報告し、財務予測をレビューします。費用の性質による区分と、それを利用者にどう見せるかが問われます。

7. サービス継続管理 ― BCP と RTO・RPO・RLO

サービス継続管理は、サービス継続のリスクをアセスメントし、要求事項を決定してサービス継続計画を作成・実施・維持するプロセスです。計画は作って終わりではなく、あらかじめ定めた間隔、又はサービス環境に重大な変更があった場合に試験することが規格の要求事項です。この「重大な変更があったら試験し直す」が抜けた選択肢はよく作られます。

上位の枠組みがBCP（Business Continuity Plan、事業継続計画）で、事業全体をどう継続・復旧させるかを定めます。BCP を作って運用し見直す活動全体が BCM（Business Continuity Management）、BCP のうち IT サービスの部分を担うのがサービス継続計画（IT サービス継続計画）、災害からの復旧に絞った計画と体制が DR（Disaster Recovery、災害復旧）です。優先順位を決める分析が BIA（Business Impact Analysis、事業影響度分析）で、業務が止まったときの影響（売上・法令違反・信用失墜）を時間の経過に沿って評価し、どの業務を何時間以内にどのレベルまで戻すかを導きます。BIA の出力が、次に述べる 3 つの目標値です。

復旧の方式と段階的復旧

待機系をどこまで動かしておくかで、費用と復旧時間が交換関係になります。冗長構成の詳しい話は第 5 章の担当なので、ここではサービス継続の観点で整理します。

すべてを同時に元へ戻すのではなく、重要な業務から順に、限定した範囲で復旧していくのが段階的復旧です。RLO を「1 日以内に重要サービスに限定して復旧する」と定めるのがこの考え方で、R6 秋に問われました。バックアップ媒体を同一の被災圏の外に置く遠隔地保管と、遠隔地に用意した代替拠点である DR サイトも継続管理の手段です。データセンタの隣の倉庫に置いた媒体は、地震や水害では一緒に失われるため遠隔地保管になりません。

あわせて情報セキュリティ管理も SMS の一部として要求されます。情報セキュリティ方針、情報セキュリティ管理策、情報セキュリティインシデントに関する事項を実施するもので、ISMS の要求事項を規定する ISO/IEC 27000 シリーズ（要求事項そのものを規定するのは ISO/IEC 27001／JIS Q 27001 で、27000／JIS Q 27000 自体は概要・用語を扱う規格です）と連携させます。管理策の中身は第 11・12 章の担当です。この小分類は直近 10 年の科目 A では 0 問ですが、可用性とセキュリティを同時に問う科目 B の題材にはなり得ます。

8. サービスの運用 ― オペレーション・バックアップ・サービスデスク

ここが得点源です。運用オペレーション（バックアップ）で 6 問、システム運用管理で 5 問、サービスデスクで 2 問と、53 問のうち 13 問がこの節の範囲から出ています。しかも「差分バックアップ方式」は 3 回とも正解肢が同一、「媒体本数の計算」も 3 回とも同型の再出題です。ここを固めれば 1 問は計算できます。

システム運用管理と運用オペレーション

システム運用管理は、日常の運用計画、障害発生時運用の計画、運用負荷低減のための改善計画を立て、あわせて容量・能力管理／情報セキュリティ管理／サービス可用性管理／サービス継続管理の方針を受けた活動を実施することです。運用の資源管理は、設備・コンピュータシステム・データ・マニュアル・成果物・要員を、組織の目標に適合するように維持・運用する活動を指します。要員が資源に含まれるところが「シフト要員数の算出」という計算問題につながります。仮想環境は台数が容易に増えるため、構成管理と資源使用率の監視をより厳密に行う必要があります。

運用オペレーションは、定められた手順に沿ってシステムの監視・操作・状況連絡を行うことです。操作は必ず作業指示書に従い、判断が必要になったら手順書の範囲を超えずにエスカレーションします。主な内容は次のとおりです。

バックアップ方式 ― 差分と増分の違いが得点源

直近 10 年で 3 回、正解肢まで同一で問われるのは「フルバックアップで復元してから、最新の差分バックアップを反映して復旧する」です。図 16-9 で、取得量の増え方と復旧に使う媒体の数を並べて見ます。

サービスデスク

サービスデスクは、利用者からの問合せに対して単一の窓口機能（SPOC：Single Point Of Contact）を提供し、適切な部署への引継ぎ、対応結果の記録、記録の管理を行う一連の活動です。窓口を 1 つにすることで、利用者が「どこに聞けばよいか」を考えずに済み、記録が 1 か所に集まって傾向分析ができるようになります。組織の構造は 4 類型が問われます。フォロー・ザ・サンは直近 10 年で 2 回出題されました。

サービスデスクの道具立ても用語で問われます。CTI（Computer Telephony Integration）は電話とコンピュータを連携させ、着信時に発信者の契約情報や過去の問合せ履歴を画面に出す仕組みです。FAQと知識ベースは、過去の問合せと回答を整理して利用者や担当者が引けるようにしたもので、AI を使ったチャットボットで自動応答させる構成も一般的になりました。指標としては、二次サポートへ回さずサービスデスクだけで解決できた割合が一次解決率、利用者が FAQ を見て自分で解決した割合が自己解決率です。FAQ を整備しても自己解決率が上がらないときは、内容の不足ではなく「探せない・更新されていない」ことが原因という筋で分析します。

9. ファシリティマネジメント

ファシリティマネジメントは、コンピュータシステムやネットワークの施設基盤の設計・構築の管理と運営を通じて、費用の削減・快適性・安全性を確保する活動です。直近 10 年での出題は少ない領域ですが、R6 春に GHG プロトコル、R7 秋に液浸冷却と、直近 3 年で環境側面と冷却技術が 2 問出ています。初出テーマは数年内に再出題される傾向があるので、定義と代表例だけは押さえておきます。

環境側面 ― グリーン IT と評価指標

地球環境に配慮した IT 製品・インフラの利用や、IT による環境負荷低減をグリーン IT と呼びます。評価の物差しが指標として問われます。

ひっかけポイント

この中分類の誤答肢は、作られ方が 6 通りしかありません。どれも「隣にある別のもの」と入れ替える手口です。

理解度チェック（科目 A 形式）

まとめ

本章のプロセスが「約束どおり回っているか」を第三者の立場で確かめるのが、次の第 17 章で扱うシステム監査と内部統制です。SLA・変更管理・アクセス権の記録が残っているかどうかが、そのまま監査証拠になります。