>サイトトップへ >このカテゴリの一覧へ

Q 20000-2

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

(1)

目  次

ページ

0.1

  序文  

1

0.2

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

1

1

  適用範囲  

3

1.1

  一般  

3

1.2

  適用  

4

2

  引用規格  

5

3

  用語及び定義  

5

4

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

5

4.1

  経営者の責任  

5

4.2

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

15

4.3

  文書の運用管理  

17

4.4

  資源の運用管理  

19

4.5

  SMS の確立及び改善  

21

5

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

26

5.1

  一般  

26

5.2

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

27

5.3

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

30

5.4

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

33

5.5

  文書及び記録  

33

5.6

  権限及び責任  

34

6

  サービス提供プロセス  

34

6.1

  サービスレベル管理  

34

6.2

  サービスの報告  

38

6.3

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

39

6.4

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

44

6.5

  容量・能力管理  

47

6.6

  情報セキュリティ管理  

50

7

  関係プロセス  

54

7.1

  事業関係管理  

54

7.2

  供給者管理  

57

8

  解決プロセス  

60

8.1

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

60

8.2

  問題管理  

63

9

  統合的制御プロセス  

66

9.1

  構成管理  

66


Q 20000-2

:2013 (ISO/IEC 20000-2:2012)  目次

(2)

ページ

9.2

  変更管理  

69

9.3

  リリース及び展開管理  

71

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

76

参考文献  

83


Q 20000-2

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

(3)

まえがき

この規格は,工業標準化法第 14 条によって準用する第 12 条第 1 項の規定に基づき,一般財団法人日本

情報経済社会推進協会(JIPDEC)及び一般財団法人日本規格協会(JSA)から,工業標準原案を具して日

本工業規格を改正すべきとの申出があり,日本工業標準調査会の審議を経て,経済産業大臣が改正した日

本工業規格である。

これによって,JIS Q 20000-2:2007 は改正され,この規格に置き換えられた。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意

を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許権,出願公開後の特許出願及び実

用新案権に関わる確認について,責任はもたない。

JIS Q 20000

の規格群には,次に示す部編成がある。

JIS

Q

20000-1

  第 1 部:サービスマネジメントシステム要求事項

JIS

Q

20000-2

  第 2 部:サービスマネジメントシステムの適用の手引


日本工業規格

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∼箇条 に規定するプロセスの運用には,人材を適切に組織し,かつ,調整することが必要である。

サービスマネジメントのプロセスを効果的かつ効率的なものとするために,適切なツールを使用してもよ

い。最も効率的な組織は,計画立案・設計から,移行,運用までの,継続的改善を含むサービスのライフ

サイクルの全ての段階における SMS への影響を考慮する。

この規格は,組織が,ISO/IEC 20000 規格群の他の部及び他の関連規格を参考にすることを含めて,JIS 

Q 20000-1

を解釈し,それを適用できるようにするための例及び提言を示している。

この規格の利用者は,正しい適用に関して責任がある。ISO/IEC 20000 規格群を利用する組織及び個人


2

Q 20000-2

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

は,次の事項を理解することが重要である。

−  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 及びサービスへの適用を促進する。

図 に示す 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 に基づく情報セキュリティマネジメントシステムと統合することができる。統合マネジメ

ントシステムアプローチは,

効率性を高め,

説明責任の明確な所在及びトレーサビリティについて確立し,

組織の計画立案,コミュニケーション及び管理を向上させる。


3

Q 20000-2

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

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

JIS Q 20000-1

は,次のとおり規定している。

この規格は,次の組織,サービス提供者又は審査員若しくは監査員が利用してもよい。

a)

サービス提供者からのサービスを求め,サービスの要求事項が満たされるという保証を必要とする組

b)

サプライチェーンに属するものを含め,全てのサービス提供者による一貫した取組みを求める組織

c)

サービスの要求事項を満たすサービスの設計,移行,提供,及び改善に関する能力を実証しようとす

るサービス提供者

d)

自らのサービスマネジメントのプロセス及びサービスを,監視,測定及びレビューするサービス提供

e)

サービスの設計,移行及び提供を,SMS の効果的な導入及び運用を通して改善するサービス提供者

f) 

この規格の要求事項に対するサービス提供者の SMS の適合性評価に,基準として用いる審査員又は

監査員

この規格は,認証を求めるか否かに関係なく,サービスマネジメントの改善方法に関する手引を必要と

する組織が利用することができる。

適用範囲 

1.1 

一般 

この規格は,

JIS Q 20000-1

に基づく SMS の適用に関する手引を示す。

この規格は,

組織が,

ISO/IEC 20000

規格群の他の部及び別の関連規格を参考にすることを含めて,JIS Q 20000-1 を解釈し,それを適用できる

ようにするための例及び提言を示す。この規格は,個別のベストプラクティスの枠組みから独立したもの

であり,サービス提供者は一般に受け入れられた手引と独自の手法との組合せを適用することができる。


4

Q 20000-2

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

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

図 の中央ボックス部分に,箇条 6∼箇条 のプロセスを示す。箇条 6∼箇条 のプロセスを取り囲んで

いるのが,箇条 の新規サービス又はサービス変更の設計及び移行プロセスである。これは,新規サービ

ス又はサービス変更が,中央ボックス部分のプロセスによって運用されることを示す。箇条 が適用され

る新規サービス又はサービス変更がない場合,全てのサービスは直接,箇条 6∼箇条 によって提供する

ことができる。

サービスマネジメントのプロセス間のインタフェースと SMS の各コンポーネントとの関係は,

サービス

提供者が異なれば,異なるように実現してもよい。サービス提供者と顧客との関係の性質が,どのように

SMS

を導入し,JIS Q 20000-1 の要求事項を満たすかに影響することもある。そのため,プロセス間のイ

ンタフェースは,

図 には示していない。

1.2 

適用 

サービス提供者には,SMS の説明責任があり,他の関係者に JIS Q 20000-1 の箇条 4(サービスマネジ

メントシステムの一般要求事項)の要求事項を満たすことを要求することはできない。例えば,サービス

提供者は他の関係者に対して,トップマネジメントを提供し,トップマネジメントのコミットメントを実

証したり,又は他の関係者が運用するプロセスのガバナンスを実証するように求めることはできない。

JIS Q 20000-1

の箇条 に示す活動の中には,サービス提供者の管理下で他の関係者が実施するものがあ

る。例えば,サービス提供者は,自身の代わりに内部監査を実施する第三者を雇うことができる。サービ

ス提供者が他の関係者に初期のサービスマネジメントの計画を立てるように求めるのも,

その一例である。

計画は,それが立案され,同意されれば,サービス提供者が直接の責任をもち,維持するものとなる。こ

うした例では,サービス提供者が,他の関係者を個別の短期的活動のために使用する。サービス提供者は,

SMS

に関する説明責任,権限及び責任をもつ。そのため,サービス提供者は,JIS Q 20000-1 の箇条 


5

Q 20000-2

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

要求事項を全て満たしているという証拠の提示ができる。

サービス提供者は,全ての要求事項を直接満たしているという証拠,又は他の関係者が運用するプロセ

スのガバナンスの証拠とともに,大半の要求事項を直接満たしているという証拠を示すことができる。JIS 

Q 20000-1

の箇条 5∼箇条 のプロセスの過半数の運用について,サービス提供者が他の関係者に依存して

いる場合,サービス提供者はプロセスのガバナンスを実証することはできない。ただし,他の関係者がご

く少数のプロセスを運用しているだけの場合,サービス提供者は,通常,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 に基づき,

“一致している”こ

とを示す。

引用規格 

次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。この引用

規格は,その最新版(追補を含む。

)を適用する。

JIS Q 20000-1

  情報技術−サービスマネジメント−第 1 部:サービスマネジメントシステム要求事項

注記  対応国際規格:ISO/IEC 20000-1,Information technology−Service management−Part 1: Service

management system requirements

(IDT)

用語及び定義 

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

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

4.1 

経営者の責任 

4.1.1 

経営者のコミットメント 

4.1.1.1 

トップマネジメントの責任 

トップマネジメントは,最高位でサービス提供者を指揮し,監視し,管理する経営者であることが望ま

しい。

トップマネジメントは,JIS Q 20000-1 の要求事項を満たすことに,次の事項が含まれていることを認識

することが望ましい。

a) SMS

の計画及び確立に始まり,SMS の運用,監視,測定,レビュー,維持及び継続的改善に至る SMS

の全段階に関与するコミットメントを実証する。

b)  SMS

に関する説明責任及び責任を実証する。


6

Q 20000-2

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

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

の方針に整合し,それを支援するプロセス及び手順の承認

トップマネジメントによるサービスマネジメントの計画の承認は重要である。

なぜならば,

この計画は,

顧客へのコミットメント,供給者のための計画立案活動,並びに改善及びその他の変更のための資源配分

に影響することがあるからである。

方針,プロセス及び手順を整合させることで,トップマネジメントの指示がサービス提供者の全ての要

員に行き届くようになる。これによって,経営者の決定が,サービス提供者の要員による日々の運用方法

と整合することが望ましい。


7

Q 20000-2

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

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 

サービスマネジメントの目的 

トップマネジメントは,合意されたサービスマネジメントの目的を定義することが望ましい。目的は,

事業目的及びサービスマネジメントの方針に整合することが望ましい。

例えば,一般的なサービスマネジメントの目的には,次の事項が含まれる。


8

Q 20000-2

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

a)

新規サービス又はサービス変更を迅速に提供して,事業の機敏性を高められるようにする。

b) 

事業上重要なサービスについて,計画外の非可用性を低減する。

c)

運用効率によって,提供するサービスの費用を最適化する。

d)

リスクを低減しながらサービスの質を高める。

実際のサービスマネジメントの目的は,目的に対する達成度を正確に測定できるように定義することが

望ましい。測定は,改善の機会の優先度付けも可能にすることが望ましい。

目的は,サービスマネジメントの計画の主要なインプットとなることが望ましい。計画は,目的の達成

及び SMS の他のコンポーネントとの整合のための処置を特定することが望ましい。

サービスマネジメントの目的は,いつ,どのようにして目的を改訂することが望ましいかをトップマネ

ジメントが決められるように,一定の間隔でレビューすることが望ましい。

サービス提供者は,

サービスマネジメントの目的を支援する上での有効性のアセスメントを行うために,

SMS

の各コンポーネントの有効性を測定することを確実にすることが望ましい。例えば,ある特定のプロ

セスによって,目的が支援される有効性の測定である。また,測定は,事業目的を支援する上での SMS

の価値を実証するものであることが望ましい。

サービス提供者には,目的の達成に向けた個人の貢献度の測定が役立つことがある。これが,SMS を支

援する要員が,同じ到達目標に向かって一丸となって働くことを促進する。

4.1.1.5 

サービスマネジメントの計画 

サービスマネジメントの計画は,サービスマネジメントの目的の達成を確実にするために,全ての SMS

の取組みの調整を促進することが望ましい。また,計画と方針とを一致させることが望ましい。

計画は,全体(end-to-end)の可視性及び管理を可能にする強力な仕組みになり得る。また,計画は,両

立しない取組みが承認又は実施されることを予防することが望ましい。計画は,資源及び能力が可能な限

り効率的かつ効果的に利用されることを可能にすることが望ましい。

計画は,全ての利害関係者に周知させることが望ましい。これは,取組みの適用範囲,作業,時間枠及

び割り当てられた責任に対する共通の理解を確実にするものであることが望ましい。割り当てられた責任

は,サービスマネジメントの計画の取組みに関与する人を含めて,SMS に関与する全員のパフォーマンス

の測定に含めることが望ましい。

計画は,SMS を導入したときに完了するものと考えないほうがよい。計画は,変化する事業ニーズ,顧

客要求事項又はサービス提供者の優先度に対応するように修正され続けることが望ましい。

サービスマネジメントの計画は,一つの計画で構成されることもあるが,調整された変更のプログラム

で構成されることもある。

そのプログラムの一部は局所的に導入されることもあるが,

中央で管理される。

サービス提供者は,サービスマネジメントの計画の全般的な管理下で,局所的に全ての変更を導入する

必要性を常に認識していることが望ましい。例えば,あるプロセスの改善は,局所的な制御プロセスオー

ナの下で局所的に実施してもよいが,その改善は,中央で管理されるプログラム全体に含まれる。

サービス継続及び可用性管理プロセスなどの個々の目的に対する計画は,個々に含めるよりもサービス

マネジメントの計画全体から参照するとよい。

専門的な計画及びそれらと計画全体との整合性については,

変更の度合いに適した頻度でレビューすることが望ましい。レビューは,少なくとも年に 1 回行うことが

望ましい。

レビューによって生じる変更,サービスの要求事項の変更によって生じる変更,又は個々の計画の変更

によって生じる変更は,いずれもサービスマネジメントの計画全体において文書化することが望ましい。


9

Q 20000-2

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

例えば,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(サービスの要求事項)の定義は,顧客及びサービスの利用者のニーズ並びにサー

ビス提供者のニーズを含んでいる。トップマネジメントは,提供されるサービスが合意したサービスの要

求事項を満たすことを確実にすることに責任をもつことが望ましい。

稼働環境のサービスと同様に,新規サービス又はサービス変更との継続的な整合を確実にするため,顧

客要求事項と事業ニーズとの両方を文書化し,監視し,レビューし,管理することが望ましい。

サービスの要求事項には,要求されるサービス目標及び期待される品質を含めることが望ましい。サー

ビス提供者のニーズには,資源及び能力の要求事項の詳細を含めることが望ましい。サービスの要求事項

は,

図 に示すとおり,SMS へのインプットとなる。


10

Q 20000-2

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

サービスの要求事項の例には,次の事項を含むことがある。

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

の有効性の測定,監査,報告及び改善に関する要求事項。


11

Q 20000-2

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

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(新規サービス又はサービス変更の設計及

び移行)の要求事項の達成を確実にすることが望ましい。


12

Q 20000-2

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

方針は,サービス提供者のマネージャ及び要員に,以下の例のように,明確なトップマネジメントの指

示を伝えることが望ましい。

例 1  サービスは,顧客の事業目的に整合している。

例 2  プロセス又は手順の変更は,変更管理プロセスを通じてだけ行われる。

例 3  サービスマネジメントのプロセスの役割及び責任は,一貫した方法で定義され,文書化され,

また,要員のパフォーマンスは,これらの責任の達成を基準にして測定される。

サービスマネジメントの方針は,サービス提供者のサービスマネジメントの目的が達成されているかど

うかのアセスメントに使えるように構成することが望ましい。例えば,サービスマネジメントの方針と,

サービス提供者のサービスマネジメントの目的を達成するために何が行われているかとの関連を実証でき

ることが望ましい。サービスマネジメントの方針は,方針の順守の測定が可能となるように構成すること

が望ましい。

サービス提供者は,サービス提供者の目的とサービスマネジメントの方針との関連が,サービスマネジ

メントの方針について最初に合意したとき以降,効果的なままであることを実証できることが望ましい。

サービスマネジメントの方針は,例えば,改善の取組みが個々のプロセスオーナ又はトップマネジメン

トによって承認されるかどうかを決定できるようにするなど,明確に権限のレベルを定義することが望ま

しい。

サービスマネジメントの方針は,サービス提供者自身の組織内に周知され,理解されることが望ましい。

サービスマネジメントの方針は,必要な場合,顧客及び供給者にも伝えてよい。方針の参照が,討議され,

理解され,

適切に利用されている場合,

この要求事項を満たしていることの証拠として使うことができる。

例えば,会議の議事録,要員の調査,供給者との契約,再請負契約,方針の変更の要求又は明確化の要求,

標準的及び計画外の運用時のプロセス,手順及び行動に及ぼす方針の影響,顧客調査,供給者調査などで

ある。

さらに,トップマネジメントは,サービスマネジメントの方針を,少なくとも年に 1 回,適切な間隔で

レビューすることを確実にする責任をもつことが望ましい。これによって,欠陥を特定することが望まし

く,また,事業ニーズ及び顧客要求事項との継続的な整合を確実にすることが望ましい。サービスマネジ

メントの方針のレビューのときに適用する品質基準は,次の事項を考慮することが望ましい。

a)

サービスの要求事項に照らした方針の妥当性

b)

レビューの頻度の適切性

c)

方針とサービスマネジメントの目的との整合

d)

方針とサービスマネジメントの計画との整合

e)

方針とサービスマネジメントのプロセスとの整合

f) 

レビューが文書化され,承認され,追跡され,適切で,かつ,実施可能かどうか

g) SMS

の確立,導入,運用,監視,レビュー,維持及び改善のための枠組みの適切性

h) SMS

のこれまでのレビュー及び監査で特定された修正及び改善処置

4.1.2.2 

方針の改善及びその他の変更 

サービスマネジメントの方針のレビュー後に,欠陥が発見された場合には,トップマネジメントは,そ

