

【運用管理の勘所⑦】「問題管理」とは?
システムマネジメントサービス部の石田です。
「運用管理の勘所」第7回目は「問題管理」について解説します。


「問題管理」とは
システム部門において問題発生時の対応と解決は重要な業務です。しかしながら、いわゆる"前向き"な業務でなく非生産的な業務のため、その負荷をいかに軽減/削減するかが、システム部門にとって、大変大きなテーマと言えます。
問題が発生したとき、迅速かつ適切に対処し、根本原因を取り除き、再発防止策を策定するまで監視下に置くことが、システム全体の信頼性向上に繋がります。そのための管理手法が問題管理で、その目的は、
- 問題の早期解決
- 問題の再発防止
の2点に尽きます。個々の場面で発生する問題について発生箇所・事象・原因などを記録し、体系的な統計処理を定期的に実施することにより、以後のトラブルの再発防止、トラブル発生時の早期解決につなげ、より安定性の高いシステムにすることが可能となるわけです。
なお、トラブル発生時の迅速な回復のための管理方法は、"回復管理"の領域となります。
早期解決のため、強力に推進する
問題管理の第一の目的は、トラブルの迅速な解決です。そのための重要なポイントは、問題管理担当者が、トラブル解決に向け強力な推進力を発揮することにあります。
多くの場合、運用管理部門だけではなく、他部署、他社(メーカー、ベンダー)と連携してトラブル解決にあたりますが、原因調査や対応策検討を依頼する場合、要求が曖昧であったり、進捗チェックがおろそかになったりすると、大幅な解決遅延を招く恐れがあります。
そのため問題管理担当者には、厳密な進捗チェックと問題がある場合の強力な推進力が求められます。
トラブル削減目標を作る
トラブルの迅速な解決と同様に重要なことは、トラブルの再発防止です。再発防止のためにはトラブル情報の蓄積と再利用が役立ちます(後述する「問題情報を蓄積する」「蓄積した情報を利用する」を参照)
が、そのような環境だけ整えても直接トラブル件数の削減にはつながりにくいものです。明確な数値的な削減目標を設定することによって、トラブル削減計画も具体化してゆきます。
また、目標達成時のインセンティブを用意することは、問題管理担当者のモラルアップのために有効です。
問題情報を蓄積する
トラブル発生時にはまず、現象から対応個所を特定し、異常内容と異常個所に応じた対処を施しますが、これを「一次対応」といいます。さらに、原因を特定し、再発防止策を講じることを「恒久対応」といい、恒久対応を施してこそ根本解決となります。
問題管理においては、発生から根本解決までの一連の情報を、「問題管理台帳」といわれるデータベースに記録し、蓄積された情報を一元管理することが重要です。
この情報を有効利用することにより、トラブルの早期解決やトラブル件数の減少につなげ、運用品質を向上させることができるからです。
蓄積した情報を利用する
同様の問題への対応を迅速化するため
トラブル発生時に問題判別を行う場合、過去に同じような現象が発生したことがあるかどうかを調べることが有効です。また、最近の変更情報の確認も重要な情報源です。「問題管理台帳」、「変更管理台帳」を参照し、同様の現象があれば、大幅な時間短縮が図れます。
潜在的なトラブル要因を見つけるため
「問題管理台帳」に蓄積された情報を定期的に分析すれば、トラブル発生を待たずに先手を打ってトラブル防止対策を行うことも可能です。
例えば、毎月、トラブル統計情報の分析を行っていれば、「あるハードウェアのトラブルが増加傾向にある」とか、「オペレーションミスが増えている」といった傾向を把握でき、「ハードウェアを交換する、点検回数を増やす」、「運用手順を改善する」など、しかるべき対応を取ることにより、トラブル件数を減少させることができるわけです。
このようにトラブル情報の統計分析を行うことは、引いては、システム運用の安定化、高品質化につながっていくはずです。
ヘルプデスク系の問い合わせ/クレーム情報と連携する
クライアントPCが高度になり、多くのOAツールが導入されるようになって以降、いわゆるヘルプデスクをIT部門に設置し、各種問い合わせを一括で引き受けるケースが増えています。
ヘルプデスクを自社に自前で設置することの是非は別として、問い合わせの多い内容については、ユーザー教育の実施や、掲示板へのFAQ(よくある質問への回答集)開設という方法も検討すべきでしょう。
前置きが長くなりましたが、ヘルプデスクにくる問い合わせ、クレームの一部が、問題管理の対象となるため、ヘルプデスクと連携するしくみが必要です。例えば、ヘルプデスクが管理する情報の中から問題管理へ受け渡す場合の基準や手順を、あらかじめ決定しておきます。
体制
問題管理を円滑に実施するために、責任や担当が明確な体制を整備する必要があります。
- 問題管理責任者
- 問題管理の全責任を負う(例:システム運用部)
- 問題管理担当者
- 問題管理を行う(例:システム運用課長)
- 対応者
- 恒久対応を行う(例:運用担当者)
- 受付者
- 問題を受け付け、問題管理を起票する(例:オペレータなど)
管理項目
問題管理の本質は問題情報の一元管理、データベース化、統計的活用の3点です。よって、管理項目は標準化し、一意に決定できるパラメータとして管理・記載することが重要で、一般的には、いわゆる問題管理表(「問題管理台帳」)を用いて一元管理します。管理項目とその内容を下表にまとめます。
- 発生状況
- 発見者、受付者、発生日時、問題内容など
- 影響
- 影響範囲、影響度、緊急度など
- 一次対応状況
- 対応内容、対応日時、対応者、コール状況など
- 解決(終了)状況
- 原因、終了理由、調査完了日時、終了日時など
問題管理の流れ
一つの問題に関する「問題管理」は問題報告を受け付けたところから始まり、定例会で「終了」が宣言されたところで終わります。従って解決が長引いている問題は、定例会の場で複数回、審議対象となり解決が促進されることになります。
- 問題の受付
- 問題を発見した者は、受付者に報告を行う
- 受付者は問題を受け付け「問題管理票」を起票する。問題管理データベースに自動的に登録され、「問題管理台帳」として一元管理されるしくみを予め整えておく。この後の状況は、各担当者が「問題管理台帳」に記載し、関係者が問題状況を参照できるようにしておく
- 受付者は問題管理担当者に報告する
- 対応者の任命
- 問題管理担当者は問題状況の確認、整理を行い、当該問題の対応者を任命する
- 問題の重要度、緊急度、影響度に応じて必要があれば、関連部署へ状況を広報する
- 一次対応
- 対応者は暫定対処を実施する。回復のための具体的な管理方法・手順は「回復管理」に述べられている。ヘルプデスク系の場合、問題の5~9割はここで解決する。必要に応じてメーカーなどへ、対応依頼する
- 対応者は随時、状況を「問題管理台帳」に記載する
- 問題管理担当者は問題状況の確認を行う
- 問題が解決するまで1~3を繰り返す
- 恒久対応
- 一次対応後、対応者は恒久対応を実施する
- 問題の終了
- 1つの問題は、恒久対応の終了を「問題管理台帳」に記載し、「状況確認定例会」で終了宣言されたところで終了(クローズ)する
定例会と統計情報の報告について
問題管理責任者は進捗状況などの管理のため、定期的に「状況確認定例会」を召集する必要があります。
基本的には月次・週次に、問題管理責任者、問題管理担当者、対応者が出席し、「問題管理台帳」の記載内容をもとに、問題状況/進捗の確認、恒久対策の検討、問題統計の分析などを行います。
- 週次定例会の主目的は
- オープン中 (未解決) の問題、新たに発生した問題の、対応状況や担当者を明確にすること
- 月次定例会の主目的は
- 前月に発生した問題の「発生個所」、「影響度」、「緊急度」など、問題そのものに関する項目の統計情報を明らかにし、問題解決の迅速化や再発防止に役立てること
いかがでしたでしょうか。次回は「回復管理」について紹介します。