カテゴリー

  • 日記・コラム・つぶやき
  • 経済・政治・国際

« 「50歳からの手習いゴルフ」に「団塊シニア賛歌」を寄稿--情報社会学、予見と戦略(15) | トップページ | 福田首相の「生活者・消費者重視」論と「社会的サービスを担う市民」の現実--情報社会学、予見と戦略(16) »

早く到達しすぎたリッチクライアントシステム「世界初MMLシステム-その3」--アルゴリズム戦記(19)

(「鐘の声 ブログ」記事マップ)

2008/01/14
早く到達しすぎたリッチクライアントシステム「世界初MMLシステム-その3」--アルゴリズム戦記(19)

ミニシリーズ:アルゴリズム戦記「世界初MMLシステム」(全4回)
-------------------------------------------------------------------------------
1.花のマックスファクターとの出会い「世界初MMLシステム-その1」
  --アルゴリズム戦記(17)

2.ユーザを待たせないアルゴリズム「世界初MMLシステム-その2」
  --アルゴリズム戦記(18)

3.早く到達しすぎたリッチクライアントシステム「世界初MMLシステム-その3」
  --アルゴリズム戦記(19)

4.MMLの終息、そして今へ「世界初MMLシステム-その4」
  --アルゴリズム戦記(20)

-------------------------------------------------------------------------------
前回の記事から続く

実は、この「端末には端末の得意な処理を、ホストにはホストの得意な処理をさせる」という発想こそがMicro Mainframe Link(MML)というものの考え方そのものであったのである。
とりわけグラフィック画面の生成はパソコンのほうがはるかに速いことがこの発想のその第一の基になっていた。しかも、もしホストコンピュータでグラフィック画面を生成してから端末に送るのであれば、元になるデータの数千倍ものデータ量を転送しなければならないのである。転送時間を考えると、それは、ありえない選択だったのである。
この仕組みを少し詳しく説明することにしよう。

(1)物理的な通信について
今のようにインターネットが存在するわけではなかった。室内でホストコンピュータ(ACOS2)とパソコン(N5200)を繋ぐことはできた。この場合、パソコン(N5200)は単なる端末になるだけである。一方、公衆回線を介してコンピュータ通信を実現する方法に普及型の汎用的な方法は存在していなかった。我々がほしいのはいわば、ホストコンピュータ(ACOS2)とパソコン(N5200)の対等な公衆通信であった。
HDLCプロトコルは使えそうだったが、NECには対応する標準的なユーティリティが存在しなかった。
一時はRS232Cを利用して音響カップラーでの通信も検討されたが、死ぬほど遅いことが予想され、とても手を出す気にはなれなかった。
そのうち、NECの技術者たちがHDLCプロトコルを利用するユーティリティを発掘して届けてくれた。おそらくは金融システムの分野で使用されていたものだろうと推測された。N5200でこれを使用するためには少しばかり繋ぎとしてアセンブラで組まなければならない部分があったが、例のデブとヤセの2人組みがこれにはせ参じて対応してくれた。
この分野は、試行錯誤しながら何とか進んでいった。

