WEBマガジン

「「インシデント管理」「問題管理」プロセスの導入から定着まで」

2011.09.09 株式会社宇部情報システム  永山 弘/登根 浩

 ITサービスマネジメントのデファクトスタンダードとして「インシデント管理」、「問題管理」が注目され始めたのは、2001年にTSO(イギリス出版局)が改訂発行したITIL バージョン2の書籍の普及からである。ITILバージョン2は7冊の書籍と1冊の副読本で構成されており、そのうち「サービスサポート」(いわゆる【青本】)と「サービスデリバリ」(いわゆる【赤本】)は特に広く普及した。

表 1 ITIL バージョン2の書籍~
ITIL バージョン2の書籍

 その後、日本版SOX法に向けた内部統制対策として、2007年頃から「構成管理」、「変更管理」も注目を集めるようになった。その頃から、ITIL準拠と銘打ったソフトウェアが次々にリリースを開始されていった。
 2007年には、ITIL バージョン3が、各管理プロセスの関連性、網羅性および継続性を強めた形で、5冊の書籍に集約され発行された。しかし、現在もなおITIL バージョン2【青本】、【赤本】の印象は強く、ITILバージョン3は普及していないようだ。なぜITIL バージョン3が普及しにくいのか?それはバージョン2以上に適用の難しさにあると考えられる。
 ITIL バージョン2でも、実際に普及したのは、【青本】、【赤本】2冊ぐらいであり、他の5冊の書籍と1冊の副読本はそれほど浸透していない。また、「インシデント管理」や「問題管理」、「構成管理」や「変更管理」「リリース管理」など【青本】の管理プロセスは全般的に企業に受け入れられたが、【赤本】では一つの管理プロセスである「サービスレベル管理」くらいではないだろうか。「サービスレベル管理」は、顧客とITサービス提供者のSLA(サービスレベルアグリメント)の必要性から普及したものと考えられる。
 このように、内部統制その他の動機から、自己流のサービス管理を整理してレベルアップする必要にせまられたとき、ITILバージョン2のイイトコどりをして、一定の成果に結びついた後、いまさらバージョン3に準拠する必要性が見当たらないといったことではなかろうか。そもそも、ITIL準拠まで一気に数段ステップアップすることに無理があるし、全てのITサービス提供者にとって、ITIL準拠が真のゴールなのかも疑問である。
 以下からは、「インシデント管理」を実践した経験を通した、個人的な考えを述べることにする。私(登根)は、「攻めの運用」「運用サービスの見える化」などITサービス提供者が抱える悩みを解決するため、2006年頃から取り組み始めた。
 ITILには参考資料や対応ソフトウェアも多数存在しているが、教科書通り適用することは難しい。現在の業務の上に、無理にITILの管理プロセスを上乗せすると、ITサービスの品質低下を招く恐れがあるからだ。どの企業においても、ITILの「インシデント管理」や「問題管理」などとは呼んでいなくても、障害管理や是正計画、移管管理などITILの対応する作業は実践しているはずである。したがって、現状業務から段階的にレベルアップしていくことが望ましい。

【教訓1】一般的にITサービスの品質向上と呼ばれている、ITILが負担になってしまうと逆に品質低下を招く。

 ITILを始める場合の多くは、「インシデント管理」、「問題管理」から検討するケースが多い。その理由は「インシデント管理」、「問題管理」は部分適用が可能でSmall Start Quick Winの手法として認知されているからだ。部分適用を「邪道」だと喝破する方も多いのだが、小さな成功を積み上げることは、モチベーションを維持するのに重要である。

【教訓2】「インシデント管理」、「問題管理」は分かり易い。

 ここで、業務効率化の観点で「インシデント管理」、「問題管理」を適用することを考え、現状の障害管理プロセスを簡単に分析した例を示す。

分析1.現状の障害管理は、どのように実践しているか?

  1. 開発/運用担当者は、Excelなどを利用して独自の方法で管理している。
  2. 障害が発生した場合は、関係者へ電話またはEメールなどで連絡している。
  3. 障害報告書を作成して、管理責任箇所へ事後報告している。
  4. 開発/運用担当が独自の方法で分析して、削減策を講じている。

分析2.現状の障害管理には、どのような問題があるか?

  1. 情報の分散、サービス品質のバラつき
  2. 障害対応が優先になるための連絡遅れや連絡漏れ
  3. 障害報告の遅れや忘れ
  4. 個別対策では削減効果がない。

