Ｗｅｂ教材一覧＞ 法規・基準

JIS Q 20000（ISO/IEC 20000）ＩＴＳＭＳ

キーワード

JIS Q 20000、ISO/IEC 20000、ＩＴＳＭＳ、ＩＴサービス、ＩＴサービスマネジメント、ＩＴサービスマネジメントシステム、ＩＴＩＬ、ＩＴＳＭＳ認証制度、ＳＬＡ、ＩＳＭＳ、顧客、ユーザ、サービス提供者、プロバイダ、サービス供給者、サプライヤ、サービスポートフォリオ、サービスカタログ、サービス・パイプライン、廃止サービス、事業関係管理、事業関係管理、サービスレベル管理、供給者管理、ＯＬＡ、運用レベル合意書、サービス保証、可用性、リスク分析、リスク分析、サービス可用性管理、サービス継続管理、ＢＣＰ、事業継続計画、情報セキュリティ管理、サービス要求管理、インシデント管理、エスカレート、ＣＭＤＢ、既知の誤り、ＫＥＤＢ、問題管理、リアクティブな問題管理、プロアクティブな問題管理、変更管理、ＲＦＣ、ＣＡＤ、変更諮問委員会、ＰＩＲ、導入後レビュー、リリース管理、展開管理、移行、引継、サービス受入れ基準、一斉移行、段階的移行、移行計画、移行リハーサル、移行判断、移行の通知、移行評価、受入れテスト、運用テスト、βテスト、資産管理、ソフトウェア資産管理、ＳＡＭ、ライセンス管理、ＳＬＭ、構成管理、ＣＩ、構成品目、キャパシティ管理、需要管理、容量・能力管理、財務管理、サービスの予算業務及び会計業務

JIS Q 20000 理解の前提

JIS Q 20000-1 の正式名称は、「JIS Q 20000-1 情報技術　サービスマネジメント第1部：サービスマネジメントシステム要求事項」です。JIS Q 20000 では、「サービス」や「ＳＭＳ」という用語を使っていますが、前提が「情報技術」であることから、一般に用いられている「ＩＴサービス」、「ＩＴＳＭＳ」のことだと解されます。

ＩＴサービス
従来「システム運用」といわれていた分野ですが、さらに広く、可用性、信頼性、保守性の概念も含むサービス性と捉えています。
例えば、次のような対象があります。
  • サービスデスク
    操作方法の指導、機器トラブル時の解決、簡単な技術指導など、日常的なユーザ支援
  • 既存ＩＴシステムの運用
    ソフトウェアのバグ修正、比較的小規模のシステム改訂など
  • ハードウェアの管理
    機器の故障修理、処理性能の拡大、新機種導入など
  • ソフトウェアの管理
    ソフトウェア利用状況、バージョンアップ、新ソフトウェアのインストールなど
ＩＴサービスマネジメント
ＩＴサービスのありかたを定め、円滑な実施をすることです。
ＩＴサービスマネジメントシステム（ＩＴＳＭＳ）
マネジメントシステムとは、経営的な観点から全社的な取り組みをし、ＰＤＣＡサイクルにより継続的な改善をする仕組みを確立することです。ＩＴＳＭＳとは、ＩＴサービスをマネジメントシステムとして運営することであり、JIS Q 20000-1 はそのためのベストプラクティスあるいはガイドラインになります。

JIS Q 20000に関連した規格等を掲げます。

