今だから話そう　グリーンベレー　Multics Multician コンパイラ　プログラム言語　昔男ありけり

(2)

グリーンベレー

── もはや時効となったお話(2)
男ありけり

　　　昔男ありけり
　　　ソフトウェア開発の技術者となりけり
　　　熱烈な Multician となりけり
　　　空港で紛失したソースプログラム一式の行方が‥‥

はじめに　(長文です)
　長年に渡ってエッセイを書き連ねてきたが、テーマによってはどうしても書くのをためらうものがある。もちろん、個人的なことで失敗した話とか勘違いで恥をかいたような話は書きたくないのは確かだが、その類いの話はいずれ時間が経てば自ら人に話せるようになる。そう思って私は、これまでの人生で苦労したことや悩んだことなどをできるだけエッセイに書くことで身軽になって生きようと努力してきた。

　一方、仕事に関することだと機密事項もあるから、会社あるいは特定の個人に迷惑が掛かる恐れもあるので、どうしてもエッセイのテーマとして取りあげるのを控えてきた。その結果、仕事に絡んで抱え込んだ悩みの持って行き場がない。どうしたらよいものか。

　これまでは、親しい友人たちとの懇談の場で思い出話としてさり気なく話してしまえば身軽になれると思っていた。しかしそういう機会は案に相異してなかなか訪れないもので、いつまでも重荷を背負い続けているのが現状である。結局は“墓場まで持って行く”ことになると最近は思うようになっていた。

　ところが、コロナ禍以後私の考えが少しずつ変わってきた。もはや時効として公開しても構わないのではないか、と。「今だから話そう」シリーズにしたら結構面白いかもしれない^(*1)。
【注】(*1)シリーズにする程テーマが沢山あるわけではない。しかし以前紹介した“とっておきの話「コワイ先生」”は、実はその種のテーマに属していたものなのである。そこで、後から“今だから話そう「コワイ先生」”とタイトルを変更することにした。
　ここでは、今から４５年程前、メインフレームのソフトウェア開発を担当していた頃の話を紹介したいと思う。

　PL/Iというプログラム言語の処理系(コンパイラ)を開発していたときに経験した話が中心となるので業務と密接な関係がある。そのとき経験したことの多くは、実は今まで個々には紹介してきた^(*2)ものである。私は、日常生活で起こる様々な出来事になぞらえて、コンピュータの技術(特にソフトウェア技術)を分かり易く紹介するという方法を編み出し「ソフトウェアと〇〇」というタイトルの一連のエッセイに仕立て上げてきた。しかしその背後にあった私の関わってきた仕事については明確には触れないできた。今回は、それに言及しなければうまく説明できない話なのである。関係者に迷惑を掛けないよう心して書くことにする。
【注】(*2)今まで紹介した技術とエッセイのタイトル一覧は、最後の▼参考資料を見てください。
背景説明　(当時のプログラム言語の状況)
　第3章「グリーンベレー」の本文に入る前に、当時の技術的背景を簡単に説明しておきたい(関心のない方はこの章は読み飛ばしてください)。

　今から４５年ほど前、メインフレームと呼ばれる大型機の分野では、それまで
　・科学技術用コンピュータはワード(Word)マシンで、
　・事務処理用はキャラクタ(character)マシンで
それぞれ対応するのが普通だった。しかし1964年にIBM社がSystem/360を発表してからは、Wordマシンとcharacterマシンの特長を合わせ持つByteマシンが主流となってきた。ソフトウェアも一新され、PL/Iと呼ばれる単一のプログラム言語で360度あらゆる方面の用途に対応できるとされていた。

　IBM以外のコンピュータメーカーは対応に苦慮し、
　・IBM互換マシンをめざすグループと、
　・独自仕様のマシンで対応するグループと
に分かれることになった。

　今まで通り独自のコンピュータでIBMに対抗するためにはPL/Iを独自で開発する必要があった。それまでIBMはソースコードを公開していたがSystem/360以後は公開しなくなったので、IBM互換グループでもPL/Iを使いたければ独自に作らねばならなくなっていた。

　当時私はメインフレームのプログラム言語処理系(コンパイラ)の開発部門で仕事をしていたので、PL/Iの独自開発を会社に提案した。

