情報技術−サービスマネジメント−
第 2 部:サービスマネジメントシステムの適用の手引
JIS_Q_20000-2:2010
 
 

目 次

Links


  • Q 20000-2:2013 (ISO/IEC 20000-2:2012)

目 次

0.1 序文 0.2 サービスマネジメントシステムの適用の手引 1 適用範囲 1.1 一般 1.2 適用 2 引用規格 3 用語及び定義 4 サービスマネジメントシステム(SMS)の一般要求事項 4.1 経営者の責任 4.2 他の関係者が運用するプロセスのガバナンス 4.3 文書の運用管理 4.4 資源の運用管理 4.5 SMS の確立及び改善 5 新規サービス又はサービス変更の設計及び移行プロセス 5.1 一般 5.2 新規サービス又はサービス変更の計画 5.3 新規サービス又はサービス変更の設計及び開発 5.4 新規サービス又はサービス変更の移行 5.5 文書及び記録 5.6 権限及び責任 6 サービス提供プロセス 6.1 サービスレベル管理 6.2 サービスの報告 6.3 サービス継続及び可用性管理 6.4 サービスの予算業務及び会計業 6.5 容量・能力管理 6.6 情報セキュリティ管理 7 関係プロセス 7.1 事業関係管理 7.2 供給者管理 8 解決プロセス 8.1 インシデント及びサービス要求管理 8.2 問題管理 9 統合的制御プロセス 9.1 構成管理 9.2 変更管理 9.3 リリース及び展開管理 附属書 A(参考)プロセス間のインタフェース及びプロセスと SMS との統合 参考文献


  • 日本工業規格
  • JIS Q 20000-2:2013(ISO/IEC 20000-2:2012)
  • 情報技術−サービスマネジメント−
  • 第 2 部:サービスマネジメントシステムの適用の手引
  • Information technology-Service management-
  • Part 2: Guidance on the application of service management systems

0.1 序文

 この規格は,2012 年に第 2 版として発行された ISO/IEC 20000-2 を基に,技術的内容及び構成を変更することなく作成した日本工業規格である。  なお,この規格で点線の下線を施してある参考事項は,対応国際規格にはない事項である。  この規格で,“注記”と記載されている情報は,関連する要求事項の内容を理解するための,又は明確にするための参考情報である。

0.2 サービスマネジメントシステムの適用の手引

 この規格は,JIS Q 20000-1 を基礎とするサービスマネジメントシステム(以下,SMS という。)の適用に関する手引を提供する。この規格は,JIS Q 20000-1 に規定された要求事項とは別に,更なる要求事項を加えるものではなく,また,いかにして評価者又は監査員に証拠を提示することができるかを明示的に示すものでもない。この規格の意図は,組織及び個人が JIS Q 20000-1 をより正確に解釈することによって JIS Q 20000-1 をより効果的に利用できるようにすることにある。  JIS Q 20000-1 には,“SMS”は“サービス提供者のサービスマネジメントの活動を指揮し,監視し,管理するためのマネジメントシステム”と定義されている。SMS は,サービスの計画立案,設計,移行,提供及び改善に必要なものを含むことが望ましい。これには少なくとも,サービスマネジメントの方針,目標,計画,プロセス,プロセス間のインタフェース,文書及び資源が含まれる。SMS は,SMS の一部としてサービスマネジメントのプロセスを備えた包括的なマネジメントシステムとしての全てのプロセスを包含する。 SMS を調整のとれた形で統合し,かつ,導入することによって,継続的な管理,より高い有効性,効率性及び継続的改善の機会が得られる。SMS によって,組織はビジョンを共有しながら効果的に活動できる。箇条 5−箇条 9 に規定するプロセスの運用には,人材を適切に組織し,かつ,調整することが必要である。サービスマネジメントのプロセスを効果的かつ効率的なものとするために,適切なツールを使用してもよい。最も効率的な組織は,計画立案・設計から,移行,運用までの,継続的改善を含むサービスのライフサイクルの全ての段階における SMS への影響を考慮する。  この規格は,組織が,ISO/IEC 20000 規格群の他の部及び他の関連規格を参考にすることを含めて,JIS Q 20000-1 を解釈し,それを適用できるようにするための例及び提言を示している。  この規格の利用者は,正しい適用に関して責任がある。ISO/IEC 20000 規格群を利用する組織及び個人は,次の事項を理解することが重要である。 − JIS Q 20000-1 は,必要な全ての法令・規制要求事項又はサービス提供者の全ての契約上の義務を含んではいない。JIS Q 20000-1 に適合しても,それだけで法的義務を免除されるものではない。 − JIS Q 20000-1 は,社内及び社外の,大規模及び小規模の,並びに営利及び非営利のサービス提供者に対して適用可能である。 − JIS Q 20000-1 は,サービスの要求事項を満たしたサービスを,設計,移行,改善及び提供することを目的とした SMS の計画,確立,実施,運用,監視,測定,レビュー,維持及び改善を行うときに,統合されたプロセスアプローチを採用することを促進する。 ISO/IEC 20000 規格群は,“計画(Plan)-実行(Do)-点検(Check)-処置(Act)”(PDCA)として知られる方法論の SMS 及びサービスへの適用を促進する。図 1 に示す PDCA 方法論を簡潔に説明すると,次のようになる。

  • 計画(Plan):事業ニーズ,顧客要求事項及びサービス提供者の方針に従ってサービスを-設計し,提供するために必要となる方針,目的,計画及びプロセスを含む SMS を確立し,文書化し,それに合意する。
  • 実行(Do):サービスの設計,移行,提供及び改善のための SMS を導入し,運用する。
  • 点検(Check):計画,方針,目的及びサービスの要求事項について,SMS 及びサービスを監視,測定及びレビューし,それらの結果を報告する。
  • 処置(Act):SMS のパフォーマンスを継続的に改善するための処置を実施する。これにはサービスマネジメントのプロセス及びサービスを含む。  次の事項は,SMS の範囲内で用いる場合,統合されたプロセスアプローチ及び PDCA 方法論の最も重要な側面である。
  • a) 顧客満足を達成するためのサービスの要求事項を理解し,満たす。
  • b) サービスマネジメントの方針及び目的を確立する。
  • c) SMS に基づいて,顧客に付加価値のあるサービスを設計し,提供する。
  • d) SMS 及びサービスのパフォーマンスを監視し,測定し,レビューする。
  • e) 客観的測定に基づいて,SMS 及びサービスを継続的に改善する。  他のマネジメントシステムが存在する場合,プロセスアプローチ及び PDCA 方法論を採用して SMS を導入することによって,サービス提供者は,組織のマネジメントシステムとの整合を図る,又は完全に統合することができる。例えば,JIS Q 20000-1 を JIS Q 9001 に基づく品質マネジメントシステム及び/又は JIS Q 27001 に基づく情報セキュリティマネジメントシステムと統合することができる。統合マネジメントシステムアプローチは,効率性を高め,説明責任の明確な所在及びトレーサビリティについて確立し,組織の計画立案,コミュニケーション及び管理を向上させる。

図 1−サービスマネジメントに適用される PDCA 方法論

 JIS Q 20000-1 は,次のとおり規定している。  この規格は,次の組織,サービス提供者又は審査員若しくは監査員が利用してもよい。 a) サービス提供者からのサービスを求め,サービスの要求事項が満たされるという保証を必要とする組織 b) サプライチェーンに属するものを含め,全てのサービス提供者による一貫した取組みを求める組織 c) サービスの要求事項を満たすサービスの設計,移行,提供,及び改善に関する能力を実証しようとするサービス提供者 d) 自らのサービスマネジメントのプロセス及びサービスを,監視,測定及びレビューするサービス提供者 e) サービスの設計,移行及び提供を,SMS の効果的な導入及び運用を通して改善するサービス提供者 f) この規格の要求事項に対するサービス提供者の SMS の適合性評価に,基準として用いる審査員又は監査員  この規格は,認証を求めるか否かに関係なく,サービスマネジメントの改善方法に関する手引を必要とする組織が利用することができる。

1 適用範囲

1.1 一般

 この規格は,JIS Q 20000-1 に基づく SMS の適用に関する手引を示す。この規格は,組織が,ISO/IEC 20000 規格群の他の部及び別の関連規格を参考にすることを含めて,JIS Q 20000-1 を解釈し,それを適用できるようにするための例及び提言を示す。この規格は,個別のベストプラクティスの枠組みから独立したものであり,サービス提供者は一般に受け入れられた手引と独自の手法との組合せを適用することができる。

図 2−サービスマネジメントシステム(SMS)

 図 2 の中央ボックス部分に,箇条 6−箇条 9 のプロセスを示す。箇条 6−箇条 9 のプロセスを取り囲んでいるのが,箇条 5 の新規サービス又はサービス変更の設計及び移行プロセスである。これは,新規サービス又はサービス変更が,中央ボックス部分のプロセスによって運用されることを示す。箇条 5 が適用される新規サービス又はサービス変更がない場合,全てのサービスは直接,箇条 6−箇条 9 によって提供することができる。  サービスマネジメントのプロセス間のインタフェースと SMS の各コンポーネントとの関係は,サービス提供者が異なれば,異なるように実現してもよい。サービス提供者と顧客との関係の性質が,どのように SMS を導入し,JIS Q 20000-1 の要求事項を満たすかに影響することもある。そのため,プロセス間のインタフェースは,図 2 には示していない。

1.2 適用

 サービス提供者には,SMS の説明責任があり,他の関係者に JIS Q 20000-1 の箇条 4(サービスマネジメントシステムの一般要求事項)の要求事項を満たすことを要求することはできない。例えば,サービス提供者は他の関係者に対して,トップマネジメントを提供し,トップマネジメントのコミットメントを実証したり,又は他の関係者が運用するプロセスのガバナンスを実証するように求めることはできない。  JIS Q 20000-1 の箇条 4 に示す活動の中には,サービス提供者の管理下で他の関係者が実施するものがある。例えば,サービス提供者は,自身の代わりに内部監査を実施する第三者を雇うことができる。サービス提供者が他の関係者に初期のサービスマネジメントの計画を立てるように求めるのも,その一例である。計画は,それが立案され,同意されれば,サービス提供者が直接の責任をもち,維持するものとなる。こうした例では,サービス提供者が,他の関係者を個別の短期的活動のために使用する。サービス提供者は,SMS に関する説明責任,権限及び責任をもつ。そのため,サービス提供者は,JIS Q 20000-1 の箇条 4 の要求事項を全て満たしているという証拠の提示ができる。  サービス提供者は,全ての要求事項を直接満たしているという証拠,又は他の関係者が運用するプロセスのガバナンスの証拠とともに,大半の要求事項を直接満たしているという証拠を示すことができる。JIS Q 20000-1 の箇条 5−箇条 9 のプロセスの過半数の運用について,サービス提供者が他の関係者に依存している場合,サービス提供者はプロセスのガバナンスを実証することはできない。ただし,他の関係者がごく少数のプロセスを運用しているだけの場合,サービス提供者は,通常,JIS Q 20000-1 に規定する要求事項を満たすことができる。  SMS に関して,定義し,合意し,及び文書化した,並びにこれらの説明責任,権限及び責任は,サービス提供者と他の関係者との双方が利用できるようにしておく。JIS Q 20000-1 の要求事項を満たすために,サービス提供者は,既存の契約又は他の合意文書の条項に対する変更に合意することが可能となる。  ISO/IEC 20000 規格群には,いかなる製品・ツールの使用又はその具体的な手引も記載していない。しかし,組織はこの規格を利用して,SMS の運用を支援する製品又はツールの使用又は開発に役立てることができる。  注記 この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。   ISO/IEC 20000-2:2012,Information technology−Service management−Part 2: Guidance on the application of service management systems(IDT)   なお,対応の程度を表す記号“IDT”は,ISO/IEC Guide 21-1 に基づき,“一致している”ことを示す。

2 引用規格

 次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。この引用規格は,その最新版(追補を含む。)を適用する。  JIS Q 20000-1 情報技術−サービスマネジメント−第 1 部:サービスマネジメントシステム要求事項  注記 対応国際規格:ISO/IEC 20000-1,Information technology−Service management−Part 1: Service management system requirements(IDT)

3 用語及び定義

 この規格で用いる主な用語及び定義は,JIS Q 20000-1 による。

4 サービスマネジメントシステム(SMS)の一般要求事項

4.1 経営者の責任

4.1.1 経営者のコミットメント 4.1.1.1 トップマネジメントの責任  トップマネジメントは,最高位でサービス提供者を指揮し,監視し,管理する経営者であることが望ましい。  トップマネジメントは,JIS Q 20000-1 の要求事項を満たすことに,次の事項が含まれていることを認識することが望ましい。 a) SMS の計画及び確立に始まり,SMS の運用,監視,測定,レビュー,維持及び継続的改善に至る SMS の全段階に関与するコミットメントを実証する。 b) SMS に関する説明責任及び責任を実証する。 c) SMS の全ての利害関係者がサービスの要求事項,SMS の適用する範囲(以下,適用範囲という。),及びサービスマネジメントの方針・目的を理解し,認識していることを確実にする。 d) サービスマネジメントの計画を,作成し,実施し,維持し,事業目的に整合することを確実にする。 e) サービスマネジメントの目的を達成し,サービスマネジメントの方針を順守するように,適切な資源の提供を確実にする。 f) SMS のパフォーマンスをトップマネジメントのレベルまで報告することを確実にする。 g) 事業ニーズ又はサービスの要求事項の変化に応じて変わる場合を含めて,サービスマネジメントの目的を達成する。 h) 変更に伴うリスクのアセスメント,処置の実施などによって,サービスに対するリスクを最小限にすることを確実にする。

 さらに,トップマネジメントは,サービスのライフサイクルの全ての段階が,サービスの要求事項に定義されたとおりに,合意したレベルに到達していることを確実にすることが望ましい。サービスのライフサイクルは,計画立案,導入,運用,監視,測定,レビュー,維持及び継続的改善を含む。また,サービスのライフサイクルは,サービスの顧客若しくは他の関係者への移管,又は最終的なサービスの廃止を含む。  トップマネジメントは,SMS 及び SMS によって提供されるサービスのアセスメント及びレビューを実施することを確実にすることについて,説明責任があることを認識することが望ましい。アセスメントには,サービス提供者自身によるレビュー及び内部監査,並びに外部監査を含めることが望ましい。マネジメントレビューに関する詳細は,4.5 に示す。

4.1.1.2 トップマネジメントのコミットメントの証拠  経営者のコミットメントがない場合には,効果的な SMS となるための要求事項と両立しない経営者の決定が下される可能性がある。例としては,他のプロジェクトへの資源の再配分,SMS に関するコミュニケーションの欠如,プロセス設計における未解決の矛盾などがある。  監査員によるレビューのために利用できる,経営者のコミットメント及び説明責任の証拠があることが望ましい。トップマネジメントは,次の業務への関与の記録に基づいて,証拠を提示できることが望ましい。 a) SMS に関する定例会議。例えば,SMS が事業ニーズ,及び新規サービス又はサービス変更の要求事項に引き続き整合するようにするために,計画会議で議長を務める。 b) SMS に,適用範囲の定義,サービスマネジメントの方針,サービスマネジメントの目的及びサービスマネジメントの計画を確実に含める。 c) サービスマネジメントの方針,サービスマネジメントの目的及びサービスマネジメントの計画の承認 d) SMS の方針に整合し,それを支援するプロセス及び手順の承認

 トップマネジメントによるサービスマネジメントの計画の承認は重要である。なぜならば,この計画は,顧客へのコミットメント,供給者のための計画立案活動,並びに改善及びその他の変更のための資源配分に影響することがあるからである。  方針,プロセス及び手順を整合させることで,トップマネジメントの指示がサービス提供者の全ての要員に行き届くようになる。これによって,経営者の決定が,サービス提供者の要員による日々の運用方法と整合することが望ましい。

4.1.1.3 トップマネジメントのコミュニケーション   トップマネジメントは,進行中のコミュニケーションのプログラムに積極的に関与することが望ましい。コミュニケーションは,4.1.3.2 に規定する承認されたコミュニケーション手順によって,直接指示されることが望ましい。  トップマネジメントは,確立された SMS が事業目的及び顧客の期待に整合していることを説明するために,進行中のコミュニケーションのプログラムに積極的に関与することが望ましい。このことは,SMS を成功させるために重要である。なぜならば,要員が SMS の目的及び重要性を理解している場合,不安又は知識不足からくる変更に対する抵抗感が少なくなるからである。SMS に関するトップマネジメントのコミュニケーションは,サービス提供者が自らの組織に意欲を起こさせる機会となる。また,トップマネジメントと要員との双方が SMS の重要性を尊重することによって,SMS に矛盾する決定がされたり,SMS に矛盾する解決策が実行されたりするリスク又は可能性を低減することが望ましい。  コミュニケーションのプログラムでは,次の事項について説明することが望ましい。 a) 組織の変更,方針,標準,ビジョン及び使命,並びに事業目標 b) 事業ニーズ。例えば,SMS と提供されるサービスとの関係,並びにそれらが定義された組織の目標及び目的をどのようにして支援するか。 c) 確立された SMS が,どのように事業目標及び顧客の期待と整合しているか。 d) サービスマネジメントの方針,目的及び計画が,どのようにしてサービスの要求事項の達成を支援するか。 e) 顧客要求事項。例えば,サービス目標,予測需要に基づいて予測された容量・能力,情報セキュリティ及び事業継続を支えるサービスの継続性 f) 労働時間,安全衛生,データ保護などの法令要求事項 g) 記録を一定の期間保存しておくなどの規制上の要求事項 h) 契約に関する要求事項。例えば,サービス提供者の情報にアクセスする前に秘密保持契約に署名するという要求事項 i) 顧客との合意文書 j) プロセス測定など,SMS 及びコンポーネントの測定によって集めたデータの定期的な分析

 さらに,コミュニケーションは,サービス提供者が自身の組織に意欲を起こさせる機会となる。  コミュニケーションのプログラムは,SMS を成功させるために重要である。なぜならば,SMS の目的及び重要性を理解している要員は,不安又は知識不足からくる変更に対する抵抗感が少なくなるからである。コミュニケーションによって,経営者と要員との双方の,SMS の重要性についての理解が深まり,SMS と対立する決定がされたり,解決策が実行されたりするようなリスク又は可能性を低減することが望ましい。  これらのコミュニケーション活動の成果は,人々がサービスマネジメントにおける自身の役割を理解し,いかにして自らがサービスの要求事項を満たし,サービスマネジメントの目的に合致することに貢献しているかを理解することとなることが望ましい。

4.1.1.4 サービスマネジメントの目的  トップマネジメントは,合意されたサービスマネジメントの目的を定義することが望ましい。目的は,事業目的及びサービスマネジメントの方針に整合することが望ましい。  例えば,一般的なサービスマネジメントの目的には,次の事項が含まれる。 a) 新規サービス又はサービス変更を迅速に提供して,事業の機敏性を高められるようにする。 b) 事業上重要なサービスについて,計画外の非可用性を低減する。 c) 運用効率によって,提供するサービスの費用を最適化する。 d) リスクを低減しながらサービスの質を高める。

 実際のサービスマネジメントの目的は,目的に対する達成度を正確に測定できるように定義することが望ましい。測定は,改善の機会の優先度付けも可能にすることが望ましい。  目的は,サービスマネジメントの計画の主要なインプットとなることが望ましい。計画は,目的の達成及び SMS の他のコンポーネントとの整合のための処置を特定することが望ましい。  サービスマネジメントの目的は,いつ,どのようにして目的を改訂することが望ましいかをトップマネジメントが決められるように,一定の間隔でレビューすることが望ましい。  サービス提供者は,サービスマネジメントの目的を支援する上での有効性のアセスメントを行うために,SMS の各コンポーネントの有効性を測定することを確実にすることが望ましい。例えば,ある特定のプロセスによって,目的が支援される有効性の測定である。また,測定は,事業目的を支援する上での SMS の価値を実証するものであることが望ましい。  サービス提供者には,目的の達成に向けた個人の貢献度の測定が役立つことがある。これが,SMS を支援する要員が,同じ到達目標に向かって一丸となって働くことを促進する。

4.1.1.5 サービスマネジメントの計画  サービスマネジメントの計画は,サービスマネジメントの目的の達成を確実にするために,全ての SMSの取組みの調整を促進することが望ましい。また,計画と方針とを一致させることが望ましい。  計画は,全体(end-to-end)の可視性及び管理を可能にする強力な仕組みになり得る。また,計画は,両立しない取組みが承認又は実施されることを予防することが望ましい。計画は,資源及び能力が可能な限り効率的かつ効果的に利用されることを可能にすることが望ましい。  計画は,全ての利害関係者に周知させることが望ましい。これは,取組みの適用範囲,作業,時間枠及び割り当てられた責任に対する共通の理解を確実にするものであることが望ましい。割り当てられた責任は,サービスマネジメントの計画の取組みに関与する人を含めて,SMS に関与する全員のパフォーマンスの測定に含めることが望ましい。  計画は,SMS を導入したときに完了するものと考えないほうがよい。計画は,変化する事業ニーズ,顧客要求事項又はサービス提供者の優先度に対応するように修正され続けることが望ましい。  サービスマネジメントの計画は,一つの計画で構成されることもあるが,調整された変更のプログラムで構成されることもある。そのプログラムの一部は局所的に導入されることもあるが,中央で管理される。  サービス提供者は,サービスマネジメントの計画の全般的な管理下で,局所的に全ての変更を導入する必要性を常に認識していることが望ましい。例えば,あるプロセスの改善は,局所的な制御プロセスオーナの下で局所的に実施してもよいが,その改善は,中央で管理されるプログラム全体に含まれる。  サービス継続及び可用性管理プロセスなどの個々の目的に対する計画は,個々に含めるよりもサービスマネジメントの計画全体から参照するとよい。専門的な計画及びそれらと計画全体との整合性については,変更の度合いに適した頻度でレビューすることが望ましい。レビューは,少なくとも年に 1 回行うことが望ましい。  レビューによって生じる変更,サービスの要求事項の変更によって生じる変更,又は個々の計画の変更によって生じる変更は,いずれもサービスマネジメントの計画全体において文書化することが望ましい。例えば,24 時間運用への勤務時間の変更,代替技術への変更又は技能の変化である。  サービスマネジメントの計画の内容には,次の事項を含めることが望ましい。 a) 序文 b) サービス提供者の組織の機能に関する記述 c) 取組みの優先度 d) 事業目的に整合した,期待される成果 e) パフォーマンスの指標 f) サービス目標 g) プロジェクト計画 h) 作業及び依存関係 i) 前回までに実施した改善の結果として達成した,利益の実現度 j) 期間及び計画の取組みの実施責任者 k) リスク及びリスク軽減策

 サービスマネジメントの計画のリスクは,最初に,及び PDCA 方法論の一部としての両方で特定し,アセスメントを行い,管理することが望ましい。リスクアセスメントには,リスク軽減のための,インプット,アウトプット,活動並びに責任及び説明責任を含めることが望ましい。また,計画は,合意した目的及びサービスの要求事項を達成することを確実にするように設計することが望ましい。

4.1.1.6 サービスマネジメントの計画を支援する資源  サービスマネジメントの目的の達成に必要な資源は,サービスマネジメントの計画において文書化することが望ましい。また,次の事項を検討することが望ましい。 a) 人的資源の獲得では,単に人数に基づくだけでなく,個人の技能及び経験を考慮することが望ましい。 b) 技術的資源。例えば,要求されるパフォーマンスを達成するためのインフラストラクチャ及び容量・能力 c) SMS のプロセスを支援するためのツール d) オフィスの施設,他の設備及びサービス継続のための設備 e) データ及び情報。例えば,顧客要求事項,顧客の事業計画,サービス提供者の事業ニーズ,サービスマネジメントの方針,パフォーマンスの測定及び他の報告書の詳細 f) SMS の計画,導入,運用及び改善を管理するために,適切な詳細さで組まれた予算の財源 g) サービス提供者の要員の数及び利用可用性,並びにその勤務時間 h) 適切な技能をもつ要員の投入,保持及び交代の計画立案のためのプロセス,手順及び期間

4.1.1.7 サービスの要求事項の内容  JIS Q 20000-1 の 3.34(サービスの要求事項)の定義は,顧客及びサービスの利用者のニーズ並びにサービス提供者のニーズを含んでいる。トップマネジメントは,提供されるサービスが合意したサービスの要求事項を満たすことを確実にすることに責任をもつことが望ましい。  稼働環境のサービスと同様に,新規サービス又はサービス変更との継続的な整合を確実にするため,顧客要求事項と事業ニーズとの両方を文書化し,監視し,レビューし,管理することが望ましい。  サービスの要求事項には,要求されるサービス目標及び期待される品質を含めることが望ましい。サービス提供者のニーズには,資源及び能力の要求事項の詳細を含めることが望ましい。サービスの要求事項は,図 2 に示すとおり,SMS へのインプットとなる。  サービスの要求事項の例には,次の事項を含むことがある。 a) サービスレベルの要求事項を含む,利用時のサービス b) 新規サービス又はサービス変更の設計に関する品質基準 c) サービスの事業上の重要性の優先度 d) 可用性の要求事項 e) 規制上の要求事項 f) 情報セキュリティの要求事項

4.1.1.8 サービスの要求事項に同意し,それを満たす上でのトップマネジメントの役割  トップマネジメントは,次の事項に関して,サービスの要求事項を定義することを確実にすることが望ましい。 a) 顧客が期待する,望まれる結果。例えば,改善された有効性・効率性・満足度 b) サービスが取り除く制約 c) サービスの利用者のニーズを含む,“目的にかな(適)った”と言われることが多い,顧客の視点から見たサービスの機能性 d) サービスが支援することが望ましい,事業活動及び需要のパターン e) サービス及び製品が提供されるか,又は合意した仕様を満たすという,保証と言われることが多い,確証

 保証の典型的な特徴は,それがサービスの継続,可用性,容量・能力及びセキュリティに関して定義されることである。例えば,保証は,重大な中断又は災害によってサービスレベルが低下したときでも,サービスが引き続き目的にかな(適)っていることを確実にする。保証は,サービスのセキュリティも確実にすることが望ましい。  サービスの利用者のニーズは,顧客のニーズの枠内で定義することが望ましい。これは,利用者が作業活動を実施する一環として,サービスを利用することによって得られる効用を記述するものであることが望ましい。例を,次に示す。  例 1 制約の除去。希望するサービス変更によって,利用者は固定された場所からだけでなく,遠隔地からサービスにアクセスすることが可能となる。  例 2 機能性。業務トランザクションの処理時間の,希望どおりの改善。  例 3 パフォーマンス。利用者は 1 分間に 1 件,1 時間に 50 件の調達トランザクションを処理しなければならないことがある。

4.1.1.9 サービス提供者のニーズ  サービス提供者の立場からは,サービスの要求事項は,次の事項を含むことが望ましい。 a) サービス提供者の組織を所有する組織の事業ニーズ及び幅広い利害関係者への対応を確実にするための要求事項。例えば,方針,標準,法令・規制要求事項及び契約上の義務を満たすという要求事項。 b) サービスマネジメントのプロセス及び活動全体を指示し,監視し,管理するための SMS の適用範囲。これは,サービスの設計,移行,提供及び改善に必要な資産,能力及び資源に関する要求事項を含む。例えば,SMS の支援に必要な組織単位,人,プロセス,情報及び技術。 c) 既に判明している SMS の制限事項。例えば,人,技術,情報及び財務に関する資源の制約。 d) 定義された事業目的に対して提供される,サービスの測定,監査,報告及び改善に関する要求事項。 e) SMS の有効性の測定,監査,報告及び改善に関する要求事項。

4.1.1.10 矛盾する要求事項  サービス提供者が要求事項に矛盾が生じることを確認した場合には,処置を実施することが望ましい。  矛盾する要求事項の例には,次の事項がある。 a) 顧客要求事項と顧客の事業ニーズとが矛盾する場合,その矛盾は顧客が解消することが望ましい。例えば,事業者の戦略的方向性と矛盾する顧客要求事項。別の方法として,サービス提供者が相違点を分析し,サービスの要求事項の改訂を提案することができる。 b) 顧客要求事項とサービス提供者自身の事業ニーズとの矛盾は,顧客要求事項が優先度,費用又は利用可能な資金の点で非現実的であるときに発生することがある。矛盾の性質,及びなぜ要求事項が非現実的であるかについて,明確に顧客に伝えることが望ましい。 c) 法令・規制要求事項又は契約上の義務と矛盾するサービスの要求事項は,解決することが望ましい。例えば,ソフトウェアの配付は,ソフトウェアの新しい版へのアクセスに関する顧客要求事項と両立しないライセンス契約によって,制限されることがある。

 サービス提供者は,リスクを最小限にする方法を特定するために,矛盾によって生じるいかなるリスクもアセスメントを行い,定量化することを確実にすることが望ましい。アセスメントには,顧客満足度と,顧客要求事項及び目的を満たす能力とに対するリスクを含めることが望ましい。  矛盾を解消できるように,矛盾及びその潜在的影響は文書化し,顧客とともに討議することが望ましい。サービスの設計に合意した後に矛盾が特定された場合には,是正処置として,又は改善の機会として,その矛盾を解消することが望ましい。

4.1.1.11 サービスに対するリスク  トップマネジメントは,SMS 及びサービスに対するリスクの特定,文書化,及びアセスメントを確実にすることが望ましい。サービスに対するリスクは,法令・規制要求事項又は契約上の義務の不履行を含むことがある。例えば,ソフトウェアライセンスの要求事項の不履行又は財務上の誠実さに関する証拠の不提出がある。  さらに,トップマネジメントは,次の事項を確実にすることを含めて,特定された全てのリスクの管理を確実にすることが望ましい。 a) 特定されたリスクを管理するために選択肢を策定し,文書化する。 b) 好ましい選択肢について顧客と合意する。 c) 必要な場合,合意したリスク軽減のための選択肢を実施する。  注記 サービス提供者には,リスクマネジメントに関する JIS Q 31000 の要求事項及び助言が役立つ。

