itil implementation for boise potato firm

はじめに

Implementation of ITIL Framework for Boise Potato Firm

Yuko Soma

（注意）この論文は、42か国に支社を持つBoise Potato社を用いたケーススタディに基づくもので、実在する企業情報を含みません。はじめに1TIL の各ライフサイクルの「事業に対する価値」は以下の通りである。　

（１）サービスストラテジ　 (SS)

サービス・ライフサイクルの中心、または開始地点として、組織の達成目標と顧客のニーズを理解すること、また、財務的観点と技術的観点の両面から、サービスマネジメントの方針、指針、プロセスの策定に役立つ基本原則を提供すること。

（２）サービスデザイン (SD)

事業達成目標を認識し、全体の要件を網羅し、優先度を考慮し、全ての利害関係者と必要なコミュニケーションをとり、的確なサービスマネジメントの設計、開発を行うこと。

（３）サービストランジション (ST)

リスクを含み、複雑性をもつ、サービスの移行段階において、プログラム管理、プロジェクト管理と明確な協力関係を持ち、移行に関するリスクをコントロールし、事業組織全体を、費用対効果高く、確実に、新しい環境に移行すること。

（４）サービスオペレーション (SO)

はじめに

サービスデザインで戦略的に設計されたサービスデザインパッケージを引き継いで移行した、サービストランジションから、運用を引き継ぐことにより、事業全体の活動を、事業の目標にそって、戦略的に、安定的に、支援していくこと。

（５）継続的サービス改善 (CSI)

より良い戦略、設計、移行、運用を目指す。具体的には、サービス品質を改善し、運用の効率化をすすめ、事業の継続性を維持し、事業全体の目標にそった形で、サービス・ライフサイクルを通して、改善活動を計画、実施すること。

各ライフサイクル共通の用語の意味は以下の通りである。「サービス」

サービスとは、顧客に特定の価値を提供することである。それによって、顧客は、直接、失敗のリスクとコストを負う必要がなく、それらをサービス・プロバイダに負わせることができ、自らの目標を達成したり、自らの事業に専念することができるので、業務効率がよくなる。従って、サービス・プロバイダは、リスクやコストを適切にコントロールする能力を持った、専門家であるべきである。サービスの価値は、顧客が決める、顧客が定義するという性質があるため、最終的には、その価格でサービスを受けるかどうかは、顧客が決めることになる。また、価値は変化するので、サービス内容は、常に変化させなければならない。

「サービスマネジメント」戦略、設計、移行、運用、継続的改善の 5 つのライフサイクルを通して、一定品質のサービス供給が続

く確約をし、顧客に価値をもたらすプロセスの一連の活動をサービスマネジメントという。一連の活動とは、人材や能力などのサービス資産をインプットし、4 つの機能（サービスデスク、運用管理、技術管理、アプリケーション管理）を使用して、26 個のプロセス（変更管理、ナレッジ管理など）をコントロール、変換し、顧客に成果をアウトプットすることである。その価値、成果とは、求めているパフォーマンスが実現されること、または、実現のための制約がないことなどの有用性と、十分な可用性、キャパシティ、継続性、セキュリティの全てがある状態の保証の二つが存在することである。

はじめに

「プロセス」プロセスは、特定の目的を達成するための一連の定義をした活動のことである。プロセスは、測定す

るものであり、プロセス・マネージャは、プロセスのコスト、品質を測定したいと考え、プロセス実務者は、期間と生産性の測定をしたいと考えるという違いがある。プロセスの仕組みは、データなどのトリガを受けて、プロセスが一連の活動を行い、その成果をアウトプットとして、顧客、または利害関係者に提供する。その成果

→のデータが、再び、トリガとなり、プロセス成果となることを繰り返し、閉ループとなる。これは、パフォーマンス駆動型と呼ばれ、閉ループする度に内容が適切に変化していく。つまり、プロセスは、継続性、反復性、改善性がある。また、プロセスは、特定の結果が必ずあるため、完了した数を数えられる。それに対して、機能は、完了した数を数えられないという性質がある。

「機能」機能は、サービス資産（つちかったナレッジ、人材、使用するツール）を使用して、プロセスを実施す

る。機能は、組織の構成単位であり、あるプロセスの実施に専念する一連の活動を行い、特定の成果を出すことに責任を負っている。つまり、機能は、パフォーマンスを発揮する、専門的な集団でなければならない。機能には、RACI(Responsible=実行責任者：一名, Accountable=説明責任者, Consulted=相談先, Informed=報告先)と呼ばれる、責任と役割が与えられている。適切なプロセスがあれば、機能の生産性が改善される。

第 1 　章 SOAについて

SOA(Service Offering and Agreement)「サービス提案と合意」について、以下の通りまとめた。


価値創出と有用性および保証　　 IT サービスは、その成果を定性化できても、金銭的なものに換算（定量化）するのが困難である。IT サービスの価値創造の定量化を試みるのであれば、顧客はどのように価値を認識するかを、「参照値(顧客自らできていること) + サービス利用による顧客の利益 - 　サービス利用による損失 =　サービスの経済的価値」、「サービスの経済的価値 – 参照値 =　サービスの差」でみることができる。このサービスの差は、サービスプロバイダが提供できる、（最終的な）有益な「有用性と保証」となる。（ただし、これらは全て、顧客側の認識と好みと顧客側が算出した事業成果がベースになっていることに注意しなければならない。）　　この、サービスの価値を決める有用性とは、パフォーマンスがサポートされているか、制約が排除されているかなどの、目的への適合性（機能性）のことである。保証とは、可用性は十分か、キャパシティは十分か、継続性は十分か、セキュリティは十分かという、使用への適合性（管理性）のことである。　　アプリケーションの開発など、有用性を確認する設計のフェーズは、単独で実行されてはならず、保証を確認する運用フェーズが関与すると価値が高くなる。設計フェーズが終了してから、運用フェーズにはいると、手戻りの追加コストが発生する場合があり、価値が低くなってしまう。また、有用性と保証の高低は、バランスがとれると複合効果が生まれ、価値を創出する。

サービス・カタログ・マネージャとサービスレベル・マネージャの立場

① 組織の駆け引きや自己利益のためではなく、達成目標の全体的な実現を目指す戦略をつくる。② チームカルチャの養成、メンタリング、コーチングをする。③ 投資が組織の意図する発展と成長に見合うようにする。④ 事業へのインパクトが最大となる領域を考え、投資の優先度付けをする。⑤ 分析結果に基づき、意思決定する。⑥ 戦略、方針、規則、契約を、評価、方向付け、モニタリングする。⑦ 妥当性が確認された事業にのみ、投資、支出することにより、コスト削減し、ROI を最大化する。⑧ 主要プロジェクトやサービス改善に対する投資レベルを引き上げる。


⑨ 上級マネジメントから指示を受け、報告をする。⑩ 顧客のニーズを知り、支援する。⑪ 他のマネージャを巻き込み、支援する。

サービスデザインが抱えるリスクや課題　課題：マネージャは、次の課題を解決するよう、努めなければならない。

設計されていないサービスやプロセスは、無秩序に発展していくこと。適切なコントロールなしに発展する場合、全体的なビジョン、および、ビジネス・ニーズを明確に理解することなく、発生した環境条件に、リアクティブに反応するだけのものになる。サービスデザインに対する、反復的、および斬新的なアプローチが必要である。

　リスク：サービスデザインがない場合、極めてコスト高になり、費用対効果がうすい。また、サービスオペレーション段階等で、障害が発生しやすくなる。リソースは、無駄に消費され、ビジネス・ニーズに整合されなくなる。どのような改善計画をもっても、達成できたはずの事業目標は達成されない。

「マネージャの立場」に則った行動

a. マネージャの立場に則った行動① 事業目標、事業利益、投資の優先順位を常に念頭において、行動する。② 上（上級マネジメント）、横（顧客と他の IT マネージャ）、下（部下、プロセス、技術、ツール）のコント

ロールに同じくらいの比重を置く。③ サービスマネジメントとは何かを第一に考える。

b. そうでない行動① 自己利益や保身のために、社内政治活動にはげむ。


② 部下の仕事を細かく監視したり、手伝ったりしてしまい、部下のモチベーションを下げる。③ 事業目標を考えず、目先のプロジェクトをこなす。


ポートフォリオ管理

ポートフォリオついてポートフォリオとは、投資ポートフォリオと同じで、顧客のリスクと収益の特性に基づいて調整され

るべきで、受容可能なリスク・レベルで利益を最大化する。従って、条件が変われば、変更が反映され、ポートフォリオは、更新されるべきである。

IT サービスのポートフォリオには、サービス・ポートフォリオ、アプリケーション・ポートフォリオ、顧客ポートフォリオ、顧客合意ポートフォリオ、プロジェクト・ポートフォリオがあるが、ポートフォリオ管理の管轄内である、サービス・ポートフォリオについてのみ、以下に説明する。

これは、事業上の価値の観点から、プロバイダが提供する、稼働中、または展開許可済みサービス(=サービス・カタログ)、準備中または開発中のサービス（=パイプライン）、廃止済みのサービスを説明して、文書化したものである。これは、様々なプロバイダの競争力を比較する手段となる。作成の目的は、ITへの投資と事業成果を実現する能力とのバランスを取るために、適切なサービスを準備するようにすることである。ポートフォリオの事業に与える価値は、事業が IT サービス投資について、健全な意思決定ができるようになることである。

サービス・ポートフォリオが明確にする戦略的な問い戦略的な問いとは、次の事項である。「サービス・プロバイダの長期的な最終目標は何か？それを達成するには、どのようなサービスが必要か？組織がそれらのサービスを実現するには、どのような能力とリソース（リソース資産）が必要か？どのようにして、目標を達成するのか？」これらの質問に満足いくように答えられるには、上級リーダと、上級アーキテクトなどの対象分野の専門家の参画が必要になる。このグループは、サービス・アーキテクチャ委員会（SAB）と呼ばれ、前述の戦略的な問いに明確に答えるのを支援し、また、各サービスの分析を行なうことにより、サービス・ポートフォリオが明確に、戦略的に、事業に価値をもたらすことになる。


サービス・ポートフォリオ管理プロセスの活動1. 　活動の開始：戦略管理、事業関係管理、継続的サービス改善、その他のサービス・プロセス・マネジメント・プロセスがトリガとなる。ここでは例として、継続的サービス改善を扱う。CSI は、サービス・ポートフォリオ管理に対して、パフォーマンスやサービスレベル達成度を改善する機会、新しい機会や現行のサービス・ポートフォリオ内にあるギャップ、全体的な改善の機会の 3 つをインプットとする。2. 定義する: 求められる事業成果、機会、有用性と保証の要件、およびサービスそのものを定義するとともに、これらを達成するための予測される投資を定義することである。

カタログ管理カタログ管理の目標事業顧客に対して、どのようなサービスを提供しているのか、どのようなサービスが承認され、今後、提供を受けられるのか、どのサービスが無くなったのか、どのサービスが足りないのかを明確に示す事によって、顧客がサービスを受けやすくなったり、今後、受けたいサービスがわかったりして、事業が発展する。また、顧客が、サービスについて適切な価格で提供されているかについて検討できるようになる。そのカタログは常に最新の状態であることが前提となる。

サービス・カタログの内容についてサービス・カタログには、2種類あり、両方ともサービス・ポートフォリオの中に含まれる。

a) 技術サービス・カタログであり、事業側には公開されない、サポートスタッフのためのカタログ内容は、サービス、ハードウェア、ソフトウェア、ネットワーク、アプリケーション、データ、サプライヤなどである。現在提供されているサービス、承認済みだがまだ提供されていないサービスの 2種類が記載される。

b) 事業サービス・カタログ顧客に供給することを約束しているあらゆるサービス情報を一元的に管理し、許可された全ての関係者にその情報を供給する。内容は、サービス、サポートされている製品方針、順序づけや要求手順、サポート条件、エントリ・ポイントとエスカレーション、価格設定と課金方法である。ユーザグループによって、違うビューを使用して、異なるカタログを見せることも可能である。


サービスレベル管理サービスレベル管理の目標SLM の目的は、現在のサービス、および準備中のサービスが、合意された達成可能な目標値を満たすようにすることである。それを達成するためには、次の目標を掲げる。IT サービスレベルを定義、文書化、合意、モニタリング、測定、報告、レビューし、適宜、改善措置をとる。事業関係管理と協力して、事業および顧客との関係を円滑に維持し、適宜、改善していく。IT サービスを測定可能な目標値で、設定できるようにする。サービス品質に対しての顧客満足度をモニタリングし、適宜、改善する。合意されたレベルで品質が維持されていたとしても、常に対費用効果が高く、常に継続的改善の対象となるようにする。

ＳＬＡおよびＯＬＡSLA 　： IT サービス・プロバイダと事業顧客の間で交わされる合意文書であり、各サービスの目標値と、両者の責任を定義している。これは、違反したら賠償金を払うためのものではなく、両者の合意に重点がおかれている。SLA は、サービスが提供するべき有用性とその保証を定義する。SLA は、サービスレベル管理(SLM)によって、立案計画、調整、起草、合意、モニタリング、報告される。OLA: IT サービス・プロバイダと、それを支援する同じ組織の別部門（購買、施設管理など）との間で交わされる合意文書であり、OLA は、支援サービス活動が SLA違反を引き起こさないように、SLA 内の目標値を支える目標値を定める。

ＳＬＡの種類a) サービスベースの SLA 　：メール・サービスなどの全従業員が使用する単一のサービスの SLA を規定し、そのサービスのすべてのユーザを対象とする。しかしながら、メール・サービスといっても、従業員によっては、自宅から使用したり、別拠点から VPN 接続で使用していたり、本社の社内 LAN からアクセスしたりなど、条件が異なるのに、同じSLA でよいかという問題と、どの使用方法による代表者が合意書への署名者となるかという問題がある。サービスレベルの有効性を高めるために、複数のサービス階級を使用することも検討される。


b) 顧客ベースの SLA 　：財務システム、給与システム、請求システム、メールシステムなど、１つの部門で使用されるすべてのサービスに対して、単一の SLA を規定する。顧客側は、１つの文書で要件が満たされるため、好まれることが多い。署名者は一名ですむため、明快である。c) マルチレベル SLA 　：例えば次のような階層構造となることがあるがこの限りではない。特定サービスレベルの SLA、顧客レベルの SLA または事業部門レベルの SLA、企業レベルの SLA の組み合わせである。詳細は、上記 a)、b)と同様である。階層の複合SLA とすることにより、SLA を扱いやすいサイズに維持できるようになり、不必要な重複が回避され、頻繁な更新の必要性が少なくなるという利点がある。リスクとしては、サービス・カタログと CMS 内での、必要な関連を維持するために、さらなる労力を要することである。

サービスレベル管理の活動について主な活動は次の通りである。1) SLR にある新規または変更されるサービス要件の判断、交渉、文書化、合意、およびサービス・ライフサイクルを通した、これらの要件の管理、およびレビューと運用中のサービスを SLA に落とし込むこと。2)サービス・パフォーマンスの SLA 達成度のモニタリングと測定。3) サービス・レポートの作成、4) サービス・レビューを行い、CSI 管理表に、改善の機会を含め、SIP を適切に管理する。5) 事業関係管理との協力による、顧客満足度の測定と、結果に応じた改善。6) SLA,サービス適用範囲、OLA のレビューと改訂、7) 事業関係管理プロセスとの協力による、苦情と賛辞の記録と管理など。

サービスレベル管理の活動の実態　　　ステップ 1 - 可用性管理が、現在の Blackberry サーバの可用性とキャパシティを測定し、ベースラ

インとした。その結果に基づいて作成された SLA を、事業顧客管理を含めて、事業顧客と話し合い、サービスレベル管理が、Blackberry メール・サービスに対して、サービスベースの SLA を、可用性 24時間　365日稼働、障害時や保守によるダウンタイム一回に 2時間以内、ダウンは、発生しても、4ヶ月に一回以下、Blackberry でのメール送受信開始までの時間(応答性)が 3秒以内で、それを下回る期間が、1時間以内であることなど、エンドツーエンドでのパフォーマンスについて取り決め、顧客と合意した（99.8%など、顧客がわからないような表現を使わない）。また、その SLA を達成するために、そのサービスを支援する、NTTドコモや、1RIM社などのサプライヤとも別途、SLA に合意し、法的拘束力のある外部委託契約にサインした。社内の調達部門とは、Blackberry入手をユーザがリクエストしてから、14日以内に IT に届けるという OLA に合意した。

1 Blackberry端末と、Blackberry Enterprise Server を開発している、カナダのリサーチ・イン・モーション社の略称。2014年現在は、社名をブランド名と同じ、Blackberry としている。2013年 2月に、日本市場からの撤退を発表した。


　　　ステップ 2 – サービス・パフォーマンスの SLA 達成度のモニタリングと測定。　　　ステップ 3 – RAGチャートを含んだサービス・レポートの作成。　　　ステップ 4 - サービス・レビューを実施し、セキュリティの脆弱性が可用性に与えるインパクトを考慮

して、Blackberry OS のバージョンアップの検討などを SIP に追加した。　　　ステップ 5 – ケース・クローズがトリガーとなる、インシデント管理ツールの自動応答サーベイ送信

（10 段階評価で、満足度をマークするようになっており、忌憚のない意見を記載できる、自由形式の欄もある。）を通じて、Blackberry に関するインシデントのユーザ満足度を調査した。　　　　


需要管理需要管理とは12月には、年賀カードがよく売れる、経理部スタッフは、毎月月末は非常に忙しいなどという、事業顧客の事業活動パターンやユーザ・プロファイルを把握、予測、分析し、サービス資産のキャパシティやパフォーマンスが過不足なく提供されることを、キャパシティ管理と共にコントロールしていくプロセスである。需要管理に固有なプロセスとしては、事業の繁忙期を拡散させて、特定のサーバへのアクセス量をコントロールするような、奨励、罰則などの戦略によって、需要に影響を与えることと、事業目標数値達成と IT投資の両方のバランスをとる方策をさぐることである。

需要管理と一番密接な関係にあるプロセスキャパシティ管理プロセスである。どちらも、事業成果実現と IT投資の最適化を目標とするが、次の点で異なる。需要管理は、ややビジネスとユーザ寄りのプロセスであり、事業顧客が、自らの顧客に対し、格差課金をもうけ、繁忙期を拡散するなどして、製品需要の調整を図るのを受けて、IT サービスの需要を予測して、戦略を立てる。一方、キャパシティ管理は、IT サービスと技術寄りのプロセスであり、需要管理から受けた需要情報により、サービス資産のキャパシティやパフォーマンスが過不足のないように管理する。このように、キャパシティ管理の仕事は、需要管理から引き継がれていること、また、需要があるから、キャパシティが必要になることからも、これらのプロセスは密接な関係にあると言える。

