実運用時にインシデント（障害）がないことは、利用者にとって価値あるITシステムの必須条件である。過去に起こったインシデントを分析して根本的な対策を打ち、問題のある開発プロセスへの改善活動へと繋げることは非常に重要な活動といえる。
この改善活動においては、インシデントの分析をいかに行うかということも大事だが、インシデントの記録自体をどう行うかがその後の改善活動の成否を大きく左右する。実際、「蓄積されたインシデント情報はあるものの、まとまりがなくフィードバックしにくい」、「各種分析を試みたものの、なかなか傾向が見出しにくい」といった声が品質マネジメント周辺ではよく聞かれる。
インシデントの記録が難しいのは、インシデント自体の多様性や立場による捉え方の多様性があるために、改善活動に繋がる記録の仕方というのがなかなか定まらないところに要因がある。今回は、そのような背景がある中で、報告者が少なくとも抑えるべき視点は何なのかを考えてみたい。
インシデントデータの記録における留意点
インシデント記録の際、留意すべき主なポイントとして①プログラム上の動作としての原因だけでなくどのように作りこんだかが記録されているか、②分類される原因が主要プロセスごとに構造的に整理されたものになっているか、が挙げられる。
①についてはインシデントの記録を開発の各フェーズに上手くフィードバックするには、作りこみや除去失敗の具体的な過程が記録されていることが重要である。実装上の原因だけを突き止めることは応急的な対応とはなるものの恒久的な対応とはなりにくい。
開発チームへの実際の行動へフィードバックするには、障害自体の原因ではなく、実際の開発行動として何故認識ミスをしてインシデント原因を作りこんだかの記録が必要である。先進的な技術を扱うような場面でない限り、ほとんどのインシデントは、コミュニケーション不足や成文化されていないノウハウの伝達ミスなど技術的課題以外のところが根本的な原因となっていることが多い。
②についてはインシデントの原因区分を構造化して整理することで、原因同士の包含関係や類似性を容易に把握できるようにしておくことが重要である。
ある程度記録が蓄積されてきたり報告者が変わったりすると、原因区分の粒度が不揃いになったり、重複する区分が生じてくる。こうなると新規インシデントを分類する際の負荷にもなる上、分析にも活用しづらい。定期的に区分を見直し、構造的に整理し直すことが必要となる。
例えば「仕様の不良」はインシデント記録上頻出する原因区分のひとつであるが、実効的な対策を立てるには、どの段階で／どの文書で仕様不良を作りこんだか、レビュー作業のどの段階の／どの作業で摘出すべきだったかの観点で整理することが必要である。(※1)。
これらの情報を元に整理することで、設計者、レビューア等それぞれの立場での改善点を見出しやすくすることができる。
※1 より一般的な構造化は例えばOrthogonal Defect Classification等がある。インシデント記録をチーム連携に活かす
規格化された製品の機械的大量生産の中での不良発生要因を分析する場合と異なり、ソフトウェア開発ではメンバのコミュニケーションやプロセス間の意思伝達のミスにより起こった原因を見出し対策を打つ必要がある事が多い。インシデントの原因分析や記録が契機となり、チームの連携の見直しに繋がることが望ましい。
技術的に成熟している企業であれば、概ね仕様通りの品質を確保するのは容易であろう。ただし人間が開発する以上、勘違いや具体化不足による認識ミスの伝播は起こりうる。過去に起こったインシデントを構造化し各プロセスへのフィードバックをしておくと、各段階でのミスの防波堤となりうる。
“だいたい動く”から”完璧に動く”への品質の詰めには、インシデントの記録をノウハウ化し、チームの知識として共有されることが必要だ。