大トラブル

昭和６０年４月、僕は課長になった。同時にＮ課長は次長に昇格した。

課長になると一気に業務スパンが広がり、１つのシステム開発に集中していれば良い状況では全くなくなった。本店各部門（ユーザー部門）から飛んで来る様々なシステム化依頼案件に対して、該当部門との折衝が大幅に増えた。特に、ユーザー部門の施策検討段階での会議に出席を求められたりもする。部内の会議も多くなる。今までの方がどれだけ良かったか。

まだ、新米のシステム開発課長として３ヶ月にも満たない頃、大事件が起きてしまった。

流通大手のトーエー（仮称）の社員向けに当社が販売した商品の代金を、給与からチェック・オフしていた。つまり、毎月当社から渡す「個人別チェック・オフ・データ」に基づいて、トーエー側の給与システムで夫々の社員の給与から引き去るのだが、当社が送ったデータに誤りがあり、予定より多くの額をチェック・オフしてしまうトラブルが起きたのだ。

実際に誤りに気が付いたのは、運良く、トーエー側で給与引き落としを行う前日だった。当社の窓口部門を通じて、差し替えデータを今直ぐ届けるのでそちらのデータでチェック・オフして貰うよう先方にお願いした。ところが、先方はこの問題の大きさに気が付かないのか、余計な対応を嫌ったのか、はたまた、流通業大手の偉そうな目線で当社を見てるのか、けんもほろろの対応だった。

僕も、電話を代わって貰って必死にお願いしたが、人事課長さんは「今更そんな対応は出来ません。事前にそちらのチェックがいい加減だったからでしょう。ダメなものはダメです」の一点張り。「もし、間違ったデータのまま給与引き落としをすると、結局は御社（トーエー）の人事部の皆さんも非難されることになると思いますので、どうか・・・」「余計な心配は不要です。その後のリカバリー対応はお宅の責任でやって貰えば良いことですから」。

そして、案の定トーエー内で大騒ぎになった。当然僕等に対する非難は強烈であったが、トーエーの人事部に対しても、何故ミスをチェック出来ないのかと大クレームに発展したのだ。

こうなって初めて先方も動き出し、1週間で全てけりを着けるべく、両者のシステム部門が協力して対応して行った。当方は返却すべき金額の個人別のデータを作り、トーエーから貰った夫々の社員の給与振込先データとドッキングして、そのデータを銀行に持ち込んで振込み作業をして貰う。

更に、社員一人一人への詫び状に夫々異なる返却金額と振込み予定日を記入しなければいけないが、対象者が数千人に及ぶためとても手作業では無理。そこで、プログラムを組み、数ヶ月前に導入したばかりの連続帳票用の高速レーザー・プリンター（ＬＢＰ）で打ち出すことにした。

これら全てが突貫工事で、且つ、ＬＢＰのような新兵器を駆使しなくてはならず、二重遭難だけは絶対に回避したかったので、部門上げてチェック体制を敷き、完璧と言えるまでテストを重ね本番に移した。そして、予定通り、1週間で全てのリカバリー処理を終えた。

大変可笑しなことながら、この大トラブルが起きたお陰で、僕は大勢を指揮してリカバリーを行い、事態を収拾したことで、課長らしい仕事が初めて出来たと思った。しかし・・・。