Recommended
More Related Content
Similar to ITIL2011 to ITIL4 transition baseline guidance in Japanese
Similar to ITIL2011 to ITIL4 transition baseline guidance in Japanese (10)
More from Jerimi Soma
More from Jerimi Soma (20)
ITIL2011 to ITIL4 transition baseline guidance in Japanese
- 1. 1 Implementation of ITIL2011 Framework for Boise Potato Firm ～ ITIL 2011レビュー記録 2019年11月4日更新版 〜 はじめに ITILの起源は、英国にて1986年であると言われるた め、30年を超える歴史がある。ITIL4コア書籍オンライ ン版が2019年10月にベータ版として出版されたため、 ITIL2011をふりかえってみる。 ITIL2011との違いは、アジャイル、クラウドコン ピューティング、SIAM、DevOps、AI等が加わることに より、より、現代の実態に即したフレームワークとなっ ていること、ITIL2011で対象であった法務部、財務部な どのIT関連部門のためのフレームワークではなく、マー ケティング部、営業部を含む組織全体、IT以外のサービ ス全体を対象にしたことである。 ITIL2011の各ライフサイクルの「事業に対する価値」 は以下の通りである。 (1)サービスストラテジ (SS) サービス・ライフサイクルの中心、または開始地点と して、組織の達成目標と顧客のニーズを理解すること、 また、財務的観点と技術的観点の両面から、サービスマ ネジメントの方針、指針、プロセスの策定に役立つ基本 原則を提供すること。 (2)サービスデザイン (SD) 事業達成目標を認識し、全体の要件を網羅し、優先度 を考慮し、全ての利害関係者と必要なコミュニケーショ ンをとり、的確なサービスマネジメントの設計、開発を 行うこと。 (3)サービストランジション (ST) リスクを含み、複雑性をもつ、サービスの移行段階に おいて、プログラム管理、プロジェクト管理と明確な協 力関係を持ち、移行に関するリスクをコントロールし、 事業組織全体を、費用対効果高く、確実に、新しい環境 に移行すること。 (4)サービスオペレーション (SO) サービスデザインで戦略的に設計されたサービスデザ インパッケージを引き継いで移行した、サービストラン ジションから、運用を引き継ぐことにより、事業全体の 活 動を、事業の目標にそって、戦略的に、安定的に、支援 していくこと。 (5)継続的サービス改善 (CSI) より良い戦略、設計、移行、運用を目指す。具体的に は、サービス品質を改善し、運用の効率化をすすめ、事 業の継続性を維持し、事業全体の目標にそった形で、 サービス・ライフサイクルを通して、改善活動を計画、 実施すること。 各ライフサイクル共通の用語の意味は以下の通りであ る。 「サービス」 サービスとは、顧客に特定の価値を提供することであ る。それによって、顧客は、直接、失敗のリスクとコス トを負う必要がなく、それらをサービス・プロバイダに 負わせることができ、自らの目標を達成したり、自らの 事業に専念することができるので、業務効率がよくな る。従って、サービス・プロバイダは、リスクやコスト を適切にコントロールする能力を持った、専門家である べきである。サービスの価値は、顧客が決める、顧客が 定義するという性質があるため、最終的には、その価格 でサービスを受けるかどうかは、顧客が決めることにな る。また、価値は変化するので、サービス内容は、常に 変化させなければならない。 「サービスマネジメント」 戦略、設計、移行、運用、継続的改善の5つのライフ サイクルを通して、一定品質のサービス供給が続く確約
- 2. 2 をし、顧客に価値をもたらすプロセスの一連の活動を サービスマネジメントという。一連の活動とは、人材や 能力などのサービス資産をインプットし、4つの機能 （サービスデスク、運用管理、技術管理、アプリケー ション管理）を使用して、26個のプロセス（変更管 理、ナレッジ管理など）をコントロール、変換し、顧客 に成果をアウトプットすることである。その価値、成果 とは、求めているパフォーマンスが実現されること、ま たは、実現のための制約がないことなどの有用性と、十 分な可用性、キャパシティ、継続性、セキュリティの全 てがある状態の保証の二つが存在することである。 「プロセス」 プロセスは、特定の目的を達成するための一連の定義 をした活動のことである。プロセスは、測定するもので あり、プロセス・マネージャは、プロセスのコスト、品 質を測定したいと考え、プロセス実務者は、期間と生産 性の測定をしたいと考えるという違いがある。プロセス の仕組みは、データなどのトリガを受けて、プロセスが 一連の活動を行い、その成果をアウトプットとして、顧 客、または利害関係者に提供する。その成果のデータ が、再び、トリガとなり、プロセス→成果となることを 繰り返し、閉ループとなる。これは、パフォーマンス駆 動型と呼ばれ、閉ループする度に内容が適切に変化して いく。つまり、プロセスは、継続性、反復性、改善性が ある。また、プロセスは、特定の結果が必ずあるため、 完了した数を数えられる。それに対して、機能は、完了 した数を数えられないという性質がある。 「機能」 機能は、サービス資産（つちかったナレッジ、人材、 使用するツール）を使用して、プロセスを実施する。機 能は、組織の構成単位であり、あるプロセスの実施に専 念する一連の活動を行い、特定の成果を出すことに責任 を負っている。つまり、機能は、パフォーマンスを発揮 する、専門的な集団でなければならない。機能には、 RACI(Responsible=実行責任者：一名, Accountable=説 明責任者, Consulted=相談先, Informed=報告先)と呼ばれ る、責任と役割が与えられている。適切なプロセスがあ れば、機能の生産性が改善される。 第1章 SOAについて SOA(Service Offering and Agreement)「サービス提案と 合意」について、以下の通りまとめた。 価値創出と有用性および保証 ITサービスは、その成果を定性化できても、金銭的な ものに換算（定量化）するのが困難である。ITサービス の価値創造の定量化を試みるのであれば、顧客はどのよ うに価値を認識するかを、「参照値(顧客自らできてい ること) + サービス利用による顧客の利益 - サービス利 用による損失 = サービスの経済的価値」、「サービ スの経済的価値 – 参照値 = サービスの差」でみること ができる。このサービスの差は、サービスプロバイダが 提供できる、（最終的な）有益な「有用性と保証」とな る。（ただし、これらは全て、顧客側の認識と好みと顧 客側が算出した事業成果がベースになっていることに注 意しなければならない。） このサービスの価値を決める有用性とは、パフォーマ ンスがサポートされているか、制約が排除されているか などの、目的への適合性（機能性）のことである。保証 とは、可用性は十分か、キャパシティは十分か、継続性 は十分か、セキュリティは十分かという、使用への適合 性（管理性）のことである。 アプリケーションの開発など、有用性を確認する設計 のフェーズは、単独で実行されてはならず、保証を確認 する運用フェーズが関与すると価値が高くなる。設計 フェーズが終了してから、運用フェーズにはいると、手 戻りの追加コストが発生する場合があり、価値が低く なってしまう。また、有用性と保証の高低は、バランス がとれると複合効果が生まれ、価値を創出する。 サービス・カタログ・マネージャとサービスレベル・マ ネージャの立場 1 組織の駆け引きや自己利益のためではなく、達成 目標の全体的な実現を目指す戦略をつくる。 2 チームカルチャの養成、メンタリング、コーチン グをする。 3 投資が組織の意図する発展と成長に見合うように する。 4 事業へのインパクトが最大となる領域を考え、投 資の優先度付けをする。 5 分析結果に基づき、意思決定する。 6 戦略、方針、規則、契約を、評価、方向付け、モ ニタリングする。 7 妥当性が確認された事業にのみ、投資、支出する ことにより、コスト削減し、ROIを最大化する。
- 3. 3 8 主要プロジェクトやサービス改善に対する投資レ ベルを引き上げる。 9 上級マネジメントから指示を受け、報告をする。 10 顧客のニーズを知り、支援する。 11 他のマネージャを巻き込み、支援する。 サービスデザインが抱えるリスクや課題 課題： マネージャは、次の課題を解決するよう、努め なければならない。 設計されていないサービスやプロセスは、無秩序に発展 していくこと。適切なコントロールなしに発展する場 合、全体的なビジョン、および、ビジネス・ニーズを明 確に理解することなく、発生した環境条件に、リアク ティブに反応するだけのものになる。サービスデザイン に対する、反復的、および斬新的なアプローチが必要で ある。 リスク： サービスデザインがない場合、極めてコスト 高になり、費用対効果がうすい。また、サービスオペ レーション段階等で、障害が発生しやすくなる。リソー スは、無駄に消費され、ビジネス・ニーズに整合されな くなる。どのような改善計画をもっても、達成できたは ずの事業目標は達成されない。 「マネージャの立場」に則った行動 a. マネージャの立場に則った行動 1 事業目標、事業利益、投資の優先順位を常に念頭 において、行動する。 2 上（上級マネジメント）、横（顧客と他のITマ ネージャ）、下（部下、プロセス、技術、ツー ル）のコントロールに同じくらいの比重を置く。 3 サービスマネジメントとは何かを第一に考える。 b. そうでない行動 1 自己利益や保身のために、社内政治活動にはげむ。 2 部下の仕事を細かく監視したり、手伝ったりしてし まい、部下のモチベーションを下げる。 3 事業目標を考えず、目先のプロジェクトをこなす。 ポートフォリオ管理 ポートフォリオついて ポートフォリオとは、投資ポートフォリオと同じで、 顧客のリスクと収益の特性に基づいて調整されるべき で、受容可能なリスク・レベルで利益を最大化する。 従って、条件が変われば、変更が反映され、ポートフォ リオは、更新されるべきである。 ITサービスのポートフォリオには、サービス・ポート フォリオ、アプリケーション・ポートフォリオ、顧客 ポートフォリオ、顧客合意ポートフォリオ、プロジェク ト・ポートフォリオがあるが、ポートフォリオ管理の管 轄内である、サービス・ポートフォリオについてのみ、 以下に説明する。 これは、事業上の価値の観点から、プロバイダが提供 する、稼働中、または展開許可済みサービス(=サービ ス・カタログ)、準備中または開発中のサービス（=パイ プライン）、廃止済みのサービスを説明して、文書化し たものである。これは、様々なプロバイダの競争力を比 較する手段となる。作成の目的は、ITへの投資と事業成 果を実現する能力とのバランスを取るために、適切な サービスを準備するようにすることである。ポートフォ リオの事業に与える価値は、事業がITサービス投資につ いて、健全な意思決定ができるようになることである。 サービス・ポートフォリオが明確にする戦略的な問い 戦略的な問いとは、次の事項である。「サービス・プ ロバイダの長期的な最終目標は何か？それを達成するに は、どのようなサービスが必要か？組織がそれらのサー ビスを実現するには、どのような能力とリソース（リ ソース資産）が必要か？どのようにして、目標を達成す るのか？」これらの質問に満足いくように答えられるに は、上級リーダと、上級アーキテクトなどの対象分野の 専門家の参画が必要になる。このグループは、サービ ス・アーキテクチャ委員会（SAB）と呼ばれ、前述の戦 略的な問いに明確に答えるのを支援し、また、各サービ スの分析を行なうことにより、サービス・ポートフォリ オが明確に、戦略的に、事業に価値をもたらすことにな る。 サービス・ポートフォリオ管理プロセスの活動 1. 活動の開始： 戦略管理、事業関係管理、継続的 サービス改善、その他のサービス・プロセス・マネジメ ント・プロセスがトリガとなる。ここでは例として、継 続的サービス改善を扱う。CSIは、サービス・ポート フォリオ管理に対して、パフォーマンスやサービスレベ ル達成度を改善する機会、新しい機会や現行のサービ
- 4. 4 ス・ポートフォリオ内にあるギャップ、全体的な改善の 機会の3つをインプットとする。 2. 定義する: 求められる事業成果、機会、有用性と保証 の要件、およびサービスそのものを定義するとともに、 これらを達成するための予測される投資を定義すること である。 カタログ管理 カタログ管理の目標 事業顧客に対して、どのようなサービスを提供してい るのか、どのようなサービスが承認され、今後、提供を 受けられるのか、どのサービスが無くなったのか、どの サービスが足りないのかを明確に示す事によって、顧客 がサービスを受けやすくなったり、今後、受けたいサー ビスがわかったりして、事業が発展する。また、顧客 が、サービスについて適切な価格で提供されているかに ついて検討できるようになる。そのカタログは常に最新 の状態であることが前提となる。 サービス・カタログの内容について サービス・カタログには、2種類あり、両方ともサービ ス・ポートフォリオの中に含まれる。 a)技術サービス・カタログであり、事業側には公開され ない、サポートスタッフのためのカタログ 内容は、サービス、ハードウェア、ソフトウェア、ネッ トワーク、アプリケーション、データ、サプライヤなど である。現在提供されているサービス、承認済みだがま だ提供されていないサービスの2種類が記載される。 b)事業サービス・カタログ 顧客に供給することを約束しているあらゆるサービス情 報を一元的に管理し、許可された全ての関係者にその情 報を供給する。内容は、サービス、サポートされている 製品方針、順序づけや要求手順、サポート条件、エント リ・ポイントとエスカレーション、価格設定と課金方法 である。ユーザグループによって、違うビューを使用し て、異なるカタログを見せることも可能である。 サービスレベル管理 サービスレベル管理の目標 SLMの目的は、現在のサービス、および準備中のサー ビスが、合意された達成可能な目標値を満たすようにす ることである。それを達成するためには、次の目標を掲 げる。ITサービスレベルを定義、文書化、合意、モニタ リング、測定、報告、レビューし、適宜、改善措置をと る。事業関係管理と協力して、事業および顧客との関係 を円滑に維持し、適宜、改善していく。ITサービスを測 定可能な目標値で、設定できるようにする。サービス品 質に対しての顧客満足度をモニタリングし、適宜、改善 する。合意されたレベルで品質が維持されていたとして も、常に対費用効果が高く、常に継続的改善の対象とな るようにする。 SLAおよびOLA SLA： ITサービス・プロバイダと事業顧客の間で交わ される合意文書であり、各サービスの目標値と、両者の 責任を定義している。これは、違反したら賠償金を払う ためのものではなく、両者の合意に重点がおかれてい る。SLAは、サービスが提供するべき有用性とその保証 を定義する。SLAは、サービスレベル管理(SLM)によっ て、立案計画、調整、起草、合意、モニタリング、報告 される。 OLA: ITサービス・プロバイダと、それを支援する同じ 組織の別部門（購買、施設管理など）との間で交わされ る合意文書であり、OLAは、支援サービス活動がSLA違 反を引き起こさないように、SLA内の目標値を支える目 標値を定める。 SLAの種類 a) サービスベースのSLA： メール・サービスなどの全 従業員が使用する単一のサービスのSLAを規定し、その サービスのすべてのユーザを対象とする。しかしなが ら、メール・サービスといっても、従業員によっては、 自宅から使用したり、別拠点からVPN接続で使用してい たり、本社の社内LANからアクセスしたりなど、条件が 異なるのに、同じSLAでよいかという問題と、どの使用 方法による代表者が合意書への署名者となるかという問 題がある。サービスレベルの有効性を高めるために、複 数のサービス階級を使用することも検討される。 b) 顧客ベースのSLA： 財務システム、給与システム、 請求システム、メールシステムなど、1つの部門で使用 されるすべてのサービスに対して、単一のSLAを規定す る。顧客側は、1つの文書で要件が満たされるため、好 まれることが多い。署名者は一名ですむため、明快であ る。 c) マルチレベルSLA： 例えば次のような階層構造とな ることがあるがこの限りではない。特定サービスレベル のSLA、顧客レベルのSLAまたは事業部門レベルのSLA 、企業レベルのSLAの組み合わせである。詳細は、上記 a)、b)と同様である。階層の複合SLAとすることによ
- 5. 5 り、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ドコモや、 RIM社などのサプライヤ 1 とも別途、SLAに合意し、法的拘束力のある外部委託契 約にサインした。社内の調達部門とは、Blackberry入手 1 Blackberry端末と、Blackberry Enterprise Serverを開発し ている、カナダのリサーチ・イン・モーション社の略 称。2014年現在は、社名をブランド名と同じ、 Blackberryとしている。2013年2月に、日本市場からの撤 退を発表した。 をユーザがリクエストしてから、14日以内にITに届ける というOLAに合意した。 ステップ2 – サービス・パフォーマンスのSLA達成度のモニタリン グと測定。 ステップ3 – RAGチャートを含んだサービス・レポートの作成。 ステップ4 - サービス・レビューを実施し、セキュリティの脆弱性 が可用性に与えるインパクトを考慮して、Blackberry OSのバージョンアップの検討などをSIPに追加した。 ステップ5 – ケース・クローズがトリガーとなる、インシデント管 理ツールの自動応答サーベイ送信（10段階評価で、満 足度をマークするようになっており、忌憚のない意見を 記載できる、自由形式の欄もある。）を通じて、 Blackberry に関するインシデントのユーザ満足度を調査 した。 需要管理 需要管理とは 12月には、年賀カードがよく売れる、経理部スタッ フは、毎月月末は非常に忙しいなどという、事業顧客の 事業活動パターンやユーザ・プロファイルを把握、予 測、分析し、サービス資産のキャパシティやパフォーマ ンスが過不足なく提供されることを、キャパシティ管理 と共にコントロールしていくプロセスである。需要管理 に固有なプロセスとしては、事業の繁忙期を拡散させ て、特定のサーバへのアクセス量をコントロールするよ うな、奨励、罰則などの戦略によって、需要に影響を与 えることと、事業目標数値達成とIT投資の両方のバラン スをとる方策をさぐることである。 需要管理と一番密接な関係にあるプロセス キャパシティ管理プロセスである。どちらも、事業成 果実現とIT投資の最適化を目標とするが、次の点で異な る。需要管理は、ややビジネスとユーザ寄りのプロセス であり、事業顧客が、自らの顧客に対し、格差課金をも うけ、繁忙期を拡散するなどして、製品需要の調整を図 るのを受けて、ITサービスの需要を予測して、戦略を立 てる。一方、キャパシティ管理は、ITサービスと技術寄 りのプロセスであり、需要管理から受けた需要情報によ り、サービス資産のキャパシティやパフォーマンスが過 不足のないように管理する。このように、キャパシティ 管理の仕事は、需要管理から引き継がれていること、ま
- 6. 6 た、需要があるから、キャパシティが必要になることか らも、これらのプロセスは密接な関係にあると言える。 コアサービスと支援サービス コアサービスとは、例えば、メールの送受信ができる など、顧客にとっての基本的なサービスである。それに 対して、支援サービスとは、顧客の要望に合わせて、ド ミノサーバであったり、Exchangeサーバであったり、 Office 365であったりと選べて、更に、メールの送受信 が、24時間365日可能であることを保証するなど、顧客 にとっての付加価値を提供する、魅力サービスである。 これらの組み合わせは、サービス・パッケージとして顧 客に提示され、サービス・プロバイダは、これをサービ ス・ポートフォリオ管理に組み入れ、購入/導入を検討 する。同時に、このコアサービスと支援サービスの組み 合わせで、顧客の事業活動パターンとユーザ・プロファ イルに適合するか、需要管理にて検討することになる。 需要をコントロールする方法 需要管理が、事業活動パターンとユーザ・プロファイ ルを分析することによって、どのユーザが、どのサービ スを、どの時期（どの時間帯）に、どのくらい必要とす るのかを事前に知る。それによって、ユーザが、期限ま でに入力しないと経費の振込が来月に繰り越されるなど の罰則をもうけて経費精算システムの使用を平準化させ てコントロールすることがある。また、キャパシティ管 理が、事業環境の変化を把握し、新しい技術やサービス 要件をサービス・ポートフォリオに反映し、リソース予 測を正確にすることで、需要に対応することも、需要を コントロールする方法といえる。 提供しているサービスの「事業活動パターン」 Altirisツール・サービスの事業活動パターン Altirisは、ITILフレームワークを強力にサポートする ITSMツールである。使用対象者は、事業顧客の全ユ ユーザ、5000名であり、ITスタッフのみではなく、入 退社の管理上、人事部も利用頻度が高い。インシデント 管理、問題管理、要求実現、アクセス管理その他に使用 される。 要求実現は、イントラネットから、買い物かご方式 で、必要なサービスをサービス・カタログから、ユーザ 自ら選択でき、自動でチケット起票される。 インシデントについては、ユーザがチケットを起票す る。サービスデスクは、フォロー・ザ・サンなので、 Altirisは、24時間月〜金、使用されており、トランザク ションの多い時間帯は、24h、常に、である。 時期的には、毎月月末と、四半期の終わりと、会計年 度末である。それぞれのタイムゾーンごと(APAC, EMEA, USの日中)に、ユーザが1500人ずつなので負荷 分散措置はとっていないが、今後、APAC, EMEA, USの 従業員数のバランスが、崩れることがないよう、需要管 理し、格差課金が設けられなければ、キャパシティ管理 が調整する必要がある。 サプライヤ管理 サプライヤとは サプライヤには、上位から、戦略的サプライヤ、戦術 的サプライヤ、運用上のサプライヤ、コモディティ・サ プライヤの4つに分類される。サプライヤというと、 サービス・プロバイダに従属的に仕事をするというイ メージがある。 戦略的サプライヤは、パートナーとして、サービス・ プロバイダやその事業顧客と対等に、そして長期的にコ ミットメントを交わし、戦略の機密情報を共有し、連帯 責任を負い、共有のリスク、および報酬を得ることがあ るので、サービス・プロバイダの上級マネジメントのレ ベルで管理される。例)アジア規模で、統一されたネッ トワーク構築サービスと運用管理を任せるなど。戦術的 サプライヤは、商業活動および事業とのやり取りが関与 する関係にあり、進行中の改善プログラムを含む定期的 な連絡とパフォーマンス・レビューを伴い、中級マネジ メントによって管理される。例）サーバのハードウェア 故障の解決を提供する保守組織）。 運用上のサプライヤは、運用上の製品または、サービ スを提供し、頻繁ではない定期的な連絡とパフォーマン ス・レビューを伴い、下級マネジメントによって管理さ れる。例）ホスティング・サービスのプロバイダなど。 コモディティ・サプライヤは、比較的用意に代替ソー シングされる、価値の低い、用意に入手できる製品と サービスを提供する。例）プリンタ・カートリッジの提 供。 1つの事柄に対して、複数のサプライヤを使用する と、管理が煩雑になるが、リスクが分散される。単一の サプライヤを使用すると、管理は楽になるが、その分、 依存していることによるリスク、コストが大きくなる。 特に、サービスをサプライヤがカスタマイズしている と、代替サプライヤに移行することは更に困難になるこ とに注意する。
- 7. 7 サプライヤ管理の達成目標 事業顧客または、サービス・プロバイダが投資した価 値に見合う成果を取得すること、契約内容が、事業顧客 のニーズに整合するように管理すること、サービスレベ ル管理プロセスと連携して、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）とは 2
- 8. 8 ROI(Return On Investment)は、ITサービスから得ら れた、事業顧客の利益の増加（=投資の正味利益）を、 事業顧客が支払ったITサービスへの投資合計で割り、 100%を乗じたものである。この結果は、その企業のIT サービスが、プロフィットセンターと見なされるか、コ ストセンターと見なされるかにより、財務諸表の収益に 追加されるか、コストから控除される。ROIは、ITサー ビス投資の価値を定量化するための概念であるが、IT サービスの提供には多くの無形の要素が関与しているた め、この計算式は、単純化されすぎており、潜在的な利 益（顧客ロイヤルティの向上など定性的なもの）を完全 には示していない。 第2章 PPOについて PPO（Planning, Protection & Operation)「計画立案 保護、および最適化」について、以下の通りまとめた。 サービスマネジメントとして優れている部分と劣ってい る部分 (1)優れているサービスマネジメント - 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 365 や、サイボーズのビジネスクラ 3 ウド などの大規模クラウドコンピューティング技術を 4 使用する顧客にとっては、大きな投資になるので、導入 前に費用対効果を確認できるというメリットがある。ま た、この適切な実施は、ITガバナンスにもつながる。 3 Office 365のテクニカルサポートは、24時間365日対応 可能であり、可用性は99.9%を保証し、満たされていな い顧客には、同社規定に基づいた額の返金が行なわれ る。(2014年４月27日現在) 4 サイボーズ社が開発した、メールとイントラネット （ファイルサーバ機能あり）サービス。ユーザ数によっ
- 9. 9 更に優れた取り組みをすることが可能なＰＰＯに含まれ るプロセスと、考えられる効果 上記事業顧客における、情報セキュリティ管理プロセス は、導入段階において、サービスデザインパッケージ (SDP)に適切に組み込まれ、サービストランジションに 渡され、サービス・オペレーションが適切に対応したこ とにより、AD /Exchangeサーバ/ファイルサーバ移行プ ロジェクト時に、障害があったものの、ユーザにとっ て、最小限の被害ですみ、予定通りにプロジェクトが終 了した。 障害内容： 休日のExchangeサーバ移行時に、ディス トリビューションリスト(DL)の一部のデータが失われ た。また、ファイルサーバ移行時に、フォルダセキュリ ティ設定の一部の設定が失われた。 ITの行動: 顧客側の各部門長に、障害情報を速やかに通 知し、顧客サービスカタログに記載されているように、 手順に従って作業し、ヘルプが必要な場合は、サービス デスクに電話するよう依頼し、速やかに、当プロジェク トの他の作業を続行し、翌朝の業務開始時刻までに、全 移行作業を終了させた。 顧客の行動：月曜日の朝、出社した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の分析 については、そのプロセ ス・オーナの責任なので責任範疇外とする。ただし、マ ネージャが、そのプロセス・オーナを兼任する場合はこ の限りではない。また、プロセス・マネージャは拠点ご となどに複数設置することがあるので、お互いに連携を 取り合うこと。 それぞれのマネージャ特有の責任については、下記の通 りである。 (1)可用性マネージャ - 内部サプライヤ、外部サプライ ヤが提供する、コンポーネントの信頼性、保守性、サー
- 10. 10 ビス性の要件の特定に責任を負う。関連するインシデン ト、問題管理を支援する。リスク・アセスメントとリス ク管理を行なう。 (2)ITSCMマネージャ – ビジネス・インパクト分析、リ スク・アセスメントとリスク管理を行なう。災害が発生 した場合、サービス継続性計画を発動して、復旧を指揮 する。そのテスト、事後レビュー、是正措置を指揮す る。復旧サービス・プロバイダとの契約管理をする。 SLAは、顧客というよりは、事業と締結する。 (3)キャパシティ・マネージャ - キャパシティと需要の 関係を調整することについて責任を負う。過去、現在、 将来のコンポーネントの使用率、最大キャパシティ、パ フォーマンスのしきい値、チューニング方法を分析す る。関連するインシデント、問題管理を支援する。 (4)セキュリティ・マネージャ – ITSCMマネージャがビ ジネス・インパクト分析をするのを支援する。関連する インシデント、問題管理を支援する。セキュリティ・リ スク・アセスメントとリスク管理を遂行する。自社のセ キュリティ方針について、顧客とユーザに普及させる。 可用性に関する「課題、CSF、リスク」 (1)課題： サービス・チケッティング・システムの Altiris が、業務時間内に、一週間に2回、5時間程度ダウ 5 ンするか、応答速度が極端に遅くなる。SLAでは、月〜 金（日本の祝日を除く） 9:30 - 17:30 の間、99.99%の 可用性で稼働していること、また、ダウンした場合は Severity2とされ、インシデントチケットが報告されて から、3時間以内に復旧することとなっており、新規導 入してから一年近く、SLA違反状態である。Altirisサー バは米国にあり、技術管理、アプリケーション管理も米 国にある。 [現状] 可用性(%) = 合意済みサービス時間(時間) – 停止時間x 100 = ( 480h /1920h ) x 100 = 25% SLAを下げる方向で、事業顧客と合意をとる必要がある が、このアプリケーションは、IT内でのみで使用される 5 米国サンディエゴ本社のAltiris社が開発した、ITSMソ フトウェア。インシデント管理、問題管理、FAQの管理 が出来る。Altirisと違い、ユーザがチケットを起起票す るインターフェイスはないが、イントラネットと連動さ せ、ユーザからの要求実現リクエスト入力を自動起票さ せることが可能。 ので、顧客にとってはVBFでなく、顧客には間接的な影 響しかないことから、話し合いが先延ばしにされてい る。しかしながら、実際は、ユーザからインシデントの 報告を受けても、サービスデスクがチケットを起票でき ない、技術管理が更新した、既知のエラーのワークアラ ウンドを、サービスデスクが閲覧出来ないことから、 ユーザに対するサービス対応が大幅遅れており、事業顧 客のビジネスにインパクトが大きい。また、サービス・ プロバイダの仕事効率は著しく低下しているが、インパ クトが測定されていない。このように、事業顧客に、 Altirisの高可用性の必要性が認識されていないことによ り、適切な投資、改善活動が行なわれない 。AMISに情 報は統合されているが、AMISが、Altirisの中にあるの で、それを活用することができない。 (2)CSF - SLA上で、Altirisの可用性は、98.12%、信頼性 (MTBSI)は、160時間（1年に12回のダウン）、保守性 (MTRS)は、3時間（1年に12回のダウンで、総停止時間 は36時間）とし、可用性と信頼性が管理されている。 - Altirisの利用に対するビジネス・ニーズの充足。 - 最適なコストで提供されている。 (3)リスク - Altirisは、IT内でしか使用しないITSMツールではある が、事業顧客の事業継続性に欠く事ができないものであ り、ITトラブルが発生した個々のユーザ、全体のトラブ ルの発生時には、Altirisの可用性が低いことによって、 間接的に、事業顧客の全ユーザ、及び、直接的に、サー ビス・プロバイダの全ユーザが影響を受けていること を、上級マネージャが、経営層に説明できていないこ と。 - 上記の理由により、このシステムの可用性プロセスへ のリソースと予算が不足していること。 - 7つのグループ会社に個別に報告しなければならない ことから、報告プロセスに労力を要すること。 キャパシティ管理 キャパシティ管理の「目標」 キャパシティとパフォーマンスに関連する全てのサー ビスが、事業顧客と合意されたレベルで達成されている ことを目標とする。キャパシティへの期待値は常に変化 していき、新しい技術も出てくるので、定期的に計測
- 12. 12 バ ッ ク ・ オ フ ィ ス ・ ス タ ッ フ (U P3 ) 外出 がほとんどない。安定した 処理性のあるPCが必要だが、重 量は気にならない。業務時間中 は高い生産性を必要とするが残 業はしないので、夕方以降や休 日もネットワークが稼働してい ることまでは期待しない。 全てのアプリ ケーションに 対して、社内 LANの応答時 間 5秒以内, ファイ サーバの使用領 一ヶ月 100MB増える。 移 動 の 少 な い 技 術 ス タ ッ フ (U P4 ) オフィスに常駐しており、外出 がほとんどない。ソフトウェア 開発業なので、大量のデータを 頻繁にダウンロードするため、 社内ネットワークの信頼性とパ フォーマンス（応答時間）への 期待値が高い。 全てのアプリ ケーションに 対して、社内 LANの応答時 間 2秒以内, ファイ サーバの使用領 一ヶ月 5GB増える。(S 財 務 管 理 シ ス テ ム (U P5 ) 締め日前の1週間は、応答が悪く なる。安定したトランザクショ ンを実現するため、ネットワー クの速度はあまり気にしない が、ネットワークの高可用性が 必須。 社内LANの応 答時間 5秒以内, VPN接 場合は、10秒 以内。(SLA) 業 務 支 援 プ ロ セ ス - ビジネス・プロセス。ユーザ自 身でインシデントを起票、進捗 管理するシステム。サービスデ スク機能がフォロー・ザ・サン なので、24時間365日、IT、ユー ザともに使用。ITは、AltirisをPC ビルドにも使用している。ま た、人事部と各部門長は、New Hireリクエストに、Altirisを使用 社内LANの応 答時間 2秒以内, VPN接 場合は、5秒 以内。(SLA) Alt iri s (U P6 ) しているため、多くの部署で共 有されている。 可用性管理 1．可用性管理の「目標」 必要とされたときに、全てのITサービスが使用でき （信頼性、保守性、サービス性に問題がないか）、パ フォーマンスよく（キャパシティに問題がないか）、セ キュリティが保たれた状態（安全性に問題がないか）で あることを目標とする。しかしながら、事業顧客が、求 めていない可用性レベルをサービス・プロバイダが設定 し、事業顧客からみて、高すぎる投資が行なわれてはな らず、事業顧客と上級マネージャの合意に基づく、適切 な可用性目標値を持ち、適正価格の投資が行なわれなけ ればならない。 2．「可用性の2つのレベル」 サービス可用性と、コンポーネント可用性の2つのレベ ルに分類される。ユーザ側からみたときに、使用できる か否か（エンドツーエンドという）の観点から、サービ ス提供状態にあるかどうかをサービス可用性という。 ネットワーク、無停電電源装置(UPS)、データセンター の空調、PCなど、ひとつひとつのコンポーネントが停 止しているか否かは、コンポーネント可用性といわれ、 サービス・プロバイダ側からみたときに、必要なものが 使用できるか否かである。コンポーネントのどれかが停 止していれば、サービス可用性に影響がでる可能性があ る。従って、この2つは連動性があり、サービス可用性 が上層で、コンポーネント可用性が下層の2レイヤーと なる。 3．可用性管理の課題、重要成功要因、リスク 課題： 可用性が、顧客の事業、顧客、上級マネジメン トの期待に添う数値であること、変化する可用性の期待 値を管理していき、必要な予算を正当化することが課題 である。マイクロソフト社がOffice 365 のサービスの可 6 6 Office 365のテクニカルサポートは、24時間365日対応 可能であり、可用性は99.9%を保証し、満たされていな い顧客には、同社規定に基づいた額の返金が行なわれ る。http://en.wikipedia.org/wiki/Microsoft_Office_365
- 13. 13 用性を、99.9%と設定しており、満たさない場合は返金 するとうたっていることの影響もあり、当たり前のよう に、高可用性が求められることが多い。しかしながら、 極端な高可用性は不必要な高コストを求めることがある ので、費用対効果が得られない場合があることに注意す る必要がある。もう1つの課題として、様々な技術から の情報が、様々なツールによって異なる形式で管理され ている場合、ひとつのサービスにみえるものの可用性を 管理することは極めて困難であることが挙げられる。例 えば、メールの送受信の可用性は、サーバ・ハードウェ アの可用性、ISPの可用性、社内ネットワークの可用 性、 MS Exchange Serverアプリケーションの可用 性、PCの可用性、PCにインストールされたOutlookの 可用性、セキュリティの可用性の全てが関係しており、 それらは通常、別々の機能により管理されている。一貫 した方法で分析できるよう、AMISに情報を統合するべ きである。 重要成功要因： エンドツーエンドの可用性が改善され たり、非可用性が削減されたり、MTRSが短縮されたり などの結果を導くように、可用性が信頼性と共に適切に 管理されていること。顧客満足度が高い、VBFの可用性 高いなどの結果を導くなど、ビジネス・ニーズを満たし ていること。非可用性により発生したコストを削減した り、タイムリーにシステム・レビューが完了するのを実 現するような、適切に文書化されたSLAが存在すること が、可用性管理のCSFである。 リスク： 事業顧客、上級マネジメントからの理解が得 られず、適正な予算を確保できていないことが、可用性 管理の失敗に繋がる可能性がある。多数のコンポーネン トからの膨大な情報が、整理されていない状態で拡散し ていると、報告プロセスに労力がかかること。エンド ツーエンドの可用性や、事業側からみたニーズを軽視し て、技術のみに焦点があたりやすいこと。 1．インフラの可用性の指標は、どのように決めたらい いか 決め方： 可用性管理プロセス・マネージャが、現在 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 サービス財務管理マネージャとともに、改善をしていか なければならない。 ITサービス継続性管理 1．ITサービス継続性管理の「目標」 経営層の責任範囲である事業継続性管理プロセス全体 を支援すること、また、復旧オプションの選択、導入と リスク軽減手段の策定を目標とする。これは、コンポー ネントの障害から起こる可用性の問題を取り扱う、可用 性管理プロセスに似ているが、それとは影響規模と責任 範囲が異なり、大地震、大火災、刑事事件、情報漏洩な どが起きたときに、SLAで合意されたレベルで、事業を 再開、継続できることを目標としている。そのため、全 ての継続性計画が事業に及ぼすインパクトを、変わりゆ く事業要件に合わせて維持管理されるように、ビジネ ス・インパクト分析(BIA)やリスク・アセスメント、レ ビューを定期的に行なう必要がある。 2．ITサービス継続性管理の上位計画（ＢＣＰ）との関 係 緊急災害時などに、長期間、オフィスが立ち入り禁止 になったり、ITサービス継続性が失われたり、スタッフ が全員仕事に戻れない状況になったりなどで、事業が継 続できなくなったとしたら、経営損失が出ることを経営 層は責任を負う必要がある。従って、事業顧客は、事業 継続性計画(BCP)を策定するBCMマネージャを任命する べきである。しかしながら、BCPの大部分は、ITサービ スやIT環境にまつわることなので、ITSCMマネージャ が、BCP案を元に、自社のITをどのように復旧させるか
- 15. 15 ⑩ 地震の振動により、部門で独自にたてた開発用Unix サーバが物理的に破壊され、開発プログラムの納品が遅 れたため、その顧客との取引契約が解除された。 この事業顧客では、下記のように、ほぼ完全な、「即時 的復旧オプション」を用意しているので、上記のことは 起きない。 IT人員関連： 同じ業務がこなせる人員を、複数の国に配置しているた め、リモートからのサポートや長期出張によるサポート 体制をとることが出来る。 メール関連： スマートフォンから、海外に設置している、 GoodLink サーバ経由、または、Blackberryサーバ経由 7 で、メールの送受信が可能。その地域の電話インフラが ダウンしている場合に備えて、そのスマートフォン・ ハードウェアとキャリアは、どの国の通信方式にも対応 しており、そのまま持って国外に移動することも可能。 アドレス帳は、AD(+ Exchangeサーバ)と同期をしてい るので、いつでも検索可能。 メールサーバがダウンしている場合は、アプリケーショ ン管理機能と技術管理が、24時間365日オンコールで修 復可能。 LAN関連： PCを緊急用アウトラインにケーブルをつなぎかえる か、会社支給のスマートフォンによるテザリングか、 データカードでインターネットに接続し、VPN接続すれ ば回避できる。地域全体のインターネットインフラがダ ウンしている場合は、全ての業務をAPACタイムゾーン の別の支社の社員に業務を分担。もしくは、香港オフィ スか台湾オフィスで出張勤務する。 PC関連: 7 米国Good Technology社の開発した、モバイル・デー タ・ソリューション・ツール。Androidフォンやi-phone とMS Exchange Serverを接続し、メールの送受信が可 能。http://en.wikipedia.org/wiki/Good_Technology 災害等で、PCが全部破壊されている場合は、海外支 社に、古いモデルのPCを全台保管しているので、それ らのPCを最寄りの海外支社から取り寄せ、Altiris ツー ルを使用し、フランス支社からネットワーク経由でPC ビルドする。ローカルデータは、Mozy online backup 8 を使用して、即時、復元可能。HDDロックがかかって しまったPCのローカルデータも、Mozy online backup 経由で、別のPCに復元可能。 ホットライン関連： 地域の電話インフラ全体がダウンしている場合は、他の 国のテクニカルサポート部門で代行可能（地域語対応の 技術社員がいる）。 サーバの物理障害関連： 壊れたサーバは、現地ITが不在の場合、ドイツ支社に空 輸され、DELLの国際ワランティーにより無償で修理さ れ、データはドイツのITによって移行され、数日で使用 可能。 サーバ障害関連： 全ての海外支社のほぼ全てのサーバが、米国本社で、 一括管理されており、二重化されているので、米国本社 以外で起きた共有サーバ障害に関して、データの同期を とる作業は不要である。 情報セキュリティ管理 1． 情報セキュリティにおける「CIA」 Cは、 Confidentiality（機密性）- 情報を知る権限を持つ 人だけに閲覧可能にすることにより、機密性が高い状態 であり、I は、Integrity（完全性）- 情報が完全でかつ正 確で、許可されていない外部からの修正から守られてい ることで、完全性が高い状態であり、A は、Availability （可用性）- 必要なときにすぐに利用可能であるとか、 障害が発生すれば、すぐに復旧できるか、そもそも障害 に対して防衛策があり、可用性が高い状態であること。 かつ、外部の企業との情報交換する場合に、その取引情 報が信頼できるものとなっていること。CIAは、IT技術 的な側面からだけではなく、オフィスへの侵入など物理 8 米国シアトル市にある、EMC社のオンラインバック アップツール。
- 16. 16 的な側面からも、ビジネス・プロセス全体に渡って、保 護されなければならない。 2． 情報セキュリティ管理における課題、重要成功要 因、リスク 課題： 情報セキュリティ委員会が機能していない。な ぜならば、上級マネジメントの支持が得られておらず、 計画立案をしていない。事業顧客は、その重要性を認識 していたとしても、IT（特に、外部サービスプロバイダ の場合）がなんとかしてくれるであろうと考えており、 上級マネジメントとの話し合いがなされていない。たと え、計画立案されていても、プロセス実務者に、その必 要性が十分説明されていない。結果、ユーザは、誰もセ キュリティ規約を守らず、事故が起きてしまってから、 例えば、たった一通のメールの誤送信が起きた場合で も、全社員のリソースを使用して、調査がはじまるもの の、対応手順が確立されていないので、膨大な時間を要 し、事業の継続性が失われる。事業顧客が重要と考える セキュリティの認識が、IT部門と整合性がとれていない ことも課題となる。 重要成功要因： 第一に、事業がセキュリティ妨害か ら保護されており、サービスデスクに報告される違反件 数が少ないこと。上級マネジメントと事業顧客の間で、 事業ニーズと一体化した合意済みの方針があり、ユーザ に、その防止策が浸透していること。プロセス実務者、 ユーザなど組織全体に、繰り返しトレーニングがなされ ていること。セキュリティ手順が、正当化され、適切 で、上級マネジメントに支持されていること。変化して いく環境に応じて、手順とコントロールに関する改善案 が数多くあがるような、改善の仕組みがあること。 リスク： 可用性と堅牢性に対する要件の増加に対応し なければならないリスク。スマートフォン紛失、ウィル ス感染、外部からの侵入など、ユーザの意図しない原因 により、個人情報を外部に流出させてしまうリスク。 ユーザが、意図的に社内情報を外部に持ち出すリスク 。事業顧客側が、ISMに従って行動しないリスクがあ る。将来の事業戦略に対する計画の認識不足や、予算不 足により、効果的にISMが実施できないリスク。 1．情報セキュリティ施策 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 - 不正がないように、ソフトウェア・ライセンスの移行 状態を正確に把握する。 9 訴訟が起きた場合、メールを保存していないと、企業 に不利になることがあるので、Exchange側で、設定して おく。
- 17. 17 c. 情報漏洩保護目的 - PCを鍵のかかる倉庫に保管し、入出庫するときは、 10分程度の一時的な出庫であっても、紙に記録する。 - PCには、唯一のハードディスクパスワードをかけて 配布する。 - メール誤送信を防ぐため、MS Outlook 2010の宛先 オートコンプリート機能はオフにしてから、ユーザに PCを提供し、ユーザにも、オンにしないよう誓約させ る。 - 3回の誤入力パスワードをトリガーとしてアカウン ト・ロックがかかるようにする。 - 全てのパスワードは、可能な限りシステム側（グルー プポリシー等）で強制的に、複雑なものしか設定できな いようにするとともに、規定の日数が経過した場合は、 変更を求めるように設定する。 - 全てのパスワードを紙に書く事は禁止している。 - パスワードやRSA Token などのPINコードを他の 10 ユーザに言う、代行ログオンは本人の許可があっても 100%禁止している。 - スマートフォンやノートPCや、RSA Tokenが手元に ないことに気がついた時点で、ITか情報セキュリティ委 員に電話で報告するよう、ユーザに誓約させる。 - 個人所有PCから、MS OWA 経由でメールサーバに 11 アクセスした場合は、添付ファイルを個人PCに保存し ないよう、誓約させる。 - ユーザ席にあるPCは全て、ケーブルロックするよ う、ユーザに誓約させる。 ウィルス侵入、外部侵入対策目的 - Windows Firewallは、ユーザがオフに出来ないよう、 グレーアウトさせて、PC配布。 - ウィルスはサーバ側で自動検知、駆除するように設 定し、感染アラートを自動リポートする。自動駆除でき 10 RSA社が開発した、安全なVPN接続可能にするシステ ム。http://en.wikipedia.org/wiki/SecurID 11 ブラウザがあれば、どのPCからでも、メール送受信が できるマイクロソフト社のシステム http://en.wikipedia.org/wiki/Outlook_Web_App ていなかったら、ユーザに連絡をとり、PCのリビルド を行なう。 - PC側のMcAfee EPO Agent が、ウィルスを自動検出 12 し、自動駆除出来ずに、警告メッセージが表示された場 合は、ITサービスデスクに速やかに報告させる。 - IMゲートウェイで監視できない、IM 以外は、インス 13 トールして使用してはならない。 - 外部ベンダーが社内で仕事をする場合は、NDAにサイ ンをしてもらう。 - 外部ベンダー用の貸し出しPCは、ドメインにログオ ンできないよう、ローカルログオンに設定し (WirelesSLANを使わせないため)、アウトライン接続し て作業してもらう。 需要管理 1．需要管理 12月には、年賀カードがよく売れる、経理部スタッ フは、毎月月末は非常に忙しいなどという、事業顧客の 事業活動パターンやユーザ・プロファイルを把握、予 測、分析し、サービス資産のキャパシティやパフォーマ ンスが過不足なく提供されることを、キャパシティ管理 と共にコントロールしていくプロセスである。需要管理 に固有なプロセスとしては、事業の繁忙期を拡散させ て、特定のサーバへのアクセス量をコントロールするよ うな、奨励、罰則などの戦略によって、需要に影響を与 えることと、事業目標数値達成とIT投資の両方のバラン スをとる方策をさぐることである。 2．需要管理と一番密接な関係にあるプロセスはどれか キャパシティ管理プロセスである。どちらも、事業成 果実現とIT投資の最適化を目標とするが、次の点で異な る。需要管理は、ややビジネスとユーザ寄りのプロセス であり、事業顧客が、自らの顧客に対し、格差課金をも うけ、繁忙期を拡散するなどして、製品需要の調整を図 るのを受けて、ITサービスの需要を予測して、戦略を立 てる。一方、キャパシティ管理は、ITサービスと技術寄 りのプロセスであり、需要管理から受けた需要情報によ 12 マカフィー社のセキュリティソフトのクライアント ツールhttp://en.wikipedia.org/wiki/McAfee_VirusScan 13 AOL, MS Messengerなどのインスタント・メッセージ ング・システムであり、社外のアカウントは登録できな いようサーバで制限している。2014年4月現在は、 Microsoft Lyncで統一している企業が多い。
- 18. 18 り、サービス資産のキャパシティやパフォーマンスが過 不足のないように管理する。このように、キャパシティ 管理の仕事は、需要管理から引き継がれていること、ま た、需要があるから、キャパシティが必要になることか らも、これらのプロセスは密接な関係にあると言える。 3． コアサービスと支援サービス コアサービスとは、例えば、メールの送受信ができる など、顧客にとっての基本的なサービスである。それに 対して、支援サービスとは、顧客の要望に合わせて、ド ミノサーバであったり、Exchangeサーバであったり、 Office 365であったりと選べて、更に、メールの送受信 が、24時間365日可能であることを保証するなど、顧客 にとっての付加価値を提供する、魅力サービスである。 これらの組み合わせは、サービス・パッケージとして顧 客に提示され、サービス・プロバイダは、これをサービ ス・ポートフォリオ管理に組み入れ、購入/導入を検討 する。同時に、このコアサービスと支援サービスの組み 合わせで、顧客の事業活動パターンとユーザ・プロファ イルに適合するか、需要管理にて検討することになる。 4．需要をコントロールする方法 需要管理が、事業活動パターンとユーザ・プロファイ ルを分析することによって、どのユーザが、どのサービ スを、どの時期（どの時間帯）に、どのくらい必要とす るのかを事前に知る。それによって、ユーザが、期限ま でに入力しないと経費の振込が来月に繰り越されるなど の罰則をもうけて経費精算システムの使用を平準化させ てコントロールすることがある。また、キャパシティ管 理が、事業環境の変化を把握し、新しい技術やサービス 要件をサービス・ポートフォリオに反映し、リソース予 測を正確にすることで、需要に対応することも、需要を コントロールする方法といえる。 1．ビジネスの事業活動パターン パターン：Webタイムシートの入力の締め日が、毎週金 曜日の22:00なので、金曜日の17:25 – 17:35の間に、 7000ユーザが一斉にアクセスし、ユーザから見たパ フォーマンスが落ちる。また、サーバがダウンする可能 性もある。 背景： 金曜日にまとめて入力する人が多く、金曜日の 17:25くらいにならないと、退出時間が不明、また、金 曜日なので、残業する人も少なく、17:35以降に入力さ せることも難しい。月曜日の朝に入力したのでは、締め 日を過ぎており、毎日入力したとしても、金曜日の夕方 も入力しなければならない。 対応策： 毎週木曜日の朝に、7000人に、一斉メール 配信で、「タイムシートの入力締め切り金曜日22:00の お知らせ」を出す事により、パート社員など退社時刻が 予めわかっているユーザには、月〜金の分まで、木曜日 の空いている時間に、入力してもらう事を期待してい る。将来的には、不可分散の措置をとる予定である。 第3章 RCVについて RCV（Release, Control & Verification)「リリース、コン トロール、および妥当性」について、以下の通りまとめ た。 ITILで示している管理プロセスに該当するもの 変更管理プロセス トリガ: IT組織をローカルベースから、ワールドワイ ドベースへ変更して、コスト削減（組織変更） インプット: 米国本社から、ワールドワイドで、OSを ローカル言語から英語に変更するという、サービスポー トフォリオ管理への変更要求。（インパクトが大きい重 大な変更なので、サービスポートフォリオ管理への変更 要求が必須） インターフェイス： 移行の計画立案およびサポート、 変更評価プロセス アウトプット： 許可された変更がアウトプットされ、 移行の計画立案およびサポート管理に渡される。 1．RCVにおいて活動するマネージャやスタッフの役割 (1)サービスの妥当性管理およびテスト ① サービス・テスト・マネージャ テストの中立性を保つために、リソース管理および展 開管理に責任を負う者以外を割り当てなければならな い。SD段階で、テスト条件、テスト・スクリプト、テ スト・データ・セットの設計と計画を支援する。テス ト・リソースを割り当て、テスト方針を遵守させる。リ ソース管理および展開管理が行なったテストを検証す る。テスト環境を管理する。テストの進捗、テスト成果 物、成功率、課題とリスクについての管理レポートの提 供を行なう。 (2)リリース管理および資産管理 ① リリースおよび展開マネージャ
- 19. 19 テストの中立性を保つために、サービスの妥当性確認 およびテストを担当する者以外を割り当てなければなら ない。技術管理やアプリケーション管理などの機能から のリソースを含む、全てのリソースを計画し、調整す る。ツールとプロセスに関する支援を計画、管理する。 変更許可を必要とするあらゆる活動の前段階で、変更許 可管理プロセスを支援する。変更管理、サービス資産管 理と構成管理、妥当性とのインターフェイスの調整をす る。 ② 初期サポートスタッフ 技術管理やアプリケーション管理の機能の要員であ り、パッケージ化と構築の実務者、または、展開の実務 者が割り当てられることが多い。展開から最終的受け入 れまでの期間に、ITサービスと事業機能をサポートする サポート文書を提供する。リリースを受け入れる。初期 の段階のインシデントやエラーの対応を、サービス・オ ペレーションに対して支援する。サービス・オペレー ションへの移行を取り扱う。問題管理を行い、RFCを提 起する。サービス・リスク・アセスメントを行なう。 (3)サービス・ナレッジ管理 1．ナレッジ管理プロセス・オーナ 多くの組織では、同プロセス・マネージャと兼任さ れ、また、サービス資産管理および構成管理の役割と兼 務されている。組織内のナレッジの識別、取得、維持の ための全体的なアーキテクチャを作成する。プロセス戦 略を定義し、プロセス設計を支援する。プロセス文書を 最新の状態に保つ。プロセスの方針と標準を定義する。 コンプライアンス確認のために、定期的に監査を行な う。プロセス戦略をレビューし、変更する。課題に対処 するCSI 管理とそのレビューを行なう。 マネージャの役割 リリース管理および展開マネージャ 概要: Windows XPから、Windows7へのアップグレード に伴う、デバイスドライバ、標準ソフトウェア、セキュ リティパッチのパッケージリリース 役割: 1) リリースと展開の計画立案。Windows XPから Windows7へ移行するに当たり、デバイスドライバを新 OS対応のものにパッケージし直す。リリース・パッ ケージには、手動でのインストール手順書、前ヴァー ジョンからの改良点の文書など複数のリリース・ユニッ トを含める。問題発生時の切り戻しのため、アンインス トールの合否もテスト項目に含める。2)リリースの構 築。ストックホルム、シドニーのパッケージャーに、リ リース・パッケージ作成依頼する。3) 妥当性確認テス ト。担当パッケージャーとコミュニケーションをとりな がら、日本語Windows7上にて、SCCM 経由にて、テ 14 ストPCへのリリース・パッケージをインストールし、 動作テスト手順項目に従って、テストを実施。不具合が あれば、問題チケットを発行し、開発チームにリ・アサ インし、パッケージの改良を行なう。完全性を保護しな がら、新しい機能性を提供できることを確認する。有用 性と保証があることも確認する。3) 確定版メディアラ イブラリに登録するために、変更管理プロセスから許可 を取る。動作テスト手順項目表にて問題項目がなくなっ たら、変更管理プロセスに変更許可依頼する。4) 展 開。受理されたら、SCCM経由で、テスト・デスクトッ プ・イメージングをし、新イメージ全体のテストを実施 する。パイロットユーザ（Early Adaptors）への展開す る。5) SDP通りにサービスを定着させる。 6) サービ スオペレーションに予測されるトラブル等を伝え、引き 継ぐ。 7)レビューとクローズ。パイロットユーザに、 悪い影響がなかったことを確認し、確定版メディアライ ブラリに登録する。Windows7マシン配布済みの全ユー ザ7000人にプッシュ配布し、変更要求チケットをク ローズする。 1．サービス・マネジメントにツールを利用することの 利点 サービス・デザイン・プロセスが、より効率的に機能 するという利点がある。具体的には、効率と効果、弱み と改善の機会を特定し、管理情報を提供する。マネジメ ント・コストを削減し、ITサービスの生産性を向上させ る。ITサービスの品質を向上する。重要なプロセスの集 中化を行い、サービスマネジメントの中核的プロセスの 自動化と統合を行なう。データが集まって、情報とな り、それがナレッジになることで、傾向を明確化できる という利点がある。 2．サービストランジションの課題、重要成功要因、リ スク 課題: STには、IT組織だけでなく、財務、技術、人事な ど、たくさんの人が関わるので、システムが、複雑にな りがちである。多種多様な顧客、つまり、多様な窓口の 管理が必要となる。そのため、調和や統合がほとんどな 14 マイクロソフト社が提供する、ソフトウェア展開、 資産管理システムツール; System Center Configuration Management http://technet.microsoft.com/ja-JP/systemcenter/bb507744. aspx