ITIL Managing Across the Lifecycle Reference Handbook(Japanese)

ITIL®

ライフサイクル全体の管理(MALC)コースバージョン 1.0

受講者用参考資料

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

www.ITpreneurs.com

Copyrights

ITIL® ライフサイクル全体の管理

本講義資料に含まれる情報は、予告なく変更されることがあります。

この資料には、著作権で保護されている占有情報が含まれています。

本資料のいかなる部分も、ITpreneurs Nederland B.V.の事前の承認を得ずに、複写、

複製、あるいは他の言語に翻訳することはできません。

© Copyright 2013 by ITpreneurs Nederland B.V. All rights reserved.

Copyright and Trademark Information for Partners/Stakeholders.

ITIL® is a Registered Trade Mark of Cabinet Office.

IT Infrastructure Library® is a registered trade mark of the Cabinet Office.

The Swirl logoTM is a trade mark of the Cabinet Office.

All contents in italics and quotes is from the ITIL® Service Lifecycle Suite ©

Crown copyright 2011 Reproduced under licence from the Cabinet Office.

All other text is based on Cabinet Office ITIL® material.

Reproduced under licence from the Cabinet Office.

More on: http://www.itil-officialsite.com/IntellectualPropertyRights/TrademarkLicensing.aspx

Copyright©2013 ITPreneurs, All rights reserved.

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

目次

謝辞 Follow us ユニット 1：主要な概念 1 1.1 サービスの管理とサービスマネジメント 2 1.2 サービス・ライフサイクルと 5 つの段階 6 1.3 エンド・ツー・エンドのサービスの理解：サービスの正当性の

理由、設計、測定、テスト、展開、運用、および改善方法の検討 10

1.4 サービスストラテジの要素が価値を構成するものを決定する方法と価値を定義し測定する方法

15

1.5 サービスオペレーションにおける事業価値の理解 24 1.6 サービストランジションにおけるサービス価値のテストと実証 30 1.7 サービス測定項目のモニタリング、およびサービス・ライフサイクルの全段階での活用 30 1.8 コアサービス、実現サービス、および強化サービス 31 1.9 サービスマネジメントのための組織化 33 1.10 プロセス間のインタフェース、およびライフサイクル間の役割と責任の定義と

明確化のための RACI モデルの活用 35

1.11 リスク・アセスメントおよびリスク管理 40 1.12 サービス・ライフサイクル全体のナレッジの共有、ナレッジマネジメントの活用 50 ユニット 2：コミュニケーションおよび利害関係者の管理 59 2.1 事業関係管理 (BRM) 60 2.2 利害関係者の管理 65 2.3 サービス・モデルの利用 71 2.4 設計活動の調整(全体的活動) 73 2.5 コミュニケーションとコミットメントの管理 74 2.6 コミュニケーション 79 ユニット 3：サービス・ライフサイクル全体にわたるサービスマネジメント・プロセスの統合 85 3.1 サービス・ライフサイクルの他の段階へのサービスストラテジのインパクト 86 3.2 サービス・ソリューションの設計 90 3.3 サービス・ライフサイクル内の各段階、

およびプロセスのインプットとアウトプット 93

3.4 ITIL のすべてのプロセスのインタフェース 99 ユニット 4：サービス・ライフサイクル全体におけるサービスの管理 139 4.1 サービス・ライフサイクルの全段階における顧客と利害関係者のニーズ、

および要件の識別とアセスメント 140

4.2 サービスデザイン・パッケージ(SDP)による、サービスデザイン、サービストランジション、およびサービスオペレーション間の関連付け

145

4.3 サービス・ライフサイクルの全段階で必要とされる適切なインパクトと関与を与えるためのライフサイクル横断のプロセスの管理

150

4.4 改善の必要性を識別する重要な情報源を利用してのサービスの導入、および改善 156 4.5 サービス・ライフサイクルの課題、重要成功要因、

およびリスクとサービス・ライフサイクル全体における潜在的な対立と競合する課題 169

ユニット 5:ガバナンス、役割、人材、力量、および組織 191 5.1 ガバナンス 192 5.2 ソーシングのガバナンス 200 5.3 IT サービスの方向性、方針、戦略の設定 201 5.4 変更の構築とテストの許可 203 5.5 マネジメントシステム 207 5.6 組織の発展 210 5.7 能力とトレーニング 235 5.8 サービス・プロバイダのタイプとサービスストラテジ 237

Copyright © 2013, ITpreneurs Nederland B.V. All rights reserved. |

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

ユニット 6：測定 251 6.1 測定と事業価値の実証 252 6.2 測定基準の決定と活用 253 6.3 測定フレームワークおよび手法の設計と開発 262 ユニット 7：サービスマネジメント能力の構築と改善 267 7.1 サービスマネジメントの導入 268 7.2 サービスマネジメントのアセスメント 273 7.3 サービスマネジメントの改善 294 7.4 サービスマネジメント・プラクティスとサービス両方の導入

および改善についての重要な考慮事項 316

7.5 サービスマネジメント技術の計画立案と導入時における重要な考慮事項 361 MALC 補足資料 365 ITIL 用語および頭字語集 371 ITIL 資格体系 485

| Copyright © 2013, ITpreneurs Nederland B.V. All rights reserved.

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

謝辞

この「ITIL® ライフサイクル全体の管理

(MALC)コース」は、この業界のエキスパ

ートである以下の方々のご協力を受けて

開発されました。ここに、皆様のご貢献に

改めて謝意を表します。エディター：和マネジメント

古賀和子様

SME レビュア：宮入勉様

レビューボードメンバー：株式会社ビーシーエス

杉谷賢昭様

Copyright © 2013, ITpreneurs Nederland B.V. All rights reserved. |

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

www.ITpreneurs.com

Follow us

Facebook

http://www.facebook.com/itpjapan Twitter

https://twitter.com/itpreneursjapan

YouTube

http://www.youtube.com/user/ITPJPN

上記ページでは次のような内容を配信・提供しております：

ITpreneurs の取り扱っているフレームワークに関する最新情報

ITIL をわかりやすく理解するための動画コンテンツ

研修情報のご案内

認定団体に関する最新情報

その他多彩な情報やコンテンツを配信しております。

Copyright©2013 ITPreneurs, All rights reserved.

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

ユニット 1 主要な概念

Copyright © 2013, ITpreneurs Nederland B.V. All rights reserved. | 1

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| ITIL® ライフサイクル全体の管理 | STUDENT |

ユニットの概要このユニットでは、サービスの管理の必要性を説明します。また、サービスの種類とサービス・ラ

イフサイクルの 5 つの段階についても詳しく説明していきます。 1.1 サービスの管理とサービスマネジメント 1.1.1 サービスコアブック該当箇所 - コアブック共通 2.1.1 - 2.1.3 サービスとは、顧客が特定のコストやリスクを追わずに達成することを望む成果を促進すること

によって、顧客に価値を提供する手段です。サービスは関連するタスクのパフォーマンスを向上し、制約の影響を緩和することによって成果

を促進します。サービスに関する制約には、規制、資金不足、キャパシティ不足、技術上の制限

などがあります。また、サービスの結果、求められる成果が得られる可能性が高まり、タスクのパ

フォーマンスを向上させます。タスクのパフォーマンスに直接的なインパクトを持つサービスもあ

ります。顧客満足度はサービス提供の重要な目的です。顧客は、サービスのレベルに満足し、サービス

が顧客にとって十分なものであると確信していなければなりません。サービス・プロバイダは、サ

ービスを提供する能力を確認し、サービスのレベルを維持し続けなければなりません。顧客から

のサービスへのフィードバックは、サービス・プロバイダが長期的にサービスを向上させることに

役立ちます。顧客の期待は絶えず変化します。そのため、もし、サービス・プロバイダが顧客の

期待を追跡しなければ、取引を失ってしまうことになります。サービスは、どのように互いに関連しあい、その顧客と関連するかという観点で論じることができ、

コアサービス、実現サービス、または強化サービスに分類することができます。サービスをより理解するために、図 1.1 を確認してください。

図 1.1 サービスの定義と意味に関する会話 (出典：コアブック共通 2.1.1 図 2.1)

ちょっと聞きたいんだが、サービスの定義を知っているか?

運用においてそれはどのような意味になるんだ?ヒントをくれないか。

コストとリスクを負わずに?顧客はそれらを排除することは望まないだろう。

そうか！プロバイダはそのようなコストとリスクを扱う能力を専門としているからだな。

そのうえ、プロバイダはそのコストとリスクを複数の顧客に分散できることもある。

私が思うに、サービスとは、顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって顧客に価値を提供する手段だ。

サービスは、より良いパフォーマンスのための条件を作り出すために活動、達成目標、タスクにプラスの影響を及ぼすことで成果を促進する。その結果、求められる成果を達成する確立が高くなる。

それはできないが、プロバイダに負わせることができる。それがまさにサービスたる理由だ。顧客が自分たちだけで何とかできるのなら、サービスは必要ないだろう?

そうだ。それに、顧客はその成果に専念したいだろうからね。

サービスマネジメントの本を書こうじゃないか！

(井戸端会議にて)

マネージャ(運用)

マネージャ(戦略)

2 | Copyright © 2013, ITpreneurs Nederland B.V. All rights reserved.

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| STUDENT | ライフサイクル全体の管理 | 主要な概念 |

1.1.1.1 サービスの種類サービスは次のように分類できます：

IT サービス：IT サービス・プロバイダによって提供されるサービス。このサービスは、情報

技術、人材、およびプロセスの組み合わせから成る。顧客向けの IT サービスは、1 つまた

は複数の顧客のビジネス・プロセスを直接支援しなければならない。このサービスのサービ

スレベル目標値は、サービスレベル・アグリーメントに定義する必要がある。支援サービス

のようなその他の IT サービスもある。支援サービスは、事業が直接そのサービスを利用す

るのではなく、サービス・プロバイダが、顧客向けサービスを提供するために必要とされるコアサービス：コアサービスは顧客のニーズを実現し、顧客が喜んで対価を支払おうとする

価値を表す。コアサービスは、顧客による継続的な活用と満足の基盤をもたらす実現サービス：実現サービスは、顧客が、コアサービスとサービスにおける「基本品質要素」

を受けられるようにするサービスである。実現サービスは、コアサービスの提供に必要であ

り、顧客からは見えない強化サービス：強化サービスは、コアサービスに追加されるサービスである。強化サービス

は、「刺激的」な品質要素を追加しコアサービスを強化する。また、顧客にとってより「刺激

的」なサービスとして利用される。強化サービスは、それによって顧客がコアサービスを利

用するようになるが、必ずしも提供される必要があるというわけではないサービスには、簡単なものと複雑なものがあります。簡単なサービスの例には、1 つの ATM トラ

ンザクションを実行するだけのものがあります。複雑なサービスの例は、カスタマー・ケア・サービ

スによる最高のサポートです。大半のサービスはさまざまな成果物と機能性から成る複雑なサ

ービスです。サービス・プロバイダが複雑なサービスを顧客に提供することは非常に難しいです。

サービス・プロバイダがサービスを個々に稼働すれば、たちまち全てのサービスを追跡し記録す

ることができなくなります。ほとんどのサービス・プロバイダは、より一般的なサービスを提供します。また、広範な顧客を獲

得できるように、価格とある一定の柔軟性を適用させることにより、競合と競っています。顧客を

引き付ける方法の1つに、サービス・パッケージの用意があります。サービス・パッケージは、2つ以上のサービスを組み合わせたものです。サービス・パッケージは、特定の種類の顧客ニーズを

満たすソリューションや特定の事業成果を提供します。サービス・パッケージは、コアサービス、

実現サービス、そして強化サービスの組み合わせで構成されます。 1.1.2 サービスマネジメント私たちは、大きなレストランで何かを注文すれば、なるべく早く食べ物がテーブルに運ばれてくる

ことを期待します。もし、顧客ケアセンターに電話すれば、直ちに顧客ケアセンターに電話が繋が

ることを期待します。技術の進歩により、このような、速くて信頼できるサービスを受けられること

を私たちは誰でも知っています。しかし、技術だけがサービスを信頼性の高いものにしているわ

けではありません。顧客の信頼を得るために、サービスの適切な管理も重要な役割を果たして

います。使い勝手のよいサービスの提供のために、技術は重要な役割を果たすので、今日の事業では、

IT が非常に重要になっています。いまのところ、技術だけでは十分に信頼性の高いサービスを

提供することはできないでしょう。専門的で、応答性の高い、価値主導型のサービスマネジメント

が品質の高いサービスを事業にもたらすのです。サービスマネジメントは、顧客に対し、サービスの形で価値を提供する組織の専門能力の集まり

です。もし、サービス・プロバイダが品質の高いサービスの提供に非常に長けていれば、顧客が

求める高品質なサービスを費用対効果の高い方法でタイムリーに提供できるようになります。能力とリソースを価値あるサービスに変換することが、サービスマネジメントの中核となります。

サービス組織がこれらの能力に注力しなければ、サービス組織は顧客にとって価値の低いリソ

ースの集まりになるでしょう。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


サービスマネジメントは、顧客に対し、サービスの形で価値を提供する組織の専門能力の集まり

と定義できます。サービス・プロバイダは 1 つまたは複数の内部顧客または外部顧客にサービス

を供給する組織です。組織の能力は、その能力により克服することが期待される課題によって形づくられる。その一例として、1950 年代のトヨタが米国メーカに比べて規模が小さく金融資本が少ないという課題を克服するために独自の能力を育成したことが挙げられる。トヨタは、抱えることができる在庫量、内製可能な構成部品数、部品製造会社の所有能力などの限界を埋め合わせるために、生産工学、業務管理、およびサプライヤの管理の面で新たな能力を育成した(Magretta、2002)。 (出典：コアブック共通 2.1.2) 組織の能力は組織が持つ課題に影響されます。課題はサービスマネジメント能力に影響を及ぼ

します。また、これらが、サービスを製造業、鉱業、農業などの他の価値創出の仕組みと区別し

ています。組織の能力に影響を及ぼす課題には以下が含まれます：サービス・プロセスのアウトプットや中間製品が無形である性質:測定、コントロール、およ

び妥当性確認(または実証)が困難需要が顧客資産と密接に結び付いている:ユーザと、プロセス、アプリケーション、文書、ト

ランザクションといったその他の顧客資産が需要とともに提供され、サービス生産を活気付ける

サービスの生産者と消費者の接触が非常に密接:サービスを創出するサービス・プロバイダと、そのサービスを消費する顧客の間に緩衝部分がほとんどないか、全くない

サービスのアウトプットとサービス・キャパシティの損耗しやすい性質:顧客にとっては、一定の品質でサービスが供給され続ける確約が得られることに価値がある。プロバイダは顧客から安定した需要を確保する必要がある (出典：コアブック共通 2.1.2)

サービスマネジメントは単なる能力の集まりではなく、広範な知識体系、経験、そしてスキルに支

えられる専門的なプラクティスです。サービスマネジメントの成長と成熟は、主に公共部門と民間部門での個人と組織で構成される

世界的規模のコミュニティによって促進されました。実践している組織や個人の教育、トレーニング、および認証のために存在する正式な制度がその品質に影響する。業界のベストプラクティス、学術研究、および正式な標準はサービスマネジメントの知的資本に貢献しそれを活用している。 (出典：コアブック共通 2.1.2) サービスマネジメントの起源は、航空会社、銀行、ホテル、電話会社などの伝統的なサービス事

業にあります。サービスマネジメントは、IT 組織が IT のアプリケーション、インフラストラクチャ、

およびプロセスをサービス指向のアプローチで管理することでサービスベースの事業の一部とな

ることに伴い、発展してきました。上述したようなサービス事業の IT 組織は、事業上の問題の識

別や解決策の提供を始めました。そして、サービスの形での事業上の問題への解決策やビジネ

ス・モデル、戦略、および事業運営が増えてきました。こういったサービスの形は一般的になり、

また、内部 IT 組織を含むサービス・プロバイダとなる組織も増えてきました。このサービス・プロ

バイダとして機能する IT 組織の増大は、サービスマネジメントのプラクティスを強化しました。同

時にサービス業界への課題も出てきています。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.1.3 IT サービスマネジメント事業組織や人は、情報技術(IT)に対して異なる観点を持っており、異なる方法で ITを理解してい

ます。主な課題は IT サービスマネジメント(ITSM)の価値を伝え、「事業が IT 組織をどのようにとらえているかの状況を理解する際にそれらの観点を認識しバランスをとることである。」 (出典：コアブック共通 2.1.3) 課題には以下が含まれます：

IT は、1 つの大きな製品のシステム、アプリケーション、およびインフラストラクチャの集まり

である。それはらプロセスとサービスで管理される IT は、独自の能力とリソースを持った組織であり、事業機能、シェアード・サービス部門、お

よび企業レベルの中核部門などさまざまな種類がある ITは、事業組織によって活用されるサービスのカテゴリである。この場合、ITアプリケーショ

ンやインフラストラクチャなどが代表的なサービスである。これらのサービスはパッケージ化

され、内部 IT 組織、または外部 IT 組織により提供される。この場合、IT のコストは事業の

経費として扱われる IT は、収益、所得、利益などの利得の流れをオーナに提供する事業資産である。この場合、

IT のコストは投資として扱われる IT 組織は、サービスマネジメントの原則を利用して、サービス・プロバイダとして機能し、顧客に

必要とされる成果を確実に実現しなければいけません。主要な概念は以下のとおりです：

IT サービスマネジメント(ITSM)：事業のニーズを満たす良質の IT サービスを実施および管理すること。IT サービスマネジメントは、IT サービス・プロバイダによって、人材、プロセス、情報技術の適切な組み合わせを用いて実行される

ITサービス・プロバイダ：内部顧客または外部顧客に ITサービスを提供するサービス・プロバイダ

(出典：コアブック共通 2.1.3)

ITSM は、組織の高いパフォーマンスと価値創出を支援します。ITSM は、効果的かつ効率的に

実施されなければなりません。 IT サービス・プロバイダとその顧客の良好な関係は以下にかかっています：

顧客がニーズを満たす IT サービスを受ける受容可能なパフォーマンスのレベル顧客が支払うことが可能なコスト

IT サービス・プロバイダが、合意されたレベルのパフォーマンス、または価格で必要なサービス

の提供ができないようであれば、IT サービス・プロバイダは顧客とコミュニケーションを取る必要

があります。サービスレベル・アグリーメント(SLA)と呼ばれる文書は、IT サービス・プロバイダと顧客の間の

合意として扱われます。SLA は複数の IT サービス、または複数の顧客を対象にする単一の

SLA の場合もあります。SLA は、IT サービスを説明し、サービスレベル目標値を文書化します。

また、IT サービス・プロバイダと顧客の責任を規定します。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.2 サービス・ライフサイクルと 5 つの段階コアブック該当箇所 - コアブック共通 1.2 ITIL サービス・ライフサイクル ITIL のコア書籍は 5 冊のライフサイクル書籍で構成されています。各ライフサイクルの段階は、

ISO/IEC 20000 規格の仕様で要求されている統合的なアプローチで必要とされるガイダンスとな

っています。 ITIL の 5 つの書籍は以下のとおりです：

サービスストラテジサービスデザインサービストランジションサービスオペレーション継続的サービス改善

ITIL のライフサイクルの段階をより理解するために図 1.2 を参照してください。

図 1.2 ITIL サービス・ライフサイクル (出典：コアブック共通 1.2 図 1.1 ) 各書籍は、サービス・プロバイダのパフォーマンスに直接インパクトを与える能力について説明し

ています。 ITIL のコア書籍は、持続的な原則、方法、およびツールによって、サービスマネジメント能力へ

構造、安定性、および強みをもたらすはずです。また、ITIL のコア書籍は、投資を保護し、測定、

学習、および改善に必要な基盤を利用できるようすることに役立ちます。 ITIL の手引きはさまざまな事業環境と組織戦略の支援に役立ちます。ITIL の補完書籍は、多

様な環境でコア書籍の内容を実施するための柔軟性を与えます。ITIL の実務者は、与えられた

状況下でコア書籍の内容を推進させる必要がある場合、補完書籍を選択して利用できます。こ

れらの書籍は、ナレッジ資産の耐久性と移植性を高め、サービスマネジメント能力への投資を保

護します。

継続的サービス改善

サービストランジション

サービスストラテジ

サービスオペレーション

サービスデザイン


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.2.1 サービスストラテジサービスストラテジはサービス・ライフサイクルの中心となるものです。組織の達成目標と顧客の

ニーズを理解することにより、この段階から価値創出のプロセスが始まります。人材、プロセス、

および製品を含む組織資産は、この段階を支持しなければなりません。『ITIL サービスストラテジ』は、実務者がサービスマネジメントを組織の能力としてだけでなく、戦

略的資産として理解するための手引きです。ITIL のサービス・ライフサイクル全体にわたるサー

ビスマネジメントの方針、指針、およびプロセスの策定に役立つ、サービスマネジメントのプラク

ティスの基礎となる原則について説明しています。『ITIL サービスストラテジ』の重要な項目は以下のとおりです：

ターゲット市場の開拓内部プロバイダと外部プロバイダのタイプの特徴サービス資産サービス・ポートフォリオサービス・ライフサイクルを通した戦略の実施事業関係管理需要管理 IT サービス財務管理組織の発展戦略的リスク

組織は、『ITIL サービスストラテジ』を、顧客とターゲット市場にむけてサービスを提供する際の

達成目標や期待されるパフォーマンスを設定するために利用するべきです。また、『ITIL サービ

スストラテジ』を、機会の識別、選択、優先度付けに利用することもできます。サービスストラテジ

とは、組織がサービス・ポートフォリオに関連するコストとリスクに確実に対応できるようになるこ

とに他なりません。もし ITIL をすでに実践している組織であれば、ITIL ベースのサービスマネジメント能力に対する

戦略的レビューの手引きとしてや ITILベースのサービスマネジメント能力と事業戦略との整合性

の改善のためにサービスストラテジを利用することができます。この ITIL ベースのサービススト

ラテジは、サービスマネジメントの実務者とリーダが「どうやってするべきか」と考える前に「なぜし

なければならないのか」について考えたり、探したりするようにします。 1.2.2 サービスデザインサービスは、常に事業に真の価値を提供するための事業達成目標を念頭において設計されな

ければなりません。IT 組織全体を網羅して設計することが、サービスの提供とサポートに役立ち

ます。サービスデザインは、サービス戦略を、事業達成目標を実現するための計画に変換するライフ

サイクルの段階です。また、サービスデザインは、サービスマネジメント・プラクティスの設計と開

発の手引きとなります。サービスデザインは、戦略的達成目標をサービスとサービス資産のポートフォリオに変換する原

則と方法を説明しています。サービスデザインの適用範囲は新規サービスだけではありません。

サービスデザインにおける変更や改善は、サービスのライフサイクルをとおしての顧客の価値、

サービスの継続性、サービスレベルの達成、標準と規制への適合を実現し維持します。サービ

スデザインは、組織がサービスマネジメントの能力を開発し設計する手引きでもあります。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


『ITIL サービスデザイン』には、サービスマネジメントのおいて重要な項目が追加されています。『ITIL サービスデザイン』の項目は以下の通りです：

デザイン・コーディネーションサービス・カタログ管理サービスレベル管理可用性管理キャパシティ管理 IT サービス継続性管理情報セキュリティ管理サプライヤ管理

1.2.3 サービストランジション『ITIL サービストランジション』は、新規および変更されたサービスをサポートする環境に導入す

る能力を開発し改善するための手引きです。サービストランジションでは、リスクをコントロールし、

意思決定支援のための組織のナレッジを支援しながら、組織がある状態から別の状態へ移行す

る方法を説明しています。また、サービスストラテジで識別されサービスデザインで変換された価

値が、サービスオペレーションで確実に実現されるように、確実に効果的に移行されるようにしま

す。『ITIL サービストランジション』では以下の活動のベストプラクティスについて説明しています：

移行の計画立案およびサポート変更管理サービス資産管理および構成管理リリース管理および展開管理サービスの妥当性確認およびテスト変更評価ナレッジ管理

また、サービストランジションは、サービスおよびサービスマネジメント・プロセスの変更における

複雑さを管理し、革新を可能にしつつも望ましくない結果を防ぐための手引きを提供しています。さらに、『サービストランジション』はサービス・ナレッジ管理システムについても説明しています。

このシステムは組織的な学習を支援するものです。このシステムは、サービス・ライフサイクル全

ての段階における全体的な効率性と有効性の改善に役立ちます。このシステムにより、ナレッジ

や経験を共有したり、情報に基づいた意思決定を支援したり、またサービスの管理を改善できる

ようになります。 1.2.4 サービスオペレーション『ITIL サービスオペレーション』は、サポートする環境においてサービスを管理するためのベスト

プラクティスについて説明しています。サービスオペレーションは、顧客、ユーザ、およびサービ

ス・プロバイダにとっての価値を、効率的で効果的に提供しサポートするための手引きです。サービス運用が戦略的達成目標の実現を促すので、サービス運用は非常に重要です。『ITIL サ

ービスオペレーション』はサービス運用における安定性を維持し、設計、規模、適用範囲、および

サービスレベルの変更を可能にするための手引きです。組織には、リアクティブとプロアクティブという 2 つの主なコントロールの観点で利用する詳細なプ

ロセス指針、方法、およびツールが提供されます。サービスオペレーションは、マネージャと実務者に、サービスの可用性の管理、需要のコントロー

ル、キャパシティ活用の最適化、運用のスケジューリング、サービス・インシデントの回避と解決、

および問題の管理で活用できるナレッジを提供してサービスの運用を支援します。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


また、サービス運用を支援する、シェアード・サービス、ユーティリティ・コンピューティング、ウェ

ブ・サービス、モバイル・コマースなどの新しいモデルとアーキテクチャについて説明しています。『ITIL サービスオペレーション』のその他の項目には以下があります：

イベント管理インシデント管理要求実現問題管理アクセス管理サービスデスク技術管理 IT 運用管理アプリケーション管理

1.2.5 継続的サービス改善継続的サービス改善は、サービスのより良い戦略、設計、移行、および運用を通じて顧客の価

値を創出し維持します。継続的サービス改善は、品質管理、変更管理、および能力改善の原則、プラクティス、方法をま

とめたものであり、以下を実施するためのベストプラクティスです：漸進的で大規模な改善の実現運用上の効率性、および事業の継続性の実現サービス・ポートフォリオのビジネス・ニーズとの継続的な整合性の達成

継続的サービス改善では、改善の努力と成果をサービスの戦略、設計、移行、および運用に結

び付けるための手引きが提供されます。また、計画・実施・点検・処置(PDCA)サイクルに基づく

閉ループのフィードバック・システムが確立します。これにより、サービス・ライフサイクルの任意

の段階からのフィードバックを使用して、ライフサイクルの他の段階を改善する機会を識別できま

す。継続的サービス改善のその他の項目には、サービス測定、測定基準による価値の実証、ベース

ラインの作成、および成熟度アセスメントが含まれています。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.3 エンド・ツー・エンドのサービスの理解：サービスの正当性の理由、設計、

測定、テスト、展開、運用、および改善方法の検討コアブック該当箇所 - コアブック共通 2.4 概要サービスとプロセスは構造を持ったつながりと、それらの変化を見えるようにします。これらの構

造は、サービスマネジメントに対して必要な適切な行動の決定に役立ちます。構造は、プロセス、人材、技術およびパートナ間の繋がりを明確に示しています。構造がなけれ

ば、サービスマネジメントのナレッジは、観察、プラクティス、および対立する最終目標の集まりで

しかありません。サービス・ライフサイクルの構造は、体系化のフレームワークでもあり、組織の構造、サービス・

ポートフォリオ、および組織内のサービス・モデルによって維持されます。構造は、組織と人の行動に影響を及ぼしたり、それらを決定したりする可能性がある。サービスマネジメントの構造を変更するほうが、単に個々のイベントをコントロールするよりも効果的な場合もある。構造がなければ、経験から学習することは困難であり、将来に向けた教育に過去を利用することが困難になる。我々は経験から学べるが、自分の行動の最も重要な結果の多くに直接向き合うことも必要である。 (出典：『サービスストラテジ』またはコアブック共通 2.4)

1.3.1 ライフサイクルにおける専門化と調整組織は、顧客へのサービスの提供およびサポートに使用する資産の管理に、協調的なアプローチを取る必要がある。組織は、パフォーマンスの高いスポーツ・チームと同じように機能するべきである。チーム内の各選手および選手以外のチーム組織の各メンバは、チームの最終目標を支持する立場にある。各選手と各チーム・メンバはそれぞれ異なる専門を持ち、全体に貢献する。チームは、経験、ベストプラクティス、現行のプロセス、および手順からのフィードバックを考慮しつつ、時間とともに成熟した結果、パフォーマンスが高く、機敏性のあるチームになる。 (出典：『サービスストラテジ』またはコアブック共通 2.4) ライフサイクルにおいては、専門化と調整が重要になります。ライフサイクル・アプローチでは専門化と調整が必要である。専門化によってサービスのコンポーネントヘの専門的な重点化が可能になるが、サービスのコンポーネント同士も価値を求めて共同作業する必要がある。専門化と調整を組み合わせることは、専門能力を管理し、重点化を向上し、プロセスにおける重複とギャップを減らすことに役立つ。専門化と調整は一緒になって、資産の活用を最大化するような、協調的で機敏性のある組織のアーキテクチャを形成することを支援する。ライフサイクル全体にわたる調整によって、IT の達成目標やプロジェクトだけではなく、事業と顧客の成果を重視した環境が形成される。調整は、機能グループ間、バリュー・ネットワーク全体、プロセスと技術の間においても不可欠である。組織の資産間のフィードバックとコントロールを行うことによって、運用上の効率性、組織の有効性、規模の経済が実現できるようになる。 (出典：『サービスストラテジ』またはコアブック共通 2.4)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.3.2 サービス・ライフサイクルを通したプロセス ITIL ライフサイクルの各コア書籍には、表 1.1 に示すように、サービスマネジメント・プロセスに関する手引きを記載している。 (出典：『サービスストラテジ』またはコアブック共通 2.2)

ITIL ライフサイクル・コア書籍書籍で説明されているプロセス ITIL サービスストラテジ IT サービス戦略管理

サービス・ポートフォリオ管理 IT サービス財務管理需要管理事業関係管理

ITIL サービスデザインデザイン・コーディネーションサービス・カタログ管理サービスレベル管理可用性管理キャパシティ管理 IT サービス継続性管理情報セキュリティ管理サプライヤ管理

ITIL サービストランジション移行の計画立案およびサポート変更管理サービス資産管理および構成管理リリース管理および展開管理サービスの妥当性確認およびテスト変更評価ナレッジ管理

ITIL サービスオペレーションイベント管理インシデント管理要求実現問題管理アクセス管理

ITIL 継続的サービス改善 7 ステップの改善プロセス表 1.1 各 ITIL 書籍で説明されているプロセス(出典：『サービスストラテジ』またはコアブック共通 2.4 表 2.1) サービスマネジメントは、サービスに関わる人たちがサービス・ライフサイクルをとおしてプロセス

の相互作用を理解すると、より効果的なものとなります。これらの相互作用は、組織内やユーザ、

顧客、サプライヤのような他の当事者との間でよくあります。サービス・ライフサイクル全体にわたるプロセスの統合は、サービス・オーナ、プロセス・オーナ、

プロセス実務者、およびその他の利害関係者に依存します。

各プロセスの使用状況、適用範囲、目的、限界プロセスに適用される、およびプロセス間のインタフェースの管理に適用される戦略、方針、

標準各プロセスに関与する人の職務権限と責任 1 つのプロセスから別のプロセスに流れる、各プロセスによって提供される情報とその作成

者、および統合されたプロセスでの使用方法


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


