２． （電サ）が主役

１９８８年に日立電子サービス［以下（電サ）と略称］の溝口さんが言い出して、８３５０の同窓会が開かれた。ソウルでオリンピックが開催された年だった。当日は秦野市の渋沢の料理屋に、東は茨城から西は広島まで、全国各地から昔いっしょに仕事をした仲間が集まって昔話に花を咲かせた。

それは忘れもしない８８年の１１月２２日のことだった。どうして日にちまではっきり覚えているかというと、その日は米軍のヘリコプタが日立の神奈川工場に不時着したり、私の靴を間違えて履いて新幹線に乗って名古屋まで帰ってしまった人がいたり、変なことが立て続けに起き、翌日新聞を見たらケネディ暗殺の２５周年の日とのことだった。

ちょうどオリンピックの年だったので、今後４年に１回、オリンピックの年に集まろうということになった。こうして第２回は９２年、バルセロナの年に真鶴に集まった。今回は何も起こらないだろうと寺島（光一）さんといっしょに大森から出かけたが、東海道線と新幹線が同時に架線切れで不通になるという珍しい事故が起き、宴も終ろうという頃にやっと真鶴までたどり着いた。この時は日立の保養所に泊まり、翌日ゴルフをした。

こういうわけで同窓会のたびに変な事件が起きるのだが、昔の仲間と思い出話しをするのは実に楽しく、時のたつのを忘れる。みんなの記憶力のよさにも驚かされる。

今と比べるとこの時代の方がみんなのびのびと仕事をしていたように思う。私など好き勝手に仕事をさせてもらっていた。新しい技術は管理されすぎた開発プロジェクトからはなかなか生まれない。技術の方向を見極めた上でのいい加減な判断が重要なことも多い。これからの仕事のしかた、させかたについて考えなければいけない点と思っている。

４年に１回となると、次は９６年のアトランタの年になったのだが、もうみんな先が短くなったので、この時以来冬季オリンピックも含めて２年に１回開くことになった。

本小冊子はリレハンメルで冬季オリンピックが開催された１９９４年の同窓会の時に、思い出話のよすがにと書いたものである。

「８５００の思い出」同様、これは極めて個人的な、８３５０の一面についての思い出で、８３５０の開発にはここに登場しない多くの方々の貢献があったことは言うまでもない。

また手元にあまり資料もなかったので、記憶違いもあるかと思う。失礼なことがあったら御容赦頂きたい。間違いに気付かれた方は御連絡頂ければ幸いです。

６８年１２月に神奈川工場の設計部隊が横浜の戸塚から秦野に引っ越した。その後６９年の始めまで私は８５００Ｓの後始末に携わっていた。８５００Ｓの目処がつくや否や、８３５０の開発に取りかかった。６９年の２月か３月のことだったと思う。

当時神奈川工場では３大プロジェクトが走っていた。

その一つは８７００であった。これは銀行等で最も要求が強かった８０００シリーズの第２世代の最上位機を目指したものだった。

もう一つのプロジェクトは通産省の「超大型プロジェクト」に対応する技術計算専用の超大型機とそれを一般マーケット向けに商用化した８８００の開発であった。

これら二つのプロジェクトには村田（健郎）さん、中澤（喜三郎）さんはじめ５０２０を開発した方々が主として従事されていた。

３番目のプロジェクトは当時の電電公社の「ＤＩＰＳ」であった。このプロジェクトには８５００に従事されていた関（弘）さん、井上（武洋）さん他、馬場（徳夫）君、野上（康一）君等がごっそり移って行った。

こうして８５００のメンバーで残ったのは私一人になってしまった。

しかし３大プロジェクトだけで飯を食っていくわけにはいかなかった。８３００、８４００の後継機を何とかしなければならなかった。

