触っちゃいけないEUC

システム部門にいると銀行の職員の方が作成されたEUCプログラムが持ち込まれることが少なくありません
要は、ちょっとプログラムを齧った（AccessやExcelのマクロがちょっと書けるようになった）銀行員の方が作成したプログラム
配置転換で作った人が居なくなった後もそのまま使っていたのだけれど、業務の見直しなどで改修が必要になり急遽持ち込まれるパターンです

プログラムを見ると、作った本人はそこそこ分かって書いていたのだと思われますが、使うだけの人にとってはブラックボックス
使っているけど、改修不能なシステムです
EUC自体は、悪いことではありませんがシステム構築のトレーニングを受けていない銀行員が作成したシステムは、ドキュメントは無し
仕様は、書かれたプログラム（マクロ）を解読してくれいったものがほとんどです

まあ、仕事ですからそんなシステムの改修依頼でもやらない訳ではありませんが基本的なスタンスは「近寄らない」、「できれば仕事を受けない」、「可能であれば逃げる」です

過去に銀行の職員の方が作成された現地法人における融資管理等を行うシステムのメンテを行なったことがあります
手形貸付、証書貸付に加え、VaR（バリューアットリスク）といった高度なリスク管理まで包含した中々に壮大なシステム
オープニング画面は、宇宙空間に宇宙船浮かぶといった凝ったものでした

ところで、システム部門が開発を行うシステムと、ユーザが開発を行うEUCの違いってなんでしょうか？
私のようなシステム屋が作ると、入力チェックや、システム内の整合性を担保するシステムチェックは必須ですが
業務を熟知したユーザが作成するEUCでは、入力チェックや、整合性チェックが欠落していることが少なくありません
利用者にとって自明のことについては、チェックを行う必要性を感じていないのだと思います
さらに、異例取引については直接DBを操作するので他者が見ると、どのようにしてデータを登録したのか全く分からないといったシステム屋泣かせのシステムとなります

このようにユーザから持ち込まれるEUCプログラムは、手強いことが多いので可能であれば、お近づきには成りたくないシステムです
それでも、持ち込まれてしまった時は楽しんで取り組むようにしています
EUCプログラムは、プログラミングスキルは稚拙であっても現場で業務を遂行している職員の方の作業を生で感じることができます
まあ、EUCプログラムを読んでユーザの意図が多少なりとも見えるようになったら、面白くなって来ますよ