サービスの開始！（インシデント管理／問題管理）- ITの品質向上とコスト削減からとらえたITIL®

Reading Time: 1 minutes

当連載記事について

当連載記事では、ITIL®の研修を多く手掛ける専門家が、分かり易い口語体でより実際的な観点からITIL®を解説しています。サラッと読みながらもITIL®に基づいた考え方をより実践的なレベルへ落とし込むことができます。また、ITIL®に準拠するための機能を備えたITサービスマネジメントツール「ManageEngine ServiceDesk Plus」を提供するゾーホージャパンより、欄外コラムとしてツールの詳細や関連機能の説明を行います。ITIL®の概念を把握しつつ、ツールを活用した場合のイメージを広げる際の一助となりましたら幸いです。

※ITIL® is a Registered Trade Mark of AXELOS Limited.

はじめに

第九回の記事では、「変更管理プロセス」「サービス資産管理および構成管理プロセス」「リリース管理および展開管理プロセス」を使用して本番環境にITサービスを移行しました。ということで、いよいよサービスが開始されます。今日はITサービス開始以降のフェーズについてお話していきたいと思います。

サービスを開始したばかりの時

ITサービスが本番環境に移行されたら、ユーザはITサービスを使用し始めることになります。つまり、ITサービスが開始されるということですね。ITIL®で表現すると「サービスオペレーション」のフェーズが開始されるということです。日本語で言えば、「運用開始」です。表現的にはサービス・プロバイダ視点となりますね。

それはともかく、ITサービスが開始されるとどうなるか。ITサービスの場合、ユーザから「操作方法がわからない」とか、「パスワード忘れちゃったからパスワードをリセットして」とか、「データベースにある顧客情報をもとにマーケティング活動を行いたいから、今年登録した顧客情報を提出してほしい」という問い合わせや依頼が発生します。

また、ITサービスが始まったばかりだと、ITサービスが突然停止したり、思っていた程の処理速度が出なかったり、といったの不具合が発生します。このような現象をITIL®では「インシデント」といいます。

このインシデントが発生したら、サービス・プロバイダは放置していて良い訳がなく、当然、ITサービスを復旧させないとなりません。この復旧を目指す活動が「インシデント管理プロセス」です。そしてインシデントといわれる現象を引き起こしている根本原因を特定して解決するのが「問題管理プロセス」となります。本日はこの2つのプロセスをお話したいと思います。

なお、ユーザからの問い合わせや依頼への対応については次回お話します。

インシデント管理プロセス

まず、インシデント管理プロセスについて。

インシデントとは、前述したとおり「ITサービスが停止したり、思っていたより処理速度が出なかったりする現象」を示す言葉で、その「原因」は含まれません。例えば、「プリンターが壊れて印刷できない」という場合、「印刷できないという現象」がインシデントです。

