サービスマネジメント

このページでは、JIS Q 20000-1とSMSの運用、SLA、インシデント管理と問題管理の違い、変更管理と移行方式、ITILとサービスデスクがわかります。

• 一言で言うと：
  • 作ったシステムを「サービス」として、止めずに、約束どおりに提供し続けるための管理の話
  • ルールブック（JIS Q 20000-1）と、ベストプラクティス集（ITIL）が出てくる
  • 用語が多く、午前によく出る節

ルールの全体像（JIS Q 20000-1）→ 運用の中身（SMSの運用）→ ベストプラクティス集（ITIL）

覚え方の軸

• JIS Q 20000-1の7つの箇条は、PDCAに割り振られている
  • ①〜④がPlan、⑤運用がDo、⑥パフォーマンス評価がCheck、⑦改善がAct
• ⑤運用の中身は「何を → 誰と約束し → いくらで、どれだけ → どう変え → どう直し → どう守るか」の順
  • サービスポートフォリオ（何を提供するか）
  • 関係及び合意（誰と約束するか。SLA）
  • 供給及び需要（お金と量）
  • サービスの設計、構築及び移行（変える）
  • 解決及び実現（直す）
  • サービス保証（守る）
• トラブル対応は4つのリレー
  • インシデント管理で、まず元に戻す
  • 問題管理で、根本原因をつぶす
  • 変更管理で、直し方を安全に決める
  • リリース及び展開管理で、本番に入れる
• 移行方式は「速さとコスト」と「安全さ」のトレードオフ
  • 一斉移行は速いが危険、並行運用移行は安全だが高い
  • その間の順次移行とパイロット移行は、問題を一部に閉じ込める
• ITILは版によって切り口が違う
  • v3はライフサイクル（戦略 → 設計 → 移行 → 運用 → 継続的改善の5段階）
  • ITIL4はプラクティス（34個を3種類に分ける）

前置き：サービスマネジメントとは

• サービスマネジメント：
  • ITサービスを作る4つのPを上手に組み合わせて、ITサービスを提供し、管理し、維持すること
• 4つのP：
  • People（人材）、Process（プロセス）、Product（技術やツール）、Partner（サプライヤ・ベンダ・メーカ）

JIS Q 20000-1:2020：サービスマネジメントのルールブック

• SMS（サービスマネジメントシステム）：
  • 自社のサービスに合ったサービスマネジメントの仕組みを作り、管理し、維持するための体系的な仕組み
• JIS Q 20000-1（サービスマネジメントシステム要求事項）：
  • SMSを作り、実施し、維持し、継続的に改善するために、組織に求められることを定めた規格
  • ISO/IEC 20000:2018をもとにしたJIS
• JIS Q 20000の部編成：
  • -1が要求事項
  • -2が適用の手引き

PDCA	箇条	中身
Plan（計画）	①組織の状況 ②リーダーシップ ③計画 ④SMSの支援	SMSの計画を作り、運用に必要な知識などを決める
Do（実行）	⑤SMSの運用	実際にサービスを提供する（中身は後述）
Check（評価）	⑥パフォーマンス評価	SMSの結果や成果を確認する
Act（改善）	⑦改善	不適合への対応、是正処置、継続的改善

• 是正処置（試験に出る）：
  • 見つかった不適合や望ましくない状況の原因を取り除く、または再発しにくくするための処置
• 継続的改善（試験に出る）：
  • パフォーマンスを上げるために繰り返し行う活動
• 注意（新しい情報）：
  • 2025年8月にJIS Q 20000-1:2025（ISO/IEC 20000-1:2018の追補1:2024に対応）が発行された
  • ISOのマネジメントシステム規格に共通で、「組織の状況」に気候変動が関係する課題かどうかを判断する、という趣旨の追加が入ったもの
  • 7つの箇条やPDCAの構成は変わらないので、上の内容で覚えてよい

サービスマネジメントシステム（SMS）の運用：⑤の中身

• ⑤運用の7つの細分箇条：
  • 運用の計画及び管理／サービスポートフォリオ／関係及び合意／供給及び需要／サービスの設計、構築及び移行／解決及び実現／サービス保証

① サービスポートフォリオ：何を、何で提供するか

