Never stop,but keep providing IT SERVICE
～とまらない、サービスの運用と改善～
平成 22 年度
西日本システム運用当研究会
OW03「ITIL
®
V3 にみる、IT サービスのライフサイクル」研究グループ
ITIL
®
V3 は、IT サービスマネジメントをライフサイクルとして捉え管理するという考え方に拠 っている。具体的に言えば ITIL
®
V2 と比較してよりビジネスを意識し、IT サービスを改善（改革） しながらビジネスに貢献するという視点が強調されている。本論文では、この ITIL
®
V3 のライフ サイクルをただ「教科書」として捉えて終わるのではなく、さらに日本の企業にとってより効果 的に利用するための道を探る。
まずはグループ内で、改善するべき各社における問題意識を集約し、ITIL
®
に分類したところサ ービス・デザインの分野に集中した。サービス・デザインは費用対効果の高い IT サービスを設計 する工程であることから、ここでは IT サービス利用者（以下「利用者」）と IT サービス提供者（以 下「提供者」）との目標値の合意がその後の IT サービスの成否を分ける鍵となる。次に当研究会 メンバー各社の利用者との合意形成の状況を調査した。その結果、日々起こる問題は運用上の目 標値の設定が曖昧で利用者と共有できていないことから発生しているとして、両者の合意の上で サービス・デザインを確立するべきであるという結論に達した。しかし、厳密な金額による保障 が絡まない場合や社内のシステム部門・情報システム子会社等の立場によっては契約による明確 な目標値の設定が困難であるという現状が判明した。とはいえ、実際は利用者と提供者に数値化 こそされていないかもしれないが IT サービスレベル目標の基準は存在するはずである。
そこで、Beacon ユーザー会会員を対象に各社のサービスレベル設定の現状についてアンケート を採った。
サービスレベル合意（Service Level Agreement、以下「SLA」）締結の有無
利用者側と提供者側との目標値の共有について
利用者側と提供者側の改善活動の共有について アンケート結果を見ると、確かに SLA を締結し ITIL
®
を有効に活用していると思われる回答もあっ た。また、予想通り SLA の締結は無くとも利用者と目標値を共有し改善活動も共同で行っている との回答もあった。一方で、利用者との目標値と改善活動の共有はなく提供者だけで改善活動を 行っているという回答が目立った。ITIL
®
を導入したが効果が上がらなかった、改善活動がどうし ても実を結ばなかった理由は、利用者との意思疎通が十分ではなかったからである。
提供者は、ITIL
®
の中でもとりわけサービス・オペレーションに目がいきがちである。ITIL
®
にな らってインシデント管理やサービスデスクを導入してみたものの、そもそも利用者との目標値の 合意がない状態でサービスの質や効率性を改善していくことには自ずと限界があった。利用者・ 提供者の双方が、日々起こっている課題の解決をライフサイクルとして継続的に共有できれば、 ノウハウも蓄積されサービス・デザインの段階で事前に課題を解消できる可能性も広がる。課題 として列挙された利用者のニーズを、いかに上手く拾って改善するか。目指すべきは、利用者・ 提供者も含めた全体でベクトルを合わせて会社や部門としてより質の高いサービスや製品を提供 し、お客様の業務改善につなげることである。サービスは、常に止まらずに提供し続けるもので ある。改善も止まらない。提供者は積極的に利用者とコミュニケーションを取ることこそが重要 である。それこそが IT サービスのライフサイクルであると我々は考える。
－ 目 次 －
1. IT サービスとは ... 1
1.1. ITIL ® の定義... 1
1.2. IT サービス... 1
1.3. サービスの運用と改善... 2
2. IT サービス提供者側の問題意識 ... 3
2.1. 各社における問題意識(各社の課題)... 3
2.2. 各社の課題を ITIL ® で分類... 4
2.3. サービス・デザインの重要性... 5
2.4. SLA の定義とサービスレベル管理... 6
3. 実態調査 ... 7
3.1. IT サービス提供の四形態... 7
3.2. アンケートの結果として... 9
3.3. ヒアリングをふまえて... 13
3.4. 検証のまとめ... 14
4. サービスのライフサイクルにむけて ... 15
4.1. IT サービス利用者の想い... 15
4.2. IT サービス提供者の想い... 15
4.3. IT サービス利用者と IT サービス提供者の意識が歩み寄るには... 16
5. まとめ ... 17
－ 資料編 －
1. メンバー紹介・活動履歴 ... 19
2. 参考文献 ... 20
3. 付録 ... 21
1. IT サービスとは
本章では一般的に定義されている ITIL
®
や IT サービスを説明する。ITIL
®
や IT サービスという 言葉を耳にすると難しいものだと考えがちであり実際、当研究会メンバー間でも少しずつ認識が ずれていた。そこでまずは共通認識として教科書的に ITIL
®
を定義した。 1.1. ITIL
®
の定義
ITIL
®
とは「IT サービスの『ベストプラクティス』を集積した書籍群(Library)」として定義さ れる。そしてその目的としては「ビジネスおよびその顧客の現在と将来のニーズに一致した IT サ ービスの提供」、「IT サービスの品質の向上」、「IT サービス提供の長期的なコストの削減」と言わ れている。つまりは IT の利用そのものであり、IT の資産運用であると考えられる。その資産を 運用することで効果を上げることに他ならない。
しかしながら実際の ITIL
®
はフレームワークあるいは考え方やベストプラクティス（良い事例）に とどまり、自分たちの仕事にどのように合わせていくかというところになると具体的なイメージ を考えるにはとても難しい。
また、ITIL
®
が普及し始めた当初のベストプラクティスである ITIL
®
V2 のフォーカスである品質と 効率性を目的とした運用の改善だけでは IT サービス全体の改善にはつながらないという現状も あった。そして ITIL
®
V2 の良い部分を残しつつ、サービス・ライフサイクルの視点から再構成さ れたのが ITIL
®
V3 である。この ITIL
®
V3 の根底となるのがサービス指向のアプローチである。 1.2. IT サービス
ITIL
®
を議論するうえで欠かせないのが「IT サービス」という言葉の定義である。一般的に業務 をサポートするコンピュータのシステム全般およびマネージメントのことをひとくくりにして IT サービスと呼んでいることが多い。たとえば顧客から見ると基幹システムであれ、それを取り巻 くシステムであれ、情報として提供されるすべてのものが IT サービスということになる。顧客に とってはそれがどのように創出され、費用がかけられているかについてのリスクや責任を負わず に、サービスを享受することでより良いビジネス上の成果を実現することだと考える。このこと からも IT サービス提供者が提供し得る「IT サービス」が何かを定義することが必要になってく る。それでも IT サービス提供者の現場はいつも疲弊している傾向が強い。家に帰っても電話がか かってくることもあれば、システム構築したらゴールインしたと勘違いしてトラブル対応で苦労 することも多い。しかしながら何を基準にしていいのかわからないので後追いの仕事になり、工 数やその場の緊急対応が増えるといった現実から逃れられない。
本来ならば IT は利用者が安定して効果の高い状態で利用でき、IT サービスを提供するベンダー のエンジニアや保守担当、営業担当は安心して携帯を切って週末や休暇を過ごしたり、寝る為に 存在するものである思う。
1.3. サービスの運用と改善
『運用』という言葉を聞くと ITIL
®
V3 ではどうしても「サービス・オペレーション」のプロセ スが中心になってしまいがちである。確かに「サービス・オペレーション」は効果的、効率的な サービスの運用を通じて顧客と IT サービス提供者の価値を向上させるのを目的としたプロセス である。しかしながら効果的、効率的なサービスを提供し続けるには事業や社会環境に応じた改 善が必要になってくる。効果的、効率的にサービスを維持するためのサービス改善の根幹は提供 するサービスの測定であるといえるだろう。そのためにも運用を開始する前に対象とするサービ スを定義し、どうあるべきか（目標・ビジョン）ということを明確にすべきであり、そして現状 を把握し測定可能な目標を設定する。それを行ったうえでどのようにすれば目標にたどり着くか を考える必要がある。
つまり目指すゴールに向かって ITIL
®
の継続的改善プロセスの 7 ステップを試みる。 (1) 測定すべきものの定義
(2) 測定できるものの定義 (3) データの収集
(4) データの処理 (5) データの分析
(6) 情報、アセスメントの要約、処理計画などの提示と利用 (7) 是正処置の実施
この 7 ステップの改善プロセスは継続的サービス改善の土台でありサービス・ライフサイクル の全体の改善において中心的な役割を果たす。
以上のことから当研究会では「ITIL
®
V3 に見る IT サービスのライフサイクル」というテーマの なかで継続的な改善がどのように実現されるのかというところを中心に取り組んだ。
まず、2 章では、IT サービス提供者として抱える問題意識の抽出を行い、それを ITIL
®
にあては めて分析・分類する。
また、3 章ではアンケート調査やヒアリングを通して当研究会メンバー以外の企業ではどのよ うな形で運用が行われているのかを検証する。
そして 4 章において IT サービス利用者側、IT サービス提供者側からどのように「ライフサイ クル」を考えれば効果的、効率的なサービスを提供し続けられるのかを追及する。
2. IT サービス提供者側の問題意識
本章では、研究を進めていくにあたり、日頃の業務で当研究会メンバーが抱えている問題意識 について抽出し、抽出した結果を ITIL
®
にあてはめ分析・分類を行っていく。 2.1. 各社における問題意識(各社の課題)
当研究会メンバーは、業種こそ違いがあるものの情報システム部門に所属しており、実際に ITIL
®
を導入し運用を行っているメンバーもいれば、現在導入のために運用方法の検討を行ってい るメンバーもいる。そこで、当研究会メンバーが各社で日頃から抱えている改善すべき問題意識 の抽出を行った。
(1) イベント発生後に DB へ登録がすぐにできない。
(2) インシデントのエスカレーションは行えるが情報の更新が遅れる。 (3) 手順書（マニュアル）にない対応を依頼される。
(4) 課員内ではお互いに何をしているか把握しているが資料・データとして出てこない。 (5) 各部署の考え方の違いから、IT サービス戦略を本部と部門の間で共有できていない。 (6) どの業務をどこまでするのか範囲が定かではない。
(7) 情報システム部門自体がイメージ依存型から抜けられていない。
(8) 利用部門の KPI（重要業績評価指標）が出てこない。システム活用の効果が見えにくい。 (9) システム変更などの際、属人化を避けるためのフォーマットを作成している。
(10)人によりサービスレベルの考え方が様々である。
(11)システムとしての在り方、範囲を明確に打ち出せていない。 以上が、当研究会メンバーが日頃抱えている問題意識である。
2.2. 各社の課題を ITIL
®
で分類
当研究会メンバーがそれぞれの運用現場で抱えている問題意識を持ち寄り、ITIL
®
にあてはめ分 類・検証を行った。
当研究会メンバーの抱える問題意識 SS SD ST SO CSI
1 イベント発生後に DB へ登録がすぐにできない。 ●
2 インシデントのエスカレーションは行えるが情報の更新が遅れる。 ●
3 手順書（マニュアル）にない対応を依頼される。 ●
4 課員内ではお互いに何をしているか把握しているが資料・データとして出てこない。 ● 5 各部署の考え方の違いから、IT サービス戦略を本部と部門の間で共有できていない。 ● ● 6 システム部門がどの業務をどこまでするのか範囲が定かではない。 ● ● 7 情報システム部門自体がイメージ依存型から抜けられていない。 ● ● 8 利用部門の KPI(重要業績評価指標)が出てこない。システム活用の効果が見えにくい。 ● 9 システム変更などの際、属人化を避けるためのフォーマットを作成している ●
10 人によりサービスレベルの考え方が様々である。 ● ●
11 システムとしての在り方、範囲を明確に打ち出せていない。 ● ●
※ SS（サービス・ストラテジ）、SD（サービス・デザイン）、ST（サービス・トランジション）、SO（サービス・オペレーション）、CSI（継続的なサービス改善）
表 2.2-1 当研究会メンバーの問題意識と ITIL
®
のライフサイクルとの関係
表 2.2-1 当研究会メンバーの問題意識と ITIL®のライフサイクルとの関係から見てとれるよう に、当研究会メンバーが日々の日常業務で抱えている問題が、サービス・デザインに集中してい る事が判った。これは、各社での業務（サービス）の具体的な内容を決めるのは「サービス・デ ザイン」であり、またビジネスのニーズをサービスに変換する役割を果たすのもまた「サービス・ デザイン」だからである。
そこで、深夜にインシデントが発生した時、オペレーターは IT サービス利用者の緊急連絡先に 問題発生の一報を入れるというオペレーションから生じる問題について考えてみる。一つは、イ ンシデント登録漏れやエスカレーション漏れなどのオペレーションの問題だろう。これは文字通 りオペレーションの問題であり、現場の改善や運用やツール等で解決可能である。次に考えられ るのは、緊急連絡リスト通りに電話をかけても担当者が捉まらず、リストを超えて四方八方に電 話を繰り返すというケースだろう。これは IT サービス利用者の都合により、決められたオペレー ションの枠を超えざるをえず現場に過度な負担がかかってしまうケースである。さらに、その IT サービス利用者から「その程度の障害なら明日の朝の連絡でよかったのに」と言われたとしよう。 これは、24 時間 365 日のつもりで運用していたオペレーターと IT サービス利用者の目標値の合 意がないことに起因する。緊急連絡リストで担当者が捉まらなかったのも、そもそもこの運用時 間の目標値の合意がなかったからである。
この問題のように、確かにオペレーション上起こった問題には違いないが、原因がオペレーシ ョンのレベルを越え IT サービス利用者との関係の中で問題が発生しているケース、24 時間 365 日というサービスレベルの取決めをした時点、つまりサービス・デザイン段階にトラブルの種が 撒かれているケースに、当研究会は着目している。
これらのことから、当研究会メンバー各社の問題意識の原因は以下の 2 点に集約できる。
改善活動を IT サービス提供者側だけで行っている。
目標値が IT サービス利用者と共有できていない。
既に述べたように、当研究会メンバー各社の問題はサービス・デザインに関係するものが集中 している。このことからサービス・デザインの重要性をきちんと理解することが問題を解決する ポイントになるのではないかと考えた。次節では、サービス・デザインの重要性について検討し たことを述べる。
2.3. サービス・デザインの重要性
サービス・デザインは IT インフラストラクチャ、アプリケーションといった IT サービスのリ ソース設計のみならず、IT サービスを提供・管理するためのプロセスや IT サービスの効率性や 有効性を評価する測定基準などの設定も対象となる。サービス・デザインは費用対効果の高い IT サービスを設計する工程であることから、IT サービス利用者と IT サービス提供者との合意がそ の後の IT サービスの成否を分ける重要な鍵となる。これらのことから日々起こっている各社の問 題はサービス・デザイン（特にサービスレベル管理プロセス）の設計段階での提供レベルが IT サ ービス利用者と IT サービス提供者との間で合意できていないことから発生しているのではない かと仮説をたてた。
ITIL
®
では、IT サービス利用者と IT サービス提供者との間でサービスの水準について合意する ための手段として SLA とサービスレベル管理が定義されており、それらを上手く活用できれば当 研究会メンバーが抱える問題を解決できると考えた。そこで次節では、SLA とサービスレベル管 理について追求していく。
2.4. SLA の定義とサービスレベル管理
一般に SLA とは、IT サービス利用者と IT サービス提供者の間でサービス内容・範囲・品質の 提供水準を測定可能な形で決め、合意を形成することである。または、それらの合意を文書化し たものあるいは契約書を指す。SLA には、合意した水準に至らない場合のペナルティについて書 かれる場合もある。
SLA のメリットとして、IT サービス利用者にとっては提供されるサービスが自らの要求に沿っ たものであることが明文化される、IT サービス提供者にとっては達成すべき水準が明らかになる ことからサービス設計を適正化し過剰サービスを避けることができる、両者にとってはサービス に関するイメージを共有できる、IT サービス利用者と IT サービス提供者の役割分担・責任範囲 が明確になるといったことが挙げられる。
ITIL
®
V3 においても SLA についての記述があるが、上記の一般的な契約としての SLA とは若干 定義が異なる。ITIL
®
V3 における SLA は、IT サービス提供部門と利用部門との間の社内合意文書 と定義されている。契約というより、社内でのサービスレベル目標という性質が色濃い。 ITIL
®
V3 では、契約を結ぶ・SLA を締結することそのものに比重を置いておらず、むしろその過 程で IT サービス利用者に IT サービスの姿を正しく理解してもらうこと、IT サービス利用者との 間に円滑なコミュニケーションがあることが重視されている。ただ、ITIL
®
には上述のような書か れかたがされているとはいえ、まだなお SLA という言葉が持つ響きは重く、「ペナルティ」という ニュアンスを醸すことから SLA 導入は難しいのではと考えた。
とはいえ、実際は IT サービス利用者と IT サービス提供者で数値化こそされていないかもしれ ないが IT サービスレベル目標の基準はあるはずである。そして、その目標値を日々の改善に活用 しているケースもあるはずである。SLA を結ばずとも、IT サービス利用者と IT サービス提供者の コミュニケーションを活発化し、IT サービスの正しい姿をお互いに模索している企業も存在する はずである。ITIL
®
のサービスレベル管理が指摘しているのもこの IT サービス利用者と IT サービ ス提供者とのコミュニケーションの重要性であり、SLA を結ぶことと ITIL
®
のサービスレベル管理 の実践とは、必ずしもイコールではないのではないか。
この疑問に答えるため、次章では、各企業が IT サービス提供者と IT サービス利用者の間で IT サービス提供の内容、範囲、品質（サービスレベル）などの目標がどのように共有されているか。 また、共同で改善活動を行っているかについて、グループ内での議論、アンケートを通じて検証 するとともに、SLA を有効に活用し IT サービスのライフサイクルを効果的に運用している事例を 紹介する。
3. 実態調査
前章の最後で述べた SLA も目標値の合意のいずれも、結ぶ相手は IT サービス利用者であること に変わりはない。だが、相手である IT サービス利用者が IT サービス提供者にとってどのような 立場であるのかによって、SLA という契約を結ぶべきなのか合意で構わないのか事情は異なって くる。
そこでまず、IT サービス利用者と IT サービス提供者の関係にはどのようなパターンがあるか を分析していく。そして、パターンごとに SLA が適するか適さないか。合意形成にどのような問 題があるかについて述べる。
3.1. IT サービス提供の四形態
IT サービス利用者と IT サービス提供者の関係のパターンを考えたところ、図 3.1-1に示す四 つのパターンに分類できた。
図 3.1-1 IT サービス提供の四形態 (1) 企業内の場合
(2) 顧客の場合（IT サービス提供者がデータセンター、SI 企業など） (3) 親子会社の場合Ⅰ（子会社が親会社の情報システム部門）
(4) 親子会社の場合Ⅱ（親会社の情報システム部門がビジネス部門と SLA を結ぶ場合） (1) 企業内の場合
IT サービス提供に金銭授受が発生しないため、SLA 締結は難しい。契約と大げさに構え ては利用部門との関係がよそよそしく、ぎこちなくなる。例えばエンドユーザーも利用す る WEB システムの運用時間を 9 時～17 時と SLA で定めたとして、ある時ビジネス部門から 時間外利用の要求が出されたとする。 情報システム部門は SLA という「契約」を盾にこの 要求を突っぱねてはならない。お客様はエンドユーザーであり、決して利用部門ではない。 全社一丸となってお客様のニーズに応えることを目指すべきである。もし、目標の合意が なければ、前述のシステムなら滅多に時間外利用がないのに、情報システム部門が勝手に 24 時間 365 日対応で過剰な設計をしてしまうかもしれない。
企業内 顧客
（ITサービス利用者）
(1)
SLA
データセンター SI 企業
（ITサービス提供者） ビジネス部門
（ITサービス利用者）
情報システム部門
（ITサービス提供者）
SLA
(2)
親会社
（ITサービス利用者）
SLA
情報システム子会社
（ITサービス提供者）
(3)
親会社
OLA 情報システム子会社
（ITサービス提供者）
(4)
ビジネス部門
（ITサービス利用者）
情報システム部門
SLA
逆にビジネス部門やお客様は 24 時間 365 日のつもりだったのに、情報システム部門は 9 時
～17 時程度の構成を組んでしまうかもしれない。従って、目標の合意自体には大きな意義 があり、もし、運用目標に誤りがあったなら、IT サービスの利用部門・提供部門の双方が 協力して改善していけるような柔軟な目標設定が望ましい。
(2) 顧客の場合（IT サービス提供者がデータセンター・SI 企業など）
IT サービス提供にあたり金銭授受が発生するため、SLA 契約が馴染む。(1)「企業内の場 合」で想定した WEB システムで同様の例外対応を迫られた場合、IT サービス提供者は SLA 契約を理由に対応を断ることが可能だろう。一方、IT サービス利用者は IT サービス提供 者に適正な対価を支払うことで、24 時間 365 日対応を要求することが可能である。SLA 契 約という合意を形成することにより、双方の責任範囲や対応可能範囲が明確になる。IT サ ービス提供者としては、顧客のニーズを逃さないために定期的な訪問や月次報告などのコ ミュニケーションの機会を設けることが重要である。
(3) 親子会社の場合Ⅰ（子会社が親会社の情報システム部門）
(1)「企業内の場合」と(2)「顧客の場合」の中間のような形態で、企業内の場合・顧客 の場合両方の問題が生じやすい。IT サービス利用者との関係が社内部門ほど密接ではなく、 完全な顧客ほど厳密に契約が取り交わされないがゆえに、過剰サービス・サービス不足の 恐れがある。サービス提供にあたっては、SLA を含めた運用目標の IT サービス利用者との 共有が大変重要である。
(4) 親子会社の場合Ⅱ（親会社の情報システム部門がビジネス部門と SLA を結ぶ場合） (3)「親子会社の場合Ⅰ」から派生したものと言えるが、サービスレベル合意の形成は親 会社の情報システム部門が利用部門と行い、IT サービス提供者である子会社はそのシステ ムの運用を請け負う OLA 契約を結ぶ。この場合、IT サービス提供者である情報システム子 会社はその運用についてのみ責任を負う。
以上の IT サービス利用者と IT サービス提供者の関係の分類を通じて、IT サービス利用者との サービスレベルの合意形成は大変重要であることがわかった。SLA は確かに有効な IT サービス利 用者との合意形成の手段だが、SLA が馴染むケースと SLA を必要としないケースがあることもわ かった。
次節では、Beacon ユーザー会会員へのアンケートの結果から、IT サービス利用者と IT サービ ス提供者の関係についての分析を行う。
3.2. アンケートの結果として
IT サービス利用者と IT サービス提供者の関係について、表 3.2-1 に示す 5 問からなるアンケ ートを実施した。
Q1. あなたのご担当は IT サービス利用者、IT サービス提供者のどちらですか?
Q2. 御社において IT サービス利用者と提供者との間で運用に関して目標値を共有されていますか? Q3. 御社において IT サービス利用者と提供者との間で明確な SLA を締結していますか?
Q4. 御社においてシステム運用に関して IT サービス利用者と提供者が一緒に改善活動をされていますか? Q5. 御社において改善活動を実施するサイクルを教えてください。
表 3.2-1 アンケート項目
その結果 45 名（内訳：IT サービス利用者 12 名、IT サービス提供者 33 名）から回答を得た。 回答全体については、添付資料を参照していただきたい。
ここではアンケートの集約結果について述べる。
Q2「IT サービス利用者と IT サービス提供者との間で運用に関して目標値を共有しているか?」 という質問に対する回答は図 3.2-1 アンケート結果（目標値の共有）のとおりであった。
図 3.2-1 アンケート結果（目標値の共有）
IT サービス利用者側と IT サービス提供者側共にほぼ同様の結果となった。目標値を共有して いない企業が共有している企業より多少なり多かった。企業内情報システム部門の場合、IT サー ビスに関する目標値が、自部門に限定された目標になるケースもあるかと思われ、部門を跨いだ 目標値の共有が難しいケースが存在すると思われる。
ITサービス利用者
ITサービス提供者
4件(33%) 5件(42%) 3件(25%)
12件(36%) 16件(48%) 5件(15%)
している していない わからない
Q3「IT サービス利用者と IT サービス提供者との間で明確な SLA を締結しているか?」という質 問に対する回答は図 3.2-2 アンケート結果（SLA の締結）のとおりであった。
図 3.2-2 アンケート結果（SLA の締結）
IT サービス利用者側として SLA を締結しているという意識が半々で分かれたが、IT サービス利 用者側としては締結していないという意識が高い。企業内情報システム部門の場合は金銭授受が 発生しないため、明確な SLA 締結は難しい。企業内で SLA を締結したとしても、何らかのトラブ ルが生じている以上、利用者も提供者も契約などをこえ理屈抜きに解決する必要があるだろう。 こうした暗黙の了解が良い方向に働けばよいが、曖昧な運用となっては意味が無い。
Q4「システム運用に関して IT サービス利用者と IT サービス提供者が一緒に改善活動をしてい るか?」という質問に対する回答は図 3.2-3 アンケート結果（IT サービス利用者と IT サービス 提供者との共同改善活動）のとおりであった。
図 3.2-3 アンケート結果（IT サービス利用者と IT サービス提供者との共同改善活動） IT サービス利用者・IT サービス提供者共に共同で改善活動を行っていると答えた企業が多かっ た。IT サービス利用者・提供者ともに IT サービスに関して、何らかの改善の必要性を感じてい るものと思われる。
Q5「改善活動を実施するサイクル」という質問に対する回答には、IT サービス利用者側は定期 的な改善の実施が少なく、不定期に問題発生の都度行われる傾向である。IT サービス提供者側に ついては改善活動のサイクルは定期的に行う必要があると考えている傾向にある。四半期、半年、 一年など、経営の期に準じるケースが多かった。「その他」の回答には、不定期や都度というコメ ントが多かった。場当たり的な対応なのか、逆に安定稼動なのかと思われる。
これらのアンケート結果を元に、当研究会が特に注目した点について分析を行った。 ITサービス利用者
ITサービス提供者
4件(33%) 4件(33%) 4件(33%)
8件(24%) 20件(61%) 5件(15%)
している していない わからない
ITサービス利用者 ITサービス提供者
6件(50%) 3件(25%) 3件(25%)
19件(58%) 10件(30%) (12%) 4件
している していない わからない
まず、IT サービス利用者側からみた目標値の共有と共同改善活動との関係について着目した。
Yes No
目標値を共有している
4 5
Yes No Yes No 改善活動を共同で実施している
3 1 2 3
表 3.2-2 IT サービス利用者からみた目標値の共有と共同改善活動
IT サービス利用者側 9 名の回答内容（表 3.2-2）を見たところ、いずれの問いに対しても回答 は割れた。その中でも改善活動を実施するサイクルについては「不定期」や「問題発生時」とい った回答が目立った。これは安定稼動のシステムなのか、あるいは回答数が少ないため正確とは いえないが、システムがうまく動いてくれていれば問題ない、トラブルさえ無ければ特に費用を かけてまで定期的に改善に取り組もうという雰囲気が少ないというように感じられる。やはり、 IT サービス利用者側にとってはコストをかけて導入した IT サービスは動いて当たり前という思 いがあり、IT サービス提供者側と比べると若干の温度差があるように感じられた。
次に SLA 締結の有無と目標値の共有についてみると、表 3.2-3のようになった。 Yes No(不明含む) 目標値を共有している
16 29
Yes No Yes No SLA を締結している
9 7 3 26
表 3.2-3 SLA の締結と目標値の共有認識
IT サービス利用者と IT サービス提供者で目標値を共有しているとの回答 16 のうち、SLA を締 結していないとの回答が半数近い 7 あった。SLA 締結が難しい企業内情報システム部門などの場 合、SLA の契約的な要素を抜きにした、文字通りのサービスレベル同意＝目標値の共有がされて いれば問題ないだろう。現に、目標値を共有しているとの回答の大半が、改善活動も共同で実施 していると答えている。（表 3.2-4）これは、重要なのは SLA そのものではなく IT サービス利用 者との目標値の共有なのだということを示している。
一方、回答の中で特に問題視したのが「目標が共有できていないにも関わらず、共同で改善し ている」という回答が 12 あったことである。（表 3.2-4 ）これは全体の 27%に当たる。
Yes No
目標値を共有している
16 21
Yes No（不明） Yes No（不明） 改善活動を共同で実施している
11 4(1) 12 8(1)
表 3.2-4 全体からみた目標値の共有と共同改善活動
測定と管理に関する格言の中に『定義できないものは測定できない。測定できないものは制御 できない。制御できないものは管理できない。』というものがある。「事業のこの部分について○
○を実現するために△△をこうする」というような目標が定義されて IT サービス利用者・提供者 の双方でその目標が共有できていなければ、コントロールすることも管理することも困難である。 共有化されていない中で改善活動を実施しても本来の目的に合った改善はなかなか難しい。 どの企業においても目指すものは経営課題に取り組みながら業務の標準化と効率化を繰り返し行 い、人・モノ・金という経営資源を巧みに配置・投下しながら顧客満足度をアップし、ひいては 高収益体質を構築していくことで、いかに持続可能な経営を行うかにある。数値化された目的や 目標もなく改善を行うことは、いたずらにコスト高を招くだけではないだろうか。
また、目標値が共有されていないとの回答が 21（全体の 57%）あった。この場合、IT サービス 提供者の都合によって、IT サービス利用者からのサービス要請や苦情などが部門ごとに管理・対 処されてしまいがちである。そのため IT サービス利用者に対し、考え方によってはスピーディで はない対応がされてしまう恐れがある。
3.3. ヒアリングをふまえて
当研究会メンバーだけでは SLA が果たして有効なものなのか、ただしがらみになっているだけ ではないか、という話になり SLA を締結している A 社に話を伺った。
A 社が SLA を導入した目的はコスト削減を考えてのことで、いろいろな無駄を取り除くことでコ スト削減を図っているとの話であった。
SLA を導入しコスト削減をどのように行っているのかは以下である。 (1) 投資対効果の適正化
IT サービス利用者は受けたいサービスの内容や水準等の費用対効果を十分に考慮し、サ ービス要求仕様を明確に設定する。
それに対し提供側は、システム運用や保守・必要要員（工数）積上げ計算・前年実績ベ ースから翌年度工数を予測したうえで、求められたサービスを安価に提供できるように最 大限努力する。
(2) 責任・役割分担の明確化
自己責任意識の高揚・システム仕様の把握・要求仕様の明確化をすることで、不要な問 い合わせを軽減する。
作業品質維持・障害の未然防止，早期発見・効率的な運用環境構築を行っている。 (3) コミュニケーション強化
サービス利用側・サービス提供側共に人材交流を図り、それぞれが持っているノウハウ の共用化を図る事で人材育成を行い、尚且つコミュニケーションを強化し、無駄な人材（工 数）のコスト削減を行っている。
「3.1 IT サービス提供の四形態」でも挙げられた IT サービス提供者と IT サービス利用者で目 標を共有しているかについても伺うことができた。
A 社では、幾つかの項目で目標設定値が決められていた。
A 社の場合はグループ会社との SLA 締結とのことから、目標値が未達成の場合でもペナルティが 無いとのことだった。
だが、目標値を設定することでそれに向けての水準を決めていることが解った。また、問題解決 に向けて一定周期の改善サイクル・問題解決会議・人材交流などを行っていることが解った。 その中でも、問題解決会議では顧客をふまえた部門長レベルの会議と現場レベルの会議を行い、 IT サービス利用者と IT サービス提供者が一体となって問題解決に取り組んでいるとのことだっ た。
このことから、A 社は ITIL
®
の“ベストプラクティス”非常にきれいな IT サービス改善のライ フサイクルが回っている好例であると考えられる。
3.4. 検証のまとめ
アンケート調査の結果から、「改善活動を IT サービス提供者側だけで行っている」および「目 標値が IT サービス利用者と IT サービス提供者との間で共有できていない」という問題を抱えて いる傾向にあることが解った。一方でこれら二つの問題を克服している企業は、IT サービス改善 のライフサイクルが見事に回っていることも解った。ITIL
®
を導入したけど効果が上がらない、ま たは改善活動はしているけれども効果が上がらない、というケースは同様の問題が原因なのでは ないか。これらの問題は 2 章で当研究会メンバーの問題意識の原因として挙げた点と一致する。 これを解決するためには、IT サービス利用者と IT サービス提供者の間で良好なコミュニケーシ ョンを取ることが最も重要である。二つの問題点について、以下にまとめる。
(1) 改善活動を IT サービス提供者側だけで行っている
何らかの改善を始める場合、手を付けやすい身の回りから始めるのが常道である。まず は、自分個人の改善、次に周りの数人のワークグループ、次に課内で改善、部内で改善と 改善の輪は広がる。しかし、なかなか部門を超えて、または親子関係を超えての改善活動 に繋げるのは困難だったのではないか。社内の情報システム部門の場合、「情報システム部 門が掲げた今期の目標・方針を達成する」となりやすく、他の部門と連携しての IT サービ スの全社的な目標という視点が欠けているケースもあるだろう。また、部門目標が会社の ビジネスの方向性と合致しているかの検証もできない。本来、情報システム部門が提供す る IT サービスは、インフラを含めてそもそもは IT サービス利用者のために存在している。
「改善を続けたが、結局、使われないサービスになった。」という失敗は IT サービス利用 者を見なかったためだろう。改善は、身の回りの小さなことからコツコツというイメージ もあるが、まずは IT サービス利用者からヒアリングした要求に沿った大局的な改善計画を 立て、その上でコツコツと改善を積み上げていくことが重要と考える。
(2) 目標値が IT サービス利用者と共有できていない
改善活動は IT サービス利用者と共に行っているが、目標値が共有されていないケースが アンケート結果に目立った。本来改善とは、ある指標が活動を経てどれくらい変わったか を測ることである。この指標・目標値が共有されていなければ改善活動自体ができない。 またゴールも見えない。ITIL
®
などの運用改善フレームワークを導入している、または定例 報告会議を持っているにも関わらず効果が現れないのは、IT サービス提供の目標値の管理 ができていないためである。
IT サービス利用者・IT サービス提供者の双方が、日々起こっている課題の解決をライフ サイクルとして継続的に共有できれば、ノウハウも蓄積されサービス・デザインの段階で 事前に課題を解消できる可能性も広がる。課題として列挙された IT サービス利用者のニー ズをいかに上手く拾って改善するか。目指すべきは、会社や部門としてより質の高いサー
4. サービスのライフサイクルにむけて
IT サービスを効果的かつ効率的に運用するには、IT サービス利用者との目標値の合意と IT サ ービス利用者と共同で改善活動を行うことが必要であるとわかった。今一度、IT サービス利用者 と IT サービス提供者の立場を整理し、両者が歩み寄ることで、より良い IT サービスのライフサ イクルを築いていく方法を考えていきたい。
4.1. IT サービス利用者の想い
IT サービス利用者の中には、きちんと目標値・共同の改善活動・改善サイクルを定めてライフ サイクルに取り組んでいる IT サービス利用者もいる。
目標値・共同の改善活動・改善サイクルを定め、IT サービス利用者と IT サービス提供者の意見 を交換することで、問題の早期発見や予防といったイレギュラーな事態に対応することができる。 ITIL
®
の観点からすると、このようにライフサイクルを考えながら取り組むことが、問題解決やサ ービスの安定稼働の第一歩につながる。
IT サービス利用者は IT サービス提供者に疑問や不満を意見することで、IT サービス利用者と IT サービス提供者が双方の考え方や状況を把握でき、改善活動に取り組むことができる。
しかし IT サービス利用者としては、サービス（システム）が上手くまわってさえいればトラブ ル発生時に改善すればよく、資金を投じてまで改善する必要性は感じないという考え方や、サー ビス（システム）は動いている事が当たり前という考え方が根強く残っているのが現状のようで ある。
4.2. IT サービス提供者の想い
IT サービス提供者の大半は、改善サイクルを定めて活動している。しかしながら現状は問題が 発生してからの対応や、必要に応じて対応するなどオペレーションレベルでの改善に留まってお り、根本的な問題解決には至っていないのが現状である。
なぜならば、共同の改善活動や改善サイクルは行っているが、目標値の設定を行っていない IT サ ービス提供者が多いからであり、目標値の設定を行っていないことによって目指すべきゴールが 初めから見えていない。もしくは IT サービス提供者と IT サービス利用者で求められているサー ビス（システム）の質等が共有できていないからである。
ライフサイクルを考える中で最も重要なのは、IT サービス利用者の目的にあったサービス（シ ステム）を安定的に提供することである。そのための問題管理やインシデント管理ではあるが、 果たして IT サービス提供者は IT サービス利用者の目的に合ったサービス（システム）を提供で きているのかは、IT サービス利用者の立場に立たない限り不明である。
IT サービス利用者の目的にあったサービス（システム）を安定的に提供し続けるためには、IT サービス利用者と IT サービス提供者の合意の上で改善活動を進めていくことが大切である。
4.3. IT サービス利用者と IT サービス提供者の意識が歩み寄るには
上記のように IT サービス利用者側は必要な情報がリスクや責任を負わずに、サービスが享受で きてさえいれば、お金や時間をかけて改善する必要性は感じていないのだろう。しかしながらト ラブルや情報の差異が起こったときには『是正処置はどうするか?』『どう改善すべきか?』という 議論になる。また、IT サービス提供者側においては改善しなければいけないという認識はあって も、平常時は『お金がでないから』『時間がない』とかの理由によりなかなか改善に着手すること はない様である。またトラブルが発生しても『今は回復させることが先決』、『とにかく原因を取 り除く』といったところに意識はいきがちである。また、システムダウンなどの様に全社的なト ラブルでもない局所的なものではそのトラブルのインパクト（個人や事業への影響）が IT サービ ス提供者側ではなかなか感じ取ることは難しい。そのようなこともあって、一概にトラブルと言 っても IT サービス利用者側と IT サービス提供者側の温度差があるのであり、平時の日常の業務 の中で効果的で効率的な改善を行っていくということはかなり難しいように見える。
しかしながら IT サービスに対して継続的改善を実施あるいは試みている企業があることもわ かった。このような企業は事業目的に適したサービスを提供することでパフォーマンスの無駄と 不足を解消している。すべての IT サービス利用者が 24 時間 365 日同じサービスを受けたいわけ ではなく、IT サービス利用者は目的にあったサービスを必要とするときに欲しいだけである。そ の求められたサービスを安価に提供できるよう最大限の努力をすることが IT サービス提供者側 の価値である。このように合意し、提供されるサービスに対して IT サービス提供者側と IT サー ビス利用者側が同じ方向性を意識することが継続的改善につながっていく。
IT サービス利用者と IT サービス提供者の意識が歩み寄るためには自社あるいは顧客の事業目 的を共有し、そのためになすべきことを一定のサイクルで見直していくことが必要である。
5. まとめ
ITIL
®
V3 ではライフサイクルの視点が強調されている。ライフサイクルの視点が必要なのは、 ビジネス戦略と IT サービス戦略の整合性をとらなければならないことを重要視しているからで ある。IT サービスは、ハードウェアとソフトウェアとドキュメント、それらを運用する人材から 構成されている。これら IT サービスを所有（本番化）した時点から、費用が発生し、陳腐化が始 まり、変更が待ち受けるという状態になる。この状況への効果的かつ効率的な対応として、継続 的な改善が必要であることを IT サービス利用者および IT サービス提供者は認識する必要がある。
ITIL
®
V2 は「システム運用のベストプラクティス」としてプロセスに重点が置かれてきたが ITIL
®
V3 では ITIL
®
V2 に「ライフサイクル」のアプローチが加えられた。各ライフサイクルについては 以下に簡単に述べておく。
(1) サービス戦略＜サービス・ストラテジ＞
IT サービスや IT システムを組織がその業務を遂行する上で必要な戦略的資産としてと らえ、サービスマネジメントの設計、開発、提供までを実現することを目的とする。 (2) デザイン＜サービス・デザイン＞
サービスレベル管理、キャパシティ管理、可用性管理、IT サービス継続性管理などはこ こに含まれる。既存サービスや新規サービスのビジネス要件を満たすためにどのような設 計、開発をしていくべきかの方法が述べられている。
(3) 移行＜サービス・トランジション＞
本番環境への移行にともなう中断や移行を原因とした障害などをコントロールしつつ、 IT サービスを実稼働に導くことを目的としている。
(4) 運用＜サービス・オペレーション＞
IT サービスの戦略を具現化し、IT サービスが業務に対して継続的に価値をもたらすこと を目的とし、PDCA サイクルのベースとなる活動が定義され実際の運用が行われる。 (5) サービス改善＜継続的サービス改善＞
IT サービス・ライフサイクルのいずれの段階においても、障害個所や弱点に対する改善 機会を見つけ出し、顧客に対してより良い IT サービスを提供することを目的とする。
上記のようにベストプラクティスの書籍群は存在し、支援する企業もあるのだが、現場へのプ ロセスの実装となると、時間やコスト面の制約から前へ進まないことも多い。そういう場合にお いては ITIL
®
を適用する範囲の絞り込みが必要であり、「我々は、何をしたいのか」という目的が 重要になってくる。
さらに、実際の作業を進めていくと、これまでやってきた作業手順に落とす工程において、現行 の手順と ITIL
®
の手順の間に、どうしても二度手間と思われるような箇所が生じることがある。今 その時の作業効率だけを見れば確かに無駄なのかもしれないが、そういう時こそ ITIL
®
導入の目的 に立ち返って考えることが必要となる。そしてプロジェクトの初期の段階で目的が曖昧であると 判断される場合は、目的を明確化するための時間を割くべきである。
また、どの企業にも上下関係の強さや組織間のパワーバランスなど、企業ごとの事情があり中々 話が纏まらない場合が多い。しかし議論を重ねていくと現実的な共通認識は出てくるはずである。 例えば、「会社の方針だから・・・」、「今年度の事業目標は・・・」、「経営層の意向は・・・」な どのようにサービス戦略（サービス・ストラテジ）の基本的なところに行きつくはずである。そ してそのために提供しなければいけない IT サービスでの努力目標値（レスポンスや情報量に対す るキャパシティ）とそれを実現するためにどこに資源（人、モノ、金）を投入していくかに繋が っていく。これは初期段階でのサービス・デザインのようにも取れる。どの企業においても ITIL
®
でよく耳にする「クイック（やれる事から）スタート」、「スモール（局地的）スタート」ができ るのもこのような明確（文書）化されていないが何となくやっている下地があるからである。
ほとんどの企業は事業戦略が毎年、多少なりとも変化している。IT サービスもそれに合わせて 変化し続けるべきである。当然戦略に合わなくなったシステムは使われなくなっていく。その場 合はサービスをそれまでと同じように提供するのではなく縮小（時間短縮、容量縮小）・廃棄・再 構築をすることも含め改変させていき、伸ばしたい事業が出てくれば IT サービスも拡大していく。 これが IT サービスにおけるライフサイクルであるといえよう。
どの企業でも実は行っていることのように思えるが、実際のところ問題なく稼働しサービスが 提供されている間は IT サービス利用者、IT サービス提供者の双方が共有する目標値をもって改 善するというところにまでは着目しないのである。IT サービス利用者の方も IT サービス提供者 の方も使われているもの（例えばよく使う画面とか利用ログが多いもの）、いないもの（メニュー にあるけど見たことない画面など）の棚卸をしてみてはいかがであろうか。そしてそれは今の戦 略目標にあっているだろうか?
以上
資料編
1. メンバー紹介・活動履歴
リーダー 関電システムソリューションズ株式会社 島田 優市
サブリーダー 日本精線株式会社 三輪 政人
エス・アイ・エス株式会社 松浦 康浩 株式会社サンモアテック 平田 直樹 株式会社東レシステムセンター 葛城 周
コーディネーター 株式会社ビーエスピー 津田 昌彦
サブコーディネーター 株式会社ビーエスピー 赫多 琴音
（敬称略）
No. 日程 開催場所 内 容
第 1 回 2010.05.25 三井アーバンホテル 春季全体会、キックオフ 第 2 回 2010.06.07 エス・アイ・エス株式会社 当研究会合
第 3 回 2010.07.09
～ 2010.07.10
京都トラベラーズ・イン 合同合宿
第 4 回 2010.07.23 関電システムソリューションズ株式会社 当研究会合
第 5 回 2010.08.20 日本精線株式会社 当研究会合
第 6 回 2010.09.17 エス・アイ・エス株式会社 論文要旨作成
第 7 回 2010.10.15 日本精線株式会社 当研究会合
第 8 回 2010.11.19 株式会社ビーエスピー 当研究会合
A 社様訪問・ヒアリング 第 9 回 2010.12.17 株式会社ビーエスピー 論文要旨作成
第 10 回 2011.01.14 日本精線株式会社 論文作成 第 11 回 2011.01.21 株式会社ビーエスピー 論文作成 第 12 回 2011.02.02 株式会社ビーエスピー 論文作成
第 13 回 2011.02.10 関電システムソリューションズ株式会社 発表用資料作成予定
2. 参考文献
【参考書籍】
ITIL 入門 IT サービスマネジメントの仕組みと活用
野村総合研究所システムコンサルティング事業本部 著：株式会社ソーテック社
図解入門ビジネス 最新 ITIL V3 の基本と仕組みがよ～くわかる本 打川 和男・勝俣 良介 著：株式会社秀和システム
図解入門ビジネス 最新 ITIL がよ～くわかる本
打川 和男・浦名 祐輔・小野寺 潤・ジェイエムシー 著：株式会社秀和システム
ITIL 教科書
青柳 雅之・北尾 一彦・木村 祐・吉田 俊雄 著：株式会社アイテック
【参考 Web サイト】
システム管理者の会ポータルサイト http://www.sysadmingroup.jp/
※ 本論文に記載されている会社名、商品名などは一般に各社の商標または登録商標であること を明記し、本文中では TM、R マークなどの表記を省略させて頂きます。
3. 付録
【アンケートの結果】
※ アンケート項目は本論文に記載されている「表 3.2-1 アンケート項目」（9頁）を参照
Q1 Q2 Q3 Q4 Q5
担当
目標値の 共有
SLA の締結 有無
共同の 改善活動
改善 サイクル
内容
1. 利用者 している している している その他 主要取引先と定期的（月次or隔月…）に協議会がしている
2. 利用者 している している している その他 3. 利用者 している している していない なし 4. 利用者 していない していない している 四半期 5. 利用者 わからない していない している 半年
6. 利用者 していない していない している その他 問題発生時
7. 利用者 していない していない していない その他 不定期、トラブル集計、リプレイス時
8. 利用者 していない している していない 一年
9. 利用者 している わからない している その他 不定期
10. 利用者 していない わからない わからない なし
11. その他 わからない わからない わからない その他 わからない 12. その他 わからない わからない わからない 一年
13. 提供者 している していない している 四半期
14. 提供者 している していない している 半年 CS調査、CS改善活動を半年ベースの目標で活動
15. 提供者 している していない している その他 都度
16. 提供者 していない していない している 四半期 17. 提供者 していない していない している 半年 18. 提供者 していない していない している 一年 19. 提供者 していない していない している 一年
20. 提供者 していない していない している その他 必要に応じて
21. 提供者 していない していない している その他 要望、制度変更が発生する都度
22. 提供者 していない していない している その他 インシデント結果から都度
23. 提供者 していない していない している その他 現在、SLAの締結、目標の設定、改善活動について検討中
24. 提供者 していない していない している その他 都度
25. 提供者 していない していない していない 半年 26. 提供者 していない していない していない 一年 27. 提供者 していない していない していない 一年 28. 提供者 わからない していない わからない 四半期 29. 提供者 わからない していない わからない 四半期 30. 提供者 していない していない していない なし 31. 提供者 していない していない していない なし 32. 提供者 わからない していない していない なし 33. 提供者 している している している 四半期 34. 提供者 している している している 一年
35. 提供者 している している している その他 改善が必要な都度、改善計画書を作成し実施している
36. 提供者 している している わからない なし
37. 提供者 している している していない その他 不定期 38. 提供者 している している していない 四半期
39. 提供者 していない している している 四半期 40. 提供者 していない している していない なし 41. 提供者 している わからない していない 半年
42. 提供者 している わからない している その他 不明です。開発部門のため
43. 提供者 している わからない している 一年 44. 提供者 わからない わからない わからない なし 45. 提供者 わからない わからない している 半年