分析3.現状の障害管理を、効率化するには何をすべきか?

  1. 標準的なルールを策定する。共通の管理基盤を準備する。
  2. 障害対応に負担を掛けない連絡方法、ルールを策定する。
  3. 報告書作成に負担を掛けない。
  4. 全体の状況を把握し、継続的に改善するためのルールを策定する。

 このような現状分析をもとに、目的とゴールを明確にして、プロジェクトとして進めていくとよい。

 次に、「インシデント管理」の管理項目の定義について。「インシデント管理」管理項目を将来の様々な分析に利用するかも知れないと考え、必要以上に多くの管理項目を定義するケースがよくある。管理項目数の増大は、管理項目の入力、分類の選択判断などの時間ロスが発生するため、そのまま業務負担の増加につながる。本来は、管理項目を決定する前に分析手法や目標などを定義できれば良いが、そこまでは初めから準備できないことがほとんどだと思う。

 継続性について。「インシデント管理」=ITサービス品質向上という気持から、今やっているサービス以上を目指そうと言うモチベーションも重要だが、現実に継続できる体制があるか冷静になって振り返ってみよう。 2007年に某分科会活動にて「ITサービスの品質向上」について1年間研究した。そこで、「ITサービスに対しての向上心に上限がないから過剰になる」「過剰になるから無理になる」「無理する割には効果が出ない」という連鎖が起こっている現実を参加者同士で確認した。ITサービスは適度なレベルを続けることが重要である。その分科会活動の中で、「ITサービスの品質向上」を、それぞれ「ITサービスの品質」と「ITサービスの向上」に分割して考え、「品質」を顧客との「合意」とし、「向上」をITサービス提供者の合意レベルに合わせる「改善」として捉えて検討した。

【教訓3】ITサービスの品質を「合意」、向上を「改善」と捉え、組織として、安定したITサービスの提供を続けるための機能がITサービスの品質向上である。

 これまでのことを念頭において、「インシデント管理」の管理項目を検討してみよう。先ずは、現状の障害管理で利用している項目と、新たに「インシデント管理」で管理したい項目を比較しながら、必要最低限の管理項目に絞る。現状の管理項目をベースに検討する事で、過去の障害対応履歴など、既存のデータを共通の管理基盤へ取り込む場合にも、現状の運用をなるべく変更させない方が良い。
 次に、管理項目を入力する際の手間や分析効率を考えて、マスタから項目選択させる場合に注意する。「インシデント管理」を正しく運用するために重要なのは情報の精度である。担当者によっては正しく選択項目を選ばない場合もあるので、誰がやっても同じ判断になるように各選択項目の定義は詳しく分かり易くしておくこと。
 また、「インシデント管理」の運用フローについても、ITIL書籍の参考例や体制図をそのまま適用するのではなく、現状の体制や手続きを考慮してフロー化すること。

【教訓4】インシデント管理項目は必要最低限からスタート。現状の運用をベースに。

 そして「インシデント管理運用」開始。開始して先ず直面する課題が「担当者の文章力」。何が書かれてあるか本人にしかわからない内容で、第3者が読んでも理解できない。システム担当者の観点で書かれると、報告を受け取る顧客には全く理解できない文章も少なくない。
 残念ながら、文章の内容まではシステム的には監視できないので、文章については人間がモニタリングして、継続的に担当者へ指導していくしか方法はない。よって、報告内容をモニタリングできる機能や体制の整備も必要となる。

【教訓5】システム担当者の文章力を継続的に指導する。

 「インシデント管理」は障害をなるべく早く解決するためのプロセスであるのに対して、インシデント発生件数を減らすのが「問題管理」プロセス。よく「インシデント管理」と「問題管理」を合わせて管理している企業の話を聞くが、大抵は対策未決のまま未クローズインシデントが山積み状態になっている。
 仮にクローズしているインシデントを参照しても、対策の内容は「チェックリストを作成する」「再度確認を徹底する」など、詳細分析しないままの定型文章になっている。根本対策ではないので、インシデントは削減されないし、対策内容によって余計な手続きに手間取り、インシデント数が増加した事象すらある。
 近年、私たちは、根本原因の分析に「なぜなぜ分析」の手法を取り入れている。システム担当者の分析能力の向上につながり、事前のリスク発見にも役立つのではないかと期待している。「なぜなぜ分析」については複数の書籍が出ているので、そちらを参照してほしい。

【教訓6】「インシデント管理」と「問題管理」は本来の目的が異なるため分けて管理する方が望ましい。

 インシデント件数の削減や早期解決を図るために、個別のインシデントまたは問題対策と併せて、ABC分析の手法を取り入れている。インシデント発生件数における発生原因のトップ2の削減を計画していくものだ。
 一般的には「人的ミス」を削減するケースもあるが、全体のインシデント件数のうち人的ミスの割合はいかほどだろうか?全体的な発生状況から分析することで効率的に効果の高い対策を計画することができる。例えば、関係者の知識の底上げを図るには、Eラーニングによる教育などの対策も有効である。

【教訓7】PDCAを回してインシデントを削減する。

 以上、筆者の経験から、「インデント管理」と「問題管理」の導入に関わる課題について述べた。現場への定着から改善サイクルを回せるまで数年かけるつもりで取り組んではどうだろうか。

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。