コアサービスと支援サービスコアサービスとは、例えば、メールの送受信ができるなど、顧客にとっての基本的なサービスである。それに対して、支援サービスとは、顧客の要望に合わせて、ドミノサーバであったり、Exchange サーバであったり、Office 365 であったりと選べて、更に、メールの送受信が、24時間 365日可能であることを保証するなど、顧客にとっての付加価値を提供する、魅力サービスである。これらの組み合わせは、サービス・パッケージとして顧客に提示され、サービス・プロバイダは、これをサービス・ポートフォリオ管理に組み入れ、購入/導入を検討する。同時に、このコアサービスと支援サービスの組み合わせで、顧客の事業活動パターンとユーザ・プロファイルに適合するか、需要管理にて検討することになる。


需要をコントロールする方法需要管理が、事業活動パターンとユーザ・プロファイルを分析することによって、どのユーザが、どのサービスを、どの時期（どの時間帯）に、どのくらい必要とするのかを事前に知る。それによって、ユーザが、期限までに入力しないと経費の振込が来月に繰り越されるなどの罰則をもうけて経費精算システムの使用を平準化させてコントロールすることがある。また、キャパシティ管理が、事業環境の変化を把握し、新しい技術やサービス要件をサービス・ポートフォリオに反映し、リソース予測を正確にすることで、需要に対応することも、需要をコントロールする方法といえる。

提供しているサービスの「事業活動パターン」Altirisツール・サービスの事業活動パターン

Altiris は、ITIL フレームワークを強力にサポートする ITSMツールである。使用対象者は、事業顧客の全ユユーザ、5000名であり、IT スタッフのみではなく、入退社の管理上、人事部も利用頻度が高い。インシデント管理、問題管理、要求実現、アクセス管理その他に使用される。

要求実現は、イントラネットから、買い物かご方式で、必要なサービスをサービス・カタログから、ユーザ自ら選択でき、自動でチケット起票される。

インシデントについては、ユーザがチケットを起票する。サービスデスクは、フォロー・ザ・サンなので、Altiris は、24時間月〜金、使用されており、トランザクションの多い時間帯は、24h、常に、である。

時期的には、毎月月末と、四半期の終わりと、会計年度末である。それぞれのタイムゾーンごと(APAC, EMEA, US の日中)に、ユーザが 1500 人ずつなので負荷分散措置はとっていないが、今後、APAC,

EMEA, US の従業員数のバランスが、崩れることがないよう、需要管理し、格差課金が設けられなければ、キャパシティ管理が調整する必要がある。

第 2 　章 PPOについて

サプライヤ管理サプライヤとは

サプライヤには、上位から、戦略的サプライヤ、戦術的サプライヤ、運用上のサプライヤ、コモディティ・サプライヤの 4 つに分類される。サプライヤというと、サービス・プロバイダに従属的に仕事をするというイメージがある。

戦略的サプライヤは、パートナーとして、サービス・プロバイダやその事業顧客と対等に、そして長期的にコミットメントを交わし、戦略の機密情報を共有し、連帯責任を負い、共有のリスク、および報酬を得ることがあるので、サービス・プロバイダの上級マネジメントのレベルで管理される。例)アジア規模で、統一されたネットワーク構築サービスと運用管理を任せるなど。戦術的サプライヤは、商業活動および事業とのやり取りが関与する関係にあり、進行中の改善プログラムを含む定期的な連絡とパフォーマンス・レビューを伴い、中級マネジメントによって管理される。例）サーバのハードウェア故障の解決を提供する保守組織）。

運用上のサプライヤは、運用上の製品または、サービスを提供し、頻繁ではない定期的な連絡とパフォーマンス・レビューを伴い、下級マネジメントによって管理される。例）ホスティング・サービスのプロバイダなど。

コモディティ・サプライヤは、比較的用意に代替ソーシングされる、価値の低い、用意に入手できる製品とサービスを提供する。例）プリンタ・カートリッジの提供。

1 つの事柄に対して、複数のサプライヤを使用すると、管理が煩雑になるが、リスクが分散される。単一のサプライヤを使用すると、管理は楽になるが、その分、依存していることによるリスク、コストが大きくなる。特に、サービスをサプライヤがカスタマイズしていると、代替サプライヤに移行することは更に困難になることに注意する。

サプライヤ管理の達成目標事業顧客または、サービス・プロバイダが投資した価値に見合う成果を取得すること、契約内容が、事業顧客のニーズに整合するように管理すること、サービスレベル管理プロセスと連携して、SLA と SLA の合意済み目標値を決めること、サプライヤとの関係を完全に管理すること、サプライヤのパフォーマンスをレビューし、管理すること、契約について、サプライヤと交渉、および合意し、そのライフサイクルを通して管理すること、


サプライヤの方針と、それを支えるサプライヤおよび契約管理情報システム (SCMIS)を維持管理することを達成目標とする。

サプライヤ契約データベースとはサプライヤおよび契約管理情報システム(SCMIS)は、サービス・プロバイダの、すべてのサプライヤに対する方針が、一貫性と有効性を持つようにする目的で作成される。SCMIS には、各サプライヤが提供するサービス、または製品の種類の詳細、および他の関連する CI情報、契約の内容を記録し、CMS または SKMS に統合されなければならない。これは、サービス・ポートフォリオとサービス・カタログも形成する。SCMIS の中の以下の情報は、サプライヤ管理の手順と活動に、参考情報一式を提供する。①新しいサプライヤ、および契約の要件の定義、②新しいサプライヤ、および契約の評価と設定、③サプライヤのカテゴリ化と SCMIS の維持管理、④新しいサプライヤの確立、⑤サプライヤとそのパフォーマンス、および関連する契約の管理、⑥契約の更新または終了。

サプライヤ管理における課題、重要成功要因、リスク課題：サプライヤ管理プロセス・マネージャは、次のことを課題として、解決に努めなければならない。常に変化するビジネス・ニーズと IT ニーズによる変更管理。不十分な目標値、パフォーマンスの測定定義をもたない契約により業務を行なうこと。組織内に十分な専門知識がないこと。改善の可能性がないにもかかわらず、早期終了に対する懲罰的な違約金のある、長期契約よる束縛（＝コスト増）。料金に関する争議。日常的な火消し作業に追われ、プロアクティブなアプローチがなされないこと。戦略的観点を失い、運用上の課題にのみ焦点を当てることにより、目標を達成できていない、課題を解決できていないこと。

CSF: サプライヤが、十分なパフォーマンスを発揮しており、ビジネス・ニーズおよび事業目標値と整合する支援サービスをもっており、十分な可用性を提供しており、プロバイダが、サプライヤ契約について明確なオーナシップがとっていること。

　リスク：事業と上級マネジメントから、サプライヤ管理のプロセスへのコミットメントが不足していること。事業と IT の将来的な方針、計画、戦略に関する情報が不足していること。リソースや予算が不足していること。


ビジネス・ニーズ、SLA, SLR の目標値を裏付けない古い契約。サプライヤの引き継ぎがあり、関係、リソース、契約が変更されること。

財務管理財務管理を行うメリット

まず、財務管理プロセスには、次の 3 つの業務がある。予算と実際の出費との不一致、収入を監視する。=

会計業務。予算を作成し、管理する。= 予算業務。支払いに対して請求をする。= 課金業務。　　財務管理を行なうメリットは、規制機関(エンロン事件をきっかけに出来た SOX法、US-GAAP などの会計作成と報告)の定めに従って、適切なデータに基づいて、法令に遵守し、罰則を回避した、健全な事業の意思決定ができるようになる。また、事業を継続するか撤退するかを、サービスとコストの関係を明らかにする、サービス・ポートフォリオを元にして、財務上の裏付けをもって判断できる。また、財務管理は、需要と供給の関係を考えて、課金システムを立案し、コストを最適化し、妥当な投資を、IT サービスマネジメントに対して行なうことができる。

「サービス査定」についてサービス査定は、次の 2 つのことである。a) 供給価値 – IT サービスを提供するのに必要な、有形無形のものの原価。例）ハードウェア、ソフトウェアライセンス、年間保守料、人件費、設備費、コンプライアンスのコストb) サービスの潜在的価値 – IT サービスの提供によって、事業に付加された分の価値であるが、事業顧客が実感する価値なので、実際の値段はない。例）2「サービスに対する価値認識（有用性と保証） = 　　顧客自身の資産 + 　サービスの潜在価値」

投資利益率（ROI）とはROI(Return On Investment)は、IT サービスから得られた、事業顧客の利益の増加（=投資の正味利益）を、事業顧客が支払った IT サービスへの投資合計で割り、100%を乗じたものである。この結果は、その企業の IT

サービスが、プロフィットセンターと見なされるか、コストセンターと見なされるかにより、財務諸表の収益2


に追加されるか、コストから控除される。ROI は、IT サービス投資の価値を定量化するための概念であるが、IT サービスの提供には多くの無形の要素が関与しているため、この計算式は、単純化されすぎており、潜在的な利益（顧客ロイヤルティの向上など定性的なもの）を完全には示していない。

第 2章　PPOについてPPO（Planning, Protection & Operation)「計画立案、保護、および最適化」について、以下の通りまとめた。

サービスマネジメントとして優れている部分と劣っている部分

（１）優れているサービスマネジメント- 　 Altirisツールを使用し、全ての情報が一括管理されている。

　　 - 　役割と機能が ITIL 通りである。- 　サービスデスク機能が充実している（スキルと時間）。日本の祝日も含み、月曜日 9:00 AM JST から土曜日 8:00AM JST（=金曜日 17:00 PST）

　　 - インフラサポートは、24時間 365 日障害対応可能。- 情報セキュリティ方針委員会が機能している。- 2011年の東日本大震災時には、適切な BCP により、問題がなかった。- マネジメントの柔軟性とリスク回避のバランスが良い。例えば、米国本社主導型のトップダウンであるが、日本の事業関係管理は、現場の IT部門に権限委譲されており、日本だけは「欧米とも、アジアとも異なる、希有な文化圏」として、日本のボードメンバー全員の強い要請があれば、ごく稀に例外が認められることがある（米国本社マネージャの承認は事前に必要）。


劣っているサービスマネジメント- 内部サービス・プロバイダゆえ、障害が起きても、事業顧客は我慢してくれるという意識がなくもない。- 需要管理プロセスの課金モデルアセスメントがない。- 米国本社主導型なので、日本人ユーザの顧客満足度が低い。例）a. 英語でのサポート依頼、英語 OS、英語アプリの強制的使用、b. 購入申請しても、ルーティングが米国本社まで通る必要があり、承認者の人数が多いので、なかなか購入物が来ない、c. 車社会ではないのに、米国本社指定の重い Laptop PC を使わされている等。ただ、APAC諸国では、そのような不満のサーベイ結果はないので、日本人特有と思われる。事実、日本支社の外国人社員、海外勤務経験のある日本人からは不満はない。日本以外に多い、プロセス重視型の人材を育成し、ユーザ側からの歩み寄りを求める。（ただし、この部分は、ITIL の管轄外）

　　


サービスデザインを適切に実施することのメリットサービスデザインを適切に実施することのメリットは、サービスライフサイクルにおいて、必要となる改善が最小限になることである。この改善は、時の経過とともに、事業の方向性が変わったり、事業とは関係なく、国内のインフラ技術が進化したりするので、必ず必要となるが、スムーズに終わらせるようにしなければならない。この実施については、サービス・トラジション、及びサービス・オペレーションへの影響も考慮して、サービスデザインパッケージをしっかり準備しておくべきである。特に、Office 3653 や、サイボーズのビジネスクラウド4 などの大規模クラウド技術を使用する顧客にとっては、大きな投資になるので、導入前に費用対効果を確認できるというメリットがある。また、この適切な実施は、ITガバナンスにもつながる。

更に優れた取り組みをすることが可能なＰＰＯに含まれるプロセスと、考えられる効果

上記事業顧客における、情報セキュリティ管理プロセスは、導入段階において、サービスデザインパッケージ(SDP)に適切に組み込まれ、サービストランジションに渡され、サービス・オペレーションが適切に対応したことにより、AD /Exchange サーバ/ファイルサーバ移行プロジェクト時に、障害があったものの、ユーザにとって、最小限の被害ですみ、予定通りにプロジェクトが終了した。

　障害内容：休日の Exchange サーバ移行時に、ディストリビューションリスト(DL)の一部のデータが失われた。また、ファイルサーバ移行時に、フォルダセキュリティ設定の一部の設定が失われた。

IT の行動: 顧客側の各部門長に、障害情報を速やかに通知し、顧客サービスカタログに記載されているように、手順に従って作業し、ヘルプが必要な場合は、サービスデスクに電話するよう依頼し、速やかに、当プロジェクトの他の作業を続行し、翌朝の業務開始時刻までに、全移行作業を終了させた。

3 Office 365 のテクニカルサポートは、24時間 365日対応可能であり、可用性は 99.9%を保証し、満たされていない顧客には同社規定に基づいた額の返金が行なわれる。(2014年４月 27日現在)

4 サイボーズ社が開発した、メールとイントラネット（ファイルサーバ機能あり）サービス。ユーザ数によって月額課金されるので、ユーザ数の増減による損失がない。(2014年４月 27日現在)


顧客の行動：月曜日の朝、出社した DL オーナである部門長が、DL紙リストを元に、DL リストに正しいメンバの追加を行なった。同様に、各部門フォルダ・オーナである部門長が、アクセス権紙リストを元に、部門フォルダ配下にある、全フォルダに、正しいメンバのアクセス権の追加を行った。結果、全ユーザが、 9:15AM には、CIA の保たれた状態で、グループメールを受領する事ができ、また、アクセスすべきフォルダにアクセスすることができ、通常業務に戻れた。

サービスカタログへの記載: a) DL は、部門長から依頼により、IT が作成する。ただし、DLへのメンバの追加、削除は、部門長自身が行い、管理すること。b) ファイルサーバの部門フォルダは、IT しか作成してはいけない。ただし、部門フォルダ配下のフォルダの作成、アクセス権付与については、部門長が作成、更新、管理する。注意:

ファイルサーバ管理者は、全てのフォルダに対して、フルアクセス権を持つが、サポート目的以外では、アクセスしない。

適切な SDP 　がなかった場合：誰がアクセス権を元に戻す責任があるのかわからない、アクセス権の付与手順がわからない、元のアクセス権がどうだったかわからない等のことから、IT とユーザ側でもめるだけで、業務が滞り、IT サービス業務も滞り、ビジネスチャンスを失いかねなかった。

改善点: 障害時刻から、月曜日の朝までに DL宛に送付されたメールは、届かなかった。休日に、VPN経由で、ファイルサーバを使用しようとしていたユーザは、月曜日の朝まで、目的のフォルダにアクセスできなかった。休日でも、ECAB を招集して、各部門長の緊急対応を義務づけることに合意させたほうがいいかもしれない。IT

がこれらのアクセスコントロールをすることは、リソースの都合上と機密文書セキュリティの観点から、関与しないことになっているが、部門長が何らかの事情で対応できなかった場合は、IT が、各部門長のバックアップ要員になるべきかもしれない。IT側で、ベースライン設定し、切り戻し方法を取るべきだったかもしれない。これらの点は、情報セキュリティ管理マネージャが CSI 管理表に記載し、可用性管理マネージャと共に改善にあたれば、更に優れた PPO を実現し、可用性を高める効果がある次の各マネージャの「責任」

　　　　下記 4 つのプロセス・マネージャは、それぞれのプロセスが密接に関連しているため、相互に連携し、IT 財務サービス管理の理解を得て、事業顧客からの適切な投資を正当化する材料を用意する責任が


ある。下記 4 つのプロセス・マネージャに共通する事項は、a) プロセスの運用管理に責任を持ち、役割に人材を任命し、リソースを管理すること、c) 必要な投資、管理手順については、そのプロセス・オーナとともに計画立案化すること、d) パフォーマンスをモニタリングし、プロセス・オーナに報告すること、e) CSI 管理表を作成、更新すること、f) 合意された SLA を遵守するよう監視すること、g) 必要な CAB

ミーティングに参加すること、h) 前述したこと全てを最新の状態の文書にすることである。　　　　 CIOへの説明責任、KPI の分析については、そのプロセス・オーナの責任なので責任範疇外とする。

ただし、マネージャが、そのプロセス・オーナを兼任する場合はこの限りではない。また、プロセス・マネージャは拠点ごとなどに複数設置することがあるので、お互いに連携を取り合うこと。

　　　　それぞれのマネージャ特有の責任については、下記の通りである。

　（１）可用性マネージャ - 内部サプライヤ、外部サプライヤが提供する、コンポーネントの信頼性、保守性、サービス性の要件の特定に責任を負う。関連するインシデント、問題管理を支援する。リスク・アセスメントとリスク管理を行なう。

（２）ＩＴＳＣＭマネージャ – ビジネス・インパクト分析、リスク・アセスメントとリスク管理を行なう。災害が発生した場合、サービス継続性計画を発動して、復旧を指揮する。そのテスト、事後レビュー、是正措置を指揮する。復旧サービス・プロバイダとの契約管理をする。SLA は、顧客というよりは、事業と締結する。

（３）キャパシティ・マネージャ - キャパシティと需要の関係を調整することについて責任を負う。過去、現在、将来のコンポーネントの使用率、最大キャパシティ、パフォーマンスのしきい値、チューニング方法を分析する。関連するインシデント、問題管理を支援する。

（４）セキュリティ・マネージャ – ITSCM マネージャがビジネス・インパクト分析をするのを支援する。関連するインシデント、問題管理を支援する。セキュリティ・リスク・アセスメントとリスク管理を遂行する。自社のセキュリティ方針について、顧客とユーザに普及させる。

可用性に関する「課題、CSF、リスク」


　（１）課題：サービス・チケッティング・システムの ServiceNow5が、業務時間内に、一週間に 2回、5時間程度ダウンするか、応答速度が極端に遅くなる。SLA 　では、月〜金（日本の祝日を除く） 9:30 - 17:30 の間、99.99%の可用性で稼働していること、また、ダウンした場合は Severity2 とされ、インシデントチケットが報告されてから、３時間以内に復旧することとなっており、新規導入してから一年近く、SLA違反状態である。ServiceNow サーバは米国にあり、技術管理、アプリケーション管理も米国にある。

[現状]

可用性(%) = 合意済みサービス時間　　(　　時間　　) – 　　停止時間　　 x 100 = ( 480h /1920h ) x 100 = 25%

　　　　　　 AST

SLA を下げる方向で、事業顧客と合意をとる必要があるが、このアプリケーションは、IT 内でのみで使用されるので、顧客にとっては VBF でなく、顧客には間接的な影響しかないことから、話し合いが先延ばしにされている。しかしながら、実際は、ユーザからインシデントの報告を受けても、サービスデスクがチケットを起票できない、技術管理が更新した、既知のエラーのワークアラウンドを、サービスデスクが閲覧出来ないことから、ユーザに対するサービス対応が大幅遅れており、事業顧客のビジネスにインパクトが大きい。また、サービス・プロバイダの仕事効率は著しく低下しているが、インパクトが測定されていない。このように、事業顧客に、ServiceNow の高可用性の必要性が認識されていないことにより、適切な投資、改善活動が行なわれない。AMIS に情報は統合されているが、AMIS が、ServiceNow の中にあるので、それを活用することができない。

（２）CSF　