れを修正することを確実にすることが望ましい。欠陥は,方針,サービスマネジメントの目的,計画,プ

ロセス又は手順のいずれかの変更として修正することが望ましい。

さらに,方針は,サービスマネジメントの目的又は SMS の適用範囲の変更を反映するように更新する


13

Q 20000-2

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

ことが望ましい。

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 の他の部分と統合されていることを確実にするこ


14

Q 20000-2

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

とを,この権限に含めることが望ましい。

サービス提供者は,どの人が管理責任者であるか,及び管理責任者の責任及び権限レベルが次の人々に

よって理解されていることが明確であることを確実にすることが望ましい。

a)

プロセス,

そのプロセスと他のプロセスとのインタフェース,

及び SMS 内での統合について文書化し,

順守し,測定し,改善することを確実にする権限及び責任をもつプロセスオーナ

b)

設計,移行,実施,改善及び廃棄を含めたライフサイクル全体で,サービスに関する権限及び責任を

もつサービスオーナ

c) 

その他のサービス提供者の要員

d)

組織内のグループ

e)

統括供給者を含む供給者

f)

顧客

注記  サービスマネジメントのプロセス間のインタフェース及び SMS の他のコンポーネントとの統

合の例については,

附属書 を参照。

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 が要求していることを認識することが望ま

しい。資産は,効果的な手順によって管理することが望ましい。

管理されることが望ましい資産の例は,ソフトウェアライセンス,モバイル機器,インフラストラクチ

ャのコンポーネント,人,契約,手順,その他の文書などがある。サービス提供者は,資産の場所,状態


15

Q 20000-2

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

及び関連する詳細情報を正確に特定できるようにすることが望ましい。

トップマネジメントは,資産管理には,正確な構成管理データベース(以下,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∼箇条 に示す,どのプロセスを運

用する他の関係者のパフォーマンスについても,全体(end-to-end)の可視性をもつことが望ましい。

サービス提供者は,SMS のプロセスを運用する全ての当事者の管理を実証できることが望ましく,この

ことは,全ての契約及び他の合意文書で裏付けられていることが望ましい。

4.2.2 

他の関係者 

他の関係者には,次が含まれる。

a) 

サービス提供者と同一の組織内にあるが,サービス提供者の直接的な管理下にない,組織単位である

内部グループ(例えば,データセンタ又はセキュリティ専門チーム)

b) 

供給者として活動する顧客(例えば,インシデント及びサービス要求管理の活動の一部を実施する顧

客)

c)

供給者(例えば,リリース及び展開管理プロセスの一部として行われる試験の外部委託先)

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

4.2.3 

説明責任及び権限の実証 

サービス提供者は,次の事項のような証拠を提示して,プロセスに関する説明責任及び権限を実証する


16

Q 20000-2

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

ことが望ましい。

a)

サービス提供者又は他の関係者によって運用される,サービスマネジメントのプロセスの有効性に関

するサービス提供者の説明責任。例えば,意思決定者のマトリクス,サービス提供者自身の組織内の

権限レベルの証明など。

b)

サービス提供者がプロセスの順守を要求する権限をもっている。例えば,情報セキュリティ方針の策

定,管理策の利用,違反の検出及び是正処置の開始。その他の例には,サービス提供者の要求によっ

て実践方法を変更した証拠の提示がある。

c)

サービス提供者による測定を含めたプロセスの記録の分析。例えば,インシデント記録を提出するの

が,インシデント管理プロセスを運用する他の関係者であっても,インシデント記録の全部又はイン

シデント報告書を検討し,その内容に基づいて決定を下す。

d) 

他の関係者が運用する箇条 5∼箇条 のプロセスを含めた,SMS の全てのプロセスの定義の管理。こ

れは,各プロセス間のインタフェースを含む。例えば,変更管理プロセスと構成管理プロセスとのイ

ンタフェース及び依存関係の文書化,合意及び運用がある。詳細は 4.2.4 参照。

e)

JIS Q 20000-1

の箇条 4(サービスマネジメントシステムの一般要求事項)∼箇条 9(統合的制御プロ

セス)に規定する,全てのプロセスに対する計画及び改善の優先度設定の管理。例えば,そのプロセ

スが他の関係者によって運用されている場合でも,容量・能力管理プロセスでの改善のアセスメント

及び優先度付けを行う。

サービス提供者は,サービス提供者が設計し文書化したプロセスの運用を他の関係者に要請することが

できる。別の方法として,サービス提供者は,他の関係者が設計し,文書化し,運用するプロセスを承認

することができる。

サービス提供者は,過半数のプロセスの運用を他の関係者に頼っている場合には,適切なプロセスのガ

バナンスを実証することはほぼ不可能だと認識することが望ましい。

注記  他の関係者が運用するプロセスのガバナンスについては,ISO/IEC 20000-3:2012 に記載されて

いる。

4.2.4 

プロセスのパフォーマンス及び適合性 

サービス提供者は,箇条 5∼箇条 に規定するプロセスが望まれる成果を挙げ,サービスマネジメント

の目的を達成するために貢献することを確実にすることが望ましい。

他の関係者が運用するプロセスのガバナンスには,次の事項を含めて,プロセスの定義を含めることが

望ましい。

a) 

プロセスオーナの識別。例えば,サービス提供者の組織のどのグループ又はどのマネージャがプロセ

スの責任をもつのか。

b)

運用責任。例えば,どのグループ又はどのマネージャがプロセスの運用に責任をもつのか。

c)

プロセスの目的,プロセスの成果,並びに満たされているサービスの要求事項及びサービスマネジメ

ントの目的へのプロセスの貢献

d)

プロセスのインプット及びアウトプット,並びにそれらを生成するのはどの当事者か。

e)

サービスマネジメントのプロセスを含む,他のプロセスとのインタフェースの定義。例えば,プロセ

ス間で受け渡されるデータ,又はある当事者から別の当事者への活動若しくは情報の受渡し

f) SMS

のプロセスと他のコンポーネントとの間のインタフェースの定義。例えば,プロセスと,サービ

スマネジメントの方針及び目的との間


17

Q 20000-2

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

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  他の関係者が運用するインシデント管理プロセスの改善は,サービス提供者の事業目的及びサ

ービスの要求事項によって,並びにサービス提供者の組織によって指示されるものであること

が望ましい。

4.3 

文書の運用管理 

4.3.1 

文書の作成及び維持 

4.3.1.1 

証拠としての文書 

サービス提供者は,SMS の監査のために証拠が利用できることを確実にすることが望ましい。証拠の多

くは,文書の形で存在することが望ましい。文書は,その目的に適切な場合,紙,データベース又はワー

ドプロセッサ内の電子ファイルなど,どのような種類,様式又は媒体でもよい。

次の文書は,SMS の監査のための証拠とみなすことができる。

a)

サービスマネジメントの方針,目的及び計画

b)

プロセス及び手順の文書

c)

サービスカタログ


18

Q 20000-2

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

d)

設計,要求事項の仕様,サービスレベル合意書(以下,SLA という。

,受入基準及びサービスのレビ

ューを含むサービス文書

e)

要求事項及び変更管理の仕様を含む契約文書

f)

監査の計画立案活動及び報告書

g)

変更の計画立案活動など,特定の変更を記述した文書又はそれに関係する文書

サービス提供者は,方針など幾つかの文書は,個別のプロセスの要求事項を満たすために JIS Q 20000-1

によって要求されると認識することが望ましい。また,組織は,明確さを更に高めるために,又は SMS

の効果的な運用若しくは改善,及びサービスの提供を確実にするために,方針を含めた追加文書の検討を

望むことがある。

記録は特別な種類の文書であり,これも同様に証拠として利用できるようにすることが望ましい。

4.3.1.2 

記録を含む文書の作成 

サービス提供者は,記録を含む文書の作成に効果的な手順が必須であることを理解することが望ましい。

これには,目的に整合した命名及び番号付けの方式,並びに文書の改訂履歴の利用が含まれる。テンプレ

ート及び標準書式を使用することによって,内容の作成,アクセス,更新及び利用の手間を省くことがで

きる。

SMS

に定義される文書に関する役割及び責任に従って,文書の受入手順の証拠があることが望ましい。

さらに,サービス提供者は,例えば,モバイル機器又は電子メールサービスの提供を支援するサーバに

保存してもよい情報が何かを定める情報セキュリティ方針のように,SLA,方針,計画などの文書が相互

に依存していることがあることを理解することが望ましい。これらの依存関係を理解し,文書を変更する

ときには管理することが望ましい。

実際に何が行われたか,又は何が起きたのかを示す記録には,必ずしも受入手順は必要ない。例として

インシデント記録がある。インシデント記録は,インシデントが進行するに従い終了まで更新することが

望ましい。インシデント記録を更新するたびに受入手順を運用することは,インシデントの解決に許容で

きない遅れを生じさせる。

注記  文書及び記録は,SMS に固有のものである必要はない。文書及び記録は,JIS Q 20000-1 の要

求事項を満たしている場合には,JIS Q 9001JIS Q 27001 などの規格の要求事項も満たしてい

る可能性がある。

4.3.2 

文書管理 

文書管理は,必須であると認識することが望ましい。文書管理は,定期的なレビュー及び必要に応じた

更新又は保管を含むことが望ましい。レビューは,少なくとも年に 1 回行うことが望ましい。文書は,劣

悪な環境条件,ハードウェア障害などによる損傷から保護することが望ましい。

管理は,他の関係者との契約又は可用性の要求事項に影響する SLA の変更など,変化の影響の可視性を

もたらすことができる。サービス提供者は,次の手段を用いて文書を管理することを確実にすることが望

ましい。

a) 

版(version)の命名及び番号付け

b) 

文書の記述,編集,レビュー,承認,更新,削除及び保管に関して割り当てられた責任

c)

変更の日付,作成者,承認及び改訂の性質を示す変更記録

d) 

承認前の変更管理プロセスによる,特定された文書への変更のアセスメント

e)

個別の文書と SMS の他のコンポーネントとの関係の識別


19

Q 20000-2

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

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 及


20

Q 20000-2

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

びサービスの管理に関与する要員

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

の各サービスマネジメントのプロセスの権限及び責任は,次の事項を含むことが望ましい。


21

Q 20000-2

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

a)

次のことに責任をもつプロセスオーナ

1) 

プロセスの設計

2) 

プロセスの順守を確実にする

3) 

プロセスの測定及び改善

b)

プロセスの運用及びプロセスのマネジメントのための資源の管理に責任をもつプロセスマネージャ

c)

プロセスの手順を実施する要員

個々のサービスマネジメントのプロセスに固有の他の役割については,箇条 5∼箇条 に規定する。

注記  特に小さな組織では,一人の人が複数のサービスマネジメントの役割を担うことは許容できる。

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 につながるおそれがあることを認識することが望ましい。


22

Q 20000-2

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

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,新規サービス又はサービス変更の要求事項。これは,顧客との合意文書が法的

な拘束力をもつ契約でない場合でも検討することが望ましい。


23

Q 20000-2

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

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 の一部を形成するプロセスの変更は,変更が


24

Q 20000-2

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

SMS

の他の部分に及ぼす影響が理解され,許容できると考えられるときにだけ行うことが望ましい。これ

は,他のプロセス又は組織のサービス提供能力への影響を含む。

例  インシデント及びサービス要求管理プロセスで使用するパラメタ又は目標への変更は,例えば,

サービスレベルマネジメント(SLM)

,報告及び情報セキュリティマネジメント(ISM)のプロセ

スなど,他のプロセスに,意図しない悪影響を及ぼすことがある。

プロセス間及び SMS の全てのコンポーネント間の依存関係を理解することによって,

リスクが低減され,

SMS

の効果的なマネジメントが可能になることがある。サービスマネジメントのプロセス間のインタフェ

ース及び SMS 内での統合の例は,参考として

附属書 に記載する。

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 の箇条を,なぜ各内部監査に含めた

か又は除外したかを含めて,決定事項を計画した論拠があることが望ましい。考慮することが望ましい要

因としては,プロセスに関わるリスクの度合い,運用の頻度及び過去の履歴が挙げられる。

内部監査を実施する間隔については,計画を立てることが望ましく,既知のリスク又はその他の問題が

あるときだけ実施するというようにはしないほうがよい。選定された間隔は,次の事項の変更の度合いを


25

Q 20000-2

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

考慮することが望ましい。

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)

顧客満足度調査の結果


26

Q 20000-2

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

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.1 

一般 

5.1.1 

要求事項の意図 

新規サービス又はサービス変更の設計及び移行プロセスは,新規サービス又はサービス変更の提供を管

理するための計画を策定し,導入することが望ましい。このプロセスは,リスクが大きいか,又はサービ

ス若しくは顧客に重大な影響を及ぼす可能性のある,新規サービス又はサービス変更に適用することが望

ましい。

5.1.2 

概念 

このプロセスは,新規サービス又はサービス変更の設計及び移行を管理するための仕組みを規定するこ


27

Q 20000-2

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

とが望ましい。このプロセスは,変更管理プロセスと緊密に連携する。このプロセスで開発又は変更され

る CI は,変更管理プロセスを経由した構成管理プロセスを通じて制御することが望ましい。新規サービス

又はサービス変更は,リリース及び展開管理プロセスを通じて展開することが望ましい。

新規サービス又はサービス変更の要求事項は,事業ニーズを満たすために,又は顧客へのサービスの提

供方法を改善するために,サービスの顧客又は利害関係者によって特定されることが望ましい。サービス

提供者は,このプロセスの用途を決定する基準を含む変更管理方針に基づいて,このプロセスをいつ使用

するかを決めることが望ましい。サービス提供者によって,どの変更に箇条 が当てはまるかを決める方

針も,使用する基準も異なる可能性がある。サービスの廃止,サービスの移行,及び重大な影響を及ぼす

可能性のある新規サービス又はサービス変更は,新規サービス又はサービス変更の設計及び移行プロセス

によって管理することが望ましい。サービス提供者は,新規サービス又はサービス変更が提案されるたび

に,それに付随するリスクを理解することが望ましい。リスクについては,サービス提供者と顧客との両

者の状況を,顧客の事業活動を含めて考慮することが望ましい。新規サービス又はサービス変更のリスク

を最小限にする処置をとることが望ましい。

5.1.3 

要求事項の説明 

新規サービス又はサービス変更の設計及び移行プロセスは,より高いレベルのリスク及び影響を管理す

るための,更に高いレベルの可視性及び統合的制御が必要となる変更を対象にしている。三つの統合的制

御プロセス,すなわち,構成管理,変更管理,並びにリリース及び展開管理のプロセスは,SMS 及びサー

ビスに対する全ての変更に関する管理の中核にある。ただし,SMS 及び SMS の適用範囲外のタスク又は

成果物とのインタフェースをもつ複雑なプロジェクトは,新規サービス又はサービス変更の設計及び移行

プロセスがもたらす更に別の層の統合的制御が必要となることが多い。

サービス提供者ごとに,新規サービス又はサービス変更の設計及び移行プロセスによって,管理する変

更の種類のどれが適切かを決めるために使用する基準は異なることが多い。例えば,基準は,特定の数よ

り多くの利用者又は場所に影響を及ぼすサービスの変更を含むことがある。データ保護法に従って,サー

ビス提供者が処罰されるリスクを引き起こす変更を含む例もある。

新規サービス又はサービス変更の設計及び移行プロセスでは,箇条 の統合的制御プロセスに関連する

インタフェースを定義し,管理することが望ましい。新規サービス又はサービス変更の設計及び移行プロ

セスは,最適なリスク管理及び全てのサービスの要求事項を満たす解決策の提供を確実にするために,箇

条 の統合的制御プロセスと連携することが望ましい。新規サービス又はサービス変更によって影響を受

ける CI は,

構成管理プロセスで管理することが望ましい。

新規サービス又はサービス変更のアセスメント,

承認,スケジューリング及びレビューは,変更管理プロセスで管理することが望ましい。全ての新規サー

ビス又はサービス変更は,

リリース及び展開管理プロセスを用いて,

稼働環境に展開することが望ましい。

5.2 

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

5.2.1 

新規サービス又はサービス変更の必要性 

新規サービス又はサービス変更の必要性は,顧客,サービス提供者,内部グループ又は供給者によって

提起される可能性がある。新規サービス又はサービス変更の目的は,事業ニーズ及び顧客要求事項を満た

すため,又はサービスの有効性を改善するためである場合がある。

5.2.2 

サービス又は顧客への影響が重大である変更 

このプロセスは,サービスへの影響が重大であり,したがって,顧客への影響も重大となる可能性があ

る変更に適用することが望ましい。このようなサービスへの変更は,変更に付随するリスクを低減するた

めに,箇条 の適用によって規定される追加活動を必要とする。


28

Q 20000-2

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

サービス又は顧客への影響が十分に低い変更は,統合的制御プロセスだけで管理することができる。サ

ービス提供者の取り扱う変更の大部分は,この後者の分類に属することが望ましい。

5.2.3 