サービスマネジメント・プロセスの統合は、プロセスおよび組織の境界を越えた情報の流れに左右される。ひいては、縦割りではなく、組織の境界を越えた支援技術と管理情報システムの導入に左右される。サービスマネジメント・プロセスが単独で導入、遵守、または変更されると、投資に見合う価値を提供しない官僚的なオーバヘッドになりかねない。さらに、運用または他のプロセスとサービスの価値を損ねたり、価値をなくしたりする可能性もある。各プロセスには明確な適用範囲があり、インプットを変換してアウトプットを確実に提供する体系的な一連の活動を伴う。プロセスのインタフェースはプロセスの境界である。プロセスの統合とは、効果的かつ効率的に情報が1つのプロセスから別のプロセスに流れるようにしてプロセス同士を結び付けることである。プロセスの統合へのマネジメントのコミットメントがあれば、通常はプロセスを導入しやすくなり、プロセス間の対立が少なくなる。ライフサイクルの各段階は、事業価値の実現に向けてサービスマネジメントの最終的な達成目標を支援するために、統合されたシステムとして一体となって機能する。 (出典：『サービスストラテジ』またはコアブック共通 2.4) 図 1.3 はサービス・ライフサイクルの各段階が相互に依存している様子を表しています。SKMSはサービス・ライフサイクル全段階にわたる統合を可能にします。 SKMS は、サービスの管理および提供に必要なナレッジ、情報、データヘの、コントロールされた安全なアクセスを提供する。サービス・ポートフォリオは、ライフサイクルのさまざまな段階において現在使用されている、または解放されているすべての資産を表す。 (出典：『サービスストラテジ』またはコアブック共通 2.4) サービス・ライフサイクル全体にわたる統合の詳細は、図 1.3 を参照してください。

図 1.3 サービス・ライフサイクル全体にわたる統合(出典：『サービスストラテジ』またはコアブック共通 2.4 図 2.9)

事業／顧客要件

変更提案サービス憲章


戦略方針

リソースと制約


ザービストランジション


継続的サービス改善

CSI管理表、改善措置改善計画

目標値に照らした達成度

実運用／稼動中のサービス

事業価値

ソリューション設計

アーキテクチャ標準

サービスデザイン・パッケージ

新規／変更された／廃止済みサービス

テスト済みのソリューション

SKMSの更新移行計画の実施

サービス・ポートフォリオ

サービス・カタログ

サービス・ナレッジ

管理システム


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


ここでは、ライフサイクルが相互にどのように作用するかを理解することが重要です。サービスストラテジはサービス・ライフサイクル全体の手引きとなる方針と原則を決定します。サ

ービス・ポートフォリオはこの段階で定義され、新規または変更されたサービスが制定されます。

ライフサイクルのサービスデザインの段階で、新規または変更されたサービスがサービスデザイ

ン・パッケージに文書化されます。またこの段階で、サービスの開発、移行、および運用に必要な要素が設計されます。必要な要

素とは、管理情報システムとツール、アーキテクチャ、プロセス測定方法と測定基準などです。ラ

イフサイクルのサービストランジション段階とサービスオペレーション段階の活動は、サービスデ

ザインで定義されます。サービストランジションはサービスデザインで開発されたサービスストラ

テジの要件を、障害と中断のリスクをコントロールしながら、サービスオペレーションで効果的に

実現されるようにします。サービスオペレーションの段階では、合意されたサービスを提供するために必要な活動とプロセ

スを実行します。ライフサイクルのこの段階で、サービスストラテジで定義された価値が実現される。継続的サービス改善は、ライフサイクルの他のすべての段階と連携して作用する。すべてのプロセス、活動、役割、サービス、技術は測定され、継続的改善の対象とするべきである。 ITIL のほとんどのプロセスと機能には、サービス・ライフサイクルの複数の段階にわたって行われる活動がある。例として、次が挙げられる。

サービスの妥当性確認およびテストのプロセスは、サービスデザイン段階でテストを設計し、サービストランジションでこれらのテストを実施する

技術管理機能は、技術に関する戦略的意思決定にインプットを提供するだけでなく、インフラストラクチャ・コンポーネントの設計と移行を支援する

事業関係マネージャは、ライフサイクルのサービスデザイン段階で詳細な要件の収集を支援したり、サービスオペレーション段階で重大なインシデントの管理にかかわったりする

サービス・ライフサイクルのすべての段階は、7 ステップの改善プロセスに貢献する付録 I に、サービス・ライフサイクルの各段階間の主要なインプットとアウトプットの一部を示している。各 ITIL コア書籍の第 3 章では、その書籍が説明する特定のライフサイクル段階のインプットとアウトプットについて、より詳細に説明しているサービス・ライフサイクルの強みは、ライフサイクルの各段階を通した継続的なフィードバックにある。このフィードバックによって、サービスの最適化が事業の観点から管理されること、そして、サービス・ライフサイクルにおける任意の時点で事業がサービスから得る価値の面から測定されることが確実になる。サービス・ライフサイクルは設計上、直線的ではない。サービス・ライフサイクルのあらゆる時点で、各段階の間のモニタリング、アセスメント、およびフィードバックのプロセスによって、軽微な軌道修正や重要なサービス改善の取り組みの必要性についての意思決定が促される。図 1.4 に、サービス・ライフサイクルに組み込まれた、継続的なフィードバック・システムの例を幾つか示す。 (出典：『サービスストラテジ』またはコアブック共通 2.4)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 1.4 継続的サービス改善とサービス・ライフサイクル(出典：『サービスストラテジ』またはコアブック共通 2.4 図 2.10) 適切な技術を採用してプロセスを自動化し、プロセスをサポートする情報をマネジメントに提供することも、効果的かつ効率的なサービスマネジメントに重要である。 (出典：『サービスストラテジ』またはコアブック共通 2.4)


戦略、方針、標準

フィードバック改善のための教訓フィードバック

改善のための教訓


サービスとサービスマネジメント・プロセスの作成と修正の計画


新規または変更されたサービスやサービスマネジメント・プロセス

の本番への移行の管理

サービスとサービスマネジメント・プロセスの日常的な運用


継続的サービス改善活動はサービス・ライフサイクルに組み込まれている

アウトプット

アウトプット

アウトプット

フィードバック改善のための教訓




Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.4 サービスストラテジの要素が価値を構成するものを決定する方法と価

値を定義し測定する方法 1.4.1 事業に対する価値コアブック該当箇所 - 『サービスストラテジ』1.1.4、3.2.3 推奨されているベストプラクティスの実施により、組織はベストプラクティスがもたらす価値を得ら

れます。サービスストラテジの標準的で一貫したアプローチを採用すると次につながります：サービス・プロバイダが実行する活動と結果を結びつけるスキルを奨励する。それによって、

単にコストへの貢献だけでなく組織に価値を付加できるサービス・プロバイダが、よりよいサービスの創出のために顧客を満足させるサービスの種

類とレベルについて明確に理解する。IT サービス・プロバイダは、戦略とサービスの定義、

およびすべての利害関係者が利用できる価値を創出し提供するための方法の定義に一貫

した反復可能なアプローチを確かなものとするサービス・プロバイダが、事業環境の変化に迅速かつ効果的に対応できるようになり、競争

上の優位性が増すサービスにおいてプラスの投資利益率を達成するための事業を運営する定量化されたサ

ービスのポートフォリオの作成と維持を支援する要件や伝達方法をより詳しく理解できるようになることにより、顧客とサービス・プロバイダ

間での実際に役立つ、曖昧さのないコミュニケーションを支援するサービス・プロバイダが組織化された方法で自身を管理しサービスを提供できる

1.4.2 サービスの価値サービスの価値は顧客の期待を満たす度合いとして測定されます。サービスの価値は、サービ

スのコストやサービス自体のそのほかの固有の質の程度ではなく、顧客がサービスに対して進

んで対価を支払おうとする程度で測定されます。製品とは違ってサービスにはそれほど多くの固有の価値はありません。サービスの価値はそれ

で何ができるかによって決まります。さらに、サービスの価値はプロバイダによってではなく、サ

ービスを受ける人によって決定されます。サービスを受ける人は、サービスを利用することで実

行しよう、または達成しようとしていることでサービスを決定します。そのため、価値の重要な特徴は以下となります：

価値は顧客によって定義される：顧客は、サービス・プロバイダが宣伝する価値によってで

はなく、最終的に顧客自身でサービスの価値を決める手ごろな特徴の組み合わせ：優れた販売員は、顧客の価値への認識に影響を及ぼすこと

はできるが、サービスの価値を決めるのは顧客である。また、顧客は、顧客が支払う意思

のある価格内での最善の特徴の組み合わせを決める達成目標の実現：財務は、最終的な結果を達成するために必要なサービスに、どれだけ支

払い準備があるかを示すかもしれないが、顧客は必ずしも財務的な視点で価値を測定して

いるわけではない。多くのサービスは、社会的責任プログラムや人的資源管理など、なんら

かの組織の達成目標を実現するために設計されている。営利組織は、一般的に、財務的

な利益からサービスを測定する傾向があるが、政府機関は他の達成目標に焦点をあてる

傾向がある。例えば、警察は犯罪の減少または犯罪者の逮捕に焦点を当てることがあり、社会福祉部門は、貧困な家庭に支払う援助額に焦点を当てることがあり、山岳救助機関は、なだれについて警告した人の数、または救出した人の数に焦点を当てることがある

(出典：『サービスストラテジ』 3.2.3)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


価値は時間と状況によって変わる：顧客の要件は時と共に変化する。今日、顧客にとっ

て価値のあることが、1 年後には価値がないかもしれない。顧客のサービスに対するニ

ーズや価値は移りゆく環境のなかで変化する。例えば、小売店は、景気が良いときには、

多くの高級品を売ることに焦点を当てることがあるが、不景気のときには、低価格の製品ラインに焦点を変えて高級品を減らす


サービスの価値がサービスを受けるためのコストよりも高いと考えられた時にだけ、サービスが

組織に価値をもたらします。そのため、IT の価値を理解するには、次の 3 つの情報が重要です:

IT はどのようなサービスを提供したか：IT がサーバ群、ネットワーク、PC だけを管理するも

のと考えられているのであれば、顧客がどうやってサービスが価値に貢献しているのかを

理解することは難しい。顧客がサービスの価値を計算するには、特定の個別のサービスを

決め、それを特定の事業活動や結果に直接関連づける必要がある。例えば、IT 組織はアプリケーション・ホスティングが事業に価値を提供すると主張する。しかし、事業は、アプリケーション・ホスティングとは何か、または、どのアプリケーションがホスティングされているかを知らない。IT組織が価値を伝えたいなら、顧客が実際に何を認識しているかを特定し、活動をサービスに結び付ける必要がある。サービス・ポートフォリオ、および特にサービス・カタログは、IT がこれを定量化するのに役立つ


サービスが何を達成したか：顧客はサービスから得られる利点を識別し、顧客と組織にお

けるサービスの重要度を決定するサービスのコストはどれぐらいだったか、またはサービスの価格はどれぐらいか：サービス

により達成できたことをサービスのコスト、または価格と比較することで、顧客はサービスの

価値を判断する。IT がサービスのコストを決定できない場合、価値を提供したと主張するのは非常に難しく、また、顧客が IT を「価値ある」ものと認識するのは非常に難しい


1.4.2.1 価値創出金銭的な観点でサービスの価値を算出することは時には簡単であるかもしれません。

例えば、顧客は、新しい製品ラインの販売をサポートするサービスを必要とする。必要なことがサービスによって実施され、コストは製品ラインの収益性にマイナスのインパクトを与えず、価格は競争力を維持している場合、顧客はそれを価値のあるものと認識する可能性が高い。


サービスの成果が金銭的なものでない場合、その価値を定性化することは可能であっても、価

値を定量化することは難しいです。

例えば、市の管理部門は、交通の流れを改善するために交通信号を調節できるように、市の中心における交通状態を追跡できるサービスを必要としている。サービスによってそれが可能になり、サービスが市の予算内に収まる場合、価値があると認識される可能性が高い。


しかしながら、価値はサービスの役割やコスト以上のものです。価値は 3 つの領域によって特徴

付けられる必要があります。

価値は、達成された事業成果、顧客の好み、および提供されたものに対する顧客の認識という 3つの領域によって定義する必要がある。 (出典：『サービスストラテジ』 3.2.3)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 1.5 にて、価値の特徴を示しています。

図 1.5: 価値の構成要素(出典：『サービスストラテジ』 3.2.3 図 3.6) 価値は顧客の事業成果の観点だけでなく、顧客の認識や好みに左右されます。顧客の認識は、

サービスの属性、同様の属性のサービスの現在あるいは過去の経験、また競合や同業者の相

対的な能力から影響をうけています。また認識は、革新者、市場リーダ、リスクを恐れないなどの顧客のセルフイメージや市場での実際のポジションにも影響される。サービスの価値はさまざまな形を取り、顧客にはそれぞれの認識に基づいた好みがある。顧客の好みと認識は、あるサービス提供内容またはサービス・プロバイダの価値をどのように他者と区別するかに影響する。 (出典：『サービスストラテジ』 3.2.3) 価値の定義や差別化は、価値に対する不確実性が存在する場合は、より重要になります。顧客

は、サービスの利用と利点の実現との因果関係が疑わしい場合には、購入をためらいます。サ

ービス・プロバイダは情報の提供や顧客の好みに応じることによって顧客の価値の認識に影響

を及ぼさなければなりません。

好み認識

価値

事業成果


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


顧客の価値認識に対する理解サービス・プロバイダはサービスの価値を決定できないが、サービスの価値がどのように顧客によって認識されるかに影響を及ぼすことができる。図 1.6 に、顧客がどのように価値を認識するかを示す(Nagle&Holden、2002 に基づく)。この図において、顧客認識の開始点は参照値である。これは、顧客がサービスに関して聞いたことがある情報、現在、顧客が自分たちでその活動を行っているという事実、またはそのサービスや同様のサービスにおける過去の経験に基づいていることがある。 (出典：『サービスストラテジ』 3.2.3)

図 1.6：顧客はどのように価値を認識するか(出典：『サービスストラテジ』 3.2.3 図 3.7) 「参照値」は、定義があいまいな場合もあれば、具体的な事実に基づいている場合もあります。参照値の例としては、顧客が内部の機能やサービスのコストについて維持するベースラインがある(DIY(do-it-yourself)戦略、つまり各自でやりくりする戦略)。サービス・プロバイダがこの参照値が何かを理解し、感じ取ることが重要である。そういった理解は、顧客との広範な対話、同一または同様の顧客との過去の経験、市場で入手可能な調査および分析などから得られる。 (出典：『サービスストラテジ』 3.2.3) サービスのプラスの差は、サービス・プロバイダによって提供される、認識された追加的な利点と利益に基づいている。これらの差は、サービス・プロバイダが提供できる追加的な保証と有用性に基づいている。これは、サービス・プロバイダが顧客の認識に最も影響を及ぼすことができる部分である。これには、次の項で説明するマーケティング・アプローチが必要である。サービスのマイナスの差は、サービスに投資することにより顧客が失うものの認識である。例えば、顧客は品質の課題や隠れたコストを認識することがある。サービスには、提示価格で顧客が期待する十分な機能性がないことがある。また、サービス・プロバイダは、顧客要件を聞き、それらにサービスの特徴を一致させることにより、この領域に影響を及ぼすことができる。また、サービスの強みを強調することにより、顧客の優先度に影響を及ぼそうとすることもできる。

マイナスの差プラスの差

_

+サービスの利用による利益

参照値サービスの経済的価値

独自の戦略か既存の取り決めに基づく

最終的な差

サービスの利用による損失


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


実質の差は、マイナスの差を割り引いた後の参照値と比べて、どのくらいサービスが優れているか(または劣っているか)について、顧客が持っている実際の認識である。これは、サービスに投資するかどうかに関する顧客の意思決定を促す領域である。 (出典：『サービスストラテジ』 3.2.3) 経済的価値は、サービスによって提供されると顧客が認識する全体的な価値です。これは、参照値に、顧客が受け取るサービスの実質の差を足したもの(または、引いたもの)を含み、求められる成果を実現する能力として顧客によって測定される。 (出典：『サービスストラテジ』 3.2.3) 何よりも事業成果に焦点をあてることは、多くのサービス・プロバイダの前途にとって重要な前進

です。これは、リソースの効果的な活用から成果の効果的な実現へ焦点が移ったことを意味しま

す。運用の効率性は、顧客の成果実現を支援する際の効果の必要性により決まります。顧客は

サービスを購入するのではありません。顧客は特定のニーズの充足を購入するのです。この違

いは、IT 組織と、そのサービスの提供先である事業との間に起る食い違いを説明するものにな

ります。顧客が評価するものは、IT 組織自身が提供していると認識しているものとは異なる場合

が多いです。マーケティングの思考形態価値を理解して伝えるには、サービス・プロバイダがマーケティングの思考形態を持つ必要があ

ります。ここで言うマーケティングとは顧客認識に影響を及ぼすようにサービスを宣伝するだけで

はなく、顧客の観点と要件を理解し、顧客の満足する成果を実現するように、サービスを調整す

ることです。重要である成果とは何か?顧客の認識と好みに関して、成果はどのように特定され順位付けられるのか?そのような質問に効果的に答えるには、エンジエアリングや運用の思考形態とは大きく異なるマーケティングの思考形態が必要である。サービスの開発について内部に焦点を当てるよりも、顧客の視点から判断し、外側から内側ヘと目を向ける必要がある。マーケティングの思考形態は単純な問いかけから始まる。

我々の事業は何か? 我々の顧客は誰か? 顧客が評価するものは何か? 我々のサービスに依存しているのは誰か? 我々のサービスを彼らはどのように使うのか? 我々のサービスは彼らにとってなぜ価値があるのか?

価値はさまざまなレベルで付加できる。重要なのは最終的な差である(図 1.6)。例えば、サービス・プロバイダは、資産として機器ベンダの機器を使用しながらも、純粋に付加価値によって自分たちを機器ベンダと差別化する。ルータやサーバではなく、通信サービスを提供することで差別化を図ることができる。また、単なる電子メール・サービスやボイスメール・サービスの運用ではなく、コラボレーション・サービスの提供によって、さらに差別化することができるかもしれない。サービス属性から成果の実現に焦点がシフトする。マーケティングの思考形態によって、顧客が価値を見いだす要素を理解することができる。 (出典：『サービスストラテジ』 3.2.3)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.4.2.2 付加価値と実現された価値 Porter (1996)は、コストと価値の関係について詳しく説明するためにバリュー・チェーンの概念を

導入しました。バリュー・チェーンとは、顧客にとって価値のある製品やサービスを作り出す、連鎖した複数のプロセスのことである。この連鎖内の各ステップは、前のステップに重ねて実施され、製品またはサービス全体に貢献する。図 1.7 に、簡単な IT バリュー・チェーンを示す。 (出典：『サービスストラテジ』 3.2.3)

図 1.7: 費やされた資金、付加価値、実現された価値(出典：『サービスストラテジ』 3.2.3 図 3.8) 図 1.7では、サービスを提供するために多数のコンポーネントが使用され、各コンポーネントは ITの部門よって管理されている。データベースはデータベース管理部門によって管理され、アプリケーションはアプリケーション管理部門によって管理され、アプリケーション・ホスティングはアプリケーション・ホスティング部門によって実行されている。


資金は、各コンポーネントの調達、開発、維持に費やされます。さらに、各部門は、給料、オフィ

ス・スペース、諸手当などに資金を使います。各部門がコンポーネントを管理し、それを有効的に

機能させることで、サービスに付加価値をつけることができます。例えば、データベースだけでは価値はそれほど高くないが、アプリケーションをデータベースと組み合わせると、2 つのコンポーネントのコストより高い価値がある。アプリケーション・ホスティングと組み合わせると、サービスは、さらに価値のあるものになる。 (出典：『サービスストラテジ』 3.2.3)

価値を付加する秘訣は、サービスに別のステップが付け加えられる毎にそのステップに到達す

るまでに費やされた資金(初期投資や各ステップで付け加えられた現在のコスト両方)より大きな

割合でサービスの価値を増加させることです。言いかえれば、バリュー・チェーンの各ステップの

あとに、サービス・プロバイダが「我々は、今持っているものを売った場合、それに費やした以上

の大きな価値があるのだろうか」と質問できるはずです。ここでは、たとえ話が役に立つでしょう。レストランは生の食材を購入します。もしその地域で他

に供給者がいなければその食材を売ると僅かな利益を得られるかもしれません。もしレストラン

がいくらかの資金をつかって生の食材を組み合わせて調理し、おいしい料理を作った場合、実際

にかかった食材や電力などのコスト以上にはるかに高い料金をその食べ物に対して請求できる

しょう。食事に飲み物をつけて出すとさらに価値が高まります。

費やされた資金

データベースアプリケーションアプリケーション・ホスティングコミュニケーションエンド・ユーザ・コンピューティング顧客

付加価値実現された価値


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


バリュー・チェーンの重要な特徴は、サービスの真の価値は、価値が実現された後だけに算出で

きる、ということです。図 1.7 では、求められる成果を顧客が達成したときに、サービスの価値が

発生していることを説明しています。商業部門では、サービスに対して実際にかかったコストより

多く支払った場合にのみ、サービス・プロバイダは、価値が付加されていたことを確認できます。

公共部門では、外部顧客は、通常、納税者です。価値の付加には次のようなルールがあります：価値が実現されたら(サービスが求められる成果を達成したら)初めて、付加価値の量を計

算できる実現された価値は、費やされた資金より高くなければならない。これは、財務的な視点で測

定しても(例えば、顧客がサービスにどれだけ支払ったか)、財務的でない視点で測定しても(例えば、政府機関は、1日に計画されている数の運転免許証の申し込みを処理できたか?)当てはまる。これらの場合には、成果の財務的でない価値は、サービスの財務コストと比較される。その後、サービスが有益かどうかについて意思決定が行われる

実現された価値が費やされた資金より高くない場合、サービス・プロバイダは価値を付加していない。逆に、資金を費やした(そして損失を出した)だけということである


これらのルールは IT 組織にも適用されます。以下に具体例を挙げます：

価値を付加したことを IT が示したい場合、その活動を、事業が価値を実現する部分に関連付けなければならない

これができない場合、IT は価値を付加する組織でなく、資金を浪費する組織と認識される資金を浪費する組織が価値を証明できる唯一の方法は、コストを削減することである(それ

により、おそらく利益幅を増やす)。これでは悪循環に陥ることになる。IT が価値を付加していると認識されていないため、事業はコスト削減を要求する。コストを削減すると、価値を付加する能力がさらに低下して、事業はさらなるコスト削減を要求する


それでは、IT が「資金を浪費している部門」ではなく、「価値を付加している部門」と認識してもら

うためにはどうすればよいのでしょうか。それは、IT 活動とサービスを関連付けることで可能です。

言いかえると、IT の活動が事業成果を達成するために役立つと示すことができない限り、IT は

活動を実施するべきではない、ということです。これについての詳細は次のセクションで詳しく説

明します。バリュー・チェーンに関する重要な注意図 1.7 に、付加価値と実現された価値の基本原理を示すために、非常に簡単なバリュー・チェーンを示している。実際には組織(特に大規模な組織)において価値を創出し実現することは、はるかに複雑なことであり、複数のバリュー・チェーンが、同時に、共通コンポーネントにわたって運用される。この複雑さは、バリュー・ネットワークの概念を使用することで、より適切に示される。 (出典：『サービスストラテジ』 3.2.3)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.4.2.3 「付加価値」と「実現された価値」の関連付けサービスを提供するために使用するインフラストラクチャ、アプリケーション、およびスタッフは、

一般的には顧客には見えないため、どれだけの価値がサービスに付加されたかを理解するの

は難しいです。投資について顧客に説明する試みは、防御手段であり、サービスの価格を押し

上げるための試みと認識されます。それよりも、サービス・プロバイダは、各内部サービスの貢献

を測定し、それを顧客の事業成果の達成に関連付けることができるモデルの構築に焦点を当て

るべきです。

図 1.8 に、価値の点から IT サービス・プロバイダによって内部顧客と外部顧客に提供される内部サービスと外部サービスを示す。サービスの種類を示す代わりに、これらのサービスのどれが価値を付加したり実現したりしているか、およびどれが「費やされた資金」として分類されるかを示している。


図 1.8 : IT サービスと価値(出典：『サービスストラテジ』3.2.3 図 3.9)

価値は、サービスが外部顧客に提供され、外部顧客の期待を満たしたときに実現されます。価

値は事業成果が実現されたかどうかの点で測定されます。通常、営利組織では、これは利益ま

たは利益幅として測定されます。非営利組織、および政府機関では、財務的でない視点で測定

されることが多いです。

図 1.8 において、付加価値サービスは、外部顧客に対するサービスに関連付けることができた場合のみ、付加価値サービスとして認識される。外部サービスヘの関連付けがなければ、「費やされた資金」と見なされる。支援サービスは、外部サービスから少なくとも 1 ステップ少ないものである。価値があると見なされるには、サービス・プロバイダは、内部または外部の IT サービスに関連付けることができる必要がある。これは、サービス・プロバイダがすべての内部サービスを顧客に公開するべきという意味ではない。むしろ、サービス・プロバイダが、事業(または政府組織の部門)の成果への各内部サービスの貢献を測定できるようになることを意味する。

これにより、サービスの保証および有用性を効果的に伝達できるため、顧客によるサービスの価値の認識を強めることになる。


外部顧客外部顧客外部顧客外部顧客外部顧客外部顧客

事業部門(内部顧客)

事業部門(内部顧客)

事業

IT

IT部門 IT部門 IT部門

ITサービス

価値を実現するサービス

価値を付加するサービス。価値を実現するサービスと関連付けなければならない

費やされた資金価値。価値を付加または実現するサービスと関連付けなければならない

価値を実現するビジネス・サービス


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


価値とサービス・パッケージ付加価値と実現された価値の概念は、サービス・パッケージがどのように定義、構築、および提供されるかに関する主な推進要因の 2 つである。3.4.7 と 3.4.8 では、これらの概念について詳細に記述しているが、同様の価値の変動性が該当することに注意するべきである。例えば、外部顧客向けのサービス・パッケージは、サービス・ヵタログに定義できる(実現された価値)。この外部サービス・パッケージは、内部サービス・プロバイダによって提供される 1 つまたは複数の内部サービスまたはサービス・パッケージを含むことができる(付加価値)。これらは、さらに内部 IT 組織によって提供される支援サービスで構成されるサービス・パッケージを含むこともある(費やされた資金)。 (出典：『サービスストラテジ』 3.2.3) 1.4.2.4 価値獲得価値獲得とは、創出および実現された価値の一部を保持するサービス・プロバイダの能力のことである。サービス・プロバイダが自身を差別化し、時間の経過とともにより大きな価値を提供する能力は、サービスを運用するコストに加えて、サービスを開発し改善するためにサービス・プロバイダが資金を得られるかどうかに依存している。価値獲得は、この資金を得るための優れた方法である。なぜなら、そのような開発のコストをサービスに直接関連付けるほうが簡単であり、顧客にとってはサービス改善の価値を評価するほうが簡単であるからである。 (出典：『サービスストラテジ』 3.2.3) 価値獲得は全ての内部サービス・プロバイダ、外部サービス・プロバイダ、全てのサービス・プロ

バイダのタイプにとって欠かせない概念です。優れた事業センスであっても価値の獲得を実証し

ないかぎり、理解関係者は組織の能力に大規模な投資をしようとしません。内部サービス・プロ

バイダは事業の中で存続可能な組織であり続けるために、戦略的な観点を採用することが推奨

されます。コストの回収は必要ですが、それだけでは十分ではありません。利益または剰余金が、

能力に直接影響を持つサービス資産の継続的な投資を可能にします。しかしながら、価値獲得の規則や境界が IT 組織により設定されようとなかろうと、またはどこで

設定されようとも、価値の獲得は、組織の役員が戦略的決定を行います。特に内部 IT 組織は価

値の獲得は許されず、管理可能なレベルで運用しなければなりません。この場合、通常は中央

の予算から状況に応じて予算を獲得しなければなりません。価値創出を価値獲得は繋げることは複雑ですが必要な努力です。簡単に言うと、顧客は、特定

の事業成果を達成するために、計画の一環としてサービスを購入します。例えば、ワイヤレス・メッセージング・サービスの利用によって、顧客の販売スタッフがセールス・フォース・オートメーション・システムに安全に接続し、販売サイクルの重要なタスクを完了することができる。これはやがて、繰越支払いによって、キャッシユ・フローに良い影響をもたらす。ワイヤレス・サービスを利用して迅速に処理される購入注文書と請求書を関連付けることで、事業成果へのサービスのインパクトに気付くことができる。このインパクトは、売掛金回収期間、受注から入金までのサイクルの平均時間などの点から測定できる。次に、サービスの総利用コストを事業成果ヘのインパクトと比較することができる。 (出典：『サービスストラテジ』 3.2.3) サービス利用とキャッシュ・フローの変化との間の因果関係を確立することは簡単ではありませ

ん。非常に頻繁にサービス利用と顧客が最終的に得る利点の間にはいくつかのレベルの隔たり

があります。絶対的な確実性の達成は難しいですが、それでも意思決定は向上します。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.5 サービスオペレーションにおける事業価値の理解コアブック該当箇所 - 『サービスオペレーション』 3.1 サービスオペレーションの原則の概要サービスオペレーションを考える時、日々の活動や技術の管理自体を目的として、それだけに焦

点を当ててしまいがちです。しかし、サービスオペレーションはより広い概念で、より広範囲な状

況で利用されます。サービス・ライフサイクルの一部として、サービスオペレーションは次のことに責任を負う。

サービスのコストや品質を最適化するプロセスを実行し、遂行する事業が達成目標を実現するようにする

技術領域の一部として、サービスオペレーションは次のことに責任を負う。

サービスをサポートするコンポーネントを効果的に機能させるサービスを管理および提供するために、運用コントロール活動を実行する

事業全体の一部として、サービスオペレーションは次のことに責任を負う。

サービスを効率的に許容可能なコストで提供するサービスを規定のサービスレベル内で提供する IT サービスヘのユーザの満足度を維持する

(出典：『サービスオペレーション』3)

ライフサイクルのサービスオペレーション段階を通して、事業は IT 投資からの価値を直接維持し

ます。本章の目的は、サービスオペレーションの実務者が、サービスオペレーションの側面を認

識し、前述した責任のすべてのバランスをとるように支援することです。このバランスは、より幅

広い背景の観点を維持しながら日々の活動を効果的に管理することに焦点を当てなければなり

ません。 1.5.1 サービスオペレーション内の機能サービスオペレーションには 4 つの重要な基本的な構造があります：

サービスオペレーションを通じての事業価値の提供サービスオペレーションのパフォーマンスの最適化サービスオペレーション内のプロセスアクセス管理

1.5.1.1 サービスオペレーションを通じての事業価値の提供サービス・ライフサイクルでは、サービスの各段階で事業に価値を提供します。例えば、サービスの価値はサービスストラテジでモデル化される。サービスのコストはサービスデザインとサービストランジションで設計、予測、および妥当性確認が行われる。そして、最適化の対策が継続的サービス改善(CSI)で明確化される。サービスの運用とは、これらの計画、設計、および最適化が、実行され測定される場所である。顧客の視点からは、サービスオペレーションは実際の価値を確認することができる場所である。 (出典：『サービスオペレーション』3.1.2) 事業価値を達成するために、サービスオペレーションは、日々の運用やサービスの提供にだけ

焦点を当ててはなりません。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


事業価値を危険にさらす課題には以下があります：どんな組織でも、サービスを設計しテストをする際には、ライフサイクルで設定された同じ予

算と投資利益率(ROI)の目標内で実施しなければなりません。しかし、実際のサービスのプ

ロセスにおいて、組織が、3 年後の運用コストがどれぐらいであるかを計算することは不可

能です。わずかな優れた組織だけが、サービスの継続的な管理に必要なコストを効果的に

