Huney

応用情報（AP） / マネジメント

サービスマネジメントとは？JIS Q 20000-1・SMS・ITILを基礎から理解しよう

ITサービスを継続的かつ安定して提供するためのサービスマネジメントについて、JIS Q 20000-1:2020、サービスマネジメントシステム（SMS）、サービスポートフォリオ、サービス保証、ITILなどを基礎から解説します。

読了時間：約15分
  • #サービスマネジメント
  • #JIS Q 20000-1
  • #SMS
  • #サービスポートフォリオ
  • #SLA
  • #インシデント管理
  • #サービス保証
  • #ITIL
  • #応用情報技術者試験

はじめに

システム開発では、

要件定義
 ↓
設計
 ↓
開発
 ↓
テスト
 ↓
リリース！

と、システムを完成させることが一つの大きな目標になります。

しかし、利用者にとっては、

リリースされたら終わりではありません。

むしろ、

システムを利用開始
        ↓
安定して使える？
        ↓
障害が起きたら？
        ↓
問い合わせには対応してくれる？
        ↓
性能は十分？
        ↓
サービスを改善できている？

と、そこからが本番です。

そこで重要になるのが、

サービスマネジメント（Service Management）

です。

今回は、

サービスマネジメント
│
├─ JIS Q 20000-1:2020
├─ サービスマネジメントシステム（SMS）
│
├─ サービスマネジメントの活動
│   ├─ サービスポートフォリオ
│   ├─ 関係および合意
│   ├─ 供給および需要
│   ├─ サービスの設計・構築・移行
│   ├─ 解決および実現
│   └─ サービス保証
│
└─ ITIL

という流れで学んでいきましょう。

1. サービスマネジメントとは

**サービスマネジメント（Service Management）**とは、

利用者に価値のあるサービスを、適切な品質で継続的に提供・管理するための活動

です。

例えば会社で、

社内メール
ファイル共有
勤怠管理
社内ネットワーク
クラウドサービス

などを提供しているとします。

システムが存在しているだけでは十分ではありません。

利用者からすれば、

必要なときに使える

十分な性能がある

障害が起きたら復旧する

問い合わせに対応してもらえる

データが安全に守られる

ことが重要です。

つまり、

「システムを作る」だけではなく「サービスとして継続的に価値を提供する」

ことを考えるのがサービスマネジメントです。

2. プロジェクトマネジメントとの違い

前の記事まで扱ってきたプロジェクトマネジメントと比較すると分かりやすくなります。

プロジェクトマネジメント

開始
 ↓
システムを作る
 ↓
完成
 ↓
終了

プロジェクトには基本的に開始と終了があります。

一方、サービスマネジメントでは、

サービス開始
 ↓
運用
 ↓
監視
 ↓
障害対応
 ↓
改善
 ↓
運用
 ↓
……

という活動が継続します。

項目 プロジェクトマネジメント サービスマネジメント
主な目的 プロジェクト目標の達成 サービス価値の継続的な提供
期間 開始と終了がある 継続的
主な対象 プロジェクト サービス
例 新システムの構築 システムの運用・改善

🍯 「作るところを管理する」のがプロジェクトマネジメント、「使い続けられるサービスを管理する」のがサービスマネジメント、と考えるとイメージしやすいです。

JIS Q 20000-1:2020

3. JIS Q 20000-1:2020とは

サービスマネジメントについて学ぶと登場する重要な規格が、

JIS Q 20000-1:2020

です。

JIS Q 20000-1:2020は、

サービスマネジメントシステムに関する要求事項を定めた日本産業規格

です。

サービスを適切に計画し、提供し、評価し、改善していくための仕組みについて定めています。

4. SMSとは

JIS Q 20000-1で重要になるのが、

SMS（Service Management System：サービスマネジメントシステム）

です。

ここでいう「システム」は、

サーバ
ネットワーク
アプリケーション

という意味だけではありません。

SMSは、

サービスマネジメントを実施するための方針・目的・プロセス・役割などを含めた管理の仕組み

です。

つまり、

サービスをどう管理する？

誰が責任を持つ？

どんな目標を設定する？

どう評価する？

どう改善する？

といったことを組織として管理する仕組みです。

5. SMSは継続的に改善する