影響が重大である変更に関する方針 

箇条 に属する変更は,変更管理プロセスの一部として開発される変更管理方針を用いて識別すること

が望ましい。この方針は,サービス又は顧客への影響が重大となる可能性のある,リスクの高い変更の識

別基準を含むことが望ましい。この方針は,サービス提供者独自のニーズ及びそのサービスに対するリス

クのアセスメントに基づくことが望ましい。この方針は,新規サービス又はサービス変更案が,様々な理

由で,様々なところから提起されることがあることを考慮することが望ましい。

この方針は文書化し,新規サービス又はサービス変更プロセスに最も直接的に関与しているトップマネ

ジメント及びプロセスオーナの合意を得ることが望ましい。

変更管理方針の基準は,既存のサービスの廃止と,他の関係者が提供することになるサービスの移管と

の両方を常に含むことが望ましい。それ以外の基準は,サービス提供者ごとに異なっていることが多い。

影響が重大となる可能性のある変更は,次の事項を含むことがある。

a) 

特定の数より多くの利用者又は場所に影響を及ぼすサービスの変更

b) 

データ保護法に従ってサービス提供者が処罰されるリスクを引き起こす可能性がある変更

c)

新規サービス又は既存のサービスの新規顧客

d)

場所,ハードウェアプラットフォームなど,サービスの提供方法の大きな違い

e) 

新しいオペレーティングシステム若しくはソフトウェアアプリケーションの投入,又は既存のソフト

ウェアの重大なリリース

サービス提供者は,新規サービス又はサービス変更の結果,SMS の適用範囲に対する変更を含めて,SMS

に要求することのできる変更を考慮することが望ましい。例えば,顧客と合意したサービス目標に対する

リスクの特定,供給者管理手順,又は既存の若しくは計画したサービスに影響を及ぼす他の関係者との合

意文書に対する変更などである。

5.2.4 

プロジェクトとしての変更管理 

箇条 が適用される新規サービス又はサービス変更は,変更の規模,リスク及び適用範囲に従って,プ

ロジェクトとして管理することが望ましい。

サービス提供者は,

新規サービス又はサービス変更の財務的,

組織的及び技術的影響の可能性に加えて,SMS への潜在的影響を検討することが望ましい。

サービス提供者は,プロジェクトの可能な限り早い段階から,変更管理プロセスとプロジェクト管理の

役割及び権限との強い連携を確実にすることが望ましい。

サービス提供者は,プロジェクトで次の事項を検討することを確実にすることが望ましい。

a)

サービス提供者の運用手順など,既存の支援の取決めへの影響

b)

既存のサービスレベルへの影響,及びサービス提供者がその影響を管理する能力

c)

サービスの変更又はサービスへの追加によって影響を受ける可能性のある,他の関係者との供給者支

援の合意,契約及び合意文書

d) 

サービスへの追加又はサービスの変更によって影響を受ける可能性のある,報告などのアウトプット

を含む,既存のサービスに対する顧客要求事項

e) 

展開のツール及び方法

5.2.5 

他の関係者による貢献 

他の関係者は,新規サービス又はサービス変更のサービスコンポーネントを提供することができる。新


29

Q 20000-2

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

規サービス又はサービス変更は,ソフトウェア,インフラストラクチャ,専門的技能又はその他のサービ

スコンポーネントの入手を伴うことがある。

他の関係者が新規サービス又はサービス変更に関与している場合,サービス提供者は徹底的なレビュー

を行うことが望ましい。レビューは,合意したサービスの要求事項を含め,他の関係者がコミットメント

を果たす能力を評価することが望ましい。レビューは,既存のサービス及び支援環境へのリスクも評価す

ることが望ましい。

サービスを稼働環境に受け入れるためには,支援要員の数,技術,試験,文書化など,要求事項を規定

する必要が生じることがある。

5.2.6 

リスクアセスメント 

サービス提供者は,プロセスの早期に,及び計画から稼働環境への受入れに至る各段階で,リスク,課

題及び軽減策のアセスメントを実施することの重要性を認識することが望ましい。

計画立案の段階で受入基準を開発するために,リスクアセスメントの結果を使用することが望ましい。

5.2.7 

サービス受入基準 

計画に含まれるサービス受入基準は,次の事項を含むことが望ましい。

a)

サービス提供者が,プロジェクトから新規サービス又はサービス変更を受け入れられるようにするた

めに満たすべき,サービス提供者の要求事項

b)

新規サービス又はサービス変更の支援に必要となる知識の移管,文書化,容量・能力,可用性,継続

性,セキュリティなど,新規サービス又はサービス変更の引渡し用のチェックリスト

c)

コミュニケーションのスケジュール,意識向上訓練,文書化などの顧客要求事項

サービス,SMS 又は顧客の事業活動に対するリスクが受容できず,軽減することもできない場合は,新

規サービス又はサービス変更を却下することが望ましい。

5.2.8 

サービスの廃止 

サービスを廃止する場合,そのことを,サービス廃止計画で計画し,文書化することが望ましい。計画

は,次の事項を含むことが望ましい。

a)

廃止が該当する条件

b)

廃止の目的及び成功のための要因

c)

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

d)

顧客,供給者,内部グループなど,全ての利害関係者の役割及び責任

e)

制限事項,リスク及び課題

f)

マイルストーン及び成果物

g)

活動の分類及び各活動の説明

h)

サービスの廃止と,サービス提供者の責任の終了とに関する合意した完了基準

i)

利用者がサービスを利用できなくなる期日及びサービスの廃止期日

j) 

他のサービスによる,廃止されるサービスと他のサービスとのインタフェースの取り扱われ方

k) 

機密情報の除去を含めた情報セキュリティの取決めのレビュー

サービス提供者は,未解決のインシデント,問題,利用者の要請事項,及び変更要求の詳細が顧客との

間で合意に至っていることを確実にすることが望ましい。この顧客との合意は,結果的に生じる処置を含

むことが望ましい。


30

Q 20000-2

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

全てのデータ,文書及びシステムコンポーネントの所有について,合意しておくことが望ましい。必要

な場合には,

データ又はその他のサービスコンポーネントへのアクセスに関する取決めに合意し,

計画し,

実施することが望ましい。保管,廃棄又は移管に関する取決めについても,合意しておくことが望ましい。

サービスの廃止の結果として要求される文書の変更についても特定し,その変更は,変更管理プロセス

を通じて行うことが望ましい。

サービスマネジメントの目的,活動及びサービスの廃止の結果は,顧客との合意文書に文書化すること

が望ましい。この合意書は,サービスの終了期日並びに役割及び責任の変更を含むことが望ましい。合意

書は,サービス提供者がどのように利用者データ,顧客情報,サービス文書,並びに影響を受けるインフ

ラストラクチャ,アプリケーション及びライセンスを管理するかについても,記載することが望ましい。

合意文書は,合意したサービスの廃止の受入基準と呼ぶことができる。

全て又は一部のサービスを他の関係者に移管する場合,その目的は,利用者へのサービスが無用な中断

なく継続することであることが望ましい。サービス提供者は,移管する前に,サービスの継続性又はサー

ビスの質へのリスクを特定するために,顧客及び他の関係者と連携することが望ましい。サービス提供者

は必要となる対策についての詳細な作業リスト,

及びその後に結果の評価文書を発行することが望ましい。

5.3 

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

5.3.1 

サービス提供者,顧客及び他の関係者が実施する活動 

サービス提供者は,早期から新規サービス又はサービス変更を提供するプロジェクトに関与することが

望ましい。早期に関与することで,要求された機能及び特徴が実運用に適切でないサービスにつながる設

計の決定を回避することができる。サービス提供者が早期に関与することによって,顧客との間で合意さ

れた要求事項に,新規サービス又はサービス変更の質に関する,少なくとも次の事項を含む基準が含まれ

ることを確実にすることが望ましい。

a)

サービスレベル,対応,及びパフォーマンスのその他の側面

b)

サービスの信頼性及び回復力(resilience)

注記  “resilience”は,一般に“回復力”又は“復元力”と訳され,ここではサービスが障害又は

災害に際し中断する状況下で迅速かつ柔軟にサービスを復旧させる能力のことである。

c)

セキュリティ管理策

d)

要求されるサービス継続の適切性

e)

変更又は新しい版のリリース及び展開の費用効率基準

f)

使いやすさ

5.3.2 

リスクマネジメント 

サービス提供者は,計画立案段階で完了した初期のリスクアセスメントの結果を設計段階で検討するこ

とが望ましい。設計は,そのアセスメントで特定されたリスクの影響を受けることが望ましい。サービス

提供者は,新規サービス又はサービス変更が稼働環境に移るとき,特定されたリスクのうちのどれが受容

可能であるかを設計段階で検討することが望ましい。ここでは,ある特定のリスクが次の事項に及ぼす,

潜在的影響を考慮することが望ましい。

a)

設計中のサービス

b)

サービス提供者の他のサービスに対するリスクの潜在的影響

c)

新規及び既存のサービスに依存する顧客

合意したサービスの質及び機能の要求事項に潜在的不適合が特定された場合,サービス提供者はリスク

を軽減することが望ましい。例えば,設計を変更するか,利害関係者がリスクを理解し,受容することを


31

Q 20000-2

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

確実にすることによる。

稼働環境へのサービスの受入れは,受入基準を満たさないサービスの潜在的影響の理解に基づくことが

望ましい。これには,他のサービスへの影響の理解を含めることが望ましい。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)

サービスレベルの管理,測定及び報告用にサービス提供者の組織内に設けられている既存のプロセス

に照らして,新規サービス又はサービス変更の適切性のアセスメントを行う。

新規サービス又はサービス変更に関するサービス提供者の計画は,要求される活動のいずれかに影響す

る可能性のある依存関係,時間及び資源の制約を含むことが望ましい。サービス提供者が外部当事者によ

って実施される活動に依存している場合,計画にこの依存関係を記載することが望ましい。依存して実施

される活動には,試験及び妥当性確認を含む。計画は,期間を守れない事態についても備えることが望ま

しい。

サービス提供者は,全ての活動の実施に必要となる人的資源,技術資源,情報資源及び財源並びにサー

ビスマネジメントの能力を特定し,提供することを確実にすることが望ましい。これらの資源及び能力が

サービス提供者の組織にない場合は,提供するまでの準備時間を含めて,それらを用意するためにどのよ

うな対策を講じる必要があるかを理解することが望ましい。計画立案の適用範囲には,新規サービス又は


32

Q 20000-2

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

サービス変更の提供に至るまでの初期設計,開発及び移行の活動を含めることが望ましい。

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)

ソフトウェア製品の保管,バックアップ,復旧及びアクセス管理の手順,並びにウイルス防護の管理


33

Q 20000-2

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

方法

サービス提供者がサービス又はサービスコンポーネントの設計又は開発を管理できない場合,サービス

提供者は,サービス又はサービスコンポーネントが期待に添うものになることを確実にするためにアセス

メントを行うことが望ましい。例えば,市販品の機能特性及び非機能特性は,要求事項及び期待を基準に

してアセスメントを行うことが望ましい。製品に必要な通常又は個別の設定は,計画し,設計することが

望ましい。

設計及び開発の計画立案に用いる文書は,一つの文書でも,別の文書の一部でもよく,複数の文書で構

成してもよい。

計画は定期的に見直し,該当する場合,修正することが望ましい。

5.4 

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

新規サービス又はサービス変更の移行は,変更管理プロセス,リリース及び展開管理プロセス及び構成

管理プロセスと連携することが望ましい。この取組みを採用して,変更の管理を新規サービス又はサービ

ス変更の移行に適用することを確実にすることが望ましい。

サービスの移行は,新規サービス又はサービス変更の構築,試験及び受入れを含むことが望ましく,そ

の後,リリース及び展開管理プロセスによって新規サービス又はサービス変更が稼働される。

移行については,顧客及び利害関係者を交えてレビューを行い,実運用の準備が整っていることを確定

することが望ましい。レビューで生じた決定は,顧客による新規サービス又はサービス変更の実運用への

受入れと合わせて記録することが望ましい。移行は,残りの活動が全て通常の実運用の一部となっている

という合意が得られるまで継続することが望ましい。移行の完了後,サービス提供者は,計画した成果に

照らして,新規サービス又はサービス変更が達成した成果を利害関係者に報告することが望ましい。

サービス受入基準については,サービス提供者及びその他の利害関係者がレビューすることが望ましい。

サービス移行前に満たしていない未処理の受入基準がある場合,これらの基準の欠如がサービスに対する

重要なリスクになるかどうかを判定することが望ましい。リスクが重要である場合,移行を遅らせること

が望ましい。ただし,リスク軽減策がある場合,又はリスクが重要でない場合は,移行を進める決定を下

してもよい。この場合は,サービス受入基準書に,未処理の処置及びそのオーナを記録することが望まし

く,これらの処置を達成することを確実にするための対策を講じることが望ましい。

サービス提供者は,合意した受入基準に照らして,顧客及び利害関係者による新規サービス又はサービ

ス変更の受入れを記録することが望ましい。

5.5 

文書及び記録 

新規サービス又はサービス変更の設計及び移行プロセスによって作成し,保持することが望ましい文書

及び記録には,次の事項を含めることが望ましい。

a) 

新規サービス又はサービス変更に関するサービスの要求事項

b)

新規サービス又はサービス変更の要求ごとに行うリスクアセスメント

c)

新規サービス又はサービス変更の設計,開発及び移行の計画

d) 

廃止するサービスに関する計画

e)

新規サービス又はサービス変更に関与している他の関係者の評価報告書

f) 

新規サービス又はサービス変更の設計仕様

g)

サービス受入基準

h)

期待される成果に照らして実現された成果を記述した移行報告書


34

Q 20000-2

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

変更管理プロセスの一部として開発され維持される,箇条 に属する新規サービス又はサービス変更に

関する方針に,このプロセスがアクセスできることが重要である。

5.6 

権限及び責任 

4.4.2.1

に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加

えて,新規サービス又はサービス変更の設計及び移行プロセスで必要となる権限及び責任には,次の事項

を含めることが望ましい。

a)

プロジェクトの成果物の提供及び管理,並びにサービス受入基準の達成を確実にすることに責任をも

つ,新規サービス又はサービス変更のマネージャで,通常はプロジェクトマネージャ

b)

方針,目的,及びプロセスを含む複数の視点で,SMS に対して提案された新規サービス又はサービス

変更の案の影響を評価できるグループ

c)

b)

と同じこともあるが,全ての新規サービス又はサービス変更の要求事項の計画立案,及び新規サー

ビス又はサービス変更の提供の受入れに関与することがあるグループ

d)

全ての新規サービス又はサービス変更の要求事項の文書化及び合意,並びに新規サービス又はサービ

ス変更の提供の受入れに責任をもつ,顧客及び事業者の代表

サービス提供プロセス 

6.1 

サービスレベル管理 

6.1.1 

要求事項の意図 

SLM

プロセスは,合意したサービスを提供し,サービス目標を満たすことを確実にすることが望ましい。

全てのサービスについて,具体的で,測定可能な目標を立てることが望ましい。SLM プロセスは,合意し

たサービス及びサービス目標が顧客が容易に理解できるように,文書化することを確実にすることが望ま

しい。

6.1.2 

概念 

SLM

プロセスは,提供されるサービスの定義,合意,文書化,監視,報告及びレビューを行うことが望

ましい。サービスの提供が達成可能であり,管理され,顧客要求事項及び事業ニーズに整合したものであ

ることを確実にするために,SLM プロセスは,事業関係管理(以下,BRM という。

)プロセス及び供給者

管理プロセスと緊密に連携する。

SLM

プロセスは,サービス提供者にサービスを提供する供給者管理プロセスと BRM プロセスとの間の

統合を可能にすることが望ましい。

SLM

プロセスは,提供されるサービス及びサービス目標が事業ニーズ及び顧客要求事項に整合している

ことを確実にするために,供給者管理プロセス及び BRM プロセスと緊密に連携する。

供給者管理プロセスは,供給者と合意したサービス目標が SLM プロセスと,サービスのレビューが行

われることを確実にするその他の要求された管理情報とに整合することとを確実にすることが望ましい。

さらに,SLM プロセスは,供給者管理プロセスに,供給者との合意に影響する変更の詳細を提供するこ

とが望ましい。例えば,供給者との契約を変更しなければならないことを意味する新規サービスの要求事

項である。プロセスのガバナンスに責任をもつサービス提供者と,サービス提供者に代わってプロセスを

運用する供給者とのインタフェースに影響するプロセス及び手順の変更も,その一例である。

SLM

プロセスは,BRM プロセスに,顧客要求事項を満たすための合意したサービス目標,及び顧客サ

ービスのレビューが行われることを確実にするための,他の必要な管理情報を提供することが望ましい。

SLM

プロセスは,サービスレベルの要求事項文書によって,新規サービス又はサービス変更の要求事項


35

Q 20000-2

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

