昭和５０年１２月にＩＢＭシステム３２が導入されましたが、「火入れ式」用のものがまともに動くもので、「給与計算」や「販売統計表」・「原価計算表」というものは翌年４月から「本番」というスケジュールでした。この余裕のあるにも関わらず、開発期間内では発見できずに、大トラブルを本番で発見するという事件を引き起こしてしまいました。
それは、新車販売の原価統計をとるプログラムでありました。昭和５１年４月度の販売統計とその原価統計のシステムを走らせると、さすがにディスク・システムでソートのスピードは先代のＮＣＲ機と比較して１日対数分という速度差を示しました。経理の担当者と「わー、めっちゃ速いなぁ！」と感嘆したものでした。
ところが、原価の総額は間違いなくあっているのですが、どう考えても「１台」ずつの原価集計にズレがあることに気がついたのです。これは、原価データと新車マスターとをマッチングして集計をとるという設計を行なっていた事に起因していました。私たちは、ＲＰＧ�Uという言語を使用してシステム開発したのですが、制御キーのブレイク毎に原価データの小計をマスターとマッチングして累計するという筈が、なんと、どうも「売れていない新車」に部品や加工工賃のデータが大きく足されている事に気付いたのです。
５月上旬はゴールデン・ウイークあるので、自動車販売店は長期連休になるのですが、休日を返上して、しかも、徹夜で原因の究明に当たったのです。ＩＢＭのＳＥさんにもプログラムを見てもらっても「原因」が判明しない、何度も、何度も修正してはテストして見るのですが、結果は変らず、本当に困りはてました。ＧＷも明けて、ともかく、期限がきたので、経理に販売統計と原価統計を提出したのですが、５月の中盤まで、四苦八苦していました。
ところが、ある時、「なんでディスク・システムなのにマッチングせなあかんのや？」と気付いたのです。新車マスターは索引付ファイルなので、キー項目でランダム更新することができるのです。
原価データをシーケンシャルに読み込んで「キー項目」で制御して、同じキーのデータを小計し、それをマスターにランダム更新する方法でバッチリ正解が出たのです。
経理に「すいません。４月度の統計表に誤りがありました」と恐る恐る申告すると、上司のＭ課長は「始末書を書いてとけ！」と笑いながら受け取ってくれました。ともかく、以後は、正しい設計法が分かったので、こんな原始的なトラブルは２度と起こしませんでした（当り前ですね！）。