2008_05_13－ユーザーサイドから見た品質確認。

２００８年５月１３日発行

分割ラインです

　★　品質管理編　★

　　
　ユーザーサイドから見た品質確認。
　　
　　
　　ユーザーサイドから見ると、品質の詳細はよくわからないものです。
　　私も、長年ユーザーに常駐しながら新規作成だけでなく、
　　　故障対応やメンテナンスも行っていましたから、
　　　　よくわかるのですが、エンドユーザーに
　　　　　　検証確認を依頼しても、正しく確認できているのは、
　　　　　　　　５０％ぐらいではないでしょうか？
　　
　　
　　
　　いろいろな規模のプロジェクトがあるので一概には言えませんが、
　　ユーザー側に情報システム部門があり、重要プロジェクトとして
　　専任メンバーいない限りは、
　　検証チェックは甘いと考えておかなければなりません。
　　
　　エンドユーザーも日常業務と兼任している場合が多く、
　　　　全ての機能について検証確認ができているかと問えば
　　　　　　「不可能」と答えるでしょう。
　　
　　扱う試験データの内容によっても、やる気は大きく異なります。
　　試験ために作成した擬似データと本番データでは、
　　　　モチベーションが大きく違います。
　　たぶん、どこのユーザーでも同じだと思います。
　　
　　
　　
　　
　　本番間際になって、慌てて検証確認に入るエンドユーザーもいます。
　　本番データを扱って試験を行うと、
　　　　かなりの精度で故障が見つかってきます。
　　　　　　なぜなら、本物の値や計算値は頭の中に入っているからです。
　　
　　
　　
　　特にユーザー側の担当者が日常業務と兼任している場合は、
　　　　本番間近までは、真剣に行っていないことが多いのです。
　　
　　　　故に複雑な条件確認試験まで、確認がしっかり行われていない
　　　　　　場合が多いのです。
　　
　　
　　このような兼任体制のプロジェクトでは、開発時における
　　　　単体試験やシステム試験が疎かになっていると、
　　　　　　本番で大きなしっぺ返しが来ます。
　　
　　
　　エンドユーザーが忙しくて、確認している時間が取れないとき、
　　せめてシステム担当者にこんなお願いしてみてはいかがでしょうか？
　　
　　
　　
　　
　　システム試験以降の結果や故障一覧を取り寄せてみるのです。
　　　　・試験結果一覧表（試験内容と検証日付が載っているもの）
　　　　・故障状況内容一覧（故障内容と対応内容が載っているもの）
　　　　・仕様書（設計書）一式
　　
　　　　確かに内容を見ても最初は意味不明でわからないかも知れません。
　　　　しかし、設計書なども一緒に見ていると、
　　　　　　　　次第に故障内容が理解できてくると思います。
　　
　　
　　
　　
　　　　　　故障の傾向が見えてきたら、チェックする重点箇所も
　　　　　　　　　　絞れるのではないでしょうか？
　　
　　
　　そこから、エンドユーザーが推測できる不安な試験などについて
　　　　確認するでだけでもかなりの精度で品質は向上して行きます。
　　
　　
　　
　　システム担当者が見る故障傾向とエンドユーザが見る故障傾向とは、
　　　　捕らえる視点が違うのです。
　　　　　　故障の内容を見れば、補強しなければならない
　　　　　　　　試験内容が業務視点で見えてくるのです。
　　
　　
　　
　　　　エンドユーザー担当者が多忙な時は、
　　　　　　このような確認をしてみるのもいいかも知れません。