　IBMのPL/Ｉは、それまでのIBMマシンで使われていたすべての機能を含む膨大な仕様を目指して開発されていたので、そのままの仕様では一般のコンピュータ向きではなかった。そこで業界団体では、業界標準のPL/I仕様を造ろうと標準化が行われ“標準PL/I”という言語仕様^(*3)が定められようとしていた時期である。
【注】(*3)1979年に国際標準化機構(ISO)によって標準化されている。
　私は業界標準のPL/Iを開発しようと計画していたのだが、プロジェクトをスタートさせる前に、技術提携先のGE社(General Electric Company)にその旨報せておいた方がよいという判断になった。つまり“仁義を切って”おくことにしたのである。ところが、GE社からは「ちょっと待って欲しい」と伝えてきた。

　しばらく待つうちに、GE社はコンピュータ部門をHoneywell社(以下、H社)に売却するという衝撃的なニュースが入ってきた。これでPL/I開発の話はなくなるなと私は予想した。しかしその後、H社(旧GE社のコンピュータ部門)から共同開発をしたいという提案が届いたのである。今までソフトウェアの分野では海外メーカーと共同開発をした経験がなかったので、これは予想外のことであった。

　２週間後、米国ボストンにある旧GEのCISL(Cambrige Information Systems Laboratory)という研究所で(旧GEの技術者1人、H社の技術者1人、東芝の技術者3人で)プロジェクトはスタートした。

　CISLではプロジェクトＭＡＣ^(*4)の開発を担っていたのでMulticsシステムが自由に使える環境が整っていた。これは後から分かったことだが、CISLでMulticsシステムの言語担当チームの長は、当時ISOのPL/I委員会の委員長を務めていたFH氏だった。標準PL/Iの言語仕様の情報を得るには絶好の場所だったことになる。
【注】(*4)プロジェクトＭＡＣとは、マサチューセッツ工科大学で行われたプロジェクトで、オペレーティングシステム、人工知能、計算理論などの先駆的研究成果が生み出された。

【開発の過程は以下に要約する】
・ボストン時代：
　システム記述言語とツール・コンパイラの開発
　Multicsという先進的なシステム環境下で仮想記憶の利点を生かす。先ず高水準のシステム記述言語を開発。その記述言語で作ったツール・コンパイラ(PL/Iのサブセット)を開発した。この過程でブートストラップ^(*5)という技術が使われた。
【注】(*5)詳しくは、ソフトウェアの法則(36)“ソフトウェアと空中浮揚“を参照。
　それまでのアセンブラを用いたソフトウェア開発とは異なり、システム記述言語で記述したソフトウェアはプログラムのサイズが大きくなる欠点があった。この問題を乗り越えるために仮想記憶方式の利点を活用したのである。豊富なメモリー容量でブートストラップ技術の最大の難関を乗り越えることに成功した。

・フェニックス時代：
　H社のコンピュータ部門(旧GE)の本部があるアリゾナ州フェニックスに移り、ツール・コンパイラを仮想記憶方式から固定記憶方式のコンピュータ環境へ移行させる。ここでもブートストラップ技術が使われ、固定記憶方式下でも成功する。これでやっと実機の上でPL/Iコンパイラが動かせるようになり、プロジェクトの成功が見えてきた。

　こうして開発されたPL/Iを日本に持ち帰って製品化することになった。

・青梅工場時代：
　東芝青梅工場にもどると新たな問題に直面する。システム記述言語を用いてソフトウェア製品を開発するのは初めての試みだったので、プログラムのサイズが極端に大きくなることへの理解が足りなかった。開発環境が日本独特のものになりツール・コンパイラが作り出す目的コードのサイズを更に小さくできないかが最大の問題となってきた。

　メインフレームの大型コンピュータといっても、出荷されるコンピュータのすべてが最大のメモリー構成とは限らない。むしろ少ないと言ってもよい。そのため日本ではPL/Iの利用者はさっぱり増えなかった。ツール・コンパイラは社内のソフトウェア開発に使われるようになったが、肝心のPL/Iコンパイラの方では少しも会社に貢献できなかった。
【要約終り】

グリーンベレー
　さて、ここからが本論である。

▼共同開発の実態
　東芝青梅工場に戻り、PL/Iを日本の市場で使ってもらうための準備に取り組んでいたそんな時に、突然フェニックス^(*6)に居る駐在員から連絡が入った。H社がアメリカの重要顧客に東芝PL/Iをリリースしたところトラブルがあり緊急サポートを依頼したいという打診があったという。それは、全く予期していなかった事なので私は大変驚くことになった。
【注】(*6)アリゾナ州フェニックスには、H社のコンピュータ部門の本部がある。
　というのは、H社と共同開発したと言っても、その実態は少し異なっていたからである。共同開発プロジェクトの進め方については当初から意見が分かれていて、フェニックスから参加したリーダーがプロジェクトをボストンからフェニックスに移動させようと画策していたからである。