サービスは一度作って終わりではありません。

計画
 ↓
サービスを提供
 ↓
結果を評価
 ↓
問題を発見
 ↓
改善
 ↓
再びサービスを提供

というように、継続的に管理・改善していきます。

例えば、

目標
「月間稼働率99.9%以上」
        ↓
実績
「99.5%だった」
        ↓
原因を調査
        ↓
改善策を実施
        ↓
次回の結果を確認

といった活動です。

サービスマネジメントシステムの運用

6. サービスマネジメントでは何を管理するのか

JIS Q 20000-1:2020では、サービスの運用に関する活動を整理して考えることができます。

今回押さえるのは、

サービスマネジメント
│
├─ サービスポートフォリオ
├─ 関係および合意
├─ 供給および需要
├─ サービスの設計・構築・移行
├─ 解決および実現
└─ サービス保証

です。

一つずつ見ていきましょう。

サービスポートフォリオ

7. サービスポートフォリオとは

**サービスポートフォリオ（Service Portfolio）**とは、

組織が管理するサービスを全体として把握・管理するための考え方

です。

例えばIT部門が、

社内メール
ファイル共有
勤怠管理
社内ネットワーク
Web会議

などを提供しているとします。

それぞれをバラバラに見るのではなく、

どんなサービスを提供している？

誰が利用している？

どんな価値がある？

継続する？

変更する？

終了する？

と、サービス全体を管理します。

8. サービスのライフサイクルを考える

サービスは永遠に提供されるとは限りません。

新しいサービス
      ↓
サービス開始
      ↓
提供・運用
      ↓
変更・改善
      ↓
サービス終了

という流れがあります。

例えば古い社内チャットサービスを終了して、新しいサービスへ移行する場合、

旧サービス
 ↓
終了

新サービス
 ↓
提供開始

という管理が必要です。

つまりサービスポートフォリオでは、

現在提供しているものだけではなく、サービス全体を戦略的に管理する

ことが重要です。

関係および合意

9. 関係および合意とは

サービスは提供者だけで成立するものではありません。

サービス提供者
        ↕
      顧客
        ↕
      利用者
        ↕
      供給者

など、さまざまな関係者が存在します。

そのため、

関係者との関係を適切に管理し、提供するサービスについて合意する

必要があります。

10. SLAとは

ここで重要なのが、

SLA（Service Level Agreement：サービスレベル合意書）

です。

SLAとは、

サービス提供者と顧客の間で、提供するサービスの水準について合意したもの

です。

例えば、

サービス提供時間
→ 24時間365日

月間稼働率
→ 99.9%以上

問い合わせ受付
→ 平日9:00〜18:00

重大障害
→ 30分以内に対応開始

などを決めます。

11. なぜSLAが必要なのか

例えば顧客が、

障害が起きたら
すぐ直してください！

と言ったとします。

しかし、

「すぐ」って何分でしょうか？

5分？

30分？

1時間？

翌営業日？

人によって認識が違います。

そこで、

重大障害
→ 30分以内に対応開始

のように具体的なサービスレベルを合意します。

これによって、

提供者と顧客の認識のズレを減らす

ことができます。

供給および需要

12. 供給および需要とは

ITサービスには、

需要（Demand）

があります。

例えばECサイトなら、

通常
→ 1,000アクセス

セール開始
→ 10,000アクセス

のように需要が変化することがあります。

需要に対してサービスを提供するためには、

サーバ
CPU
メモリ
ストレージ
ネットワーク
人員

などの資源が必要です。

そのため、

サービスへの需要を把握し、それに対応できる供給能力を管理する

必要があります。

13. 需要と供給のバランス

例えば、

利用者
10,000人
       ↓
アクセス集中
       ↓
サーバ能力
1,000人分

では、十分なサービスを提供できません。

逆に、

利用者
100人

超巨大サーバ
100,000人対応

では、必要以上のコストがかかる可能性があります。

つまり、

需要
 ↕
供給能力

のバランスを考えることが重要です。

14. キャパシティを管理する

このような、

サービスを提供するために必要な処理能力や資源

を考えることをキャパシティ管理と関連付けて理解できます。

例えば、

CPU使用率
メモリ使用量
ストレージ容量
ネットワーク帯域
同時接続数