用意します。運用の段階で、元来の価値提案の一部ではなかったような、設計上の欠陥や不測の要件

を調整することは非常に難しい。多くの場合、これらの問題が表面化するのは、運用後しばらく経過してからである。ほとんどの組織は、設計と価値について運用中のサービスをレビューするための正式な仕組みを持っていない。解決は、あたかも純粋な運用上の課題であるかのように、インシデント管理と問題管理に委ねられる

(出典：『サービスオペレーション』3.1.1)

サービスオペレーションの効率性の改善を目的としたツールや活動(トレーニングを含む)のために追加の予算を得ることは難しい。これは、それらが特定のサービスの機能性に直接結び付かないためであり、また、それらのコストは最初からサービスのコストに組み込まれているべきだという顧客の期待があるためである。残念ながら、技術が変化する速度は非常に速い。一連のサービスを効率的に管理するソリューションが展開されてからすぐに、同じことをより速く、より安価に、そしてより効果的に行うことができる新しい技術が出現する


いくつかのサービスは当然のことと考えられ、これらを最適化するために実施される活動は、

壊れていないサービスを修理するとみなされる

1.5.1.2 サービスオペレーションのパフォーマンスの最適化サービスオペレーションは、長期的な漸進的改善と短期的な継続的改善の 2 つの方法で最適化

されます。

長期的な漸進的改善長期的な漸進的改善は、サービスオペレーション全体のプロセス、技術、機能とアウトプットの長

期にわたるパフォーマンスやアウトプットの評価を基に実施されます。この改善では、報告により、分析し、改善が必要かどうかについて決定を下します。また、どのよ

うに改善するかをサービスデザインやサービストランジションを通じて決定します。長期的な漸進的改善の例：

新規ツールの展開プロセス設計の変更インフラストラクチャの再構成

短期的な漸進的改善短期的な継続的改善は、サービスオペレーションそのものを強化する、プロセス、機能、技術に

関する業務慣例に対して実施されます。このような改善の規模は小さく、プロセスや技術の基本

的な性質をなんら変更することなく実施できます。

短期的な漸進的改善の例：チューニング作業負荷のバランス調整人材の再配置トレーニング


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


これらの改善のどちらも、本書の適用範囲内においてある程度詳細に説明しているが、『ITIL 継続的サービス改善』では、事業達成目標の全体的なサポートの一環として、改善を推進するフレームワークと代替案を提供している。変更管理プロセスに関する詳細は、『ITIL サービストランジション』を参照すること。 (出典：『サービスオペレーション』3.1.1) 1.5.1.3 サービスオペレーション内のプロセス効果的で全体的な IT サービス構造を提供するために、重要なサービスは相互に関連づけるべ

きです。効果的で全体的な IT サービス構造を提供するために、関係のある重要なサービスオペ

レーションのプロセスがあります。この章では全体的な構造を簡単に説明します。サービスオペレーション内のプロセスは、イベント管理、インシデント管理、問題管理、要求実現、

およびアクセス管理です。イベント管理はイベントを、そのライフサイクルを通して管理する。イベントのライサイクルは、

イベントを検出し、それが意味するものを判断し、適切なコントロール活動を決定するため

のイベントの調整の活動を含むインシデント管理は、事業へのインパクトを最小限にするために、ユーザが予期せぬサービ

スの低下や中断から可能な限り迅速に復旧することに注力する問題管理は、インシデントの原因を決定、解決するための根本原因を分析し、将来起こり

得る問題/インシデントの発生を検出し、その発生を防ぐためのプロアクティブな活動を含む。

また、問題管理には、その後発生するかもしれないインシデントの迅速な診断と解決を可

能にするための既知のエラー・レコードやワークアラウンドの作成も含まれる要求実現は、すべてのサービル要求のライフサイクルを管理するためのプロセスである。

サービス要求は、そのライフサイクルをとおして、個別の要求実現レコード/テーブルを使い、

最初の要求から実現まで、そのステータスを記録し追跡して管理されるサービス要求は、ユーザが ITサービス・プロバイダに何かを正式に要求するための仕組み

である。サービス要求はトランザクション的なもので、プロバイダが提供している標準的なサービスに関連付けられる

図 1.9 IT サービスに関連付けられたサービス要求の例 (出典：コアブック SO 3.1.3)

サービス：デスクトップ・サポート

要求の種類

• デスクトップの設置

• デスクトップの移動

• キーボードの追加

• デスクトップのアップグレード

• デスクトップの撤去

• デスクトップの交換

サービス：電子メール・サポート

要求の種類

• ユーザの追加

• ユーザの削除

• パスワードの変更

• メールボックス容量の増加

• ユーザ・グループの追加

サービス：開発サポート

要求の種類

• 開発者のワークステーションの設置

• 開発環境の回復

• 開発からテスト環境へのコード移行

• 開発サーバの設置


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


サービス要求は、必須条件、必要な許可、およびそれを実現するための標準的な作業ステップと活動を定義する要求モデルに関連付けられる。その要求モデルの一部として、実現処置を完了するために、標準的な変更やその他の種類の変更要求(RFC)が必要な場合がある。図 1.10に、サービス、サービス要求、要求モデル、RFC の関係を示す。 (出典：『サービスオペレーション』3.1.3)

図 1.10 : サービス、サービス要求、要求モデル、RFCの関係 (出典：『サービスオペレーション』3.1.3 図 3.2)

利用可能なITサービス

デスクトップ・サポート、ホスティング・サポートなど

サービスの要求要求実現プロセス

ユーザの追加、パスワードの変更、ユーザのワークステーションの設置や移動など

実現した要求要求モデル

変更要求(RFC)

要求のライフサイクルの管理

要求を実現するための文書化された作業ステップと、承認のワークフローおよび

必須の要件

要求を実施するのに必要になる場合がある

標準的な変更、および変更の他のカテゴリ


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.5.1.4 アクセス管理アクセス管理プロセスは、許可されたユーザに、サービスを使用する権限を与えます。また、許

可されていないユーザのサービスへのアクセスを制限します。

これは、許可されたユーザを正確に識別し、彼らの特定の組織上の役割や職能に必要なサービスヘアクセスできるように、管理できることに基づいている。アクセス管理は、組織によっては ID管理または権限管理とも呼ばれている。アクセス管理は、役割、権限、および職務の分離に関して情報セキュリティ管理プロセス(『ITIL サービスデザイン』を参照)で策定された方針を完全にサポートする必要がある。


1.5.2 サービスオペレーション内の機能概要効果的なサービスオペレーションを維持するためには、安定したインフラストラクチャやスキルを

持った人材が必要です。この実現には、サービスオペレーションは、運用タスクを実行するため

のいくつかの機能を必要とします。良く管理されたサービスオペレーションでは、サービスの機能

に、スキルを持った人材のグループが含まれます。このグループは、1 つまたはそれ以上のサー

ビス・ライフサイクルのプロセスと活動で重要な役割を果たします。サービスオペレーションには 4 つの主要な機能があります。それらは、サービスデスク、技術管

理、IT 運用管理、そしてアプリケーション管理です。

1.5.2.1 サービスデスクサービスデスクは、サービスの中断があった場合の、ユーザにとっての単一窓口です。サービス

デスクはユーザに対して、複数の IT グループやプロセスに対するコミュニケーションと調整の場

を提供します。

1.5.2.2 技術管理技術管理は、IT サービスの継続的運用や IT インフラストラクチャの管理を支援するために必要

な詳細な技術スキルやリソースを提供します。技術管理は、IT サービスの設計、テスト、リリース、

および改善において重要な役割を果たします。小規模な組織では、単一の部門内で専門知識を

管理できますが、大規模な組織では、いくつかの専門的部門に分割されます。

1.5.2.3 IT 運用管理 IT運用管理は、ITサービスの管理や ITインフラストラクチャのサポートに必要とされる日々の運

用活動を管理します。IT 運用管理は、サービスデザインで定義されたパフォーマンス標準に従っ

て実施されます。IT 運用管理は、単一の一元的な部門である場合もあればいくつかは、活動や

スタッフが一元化された部門で、そのほかは分散的または専門的な部門である場合もあります。 IT 運用管理は 2 つの特徴があります。組織的にサブ機能に分けられます。

IT 運用コントロール通常は、シフト勤務のオペレータが配置され、日常的な運用タスクが確実に実行されるようにする。IT 運用コントロールは、通常、運用統制室またはネットワーク運用センタを利用して、集中化されたモニタリングとコントロールの活動も提供する

施設管理物理的な IT 環境、通常はデータセンタまたはコンピュータ室の管理を指す。多くの組織では、技術管理およびアプリケーション管理は、大規模なデータセンタ内の IT 運用と同じ場所に配置される



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.5.2.4 アプリケーション管理アプリケーション管理はライフサイクルをとおしてアプリケーションを管理します。アプリケーション

管理は、運用中のアプリケーションをサポートし維持するだけでなく、ITサービスの一部を成すア

プリケーションの設計、テスト、および改善において重要な役割を果たします。 ITIL では、アプリケーション管理を、アプリケーション開発とは異なったものとしてとらえている。ITにおいて、アプリケーション開発は通常、IT組織内で構築中の ITソリューションを設計、構築、テスト、展開するための内部活動に焦点を当てる。アプリケーション管理は、内部の IT 組織以外の多数の提供元からアプリケーションを入手するために、今日の市場における能力を見抜くようなさらに広い視野を持つ。また、アプリケーションが展開された後に実施されるアプリケーションの継続的な管理と保守にも焦点を当てる。このさらに広い視野の例では、次のすべてが考慮される。

IT 組織内で開発中のアプリケーションサードパーティから購入またはソーシングするアプリケーションソフトウェア・アズ・ア・サービス(SaaS)ソリューションなど、クラウドベースになるようなアプリ

ケーション(『ITIL サービスストラテジ』、C2 を参照) アプリケーションの保守と、アプリケーションを継続的に管理するためのその他の活動アプリケーションのアップグレードアプリケーションの使用許諾と、法的要件へのコンプライアンス障害者要件に伴うコントロール、標準、またはコンプライアンスのための特殊なニーズなど、

他の業界要件へのアプリケーションのコンプライアンスアプリケーションが許容可能なコストとリスクで継続的に運用できるようにするための、保証

の検討事項アプリケーション管理は、組織のアプリケーション・ポートフォリオに基づいて複数の部門に分けられることがあるため、専門化とより焦点を絞ったサポートが行われやすくなっている。 (出典：『サービスオペレーション』3.1.3)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.6 サービストランジションにおけるサービス価値のテストと実証コアブック該当箇所 - 『サービストランジション』4.6.3 RCV：変更評価プロセスの事業価値変更評価プロセスは、その性質上、価値にかかわるものです。効果的な変更評価は、提供され

たメリットの観点からみて、リソースを使用します。変更評価プロセスの詳細は、将来のサービスの開発や変更管理において、より的確に価値に焦

点を当てることを手助けします。継続的サービス改善は、変更のプロセスや、サービス変更パフォーマンスの予測と測定に関す

る将来の改善に必要な非常に多くの情報を変更評価から得ることができます。 1.7 サービス測定項目のモニタリング、およびサービス・ライフサイクルの

全段階での活用コアブック該当箇所 - 『サービスオペレーション』 5.1.2.12 他のサービス・ライフサイクルとのインタフェース運用上のモニタリングと継続的サービス改善の概要：この項目は、運用上のモニタリングと報告、そして、モニタリングだけでなく、CSI(継続的サービス

改善)の出発点に焦点を当てます。品質は、CSI の主要な達成目標です。モニタリングは、サービス、プロセス、ツール、組織、また

は CI の有効性に焦点を当てます。実際の目的は、サービスをリアル・タイムに保証するのでは

なく、サービス、または IT パフォーマンスの既存レベルの改善の場所を識別することです。モニタリング活動は、例外の検出と解決策に焦点を当てなければなりません。例えば、CSI の活動は、インシデントが合意した時間内に解決されたかどうかや将来のインシデ

ントを防止できるかどうかに焦点を当てます。 SLA が長期にわたり一貫して満たされている場合、CSI の活動は、そのレベルのパフォーマンス

をより低いコストで維持できないか、または、より高いレベルのパフォーマンスにアップグレードす

る必要がないかを判断することに焦点を当てます。CSI の活動は、定期的なパフォーマンス・レ

ポートからのインプットを必要とするかもしれません。 IT サービスのインフラストラクチャ全体でみると、モニタリング・データは大規模で膨大な量となり

ます。CSI活動では、一般的にサービス改善に焦点をあて、モニタリング・データの特定の一部を

要件とします。これには 2 つの主な意味があります：

CSI のモニタリングは時間とともに変化します。例えば、四半期は、人事システムのモニタリ

ングに、次の四半期は業務管理システムのモニタリングが必要と考えるかもしれないそのため、サービスオペレーション、およびCSIは、モニタリングの領域、および基本的な目

的を検討し用意するのを支援する


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.8 コアサービス、実現サービス、および強化サービスコアブック該当箇所 - 『サービスストラテジ』3.2.2.4 内部サービス、外部サービスに関わらず、サービスが相互に作用し、顧客と関連するという観点

から全てのサービスのタイプを分類できます。サービスは以下のように分類できます：

コアサービス実現サービス強化サービス

表 1.2 に、これらのサービスの例を示す (出典：『サービスストラテジ』3.2.2.4) コアサービス実現サービス強化サービス IT サービス (オフィス・オートメーション)

文書作成処理更新のダウンロードとインストール

高品質なパンフレットを作成するために専門の印刷業者に文書を提供する。

IT サービス (給付金の追跡)

会社員は、給付金のステータスをモニタできる(健康保険や年金口座など)

給付金追跡サービスに対して、使いやすいフロントエンドのアクセスを提供するポータル

顧客は健康維持または減量プログラムを作成し管理できる。プログラムで進展を示す顧客は、保険料の割引を受けられる。

表 1.2 コアサービス、実現サービス、強化サービスの例 (出典：『サービスストラテジ』3.2.2.4 表 3.5)

コアサービスコアサービスは、組織での基本的なサービスを扱います。例えば、病院のコアサービスは、全て

の患者に速くて費用の安いサービスを提供することでしょう。もし病院がタイムリーに基本なサー

ビスを提供すれば、患者にとっての価値が創出されるでしょう。

実現サービス実現サービスには、次のようなものがある。

運転資本の必要性と担保の評価で融資担当者が提供する支援申し込み処理サービス貸付資金の柔軟な支払い借り手が資金を電子的に送金できる銀行口座

(出典：『サービスストラテジ』3.2.2.4)

実現サービスは、プロバイダが顧客にサービスを提供する機会を与えます。顧客がコアサービス

を満足して利用するために、実現サービスは重要です。たいてい、顧客は実現サービスを手に

入れるが、それについて費用を払う必要があるとは考えていません。実現サービスとして提案さ

れる一般的な例として、サービスデスク、支払いサービス、登録サービス、ディレクトリ・サービス

があります。ほとんどの市場において、実現サービスは運用の最小要件を可能にし、多くは差別化の基盤を提供する。しかし、差別化、つまり「魅力品質要素」をもたらすのは強化サービスである。 (出典：『サービスストラテジ』3.2.2.4)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


強化サービス強化サービスは、コアサービスまたは実現サービスに吸収されたり、その時々によってサービス

が異なる傾向にあるため、実現サービスの例を挙げるのは難しいです。言いかえると、現在、顧客にとって刺激的なことでも、常に提供されていると当然のことになる。例を挙げると、ホテルの部屋でのブロードバンド・インターネット・サービスの提供がある。数年前には、有料のブロードバンド・サービスの提供は、差別化要因と見なされていた(このホテルはこのサービスを提供しているが、ほかの競合ホテルは提供していない)。このサービスを提供するホテルが増えてくると、顧客はそれを必須と見なし始めたため、それは実現サービスになった。その後、ホテルは「無料の」ブロードバンド・インターネット・サービスを提供し始めた。しばらくの間は、これは強化サービスだったが、今では一般的になったので、急速に必要な(つまり実現)サービスになりつつある。一部の旅行者にとっては、このサービスは、例えばバスルームが付いているのと同じように、実際にコアサービスの一部となっている。 (出典：『サービスストラテジ』3.2.2.4)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.9 サービスマネジメントのための組織化コアブック該当箇所 - コアブック共通 2.4 組織化するための唯一最善な方法などありません。また、ITIL で説明されているベストプラクテ

ィスは、個々の組織や状況に応じて調整する必要があります。変更を行う場合、リソースの制約

と規模、事業および顧客の性質とニーズを考慮しなければなりません。戦略を用意することが、

組織の設計の出発点になります。

1.9.1 機能機能は、人材のチームまたは集まり、ツール、およびプロセスや活動を実行するリソースを含み

ます。大規模な組織では、機能を分割、あるいはより小さなかたまりに分けたり、また、部門、チームお

よびグループに分けたりします。小規模な組織でもこのように分けて機能が実施されることもあり

ます(例：サービスデスク)。比較的に小規模な組織では、１人の担当者、あるいはグループが複数の機能を果たすことがあ

ります。例えば、人事部門は同時に多くの機能を果たします。サービス・ライフサイクルを成功させるには、組織はライフサイクルの各段階に含まれるプロセス

および活動を実施するのに必要な役割と責任を明確に定義する必要があります。組織はまた、

チーム、グループ、あるいは機能の構造を決定し、管理しなければなりません。チーム、グループ、あるいは機能の構造は以下のとおりです：

グループ：何かを実行する時、なんらかの時点で共通項のある人の集まり。ITIL では、グ

ループとは、例えば異なる技術、部門、または異なる企業に属していても同様の活動を実

施している人たちを意味する。グループは、組織横断で共通のプロセスを定義する際に非

常に有益であるチーム：より正式な人のグループである。チームは、同じ組織構造の中になくても共通の達

成目標を実現するために協働する。チーム・メンバは、共同して働くことも、複数の場所で働

きながら仮想的に活動することも可能である。チームは、恊働のため、あるいは、一時的ま

たは移行を伴う状況の対処に有用である。チームの例には、プロジェクトチーム、アプリケ

ーション開発チーム、インシデントまたは問題解決チームがある部門：正式な組織構造である。部門は、特定の定義された一連の活動を継続的に実施する。

部門は、階層的な報告構造を持つ。また、活動の実施や部門のスタッフの日々の管理に責

任に負うマネージャがいる事業部：事業部は地理的、または生産ラインごとにグループ化された多数の部門の集まり

であり、通常、自己完結している

ITIL のサービスオペレーションでは、以下の機能を詳しく説明しています：サービスデスク：サービスデスクは、全ての種類のサービス、サービス要求、あるいは一部

のカテゴリの変更要求に関する、ユーザの単一窓口である。サービスデスクは、ユーザ、ITグループ、そしてプロセスのコミュニケーションと調整の場を提供する

技術管理：技術管理は、IT サービスの継続的な運用や IT インフラストラクチャの管理をサ

ポートするために必要とされる技術的スキルおよびリソースを提供する。この機能は、IT サ

ービスの設計、テスト、リリース、および改善にも重要な役割をはたす IT運用管理：IT運用管理は、ITサービスの管理やサービスデザインで定義されたパフォー

マンスの標準に従って稼働する IT インフラストラクチャのサポートに必要な日々の運用活

動を行う。IT 運用管理には 2 つの機能があり、一般的には組織的に分かれている。この 2つの機能は、IT 運用コントロールと施設管理である

アプリケーション管理：アプリケーション管理はライフサイクルを通してアプリケーションを管

理する。この機能は、運用中のアプリケーションをサポートおよび保守する他に、IT サービ

スの一部を成すアプリケーションの設計、テスト、および改善で重要な役割をはたす


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


他の ITIL コア書籍では機能を詳細に定義していないが、それらの書籍でも、本書で説明する技術管理機能やアプリケーション管理機能に依存している。技術管理およびアプリケーション管理はサービス・ライフサイクル全体を管理するための技術的なリソースと専門能力を提供する。ライフサイクルの特定の段階における実務者の役割は、これらの機能のメンバが果たす場合がある。 (出典：『サービスストラテジ』3.2.2.4、または共通 2.2.3) 1.9.2 役割サービス・ライフサイクルにおいては、多くの役割を実行する必要があります。組織は、それぞれ

の構造と達成目標にあった方法で ITIL コア書籍の指針を適用しなければなりません。定義：役割役割とは、個人やチームに与えられた責任、活動、および職権である。役割はプロセスまたは機能内で定義される。1 人の個人または 1 つのチームに、複数の役割が与えられることがある。例えば、構成マネージャと変更マネージャの役割を 1 人の要員が実行するなど。 (出典：『サービスストラテジ』3.2.2.4、または共通 2.2.3) 役割はよく職名と混同されますが、これらは同じではないことを認識する必要があります。組織

は、それぞれのニーズに合った適切な職名と職務記述書を定義します。個人は職名を持ちます。

そして、その職責には、1 つまたは複数の役割が含まれます。 1 人の要員が職務の一部として、複数のプロセスに参加することになる 1 つのタスクを実行する場合があることも認識するべきである。例えば、パフォーマンスの間題を解決するためにサーバにメモリを増設する変更要求(RFC)を提出する技術アナリストは、キャパシティ管理プロセスと問題管理プロセスの活動に参加すると同時に、変更管理プロセスの活動にも参加することになる。 (出典：『サービスストラテジ』3.2.2.4、または共通 2.2.3) 1.9.3 組織のカルチャと行動組織のカルチャは、サービス・プロバイダと、顧客、ユーザ、サプライヤ、内部スタッフなどを含む

全ての利害関係者とのやりとりをコントロールする価値や基準です。組織の価値は、カルチャに

影響を及ぼす望ましい行動様式です。組織の価値の例には、高い水準、顧客への配慮、伝統や

職務権限の尊重、慎重で保守的な活動、倹約などがあります。パフォーマンスの高いサービス・プロバイダは、効率性と有効性のためにバリュー・ネットワークを継続的に整合させる。バリュー・ネットワークを通したカルチャは、社会化、トレーニング・プログラム、説話、行事、および言語を通じてスタッフに伝達される。ガバナンス、能力、標準、リソース、価値、倫理などの制約は、組織のカルチャと行動において重要な役割を果たす。組織のカルチャは構造や管理のスタイルにも影響を受け、パフォーマンスヘのプラスまたはマイナスのインパクトを生じさせることもある。組織構造や管理スタイルは、人材、プロセス、技術、およびパートナの行動の根拠となる。これらは、サービスマネジメント・プラクティスと ITIL を採用するうえで重要な側面である。サービスマネジメント・プログラムに関連する変更は組織のカルチャに影響を及ぼすため、求められるパフォーマンスの成果を達成するために、要員に対して効果的なコミュニケーション計画、トレーニング、方針、手順を整備することが重要である。カルチャの変更を定着させることも、サービスマネジメントに関与するさまざまな人々の間の協働にとって重要な要素である。サービスの移行を通じた人材の管理については、『ITIL サービストランジション』の第 5 章でより詳細に説明する。 (出典：『サービスストラテジ』3.2.2.4、または共通 2.2.3)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.10 プロセス間のインタフェース、およびライフサイクル間の役割と責任の

定義と明確化のための RACI モデルの活用コアブック該当箇所 - 『サービスデザイン』 3.7.4.1-3.7.4.2 1.10.1 概要サービス、あるいはプロセスを設計する際、全ての役割を定義することは重要です。パフォーマ

ンスの高い組織は、素早く正しい決定を下し、効果的にそれらを実行します。これはパフォーマン

スの高い組織の特徴です。決定は戦略的で、誰がインプットし、誰が決定し、誰が行動するかが

明らかであることが、組織を優位な立場にします。組織は、プロセスでの全ての活動は、特定の組織単位に限定されるべきではないことを理解す

る必要があります。これは、プロセスの主要な特徴です。例えば、サービス資産および構成管理プロセスの活動は以下の部門で実施できます：

調達、倉庫、会計など IT 以外の部門コンピュータの運用システム・プログラミングアプリケーション管理ネットワーク管理システム開発

サービス、プロセス、およびそれらのコンポーネントに関する活動は組織全体で実行されるため、個々の活動を、適切に定義した役割に明確に対応付けるべきである。役割と活動は、プロセス・マネージャによって調整される。詳細な手順と作業指示書を作成したら、組織は、プロセスの定義済みの役割と活動を既存のスタッフに対応付けなければならない。説明責任および実行責任の明確な定義は、すべての改善活動の重要成功要因(CSF)である。これらの定義なしでは、新しいプロセス内の役割と責任がわかりにくくなる可能性があり、新しい手順が導入される前の「これまでにいつもやってきた方法」に従業員が戻ってしまう。 (出典：『サービスデザイン』3.7.4.1-3.7.4.2) プロセスと活動に関連した役割と責任を定義するために、RACI モデル(職務権限マトリクス)が組織内で良く利用されます。RACI モデルは、各プロセスで誰が何をするか簡単に追跡できるよ

うにし、迅速で確固とした意思決定を可能にします。 RACI は、次の 4 つの主要な役割を示す頭字語である。

実行責任者(R：Responsible)業務の遂行のために、正確な実行に責任を持つ 1 人または複数の人物

説明責任者(A：Accountable) 品質および最終結果のオーナシップを持つ人物。説明責任を負うのはタスクごとに 1 人のみ

協議先(C：Consulted)相談を受け、意見を求められる複数の人物。ナレッジおよび情報のインプットを通じて関与する

報告先(I：Informed) 進捗について最新の情報を常に受け取る複数の人物。プロセスの実行と品質に関する情報を受け取る

(出典：『サービスデザイン』3.7.4.1-3.7.4.2)

RACI モデルには幾つかのバージョンがあります。RACI の定義に従う組織もありますが、

Accountable(説明責任者)、Responsible(実行責任者)、Consulted(協議先)、Informed(報告先)の順の ARCI を使う組織もあります。どちらもその意味と使用方法は変わりません。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


RACI-VS と呼ばれる、さらに 2 つの役割を追加したRACIの拡張バージョンを利用する組織もあ

ります。その 2 つの役割は以下のとおりです：

検証者(V：Verifies)受け入れ基準が満たされているかどうかを確認する 1 人の人物またはグループ

最終承認者(S： Signs Off) 検証者(V)の決定を承認し、成果物の引き渡しを許可する 1 人の人物。これは説明責任者(A)である場合もある

(出典：『サービスデザイン』3.7.4.1-3.7.4.2)

RACI モデルの 3 つ目のバージョンは RASCI であり、S は支援者(Supportive)を表す。この役割は、例えば業務実施のための追加リソースを提供したり、導入における支援的役割を果たしたりする。この役割は、IT サービスの導入に有益であるだろう。 (出典：『サービスデザイン』3.7.4.1-3.7.4.2) プロセスに RACI モデルを適用すると、１人の人(通常はプロセス・オーナ)だけが、プロセスのエ

ンド・ツー・エンドの責任を持たなければなりません。同様に、個々の活動では、複数の人が活動

の一部の実行に責任を負いますが、１人の人だけが説明責任を負います。表 1.3 の RACI チャートでは、RACI モデル化の構造と有効性を示している。行は必要な活動を示し、列は意思決定を行う人物、活動を実施する人物、またはインプットを提供する人物を識別している。 (出典：『サービスデザイン』3.7.4.1-3.7.4.2)

サービスマネジ

メント担当役員サービスレベ

ル・マネージャ問題マネージャセキュリティ・マ

ネージャ調達マネージャ

活動 1 AR C I I C 活動 2 A R C C C 活動 3 I A R I C 活動 4 I A R I 活動 5 I R A C I

表 1.3 簡単な RACI マトリクスの例 (出典：『サービスデザイン』3.7.4.1-3.7.4.2 表 3.2) RACI、または、他のツールやモデルを使用する際は、責任の割り当てを成り行きに任せず、ぎり

ぎりまで決定を延ばさないようにするべきです。前もって役割が割り当てられていれば、対立を避

け迅速な決定ができるようになります。 RACI チャートを作成するステップは以下のとおりです：

1. プロセス/活動の特定 2. 役割の特定と定義 3. ミーティングの開催と RACI コードの割り当て 4. 漏れや重複の特定(R が複数存在する個所、または全く存在しない個所など。次の項の分

析を参照) 5. チャートの配付とフィードバックの取り込み 6. 割り当てが守られていることの確認

(出典：『サービスデザイン』 3.7.4.1-3.7.4.2)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


RACI チャートの分析弱みまたは改善の領域を識別するための RACI チャートの分析には、役割と活動の両方の側面の検討も含めるべきである。 (出典：『サービスデザイン』 3.7.4.1-3.7.4.2) 役割分析役割分析には、次について問うことが含まれる。

多数の A：職務が適切に分離されているか?これらの活動の一部について、他の誰かが説明責任を負うべきか?一部の領域で、意思決定を遅らせるボトルネックを引き起こしていないか?

多数の R：1 つの機能には多すぎるのではないか? 空白なし：この役割は、それほど多くのタスクに関与する必要があるか? また、参加の種類や度合いがこの役割の資格要件と一致するか?

(出典：『サービスデザイン』 3.7.4.1-3.7.4.2)

活動分析活動分析により、次のことが示される。

複数の A：1 つの役割のみが説明責任を負うことができる A なし：各活動に少なくとも 1 つは A を割り当てなければならない複数の R：多くの役割に実行責任を割り当てると、誰も実行責任を果たさなくなることが多い。

実行責任は共有可能だが、それは役割が明確である場合にのみ可能である R なし：少なくとも 1 つの役割は実行責任を持たなければならない多数の C：それほど多くの役割との協議が必要なのか?その利点は何か、また追加の時間

を正当化できるか? C および I なし：人や部門が互いに会話を交わして最新情報を交換できるように、コミュニケ

ーション・チャネルが利用可能になっているか?

(出典：『サービスデザイン』 3.7.4.1-3.7.4.2) 組織内の正式な機能と、それらの機能が実行すると期待されているプロセスの役割との違いを

理解する必要があります。正式な機能の担当者は、具体的なサービスマネジメントの役割を果たし、複数のプロセスに関連

する活動を実施します。例えば、「ネットワーク・アドミニストレータ」という肩書きを持つ個人は、インシデント管理とキャパシティ管理の活動を行う責任を負う。ネットワーク・アドミニストレータは、別の機能のライン・マネージャに対して報告する場合があるが、同時にサービスデスク機能およびキャパシティ管理のプロセス・オーナに対して活動を実行する責任も負う。 (出典：『サービスデザイン』 3.7.4.1-3.7.4.2) 職務権限マトリクスの作成は、面倒で手間がかかると感じられますが、とても重要な作業です。

職務権限マトリクスは、関与する全ての人に遂行してほしい活動を明確にし、サービス提供と責

任におけるギャップを特定します。特に、改善に必要なスタッフ配置モデルを明らかにする際に

役立ちます。職務権限マトリクスは、よく見落とされる、または特定が困難な 2つの重要な活動に役立ちます。

1 つは、RACI マトリックスの全ての R に潜在的な OLA があるということです。2 つめは、コミュニ

ケーションとワークフローの経路を明らかにすることで報告を受けなければならない役割を特定

することです。これは、CSI 活動のコミュニケーション手段を定義する時に非常に役に立ちます。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


RACI モデルで考えられる問題には、次が含まれます：複数の人物に 1 つのプロセスの説明責任を負わせるということは、実際には誰も説明責任を負

わないということである必要な職務権限がないのに実行責任または説明責任が委譲されるプロセスと活動を部門に合わせることに注力してしまう機能の分割/組み合わせを誤る。すなわち、課題または最終目標が矛盾しているインシデント管理、問題管理、サービス資産管理および構成管理、変更管理、リリース管理およ

び展開管理など、密接に関係するプロセスに対する実行責任が兼任されている。責任を兼任させると、場合によっては、適切なガバナンスを支える抑制と均衡が弱まったり、役割を兼務している人の一部が過負荷になったりするおそれがある

(出典：『サービスデザイン』 3.7.4.1-3.7.4.2)