に関して交渉し,合意し,文書化することが望ましい。次に,運用サービスに関する署名入りの SLA を作

成して,サービスのライフサイクル全体でその要求事項を管理し,レビューすることが望ましい。

注記  SMS における SLM プロセス及び他のプロセスのインタフェースの例は,附属書 に記載して

いる。

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 に規定する変更管理プロセスの負荷が最小化される。

さらに,サービスカタログはサービスと支援サービスとの依存関係を示すことが望ましい。例えば,事

業者のサービスが,電子メール,セキュリティ又はネットワークサービスのような,幾つかの請負サービ


36

Q 20000-2

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

スに依存している場合がある。これ以外に,供給者,又はサービス提供者の直接的な管理下にない内部グ

ループによって提供される,サービスコンポーネントに依存しているサービスの例がある。

サービスカタログは,顧客の期待を設定するための主要な文書であり,顧客と支援要員との双方に広く

利用可能であることが望ましい。

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 か所にまとめられている用語集


37

Q 20000-2

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

は,サービスカタログを含め,全文書に共通であることが望ましい。これが可能となるのは,参照される

文書も変更管理プロセスの管理下に置かれている場合だけである。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 

他の関係者の管理 

サービス提供者は,顧客が供給者及び顧客の両方として活動することがあると認識することが望ましい。

例えば,顧客の組織の専門家グループは,サービスコンポーネントを提供することがあるが,サービス提


38

Q 20000-2

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

供者の 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 

要求事項の説明 

サービスの報告に関する要求事項は,顧客と経営者との間で合意し,記録することが望ましい。報告書

は,数種類のものを作成することが望ましい。これには,事後報告書及び事前報告書が含まれる。事後報

告書は,何が起きたかを,それが起きた後に示す。事前報告書は,重要な事象について警告し,それによ

って予防処置をとることが可能となる。例えば,顧客に影響を及ぼすインシデントの発生を予防する目的

で,事業上重要なサービスのための冗長性を強化する必要性を特定する報告書がある。それ以外の種類の


39

Q 20000-2

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

報告書には,スケジュール及び予測報告書がある。これらは計画した活動を示す。

サービス提供者は,顧客及び経営者のために,少なくとも次の事項を含む報告書を作成することが望ま

しい。

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 

概念 

サービス継続及び可用性管理プロセスは,サービス障害又は災害の予防及びそこからの復旧,並びにサ


40

Q 20000-2

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

ービスの要求事項を満たすために十分なサービスの可用性の提供を確実にすることを含む。

サービス提供者は,サービス継続及び可用性管理プロセスを,関連する二つの独立したプロセスとして

運用してもよい。別の方法として,サービス提供者は,それらを単一のプロセスとして運用してもよい。

その決定は,サービス提供者の状況に基づくことが望ましく,SMS の一部として文書化することが望まし

い。

サービス継続及び可用性管理プロセスは,プロセスの事後対応的側面及び事前予防的側面の両方,並び

に合意したサービスの事業上の重要性の優先度付けを考慮することが望ましい。また,サービス継続及び

可用性管理プロセスは,サービス提供者によるサービスの監視,管理,レビュー及び改善,並びに該当す

る場合は,顧客への報告を可能にするデータを取り込むことが望ましい。

サービス提供者は,合意した要求事項を満たすことができることを確実にするために,効果的な計画を

立てることが望ましい。これらの要求事項は,平常の状況及び重大なサービスの停止後の状況の両方の下

での可用性及び継続に関する要求事項を含む。計画は,サービスレベルの増減対策,予想される活動のピ

ーク,並びにサービス継続及び可用性に関する将来の事業ニーズに対処するための新規又は変更された要

求事項の理解を含むことが望ましい。

6.3.3 

要求事項の説明 

6.3.3.1 

リスクアセスメント及びリスクマネジメント 

サービス継続及び可用性管理プロセスの主要な特徴は,リスクアセスメント及びリスクマネジメントで

あることが望ましい。リスクアセスメントは,重大なサービスの停止の事業影響度分析を含むことが望ま

しい。

サービス継続及び可用性の要求事項は,合意したサービスの要求事項,事業影響度分析を実施した結果,

顧客の事業上の優先度,方針及び計画,SLA 並びにアセスメントを行ったリスクに基づいて特定し,合意

することが望ましい。サービス提供者は,重大なサービスの停止があった場合に,合意したサービスレベ

ルが維持されることを確実にするために設計された効果的な計画と合わせて,十分なサービス能力を維持

することが望ましい。

重大なサービスの停止後にサービスレベルの維持を確実にするためには,顧客,供給者など,他の関係

者の管理下にあるサービスの実運用の要素を考慮することが望ましい。

平常のサービス及び重大なサービスの停止後に関するサービス継続及び可用性の要求事項には,少なく

とも次の事項を含めることが望ましい。

a)

アクセス権。平常の状態でのアクセス権を誰がもち,重大なサービスの停止後に,限定されたサービ

スに対する最優先のアクセス権を誰がもつかなど。

b)

応答時間。平常の状況及び重大なサービスの停止後の状況での応答時間など。サービスごとに許容で

きる応答時間はどれほどか,また合意した応答時間の達成を確実にするためにはどのような処置をと

ることが望ましいかについて,顧客を交えて定義し,合意することが望ましい。

c) 

全体(end-to-end)の可用性。例えば,平常のサービス時に完全なサービスを提供するために必要とな

るコンポーネントに要求される可用性はどれほどか。重大なサービスの停止後,個別のサービスを平

常のパフォーマンスに復帰させる優先度をどのように定めることが望ましいか。

6.3.3.2 

サービス継続方針 

サービス提供者にとって,サービス継続の義務を果たすための一般的な取組みを定義した方針を策定し,

維持することが役立つ。サービス継続方針の適用範囲は,SMS の適用範囲と一致することが望ましい。

方針は,各サービスに要求される回復力(resilience)に対する実際の回復力(resilience)を決定し,サ


41

Q 20000-2

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

ービスの事業上の重要性に整合した改善の機会について優先度付けを行う,一貫した方法を定義すること

が望ましい。

サービス継続方針は,サービス継続計画の適用範囲内でサービス提供者の継続計画の立案活動を促進す

ることが望ましい。

方針は,合意したサービスの要求事項を満たすために必要な役割,活動及び責任に対処することが望ま

しい。

方針は,サービス継続及び可用性管理プロセスと,他のサービスマネジメントプロセスとのインタフェ

ースを定義することが望ましい。

サービス継続及び可用性管理プロセスと SMS の他のコンポーネントとの

インタフェースに関する情報を参考として

附属書 に記載する。

方針は,合意したサービス時間及び事業上重要な期間を考慮することが望ましい。サービス提供者は,

顧客グループ及びサービスごとに,次の事項を含む要求事項を個別に特定することが望ましい。

a)

サービスの停止の許容可能な最長継続期間

b) 

サービスの品質低下の許容可能な最長期間

c)

サービス復旧期間中の,許容可能なサービス品質低下レベル

合意するサービス時間及び事業上重要な期間は,月末,年末,休日期間など,個別の事業サイクル及び

それに関連する重要性に関連して定義することが望ましい。

サービス提供者がサービス継続方針に基づいてプロセスを指導する場合,サービス継続方針については,

合意した間隔で,少なくとも年に 1 回,レビューすることが望ましい。方針の変更は,サービス提供者と

顧客との間で正式に合意することが望ましい。

6.3.3.3 

サービス継続及び可用性の計画 

サービス継続方針が設けられている場合,サービス提供者は,その方針をサービス継続戦略に整合させ

ることができる。サービス継続戦略は,サービスの事業影響度分析に基づいたサービスの重要性にふさわ

しいことが望ましい。また,サービス提供者は,サービス継続戦略のインプットとして他のサービスマネ

ジメントのプロセスから関連情報を収集することが望ましい。

戦略が定義された場合は,戦略と矛盾する継続性のリスクを特定し,それを管理する管理策を定義する

ため,又はリスクのレベルが受容できない場合は軽減処置を開始するために,リスク分析を実施すること

が望ましい。

サービス提供者は,合意した要求事項を満たすことを確実にするために設計された実行可能な計画と合

わせて,十分なサービスの能力を維持することが望ましい。

サービス提供者は,サービス継続及び可用性の計画,復旧計画及び手順,並びにサービス継続試験の方

針を策定することが望ましい。サービス継続計画及び試験の方針は,主要な事業機能及びプロセスに対す

る重大な中断の影響を低減するために設計することが望ましい。

サービス継続計画は,サービス継続方針に定義される要求事項,事業影響度分析及びリスクアセスメン

トに基づくことが望ましい。

継続的運用では,サービス継続の教育,認識及び教育・訓練,レビュー並びに監査のために,サービス

継続の試験及び変更管理プロセスとの連携に関する要求事項を定義することが望ましい。サービス継続計

画は,定期的に試験を行うことが望ましく,発動の責任は明確に割り当てることが望ましい。サービス継

続試験は,少なくとも年に 1 回,又は大きな事業変更の都度,実施することが望ましい。全ての関係者に

向けて,定期的な講習会を開くことが望ましい。サービス継続及び復旧計画の保管に関しては,定義され,

管理された配付方針があることが望ましく,復旧に必要な,全ての重要なバックアップ媒体,文書及びそ


42

Q 20000-2

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

の他の資源は遠隔地に保管することが望ましい。

サービス提供者は,次の事項を確実にすることが望ましい。

a) 

サービス継続計画で,サービスとサービスコンポーネントとの依存関係を考慮する。

b)

サービス継続計画及びサービス継続を支援するために必要なその他の文書を記録し,維持する。

c)

サービス継続計画を発動する責任を明確に指定し,計画で,方針の復旧要求事項別にとる処置の責任

を割り当てる。

d)

重大なサービス障害又は災害の後に,サービス復旧に必要なデータ,文書及びソフトウェアのバック

アップ,並びに機器及び要員が速やかに利用可能である。

e)

サービス継続に関する文書,例えば,サービス継続計画及びスケジュール,連絡先リスト,CMDB な

どが,中断中でもアクセス可能である。

f)

要員が,計画の発動及び/又は計画の実施時の役割を理解する。

g) 

該当する場合,供給者及び復旧サイトの提供者と待機に関する取決めを交わしておく。

サービス継続計画及び契約書などの関連文書は,システム又はサービスの変更が承認される前,及び重

要な新規顧客要求事項又は修正された顧客要求事項に関する合意の前に,影響についてアセスメントを行

うことが望ましい。また,サービス継続計画及び関連文書については,少なくとも年に 1 回,レビュー及

び試験を行うことが望ましい。

可用性計画を策定して,公表することが望ましい。可用性計画は,現在と将来との両方での,事業上の

可用性の要求事項を満たすために必要な,事業ニーズ及び顧客要求事項,設計要求事項,技術仕様,及び

プロジェクト計画活動を特定することが望ましい。可用性計画に文書化されている将来の可用性に関する

予想は,計画外の非可用性の可能性を軽減するための予防処置案を含むことが望ましい。可用性計画は,

定期的に,少なくとも年に 1 回,及び重大な変更後に,レビューし,改訂することが望ましい。

新規サービス又はサービス変更の可用性の計画及び設計は,事業に対するサービスの重要性に基づくこ

とが望ましく,費用と受容可能な事業上のリスクとの釣合いがとれていることが望ましい。

全てのサービス及びサービスコンポーネントの非可用性は,記録し,調査することが望ましく,今後の

発生の影響及び/又は発生の可能性を低減するために,適切な処置をとることが望ましい。

6.3.4 

サービス継続及び可用性の監視及び試験 

6.3.4.1 

サービス継続試験 

サービス継続試験は,大きな事業変更及びサービスの環境に対する変更があった後に実施することが望

ましい。その頻度は,サービス提供者の状況に基づくことが望ましい。その頻度は,サービス継続計画が

効果的で,変化するシステム,プロセス,要員及び事業ニーズが進化しても引き続き効果的であるという

保証を得るために十分なものであることが望ましい。サービス継続試験の適用範囲は,中断後の正常なサ

ービス運用への復帰を含むことが望ましい。

サービス継続試験には,顧客及びサービス提供者が,合意した一連の目的に基づいて共同で参加するこ

とが望ましい。該当する場合,他の関係者も含めることが望ましい。試験での失敗は,サービスを改善す

るための計画へのインプットとして文書化し,レビューすることが望ましい。

サービス継続試験後のレビューは,試験の目標及び目的の達成のアセスメントを行い,弱点部分又は改

善の機会を特定するために実施することが望ましい。

6.3.4.2 

可用性の監視及び試験 

サービス継続及び可用性管理は,合意した可用性計画に従って,次の事項を行うことが望ましい。


43

Q 20000-2

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

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 

文書及び記録 

サービス継続及び可用性管理プロセスで作成し,保持することが望ましい文書及び記録には,次の事項

を含めることが望ましいが,これらだけに限らない。


44

Q 20000-2

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

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)

予算を策定し,サービスマネジメントのプロセスで利用する。


45

Q 20000-2

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

d)

費用又は予算の予想外の差異を特定し,管理する。

e)

予算期間全体でサービス提供資金が適切に供給されるように予算を順守する。

f)

プロセス及び手順が引き続き有効であることを確実にするために,予測,予算及び費用を定期的にレ

ビューする。

6.4.2 

概念 

予算業務及び会計業務プロセスは,サービス及びサービスコンポーネントの財務的側面を管理すること

が望ましい。サービスの予算業務及び会計業務プロセスは,サービスの実運用と,サービス変更及び改善

のための資金提供との両方を支援する情報を提供することが望ましい。サービスの予算業務及び会計業務

プロセスは,サービスの提供の費用を追跡でき,サービスが適正な価格であり,予算に従うことを確実に

することが望ましい。

多くの財務上の決定責任は,SMS の適用範囲外となることがある。提供する財務情報の詳細さのレベル,

また,どのような形式で,どれほどの頻度で提供するかに関する要求事項は,サービス提供者以外の当事

者が指定することがある。それ以外の規制上又は組織固有の要求事項も,定義された方針及び手順の幾つ

かに影響することがあるので,考慮することが望ましい。採用する全ての会計業務の実践は,サービス提

供者の組織のより広い会計業務の実践に整合させることが望ましい。

サービスの予算業務及び会計業務プロセスは,財務管理の他の側面が組織の別の部署で実施されるかど

うかに関係なく,サービス提供者が実施することが望ましい。サービスの予算業務及び会計業務プロセス

は,サービス提供者の組織の財務プロセスに整合し,そのプロセスから情報を受領することが望ましい。

6.4.3 

要求事項の説明 

6.4.3.1 

方針 

サービス提供者は,サービスの財務管理のために文書化された方針及び手順をもつことが望ましい。方

針は,

サービスの予算業務及び会計業務プロセスによって達成する目的を定義することが望ましい。

また,

方針は,目的を達成することを確実にするために必要な詳細を定義することが望ましい。そのためには,

方針は,予算で費用の割当てに使用する費用の種類,及びどのように間接費を配賦するかについての説明

を含むことが望ましい。

各サービスの予算及び会計の分析のための基準を定義することが望ましい。基準が定義された場合,サ

ービスの費用に関して定期的な監視ができ可視性が得られることを保証するために,予算項目及び会計項

目にその基準を適用することができる。これは,サービスの費用の追跡に利用することができ,市場で同

じサービスを得るときの費用との比較を可能にする。

サービスの予算業務及び会計業務プロセスに提供される資源は,方針に定義される財務上の詳細のため

に,顧客,サービス提供者,供給者及び他の利害関係者のニーズに基づくことが望ましい。

6.4.3.2 

費用の種類 

サービス提供者は,サービスマネジメントに役立つ予算の費用項目の分類を選択することが望ましい。

例えば,サービス提供者は,6.1 のサービスカタログに定義されるサービス及びそのコンポーネントに一致

した費用のモデルを定めることが望ましい。費用の種類は,サービスの一部を形成する各費用に割り当て

ることが望ましい。費用のモデルは,サービス提供者が,様々なレベルのサービスの質又は様々なサービ

スの選択肢の費用/便益をより正確に予測することができるようになるため,有用である。費用のモデル

は,各サービスの提供に係る全費用を実証できることが望ましい。

サービス提供者は,次のような費用の種類も検討することが望ましい。

a) 

サービスの提供に使用する資産


46

Q 20000-2

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

b)

一次サポートとして知られるサービスデスクなどの共有資源

c)

オフィスのスペースなどの間接費

d)

供給者が提供するサービス

e) 

サービスマネジメント要員を雇用する費用

適切な費用の種類を特定する場合,費用の種類から引き出される詳細な会計情報の便益と,必要となる

大量の情報を集め,それを管理する困難さとの釣合いをとることが望ましい。費用の種類は,簡単かつ確

実に測定できる分類に基づくことが望ましい。例として,ハードウェア費用,ソフトウェア保守費用,人

件費などが挙げられる。

6.4.3.3 

