納入したシステムについて、お客様から「不具合が出ていて・・」そんな指摘があった場合、まずは、どう対応すれば良いのか。
みなさん、こんにちは。セルネッツ竹本です。
今回は、不具合指摘のご連絡をいただいてから、顧客ファーストでどんな対応が必要になるのか、解説したいと思います。
指摘をうけ、まず最初の工程は、「具体的な事象確認」
当たり前のようでもありますが、納入システムに起因するバグかどうか見極めができない状況もあります。
ここで得たい情報は次のとおり。
1.今、起こっている具体的な事象
2.どんな操作によって発生したのか
3.特定のPCのみで発生する事象か(他のPCでも同じか)
4.再現性はあるか
5.これまで問題なく運用できていたのか
6.当該事象による影響は?(仕事にならない?)
これらの情報を手がかりに、原因究明にあたりますが、必要なのは「再現テスト」です。
お客様の指摘する事象が再現できればしめたもの。原因の特定は時間の問題です。
何故なら、プログラムを追跡することで問題が浮き彫りになるためです。
再現しない場合は、まず、原因究明よりも、不具合回避の策定と、この場を乗り切る代替提案を行います。
通常、よっぽど入り組んだ複雑なソース記述がなければ、再現はまず可能です。
◆原因特定により、停止したシステム。次のステップは不具合対応そのもの
原因にもよりますが、それに起因した要因を取り除く、または、回避処理を施すことで運用を見届けます。
ここでは暫定的であってもかまいません。
もしも、納入システムに起因するバグ認定であれば、対応後に「障害報告書」という形で、報告を書面提示します。
システム不具合は、必ずしも、納入システム側の非ではないケースもあります。
例えば、ネットワーク回線の障害や、前提外データの混在、明らかな操作ミス、サポートできない利用環境での動作など。
大切なことは、バグであれ、そうでない原因であれ、お客様の運用に支障がでている以上は、高い緊急度で、解決に取り組む必要があります。
責任所在がどこにあるのかは、この段階では後回しです。
◆障害によっては、データ復旧リカバリが必要な場合もある
これはゾッとする話ですが、システムバグによって、入力したデータが消えた、書き換わった。
そんなケースでは、本来あるべき状態に復元を求められることになります。
が、その仕組みが「設計の時点」で出来ていない場合は、なす術もありません。
対策は、システムデータを起動時の状態にする「自動バックアップ」くらしかありませんので、留意してください。
◆障害報告書の書き方。
(障害報告書に必要な要素)
1.不具合事象
2.原因
3.再現性の有無
4.今回の対策
5.今後の対策
6.障害がもたらした不利益(過去への影響も含む)
7.データ復旧リカバリの必要性
などです。
実務担当者をはじめ多くの関係者に迷惑をかけることになるので、書面によるレポートは必須ですし、誠意をもって今後に留意しなくてはなりません。
いろんな不具合を見てきましたが、避けられた不具合の多いことにも気付かされます。
その多くは、やはり「テスト不足」。そして、「設計面での考慮不足」が大半です。
以下の「コラム」でも紹介していますが、本当にテストの重要性は高いので、十分な動作テストを行い、障害を避けたいものです。
今回のテーマは、Excelマクロ開発に特化した内容ではなく、あらゆるシステム開発において、重要なポイントとなります。
本記事が、品質向上において、ご参考お役立てになれば幸いです。
