日付入力欄...ありえない日付チェック
顧客コード欄...マスター存在チェック
などはコーディングしても手間は変わらないし、チェックしないのは開発者の手抜きと思うので実装します。
問題にしたいのは、業務ルールに基づくチェックです。
売上入力画面で販売日の欄があるとします。デフォルトは当日値とします。翌日に過去日のデータを入力することもあるので、更新項目になっています。この欄は非営業日の値はダメというルールになってます。
普通に考えると、営業日カレンダー機能を設置して、チェックをする事になります。
機能分析/工程表に営業日カレンダーチェック機能...xx人日
単価と数量と消費税の欄の妥当性チェック機能......xx人日
(*)消費税はキッチリ税率通りにならないのことがあるので手入力にしてます。±10円程度の差は OKとしても、単価*数量の10%や50%などの値が入らない用にチェックしたほうが良いと思うのです。以前に 50万円* 1株の入力を1円 50万株(数値は怪しいです) と入力して、株価がパニックになったニュースがありました。その時もチェックを噛ませておけば防げたように感じました。
このような感じで、チェック機能の行が数行から数十行続くことがあります。開発コストも累積します。
(明文化しないでチェックを埋め込むケースもあるかも知れませんが、それだとチェック仕様が見えません。詳細仕様に記して、ユーザーに見せない手もありますが...業務ルールに関わる箇所だとそうは行かないです)
コストの商談段階で、「非営業日の入力や消費税の誤入力などはユーザー教育を徹底させるので、チェック機能は省いて欲しい」と言われるそうな。
商品Aの付属品で商品Bが付いているとき、A,B一緒に売らない....この辺になると運用回避でもいいかも知れません。
コスト抑制の見地からそのように考えるのでしょうが、聞き入れるとマーフィー則が訪れます。
案の定、休日日付のデータ 、1823年や4000年のデータ、商品より高い消費税、マイナス消費税(赤伝はマイナスで入力するので負値を許している)のデータが発生している.....トホホな状態。
運用担当者は RDBとAccessをリンクして、直接データを修正しているそうな......危険なことこの上ない。
整合性Checkという僅かなコストをケチった見返りは大きいですね。
修正してくれと泣きつかれたり、なんでチェックしてないんだと逆切れされたり、開発側が悪者にされたり、ろくなことは在りません。
初期段階で確認しておきたい項目です。実装して置いてコメントアウトしておくとかwwww
ユーザーを説得するのも大事な仕事です。