第 2 章世界の情勢 分散処理時代が始まろうとしている。 テクチャが急速に変化しようとしている。すなわち本当の意味での 激に増大しており情報処理システムのトータル・システム・アーキ ルコンピュータ、ワードプロセッサ、ターミナルなど ) の持っ役割が急 195 国業界との接触を常時行う事が肝要ではないか。 はもちろんの事、それ以外にも UIS の代理人 ( 駐在員 ) を米国に置き、米 為には NCC 、 SIGGRAPH 、 NSS 、 COMDEX 等へ要員を派遣調査させること 動きを常時監視し UI s の事業に反映させることが必要である。この ロッパの動きを無視することは出来ないが何と言ってもアメリカの 我々の見るかぎりこの業界の中心はやはりアメリカである。ヨー 業の出現、倒産はきわめて激しいものがある。 事実ここ 2 ~ 3 年の米国における情報処理業界の統廃合、提携、新企 年の変化は過去 10 年の変化よりも大きいのではないかと思われる。 展に伴い情報処理産業分野は大きくゆれ動いておりこれから 2 ~ 3 いずれにせよマイクロプロダクトと通信のディジタル化の進歩発 か先進国に多少の遅れを取っているとの印象をもった。 もあり又種々の法的規制による自由競争の排除などの影響もあって ない。わが国での ISDN の実現は法制度の適応的な再構築が必要な面 高度情報通信システムはまさにこの I SDN の実現のことにほかなら わが国で電々公社が称えている INS(Information Network System) 網の実現に血の道を上げている所以である。 ISDN(Integrated Service Digital Network ) 統合サービスデジタノレ は明らかに今日の社会に革命をもたらすことになろう。世界各国が を全て一貫して行うことを可能とする世界がひらけて来る。この事 声、画像、データなどの多様な情報の伝送、交換、処理、検索など との融合を多面的に進めることになり分散処理の要請と合まって音 グからディジタルへと変わろうとしている。これが通信と情報処理 一方 LSI 、 VLSI の活用により通信の世界がこれまた急速にアナロ

第 3 部拡張 売する会社が出現していた。 NUK はプロダクトリクワイアメント等を通じ UNIVAC 社に DRAM メ モリーの実現を要求し続けていたが、色よい返事を得ることは出来 ないままでいた。 ( 2 ) 試作 こんな時期に米国の某社が NUK にプラグコンパチプルメモリーユ ニットの開発案件を持ち込んできた。 赤須は秋元と相談の上、研究開発の名目で U Ⅵ VAC 1100 システム のプラグコンパチプルメモリーユニットを作成することを決定した。 このプロジェクトは極秘裏で進められ、総研が所有する社内用の UNIVAC 1108 を使用して稼動テストに漕ぎ着けた。 ( 3 ) UNIVAC への圧力 赤須は故意にこの情報をスペロニ (AAD:AsiaAfricaDivision UNIVAC の日本担当部門の TechnicaI Director で、日本に常駐して おり NUK 内部にオフィスを置いていた。 ) にリークし、 UNI VAC の反 応を窺った。 UNIVAC が何のアクションも起こさない場合は、日本市 場では UNIVAC 1100 システム用のプラグコンパチプルメモリーユニ ットが出回ることになるよという、強烈なプラフを UNIVAC に裏チャ ネルを通じて仕掛けたことになる。この出来事は UNIVAC 内部で大き な反響を呼んだと推測される。 これをきっかけとして UNIVAC ー NUK 間の開発契約の話が持ち上が り TDC ( 東京開発センター ) が設立された。 DRAM の採用も急速に具 体化し、インテルの協力を得て、 DRAM を装備した UNIVAC 1110 を UNIVAC 1100/40 という型番で実現する運びとなった。 このきっかけとなったプラグコンパチブルメモリーユニットの開 発は、稟議なしで開発部の予算内の遣り繰りで実施したため、後始 126