などを監視し、

今後利用者が増える
        ↓
現在のサーバでは不足する
        ↓
事前に増強する

といった対応を行います。

サービスの設計・構築・移行

15. サービスの設計・構築・移行とは

新しいサービスを提供したり、既存サービスを変更したりするときには、

設計
 ↓
構築
 ↓
テスト
 ↓
移行
 ↓
本番サービス

という活動が必要です。

重要なのは、

変更した結果、現在のサービスを壊してしまわないこと

です。

16. 変更を適切に管理する

例えば本番システムで、

担当者
「便利そうだから
この設定変えときました！」

と自由に変更してしまったら危険です。

設定変更によって、

サービス停止
データ消失
セキュリティ問題
他システムへの影響

などが発生する可能性があります。

そのため、

変更要求
 ↓
影響を評価
 ↓
承認
 ↓
変更
 ↓
確認

というように、変更を管理します。

17. リリースと移行

開発・変更したものを実際のサービス環境へ導入する活動も重要です。

例えば、

新バージョン完成
      ↓
テスト
      ↓
リリース準備
      ↓
本番環境へ移行
      ↓
動作確認

という流れです。

サービスへの影響をできるだけ小さくしながら、安全に新しい状態へ移行します。

解決および実現

18. 解決および実現とは

サービスを運用していると、

ログインできない！

ネットワークにつながらない！

システムが遅い！

パスワードを変更してほしい！

など、利用者からさまざまな問い合わせや要求が発生します。

これらへ対応する活動が、

解決および実現

です。

19. インシデントとは

ここで重要なのが、

インシデント（Incident）

です。

インシデントとは、

サービスの中断や品質低下など、サービスへ悪影響を与える事象

です。

例えば、

システムにログインできない

Webサイトが表示されない

ネットワークがつながらない

処理速度が極端に遅い

などです。

20. インシデント管理

インシデントが発生した場合、まず重要なのは、

サービスをできるだけ早く正常な状態へ戻すこと

です。

例えば、

障害発生
 ↓
インシデントを記録
 ↓
分類・優先度設定
 ↓
調査
 ↓
復旧
 ↓
サービス再開

という流れで対応します。

ここで重要なのは、

インシデント管理の主目的は原因究明そのものではなく、サービスの迅速な復旧

という点です。

21. 問題管理

では、

なぜ障害が起きたの？

を調査するのは何でしょうか。

それが**問題管理（Problem Management）**です。

例えば、

インシデント管理
→ とにかくサービスを復旧する

問題管理
→ 根本原因を調査して再発を防ぐ

という違いがあります。

🍯 「インシデント＝まず直す」「問題管理＝なぜ起きたかを追う」と覚えると区別しやすいです。

22. サービス要求

障害だけでなく、

パスワードをリセットしてほしい

ソフトウェアをインストールしてほしい

アクセス権を追加してほしい

といった通常の依頼もあります。

このような利用者からの要求についても、受付・処理・完了まで適切に管理します。

サービス保証

23. サービス保証とは

サービスは、

動いているからOK！

ではありません。

利用者が安心して利用できる品質を維持する必要があります。

そのため、

利用できる？

十分な性能がある？

障害が起きても復旧できる？

情報は安全？

約束したサービスレベルを守っている？

などを管理します。

これがサービス保証に関わる重要な考え方です。

24. 可用性

**可用性（Availability）**とは、

必要なときにサービスを利用できる度合い

です。

例えば、

1か月の総時間
    ↓
サービスが利用できた時間
    ↓
稼働率を算出

といった形で評価できます。

SLAで、

月間稼働率
99.9%以上

などの目標を設定することもあります。

25. サービス継続性

大規模障害や災害が発生した場合にも、

重要なサービスを継続・復旧できるよう準備する

必要があります。

例えば、

バックアップ

冗長化

災害復旧環境

復旧手順

定期的な訓練

などです。

26. 情報セキュリティ

サービスを提供するときには、

情報セキュリティ

も重要です。

基本となるのが、

機密性
→ 見てはいけない人に見せない

完全性
→ 勝手に変更されない

可用性
→ 必要なときに利用できる

という考え方です。

サービスの安定性だけでなく、

安全に利用できること

