IT道場その５補足 ～エラーチェック実例～

前回の記事で紹介したエラーチェックについての実例を紹介します。

請求入力画面　＝＞　請求データ　＝＞　支店締め処理　＝＞　実績データ　＝＞　全支店更新処理　＝＞　会計仕訳データ　

という流れにおいて、
会計仕訳データに不正なデータを入れないために、必須チェックを全支店更新処理にて行っていましたが、
・この段階は最終段階であり、締切日当日の夜の処理となる
・エラーに引っかかってから原因を特定した頃には支店担当者は既に帰宅している
・従って、修正が翌日となり、データ連携が遅れる

という問題がありました。

必須チェックは、請求入力画面では行っていましたが、
請求入力画面にも、
　他システム１　＝＞　請求データ
　他システム２　＝＞　請求データ
　請求データ　＝＞　自動作成の請求データ
の流れがあり、入力画面で制御を行っていても他のシステムから入ってくるデータに同様の制御がされている保証はありませんでした。

そこで、その中間であり、その後の工程が一本である「支店締め処理」の段階で必須チェックを追加しました。

これを行うことで、仮にエラーとなっても、その場でわかるため、担当者が既に帰ってしまっていた、という問題を防ぐことができます。

さて、この実例を通じて得られる鉄則を列挙します。

①　エラーチェックは工程の前段階に置く。ただし、工程の分岐・合流を考えて、たとえ冗長となっても必須のロジックは主要なポイントすべてに配置する。（多重チェック）

②　エラーチェックの目的は「早期発見」である。一般にエラー対応は時間がかかるため、締切までの時間は長ければ長いほどよい。
　　特に、締切が業務時間外となる場合は、エラー対応が業務時間内か時間外かで、効率・効果が大幅に異なる。
　　最低でも昼間、できれば締切の１日以上前に特定、解決することを目指すべき。

③　当然であるが、エラーチェックを行うためには、プログラム・システム的な視点はもとより、業務の流れについての一定以上の知識・理解が必要である。