• サービスポートフォリオ：
  • サービスの要求事項、サービスに関わる関係者、サービス提供に使う資産などの管理に関する要求事項
• サービスの計画：
  • 既存・新規・変更するサービスの要求事項を決めて文書にする
  • 使える資源を考えて、変更要求や新サービスの優先度を決める
• サービスカタログ管理：
  • 提供するサービス、その成果、サービス間の依存関係を書いたサービスカタログを作り、維持する
  • 顧客や利用者が、サービスカタログの必要な部分を見られるようにする
• 資産管理：
  • サービスに使っている資産を確実に管理する
• 構成管理：
  • サービスを構成する要素（CI：構成品目）の種類を定義し、その構成情報を管理する
  • 構成情報の正確さを定期的に確かめ、欠陥があれば処置する
  • CIの変更は追跡・検証できるようにし、変更を展開したら構成情報を更新する
• CMDB（構成管理データベース）：
  • 構成情報を管理するデータベース
• SBOM（ソフトウェア部品表）：
  • ソフトウェアを作っている全部品（OSSなど）、その依存関係、ライセンスを一覧にした、機械で処理できるリスト
  • あるOSSに脆弱性が見つかったとき、自社ソフトへの影響をすぐ調べられる

② 関係及び合意：誰と、何を約束するか

• 関係及び合意：
  • 顧客との関係管理、サービスレベル管理（SLM）、供給者（外部・内部）との関係管理に関する要求事項
• SLMの主な決まり：
  • サービスごとに、1つ以上のSLA（サービスレベル合意書）を顧客と合意する
  • SLAには、サービスレベル目標、作業負荷の限度、例外を含める
  • 決まった間隔で、目標に照らして実績を監視・レビュー・報告する
  • 目標が達成できていなければ、改善の機会を見つける
• SMART：
  • SLAの良い目標値の条件
  • 具体的（Specific）、測定可能（Measurable）、達成可能（Achievable）、適切（Relevant）、期限がある（Time-bound）
• OLA：
  • SLAを実現するために、サービス提供者の内部で結ぶ合意
  • SLAは顧客と、OLAは社内の別部門と結ぶ

③ 供給及び需要：いくらで、どれだけ提供できるか

• サービスの予算業務及び会計業務：
  • 予算を立て、決まった間隔で実際の費用と比べて監視・報告し、費用を管理する
• 需要管理：
  • 今の需要を把握し、将来の需要を予測する
  • 需要と消費を監視・報告する
• 容量・能力管理（キャパシティ管理）：
  • 需要管理と連携して、必要な容量・能力を決めて計画する
  • 使用状況を監視・分析し、パフォーマンスを改善する機会を見つける
• 容量・能力管理の指標：
  • CPU使用率、メモリ使用率、ディスク使用率、ネットワーク使用率、応答時間など
• TCO（総所有費用）（試験に出る）：
  • 導入費用だけでなく、運用管理まで含めた総コスト
• 逓減課金方式（試験に出る）：
  • 使えば使うほど、1単位あたりの料金が段階的に安くなる課金方式
  • 累計の料金グラフは、だんだん傾きがゆるやかになる

④ サービスの設計、構築及び移行：どう変えるか

• 変更管理の方針：
  • 何を変更管理の対象にするかを決める
  • 標準変更・通常変更・緊急変更などの分類と、それぞれの扱い方を決める
  • 顧客やサービスに重大な影響を与える変更かどうかの判断基準を決める
• 変更管理の開始：
  • RFC（変更要求）を記録・分類する
  • 「サービスの設計及び移行」と「変更管理の活動」のどちらで扱うかを決める
  • 顧客に重大な影響がある新規サービス・変更・廃止は、「サービスの設計及び移行」で扱う
• 変更管理の活動：
  • リスク・事業利益・実現可能性・財務影響を考えて、RFCを承認し、優先度を決める
  • 承認した変更を計画・構築・試験する
  • 失敗したときに元に戻す（切り戻し）か修正する活動も、計画・試験しておく
  • 試験した変更を、リリース及び展開管理に送る
• RFC（変更要求）：
  • サービス、サービスの部品、SMSに対する変更の提案
• CAB（変更諮問委員会）：
  • 重大な変更のRFCを分析・評価し、優先度や実施の許可を決める
  • メンバーは変更の内容によって柔軟に変える
