システム開発におけるインシデント管理の重要性と運用フロー例

システム開発におけるテストを円滑に進めるための重要な事項として、「インシデント管理」があります。

用意周到にテストを計画し、設計し、それを実行して、うまくインシデントを抽出できたとしても、インシデントが適切に管理されていなければ、インシデントの対応遅れ、対処漏れなどの重大なミスが引き起こされる危険があります。

では、インシデント管理はどのように行うものでしょうか、勘所は何処にあるのでしょうか。

本記事では、インシデントとは何かを解説し、さらに適切に管理するためのポイントや具体的な運用フロー例をご紹介します。

もくじ

1. インシデントとは
   • インシデントとは？
   • 「欠陥」との違い
2. インシデント管理の重要性
3. インシデントを適切に管理するために定義すべき2つ
   • インシデントを報告するレポートのフォーマット
   • インシデントレポートを運用するフロー
4. インシデント管理の運用フロー例
   • インシデントの検出
   • インシデントの記録・レポート
   • インシデントの有効/無効判断
   • 原因調査
   • 修正対応判断
   • 修正
   • 修正確認・再テスト
   • クローズ
5. まとめ

1．インシデントとは

「インシデント管理」の本題に入る前に、まずは「インシデント」とは何か、「欠陥」の違いについて明らかにしていきます。

インシデントとは？

インシデントとは、発見が遅れると重大な事件・事故に発展する可能性を持つ出来事や事案・事象のことです。
システム開発においては、調査が必要な事象のことを指します。テストを実施する過程で、原因がどうであれ「期待した結果と異なる」事態が発生すれば、それが「インシデント」となります。

JSTQBの用語集「ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02」では、下記のように定義しています。

【インシデント】

発生した事象の中で、調査が必要なもの。

※なお、JSTQBでは2019年3月27日に改訂された「ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018.J02」にて、「インシデント」という言い回しが削除され、「不正」で統一されています。

また「インシデント管理」、「インシデントレポート」はそれぞれ「欠陥マネジメント」、「欠陥レポート」という言葉に置き換わっています。

「欠陥」との違い

「インシデント」と「欠陥」は、混同されることがよくありますが、両者はそれぞれ違う意味を持っています。

JSTQBの用語集「ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02」では、下記のように定義しています。

【欠陥】

コンポーネント又はシステムに要求された機能が実現できない原因となる、コンポーネント又はシステムに含まれる不備。たとえば、不正なステートメント又はデータ定義。実行中に欠陥に遭遇した場合、コンポーネント又はシステムの故障を引き起こす。

インシデントの原因が、プログラム内のロジック誤りや漏れ等である場合、その「誤りや漏れ」が「欠陥」となります。

簡単に言えば、「インシデント」は何かの出来事、「欠陥」はプログラム中に潜んでいる誤動作を引き起こすもの、というように踏まえておけば良いでしょう。

他にも類似の言葉として、「不具合」や「バグ」といったものもあります。

これらの用語のとらえ方は、組織やプロジェクトによって様々であり、無理に統一する必要はありません。しかし同じ組織・プロジェクト内で用語の認識がずれていると、うまく意思疎通できないこともあり得ます。類似の用語がそれぞれどんな意味で使われているか、規格などではどのように定義されているか、今一度チーム内で確認して認識を合わせておくとスムーズです。

2．インシデント管理の重要性

システム開発において、インシデントの管理は重要です。なぜなら、インシデントを適切に管理できていると、不要なトラブルが防止でき、プロジェクトが安定するようになるからです。インシデントの数がごく少ない件数である場合は、各関係者の連絡のやり取りに委ね、厳密に管理する必要は無いかもしれません。

しかし、インシデントの数が増えてくれば、きちんとしたルールの元で管理しなければ、どのインシデントが今どんな状態なのか、誰がボールを持っているか、が分からなくなり、プロジェクトが大混乱状態に陥ることになってしまいます。

そのような状態だと、以下のような重大事故を引き起こしかねません。

• インシデントが放置されて深刻な故障に発展する
• 安易に修正を行って、別の重大インシデントを引き起こす

このような事態を避けるためにも、インシデント管理は重要です。

また、適切な管理によって、インシデントレポートにさらなる価値が見出せるようになります。インシデントレポートの内容を詳しく分析すると、以下のようなプロジェクトの傾向が見えてきます。

• 「どのようなインシデントが起こりやすいか」
• 「システム開発のボトルネックはどこか」

蓄積されたインシデントレポートを集計、分析することで、インシデントの発生条件や欠陥の作り込むパターンを探れば、今後のシステム開発に活用できる資産となるでしょう。
欠陥レポートは、そのプロダクトの品質を可視化するための、また、開発・テストを改善するための、情報の宝庫なのです。

ただし、資産として活用できるようにするには、無闇やたらに集計してもうまくいきません。「蓄積したインシデントレポートからどのような分析をしたいのか？」をあらかじめ決めておかなければならない点に注意してください。

3．インシデントを適切に管理するために定義すべき2つ

インシデントを適切に管理するためには 、以下の２つがポイントになります。

• インシデントを報告するレポートのフォーマットを定義すること
• インシデントレポートを運用するフローを定義すること

それぞれ解説していきます。

インシデントを報告するレポートのフォーマット

インシデントレポートのフォーマットを定義する目的は、レポートを誰が書いても、漏らさず、正確に記載するためです。

インシデントレポートのフォーマットは、テスト実施が始まる前に決めておく必要があります。プロジェクトの途中でルールを変更すると、混乱の元となるためです。フォーマットに盛り込む項目、対応の流れをあらかじめ開発側とテスト側で協議し、きちんと文書化しておきましょう。

インシデントレポートを運用するフロー

インシデントレポートの運用フローもテスト実施が始める前に決めておくことが必要です。運用フローは、その組織やプロジェクトで異なるものですが、大きく分けると以下のフェーズで区分けされます。

「検出・報告」→「原因調査・修正判断」→「修正」→「修正確認」→「クローズ」

このようにフェーズ分けすることで、そのインシデントは今 何の対処をしているのか、分かるようにします。併せて、そのインシデントは今、誰が対処しているかを分かるようにします。

次章で運用フロー例をご紹介します。