4.1.2 サービスマネジメントの方針 4.1.2.1 サービスマネジメントの方針の指針  サービスマネジメントの方針は,サービス提供者の状況に固有であり,顧客重視のものであることが望ましい。方針は,汎用的で広く適用可能な記述ではないほうがよい。むしろ,サービス提供者の状況及び目的を反映することが望ましい。  方針は,合意した SMS の適用範囲に基づくものであることが望ましく,そのため,サービス提供者のサービスマネジメントの目的及びサービスマネジメントの計画を支援するものであることが望ましい。  方針は,サービスの要求事項を満たすためのトップマネジメントの指示及びコミットメントを表すものであることが望ましい。また,方針は,JIS Q 20000-1 の箇条 5(新規サービス又はサービス変更の設計及び移行)の要求事項の達成を確実にすることが望ましい。  方針は,サービス提供者のマネージャ及び要員に,以下の例のように,明確なトップマネジメントの指示を伝えることが望ましい。  例 1 サービスは,顧客の事業目的に整合している。  例 2 プロセス又は手順の変更は,変更管理プロセスを通じてだけ行われる。  例 3 サービスマネジメントのプロセスの役割及び責任は,一貫した方法で定義され,文書化され,また,要員のパフォーマンスは,これらの責任の達成を基準にして測定される。

 サービスマネジメントの方針は,サービス提供者のサービスマネジメントの目的が達成されているかどうかのアセスメントに使えるように構成することが望ましい。例えば,サービスマネジメントの方針と,サービス提供者のサービスマネジメントの目的を達成するために何が行われているかとの関連を実証できることが望ましい。サービスマネジメントの方針は,方針の順守の測定が可能となるように構成することが望ましい。  サービス提供者は,サービス提供者の目的とサービスマネジメントの方針との関連が,サービスマネジメントの方針について最初に合意したとき以降,効果的なままであることを実証できることが望ましい。  サービスマネジメントの方針は,例えば,改善の取組みが個々のプロセスオーナ又はトップマネジメントによって承認されるかどうかを決定できるようにするなど,明確に権限のレベルを定義することが望ましい。  サービスマネジメントの方針は,サービス提供者自身の組織内に周知され,理解されることが望ましい。サービスマネジメントの方針は,必要な場合,顧客及び供給者にも伝えてよい。方針の参照が,討議され,理解され,適切に利用されている場合,この要求事項を満たしていることの証拠として使うことができる。例えば,会議の議事録,要員の調査,供給者との契約,再請負契約,方針の変更の要求又は明確化の要求,標準的及び計画外の運用時のプロセス,手順及び行動に及ぼす方針の影響,顧客調査,供給者調査などである。  さらに,トップマネジメントは,サービスマネジメントの方針を,少なくとも年に 1 回,適切な間隔でレビューすることを確実にする責任をもつことが望ましい。これによって,欠陥を特定することが望ましく,また,事業ニーズ及び顧客要求事項との継続的な整合を確実にすることが望ましい。サービスマネジメントの方針のレビューのときに適用する品質基準は,次の事項を考慮することが望ましい。 a) サービスの要求事項に照らした方針の妥当性 b) レビューの頻度の適切性 c) 方針とサービスマネジメントの目的との整合 d) 方針とサービスマネジメントの計画との整合 e) 方針とサービスマネジメントのプロセスとの整合 f) レビューが文書化され,承認され,追跡され,適切で,かつ,実施可能かどうか g) SMS の確立,導入,運用,監視,レビュー,維持及び改善のための枠組みの適切性 h) SMS のこれまでのレビュー及び監査で特定された修正及び改善処置

4.1.2.2 方針の改善及びその他の変更  サービスマネジメントの方針のレビュー後に,欠陥が発見された場合には,トップマネジメントは,それを修正することを確実にすることが望ましい。欠陥は,方針,サービスマネジメントの目的,計画,プロセス又は手順のいずれかの変更として修正することが望ましい。  さらに,方針は,サービスマネジメントの目的又は SMS の適用範囲の変更を反映するように更新することが望ましい。

4.1.3 権限,責任及びコミュニケーション 4.1.3.1 権限及び責任  サービス提供者は,SMS の全ての側面に関する権限及び責任を定義することを確実にすることが望ましい。役割記述書は,合意し,個人に割り当て,全要員に周知させ,文書管理手順に従って最新に保つことが望ましい。サービス提供者は,自身の活動がサービスマネジメントの目的の達成に貢献しているという認識を全要員に定着させ,維持するように促すことを確実にすることが望ましい。

4.1.3.2 コミュニケーション手順  トップマネジメントは,コミュニケーション手順を設計し,移行し,実施し,利用することを確実にする説明責任をもつことが望ましい。トップマネジメントは,手順の実際の設計を委託してもよいが,実施に先立って手順を承認し,その利用を実行することが望ましい。トップマネジメントは,コミュニケーション手順に積極的に関与することが望ましい。  トップマネジメントは,要員の認識,意欲,並びに効果的なサービスマネジメント及び継続的改善への参加の価値を理解することが望ましい。コミュニケーション手順は,要員の意欲をかき立てるものであることが望ましい。例えば,改善活動に参加した要員の好結果を周知させると,大きな意欲啓発効果となることがある。  コミュニケーション手順は,少なくとも提供方法,タイミング及び/又は頻度,並びに対象を含めることが望ましい。手順には,段階的取扱いの仕組み,連絡先の詳細,配付リストの維持,コミュニケーション方法,ツール及び情報へのアクセス,スケジュール並びに責任も盛り込むことが望ましい。  コミュニケーション手順には,次の事項を含めることが望ましい。 a) 提供方法 b) タイミング及び頻度 c) 個別のコミュニケーションの対象 d) 段階的取扱いの仕組み e) コミュニケーションの対象の詳細な連絡先 f) 配付リストの維持 g) コミュニケーション方法 h) ツール及び情報へのアクセス i) スケジュール及び責任

 コミュニケーションは,その形態が様々であってもよく,文化又は組織,連絡をとる個人及びその人の組織での役割によって異なったものになる。  トップマネジメントのコミュニケーション方法としては,要員向けオリエンテーション資料,説明会及び研修会,組織内の要員向け刊行物,電子メール,ソーシャルメディア,要員フィードバックフォーラムなどが挙げられる。

4.1.4 管理責任者 4.1.4.1 責任の理解  管理責任者は,SMS の確立,利用,長期にわたる改善,及び変化する事業ニーズとの整合を確実にする権限をもつ,サービス提供者の管理チームの一員であることが望ましい。サービスマネジメントのプロセス相互のインタフェースが適切であり,プロセスが SMS の他の部分と統合されていることを確実にすることを,この権限に含めることが望ましい。  サービス提供者は,どの人が管理責任者であるか,及び管理責任者の責任及び権限レベルが次の人々によって理解されていることが明確であることを確実にすることが望ましい。 a) プロセス,そのプロセスと他のプロセスとのインタフェース,及び SMS 内での統合について文書化し,順守し,測定し,改善することを確実にする権限及び責任をもつプロセスオーナ b) 設計,移行,実施,改善及び廃棄を含めたライフサイクル全体で,サービスに関する権限及び責任をもつサービスオーナ c) その他のサービス提供者の要員 d) 組織内のグループ e) 統括供給者を含む供給者 f) 顧客  注記 サービスマネジメントのプロセス間のインタフェース及び SMS の他のコンポーネントとの統合の例については,附属書 A を参照。

4.1.4.2 責任  管理責任者は,次の事項を達成することを確実にする責任をもつことが望ましい。 a) JIS Q 20000-1 が規定する経営者の責任の全側面を,トップマネジメントが要求するものを含めて実行する。 b) サービスの要求事項を文書化する。 c) SMS 及び適用範囲の定義が,サービス提供者自身のニーズ,並びに顧客及びサービスの利用者のニーズを満たす。 d) SMS の適用範囲及び詳細が,サービスの要求事項を引き続き満たすことを確実にするために,適切な間隔で確認する。例えば,顧客のニーズが変化した場合には,SMS 又は SMS の適用範囲も変更する必要が生じることがある。 e) プロセスの初期の計画立案時に,プロセスの設計,運用及び改善に対する決定の基礎としてサービスマネジメントの方針及び目的を使用する。 f) プロセスの設計を,インプット及びアウトプット並びにプロセスの一部として実行する活動を特定することから始める。 g) 方針及び目的が,サービスマネジメントのプロセスの改善の優先度付けを行う基準の決め手になっている。 h) サービスマネジメントのプロセスには,他のプロセスとの適切かつ効果的なインタフェースがあり,SMS の他の部分と統合されている。 i) PDCA 方法論を実施し,SMS 及びサービスの継続的改善に利用する。 j) サービスマネジメントの目的を達成し,サービスの要求事項を満たす SMS の能力を測定するために,SMS の内部監査及びアセスメントを一定の間隔で実施する。

4.1.4.3 資産管理  トップマネジメントは,サービスの提供に用いる全資産が,関連する法令,規制及び財務上の要求事項並びに契約上の義務に従って管理されることを,JIS Q 20000-1 が要求していることを認識することが望ましい。資産は,効果的な手順によって管理することが望ましい。  管理されることが望ましい資産の例は,ソフトウェアライセンス,モバイル機器,インフラストラクチャのコンポーネント,人,契約,手順,その他の文書などがある。サービス提供者は,資産の場所,状態及び関連する詳細情報を正確に特定できるようにすることが望ましい。  トップマネジメントは,資産管理には,正確な構成管理データベース(以下,CMDB という。)又はそれと同等の記録の保管手段を定め,それを効果的に利用する必要があると認識することが望ましい。CMDB の情報は,CMDB の変更が変更管理プロセスによって承認されるなど,効果的なサービスマネジメントのプロセスによって最新に保つことが望ましい。  法令要求事項は,知的財産及び著作権法と同様に,プライバシー及びデータ保護法を含むことがある。これ以外の法令要求事項は,顧客情報資産の保護又は財務情報の保護に関するものである。  規制要求事項及び契約上の義務は,ノート PC 上における機密情報の暗号化に関するセキュリティ規格など,資産が事業上のライセンスの要求事項及び規格に適合することを確実にすることを含むことがある。  注記 ソフトウェア資産管理については,JIS X 0164-1 及び ISO/IEC 19770-2 がサービス提供者の役に立つ。

4.1.4.4 管理責任者による報告  トップマネジメントへの報告は,4.1.4.2 に規定した事項を含めることが望ましいが,これらだけに限らない。例えば,報告では,PDCA 方法論を用いて実現される,継続的な改善の機会を特定することが望ましい。これは,SMS 及びサービスのパフォーマンスに関する報告に基づくことが望ましい。  報告の頻度及び詳細さの程度は,活動のレベル,変更の分類,並びに管理責任者が特定した課題及びリスクの重大さに適したものであることが望ましい。欠陥を修正するための変更の選択肢は,処置の優先度付け及びその後のトップマネジメントによる意思決定を支援するために提供されることが望ましい。  トップマネジメントへの報告は,事業目的を支援しながら,SMS によってもたらされる価値をはっきりと明示することが望ましい。

4.2 他の関係者が運用するプロセスのガバナンス

4.2.1 他の関係者が運用するプロセスに関する手引  サービス提供者は,少数のプロセスについては,他の関係者が運用するプロセスのガバナンスを実証することで,JIS Q 20000-1 の要求事項を満たすことができることを認識することが望ましい。  サービス提供者は,他の関係者が運用する全てのサービスマネジメントのプロセス又は一部のプロセスを特定することができることが望ましい。サービス提供者は,箇条 5−箇条 9 に示す,どのプロセスを運用する他の関係者のパフォーマンスについても,全体(end-to-end)の可視性をもつことが望ましい。  サービス提供者は,SMS のプロセスを運用する全ての当事者の管理を実証できることが望ましく,このことは,全ての契約及び他の合意文書で裏付けられていることが望ましい。

4.2.2 他の関係者  他の関係者には,次が含まれる。 a) サービス提供者と同一の組織内にあるが,サービス提供者の直接的な管理下にない,組織単位である内部グループ(例えば,データセンタ又はセキュリティ専門チーム) b) 供給者として活動する顧客(例えば,インシデント及びサービス要求管理の活動の一部を実施する顧客) c) 供給者(例えば,リリース及び展開管理プロセスの一部として行われる試験の外部委託先)

 供給者は,再請負契約先供給者の管理責任をもつ統括供給者のこともある。

4.2.3 説明責任及び権限の実証  サービス提供者は,次の事項のような証拠を提示して,プロセスに関する説明責任及び権限を実証することが望ましい。 a) サービス提供者又は他の関係者によって運用される,サービスマネジメントのプロセスの有効性に関するサービス提供者の説明責任。例えば,意思決定者のマトリクス,サービス提供者自身の組織内の権限レベルの証明など。 b) サービス提供者がプロセスの順守を要求する権限をもっている。例えば,情報セキュリティ方針の策定,管理策の利用,違反の検出及び是正処置の開始。その他の例には,サービス提供者の要求によって実践方法を変更した証拠の提示がある。 c) サービス提供者による測定を含めたプロセスの記録の分析。例えば,インシデント記録を提出するのが,インシデント管理プロセスを運用する他の関係者であっても,インシデント記録の全部又はインシデント報告書を検討し,その内容に基づいて決定を下す。 d) 他の関係者が運用する箇条 5−箇条 9 のプロセスを含めた,SMS の全てのプロセスの定義の管理。これは,各プロセス間のインタフェースを含む。例えば,変更管理プロセスと構成管理プロセスとのインタフェース及び依存関係の文書化,合意及び運用がある。詳細は 4.2.4 参照。 e) JIS Q 20000-1 の箇条 4(サービスマネジメントシステムの一般要求事項)−箇条 9(統合的制御プロセス)に規定する,全てのプロセスに対する計画及び改善の優先度設定の管理。例えば,そのプロセスが他の関係者によって運用されている場合でも,容量・能力管理プロセスでの改善のアセスメント及び優先度付けを行う。

 サービス提供者は,サービス提供者が設計し文書化したプロセスの運用を他の関係者に要請することができる。別の方法として,サービス提供者は,他の関係者が設計し,文書化し,運用するプロセスを承認することができる。  サービス提供者は,過半数のプロセスの運用を他の関係者に頼っている場合には,適切なプロセスのガバナンスを実証することはほぼ不可能だと認識することが望ましい。  注記 他の関係者が運用するプロセスのガバナンスについては,ISO/IEC 20000-3:2012 に記載されている。

4.2.4 プロセスのパフォーマンス及び適合性  サービス提供者は,箇条 5−箇条 9 に規定するプロセスが望まれる成果を挙げ,サービスマネジメントの目的を達成するために貢献することを確実にすることが望ましい。  他の関係者が運用するプロセスのガバナンスには,次の事項を含めて,プロセスの定義を含めることが望ましい。 a) プロセスオーナの識別。例えば,サービス提供者の組織のどのグループ又はどのマネージャがプロセスの責任をもつのか。 b) 運用責任。例えば,どのグループ又はどのマネージャがプロセスの運用に責任をもつのか。 c) プロセスの目的,プロセスの成果,並びに満たされているサービスの要求事項及びサービスマネジメントの目的へのプロセスの貢献 d) プロセスのインプット及びアウトプット,並びにそれらを生成するのはどの当事者か。 e) サービスマネジメントのプロセスを含む,他のプロセスとのインタフェースの定義。例えば,プロセス間で受け渡されるデータ,又はある当事者から別の当事者への活動若しくは情報の受渡し f) SMS のプロセスと他のコンポーネントとの間のインタフェースの定義。例えば,プロセスと,サービスマネジメントの方針及び目的との間 g) 情報がプロセス間を行き来する頻度及び行き来するときの方法 h) 他の関係者が運用するプロセスのガバナンスのために,サービス提供者が要求する文書及び記録,並びに誰がそれらを作成するか。 i) 要求される全ての活動に関する明確な説明責任及び責任

 SMS コンポーネント間のインタフェースの定義には,サービスマネジメントの方針及び目的並びに変化する事業上のニーズを支援するために,サービスマネジメントのプロセスを確立し,継続的改善をする方法を含めることが望ましい。例えば,プロセスを含む SMS コンポーネントが,サービスマネジメントの方針に整合し,支援するものであることを,どのようにして測定するのか。

4.2.5 プロセスのパフォーマンス及び適合性の判定  サービス提供者は,次の事項によって全てのプロセスが効果的であることを確実にすることが望ましい。 a) サービス提供者及び他の関係者に利用可能とする文書及び記録の頻度及び様式を文書化し,他の関係者との間で合意する。 b) レビューサイクル及びプロセスのアセスメントの基準を定める。 c) JIS Q 20000-1 の要求事項に基づいたプロセスのアセスメントを行う。 d) プロセスのレビュー活動の範囲内で,他の関係者の義務を定義する。 e) プロセスのパフォーマンスの分析 f) 他の関係者が運用する全部又は一部のプロセスと,それ以外のプロセスとのインタフェース,並びに方針及び計画の分析 g) 他の関係者が運用するプロセス又はプロセスの一部と,サービスマネジメントの目的との整合の分析 h) プロセスを最適化するための改善又は修正のための活動の優先度付け及び計画立案

4.2.6 プロセスの改善に関する計画立案及び優先度付けの管理  サービス提供者は,他の関係者が運用するものを含めて,全てのプロセスの改善に与える優先度を管理していると実証できることが望ましい(例 1 及び例 2 参照)。  例 1 変更管理プロセスの改善案は,リリース及び展開管理プロセスの改善案よりも組織にもたらす恩恵が大きいと考えることができる。プロセスの改善の優先度付けは,事業目的及びサービスの要求事項に整合させることが望ましい。  例 2 他の関係者が運用するインシデント管理プロセスの改善は,サービス提供者の事業目的及びサービスの要求事項によって,並びにサービス提供者の組織によって指示されるものであることが望ましい。

4.3 文書の運用管理

4.3.1 文書の作成及び維持 4.3.1.1 証拠としての文書  サービス提供者は,SMS の監査のために証拠が利用できることを確実にすることが望ましい。証拠の多くは,文書の形で存在することが望ましい。文書は,その目的に適切な場合,紙,データベース又はワードプロセッサ内の電子ファイルなど,どのような種類,様式又は媒体でもよい。  次の文書は,SMS の監査のための証拠とみなすことができる。 a) サービスマネジメントの方針,目的及び計画 b) プロセス及び手順の文書 c) サービスカタログ d) 設計,要求事項の仕様,サービスレベル合意書(以下,SLA という。),受入基準及びサービスのレビューを含むサービス文書 e) 要求事項及び変更管理の仕様を含む契約文書 f) 監査の計画立案活動及び報告書 g) 変更の計画立案活動など,特定の変更を記述した文書又はそれに関係する文書

 サービス提供者は,方針など幾つかの文書は,個別のプロセスの要求事項を満たすために JIS Q 20000-1 によって要求されると認識することが望ましい。また,組織は,明確さを更に高めるために,又は SMS の効果的な運用若しくは改善,及びサービスの提供を確実にするために,方針を含めた追加文書の検討を望むことがある。  記録は特別な種類の文書であり,これも同様に証拠として利用できるようにすることが望ましい。

4.3.1.2 記録を含む文書の作成  サービス提供者は,記録を含む文書の作成に効果的な手順が必須であることを理解することが望ましい。これには,目的に整合した命名及び番号付けの方式,並びに文書の改訂履歴の利用が含まれる。テンプレート及び標準書式を使用することによって,内容の作成,アクセス,更新及び利用の手間を省くことができる。  SMS に定義される文書に関する役割及び責任に従って,文書の受入手順の証拠があることが望ましい。  さらに,サービス提供者は,例えば,モバイル機器又は電子メールサービスの提供を支援するサーバに保存してもよい情報が何かを定める情報セキュリティ方針のように,SLA,方針,計画などの文書が相互に依存していることがあることを理解することが望ましい。これらの依存関係を理解し,文書を変更するときには管理することが望ましい。  実際に何が行われたか,又は何が起きたのかを示す記録には,必ずしも受入手順は必要ない。例としてインシデント記録がある。インシデント記録は,インシデントが進行するに従い終了まで更新することが望ましい。インシデント記録を更新するたびに受入手順を運用することは,インシデントの解決に許容できない遅れを生じさせる。  注記 文書及び記録は,SMS に固有のものである必要はない。文書及び記録は,JIS Q 20000-1 の要求事項を満たしている場合には,JIS Q 9001,JIS Q 27001 などの規格の要求事項も満たしている可能性がある。

4.3.2 文書管理  文書管理は,必須であると認識することが望ましい。文書管理は,定期的なレビュー及び必要に応じた更新又は保管を含むことが望ましい。レビューは,少なくとも年に 1 回行うことが望ましい。文書は,劣悪な環境条件,ハードウェア障害などによる損傷から保護することが望ましい。  管理は,他の関係者との契約又は可用性の要求事項に影響する SLA の変更など,変化の影響の可視性をもたらすことができる。サービス提供者は,次の手段を用いて文書を管理することを確実にすることが望ましい。 a) 版(version)の命名及び番号付け b) 文書の記述,編集,レビュー,承認,更新,削除及び保管に関して割り当てられた責任 c) 変更の日付,作成者,承認及び改訂の性質を示す変更記録 d) 承認前の変更管理プロセスによる,特定された文書への変更のアセスメント e) 個別の文書と SMS の他のコンポーネントとの関係の識別 f) 文書のアクセス制御の仕組み及び配付 g) 文書の使用承認手順 h) 文書のレビュー及び必要に応じた更新,並びに再承認の手順 i) サービス提供者が SMS の計画及び運用に必要と判断した外部で作成された文書を識別し,その配付を管理することを確実にする手順 j) 文書を情報セキュリティ方針及び法令・規制要求事項に従って処分することを確実にするための手順 k) 古い文書を保管する手順

 文書管理を達成するためには,文書の版をどのように示すかに関する方針など,文書管理,知識管理,変更管理及び構成管理の技法を利用することができる。  サービス提供者は,文書管理手順の対象とする文書を特定することが望ましい。これには,規格,規制,顧客文書など,外部で作成された文書が含まれることがある。サービス提供者は,例えば,外部で作成された文書と内部文書,内容の違いによってセキュリティを変える必要がある文書など,項目の種類によって異なってくる管理の種類を区別することが望ましい。  管理することが望ましい文書は,4.3.1.1 に規定するものを全て含む。多くの文書は構成品目(以下,CIという。)に分類されており,したがって構成管理プロセスによっても管理される。電子的な手段によって文書管理を達成する場合は,適切な承認,アクセス,配付,媒体及び保管手順に特に注意することが望ましい。  注記 1 サービス提供者には,JIS Q 9001 の 4.2.3(文書管理)及び 4.2.4(記録の管理)が役立つ。  注記 2 詳細については,ISO/IEC TR 20000-4 の 5.11(情報項目管理プロセス)を参照。

4.3.3 記録の管理  SMS 関連の記録は,JIS Q 20000-1 の要求事項,法令・規制要求事項,及び契約上の義務と整合させることが望ましい。例えば,記録の保持,保管及び処分の実践である。保持することが望ましい記録には,文書レビューの記録,解決に至るレビューのコメントの追跡などが挙げられる。これらの要求事項及び義務は,SMS の設計に影響を及ぼすことが望ましい。  法令・規制要求事項又は契約上の義務と JIS Q 20000-1 の要求事項との間に矛盾がある場合には,解決することが望ましい。このことは,SMS の一部として作成され,利用される全ての記録に適用することが望ましい。これには,文書,ログ及びデータベースの記録,既知の誤りの記録,CI,インシデント記録,並びに変更要求の記録を含むが,これらだけに限らない。  要求事項への適合及び SMS の効果的な運用の証拠となるように定められている記録は,管理することが望ましい。組織は,記録の特定,保存,保護,検索,保持及び処分に必要となる管理策を定義する文書化された手順を確立することが望ましい。記録は,いつまでも読みやすく,容易に識別可能で,検索できることが望ましい。  注記 記録管理の詳細については,JIS X 0902-1 に規定されている。

4.4 資源の運用管理

4.4.1 資源の提供 4.4.1.1 SMS を導入するための資源  サービス提供者は,SMS 及び合意したサービスを確立,導入,維持及び改善するために,計画で合意した全ての資源を利用できるようにすることが望ましい。資源は,少なくとも次の事項を含む。 a) 人的資源。例えば,SMS の設計,導入及び運用に当たる人員,トップマネジメント,並びに SMS 及びサービスの管理に関与する要員 b) 技術的資源。例えば,サービスの要求事項を達成するためのインフラストラクチャ及び十分な容量・能力,SMS のプロセスを支援するためのツール,オフィスの施設及び設備,並びにサービス継続のための設備 c) 情報。例えば,顧客要求事項の詳細,顧客の事業ニーズ及び事業計画,サービス提供者の事業ニーズ,サービスマネジメントの方針,対策及びその他の報告書 d) プロジェクトの資金と SMS の運用継続の資金との両方を含めた財源

4.4.1.2 資源の承認  人,インフラストラクチャ,ツール,資金など,合意した資源の利用を承認する手順があることが望ましい。手順は,次の事項を含む。 a) サービスマネジメントの計画の実施に先立って合意され,予算が決められた資金 b) サービスマネジメントの計画を実施するためのプロジェクト,並びに長期的な継続的改善及び日々のプロセスの運用に必要な人の割当て c) 承認された人材の採用,及び/又は既存の人員の教育・訓練による技能の特定・育成 d) 新しい役割及び技術の特定,合意及び承認 e) オフィス及びデータセンタの施設,ローカルな LAN 及び WAN のアクセスポイントなどの通信機器,サーバ,ストレージ,配電及び冷却装置を含めた必要なインフラストラクチャ f) 監視又は測定,及び個別プロセスのサービスの報告又は支援のツールを含むことがある,サービスマネジメントのツール  例 資源提供手順は,個別の容量・能力のモデル化ツール又は CMDB から取り出した情報によって支援することができる。ツールは,JIS Q 20000-1 の要求事項ではないが,プロセスをより効果的で効率的なものにすることができる。ツールは,JIS Q 20000-1 の要求事項に適合しているという証拠が得られる点でも助けになる。

4.4.2 人的資源 4.4.2.1 一般  サービス提供者の資源提供に関するコミットメントは,各役割及び個人が SMS 及びサービスにどのように貢献できるかを定めることを含むことが望ましい。また,サービス提供者は,役割の種類ごとの権限レベル及び責任を定義し,それに合意することが望ましい。これは,各役割に要求される力量,教育,訓練,技能及び経験を含む。サービス提供者は,サービス提供者の組織内で,この情報を定義し,それに合意し,周知させることが望ましい。関連すると考えられる場合は,サービス提供者は,この情報を他の関係者にも周知させることが望ましい。  サービス提供者は,どの役割が,すなわち,どの個人が特定のレベル及び種類の権限及び責任をもつかに関して,不確かさから生じるリスクを理解することが望ましい。各役割の権限,説明責任及び責任のレベルが定義されたときには,この情報を SMS の統合されたコンポーネントにすることが望ましい。サービス提供者にとって,権限,説明責任及び責任を文書化するために,RACI(Responsible, Accountable, Consulted,Informed)などの責任分担マトリクスが役立つ。その情報が SMS のコンポーネントになった場合には,次に,これを SMS のレビューサイクルに含めることが望ましい。  資源は,SMS 及び SMS が提供するサービス全体の責任及び説明責任をもつトップマネジメントを含むことが望ましい。この資源の要求事項は,SMS 導入プロジェクト後も無期限に続く。  SMS の各サービスマネジメントのプロセスの権限及び責任は,次の事項を含むことが望ましい。 a) 次のことに責任をもつプロセスオーナ  1) プロセスの設計  2) プロセスの順守を確実にする  3) プロセスの測定及び改善 b) プロセスの運用及びプロセスのマネジメントのための資源の管理に責任をもつプロセスマネージャ c) プロセスの手順を実施する要員

 個々のサービスマネジメントのプロセスに固有の他の役割については,箇条 5−箇条 9 に規定する。  注記 特に小さな組織では,一人の人が複数のサービスマネジメントの役割を担うことは許容できる。

4.4.2.2 力量,技能,教育・訓練及び経験  ある役割に求められる力量は,その役割の個別の特徴及び要求事項の分析に基づくことが望ましい。これは,教育,訓練,技能及び経験を含むことが望ましいが,これらだけに限らない。  JIS Q 20000-1 の 4.4.2(人的資源)を満たすことに関連する各役割に求められる力量を特定することが望ましい。ある役割の権限及び責任のレベル及び種類も考慮することが望ましい。これには,トップマネジメントの役割を含む。  サービス提供者は,各役割に伴う作業負荷及び各役割が時間の経過とともにどのように変化するかについても検討することが望ましい。個人への役割及び責任の割当ては,役割及び責任を割り当てるときに,役割のこうした側面を考慮することが望ましい。  サービス提供者は,役割を適切に果たすための能力基準を満たした個人に割り当てることが望ましい。  ある役割に関する個人の適性判断は,実際の力量と,その役割に求められる力量との比較に基づくものであることが望ましい。合意した力量の要求事項と,その役割について検討されている個人又は既に役割を担っている個人の力量とに不一致がある場合,サービス提供者は,その不一致の解消を確実にすることが望ましい。  不一致の解消方法は幾つかある。例えば,個人に教育及び訓練を行って不一致を解消する。別の方法として,サービス提供者は,不足している技能又は経験を,既にその技能及び経験を保有している別の人とともに作業することで得るようにしてもよい。この是正処置を実施した後,サービス提供者は,実施した処置が不一致を解消したかを確認するために,個人の力量のアセスメントを再度行うことが望ましい。  サービス提供者は,重要業績評価指標及び/又は要員の重点達成分野を,サービスマネジメントの目的の達成に整合させることが望ましい。そうすることによって,要員は自らの義務を認識するだけではなく,どのようにすれば望まれるサービスの成果に貢献できるかをよりよく理解するようになる。  サービス提供者は,教育,訓練,技能及び経験を含む力量の記録をとり,最新に保つことが望ましい。サービス提供者は,要員が,どのようにすればサービスマネジメントの目的の達成に貢献するかを認識することを確実にすることが望ましい。  要員の記録を最新に保つことを確実にする文書化された手順があることが望ましい。