　もちろん私は反対だったのですぐ東芝に連絡して対応の仕方を相談することにした。しかし東芝からは、リーダーの意見にしたがってフェニックスへ移動せよと言ってきた。プロジェクトの成否が懸かっていると説明したが許されなかった。ボストンではまだ何の成果も得られていないのに、プロジェクトを移動させるのは早過ぎる！

　このままではプロジェクトが失敗しPL/Iが完成しないまま日本に戻ることになるのは明白であった。初めての“共同開発”という試みを失敗させたという烙印を背負って生きて行かねばならないと想像し私は落胆してしまった。

　しかし私にとって幸いなことに、この試みは失敗に終ったことが明らかとなった。実はフェニックスでは、以前PL/Iの開発に取り組んだことがあったが成功しなかったらしい。その時の成果を活用してフェニックスに開発環境を作ろうと計画したのであろう。しかしテストの結果、フェニックスの開発環境ではメモリーが足りずコンパイルすらできなかったと聞いている。呆れるような成り行きであった。

　結局プロジェクト開始から６ヶ月後、H社のリーダーは病気を理由にフェニックスに戻りプロジェクトから離脱した。もう一人のH社の技術者は我々のボストン生活が落ち着くのを手助けしてくれて(出身地のボストン近郊にある)ウォルサムへと戻っていった。H社は、明らかにプロジェクトから手を引いたのである。

　このようにして東芝技術者だけのプロジェクトになってしまった。しかしCISLの所長は親切にも我々東芝技術者だけによる開発続行を許可してくれた。更に、CISLにあるMulticsシステムの環境^(*7)を引き続き利用させてくれたのである。
【注】(*7)Multicsシステムの環境については、ソフトウェア設計論(6)“【プログラミング】美しさ”で紹介されている。
　これにより、東芝チーム全員の士気も上がりエンジンが掛かってきた。勤務時間を午後から真夜中にかけての時間帯にシフトすることに決めた。以後、Multicsシステムの端末がより自由に使えるようになった。
　Multicsシステムの環境にも慣れてきて、更に６ヶ月後、H社の予想(?)に反し、東芝チームによるツール・コンパイラは完成したのである。

　それ以後は、H社も協力姿勢に転じたようである。実機のあるフェニックスに移ってからは実機での開発続行にも協力してくれた。しかし彼らはアメリカの市場ではPL/Iの要求はないと言ってメンバーの増員には応えてくれなかった。そのため、東京から日本人メンバーを増やすことにした。

▼グリーンベレーへの対応
　こういう事情があったので、H社が東芝の了承を得ないままアメリカのユーザーに東芝PL/Iをリリースしてしまったのは驚きであった。しかしH社の協力のお陰でここまで完成できたのだから、ここは何も言わずに協力するのが良いという結論になった。

　サポート部隊の派遣が可能かどうかは本社の許可次第である。早速、部長が東芝本社に電話で「フェニックスから“グリーンベレーの派遣依頼”が来ている…」と報告しているのを聞きながら、私は、なるほどこういうのを“グリーンベレー”と呼ぶのかと初めて知ったのであった。
　グリーンベレーとは、アメリカ陸軍の特殊部隊の通称であり、緑色のベレー帽を着用していることで知られている。コンピュータ業界でもサポートのために派遣される特別部隊のことを「グリーンベレー」と表現するようになったらしい。

　顧客への対応は本来ならＳＥの役割であるが、重要顧客先で何かトラブルが発生したときは特別チームを編成して対応する場合がある。こういう場合、使われているシステムに一番詳しい人を派遣する。一番詳しいのは普通は開発者であるが、大型のシステムになると分担が複雑に絡み合っているから誰を派遣すべきかの人選が難しい。安全をとって多人数になることもある。ただし、技術面以外の顧客への対応は、礼を失することがないように必ず専任者が付いていてその人を通してやることになる。

　結局、本社の許可が降りH社の依頼を引き受けることになった。取りあえず派遣するメンバーとして、開発チームから私を入れて３人が行くことになった。部長からは、できるだけH社の人に世話をかけないよう“何でも自分でやる”ようにと指示された。