８３００等の８０００シリーズの第１世代機はＲＣＡのＳＰＥＣＴＲＡシリーズをベースにしたものだった。ところがＲＣＡはその後継機をまじめに開発していなかった。ＳＰＥＣＴＲＡの７０／４５を開発したYen,７０／３５を開発したNeilson等の主力エンジニアはＲＣＡを離れてしまっていた。当時「３Ｒ」作戦と呼ばれていたが、ＳＰＥＣＴＲＡシリーズの「Renaming、Reskining、Repricing」、要するにお化粧直しでごまかそうとしていた。こんなことでは到底うまくいくように思われなかった。そこで８０００の後継シリーズは自社開発することになった。この決断には８５００の自力開発に成功した自信が大きかったと思う。

結局ＲＣＡはその後２年あまりたった７１年９月にコンピュータから撤退してしまった。早めに縁を切っておいたおかげで日立は助かった。

８３００の後継機である８３５０については、８４００の仕事から開放された寺島（光一）さんが中心になって検討を進めていた。そこへ私が加わったのだが、当初は他には小宮（充男）君、石橋（陸泰）君、木田（正彦）君ぐらいしかいなかったと思う。

あとはもっぱら電子サービスの人に仕事をしてもらっていた。開発の初期からＡＬＵまわりと故障診断は常世田君、チャネルは南君に中心になって設計してもらった。その後全国各地から順次応援に来てもらった。溝口、永橋、福井、末次、横山、後藤、他の皆さんだった。

その後新しい方式の「マイクロ診断」のプログラムと辞書の作成に人が足りなくて困っていると、今は亡き（電サ）の角田（基文）さんが教育を終ったばかりの（電サ）の新人を大勢一度に送り込んでくれた。新しい故障診断システムを何とかものにしたいと企んだものだった。それは伊藤、小嶋、松本、持沢、他の皆さんだった。

松本君はその後私のところで庶務の仕事をしていた久保珠美さんと結ばれた。角田さんの媒酌で大阪の天王寺で式を挙げられ、私も出席させて頂いた。これも８３５０プロジェクトの一つの成果であった。

こうしてピークには２０人に近い（電サ）の人がいっしょに仕事をしていた。

当時はみんな若かったのでよく遊びに出かけた。山中湖、湯河原、伊香保等へ車を連ねて繰り出したことを懐かしく思い出す。一杯入ると必ず聞けるのが横山さんの秋田の民謡だった。先日同窓会の折、２０年振りに大変懐かしく聞かせてもらった。

こうして今でも同窓会を開くと工場の人より（電サ）の人の方がはるかに多い。あまり多くなりすぎるので後半戦に参加した（電サ）の新人は呼ばなかったのにこのありさまであった。

「いったい８３５０は誰が設計したんだ？」

と話し合った。

ない袖は振れなかったわけだが、こういう体制で仕事をしたため、工場に開発力の蓄積を充分できなかったのは残念であった。ただわれわれ工場の者にとって最前線のサイトの生々しい話しを聞くことができたことは貴重な経験であった。

開発を開始した当時の設計の主任技師は飛永（勝年）さん、部長は佐藤（利男）さん（現在の大沼さん、元 （電サ））だった。昔のことなので時期がはっきりしないが、多分１年くらいして主任技師は関（弘）さん（現 国際電気）、部長は波多野（泰吉）さん（現 トキコ）に変わった。そして寺島さんは新たに８２５０を開発するためにわれわれのチームを離れていかれた。

３大プロジェクトのあおりは開発の最後まで続いた。ＤＡのマシン時間の取り合いもその一つであった。まともにぶつかっては勝ち目がないので、間隙を縫うようにして仕事を進めた。

「ダンプカーの合間を縫って走る軽自動車のようなものだ。近寄りすぎるとはね飛ばされるから気を付けろ」

と当時話し合っていた。いっしょに仕事をした人達には大変な苦労をかけた。

基本回路には当時一般化し始めていた市販品のＴＴＬを使うことになっていた。またプリント基板には先行していた８２１０で開発された「高密度配線板」の使用が予定されていた。これは４層で１００ミルピッチの格子間を２本の配線が走るごく普通のものだったが、８０００シリーズの手書きのミミズが走るものに比べればはるかに高密度であった。

