週末の愛人宅

　入社三年目、開発が完了した時点に話を戻そう。「十年後十人で開発」を目指し「交換プログラム開発のビジュアル化と人工知能の応用」を研究企画し、所長表彰をいただいた。これで学会の研究会を開催することになった。
　人工知能の第一次ブームで、武蔵野の基礎研究所でもＬＩＳＰマシンＥＬＩＳを開発していた。これを使いたいと上申した。ＥＬＩＳは大型冷蔵庫ほどもあった。交換ではＭａｃやＳｕｎは購入していたが、同じ敷地で開発していたＥＬＩＳには懐疑的だった。ビジュアルな画面にはＳｕｎを勧められたが、買ったばかりのＳｕｎ１が小火を起こし頓挫した。結局、ＥＬＩＳとＣＡＤ端末をＶＡＸでつなぐ２億円近いマシンたちを、以前はリストを印刷していた部屋に設置した。妻はここを「愛人宅」と呼んだ。
　この頃、組合の役員に選ばれた。電電公社民営化に反対するため、ビラ巻きや選挙の応援で忙しかった。平日は組合事務所に詰めることが多くなり、愛人には週末に会う生活になった。本来は上司に印をもらい、事前に守衛に申請しておく必要がある。しかし、組合役員が休日出勤はまずい。こっそり会いに行くしかない。
　研究にシフトして人間らしい生活になるはずだったから結婚したのに、週末は愛人宅になってしまった。わくわく出勤する私に、妻はお弁当を作ってくれた。
　状態遷移図をビジュアルに設計するデモ、信号シーケンスをシミュレーションするデモを作成した。障害時の縮退運転をシミュレーションするデモを、同僚が作成するのも手伝った。これらは、素人受けしたので、見学者の定番デモになった。
　研究会が近づいてきた週末、深夜、眠る前にディスクのゴミファイルを消すつもりで、私はＶＡＸのディスクを消してしまった。ＥＬＩＳとつなぐプログラムも、他のメンバのデモも、ＯＳさえ、すべて。アスタリスクに要注意だ。バックアップはとってあったが、磁気テープである。復元できたときには、もう朝になっていた。
　さて、研究会は武蔵野研究所の講堂を使った。階段教室のような造りだ。古くてプロジェクタ設備はなく、ＣＡＤの画面を投影するのに苦労した。参加者からは「これからはビジュアル設計ですね」とか「ＡＩですね」と賛辞を頂戴したが、私は満足いっていなかった。多くはメーカの幹部で、大半が研究所のＯＢだった。デモはこの研究会をターゲットにしたもので、本当に開発を容易化できるのか未知数だった。第一、使っているマシンが高価すぎる。
　「もう質問はありませんか？」に、あるＯＢが手を挙げ、「今回のご研究とは少し違うのですが」と話し始めた。それが「分析ツリー」についてだった。
　分析ツリーとは、交換機が信号を受信したとき、様々な条件をチェックして、その信号に対して何をすべきか決定するロジックである。たとえば、受話器をあげたとき、そのお客様が契約しているか、料金を払っているか、プッシュホンか、着信専用ではないか等をチェックし、ＯＫならばダイヤルトーンを出す。チェックの順番をツリー状のデータで表現しているので「分析ツリー」という。実際の交換機では巨大になり、新サービスを追加するときの調査検討を難しくしていた。
　チェック項目は数百、それぞれに分岐が数通りから数百通りである。たとえば、分岐百通りのチェック項目を１０項目分析したら、条件は全部で千通りになる。数百ある状態毎に分析するので、全条件は何通りになるのか、誰にも分からなかった。私は「ぜひやりたいテーマです」と熱っぽく答えたのだが、組合が忙しくなり、愛人宅にも通えなくなる。そして、私は企画部門に異動になった。
　その研究会から４年後、開発部門に異動し、懐かしい交換プログラムに再会する。内製のためだ。
　内製を始めて二年目、「分析ツリーを研究している」という男が研究所から会いに来た。テーマを引き継いでいる人がいた、と思ったが、話を聞くうちにいらいらしてきた。ツリーをビジュアルに編集するツールを、いまだに目指していた。現実の分析ツリーはあまりに巨大で、ビジュアル化は困難だ。そして、相談のポイントはビジュアル化ではなく、実際の分析ツリーを読み込んで解析するところに苦労している、というのだ。
　難しいというツリーを見ているうちに、ソースを修正してしまえばよいと気づいた。彼は、運用中のプログラムを研究のために修正することなど、できない前提でいた。
　話を聞いた日の夜、娘を寝かせつけてから、ツールを作ってみた。これで分析ツリーのソースを整形してしまえば、そのあとはとても楽になる。しかも、ビジュアル化は捨てて、単純に条件を一覧に列挙することにしてみた。ＵＮＩＸのシェルスクリプトで書いてしまった。
　列挙した条件一覧はもちろん巨大になった。Ａ３に八ポイントのフォントでぎっしり印字しても、厚さ十センチ。「もし電話がプッシュで、契約が事務所で、発信専用で、、、」という具合の一覧だから、検索は容易だ。設計者たちに見せてみると、やはり紙で欲しいという。そこで、別に索引を用意した。「発信専用という条件を参照しているツリーの箇所は…」を一覧にした。これも十センチになったが、これがヒットの鍵となった。機能追加するときには分析条件を追加することになるが、その影響を索引で網羅できる。計二十センチのＡ３は、設計者たちの引っ張りだこになり、Ａ３が印刷できるレーザプリンタが故障して、印刷の自粛令が出たほどだった。ツリーを修正するたびに最新版をねだられ、徹夜でシェルスクリプトを動かした。
　愛人宅での悪戦苦闘から壮大な回り道であった。現場を直視し、発想を変えれば、驚くほど簡単で実用的な解決策がある。
　ビジュアル化やＡＩは今でも流行りである。ＡＩで問題を適切に絞り込む点が注目されがちだが、現場ではとにかく「一覧」にしてしまう力業が案外有効だったりする。特に、この分析ツリーのように、プロが使う場合には。研究企画では「誰でも設計できる」を謳い文句の１つとしたが、交換プログラムを素人に設計させるなど、必要のないことだ。