カテゴリー

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

« 「テキスト類似度・飯箸法」がアピール、第16回次世代大学教育研究会「知の発掘」(東京)--感性的研究生活(25) | トップページ | 色と形とテイストと、だれが正しい?、何が正しい?--情報デザイン研究ノート(14) »

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

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

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

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

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

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

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

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

(1)販社にも集計分析結果を返す。
販社にも集計と分析結果を透明性を担保して間髪入れずに返してあげれば、もっと頻繁にデータを本社に送信することをいとわないに違いない。
(2)分析軸は、商品のルート別、商品分類別、時系列の3軸である。
帳票法に従って集められた情報に基づけば、これらの3軸の組み合わせを対象範囲を小さくまたは大きくとりながら整理しているのである。それぞれの軸の性質と対象範囲をもう少し詳しく分析すべきである。
(3)メインフレームとパソコンの結合が必要である。
大容量データの大量高速処理に向いたメインフレームとカラー帳票やカラーグラフが容易に表示できるバソコンを結合することが利用率の飛躍的向上につながると確信した。

この観点を引っさげて、マックスファクター電算室の担当者Aさん、室長のBさん、他のスタッフ数名と、私、私の会社の主だったスタッフ数名は、伊豆高原で合宿した。朝から夜まで疲労と睡魔と闘う討論であった。周囲の散策をする余裕もなく緊張のうちに終わった合宿は、大きな成果を挙げた。
この会議には、マックスファクターで勘定系のシステムを担当しているシステムハウスも参加した。彼らはCOBOLの達人たちである。

商品のルート別、商品分類別、時系列の3軸だから3次元空間が一つかというと、そう単純ではない。
商品のルート別の軸には、「本社-販社-営業所-小売店」と「全国-都道府県-市区町村」という2種類がある。
商品分類には、「大分類(ブランド)-中分類-小分類」と「ライン(ユーザの嗜好傾向)」がある。
時系列には、「フィジカル年(カレンダ年)」と「年度」の区別があり、それぞれに「年-月-日」の系列がある。
これらは、主としてディレクトリ構造を形成するが、商品の「ライン(ユーザの嗜好傾向)」だけはディレクトリにはなじまない構造である。商品の「ライン(ユーザの嗜好傾向)」だけは、分析軸からははずした。
すなわち、軸の構成は以下のとおりにした。
商品のルート別の軸: 「本社-販社-営業所-小売店」と「全国-都道府県-市区町村」
商品分類: 「大分類(ブランド)-中分類-小分類」
時系列: 「フィジカル年(カレンダ年)の年-月-日」と「年度の年-月-日」
これらの軸を入れ替えつつ、構成する4種類の3次元データの空間が想定されることになった。
さて、3次元空間をいかに表示するのかというと、画面は2次元である。表形式もグラフも2次元にしかならない。3次元表示をしても見にくいだけである。
一つの3次元空間は3つの平面であらわすことができる。したがって、用意するのは12個のテーブルデータである。

さてさて、ユーザインターフェイスはいかにあるべきかといえば、ターンアラウンドタイム5秒以内と決めることにした。先刻のA氏は、わけもなく「1秒以内」を主張したが、N5200ではテキストだけの表でさえ1画面分を表示するのに2秒程度かかるという時代なので、データの要求、ホストマシンでのデータ取得、データの端末への転送、表やグラフの表示のすべてを行うには、普通にやれば20分~30分はかかるという状況だった。