4.5 SMS の確立及び改善

4.5.1 適用範囲の定義  サービス提供者は,計画段階の初期に,JIS Q 20000-1 が各自の状況に適用可能かどうかを見定めることが望ましい。同様に,サービス提供者は,計画段階の初期に SMS の適用範囲を定義することが望ましい。サービス提供者は,このいずれかの活動を怠ることが,JIS Q 20000-1 の要求事項を満たさない,失敗した SMS 又は非効率的な SMS につながるおそれがあることを認識することが望ましい。  SMS を効果的なものとするために,サービス提供者は,PDCA 方法論を用いて SMS 及びサービスを継続的に改善することが望ましい。SMS の適用範囲は,SMS を改善する前に理解しておくことが望ましい。  SMS の適用範囲を定義するとき,次のパラメタを検討することが望ましい。 a) サービスを提供する組織の単位。例えば,一部門か,複数部門か,全部門か。 b) 提供するサービス。例えば,一つのサービス,複数のサービス又は全てのサービス,金融サービス,小売サービス,電子メールサービス c) サービス提供者のサービスの提供元となる地理的所在地。例えば,一つのオフィス,複数のオフィス,地域,国内又は世界 d) 顧客及びその所在地。例えば,一つの顧客,多数の顧客,外部又は内部の顧客 e) サービスを提供するために用いる技術

 適用範囲の記述には,サービスの提供に貢献している他の関係者の名称を含めないほうがよい。  JIS Q 20000-1 の要求事項を満たす方法を計画するとき,サービス提供者は ISO/IEC 20000-3 の手引を考慮することが望ましい。これは,SMS の適用範囲の定義,及び JIS Q 20000-1 がサービス提供者の状況に適用可能かどうかの確認に関する助言を示すものである。

4.5.2 SMS の計画(Plan) 4.5.2.1 計画の重要な側面  SMS の計画は,サービスマネジメント及びサービスの提供の全側面を取り上げ,次の側面を含むことが望ましいが,これらだけに限らない。 a) サービスマネジメントの目的。必要な変更及び改善を実施する場合のサービス提供者の優先度付けされた目的は,曖昧でないことが望ましい。 b) サービスマネジメントの計画。可能な場合には,計画は段階に細分化し,段階ごとにその効用を特定することが望ましい。 c) サービス提供者のサービスマネジメントの方針。例えば,変更管理方針,情報セキュリティ方針,サービス継続方針など,全ての個別の計画に関係する方針。SMS の計画立案の初期に方針を定義した場合,SMS の適用範囲の検証が可能となり,重要な検討事項の特定が可能となる。 d) サービスの要求事項。方針,規格又は事業上の重要業績評価指標は,サービスの要求事項と両立することが望ましく,顧客要求事項及び事業ニーズを満たすことが望ましい。例えば,サービスの要求事項は,事業全体をリスクにさらすような,情報セキュリティ方針に適合しないものにならないほうがよい。 e) SMS に影響を及ぼし得る既知の制限。例えば,SMS の導入及び管理の方法に関して,サービス提供者の要員の技能が不十分である場合。計画では,教育・訓練及び認識の提供,適切な技能及び経験をもつ新規要員の雇用,要員を指導するための他の関係者の専門知識の活用など,適切な処置を特定することが望ましい。

4.5.2.2 計画立案と合意との整合  サービスマネジメントの計画は,サービスの要求事項の合意書及び文書を含むことが望ましい。サービス目標は,計画,及びサービス提供者と関連するグループとの合意書の,両方に記載することが望ましい。合意書では,次の側面を考慮することが望ましい。 a) 顧客,例えば,SLA,新規サービス又はサービス変更の要求事項。これは,顧客との合意文書が法的な拘束力をもつ契約でない場合でも検討することが望ましい。 b) 内部グループ。例えば,設備グループ,システム開発グループ,人的資源グループ又は財務グループとの運用レベル合意書。サービス提供者と内部グループは同一法人の一部であるため,これは法的に拘束力のある契約とはならない。ただし,内部グループは,サービス提供者の直接的なライン管理の一部になっていないことがある。内部グループは,サービス全体の重要な部分を占めることがあるので,SMS の適用範囲を定義する重要な側面となり得る。 c) 供給者及び統括供給者。例えば,サービス又は資源の再請負契約先。 d) その他の規格,規制及び法令要求事項。例えば,医療,自動車,通信など業界固有の,又は国固有のソフトウェアライセンスに関する法への適合。

4.5.2.3 経営者の役割,権限及び責任  SMS の適用範囲内の経営者の役割,権限及び責任は,次の事項を含めて,サービスマネジメントの計画,プロセス文書及び関連合意書に記載することが望ましい。 a) 経営者が個別に又は全体で,説明責任及び責任をもつ全ての役割 b) この役割の権限に関する制限事項を含めた管理責任者,及びこの人が代表となっているトップマネジメントとの関係 c) サービス又はプロセスのオーナ

 SMS の役割に関する権限及び責任は,同じ役割の人が変更を提案し,承認も行うなど,利害の対立がないことを確実にするために確認することが望ましい。計画の中の権限,責任及びプロセスの役割の枠組みは,どの役割が SMS の全てのコンポーネントに関する説明責任及び責任をもつかの詳細を含むことが望ましい。

4.5.2.4 プロセスインタフェース  プロセス間のインタフェースに関する情報は,一つのプロセスから別のプロセスに受け渡される情報の種類,方法及び頻度を含むことが望ましい。サービス提供者は,これがプロセスの定義の重要な部分であること,並びにこれがプロセス及び SMS が効果的かつ効率的に機能することを確実にするということを認識することが望ましい。  JIS Q 20000-1 の箇条 5(新規サービス又はサービス変更の設計及び移行)は,この規格の箇条 6−箇条 9 のプロセス間のインタフェース,並びに新規サービス又はサービス変更の設計及び移行に関する要求事項を含んでいる。  新規サービス又はサービス変更に関する要求事項には,サービスの要求事項が定義され,サービスが設計され,移行されるときのプロジェクトの段階を含む。サービス提供者は,インタフェースの管理には効果的なプロジェクト管理が重要であると認識することが望ましい。SMS とプロジェクトとの間のインタフェースは,定義し,合意し,計画に記録することが望ましい。  プロセス,方針,目的及び計画を含む SMS の統合されたコンポーネントは,SMS 及びサービスの効率性及び有効性を特定し,管理し,改善することができるように測定することが望ましい。  顧客とサービス提供者との間の統合及び相互運用性を促進するために,サービス提供者は標準化されたプロセス記述書を作成することができる。プロセス記述書では,SMS 内のサービスマネジメントのプロセスごとに,目的,成果,活動,方針,役割及び責任,情報項目並びにインタフェースを定義する。各プロセスは,活動にどう着手するかを更に定義する目的で,手順書及び作業指示書を要求することもできる。  サービス提供者は,SMS の全体的な管理及び調整が特に重要となるのは,何か別の理由で SMS を改善又は変更するときであると認識することが望ましい。SMS の一部を形成するプロセスの変更は,変更が SMS の他の部分に及ぼす影響が理解され,許容できると考えられるときにだけ行うことが望ましい。これは,他のプロセス又は組織のサービス提供能力への影響を含む。  例 インシデント及びサービス要求管理プロセスで使用するパラメタ又は目標への変更は,例えば,サービスレベルマネジメント(SLM),報告及び情報セキュリティマネジメント(ISM)のプロセスなど,他のプロセスに,意図しない悪影響を及ぼすことがある。  プロセス間及び SMS の全てのコンポーネント間の依存関係を理解することによって,リスクが低減され,SMS の効果的なマネジメントが可能になることがある。サービスマネジメントのプロセス間のインタフェース及び SMS 内での統合の例は,参考として附属書 A に記載する。

4.5.3 SMS の導入及び運用(Do)  サービス提供者は,サービスマネジメントの計画に沿って,及びサービスマネジメントの目的を達成する手段として,SMS を導入し,運用することが望ましい。  サービス提供者は,サービス提供者と顧客との双方の権限及び責任を文書化し,当事者双方に影響する活動について合意することを確実にすることの効用を認識することが望ましい。  サービス提供者は,計画立案及び初期の実施に適任の人が,SMS の運用にも適任とは限らないと認識することが望ましい。計画,導入及び運用には,それぞれ異なる技能が要求される。

4.5.4 SMS の監視及びレビュー(Check) 4.5.4.1 一般  サービス提供者は,サービスマネジメントの目的を監視,測定,及びレビューし,目的を達成することを確実にするための必要な活動を計画することが望ましい。トップマネジメントは,レビューの結果を認識することが望ましい。サービスマネジメントの計画及び目的の変更が必要と考えられる場合には,これらの変更は,変更管理プロセスに従って承認することが望ましい。  PDCA 方法論に従って,サービス提供者は,プロセス及び提供されるサービスに関する情報を特定,収集,及び分析し,報告することが望ましい。これらの活動は,SMS 及びサービスの効果的な管理を支援することが望ましく,提供されるサービスの質及び価値を客観的に実証することを可能にすることが望ましい。  注記 測定に関する詳細については JIS X 0141 を,プロセスアセスメント及びパフォーマンス評価については JIS X 0145 規格群を,製品評価については JIS X 0133 規格群を,そしてソフトウェア製品測定の例については ISO/IEC TR 9126-2 及び ISO/IEC TR 9126-3 を参照。

4.5.4.2 内部監査  サービス提供者は,監査の権限及び責任を記載した手順書に従って,内部監査を実施することを確実にすることが望ましい。内部監査の実施責任者は,適切な知識を保有し,監査を受ける部署から独立した人であることが望ましく,例えば,自分自身の作業を監査しないほうがよい。必要な役割は文書化することが望ましい。役割としては,プロジェクトマネージャ,スポンサ,運営委員会,他の利害関係者,独立監査員などが挙げられる。  各サービスについて,いつ,JIS Q 20000-1 のどの箇条に関して監査を行うかを特定した,合意した内部監査プログラムがあることが望ましい。サービス又は JIS Q 20000-1 の箇条を,なぜ各内部監査に含めたか又は除外したかを含めて,決定事項を計画した論拠があることが望ましい。考慮することが望ましい要因としては,プロセスに関わるリスクの度合い,運用の頻度及び過去の履歴が挙げられる。  内部監査を実施する間隔については,計画を立てることが望ましく,既知のリスク又はその他の問題があるときだけ実施するというようにはしないほうがよい。選定された間隔は,次の事項の変更の度合いを考慮することが望ましい。 a) SMS 及びサービス b) 顧客要求事項及び顧客の組織 c) サービス提供者の要員及び組織 d) サービスの提供に用いる技術 e) ツールを使用している場合,サービスマネジメントのツールの重大な変更

 経営者は,文書化した理由に基づいて予定を変更しない限り,監査を計画どおり実施することを確実にすることが望ましい。  SMS の内部監査には,SMS の適用範囲と,SMS が顧客と合意したサービスの提供において,その効果が継続していることのアセスメントとを含めることが望ましい。これには,サービスマネジメントの方針が依然として適正な経営者の指示を示しており,期待される期間内で目的が達成されていることの確認を含むことが望ましい。内部監査は,SMS のパフォーマンスを基準に,計画のレビュー及び報告を行うことが望ましい。  監査頻度に合致した時間軸を用いて,内部監査員は不適合の詳細を提示することが望ましい。次にサービス提供者は,処置を特定し,その優先度付けを行うために,内部監査の結果を用いることが望ましい。  これまでの監査結果を考慮することが望ましい。例えば,懸念事項が特定された場合,計画は,懸念事項の原因を次回の内部監査で再度監査することを確実にすることを含むことが望ましい。内部監査では,特定され,合意された是正処置又は予防処置が,合意した期間に実施されたことを確認することが望ましい。内部監査では,合意した処置で予想どおりの改善が得られたことも確認することが望ましい。  不適合は,根本原因を究明するために分析することが望ましい。監査に起因する処置は,特定された根本原因の予防処置を含むことが望ましい。処置が効果的にかつ時間どおりに完了することを確実にするために,処置のオーナ及び期間は明確で合意されたものであることが望ましい。特定された不適合のフォローアップ活動は,処置がとられたという検証を含むことが望ましい。とった処置の結果は,トップマネジメントに報告することが望ましい。

4.5.4.3 マネジメントレビュー  SMS は,それが継続的に変化する事業ニーズ及びサービスの要求事項を満たすことができていることを確認するために,あらかじめ定めた間隔でレビューすることが望ましい。レビューは,少なくとも年に 1回実施することが望ましいが,急激に変化する環境で活動するサービス提供者もおり,その場合は,SMS のレビューをより頻繁に行うことが望ましい。レビューは,SMS の定義された適用範囲を基準にした実際の適用範囲,顧客の現在のニーズ及び顧客の事業ニーズと比較した現行計画の適切性を含むことが望ましい。  具体的には,レビューは,次の事項を基準に実施することができる。 a) 方針,計画及び目的を基準にした SMS のパフォーマンス b) プロセスの重要業績評価指標(KPI)の測定 c) 内部及び外部監査の結果 d) 事業目的に整合した継続的改善活動のレビュー e) 変更の実施後のレビュー f) 業界のベストプラクティス g) 顧客満足度調査の結果 h) 望まれる事業成果  注記 プロセスアセスメントの要求事項及び手引については,JIS X 0145-2 及び JIS X 0145-3 を参照。

4.5.5 SMS の維持及び改善(Act) 4.5.5.1 一般  サービス改善のための戦略的な取組みは,SMS 及びサービスの継続的改善に関する方針を定めることによって行うことが望ましい。方針には,改善の機会の受入れ及び優先度付けについて合意した評価基準の定義を含むことが望ましい。  顧客に提供される全てのサービス,サービスマネジメントのプロセス,及び全体としての SMS は,継続的改善の対象とすることが望ましい。これをより容易に行うために,サービス提供者が,継続的改善活動をサービスマネジメントのプロセスの文書の中に組み込むと役立つことがある。また,SMS コンポーネント及び要員のパフォーマンスの目標の測定を継続的改善の達成の基準にすると,サービス提供者に有益であることがある。  アセスメント,監査又は他の手段で特定された不適合に対処し,特定された不適合と潜在的不適合との両方の原因を取り除くための処置をとることが望ましい。

4.5.5.2 改善の管理  継続的改善は,ISO/IEC 20000 規格群の中核概念の一つである。全ての改善活動の権限及び責任を特定するための手順書を使用することが望ましい。この手順は,改善の機会を効果的に特定し,評価し,優先度付けし,承認し,実施し,管理し,測定することを確実にすることが望ましい。  継続的改善を管理するためのインプットは,次の事項を含むことが望ましい。 a) トップマネジメントからの適切な指令 b) SMS と個々のサービスとの両方の監査,及びレビュー結果として特定された根本原因 c) 顧客,他の関係者及びサービス提供者の組織内からの助言 d) 問題の記録 e) 計画の試験。例えば,サービス継続試験 f) 価値/サービスの要求事項の提供。例えば,サービスの事業上の重要性に基づいた改善活動の優先度付け g)最適化された資源の活用又はリスク低減。例えば,効率性の向上又は自動化の改善の機会  注記 1 更なる手引の詳細は,ISO/IEC TR 20000-4 に記載されている。  注記 2 システム工学及びソフトウェア開発用のプロセスモデル及びアセスメント方法については,ISO/IEC 15504-5及び ISO/IEC TR 15504-6 に記載されている。

5 新規サービス又はサービス変更の設計及び移行プロセス

5.1 一般

5.1.1 要求事項の意図  新規サービス又はサービス変更の設計及び移行プロセスは,新規サービス又はサービス変更の提供を管理するための計画を策定し,導入することが望ましい。このプロセスは,リスクが大きいか,又はサービス若しくは顧客に重大な影響を及ぼす可能性のある,新規サービス又はサービス変更に適用することが望ましい。

5.1.2 概念  このプロセスは,新規サービス又はサービス変更の設計及び移行を管理するための仕組みを規定することが望ましい。このプロセスは,変更管理プロセスと緊密に連携する。このプロセスで開発又は変更される CI は,変更管理プロセスを経由した構成管理プロセスを通じて制御することが望ましい。新規サービス又はサービス変更は,リリース及び展開管理プロセスを通じて展開することが望ましい。  新規サービス又はサービス変更の要求事項は,事業ニーズを満たすために,又は顧客へのサービスの提供方法を改善するために,サービスの顧客又は利害関係者によって特定されることが望ましい。サービス提供者は,このプロセスの用途を決定する基準を含む変更管理方針に基づいて,このプロセスをいつ使用するかを決めることが望ましい。サービス提供者によって,どの変更に箇条 5 が当てはまるかを決める方針も,使用する基準も異なる可能性がある。サービスの廃止,サービスの移行,及び重大な影響を及ぼす可能性のある新規サービス又はサービス変更は,新規サービス又はサービス変更の設計及び移行プロセスによって管理することが望ましい。サービス提供者は,新規サービス又はサービス変更が提案されるたびに,それに付随するリスクを理解することが望ましい。リスクについては,サービス提供者と顧客との両者の状況を,顧客の事業活動を含めて考慮することが望ましい。新規サービス又はサービス変更のリスクを最小限にする処置をとることが望ましい。

5.1.3 要求事項の説明  新規サービス又はサービス変更の設計及び移行プロセスは,より高いレベルのリスク及び影響を管理するための,更に高いレベルの可視性及び統合的制御が必要となる変更を対象にしている。三つの統合的制御プロセス,すなわち,構成管理,変更管理,並びにリリース及び展開管理のプロセスは,SMS 及びサービスに対する全ての変更に関する管理の中核にある。ただし,SMS 及び SMS の適用範囲外のタスク又は成果物とのインタフェースをもつ複雑なプロジェクトは,新規サービス又はサービス変更の設計及び移行プロセスがもたらす更に別の層の統合的制御が必要となることが多い。  サービス提供者ごとに,新規サービス又はサービス変更の設計及び移行プロセスによって,管理する変更の種類のどれが適切かを決めるために使用する基準は異なることが多い。例えば,基準は,特定の数より多くの利用者又は場所に影響を及ぼすサービスの変更を含むことがある。データ保護法に従って,サービス提供者が処罰されるリスクを引き起こす変更を含む例もある。  新規サービス又はサービス変更の設計及び移行プロセスでは,箇条 9 の統合的制御プロセスに関連するインタフェースを定義し,管理することが望ましい。新規サービス又はサービス変更の設計及び移行プロセスは,最適なリスク管理及び全てのサービスの要求事項を満たす解決策の提供を確実にするために,箇条 9 の統合的制御プロセスと連携することが望ましい。新規サービス又はサービス変更によって影響を受ける CI は, 構成管理プロセスで管理することが望ましい。新規サービス又はサービス変更のアセスメント,承認,スケジューリング及びレビューは,変更管理プロセスで管理することが望ましい。全ての新規サービス又はサービス変更は,リリース及び展開管理プロセスを用いて,稼働環境に展開することが望ましい。

5.2 新規サービス又はサービス変更の計画

5.2.1 新規サービス又はサービス変更の必要性  新規サービス又はサービス変更の必要性は,顧客,サービス提供者,内部グループ又は供給者によって提起される可能性がある。新規サービス又はサービス変更の目的は,事業ニーズ及び顧客要求事項を満たすため,又はサービスの有効性を改善するためである場合がある。

5.2.2 サービス又は顧客への影響が重大である変更  このプロセスは,サービスへの影響が重大であり,したがって,顧客への影響も重大となる可能性がある変更に適用することが望ましい。このようなサービスへの変更は,変更に付随するリスクを低減するために,箇条 5 の適用によって規定される追加活動を必要とする。  サービス又は顧客への影響が十分に低い変更は,統合的制御プロセスだけで管理することができる。サービス提供者の取り扱う変更の大部分は,この後者の分類に属することが望ましい。

5.2.3 影響が重大である変更に関する方針  箇条 5 に属する変更は,変更管理プロセスの一部として開発される変更管理方針を用いて識別することが望ましい。この方針は,サービス又は顧客への影響が重大となる可能性のある,リスクの高い変更の識別基準を含むことが望ましい。この方針は,サービス提供者独自のニーズ及びそのサービスに対するリスクのアセスメントに基づくことが望ましい。この方針は,新規サービス又はサービス変更案が,様々な理由で,様々なところから提起されることがあることを考慮することが望ましい。  この方針は文書化し,新規サービス又はサービス変更プロセスに最も直接的に関与しているトップマネジメント及びプロセスオーナの合意を得ることが望ましい。  変更管理方針の基準は,既存のサービスの廃止と,他の関係者が提供することになるサービスの移管との両方を常に含むことが望ましい。それ以外の基準は,サービス提供者ごとに異なっていることが多い。  影響が重大となる可能性のある変更は,次の事項を含むことがある。 a) 特定の数より多くの利用者又は場所に影響を及ぼすサービスの変更 b) データ保護法に従ってサービス提供者が処罰されるリスクを引き起こす可能性がある変更 c) 新規サービス又は既存のサービスの新規顧客 d) 場所,ハードウェアプラットフォームなど,サービスの提供方法の大きな違い e) 新しいオペレーティングシステム若しくはソフトウェアアプリケーションの投入,又は既存のソフトウェアの重大なリリース

 サービス提供者は,新規サービス又はサービス変更の結果,SMS の適用範囲に対する変更を含めて,SMS に要求することのできる変更を考慮することが望ましい。例えば,顧客と合意したサービス目標に対するリスクの特定,供給者管理手順,又は既存の若しくは計画したサービスに影響を及ぼす他の関係者との合意文書に対する変更などである。

5.2.4 プロジェクトとしての変更管理  箇条 5 が適用される新規サービス又はサービス変更は,変更の規模,リスク及び適用範囲に従って,プロジェクトとして管理することが望ましい。サービス提供者は,新規サービス又はサービス変更の財務的,組織的及び技術的影響の可能性に加えて,SMS への潜在的影響を検討することが望ましい。  サービス提供者は,プロジェクトの可能な限り早い段階から,変更管理プロセスとプロジェクト管理の役割及び権限との強い連携を確実にすることが望ましい。  サービス提供者は,プロジェクトで次の事項を検討することを確実にすることが望ましい。 a) サービス提供者の運用手順など,既存の支援の取決めへの影響 b) 既存のサービスレベルへの影響,及びサービス提供者がその影響を管理する能力 c) サービスの変更又はサービスへの追加によって影響を受ける可能性のある,他の関係者との供給者支援の合意,契約及び合意文書 d) サービスへの追加又はサービスの変更によって影響を受ける可能性のある,報告などのアウトプットを含む,既存のサービスに対する顧客要求事項 e) 展開のツール及び方法

5.2.5 他の関係者による貢献  他の関係者は,新規サービス又はサービス変更のサービスコンポーネントを提供することができる。新規サービス又はサービス変更は,ソフトウェア,インフラストラクチャ,専門的技能又はその他のサービスコンポーネントの入手を伴うことがある。  他の関係者が新規サービス又はサービス変更に関与している場合,サービス提供者は徹底的なレビューを行うことが望ましい。レビューは,合意したサービスの要求事項を含め,他の関係者がコミットメントを果たす能力を評価することが望ましい。レビューは,既存のサービス及び支援環境へのリスクも評価することが望ましい。  サービスを稼働環境に受け入れるためには,支援要員の数,技術,試験,文書化など,要求事項を規定する必要が生じることがある。

5.2.6 リスクアセスメント  サービス提供者は,プロセスの早期に,及び計画から稼働環境への受入れに至る各段階で,リスク,課題及び軽減策のアセスメントを実施することの重要性を認識することが望ましい。  計画立案の段階で受入基準を開発するために,リスクアセスメントの結果を使用することが望ましい。

5.2.7 サービス受入基準  計画に含まれるサービス受入基準は,次の事項を含むことが望ましい。 a) サービス提供者が,プロジェクトから新規サービス又はサービス変更を受け入れられるようにするために満たすべき,サービス提供者の要求事項 b) 新規サービス又はサービス変更の支援に必要となる知識の移管,文書化,容量・能力,可用性,継続性,セキュリティなど,新規サービス又はサービス変更の引渡し用のチェックリスト c) コミュニケーションのスケジュール,意識向上訓練,文書化などの顧客要求事項

 サービス,SMS 又は顧客の事業活動に対するリスクが受容できず,軽減することもできない場合は,新規サービス又はサービス変更を却下することが望ましい。

5.2.8 サービスの廃止  サービスを廃止する場合,そのことを,サービス廃止計画で計画し,文書化することが望ましい。計画は,次の事項を含むことが望ましい。 a) 廃止が該当する条件 b) 廃止の目的及び成功のための要因 c) 他の関係者が運用するプロセスのガバナンス d) 顧客,供給者,内部グループなど,全ての利害関係者の役割及び責任 e) 制限事項,リスク及び課題 f) マイルストーン及び成果物 g) 活動の分類及び各活動の説明 h) サービスの廃止と,サービス提供者の責任の終了とに関する合意した完了基準 i) 利用者がサービスを利用できなくなる期日及びサービスの廃止期日 j) 他のサービスによる,廃止されるサービスと他のサービスとのインタフェースの取り扱われ方 k) 機密情報の除去を含めた情報セキュリティの取決めのレビュー

 サービス提供者は,未解決のインシデント,問題,利用者の要請事項,及び変更要求の詳細が顧客との間で合意に至っていることを確実にすることが望ましい。この顧客との合意は,結果的に生じる処置を含むことが望ましい。  全てのデータ,文書及びシステムコンポーネントの所有について,合意しておくことが望ましい。必要な場合には,データ又はその他のサービスコンポーネントへのアクセスに関する取決めに合意し,計画し,実施することが望ましい。保管,廃棄又は移管に関する取決めについても,合意しておくことが望ましい。  サービスの廃止の結果として要求される文書の変更についても特定し,その変更は,変更管理プロセスを通じて行うことが望ましい。  サービスマネジメントの目的,活動及びサービスの廃止の結果は,顧客との合意文書に文書化することが望ましい。この合意書は,サービスの終了期日並びに役割及び責任の変更を含むことが望ましい。合意書は,サービス提供者がどのように利用者データ,顧客情報,サービス文書,並びに影響を受けるインフラストラクチャ,アプリケーション及びライセンスを管理するかについても,記載することが望ましい。合意文書は,合意したサービスの廃止の受入基準と呼ぶことができる。  全て又は一部のサービスを他の関係者に移管する場合,その目的は,利用者へのサービスが無用な中断なく継続することであることが望ましい。サービス提供者は,移管する前に,サービスの継続性又はサービスの質へのリスクを特定するために,顧客及び他の関係者と連携することが望ましい。サービス提供者は必要となる対策についての詳細な作業リスト,及びその後に結果の評価文書を発行することが望ましい。

5.3 新規サービス又はサービス変更の設計及び開発

5.3.1 サービス提供者,顧客及び他の関係者が実施する活動  サービス提供者は,早期から新規サービス又はサービス変更を提供するプロジェクトに関与することが望ましい。早期に関与することで,要求された機能及び特徴が実運用に適切でないサービスにつながる設計の決定を回避することができる。サービス提供者が早期に関与することによって,顧客との間で合意された要求事項に,新規サービス又はサービス変更の質に関する,少なくとも次の事項を含む基準が含まれることを確実にすることが望ましい。 a) サービスレベル,対応,及びパフォーマンスのその他の側面 b) サービスの信頼性及び回復力(resilience)  注記 “resilience”は,一般に“回復力”又は“復元力”と訳され,ここではサービスが障害又は災害に際し中断する状況下で迅速かつ柔軟にサービスを復旧させる能力のことである。 c) セキュリティ管理策 d) 要求されるサービス継続の適切性 e) 変更又は新しい版のリリース及び展開の費用効率基準 f) 使いやすさ

5.3.2 リスクマネジメント  サービス提供者は,計画立案段階で完了した初期のリスクアセスメントの結果を設計段階で検討することが望ましい。設計は,そのアセスメントで特定されたリスクの影響を受けることが望ましい。サービス提供者は,新規サービス又はサービス変更が稼働環境に移るとき,特定されたリスクのうちのどれが受容可能であるかを設計段階で検討することが望ましい。ここでは,ある特定のリスクが次の事項に及ぼす,潜在的影響を考慮することが望ましい。 a) 設計中のサービス b) サービス提供者の他のサービスに対するリスクの潜在的影響 c) 新規及び既存のサービスに依存する顧客

 合意したサービスの質及び機能の要求事項に潜在的不適合が特定された場合,サービス提供者はリスクを軽減することが望ましい。例えば,設計を変更するか,利害関係者がリスクを理解し,受容することを確実にすることによる。  稼働環境へのサービスの受入れは,受入基準を満たさないサービスの潜在的影響の理解に基づくことが望ましい。これには,他のサービスへの影響の理解を含めることが望ましい。5.2.6 及び 5.3.2 に規定するリスクアセスメント及びリスクマネジメントの手引は,受入基準の開発に影響を及ぼすことが望ましい。また,次の例に示す事項を検討することが望ましい。  例 1 すぐに修正する。欠陥の修正を可能にするための運用への移行の遅れ。  例 2 後日修正する。欠陥の修正が,合意した間隔で行われるように通告付きで受け入れる。  例 3 修正しない。新規サービス又はサービス変更の欠陥に対応するように,他のサービスを変更して受け入れる。  例 4 修正できない。受け入れるが,欠陥は修正できないか又は修正の必要がないという合意がある。  注記 リスクマネジメントの詳細については,JIS Q 31000 を参照。