- SLA上で、ServiceNow の可用性は、98.12%、信頼性(MTBSI)は、160時間（1年に 12回のダウン）、保守性(MTRS)は、3時間（1年に 12回のダウンで、総停止時間は 36時間）とし、可用性と信頼性が管理されている。- ServiceNow の利用に対するビジネス・ニーズの充足。

5 米国サンディエゴ本社の ServiceNow社が開発した、ITSMソフトウェア。インシデント管理、問題管理、FAQ の管理が出来る。Altiris と違い、ユーザがチケットを起票するインターフェイスはないが、イントラネットと連動させ、ユーザからの要求実現リクエスト入力を自動起票させることが可能。


- 最適なコストで提供されている。

（３）リスク- ServiceNow は、IT 内でしか使用しない ITSMツールではあるが、事業顧客の事業継続性に欠く事ができないものであり、IT トラブルが発生した個々のユーザ、全体のトラブルの発生時には、ServiceNow の可用性が低いことによって、間接的に、事業顧客の全ユーザ、及び、直接的に、サービス・プロバイダの全ユーザが影響を受けていることを、上級マネージャが、経営層に説明できていないこと。- 上記の理由により、このシステムの可用性プロセスへのリソースと予算が不足していること。

　　 - 7 つのグループ会社に個別に報告しなければならないことから、報告プロセスに労力を要すること。　　


キャパシティ管理キャパシティ管理の「目標」キャパシティとパフォーマンスに関連する全てのサービスが、事業顧客と合意されたレベルで達成されていることを目標とする。キャパシティへの期待値は常に変化していき、新しい技術も出てくるので、定期的に計測し、新技術には、常に敏感になり、将来のニーズを予測し、適切な予算投資をしていくよう、事業顧客の理解を求めていくことが大事である。サービスデスク機能などの人的リソース、人員配置とスキルレベル、加えて、ネットワーク帯域幅、CPU の性能などのコンポーネントレベルのリソースも、キャパシティ管理の範疇である。高い費用対効果をもって、最適なスケジュールで管理されなければならない。

キャパシティ管理の３つのレベル3 つのレベルとは、以下の 3 つのサブプロセスがあり、これら３つに共通していることは、現在と将来の顧客事業の需要を第一と考えることである。１つ目の事業キャパシティ管理(BCM) は、長期的な将来の事業目的を正確に把握することにより、キャパシティを分析、計画していく。２つ目のサービスキャパシティ管理(SCM) は、IT サービスが、時期や時間や近い事業計画の更新によるトランザクションの効果を分析し、リソースをどのように活用するかを予測していくことである。3 つ目のコンポーネントキャパシティ管理(CCM)は、データセンターの空調システム、SECOM入室管理システム、CPU などひとつひとつのコンポーネントのパフォーマンスとキ

→ →ャパシティを予測し、管理する。この３つのサブプロセスは、１２３の順で階層となっており、3 に不具合があると、2 に悪影響があり、それが、1 の見直しに繋がるというように、階層的に関連している。

キャパシティ管理の課題、重要成功要因、リスク課題：取り扱う情報が膨大なため、適切なしきい値をもうけ、警報とアラートがあがるようにするなど、ツールを使用して、なるべく自動化を計り効率化する必要がある。特に、自身が外部サービス・プロバイダである場合、事業顧客の事業計画を知ることが困難な場合があるが、情報を収集するよう、上級マネジメントに働きかける必要がある。


重要成功要因：事業計画に添ったニーズを理解し、キャパシティ管理計画を、費用対効果よく、タイムリーに導入すること。SLA 達成を失敗させる古い技術を取り除き、新しい技術を検討するなど、広い技術的ナレッジを持つこと。パフォーマンスが低いことに起因するインシデントを減少させること。

リスク：事業顧客や上級マネジメントからの、適切な量のヒト、モノ、カネ、情報が不足していること、事業の将来計画情報がわからないこと、ツールやコンピュータ・システムを利用せず、手作業に頼ることにより、正確で迅速な情報提供ができないこと、ビジネスの観点からわかるようなレポートを作成できないこと。

サービス提供インフラと対象としているビジネスにおける「事業活動パターン」との関連ユーザの職務により、繁忙期や使用目的が異なるため、キャパシティ管理の重要度は、下表のようにユー

ザ・プロファイルによって異なる。例えば、社内 LAN のキャパシティは、下表の通り、特に、この事業顧客のプロダクトを支える技術部門において重要なインフラとなる。この事業顧客の VBF は、ソフトウェア開発環境であり、その重要なサービスは社内 LAN のパフォーマンスである。しかしながら、その他のユーザにとっての社内 LAN のキャパシティ要求は、技術部門よりは高くはない。

この事業顧客に特有な、キャパシティ管理と事業活動パターンの関係性は、下表の通りである。

ユーザ・プロファイル該当する事業活動パターン（PBA）キャパシティ管理上級役員 (UP1) Blackberry で、常にメールの送受信が可能なことが顧客との良好な関係

に欠かせない。全てのアプリケーションに対して、社内 LAN の応答時間5秒以内, VPN 接続の場合は、10秒以内。

移動の多い法人営業 (UP2)

顧客との高い接触度。顧客に即応できる必要性。残業が多く、夕方〜深夜までネットワークが稼働していることを期待。電車での移動が多いので、処理能力は落ちても、軽量の PC を必要としている。PC が、常に VPN

接続できること、Blackberry で、常にメールの送受信が可能なことが外部顧客への早いレスポンスに欠かせない。

全てのアプリケーションに対して、社内 LAN の応答時間3秒以内, VPN 接続の場合は、5秒以内。ファイル


サーバの使用領域は、一ヶ月100MB増える。(SLA)

バック・オフィス・スタッフ(UP3)

外出がほとんどない。安定した処理性のある PC が必要だが、重量は気にならない。業務時間中は高い生産性を必要とするが残業はしないので、夕方以降や休日もネットワークが稼働していることまでは期待しない。

全てのアプリケーションに対して、社内 LAN の応答時間5秒以内, ファイルサーバの使用領域は、一ヶ月100MB増える。(SLA)

移動の少ない技術スタッフ (UP4)

オフィスに常駐しており、外出がほとんどない。ソフトウェア開発業なので、大量のデータを頻繁にダウンロードするため、社内ネットワークの信頼性とパフォーマンス（応答時間）への期待値が高い。

全てのアプリケーションに対して、社内 LAN の応答時間2秒以内, ファイルサーバの使用領域は、一ヶ月5GB増える。(SLA)

財務管理システム (UP5)

締め日前の 1週間は、応答が悪くなる。安定したトランザクションを実現するため、ネットワークの速度はあまり気にしないが、ネットワークの高可用性が必須。

社内 LAN の応答時間5秒以内, VPN 接続の場合は、10秒以内。(SLA)

業務支援プロセ　ス - Altiris (UP6)

ビジネス・プロセス。ユーザ自身でインシデントを起票、進捗管理するシステム。サービスデスク機能がフォロー・ザ・サンなので、24時間365日、IT、ユーザともに使用。IT は、Altiris を PC ビルドにも使用している。また、人事部と各部門長は、New Hire リクエストに、Altiris を使用しているため、多くの部署で共有されている。

社内 LAN の応答時間2秒以内, VPN 接続の場合は、5秒以内。(SLA)


可用性管理１．可用性管理の「目標」必要とされたときに、全ての IT サービスが使用でき（信頼性、保守性、サービス性に問題がないか）、パフォーマンスよく（キャパシティに問題がないか）、セキュリティが保たれた状態（安全性に問題がないか）であることを目標とする。しかしながら、事業顧客が、求めていない可用性レベルをサービス・プロバイダが設定し、事業顧客からみて、高すぎる投資が行なわれてはならず、事業顧客と上級マネージャの合意に基づく、適切な可用性目標値を持ち、適正価格の投資が行なわれなければならない。

２．「可用性の２つのレベル」サービス可用性と、コンポーネント可用性の 2 つのレベルに分類される。ユーザ側からみたときに、使用できるか否か（エンドツーエンドという）の観点から、サービス提供状態にあるかどうかをサービス可用性という。ネットワーク、無停電電源装置(UPS)、データセンターの空調、PC など、ひとつひとつのコンポーネントが停止しているか否かは、コンポーネント可用性といわれ、サービス・プロバイダ側からみたときに、必要なものが使用できるか否かである。コンポーネントのどれかが停止していれば、サービス可用性に影響がでる可能性がある。従って、この２つは連動性があり、サービス可用性が上層で、コンポーネント可用性が下層の２レイヤーとなる。

３．可用性管理の課題、重要成功要因、リスク　課題：可用性が、顧客の事業、顧客、上級マネジメントの期待に添う数値であること、変化する可用性の期待

値を管理していき、必要な予算を正当化することが課題である。マイクロソフト社が Office 3656のサービスの可用性を、99.9%と設定しており、満たさない場合は返金するとうたっていることの影響もあり、当たり前のように、高可用性が求められることが多い。しかしながら、極端な高可用性は不必要な高コストを求めることがあるので、費用対効果が得られない場合があることに注意する必要がある。もう１つの課題として、様々な技術からの情報が、様々なツールによって異なる形式で管理されている場合、ひとつのサービスにみえるものの可用性を管理することは極めて困難であることが挙げられる。例えば、メールの送受信の可用性は、サーバ・ハードウェアの可用性、ISP 　の可用性、社内ネットワークの可用性、 MS Exchange Server アプリケー

6 Office 365 のテクニカルサポートは、24時間 365日対応可能であり、可用性は 99.9%を保証し、満たされていない顧客には同社規定に基づいた額の返金が行なわれる。 http://en.wikipedia.org/wiki/Microsoft_Office_365

http://en.wikipedia.org/wiki/Microsoft_Office_365


ションの可用性、PC の可用性、PC にインストールされた Outlook の可用性、セキュリティの可用性の全てが関係しており、それらは通常、別々の機能により管理されている。一貫した方法で分析できるよう、AMIS に情報を統合するべきである。

　重要成功要因：エンドツーエンドの可用性が改善されたり、非可用性が削減されたり、MTRS が短縮されたりなどの結果を導くように、可用性が信頼性と共に適切に管理されていること。顧客満足度が高い、VBF の可用性高いなどの結果を導くなど、ビジネス・ニーズを満たしていること。非可用性により発生したコストを削減したり、タイムリーにシステム・レビューが完了するのを実現するような、適切に文書化された SLA が存在することが、可用性管理の CSF である。

　リスク：事業顧客、上級マネジメントからの理解が得られず、適正な予算を確保できていないことが、可用性管理の失敗に繋がる可能性がある。多数のコンポーネントからの膨大な情報が、整理されていない状態で拡散していると、報告プロセスに労力がかかること。エンドツーエンドの可用性や、事業側からみたニーズを軽視して、技術のみに焦点があたりやすいこと。

１．インフラの可用性の指標は、どのように決めたらいいか　決め方：可用性管理プロセス・マネージャが、現在の Blackberry サーバの可用性を測定し、プロセス・オ

ーナに報告し、プロセス・オーナが CIO に説明して、CIO が経営層とのミーティングを行い、事業顧客からの要望、IT スタッフのリソース、コンポーネント障害時のサプライヤのサービス性をふまえて、SLA を、可用性 90.00 %、24 　時間 365日稼働、障害時や保守によるダウンタイム 2時間以内と決定した。

　改善点： Blackberry サーバの可用性を決めても、Blackberry を経由してのメールの送受信の可用性については、Exchange メールサーバ、Blackberry端末の故障、日本であれば、NTTドコモの基地局の不具合、社内ネットワークの不具合など様々なサービスが複雑に影響しあうが、この点を、事業顧客が理解していない場合、Blackberry が長い時間使えないとしても、Blackberry サーバ自体は 100%正常に稼働しており、Blackberry の可用性は、90.00%という SLA を満たしていることもあるので、「Blackberry を使用してのメールの送受信」の可用性について、SLA を取り決めた方が、事業顧客にはわかりやすく、プロアクティブな処置に対して、適切な投資が行なわれるかもしれない。これらの点について、可用性管理マネージ


ャは、CSI 管理表に記載し、キャパシティ管理マネージャ、サプライヤ管理マネージャ、IT サービス財務管理マネージャとともに、改善をしていかなければならない。

ＩＴサ―ビス継続性管理―１．ＩＴサビス継続性管理の「目標」

経営層の責任範囲である事業継続性管理プロセス全体を支援すること、また、復旧オプションの選択、導入とリスク軽減手段の策定を目標とする。これは、コンポーネントの障害から起こる可用性の問題を取り扱う、可用性管理プロセスに似ているが、それとは影響規模と責任範囲が異なり、大地震、大火災、刑事事件、情報漏洩などが起きたときに、SLA で合意されたレベルで、事業を再開、継続できることを目標としている。そのため、全ての継続性計画が事業に及ぼすインパクトを、変わりゆく事業要件に合わせて維持管理されるように、ビジネス・インパクト分析(BIA)やリスク・アセスメント、レビューを定期的に行なう必要がある。

―２．ＩＴサビス継続性管理の上位計画（ＢＣＰ）との関係緊急災害時などに、長期間、オフィスが立ち入り禁止になったり、IT サービス継続性が失われたり、スタッフが全員仕事に戻れない状況になったりなどで、事業が継続できなくなったとしたら、経営損失が出ることを経営層は責任を負う必要がある。従って、事業顧客は、事業継続性計画(BCP)を策定する BCM マネージャを任命するべきである。しかしながら、BCP の大部分は、IT サービスや IT 環境にまつわることなので、ITSCM マネージャが、BCP案を元に、自社の IT をどのように復旧させるかについて管理しなければならないので、BCP とITSCM は、密接な関係にあるといえる。

―３．ＩＴサビス継続性管理の課題、重要成功要因、リスク　課題：ビジネス継続性マネジメント(BCM)がないことが課題となる。BCM プロセスがないと、IT側は、事

業顧客の戦略を理解しておらず、IT側に都合のよいプロセスと優先度により、IT サービスを復旧しようと試みるため、安易に、事業顧客の意図しない高価な ITソリューションを購入することになる。もしくは、災害時には、IT が全て何とかしてくれるだろうと思い込み、事業の継続性と収益が失われることになる。


　重要成功要因： IT サービスが顧客事業の達成目標を実現するために供給されていることを認識し、そのために復旧作業ができるようにする。復旧オプションのためのサプライヤとの契約が適切に締結されている。また、顧客事業の経営層、IT側の上級マネージャ、全ての従業員が、事業継続計画および IT サービス継続性計画に対する意識があることが、CSF となる。

　リスク： BCM がなく、ITSCM が単独で存在していること。また、ITSCM があったとしても、情報が古くなっており、事業のニーズとの整合性がとれていないこと。事業顧客側から、BCM のある ITSCM を策定するための事業計画、事業戦略などの十分な情報がなく、それゆえ、予算を正当化できないこと。技術的な課題にばか

　り焦点がいき、事業のニーズや優先度に焦点があてられていないこと。

―４．ＩＴサビス継続性管理の活動BCM に沿った ITSCM の方針を立て、BCM プロジェクトを立ち上げる。ITSCM は、ビジネス・インパクト分析により、災害によってもたらされる被害事項を知り、また、リスク・アセスメントを行い、その組織の脆弱性の程度を知ることを要件として、戦略となるリスクの軽減をどこまで行なうかと、もう１つの戦略である、復旧オプションをどれにするかを決めて、初期テストを行なってみる。そして、経営層からユーザまで組織全体に、事業継続性についての意識を啓蒙し、実際の手順について教育を行なう。そこまでの活動を通して、レビューと監査を行い、再テストを行い、問題がなければ、変更管理に渡して、ITSCM の活動はいったん完了するが、引き続き、事業の変化に応じて、改訂を行なっていく。

１．インフラが損害を受け、サービスが停止する可能性において、どのような損害が発生するか① 　一名体制の IT部員が、海外で交通事故にあい、現地で入院。その間、障害が起きたメールサーバにア

クセス出来なくなり、取引先との連絡が一ヶ月以上途絶えて、取引停止となった。②　メール情報漏洩と経営不正が、マスコミに公表され、会社の評判が著しく落ち、IT担当者全員含む、社員の 4割が即日退職し、社内 IT インフラが停止した。そのため、IT サービスに依存していた全業務が停止し、倒産した。


③　社内で傷害事件が発生し、警察が調査に来て、IT が、入室管理履歴を調査して、犯人を特定していた。その間に、全ての入室装置サービスが長時間停止してしまい、業務に支障をきたして、顧客との取引が停止になった。

④　火災により、データセンターに設置していたサーバが焼失。Web 業務アプリケーションサービスにアクセスできなくなり、締め日が終わってしまい、米国本社の経理システムが自動クローズされてしまい、修正不可能になり、部門長が、米国本社から責任を追求された。

⑤　津波により、外部インターネットにアクセスできなくなり、オンラインバンキングを使用しての取引先への振込が間に合わず、企業としての信頼を失った。

⑥　地震の影響で、ファイルサーバがダウンしたため、営業が（米国本社が作成した）新製品のプレゼン・テンプレートのダウンロードが不能。コンペに間に合わず、競合他社が勝ってしまった。

⑦　震災で、電話回線がダウンし、テクニカルサポート・ホットラインの受発信ができなくなり、テクニカルサポートを求める顧客からの電話がとれず、信頼を失った結果、多数の顧客からサーベイで低い点数をつけられ、部門長が、米国本社から責任を追求された。

⑧　震災で、FAX が不通となり、DELA のポリシーにより、契約 FAX番号からしか FAX で送れない、HDD ロック解除マスターキーが、DELA から受け取れず、社長の HDD のローカルにしかない資料をメールすることが出来ず、取引先に多大な迷惑をかけて取引停止にいたった。

⑨　火災により、入室管理システムが壊れ、社員がオフィスに入る事ができなくなって、一ヶ月が経過し、顧客から解約の申し込みが殺到した。

⑩　地震の振動により、部門で独自にたてた開発用 Unix サーバが物理的に破壊され、開発プログラムの納品が遅れたため、その顧客との取引契約が解除された。

この事業顧客では、下記のように、ほぼ完全な、「即時的復旧オプション」を用意しているので、上記のことは起きない。

IT 人員関連：同じ業務がこなせる人員を、複数の国に配置しているため、リモートからのサポートや長期出張によるサポート体制をとることが出来る。


メール関連：スマートフォンから、海外に設置している、GoodLink7サーバ経由、または、Blackberry サーバ経由で、メールの送受信が可能。その地域の電話インフラがダウンしている場合に備えて、そのスマートフォン・ハードウェアとキャリアは、どの国の通信方式にも対応しており、そのまま持って国外に移動することも可能。アドレス帳は、AD(+ Exchange サーバ)と同期をしているので、いつでも検索可能。メールサーバがダウンしている場合は、アプリケーション管理機能と技術管理が、24時間 365日オンコールで修復可能。

LAN 関連：PC を緊急用アウトラインにケーブルをつなぎかえるか、会社支給のスマートフォンによるテザリングか、データカードでインターネットに接続し、VPN 接続すれば回避できる。地域全体のインターネットインフラがダウンしている場合は、全ての業務を APACタイムゾーンの別の支社の社員に業務を分担。もしくは、香港オフィスか台湾オフィスで出張勤務する。

