IT サービスマネジメントフォーラムジャパン Newsletter Newsletter 2014.7 目次 2014.7 月号 第 11 回 it SMF Japan コンファレンス /EXPO 告知 it SMF Japan コンファレンス担当 3 JICA 沖縄国際センター研修員訪問見学 it SMF Japan 事務局 4 会員寄稿 IT サービスマネジメントとビジネス情報マネジメント 村川 洋介 氏 5 会員寄稿 サービスデスク導入に関する考察 伊藤 俊治 氏 10 小澤 一友 氏 16 武上 弥尋 氏 24 会員寄稿 脱・IT 後進国への特効薬：これを飲まずして何を飲む – システム運用部門からビジネスパートナへの誘い - 近野 章二 氏 33 会員寄稿 運用自動化によるサービス改革の促進 岩村 郁雄 氏 38 ・効果的な問題管理のための 5 つのアドバイス ・IT 変更の失敗を避ける方法 From SERVICE TALK 翻訳記事 44 新分科会紹介 バリューコストマネジメント研究分科会 52 新理事紹介 it SMF Japan 理事 伊藤 清 54 itSMF Japan 関西支部報告 it SMF Japan 関西支部 55 第 11 回通常総会報告 it SMF Japan 事務局 56 会員寄稿 クラウドコンピューティングと ITIL® 的ソーシングのすゝめ ～『借りぐらし』世代の反復的ソーシング・ライフサイクル。 『私たちは、そう簡単に滅びたりしないわ！』～ 会員寄稿 Proactive な Service Transition ～開発と運用の協業（DevOps）および IT 価値向上の実現と人材育成～ / 企業の成長戦略を加速する IT サービスマネジメント － － Social, Social, Mobile, Mobile, Analytics, Analytics, Cloud Cloud の活用を支える－ の活用を支える－ 参加者募集は、 9 月中旬を予定しております。 皆様、 奮ってご参加ください。 詳しくは、 itSMF Japan ホームページ （http://www.itsmf-japan.org） Facebook(http://www.facebook.com/itsmf.japan） をご覧ください。 2014 年11月13日［木］ -14日［金］ ガーデンシティ品川（東京・SHINAGAWA GOOS 1F) ◎主 催 特定非営利活動法人 itSMF Japan ◎共 催 日経 BP イノベーション ICT 研究所 3 it SMF Japanでは地球環境に配慮し、エコイベントを実施いたします。 ■ 印刷物（講演資料印刷の廃止、再生紙の利用） ■ ゴミ（分別回収の徹底） ご理解・ご協力のほどよろしくお願い申し上げます。 JICA 沖縄国際センター研修員訪問見学 第 4 回（2014 年 5 月 13 日） ～海外 4 ヵ国の方々と意見交換～ 国際協力機構 (JICA) の沖縄国際センター（OIC） IT 研修「電子政府推進のためのシステム運用管理 (B)」コースの研修員が、見学実習として 5 月 13 日 に it SMF Japan 事務所を訪問されました。その目的は、 「システム運用管理業務における知見養成のため、講 義内容の裏付けとして、実例を知り、そこから学ぶ」 ことです。 4 回目となる今回は、ガーナ・タンザニア・ザンビア・ コソボの 4 ヵ国 8 名の研修生が訪問されました。 ・すべての講演が非常に有益であった。 it SMF Japan からは、富田理事長より it SMF Japan ・事例から学ぶものが多く、自組織にも活用可能と感 の IT サービスマネジメントの普及啓蒙活動のご説明 じた。特に ITIL® の導入ステップが実に素晴らしい。 を行い、小山事務局長からは「ITIL® の概要」をご説 この事例を共有いただいたことに感謝する。 明しました。そして最後に、前回に引き続き ITIL® ・最初に経営層の支持を取り付けておくことが成功へ の導入事例として KVH 株式会社シニアプロジェクト の道のりに繋がることを教えてくれた。プロセスが マネージャ小渕様より『サービスマネジメントを実 失敗に終わる原因には、プロセスが適切でないので はなく、経営側がそのプロセスの導入に関心がない 現するための 5 つのステップ～ドラッカー流サービ ことに起因する場合もあると思う。 スマネジメント導入アプローチ～』について、ご説 ・進捗状況を判断するために、評価や測定は非常に重 明いただきました。 要であることを学んだ。 ・サービスマネジメントを成功させるための 5 つのス OIC 様からは、「研修員が ITIL® の有用性に関する テップは素晴らしい。知識やツールを持ち合わせて 理解を深める良い機会となったと考えております。 いても、良いタイミングでその知識を活用できる能 また、研修員が帰国後にアクションプランとして 力こそが、違いを生み出すことのできる源だと思う。 ITIL® に説明されているシステム管理プロセスを自組 ・3 年間でサービスマンジメント改革を成し遂げた KVH 織に適用する際、本見学で得た多くの情報は、大変 社の事例は、ベストプラクティスであり、よい学び 役に立つものと考えております。質疑応答において の経験となった。ITIL® を活用したサービスマネジメ も各質問にていねいに対応いただき、誠にありがと ント改革をぜひ自組織にも導入していきたい。 ・ITIL® のフレームワークと範囲をよく理解できた。 うございました」とのコメントをいただきました。 ・多くの企業の成功を支援する大きな役割を it SMF は担 研修員の方々とは 2 時間半にわたって、活発な意 っている。ITIL® によって、企業の収益と継続性を最 見交換を行いました。後日、研修員の方々より以下 適化する持続的なビジネス手法を it SMF は推進してい のような感想をいただきました。 る。NPO としてこのような大きな支援を行っていると いう事実は、我が国では考えられないことである。 ・ITIL® のための TIPA のプロセスアセスメントモデルを 導入すると、理想的なプロセスを把握したうえでどの ような改善が必要かを理解できるようになると思う。 やはり、導入事例を聞くことにより研修員の理解が 深まっているようです。小渕様、事例発表ならびに 質疑対応ありがとうございました。この場を借りて 御礼を申し上げます。 4 (it SMF Japan 事務局 ) 会員寄稿 IT サービスマネジメントと ビジネス情報マネジメント I はじめに - ビジネス情報マネジメント（BIM）とは 係にあると言える。実際に US では、ITIL® コミュニ ティにおいて BiSL® の勉強会が積極的に実施されて サ ー ビ ス・ マ ネ ジ メ ン ト の 領 域 に お い て、 ビ いる [3]。 ジ ネ ス 情 報 マ ネ ジ メ ン ト Business Information Management（BIM）という概念が定義されている。 この稿では、日本ではまだ知られていない BiSL® フレームワークの概要を紹介し、BIM の考え方と IT “Business information management is the サービスマネジメントの関連を考察する。また国内 means by which an organization efficiently で初めて BiSL® を実際に適用したプロジェクト事例 plans, collects, organizes, uses, controls, を紹介し、その有用性と今後の展望について述べる。 disseminates and disposes of its information, and through which it ensures that the value of *ITIL® is a Registered Trade Mark of AXELOS that information is identified and exploited to Limited the fullest extent.”[1] *BiSL® and Application Services Library (ASL®) ビジネス情報マネジメントとは、ある組織が持て are registered trade marks of the ASL BiSL る情報を効果的に、計画し、収集し、編成し、利用し、 Foundation. コントロールし、広め、廃棄するためのものであり、 またそれを通して、情報の価値を特定し最大限に有 II BiSL® を取り巻く状況 効利用することを、確実にするものである。 BiSL® は、 オ ラ ン ダ に 本 拠 を 置 く NPO 組 織 ASL BIM は、IT により自動化されたものと EUC のよう BiSL Foundation が知的所有権を持つ、ベンダー独立 に自動化されていないものの双方を含む、情報の最 でパブリックドメインの BIM 適用フレームワークで 適な提供と利用および保守についての、ユーザ組織 ある。フレームワークを定義した書籍と多数のホワ の責任を規定している。 イトペーパーが用意され、認定資格が発行されてい る [4]。 BIM の 代 表 的 な フ レ ー ム ワ ー ク と し て、 ヨ ー ロ ッ パ を 中 心 に 利 用 が 広 が り 始 め て い る Business BiSL® の 歴 史 は、1997 年 に Dutch Computer Information Services Library (BiSL®) が あ る。 Center, RCC で開発された FBM と呼ばれる情報管理 BiSL® は ITIL® を意識して構成されたビジネスユーザ のフレームに遡る。2002 年設立の ASL Foundation 向けのフレームワークであり、相互の関連について （後の ASL BiSL Foundation）に移管された後、2005 の分析も進められている [2]。ITIL® においても「ビ 年に BiSL® 1st Edition が公開された。2012 年には ジネスユーザおよびビジネスニーズに貢献する IT サ 2nd Edition が公開され現在に至る。 ービスの提供」という観点はその重要性が認識され てきており、この点で ITIL® と BiSL® は相補的な関 同 時 期 に ア プ リ ケ ー シ ョ ン・ サ ー ビ ス・ マ ネ 5 ジ メ ン ト の フ レ ー ム ワ ー ク と し て、Application 要な、ユーザ組織と IT サービス・プロバイダ双方 Services Library（ASL®）が定義され、同団体から の活動について、互いに補完する立場からのガイダ 公開されている。 ンスを提供していることがわかる。 BiSL® 用語集として、英語、オランダ語、スペイ ン語、ポルトガル語、フランス語、ロシア語、中国語、 スコープ そして日本語版が公開されており、実績としては主 にヨーロッパ諸国で利用されている。特にオランダ では、ASL BiSL Foundation のマネージングパート ナーとしてオランダ国防省とオランダ国税庁が参加 している関係から、IT システムの政府調達において 「BiSL® Certification を持っていることが強く推奨 される」という入札条件が付くこともある。 BiSL® ITIL® ユーザ組織の中で実施 される BIM の活動をガ イドするプロセスモデ ル。ビジネス・プロセ スで必要な情報を、効 果的かつ効率的な方法 で取得するために、需 要側で実行する必要の あるすべての活動を対 象とする。 IT サービスマネジメン トのベスト・プラクテ ィスをまとめたフレー ムワーク。ビジネス上 の価値を可能にすると いう観点から、サービ ス・ライフサイクル全 体の、IT サービスマネ ジメントの指針を提供 する。 BIM に つ もっぱら BIM を確立す 明示的に BIM には言及 い て の 記 ることが目的であり、 していないが、IT サー 情報システムの機能を ビス・プロバイダの役 述 積極的に管理・維持し、 割を果たすための前提 サポートするユーザ組 条件として、BIM に含 織の活動のガイダンス まれる活動を説明して いる。 を記述している。 ITIL® との関連においては、英国の it SMF UK 主催 のカンファレンス ITSM において、2012 年、2013 年 と 連 続 し て ASL BiSL Foundation の Mark Smalley 氏によるフレームワーク紹介の講演やワークショッ プがおこなわれている [5]。 視点 また米国では、it SMF US と ASL BiSL Foundation ビジネス組織（ユーザ） IT サービス・プロバイ からの視点 ダからの視点 表Ⅲ -1 BiSL® と ITIL® の比較（[2] を元に作成） の共同プロジェクトで、BiSL® 入門用の教育パッケ ー ジ ”BiSL® in a Box" が 開 発 さ れ、2013 年 か ら 各地の支部（LIG）で学習会が開催されている [3]。 2 比較表についての考察 itSMF US の Web サイトでは、トップページに BiSL® 最も特徴的な差異は、ITIL® では IT サービス・プ Group and blog のリンクが設置されており、すでに ロバイダの視点から、ビジネス上の価値を可能にす 一定の認知を得ていることが伺える [6]。 る IT サービスマネジメント活動を定義しているの に対し、BiSL® では、ユーザ組織の視点から、ビジ 日本国内では、2013 年に筆者らのグループが日 ネスで必要な情報の維持・管理のための活動を定義 本語版用語集の作成やホワイトペーパーの翻訳を開 している点にある。 始した。2014 年には ASL BiSL Foundation - Japan Ambassador が設置され、本格的な展開の準備をおこ 情報システムの計画、構築、保守運用、拡張とい なっている。 ったライフサイクル全体において、情報システムの 効果的な利用のためには、ユーザ部門と IT サービス・ プロバイダは緊密に連携して活動する必要がある。 III BiSL® と IT サービス・マネジメントの関連 その際に、相互に補完するフレームワークを活用す 1 BiSL® と ITIL® の比較 ることで、それぞれが果たすべき役割と責任を明確 ASL BiSL Foundation と、ITIL® の出版元であった にできれば、非常に有効であると考えられる。 The Stationery Office（TSO） は、BiSL® と ITIL® IV BiSL® のフレームワーク のフレームワークの相乗効果と相違点についてのガ イダンスを提供するために、共同でホワイトペーパ BiSL® のフレームワークは、戦略、管理、運用の ーを作成した。[2] 3 つのプロセスレベルに配置された、7 つのプロセ このホワイトペーパーによると、BiSL® と ITIL® ス群から構成されている（図Ⅳ -1）[7]。以下に、 は表Ⅲ -1 で示すように、ビジネス上の価値を可能 これらプロセス群の概要を紹介する。 にするための情報システムの構築、維持、管理に必 6 戦略的 サプライヤ管理 戦略プロセス 戦略的 ユーザ関係 管理 管理プロセス 情報 コーディ ネーション I -組織戦略 の定義 情報 ライフサイクル 管理 戦略的 情報パートナー 管理 I- 組織戦略群 計画立案と リソース管理 エンドユーザ サポート 技術開発の 確立 情報連鎖開発の 確立 情報戦略群 財務管理 ビジネスデータ 管理 ビジネス・プロセス 開発の確立 需要管理 変更 管理 情報 ポートフォリオ 管理 契約管理 情報要件の 明確化 自動化されていない 情報システムの 設計 移行準備 レビューと テスト 運用プロセス 運用的 サプライヤ管理 移行 管理 利用管理群 機能管理群 図Ⅳ -1 BiSL® フレームワーク（[7] を元に筆者が日本語化） 1 運用プロセスレベル 1) 管理プロセス群 運用レベルのプロセスには、利用管理プロセス群、 管理プロセス群には、計画立案とリソース管理、財 機能管理プロセス群、およびその間をつなぐ接続プ 務管理、需要管理、契約管理の４つのプロセスが含 ロセスが含まれる。 まれる。これらのプロセスでは、合意されたコスト と便益、要求、IT プロバイダーとの契約とサービス 1) 利用管理プロセス群 レベル、および計画に留意して、活動をモニターす ビジネスで必要な情報を、継続的に最適な状態で提 る。 供するためのサポートを目的とするプロセス。IT サ ービス・プロバイダに対する運用管理や、データ提 3 戦略プロセスレベル 供の運用監視、情報を利用するユーザへのサポート 戦略レベルのプロセスには、情報戦略プロセス群、 提供が含まれる。 I- 組織戦略プロセス群、およびその間をつなぐ接続 プロセスが含まれる。 2) 機能管理プロセス群 情報提供の機能を変更する際の、要件の明確化から 1) 情報戦略群 設計、開発、テスト、移行までの期間のプロセスを 組織をとりまく環境や、組織自体のビジネス・プロ 記述する。フレームワークに整合する形で、ユーザ セス、および部署への情報提供に影響を及ぼすあら の目的と需要を満たした情報提供機能の変更が実施 ゆる種類の変化を考慮して、情報提供機能が将来の されるように管理することが目的となる。 需要に適合し、現在の状況の構造的な欠陥を解決す るように、情報提供の戦略を策定するプロセスを記 3) 運用レベルでの接続プロセス群 述する。 利用管理と機能管理のプロセス群を連携し、情報提 供機能にどのような変更が加えられるべきか（変更 2)I- 組織戦略群 管理）、および、情報提供機能の変更が、ユーザ組 I- 組織とは、情報提供をコントロールする組織もし 織内で実際にどう適用されるか（移行管理）を判断 くは部署と定義される [7]。情報提供には、通常複 するためのプロセスを記述している。 数の組織が関わることになる。I- 組織戦略プロセス 群では、この情報提供に関わる各組織が、適切に管 2 管理プロセスレベル 理及び意思決定できるようにするためのプロセスが 管理レベルのプロセス群は、これまでに述べてきた 記述される。これは外部にいる関係者、例えば、サ 運用レベルのプロセス群を、正しく管理することが プライヤーや、サプライチェーンのパートナーや、 目的となる。 ユーザ組織などとの関係にも適用される。 7 3) 戦略レベルの連結プロセス セスの活動は、IT サービス・プロバイダの立場から 戦略レベルの連結プロセスは、関与するすべての当 すればむしろオーソドックスな、当然必要とされる 事者の調整と、情報提供の様々な要素に対する計画 ものばかりである。しかしながら、その活動をビジ の調整を目的とする。I- 組織戦略で扱う各組織では、 ネスユーザ側の視点から整理し、戦略立案から開発・ さまざまなレベルで情報提供に関わる計画やポリシ 運用まで体系化していることに意味があると考えら ー、情報戦略が策定される。これらを互いに調整し れる。 統合する情報コーディネーションが、戦略レベルの 連結プロセスとして記述される。 ビッグデータやクラウドサービスの活用など、ビ ジネス情報提供の意味する範囲は、旧来の狭い意味 近年、より多くの組織間での相互情報連携が進み、 での IT システム構築に限らなくなってきている。そ またアプリケーション・パッケージや ASP の利用が のため、経営の根幹としてビジネスユーザが主体的 増加している状況で、情報戦略と組織間の調整は、 に情報戦略立案から環境整備まで関わる必要性は、 複雑さと困難さを増してきている。関係組織間の調 ますます増してきている。ユーザ視点での BIM のフ 整プロセスを明確化して、情報戦略の全体最適化を レームワークの果たす役割は、今後さらに重要性を 図ることが重要となる。 増してくると考えられる。 4 フレームワークの活用についての考察 V 国内プロジェクトへの BiSL® 適用事例 これまで見てきたように、BiSL® はユーザ側の視 点から情報提供の機能を管理、利用するためのプロ 筆者は国内のシステム導入プロジェクトにおい セスモデルを提供している。このフレームワークの て、プロジェクト・マネジメント・オフィス（PMO） 活用方法としては、例えば次の 2 つのシーンが想定 として、ユーザ部門とシステム部門の連携を図る立 される。 場で BiSL® の運用レベルプロセスを実際に適用して みた。 1) ユーザ組織へのコンサルティングツールとして 情報の利用者でありオーナーであるユーザ組織が実 BiSL® はフレームワークでありメソドロジーでは 施するプロセスとして、例えば企画部門等の情報シ ない。つまり、プロジェクトの進め方や成果物テン ステム整備計画で、戦略レベルプロセス群を採用す プレートが用意されているわけではないが、「考え ることが考えられる。この場合、ユーザ部門自身が 方の枠組み」としてガイドラインのチャートを利用 プロセスを構築するために、BiSL® のフレームワー することが可能である。例えば、要件定義フェーズ クに習熟したコンサルタントが、助言などの支援を でのユーザ部門とシステム部門、IT サービス・プ 提供することが有効であると考えられる。 ロバイダ間の役割を定義するために、機能管理群の これは BiSL® が本来想定する活用方法である。 プロセス関連図を使用するなどの方法を試行してみ た。結果としてプロジェクトは無事サービスインを 2)IT サービス・プロバイダからユーザへの連携ツー 迎え、ユーザ部門のメンバからは「自分たちが実施 ルとして情報システム構築プロジェクトやシステム しなければいけないアクティビティがよく整理され 運用の開始時に、運用レベルプロセスを、IT サービ ており、理解しやすかった」などの感想が聞かれる ス・プロバイダとユーザ組織の間の役割と責任を定 など、一定の効果はあったと考えられる。 義するためのフレームワークとして活用することが 考えられる。BiSL® 自体は、ユーザ組織側の視点か 今回のプロジェクトは、国内における初の適用事 ら役割と活動が整理されているため、IT サービス・ 例として、フレームワークの有効性を試験的に確認 プロバイダが BiSL® を理解しユーザ組織との調整に することが目標であったため、定量的な導入効果の 活用することで、円滑に合意形成を図る効果が期待 測定などは実施していない。可能であれば今後、定 できる。 量的、定性的な導入効果の測定を検討したいと思う。 BiSL® で定義されているプロセスや活動は、決し て新規で独特なものではない。特に運用レベルプロ 8 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 business-IT alignment from a business 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 : it SMF US Web サイト： 村川 洋介 http://www.itsmfusa.org/?page=Pgm_BiSL_in_a_ 日本アイ・ビー・エム株式会社 box マネージング・コンサルタント [4] ASL BiSL Foundation Web サイト http://www. ASL BiSL Foundation-Japan Ambassador aslBiSLfoundation.org/ PMP [5] ITSM 13 ( 第 22 回 it SMF UK コンファレンス ) 日本アイ・ビー・エム入社後、製品開発研究所で 参加報告 , it SMF Japan Newsletter 2014.1, 中井秀 PC 周辺機器やネットワーク関連の研究開発に従事。 有 ,2014 (P.21,22 TIMETABLE 中の Sponsor Theatre 新規事業開発部門に異動してインターネット技術 EXPO HALL Session 4 を参照 ) を活用した新サービスの開発から、SI 部門での流 [6] it SMF US Web サイト http://www.itsmfusa.org/ 通業、金融業などのシステム開発プロジェクトの PM を経験。2006 年ビジネス・コンサルティング部 [7] BiSL® - A Framework for Business 門に異動し、現在は主に会計システム導入のコン Information Management - 2nd revised edition, サルティングを実施。 Remko van der Pols, Ralph Donatz, Frank van Outvorst, Van Haren Publishing, 2012 9 会員寄稿 サービスデスク導入に関する考察 I. はじめに システム（パッケージの場合もある）の開発およ びサポートを主業務としている組織では、図Ⅰ―1 の ように、複数のシステムをそれぞれ別の担当者がサ ポートしているケースが多く見られる。 II. コール・センタを利用した場合の考察 まず始めに 1 次窓口を一般のコール・センタに依 頼した場合（図Ⅱ－ 1）についての考察を行う。コール・ センタ業界は既にビジネスモデルとして確立してお このような状況では、お客様は、窓口が複数存在 り、サービスデスクのプロフィットセンター化を考 することで、システム毎に問合せを行う窓口が違う えるうえで参考になると考えられる。 不都合が発生する。また担当者が属人化していて、 担当者が捉まらない状況が発生しやすい。 一方、サポート担当者は、メイン業務の開発の片 手間で、以前開発に携わったシステムのサポートを 行わなければならず、非常に大きな負担となってい るケースが多い。 これらの問題を解決するために、窓口を一本化し、 専任のサポート要員を置くことで解決を目指すがな かなかうまくいかないケースが多い（図Ⅰ―2 参照）。 窓口を一本化し、サービスデスクを導入する場合の 成功要因とは何なのか以下で考察を行う。更に、サ 1. サービスデスク／コール・センタの定義 ービスデスクを導入した後、サービスデスクをプロ まずは、サービスデスクとコール・センタの違い フィットセンターとして運営するための成功要因に を明確にするために、サービスサポート（V2）での ついても考察を行う。 定義の確認を行う。定義は以下の通り。 10 商品の通信販売サービス（例えば銀行や保険） コール・センタ 向けの電話ベースの取引の膨大なコールを専門 的に処理することに主な重点が置かれている。 主な目的は、インシデントを管理、調整、およ び出来る限り迅速に解決すること、および要求 が紛失、忘却、そして無視されないことを保証 ヘルプデスク することである。一般的に、技術支援として、 構成管理や、ナレッジ・ツールへの関連付けが 利用される。 サービスデスクは、サービスの範囲を拡張し、 より広い視野を持ったアプローチを提供するこ とで、ビジネス・プロセスをサービスマネジメ ント・インフラストラクチャに統合することを 可能にしている。サービスデスクは、インシデ サービスデスク ント、問題、そして質問に対応するだけではない。 例えば、顧客の変更要求、保守契約、ソフトウ エア・ライセンス、サービスレベル管理、構成 管理、可用性管理、ＩＴサービス財務管理、そ してＩＴサービス継続性管理等の他の活動との インタフェースも提供している。 サービスサポート（V2）のコール・センタの定義「商 また、ITIL® 入門（V2）での定義は以下の通りと いは ITIL® 入門（V2）のコール・センタの定義「コ なっている。 ールを記録するだけでソリューションの提供は行わ コールを記録するだけでソリューションの提供 は行わない。コールは専門部門に回され、そこ コール・センタ で対処する。コールの記録とルーティングは音 声応答システムで自動化できるケースもある。 コールを記録し、一般的な用語で説明を行って、 ただちに他の部門に回す。サービスデスクは概 して他部門に早く回すことが機能であり、コー 非スキル型 サービスデスク、 ルの取扱いを期待され、幅広い標準的な手順、 コールに対応するためのスクリプト、規範、経 または、 験のあるマネージャが必要となる。このアプロ コール記憶型 サービスデスク ーチの利点はインシデントの記録のしかたが統 一されることである。欠点は対応時間が長くな り、初回のコールでの解決率がスキル型サービ スデスクよりかなり低くなる。 優れたスキルと経験を有している。文書化された ソリューションを使って多くのインシデントを解 スキル型 決するが、インシデントによってはサポート・チ サービスデスク ームに回すものもある。初回のコール解決率は一 般にヘルプデスクよりも格段に高くなる。 全 IT インフラストラクチャに関する専門的知 エキスパート・ 識と、ほとんどのインシデントを独りで解決す サービスデスク るだけの知識を有している。 ない。」とある通りソリューション提供力となる。 以上の定義をまとめると以下のようになると考え 品の通信販売サービス（例えば、銀行や保険）向け の電話ベースの膨大なコールを専門的に処理するこ とに主な重点がおかれている。」の記述の通りコー ル・センタでは「膨大なコール」が一つのキーワー ドとなる。コール・センタがビジネスとして成り立 っているのは大量呼を処理することで、システムサ ポートで発生することが多い待機時間を回避できて いることが、ひとつの大きな要因となっている。見 方を変えると、図Ⅰ―1 のシステムサポートの形態 は、開発の空き時間でシステムサポートを行うこと で待機時間をなくすることができている。 もう一つのサービスデスクとコール・センタの違 定義通りコール・センタにソリューション提供力が 全くないとは考えにくいが、図Ⅱ－ 1 のように 1 次 窓口にコール・センタを活用した場合、ソリューシ ョン提供力をある程度持てたと考えた場合でも非ス キル型サービスデスクになると考えられる。 一方、サービスデスクの導入成功には、スキル型 サービスデスクあるいはエキスパート・サービスデ スクであることが、ITIL® 入門（V2）の定義から考 察できる。非スキル型サービスデスクでは、対応時 間が長くなり、1 次回答率が低い状況が発生する。 顧客からみるとサービスデスクを導入したことで回 答時間が長くなり、サービスの質が落ちてしまうこ ととなるからである。 サービスデスク導入の成功には何が必要なのであ られる。 ろうか。第一の成功要因はスキル型サービスデスク 以上のソリューション提供力をサービスデスクが持 たなくてはいけないということになる。しかし、サ ービスデスク要員からみると他の担当者あるいは他 の組織が開発したシステムをサービスの品質を落と さずにサポートすることは至難の業である。図Ⅰ－ 1 と同様のサービス品質を保ちながらサービスデス クを導入するにはどうすればよいのか。以下にサー ビスデスク導入成功のためのひとつ方法論を提示す る。 11 III. サービスデスク導入の成功要因 を、内容の確認という形でメールでお客様に送信して もらい、それをサービスデスクがキャプチャーする。 1. キャプチャー型のインシデント管理 サービスデスクをシステムサポートに導入する場 顧客にとっては、導入初期は今まで通り担当者が 合、導入初期は、非スキル型サービスデスクになら 対応してくれ、かつ図Ⅰ－ 1 の形態の対応時には発 ざる負えない。サービスデスク要員は、サポートす 生しがちだった担当者が捉まらないというような状 るシステムにノウハウを持たない、あるいは勉強を 況も回避することができるので、サービス品質の低 したとしても、現行のサポート担当者のノウハウに 下はなくむしろサービス品質が向上した状態でサー は遠く及ばないからである。 ビスデスク導入を進めることができる。 そこで、導入初期は現行のサポート担当者が今ま IV. サービスデスク、プロフィットセンター化の成功要因 で通りサポートを行い、サービスデスクはお客様と サポート担当者のやり取りをキャプチャーしてイン メーリングリストを利用したキャプチャー型のイ シデント管理のみ行う形態とする。（図Ⅲ―1 参照） ンシデント管理のサービスデスク導入プロセスを経 キャプチャーによるインシデント管理を行っている た後に、サービスデスクをプロフィットセンターと 間に①システム内容の教育、②サポートマニュアル して運営していくにはどうすればよいのか。 の充実（サービスデスクで）③ FAQ の蓄積をするこ とで、徐々にサービスデスクで回答できる内容を増 コール・センタのビジネス構造を考えた時と同様に やしていく。このプロセスを持つことでサービスデ インシデント数（コール・センタではコール数）が一 スクをサービス品質の低下なしに導入することが可 つの目安となる。インシデント数がある一定以上ない 能となる。 と、プロフィットセンターとしては、非スキル型サー ビスデスクをスキル型サービスデスクに移行できない。 例えば、安定したシステムで、問い合わせや障害が 月に 1、2 件程度しか発生しなければ、サポート費用 も少なく、サービスデスクにかける費用も少なくなる。 当然、サービスデスク要員のスキルアップにかける教 育の費用を捻出することが難しくなり、マニュアルを 作成する費用も捻出することができない。更にインシ デントが少ないため、FAQ は増加しない。そして、何 よりもインシデントが少ないことでサービスデスク要 員がシステムサポートを経験できる回数が少ないこと キャプチャー型のインシデント管理行う上で大切 がスキル型サービスデスクに移行するうえでもっとも なことは、インシデント管理の責任はサービスデス 大きな障壁となる。 （図Ⅳ－ 1 参照） クが持っていることを明確に意識することである。 例えば、2 時間以内に回答を行う SLA となっていた 場合、2 時間以内に回答できるようにサービスデス クが担当者のマネジメントを行う。専任のサービス デスクがマネジメントを行うことで、サービス品質 の向上につながる。 2. 対応チャネルはメールが基本（メーリングリスト活用） キャプチャー型のインシデント管理を行うには、 メーリングリストを活用したメールでの対応が基本 となる。どうしても電話を利用せざる負えないとき は現行対応者に電話での顧客とのやり取りの内容 12 インシデント数とソリューション提供力を軸にビ スキル型サービスデスクを以下に説明するそれぞ ジネス構造を考えると、図Ⅳ―2 のようになる。 れの施策で低価格で提供することで他組織との差別 化を図る。 それと同時に、システムサポートではどうしても 発生する待機時間を利用して非スキル型サービスデ スクを低価格で提供する。 また、キャプチャー型インシデント管理を利用し スキル型サービスデスクにレベルアップすることで メインの業務であるスキル型サービスデスクを徐々 に増やすというビジネス構造が成り立つ。 以下に低価格でスキル型サービスデスクを提供す るための施策を簡単に説明する。 サービスデスクが 1 次窓口を行うにはキャプチャ ー型インシデント管理を利用した非スキル型サービ 1. 財務管理（スピーディな） スデスクから導入を開始する。その中で、採算ライ 提供サービス毎（システムサポート毎）に毎月ス ンを超えるインシデント数があり、顧客がスキル型 ピーディな財務管理を実施することで、財務状況を サービスデスクを望む（費用面も含めて）サポート 的確に把握する。 に関しては、教育、マニュアル化、FAQ 充実等でノ ウハウ向上を図り、スキル型サービスデスク／エキ 2. 多能工化（マニュアル化） スパート・サービスデスクに移行するというビジネ 主にマニュアル化を徹底的に行うことで、サービ ス構造が成り立つ。 スデスク要員が複数システムの対応を行えるように する。ただし、スキル型サービスデスクの対応を一 このビジネス構造では、スキル型サービスデスク 人が複数システムについて行うのはノウハウの面で の提供が、メイン業務となるので、当然、スキル型 かなり大変なので、非スキル型サービスデスクをス サービスデスクの他組織との差別化を考えなくては キル型サービスデスクの待機時間で行うことでサー いけない。 ビスデスクプロフィットセンター化で大きな障害と なる待機時間の発生を抑える。（因みに１人で対応 図Ⅳ―3 にサービスデスクのビジネス構造の 1 つ できるスキル型サービスデスクの数は３システム程 のモデルを示す。 度が限界である。） 3. 継続的な改善の仕組み 日常プロセスの中に組み込まれた継続的な改善の 仕組みを日常業務として行う。 4. ライフワークバランス サービスデスク要員のモラール向上のために、属 人性の排除や、毎月の残業時間抑止等の施策を行う。 13 きた時にはサービス提供組織として IT サービス継 V. サービスデスクの組織自体への ITIL® 適用 続管理（事業継続）もプロセスとして持っていなけ 当然ではあるが、サービスデスクの組織自体も れば、質の高いサービスデスクサービスの提供はで ITIL® を適用していることが重要な成功要因となる。 きない。 ITIL® 2011 edition サービスオペレーションのサ VI. まとめ ービスデスクの 6．3．2 サービスデスクの達成目標 には「典型的なサービスデスクでは、インシデント およびサービス要求を管理し、ユーザとの連絡も処 図Ⅰ－ 1 のそれぞれのシステムをそれぞれの担当 理する。」とある。サービスデスクの顧客への提供 者がサポートしている状況から図Ⅰ－ 2 のようにサ プロセスは①インシデント管理②要求実現そしてイ ービスデスクが 1 次窓口となる状態にスムーズに移 ンシデントの解析も行うので③問題管理の一部（イ 行するには、メーリングリストを利用したキャプチ ンシデント解析）となる。 ャー型のインシデント管理から始める必要がある。 一方、サービスデスクもサービス提供組織なので、 サービスデスクのプロフィットセンター化の成功 組織として ITIL® の他のプロセスも実装しているこ 要因は、①財務管理、②多能工化、③継続的な改善 とが質の高いサービスの提供には必要となる（図 V の仕組み、④ライフワークバランスの施策を使って、 － 1 参照）。 価格競争力のあるスキル型サービスデスクを提供す ることが必要となる。 そして、非スキル型サービスデスクからスキル型 サービスデスクへの移行は、採算ラインを超えたイ ンシデント数が必要となることを認識し、非スキル 型サービスデスクの提供を、待機時間撲滅のために 積極的に活用する必要がある。 最後に、サービスデスク自体が ITIL® の各プロセ スを実装していることも成功要因のひとつとなる。 VII. 最後に 図Ⅰ－ 1 のように、個々の担当者が開発したシス テムのサポートを苦労しながら、サポートしている 状況を少しでも改善したいということがサービスデ 提供プロセスの部分では、サービスデスクは、イ スク導入の大きな目的のひとつであった。 ンシデント管理、要求実現および問題管理の一部と してのインシデント分析をサービスデスクサービス 弊社の場合は、サービスデスクの導入は成功し、 として顧客に提供する．一方、顧客のシステムの変 サービスデスクの外販も実現することができた。 更管理やリリース管理等々はお客様の責任となる。 しかし、相変わらず、インシデント数が少ない採 サービスデスクをサービスとして提供する場合、 算ラインに乗らないシステムサポートに関しては、 サービスデスクサービスを実現するために内部のシ 担当者がソリューションを提供している状況であ ステムおよびプロセスが必要となる。このサービス る。 デスクサービスを実現するシステムおよびプロセス については、システム変更が必要であれば、サービ 今後その部分を如何にサービスデスクのビジネス スデスクで変更管理を行わなければいけないし、リ として取り込めるかが課題である。 リースも管理しなくてはいけない。また、地震が起 14 参考文献 ［1］「ITIL® V2 サービスサポート」TSO ［2］「ITIL® 入門」TSO ［3］「ITIL® 2011 edition サービスオペレーション」TSO 伊藤 俊治 株式会社 SSL パワードサービス 取締役 ITIL® マネージャ 株式会社富士通ソーソアルサイエンスラボラトリ 入社後、通信事業者様向けの大規模システム開発 担当。1997 年～ CRM パッケージ開発および拡販。 2002 年～各種サポート業務。主にサービスデスク。 2005 年～株式会社 SSL パワードサービス設立に携 わり、2005 年 11 月会社設立。 15 会員寄稿 クラウドコンピューティングと ITIL® 的ソーシングのすゝめ ～『借りぐらし』世代の反復的ソーシング・ライフサイクル。 『私たちは、そう簡単に滅びたりしないわ！』～ I. はじめに クラウドコンピューティングは「『過度な期待』の 本章では国際的なソーシング方法論として知られる 時期が過ぎ、冷静な判断が行われるようになってき OPBOK[2]、eSCM[3] に触れ ITIL® との位置づけを整理 ている（ガートナー /2013）」[1] と言われつつも依然 しておこう。 として高い市場成長の継続が予測されている。クラ ウドサービスの活用はアウトソーシングの変遷の中 I.1 OPBOK に見られるソーシング・ライフサイクル で生まれた一形態にあたり、より柔軟なソーシング OPBOK(Outsourcing Professional Body Of を実現する環境を企業に提供している。 Knowledge) は米国 IAOP( 国際アウトソーシング専門 家協会 ) が開発したアウトソーシングの専門知識体 本稿では、ITIL® では各ステージやプロセスに紛れ 系である。IAOP は世界で 12 万社の会員を有し、毎年 込んでしまっているソーシング関連の活動を一貫し 行われる「グローバルアウトソーシング 100」のラン たソーシング方法論で補完する一方で、従来の直列 キング評価などでも知られる。また OPBOK に対応し 的なソーシング・ライフサイクルに ITIL® に見られ た資格 (Certified Outsourcing Professional) 制度 る反復的ライフサイクルの視点を導入することを提 を国際的に展開している。日本でも OPBOK を含めた 案する。 ソーシング・ガバナンス知識の資格制度が APMG を通 じて展開されている。 クラウドコンピューティングのメリットの一つと して『借りぐらし』による「ポータビリティ（移転性）」 OPBOK ではソーシングのライフサイクルを図 I-1 に が進化を続けている。このことは、ますますクラウ 示すように、アイデア、アセスメント、実施、トラ ドサービス利用者がアウトソース先を容易に変更し ンジション、マネジメント、というステージで構成 たり、アウトソースされたものを再度インソースし している。( 筆者訳 ) やすくなることを意味している。今春で消費増税前 アイデア の駈込み住宅購入も過去の話になってしまったが『住 Idea 宅ローン返済より高い家賃を払う』理由を今後のソ ーシング戦略の考慮に入れていただきたい。アウト アセスメント ソーシングに伴うベンダ・ロックインという伝統的 Assessment な課題がクラウドコンピューティング世代に継承さ 実施 れないことを祈っている。 Implementation • コンセプト開発 • 企業の方向性識別 • アウトソーシング機会の分析、等 • 現状のプロセス・機能の分析 • アウトソースすべきプロセス・機能の定義 • リスク分析、等 • RFP発行、契約交渉、締結 • 移転（資産、要員）計画 • ガバナンス計画、等 *ITIL® is a Registered Trade Mark of AXELOS Limited トランジション Transition I. ソーシング方法論と ITIL® コンピュータ資産と関連要員など IT リソースを外 マネジメント 部に求める IT アウトソーシングは、データセンター・ Management サービスや xSP(ISP、ASP、MSP、など ) の普及、更に • 新組織の導入 • 資産・要員・プロセス・機能のトランジション • トレーニング、等 • 日々のマネジメント活動 • パフォーマンスの監視 • 関係管理、変更管理、等 図 I-1. OPBOK に見られるソーシング・ライフサイクル オンデマンド化要求や仮想化技術の採用を通じてク ラウドサービスへと新たな形態を取り入れてきた。 16 I.2 eSCM に見られるソーシング・ライフサイクル 初期のアウトソーシングのように 10 年単位の契 eSCM(eSourcing Capability Model) は IT 組 織 の 約であった頃と違い、今やオンデマンド化やクラウ ソーシング能力の成熟度を示すフレームワークとし ドによる『借りぐらし』の世代である。一旦アウト て米国カーネギーメロン大学ソフトウェアエンジニ ソースしたリソースをインソースしなおしたり、別 アリング研究所で開発された。国内でも多くの IT のより適切なサービス提供者に切り替えることがソ 企業が公式評価レベルをアピールしてきた CMMI の ーシング・ライフサイクルの中で行えなければ、ポ ような成熟度モデルの IT ソーシング版と言える。 ータビリティ（移転性）という『借りぐらし』の重 要なメリットが失われ、ベンダ・ロックインのリス クに変わってしまう。 eSCM ではソーシング・ライフサイクルを図 I-2 に 示すように、分析、開始、デリバリ、終了、共通と いうフェーズで構成している。( 筆者訳、尚クライ 賃貸契約の気軽さでローンを組んで住宅を購入し アント向けの eSCM である eSCM-CL に基づいている ) たものの、住み替えを考える頃には資産価値の低下 共通 Ongoing • ガバナンス管理 • 関係管理、等 とローンの残債が重荷になって身動きが取れないと 分析 Analysis 開始 Initiation デリバリ Delivery 終了 Completion • ソーシング機会分析 • ソーシング・アプローチ いう状況はあなたの身近にも耳にするのではないだ • ソーシング計画 • サービス提供者評価、ソーシング契約 • サービス移転 いながらこのような『持家』のリスクまで負ってし ろうか。ともすれば『借りぐらし』の高い賃料を払 まっては元も子もない。 • 委託されたサービスの管理 • ソーシング管理の実施 • パフォーマンスの監視、等 本稿ではクラウドコンピューティング時代におけ るソーシングについて、ITIL® をソーシング方法論 • ソーシングの終了 • 終了計画立案 • 委託先からの移転、等 で補完する一方で、従来のソーシング方法論に対し ては直列的なソーシング・ライフサイクルを ITIL® 図 I-2. eSCM に見られるソーシング・ライフサイクル の反復的なサービス・ライフサイクルで補完するこ I.3 ソーシング・ライフサイクルと とを提案したい。図 I-3 のように、ITIL® の反復的 ITIL® のサービス・ライフサイクル なサービス・ライフサイクルにソーシング・ライフ ITIL® においてはソーシング関連の活動は、サー サイクルを同期して反復的なソーシング・プロセス ビスストラテジのサービス・ソーシング、サービス を整備していくことで『借りぐらし』世代に適応し デザインのサービスレベル管理、サプライヤ管理な たソーシング・プロセスを構築できる、ということ どおいてソーシングの観点や活動が盛り込まれてい である。反復的ソーシング・ライフサイクルについ るものの、各ステージに紛れ込み・また記載も少な て詳しくは第Ⅲ章で述べる。 いことから、ソーシングの観点で一貫したプロセス を読み取るのは難しい。IT 組織がソーシングのプ ロセスを整備する際には OPBOK のようなソーシング 方法論の一貫したソーシング・ライフサイクルで ITIL® を補完することが望ましいと考えられる。 一方、上記で見てきた OPBOK、eSCM のような従来 のソーシング・ライフサイクルに見られる特徴は、 システム開発で言えばウォーターフォール型のよう な直列的なライフサイクルであることである。大胆 に解釈すれば、アウトソースされた後はサービスが 終了するまでアウトソーサにベンダ・ロックインさ れることを前提もしくは基本形にしている、と言え る。 図 I-3. ITIL® のサービス・ライフサイクルと OPBOK、eSCM のソーシング・ライフサイクル 17 Ⅱ . クラウドコンピューティングとソーシング戦略 ITIL® ではサービス・ソーシングを「サービスを 内部で提供するか、または外部サービス・プロバイ ダにアウトソーシングするかを決定するための戦略 とアプローチ。サービス・ソーシングは、この戦略 の実施も意味する。」と定義している。 本章ではソーシング・ライフサイクルの中でもソ 表 II-1 代表的なクラウドサービスの形態 ーシング戦略の肝である意思決定マトリックスを中 心にクラウドサービス利用検討のポイントを整理す る。更にそのソーシング戦略は、一旦アウトソーシ Ⅱ .2 ソーシング意思決定マトリックスとクラウド ング機会を得た場合でもその後の変動要因によりイ サービスの対象リソース ンソーシング機会を再度得ることを例示する。 ソーシング意思決定マトリックスは、ソーシング の検討対象を、その汎用性 / 特殊性といった差別化 Ⅱ .1 クラウドサービスの形態と の視点や自組織の Strong/Weak といった市場優位性 アウトソーシング対象リソース の視点でポジションニングを整理しソーシングの判 クラウドコンピューティングで検討されるアウト 断 (In/Out) を支援するツールであり、OPBOK でもア ソーシングの対象リソースの主なものとしては、設 ウトソーシング機会の分析における手法として記載 備や HW、SW、などのコンピュータ・リソースとアプ されている。図 II-1 は OPBOK を参考に筆者が作成 リケーション開発要員、インフラ構築要員、運用管 したソーシング意思決定マトリックスの例である。 理要員などの人的リソースがある。 単純に言ってしまえば右上にあるほど内部留保（イ ンソース）、左下にあるほどアウトソースの機会が 高いと判断するものである。 これらは近年整理されてきたクラウドサービスの 形態である IaaS/PaaS/SaaS の分類に沿ってソーシン グの判断材料とすると良いだろう。IaaS/PaaS/SaaS 外部サービスに対する優位性 の各形態の特徴については表Ⅱ -1 を参照されたい。 （参考：ウィキペディア「クラウドコンピューティ ング」[4]） クラウドサービス形態に沿ってアウトソーシン グの対象リソースを考える場合は、階層的な包含 関係と各コンピュータ・リソースに関連する人的 リソースを想定することになる。階層的な包含関 例えば、 優位性の維持向上の ために内部留保 ／ 特殊化領域への フォーカスのために アウトソース 例えば、 能力補完や 「規模の経済」効果の ために アウトソース 例えば、 更なる特殊化や 優位性の維持向上に 向けて 内部留保 例えば、 能力の成長に 向けて内部留保 ／ 能力を補完する ために アウトソース 係とは、PaaS を例にとればそのインフラ・リソー 特殊化要因の重要性 スの提供である IaaS のサービス内容を包含して 図Ⅱ -1 ソーシング意思決定マトリックスの例 いるということである。関連する人的リソースと は、コンピュータ・リソースに紐づいた運用保守 の要員などである。勿論サービス管理やユーザサ これにクラウドサービスのサービス形態の観点 ポートについてはクラウドサービスの対象外とし で対象となるリソースをマッピングしたものが図 て別途検討する必要がある。 Ⅱ -2 である。例えば特殊性が高く自組織の強みを 生かすべく右上におかれた「戦略的なアプリ」は、 ビジネスの俊敏性を支えるアプリケーションなど 昨今のアジャイル開発や DevOps などによりインソ ース化が提唱されている領域をイメージしていた だきたい。勿論この場合でもプラットフォームや 18 HW については左半分におかれているようにクラウ 考えていただきたい。尚、本稿で述べるインソース ドサービスにアウトソースされている場合がある。 の範囲としては所謂「内製」だけでなく、委託先の リソース ( 資産、要員 ) を自社環境として利用する 本稿で主に述べているクラウドサービスの対象 所謂「オンプレミス型プライベートクラウド」のよ リソースは左半分に配置している。汎用性の観点で うな形態を含むものを想定しているので留意され 左からインフラストラクチャ / プラットフォーム / たい。 アプリケーションと順に置いているが、縦長の領域 に配置している点に留意いただきたい。これは組織 (1)HW 等インフラストラクチャ により外部サービスとの優位性が違うということ 先ず、IaaS の対象となるインフラストラクチャ に加えて、組織の状況が変動しうることを表したも であるが、コンピュータ・リソース、人的リソース のである。下方に位置すればアウトソーシング機会 について下記のような例があげられる。 が強く、上方に位置すればインソーシング機会が強 ・コンピュータ・リソース くなる。これらの変動要因の影響が強ければ、より ▶初期予算を抑えるために IaaS を利用してサー 反復的にソーシング戦略を練り直す必要が出てく バを立ち上げたが、システム負荷が安定し、か るのである。「過度な期待」のピーク期を過ぎた現 つ今後も長期に稼働が見込まれるため、購入し 在、我々はクラウドコンピューティングにおける変 なおした方がトータルコストを抑制できるこ 動要因を前提にしたソーシング・ライフサイクルを とがわかった。 ▶自社の仮想環境が整備されリソース・プールが デザインし実行すべきだと考える。 確保されたため、IaaS 上の仮想サーバを引き 取れるようになった。 ・人的リソース ▶自社内環境の運用業務改善により、社内の運用 体制に余裕が出来た。 ▶自社の仮想環境の整備と共に、社内の運用要員 に仮想環境のシステム管理についてトレーニ ングが十分行われた。 (2) プラットフォーム インフラストラクチャ上のプラットフォーム領 域については下記のような例があげられる。 ・コンピュータ・リソース 図Ⅱ -2 クラウドサービス対象リソースの配置イメージ ▶ PaaS で構築したアプリケーションの利用が進 むにつれ DB アクセス処理の性能が次第に低下 Ⅱ .3 ソーシング戦略の変動要因と してきている。サーバのリソース割当てを増や クラウドサービス利用見直しの可能性 しても効果がなく（もしくは増やせず）、社内 クラウドサービス利用におけるソーシング戦略 で採用している DB サーバの DBMS のように思う の変動要因を考えてみよう。本節では II.2 で述べ ようにチューニングが進まない。 た図Ⅱ -2 の左半分、つまりインフラストラクチャ ▶アプリケーション構築後の長期利用において / プラットフォーム / アプリケーションについて変 PaaS 環境を利用し続けるよりも、IaaS や自社 動要因を整理し、ありがちなクラウドサービス利用 の仮想サーバ上でオープンソースのミドルウ の見直し即ち、インソーシング機会について述べ ェアにコンバージョンした方がトータルコス る。図Ⅱ -2 において外部サービスに対する優位性 トを抑制できることがわかった。 （縦軸）がない（下方に位置した）ためにクラウド ・人的リソース サービスにアウトソースしていたものが、様々な ▶自社内環境の運用自動化など業務効率化によ 変動要因により優位性を取り戻し（上方に移動し） り、社内の運用体制に余裕が出来た。 て再度インソースする機会が高まってくるものと ▶社内の運用保守要員に OS やミドルウェア利用 19 についてのトレーニングが十分行われた。 抑制できる状況になった。 (3) アプリケーション ②サービス提供者 OS、ミドルウェアなどのプラットフォーム上に構 外部サービス提供者の専門性に対し、自社要員の 築されるアプリケーション領域については下記の キャパシティやスキル・ノウハウ不足があったが解 ような例があげられる。 消された。 ・コンピュータ・リソース クラウドサービス提供者の能力が期待に満たな ▶ SaaS で構築したアプリケーションで障害が頻 かった。 発しているがブラックボックスなため自社で は対処できないし、サービス提供者の対処も不 ③便益 透明なまま、可用性、性能が改善されない。 他の自社内システムのための人的リソースやシ ▶アプリケーション構築後の長期利用において ステム運用基盤の整備によりアウトソースされて SaaS 環境を利用し続けるよりも、自社環境や いるシステムにも対処できるようになった。 他のクラウド環境上にコンバージョンした方 がトータルコストを抑制できることがわかっ ④実行の容易さ た。（システム開発コストの大半をしめる要件 他の自社内システムにおける共通の管理プロセ 定義、設計の必要が無い） スがあり、巻き取りやすい。 ・人的リソース 自社の仮想環境整備が進み、クラウドサービスの ▶自社のサービスデスクの一次対応でアプリケー ポータビリティを活用してコンピュータ・リソース ション利用者からの問合せに対処できるよう を容易に移転できる状態になった。 になった。 ▶アプリケーション運用について SaaS 提供者に Ⅲ . 反復的ソーシング・ライフサイクル アウトソース出来ない領域があり、結局社内の 運用保守体制を維持する必要があった。 最近のレポート「アウトソーシング・アドバイザ リ：サービス・ソーシング戦略策定の実行（ガート Ⅱ .4 アウトソーシング機会の優先付け尺度とイン ナー /2014）」[5] では「70% 超の企業が、重要なア ソーシング機会 ウトソーシング契約の評価時にのみソーシング戦 OPBOK ではアウトソーシング機会の優先付けにお 略を策定している」との所見を示している。これは ける尺度として下記を挙げているが、Ⅱ .3 で挙げ 第 1 章に挙げた従来の直列的なソーシング・ライフ た例はこれらがインソーシング機会の目的におい サイクル上の上流工程としてソーシング戦略が一 ても当てはまることを示している。 度実施されそのまま放置されている状況を示して ①財務…予算への影響・効果、等 いるのではないだろうか。とりわけクラウドコンピ ②サービス提供者…規模や専門性、等 ューティングにおいては『借りぐらし』のメリット ③便益…リソースの解放、コスト削減等 であるポータビリティを前提として、反復的ソーシ ④実行の容易さ…4 プロセスの明確さ等、移転のし ング・ライフサイクルに切り替えていく必要がある ことを述べてきた。 やすさ 上記の観点でⅡ .3 に挙げた例を整理すると下記 本章では ITIL® の継続的サービス改善に見られる のようになり、一旦クラウドサービスにアウトソー 反復的なサービス・ライフサイクルを取り込んだ反 スされたリソースについて、時間の経過と共にイン 復的なソーシング・ライフサイクルの導入を提案す ソースしなおす機会が発生することが分かる。 る。これは同時に、ITIL® に基づいたサービス・ライ フサイクルの運営にソーシング・ライフサイクルを ①財務 統合し、クラウドコンピューティング時代に適応し 初期コストを抑制するためにクラウドサービス た IT サービスマネジメントを提案することでもある。 を採用したが、継続稼働のランニングコストを考慮 するとインソースし直した方がトータルコストを 20 Ⅲ .1 ポータビリティを前提とした ったソーシング・ライフサイクルである。この反復 反復的ソーシング・ライフサイクル 的ソーシング・ライフサイクルを ITIL® のサービ 従来の情報システムのアウトソーシングでは新 ス・ライフサイクルと同期をとる形で構成したも 規システム開発や移転プロジェクトの膨大な初期 のが図Ⅲ -1 である。これにより、第 1 章で挙げた 費用をかけ、一旦ベンダにアウトソースすると契約 OPBOK や e-SCM というソーシング・ライフサイクル 更新時に条件見直しなどがあるにせよ、ソーシング の標準で ITIL® のサービス・ライフサイクルを補完 自体を見直すことはされない傾向にある。また内部 する一方で、ソーシング・ライフサイクルをクラウ ナレッジの遺失やアウトソース先でのブラックボ ドコンピューティングのポータビリティを明確に ックス化が進み、時間の経過と共にインソースする 意識した反復的なものとすることができる。 ことが困難になっていた。 サービス ストラテジ ベンダ・ロックインとは「特定ベンダの独自技術 ソーシング ストラテジ • 組織の方向性識別 • ソーシング機会分析 • ソーシング対象領域(In/Out)の定義、等 ソーシング デザイン • アウトソーシング仕様(資産、プロセス等)の定義 • サービス提供者評価、アウトソーシング契約 • 移転計画、等 サービス トランジション ソーシング トランジション • サービス提供者への移転(サービス、業務、等) • サービス提供者の切替 • サービス提供者からの移転(インソーシング)、等 サービス オペレーション ソーシング オペレーション • 日々のマネジメント活動 • パフォーマンス監視、関係管理 • 変更管理(資源利用量の拡大・縮小も含む)、等 継続的 サービス改善 継続的 ソーシング 改善 サービス デザイン に大きく依存した製品、サービス、システム等を採 用した際に、他ベンダの提供する同種の製品、サー ビス、システム等への乗り換えが困難になる現象の こと（ウィキペディア）」と言われているが、上記 のアウトソーシングにおける状況もベンダ・ロック インの一つと言える。 クラウドコンピューティングにおけるアウトソ ーシングでは、「特定ベンダの独自技術に大きく依 • ソーシング効果のレビュー • 教訓などナレッジの棚卸 • ソーシング・プロセスの見直し、等 図Ⅲ -1 サービス・ライフサイクルに沿った 反復的ソーシング・ライフサイクル 存」しなければならない状況は限定的であり、仮想 化技術によるポータビリティを前提とすればベン ダ・ロックインの発生はソーシング・プロセスの問 Ⅲ .2 ポータビリティに伴うベンダ・チェンジの機会 題として解決できる範囲が多いと考えられる。 本稿では、アウトソースからインソースへの移行 例えば、IaaS 上の仮想サーバは、自社内に仮想 について主に述べてきたが、インソーシング戦略を 環境を構築できれば HW など物理的な制約を受けず とらない場合やナレッジ不足などによりインソー にサーバ自体を電子データとして簡単に自社内に スは時期尚早と判断する場合でも、クラウドコンピ 移転できる。たとえ SaaS 上のアプリケーションで ューティングにおけるポータビリティ技術の進展 も標準化した業務アプリケーションであればベー に伴い、他のサービス提供者へのベンダ・チェンジ スとなるパッケージの選択肢も増え、さらに利用中 の機会はより現実的な選択肢となってきている。 の SaaS として機能要件や設計が実体として具体化 している状況では工期と工数の不透明なシステム クラウドコンピューティングは「『過度な期待』 開発の上流工程を経ずに、所謂コンバージョンによ の時期が過ぎ、冷静な判断が行われるようになっ って自社内のサーバ環境に移転することも出来る。 てきている（ガートナー /2013）」と言う時期を迎 PaaS 上で開発したシステムなら、オープンなミド えサービス提供者の淘汰が進むとも言われている。 ルウェア環境を採用していればいるほど、より容易 サービス料金等の契約条件についてもサービス提 に自社内のシステム基盤にコンバージョン出来る 供者間の差別化が進むだろう。クラウドサービスへ だろう。このようなポータビリティを前提にすれば の品質的な不満が、より適切なサービス提供者へベ 大半のシステムでは技術的にベンダ・ロックインに ンダ・チェンジすることで短期的に解消される可能 陥る必要はないのである。 性もある。 そこで本稿で提案するのは、ポータビリティを前 前節の例のように IaaS で互換性のある仮想化基 提とし、ソーシング状態を反復的に判断し、必要に 盤を採用しているサービス提供者間では HW として のサーバを電子データとして移転するだけであり、 応じてソーシング状態を切り替えるプロセスをも 21 従来のデータセンター・サービスにおけるコロー のインソースに向けてポータビリティを担保した ケーションとは異なり技術的な負担が非常に軽い。 クラウドサービス利用を誘導する。 また SaaS から移行して IaaS や PaaS に移行してア プリケーションをコンバージョンするような中間 ②サービス・ポートフォリオ、サービス・カタログ の整備と運用 的な再インソースもベンダ・チェンジの機会となる アウトソースしたサービスをサービス・カタログ だろう。 に組込み継続的に管理すると共に、将来の更改や 上述の反復的ソーシング・ライフサイクルのモデ 継続稼働についてのポートフォリオを継続的に把 ルにおいても、各ステージにおいてベンダ・チェン 握できるようにする。 ジをインソースへの切替えと同様に一つの選択肢と これにより、「財務」の観点での外部サービスへ して考慮できるように配置している。（図Ⅲ -1 のソ の優位性など時系列的なソーシング戦略の変動要 ーシングデザイン、ソーシングトランジション等） 因・インソーシング機会を把握できるようにして おく。 IV.『そう簡単に滅びたりしない！』 インソーシングに向けたチャレンジ ③運用プロセス整備、運用自動化による効率化 サービス・オペレーション領域などの ITSM プロ クラウドコンピューティングという選択肢の登 セスの整備や、RBA 等運用自動化環境の整備を通 場とビジネスの俊敏性要求の高まりは、IT 部門で じて既存 IT 部門の運用業務の効率化を推進する。 俊敏な対応が出来ない IT 化要求をビジネス部門か 「サービス提供者」の観点で、外部サービスに対 ら直接アウトソーシングする流れを助長する。これ する優位性を上げ、インソーシング機会を拡大す はビジネス部門が自身で IT 化を推進する従来のエ る。 ンドユーザコンピューティングの領域が更にネッ トワークアプリケーションへと拡大しやすい状況 ④仮想化基盤の整備、仮想化環境の管理スキルの習熟 を迎えているということである。例えばエンドユー サーバ仮想化など企業内の仮想化基盤の整備と ザコンピューティングで一般的な Excel での案件管 共に仮想化環境の運用・管理スキルの習熟を進め 理を SaaS の CRM にリプレースするようなソリュー る。 ションがビジネス部門に向けて直接提供されてお ハードウェアなどコンピュータ・リソースに対す り、このような市場環境にあることを IT 部門は意 る「便益」の観点で外部の IaaS に対する優位性 識するべきだろう。DevOps-NoOps などの流れと相 を上げ、また移転の「実行の容易さ」を確保する まって IT 部門不要説、特に IT 運用部門不要説を後 ことによりインソーシング機会を拡大する。 押しする材料になる恐れもある。IT 部門存亡の危 機となるケースも出てくるだろう。 ⑤オープン・ソース、DevOps ツールなどプラット フォーム技術のキャッチアップ このような状況下で IT 部門は企業内の IT に責任 DBMS や ア プ リ ケ ー シ ョ ン・ サ ー バ、Web サ ー バ を持つ立場として無秩序なクラウドサービスへの な ど オ ー プ ン・ ソ ー ス の ミ ド ル ウ ェ ア 利 用 や、 アウトソーシングをコントロールしつつ、ソーシン DevOps ツールなど保守用ソフトウェア利用などプ グの最適化に向けた中長期的な方策をとっていく ラットフォーム技術をキャッチアップし、ライセ ことを提案したい。特に既存の IT 資産としてコン ンス費用の抑制やベンダ非依存のポータビリティ ピュータ・リソース、人的リソースを有する組織に の高いソフトウェアを利用できる状況を準備する。 ついてはアウトソースされた資産を再度インソー プラットフォームに対するどコンピュータ・リソー スする機会を創出する中長期的な努力が必要であ スに対する「便益」の観点で外部の PaaS に対する る。その主要なアクションを下記に提言する。（鉤 優位性を上げ、また移転の「実行の容易さ」を確保 括弧についてはⅡ .4 節を参照されたい） することによりインソーシング機会を拡大する。 ①クラウドサービス利用のガイドライン策定と展開 ビジネス分門の支援をする立場をとりつつ、将来 22 V. まとめ 本稿では、近年のクラウドコンピューティングの 広がりを踏まえ、今後 IT サービスマネジメントに 求められるソーシングの観点を国際的なソーシン グ方法論から取入れる一方で ITIL® の継続的サービ ス改善の概念を取込んだ反復的ソーシング・ライフ サイクルの導入を提案した。 反復的ソーシング・ライフサイクルにおいては、 クラウドコンピューティングの特徴であるポータ ビリティの効果を活かすために、中長期的なインソ ーシング機会を考慮した IT 部門の方策が求められ ることを述べた。 ビジネス変革のスピードが求められる近年、クラ ウドコンピューティングが新たなアウトソーシン グの提供を広げる一方で、企業の IT 部門の位置づ けが問われ、特に IT 運用部門については存亡をか けた変革が求められるケースも増えることだろう。 本稿がそのような IT 部門の今後のあり方について 検討の一助になれば幸いである。 株式会社シグマクシス 小澤 一友 マネージャー ITIL® V2 Manager / V3 Expert Certificate ＜参考文献＞ PMP [1] 「日本におけるテクノロジのハイプ・サイク ソーシングガバナンスファンデーション認定 (COS-FP) ル：2013 年 」 ガ ー ト ナ ー (2013/9) http://www. 1992 年、自然言語処理への関心から IT 企業に入社、 gartner.co.jp/press/html/pr20130903-01.html システム開発／保守、特に広域監視システムの研究・ [2]「Outsourcing Professional Body of 構築などシステム運用管理関連の経験を経て、2004 年 Knowledge」International Association of 4 月 ITIL® マネージャ認定を取得後、組織的な ITIL® Outsourcing (2010) 活用推進、品質改善活動に取組む。以降 IT 企業数社 [3]「The eSourcing Capability Model for Client にて IT 運用改善、IT サービスマネジメント導入コン Organizations (eSCM-CL) v1.1」Bill Hefley, サルティング、IT アウトソーサ創業に際した品質マネ Ethel A. Loesche (2009/11) ジメントシステムの構築などを経験。現在 ITSM 運営 [4]「クラウドコンピューティング」ウィキペディ 組織とソーシング管理研究分科会副座長。 ア http://ja.wikipedia.org/wiki/ ク ラ ウ ド コ ン ピューティング [5]「アウトソーシング・アドバイザリ：サービス・ ソーシング戦略策定の実行」ガートナー (2014/1) http://www.gartner.co.jp/b3i/research/140513_ sor/index.html 23 会員寄稿 Proactive な Service Transition ～開発と運用の協業 （DevOps） および IT 価値向上の実現と人材育成～ Ⅰ 価値実現のスピードやサイクルをどう早めるか を早める意での DevOps が語られることも増えまし た。 し か し、Agile の 根 本 で あ る Agile Project 手作業の機械化という、古典的な価値提供 が一段落して以降、IT 業界は常に自らの価値 Enterprise ITをめぐる潮流・・SoR/SoEという捉え方 創出に腐心してきました。最重要は本業やユ ーザーにとっての価値実現であり、その実現 スピードやサイクルが、常々の課題でした。 最近では Agile などの方法論や DevOps など Systems of Record 『定型業務処理システム』 Systems of Engagement 『協働のための情報活用システム』 焦点 トランザクション 対話 ガバナンス 統制 強調 主な要素・ 記録形式 事実、日付、契約 文書 洞察、アイディア、ニューアンス 会話 価値 事実は一つの情報源 発見と対話のためのオープンな場 立ち位置 データ中心 利用者中心 使い勝手 ユーザーがシステムを学ぶ システムがユーザーを学ぶ 性能の基準 正確性と完全性 即時性とアクセスの容易性 ポリシー セキュリティ（資産の保護） プライバシー（利用者の保護） も、その解決策や救世主の 1 つとして、議論 されてきました。 対象が新規開発／構築ならば、最新の技術 やインフラを惜しみなく活用できます。あた かも「新しいぶどう酒を古い革袋に入れるも のはいない。」（新約聖書：マタイによる福 「Systems of Engagement and The Future of Enterprise IT - A Sea Change in Enterprise IT」 Geoffrey Moore, AIIM White Paper, 2011 より一部抜粋・英訳 音書 9 章 17 節）の言葉どおりです。まさに 図1 CAMS（Cloud, Analytics, Mobile, Social） などの新興分野は、Agile 開発やそれらを取 Management は、インクリメンタル開発や段階的リリ り巻くツールを活用するに最適の状況といえるでし ースと類似であり、アプローチや方法論の点では、 ょう。 過去 Waterfall を主とする場でも対比／試行されて きたものです。導入成功の鍵は、「部分的反復開発 我々にとって悩ましい問題は、多くのケースで多 にパラダイムシフトできるチームや環境である事」 くの既存資産を抱えているという事実です。更地 「自己組織化（Self Organized）されたチームとし に新しい家を建てるが如き新規開発／構築は、SoR て自律的／自立的に活動できる事」等にあることを、 （Systems of Record: 『 定 型 業 務 処 理 シ ス テ ム 』） 我々は学んでいます [2]。また、道具やインフラと [1] の世界においては、残念ながら主流ではなくな しての Agile ツールは、CAMS などの新興分野では有 って久しい状況です（図 1）。大半は改修・保守で、 効なものの、古い革袋の救世主とするにはインフラ、 既存システムの考慮は常に前提であり、再構築やス 人材、スキルなど様々なリソースの面で困難を伴う クラップ＆ビルドの場合でも、既存との連携抜きに ことが多い現実もあります。 は成立しえないのが現実です。 結局、スピードやサイクルを早めたいのであれ 開発からリリースまでのスピードやサイクルを ば、まず足元の Service Transition を再検討する 早めるために、Agile 開発や継続的インテグレー ことになります。Flickr は 1 日 10 回以上ものデプ シ ョ ン（Continuous Integration）、Agile to Ops ロイを実現できる重要な要素として、ハート印に 24 DevOps と書いた象徴的絵柄とともに、「開発と運用 既存資産の開発に従事した世代が現役の間は、問題 の協業（融合）」という「のりしろ領域」の改善を を表面化させることなく推移させることもできま 挙げています [3]。ITIL® の有識者も語るとおり、 した。シニア層の一斉退社が目前になると、急速な 実際のところ DevOps が対象とする領域は、Service 世代交代を前に技術伝承が進められましたが、業務 Transition そのものであり [4]（図 2）、ITIL® の概 スキル移管や安定稼働維持など目前の重要な基本 念・プロセス等の活用は、DevOps をも補強し、相 実務で精一杯、応用業務やのりしろ分野までは中々 乗効果を生むものとなると考えます。 行き届きません。また、最新の管理ツールを活用で きる新規分野でも、管理レベルや管理プロセスの成 DevOps と ITIL® Service Transition 熟度が上がらなければ、同様の事態を招くことは容 ITIL®で定義されている機能やプロセスは、Agile to Opsでも必要 DevOpsですべき事は、既にITIL®で語られ、実績もある 易です。移行を一過性のつなぎと見なし、やっつけ ※Service Transitionのプロセスと活動 仕事で済ませていると、結局は相応の代償を払う事 移行計画、変更管理、サービス資産管理、構成管理、 リリース管理、展開管理、サービスの妥当性確認・テスト、 評価、サービス・ナレッジ管理 など 態が生じます。 移行・移管は本来、投資（開発局面）を、成果 や価値を生む段階（運用局面）に持ち込む上で必 須の通過点です。IT ガバナンスの面でも重要なコ ントロールポイントであるため、本番稼働の可否判 定や承認などは、必然的にプロセス重視の運営と ならざるを得ない面もあります。一方、Agile to 「Maximize the synergies between ITIL and DevOps」 Anthony Orr, BMC Software 図2 Ops や継続的インテグレーションなど新興分野の視 点でみると、各種のプロセス定義やその遵守は、迅 Ⅱ 「のりしろ領域」の重要性とスキル不足 速さに欠け官僚的に映りがちです。同様の観点から ITIL® についても、柔軟性に乏しいと見なされる事 SoR での課題の 1 つに、開発と運用の谷間を埋め を懸念する意見すらあります [5]。 る人材やスキルの不足が挙げられます。IT 業界で は長らく“開発 (Dev)”と“運用 (Ops)”という二 移行・移管をめぐる方法論は最終的に、即応の必 元論的な組織・体制で、多くの業務や人材育成が進 要性や業務の特性、選択した開発メソドロジーな められてきました。狭間である“移行・移管”は、 どにより必然的に決定されるもので、即応や自動 本番稼働前の重要な活動ではあるものの、創造性が 化の要否は、運営コストも含めての判断となりま 少ない面も含め、言わば“スキマ仕事”“引っ越し す（図 3）。再認識すべきは、その重要性を認識し、 作業”的な認識で、片手間で片づけておくに過ぎな Service Transition という独立した局面を整理し、 い分野として扱われてきた感があります。加えて稼 果たすべき役割を体系化してきた ITIL® の先見性で 働優先・コスト重視で物事を進めると、本来ならば す。必要なプロセスや機能は詳しく定義され、コア 本稼働前後で整備・蓄積・伝承されるべき各種情報 の総括にも手が回らず、時間の経過とともに散逸、 即応の程度を問い直してみる 結果として管理が立ち遅れてしまう場合も少なく ・一刻を争うリリースが必要か? 即応要でなければ、着実に、品質高くリリースすればよい ・Agile or Waterfall は手段の議論、目的ではない、向き不向きあり （例：ネット販売サイト vs. 銀行ATM） ないのが現実です。 Service Transition が 定 義 す る プ ロ セ ス と 活 動 の 中 で も 特 に、 サ ー ビ ス 資 産 管 理 お よ び 構 成 管 理（SACM: Service Asset and Configuration Management）は、その懸念が該当しがちな分野です。 資産に関する正確で信頼性ある情報を整理し、必要 な時に必要な所で利用可能とする事が求められて きましたが、情報も文書も継承しきれていない古参 図3 の資産は、現実には多数存在しています。それでも 25 ブ ッ ク（『ITIL® Service Transition』） と し て 集 したいと考えました。また Service Transition を 大成されています。その概念とフレームワークは、 IT サービス・ライフサイクルの要と捉え、活動の 開発 (Dev) と運用 (Ops) といった二極軸ではなく、 意義を適切に再認識してもらう必要もありました。 価値追求を目的とし一体化されています。組織やチ 次章では上記を背景にして進めた、プロセス推進 ームの構築、あるいは人材育成においても、「のり の考慮点やチーム構築での工夫など、Proactive な しろ領域」での活動の指針を、体系的・網羅的に参 Service Transition のあり方について提言します。 照できる利点があります。DevOps やその適用を論 じるのであれば併せて、ITIL® Service Transition Ⅳ Proactive な Service Transition に集大成されている役割論やベストプラクティス を、自組織に照らして確認すべきと考えます。 移行・移管の業務はその本質から、いわば「つ なぎ」を本業としています。一見すると、一時的・ Ⅲ Service Transition はライフサイクルの要（かなめ） 通過点・調整役など、その道を究めるプロフェッシ ョナルのイメージとは程遠い感があります。しかし 専門分野としての共通認識が薄く、体制作りや人 何事にもよい面はあるもので、全体感が求められ俯 材育成も後回しになりがちな反面、本番稼働直前の 瞰の機会も多いなど、キャリア面では多様で有用な コントロールポイントである移行・移管の重要性 経験も得られる場です。 は、今日的課題も相まってますます高まるばかりで す。変更管理や構成管理、リリース管理／展開管理 Service Transition に お い て 理 想 的 な 人 材 は、 などが中心であることから、元より QCD（品質・コ その職務面より、開発と運用のどちらにもある程度 スト・納期）は重視されてきましたが、今や IT ガ 事情通で、相互の狭間においてリーダーシップも バナンスやセキュリティの確保など、要求される分 相応に発揮できる人ということになります。適切 野も格段に広がり、管理レベルの向上も強く期待さ な Skilled Person が存在すれば、業務運営上は何 れています。例えば、権限分離（SOD: Separation よりですが、多様な経験を得てほしい中堅にとって of duty）の徹底やその管理、リリースおよび展開 も、今後にとってよい機会となります。キャリアパ をめぐる安全性や耐監査性の確保などは、その典型 スとして一定期間担当し、次世代とのローテーショ と言えます。 ンを図る位置付けとすれば、IT サービス全般にも 組織にも見渡しが効き、多様な機会と経験を得られ 筆者が Service Transition をめぐる期待と現実 る又とない場を、多くの人に経験してもらうことも のギャップ、課題や矛盾に気づいたのは、この 10 できます。 年に携わった幾つかの統合・再構築プロジェクトの 推進がきっかけでした。1970 年代からの資産も相 現実にはプロジェクトの実情と喫緊の課題から、 応に抱える中、経営方針の転換に伴なう大規模改修 人事異動を伴う職務命令と組織再編により、人材の が必要とされていました。開発・運用それぞれに課 確保と Service Transition のチーム構築を行ない 題がありましたが、Service Transition の領域は ました。並行して、Service Transition を IT サー 特に、人員もスキルも不足していました。長期にわ ビスや組織への理解を深める場と捉え、期間限定 たり小規模改修・保守が中心で、コスト重視での運 のキャリアパスとして位置付ける工夫も進めまし 営も求められており、移行・移管に関わる人材やス た。以下はその際に留意した進め方や、個人の成 キルは、必要性の面からも後回しとなりがちでし 長を促す動機づけの具体策であり、それらを ITIL® た。いわゆる「業務共通」「開発基盤」等と呼ばれ V3 のプロセス視点から再整理しています。加えて、 る類の組織、開発と運用の橋渡しを進め、本番稼働 ITIL® Service Transition が具体的な指針を与え に向けた煩雑な移行・移管を成功裡に計画・推進で ている部分についても紹介を試みています。 きる、のりしろチームの再構成が必要でした。 Ⅳ -1 移行戦略 チーム構築にあたり、業務上の責任や必要性理解 ～リリース範囲と依存関係のコントロール は当然ながら、従事する人々が面白いと感じられ 開発したアプリケーションをどの範囲で区切り る、活気ある場やモチベーションの高まる機会に いつ本番投入するかは、ユーザーに対する実現範 26 囲や IT 化の価値を左右する重要な問題です。移行 にあたっての重要な活動となってきます。関係者 戦略の段階で留意に努めるべき重要課題の 1 つに、 は、説明責任の発揮と適切なマネジメント判断の、 案件分割と依存関係の把握があります。 双方が求められます。 本番化の範囲や時期は、要件の確定や予算化を担 CAB の運営を通じて体得する、変更時の考慮点や う組織、費用・承認プロセス等の制約を受けつつ、 各種調整は、IT 従事者が Stakeholder Management 最終決定されます。当然ながら、IT 化に都合のよ を意識し実践する、格好の機会にもなります。重 い単位で、案件やリリース範囲が確定するとは限ら 要な事は、プロセスを進める作業者としてではな ないのが現実です。費用や配賦面からの起案分割、 く、当事者あるいはマネジメントとしての視点に 要件の確定度を踏まえた多段階化、五月雨式の予算 立つ事です。それにより、変更アセスメントにま 確保・承認による案件分割などは、現実には頻繁に つわる具体的な判断基準を、短期に数多く経験で 発生する話です。案件は分かれても一体のシステム きる上、利害関係者の種類や影響度・重要性など、 として機能し、万全な品質でサービスインを迎える Stakeholder Management についても経験値を増や 必要のあるケースも少なくありません。 す事ができます。 多くの場合は、開発開始前の企画段階でそのスコ ITIL® では変更申請・承認に関し、「変更管理の ープが調整されるものの、相応規模のプロジェクト 7 つの R」（図 4）という切り口で、有用な視点を提 や、案件が複数並走するとなれば、他の様々な事情 供しています（『ITIL® Service Transition -2011 も関与してきます。そして、開発作業がサイロ的に edition』P.74 ※以下頁記載は左記書籍）。併せ 進み始めるにつれ、案件やプロジェクトを跨る依存 「変更管理の7つのR」 関係のコントロールは、予定どおり益々困難になり 提起 （Raised） 変更を「提起（Raised）」したのは誰か？ 理由 （Reason） 変更の「理由（Reason）」は何か？ 見返り （Return） 変更に求められる「見返り（Return）」は何か？ リスク （Risk） 変更に伴う「リスク（Risk）」は何か？ リソース （Resource） 変更を行なうために必要な「リソース（Resource）」は何 か？ 定義や外部設計での検討事項でもあります。並行し 責任者 （Responsible） 変更の構築、テスト、および実施の「責任者 （Responsible）」は誰か？ て移行戦略を策定し、状況によってはマスタースケ 関係 （Relationship） この変更と他の変更との「関係（Relationship）」は何か？ ます。 依存関係の概略整理は、複数案件全体をマネジメ ントする観点からも、プロジェクトの早い段階から 必要となります。業務要件や見積に関わる事象（例： データ連携や既存プログラム再利用など）は、要件 ジュールの適切な時期にチェックポイントを設け 図4 ます。案件相互の俯瞰や依存関係を再確認し、移行 て Stakeholder Management やその戦略についても、 リスクの認識や対応策定を行なう機会を、計画段階 「利害関係者の管理」（『ITIL® Service Transition から組み込んでおくことが、遅延や手戻りを防ぐ上 -2011 edition』5.3 章 ※以下章記載は左記書籍） でも必要です。実施段階では、リリース・ユニット や「利害関係者マップと分析」（5.3.2 章）などで、 の整理やリリース・パッケージの設計により、リリ 分析の視点を提示し整理しています。特に「インパ ース範囲と依存関係のコントロールを進めます。 クト強度マトリックス」では、マネジメントすべき 利害関係者の分析方法を具体的に示し、その判断基 Ⅳ -2 変更管理 準も提示しています（P.217）（図 5）。 ～ RFC と CAB で体得する Stakeholder Management 変 更 管 理 の 中 心 と な る CAB（Change Advisory Stakeholder Management もまた、KKD（勘と経験 Board）は、影響範囲や影響度、前提条件／依存関 と度胸）で進められることが多い中、ITIL® が提示 係など、変更に関して総合的で包括的な判断を行 する分析例は、実践しやすい具体的視点となってい なう場です。申請側・承認側ともに、RFC（Request ます。ちなみに Stakeholder Management は、プロ for Change）を十分に理解・検討する必要があり、 ジェクトマネジメントにおいても注目の分野であ 関連機能・稼働状況など全体の俯瞰、影響度や変更 り、PMBOK® V5 では、独立した知識エリアとして再 リスクの整理等、相応の前準備や情報共有が、推進 定義された経緯があります（V4 では Communication 27 せん。結果的に適切な管理を継続的に実施すること インパクト強度マトリックス 中 低 高 中 低 が難しく、情報とナレッジの散逸が進みがちな現実 利害関係者に対する新規または変更された サービスの潜在的インパクト 高 があります。 特に既存資産の多い IT サービス組織においては、 状況はより深刻です。把握しておくべき情報の定義 と、それを継続的に遂行する体制や投資が伴わない 場合、世代交代と共に加速度的に、情報把握が困難 になりかねない面があります。維持管理が不十分な 場合、アプリケーション開発に関する基本文書（例： システム全体図、機能関連図、DFD、ERD、仕様書 変更の確実さとサービス技術に対する 利害関係者の重要性 『ITIL® Service Transition -2011 edition』 P.217 etc.）すら、散逸・欠落しかねない面があります。 図5 Management の一部としての位置づけ）。利害関係 何を把握対象としどう維持管理していくか。以下 者のマネジメントと、チームを動かす上で必須と は SACM の基本概念として ITIL® が定義する項目で なるコミュニケーションやその手段とでは、その す。少なくとも下記 3 つについては、相応に定義さ 要点や考慮点も異なっており、立て分けて進める れ、抜け漏れなく構築・集約・運営されている事が、 ことは、ある意味当然な成り行きでもあります。 管理の第一ステップになると考えます。 Stakeholder Management が、物事を進めるにあた り重要な要素であることは、プロジェクトマネジメ ＜ SACM の基本概念（P.92）＞ ントの視点からも明らかであると言えます。 ・構成アイテム（CI：Configuration Item） ・構成管理データベース（CMDB：Configuration Management Database） 標準的でリスクの小さな変更は、CAB を前提とせ ・構成管理システム（CMS：Configuration ず、自動化も含めた変更管理プロセスで処理を進 Management System） め、それにより生産性や品質の向上を狙うことも可 能です。しかしいずれの場合も、アセスメント／優 ※上記の他、サービス資産、構成モデル、構成レ 先順位づけ／スケジューリング／承認などが前提 コード、サービスナレッジ管理（SKMS）等 のプロセスであるため、判断にあたっては変更レ ベルに応じた利害関係者は関与し、進めていくこ 重要成功要因（CSF：Critical Success Factor） とになります。まさに RFC や CAB は、Stakeholder についても、ITIL® は指針を与えています。CSF の Management を繰り返し体得する活きた場であり、 1 つとして掲げているのが、“正確で完全な CMS の ITIL® はそれらに具体的な指針を与えています。 確立と維持”で、そのためのプロセスも詳細に定義 されています。具体的には、構成識別（4.3.5.3 章） Ⅳ -3 サービス資産管理と構成管理 や構成コントロール（4.3.5.4 章）などで、特に構 ～求められる俯瞰力 成識別については、以下ステップに分け丁寧に記述 SACM（Service Asset an Configuration されています。構成アイテムの識別は、把握すべき Management：サービス資産管理と構成管理）は、 対象を定義する事であり、保管の価値や必要性があ Service Transition の中でも後回しとなりがちで、 る情報を、将来的な観点も含めて見分け、判断する 立ち遅れてきた分野です。本来、重要な達成目標 活動でもあります。 の 1 つは、「変更とリリースの許可や、インシデン トと問題の解決など、人々が適時に決定を下せるよ ＜構成識別のステップ（P.100-108）＞ うな正確な構成情報を提供することによって、効率 ・構成構造と構成アイテムの選択 的かつ効果的なサービスマネジメント・プロセスを ・構成アイテムの命名 支援する」 （P.90）です。しかし、実態把握が必要 ・構成アイテムのラベル付け との認識はあっても、そのために十分なワークロー ・構成アイテムの属性 ・構成文書の定義 ド・時間・予算が確保できない場合も少なくありま 28 ・関係 リリースと展開の計画立案は、関連する成果物や ・構成アイテムのタイプ 文書の、バージョン管理・原本管理・ライブラリー ・メディア・ライブラリの識別 管理などと合わせて、煩雑で整理しづらい面も多い ・構成ベースラインの識別 活動です。変更の規模による考慮点のバリエーショ ・リリースユニットの識別 ン、HW/SW の違いによる作業の分断、それら各要素 でのバージョン／原本／保管先の考慮なども、分か 上記に加え、全体最適を考慮し整理・共有された りにくさを助長しています。 しくみ（システム）としかけ（プロセス）を推進し、 リリースと展開に関する概念と用語 維持管理が健全に機能するよう、組織として継続的 ・リリースと展開、リリースユニットとリリースパッケージ ⇒検討の段階を分け、必要な有識者の参画を得ながら整理 ・リリースの内容は適切な形で記録・保管・維持管理 な定着と徹底を進める事になります。 一緒にビルドされ、テストされ、展開される、ITサービスに対する1 つまたは複数の変更 展開 新規または変更されたHW,SW,文書、プロセスなどを、稼働環境 （デプロイ） へ移行すること リリース・ 同時にリリースされるITサービスのコンポーネント群で、一般的に、 ユニット ある有用な機能を実行するために十分なコンポーネントが含まれ る リリース・ 1つのリリースとして一緒にビルドされ、テストされ、展開される一 パッケージ 連の構成アイテムで、通常1つまたは複数のリリース・ユニットから 成る リ リ ー ス ・ リリースの内容を定義するレコード。リリースレコードは、そのリ レコード リースの影響を受ける全ての構成アイテムと関係がある。変更レ コードは、構成管理システム、またはサービスナレッジ管理システ ムの任意の場所に格納してもよい。 リリース 問題は、SACM の構築や継続的な運営による効果 を、長期的かつ大局的な観点からどう位置づけ、組 織として共通認識していくかにあります。本来は 将来に向けた強みとなるはずの活動ですが、単な る管理台帳の延長線上で捉えると、実機・現物と 台帳の一致や、整合性確保に費やす手間等に目が 行きがちです。本当に適切な情報蓄積を実施でき、 投資に見合った効果・効用を得られるのか、中途半 図6 端な CMDB や CMS では有事の助けとならない面もあ 概念と用語は整理されているか、まずは ITIL® で り、結果的に三現主義（現場・現物・現実の重視） の例（図 6）に沿って確認してみます。リリースと に収まっているケースが多いのも事実です。 展開の違い、リリース・ユニットとリリース・パッ ケージでの単位の視点の差異などは、混乱しやすい “IT 管理の IT 化”にどんな見返りを期待するのか。 ポイントです。概念が用語とともに定着しているか 実態把握と継続的改善により不良・不要資産の棚卸 （用語が別物としても類似の整理が行なわれている は進むのか、経営資源は効率化されるのか、組織 か）、本番稼働に向けて差異を踏まえた活動ができ として追求する効果やビジョンも問われる事とな ているか等は、サービス品質やプロセスの成熟度を ります。台帳と断片的文書による KKD（勘と経験と 見極めることにもなります。ITIL® における「リリ 度胸）での管理になりがちな中、正確で完全な CMS ースとリリース・パッケージの設計」（4.4.4.2 章） は理想の存在です。その実現に必要なのは俯瞰力で 「リリースと展開の計画」 「ロジスティクスと提供の あり、ヒト・モノ・カネの継続的投入や、運営者の 計画立案」（いずれも 4.4.5.1 章）等は、特に意識 モチベーションを考慮する意味からも、SACM で目 して再点検すべきプロセスです。 標とする成果・効果や、サービス戦略としての意義 体系立った呼称に基づき整理・活動が進んでいる の明確化が、前提になると考えます。 かは、変更の規模・影響および組織的な成熟度とも、 Ⅳ -4 リリース管理と展開管理 表裏一体な面があります。例えば相応の規模におい ～本番稼働の要（かなめ） て、リリースと展開のいずれも成功裡に進めようと 当分野は、「リリースの構築、テスト、展開を計 すれば、スキルセットの異なる人材を検討チームに 画立案、スケジューリングおよびコントロールす 交え、内容や場面を立て分け、それぞれの計画を策 ること」や、「既存サービスの完全性を保護しなが 定していくことになります。 ら、事業が要求する新しい機能性を提供すること」 を責務としています。しかし概念を整理する用語自 リリース・パッケージの設計には、さまざまな利 身の、理解や活用が十分定着していない事に加え、 害関係者の関与が必要となるケースがあります。規 単位のくくり出しや紐づけ管理がもつ本来的な煩 模によっては、開発・運用の IT 関係者やユーザー 雑さもあり、規模によっては結果的に、個別判断が 部門はもとより、対外的な関係者なども含め、最も 多く汎用化の難しい領域となる場合もあります。 適切な方法を検討・決定していく必要が生じます。 29 多くの人々が関わり、変更の規模が大きく、失敗が ますが、適切なスキル移管や育成が伴なってなけれ 許されない本番稼働を“バベルの塔”にしないため ば、技術面でも危うい状況を抱えてしまいます。 には、共有すべき概念や押さえるべき要点を適切な 言葉で統一し、それを踏まえて十分な事前検討や調 作業量やコストの面から、移行専任のスタッフを 整を行なうことが必要です。 常設しない場合は、チーム編成にも一工夫が必要で す。移行チームは通常、①変更・構成およびリリー 昨今ではリリースや展開は、継続的インテグレー スのチーム ②評価およびテストのチーム、の大き ションや継続的デリバリーなどの概念とともに、新 く 2 つで構成することが多いですが、専任者を置か 規ソリューションが群雄割拠する成長分野ともな ず一時的な体制で間に合わせる場合、開発や運用の っています。自動化ツールやクラウドの活用など、 現場から、適任者・有識者を確保していく事になり ツールや展開先の導入や見直しで、効率化・自動化 ます。多忙な現場の協力をいかにして得るか、移行・ が図れるのであれば、それ自体は良い事であり、検 移管に関する役割や責任範囲をどう捉えてもらう 討の価値があります。しかし、ある意味では道具の かも、結果的に成功を左右する鍵となります。幸い、 問題であり、人間に代わって移行計画や全体最適の 妥当性確認と評価のプロセスは、必要性を感じて 方針策定などを代替するものにはなり得ません。最 もらいやすく、IT の各部門ともユーザー部門とも 終的にユーザーが期待するサービスは、俯瞰力や計 親和性の高い分野です。これを入口とし、前述の 4 画力や遂行力など、人の力に依るところが大きく、 分野も含めた、Positive な Service Transition チ 困難さとそのマネジメントにこそ、ビジネスや価値 ームを構築したいものです。やがて訪れる本番稼働 の源泉があるのです。 では、開発（Dev）と運用（Ops）を跨る“のりしろ” の度合いが、業務成果でもチーム力でも問われる場 Ⅳ -5 サービスの妥当性確認およびテスト 面を迎えます。 ～開発と運用の協業をリード 成果物やサービスの品質を重視する日本の IT 業 Ⅴ さらなる価値向上をめざして 界では、当分野は IT の黎明期より重視され、相応 の整理や運営が進められてきました。サービス品 移 行・ 移 管 と い う「 の り し ろ 領 域 」 の 課 題 を 質方針の策定、リスクアセスメント、Ｖモデルでの 踏 ま え、ITIL® Service Transition を 活 用 し て 品質向上、テスト戦略、テスト環境の整備、等々、 の Proactive な 活 動 に よ り、 開 発 と 運 用 の 協 業 ITIL® の述べるプロセスや機能も、概ね身近である （DevOps）やサービスの価値向上を促進する具体案、 程度は確立された状況にあります。テストのアプ それらを活かしたチーム構築・人材育成、について ローチ（p.158）やテストの種類（p.161）なども、 述べてきました。以下ではさらに価値あるサービス 理論と実践の両面から、それなりには議論されてき を進める上で、Service Transition にどのような ました。 課題があるか、を整理します（図 7）。 今日的な課題はむしろ、変更に伴なう障害の 最小化や、昨今の諸事情を踏まえた開発と運用 の効果的な協業などにあると捉えます。既存 資産の蓄積や有識者の世代交代など、量・質で のマイナス要素の存在を前提に、維持管理に必 要なスキルを定義し、改修・保守時の影響度評 価やテスト範囲の確定等が適切に進められるよ う、継承の場を継続的に確保します。例えば、 変更によるデグレードを防ぐ有効手段である回 帰テスト等も、業務スキルの伝承やシステムへ の理解が不十分であれば、計画も実施も難しい 状況に陥ります。回帰テストの難しさは、直接 さらなる課題 1. “共通の場”の継続とガバナンスレベル向上 ・開発と運用の協業・・・共通の課題認識や討議のできる場を設定 例）・共通の会議体やPMO ・共通の目標（ライフサイクルでの評価指標設定やPDCA） ・各種の標準（標準WBS、テスト実施状況、品質／リスク評価 ・“共通の場”のさらなる活用、継続的改善や“価値の補強”の推進 等） 2. 人材育成と組織の工夫 ・成長の機会を創る工夫・・・Stretch Assignment、気づき、メンタリング 等 ・ ① トランスフォーメーション・マネジメント ② チェンジ・マネジメント 3. サービスの棚卸とマッピング ① 棚卸とマッピング ・会社のシステム資産の棚卸と ビジネスプロセスとのマッピング ② 資産評価の実施 ・現在のシステムのSWOT分析 ・賞味期限の設定 ・活動効果の評価 …など http://www.openscg.com/devops-delivered/ 図7 的には必要コストの圧倒的な高さに原因があり 30 Ⅴ -1 “共通の場”の継続とガバナンスレベル向上 結局は個々人のコンピテンシーを、他者の力で高 移行・移管での活動をスムースに進める上では、 めることができるかという問題に突きあたります。 コミュニケーションの戦略と計画も重要となりま スキルや知識を授けることは可能でも、価値観や性 す。事業目標達成、後援者の確保、抵抗の障壁除去、 格・動機など、個々人に深く基づく部分に働きか パートナーシップの確立などは、本番稼働に向けユ けることは、容易ではありません。高業績につなが ーザー部門との間で十分考慮し推進しておくべき る行動特性をいかにして引き出すことができるか、 活動です。 が課題となります。 また、開発と運用が相互に課題認識や討議を進め “困難に直面し、それを乗り切った時に、人は成 られる、共通の場の構築も重要です。移行・移管で 長する”という事象は、学説でも裏付けられていま 培った協業の場も、より積極的で本質的な価値補強 す（“キャリア・トランジション・サイクル・モデル” ： に役立てるべく、そのガバナンスレベル高めつつ継 Nigel Nicholson [6]）。これを活用し、困難なジョ 続していきたいものです。脱サイロ・脱縦割りでの ブアサイン（いわゆる Stretch Assignment）、周囲 コミュニケーションの中から、課題解決を図ること からのメンタリングやコーチングなど、克服や気づ はもちろん、共通の目標や取り組みを見える化し、 きの機会を増やすことで、成長を促す方法がありま IT サービスの全体最適や価値補強につなげていく す。自身がメンターの立場であれば、どういった機 ことできれば何よりです。 会やアドバイスが適切か、自分自身の“乗り越えた 経験”を振り返ってみることも、自身やメンティー “開発 1 年、運用 10 年”、投資である開発局面が にとって参考になります。こういった機会を、日常 完了し、移行・移管を経て本番稼働を迎え、真価が 業務のアサインや管理職研修などの場で、組織的か 問われる長期の運用局面に突入します。“サービス つ継続的に作り込むことができれば、そのチームや の価値は運用で決まる”のであり、運用段階での状 部門はより良く変化し成長できるように思います。 況把握と継続的改善により“価値の補強”を図るこ また“価値の補強”を進める点では、変革のマネジ とは、お客様の満足を獲得し IT サービスを継続し メントの視点に立ち、いわゆる“トランスフォーメ ていく上でも必須の事象と考えます（図 8）。 ーション”や“チェンジマネジメント”を試みる事 も考えられます。組織のおかれた状況にもよります ライフサイクルでシステムを見る重要性 が、これらを進めようとする場合、従事する関係者 運用して初めて、サービスの価値が具現化 – ITの役割が戦略性を増すにつれ、全社視点での評価、実証性が期待される の目標や意識改革、人材育成などが必要となってき • ライフサイクルで評価することが大事 • ライフサイクルで考えるにはフレームワークの活用が有効 ます。 価値の補強・・・全体を俯瞰しての最適化と継続的改善 システムライフサイクルコストの重要性 Ⅴ -3 サービスの棚卸とマッピング 費 用 開 発 導 入 費 用 実務レベルでの今後の課題の 1 つとして、サービ 開発・導入だけでなく 保守・運用を含め 総費用を考慮した システム構築の推進が重要 運用費用（利用期間） アプリケーション保守費用 SW使用料・保守費用 HW保守費用 顧客にとっての価値 スの棚卸とマッピングがあります。SACM 領域では、 継続的な情報蓄積や CMDB ／サービスカタログ等で の資産把握が急務です。既存資産を棚卸し、いわゆ 特別保守 廃棄の検討 （延命課題） る“死産”の撲滅により、経営資源の有効活用を図 システムライフサイクル っていくことが期待される段階にあります。資産評 図8 価を進め、効果を整理し、状況によってはサービス Ⅴ -2 人材育成と組織の工夫 の終了等も、進めていくことになるでしょう。 “価値の補強”には、その必要性を理解し実践し ようとする、Proactive な人材が必要です。しかし、 Ⅵ おわりに 同じ環境にいても、課題に深く気づき動く人と、通 り過ぎてしまう人がいるように、役割意識や当事者 初めて ITIL® V3 のフレームワークに触れた時、 意識は根の深い課題です。当事者意識やチャレンジ Service Transition は正直なところ、少々印象が 精神に乏しければ具体的な変化には至らず、“価値 薄い存在でした。業務イメージや目標感の明確な の補強”を求めるまでもありません。 Strategy/Design/Operation と、 そ の 課 題 観 か ら 31 存 在 感 を 放 つ Continual Service Improvement の 中にあって、いささか中途半端にも感じられたも のです。しかし長らく向きあってきた IT サービ ス が、CAMS な ど SoE の 台 頭 を 前 に SoR と 一 括 さ れ、DevOps とともにリリースのスピードや頻度が 話題となるに至り、今後は Transition がその存在 価値を再評価され、輝きを増していくように思い ます。我々の牙城である IT サービスマネジメント を再認識し、継続的な価値を提供し続ける上でも、 Positive な Service Transition が求められること になると考えます。この小文が IT サービスマネジ メントに携わる全ての方々にとって、ささやかなヒ ントになりましたら幸いです。 参考文献 [1]「Systems of Engagement and The Future of Enterprise IT – A Sea Change in Enterprise IT」Geoffrey Moore, AIIM White Paper, 2011 [2]「サービスマネジメント視点の DevOps ～開発 日本アイ・ビー・エム株式会社 武上 弥尋 と運用をめぐる現場の課題と今後～」 IBM Certified Executive Project Manager 武上弥尋 , itSMF Japan Newsletter, 2013/7 PMP [3]「10+ Deploys Per Day : Dev and Ops 日本 IBM に入社後、製造業担当 SE としてシステム構築、 Cooperation at Flickr」 サービス事業にて SI 開発に従事。2000 年以降、公共 John Allspaw(Etsy.com) & Paul Hammond(Etsy. 公益、官公庁、医療、運輸などの管理職ないし PM として、 com), 2009/6/23 提案活動やプロジェクト運営を実施。2004 年から金融 http://velocityconf.com/velocity2009/public/ 業 SO の統括 PM として活動、2009 年には日本 IBM の PM schedule/detail/7641 Profession Leader として全社の PM 育成を担当。2011 [4]「Maximize the Synergies between ITIL® and 年より製造業 SO の統括プログラムマネジャーとして、 DevOps」 全国各拠点で複数並走するプロジェクトの横断的マネ ジメントや、PMO 統括、品質保証、人材育成などを推進。 Anthony Orr (BMC software), 2012/12 http://documents.bmc.com/products/ documents/52/40/435240/435240.pdf [5]「DevOps: 王 は 死 す。 新 王 に 栄 え あ れ 」Kevin Holland, it SMF Japan Newsletter 2013 .4. [6]「A Theory of Work Role Transitions」Nigel Nicholson, Administrative Science Quartely Vol.29, No.2 (Jun, 1984) p172-191 「キャリアの学説と学説のキャリア」金井壽宏 , 日 本労働研究雑誌 No.603, 2010.10 32 会員寄稿 脱 ・ IT 後進国への特効薬 ： これを飲まずして何を飲む ～システム運用部門からビジネスパートナへの誘い～ I はじめに 達するまでに採るべき作法を描いたものがなく、IT 部門やサービスプロバイダ、CIO と言われている方々 国内 IT 産業、ならびに IT 部門は、まさに「イノ は五里霧中状態でコトを進めてきたのではないでし ベーションのジレンマ」の真っ只中にいる。IT 先 ょうか。 進国として世界を牽引してきたというのは幻想にな りつつあり、世界に遅れをとり、IT 後進国と認識 そんな中、世の雑誌、カンファレンス、セミナのタ されつつあるようです。「OA 化 ( 注 1） が進んだのは イトルを賑わせているのは、また「変革」です。「ま 確 か で あ る が、 そ れ が IT 化 ( 注 2） と 呼 べ る か？」 たか！」とうんざりしている読者は多いのではない という意見も出ていきています。IT という言葉が でしょうか。今まさに、クラウドの出現、グローバ 生まれ、世間に広まったのは 1995 年と言われてい ル進出の支援拡大により、IT 部門もビジネス部門も、 ます。あれから 20 年経ちました。しかし、この分 それらを取り巻くコンサルタントやベンダも「変革」 野でも「失われた 20 年」の雰囲気が滲み出ている に追われています。 ように思われます。 みなさんは、また同じ道を歩みますか？ みなさん なぜ、このような状況に陥ってしまったのでしょう がまた同じ道を歩まないようにするために、本稿で か。今後進むべき姿やビッグピクチャを描くことを は、その特効薬となり得ると筆者が考えるフレーム 推奨する書籍は多く存在します [1][2][3][4]。また、 ワークを紹介します。その後、「システム運用部門か 特定分野ごとに、現状の問題・課題を示し、それら らビジネスパートナへの変革」にフォーカスし、そ 問題・課題解決が達成された理想の姿を描くことで、 の領域において、組織能力を醸成するために役立つ 読者に気づきを与える書籍やフレームワーク ( 注 3） フレームワークと ITSM/ITIL® の融合により脱・IT 後 が多く存在します。更に、独自にフレームワーク（理 進国を目指して進むべき方向に言及していきます。 想形）を策定し、組織一丸となってその導入に邁進 注 1:OA 化：作業の効率化や生産性向上を目指した各種取 り組み。 注 2:IT 化：経営革新を支え、活用することで新たな価値 を生み出すこと。 注 3: フレームワーク：汎用的な機能や業務を定めた枠組み。 しているケースもあります。うまくいっていない場 合は、堂々巡りを繰り返しているように思われます。 国内に ITSM という考え方や ITIL® を広げ始めたの は今から 10 年ほど前、it SMF Japan が設立された頃 です。さて、当時から今まで、理想形として描かれ II 今までのフレームワークの課題 たもの、それらを実現するために推奨されたプロセ スや考え方、ツールなどはどこまで組織変革を支援 今まで、IT 部門や IT サービスプロバイダの関心は してきたでしょうか。それら変革が当初の目標通り 「プログラム開発」や「システム管理」という言葉が に進んでいることをどれだけの人が明言できるでし 代表するように、情報システムの開発・運用が中心 ょうか。理想像（必要性、考え方、描き方など）自 でした。現在は IT 戦略・企画立案，プログラム＆プ 体は浸透したとしても，現在の姿から理想の姿に到 ロジェクトマネジメント，及びサービスマネジメン 33 ト等が中心になってきています。今後 IT のビジネ ていますがソフトウェア開発の領域に限ったもので スへの貢献を最大化していくためには，ビジネス部 あり、かつプロセス改善が中心です。組織変革を目 門の運営の手法を IT 部門運営においても取り入れ 的としたものとしては不足感があります。ITIL® は ていく必要があると考えられています [5]。技術中 心の考え方や作法に固着していては、周りの環境の IT サービスマネジメント、COBIT® は IT コントロー 変化に対応できず、競争に負けてしまう。事業運営 の域を出ていないのです。個々の目的に合った使い を進めるために必須となる技術思考オンリーから抜 方を進めれば良いのですが、それだけでは組織変革 け出した儲けを意識した知識やスキルを身に付けて のゴールにはたどり着けません。 ルといったように、全てがスポットソリューション いくという大きな挑戦が求められています。ここで、 今までの業務を支えてきたフレームワークの問題、 筆者は，先の問題、課題を解決する特効薬とし 課題について触れておきます。 て、IVI(Innovation Value Institute) が策定し普 及 を 進 め て い る IT-CMF(IT Capability Maturity 1 リソースベースの限界 Framework)[6] の活用が有効で、ITIL® と強力な効 従前より、組織運営はリソース中心に議論されて 果を発揮するものと期待しています。IT-CMF は、従 きました。しかし、それだけでは、前もって定めた 来から普及されている静的なフレームワークの対極 目標の達成が難しいままであり、良くなったとして にあり、「急激に変化する環境に対処するために組 も一時的なものとなることが多かったように思われ 織内外の資源を統合、構築、そして再構成する能力」 ます。リソースを活用し収益に繋げる組織能力が備 （ダイナミック・ケイパビリティ）を備えています わり、それらリソースを使いこなし成果を生み出す （[6] の表 1 を参照）。ここ数年、経営戦略論の分野 エンジンが未整備だったからではないでしょうか。 で最も活発に研究されている領域の一つです。 2 静的な組織能力の限界 以降、IT-CMF についていくつかの特徴を紹介して リソースベースの組織論の限界が認識された頃、 いきます。 組織能力を表現するプロセス指向が台頭してきまし た。ITIL® もその一つです。ITSM を効果的に進める 1 IT-CMF とは ためのプラクティスが集められ、今の形となってい IT-CMF とは、IT 組織の組織能力（ケイパビリティ） ます。しかし、この取り組みも限界に来ていると囁 を向上させる、経営（マネジメント）のベストプラ かれ始めています。数年スパンで、数名の Thought クティスととともに、IT 組織のパフォーマンスにつ Leader により策定され浸透していくのですが、時代 いて、包括的な評価の基盤を提供するフレームワー の変革や事業スピードから静的なものと捉えられ、 クです。IT 組織全体で、継続的にパフォーマスの向 かつ特定領域での業務改善を指向するフレームワー 上ができる、CIO と IT 管理職向けの管理システムと クであり、今、IT 部門やサービスプロバイダが求め なりえるものです。このフレームワークを活用する られている変革にはフィットさせにくいと捉えられ ことで、組織は、より高いビジネス価値と革新（イ てきています。 ノベーション）の継続的な提供を目指し、それらを 実現できるようにするものです。 III IT リソースをビジネス価値に変える能力 IT-CMF は、アイルランド国立大学メイヌース校と 「IT リソースをビジネス価値に変える能力」は誰が Intel 社が共同で設立した非営利のテクノロジー研 持つべきでしょうか？ CIO だけが持つべきものでは 究・教育機関である IVI が策定しました。組織のパ ないはずです。IT 部門やサービスプロバイダ一丸と フォーマンスを向上させる、実証されたベストプラ なって持つべきものと考えるべきです。 クティスについて研究、開発、普及などに取り組ん でいます。原型となるモデルは、インテル社の IT 部 では、今まで、こういったことを目的に作られた 門の組織運営能力を管理するために開発された標準 フレームワークは無かったのでしょうか？組織能力 です。IT の価値をビジネス部門や投資家に定量的 / 向上と言えば、CMMI® などに代表されるマチュリテ 定性的に可視化する術がなく、IT 部門の変革を必要 ィモデルが思い浮かぶと思います。能力向上を謳っ としたことからこのフレームワークが生まれました。 34 このフレームワークは、組織変革の能力をアセス クだけでした。今も増え続け、バージョンアップが メントすることに活用できます。組織能力全体をざ 繰り返されています。ITIL® もそのひとつです。 っと評価する「エグゼクティブ・アセスメント」、個々 の組織能力別に詳細に評価する「クリティカル・ケ IT サービスマネジメントは、ビジネスへの価値提 イパビリティ・アセスメント」、変革テーマに該当 供という観点で捉えれば一つのコンポーネントにな する組織能力の集合に関して評価をする「クラスタ・ ります。ビジネスへの価値提供のためにはその他に アセスメント」、他業種 / 同業種他社とのベンチマ イノベーションマネジメント、ビジネス思考、エン ークを可能とする「業界ベンチマーク・アセスメン タープライズ・ワイドの戦略思考など、多岐に渡る ト」を実施できます。IVI は、IT-CMF を適用した結 ケイパビリティも必要になったのです。つまり、CIO 果を蓄積し、その後のベンチマークデータとして活 や IT 部門の人々は、ある問題解決のテーマに合った 用する仕組みを持ちます。この点も、特筆すべきポ 形で組織能力を再利用 / 再構成し、無駄のない価値 イントであると考えます。 提供ができるパターン化されたもの（IT とビジネス の融合領域におけるハイレベルなデザインパターン 2 なぜ IT-CMF が生まれたか と表現しようと思います）が必要になったのです。 インテル社の IT 部門に所属する Martin Curley ら の 論 文 [7] に よ る と、CIO(Chief Information Curley らは、IT-CMF を策定する際に、158 もの既 Officer) に対して、「IT コストの削減」と「ビジネ 存のフレームワークを調べ上げ、そこから静的なフ ス価値の最大化支援」を同時に達成せよと言われて レームワークの問題点は、1）包括性の欠如、2）共 いるものの、為すすべもなく、IT の経営判断をせよ 通言語の欠如、3）ビジネス価値指向の欠如、4）静 と迫られていたことが事の発端であると解釈できま 的な性格をもつ、5）フレームワーク策定のエコシ す。CIO の役割が明確に定義されたのは、1996 年、 ステム機能不全、の 5 つであると結論づけました。 米国クリンガー・コーエン法です。その後、大学で ITIL® もその一つです。ITIL® が悪い / 劣るという は教育カリキュラムが策定され、人材育成が始まり ことではなく、今の世の中の環境の流れにあわなく ました。そこに欠けていたのは、IT の経営を支援す なってしまったということだと思います。 る、しかも IT コストの削減やビジネス価値最大化 という側面を持った問題解決策でした。CIO がやら その際、CIO や IT 部門がカバーすべき範囲をどれ なければいけないことは書かれていましたが、その だけ含んでいるかという視点とビジネス価値指向の ための策がなかったのです。IT-CMF の原型は、2000 内容が含まれているかという視点でスコアリングも 年前半に、当時もインテル社 IT 部門で勤務してい 実施しました。その結果、158 フレーク中 90% はカ た Curley 氏が試行錯誤を重ね、IT コストの削減と バー範囲が限定的でありビジネス価値指向とは言え ビジネス価値のアピールの仕方などを追求し、イン ないもの、2.5% はカバー範囲は広いもののビジネス テル社 IT 部門の運営を変革した際の取り組みなの 価値指向ではないもの、残りの 7.5% はカバー範囲 です。 が限定的であるがビジネス価値指向であるものとい うことが判明しました。つまり、カバー範囲が広く、 CIO に 対 す る 要 求 は 益 々 増 大 し、CIO は Chief ビジネス価値指向を謳っているものは皆無というこ Innovation Officer と置き換えられるようになった とです。 のが 2007 年頃と言われています。その頃には、CIO が解決すべき領域は多方面にわたり、個々の領域ご 現在、みなさんが置かれている環境の変化にあっ とに意思決定や変革をリードしなければいけなく て、上記の 5 点の問題・課題を持つフレームワーク なりました。個々の領域（例えば、プログラム / プ を使い続けて良いのでしょうか？人材不足など対応 ロジェクト管理、ソフトウェア開発、サービス管理 できない理由はあるにしても、早急に対処すべき変 など）には、それぞれの目的に対応するプラクティ 革問題を解決する手助けに適さないフレームワーク ス集や標準フレームワークなどが誕生していました は選ぶべきではないと思います。IT 部門や CIO、ビ が、どれも Innovation には適していなかったのです。 ジネス部門を取り巻く環境の変化のスピードが益々 そこにあったのは、特定領域に閉じた世界でのプロ 増す中で、備えるべきケイパビリティも変えていく セス間の関係により表現された静的なフレームワー 必要性が出てきているのは周知の事実です。可用性 35 や SLA が中心となっていたのは昔の話で、安定稼働 ができるような柔軟性をもつフレームワーク（ダイ が当たり前になってからは、IT 部門やサービスプロ ナミック・ケイパビリティの考え方がベース）であ バイダは別の軸で評価されるようになってきていま るからこそ期待できる拡張性も持っています。産官 す。その解が IT-CMF の導入なのです。 学連携により、オープンイノベーション型でフレー ムワークを構築しているため、強力なエコシステム ITIL® に置き換わるというものではなく、ITIL® が機能していとも言え、こちらも期待できます。静 と IT-CMF を融合させ、IT とビジネスの融合領域に 的なフレームワークでは、長い年月をかけ、数年ご おける変革を進めるものとご理解ください。もし、 とにバージョンアップされるのを待つしかないです ITIL® の導入と共にビジネス価値を意識した組織変 が、そういった現象は起こりえないのです。クリス 革を進める場合には、IT-CMF との強連携による業務 テンセンが言及している「イノベーションのジレン の刷新を目指すことになるでしょう。そのためのア マ」が生じないようにするために、IT-CMF はデザイ セスメント、変革のために実施すべきこと、その変 ンされているのです。 革が達成できているかを測る指標が IT-CMF に織り 込まれているのです。 IT-CMF は、最新の組織経営のテーマにより生み出 された考え方をベースに設計されています。Living 3 IT-CMF 導入の実績 （生きた / 現実問題とその解決策を映し出している） IT-CMF は、2010 年の夏にファーストバージョン フレームワークであり、かつ常に変化をし続ける知 がリリースされました。以来、現在まで、世界各国 識体系でもあると言えるのです。 の主要な企業や組織において活用されています。最 初の 18 ヶ月で 350 ほどの組織を対象にしたアセス Ⅳ おわりに メントが実施されたことからも、このフレームワー クに寄せる期待の大きさが分かります（この数字は 本稿を読んでいただいたことで、次の 10 年、20 驚異的なレベルと思います）。また、オープンイノ 年を生き抜くために目指すべき方向性をご理解いた ベーション型によるフレームワーク策定を進めてお だけたかと思います。脱・IT 後進国を目指すために、 り、80 を超える組織で構成されるコミュニティーが ITIL® の導入 / 普及と共に IT-CMF とのコラボが必須 形成され、当フレームワークの更新をし続けていま になってきているのは間違いありません。IT-CMF に す。産業界に閉じることなく、産官学で進められて は、it SMF だけではなく、AXELOS など関係組織にお いる点も評価に値します。 けるフレームワーク策定に対しても多くの気づきを 与えるものであると期待しています。今後、it SMF 国内においても、産においては NTT データ、富士 Japan は、IVI や関連組織とともに、IT とビジネス 通、学においては東工大、早稲田大学、国際 CIO 学会、 の融合領域におけるフレームワークの策定とその普 経営情報学会などが関わっており、今の拡大中です。 及をリードしていくべきであると考えます。 国内外の他団体のカンファレンス、itSMF 地域別カ ンファレンスでの講演実績があり、その必要性はヨ IT-CMF は、新たに挑戦すべき特定テーマが生まれ ーロッパや北米を中心に広がり、国内でも広がりつ ると、それに対するケイパビリティのクラスタを定 つあります。 義し、問題解決に寄与するプラクティスを考え出す ことを継続的に進めています。その例が「クラウド 4 IT-CMF の将来性 活用」です。IT-CMF クラウド・ライフサイクルがそ 文献 [6] の表１にあるように、現在、IT-CMF が れです。コアとなるフレームワーク以外にも、今後、 もつマクロ・ケイパビリティ（最上位のケイパビリ 益々その効果が発揮される場面が増えてくると期待 ティの分類）は 4 つ、クリティカル・ケイパビリテ しています。 ィは 33 あります。本フレームワークは、IT やビジ ネスの融合領域を継続的にウォッチし続け、変革に 欧米とは異なる日本独自に抱え込んでいる問題や課 必要な問題や課題を捉え、その変革に必要な道を示 題、変革ニーズもあると思っています。今後、国内主 し続けることが期待できます。クラスタ、ならびに 導によるコミュニティー形成を促進し、 「IT 後進国」 クリティカル・ケイパビリティが成長し続けること の汚名を晴らせる日が来ることを願っています。 36 参考文献 [1] J.A.Zachman, A Framework for Information Systems Architecture, IBM SYSTEMS JOURNAL, 26(3), (1987)。 [2] O.Renn and K. Walker, Global Risk Governance: Concept and practice Using the IRGC Framework, Springer Science and Business Media, 400, (2007)。 [3] Richard Norman, Service Management: Strategy and Leadership in Service Business, 256, (2001)。 [4] Tucker, R.B.，Driving Growth through Innovation: How Leading Firms are Transforming their Future, Second Edition, Berrett-Koehler Publishers, Inc.，380（2008） [5] 鎌田春雄，近野章二，神野俊昭，IT 部門の組織 能力向上を支援する運営最適化ソリューション，日 株式会社日立製作所 立評論，89(09)，32-35（2007）。 横浜研究所 主任研究員 近野 章二 [6] IVI, About us, https://ivi.nuim.ie/about- 1996 年日立製作所入社。入社当初はソフトウェア開発 us/ivi-japan-0, (2012)。 管理における生産性向上の研究に従事。2001 年より長 年、IT ガバナンス分野における IT アセスメントの研 [7] Martin Curley, Jim Kenneally, and Ralf 究を担当。最近は、グローバル市場向け IT サービス Dreischmeier, Creating a New IT Management 提供に関する Gr 内業務標準の策定、および組織機能 Framework Using Design Science – A Rationale 変革へのサービス思考適用の研究に従事。 for Action and for Using Design Science -, Practical Aspects of Design Science, EDSS 2011, pp.96-115, (2011). ITIL® は、AXELOS Limited の登録商標です。 COBIT は、Information Systems Audit and Control Association (ISACA) および IT Governance Institute (ITGI) の登録商標です。 CMMI は、米国に於けるCarnegie Mellon University の登録商標です。 37 会員寄稿 運用自動化によるサービス改革の促進 Ⅰ はじめに 「顧客は 1/4 インチのドリルが欲しいわけではな い。1/4 インチの穴が欲しいのだ」これはハーバー ド大学教授セオドア・レビット 1968 年の著作「マ ーケティング発想法」にある有名なフレーズである が、マーケティング分野だけでなく、サービスマネ ジメント分野でも本質をとらえたフレーズとなって いる。顧客は「穴」が開けば、その手段はドリルで アウトプットが変化しないことを前提としたサービ あろうがなかろうが構わない。サービスは顧客に価 ス内部の固定的な運用活動にフォーカスされてい 値を提供する手段であり、価値が得られるのであれ た。今日の IT の変革によって、インプットとアウ ば顧客はどのような手段であっても構わないと考え トプットが様々に変化し、特に顧客の価値 = アウト る。昨今 IT ではクラウドやモバイル、モノのイン プットの特性が顕著に変化している。固定的な運用 ターネットなど、破壊的な変革をもたらすサービス 活動にフォーカスして自動化しても、アウトプット 基盤が登場し、これらの基盤から今までにないスピ が変化することでサービス内部の IT による処理も ードでサービスが市場投入される。これらが従来の 変化し、その運用活動も変化するため、運用自動化 サービスよりも安価で同じ価値を提供できるのであ の効果が長続きしない。 れば、顧客は喜んで新しいサービスを使うであろう。 この大きな変革に対し、サービス提供を支える IT 本章では、サービスのインプットとアウトプッ 運用の現場では、各種のプロセスを自動化しなけれ トの特性と変化に応じたサービスの変化の特徴を ば人的リソースが枯渇し、迅速な市場投入や高頻度 分類し、変化に対応するための運用自動化要件を のサービス変更は実現できなくなるであ 分析する。 ろう。本稿は IT のめまぐるしい変革の中、 運用自動化に焦点を当て、自動化の要件 分析と、変革による自動化の実装例、そ して自動化を取り巻くテクノロジーの管 インプット 商品購入 作業依頼 飲食注文 表1. サービス 物品販売 労働提供 飲食提供 インプットとアウトプット アウトプット アウトプットの例 商品 キャベツ、テレビ 成果 子守、引っ越し 商品と接客 レストランの食事と接客 理と利用方針について説明する。 1 サービスのインプットとアウトプット Ⅱ アウトプットの特性変化と運用自動化要件の分析 サービスのインプットとは、顧客にとってはサー ビスに対する要求であり、サービスにとっては活動 運用の自動化要件と対象を分析するために、サー を開始する契機である。サービスのアウトプットは ビスを模式化すると、図 1 のように捉えることがで サービスによる成果・結果であり、顧客が得る価値 きる。自動化の対象はサービスの内部に存在するこ である。我々が日頃利用しているサービスをインプ とは自明であり、IT によるサービス提供に必要な各 ットとアウトプットに分類すると表１のように例示 種の運用活動が自動化の対象となる。 できる。この例から、アウトプットは物と物以外、 つまり「有形」と「無形」の２種類に大別されるこ 従来の運用自動化のアプローチは、インプットと とが分かる。テレビや食事は有形であり、子守や接 38 客は無形のアウトプットである。 4) 無形から有形 3D プリンタは、複製の難しいデザイン意匠や熟練 有形と無形の観点から、アウトプットが変化する した職人の技、あるいは設計データなど、モノの「形 形態は４つのエリアに分類され、アウトプットの変 づくり」において無形であったアウトプットを有形 化に応じてサービスも変化する。 化する。この技術は、今まで高価で時間がかかるた めに敬遠されていた試作品を実際に手に取って実感 1) 有形から有形 できるようにしたり、今までできなかったような造 ウォークマン、コンピュータ、カメラ、プリンタ 形や大量複製ができるようにしたりする。現在は建 などの小型軽量化された家電商品、グローバルな施 築、医療、教育などに必要となるモノの製造面で活 策で安価な生産コストを利用した低価格戦略を展開 用されているが、比較的安価な 3D プリンタ一が一 する衣料品事業や、様々な機能を集積して利便性を 般家庭にも普及しつつあり、3D プリント用データの 高め、個人が手放すことができなくなるスマートフ 売買など、新しいサービスの登場も予見される。 ォンなど、有形のアウトプットで留まることのない 破壊的な変革を続けているエリアでは、新しい商品 このようなサービスの変化にともない、各種のア が次々と登場し、その生産、販売、保守などに関す ウトプット提供に必要なサービスが従来よりも短期 るサービスが新規に登場したり、刻々と変化したり 間で新規に登場し、頻繁に変更されたりする。その する。 ため、それを支える IT サービスも頻繁に新設、変 更される。これらは、従来の運用方法では対応が難 2) 無形から無形（有人から無人） しく、そこに運用自動化の要件が生じる。アウトプ インターネット接続サービス、ケーブル TV、スマ ットの変化から運用自動化の要件を予測、把握し、 ートフォンのアプリなど、IT サービスに依存した無 プロアクティブに対応することで、ビジネスが求め 形のアウトプットが進化しているエリアでは、それ る市場提供のスピードを充足し、競合他社に先駆け らの IT サービスの運用も各種の自動化により進化 ることができるようになる。 を遂げている。電力自由化などは、今後大きなサー ビスの変革が予想されるエリアである。 2 サービスマネジメントの 4 つの P 図 1 で示したサービスの組成で、サービスの内部 接客や教育、医療も無形のアウトプットであり、 に 4 つの要素を記載した。これらはサービスマネジ 給仕や、芸能 / エンターテイメント、外科的治療など、 メントの 4 つの P と呼ばれ、運用自動化を促進する それ自体で価値を生み出すアウトプットに関する運 ために不可欠な要素であると共に、これらの要素自 用自動化の要件は薄い。しかしながら、インターネ 体が自動化の対象にもなる。一般に 4 つの P は次の ットによる物品販売、大学講義の配信、遠隔医療の ような意味で用いられる。 ように、有人・対面でしかできなかったことが無人 ●人材：「People」の訳で、スタッフや組織体制を でできるようになるところには、顕著なサービスの 表す 変化が起きている。 ●プロセス：「Process」の訳で、広義には目標達成 のための一連の活動を表し、狭義には、運用業務 3) 有形から無形 の各種手順を表す 音楽や映像はかつて、レコードやテープなど、記録 ●ツール：「Product」の訳で、「ツール／製品」と されたメディアをアウトプットとするサービスにより も呼ばれる。サービスマネジメントで利用する各 提供されていた。今や音楽や映像データを PC やスマ 種ツールを表す ートフォン内のディスクやメモリーにダウンロードす ●パートナ：「Partner」の訳で、外部のサービス提 るサービスが全盛となり、顧客は有形の「メディア」 供者を表す を入手する必要がなくなっている。このように有形か 前述の各エリアの要件を、上記の４つの P で考察 ら無形のアウトプットの変化は、デジタル化によるサ すると、アウトプットが有形のエリアは、新商品の ービスの提供モデル自体が大きく変革する中で実現さ 開発から市場投入までの期間を短縮するために適切 れる。こちらは第 3 章で詳細に論じる。 な「人材」を登用し、従来よりも標準化され簡略化 できるようにした「プロセス」を確立し、人手で実 39 施していた作業を「ツール」により自動化し、必要 ムソフトやゲーム機をレンタルしたり、食料品や に応じて部品や人材、支援サービスを「外部のサー 他の商品を販売したりするようになった。（図 3） ビス提供者」から調達することで、新商品の市場投 入の要件を充足することができる。アウトプットが 無形のエリアでは一般に、アウトプットが IT サー ビスから直接提供されるので、各種の処理はソフト ウェアにより実行される。医療や生活インフラなど アウトプットの高可用性が求められるものについて は、特にプロセスとツールの面で運用自動化要件が Step3：メディア軽量小型化による無人化モデル 高く、インターネットショッピング、ゲーム、SNS メディアが DVD やブルーレイなど軽量小型化した アプリなどは、コンテンツの改訂頻度が高いため、 ことで、自動販売機型のレンタルマシンや、宅配 変更 / リリース管理に関するプロセスの運用自動化 を利用した無人でのレンタルができるようになっ 要件が高い。また、有形、無形のどちらのエリアに た。（図 4） おいても、例えばパブリッククラウドにより提供さ れる各種の支援サービスを利用する機会が増え、パ ートナによる自動化という手段も運用自動化要件に 対する解決策となり得る。 Ⅲ サービス提供モデルの変革と運用自動化の実装 2 章では、運用自動化要件がアウトプットの変化 Step4：インターネット配信による無形化モデル により生じ、要件を 4 つの P により考察するアプロ テレビやパソコンと連携したコンテンツ配信型の ーチを述べた。この章では、アウトプットの変化に サービスで、アウトプットは有形のメディアでは よりサービス提供モデルが変革している具 なく無形の配信データに変化している。（図 5） 体的な例から、変革の各段階で生じる運用 自動化要件と実装例について説明する。 1 レンタルビデオの変革 映画のビデオテープをレンタルするとこ ろから始まったレンタルビデオのサービス 提供モデルは、この 20 年余りで何度も大 きな変革を遂げている。主な変革のポイントを以下 Step5：スマートフォン / タブレットによるポータ に挙げる。 ブルモデル スマートフォン / タブレットへのコンテンツ配信型 Step1：初期モデル のサービスで、利用者は場所を選ばず鑑賞でき、コ 顧客はビデオ店を訪れ、ビデオテープを借り、家 ンテンツを持ち歩きできるポータブルモデルへと変 に持ち帰って鑑賞し、期限までに返却した。（図 2） 革を遂げている。（図 6） Step2：サービス拡充 モデル レンタルビデオ店 は、 新 作 の 借 り 手 の 数 を 予 想 し、 在 庫を多く持つことで機会ロスを予防すると同時に、 レンタル保証（別のアイテムの無料レンタル）で サービスを拡充した。さらにビデオ以外に、ゲー 40 2 レンタルビデオの変革と運用自動化実装例 りする際の「ワークフロー」をシステム化する技術 前述の各 Step では、各種のサービス変更が起こり、 と、運用業務の手順書（＝ランブック）の中のスク 変更されたサービスを運用するために自動化の実装 リプトやコマンド実行操作を遠隔から自動的に実行 が行われた。いくつかの例を表 2 に示す。 できるようにする技術である。 表２. レンタルビデオの変革と運用自動化実装例 モデル 特徴 運用自動化の実装例 Step1：初期モデル 台帳ベースのIT無用運用 ・巻戻し自動化（自動巻戻し機による巻戻し不要サービス） Step2：サービス拡充モデル 貸借や在庫管理のシステム化 ・メディア、入出金、督促など各種管理プロセスを自動化 ・対面業務がシステム処理に交代（全自動化） Step3：無人化モデル 対面レンタル不要 ・宅配レンタルモデルでは巨大配送センターで集中管理 ・データセンタ（クラウド上）で主要なシステム運用を自動化 ・CATVやオンライン配信など同様のアウトプットを提供する Step4：無形化モデル ネットワーク経由でデータ配信 別のモデルでも価格競争による徹底した運用効率化（自動 化）の取組みを実施 ・国内外のテレビ番組など短時間のコンテンツも続々と提 Step5：ポータブルモデル アウトプットの可搬性 供され、高頻度なサービス変更に対してリリース管理プロ セスを自動化 RBA は 2005 年 に 登場した技術エリア で、テクノロジーの 発展を取り込んで現 在もその適用範囲を 拡 張 し 続 け て い る。 運用管理の中で、障 表 2 のように、IT システム化、無人化、無形化な 害からいち早く回復するためのインシデント管理に ど、サービス提供モデルの大きな変革のタイミング 最初に適用されることが多いが、昨今の運用自動化 で、生き残りをかけたサービス変更とそれにともな 要件の高まりに応じ、他の管理プロセスへの適用や う運用自動化の取組みが実施されていることが分か プライベートクラウドの運用も一元的に管理できる る。これらモデル変革の特徴とその対応は、今後も ようになっている。インシデント管理プロセスの 他のサービスで同様の変革が起きた時に運用自動化 RBA 適用ビフォーアフターの例を図７に示す。 の方針を教示するものである。 なお RBA を利用して運用管理を高度化するテーマ Ⅳ 運用自動化を取り巻くテクノロジー動向 については、it SMF Japan スポンサー White Paper の 2013 年拙著 「ランブック自動化技術を利用した 運用自動化を支援するテクノロジーと、運用自動 運用管理の高度化アプローチ」で詳細解説している 化に大きな影響を及ぼしつつあるテクノロジーの動 のでご参照いただきたい。 向について述べる。 2 クラウド、DevOps、モバイル、モノのインターネット 1 ランブック自動化 運用自動化に影響を及ぼすことが予想されるテク 運用自動化に直結するテクノロジーにランブック ノロジーとしてクラウド、DevOps、モバイル、モノ 自動化（Run Book Automation： 以降 RBA と略記） のインターネットについて動向を述べる。 がある。RBA は 2 つの技術の組み合わせで実装される。 1) クラウドコンピューティング 各種申請手続きや複数の担当者間でタスクをやりと プライベートクラウド環境を社内インフラ基盤とし 41 て標準化し、「運用極小化」されたサービスを素早 れる動向から分かるように、アプリケーションのイ く投入する形態はすでに各社で活用されている。こ ンフラはクラウドで、稼働先はモバイルデバイスを こでのポイントは標準化設計時に自動化された運用 最初に候補とするアプローチが成功実績を積んでい 機能も盛り込むことであり、これにより画一化され る。モバイルデバイスの運用管理は今のところセキ たレベルで運用できるようになる。 ュリティを含めて MDM という管理エリアで専門的に 実装する方法が典型であり、運用自動化のプラクテ パブリッククラウドは今のところ、クラウド利用 ィスが登場するにはまだ日が浅い状況である。ただ 者による運用自動化の適用は部分的なものに限ら し、モバイルデバイスを運用自動化のために利用す れ、SLA で合意されたレベルの運用がクラウド事業 る視点では、様々な適用エリアがある。技術管理や 者により実施されていることを担保する方法が一般 アプリケーション管理の技術担当者が、社外からイ 的である。 ンシデント対応を行うことができれば、復旧時間の 短縮が期待できる。バインダーで何十キロもある運 ク ラ ウ ド コ ン ピ ュ ー テ ィ ン グ の 動 向 と し て、 用手順書を電子化し、タブレットで表示できるよう OpenStack/Tosca など、公開されたオープン・クラ にすれば、手順の参照や実行を短時間で正確にでき ウド技術が実装レベルまで到達し、一部の機能で複 るようになる。差し当たりモバイルは、そのテクノ 数のクラウド環境を相互に運用できるようになって ロジーを利用した運用自動化の方向性を検討するの きている。オープン・クラウド技術により運用機能 が効果的である。 が標準化されたクラウドインフラや、あらかじめ運 用機能が組み込まれたクラウドインフラが実装され 4) モノのインターネット（Internet of Things：以 るようになれば、パブリック、プライベートの両方 降「IoT」と略記） を統合管理することが可能になる。運用自動化を運 IoT を具現化するセンサー技術の発展はめざまし 用担当者側が苦労して組み込むのではなく、クラウ く、あらゆるモノが IT により管理できるようにな ドインフラの前提として事前に組み込まれる時代も る日も近いと言われている。現在の実装技術では、 遠くはない。 センサーはモバイルデバイスと同様にセンサー専門 の技術を使って管理するので、運用管理のプラクテ 2) DevOps ィスは登場していない。しかし今後、運用管理の面 開発と運用の融合を目指す DevOps のコンセプト で管理すべき対象が爆発的に増えることが予想され は、従来の運用管理を対象としたものではないの るため、動向に注目する必要がある。 で誤解されることも多いが、開発から本番稼働ま での時間を短縮し、本番稼働後も細かく改善を施 このトレンドも運用自動化のために利用する視点 す開発と運用の手法は、クラウドベースの Web ア では、かつて夢物語であったことが現実となる可能 プリケーション / モバイル・アプリケーションで 性を秘めている。本稿のテーマに直接関係するもの 顕著となっている。ただし今のところ、従来の運 でないので、キーワードだけ述べると、 「認証」、 「監 用管理の視点で見ると、DevOps とは「クラウド上 査」、「位置特定」、「リアルタイムの資産管理」、「作 で高頻度な変更を行うサービス」であり、運用自 業動線」などで IoT の適用による劇的な変革が予想 動化の適用対象は主として「変更管理」と「リリ される。 ー ス 管 理 」 に 限 ら れ る。 な お DevOps を 採 用 す る 際、運用部門としては「変更管理」と「リリース Ⅴ まとめ 管理」の自動化を検討すると共に、DevOps で利用 されている開発ツールの活用を検討するべきであ アウトプットの特性変化と運用自動化要件の分 る。DevOps で使われるインフラ Code 化のテクノロ 析から、アウトプットが有形、無形で変化してい ジーは、運用自動化との親和性が高く、その活用 く際に、新たな運用自動化要件が生じることを説 エリアが驚くほど広いことが分かる。 明した。また、レンタルビデオのサービス提供モ デルの変革を例に、変革に沿った運用自動化の実 3) モバイル 装例を提示した。そしてそれらの運用自動化要件 クラウドファースト、モバイルファーストと言わ に影響を及ぼすいくつかの最新テクノロジーの動 42 向について説明した。 長期的な視点では、運用自動化はクラウドインフ ラ上で標準化、汎化された組込み技術として実装さ れるものと考える。この過程において、仮想化環境 におけるサーバ、ネットワーク、ストレージがコー ド化されてプロビジョニングできるようになるのと 同様に、運用機能のセットがコード化されて提供で きるようになる。そこには人手が介在することはな く、運用担当者はサービスが止まらずに効率よく稼 働し、常に改善し続けられるようにするために、各 種運用機能を考案し、実装し、組合せ、改善するこ とが仕事になるであろう。 これまで述べたように「有形から無形」、「有人か ら無人」、「設置から可搬」といったアウトプットの 変化、サービス提供モデルの変革を契機に、各種の 運用自動化要件が生じる。新しい魅力的なサービス を遅滞なく提供するためには、これらの契機を見逃 さず、変革の勝者になるための運用自動化をリード されることを期待する。 岩村 郁雄 日本アイ・ビー・エム・システムズ・エンジニアリング株式会社 ITSM エバンジェリスト IBM 運用管理製品のサポートを通じ、運用管理システ ムの設計、構築、保守を 20 年に渡り手がけている。また、 ITIL® Service Manager(2005)、ITIL® Expert(2010) の認定資格を取得し、IT サービスのライフサイクルを 通じた各種管理プロセスの確立、改善、高度化に関す る案件支援、情報発信などの活動を展開している。業 界活動としては、it SMF Japan における ITIL® 関連書 籍の翻訳レビューと寄稿、講演活動を通じ、書籍の翻 訳品質の向上と、日本での ITIL® V3 の普及の促進に 貢献している。 43 効果的な問題管理のための 5 つのアドバイス ITIL® に基づく効果的な問題管理の取り組みは、高いレベルのサ ービス可用性と一貫して高品質な IT サービスを提供しようとす る IT 組織には欠かせないものです。しかし、残念ながら、大多 数の IT 組織が問題管理の取り組みに費やした時間と労力に比べ て注目に値するメリットを得ていないのが実情です。今回の記事 では、効果的な問題管理を整備し維持するのに役立つ、簡単で実 践的な 5 つのアドバイスを紹介します。 アドバイス 1： 語の使用をあえて避けていますが、そ い）測定基準をすべて忘れ去る必要が 問題管理の労力は恒久的な解決策 れには理由があります。誰もがそれで あります。例えば、根本原因分析を完 の発見に集中しなさい 混乱してしまうからです。恒久的な解 了するためにかかった時間や未処理の 一時的な解決策を見つけ出すのに問 決策にも一時的な解決策にも適用でき 問題件数などがそうです。実のところ、 題管理を使用するという発想は捨てて るため、紛らわしいのです。そのため、 これらは問題管理に取り組んでいる価 ください。 この用語は避けるのが最善です（誰に 値を示しおらず、反映しておらず、ま でもわかる恒久的または一時的な解決 た測定してもいません。 問題管理で有形の真の価値を実現し 策という言葉の使用を貫きましょう）。 たいのであれば、恒久的な解決策を見 要するに、問題管理から真の価値を得 実際には、問題管理プロセスが価値 つけ出すことに集中した問題管理プロ る秘訣は、恒久的な解決策を見つけ出 をもたらしているかどうかの真に有形 セスを整備しなければなりません。 すことに集中するプロセスを構築する で意味のある指標は 1 つだけです。そ ことなのです。 れは何かと言えば、インシデントの量 の削減です。これが実現すれば、価値 問題管理活動を恒久的な解決策に集 中させなければ、インシデントの量を それができてこそ、問題の調査やそ ある問題管理プロセスだということで 大幅に減らすことはできません。つま の後の恒久的な解決策の展開に投じら す。そうならない場合は、有り体に言 り、問題管理の真の価値は、インシデ れた時間、労力、およびリソースを正 えば、単に時間を無駄にしているので ントの量の削減にこそあります。 当化する価値（インシデントの量の削 す。それほど簡単なことなのです。 減）を実現できます。 問題管理プロセスを定期的に（3 ヵ ここで重要なのは、恒久的な解決策 と一時的な解決策の違いを明確にする アドバイス 2： 月に 1 回などの頻度で）レビューし、 ことです。 整備した問題管理プロセスで確実 価値をもたらしているか、インシデン に真の価値を実現しなさい トの量が減少しているか確認しなけれ ・恒久的な解決策とは、インシデント ITIL® をよく知る組織はほとんどが ばなりません。そうなっていない場合 の根本原因がインシデントの再発を 何らかの形で問題管理を取り組んでい は、現在行っていることを中止し、変 防ぐような形で対処された場合を言 ます。そして、ごくわずかな例外を除 更する必要があります。プロセスを変 います。 いて、時間を無駄にしています。それは、 更するのです。改善し、より効果的に ・一時的な解決策とは、ユーザが（「可 整備した問題管理プロセスが、真の（有 しましょう。 能な限り早く」）作業を再開できるよ 形で、意味があり、測定可能な）価値 う採られる策で、必ずしも将来にお を何らもたらすことがないからです。 必要なら、さらに踏み込んで何らか の具体的な目標を設定してもよいでし けるインシデントの再発を防ぐもの ではありません。ユーザを一時的に 整備した問題管理プロセスが実際に ょう。例えば、優先度 1 のインシデン 別の印刷キューに割り当て直すこと 価値をもたらすかどうかは、どうすれ トを 3 ヵ月以内に 40% 削減する（最も などがその例です。 ばわかるでしょうか？それにはまず、 悪影響を及ぼすインシデントに対応す よく言及されるさまざまな（関係のな ることになりますから、これは非常に 私は「ワークアラウンド」という用 SPRING 2014 SERVICE TALK 44 効果的な問題管理のための 5 つのアドバイス 有効な目標です）、ネットワーク印刷関 家（SME）が実施します。 連のインシデントを 6 ヵ月で 60% 削減 するなどです。 害の大きい」インシデントをなくす） 問題マネージャの主な責任は、実際 問題に調査の優先度を置きたいもので には運営管理、調整、および推進にあ す。ここまでは異論ありませんよね。 インシデントの量が他の要因に左右 ります。具体的な活動としては、次の されうることは重々承知しています。 ものなどがあります。 多くの組織がこの点を、問題管理の有 効性の指標にインシデントの量を使用 しない口実にしていることもわかって を最大限に減らせる（または最も「損 では、どの問題調査が最大のメリッ トをもたらすかを決定するうえで最も ・問題調査の要求に正当性があるかど うかについてレビューする 良い立場にあるのは誰でしょうか？調 査に必要なリソースを正当化できるの います。インシデントの量は多くの要 ・各問題調査について、その調査に必 はどの問題であるかを決定するうえで 因に左右され、優れた問題管理を整備 要なリソースを正当化するためにビ 最も良い立場にあるのは誰でしょう しても場合によってはインシデントの ジネス・ケースを作成する か？ 量が（一時的に）増加する可能性があ ることは、私も認めます。 このような潜在的な課題があるにし ても、やはりインシデントの量が問題 管理プロセスの有効性の唯一最も重要 な指標であることに変わりはありませ ん。他のことはすべて忘れてください。 これを確実に達成するようにし、そう ならない場合は何とか手だてを考える のです。 ・適切な SME リソースが利用でき、関 連する問題調査に割り当てられるよ それは明らかに、（IT 組織の中で） うに手配する インシデント量の削減で最も恩恵を受 ・問題調査を実施する各 SME が準拠す るべき委任事項を作成する ・SME によって実施される調査を監督 する ける立場にある人であり、現在のイン シデントの傾向と量を最もよく把握し て理解している人であるに違いありま せん。 ・根本原因分析と提案された恒久的な 解決策の妥当性を確認する ・展開された恒久的な解決策の有効性 をレビューする それがサービスデスク／インシデン ト・マネージャであることは明白です。 実際のところ、この IT の役割は、効果 大半の組織では、専任リソースが問 的な問題管理に取り組んでいることに アドバイス 3： 題マネージャの役割を果たす正当な理 最も大きな関心を常に持っています。 サービスデスク／インシデント・マネ 由など、ほとんどありません。そのた つまりこれが、前述の役割を同じ人が ージャを問題マネージャとしなさい め、別の役割と兼任させることがしば 担うべきだと考える理由です。 もちろん、わかっていますよ。ITIL® しばです。まず行うべき非常に重要な ではやってはいけないとされているこ ポイントは、この役割に誰かを任命す これらの役割の間には「対立」があ とですね。ITIL® でそのようにアドバ ることです。誰かが（効果的な）問題 りません。共有された目標とメリット イスされている理由も知っていますし、 マネージャの役割を果たさないことに があるだけです。ですから、これらの 理解もしています。しかし、この場合 は、効果的な問題管理に取り組むこと 役割は兼任させてください。これが唯 は ITIL® が間違っていると思います。 はできないでしょう。 一賢明な選択肢です。 サービスデスク / インシデント・マ では、ここで話を元に戻しましょう。 アドバイス 4： ネージャを問題マネージャとするのが なぜ私が ITIL® に反対し、サービスデ とにかくやってみなさい。専門的 よいと言える正当な理由は実際にあり スク / インシデント・マネージャと問 なリソースもツールも不要 ます。ただ、それを説明する前に、問 題マネージャの役割を兼任させるよう 問題管理に取り組むための「リソー 題マネージャの実際の役割が何かを明 推奨するのかという話です。 ス」、つまり必要な人材および統合され たインシデント / 問題管理システムが 確にしておきましょう。 その理由は簡単です。問題管理プロ 不足しているという考えから、問題管 問題マネージャは技術的な役割では セスの主な目標は、インシデントの量 理の導入に消極的な組織があります。 なく、問題調査に取り組んだりはしま を削減することです（アドバイス 2 を せん。問題調査（根本原因分析と解決 参照）。それならば、最大のメリットを これはナンセンスです。効果的な問 策の特定）は、適切な対象分野の専門 SPRING 2014 SERVICE TALK もたらす、つまりインシデントの再発 題管理に取り組むのに何も特別なリソ 45 効果的な問題管理のための 5 つのアドバイス ースは必要ありません。既にあるリソ 依存するものでもありません。 ースで問題なく実施できます。 の程度の頻度で行うべきか、どのよう に分析するべきかなどです。特定のイ 一般的に考えられていることとは逆 ベント（高優先度のネットワーク障害 人材 に、サービスデスクが問題レコードに など）の後に問題調査の要求がされた 大規模なサードパーティの IT サービ アクセスできるようにすることには何 場合は、それがどのような経緯で発生 ス・プロバイダでない限り、問題調査 ら本当のメリットはありません。 したかが重要です。これらすべてを定 義し、問題管理プロセス文書に明確に に取り組む技術専門家を十分に揃えた 専任の問題管理チームを設立する必要 はっきり言えば、効果的な問題管理 は絶対にありません。実際には、これ に着手するのに何か特別なリソースは は全くもってやってはいけないことな 必要ないのです。とにかくやってみる しかし、問題調査の要求が問題マネ のです。 ことです。 ージャに提出された時点から、その要 記載する必要があります。 求の正当性を検討し、調査を受け付け 問題調査に取り組む SME は、事実上、 アドバイス 5： て優先度付けし、調査にリソースを割 既存の IT 部門やチームから割り当てる プロアクティブな問題管理とリア り当て、調査結果の妥当性を確認する ことになるでしょう。ここで重要なポ クティブな問題管理の区別に頭を といったプロセスは、要求の発生源に イントは、彼らが問題調査に費やす時 悩ませないこと 関係なく同じです。 間と労力が十分に正当化されることで 問題調査の要求がどこから発生した す。これは問題マネージャの責任です のかは重要でしょうか？ ですから、余計な複雑さは避け、プ ロアクティブな問題管理とリアクティ （アドバイス 3 を参照）。SME はどれだ けの時間を問題調査に充てる必要があ インシデントの定期的な傾向分析の ブな問題管理の無用な区別は無視して るでしょうか？ それは調査すると決 実施から発生したのか、優先度 1 のイ ください。単一のエンドツーエンドの 定した問題の性質と件数によります。 ンシデントが記録された結果として自 問題管理プロセスを開発するのです。 動的に発生したのかなどは、本当に重 要は、問題管理は現在手元にあるス 要なのでしょうか？いいえ。問題調査 タッフで着手できるということです。 のための効果的なプロセスを開発する という観点から言えば、問題の発生源 ただし 1 つ重要な注意点があります。 はほとんど重要ではありません。 問題調査のかなりの部分（大部分？） は性質上、技術的なものではないこと 多くの組織が、プロアクティブな問 を留意しておいてください。インシデ 題管理とリアクティブな問題管理には ントの大多数はプロセスや手順の不 別々の手順を用意する必要があるとい 良、人為ミスなどから生じます。問題 う認識から、過剰に複雑な問題管理プ 調査は、技術がうまくいかなかった原 ロセスを整備しています。しかし、プ 因ではなく、手順がうまくいかなかっ ロアクティブな問題管理とリアクティ た原因を探すことになるのがしばしば ブな問題管理の区別は、不必要に複雑 です。ですから、SME は必ずしも技術 にするだけです。問題管理手順を別々 リソースでなくてもかまいません。 に 2 通り用意する必要はありません。 Charles Fraser は熟練したフリー ツールセット ここで間違いなく重要なのは、潜在 ランスの ITSM コンサルタントです。 問題管理のための専門的なツール / 的な問題調査の要求がいつ、どのよう 専門領域は ITIL® プロセスの成熟 システムにお金を使う必要はありませ に、どこから発生し、それらを検討の 度／有効性のアセスメント、組織 ん。インシデント・レコードを問題レ ために問題マネージャにどのようにし コードに動的にリンクする必要は絶対 て提出するべきかを綿密に明確化する にありませんし、問題管理は統合され ことです。例えば、インシデントの傾 たインシデント／問題ツールセットに 向を分析する責任者は誰か、分析はど SPRING 2014 SERVICE TALK 46 による ISO/IEC 20000 認証取得の 支援などです。 著者への連絡先： Charles.fraser@CharlesFraser.net IT 変更の失敗を 避ける方法 IT変更が失敗すると、リソース時間、資材、インフラス トラクチャの誤用などの面で、多大なコストが生じるこ とがあります。そのため、事業の満足度や顧客の認識が 悪化し、多くの場合、事業機会を失うことになります。 Debarshi BandyopadhyayとVikas Singhaiが、変更の失 敗の理由を考察し、それらに対処するプロアクティブな対 策とリアクティブな対策を提案します。 どうして変更が失敗するのでしょうか？ 彼らの考えに耳を傾け、変更のうち彼ら 階で要員をトレーニングする必要があ 現代のオンライン化された世界経済 にかかわる部分のオーナシップを取るよ り、このときに新しいプロセスに習熟す では、IT のエンド・ユーザはアプリケ うに推進していることがわかっていま ることに対して多大な反発が起きまし ーションへのアクセスを 24 時間求めま す。このプラクティスは、成長している た。確立されたカルチャを持つ組織での す。この市場環境に対応するため、組織 今日のマルチベンダ環境では特に意義深 実質的な変更は常に困難を伴います。こ は絶えず革新と費用対効果で境界を押し いものです。しかし、必ずこれができる の特定のケースでは、上級マネジメント 広げています。今や、IT アプリケーシ と言えるでしょうか？ 残念ながら、変 が腕まくりして直接関与しなければなら ョンとサービスは多様なプラットフォー 更の要求元、変更マネージャ、および変 なくなりました。彼らの奮闘がなければ、 ムに構築され、さまざまな地域にホステ 更諮問委員会のメンバの役割と責任が、 プログラムは大失敗に終わったかもしれ ィングされ、分散したチームによってサ アウトソース環境の中でよく理解されて ません。 ポートされています。この複雑なフレー いないことが多々あります。このような ムワークは人材、プロセス、および技術 要因はどのような変更プロジェクトにお プロセス によってまとめられており、適切に管理 いても極めて重要です。 変更失敗の主な理由の 1 つはプロセス を遵守しないことですが、ちょっとした しなければ、この基礎となる柱そのもの が IT 変更の失敗を引き起こすことにな もう 1 つ、IT 変更に対する要因でよ 見落とし、無知、プロセスの全くの未熟 ります。 く見落とされるものがカルチャです。こ さが変更の失敗につながったケースがこ れは実際にあったことなのですが、ある れまでに多数あります。変更管理の標準 人材 世界的な製薬会社で、新しいユーザ・ア 化の程度は今でも多くの IT 部門にとっ どのような変更でも、人とその利害、 クセス管理ソリューションを展開する大 ての課題です。失敗の原因となるのは変 組織の境界、および考え方が影響要因と 規模なプログラムが開始されました。 更プロセスばかりとは限りません。見落 とされるかもしれない、セキュリティ、 なります。研究によると、成功する変更 を主導する人はあらゆるレベルの人々に プログラム自体は技術的にすべてがう SLM、可用性、およびキャパシティ管理 情報を与え続けることで深く関与させ、 SPRING 2014 SERVICE TALK まく進んでいるようでしたが、最後の段 などの相互依存プロセスも失敗の原因と 47 IT 変更の失敗を避ける方法 なります。経験によると、不十分な要件 いことがあります。 把握、適切なテストとユーザ受け入れの みを利用すれば堅牢性を強化できます。 リリース計画を整備し、これに変更展開 欠如でも変更の実施がうまくいかない場 CPU、メモリ、およびディスクに限ら 指針（ラン・ブック）と切り戻し手順を 合があるようです。 ずネットワーク・キャパシティなどを含 盛り込むべきでしょう。 む環境のサイジングも、帯域幅や遅延の オーストラリアのある大手銀行がその 面で見落とされることが多くあります。 前述のオーストラリアの銀行の例で電 電気通信ネットワークの管理をサービ 変更は既存のサービス・ラインに持ち込 気通信プロバイダが標準運用手順にピ ス・プロバイダにアウトソーシングして まれるため、ネットワークのキャパシテ ア・レビューの仕組みを組み込んでいれ いました。銀行が新たな拠点を追加しな ィには定常的なモニタリングとアップグ ば、変更の失敗を避けられたかもしれま ければならなくなり、その拠点に対して レードが必要です。アーキテクチャの整 せん。 電気通信ネットワークの拡張を実施する 合不良、技術的な不一致、第三の構成ア ことになりました。これは同銀行にとっ イテムが技術ロードマップに整合してい 2. コミュニケーションと再コミュ ては成長計画に則った標準的な変更でし ないという落とし穴も、変更の失敗につ ニケーション： た。電気通信サービス・プロバイダでは ながることがあります。 さまざまな利害関係者の期待が裏切ら 標準的な運用手順が整備されていまし れないようにするため、展開しようとし た。不運なことに現場のセキュリティ・ 英国の最大手電気通信サービス・プロ ている変更を前もってコミュニケーショ エンジニアがあるステップを実施し損な バイダの 1 社が、欧州で運営している関 ンすれば、人々が心構えをするのに役立 ったため、新拠点の立ち上げ日に間に合 連会社の 1 社でオンライン・プラット ちます。変更についてコミュニケーショ わなくなりました。何がまずかったのか フォームのアップグレードを行わせまし ンし、テストし、展開する。そして変更 を探ることに数人日が割かれました。 た。この変更の結果、誤って機密資料が が実施されたことを再びコミュニケーシ 公開されたしまったことが明らかにな ョンすることにより、適度な利害関係者 同様のケースですが、北米のある大手 り、標準的な技術的変更を展開から数分 の関与が得られます。 ケーブル・サービス・プロバイダが、ア のうちに切り戻さなければならなくなり カウント更新のビジネス・プロセスを設 ました。このトラブルの主な理由は、新 3. 測定基準と測定： 計し直すことになりました。ビジネス・ プラットフォームと旧プラットフォーム 測定基準の収集と分析を実施すること プロセスの設計が承認され、IT サービ の間でセキュリティ・モジュールの互換 が重要です。四半期ごと、月次、および ス会社が本番環境に IT 変更を展開する 性がなかったことでした。 年次データに基づく経時的な分析で、変 ことになりました。期日が迫っているこ 更の失敗にパターンが見つかることがあ とから、重大で緊急の展開として扱われ、 成功率を高めるには ります。分析により、技術、事業、地域、 変更諮問委員会の承認は省かれました。 どうすればよいしょうか？ およびアプリケーション、ネットワーク、 展開は、多くのアカウント更新がある営 チームなどのさまざまな領域にまで掘り 業日に行われました。その結果、本番環 以下に、大企業の IT 組織内で不備が 下げることができます。運用上の測定基 境で障害が発生し、6 時間にわたってシ よく見られる領域を幾つか示します。こ 準としては例えば次のものがあります。 ステムが停止しました。 れらの領域に正しく対応すれば、変更の 成功率を大幅に高められるでしょう。 技術 ・サービス・ライン別、地域別、事業部 門別の毎月の変更失敗件数 組織はそれぞれ広範囲の構成アイテ 1. 総合的品質保証： ムをサポートしており、これらの相互 どのような大規模な変更においても、 ・変更の失敗により発生したインシデン トまたは問題の件数 依存性も変更を成功させる鍵となりま エンド・ユーザ教育および標準運用手順 ・不十分なインパクト分析、許可の欠如、 す。特に、他から切り離して行われる （SOP）を伴った徹底的なユーザ受け入れ またはプロセスを遵守しないことによ アップグレードはしばしば問題の発生 テストの実施が重要です。SOP はプロセ につながります。さまざまなベンダが スを標準化し、タスクを一貫した方法で 提供するハードウェアも、アルゴリズ 行える段階的な操作指示を提示します。 4. ガバナンスの確立と遵守： ムの変更に加えて、アプリケーション 文書化された SOP とチェックリストが非 変更諮問委員会を構成するさまざまな がもたらす変更にもうまく対応できな SPRING 2014 SERVICE TALK 常に有用ですが、ピア・レビューの仕組 役割（アプリケーション・オーナ、ハー 48 る変更の失敗 IT 変更の失敗を避ける方法 ドウェア / ネットワーク専門家、事業オ ーナなど）を考慮したガバナンス体制を て総意を得ます。 ます。 ・コンサルティング：専門家に改善の領 構築しなければなりません。これにより、 域をレビューしてもらいます。事業マ ある大手電気通信プロバイダでの事例 各オーナにそれぞれの領域に集中させ、 ネージャおよび技術マネージャとブレ で、変更を複雑、中程度、単純に分類す しかもどのような変更でも全体的な運用 インストーミングを行うことにより、 る重要性が明らかになりました。この組 には影響が及ばないようにすることがで 課題を識別します。このようなセッシ 織は、新規の法人顧客を獲得するため、 きます。また、利害関係者全員が関与す ョンの目的は、ユーザ、顧客、および 百万ドル規模の新規ポータル立ち上げに るため、機能性、サービスレベル、パフ 各利害関係者が結果に満足すること 取り組みました。このポータルはトライ ォーマンス、キャパシティ、およびコス で、そうでない場合はさまざまな不備 アルに選ばれた顧客 1 社とともに立ち上 トに対する望ましくない副作用が抑制さ について話し合い、将来はそれらを回 げられましたが、その顧客は 1 ヵ月もし れます。変更管理は、あらゆるレベルの 避できるようにすることです。 ないうちに製品品質の悪さが不満で撤退 サービス・サポート・チームにできるだ したのです。立ち上げが切り戻されるこ け前もって情報を提供し、実施される変 これまで述べた指針に関連し、変更の とはありませんでしたが、多大な収益の 更に基づいて適切なスタッフの配置を手 展開の成功率を大きく向上させたプラク 損失が生じました。問題を解決するた 配しなければなりません。 ティスを次に紹介しましょう。 め、追加資金も投入しなければなりませ んでした。これは変更の失敗と分類して 5. 継続的プロセス改善： ヒント 1：複雑性に基づく変更の分類： よいでしょうか？ この展開には、切り 昨日はうまくいったからといって、明 契約上、変更の失敗はペナルティを伴 戻しを除くと、変更の失敗の属性すべて 日もそうだとは限りません。変更プロセ うため、マルチベンダ環境では責任者を が備わっています。失敗の主な理由は、 スには継続的改善を適用し、ストレス・ 明確にするうえで分類が重要です。大組 設計時に採られた戦略のまずさにありま テスト後は短期のうちに成熟度が上がる 織では、基本的なソフトウェア・ビルド した。短期での市場投入を達成するた ようにする必要があります。当初設定 を担当する技術パートナに加え、何社か め、すぐに使えるシステムの実装と統合 した達成目標が満たされたか確認するた のハードウェア・プロバイダ、複数のシ に主な焦点が置かれました。多様なシス め、実施後のレビューを行わなければな ステム・インテグレータ、および多数の テムにまたがって入り組んだワークフロ りません。 外部契約者を抱えているのが普通です。 ーが導入され、カスタマイゼーションも そのため、変更が失敗した場合にその責 最小限に止められました。IT システム 6. 実施後のレビュー： 任がどこにあるのかを確認することが重 というものは、LEGO ブロックとは異なり、 プロジェクト管理のベスト・プラク 要です。また、全体的なプロセス・コン 信頼性を実現するためには設計、開発、 ティスの幾つか、例えば教訓、うまく トロールに単一のオーナシップがないの テスト、展開の厳しさをくぐる必要があ いったこととうまくいかなかったこと で、変更失敗の原因が何だったのかを精 るのだということが忘れ去られていたの の記録なども、変更管理に適用できま 査することに貴重な時間の多くが失われ です。 す。RISC モ デ ル（Review（ レ ビ ュ ー）、 Investigate（調査）、Survey（サーベイ）、 Consult（コンサルティング））は、実施 後レビューの非常に有効なツールです。 ・レビュー：週ごと、月ごと、年ごとの 変更失敗件数、変更の失敗による平均 停止時間、復旧までの時間などの統計 を集めます。 ・調査：変更の失敗 1 件によりどれだけ のインシデントが記録されたか、どれ だけ SLA に違反したかなど、コストを 計算します。 ・サーベイ：最も重要なサービスについ SPRING 2014 SERVICE TALK 49 IT 変更の失敗を避ける方法 リスク・カテゴリが「赤」の変更に 前述の例では、設計戦略が失敗の理 変更の失敗に対してより適切に備え は緊急事態対応計画が必須です。他の 由でした。別の見方をすれば、なぜ生 られるようにするため、実証済みの方 カテゴリの変更は成功率がより高いで 煮えの製品が市場にリリースされたの 法を幾つか次に示します。 すが、これらの変更を緊急事態対応計 かと、テスト戦略を疑問視することも 画を通して行わなければリスクと見返 できるでしょう。変更を複雑、中程度、 簡易的な追跡 りのバランスを達成できないかもしれ 単純に分類することは不可欠です。そ リスク（赤、黄、緑）にかかわらず、 ません。緊急事態対応計画の狙いは、 うすることにより、複雑な変更におい 変更はすべて変更管理システムにより 予期できないイベントのインパクトを て必要な設計の詳細とテストの段階が 追跡し、実施に先立って関連するサー 最小化し、当初の計画が失敗した後も 見落とされずに済みます。 ビスや構成アイテムへの潜在的なイン 事業が通常の運用を再開できるよう計 パクトを評価しましょう。業界のフレ 画することにあります。それでは、ど 教訓： ームワークでは 7 レベルの分析が提案 のようにすればそれが行えるでしょう 事業収益の損失、組織の評判および されています。7 つのレベルとは、変更 か？ 契約上のペナルティは、「複雑」な変更 提案者の明確化、変更の理由、期待さ が「単純」な変更とは異なる形で設計 れる利益、関連するリスク、必要なリ 1. 総合的なリスク・アセスメントの実施： され実現されれば回避できます。 ソース、役割と責任、およびその変更 当初の計画が想定どおりに進まなか とその他の変更との関係です。 ったときには何が起こるのかを自問自 答します。 ヒント 2：インパクトに基づくリスク のカテゴリ：変更に伴うリスクを、経 つまり、追跡により学習効果が上が 験に基づく失敗の確率に従って赤、黄、 るのです。追跡中に得られた重要な情 2. 計画の策定： 緑に分類するとよいでしょう。リスク 報は、現在および将来の改善につなが 緊急事態計画は複雑にならず、全員 がわかれば、変更マネージャは幾つか る「真実の源」となります。 のニーズを満足できるようなものとし の対策によりそれを緩和するよう努め ます。計画には、「いつもの事業」に戻 ることができます。このアプローチの 切り戻しと緊急事態対応計画 るためには何が必要であるかなど、成 利点は、成熟度が向上する点です。組 切り戻しのオプションは全てのリス 功基準を必ず定義します。 織は、赤（高リスク / 高インパクト）、 ク・カテゴリの変更に対して計画しな 黄または緑（低リスク）の変更の履歴 ければなりません。変更をスケジュー 3. 計画の維持： に基づいて、リリースおよび展開の計 リングする前に、変更マネージャかリ 計画を組織の全員に伝達し、計画の 画立案を成熟させることができます。 リース・マネージャが必ず次の 2 つの 活動に従って RACI を整備します。計画 場合について、どの活動を実行するべ が常に組織のビジネス・ニーズを満た 備えをより適切に きかという根本的な質問を投げかけな すように、定期的な監査を実施します。 - 変更は失敗することがある ければなりません。 現実に向き合いましょう。IT では、 ・展開の前に何をすべきか？ 例としては、ドイツで電子請求シス 勝利の方程式を保証できる者などいま ・失敗の場合に何をすべきか？ テムを投入しようとした電気通信サー せん。失敗は起こるものです。しかし、 この質問に対応することにより、高 ビス・プロバイダのケースがあります。 組織がその方法論をプロアクティブに レベルの準備状況が保証されます。展 加入者数は非常に多く、800 万人を超え 是正すると決めれば、戦いは半分勝っ 開の日常業務の一環として切り戻し計 る規模でした。この変更が失敗すると、 たようなものです。組織がシステムの 画を含めることは、物事が計画どおり サービスデスクには大量のコールが寄 停止時間やデータ喪失から復旧するの に進まない場合のサービス中断を防止 せられると思われました。そのリスク にかかる時間は財務上の危機につなが するうえで有効な方法です。切り戻し に基づき、変更分類は赤とされました。 り、場合によっては事業が幕を閉じる 計画の存在が保険となります。変更が 変更マネージャは変更が夜間に行われ おそれもあります。したがって、変更 失敗した場合には、切り戻し / 巻き戻 るよう徹底しました。この新ソリュー の失敗に対してより適切に備えなけれ しを早く無事に完了させるほど、イン ションがうまくいかなかった場合には、 ばなりません。 シデント件数と運用コストが少なくな 緊急事態計画が発動され、夜明けまで ります。 SPRING 2014 SERVICE TALK 50 IT 変更の失敗を避ける方法 に元の請求ソリューションに切り戻さ の幾つかは達成できません。 れることになっていました。切り替え の実施前には、上級マネジメントの承 これに対する答えは、サービス導入 認が求められました。 モデルにあります。サービス導入は、 ロードマップ、リリース・ライフサイ ITIL® は何といっているでしょうか？ クルの中で潜在的な落とし穴を指摘す 小さな変更でも大きなインパクトを る手引きや助言を与えてくれる情報源、 及ぼすことがあります。たとえ小さな そして何より、厳しく統制されコント 変更でも、失敗した場合のインパクト ロールされたリリース・プロセスを整 の面で赤に分類されているのであれば、 備することの重要性を強調しています。 プロセスの遵守、ガバナンスの確保、 これは、あらゆることが一貫した方法 役割と責任、および技術の精査の重要 で記録される 1 つのまとまった場所で 性は極めて高いと言えます。変更マネ あり、プロジェクトとプログラムのポ ージャとしては潜在的なインパクトに ートフォリオに関する最新情報を提供 はどのようなものにでも備える必要が し、教訓が記録されるだけではなく実 ありますから、赤分類の小さな変更に 践されるようにもするための手段とな 対するプロセスでも何一つ手を抜けま ります。 せん。人材、プロセス、技術の 3 つの 柱によりどれほど徹底的な精査や綿密 な整合を行おうと、切り戻し計画は整 備しなければなりません。 事業から次々と期限を迫られたため に、成熟した能力モデルを持つ組織が つまずいた例が幾つもあります。納期 もコストの一部ですから、事業パート ナからの期限も同様に厳しいのでしょ う。しかし上級マネジメントは、変更 が失敗すれば多くの場合はもっとコス トがかかることを理解しなければなり ません。 ITIL® は、すべての IT サービスを本 番環境に移行させる場合に、単一の反 復可能なプロセスを整備することの重 要性を強調しています。IT 組織はコス Debarshi Bandyopadhyay（左）はInfosys トのかかるプロジェクト、プロジェク Limitedのインフラストラクチャ・マネジメン ト・マネージャ、対象分野の専門家、 ト・サービス部門の上級コンサルタントであ サプライヤ、およびさまざまなコンサ り、Vikas Singhaiは同部門の主席コンサルタ ルタントに投資するのですが、新プロ ントです。2人は、2012年11月にitSMF UKのプ ジェクトが立ち上がる度に一からやり ロジェクト・オブ・ザ・イヤー賞の最終選考に 直し、下手をすれば関与している人材 残ったInfosys-Vodafoneの代表です。さまざま な業界と地域にわたり、変更およびサービス移 の本当の専門能力を活用せずに終わり 行の管理おいて合わせて15年を超える経験を持 ます。毎回同じことが見落とされるわ っています。 けですから、このようなプロジェクト SPRING 2014 SERVICE TALK 51 分科会紹介 it SMF Japan では、IT サービスマネジメントにおける新技術の調査・研究、あるいは既存技術の 高度化、体系化などを目的として分科会を立ち上げて活動しています。各分科会は、IT サービス マネジメントのベストプラクティスである ITIL® に関連したテーマを選定し、会員により運営され ています。活動内容・成果は、分科会セミナやコンファレンスにて報告しています。 2014 年 3 月に新たに発足しました「バリューコストマネジメント研究分科会」をご紹介いたし ます。 バリューコストマネジメント研究分科会 「バリューコストマネジメント研究分科会」は、 た方法に基づき適切に算出し、管理すること、また 2014 年 3 月に 18 名で発足した分科会です。これま それらをきちんと顧客へ説明し、合意できることが での分科会でもあまり触れることが少なかった IT 重要です。 コストに着目し、その中でも特に運用フェーズに焦 点を絞って研究活動することを目的としています。 そのため、当分科会では以下の 2 つを研究テーマ として活動を始めました。 IT 投資は最近になって徐々に増加しつつあります が、運用に対する投資は相変わらず抑制傾向にある 【テーマ 1】 のが現状です。特に運用業務はビジネスを支える重 ◆運用コスト管理方法の研究 要な位置づけであるのに対して、その価値（バリュ ・顧客が要求するサービス内容に必要な運用コスト ー）をアピールできていないため、コスト削減の無 の算出方法および管理方法を研究します。 条件なターゲットにされてしまうことが多く、それ らが運用部門の中で大きな課題となっています。 【テーマ 2】 ◆運用コスト価値の研究 運用に対する重要度が認識されていない理由とし ・運用コストに対する価値（バリュー）とはどのよ ては、サービスに基づく適切な運用コストの算出方 うなことなのかを検討すると同時にそのアピール 法や管理を行うための標準的な方法が確立されてい 方法を研究します。 ないこと、およびコストは品質やリスクとの関係（バ ランス）を評価する必要があるがそれらが実施され 【成果物】 ていないことに原因があると考えています。顧客か ◆成果物としては、それぞれのテーマから以下を予 らの要求に対し、それらに必要なコストを定められ 定しています。 52 ・運用コスト管理ガイドライン（仮称） ・運用コストに対する価値（バリュー）の考え方（仮称） 現在、11 月に開催される第 11 回 it SMF Japan コ ンファレンス /EXPO を当面の目標に議論を進めてお り、その際にはそれまでに行った研究内容を発表し たいと考えています。 今後の「バリューコストマネジメ ント研究分科会」の活動にご期待く ださい。 （座長 齋藤 寛） バリューコストマネジメント研究分科会メンバー （2014年5月現在）※敬称略・順不同 座 長 齋藤 寛 ユニアデックス株式会社 副 座 長 大歳 岳 株式会社野村総合研究所 副 座 長 進 典子 株式会社 NEC 情報システムズ 官野 厚 オリーブネット株式会社 中村 峰行 トランスコスモス株式会社 川村 喜一 株式会社信興テクノミスト 水野 拓郎 ServiceNow Japan 株式会社 岸本 拓也 株式会社インサイトテクノロジー 濱野 勇作 アルファテック・ソリューションズ株式会社 松田 敬子 個人会員 須原 健太 富士通エフサスシステムズ株式会社 宮入 勉 個人会員 岡本 宗之 株式会社 IT プレナーズジャパン・アジアパシフィック 後藤 圭介 クオリカ株式会社 高橋 洋一郎 ヤフー株式会社 是村 潤 個人会員 近藤 英志 コベルコシステム株式会社 石川 智恵 株式会社フェス 53 新理事挨拶 ■ it SMF Japan 理事 伊藤 清 2014 年 4 月より新しく理事に就 ついて模索しているケースも多く存在しております。 任いたしました伊藤 清です。 どうぞよろしくお願いいたします。 IT をビジネスとして運営し、より優れた価値をビ ジネスへ提供していくためには、より優れた IT バ 現在、企業活動の更なるグロー リューチェーンによる、更に優れた IT サービスの バル化や需要の多様化により、ビ 提供が必要であり、サービスマネジメントが必要不 ジネスにおける IT の必要性と期待が益々高まって 可欠な要素となります。 おり、IT がビジネスへ、より優れた価値を提供す ITIL® の普及促進を目的とした it SMF Japan は、こ ることが求められております。 のような更に優れた活動を企業が実現していくため 特に近年、クラウド、モビリティ、ビッグデータ、 に、大変重要な役割を担っていると感じております。 ソーシャルを軸とした「IT の新しいスタイル」を展 開し、IT を、従来のコストセンターから、ビジネス 末筆ではございますが、会員の皆様のご支援を賜 の一部としてのビジネスイノベーションセンターと りつつ、微力ながら it SMF Japan の活動と今後の発 していくための IT トランスフォーメーションを計画 展に努めていきたいと存じますので、ご指導ご鞭撻 し推進する企業が国内外ともに増えている一方で、 のほど、何卒よろしくお願い申し上げます。 このような変革を実際にどのように進めるべきかに 各種募集のお知らせ ■広告の募集 it SMF Japan 会報誌「Newsletter」では、IT サービスマ 回数 掲載場所 ページ 料金 ( 税込 ) ネジメントに関するビジネスに取り組む企業会員様からの 表紙の次のページ 1 ページ 108,000 円 itSMF Japan 会報誌「Newsletter」( 年 4 回発行 ) への広 1回 半ページ 43,200 円 上記以外 ( 通常のページ ) 告掲載を募集しております。 1 ページ 86,400 円 it SMF Japan オ フ ィ シ ャ ル サ イ ト（http//www.itsmf半ページ 70,200 円 japan.org）会報誌のページ「広告掲載規定」をご確認い 半年 (2 回 ) 通常のページ 1 ページ 140,400 円 ただき、 「it SMF Japan 広告掲載申込書」にご記入の上、 半ページ 108,000 円 事務局までメールにてお申し込みください。 通年 (4 回 ) 通常のページ 1 ページ 216,000 円 (info@itsmf-japan.org) ■投稿の募集 it SMF Japan 会報誌「Newsletter」では、会員・非会員を問わず皆様からの投稿を募集しています。ぜひ皆様の貴 重なご意見・ご経験をお伝えさせていただきたいと考えています。なお、会員の方からの投稿が採用された場合、 it SMF Japan WEB ページで販売している書籍を 1 冊（PDF 書籍を除く）贈呈させていただきます。非会員の方から の投稿が採用された場合、個人会員資格を無償で 1 年間（掲載された会報誌の発行日から 1 年間）譲与させていた だきます。 ■インタビュをお受けいただける会員様の募集 it SMF Japan 会報誌「Newsletter」では、企業会員様およびコンファレンスでご講演いただきました企業様を対象 として 1 時間ほどのインタビュを行わせていただき、IT サービスマネジメントの取り組みをご紹介させていただ いております。こちらも随時募集しております。投稿と同様ご希望の書籍を 1 冊贈呈いたします。 ■会報誌「Newsletter」編集メンバの募集 it SMF Japan 会報誌「Newsletter」では、編集活動にご協力いただける会員様を募集しております。主な活動内容は、 編集会議への参加、翻訳記事のレビュー、編集活動（起稿、校正等）などです。 参加ご希望の方は、メール (info@itsmf-japan.org) にてお知らせください。編集メンバは、 「Newsletter」最終ペー ジにお名前と所属企業名を掲載いたします。it SMF Japan への貢献をアピールできますので、奮ってご参加ください。 54 関西支部活動報告 ■ it SMF Japan 関西支部 初夏の日差しがいっそう厳しくなってきました 所が多いので、近くにも、きっと皆様だけの隠れたあ が、皆さまはいかがお過ごしでしょうか。 じさいの見所、名所があるのではないでしょうか。き っと心が癒されることと思います。 今年もすでに 7 月に入っておりますが、今回は 6 月の梅雨のお話をさせていただきます。梅雨は春か it SMF Japan 関西支部の活動につきましては、今 ら夏への季節の移り変わりの時期で 4 月から 5 月に 年も大阪でセミナを年 2 回開催いたします。今年度 かけて桜、藤、山吹、躑躅、牡丹、芍薬、皐月と、 も要望の多いユーザ事例、資格取得のための情報提 さまざまな花が次々と咲き、私たちの目を楽しませ 供を計画しております。東京開催のコンファレンス てくれましたが、6 月の梅雨の時期に咲く花と言え やセミナでの講演を関西の皆様にもご聴講してい ば、まず「あじさい」を連想する方も多いのではな ただくことも考えております。セミナ開催情報は、 いでしょうか。雨に濡れたあじさいの色は、ひとき it SMF Japan ホームページでご案内させていただき わ美しく感じます。日照時間等の条件にもよります ますのでご参照願います。 が、あじさいは、土壌が酸性の場合は青色、アルカ リ性の場合は赤色になる、と言われています。 また、分科会活動に関しましては、関西エリアで 分科会を発足したいという会員様がいらっしゃいま 関東では白いあじさいをよく目にしますが、これは、 したら、分科会発足に向けたサポートも実施いたし 色素をもたないので、土壌が変わっても花の色は変わ ますので、お気軽にお声をおかけください。 らないようです。多湿に強いあじさいは、日本の気候 によくあい、古くは万葉集にも 2 首、あじさいの和歌 ITIL® はグローバル化、クラウド化も含めて IT シ が詠まれているほど、私たちにとって馴染み深く、今 ステム運用におけるさまざまな問題を解決し、企業 でも演歌やポップスなど、ジャンルを問わず、歌のモ の事業継続の一助にもなりうると考えております。 チーフに取り上げられている花でもあります。そんな 今一度 ITIL® の目線で再度 IT システムを注目して あじさいには、あじさい寺、あじさい園など、見所、 みてください。皆様にとっての IT 投資の「グッド 名所が全国的に数多く存在します。 プラクティス」が見つかると思います。 関西在住の私たちにとって、関東のあじさいの名 末筆ではございますが、今後とも it SMF Japan の 所と言えば、テレビの旅行番組でもよく取り上げら 会員の皆様にとって喜ばれる活動、内容をめざして れる鎌倉や箱根を思い浮かべます。関西では、日本 まいりますので、ご指導、ご鞭撻のほどよろしくお 屈指の 5 万株のあじさいが咲き誇る兵庫県の神戸市 願い申しあげます。 立森林植物園や京都府の舞鶴自然文化園は、あじさ い園として、また、しっとりとした雰囲気にあじさ いが彩を添える京都府の善峯寺、三室戸寺、奈良県 の矢田寺は、あじさい寺として有名です。 お近くにお越しになられた際には、是非、お立ち 寄りいただきたい関西屈指のあじさいの名所です。 あじさいは今ご紹介したような見所、名所以外にも、 お寺の庭や公園、学校の花壇など、植えられている場 55 特定非営利活動法人 it SMF Japan 第 11 回通常総会報告 2014 年 5 月 27 日（火）14：00 ～ 16：05 富田理事長より、総会開催にあたり以下の挨拶が ソラシティカンファレンスセンター ROOM B ありました。 当日は議決権を有する正会員と傍聴者合わせて 87 理事長挨拶 人の出席がありました。司会より開会宣言と総会設 it SMF Japan の活動は 10 年を経過したが、活動の 立（議決権のある会員数 426 人のうち、出席 75 人、 さらなる活発化を行っていきます。 書面評決 102 人）が告げられ、以下の議題に沿って ITIL® はコモディティ化したと評する人がいるが、 議事審議を行いました。 広く普及したという意味に解釈している。 ※ 2013 年度活動報告と 2014 年度活動計画の詳細は、第 日本および世界で、ITIL® は運用管理、サービス 11 回通常総会議案書をご参照ください（it SMF Japan マネジメントのレファレンスとして広く使われてい WEB サイトの会員ページより、ダウンロード、通常総会 る。ただ、こうした状況の中にありながら、残念な からご覧になれます）。 がら ITIL® 2011 edition の書籍売上が伸び悩んでい る。今後の 10 年に向け、新たな施策を実施していき 総会次第 たい。 1) 開会宣言 ・昨年度末に会員満足度調査を実施した。今期は、 2) 理事長挨拶 IT サービスマネジメント実態調査を実施しそれら 3) 議長選出 の結果を活動計画に反映させていく。 4) 定足数確認、議事録署名人選出 ・ITIL® の版権を所有し、資格スキームを運営する 5) 第 1 号議案 2013 年度事業報告 ( 案 )（審議事項） 英国 AXELOS 社の人員は、大幅に強化された。プラ 6) 第 2 号議案 2013 年度決算報告 ( 案 )（審議事項） クティショナーとのネットワーキング、PRINCE2 7) 第 3 号議案 2014 年度理事選任報告（報告事項） などのベストプラクティスやサイバーセキュリテ 8) 第 4 号議案 2014 年度監事選出（審議事項） ィ等の新たな施策にも取り組みはじめた。 9) 第 5 号議案 2014 年度事業計画（報告事項） ・it SMF International は、UK、US、オーストラリア、 10) 第 6 号議案 2014 年度予算（報告事項） 日本が活動を主導している。日本の活動は、質も 11）議長解任 高く規模も適切でスピード感をもってやっている 12）新理事挨拶 と各国より高く評価されている。 13）閉会宣言 ・it SMF USA では、ビジョン、ミッションを新たに 56 定義しなおし、ITIL® をサービスマネジメントに 「質問」 も適用していくことが提起されている。 現状の共有フォルダが使えないとしたら、 各分科会 ・ITIL® 導入のアセスメントをきちんと行い、企業 でコントロールしてもいいか？ のトランスフォーメーションを支え、さらにその Capability を高めることの重要性をユーザ企業に 「回答」 伝えていきたい。 代替のツールを使っている分科会もあり、あえて、 ・また、企業の CIO、CFO に対しさらなる情報発信を 現状の共有フォルダに拘るものではない。 行っていきたい。資金を有効に使い、今後の 10 年 も当団体が継続して発展していけるよう活動して 「質問」 いきたい。 ソーシャルメディアを利用した情報発信につい て、昨年 1 年間見ても、it SMF Japan からの情報発 皆様のご協力およびご支援をこれからもよろしく 信は少なかったと思う。コンファレンスの Facebook お願いします。 は、特に「いいね」の数が少なかった。今年度は、 費用がかからず宣伝できる Facebook を活用して、 第 1 号議案 2013 年度活動報告 コンファレンスの宣伝をもっとやってほしい。 会員、事業化推進委員会、試験・書籍の日本語化、 出版業務、コンファレンス、セミナ、関西支部、分 ｢ 回答 ｣ 科会、会報誌、WEB、試験、国際プロモーション、国 ご指摘いただきありがとうございます。Facebook 内プロモーションに関する活動と事務局の活動およ 運用のプロセスを整備してタイムリーな情報発信を び 2013 年度理事と監査についての活動が報告され、 行っていきたい。 承認されました。 ＜議決＞ 第 1 号議案は、出席した構成員の過半数以上の拍 ＜質疑・応答＞ 手により承認されました。 「質問」 分科会メンバの共有ツール「共有フォルダ」が使 いにくいという質問を昨年の総会で行ったが、改善 第 2 号議案 2013 年度決算 がされていない。また、会員パスワードはセキュリ 2013年度決算報告・監査報告が承認されました。 ティのため毎年更新されるが、分科会の共有ツール 経常収益：89,939,741円 では、会員とリンクができておらず、古いパスワー 内 会費収入：23,572,917円 ドでないとログインできない。 事業収入：66,226,228円 その他 ： 140,596円 「回答」 経常経費：84,961,540円 昨年度は、WindowsXP サポート終了対応があり、 内 事業費：61,864,290円 管理費：23,097,250円 インフラ整備が遅れていることは申し訳ないと思っ ている。「パスワード」については、会員管理シス 続いて、以下の通り、徳地理事より内部監査報 テムと分科会管理システムが別々のシステムになっ 告(年2回)および福島監事より監査報告が行われ ていること、現共有フォルダは、メンバ各社のセキ ました。 ュリティ環境により使用できないケースもあること に起因している。 内部監査報告：経費処理業務、会員管理業務、書 分科会座長会では、運用でカバーしていただくよ 籍販売業務について業務フローとの突き合わせを行 う話してきており、ご理解いただいていると認識し い、業務が適切に行われていることを確認した。前 ている。今後、システム全体の見直しについては継 回の監査の指摘事項についても是正計画書を確認し 続して検討していきたい。 内部統制ができていることを確認した。 外部監査報告：これからの10年に向けて、資産をど 57 う使っていくか、中長期の計画をきちんと立てていく 2014 年度監事は、引き続き福島監事が選出され承 ことが肝要である。当法人の会計の方法と結果、財産 認されました。 目録、貸借対照表、活動計算書、付属明細書、理事の 職務遂行に関して間違いがないことを監査した。 第 5 号議案 2014 年度活動計画 2014 年度の活動計画は、以下のように報告されま ＜質疑・応答＞ した。 なし 1. 事業化推進グループ ＜議決＞ 事業化推進委員会 第 2 号議案は、出席した構成員の過半数以上の拍 ・会員増獲得に向けた新規施策を検討します。 手により承認されました。 ・スポンサー White Paper を充実していきます。 第 3 号議案 2014 年度理事選任報告 10 周年調査プロジェクト 2014 年度の理事の選任について以下のように報告さ ・IT サービスマネジメント実態調査を実施し、調査 れました。 結果を分析し、報告書として発行します。 富田 修二 西野 弘 出版・試験翻訳 小林 賢也 ・ITIL® 2011 edition 補完書籍 ファンデーション・ 浅野 芳郎 ハンドブックを出版します。（2014 年 12 月予定 ) 畔田 秀信 ・試験に関しては、AXELOS 社と連携し推進していき 伊豆 則夫 ます。 伊藤 清 一法師 淳 2. 会員サービス推進グループ 小山 條二 コンファレンス 徳地 隆弘 ・第 11 回コンファレンス /EXPO を、11 月 13 日 ( 木 ) 豊田 智洋 ～ 14( 金 ) ガーデンシティ品川にて開催します。 中村 輝雄 古川 公一 セミナ マイク・アルフォード ・会員の皆様に関心の高い内容や事例講演を中心に、 南 敏 昨年度以上の実施ができるように企画します。 山賀 裕二 ・東京と大阪地区以外にお住まいの方にもご覧いた 第 4 号議案 2014 年度監事選出 だけるよう WEB セミナを充実していきます。 58 関西支部 監査 ・関西エリアでの普及活動を目的としてセミナの開 ・年 2 回の内部監査を実施し、一層のアカウンタビ 催、新規分科会の設立を支援します。 リティを果たしていきます。 分科会 ＜質疑・応答＞ ・座長会を通して活動の情報共有、より円滑な分科 「質問」 会運営ができるよう支援します。 ユーザ側で現場を担当している。運用管理を考え ていきたいと思い、昨年入会したが、何をどうすれ 会報誌 ばよいのか分からない。初めての人へのガイドは ? ・ITIL®、IT サービスマネジメントに関する情報や、 導入現場からの生の声を発信します。 「回答」 it SMF Japan は、ITIL® を推進していく上での研 ・新企画、魅力ある記事掲載により会員サービスを 究を行ってきているが、初めて it SMF Japan に入会 向上させます。 ・第 7 回 itSMF Japan Newsletter Contribution Award された方にもっとご理解いただけるよう普及促進の を実施します。 面からもさらなる努力をしていきたい。セミナ、コ ンファレンス、White Paper で、ユーザ事例を紹介 WEB したり、現場でどのように ITIL® が使われているの ・it SMF Japan の WEB サイトを、より見やすく分か かを理解いただけるように、情報整備しているので、 りやすいものに構築し改善していきます。 ぜひ活用ください。 今年度は、ユーザ企業の現場の方々とのネットワ 3. プロモーショングループ ーキングを行い、ディスカッションができる場を作 国際プロモーション り、課題を共有していきたい。 ・it SMF International 関連の活動を強化していき また、初めて入会された方への、手引きも考えて ます。 いきたい。 ・国際会議への出席、AXELOS 社との連携、出版活動 まずは、ファンデーション資格を取得することか を通じた日本から海外への情報発信などを行いま ら始めてはどうか。また、資格取得と併せて書籍 す。 「ITIL® V3 ファンデーション」をお読みになること もお勧めしたい。 国内プロモーション / 国内渉外 / 広報 ・it SMF Japan の活動や、ITIL®、IT サービスマネ 「質問」 ジメントの有用性について広くユーザに広める活 会員を増やすために、もっと会員が動くようなや 動を行います。 り方、「会員からの紹介」があってもいい。特典を ・他団体との連携を強化し、ユーザ企業や他団体と 設け、たくさん紹介された方を表彰する、メールで の新たなネットワークづくりを行います。 広報をするなど行うとやりがいがあるのではない ・ITIL®/ITSM 関連の White Paper のプロモーション か。また、試験の受験料が高いのでもう少し普及す を強化します。 るためにも安くならないのだろうか。 ・Facebook のさらなる推進を行います。 「回答」 事務局 検討していきたい。受験料が高いことについては、 ・it SMF Japan 全体の活動を円滑に推進するために AXELOS 社にトレーニング会社などからも意見を聞き 他の担当業務と連携し実施していきます。 つつ、日本の意向を示したい。 ・会員拡大への施策の策定と実施ならびに中期計画 の策定に向けたサポートを行います。 「質問」 it SMF Japan は個人会員を増やしたいのか、団体 会員を増やしたいのか？ 59 また、議案書の都道府県別の会員分布表には 21 策の検討・実施 都道府県にしか会員がいない。まだまだ拡大の余地 4. 会員への情報発信力の強化（IT サービスマネジ があるのになぜ増えないのか。会員拡大についてプ メントの実態調査など） ロモートが足りないのではないか。対策、体制、施 5. 会員のネットワーキング支援の強化（他団体およ 策を見直す必要があるのではないか。 び会員間コミュニケーションの場の提供など） 「回答」 2014 年度予算 47 都道府県の半分にしか会員がいないことについ 収入：86,761,200 円 ては、課題と考えており、地方セミナを開催し広げ 支出：86,761,200 円 ていくことや WEB セミナなど地方でも活用できるコ ンテンツ整備など、他の対策も進めていきたい。 団体会員と個人会員の件についてはどちらという ことでなく、両者とも広げていきたい。 理事会の中でも会員拡大が最大の懸案事項であ る。福島監事からも会員が減少傾向であり会員増に ついての施策が必要であると指摘をいただいてお り、理事会でも中期的視野を含めて大胆な施策を検 討していきたいと思っている。会員増に対して本総 会でもアイデアをお寄せいただきありがとうござい ます。他にもいいご意見がありましたら事務局まで ぜひお寄せください。 議事終了のあと、新理事挨拶として、伊藤理事と 中村理事から新任の挨拶がありました。 「質問」 事業化推進の中では、予算の執行率が昨年度はゼ お忙しい中、it SMF Japan 第 11 回通常総会にご出 ロ、今年度は 2％となっている。具体的な計画を示 席いただいた皆様には、この場をお借りして御礼申 していく必要がある。昨年と比較すると実施率が減 し上げます。 っている。国内プロモーションも昨年と同じ文言が 掲載されており変化がない。抜本的に変えていく必 追記： 要があるのではないか。 総会終了後は、総会会場にて、会員同士、会員と 理事とのコミュニケーションの場として、懇親会を 「回答」 企画しました。約 60 名の方がご参加いただき、大 新たな取り組みとして、 会員間、 会員と理事間を含 変有意義で盛況な懇親会となりました。 め多方面でのネットワーキングを今年度から実施すべく、 総会、懇親会での会員からいただいたご意見は次 活動計画に反映させていく。 会員の方からもご意見や の活動に生かしていきたいと思っています。 アイディアをいただきたい。 また、 ITIL® の導入事例を 今後ともご支援よろしくお願いいたします。 White Paper にお寄せいただくなどのご協力もお願いし たい。 第 6 号議案 2014 年度予算 2013 年度予算は、以下の重点が報告されました。 1. 会員サービス強化による会員満足度の向上と、新 規会員拡大 2.ITIL® 2011 edition 日本語版のプロモーションお よび新規書籍の投入による書籍販売の拡大 3. コンファレンスの集客増、出展社増に向けた強化 60 編集後記 今月号には、「it SMF Japan Newsletter Contribution Award」の審査対象となる投稿が 6 件も集中 しました。今までで最多数です。どれも読み応えのある素晴らしい内容です。 さて、各種募集のお知らせでも案内していますが、次号（2014 年 10 月号）より、非会員の方から も投稿を募集することになりました。Award 最優秀賞の争奪戦が激しくなることが予想されますが、 一年を通じて多くの原稿が寄せられることを期待します。 （岡田） ■ご意見: Newsletterへのご意見・ご要望は、it SMF Japan 会報誌担当宛てにメ ールにてお送りください。 メールアドレス : info@itsmf-japan.org ■寄稿: ITサービスマネジメント導入、運営における経験を他の会員の皆様とシ ェアしていただける方を募集しております。ご協力いただける方は、it SMF Japan 会報誌担当宛てにメールにてご連絡ください。 メールアドレス: info@itsmf-japan.org ■広告: Newsletterは皆様の広告料で制作されています。広告掲載に興味をお持 ちの方は、it SMF Japan 事務局へご連絡ください。 メールアドレス: info@itsmf-japan.org ■it SMF Japan Newsletter (1月、4月、7月、10月発行) 2014年7月号 編集人: 畔田 秀信(特定非営利活動法人it SMF Japan 会報誌担当理事) 編集取りまとめ: 岡田 雄一郎（日本電気㈱） 編集委員(アイウエオ順): 岡田 雄一郎（日本電気㈱）、品田 京子 ( 日本アイ・ビー・エム㈱ )、 中井 秀有 ( 日本アイ・ビー・エム㈱ )、中川 悦子 (EXIN JAPAN)、 藤井 宏子 ( ㈱アビリティ・インタービジネス・ソリューションズ )、 八木 隆 ( ㈱日立製作所 ) 翻訳に協力いただいた方（敬称略）：林 智之（日本電気㈱） ■発行所 : 特定非営利活動法人 it SMF Japan 東京都港区芝 5-16-7 芝ビル 6F-A Tel: (03)5439-5591 Fax: (03)5439-5592 URL: www.itsmf-japan.org ■ ITIL® is a Registered Trade Mark of AXELOS Limited ■その他記載の組織名 ( 会社 / 団体 / 機関 )、製品名は、それぞれの会社 / 団体 の商標または登録商標です。 注 . 記事において記載の組織や製品に対し it SMF Japan がなんらの推奨を行うも のではありません。 ■本誌掲載記事の無断転載を禁じます。 61
© Copyright 2024 Paperzz