5.3.3 サービス設計活動 5.3.3.1 設計計画  新規サービス又はサービス変更の設計も,次の事項を考慮して計画することが望ましい。 a) 合意した事業ニーズ及び顧客要求事項を満たすことを重視する。これは,プロジェクトの適用範囲内の要求事項の一部として文書化することが望ましい。 b) 新規サービス又はサービス変更の設計は,計画が周知され,サービスの利害関係者によって承認されるようにし,CI への影響が理解され,受け入れられることを確実にするために,変更管理プロセスに関連付けることが望ましい。 c) 新規サービス又はサービス変更の CI を適切に計画し,管理することを確実にする。 d) 変更スケジュールにおいて,プロジェクト期間を考慮することを確実にする。 e) サービス設計の提供及び継続的管理の費用を検討する。例えば,サービス設計の結果,過剰な資源又は技術なしに効果的な支援が行えることが望ましい。 f) 新規サービス又はサービス変更の提供による組織,技術及び営業上の影響を考慮する。 g) サービス設計が既存の組織及び技術を最大限に活用し,既存の営業上の取決めの中断を最小限にすることを確実にする。 h) サービス提供者の組織が管理できるように,設計で,新規サービス又はサービス変更が合意したサービスレベルを満たすことができるようにする。 i) サービスレベルの管理,測定及び報告用にサービス提供者の組織内に設けられている既存のプロセスに照らして,新規サービス又はサービス変更の適切性のアセスメントを行う。

 新規サービス又はサービス変更に関するサービス提供者の計画は,要求される活動のいずれかに影響する可能性のある依存関係,時間及び資源の制約を含むことが望ましい。サービス提供者が外部当事者によって実施される活動に依存している場合,計画にこの依存関係を記載することが望ましい。依存して実施される活動には,試験及び妥当性確認を含む。計画は,期間を守れない事態についても備えることが望ましい。  サービス提供者は,全ての活動の実施に必要となる人的資源,技術資源,情報資源及び財源並びにサービスマネジメントの能力を特定し,提供することを確実にすることが望ましい。これらの資源及び能力がサービス提供者の組織にない場合は,提供するまでの準備時間を含めて,それらを用意するためにどのような対策を講じる必要があるかを理解することが望ましい。計画立案の適用範囲には,新規サービス又はサービス変更の提供に至るまでの初期設計,開発及び移行の活動を含めることが望ましい。

5.3.3.2 サービスの設計及び開発  サービスの設計は,開発の前に文書化し,合意することが望ましい。設計は,現行のサービスの要求事項,情報セキュリティの留意点,サービスの回復力(resilience)及びサービスの予想される提供期間における資源の容量・能力の拡大予測を考慮することが望ましい。  新規サービス又はサービス変更の設計及び開発は,プロジェクト管理の方法及び技法を採用することが望ましい。新規サービス又はサービス変更の要求事項・設計・試験の間にトレーサビリティがあることが望ましい。  サービスの設計は,開発の前に,影響を受ける全ての当事者又は利害関係者との間で合意しておくことが望ましい。このような当事者には,影響を受ける可能性のある既存のサービスの提供に責任をもつ当事者及び必要な資源の提供に責任をもつ当事者を含めることが望ましい。  プロジェクトの進行中に変更が合意された場合には,設計を更新し,承認することが望ましい。実運用の前に,仕様の各要求事項を基準にしてサービスの試験を行い,結果を記録することが望ましい。  該当する場合,設計及び開発は,次の事項を含むことが望ましい。 a) サービスを受け入れるための設計,導入,移行,運用及び維持の活動で,次の事項の特定又はその参照を含む。  1) 実施すべき開発活動  2) 各活動への必要なインプット  3) 各活動からの必要なアウトプット  4) 実施すべき管理及び支援活動  5) チームに必要な教育・訓練  6) 製品及びサービスの提供を管理する計画の立案 b) チーム構成,責任,供給者の利用,及び使用する資源を含めたプロジェクト資源の編成 c) プロジェクト内の小チーム,供給者,パートナ,利用者,顧客の代表及び品質保証の代表など,様々な個人又はグループ間の組織面及び技術面のインタフェース d) 設計及び開発に関連する,想定されるリスク,前提,依存関係及び課題の分析 e) 次の事項を特定するスケジュール  1) 変更の段階,実施すべき活動  2) 関連する資源及びタイミング  3) 関連する依存関係  4) マイルストーン  5) 検証及び妥当性確認活動 f) 規格,規則,実践及び規約,方法,ライフサイクルのモデル,法令・規制要求事項,契約上の義務並びにその他の制約の特定 g) サービス開発のためのツール及び技法 h) サービス開発に必要なハードウェア,ソフトウェアなどの設備 i) 構成管理の活動 j) 不適合のソフトウェア及びハードウェアの製品を管理する方法 k) サービス開発を支援するためのソフトウェア及びハードウェアの管理方法 l) ソフトウェア製品の保管,バックアップ,復旧及びアクセス管理の手順,並びにウイルス防護の管理方法

 サービス提供者がサービス又はサービスコンポーネントの設計又は開発を管理できない場合,サービス提供者は,サービス又はサービスコンポーネントが期待に添うものになることを確実にするためにアセスメントを行うことが望ましい。例えば,市販品の機能特性及び非機能特性は,要求事項及び期待を基準にしてアセスメントを行うことが望ましい。製品に必要な通常又は個別の設定は,計画し,設計することが望ましい。  設計及び開発の計画立案に用いる文書は,一つの文書でも,別の文書の一部でもよく,複数の文書で構成してもよい。  計画は定期的に見直し,該当する場合,修正することが望ましい。

5.4 新規サービス又はサービス変更の移行

 新規サービス又はサービス変更の移行は,変更管理プロセス,リリース及び展開管理プロセス及び構成管理プロセスと連携することが望ましい。この取組みを採用して,変更の管理を新規サービス又はサービス変更の移行に適用することを確実にすることが望ましい。  サービスの移行は,新規サービス又はサービス変更の構築,試験及び受入れを含むことが望ましく,その後,リリース及び展開管理プロセスによって新規サービス又はサービス変更が稼働される。  移行については,顧客及び利害関係者を交えてレビューを行い,実運用の準備が整っていることを確定することが望ましい。レビューで生じた決定は,顧客による新規サービス又はサービス変更の実運用への受入れと合わせて記録することが望ましい。移行は,残りの活動が全て通常の実運用の一部となっているという合意が得られるまで継続することが望ましい。移行の完了後,サービス提供者は,計画した成果に照らして,新規サービス又はサービス変更が達成した成果を利害関係者に報告することが望ましい。  サービス受入基準については,サービス提供者及びその他の利害関係者がレビューすることが望ましい。サービス移行前に満たしていない未処理の受入基準がある場合,これらの基準の欠如がサービスに対する重要なリスクになるかどうかを判定することが望ましい。リスクが重要である場合,移行を遅らせることが望ましい。ただし,リスク軽減策がある場合,又はリスクが重要でない場合は,移行を進める決定を下してもよい。この場合は,サービス受入基準書に,未処理の処置及びそのオーナを記録することが望ましく,これらの処置を達成することを確実にするための対策を講じることが望ましい。  サービス提供者は,合意した受入基準に照らして,顧客及び利害関係者による新規サービス又はサービス変更の受入れを記録することが望ましい。

5.5 文書及び記録

 新規サービス又はサービス変更の設計及び移行プロセスによって作成し,保持することが望ましい文書及び記録には,次の事項を含めることが望ましい。 a) 新規サービス又はサービス変更に関するサービスの要求事項 b) 新規サービス又はサービス変更の要求ごとに行うリスクアセスメント c) 新規サービス又はサービス変更の設計,開発及び移行の計画 d) 廃止するサービスに関する計画 e) 新規サービス又はサービス変更に関与している他の関係者の評価報告書 f) 新規サービス又はサービス変更の設計仕様 g) サービス受入基準 h) 期待される成果に照らして実現された成果を記述した移行報告書

 変更管理プロセスの一部として開発され維持される,箇条 5 に属する新規サービス又はサービス変更に関する方針に,このプロセスがアクセスできることが重要である。

5.6 権限及び責任

 4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,新規サービス又はサービス変更の設計及び移行プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) プロジェクトの成果物の提供及び管理,並びにサービス受入基準の達成を確実にすることに責任をもつ,新規サービス又はサービス変更のマネージャで,通常はプロジェクトマネージャ b) 方針,目的,及びプロセスを含む複数の視点で,SMS に対して提案された新規サービス又はサービス変更の案の影響を評価できるグループ c) b)と同じこともあるが,全ての新規サービス又はサービス変更の要求事項の計画立案,及び新規サービス又はサービス変更の提供の受入れに関与することがあるグループ d) 全ての新規サービス又はサービス変更の要求事項の文書化及び合意,並びに新規サービス又はサービス変更の提供の受入れに責任をもつ,顧客及び事業者の代表

6 サービス提供プロセス

6.1 サービスレベル管理

6.1.1 要求事項の意図  SLM プロセスは,合意したサービスを提供し,サービス目標を満たすことを確実にすることが望ましい。全てのサービスについて,具体的で,測定可能な目標を立てることが望ましい。SLM プロセスは,合意したサービス及びサービス目標が顧客が容易に理解できるように,文書化することを確実にすることが望ましい。

6.1.2 概念  SLM プロセスは,提供されるサービスの定義,合意,文書化,監視,報告及びレビューを行うことが望ましい。サービスの提供が達成可能であり,管理され,顧客要求事項及び事業ニーズに整合したものであることを確実にするために,SLM プロセスは,事業関係管理(以下,BRM という。)プロセス及び供給者管理プロセスと緊密に連携する。  SLM プロセスは,サービス提供者にサービスを提供する供給者管理プロセスと BRM プロセスとの間の統合を可能にすることが望ましい。  SLM プロセスは,提供されるサービス及びサービス目標が事業ニーズ及び顧客要求事項に整合していることを確実にするために,供給者管理プロセス及び BRM プロセスと緊密に連携する。  供給者管理プロセスは,供給者と合意したサービス目標が SLM プロセスと,サービスのレビューが行われることを確実にするその他の要求された管理情報とに整合することとを確実にすることが望ましい。  さらに,SLM プロセスは,供給者管理プロセスに,供給者との合意に影響する変更の詳細を提供することが望ましい。例えば,供給者との契約を変更しなければならないことを意味する新規サービスの要求事項である。プロセスのガバナンスに責任をもつサービス提供者と,サービス提供者に代わってプロセスを運用する供給者とのインタフェースに影響するプロセス及び手順の変更も,その一例である。  SLM プロセスは,BRM プロセスに,顧客要求事項を満たすための合意したサービス目標,及び顧客サービスのレビューが行われることを確実にするための,他の必要な管理情報を提供することが望ましい。  SLM プロセスは,サービスレベルの要求事項文書によって,新規サービス又はサービス変更の要求事項に関して交渉し,合意し,文書化することが望ましい。次に,運用サービスに関する署名入りの SLA を作成して,サービスのライフサイクル全体でその要求事項を管理し,レビューすることが望ましい。  注記 SMS における SLM プロセス及び他のプロセスのインタフェースの例は,附属書 A に記載している。

6.1.3 要求事項の説明 6.1.3.1 サービスコミットメントの文書化  SLA は,サービス提供者の組織外の供給者,又は内部グループとの合意を通して支援しなければならないことがある。供給者との支援の合意は,基盤となる契約(underpinning contract)として知られるものである。  内部グループとの支援協定は,運用レベル合意書として知られるものである。これは,いずれの当事者も法的に拘束することができないが,拘束できるかのように取り扱うことができる。SLA を支援する全ての合意の複合的制約は,SLA を完成させる前に検討することが望ましい。  サービス提供者は,全ての運用サービスのパフォーマンスの達成度を,SLA,運用レベル合意書又は他のパフォーマンスの合意にある目標に照らして監視し,測定して,サービス報告書を作成することが望ましい。サービスのレビューを行うことが望ましく,サービス改善計画は定期的に,少なくとも年に 1 回作成することが望ましい。

6.1.3.2 サービスカタログ  サービス提供者は,顧客の考えるサービスに整合し,詳細な技術的理解のない人でも理解できる用語を使用して,全てのサービスをカタログに定義することが望ましい。サービスカタログは,全てのサービスの定義を集め,それを提示することが望ましい。定義される各サービスの適用範囲は,顧客の事業活動に関連することが望ましい。カタログは,6.1.3.4 に規定するように,SLA を簡略化するために,全てのサービス又は大半のサービスに共通の情報を収録することが望ましい。サービスカタログは,次のような多様な情報を含むことが望ましい。 a) サービスの名称及び説明 b) サービス目標。例えば,サービス要求を実現するまでの時間,新規利用者のためのサービスの設定時間,重大な障害があった後にサービスを再開するまでの時間 c) 連絡先 d) サービス提供時間,支援時間及び例外 e) セキュリティの取決め f) 現行のサービス g) サービスとサービスコンポーネントとの依存関係。例えば,利用者のノート PC を支援するサービスには,アプリケーションの支援,インターネットアクセスの支援,ハードウェアの支援などがあり,いずれのサービスも,異なる供給者又は内部グルーブに提供されることがある。  注記 ここに列挙してある例は,全てを網羅したものではない。

 サービス提供者は,情報を容易に維持できるようにサービスカタログを設計することを確実にすることが望ましい。情報の論理的で効率的な分類は,比較的頻繁な変更の対象となる情報の場合,特に重要である。これにより,6.1.3.4 に規定する変更管理プロセスの負荷が最小化される。  さらに,サービスカタログはサービスと支援サービスとの依存関係を示すことが望ましい。例えば,事業者のサービスが,電子メール,セキュリティ又はネットワークサービスのような,幾つかの請負サービスに依存している場合がある。これ以外に,供給者,又はサービス提供者の直接的な管理下にない内部グループによって提供される,サービスコンポーネントに依存しているサービスの例がある。  サービスカタログは,顧客の期待を設定するための主要な文書であり,顧客と支援要員との双方に広く利用可能であることが望ましい。

6.1.3.3 サービスレベル合意書  顧客とサービス提供者とは,提供するサービスの条件及び目標に合意し,これを SLA に記載することが望ましい。SLA は,サービス及びサービス目標について記述する文書である。SLA は,サービス提供者及び顧客の責任も規定する。一つの SLA で,複数のサービス又は複数の顧客に対処してもよい。SLA は,サービスの提供に必要な全てのコンポーネントを網羅することが望ましい。  顧客要求事項,事業ニーズ及びサービス提供者の能力は,SLA の内容,構成及び目標を決めるときに強い影響力をもつことが望ましい。提供されるサービスの測定基準となることが望ましい目標は,顧客の視点で定義することが望ましい。  サービス提供者は,SLA に記載する目標の数が多すぎると,混乱が生じ,効用をもたらすことなく負荷が過剰になると認識することが望ましい。顧客にとって最も重要なサービスの側面に焦点が当たるようにするために,SLA には目標の適切な部分だけを記載することが望ましい。  SLA に記載することが望ましい最低限の内容,又はサービスカタログで SLA から直接参照してよい最低限の内容は,次のとおりである。 a) サービスの簡潔な説明 b) 有効期間及び/又は SLA 変更の管理の仕組み c) 変更の承認の詳細 d) 報告,レビューの頻度及びスケジュールを含む,コミュニケーションの簡潔な説明 e) サービス提供時間(例えば,9 時−17 時),例外となる期日(例えば,週末,祝日,事業上重要な期間),及び時間外の対応 f) 通知方法及び期間当たりの頻度を含めた,予定され,合意されたサービスの中断 g) システムの正しい使い方,情報セキュリティ方針の順守など,顧客の責任 h) セキュリティなど,サービス提供者の法的責任及び義務 i) 影響及び優先度の指針 j) 段階的取扱い及び通知のプロセス k) 苦情対応手順 l) サービス目標 m) 合意した利用者数/作業負荷の量,システムスループットを支援するサービスの能力など,作業負荷の上限及び下限 n) 課金コードなど,高レベルの財務管理の詳細 o) インシデント及び災害を含むサービスの中断時にとる処置は,通常は SLA から参照される。 p) 用語集 q) 支援サービス及び関連サービス r) SLA に示す条件の例外

 頻繁に変更される情報又は多くの SLA に共通の情報は,電話番号簿又は電子メールアドレス帳,及び組織構成図などの文書を SLA の中で参照することによって提供してもよい。これによって,SLM プロセスの質に影響を及ぼすことなく,SLA の変更管理が容易になる。通常は,1 か所にまとめられている用語集は,サービスカタログを含め,全文書に共通であることが望ましい。これが可能となるのは,参照される文書も変更管理プロセスの管理下に置かれている場合だけである。SLA 及び SLA が記述する各サービスは,いずれも変更管理プロセスの対象とすることが望ましい。

6.1.3.4 サービスカタログ及びサービス提供の管理  サービス提供者は,それぞれの役割を効果的に果たすためにサービスカタログを必要としている人が,容易に利用できる手順を定めておくことが望ましい。また,この手順は,カタログを使用する要員の専門外の技能又は知識がなくても,カタログを最新の状態に保ち,更新しやすいことを確実にすることが望ましい。カタログに記載されている情報の正確さについては,定期的に確認することが望ましい。  事業の成長,事業の再編及び併合,変化する顧客要求事項などによる大きな事業の変化は,サービスレベルの調整,再定義,又は場合によっては,一時的な保留さえも要求することがある。  サービスカタログ又は SLA の変更は,全体的な影響が管理されていない状態で導入されないことを確実にするため,変更管理プロセスを通じて開始し,管理することが望ましい。  SLM プロセスは,こうした変更に対応するために十分に柔軟であることが望ましい。SLM プロセスは,サービス提供者がサービス提供の計画立案,実施及び継続的管理の全体で,顧客を重視し続けることを確実にすることが望ましい。サービス提供者は,顧客の事業推進要因及び要求事項を理解するために,BRMプロセス及び顧客と連携することが望ましい。  SLM プロセスは,次の事項を特定するために,サービスレベルに関与する要因を管理し,調整することが望ましい。 a) サービスの要求事項及び予想されるサービスの作業負荷の特性に関する合意 b) サービス目標に関する合意 c) 達成したサービスレベルの測定及び報告,作業負荷,並びに合意した目標を達成しない場合の説明(6.2を参照) d) 報告されたパフォーマンス及び顧客満足度を確認するための,顧客を交えたサービスのパフォーマンスのレビュー e) 是正処置又は予防処置の開始 f) サービス改善計画へのインプット g) サービスレベル及びサービスカタログの適切性及び事業上の要求事項との整合に関する,合意した計画活動に従った,少なくとも年に 1 回のレビュー

 このプロセスは,サービス提供者と顧客との双方に,サービス改善に向けた事前予防的な態度の育成を奨励することが望ましく,両者がサービスに対する共同責任をもつことを確実にすることが望ましい。  顧客満足度は SLM プロセスの重要な部分であるが,SLA 内のサービス目標は客観的測定であることが望ましいのに対して,顧客満足度は主観的な測定であると認識することが望ましい。SLM プロセスは,顧客満足度を管理し,同時にサービス目標を達成するために,事業関係及び供給者管理プロセスと緊密に連携することが望ましい。  サービスカタログ及び SLA については,合意した計画立案活動に従って,顧客を交えてレビューを行うことが望ましい。

6.1.3.5 他の関係者の管理  サービス提供者は,顧客が供給者及び顧客の両方として活動することがあると認識することが望ましい。例えば,顧客の組織の専門家グループは,サービスコンポーネントを提供することがあるが,サービス提供者の SMS の適用範囲にあるサービスを受領することもある。このような場合,サービス提供者は,供給者として活動する顧客を管理するために,SLM プロセスを使用することが望ましい。  同様に,SMS に含まれていない内部グループも,サービス提供者が管理することが望ましい。  注記 定義上,サービス提供者の組織外の供給者の管理は,7.2 の供給者管理プロセス下にある。

6.1.4 文書及び記録  顧客,サービス提供者及び利害関係者が作成し,使用する文書には次の事項を含めることが望ましい。 a) サービスカタログ b) 全ての SLA 及び関連する他の合意書 c) サービスカタログ及び SLA の管理を含む, SLM プロセスのプロセス及び手順 d) SLM プロセス,サービスカタログ及び SLA のレビューのインプット及びアウトプット e) サービスの報告の要求事項 f) サービスレビューの計画立案活動 g) 監視及び管理の報告書 h) サービスレビューの記録及び特定された改善の機会 i) サービス改善計画

6.1.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,SLM プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) プロセスの運用並びに資源及びコミュニケーションの管理は,サービスレベルマネージャの責任とすることが望ましい。このマネージャは,その手順を実施するサービス提供者の要員についても責任をもつ。 b) 顧客の代表及びサービスレベルマネージャはともに,サービスカタログを認可する責任をもち,各 SLA は顧客及びサービスレベルマネージャの責任である。これら二つの役割は,カタログにおけるサービスの定義及びサービス目標に合意するために十分な権限をもつことが望ましい。

6.2 サービスの報告 6.2.1 要求事項の意図  サービスの報告のプロセスは,十分な情報に基づいた意思決定及び効果的な伝達を促進するために,合意に基づく,適時の,信頼できる,正確な報告の作成を確実にすることが望ましい。

6.2.2 概念  サービスマネジメントのプロセスの成否は,サービス報告書に記載される情報の使用に左右される。監視及び報告は,現在及び履歴の分析を提供する,サービスの測定可能な全側面を包含することが望ましい。  サービス報告書は,報告書の読み手のニーズにかな(適)い,意思決定支援ツールとして利用するために十分に正確であることが望ましい。言語及び体裁は,分かりやすいように図表を用いるなどして,報告書の理解を助けるようにすることが望ましい。

6.2.3 要求事項の説明  サービスの報告に関する要求事項は,顧客と経営者との間で合意し,記録することが望ましい。報告書は,数種類のものを作成することが望ましい。これには,事後報告書及び事前報告書が含まれる。事後報告書は,何が起きたかを,それが起きた後に示す。事前報告書は,重要な事象について警告し,それによって予防処置をとることが可能となる。例えば,顧客に影響を及ぼすインシデントの発生を予防する目的で,事業上重要なサービスのための冗長性を強化する必要性を特定する報告書がある。それ以外の種類の報告書には,スケジュール及び予測報告書がある。これらは計画した活動を示す。  サービス提供者は,顧客及び経営者のために,少なくとも次の事項を含む報告書を作成することが望ましい。 a) サービス目標を基準にしたパフォーマンス。例えば,目標に照らした例外又は例外に近いもの,休止報告書及び成果 b) 作業量及び定期的な変更を含む,作業負荷の特性。例えば,インシデント,問題,変更及び活動,分類,場所,顧客,季節動向,優先度構成,救援要請回数,突出した作業負荷の期間別分布 c) 内部監査で特定された JIS Q 20000-1 への不適合 d) 是正処置及び予防処置のパフォーマンス報告,重大なインシデント,新規サービス又はサービス変更の設計・移行・リリースなどの重大な事象を受けて学んだ教訓,及びサービス継続の中断又は試験・改善活動 e) 将来のパフォーマンスの予測を助ける現在の傾向の見通し f) 苦情,顧客満足度測定の否定的なフィードバック及びその根本原因に対処するための是正処置及び予防処置が,顧客満足度を回復したかの追跡 g) 財務予想,作業負荷の計画,計画した変更スケジュールなど,予想及び計画

 複数の供給者,統括供給者及び再請負契約先供給者がある場合,報告書は供給者間の関係を反映することが望ましい。例えば,統括供給者は,顧客サービスの一環として管理している再請負契約先供給者によるサービスを含めて,提供するサービス全体に関して報告することが望ましい。  トップマネジメントによる決定を含めたサービスに関する決定,及び各決定の結果によってとる処置は,サービス報告書に含まれる所見に基づくことが望ましい。SMS は,そのような決定が,能力の増大に投資する基礎として使用する,以前の可用性,パフォーマンス報告書など,サービス報告書の情報によって妥当性が確認されていることを定期的に検証する手順を含むことが望ましい。サービスに関する全ての決定がサービス報告書に基づいて行えるわけではない。そうした例外の例としては,法令及び規制の変更,外部市場調査,変化する事業構造,技術の進展などが挙げられる。  サービス提供者は,トップマネジメント,プロセスオーナ,顧客,供給者及び統括供給者が関係しているときは,それらを含む全ての利害関係者に,各プロセスの報告書及び結果を周知させることを確実にすることが望ましい。

6.2.4 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実施する要員に加えて,サービスの報告プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) サービス報告書の,適時のかつ正確な作成及び関係者への配付に責任をもつ要員 b) 形式,内容,様式及び頻度を含めた各報告書の内容の定義に責任をもつ要員 c) 報告書を分析し,改善の特定,優先度付け及び処置を行うことが望ましい,他のサービスマネジメントのプロセスのプロセスオーナ,サービスオーナ,技術グループ及び他の利害関係者

6.3 サービス継続及び可用性管理

6.3.1 要求事項の意図  サービス継続及び可用性管理プロセスは,合意した目標の中で,合意したサービス継続及び可用性のコミットメントを果たすことを確実にすることが望ましい。

6.3.2 概念  サービス継続及び可用性管理プロセスは,サービス障害又は災害の予防及びそこからの復旧,並びにサービスの要求事項を満たすために十分なサービスの可用性の提供を確実にすることを含む。  サービス提供者は,サービス継続及び可用性管理プロセスを,関連する二つの独立したプロセスとして運用してもよい。別の方法として,サービス提供者は,それらを単一のプロセスとして運用してもよい。その決定は,サービス提供者の状況に基づくことが望ましく,SMS の一部として文書化することが望ましい。  サービス継続及び可用性管理プロセスは,プロセスの事後対応的側面及び事前予防的側面の両方,並びに合意したサービスの事業上の重要性の優先度付けを考慮することが望ましい。また,サービス継続及び可用性管理プロセスは,サービス提供者によるサービスの監視,管理,レビュー及び改善,並びに該当する場合は,顧客への報告を可能にするデータを取り込むことが望ましい。  サービス提供者は,合意した要求事項を満たすことができることを確実にするために,効果的な計画を立てることが望ましい。これらの要求事項は,平常の状況及び重大なサービスの停止後の状況の両方の下での可用性及び継続に関する要求事項を含む。計画は,サービスレベルの増減対策,予想される活動のピーク,並びにサービス継続及び可用性に関する将来の事業ニーズに対処するための新規又は変更された要求事項の理解を含むことが望ましい。

6.3.3 要求事項の説明 6.3.3.1 リスクアセスメント及びリスクマネジメント  サービス継続及び可用性管理プロセスの主要な特徴は,リスクアセスメント及びリスクマネジメントであることが望ましい。リスクアセスメントは,重大なサービスの停止の事業影響度分析を含むことが望ましい。  サービス継続及び可用性の要求事項は,合意したサービスの要求事項,事業影響度分析を実施した結果,顧客の事業上の優先度,方針及び計画,SLA 並びにアセスメントを行ったリスクに基づいて特定し,合意することが望ましい。サービス提供者は,重大なサービスの停止があった場合に,合意したサービスレベルが維持されることを確実にするために設計された効果的な計画と合わせて,十分なサービス能力を維持することが望ましい。  重大なサービスの停止後にサービスレベルの維持を確実にするためには,顧客,供給者など,他の関係者の管理下にあるサービスの実運用の要素を考慮することが望ましい。  平常のサービス及び重大なサービスの停止後に関するサービス継続及び可用性の要求事項には,少なくとも次の事項を含めることが望ましい。 a) アクセス権。平常の状態でのアクセス権を誰がもち,重大なサービスの停止後に,限定されたサービスに対する最優先のアクセス権を誰がもつかなど。 b) 応答時間。平常の状況及び重大なサービスの停止後の状況での応答時間など。サービスごとに許容できる応答時間はどれほどか,また合意した応答時間の達成を確実にするためにはどのような処置をとることが望ましいかについて,顧客を交えて定義し,合意することが望ましい。 c) 全体(end-to-end)の可用性。例えば,平常のサービス時に完全なサービスを提供するために必要となるコンポーネントに要求される可用性はどれほどか。重大なサービスの停止後,個別のサービスを平常のパフォーマンスに復帰させる優先度をどのように定めることが望ましいか。

6.3.3.2 サービス継続方針  サービス提供者にとって,サービス継続の義務を果たすための一般的な取組みを定義した方針を策定し,維持することが役立つ。サービス継続方針の適用範囲は,SMS の適用範囲と一致することが望ましい。  方針は,各サービスに要求される回復力(resilience)に対する実際の回復力(resilience)を決定し,サービスの事業上の重要性に整合した改善の機会について優先度付けを行う,一貫した方法を定義することが望ましい。  サービス継続方針は,サービス継続計画の適用範囲内でサービス提供者の継続計画の立案活動を促進することが望ましい。  方針は,合意したサービスの要求事項を満たすために必要な役割,活動及び責任に対処することが望ましい。  方針は,サービス継続及び可用性管理プロセスと,他のサービスマネジメントプロセスとのインタフェースを定義することが望ましい。サービス継続及び可用性管理プロセスと SMS の他のコンポーネントとのインタフェースに関する情報を参考として附属書 A に記載する。  方針は,合意したサービス時間及び事業上重要な期間を考慮することが望ましい。サービス提供者は,顧客グループ及びサービスごとに,次の事項を含む要求事項を個別に特定することが望ましい。 a) サービスの停止の許容可能な最長継続期間 b) サービスの品質低下の許容可能な最長期間 c) サービス復旧期間中の,許容可能なサービス品質低下レベル

 合意するサービス時間及び事業上重要な期間は,月末,年末,休日期間など,個別の事業サイクル及びそれに関連する重要性に関連して定義することが望ましい。  サービス提供者がサービス継続方針に基づいてプロセスを指導する場合,サービス継続方針については,合意した間隔で,少なくとも年に 1 回,レビューすることが望ましい。方針の変更は,サービス提供者と顧客との間で正式に合意することが望ましい。