PC 関連:

災害等で、PC が全部破壊されている場合は、海外支社に、古いモデルの PC を全台保管しているので、それらの PC を最寄りの海外支社から取り寄せ、Altiris ツールを使用し、フランス支社からネットワーク経由でPC ビルドする。ローカルデータは、Mozy online backup8を使用して、即時、復元可能。HDD ロックがかかってしまった PC のローカルデータも、Mozy online backup経由で、別の PC に復元可能。

ホットライン関連：地域の電話インフラ全体がダウンしている場合は、他の国のテクニカルサポート部門で代行可能（地域語対応の技術社員がいる）。

7 米国 Good Technology社の開発した、モバイル・データ・ソリューション・ツール。 Android フォンや i-phone と MS Exchange Server を接続し、メールの送受信が可能。http://en.wikipedia.org/wiki/Good_Technology

8 米国シアトル市にある、EMC社のオンラインバックアップツール。

http://en.wikipedia.org/wiki/Good_Technology


サーバの物理障害関連：壊れたサーバは、現地 IT が不在の場合、ドイツ支社に空輸され、DELL の国際ワランティーにより無償で修理され、データはドイツの IT によって移行され、数日で使用可能。

サーバ障害関連：全ての海外支社のほぼ全てのサーバが、米国本社で、一括管理されており、二重化されているので、米国本社以外で起きた共有サーバ障害に関して、データの同期をとる作業は不要である。


情報セキュリティ管理１．情報セキュリティにおける「ＣＩＡ」

C は、 Confidentiality（機密性）- 情報を知る権限を持つ人だけに閲覧可能にすることにより、機密性が高い状態であり、I は、Integrity（完全性）- 情報が完全でかつ正確で、許可されていない外部からの修正から守られていることで、完全性が高い状態であり、A は、Availability（可用性）- 必要なときにすぐに利用可能であるとか、障害が発生すれば、すぐに復旧できるか、そもそも障害に対して防衛策があり、可用性が高い状態であること。かつ、外部の企業との情報交換する場合に、その取引情報が信頼できるものとなっていること。CIA は、IT 技術的な側面からだけではなく、オフィスへの侵入など物理的な側面からも、ビジネス・プロセス全体に渡って、保護されなければならない。

２．情報セキュリティ管理における課題、重要成功要因、リスク

　課題：情報セキュリティ委員会が機能していない。なぜならば、上級マネジメントの支持が得られておらず、計画立案をしていない。事業顧客は、その重要性を認識していたとしても、IT（特に、外部サービスプロバイダの場合）がなんとかしてくれるであろうと考えており、上級マネジメントとの話し合いがなされていない。たとえ、計画立案されていても、プロセス実務者に、その必要性が十分説明されていない。結果、ユーザは、誰もセキュリティ規約を守らず、事故が起きてしまってから、例えば、たった一通のメールの誤送信が起きた場合でも、全社員のリソースを使用して、調査がはじまるものの、対応手順が確立されていないので、膨大な時間を要し、事業の継続性が失われる。事業顧客が重要と考えるセキュリティの認識が、IT部門と整合性がとれていないことも課題となる。

　重要成功要因：第一に、事業がセキュリティ妨害から保護されており、サービスデスクに報告される違反件数が少ないこと。上級マネジメントと事業顧客の間で、事業ニーズと一体化した合意済みの方針があり、ユーザに、その防止策が浸透していること。プロセス実務者、ユーザなど組織全体に、繰り返しトレーニングがなされていること。セキュリティ手順が、正当化され、適切で、上級マネジメントに支持されていること。変化していく環境に応じて、手順とコントロールに関する改善案が数多くあがるような、改善の仕組みがあること。


　リスク：可用性と堅牢性に対する要件の増加に対応しなければならないリスク。スマートフォン紛失、ウィルス感染、外部からの侵入など、ユーザの意図しない原因により、個人情報を外部に流出させてしまうリスク。ユーザが、意図的に社内情報を外部に持ち出すリスク。事業顧客側が、ISM に従って行動しないリスクがある。将来の事業戦略に対する計画の認識不足や、予算不足により、効果的に ISM が実施できないリスク。

１．情報セキュリティ施策

a. 入退社に伴う事故対策目的- 　 Tool上で New Hire request が生成されると、Windows アカウントが自動生成されるが、AD上で、Outlook から見えないよう設定を治しておき、確実に出社が黙視確認された後に（離れているオフィスの社員の場合は、本人と連絡がとれた後）、見えるように設定する。（まだ社員ではない人間の個人情報保護）- 　 Tool上で Termination Request が生成されると、Windows アカウントが自動で Disable されるが、最終出社日を人事部と本人に確認し、MS Outlook から見えないように設定する。（もう社員ではない人間のプライバシー） - あらゆるアクセス権の追加には、そのユーザ直属の上長からの申請があった場合のみ可能。- 　退職者の Windows アカウントが AD上で無効化されているか確認し、hostname を無効にし、Unix アカウントも無効にし、全ての Distribution List や、アクセスグループから削除する。- ファイルサーバのフォルダごとのアクセス権管理がなされているか確認する。- 退職者の回収リストを作成して、全てのアセットを確実に回収し、部門長のサインをもらう。- 退職者のローカルデータは、丸ごと DVD に焼いて、部門長に渡して、サインをもらう。- 退職者の HDD は、規定の時間以内に復旧不可能なレベルでフォーマットする。- 部屋によって、入室できる人を最低限に制限したアクセスカードを作成し、入室の必要がなくなったら、規定時間以内に、システム側で変更。


b. リーガルセキュリティ目的- 人事部からの要請があった場合、ユーザ個人の VPN アクセス履歴、ログオン履歴、インターネットアクセス履歴などを開示する。- 情報セキュリティ委員会の規定作成に関わり、調査、提案、ドキュメントのアップデートを行なう。- 退職者のメールデータであっても、一定期間、訴訟ホールド9しておく。- 不正がないように、ソフトウェア・ライセンスの移行状態を正確に把握する。

c. 情報漏洩保護目的- PC を鍵のかかる倉庫に保管し、入出庫するときは、10分程度の一時的な出庫であっても、紙に記録する。- PC には、唯一のハードディスクパスワードをかけて配布する。- メール誤送信を防ぐため、MS Outlook 2010 の宛先オートコンプリート機能はオフにしてから、ユーザにPC を提供し、ユーザにも、オンにしないよう誓約させる。- 3回の誤入力パスワードをトリガーとしてアカウント・ロックがかかるようにする。- 全てのパスワードは、可能な限りシステム側（グループポリシー等）で強制的に、複雑なものしか設定できないようにするとともに、規定の日数が経過した場合は、変更を求めるように設定する。- 全てのパスワードを紙に書く事は禁止している。- パスワードや RSA Token10などの PIN コードを他のユーザに言う、代行ログオンは本人の許可があっても100%禁止している。- スマートフォンやノート PC や、RSA Token が手元にないことに気がついた時点で、IT か情報セキュリティ委員に電話で報告するよう、ユーザに誓約させる。

9 訴訟が起きた場合、メールを保存していないと、企業に不利になることがあるので、Exchange側で、設定しておく。

10 RSA社が開発した、安全な VPN 接続可能にするシステム。http://en.wikipedia.org/wiki/SecurID

http://en.wikipedia.org/wiki/SecurID


- 個人所有 PC から、MS OWA11経由でメールサーバにアクセスした場合は、添付ファイルを個人 PC に保存しないよう、誓約させる。- ユーザ席にある PC は全て、ケーブルロックするよう、ユーザに誓約させる。

ウィルス侵入、外部侵入対策目的- Windows Firewall は、ユーザがオフに出来ないよう、グレーアウトさせて、PC配布。- 　ウィルスはサーバ側で自動検知、駆除するように設定し、感染アラートを自動リポートする。自動駆除できていなかったら、ユーザに連絡をとり、PC のリビルドを行なう。- PC側の McAfee EPO Agent12が、ウィルスを自動検出し、自動駆除出来ずに、警告メッセージが表示された場合は、IT サービスデスクに速やかに報告させる。- IMゲートウェイで監視できない、IM13以外は、インストールして使用してはならない。- 外部ベンダーが社内で仕事をする場合は、NDA にサインをしてもらう。- 外部ベンダー用の貸し出し PC は、ドメインにログオンできないよう、ローカルログオンに設定し(Wireless LAN を使わせないため)、アウトライン接続して作業してもらう。

11 ブラウザがあれば、どの PC 　からでも、メール送受信ができるマイクロソフト社のシステムhttp://en.wikipedia.org/wiki/Outlook_Web_App

12 マカフィー社のセキュリティソフトのクライアントツール http://en.wikipedia.org/wiki/McAfee_VirusScan

13 AOL, MS Messenger などのインスタント・メッセージング・システムであり、社外のアカウントは登録できないようサーバで制限している。2014年 4月現在は、Microsoft Lync で統一している企業が多い。

http://en.wikipedia.org/wiki/McAfee_VirusScan

http://en.wikipedia.org/wiki/Outlook_Web_App

第 3 　章 RCVについて

需要管理１．需要管理12月には、年賀カードがよく売れる、経理部スタッフは、毎月月末は非常に忙しいなどという、事業顧客の事業活動パターンやユーザ・プロファイルを把握、予測、分析し、サービス資産のキャパシティやパフォーマンスが過不足なく提供されることを、キャパシティ管理と共にコントロールしていくプロセスである。需要管理に固有なプロセスとしては、事業の繁忙期を拡散させて、特定のサーバへのアクセス量をコントロールするような、奨励、罰則などの戦略によって、需要に影響を与えることと、事業目標数値達成と IT投資の両方のバランスをとる方策をさぐることである。

２．需要管理と一番密接な関係にあるプロセスはどれかキャパシティ管理プロセスである。どちらも、事業成果実現と IT投資の最適化を目標とするが、次の点で異なる。需要管理は、ややビジネスとユーザ寄りのプロセスであり、事業顧客が、自らの顧客に対し、格差課金をもうけ、繁忙期を拡散するなどして、製品需要の調整を図るのを受けて、IT サービスの需要を予測して、戦略を立てる。一方、キャパシティ管理は、IT サービスと技術寄りのプロセスであり、需要管理から受けた需要情報により、サービス資産のキャパシティやパフォーマンスが過不足のないように管理する。このように、キャパシティ管理の仕事は、需要管理から引き継がれていること、また、需要があるから、キャパシティが必要になることからも、これらのプロセスは密接な関係にあると言える。

３．コアサービスと支援サービスコアサービスとは、例えば、メールの送受信ができるなど、顧客にとっての基本的なサービスである。それに対して、支援サービスとは、顧客の要望に合わせて、ドミノサーバであったり、Exchange サーバであったり、Office 365 であったりと選べて、更に、メールの送受信が、24時間 365日可能であることを保証するなど、顧客にとっての付加価値を提供する、魅力サービスである。これらの組み合わせは、サービス・パッケージとして顧客に提示され、サービス・プロバイダは、これをサービス・ポートフォリオ管理に組み入れ、購入/導入を検討する。同時に、このコアサービスと支援サービスの組み合わせで、顧客の事業活動パターンとユーザ・プロファイルに適合するか、需要管理にて検討することになる。


４．需要をコントロールする方法需要管理が、事業活動パターンとユーザ・プロファイルを分析することによって、どのユーザが、どのサービスを、どの時期（どの時間帯）に、どのくらい必要とするのかを事前に知る。それによって、ユーザが、期限までに入力しないと経費の振込が来月に繰り越されるなどの罰則をもうけて経費精算システムの使用を平準化させてコントロールすることがある。また、キャパシティ管理が、事業環境の変化を把握し、新しい技術やサービス要件をサービス・ポートフォリオに反映し、リソース予測を正確にすることで、需要に対応することも、需要をコントロールする方法といえる。

１．ビジネスの事業活動パターンパターン：Webタイムシートの入力の締め日が、毎週金曜日の 22:00 なので、金曜日の 17:25 – 17:35 の間

に、7000ユーザが一斉にアクセスし、ユーザから見たパフォーマンスが落ちる。また、サーバがダウンする可能性もある。　背景：金曜日にまとめて入力する人が多く、金曜日の 17:25 くらいにならないと、退出時間が不明、また、金

曜日なので、残業する人も少なく、17:35 以降に入力させることも難しい。月曜日の朝に入力したのでは、締め日を過ぎており、毎日入力したとしても、金曜日の夕方も入力しなければならない。

　対応策：毎週木曜日の朝に、7000 人に、一斉メール配信で、「タイムシートの入力締め切り金曜日22:00 のお知らせ」を出す事により、パート社員など退社時刻が予めわかっているユーザには、月〜金の分まで、木曜日の空いている時間に、入力してもらう事を期待している。将来的には、不可分散の措置をとる予定である。

第 3 　章 RCV についてRCV（Release, Control & Verification)「リリース、コントロール、および妥当性」について、以下の通りまとめた。

ITIL で示している管理プロセスに該当するもの変更管理プロセス


トリガ: 　 IT 組織をローカルベースから、ワールドワイドベースへ変更して、コスト削減（組織変更）インプット: 米国本社から、ワールドワイドで、OS をローカル言語から英語に変更するという、サービスポートフォリオ管理への変更要求。（インパクトが大きい重大な変更なので、サービスポートフォリオ管理への変更要求が必須）

　インターフェイス：移行の計画立案およびサポート、変更評価プロセス　アウトプット：許可された変更がアウトプットされ、移行の計画立案およびサポート管理に渡される。

１．ＲＣＶにおいて活動するマネージャやスタッフの役割り（１）サービスの妥当性管理およびテスト

①　サービス・テスト・マネージャテストの中立性を保つために、リソース管理および展開管理に責任を負う者以外を割り当てなければならない。SD 段階で、テスト条件、テスト・スクリプト、テスト・データ・セットの設計と計画を支援する。テスト・リソースを割り当て、テスト方針を遵守させる。リソース管理および展開管理が行なったテストを検証する。テスト環境を管理する。テストの進捗、テスト成果物、成功率、課題とリスクについての管理レポートの提供を行なう。（２）リリース管理および資産管理

①　リリースおよび展開マネージャテストの中立性を保つために、サービスの妥当性確認およびテストを担当する者以外を割り当てなければならない。技術管理やアプリケーション管理などの機能からのリソースを含む、全てのリソースを計画し、調整する。ツールとプロセスに関する支援を計画、管理する。変更許可を必要とするあらゆる活動の前段階で、変更許可管理プロセスを支援する。変更管理、サービス資産管理と構成管理、妥当性とのインターフェイスの調整をする。

②　初期サポートスタッフ技術管理やアプリケーション管理の機能の要員であり、パッケージ化と構築の実務者、または、展開の実務者が割り当てられることが多い。展開から最終的受け入れまでの期間に、IT サービスと事業機能をサポートするサポート文書を提供する。リリースを受け入れる。初期の段階のインシデントやエラーの対応を、


サービス・オペレーションに対して支援する。サービス・オペレーションへの移行を取り扱う。問題管理を行い、RFC を提起する。サービス・リスク・アセスメントを行なう。

（３）サービス・ナレッジ管理① ナレッジ管理プロセス・オーナ

多くの組織では、同プロセス・マネージャと兼任され、また、サービス資産管理および構成管理の役割と兼務されている。組織内のナレッジの識別、取得、維持のための全体的なアーキテクチャを作成する。プロセス戦略を定義し、プロセス設計を支援する。プロセス文書を最新の状態に保つ。プロセスの方針と標準を定義する。コンプライアンス確認のために、定期的に監査を行なう。プロセス戦略をレビューし、変更する。課題に対処する CSI 管理とそのレビューを行なう。

マネージャの役割リリース管理および展開マネージャ概要: Windows XP から、Windows7へのアップグレードに伴う、デバイスドライバ、標準ソフトウェア、セキュリティパッチのパッケージリリース

役割: 1) リリースと展開の計画立案。Windows XP から Windows7へ移行するに当たり、デバイスドライバを新 OS 対応のものにパッケージし直す。リリース・パッケージには、手動でのインストール手順書、前ヴァージョンからの改良点の文書など複数のリリース・ユニットを含める。問題発生時の切り戻しのため、アンインストールの合否もテスト項目に含める。2)リリースの構築。ストックホルム、シドニーのパッケージャーに、リリース・パッケージ作成依頼する。3) 妥当性確認テスト。担当パッケージャーとコミュニケーションをとりながら、日本語Windows7上にて、SCCM14経由にて、テスト PCへのリリース・パッケージをインストールし、動作テスト手順項目に従って、テストを実施。不具合があれば、問題チケットを発行し、開発チームにリ・アサ14 マイクロソフト社が提供する、ソフトウェア展開、資産管理システムツール; System Center Configuration Management http://technet.microsoft.com/ja-JP/systemcenter/bb507744.aspx

http://technet.microsoft.com/ja-JP/systemcenter/bb507744.aspx


インし、パッケージの改良を行なう。完全性を保護しながら、新しい機能性を提供できることを確認する。有用性と保証があることも確認する。3) 確定版メディアライブラリに登録するために、変更管理プロセスから許可を取る。動作テスト手順項目表にて問題項目がなくなったら、変更管理プロセスに変更許可依頼する。4) 展開。受理されたら、SCCM経由で、テスト・デスクトップ・イメージングをし、新イメージ全体のテストを実施する。パイロットユーザ（Early Adaptors）への展開する。5) SDP 　通りにサービスを定着させる。 6) サービ

　スオペレーションに予測されるトラブル等を伝え、引き継ぐ。 7)レビューとクローズ。パイロットユーザに、悪い影響がなかったことを確認し、確定版メディアライブラリに登録する。Windows7 マシン配布済みの全ユーザ 7000 人にプッシュ配布し、変更要求チケットをクローズする。


１．サービス・マネジメントにツールを利用することの利点サービス・デザイン・プロセスが、より効率的に機能するという利点がある。具体的には、効率と効果、弱みと改善の機会を特定し、管理情報を提供する。マネジメント・コストを削減し、IT サービスの生産性を向上させる。IT サービスの品質を向上する。重要なプロセスの集中化を行い、サービスマネジメントの中核的プロセスの自動化と統合を行なう。データが集まって、情報となり、それがナレッジになることで、傾向を明確化できるという利点がある。

２．サービストランジションの課題、重要成功要因、リスク課題: ST には、IT 組織だけでなく、財務、技術、人事など、たくさんの人が関わるので、システムが、複雑になりがちである。多種多様な顧客、つまり、多様な窓口の管理が必要となる。そのため、調和や統合がほとんどない。また、レガシーシステム、新技術などの未知の依存関係がある。安定稼働と、サービス変更のビジネス・ニーズの間でバランスをとる必要がある。CSF: サービス品質を、事業要件と整合させながら、費用対効果よく、継続的に向上させること。リスク: モチベーションを下げるような説明責任、実行責任、プラクティスの変更があること。運用スタッフの異動。計画外の追加コストの発生。リスクを回避しすぎることで、事業に過剰なコストがかかる。不適切な人が情報にアクセスし、ナレッジに介入してくる。プロセス間の統合が不十分なため、縦割りになる。その結果、事業が失敗すること。