▼持参する物の準備
　早速、何を持参するかを検討し以下の物をそろえることにした。

　(1)PL/Iシステムのソースコード
　　(1-1)PL/Iソースはラインプリンタへの出力リストで、
　　(1-2)アセンブラ記述のドライバー、オペレータ類の
　　　　　コードはマイクロフィルム化した形で、
　(2)記述言語のコンパイラーシステム一式
　(3)念のため、PL/Iのソースコードを記録した磁気テープ^(*8)

　トラブルの原因を追跡するためには、ソースリストを読まねばならないから(1-1)が必須である。PL/Iソースの出力リストはかなりかさ張るが止むを得ない。ドライバーやオペレータ類のコード(1-2)はマイクロフィルム化して持参する。マイクロフィルム・リーダーは現場で借りることにした。
　(2)(3)は、PL/Iのソースコードを変更する場合に必要となるものだが、今回は現場でコンパイラソースを変更する積りはない^(*9)ので使われることはないと思ったが、念のため持って行くことにした。
【注】(*8)当時は大容量のデータを搬送する場合、唯一の方法は磁気テープしかなかった。通信回線で転送するようなことは不可能な時代の話である。磁気テープの場合、大型機で使われていたリールに巻かれていて、１巻で大容量のデータを保存できた。低コストで大量のデータを保存できるのに今では全く利用されていない。

　( 磁気テープ )　
【注】(*9)高水準の記述言語で作られたシステムプログラムは、どこか一か所でもソースコードを変更したら必ず出荷検査からやり直さねばならなくなる。したがって普通は機械語でのパッチを利用するしか方法がなかった。
　これらの資料をメンバー３人で手分けして持参することにした。

▼荷物がない！！
　目的地は、シンシナティ^(*10) にある世界的に有名な産業機械の会社(以下、M社)である。現在では産業用ロボットも手掛けている。
　H社からは事前に予約した我々が泊るホテルの名前、H社の担当者2名の名前と電話番号(office と自宅)を知らされた。最悪の場合、ここへ電話すれば連絡が取れる訳だ。
【注】(*10)シンシナティは、オハイオ州南西端に位置する。州都コロンバスの南西約170km、ケンタッキー州との州境になっているオハイオ川の河畔にある。

　( アメリカの地図 )　
・6/12　サンフランシスコへ
　羽田空港から17:00発の便でサンフランシスコ経由シンシナティへ向かうことにした。サンフランシスコ空港では、シンシナティ行きの国内線に乗り換える際にメンバーの一人の荷物が見つからず、行方不明の扱いになってしまった。発見次第送ってもらう手続きをして全員でシンシナティに向かう。

・23:49 シンシナティ着
　グレーター・シンシナティ空港(現在の名は、シンシナティ・ノーザン・ケンタッキー国際空港)に到着。H社の世話にはならないようにとの指示にしたがって早速レンタカー屋に行き車を1台借りる。シンシナティの地図を貰ってRiver Frontにあるホテルを目指す。

　時間は既に真夜中である。地図を頼りに初めての高速道路を走るのだから神経を使うが、アメリカの交通標識は日本と比べて大きさ、周辺の明るさ等どの点でも優れて居るので無事にダウンタウンに到着しホテルを見つけることができた。

▼サポート開始
　翌朝、H社の担当者と連絡が取れ、一緒にM社の工場プラントへ向かう。立派な工場である。赤レンガ造りの建物に技術部門と本社組織が入っていて問題のコンピュータもそこに置かれていた。それまで使っていたIBM System/370を、最近H社製コンピュータにリプレースしたとのこと。コンピュータ部門の長はIBMから引き抜かれた女性の部長が取り仕切っていた。

　クレームの内容は、新しいコンピュータ上でPL/Iプログラムを実行するとIBMマシンでの実行結果と異なるという点であった。だいたいの予想は付いていたが内部コードの違いであろう。

　IBMのコンピュータでは、文字コードの内部表現はIBM独自のコードでEBCIDIC(エブシディック)^(*11)と呼ばれるコードが使われている。それに対してIBM以外のメーカーは、国際標準のコードを使っていた。

