かなり間が空いてしまいましたが、こちら の続きになります。
以前に記事では「”バグ”の扱いについて関係者で共通認識を持っておく必要がある」と記載しましたが、具体的にはどんな内容について共通認識を持っておくべきなのでしょうか？
バグの定義
まずはバグの定義です。一般的には「システムが想定通りに動かないこと」をバグとするのようです。そうであればこの「想定」が共通認識として関係者内で共有されていることが前提になります。通常この「想定」は「詳細設計書」や「ユーザーマニュアル」に記載されますが 「詳細設計書」「ユーザーマニュアル」 の作成目的は一般的に、
・詳細設計書・・・システムを構築するため
・ユーザーマニュアル・・・ユーザーにシステムの使い方を説明するため
なので「バグを定義するため」という観点では記載内容が不十分なケースも多々あるのではないでしょうか？
ですので「バグを定義する」といった観点もドキュメント盛り込むことを意識していただければ、サービスイン後のトラブルを回避できるだけでなく、システムそのものの品質向上にもつながります。
バグへの対応ルール
つぎはバグへの対応ルールです。対応ルールを定義するにあたりバグをその影響度からレベル分けした上で対応ルールを示すのが一般的です。
影響度大：業務への影響が大きく代替手段がない・・・24時間/365日、即時対応
影響度中：業務への影響がそれなりにはあるが代替手段あり・・・9-18時/営業日、 即時対応
影響度小：業務への影響が一部に限定され代替手段あり・・・9-18時/営業日、3営業日対応
といった具合ですね。
システムによっては「外部ユーザーへの影響」とか「物理的な損害に繋がるか？」など影響度の考えもそれぞれだと思いますが「どんな些細な不具合でも即刻対応すべきである」という極端なお考えを当然と認識している人（いわゆる正論くん）もいますので注意が必要です。
いかがでしょうか？ システム構築中はどうしても「バグ」について考えないという思考に陥りですが、「どんなに注意して開発してもバグは発生するもの」として準備を行っておくことが現実的な対応となります。
コメント