社内SEのインシデント対応について

社内SEをしていたとき、ユーザーからの問い合わせ対応をしつつ、システムへの機能追加や見つかった不具合の改修対応を行わなければならなかった。

あらためて振り返って、当時の環境についてどのようにしたらよかったのかを考えたい。今回は、予定外の対応となる問い合わせ対応（＝インシデント対応）に注目していく。

当時の業務プロセス

当時の問い合わせ対応に関する業務プロセスを整理すると次のようになっていた。なお、これはヘルプデスク担当の業務ではなく、システム管理者である私自身が行っていた業務である。

サービスデスクも設置していたものの、個別システムに関する問い合わせについてはサービスデスクでは対応できなかったため、そのままエスカレーションされて対応していた。結果的に、ユーザーからはサービスデスクではなく直接私へ連絡が来ていた。

改善後の業務プロセス案

改善後のプロセス案を整理した。

改善後プロセスのポイントは下記2点と思っている。

1. 問い合わせ窓口をフォームまたはサービスデスクに集約し、ユーザー接点を統一すること。
   • 簡単な問い合わせでシステム管理者の時間が奪われないようにすることを狙う。
   • 最初はシステム管理者へ直接連絡が来ることも多いと思うが、サービスデスクがユーザー接点の単一窓口となることで、次第にシステム管理者への直接の問合せは減ってくることが期待される。
2. インシデント管理システムに記録を蓄積していくこと
   • 記録の蓄積によるナレッジ化を狙う。
   • 最初はサービスデスクからシステム管理者へのエスカレーションは多いと思うが、記録が蓄積されてくるにつれて、サービスデスクで一次回答できる割合が増えてくることが期待される。
   • そのためには、システム管理者も面倒くさがらずに、しっかりとインシデント管理システムに記録をつけて行く必要がある。

上記のようなプロセスとは別に、インシデントの根本原因となっている問題の解決のためのプロセスや、プロセス自体を改善するためのレビュープロセスのようなものも整備していく必要があると思う。

まとめ

ただ問い合わせを対応するだけではなく、「どうしたらもっとよりよくなるか」という観点でプロセスを組み立てることが重要。どんな業務においても、組織としての継続的改善のためのプロセスを模索していきたい。

おすすめの本

ITIL 4 の勉強を始めてFoundation試験に合格しました。本記事を書く上でも非常に参考になった書類です。