読者です 読者をやめる 読者になる 読者になる

GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

ITILファンデーション資格ゲット

2日間の集中研修後に資格試験に挑み、75点で合格することができました。以下メモ。適当につまんでもらえれば。

ITILってなに?

英国政府が体張ってまとめた、ITサービス設計・運用のベストプラクティス。マニュアルではなく、考え方や方法論をまとめたもの。どのようにITILで提供されているフレームワークを実施するかは、自分で考えろの世界。

これを全部やろうとしても、間違いなくできないと思われる。自分の会社にフィットする部分を上手く拾うセンスが求められる。スモールスタートで。

どういう構成?

どうやってITサービスを設計するのかというサービス・デリバリと、日々の運用手順・方法についてまとめたサービス・サポートが中心。ITILファンデーションの試験もここら辺の話しかでません。

サービスデリバリの構成要素

  1. サービスレベル管理(何をどう提供するか)
  2. ITサービス財務管理(コスト管理)
  3. キャパシティ管理(サイジングとか)
  4. 可用性管理(信頼性と保守性の確立)
  5. ITサービス継続性管理(災害時のリカバリとか)

最も重要なのはどういったサービスレベルで合意を取ったか。これが残りの4つの管理の行動基準となるためです。

サービスサポートの構成要素

  1. サービスデスク(ユーザーとの窓口)
  2. インシデント管理(ビジネスに悪影響を与えるものを管理)
  3. 問題管理(インシデントの原因を管理)
  4. 構成管理(ソフトやハード、マニュアルやSLAなどの文書も含む)
  5. 変更管理(そのまんま)
  6. リリース管理(実環境への投入、ライブラリやハードの管理)

ちょっとここは解説がいる。

インシデントというのは、顧客の業務に悪影響を与える事象のこと。システム障害のみならず、パスワード忘れや「XXを今使ってるシステムでやりたいんだけど」的なことも全部含める。あくまで「事象」ってのがポイント。また、普通の感覚だとインシデントから原因究明のプロセスを辿りたくなるが、ITILでは「まずは何でもいいからインシデントを回避して顧客の業務を滞りなく進める方法をユーザーに告知しろ。原因究明はその次だ。」というポリシーです。

問題というのは、そのインシデントが起こった根本原因のこと。インシデントから原因を導くのが問題管理のプロセス。でもって、その問題を元に回避策もしくは恒久的な対応策が取れた場合、それは問題から「既知のエラー」というものに変わります。

ITILでは、変更管理とリリース管理を別に分けています。変更を行うことに責任を持つ組織と、その変更を元に実作業をする人を明確に区別しています。変更が上がってくるのは問題管理の担当者からもしれないし、構成管理の担当者かもしれないからです。変更を受容するのと、変更を実施するのは別という考えは中々理にかなっています。

どれもこれもつながってます

サービスデリバリはSLAに基づく合意事項の元に、どのようにITサービスを設計してゆけばいいのかを導きます。コアはサービスレベル管理にあります。

サービスサポートはインシデント管理だけでもコトは足りますが、結局「なぜそんなことが起こったのか」を解明しないことには解決になりませんので、問題管理が必要になります。インシデントが起きた環境を把握するためにも構成管理が必要になるだろうし、問題解決のために今使っているITサービスの変更が必要になったりもします。

なので各プロセスの責任範囲と、各々のプロセスにどういったつながりがあるのかを理解することがITILファンデーション対策にもなります。結局ITILファンデーションの試験で問われるのはそこだった気がします。

話は戻りますが、問題管理のみ、構成管理のみ、というのはうまみが少なくなりがちです。ある程度セットでやらないと意味が無いかなと。そうなると、共通的なDB*1作った方がいいよねという話になりますが、最初から色々DBに突っ込むと死ねるので、これもスモールスタートが望ましいです。

ITIL適用は業務再設計と等価です

結局の所「ITILという旗印の元に、自社の運用サポート業務プロセスを再設計する」というのが「ITILを適用する」という言葉の意味です。ITILで言われているベストプラクティスはあくまで100点満点の理想論です。ですが、理想的な姿を知ることで「現状をどう変えればよりよい姿に近づくのか」という考えに至ることができますので、そこは意味があることだと思います。

業務改善を行うに当たっては、この3つの要素が全て有機的に変わらないと改善されません。

  • ヒト
  • 業務プロセス
  • 技術、ツール

ツールありきではダメ、業務を再設計しても道具が無ければ絵に描いた餅、業務もツールも用意しても、ヒトの反発にあえばそれまでよ、と。この3つが全て有機的に変わらないとダメだねという話。

ITILファンデーションってどうよ?

ここに書いてあることが全てです。

さて、この ITIL Foundation 取得によって実践レベルで何か変化があるかというと、それはちょっと難しいのではないかと思います。少なくとも、自らITILベースで運用管理について考えたりプロセス検討したりするには、ぜんぜん物足りないです。

この資格は「チミはITILという考え方に基づいたITサービス設計や運用のあり方について、ある一定の理解がありますねぇ」というのを証明するだけのものです。それを元にどうすんのよ、どうPDCAまわすのよ、っていうのは別次元の話です。

試験対策テクニック

試験問題の日本語が直訳のため微妙な日本語になってます。あんまり深読みせず「もっともらしい答え」及び「問題と直接関係がある答え」を探しましょう。

また、ごにゃごにゃと前口上が長い問題もあります。それは全部意味が無いことが殆どです。問題文の主語と述語だけ切り取って考えると良いです。

知識面や勉強法については以下のページをご覧ください。当エントリよりはるかに参考になります。

*1:これを構成情報DB(CMDB)と呼ぶ