業務をはじめから立ち上げる事例RSAハードウェアトークンから、RSAソフトウェアトークンへの移行1. VPN 　接続が移行期間も引き続き使え、ダウンタイムがないことに注力 --- >　可用性の問題を解決。2. RSAソフトウェアトークンへの移行が済んだユーザに対しては、速やかに確実に、RSAハードウェアトーク

　 →　ンアカウントを無効にすることに注力セキュリティの可用性の問題を解決。3. 　 RSA 　 →　ハードウエアトークンを確実に回収することに注力サービス資産管理および構成管理データベース(SACM)を正確に保つ問題を解決。


変更管理1. 変更管理の「目標」変更ライフサイクルを一貫してコントロールすることにより、サービスの中断のリスクを最小化し、事業に有益な変更を実施することを目標とする。そのためには、変化する事業要件に対応し、サービスの価値を最大化し、変更によるインシデント、変更に伴うサービスの中断、変更に関する手直しを削減しなければならない。IT

サービスと事業のニーズを整合させるような変更要求に対応することが望ましい。変更管理は、a) 事業が求める、コスト削減、サービス改善、サポートの容易さや有効性の向上、b) エラーを解決し、変化する状況に適応する手段として、リアクティブに生じるコストと時間の削減、c) 利点やリスクの排除を早期に実現することで、事業の損益を改善するために、必要とされるプロセスである。

２．「変更許可モデル」変更要求の許可には、様々なレベルのものがあり、下記のように、階層づけられる。この情報は、CMS に文書化すべきである。既に判断されたレベルでも、途中で、新たなリスクが発見された場合、その度合いにより、適切なレベルまでエスカレーションされる。また、却下された変更要求は、より高いレベルに申し立てることができる。レベル 1: 　　　事業担当役員が変更許可 – 役員の意思決定を必要とする、高コスト、高リスクの変更。レベル 2: IT 　　　　　　役員が変更許可 – 複数のサービスまたは複数の事業部にインパクトを与える変更。レベル 3: CAB または、ECAB が変更許可　 – 現場またはサービスのグループのみに影響を及ぼす変更。レベル 4: 　変更マネージャが、変更許可 – 低リスクの変更。レベル 5: 　　　　　　　　　現場の許可 – 標準的な変更。

３．「変更管理の７つのＲ」Raised, Reason, Return, Risk, Resource, Responsible, Relationship であり、変更管理する上で、必ずこれらが、報告されなければ、正しく変更管理できていないことになる。変更管理を提起した者は誰か、変更する理由は何か、変更するメリットは何か、変更することによるリスクは何か、リスクがあっても、変更を求める


か、変更するのに必要なリソース（人、モノ、カネ）は何か、それは足りているのか、その変更の構築、テスト、実施に責任をもつ者は誰か、その変更に影響を受けるものは何であり、どんなことかを明らかにする必要がある。

変更承認　担当：レベル 2: IT 　役員が変更許可 – 複数のサービスまたは複数の事業部にインパクトを与える変更。

CIO が、海外本社にいるため、日本ローカルのみに影響のある変更については、ローカル IT が変更許可をしている。例えば、日本でのみ販売されているスマートフォン、フィーチャーフォンの機種変更、日本の通信キャリアの選定など、複数の事業部にインパクトを与える変更などである。見積もりが、1000万円以上の場合は、レベル 1 にエスカレーションされる。


サービス資産管理および構成管理

１．サービス資産管理および構成管理の目標サービス資産をうまく管理しないと、事業は効率的、効果的に運用できないので、資産が適切にコントロールされるようにすることが目標となる。そのためには、正確で信頼性のある情報が、必要なときに、必要なところで利用できなければならない。その主な目的は、a) バージョン、ベースライン、構成コンポーネント、それらの属性、関係を含む、サービスと他の CI について、識別、コントロール、記録、報告、監査、検査する。b) 正確で完全な CMS を作成し、維持し、それらの完全性を確立する。c) 変更とリリースの許可や、インシデントと問題の解決などにおいて、適宜判断を下せるようにすること。

２．サービス資産管理および構成管理の「事業に対する価値」次の 2 つが、SACM の事業に対する価値となる。a)サービス停止、罰金、修正ライセンス料金、監査がうまくいかないことなどの全体的なサービス・パフォーマンスの改善がもたらされること、また、b) サービスレベルの保証の提供、法律上、および規正上の義務の遵守レベルの向上、サービスのコストを識別できる能力、固定資産の適切な管理、変更とリリースのアセスメント、計画立案の提供による、サービス・リリース環境の可視化が行なわれること。

３．サービス資産管理および構成管理の活動ステップ 1. 管理と計画立案をする。（注意）このステップ 1 は、PDCA の P(Plan)に当たるので、後述のステップ 2 - 5 　までを支配する。例）下記のような項目を決める。適用範囲を決めるサービス、環境、インフラ、ロケーション要件を決める方針と戦略、説明責任、追跡可能性、監査可能性に対する要件、CMS に関

連する要件との関連づけ。適用する方針と標準を決める ISO20000 などの業界企画。ハードウェア標準を決める。SACM の組織役割と責任、CAB、ベースライン、変更、およびリリースを確立する権限。SACM のツールを決めて、プロ構成識別、バージョン識別、サプライヤ管理、変更管理


セス手順を決める。他のプロセスやグループとの関係

固定資産管理、プロジェクト、SPI、サービスデスク

ステップ 2: 構成を識別する活動文書化された基準にしたがって、CI と構成コンポーネントを決める。CI に識別子を割り当てる。CI に属性を指定する。CI を SACM のコントロール下に置く時期を指定する。各 CI のオーナーを決める。

ステップ 3: 構成をコントロールする活動a) 未使用ライセンスが最小限である状態にする、ライセンス・コントロール。b) 変更管理、イメージビルドのバージョン・コントロール。c) CMSへのアクセス・コントロール、d) DML の完全性コントロール。

ステップ 4: ステータスの説明と報告の活動→ →開発中承認済み使用中止のどれかのステータス。その活動は、構成レコードを維持し、アーカイブす

ること、また、今までの構成を記録、検索、管理。受領から廃棄までの CI の変更の記録すること。

ステップ 5: 検証と監査をする活動文書化されたベースラインが実際と一致しているか。CI が組織内、または、DML や予備品保管庫に存在していること。CMS 内のレコードが実際のインフラと一致していること。（注意）このステップ 5 は、ステップ 1 にフィードパックをする。

１．構成管理の実施状況


ネットワーク経由で、Altiris15ツールが、ネットワークに接続されているサーバ、PC (CI)の情報を吸い上げる。自動認識できない CI、DML、イメージビルドのバージョンなどについては、別途、MS Excel やファイルサーバ、キャビネット等で管理している。Altiris コンソールから、PC アセットのシリアル番号、モデル番号、ハードウェアスペック、インストールされている OS やインストールされたソフトウェア情報を確認できる。それらの情報は、固定資産管理、ソフトウェア・ライセンス数管理、トラブルシューティング時の参考情報として活用される。CI の使用中、廃棄などのステータスの履歴は、Altiris から、確認できないので、その都度、チケットを起票するとともに、MS Access で管理し、いつでも、検索により、構成の履歴を追跡することを可能にしている。アセット納品時に、サービスタグナンバーを経理部に知らせ、年に一度の棚卸し時に、経理部と IT とで、固定資産を物理的つきあわせることで、資産台帳管理をしている。

15 Altiris社が開発した、自動アセット管理、自動ソフトウェア配信、PC ビルド、ナレッジ管理等が可能な IT サービスマネジメントツール。ユーザ自身でチケットを起票し、ステータスを自身でトラッキングすることが可能。


サービスの妥当性管理およびテスト

１．サービスの妥当性管理およびテストの「目標」サービスの品質保証が目標である。具体的には、新規、または変更されたサービス、サービス提供内容が SD とリリースで実現すること。設計仕様に合致して、事業ニーズを満たすようにすること。リリースが、コスト、キャパシティ、制約の中で、成果と価値をもたらしていること。有用性と可用性があること。テスト・プロセスを計画して、実施すること。事業要件と利害関係者の要件を満たすこと。これらには、SD の初期に行なわれるテストが重要である。このテストにより、a) ユーザが効果的に利用できていないことの増加、b) インシデントの増加 c)サービスデスクへの確認コールの増加、d) エラーによる修正コストの増加を防ぐことができ、これらも目標となる。

２．サービスの妥当性管理およびテストに関連ある下記の用語

(１)　テスト戦略：　関与していなかった第三者によるテストが望ましい。合否の基準は、SDPに文書化してから決める。反復的で再利用できるテストであること。（テスト・モデル→テスト・ケース→テスト・スクリプト→テスト・データのためのライブラリ作成→カタログ化→保守の順のテンプレートを作成する）また、テストをプロジェクトやサービスライフサイクルに統合する。リスク軽減のためのリスクベースのテスト・アプローチ、テストスキルの向上を含む。

（２）　テスト・モデル　：前述のテスト戦略に基づいた、フィードバック取得を目的とした、テスト手順のこと。テスト計画、テスト対象、テスト方法を定義したテスト・スクリプトを含む。反復可能で、効果的、効率的であり、一貫性があることが望ましい。

３．サービスの妥当性管理およびテストの観点サービスの妥当性管理およびテストは、サービスが、要求された通りに提供されるかに焦点をおくが、それは、サービスを使用する人、提供する人、展開する人、管理する人、運用する人々の観点が基本となる。テストの開


始基準と終了基準は、サービスデザインパッケージの開発段階で決める。その観点は、①サービスデザイン、機能上、管理上、運用上の観点、②技術設計、③プロセス、④測定設定、⑤文書、⑥スキルとナレッジである。サービス受け入れのテストは、サービス要件の検証から始まる。合意されたサービス要件を最終確認する顧客、顧客代表、その他利害関係者（該当する新規、または変更されたサービスを使用する、ユーザ）は、サービス受け入れ基準とサービス受け入れテスト計画に対しても、最終確認を行なう。

１．移行にあたっての妥当性確認をどのように実施するか。サービスレベル（有用性、保証）の判定はどのように行なわれるか。

内容：会計システム用リポーティングマクロのバージョンアップの妥当性確認方法：本番システムより、MS SQL サーバの中の先週分データを、テストシステムにコピーして、テストシステム上のデータから、バージョンアップしたリポーティングマクロを実行させ、顧客の要求通りのデータが抽出されているかを確認する。

サービスレベル判定：顧客の要求しているデータが正しく抽出されているか（パフォーマンスの実現）、それを抽出するために、何か特別な操作がいらないか（使用にあたり、制限が無いか）の 2 点を確認することにより、有用性を確認する。また、マクロボタンを押したときに、時間がかからずに、リポートが表示されるか（キャパシティ管理）、常に、同じように正しく動作するか（可用性管理）、マクロが壊れたときに代替案が使用できるか（IT サービス継続性管理）、それらのデータに適切なユーザのみがアクセスできるかどうか（セキュリティ管理）の 4 点を確認することにより、保証を確認することで、妥当性とサービスレベルを判定できる。

第 3章 RCVについて

リリース管理および展開管理

１．リリース管理および展開管理の「目標」リリースの構築、テスト、展開を計画、スケジューリング、コントロールすること、また、既存サービスの完全性を保護しながら、事業が要求する新しい機能性を提供することを目標とする。そのためには、次の順番で、目的を達成する。a) 顧客や利害関係者とリリース管理および展開管理の計画を定義し、合意する。b) リリースパッケージを作成し、テストする。c) 完全性が維持され、DML に保存され、CMS に正確に記録されるようにする。d) DML 環境から本番環境に展開する。e) 追跡、導入、テスト、検証し、また、適宜、削除、切り戻しできるようにする。f) 逸脱、リスク、課題を記録、管理し、必要な是正処置をとる。g) ナレッジとスキルをサービスオペレーションの機能に継承されるようにする。

２．リリース管理および展開管理の「事業に対する価値」効果的なリリース管理および展開管理の実施により、より迅速に最適なコストで、かつリスクを最小化して実現する、顧客とユーザが、新規または変更されたサービスを、事業最終目標を支援する形で、利用できるようにする、事業の変更、サービスチーム、サプライヤ、顧客の間で、より一貫した実施アプローチを取ることができる、サービストランジションを通じ、あらゆることが監査可能、追跡可能であることが、事業に対する価値である。

３．リリース管理および展開管理の「活動」a) 　リリースと展開の計画立案 – →変更管理による許可リリースパッケージ作成への変更管理の許可という活動。b) 　リリースの構築とテスト – → →ベースライン化されたリリース・パッケージの構築そのテストの実施サービス資産管理および構成管理を通して、DMLへの登録という活動。（注意：一度しか生じない）c) 展開 – DML にあるリリース・パッケージを本番稼働環境に展開し、サービスオペレーションと初期サポート（アプリケーション管理や技術管理）に引き継ぐという活動。（注意：リリースごとに複数回生じる）d) 　レビューとクローズ – 経験とフィードバックが取得され、パフォーマンスと成果がレビューされ、ナレッジを得る活動。

第 3章 RCVについて

ITIL のリリース管理の活動と比較ステップ 1: 　リリースと展開の計画立案 – →変更管理による許可リリース作成への変更管理の許可という活動。

2013年 12月末までに、Windows7 に対応するインフラ、クライアント PC、サービスデスク、運用管理、技術管理、及び、アプリケーション管理の体制を整えなければ、2014年 4月の Windows XP のサポート終了までに、ユーザが安全に IT サービスを受けられない。同時に、Lotus Domino (Notes Mail と Notes データベース) から、MS Exchange Server (Outlook メール) + MS Share Point（データベース）への移行も完了し、そのインパクトがユーザのクライアント PC に及ばないようにし、MS Exchange Server + MS Share　 point の使用により、ユーザの仕事の効率も高めなければならない。これらの計画に対して、それぞれ RFC が作成され、変更評価にて、STORMPUP リスク・アセスメントを行い、変更管理から、リリース作成開始の許可を得た。

ステップ 2: 　リリースの構築とテスト – → →リリース・パッケージの構築そのテストの実施 DMLへの登　録という活動。シドニーと、ストックホルムのパッケージャーが、リリース・パッケージを構築し、日本で、その妥当性確認テストを実施し、合格したものから、順次、DML に登録した。　　

ステップ 3: 展開活動MS SCCMツールを使用して、パイロットユーザに配布し、変更管理に許可を得て、全ユーザに配布した。アプリケーション管理と技術管理にて、レビューがなされ、初期サポート・スタッフに引き継いだ。

ステップ 4: レビューとクローズ活動アプリケーション管理と技術管理からの経験とフィードバックを取得し、パフォーマンスと成果をレビューし

ナレッジを SKMS に保存した。

第 4章 OSAについて

評価１．評価の「目標」変更管理がリリースを許可する前に実行される活動であり、事業成果に対して、また、既存および提案されたサービスと IT インフラに対して、与えそうなインパクトの面から、サービス要求のパフォーマンスを判断することで、一貫性のある標準化された手段を提供することを目標とする。パフォーマンスは、予測されたパフォーマンスと比較して評価される。利害関係者の期待を正しく設定し、変更管理に有効な情報を正しく提供して、リスクをかかえたまま変更が許可されるのを防ぐ。できる限り多くの項目について、評価するのが望ましい。

２．評価の課題マネージャが解決すべき評価管理プロセスの課題は、a)様々なプロジェクトやサプライヤに共通して適用される、標準的なパフォーマンス指標と測定方法を策定すること、b)様々な利害関係者の観点を理解すること、c)

移行中、および移行後の予測における差異の減少を、測定および実証すること、d)移行中と移行後の予測における差異の減少を測定すること、e)リスクに対して、現実的で慎重なアプローチをとること、f) 人々が、情報を共有するリスク管理のカルチャを推奨すること等である。

評価プロセスの状況

ステップ 1: 評価の計画立案 – 目標としている変更を確実に達成するため、変更による意図しない悪影響がないようにするため、計画を立てる。

ステップ 2: 　予測されたサービス・パフォーマンス（有用性と保証）の評価 - 移行しても問題がないかを確認するため、計画されたパフォーマンス通りになっているかどうかを評価する。

ステップ 3: 　実際のサービス・パフォーマンスの評価 –　変更評価に、（リリース前であれば）臨時評価レポート、（展開後であれば）初期サポートからのフィードバックを含め、評価レポートを提出する。


評価レポートに含まれるもの: リスク・プロファイル、逸脱レポート、検定記述書、妥当性確認記述書、推奨事項。ステップ 4: 情報管理 – すべての評価レポートを CMS に登録し、SKMS に保存する。

ナレッジ管理１．ナレッジ管理の「目標」a) アイディアの共有、経験、情報、観点の共有、情報に基づいた決定をすること、b) 新たにナレッジを発見しなければならない必要性を少なくし、効率よく、信頼性があり安全なナレッジ、情報、データをサービスライフサイクル全体を通して利用することにより、マネジメントの意思決定の品質を改善することを目標とすることを目標とする。それにより、サービス品質を改善し、顧客満足度が向上し、サービスコストが削減され、スタッフが共通の認識を持つ。２．DIKW

Data – 個々の事実の集まりが “データ”　例）Oracleベースの業務アプリケーションのインシデントがユーザにより起票された日時Information – データを意味のあるものにしたものが ”情報”であり、情報はコンテンツに保存される。　

例）Oracle のアプリケーション管理機能にエスカレーションされた、問題の累積未クローズ件数。Knowledge　 – 個人の経験、アイディアから昇化したものを統合すると別のナレッジになる。例）Oracleベースの業務アプリケーションの問題は、Oracleチーム・キューにアサインするが、John さんにリ・アサインされた場合のみ、すぐにワークアラウンドが発見されると気がついた。John さんは、知識が豊富らしい。Wisdom – ナレッジを活用し、十分な情報に基づいた正しい意思決定により、有用な常識的判断ができ、”知恵”になる。例）Oracleチームに、当面の間、全ての問題に関し、John さんと情報共有するようにしてもらうよう提案するとよいのではという知恵が生まれた。Oracleチームは、John さんからトレーニングを受けることになり、その後の問題解決がスムーズにいくようになった。

３．ナレッジ管理の「事業に対する価値」


次のものが、ナレッジ管理の利点となり、事業に対する価値となる。a)法的要件、全社の方針、職業倫理など、その他の要件への適合、b)組織が簡単に利用できる形になっているもの、c)最新の完全かつ有効なナレッジ、d)

必要な人が、必要なときに、入手できるナレッジ、e)必要に応じたナレッジの廃棄。また、ナレッジ管理は、サービスの管理、および提供に必要な”ナレッジ、情報、データ”への、コントロールされた安全なアクセスを提供することにより、サービスライフサイクルの全段階に価値をもたらし、事業に対する価値となる。

４．CSI におけるナレッジ管理ナレッジ管理は、CSI において、重要な役割を果たす。例えば、サービスライフサイクルの CSI 段階は、ナレッジを得て、実際に何が起きているかを理解でき、知恵を活用できるようにするために、データを取得する。これが、前述の DIKW の構造である。複数の異なる種類のナレッジが集まって、知恵になり、改善についての優れた意思決定につながることがある。ナレッジ管理はあらゆる業務改善のプロセスの柱となり、サービスライフサイクル全段階を通して、関連するプロセスである。

