１９９２年３月２３日号
大規模な業務支援システムをエンドユーザーが独力で開発パソコンのアプリケーションからサーバーのＲＤＢを自在に検索・加工
1991年秋、トヨタ自動車の本社工場で、パソコンLAN(ローカル・エリア・ネットワーク)をべ一スにエンドユーザー'コンピューティングを実現する業務支援システムが全面稼働した。
エンドユーザーである本杜工場工務部の職員が自分達で設計・開発し、保守・運用まで行っている。 名前は「OA」だが、生産管理、原価管理、保全管理、人事・教育など、 工場内で発生するほとんどの主要な日常業務を処理する。 さらに、業務で使うデータをLotus1-2-3などのパソコン用パッケージ・ソフトに渡して容易 に分析・加工できるなど、非定型処理の仕組みにも工夫を凝らしている。 今後のエンドユーザー指向の情報システム像を考える上で、参考になる点の多い先進的なシステムだ。 パソコンのアプリから、LAN経由でサーバーのRD8にアクセス このシステムを構築するため、全社基幹システムの大型汎用機とは別に、 データベース・サーバーとして使う汎用機1台と約90台のパソコンをつないだLANを工場内に導入した。 パソコンは製造拠点各所や工務部のオフィスなどに分散配置している。 ユーザーは、パソコン上のアプリケーション・プログラムからLAN経由でサーバーのRDB(リレーショナル・データベース)にアクセスし、 必要なデータを検索したり、更新することができる。 取り出したデータを同一パソやワープロなどのパッケージ・ソフトに渡して加工することも可能だ。 典型的なクライアント/サーバー型のシステムである。 大部分のアプリケーション・プログラムはBASIC言語で開発した。 パソコンとはいえ、1000ステップ程度のプログラム約400本で構成する大規模なシステムだ。 プログラムは各パソコンの40メガバイトのハードディスクに収納している(表1)。 表1●トヨタ自動卓本社工場OAシステムの概要
本社工場は他9工場とは別にエンドユーザーが開発・運用 トヨタが本杜工場など全国10工場を対象に、工場OA化プロジェクトを発足させたのは88年8月のことである。 当初はシステム部門が全工場のシステムを開発する予定だった。 ところが、パソコンによるプログラム開発の経験があり、ソフト資産のあった本社工場は自分達で設計・開発すると主張。 約半年問の議論の末、ついに独自路線を選んだ。 全社の情報システムを企画し、開発予算を管理するのはCIS(Commu-nicationandInformationSystem)企画部の役割である。 同部部長の改田護取締役(120ぺ一ジのミニインタビュー参照)は、 「これまでも工場のFA(ファクトリ・オートメーション)や研究所のシステムなどはエンドユーザーに開発を任せたことがあったが、 本格的なOAシステムは今回が初めて」と言う。
開発プロジェクトが発足するまでは、特にシステム開発を専門にしていたわけではなく、 それぞれ工務部本来の業務を抱えていた人々だ、 しかしメンバーの大半はBASICによる開発の経験があった。 使いやすいユーザー・インタフェースを持つサーバーRDBの検索ツールや、 RDBにデータを複数のパッケージ・ソフト用のデータに自動変換する機能を自分達で開発するなど、技術も高度だ。 エンドユーザーが常に最新プログラムを利用できるように、パソコンの電源を入れると 、サーバーに登録してある新しいプログラムを自動的に取り込む、という仕組みも開発した(118ぺ一ジや121ぺ一ジを参照)。 本社工場はアプリをパソコン上で稼働全社ホストと交換するデータは共通 図1を見ていただきたい。
本杜工場のシステムはクライアント」サーバー型である。 データベース・サーバーの汎用機ACOS3300とパソコンPC-9801(一部はN5200)がLANによって結ばれている。 大部分のアプリケーションは、クライアントであるPC-9801上にある。 一方、他の9工場はオフコンV7060を部門ホストとし、この上でアプリケーションを動かす、ホストー端末型のシステムだ。 端末にはJ-3100(一部はJ-3300)を使用する。 もちろん両システムには共通点もある。 例えば、部門コンピュータのACOS3300とV7060が、全社事務系ホストであるIBM3090とやり取りするデータの項目や内容は全く同じである。 部門コンピュータは全社ホストから1日1回の割合で、RJE(リモート・ジョブ・エントリ)によってデータを受け取っている。 バッチ処里処理中心では要求が満たせないBAS1C経験者が開発をリード 本社工場工務部があえて独自システムの開発に踏み切った理由はいくつかある(図2)。
これまで利用してきたバッチ処理中心のホスト－端末型システムは、「システム部に依頼してデータが出力されるのを数週間も待つことがあった。 その間に現場の情報に対する二一ズも変わってしまう」(同)という。 これが最も切実な理由だ。 第2の理由は、前述したようにパソコンによるアプリケーション開発の経験と実績があったことだ。 開発を担当した7人のうち、2人は既にBASICで業務プログラムを開発した経験があり、他にも3人がBASICの知識を持っていた。 本杜工場が日本電気のハードを選んだのは、PC-9801で開発したプログラム資産を生かしたい、というのが最大の理由だ。 OA化プロジェクトがスタートした当時、本社工場には既に数10台のPC-9801が導入されており、 エンドユーザーにとっても馴染みのある利用環境の方がよいと考えた。 そのほか、表計算、ワープロ、データベースなどのパソコン用パッケージ・ソフトや、ACOS用のRDBであるRIQSII、 第4世代言語のIDLⅡなど、サーバー側のアプリケーションの開発環境も評価した。 本杜工場にとってACOSのアプリケーション開発は全く未経験だったが、開発メンバーのうちBASICの経験のない2人が、IDLⅡを習得して対応した。 PC-9801上のBASICプログラムがLAN経由でACOSのRIQSIIにアクセスするためのインタフェースのソフト開発は、日本電気が請け負った。 クライアント側のハードとサーバー側のハードのベンダーを共通にしたことで、 このような技術的なサポートを受けやすかったというメリットもあった。 パソコンと汎用機を有機的に連携させるソフト群 以下では、本杜工場OAシステムのメニュー構成や基本的なシステムの利用方法の例を示そう。 サーバーとバソコンに搭載するソフトの構成にも触れる。 まず表2を見ていただきたい。
ユーザーがパソコンの電源を入れると、これらのうちの1つのカテゴリが表示され、←→カーソルによってカテゴリを変更できる。 さらに↑↓カーソルで、利用したい項目を選択する。 メニューは階層的に組み立てられており、各階層では画面に表示された選択枝をファンクション・キー(f・1、f・2など)によって選ぶ。 使い勝手を考慮し、階層を飛び越えてメニューを選択することもできるように設計している。 ユーザーが日常的に利用するのは、BASICで開発した③、④の業務システムである。 これらのアプリケーション・プログラムは、LAN経由でサーバーのRDBにアクセスし、データを処理する。 ①はサーバーに直接関係するメニュー。 特に宮本次長らが独自に開発したQpon-RDBと呼ぶソフトは、RDBを容易に検索できるユーザー・インタフェースを提供し、 パソコン用パッケージ・ソフトヘのデータ変換機能などを持つ高度なツールだ(118ぺ一ジ参照)。 ②、⑤のように、パツケージ・ソフトやツールを数多く用意し、 ユーザーが使い慣れたソフトでデータを分析したり資料を作成できるよう配慮しているのも特徴である。 主なユーザーは製造拠点の管理者 システムを利用するのは、主に工場内の各製造拠点の管理者(現場監督)である。 ユーザーは毎日の生産状況や労働状況に関するデータを入力したり、設傭の故障状況を画面上に出力してチェックする。 メニューを掘り下げていけば、故障原因の履歴を出力するなど、より詳細な分析も可能だ。 データを統合ソフトなどに渡し、ユーザー独自の分析を加えることもできる。 基本的な利用の仕方の例として、各生産ラインで製造する部品の合格数や、 費やした工数(人数や時間)などを入力する画面を写真3に示した。 
メイン・メニューで③合格数/工数入カシステムを選択し、日付やユーザーの所属を入力すると、写真3の画面となる。ユーザーは生産ライン名、人員の数、部品の品番、操業時間などを表中に入力していく。 操業時間の項目にカーソルを持っていくと、操業開始時間と・終了時間などを入力するためのウインドウ(水色)が開く。 この数値を入れてやると自動的に操業時間を計算して表中に書き込む、という工夫をしている。 BASlCアプリ、パッケージ、IDLⅡアプリを切り替えて利用 本社工場OAシステムで使用する基本的なソフトの構成を図3に示した。
第１にBASICで開発したアプリケーション、第2に表計算などのパッケージ・ソフト、第3にIDLⅡで開発したACOS上のアプリケーションである。 IDLⅡアプリケーションはETOS52GというACOSの端末エミュレータを使って利用する。 MS-DOSモードに戻ることなく、ファンクション・キーによってBASICプログラム、パッケージ・ソフト、IDLⅡプログラムを切り替えて使用できる。 BASICプログラムがACOSのRIQSⅡと通信してデータをやり取りする過程では、PC-9801上のPC-RDBサーバー、 ACOS上のRIQSⅡサーバー、それにCOM-XEという3つのソフトが機能する。 PC-RDBサーバーは、RDBの表の操作条件をRDB用検索言語であるSQL文に変換する。 RIQSⅡサーバーはCOM-XEを介してSQL文を受け取り、RIQSⅡがディスク中のデータ を読み出したりディスクに書き込んだりするための言語、DML(データ操作言語)に変換する。 サーバーＲＤＢの検索ツールをBASICで開発
次に、データを多面的に分析していく手法の例を紹介する。 エンドユーザーが自分達で開発したツールの中でも、特に有用なのが前述したQpon-RDBである。 パソコン画面上に簡単な検索条件を入力するだけで、即座にサーバーRDBのデータを引き出して表示する機能や、 検索したデータを各種のパッケージ・ソフト用データに変換できる機能を持っている。 以下で説明しよう。 まず、サーバーRDBの汎用検索ツールである(117ぺ一ジの写真4)。 写真4(a)は検索条件などを入力する画面である。 この例では、ある製造拠点の生産状況に関するRDBの表(名前は“QLINSTOP")を対象に、「年月」から「遅れ」までの11項目を 表示するよう指示している(「取込指定」)。 検索条件は、「年月」が199202 (1992年2月)、「(生産)ライン」が1である。 さらに「日」や「直」を昇順で表示するよう、ソート条件も入力した。 「直」は昼間か夜間かを示す。 これらの条件で検索を実行したのが写真4(b)である。 BASlCプログラムを自動生成条件を変数に代えて汎用化も可能このツールを使ってRDBを検索すると、 検索手順を自動的にBASICプログラムに変換するソフトも開発した。 写真4の条件で検索した時に自動生成したプログラムの一部を117ぺ一ジの図4に示した。
これはSQL文をパソコンからサーバーRDBに渡してやるためのものである。 5000行目以降では、検索条件を示すSQL文をBASICプログラム中に文字列として組み込んでいる。 RDBSUBは、メモリー上に展開されているSQL文を読み出し、RDBに投げてやる。 プログラムに名前を付けて登録しておけば、何度でも同じ条件で検索できる。 このプログラムをさらに汎用的なものにする機能も開発した。 例えば、検索条件の「年月」に入力した199202を文字変数に書き換えて、プログラムの5050行を SQL(5)="年月="+YYMM$ とする。 これを登録して実行すると、年月以外の条件は前と同じで、年月のみをユーザーに尋ねてくるプログラムにすることができる。 パッケージ・ソフトで即座に加工 このツールを使って検索したデータは、簡単にパッケージ・ソフト用のデータに変換して、加工することができる。 いったんMS-DOSに戻って、そのソフトを立ち上げる必要はない。 システムの使い勝手を考える上で、この機能は特に重要なものだ。 サーバーRDBのデータを検索した後、画面下のファンクション・キー群の中から「市販AP」を選ぶと、いくつかのパッケージ・ソフトの名前が表示される。 現在Qpon-RDBを使ってデータを変換できるパッケージ・ソフトは、表計算のLotus1-2-3、グラフ作成のtheGRAPH、 ワープロの新松、データベースのPC-PALスーパーの4種類である(図5)。
このほか、MML(マイクロ・メインフレーム・リンク)機能を持った統合ソフトのファラオNは、直接RDB のデータを操作できる。 またドッドウェルB・M・SのBM一サザンと呼ぶソフトの導入も検討している。 これはQpon-RDBと同様に、RDBのデータをパッケージ・ソフト用データに変換する機能を持っている。 Lotus1-2-3のほか、Qpon-RDBでは扱えない表計算ソフトの桐やMultiplanのデータに変換できる。 このほかデータ変換ツールのQponDiskを使うと、DiskBASIC、MS-DOS、PTOS(N5200)、IBM EBCDICのデータを、 他のいずれのデータに変換することも可能だ。 多面的な分析が可能な画面構成表示を工夫し、基本的なグラフも用意 実際の業務に沿って、データを多面的に分析する例を紹介する。 メイン・メニュー③の保全システムによる設備故障の分析である(119ぺ一ジ写真5)。
修理時間、機械の停止時間、修理工数もわかる。 各設備の故障履歴も同一画面上に表示できる。 写真の例ではNO.3の設備(緑色の文字に変わっている)に注目して、過去1年の月別の故障履歴を表示している(白色の部分)。 ここで、画面右下に示した「グラフ」をファンクション・キーで選ぶと、故障の件数、修理の時間、工数や機械の 停止時間の月別履歴をグラフ化して表示する(写真5(b))。 パッケージ・ソフトを利用しなくても、このような簡単なグラフ化機能はメニューの各所に用意されている。 写真5(c)はNO.3の設備の故障内容の履歴を示している(青色の部分)。 この中で、修理時間や修理工数が際立っている12月10日の故障(緑色の文字に変わっている)に注目し、さらに 詳しい故障内容を表示した(オレンジ色の部分)。 このように、ユーザーの思考の流れに沿って多面的に分析を進めていけるような画面構成を考慮している。 エンドユーザー自身がシステムを管理するだめの工夫 本社工場OAシステムには、エンドユーザー自身が管理し保守するシステムゆえの工夫が施されている。 その仕組みを紹介しよう。 これまでは、新しいプログラムを開発するとフロッピ・ディスクに入れて、担当者がパソコンを巡回しながらインストーノレしていた。 しかしパソコンの数は現在約90台で、今後も増えていくことを考えると、その負荷は大きい。 そこで、パソコンがサーバーから新しいプログラムを自動的にダウンロードする方法を採用した(図6)。
普通は、サーバーが定期的に信号を発して各パソコンの状態を調べ、プログラムを送信するという方法をとる。 しかし、パソコンの電源が切られていたり、ユーザーがアプリケーションを実行していたりするとプログラムを送信できず、 LAN上の通信のオーバー・ヘッドも問題になる。 そこでこれとは逆に、ユーザーがパソコンの電源を入れると、サーバーに信号を送って新しいプログラムをダウンロードするという方式を採用した。 こうすれば、ユーザーは常に最新のプログラムを利用することができる。 まさにエンドユーザーの発想だからこそ開発できた管理ツールといえよう。 
各パソコンは、新しいプログラムがサーバー側に登録された時期と、自分のシステムのプログラム更新時期とを
比較し、効率的に未登録のプログラムのみをダウンロードするように工夫している(113ぺ一ジの写真1を参照)。アクセス権の管理はサーバー側でRDBの表定義でユーザーを指定最後にセキュリティの問題に触れておこう。 本杜工場OAシステムでは、パソコンからサーバーRDBのデータを検索できるだけでなく、データを書き換えたり、追加することも許している。 「エンドユーザー・コンピューテイングと言うからには、ユーザーにいじられて困るデータはない、というのが基本的な考え方」(宮本次長)だ。 しかしどうしてもデータの書き込みを制限する必要がある場合は、サーバーRDBの表を定義する時にアクセス可能なユーザー・コードを指定することで対処している。 (吉田琢也) -----ミニインタビュー/改田取締役ＣＩＳ企画部長 問 トヨタの情報システムに対する取り組み方を説明してほしい。 答 以前のシステム部門は、エンドユーザーの要望を聞いてそれに答えるだけの受け身の存在だった。 それではいけないという反省から、全社の中での情報システムの位置づけを明確にし、システム化の優先順位や、予算、人員などを決定するCIS企画部を設立した。 基本的には情報システムの開発はCIS企画部の計画に従って行う。 しかし、今回の本社工場のようにエンドユーザーが自分達でシステムを開発したいという意向にはできる限り答えていくつもりだ。 ユーザー自身がやる気になってくれないシステムはうまく機能しないからだ。 問 エンドユーザー自身がシステムを開発するメリットは何か。 答 私も元はユーザー部門に在籍していた。 当時の経験から言えることだがシステム部門から情報システムの導入に伴って業務改善を指示されると、どうも高圧的な感じを受けて素直に聞けないことが多い。 ところがユーザーか自分達でシステムを開発すると、自発的に仕事の仕組みを整理してコンピュータを上手に使いこなそう、という意識が生まれる。 ここが一番違う点だ。 問 これからの情報システムの課題は何か。 答 全社ホスト、部門コンピュータ、パソコンのそれぞれにどのようなデータを載せたらよいか、というデータの切り分けの問題がある。 例えば全杜ホストは必ずしも全工場の人事や経理に関するデータを持つ必要はないという考え方もある。 データベースの整備はCIS企画部にとって大きな課題だ。 教育についての課題も多い。 システム部門では以前から大型機の教育を実施しているが、パソコンや、中型機とパソコンとのインタフェースに関する教育が遅れており、今年から始める計画だ。 またエンドユーザーの中にシステム化を推進するための核となる人物を育てる教育も必要。 情報システム部の人員も限られており、ユーザーの要求に答えきれなくなってきたからだ。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