1.10.2 プロセスと RACI 職務権限マトリクスを良く理解するためには、変更管理プロセスを使用するべきです。プロセス

の全ての主要な活動が、特定の手順、タスク、作業指示書の詳細なフローへと展開されます。例として、変更管理プロセスの 5 番目の活動、すなわち変更の許可、構築、およびテストを許可モデル(図 1.11)として詳しく説明する。この例では、さまざまなレベルの変更ごとに、さまざまなレベルの変更許可が必要であるため、さまざまな役割に許可委員を割り当てる必要がある。 (出典：『サービスデザイン』 3.7.4.1-3.7.4.2)

図 1.11：変更管理の例：変更許可モデル (出典：『サービスデザイン』3.7.4.2 図 3.12)

コミュニケーション、意思決定、処置

RFC、リスク、課題に関する

コミュニケーションとエスカレーション

変更許可委員

事業担当役員

IT担当役員またはIT運営グループ

CABまたはECAB

変更マネージャ

現場の許可

リスク／インパクトのレベル

役員の意思決定を必要とする

高コスト／高リスクの変更

複数のサービスまたは複数の事業部に

インパクトを与える変更

現場またはサービスのグループのみに

影響を及ぼす変更

低リスクの変更

標準的な変更

レベル1

レベル2

レベル3

レベル4

レベル5


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 1.11 に記載する変更許可モデルを利用して、変更許可を与えるべきレベルを決定するために必要となる詳細な手順のステップヘと、許可の活動を展開できる。次に、RACI モデルに基づく職務権限マトリクスの例を作成し、これまでに説明してきたさまざまな役割と、詳細な手順と、手順の実行、ひいてはプロセスの実行を成功させるために各役割に割り当てられた実行責任のレベルとの関連を示す。 (出典：『サービスデザイン』3.7.4.1-3.7.4.2) 表 1.4 に RACI マトリクスを示します。

プロセスの役割

顧客

変更の要求元

サービスデスク

変更マネージャ

変更の実行者

CA

B

ECA

B

リリースおよび

展開マネージャ

IT担当役員

事業担当役員

No. 手順における活動： 1 リスクのレベルを決定する： RC C C AR C

1.1 レベル 5-標準的な変更現場の許可

C AR RI

1.2 レベル 4-低リスクの変更変更マネージャの許可

C AR RI

1.3 レベル 3 -現場またはサービスのグ

ループのみに影響があるアセスメントのためにRFCをCABへ

C AR CI

1.4

レベル 2-複数のサービスまたは事

業部に影響があるアセスメントのためにRFCを IT担当

役員へ

C AR C CI

1.5 レベル 1 -高コスト/高リスクの変更アセスメントのために RFC を事業担

当役員へ

C AR CI

2 支持されたか? はい-2.1 へ進むいいえ-3.1 へ進む

ARI

I

2.1 CAB メンバがインパクトとリソースを

見積もり、優先度を確認し、変更を

スケジューリングする

A R C

3.0 許可されたか? 許可されなかった-3.1 へ進む許可された-3.2 へ進む

I I I A I R

3.1 RFC が却下されクローズされた (要求元に、却下された理由の簡単

な説明が通知される)

I I A R I I

3.2 変更がリリースと展開を通じた実施

のためにスケジューリングされる CI I AR RC C

凡例：R=実行責任者、A=説明責任者、C=協議先、I=報告先、RFC=変更要求、CAB=変更諮問

委員会、ECAB=緊急変更諮問委員会表 1.4 RACI マトリクス - 許可手順に基づく変更管理の職務権限マトリクスのサンプル (出典：『サービス

デザイン』3.7.4.1-3.7.4.2 表 3.3)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.11 リスク・アセスメントおよびリスク管理コアブック該当箇所 - 『サービスストラテジ』.6.5、『サービスデザイン、』4.1.5.4、『サービスオペレーション』 8.3、『継続的サービス改善』5.8.12、共通付録：リスク・アセスメントとリスク管理 1.11.1 リスクの識別と管理 ITILには、リスク管理のいくつかの参照文献があります。「サービスストラテジ」の付録Eには、リ

スク管理のフレームワークが紹介されています。サービスマネジメントの実施に関連するリスクを

管理しなければならないプロジェクトで、このフレームワークを利用できます。プロジェクト管理の

方法論にもそれぞれ、リスクを識別し管理するアプローチがあります。『ITIL サービスストラテジ』には、典型的な ITSM プロジェクトのためのリスク管理の包括的な説

明が記されています。 1.11.1.1 リスク管理の計画立案識別したリスクを管理するために、チームは、サービスマネジメントの導入戦略の適用範囲と複

雑さに応じて、個別の計画を立てる必要がある場合があります。この計画は、戦略実行の一部

である全体的なプロジェクト計画の一部となり、定期的なコントロール・ポイントでレビューされま

す。組織によっては、プロジェクトに関するリスクをモニタおよび管理するための個人を割り当て

ます。一般的に、プロジェクト・マネージャは、リスクを識別してそれを軽減することに責任を負います。

プロジェクトチームは、プロジェクト・マネージャと共に、潜在的なインパクトとリスク発生の確率を

含めてリスクを識別し、文書化します。リスクの識別リスクの識別、またはリスクの命名は、プロジェクトの一部です。プロジェクト、または戦略の成功

を脅かすかもしれないことを調べることは重要です。リスクやそれらの性質についての多くの考

えを議論したりブレーンストーミングをしたりする必要があるでしょう。また、リスクをそれぞれ識

別し、それが引き起こすと考えられる結果を文書化することも必要です。例えば、プロジェクトチ

ームが 30 日後にプロジェクトを終わらせられない場合、プロジェクト・マネージャは、計画の見直

し、またはプロジェクトの終了を遅らせなければなりません。リスクの分析リスクを識別した後は、リスクのインパクトと確率を定量化しなければなりません。インパクトとは、

リスクが現実のものとなり、顧客がリスクの結果を経験した場合に、戦略、またはプロジェクトに

与える影響のことです。ほとんどのリスク管理アプローチは、これらの領域に関する定性的説明と定量的説明の両方を使用する。つまり、結果とインパクトは言葉で定義されるが、それらに数値が関連付けられる。数値はリスクのランク付けの計算に使用され、説明はリスクに対処する方法を定義するのに使用される。確率が 100%のリスクはリスクではなく確実性であり、よって課題であることに留意すること。これらのリスクはリスク計画から削除し、課題として対処するべきである。同様に、確率が 0 のリスクは計画から削除するべきである。 (出典：『サービスストラテジ』5.6.5)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.11.1.2 リスクの管理リスクがアセスメントされ、処置計画とともに文書化された後は、リスク管理計画を定期的にレビ

ューし、適切な処置が取られ、期待どおりに機能していることを確認しなければなりません。プロジェクトチームは、プロジェクトをとおして、リスクのステータスが変わることについて留意しな

ければなりません。例えば、リスクを完全に回避できたか、または軽減処置が非常にうまくいってリスクが格下げまたは排除されたとする。しかし一方で、幾つかのリスクの確率が高くなり、それによってそれらのランクが上がるという状況が生まれるかもしれない。これらの変更はモニタされ、通常のプロジェクト・コントロールの仕組みに組み込まれなければならない。例えば、すべてのプロジェクト・ミーティングに、新しいリスクのリスク管理計画とアセスメントのレビューを含めるべきである。 (出典：『サービスストラテジ』5.6.5) リスク管理は、反復的な活動でリスク管理のプロセス全体が何度もレビューされ実行されます。 1.11.1.3 設計のリスクおよび課題の管理(全体的な活動) デザイン・コーディネーションは、設計の活動に関連するリスクを管理し、不十分な設計によって

起こりうる課題の数を削減するために、正式なリスク・アセスメントおよびリスク管理の技法を用

いなければなりません。プロジェクトチームは全ての設計で取り組む共通リスクと、個々のプロジ

ェクトと変更に関係するリスクの両方に注意しなければなりません。チームは、設計段階における課題を明確にし、文書化し、対処方法を決めなければなりません。全ての手順は、設計プロセスと、必要な時に適用できる組織のプロジェクト管理方法論に統合さ

れる必要があります。 1.11.1.4 サービスオペレーションのリスク・アセスメントとリスク管理サービスオペレーションに対するリスク・アセスメントを迅速に実行し、対処することが急務となる機会は多いだろう。最も明白な領域は、(すでに他の場所でも説明されているが)潜在的な変更または既知のエラーのリスクをアセスメントすることにあるが、それに加えて、サービスオペレーション・スタッフは次のリスクとインパクトのアセスメントに関与する必要があるだろう。

イベント管理またはインシデント/問題管理によって報告される障害または潜在的な障害、あるいはメーカ、サプライヤ、または委託先によって出される警告

最終的に稼働環境へ提供することになる新しいプロジェクト環境リスク(IT サービス継続性が対象とする物理的環境や場所にかかわるリスクをはじめ、

政治上、営利上、または労働関係にかかわるリスクを含む) サプライヤ。特に新しいサプライヤが関与する場合、または主要なサービス・コンポーネント

がサードパーティのコントロール下にある場合セキュリティ・リスク。セキュリティ関連のインシデントやイベントが原因で発生する、理論上

または実際のリスクサポート対象となる新しい顧客/サービス

(出典：『サービスオペレーション』8.3)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.11.2 リスク管理リスク管理は、変更管理、IT サービス継続性管理(ITSCM)、可用性管理、情報セキュリティ管理

(ISM)、および戦略的リスク管理のような多くのプロセスの一部です。リスクは、保証と有用性の

全ての要素において、アセスメントされ、軽減される必要があります。リスク管理は、主にサービス・ライフサイクルのサービスデザインとサービストランジションの段階

で実施されます。一方、優れた継続的サービス改善(CSI)の取り組みは、リスクの軽減、排除、お

よび管理をとおしてサービスの改善点を識別するために、リスク管理の活動の結果をアセスメン

トします。あらゆる組織はリスクを管理しますが、その方法は必ずしも可視的でも反復可能でもなく、意思

決定の支援に常に適用されているわけではありません。リスク管理は、組織が適切に定義され

た一連のステップを利用し、費用対効果の優れた方法を確実に利用できるようにします。この活

動の主な目的は、リスクとリスクが及ぼすインパクトを理解し、より優れた意思決定を支援するこ

とです。リスク管理には、リスク・アセスメントとリスク管理の 2 つの段階があります。 1.11.2.1 リスク・アセスメントリスク・アセスメントは、リスクにさらされているものについての情報を集め、組織が適切な決定を

行い、適正なリスクの管理ができるようするための活動です。また、リスク・アセスメントには、リスクのレベルの識別とアセスメントも含みます。リスクのレベル

は、資産の評価価値、脅威の評価レベル、および資産の脆弱性から算出されます。

1.11.2.2 リスク管理リスク管理で実施されるプロセスは以下のとおりです：

リスクのモニタリスクについて信頼性のある最新情報へのアクセスリスクに対処するためのコントロールの適切なバランスの管理リスク・アセスメントと評価のフレームワークによる意思決定プロセスの実行

リスク管理は、障害が発生した場合にサービスが受ける可能性のあるインパクトを考慮する際に

識別され正当化される、対策の特定、選択、および適用も含みます。これにより、リスクを許容可

能なレベルに軽減します。リスク管理は、事業継続性管理(BCM)、セキュリティ、プログラム/プロジェクトのリスク管理、運

用サービスの管理を含む、広範な領域に適用されます。(これらの関連領域は、リスク管理として

組織的なフレームワークの中で実施される必要があります。セキュリティなど、リスクに関連する

いくつかの領域は、極めて特殊(専門性が高い)です。そのため、この手引きでは必要な要素の

概要だけが提供されています。) 組織が達成目標を実現しようとする場合、ある程度のリスクを負うことは避けられない。効果的なリスク管理は、次のような貢献によってパフォーマンスを改善するのを支援する。

確実性の向上と予期せぬ事態の削減サービス提供の改善より効果的な変更管理リソースのより効率的な利用意思決定の改善によるすべてのレベルでの管理の改善無駄や不正の低減と投資に見合う価値の向上革新緊急時の活動および保守活動の管理

(出典：『継続的サービス改善』5.8.12)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.11.2.3 安全、セキュリティ、および事業継続に関連するリスクの管理リスク管理は、安全性の懸念、セキュリティ、および事業継続性を広く考慮して実行されるべきである。

安全衛生の方針とプラクティスは、職場が安全な環境であるようにすることに関係するセキュリティは、情報、建物などを含む組織の資産を保護することに関係する事業継続性は、サービスの損失、洪水や火災被害などの災害発生時に組織が運用を継続

できるようにすることに関係する



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 1.12 は、リスク管理プロセスが必要な理由を図で示しています。

図 1.12 リスク管理プロセスの理由 (出典：『継続的サービス改善』5.8.12 図 5.20)

1.11.2.4 リスク管理に対する事業の観点サプライヤとの連携では、事業のあらゆる側面に脅威を及ぼす、各サプライヤ協定や脆弱生の

アセスメントに重点を置きます。事業のあらゆる側面とは以下を含みます：顧客満足度ブランド・イメージ市場シェア株価収益性規制のインパクトまたは罰則(ある業界では)

サプライヤとの関係の性質は、事業へのリスクの度合いに影響します。

アウトソーシングされたサプライヤに関連するリスクは、内部サプライヤに関連するリスクに比べて数が多く、管理するにはより複雑である可能性が高い。リスクをアウトソーシングすることは、ほとんど不可能である。サプライヤを非難することは、セキュリティ・インシデントまたは長期のシステム障害に影響される顧客または内部ユーザに良い印象を与えない。関係から生じる新たなリスクは、必要に応じてコミュニケーションやエスカレーションによって、識別され管理される必要がある。

十分なリスク・アセスメントが契約前に行われるべきであるが、このリスク・アセスメントは、変化するビジネス・ニーズ、契約の適用範囲の変更、または運用環境の変更を考慮して維持する必要がある。 (出典：『継続的サービス改善』5.8.12)

利点を達成し、新しい技術を通じて革新をもたらすといった機会を活用するため

市場や顧客のニーズにおける変化に適応するため

サプライヤが原因の障害、セキュリティ違反、自然災害などの困難な状況において、事業継続性とサービス供給を維持するため

カルチャや政治的環境などにおける外部的な変化を管理するため

公の、または商業上の妨げや財務上の損失において、(認識上の、または障害のインパクトを回避するため

ISO/IEC 20000COBIT、 ISO/IEC27001、 ISO/IEC27002、品質要件などのベストプラクティスと標準への適合を実証するため

データ保護法、SOX法、HIPAA、EU指令、安全衛生、監査などの法律

上や規制上の要件を遵守するため

サプライヤと現行サービスを管理するため

真のコーポレート・ガバナンスを達成し、実証するため。また、その他の方針の取り組みについて検討するため

サービス提供

適切な調達と契約上の取り決めを通じて、新規の製品やサービスの取得(または開発)をコントロールするため


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.11.2.5 リスク・プロファイルおよび責任組織およびサプライヤは、関係によって自身の資産にもたらされる脅威に、より注意を払わなけ

ればなりません。組織およびサプライヤはそれぞれのリスク・プロファイルを保持するべきです。

また、各自のリスク・オーナを特定しなければなりません。リスク・アセスメントにサプライヤの専

門家を巻き込むことで、リスクの軽減やアセスメントの範囲改善の最良の方法を得る場合もあり

ます。リスク・アセスメントは、主に 1 つ以上の資産の機密性、完全性、または可用性にインパクトを与

える可能性のある脅威に重点を置きます。リスク・アセスメントの適用範囲には次のものが含まれる。

リスク(脅威と脆弱性)の識別対象、つまり脅威にさらされる資産リスクの定性的および定量的なインパクト発生確率考えられる軽減処置またはコントロールそのリスクに対して説明責任を負い、適切な処置を選択する(場合によってはリスクをコント

ロールせずに受容する)責任を負う利害関係者の識別選択した処置またはコントロールの実施に関する責任処置またはコントロールのインパクトとコストの評価に基づく、処置またはコントロールの選

択アウトソーシングされた運用について、リスクにさらされる資産のオーナシップを検討する際には特に注意が必要である。これは当事者ごとに異なる。リスク管理プロセスは、以前の処置の適合性をレビューし、変化する状況を考慮してリスクを再アセスメントする循環的なものと考える必要がある。リスクは、以下に示すようなリスク管理表によって管理されるだろう。 (出典：『継続的サービス改善』5.8.12) 表 1.5 は、リスク管理表を表しています。参照説明

重み付き優先度

提案された処置またはコントロールおよびコスト

オーナ

確率インパクト確率×インパ

クト=起こりう

る障害

R1 高大 9 R2 高中 6 R3 中小 3 R4 低小 1

表 1.5 リスク管理表 (出典：『継続的サービス改善』5.8.12 表 5.16)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.11.3 リスク・アセスメントとリスク管理本付録では、リスク・アセスメントとリスク管理に対する、広く知られ、使用されている幾つかのアプローチについての基本的な情報を記載する。これは、主題の総合的な調査を意図したものではなく、むしろ使用されている幾つかの方法について認識を与えるものである。 (出典：コアブック共通付録：リスク・アセスメントとリスク管理) 1.11.3.1 リスクの定義とリスク管理リスクは、プラスの機会であろうとマイナスの脅威であろうと、成果の不確実性と定義される場合がある。不確実性によって注意とリスクの正式な管理の必要性が生じるというのは事実である。結局のところ、マイナスの脅威が現実となることを組織が 100%確信しているなら、選択すべき一連の行動を判断するのはそれほど困難なことではないだろう。同様に、プラスの機会が現実となることが組織に保証されれば、その道筋は明らかだろう。リスクを管理するには、組織の事業達成目標の実現にインパクトを及ぼす可能性があるリスクにさらされていることを識別し、コントロールする必要がある。あらゆる組織はリスクを管理するが、その方法は必ずしも可視的でも反復可能でもなく、意思決定の支援に常に適用されているわけでもない。正式なリスク管理の目的は、リスクと、リスクが達成目標の実現に及ぼす可能性があるインパクトをしっかり理解することによって、より優れた意思決定を可能にすることである。組織は、適切に定義された一連のステップがあるリスク・フレームワークを、費用対効果の優れた方法で組織が確実に利用できるようにすることで、こうした理解を得ることができる。意思決定には、組織により受容可能と見なされるレベルまでリスクを管理するために取るべきあらゆる適切な処置を決定することが含まれるべきである。さまざまな方法論、標準、およびフレームワークの多くは、リスク管理のために開発されてきた。さまざまなレベルおよびニーズに幅広く適用できる一般的な技法に重点を置くものもあれば、組織が自身の達成目標の追求のために利用する重要な資産に関するリスク管理に特に関係があるものもある。組織はそれぞれのニーズおよび状況に最も適したリスク管理へのアプローチを決定しなければならず、採用されたそのアプローチが、認知されている複数の標準やフレームワークに反映されたアイデアを活用することもある。本付録では、リスクを管理する際の次のアプローチについて簡単に説明する。

リスクの管理(M_o_R) ISO 31000 ISO/IEC 27001 Risk IT

(出典：コアブック共通付録：リスク・アセスメントとリスク管理) 1.11.3.2 リスクの管理(M_o_R) リスクの管理(M_o_R)は、組織がリスク管理のための効果的なフレームヮークを整備するのを支援することを目的としている。これは、組織の戦略的、プログラム上、プロジェクト上、および運用上の達成目標に影響を及ぼすリスクについて、情報に基づいた意思決定を行う手助けになる。 M_o_R は、原則、1 つのアプローチ、相関する一連のステップを含む 1 つのプロセス、およびリスク管理の技法と専門性に関して参考となる詳細な情報源の指針をまとめて、リスク管理のルート・マップを提供する。また、これらの原則、アプローチ、およびプロセスが、リスクにさらされている達成目標の性質に応じて別々に、どのように組み込まれ、レビューされ、適用されるべきかについての助言を提供している。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


M_o_R フレームワークは、4 つの中核概念に基づいている。 M_o_Rの原則原則は、リスク管理のグッドプラクティスの開発および維持に必須である。コーポレート・ガバナンスの原則およびリスク管理の国際規格、ISO31000：2009 で報告されている。内部コントロールの一部として、組織がリスク管理への適切なアプローチを設計するにあたり組織に手引きを提供する、上位レベルの普遍的に適用できる記述である M_o_R のアプローチ原則は、各組織に合うよう適応させて採用させる必要がある。組織の原則へのアプローチは、リスク管理方針、プロセスの手引き、および戦略の中で合意および定義される必要がある M_o_R のプロセスプロセスは、識別、評価、計画、実施という 4 つの主要なステップに分けられる。各ステップには、プロセス全体が有効であることを確実にするために、関与するインプット、アウトプット、タスク、および技法が記述されている M_o_R の組み込みとレビュー原則を満たす 1 つのアプローチと 1 つのプロセスを整備した後、組織はそれらが組織全体で一貫して適用されていること、そして有効であり続けるためにその適用を継続的に改善することを確実にしなければならない要約リスク・プロファイルを含む、リスク管理を支援する共通の技法が幾つかある。要約リスク・プロファイルは、既存のリスク管理表によく見られる情報を視覚的に表現したものであり、リスクの可視化に役立つ。要約リスク・プロファイルおよび他の M_o_R 技法の詳細は、『Management of Risk： Guidance for Practitioners』(OGC、2010)を参照すること。 (出典：コアブック共通付録：リスク・アセスメントとリスク管理) 1.11.3.3 ISO 31000 ISO 31000 は 2009 年 11 月に発行され、「あらゆる公共、民間もしくは共同体の事業体、団体、グループ、または個人」に適用および適応できることを目的とした、リスク管理に関する国際的な指針の第一版である。ISO 31000 は、コントロール指向というよりもプロセス指向のリスク管理アプローチであり、組織のリスク・アセスメントおよびリスク管理に対するアプローチのすべての側面を規定するというよりも、むしろより広範囲でより概念的な手引きを提供している。例えば、ISO 31000では、組織がどのようにリスク・データを作成またはリスクを測定するかを定義しておらず、組織が達成目標の実現に関連するリスクの全領域におけるレビューを盛り込むことも徹底してはいない。ISO 31000 は、認証を取る対象ではない規格として発行された。 ISO 31000 は、「目的に対する不確かさの影響」としてリスクを定義している。リスク管理は、組織のあらゆるレベルにわたってリスクの管理を組み込む基盤および規定を提供するフレームワーク内で実施するべきである。ISO 31000 では、そのようなフレームワークに必要な、次のような要素を特定している。

指令およびコミットメントリスクの運用管理のための枠組みの設計組織および組織の状況の理解リスクマネジメント方針の確定アカウンタビリティ組織のプロセスヘの統合資源内部のコミュニケーションおよび報告の仕組みの確定外部のコミュニケーションおよび報告の仕組みの確定枠組みのモニタリングおよびレビュー枠組みの継続的改善

いったん枠組みを確立し、状況を把握したら、リスク・アセスメントを実施する。これには、リスク特定、リスク分析、リスク評価の 3 つのステップがある。リスク特定のステップは、組織の目的の


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


到達を実現、促進、妨害、阻害、加速、または遅延させる可能性のある事象に基づいてリスクの包括的な一覧を作成することを目的としている。リスク分析には、リスク評価に対する、およびリスク対応の計画に関する意思決定に対するインプットとして、リスクの理解を深めることが含まれる。リスク評価は、どのリスクが対応を必要としているかということと、その中での相対的な優先度について意思決定を下すことである。リスク対応には、1 つまたは複数のアプローチを用いたリスクの修正が含まれる。これらのアプローチは、必ずしも相互排他的ではなく、次のことが含まれる場合がある。

リスクを生じさせる活動を開始または継続しないと決定することによって、リスクを回避するある機会を追求するために、リスクを取るまたは増加させるリスク源を除去する起こりやすさを変える結果を変える 1 つ以上の他者とリスクを共有する(契約およびリスクファイナンシングを含む) 情報に基づいた意思決定によって、リスクを保有する

ISO 31000に記載されているアプローチは、各組織が上位レベルの原則を採用し、その原則を自身の特定のニーズおよび状況に適応させるために、広い適用範囲を提示している。 (出典：コアブック共通付録：リスク・アセスメントとリスク管理) 1.11.3.3.1 ISO/IEC 27001 ISO/IEC 27001 は、2005 年 10 月に発行され、情報セキュリティを明示的な管理コントロール下に置くことを目的としたマネジメントシステムを正式に規定する情報セキュリティマネジメントシステム(ISMS)規格である。ISO/IEC 27001 は、リスク管理標準ではなくセキュリティ標準であるものの、リスク管理に関する要件を含むセキュリティの特定要件を義務付けている。このような文脈で記述されているリスク管理手法は、一般的なリスク管理活動に適用されることもある。 ISO/IEC 27001 では、次のような管理が必要とされている。

組織の情報セキュリティのリスクを体系的に調査し、脅威、脆弱性、およびインパクトを考慮する

受容不可と見なされるリスクに対処するために、一連の首尾一貫した包括的な情報セキュリティ管理策やその他の形式のリスク対応(リスク回避やリスク移転など)を設計および実施する

情報セキュリティ管理策が継続的に組織の情報セキュリティ・ニーズを満たし続けることを確実にするために、包括的な管理プロセスを採用する

ISO/IEC 27001 に記載の主要なリスク管理関連ステップには、次のものがある。

組織のリスク・アセスメントのアプローチを定義する ISMS、特定された事業上の情報のセキュリティの要求事項、ならびに特定された法令およ

び規制上の要求事項に適したリスク・アセスメント方法論を特定するリスク受容基準を設定し、また、リスクの受容可能レベルを特定するリスクを特定する ISMS の適用範囲の中にある資産およびそれらの資産の管理責任者を特定するそれらの資産に対する脅成を特定するそれらの脅威がつけ込むかもしれない脆弱性を特定する機密性、完全性および可用性の喪失がそれらの資産に及ぼす影響を特定するリスクを分析し、評価するセキュリティ障害に起因すると予想される、組織における事業的影響のアセスメントを行う。

このアセスメントでは、その資産の機密性、完全性または可用性の喪失の結果を考慮する認識されている脅威および脆弱性ならびに資産に関連する影響の観点から、起こりうるセ

キュリティ障害などの現実的な発生可能性についてアセスメントを行う。その際に、現在実施されている管理策を考慮する

そのリスクのレベルを算定する


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


そのリスクが受容できるか、または対応が必要であるかを判断する。この判断には、前に確立したリスク受容基準を用いる

リスク対応策のための選択肢を特定し、評価する。選択肢には、次がある適切な管理策の適用組織の方針およびリスク受容基準を明確に満たすリスクの、意識的、かつ、客観的な受容リスクの回避関連する事業上のリスクの、他者(例えば、保険業者、供給者)への移転

リスク対応のための、管理目的および管理策を選択するその結果としての残留リスクについて経営陣の承認を得るその ISMS を導入し、運用することについて経営陣の承認を得る

ISMS の導入と運用において、リスク対応計画が策定され(情報セキュリティ・リスクを運営管理するための、経営陣の適切な活動処置、経営資源、責任体制および優先順位を特定し)、実施される。また、ISO/IEC 27001 は、組織の最終日的を確実に満たしているようにするために、リスクとリスク対応の継続的な監視およびレビューと、ISMS の正式な維持を求める。このアプローチは組織の情報セキュリティに関係する資産に特に焦点を当てているが、一般的な原則はサービス供給全体に適用できる。 (出典：コアブック共通付録：リスク・アセスメントとリスク管理) 1.11.3.3.2 Risk IT Risk IT は、ISACA の IT ガバナンス製品ポートフォリオの一部で、従うべき原則に基づいて、IT リスクの効果的なガバナンスおよび管理のためのフレームワークを提供している。Risk IT とは、ITの使用に関連する事業リスクを含む ITリスクのことである。Risk ITが文書化された出版物には、『Risk IT フレームワーク』 (ISACA、 2009)と『The Risk IT Practitioner Guide』 (ISACA、2009)(www.isaca.org を参照)がある。 Risk IT における主要原則は、IT リスクの効果的な企業ガバナンスおよび管理により次のことが行われることである。

常に事業目標と関連付けられる IT に関連した事業リスクの管理を、企業全体のリスク管理に整合させる IT リスクマネジメントにおけるコストと効果のバランスを保つ IT リスクヘの公正でオープンなコミュニケーションを促進する経営上層部が適切な風土を確立し、同時に、受容可能で十分に定義された許容レベルで

運用するために個人の責任を定義し守らせる継続的なプロセスと日常的な活動の一部とする

フレームワークは 3 つの領域を提供しており、各領域には 3 つのプロセスが含まれる。『Risk ITフレームワーク』には、各プロセスの主要な活動、プロセスに対する責任、およびプロセスと各プロセスのパフォーマンス管理の間の情報の流れが記載されている。リスク・ガバナンスは、企業に IT リスク管理のプラクティスが組み込まれていることを確実にし、最適なリスク調整後利益の確保を可能にする。リスク評価は、IT 関連のリスクと機会が事業の観点で識別、分析、および提示されていることを確実にする。リスク対応は、費用対効果の高い方法で事業の優先度に沿って IT 関連リスクの課題、機会、およびイベントが対処されていることを確実にする。 (出典：コアブック共通付録：リスク・アセスメントとリスク管理)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.12 サービス・ライフサイクル全体のナレッジの共有、ナレッジマネジメント

の活用コアブック該当箇所 - 共通 2.2.5、『サービストランジション』4.7.4 (4.7.4.3 は除く)、『サービストランジション』4.7.5.1、4.7.5.2、『継続的サービス改善』5.8.11) 1.12.1 概要：ナレッジ管理とサービス・ナレッジ管理システム(SKMS) 質の高いナレッジと情報は、人々がプロセス活動を実施し、サービス・ライフサイクルの段階間や

プロセス間の情報の流れを支援します。ナレッジ管理プロセスの責務は、情報の理解、定義、確立、および維持です。 SKMS の導入は、効果的な意思決定支援を可能にし、適切な仕組教を持たないことで起こりうるリスクを軽減する。しかし、SKMS の導入には、データ、情報、およびナレッジの保管と管理のためのツールヘの大規模な投資が伴う。組織はそれぞれに異なる部分でこの作業を開始し、どこを目指すのかという独自のビジョンを持つ。このため、「ナレッジ管理の支援にはどのようなツールとシステムが必要か?」という質問に対する明確な回答は存在しない。データ、情報、ナレッジは組織全体で相互に関連付けられている必要がある。SKMS 導入の基盤として、文書管理システムや構成管理システム(CMS)を使用することができる。 (出典：コアブック共通 2.2.5) 図 1.13 に、4 つの層を持つサービス・ナレッジ管理のアーキテクチャを、各層の内容例とともに示す。4 つの層は次のとおりである。

プレゼンテーション層検索、閲覧、取り出し、更新、要求、協働を可能にする。他の層の上にあるさまざまなビューは、異なる対象者に適している。すべてのビューは、許可された人だけがその基礎となるナレッジ、情報、データを参照または修正できるように保護するべきである

ナレッジ処理層ここで情報が有用なナレッジに変換され、意思決定が可能になる情報統合層データ層にある複数のソースのデータから収集され、統合された情報を提供

するデータ層データ検出とデータ収集のためのツール、構造化されていない形式と構造化され

た形式のデータ項目が含まれる

(出典：コアブック共通 2.2.5)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 1.13： SKMS のアーキテクチャの階層 (出典：コアブック共通 2.1.1 図 2.1) 実際には、SKMS は複数のツールとリポジトリで構成されることが多い。例えば、異なるプロセスやプロセスの組み合わせの支援に 4つの層すべてを提供するツールが存在することもある。さまざまな利害関係者は、幅広い観点をもたらすさまざまなツールを使用して、協調的な意思決定の支援のための、この共通のリポジトリにアクセスすることになる。このアーキテクチャは、ITIL における管理情報システムの多くに適用できる。SKMS の主な要素は、サービス・ポートフォリオである。他の例としては、CMS、可用性管理情報システム(AMIS)、キャパシティ管理情報システム(CMIS)などがある。 (出典：コアブック共通 2.2.5) 1.12.2 方針、原則、基本概念 1.12.2.1 ナレッジ管理の方針組織の全てのスタッフを導き、ナレッジ管理を効果的に実施するために、ナレッジ管理の方針が