第 3 部拡張 危機感より、プロジェクトに対して全力投入して早期実現を図るよ う指示を出すと同時に、対 UNIVAC の作戦を開始した。当初渋ってい たスペロニも説得し、昭和 55 年 3 月より社長以下全社一丸となって UNIVAC の了承取り付けを開始した。この折衝は極めて難航したが、 最終的には了承を取り付け、昭和 57 年 3 月に客先納入を実現した。 これも強硬突破作戦であり、 UNIVAC の一切のサポート無しにディ スク制御装置の改造を実現し、 UNIVAC が了承しなくても実施に踏み 切るぞという強い姿勢で臨んだから出来たことであった。ディスク の制御は非常に技術的にも難しいものであり、改造の最終段階では キーとなる技術者の超人的な頑張りでやっと実現したが、 UNIVAC か ら見るととても出来そうも無いことを実現した NUK の技術力を見直 すことにもなったが、マイナス面として NUK に対する警戒心を抱か せる事にも繋がった。 日立ディスクの安定性は、 NUK の期待以上のものであった。それ 以上に NUK の経営にもたらしたプラス効果は大きかった。 8470 ディ スクが NUK に及ぼしていた負のインパクトが如何に大きかったかと いうことである。財務内容の改善も目を見張るものがあった。 ( 5 ) 問題の原因 8470 ディスクの不安定性の原因については、日立ディスクへの切 り替えが先行した為あまり話題にならなかったが、開発部は 8470 ディスクの品質検査を、大石完ーを中心にしてこっこっと実施して いた。そして最終的にはヘッドクラッシュの原因を突き止めていた。 それは完全密封されている筈のお釜に大きな盲点があったのであ 空冷の空気取り入れ口には完全なフィルタが付いており防塵対策 は完全かに見えたが、空気排出口が盲点になっていた。即ち電源を オフした時に、密閉ディスク内部に非常に強い吸引力が発生し、汚 る。 134

第 3 部拡張 第一弾として PNR を活用した「国内線運賃計算 & 発券システム」を 昭和 55 年 ( 1980 年 ) 3 月カットオーバーこの延長線上で名前べース のチェックイン及び搭乗管理システムが実現し、旅客処理の全自動 化を実現している。この他に FFP (Frequent F1yers program ・顧客 管理 ) があり、これは最近流行の CRM である。 ( 4 ) 団体予約 国内団体予約では、往路と復路で予約席数が異なるのが当たり前 であるが、これは国内団体予約の世界のみで、国際線を対象として いた USAS にはない機能でありこの実現には、 Non Homogeneous PNR (Heterogeneous PNR) 機能が必要であった。 UNIVAC は反対であっ たが、 NUK のリスクで USAS の優れた機能をベースに、国内団体予約 に限定した Heterogeneous PNR を実現している。 ( 5 ) PNR の評価 この様に結果だけ見れば PNR の採用すなわち UNIVAC を選択したこ とは全日空社にとって正しい選択であったと思うが、 USAS が未完成 であることによる USAS 不信・ U Ⅵ VAC への不信感が全日空社内には びこり、寺本部長、佐藤課長、大塚課長の苦悩は多大であったと思 昭和 53 年の第 2 次トレーニング開始後辺りから、 PNR による国内 座席予約を開始できるという理解を得られ、インべントリのみの予 約管理と PNR 十 USAS による予約管理精度の強大な機能差、及び顧客 サービス向上機能を理解され始め、 RESANA ー、の期待感が高まり NUK , 、の期待が大幅に向上し、信頼回復されたと理解している。 168

第 9 章全日空プロジェクト の岡田の認識は、 ・ RTOS は、未熟で稼動の見込みが立たず、 UNIVAC 社全体の予 算も逼迫していること。 ( 全日空プロジェクトが RTOS のカ ギを握ることになること ) ・ Harry Sweere 率いる AirIine Operations (AO) は、 USAS を設計するためのノウハウはあるが、 PNR 座席予約のよう な大規模ソフトウェア開発については見通しが甘く、開発 責任者の ReganCampbell は、アプリケーションに強く勉強 もしているが、納期や移行についてはいささか感覚が古い ソフトウェアマンであること。 ・ローズビルには H i gh Vo lume OLTP のノウハウがないので、 EXEC8 のアーキテクチャでは実現不可能とされていること。 ・ 1 100 シリーズ標準 OS での PNR 座席予約システムの実現に は、世界の航空業界の座席予約関係者が強い関心、という より実現の可能性についての疑問を持っており、カットオ ーバー延期申し入れのタイミングを誤ると全日空社は「キ ャンセルー IBM 採用」の路線を取ると予想されること。 ( 事 実、日本 IBM も含め IBM は実現不可能と見ており、いずれ UNIVAC はギフ。アップして、全日空が IBM に泣きついてくると 判断していたことが、プロジェクト発足後すぐに分かった。 ) 昭和 50 年 ( 1975 年 ) の 4 月に全日空の内示を受け、いよいよ待っ た無しの窮地に追い込まれた営業は、 TOP 折衝で広末営業本部長が 赤須システム本部長に膝詰め談判で岡田の割愛を要請した。この結 果 5 月には業務命令で岡田は全日空プロジェクト部長に就任する。 またシステム本部は岡田の放出に伴いソフトウェア開発部を廃部せ ざるを得なかった。 岡田はプロジェクト部長就任後考えられるあらゆる手を打った。 165

