ITサービスの「サービス」を管理するするための考え方を説明します。
良いサービスを提供するため、ITサービスを計画・提供・運用・改善するための仕組みや管理の枠組みをService Management System（サービスマネジメントシステム）と言い、SMSと略されることもあります。
本書はJIS Q 20000-1を参考にしています。
SMSの範囲を明確にする
組織とは目的を達成するためサービスを提供する人の集まりです。組織は会社全体、会社の中の部門または個人で良いです。
次に利害関係者は、主に顧客やユーザ、経営者、外部の供給者です。
顧客はサービスを受ける利用者です。
組織及びその状況の理解
組織の課題を理解する
組織はサービスをきちんと提供するにあたり、課題を整理しておきます。
いくつか例を挙げます。
- 市場環境：顧客がオンプレからクラウドへ移行する流れが加速。
- 競合状況：他社が低価格プランを出しており、サービス差別化が求められる。
- 社会情勢：リモートワークの普及により、VPNやセキュリティ強化の需要が増加。
- リソース：クラウド技術に詳しい人材が不足している。
- 設備：一部のシステムは古いハードウェアで動いており、障害リスクがある。
利害関係者のニーズを理解する
利害関係者を把握し、要求事項を把握します。
いくつか例を挙げます。
SMSの適用範囲を決める
組織は、SMSをどこまでの範囲で適用するのかを決めておく必要があります。
その際には、上の章で整理した「組織の課題」、「利害関係者のニーズ」を考慮して決めます。
決めた範囲には、対象となるサービスと、それを管理・提供する組織の名前を含める必要があります。
経営層の責任(リーダシップ)
経営層は、SMSがきちんと機能するように、次のことを行わなければなりません。
- 方針、目標を定める（例：「顧客満足を最優先とする」）
- 人材や予算などの資源を提供する
- 役割と責任を明確にして組織へ伝える（例：インシデント管理責任者を任命）
- 継続的な改善を推進する
計画書作成
上の章で整理した「組織の課題」、「利害関係者のニーズ」を考慮し、リスクと機会の計画します。
例えば顧客への影響、リスク受容基準などをまとめ、取組みを決めていきます。
さらに、優先度や評価方法なども検討して計画書に記載します。
サービスマネジメントシステムの支援
組織がSMSのために支援すべき内容は、①資源、②力量、③認識、④コミュニケーション、⑤文書化した情報、⑥知識があります。
①資源
サービスマネジメントシステム実施にはリソース（ヒト、技術、モノ、財源、情報）を確保することが不可欠です。
②力量
力量は「意図した結果を達成するために，知識及び技能を適用する能力。」と定義されています。
組織は、スタッフの能力やスキルが十分であることを確保する必要があり、適切な教育・トレーニング、経験の積み重ね、評価が含まれます。
③認識
組織の管理下で働く人々は，次の事項に関して認識をもたなければならないです。
・方針
・目的
・自らの業務に関連するサービス
・パフォーマンスの向上によって得られる便益を含む，SMSの有効性に対する自らの貢献
④コミュニケーション
組織内外の関係者との適切なコミュニケーションが不可欠です。顧客とのやり取りや、サプライヤーとの連携も含まれます。
⑤文書化した情報
必要なプロセスや手順、記録を文書化することが求められます。
⑥知識
組織は、サービスの運用に関する知識を蓄積し、共有する仕組みを作る必要があります。
サービスマネジメントシステムの運用
サービスポートフォリオ
サービスポートフォリオは、組織が提供する全てのサービスを整理したものです。
サービス提供中のサービスはサービスカタログと言います。
検討中や開発中のサービス、廃止済みのサービスも含めます。
検討中や開発中のサービスはサービスパイプラインと言います。廃止済みのサービスも含めます。
サービスポートフォリオは、サービス，成果及、サービス間の依存関係といった情報を含めるようにします。
他の関係者が提供又は運用するサービスがあればその情報も記載します。
■サービス・パッケージ
ITILでは顧客ニーズ満たすために組み合わされた複数のサービス「サービス・パッケージ」というのがありあす。サービス・パッケージは次の３つで構成されています。
・コアサービス ： 必要な基本サービス
・実現サービス ： コアサービスに必要なサービス
・強化サービス ： 追加サービス
資産管理(構成アイテム管理)
組織は、サービス提供に使われる資産を適切に管理します。
一般的に資産は構成品目（Configuration Item）(※CIと略す)ごとに管理し、各CIはCMDB（構成管理データベース）で一元的に管理されます。
＜CIで管理する主な情報(属性)＞
- 一意の識別情報
- CIの種類
- CIについての記述
- 他のCIとの関係
- 状態
関係者との合意
顧客や外部供給者とSLA(サービスレベル合意書)や契約書で締結します。
SLAとは、「Service Level Agreement（サービスレベル合意）」の略で、サービス提供者と利用者の間で、提供するサービスの内容や品質をあらかじめ取り決めた契約のことです。
SLAにはサービスレベル目標を含めるようにしますが、良い目標の決め方としてSMARTの考え方があります。
S：Specific（具体的である）：誰が・何を・どのように達成するかが明確であること
M：Measurable（測定可能である）：数値などで目標の達成度を客観的に測れること
A：Achievable（達成可能である）：現実的に達成できる内容であること
R：Relevant（関連性がある）：組織の目標・顧客ニーズに合っていること
T：Time-bound（期限がある）：達成すべき期限や頻度が定められていること
| SLAのサンプル |
|---|
| １．目的 会計システムのヘルプデスク・・・ ２．対象範囲 2.1対象システム ・会計Aシステム（アプリケーション、インフラ） ・会計Bシステム（アプリケーション） 2.2 対象外 ・会計Bシステムのサーバ（OSやインフラ） ・利用者のパソコンに関連する部分 ・システムの機能追加、パッケージバージョンアップ ： ３．役割と責任 ・ヘルプデスク基幹職の責任 対応件数を上回る問い合わせ件数が続く場合は人員の確保を実施。 ・顧客（主管部門）の責任 ①社内ユーザ部門への方針決め、トップダウン指導 ②サポート対象外のサーバ機器の故障が発生した場合に備え、予算確保をする。 ： ４．サービス提供時間 平日９：００～１８：００ ５．連絡先 TEL：１２－３４５－ｘｘｘ ６．目標処理時間 （１）インシデント ①緊急 開始までの時間：10分以内、解決までの時間：4時間以内・・・ ②緊急以外 ・・・ ７．対応可能件数 ８．可用性目標 年間：99.9% ９．サービス復旧目標時間 10．サービス継続性の取り決め 11．測定／報告 （１）問合せ、インシデントの発生件数と解決件数 （２）可用性目標の結果 （３）レスポンスを測定し報告する。 |
事業関係管理
顧客などの利害関係者を明確にして記録する必要があります。
顧客との関係を管理し、満足度を維持する担当者を1人以上任命しなければなりません。
定期的に満足度を測定し、サービスの成果や傾向を確認・見直します。
苦情は記録し、問題解決まで管理・報告します。
通常の手段で解決できない場合はエスカレーション手段を確保しておく。
サービスレベル管理
定期的に次の事項をレビューします
・サービスレベル目標に照らしたパフォーマンス
・SLAの作業負荷限度と比較した，実績及び周期的な変化
供給者管理
組織は外部供給者と次の事項を契約文書にて合意します。
- サービスの適用範囲
- 要求事項
- 目標や契約義務
外部供給者の業務パフォーマンスを、あらかじめ定めた間隔で監視し、目標や契約義務が果たされていない場合、改善の機会を特定する必要があります。
供給・需要管理
■サービスの予算業務及び会計業務
予算業務及び会計業務を行います。
■需要管理
需要管理では、事業活動パターン(PBA)やユーザープロファイル(UP)を元に、サービスの需要を調査ます。
| 内容 | 説明・例 |
|---|---|
| 過去のインシデントや問合せ | 問い合わせの中に、サービス外の要望があったなど。 |
| PBA（事業活動パターン） | 業務の発生パターン(日次、週次、月次など)をまとめ、変化する需要の変化に注目します。 例：昼間は利用ユーザ数が多く、深夜は少ない 月末決算はシステム負荷が上がる |
| ユーザープロファイル(UP) | ユーザ部門などのグループ単位で、利用するサービスの傾向や特徴をまとめます。 例：営業部は社外からモバイルを使用 開発部はリモート接続で性能重視のPCを使用 |
■容量・能力管理
サービスに必要なリソース（人・技術など）の容量と能力を予測・計画・監視し、常に足りるように管理する。
サービスの設計，構築及び移行
変更管理
変更管理は、品目(ハードウエア、ソフトウエア、文書など)に対する変更によるサービスへの影響やリスクを最低限に抑えることが目的です。
主に次の内容で進めます。
- 顧客の要求者がRFC（Request for Change）を起票（代理で起票することもある）
- RFCを受け取り、基本情報(変更の内容、目的、スケジュール、影響範囲など)を入力して記録します。(記録を残すことで、追跡・監査が可能になります。)
影響範囲は、CMDB(構成管理データベース)を参考にしたり、連携しているシステムや業務の情報をもとに考えたりします。 - CAB（Change Advisory Board）が、提出された変更に対してリスクや影響を評価し、承認または却下を行います。
- 開発や設定変更など、実装をします。
- 実装後に成果と影響を振り返るレビューをします。
サービスに追加、変更、廃止によって顧客へ影響が出る場合は、次の「サービスの設計及び移行」に則って実施が必要です。
RFC（Request For Change：変更要求書）を起票して、変更管理チームに送信し、検証と承認を行います。
標準変更・・・事前承認されている変更（定期的なパッチ適用など）
緊急変更・・・予期していない変更で、即時対応が必要な高リスク変更（悪意のある攻撃を受けた時の対応など）
通常変更・・・緊急性はないが審査・承認が必要な変更。
サービスの設計及び移行
■新規サービス又はサービス変更の計画
最初の計画時には、各活動の内容とその責任者を明確にします。
■サービス受入基準
サービス受入基準は、顧客からの要求や契約条件などから設定します。
例として次のような内容があります。
| No. | 内容(例) |
|---|---|
| 1 | ユーザ受入テストで期待効果「△△業務の負担が50%以上軽減」が得られることが確認できる。 |
| 2 | 設計書、各テスト結果報告書が完成しており、レビューが完了していること。 |
| 3 | 各テストにおいて合格していること。 |
■設計
設計フェーズでは次の内容を含めることが必要です。
- 新サービスに必要な訓練
- SLAの変更
- サービスカタログの更新
■構築及び移行
開発や設定変更などを実施しますが、サービス受入れ基準を満たしていることを検証するために，試験をします。
リリース及び展開管理
①承認
サービス受入れ基準を満たしているかなどを判定し、承認される必要があります。
②リリースの計画
変更管理の内容をインプットして、リリース作業の日付、担当者、展開方法を作成します。
| 名称 | 説明 |
|---|---|
| ①CI（構成アイテム）の確認 | ・今の機器で足りるか ・新たな運用マニュアル要否 ・新たなユーザマニュアル要否 |
| ②要員計画 | ・今の要員で足りるか、必要増員数 ※リリース後の初期トラブルも想定する |
| ③トレーニング計画 | 新サービスや機能リリースにあたり、ユーザへ教育などの説明会が必要であれば計画に入れておく。 |
| ④引継ぎ計画 | 開発部門から運用担当者への引継ぎを計画に入れる。 |
| ⑤周知計画 | リリース後に追加される機能の説明や、リリース作業によるシステム停止など |
インシデント管理
インシデントとは、計画外のサービス中断，サービスの品質の低下です。
まだ、顧客やユーザへ影響していない場合(停止や品質低下に成り得る事象)もインシデントになります。
インシデント管理はユーザからの問合せや、監視ツールからの発報をトリガーに発動します。
受付して優先度を決めてから対処します。
インシデントの事象や活動内容はしっかり記録します。
インシデント管理は、サービスの早期復旧(要すれば暫定対応)に焦点を当た活動です。
根本原因の究明して、恒久的な解決策を考えることも重要ですが、この活動は後で説明する「問題管理」で行います。
問題管理
問題管理は、インシデントの根本原因を分析して再発を防止するための活動です。
サービス可用性管理
サービス可用性管理は、可用性リスクのアセスメント、目標設定、監視、記録、対応といった一連の活動を継続的に行います。
| 活動内容 | 活動の例 |
|---|---|
| あらかじめ定めた間隔で，サービス可用性のリスクのアセスメントを行う | 機器の老朽化、サイバー攻撃などで可用性を脅かすリスクを洗い出して、リスク一覧表を作成 |
| サービス可用性の要求事項及び目標を決定 | 可用性目標を「月間稼働率99.9％」と定める |
| サービス可用性を監視し，結果を記録し，目標と比較 | Zabbix、Nagios、CloudWatchなどでサーバー稼働状況を常時監視し、月次でダウンタイムレポートを自動生成 |
| 計画外の可用性の喪失は，調査し，必要な処置をとる | xxxx年x月x日に1時間のサービス停止が発生 原因：リリース作業時の設定ミス 処置：設定変更手順にダブルチェックを導入 |
サービス継続管理
サービス継続管理は、災害や重大な障害発生時でも、重要サービスを継続・復旧させることを目的とした活動です。
主にBCP（事業継続計画）、DR（災害復旧）計画の策定、演習、復旧手順の整備をします。
| 活動内容 | 活動の例 |
|---|---|
| 定めた間隔で，サービス継続のリスクのアセスメントを行う | 自然災害、サイバー攻撃、システム誤操作などを洗い出して、それぞれのリスクがサービス継続にどれだけ影響を与えるかを評価。 |
| サービス継続の要求事項を決定 | 要求事項の例： 自然災害、サーバー攻撃などの発生時には最大12時間以内にサービスを復旧させる必要がある。 |
| サービス継続計画を作成して実行 | 機器の冗長化 バックアップが正しく取得されているかを検証 |
| 通常のサービス提供領域へのアクセスが妨げられた場合でも関係者へ連絡を取れるようにする | 紙媒体での連絡先リストを全社員に配布 クラウド上に暗号化した連絡先を保存 |
| 定めた間隔でサービス継続計画の試験をする | 年に1回、計画的にサービス継続計画のシミュレーション（災害シナリオ）を実施し、復旧手順を実施する |
「サービス継続管理」と「サービス可用性管理」は似ていますが、「サービス可用性管理」は機器障害や設定ミスなどの日常の運用でサービスを中断させずに稼働し続けることが主で、「サービス継続管理」は地震、火災、洪水、サイバー攻撃、パンデミックなどの大規模・非日常的な障害が対象です。
パフォーマンス評価
監視，測定，分析及び評価
サービスのパフォーマンスと有効性を、客観的に評価・改善するために行うべき活動を定めています。
| 活動内容 | 活動の例 |
|---|---|
| 監視及び測定が必要な対象を決定 | ・インシデント管理プロセスの対応時間 ・サービスの稼働率（可用性） ・ユーザー満足度 |
| 評価の方法を決定 | ・インシデント管理レポート ・監視ツール（Zabbix、Nagiosなど）による自動取得 ・ユーザからのアンケート |
| 評価 | 定例会議などで報告して評価 |
内部監査
内部監査はSMSが適切に機能しているかどうかを、組織内部で定期的に確認・評価することです。
| 項目名 | 説明 |
|---|---|
| 目的 | SMSが要求事項を満たしていることを確認する |
| 実施タイミング | 原則 １年に1回 |
| 実施者 | 公平な立場の社内監査員、または外部監査員 |
| 実施内容 | ・日々作成している文書 ・インタビュー |
マネジメントレビュー
マネジメントレビューは、SMSとサービス全体が、現在目的に合致し、効果的に機能しているかを、トップマネジメントが定期的に確認することです。
継続的改善
継続的改善は、パフォーマンスを向上するために繰り返し行われる活動です。
この活動では目標を設定やその優先度を設定して、実行されることを確実にするものです。
コメント