ITIL の変更点
Top / ITIL
- 追加された行はこの色です。
- 削除された行はこの色です。
- ITIL へ行く。
- ITIL の差分を削除
IT Infrastructure Library（ITインフラストラクチャ・ライブラリ）の略で、IT運用に関するガイドラインのことで、アイティアイエル、アイティル等と呼ばれる。 ここでは、特に記載がない場合は2007年に改定されたversion 3に準拠する。 ---- #contents ---- * 概要 [#ifc569f5] ITILは英国で定められ、これまで「ITとは何ぞや？」「ITを運用するって、どういうこと？」という問いに応えられるものはなかったが、その運用や管理について体系的に且つ網羅的に記述しているナイスなガイドラインである。 ベストプラクティスだの包括的フレームワークだの書かれるとアレルギー反応を示す人もあるかと思うが、要はコンセプトとして掲げられている「ITとビジネスが一体であること」のもと、よりよくITを付き合っていきましょうということ。 これを支えるのはプロセス・ピープル・プロダクトと言われ、どれが欠けても成立しないとされている。これらの頭文字を取って「3つのP」と呼ばれることがある。((余談だが、絶対に「みっつのぴー」と覚えて頂きたい。大真面目な場で、そんな意図はなく「さんぴー」と口にしてしまい、緊張感が消滅してしまったことがある。当然、打ち合わせどころではなくなった)) さておき、「ITとビジネスが一体であること」とは、具体的にどういったことなのか？ それは、システム指向からビジネス指向あるいは指向サービスへの変遷だと考える。 今までのITやIT部門は、仕組みやその面倒を見ることが主眼であったと考えるが、最早この認識は有効ではなく、''大前提として、ITとはビジネスを成り立たせるための必須要件であり、IT部門はシステムのお守りではなく、ITを用いたビジネスの遂行をサポートするという役割を持つ''という認識を持たなくてはならない。 ** 誕生の背景 [#q21fce6d] 「英国で定められた」と記述したが、そのころ英国政府では下記のような問題があったことを背景に、過去事例を取りまとめて完成させたという経緯がある。 -導入したITが肥大化しコントロールしきれなくなってきた トラブルが増加し、原因究明が難しくなる。日々の問い合わせに忙殺され、根本治療や改善活動への取り組みが疎かになる。 これでは、変化するビジネスニーズに追随するどころではない。 -気がつくとシステム運用側の仕事がやけに増えている。が、その割に人員は増強されない 情報共有の重要性は高まるばかりだが、担当者の素養と努力に依存し属人化の温床となる。 結果、優先度もロクに考えない場当たり的な対応ばかりになり、レスポンスやクオリティは低下。頑張っても頑張っても利用者側からはクレームばかり。 -それらを使い続けるために費やすコストが馬鹿にならなくなってきたが、その割には何にどれだけ金を使っているのかわからない 管理者側にとっては無駄金をかけ続けているように見えてしまうが、言われる側にとっては、まるで言いがかりで、まっとうなコストであっても曖昧な削減要求に遭う。 -投資に見合う効果が得られなかった そもそも、投資自体の目的やスコープ、受益者や評価の尺度が充分に語られないままエイヤで取り組んでしまう。 これらに対し、ITILの登場前はどうだったかというと、恐らく日本と同じでKKD（カン・経験・度胸）と呼ばれる属人的かつ整理も明文化されていない要素を元に、場当たり的に進められていたと思われ、それではイカンということで、体系的に・網羅的に・ロジカルにまとめられたと考える。 これが実現できれば、コストマネージャは何故・何に・どれだけのコストが掛かるかを把握できるし、運用側は情報やプロセスを整理することで効率化を実現でき、利用者側はそれによって向上したサービスを受けることができる。 理想論にしか聞こえないかもしれないが、机上の空論に終わらないことは既に多くの導入企業が証明している。 なお、ITILはあくまで「ガイドライン」であり「マニュアル」ではないため、当然ながら企業ごとの詳細なターゲットやオペレーションについて細微に記載されているわけではなく、業務の実際と突合しつつ適用しなければならない。 ** 導入の目的と期待する効果 [#p9d1ae31] 簡単ではあるが、よくある課題とITIL導入によって期待される採用効果の一部を記した。 |いままでの課題|利用者のメリット|管理者・運用側のメリット|経営層のメリット|h |自社で利用しているITの全体像が見えない|採用したIT投資が利用しきれるようになる|ITの構成が漏れなく把握できる|何にどれだけコストが発生し活用されているか可視化される| |問合せが埋没する、同じ問合せが発生するたびに対応しなければならない|案件管理によって正しく処理される、無視されない|過去事例を参照でき、対応手順がクリアになる|従業員の勤務時間が効率化される、サポート負荷が可視化される| |社内のITが整理されていない|整頓・交通整理するだけで効率化される面がある|なんでもかんでもIT部門の責任にされなくて済む|良いものと悪いものが可視化され、見通しの良いIT戦略が立てられる、従業員をコア業務に集中させることができる| |IT部門が評価されてない、IT部門に対する不満が鬱積している|相互の理解や協力関係が改善することで、少なくともストレスは減る|雑務や下働きばかり押し付けられ、金食い虫呼ばわりされずに済む|従業員同士の軋轢が解消される、IT部門のタスクが透明化する| もちろん導入による効果はこれだけではないが、漠然とコスト削減や効率化が謳われることに嫌悪を感じる人もあるだろうということで、少しだけ書いてみた。 また、ITILを採用した企業の多くは、これらの目的を揚げている。 +サービスの質や、ユーザ満足度を改善させるため +ITサービスを個別に把握するため +コストをより削減するため +コンプライアンス対応 これらを如何に現実の元とするかについては、次項で触れたい。 ** ITILの内容 [#i73f8f5b] サービス・ストラテジー、サービス・オペレーション、サービス・デザイン、サービス・トランジション、継続的サービス改善という5つの要素がある。 サービス・ストラテジーはその名の通りITサービスの提供に関する戦略であり、全体のロードマップを指すコアプロセスと呼ぶことができ、ここで描いた全体像の元、サービス・デザインで設計し、サービス・トランジションで移行し、サービス・オペレーションで運用する。 これらは一度やって終わりという性質ではなく、これらに対し「継続的なサービス改善」を作用させることでサービス・ライフサイクル・アプローチを実現するというもの。 各プロセスは、「継続的なサービス改善」からのフィードバックを反映させ、更なる改善を目指していく。 また、それぞれの要素は独立しておらず、相互に関連しあう。 +[[サービス・ストラテジー]] +[[サービス・デザイン]] +[[サービス・トランジション]] +[[サービス・オペレーション]] +[[継続的サービス改善]] ** ITILの導入プロセス [#cbddad13] *** アプローチ [#ef575906] +説明会や個別セッションなどを実施する +インシデント管理など「とっつきやすい」ものから採用する +全てのITILプロセスを導入する 難易度・コスト・効果のいずれも、上から順に高くなっていく。 後述するが、一番お勧めしないのは''インシデント管理など「とっつきやすい」ものから採用する''こと。 一見、手軽に効果が出やすいポイントを実施することが足がかりになりフルバージョンほどコストがかからない折衷案のように思える。しかし、その部分だけの導入を目指すため他のプロセスとの整合性が勘案されず、次の展開が難しくなるという致命的な欠点がある。 家でいえば、最初から望む間取りで建てる場合と建てた後で増築する場合を比べると、トータルの期間と予算は圧倒的に前者の方が余裕があり、また後者は前者にない制約が課せられることが多い。（家でいえば、水回りの設置場所や動線の確保など） とはいえ、いきなり全ては厳しいというのも事実なので、そういった場合はPCやグループウエアに関するもの、次に基幹システムに関するものといったように、対象をある程度分割することは良い方法だと思う。 *** 注意点 [#v85a58b9] 導入は長期プロジェクトになるため、周囲からの継続的な支持が必須となる。 とはいえ、何かしらのUpdate（できれば効果を出すこと）がなければマネジメント層からのサポートは継続しない。「何の効果もないことに、あとどれだけ付き合わされるんだ？」となるのは必然だからだ。そうなると推進派は発言力を失い、反対派はより勢いを増し、プロジェクトメンバの士気はダダ下がり。 まずは身近でキャッチーな目標を掲げ、「プロジェクトの一環として、それらが解決できていますよ」という事実を叶えることが肝要ではないだろうか。そうした改善活動への試みとその結果は、次の改善につながることは少なくない。 ** ITILあるある [#c936de15] *** IT部門のみで進めてしまう [#bb7dae68] 恐らく導入にあたってはIT部門が主管となるかと思うが、IT部門のみで実行してはならない。 何故ならば、ITILは全てのIT利用者つまり末端の利用者やマネジメント層も含む全体最適でなければならないが、IT部門のみでプロジェクトを進行してしまうと管理・運用するIT部門の受益を優先する個別最適になってしまいがちだからである。 こういった意図や利用者不在の志向を他の部門が察してしまうと、当然ながら''「そっちが楽をするための試みに、何故こちらが時間を割いたり面倒な思いをしなければならないんだ？」''となることは想像に難くなく、事実そういった経緯による失敗事例も少なくないようだ。 *** IT部門の不満に付き合ってしまう [#q0a4cffc] 最初に言いたいのは、もちろん全員がそうだとは言わないが、IT部門の人間はITに詳しくない人間を見下しがちであるということ。 ITに詳しいということを何か特権階級かのように思っているため、IT部門とはそれはそれは価値ある仕事をしているのだ、と思っている人は少なくない。 自らの役割に誇りを持つことは良いことなのだが、ITILの導入に際しては、「ITに一番詳しい自分たちの仕事に、詳しくもない連中が自分たちの仕事に口出ししてくる」等の解釈という悪い面が出がち。 *** 部分導入してしまう [#a200e696] ITILで語られているコンテンツは相互に関連し合っており、どれが欠けてもコンセプトを全うすることはできない。 これを忘れて部分的にピックアップしてしまったことで立ち行かなくなった事例は、version 2の段で山ほどあったそうな。 version 3は、その反省を踏まえているため掻い摘んだ導入がしやすい形ではないものの、この点もお忘れなきよう。 ただし、「部分導入が悪い」という意図は、掻い摘むと恣意性が出やすいこと等を訴えるものであり、例えばOA関連→基幹システム→ネットワークなど対象を小分けにして段階導入することがまずいということではない。 *** 導入して終わり、になってしまう [#k182f8e7] ITILのコンセプトを一言でいえば「より良く運用すること」であるため、導入しました→お疲れさん、では意味がない。 デザインの中に[[PDCAサイクル]]が包含されているため、正しく運用していればそうはならないはずだが、とかく運用し続けることが苦手な人、それが社風化してしまう企業は少なくないため、この点は認識して頂きたい。 *** ツールやアプリの採用をITILの導入と解釈してしまう [#xa2ae49f] よく「ITILに準拠した〜」という表現で売り込むソフトウエアがある。 これを否定する意図は全くないが、これを導入したからといってITILが導入されたわけではない。 ITILの導入とは、自分たちにとってのIT運用を考え、遂行し、見直すことであり、アプリケーションのインストールとは関係を持たない。 *** 導入することで、「全ての問題」が「一度に」解決すると認識してしまう [#c2f78639] ITILの導入には、決して少なくない予算と期間が必要とされることが多い。 その分期待度が上がることはやむを得ない面もあるかと思うが、だからといって一度に全ての問題が解決するわけではない。 むしろ、色々なトラブルや課題に対して継続的に取り組んでいくことで「最終的にすべての課題を解決する」という心持ちで臨むことが良いのではないかと思う。 ただでさえ日本の企業はメシア願望が強く、何か新しいものや役に立ちそうなものを見つけると完全無欠のソリューションを期待しては、そうではないことを悟りガッカリしてしまう。そしてそれを繰り返すうちに「ITなんて・・・」的な悲観に陥る癖があるため、そうではないと啓蒙することは欠かせない。 *** 現場任せにしてしまう [#mf0e6201] ITILは全体最適に重きを置いているが、上記「IT部門のみで導入しないこと」で述べたとおり、IT部門だけで行うと「IT部門のための〜」となってしまう。また、他の部門を関与させたらさせたで声の大きな人の独擅場になってしまうことも懸念される。 こういったことにもケアが必要であること、またITILに限らずマネジメント概念の導入にはカルチャーチェンジという大きな変革が待ち受けており、人は変化を嫌うのが常であるため、反対がデフォルトと思っていい。 こういったシーンではトップダウン指示がなければ進行は難しく、トップマネジメント層の支持は必須と言っていい。 偉い人は下の不満になどイチイチ付き合っていられないことから、現場が大変だと言っても「ええから、やったらええやん」的なリアクションが多く、また大抵は腰が重い。 そのため、理解を得ることやメリットを理解してもらうことは骨が折れるが、プロジェクトの完遂には必要なことだとご認識頂きたい。 *** 全ての企業で投資対効果が高いと認識してしまう [#d2eefdc4] ITILのコンセプトは企業の規模の大小を問わず有用なものであることは認めるが、極端に言えば八百屋さんに導入したってしょうがない。 もう少し噛み砕くと、業務プロセスの数、そのうちIT化されているプロセス数、導入しているITサービスの数と金額（Initial、Runningともに）、PCやサーバの台数、従業員の数などが影響し、企業規模が小さいと価値がないとは言わないが、大企業での採用ほどメリットがないことは確か。 また、そもそも「管理する」とは柔軟性を殺すこととある程度リンクしていることも忘れてはならない。これらが「投資に見合うか？」というと、小規模での導入はNoになりやすい。 * 補足 [#b8284798] ** 資格について [#z77ce081] [[プロメトリック>http://it.prometric-jp.com/testlist/exin/index.html]]より、入門編とも呼べる''ITIL V3 Foundation''が受験できる模様。受講料は税込20,160で、SAPの試験と比べればマシか。 //** 成功事例 [#sf5e8bf6] //-P&G //500万ドルのコストカット、IT運用コストのうち6〜8％、IT部門の人員を15〜20％削減らしい ** リンク [#w97cadc8] [[itSMF〜ITILとは>http://www.itsmf-japan.org/itil/index.html]] [[内部統制ナビ〜ITIL>http://www.eusea2006.org/itil/]] ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_iphone_book_howto) #htmlinsert(amazon_iphone_book_itil) ~ ~ ---- #pcomment(reply)
