ケーススタディ

www.servicenow.com

ITバリューチェーンの自動化

私はGustav Hoyerです。IT業務に関する管理コンサルタント企業、Alvarez and Marsalのビジ

ネスコンサルティングディレクタを務めています（ghoyer@alvarezandmarsal.com）。私の業務

は、エンタープライズアーキテクチャ（EA）の標準、フレームワーク、基準をそれ自体がビジネスのようなITに適用することです。ITの運用は、いわば「企業内の企業」のようなものです。たとえ

ば、調達、ソーシング、原材料の獲得、サーバーの購入、人材の確保などといった役割があります。

私は以前、Sony Pictures Entertainmentに勤務していました。Columbia、TriStar、Sony Pictures Classicsなどの著名なブランドで映画を製作している、Sonyの子会社です。全世界にコンテンツを販売しているため、スタジオは広大で、ITのフットプリントもかなり大きくなっています。 各国、各地域、各立法区域で会計が必要であり、映画館への配給ネットワークも複雑です。 同社に在職中、私はServiceNowを60日間で実装しました。本書では、短期間で成し遂げたその

実装の経緯をご紹介し、アーキテクチャの一部について説明しながら、当時の意思決定につながった考え方についてお話しします。

迫られる迅速な対応 始まりは、よくあるIT環境でした。開発者、派遣人材、専門家が社内に分散し、知識はあちこち

に偏在し、業務との一貫性も欠けている、そういう状態でした。そんな中で2009年の12月、役員からIT部門の責任者に対して「３ヶ月以内にマネージドサービスの実装を開始する」という通

達がありました。パートナーも、組織編成の概要もすでに決まっていました。要するに、役員はIT部門を根本から再編しようとしており、私たちには大規模なSLA主導のデリバリモデルを整え

るまでに数ヶ月しかありませんでした。

マネージドサービスを手配するうえで重要なのは、あらゆるIT業務、特にインシデント管理や、

従来ITが扱ってきたトランザクション寄りの業務を社外のベンダーに任せるということ、つまり社

内では業務の管理も割り当てもいっさい不要になるということです。ベンダーには、「お願いしたい仕事はこれで、結果はこのような方法で評価します。」と伝えるだけです。

私たちは、ベンダーを評価する方法と、契約との関係を管理する方法を決めなければなりません

でした。マネージドサービスの手配に影響する要素はそれだけです。買うのはサービスであって、ものではありません。そのため、私たちは早急な再編成が必要となり、しかも残された時間は60日間しかなかったのです。

これは私たちにとって大きな方向転換でした。ITは小規模で社内にあったことから、評価基準は

必要不可欠なものではありませんでした。弊社には少なくとも4つのインシデント管理システムが

あり、変更管理はいくつかのアプリケーションで実施されていました。需要管理と構成管理は、エクセル天国としか言いようのない状態でしたし、あらゆるものがスプレッドシート形式で50部もコ

ピーされ、いたるところに分散していました。

「ServiceNowは驚くほどアジャイルです。スケーラビ

リティを気にする必要はありません。必要なことは、

人が吸収できる速さで機能をロールアウトすること だけです。」

ServiceNowのこのケーススタディは、当時Sony Pictures EntertainmentのITディレクタだった（現在はAlvarez and Marsalの業績改善部門責任者）Gustav Hoyerによる「Knowledge 11」のプレゼンテーションに基づいてい

ます。

特長

SLA主導のITを企業内企業として管理

組織

Sony  Pictures  Entertainment  

業種

エンターテインメント、映画製作

本社

米国カリフォルニア州カルバーシティー

対象地域

全世界

最新のITSMソフトウェア

インシデント管理  

ナレッジ管理  

問題管理  

変更管理

需要管理

実装の所要時間

60日間

ケーススタディ

地域は、米国、アジア太平洋、ヨーロッパ、南米の4つに大別されます。どの地域でも、

一定レベルのチケット処理とサービスリクエストはRemedyで処理されていましたが、