ＩＴＩＬ（Information Technology Infrastructure Library）
英国商務局（OGC : Office of Government Commerce）が、ＩＴサービス管理を行うときの業務プロセスと手法を体系的に標準化したガイドブックです。その後、英国規格BS 15000になり、さらに ISO/IEC 20000（JIS Q 20000）になりました。
ＩＴＩＬは、JIS Q 20000はマネジメントシステム規格を実現するための手引書であるといえます。
参照：ＩＴＩＬ、 ＩＴＩＬ（Ｖ４）
ISO/IEC 20000／JIS Q 20000
・ISO/IEC 20000-1:2020／JIS Q 20000-1:2020 第1部：サービスマネジメントシステム要求事項
ＩＴＳＭＳを実現するのに必要な事項を体系的に列挙したものです（本章では、これを対象にしています）。
・ISO/IEC 20000-2:2012／JIS Q 20000-2:2013 第2部：サービスマネジメントシステムの 適用の手引
JIS Q 20000-1をより正確に解釈することにより JIS Q 20000-1 をより効果的に利用できるようにすることを目的とする手引書です。ＩＴＥＬの後継規格だといえます。
ＩＴＳＭＳ認証制度
組織のＩＴＳＭＳの状況が、JIS Q 20000-1 の要求事項との適合性を第三者が監査して認証する制度です。
参照：ＩＴＳＭＳ適合性評価制度
ＳＬＡ（Service Level Agreement、サービス水準合意）
ＩＴＳＭＳを実現するには、社外の専門企業の協力が必要です。そのとき、サービス提供者（注１）とサービス受益者の間で、サービスの対象分野やサービスレベル（注２）に関する合意が必要です。それをＳＬＡといい、JIS Q 20000-1 でもサービスレベル管理として大きな対処になっています。
参照：ＳＬＡ／ＳＬＭ
（注１）JIS Q 20000-1 では、サービス提供者にはＩＴ運用部門など社内の提供者も想定しています。これについては後述します。
（注２）「システムが絶対にダウンしない」ことを保証することは不可能です。それを要求したら莫大な料金を請求されましょう。それで、どの程度のトラブルが月何回以内にするか、復旧までの時間を何時間以内にするかなどのサービスレベルを設定し合意することが大切なのです。
ＩＳＭＳ（Information Security Management System）
ＩＴＳＭＳと似た用語ですが、セキュリティ対策を重点にしたマネジメントシステムです。JIS Q 27000で規格化されています。
参照：参照：ＩＳＭＳの概要

JIS Q 20000-1（ＩＴＥＬ）での組織用語はやや特殊です。

顧客
事業の運営に責任をもち、サービスが事業に様々な価値をもたらすことを期待してサービスにお金を出す人です。システムオーナともいいます。サービスの影響が全社的なときは、トップマネジメントだとするのが適切です。ＳＬＡの一方の当事者です。
ユーザ
日常的なシステムの利用者、直接にサービスを受ける人です。発注企業の人だけでなく、ネット販売の消費者なども含まれます。ユーザはＩＴＳＭＳの適用外です。
サービス提供者（プロバイダ）
サービスを直接提供している組織です。
　　・外部提供者：受託企業
　　・内部提供者：ＩＴ運用部門
がありますが、その区分はせず、供給者全体として、ＳＬＡの一方の当事者となります。
ＩＴ運用部門は、自社システムの運用ですがプロバイダの立場であり、極端には、外部供給者が存在しないときは、ＩＴ運用部門と経営者の間でＳＬＡに合意することになります。
サービス供給者（サプライヤ）
プロバイダを支援する組織です。
　　・外部供給者：システム開発ベンダ、サーバなどのハードベンダ、通信ベンダなど。
　　・内部供給者：ＩＴ開発部門、技術部門、一部のユーザなど。
　　・供給者として行動する顧客：インシデント及びサービス要求管理の活動の一部を実施する顧客など
ＳＬＡ策定に参加することはあっても、あくまでも顧客やサービス提供者への支援の立場であり、ＩＴＳＭＳの直接の当事者ではありません。

JIS Q 20000-1 の内容（目次）

JIS Q 20000-1:2020 情報技術　サービスマネジメント第1部：サービスマネジメントシステム要求事項
（ http://kikakurui.com/q/Q20000-1-2020-01.html）

以降の文中（#8.2）は、この目次の章・節を示します。しかし、JIS Q 20000-1 の記述ではありません。

ＩＴサービスの提案からＳＬＡ策定まで

提供サービス一覧

サービス提供者は、自社が提供できるサービスを常に把握して一覧にしておく必要があります。

サービス見積

ＳＬＡ合意に際して、サービス提供者には、費用対効果を算出することが求められます。ところが、ＩＴサービスでは、それが困難な事情が多くあります。

高精度な数値を算出するのは困難でしょうが、過去の事例やヒアリングなどから統計的に推測することはできます。逆に、それを効果的に行うために、ＳＬＡの実績把握システムを整備するのが重要だといえます。
　最終的にはＳＬＡ当事者の直観的判断になります。そのためには当事者の相互信頼性を高めることが重要です。さらに、継続的に改善するために、ＳＬＭが必要になるのです。

ＳＬＡの策定

サービス提供者とサービス供給者の関係

供給者管理（#8.3.4）