　国際標準のコード表の中で、通貨記号の欄にはそれぞれの国の通貨記号が使われる以外はどの国でも英数字と基本的な特殊記号の並びは共通と考えてよい^(*11)。アメリカではASCII(American Standard Code for Information Interchange)コードと呼ばれている。
【注】(*11)詳しくは、EBCDIC-Code,　ASCII-Code 参照。
　詳しく事情を聞くと、果せるかな使用している内部コードの違いであることが分かった。PL/Iのプログラムにデータとして部品の名称などを入力し部品名の一覧を作成するとする。A,B,C 順にソートして表示すると文字コードが異なるので結果として相違が出てしまったのである。

　こういう場合、普通は「仕様書通り、データはASCII形式で入力してください」と言って利用者側の了解を得るのが普通のケースだが、何しろ重要顧客が目の前で実際に困っているのだから何とかしてあげたい。H社の担当者も、わざわざ日本から呼んだのに「自分の守備範囲ではない」と言って帰られても困るだろう。そうかと言って、こちらはPL/Iコンパイラに問題があればそれを修復するために派遣されてきたのだから、それ以外の仕事を勝手に引き受けることは許されない。

　そこで東芝に電話して判断を仰ぐことにした。東芝側は「協力しろ」とのことであった。こうして許可が降りたので翌日からサポート作業を開始することにした。

　この間、サンフランシスコ空港で紛失したトランクは、まだ見つからないという連絡が入った。時間が掛かりそうである。トランクを受け取れなかったメンバーは着替えとか生活に必要な物一切がないので近くの店で買い集めなければならなかった。気の毒なことになってしまった。分担して持ってきた資料の内、そのトランクと一緒に行方不明になったのは、PL/Iコンパイラのソースコードを記録した磁気テープ1巻であることが分かった。とりあえずPL/Iのソースコードは使う予定がないので、当面の仕事には影響しないと安堵したが、資料が戻らなかったら…と考えるとかなりのショックであった。

▼コード変換のプログラム
　翌日からサポート作業が始まった。作業場所として小さな会議室が与えられたので、そこで全員で作業をすることになった。作戦としてはPL/I本体には触れないことにして、オペレータの方を改変することにした。

　PL/Iのプログラム上で文字列同士の比較が行われると、コンパイラは文字列比較を行う演算子(オペレータ)を呼び出す為のコードを生成する。このオペレータはアセンブラで記述されている。これを拡張してEBCIDICコードの文字列比較に切り換えてしまう。実行時にこのコードが呼ばれると、すべての文字列はEBCIDICコードとして扱われることになる。

　EBCIDICコードの文字列比較を行うためのライブラリプログラムを作ることにした。それをPL/Iの目的プログラムとリンクさせるための工夫をすればよいことになる。

　そのためのテストプログラムを組み込むときは女性部長の許可を得なければならない。その都度どこをどう直したかの説明を求められる。部長の部屋でラインプリンタ用紙を床の上に広げて互いに論争したこともあった。なかなか手強い部長であった。

　こうした戦いの末、EBCIDICコードへの対応は２週間程で成功裏に終息した。しかしM社のコンピュータ部門の幹部は引き続き協力を求めてくるのでなかなか解放してくれない。その内に、フェニックスからH社の幹部が現状調査にやって来ることになった。

　翌日、3人の幹部がやってきて東芝のサポートで顧客を満足させられたかどうかを聞き取り調査していたようである。我々のいる小会議室にもやってきた。そのときのやり取りで悔しい思いをしたが、何が悔しかったのか今ではすっかり忘れてしまっている。その結果、我々はやっと無罪放免となったのである。

▼再び、アリゾナへ
　帰りの便は、サポート作業中から何度も予約変更を繰り返していたのだが、最終的に私以外の二人のメンバーが直接帰国することになった。私はフェニックスへ寄って最終報告をせよということになった。