6.3.3.3 サービス継続及び可用性の計画  サービス継続方針が設けられている場合,サービス提供者は,その方針をサービス継続戦略に整合させることができる。サービス継続戦略は,サービスの事業影響度分析に基づいたサービスの重要性にふさわしいことが望ましい。また,サービス提供者は,サービス継続戦略のインプットとして他のサービスマネジメントのプロセスから関連情報を収集することが望ましい。  戦略が定義された場合は,戦略と矛盾する継続性のリスクを特定し,それを管理する管理策を定義するため,又はリスクのレベルが受容できない場合は軽減処置を開始するために,リスク分析を実施することが望ましい。  サービス提供者は,合意した要求事項を満たすことを確実にするために設計された実行可能な計画と合わせて,十分なサービスの能力を維持することが望ましい。  サービス提供者は,サービス継続及び可用性の計画,復旧計画及び手順,並びにサービス継続試験の方針を策定することが望ましい。サービス継続計画及び試験の方針は,主要な事業機能及びプロセスに対する重大な中断の影響を低減するために設計することが望ましい。  サービス継続計画は,サービス継続方針に定義される要求事項,事業影響度分析及びリスクアセスメントに基づくことが望ましい。  継続的運用では,サービス継続の教育,認識及び教育・訓練,レビュー並びに監査のために,サービス継続の試験及び変更管理プロセスとの連携に関する要求事項を定義することが望ましい。サービス継続計画は,定期的に試験を行うことが望ましく,発動の責任は明確に割り当てることが望ましい。サービス継続試験は,少なくとも年に 1 回,又は大きな事業変更の都度,実施することが望ましい。全ての関係者に向けて,定期的な講習会を開くことが望ましい。サービス継続及び復旧計画の保管に関しては,定義され,管理された配付方針があることが望ましく,復旧に必要な,全ての重要なバックアップ媒体,文書及びその他の資源は遠隔地に保管することが望ましい。  サービス提供者は,次の事項を確実にすることが望ましい。 a) サービス継続計画で,サービスとサービスコンポーネントとの依存関係を考慮する。 b) サービス継続計画及びサービス継続を支援するために必要なその他の文書を記録し,維持する。 c) サービス継続計画を発動する責任を明確に指定し,計画で,方針の復旧要求事項別にとる処置の責任を割り当てる。 d) 重大なサービス障害又は災害の後に,サービス復旧に必要なデータ,文書及びソフトウェアのバックアップ,並びに機器及び要員が速やかに利用可能である。 e) サービス継続に関する文書,例えば,サービス継続計画及びスケジュール,連絡先リスト,CMDB などが,中断中でもアクセス可能である。 f) 要員が,計画の発動及び/又は計画の実施時の役割を理解する。 g) 該当する場合,供給者及び復旧サイトの提供者と待機に関する取決めを交わしておく。

 サービス継続計画及び契約書などの関連文書は,システム又はサービスの変更が承認される前,及び重要な新規顧客要求事項又は修正された顧客要求事項に関する合意の前に,影響についてアセスメントを行うことが望ましい。また,サービス継続計画及び関連文書については,少なくとも年に 1 回,レビュー及び試験を行うことが望ましい。  可用性計画を策定して,公表することが望ましい。可用性計画は,現在と将来との両方での,事業上の可用性の要求事項を満たすために必要な,事業ニーズ及び顧客要求事項,設計要求事項,技術仕様,及びプロジェクト計画活動を特定することが望ましい。可用性計画に文書化されている将来の可用性に関する予想は,計画外の非可用性の可能性を軽減するための予防処置案を含むことが望ましい。可用性計画は,定期的に,少なくとも年に 1 回,及び重大な変更後に,レビューし,改訂することが望ましい。  新規サービス又はサービス変更の可用性の計画及び設計は,事業に対するサービスの重要性に基づくことが望ましく,費用と受容可能な事業上のリスクとの釣合いがとれていることが望ましい。  全てのサービス及びサービスコンポーネントの非可用性は,記録し,調査することが望ましく,今後の発生の影響及び/又は発生の可能性を低減するために,適切な処置をとることが望ましい。

6.3.4 サービス継続及び可用性の監視及び試験 6.3.4.1 サービス継続試験  サービス継続試験は,大きな事業変更及びサービスの環境に対する変更があった後に実施することが望ましい。その頻度は,サービス提供者の状況に基づくことが望ましい。その頻度は,サービス継続計画が効果的で,変化するシステム,プロセス,要員及び事業ニーズが進化しても引き続き効果的であるという保証を得るために十分なものであることが望ましい。サービス継続試験の適用範囲は,中断後の正常なサービス運用への復帰を含むことが望ましい。  サービス継続試験には,顧客及びサービス提供者が,合意した一連の目的に基づいて共同で参加することが望ましい。該当する場合,他の関係者も含めることが望ましい。試験での失敗は,サービスを改善するための計画へのインプットとして文書化し,レビューすることが望ましい。  サービス継続試験後のレビューは,試験の目標及び目的の達成のアセスメントを行い,弱点部分又は改善の機会を特定するために実施することが望ましい。

6.3.4.2 可用性の監視及び試験  サービス継続及び可用性管理は,合意した可用性計画に従って,次の事項を行うことが望ましい。 a) サービスの可用性の監視及び記録 b) サービスの可用性に関する正確な履歴データの維持 c) 合意した可用性目標に対する不適合を特定するための,SLA に定義した要求事項との比較 d) 不適合の文書化及びレビュー e) 将来の可用性の要求事項の予測

 定期的な可用性試験のスケジュールは,可用性の解決策が達成可能で,適切な回復力(resilience)があることを確認するものであることが望ましい。重大な変更があった後には,可用性,信頼性及び回復力(resilience)の仕組みについて,レビュー及び試験を行うことが望ましい。  可能な場合には,潜在的な課題を予測し,予防処置をとることが望ましい。サービス継続及び可用性管理は,サービスの全てのコンポーネントについて,是正処置及び予防処置を特定し,記録し,実施して,定義された信頼性のレベルの達成及び改善に努めることが望ましい。

6.3.4.3 可用性に対するリスクの管理  リスクアセスメントは,不可欠な事業機能及び可用性の要求事項,並びに事業者と合意したリスクを特定することが望ましい。  リスクマネジメントは,可能な場合には特定されたリスクを軽減するための費用が妥当な対策を実施することによって,要求される可用性レベルの提供を可能にする解決策を提示することが望ましい。可用性の改善の効用よりはるかに多くの費用がかかる大規模な財政投資によって,要求事項を上回ることは賢明ではない。  新規サービス又はサービス変更の可用性の計画立案及び設計は,サービスの事業上の重要性,異なる作業時間の事業における重要性及び要求されるサービス時間に基づくことが望ましい。  サービス及びコンポーネントの可用性の定期的な監視,測定,分析,報告及びレビューは,プロセスの必須の側面であることが望ましい。サービスの可用性及び非可用性に関しては,関連する全てのデータを維持することが望ましい。達成した可用性の目標の報告には,実際の履歴データを使用することが望ましく,測定及び報告の焦点は合意した目標に整合することが望ましい。  全ての新規サービス又はサービス変更の変更要求のアセスメントでは,合意した可用性の目標に対するリスクの潜在的影響を考慮することが望ましい。可用性,信頼性及び回復力(resilience)の仕組みは,定期的にレビューし,重大な変更後に試験を行うことが望ましい。  可用性の設計基準は,要求される信頼性を提供する基本的な製品,技術及びコンポーネントを定義することが望ましい。

6.3.4.4 サービス継続計画発動後のレビュー  サービス継続計画発動後のレビューは,次の目的で行うことが望ましい。 a) 計画の発動を開始させるサービスの停止の性質及び原因の特定 b) 経営者の対応の適切性に関するアセスメント c) 目標復旧時間を達成する組織の有効性のアセスメント d) 計画の発動への要員の準備を通したサービス継続計画及び試験の適切性のアセスメント e) サービス継続計画及び試験の改善点の特定

6.3.5 文書及び記録  サービス継続及び可用性管理プロセスで作成し,保持することが望ましい文書及び記録には,次の事項を含めることが望ましいが,これらだけに限らない。 a) サービス継続及び可用性管理の方針 b) 事業影響度分析 c) リスクアセスメントの報告書 d) サービス継続及び可用性の計画 e) サービス継続及び可用性の顧客要求事項 f) サービスコンポーネントの可用性の制約及びデータ g) サービス継続及び可用性の設計 h) サービス継続及び可用性の試験計画 i) サービス継続及び可用性の試験報告書 j) サービス継続及び可用性管理のプロセス及び手順 k) 意識向上訓練の要求事項及び記録 l) 可用性管理のデータベース m) 可用性の監視報告書 n) 保守及び予定されたサービスの休止のスケジュール

 要員は,計画の発動及び/又は実施時における自身の役割を理解し,サービス継続の文書に直ちにアクセスできることが望ましい。  サービス継続計画,及び契約文書などの関連文書は,変更管理プロセス,SLM プロセス及び供給者管理プロセスの一部として,例えば,新規サービス又はサービス変更を受け入れる前,又はサービスの要求事項に合意する前に,潜在的影響についてアセスメントを受けることが望ましい。

6.3.6 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,サービス継続及び可用性管理プロセスで必要な権限及び責任には,次の事項を含めることが望ましい。 a) コンポーネント及びサービスの可用性に関するインフラストラクチャの監視,並びにデータの収集が正しく,要求されたとおりに行われることを確実にすることに責任をもつ,可用性の管理者 b) 災害復旧計画,サービスの試験及び復旧に責任をもつ技術復旧チーム c) サービス継続及び可用性管理に関する情報へのアクセスを要求し,試験に参加し,サービス継続の要求事項に合意する,顧客,サービス提供者の要員及び利害関係者 d) 可用性の改善のための適切な解決策を特定できるように,実際の,及び潜在的な可用性の課題を特定するための,可用性の報告書及びデータのレビュー及び分析に責任をもつ可用性アナリスト e) 監視能力及びきっかけの維持に責任をもつサービス継続の要員

6.4 サービスの予算業務及び会計業務

6.4.1 要求事項の意図  サービスの予算業務及び会計業務プロセスは,サービス提供者のサービスの総費用に関する理解及びサービスの総費用の管理能力を支援することが望ましい。この目的を達成するために,このプロセスは次の事項を確実にすることが望ましい。 a) 個々のサービス,サービス提供全体の費用,及びサービス提供者の予算を理解する。 b) 費用及び予算の両方について信頼できる予測が可能である。 c) 予算を策定し,サービスマネジメントのプロセスで利用する。 d) 費用又は予算の予想外の差異を特定し,管理する。 e) 予算期間全体でサービス提供資金が適切に供給されるように予算を順守する。 f) プロセス及び手順が引き続き有効であることを確実にするために,予測,予算及び費用を定期的にレビューする。

6.4.2 概念  予算業務及び会計業務プロセスは,サービス及びサービスコンポーネントの財務的側面を管理することが望ましい。サービスの予算業務及び会計業務プロセスは,サービスの実運用と,サービス変更及び改善のための資金提供との両方を支援する情報を提供することが望ましい。サービスの予算業務及び会計業務プロセスは,サービスの提供の費用を追跡でき,サービスが適正な価格であり,予算に従うことを確実にすることが望ましい。  多くの財務上の決定責任は,SMS の適用範囲外となることがある。提供する財務情報の詳細さのレベル,また,どのような形式で,どれほどの頻度で提供するかに関する要求事項は,サービス提供者以外の当事者が指定することがある。それ以外の規制上又は組織固有の要求事項も,定義された方針及び手順の幾つかに影響することがあるので,考慮することが望ましい。採用する全ての会計業務の実践は,サービス提供者の組織のより広い会計業務の実践に整合させることが望ましい。  サービスの予算業務及び会計業務プロセスは,財務管理の他の側面が組織の別の部署で実施されるかどうかに関係なく,サービス提供者が実施することが望ましい。サービスの予算業務及び会計業務プロセスは,サービス提供者の組織の財務プロセスに整合し,そのプロセスから情報を受領することが望ましい。

6.4.3 要求事項の説明 6.4.3.1 方針  サービス提供者は,サービスの財務管理のために文書化された方針及び手順をもつことが望ましい。方針は,サービスの予算業務及び会計業務プロセスによって達成する目的を定義することが望ましい。また,方針は,目的を達成することを確実にするために必要な詳細を定義することが望ましい。そのためには,方針は,予算で費用の割当てに使用する費用の種類,及びどのように間接費を配賦するかについての説明を含むことが望ましい。  各サービスの予算及び会計の分析のための基準を定義することが望ましい。基準が定義された場合,サービスの費用に関して定期的な監視ができ可視性が得られることを保証するために,予算項目及び会計項目にその基準を適用することができる。これは,サービスの費用の追跡に利用することができ,市場で同じサービスを得るときの費用との比較を可能にする。  サービスの予算業務及び会計業務プロセスに提供される資源は,方針に定義される財務上の詳細のために,顧客,サービス提供者,供給者及び他の利害関係者のニーズに基づくことが望ましい。

6.4.3.2 費用の種類  サービス提供者は,サービスマネジメントに役立つ予算の費用項目の分類を選択することが望ましい。例えば,サービス提供者は,6.1 のサービスカタログに定義されるサービス及びそのコンポーネントに一致した費用のモデルを定めることが望ましい。費用の種類は,サービスの一部を形成する各費用に割り当てることが望ましい。費用のモデルは,サービス提供者が,様々なレベルのサービスの質又は様々なサービスの選択肢の費用/便益をより正確に予測することができるようになるため,有用である。費用のモデルは,各サービスの提供に係る全費用を実証できることが望ましい。  サービス提供者は,次のような費用の種類も検討することが望ましい。 a) サービスの提供に使用する資産 b) 一次サポートとして知られるサービスデスクなどの共有資源 c) オフィスのスペースなどの間接費 d) 供給者が提供するサービス e) サービスマネジメント要員を雇用する費用

 適切な費用の種類を特定する場合,費用の種類から引き出される詳細な会計情報の便益と,必要となる大量の情報を集め,それを管理する困難さとの釣合いをとることが望ましい。費用の種類は,簡単かつ確実に測定できる分類に基づくことが望ましい。例として,ハードウェア費用,ソフトウェア保守費用,人件費などが挙げられる。

6.4.3.3 間接費の配賦及び直接費の割当て  間接費の配賦は,定額,定率,提供されるサービスについて合意した可変要素の規模に基づくものなど,様々な仕組みに基づいてもよい。  サービス提供者は,配賦を管理する費用が,詳細な費用の配賦が可能になることの便益と釣り合うように,組織にとって適切な間接費の配賦及び直接費の割当ての方法を用いることが望ましい。それ以外に検討してもよい要因は,次の事項を含む。 a) サービスの性質,範囲,及び消費又は利用 b) 顧客の組織の粒度。例えば,事業単位が一つだけであるか,部門に分かれているか,又は地域別になっているか。 c) SLA ,並びにサービス及びサービスレベルへの費用の配賦 d) 供給者が提供するサービス

6.4.3.4 予算業務  予算業務のための費用及び収入の予測では,予算期間中の,計画されたサービス変更を考慮することが望ましい。該当する場合,季節的変動,並びにサービスの費用及び課金に対して計画した短期の変更については,これを理解し,予測予算に含めることが望ましい。予算業務及び費用の追跡は,年間を通してサービスレベルを維持できるように,サービスの運用及び改善の計画立案を支援することが望ましい。合意した期間,サービスを合意したサービスレベルに保つために必要な資源を賄うために十分な,計画された支出を予定しておくことが望ましい。実費と支出予算額との差異を特定し,管理するための手順も定めておくことが望ましい。

6.4.3.5 会計業務  会計活動は,合意した詳細さで費用を追跡するために,合意した期間において利用することが望ましい。サービスを提供することの決定は,費用と効果との比較に基づくことが望ましい。費用のモデルは,サービス提供の全費用を明示できることが望ましい。  会計報告書は,支出と回収との過不足額を示すことが望ましい。会計報告書は,理想的には,サービスレベルが低いものの費用,又はサービスの停止による費用を計算するために十分な情報を提供することが望ましい。サービスレベルが低いもの又はサービスの停止による費用を計算するために,サービス提供者はサービス提供に必要となる資源の費用について明確に理解しておくことが望ましい。これは,要員,コンポーネント,設備,及び他の関係者が提供するサービスの側面を含むことが望ましい。サービス提供者は,継続期間,時期(日,週,月又は年),及び問題となっているサービスに応じて,サービスの停止が事業に与える影響についても明確に理解しておくことが望ましい。この情報は,事業影響度分析で得ることができる。  会計報告書は,特定のサービスを支援する CI の総所有費用及び総減価償却費用を計算するために,CI の状態及びライフサイクルに関する CMDB からの情報を利用してもよい。この情報は,次の予算サイクルにおける費用の理解及び計画に使用することができる。

6.4.3.6 課金業務  課金業務は,JIS Q 20000-1 に含まれていないが,課金業務を使用する場合には,課金の仕組みを定義し,全ての当事者から理解を得ることを推奨する。

6.4.4 文書及び記録  顧客,サービス提供者及び利害関係者が作成し,使用する文書及び記録は,次を含む。 a) 予算業務及び会計業務に関する方針,プロセス及び手順 b) 過去の予算,次年度の予算案及び当年度の予算 c) 作業負荷,容量・能力(要員を含む。),及び収入項目の費用単位に関するサービスマネジメントの予測,並びに計画された資本支出 d) 予算編成の予定表 e) 予算年度の各期間の,差額を含めた収支を示す財務報告書 f) 差額の原因及びその管理方法に関する報告書 g) サービスの継続的改善のプロジェクトへの投入資金 h) サービスの提供及び価値の創出に,費用要素をどのように使用するかを示す費用のモデル i) 法令又は規制上の目的のために必要となる報告書

6.4.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,予算業務及び会計業務管理プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) 財源の管理に責任をもつ予算業務及び会計業務マネージャ b) サービス提供者の組織の中で個別の予算に説明責任をもつマネージャ

6.5 容量・能力管理

6.5.1 要求事項の意図  容量・能力管理プロセスは,現行の合意した容量・能力及びパフォーマンスの要求事項を満たすために,十分な容量・能力を提供することを確実にすることが望ましい。サービス提供者は,合意した将来のサービスの容量・能力及びパフォーマンスの要求事項を満たすために,容量・能力計画を策定し,実施することが望ましい。  注記 容量・能力はキャパシティともいう。

6.5.2 概念  資源は,現行の合意した容量・能力及びパフォーマンスの要求事項を満たし,将来の要求事項の達成に備えるために,釣合いを保つことが望ましい。  容量・能力管理プロセスは,事後対応的活動と事前予防的活動との両方を含むことが望ましい。事後対応的活動は,運用中の容量・能力の継続的な監視,調整,分析及び改善を重視することが望ましい。プロセスの事前予防的活動の側面は,合意した将来の事業需要を満たす計画を中心とすることが望ましい。  容量・能力管理プロセスは,容量・能力の要求事項に合意し,それを予測し,満たすことを確実にするために,計画を策定することが望ましい。これらの計画は,事業予想及び推定作業負荷を特定の容量・能力の要求事項に変換することが望ましい。これは,次の三つの重点分野を容量・能力管理プロセスに組み込むことによって促進することが望ましい。 a) 顧客及びサービス提供者の事業計画及びニーズを将来のサービスの要求事項に定量化することを中心とする事業の容量・能力管理 b) サービスの計画及び管理,並びに合意したサービス目標の全てを満たすことを確実にするための,サービスの計画及び管理並びに資源の支援を中心とするサービスの容量・能力管理 c) サービスの効果的な支援,及び合意したコンポーネントの目標の達成を確実にするための,運用資源及びコンポーネントの計画,並びに管理を中心とするコンポーネントの容量・能力管理

6.5.3 要求事項の説明 6.5.3.1 容量・能力管理活動  容量・能力管理活動は,容量・能力の使用状況の監視,容量・能力データの分析などの日々の運用作用,サービス目標を基準にしたパフォーマンスの管理,及び将来の容量・能力の要求事項のための計画を包含する。  容量・能力管理プロセスの活動は,次の事項を含む。 a) 容量・能力の要求事項のアセスメント,文書化及び合意,作業負荷及びパフォーマンスのベースラインの定義,並びに作業負荷及びパフォーマンスのしきい(閾)値及びきっかけの設定。 b) 新規サービス又はサービス変更の容量・能力の要求事項のアセスメント,文書化及び合意。 c) 容量・能力管理プロセスは,パフォーマンス及び/又は容量・能力が要因となっている場合,新規サービス又はサービス変更の設計に関与し,コンポーネント及び資源の調達に関して推奨を行うことが望ましい。費用と容量・能力との釣合いをとる必要があることから,容量・能力管理プロセスは,解決策案の候補の費用を調べ,最も適切な,費用対効果の高い解決策を推奨することが望ましい。 d) 新しい容量・能力の要求事項のための活動は,計画立案,支援チーム及び事業グループから得られるインプットに基づくことが望ましい。これには,新規プロジェクトのインフラストラクチャ導入の計画立案,及び老朽化したインフラストラクチャのコンポーネントの交換の予測を含めることが望ましい。 e) コンポーネントの活用及びサービスのパフォーマンスを自動的に管理し改善するための,容量・能力のしきい(閾)値,警告及び警報の設定,監視及び使用。 f) 容量・能力データベースと言われることが多いリポジトリへの,容量・能力管理プロセスが使用するデータ及び情報の保存。このリポジトリは,容量・能力管理プロセスの主要な要素とすることが望ましい。容量・能力データベースに含まれるデータ及び情報は,全ての容量・能力管理活動で分析されており,次に示す技術の全分野から得られる,事業,サービス,資源又は利用度,及び財務に関するデータを含むことが望ましい。  1) 事業データ:現在及び将来の事業ニーズに関する信頼性の高い情報  2) サービスデータ:トランザクション応答時間,トランザクション量及び作業負荷量(これらだけに限らない。)  3) コンポーネントの利用状況に関するデータ:コンポーネントが利用されることが望ましいレベルの限界は,文書化しておくことが望ましい。この利用レベルを超えた場合,資源が過剰に利用され,その資源を使用しているサービスのパフォーマンスが損なわれる。  4) 容量・能力管理プロセスが利用する他のデータ:障害及び特定された弱点,冗長性及び予備の容量・能力,資源,コンポーネント,サービスのしきい(閾)値及び許容誤差,現在,過去及び予測できるスループット及びパフォーマンス,並びに実際の達成度と予想達成度との比較を含める。 g) 多くのサービスマネジメントのプロセスに貴重な情報を提供する,容量・能力及びパフォーマンス報告書の作成。容量・能力報告書は,利害関係者が参照できるように,容量・能力データベースにまとめて保存することが望ましい。これらの報告書には,次の事項を含めることが望ましい。  1) コンポーネントのパフォーマンスがどれほどで,その容量・能力のどれほどが利用されているかを説明したコンポーネント単位の報告書及び情報  2) サービス及びそれを構成するコンポーネントが,サービス目標及び制限の全体に対して,どのようなパフォーマンスを示しているかを説明したサービス単位の報告書及び情報。これらの報告書は,容量・能力及びパフォーマンスに関する顧客サービス報告書並びに SLM 報告書の基礎となる。  3) 特定のコンポーネント,又はサービスの容量・能力及びパフォーマンスが,いつ許容できないものとなったかを,マネジメント及び技術要員に示す例外報告書も作成することが望ましい。特に例外報告書は,SLA の目標を達成したか又は違反したかを判定するとき,SLM プロセスの役に立つことが望ましい。インシデント及びサービス要求管理プロセス,並びに問題管理プロセスは,インシデント及び問題の解決で例外報告書を利用することができる。 h) 将来のコンポーネント,並びにサービスの容量・能力及びパフォーマンスの予想は,採用する技法及び技術に応じて様々な方法で行うことが望ましい。例として次の事項が含まれる。  1) ベースラインのモデル化は,モデル化の第一段階である。これは,達成されているパフォーマンスを正確に反映する,ベースラインのモデルの作成に使用する。このベースラインのモデルが作成された場合,予測モデル化の開発が可能となる。  2) 傾向分析は,収集された資源の活用及びサービスのパフォーマンス情報を使って完了する。  3) 分析モデル化は,コンピュータシステムのパフォーマンスを分析するために数学的手法を用いる。  4) シミュレーションのモデル化は,所定のシステム構成を基準にしたトランザクション到着率など,離散事象のモデル化を伴う。

6.5.3.2 容量・能力計画  容量・能力計画は,実際のパフォーマンス,予想される事業上の容量・能力ニーズ及びサービスの要求事項を文書化することが望ましい。これは少なくとも年に 1 回,又はサービスの変更の度合い及びサービスの量が要求する場合は,より頻繁に作成することが望ましい。容量・能力計画は,事業上の要求事項を満たすための合意したサービス目標及び費用の選択肢を達成する目的で,推奨される解決策を文書化することが望ましい。  容量・能力計画は,次の事項を含むことが望ましい。 a) 現在の及び将来のサービス利用量で,理想的には,容量・能力需要に影響する機会に関する推奨を含む。 b) 現在の及び将来の資源利用量及びパフォーマンスで,どの資源がどのサービスを支援するかの理解を含む。 c) 災害時の推定作業負荷,容量・能力の要求事項など,可用性,サービス継続及びサービス目標に関する合意された要求事項が容量・能力及びパフォーマンスに及ぼす影響 d) 経営統合の結果としての,サービスの容量・能力の増加を提供するために必要な,日数,費用など,サービスの容量・能力を拡大するための期間,しきい(閾)値及び費用 e) 関連する事業計画,シナリオ及び事業活動のパターンの概要 f) 利用できる場合は利用者情報を含む,事業活動の変更の概要 g) 容量・能力計画の詳細の計算に用いる方法,前提及び情報の詳細 h) 容量・能力及びパフォーマンスに新技術が及ぼす潜在的影響 i) モデル化の技法など,予測分析を可能にするデータ及び手順 j) 規制を満たす電子カルテ用の十分な容量の記憶領域,バックアップ容量・能力を維持するための計画など,法令上,規制上,契約上及び組織上の要求事項に及ぼす潜在的影響

6.5.4 文書及び記録  容量・能力管理プロセスで作成し,保持する文書及び記録には,次の事項を含めることが望ましい。 a) 容量・能力計画 b) 容量・能力管理手順 c) ベースライン及びプロファイル d) 容量・能力管理データベース e) サービス及び資源のしきい(閾)値の仕様,並びに事象及び警報のしきい(閾)値 f) サービスのパフォーマンス報告書 g) 利用レベル及びスケジュール h) 有効性のレビュー i) 作業負荷の分析 j) 容量・能力管理の例外報告書 k) 容量・能力及びパフォーマンスに関するインシデント記録のレビュー

 容量・能力管理プロセスによってレビューする文書及び記録には,SLA 及び要求されるサービスレベル並びに監査報告書を含めた,顧客及び事業者の現在及び将来のサービスの容量・能力の需要及び要求事項を含めることが望ましい。容量・能力計画の変更は,変更管理プロセスで管理することが望ましい。

6.5.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,容量・能力管理プロセスで必要となる権限及び責任には,次の要員を含めることが望ましい。 a) 現在及び潜在的な容量・能力の課題を特定し,その課題を解消し,サービスのパフォーマンスを維持するための解決策が特定できるように,容量・能力及びパフォーマンスのデータの分析及びレビューに責任をもつ容量・能力の分析者。容量・能力の分析者は,容量・能力の継続的な需要を満たすための,選択肢の特定並びに奨励策の分析及び推奨を補佐する。 b) 全ての容量・能力要求事項の文書化及び合意に責任をもつ,顧客及び事業者の代表。

6.6 情報セキュリティ管理

6.6.1 要求事項の意図  情報セキュリティ管理(以下,ISM という。)プロセスは,情報資産を保護するためにセキュリティ管理策を設けること,並びに,情報セキュリティの要求事項が新規サービス又はサービス変更の設計及び移行に組み込まれることを確実にすることが望ましい。

6.6.2 概念  情報セキュリティは,組織の情報,並びに情報の格納,転送及び処理に関連して使用される,あらゆる資源を識別し,制御し,かつ,保護するように設計された方針及び手順を体系にしたものであることが望ましい。  経営者は,明確に定義された情報セキュリティ管理目的が備えられ,それが事業ニーズに整合することを確実にすることが望ましい。  サービス提供者及び顧客は,情報資産を,価値,機密性又は事業に与える影響に応じて分類することが望ましい。サービス提供者及び顧客は,各分類別に,リスクの受容レベルを定義し,合意することが望ましい。

6.6.3 要求事項の説明 6.6.3.1 情報セキュリティ方針  サービスの要求事項,法令・規制要求事項及び契約上の義務は,情報セキュリティ方針の基礎を提供することが望ましい。方針は,機密性,完全性,アクセス性など,情報資産のセキュリティを保護するように設計される物理的,実務管理的及び技術的な情報セキュリティ管理策の採用に方向性を示すことが望ましい。方針は,SMS 及びサービスに説明責任をもつマネージャによる承認を得ることが望ましい。  注記 1 対応国際規格の“accessibility”に対して“アクセス性”の訳語を当てたが,これは JIS Q 27001:2006 の“information security”の定義に用いられている“availability”と同じ意味である。  情報セキュリティ方針の適用範囲には,SMS の適用範囲内で情報資産の機密性,完全性及びアクセス性を確実にするために必要な物理的,実務管理的及び技術的管理策を含めることが望ましいが,これらだけに限らない。情報セキュリティ方針の適用範囲は,事業ニーズに応えるために SMS の適用範囲を超えることもある。  経営者は,要員,顧客及び供給者,並びに内部グループが,方針の内容を適切に理解し,方針を順守することの重要性を認識することを確実にすることが望ましい。  さらに,経営者は,情報セキュリティ方針を,リスクアセスメントの一部として,及び情報セキュリティ監査のときに,用いることを確実にすることが望ましい。  方針は,リスク受容基準,及びパスワード管理などの特定された情報セキュリティリスクを管理するための取組みに関する手引となることが望ましい。  方針は,情報セキュリティ内部監査を,情報セキュリティ違反の後,新規サービス又はサービス変更の展開後など,一定の間隔で実施することを確実にすることが望ましい。  方針は,情報セキュリティ監査の結果について一定の間隔でレビューを行い,これを用いて情報セキュリティの改善の機会を特定することを確実にすることが望ましい。例えば,情報セキュリティ監査時に特定されるぜい(脆)弱性の修正などである。  注記 2 情報セキュリティの専門家としての役割を担う要員は,JIS Q 27002 に精通していると役に立つ。この規格は,セキュリティ方針の内容に関する手引を含んでいる。

