システム開発プロジェクトや稼動後の保守業務に携わっていると、日々、いろいろな問題が発生します。

例えば、開発フェーズではお客様の要件変更や考慮漏れに起因する設計変更の発生、テスト段階でのエラー発生等があります。
また保守フェーズでは、稼動中システムの異常停止やエラーの発生、誤動作、期待通りの結果が得られないといった問題が発生します(※1)

このようなシステムに関連して発生する問題をインシデントと呼びます。(※2）

インシデントは、その発生から対策の実施と解決（クローズ）までの一連のながれを管理し、コントロールする必要があります。

しかし、これがそう簡単ではありません。

小規模で短期的なプロジェクトでしたら、インシデントをEXCELシートに順次追記していってプロジェクトの完了時点で終わり、というだけで管理できるのですが、大規模または長期的なプロジェクトの場合は、記録するインシデント数が膨大になります。

また、インシデントの中には再現性がないため原因の解析が困難だったり、予算等の理由により本格対策を実施できずに、様子見や保留、代替手段での対応など、中途半端な状態におかれるものも少なくありません。

これらのインシデントがどんどん積み重なっていく中で、優先順位の判断を誤ったり重要なインシデントが未解決のまま埋もれてしまった、同じインシデントを二重登録してしまった、といったトラブルが発生する確率が高くなります。

このような背景があるためか、使いやすいインシデント管理ツールや問題管理ツールの類を探しているプロジェクトマネージャは意外と多いようです。

ところが既存のインシデント管理ツールをいろいろ調べてみても、いずれも「帯に短し、たすきに長し」で、組織やプロジェクトのインシデント管理ルールやレベルにぴったりマッチしたツールというのはなかなか見つからず、結局EXCELでやるしかない、とあきらめてしまうようです。

また、オープンソースのプロジェクト管理ツールもあるのですが、セットアップなど使い始めるまでの手間を考えると二の足を踏んでしまいます。

簡単に始めることができて、使い込んでくれば高度な使い方も可能になるインシデント管理ツールがあるといいですよね。

弊社では、このようなお客様のためにProot(プルート)インシデント管理システムを提供しています。 以下、簡単にその特徴を説明します。

Prootインシデント管理システムでは、管理者がインシデント票のデータ項目を自由に追加・変更できます。

インシデント票や問題管理票といった入力フォームをテンプレートとしてあらかじめ定義しておいて、プロジェクト毎に使用するテンプレートを指定できるのです。

例えば、ソフトウェア開発プロジェクトであれば、「障害発生バージョン」「解決バージョン」「制限事項」などの項目がインシデント票に必要になります。

協力会社に対応を依頼する形態では、ステータスとして、「依頼済」「確認待」なども必要になってきます。

このテンプレート定義では、各項目ごとに編集権限を設定できるようになっています。これによって・・・

協力会社や委託先とインシデント情報を共有し、必要な項目を相互にインシデント票に入力する運用が可能になります。このような運用を行うことで、解決までの全ての経緯をツール上に記録することができます。

右のフローチャートをご覧ください（クリックで拡大します）

まず、「依頼側」がインシデントの発生を認識したならば、速やかにインシデント票を作成し「対応側」に連絡します。

「対応側」は担当者を決定し、インシデント票に入力します。
同時にステータスを「進行中」に変更します。

「対応側」が「調査・対応作業」を実施した結果を「回答コメント」として入力します。（ここでステータスを「確認待」に変更する運用も可能です）

「依頼側」は「回答コメント」を参照して、「確認」作業を実施し、インシデントが解決されているかどうかを確認します。
確認結果がＯＫでもＮＧでも「依頼側」は結果を「追加コメント」に入力します。ＮＧの場合は「対応側」は「調査・対応作業」から繰り返します。

解決されていれば、「依頼側」はステータスを「クローズ」にして完了となります。

もう一つインシデント管理で考慮すべき点として、インシデントを共有する人数を適切に設定することが挙げられます。

人数が多くなりすぎ、一つのグループでのインシデント数が膨らんでしまうと、管理者のコントロールが難しくなることと、各メンバーが共有する情報量が多くなりすぎることにより運用が行き詰まります。

Prootインシデント管理システムでは、階層型プロジェクト構成をとることでこれを回避しています。

例えば、右図の構成をとった場合は「ＰＭＯ」のメンバーは配下の全プロジェクトのインシデントを参照できます。

また、「Ａ社様プロジェクト」のメンバーは「Ｘシステム」と「Ｙシステム」のインシデントを参照できます。

これにより、個々のプロジェクト内では全てのインシデントを共有し、上位プロジェクトでは影響度の高いものや遅延の大きいものだけを管理するという運用が可能となります。

経験則によれば、インシデントを共有するメンバーは、５人～１０人程度が適切のようです。

さて、簡単にProotインシデント管理システムについてご紹介してきましたが、皆さんのプロジェクトではこのようなインシデント管理あるいは問題管理がきちんと出来ていますでしょうか？

もしインシデント管理ツールを検討してみたいということでしたら、Prootインシデント管理システムには無料お試しサイトもありますので、是非一度お試しください。
Prootインシデント管理システムのサイトはこちらです。

※1)運用ミスやプロジェクトマネジメントに起因する問題はここでは対象外とします

※2)インシデント管理と問題管理を分離する考えかたもありますが、ここでは両方をまとめてインシデント管理として扱っています。

イラストは、ソザイヂテン http://www.sozaijiten-business.rash.jp/ を使用しています。