Facebook Twitter

ジャンル

マネジメント 2023.03.24
twitter hatenabookmark

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

執筆: 三堀 雅也

バルテス・ホールディングス株式会社 R&C部 マネージャー

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

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

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

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

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

もくじ
  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つ

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

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

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

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

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

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

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

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

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

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

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

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

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

その例を以下に記します。

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

① インシデントの検出

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

検出パターンその1:意図した通りにインシデントを検出する

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

検出パターンその2:意図しないところでインシデントを検出する

例えば、「テストケースの手順中にフリーズした」など。
欠陥はテストケースとして作成していないところから検出される場合もあります。

検出パターンその3:欠陥では無いインシデントを検出する

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

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

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

インシデントレポートは、予め定義したフォーマットと記載ルールに沿って作成します。

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

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

④ 原因調査

対応する必要があると判断されたインシデントの発生原因が「欠陥」によるものなのかは、インシデントレポートが報告された時点では分かりません。

そのため、このフェーズでインシデントの発生原因を明らかにします。

⑤ 修正対応判断

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

インシデントの原因が「欠陥」であると判明しても、直ぐに「修正する」という判断にはなりません。

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

欠陥を修正しない場合のリスクと修正する場合のリスクを比較して、修正するかどうかを慎重に判断します。欠陥を修正すると判断しても、次にリソースとコスト、時間の問題が出てきます。
「修正するためのリソース、予算はあるか」、「リリース日までに修正、修正確認が完了できるのか」などを検討し、修正対応する時期を決めます。

修正することになった場合でも、例えば「リリース後に修正し、運用する中で改修版をリリースする」といったように、修正時期を遅らせると判断されることもあります。

⑥ 修正

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

⑦ 修正確認・再テスト

インシデントは開発側が欠陥を修正したらそれで終わり、というわけではありません。テスト側でインシデントが是正されているか、確認する必要があります。

インシデントの発生手順をなぞって期待どおりに動作することを「修正確認」し、NGとなったテストケースを「再テスト」します

インシデントが検出されなくなり、テストケースがOKになることで、初めて「インシデントが修正された」ことになるのです。

⑧ クローズ

インシデントの修正を確認したら、そのインシデントレポートはクローズとなります。

「クローズ」は「終了する」という意味です。

まとめ

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

ポイントは以下の2点です。

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

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

マネジメント
twitter hatenabookmark

執筆: 三堀 雅也

バルテス・ホールディングス株式会社 R&C部 マネージャー

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