プログラマとプロマネのあいだ

プログラマもやるし、プロマネもやるし、たまに似非アーキとか営業っぽいこともやる

「要点解説 ITILがわかる!」読了

要点解説 ITILがわかる!

要点解説 ITILがわかる!

ITILってキーワードは聞くけど、なんぞや?と疑問を持ったのが本書を読むきっかけです。
ITIL - Wikipedia: http://ja.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
端的に言えば、ITをサービスとして提供する側に対して、「ITの運用」はこういう仕組みでやればうまくいく(ベストプラクティス)というのを、体系的にまとめたものということになるようです。
大きく「サービスサポート」と「サービスデリバリ」に分けられるのですが、特に「サービスサポート」については、開発中にも行うプロセスが多く、わりと身近だったりします。
サービスサポート - Wikipedia:
http://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88
特定のツールとも結び付けられますしね。
例えば、問題管理 - Bugzilla, Trac、構成管理 - Subversion, CVSなどなど。
逆に言えば、これらのツールは、開発中のみならず、保守・運用にも使えるツールだということになりますね。
一方の「サービスデリバリ」については、非機能要件として定義されるような項目が並びます。
サービスデリバリ - Wikipedia:
http://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%83%87%E3%83%AA%E3%83%90%E3%83%AA
開発者としてなじみのあるのは、キャパシティ管理(キャパシティプランニングとか)とか、ITサービス継続性管理(障害時計画とか)とか。
開発者視点で読みましたが、わりと今の現場は規模が大きいこともあり、現場でやってるアレ相当だなとか結びつけが出来てわかりやすかったです。ITILを意識しているかどうかは分かりませんが、「サービスレベル管理」とか「ITサービス財務管理」みたいな見えない部分は不明ですが、わりと仕組み化されている印象です。
ITILが必要なのは、ある程度の規模の組織になってきて、仕組み(ルール)がなくてうまく行かない部分があるというような場合が多そうですが、チーム単位の導入でも効果ありそうな気がします。
とにかく、仕組み的なところを考える機会があれば、一度ITILを参考にしてみると良いかも知れません。