一般的なツールであることを除けば、なんの規則も基準もない状態でした。

新しいベンダーが来て、弊社に必要なの

はインシデント管理、ナレッジ管理、変更管理、問題管理であると教えてくれました。

弊社はそれまで、RemedyとProject Portfolio Management（PPM、HPの製品）

を運用していましたが、ライセンス上の制約を考えると、このプラットフォームにス

ケーラビリティは期待できませんでした。思い切った決断が必要になったため、弊社

は、ServiceNowを含めた数社に対し、小規模な提案依頼を実施しました。

ITのバリューチェーン ITの下位組織にはバリューチェーンがあり

ます。バリューチェーンとは、各組織が価値を生み出すために実施する活動を表す

方法のことを言います。組織のあらゆる活動を総合的に把握し、その活動を連鎖的

に示し、コンテキストを明らかにするというのが、バリューチェーンの考え方です。部

門としてのITの本質は、社内で運用上の価値を生み出すことにあります。

これに結び付くのが、ServiceNowとITILで

す。ITILのフレームワークを利用すれば、ITが実施する機能とサービスを引き受け、標

準的な体系で提供し、そのサービスを業界標準としてパッケージすることができるから

です。ITILは、同業他社の業績や、他業種企業の業績、そして自社の状況を比較する

ベンチマークを提供します。

実装を開始するにあたり、私たちは「この

バリューチェーンに、IT自体を当てはめ

てみたらどのようになるだろうか」と問いました。ITを企業内の企業としてとらえて

みてください。このバリューチェーンが60日間というこの短期実装の成功に役立っ

た理由が理解いただけるでしょう。

以下の図は、標準的なバリューチェーン

モデルにITを当てはめたものです。ITの

リーダーシップ、管理、戦略、計画、エンタープライズ標準、ガイドライン、プロジェ

クト管理、プログラム管理などが並んでいます。

紫のエリアが製品開発部門、青がサプライチェーン、赤がカスタマサポート部

門です。

•  まず、需要管理が先頭にあります。ITにおけるマーケティングの業務は、以

下のような質問に答えることです。 「顧客が求めているものは何か? 顧客

は何を必要としているのか? 何をめざしているのか? 彼らのビジネス戦略

は? どのようにしてそこに到達するのか? テクノロジを決定する要因は何

か?」

•  組織にビジネスリレーションシップマネジメ

ント部門がある場合には、アーキテクチャ

が次に続きます。研究開発部門、あるいは純粋な技術研究を行う部門がある場合、

そこで問われるのは「初期ツールをどのように確保するか。顧客を満足させるツール

をどのように手に入れるか、または構築するか」ということです。

•  次に、その実施方法の計画を始めます。

これに当たるのがプロジェクトポートフォリオ管理、需要計画、およびリリース管

理基準です。ここで、開発サイクルのスケジュールと開始を行います。

•  次が、プロジェクトプログラムの管理と監

督の部門です。調達およびベンダー管理では、製品を組み合わせる、あるいは製

品を調達するための人材やソフトウェアを確保する方法を考えます。

•  ソリューションデリバリはまだ構築されて

いません。ちょうど、みなさんが今、ServiceNowプラットフォームJavaScriptを書いているように、昔ながらのコーディング担当者が机に陣取ってソフトウェアを

書いています。

•  変更管理とリリース管理では、スケ

ジュールと管理、追跡を行い、影響を

特定します。

•  インフラストラクチャの運用では開

発した成果物を顧客にどのように

提供するかを考えます。顧客の玄関口で製品を渡してくればそれで

終わりというのではなく、どのように消費者製品のフルフィルメントを行

うかを考えます。つまり、ITは継続的なフルフィルメントなのです。

「私たちは、ベンダーを 評価する方法と、契約と

の関係を管理する方法を

決めなければなりません

でした。マネージドサービ

スの手配に影響する要素

はそれだけです。買うの

はサービスであって、もの

ではありません。そのた