この二つの新しいハードウェア技術で、８５００に近い性能のＣＰＵをコンパクトに安く実現し、８３００の後継機を作ろうというのが８３５０のねらいであった。

このように基本的な方針は決まっていたが、私としては今回是非とも実現したいと思っていたことが二つあった。

その一つは設計を見通しよく、手戻りなく進めることであった。前回の８５００の開発の時は、経験不足のため、手探り、試行錯誤の連続であった。ある程度設計が固まったところで、机上でのチェックは行き詰まり、試作機を作って延々何ヶ月もかかって調整した。今後はこういうことではだめだと思っていたので、８３５０ではマイクロプログラムのシミュレーションの改善を図った。これについては別項で触れる。

もう一つは保守性、信頼性の改善であった。８５００ではこれの不足のため大変な苦労をした。サイトで事故が起きても原因が分からず、何日間も徹夜して調べたことが何回もあった。徹夜明けの朦朧とした頭で、「設計者が何日間も徹夜しても分からないような事故を起こす機械を世の中に送り出すのは社会的罪悪だ。次の時は何とかしなければ」と思い続けていた。

保守性改善の面で最も力を入れたのは「マイクロ診断」と「エラーロギング」だった。これらについても項を改めて触れる。

保守機能の強化については（電サ）の常世田君、南君他といっしょになって、考えられることは何でもやってみようという方針で進めた。当時の報告書を見ると、

　　　過去２サイクルのＲＯＭアドレスを保管しておくレジスタ

　　　プログラムによるコアメモリのマージン試験機能

　　　マイクロプログラムの指定部分を繰り返し実行する機能

　　　スタートスイッチの信号を自動的に繰り返し出す機能

等、変わった機能が数多く出ている。

８５００では少なすぎて困ったので今度は逆方向に振り切ってみようというのが私の考えであった。何年かたってからこれらの機能のサイトでの使用状況を調べたところ、障害自身が大幅に減ったこともあって、ほとんど使われていない機能が多かった。しかし今でも技術の進歩のためには振り切ってみることも重要と信じている。

今から思うと８３５０の保守性強化については本当にやりたい放題のことをやったように思う。なかには道楽に近いようなものまであった。最近はコストの競争が厳しくなってこのような道楽じみたことをするゆとりはほとんどなくなっているが、製品開発時のこういう「ゆとり」は非常に重要だと思っている。

それにしても性能、信頼性、早期開発が最重要課題でコストは二の次の古きよき時代であった。

特に当時のマイクロプログラムにはワードシート型のＲＯＭが使われていたので、変更があると大変だった。バグが見つかると手動のワードシート穴あけ機で１ビットづつ穴をあけ、ＲＯＭのスタックをばらしてワードシートを交換し、スタックを組み立て直して調整を続ける。そうするとすぐまた次のバグが見つかるという具合であった。

こういう事態を解決するためマイクロプログラムのシミュレーションに挑戦することにした。

すでに８５００等でも一部シミュレーションを実施していたが、８３５０では新しい試みとして「試験プログラム」を直接シミュレーションのテストデータとして使う方式に挑戦した。試験プログラムの磁気テープから指定したブロックを次々に読み込んでシミュレーションを実行するというものであった。これがうまく行けば、命令語のマイクロプログラムに関する限り、実機では試験プログラムが一発で通るはずであった。

８３５０のマイクロ命令の仕様は８０００のアセンブラ言語で記述した。８０００の命令語を実行するためのマイクロ命令を記述するのだから、ＦＯＲＴＲＡＮ等を使うよりこの方が容易なはず、との判断だった。当時は高級な論理記述言語など無かった。タイミング等もできるだけ実際の論理に忠実に記述し、方式設計の不良も見つかるよう狙った。

シミュレーションを制御する「モニタ」は６９年に入社したばかりの吉田（和史）君に中心になって作ってもらった。

こうして作ったシミュレータを実行して、５０件のマイクロプログラムのバグと１０件の方式設計不良を見つけることができた。試作機の試験プログラムによるテストは命令語に関する限り不良ゼロで、当初の目的を達成することができた。

