至素根譚 (しすこんたん/syscontan)

ミスから出たミス

 巷では、システムの「ミス」を何とか未然に防ごうと躍起になっている。
筆者も過去に多くの「ミス」を犯したが、まだ「首」がつながっている。
それは、本当の事を他人に報告していないからである。
誰が言うものか!
「墓場」迄「TAKEOUT!」
筆者のみならず「正直に報告を受けた人」もその「判断」「処理」に苦しむことになる。
だから何事もなかったように「闇」から「闇」へ…
時には「ミス」だと思い込む「ミス」なんかして…
 筆者の経験から独善的に「ミス」を大別してみたい。
決して学問的でないことを予め言っておく。

1 原票記入ミス
金額の記入ミスが典型的である。
責任の所在は基本的にお客様にある。
システム開発担当者には文句が来ない。

2 指示ミス
作業指示の間違いで「指示書」の記入ミスがある。
現場の責任者が責められる。
システム開発担当者には文句が来ない。

3 入力ミス
単純にオペレータのミス。
「ケタずれ」等がある。
システム開発担当者には文句が来ない。

4 関連チェックミス
上記の「原票記入ミス」「指示ミス」「入力ミス」の中には「システムチェック」で未然に防ぐことが出来るものもある。
お客様は「チェックできた筈だ!」とシステム開発担当者に「責任転嫁」することがある。
結局「今後気を付けます!」なんて言ったりして(本人は納得していないが)

5 計算処理ミス
どうもみても、悪いのはシステム開発担当者。
「高級菓子」「上司」といっしょに頭を下げに行く。
時には「始末書」なんか持参して…

6 印刷ミス
「欠け字」「化け字」「フォントミス」「帳票の使用ミス(色違い・表示年度違い)」等がある。
受託処理の場合は大問題になる。
「ハガキ」「通知書」等が個人宅に届いてしまった時には「大火」になる。

 ここまではミスの「原因」「責任」は明確に議論できる。
ここに、もうひとつ厄介な「ミス」が付け加わる。
それは「リカバリー処理ミス」である。
そもそも「リカバリー」という言葉自身が公の場で「認知」されていない。
言い方によっては、システム全体の品質が疑われるからだ。
「営業」「おエラ方」は、
「このシステムはリカバリー処理をするような事は絶対ない!」
と根拠のない「ハッタリ」でお客様に強調!
したがって「リカバリー処理」の「見積」はされたことがない。

recovery.gif

「ミス発生」は「何時」「何処」で起きるか分からない。
「リカバリー処理」は「ミス発生時」のみに行われる。
その為「一発勝負」「徹夜」で行われることになり「ミス」が発生する確率は非常に高い。
 「リカバリー処理」そのものが「裏舞台」であり「リカバリー処理ミス」は「裏舞台の舞台裏」である。
「リカバリー処理ミス」の修復は、必ずしも「論理的」に行われない。
時には修復不可能な為に「正しい出力結果」そのものの値を直接入力したり、人海戦術のオンパレード。(これは筆者だけの経験だろうか)
 周囲の人々には何をやっているのか全く分からない。
スタッフが「キチンとした説明」もせずにひたすら「もくもく」とやっているとしたら、ほとんど「リカバリー処理ミスの修復作業」である。
この手の報告には「中間報告」はなく「最終結果報告」のみになり「リカバリー処理ミス」という言葉は何処にも見つからない。

 そして、忘れかけた頃「リカバリー処理ミス」の「残骸」が突然発見される。