2005.01 ������� ���������� � � ������� ���������� � ���� ����� ����� ������� ���������� ����� ����� ������� ���������� ����� ����� � �� ����� ��� � � ������� � ������������ 目次 it SMF Japan の本格的な展開に向けて 「ITIL の実装へ向けて ｣ 〜インシデント管理プロセスの整備〜 ニュースレター 2005.01 it SMF Japan 理事 塩田 貞人 4 株式会社アイ・ティ・アール 5 新会員紹介 ソニーグローバルソリューションズ殿 7 ITSM ライブラリ it SMF Netherland サービスカタログの作成 From SERVICEtalk 12 Ask The Experts From SERVICEtalk 14 ファントム爆撃機での体験 From SERVICEtalk 18 ベストプラクティスを目指して From SERVICEtalk 19 翻訳レビュー出版活動のご報告 it SMF Japan 21 it SMF Japan 分科会活動計画・活動状況 it SMF Japan 22 2 9 it SMF Japan の本格的な展開 に向けて 初めて ITIL 本を目にしたのは 1999 年でした。タイで ITIL が発表されたのは 1980 開催されたコンサルタントの会合に参加した折、参加者 年代後半。40 冊以上の冊子から 達が ITIL をべたほめするのです。IT サービスマネジメン なる IT サービスマネジメントの トのバイブルと言ってはばかりません。その当時、すで ベストプラクティスの集大成は V に ITIL マスター資格 (Manager １と呼ばれています。その後、現 s Certificate in IT Service Management) を持つ UK の同僚が、 これだよ とカバン 在の 7 冊の体系にまとめられまし から取り出したのが Change Management でした。A4 サ た。これが ITIL V2 です。ITIL の イズより小さなその本は、ページ数も 50 頁ほどしかなく、 すばらしい側面は、現在でも改訂 バイブルと言うにはほど遠く感じられたものです。帰国後 し、進化しつづけているところです。2005 年は ITIL V3 へ に早速購入しましたが、まわりの反応は、 ん、何それ？ 向けてのプロジェクトがスタートします。2007 年頃には と言うものがほとんどでした。 ITIL V3 のリリースが期待されています。 月日は流れて、今や日本も ITIL 先進国の仲間入りを果 11 月末には、ITIL 書籍の中で唯一未発行であった たそうとしています。ITIL に関連した記事を、月刊誌、業 Business Perspective が出版されました。ITIL フレームワー 界誌をはじめとするメディアでは頻繁に見かけます。ITIL クで最もビジネス寄りに位置づけられる本書は、他の 6 冊 をキーワードとするセミナを開催すれば、集客に期待が持 の ITIL 書籍の基礎の上に成り立ち、これらの書籍のベスト てる状況です。ITIL を学習している、あるいは採用を検討 プラクティスがどのようにビジネス内に拡張、集約されて している企業も少なくはないでしょう。 いるかを教えてくれます。 ITIL Foundation の資格者は増加の一途であり、国内 報道によれば、2004 年 12 月 8 日には国内初の 2000 名〜 3000 名と推測されます。英語圏の中でさえ難関 BS15000 認証企業が 3 社、認証登録したとのことです。 と言われ、しばらくは合格者が出ないのではないかと考え BS15000 認証は it SMF でも認証スキームを提供しており、 られていた ITIL マスター資格者も、すでに 20 名近くまで 今後は国内でも認証獲得の活動が加速されてゆく可能性が 増えています。ITIL の普及が進むほどに、欧米同様に ITIL あります。BS15000 は ISO 化の動きも急ピッチで進められ 資格の有効性が認識され、取得者は増加してゆくことが期 ていて、国内外共に 2005 年は BS15000 の動向から目を離 待されます。 せない状況です。 2004 年の it SMF Japan の活動を振り返って見ましょう。 よく ITIL は野球にたとえて説明されますが、2004 年 日本で NPO（特定非営利団体）として認可され、法人とし は日本の ITIL にとってルーキー・イヤーだったと言えるで て活動をはじめたのが 2003 年の 9 月です。2004 年は設 しょう。野球と同様に、ITIL は実践を伴ってこそ価値が見 立一年目を迎えた NPO にとって、チャレンジの年だったと 出されます。ITIL を実践するメジャー・プレーヤは、現場 言えるでしょう。 で IT サービスマネジメントに関わるすべての方です。実際 主な活動実績をあげますと、セミナー２回開催、年次コ のプレーで観客 ( ステークホルダ ) をうならせるのは 2 年 ンファレンス開催、ニューズレターの発行 3 回、IT サービ 目以降のこれからです。it SMF Japan は会員の皆様と共に、 スマネジメント ITIL 入門の出版などです。そして、12 月 日本における IT サービスマネジメントの向上を目指してゆ には Planning to Implementation IT Service Management きたいと考えています。ご指導ご鞭撻のほど、よろしくお の翻訳 QA チームのキックオフが開催され、2005 年 6 月 願い申し上げます。 の発刊に向けて動き出しています。 塩田 貞夫 it SMF Japan 分科会担当理事 多くの会員参加により運営されている分科会は、2004 年 9 月から新規分科会を含め、4 つの分科会（アセスメン ITIL Foundation/Master 資格者 ト分科会、SLA 分科会、サービスデスク分科会、事例研究 分科会）が活動中です。 インターナショナルの ITIL 動向に目を転じると、こち らも国内に劣らず、話題豊富な年でした。 4 「ITIL の実装へ向けて」 ― インシデント管理プロセスの整備 企業の情報システムを効果的に運用するには、定常的な運 ― セスを、組織横断型で策定している IT 部門は調査対象企業 用業務を手順化、あるいは自動化することで、業務効率を良 の 10% 以下に過ぎない。組織構造上の問題がある場合、イン くすることが求められる。しかし、エンドユーザからの問い フラ要件の増加や環境の複雑化などで IT 部門の人件費が膨ら 合せや障害連絡への対応方法、システム変更の手続き、資産 み、10% から 20% のコスト増を招く可能性があると示唆され の一元管理といった基礎的な定常業務であっても、十分な効 ている。IT 部門は受け身の体質から脱却し、能動的にインシ 率性を確保する IT 部門は少数派であると見られる。定常業務 デント管理を行う必要性に迫られているといえよう。 は、特別意識することなく日常的な維持活動を遂行するとい 国内でもインシデント管理に課題を抱える企業は少なくな う意味で人間の体でいえば自律神経に等しい。他の機能に比 い。これにはサービスデスクの統合が進んでいない、二次サ べて優先的な保護が要求される部位である。ところが、多く ポート組織（運用グループ、開発グループ、ネットワーク・ の企業ではこの優先すべき機能が、対象リソースの増加、ユ グループなど）との連携が円滑に立ち行かないなどのさまざ ーザ要件の増大、システムの複雑化といった諸問題により、 まなケースが見られる。課題を解決困難にしている要因のひ ブラックボックス化する傾向にある。このことは、情報シス とつに、IT 関連プロジェクトを単一組織で管理しきれてい テムの健全性を阻害しており、ひいては非定常的な活動（プ ないケースが見られる。この場合、PC ／オフィス・ツール、 ロジェクト等）へ対しても影響を与えている。 ERP、部門別システムなどにサービスレベルの異なる独立し 定常業務にはさまざまなものがあるが、とりわけ日常性の たヘルプデスクが存在することから、インシデントや問題を 高い業務は ITIL ではサービスサポートの分野に位置付けられ 体系づけて管理することが難しく、新機能のリリースやメン る。サービスサポートには、問題管理、変更管理、リリース テナンス停止の告知も煩雑化する。事業部予算により構築さ 管理などのプロセスがあげられるが、ITIL を活用する国内企 れたシステムであっても、オーナーシップと権限・責務を明 業はこれらのプロセス管理の起点として、特にインシデント 確に定義することで、IT 部門がユーザ窓口を掌握することは 管理に注目すべきである。インシデント管理が適切に行われ 早期に解決すべき課題のひとつといえるだろう。このように、 なければ、その後の問題管理、変更管理などへのエスカレー インシデント管理プロセスを整備するうえでは、役割分担、 ションが立ち行かなくなり、あらゆる業務への悪循環を引き 権限／責任、組織間連携といったキーワードが重要となる。 起こすこととなろう。ここではサービスサポートの初動段階 であるインシデント管理を中心に、その整備のあり方につい て考察する。 インシデント管理プロセスの整備 インシデント管理に求められるのは、インシデントが既知 インシデント管理の現状 のものか未知のものかを診断し、その結果を適切なプロセス へ引渡すことである。インシデント管理の目的は、迅速なサ これまでのインシデント管理は、インシデント ( サービス ービスの回復と、SLA の規定に沿って社内への影響を最小限 の中断、あるいは質の低下をもたらすイベント ) が発生して にとどめることにある ( これに対し、問題管理は問題の解決 から事後対応することが多かった。米 META グループの調査 を目的とする )。インシデントが未知だった場合や、サービス によれば、ネットワーク障害、アプリケーション障害、ハー デスクで診断・対応処理ができないものであった場合は、「問 ドウェア障害など、IT 部門が管理するインシデントの 60% が、 題」として扱われるようになる。このようにインシデントと 実際に何かが起こってからの事後対応となっていることが報 問題を的確に区別している点は ITIL の特徴のひとつといえる 告されている。これは、問題が発生しても各組織が自らの担 だろう。 当するサービスを回復するうえで必要なことしか行わないこ 問題管理プロセスを改善し問題の発生に先手を打つ、攻め とに起因するが、その背景には、多くの IT 部門においてイン のプロセスにできるかどうかは、インシデントを管理する際に シデントを管理するプロセスが確立されていない、あるいは 収集される情報にかかっている。インシデントや問題の追跡に 確立されていても関与組織が連携せず、リソース ( アプリケ は、サービスデスク・ツールを活用するのが一般的であるが、 ーション、ネットワークなど ) ごとに個別管理するという組 サービスデスクとさまざまな運用グループのプロセスやシステ 織構造上の問題が存在する。インシデント／問題管理のプロ ムが連携することで、より能動的な対応が可能となる ( 図１)。 5 インシデント管理プロセスが正式に策定されている IT 部 セスと連携・統合することが求められる。国内でも先進的な 門は全体の 40% から 50% であるが、インシデントの発生を 企業では、インシデント管理をサービスレベル管理と紐付け 事前に抑制し発生回数を減らすために、インシデント管理プ て、定量的な目標管理を実行している。一般的には、管理項 ロセスと問題管理プロセスを適切に連携・統合させていると 目としては、即答率（初回コールにて完了した率）、障害回復 ころは、10% から 20% に過ぎない。2005 年には、IT 運用グ 時間、顧客満足度指数などがあげられるが、即答率だけ見ても、 ループの 50% が自社の問題管理プロセスの見直し ( トレンド 非常に高い企業で 8 割程度、低い場合は 1 割程度と大きなば 分析の強化、根本原因分析の策定、問題回避プロセスの検討 らつきがあるのが現状となっている。計測された数値を元に など ) を行うようになると見られる。 目標管理を行うことは、今後多くの IT 部門が説明責任を果た すうえで有効な手法となろう。 運用改善へ向けてプロセスの定型化を進めるうえでは、ま ず各プロセスを目的に応じて分類・定義することが推奨され る。インシデント管理ではサービスの回復と影響の最小化を 株式会社アイ・ティ・アール／ META グループ 目標とし、そのうえで問題管理、構成管理といった他のプロ シニア・アナリスト 図1 金谷 敏尊 Toshitaka Kanaya インシデント管理のフロー CMDB* 既知のエラー サービス回復 (回避策) ワークアラウンド 詳細の構成情報 インシデント管理 サービスデスク 運用グループ ネットワーク・グループ アプリケーション 開発グループ エンドユーザー インシデントの検知と記録 ? ? インシデントの分類 ? 調査と診断 ? サービスの回復 ? インシデントのクローズ ? インシデントの オーナーシップ 、監視、追跡、コミュニ ケーション インプット 未知のエラー 問題 解決 変更 記録保持／原因追及 サービス要求 ? プロセスへのインシデントの投入 その他関係者・組織 アウトプット ? サービスの回復 - 回避策 - 解決策 * CMDB (Configuration Management Database) ：構成情報を管理する論理的なデータベース インシデントの検知と記録 エラーの発生に伴うインシデントの検知は、サービスデスクや各運用部門で行われる。インシデ ントを最初に発見したのがエンドユーザや運用スタッフであっても、インシデントの第一報がも たらされるのはサービスデスクでなければならない。インシデントが把握されたら、それを記録 する。インシデントを記録することで共有リポジトリで傾向分析を行ったり、関与組織が管理す インシデントの分類 る単独リポジトリでコミュニケーションやエスカレーションを行ったりすることができる。 インシデントの分類を行うことで、それぞれが属するカテゴリ、重要度や深刻さのレベル、社内 に与える影響を把握・追及できる。インシデントの区分により、そこから先の管理プロセスが何 調査と診断 になるかが決まる。 診断には 2 つの段階がある。サービスデスクで診断可能な既知のエラーと、然るべき運用スタッ フに回して診断しなければならない未知のエラーである。インシデントの診断はあくまでもサー ビスの回復が目的であり、問題の解決は問題管理プロセスで行われることになる。 サービスの回復／インシデ インシデントは、サービスデスクのスタッフが最終監査を行い、診断し、将来起こりうるインシ ントのクローズ デント、既知の問題として伝えるべき必要知識、解決までのプロセス、動向分析や変更要求が必 要かどうかなどについて、運用スタッフから集められたすべての関連情報を検証したうえで、ク ローズとなる。 インシデントのオーナーシ インシデントの追跡においては、インシデントにより停止したサービスの回復に努める運用部門 ップ、監視、追跡、コミュ とだけでなく、エンドユーザ・グループともコミュニケーションを図る必要がある。インシデント・ ニケーション マネージャ ( エスカレーション・マネージャ ) は、こうしたコミュニケーションが確実に行われ、 また状況報告がインシデントに適した方法で行われるようにする役割をもつ ( 例えば、ネットワ ーク障害が起こっている時に電子メールで報告すべきではない )。 出典 META グループ 6 会員ご紹介 ソニーグローバルソリューションズ株式会社殿 ソニーグローバルソリューションズ株式会社殿（以降 SGS 殿）はソニー・グループ向けに IT サービスの提供を行う、売り上げ約 633 億円（2003 年度）、従業員約 1000 名の企業です。設立は 1988 年。ソニー・グループへの貢献に全力を上げられている IT/IS のトー タル・ソリューション・プロバイダです。ネットワークサービス事業部の木村氏と林氏にお話を伺いました。 インタビュア：SGS 殿の運用しているシステムについて教え トフォーム」と呼 て下さい。 んでいます。ユー 木村氏：東京と名古屋にデータ・センタがあり、それぞれ ザはハードウェア 1000 台以上のマシンが稼働しています。システムは、一部 を意識せずに「サ メインフレームが残っていますが、UNIX や Windows が主流 ービス」を利用い です。これらのシステムを利用するユーザはグループで数万 ただけるようにな 人を超えていると思います。 っています。「共用 プラットフォーム」 を採用していなけ 木村氏 林氏 インタビュア：最近のシステムのトレンドはどのようになっ れば、今頃はイン ていますか？ フラ管理の負荷はかなり上がっていたのではないでしょうか。 林氏：最近急にというわけではありませんが、オープン化の 波以降、システムが広範囲化すると同時に連携が進むなど、 徐々に複雑度が増しています。24 時間 365 日のサービス稼 インタビュア：ITIL への取り組みをお聞かせ下さい。 働を含めビジネス側からのニーズも多様化しています。その 木村氏：2003 年から Foundation の資格 を取り始めました。 一方で、コスト削減の要求は厳しく求められるという難しい 弊社はもともと、ユーザや顧客に対してシステムではなく「サ 状況です。例えば、ビジネス側の都合を考慮しつつ、センタ ービス」を提供する、という方針がありましたので ITIL に違 に集中化した機器のメンテナンス時間を細かく調整しなけれ 和感を感じませんでした。資格保有者を中心として、まずは ばならないなど、様々なニーズ対応が要求されます。 3 〜 4 名が現場の改善活動を実施、変更管理と構成管理、イ ンシデント管理の一部のプロセスから取り組みました。書籍 木村氏：コスト以外のニーズ、品質に対しては、サービスが をお手本に、できているところとできていないところを見直 利用できて当たり前、さらにお客様のニーズに対する即応性 したのです。変更管理などはもともと仕組みがあって、イン というところもあり、そのプレッシャーも増しています。 シデントのモニタリング、チケッティングなどを行っていた ため、取り組みやすい分野でした。そして、現場での改善活 林氏：ソニーのユーザは、OS まで開発してしまうようなエン 動の発展形として、2004 年 4 月には事業部長の音頭とりの ジニアリング集団なのでリテラシーが高いと思います。また、 もと、ITSM プロジェクトが発足しました。専任のプロジェク 新しいものをどんどん取り入れる文化があります。他の部署 ト・マネージャを配置し、個別プロセスだけでなく、全体を が最新のシステムを採用すると、隣の部署ではさらに新しい どう進めるかという検討を実施、2007 年までの絵を描いてい アーキテクチャを採用する、というような傾向がありました。 ます。 ユニークさを求める一方で、増大するコストの問題が問い正 され、その一つの解として、3 年ほど前に、「共用プラットフ ォーム」の考え方を導入しました。 インタビュア：ITIL に取り組まれて変わったことは？ 林氏：大変な作業でしたが、サービス提供の業務が可視化さ れたことが大きかったと思います。大規模なシステム変更を インタビュア： 「共用プラットフォーム」とは？ 何件行ったかなど、従来に比べて、マネジメントへの報告の 弊社では Web システムに N-Tier のアーキテクチャを採用し 精度が上がっており、マネジメントが的確な問題意識を持て ていますが、この各階層で、例えばスイッチであればこの機 るところにまでなっています。それと、現場で使用される言 種とこの機種といったように、標準の機器やソフトウェアを 語が統一できたことがあります。従来は個々の対応において、 いくつか用意しています。ユーザには、標準の機器やソフト そのチーム内でのみ分かる言語やあうんの呼吸でやりとりし、 ウェアで実現される「サービス」を購入してもらうことを推 隣で似た業務をしていても、同じと認識できない言葉の壁が 奨しています。この標準のプラットフォームを「共用プラッ ありました。現在はチームをまたがっても同じ認識、事実関 7 係で動けるようになっています。さらに、現場の改善活動が のプロセス改善だけでなく、お客様との関係を発展させると 活性化されるようになったことも大きいと思います。現場は ころまで踏み込んだ改善活動へと繋げられればと考えていま どうしても目の前の業務に忙殺されてしまいますが、組織立 す。 ててプロジェクトを行うことで改善の時間をとれるようにな インタビュア：it SMF Japan 参加の経緯と期待を教えてくださ りました。 い。 インタビュア：ITIL を導入するにあたりご苦労された点は？ 林氏：弊社では独自の IT サービスマネジメント（ITSM）へ 木村氏：ITIL の解釈の仕方に人それぞれ意見があり、そうい の取り組みを行っていました。設立当初の ITIL の啓蒙時期で った方と議論する中で、ITIL への理解をさらに進めることも は参加を見送っていましたが、ここにきて ITSM を導入して できました。組織を越えた仕組みの普及や、導入時の工数増 いくユーザ間の交流が始まり、われわれの経験がお役に立つ に対する抵抗なども経験しました。ただ、もともと弊社は「シ こともあるだろう、ということで参画することにしました。 ステム」を提供するのではなく「サービス」を提供するのだ、 最近では事例分科会にも参加して、他の企業の発表を聞いた という観点で業務を行っていたので、導入に大きな混乱はな りと、様々な情報をシェアさせて頂いています。今後、日本 かったように思います。事業部長は「40 年「サービス」を提 のユーザ事例にアクセスできる機会を増やしお互いが切磋琢 供し続けてきた我社にとって、ITIL は特別なものではない！」 磨できる環境を整えていただくことを期待しています。 と常々話しています。 訪問者独り言： システムを提供するのではなく、「サービス」 インタビュア：今後の課題は何でしょうか？ を提供するという組織としてのポリシーをお持ちだった SGS プロセスをいかに定着させるか、改善の手綱をいかにゆるめ 殿。その 40 年にわたる活動が ITSM に出会ってさらに飛躍の ないか、でしょう。また、サービス部門全体として ITSM へ 機会を得たように感じました。ぜひ会員の皆様とナレッジを の認識が深まってきていますので、今後は内部の IT サービス 共有させていただければと思います。 8 ITSM ライブラリ ITIL はもともと公式には UK から出版されましたが、オラ it SMF Netherland ラリとして認識されつつあります。ただし、もちろん ITIL に ンダ人は、出版当初から関与することに非常に熱心でした。 記述してある話題は網羅されています。ITSM ライブラリにお いくつかのオランダの企業が ITIL シリーズの最初の書籍群の いて最も成功した書籍の１冊は、it SMF international の標準 執筆に関与し、 （サービスレベル管理のような）数冊について 書籍である「IT サービスマネジメント− ITIL 入門」です。こ は、オランダ人の著者が執筆しています。このことは、オラ れはすでに日本語に翻訳されています。ITSM ライブラリの主 ンダの企業が、1990 年代初期においてサービスマネジメント な特徴は次の通りです。 のアプローチに対する準備が整っていたという事実を浮かび 上がらせます。 ■重要なマネジメント・フレームワークに関する高品質な出 ところが、UK とオランダには大きな違いがあります。UK 版物 企業はどちらかというと厳密に ITIL に従いましたが、オラン ■出版時、多くの関係者が関与 ダの企業は企業独自の視点から ITIL を活用することができま ■トレーニング手引きや早引きポケットガイドなどの便利な した。つまり、ITIL はオランダの成果物ではなかったので、 書籍により、教育が促進される オランダ企業は ITIL の中の優れたコンポーネントを、彼らが すでに用いていた他のフレームワークと組み合わせることが いずれのケースにおいても登録商標の利用はその所有者に できたのです。それらほかの論理的なフレームワークは数年 許諾されています。 の間活用されていました。1988 年、Maarten Looijen 教授が Delft 大学にて、全世界で初めて IT サービスマネジメントの 教鞭を振りました。他の大学がこれをとりあげる 15 年以上 分野 も前のことです。 これは、オランダの IT マネジメントの専門家が、IT サー ライブラリは５つの分野に分類されています（図１参照） ビスマネジメントに対する独自のアプローチを打ち立てる 1 学習の分野には、非専売のフレームワーム、モデルや理 つの方法でした。さらに彼らは大掛かりな事業を興しました。 論に広く焦点を当てた入門書籍が含まれます。現在のところ、 オランダ企業の認識とプロフェッショナリズムを刺激し、サ ITSM ライブラリでは次の入門書が出版されています。 ービス品質を改善する為、1994 年、オランダ it SMF を立ち 上げたのです。オランダ it SMF は、すでに存在していた UK ■ IT Service Management, an introduction based on ITIL（IT の it SMF を見本にデザインされました。その後、他の各国 サービスマネジメント− ITIL 入門） it SMF が続きました。今や世界中に数多くの it SMF を見るこ ■ Project Management, an introduction based on Prince2 とが出来、強力な国際コミュニティを構築しています。 ■ IT Service Procurement, an introductie based on ISPL オランダが 1990 年代に ITIL を取り上げた際には、独自 のプロセス・モデルを展開し、それらのモデルを出版しはじ IT ガバナンス、品質規格、およびソフトウェア開発標準 めました。無駄な誤解を排除するために、1996 年には共通の に関する書籍が追加される予定です。 用語と定義群を開発し、1997 年にオランダ企業におけるベス この分野の書籍は、本来、説明的であり、その話題の基礎 トプラクティスの包括的な手引きを出版しました。数冊の雑 レベルのトレーニングを受ける読者向けに構想されています。 誌が発刊され、多くのイベントが企画され、そしてナレッジ ITIL 入門は ITIL ファンデーション・コース向けの国際標準と 開発が多くの企業にとってのコア事業となりました。 して活用されていますが、本書は、it SMF International の出 版委員会によって国際標準としての承認もされています。 新しいライブラリ ポケットガイド この状況は、最終的には ITSM ライブラリ、つまり、IT マ ポケットガイドの分野には、（学習分野からの）フレー ネージャに活用されるベストプラクティスのライブラリとマ ムワークや（トピック分野からの）トピックに対する早引き ネジメント手段の開発を導いてきています。このライブラリ 書籍が含まれます。現在のところ、次のポケットガイドは、 は、国際的な IT マネジメントの領域でしっかりと重みを増し ITSM ライブラリの範囲の一部となっています。 てきており、ITIL 範囲外の課題を多く網羅した、IT インフラ ストラクチャ・ライブラリ（ITIL）に対する補完的なライブ ■ IT Service Management, a summary based on ITIL ( オラン 9 ダ ITIL ポケットガイド ) 翻訳 ■ IT Governance, a pocket guide based on COBIT ■ IT Service CMM, a pocket guide 書籍は、対象となる国の要望に応じて多言語で提供され ■ IT Service Management from hell! ています。現在、オランダ語、英語、ドイツ語、フランス語、 スペイン語、ポルトガル語、日本語、中国語、ロシア語が使 BS15000 に関するポケットガイドがまもなく出版されま われています。イタリア語、ハンガリー語、様々なスカンジ す。シックス・シグマ、Prince2、および ISPL のポケットガ ナビア語な、いくつか他の言語について議論に上っています。 イドが追加される予定です。 翻訳は、「Compendium IT Service Management（IT サー ビスマネジメント概要）」の一部である、良く体系化された翻 訳リストに従っています。この翻訳リストは、対象コミュニ ティの現場の専門家により開発され、各国の it SMF と it SMF 開発中の分野 の国際出版委員会（International 他の３つの分野は開発中です。トピックの分野は、フレー s Publication Board）によ り認可されています。リストは ITSM ポータル (http://en.itsm ムワークでは捉える必要はないが重要な課題に関する書籍を portal.net) から無料でダウンロード可能です。 含みます。 IT マネジメントの分野は、IT マネジメントにおいてよく 用いられる手段に関する情報を含みますが、学習分野におけ 管理 るフレームワークよりも遥かに狭い範囲を扱います。この解 説書では、一般的に受け入れられた手段を参照します。例え ITSM ライブラリの書籍は、その同一のレイアウトと形式 ば SLA のテンプレート、サービスカタログのテンプレート、 によって識別可能になっています（図 2 を参照）。各書籍の左 IT バランス・スコアカードなどです。 端には縦のレイアウトで「ITSM 3 番目のケースの分野では、具体的な企業の実践について 記述したものを納めます。その内容は、広い意味で ITSM 上 の図が配置されています。 ITSM の内容は it SMF によって管理されています。it SMF の課題により決定されます。いくつかの「トピック」が 1 つ のケースで網羅されるような方法で納められます。 図１ Library」とあり、書籍のタ イトルは表紙の上にあります。また表紙の下半分には何らか はライブラリの編集長と出版社を任命しています。ITSM ライ ITSM ライブラリの体系 ITSMライブラリ 学習 ポケット ガイド トピック IT マネジメント 手段 ケース 教育目的の 各フレームワーク 入門書 フレームワークと トピックの 早引き書 ITSMのトピック に関する 多様な観点 一つの管理手段 に関する 有益な詳細情報 （ハウ・ツーもの） 実践情報 10 ブラリの書籍は多くの経路で流通しています。ある 図2 版は 1 年に数百から数千冊重ねられています。 成熟度 it SMF オランダがここまでになるには約 10 年を要しまし た。多くの人が関係し、多くの時間が費やされました。it SMF オランダのプロフェッショナリズムは今やオランダ企業にと り非常に重要なものとなっています。彼らは優れたナレッジ 基盤を利用し、サービスを認識する強烈なカルチャをサポー トしています。ITSM ライブラリに続き、it SMF オランダは 17-21 歳の学生を対象とした教育用の出版物の開発を支援し ました。これらすべての努力により、オランダの IT 管理の専 門家は、IT サービスマネジメントの教育を受けて育ち、企業 が組織に新人を採用する際、何の問題も生じなくなるでしょ う。結果として、ITIL ファンデーション・トレーニングの数 は安定していますが、現在は徐々に数が減少しつつあります。 恐らく、現在オランダがいる地点に日本がたどり着くまで には 10 年とはかからないでしょう。日本の皆さんも、日本 の it SMF と日本の企業の助けにより、豊富なナレッジ源を利 用するようになるでしょう。 Jan van Bon,、ITSM ライブラリ編集長 11 サービスカタログの作成 From なぜサービスカタログを作成するのか？ SERVICEtalk して解答を出す必要があります。 ショッピングカタログを眺めるとき、顧客側は自分が理解 ■サービスカタログで達成したいことは何か？ できる言葉で商品説明が行われていると期待しています。一 ■現行サービスを定義したか？定義しているなら、サービス 方、企業側の目的は製品の販売であり、そのためには、製品 は何をベースとし、何のために使用されるのか？ 販売と顧客ロイヤリティの維持の助けとなるような価格や明 ■ IT ビジネス・サービスをどのように定義するのか？ 確かつ端的な説明など、できる限り多くの情報を提供する必 ■プロジェクトの範囲は？ 要があると考えています。ここでは「テクノロジの観点から ■目的が達成できたことは、どのように確認するのか？ のみ IT サービスを提供した場合、IT 顧客はどの程度重要視さ れているのか」を自問することが必要となります。 IT 部門は、ビジネスに焦点を当て、ビジネス・ニーズと 現状把握 IT を理解し連携させることの必要性について認識を深めてい ます。しかし、長時間を要するうえに時には費用がかかるプ サービスマネジメント・ツールには、事業単位、ユーザ、 ロジェクトについて支援や承認を得るのは難しいことも多々 サポート要員に関する豊富な情報が含まれ、この情報があれ あります。プロジェクト開始時点で、ビジネスに焦点を当て ば、組織の全体像および主要プロセス・オーナを描くことが たサービスカタログを作成することによって得られるメリッ できます。 トのすべてが理解されているとは限りませんが、メリットの 例としては以下を挙げることができます。 ビジネス・プロセス ほとんどの組織には明確に定められたビジネス・プロセス ■サービスサポートとデリバリの改善 および手順があり、各部門の日々の業務に関して貴重な情報 ■ IT ビジネス・サービスごとの要件の理解 を提供してくれます。 ■ IT 要件とビジネス要件の連携 エンド・ツー・エンドのビジネス・プロセスが定義されて ■エンド・ツー・エンドの IT ビジネス・サービスに対する深い いれば、事業単位あるいはプロセスの相互依存を理解するこ 理解 とができ、エンド・ツー・エンドの IT ビジネス・サービスを ■エンド・ツー・エンドの IT ビジネス・サービスがなくては、 特定して構築する時間を大幅に短縮することができます。 多くのコアとなるビジネス・プロセスが失敗するという認 識 IT ビジネス・プロセス ■各 IT ビジネス・サービスを使用するビジネス分野とユーザ IT ビジネス・プロセスにより、IT 部門の役割、構成、ワ の特定 ークフローを素早く理解することができます。こうした知識 ■主要 IT ビジネス・サービスの理解 は、IT/ 運用サービスや請負サービスを定義する際の助けとな ■事業部門と IT 部門間の関係改善 ります。 ■ビジネスの観点にもとづいた対話が可能 組織のツールおよびプロセスを分析することで、組織単位 ■ビジネスに焦点を当てたインパクト評価 ごとの運営方法に関する基本知識や現状の基礎はわかります ■ SLA および OLA 構造を導入し維持するためのモデル が、だからといってビジネス側に対するヒアリングを省略し ■サービスにもとづいた原価計算および課金の導入が可能 てもよいというわけではありません。 サービスカタログの構造 プロジェクトの開始 組織の構造にもとづいてサービスカタログの階層的データ モデルを定義することにより、すべての現行および今後のサ プロジェクト開始時点においては、何を達成したいのか、 ービスが遵守すべき基準を設定することができるでしょう。次 プロジェクトを開始するビジネス上の理由を理解することが ページの図１は、サービスカタログ構造の例を示しています。 大切です。プロジェクトの成果 ( 物 ) をよく理解したら、どの 最上位では IT ビジネス・サービスが定義されます。保守 ように目的を達成するのか検討する必要があり、そのために と利用を容易にするため、ここに含まれるのは、少数の親サ は現状を把握しなければなりません。以下のような疑問に対 12 ービスだけです。このモデルでは、コアの IT ビジネス・サー 起こり得る問題 ビス、補助的なコーポレート IT ビジネス・サービス（人事部、 サービスマネジメントの取り組みでは、ほとんど場合、初 財務部など） 、e メールやデスクトップ・サービスなどの補助 期段階で問題に直面するものですが、サービスカタログも例 的な IT ビジネス・サービスの違いを考慮すべきです。 外ではありません。しかし、リスクを理解しておけば、イン それぞれの親サービスには多数のメイン・サービスが含 パクトを軽減したり、完全に排除したりすることができるで まれ、エンド・ツー・エンドの一部であれば、メイン・サー しょう。発生する問題としては、以下のものが考えられます。 ビスが多数のサブ・サービスの親サービスになります。通常、 サブ・サービスは、エンド・ツー・エンドのコアのビジネス・ ■スキルあるいは専属リソースの不足 サービスです。 ■ IT チームからの合意が得られない モデルを定義することで、現行および将来のサービスの持 ■ビジネス・リソースの不足 続性が保たれ、SLA と OLA を定義・維持するモデルを構築す ■時間 ‒ 長すぎるあるいは短すぎる るための骨組みができます。 ■サービス構造が複雑すぎる 最初のデータ・モデルを第一歩として、ビジネス側にも議 ■エンド・ツー・エンド・サービスの理解 論に参加してもらい、自分達が使用する IT ビジネス・サービスを ■ IT ビジネス・サービスと IT システムの違いに対する理解 定義し、各サービスの名称を設定する過程に参加してもらいます。 ■ビジネス知識の不足 親コアサービス 親コーポレートサービス コーポレート ビジネス・サービス コアビジネスサービス メインコア サービス１ メインコア サービス２ メインコア サービス３ サブ サービス １．１ サブ サービス ２．１ サブ サービス ３．１ サブ サービス １．２ サブ サービス ２．２ サブ サービス ３．２ サブ サービス １．３ サブ サービス ２．３ サブ サービス ３．３ サブ サービス １．４ 親サポートサービス サポート ビジネス・サービ ス メイン コーポレート サービス１ メイン サポート サービス１ メイン コーポレート サービス２ メイン サポート サービス２ メイン コーポレート サービス３ メイン サポート サービス３ メイン コーポレート サービス４ メイン サポート サービス４ サブ サービス ３．４ サブ サービス １．５ サービスのサポート ＩＴ／オペレーション サービス 契約/サードパーティ サービス 請負サービス ■カルチャ 管理ツールとビジュアライゼーション・ツールを導入すると、 イベントとサービスをリンクさせて、デスクトップ上でサー 将来の機能とメリット ビスを可視化し、サービスやエンド・ツー・エンド・サービ スのコンポーネントがいつインパクトを受けるのか示すこと サービスカタログを作成することにより、企業はサービス ができるようになります。 構成およびビジネスへのサービス提供方法を理解することが これはすべて、ビジネス側との強力な協力関係を構築する でき、SLA をベースとした真のサービスと課金をすべてのサ ことなく達成することは不可能ですので、サービスレベル管 ービスに導入できるようになります。 理プロセスの導入と展開にとっての良い基本となることでし IT ビジネス・サービスと IT 運用サービスから成るデータ・ ょう。 モデルを定義することで、ビジネスとそれをサポートするサ ービスの関連性を直ちに特定することができ、OLA 要件を Vicky Howells, Fox IT 設定することができます。サービスが外部組織によって保守 / サポートされている場合は、これをさらに拡大して、請負契 約を含むようにすることもできます。 IT インフラストラクチャをサービスに対応させ、イベント 13 Ask The Experts it SMF が受け取った質問に対して業界をリードしている専 From SERVICEtalk 差異を定義する別の方法として CMDB の内容があります。 門家が回答します。 ステータスが 稼動中 もしくは 運用中 のあらゆる構成 アイテム (CI) と関連属性について、計画作業の提案時に変更 質問 1 要求 (RFC) が必要となるでしょう。一方ステータスが 変更が変更であってリリースでないのはいつでしょうか？ ト中 （SERVICEtak 2004 年 10 月） もしくは 開発中 テス のあらゆる構成アイテム (CI) と関 連属性については、リリースが必要となるでしょう。 要約すると、 リリース 画された作業、 変更 回答 1-1 は新しいものの提供に関する計 は既に稼動／運用されているサービス への修正となります。 Paul Gurr、Plan-Net Services ここ数年企業組織において変更管理とリリース管理機能に 回答 1-2 責任を持つ立場であった個人的な経験から述べますと、この 疑問は 変更 もしくは リリース James Finister、AXA を計画・提案する度に 担当スタッフから提起され続けています。管理プロセスの計 画・実装の初期にこのふたつの違いを定義しておくことは 更 と リリース 私はこの質問は、もし現バージョンの ITIL が唯一正式の 変 プロセス・モデルとして組み込まれているとすれば提議され の責任に対する認知や可能な代替策を確 ないもののひとつであると考えます。リリースと変更はふた 立するために非常に重要です。また、それらが将来の実装を つの全く異なる種類のものです。 コントロールするでしょう。 リリース 単純なレベルでは、変更はある特定のひとつの CI の状態 を最も簡単な文章で定義すると、稼動／運用 変化であるのに対し、リリースはひとつのエンティティとし 環境に実装するあらゆる新しいハードウエアあるいはソフト て管理される CI の集合体の状態変化といえます。 ウエアに関係するプロセスといえるでしょう。ここでいう リ リース リリースは（複数の）変更を本番環境に導入するしくみで は、以下の例のような本番化にあたっての前提事項 あり、一度に多数の変更を実装するために使われると考えら が全て確実に考慮されるよう、厳格にコントロールされた変 れます。 更管理の下で管理される受け入れ手順に従わなくてはなりま 変更は主に以下の３つの要因により発生します。 せん。 ■インシデント管理もしくは問題管理のどちらかで判別され ■コミュニケーションと認知 た不具合を修正する必要がある場合 ■トレーニング ■ビジネス要求により機能を根本的に変更する場合 ■本番実装前テスト ■テクノロジやベンダ・サポートが変更になる場合（製品の ■切り戻し計画 サポート切れなど） ■許可 ■お客様の期待値の管理 いくつかの変更は非常に重大です。例えば、Windows XP ■ソフトウエア保管領域 SP2 のリリースのようなオペレーティングシステムの新バー ■ CMDB の更新 ジョンへの置き換えなどです。一方、変更同士で複雑な相互 依存がある場合もあります。変更管理はリリース管理との組 上記の定義は、 変更とは何か に関するガイドラインと もなります。変更管理機能の究極のゴールは 稼動 合せで、これら全ての独立した変更の実装をコーディネート 運用環 する必要があります。 境を保護し、リスクを軽減し提案された実装の影響を最小化 これらの変更はリリースを本番環境に昇格することによっ する事であるべきです。従って変更の定義は、 稼動／運用中 て真に実装されます。ひとつの組織が厳正なるリリース・ポ のシステム、サービス、アプリケーションに影響する、ある リシーに従い、企業のビジネス・カレンダーに沿って事前に いは潜在的に影響する可能性のある、提案され計画された 合意された日程で一年に多数のリリースを実施することが一 あるいは緊急の作業 般的です。 となるでしょう。 14 リリースは V1.01b のようにアサインされたバージョン番 れ、リリース管理としては、構築、テストそしてリリース管 号を持ち、以前のリリースからの変更の幅を示すことができ 理を行ないます。ITIL の全領域と同様に、ビジネスサイドの ます。新しいリリースのバージョンは構成管理における新し 要求に応じて、時にあいまいであり、かつお互いに関連しあ いベースラインを示すものとなります。 った領域間の境界は密接にリンクします。それゆえ、もっと しかし注意が必要なのは、リリースは時に階層になってい も適切な境界（もし、あなたが必要とするならばですが）は、 ることです。例えば標準的にデスクトップ用に作り上げられ あなた自身、あなたのチーム、あなたのビジネスそして、使 たリリースはセキュリティ・ソフトウエアのリリースとオフ 用可能なリソースによって決まります。 ィスの生産性向上のためのソフトウエアのリリースの両方の リリースを含むかもしれません。 実際には、リリースは本番環境で扱われるべき重大な変更 回答 1-5 と、標準的に行われる小さな変更の最も低いレベルであるべ Tony Price、PinkRoccade きです。現実には完全なリリース管理の事務手続き負担が見 合わないために、小さな変更を通常のリリース・スケジュー お答えする前に、まず、変更の完全な定義を考えましょ ル外で実施することが必要な場合があります。その場合でも う（いくつかあるでしょうが、これは、私のバージョンです）。 変更管理の手順は踏む必要があり、CMDB への記録も必要で 理論的には、ひとつの変更は、変更される項目に対しての何 す。 らかのアクションです。ここでアクションは、修正、変更、 なんらかの追加をその変更される項目へ行うことです。これ を可能な限り最下位のところまでもっていくと、理論的には、 回答 1-3 個々の原子のレベルへいきます。なぜ、正式に変更を取り扱い、 John Efford、abbey これを単純化したいのでしょうか。それは管理を導入するた めだと理解しなければなりません。 この件について多くを語る事もできますが、私としては変 変更はある意味でのリスクを持ち込む事と見られます。そ 更とは何かしら（ハードウエアやソフトウエアなど）の置き れは、リスクが、財務的な意味を持っているからです。つまり、 換えと考えます。リリースは機能拡張を目的としたコンポー リスクであるかもしれないというのは、CI などの項目へ何ら ネントのアップグレードといえるでしょう。例えばソフトウ かの変更を行った後、想定したとおりの結果とならない場合 エアの新バージョンやパフォーマンスを向上させる新しいハ があることでもあります。そのことは、財務上のリスクとな ードウエアなどです。 り得ます。このことからも、私が当初申し上げたように、管 理が必要となります。 また、各変更群は、互いに関連していることが多いもので 回答 1-4 す。事実、多くの場合、変更は単純なものであっても、複数 Paul Wigzel、Avon & Somerset Police の他の変更群との相互関連性なしには、発生し得ないもので す。このようなケースでは、通常単純化できるよう変更群を 変更は、システム、サービスまたはビジネス・プロセス 論理的なグループへまとめたいと考えるか、または想定され それ自体に対する変更です。リリースは、変更のための構成、 るリスクを極力ひとつの領域（たとえば、ソフトウェア・リ 投入、レビュー・メカニズムのことです。変更は、パッケー リース）へまとめることができるようグループ化したりする ジ・リリースの一部です。しかし、もしビジネスサイドの承 ことを考えます。こうして、ある「リリース」へと変更群を 認があれば、独立したデルタ・リリースにも成り得ます。こ まとめるためのグルーピングが重要となります。 うして、同じ変更であっても、リリース方法が異なってきます。 ご質問へ戻りましょう。ある変更は、以下の場合において 一例を挙げます。サービスデスクは問題管理チームと一緒に のみ「変更」となります。その変更によるリスクまたは財務 問題を記録します。問題管理チームは、その記録から、シス 的な影響の管理が許容可能な範囲であると判断でき、その組 テム設定へ必要な変更を行うための恒久敵な修正情報の調査 織にとって必要である場合（つまり、リスクと財務的影響の や作成を行います。この変更要求は、評価、リスク分析そし 両面から、あなたの組織が許容可能なレベルと判断できた時） てインパクト分析のために CAB( 変更詰問委員会 ) へ提出され です。これは組織の判断により変更とみなされるか、そうで ます。CAB が、要求を承認し、受け入れると、「変更要求」は ないかの差となりえます。たとえば一例として、ある組織で 「変更」となります。しかし、CAB では、その「変更」の優先 はその変更を PC マウスの置き換え作業と考えたとしても、他 度が低いと判断した場合は、その「変更」を次期のパッケー の組織では変更とも考えないような簡単で気にもしないよう ジ・リリースへ組み込むことでしょう。それゆえ、その「変更」 な作業と考えることとなり得るわけです。リリースとは、相 は、次のパッケージ・リリース内の変更のひとつとして扱わ 互関連する変更群を論理的にグルーピングし、パッケージ化 15 したものです。グルーピングされた変更群は、その組織にと です。このフィードバックは、インシデント、問題、変更そ って受容可能と判断されていることが前提です。こうして、 「リ してサービスレベル管理の各プロセス・レビューを通して得 リース管理におけるパッケージとは何か？」というテーマで られます。 の議論へと発展してゆくこととなりますが、これは、このご 質問の範囲ではないですので、Service Talk の次号以降で議論 することとしましょう。 回答 2-3 John Gibert、Southcourt 質問２ 私は、予防ということにフォーカスすべきと考えます。物 多くのツールとサービスがあります。さらに様々なアプロー 事をうまく揃えるには、調達、開発、統制をうまく行うこと チが私の関わる「サービス」をどうやって良くするか、ある です。そうすることで、IT サービスは、目的によく合った形 いはそうでないかを語っています。これらは、そもそもどう となります。「検知と修正」の継続が必要であり、エラー、イ 違っているのでしょうか？また、私はどこから始めたら良い ンシデントそして問題を予測し続けることも必要です。しか のでしょうか？（SERVICEtak 2004 年 10 月） し、これは、全てを監視しレポートするという意味ではあり ません（だれも果てしなく監視ツールを配置することはでき ませんし、無限に大量のパフォーマンス情報を作ることもで 回答 2-1 きませんし、すべきでもありません）。全ての場合において、 「予 John Efford、abbey 防、検知、そして修正」のためであり、ビジネスと、IT のお 客様と、一緒に始め、彼らにとって、何が重要かを理解して まず、最初におたずねさせていただきたいことがありま いきます。また、ビジネス部門が行っているビジネス・プロ す。キーとなる利害関係者は、そのサービスについてどのよ セスの重要度へ注力することも重要です。結果として、何が うに考えておられるでしょうか？このサービスは、様々な方 重要な IT サービスであり、それらのどこが品質面の課題を持 法で提供されます。いくつか例を挙げますと、内部のメンバ っているかを把握することが重要です。 あるいは Maven 社などの会社経由での顧客調査／質問による こうして、最も良い方法を、理想的に、（簡単に、低コス 方法、または、これも内部または Compass 社のような会社経 トで、合理的な正確さで、繰り返し、そして必要な時にのみ） 由になりますがインダストリ・ベンチマークなども参考にな 見つけていく必要があります。ツールは、ニーズと課題が明 るかもしれません。 確な場合のみ手助けなります。常識が重要です。 可用性やパフォーマンスについてのキーとなる指標を得る ことは、あなたのサービスをどう改善していくかの答えを得 る助けとなり得ます。 質問３ 私は定期的な IT システムの復旧テストの実施を引き受けてい ます。最も効果的な実ユーザを巻き込む手段は何ですか ? 回答 2-2 （SERVICEtak 2004 年 10 月） Steve Straker、Fujitsu 最初に、it SMF の ITIL セルフアセスメント・スプレッド 回答 3-1 シートをダウンロードすることからはじめましょう。このシ Steve Ackland、Aim4Gain ートの質問へ全て答えることは、今あなたがどこにいて、ど うなる必要があるか（その中には、目標も入っています）を 多くの IT サービスマネジメントのハートを打つ非常に有 理解することができます。こうして、簡単なギャップ分析を 効な質問が発行されました。どのようにしてユーザの IT への することができます。さらに高度なサービス指標を得るには、 関心を獲得するか、それからどのようにしてそれを有効に活 いくつかのツールやサービスがあります。これらは、企業規 用するのでしょうか？このような事柄が通常人々の協議事項 模でビシネスを要約する（この要約は、あなたが提供してい にあるので、IT およびサービス継続性の両方を含むとき、そ るサービスの戦略的な面、戦術的な面、業務的な面の各領域 のチャレンジは倍難しくなります。 での取り組みをまとめてくれます）バランス・スコアカード IT システムの復旧を含むサービス継続性のあらゆる形態 から何かを作成してくれます。たとえば、EFQM（European のいくつかの点でユーザが巻き込まれなくてはいけないとい Foundation Quality Model）は、このための良いスタート地点 うことを最初にはっきりさせておくことは、私にとって重要 となります。また、あなたのサービスがどのように良いかを です。それには 2 つの理由があります。第一に、サービス・ 示すための最もよい指標は、顧客との関係のフィードバック マネージャは、システムとユーザが、組織のプロセスに関し 16 て相互接続される重要なコンポーネントだという事実を見失 彼らの役割と責任を理解しなくてはいけません。第三に、リ ってはいけません。したがって、ちょうど運用の移行の前に ハーサルは、主導権を発揮するユーザにとって面白く、やり 新しいシステム開発のテストを行うように、IT システムの復 がいがあり、そして楽しい現実的なシナリオに従うべきです。 旧テストは、緊急時の手続きがうまくエンド・ツー・エンド そして、そのイベントを録画することがしばしば役に立つと で実施できることを確認するために、ユーザ・コミュニティ わかります。もちろん事前に許可されている必要はあります を巻き込まなくてはいけません。サービス継続性マネージャ が、後でそれらはパフォーマンスへの建設的なフィードバッ は、それゆえにデータセンタの孤立した IT システムの技術的 クの役立つ情報源となります。 な復旧をただちに実行すべきではありません。第二に、ユー 異なる組織での数多くのリハーサルを実施していること ザとの定期的な取り決めは、IT リソースが制約される必要の は、次に続くこれらのステップがユーザを効果的に巻き込む ある危機において特に重要となるビジネス上の要求や組織横 と同時に、組織が危機についての扱いをよく準備しているこ 断的な優先度に関する豊富な情報源となる、ということです。 とを確認するでしょう。 定期的な取り決めを通してのみ、サービス継続性マネージャ は平常時の運用と危機におけるユーザの需要と供給の期待を 理解するでしょうし、SLA に確信を持ってそれらを記載する 回答 3-2 ことができます。 James Finister 、AXA それでは、ユーザを効果的に巻き込む最もよい方法は何で しょうか？計画と復旧手順が最新でなければならず、定期的 ユーザを巻き込む最もよい方法は、IT の災害復旧をテス にリハーサルを実施しなくてはいけないという事実がある一 トするということから、ビジネス継続性計画 (BCP: Business 方で、ユーザには日々の業務があり、それで彼らの関与は必 Continuity Planning) をテストするということへ移行すること 要最小限にとどめなければならない、ということも事実です。 です。BCP は、CIO の責任である IT の災害復旧 というよりも、 それゆえにリハーサル・プログラムでは、何がリハーサルさ むしろそれに IT が寄与する ビジネス責任 であるべきです。 れ、いつ、そして誰が必要とされるかといった決定が工夫さ IT のテストの成功を会社へ報告するときに、ビジネス・プロ れるべきです。これにより、ユーザが前もって責務を理解し、 セスを適切に保護するためにどのような打ち合わせをするか リハーサルを日常的にすることを可能にします。 サプライズ について尋ねます。たとえば、オフィスの利用が拒否された テストを例えば 2 週にわたって合意された時間帯に起こるよ とき、どこで働くのでしょうか？もしあなたが、テロリスト うにスケジュールすることさえもできます。これは、スイッ の爆撃または火事といった重大な災害状況を生き延びたビジ チを切ることに対して誰も感謝しないだろう時間帯では、通 ネス上の他のユーザに、あなたの顧客を会わせることができ 常時のビジネス活動のピークエリアが避けられるということ るならば、それは本当に役立つものだと私は過去にわかりま を意味します。リハーサル・プログラムは、異なるテスト範 した。 囲を含むべきです。あるものは単純な技術的なシステム復旧、 またあるものはユーザのみを含むテスト、そして両方の要素 を一緒にした評価といったものです。ユーザを含むリハーサ 回答 3-3 ルは、知識を維持するのに十分な頻度で実施されるべきです。 John Gibert 、Southcourt しかし彼らがいやな仕事と思うのは、しばしばではありませ ん。ユーザを含む最も単純なリハーサルは、「walkthroughs」 最善の方法は、ビジネス継続性テストの一部として実施す （ウォークスルー）と名づけられたもので、そこでの達成目標 ることです。そこでは、技術的な失敗と災害復旧 (DR) が、影 は指令や記録データの側面と正確さの管理をアセスすること 響を受ける事業部門のためのビジネス継続性テストへと連携 です。これらは、毎月あるいは、2 ヶ月ごとに引き受けられ、 されます。 ユーザを含めた 1 時間程度のものです。より多くの複雑なリ テストは、サービス継続性インシデントのエンド・ツー・ ハーサルは、全体のビジネス機能、単一の場所、またはすべ エンドの復旧をシミュレートしなければなりません。そこで ての組織に焦点があてられるかもしれません。そして、IT シ はそのビジネスはビジネス継続性計画の使用を運用できるよ ステムの復旧は、ユーザの運用や災害復旧サイトへの再配置 うにテストをしなければなりません。並行して、IT は、IT テ （もしある場所を利用できればだが）とともにテストされます。 クノロジー、データ、サービスを復旧することができるよう 後者は少なくとも年に１度、１日またはそれ以上で続けられ テストをしなければなりません。また、そのビジネスは、あ るべきです。 らゆる失った情報の実際の復旧と未処理の作業に対する解決 リハーサルをそれ自身でできるだけユーザに受け入れられ 策の編成のテストをすることができます。 るようにするためには、経験上、次の局面が扱われるべきです。 もしそのビジネスが BCP を持っていれば、IT は DR と BC 第一に、上級管理職の肩入れ、関与、声援は確保されなくて のテストを一緒に実行しなければなりません。もしそのビジ はいけないということです。第二に、巻き込まれたユーザは、 ネスが BCP と BC のテストをしていなければ、CIO に知らせ 17 ファントム爆撃機での体験 From Service Management Essentials コースの講師である私は、 SERVICEtalk 因を証明することはできませんでした。 同僚がコース会場のホテルの構成を使って構成管理を論じ、これ あいにく、同じ機体が次に離陸した際にも同じ不具合が を各コンポーネントに分割する原則を説明しているのを聞いてい 発生し、インシデントが上げられました。この時点で、エン ました。この比較が非常に興味深く適切だったので、他にどこで ジニアとしてこの機体を格納庫に移動して十分な検証を行った この原則が適用されているのを見たことがあるかと考え始めまし うえで根本的原因を追究したいと思う私と、早急にインシデン た。考えるほどに色々な例が思い浮かびましたが、最も良い例は、 トをクローズして機体を使えるようにしたい（可用性を高めた RAF（英国空軍）の航空技師時代に経験したことでした。航空機 い）と考えるエンジニアリング・コントローラの間で意見が対 保守とサービスマネジメントには共通点が多々あり、RAF 時代の 立しました。最終的には私が勝って、問題解決に取り掛かりま アイデアを IT 環境に取り込んで問題を解決したことは 1 度や 2 した。問題解決を行う間、コンポーネントを取り外す必要があ 度ではありません。 る場合にはジョブカードを上げて確実に再装着されるようにす 引き続いて行われた ITIL トレーニングコースで、私は、 るとともに、関連システムが検証されてから当該機の飛行が許 インシデント―問題―既知のエラー―変更というライフサイ 可されるようにしました。尚、RAF のジョブカードでは、 「Open クルをなかなか理解させることができず、航空工学の実例を Entry」が上げられるようになっています。 挙げて視点を変えてみることにしました。また、本誌にもこ カードには 2 つの書込み領域があり、第 2 の領域には、 れまでとは違うタイプの記事を書くことができ、ITIL 技術者 エンジニアが実施した修理内容（「アクセスのため、オートパ が他者の経験を引き出し、学ぶことができるような比較記事 イロット・コントローラを取り外した」など）を記録できる の流れを作り出すことができるのではないかと思ったのです。 ようになっています。第１の領域には、一連の Open Entry が 私たち第 92 連隊（ファントム IV 爆撃機）保守チームの 上げられ、ジョブカードをクローズする前に完了しなければ メンバは、パイロットの砲撃演習に合わせて、毎年 1 ヶ月間 ならない作業の詳細（「オートパイロット・コントローラの再 キプロスに滞在しなければなりませんでした（やっかみの声 装着」、「オートパイロット・システムのテスト」など）が記 が聞こえてきますね）。キプロス周辺の地中海には広大な侵入 録されます。Open Entry の各項目について、第 2 の領域の項 規制海域があり、そこで、RAF の戦闘機が機体より大きなバ 目が入力され、必要作業が完了したと言えるまで、ジョブカ ナーを引き、他機がバナー周辺に爆撃するという実弾演習を ードをクローズすることはできません。ジョブカードがオー 行っていました。いつも、バナーを引くパイロットはさぞか プンしたままの機体に飛行許可が下るのは、例外的な場合だ し豪華な朝食を出され、決死の覚悟で飛び立つのだろうと思 けです。 ったものです。 これでは、明らかに書類処理が増えますが、安全な飛行を ある演習で、実弾を搭載した１機のファントム爆撃機が離 確保するためには不可欠であるため、納得して実施するようにな 陸した直後に、電子パネルに一斉に漏電遮断器が表示された るのです。IT の世界における技術者は、実際の仕事よりも長い管 ことがありました。このような場合、パイロットには警告音が 理作業を嫌がることが多いようです。しかし、最新かつ正確な記 聞こえ、視界にフラッシュライトが光ることになっています。 録を維持し、すべての活動を記録しておくことは必要なことです。 （パイロットが気づく前に、管理システムが自動で不具合を検 今後 他の問題を調査する場合には、時間を大幅に節約することが 知する）この機は緊急事態を宣言し、安全に着陸しました。着 できるのです。 陸を済ませると、パイロットはエンジニアの詰所である建物 さて、先の問題に戻りましょう。格納庫の中は暑く、何時 に出向いて不具合内容を報告しました（インシデントを上げま 間も作業をして大量の書類処理を行っても、不具合を見つけ した）。そして、エンジニア（私！）が派遣され、すべてのシ ることはできませんでした。私はエンジニアの 1 人に飲み物 ステムが検証されましたが、問題を再現することはできません を取りに行かせたのですが、そのエンジニアがコックピット でした。万一に備えて、「ジョブカード」を上げ、不具合の原 から出る時、飛行中に作動したすべての漏電遮断器がまた作 因かもしれない一連のブラックボックスを交換しました（各々 動したのです。間もなく、このエンジニアがコックピット・ のジョブカードには「変更要求」と記されました）。ボックス フレーム周辺にめぐらされたワイヤリングルーム ( ワイヤの 交換されたシステムはすべてサービス性がテストされ、不具合 束 ) に悪影響を与えた結果、機体への漏電が発生したことが が認められなかったため、その機体は飛行可能と認められて、 わかりました。 不具合ログはクローズされました。私たちは、インシデント― さらなる調査で、ルーム内に擦り切れたワイヤがあること 問題―複数の変更というルートを辿ってみましたが、問題の原 が分かりました。通常の状態では、損傷を受けたワイヤがシ 18 ョートすることはありませんが、離陸時の G を受けた状態（あ 既知のエラーに類するものを上げて対応することができまし るいは、 コックピットから出るボブの膝が当たった状態）では、 た。つまり、機体の使用停止を未然に防ぐこともできたのです。 ショートが発生することがわかり、原因が究明されたのです。 さらに、前回の修理における共通点を特定する作業も行わ ワイヤリングルームは修理され、問題は解決されました。月 れました。記録によれば（あらゆることが包括的に記録され 曜日の朝、この爆撃機は問題なく飛び立ちました。 ているため）、すべての修理を同じエンジニアが行った しかし、これで話が終わったわけではありません。作業対 ことが分かりました。これを受け、RAF はそのエンジニアに 象となったファントム機は RAF が多数所有する機体の 1 つでした。 指示通りの作業を行うよう「指導」しました（鬼軍曹にしご 他機にも同じ問題があったらどうするのでしょう？今回の発見を共 かれたのでしょうか）。この問題は、指示通りに修理が行われ 有しなければ、多くの場合、多大な労力を費やして問題を特定し、 なかった結果を示す例として、ある航空安全誌にも掲載され 解決しなければならないことでしょう。また、私たちの発見は 2 次 ました。 的な問題で、調査すべき原因がありました。なぜワイヤリングルー 皆さんが、これまでとは違う興味深い話としてこの記事を ムに擦れが生じたのでしょうか？すべての機体、問題、修正などに 読んでくだされば幸いです。では、記事の最初に戻って、IT サ 関して保存されている包括的情報源（CMDB に相当）を使用すると、 ービスマネジメントの観点で読み直し、私達がしていること（す 損傷があった部位から余分なスタンバイ・コンパス ( 飛行機の部品 べきこと）との類似点に注目してみてください。航空安全の世界 ) を取り除くため、以前、ファントム機全数が修理されていたこと では、問題の再発を防止するために、できる限り踏み込んだ調査 を突き止めることができました。修理パンフレットを見ると、ワイ をすることが重要です。IT 環境では、この点をおざなりにしては ヤリングルームの動きを防止するためにプラスチックのケーブル・ いないでしょうか。しかし、おざなりでよいのでしょか？長い目 クリップを装着すべきところ、前回の修理の際にはそれが省かれて で見れば、内在する問題を解決する方が費用対効果は高いのでは いたことがわかりました。 ないでしょうか。 私たちは、すべてのファントム連隊に対し、全機について クリップの装着ミスをチェックするよう伝えました。すると、 Mike Baker, 何機かに問題がみられ、機体の使用を停止することなく（可 MISM Group Change Manager, The Big Food Group 用性を低くすることなく）次の機会に問題を解決できるよう、 SERVICEtalk 2004 年 10 月 ベストプラクティスを目指して From お客様が次に貴社システムにログオンする時、何をす SERVICEtalk では、ダイレクト・アクセスのみを提供すべく設立された るためにシステムを使用すると思いますか？うまくすれば 会社（まだ少数派です）以外の企業では、標準 SLA 履行率 注文が入るでしょうし、個人情報の変更や質問をすること 98.5% で日曜日をメンテナンスに当てていた時代に設計さ が目的かもしれません。そして、電子システムであること れたシステムとインフラを運用しているのです。 を考えれば、まさに 24 時間 x7 日のサービスが期待されて いるのです。しかし、この業界では周知の通り、システム の多くは無停止ではなく、 「ただ今、一時的にサービスが中 お客様はサービスを今求めている 断されています」というメッセージにはかなりイライラさ せられるものです。それ以上に、製品自体やブランドや価 日曜日営業、24 時間バンキング、 「ジャストインタイム」 格ではなく、全体的な「サービス体験」によって銀行、エ といった現代消費者の社会的傾向は、「常時接続」という考 アタイム・プロバイダ、スーパーマーケットなどを決める え方をもとに、サービス・インフラストラクチャを飛躍的 お客様が増えているため、非常に高い代償を支払うことに に進歩させました。電話会社やインターネット・サービス なってしまいます。こうしたサービス体験に対する期待は、 プロバイダだけでなく、銀行、小売店、旅行会社が 100% もはやカスタマー・サービス部門が対応すべき領域ではあ のアップタイムとレスポンス保証を行うようになっていま りません。というのも、電子取引におけるアクセスと実行 す。これは、一般社会にサービス等を提供するあらゆる企 （セルフサービス）が制服を着た人間に取って代わり、お客 業にも言えることです。 様は企業の IT インフラストラクチャと直にやりとりをして 今や、一般の人は IT インフラが期待に沿うレベルにあ いるからです。ここから問題が発生するのです！イギリス るかどうかで企業を評価します。そして、IT が期待はずれ 19 であれば、新聞に投稿しないまでも、直接的に、公然と、 この場合のソリューションは、サービスマネジメント 当惑するような形で不備を知らせてきます。では、イギリ です。この発想の転換とは、IT デリバリ・インフラストラ スの企業はどのようにサービス経験への期待を管理し、IT クチャ管理のあらゆる側面を顧客の観点から見て、問題に をよく知るお客様の高まる要求を満足すればよいのでしょ なりそうな点をすべて管理することによってサービスを保 うか？答えは、 「対応策は必ずある」であり、パラドックス 証することを意味します。これにより、内部の非効率や新 は「達成は難しくもなければコストがかかるわけでもない 規システムに情報をフィードするシステム間の連携不備を が、ソリューションには代償を伴う」ということです。こ 発見することができます。こうして、サービス・コンポー の代償とは、発想の転換であり、これは数値化が容易でな ネント管理における弱点がわかり、期待と現実のギャップ いばかりか、購入してくるわけにもいけません。 が明確になるのです。サービスギャップを埋めるためには、 次の 3 点が必要です。 近年最大の社会変化の 1 つがセルフサービス文化の発展 であることは間違いありません。今日の消費者は、インタ ■カルチャ ― 優れたサービスを構築するための人、スキ ーネットで注文し、世界中どこからでも自分の銀行口座を ル、姿勢 管理し、携帯端末でインタラクティブなメッセージを受け ■テクノロジー ― お客様の期待に沿ったサービスを構築 取ることを期待しています。しかしこれは、こうしたサー ■プロセス ― 毎日、均質なサービスを提供 ビスをサポートする IT インフラストラクチャがお客様の期 待を満足するような形で運用されてはじめて実現されるの 幸い、多くの企業はこの 3 点を実行しています。ただし、 です。 米英の主要大学が実施した調査によると、世界最高水準の サービスを提供しているサービス組織の割合は、イギリス では約 5% である一方、アメリカでは 13% です。イギリス SLA の終焉 企業の課題は明らかです。世界のトップ水準に追いつくだ けでなく、お客様はログオンするたびに最高水準のサービ 発想の転換には、SLA に関して 25 年間蓄積してきた知 スを求めているのだと認識する必要があります。目指すと 識を忘れることも含まれます。SLA は、サプライヤと顧客 ころは、お客様が貴社の IT システムを自分で操作する「常 が同一企業内に存在したり、外部サプライヤからサービス 時接続」という環境で、優れたサービス・デリバリを管理 を購入して衡平法や契約法が適用されたりした場合にのみ することであり、それは、ベストプラクティスと呼ばれて 可能だったことです。これらのルールのいずれも顧客と企 います。未来はそこにあるのですから、ベストプラクティ 業のインタラクションには適用されず、銀行口座の可用性 スを目指す旅に出ても後悔はないでしょう。 が 98.5% であることなど、誰も興味がないのです。「残り の 1.5% はどうなる？」というわけです。 Peter Wheatcroft, Partners in IT Ltd 新規システムのビジネスケースを提示する時には、その SERVICEtalk 2004 年 10 月 目標と目的が明文化され、コストベースの利益率予測が示 され、それに対して IT マネージャの責任を負うことになり ます。しかし、100％未満の可用性を想定する新規システ ムはほとんどなく、サービスデリバリ機能がアプリケーシ ョンとその他のものとのスケジューリングを開始してから 上手くいかないことがわかると、そこから妥協が始まるわ けです。実際のケースとして、ご自身の企業の最近のビジ ネスケースで、ROI あるいは DCF の計算においてどの程度 のサービス停止が想定されているか見てください。それか ら、新規システムが提供すると想定されているサービスに 見合ったデリバリ・インフラストラクチャが構築されたの か、IT 部門に尋ねてみてください。想定と現実にギャップ はあるでしょうか。 ギャップに注意 : サービス・ソリューション 20 Planning to Implement Service Management 翻訳レビュー出版活動のご報告 昨年末、Planning to Implement Service Management（緑本）の翻訳レビュー活動が始まりました。6 月末の出版を目指して活 動を進めてまいります。スケジュールと参加のメンバは以下の通りです。( 出版ワーキンググループ ) スケジュール 参加メンバ（敬称略、アイウオエ順） 日本電気 川瀬 訓範 日本ユニシス 山崎 彰一 日立製作所 岡本 彩子 日立製作所 亀山 伸 日立製作所 八木 隆（コーディネータ） 日立製作所 萩野 美穂（とりまとめ） 日立電子ｻｰﾋﾞｽ 齊藤 豪 日立電子ｻｰﾋﾞｽ 松長 由香里 富士通サポートアンドサービス 佐藤 昭博 富士通ラーニングメディア 森 恭子 プロクターアンドギャンブル 橋本 深雪 プロシード 島崎 理一 プロシード 吉田 俊雄 三菱電機情報ネットワーク 吉本 賢祐 シーエーシー 野村 紀美 ソニーグローバルソリューションズ 竹川 雄介 ﾄﾗﾝｽｺｽﾓｽ 中村 峰行 日本 IBM Marcilla Rahim 日本 IBM 足立 卓 日本 IBM 生田 奈津子 日本 IBM 稲野 岳 日本 IBM 岩田 謙一 日本 IBM 岩村 郁雄 日本 IBM 品田 京子 日本 IBM 長友 芳正 日本 HP 新井 浩介 日本 HP 久納 信之 日本 HP 塩田 貞夫 日本 HP 土井 美奈子 日本 HP 濱田 剛 日本情報通信 應和 周一 日本電気 大畑 毅 21 it SMF Japan 分科会活動計画・活動状況 前回 it SMF Japan における分科会活動をご紹介させて頂きましたが、今回はサービスデスク分科会と事例研究分科会の 具体的な活動計画・活動状況をご提供頂きましたのでご紹介します。活動計画・活動状況については今後、外部向け Web サイトでも公開していく予定です。 サービスデスク分科会 (2004 年前期〜 ) 【 サービスデスク分科会後期活動の方針（案） 】 ・サービスデスクの概念の普及 、 、 サービスデスクの実践的な方法論の普及への貢献 ・一般的な情報より、より深く理解したい、「前向きな人」をターゲットとする 全体討議 仮説出し（チーム毎） テーマ選定と全体計画 1月～ 2月 11 月～ 12 月 3月～ 4月 成果物作成 ～ 4月・ 5月 ・チーム毎にテクニックや 評価手法について幅広く 討議 ・評価結果と手法（改善 テクニック）の融合 ・成果物作成作業 具体的�活動 ・各テーマを効果的に研究 するための討議 ・今後の進め方の合意 ・テクニックの活用シーン を討議 ・定量的な評価指標の根拠 と測定方法、指標ロジッ クの討議 ・定量的な評価が悪かった 場合に何をアクションと して実施すべきか、関係 性について討議 ・成果物作成作業 備考 ����概要 ・テーマ設定「役割毎のテ クニック」「評価方法」 についてチーム内の合意 ・アセスメント分科会の テーマにセルフアセス メントが包含されている ・ユーザー企業の意見を聞 きたい。（ 3月） ・レポートイメージは前期 と同じ。（難しく書かな い） 分科会より： サービスデスク分科会では、2004 年 12 月から 2005 年 6 月までの期間で １）サービスデスクの評価手法 ２）サービスデスクの役割毎のテクニック の２つをテーマとして、より実践的な方法論を研究していきます。そのテーマの有効性についてご意見頂くため、実際の情報シ ステム部などでヘルプデスクなどを担当されている方の意見がかかせません。サービスデスク分科会の活動にご興味ございまし たら、分科会へご参加お待ちしております。参加ご希望の方は it SMF Japan(info@itsmf-japan.org) までお問い合わせ下さい。 事例研究分科会 (2004 年前期〜 ) 【 事例研究分科会後期活動の方針 】 ・国内事例を蓄積するため、ユーザ企業の参加を促進する ・参加企業それぞれの ITIL 、取組みにあたっての悩みを共有し、解決の糸口を参加メンバで議論することで“事例”にお ける課題とその 解決手法例：目的面、実装面の FAQ 、ヒント集」を作成する 目的面 定量的な指標の検討 効果予測 ,実績測定の検討 実装面 課題、悩みの抽出 解決手法の議論 ＩＴＩＬの現状を議論 具体的�活動 ・ユーザ企業含む分 科会メンバにて、 ＩＴＩＬ導入課題 などの現状を議論 備考 ������������分割�作業�実施 ����概要 ・ＩＴＩＬ導入課題 などの現状を議論 成果物作成 ・各社のＩＴＩＬ導入での 課題、悩み、疑問点の抽 出 ・課題、悩み、疑問点に関 して分科会メンバで議論・ 討論 ・成果物作成作業 ・２つのテーマにそって以 下を検討 ・ＩＴＩＬ導入、取組みの 際の課題、悩み、疑問点 を事例にそって提示いた だく ・２つのテーマにそって以 下を検討 ・課題、疑問点を解決する 方法をメンバで議論・討 論し、解決策をまとめる ・成果物作成作業 ・成果の発表に関してはカ ンファレンスとするが、 当成果物に関しては３月 末までの作成を目標と す る ・ひとつの課題に対して、 あえてひとつにまとめず、 数種類の答え、ヒントを 作成 ・ＩＴＩＬ導入における課 題とその解決手法例：目 的面、実装面のＦＡＱ集、 ヒント集的なものを作成 1 分科会より： 事例研究分科会では、2005 年 6 月までの期間で ITIL の課題として以下の 2 つをテーマとして研究をすすめていきます。 １）目的面・計画面における定量指標、効果予測、実績測定の検討 ２）実装面における課題、悩みに対する解決手法の検討 次回は SLA 分科会、アセスメント分科会の具体的な活動計画・活動状況をご紹介させて頂く予定です。 22 編集後記 2004 年１月に創刊されたニュースレターも２年目に入りました。この 1 年は海外の活動を中心に紹介してまいりましたが、 今年は会員皆様の活動を積極的に紹介していきたいと考えております。it SMF Japan では、11 ページの寄稿募集にもありま すように、会員皆様による編集活動への参画をお待ちしております。ご多忙のところ誠に恐縮ですが、是非ご参加いただけ ますよう、何卒宜しくお願い申し上げます。 （八木） ■ ご意見： 本ニュースレターへのご意見・ご要望は、it SMF Japan 版担当宛てにメールにてお 送りください。 メールアドレス： ■ 寄稿： publication@itsmf-japan.org IT サービスマネジメント導入、運営に経験を他の会員の皆様とシェアしていただけ る方を募集しております。ご協力いただける方は、it SMF Japan 出版担当宛てにメールにてご 連絡ください。 メールアドレス： ■ 広告： publication@itsmf-japan.org 本ニュースレターは皆様の広告料で制作されています。広告掲載に興味をお持ちの 方は it SMF ｓ Japan 事務局にご連絡ください。 ■ it SMF Japan ニュースレター 2005 年１月号 編集人： (1 月、4 月、7 月、10 月発行 ) 水野 康彦（it SMF Japan 出版担当理事） 編集取りまとめ： 八木 隆 ( 日立製作所 ) 編集に協力いただいた方々（敬称略、アイウエオ順）： 大倉俊治 ( 日本アイ・ビー・ エム） 、奥村剛史 ( コンピュータ・アソシエイツ )、経塚麻衣子 ( コ ンピュータ・アソシエイツ )、 小久保洋平 ( コンピュータ・アソシエイツ )、三部佳彦 ( コンピュータ・ アソシエイツ )、品田京子 ( 日本アイ・ビー・エム）、土田智 ( 日本アイ・ビー・エム）、富樫 和子 ( 日 本アイ・ビー・エム）、萩野美穂 ( 日立製作所 )、廣澤正道 ( 日本アイ・ビー・エム） 、本多英利 ( 日 本アイ・ビー・エム )、米田朋子 ( コンピュータ・アソシエイツ ) ■発行所：it SMF Japan 東京都港区六本木 6 丁目 10 番 1 号六本木ヒルズ森タワー 34 階私書箱 30 号 電話 (03)5786-7525 Fax (03)5786-7523 URL: www.itsmf-japan.org ■ ITIL® は英国政府機関の OGC(Office of Government Commerce) の英国およびその他の国におけ る商標または登録商標です。 ■その他記載の組織名（会社／団体／機関） 、製品名は、それぞれの会社／団体の商標または登録 商標です。 ■本誌掲載記事の無断転載を禁じます。 23
© Copyright 2024 Paperzz