サービス提供者（プロバイダ）はサービスを直接提供している組織、サービス供給者（サプライヤ）プロバイダを支援する組織です。サービス対象のなかには、サーバなどの機器故障やクラウドサービスでのトラブルなど、実際にはサービス提供者自身では解決できず、サービス供給者に頼ることが多くあります。

ＳＬＡとは、広義には、ベンダおよび社内ＩＴ部門が、利用部門と交わす文書になりますが、それを分解すると、次の２つになります。

インフラストラクチャの管理（#8.7）

ＩＴＳＭＳの最大の目的は、ユーザが必要なときに必要なサービスを受けることができる、すなわち、サービスの可用性を保証することにあります。可用性管理のうち、特に災害などの緊急時での事業継続を対象とする場合は継続性管理といいます。

可用性管理／継続性管理に共通な>基本事項を列挙します。

サービス可用性管理（#8.7.1）

サービス可用性では、量としての可用性だけでなく、質としての可用性も含まれます。例えば、サービスデスクに依頼したとき、解決までの時間だけでなく、再発しないようにトラブルの原因の説明や独力復旧の手順まで得られるかなど、満足性も含まれます（しかし、上述のＭＴＢＳＩ≒ＭＴＢＦは量としての可用性だけを指します）。

可用性管理ではITサービスの可用性/非可用性を予測、計画して管理することを目的として以下の目標を掲げています。
　・将来的なサービス損失の予防
　・外部ベンダに対する契約調整
　・サービスを構成するアイテムについての適切な保守活動

障害時運用設計

システムが正常に稼働しなくなったときの対応です。代表的な対象は次の２つです。
　　・システムの多重化
　　・データベースのバックアップ・リカバリー
　サービス提供者の任務は（ＳＬＡにより異なりますが）、次の２つです。
　　・平素から、復旧目標値内で復旧するための方法や手順を作成し、評価し、改訂しておくこと
　　・トラブル発生時に、手順に従い短期間に確実に復旧作業を行うこと

計画書策定には、それぞれの分野での高度な知識やスキルを持つ技術者が必要です。また障害発生時の復旧作業でも手順書通りに復旧できない異常な状況では、同様な技術者が必要です。
　これらは、平時でのサービス提供者だけでは、量・質ともに不十分であり、高度技術を持つサービス供給者の支援が必要になります。そのため、これらに特化したＯＬＡ（運用レベル合意書）の策定が重要になります。

サービス継続管理（#8.7.2）

ＢＣＰ（Business Continuity Plan、事業継続計画）での災害対策設計に相当する分野です。
　例えばサーバ設置場所が火災にあったとき、最小限の時間でサービス復旧をするためには、平素から、離れたセンターにデータを保管しておくとか、必要最小限の処理ができる設備を確保しておくこと、災害発生時に最小時間で復旧させる手段を講じておくことなどがこれにあたります。大規模な障害時運用設計だともいえます。

被害が広範囲に甚大な影響を与えることから、トップマネジメント主導によるＢＣＰ／ＢＣＭがあり、その大きなサブシステムとして、継続性管理を位置付けるべきです。サービス提供者は重要な一員ですが、トップマネジメント、ユーザ、サービス供給者、その他の重要な利害関係者からなるレビューにより、計画策定、災害発生時の対応を検討することが不可欠になります。

計画策定

災害発生時の対処

災害は想定外な状況になります。計画した手順の対処では解決できないことが多いので、シミュレーションなどによる訓練を行い、それを評価して、計画を改訂することが重要です。
　それでも実際には、想定外のトラブルが発生します。緊急対処に関する事項も検討しておくべきです。

情報セキュリティ管理（#8.7.3）

情報セキュリティ対策は、情報資産の機密性，完全性，可用性を保つために重要です。これに関しては JIS Q 20000 Ｉの他の分野でも言及していますが、それらを統合的に管理するために「情報セキュリティ管理」を設けています。しかし、情報セキュリティのマネジメントシステムは JIS Q 27000シリーズ（ＩＳＭＳ）がありますので、ここでは、サービス供給者が行う事項の概要を示すだけになっています。

サービス要求から解決、本番移行までのプロセス（#8.6. #8.5）

ユーザからのサービス提供者の窓口をサービスデスクといいます。ユーザとサービス提供者の間のコミュニケーションはすべてサービスデスクを介して行われます。

サービス要求のなかには、サービスデスクだけで解決するものもあれば、サービス提供者内部の専門技術者あるいはサービス供給者による解決が必要なものもあります。

サービス要求管理（#8.6.2）