ナレッジ管理プロセスを導入手順1) 方針の決定と上位との合意ガバナンスモデル(SOX法など)、組織変更にともなう変更があるか、資金の調達、ナレッジ管理の方針2) 必要なデータがどこにあるかを知るために、PR と巻き込み

IT スタッフ、ユーザ、サードパーティ、人事部、財務部、ビジネス・ケース、DML、インシデント、AMIS などのデータ。

3) 手順を決める。・組織が有用なナレッジを識別できるよう支援・ナレッジの分類とカテゴライズ・公開のための体系的プロセスをつくる・プロセスとワークフローを通じて、ナレッジにアクセスする


・外部ナレッジの取得（サプライヤやパートナー）・ナレッジのレビュー・更新、消去、アーカイブなどのメンテナンス

4) トレーニングを行なう。5) 必要に応じて、改善する。

第 4 　章 OSA についてOSA（Operational Support & Analysis)「運用サポートと分析」について、以下の通りまとめた。

１．OSAの「機能」と「プロセス」について

(1)機能 ①　サービスデスク (役割)　顧客サービス、顧客満足度の向上。単一窓口による、コミュニケーション、単一の情報源を通じたアクセス性の向上。高品質で、迅速な対応により、顧客のビジネスの生産性向上に貢献する。

②　アプリケーション管理

(役割) 1. アプリケーションの管理に関連する、技術的なナレッジと専門能力の管理人。（注意：アプリケーション開発は行なわない。）技術管理と協力し、IT サービスの設計、テスト、管理、改善に必要なナレッジが把握されていること。2. サービスライフサイクルをサポートする、実際の人的リソースを提供する。技術の設計、構築、移行、運用、開演のために、人的リソースが効果的に訓練され展開されるよう

　にする。③　技術管理 (役割)　 1. IT インフラストラクチャの管理に関連する、技術

的なナレッジと専門能力の管理人。IT サービスの設計、テス


ト、管理、改善に必要なナレッジが把握されていること。2.

サービスライフサイクルをサポートする、実際の人的リソースを提供する。技術の設計、構築、移行、運用、改善のために、人的リソースが効果的に訓練され展開されるようにする。

(2)プロセス ①　インシデント管理②　問題管理③　アクセス管理

イベント管理１．イベント管理の「目標」イベント管理の目的は、ライフサイクル全体を通して、イベントを管理することである。達成目標は次の通りである。CI や IT サービスの管理にとって、重要性のある状態のすべての変更を検出する。イベントに適切なコントロール処置を決定し、これらが適切な機能に伝達されるようにする、多くのサービス・オペレーション・プロセスと運用管理活動の実施のために、トリガを提供する。実際の運用パフォーマンスと動作を、設計標準や SLA と比較する手段を提供する。サービスの確約と報告、サービス改善の基礎を提供する。

２．イベントの３つの分類イベントとは、CI や IT サービスの管理にとって、重要性のある状態のあらゆる変更であり、IT サービス、CI またはモニタリングツールによって生成される通知を通じて認識されるものである。a) 　情報イベント – スケジューリングされた作業負荷が完了した。ユーザがアプリケーションにログオンした。電子メールが受取人に届いた等。** 何も対応がいらないもの。b)警告イベント - サーバのメモリ使用率が、しきい値 5%以内まで達している。トランザクション完了に、しきい値より、20%長い時間がかかっている。** 異常を示しているが、例外ではなく、ただちに対応する必要はないが、注意深くモニタリングする必要があるもの。


c) 　例外イベント – ユーザが不正なパスワードでログオンしようとした。さらなる調査を必要とする、例外を示す異常な状況が発生した。トランザクション処理が終わらない等。** 警告のレベルを超えて、直ちに対応が必要になったもの。

３．イベント管理の課題、重要成功要因、リスク　課題：イベント管理マネージャは、次の課題を解決するよう、努めなければならない。1)必要なツールの購入

のための資金を、コストを正当化して(ROI をもたらす)、調達すること。そのためには、説得力のあるビジネス・ケースを準備し、効果的なイベント管理の利点が、いかにコストを上回るかを説明する。2) 適切なフィルタリリングのレベルを設定し、重要でない、イベントが大量に生成されたり、重要なイベントが手遅れるになるまで検出されないことを未然に防止すること。CSF: CI および IT サービスの管理にとって重要性のある状態の、全ての変更を検出すること。全てのイベントが、報告を受けたり、さらなるコントロール処置を取ったりする必要のある、適切な機能に伝達されること。

　リスク：十分な資金を調達できないこと。適切なフォルタリングのレベルを確保できないこと。必要なモニタリング・エージェントを IT インフラストラクチャ全体に展開することにおいて、推進力を維持できないこと。

１．提供インフラにおける上記理論編２の「イベントの３つの分類」についての例示

a) 　情報イベント – Windows セキュリティパッチの配布が完了した。ユーザが Hyperion Planning アプリケーションにログオンした、ログオフした。b) 警告イベント - サーバのメモリ使用率が、しきい値 5%以内まで達している。トランザクション完了に、先月より、20%長い時間がかかっている。c) 　例外イベント – 許可されていないユーザが、財務アプリケーションにアクセスした。許可されていない PC

がドメインにログオンしようとした。--- 調査したら、SOHOユーザで、ずっと、キャッシュ Windows ログオンで、VPN 接続しており、久しぶりにオフィスに来て、会社の LAN からログオンしようとしたことが原因だった。ホスト名は、一ヶ月以上、ドメインにログオンしていないと自動的に無効化される。

第 4 　章 OSAについて

インシデント管理

１．インシデント管理の「目標」インシデント管理の目的は、通常のサービス運用を可能なかぎり迅速に回復させ、事業運営へのマイナスのインパクトを最小限に抑え、SLA で合意したレベルのサービス品質を維持することである。そのためには、次の目標を達成しなければならない。1) インシデントに対する効率的かつ迅速な、応答、分析、文書化、継続的な管理と報告のために、標準化された手法と手順が使用されるようにする。2) インシデント発生時に迅速に解決し、IT に対する事業の認識を向上させる。3)インシデント管理活動および優先度を、事業の活動および優先度と整合させる。

２．インシデントの一般的な例インシデントとは、IT サービス中断や IT サービスの品質の低下、または IT サービスにまだインパクトを与えていない CI の障害である。例としては、ネットワークが遅い、メールが送信できなくなった等である。これらのインシデントは、イベント管理にて発見できなかった問題が引き起こした、ユーザサイドでのトラブルを、ユーザが、ウェブインターフェイスやサービスデスクを経由して連絡してくることによって、発見されたり、（ネットワークの遅延などは）イベント管理がイベント管理ツールを経由して通知されて、発見されたり、また、技術管理スタッフが発見し、サービスデスクに報告されたりする。ただし、インシデントは、理想的には、イベント監視等により、プロアクティブに回避されなければならず、ユーザからの報告を待つべきではない。全てのインシデントは、正しくカテゴリに分別され、もれなく記録されなければならない。（正確性、完全性の維持）これらは、定期的に、独立した情報源に、監査されなければならない。

３．インシデント管理プロセスの有効性と効率性を測るために測定基準はどのように利用されるか下記測定基準を使用することで、有効性と効率性を計ることができ、顧客満足度向上につながる。1) インパクト・コードごとに分類された、インシデントの解決、または回避にかかった平均経過時間2) 単一窓口が、エスカレーションせずに、クローズできたインシデントの割合3) 遠隔地から、電話や遠隔操作にて、クローズできたインシデントの割合


4) 事業にインパクトを与えずに、クローズできたインシデントの割合5) インシデント総数、未処理のインシデント、重大なインシデントの割合6) インシデントのクローズがトリガとなる自動送信による、顧客サーベイのスコア平均7) SLA 達成できなかったインシデントの割合8) インシデント当たりの平均コスト9) 間違ってアサインされたインシデント、間違ったカテゴリが選択されたインシデントの割合

インシデントとワークアラウンド　インシデント：社内ネットワークを誰も使用できないというインシデントが発生した。その結果、誰も

メールにも、業務アプリケーションにもアクセスできなくなった。優先度: 1 　 (インパクト：高、緊急度：高)　 SLA: 　 2時間以内

　ワークアラウンド：いつも案内しているように、貸与しているスマートフォンにて、テザリングし、RSA

ソフトウェア VPN トークンで、VPN 接続することにより、社内ネットワークリソースを使用してもらった。そのおかげで、業務ダウンタイムは、10分程度ですんだ。その間に、技術管理が、ISP に連絡したり、スイッチを確認するなどして、社内ネットワークを復旧させた。インシデント・レコードのクローズまでは、2時間だった。

根本原因: 　 KEDB にある通り、ISP の回線の問題であった。問題レコードは、既知の問題で、ISP の問題なので、元々レコードが存在しており、新たには起票していないが、今回のインシデント・レコードを、以前の問題レコードに紐づけておいた。


要求実現１．要求実現の「目標」ユーザからの全てのサービス要求のライフサイクルを管理することに責任を負うことを目標とする。効率的、かつ専門的に処理することによって、顧客満足度を維持する。標準サービスを要求したり、利用するためのチャネルを、ユーザに提供する。サービスの可用性やサービスを受ける手順に関する情報を、ユーザに提供する。ソフトウェア・ライセンスなど、要求された標準サービスのコンポーネントをソーシング、および提供する。一般的な情報、苦情、またはコメントに対応することを目的とする。

２．サービス要求ユーザからサービスデスクに課される、様々な種類の、数多くの要求のこと。インシデントとして管理している会社もあるが、リクエストとして管理している会社もある。a) 　単純な情報提供 – サービスデスクは何時まで受け付けていますか？等、b) 　問い合わせレベルのもの – MS Excel の一斉ヴァージョン・アップはいつ頃、

　行なわれますか？等 c) 低リスクで、低コストの小さな変更要求（=標準の変更） – 同じ部署の退職したユーザが使用していた、Adobe のソフトウェアを自分の PC にインストールしてください等、の３つに分類される。

３．要求実現の事業に対する価値事業スタッフが彼らの生産性やビジネス・サービス、および製品の品質を改善するために利用できる標準サービスに、迅速で効果的にアクセスできるようにする能力。既存サービスまたは、新規サービスへのアクセス要求、および受理に関する、官僚的な要素を効果的に軽減し、それによって、これらのサービス提供にかかるコストを削減する能力。実現機能の集約化によって、要求されたサービスに対するコントロールのレベルを向上させる能力。サプライヤとの交渉の集中化によるコストの削減、またサポートにかかるコストの削減にも役立つという事業価値がある。

サービス要求以下の 4種類のサービス要求がある。1) 単純な情報の要求


①　電球が切れているが、どこに知らせたらいいか②　サービスデスクの営業時間について③　 MS Excel の一斉ヴァージョン・アップはいつ頃、行なわれるか④　 MS Access のインストールしてもらうにはどうしたらいいか

2) 頻度は高いが、低リスクで、低コストの小さな変更要求（=標準の変更）⑤　アプリケーションの追加インストール⑥　デスクトップ機器の再配置⑦　ソフトウェア・ライセンスの購入⑧　 Windows, Unix パスワードのリセット

3) アクセス管理プロセスで手順が決められているもの⑨　　ユーザの役割変更に伴う、アクセス権の付与

4) 事業関係管理など他のプロセスを通過する必要のあるもの⑩　スマートフォンの機種変更

サービス要求に対応する要求実現プロセスの位置づけサービス要求の数が多く、組織の力量が高くないので、はじめは、東京に専門の要求実現グループを置いていたが、コストが予算を超えてしまったので止めた。現在は、要求実現プロセスを、人件費の安価な地域にオフショア・アウトソーシングしており、比較的安定しているので、コストを正当化できている。どんなチームにサービス要求の処理を任せるにせよ、サービス要求が実現されたら、サービスデスクに戻して、ユーザが結果に満足しているかどうかを確認してからクローズする。サービスデスクは、進捗をモニタおよび追跡し、ユーザに情報を与え続けなければならない。


問題管理問題管理の「目標」

インシデントの識別、さらなる調査、文書化、および最終的な除去まで、すべての問題のライフサイクルを管理すること、インシデントおよび問題の事業に対するマイナスのインパクトを最小限に抑え、再発をプロアクティブに防止すること、これを達成するために、インシデントの根本原因を見つけ、既知のエラーを文書化し伝達し、状況を改善する処置を開始するのが目的である。この目的を達成するために、問題およびその結果によるインシデントの発生を防ぐ、再発するインシデントを排除する、防止できないインシデント発生のインパクトを最小限に抑えることを目標とする。

問題管理プロセスとインシデント管理プロセスとの関係両者は密接に関連しているプロセスである。例えば、両者は同じツールを使用しており、カテゴリ化やインパクト、優先度のコード化において、同じルールに基づいて選択していることにより、対応するときに、お互いに効果的、効率的なコミュニケーションをとることができる。また、複数のインシデントがひとつの問題に起因しているケースがあるので、インシデント管理プロセスは、問題管理プロセスに、エスカレーションすることがある。両者は、顧客満足度のために、プロアクティブに活動すべきであることが共通している。また、両者は、変更管理と連携し、IT サービスに影響を与える可能性のあるインシデント下図と期間を削減することで、IT サービスの可用性と品質を向上させるという共通目標がある。

問題への取り組み状況や既知のエラーの管理a) 　問題への取り組み状況問題の可能性があるパターンと傾向を見つけるために、インシデント・レコードを月 1回、レビューする。根本的な問題を含む可能性のある、警告と例外イベントのパターンと傾向を対象として、イベント・ログを週に一回、レビューする。チェックシートを使用して、根本的な問題検出に役立つ運用の品質課題に関するデータを収集し、活用する。b) 既知のエラーの管理インシデントが解決されたかどうかに関わらず、その決定的な原因が特定できていない場合、複数のインシデント・レコード(INC00001-INC00006)から、１つの問題レコード(PR00001)を起票する。ワーク


アラウンドが発見されていたら、既知のエラー・レコードを起票し、KEDB で管理する。（この時点では、問題レコードはオープンのままにしておく。問題レコードの優先度を見直す。）KEDB は、サービス・プロバイダ内で、誰でも、検索できるようにして、類似のインシデントが発行されたら、サービスデスクが、即時解決できるようにしている。問題の根本的な原因が解決されたら、もしくは、コストの関係上、根本的に解決できないと判断された場合は、問題レコードをクローズする。


アクセス管理１．アクセス管理許可されたユーザだけに、特定のサービスを使用する権限を与え、許可されていないユーザに対しては、制限するというプロセスである。つまり、情報セキュリティ管理で定義された CIA の方針と処置を実行するという目的がある。この目的を達成するために、情報セキュリティ管理によって定義された方針と処置に基づいて、サービスへのアクセスを管理する。アクセス権の付与、変更、制限に関する要求に効率的に応答する。サービスへのアクセスを関しし、不適切に使用されないようにすることを目標とする。

２．アクセス管理の適用範囲、とくに可用性管理や情報セキュリティ管理との関係アクセス管理は、可用性管理と情報セキュリティ管理と関係が深く、以下を適用範囲とする。具体的には、アクセス管理は、事実上、情報セキュリティ管理の方針を実行することにより、組織は、組織のデータ、および知的財産の機密性、可用性、および完全性を管理できるようになる。これが、CIA である。アクセス管理では、権限の変更のみを取り扱う。従って、合意されたサービス時間内に、常にこのアクセスが可能であるようにするわけではなく、これは、可用性管理によって実施されることに注意する。また、アクセス管理は、技術管理、およびアプリケーション管理の機能によって実行される機能のひとつで、通常は個別の機能ではない。通常は、IT 運用管理かサービスデスクが調整窓口となっている。

３．アクセス管理の事業上の価値a)　コントロールされたアクセス権限によって、組織が所有する情報の機密性を保持できるようにする。b)　事業顧客が、仕事を効果的に実行する為の、適切なレベルでのアクセス権限を保持するようになる。c)　知識不足のユーザが、株取引システムなど、重要なサービスを使用することによるエラーを減らす。d)　サービスの使用を監視し、サービスの不正使用を追跡する。e)　セキュリティ上、重要である、即時アクセス権無効を実施する。f)　規制要件に対するコンプライアンスを提供および実証する。


アクセス管理プロセス・アクセスの要求

アクセス要求のルールは、要求実現モデルの一部として、文書化され、サービス・カタログにも説明されている。

・検証正当なサービス要求かの判断は、本人からのリクエストではなく、サービスにより、プロセスで定義された適切なマネージャ、部門マネージャ、そのアプリケーション管理者、人事部、RFC からのリクエストしか受け付けないことで行なう。

・権限の提供アクセス管理は、誰がアクセス権を持つのかを決定できない。SS および、SD で定義された、方針と規制を実行する役割をもつだけである。自動化されることが理想であり、実際、弊社では、途中から、入社リクエスト、退社リクエストをトリガとし、Windows アカウントの自動生成、自動無効化されるようになり、人為的なミスが無くなった。

・アクセスの記録と追跡アクセス管理は、提供した権限が適切に使用されていることを確認する責任がある。すべての技術管理機能、アプリケーション管理機能、サービスオペレーション機能のモニタリング活動に、アクセス・モニタリングも含めなければならない。例外のアクセスがあるならば、インシデントとして処理されるべきである。法的な操作が必要になった際は、アクセス日時や内容を証拠として提出する。

・権限の制限アクセスのレベル、時間、または期間の短縮で、権限を制限する。例えば、Boise Potato 社では、契約社員のアカウントは、契約期間によらず、一律、90日で自動的に無効になるように自動化している。有効にするには、部門長からの事前申請が必要になるが、90日ごとに何度も繰り返し申請する必要があるなど、制限を強化している。


サービスデスク１．サービスデスクとはサービスデスクは、ユーザと直接コミュニケーションを立場であることから、IT 組織全体の印象を決める、極めて重要な部分であり、ユーザの単一窓口となる。彼らは、インシデントの対応、問題管理へのエスカレーション、サービス要求の管理、質問への回答の他、顧客の変更要求、保守契約、ソフトウェア・ライセンス、サービスレベル管理、サービス資産管理および構成管理、可用性管理、IT サービス財務管理、IT サービス継続性管理を提供する。

２．サービスデスクと密接な関係にあるプロセスサービスデスクが処理する、またはエスカレーションする、されてくるので、イベント管理、インシデント管理アクセス管理、問題管理と密接な関係がある。サービスデスクの仕事は、インシデントを扱うことがメインである。インシデントは、ユーザ（ウェブ、メール、電話）、イベント管理からの警告イベント・チケットの起票、技術スタッフのどれかから伝達され、インシデントかどうか切り分けされたものである。アクセスの変更と判断された場合は、アクセス管理を経由して、サービスデスクが処理する。インシデントであれば、サービスデスクが直接対応し、KEDB に既知の問題として存在していれば、ワークアラウンドをユーザに提供する。根本原因の調査が必要なインシデントは、問題管理が取り扱う。

