障害記録票と問合せ管理簿の2重管理問題

応用情報技術者試験で、インシデント管理をExcelの障害記録票と障害管理簿で2重管理していた問題が出ていた。
この手の不手際がよくありそうなのでメモ。
以下ラフなメモ書き。

【元ネタ】
平成22年度春期試験　応用情報技術者試験（AP）午後問題

平成22年度春期試験　　応用情報技術者試験（AP）午後問題解答

上記の問11にITILのサービスサポートのインシデント管理の問題がある。
問題の詳細は省略。
その事件として、まずかった点は二つある。

問合せ管理簿で、他の問合せの最新状況が反映されていなかったために、過去直近の問合せと原因は同じと判断を誤ったこと。
もう一つは、問合せ管理簿に、プログラム改修の要否や改修予定日などが書かれていなかったために、ユーザに正しい情報を即答できなかったこと。

ITの運用保守業務では、インシデント管理ではまず障害の暫定措置や早期復旧を最優先にして、根本原因の解決は問題管理フロー以降で念入りに対策をとるのが基本。
インシデント管理で迅速に正しい判断を行うには、過去に蓄積された情報を早く正しく検索して、判断を誤らないようにすることが大事。

上記では、Excelで障害記録票と問合せ管理簿の2重管理をやっていたのだろうと思われる。
だから、障害記録票から問合せ管理簿への最新情報のコンバートが手作業で面倒であり、運用がルーズになっていたと思われる。

また、Excelの問合せ管理簿からプログラム改修の要否や改修予定日などの項目が漏れていたように、インシデント管理で必要な情報が表示されていなかった。
この手の運用は、最初から正しい運用を行うのは難しく、何度も試行錯誤しながら、Excelの問合せ管理簿へ項目をどんどん追記して保守していくようになる。
だから、保守コストもバカにならない。

上記の問題を読むと、Excelによる障害管理や問合せ管理は時代遅れになっているのでは、と思ったりする。
障害管理や問合せ管理は10年以上前から既に存在しており、PCがない状況では、紙の台帳で管理していた。
PCが普及してからも、台帳をExcelに焼き直しただけで管理していた。
だから、後から検索しやすくするように、付箋をつけたり、索引を手作業で作ったり、PostItなどでノウハウを書き込んだり、独自に改良していた。
その頃のできるプロマネは、運用ルールを作るのがうまく、その運用ルールをExcelの台帳として見本を作り、管理するのが基本だった。

しかし、Excelの障害管理簿はすぐに肥大化しやすく、一度ファイルが壊れると非常に困る代物。
また更新履歴を構成管理の配下に置いていないから、どれが最新の障害管理簿なのかすぐに分かるように厳重に管理しているのが普通。
だから、運用ルールが厳しくなるほど、障害管理簿への記入が遅れて、最新化が遅れて、色んな作業のリードタイムが長くなってしまう。

Excelのプロジェクト管理は何故良くないのか: プログラマの思索にも書いたけれど、Excelによる障害管理の問題点は二つに尽きる。
一つは、Excelでは作業ステータスの最新化や集計に手間がかかること。
もう一つは、Excelの台帳であろうとも構成管理されていないために更新履歴が残っていないので、過去の修正の経緯や問合せの解決方法を追跡しづらいこと。

現代ならRedmineやTracなど優れたBTSがあり、しかもプロジェクト管理機能がとても優れているので、障害の入力も最新化も集計も簡単だし、全文検索できるから、いつでも欲しい情報をすぐに探せる。
又、SCMリポジトリにある成果物の修正履歴はチケットに紐づいているから、何故こんなパッチが施されているのか、という経緯も簡単に探すことができる。

そして、昔のプロマネのやり方が現代のプロジェクト管理に合わなくなっている気もする。
上から押し付けられた運用ルールでは実際の現場にフィットしない時もある。
Excelの台帳を見本として見せて、今からのノウハウをExcelの台帳へ貯めていく手法は古いと思う。
現代なら、Excelではなく、Wikiにまとめた方が情報共有もやりやすい。

また、現場のメンバーとふりかえりなどでフィードバックしてもらい、皆ですこしずつ改善しながら、運用ルールを現場に見合った内容へ変えていく。
Agile開発では、イテレーションと言うタイムボックスがあり、ふりかえりを行うタイミングが自然に生まれるので、そのタイミングにフィードバックプロセスを回すようにすれば、チームの一体化が図れるだけでなく、次のイテレーションに向けて少しずつ改善していく契機になる。

プロジェクト管理の手法も、10年前と比べて静かに進化しているように思う。