「どう壊れたか」とか「なんで印刷できない」という話は原因になりますので、インシデント管理プロセスで取り扱う範囲外となります。当然、日々、障害対応されている方々は、「原因が含まれないのなら対応のしようがないじゃないか」とお考えになるかもしれません。それ自体は気持ちもよくわかりますし、間違いとは思ってません。ただ、ITIL®的には間違いなのです(苦笑。

というのも、インシデント管理プロセスは、あくまでもインシデントを解決して「事業のマイナスのインパクトを抑える」ことがメインなんです。極端に言えば、ユーザから「次の会議で使用する資料を５部印刷したいが、プリンターが壊れてで印刷できない」と言われた場合、インシデント管理プロセスはどうするか。

インシデント管理プロセスとしては、そのプリンターは複合機でコピーの機能は使えそうであることを把握した上で、ユーザに対して「申し訳ありませんが、コピーの機能は使えるので手書きで資料を作成して、5部コピーしてください」という対応行っても、構いません。

もちろん、このような対応では結果としてユーザ（顧客）満足度が下がるかもしれません。しかし、インシデント管理プロセスの目的は、あくまでも「事業のマイナスのインパクトを抑える」ことなんです。だから今の例で一番避けたいのは「会議が開催できなくなること」なのです。であれば、会議を開催できるような方法を考えて実践すればよく、プリンターを直す必要はありません。

このように、原因がわからなくても対応はできるのです。全てのインシデントにおいてこのように対応できるかどうかはわかりません。場合によっては、インシデント対応だけではなく根本原因を追究して原因を取り除いた方が、小さな影響で済む場合もあるでしょう。ただ、それは結果の話であって、インシデントが発生したときに何を考えなければならないかといえば、「原因追求」ではなく「事業への影響を抑える方策」である、ということなんです。そしてこの考え方に基づいて対応するのがインシデント管理なんですね。

問題管理プロセス

次に問題管理です。問題管理はインシデント管理と違ってインシデントの根本原因を追究して解決していくことを目指します。だから、問題管理プロセスで問題を解決したらインシデントはもう発生しなくなります。逆に言うとインシデントは問題が解決しなければいつでも再発するということになります。よって、インシデント管理プロセスだけあってもあまり意味はなく、一緒に問題管理プロセスも行うことで、みなさんがイメージする一般的な意味での障害対応となります。

ただ、そうはいってもすべての問題が解決できるとは限りません。特にお金の問題が絡む場合は解決できないことがあります。

例えば、あるソフトウェアが原因でインシデントが発生したとします。根本原因を追究したら、ソフトウェアのバグが原因であることが分かりました。でもこのバグが理由でインシデントが発生する可能性は非常に低く、5年に1度あるかないかという程度です。しかも発生した場合の経済的な損失は30万円程度ということが分かりました。一方、解決するためにバグを修正するには、瑕疵担保期間が過ぎているため、サプライヤに500万円を支払う必要があります。合わせて、サービス・プロバイダ内でも作業が発生するため、3人月程度の工数が必要であることが分かりました。この時このバグを修正するでしょうか？

企業によるとは思いますが、たぶんバグは修正しないでしょう。費用対効果が見合いませんから。とはいえ、ITIL®の問題管理プロセスが「このままバグを放置してよいと思っているか」といえば、もちろん、そうではありません。万が一、インシデントが発生した場合に備えて、少しでも被害を抑えるような対策を行ったり、5年に1度程度の可能性を10年に1度程度にするような対策を施したりします。このように、被害が最小限になるための対策は行います。それが問題管理プロセスなんです。

最後に

それでは次回はユーザからの問い合わせや依頼については次回お話します。

＞＞記事一覧：ITの品質向上とコスト削減からとらえたITIL®

執筆者情報

日本クイント株式会社　コンサルタント　吉村友秀（よしむら　ともひで）

主要資格：ITIL® エキスパート、公認情報システム監査人（CISA)

ServiceDesk Plusのインシデント管理／問題管理機能について

連載記事をご一読頂き、ありがとうございます。今回は、ITサービス開始後に発生する「インシデント管理」や「問題管理」に焦点を当てた解説がされていましたね。ServiceDesk Plusには、ITIL®に則ったITサービスマネジメントを行うために、「インシデント管理機能」「問題管理機能」が備わっています。

記事内で、問題管理プロセスは「インシデントの根本原因を追究して解決していくことを目指す」と紹介されていました。このため、ServiceDesk Plusではインシデント管理機能と問題管理機能がお互いに連動するように設計されています。

例えば、サービスデスク担当者が「プリンターの調子が悪いです」というお問い合わせを受け取った場合、最初は応急的に「プリンターを再起動してみてください」や「別フロアのプリンターを利用してください」といった回答で乗り切っていたとします。ITIL®的に、これは「インシデント管理」ですね。ServiceDesk Plusでも、このような対応をインシデント管理機能で実施できるようになっています。

しかし、同じようなお問い合わせが1日に何件も発生し、それがずっと継続するので、とうとう担当者が根本問題の解決に乗り出したとします。この時、ServiceDesk Plusの画面では、以下図のように「インシデント」情報を引き継いで「問題」情報を作成できます。