必要となります。方針の記述は組織のカルチャに大きく依存しますが、以下が含まれます：

サービスをサポートするために必要なナレッジと情報は、必要なときに必要な場所ですべてのスタッフがアクセスできるように保管される

方針、計画、およびプロセスはすべて、少なくとも年に 1 回レビューされなければならないナレッジと情報はすべて、文書化された正式なプロセスに従って作成、レビュー、承認、維

持、コントロール、および廃棄されるべきである

(出典：『サービストランジション』 4.7.4)

プレゼンテーション層

ポータルスコアカードダッシュボード

レポート

ITガバナンスのビュー

品質管理のビュー

サービスのビュー

資産と構成のビュー

サービスデスクとサービス

サービスのビュー

セルフサービスの

ビュー

ナレッジ処理層

情報統合層

データ層

問い合わせと分析

報告パフォーマンス管理モデル化モニタリングと

アラート

サービス・ナレッジ管理ベース

統合CMDB

スキーマの対応付け、メタデータの管理、突合わせ、抽出、変換、マイニング

CMDBCMDBCMDBCMDB

DMLサービス・ポートフォリオ

その他の構造化された

データ

外部

データベース・リンク

構造化されていないデータ

検出、収集、監査

その他の統合されたデータと情報

検索、閲覧、取り出し、更新、発行、要求、協働


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


1.12.2.2 データ・情報・ナレッジ・知恵(DIKW)モデル一般的にナレッジ管理は、データ・情報・ナレッジ・知恵(DIKW：Data-to-Information-to- Knowledge-to-Wisdom)の構造で表されます。これらの用語の使用方法を以下に示します：データは、個々の事実の集まりです。殆どの組織は、サービス資産管理および構成管理

(SACM)のツール/システムやデータベースのような、高度に構造化されたデータベースに膨大な

量のデータを取得し保持しています。データを中心としたナレッジ管理の主要な活動は次のとおりである。

正確なデータの取得データの分析、統合、および情報への変換関連のあるデータの識別、およびその取得のためのリソースの集中データの完全性の維持データの可用性とリソースの利用の最適なバランス

データの一例は、インシデントが記録された日時である。情報は、データに背景を提供することから生まれる。情報は通常、文書、電子メール、マルチメディアなどの半構造化されたコンテンツに保存される。情報に関する重要なナレッジ管理活動は、情報の取得、問い合わせ、発見、再利用、および経験からの学習を容易にするような方法でそのコンテンツを管理し、その結果として、誤りが繰り返されないようにし、また作業が重複しないようにすることである。情報の一例は、優先度 2 のインシデントをクローズするまでの平均時間である。この情報は、多数のインシデントの開始時間、終了時間、および優先度からのデータを組み合わせることにより作成される。ナレッジは、個人の暗黙の経験、アイデア、洞察、価値、および判断から構成される。人々は自分自身および同僚の専門能力、ならびに情報(およびデータ)の分析からナレッジを得る。これらの要素の統合によって、新しいナレッジが創出される。ナレッジは動的で背景に基づくものである。ナレッジは情報を「利用しやすい」形式にし、それによって意思決定を促進できる。サービストランジションでは、このナレッジは単に進行中の移行だけを基にするのではなく、経験のあるスタッフが長年の間に無意識に集めてきた、以前の移行からの経験、最近の変更および予想される変更の認識、およびその他の領域から収集される。ナレッジの一例は、サービスの新バージョンをリリースして以来、優先度 2 のインシデントをクローズするまでの平均時間が約 10%増加したといった内容である。知恵は、ナレッジを活用して、十分な情報に基づいた正しい意思決定により価値を生み出す。知恵には、適用や背景についての認識を持ち、有効な常識的判断ができるようになることが含まれる。知恵の一例は、優先度 2 のインシデントをクローズするまでの平均時間の増加は、新バージョンのサービスについての質の悪い文書が原因であることを認識することである。これを図 1.14に示す。 (出典：『サービストランジション』4.7.4)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 1.14 データから知恵までの流れ(出典：『サービストランジション』4.5.4 図 4.7.4) 1.12.2.3 ナレッジ管理の戦略ナレッジ管理には総合的な戦略が必要です。ナレッジ管理に対する組織的なアプローチは、IT サービスマネジメント、またはその他のグルー

プ内の取り組みを、総合的な組織的アプローチ内に収まるように設計しなければなりません。組織的なナレッジ管理アプローチがない場合、サービストランジション、または IT サービスマネジ

メント内にナレッジ管理を確立するための適切なステップが必要になります。この場合、できる限り広い範囲で、直接的な IT スタッフ、ユーザ、サードパーティ・サポート、およ

び、ナレッジに貢献するかナレッジを有益に利用すると考えられる人々を対象として、ナレッジを

管理する必要があります。ナレッジ管理の戦略は以下が強調されます：

ガバナンス・モデル。該当する場合はソフトウェア資産管理、サーベンス・オクスリー法、ISO/IEC 20000、ISO/IEC 38500、COBIT の要件を含む

進行中および計画済みの組織の変更、およびその結果としての役割と責任の変更役割と責任、および継続的な資金調達の確立ナレッジ管理の方針、プロセス、手順、手法技術要件およびその他のリソース要件パフォーマンスの指標

(出典：『サービストランジション』 4.7.5.1)

ナレッジの識別、取得、維持具体的には、戦略では、関連するナレッジ、およびそれを裏付ける重大な情報とデータの取得について識別し計画する。これを行うステップは次のとおりである。

組織が有用なナレッジを識別できるよう支援するナレッジの分類法を作成し、ナレッジをカテゴリ化する関連する領域に関して人々の理解がより深まるような方法で情報を整理、抜粋、保存、お

よび公開するための、体系的なプロセスを設計するプロセスとワークフローを通じてナレッジを蓄積する新しいナレッジを生み出す外部情報源からの貴重なナレッジにアクセスする

背景

データ

知恵

なぜ?

どのように?

誰が、何をいつ、どこで?

情報

ナレッジ

理解


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


外部のナレッジを取得してそれを採用する。例えば、データベース、ウェブサイト、従業員、サプライヤ、パートナなどのさまざまな情報源からのデータ、情報、およびナレッジ

保存されたナレッジをレビューし、関連性と正確性がまだあることを確認するナレッジを更新、消去、アーカイブする


1.12.2.4 ナレッジの継承サービス・ライフサイクルの間に、組織は、問題解決、動的な学習、戦略的な計画立案、および意思決定を通じて、ナレッジを取り出し、共有し、および活用することに焦点を当てる必要がある。これを達成するには、ライフサイクルの特定のポイントで、ナレッジを他の人々や組織の他の部門に継承する必要がある。サービスマネジメントのプロセスの多くはこれに関連している。例えば、サービストランジションからサポートに入るポイントで、サービスデスクが最適なナレッジおよび理解を得ているようにすることなどである。サービスデスクは、リリース管理および展開管理からの情報に依存する。例えば、リリース・スケジュールに支障を来すほどではなく、本番にリリース/展開されるサービスに含まれる既知のエラーや、いずれかの技術サポート・チームからの診断スクリプトなどである。人事、設備、およびその他の支援サービスとの関連も確立され、維持され活用されるべきである。人々が関連するナレッジを検索し取り出すことができる、効果的かつ効率的な仕組みがなければならない。多くの場合に課題となるのは、組織のある要員や部門から別の要員や部門へのナレッジの引き渡しという現実的な問題である。それはただ単に電子メールを送ればいいという話ではない。ナレッジの継承はもっと複雑である。正確に言えば、ある要員や部門(グループ、部、課など)が別の要員や部門の経験、アイデア、または観点から学ぶことができる活動である。その形式は、それを使用する人々にとって適用可能なものであり、「使いやすさ」の面で良い評価を受けなければならない。ナレッジの継承は、個人または部門レベルの受け手のナレッジまたはパフォーマンスの変化を通じて観察できる。組織内のナレッジのギャップ(存在する場合)の分析を行うべきである。ギャップは、スタッフが責任を果たすために必要とされるナレッジヘの理解と、観察された実際のナレッジとを比較する直接的な調査によって調べ、立証する必要がある。これは客観的に行うことが困難なタスクであり、反感や不信を買うリスクを冒すよりも、これを行うスキルや経験を備えた何らかの支援を探すほうが有益であることが多い。ナレッジのギャップ分析からのアウトプットは、ナレッジの伝達における計画立案と成功の測定を可能にする、コミュニケーション改善計画の基礎を形成する。従来、ナレッジの継承は、講義形式の正式なトレーニングと文書化に基づいて行われてきた。多くの場合、最初のトレーニングが作業グループの代表者に提供され、その後、彼らが同僚たちにナレッジを伝達していく必要がある。ほかにも適した技法があり、サービストランジションが抱える有用なツール群となる。検討に値する技法には次のものがある。 (出典：『サービストランジション』 4.7.5.2)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


学習のスタイル学習する方法は人それぞれであるが、サービスマネジメント内およびユーザ・コミュニティ内でナレッジを継承および維持する最適な方法を確立する必要がある。

学習のスタイルは、年齢、カルチャ、姿勢、および性格に応じて異なる。IT スタッフの場合、あるナレッジ継承の仕組みが IT スタッフ自身にとって機能するからといって、現在のユーザ層にも適切とは言えないということを認識させることは有効である(このことは、グラフイック設計、実行者、販売チームなど、さまざまな業務形態のユーザをサポートしている状況では特に当てはまる)。

多くの人にとって、「実践」経験の幾つかの要素は学習にとってプラスの支援となり、シミュレーションや指導者付きの経験や実験は有効な検討事項となるだろう。

ナレッジの視覚化これは、コンピュータ、および図、画像、写真、絵コンテなどのコンピュータをベースとしない視覚的なものを使用して、ナレッジの継承を改善することを目的としている。人々の間のナレッジ継承に焦点を当て、さまざまな視覚化を補足的に用いて、洞察、経験、姿勢、価値、期待、観点、意見、予測を継承することが狙いである。教育用アニメーションなどの動的な形態の視覚化は、時間を経て変化していくシステムに関する理解を促進させる可能性を持っている。例えば、これは、機能は変わらないが 1 つのアイテム上のコンポーネントの位置が変わるようなハードウェアの更新の際に特に有効である。

行動の促進ナレッジの継承は、予見できるあらゆる状況で、スタッフがそれぞれのタスクを提供するための正しい処置を判断できるようにすることが狙いである。予測可能で一貫したタスクの場合、スタッフがタスクに使用するソフトウェア・ツールの中に、手順を組み込むことができる。すると、それらの手順によって、受け入れられた方法での行動が促進される。変更モデル(図 4.2 を参照)とサービスデスク・スクリプトはその好例である。これには、導入されているプラクティスが適切でなくなった(または適切でなくなる可能性がある)場合を認識できる必要がある。例えば、予想外の状況で、導入されているプラクティスでは要求されたとおりの提供ができず、そのままでは状況を悪化させてしまうため、決められた規則に背くタイミングなどである。

セミナー、ウェブ・セミナー、文書新規または変更されたサービスの正式な開始の際には、ナレッジの継承を向上させる「イベント」が開催されることがある。ウェブ・セミナーなどの技術ベースのイベントでは、注目度の高いナレッジ提供の仕組みをオンラインで維持し、それを後で他の場所や新しいスタッフに提供することが可能になる。インターネットおよびイントラネットのポータルでも同様のメッセージを継続的な方法で伝達でき、ディスカッション・フォーラムで質問をしたり、ナレッジを発展させたりすることができる。製品の文書は、ナレッジの継承を推進するように設計するべきであり、必要なときに必要な場所で利用できなければならない。

ジャーナルとニュースレター定期的なコミュニケーションのチャネルは、いったん確立されると、小規模な部門にナレッジを継承するのに便利である。「ビッグバン」ではなく段階的に継承するほうが、取り入れと維持が容易である。また、それらによって、漸進的なトレーニングや、状況や時間に合わせた調整が可能になる。重要なのは、これらの技法は楽しくすることができ、特定のグループを対象とすることもできることである。

ディスカッション・フォーラムとソーシャル・メディアナレッジの消費者が自身の経験と観点に基づいてナレッジを作成、更新、および共有することもできる非公式なチャネルを提供できるツールには、さまざまなものが多数ある。このようなチャネルは、そのコンテンツの正確性と関連性を確保するために注意深いモニタリングと管理が必要であるものの、ナレッジ創出のスピードおよびそのナレッジの関連性とアクセス性を大きく向上させる可能性がある。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


このようなコミュニケーション・チャネルを利用するときには、機密情報を明かさないことや、適切な範囲外で価値ある知的財産を共有しないことの重要性を理解するようスタッフにトレーニングを行うことが重要である。公共のインターネット上のリソースと、組織内の非公開のリソースとの間には明確な区別があるべきである。


1.12.2.5 ナレッジ管理 CSI を支援する主要な領域の 1つはナレッジ管理である。ナレッジを把握し、体系化し、その品質をアセスメントし、利用することは、CSI 活動の大きなインプットである。組織は、サービスレベルの達成度やサービスマネジメント・プロセスの結果とアウトプットにおける傾向を探るために、ナレッジを収集し、結果を分析しなければならない。このナレッジは、CSI 管理表に含める改善の機会の識別に使用された後、管理表のレビューと優先度付け、および SIP の策定に使用される。

今日の市場におけるナレッジ管理は、10 年前とは大きく異なっている。この短い時の流れの中でも、次のような変化が生じている。

参入に対する障壁が低下し、新しい機会が開かれたため、業界および市場の情勢が変化する速度が上昇した

新しい経験と観点を身に付けて共有するために転職するという考えが社会的に受け入れられ、有益なことも多くなったため、従業員の離職率が増加した

インターネットを介した情報へのアクセスが増加し、世界経済がさらに開かれた企業の従業員に部門間および関連会社間でナレッジを共有することを余儀なくさせる市場

競争が拡大した


1.12.2.6 ナレッジ管理の概念効果的なナレッジ管理は、前述のような変化から企業が得る利点を最適化することを可能にすると同時に、次のような項目を実現する。

適切な時期に適切な情報を得ることでより優れた意思決定を実現し、これを通じて組織の有効性を高める。また、アイデアや人材の交換や開発を通じて企業の学習を促進する

情報およびサービスの共有によって顧客とサプライヤの関係を強化し、共同で努力することによって能力を拡大する

得られた教訓、結果、およびベストプラクティスを組織全体で共有することでビジネス・プロセスを改善する

ナレッジ管理は、業界における競争上の優位性の獲得から、IT 導入のサイクル・タイムおよびコストの削減にいたるまで、企業全体の存続の鍵である。ナレッジを深めるアプローチは、既存のナレッジベースの構成と、カルチャにかかわるナレッジ管理の基準に大きく影響を受ける。

ナレッジ管理の成功に対して 2 つの主な要素がある。開かれたカルチャ - ベストプラクティスと得られた教訓のナレッジが組織全体で共有されて、

各個人がナレッジにふさわしい報酬を受ける。多くのカルチャでは、「ナレッジは力」という環境を育てている(他者の知らないことを多く知っていればいるほど、企業にとってより貴重な人材になる)。この種のナレッジの蓄積は、企業にとって報酬を与えるという点では危険な行為となる。そのナレッジはいつでも企業を離れる可能性があるからである。開かれたカルチャのもう 1 つの原則は、学習意欲である。これは、個人のナレッジベースの蓄積が、開かれたサポートと機会を通じて報いられ、促進されるような環境を指す

インフラストラクチャ - カルチャがナレッジ共有に対して開かれていても、それをサポートする手段またはインフラストラクチャがないと、最善の意図でさえも損なわれ、時間とともに意欲を喪失する原因となって行動を抑制する働きをする。このインフラストラクチャはさまざまな方法で定義できるもので、個人が自分のペースでオンライン・トレーニングを受けることができる技術的なアプリケーションやシステムを指す場合もあれば、ベストプラクティスや得られた教訓を議論するために人々を集めるように設計された、事後検討やナレッジを共有する活動などのプロセスを指す場合もある


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


ナレッジのギャップの特定と、その結果行われるナレッジの共有および開発は、IT ライフサイクルを通して CSI に組み込む必要がある。これはさらに、依存関係と優先度の課題も提起する。ITライフサイクル自体が、ナレッジの開発および共有の優先度を自然に導く。しかし、IT プロジェクトのライフサイクルの段階にかかわらず、ナレッジを適用する可能性のある時期に先立って、必要なナレッジベースを識別し開発することが重要である。これは当たり前のことに思えるかもしれないが、大多数の組織では、スキル不足のためにプロセスが行き詰まるまで、個人をトレーニングする必要性を認識しない。ナレッジの共有は、タスクヘのナレッジの適用前、適用中、そして適用後も促進するべき活動である。ナレッジ管理は、必要なすべてのナレッジをプロセス自体に組み込んでいる、完全に自動化された一連のプロセスの対極にあると見なすことができるかもしれない。サービスマネジメント・プロセスはこれらの両極の間のどこかに位置しており、運用プロセスは、戦術的プロセスや戦略的プロセスよりも、プロセスの自動化に近い場所に位置付けられる。これは ITSMプロセスを設計する際に考慮するべきである。ナレッジ管理は、よりナレッジ管理集約型のプロセスにおいて、即効性のある成果を出せる可能性が高い。これは、プロセスの参加者に要求されるナレッジのレベルに違いがあることを意味しているのではなく、むしろ、SLM およびベンダ管理のプロセスをさらに発展させるために、戦術的なナレッジを取り入れる必要があることを意味している。運用レベルのプロセスは、より幅広く深いナレッジを必要とする戦術的または戦略的なプロセスよりも自動化することが容易である。 CSI の取り組みを通して、多くの経験と情報が得られる。このナレッジを収集、体系化し、利用しやすくしておくことが重要である。プログラムを継続して成功させるには、ナレッジ管理の技法を適用しなければならない。このナレッジはすべてサービス・ナレッジ管理システム(SKMS)から提供される(図 1.15 を参照)。 (出典：『継続的サービス改善』5.8.11)

図 1.15：ナレッジの源 (「サービストランジション」は SKMS の原則と構造を説明している) (出典：『継続的

サービス改善』5.8.11 図 5.19)

SLAOLA UC インシデント CFIA FTA 問題の

レビューTO

リスク管理

AMIS

需要管理

作業負荷管理

アプリケーション・

サイジング

モデル化

CMISPSA 変更スケジュール CMS セキュリティ

方針コストモデル

予算

事業要件

サービス戦略計画

AM計画

キャパシティ計画

ITSCM計画

外部推進要因

構成計画

変更モデル

サービス・ナレッジ

管理システム

CSIへのインプット― 何が必要か?

人材：ナレッジ、スキル、経験 SIP：適用範囲、規模


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

ユニット 2 コミュニケーションおよび

利害関係者の管理


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


ユニットの概要このユニットでは、サービス・ライフサイクル全体における事業関係管理の優れたコミュニケーシ

ョンおよび適切な調整の必要性について学びます。総合的なコミュニケーション、および利害関

係者のコミュニケーションにおける事業関係管理の役割をこのユニットで説明していきます。また、

このユニットでは、良好なコミュニケーションの価値そしてサービス・ライフサイクル全体における

良好なコミュニケーションの維持に焦点を当てます。 2.1 事業関係管理 (BRM) 2.1.1 ライフサイクルを通じた BRM プロセスコアブック該当箇所 - 『サービスストラテジ』4.5.5.5 サービス・プロバイダが、内部プロセスを、顧客の事業と整合、調整、および必要に応じて統合す

る必要がある時に、事業関係管理（BRM）を中核的なプロセスとして利用できます。しかしながら、

各段階の活動は同時に実行されるわけではないことや、いつも同じ順序で実行される必要がな

いことに注意する必要があります。活動の正確な数と組み合わせは、事業関係管理プロセスを開始したシナリオによって異なりま

す。そのため、各活動を登録し、それぞれに対する応答を設計することが重要です。頻繁に発生するシナリオには、事業関係管理は、シナリオ毎に標準的な手順を定義し文書化す

るとよいでしょう。この手順には、どの事業関係管理の活動がどの順番で実行されるか、他のど

のプロセスが手順に関与するかなどの詳細が含まれます。プロセス実行の際に事業関係管理によって使用される主なツールは、次のとおりである。

開始されているすべてのケースの一元管理表。これは顧客関係管理ツールの形式を取ることが多い。外部サービス・プロバイダでは、企業資源管理ツールのスイートに含まれることが多い。内部サービス・プロバイダでは、通常はサービスマネジメント・ツールのスイートに含まれる

事業成果、機会などの追跡に使用される顧客ポートフォリオ。また、顧客ポートフォリオは、機会と戦略の進捗管理、コミュニケーションの計画立案、およびサービス・プロバイダのプロジェクトに重要な利害関係者の特定を行うための連絡先管理データベースとしても使用できる

サービス・ポートフォリオ。これは、BRM が新しい機会を記録するためと、新規サービスまたは既存のサービスに対する変更を評価および承認する一環として、事業関係管理で必要となる顧客関連の活動をすべて特定するために使用される。事業関係マネージャは、顧客から要求された投資の入力および追跡にもサービス・ポートフォリオを使用する。サービス・ポートフォリオは、既存のサービスが新しい機会に対応できるかを識別する際に BRM が利用できる情報を提供する。また、サービス・ポートフォリオは、サービスのステータスに関する最新情報を顧客に与え続ける際に BRM が利用するステータス情報を提供する

顧客合意ポートフォリオ。これは、サービスストラテジの一環として識別されている機会、または顧客から要求されている機会を定量化するときに使用される

アプリケーション・ポートフォリオは、利用可能な既存の機能のほか、各機会を探るためにBRM がコミュニケーションを取る必要のあるアプリケーション開発チームとアプリケーション管理チームを識別する

プロジェクト・ポートフォリオは、プロジェクト・スケジュール、現在の優先度、および新規サービスまたは既存のサービスに対する変更のステータスに関する情報を BRM に提供する

(出典：『サービスストラテジ』 4.5.5.5）


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| STUDENT | ライフサイクル全体の管理 | コミュニケーションおよび利害関係者の管理 |

サービスストラテジサービスストラテジにおいて、事業関係管理は主に戦略、方針、および計画を適用し、サービス・

プロバイダのプロセスを顧客の要件や機会と調整するために機能します。IT サービス戦略管理

によって、重要なターゲット市場や事業機会が特定されます。サービスストラテジでの BRM の役

割は、全ての戦略、方針、および計画が、顧客の観点で適切に定義され実行されることを確実に

することです。この段階で事業関係管理が連携する主な領域は、次のとおりである。

IT 戦略、方針、計画これらにより、すでに合意および承認されている戦略的な機会、成果、優先度、およびすべての処置計画が識別される。さらに、方針によって幾つかのパラメータが定義されるが、そのパラメータは事業関係管理によってその範囲内で承認された機会および新しい機会に有効となるべきである(例えば、どの機会によって組織がその戦略から遠ざけていると見なされるか、組織はどの標準を遵守する必要があるかなど)

サービス・ポートフォリオ管理実現可能な場合は、新しいターゲット市場、新規顧客、または新しい顧客要件に対応するために常に既存サービスを活用するべきである。多くの場合、これは既存のサービスまたはサービス・パッケージのラインという形式で存在する。事業関係管理では、各事業成果を達成するために最適なサービスおよびサービス・パッケージのラインの組み合わせを識別する。これらが存在しない場合は、新規サービスを定義する必要があるだろう。これを実現するために行われる事業関係管理の主な活動には、次のものが含まれるサービス・ポートフォリオ管理と連携して、プロジェクトの利害関係者全員を特定する達成するべき成果を定義する。これらは戦略に記述されているかもしれないが、より詳細

な定義が必要な場合がある顧客によって識別された新しい機会の場合、BRM が戦略要件を定義する必要がある(これ

らはサービスストラテジで識別されているサービスにすでに存在しているはずである。存在しない場合は、BRM が顧客と協力してそれらを識別する)

新規サービスまたは既存のサービスに対する変更のための資金が利用可能であることを確認する。資金が利用できない場合は、サービスが提供されないか(BRMは顧客に通知する必要がある)、合意された戦略がリスクにさらされているため、組織の役員に状況をエスカレーションする必要がある

新規または変更されたサービスのビジネス・ケースを定義する。BRM は、顧客と協力して

サービスの事業成果と予測される利益を把握する必要がある需要管理 BRM は、機会ごとに予測された事業活動パターン、およびこれらのパターンに

影響を与える要素を特定する IT サービス財務管理 BRM は、各機会で使用されるコスト・モデルの妥当性確認と(外部サ

ービス・プロバイダの場合、これはコスト・モデルではなく価格設定モデルに関連する)、財務予測で利用される情報の提供を支援する。IT サービス財務管理は、機会への投資の識別と評価を支援する

(出典：『サービスストラテジ』 4.5.5.5)

サービスデザインサービスデザインでは、サービスの詳細な設計と開発が継続して顧客の要件を満たし、識別さ

れている事業成果に対して有効であることを確実にするために事業関係管理が役立ちます。ま

た、事業関係管理は、識別されている事業成果の妥当性を確認します。サービスデザインでは、

BRM は、主にサービスの機能性(有用性)の要件に重点を置きますが、サービスの保証につい

ても顧客に確約できる必要があります。連携する主なプロセスには次のものが含まれる。

プロジェクト管理すべてのプロジェクトは事業関係管理とやり取りを行う必要がある。BRMは顧客要件を確認または明確化し、必要に応じてより詳細な要件を入手するために機能する。また、BRM は継続的なコミュニケーション計画立案および顧客との連携を支援する。顧客からのリソースが必要とされる場合は、必ず BRM が適切なリソースは誰かを確認し、顧客から合意を得てリソースのスケジューリングを調整する


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


ITサービス財務管理事業関係管理では、サービスデザインで識別されたコストが、サービスストラテジで予測された投資に確実に沿うようにする必要がある。IT サービス財務管理によってあらゆる逸脱が通知され、BRM が顧客と協力してこれらを受け入れるか、または設計要件を変更する

サービスレベル管理既存サービスの場合、事業関係管理はサービスレベル管理と連携して、既存サービスの現在のサービスレベルおよびこれらがどのように変化する可能性が高いかを特定する。事業関係管理では、顧客がサービスレベルを認識し、そのレベルが許容可能であることを確実にする。新規サービスの場合、BRM はすべてのサービスレベル要件がサービスレベル管理に伝達されることを徹底する。また、BRM は、新規または変更されたサービスのサービスレベル・アグリーメントに関する交渉を促進し、サービス・プロバイダと顧客間のあらゆる相違を解決する処置を開始する

需要管理サービスの事業活動パターンがまだ定義されていない場合、BRM は顧客と協力してこれを定義する。サービスストラテジで定義済みの場合、BRM はそのパターンを確認または洗練する。プロジェクト中に追加情報が手に入る場合やパターンが明確になる場合があっても、成果物を生み出すことに躍起になったプロジェクト・チームによって失われるか無視される場合がある。事業関係管理では、すべての変更が適切に対処され、作業の適用範囲に明確に受け入れられるか、または正式に却下されて顧客に通知されることを確実にする

サービス・カタログ管理 BRM は顧客と協力して、サービス・カタログおよびサービス要求カタログ内のサービスの説明を定義する

可用性管理単にデバイスやシステムの可用性に基づいて可用性を設計するアプローチでは、顧客要件を満たすことができない場合が多い。BRM は、サービスがいつ利用できる状態にある必要があるか、およびユーザがこれをどのように測定するかを厳密に定義する際に重要な役割を果たす

キャパシティ管理キャパシティ管理との作業の一部は、需要管理およびサービスレベル管理を通じて行われる。場合によっては、事業関係管理がキャパシティ管理と直接やり取りする必要がないときもある。しかし、キャパシティ管理では、顧客が実行するトランザクションの種類と、それらのトランザクションではシステムとデバイスのパフォーマンスがいかに重要であるかを確実に把握することが重要である。事業関係管理は、この情報を確認することができるようになり、サービス要件およびテスト計画に必ず組み込まれているようにする

ITサービス継続性管理事業へのインパクトと事業復旧目標の識別は、顧客からの関与がなれば実施することができない。BRMは顧客の関与を促進し、ITサービス継続性管理で IT復旧に限らずサービス継続性全体として重点を置き続けるようにする


サービストランジションサービストランジション段階では、BRM はこの段階のプロセスに顧客が関与するよう調整を行い

ます。サービストランジションでの BRM の役割は、すべての変更とリリースが、顧客が設定した

要件を確実に満たすようにすることです。

変更管理既存のサービスおよび技術に依存する機会の多くは、変更管理を通じて開始される。BRM は変更要求を提起し、変更管理プロセス全体にわたって適切に顧客が確実に参加するようにする。また、BRM は変更が正しく導入されたことを最終承認する。変更のインパクトとスケジューリングをアセスメントする際に顧客が参加するようBRMが確実にし、適切な変更管理活動(変更のインパクトのアセスメントなど)に顧客を関与させる

ナレッジ管理 BRM は、ナレッジおよび情報に関する顧客ニーズがナレッジ管理計画に含まれていること、および顧客とそのビジネス・プロセスに関するナレッジと情報が必要に応じて SKMS で利用可能であることを確実にする

サービスのテストおよび妥当性確認サービスが何をするべきかについて、最終的な決定権限は顧客にある。BRM は、顧客要件をテストするようにテスト計画が正しく設計されていることを確認し、顧客が計画に関与するよう調整する。UAT へのユーザの割り当てやテスト・データ利用の交渉を含め、テスト中の顧客の活動の調整も行う


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


リリース管理および展開管理 BRM は他の事業の優先度とリリースのスケジュールを調整し、すべての顧客とユーザが新規または変更されたサービスのトレーニングを十分に受けていることを確実にする。顧客とユーザから出された懸案や質問はすべてリリース・チームに伝達され、リリース文書で確実に取り上げられるようにする。また、BRM はサービスの既知のエラーに関する情報を受け取り、顧客にそのエラーのことが伝わっていて、顧客が確実にエラーに対処できるようにする。さらに、その既知のエラーを解決するためのすべての計画、コスト(必要に応じて)、およびスケジュールも伝達する。BRM は顧客と協力して、パイロットヘの参加とその適用範囲が適切であることの確認も行う

変更評価 BRM は変更評価活動の調整を支援でき、評価によって生じる処置の記録と調整も行う


サービスオペレーションサービス・プロバイダと顧客の両方で BRM プロセスを継続する、2 つの主な理由があります。

1. 顧客によるサービスの利用は時間とともに変化する。サービスが引き続き有効であるように、BRM はこの変化を検出し、サービス・プロバイダにフィードバックできる必要がある

2. 完璧なサービスというものはなく、サービスデスクはほとんどのインシデントと要求に対処できるが、他よりも高いレベルの関与とコミュニケーションが要求されるものもある

上記の理由により、サービスが展開されたら BRM の役割は必要ないと感じることは正しくありま

せん。また、BRM が提供するべき他の役割には以下があります：要求実現場合によっては、BRM が顧客と協力して、サービス要求カタログから標準サービ

スをどのように要求するかを顧客に教育する必要がある。このほかにも、BRM は実際にこれらのサービスを要求するための窓口となる。これは通常、顧客環境にいる特定の重要な人々に対して行われ、顧客関係を強化する方法として利用される

インシデント管理通常、事業関係管理は重大なインシデントの発生時に関与し、インシデントのステータスに関して顧客と集中的なコミュニケーションを取り、顧客へのインパクトに関してインシデント管理を最新の状態に維持する。極端な場合、BRM は災害復旧計画を発動するために、意思決定に関与する。また、事業関係管理は、サービスデスクまたは技術チームが適切なレベルの緊急度でインシデントを扱っていないと顧客が感じる場合にこれをエスカレーションするため、顧客によって利用される。このような場合の BRM の役割は、インシデントの相対的な優先度の評価に役立つ事業情報をインシデント管理に提供し、最初にどれに対処するかについて合意に達することにより、顧客とインシデント管理の両方を支援することである


継続的サービス改善継続的サービス改善では、BRM は、改善の機会を識別し、サービス・プロバイダと顧客の両方

が改善を達成できるように調整することに役立ちます。新しい機会が識別されると、サービススト

ラテジのプロセスが再開されます。継続的サービス改善での BRM の他の重要な活動は、顧客

満足度調査の実施です。この調査は、BRM が改善と新たな機会の領域を識別することに役立

ちます。サービス・ライフサイクルのこの段階で、事業関係管理がやり取りを行うプロセスおよび活動は次のとおりである。

サービス報告事業関係管理は、顧客に何が報告されるか、および受け取ったレポートで何をすることが顧客に期待されるかを識別する鍵である。また、事業関係管理では、サービス・プロバイダおよびサービスの品質に関する顧客の認識に影響を与える場合にレポートを利用する。サービス報告では、どの項目をモニタする必要があるかも識別する。また、イベント管理をどのように構成する必要があるかを定義するときにも使用できる。サービス報告からの情報は、事業との定期的な事業関係管理レビューの中心的要素である


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


サービスレベル管理事業関係管理はサービスレベル管理と連携し、顧客およびユーザとのサービス・レビューをスケジューリングして実施する。それらのミーティングで合意された処置は、適用の対象が顧客かサービス・プロバイダかにかかわらず、BRM によって調整およびモニタされる

7 ステップの改善プロセス事業関係管理は提案された改善を識別し、それらをサービス、またはサプライヤのサービスストラテジ、サービスデザイン、サービストランジション、サービスオペレーションの各プロセスに伝達するのに役立つ。また、事業関係管理では、改善のための要件とビジネス・ケースの定義に顧客が関与することを促進する


2.1.2 事業関係管理コアブック該当箇所 - 『サービスストラテジ』6.8.8 事業関係管理プロセスは、必要な責務を果たすために、幾つかの役割とその役割を持つ人たち

の支援を必要とします。これらの役割は職名ではありませんが、事業関係管理のプロセスの実

行を支援するために網羅された役割です。そのため、組織は、ニーズに適した職名と職務記述

書を定義する必要があります。組織が定義する役割には以下があります。 2.1.2.1 事業関係マネージャ組織の人事方針や、職名の特定や定義の方法にもよりますが、組織には事業関係マネージャ

(BRM)という職名の人がいるはずです。BRM の職務は、事業関係管理プロセス・オーナと事業

関係管理プロセス・マネージャの役割を組み合わせることもできます。通常、BRM は 1 つの組織

内でひとりの人に割り当てられます。しかしながら、「事業関係マネージャ」は、さまざまな顧客セグメントまたはグループに焦点を当て

る事業関係管理に携わる複数の個人を代表することもあります。また、組織によっては、この役

割はサービスレベル・マネージャの役割と兼務されることもあります。事業関係マネージャの役割と事業関係管理のプロセスが混同されることがあります。事業関係

マネージャは、しばしば、他のプロセスの活動を実行する場合があります。これは、単に事業関

係マネージャが顧客と接するポジションであるためです。こういった活動が事業関係管理プロセ

スの一部になるわけではありません。それでは、事業関係管理の他のさまざまな役割と責任を確認していきましょう。 2.1.2.2 事業関係管理プロセス・オーナ事業関係管理プロセス・オーナには通常、以下のような責任があります：

事業関係管理プロセスにおいてプロセス・オーナの全般的な役割を遂行する他のプロセス・オーナと協力し、事業関係管理の設計および導入に対して共通のアプロー

チを策定する 2.1.2.3 事業関係管理プロセス・マネージャ事業関係管理プロセス・マネージャには通常、以下のような責任があります：

事業関係管理プロセスにおいてプロセス・マネージャの全般的な役割を遂行する顧客のニーズを識別し、サービス・プロバイダがサービス・カタログによってそれらのニーズ

を満たすことを確実にするサービス・プロバイダが、顧客の期待を満たせることを確実にする。また、顧客の期待が、

彼らが対価として支払おうとすること以上のものにならないことを確実にするサービス・プロバイダと顧客の間に建設的な関係を確立し、維持できるよう、顧客とその事

業推進要因を理解する提供されるサービスの種類、レベル、または利用にインパクトを与える可能性のある技術

の傾向を識別する


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


新しいサービスや既存サービスへの変更のための事業要件を確立し、明確にするサービス・プロバイダが顧客のビジネス・ニーズを満たしていることを確認する異なる事業部門からのサービスの要件に対立が発生した場合、調整する

2.1.3 顧客/ユーザ事業関係管理が対応する必要のある他の利害関係者は、IT サービスの顧客とユーザです。顧

客とユーザは、事業の重要な要素であり、彼らは自身のニーズを伝え、事業成果が確実にサポ

ートされるように継続的な関係に参加します。 2.2 利害関係者の管理 2.2.1 利害関係者の管理とコミュニケーションサービスマネジメントにおける利害関係者利害関係者は組織、プロジェクト、サービスなどに利害関係を持ち、サービスマネジメントの活動、目標、リソース、または成果物に対して利害関係を持つこともある。利害関係者の例には、組織、サービス・プロバイダ、顧客、消費者、ユーザ、パートナ、従業員、株主、オーナ、サプライヤなどが含まれる。「組織」という用語は、企業、法人組織、またはその他の機関を定義する場合に使用される。この用語は、人材、リソース、予算を持つ任意の単位を指す場合もある(例えば、プロジェクトや事業など)。サービス・プロバイダ組織内には、サービスを提供する機能、グループ、チームなど、多様な利害関係者が存在する。サービス・プロバイダ組織の外部にも、次のような多くの利害関係者が存在する。

顧客商品やサービスを購入する人。IT サービス・プロバイダの顧客は、サービスレベル目標値を定義し、それに合意する人またはグループである。また、この用語は、非公式にはユーザの意味で使用されることがある。例えば、「これは顧客フォーカスの組織だ」など

ユーザサービスを日常的に利用する人。一部の顧客は ITサービスを直接的には利用しないため、ユーザは顧客とは異なる

サプライヤ IT サービスを提供するために必要となる、商品またはサービスの供給を責務とするサードパーティ。サプライヤの例には、汎用品のハードウェアやソフトウェアのベンダ、ネットワークと通信のプロバイダ、アウトソーシング組織などがある

IT サービス・プロバイダと同じ組織に属する顧客と、他の組織に勤める顧客には違いがある。これらは次のように区別される。

内部顧客 IT サービス・プロバイダと同じ事業組織に属する顧客。例えば、マーケティング部門は IT サービスを利用するため、IT 組織の内部顧客である。マーケティング責任者と最高情報責任者はともに最高経営責任者の配下である。IT がサービスに対して課金する場合、支払われる金銭は組織の会計システムにおける内部取引であり、実質収益ではない

外部顧客 IT サービス・プロバイダとは異なる事業組織に属する顧客。外部顧客は通常、法的拘束力のある契約や合意によってサービス・プロバイダからサービスを購入する

(出典：『サービスストラテジ』2.1.5)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


コアブック該当箇所 - 『サービストランジション』 5.1 利害関係者の管理は、サービストランジションにおいて重要な成功要因です。サービストランジ

ションは、あらゆる新規、またはサービスの変更を対象としていますが、これらの移行を成功させ

るためには、利害関係者の継続的で積極的な関与が必要になります。利害関係者が、等しく移

行に関与すれば、利害関係者の要求に対する支援と提供は実施されやすくなります。しかしな

がら、全ての利害関係者グループを正しく特定できないと、思いがけない事態が発生することに

なります。これは、サービストランジションでの活動が、影響を受ける利害関係者グループに伝わ

らないために、彼らの懸案や要望を知ることができないからです。そもそも活動に関与していな

ければ、利害関係者グループがその活動を支持することもできません。 2.2.2 利害関係者の管理の戦略利害関係者のグループを正確に特定するために、サービスデザインの段階から、利害関係者の

管理の戦略では、以下の問いに対する答えを検討する必要があります： a) 利害関係者は誰か b) 彼らの関心は何か、また影響はどのようになりそうか c) プロジェクトやプログラムはどのように利害関係者と関わるのか d) どのような情報を伝達するか e) フィードバックをどのように処理するか