間接費の配賦及び直接費の割当て 

間接費の配賦は,定額,定率,提供されるサービスについて合意した可変要素の規模に基づくものなど,

様々な仕組みに基づいてもよい。

サービス提供者は,配賦を管理する費用が,詳細な費用の配賦が可能になることの便益と釣り合うよう

に,組織にとって適切な間接費の配賦及び直接費の割当ての方法を用いることが望ましい。それ以外に検

討してもよい要因は,次の事項を含む。

a)

サービスの性質,範囲,及び消費又は利用

b)

顧客の組織の粒度。例えば,事業単位が一つだけであるか,部門に分かれているか,又は地域別にな

っているか。

c) SLA

,並びにサービス及びサービスレベルへの費用の配賦

d)

供給者が提供するサービス

6.4.3.4 

予算業務 

予算業務のための費用及び収入の予測では,予算期間中の,計画されたサービス変更を考慮することが

望ましい。該当する場合,季節的変動,並びにサービスの費用及び課金に対して計画した短期の変更につ

いては,これを理解し,予測予算に含めることが望ましい。予算業務及び費用の追跡は,年間を通してサ

ービスレベルを維持できるように,サービスの運用及び改善の計画立案を支援することが望ましい。合意

した期間,サービスを合意したサービスレベルに保つために必要な資源を賄うために十分な,計画された

支出を予定しておくことが望ましい。実費と支出予算額との差異を特定し,管理するための手順も定めて

おくことが望ましい。

6.4.3.5 

会計業務 

会計活動は,合意した詳細さで費用を追跡するために,合意した期間において利用することが望ましい。

サービスを提供することの決定は,費用と効果との比較に基づくことが望ましい。費用のモデルは,サー

ビス提供の全費用を明示できることが望ましい。

会計報告書は,支出と回収との過不足額を示すことが望ましい。会計報告書は,理想的には,サービス

レベルが低いものの費用,又はサービスの停止による費用を計算するために十分な情報を提供することが

望ましい。サービスレベルが低いもの又はサービスの停止による費用を計算するために,サービス提供者

はサービス提供に必要となる資源の費用について明確に理解しておくことが望ましい。これは,要員,コ

ンポーネント,設備,及び他の関係者が提供するサービスの側面を含むことが望ましい。サービス提供者

は,継続期間,時期(日,週,月又は年),及び問題となっているサービスに応じて,サービスの停止が

事業に与える影響についても明確に理解しておくことが望ましい。この情報は,事業影響度分析で得るこ

とができる。


47

Q 20000-2

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

会計報告書は,特定のサービスを支援する 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 

概念 

資源は,現行の合意した容量・能力及びパフォーマンスの要求事項を満たし,将来の要求事項の達成に

備えるために,釣合いを保つことが望ましい。

容量・能力管理プロセスは,事後対応的活動と事前予防的活動との両方を含むことが望ましい。事後対

応的活動は,運用中の容量・能力の継続的な監視,調整,分析及び改善を重視することが望ましい。プロ

セスの事前予防的活動の側面は,合意した将来の事業需要を満たす計画を中心とすることが望ましい。

容量・能力管理プロセスは,容量・能力の要求事項に合意し,それを予測し,満たすことを確実にする

ために,計画を策定することが望ましい。これらの計画は,事業予想及び推定作業負荷を特定の容量・能

力の要求事項に変換することが望ましい。これは,次の三つの重点分野を容量・能力管理プロセスに組み


48

Q 20000-2

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

込むことによって促進することが望ましい。

a)

顧客及びサービス提供者の事業計画及びニーズを将来のサービスの要求事項に定量化することを中心

とする事業の容量・能力管理

b)

サービスの計画及び管理,並びに合意したサービス目標の全てを満たすことを確実にするための,サ

ービスの計画及び管理並びに資源の支援を中心とするサービスの容量・能力管理

c)

サービスの効果的な支援,及び合意したコンポーネントの目標の達成を確実にするための,運用資源

及びコンポーネントの計画,並びに管理を中心とするコンポーネントの容量・能力管理

6.5.3 

要求事項の説明 

6.5.3.1 

容量・能力管理活動 

容量・能力管理活動は,容量・能力の使用状況の監視,容量・能力データの分析などの日々の運用作用,

サービス目標を基準にしたパフォーマンスの管理,及び将来の容量・能力の要求事項のための計画を包含

する。

容量・能力管理プロセスの活動は,次の事項を含む。

a) 

容量・能力の要求事項のアセスメント,文書化及び合意,作業負荷及びパフォーマンスのベースライ

ンの定義,並びに作業負荷及びパフォーマンスのしきい(閾)値及びきっかけの設定。

b)

新規サービス又はサービス変更の容量・能力の要求事項のアセスメント,文書化及び合意。

c)

容量・能力管理プロセスは,パフォーマンス及び/又は容量・能力が要因となっている場合,新規サ

ービス又はサービス変更の設計に関与し,コンポーネント及び資源の調達に関して推奨を行うことが

望ましい。費用と容量・能力との釣合いをとる必要があることから,容量・能力管理プロセスは,解

決策案の候補の費用を調べ,最も適切な,費用対効果の高い解決策を推奨することが望ましい。

d) 

新しい容量・能力の要求事項のための活動は,計画立案,支援チーム及び事業グループから得られる

インプットに基づくことが望ましい。これには,新規プロジェクトのインフラストラクチャ導入の計

画立案,及び老朽化したインフラストラクチャのコンポーネントの交換の予測を含めることが望まし

い。

e)

コンポーネントの活用及びサービスのパフォーマンスを自動的に管理し改善するための,容量・能力

のしきい(閾)値,警告及び警報の設定,監視及び使用。

f)

容量・能力データベースと言われることが多いリポジトリへの,容量・能力管理プロセスが使用する

データ及び情報の保存。このリポジトリは,容量・能力管理プロセスの主要な要素とすることが望ま

しい。容量・能力データベースに含まれるデータ及び情報は,全ての容量・能力管理活動で分析され

ており,次に示す技術の全分野から得られる,事業,サービス,資源又は利用度,及び財務に関する

データを含むことが望ましい。

1) 

事業データ:現在及び将来の事業ニーズに関する信頼性の高い情報

2) 

サービスデータ:トランザクション応答時間,トランザクション量及び作業負荷量(これらだけに

限らない。

3)

コンポーネントの利用状況に関するデータ:コンポーネントが利用されることが望ましいレベルの

限界は,文書化しておくことが望ましい。この利用レベルを超えた場合,資源が過剰に利用され,

その資源を使用しているサービスのパフォーマンスが損なわれる。

4) 

容量・能力管理プロセスが利用する他のデータ:障害及び特定された弱点,冗長性及び予備の容量・

能力,資源,コンポーネント,サービスのしきい(閾)値及び許容誤差,現在,過去及び予測でき

るスループット及びパフォーマンス,並びに実際の達成度と予想達成度との比較を含める。


49

Q 20000-2

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

g)

多くのサービスマネジメントのプロセスに貴重な情報を提供する,容量・能力及びパフォーマンス報

告書の作成。容量・能力報告書は,利害関係者が参照できるように,容量・能力データベースにまと

めて保存することが望ましい。これらの報告書には,次の事項を含めることが望ましい。

1) 

コンポーネントのパフォーマンスがどれほどで,その容量・能力のどれほどが利用されているかを

説明したコンポーネント単位の報告書及び情報

2) 

サービス及びそれを構成するコンポーネントが,サービス目標及び制限の全体に対して,どのよう

なパフォーマンスを示しているかを説明したサービス単位の報告書及び情報。これらの報告書は,

容量・能力及びパフォーマンスに関する顧客サービス報告書並びに SLM 報告書の基礎となる。

3) 

特定のコンポーネント,又はサービスの容量・能力及びパフォーマンスが,いつ許容できないもの

となったかを,マネジメント及び技術要員に示す例外報告書も作成することが望ましい。特に例外

報告書は,SLA の目標を達成したか又は違反したかを判定するとき,SLM プロセスの役に立つこと

が望ましい。インシデント及びサービス要求管理プロセス,並びに問題管理プロセスは,インシデ

ント及び問題の解決で例外報告書を利用することができる。

h)

将来のコンポーネント,並びにサービスの容量・能力及びパフォーマンスの予想は,採用する技法及

び技術に応じて様々な方法で行うことが望ましい。例として次の事項が含まれる。

1) 

ベースラインのモデル化は,モデル化の第一段階である。これは,達成されているパフォーマンス

を正確に反映する,ベースラインのモデルの作成に使用する。このベースラインのモデルが作成さ

れた場合,予測モデル化の開発が可能となる。

2)

傾向分析は,収集された資源の活用及びサービスのパフォーマンス情報を使って完了する。

3) 

分析モデル化は,コンピュータシステムのパフォーマンスを分析するために数学的手法を用いる。

4) 

シミュレーションのモデル化は,所定のシステム構成を基準にしたトランザクション到着率など,

離散事象のモデル化を伴う。

6.5.3.2 

容量・能力計画 

容量・能力計画は,実際のパフォーマンス,予想される事業上の容量・能力ニーズ及びサービスの要求

事項を文書化することが望ましい。これは少なくとも年に 1 回,又はサービスの変更の度合い及びサービ

スの量が要求する場合は,より頻繁に作成することが望ましい。容量・能力計画は,事業上の要求事項を

満たすための合意したサービス目標及び費用の選択肢を達成する目的で,推奨される解決策を文書化する

ことが望ましい。

容量・能力計画は,次の事項を含むことが望ましい。

a) 

現在の及び将来のサービス利用量で,理想的には,容量・能力需要に影響する機会に関する推奨を含

む。

b)

現在の及び将来の資源利用量及びパフォーマンスで,どの資源がどのサービスを支援するかの理解を

含む。

c)

災害時の推定作業負荷,容量・能力の要求事項など,可用性,サービス継続及びサービス目標に関す

る合意された要求事項が容量・能力及びパフォーマンスに及ぼす影響

d)

経営統合の結果としての,サービスの容量・能力の増加を提供するために必要な,日数,費用など,

サービスの容量・能力を拡大するための期間,しきい(閾)値及び費用

e)

関連する事業計画,シナリオ及び事業活動のパターンの概要

f)

利用できる場合は利用者情報を含む,事業活動の変更の概要

g)

容量・能力計画の詳細の計算に用いる方法,前提及び情報の詳細


50

Q 20000-2

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

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 

概念 

情報セキュリティは,組織の情報,並びに情報の格納,転送及び処理に関連して使用される,あらゆる

資源を識別し,制御し,かつ,保護するように設計された方針及び手順を体系にしたものであることが望

ましい。

経営者は,明確に定義された情報セキュリティ管理目的が備えられ,それが事業ニーズに整合すること

を確実にすることが望ましい。


51

Q 20000-2

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

サービス提供者及び顧客は,情報資産を,価値,機密性又は事業に与える影響に応じて分類することが

望ましい。サービス提供者及び顧客は,各分類別に,リスクの受容レベルを定義し,合意することが望ま

しい。

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

プロセスは,稼働環境の情報セキュリティリスクを特定するために,定期的にリスクアセスメント


52

Q 20000-2

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

を実施することが望ましく,次にそれを文書化し,特定されたリスクの影響を予防又は最小化するための

具体的な管理策を実施することが望ましい。また,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)

定期的な監査は,確立された情報セキュリティ方針及び管理策の適合性を確認するために実施するこ


53

Q 20000-2

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

とが望ましい。

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)

情報セキュリティ管理策を維持する要員


54

Q 20000-2

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

関係プロセス 

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 

一般 

サービス提供者は,サービス間の依存関係を完全に理解するために,その顧客,他の利害関係者,供給

者及び従属する再請負契約先供給者を特定し,文書化することが望ましい。例えば,インターネットを利

用したサービスは,セキュリティが保たれたウェブポータル及び暗号化機能を提供するサービスに依存し

ている。利害関係者は,利用者のグループ及び事業単位を含むことがある。

サービス提供者は,提供するサービスの種類に従って顧客を分類することが望ましい。特性の類似した

顧客は,効率性及び有効性を改善するために類似の方法で分類してもよい。サービス提供者が定義するプ

ロセスは,細かいレベルでは,顧客の種類ごとに異なることがある。

サービス提供者は,顧客の単一窓口として個人を特定することが望ましく,その個人が顧客ごとに関係

及び顧客満足度の管理に責任をもつ。この個人は,専任で顧客関係を管理するように選んでもよいし,該


55

Q 20000-2

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

当する場合,その役割を別の役割と兼務してもよい。

BRM

プロセスと SLM プロセスとが密接な関係にあるために,事業関係マネージャの役割及びサービス

レベルマネージャの役割を同一人物が果たすことができる。同一人物が二つの役割を果たす場合は,役割

の異なる性質を役割記述書で区別することが望ましい。BRM プロセスは,

戦略的なものであるのに対して,

SLM

プロセスは運用又は戦術に関わるものである。これほど視点が異なる二つの役割を,同一人物が果た

すことのリスクについても管理することが望ましい。

顧客との間で成立するコミュニケーションの仕組みは,議事録をとる正式な会議に加えて,臨時会議及

び非公式の会議を含むことが望ましい。これらのコミュニケーションは,顧客との関係を築き,事業上の

優先度及び目的の変更を特定し,サービス提供者が行動を起こすきっかけとなることが望ましい。

コミュニケーションの仕組みは,事業ニーズ,顧客要求事項及び重大な変更を含めて,サービスが運用

される事業環境の理解を助けることが望ましい。

サービス提供者は,

特定されたニーズに対応するために,

この情報を用いることが望ましい。

サービス提供者は,顧客に関する情報を追跡し,管理するためのツールを使用することができる。

7.1.3.2 

顧客サービス管理のレビュー 

サービス提供者は,顧客満足度,戦略的方向性及びサービスのパフォーマンスの重大な例外に関するレ

ビューを行うために,顧客との正式な会議を開催することが望ましい。このような会議は,SLA 及びパフ

ォーマンスのレビュー,サービス提供者の組織の変更,並びに顧客の組織の変更を含むことが望ましい。

会議には,全ての当事者の代表が出席することが望ましい。会議は前もって予定を組み,定期的に,少

なくとも年に 1 回開催することが望ましい。実際の頻度は,サービスの要求事項の変更の度合い,新規サ

ービスなどの重大なプロジェクト及び提供するサービスの質によって変更することが望ましい。サービス

提供者及び顧客が頻繁な変更を管理しているとき,又はサービスの質に懸念があるときは,少なくとも年

に 1 回よりも高い頻度で会議を開くことが望ましい。例えば,サービスの要求事項の頻繁な変更,新規サ

ービス又はサービス変更などの重大なプロジェクトがそれに当たる。もし顧客レビュー会議を年に 5 回以

上開くと,参加する管理責任者にとって会議の内容が不十分なものとなり,逆効果となることがある。

顧客レビューの成果は,既存のサービス又はサービスレベルに必要となる,新規サービス又はサービス

変更が特定されることである。サービス提供者は,SLA 及び契約の変更を,変更管理プロセスを通じて管

理し,成立済みの SLM プロセスに従うことを確実にすることが望ましい。

顧客要求事項からサービス変更までの,トレーサビリティを確立することが望ましい。

7.1.3.3 

顧客満足度 

サービス提供者は,顧客満足度を記録する正式な仕組みを定めることが望ましい。測定の頻度及び規模

は,前もって顧客との間で合意することが望ましく,これには調査対象となる利用者のサンプルを含める

ことが望ましい。このような活動は,多くの場合,インシデント/問題の解決後に,一次サポートとして

知られるサービスデスクが進めることがある。ただし,正しい顧客満足度の測定のためには,例えば,サ

ービス要求の数及び種類,実際の費用,認識された費用,提供されるサービスの事業価値などを含む,幅

広い測定を実施することが望ましい。改善の機会を特定するために,その結果を特定し,分析し,レビュ

ーすることが望ましい。

満足度調査結果は,満足度の傾向を追跡し,必要な課題又は改善が特定されるように,長期にわたって

測定することが望ましい。

サービスに関する苦情の対応手順書は,受け取ったサービスに関する苦情の記録,調査,処置,報告及

び終了を含むことが望ましい。手順書は,顧客が処置案又は解決案に合意しない場合,又はそれを受け入


56

Q 20000-2

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

れない場合に使用する,段階的取扱い手順を含むことが望ましい。苦情は,苦情が解決したと顧客が正式

に合意するまで,未解決にしておくことが望ましい。

サービス提供者は,サービスに関する正式な苦情の原因が何かを理解し,定義し,顧客との間で合意す

ることが望ましい。サービスに関する正式な苦情は,通常,極めて深刻であり,口頭ではなく書面で提出

される。サービスに関する正式な苦情は,顧客のマネージャがサービス提供者のマネージャに送付するこ

とが望ましい。インシデント又は問題は,苦情の原因となることがあるが,これ自体は苦情ではない。