　7月11日、私はシンシナティ空港から12:12発の便に乗り、15:00にはフェニックス空港に到着した。2年振りのフェニックスである。空港には駐在員のHF氏が待っていてくれたが、例によって私は自分でレンタカーを確保してホテルへ向かうことにした。車にはHF氏が同乗してくれたが、駐在員が出迎えた人の運転する車に乗せてもらうなんてと彼は笑いながらも驚いていたようだ。これは“何でも自分でやれ”と言う部長の指示に従った訳ではなく、以前私は友人の運転する車に乗せてもらって事故に遭い怪我をした苦い経験^(*12)があったからで、特に海外出張中は人の運転する車には乗らないことにしていたのである。
【注】(*12)詳細を知りたければ、中公新書(1270)「ソフトウェアの法則」の中の“ソフトウェアと時差”を参照してください。(新書版は絶版、電子版のみ入手可)
▼ご褒美と土産物
　フェニックスでの報告という最後の仕事の前に、土曜と日曜は久しぶりの休息日となった。駐在員のHF氏が彼の家のランチタイムの食事に招いてくれた。HF氏と私とは同じ高等学校の同期生である。彼は、部屋の壁に掛けてあった牛の角の飾り物をわざわざ取り外してきて、私にプレゼントしてくれると言う。牛の角の飾りはアリゾナの土産物として有名だが、かなり高価なものでもある。今回のグリーンベレーでは、私の方がお世話になっていたので恐縮してしまった。駐在員として裏で様々な努力をしてくれたのを私は知っていたので、彼も駐在員として活躍の場を与えられ喜んでくれていることが分かった。それが彼なりの感謝の気持ちとして私にも伝わってきた。
　しかし、残念ながらこの2ヶ月後、彼は自動車事故で帰らぬ人となってしまった。この牛の角の飾り物は、彼の形見として私の書斎に今でも飾られている。

　
　( 牛の角の飾り物 )　
　週が明けて最初の日、H社の会議室で経過報告のプレゼンテーションが終わると、突然カメラマンが現れて写真を撮ってくれた。同時に3人分のJWD(Job Eell Done)の賞状と記念品として“インディアンの砂絵”が授与された。やはり3人全員で出席させてもらいたかったなと強く思った。
　彼らは、普段からこういう簡単な表彰式をさりげなく行なうようである。しかも事前には本人たちに報せず、突然やって驚かせるのである。社員のやる気を引き出すためのインセンティブ制度が確立しているのであろう。

　( 報告後の記念写真 )　
　翌日、私はこれら３人分の賞品類を抱えて日本へ戻ったのであった。

▼後日談
　その後、東芝のメインフレームの業務は日本電気に移管されることになった。私もコンピュータの仕事から離れ、医用機器の研究所に移ったので、その後の大型コンピュータの動向やPL/Iの普及動向等はどうなったのか全く知らない。

　行方不明となった荷物はその後どうなったのだろう。風の便りで聞いたところでは、別の空港でトランクが発見されたらしい。しかし中身は無くなっていたと聞いている。こういう情報は紛失した当人にしか報告が行かないので、私には何の連絡もなかった。ソースコードが記録された磁気テープの行方はどうなったのだろう？　多分、ごみとして捨てられてしまったのだろうと思った。

　今から振り返って見ると、標準PL/Iのコンパイラが大き過ぎると言ってなかなか利用者は増えなかったが、現在のパソコン業界でのソフトウェアのサイズとほぼ同じ程度のサイズなのである。当時のハードウェアが装備するメモリサイズでは狭すぎたのである。時期的に生まれてくるのが早過ぎたのだと思う。

　PL/I言語の登場の時期も悪かったようだ。この頃から「オブジェクト指向」という技術が登場しソフトウェア開発に不可欠のものとなった。プログラム言語の言語仕様にこの機能を取り入れた処理系でないと使われなくなってしまったのである。なぜかPL/Iには採り入れられなかったようだ。PL/IだけでなくAdaにも！　取り入れなかったプログラム言語は、後に姿を消す運命となった。最近はどうなっているのだろう。

▼紛失したファイルの行方は？
　その後、再び私はコンピュータの仕事に戻ったが、その頃はパソコン開発の黎明期であり、私もパソコン開発を担当することになった。

　パソコン開発でのソフトウェアの仕事は、他の沢山の会社と協力して製品を造り上げるというスタイルを取る必要があった。その結果、他の会社の技術者と交わる機会が多くなっていった。

　あるとき、そういった会社の人たちと一緒に昼休み中の雑談をしていたときのことである。その内の一人が友人の話をしていて、その奥さんもやはりコンピュータ関係の仕事をしていて某メーカーの研究所に出入りしているという話になった。そこでは、出入りしている研究室の隣りの研究室で偽札の検出機械を研究しているそうである。またその隣りでは「東芝のPL/Iコンパイラのソースコードがあって、それを解読して研究している」というような話をしていた。