2.2.2.1 利害関係者のカテゴリ利害関係者が、「ユーザ/受益者」や「プロバイダ」のようにカテゴリ分けされていると、利害関係

者を識別しやすくなります。必要であれば、各カテゴリをさらに細分化できます。しかし、これらの

カテゴリは、抽象的ではなく識別可能なグループでなければならないことに留意してください。例

えば、「ある地理的位置に拠点を置く従業員」は、簡単で容易に識別可能なグループですが、

「人権を支持する一般市民」は、そうではありません。同一人物が複数のカテゴリに当てはまることもありますが、下記の図 2.1 に示すように、様々な

肩書を持つ利害関係者を区別することは多くの場合に有益です。

図 2.1 考えられる利害関係者 (出典：『サービストランジション』5.3.2 図 5.5)

上級マネジメント政府

事業領域

運用スタッフ

労働組合

プログラムとプロジェクトの

チーム

サプライヤ（サービス）

事業パートナ

マスコミ

顧客

サプライヤ（製品）

監査人株主

利害関係者管理


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.2.3 利害関係者マップと分析利害関係者は必然的に変更全体の中で非常に影響力を持ちます。変更に肯定的な人もいるか

もしれませんし、否定的な人もいるかもしれません。ある利害関係者は変更が自分の作業環境

にどのような影響を及ぼすかに関心を持ち、別の利害関係者は、顧客の変更への準備に関心を

持つかもしれません。そして、利害関係者マップ(図 2.2 を参照)は、さまざま状況に対応するのに、また、サービストラン

ジションにおける関心領域、活動、および成果毎に、様々な利害関係者を位置づけるのに役立

ちます。サービストランジションは、サービスデザインと連携し、正確な利害関係者マップ、あるい

は同等のものがあるようにしなければなりません。

図 2.2 利害関係者マップの例 (出典：『サービストランジション』5.3.2 図 5.6) 影響を受ける可能性のある人々の例は次のとおりである。

サービス変更(技術の刷新など)の後援者変更またはサービストランジションによって影響を受ける人々商品やサービスのサプライヤ新規または変更されたサービスに関与するサービスマネジメント・チームサービストランジションや、新規または変更されたサービスの影響を受ける顧客や消費者関係管理スタッフ内部監査や外部監査情報セキュリティ不正対策部門リスク管理組織の株主、マネジメント、スタッフ労働者グループ/労働組合/労使協議会政治団体や規制機関一般市民などの、より広範なコミュニティサービス・ライフサイクル全体の中でプロジェクトを提供している、プロジェクト管理チームお

よびプログラム管理チーム

(出典：『サービストランジション』5.3.2)

利害関係者

事業パートナ

プロジェクト・チーム

顧客

マスコミ

労働組合

スタッフ

規制機関

戦略的方向性財務面運用上の変更顧客との

インターフェース公共の安全

競争的ポジション


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


利害関係者マップと分析は、利害関係者の要件と利害関係者が変更に対してもつ関心やインパ

クトに対する十分な理解を確実にすることに役立ちます。多くの場合、利害関係者の影響やイン

パクトは、合理的で正当化できますが、感情的で根拠のない場合もあります。しかしながら、利害

関係者管理の一部として事業関係管理に取り組む時、このような影響やインパクトを考慮しなけ

ればなりません。利害関係者は変更プロセス、そしてサービストランジションに影響を与えるため、

利害関係者マップの定義は最も重要となります。

利害関係者マップと分析は度々再利用することができます。例えば、あるシェアード・サービスおよびインフラストラクチャに関して多数のプロジェクトが実施されている場合、事業の後援者、サービスオペレーションのマネージャ、サービスマネジメントの最高責任者、および変更諮問委員会の常任メンバなどの利害関係者が同じであることがある。


利害関係者を分析する際には、利害関係者に関連する情報を共有できる手法を用いるように留

意するべきです。このことは、変更が発生した際にコミュニケーションを十分にとるために不可欠

です。適切なメッセージと詳細レベルが、該当する利害関係者グループに届けられるべきです。

変更に間接的に関与することになる利害関係者グループには、適切なコミュニケーションチャネ

ルが用いられるべきです。多くの場合、パートナ、業界グループ、規制機関など連携が必要とさ

れます。このような移行を実施する最良の方法は、機能レベルで部分的なコミュニケーション・ア

プローチをとるのではなく、より一貫性のある強力なメッセージを届けるための広範囲なコミュニ

ケーション・アプローチをとることです。

利害関係者を分析するための技法の 1 つは、サービストランジションに対する彼らの重要性と、変更から受けると考えられるインパクトの点から各利害関係者を検討し、マトリクス上に配置することである(図 2.3 を参照)。これは、サービストランジションが採用するべき活動の指針となる。例を次に挙げる。

サービス変更全体に対する事業の後援者の重要性は「高」となり、新規または変更されたサービスのインパクトは、投資利益の規模と機会に応じて「低」、「中」、「高」のいずれかになる

サービスデスクで働き、異なるサービスをサポートしている人にとっては、サービス変更全体に対する重要性は低く、そのサービスのインパクトは彼らにとって低いものとなる



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 2.3 インパクト強度マトリクス (出典：『サービストランジション』5.3.2 図 5.7)

前頁の利害関係者の配置は、1 つのケーススタディにすぎません。サービス・ライフサイクルを通

じて移行する中で利害関係者がマトリクス内を上下するので、特にサービストランジションの詳細

計画立案の際には、利害関係者分析を再度実施することが重要です。円滑なサービストランジ

ションの支援と提供には、責任ある利害関係者が、サービストランジションの進め方を改善したり、

時には変更したりすることができますし、またそうするべきです。 2.2.4 利害関係者の変更サービス・ライフサイクル中に利害関係者が移り変わることがありますが、変更後援者などの主

要な利害関係者は最初から最後まで同じであるべきです。しかし、そのような方法では、利害関

係者の変更を扱うには十分でありません。十分なレコードと文書を維持することで、個人や利害

関係者が効果的に引き継ぎできるようになります。十分なレコードと文書を維持する別の理由は、利害関係者の中には、諮問的または保証的な役

割ができる人や、利益の実現のアセスメントで重要となる人々や、監査的な観点を持つ人がいる

からです。

変更の確実さとサービス技術に対する利害関係者の重要性

利害関係者に対する新規のまたは変更された

サービスの潜在的インパクト

高中低

低

中

高


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.2.4.1 利害関係者のコミットメントの変更図 2.4 は、コミットメントの計画のサンプルである。この図は、個人およびグループの現在のコミットメント・レベルと、移行を成功させるためにそのコミットメントをどのように変えなければならないかを示している。

図 2.4 コミットメント計画立案チャートの例 (出典：『サービストランジション』5.3.2 図 5.8) それぞれに付けられた「0」は現在のポジションを示し、「X」はそれぞれに要求されるコミットメントのレベルを示している。ときには、このポジションを後退させる必要があることもある。例えば、この表内の「退職する顧客役員」は、リーダシップの役割を引き渡す必要があるだろう。 (出典：『サービストランジション』5.3.3)

主要な当事者

退職する顧客役員

サービス・プロバイダの取締役議長

サービス・プロバイダの新しい役員

顧客

あなたのマネージャ

あなたのスタッフ

サービスストラテジ・チーム

サプライヤ

サービスオペレーション・スタッフ

コミットメントなし抵抗なし実現を支援実現に尽力

X O

XO

X

X

X

X

X

OX

OX

O

O

O

O

O


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.3 サービス・モデルの利用コアブック該当箇所 - 『サービスストラテジ』3.4.7 サービス・モデルは、サービスストラテジのコミュニケーションを支援し、顧客/ユーザの価値の創

出に利用することができます。サービス・モデルの定義は、「サービス資産が顧客資産といかに

やりとりし、価値を創出するかを示すモデル」(出典『サービスストラテジ』3.4.7)です。サービス・

モデルは、サービスの構造(構成アイテムがどのように組み合わせられるか)とサービスの変動

性(活動、リソースの流れ、およびやりとり)を表します。サービス・モデルは複数のサービスのテ

ンプレートまたは、青写真として使用できます。また、サービス・モデルのテンプレートは以下の様式をとることができます。

異なるコンポーネント、およびそれらの依存関係を示す簡単な論理チャート異なる構成、および需要パターンにあるサービスの変動性を分析する複雑な分析モデル

特にサービス・ポートフォリオ管理で、サービス・モデルを利用する利点には以下があります：

新しいサービスを提供するには何が必要かを理解する重要なサービス・コンポーネント、顧客資産、またはサービス資産を特定し、必要な需要に

対処するように設計されていることを確認する価値がどのように創出されるかを示すサービスの提供に関与するチームと資産を対応付け、チームが、事業成果を達成する顧客

の能力に対するインパクトを理解するようにする新しいサービスを設計する開始点として既存のサービスヘの変更のインパクトを理解するためのアセスメント・ツールとして既存の資産を使用して新しいサービスを提供できるかどうかを特定する手段として提供できない場合は、サービスを提供するには、どのような種類の投資が要求されるかを

アセスメントするサービスの開発および提供に必要な技術、人材、プロセスの間のインタフェースを特定する

(出典：『サービスストラテジ』3.4.7)

重要なメッセージサービス・モデルは設計ではない。サービス・モデルは、サービスを提供できるために必要なアイテムの一覧または図である。サービス・モデルは、これらのアイテムがどのように関連付けられているか、サービスによってどのように使用されるかを示す。 (出典：『サービスストラテジ』3.4.7) サービス・モデルは、顧客資産の基本となり、与えられた顧客のポートフォリオの価値の創出に

役に立ちます。サービス・モデルは、価値創出について伝達および協働するための、サービスマ

ネジメント・プロセスと機能の青写真です。サービス・モデルは、必要とされることと提供できるこ

とのやり取りのレベルを示しています。このようなやりとりは、双方のコミットメントと期待を伴って

行われる諸条件を規定したサービスレベル・アグリーメントを通じて文書化されます。成果は、顧

客に対して創出される価値を定義します。また、価値自体は、顧客に提供される有用性と保証に

依存します。また、サービス・モデルは、サービスの構造と変動性を示し、これらは顧客の有用性と保証の要

件に影響を受けます。構造と変動性は、顧客に提供される有用性と保証の要因に影響を受けま

す。構造は、必要とされる特定のサービス資産およびこられが構成されるパターンの観点から定

義されます。構造には、ユーザとサービス・プロバイダ間の協力とコミュニケーションが含まれま

す。サービスの変動性には、事業活動パターン、需要パターン、例外、および変化が含まれま

す。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 2.5 に、サービス・モデルにおいてサービスの変動性をどのように表せるかの例を示す。ここでは小売リサービスを例として挙げている。この例では、サービスの各コンポーネントは、個別の分岐(または部分)に示しており、サービスが通常提供される順に、各活動に番号を付けている。サービスの各コンポーネントは、他のコンポーネント、特定された依存関係、および示されたコミュニケーションとデータの流れと関連付けて記載している。 (出典：『サービストランジション』3.4.7)

図 2.5 サービス・モデルの変動性 (出典：『サービスストラテジ』3.4.7 図 3.33) サービス・モデルを完成させるために、システム・エンジニアリングとワークフロー管理の手法を

活用することができます。これらの手法とツールは、サービス・モデルの完全性のために必要な、

プロセス・マップ、ワークフロー図、待ち行列モデル、および活動パターンの開発に役立ちます。

サービストランジションは、詳細なサービス・モデルがサービス・カタログを通じてサービスオペレ

ーションに入る前に、それらが目的と使用に適しているかを評価します。サービス資産や構成に

変更があるとサービスの有用性と保証に望ましくない変化が伴うことがあるので、サービス・モデ

ルは変更コントロール下にある必要があります。サービス・モデルは、サービストランジションとサービスオペレーションに非常に役に立ち、コンポ

ーネントがどのようにやり取りしてサービスを作りだすかを伝えることを支援します。これは、徹底

したテスト、構築、および利害関係者への変更の伝達を促進します。依存関係とインパクトが明

確に示されるため、サービスオペレーションでは、運用チームがインシデント管理と問題管理をよ

り良く実行するのに役立ちます。また、運用チームがパフォーマンスに影響する可能性があるす

べてのコンポーネントについてより深く理解することでサービスのパフォーマンスを管理すること

にも役立ちます。サービス・モデルは、継続的サービス改善(CSI)の有効性に対しても有益です。モデルの構造、

あるいは変動性を改善することができます。サービストランジションは、改善のための選択肢ま

たは経路を評価し、費用対効果が高く、低リスクの解決策を推奨します。顧客から受け取った外

部のフィードバックや、サービスマネジメント・プロセスから受け取った内部のフィードバックをもと

に、サービス・モデルは、継続的に発展します。CSI の活動は、全てのサービス・ライフサイクル

へフィードバックを確実に渡すようにします。

パート7配送

パート8配送と税金に関する情報を計算

(サードパーティのサービス)

パート9詳細を配送者に提示

パート10配送を許可


配送の選択肢を提示

配送と税金のコストを提示

最終確認を入手

確認した詳細を提供

購入されたアイテムを配送

販売専門家の割り当て

質問に回答

ショッピング・カートを提供

カートの内容を保持

検察可能およびナビゲーション可能なカタログを提示

検索と並び替え

パート5支援

パート2選択

パート1ショッピング

買い物客の選択を支援

買い物客の購入決定を支援

注文を完了

顧客満足の追跡調査を開始

パート3推奨

パート4

格付け

パート6

特典を提示

パート11

支払いを処理

9

10

11

12

13

6

7 5

4 1

2

3

8

14

15



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.3.1 サービスデザインでのサービス・モデルの利用コアブック該当箇所 - 『サービスストラテジ』8.3.1.2 サービスデザインにおいてサービスを開発するための基本的なアーキテクチャを提供するサービスデザイン・パッケージの定義と開発の開始点となるサービスを設計する対象のターゲット市場や、サービスを提供およびサポートする必要のある資

産のタイプを特定するサービスの設計に関わる幅広いチームに、サービス戦略の意図、サービスの変動性を、伝える

ことに役立つ

2.4 設計活動の調整(全体的活動)

コアブック該当箇所 - 『サービスデザイン』 4.1.5.3

プロジェクト毎に設計活動を調整するだけでは不十分です。全ての設計が最も効果的で効率的

な方法で進められるようにするには、正式なプロジェクトの一部として行われるか、プロジェクトで

はなく、変更管理により管理されるにかかわらず、すべての設計活動の監督が必要となります。

この活動は、プロジェクトや変更にわたる全ての設計活動の調整、スケジュール、リソースと対立、

必要に応じてサプライヤとサポート・チームの管理に関係しています。

デザイン・コーディネーションは、スケジュールを明確にして、設計のマイルストーンが伝達され

達成されるようにするために、他のサービスデザインのプロセスだけでなく、必要に応じて変更管

理プロセスとも密接に統合されなければなりません。また、全ての設計が、マネジメントシステム、

アーキテクチャ、測定と測定基準の仕組み、およびプロセスを含む、機能上(有用性)の要件と運

用上(保証)の要件の両方を対象範囲としなければなりません。

最も有能な IT サービス・プロバイダは、設計の 5 つの側面を個別に設計するのではなく、全てを

統合して設計します。これにより、サービスの管理上および運用上の要件のすべてと、事業が求

める機能性を満たす、標準、設計、およびアーキテクチャの一式から成る統合されたエンタープ

ライズ・アーキテクチャが作られます。この統合された設計は、新規または変更されたサービス

が導入される際に事業が必要とする機能上の要件を提供するだけでなく、全ての領域でそのサ

ービスレベルと目標を実現し、また実現し続けるようにします。これによって、後から対処しなけ

ればならないような弱点が 1 つもない(または、絶対的に最小)状態となります。そのため、デザイ

ン・コーディネーションは、設計の原則と基準、およびさまざまなレベルの有用性と保証について

のサービス受け入れ基準について助言と手引きを提供するべきです。

統合された設計を実現するために、設計活動の調整全体で以下を確実に実施しなければなりま

せん：さまざまな設計活動と全ての関係者(事業と IT の計画立案者、設計者、アーキテクト、戦略

家を含む)との間の良好なコミュニケーション該当する事業と IT の計画と戦略の最新バージョンを全ての設計者が入手できることアーキテクチャの文書、サービス・モデル、サービス・ソリューション設計、および SDP の全

てが、戦略要件、アーキテクチャ要件、ガバナンス要件、および企業の他の要件、ならびに

IT の方針と計画に適合することサービスデザインから適切に引き継がれるようにするための、サービストランジション・プロ

セスとの良好なコミュニケーションと調整アーキテクチャと設計は以下のとおりであること：

柔軟に、そして新しいビジネス・ニーズに IT が迅速に対応できるようにする全ての戦略と方針と整合しているサービス・ライフサイクルの他の段階のニーズをサポートしている事業のニーズと日程感に適切に整合した新規または変更されたサービスやソリューション

を促進する


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.4.1 サービスの定義コアブック該当箇所 - 『サービスデザイン』 4.2.4.2 サービスとは何か?という質問は見た目ほど簡単には答えられません。また多くの組織が、IT と

の関連において明確な定義を導き出すことに失敗しています。IT スタッフは、しばしば、顧客が

認識している「サービス」と IT システムを混同します。多くの場合、ある「サービス」が他の「複数

のサービス」(など)から構成されることがあり、それらのサービス自体も、環境、データ、アプリケ

ーションとともに、ハードウェア、ソフトウェア、ネットワークを含む全体的なインフラストラクチャ内

部の 1 つ以上の IT システムから構成されています。2 つ以上のサービスが組み合わされる場合

は、サービス・パッケージと呼ばれます。各組織は、サービスとは何か、またサービスがどのように定義され合意されるかについての方針

を策定する必要があります。顧客にどの IT サービスを使っているのか、また、それらのサービス

が顧客の事業にどのように位置づけられサポートしているかを尋ねることは、多くの場合、良い

開始点になります。顧客は、大抵の場合、サービスはこうであるべき、という明確な信念をもって

いるからです。方針の詳細は、以下のような多くの要素に影響されます：

サービス・カタログの以下のような予測される用途：顧客に対するサービスのマーケティングサービスについて顧客との継続的なコミュニケーションサービス・プロバイダのスタッフが利用するサービスとそれらの依存関係やインタフェース

に関する参照情報提供されたサービスとその条件に関するユーザのための参照情報カタログ内のサービスに関する要求をどこへどのように出すのかについての情報源

サービス・カタログの対象者現在の組織のカルチャ、プラクティス、成熟度レベル

サービスの定義と命名に関する組織の方針は、時と共に大きく進化することがあります。成功の

カギとなる目安は、その方針がより効果的で効率的なサービスの供給をどの程度支援するかで

す。 2.5 コミュニケーションとコミットメントの管理コアブック該当箇所 - 『サービストランジション』 5.1 変更が起こる時はいつでも、全ての利害関係者に伝達されることが必要です。それゆえ、コミュ

ニケーションは、サービストランジションの変更のプロセスの要となります。実際に、変更が大き

いほど、明確なコミュニケーションの必要性が大きくなります。対象者に変更の理由や論理的根

拠、期待される利点、実施のための計画、および想定される効果についてタイムリーなコミュニ

ケーションをとることが必要です。移行の詳細の一部を共有できない場合、この事実を認め、な

ぜそれが不可能であるか、例えばセキュリティ上の理由などを説明する必要があります。このよ

うに、コミュニケーション計画を立案する前に、人々のコミットメントを理解する必要があります。それでは、サービストランジションにおけるコミュニケーションを詳細に確認していきましょう。 2.5.1 サービストランジションにおけるコミュニケーションサービスの変更は、様々な利害関係者グループに複数の(大きな、あるいは小さな)影響を及ぼ

すため、利害関係者のコミットメントは、どんな変更を行う前にも重要です。うまく移行をすすめる

には、以下を特定することが重要です：すでに移行を支持している人々(これらの人々を変える必要はないので、彼らに対して今す

ぐ何かをする必要はない)。彼らには「受け入れ」の段階で対処する


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


強く反対している人々、および説得しても良い反応が得られそうにない人々。こうした人々に時間を費やすのは、労力が報われる見込みが当面ないので、建設的ではない

アプローチの手法を理解するために、「感情のサイクル」の中で個人がどの段階にあるのかを明確にすることが重要である (出典：『サービストランジション』5.1.1) サービストランジション・チームにとって、自身を対象者に合わせる時が最も重要な時期です。し

かし、さまざまな利害関係者に多くの日数を割けないことも学ぶべきです。2 つの両極端にいる

人々に集中することが最良の方法です。サービストランジションでは、サービストランジション・チ

ームの一部として、姿勢を変える必要性や、カルチャの変革の実施により一層の努力を注ぎま

す。サービストランジション・チームの最終目標は、変更に対する熱意とコミットメントを築くことです。

その一方、変更がどのようなインパクトを利害関係者にもたらすのか、およびその後数カ月間に

期待されていることについて、全ての利害関係者が明確に理解しているようにすることです。明

瞭な双方向のコミュニケーションの活用により、従業員が自分たちのフィードバックやアイデアに

価値があると感じるようになります。組織の重要な変更の際には、利害関係者の管理は、スタッフの工数の 50%までが費やされるこ

とは一般的なことです。

2.5.2 コミュニケーションの計画立案前向きな変更実現者を奨励していく戦略を確立し、組織内でのコミットメントのレベルを把握した

ら、サービストランジションは、情報が最も効果的になるような伝達先を定めた詳細なコミュニケ

ーション計画を作成しなければなりません。サービストランジションにおける変更の期間中に情報を伝える際には、伝達する必要のあるそれぞれの事柄について、次の点を考慮する必要がある。

コミュニケーションの達成目標は何で、求められる成果は何か? コミュニケーション計画はどの程度正式で、しっかりしている必要があるか?一部の移行で

は完全に統合され文書化されたコミュニケーション計画が必要だろうが、小規模な移行ではより単純なアプローチのほうが適切だろう

情報をどのように提供するべきか?すべて一度に、または、幾つかの部分に分割して一定期間中に発表するか?幾つかに分割して発表する場合は、各部分にどの要素を含めるか、またメッセージを伝える一連のタイミングはどうするか?

各メッセージの語調をどのようにするべきか(4.7.5.2 を参照)?どのような語調や形式でメッセージを伝えるべきか?強気な調子か、警告的か、楽観的か?

コミュニケーションの前に、伝える情報の理解や受け入れを促進するためにどのような処置を取ることができるか?

コミュニケーション情報を組織内の他のレベルに伝達する際に、いつどのように各グループを巻き込むか?

該当するサービストランジションに関する特定のコミュニケーションの障壁(例えば、カルチャの違い、大規模チームのつぎはぎ構造、地理的に分散している要員に関する追加要件)を、コミュニケーションでうまく打破することができるか?

プロジェクト内の他の利害関係者(例えば、意思決定者、オピニオン・リーダ、システム・ユーザ、内部および外部の規制機関、および新たなサービストランジションの実施のインパクトを受けるあらゆる人々)のコミュニケーション・ニーズに対処することを考慮しているか?

コミュニケーションの成功をどのように測定するか?

(出典：『サービストランジション』5.1.2) 図 2.6 に、効果的なコミュニケーションを計画する際に考慮する主な要素の概要を示す。 (出典：『サービストランジション』5.1.2)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 2.6 コミュニケーションの戦略と計画内容の例 (出典：『サービストランジション』5.1.2 図 5.1) コミュニケーション戦略を効果的にするには、調査のようなモニタリングの手法を実行する必要

