トレンド情報 / 記事を探すCOLUMN

システム開発におけるインシデント管理の重要性

更新日|2019.07.17

三堀雅也

8607-00067-1.jpg

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

では、インシデント管理はどのように行うものでしょうか、勘所は何処にあるのでしょうか。 これらを本稿で解説していきます。

インシデント

「インシデント管理」の本題に入る前に、「インシデント」と「欠陥」の違いを明らかにしておきましょう。

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

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

【インシデント】
発生した事象の中で、調査が必要なもの。

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

テストを実施する過程で、原因がどうであれ「期待した結果と異なる」ような事態が発生すれば、それが「インシデント」となります。
そのインシデントの原因が、プログラム内のロジック誤りや漏れ等である場合、その「誤りや漏れ」が「欠陥」となります。
簡単に言えば、「インシデント」は何かの出来事、「欠陥」はプログラム中に潜んでいる誤動作を引き起こすもの、というように踏まえておけば良いでしょう。

本稿では、「インシデント」を上掲の定義にあるように、"発生した事象の中で、調査が必要なもの"として扱っています。

これまでインシデントや欠陥の違いを確認してきましたが、他にも類似の言葉として、「不具合」や「バグ」といったものもあります。これらを厳密に区別して使い分けることは、その組織やプロジェクトの従来からの経緯もあるでしょうから、無理に統一せず、必要に応じて行えば良いでしょう。しかし、用語の捉え方の齟齬によって、うまく意思疎通できないこともあり得ますから、類似の用語がそれぞれどんな意味で使われているか、規格などではどのように定義されているか、今一度 確認しておくと良いでしょう。

※なお、JSTQBでは2019年3月27日に改訂された「ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018.J02」にて、「インシデント」という言い回しが削除され、「不正」で統一されています。
また「インシデント管理」、「インシデントレポート」はそれぞれ「欠陥マネジメント」、「欠陥レポート」という言葉に置き換わっています。
参考記事:全てバグ?ソフトウェアにおけるエラー、欠陥、フォールト、故障の意味と違い

インシデント管理のポイントは2つ

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

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

インシデントレポートのフォーマットを定義する目的は、レポートを誰が書いても、漏らさず、正確に記載するためです。本稿では"インシデント管理"を主眼にしているため、インシデントレポートを記述する項目・作法に関する解説は割愛し、別のコラムに譲ることにいたします。

インシデントレポートの運用フローは、その組織やプロジェクトで異なるものですが、大きく分けると以下のフェーズで区分けされます。「検出・報告」→「原因調査・修正判断」→「修正」→「修正確認」→「クローズ」このようにフェーズ分けすることで、そのインシデントは今 何の対処をしているのか、分かるようにします。併せて、そのインシデントは今、誰が対処しているかを分かるようにします。

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

インシデント管理 運用フローの例

インシデントの運用フローをもう少し詳しく見ていきましょう。インシデントの管理は、「インシデントレポート」を介して行われ、その運用ルールをフローとして定義します。その例を以下に記します。

  1. インシデントの検出
  2. インシデントの記録・レポート
  3. インシデントの有効/無効判断
  4. 原因調査
  5. 修正対応判断
  6. 修正
  7. 修正確認・再テスト
  8. クローズ

1.インシデントの検出

「インシデントの検出」となる状況は大きく3つのパターンがあります。

検出パターンその1:意図した通りにインシデントを検出する
「テストケースに沿ってテストを実施した結果、テストケースの期待結果や機能仕様書の記述の通りに動作しなかった時」をイメージすると分かりやすいかと思います。
欠陥を検出するためにテストケースを作成し、その狙い通りに欠陥を検出した形です。

検出パターンその2:意図しないところでインシデントを検出する
例えば、「テストケースの手順中にフリーズした」など。
欠陥はテストケースとして作成していないところから検出される場合もあります。

検出パターンその3:欠陥では無いインシデントを検出する
例えば、「テストケースの期待結果の通りには動作しているものの、操作中のレスポンスが悪い」など。
欠陥で無くても、システムを使用するユーザにとって不利益となるような事象もインシデントとして扱います。

2.インシデントの記録・レポート

検出したインシデントを開発側へ報告するために「インシデントレポート」を作成し、開発側に提出します。

インシデントレポートは、予め定義したフォーマットと記載ルールに沿って作成します。インシデントレポートの記載の仕方にも、大切な作法やノウハウがあるのですが、インシデントレポートの記述に関する解説は、前述のとおり、別のコラムで扱うようにいたします。

3.インシデントの有効/無効判断

開発側がインシデントレポートの内容を確認し、機能仕様と異なる動作なのか、ユーザにどの程度の支障が出る事象なのかといったところを把握し、対応する必要があるかどうかを判断します。