その後の神奈川工場でＭ−２４０等全面的にＬＳＩを採用したＣＰＵを開発の際、大型コンピュータを湯水のように使って試験プログラムを直接シミュレーションするのが一般化したが、８３５０のアプローチはいわばそのはしりであった。

その一つはＲＣＡの７０／３５等で試みられたマイクロプログラムによる診断であった。この方法の弱点はマイクロプログラムを磁気テープ等からメインメモリへロードして診断を開始するまでに半分以上の論理を使ってしまうことであった。つまり相当正気でないと自分自身の体の診断はできないということである。

もう一つはＩＢＭの３６０／５０等で試みられたＦＬＴ（Fault Locating Test）と呼ばれるものであった。これは診断専用のスキャンイン／スキャンアウトパス、制御論理を持つもので、気違いが気違いを診断するという問題はなかったが、ハードウェアの負担が大きく、また診断データの作成が大変であった。

われわれはマイクロプログラムによる診断を改善すれば実用に耐えるものにできるのではないかと考えた。これには（電サ）の常世田君の貢献が大きかった。

まず診断プログラムのロード用に単純化した入出力チャネルの機能を用意した。

次にこの機能を含め診断プログラムを実行するために正常に動作しなければならない機能（ハードコア）を、ごく単純な機能から一歩一歩確認するマイクロプログラムを作り、これをＲＯＭに常駐させた。これを「ハードコアテスト」と呼んだ。そして確認が済んだ機能を使いながら少しずつ確認済みの範囲を増やしていく方法を「ブートストラップ構造」と呼んだ。

こうして基本機能の診断が終ると、次はレジスタへのデータの書き込み、読み出しが正しくできるかを確認する。これを「スキャンイン・スキャンアウト・テスト」と呼んだ。

このあとこれらの診断済みの機能を使ってマイクロ命令の機能をひとつづつ確認していく。

このやり方は新設計のコンピュータの試作機の組み立てが終った時、基本機能からひとつづつ人手で確認するやり方と同じであった。これは人間の故障診断の手順と非常に近いため、複雑な故障で直接故障個所を指摘することができなくても、人間がトラブルシュートをする時の有力な手掛かりを与えることができると考えた。

こうして６９年に診断方式の構想を固め、ハードウェアを作りこみ、７０年に入って診断プログラムの開発に取りかかっていた。

こうしたある日、私はＡＦＩＰＳ（アメリカの情報処理学会）の７０年のＳＪＣＣ（春の学会）の論文集を見ていて腰を抜かさんばかりに驚いた。それにはＩＢＭの３６０／８５の診断方式の論文が載っていたが、その考え方はわれわれとまったく同じものであった。

われわれが「ブートストラップ構造」と呼んでいたものを彼らは「スタートスモール」と名付けていた。

われわれが「スキャンイン・スキャンアウト・テスト」と呼んでいたものを彼らは「ゼロサイクル・テスト」と名付けていた。

名前こそ違ったが基本的な設計思想はまったく同じであった。ただ３６０／８５はマイクロプログラムの格納用にＲＯＭでなくＲＡＭを使っていたので、診断用のマイクロプログラムの格納にメインメモリを使っていたわれわれの方式よりすっきりしていた。

ＩＢＭはこの方式を「マイクロダイアグノスティックス」と名付けていた。われわれもこれに対抗して名前をつけなければいけないとみんなで相談した。その結果、「ＨＤＳ（日立ダイアグノーズ・システム）」と呼ぶことにした。

「マイクロダイアグノーズ」というのはＩＢＭの用語だと、当時われわれは対抗意識を燃やして使わなかった。しかしこの診断方式が一般に普及し、日本でも「マイクロ診断」という言葉が定着すると日立社内でもこの言葉が一般に使われるようになった。

この８３５０で採用した診断方式を常世田君といっしょに電気通信学会の全国大会で発表し、「日立評論」にも論文を載せた。

その後のＭシリーズではこの診断方式が広く採用されるようになった。

６． （電サ）の人をソフトウェア工場へ送り込む