6.6.3.2 情報セキュリティ管理策  情報セキュリティ管理策は,情報セキュリティ管理の目的を達成し,情報セキュリティリスクを管理することを保証することが望ましい。情報セキュリティ管理策は,物理的,実務管理的,又は技術的なこともある。  サービス提供者は,管理策が文書化され,関連リスク及びリスク軽減戦略を記述したものであることを確実にすることが望ましい。また,サービス提供者は,管理策のレビューについての権限及び責任,並びにどの程度の頻度で管理策をレビューすることが望ましいかについて,定義することが望ましい。  さらに,サービス提供者は,組織の情報又はサービスにアクセスし,それを使用又は管理する必要がある外部の組織及び個人を管理するために,情報セキュリティ管理策を定義することが望ましい。

6.6.3.3 リスクアセスメント  ISM プロセスは,稼働環境の情報セキュリティリスクを特定するために,定期的にリスクアセスメントを実施することが望ましく,次にそれを文書化し,特定されたリスクの影響を予防又は最小化するための具体的な管理策を実施することが望ましい。また,ISM プロセスは,新規サービス又はサービス変更の設計及び移行の一部として,適切なリスクアセスメントを行うか,又は行われることを確実にすることが望ましい。  情報セキュリティ方針は,情報セキュリティリスクアセスメントが,次のとおりであることを確実にすることが望ましい。 a) 新規サービス又はサービス変更に対するものを含めて,合意した間隔で実施される。 b) 記録し,承認された要員だけに可視的であるようにする。 c) 事業ニーズ,プロセス及び構成の変更の間も維持される。 d) サービスに影響を及ぼすものについての理解を助ける。 e) 情報セキュリティ監査に関する要求事項を定義する。 f) 運用する管理策の種類に関する決定を通知する。

 情報資産のリスクは,リスクの性質及び事業に与える潜在的な影響に応じてアセスメントを行うことが望ましい。  注記 情報セキュリティの専門家としての役割を担う要員は,ISO/IEC 27005 に精通していると役に立つ。

6.6.3.4 情報セキュリティリスクの管理  情報セキュリティ管理策は,サービス提供者が,サービスマネジメントの目的及びセキュリティ方針の要求事項を達成できることを確実にすることが望ましい。また,管理策は,サービス提供者が特定された全ての情報セキュリティリスクを管理できるようにすることが望ましい。  情報セキュリティ管理策の例を次に示す。 a) 情報セキュリティ方針を確立し,導入し,要員,供給者及び顧客に周知させることが望ましい。 b) 情報セキュリティ管理プロセスの権限及び責任を定義し,割り当てることが望ましい。 c) 情報セキュリティ方針の有効性を監視し,測定し,アセスメントを行うことが望ましい。 d) 重要な情報セキュリティの役割を担う要員は,情報セキュリティに関する教育・訓練を受けることが望ましい。 e) リスクアセスメント及び管理策の導入について,専門家の助けが得られるようにしておくことが望ましい。 f) 変更によって,管理策の効果的な運用が損なわれないほうがよい。 g) 情報セキュリティインシデントは,インシデント及びサービス要求管理プロセスに従って報告し,適切な優先度を割り当てられることが望ましい。 h) 情報セキュリティインシデントは,その優先度及びセキュリティインシデント記録にアクセスするために必要な権限のレベルに応じて,それを解決する権限をもつ要員への段階的取扱いをすることが望ましい。 i) 情報セキュリティインシデントの詳細は,適切な権限をもつ要員だけに可視的であるようにすることが望ましい。 j) 定期的なリスクアセスメントは,組織のリスク耐性への準備状況の変化を特定するために完了することが望ましい。 k) 定期的な監査は,確立された情報セキュリティ方針及び管理策の適合性を確認するために実施することが望ましい。 l) 情報セキュリティのベースラインは,定義され,効果的に適用されることが望ましい。 m) 情報セキュリティ監査の所見は,分析して,優先度付けされた行動計画に集約することが望ましい。 n) 情報セキュリティの教育・訓練計画及び教育・訓練記録を作成し,最新に保つことが望ましい。

 サービス提供者は,サービス提供者の情報にアクセスするか又はそれを利用する外部組織とともに,情報セキュリティ管理策を特定し,文書化し,管理することを確実にするために,供給者管理プロセスと連携することが望ましい。

6.6.3.5 情報セキュリティの変更及びインシデント  情報セキュリティの変更及びインシデントは,変更管理プロセス,並びにインシデント及びサービス要求管理プロセスに従って処理することが望ましい。  変更要求は,変更案の結果としての新たな情報セキュリティリスク又は情報セキュリティリスクの変更を特定する目的で,アセスメントを行うことが望ましい。また,変更要求は,既存のサービス,プロセス及び方針又は既存の情報セキュリティ管理策への潜在的影響を基準にしてアセスメントを行うことが望ましい。  サービス提供者は,潜在的欠陥及び改善の機会を特定するために,情報セキュリティインシデントの記録のレビュー,並びに情報セキュリティアセスメント及び監査の結果を用いることが望ましい。

6.6.4 文書及び記録  ISM プロセスによって作成し,保持することが望ましい文書及び記録は,次の事項を含めることが望ましい。 a) 情報セキュリティ戦略 b) 情報セキュリティ方針 c) 情報セキュリティ計画 d) 情報セキュリティ管理手順 e) 情報セキュリティ報告書 f) ISM プロセスの有効性及び効率性に関する報告書 g) 情報セキュリティインシデントの記録 h) 情報セキュリティリスクアセスメント i) 情報資産台帳

 文書及び記録は,経営者に情報セキュリティ方針の有効性に関する情報を提供するために,定期的に分析することが望ましい。その他に役に立つ側面としては,情報セキュリティインシデントの傾向,サービス改善計画へのインプット,並びに情報,資産及びシステムへのアクセス管理がある。

6.6.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,ISM プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) ISM の CI 及びデータへのアクセスを必要とする顧客,サービス提供者の要員及び利害関係者 b) 情報セキュリティ管理策を維持する要員

7 関係プロセス

7.1 事業関係管理

7.1.1 要求事項の意図  BRM プロセスは,サービス提供者と顧客との関係を管理するための仕組みを確立することを確実にすることが望ましい。プロセスの成果は,顧客満足度の改善,及び達成可能な事業成果による価値の提供であることが望ましい。サービスの要求事項を特定し,その優先度付けを行うための顧客及びサービス提供者の双方の説明責任及び責任を,明確に定義することが望ましい。サービス提供者と顧客との継続的な関係を管理するための手順を定義し,これに従うことが望ましい。  サービス提供者と顧客との関係を管理するための仕組みは,次の事項を含むことが望ましい。 a) 顧客関係及び顧客満足度の管理に責任をもつ指名された個人 b) サービス提供者が事業環境,事業ニーズ及び優先度,並びに新規サービス又はサービス変更に関する要求事項を理解できるようにするための,顧客との定期的なコミュニケーション c) サービスの顧客との,稼働環境での定期的なパフォーマンスのレビュー

7.1.2 概念  BRM プロセスは,サービス提供者と顧客との戦略的整合の進展を実現する主要なプロセスであることが望ましい。事業価値の増大は,顧客の事業上のニーズとサービス提供者の目的との整合を通じて実現することが望ましい。BRM プロセスは,サービス提供者と顧客との間に認識された,又は実際の障壁の低減に寄与することが望ましい。  BRM プロセスと SLM プロセスとの間に,強い関連があることが望ましい。SLM プロセスは,サービスレベルのパフォーマンスを評価するための対策を定義し,利用することが望ましい。SLM プロセスは,現在提供されているサービス及びサービスレベルを運用レベルで管理することが望ましい。  これに対して,BRM プロセスは,将来の事業目的及び方向性を理解するために,顧客との緊密な連携を追求することが望ましい。これによって,BRM プロセスは,顧客のニーズに先駆けてサービス変更を計画できることを確実にすることが望ましい。また,顧客の事業目的を十分に理解することによって,サービス提供者が,顧客の事業ニーズを満たす密接に整合した解決策を提供できるようにすることが望ましい。  大規模な商用サービスを多数の顧客に提供する場合,各顧客と個別の関係をもつことが困難なことがある。例えば,個々の家庭が利用するインターネットサービスである。このような場合,サービス提供者は,どのように複数の顧客とやりとりするかを考慮することが望ましい。顧客満足度の測定は,計画したサービス及び実際のサービスが顧客要求事項に整合していることを確実にするために使用することができる。

7.1.3 要求事項の説明 7.1.3.1 一般  サービス提供者は,サービス間の依存関係を完全に理解するために,その顧客,他の利害関係者,供給者及び従属する再請負契約先供給者を特定し,文書化することが望ましい。例えば,インターネットを利用したサービスは,セキュリティが保たれたウェブポータル及び暗号化機能を提供するサービスに依存している。利害関係者は,利用者のグループ及び事業単位を含むことがある。  サービス提供者は,提供するサービスの種類に従って顧客を分類することが望ましい。特性の類似した顧客は,効率性及び有効性を改善するために類似の方法で分類してもよい。サービス提供者が定義するプロセスは,細かいレベルでは,顧客の種類ごとに異なることがある。  サービス提供者は,顧客の単一窓口として個人を特定することが望ましく,その個人が顧客ごとに関係及び顧客満足度の管理に責任をもつ。この個人は,専任で顧客関係を管理するように選んでもよいし,該当する場合,その役割を別の役割と兼務してもよい。  BRM プロセスと SLM プロセスとが密接な関係にあるために,事業関係マネージャの役割及びサービスレベルマネージャの役割を同一人物が果たすことができる。同一人物が二つの役割を果たす場合は,役割の異なる性質を役割記述書で区別することが望ましい。BRM プロセスは,戦略的なものであるのに対して,SLM プロセスは運用又は戦術に関わるものである。これほど視点が異なる二つの役割を,同一人物が果たすことのリスクについても管理することが望ましい。  顧客との間で成立するコミュニケーションの仕組みは,議事録をとる正式な会議に加えて,臨時会議及び非公式の会議を含むことが望ましい。これらのコミュニケーションは,顧客との関係を築き,事業上の優先度及び目的の変更を特定し,サービス提供者が行動を起こすきっかけとなることが望ましい。  コミュニケーションの仕組みは,事業ニーズ,顧客要求事項及び重大な変更を含めて,サービスが運用される事業環境の理解を助けることが望ましい。サービス提供者は,特定されたニーズに対応するために,この情報を用いることが望ましい。  サービス提供者は,顧客に関する情報を追跡し,管理するためのツールを使用することができる。

7.1.3.2 顧客サービス管理のレビュー  サービス提供者は,顧客満足度,戦略的方向性及びサービスのパフォーマンスの重大な例外に関するレビューを行うために,顧客との正式な会議を開催することが望ましい。このような会議は,SLA 及びパフォーマンスのレビュー,サービス提供者の組織の変更,並びに顧客の組織の変更を含むことが望ましい。  会議には,全ての当事者の代表が出席することが望ましい。会議は前もって予定を組み,定期的に,少なくとも年に 1 回開催することが望ましい。実際の頻度は,サービスの要求事項の変更の度合い,新規サービスなどの重大なプロジェクト及び提供するサービスの質によって変更することが望ましい。サービス提供者及び顧客が頻繁な変更を管理しているとき,又はサービスの質に懸念があるときは,少なくとも年に 1 回よりも高い頻度で会議を開くことが望ましい。例えば,サービスの要求事項の頻繁な変更,新規サービス又はサービス変更などの重大なプロジェクトがそれに当たる。もし顧客レビュー会議を年に 5 回以上開くと,参加する管理責任者にとって会議の内容が不十分なものとなり,逆効果となることがある。  顧客レビューの成果は,既存のサービス又はサービスレベルに必要となる,新規サービス又はサービス変更が特定されることである。サービス提供者は,SLA 及び契約の変更を,変更管理プロセスを通じて管理し,成立済みの SLM プロセスに従うことを確実にすることが望ましい。  顧客要求事項からサービス変更までの,トレーサビリティを確立することが望ましい。

7.1.3.3 顧客満足度  サービス提供者は,顧客満足度を記録する正式な仕組みを定めることが望ましい。測定の頻度及び規模は,前もって顧客との間で合意することが望ましく,これには調査対象となる利用者のサンプルを含めることが望ましい。このような活動は,多くの場合,インシデント/問題の解決後に,一次サポートとして知られるサービスデスクが進めることがある。ただし,正しい顧客満足度の測定のためには,例えば,サービス要求の数及び種類,実際の費用,認識された費用,提供されるサービスの事業価値などを含む,幅広い測定を実施することが望ましい。改善の機会を特定するために,その結果を特定し,分析し,レビューすることが望ましい。  満足度調査結果は,満足度の傾向を追跡し,必要な課題又は改善が特定されるように,長期にわたって測定することが望ましい。  サービスに関する苦情の対応手順書は,受け取ったサービスに関する苦情の記録,調査,処置,報告及び終了を含むことが望ましい。手順書は,顧客が処置案又は解決案に合意しない場合,又はそれを受け入れない場合に使用する,段階的取扱い手順を含むことが望ましい。苦情は,苦情が解決したと顧客が正式に合意するまで,未解決にしておくことが望ましい。  サービス提供者は,サービスに関する正式な苦情の原因が何かを理解し,定義し,顧客との間で合意することが望ましい。サービスに関する正式な苦情は,通常,極めて深刻であり,口頭ではなく書面で提出される。サービスに関する正式な苦情は,顧客のマネージャがサービス提供者のマネージャに送付することが望ましい。インシデント又は問題は,苦情の原因となることがあるが,これ自体は苦情ではない。  苦情のレビュー結果は,顧客の意見が重大に受けとめられて,対処されていると分かるように,要約して顧客に報告することが望ましい。

7.1.4 文書及び記録  BRM プロセスの文書には,次の事項を含めることが望ましい。 a) 基本となる連絡先情報,重要な役割,利用されるサービスなどを含む顧客/利害関係者に関する記述 b) 指名された個人が顧客と共有するための役割の仕様 c) 顧客とサービス提供者との間で開催された正式な会議の議題及び議事録 d) 顧客とサービス提供者との間で開催された非公式の会議のメモ e) サービス提供者のパフォーマンス全体を示すサービス測定基準の概要 f) サービスに関する苦情の対応手順書 g) 苦情及び処置の記録 h) 顧客満足度の調査/測定 i) 満足度のレビュー,分析及び処置の記録 j) 顧客にフィードバックするための,顧客満足度調査の結果の概要。

7.1.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,BRM プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) 苦情,顧客満足度データの収集及び分析を含む,顧客満足活動全般の実施に責任をもつ事業アナリストの役割 b) 次の事項に責任をもつ事業関係マネージャの役割

 1) 顧客別の顧客満足度の改善  2) サービス提供者の組織内での顧客の代行活動  3) サービス提供者と顧客との間の,効率的で効果的なコミュニケーションの仕組みの確立  4) 顧客を交えたサービスレビューの実施,及び改善又は処置の確実な実施  5) SLM プロセスによる,顧客要求事項の変更の,SLA 及びその他の文書への確実な反映  6) SLM プロセスとの窓口  7) 苦情が解決されて顧客が満足することを確実にするための,サービスに関する正式な苦情の管理  8) 顧客満足度の定期的な測定,並びに結果の分析,レビュー及び処置の確実な実施  9) 顧客満足度調査の結果及びとった処置の適時な顧客への連絡  10) 顧客からの段階的取扱いに対する,適時で効果的な処理の確実な実施  11) 将来の事業上の要求事項の理解及び計画立案

 この役割の名称は,事業関係マネージャが一般的だが,変わることがある。これ以外にも,顧客関係マネージャ又はアカウントマネージャという肩書きが考えられる。サービス提供者は,状況に応じて,この役割を別の役割と兼ねることもでき,また,チーム全体で実施することもできると認識することが望ましい。  この役割を効果的に果たすために,サービス提供者は,サービス提供者自身の事業,技術,並びに顧客の事業上の要求事項及び優先度に関する専門知識が必要であると認識することが望ましい。また,顧客要求事項をサービス提供者の技術の専門家に周知させるために,この専門知識を用いることが望ましい。この役割の複雑さは,細部への配慮及び複数の当事者と連絡をとる能力を,役割の重要な側面として認識することが望ましいことを意味する。また,サービス提供者は,これらの責任が,若く経験の浅い役職レベルの力量を超えていると認識することが望ましい。

7.2 供給者管理

7.2.1 要求事項の意図  供給者管理プロセスの目的は,中断のない高品質のサービスの提供を確実にするために,供給者を管理することであることが望ましい。サービス提供者は,プロセス若しくはサービスの一部の運用,又はハードウェア,ソフトウェアなどのコンポーネントの供給に供給者を利用することができる。供給者管理プロセスは,全ての供給者に用いることが望ましい。これには,サービス提供者のためにプロセス又はプロセスの一部を運用する供給者が含まれる。供給者管理プロセスは,内部グループ及び供給者として活動する顧客を管理するために SLM プロセスを補足するものとして役立つ。

7.2.2 概念  供給者管理手順は,次の事項を確実にすることが望ましい。 a) 供給者がサービス提供者に対する義務を理解する。 b) 合意したサービスレベル及び適用範囲内で,合意した要求事項を満たす。 c) 要求事項及び義務の変更を管理する。 d) 全ての当事者間の業務トランザクションを記録する。 e) 全ての供給者のパフォーマンスに関する情報を観察し,対処することができる。 f) サービス提供者の顧客との SLA を,供給者との契約に整合させる。

7.2.3 要求事項の説明 7.2.3.1 契約の管理  サービス提供者は,各供給者との関係を担当する担当窓口を指名することが望ましい。サービス又はサービスコンポーネントが依存関係をもつ場合は,供給者間でも窓口を指名することが望ましい。  契約には,供給者に求める要求事項及びサービスレベルを含めることが望ましい。供給者の契約で合意したサービス目標は,サービス提供者と顧客との SLA が満たされることを確実にするために明確にすることが望ましい。供給者のサービスレベルが SLA と整合していない場合は,リスクとして,そのリスクを適時に解決するための計画を策定して管理することが望ましい。  全ての供給者契約には,レビューのスケジュールを含めることが望ましい。少なくとも年に 1 回のレビューをスケジュールに組むことが望ましい。レビューは,サービス又はサービスコンポーネントを調達するための事業目的が引き続き有効であるかどうか,また,供給者が合意したパフォーマンスを達成しているかどうかのアセスメントを,契約のサービス目標に照らして行うことが望ましい。  各契約を管理するための,明確に定義されたプロセスがあることが望ましい。契約修正のためのプロセスも,明確に定義しておくことが望ましい。この手順に変更があるときは,影響を受ける全ての供給者に正式に通知することが望ましい。  契約が罰則又は報奨を含む場合は,その論拠を明記し,要求事項及びサービス目標との適合性を測定し,報告することが望ましい。  供給者がサービスの一部を提供する場合は,サービス提供者は,供給者との契約に,該当する顧客要求事項の達成に必要な全ての事項が含まれることを確実にすることが望ましい。これは,顧客にコミットメントを示す前に確認し,文書化することが望ましい。供給者は,4.2 に規定するように,サービス提供者が,供給者が運用するサービスマネジメントのプロセスのガバナンスをもつことを受け入れることが望ましい。  サービス提供者は,供給者が契約の全要求事項を満たし,その要求事項を一貫して満たしていることを,効果的に確実にする質の高いプロセスを備えているという証拠を,あらかじめ定めた間隔で入手することが望ましい。これは,サービス提供者による供給者の監査という手段で達成してもよい。  再請負契約サービスに関する会議,レビュー及び監査の全結果について,改善の機会を特定するためにレビューすることが望ましい。変更が必要な場合は,変更管理プロセスに従って管理することが望ましい。

7.2.3.2 供給者の詳細  サービス提供者は,サービスごと及び供給者ごとに,次の情報を,その情報が契約に含まれていない場合でも,記録しておくことが望ましい。 a) サービス,役割及び責任の定義 b) サービスの適用範囲及び能力 c) 供給者が満たすべき要求事項 d) 定義し,合意したサービス目標,サービス目標を達成しなかったときの罰則又は影響 e) トランザクション回数,サーバの数,データベースの規模など,作業負荷の特性 f) SLA の合意した例外基準 g) 契約管理プロセス,認可レベル及び契約解消の計画 h) 該当する場合の支払条件 i) 合意した報告のパラメタ及び達成したパフォーマンスの記録

7.2.3.3 再請負契約先供給者の管理  サービス提供者が全ての供給者と直接取引をしているのか,又は再請負契約先供給者に対する責任をもつ統括供給者と取引をしているのかを明確にすることが望ましい。  サービス提供者は,統括供給者が再請負契約先供給者を正式に管理しているという証拠を,統括供給者から入手することが望ましい。この証拠は,JIS Q 20000-1 の要求事項に従うことが望ましい。統括供給者には,全ての再請負契約先供給者の名称,並びにその再請負契約先供給者の責任及び関係を記録するように要求することが望ましい。この情報は,必要な場合には,サービス提供者に提供することが望ましい。サービスの一部を提供している供給者及び再請負契約先供給者の例を,図 3 に示す。これは,ISO/IEC 20000-3から転載したものである。

図 3−統括供給者及び再請負契約先供給者との関係の例

7.2.3.4 契約紛争の管理  サービス提供者と供給者との双方が,紛争を管理するためのプロセスに合意することが望ましい。これは,契約書の中で定義するか,又は言及して,必要に応じて実施することが望ましい。通常のコミュニケーション手段で解決することのできない紛争については,段階的取扱いの経路を設けることが望ましい。このプロセスは,紛争を記録し,調査し,対処し,正式に終了することを確実にすることが望ましい。

7.2.3.5 契約の終了  契約管理プロセスは,予定どおりの終了,又はそれより早いかの,いずれかの契約終了に関する規定を含むことが望ましい。また,契約管理プロセスは,契約終了時の,他の組織へのサービスの移管についても規定することが望ましい。契約終了条項は,サービス,費用,知的財産の所有,ハードウェア,ソフトウェアライセンス及びデータの廃棄又は移管に関する責任を明確にすることが望ましい。

7.2.4 文書及び記録  全ての供給者契約の承認済みの写しを,サービス提供者及び供給者が保有することが望ましい。契約には,サービスの定義を含めるか参照することが望ましく,供給者が提供する全てのサービスを対象とするサービスマネジメントのプロセスを特定することが望ましい。複数の当事者が運用するプロセス間のインタフェースは,文書化することが望ましい。  サービス提供者は,次の事項も保有することが望ましい。 a) 顧客,サービス提供者,統括供給者及び再請負契約先供給者を含めた,全ての利害関係者の組織の名称,責任及びその関係 b) 定期的な契約レビュー会議の記録及びその結果とった処置並びに再請負契約先監査の報告書を含む,サービス提供者が供給者を正式に管理していることを示す証拠 c) b)と同様に,統括供給者が正式に再請負契約先供給者を管理していることを示す証拠

7.2.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,供給者管理プロセスで必要となる権限及び責任には,次の要員を含めることが望ましい。 a) 供給者関係マネージャ。サービス提供者と個別の供給者との関係の管理に責任をもつように指名された個人。これには,契約及びパフォーマンスの管理を含む。複数の要員がこれらの活動に従事している場合,供給者のパフォーマンスに関する情報は,一貫性があり,比較可能であり,観察され,かつ,対応されることを確実にするための手順があることが望ましい。 b) 各供給者内で定められた担当窓口。

8 解決プロセス

8.1 インシデント及びサービス要求管理

8.1.1 要求事項の意図  インシデント及びサービス要求プロセスは,インシデントの解決又はサービス要求の実現を,合意したサービス目標及び時間枠内に達成することを確実にするために,インシデント及びサービス要求を一貫して管理することが望ましい。

8.1.2 概念  インシデント及びサービス要求プロセスは,全てのインシデント及びサービス要求を,事業及び顧客の優先度に従って,効果的かつ効率的に管理できることが望ましい。インシデント及びサービス要求の一環として収集したデータは,該当するサービス目標を基準にしたパフォーマンスの監視に使用することが望ましい。このデータは,顧客に渡すサービス報告書に含めることができる。  インシデントは,計画外のサービスの中断,サービスの質の低下,又はまだサービスに影響を及ぼしていない構成品目の障害と考えられる。サービス要求の例には,低リスクで,十分に定義され,事前に承認を受けた変更などの標準変更,情報の要求,手引の要求,標準的サービスへのアクセスの要求などが含まれることがある。  インシデント及びサービス要求管理プロセスは,二つの別々の文書化された手順で支援することが望ましい。一つはインシデントの管理用であり,もう一つはサービス要求の管理用である。二つの手順は,次の事項を定義することが望ましい。 a) インシデント及びサービス要求の一貫した記録 b) 合意し,文書化されたサービス目標に基づく,インシデント及びサービス要求の優先度付け及び分類 c) 8.1.3−8.1.6 に詳述する,インシデントの解決及びサービス要求の実現に必要な活動 d) インシデントが解決したか,又はサービス要求が実現されたことについての利用者からの確認に関する,インシデント及びサービス要求記録を更新し,終了するために必要な処置 e) 該当する場合,合意したサービスレベルに従って,各インシデント又はサービス要求の解決又は実現を確実にするための段階的取扱い

 インシデント及びサービス要求の手順は,既知の誤り及び問題とインシデントとの比較,並びにサービスカタログとサービス要求との比較を含むことが望ましい。

8.1.3 要求事項の説明 8.1.3.1 インシデント及びサービス要求の受付け及び記録  インシデント及びサービス要求管理プロセスの手順は,インシデント及びサービス要求を受け付け,それを記録する仕組みを定義することが望ましい。これは,次の事項を確実にすることが望ましい。 a) 取扱いの一貫した取組み b) 組織に要求されたデータの保存及び検索 c) 合意したサービス時間帯とそれ以外の時間帯との両方で,適切なコミュニケーション経路及び方法が利用可能な状態である。

 全てのインシデント及びサービス要求は,その優先度及びサービス目標のコミットメントに従って対応できるように分類することが望ましい。インシデント又はサービス要求の種類による分類は,どの CI が影響を受けるか,次に,解決又は実現に関与する必要のある要員を特定するために何が手がかりになるかの,判断を含むことが望ましい。  優先度は,インシデント若しくはサービス要求を受け付けてから,又はその後可能な限り早く,顧客と合意することが望ましい。優先度の決定は,問題となっているインシデント又はサービス要求の影響,及び緊急度のアセスメントに基づくことが望ましい。  インシデント及びサービス要求は,セキュリティへの潜在的波及効果と,通常の運用対応に加えてセキュリティインシデント対応手順を実施することが望ましいかどうかの決定とに関して,評価されることが望ましい。例えば,運用要員は,情報セキュリティ担当要員又は法的機関の要員に連絡すべきかどうかを決定する手順を定めておくことが望ましい。  サービス目標について討議し,その目標に合意することの一部として,インシデント及びサービス要求の両方に関して,影響及び緊急度に基づいた優先度表を作成することが望ましい。優先度に基づいたインシデントの解決目標時間の例を,表 1 に示す。インシデント及びサービス要求の両方に関して,数種の分類の一つ一つに基づく目標の一般原則を採用することが望ましい。

表 1−優先度に基づくインシデントの解決目標時間の例

 表 1 はインシデントのためのものであり,サービス要求の場合は,目標時間が異なるので別の表が必要となる。

8.1.3.2 インシデント及びサービス要求のライフサイクル並びにデータの使用  インシデント及びサービス要求管理プロセスの一部として,次の事項を定義することが望ましい。 a) インシデント及びサービス要求のインプットの出所の識別 b) インシデント及びサービス要求の記録の作成及び更新の責任 c) CMDB ,既知の誤りのデータベース,サービスカタログ,その他の関連文書及び記録など,適切な情報源の使用 d) 問題管理プロセスとの関係/インタフェース e) きっかけ,機能又は階層の種類,及び発動権限を含めた段階的取扱いの規則 f) 変更要求を利用してインシデントの解決又はサービス要求の実現を行うときの,変更管理プロセスとのインタフェース g) インシデントの解決又はサービス要求の実現の検証に対する責任 h) インシデント又はサービス要求の終了に関する方針及び取組み。例えば,このプロセスは利用者又は顧客に復旧が有効かどうかの確認を求めてから,記録を更新し,最終的に記録を終了状態に設定することが望ましい。

 サービス提供者は,復旧が有効であったことの確認を利用者又は顧客から得ない場合,インシデントを解決した,又はサービス要求を実現したという不正確な想定を行ってしまうことがある。

8.1.4 重大なインシデントのための手順  インシデント及びサービス要求管理プロセスは,重大なインシデントを専用に取り扱うための文書化された手順を含むことが望ましい。重大なインシデントは,一般に影響が大きく,その解決には特別な注意が必要となる。  重大なインシデントのための手順は,次の事項を定義することが望ましい。 a) 何が重大なインシデントに当たるか。 b) 誰が重大なインシデントであると宣言する権限をもち,どのようにして宣言するか。 c) 誰が活動の調整及び管理を行うことが望ましく,誰が関与することが望ましいか。 d) どのようにして解決作業を実施するか。 e) 重大なインシデントの進行中及び終了後にどのような連絡を行うことが望ましいか。 f) 重大なインシデントの解決後のレビューに必要となる様式,タイミング及び参加者。 g) サービス継続の発動が必要となる場合,サービス継続及び可用性管理プロセスとのインタフェース。

8.1.5 文書及び記録  インシデント及びサービス要求管理プロセスで作成し,保持することが望ましい文書及び記録には,次の事項を含めることが望ましい。 a) インシデント及びサービス要求管理の手順 b) インシデントの記録 c) サービス要求の記録 d) 重大なインシデントの記録で,重大なインシデントのレビュー及び行動計画を含む。 e) 所定の期間にわたるインシデント及びサービス要求に関する報告書 f) インシデントの解決及びサービス要求の実現のパフォーマンス報告で,サービス目標を超えた,又は満たさなかった事例を含む。 g) 呼出しの種類,呼出し終了の種類,呼出しの分類,及び数量の内訳に関する統計報告書 h) 品質要因が,誤分類,優先度の調整,段階的取扱い,再開されたインシデント,データの不正確なサービス要求記録などの分類を含む場合,取扱いを誤ったインシデント及びサービス要求の例外報告書 i) 問題を調査するために問題管理プロセスに引き渡されるインシデント j) 特定された潜在的な改善又は処置がとられた箇所