(2)アプリケーション上の通信について
この部分については、私に秘策があった。
アプリケーション上の通信については、できるだけ小さなデータセットの往来で、ホストコンピュータとパソコン(後にはサーバとクライアントと呼ばれるようになったもの)が、最新情報を共有し、正しい情報に基づいて協調的動作をするようにするという考えであった。
1)最新情報の共有
ホストコンピュータとパソコン(後にはサーバとクライアントと呼ばれるようになったもの)が共通して持っていなければならない最新情報とは、この場合、分析軸に関する情報である。
分析軸は固定的なように見えて、頻繁に修正が加えられる。この問題については、前回の記事に書いた通りである。たとえば販社につながる営業所は年に何度も統廃合や新規オープンがある。市区町村の統廃合や名称変更も頻繁である。商品軸に至っては新製品発表や廃番商品も頻繁なのでさらに激しく変更が加わるのである。これらの変更は、画面からのデータ変更操作で容易にできるようにした。これらの軸に沿った編成データは、夜間バッチで生成される。
夜間バッチでは、夜間バッチが走り始める直前までに修正された分析軸のデータが利用されるので、前日までの分析軸とは異なる集計の方法がされている可能性もあるのである。N5200が、古い分析軸のデータに基づいて該当するデータを要求しても該当データがない危険性もある。そこで、N5200にもホストコンピュータ側にもそれぞれが保持している最新の12個の分析軸の基本データの更新日時と大量データの更新日時の一覧(テーブル)を入れておくのである。もちろく、更新日時を管理しているテーブル自体の更新日時も管理する。
まず、パソコン側のシステムが起動するとN5200は、更新日時を管理しているテーブル自体の更新日時をホストコンピュータに送る。ホストコンピュータは、自分の持っている更新日時を管理しているテーブル自体の更新日時と同じであれば、OKの情報だけを返す。この場合、N5200はこれ以上基本データの要求を送ることなく、ユーザーからの要求(ほしい表示に関する要求)を待つことになる。
もしも、ホストコンピュータが持っている「更新日時を管理しているテーブル自体の更新日時」のほうが新しければ、「更新日時を管理しているテーブル」のデータを接続中のN5200に送り返す。受け取ったN5200は送られてきた「更新日時を管理しているテーブル」のデータと自分が持っていた「更新日時を管理しているテーブル」のデータを仔細に比較して、自分が持っている基本データの更新日時のほうが古くなっている基本データをピックアップして、送信要求を行う。ホストコンピュータは要求に応じて更新されている基本データを送り返すのである。多くの場合、全ての基本データが更新されていることはないので、せいぜい1つか2つのデータが送られるにとどまるので、時間はかからない。かくして、ホストコンピュータとパソコンは、共通の認識の上でデータのやり取りが可能になるのである。
人の世界でも正しく情報がやり取りされるためには、共通認識が極限までに完璧になされていることが必要である。情報システムにおけるコミュニケーションにおいても事情は全く同じということである。
さてさて、そもそもコンピュータの世界では難しい問題に直面したら、人ならばどうするか、と考えてみることが、良いシステムをつくるコツである。人が考えてなすようにコンピュータにもさせてみること、これが人工知能の基本的な考え方であるが、これがここでも効を奏したのである。
ホストコンピュータとパソコンN5200が回線を介して共通認識に立つことになれば、N5200に提示される分析の軸もホストに持っている大量の編成データの分析軸と同じものが表示されることになる。パソコンN5200の前に座っている人は、その提示された分析軸の中から自分がほしい軸のレベルとそれらの組み合わせを指定できるのである。このようにすれば、N5200がホストに要求する1ページ分のデータに該当がなかったり、間違ったデータを指定したりすることはなくなる。
2)表の表示とグラフの表示
当時は、表やグラフをパソコンの画面上に表示使用とするならば、座標の一つ一つを計算して描かせなければならなかった。表とグラフではまったく別のロジックが必要だったが、それぞれに計算処理が必要なのは共通していた。処理速度を稼ぐためにC言語を利用したが、スピードを上げる工夫はそれが全てではない。
従来の考え方で、仮に同様のシステムを作ろうとすれば、表やグラフを作る計算はホストコンピュータ側で実行して、端末はその結果のマッピングデータを転送して受け取るというものにならざるを得なかった。ホストコンピュータには、当然のことながらグラフィックボードなどはない。それだけでも計算はパソコンに比べて極端に遅い。複数の端末から要求があると要求同士がぶつかってハングアップすることもないとはいえない。しかも出来上がったマッピングデータは、元のデータの数千倍の容量になる危険性がある。通信時間を考えるととても実用的ではない。
私の考えは、元データだけをホストから持ってきて、計算は全てパソコン側でやるというものであった。当時もパソコンN5200はそれなりのグラフィックボードを持っていた。しかも、複数の端末からの要求を受け取ることなどありえないい、--何しろ当該のパソコンを使用している一人のために計算を行うだけなのだから、他からの要求などが飛び込んでくる恐れはなかった。パソコンの中で生成するデータが元データの数千倍になろうとも、通信に必要なデータは元データのままなのだからごく小さいのである。
要は、今の技術で言えばリッチクライアント技術の考え方であるが、それを20年前の当時の環境が許す範囲ですっかり実現したようなものだったのである。いわば、それは早く到達しすぎたリッチクライアントシステムだった。