苦情のレビュー結果は,顧客の意見が重大に受けとめられて,対処されていると分かるように,要約し

て顧客に報告することが望ましい。

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)

将来の事業上の要求事項の理解及び計画立案

この役割の名称は,事業関係マネージャが一般的だが,変わることがある。これ以外にも,顧客関係マ

ネージャ又はアカウントマネージャという肩書きが考えられる。サービス提供者は,状況に応じて,この


57

Q 20000-2

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

役割を別の役割と兼ねることもでき,また,チーム全体で実施することもできると認識することが望まし

い。

この役割を効果的に果たすために,サービス提供者は,サービス提供者自身の事業,技術,並びに顧客

の事業上の要求事項及び優先度に関する専門知識が必要であると認識することが望ましい。また,顧客要

求事項をサービス提供者の技術の専門家に周知させるために,この専門知識を用いることが望ましい。こ

の役割の複雑さは,細部への配慮及び複数の当事者と連絡をとる能力を,役割の重要な側面として認識す

ることが望ましいことを意味する。また,サービス提供者は,これらの責任が,若く経験の浅い役職レベ

ルの力量を超えていると認識することが望ましい。

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 回のレビ

ューをスケジュールに組むことが望ましい。レビューは,サービス又はサービスコンポーネントを調達す

るための事業目的が引き続き有効であるかどうか,また,供給者が合意したパフォーマンスを達成してい

るかどうかのアセスメントを,契約のサービス目標に照らして行うことが望ましい。

各契約を管理するための,明確に定義されたプロセスがあることが望ましい。契約修正のためのプロセ

スも,明確に定義しておくことが望ましい。この手順に変更があるときは,影響を受ける全ての供給者に

正式に通知することが望ましい。

契約が罰則又は報奨を含む場合は,その論拠を明記し,要求事項及びサービス目標との適合性を測定し,


58

Q 20000-2

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

報告することが望ましい。

供給者がサービスの一部を提供する場合は,サービス提供者は,供給者との契約に,該当する顧客要求

事項の達成に必要な全ての事項が含まれることを確実にすることが望ましい。これは,顧客にコミットメ

ントを示す前に確認し,文書化することが望ましい。供給者は,4.2 に規定するように,サービス提供者が,

供給者が運用するサービスマネジメントのプロセスのガバナンスをもつことを受け入れることが望ましい。

サービス提供者は,供給者が契約の全要求事項を満たし,その要求事項を一貫して満たしていることを,

効果的に確実にする質の高いプロセスを備えているという証拠を,あらかじめ定めた間隔で入手すること

が望ましい。これは,サービス提供者による供給者の監査という手段で達成してもよい。

再請負契約サービスに関する会議,レビュー及び監査の全結果について,改善の機会を特定するために

レビューすることが望ましい。

変更が必要な場合は,

変更管理プロセスに従って管理することが望ましい。

7.2.3.2 

供給者の詳細 

サービス提供者は,サービスごと及び供給者ごとに,次の情報を,その情報が契約に含まれていない場

合でも,記録しておくことが望ましい。

a)

サービス,役割及び責任の定義

b)

サービスの適用範囲及び能力

c)

供給者が満たすべき要求事項

d)

定義し,合意したサービス目標,サービス目標を達成しなかったときの罰則又は影響

e)

トランザクション回数,サーバの数,データベースの規模など,作業負荷の特性

f) SLA

の合意した例外基準

g)

契約管理プロセス,認可レベル及び契約解消の計画

h)

該当する場合の支払条件

i)

合意した報告のパラメタ及び達成したパフォーマンスの記録

7.2.3.3 

再請負契約先供給者の管理 

サービス提供者が全ての供給者と直接取引をしているのか,又は再請負契約先供給者に対する責任をも

つ統括供給者と取引をしているのかを明確にすることが望ましい。

サービス提供者は,統括供給者が再請負契約先供給者を正式に管理しているという証拠を,統括供給者

から入手することが望ましい。この証拠は,JIS Q 20000-1 の要求事項に従うことが望ましい。統括供給者

には,全ての再請負契約先供給者の名称,並びにその再請負契約先供給者の責任及び関係を記録するよう

に要求することが望ましい。この情報は,必要な場合には,サービス提供者に提供することが望ましい。

サービスの一部を提供している供給者及び再請負契約先供給者の例を,

図 に示す。これは,ISO/IEC 

20000-3

から転載したものである。


59

Q 20000-2

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

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

7.2.3.4 

契約紛争の管理 

サービス提供者と供給者との双方が,紛争を管理するためのプロセスに合意することが望ましい。これ

は,契約書の中で定義するか,又は言及して,必要に応じて実施することが望ましい。通常のコミュニケ

ーション手段で解決することのできない紛争については,段階的取扱いの経路を設けることが望ましい。

このプロセスは,紛争を記録し,調査し,対処し,正式に終了することを確実にすることが望ましい。

7.2.3.5 

契約の終了 

契約管理プロセスは,予定どおりの終了,又はそれより早いかの,いずれかの契約終了に関する規定を

含むことが望ましい。また,契約管理プロセスは,契約終了時の,他の組織へのサービスの移管について

も規定することが望ましい。契約終了条項は,サービス,費用,知的財産の所有,ハードウェア,ソフト

ウェアライセンス及びデータの廃棄又は移管に関する責任を明確にすることが望ましい。

7.2.4 

文書及び記録 

全ての供給者契約の承認済みの写しを,サービス提供者及び供給者が保有することが望ましい。契約に

は,サービスの定義を含めるか参照することが望ましく,供給者が提供する全てのサービスを対象とする

サービスマネジメントのプロセスを特定することが望ましい。複数の当事者が運用するプロセス間のイン

タフェースは,文書化することが望ましい。

サービス提供者は,次の事項も保有することが望ましい。

a) 

顧客,サービス提供者,統括供給者及び再請負契約先供給者を含めた,全ての利害関係者の組織の名

称,責任及びその関係

b)

定期的な契約レビュー会議の記録及びその結果とった処置並びに再請負契約先監査の報告書を含む,

サービス提供者が供給者を正式に管理していることを示す証拠

c)

b)

と同様に,統括供給者が正式に再請負契約先供給者を管理していることを示す証拠

7.2.5 

権限及び責任 

4.4.2.1

に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加

えて,供給者管理プロセスで必要となる権限及び責任には,次の要員を含めることが望ましい。

a)

供給者関係マネージャ。サービス提供者と個別の供給者との関係の管理に責任をもつように指名され

た個人。これには,契約及びパフォーマンスの管理を含む。複数の要員がこれらの活動に従事してい

る場合,供給者のパフォーマンスに関する情報は,一貫性があり,比較可能であり,観察され,かつ,


60

Q 20000-2

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

対応されることを確実にするための手順があることが望ましい。

b) 

各供給者内で定められた担当窓口。

解決プロセス 

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)

合意したサービス時間帯とそれ以外の時間帯との両方で,適切なコミュニケーション経路及び方法が

利用可能な状態である。

全てのインシデント及びサービス要求は,その優先度及びサービス目標のコミットメントに従って対応


61

Q 20000-2

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

できるように分類することが望ましい。インシデント又はサービス要求の種類による分類は,どの CI が影

響を受けるか,

次に,

解決又は実現に関与する必要のある要員を特定するために何が手がかりになるかの,

判断を含むことが望ましい。

優先度は,インシデント若しくはサービス要求を受け付けてから,又はその後可能な限り早く,顧客と

合意することが望ましい。優先度の決定は,問題となっているインシデント又はサービス要求の影響,及

び緊急度のアセスメントに基づくことが望ましい。

インシデント及びサービス要求は,セキュリティへの潜在的波及効果と,通常の運用対応に加えてセキ

ュリティインシデント対応手順を実施することが望ましいかどうかの決定とに関して,評価されることが

望ましい。例えば,運用要員は,情報セキュリティ担当要員又は法的機関の要員に連絡すべきかどうかを

決定する手順を定めておくことが望ましい。

サービス目標について討議し,その目標に合意することの一部として,インシデント及びサービス要求

の両方に関して,影響及び緊急度に基づいた優先度表を作成することが望ましい。優先度に基づいたイン

シデントの解決目標時間の例を,

表 に示す。インシデント及びサービス要求の両方に関して,数種の分

類の一つ一つに基づく目標の一般原則を採用することが望ましい。

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

影響

緊急度

重大

高 P1:2 時間で解決 P2:4 時間で解決 P3:1 日で解決 P4:2 日で解決

中 P2:4 時間で解決 P3:1 日で解決 P4:2 日で解決 P5:3 日で解決

低 P3:1 日で解決 P4:2 日で解決 P5:3 日で解決 P6:5 日で解決

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

となる。

8.1.3.2 

インシデント及びサービス要求のライフサイクル並びにデータの使用 

インシデント及びサービス要求管理プロセスの一部として,次の事項を定義することが望ましい。

a)

インシデント及びサービス要求のインプットの出所の識別

b)

インシデント及びサービス要求の記録の作成及び更新の責任

c) CMDB

,既知の誤りのデータベース,サービスカタログ,その他の関連文書及び記録など,適切な情

報源の使用

d)

問題管理プロセスとの関係/インタフェース

e)

きっかけ,機能又は階層の種類,及び発動権限を含めた段階的取扱いの規則

f)

変更要求を利用してインシデントの解決又はサービス要求の実現を行うときの,変更管理プロセスと

のインタフェース

g) 

インシデントの解決又はサービス要求の実現の検証に対する責任

h) 

インシデント又はサービス要求の終了に関する方針及び取組み。例えば,このプロセスは利用者又は

顧客に復旧が有効かどうかの確認を求めてから,記録を更新し,最終的に記録を終了状態に設定する

ことが望ましい。

サービス提供者は,復旧が有効であったことの確認を利用者又は顧客から得ない場合,インシデントを


62

Q 20000-2

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

解決した,又はサービス要求を実現したという不正確な想定を行ってしまうことがある。

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)

各サービス要求の完了を補佐するために作業が割り当てられるサービス提供グループ。


63

Q 20000-2

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

e)

基盤となる契約(underpinning contract)及び合意書に定義される支援サービスを提供できる外部供給

者及びベンダ。

8.2 

問題管理 

8.2.1 

要求事項の意図 

問題管理プロセスは,インシデントの未知の根本原因を特定し,変更管理プロセスを通じて恒久的な解

決策を提案する。また,問題管理プロセスは,傾向分析及び予防処置の推奨を通じてインシデントの発生

を事前予防的に防止する。

8.2.2 

概念 

問題管理プロセスは,インシデントの根本原因を調査することが望ましい。次に,問題管理プロセスは,

変更管理プロセスを通じて恒久的な解決策を提案して,インシデント及び問題の影響を最小化する又は回

避することが望ましい。

さらに,問題管理プロセスは,内在する根本原因が特定された場合,暫定策を含む既知の誤りの記録を

作成し,管理することが望ましい。既知の誤りの記録は,効率的なインシデントの解決及び組織的な学習

を確実にするために用いることができる。

問題管理プロセスは,定義された適用範囲をもつことが望ましく,採用する問題管理方法を決定するこ

とが望ましい。問題の優先度付け及び調査の両方の基準を定めることができる問題管理方針があると役に

立つ。

問題管理プロセスの主たる視点は,多くの組織で,既に発生したインシデントに基づいている。影響が

極めて大きく,リスクが極めて大きい問題の恒久的な解決策を見つけることは,組織にとって効用が大き

く,また,このことによって,サービスを,より信頼性が高く,費用対効果が大きく,かつ,効率的なも

のにできる。

これらの問題管理活動の結果として,環境の信頼性が向上すると,要員は,事前予防的な問題管理によ

り多くの時間を割くことができるようになる。事前予防的な問題管理活動は,最初からインシデントの予

防を目指すことが望ましい。例えば,事業上重要なサービスの潜在的な単一障害点を特定し,顧客に影響

を及ぼす将来のインシデントを予防するための冗長性を提案することである。

8.2.3 

要求事項の説明 

問題管理プロセスは,次の手順を含むことが望ましい。

a)

問題の特定は,次の事項を含む。

1)

一つ以上のインシデントの未知の根本原因の検知

2)

根本的な問題を明らかにする一つ以上のインシデントの分析

3) 

供給者又は内部グループからのサービスコンポーネントに関する問題の通知

b)

各問題の記録を確実にするための問題の記録。記録は,日時など関連する問題の詳細,及び問題の記

録の発端となったインシデントの相互参照を含むことが望ましい。

c)

問題の分類及び優先度付けは,次の事項を確実にすることが望ましい。

1) 

インシデント及びサービス要求管理プロセスで使用しているものと同一の分類基準を利用して,問

題の性質を判別し,有意義な情報を提供する目的で各問題を分類する。

2)

各問題に,関連インシデントの緊急度及び影響に従って解決の優先度を与える。

3)

問題を調査し,解決のための最善の選択肢を特定するための時間及び資源を,問題の優先度に応じ

て割り当てる。

4) 

問題の優先度及びサービスの要求事項を満たすために変更を加える効用に応じて,問題の解決に時


64

Q 20000-2

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

間及び資源を割り当てる。

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)

未解決の,異常な,又は影響の大きい問題を調査するために行われる重大な問題のレビューは,次の

事項を確実にすることが望ましい。


65

Q 20000-2

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

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)

問題の根本原因の分析を行い,解決策及び/又は暫定策を決め,ひも(紐)付けされた既知の誤りの

データの記録を作成する要員


66

Q 20000-2

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

b)

解決策,暫定策,既知の誤りの情報,助言及びレビューに関与する供給者,顧客又は内部グループ

統合的制御プロセス 

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 の保管場所及び保管条件,並びに情報


67

Q 20000-2

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

の場合は記憶媒体

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 又は統合された文書若しくは記録に関連情報をもつことが望ましい。


68

Q 20000-2

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

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

に規定するプロセスオーナ,プロセスマネージャ,及びこのプロセスの手順を実行する要員に加

えて,構成管理プロセスで必要となる権限及び責任には,次の要員を含めることが望ましい。


69

Q 20000-2

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

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 に対する全ての変更要求は,このプ

ロセスによって管理することが望ましい。

サービス又は顧客に大きな影響を及ぼす可能性がある変更は,変更管理方針で定義された基準に従って

分類することが望ましい。これらの変更は,新規サービス又はサービス変更の設計及び移行プロセスを用

いて管理し,変更管理プロセスと連携することが望ましい。

変更管理方針は,どの変更を変更管理プロセスで管理することが望ましいか,並びにどの変更を新規サ

ービス又はサービス変更の設計及び移行プロセスで管理することが望ましいかを決める基準を定義するこ

とが望ましい。

新規サービス又はサービス変更の設計及び移行プロセスを通じて管理される変更を判断するときに使

用する基準は,サービスの廃止のための変更と,サービス提供者からサービスを他の関係者に移管するた


70

Q 20000-2

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

めの変更とを含むことが望ましい。他の関係者は,顧客又は供給者のこともある。

9.2.3.2 

計画立案及び実施 

変更要求は,文書化された適用範囲をもつことが望ましく,定義され,合意した基準に従って分類する

ことが望ましい。変更要求は,リスク,サービス及び顧客への影響,財務への波及,事業利益,並びに技

術的な実現可能性を考慮して,開発又は構築の前にアセスメントを行い,承認を受けることが望ましい。

変更の構築,試験及び実施の管理は,構成管理プロセス並びにリリース及び展開管理プロセスと連携す

ることが望ましい。

失敗した変更を元に戻すか,修正するために必要な活動を計画し,試験することが望ましい。失敗した

場合には,その変更を元に戻すか,修正することが望ましい。失敗した変更は調査し,適切な処置をとる

ことが望ましい。

開発が承認された変更の詳細,及びその実施の期日案を含む変更スケジュールを策定し,例えば,一次

サポート,BRM,供給者管理などの利害関係者に通知することが望ましい。

変更管理プロセス及び手順は,次の事項を確実にすることが望ましい。

a)

変更は,影響を受ける構成品目を特定するような,明確に定義され,文書化された適用範囲をもつ。

b)

変更要求の受付け及び承認に関する決定のときに,リスク,優先度,サービス又は顧客への潜在的影

響,サービスの要求事項,事業利益,技術的な実現可能性及び財務への影響を考慮する。

c)

承認される変更の詳細及びその展開の期日案を含む,変更スケジュールを策定する。

d)

変更スケジュールを利害関係者に伝える。

e)

変更スケジュールを,リリース展開の計画立案に使用する。

f)

特定されたサービス及び構成品目に対する,承認された変更を開発し,変更スケジュールに従って試

験を行う。

g)

変更スケジュールに従って,変更を展開する。

h)

失敗した変更を元に戻す,又は修正するための活動を計画し,試験する。

i)

失敗した変更を元に戻すか,修正し,失敗した変更の理由を文書化し,調査する。

j)

変更の成否にかかわらず,展開後に CMDB を更新する。

9.2.3.3 

