ITIL・ITサービス管理講習

会社が紹介＆費用負担してくれたITIL講習に行った。結構予習していったので試験（ファウンデーション）は楽勝。以下覚え書き、自分なりの理解と解釈。

自分の環境を振り返る

ITILは「新規に導入するもの」ではない・・・。多かれ少なかれ、ITサービスに携わる企業は、「運用プロセスを定型化・標準化・記録保持しないとまずい」ということに気づいているし、それを受けて社内外には（どういうレベルにせよ）整えられたプロセスがあるはずだ。その「現状環境」を検分してPDCAをまわすツール、と考えればそう敷居は高くは無い。
自分が前にサポートをやっていたときの環境は、外資だったからか、かなりしっかりとした枠組みがあり、今考えるとITILのフレームワークを意識した内容だったと思う。（ヘルプデスクなので、主にサービスデスク、インシデント管理、変更管理）
もしアセスメントを考えるとすれば、「問題」概念の導入だろうか。
このときのシステムでは「問題」の概念が無く、単に問い合わせ（インシデント）とバグ番号のみの管理だったので、「バグとは確定していない、再現しない、再発しない」タイプの問題をうまくトラックできなかった。しょうがないのでローカルで手作業のメモをみんなでまとめていた。
今の環境も、まだ十分にいじっていないけれど、やはりかなり意識していることが感じられる。このあたりの現状観察・分析などから勉強につなげられたらよいと思う。

ITILに関する誤解

自分以外の受講者15人は全てプリセールス系SE。「お客様との共通認識の基盤を獲得したい」「提案につなげたい」などの意識に納得。ただ、（特に職種とは関係ないけど）質疑応答の中でいくらか誤解がみられた。

ITILはフレームワークであり、手引きではない

実装方式についてはほとんど規定がない。たとえばCMDBに登録する項目は何であるべきか、や、さらに実際のDBの設計については全く触れていない。逆にそこがベンダやSIの頑張りどころ、儲けどころともいえるんだけど。

各プロセスは抽象的なモデルであり、実際の組織や担当者と1対1で対応するものではない

「ITILはITサービスの改善方法である→現実のビジネスではこのプロセスはこの業務のこと→この業務ではこういうリスクが発生する→でもこのプロセスがそのリスクをどう判断するのか書いていない！」という主旨の質問。
サービスサポートの分野では特に、実際の業務とプロセスを重ね合わせてみてしまう誤解が見られた。
確かに「サービスデスク」は実際のコールセンタ、「変更管理」「リリース管理」はインフラのアップグレード等、という業務が簡単に想起されるんだけど、
逆に「リリース管理はシステムアップグレードの方法」かというとそうではない。
実際の業務は単一のプロセスの枠組み内で行われるものではないし、部分、部分ごとに必要なプロセスのフレームワークを利用しながら行われる。たとえばアップグレード時のリスクをどう検討・説明するかは、可用性管理なりサービスレベル管理なりの視点を持って行われるものだろうし。（そういうプロセス間のインターフェイスみたいなことをもっと強調できた講義だったら、こういう誤解で荒れたりしないかなー。）

ITILはITビジネス全体をカバーしない

これも、「ITILはITサービスの改善方法である→現実のビジネスでこういう問題が発生する→でもITILではそれをどう処理するのか書いていない！！」という主旨の発言から。
実際のITビジネス、サービスはITILの「外部要素」を含んでいる。外部要素はITILのプロセスで直接処理されるものではない。たとえばコールセンタに「作業員の態度が悪い」という顧客からのコールがあった場合、それは「システムを通常稼動でない状態にする」という意味の「インシデント」にはならない。インシデント以外、ということで「サービス要求」といえるが、「それをどう追跡すればよいのか？」という場合、その作業員の勤務態度をどう改善させるか、は少なくともITILの対象範囲ではない。これは極端な例だけど、そこまででなくとも「ITILのフレームワークにむりやりいれる必要のない分野」は確かに存在するし、そこは線引きをすべきだろう。「それはITILでは解決できないし、解決する対象でもありません」

ITILはその利用・導入する範囲を制限していない

「顧客に向けてのサービスに導入するものなのか？自社のワークフローにも導入しなくてはならないのか？」という問いはあまり意味がない、というのも何を顧客としてフレームワークを起動するかは目的によりけりだからだ。これは社内IT部門にITILを利用すると想定すると、顧客は実際のところ会社経営層、ユーザが社員一般となる。（モデル上の「顧客」は必ずしも現実の「顧客」ではない）
また、ほとんどのITサービス企業（ベンダなど）は、内部に開発→リリース→修正のサイクルを含むので、そのプロセスの改善を進めるために、社内（の開発）プロセスにITILフレームワークを使用し、顧客向けのプロセスのまとまりと社内向けプロセスのまとまりが円滑に進むように企画できると望ましい。これは、「ある（ビジネスとしての）ITサービスのうえでは、レイヤの異なる複数のITサービスが存在する」ことから考えれば明らかで、それぞれにITILの視点を利用していくことが望ましい、といえるんだろう。

何かと、実際のインスタンスに置き換えて考えたほうが確かにわかりやすい。
ただ、そのまま続けると、例としてあげた実装方式をあたかも「推奨実装方式」のようにとらえてしまい、プロセスを過度に実際の組織・プロセス・製品と結び付けてしまい。ITILの各プロセスがあくまで「フレームワーク」であることを忘れてしまう。講師の解説も混乱を招く部分が多々あり、その点があまりよくなかった。（ITサービス管理としての推奨なのか、ITILの事例なのか、個人的な意見なのかがはっきりしない）まー、自分が教えられるようになりたいもんだけど。