もサービス品質の重要な要素です。

ITIL

27. ITILとは

サービスマネジメントを学ぶと必ず登場するのが、

ITIL

です。

ITILは、

Information Technology Infrastructure Library

の略称として広く知られています。

ITサービスマネジメントについての実践的な考え方やベストプラクティスを体系化したフレームワークです。

28. ITILは何のためにある？

例えばサービス運用で、

障害が発生したらどうする？

変更はどう管理する？

問い合わせはどう処理する？

サービスをどう改善する？

といった課題があります。

こうしたITサービスマネジメントについて、

効果的に管理するための考え方や実践方法

を体系化しているのがITILです。

29. JIS Q 20000-1とITILの違い

ここは混同しやすいポイントです。

JIS Q 20000-1

サービスマネジメントシステム
        ↓
要求事項を定めた規格

ITIL

ITサービスマネジメント
        ↓
実践的なベストプラクティス

ざっくり整理すると、

項目 JIS Q 20000-1 ITIL
種類 規格 ベストプラクティスを体系化したフレームワーク
対象 サービスマネジメントシステム ITサービスマネジメント
イメージ 何を満たすべきか どう実践するかを考える助け

両者は対立するものではなく、

サービスを適切に管理するための考え方として関連付けて理解する

のがよいでしょう。

30. サービスマネジメントの全体像

今回の内容を整理すると、

サービス
│
↓
サービスマネジメント
│
├─ JIS Q 20000-1:2020
│   └─ SMS
│       └─ サービスを管理する仕組み
│
├─ サービスポートフォリオ
│   └─ サービス全体を管理
│
├─ 関係および合意
│   └─ 顧客・供給者などとの関係
│       └─ SLA
│
├─ 供給および需要
│   └─ 必要な能力・資源を管理
│
├─ 設計・構築・移行
│   └─ 変更やリリースを管理
│
├─ 解決および実現
│   ├─ インシデント
│   ├─ 問題
│   └─ サービス要求
│
├─ サービス保証
│   ├─ 可用性
│   ├─ 継続性
│   └─ 情報セキュリティ
│
└─ ITIL
    └─ ITサービスマネジメントの
       ベストプラクティス

サービスマネジメントは、

「障害対応」だけではありません。

サービスの計画から、

どんなサービスを提供する？
        ↓
顧客と何を約束する？
        ↓
必要な能力はある？
        ↓
安全に変更・リリースできる？
        ↓
障害や要求に対応できる？
        ↓
安定・安全に利用できる？
        ↓
もっと改善できる？

まで、サービス全体を継続的に管理する考え方です。

まとめ

この記事で覚えること

  • サービスマネジメントは、利用者へ価値のあるサービスを継続的に提供・管理するための活動
  • JIS Q 20000-1:2020は、サービスマネジメントシステムの要求事項を定めた規格
  • SMSはサービスマネジメントを組織的に実施するための管理の仕組み
  • サービスポートフォリオでは、組織が管理するサービスを全体として把握・管理する
  • 関係および合意では、顧客や供給者などとの関係や合意を管理する
  • SLAでは、サービス提供者と顧客の間でサービスレベルについて合意する
  • 供給および需要では、サービスへの需要と提供能力のバランスを管理する
  • サービスの設計・構築・移行では、変更やリリースを適切に管理する
  • 解決および実現では、インシデントやサービス要求などへ対応する
  • インシデント管理では、サービスをできるだけ早く正常な状態へ戻す
  • 問題管理では、問題の根本原因を調査して再発防止につなげる
  • サービス保証では、可用性・継続性・情報セキュリティなどを管理する
  • ITILは、ITサービスマネジメントの実践的なベストプラクティスを体系化したフレームワーク
  • JIS Q 20000-1は「要求事項を定めた規格」、ITILは「実践のためのベストプラクティス」と整理すると分かりやすい

🍯 はちみつメモ

サービスマネジメントは「システムを動かす」だけではなく、「利用者へ価値を届け続ける」ための管理。JIS Q 20000-1はSMSの要求事項を定めた規格、ITILはITサービスマネジメントの実践知。障害が起きたら「まず復旧＝インシデント管理」「根本原因を追う＝問題管理」の違いも押さえておこう！