IT サービスマネジメントフォーラムジャパン
2014.7
2014.7
Newsletter
第 11 回itSMF Japan コンファレンス /EXPO 告知 itSMF Japan コンファレンス担当 3
JICA 沖縄国際センター研修員訪問見学 itSMF Japan 事務局 4
会員寄稿 IT サービスマネジメントとビジネス情報マネジメント 村川 洋介 氏 5 会員寄稿 サービスデスク導入に関する考察 伊藤 俊治 氏 10 会員寄稿 クラウドコンピューティングと ITIL® 的ソーシングのすゝめ ～『借りぐらし』世代の反復的ソーシング・ライフサイクル。 『私たちは、そう簡単に滅びたりしないわ！』～ 小澤 一友 氏 16 会員寄稿
Proactive な Service Transition
～開発と運用の協業（DevOps）および IT 価値向上の実現と人材育成～ 武上 弥尋 氏 24 会員寄稿 脱・IT 後進国への特効薬：これを飲まずして何を飲む –システム運用部門からビジネスパートナへの誘い -近野 章二 氏 33 会員寄稿 運用自動化によるサービス改革の促進 岩村 郁雄 氏 38 ・効果的な問題管理のための 5 つのアドバイス
・IT 変更の失敗を避ける方法 From SERVICE TALK 翻訳記事 44
新分科会紹介 バリューコストマネジメント研究分科会 52
新理事紹介 itSMF Japan 理事 伊藤 清 54
itSMF Japan 関西支部報告 itSMF Japan 関西支部 55
第 11 回通常総会報告 itSMF Japan 事務局 56
目次
2014.7 月号3 SMF Japanでは地球環境に配慮し、エコイベントを実施いたします。 ◎ 主 催
特定非営利活動法人
itSMF Japan
◎ 共 催日経
BP
イノベーション
ICT
研究所
2014
年
11
月
13
日
［木］
-14
日
［金］
ガーデンシティ品川
（東京・SHINAGAWA GOOS 1F)企業の成長戦略を加速する
IT サービスマネジメント
－ Social, Mobile, Analytics, Cloud の活用を支える－
企業の成長戦略を加速する
IT サービスマネジメント
－ Social, Mobile, Analytics, Cloud の活用を支える－
参加者募集は、 9 月中旬を予定しております。 皆様、 奮ってご参加ください。
詳しくは、
itSMF Japan ホームページ （http://www.itsmf-japan.org）
Facebook(http://www.facebook.com/itsmf.japan） をご覧ください。
/
国際協力機構 (JICA) の沖縄国際センター（OIC） IT 研修「電子政府推進のためのシステム運用管理 (B)」コースの研修員が、見学実習として 5 月 13 日 にitSMF Japan 事務所を訪問されました。その目的は、 「システム運用管理業務における知見養成のため、講 義内容の裏付けとして、実例を知り、そこから学ぶ」 ことです。 4 回目となる今回は、ガーナ・タンザニア・ザンビア・ コソボの 4 ヵ国 8 名の研修生が訪問されました。
itSMF Japan からは、富田理事長より itSMF Japan の IT サービスマネジメントの普及啓蒙活動のご説明 を行い、小山事務局長からは「ITIL® の概要」をご説 明しました。そして最後に、前回に引き続き ITIL® の導入事例として KVH 株式会社シニアプロジェクト マネージャ小渕様より『サービスマネジメントを実 現するための 5 つのステップ～ドラッカー流サービ スマネジメント導入アプローチ～』について、ご説 明いただきました。 OIC 様からは、「研修員が ITIL® の有用性に関する 理解を深める良い機会となったと考えております。 また、研修員が帰国後にアクションプランとして ITIL® に説明されているシステム管理プロセスを自組 織に適用する際、本見学で得た多くの情報は、大変 役に立つものと考えております。質疑応答において も各質問にていねいに対応いただき、誠にありがと うございました」とのコメントをいただきました。 研修員の方々とは 2 時間半にわたって、活発な意 見交換を行いました。後日、研修員の方々より以下 のような感想をいただきました。 ・すべての講演が非常に有益であった。 ・事例から学ぶものが多く、自組織にも活用可能と感 じた。特に ITIL®の導入ステップが実に素晴らしい。 この事例を共有いただいたことに感謝する。 ・最初に経営層の支持を取り付けておくことが成功へ の道のりに繋がることを教えてくれた。プロセスが 失敗に終わる原因には、プロセスが適切でないので はなく、経営側がそのプロセスの導入に関心がない ことに起因する場合もあると思う。 ・進捗状況を判断するために、評価や測定は非常に重 要であることを学んだ。 ・サービスマネジメントを成功させるための 5 つのス テップは素晴らしい。知識やツールを持ち合わせて いても、良いタイミングでその知識を活用できる能 力こそが、違いを生み出すことのできる源だと思う。 ・3 年間でサービスマンジメント改革を成し遂げた KVH 社の事例は、ベストプラクティスであり、よい学び の経験となった。ITIL®を活用したサービスマネジメ ント改革をぜひ自組織にも導入していきたい。 ・ITIL®のフレームワークと範囲をよく理解できた。 ・多くの企業の成功を支援する大きな役割をitSMF は担 っている。ITIL®によって、企業の収益と継続性を最 適化する持続的なビジネス手法をitSMF は推進してい る。NPO としてこのような大きな支援を行っていると いう事実は、我が国では考えられないことである。 ・ITIL®のための TIPA のプロセスアセスメントモデルを 導入すると、理想的なプロセスを把握したうえでどの ような改善が必要かを理解できるようになると思う。 やはり、導入事例を聞くことにより研修員の理解が 深まっているようです。小渕様、事例発表ならびに 質疑対応ありがとうございました。この場を借りて 御礼を申し上げます。 (itSMF Japan 事務局 )
JICA 沖縄国際センター研修員訪問見学
第 4 回（2014 年 5 月 13 日）
～海外 4 ヵ国の方々と意見交換～
会員寄稿
IT サービスマネジメントと
ビジネス情報マネジメント
I はじめに - ビジネス情報マネジメント（BIM）とは サ ー ビ ス・ マ ネ ジ メ ン ト の 領 域 に お い て、 ビ ジ ネ ス 情 報 マ ネ ジ メ ン ト Business Information Management（BIM）という概念が定義されている。“Business information management is the means by which an organization efficiently plans, collects, organizes, uses, controls, disseminates and disposes of its information, and through which it ensures that the value of that information is identified and exploited to the fullest extent.” [1]
ビジネス情報マネジメントとは、ある組織が持て る情報を効果的に、計画し、収集し、編成し、利用し、 コントロールし、広め、廃棄するためのものであり、 またそれを通して、情報の価値を特定し最大限に有 効利用することを、確実にするものである。
BIM は、IT により自動化されたものと EUC のよう に自動化されていないものの双方を含む、情報の最 適な提供と利用および保守についての、ユーザ組織 の責任を規定している。
BIM の 代 表 的 な フ レ ー ム ワ ー ク と し て、 ヨ ー ロ ッ パ を 中 心 に 利 用 が 広 が り 始 め て い る Business Information Services Library (BiSL®) が あ る。 BiSL® は ITIL® を意識して構成されたビジネスユーザ 向けのフレームワークであり、相互の関連について の分析も進められている [2]。ITIL® においても「ビ ジネスユーザおよびビジネスニーズに貢献する IT サ ービスの提供」という観点はその重要性が認識され てきており、この点で ITIL® と BiSL® は相補的な関 係にあると言える。実際に US では、ITIL® コミュニ ティにおいて BiSL® の勉強会が積極的に実施されて いる [3]。 この稿では、日本ではまだ知られていない BiSL® フレームワークの概要を紹介し、BIM の考え方と IT サービスマネジメントの関連を考察する。また国内 で初めて BiSL® を実際に適用したプロジェクト事例 を紹介し、その有用性と今後の展望について述べる。
*ITIL® is a Registered Trade Mark of AXELOS Limited
*BiSL® and Application Services Library (ASL®) are registered trade marks of the ASL BiSL Foundation.
II BiSL® を取り巻く状況
BiSL® は、 オ ラ ン ダ に 本 拠 を 置 く NPO 組 織 ASL BiSL Foundation が知的所有権を持つ、ベンダー独立 でパブリックドメインの BIM 適用フレームワークで ある。フレームワークを定義した書籍と多数のホワ イトペーパーが用意され、認定資格が発行されてい る [4]。
BiSL® の 歴 史 は、1997 年 に Dutch Computer Center, RCC で開発された FBM と呼ばれる情報管理 のフレームに遡る。2002 年設立の ASL Foundation （後の ASL BiSL Foundation）に移管された後、2005 年に BiSL® 1st Edition が公開された。2012 年には 2nd Edition が公開され現在に至る。
ジ メ ン ト の フ レ ー ム ワ ー ク と し て、Application Services Library（ASL®）が定義され、同団体から 公開されている。 BiSL® 用語集として、英語、オランダ語、スペイ ン語、ポルトガル語、フランス語、ロシア語、中国語、 そして日本語版が公開されており、実績としては主 にヨーロッパ諸国で利用されている。特にオランダ では、ASL BiSL Foundation のマネージングパート ナーとしてオランダ国防省とオランダ国税庁が参加 している関係から、IT システムの政府調達において 「BiSL® Certification を持っていることが強く推奨 される」という入札条件が付くこともある。 ITIL® との関連においては、英国のitSMF UK 主催 のカンファレンス ITSM において、2012 年、2013 年 と 連 続 し て ASL BiSL Foundation の Mark Smalley 氏によるフレームワーク紹介の講演やワークショッ プがおこなわれている [5]。
また米国では、itSMF US と ASL BiSL Foundation の共同プロジェクトで、BiSL® 入門用の教育パッケ ー ジ ”BiSL® in a Box" が 開 発 さ れ、2013 年 か ら 各地の支部（LIG）で学習会が開催されている [3]。 itSMF US の Web サイトでは、トップページに BiSL® Group and blog のリンクが設置されており、すでに 一定の認知を得ていることが伺える [6]。
日本国内では、2013 年に筆者らのグループが日 本語版用語集の作成やホワイトペーパーの翻訳を開 始した。2014 年には ASL BiSL Foundation - Japan Ambassador が設置され、本格的な展開の準備をおこ なっている。
III BiSL® と IT サービス・マネジメントの関連
1 BiSL® と ITIL® の比較
ASL BiSL Foundation と、ITIL® の出版元であった The Stationery Office（TSO） は、BiSL® と ITIL® のフレームワークの相乗効果と相違点についてのガ イダンスを提供するために、共同でホワイトペーパ ーを作成した。[2] このホワイトペーパーによると、BiSL® と ITIL® は表Ⅲ -1 で示すように、ビジネス上の価値を可能 にするための情報システムの構築、維持、管理に必 要な、ユーザ組織と IT サービス・プロバイダ双方 の活動について、互いに補完する立場からのガイダ ンスを提供していることがわかる。 BiSL® ITIL® スコープ ユーザ組織の中で実施 される BIM の活動をガ イドするプロセスモデ ル。ビジネス・プロセ スで必要な情報を、効 果的かつ効率的な方法 で取得するために、需 要側で実行する必要の あるすべての活動を対 象とする。 IT サービスマネジメン トのベスト・プラクテ ィスをまとめたフレー ムワーク。ビジネス上 の価値を可能にすると いう観点から、サービ ス・ライフサイクル全 体の、IT サービスマネ ジメントの指針を提供 する。 BIM に つ い て の 記 述 もっぱら BIM を確立す ることが目的であり、 情報システムの機能を 積極的に管理・維持し、 サポートするユーザ組 織の活動のガイダンス を記述している。 明示的に BIM には言及 していないが、IT サー ビス・プロバイダの役 割を果たすための前提 条件として、BIM に含 まれる活動を説明して いる。 視点 ビジネス組織（ユーザ） からの視点 IT サービス・プロバイ ダからの視点 表Ⅲ -1 BiSL® と ITIL® の比較（[2] を元に作成） 2 比較表についての考察 最も特徴的な差異は、ITIL® では IT サービス・プ ロバイダの視点から、ビジネス上の価値を可能にす る IT サービスマネジメント活動を定義しているの に対し、BiSL® では、ユーザ組織の視点から、ビジ ネスで必要な情報の維持・管理のための活動を定義 している点にある。 情報システムの計画、構築、保守運用、拡張とい ったライフサイクル全体において、情報システムの 効果的な利用のためには、ユーザ部門と IT サービス・ プロバイダは緊密に連携して活動する必要がある。 その際に、相互に補完するフレームワークを活用す ることで、それぞれが果たすべき役割と責任を明確 にできれば、非常に有効であると考えられる。 IV BiSL® のフレームワーク BiSL® のフレームワークは、戦略、管理、運用の 3 つのプロセスレベルに配置された、7 つのプロセ ス群から構成されている（図Ⅳ -1）[7]。以下に、 これらプロセス群の概要を紹介する。
図Ⅳ -1 BiSL® フレームワーク（[7] を元に筆者が日本語化） 1 運用プロセスレベル 運用レベルのプロセスには、利用管理プロセス群、 機能管理プロセス群、およびその間をつなぐ接続プ ロセスが含まれる。 1) 利用管理プロセス群 ビジネスで必要な情報を、継続的に最適な状態で提 供するためのサポートを目的とするプロセス。IT サ ービス・プロバイダに対する運用管理や、データ提 供の運用監視、情報を利用するユーザへのサポート 提供が含まれる。 2) 機能管理プロセス群 情報提供の機能を変更する際の、要件の明確化から 設計、開発、テスト、移行までの期間のプロセスを 記述する。フレームワークに整合する形で、ユーザ の目的と需要を満たした情報提供機能の変更が実施 されるように管理することが目的となる。 3) 運用レベルでの接続プロセス群 利用管理と機能管理のプロセス群を連携し、情報提 供機能にどのような変更が加えられるべきか（変更 管理）、および、情報提供機能の変更が、ユーザ組 織内で実際にどう適用されるか（移行管理）を判断 するためのプロセスを記述している。 2 管理プロセスレベル 管理レベルのプロセス群は、これまでに述べてきた 運用レベルのプロセス群を、正しく管理することが 目的となる。 1) 管理プロセス群 管理プロセス群には、計画立案とリソース管理、財 務管理、需要管理、契約管理の４つのプロセスが含 まれる。これらのプロセスでは、合意されたコスト と便益、要求、IT プロバイダーとの契約とサービス レベル、および計画に留意して、活動をモニターす る。 3 戦略プロセスレベル 戦略レベルのプロセスには、情報戦略プロセス群、 I- 組織戦略プロセス群、およびその間をつなぐ接続 プロセスが含まれる。 1) 情報戦略群 組織をとりまく環境や、組織自体のビジネス・プロ セス、および部署への情報提供に影響を及ぼすあら ゆる種類の変化を考慮して、情報提供機能が将来の 需要に適合し、現在の状況の構造的な欠陥を解決す るように、情報提供の戦略を策定するプロセスを記 述する。 2)I- 組織戦略群 I- 組織とは、情報提供をコントロールする組織もし くは部署と定義される [7]。情報提供には、通常複 数の組織が関わることになる。I- 組織戦略プロセス 群では、この情報提供に関わる各組織が、適切に管 理及び意思決定できるようにするためのプロセスが 記述される。これは外部にいる関係者、例えば、サ プライヤーや、サプライチェーンのパートナーや、 ユーザ組織などとの関係にも適用される。 計画立案と リソース管理 財務管理 需要管理 契約管理 情報 コーディ ネーション 利用管理群 機能管理群 ビジネス・プロセス 開発の確立 情報戦略群 戦略的 サプライヤ管理 戦略的 情報パートナー 管理 I-組織戦略 の定義 戦略的 ユーザ関係 管理 I-組織戦略群 情報 ライフサイクル 管理 情報連鎖開発の 確立 技術開発の 確立 変更 管理 移行 管理 情報 ポートフォリオ 管理 戦略プロセス 管理プロセス 運用プロセス 情報要件の 明確化 自動化されていない 情報システムの 設計 移行準備 レビューと テスト 運用的 サプライヤ管理 ビジネスデータ 管理 エンドユーザ サポート
3) 戦略レベルの連結プロセス 戦略レベルの連結プロセスは、関与するすべての当 事者の調整と、情報提供の様々な要素に対する計画 の調整を目的とする。I- 組織戦略で扱う各組織では、 さまざまなレベルで情報提供に関わる計画やポリシ ー、情報戦略が策定される。これらを互いに調整し 統合する情報コーディネーションが、戦略レベルの 連結プロセスとして記述される。 近年、より多くの組織間での相互情報連携が進み、 またアプリケーション・パッケージや ASP の利用が 増加している状況で、情報戦略と組織間の調整は、 複雑さと困難さを増してきている。関係組織間の調 整プロセスを明確化して、情報戦略の全体最適化を 図ることが重要となる。 4 フレームワークの活用についての考察 これまで見てきたように、BiSL® はユーザ側の視 点から情報提供の機能を管理、利用するためのプロ セスモデルを提供している。このフレームワークの 活用方法としては、例えば次の 2 つのシーンが想定 される。 1) ユーザ組織へのコンサルティングツールとして 情報の利用者でありオーナーであるユーザ組織が実 施するプロセスとして、例えば企画部門等の情報シ ステム整備計画で、戦略レベルプロセス群を採用す ることが考えられる。この場合、ユーザ部門自身が プロセスを構築するために、BiSL® のフレームワー クに習熟したコンサルタントが、助言などの支援を 提供することが有効であると考えられる。 これは BiSL® が本来想定する活用方法である。 2)IT サービス・プロバイダからユーザへの連携ツー ルとして情報システム構築プロジェクトやシステム 運用の開始時に、運用レベルプロセスを、IT サービ ス・プロバイダとユーザ組織の間の役割と責任を定 義するためのフレームワークとして活用することが 考えられる。BiSL® 自体は、ユーザ組織側の視点か ら役割と活動が整理されているため、IT サービス・ プロバイダが BiSL® を理解しユーザ組織との調整に 活用することで、円滑に合意形成を図る効果が期待 できる。 BiSL® で定義されているプロセスや活動は、決し て新規で独特なものではない。特に運用レベルプロ セスの活動は、IT サービス・プロバイダの立場から すればむしろオーソドックスな、当然必要とされる ものばかりである。しかしながら、その活動をビジ ネスユーザ側の視点から整理し、戦略立案から開発・ 運用まで体系化していることに意味があると考えら れる。 ビッグデータやクラウドサービスの活用など、ビ ジネス情報提供の意味する範囲は、旧来の狭い意味 での IT システム構築に限らなくなってきている。そ のため、経営の根幹としてビジネスユーザが主体的 に情報戦略立案から環境整備まで関わる必要性は、 ますます増してきている。ユーザ視点での BIM のフ レームワークの果たす役割は、今後さらに重要性を 増してくると考えられる。 V 国内プロジェクトへの BiSL® 適用事例 筆者は国内のシステム導入プロジェクトにおい て、プロジェクト・マネジメント・オフィス（PMO） として、ユーザ部門とシステム部門の連携を図る立 場で BiSL® の運用レベルプロセスを実際に適用して みた。 BiSL® はフレームワークでありメソドロジーでは ない。つまり、プロジェクトの進め方や成果物テン プレートが用意されているわけではないが、「考え 方の枠組み」としてガイドラインのチャートを利用 することが可能である。例えば、要件定義フェーズ でのユーザ部門とシステム部門、IT サービス・プ ロバイダ間の役割を定義するために、機能管理群の プロセス関連図を使用するなどの方法を試行してみ た。結果としてプロジェクトは無事サービスインを 迎え、ユーザ部門のメンバからは「自分たちが実施 しなければいけないアクティビティがよく整理され ており、理解しやすかった」などの感想が聞かれる など、一定の効果はあったと考えられる。 今回のプロジェクトは、国内における初の適用事 例として、フレームワークの有効性を試験的に確認 することが目標であったため、定量的な導入効果の 測定などは実施していない。可能であれば今後、定 量的、定性的な導入効果の測定を検討したいと思う。
VI おわりに
BiSL® のフレームワーク定義 [7] は書籍および電 子書籍として提供されている。またベストプラクテ ィスなどを報告した多数のホワイトペーパーが、ASL BiSL® Foundation の Web サイト [4] で公開されてい る。 II でも触れたが、筆者らはこれらの文書を日本語 化し、多くのビジネスユーザや IT サービス・プロ バイダがアクセスしやすい環境を整えるための活動 を、ボランティアでおこなっている。今後、コンフ ァレンス等の機会を活用して、BiSL® の具体的な内 容を紹介していきたいと考えている。 参考文献
[1] Business Information Management, Mark Smalley, ASL BiSL Foundation, 2012
[2] ITIL® and BiSL®: sound guidance for b u s i n e s s - I T a l i g n m e n t f r o m a b u s i n e s s perspective, Machteld Meijer, Mark Smalley, Sharon Taylor and Candace Dunwoodie, ASL BiSL Foundation, AXELOS Limited and the Cabinet Office, 2013
[3] BiSL in a Box : itSMF US Web サイト： http://www.itsmfusa.org/?page=Pgm_BiSL_in_a_ box
[4] ASL BiSL Foundation Web サイト http://www. aslBiSLfoundation.org/
[5] ITSM 13 ( 第 22 回itSMF UK コンファレンス ) 参加報告 , itSMF Japan Newsletter 2014.1, 中井秀 有 ,2014 (P.21,22 TIMETABLE 中の Sponsor Theatre EXPO HALL Session 4 を参照 )
[6] itSMF US Web サイト http://www.itsmfusa.org/ [ 7 ] B i S L ® - A F r a m e w o r k f o r B u s i n e s s Information Management - 2nd revised edition, Remko van der Pols, Ralph Donatz, Frank van Outvorst, Van Haren Publishing, 2012
村川 洋介 日本アイ・ビー・エム株式会社
マネージング・コンサルタント
ASL BiSL Foundation-Japan Ambassador PMP 日本アイ・ビー・エム入社後、製品開発研究所で PC 周辺機器やネットワーク関連の研究開発に従事。 新規事業開発部門に異動してインターネット技術 を活用した新サービスの開発から、SI 部門での流 通業、金融業などのシステム開発プロジェクトの PM を経験。2006 年ビジネス・コンサルティング部 門に異動し、現在は主に会計システム導入のコン サルティングを実施。
会員寄稿
サービスデスク導入に関する考察
I. はじめに システム（パッケージの場合もある）の開発およ びサポートを主業務としている組織では、図Ⅰ―1 の ように、複数のシステムをそれぞれ別の担当者がサ ポートしているケースが多く見られる。 このような状況では、お客様は、窓口が複数存在 することで、システム毎に問合せを行う窓口が違う 不都合が発生する。また担当者が属人化していて、 担当者が捉まらない状況が発生しやすい。 一方、サポート担当者は、メイン業務の開発の片 手間で、以前開発に携わったシステムのサポートを 行わなければならず、非常に大きな負担となってい るケースが多い。 これらの問題を解決するために、窓口を一本化し、 専任のサポート要員を置くことで解決を目指すがな かなかうまくいかないケースが多い（図Ⅰ―2 参照）。 窓口を一本化し、サービスデスクを導入する場合の 成功要因とは何なのか以下で考察を行う。更に、サ ービスデスクを導入した後、サービスデスクをプロ フィットセンターとして運営するための成功要因に ついても考察を行う。 II. コール・センタを利用した場合の考察 まず始めに 1 次窓口を一般のコール・センタに依 頼した場合（図Ⅱ－ 1）についての考察を行う。コール・ センタ業界は既にビジネスモデルとして確立してお り、サービスデスクのプロフィットセンター化を考 えるうえで参考になると考えられる。 1. サービスデスク／コール・センタの定義 まずは、サービスデスクとコール・センタの違い を明確にするために、サービスサポート（V2）での 定義の確認を行う。定義は以下の通り。コール・センタ 商品の通信販売サービス（例えば銀行や保険） 向けの電話ベースの取引の膨大なコールを専門 的に処理することに主な重点が置かれている。 ヘルプデスク 主な目的は、インシデントを管理、調整、およ び出来る限り迅速に解決すること、および要求 が紛失、忘却、そして無視されないことを保証 することである。一般的に、技術支援として、 構成管理や、ナレッジ・ツールへの関連付けが 利用される。 サービスデスク サービスデスクは、サービスの範囲を拡張し、 より広い視野を持ったアプローチを提供するこ とで、ビジネス・プロセスをサービスマネジメ ント・インフラストラクチャに統合することを 可能にしている。サービスデスクは、インシデ ント、問題、そして質問に対応するだけではない。 例えば、顧客の変更要求、保守契約、ソフトウ エア・ライセンス、サービスレベル管理、構成 管理、可用性管理、ＩＴサービス財務管理、そ してＩＴサービス継続性管理等の他の活動との インタフェースも提供している。 また、ITIL® 入門（V2）での定義は以下の通りと なっている。 コール・センタ コールを記録するだけでソリューションの提供 は行わない。コールは専門部門に回され、そこ で対処する。コールの記録とルーティングは音 声応答システムで自動化できるケースもある。 非スキル型 サービスデスク、 または、 コール記憶型 サービスデスク コールを記録し、一般的な用語で説明を行って、 ただちに他の部門に回す。サービスデスクは概 して他部門に早く回すことが機能であり、コー ルの取扱いを期待され、幅広い標準的な手順、 コールに対応するためのスクリプト、規範、経 験のあるマネージャが必要となる。このアプロ ーチの利点はインシデントの記録のしかたが統 一されることである。欠点は対応時間が長くな り、初回のコールでの解決率がスキル型サービ スデスクよりかなり低くなる。 スキル型 サービスデスク 優れたスキルと経験を有している。文書化された ソリューションを使って多くのインシデントを解 決するが、インシデントによってはサポート・チ ームに回すものもある。初回のコール解決率は一 般にヘルプデスクよりも格段に高くなる。 エキスパート・ サービスデスク 全 IT インフラストラクチャに関する専門的知 識と、ほとんどのインシデントを独りで解決す るだけの知識を有している。 以上の定義をまとめると以下のようになると考え られる。 サービスサポート（V2）のコール・センタの定義「商 品の通信販売サービス（例えば、銀行や保険）向け の電話ベースの膨大なコールを専門的に処理するこ とに主な重点がおかれている。」の記述の通りコー ル・センタでは「膨大なコール」が一つのキーワー ドとなる。コール・センタがビジネスとして成り立 っているのは大量呼を処理することで、システムサ ポートで発生することが多い待機時間を回避できて いることが、ひとつの大きな要因となっている。見 方を変えると、図Ⅰ―1 のシステムサポートの形態 は、開発の空き時間でシステムサポートを行うこと で待機時間をなくすることができている。 もう一つのサービスデスクとコール・センタの違 いは ITIL® 入門（V2）のコール・センタの定義「コ ールを記録するだけでソリューションの提供は行わ ない。」とある通りソリューション提供力となる。 定義通りコール・センタにソリューション提供力が 全くないとは考えにくいが、図Ⅱ－ 1 のように 1 次 窓口にコール・センタを活用した場合、ソリューシ ョン提供力をある程度持てたと考えた場合でも非ス キル型サービスデスクになると考えられる。 一方、サービスデスクの導入成功には、スキル型 サービスデスクあるいはエキスパート・サービスデ スクであることが、ITIL® 入門（V2）の定義から考 察できる。非スキル型サービスデスクでは、対応時 間が長くなり、1 次回答率が低い状況が発生する。 顧客からみるとサービスデスクを導入したことで回 答時間が長くなり、サービスの質が落ちてしまうこ ととなるからである。 サービスデスク導入の成功には何が必要なのであ ろうか。第一の成功要因はスキル型サービスデスク 以上のソリューション提供力をサービスデスクが持 たなくてはいけないということになる。しかし、サ ービスデスク要員からみると他の担当者あるいは他 の組織が開発したシステムをサービスの品質を落と さずにサポートすることは至難の業である。図Ⅰ－ 1 と同様のサービス品質を保ちながらサービスデス クを導入するにはどうすればよいのか。以下にサー ビスデスク導入成功のためのひとつ方法論を提示す る。
III. サービスデスク導入の成功要因 1. キャプチャー型のインシデント管理 サービスデスクをシステムサポートに導入する場 合、導入初期は、非スキル型サービスデスクになら ざる負えない。サービスデスク要員は、サポートす るシステムにノウハウを持たない、あるいは勉強を したとしても、現行のサポート担当者のノウハウに は遠く及ばないからである。 そこで、導入初期は現行のサポート担当者が今ま で通りサポートを行い、サービスデスクはお客様と サポート担当者のやり取りをキャプチャーしてイン シデント管理のみ行う形態とする。（図Ⅲ―1 参照） キャプチャーによるインシデント管理を行っている 間に①システム内容の教育、②サポートマニュアル の充実（サービスデスクで）③ FAQ の蓄積をするこ とで、徐々にサービスデスクで回答できる内容を増 やしていく。このプロセスを持つことでサービスデ スクをサービス品質の低下なしに導入することが可 能となる。 キャプチャー型のインシデント管理行う上で大切 なことは、インシデント管理の責任はサービスデス クが持っていることを明確に意識することである。 例えば、2 時間以内に回答を行う SLA となっていた 場合、2 時間以内に回答できるようにサービスデス クが担当者のマネジメントを行う。専任のサービス デスクがマネジメントを行うことで、サービス品質 の向上につながる。 2. 対応チャネルはメールが基本（メーリングリスト活用） キャプチャー型のインシデント管理を行うには、 メーリングリストを活用したメールでの対応が基本 となる。どうしても電話を利用せざる負えないとき は現行対応者に電話での顧客とのやり取りの内容 を、内容の確認という形でメールでお客様に送信して もらい、それをサービスデスクがキャプチャーする。 顧客にとっては、導入初期は今まで通り担当者が 対応してくれ、かつ図Ⅰ－ 1 の形態の対応時には発 生しがちだった担当者が捉まらないというような状 況も回避することができるので、サービス品質の低 下はなくむしろサービス品質が向上した状態でサー ビスデスク導入を進めることができる。 IV. サービスデスク、プロフィットセンター化の成功要因 メーリングリストを利用したキャプチャー型のイ ンシデント管理のサービスデスク導入プロセスを経 た後に、サービスデスクをプロフィットセンターと して運営していくにはどうすればよいのか。 コール・センタのビジネス構造を考えた時と同様に インシデント数（コール・センタではコール数）が一 つの目安となる。インシデント数がある一定以上ない と、プロフィットセンターとしては、非スキル型サー ビスデスクをスキル型サービスデスクに移行できない。 例えば、安定したシステムで、問い合わせや障害が 月に 1、2 件程度しか発生しなければ、サポート費用 も少なく、サービスデスクにかける費用も少なくなる。 当然、サービスデスク要員のスキルアップにかける教 育の費用を捻出することが難しくなり、マニュアルを 作成する費用も捻出することができない。更にインシ デントが少ないため、FAQ は増加しない。そして、何 よりもインシデントが少ないことでサービスデスク要 員がシステムサポートを経験できる回数が少ないこと がスキル型サービスデスクに移行するうえでもっとも 大きな障壁となる。（図Ⅳ－ 1 参照）
インシデント数とソリューション提供力を軸にビ ジネス構造を考えると、図Ⅳ―2 のようになる。 サービスデスクが 1 次窓口を行うにはキャプチャ ー型インシデント管理を利用した非スキル型サービ スデスクから導入を開始する。その中で、採算ライ ンを超えるインシデント数があり、顧客がスキル型 サービスデスクを望む（費用面も含めて）サポート に関しては、教育、マニュアル化、FAQ 充実等でノ ウハウ向上を図り、スキル型サービスデスク／エキ スパート・サービスデスクに移行するというビジネ ス構造が成り立つ。 このビジネス構造では、スキル型サービスデスク の提供が、メイン業務となるので、当然、スキル型 サービスデスクの他組織との差別化を考えなくては いけない。 図Ⅳ―3 にサービスデスクのビジネス構造の 1 つ のモデルを示す。 スキル型サービスデスクを以下に説明するそれぞ れの施策で低価格で提供することで他組織との差別 化を図る。 それと同時に、システムサポートではどうしても 発生する待機時間を利用して非スキル型サービスデ スクを低価格で提供する。 また、キャプチャー型インシデント管理を利用し スキル型サービスデスクにレベルアップすることで メインの業務であるスキル型サービスデスクを徐々 に増やすというビジネス構造が成り立つ。 以下に低価格でスキル型サービスデスクを提供す るための施策を簡単に説明する。 1. 財務管理（スピーディな） 提供サービス毎（システムサポート毎）に毎月ス ピーディな財務管理を実施することで、財務状況を 的確に把握する。 2. 多能工化（マニュアル化） 主にマニュアル化を徹底的に行うことで、サービ スデスク要員が複数システムの対応を行えるように する。ただし、スキル型サービスデスクの対応を一 人が複数システムについて行うのはノウハウの面で かなり大変なので、非スキル型サービスデスクをス キル型サービスデスクの待機時間で行うことでサー ビスデスクプロフィットセンター化で大きな障害と なる待機時間の発生を抑える。（因みに１人で対応 できるスキル型サービスデスクの数は３システム程 度が限界である。） 3. 継続的な改善の仕組み 日常プロセスの中に組み込まれた継続的な改善の 仕組みを日常業務として行う。 4. ライフワークバランス サービスデスク要員のモラール向上のために、属 人性の排除や、毎月の残業時間抑止等の施策を行う。
V. サービスデスクの組織自体への ITIL® 適用 当然ではあるが、サービスデスクの組織自体も ITIL® を適用していることが重要な成功要因となる。 ITIL® 2011 edition サービスオペレーションのサ ービスデスクの 6．3．2 サービスデスクの達成目標 には「典型的なサービスデスクでは、インシデント およびサービス要求を管理し、ユーザとの連絡も処 理する。」とある。サービスデスクの顧客への提供 プロセスは①インシデント管理②要求実現そしてイ ンシデントの解析も行うので③問題管理の一部（イ ンシデント解析）となる。 一方、サービスデスクもサービス提供組織なので、 組織として ITIL® の他のプロセスも実装しているこ とが質の高いサービスの提供には必要となる（図 V － 1 参照）。 提供プロセスの部分では、サービスデスクは、イ ンシデント管理、要求実現および問題管理の一部と してのインシデント分析をサービスデスクサービス として顧客に提供する．一方、顧客のシステムの変 更管理やリリース管理等々はお客様の責任となる。 サービスデスクをサービスとして提供する場合、 サービスデスクサービスを実現するために内部のシ ステムおよびプロセスが必要となる。このサービス デスクサービスを実現するシステムおよびプロセス については、システム変更が必要であれば、サービ スデスクで変更管理を行わなければいけないし、リ リースも管理しなくてはいけない。また、地震が起 きた時にはサービス提供組織として IT サービス継 続管理（事業継続）もプロセスとして持っていなけ れば、質の高いサービスデスクサービスの提供はで きない。 VI. まとめ 図Ⅰ－ 1 のそれぞれのシステムをそれぞれの担当 者がサポートしている状況から図Ⅰ－ 2 のようにサ ービスデスクが 1 次窓口となる状態にスムーズに移 行するには、メーリングリストを利用したキャプチ ャー型のインシデント管理から始める必要がある。 サービスデスクのプロフィットセンター化の成功 要因は、①財務管理、②多能工化、③継続的な改善 の仕組み、④ライフワークバランスの施策を使って、 価格競争力のあるスキル型サービスデスクを提供す ることが必要となる。 そして、非スキル型サービスデスクからスキル型 サービスデスクへの移行は、採算ラインを超えたイ ンシデント数が必要となることを認識し、非スキル 型サービスデスクの提供を、待機時間撲滅のために 積極的に活用する必要がある。 最後に、サービスデスク自体が ITIL® の各プロセ スを実装していることも成功要因のひとつとなる。 VII. 最後に 図Ⅰ－ 1 のように、個々の担当者が開発したシス テムのサポートを苦労しながら、サポートしている 状況を少しでも改善したいということがサービスデ スク導入の大きな目的のひとつであった。 弊社の場合は、サービスデスクの導入は成功し、 サービスデスクの外販も実現することができた。 しかし、相変わらず、インシデント数が少ない採 算ラインに乗らないシステムサポートに関しては、 担当者がソリューションを提供している状況であ る。 今後その部分を如何にサービスデスクのビジネス として取り込めるかが課題である。
参考文献
［1］「ITIL® V2 サービスサポート」TSO ［2］「ITIL® 入門」TSO
［3］「ITIL® 2011 edition サービスオペレーション」TSO
伊藤 俊治 株式会社 SSL パワードサービス 取締役 ITIL® マネージャ 株式会社富士通ソーソアルサイエンスラボラトリ 入社後、通信事業者様向けの大規模システム開発 担当。1997 年～ CRM パッケージ開発および拡販。 2002 年～各種サポート業務。主にサービスデスク。 2005 年～株式会社 SSL パワードサービス設立に携 わり、2005 年 11 月会社設立。
会員寄稿
クラウドコンピューティングと
ITIL
®
的ソーシングのすゝめ
～『借りぐらし』世代の反復的ソーシング・ライフサイクル。
『私たちは、そう簡単に滅びたりしないわ！』～
I. はじめに クラウドコンピューティングは「『過度な期待』の 時期が過ぎ、冷静な判断が行われるようになってき ている（ガートナー /2013）」[1]と言われつつも依然 として高い市場成長の継続が予測されている。クラ ウドサービスの活用はアウトソーシングの変遷の中 で生まれた一形態にあたり、より柔軟なソーシング を実現する環境を企業に提供している。 本稿では、ITIL® では各ステージやプロセスに紛れ 込んでしまっているソーシング関連の活動を一貫し たソーシング方法論で補完する一方で、従来の直列 的なソーシング・ライフサイクルに ITIL® に見られ る反復的ライフサイクルの視点を導入することを提 案する。 クラウドコンピューティングのメリットの一つと して『借りぐらし』による「ポータビリティ（移転性）」 が進化を続けている。このことは、ますますクラウ ドサービス利用者がアウトソース先を容易に変更し たり、アウトソースされたものを再度インソースし やすくなることを意味している。今春で消費増税前 の駈込み住宅購入も過去の話になってしまったが『住 宅ローン返済より高い家賃を払う』理由を今後のソ ーシング戦略の考慮に入れていただきたい。アウト ソーシングに伴うベンダ・ロックインという伝統的 な課題がクラウドコンピューティング世代に継承さ れないことを祈っている。*ITIL® is a Registered Trade Mark of AXELOS Limited
I. ソーシング方法論と ITIL® コンピュータ資産と関連要員など IT リソースを外 部に求める IT アウトソーシングは、データセンター・ サービスや xSP(ISP、ASP、MSP、など ) の普及、更に オンデマンド化要求や仮想化技術の採用を通じてク ラウドサービスへと新たな形態を取り入れてきた。 本章では国際的なソーシング方法論として知られる OPBOK[2]、eSCM[3]に触れ ITIL® との位置づけを整理 しておこう。
I.1 OPBOK に見られるソーシング・ライフサイクル OPBOK(Outsourcing Professional Body Of Knowledge) は米国 IAOP( 国際アウトソーシング専門 家協会 ) が開発したアウトソーシングの専門知識体 系である。IAOP は世界で 12 万社の会員を有し、毎年 行われる「グローバルアウトソーシング 100」のラン キング評価などでも知られる。また OPBOK に対応し た資格 (Certified Outsourcing Professional) 制度 を国際的に展開している。日本でも OPBOK を含めた ソーシング・ガバナンス知識の資格制度が APMG を通 じて展開されている。 OPBOK ではソーシングのライフサイクルを図 I-1 に 示すように、アイデア、アセスメント、実施、トラ ンジション、マネジメント、というステージで構成 している。( 筆者訳 ) 図 I-1. OPBOK に見られるソーシング・ライフサイクル アイデア Idea アセスメント Assessment 実施 Implementation トランジション Transition マネジメント Management • コンセプト開発 • 企業の方向性識別 • アウトソーシング機会の分析、等 • 現状のプロセス・機能の分析 • アウトソースすべきプロセス・機能の定義 • リスク分析、等 • RFP発行、契約交渉、締結 • 移転（資産、要員）計画 • ガバナンス計画、等 • 新組織の導入 • 資産・要員・プロセス・機能のトランジション • トレーニング、等 • 日々のマネジメント活動 • パフォーマンスの監視 • 関係管理、変更管理、等
I.2 eSCM に見られるソーシング・ライフサイクル eSCM(eSourcing Capability Model) は IT 組 織 の ソーシング能力の成熟度を示すフレームワークとし て米国カーネギーメロン大学ソフトウェアエンジニ アリング研究所で開発された。国内でも多くの IT 企業が公式評価レベルをアピールしてきた CMMI の ような成熟度モデルの IT ソーシング版と言える。 eSCM ではソーシング・ライフサイクルを図 I-2 に 示すように、分析、開始、デリバリ、終了、共通と いうフェーズで構成している。( 筆者訳、尚クライ アント向けの eSCM である eSCM-CL に基づいている ) 図 I-2. eSCM に見られるソーシング・ライフサイクル I.3 ソーシング・ライフサイクルと ITIL® のサービス・ライフサイクル ITIL® においてはソーシング関連の活動は、サー ビスストラテジのサービス・ソーシング、サービス デザインのサービスレベル管理、サプライヤ管理な どおいてソーシングの観点や活動が盛り込まれてい るものの、各ステージに紛れ込み・また記載も少な いことから、ソーシングの観点で一貫したプロセス を読み取るのは難しい。IT 組織がソーシングのプ ロセスを整備する際には OPBOK のようなソーシング 方法論の一貫したソーシング・ライフサイクルで ITIL® を補完することが望ましいと考えられる。 一方、上記で見てきた OPBOK、eSCM のような従来 のソーシング・ライフサイクルに見られる特徴は、 システム開発で言えばウォーターフォール型のよう な直列的なライフサイクルであることである。大胆 に解釈すれば、アウトソースされた後はサービスが 終了するまでアウトソーサにベンダ・ロックインさ れることを前提もしくは基本形にしている、と言え る。 初期のアウトソーシングのように 10 年単位の契 約であった頃と違い、今やオンデマンド化やクラウ ドによる『借りぐらし』の世代である。一旦アウト ソースしたリソースをインソースしなおしたり、別 のより適切なサービス提供者に切り替えることがソ ーシング・ライフサイクルの中で行えなければ、ポ ータビリティ（移転性）という『借りぐらし』の重 要なメリットが失われ、ベンダ・ロックインのリス クに変わってしまう。 賃貸契約の気軽さでローンを組んで住宅を購入し たものの、住み替えを考える頃には資産価値の低下 とローンの残債が重荷になって身動きが取れないと いう状況はあなたの身近にも耳にするのではないだ ろうか。ともすれば『借りぐらし』の高い賃料を払 いながらこのような『持家』のリスクまで負ってし まっては元も子もない。 本稿ではクラウドコンピューティング時代におけ るソーシングについて、ITIL® をソーシング方法論 で補完する一方で、従来のソーシング方法論に対し ては直列的なソーシング・ライフサイクルを ITIL® の反復的なサービス・ライフサイクルで補完するこ とを提案したい。図 I-3 のように、ITIL® の反復的 なサービス・ライフサイクルにソーシング・ライフ サイクルを同期して反復的なソーシング・プロセス を整備していくことで『借りぐらし』世代に適応し たソーシング・プロセスを構築できる、ということ である。反復的ソーシング・ライフサイクルについ て詳しくは第Ⅲ章で述べる。 図 I-3. ITIL® のサービス・ライフサイクルと OPBOK、eSCM のソーシング・ライフサイクル 分析 Analysis 開始 Initiation デリバリ Delivery 終了 Completion 共通 Ongo in g • ソーシング機会分析 • ソーシング・アプローチ • ソーシング計画 • サービス提供者評価、ソーシング契約 • サービス移転 • 委託されたサービスの管理 • ソーシング管理の実施 • パフォーマンスの監視、等 • ソーシングの終了 • 終了計画立案 • 委託先からの移転、等 • ガ バナ ン ス 管理 • 関係管理、 等
Ⅱ . クラウドコンピューティングとソーシング戦略 ITIL® ではサービス・ソーシングを「サービスを 内部で提供するか、または外部サービス・プロバイ ダにアウトソーシングするかを決定するための戦略 とアプローチ。サービス・ソーシングは、この戦略 の実施も意味する。」と定義している。 本章ではソーシング・ライフサイクルの中でもソ ーシング戦略の肝である意思決定マトリックスを中 心にクラウドサービス利用検討のポイントを整理す る。更にそのソーシング戦略は、一旦アウトソーシ ング機会を得た場合でもその後の変動要因によりイ ンソーシング機会を再度得ることを例示する。 Ⅱ .1 クラウドサービスの形態と アウトソーシング対象リソース クラウドコンピューティングで検討されるアウト ソーシングの対象リソースの主なものとしては、設 備や HW、SW、などのコンピュータ・リソースとアプ リケーション開発要員、インフラ構築要員、運用管 理要員などの人的リソースがある。 これらは近年整理されてきたクラウドサービスの 形態である IaaS/PaaS/SaaS の分類に沿ってソーシン グの判断材料とすると良いだろう。IaaS/PaaS/SaaS の各形態の特徴については表Ⅱ -1 を参照されたい。 （参考：ウィキペディア「クラウドコンピューティ ング」[4]） クラウドサービス形態に沿ってアウトソーシン グの対象リソースを考える場合は、階層的な包含 関係と各コンピュータ・リソースに関連する人的 リソースを想定することになる。階層的な包含関 係とは、PaaS を例にとればそのインフラ・リソー スの提供である IaaS のサービス内容を包含して いるということである。関連する人的リソースと は、コンピュータ・リソースに紐づいた運用保守 の要員などである。勿論サービス管理やユーザサ ポートについてはクラウドサービスの対象外とし て別途検討する必要がある。 表 II-1 代表的なクラウドサービスの形態 Ⅱ .2 ソーシング意思決定マトリックスとクラウド サービスの対象リソース ソーシング意思決定マトリックスは、ソーシング の検討対象を、その汎用性 / 特殊性といった差別化 の視点や自組織の Strong/Weak といった市場優位性 の視点でポジションニングを整理しソーシングの判 断 (In/Out) を支援するツールであり、OPBOK でもア ウトソーシング機会の分析における手法として記載 されている。図 II-1 は OPBOK を参考に筆者が作成 したソーシング意思決定マトリックスの例である。 単純に言ってしまえば右上にあるほど内部留保（イ ンソース）、左下にあるほどアウトソースの機会が 高いと判断するものである。 図Ⅱ -1 ソーシング意思決定マトリックスの例 これにクラウドサービスのサービス形態の観点 で対象となるリソースをマッピングしたものが図 Ⅱ -2 である。例えば特殊性が高く自組織の強みを 生かすべく右上におかれた「戦略的なアプリ」は、 ビジネスの俊敏性を支えるアプリケーションなど 昨今のアジャイル開発や DevOps などによりインソ ース化が提唱されている領域をイメージしていた だきたい。勿論この場合でもプラットフォームや 特殊化要因の重要性 外部サ ービ ス に 対する優位性 例えば、 更なる特殊化や 優位性の維持向上に 向けて 内部留保 例えば、 能力補完や 「規模の経済」効果の ために アウトソース 例えば、 能力の成長に 向けて内部留保 ／ 能力を補完する ために アウトソース 例えば、 優位性の維持向上の ために内部留保 ／ 特殊化領域への フォーカスのために アウトソース
HW については左半分におかれているようにクラウ ドサービスにアウトソースされている場合がある。 本稿で主に述べているクラウドサービスの対象 リソースは左半分に配置している。汎用性の観点で 左からインフラストラクチャ / プラットフォーム / アプリケーションと順に置いているが、縦長の領域 に配置している点に留意いただきたい。これは組織 により外部サービスとの優位性が違うということ に加えて、組織の状況が変動しうることを表したも のである。下方に位置すればアウトソーシング機会 が強く、上方に位置すればインソーシング機会が強 くなる。これらの変動要因の影響が強ければ、より 反復的にソーシング戦略を練り直す必要が出てく るのである。「過度な期待」のピーク期を過ぎた現 在、我々はクラウドコンピューティングにおける変 動要因を前提にしたソーシング・ライフサイクルを デザインし実行すべきだと考える。 図Ⅱ -2 クラウドサービス対象リソースの配置イメージ Ⅱ .3 ソーシング戦略の変動要因と クラウドサービス利用見直しの可能性 クラウドサービス利用におけるソーシング戦略 の変動要因を考えてみよう。本節では II.2 で述べ た図Ⅱ -2 の左半分、つまりインフラストラクチャ / プラットフォーム / アプリケーションについて変 動要因を整理し、ありがちなクラウドサービス利用 の見直し即ち、インソーシング機会について述べ る。図Ⅱ -2 において外部サービスに対する優位性 （縦軸）がない（下方に位置した）ためにクラウド サービスにアウトソースしていたものが、様々な 変動要因により優位性を取り戻し（上方に移動し） て再度インソースする機会が高まってくるものと 考えていただきたい。尚、本稿で述べるインソース の範囲としては所謂「内製」だけでなく、委託先の リソース ( 資産、要員 ) を自社環境として利用する 所謂「オンプレミス型プライベートクラウド」のよ うな形態を含むものを想定しているので留意され たい。 (1)HW 等インフラストラクチャ 先ず、IaaS の対象となるインフラストラクチャ であるが、コンピュータ・リソース、人的リソース について下記のような例があげられる。 ・コンピュータ・リソース ▶初期予算を抑えるために IaaS を利用してサー バを立ち上げたが、システム負荷が安定し、か つ今後も長期に稼働が見込まれるため、購入し なおした方がトータルコストを抑制できるこ とがわかった。 ▶自社の仮想環境が整備されリソース・プールが 確保されたため、IaaS 上の仮想サーバを引き 取れるようになった。 ・人的リソース ▶自社内環境の運用業務改善により、社内の運用 体制に余裕が出来た。 ▶自社の仮想環境の整備と共に、社内の運用要員 に仮想環境のシステム管理についてトレーニ ングが十分行われた。 (2) プラットフォーム インフラストラクチャ上のプラットフォーム領 域については下記のような例があげられる。 ・コンピュータ・リソース ▶ PaaS で構築したアプリケーションの利用が進 むにつれ DB アクセス処理の性能が次第に低下 してきている。サーバのリソース割当てを増や しても効果がなく（もしくは増やせず）、社内 で採用している DB サーバの DBMS のように思う ようにチューニングが進まない。 ▶アプリケーション構築後の長期利用において PaaS 環境を利用し続けるよりも、IaaS や自社 の仮想サーバ上でオープンソースのミドルウ ェアにコンバージョンした方がトータルコス トを抑制できることがわかった。 ・人的リソース ▶自社内環境の運用自動化など業務効率化によ り、社内の運用体制に余裕が出来た。 ▶社内の運用保守要員に OS やミドルウェア利用
についてのトレーニングが十分行われた。 (3) アプリケーション OS、ミドルウェアなどのプラットフォーム上に構 築されるアプリケーション領域については下記の ような例があげられる。 ・コンピュータ・リソース ▶ SaaS で構築したアプリケーションで障害が頻 発しているがブラックボックスなため自社で は対処できないし、サービス提供者の対処も不 透明なまま、可用性、性能が改善されない。 ▶アプリケーション構築後の長期利用において SaaS 環境を利用し続けるよりも、自社環境や 他のクラウド環境上にコンバージョンした方 がトータルコストを抑制できることがわかっ た。（システム開発コストの大半をしめる要件 定義、設計の必要が無い） ・人的リソース ▶自社のサービスデスクの一次対応でアプリケー ション利用者からの問合せに対処できるよう になった。 ▶アプリケーション運用について SaaS 提供者に アウトソース出来ない領域があり、結局社内の 運用保守体制を維持する必要があった。 Ⅱ .4 アウトソーシング機会の優先付け尺度とイン ソーシング機会 OPBOK ではアウトソーシング機会の優先付けにお ける尺度として下記を挙げているが、Ⅱ .3 で挙げ た例はこれらがインソーシング機会の目的におい ても当てはまることを示している。 ①財務…予算への影響・効果、等 ②サービス提供者…規模や専門性、等 ③便益…リソースの解放、コスト削減等 ④実行の容易さ…4 プロセスの明確さ等、移転のし やすさ 上記の観点でⅡ .3 に挙げた例を整理すると下記 のようになり、一旦クラウドサービスにアウトソー スされたリソースについて、時間の経過と共にイン ソースしなおす機会が発生することが分かる。 ①財務 初期コストを抑制するためにクラウドサービス を採用したが、継続稼働のランニングコストを考慮 するとインソースし直した方がトータルコストを 抑制できる状況になった。 ②サービス提供者 外部サービス提供者の専門性に対し、自社要員の キャパシティやスキル・ノウハウ不足があったが解 消された。 クラウドサービス提供者の能力が期待に満たな かった。 ③便益 他の自社内システムのための人的リソースやシ ステム運用基盤の整備によりアウトソースされて いるシステムにも対処できるようになった。 ④実行の容易さ 他の自社内システムにおける共通の管理プロセ スがあり、巻き取りやすい。 自社の仮想環境整備が進み、クラウドサービスの ポータビリティを活用してコンピュータ・リソース を容易に移転できる状態になった。 Ⅲ . 反復的ソーシング・ライフサイクル 最近のレポート「アウトソーシング・アドバイザ リ：サービス・ソーシング戦略策定の実行（ガート ナー /2014）」[5]では「70% 超の企業が、重要なア ウトソーシング契約の評価時にのみソーシング戦 略を策定している」との所見を示している。これは 第 1 章に挙げた従来の直列的なソーシング・ライフ サイクル上の上流工程としてソーシング戦略が一 度実施されそのまま放置されている状況を示して いるのではないだろうか。とりわけクラウドコンピ ューティングにおいては『借りぐらし』のメリット であるポータビリティを前提として、反復的ソーシ ング・ライフサイクルに切り替えていく必要がある ことを述べてきた。 本章では ITIL® の継続的サービス改善に見られる 反復的なサービス・ライフサイクルを取り込んだ反 復的なソーシング・ライフサイクルの導入を提案す る。これは同時に、ITIL® に基づいたサービス・ライ フサイクルの運営にソーシング・ライフサイクルを 統合し、クラウドコンピューティング時代に適応し た IT サービスマネジメントを提案することでもある。
Ⅲ .1 ポータビリティを前提とした 反復的ソーシング・ライフサイクル 従来の情報システムのアウトソーシングでは新 規システム開発や移転プロジェクトの膨大な初期 費用をかけ、一旦ベンダにアウトソースすると契約 更新時に条件見直しなどがあるにせよ、ソーシング 自体を見直すことはされない傾向にある。また内部 ナレッジの遺失やアウトソース先でのブラックボ ックス化が進み、時間の経過と共にインソースする ことが困難になっていた。 ベンダ・ロックインとは「特定ベンダの独自技術 に大きく依存した製品、サービス、システム等を採 用した際に、他ベンダの提供する同種の製品、サー ビス、システム等への乗り換えが困難になる現象の こと（ウィキペディア）」と言われているが、上記 のアウトソーシングにおける状況もベンダ・ロック インの一つと言える。 クラウドコンピューティングにおけるアウトソ ーシングでは、「特定ベンダの独自技術に大きく依 存」しなければならない状況は限定的であり、仮想 化技術によるポータビリティを前提とすればベン ダ・ロックインの発生はソーシング・プロセスの問 題として解決できる範囲が多いと考えられる。 例えば、IaaS 上の仮想サーバは、自社内に仮想 環境を構築できれば HW など物理的な制約を受けず にサーバ自体を電子データとして簡単に自社内に 移転できる。たとえ SaaS 上のアプリケーションで も標準化した業務アプリケーションであればベー スとなるパッケージの選択肢も増え、さらに利用中 の SaaS として機能要件や設計が実体として具体化 している状況では工期と工数の不透明なシステム 開発の上流工程を経ずに、所謂コンバージョンによ って自社内のサーバ環境に移転することも出来る。 PaaS 上で開発したシステムなら、オープンなミド ルウェア環境を採用していればいるほど、より容易 に自社内のシステム基盤にコンバージョン出来る だろう。このようなポータビリティを前提にすれば 大半のシステムでは技術的にベンダ・ロックインに 陥る必要はないのである。 そこで本稿で提案するのは、ポータビリティを前 提とし、ソーシング状態を反復的に判断し、必要に 応じてソーシング状態を切り替えるプロセスをも ったソーシング・ライフサイクルである。この反復 的ソーシング・ライフサイクルを ITIL® のサービ ス・ライフサイクルと同期をとる形で構成したも のが図Ⅲ -1 である。これにより、第 1 章で挙げた OPBOK や e-SCM というソーシング・ライフサイクル の標準で ITIL® のサービス・ライフサイクルを補完 する一方で、ソーシング・ライフサイクルをクラウ ドコンピューティングのポータビリティを明確に 意識した反復的なものとすることができる。 図Ⅲ -1 サービス・ライフサイクルに沿った 反復的ソーシング・ライフサイクル Ⅲ .2 ポータビリティに伴うベンダ・チェンジの機会 本稿では、アウトソースからインソースへの移行 について主に述べてきたが、インソーシング戦略を とらない場合やナレッジ不足などによりインソー スは時期尚早と判断する場合でも、クラウドコンピ ューティングにおけるポータビリティ技術の進展 に伴い、他のサービス提供者へのベンダ・チェンジ の機会はより現実的な選択肢となってきている。 クラウドコンピューティングは「『過度な期待』 の時期が過ぎ、冷静な判断が行われるようになっ てきている（ガートナー /2013）」と言う時期を迎 えサービス提供者の淘汰が進むとも言われている。 サービス料金等の契約条件についてもサービス提 供者間の差別化が進むだろう。クラウドサービスへ の品質的な不満が、より適切なサービス提供者へベ ンダ・チェンジすることで短期的に解消される可能 性もある。 前節の例のように IaaS で互換性のある仮想化基 盤を採用しているサービス提供者間では HW として のサーバを電子データとして移転するだけであり、 サービス ストラテジ サービス デザイン サービス トランジション サービス オペレーション 継続的 サービス改善 ソーシング ストラテジ ソーシング デザイン ソーシング トランジション ソーシング オペレーション 継続的 ソーシング 改善 • 組織の方向性識別 • ソーシング機会分析 • ソーシング対象領域(In/Out)の定義、等 • アウトソーシング仕様(資産、プロセス等)の定義 • サービス提供者評価、アウトソーシング契約 • 移転計画、等 • サービス提供者への移転(サービス、業務、等) • サービス提供者の切替 • サービス提供者からの移転(インソーシング)、等 • 日々のマネジメント活動 • パフォーマンス監視、関係管理 • 変更管理(資源利用量の拡大・縮小も含む)、等 • ソーシング効果のレビュー • 教訓などナレッジの棚卸 • ソーシング・プロセスの見直し、等
