「インシデント管理簿」という言葉を聞いたことがあるだろうか？IT業界でよく使われる問題管理手法の一つで、発生した案件毎に発生日時や担当者、不具合のカテゴリ、優先度等々、複数の項目を割り振り、状況のログを記載し進捗や状況を管理するやり方だ。これは前職にて、とあるプロジェクトで同僚からこのインシデント管理簿を使用した問題管理について手解きを受けた。これが非常に有効で、その後様々な配置についた際に必要に応じてこの簿冊を作り、案件対処に当たってきた。
一例を紹介しよう。ある時、ある地区で使われているシステムに属する端末のうち、私の担当だけで約七千台の端末の換装を行わなければならなくなった。設置当初は当然、山のように不具合が発生するわけだが、他のチームが不具合の管理に右往左往する中、私はこのインシデント管理簿を使用し、問題の管理と統制をおこなった。そのうち、面白いことに気が付いた。
その一つが、オペレーション上の優先順位が低い案件や、不具合の影響があまりない小さい案件などを、優先度「低」のフラグをつけて「忘却することなく後回し」にできることだ。機材の納入業社は、自分たちに都合の悪いことは、ほったらかしにすればそのうち納入先が忘却の彼方に忘れてくれることを願っているようなフシがある。それを、記録しておくことによって、一切忘れることなく後回しにでき、より優先度の高いクリティカルな不具合にリソースを割けることができるようになるのである。
また、もう一つが、同種不具合の相関を取ったり、多数の不具合の全体を俯瞰することにより、問題の根本の推測ができるようになることである。このおかげで、モグラ叩きのように発生した問題に対して反応的に対応したりすることなく、より問題の本質を見極めた上で、その本質に対してリソースを配分することができるようになることである。
また、問題に対してアサインした担当者を記載しておくことで、責任の所在を明確にし、宙ぶらりんなタスクを発生させないようにしたりする利点もある。
もう一つ、私がこれは大きいと思う機能は知識管理としての役割である。これまでおこなった処置をログのように記録しておくことから、そこには大量のノウハウが記載されることになる。内容を記述していく中で、これは後々重要な知見になると感じた部分にフラグを立てて後で検索できるようにしておいたり、青字で目立たせておいたりすると、巨大な知識のアーカイブの出来上がりだ。
また、忘れてはならないのが担当者間の申し継ぎとしての機能だ。担当者がコロコロ変わったとしても、インシデント管理簿がログの機能を果たすので、それを見れば過去に何が起こったか、今何が優先度が高いのかが一目瞭然である。
以上のように5つの利点を特出しして解説したが、他にもまとめると次のような利点がある。①言った言わないのすれ違いの防止②複数の担当者間の申し継ぎ③内容に応じた優先度の付与付けの容易化④優先度の低い案件を忘却を防止しつつ後回しにすることが可能⑤対処案件の抜け漏れの防止⑥過去対処案件とノウハウ両方の集積による知識の資産化⑦不具合の同時発生時の割り振りの明確化と容易化⑧実施事項や合意事項などのエビデンス化⑨マスデータの蓄積、ざっと数えただけでこれら九つのメリットが存在する。有効に活用できた場合、管理する側から見ると、能率の向上はかなり強烈なものになる。当然、ここで伏線回収だが、インシデント管理簿による管理があまりに便利なため、一度これを使うとインシデント管理簿原理主義ともいうべき熱烈なユーザーに私はなっている。当然、IT業界以外においても様々な業界でこのやり方は転用可能だ。
ただし、いくつかのデメリットもある。それは、インナースレットに弱いということである。どういうことかというと、メンバーの中にやる気が無い人物がいたとして、その人物がインシデント管理簿への記載を手を抜いて適当に行なったり、悪意のある上書き行為を行った場合、その一連の行為への対応を行なったり軌道修正したりするのに非常に手間がかかるということである。また、もう一つ、管理される側から見ると、インシデント管理簿による管理はそれなりの負担になるため、それを念頭においた上での適切な使用が必要となることは言うまでもない。
コメントを残す