め、私たちは早急な再編

成が必要となり、しかも残

された時間は60日間しか

なかったのです。」

ITバリューチェーンの自動化

ケーススタディ

導入は単独の行為ですが、サプライチェーンからの需要のフルフィルメントは、1回で終わることはありません。だからこそデータセンターとオペレーションチームが必要になるので

す。

•  社内ITですから、典型的な方法で自分の会社にものを売るわけではありません。「X、Y、Zのプロジェクトを来週までにお買い上げいただければ、50万ドルでご提供できますが、それ

を過ぎると75万ドルになります」というような仕事ではないのです。それでも私たちは、顧客が得られる価値について伝えるために、なぜそれほどITコストがかかるのか、それを正当

化できる合理的な説明を常に行っています。そうした情報を顧客に返すために用いるのが、スコアカードとコミュニケーションです。「これが、私たちのサポートの結果として実現できる

ことです。ITがなければ実現できなかったでしょう。」

•  最後に、おなじみの機能としてサービスデスクとインシデント管理があります。IT関係のこと

を、顧客はどのようにリクエストするでしょうか。それが達成されたこと、評価されたことは、

どうやって確認しますか。

こうしたバリューチェーンを通じて、各エリアの状態を把握することができます。たとえば、ここ

にプロセス指標がない、プロセスの定義がない、あれやこれが機能するようなトレーニングを

実施していない、といったことがわかります。私たちの仕事は、見逃している決定事項を経営陣にすべて把握してもらうことです。そこで、バリューチェーンが有効なコミュニケーションツー

ルとなります。ITは企業内の企業であり、これらの要素がどのように連携しているかは、でたらめな見方で把握することはできません。

次に、この図の下段に並んだ項目別に、実装を分類します。

実装 マネージドサービスへの移行について、簡単に財務的な評価を行いました。Remedyをホス

トしていた状態からServiceNowに移行するので、資産を帳簿から消却します。サービスとソフトウェアを所有形態からライセンス方式に移行する場合に、原価消却と減価償却が必要に

なるのは、ライセンスモデルが資本支出ではなく営業経費だからです。そのため、ServiceNowとRemedyの比較に2、3週間を費やしました。

3月1日、私たちはServiceNowの採用を決定するとともに、統合パートナーとしてNavigisを

選定し、次の言葉でプロジェクトを始動しました。「弊社はツールをカスタマイズするつもりはありません。その実績を前提に考えて、ServiceNowをそのまま使います。インシデントはこ

のように動きます。以上」。私たちは、ServiceNowの機能に合わせて私たちのプロセスのほうを変えました。30日間で8,000のユーザーを置き換え、そのすべてをServiceNowに移

行しました。3月はただでさえ忙しい、修羅場を迎える時期ですが、何とか乗り切りました。

ITバリューチェーンの自動化

「私たちの仕事は、見逃

している決定事項を経営

陣にすべて把握してもら

うことです。そこで、バ

リューチェーンが有効な

コミュニケーションツール

となります。ITは企業内

の企業であり、これらの

要素がどのように連携し

ているかは、でたらめな

見方で把握することはで

きません。」

ケーススタディ ITバリューチェーンの自動化

「CMDBでアプリケーション

をリストアップし、ボタンを

追加しました。これで、

インドにある第1レベルの

サービスデスクは、[Route]ボタンをクリックするだけで、

チケットを発行して別部署

での解決を依頼できる

ようになります。何も考える

必要がありません。」

設定項目（CI） - CIの設定および割り当てグループとともに、ServiceNowのCMDBを利用し、CIをアタッチしてルーティングを自動化しました。CMDBでアプリケーションをリストアップし、ボタンを追

加しました。これで、インドにある第1レベルのヘルプデスクは、[Route]ボタンをクリックするだけで、

チケットを発行して別部署での解決を依頼できるようになります。何も考える必要がありません。CIはインシデントとうまく連動するので、ほとんどのルーティングが自動化され、トレーニングも最小限