• サービスの設計及び移行：
  • 新規サービスやサービス変更を計画する
  • 要求事項を満たすように設計し、文書にする（SLAやサービスカタログも新設・更新する）
  • 構築して、サービス受入れ基準を満たすか試験し、リリース及び展開管理に送る
• サービス受入れ基準：
  • サービスが要求事項を満たしているか、展開したときに運用できる状態か、を確かめる基準
• リリース及び展開管理：
  • 新しいサービスや変更を、本番環境（稼働環境）に展開する
  • サービスの完全性を保つように計画して展開する

新システムへの移行

• 移行計画：
  • 移行方法・手順・体制などを決めた、綿密な切替えの計画
• 移行テスト（移行リハーサルともいう）：
  • 移行の手順が確実かつ効率的か、事前に確かめるテスト
• 移行の対応計画：
  • 問題が起きたときに、やり直すのか、旧システムに切り戻すのか、その判断基準を含めて事前に作っておく
• UAT（ユーザー受入れテスト、検収テスト）：
  • 完成したシステムが、合意した要件を満たすかを確かめるテスト
  • 本番環境か、ステージング環境で行う
• ステージング環境（準本番環境）：
  • 本番とほぼ同じ構成で、リリース前の最終テストを行う環境
• 移行方式の決め方：
  • コストや手間、移行期間、問題が起きたときの戻しやすさに一長一短があるので、システムの規模・複雑さ・重要度で決める

方式	やり方	長所	短所
一斉移行	全部を一度に移す	移行期間が短い	不具合があると影響が大きい。新システムに高い信頼性が必要
順次移行（部分移行、段階的移行）	サブシステムや拠点ごとに順番に移す	問題をそのサブシステム内に抑えられる	移行が終わるまで新旧を並行して動かす必要がある
並行運用移行	新旧両方を同時に動かしながら移す	問題が起きても業務への影響が最小	新旧両方のリソースが重複して必要（高い）
パイロット移行	限られた部門で試しに移し、評価してから全部門を移す	問題の影響を局所化できる	（全体の移行までに時間がかかる）

⑤ 解決及び実現：どう直すか（★インシデントと問題の違いがよく出る）

• インシデント管理：
  • 目的は、サービスを早く元に戻すこと。原因究明はしない
  • 記録・分類し、影響と緊急度から優先度を決め、必要ならエスカレーションして解決する
  • 重大なインシデントは決めた手順で扱い、トップマネジメントに通知する
  • 解決策が不明なときは、ワークアラウンド（回避策）を示す
• サービス要求管理：
  • 利用者からのお願いに応える
  • 記録・分類・優先度付けをして実現する
• 問題管理：
  • 目的は、根本原因を見つけて再発を防ぐこと
  • インシデントのデータや傾向を分析して、根本原因を探る
  • 問題を解決するための変更は、変更管理の方針に従う
  • 恒久的に解決できていないときは、影響を減らす処置を決める
  • 既知の誤りを記録し、他の活動でも使えるようにする
• インシデント：
  • サービスの計画外の中断や品質の低下、または、まだサービスに影響していない事象
• サービス要求：
  • 利用者がIT部門に出すいろいろな要求
  • 例えば、パスワードの変更や、仮想サーバの貸出
• 問題：
  • 1つ以上のインシデントの（実際の、または潜在的な）原因
• 既知の誤り：
  • 根本原因がわかっている、または影響を減らす方法がある問題
• 既知のエラーDB：
  • 既知の誤りを記録するデータベース
• ワークアラウンド：
  • 根本的な解決ではない、その場の回避策
  • 例えば、ある入力操作が拒否されるなら、別の入力操作を教える
• エスカレーション（段階的取扱い）：
  • 自分で解決できない案件を、他の人に任せること。2種類ある
• 機能的エスカレーション：
  • より専門知識のあるスタッフに任せる（横に渡す）
• 階層的エスカレーション：
  • 時間内に解決できないとき、より権限のある上の人に任せる（上に渡す）
• トラブル対応のリレーの例え：
  • 水漏れなら、バケツを置いて元栓を閉めるのがインシデント管理
  • 配管が古いと突き止めるのが問題管理
  • 配管の交換を決めるのが変更管理
  • 交換工事をするのがリリース

