真夜中の初台電話局

　試験終盤になって、私のモジュールに小さなバグが見つかった。改修は数行だったが、試験が必要だ。二項目の簡単な試験、一時間もあれば充分なのだが、その時間がもらえない。どこもマシンは一杯だ。
　試験用の交換機は、まず研究所に一台目。ダイヤルトーンが出ると、あちこちの電話局に増設された。試験が終われば本番に供する。メーカが、新宿は初台の電話局のマシンの日曜、深夜０時から朝八時までなら使っていいと言ってきた。さすがに休みたかったのだろう。現場から応援に来ていた若者と２３時に待ち合わせて初台に向かう。終わったら新宿でラーメンでも食べよう、などと話しながら試験を始めた。
　ところが、マシンが立ち上がらない。メーカの担当者はもう帰宅していて誰も居ない。どこでダウンしているのか。いや、上がってからダウンしているのではない？「うんともすんとも」なのだ。
　一体プログラムはどこを走っているのか。ここか？ここにはきてるか？と絶対番地を指定してトラップを試みるが、想定したところに全く来ない。ブートプログラムまで遡って行って、とうとう朝五時を回ってしまった。これはもう二次記憶のプログラムが壊れてしまってるんじゃないのか。人間、疲れてくると発想が飛躍してくる。やけくそで二次記憶を覗く。え？リストと違う。どういうことだ。しばらく眺めて、機械語が一番地ずれていることに気づいた。
　試験の持ち時間が終わると、メモリ上のプログラムを二次記憶にセーブして引き継ぐ。試験でメモリにあてたパッチを引き継ぐためだ。前任者は、そのコマンドで間違えたらしい。そういえば若手が一人で試験していた。ずらして立ち上げると、すんなりダイヤルトーンが出た。試験が終わったのは朝八時少し前だった。
　たった２項目の試験に一晩費やしてしまった。「デバッグ」には、マシンの操作ミスというバグも含まれていた。それにしても、絶対番地のリストのありがたさを、改めて実感した。
　全国に試験拠点が拡大していったので、磁気テープでプログラムを送るのをやめ、通信で送ろうと提案した。専用線はバカ高いし、開通までに期間がかかるから間に合わない。高速の電話モデムで送ることにした。四千八百ＢＰＳのモデムは電子レンジくらいの大きさがあり、高価だったが、本社を脅して購入させた。しかし、現場はリストが届くまで新しいプログラムで試験しようとしなかった。
　試験でバグが見つかると、機械語のパッチで仮対処して試験を続ける。一方でプログラムを修正してコンパイルし直すが、これは当初一カ月毎だった。これを二週間毎に短縮した。パッチを削減するためだ。しかし、今度はリストの印刷と配送が大変になる。
　パッチを作るためには機械語のリストが必須だ。それも絶対番地が入っている方が作りやすいから、コンパイル後、リンケージまで終わらないとリストの印刷を始められない。三枚の紙の間にカーボンが挟まれたラインプリンタ用紙を使い、三回印刷して合計九部。カーボンを取り除いて箱に詰めて発送する。
　全リストは十箱以上になった。それを複数の拠点に送るのだが、ＸＸＸモジュールが入ってない、とクレームがくる。一箱に一モジュールでは五十箱以上になってしまう。小さなモジュールもあるから、複数を詰め込む。そうすると、何をどこまで入れたか、ミスが起こりやすい。
　届いたリストは、モジュール毎にバインダに閉じ込む。バインダにマジックでモジュール名を書いて並べる。これでようやく試験に供することができるが、のんびりやっていると新しいプログラムが届いてしまう。
　バグ票もコピーして各拠点に送る。表書きの次に資料がクリップ止めされていたから、かさばる。そんなバグ票を段ボール一杯、二杯コピーして送る。コピー前後で件数を数えて比較してみると、案の定合わない。人を換えて数え直すとまた違う。こんな感じだった。
　のちに、ＮＴＴコムウェアでは全国九拠点で年間十万項目を試験できるようになる。パッチを不要にすべくコンパイルを一晩に短縮した。リストも自動転送するようにした。自動化によってミスをなくし、ロスタイムを減らしていった。