変更要求のレビュー 

変更量の増加,頻繁に再発する種類,新しい傾向及びその他の関連情報を特定するために,変更要求の

記録は,あらかじめ定めた間隔で分析することが望ましい。変更の分析から引き出された結果及び結論は

記録し,改善の機会の特定に利用することが望ましい。不適合は記録し,処置をとることが望ましい。

個々の変更要求に関してレビューを行った結果,変更管理プロセスにおいて特定された弱点又は欠陥は,

改善計画に盛り込むことが望ましい。

変更が展開され,受け入れられた場合は,変更要求を終了することが望ましい。変更を実施しないとい

う決定が下されたときも,変更を終了することができる。変更要求が終了したときは,変更の結果を変更

要求の起案者及びその他の利害関係者に報告することが望ましい。

9.2.3.4 

緊急変更 

緊急変更は,リスクの増加,並びに緊急変更の承認及び実施の費用の増加のために,他の変更と区別す

ることが望ましい。

緊急変更については,承認並びに実施後の文書及びレビューに関する取決めを含む,定義されたプロセ

スがあることが望ましい。緊急変更は,適切な変更権限をもつ者が承認することが望ましく,可能な場合

には,利害関係者に通知することが望ましい。


71

Q 20000-2

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

緊急変更は,通常変更プロセスの手順,予定及び承認権限を順守する十分な時間がない緊急事態を解決

するために利用してもよい。可能な場合には,完全な変更プロセスに従うことが望ましい。ただし,緊急

変更の実施はその緊急性のために,詳細の一部は後で記録することもあり,試験ができないこともある。

事態の緊急性に対応するために,これらの段階の一部を省略した場合でも,失敗した場合に緊急変更を元

に戻すか,それを修正するための計画があることが望ましい。緊急手順に従ったために,実施前の試験が

不完全なものになるなど,他の変更管理の要求事項を省略することになった場合は,できる限り早急に,

変更がこれらの要求事項に適合するようにすることが望ましい。

緊急変更は,

実施者が実施理由を説明し,

変更後にレビューを行って,本当に緊急事態であったことを検証することが望ましい。

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 

要求事項の意図 

リリース及び展開管理プロセスは,ハードウェア,ソフトウェア及びサービスコンポーネントの完全性

が維持されるように,全てのリリースを稼働環境に効果的に展開することを確実にすることが望ましい。

リリース及び展開管理プロセスは,リリースの全側面を調整することが望ましい。これは,技術的機能性,

環境との統合,リリースの開発,試験及び展開を行うための資源の割当て,教育・訓練,支援,リリース

文書などを含むことが望ましい。リリースが成功することを確実にするために,全側面を併せて検討する

ことが望ましい。


72

Q 20000-2

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

稼働環境の完全性を保護することが望ましく,適切な計画立案,試験及び変更管理プロセスとの連携を

通じて,中断を最小限にすることが望ましい。

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 

リリース及び展開の計画立案 

リリース及び展開管理プロセスは,新規サービス又はサービス変更の稼働環境へのリリース及び展開を,


73

Q 20000-2

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

顧客及び利害関係者とともに計画することが望ましい。リリース及び展開の計画立案の支援には,プロジ

ェクト管理の方法及び技法を用いることが望ましい。リリース及び展開計画に関する最低限の情報は,サ

ービス提供者が定義することが望ましく,リリースの種類に従って異なるものであってもよい。

リリース及び展開計画は,常に,全ての変更が変更管理プロセスと連携することを確実にすることが望

ましい。リリース及び展開計画は,リリースの影響,関連するリスクのアセスメント,及び受容できない

リスクを最小限にするための軽減措置の特定を含むことが望ましい。

リリース及びその展開を計画立案するときに検討することが望ましい一般的な要因には,事業の規模,

リリースの展開に必要な技術的変更及びその他の変更がある。例えば,新技能,新規又は変更されたプロ

セス,及び新規ツールがある。その他の要因には,依存関係,並びにリリースの構築,試験及び展開に必

要な時間及び資源が含まれる。

リリース及び展開計画は,次のコンポーネントを含むことが望ましい。

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)

技術的なハードウェア及び環境の構築


74

Q 20000-2

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

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)

リリース計画


75

Q 20000-2

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

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)

新規サービス若しくはサービス変更,又はサービスコンポーネントの運用活動の試験に責任をもつサ

ービス提供者の要員


76

Q 20000-2

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

附属書 A

(参考)

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

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

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

新規サービス又はサービス変更の設計及び移行と SMS の他のプロセスとのインタフェースの例には,次の事項が
含まれる。 

SLM

プロセスは,新規サービス又はサービス変更のサービスレベルの要求事項を提供することが望ましい。

BRM

プロセスは,新規サービス又はサービス変更に関する全ての顧客要求事項及び事業上の要求事項を特定し,文

書化し,合意し,提示することを確実にするために,それらの要求事項を提示することが望ましい。

インシデント及びサービス要求管理プロセスは,稼働環境に移行後の,新規サービス又はサービス変更の実施の影
響に関する詳細を提供することが望ましい。

リリース及び展開管理プロセスは,展開のタイミング及び方法に関する助言を提供することが望ましい。

サービスの予算業務及び会計業務プロセスは,サービス提供の変更に係る費用の見積報告書を受領することが望ま
しい。

変更管理プロセスは,新規サービス又はサービス変更の導入によって生じる変更要求を受領することが望ましい。

新規サービス又はサービス変更の設計及び移行と SMS の他のプロセスとの統合例には,次の事項が含まれる。 

新規サービス又はサービス変更の設計及び移行は,新規サービス又はサービス変更に関する潜在的要求事項を特定
するためのインプットとして,監査での不適合記録を受領することが望ましい。

新規サービス又はサービス変更の設計及び移行は,顧客満足度に対処するために,新規サービス又はサービス変更
に関する潜在的要求事項を特定するためのインプットとして,

顧客満足度の分析報告書を受領することが望ましい。

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

SLM

と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

サービス継続及び可用性管理プロセスは,SLA へのインプットとして継続又は可用性の要求事項を提供し,中断又
は非可用性による SLA 違反を低減することが望ましい。

容量・能力管理プロセスは,貧弱なパフォーマンスによる SLA 違反を低減するために,SLA へのインプットとし
てパフォーマンスの要求事項を提供することが望ましい。

供給者管理プロセスは,供給者の契約目標が SLA に整合するように,供給者との契約の詳細を提供することが望ま

しい。

ISM

プロセスは,SLA がセキュリティ方針に整合して策定されるように,情報セキュリティ方針を提供することが

望ましい。

インシデント及びサービス要求管理プロセスは,インシデントについての関連データを提供することが望ましい。

インシデント及びサービス要求管理プロセスは,インシデント及び要求が,優先度付けされ,対応及び解決のため

の合意した時間枠内に解決又は実現されるように,SLA を受領することが望ましい。

変更管理プロセスは,SLA の変更要求を受領し,計画した SLA との差分について詳述した,想定されるサービス

の休止を特定することが望ましい。

SLM

と SMS の他のプロセスとの統合例には,次の事項が含まれる。 

SLM

プロセスは,トップマネジメントと,顧客と,利用者と,サービスレベルマネージャとの間で合意したサービ

スの定義を維持することが望ましい。

SLM

プロセスは,サービス提供に必要な,サービス提供者の技能及び資源を定義することが望ましい。

SLM

プロセスは,二次サポート,三次サポートなどの,サービスに関する問題の解決者グループ及びサービス要求

の実現を支える,サービスの供給者とやりとりすることが望ましい。


77

Q 20000-2

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

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

サービスの報告と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

SLM

プロセスは,サービスの報告に関する適切な方針及び規則を定義するために,SLA に対応する情報を提供する

ことが望ましい。

インシデント及びサービス要求管理プロセスは,全ての利害関係者が影響を理解し,合意した処置をとることがで
きるよう,インシデントに関するデータをサービスの報告に提供することが望ましい。

サービス継続及び可用性管理プロセスは,サービス及びコンポーネントの可用性に関する情報を提供することが望
ましい。

容量・能力管理プロセスは,事前に定義したしきい(閾)値を基準にすることを含めて,作業負荷の報告に関する

情報を提供することが望ましい。

BRM

プロセスは,最適なレベルのサービス提供及び顧客満足度の改善を可能にするために,正しいレベルの情報を

受領することが望ましい。

サービスの報告と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

サービスの報告プロセスは,サービスに関する意思決定及び処置がとれるようにするために,サービスの質,費用

及びリスクに関して利害関係者に報告書を提供することが望ましい。

サービスの報告プロセスは,SMS の管理及び改善に必要なコミュニケーション及び可視性が得られるようにするた

めに,全てのサービスマネジメントのプロセスからデータを受領することが望ましい。

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

サービス継続及び可用性管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

SLM

プロセスは,次の事項を提供することが望ましい。

− SLA におけるサービス継続及び可用性の義務

−  災害のときに事業者にとって受入れ可能なサービスレベル 
−  可用性の目標の決定に対する支援,並びにサービス及びコンポーネントの違反の調査及び解決

容量・能力管理プロセスは,次の事項を提供することが望ましい。

−  可用性計画との整合を可能にするための容量・能力計画

−  災害後の復旧を可能にするための,回復力(resilience)及び予備の容量・能力を備えたデータ保管庫など,十

分な資源が備わるようにしたモデル化の情報

ISM

プロセスは,情報セキュリティインシデントがいつ災害とみなされるのかの定義を提供することが望ましい。

構成管理プロセスは,全てのサービス継続及び可用性管理プロセスの活動並びに計画及び復旧設備の維持を可能に
するために,インフラストラクチャを形成するコンポーネントに関する情報を提供することが望ましい。

変更管理プロセスは,サービス継続及び可用性の計画への潜在的影響をもつ全ての変更に関する情報を提供するこ
とが望ましい。

SLM

プロセスは,合意して SLA として文書化できるように,復旧の要求事項及び選択肢を受領することが望まし

い。

インシデント及びサービス要求管理プロセス並びに問題管理プロセスは,サービス継続及び可用性の計画の発動に

関して,明確に合意され文書化された基準を受領することが望ましい。

サービス継続及び可用性管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

サービス継続及び可用性管理プロセスは,サービス継続又は可用性に関する新規又は変更された要求事項を特定す

るために,顧客及び利害関係者から事業計画に関する情報を受領することが望ましい。

サービス継続及び可用性管理プロセスは,サービスマネジメントに関する決定が,可用性の欠如による事業への影

響の明確な理解に基づくことを確実にするために,事業影響度分析をトップマネジメント及び全ての利害関係者に
提供することが望ましい。


78

Q 20000-2

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

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

サービス予算業務及び会計業務と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

新規サービス又はサービス変更の設計及び移行プロセスは,予算及び期間を含む新規サービス又はサービス変更の

計画を提供することが望ましい。

SLM

プロセスは,サービス提供者が提供するサービスに関する費用のモデルを構築するための基礎として,サービ

スカタログを提供することが望ましい。

容量・能力管理プロセスは,事業上の要求事項を満たすための選択肢について行った費用の見積りを含めて,容量・
能力計画を提供することが望ましい。

供給者管理プロセスは,短期及び契約満了までの両方に係る,費用の変更の詳細を提供することが望ましい。

構成管理プロセスは,全ての構成品目の詳細を提供することが望ましい。

容量・能力管理プロセスは,サービス及びインフラストラクチャのアップグレード又は新規コンポーネントの購入
用の予算を受領することが望ましい。

変更管理プロセスは,必要な場合には,財務に関する承認を受けることが望ましい。

サービスの予算業務及び会計業務と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

サービスの予算業務及び会計業務プロセスは,信頼できる費用の予想及び配賦を可能にするために,サービス提供

者の財務管理組織から十分な情報を受領することが望ましい。

サービスの予算業務及び会計業務プロセスは,

財務管理方針及び規制要求事項に整合することを可能にするために,

組織に対するサービスの予算業務及び会計業務の方針を提供することが望ましい。

財源は,SMS の導入,運用及び改善を管理するために適した詳細度で予算配分することが望ましく,このためには,
サービスの予算業務及び会計業務プロセスと財務管理との調整が必要となる。

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

容量・能力管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

SLM

プロセスは,容量・能力管理の目標に加えて,SLA 及び要求されるサービスレベルを提供することが望ましい。

サービスの予算業務及び会計業務プロセスは,サービス提供の結果,容量・能力の費用の減少又は容量・能力の資
源の利用度の向上につながる,効率性の向上に関する情報を提供することが望ましい。

インシデント及びサービス要求管理プロセスは,容量・能力及びパフォーマンスに関係するインシデントについて

の情報を提供することが望ましい。

構成管理プロセスは,CMDB で維持される CI に関する技術,サービス,利用度,財務及び事業に関するデータを

提供することが望ましい。

SLM

プロセスは,新規又は変更された要求事項のパフォーマンス及び容量・能力の目標の達成を確実にするために,

定期的な報告書を受領することが望ましい。パフォーマンスは所定の作業負荷に依存するので,具体的なパフォー
マンスの目標が定められた SLA では,両方が必要となる。同様に,容量・能力又はパフォーマンスの課題が関与し

ている場合,運用レベル合意書及び外部契約の起草及びレビューを行う上で,SLM プロセスを補佐するための容

量・能力管理プロセスに関する要求事項が必要となることがある。

サービス継続及び可用性管理プロセスは,採用する復旧のための全ての選択肢に必要となる容量・能力を決定する

ために,モデル化データを受領することが望ましい。発動後に,必要となるパフォーマンス及びスループットのレ
ベルを定めるために,必要となる最低限のハードウェア及びソフトウェア構成を定義する。

問題管理プロセスは,容量・能力に関する問題の特定,診断及び解決を助けるために,専門知識を受領することが

望ましい。

変更管理プロセスは,変更が容量・能力に及ぼす累積的な影響に関して,容量・能力管理プロセスから情報を受領

することが望ましい。また,容量・能力管理プロセスについても,既存の容量・能力に対する変更の影響のアセス

メントを行い,容量・能力の要求事項の変更を特定するために,代表者が変更諮問委員会に参加する。

リリース及び展開管理プロセスは,特に配付にネットワークを使用している場合,リリースの配付方針の決定を助
ける情報を受領することが望ましい。ネットワーク帯域幅,ホスト及び目標とする容量・能力,配付時間帯及び目

標数などの要因は,リリースの配付方針の一部として検討することが望ましい。

容量・能力管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

容量・能力管理プロセスは,不適合及び改善の機会を特定する監査結果を受領することが望ましい。

容量・能力管理プロセスは,サービス提供者が十分な技能をもち,容量・能力管理プロセスを支援できる技能レベ
ルであることを確実にするために,力量,認識及び教育・訓練に関する要求事項を提供することが望ましい。


79

Q 20000-2

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

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

ISM

と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

サービスの予算業務及び会計業務プロセスは,セキュリティ管理策関連の費用に関する情報を提供することが望ま

しい。

容量・能力管理プロセスは,セキュリティ管理策の容量・能力への影響(セキュリティ管理策はサービスのパフォ
ーマンスに影響を及ぼすことが多い。

)を提供することが望ましい。

供給者管理プロセスは,供給者が情報セキュリティ方針を順守し,維持しているかどうかを評価する報告書を提供
することが望ましい。

インシデント及びサービス要求管理プロセスは,情報セキュリティ方針の要求事項を満たし,再発を防ぐために,

全てのセキュリティインシデントに関する詳細な情報を提供することが望ましい。

問題管理プロセスは,特定された情報セキュリティインシデントの根本原因を ISM に提供することが望ましい。

構成管理プロセスは,高いセキュリティリスクに関して CMDB に置かれている構成品目の詳細,並びに情報セキュ

リティ問題の影響及び解決策を決定できる,CMDB にある情報を提供することが望ましい。

変更管理プロセスは,情報セキュリティの解決策及び暫定策の詳細を提供することが望ましい。

SLM

プロセスは,SLA に含める情報セキュリティの要求事項を受領することが望ましい。

サービス継続及び可用性管理プロセスは,サービスの継続及び可用性を確実にするために,情報セキュリティイン
シデント,問題及び解決策の詳細を受領することが望ましい。

BRM

プロセスは,情報セキュリティの脅威に関する警告を受領することが望ましい。

インシデント及びサービス要求管理プロセスは,情報セキュリティインシデントへの対処法に関する手引を受領す
ることが望ましい。

ISM

と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

ISM

プロセスは,全ての情報が保護され,事業価値,規制要求事項,並びに機密性,完全性及び可用性の要求され

るレベルに整合するように管理されることを確実にするために,文書の運用管理に情報セキュリティ方針を提供す

ることが望ましい。

ISM

プロセスは,サービスに対するセキュリティリスクのアセスメントが行われ,管理されることを確実にするた

めに,情報セキュリティ方針をリスクマネジメントに提供することが望ましい。

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

BRM

と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

SLM