サービス要求には、次のようなものがあります。
　・質問：既存システムやオフィスソフトなどの操作方法など
　・支援：新規ユーザの登録、不定期のバッチ処理依頼
　・異常事態：ソフトウェアのエラー、ハードウェアの故障など
　・改善要求：応答時間の短縮、データ入力手順の簡素化など（大規模なものは除く）

サービス要求は、ユーザからサービスデスクに通知されます（サービス提供者が自ら監視や検討して発見することもあります。
　このうち、サービスデスクで単純に対処でき、他への影響度が小さい要求は、記録にとどめるだけで完了します。

インシデント管理（#8.6.1）

サービスデスクからのサービス要件をインシデントといいます。
インシデント管理とは、インシデントに対して、業務への影響を最小限に抑え迅速な回復を図る可用性を重視した臨床的な初期サポートです。

補充

エスカレーション
サポートデスクで解決できない要求をインシデント管理に渡したり、インシデントがインシデント管理で解決できないとき、問題管理に渡すというように、解決を次の段階へ委ねること、あるいは、そのような状況になることです。
  • 機能的エスカレーション
    解決に必要な知識が不足するために、より専門性な知識を持つ組織に解決を委ねることです。２次、３次へとエスカレートすることもあります。
  • 階層的エスカレーション
    要求を解決するには自組織が権限を持たない他の組織に影響が及ぶとき、双方の組織を関する上司に解決してもらうことです。
解決目標時間
ユーザは、復旧時間に大きな関心を持ちます。インシデント管理だけでなく後続する管理でも、状況と解決目標時間をサポートセンタを通してユーザに伝えるようにします。ＣＭＤＢからそのためのファイルを派生して、ユーザがオンラインで確認できる（ネット販売での配送状況通知のような）工夫が求められます。
回避策（ワークアラウンド）
本来ならば、サービス要求に対して原因を明確にして同様なトラブルが発生しないようにするべきですが、技術的理由、時間的制約により、現在できることにとどめ、未解決の部分をペンディングすることです。最終的解決をしていないので、ＣＭＤＢには未解決のプラグが付きます。

問題管理（#8.6.3）

同様なインシデントが再発しないようにするには、根本的な対策が必要になります。それをインシデントが問題にエスカレーションしたといいます。「問題」とは原因が「未知な誤り」のことでもあります。
、その管理を問題管理といいます。「未知な誤り」の原因を見出して「既知の誤り」にすることです。なお、既知の誤り情報をＫＥＤＢに登録します。
　問題管理では、病理学的に根本原因を特定します。これにより類似の問題発生を予防できます。

根本原因が特定したら、変更管理に変更要求を出します。その変更要求のことをＲＦＣ（Request For Change）といいます。

変更管理（#8.5.1）

変更管理では、インシデント管理や問題管理からの変更要求（ＲＦＣ）の内容について、変更の緊急性や影響度、それにかかるコストや時間などを評価して、認可／却下の決定、優先度の決定をします。その組織を変更諮問委員会（Change Advisary Board、ＣＡＤ）といいます。

変更は次の変更タイプに区分されます。

認可された変更は、実装確認のレビューＰＩＲ（Post Implementation Revew：導入後レビュー）をします。それに成功すれば、実際の変更作業はリリース管理が行ないます。

リリース管理／展開管理（#8.5.3）

ＰＩＲなどにより確認された変更を公式に認め実施するころをリリースといいます。リリース管理では、変更管理で計画した変更を実施、テストして、実装し利用者への周知などを行います。リリース管理は変更管理の一部で、変更管理が変更に伴う多様な決定をするのに対して、リリース管理は変更が決定してからの作業手順管理です。通常は情報システム部門が担当し、試験環境を設定してテストします。

リリースの種類

なお、変更したシステムを試験環境から稼働環境へ戻すことをロールバックといい、その管理を展開管理といいます。リリース管理に展開管理も含めることもあります。

本稼働環境への移行（#8.5.2）

運用引継には２つの局面があります。どちらの場合も、ドキュメント・資料類をリスト化し、バージョン管理して、最新のバージョンを確実に引き継ぐこと、それを双方が確認することが重要です。

移行・引継での基準

変更後システムをサービス提供者からシステム運用部門に移管するのにあたり、あらかじめ、サービス提供者が行った作業が適切であり、その後の運用を引き継ぐための基準を明確にしておく必要があります。

サービスの移行

運用引継ぎ