⑥ サービス保証：どう守るか

• サービス保証：
  • サービスの可用性と継続、情報セキュリティの管理に関する要求事項
• サービス可用性：
  • 合意した時点や期間に、求められた機能を実行できる能力
  • 合意した時間のうち、実際に使えた時間の割合で表す
• 例題（可用性）：
  • 合意したサービス時間が月720時間で、止まったのが7.2時間なら、（720 − 7.2）÷ 720 ＝ 99%
• サービス継続：
  • サービスを中断せずに、または合意した可用性で提供し続ける能力
• サービス可用性管理：
  • 決まった間隔で、可用性のリスクを評価する
  • 可用性の要求事項と目標を決め、監視して目標と比べる
  • 計画外の停止は調査して処置する
• サービス継続管理：
  • 決まった間隔で、継続のリスクを評価する
  • サービス継続計画を作って維持する
  • 決まった間隔や、大きな環境変化があったときに、計画を再試験する
• サービス継続計画に含めること：
  • 発動の基準と責任
  • 重大な停止のときの手順
  • 発動中の可用性の目標
  • 復旧の要求事項
  • 平常業務に戻る手順
• 情報セキュリティ管理：
  • 情報セキュリティ方針、管理策、情報セキュリティインシデントについて定める
• BCP（事業継続計画）：
  • 事業が中断したときに、事業を再開・復旧する方法をまとめた計画
  • BIAの結果をもとに作り、経営環境や業務の変化に合わせて適時に見直す
• BCM（事業継続管理）：
  • BCPを作るところから、継続的に改善するところまでを含む管理
  • サービス継続管理はBCMの一部
• BCPとサービス継続計画の違い：
  • BCPは、地震などの大規模災害を想定することが多い
  • サービス継続計画では、もっと局所的・小規模なリスクも考える
• BIA（ビジネスインパクト分析、事業影響度分析ともいう）：
  • 災害や事故で主要な業務が止まったときの影響度を、分析・評価する手法
• BIAの手順：
  1. 起こり得るリスクや脅威を洗い出す
  2. 業務や経営資源の弱点を分析し、事業継続に大きく影響する重要な要素を特定する
  3. その要素の最大許容停止時間や被害額を算定する
• レジリエンス（回復力）：
  • 不測の事態から素早く回復し、正常な状態に戻す能力

ITIL：サービスマネジメントのベストプラクティス集

• ITIL：
  • 世界で事実上の標準（デファクトスタンダード）になっている、サービスマネジメントのフレームワーク
• ITILの版の順番：
  • ITIL v2 → ITIL v3 → ITIL 2011 edition（v3の更新版）→ ITIL4
  • ITIL4の後継として、ITIL (Version 5) も発表されている（下の注意を参照）
• ITIL v3・2011 edition：
  • サービスのライフサイクル（戦略、設計、移行、運用、継続的サービス改善）で整理している

段階	中身
①サービスストラテジ	ITサービスと、その管理の全体的な戦略を決める
②サービスデザイン	戦略をもとにサービスを設計する
③サービストランジション	サービスのリリースや変更を行う（移行）
④サービスオペレーション	SLAに従ってサービスを提供する（運用）
⑤継続的サービス改善	①〜④のそれぞれを改善して、サービスの価値を保ち、高める

• ITIL4：
  • デジタル時代の新しい働き方を取り入れるための支援基盤となるフレームワーク
  • 「業務の遂行や目的達成のために作られた組織の資源のまとまり」として、プラクティスを定めている（合計34個）
  • 会社全般の仕事が「一般」、ITサービスの仕事が「サービス」、技術そのものの仕事が「テクニカル」と覚える
• 一般マネジメントプラクティス（14個）：
  • 戦略管理、ポートフォリオ管理、サービス財務管理、関係管理、サプライヤ管理、ナレッジ管理、情報セキュリティ管理、継続的改善、アーキテクチャ管理、リスク管理、組織変更管理、プロジェクト管理、労働力と人材の管理、測定と報告
