【ITILと私】ITILを利用してIT運用現場を改善しました
こんにちは。業務プロセス改善エンジニアのMIYAです。 IT運用現場の改善活動にて利用したITサービスマネジメントのフレームワーク「ITIL」を紹介したいと思います。
ITILのバージョンは、Version3の2011年版です。
ITILを使うメリット
ITILを利用すると、「もれなく」「無理なく」「効果的に」できる手軽さと柔軟性を感じます。
ITの世界で実績のあるプロジェクトマネジメント手法であり、体系的で抜け漏れがない ➡ もれなく
すべてを適用する必要はなく、現場の実態に似合わせた「いいとこどり」ができる。スピードのある改善ができる ➡無理なく
ビジネスニーズを主軸とした考え方。経営者を顧客ととらえ、費用対効果など経営者に納得感を持ってうけいれられやすい ➡効果的に
ITILの4つの登場人物
ITILには、４つの登場人物が存在します。この４つの登場人物像にIT運用現場の関係者をあてはめました。
顧客・・・「サービス」を運営するのに必要なお金や人などのリソースを提供してくれる人
ユーザー・・・「サービス」を利用する人
サービスプロバイダ・・・与えられたお金や人を使って、実際にそのサービスを提供する人
サプライヤー・・・「サービス」を運用する作業を委託されている別会社の人
サービスとは
サービスプロバイダ、サプライヤーが日々取り組んでいる仕事＝「業務」すべてが「サービス」
ITILの５つのアプローチ（ライフサイクル）
「業務」すなわち「サービス」をビジネス目標を達成するために、限られた資源で効率良く品質良く回していくためにITILはコアとなる５つのアプローチを示している。その５つを実践することでサービスをうまく回せる、マネジメントできるようになる。 そしてこの５つは、一連のサイクルになっている。
サービスストラテジ・・・全体方針や戦略
サービスデザイン・・・業務設計
サービストランジション・・・運用準備
サービスオペレーション・・・実際の業務の運営
継続的サービス改善・・・業務の運用状況の測定と報告、そして改善をサポートする
ITILの５つのアプローチを実行するための主なプロセス
５つのアプローチには、以下のような「プロセス」や「機能」と呼ばれるものがある。
プロセス・・・特定の達成目標を実現するための一連の活動
機能・・・ある業務に専念し、人の能力などのリソースやツールを活用し業務を遂行する専門組織
私のミッション
ITILの概要をざっくり説明したところで、私の役割は以下の実現が大前提になります。
「顧客」のビジネス目標を達成するために、
「顧客」から必要なリソース（ヒト、モノ、カネ）を得て、「サプライヤ」を擁しつつ「ユーザー」にサービスを提供する
それを実現するために「プロセス」を構築して管理を行う
大前提を踏まえて、顧客から私への具体的な要望として以下がありました。
重大な障害は発生していないように見えるシステムの状況を見える化してほしい
私のアプローチ
実際の運用活動を行う機能は、「サービスデスク」と「IT運用管理」ですか、そのなかで発生した重大な障害は、「インシデント管理」にて記録されているはずでした。
しかし、インシデント管理台帳は存在したのですが、１年以上前から記入が止まっており重大な障害があったのか無かったのか判断する情報がありませんでした。重大な障害がないのではなく、インシデント管理が実施されておらず、問題管理についてはその管理簿の記入さえもさてれいない状況がわかりました。
そこで、まず、私の実施したのは以下です。
「サービスオペレーション」サイクルの「インシデント管理」プロセス、「問題管理」プロセスを構築することにより、運用活動の状況を測定可能にすること
インシデント管理を実施
目標を設定して、日々の運用作業と並行してインシデント管理を実施した。
インシデント管理の目標を設定
月あたりのインシデント発生件数、未クローズ率を測定し、インシデントの滞留を防ぐ
未クローズ率をゼロに近づけること
インシデントの定義を徹底する
インシデントの定義が人により異なっており、「サービスの計画外の中断や品質低下」をインシデントとして認識できていないことがあった
通常できた操作ができなくなった等の品質の低下もインシデントとして管理した。
もれなく管理簿に記載する
サプライヤーに作業記録をもれなく行っていくことを再度意識してもらい、毎日朝のミーテングにて作業記録からインシデント管理への棚卸を実施した。
問題管理を実施
週に一回、インシデント管理から問題管理へのエスカレーションがないかを確認するミーテングを実施した。
運用状況の見える化
インシデント管理、問題管理を「もれなく」実施したことにより以下の計測ができた。
月あたりのインシデント発生件数・・・7.7
インシデント未クローズ率・・・10.9%
運用担当１人あたりのインシデントクローズ件数（6ヶ月間）・・・59.0
問題要因抽出率(※1)・・・127%
(注釈) ※1 問題管理によりインシデント発生要因を特定できた割合。発生要因が複数特定されると100%を超える。
✔️インシデント件数は、多めだがクローズ率を意識して高めたことにより、ユーザーにとってはストレスなくサービスをつかってもらえている
他の課題が浮き彫りになってきた
ここでは詳細は控えますが、、、運用設計が十分でないことが次々と見つかり課題が見えてきました。
✔️一人当たりのインシデントクローズ率が高いのは、各サブシステムの保守要員が１人であったためで、 サプライヤー、サービスプロバイダの体制が脆弱でありリスクを抱えていた。
✔️システム開発フェーズから在籍している１人の人員で業務を回しているため、日々の業務の手順書が不十分であり人員交代、人員増員ができない状況であった。
✔️インシデントの発生件数が高いサブシステムにEOSLを迎えているものを発見し、他のサブシステムを含めてEOSLの管理が運用設計から組み込まれていなかったことが明らかになった。
まとめ
「ITIL」と私（SHIFTグループ）にて「顧客」のビジネスを支える ITシステムの状態を正しく測定し、課題の抽出ができた。
「ITIL」のプロセス「インシデント管理」、「問題管理」を「もれなく」行うことにより、他の課題が明らかになり「効果的」に 業務プロセス改善活動が「無理なく」進められた。
最後までお読みいただきありがとうございました。
参考文献
ITILファンデーション シラバス2011
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール：Miyamori Kazuho
システム開発の作る側であったが、SHIFTの第三者検証による品質管理の標準化に感動してSHIFTに入社。テスト自動化、業務自動化、業務プロセス改善を通して、顧客にありがとうと言われるエンジニアを目指している。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/