「ITIL はじめの一歩」を読みましたので、感想を書きます。

ITILとは

ITIL とは「ITサービスマネジメントのベストプラクティスをフレームワークとしてまとめた書籍群」であり、この本はまさしく、その「はじめの一歩」となります。

本の構成について

感想を書く前に、まず本の構成について。

「はじめの一歩」ということもあり、「読みやすさ」において随所に工夫が凝らされています。

この本は ITIL について説明していますが、大部分をケーススタディーに割いています。

余談ですが、私は Chapter 03 が業務とマッチしている箇所が多く、共感することが多かったです。

上記ケーススタディーの解説は、基本的に見開き2ページで完結しており、左側に文章、右側に図の構成が統一されています。

私は、主にお昼休みに読み進めていたので、中断しやすく、再開しやすい構成で大変助かりました。

私はこの本を読むまで、システムを提供するという認識でいました。ただ、この本を読んで、対応しているユーザー部門はサービスを求めているということがよくわかりました。

また、 SLA (Service Level Agreement) については知っていましたが、どのように合意まで持っていくか判然としていませんでした。

私は現職に就いてから保守と運用に携わる様になったのですが、リリースや展開の意味合いの違いがわかりませんでした。

この本では、それらが ITIL に基づいて明確に説明されています。これからは、それに基づいて上記用語を使用するようにします。

読んで終わりでは意味がない*1ので、最後にこれから実践することをまとめます。

インシデント管理は、本を読む前から業務として行っていましたが、活用までの導線が少ないのが現状です。

これは、インシデント発生時のプロセスが明確に定義されていないことが原因ではないかと思いました。これを機に、インシデント発生時のプロセスを定義します。

最初は、インシデント管理に問題管理も含めて上記に書こうと考えていましたが、書いている内に「問題」として独立して管理できていないことがわかりました。

インシデントからは切り分けていましたが、切り離した先が「問題」としてではなく「どの様に改修するか」であった為、他要因の改修と混ざってしまっていました。

これを改善すべく、「改修内容」ではなく「問題」として切り分けるようにします。

ナレッジ管理については、共有可能な Wiki に書く運用にしていますが、その記事を共有できていませんでした。

いきなり共有する運用にすると迎合されないので、まずは自分が書いた Wiki を客観的な観点で整理することにします。

*1:ブログを書く様になって痛感するようになりました