があります。このような調査は、コミュニケーションの受けてからのフィードバックを提供できます。

調査には、目標が正しいことを証明するために、「変更のサイクル」に対する人々の反応を確認

する質問を含めるべきです。フィードバックの結果から、受け入れ可能なレベルの賛同を得るた

めに、サービストランジション・チームによるさらに個人的な接触を必要とする人々が分かるかも

しれません。一連のイベントの理解を得るには、図 2.7 に示すようなコミュニケーション経路図が、コミュニケー

ション・プロセスの計画立案に役立ちます。この図は、サンプル・プロジェクトで発生する可能性

のある一般的なコミュニケーション活動を簡単に示しています。

図 2.7 コミュニケーション経路の例 (出典：『サービストランジション』5.1.2 図 5.2)

コミュニケーション計画

コミュニケーション戦略

抵抗の障壁の除去－パートナシップの構築

オーナーシップ

形式

提供の仕組み

力量－スキル、トレーニング

関連するその他の現在進行中の活動

内部および外部の対象者

全レベルのスタッフの巻き込み

（利害関係者と運用）

期間

重要成功要因

対象者からのフィールドバックのモニタ

適切なメッセージが適切なタイミングで適切な

人々に届くこと

ビジョンとチーム憲章の定義

ギャップ分析の実施作業パッケージと

レポート作成ツールの開発

リーダーシップ・

チームの賛同の獲得

貢献グループの設立

コミュニケーション計画の定義

現在の構成のベースライン設定／

パイロット段階の定義

個人／チームの目標値の合意

目標を達成する方法の計画とフィードバック

の取得

実施、レビュー、報告

プロセス全体のレビュー

現在の状況

予測される状態


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.5.3 コミュニケーションの手法変更のサイクルについて全体的なフィードバックを理解するためのコミュニケーションの一般的な

手法には、以下が含まれます：ワークショップ：ワークショップは、サービストランジションの全体的なアプローチについて、

対象者に明確で一貫したメッセージを伝えることに役立つ。このアプローチは、複数のチー

ム間で理解の構築、オーナシップ、高揚感の喚起のために、あらゆるコミュニケーション戦

略の開始点で役に立つ組織、事業部門、または IT のニュースレター：このコミュニケーション手段は、既に提供さ

れたあらゆるメッセージを補足するのに役立つ。しかしながら、このアプローチは、従業員

がコミュニケーションの手段として最初に目にするものではないことに注意する必要があるトレーニング・セッション：この手段はサービストランジションの一部として利用することがで

きる。役割、またはプロセスは変化していくものであり、的を絞ったトレーニングが必要とな

る。このトレーニングは、従業員が新しい業務方法について手掛かりを得るのに十分な時

間を与えるように計画するべきであるチーム・ミーティング：コミュニケーションの最も手軽な手段の一つで各チームのリーダが、

それぞれの週次ミーティングであらゆるメッセージを補強できるように、サービストランジショ

ン・チームが支援する。従業員が持つ疑問は、このような下位レベルのミーティングでよりよ

く理解される。人々は、日々共に働く同僚との、このようなコミュニケーションの方法に慣れ

ているため、より打ち解けることができる組織全体のミーティング：この手段は、大規模なコミュニケーションで採用され、組織の規模

や種類によって、対面ミーティング、ビデオまたはオーディオの技術を利用したものがある。 1 対 1 のミーティング：この手段は、小さな対象者グループ向きで、主な利害関係者は時間

を取って全ての作業環境を訪れる(フロアを歩く)。ミーティングでは、上級マネジメントによる

前向きな支援の例を示し、従業員に、彼ら自身に関する質問をさせる質疑応答やフィードバック：掲示板、またはメールボックスへの投稿を利用した方法で、従

業員が匿名で質問を出し、懸案へのフィードバックを受け取ることができるシミュレーション・ゲーム：変更についてのコミュニケーションの新しいアプローチで、情報伝

達の実践的で楽しい方法である補足連絡文書：この手法は、上級の利害関係者が、重要な情報を強調したり、実施活動の

最新情報を提供したりするために利用できる。このアプローチはどの段階にも実際に関与

しないであろう人々に対して、サービストランジションの活動を継続的に伝えることができるポスター/ロードマップ：この楽しいアプローチは、導入活動、進捗、または全般的な最新情

報をオフィスの壁に掲示する、良質でカラフルな伝達手段である。コミュニケーションを活発

に維持して一貫したメッセージを伝えるための有効な手段である給与明細による通知：情報が 100%確実に伝わるようにするために、給与明細に重要な伝

達事項を添付する「Z カード」/多重折参照カード：クレジットカードサイズの小さな文書に主要な情報を記載し

たもので、スタッフが財布やバッグにいれて携帯することを意図したものモデルは、各サービスや各種変更に対する期待を伝達するのに役立ちます。図 2.8 は、ある組

織から外部サービス・プロバイダへサービスを移行(アウトソーシング)する際に使用されるモデ

ルの例です。これは、全体的な組織の変更の例で、管理、プロセス、スタッフ配置に変更が実施

されますが、多くのスタッフが新しいサービス・プロバイダの組織に異動することもあります。伝達

しやすい一連のサービス・モデル、変更モデル、移行モデルを利用することで、サービストランジ

ション中の期待の設定に役に立つでしょう。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


図 2.8 アウトソーシングのためのサービストランジションのステップ例 (出典：『サービストランジション』

5.1.3 図 5.3) 2.5.4 モチベーションとコミュニケーションの重要性変更の実現に向けて人々を動機付けする場合、変更の進捗について、良くても悪くても、最新の

情報を知らせ続ける必要があります。Hackman and Oldham(1980)は、人々がよく働こうとするのは、業務を満足いくものと考えているときだ、ということを「内部のモチベーベション」として説明しています。この概念は表 2.1 で定義しています。表 2.1 人々を動機付けする職務の特性職務の必須特性従業員にとっての利点これらの特性がすべてそろっ

ている場合の結果職務からのフィードバック作業活動の実際の結果に関

するナレッジ作業に対する内部のモチベーションの向上

自主性作業の成果に対する責任についての経験

スキルの多様性タスクの認識タスクの重要性

作業の意義深さについての経験

人は、進捗が見えると動機付けされ、没頭するものである。短期間での達成を伝えて、進捗を称賛するべきである。 (出典：『サービストランジション』5.1.4)


ebyサービストランジションの計画

実行（実施）

レビュー（点検）

クローズ（処置）

ビジネスケース

サービストランジションの作業記述書

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

組織モデル

サービストランジションのチーム憲章

マネジメントの後援者チームとスキルのアセスメント変更管理プロセスの開始カルチャ的な価値観に関する

プロファイルと認識のアセスメント共同検証計画コミュニケーション計画レビュー済みの法律上／契約上／

営利上の基盤リスク管理の戦略

サービストランジションのキックオフの実施

品質の評価と不一致への対処組織的およびカルチャ的な変更のレビュー

コミュニケーション計画の開始

サービストランジションのプロセスとワークフローの開始

サプライヤ／パートナの活動と報告の開始

顧客関係の管理

法的／契約管理の開始

サービストランジションのすべて

のプロセスに対する品質管理チェックの定着化

サービストランジションに関与

する顧客とチームの定期的なレビューの実施

SLAなどに基づいたサービス

トランジションのプロセスと解決策の強化と、伝達

全領域における変更の管理の維持

エスカレーション・プロセスのテスト

移行が適用範囲とコスト・モデル

内であることの確認全体を通したリスク管理の維持

SLAが満たされているかの妥当性確認

得られたフィードバックと

教訓に対する顧客とチームによるレビューの実施

変更管理のついての実施後

のレビュー・レポートの作成契約とコスト・モデルの最終

承認サービストランジションに

対する事業の最終承認の獲得

現在進行中の継続的サービス改善に対するけいかくの定義

リスクのアセスメント、レビュー、管理


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.6 コミュニケーションコアブック該当箇所 - 『サービスオペレーション』 3.6 この章では、サービスオペレーションにおける良好なコミュニケーションの必要性を強調していま

す。良好なコミュニケーションは、他の IT チームや部門、ユーザや内部顧客、またサービスオペ

レーション・チームと部門自体の間で必要とされます。適切なコミュニケーションより、課題の発生

が防止されたり、課題が緩和されたりすることが多いです。重要な原則として、全てのコミュニケーションには、本来の目的や結果的な処置が必要となりま

す。対象者が明確でなければ、情報を伝えるべきではありません。さらに、その対象者は、コミュ

ニケーションの必要性の判断と、その情報の扱い方の判断に、関与し続ける人であるべきです。

さらに、情報が対象者にまだ必要とされているかということを検証するために、定期的に、継続中

のコミュニケーションをレビューする必要があります。

典型的な対象者と、各コミュニケーションの結果として取るべき処置も説明している。それには次のものが含まれる。

運用に関する日常的なコミュニケーションシフト間のコミュニケーションパフォーマンス報告プロジェクトにおけるコミュニケーション変更に関するコミュニケーション例外に関するコミュニケーション緊急事態に関するコミュニケーション新規またはカスタマイズされたプロセスおよびサービス設計のトレーニングサービスオペレーション・チームに対する戦略、設計、および移行の伝達


コミュニケーション手段は組織によって異なることがあります。コミュニケーションをミーティングで

行う組織もあれば、電子メールの利用や組織内のサービスマネジメント・ツール固有のコミュニケ

ーションを好む組織もあります。

そのため、各チームまたは部門のコミュニケーションや、各プロセスのためのコミュニケーション

についての方針がなくてなりません。例えば、1 人のマネージャが、変更に関する全ての伝達事

項を電子メールで送るべきだと要求している場合、このことが、その部門の SOP(どんな形式で存

在するかは問いません)に規定されている限り、別の方針を作成する必要はありません。

コミュニケーションの一般的な内容は、一度プロセスが定義されれば、ほぼ一定して変わらないが、コミュニケーションの手段は、新技術導入のたびに変化する。代替手段は増えつつあり、現在では次のようなものがある。

従来のクライアントや携帯機器への電子メールソーシャル・メディアとミニブログ・サービスウェブベースのインターネット・リレー・チャット(IRC) ショート・メッセージ・サービスのメッセージページャインスタント・メッセージ、携帯メール、およびウェブベースの「チャット」 VOIP(voice over internet protocol)のユーティリティ。あらゆる接続機器を安価なコミュニケ

ーション媒体へと変えることができるテレビ電話会議やバーチャル・ミーティングのユーティリティ。遠隔地同士で開催するミーテ

ィングに変革をもたらした文書共有のユーティリティ



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


全ての利害関係者がコミュニケーションをとる方法や時期を理解し、継続的にコミュニケーション

を利用する必要性を示している限り、どのようなコミュニケーションでも使用できます。 2.6.1 ミーティング組織が異なれば、コミュニケーションの方法も変わります。組織が分散している場合、電子メール

や電話会議設備に依存する傾向があります。より成熟したサービスマネジメント・プロセスとツー

ル(例えば、電子メールや電話で更新を依頼する代わりに、インシデントのエスカレーションや追

跡を行うインシデント管理ツールを使う)を備えています。しかしながら、多くの組織はミーティングを利用したコミュニケーションを好みます。ミーティングは

好まれる方法ですが、適切に計画し調整されなければ、多くの時間を浪費していまいます。ミー

ティングは、適切にコントロールされ簡潔であるべきです。また、実行を促すことに焦点を当てる

べきです。そのため、ミーティング主催者は、ミーティングの価値と、出席者の数と彼らがミーティ

ングで費やす時間と労力のバランスをとらなければなりません。自動化された方法で情報が効

果的に伝達される場合や、情報の伝達だけが目的という場合はミーティングを開かないというの

は良いルールでしょう。ミーティングを成功させるには多くの要素が必要です。要素は以下の通りです：

参加者が議題を事前に準備し、ミーティングでその目的を達成できるように、前もって明確

なアジェンダを作成し、参加者に事前に伝えておく参加上のルールを確実に理解させる。組織は、正式な一連のミーティングのルールを持つ

傾向がある。それらは比較的略式なものから正式なものまで幅がある「パーキング・ロット」やノートを活用する。これらは、ミーティングの目的には直接関連はな

いが議論の必要性が生じたときに要求される課題を記録しておくミーティングの議事録を作成する。議事録は、処置を割り当てられた人々に忘れさせないた

めに、また委任された処置の経過を追跡するために利用される。また、機能横断的な決定

や処置が追跡され実施されるようにすることにも役に立つ。議事録には、実施事項、誰のた

めに、担当する部門、および期限が必ず記録され、許容可能な期限内で公開されるべきで

ある適切なレベルの参加を促すための技法を利用する。例えば、改善について議論する際の

技法の１つに、「継続、停止、開始」の技法がある。出席者は、継続したい事項、停止する

必要のある項目、また開始させたいと思う取り組みや処置をリストアップするように奨励す

る一般的なミーティングの例を次に示す。 1. 運用ミーティング運用ミーティングは通常、IT 運用の部門、チーム、またはグループのマネージャたちの間で、各営業日か各営業週の初めに行う。この種類のミーティングの目的は、運用に関するあらゆる課題(変更スケジュール、事業イベント、保守スケジュールなど)をスタッフに認識させることと、スタッフに自分たちが認識しているあらゆる課題を提起する機会を提供することである。データセンタの全部門の同期が取れていることを確認する機会でもある。地理的に分散した組織では、単一の日次運用ミーティングを行うことは不可能だろう。このような場合、各ミーティングの議事を調整し、各ミーティングには次の 2 つの要素を持たせるようにすることが重要である。ミーティングの前半では、組織全体に当てはまる側面を取り上げる。例えば、全地域に影響する新規方針や変更、全地域に及ぶ事業イベントなどミーティングの後半では、その地域にだけ当てはまる側面を取り上げる。例えば、該当地域の運用スケジュール、該当地域の機器に対する変更など運用ミーティングは通常、IT 運用マネージャや上級運用マネージャが議長を務め、すべてのマネ


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


ージャとスーパーバイザが出席する(シフトの勤務時間外の場合を除く)。同時に、サービスデスクから少なくとも 1人の代表がミーティングに出席し、インシデントを起こす可能性のあるあらゆる状況を認識できるようにすることも有益である。サービスやプロセスの改善機会がもし提示されれば把握して、CSI の責任を負うチームに申し送るべきである。 2. 部門ミーティング、グループ・ミーティング、チーム・ミーティング本質的には運用ミーティングと同じであるが、これらのミーティングは IT の単一の部門、グループ、またはチームを対象としている。各マネージャやスーパーバイザは、各自のチームに関係する運用ミーティングの情報を伝える。これらのミーティングでは、今も対処しているインシデント、問題、および変更に関するより詳細な議論と、次の点に関する情報を取り上げる。

これまでの進捗これから実行するべき事項の確認予想完了時間必要な場合、追加リソースの要求起こりうる問題や懸案の議論勤務当番表記載の作業内容に対するスタッフ可用性の確認休暇スケジュールの確認

3. 顧客とのミーティング定期的なサービスレベル・レビュー・ミーティングとは別に、顧客とのミーティングを時々行う必要がある。次に例を示す。

重大なインシデント後のフォローアップこのようなミーティングの目的は顧客との関係を修復するためであるが、再発防止に必要なすべての情報を IT が確実に把握するためでもある。顧客にとっては、事業への不測のインパクトについて情報を提供する機会にもなる。こうしたミーティングは、将来発生しうる同種のインシデントの処置について合意するうえで有益である

顧客フォーラムこれはさまざまな目的で使用でき、例えば、新しいサービスやソリューションのアイデアをテストしたり、新規または改定されたサービスや手順に関する要件を収集したりする。顧客フォーラムは一般に、顧客との定期的なミーティングであり、共通の懸案を議論する

顧客とのミーティング顧客へのコミュニケーションが調整され一貫したものになるよう、事業関係管理およびサービスレベル・マネージャと協力してスケジューリングし、開催するべきである


2.6.2 コミュニケーションの戦略と計画コアブック該当箇所 - 『継続的サービス改善』8.5 継続的サービス改善のためには、適時で効果的なコミュニケーションを取ることが最も重要な要

素となります。その場しのぎで CSI 活動を実施する状態から、より正式で継続的な CSI 活動を実

施することへ組織を変革する取り組みの中で、参加者と利害関係者に、プロセス、活動、役割、

および責任へのあらゆる変更が通達されることが重要です。そのため、コミュニケーション計画を策定する時には、CSI の取り組みに対する主要な影響力の

ある利害関係者の意識、理解、熱意、および支持を確立し維持するこが重要です。コミュニケー

ション計画には、対象者からの反応、およびフィードバックに対処する能力が含まれている必要

があります。


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


コミュニケーション計画には、次を行う役割が含まれるべきである。 CSI の他の役割、他の ITSM プロセスの役割などの利害関係者、および識別された対象者

に対するコミュニケーションを設計し、実施する顧客およびユーザのフィードバックのためのフォーラムを特定する反応およびフィードバックを受け取り、プロジェクト・マネージャやプロセスのチーム・メンバ

にそれらを提供するコミュニケーション計画の主要な活動には、次が含まれる。

利害関係者と対象者の識別コミュニケーションの戦略と戦術の策定コミュニケーションの手法と技法の識別コミュニケーション計画の策定(誰が、何を、なぜ、いつ、どこで、どのように、に関するマトリ

クス) プロジェクトのマイルストーンと、関連するコミュニケーション要件の識別対象者の理解のレベルを把握するために使用するツールと技法。例えば、調査、ウェブサ

イトヘのアクセス、イベントヘの参加など

(出典：『継続的サービス改善』 8.5) 本章の最初で説明したように、サービストランジション・チームのメンバは、組織内で発生するど

んな変更に対しても、対象者の姿勢や熱意を組み入れる必要があります。行動を変え、最終的

に組織のカルチャを変えるために、十分に練られたコミュニケーション戦略と計画が必要になり

ます。効果的なコミュニケーション戦略と計画は、組織がサービスマネジメントを導入している理

由、CSI プロセスを正式なものにすることを望む理由、および ITIL がベストプラクティスのフレー

ムワークとして選択された理由についての意識を高めることに役立ちます。また、この計画は、

正式なトレーニング・プログラムや内部ミーティングによって、サービスマネジメント教育を提供す

る方法、新たな期待をもたらす新しいプロセスとツールについての正式なトレーニングを提供す

る方法、また進捗と達成度についての最新情報を提供する方法を扱う必要があります。コミュニケーション戦略と計画を策定する際には、以下のルールを念頭に置く必要があります：

企業のコミュニケーションが現在どのように機能しているかを考慮することが重要である。

一部の組織では、CSI または何らかのサービスマネジメント・プロジェクトを代表して最高情

報責任者(CIO：chief information officer)にコミュニケーションを行ってもらおうとすると、長

い時間がかかる場合がある。そのようなことも計画に組み込む必要がある事業とのコミュニケーションに関するカルチャも念頭に置くこと。事業とコミュニケーションを

行うことができる人に関して厳しい指針がある組織もある。このコミュニケーションは、サー

ビスレベル管理(SLM)プロセスと事業関係管理プロセスによって行われることが多い。手法

がどのようなものであれ、事業とのコミュニケーションを、常に主要なコミュニケーション活動

の 1 つに位置付けること


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.6.3 コミュニケーション計画の定義(出典『継続的サービス改善』8.5.1) 計画を定義するには、以下の項目を考慮する必要があります：

誰がメッセージ発信者であるか? これは、メッセージ発信者とメッセージを整合させることの重要性をアセスメントする場合に、見落とされることが多い。CIO がコミュニケーションを行うのが適切なことも、サービス・オーナまたはプロセス・オーナがコミュニケーションを行うべきであることもある

メッセージは何であるか? メッセージの目的と達成目標を定義する。これは、対象者に合わせて調整する必要がある。CSIの取り組みの利点を伝達することの重要性を念頭に置くこと。What's- In- It- For-Me(それは自分にどのような利点があるのか)アプローチはここでも有効であり、これに留意する必要がある

誰が対象者であるか? CSI の対象者は上級マネジメント、ミドル・マネージャ、または CSI 活動の実施に取り組むスタッフである場合がある。メッセージの内容に基づいて誰がメッセージを提供するかは、対象者によって決まることが多い

コミュニケーションのタイミングと頻度適時のコミュニケーションを計画し、実施すること。変更の管理に関する不変の事実は、コミュニケーションを効果的にするには、一回限りのコミュニケーション以上のものが必要であるということである。伝達されているものが報告であれば、報告のスケジュールと頻度を定義する必要があるだろう

コミュニケーションの手法電子メールを送る、何かをウェブ上で公開するといった従来からの決まったやり方は、ある形式のコミュニケーションには機能するかもしれないが、変更を効果的に管理するためには、双方向のコミュニケーションの機会となる対面ミーティングを行うことが重要である。スタッフ・ミーティングヘの出席、IT 要員の全員が自由に出席できる情報ミーティングの開催、およびタウン・ホール・ミーティングの開催はすべて、考慮するべき非常に効果的な手法である

フィードバックの仕組みの提供従業員が変更の取り組みについて質問したり、フィードバックを提供したりするための、何らかの手法を提供すること。質問またはコメントが回答されていることを確認し、それを徹底するオーナシップを持つ人がいるべきである

(出典：『継続的サービス改善』 8.5.1)

文書化されたコミュニケーション戦略と計画は効果的な実行を認識するのに役立つため、忘れず

にそれら全てのコミュニケーション戦略と計画を文書化することです。表 2.2 に示すように、コミュニケーション計画のための簡潔な表を作成することができる。IT 内のさまざまなグループとコミュニケーションを取ることを念頭に置くこと。また、上級マネジメント、ミドル・マネージャ、およびラインの貢献者だけでなく、CSI 活動に取り組む人や、それをサポートする人を必ず含めること。表 2.2 コミュニケーション計画表のサンプルメッセージ発信者

対象者メッセージコミュニケーションの手法

日時と頻度ステータス

CIO IT の全員 CSI の取り組みの開始

タウン・ホール・ミーティング

月/日計画済み

(出典：『継続的サービス改善』 8.5.1)


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


2.6.4 コミュニケーションの変革組織内の新たな取り組みについてのコミュニケーションは、戦略的レベルで始められなければな

りません。CSI の取り組みは、戦略的レベルから戦術レベルへ、そしてその後は運用レベルへ引

き継がれます。各レベルが固有の変革プロセスを経ることは例外でなくむしろ普通なことです。情報の流れは、全てのレベルで等しく伝達されなければなりません。理想的には、伝達された情

報をどのように扱うかを伝えるために、上位のレベルは、プロセスについてのフィードバックを、

次のレベルに伝えなければなりません。このプロセスは、組織が次のレベルへ変革することに役

立ちます。残念なことに、ビジョンの内容や組織の変更の理由は、組織の下層へと伝えられる毎に、次第に

理解されなくなっていきます。組織の変更の背景となる理論的根拠の一部だけが運用レベルに

届きます。図 2.9は、ビジョンの元の内容の一部だけが運用レベルに伝わる様子(「上層レベルの

影」)を示しています。メッセージが運用レベルに伝わる時、ビジョンの明確さや内容がさらに曖昧

になります。

図 2.9 ビジョンがあいまいになる様子(出典：『継続的サービス改善』図 8.2) マネジメントの各レベルは独自の異なる変革プロセスを有しているため、他のレベルの感情を理

解できません。これは運用レベルのスタッフで最も顕著になります。スタッフが議論に関わってい

ない場合は、特にスタッフは無力を感じます。しかし、運用レベルのスタッフのコミットメントと活力

は、組織のあらゆる変更の成功に不可欠なものです。

ビジョン

コミュニケーション・ライン

変革

変革

変革

戦略的

戦術的

運用上


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| STUDENT | ライフサイクル全体の管理 | ITIL用語および頭字語集 |

ITIL®日本語版用語集、v1.0、2011 年 10 月 13 日英語版用語集 v1.0、2011 年 7 月 29 日に基づく

ITIL 用語および頭字語集

日本語

本用語集は自由にダウンロードできます。使用許諾条件の詳細は、www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

を参照してください。

© Crown Copyright 2011 1


Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

http://www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

http://www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx


謝辞 2007 年 5 月に ITIL 英語版用語集の原本を作成した Ashley Hanna（HP）と Stuart Rance（HP）に、および 2011 年 7 月に同用語集を更新した Ashley Hanna に、感謝の意を表します。 ITIL コア書籍の 2007 年版および 2011 年版に貢献したすべての人々にも感謝を申し上げます。貢

献者名のリストは、www.itil-officialsite.com/Publications/PublicationAcknowledgements.aspx をご

覧ください。また、日本語版用語集の翻訳プロジェクトを推進した itSMF Japan の小山條二、中井秀有、八木

隆ならびに品質保証チームの次の専門家の皆様に対し、感謝を申し上げます。青木保壽富士通岩村郁雄日本アイ・ビー・エム・システムズ・エンジニアリング瀧本研介日本マイクロソフト野村紀美シーエーシー松長由香里日立電子サービス森田礼子アビリティ・インタービジネス・ソリューションズ



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

http://www.itil-officialsite.com/Publications/PublicationAcknowledgements.aspx


用語集

英語版用語日本語版用語英語版の定義日本語版の定義

acceptance 受け入れ Formal agreement that an IT service, process, plan or other deliverable is complete, accurate, reliable and meets its specified requirements. Acceptance is usually preceded by change evaluation or testing and is often required before proceeding to the next stage of a project or process. See also service acceptance criteria.

IT サービス、プロセス、計画、ま

たはその他の成果物が、完全かつ

正確で信頼性があり、特定の要件

を満たしているという正式な合

意。通常、受け入れの前には変更

評価またはテストが行われる。ま

た、プロジェクトやプロセスの次

の段階に進む前に要求されること

が多い。サービス受け入れ基準も

参照。

access management

アクセス管理 (ITIL Service Operation) The process responsible for allowing users to make use of IT services, data or other assets. Access management helps to protect the confidentiality, integrity and availability of assets by ensuring that only authorized users are able to access or modify them. Access management implements the policies of information security management and is sometimes referred to as rights management or identity management.

（ITIL サービスオペレーション）

IT サービス、データ、またはその

他の資産をユーザが活用できるよ

うにすることを責務とするプロセ

ス。アクセス管理は、許可された

ユーザだけが資産へのアクセスま

たは修正を行えるようにすること

で、資産の機密性、完全性、およ

び可用性の保護を支援する。アク

セス管理は、情報セキュリティ管

理の方針を実施し、権限管理また

は ID 管理と呼ばれることもある。

account manager

アカウント・

マネージャ (ITIL Service Strategy) A role that is very similar to that of the business relationship manager, but includes more commercial aspects. Most commonly used by Type III service providers when dealing with external customers.

（ITIL サービスストラテジ）事業

関係マネージャの役割に極めて類

似した役割。ただし、より営利的

な側面を扱う。タイプ III サービ

ス・プロバイダが外部顧客を扱う

場合に最もよく配置される。

accounting 会計業務 (ITIL Service Strategy) The process responsible for identifying the actual costs of delivering IT services, comparing these with budgeted costs, and managing variance from the budget.

（ITIL サービスストラテジ）IT サ

ービスの提供にかかる実際のコス

トを識別し、それらのコストを見

積もられたコストと比較して、予

算との不一致を管理することを責

務とするプロセス。

accounting period

会計期間 (ITIL Service Strategy) A period of time (usually one year) for which budgets, charges, depreciation and other financial calculations are made. See also financial year.

（ITIL サービスストラテジ）予

算、料金、減価償却、およびその

他の財務上の計算の対象となる期

間（通常は 1 年間）。会計年度も

参照。

accredited 認定 Officially authorized to carry out a role. For example, an accredited body may be authorized to provide training or to conduct audits.

ある役割を実行することを公式に

認可されること。例えば、認定団

体は、トレーニングや監査の実施

を認可されている。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| ITIL® ライフサイクル全体の管理 | STUDENT | 英語版用語日本語版用語英語版の定義日本語版の定義

active monitoring 能動的モニタ

リング (ITIL Service Operation) Monitoring of a configuration item or an IT service that uses automated regular checks to discover the current status. See also passive monitoring.


自動的な定期チェックを利用して

現状を把握する、構成アイテムま

たは IT サービスのモニタリング。

受動的モニタリングも参照。

activity 活動 A set of actions designed to achieve a particular result. Activities are usually defined as part of processes or plans, and are documented in procedures.

特定の結果を達成するために計画

された一連の処置。活動は、通

常、プロセスまたは計画の一部と

して定義され、手順に記載され

る。

agreed service time (AST)

合意済みサー

ビス時間

（AST）

(ITIL Service Design) A synonym for service hours, commonly used in formal calculations of availability. See also downtime.

（ITIL サービスデザイン）サービ

ス時間の同義語。可用性の正式な

計算によく使用される。停止時間

も参照。

agreement 合意 A document that describes a formal understanding between two or more parties. An agreement is not legally binding, unless it forms part of a contract. See also operational level agreement; service level agreement.

複数の当事者間における正式な合

意を記載した文書。合意は、契約

の一部を構成しないかぎり、法的

な拘束力を持たない。オペレーシ

ョナルレベル・アグリーメント、

サービスレベル・アグリーメント

も参照。

alert アラート (ITIL Service Operation) A notification that a threshold has been reached, something has changed, or a failure has occurred. Alerts are often created and managed by system management tools and are managed by the event management process.


しきい値に達したとき、変更があ

ったとき、または障害が発生した

ときの通知。アラートは多くの場

合、システム管理ツールで生成お

よび管理され、イベント管理プロ

セスで管理される。

analytical modelling

分析モデル化 (ITIL Continual Service Improvement) (ITIL Service Design) (ITIL Service Strategy) A technique that uses mathematical models to predict the behaviour of IT services or other configuration items. Analytical models are commonly used in capacity management and availability management. See also modelling; simulation modelling.

（ITIL 継続的サービス改善）（ITILサービスデザイン）（ITIL サービ

スストラテジ）IT サービスまたは

その他の構成アイテムの動作を、

数理モデルを使用して予測する技

法。分析モデルは、キャパシティ

管理と可用性管理によく使用され

る。モデル化、シミュレーショ

ン・モデル化も参照。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| STUDENT | ライフサイクル全体の管理 | ITIL用語および頭字語集 | 英語版用語日本語版用語英語版の定義日本語版の定義

application アプリケーシ

ョン Software that provides functions which are required by an IT service. Each application may be part of more than one IT service. An application runs on one or more servers or clients. See also application management; application portfolio.

IT サービスに必要とされる機能を

提供するソフトウェア。各アプリ

ケーションは、複数の IT サービス

の一部になる場合がある。アプリ

ケーションは、1 台または複数の

サーバまたはクライアント上で実

行される。アプリケーション管

理、アプリケーション・ポートフ

ォリオも参照。

application management

アプリケーシ

ョン管理 (ITIL Service Design) (ITIL Service Operation) The function responsible for managing applications throughout their lifecycle.

（ITIL サービスデザイン）（ITILサービスオペレーション）アプリ

ケーションのライフサイクルを通

した管理を責務とする機能。

application portfolio

アプリケーシ

ョン・ポート

フォリオ

(ITIL Service Design) A database or structured document used to manage applications throughout their lifecycle. The application portfolio contains key attributes of all applications. The application portfolio is sometimes implemented as part of the service portfolio, or as part of the configuration management system.

（ITIL サービスデザイン）アプリ

ケーションのライフサイクルを通

した管理に使用するデータベース

または構造化された文書。アプリ

ケーション・ポートフォリオに

は、すべてのアプリケーションの

主要な属性が含まれている。アプ

リケーション・ポートフォリオ

は、サービス・ポートフォリオの

一部、または構成管理システムの

一部として導入されることがあ

る。

application service provider (ASP)