　私は、何気なく皆の話に耳を傾けていただけだったので、この瞬間「ぇえ？！」と思ったが、咄嗟に何も言えなかった。彼は、私が以前どのような仕事をしていたかを知らなかったと思う。私に向かって話していた訳でもない。ましてや、PL/Iソースの紛失というような事件のことは知らない筈である。私は衝撃を受けてはいたが、冷静に、何も言うまい、何も聴くまいと思った。とんでもないことを耳にしてしまった、忘れよう！と決めたのである。

　今から思い返してみてもそれがいつ頃のことか、何処で誰と話していたのかも思い出せないでいる。しかし、あの行方不明になったソースコードの行き先が、私には分かった気がした。確信を持って“分かった”瞬間でもあった。

　しかしこの様な出所も分からないいい加減な情報を誰が信じてくれるのか。誰も信用しないような話である。当時の組織はもう存在しないし、当時の上司ももういない。かえって多くの関係者に迷惑をかけることになってしまう。誰にも話さないことにしよう、そう強く思った。墓場まで持って行くことにしよう、と。

▼おわりに
　Multicsシステムは、私にとってはUnixよりも夢のある素晴らしいシステムだと思っている。そういうMulticsシステムの熱烈な愛好者のことを“Multician”と呼ぶ。私は今でもMulticianであり、Multicsに関する情報や当時一緒に働いた知人の動向を知りたくてときどきウェッブ上を捜すことがある。最近、Multicsプロジェクトの全容を集めたサイト( https://multicians.org/index.html )を発見した。

　これはプロジェクトの総括サイトであり、すべての記録が残っている。仲間とのハイキングの記念写真すらも整理されて残されている。一つの仕事を完了した時点で徹底的な総括を行なってすべての記録を残す習慣が着実に実行されているのである。

　ここで、私の知っている研究者の動向を知ることができた。
　CISLの所長だったCC氏はご存命のようだが、その他の私の知っている関係者は故人になっている人が多い。言語担当だったFH氏やBW氏らも既に故人となっていた。何時かはメールで連絡が取れ旧交を温めることができるかもしれないと思っていたのだが残念なことである。

　普段から毎朝のメールチェックでは、迷惑メールと見做される英文メールも注意深く差出人の名前だけはチェックしていたのだが、その努力も無駄であることを知った。彼らは私と同年代だったのである。
　このことが切っ掛けとなり、私も過去の出来事の後始末を付けようという気になったのである。

　「グリーンベレー」は、最初から書く積りはなかったので関係の資料が残っていない。書くことに決めてから、急遽古い資料を漁って当時の資料を捜して書くことにしたが、記憶違いがあるかもしれない。気が付いた方はご指摘いただければ幸いです。■

▼参考資料
・表の利用の仕方
　「ソフトウェアと〇〇」の一連のエッセイは、最初に日常生活の出来事に触れ、その後にソフトウェア技術の紹介へと移る形式をとっている。技術の紹介をいくら一生懸命書いても読者は退屈してしまい肝心のところまで行き着く前に読むのをやめてしまうことが多い。
　それを避けるには、最初の出来事(これを“前振り”と呼ぶことにしよう)を出来るだけ面白く書く必要があった。ここを読んでもらえれば、もしかすると後段の技術の紹介も読んでもらえるだろうという作戦である。
　この作戦はかなりの部分で成功した。しかし今読み返してみると前振りの部分の文章がつたなくて冗長である。ある程度コンピュータのことを知っている人には読み続けるのが苦痛になると考えた。そこで、個々の技術の話だけを(太字にして)部分的に読めるように工夫した(もちろん全体も読めますが)。

　　　・表示欄の“全体”は、前振りを含む全体を読みたいとき、
　　　・表示欄の“部分”は、前振りなしで個々の技術の説明を読みたいとき

項番表示 タイトル　と　内容　　　

(1) 　 「ソフトウェアと時差」(ファイルなし)

　　　自動車事故に遭った話。
　中公新書(1270)「ソフトウェアの法則」の中の“ソフトウェアと時差”参照。(新書版は絶版、電子版のみ入手可)

(2) 全体 「ソフトウェアと空中浮揚」

　部分 「ブートストラップ」についての説明

(3) 全体 「ソフトウェアとドッグフード」

　部分「ドッグフードを食べる」の意味とは…
「デバッグの難しさ」についての説明

(4) 全体 「ソフトウェアと石」

　部分 「創造と発掘」について

(5) 全体 「ソフトウェアと名前」

　部分 「悪さを企てたが未遂に終わった話」

(6) 全体 【プログラミング】美しさ

　部分 「Multicsシステム」の環境について