当時としては考えられないパフォーマンスに関係者は驚嘆してくれたようだった。
情報処理学会には招待を受けて講演をした。
http://fw8.bookpark.ne.jp/cm/ipsj/particulars.asp?content_id=IPSJ-IS87017002-PDF
その後、デモと講演の依頼が次々とやってきた。その後しばらくはコンピュータ業界で私は英雄扱いだった。全国でデモと講演は行われた。その数は数十回、仙台、大宮、東京、横浜、静岡、名古屋、京都、大阪、和歌山、広島、福岡、・・・、おかげでたくさんの土地のおいしいモノを知ることができた。花王、ライオン、エステー化学、・・・などなどの大手企業にも出向いた。
さて、ところで、このようなデモと講演の依頼は、零細な当社にとっては経済的に大変な負担でもあった。主として依頼をもたらせてくれたのは、NECの装置産業事業部とその関連企業からである。NECの優れた技術の紹介をしてほしいというのである。NECの皆さんのお力添えもなければ実現できなかったシステムであることを思えば喜んでお受けするのが当然だったが、私たちの会社のフトコロを直撃することにもなった。NECは化粧品業界の巨人マックスファクターがその費用を負担していると思っていた節があり、マックスファクターは依頼主のNECが私にその費用を支払うのが当然と思っていたところがあったようだ。1回の出張で、機材の運搬、旅費宿泊費、スタッフの人件費を合わせるとかなりの金額になる。音を上げて、NECやマックスファクターに補助を願っても「検討する」との回答だけでなしのつぶて・・・。結局、NEC東芝の営業部長さんが数万円の謝金を1度だけ捻出してくれたことがあったに過ぎない。1回分の費用にしてもまことに"焼け石に水"というべきだった。計算したことはないが当社にとっては数百万相当の負担だったに違いない。名誉ではあったが、困惑の極みであった。しかも、出先で待機して下さるNEC関連の社員さんたちは、ご当地に宿泊することになる私たちと夕食をともにしてお酒を楽しそうに飲むことが多かったが、率先して自分の分を支払う方はほとんどいなかった。あえて、請求するのもはばかられたので、ニコニコと私が支払うはめになった。皆さんともに人柄の良い方ばかりだったが、通常業務とは別に、我々の出張に付き合うように上司から命じられただけなのだろう。本人たちの自己負担となるのは筋違いというものである。皆さんは、ご苦労様会ぐらいはしてくれて当たり前と思っていたに違いない。
いささか、嫌気が差し始めていたころ、突然、当時NECの装置産業事業部長をしていた金杉明信氏から呼び出しがあった。昭和63年4月14日のことである。驚いたことに宴会場はNECの装置事業部の関係者とその顧客企業の情報システム部のおえらい方ばかりが立派に着飾って会場狭しと詰め掛けていた。私はそんなつもりではなかったので貧相な普段着のままである。実は、装置事業部創立記念式典ということで、お偉い方々のご挨拶に続いた。そして、私の名前が呼ばれ、おずおずと壇上に登ると、最新技術の開発に貢献したとの説明があって、表彰状が金杉氏から手渡された。このときばかりは金杉氏がひどく大きく見えた。私はただただ唖然として驚き、ドッキリカメラでもあるのかと、思ったくらいである。私の心情を慮って、金杉氏が配慮したことだったらしい。金杉氏は後にNECの代表取締役になり、すでに亡くなっている。彼は、そのような配慮のできる方だった。このときの表彰状は、今でも我が家の居間に飾ってある。これを見るたびにほろ苦い思いがこみ上げてくる。

マックスファクター様の依頼でその後も、マイクロメインフレーム(MML)タイプのシステムは、次々に開発され、1991年3月マックスファクタが事実上倒産するまで続けられた。

その間に開発したシステムは、次の通りである。

昭和60~62年(1985年から1987年)
マックスファクター株式会社様向けマイクロメインフレーム(MML)タイプの意志決定支援システム「MDBSコース検索」を企画設計製造。アドバイザとしての活動の端緒となる。全国ネットシステム。後に当社から「DSS-CUBIC 希望」の名称でパッケージ販売する事になったものである。プロジェクトリーダー。
ACOS2,COBOL/S,ETOS52G,PTOS,COBOL5