プロセスは,サービスの適用範囲を含む SLA 又は契約を提供することが望ましい。

サービスの報告プロセスは,特定されたニーズ及び顧客要求事項を含むサービス報告書を提供することが望ましい。

サービス継続及び可用性管理プロセスは,サービス継続計画の詳細を提供することが望ましい。

ISM

プロセスは,顧客関係に影響を及ぼす可能性がある脅威の警告を提供することが望ましい。

インシデント及びサービス要求管理プロセスは,

顧客からの正式な苦情及び賛辞の詳細を提供することが望ましい。

変更管理プロセスは,

顧客の苦情及び顧客満足度調査から生じる修正処置及び改善処置を受領することが望ましい。

BRM

と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

BRM

プロセスは,コミュニケーション及び顧客満足度の改善につながるこれらの結果を,顧客に提供することが望

ましい。

顧客の苦情及び顧客満足度調査は,SMS のレビューへのインプットを提供することが望ましい。


80

Q 20000-2

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

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

供給者管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

SLM

プロセスは,目標,要求事項及び責任が,基盤となる合意書及び契約(underpinning agreements and contracts)

請負の合意書及び契約に含まれることを確実にし,これらの目標が SLA に規定されるものを含めたサービスの要求
事項を支援するように,目標,要求事項及び責任を提供することが望ましい。

サービス継続及び可用性管理プロセスは,他の関係者によって供給されるサービスに関して,継続及び可用性要求

事項を提供することが望ましい。

サービスの予算業務及び会計業務プロセスは,供給者管理の要求事項及び契約に資金を投入するため,並びに購入

及び調達に関する事項に助言及び手引を提供するため,適切な資金を提供することが望ましい。

ISM

プロセスは,供給者のサービス及びシステムへのアクセスと,ISM の方針及び要求事項への適合に関する供給

者の責任とに関する方針及び手順を提供することが望ましい。

供給者管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

供給者管理プロセスは,供給者のパフォーマンスのデータを受領することが望ましく,顧客要求事項及び事業計画

を支援するための金銭的価値を交渉するために,

利用可能な選択肢に対してこのデータを測定することが望ましい。

供給者管理プロセスは,供給者が事業遂行能力の要求事項を継続的に満たすことを確実にするために,供給者の能

力,認識及び教育・訓練並びに供給者の教育・訓練の評価結果に関する要求事項を提供することが望ましい。

サービスに対するコミットメントの変更を含む,利害関係者が合意する契約,合意文書又はその他の文書の変更は,
変更管理プロセスで管理することが望ましい。

変更管理プロセスは,要求されたとおりに,供給者が組織の変更管理の実践を順守していること,並びに供給者に
よって提供されるサービスに影響を及ぼす変更案のレビュー,アセスメント及び認可に供給者が参加することを確

実にすることが望ましい。

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

インシデント及びサービス要求管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。

SLM

プロセスは,合意したインシデント及びサービス要求の目標を提供することが望ましい。

問題管理プロセスは,インシデントの影響を最小限にするために,既知の誤りの記録及び暫定策の詳細を提供する
ことが望ましい。

構成管理プロセスは,より正確な影響アセスメントを可能にするために,インシデント又はサービス要求によって

影響を受ける CI に関する情報をインシデント及びサービス要求管理プロセスに提供することが望ましい。

サービス継続及び可用性管理プロセスは,サービスの可用性又は継続に大きな影響を及ぼす,インシデント及び重

大なインシデントの詳細を受領することが望ましい。

容量・能力管理プロセスは,容量・能力不足に関連するインシデント及び重大なインシデントの詳細を受領するこ

とが望ましい。

問題管理プロセスは,傾向分析のために,インシデント及びサービス要求の記録の詳細を受領することが望ましい。

変更管理プロセスは,結果的に新たなインシデントとなった,失敗した変更の影響に関する報告を受領することが

望ましい。

インシデント及びサービス要求管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

インシデント及びサービス要求管理プロセスは,役割ごとに,要員の専門的力量を要求する。これらのサービスマ

ネジメントの力量に関する要求事項は,明確に定義することが望ましい。その役割について検討されている個人又
は既に役割を担っている個人に力量の不足又はその他の欠陥がある場合,サービス提供者は,この不足を修正する

ことを確実にすることが望ましい。

プロセスの改善及び経費節減の機会を特定するために,インシデントの記録及びサービス要求についてレビューす

ることが望ましい。


81

Q 20000-2

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

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

問題管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

SLM

プロセスは,SLA 及び合意した問題管理の目標を含めた合意書を提供することが望ましい。

サービス継続及び可用性管理プロセスは,サービスの可用性又は継続に大きな影響を及ぼす問題の詳細を提供する

ことが望ましい。

容量・能力管理プロセスは,容量・能力の傾向を提供することが望ましい。

インシデント及びサービス要求管理プロセスは,次の事項を提供することが望ましい。

−  未知の根本原因があるインシデントの詳細を問題管理プロセスに提供する。 
−  傾向分析など,事前予防的問題管理のためのインシデントデータ

構成管理プロセスは,問題の影響及び解決策の決定を助ける,CI 間の関係に関する情報を提供することが望ましい。

インシデント及びサービス要求管理プロセスは,次の事項を受領することが望ましい。 
−  稼働環境に導入される新規サービス又はサービス変更のための,既知の誤りの詳細

−  インシデントの影響を最小限にするための既知の誤りの記録及び暫定策の詳細

変更管理プロセスは,既知の誤りに対して恒久的解決策を実施するための変更要求を受領することが望ましい。

問題管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

問題管理プロセスは,SMS の問題に関する情報を受領することが望ましい。

問題管理プロセスは,SMS の問題の根本原因を特定し,変更管理プロセスを通してそれらを解決することが望まし
い。

既知の誤りのデータベースは,文書の運用管理の方針及び手順を順守することが望ましい。

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

構成管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

構成管理プロセスは,問題の影響及び根本原因の分析を助ける,CI 間の関係に関する情報を提供することが望まし

い。

構成管理プロセスは,変更案によってどの CI が影響を受けるかに関する情報を提供することが望ましい。

構成管理プロセスは,

サービスカタログに記載されているサービスを支援する CI に関する情報を提供することが望

ましい。

新規サービス又はサービス変更の設計及び移行プロセスは,利害関係者が,既存の CI 及びサービスに対する影響の

アセスメントを行えるように,新規サービス又はサービス変更の全ての計画及び設計の詳細を提供することが望ま
しい。

インシデント及びサービス要求管理プロセスは,CI に関係する全てのインシデント及びサービス要求の詳細を提供

することが望ましい。

問題管理プロセスは,既知の誤り及び暫定策とその影響を受ける構成品目との関連を提供することが望ましい。

変更管理プロセスは,CI に加わる変更の詳細,及びその変更を CMDB に反映させる権限を提供することが望まし

い。

リリース及び展開管理プロセスは,リリース品目の構成ベースライン並びにリリースの前及び後の対象の環境を提

供することが望ましい。

全てのプロセスは,そのプロセスの適用範囲内の全ての CI に関して,最新かつ正確な情報を受領することが望まし

い。

サービスの予算業務及び会計業務プロセスは,サービスの提供に使用する,ライセンスを含めた資産の詳細を受領

することが望ましい。

構成管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

トップマネジメントは,サービスの提供に使用する,ライセンスを含めた全ての資産を,法令・規制要求事項及び

契約上の義務に従って管理することを確実にする責任をもつ。構成管理は,この要求事項を達成するための主要な
手段である。

構成管理プロセスには財務資産の会計業務を含まないが,財務資産の会計業務プロセスとのインタフェースを含む

ことが望ましい。


82

Q 20000-2

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

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

変更管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

サービス継続及び可用性管理プロセスは,次の事項を提供することが望ましい。

−  サービス継続の手順及び計画を更新するための変更要求。これよって,サービス継続の手順及び計画が引き続

き正確で,最新であることを確実にし,利害関係者が変更について認識することを確実にする。

−  変更案がサービス又はコンポーネントの可用性に及ぼす潜在的影響を,変更管理プロセスに提供する。

容量・能力管理プロセスは,個々の変更の影響だけではなく,変更がサービスの容量・能力,及び資源又はコンポ

ーネントの容量・能力に及ぼす総合的影響を含めて,変更案のアセスメントを提供することが望ましい。

ISM

プロセスは,変更案が情報セキュリティ方針及び管理策に及ぼす潜在的影響を提供することが望ましい。

インシデント及びサービス要求管理プロセスは,実施された変更に付随するインシデントに関する情報を提供する

ことが望ましい。

問題管理プロセスは,実施された変更に付随する問題に関する情報を提供することが望ましい。

構成管理プロセスは,利害関係者及び要員が変更案の影響のアセスメントを行えるようにするために,正確な構成

情報への,信頼性があり,迅速かつ容易なアクセスを提供することが望ましい。

リリース及び展開管理プロセスは,リリース管理によって実施される,承認された変更に関する情報を受領するこ

とが望ましい。

変更管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

SMS

への全ての変更は,変更管理プロセスを経由することが望ましい。

変更管理プロセスは,SMS,サービスカタログ,サービス,方針,目的及び計画,事業上の要求事項,サービスの

要求事項,並びに供給者の要求事項への全ての変更の詳細を提供することが望ましい。

SMS

の適用範囲は,改善及びその他の変更に係る時間及び費用に影響を及ぼし,加えて変更管理プロセスにも影響

を及ぼす。

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

リリース及び展開管理と SMS の他のプロセスとのインタフェースの例には,次の事項が含まれる。 

サービス継続及び可用性管理プロセスは,特に全体的な容量・能力が向上するときに,サービスが継続的に可用性

の目標を満たすことを確実にするために,技術設計のアセスメントを提供することが望ましい。継続管理計画の早
期のレビュー及び更新には,重要な新規リリースを含めることが望ましい。適切な継続性のレビュー及び試験のス

ケジュールは,リリース展開の前に組むことが望ましい。

容量・能力管理プロセスは,リリースを支援するための増分の容量・能力の購入及び導入に関する情報及び支援を

提供することが望ましい。これには,開発及び試験の環境用の容量・能力の確保を含めてもよい。

ISM

プロセスは,リリースの結果生じる新たな方針,実践及びツールの採用に合わせて,更新されたセキュリティ

計画を提供することが望ましい。

供給者管理プロセスは,現在有効な,又はリリース内にある技術コンポーネントの調達及び支援の前に更新される,

必要な契約及び合意書を提供することが望ましい。これによって,リリースの実運用の要件を満たす。

変更管理プロセスは,承認された変更要求をリリース及び展開管理に提供することが望ましい。

SLM

プロセスは,サービス又はサービスレベルの文書及び主要な窓口の変更に関する更新を受領することが望まし

い。

問題管理プロセスは,リリースとともに稼働環境に持ち込まれる欠陥及びそのための暫定策の通知及び記録を受領
することが望ましい。

構成管理プロセスは,リリース後の稼働環境の変更を反映した情報を受領することが望ましい。この情報で,CMDB
の正確さを確実にする。CMDB に関する追加のリリース情報は,修正又は廃止される CI の更新及び旧サービスに

取って代わる新規サービスを含む。

リリース及び展開管理と SMS の他のプロセスとの統合の例には,次の事項が含まれる。 

リリース及び展開管理プロセスは,リリースの一部として必要となる教育・訓練,新規採用又は初期支援を考慮す

ることが望ましい。

トップマネジメントは,サービス提供者が取得又は使用する要員資源の量及び技能が,リリースの構築,試験及び

展開,並びに実運用に入った新規リリースの支援及び運用のために十分であることを確実にすることが望ましい。


83

Q 20000-2

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

参考文献

[1]  ISO/IEC 20000-3

,Information technology−Service management−Part 3: Guidance on scope definition and

applicability of ISO/IEC 20000-1

[2]  ISO/IEC TR 20000-4

,Information technology−Service management−Part 4: Process reference model

[3]  ISO/IEC TR 20000-5

,Information technology−Service management−Part 5: Exemplar implementation plan

for ISO/IEC 20000-1

[4]  JIS Q 9000

  品質マネジメントシステム−基本及び用語

注記  対応国際規格:ISO 9000,Quality management systems−Fundamentals and vocabulary(IDT)

[5]  JIS Q 9001

  品質マネジメントシステム−要求事項

注記  対応国際規格:ISO 9001,Quality management systems−Requirements(IDT)

[6]  JIS Q 9004

  組織の持続的成功のための運営管理−品質マネジメントアプローチ

注記  対応国際規格:ISO 9004,Managing for the sustained success of an organization−A quality

management approach

(IDT)

[7]  ISO/IEC TR 9126-2

,Software engineering−Product quality−Part 2: External metrics

[8]  ISO/IEC TR 9126-3

,Software engineering−Product quality−Part 3: Internal metrics

[9]  JIS Q 10002

  品質マネジメント−顧客満足−組織における苦情対応のための指針

注記  対応国際規格:ISO 10002,Quality management−Customer satisfaction−Guidelines for complaints

handling in organizations

(IDT)

[10] ISO 10007

,Quality management systems−Guidelines for configuration management

[11]  JIS X 0160

  ソフトウェアライフサイクルプロセス

注記  対応国際規格:ISO/IEC 12207,Systems and software engineering−Software life cycle processes

(IDT)

[12] JIS X 0133

  ソフトウェア製品の評価(全ての部)

注記  対応国際規格:ISO/IEC 14598 (all parts),Software engineering−Product evaluation

[13] ISO/IEC 15288

,Systems and software engineering−System life cycle processes

[14] JIS X 0145-1

  情報技術−プロセスアセスメント−第 1 部:概念及び用語

注記  対応国際規格:ISO/IEC 15504-1,Information technology−Process assessment−Part 1: Concepts

and vocabulary

(IDT)

[15] JIS X 0145-2

  情報技術−プロセスアセスメント−第 2 部:アセスメントの実施

注記  対応国際規格:ISO/IEC 15504-2,Information technology−Process assessment−Part 2: Performing

an assessment

(IDT)

[16] JIS X 0145-3

  情報技術−プロセスアセスメント−第 3 部:アセスメント実施の手引

注記  対応国際規格:ISO/IEC 15504-3,Information technology−Process assessment−Part 3: Guidance

on performing an assessment

(IDT)

[17] JIS X 0145-4

  情報技術−プロセスアセスメント−第 4 部:プロセス改善及びプロセス能力判定のため

の利用の手引

注記  対応国際規格:ISO/IEC 15504-4,Information technology−Process assessment−Part 4: Guidance

on use for process improvement and process capability determination

(IDT)


84

Q 20000-2

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

[18] ISO/IEC 15504-5

,Information technology−Process assessment−Part 5: An exemplar software life cycle

process assessment model

[19] ISO/IEC TR 15504-6

,Information technology−Process assessment−Part 6: An exemplar system life cycle

process assessment model

[20] JIS X 0141

  システム及びソフトウェア技術−測定プロセス

注記  対応国際規格:ISO/IEC 15939,Systems and software engineering−Measurement process(IDT)

[21] JIS Q 19011

  マネジメントシステム監査のための指針

注記  対応国際規格:ISO 19011,Guidelines for auditing management systems(IDT)

[22] JIS X 0164-1

  ソフトウェア資産管理−第 1 部:プロセス

注記  対応国際規格:ISO/IEC 19770-1,Information technology−Software asset management−Part 1:

Processes and tiered assessment of conformance

(IDT)

[23] ISO/IEC 19770-2

,Information technology−Software asset management−Part 2: Software identification tag

[24] ISO/IEC TR 24748-2

,Systems and software engineering−Life cycle management−Part 2: Guide to the

application of ISO/IEC 15288 (System life cycle processes)

[25] ISO/IEC TR 24748-3

,Systems and software engineering−Life cycle management−Part 3: Guide to the

application of ISO/IEC 12207 (Software life cycle processes)

[26] JIS Q 27001

  情報技術−セキュリティ技術−情報セキュリティマネジメントシステム−要求事項

注記  対 応国際規格 : ISO/IEC 27001,Information technology− Security techniques− Information

security management systems

−Requirements(IDT)

[27] JIS Q 27002

  情報技術−セキュリティ技術−情報セキュリティマネジメントの実践のための規範

注記  対応国際規格:ISO/IEC 27002,Information technology−Security techniques−Code of practice for

information security management

(IDT)

[28] ISO/IEC 27005

,Information technology−Security techniques−Information security risk management

[29] JIS Q 31000

  リスクマネジメント−原則及び指針

注記  対応国際規格:ISO 31000,Risk management−Principles and guidelines(IDT)

[30] ISO/IEC 38500

,Corporate governance of information technology

[31] ISO/IEC 90003

,Software engineering−Guidelines for the application of ISO 9001:2000 to computer software

[32] JIS X 0902-1

  情報及びドキュメンテーション−記録管理−第 1 部:総説

注記  対 応 国 際 規 格 : ISO 15489-1 , Information and documentation − Records management− Part

1:General

(IDT)