ITサポートを担当していた数年間、私は「インシデント」と「問題」の違いを意識したことが一度もありませんでした。障害の記録を書くにあたり、私も同僚たちも2つの単語のどちらを使っても大差ないような感覚で書いていましたし、サポートアナリストもほぼ同様だったと記憶しています。Zendeskの場合、インシデントと問題とでは、チケットタイプの機能が異なります。ITサービスマネジメント（ITSM）プラクティスでは、チケットタイプの目的が区別されています。ただし、この点についてITSM専門家の間でしばしば議論の的になります。ITILのフレームワークでも、問題とインシデントの定義は、バージョンによって若干異なります。
インシデント管理と問題管理。これらが別々のプロセスとして扱われていて、ややこしいと感じるのも無理はありませんが、この区別によって得られるワークフローの効率を考えると、無視できません。大所帯のITサポートデスクになると、専任の問題管理グループが設けられている場合もあります。そのメリットについては後ほど説明するとして、まず、インシデントと問題の違いに注目してみましょう。
「インシデント」とは、顧客がサービスを利用できなくなっている状態。「問題」とは、その原因です。トラブルが起こった際に速やかに復旧すること、それがインシデント管理です。ITサポートの現場では、アプリケーションのパスワード再設定を要求するような単純な状況も、インシデントと呼ばれます。パスワードの例で説明すると、複数のスタッフが同一のアプリケーションのパスワード再設定を要求してくる場合、何か別の事情が絡んでいる、すなわち根本的な問題の存在が疑われます。そこでサポートアナリストは、Zendeskでチケットを作成し、なぜ立て続けにログインに失敗したのかを調査します。この問題を解決するには、何らかのトレーニングをスタッフに行うだけで済む場合もあれば、アプリケーションまたはインフラそのものに関係している場合もあるでしょう。こうした調査をチケットで扱うことにより、作業が効率化し、担当者の割り当ても容易になります。
チケットは、担当するエージェントだけが閲覧できるようにします。これによってレポートから曖昧さが排除されます。また、関連性のあるインシデントをリンクさせることで、1つのチケットを更新すれば自動的に関連するインシデント全てに反映させることもできます。そして問題が解決されれば、関連付けられたインシデントもすべて解決済になります。
ただし、問題管理とは、対処療法的に根本原因を調べることだけではありません。サービスが中断される可能性を予見し、それを未然に防ぐことでもあります。たとえばサーバーのディスク障害について考えてみましょう。冗長化しておけばサーバーは動作を続行し、サービスを提供し続けますが、やがて残った方のディスクも故障してしまえば、インシデントに対するチケットが続々と送られてくる結果になるでしょう。したがって、問題チケットをオープンし、ディスクが故障した原因を突き止めて交換しておきます。そうすれば、顧客が異変に気付くこともありません。
前述したように、インシデント管理と問題管理は分けておくことで、メリットが得られます。インシデント管理の目的が、できるだけ早くサービスを復旧することだとすれば、問題については専任の管理者またはグループに問題をエスカレートするのが最善策と言えます。グループで時間をかけて原因を調査することで、インシデントレポートの大量生産を回避し、サービスの即時復旧に全力を注いでいるスタッフを間接的にサポートします。しっかりした問題管理のプロセスは、手抜かりのないチェンジマネジメントプロセスにもつながります。
すべてのITサービスデスクで専任の人員を確保できるわけではありません。しかし、少なくともインシデントと問題の目的の違いをきちんと理解しておけば、より明確なエスカレーションパスやレポートの定義が可能になります。結果的に、より顧客中心型のITサポートが実現されるのです。
この記事は、シンプルで強力なITサービス管理を達成するためのZendeskのアプローチをテーマとするシリーズのパート４です。
パート2：チェンジマネジメントとパート3：顧客満足度も併せてご覧ください。
社内ITをサポートする方法については、こちらをご覧ください。
