交換機のプログラムは、ずっとアセンブラ（機械語）で開発されていた。リアルタイム性とメモリ量のためだ。そして、アセンブラも交換機で動かしていた。交換プログラムは交換機を使って開発していたのだ。（スマホのアプリをスマホで開発するようなもの）当時の交換機はメモリが少ない。開発に使える二次記憶は磁気テープ。そして、ＯＳはＤＯＳレベルだ。ＣＨＩＬＬ言語のコンパイラも最初は交換機で動かしていた。メインフレームに移植され、最初の開発が、私が新人で参加したプロジェクトだった。だから、配属直後の課題が、メインフレームでのコンパイラの操作マニュアル作りだったのだ。
　武蔵野研究所では、上階に計算センタがあり、メインフレームはワンフロアを占めていた。センタの入口には空港の到着便一覧のようなディスプレイがあった。コンパイルのバッチが表示されており、メーカの若い担当者が見張っていた。「よ、今夜はどう？」「あと十二本っす」（１２モジュールのコンパイル完了を待っています）渋い顔だ。奴は夜行で山へ行くつもりなのだ。つまらないエラーだとコンパイルは短時間で終了する。モジュールの担当者に連絡だ。長引いていれば正常なのだが、今度はセンタの終了時刻が気になってくる。「延長願い出そうか？」と意地悪に言うと「そうですね」と涙目のしぐさ。
　あれから七年、一九八九年でも、まだメインフレームだった。品川は衛星通信用のビルで、メインフレームはない。計算センタは地下鉄を乗り継いだ先にあった。誰かを行かせ、ディスプレイを監視させる。リストは印刷してタクシーで持ち帰る。ソースを編集する遠隔端末は、品川に数台しかなかった。コンパイラのＵＮＩＸ移植完了まで、もう少しだった。
　大学院時代、コンパイラを勉強しに計算機学科に通っていたとき、ＰＤＰ１１を見た。最初にＵＮＩＸが開発されたマシンだ。武蔵野時代、隣の研究室が買ったＳｕｎ１が小火を起こし、買うことができなくなった。ＶＡＸやＥＬＩＳを使いながらも、他研究室のＵＮＩＸマシンにアカウントをもらい、遊んでいた。
　Ｓｕｎワークステーションは当時一千万円近かったと思う。パソコンなら百万円しない。ベテランたちはパソコンを欲しがった。以前、研究所に応援に行き、開発をかじった彼らは、自分専用のパソコンを持つことが勲章だった。品川でパソコンを専有していた「ベテラン」は十人いなかった。当時のパソコンのハードディスクは小さく、入らない。ソースはフロッピーディスクで十数枚だった。
　念願のＳｕｎワークステーションがやってきた。最初は一台を数十人で共用した。古いパソコンを集め、端末エミュレータでアクセスする。当時のパソコンにＬＡＮボードはない。ＲＳ２３２Ｃでつないだ。しかし、ベテランたちは見向きもしない。どうやってベテランに使わせるか。
　ゴミ掃除やデータ定義の集約は若手にやらせた。初めてみるソース、初めて使うＵＮＩＸに彼らは夢中になった。当時のパソコンはＤＯＳである。検索している間は何もできない。ＵＮＩＸなら複数の検索を同時に実行できる。だが、これだけでベテランは触手を伸ばしてくれなかった。
　そこで、ソースを日本語化することにした。カーソルが指すサブルーチンやデータ名を日本語に翻訳する。ＥＬＩＳチームからヒントをもらって作った、エディタ内から辞書をひく仕掛けである。辞書は順次拡充していった。メインフレームでは英数字と半角カタカナしか使えなかったから、プログラムを理解するのに詳細設計書が必要だった。しかし、ソースも紙、詳細設計書も紙では、両方をそろえてソースを読むには机２つを専有しなければならない。
　エディタでソースを追いながら、キーを押すと画面下に日本語が表示される。これは強烈なインパクトがあった。新人でもソースをなんとなく読める。ベテランもＵＮＩＸを覗き込むようになった。
　交換プログラムでは名称付与方法を規定していた。「加入者」はＳＢ、「制御」はＣＴ。だから、「加入者制御プログラム」はＳＢＣＴとする。新人のとき、名称付与基準マニュアルを作った。基本単語を覚えると、ＳＢＯＲＤＴは「加入者発信検出」と理解できる。この付与基準はよく守られていた。
　エディタにはemacsを採用した。ＵＮＩＸといえばviだが、日本語翻訳の仕掛けがemacsなら容易に実現できたのだ。ＥＬＩＳのエディタはemacs風で、私の指は完全にemacsになっていた。しかし、emacsはメモリを消費する。大きなモジュールを開くと、ワークステーションが固まってしまった。当時のＳｕｎはメモリが４ＭＢ。それを最初は数十人で共用した。ＵＮＩＸのテキスト検索ツールgrepは少ないメモリで動く。並行して検索すれば遅くはなるが、固まることはない。しかし、誰かが編集しようとするとシステム全体固まって、全員使えなくなった。
　そこで、ソースを細かく分割することにした。サブルーチン単位、データ は宣言単位に分割してしまった。数行しかないソースもあったが、データ定義を集約するとき、ここまで分割しておくと便利なのだ。ソースファイルの名前はデータ名そのものだから、集約モジュールのディレクトリにソースファイルを移動するだけで、アルファベット順のソースを簡単に作れる。
　ワークステーションの利点はマルチウィンドウだ。最終的には一人一台配備されたが、どう拡充していくか、誰に割り当てるか。ワークステーションを与える基準を設けた。ＵＮＩＸの基本コマンドを覚えること、そして、タイピングが速いこと。課題文章のタイプ時間を測定し、速い順にワークステーションを与えていった。昼休みに競って課題をタイプするようになった。
　作業方法も改良した。重要なプログラムの編集は二人ペアで行う。編集後、差分を二人で点検する。新人の編集をベテランがチェックする。従来なら印刷していたが、次第にワークステーションの画面で行うようになった。
　できるだけ印刷させないよう、プリンタは私の横に置いた。ベテランはすぐ印刷したがる。紙で持ちたがる。暗黙のプレッシャーだったが、それでもプリンタはすぐ故障した。業者を呼ぶと「この機種でこの量は印刷できません」と怒られた。
　バージョン管理も導入した。ソースをバラバラに分解したが、今週試験を始めたい内容と、来月、他モジュールと合わせて盛り込む内容が混在することがある。バージョン管理を使えば並行して盛り込める。待って、短時間で盛り込む必要がなくなり、コーディングの負荷を平準化できる。タイプが速いやつが遅い奴に引きずられることも防げる。それだけで生産性を一割改善できた。
　ユーザ名は社員番号とした。ＮＴＴの社員番号は七桁だったので、先頭に英字を付けた。（ＵＮＩＸのログイン名は八文字の英数字）誰が編集したソースか、異動しても退職しても追跡できる。
　ＵＮＩＸ上で責任をとるためには、個人アカウントを徹底する必要がある。パソコンは共用していることが多かった。パスワードは簡単に「１１１」などとしていた。そこで、「パスワード破りゲーム」を開催した。ログインしたままで席を空けていたら、私に「○○君のアカウント破ったり」とメールする。破られた者は朝のミーティングで、全員の前で懺悔するルールとした。
　複数のＵＮＩＸマシンで開発する際、大事なのはＵＩＤである。ファイルを誰が作り、誰が変更したか、ＵＩＤで記録されている。マシン間でＵＩＤが揃っていなければ、マシンを越えてコピーすると、誰のファイルか分からなくなる。また、ＵＮＩＸではグループ単位にアクセス権限を設定するのでＧＩＤも重要である。
　ＵＮＩＸの魅力が伝搬し、導入が始まると、勝手に管理したがる者が現れる。ＵＩＤ統一の重要性を説明してみても、多国籍軍である。とうとう、最後の手段を採った。日曜夜、あるマシンのアカウントを社員番号式に書き換えてしまった。そのマシンの管理者が、どうしても言うことを聞いてくれなかったからだ。その後、アカウント数が千を越えるまで、十数台のＳｕｎサーバを管理した。アカウントは全国の開発拠点をＹＰ（のちにＮＩＳ）で一元管理した。