• サービスマネジメントプラクティス（17個）：
  • サービスレベル管理、可用性管理、サービスカタログ管理、サービス構成管理、サービス継続性管理、サービス要求管理、サービスの妥当性確認とテスト、変更コントロール、リリース管理、キャパシティとパフォーマンス管理、モニタリングとイベント管理、インシデント管理、問題管理、サービスデスク、事業分析、サービスデザイン、IT資産管理
• テクニカルマネジメントプラクティス（3個）：
  • インフラストラクチャとプラットフォーム管理、展開管理、ソフトウェアの開発と管理
• 注意（新しい情報）：
  • 2026年1月にITIL (Version 5)が発表された（日本語のファンデーション試験は2026年5月から）
  • ITIL4の置き換えではなく「進化版」の位置づけ。デジタルプロダクトとサービスを一体で管理することや、AIへの対応が加わった
  • 試験は当面ITIL4までの内容で問われると考えられる。「最新はVersion 5」とだけ知っておく
• サービスデスク：
  • 利用者からの問合せ、クレーム、障害報告などを受ける単一の窓口（SPOC）
  • 適切な部署へ引き継ぎ、対応結果を記録・管理する
• WFM（ワークフォースマネジメント）：
  • 過去の実績から今後を予測し、必要な人数を配置して、サービス品質と人件費の抑制を両立させる考え方
  • サービスデスクで導入されることがある

形態	置き方	長所
中央サービスデスク	1拠点か少数の場所に集中	要員を効率よく配置でき、大量の電話に対応できる
ローカルサービスデスク	利用者の近くに置く	言語や文化の違いへの対応、VIP対応ができる
バーチャルサービスデスク	要員は分散しているが、通信技術で1つの窓口に見せる	場所に縛られない
フォロー・ザ・サン	時差のある拠点に置き、リレーする	24時間対応できる

混同しやすいペア

• インシデント管理 ／ 問題管理 ／ サービス要求管理
  • インシデント管理は、早く元に戻す。原因は追わない
  • 問題管理は、根本原因をつぶし、再発を防ぐ
  • サービス要求管理は、利用者のお願いに応える
• インシデント ／ 問題 ／ 既知の誤り
  • インシデントは、中断や品質低下という出来事
  • 問題は、インシデントの原因
  • 既知の誤りは、原因か回避策がわかっている問題
• 変更管理 ／ リリース及び展開管理
  • 変更管理は、変更を承認し、計画・試験する
  • リリース及び展開管理は、本番環境に展開する
• 機能的エスカレーション ／ 階層的エスカレーション
  • 機能的は、専門家へ渡す（横に渡す）
  • 階層的は、権限のある人へ渡す（上に渡す）
• SLA ／ OLA
  • SLAは、顧客との合意
  • OLAは、社内での合意
• 資産管理 ／ 構成管理
  • 資産管理は、使っている資産そのものを管理する
  • 構成管理は、CIとその構成情報を管理する（CMDB）
• 需要管理 ／ 容量・能力管理
  • 需要管理は、どれだけ使われるかを見る
  • 容量・能力管理は、どれだけ提供できるかを見る
• 一斉移行 ／ 並行運用移行 ／ 順次移行 ／ パイロット移行
  • 一斉移行は、速いが危険
  • 並行運用移行は、安全だが高い
  • 順次移行は、サブシステムや拠点ごとに移す
  • パイロット移行は、一部の部門で試してから移す
• サービス可用性 ／ サービス継続
  • サービス可用性は、使える時間の割合
  • サービス継続は、中断せずに提供し続ける能力
• BCP ／ BCM ／ BIA
  • BCPは、事業継続の計画
  • BCMは、計画を含む管理全体
  • BIAは、影響度の分析。BCPの前に行う
• 中央 ／ ローカル ／ バーチャル ／ フォロー・ザ・サン
  • 中央は、集中させる
  • ローカルは、利用者の近くに置く
  • バーチャルは、分散しているが1つの窓口に見せる
  • フォロー・ザ・サンは、時差のある拠点で24時間対応する
• ITIL v3 ／ ITIL4
  • ITIL v3は、ライフサイクルの5段階
  • ITIL4は、34のプラクティス
• 是正処置 ／ 継続的改善
  • 是正処置は、原因を取り除いて再発を防ぐ
  • 継続的改善は、繰り返し良くする

---

← 10 プロジェクトマネジメント・サービスマネジメントの目次に戻る