当時のマックスファクターのシステムはACOS2(NEC)とN5200である。処理のボトルネックは「集計データの生成」と「必要データの検索」と「通信速度」だった。
データベースの導入を提案したが、電算室はそれを渋った。NECはRIQSⅡというリレーショナル型のDBを勧めていたのだがかなり高価だった。電算室は他のさまざまな(旧式で安価な)データベースの導入の検討を依頼してきたが、データ量を見てもまるで無理ということになった。
ついに、電算室もRIQSⅡの導入に賛同した。このとき、気づいてみるとNECの営業担当者と支援SEたちは全員我々の味方になっていたのである。予想外のことだったが、とてもうれしいことだった。
「集計データの生成」は、N5200側から要求される都度生成するとすれば、場合によって1時間以上もかかることになる。ユーザを待たせるにもほどがあるというものである。これには、私の発案で前夜全国から転送される基礎データを夜半から明け方にかけてのバッチ処理で集計しておくという方法を採用することにした。しかし、「年別のデータ×小売店別のデータ」をデータベース全体から選択的に収集するととてつもなく遅いことも十分推測できた。同社に入り込んでいた別のソフトハウスは、都度選択的に収集するという方法を主張したので、彼らに実測してもらうと、20分から40分程度かかることがわかった。データがあっても、仮想テーブルで選択的に都度収集する(ランダムアクセス)という方法は遅いのである。動作を速くするには、シーケンシャルアクセス(連続番地の一気読み)しかないのである。そのためには、仕掛けが必要である。必要な軸の組み合わせと集計レベルに合わせて、すべての組み合わせを、シーケンシャルアクセス対応に(順形式で)生成しておく必要があるのである。販社からのデータ要求があったときには新しいデータセットを構成しなおすのではなく、すでに出来上がっているデータセットの一部を転送するだけというようにしておくということであった。
さて、あらかじめ用意するこの組み合わせを作成するに当たって、困ったことがあった。たとえば、本社-販社-営業所などの軸は固定のように見えて固定ではないのである。営業所の統廃合や新設は日常茶飯事である。小売店も新規取引開始も日常的に多いが、閉店や取引解消も同じくらい多い。固定のバッチプログラムでは、始終プログラムの改修に追われることになる。都道府県はめったに変わらないが、あまり知られていない事実であるが、市区町村は始終変わるのである。商品にいたっては、大幅変更が年に2回、小変更は日々発生している。
私は、考えた。ここは、三井造船で体験した「フレーム理論」の応用場面であると心を燃やした。各分析軸(5種類)とその他の管理データ7種(だったと思う)のあわせて12種類の管理データを用意し、これらのデータをリレーショナルデータベースのテーブルに置き、LAN内のオンラインでいつでも手軽に訂正できるようにしてやることにしたのである。基礎データから、各種の集計データを作成し、順編成データファイルをRIQSⅡの中に生成しソートをするキーとして、その軸のデータを参照するバッチプログラムを作成しておくのである。こうしておけば、軸のデータ(たとえば小売店が入れ替わっても)が変化してもそのバッチプログラムは変える必要がない。
これらの管理データは、クライアントの側でも表側表示やグラフの軸データに必要である。どちらにも使用できるようにしておくのである。
さて、もう一つのネックはデータの転送である。A氏は、N5200から要求があれば、そのデータのすべてをN5200に転送することを主張した。私は反対だった。私の考えは、要求されたデータを必要な一画面分を転送するにとどめるという考えだった。専用回線ではあったが、当時のデータ転送はきわめて遅かった。1画面分の転送でも、回線状況によっては30秒以上かかるという時代だったのである。回線状況が良いときには2-3秒である。私は、1画面分のデータをまず転送し、端末の画面に端末が表示し終えると続いて次の画面1ページ分だけは送っておくという仕掛けにしたのである。前ページを要求された場合は前ページを表示した後、前々ページも(あれば)送っておくというものである。ユーザは最初の1画面では少しばかり時間がかかるが、次からは比較的スピーディに画面表示と印刷ができるということになるのである。
ここで、重要な事柄をあっさりと書き流したのだが、実は当時にしてはとんでもなく、ぶっ飛ぶような発想がここには潜んでいた。画面に表示される表やグラフなどはホスト側で描かないのである。当時は、端末に表示させる表やグラフもホストで描かせてから、そのデータを端末に送るのが定石であり、それ以外にはできなかったのである。なにしろ、当時までは端末には描画機能などはなかったのだから。しかし、幸い、N5200はパソコンであった。描画機能も罫線機能も備えていた。ホストに描画させたり計千色歩させていたら、端末(N5200)がデータを要求してから画面に表示されるまでいくら時間があっても足りないのである。ホストコンピュータのCPU能力を考えても全国の営業所からの要求にこたえることは到底かなわないというものである。人間の試行錯誤や画面への配置処理という端末ごとに違った処理が発生するものは端末に任せようというのが私の発想の素であった。
実は、この「端末には端末の得意な処理を、ホストにはホストの得意な処理をさせる」という発想こそがMicro Mainframe Link(MML)というものの考え方そのものであったのである。
とりわけグラフィック画面の生成は端末のほうがはるかに速いこと、もしもホストでグラフィック画面を生成してから端末に送るのであれば、元になるデータの数千倍ものデータ量を転送しなければならないのである。それは、ありえない選択だったのである。

マックスファクター株式会社様向けに開発したマイクロメインフレーム(MML)タイプの情報システムには、以下のようなものがある。全てを取り上げる余裕はないので、この記事では主にその最初のシステムを取り上げている。

昭和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

(以下、つづく)

△次の記事: アルゴリズム戦記(19)
http://shyosei.cocolog-nifty.com/shyoseilog/2008/01/mml319_7465.html
▽前の記事: アルゴリズム戦記(17)
http://shyosei.cocolog-nifty.com/shyoseilog/2007/07/mml17_00c0.html

琵琶


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

« 「テキスト類似度・飯箸法」がアピール、第16回次世代大学教育研究会「知の発掘」(東京)--感性的研究生活(25) | トップページ | 色と形とテイストと、だれが正しい?、何が正しい?--情報デザイン研究ノート(14) »

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

コメント

コメントを書く

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

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

トラックバック

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

この記事へのトラックバック一覧です: ユーザを待たせないアルゴリズムへ「世界初MMLシステム-その2」--アルゴリズム戦記(18):

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

« 「テキスト類似度・飯箸法」がアピール、第16回次世代大学教育研究会「知の発掘」(東京)--感性的研究生活(25) | トップページ | 色と形とテイストと、だれが正しい?、何が正しい?--情報デザイン研究ノート(14) »

2017年4月
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            
無料ブログはココログ