昭和62~63年(1987年から1988年)
マックスファクター株式会社様向けマイクロメインフレーム(MML)タイプの意志決定支援システム「キャプテンサポートシステム(経営支援システム)」をアドバイズ&企画設計製造。全国ネットシステム。プロジェクトリーダー。
ACOS2,COBOL/S,ETOS52G,PTOS,BASIC

昭和63~平成1年(1988年から1989年)
マックスファクター株式会社様向けマイクロメインフレーム(MML)タイプの意志決定支援システム「プレゼテーションサポートシステム」を企画設計製造。PTOSの限界と言われたグラフィック処理を実現した。全国ネットシステム。アドバイズ企画設計。プロジェクトリーダー。
COBOL5,FORTRAN

平成1年~平成4年(1988年から1991年)
マックスファクター株式会社様向けマイクロメインフレーム(MML)タイプの意志決定支援システム「MDBSオーダ検索」をアドバイズ企画設計製造。予期駆動型フレーム理論を適用した人工知能型の検索、システム自動生成、帳票の自動生成の機能を持つシステムである。全国ネットシステム。顧客企業が他の企業に買収され事実上解体されため、プロトタイプの完成をもってプロジェクトを中断した。プロジェクトリーダー。
ACOS2,COBOL/S,COM-XE(通信ユーティリティ),
OS/2,PM,SmallTalk

最後のシステムは、予期駆動型フレームを使用する人工知能型のシステムで、エージェントシステムを狙うものであった。

(以下、つづく)

△次の記事: アルゴリズム戦記(20)
http://shyosei.cocolog-nifty.com/shyoseilog/2008/03/mmlmml420_9517.html
▽前の記事: アルゴリズム戦記(18)
http://shyosei.cocolog-nifty.com/shyoseilog/2007/08/mml218_0171.html

琵琶


(補1)「鐘の声 ブログ」はリンクフリーです。ただし、「鐘の声 ブログ」の記事の一部または全部を引用または翻案して、公的に発言または発表される場合は、事前にメール等でお知らせください。[→連絡先]
(補2)ブログ「鐘の声」には、10個ほどのシリーズとシリーズ以外の一般記事があります。シリーズの全体構成やシリーズ別の記事一覧は下記(別サイト)にあります。
  ☆「鐘の声」の全体構成(「鐘の声 ブログ」記事マップ)☆ (GO!)
  ・独創力の創り方シリーズ
  ・心理、教育、社会性の発達シリーズ
  ・社長の条件シリーズ
  ・アルゴリズム戦記シリーズ
  ・情報デザイン研究ノートシリーズ
  ・「情報社会学、予見と戦略」シリーズ
  ・感性的研究生活シリーズ
  ・街に活力をシリーズ
  ・交友の記録シリーズ
  ・オヤジと家族のお料理ライフシリーズ
  ・我が家の愛犬様シリーズ
  ・妻が、車に撥ねられるシリーズ
  ・その他、シリーズ外

« 「50歳からの手習いゴルフ」に「団塊シニア賛歌」を寄稿--情報社会学、予見と戦略(15) | トップページ | 福田首相の「生活者・消費者重視」論と「社会的サービスを担う市民」の現実--情報社会学、予見と戦略(16) »

「日記・コラム・つぶやき」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/73834/17676458

この記事へのトラックバック一覧です: 早く到達しすぎたリッチクライアントシステム「世界初MMLシステム-その3」--アルゴリズム戦記(19):

» http://38165687.at.webry.info/201505/article_4.html [授業用ブログ]
アルゴリズム戦記19話 飯箸先生の授業 [続きを読む]

» アルゴリズム戦記19話の要約 [授業用ブログ]
アルゴリズム戦記19話 飯箸先生の授業 [続きを読む]

« 「50歳からの手習いゴルフ」に「団塊シニア賛歌」を寄稿--情報社会学、予見と戦略(15) | トップページ | 福田首相の「生活者・消費者重視」論と「社会的サービスを担う市民」の現実--情報社会学、予見と戦略(16) »