アプリケーシ

ョン・サービ

ス・プロバイ

ダ（ASP）

(ITIL Service Design) An external service provider that provides IT services using applications running at the service provider’s premises. Users access the applications by network connections to the service provider.

（ITIL サービスデザイン）自組織

の施設内で実行しているアプリケ

ーションを使用して、IT サービス

を提供する外部サービス・プロバ

イダ。ユーザはサービス・プロバ

イダにネットワーク接続すること

によって、アプリケーションにア

クセスする。

application sizing

アプリケーシ

ョン・サイジ

ング

(ITIL Service Design) The activity responsible for understanding the resource requirements needed to support a new application, or a major change to an existing application. Application sizing helps to ensure that the IT service can meet its agreed service level targets for capacity and performance.

（ITIL サービスデザイン）新しい

アプリケーションや、既存のアプ

リケーションに対する重大な変更

をサポートするために必要なリソ

ース要件の把握を責務とする活

動。アプリケーション・サイジン

グは、IT サービスが、キャパシテ

ィとパフォーマンスに関する合意

済みサービスレベル目標値を確実

に達成できるようにするために役

立つ。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


architecture アーキテクチ

ャ (ITIL Service Design) The structure of a system or IT service, including the relationships of components to each other and to the environment they are in. Architecture also includes the standards and guidelines that guide the design and evolution of the system.

（ITIL サービスデザイン）システ

ムまたは IT サービスの構造。コン

ポーネント同士の関係や、コンポ

ーネントとその環境との関係も含

む。アーキテクチャには、システ

ムの設計や発展を手引きする標準

や指針も含まれる。

assembly アセンブリ (ITIL Service Transition) A configuration item that is made up of a number of other CIs. For example, a server CI may contain CIs for CPUs, disks, memory etc.; an IT service CI may contain many hardware, software and other CIs. See also build; component CI.

（ITIL サービストランジション）

他の複数の構成アイテム（CI）か

ら成る CI。例えば、サーバ CI には CPU、ディスク、メモリなどの

CI が含まれ、IT サービス CI には

多数のハードウェア、ソフトウェ

ア、およびその他の CI が含まれる

だろう。構築、コンポーネント CIも参照。

assessment アセスメント Inspection and analysis to check whether a standard or set of guidelines is being followed, that records are accurate, or that efficiency and effectiveness targets are being met. See also audit.

標準や一連の指針に従っている

か、レコードが正確か、効率性と

有効性の目標値が満たされている

かなどを確認する検査と分析。監

査も参照。

asset 資産 (ITIL Service Strategy) Any resource or capability. The assets of a service provider include anything that could contribute to the delivery of a service. Assets can be one of the following types: management, organization, process, knowledge, people, information, applications, infrastructure or financial capital. See also customer asset; service asset; strategic asset.

（ITIL サービスストラテジ）任意

のリソースまたは能力。サービ

ス・プロバイダの資産には、サー

ビスの提供に寄与する可能性があ

るすべてのものが含まれる。資産

は、管理、組織、プロセス、ナレ

ッジ、人材、情報、アプリケーシ

ョン、インフラストラクチャ、金

融資本のいずれかのタイプになり

うる。顧客資産、サービス資産、

戦略的資産も参照。

asset management

資産管理 (ITIL Service Transition) A generic activity or process responsible for tracking and reporting the value and ownership of assets throughout their lifecycle. See also service asset and configuration management; fixed asset management; software asset management.


資産の価値とオーナシップを、そ

の資産のライフサイクルを通して

追跡および報告することを責務と

する一般的な活動またはプロセ

ス。サービス資産管理および構成

管理、固定資産管理、ソフトウェ

ア資産管理も参照。

asset register 資産管理表 (ITIL Service Transition) A list of fixed assets that includes their ownership and value. See also fixed asset management.


固定資産の一覧。各資産のオーナ

シップと価値が含まれる。固定資

産管理も参照。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


asset specificity 資産の特殊性 (ITIL Service Strategy) One or more attributes of an asset that make it particularly useful for a given purpose. Asset specificity may limit the use of the asset for other purposes.

（ITIL サービスストラテジ）ある

資産をある目的に特に有用になる

ようにする 1 つまたは複数の属

性。資産の特殊性により、その資

産の他の目的への利用が制限され

る場合がある。

attribute 属性 (ITIL Service Transition) A piece of information about a configuration item. Examples are name, location, version number and cost. Attributes of CIs are recorded in a configuration management database (CMDB) and maintained as part of a configuration management system (CMS). See also relationship; configuration management system.


構成アイテムに関する情報の一

部。名前、場所、バージョン番

号、コストなど。CI の属性は、構

成管理データベース（CMDB）に

記録され、構成管理システム

（CMS）の一部として維持され

る。関係、構成管理システムも参

照。

audit 監査 Formal inspection and verification to check whether a standard or set of guidelines is being followed, that records are accurate, or that efficiency and effectiveness targets are being met. An audit may be carried out by internal or external groups. See also assessment; certification.

標準や一連の指針に従っている

か、レコードが正確か、効率性と

有効性の目標値が満たされている

かなどを確認する、正式な検査と

検証。監査は、内部グループまた

は外部グループによって行うこと

ができる。アセスメント、認証も

参照。

authority matrix 職務権限マト

リクス See RACI. RACI を参照。

automatic call distribution (ACD)

自動着信呼分

配（ACD） (ITIL Service Operation) Use of information technology to direct an incoming telephone call to the most appropriate person in the shortest possible time. ACD is sometimes called automated call distribution.


情報技術を活用して、最適な相手

に最短時間で着信呼を振り分ける

こと。ACD（Automatic Call Distribution）は Automated Call Distribution と表記されることもあ

る。

availability 可用性 (ITIL Service Design) Ability of an IT service or other configuration item to perform its agreed function when required. Availability is determined by reliability, maintainability, serviceability, performance and security. Availability is usually calculated as a percentage. This calculation is often based on agreed service time and downtime. It is best practice to calculate availability of an IT service using measurements of the business output.

（ITIL サービスデザイン）IT サー

ビスまたはその他の構成アイテム

が、必要とされたときに、合意済

みの機能を実行する能力。可用性

は、信頼性、保守性、サービス

性、パフォーマンス、およびセキ

ュリティによって決定される。可

用性は、通常、パーセンテージで

計算される。この計算は、合意済

みサービス時間と停止時間に基づ

いて行われることが多い。事業の

アウトプットからの測定値を使用

して、IT サービスの可用性を計算

するのがベストプラクティスであ

る。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


availability management (AM)

可用性管理

（AM） (ITIL Service Design) The process responsible for ensuring that IT services meet the current and future availability needs of the business in a cost-effective and timely manner. Availability management defines, analyses, plans, measures and improves all aspects of the availability of IT services, and ensures that all IT infrastructures, processes, tools, roles etc. are appropriate for the agreed service level targets for availability. See also availability management information system.


ビスが、現在および将来の可用性

に関する事業のニーズを高い費用

対効果でタイムリーに達成される

ようにすることを責務とするプロ

セス。可用性管理は、IT サービス

の可用性のすべての側面を定義、

分析、計画、測定、および改善

し、すべての IT インフラストラク

チャ、プロセス、ツール、役割な

どが、可用性に関する合意済みサ

ービスレベル目標値に適切である

ようにする。可用性管理情報シス

テムも参照。

availability management information system (AMIS)

可用性管理情

報システム

（AMIS）

(ITIL Service Design) A set of tools, data and information that is used to support availability management. See also service knowledge management system.

（ITIL サービスデザイン）可用性

管理の支援に使用される一連のツ

ール、データ、および情報。サー

ビス・ナレッジ管理システムも参

照。

availability plan 可用性計画 (ITIL Service Design) A plan to ensure that existing and future availability requirements for IT services can be provided cost-effectively.


ビスに対する現在および将来の可

用性要件を、費用対効果よく満た

すようにするための計画。

back-out 切り戻し (ITIL Service Transition) An activity that restores a service or other configuration item to a previous baseline. Back-out is used as a form of remediation when a change or release is not successful.


サービスまたはその他の構成アイ

テムを以前のベースラインに戻す

活動。切り戻しは、変更またはリ

リースがうまくいかなかったとき

の修復の一形式である。

backup バックアップ (ITIL Service Design) (ITIL Service Operation) Copying data to protect against loss of integrity or availability of the original.

（ITIL サービスデザイン）（ITILサービスオペレーション）元のデ

ータの完全性や可用性の喪失を防

止するために、データをコピーす

ること。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


balanced scorecard

バランス・ス

コアカード (ITIL Continual Service Improvement) A management tool developed by Drs Robert Kaplan (Harvard Business School) and David Norton. A balanced scorecard enables a strategy to be broken down into key performance indicators. Performance against the KPIs is used to demonstrate how well the strategy is being achieved. A balanced scorecard has four major areas, each of which has a small number of KPIs. The same four areas are considered at different levels of detail throughout the organization.

（ITIL 継続的サービス改善）ハー

バード・ビジネス・スクールのロ

バート・キャプラン（Robert Kaplan）教授とデイビッド・ノー

トン（David Norton）教授によっ

て開発された管理手法。バラン

ス・スコアカードを使用すると、

戦略を重要業績評価指数（KPI）に

細分化できる。戦略がいかにうま

く達成されているかを示すため

に、KPI に照らしたパフォーマン

スが使用される。バランス・スコ

アカードには 4 つの主要な領域が

あり、各領域に少数の KPI が含ま

れる。これら 4 つの領域は、組織

全体を通して、さまざまな詳細レ

ベルで検討される。

baseline ベースライン ITIL Continual Service Improvement) (ITIL Service Transition) A snapshot that is used as a reference point. Many snapshots may be taken and recorded over time but only some will be used as baselines. For example:

• An ITSM baseline can be used as a starting point to measure the effect of a service improvement plan

• A performance baseline can be used to measure changes in performance over the lifetime of an IT service

• A configuration baseline can be used as part of a back-out plan to enable the IT infrastructure to be restored to a known configuration if a change or release fails.

See also benchmark.

（ITIL 継続的サービス改善）（ITILサービストランジション）基準点

として使用されるスナップショッ

ト。時間の経過につれて、多くの

スナップショットが取られて記録

される場合があるが、ベースライ

ンとして使用されるのはその一部

のみである。例として、次のよう

なものがある。

• ITSM ベースラインは、サー

ビス改善計画の効果の測定の

開始点として使用できる

• パフォーマンス・ベースライ

ンは、IT サービスの存続期間

を通したパフォーマンスの変

化の測定に使用できる

• 構成ベースラインは、変更ま

たはリリースが失敗した場合

に IT インフラストラクチャを

既知の構成に戻せるようにす

るための切り戻し計画の一部

として使用できる

ベンチマークも参照。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


benchmark ベンチマーク (ITIL Continual Service Improvement) (ITIL Service Transition) A baseline that is used to compare related data sets as part of a benchmarking exercise. For example, a recent snapshot of a process can be compared to a previous baseline of that process, or a current baseline can be compared to industry data or best practice. See also benchmarking; baseline.

（ITIL 継続的サービス改善）（ITILサービストランジション）ベンチ

マーキング作業の際に、関連する

一連のデータとの比較に使用され

るベースライン。例えば、プロセ

スの最近のスナップショットをそ

のプロセスの以前のベースライン

と比較したり、現在のベースライ

ンを業界データやベストプラクテ

ィスと比較したりできる。ベンチ

マーキング、ベースラインも参

照。

benchmarking ベンチマーキ

ング (ITIL Continual Service Improvement) The process responsible for comparing a benchmark with related data sets such as a more recent snapshot, industry data or best practice. The term is also used to mean creating a series of benchmarks over time, and comparing the results to measure progress or improvement. This process is not described in detail within the core ITIL publications.

（ITIL 継続的サービス改善）ベン

チマークを、より最近のスナップ

ショット、業界データ、ベストプ

ラクティスなどの関連する一連の

データと比較することを責務とす

るプロセス。この用語は、長期間

にわたって一連のベンチマークを

作成すること、そして進捗や改善

を評価するためにその結果を比較

することも指す。このプロセス

は、ITIL コア書籍では詳細に説明

されていない。

Best Management Practice (BMP)

ベスト・マネ

ジメント・プ

ラクティス

（BMP）

The Best Management Practice portfolio is owned by the Cabinet Office, part of HM Government. Formerly owned by CCTA and then OGC, the BMP functions moved to the Cabinet Office in June 2010. The BMP portfolio includes guidance on IT service management and project, programme, risk, portfolio and value management. There is also a management maturity model as well as related glossaries of terms.

ベスト・マネジメント・プラクテ

ィス・ポートフォリオは、英国政

府の内閣府が所有している。BMPに関する職務は、以前は CCTA そ

の後 OGC の責任下にあったが、

2010 年 6 月に内閣府に引き継がれ

た。BMP ポートフォリオには、ITサービスマネジメントのほか、プ

ロジェクト管理、プログラム管

理、リスク管理、ポートフォリオ

管理、および価値管理に関する手

引きが含まれる。管理の成熟度モ

デルおよび関連する用語集もあ

る。

best practice ベストプラク

ティス Proven activities or processes that have been successfully used by multiple organizations. ITIL is an example of best practice.

複数の組織で成功している、実績

のある活動またはプロセス。ITILはベストプラクティスの一例であ

る。

billing 請求処理 (ITIL Service Strategy) Part of the charging process. Billing is the activity responsible for producing an invoice or a bill and recovering the money from customers. See also pricing.

（ITIL サービスストラテジ）課金

プロセスの一部。請求処理は、明

細書や請求書を作成し、顧客から

料金を回収することを責務とする

活動である。価格設定も参照。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


brainstorming ブレインスト

ーミング (ITIL Service Design) (ITIL Service Operation) A technique that helps a team to generate ideas. Ideas are not reviewed during the brainstorming session, but at a later stage. Brainstorming is often used by problem management to identify possible causes.

（ITIL サービスデザイン）（ITILサービスオペレーション）チーム

でアイデアを出すことを支援する

技法。アイデアのレビューは、ブ

レインストーミング・セッション

中ではなく、セッション後に行わ

れる。ブレインストーミングは、

考えられる原因を識別するために

問題管理で使用されることが多

い。

British Standards Institution (BSI)

英国規格協会

（BSI） The UK national standards body, responsible for creating and maintaining British standards. See www.bsi-global.com for more information. See also International Organization for Standardization.

英国標準の作成と維持を責務とす

る、英国の国内標準化団体。詳細

は、www.bsi-global.comを参照。

国際標準化機構（ISO）も参照。

budget 予算 A list of all the money an organization or business unit plans to receive, and plans to pay out, over a specified period of time. See also budgeting; planning.

特定の期間中に組織または事業部

門が受け取ること、または支払う

ことを計画している、すべての金

額の一覧。予算業務、計画立案も

参照。

budgeting 予算業務 The activity of predicting and controlling the spending of money. Budgeting consists of a periodic negotiation cycle to set future budgets (usually annual) and the day-to-day monitoring and adjusting of current budgets.

金銭の支出を予測しコントロール

する活動。予算業務は、将来の予

算を設定する周期的交渉サイクル

（通常は年次）と、現在の予算に

対する日々の監視と調整で構成さ

れる。

build 構築 (ITIL Service Transition) The activity of assembling a number of configuration items to create part of an IT service. The term is also used to refer to a release that is authorized for distribution – for example, server build or laptop build. See also configuration baseline.


IT サービスの一部を作成するため

に、複数の構成アイテムを組み立

てる活動。配付を許可されたリリ

ースを示す場合は、「ビルド」と

もいう。例えば、「サーバのビル

ド」や「ノート PC のビルド」の

ように使用する。構成ベースライ

ンも参照。

build environment

構築環境 (ITIL Service Transition) A controlled environment where applications, IT services and other builds are assembled prior to being moved into a test or live environment.


アプリケーション、IT サービス、

およびその他の構築の組み立てを

行うコントロールされた環境。こ

の環境の後、テスト環境または稼

働環境に移行する。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

http://www.bsi-global.com/

http://www.bsi-global.com/


business 事業 (ITIL Service Strategy) An overall corporate entity or organization formed of a number of business units. In the context of ITSM, the term includes public sector and not-for-profit organizations, as well as companies. An IT service provider provides IT services to a customer within a business. The IT service provider may be part of the same business as its customer (internal service provider), or part of another business (external service provider).

（ITIL サービスストラテジ）複数

の事業部門から成る、企業体また

は組織の全体。ITSM におけるこの

用語には、企業だけでなく、公共

部門と非営利組織も含まれる。ITサービス・プロバイダは、事業組

織内の顧客に IT サービスを提供す

る。この IT サービス・プロバイダ

は、顧客と同じ事業組織に属して

いる場合（内部サービス・プロバ

イダ）や、別の事業組織に属して

いる場合（外部サービス・プロバ

イダ）がある。

business capacity management

事業キャパシ

ティ管理 (ITIL Continual Service Improvement) (ITIL Service Design) In the context of ITSM, business capacity management is the sub-process of capacity management responsible for understanding future business requirements for use in the capacity plan. See also service capacity management; component capacity management.

（ITIL 継続的サービス改善）（ITILサービスデザイン）ITSM における

事業キャパシティ管理とは、キャ

パシティ計画で使用する将来の事

業要件の把握を責務とするキャパ

シティ管理のサブプロセスであ

る。サービス・キャパシティ管

理、コンポーネント・キャパシテ

ィ管理も参照。

business case ビジネス・ケ

ース (ITIL Service Strategy) Justification for a significant item of expenditure. The business case includes information about costs, benefits, options, issues, risks and possible problems. See also cost benefit analysis.

（ITIL サービスストラテジ）主要

な支出項目の正当性を説明するも

の。ビジネス・ケースは、コス

ト、利点、代案、課題、リスク、

起こりうる問題などに関する情報

を含む。費用便益分析も参照。

business continuity management (BCM)

事業継続性管

理（BCM） (ITIL Service Design) The business process responsible for managing risks that could seriously affect the business. Business continuity management safeguards the interests of key stakeholders, reputation, brand and value-creating activities. The process involves reducing risks to an acceptable level and planning for the recovery of business processes should a disruption to the business occur. Business continuity management sets the objectives, scope and requirements for IT service continuity management.

（ITIL サービスデザイン）事業に

深刻な影響を与える可能性のある

リスクの管理を責務とするビジネ

ス・プロセス。事業継続性管理

は、主要な利害関係者の利益、評

判、ブランド、および価値を創造

する活動を保護する。このプロセ

スには、リスクを受容可能なレベ

ルまで低減することや、事業に中

断が生じた場合にビジネス・プロ

セスを回復するための計画立案を

行うことが含まれる。事業継続性

管理は、IT サービス継続性管理の

達成目標、適用範囲、および要件

を設定する。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


business continuity plan (BCP)

事業継続性計

画（BCP） (ITIL Service Design) A plan defining the steps required to restore business processes following a disruption. The plan also identifies the triggers for invocation, people to be involved, communications etc. IT service continuity plans form a significant part of business continuity plans.

（ITIL サービスデザイン）ビジネ

ス・プロセスの中断後に、そのプ

ロセスを回復するために必要なス

テップを定義した計画。この計画

では、発動のトリガ、関与する

人、コミュニケーションなども特

定する。IT サービス継続性計画

は、事業継続性計画の重要な部分

を占める。

business customer

事業顧客 (ITIL Service Strategy) A recipient of a product or a service from the business. For example, if the business is a car manufacturer, then the business customer is someone who buys a car.

（ITIL サービスストラテジ）事業

からの製品またはサービスの受領

者。例えば、事業が自動車製造業

者の場合、自動車を購入する人が

事業顧客である。

business impact analysis (BIA)

ビジネス・イ

ンパクト分析

（BIA）

(ITIL Service Strategy) Business impact analysis is the activity in business continuity management that identifies vital business functions and their dependencies. These dependencies may include suppliers, people, other business processes, IT services etc. Business impact analysis defines the recovery requirements for IT services. These requirements include recovery time objectives, recovery point objectives and minimum service level targets for each IT service.

（ITIL サービスストラテジ）ビジ

ネス・インパクト分析は、重要事

業機能とそれら機能間の依存性を

識別する、事業継続性管理の活動

である。これらの依存性には、サ

プライヤ、人材、その他のビジネ

ス・プロセス、IT サービスなどが

含まれる場合がある。ビジネス・

インパクト分析によって、IT サー

ビスの復旧要件が定義される。こ

れらの要件には、IT サービスごと

の目標復旧時間、目標復旧時点、

および最小限のサービスレベル目

標値が含まれる。

business objective

事業達成目標 (ITIL Service Strategy) The objective of a business process, or of the business as a whole. Business objectives support the business vision, provide guidance for the IT strategy, and are often supported by IT services.


ネス・プロセスの達成目標。また

は事業全体としての達成目標。事

業達成目標は事業のビジョンを支

援し、IT 戦略の手引きを提供す

る。これらの達成目標は、IT サー

ビスによって支援されることが多

い。

business operations

事業運営 (ITIL Service Strategy) The day-to-day execution, monitoring and management of business processes.


ネス・プロセスを日々実行、モニ

タリング、および管理すること。

business perspective

事業の観点 (ITIL Continual Service Improvement) An understanding of the service provider and IT services from the point of view of the business, and an understanding of the business from the point of view of the service provider.

（ITIL 継続的サービス改善）事業

の視点からサービス・プロバイダ

および IT サービスを理解すること

と、サービス・プロバイダの視点

から事業を理解すること。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint


頭字語集

英語頭辞語日本語頭辞語英語正式名称日本語正式名称

ACD ACD automatic call distribution 自動着信呼分配

AM AM availability management 可用性管理

AMIS AMIS availability management information system 可用性管理情報システム

ASP ASP application service provider アプリケーション・サービス・プロ

バイダ

AST AST agreed service time 合意済みサービス時間

BCM BCM business continuity management 事業継続性管理

BCP BCP business continuity plan 事業継続性計画

BIA BIA business impact analysis ビジネス・インパクト分析

BMP BMP Best Management Practice ベスト・マネジメント・プラクティ

ス

BRM BRM business relationship manager 事業関係マネージャ

BSI BSI British Standards Institution 英国規格協会

CAB CAB change advisory board 変更諮問委員会

CAPEX CAPEX capital expenditure 資本的支出

CCM CCM component capacity management コンポーネント・キャパシティ管理

CFIA CFIA component failure impact analysis コンポーネント障害インパクト分析

CI CI configuration item 構成アイテム

CMDB CMDB configuration management database 構成管理データベース

CMIS CMIS capacity management information system キャパシティ管理情報システム

CMM CMM capability maturity model 能力成熟度モデル

CMMI CMMI Capability Maturity Model Integration 能力成熟度モデル統合

CMS CMS configuration management system 構成管理システム

COBIT COBIT Control OBjectives for Information and related Technology

Control OBjectives for Information and related Technology

COTS COTS commercial off the shelf 既製品



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| ITIL® ライフサイクル全体の管理 | STUDENT | 英語頭辞語日本語頭辞語英語正式名称日本語正式名称

CSF CSF critical success factor 重要成功要因

CSI CSI continual service improvement 継続的サービス改善

CTI CTI computer telephony integration コンピュータ電話統合

DIKW DIKW Data-to-Information-to-Knowledge-to-Wisdom データ・情報・ナレッジ・知恵

DML DML definitive media library 確定版メディア・ライブラリ

ECAB ECAB emergency change advisory board 緊急変更諮問委員会

ELS ELS early life support 初期サポート

eSCM-CL eSCM-CL eSourcing Capability Model for Client Organizations

クライアント組織向け e ソーシング

能力モデル

eSCM-SP eSCM-SP eSourcing Capability Model for Service Providers

サービス・プロバイダ向け e ソーシ

ング能力モデル

FTA FTA fault tree analysis 故障樹解析

IRR IRR internal rate of return 内部利益率

ISG ISG IT steering group IT 運営グループ

ISM ISM information security management 情報セキュリティ管理

ISMS ISMS information security management system

情報セキュリティマネジメントシス

テム

ISO ISO International Organization for Standardization 国際標準化機構

ISP ISP internet service provider インターネット・サービス・プロバ

イダ

IT IT information technology 情報技術

ITSCM ITSCM IT service continuity management IT サービス継続性管理

ITSM ITSM IT service management IT サービスマネジメント

itSMF itSMF IT Service Management Forum IT サービスマネジメントフォーラム

IVR IVR interactive voice response 音声自動応答

KEDB KEDB known error database 既知のエラー・データベース

KPI KPI key performance indicator 重要業績評価指標

LOS LOS line of service サービス・ライン



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| STUDENT | ライフサイクル全体の管理 | ITIL用語および頭字語集 | 英語頭辞語日本語頭辞語英語正式名称日本語正式名称

MIS MIS management information system 管理情報システム

M_o_R M_o_R Management of Risk リスクの管理

MTBF MTBF mean time between failures 平均故障間隔

MTBSI MTBSI mean time between service incidents 平均サービス・インシデント間隔

MTRS MTRS mean time to restore service 平均サービス回復時間

MTTR MTTR mean time to repair 平均修理時間

NPV NPV net present value 正味現在価値

OLA OLA operational level agreement オペレーショナルレベル・アグリー

メント

OPEX OPEX operational expenditure 運用支出

PBA PBA pattern of business activity 事業活動パターン

PDCA PDCA Plan-Do-Check-Act 計画・実施・点検・処置

PFS PFS prerequisite for success 成功の必須条件

PIR PIR post-implementation review 実施後のレビュー

PMBOK PMBOK Project Management Body of Knowledge プロジェクトマネジメント知識体系

PMI PMI Project Management Institute プロジェクトマネジメント協会

PMO PMO project management office プロジェクト管理オフィス

PRINCE2 PRINCE2 PRojects IN Controlled Environments PRojects IN Controlled Environments

PSO PSO projected service outage サービスの停止計画

QA QA quality assurance 品質保証

QMS QMS quality management system 品質マネジメントシステム

RACI RACI responsible, accountable, consulted and informed

実行責任者、説明責任者、協議先、

報告先

RCA RCA root cause analysis 根本原因分析

RFC RFC request for change 変更要求

ROA ROA return on assets 総資産利益率

ROI ROI return on investment 投資利益率



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| ITIL® ライフサイクル全体の管理 | STUDENT | 英語頭辞語日本語頭辞語英語正式名称日本語正式名称

RPO RPO recovery point objective 目標復旧時点

RTO RTO recovery time objective 目標復旧時間

SAC SAC service acceptance criteria サービス受け入れ基準

SACM SACM service asset and configuration management サービス資産管理および構成管理

SAM SAM software asset management ソフトウェア資産管理

SCM SCM service capacity management サービス・キャパシティ管理

SCMIS SCMIS supplier and contract management information system サプライヤ契約管理情報システム

SDP SDP service design package サービスデザイン・パッケージ

SFA SFA service failure analysis サービス障害分析

SIP SIP service improvement plan サービス改善計画

SKMS SKMS service knowledge management system サービス・ナレッジ管理システム

SLA SLA service level agreement サービスレベル・アグリーメント

SLM SLM service level management サービスレベル管理

SLP SLP service level package サービスレベル・パッケージ

SLR SLR service level requirement サービスレベル要件

SMART SMART specific, measurable, achievable, relevant and time-bound

具体的、測定可能、達成可能、適

切、適時

SMIS SMIS security management information system セキュリティ管理情報システム

SMO SMO service maintenance objective サービス・メンテナンス目標

SoC SoC separation of concerns 関心事の分離

SOP SOP standard operating procedure 標準運用手順

SOR SOR statement of requirements 要件記述書

SOX SOX Sarbanes-Oxley (US law) サーベンス・オクスリー法（米国の

法律）

SPI SPI service provider interface サービス・プロバイダ・インタフェ

ース



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| STUDENT | ライフサイクル全体の管理 | ITIL用語および頭字語集 | 英語頭辞語日本語頭辞語英語正式名称日本語正式名称

SPM SPM service portfolio management サービス・ポートフォリオ管理

SPOF SPOF single point of failure 単一障害点

TCO TCO total cost of ownership 総所有コスト

TCU TCU total cost of utilization 総利用コスト

TO TO technical observation 技術監視

TOR TOR terms of reference 委任事項

TQM TQM total quality management 総合的品質管理

UC UC underpinning contract 外部委託契約

UP UP user profile ユーザ・プロファイル

VBF VBF vital business function 重要事業機能

VOI VOI value on investment 投資価値

WIP WIP work in progress 処理中の作業

The Swirl logo™はCabinet Officeの商標です。

ITIL®はCabinet Officeの登録商標です。

PRINCE2®はCabinet Officeの登録商標です。

M_o_R®はCabinet Officeの登録商標です。



Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

| STUDENT | ライフサイクル全体の管理 | ITIL資格体系 |

ITIL®資格体系本文書は、全体的な ITIL の資格体系、2 種類あるインターミディエイトレベルの違い、それぞれのストリームに属する認定資格とそのディプロマ、さらなる上位トレーニングへの様々なパスを説明するものです。本文書の内容は、ITIL 認定資格試験の範囲外となります。

本文書の内容は、2013 年 4 月の時点の最新の情報を掲載しておりますが、もっとも新しい情

報に関しましては、ITIL 公式ウェブサイト (http://www.itil-officialsite.com/home/home.aspx)をご確認ください。

資格体系 ITIL の資格体系は、次の段階で構成されています：ファンデーションレベルインターミディエイトレベルライフサイクル全体の管理レベルアドバンスレベル

ITIL®資格体系の図

+

_

485 Copyright © 2013, ITpreneurs Nederland B.V. All rights reserved.

+

-

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

http://www.itil-officialsite.com/home/home.aspx


ファンデーションレベルでは、ITIL の主要な概念、用語、プロセスの基礎をしっかりとおさえるために、ナレッジの習得と内容の理解に焦点を当てます。

インターミディエイトレベルには「ケイパビリティ・ストリーム」と「ライフサイクル・ストリーム」の 2つのストリームがあります。ライフサイクル・ストリームは、OGC が発行している 5 つのコア書

籍、「サービスストラテジ」、「サービスデザイン」、「サービストランジション」、「サービスオペレ

ーション」、「継続的サービス改善」と同じ構成になっています。ケイパビリティ・ストリームは 4 つのクラスタ(認定資格)から構成されています：

運用サポートと分析(OSA)：イベント管理、インシデント管理、要求実現、問題管理、アクセス管理、(機能)サービスデスク、技術管理、IT 運用管理、アプリケーション管理

計画立案、保護、最適化(PPO)：可用性管理、キャパシティ管理、IT サービス継続

性管理、需要管理、リスク管理、情報セキュリティ管理

リリース、コントロール、および妥当性確認(RCV)：変更管理、リリース管理および

展開管理、サービスの妥当性確認およびテスト、サービス資産管理および構成管

理、ナレッジ管理、要求実現、評価

サービス提供と合意(SOA)：サービス・ポートフォリオ管理、サービスレベル管理、

サービス・カタログ管理、需要管理、サプライヤ管理、財務管理、事業関係管理

どちらのストリームでも、ITIL の概念についての理解度と適用力が評価されます。「ライフサ

イクル全体の管理」コースではサービスマネジメントに対するライフサイクル・アプローチのもっと

も重要な点をすべてまとめたコースです。

ファンデーションレベル、インターミディエイトレベル、ライフサイクル全体の管理コースのレベル

を修了し、必要クレジット数である 22単位を取得すると、「ITIL エキスパート認定」として認めら

れます。エキスパートとなるためには、別に試験や研修を受けなければならないということはあり

ません。

注：こちらの資格体系に関する情報は単なる情報であり、試験範囲には含まれません。また、こ

の資格体系は変更される場合があります。

+

_

486 Copyright © 2013, ITpreneurs Nederland B.V. All rights reserved.

Sampl

e Mat

eria

l - N

ot fo

r Rep

rint

Documents

ITIL Managing Across the Lifecycle Reference Handbook(Japanese)