移行したシステムを運用グループが受け入れる段階の作業です。ここでは、説明の都合から、システム開発部門（受注ベンダ）が作成した新規システムを運用部門（発注企業）が引き継ぐ（納品確認をする）こととして記述します。
　システムが発注した品質をすべて満足していることを確認する一連のテストを受入れテストといいます。

インフラストラクチャの管理

資産管理（Asset Management）（#8.2.5）

資産とは、自社が保有するものを指します。ここでの資産とは、情報資産のことで、情報システムに必要なハードウェア・ソフトウェア・データ・人員・文書などです。
　情報資産を管理することを、情報資産管理（IT Asset Management、ＩＴＡＭ）といいます。

構成管理（Configuration Management）（#8.2.6）

ＩＴサービスを構成するハードウェア，ソフトウェア，ドキュメントなどを構成品目（Configuration Item、ＣＩ）といいます。逆に、ＣＩを互いに関連付けて実務的機能と捉えたものをＩＴインフラストラクチャといいます。すなわち、ＩＴサービスとは、ＩＴインフラストラクチャのサービス性（可用性、信頼性、保守性）を実現することだといえます。

構成管理とは、ＣＩを定義し、正確な構成情報を維持する一連の活動です。それによりＩＴインフラストラクチャとサービスの論理モデルを提供します。

　資源管理が資産履歴の記録を主目的としているのに対して、構成管理ではシステム構成の整合性まで管理することを目的に、次のことを行います。

このような管理により、ＣＭＤＢを分析することにより、ＩＴサービスを行うインフラストラクチャの状況を正しく把握することができます。把握できるようにするのが構成管理の目的だともいえます。

キャパシティ管理（容量・能力管理）

例えば、取引の量が多くなると、データベースをアクセスするトランザクションが増大し、データベースの容量が大きくなりディスクの追加が必要になるとか、応答時間がＳＬＡで定めた時間より長くなるなどの現象が起こります。
　その状況を事前に把握して、重大な影響が生じないうちに、ハードウェアの増強を図ったり、処理を分散するなど運用方法を変更したりすることが必要になります。それをキャパシティ管理といいます。

キャパシティ管理のためには、トランザクションの増大などＩＴインフラストラクチャへの需要を予測する必要があります。このように、定期的にサービスに対する需要を把握して、将来の需要を予測して報告する仕組みを需要管理（#8.4.2）といいます。

キャパシティ計画

キャパシティ不足時の対策を検討することです。
　サーバを取り換える、メモリを増設するなどの対策、優先度の低い処理を止める、アクセス集中を回避するなど、多様な対策があります。
　特殊な機器の調達とかシステムの全面改訂など、対策が実現するまでに長期間かかり費用もかかるものもあります。また、不足の程度により、異なる対策を段階的に行うのが適切なこともあります。技術的進歩により、安価な対策が得られることもあります。
　そのため、多様な関係者による調査、代替案の列挙、定期的な見直しなどを行う仕組みを構築しておくべきです。

（狭義の）キャパシティ管理

日常的にキャパシティの余裕度や緊迫度を把握する分野です。次のような手順になります。

キャパシティ管理指標

容量・能力管理（#8.4.3）

キャパシティ管理を容量・能力管理として捉えたとき、単にハードウェアやソフトウェアだけでなく、人や財務なども対象にします。
　次の事項を含めて，容量・能力を計画しなければならないとしています。

ＩＴサービスの評価

留意事項
　JIS Q 20000 では、サービス提供者を独立した会計単位として、予算案提出から予算実績対比、費用対効果を行う業務を対象にしています。
　現実には、ＩＴサービスは（外部提供者への外注はあっても）ＩＴ運用部門の担当業務であり、ＩＴ開発部門などのＩＴ部門全体の一部ですから、ＩＴ予算管理と完全に分離するのは困難だと思われます。またＩＴ投資は通常の投資とは異なる視点が必要です。ところが、JIS Q 20000 では、これらの特殊性に関する言及はありません。

財務管理

財務管理はＩＴサービスに係るコストを明確にし、管理することで、次の３プロセスで構成されます。

サービスの予算業務及び会計業務（#8.4.1）

情報資産、共有資源、間接工数、外部の供給サービス、人的資源、保険、ライセンス等を含むさまざまな予算及び会計、サービスに対する間接費の割り当てと直接費の配分、効果的な財務管理と承認に関する方針及びプロセスを明確にします。