・ UN Ⅳ AC コンピュ ータの系譜 昭和 2 1 5 年 昭和 25 年 1 ー 昭和 3 1 5 年 昭和 35 年 1 昭和 4 1 5 年 昭和年 197 昭和 5 1975 年 昭和 55 年 198 昭和 6 19 年 世界最初の コンビュータ 世界刀の商用 コンビュータ ENIAC 田Ⅲ AC 煦 409 U ー 60 U ー 60 〔事務計算用〕 〔技術計算用〕 1 105 1103A 1 1 02 UMC USSC USSII U- Ⅱ FLO ト刊 C U-III 自動プログラム 割り込みの採用 〔技術計算用〕 LARC 〔オンライン用〕 UFC ランダム・アクセス 490 重プログラミングの採用多重プロセ、、サの採用 1 004 9200 9300 9400 9 300 0 9 400 1050 1 040 9 70 0 9700 〔汎用〕 1 1 08 1 1 1 0 1 バッチ、リモートバッチ、 リアルタイム、デマンド 処理を 1 台で実現 418 494 的リアルタイムを実現 機能分散プロセッサの採用 1 1 1 00 / 20 1 1 00 40 1100 / 80 トータル・コストセービングの思想 分散処理システムの実現 0 / 30 , 5 80 / 65 80 55 CHAPARRAL / 2 1 1 00 / 60 マルチ・マイクロプロセッサ方式の採用 1 1 00 / 90 拡張アーキテクチャの採用 1 1 00 70 1 100 / 90AD 双頭プロセッサ方式の採用 394

第 3 部拡張 面での接触も増大していた。この様な環境にいた関係で、岡田 は UNIVAC のソフトウェア関連の動き、実力、問題点に関する知 識、並びにキーマンとの関係が次第に深くなって行った。 ( b ) ソフトウェア開発部 昭和 45 年 ( 1970 年 ) に当時ブルーベルのソフトウェア担当駐 在員の堀内匡が岡田の後任として赴任し、岡田の希望で永年の 労に報いるインセンテイプとして、半年間の米国内でのプロジ ェクトマネジメントを勉学し帰国した。帰国後はシステム本部 のソフトウェア開発部長に就任した。ソフトウェア開発部はソ フトウェアェンジニアリングの確立を目指しての実験工場と しての位置付けで、岡田あっての組織であった。 ( c ) 全日空プロジェクトの編成問題 全日空へのセールスが最終段階に達した昭和 50 年 ( 1975 年 ) 初頭には、次の段階として全日空システムを実現するための全 日空プロジェクトの編成が問題として浮上していた。 大規模なアプリケーションパッケージを前提とするシステム 開発は NUK としても初めての経験であり、しかも NUK に業界知 識の無い分野で且っ米国 U Ⅵ VAC 製のパッケージ (USAS) が前提 とあっては、このシステム開発のプロジェクトリーダーが勤ま る人材は極めて限られていた。 ( d ) 岡田の認識 岡田自身やってみたいと長年思い続けていた仕事ではあった が、なにせ前提条件が悪すぎた。 UNIVAC 社内部の状況を熟知し ていた岡田の目には「納期はダメ / キャンセルの危険大」とし か見えず引き受ける気にならなかったのはうなずける。この時 164

第 5 部ユニバックあれこれ NTT では、 1970 年代に世界に先駆けて「新データ網である回線交 換網 (DDX-C) 」と最大のイベントである「新データ網のバケット交 換網 (DDX-P) 」をサービスするという計画をたてていましたが、 その第一関門の回線交換サービス (DDX-C) が昭和 54 年 ( 1979 年 ) 12 月最後の月にサービスが出来、 NTT としても「何とか 1970 年代に実 現した」と胸をはって喜んだ当事の技術局部門長の顔を思い出しま す。この翌年に X25 通信網であるバケット交換サービスの試行が行 われました ーーにおいても日本ュニバックの協力が NTT に大きく 平価された時期でした。 何故試行サービスかというと本来的な世界標準である 80 年度版 X25 プロトコルがまだ発表前であったことと IBM などの主要外国製の コンピュータメーカの反対があったための試行といわれています。当 時の IBM も SNA の発表 ( 1976 年 ) から昭和 53 年 ( 1978 年 ) に SNA の拡張 版を発表。この時期に SNA の体系下で X25 を接続するという公式発表 を行いましたが国内の NTT 仕様の X25 対応の接続には間に合わず、 の世界でも NUK が先行して NTT 仕様 X25 対応の接続試験に取り組み、 成功を収めました。この実績を基に、昭和 56 年 ( 1981 年 ) 7 月に全 国共済農業協同組合連合会 ( 全共連 ) の全国バケット交換網オンライ ンがわが国で初めて実現しました。同時に、労働省 ( 昭和 56 年 7 月 ) 、 沖電気 ( 同月 ) 日本情報サービス ( 現日本総合研究所 ) 富国生命 ( 昭 和 57 年 4 月 ) 、以降富士銀行、近畿日本ツーリスト、日貿信、宇部 興産、農林漁業金融公庫 ( 農林中金 ) 等が多数、実現し、バケット交 換の UNIVAC という評価を得るようになりました。 当時の NTT の新技術の対応に一番早いコンピュータメーカとして 「 UNIVAC 」の名前が強く残った時期でした。 4. 国産標準プロトコル (CCNP プロトコル ) の対応 分散処理の実現化、公衆データ網の実現と商用化、ネット ーワー 一三ロ 280

