FAQ3：認証基準の解釈（ITSMS）
３１．認証基準本文
経営陣の責任の証拠：関係箇条（3.1）
Ｑ3101Ｔ．コミットメントの証拠を示すとは、どのようなことですか。
Ａ．JIS Q 20000-1:2007の箇条3.1には、以下のような記述があります。 「経営陣は、サービスマネジメントの能力を事業上の要求事項及び顧客要求事項との関連において開発、実装及び改善することへのコミットメントの証拠を、リーダシップ及び活動を通じて示さなければならない。」 また、上記の記述の後に、「経営陣は、次を実施しなければならない。」として、a)～g)までの事項を記述しています。
「サービスマネジメントの活動に対するコミットメントの証拠を経営陣が示す」とは、規格に記述されている事項について「経営陣が主体的に関与している記録を残すこと」と理解すればよいでしょう。記録の具体例としては、以下のようなものが挙げられます。
・経営陣が参画している会議体の議事録
・経営陣に対する報告資料
・経営陣からの指示資料 （通達文書、電子メールなど）
文書化の程度：関係箇条（3.2）
Ｑ3102Ｔ．サービスマネジメントにおいて作成する文書は、どの程度の内容を含むべきですか。
Ａ．JIS Q 20000-1:2007では、文書または記録に関する要求事項として箇条3.2があります。箇条3.2では、提供しなければならない文書及び記録として以下のものが挙げられています。
a) 文書化したサービスマネジメントの方針及び計画
b) 文書化したSLA
c) この規格が要求する、文書化したプロセス及び手順
d) この規格が要求する記録
しかし、文書の構成や含むべき内容について規格には明確な要求事項はありません。 したがって、組織が設計（構築）したサービスマネジメントを運用するために必要な事項を文書としてとりまとめることが望まれます。
ただし、ITSMS認証の取得を視野に入れた場合には、箇条3.2に挙げられている文書及び記録を整備することに加えて、規格に記述されている要求事項を満たしていることの立証が求められますので、規格要求事項を満たしていることを説明できるだけの文書化が必要となります。
力量とは：関係箇条（3.3）
Ｑ3103Ｔ．「力量」とは何ですか。
Ａ．規格で求められる「力量」とは、一般的に用いられるコンピテンシーや遂行能力と捉えるとわかりやすいと思われます。
「力量」に関しては、「ITSMSユーザーズガイド～導入のための基礎～」の「2.7. 力量」に詳しい説明がありますので、必要に応じて参照してください。
「ITSMSユーザーズガイド～導入のための基礎～」は、下記からダウンロードできます。
適用範囲設定時の考慮事項：関係箇条（4.1）
Ｑ3104Ｔ．サービスマネジメントの適用範囲として、考慮しなければならない要素とは何ですか。
Ａ．サービスマネジメントの適用範囲は、サービスマネジメントを実施する上で、意味のある活動となるように決定する必要があります。単に利潤の高いサービスに直接影響を及ぼすプロセスだけを取上げて適用範囲とするのではなく、間接的なプロセス間の連携や、取り交わされる情報処理についても考慮に入れ、サービスを実施する場所・施設、組織、インフラストラクチャーなどの要素を適用範囲として定義付けしていく必要があります。 また、適用範囲外となった部門やプロセスにおけるインターフェース（境界線）も明確にし、それらとの調整方法や、緊急時の対応なども視野にいれる必要があります。
資金及び予算の算出方法：関係箇条（4.2）
Ｑ3105Ｔ．資金及び予算については、前年度のサービスの売上げなどから、算出するのでしょうか。
Ａ．現実的には、サービスの売上げなどに比例して、予算が割当てられることも少なくはないと思います。
しかし、この規格で要求していることは、箇条4.1「サービスマネジメントの計画」のｆ）で検討されたリスクの特定及びアセスメントの結果からリスク管理のためにとるべき対策に必要な資金及び予算を試算し、予算化しておくことを指します。
安易に売上げの数%をサービスの運用・維持費に回すというような取組みではなく、将来的な容量・能力の拡張、可用性の増強、その他のリソース増加などの必要性を予測し、しっかりとしたリスクマネジメントにおけるリスク対応という形で予算化を図ることは、効果的なマネジメントシステムを構築する上で重要です。サービスの予算業務については、規格の箇条6.4の項目も参照してください。
監査の項目：関係箇条（4.3）
Ｑ3106Ｔ．監査員は、どのような項目について監査するのでしょうか。
Ａ．監査員は、サービスマネジメントの要求事項が、有効に実施され、かつ維持されているかについて監査します。 監査する事項については、サービス目標の達成度、顧客満足度、資源の稼働率等について、規格の要求事項との適合性を考慮にいれ、監査する必要があります（JIS Q 20000-2 4.3 監視、測定及びレビュー（check） 参照）。 特に、サービスの品質などに係る監査項目としては、要求事項である「6.1 サービスレベル管理」、「6.2 サービスの報告」、「8.2 インシデント管理」、「8.3 問題管理」などの状況を把握するための項目が挙げられるでしょう。 同様に、資源の稼動率などに係る監査項目は、「6,4 サービスの予算業務及び会計業務」、資源の状況については、「6.5 容量・能力管理」などの状況を把握するための項目が挙げられるでしょう。
変更管理との違い：関係箇条（5）
Ｑ3107Ｔ．「5新規サービス又はサービス変更の計画立案及び導入」と「9.2変更管理」との違いは何ですか。
Ａ．「5新規サービス又はサービス変更の計画立案及び導入」と「9.2変更管理」とは、『何らかの変更を管理するためのプロセス』という観点から見たときには本質的な違いはないと考えられます。ただし、それぞれのプロセスの主な対象が異なると捉えるとわかりやすいと思われます。
「5新規サービス又はサービス変更の計画立案及び導入」は比較的規模の大きなものを対象としていると考えられ、新規サービスを導入する際やサービス内容を変更する際には、当該サービスの導入や変更にともない、各プロセス（構成管理、変更管理、キャパシティ管理、可用性・継続性管理など箇条6以降のプロセス）で必要な準備を確実に実施することを求めている、とも捉えられます。
具体的な例としては、以下のようなものが考えられます。
・サービスリリースにあたっての、サービスカタログやCMDBの更新
・サービス導入・変更の影響を受ける利害関係者（顧客や供給者など）への説明と合意
・インシデント管理プロセスにおける監視対象やエスカレーションフローの見直し
SLAの位置付けと内容：関係箇条（6.1）
Ｑ3108Ｔ．SLAは契約書でも構いませんか。また、「保証」するものではなく「努力目標」でもよいのでしょうか。
Ａ．SLAに記載するべきサービスレベルなどの事項が記載されている文書であれば、契約書、標準約款、合意書等、どのような名称を採用しても構いません。また、契約書とは別にSLAを合意してもよいでしょう。
JIS Q 20000-1:2007の用語及び定義には、SLAはサービス及び合意したサービスレベルを記述したものとして定められていますので、サービスレベルの記載が求められます。また、サービスレベル目標に対するパフォーマンスに関する報告が求められていること（6.2「サービスの報告」）、可用性及びサービス継続に関する要求事項をSLA等に基づいて特定する必要があること（6.3「サービス継続及び可用性の管理」）などから、サービスレベル管理以外の要求事項についても考慮する必要があります。
ペナルティを求める「保証」とするか、あくまで「努力目標」とするかは、サービス提供者と顧客との間で合意できていればどちらでも構いません。
サービス報告の対象（報告先）：関係箇条（6.2）
Ｑ3109Ｔ．サービスの報告は誰に対して行うべきですか。
Ａ．JIS Q 20000-2:2007によれば、サービス提供者は、顧客及び経営陣のために報告書を作成することが望ましいとされています。
したがって、サービスの報告先は、サービス提供者の経営陣と顧客ということができます。経営陣に対してはマネジメントレビュー（4.3「監視，測定及びレビュー（Check）」参照）として、顧客に対してはサービスレビュー会議（7.2「顧客関係管理」参照）を通じて、報告することが考えられます。
可用性とサービス継続性の相違点：関係箇条（6.3）
Ｑ3110Ｔ．可用性管理とサービス継続性管理はそれぞれ異なるものですか。
Ａ．可用性の管理とサービス継続性の管理は、どちらも『顧客がサービス利用可能な状態』を維持すること、平易に言えば（あらかじめ約束した）『サービス提供を止めないこと』を目的としています。 可用性管理は日常的に発生する障害や不具合などに着目しており、サービス継続性管理は災害発生時や大規模なシステム障害等を対象にしていると整理するとよいでしょう。
「ITSMSユーザーズガイド－JIS Q 20000（ISO/IEC 20000）対応－」の「6.3サービス継続及び可用性の管理」に詳しい説明がありますので、必要に応じて参照してください。 「ITSMSユーザーズガイド-JIS Q 20000（ISO/IEC20000）対応－」は、下記からダウンロードできます。
効果的な財務管理とは何か：関係箇条（6.4）
Ｑ3111Ｔ．「効果的な財務管理」とは、具体的にはどのような管理方法等を言うのでしょうか。
Ａ．何を以って効果的と判断するかは極めて難しいところですが、予算化や会計業務上の意思決定及び承認ができる詳細さがあり、財務予測をするうえでも十分役に立つ情報が提供できる状態にあることなどを総合的に勘案し、効果的な管理と言えるものと考えられます。
具体的には、予算化等にあたっては十分詳細な管理費目とすること、予算業務及び会計業務のプロセスが明確に定められていること、費用を監視し財務予測を行うこと、然るべき承認がなされていること等によって、効果的な財務管理ということができます。箇条6.4内の前後の要求事項を満たすことにより、効果的な財務管理を実現させることができると整理するとよいでしょう。
容量・能力の「しきい値」とは何か：関係箇条（6.5）
Ｑ3112Ｔ．サービス拡張のための「しきい値」とは何ですか。
Ａ．サービス提供者が用意しているシステムコンポーネントや設備は無限にあるものではありません。一定以上の容量や処理能力を超えたサービスのリクエストは品質低下を招く可能性があります。具体的には、パフォーマンスの低下やシステムダウンにもつながってしまいます。人的資源不足によって手が回らないなどの状態も考えられます。
そのような状態にならないために、容量・能力が危険水域に達した状態、もしくはその前段階で警告（アラート）を発し、各種資源を増強・拡張させる必要があります。この危険水域を「しきい値」と言います。
情報セキュリティインシデントとインシデント管理：関係箇条（6.6）
Ｑ3113Ｔ．情報セキュリティインシデントは、その他インシデントと同様のインシデント管理手順で扱うべきですか。
Ａ．JIS Q 20000-1:2007の箇条6.6には、以下のような記載があります。
「情報セキュリティインシデントは、インシデント管理手順に従って、できる限り速やかに報告し、かつ、記録しなければならない。」
上記にある「インシデント管理手順」ですが、箇条8.2 「インシデント管理」で要求されている手順と同一の手順であることは必ずしも求められていないと考えられます。
情報やデータが紛失・漏洩したなどの情報セキュリティインシデントとその他のインシデントを全く同じ手順で扱うことは、実際には難しい場合があるかもしれません。もちろん、同一の手順や様式を採用しても構いません。ただし、情報セキュリティインシデントは他のインシデントと識別させるなど、サービス提供者が管理しやすく工夫するとよいでしょう。
顧客満足度調査：関係箇条（7.2）
Ｑ3114Ｔ．「顧客満足度の定期的な測定結果」を得るために、顧客満足度調査を実施しなければなりませんか。
Ａ．顧客に対するアンケート調査のようなものを実施することは必ずしも要求されていません。
JIS Q 20000-1:2007の箇条7.2で要求されていることは、「顧客満足度を測定すること」と「測定結果に応じた対応をすること」の2点であると考えられます。したがって、必ずしも「顧客満足度調査アンケート」のような形態をとる必要はなく、たとえば営業担当者やお客様窓口などの顧客インタフェースにおける聞き取り調査などで測定することも可能だと考えられます。
供給者とのSLA：関係箇条（7.3）
Ｑ3115Ｔ．供給者とのSLAは必ず締結しなければなりませんか。
Ａ．JIS Q 20000-1:2007では、以下のように記述されています。
「供給者が提供する、要求事項、適用範囲、サービスレベル及びコミュニケーションプロセスを、SLA又は他の文書の中で文書化し、かつ、すべての関係者の合意を得なければならない。」
この要求事項は、「サービスレベル」を文書化して合意することを求めています。FAQ3108「SLAの位置付けと内容」と同様に、名称や未達時のペナルティの有無などは組織と供給者（及び顧客）の間で合意ができれば、どのような形態であっても問題にはなりません。
インシデントの記録：関係箇条（8.2）
Ｑ3116Ｔ．「すべてのインシデントを記録」とありますが、どのような範囲で「すべて」記録するのですか。
Ａ．組織が記録すると決定した「インシデント」について「すべて」記録をとる、と理解すればよいと考えられます。
どの程度の範囲や詳細さでインシデントの記録を取得すべきかについては、求められるサービスレベルや顧客からの要望などを踏まえて検討するとよいでしょう。ただし、顧客へ影響を与える可能性のあるものやサービスレベルを低下させる可能性のあるもの、及びそれらの原因となり得るものについては記録を取得しておくことが望ましいと考えられます。
また、記録をとる方法は、たとえばサービスデスクツールなどのシステムが有用であることも多いですが、必ずしもシステム化されている必要はありません。組織が採りうる選択肢を挙げて、現実的な方法を採用すればよいでしょう。
問題解決の有効性の監視：関係箇条（8.3）
Ｑ3117Ｔ．「問題解決の有効性を監視」とは、どのようなことですか。
Ａ．組織で特定した問題を解決するために行った処置（多くの場合は変更の実装）が、問題の解決に役立っているかどうかを継続的に確認することを指しています。言い換えると、単一あるいは複数のインシデントの根本原因として識別された問題を解決するために実装した変更によってインシデントの再発が防止されたかどうかを確認すること、と捉えられます。
問題に対するレビューについては、JIS Q 20000-2:2007の箇条8.3.8、8.3.9に補足がありますので、必要に応じて参照してください。
変更管理と構成管理の統合的な取組みとは：関係箇条（9.1）
Ｑ3118Ｔ．「変更管理及び構成管理の計画立案について、統合的な取組みを備える」とはどのようなことですか。
Ａ．JIS Q 20000-1:2007の解説の箇条5.2.10には、以下のような記述があります。
「この部分は、変更管理と構成管理の連携が特に重要視される必要があることを示していると考えられるだろう。」
これは、構成管理が、「正確な構成情報の維持」を目的としていることから、変更を制御する変更管理とは密接な連携をする必要がある、ということを指しています。 構成情報の正確性を維持するためには、構成情報を変える必要がある変更が生じた場合に、その「変更の情報」を構成管理にインプットする必要があります。したがって、構成管理と変更管理は同じ範囲を対象とすることが必要であると考えられます。
構成管理と変更管理の適用範囲の考え方については、「ITSMSユーザーズガイド～導入のための基礎～」の「3.2.1.すべての管理プロセスを整備する b） 構成管理と変更管理」に詳しい説明がありますので、必要に応じて参照してください。
「ITSMSユーザーズガイド～導入のための基礎～」は、下記からダウンロードできます。
構成品目の詳細さ：関係箇条（9.1）
Ｑ3119Ｔ．管理すべき構成品目の詳細さについて、最低限求められることはありますか。
Ａ．JIS Q 20000-1:2007の箇条9.1構成管理には、構成品目の詳細さについては明確に要求されていません。
ただし、以下のような記述があります。
「構成品目及びそれを構成するコンポーネントとして、何を定義するかについての方針を備えなければならない。」 「構成管理は、サービス及びインフラストラクチャの識別可能なコンポーネントの版を識別し、制御し、かつ、追跡するための仕組みを提供するものでなければならない。また、制御の程度が事業上の必要性、失敗のリスク及びサービスの重要性に十分見合うことを、確実にするものでなければならない。」
したがって、構成品目の詳細さについては、ITSMSを導入する組織において決定する必要があります。逆に言えば、どのような構成品目について、どこまでの情報を管理するか、を明確に決めておくことが重要となります。ただし、少なくとも、「○○サービス一式」のように、登録された構成品目と実際の「モノ」を対応付けることが難しくなるような粗さでは十分ではないと考えられます。
CMDBのシステム化：関係箇条（9.1）
Ｑ3120Ｔ．CMDBは、システム化しなければなりませんか。
Ａ．CMDBのシステム化は必須ではありません。
表計算ソフトやデータベースソフトなどを活用して構成管理を行うこともできます。ただし、その場合には、CMDBへの更新アクセスを厳重に管理し、データの信頼性及び正確性を確実にするためのアクセス制御などが重要となります。
比較的大きな範囲（対象となるサービスやコンポーネント、対象となる要員などが多い範囲）でITSMSを導入する場合には、システム化するメリットがあると考えられます。システム化する場合には、管理する範囲や登録すべき情報などについて、実装前（設計段階）に綿密な検討をしておくことが重要です。
変更分析から得られる結果及び結論：関係箇条（9.2）
Ｑ3121Ｔ．変更分析から得られる結果及び結論とは、例えばどのようなものですか。
Ａ．JIS Q 20000-1:2007には、変更分析からどのような結果及び結論を得なければならないかについては具体的な要求はありませんが、変更記録を定期的に分析することの目的として、以下の事項が挙げられています。
「変更量の増加、頻繁に再発する種類、新しい傾向、その他の関連情報を把握するため」
したがって、JIS Q 20000-1:2007に掲げられている事項については、変更分析によって最低限把握しておく必要があると考えられます。
また、最低限把握するべき事項のほかにも、変更分析によって例えば以下のような課題点がわかる場合もあります。
・処理されていない変更が多い ⇒ 変更管理を担当する人的リソースが不足している可能性がある
・変更の失敗率が高い ⇒ 変更の事前評価（アセスメント）が十分ではない可能性がある
・機能増強の変更要求が多くなってきた ⇒ コンポーネントの性能が不足してきた可能性がある
変更管理とリリース管理プロセスの「元に戻す方法又は修正する方法」の違い：関係箇条（10.1）
Ｑ3122Ｔ．変更管理にある「元に戻す方法又は修正する方法」とリリース管理プロセスにある「元に戻す方法又は修正する方法」は何が違うのですか。
Ａ．基本的には、変更管理とリリース管理プロセスにある「元に戻す方法又は修正する方法」は同じものと捉えて問題ないと考えられます。
JIS Q 20000-1:2007に記述されている「元に戻す方法又は修正する方法」は、一般に「切り戻し計画」と呼ばれているものと考えられます。したがって、「元に戻す方法又は修正する方法」とは、何らかの変更をリリース（実装）する際に、うまくいかなかった場合に備えて準備しておくべき対応であり、リリースごとに準備しておいて差し支えはないでしょう。ただし、変更管理では、リリースにあたって「元に戻す方法又は修正する方法」が検討されていることを監視しておくことが重要です。
なお、JIS Q 20000-1:2007では、「元に戻す方法又は修正する方法」について具体的に言及されていないため、変更管理とリリース管理プロセスの「元に戻す方法又は修正する方法」は、必ず同一であることまでは要求されていないと考えられます。
独立した受入れ試験環境の必要性：関係箇条（10.1）
Ｑ3123Ｔ．すべての変更・リリースを試験するために、すべての環境に対応した、独立した試験環境は必要ですか。
Ａ．JIS Q 20000-1:2007には、受入れ試験環境に関して、「制御された受入れ試験環境を確立しなければならない。」と記述されています。したがって、必ずしも独立した受入れ試験環境をすべての環境に準備することは要求されていないと考えられます。
受入れ試験環境の考え方については、「ITSMSユーザーズガイド～導入のための基礎～」の「3.2.1.すべての管理プロセスを整備する d） その他の留意事項」に説明がありますので、必要に応じて参照してください。
「ITSMSユーザーズガイド～導入のための基礎～」は、下記からダウンロードできます。