8.1.6 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,インシデント及びサービス要求管理プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) 重大なインシデント管理プロセスの発動,対応チームの動員,及び各々の重大なインシデントに必要となる役割及び要員の特定に責任をもつ,重大なインシデントのマネージャ。 b) 初期症状のデータの収集及び利用者との継続的コミュニケーションのための,コミュニケーションの役割を果たす一次サポート。 c) 二次サポート及び三次サポートとして指名される解決グループ。これらのグループに割り当てられるのは,診断及び解決のために段階的取扱いがされたインシデントであり,通常,このグループは,一次サポート要員を超える専門的技能及び経験をもつ。 d) 各サービス要求の完了を補佐するために作業が割り当てられるサービス提供グループ。 e) 基盤となる契約(underpinning contract)及び合意書に定義される支援サービスを提供できる外部供給者及びベンダ。

8.2 問題管理

8.2.1 要求事項の意図  問題管理プロセスは,インシデントの未知の根本原因を特定し,変更管理プロセスを通じて恒久的な解決策を提案する。また,問題管理プロセスは,傾向分析及び予防処置の推奨を通じてインシデントの発生を事前予防的に防止する。

8.2.2 概念  問題管理プロセスは,インシデントの根本原因を調査することが望ましい。次に,問題管理プロセスは,変更管理プロセスを通じて恒久的な解決策を提案して,インシデント及び問題の影響を最小化する又は回避することが望ましい。  さらに,問題管理プロセスは,内在する根本原因が特定された場合,暫定策を含む既知の誤りの記録を作成し,管理することが望ましい。既知の誤りの記録は,効率的なインシデントの解決及び組織的な学習を確実にするために用いることができる。  問題管理プロセスは,定義された適用範囲をもつことが望ましく,採用する問題管理方法を決定することが望ましい。問題の優先度付け及び調査の両方の基準を定めることができる問題管理方針があると役に立つ。  問題管理プロセスの主たる視点は,多くの組織で,既に発生したインシデントに基づいている。影響が極めて大きく,リスクが極めて大きい問題の恒久的な解決策を見つけることは,組織にとって効用が大きく,また,このことによって,サービスを,より信頼性が高く,費用対効果が大きく,かつ,効率的なものにできる。  これらの問題管理活動の結果として,環境の信頼性が向上すると,要員は,事前予防的な問題管理により多くの時間を割くことができるようになる。事前予防的な問題管理活動は,最初からインシデントの予防を目指すことが望ましい。例えば,事業上重要なサービスの潜在的な単一障害点を特定し,顧客に影響を及ぼす将来のインシデントを予防するための冗長性を提案することである。

8.2.3 要求事項の説明  問題管理プロセスは,次の手順を含むことが望ましい。 a) 問題の特定は,次の事項を含む。  1) 一つ以上のインシデントの未知の根本原因の検知  2) 根本的な問題を明らかにする一つ以上のインシデントの分析  3) 供給者又は内部グループからのサービスコンポーネントに関する問題の通知 b) 各問題の記録を確実にするための問題の記録。記録は,日時など関連する問題の詳細,及び問題の記録の発端となったインシデントの相互参照を含むことが望ましい。 c) 問題の分類及び優先度付けは,次の事項を確実にすることが望ましい。  1) インシデント及びサービス要求管理プロセスで使用しているものと同一の分類基準を利用して,問題の性質を判別し,有意義な情報を提供する目的で各問題を分類する。  2) 各問題に,関連インシデントの緊急度及び影響に従って解決の優先度を与える。  3) 問題を調査し,解決のための最善の選択肢を特定するための時間及び資源を,問題の優先度に応じて割り当てる。  4) 問題の優先度及びサービスの要求事項を満たすために変更を加える効用に応じて,問題の解決に時間及び資源を割り当てる。 d) 問題の調査及び診断は,次の事項を確実にすることが望ましい。  1) 根本原因の診断を行うために,各問題を調査する。  2) 解決方法を特定できるようにするが,解決方法は,関連するインシデント及び潜在的インシデントの影響,暫定策の有無並びに見積もった解決費用に依存する。  3) 問題を解決するという決定は,関連するインシデントの影響,暫定策の有無及び解決費用に依存する。  4) 問題を解決しないという決定は,問題管理方針に従って管理する。  5) 問題管理プロセスは,既知の誤りが発見される前でも,暫定策を特定することによって,インシデント及びサービス要求管理プロセスを支援することができる。  6) 問題の診断は,根本原因が特定され,問題の解決方法が特定された時点で完了する。 e) (この細別は,対応国際規格で欠落) f) 問題の追跡は,次の目的で,全ての問題の進捗状況を記録することを確実にすることが望ましい。  1) 問題の進捗に現在責任をもつ人の詳細を含めて,問題管理プロセスを通じて進捗状況を追跡する。  2) 使用する全ての資源及びとった処置を記録する。 g) 問題の段階的取扱いは,次の事項を含めて,全ての課題について該当する当事者への段階的取扱いがされることを確実にすることが望ましい。  1) サービス目標に違反する,関連するインシデントを特定する。  2) 未解決の問題による影響を最小限にするための適切な処置をとることができるように,顧客に情報を転送する。  3) サービスデスク又は一次サポートが,影響を受ける利用者又は顧客に定期的な更新を提供できるようにする。  4) 段階的取扱い先を定義する。 h) 既知の誤りの文書化は,次の事項を確実にすることが望ましい。  1) 根本原因及び問題の解決方法案が特定されたとき,既知の誤りが,暫定策とともに既知の誤りのデータベースに記録される。  2) 恒久的な解決策が変更管理プロセスを通じて実施されるまで,既知の誤りの記録は完了しない。  3) 既知の誤りの記録が関係する全要員に利用可能にされ,新規の誤り記録又は更新された既知の誤りの記録は全員に定期的に周知される。  4) 定められた期間,既知の誤りの記録が終了しないままになっている場合,無効となった情報が既知の誤りのデータベースに置かれることがないように,既知の誤りの記録のレビューが行われ,既知の誤りの記録が最新に保たれる。  5) 全ての既知の誤りが,現行のサービス,影響を受ける可能性のあるサービス及び故障が疑われる構成品目に照らして記録される。 i) 問題の記録の終了は,既知の誤りが特定され記録されたとき,次の事項を確実にすることが望ましい。  1) 解決策の詳細が正確に記録される。  2) 問題の記録が,分析しやすいように関連するインシデントに対応させてある。  3) 分析しやすいように,根本原因が分類されている。 j) 未解決の,異常な,又は影響の大きい問題を調査するために行われる重大な問題のレビューは,次の事項を確実にすることが望ましい。 1) 事業,顧客又はサービス提供者へのリスクを特定し,管理する。 2) 経営者にとって,未解決の問題の理由,及び未解決の問題の事業への継続的な影響に関する可視性がある。 k) 問題のレビューは記録することが望ましく,適切なサービス改善の推奨事項を含むことが望ましい。レビューは,次の事項を調べることが望ましい。  1) 問題管理プロセスの改善の機会  2) その他のプロセス,サービス又は SMS の改善の機会  3) 再発又は特定の種類の問題の予防方法  4) 人的な誤りが原因であるインシデントの修正又は予防のために,教育・訓練又は認識を提供することが望ましいかどうか。  5) 供給者,顧客又は内部グループの側に,発生した問題の責任があるかどうか,また,フォローアップ処置が必要かどうか。 l) 事前予防的問題管理は,次の事項を確実にすることが望ましい。  1) 傾向を特定するために,インシデント及び問題のデータ,CMDB 並びに他の関連情報源について分析が行われる。  2) 意思決定の改善及び起こり得るサービス低下の回避に,インシデント及び問題のデータ,CMDB 並びに他の関連情報源を使用することができる。  3) 問題のレビューで得られた知識は,顧客が,とった処置及び特定されたサービス改善の推奨事項を認識することを確実にするために,顧客に周知させる。  4) 事前予防的問題管理の事業価値を実証する,主要な測定を定義する。  5) 潜在的な単一障害点,新たに出現する傾向及びサービスに対するリスクが特定され,変更管理プロセスを通じて選択肢が提案される。

8.2.4 文書及び記録  問題管理プロセスで作成し,保持することが望ましい文書及び記録には,次の事項を含めることが望ましい。 a) 問題管理の手順 b) 問題の記録 c) 既知の誤りの記録 d) 暫定策の詳細 e) 恒久策につながる変更との関連 f) 問題レビュー会議の議事録を含めた問題レビューの記録 g) インシデント及び問題の傾向情報を含む管理報告書 h) サービス改善の推奨事項

 問題管理方針は,問題管理プロセスの促進及び支援に役立てることができる。

8.2.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,問題管理プロセスで必要となる権限及び責任には,次の要員を含めることが望ましい。 a) 問題の根本原因の分析を行い,解決策及び/又は暫定策を決め,ひも(紐)付けされた既知の誤りのデータの記録を作成する要員 b) 解決策,暫定策,既知の誤りの情報,助言及びレビューに関与する供給者,顧客又は内部グループ

9 統合的制御プロセス

9.1 構成管理

9.1.1 要求事項の意図  構成管理プロセスは,構成品目の特定,管理,記録,追跡,報告及び検証,並びに CMDB での CI 情報の管理を含むことが望ましい。このプロセスは,サービスのライフサイクル全体で,特定されたサービス,サービスコンポーネント及び CI に関する情報の完全性を確立し,維持することが望ましい。また,構成管理プロセスは,CI 間の関係,及び CI とそれが支援するサービスとの関係に関する情報の特定,管理及び検証を行うことが望ましい。  構成管理プロセスの適用範囲からは,財務資産管理を除外することが望ましいが,財務資産管理プロセスとのインタフェースは含めることが望ましい。

9.1.2 概念  構成管理プロセスは,進化するサービス資産及び構成,並びにその関係の管理及び制御の中心となることが望ましい。このプロセスは,構成管理プロセスを計画し,実施する活動を含むことが望ましい。  構成管理は,各 CI の種類の定義を文書化し,各 CI を構成管理の方針及び手順に従って特定することが望ましい。CI 別に記録される情報は,各 CI 及び関連する構成情報の効果的な制御を確実にすることが望ましい。  構成情報は,構成品目,版,関係,ベースライン及びリリースに関するデータを収録する CMDB に記録される。各 CI の情報は,識別子,説明,状態,場所,CI 間の関係,並びに変更要求,インシデント,問題及び既知の誤りの記録などの関連記録を含むことが望ましい。構成情報は,許可された担当者が維持し,許可された利害関係者だけに利用可能にすることが望ましい。

9.1.3 要求事項の説明 9.1.3.1 構成管理活動  構成管理プロセスの計画立案は,サービス提供者が,次の事項を行う上で十分な程度の制御を達成できるようにすることが望ましい。 a) 顧客,利用者,サービス提供者及び他の利害関係者の合意した要求事項を満たす。 b) ライセンスを含めて,サービス提供に使用する資産を,法令・規制要求事項及び契約上の義務に従って管理することを確実にする。 c) サービス及びサービスコンポーネントに関する情報の完全性を維持することを確実にする。 d) その信頼性及び正確さを確実にするために,記録された構成情報を維持する。

9.1.3.2 資源及び力量  構成管理プロセスは,進化する CI の記録の実施及び維持のための十分な資源及び能力があることを確実にするために計画立案することが望ましい。構成管理プロセス及び方針の適用範囲には,次の事項を含めることが望ましい。 a) SMS 及び変更管理プロセスの適用範囲に整合した構成管理プロセスの適用範囲の計画立案 b) CI の種類ごとの定義,並びに他の CI 及びサービスコンポーネントとの関係 c) CI にアクセスし,その変更を制御する権限 d) CI の版及び状態を特定し,記録し,追跡するための文書化された手順 e) 指定された完全性,セキュリティ及び安全性に従った物理的 CI の保管場所及び保管条件,並びに情報の場合は記憶媒体 f) 構成制御を開始し,進化する構成のベースラインを維持するための基準又は事象 g) 監査の計画立案及び実施,結果の報告並びに監査記録の維持に関する権限及び責任を含む文書化された手順 h) 法令・規制要求事項及び契約上の義務に従った,CI に関するデータの削除,保管,処分又は移管の計画立案 i) 人的な誤りの機会を減らすなど,効果的な制御を確実にするための十分な自動化

9.1.3.3 CI の識別及び定義  計画は,構成管理プロセスの制御の対象となる CI の種類の識別及び定義を含むことが望ましい。CI は,そのライフサイクル全体で管理でき,トレーサビリティが得られるように,設定した選択基準に従って選択し,グループ分けし,分類し,識別することが望ましい。  各サービスは,次のことを可能にするために,構成要素であるサービスコンポーネントの,論理的に関連する下位のグループに分類又は分別することが望ましい。 a) 使用を許可されている構成情報を見つけ,使用することができる利害関係者 b) CI 及びその関係に関する情報の管理方法についての,利害関係者間での理解の共有 c) 役割を果たすために必要となるか又は役立つ CMDB,構成管理方針及び手順にアクセスすることができる,サービスマネジメントの全てのプロセスに関与する要員 d) 正しい権限レベルをもつ要員だけに CMDB への編集アクセスを与え,それ以外の要員には読取りアクセスを提供するサービス提供者

 CI は,一意の,恒久的な識別子,又は該当する場合,マーキングで明確に識別することが望ましい。識別子は,構成管理プロセスで制御される全ての CI が,その仕様又はそれと同等の記述文書までの明瞭なトレーサビリティが得られるように,該当する標準及び規約に従うことが望ましい。CI 及び各 CI のために記録すべき情報の定義のリストがあることが望ましい。CI 間の適切な関係及び依存関係は,必要な程度の可視性及び制御が得られるように特定することが望ましい。

9.1.3.4 CI の種類  CI の種類には,次の事項を含めることが望ましい。 a) サービスカタログに記載されるサービス及びその関連情報,並びに文書(SLA,合意書,契約,サービスの要求事項,サービス設計の仕様など) b) ハードウェア,ソフトウェア及びライセンス,ツール,アプリケーション,文書,支援サービスなどを含むサービスコンポーネント c) サービス,システム,ソフトウェア構成ベースライン又は構築記述書の全ての版及びリリース。その構築記述書は,各々の構築文を適用可能な環境,及びハードウェア構成図のような標準的なハードウェア構築に対するものである。 d) 物理的及び/又は電子的な格納庫に保管される CI の原本,CMDB 及び使用ツール e) 情報セキュリティ資産 f) セキュリティが保たれた磁気媒体,機器など,財務資産管理又は事業上の理由で追跡する必要のある資産 g) 方針,プロセス文書,手順,計画などの SMS 文書

 各 CI の種類は,CMDB 又は統合された文書若しくは記録に関連情報をもつことが望ましい。

9.1.3.5 CI の維持  構成管理の実施は,完全性及びセキュリティの適切なレベルを伴う,CI 及び CI 相互の関係に関する情報を維持する活動を含めることが望ましい。  構成制御手順は,合意した識別可能な CI の種類及び情報だけを受け入れ,適切でセキュリティが保たれた環境に保存することを確実にすることが望ましい。CI は,承認された変更要求など,適切な管理文書がない場合は,追加,修正,交換又は撤去/回収を行わないほうがよい。ライフサイクル全体で進化する CI の状態は,指定の時間又は定められた状況をきっかけとするベースラインとして文書化することが望ましい。ベースラインの根拠は,記録することが望ましい。構成記録は,CI のライフサイクル全体で維持し,構成管理方針に従って保管又は撤去することが望ましい。  システム,サービス及びインフラストラクチャの完全性を保護するために,CI の記録及び CMDB は,適切でセキュリティが保たれた環境に保存することが望ましい。この環境は,承認されていないアクセス,変更又は CMDB の破壊からその記録を保護することが望ましい。また,CMDB の災害復旧手段,ソフトウェア,電子媒体など,マスターコピーの制御された検索を可能にする方法があることが望ましい。  構成監査活動は,あらかじめ定めた間隔で,かつ,特定の事象に対応して実施することが望ましい。次の目的で,適切な手順及び資源を用意しておくことが望ましい。 a) プロセスの適用範囲内で,サービス提供者が全ての CI 及び CI 間の関係に関する情報を制御していることを検証する。 b) サービス提供者が,ソフトウェアライセンスの場所及び数量に関する情報を制御していることを検証する。 c) 構成情報が正確で,制御され,承認された要員が閲覧できるという信頼性を与える。 d) 実際の構成情報と予想される構成情報との不一致の原因を特定し,変更管理プロセスと連携して問題を解決する。 e) 定期的に,少なくとも稼働環境へのリリースの展開に先立って,構成ベースラインがとられることを確実にする。 f) CMDB の情報の機密性及びアクセス性を確実にする。

9.1.4 文書及び記録  構成管理プロセスで作成し,保持することが望ましい文書及び記録には,次の事項を含めることが望ましい。 a) 構成管理方針 b) 構成管理プロセスの手順 c) CI ,並びにその CI と他の CI,サービスコンポーネント及びサービスとの関係に関する最新で正確な情報 d) CI の種類の定義 e) 構成ベースライン f) 構成管理報告書 g) 構成監査報告書 h) CMDB のバックアップの頻度及び試験について規定する,文書化された手順

9.1.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,構成管理プロセスで必要となる権限及び責任には,次の要員を含めることが望ましい。 a) 構成情報に認可されたアクセス権をもつ顧客,利用者,サービス提供者の要員及び利害関係者 b) CMDB を維持する要員 c) CI の状態に関する更新が行われることを確実にする責任をもつ,資産又は CI の所有者 d) 資産及び CI の内部及び外部供給者

9.2 変更管理

9.2.1 要求事項の意図  変更管理プロセスは,全ての変更を制御された方法でアセスメントし,承認し,実施し,レビューすることを確実にし,そのライフサイクルを通じて変更を管理することが望ましい。

9.2.2 概念  変更管理プロセスは,リスクを最小限にする変更を効果的に実施するための構造化された取組み,及び理想的には,管理されていない変更又は管理が不十分な変更に起因するインシデントの予防をもたらす。  要求される可視性及び制御が得られるように,全ての変更要求は記録し,分類することが望ましい。開発が承認された変更の詳細及びその実施の期日案を含む変更スケジュールを策定し,利害関係者に通知し,必要に応じて更新することが望ましい。  変更要求の種類の一般的な例を,次に示す。 a) 緊急変更。これは早急に実施することが望ましい変更で,例えば,重大なインシデントの解決又は情報セキュリティパッチの実施を目的としたもの。 b) 通常変更。計画どおりのサービス変更で,標準変更でも緊急変更でもないもの。 c) 標準変更。リスクが低く,比較的よくあり,手順又は作業指示書に従う事前認可済の変更。

 通常変更は,関連する費用及びリスクに応じて,重大,重要及び軽微に分類することができる。この分類は,適切な変更権限,すなわち,その変更の分類に対する権限をもつ人に関連させ,その人を特定するために用いることができる。  全ての変更の記録,分類,アセスメント,承認,計画立案,開発,試験及び展開を制御するための手順を文書化し,利用することが望ましい。  変更の実施の成功後に,変更管理プロセスは,変更された環境を反映するために CMDB が更新されることが望ましいことを,構成管理プロセスに通知することが望ましい。

9.2.3 要求事項の説明 9.2.3.1 変更管理方針  変更管理プロセスが制御している CI を定義する,変更管理方針を確立し,文書化することが望ましい。変更管理プロセスの適用範囲内にある変更管理方針で定義された,CI に対する全ての変更要求は,このプロセスによって管理することが望ましい。  サービス又は顧客に大きな影響を及ぼす可能性がある変更は,変更管理方針で定義された基準に従って分類することが望ましい。これらの変更は,新規サービス又はサービス変更の設計及び移行プロセスを用いて管理し,変更管理プロセスと連携することが望ましい。  変更管理方針は,どの変更を変更管理プロセスで管理することが望ましいか,並びにどの変更を新規サービス又はサービス変更の設計及び移行プロセスで管理することが望ましいかを決める基準を定義することが望ましい。  新規サービス又はサービス変更の設計及び移行プロセスを通じて管理される変更を判断するときに使用する基準は,サービスの廃止のための変更と,サービス提供者からサービスを他の関係者に移管するための変更とを含むことが望ましい。他の関係者は,顧客又は供給者のこともある。

9.2.3.2 計画立案及び実施  変更要求は,文書化された適用範囲をもつことが望ましく,定義され,合意した基準に従って分類することが望ましい。変更要求は,リスク,サービス及び顧客への影響,財務への波及,事業利益,並びに技術的な実現可能性を考慮して,開発又は構築の前にアセスメントを行い,承認を受けることが望ましい。  変更の構築,試験及び実施の管理は,構成管理プロセス並びにリリース及び展開管理プロセスと連携することが望ましい。  失敗した変更を元に戻すか,修正するために必要な活動を計画し,試験することが望ましい。失敗した場合には,その変更を元に戻すか,修正することが望ましい。失敗した変更は調査し,適切な処置をとることが望ましい。  開発が承認された変更の詳細,及びその実施の期日案を含む変更スケジュールを策定し,例えば,一次サポート,BRM,供給者管理などの利害関係者に通知することが望ましい。  変更管理プロセス及び手順は,次の事項を確実にすることが望ましい。 a) 変更は,影響を受ける構成品目を特定するような,明確に定義され,文書化された適用範囲をもつ。 b) 変更要求の受付け及び承認に関する決定のときに,リスク,優先度,サービス又は顧客への潜在的影響,サービスの要求事項,事業利益,技術的な実現可能性及び財務への影響を考慮する。 c) 承認される変更の詳細及びその展開の期日案を含む,変更スケジュールを策定する。 d) 変更スケジュールを利害関係者に伝える。 e) 変更スケジュールを,リリース展開の計画立案に使用する。 f) 特定されたサービス及び構成品目に対する,承認された変更を開発し,変更スケジュールに従って試験を行う。 g) 変更スケジュールに従って,変更を展開する。 h) 失敗した変更を元に戻す,又は修正するための活動を計画し,試験する。 i) 失敗した変更を元に戻すか,修正し,失敗した変更の理由を文書化し,調査する。 j) 変更の成否にかかわらず,展開後に CMDB を更新する。

9.2.3.3 変更要求のレビュー  変更量の増加,頻繁に再発する種類,新しい傾向及びその他の関連情報を特定するために,変更要求の記録は,あらかじめ定めた間隔で分析することが望ましい。変更の分析から引き出された結果及び結論は記録し,改善の機会の特定に利用することが望ましい。不適合は記録し,処置をとることが望ましい。  個々の変更要求に関してレビューを行った結果,変更管理プロセスにおいて特定された弱点又は欠陥は,改善計画に盛り込むことが望ましい。  変更が展開され,受け入れられた場合は,変更要求を終了することが望ましい。変更を実施しないという決定が下されたときも,変更を終了することができる。変更要求が終了したときは,変更の結果を変更要求の起案者及びその他の利害関係者に報告することが望ましい。

9.2.3.4 緊急変更  緊急変更は,リスクの増加,並びに緊急変更の承認及び実施の費用の増加のために,他の変更と区別することが望ましい。  緊急変更については,承認並びに実施後の文書及びレビューに関する取決めを含む,定義されたプロセスがあることが望ましい。緊急変更は,適切な変更権限をもつ者が承認することが望ましく,可能な場合には,利害関係者に通知することが望ましい。  緊急変更は,通常変更プロセスの手順,予定及び承認権限を順守する十分な時間がない緊急事態を解決するために利用してもよい。可能な場合には,完全な変更プロセスに従うことが望ましい。ただし,緊急変更の実施はその緊急性のために,詳細の一部は後で記録することもあり,試験ができないこともある。事態の緊急性に対応するために,これらの段階の一部を省略した場合でも,失敗した場合に緊急変更を元に戻すか,それを修正するための計画があることが望ましい。緊急手順に従ったために,実施前の試験が不完全なものになるなど,他の変更管理の要求事項を省略することになった場合は,できる限り早急に,変更がこれらの要求事項に適合するようにすることが望ましい。緊急変更は,実施者が実施理由を説明し,変更後にレビューを行って,本当に緊急事態であったことを検証することが望ましい。

9.2.4 文書及び記録  このプロセスで作成し,保持することが望ましい記録を含めた文書は次のとおりである。 a) 変更管理方針 b) 緊急変更手順及び標準変更手順を含む,変更管理プロセスの文書及び手順 c) 承認された標準変更のリスト d) 変更スケジュール e) 変更要求の記録,及び例えばリスクアセスメント,修正計画,展開計画などの関連情報の記録 f) 変更管理プロセスの有効性及び効率性に関する報告書 g) 実施後のレビューを含む変更管理に関する報告書

 各変更要求にひも(紐)付けされた変更記録は,適切な変更ログに記録することが望ましい。組織に CMDB がある場合には,変更記録を,CI の記録との関連によって該当する CI にひも(紐)付けることが望ましい。理想的には,この変更記録と該当する単数又は複数の CI との関連は,変更要求が記録された時点から,承認及び実施まで可視化することが望ましい。

9.2.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実施する要員に加えて,変更管理プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) 変更要求を記録し,分類することができる役割及び個人。 b) サービスオーナ,プロセスオーナなど,各変更要求のライフサイクルの管理に責任をもつオーナ。 c) 変更の影響について助言を与える,指名された代表。これは,サービス及び事業環境に及ぶ変更の範囲及び影響に応じて,一般にサービス提供者,顧客及び利害関係者の代表を含む変更諮問委員会でよい。 d) 変更の受入れ及び承認に関する決定を下す変更権限。変更権限の保有者は,変更の種類に適切であることが望ましく,指名される役割でも,個人又は変更諮問委員会でも,緊急変更諮問委員会でもよい。

9.3 リリース及び展開管理

9.3.1 要求事項の意図  リリース及び展開管理プロセスは,ハードウェア,ソフトウェア及びサービスコンポーネントの完全性が維持されるように,全てのリリースを稼働環境に効果的に展開することを確実にすることが望ましい。リリース及び展開管理プロセスは,リリースの全側面を調整することが望ましい。これは,技術的機能性,環境との統合,リリースの開発,試験及び展開を行うための資源の割当て,教育・訓練,支援,リリース文書などを含むことが望ましい。リリースが成功することを確実にするために,全側面を併せて検討することが望ましい。  稼働環境の完全性を保護することが望ましく,適切な計画立案,試験及び変更管理プロセスとの連携を通じて,中断を最小限にすることが望ましい。

9.3.2 概念  リリース及び展開管理プロセスは,重大又は複雑なリリースと軽微なリリースとの両方の調整に責任をもつ。したがって,リリース及び展開管理プロセスは,それぞれ適用範囲,複雑さ及びリスクの程度が異なるリリースの効果的な管理及び連携が可能であるように設計することが望ましい。  リリースは,一つのサービスに対して構築,試験及び展開が併せて行われる,一つ以上の変更になることがある。複数の変更は,依存関係の管理及び効率性のため,一つ以上のリリースとして一体化させてもよい。リリースの集合は,一つのリリースとして併せて展開される CI の集まりを含むことが望ましい。  リリース及び展開管理プロセスは,各リリース内の変更が両立することを確実にすることが望ましい。  展開は,対象の環境における正しい場所及び時間での,サービス及びサービスコンポーネントの配付及び提供に責任をもつことが望ましい。  サービス提供者は,リリース及び展開活動について,顧客,利用者及び利害関係者と調整することが望ましい。多くの場合,リリースは,関連する意識向上,コミュニケーション及び教育・訓練のプログラムに整合させるために,事業変更プロジェクト及び事業変更管理と調整することを確実にすることが望ましい。  リリース及び展開管理プロセスは,新規サービス又はサービス変更の設計及び移行プロセスと変更管理プロセスとの両方に連携させて,新規サービス又はサービス変更のための個々のリリースを計画し,管理することが望ましい。  可能な場合には,リリースは,CI の完全性を確実なものとする,標準化された方法又は一貫した方法を用いることが望ましい。リリースは,標準的方法を採用し,実現可能な場合には自動化を利用して規模の効率を追求することによって,より費用対効果の高い達成ができる。

9.3.3 要求事項の説明 9.3.3.1 リリース方針  サービス提供者は,リリースの種類ごとのリリース頻度及び取組みの指定を補佐するために,顧客及び利害関係者とともにリリース方針を策定し,それに合意することが望ましい。リリース方針には,一般に,次の事項を含めることができる。 a) 緊急,重大,重要,軽微など,リリースの種類ごとの定義 b) リリースの種類ごとの頻度 c) 全てのリリース及び展開管理プロセス活動のための,主要な役割及び責任の定義 d) リリースの受入れ及び展開の承認に関する権限レベル e) リリースの検証及び受入れに関する規則 f) リリースの識別方式 g) リリースの版の決定規則 h) リリースの構築及び一体化 i) 該当する場合,自動展開の方法及びツールを含む,リリースの種類ごとのリリース及び展開への取組み j) 事前に定めた一貫した試験への取組み