３．サービスデスクの品質を測る測定基準測定することは、健全度、成熟度、効率性、有効性、運営を改善するあらゆる機会をアセスメントする上で重要である。コール総数の測定に関する注意点としては、組織の繁忙期など例外的な時期を基準にしてはいけないことが上げられる。また、コール総数は、サービスの信頼性が低下している時期と、サービスデスクへの信頼性が高まった時期のどちらも増加するので、それだけでは判断してはならない。最後の測定ベースライン以降に、サービスへの信頼性の変化がないか、サービスデスクの改善が行なわれていないかを確認してから判断すべきである。以下に 11 個の測定基準を例示する。1. 一次サポートで解決率を測定基準とする。2. ただし、それだけで判断せず、2次サポートの助けを借りずに解決した割合も測定する、3. 最初のコール中に解決した割合、4.

インシデント解決の平均時間、5. インシデントをエスカレーションするまでの平均時間を測定する。6. また、インシデント対応の平均サービスデスク・コストを測定する。 7. サービスデスクの総コスト/コール数。8. 該当期間の総コスト/合計コール時間（分）。9. SLA で定義された目標時間内に実施された顧客またはユーザに


よる更新の割合。10. 解決されたコールのレビューとクローズの平均時間。11. 平均コール時間の測定基準と組み合わせた、時刻ごと、曜日ごとのコール数の内訳は、スタッフ配置を決める上で不可欠である。

窓口業務の機能

日本と中国の単一窓口は、中国の大連で、質問でも、トラブルでも、一括で受け付けている。単一窓口に電話すると、音声ガイダンスで、サポート内容と、話したい言語を選ぶようになっており、サービスデスクの手間が効率化されている。インシデントが受理されると、インシデント・レコード番号を発行してくれて、それを元にしているので、再度、問い合わせた場合、内容を始めから話さなくてもよい。パスワードのリセットは、職員番号と建物名と携帯電話番号を言い、必ず、折り返しの電話に出るかどうかで本人確認をしてから、リセットをしてくれているので情報セキュリティ管理の CIA は問題ないと思うが、折り返しの電話がくるのが、サービスデスクが忙しい場合、1時間待たないといけないのが不満である。アクセス権の申請については、申請データベース経由で、厳重にチェックされている。日本語がうまく伝わらなかったり、折り返しの電話が遅いのは、費用対効果(人件費が、日本の 10分の 1程度で、全員、日本語、英語、中国語対応もできる)の良さから、十分耐えうる、また、時間の経過、トレーニング次第で改善すると、事業顧客は考えている。

第 5 　章 MALCについて

共通機能１．技術管理の機能a） IT インフラストラクチャの管理に関連する、技術的なナレッジと専門能力の管理人。IT サービスの設計、テスト、管理、改善に必要なナレッジが把握され、育成され、洗練されるようにする。b)サービスライフサイクルをサポートする、実際の人的リソースを提供する。技術の設計、構築、移行、運用、改善のために、人的リソースが効果的に訓練され展開されるようにする。戦略として、人的リソースのスキルレベル、利用状況、コストのバランスを確保し、必要な時間に、そのタスクのためだけに委託するか、もしくは、内部の専門スタッフを中央にまとめ、専門家の活用度を高めるかを決める。これは、プロジェクト・チームと問題解決で有益である。c) 他の役割として、IT 運用管理とうまくコミュニケーションをとり、IT 運用手引きを提供することにより、安定的に技術インフラを運用できるようにする。

２．アプリケーション管理の機能a) アプリケーションの管理に関連する、技術的なナレッジと専門能力の管理人として、事業が求めるサービスレベルを満たすアプリケーション提供をしたり、問題管理を支援する。（注意：アプリケーション開発は行なわない。）技術管理と協力し、IT サービスの設計、テスト、管理、改善に必要なナレッジが、把握され、育成され、洗練されるようにする。b) サービスライフサイクルをサポートする、実際の人的リソースを提供する。技術の設計、

　構築、移行、運用、開演のために、人的リソースが効果的に訓練され展開されるようにする。 c ) IT 運用と日々のコミュニケーションをとり、IT 運用管理に、アプリケーションの継続的な運用管理を実施する最前の方法について手順書を提供する。d )アプリケーション管理ライフサイクルを、サービス・ライフ・サイクルに統合する。e )

アプリケーションのトレーニング提供に責任を持つ。

３．IT 運用管理の機能IT サービスを合意されたレベルで提供し、サポートするよう、IT インフラストラクチャを管理し、保守する為に必要となる、継続的な活動と手順を、日々、実行する機能である。具体的には、装置、システム、プロセスが、戦略や計画立案に照らして、実際に稼働または機能しているようにする作業がある。比較的長期にわたって実施され、反復される。技術トレーニングを受けた専門的な技術スタッフによって行なわれる。機器、人的資源への投


資に依存する。IT 運用管理は、IT 運用コントロール(コンソール管理、ジョブ・スケジューリングの管理)と、施設管理(データセンタ、コンピュータ室、復旧拠点の管理)に分類される。技術管理とアプリケーション管理が、IT 運用管理の機能の一部として加わる。

組織における機能（技術管理、アプリケーション管理）の状況

技術管理は、IT インフラストラクチャに変更がある場合、計画立案を支援、テスト、導入を実施、その保守計画を立て、運用管理に実施させる。アプリケーション管理は、Oracleチーム、Citrixチーム、XXチームなど、大きな製品ごとに分かれて、変更計画立案を支援、設計、テスト、導入を実施、その保守計画を立てて、運用管理に実施させる。運用管理は、IT インフラストラクチャの運用活動と、ネットワークの監視、集中化された印刷や電子的な出力すべての収集と配布のための印刷と出力の管理をしている。また、技術管理とアプリケーション管理チームが作成した手順書を元に、保守活動をしている。

第 5 　章 MALC についてMALC (Management Across Life Cycle)「ITサービスマネジメントのライフサイクル」ついて、以下の

通りまとめた。

１．プロバイダの選択は、何に基づいて行うのか？①　提携する事業に関連した実績、能力、信用照会、信用格付け、規模。②　単一のサプライヤと契約するのか、リスク分散するために、マルチソーシングにするのか。③　従属的なサプライヤの位置づけにするのか、連帯責任を追うような、パートナー関係を結ぶのか。④　ITSMツール導入のためのプロジェクトなどの短期的関係か、運用業務のための長期的な関係か。


⑤　ビジネス・ケースを作成し、ROI（投資利益率）とVOI（投資価値）に照らした結果。⑥　顧客満足度、ブランド・イメージ、市場シェア、株価、採算性、規制のインパクトまたは罰則のリスクをアセスメントした結果。⑦　ビジネス・ニーズ、適用範囲などの環境変化に耐えられるかどうか。⑧　ISO20000に認定されている企業がどうか。（共通の用語、フレームワークの理解）

２．システムの構築や ITサービスの調達を行うときに、どのような基準でプロバイダを選定すべきか。

選定時の手順① サプライヤ選定に関して、SWOT分析をする。② ROI, VOI, KPIを明らかにしたビジネス・ケースをサービス・ポートフォリオ管理に提出する。③ ITサービス財務管理が承認し、CFOに申請する。

選定の基準ホスティング・チーム　(独立系アウトソーシング会社 A社)

①サービス・フィーが低いこと。② SLAを遵守してくれること。③ A社のマネージャがスタッフのリソース管理、トレーニング、リポーティングをしてくれること。

ID管理・SACMチーム(独立系アウトソーシング会社 B社)

①サービス・フィーが低いこと。② B社のマネージャがスタッフのリソース管理、トレーニング、リポーティングをしてくれること。


デスクトップサポート・チーム(独立系アウトソーシング会社 C社)

①サービス・フィーが低いこと。② C社の経営状態が健全であること。（ただし、C社倒産などのリスク分散に備え、類似の仕事をA社とB社にも依頼することがある）。③ SLAを遵守してくれること。④ C社のマネージャーがスタッフのリソース管理、トレーニング、リポーティングをしてくれること。⑤英語が話せる日本語ネイティブであること。⑥ソフトスキルがあり、サービス指向が高く、サービス・カルチャ達成の重要性を理解できるスタッフを派遣できること。技術スキルはなくてよい。

サービスデスク・チーム(中国大連市の同法人 D社)

①サービス・フィーが低いこと。② SLAを遵守してくれること。③日本語と英語が話せる、中国人であること。④ソフトスキルがあり、サービス指向が高く、サービス・カルチャ達成の重要性を理解できること。技術スキルは全くなくてよい。

業務アプリケーション開発チーム

（インド法人　E社）

①サービス・フィーが低いこと。②日本語力は問わないが、データベースと会計の専門知識があること。③納期が守れること。④ NDAにサインしてくれること。

プロジェクト管理業務(外資系コンサルティング会社 F社)

①トリリンガルであること。② ServiceNow開発ツールキットの使用、Active　Directory, Hyper-V、会計システムの導入経験、いずれも５年以上であることなど、細かい職務経歴がニーズにマッチしていること。③プロジェクト全体の調整能力があること。

技術管理、アプリケーション管理、全体のサービスマネジメント（自社の正社員）

①サービスマネジメント経験があること。②中枢となる技術について、専門知識が高いこと。②事業戦略を理解していること。③前述の多数のサプライヤからなる多種多様なチームをまとめていく力量があること。 ④顧客の各事業ユニットとの調整窓口となるので、顧客サービス・スキルがあること。


３．組織のＣＩＯに就任した場合、初めにＩＴサービスマネジメントの、どこをどのように改善するか。

① サービスの変更ごとに、ビジネス・ケースを作成させる。 - 事業戦略に沿っているか、ROI がよいかを確認したいため。

② 前述のビジネス・ケースを精査し、新たな投資の優先順位づけをする。 - 例えば、ホスティング・チームも大連オフィスに移行させる（ニアショア・ソーシング戦略）。また、多忙な社員を更に多忙にして疲労させるのではなく、臨時スタッフへの短期的な投資を行うことで、全体の人件費を節減し、浮いたコストにより、ITSMツールの導入に投資し、効率化をはかるため。

③ IT 組織の再構築をする。- 正社員は、マネージャ（とその候補）のみを残して、他は IT 以外の部署に異動させる。残った正社員には、明確なキャリアパス、トレーニング機会、適切な報酬を与えて、士気を高め、正社員同士の積極的なコミュニケーションに重点を置き、事業戦略に沿った業務ができる新たなチームを形成するため。


戦略的変更の管理１．「契約ポートフォリオ」

契約ポートフォリオには、サプライヤ契約にかかわる投資、および対応する利益の分析に使用される財務情報が含まれている。

サプライヤ契約は、特に、組織の再編成、合併、新しいサプライヤの追加の結果、複雑なサプライヤ契約となることがある。この契約を見直すためには、契約ポートフォリオを策定し直さなければならない。サプライヤ契約を合理化することにより、コスト削減と効率性の増大を達成できるので、サプライヤ契約に変更が加えられる前に、それぞれに対応したビジネス・ケースを作成し、契約ポートフォリオに盛り込むことを推奨する。

２．「提供モデル」サービスを設計する際に、サービスをどのような枠組みで提供するかを検討する必要があり、これを

7つのカテゴリに分けたものを提供モデルと呼んでいる。7つのカテゴリ = インソーシング、アウトソーシング、コソーシング、マルチソーシング、BPO、アプ

リケーション・サービス供給、ナレッジ・プロセス・アウトソーシング。インソーシングの長所は、ビジネス・プロセスに精通していること、また、セキュリティのリスクが

低いことであるが、人員を変更するのが難しいので、必要なスキルをすぐには入手できないことである。アウトソーシングの長所は、必要なスキルをすぐに入手できることであるが、他社に委託するためのセキュリティリスクの解決にコストがかかるという短所がある。また、サプライヤに、技術的に頼りすぎて、中枢がうばわれてしまい、情報システム部が空洞化していることが、昨今、問題となっている。

３．ＩＴサービスによる利益を５年後に倍増するビジネスケースの事例

優先順位 1（業界）海外進出日系企業向け監査市場のリーダシップ獲得


A. 序章 IFRS会計士の育成B. 方法と想定事項対象ユーザ:　全会計士

実施時期: 　 2009年会計年度より　組織的背景：業界全体において、日系顧客の囲い込みの動きが活発であ

る。C. 事業へのインパクト ① 既存会計士の IFRS検定トレーニングコスト、IFRS経験有りの会計士

中途採用のヘッドハンティング会社への報酬。1000万円。①　フィリピンと北京での英語、中国語語学研修制度の確立。2005 　年 1000

万円。②　グローバル化への対応をいそぐ日系企業をできるだけ多く、競合他社よりも早く、会計監査の顧客として取り込むことによる収益の獲得。10%増収。③　 2011年までに、既存の外資系企業の会計監査顧客数獲得 10%増加。④ IFRS に付随して、それらの顧客への ServiceNow, Balanced Scorecard,

Enterprise 連結会計ツール導入により、50%の増収。　結果：

　・ ROI は、1800/1450=1 以上になる。　・顧客ロイヤルティ向上のため、マーケティング能力強化につながる。

D. リスクと緊急事態（外部要因）

①　日本政府の解雇規制緩和法案が延期になるリスク。（社内失業者の増大16 　）発生確率 10%

②　 TPP 　交渉失敗のリスク。（人材、サービスの自由貿易）発生確率 80%

⑤ 東京アジアヘッドクォーター特区構想失敗のリスク（これによって、日　系企業が海外進出する必要性が薄れるため）発生確率 90%

⑥ 海外案件の増加により、英語力のない既存社員のモチベーションの低　下。発生確率 99%

16 ただし、ITIL では、解雇は推奨していないので、多部署への異動など、組織変更で対応する可能性もある。


E. 推奨事項 ①　日本の新卒一括採用は、エントリー時までに、US-CPA取得と TOIEC850

点、HSK4級を最低基準とする。②外国人会計士採用時のビザサポートのスピードアップ体制を整える。

(移民弁護士を増員して、2012年 4月までに、ビザ発行まで 6ヶ月から 2

ヶ月に短縮)

④ ITエンジニアの採用方式、研修も、事業顧客の制度に合わせてもらうよう、経営層に推薦してもうらよう、推奨する。

⑤ 全てのリスクを完全に管理すること。優先順位 2（戦略的）競争力のある製品の導入A. 序章（事業目標の提示）日系企業顧客への ServiceNow などの ITSMツールの導入、開発による収

益の増加。B. 方法と想定事項（ビジネス・ケースの境界定義）

対象顧客:　業界問わず日系の大企業（選択と集中により、中小は対象外）実施時期: 　 2005年から

　組織的背景：日本ではまだまだ ITSMツールが浸透していないので、在日外資系市場にて、経験豊富な弊社が、独占状態をキープしているが、今後の市場規模は不透明である。

C. 事業へのインパクト　(財務的、および財務以外の結果)

① ServiceNow などの ITSMツール開発経験者の中途採用において、人材会社に支払う報酬 1000万円(200万円 x 5名)。

　新人外部講習： 80万円 x 5 　名新規ソフトウェア・ライセンス購入： 10万 x　 5名合計投資額: 1450万円②　グローバル化への対応をいそぐ日系企業をできるだけ多く取り込むことによる収益の獲得。前年比 30%増 (1000万円)

③ 付随して、それらの顧客への Balanced Scorecard, Enterpriseツールの導入による増収。前年比 50%増 (800万円)


　結果：　・ ROI は、1800/1450=1 以上になる。　・顧客ロイヤルティ向上のため、マーケティング能力強化につながる。

D. リスクと緊急事態（別の結果が発生する確率）

①　 2012年ごろから日系販売代理店の台頭。（だが、他社には、導入経験のあるエンジニアはほとんどいない）発生確率 10%

②　 2013年以降、外資 ITSMツール・メーカーが日本支社を持つようになり、直接、サポートするようになること。発生確率 100%

⑦ 高度人材の働き方の多様化がすすみ、顧客内部の中途採用の人間や短期派遣スタッフが、ITSMツールを設計、開発、教育するようになり、弊社へのアウトソースが不要になりつつこと。発生確率: 10%

⑧ 需要管理が失敗し、受注が予想外に減った場合、社員のモチベーション　低下。発生確率 20%

E. 推奨事項（具体的措置）

①　さらなる東南アジアとの業務委託契約による、価格競争力を強めることを検討する。②　コア社員以外の非正規への置き換えを検討する。③　クラウドソーシングの活用により、安価な労働力を海外に求めることを検討する。クラウドソーシングの場合は、法案は影響しない。

④ ④　全てのリスクを事前にあらいだす。優先順位 3（財務上）やり直しコストの削減優先順位 4（運用上）開発時間の短縮


リスク管理１．システム移行を行うときに想定されるリスクサービストランジションの管理プロセス全てにおいて、SWOT分析が SMART 原則に基づいてなされていないために、ROI、VOIが明確にならず、事業への価値が曖昧になる。

① システム移行時に、変更ごとに、ビジネス・ケースを作成していない結果、ROI、VOIが明確にならず、事業への価値が曖昧になる。

② システム移行に、サービス・ストラテジが関与していないことによる、予算オーバー。サービス・デザインが関与していなかったことによる、キャパシティ不足。サービス・オペレーションが関与していなかったことによる、インシデントの増大。サービスの継続的改善が関与していないことによる、改善機会の喪失。

２．設計活動におけるリスク低減をおこなう取り組み

まず、設計活動におけるリスクは、サービスにおけるパフォーマンスのリスクと、需要のリスクである。顧客は、サービスが顧客の資産のパフォーマンスに有益なインパクトを与えることを期待する（顧客から見たときは、有用性とされる）。そのように設計されているはずのサービスが、有用性において、期待される利点を提供できていないと顧客から判断されるリスクが常に存在する。

パフォーマンス不足は、不十分な設計活動に起因する。不十分な設計活動の大きな理由は、需要のパターンを適切に把握、調節できていないことから起きることがある。設計活動におけるリスク低減は、需要パターンの急な変更に耐えられるだけの柔軟性をいかにもたせられるかにかかっている。

３．内部統制機能の一つである職務の分離について、あなたの所属する組織の適当な管理を例にして説明しなさい。（実践編）

①　ビジネス・プロセスと企業会計業務の透明性と説明責任を果たすことを目的とした、SOX 法に基づいて、財務レポートを作成したビジネス・プロセスが正しいこと、また、正しい ITサービスマネジメント・プロセスにより、適切にアカウントが削除されたかなどの監査を、外部の専門機関が行なっており、我々は、アカウント・データなどを、監査人に、言われた通り、プリントアウトして、提出するだけである。


②　技術アーキテクトは、運用チームが管理しているインシデント・データにアクセスできないようになっている、IT運用チームは、本番の人事データベースと経理データベースにはアクセスできないようになっているなど、同じ会社に所属していても、アクセスできるデータは異なり、職務が分離されている。


ＩＴサービスマネジメントの企画と実現１．継続的サービス改善（ＣＳ I）段階におけるＰＤＣＡデミングサイクルは、全てのサービスライフサイクルにおいて、IT サービス品質の向上につながるが、特に、CSI の段階で効果的である。計画、実施、点検、処置のデミングサイクルのサークルは、時間の経過とともに、IT