4.原因調査

対応する必要があると判断されたインシデントのインシデントレポートが報告された時点ではその事象の発生原因が「欠陥」によるものなのか分からないため、このフェーズでインシデントの発生原因を明らかにします。

5.修正対応判断

欠陥のある対象プログラムの影響範囲、影響度合いを開発側が調査し、修正を行うかどうか判断します。

インシデントの原因が「欠陥」であると判明しても、直ぐに「修正する」という判断にはなりません。
システム内はプログラムが複雑に絡み合っており、その中から欠陥を取り除くとなると、欠陥部分だけではなく、関連する別のプログラムにも手を入れなければなりません。しかし、別のプログラムを改修するということは新たな欠陥を作りこんでしまう可能性があるということでもあり、プログラムを安易に修正してしまうと欠陥を増やしてしまう事態になってしまいます。

欠陥を修正しない場合のリスクと修正する場合のリスクを比較して、修正するかどうかを慎重に判断します。
欠陥を修正すると判断しても、次にリソースとコスト、時間の問題が出てきます。
「修正するためのリソース、予算はあるか」、「リリース日までに修正、修正確認が完了できるのか」などを検討し、修正対応する時期を決めます。
修正することになった場合でも、例えば「リリース後に修正し、運用する中で改修版をリリースする」といったように、修正時期を遅らせると判断されることもあります。

6.修正

欠陥を修正すると判断された場合、その欠陥を開発側が修正します。

7.修正確認・再テスト

インシデントは開発側が欠陥を修正したらそれで終わり、というわけではありません。テスト側でインシデントが是正されているか、確認する必要があります。
インシデントの発生手順をなぞって期待どおりに動作することを「修正確認」し、NGとなったテストケースを「再テスト」します
インシデントが検出されなくなり、テストケースがOKになることで、初めて「インシデントが修正された」ことになるのです。

8.クローズ

インシデントの修正を確認したら、そのインシデントレポートはクローズとなります。
「クローズ」は「終了する」という意味です。

インシデント管理の必要性

8607-00067-3

これまで インシデントの運用フローを解説してきましたが、インシデントの数がごく少ない件数である場合は、各関係者の連絡のやり取りに委ね、厳密に管理する必要は無いかもしれません。
しかしインシデントの数が増えてくれば、きちんとしたルールの元で管理しなければ、どのインシデントが今どんな状態なのか、誰がボールを持っているか分からなくなり、プロジェクトが大混乱状態に陥ることになってしまいます。
そのような状態では、「インシデントが放置されて、深刻な故障に発展する」、「安易に修正を行って、別の重大インシデントを引き起こす」といった重大事故を引き起こしかねません。

逆にインシデントを適切に管理できていると、不要なトラブルが防止できることでプロジェクトが安定するようになります。

加えて、インシデントレポートにさらなる価値が見いだせるようになります。
インシデントレポートの内容を詳しく分析すると、「どのようなインシデントが起こりやすいか」、「システム開発のボトルネックはどこか」といったプロジェクトの傾向が見えてきます。
蓄積されたインシデントレポートを集計、分析することで、インシデントの発生条件や欠陥の作り込むパターンを探れば、今後のシステム開発に活用できる資産となるでしょう。
欠陥レポートは、そのプロダクトの品質を可視化するための、また、開発・テストを改善するための、情報の宝庫なのです。

ただし、資産として活用できるようにするには、無闇やたらに集計してもうまくいきません。「蓄積したインシデントレポートからどのような分析をしたいのか?」をあらかじめ決めておかなければならない点に注意してください。
分析したい内容を精査し、それに必要な項目を反映したフォーマット、運用フローをデザインすることも「インシデント管理」の一環なのです。

おわりに

今回の記事ではソフトウェアテストの工程の肝とも言えるインシデント管理について、「インシデントの運用フロー」をベースに解説いたしました。ポイントは以下の2点です。

  • インシデント管理は、インシデントの対応状況を可視化するためには必要不可欠であること。
  • インシデントレポートは単なる記録帳票ではなく、プロダクトの品質を可視化し、開発・テストを改善するための、情報の宝庫であること。

インシデント管理のプロセスを導入・改善される際、こちらの記事でご紹介した内容をぜひお役立てください。

資料ダウンロード

ライター:三堀雅也

バルテス株式会社 R&C部 副主任研究員

モバイルアプリ、Webサイト、ソーシャルゲームのテスト業務経験後、バルテスに入社。業務系システムを中心にテスト業務全般(管理、計画、設計、実施)に従事。またマネージャとして、オフショアとのブリッジ対応...