9.3.3.2 リリース及び展開の計画立案  リリース及び展開管理プロセスは,新規サービス又はサービス変更の稼働環境へのリリース及び展開を,顧客及び利害関係者とともに計画することが望ましい。リリース及び展開の計画立案の支援には,プロジェクト管理の方法及び技法を用いることが望ましい。リリース及び展開計画に関する最低限の情報は,サービス提供者が定義することが望ましく,リリースの種類に従って異なるものであってもよい。  リリース及び展開計画は,常に,全ての変更が変更管理プロセスと連携することを確実にすることが望ましい。リリース及び展開計画は,リリースの影響,関連するリスクのアセスメント,及び受容できないリスクを最小限にするための軽減措置の特定を含むことが望ましい。  リリース及びその展開を計画立案するときに検討することが望ましい一般的な要因には,事業の規模,リリースの展開に必要な技術的変更及びその他の変更がある。例えば,新技能,新規又は変更されたプロセス,及び新規ツールがある。その他の要因には,依存関係,並びにリリースの構築,試験及び展開に必要な時間及び資源が含まれる。  リリース及び展開計画は,次のコンポーネントを含むことが望ましい。 a) 成果物を含むリリースの適用範囲及び内容 b) ライセンスを含む,移管,停止又は廃棄するサービス及びサービスコンポーネント c) 指名された各サイトの顧客と協議して決める,日付を含めた,リリースの集合化及び展開の予定 d) リリースの計画立案,調整,構築,試験,展開及びレビューに関する役割及び責任 e) 展開中のソフトウェア,ハードウェア及び他のサービスコンポーネントの完全性を確実にする,リリース及び展開の手順及び方法 f) 顧客組織内の利用者,サービス提供者の要員,及び関連する供給者に必要な情報を提供するコミュニケーション活動の計画 g) リリース中に発見される課題を特定し,追跡し,管理するための取組み h) 受入基準,試験方法,手続及び結果の記録用紙などの項目を含む試験計画 i) 該当する場合,パイロット,試行及び/又は展開の前にリリースが十分に試験されることを確実にするための,制御された試験環境を管理するための取組み j) 資産管理,構成管理,安全衛生,環境,情報セキュリティ管理など,該当する方針及び手順に従って資産及び CI を管理するための取組み k) リリース及び展開を検証するときの基準,並びにリリースが失敗したとき,それを元に戻すか,修正するために用いる適切な基準及び承認された取組み l) 次の事項に関して,計画に定義される要求事項又はその参照箇所  1) 内部又は外部資源の使用に関係なく,リリース及び展開の作業指示書  2) リリースの実行に必要なツールで,ソフトウェアの遠隔導入又は無人導入用のツール及び手法の使用を含む。  3) 変更管理プロセスを通じてリリースが承認される標準変更の実施  4) リリースに影響されるサービス,サービスコンポーネント及び CI の構成の詳細の更新

9.3.3.3 リリース及び展開の実践  各リリースは,CI の集まりを含むことが望ましい。リリース及び展開管理プロセスは,次の事項に従って CI が正しく定義されることを確実にするために,構成管理プロセスと緊密に連携することが望ましい。 a) 合意された CI の種類,例えば,構成管理方針 b) 他の CI との関係 c) 命名規則及び版の決定規則 d) 技術的なハードウェア及び環境の構築 e) ソフトウェアイメージ  注記 複数のソフトウェア,データファイルなどをひとまとめにして展開可能な形に記録したもの f) 作業指示書

 これによって,展開中に,サービス及びサービスコンポーネントに関する情報の完全性を確実にすることが望ましい。  リリースの内容は,展開のためのリリースの適切性を確実にするものであることが望ましい。リリースの内容は,リリースのコンポーネントとして調達され,組み立てられる資産及び CI を定義するものであることが望ましい。これは,調達及びその後のソフトウェアライブラリへの保管が必要となる,ソフトウェアライセンスの原本を含むことがある。また,特定されたハードウェアの保管庫に保持しておくことが望ましいハードウェア品目の調達を含むこともある。  試験,パイロット及び試行を通じて検証されている,一貫した作業の実践及び定義された手順を採用することが望ましい。このような作業の実践及び手順の例には,リリースの構築,試験,リリースの配付,リリースの導入,検証,及び必要に応じてリリースの復元又は修正が含まれる。  リリース及び展開管理プロセスは,緊急変更管理手順とのインタフェースと連携して,緊急リリースに採用される方法及び実践を定義することが望ましい。

9.3.3.4 リリースの試験  試験活動は,次の事項を含むことが望ましい。 a) 試験計画の作成 b) テストルーチンの作成及びリリースのための試験環境の準備 c) 試験環境で実施する試験活動 d) 利用者受入試験 e) 版(version),課題並びにその課題が発見された時刻及び日付を含む,試験結果の記録 f) 試験報告書の作成 g) 受入基準を満たし目的にかな(適)っている場合の,リリースの承認

9.3.3.5 展開活動及び手順  展開活動及び手順には,次の事項を含めることが望ましい。 a) 正しい場所及び時間での,サービス及びサービスコンポーネントを支援する CI の配付及び提供 b) 変換された,又は新規のデータ及び情報を含む CI の構築,導入及び構成 c) サービス及びサービスコンポーネントが受入試験に従って試験されていることの検証,並びに導入及び試験の報告書の作成 d) 新規リリース及び切替中に削除される CI 又はサービスの記録の更新 e) インシデント,問題,既知の誤り,予想外の事象又は計画から逸脱の記録 f) 展開時の是正処置の実施 g) 失敗したリリースを修正するための,復元又は修正処置の実施

9.3.4 文書及び記録  リリース及び展開管理プロセスで作成し,保持することが望ましい文書及び記録には,次の事項が含まれる。 a) リリース方針 b) リリース計画 c) 変更管理プロセスで承認する,関連する変更を含む各リリースの内容 d) 新規コンポーネント,リリース及び展開活動の結果改変したコンポーネント,展開時に復元した又は無効にした廃棄コンポーネントなどを含む各リリースの内容 e) リリース設計,リリース通知及びリリースの導入の手引 f) プロジェクト計画などの形をとる展開計画 g) 会計年度末などの時期に顧客へのリスクが増大するために,リリースのスケジュールが組めない期間を示すリリース及び展開のスケジュール h) 利用者影響アセスメント及び事業変更影響アセスメント i) コミュニケーション計画 j) 利用者,サービス提供者の要員及び利害関係者の教育・訓練計画 k) リリース及び展開の試験計画及び試験結果 l) リリースの受入れ及び顧客による承認 m) フォローアップ処置のリスト又はインシデントのログを含む,成否の記録 n) リリースの失敗,復元,又は復元作業のための,インシデント,問題及び既知の誤りの記録 o) 各リリースの CI 情報  1) リリースの識別子及び版  2) リリースの記述  3) リリースとそれを構成する CI との関係  4) リリースの集合及び導入の場所  5) 関連する変更要求  6) 関連するインシデント,問題,及びリリースによって修正されるものを含めた既知の誤り

9.3.5 権限及び責任  4.4.2.1に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加えて,リリース及び展開管理プロセスで必要となる権限及び責任には,次の事項を含めることが望ましい。 a) 事業変更活動とともに,リリース及び展開の計画立案及び調整に責任をもつ顧客又は顧客の代表 b) 新規サービス若しくはサービス変更,又はサービスコンポーネントの運用,及び該当する場合,利用者試験の実施に責任をもつ利用者 c) 新規サービス若しくはサービス変更,又はサービスコンポーネントの運用活動の試験に責任をもつサービス提供者の要員

  • Q 20000-2:2013 (ISO/IEC 20000-2:2012)

附属書 A

(参考) プロセス間のインタフェース及びプロセスと SMS との統合

 この附属書の全ての表に記載する例は,全てを網羅したものではない。

表 A.1−新規サービス又はサービス変更の設計及び移行とのインタフェース及び統合

 新規サービス又はサービス変更の設計及び移行と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  SLM プロセスは,新規サービス又はサービス変更のサービスレベルの要求事項を提供することが望ましい。  BRM プロセスは,新規サービス又はサービス変更に関する全ての顧客要求事項及び事業上の要求事項を特定し,文書化し,合意し,提示することを確実にするために,それらの要求事項を提示することが望ましい。  インシデント及びサービス要求管理プロセスは,稼働環境に移行後の,新規サービス又はサービス変更の実施の影響に関する詳細を提供することが望ましい。  リリース及び展開管理プロセスは,展開のタイミング及び方法に関する助言を提供することが望ましい。  サービスの予算業務及び会計業務プロセスは,サービス提供の変更に係る費用の見積報告書を受領することが望ましい。  変更管理プロセスは,新規サービス又はサービス変更の導入によって生じる変更要求を受領することが望ましい。  新規サービス又はサービス変更の設計及び移行と SMS の他のプロセスとの統合例には,次の事項が含まれる。  新規サービス又はサービス変更の設計及び移行は,新規サービス又はサービス変更に関する潜在的要求事項を特定するためのインプットとして,監査での不適合記録を受領することが望ましい。  新規サービス又はサービス変更の設計及び移行は,顧客満足度に対処するために,新規サービス又はサービス変更に関する潜在的要求事項を特定するためのインプットとして,顧客満足度の分析報告書を受領することが望ましい。

表 A.2−SLM とのインタフェース及び統合

 SLM と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  サービス継続及び可用性管理プロセスは,SLA へのインプットとして継続又は可用性の要求事項を提供し,中断又は非可用性による SLA 違反を低減することが望ましい。  容量・能力管理プロセスは,貧弱なパフォーマンスによる SLA 違反を低減するために,SLA へのインプットとしてパフォーマンスの要求事項を提供することが望ましい。  供給者管理プロセスは,供給者の契約目標が SLA に整合するように,供給者との契約の詳細を提供することが望ましい。  ISM プロセスは,SLA がセキュリティ方針に整合して策定されるように,情報セキュリティ方針を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,インシデントについての関連データを提供することが望ましい。  インシデント及びサービス要求管理プロセスは,インシデント及び要求が,優先度付けされ,対応及び解決のための合意した時間枠内に解決又は実現されるように,SLA を受領することが望ましい。  変更管理プロセスは,SLA の変更要求を受領し,計画した SLA との差分について詳述した,想定されるサービスの休止を特定することが望ましい。  SLM と SMS の他のプロセスとの統合例には,次の事項が含まれる。  SLM プロセスは,トップマネジメントと,顧客と,利用者と,サービスレベルマネージャとの間で合意したサービスの定義を維持することが望ましい。  SLM プロセスは,サービス提供に必要な,サービス提供者の技能及び資源を定義することが望ましい。  SLM プロセスは,二次サポート,三次サポートなどの,サービスに関する問題の解決者グループ及びサービス要求の実現を支える,サービスの供給者とやりとりすることが望ましい。

表 A.3−サービスの報告とのインタフェース及び統合

 サービスの報告と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  SLM プロセスは,サービスの報告に関する適切な方針及び規則を定義するために,SLA に対応する情報を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,全ての利害関係者が影響を理解し,合意した処置をとることができるよう,インシデントに関するデータをサービスの報告に提供することが望ましい。  サービス継続及び可用性管理プロセスは,サービス及びコンポーネントの可用性に関する情報を提供することが望ましい。  容量・能力管理プロセスは,事前に定義したしきい(閾)値を基準にすることを含めて,作業負荷の報告に関する情報を提供することが望ましい。  BRM プロセスは,最適なレベルのサービス提供及び顧客満足度の改善を可能にするために,正しいレベルの情報を受領することが望ましい。  サービスの報告と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  サービスの報告プロセスは,サービスに関する意思決定及び処置がとれるようにするために,サービスの質,費用及びリスクに関して利害関係者に報告書を提供することが望ましい。  サービスの報告プロセスは,SMS の管理及び改善に必要なコミュニケーション及び可視性が得られるようにするために,全てのサービスマネジメントのプロセスからデータを受領することが望ましい。

表 A.4−サービス継続及び可用性管理とのインタフェース及び統合

 サービス継続及び可用性管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  SLM プロセスは,次の事項を提供することが望ましい。  − SLA におけるサービス継続及び可用性の義務  − 災害のときに事業者にとって受入れ可能なサービスレベル  − 可用性の目標の決定に対する支援,並びにサービス及びコンポーネントの違反の調査及び解決容量・能力管理プロセスは,次の事項を提供することが望ましい。  − 可用性計画との整合を可能にするための容量・能力計画  − 災害後の復旧を可能にするための,回復力(resilience)及び予備の容量・能力を備えたデータ保管庫など,十分な資源が備わるようにしたモデル化の情報  ISM プロセスは,情報セキュリティインシデントがいつ災害とみなされるのかの定義を提供することが望ましい。  構成管理プロセスは,全てのサービス継続及び可用性管理プロセスの活動並びに計画及び復旧設備の維持を可能にするために,インフラストラクチャを形成するコンポーネントに関する情報を提供することが望ましい。  変更管理プロセスは,サービス継続及び可用性の計画への潜在的影響をもつ全ての変更に関する情報を提供することが望ましい。  SLM プロセスは,合意して SLA として文書化できるように,復旧の要求事項及び選択肢を受領することが望ましい。  インシデント及びサービス要求管理プロセス並びに問題管理プロセスは,サービス継続及び可用性の計画の発動に関して,明確に合意され文書化された基準を受領することが望ましい。  サービス継続及び可用性管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  サービス継続及び可用性管理プロセスは,サービス継続又は可用性に関する新規又は変更された要求事項を特定するために,顧客及び利害関係者から事業計画に関する情報を受領することが望ましい。  サービス継続及び可用性管理プロセスは,サービスマネジメントに関する決定が,可用性の欠如による事業への影響の明確な理解に基づくことを確実にするために,事業影響度分析をトップマネジメント及び全ての利害関係者に提供することが望ましい。

表 A.5−サービスの予算業務及び会計業務とのインタフェース及び統合

 サービス予算業務及び会計業務と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  新規サービス又はサービス変更の設計及び移行プロセスは,予算及び期間を含む新規サービス又はサービス変更の計画を提供することが望ましい。  SLM プロセスは,サービス提供者が提供するサービスに関する費用のモデルを構築するための基礎として,サービスカタログを提供することが望ましい。  容量・能力管理プロセスは,事業上の要求事項を満たすための選択肢について行った費用の見積りを含めて,容量・能力計画を提供することが望ましい。  供給者管理プロセスは,短期及び契約満了までの両方に係る,費用の変更の詳細を提供することが望ましい。  構成管理プロセスは,全ての構成品目の詳細を提供することが望ましい。  容量・能力管理プロセスは,サービス及びインフラストラクチャのアップグレード又は新規コンポーネントの購入用の予算を受領することが望ましい。  変更管理プロセスは,必要な場合には,財務に関する承認を受けることが望ましい。  サービスの予算業務及び会計業務と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  サービスの予算業務及び会計業務プロセスは,信頼できる費用の予想及び配賦を可能にするために,サービス提供者の財務管理組織から十分な情報を受領することが望ましい。  サービスの予算業務及び会計業務プロセスは,財務管理方針及び規制要求事項に整合することを可能にするために,組織に対するサービスの予算業務及び会計業務の方針を提供することが望ましい。  財源は,SMS の導入,運用及び改善を管理するために適した詳細度で予算配分することが望ましく,このためには,サービスの予算業務及び会計業務プロセスと財務管理との調整が必要となる。

表 A.6−容量・能力管理とのインタフェース及び統合

 容量・能力管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  SLM プロセスは,容量・能力管理の目標に加えて,SLA 及び要求されるサービスレベルを提供することが望ましい。  サービスの予算業務及び会計業務プロセスは,サービス提供の結果,容量・能力の費用の減少又は容量・能力の資源の利用度の向上につながる,効率性の向上に関する情報を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,容量・能力及びパフォーマンスに関係するインシデントについての情報を提供することが望ましい。  構成管理プロセスは,CMDB で維持される CI に関する技術,サービス,利用度,財務及び事業に関するデータを提供することが望ましい。  SLM プロセスは,新規又は変更された要求事項のパフォーマンス及び容量・能力の目標の達成を確実にするために,定期的な報告書を受領することが望ましい。パフォーマンスは所定の作業負荷に依存するので,具体的なパフォーマンスの目標が定められた SLA では,両方が必要となる。同様に,容量・能力又はパフォーマンスの課題が関与している場合,運用レベル合意書及び外部契約の起草及びレビューを行う上で,SLM プロセスを補佐するための容量・能力管理プロセスに関する要求事項が必要となることがある。  サービス継続及び可用性管理プロセスは,採用する復旧のための全ての選択肢に必要となる容量・能力を決定するために,モデル化データを受領することが望ましい。発動後に,必要となるパフォーマンス及びスループットのレベルを定めるために,必要となる最低限のハードウェア及びソフトウェア構成を定義する。  問題管理プロセスは,容量・能力に関する問題の特定,診断及び解決を助けるために,専門知識を受領することが望ましい。  変更管理プロセスは,変更が容量・能力に及ぼす累積的な影響に関して,容量・能力管理プロセスから情報を受領することが望ましい。また,容量・能力管理プロセスについても,既存の容量・能力に対する変更の影響のアセスメントを行い,容量・能力の要求事項の変更を特定するために,代表者が変更諮問委員会に参加する。  リリース及び展開管理プロセスは,特に配付にネットワークを使用している場合,リリースの配付方針の決定を助ける情報を受領することが望ましい。ネットワーク帯域幅,ホスト及び目標とする容量・能力,配付時間帯及び目標数などの要因は,リリースの配付方針の一部として検討することが望ましい。  容量・能力管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  容量・能力管理プロセスは,不適合及び改善の機会を特定する監査結果を受領することが望ましい。  容量・能力管理プロセスは,サービス提供者が十分な技能をもち,容量・能力管理プロセスを支援できる技能レベルであることを確実にするために,力量,認識及び教育・訓練に関する要求事項を提供することが望ましい。

表 A.7−ISM とのインタフェース及び統合

 ISM と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  サービスの予算業務及び会計業務プロセスは,セキュリティ管理策関連の費用に関する情報を提供することが望ましい。  容量・能力管理プロセスは,セキュリティ管理策の容量・能力への影響(セキュリティ管理策はサービスのパフォーマンスに影響を及ぼすことが多い。)を提供することが望ましい。  供給者管理プロセスは,供給者が情報セキュリティ方針を順守し,維持しているかどうかを評価する報告書を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,情報セキュリティ方針の要求事項を満たし,再発を防ぐために,全てのセキュリティインシデントに関する詳細な情報を提供することが望ましい。  問題管理プロセスは,特定された情報セキュリティインシデントの根本原因を ISM に提供することが望ましい。  構成管理プロセスは,高いセキュリティリスクに関して CMDB に置かれている構成品目の詳細,並びに情報セキュリティ問題の影響及び解決策を決定できる,CMDB にある情報を提供することが望ましい。  変更管理プロセスは,情報セキュリティの解決策及び暫定策の詳細を提供することが望ましい。  SLM プロセスは,SLA に含める情報セキュリティの要求事項を受領することが望ましい。  サービス継続及び可用性管理プロセスは,サービスの継続及び可用性を確実にするために,情報セキュリティインシデント,問題及び解決策の詳細を受領することが望ましい。 BRM プロセスは,情報セキュリティの脅威に関する警告を受領することが望ましい。  インシデント及びサービス要求管理プロセスは,情報セキュリティインシデントへの対処法に関する手引を受領することが望ましい。  ISM と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  ISM プロセスは,全ての情報が保護され,事業価値,規制要求事項,並びに機密性,完全性及び可用性の要求されるレベルに整合するように管理されることを確実にするために,文書の運用管理に情報セキュリティ方針を提供することが望ましい。  ISM プロセスは,サービスに対するセキュリティリスクのアセスメントが行われ,管理されることを確実にするために,情報セキュリティ方針をリスクマネジメントに提供することが望ましい。

表 A.8−BRM とのインタフェース及び統合

 BRM と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  SLM プロセスは,サービスの適用範囲を含む SLA 又は契約を提供することが望ましい。  サービスの報告プロセスは,特定されたニーズ及び顧客要求事項を含むサービス報告書を提供することが望ましい。  サービス継続及び可用性管理プロセスは,サービス継続計画の詳細を提供することが望ましい。  ISM プロセスは,顧客関係に影響を及ぼす可能性がある脅威の警告を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,顧客からの正式な苦情及び賛辞の詳細を提供することが望ましい。  変更管理プロセスは,顧客の苦情及び顧客満足度調査から生じる修正処置及び改善処置を受領することが望ましい。  BRM と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  BRM プロセスは,コミュニケーション及び顧客満足度の改善につながるこれらの結果を,顧客に提供することが望ましい。  顧客の苦情及び顧客満足度調査は,SMS のレビューへのインプットを提供することが望ましい。

表 A.9−供給者管理とのインタフェース及び統合

 供給者管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  SLM プロセスは,目標,要求事項及び責任が,基盤となる合意書及び契約(underpinning agreements and contracts)  請負の合意書及び契約に含まれることを確実にし,これらの目標が SLA に規定されるものを含めたサービスの要求事項を支援するように,目標,要求事項及び責任を提供することが望ましい。  サービス継続及び可用性管理プロセスは,他の関係者によって供給されるサービスに関して,継続及び可用性要求事項を提供することが望ましい。  サービスの予算業務及び会計業務プロセスは,供給者管理の要求事項及び契約に資金を投入するため,並びに購入及び調達に関する事項に助言及び手引を提供するため,適切な資金を提供することが望ましい。  ISM プロセスは,供給者のサービス及びシステムへのアクセスと,ISM の方針及び要求事項への適合に関する供給者の責任とに関する方針及び手順を提供することが望ましい。  供給者管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  供給者管理プロセスは,供給者のパフォーマンスのデータを受領することが望ましく,顧客要求事項及び事業計画を支援するための金銭的価値を交渉するために,  利用可能な選択肢に対してこのデータを測定することが望ましい。  供給者管理プロセスは,供給者が事業遂行能力の要求事項を継続的に満たすことを確実にするために,供給者の能力,認識及び教育・訓練並びに供給者の教育・訓練の評価結果に関する要求事項を提供することが望ましい。  サービスに対するコミットメントの変更を含む,利害関係者が合意する契約,合意文書又はその他の文書の変更は,変更管理プロセスで管理することが望ましい。  変更管理プロセスは,要求されたとおりに,供給者が組織の変更管理の実践を順守していること,並びに供給者によって提供されるサービスに影響を及ぼす変更案のレビュー,アセスメント及び認可に供給者が参加することを確実にすることが望ましい。

表 A.10−インシデント及びサービス要求管理とのインタフェース及び統合

 インシデント及びサービス要求管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  SLM プロセスは,合意したインシデント及びサービス要求の目標を提供することが望ましい。  問題管理プロセスは,インシデントの影響を最小限にするために,既知の誤りの記録及び暫定策の詳細を提供することが望ましい。  構成管理プロセスは,より正確な影響アセスメントを可能にするために,インシデント又はサービス要求によって影響を受ける CI に関する情報をインシデント及びサービス要求管理プロセスに提供することが望ましい。  サービス継続及び可用性管理プロセスは,サービスの可用性又は継続に大きな影響を及ぼす,インシデント及び重大なインシデントの詳細を受領することが望ましい。  容量・能力管理プロセスは,容量・能力不足に関連するインシデント及び重大なインシデントの詳細を受領することが望ましい。  問題管理プロセスは,傾向分析のために,インシデント及びサービス要求の記録の詳細を受領することが望ましい。  変更管理プロセスは,結果的に新たなインシデントとなった,失敗した変更の影響に関する報告を受領することが望ましい。  インシデント及びサービス要求管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  インシデント及びサービス要求管理プロセスは,役割ごとに,要員の専門的力量を要求する。これらのサービスマネジメントの力量に関する要求事項は,明確に定義することが望ましい。その役割について検討されている個人又は既に役割を担っている個人に力量の不足又はその他の欠陥がある場合,サービス提供者は,この不足を修正することを確実にすることが望ましい。  プロセスの改善及び経費節減の機会を特定するために,インシデントの記録及びサービス要求についてレビューすることが望ましい。

表 A.11−問題管理とのインタフェース及び統合

 問題管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  SLM プロセスは,SLA 及び合意した問題管理の目標を含めた合意書を提供することが望ましい。  サービス継続及び可用性管理プロセスは,サービスの可用性又は継続に大きな影響を及ぼす問題の詳細を提供することが望ましい。  容量・能力管理プロセスは,容量・能力の傾向を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,次の事項を提供することが望ましい。  − 未知の根本原因があるインシデントの詳細を問題管理プロセスに提供する。  − 傾向分析など,事前予防的問題管理のためのインシデントデータ  構成管理プロセスは,問題の影響及び解決策の決定を助ける,CI 間の関係に関する情報を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,次の事項を受領することが望ましい。  − 稼働環境に導入される新規サービス又はサービス変更のための,既知の誤りの詳細  − インシデントの影響を最小限にするための既知の誤りの記録及び暫定策の詳細  変更管理プロセスは,既知の誤りに対して恒久的解決策を実施するための変更要求を受領することが望ましい。  問題管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  問題管理プロセスは,SMS の問題に関する情報を受領することが望ましい。  問題管理プロセスは,SMS の問題の根本原因を特定し,変更管理プロセスを通してそれらを解決することが望ましい。  既知の誤りのデータベースは,文書の運用管理の方針及び手順を順守することが望ましい。

表 A.12−構成管理とのインタフェース及び統合

 構成管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  構成管理プロセスは,問題の影響及び根本原因の分析を助ける,CI 間の関係に関する情報を提供することが望ましい。  構成管理プロセスは,変更案によってどの CI が影響を受けるかに関する情報を提供することが望ましい。  構成管理プロセスは,サービスカタログに記載されているサービスを支援する CI に関する情報を提供することが望ましい。  新規サービス又はサービス変更の設計及び移行プロセスは,利害関係者が,既存の CI 及びサービスに対する影響のアセスメントを行えるように,新規サービス又はサービス変更の全ての計画及び設計の詳細を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,CI に関係する全てのインシデント及びサービス要求の詳細を提供することが望ましい。  問題管理プロセスは,既知の誤り及び暫定策とその影響を受ける構成品目との関連を提供することが望ましい。  変更管理プロセスは,CI に加わる変更の詳細,及びその変更を CMDB に反映させる権限を提供することが望ましい。  リリース及び展開管理プロセスは,リリース品目の構成ベースライン並びにリリースの前及び後の対象の環境を提供することが望ましい。  全てのプロセスは,そのプロセスの適用範囲内の全ての CI に関して,最新かつ正確な情報を受領することが望ましい。  サービスの予算業務及び会計業務プロセスは,サービスの提供に使用する,ライセンスを含めた資産の詳細を受領することが望ましい。  構成管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  トップマネジメントは,サービスの提供に使用する,ライセンスを含めた全ての資産を,法令・規制要求事項及び契約上の義務に従って管理することを確実にする責任をもつ。構成管理は,この要求事項を達成するための主要な手段である。  構成管理プロセスには財務資産の会計業務を含まないが,財務資産の会計業務プロセスとのインタフェースを含むことが望ましい。

表 A.13−変更管理とのインタフェース及び統合

 変更管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  サービス継続及び可用性管理プロセスは,次の事項を提供することが望ましい。  − サービス継続の手順及び計画を更新するための変更要求。これよって,サービス継続の手順及び計画が引き続き正確で,最新であることを確実にし,利害関係者が変更について認識することを確実にする。  − 変更案がサービス又はコンポーネントの可用性に及ぼす潜在的影響を,変更管理プロセスに提供する。  容量・能力管理プロセスは,個々の変更の影響だけではなく,変更がサービスの容量・能力,及び資源又はコンポーネントの容量・能力に及ぼす総合的影響を含めて,変更案のアセスメントを提供することが望ましい。  ISM プロセスは,変更案が情報セキュリティ方針及び管理策に及ぼす潜在的影響を提供することが望ましい。  インシデント及びサービス要求管理プロセスは,実施された変更に付随するインシデントに関する情報を提供することが望ましい。  問題管理プロセスは,実施された変更に付随する問題に関する情報を提供することが望ましい。  構成管理プロセスは,利害関係者及び要員が変更案の影響のアセスメントを行えるようにするために,正確な構成情報への,信頼性があり,迅速かつ容易なアクセスを提供することが望ましい。  リリース及び展開管理プロセスは,リリース管理によって実施される,承認された変更に関する情報を受領することが望ましい。  変更管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  SMS への全ての変更は,変更管理プロセスを経由することが望ましい。  変更管理プロセスは,SMS,サービスカタログ,サービス,方針,目的及び計画,事業上の要求事項,サービスの要求事項,並びに供給者の要求事項への全ての変更の詳細を提供することが望ましい。  SMS の適用範囲は,改善及びその他の変更に係る時間及び費用に影響を及ぼし,加えて変更管理プロセスにも影響を及ぼす。

表 A.14−リリース及び展開管理とのインタフェース及び統合

 リリース及び展開管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。  サービス継続及び可用性管理プロセスは,特に全体的な容量・能力が向上するときに,サービスが継続的に可用性の目標を満たすことを確実にするために,技術設計のアセスメントを提供することが望ましい。継続管理計画の早期のレビュー及び更新には,重要な新規リリースを含めることが望ましい。適切な継続性のレビュー及び試験のスケジュールは,リリース展開の前に組むことが望ましい。  容量・能力管理プロセスは,リリースを支援するための増分の容量・能力の購入及び導入に関する情報及び支援を提供することが望ましい。これには,開発及び試験の環境用の容量・能力の確保を含めてもよい。  ISM プロセスは,リリースの結果生じる新たな方針,実践及びツールの採用に合わせて,更新されたセキュリティ計画を提供することが望ましい。  供給者管理プロセスは,現在有効な,又はリリース内にある技術コンポーネントの調達及び支援の前に更新される,  必要な契約及び合意書を提供することが望ましい。これによって,リリースの実運用の要件を満たす。  変更管理プロセスは,承認された変更要求をリリース及び展開管理に提供することが望ましい。  SLM プロセスは,サービス又はサービスレベルの文書及び主要な窓口の変更に関する更新を受領することが望ましい。  問題管理プロセスは,リリースとともに稼働環境に持ち込まれる欠陥及びそのための暫定策の通知及び記録を受領することが望ましい。  構成管理プロセスは,リリース後の稼働環境の変更を反映した情報を受領することが望ましい。この情報で,CMDB の正確さを確実にする。CMDB に関する追加のリリース情報は,修正又は廃止される CI の更新及び旧サービスに取って代わる新規サービスを含む。  リリース及び展開管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。  リリース及び展開管理プロセスは,リリースの一部として必要となる教育・訓練,新規採用又は初期支援を考慮することが望ましい。  トップマネジメントは,サービス提供者が取得又は使用する要員資源の量及び技能が,リリースの構築,試験及び展開,並びに実運用に入った新規リリースの支援及び運用のために十分であることを確実にすることが望ましい。

参考文献



トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2017-09-26 (火) 14:27:45 (1120d)