で済むため、プロセスの完全移行が可能になりました。人間が手動でチケットを再割り当てするの

ではなく、CMDBによってルーティングできるようになり、チケットの扱いについてトレーニングが不

要になるというメリットがあります。その知識をシステムに活かせば、適材適所を実現できることになります。ルーティングを誤る可能性もないではありませんが、それはいつでも起こりうることで、し

かも修正がきくことです。少なくとも、無秩序にルーティングの誤りが起きることはなくなります。

問題管理 - ここでも同じように、ロールアウトに必要な設定は最小限です。移行前には問題管理の

プロセスはありませんでしたが、最も困難だったのは、問題管理がインシデント管理とどう違うのか

を説明することでした。インシデント管理の目標は、手段を問わず、ユーザーが作業を続けられるよ

うにすることです。問題管理は、サービスの復旧後にその原因を解明することです。非同期の作業なので、ユーザーを何もせずに待たせることはありません。ITIL上重要なこの区別がついていない

と、チームは「お客様からメールがありました。今すぐ根本原因を突きとめて、サービスを復旧する

必要があります」などと言いだしかねません。サービス復旧より問題解決にエネルギーが費やされ、

ユーザーはにっちもさっちもいかなくなります。

変更管理 - 変更管理は、比較的成熟していました。変更管理についてITILのトレーニングは実施

済みで、ITILの実装も数年前に済んでいました。変更管理のマネージャもいたので、変更管理に移行はスムーズでした。

需要管理 - オフショアのマネージドサービスプロバイダがいるので、これは厄介です。これに費や

す作業量を検討しなければなりません。プロバイダは、対価に見合う成果物を提供しているか、ど

うやって確かめればいいのでしょうか。中規模の強化依頼からインシデント管理まで、あらゆる点に

ついてグローバルにとらえる視野が必要でしたが、各チームは個々に需要を追跡しており、それを

構造化する手段はありませんでした。 Remedy ITSMとHP PPMの時代には、ITに求められるすべての要求、それこそ、「ネットワークプ

リンタを使えるようにマッピングしてください」といったことから、「ハンガリーでSAPを実装してくださ

い」といったことまでを連続的に需要とみなし、それを中心にしてアーキテクチャを構築していました。

これを分割し、ひとつひとつを追跡して、それに応じて特定のベンダーを評価する方法が必要でし

た。私たちが考えついたのが、需要のピラミッドです（下図を参照）。

ケーススタディ

•  最下部は、サービスデスク部門で最も頻繁に、また最も短いターンアラウンドで行われる一般的なトランザクションです。その一部が問題化した場合は、問題管理で対処が必要

になります。

•  場合によっては、インシデントまたは問題の解決のために変更管理を開始する必要があ

ります。それがピラミッドの1つ上の段階です。

•  次に、中規模の強化依頼がまとまって来ると、スケジューリングが必要になり、コード

変更に1か月かかります。

•  最後がプロジェクトです。プロジェクトマネージャ、計画、安定したロールアウトが関係し、大

きい資本支出となる部分です。

私たちは常に言い続けました。「これを全部、どうやったら一緒にできるのか。どうすれば、こ

れを統一的なオートメーションプラットフォームにして、ITをスムーズに運用できるのか。作業はチーム間で受け渡しできるが、1つのプロセスが完了したとき、自動的にプロセスを他の

チームに通知して、エラーのリスクを抑えるには、どうすればいいのか。」

私たちは最終的に、オペレーションから戦略までを網羅した1つの大きなスペクトル図を描くこ

とにしました（下図を参照）。「これは破損している」「イベントが検出された」「オペレーションセ

ンターからインシデント発生の報告があった」などから、「何が必要かわからない、ITが何をすべきかもわかっていないが、そこにプレースホルダは必要だ」などまで把握できます。

需要管理モジュールでは、ショッピングカートを応用し、サーベンス・オクスリー法（SOX法）の認証に必要なこととも結び付けました。インシデント管理をロールアウトする際には、