第 9 章全日空プロジェクト ことしやかに伝えられたが、どこまで本当だったかは分らない。 EXEC 8 は、汎用 OS として自由な多重プログラム処理を実現し、 他のユーザーを意識しないで大量のデータを伴うアプリケーション プログラムをこなすバッチ処理、やはり他のユーザーを意識しない で多数の端末から大勢の人が同時にコンヒ。ュータを利用することが できるタイムシェアリング処理、リアルタイム処理の中でも現在 0LTP(OnIine Transaction Processing) と呼ばれている分野に対応、 これらの全ての機能を備えることが目標であった。ュナイテッド航 空の PNR 座席予約システムを実現することは、リアルタイム処理の 中でも高速処理が必要な大量のトランザクション処理が可能である ことを意味した。 EXEC 8 の目指したものの内、 EXEC II の Run Control Stream を拡 張した本格的多重プログラミングによるバッチ処理が最初に実現し、 次いで 1960 年代の終わりには、約 100 台の実機によるタイムシェア リングのテストにも成功していた。しかし、リアルタイム処理につ いての方向ははっきりしなかった。 ( 3 ) リアルタイム処理に関する状況 セントボール系コンピュータの特徴の一つは、軍用のシステムに 始まるリアルタイム処理にある。リアルタイムといっても、民間の アプリケーションでは OLTP ということになるが、この技術は UNIVAC 418 / 490 に引き継がれノースウェスト・オリエント航空、ルフトハ ンザ航空、ブリティッシュ・ユーロピアン航空 ( 当時 ) 、イースタン 航空など、航空各社を含め、数多くのユーザーで成功を収めた。 日本では UNIVAC418 による富士銀行のリアルタイムバンキングシ ステムの他、 U Ⅵ VAC490 による国鉄をはじめとした輝かしい実績が UNIVAC 1108 と時を同じくして UNIVAC 494 が、 UNIVAC 490 の後継 1 47

第 9 章全日空プロジェクト NUK が共同開発の立場で TIP の開発に参画した経緯に関して は、第 7 章商品開発の 8 項の TIP の採用迄の経緯に詳述した ので参照願いたい。 NUK はこの開発に「野村 TOPS 」の開発の中 心人物を初め多くの OLTP のノウハウを持った人材を投入して いる。 TIP を最終的には UNIVAC 開発部門の標準製品に持ち上げたの は NUK の努力の賜物と言うことが出来る。 TIP の実現には大袈裟に言えば NUK の存続がかかっていた。 それだけに TIP の客先導入は先行せざるを得ず、 TIP の NUKzÄ ージョンは標準製品より先行しており、強固な TIP 開発勢力を NUK 内部に抱えることにもなっていた。このことが結果として 全日空プロジェクトの成功にも繋がっていく。 (b) High volume OLTP を実現すること 当時の PNR 座席予約に代表される HighVolume0LTP を実現す る為には、 OS のオーバーヘッドを小さくする必要があった。ュ ナイテッド航空にコミットはされたが、もともと EXEC 8 はオー ルラウンドプレイヤーであることが求められており、開発部門 でもオーバーヘッドを小さくすることは第二義的なものと考え ていた。開発グループにとっては、自分たちが知らないうちに 営業がコミットして来た迷惑な機能であったのかもしれない。 この分野に関する動きはインターナショナルディビジョンから提 起された。即ち、 RTOS (Real Time 0perating system) である。 1960 年代後半にプリティッシュ・ヨーロヒ。アン航空のプロジェク トマネジャを務めた経験を持っ Edwin s. Mack がロンドンに開発セ ンタ—(lnternational Research & Development center : IRDC—後 LDC) を設立し、 EXEC 8 と同じ API (AppIication Program lnterface) 1 49