サービス品質の成熟度レベルを上げていき、事業と IT の整合に向かって、坂を上がっていくべきである（転がり落ちてはいけない）。デミングサイクルの最終目的は、着実で継続した改善である。

策定手順：ステップ 1. サービス・ポートフィリオ管理が作成した、ビジネス・ケースを確認する。優先順位 1（運用）業務効率生の改善A. 　序章（事業目標） Windows7 移行、ハードウェア向上の結果、生産性が 80&増す。B. 方法と想定事項（ビジネス・ケースの境界定義）

対象ユーザ:　全社員（契約社員、派遣社員を除く）実施サイクル: 3年毎開始時期: 2013年 1月終了時期: 2013年 12月

　組織的背景：人員を削減しているので、生産性向上が急務である。2000 人分の PC リフレッシュ・プロジェクトへの投資により、全社員の生産性が上がり、事業収益につなげるようにする必要がある。

C. 事業へのインパクト ①　コスト: 1000万円(注)ハードウェアの購入、テスト環境構築、プロジェクト人件費（固定費除く）含む。②　人件費を 30%削減し、1000万円を捻出する。

　結果：　・ ROI は、1800/1450=1 以上になる。


　・従業員満足度の向上。90%

D. リスクと緊急事態 ①　予定通り完了しなかった場合の情報セキュリティリスク。(マイクロソフトによる、Windows XP のセキュリティパッチ配布が、2014年 4月に終了)

②　 Windows Server 2003 も、セキュリティパッチ配布が、2015年 7月に終了するので、サーバ側の Version も、全サーバに関して、再確認が必要。③ 新しい OS で、特定のアプリケーションの動作に問題が起きると、ビジネ

　ス・プロセスに影響がでるリスク。確率： 10%

④ 新しい OS、新しいハードウェアの使用方法がわからないと、業務効率に支障をきたし、事業収益が下がるリスク。確率: 40%

③　新しい OS の使用方法に慣れるまでの社員のストレスの増加面のフォローアップ。

E. 推奨事項 ①　全てのサービスライフサイクルが協力し、アセットリフレッシュ計画プロジェクトを成功させるよう、プロセスごとに役割を明確にする。②　プロジェクト管理オフィス(PMO)の立上げを行なう。③　古い PC と環境を全て最低 3年間は保存して、災害時やトラブル時の緊急時に備える。④　リスクマネジメントに力を入れて、あらゆるリスクを管理する。

ステップ 2: 以下を含む、サービスデザインパッケージを作成する。① サービス憲章② サービス仕様③ サービス・モデル④ アーキテクチャ設計（制限事項を含む）⑤ リリース、リリースパッケージの定義と設計


⑥ リリース管理および展開管理の計画⑦ サービス受け入れ基準

ステップ 3: [サービスの妥当性確認およびテスト]プロセスに、サービスデザインパッケージを引き渡す。

３．ＣＩＯが、組織で拡充すべきコミュニケーションについて

⑫ 組織の駆け引きや自己利益のためではなく、達成目標の全体的な実現を目指す戦略をつくるためのコミュニケーションの拡充を実施する。

⑬ チームカルチャの養成、メンタリング、コーチングのためのコミュニケーションを拡充する。③　投資が組織の意図する発展と成長に見合うようにするためのコミュニケーションを拡充する。⑭ マネージャ全員に、自らの役割を認識させるコミュニケーションを拡充する。⑮ 投資の優先度付けについてのコミュニケーションを拡充する。⑯ サービスプロバイダの弱みと強み、機会と脅威についてのコミュニケーションを拡充する。⑦　戦略、方針、規則、契約を、評価、方向付け、モニタリングするためのコミュニケーションを拡充する。


組織の挑戦１．プロセスの成熟度の５段階の成熟を現すキーワードCMMI 成熟度モデルには、0.存在しない、1.初期の状態、2. 反復できる状態、3. 定義された状態、4. 管理された状態、5.最適化する状態の 6 段階がある。CMMI(Capability Maturity Model Integration)は、カーネギーメロン大学ソフトウェア工学研究所で開発された、プロセス改善アプローチである。CMMI は、プロジェクト、事業部、または

○○組織全体にわたるプロセス改善や調整の指導に使用される。例えば、管理プロセスの成熟度が 0 や 1 であり、○○組織が、管理プロセスに大きく依存している場合、組織にはかなりのリスクがある。逆に、△△管理プロセス

の成熟度が 5 であるにもかかわらず、△△管理プロセスが、事業にほとんど貢献していない場合は、組織は、リソースと資金を無駄に投資している可能性があると判断できる。

２．プロセスの成熟度をアセスメントする場合の要因（領域）CMMI、ISO/IEC20000 などの国際規格により、能力成熟度をアセスメントすることができる。これは、自組織内の人材、プロセス、技術を含むプロセス環境全ての側面に適用されるばかりでなく、業界全体の基準に照らし合わせて、結果を見ることができる。成熟度のアセスメントにより、受容のカルチャ、プロセス戦略とビジョン、プロセス組織、プロセス・ガバナンス、事業と IT の整合、プロセス報告、プロセス測定基準、意思決定の成熟度を評価できる。

３．CIO が、現状のＩＴサービスの成熟度レベルを１段階上げるために必要な施策①　 IT サービスの成熟度レベルを上げることが、顧客事業の成功に結びつくことを、上級マネジメントに合意をとる。②　アセスメント計画について、サービス・マネージャに、ビジネス・ケースを作成させる。⑤ IT サービス財務管理マネージャに、CMMI外部コンサルタント使用の資金調達をさせる。⑥ サービスレベル管理マネージャが協力して、外部コンサルタントに、客観的に、成熟度をアセスメントさせ

る。⑦ プロセス・ギャップを報告させる。


⑧ CSI マネージャに、利害関係者を巻き込んで、成熟度を改善させる。


サービス評価１．３種類の測定基準① 　技術測定基準：個別のコンポーネントやアプリケーションに対しての、パフォーマンスや可用性を測定

する。② 　プロセス測定基準： CSF と KPI で、サービスマネジメントのプロセスを測定し、プロセスの全体的な健

全性を判定する。KPI は、コンプライアンス　　　　　　4　　　　要素となる、　　1)　　サービス品質、　　2)　　パフォーマンス、　　3)　　価値、　　4)　　

プロセスに即しているかどうかに答える指標となる。CSF、KPI測定結果は、CSI 管理表のインプットとなり、サービス全体が継続的に改善されることに貢献される。

③ 　サービス測定基準：顧客体験である、エンドツーエンドのサービスパフォーマンスの指標となる。①の技術測定基準と②のプロセス測定基準は、③のサービス測定基準を算出する場合の、インプットとして使用されるという意味で、この 3種類の測定基準は関連している。

２．ＩＴサービスで設定した測定基準私は、技術測定基準を担当し、Oracle アプリケーション・サーバ、社内有線ネットワーク、無線ネットワーク、VPN サーバ、Exchange サーバ、ファイルサーバ、Blackberry サーバなどの速度やキャパシティのパフォーマンスを測定している。この結果は、ITSMツールにより、自動的にレポート出力され、私が、レポートの複数の受領者たちの要望通りに、必要な分析を加えた表に加工しなおしている(ITIL は、運用レベルのプロセスは、できる限り自動化したほうがよいと言っている)。私のレポートは、プロセス測定基準担当者にとっては、参考程度に閲覧され、サービス測定基準担当者には、エンドツーエンド測定へのインプットとされ、活用される。

３．CIO が、「関わったＩＴサービス」のサービス品質を、さらに経営に役立てるために追加すべきサービス測定基準弊社の戦略的事業部門(SSU)では、バランス・スコアカードを、経営に役立つサービス測定基準として導入している。バランス・スコアカードは、内部プロセス、顧客、学習と成長、財務の 4 つの視点から項目を採

○点し、できるだけ、のバランスがとれるようにする。元々は、事業顧客の経営状態を計る指標であつたが、10年前からは、IT サービス状態の指標としても利用するようになった。それぞれの視点に対して、最終目


標と、KPI ○を定め、定量化した評価をしていくと、のバランスから、組織の強みと弱みを認識でき、改善活動につながる。

おわりに

ITIL 以外の戦略系フレームワーク・技法・ツールの利用目的

① 　 COBIT

ITガバナンスの原則を遵守しており、戦略との整合、価値の提供、資源の管理、リスク管理、および成果の測定の 5 つを網羅している。COBIT は、世界的に認知され採用されている、コントロールに基礎を置く、価値とリスク管理に関するフレームワークで、全般的な ITガバナンス支援を利用目的とする。

② 　 ISO/IEC20000

サービス・プロバイダが、マネージド・サービスを提供するための要件を定義していることを、社外に証明することを利用目的とする。

③ 　 CMMI (Capability Maturity Model Integration)

能力成熟度モデルであり、システム開発のプロセス改善に関するガイドラインとなることを利用目的とする。製品、またはサービスが顧客の期待を確実に満たすようにする。初期の状態、反復できる状態、定義された状態、管理された状態、最適化する状態の 5 つの段階をふんで、プロセスは成熟していく。

④ 　バランス・スコア・カード

1992年にアメリカ人により開発され、顧客の視点、財務の視点、学習と成長の視点、業務プロセスの視点から、業績を評価することを利用目的とする。この 4 つの観点から測定基準を策定し、データを収集し、データを分析することが有益であると提案している。

⑤ 　品質管理組織力を強化することを利用目的とする。自社製品の品質管理だけではなく、IT サービスの品質管理、IT

サービス・プロセスの品質管理などもある。組織が、ISO9000, シックス・シグマ、TQM などの品質管理システムを活用している場合、定期的なレビューとレポート作成によって、定期的に進捗を評価し、合意されたサービス改善の取り組みを推進することができる。

おわりに

⑥　 OSI フレームワーク・ ITILヴァージョン 1 が作成されていたころ、国際標準化機構は、最終的に開放型システム間相互接

続(OSI)フレームワークとなる取り組みを開始した。・ OSI フレームワークの取り組みが対象としていた領域の多くは、ITILチームが対象としていた領域

と同じだったため、両者が多くの同じ題材を取り扱っていた。・組織の異なる者同士が ITIL と OSI フレームワーク両方の用語を使用することがよくあり、これが事態をより混乱させることがある。

　　⑦ 年金

　　年金制度は、高齢期の生活の基本的部分を支える年金を保証する仕組みである。利用方法は以下の通りである。（アーク著MACL の課題回答より引用）

・表 A.1 を使用して、将来支給される年金の 1ポンドの現在価値を調べる。・該当する割引率（または資産コスト）の列と、該当する支払い年数の行を特定する。・その列と行が交差した箇所が、その年数分支払った 1ポンドあたりの年金の現在かちである。・この値と、1回の甲府で受給できると予想されるポンドの額を掛け合わせると、その年金の現在勝

ちがわかる。

⑧　サービスマネジメント成熟度フレームワーク（アーク著MACL の課題回答より引用）・プロセス成熟度フレームワーク(PMF: Process Maturity Framework)は、サービスマネジメント・プロ

セスの成熟度をそれぞれ個別にアセスメントする。・プロセスのレビューでは、次の５つの領域に対するアセスメントを行なう。ヴィジョン、プロセス、人材、技術、カルチャ

　・初期の状態、反復できる状態、定義された状態、管理された状態、最適化する状態の 5 つの段階をふんで、プロセスは成熟していく。

おわりに

　　⑨ シックス・シグマ（アーク著MACL の課題回答より引用）1980年代、モトローラによって開発された、日本の製造業の QC を元にした手法であり、「プロセスのばらつき」を削減することに焦点を当てている。・シックス・シグマは、IT に適したプロセス改善の方法論である。・基本的な達成目標は、100万回の作業実施につき、欠陥数が 3、４個より少なくなるように、エラー

を削減することである。・ IT マネージャは、IT 成果物の様々なばらつき（例えば、変更管理、問題管理、キャパシティ管理な

ど）、および、IT 運用環境内の役割とタスクのさまざまなばらつきを考慮して、シックス・シグマ・レベルの提供を期待することが妥当かどうかを判断しなければならない。

・シックス・シグマは、継続的改善を支援する、データ主導のアプローチである。・シックス・シグマには、2 つの主要な下位方法論がある。

DMAIC 　 - Define, Measure, Analyse, Improve, Control

DMADV - Define, Measure, Analyse, Design, Verify

⑨ プロジェクト管理

・ IT サービスの改善には、PMI が提唱する PMP や、PRICEN2(Project in Controlled Environment v2)などの体系化されたプロジェクトの手法を利用できる。

・体系化されたプロジェクトのアプローチが全ての改善に必要となるわけではないが、多くの改善では、その適用範囲と規模を完全に網羅するために、このアプローチが必要となる。

　・毎回異なる目的を持ち、始期と終期がある活動をいう。

⑪　 TQM

総合的品質管理のこと。Total Quality Management の略。1980年代に、アメリカで開発された、品質管理を経営戦略に適合させた手法であり、その後、日本のボトムアップ型 TQC が、トップダウン型の TQM に置き換わって行くことになる。

おわりに

・総合的品質管理（TQM）は、組織内のすべてのプロセスに、品質に対する意識を組み込むことを狙いとした管理戦略である。

・ TQM の取り組みでは、組織のすべての人々が、プロセス、製品、サービス、および各自の業務を取り巻くカルチャを改善することに参加する。

おわりにITIL EXPERT 資格についてITIL EXPERT試験は、AXELOS17が監修し、EXIN18などが試験実施の総括を委託されており、EXIN

ITIL 中級試験の実施は、日本では、EXIN のパートナーがトレーニングと共に供給している。ITIL EXPERT は、5 つの試験で構成され、受験資格として、ITIL ファウンデーションの合格、および、EXIN 認定機関でのトレーニング受講完了が前提となる。AXELOS が認定したトレーニング機関であれば、EXIN でなくてもよく、オンラインのみのトレーニング、および、受験が可能である。ITIL EXPERT の上位資格として、ITIL

MASTER があり、インタビュー形式で行われる。マレーシアで受験するか、東京に審査員出張可能である。EIXN 以外のトレーニング機関でも、ITIL EXPERT および、ITIL MASTER は、受験は可能である。

ITIL EXPERT 資格1. SOA (Service Offering and Agreement「サービス提案と合意」)

当試験は、ビジネス価値創造に主眼をおき、財務による、資金調達、予算調整からはじまる、戦略的な IT サービスを提案し、事業との合意を得た製品群リストを提案し、事業に価値をもたらす一連の活動を、適切に運用するのに必要な実践知識を、IT マネージャや上級マネジメントの視点で、備えているかを問う内容となっている。SOA のコンテンツとしては、SS コア書籍の中の、「サービス・ポートフィリオ管理」、「IT サービス財務管理」、「需要管理」、「事業関係管理」に加えて、SD コア書籍の「サービス・カタログ管理」、「サービスレベル管理」、「サプライヤ管理」を主体とし、ITIL 中級レベルの包括的な応用能力がつくように構成されている。

17 2013年 7月 1日に設立された、ITIL と PRINCE2 認定試験を監修する、英国政府と Captia社のジョイントベンチャー。http://www.axelos.com/IT-Service-Management-ITIL/

18 オランダに本社がある ITIL試験統括を委託されている企業。https://www.exin.com/NL/en/home/

https://www.exin.com/NL/en/home/

http://www.axelos.com/IT-Service-Management-ITIL/

おわりに

2. PPO（Planning, Protection & Operation「計画立案、保護、および最適化」）

当試験は、「サービスデザインパッケージ立案、情報・データの保護、ライフサイクルの最適化」試験である。試験は、IT マネージャや上級マネジメントの視点で、IT サービス・デザインを適切に実践する能力を備えているかを問う。 PPO のコンテンツとしては、SD コア書籍の中の主に、「キャパシティ管理」、「可用性管理」、

「IT サービス継続性管理」、「情報セキュリティ管理」、SS コア書籍の中の主に、「需要管理」を主体とし、SO,

ST, CSI コア書籍の内容も含み、ITIL 中級レベルの包括的な応用能力がつくように構成されている。

3. RCV（Release, Control & Verification「リリース、コントロール、および妥当性」）

当試験は、SOA にて開発されたサービスストラテジの要件を、障害とその後の中断のリスクをコントロールしつつ、いかにサービスオペレーションで効果的に実現するかについての必要な、サービストランジションの実践知識を、IT マネージャや上級マネジメントの視点で、備えているかを問う。 RCV のコンテンツとしては、ST コア書籍の中の主に、「移行計画およびサポート」、「変更管理」、「サービス資産管理および構成管理」、

「リリース管理および展開管理」、「サービスの妥当性確認およびテスト」、「ナレッジ管理」、SO コア書籍の中の「要求実現」を主体とし、ITIL 中級レベルの包括的な応用能力がつくように構成されている。

4. OSA（Operational Support & Analysis「運用サポートと分析」）当試験は、設計、規模、適用範囲、およびサービスレベルの変更に対応しながら、サービス運用の安定性を維持するのに必要な実践知識を、IT マネージャや上級マネジメントの視点で、備えているかを問う。OSA書籍のコンテンツとしては、SO コア書籍の中の、「イベント管理」、「インシデント管理」、「要求実現」、「問題管理」、「アクセス管理」、また、「サービスデスク」、「技術管理」、「アプリケーション管理」、「IT 運用管理」を主体とし、ITIL 中級レベルの包括的な応用能力がつくように構成されている。

5. MALC (Management Across Life Cycle「ITサービスマネジメントのライフサイクル」)

おわりに

当試験は、IT サービスマネジメントのライフサイクル全体を、構築、管理、改善していくための IT マネージャの力量を問う。MALC試験は、ある銀行の合併戦略に伴う、経営拡大と、IT部門統合のシナリオに基づいた各ケーススタディを分析していく形式となっている。MALC は、SOA, PPO, RVC, OSA 全ての試験の合格者のみが受験可能であり、MALC の合格を持ってITIL EXPERT となる。

参考文献第一次資料株式会社アーク著、『すご訳！コア書籍』、東京、株式会社アーク、2013年株式会社アーク著、『ITIL課題』、東京、株式会社アーク、2013年

第二次資料官野厚著、『ITIL 　豆知識』 < http://www.olivenet.co.jp/essay.html >　東京、オリーブネット株式会社、2014年　

　　笹森俊裕・満川一彦著、『IT 　サービスマネジメント教科書 ITIL 　ファンデーションシラバス 2011』、東京、翔泳社、2013年特定非営利活動法人 itSMF Japan著、『IT 　サービスマネジメント事例に学ぶ実践の秘訣』、東京、翔泳社、2013年

　　打川和男著、『図解入門ビジネス ISO20000　 2011 の基本と仕組みがよ〜くわかる本』、東京、秀和システム、2011年

　官乃厚著、『ITIL 　の基礎 ITIL ファンデーション（シラバス 2011試験対応）、東京、株式会社マイナビ、2014

年野村総合研究所システムコンサルティング事業部著、『ITIL 　入門 IT サービスマネジメントの仕組みと活用』、東京、株式会社ソーテック、2012年

http://www.olivenet.co.jp/essay.html

おわりに

itil implementation for boise potato firm

Business