Active Directory - LDAPと統合しました。両方を部分的に利用したので、LDAP統合を行って、社内の各ユーザーをプラットフォームに追加しました。SOX認証を取得でき、SOXを必

要とするCIをカスタマイズしてその設定をCIに適用し、需要管理においてSOX認証メカニズムを推進することができました。

ここで3段階のSOX認証を導入することで、コンプライアンス担当者にもこのプラットフォームが適している理由を納得してもらえました。これで、基本的な必須作業を行う場

所、スケジュールとプランニングを行う場所、製品として仕上げる場所を合わせたファクトリ全体の概念を把握していることになります。

ITバリューチェーンの自動化

「中規模の強化依頼 からインシデント管理

まで、あらゆる点につ

いてグローバルにとら

える視野が必要でした

が、各チームは個々に

需要を追跡しており、

それを構造化する 手段はありませんで した。」

ケーススタディ

www.servicenow.com ©2013 ServiceNow, Inc. All rights reserved. この資料に記載されている内容は発行時点では正確であると考えていますが、技術的な誤りや誤植が含まれている可能性があります。内容は予告なしに変更されることがあります。記載されている内容は定

期的に変更され、変更内容は資料の追加事項として反映されます。本資料に記載されている製品およびプログラムは任意の時点で改変される可能性があります。書面による事前の許可なく本資料を複写することは禁止されています。本資料の内容は現在の情報をもとに提供されます。ServiceNowは、本資料に記載されている内容に関して、いかなる表明または保証も行っておりません。特に、特定目的に対する市場性または適合性の暗示的な保証は、これを否認します。 ServiceNowはServiceNow, Incの商標です。その他のブランド、製品、サービス名、商標、または登録商標は、各社が所有する製品またはサービスであることを示すために使用しています。

ソフトウェア開発のライフサイクル（SDLC）ワークフロー - 最終的に、まったく新しい形

でITと新しいツールセットを提供できるようになったため、1か月ほどは誰もが困惑してい

ました。新しいプラットフォームに少しずつ順応した段階で、SDLCに取りかかりました。そ

れに取り組みながら私たちが考えたのは、「どのアクティビティにもタスクがあり、そのタ

スクの多くは承認過程が必要なので、ServiceNowを使えば承認に対処できる」と

いうことでした。これまではサードパーティにアウトソーシングしていましたが、信頼性に

欠けるため、あらゆるステップを確実に確認したいと考えています。サードパーティへの

アウトソーシングは、残念ながら不信の上に成り立っており、長続きはしないと認識して

いました。承認やらチェックやらで、15から20のステップがありました。これは非現実的で

す。

ServiceNowでは、すべてのアクティビ

ティに承認が必要だったり、タスクがあっ

たりしません。ユーザーにとっても、それは非常にストレスなことであると、幸いに

も気づきました。タスクの担当者が変わるとき新しい担当者がそれを認識したことを

確認するだけにとどめ、承認は廃止されました。

手痛い教訓で、ユーザー導入までにコストもかかりました。システムのソフトウェアを

書き換えて展開時に変更するのは簡単ですが、人によるプロセスのためのソフトウェ

アは変更に時間がかかります。これは重要なので繰り返しておきましょう。弊社が

ServiceNowに移行したのは、人がくだす意思決定を記録するためであり、

ServiceNowに任せるためではありません。

結論 ServiceNowには深く感銘を受けました。

部署を問わず、プロセス導入とワークフロー管理のための堅牢なプラットフォーム

です。こう言ってもいいでしょう。「インシデント管理を行っています。ITILではそれは

こんなに小さなことだとされています。私たちもその通りにしています。」　私たちは、

プラットフォーム全体がプロセスオートメーションツールであると、すぐに理解したので

す。

ITバリューチェーンの自動化

「ServiceNowには深く 感銘を受けました。 部署を問わず、プロセス 導入とワークフロー管理の ための堅牢なプラット フォームです。」