日経コンピュータ
1992年3月23日号

大規模な業務支援システムをエンドユーザーが独力で開発

パソコンのアプリケーションからサーバーのRDBを自在に検索・加工

  • トヨタ自動車の本社工場は1991年秋、パソコンLAN(ローカル・エリア・ネットワーク)をべ一スにした業務支援システムを全面稼働した。 エンドユーザー自身が40万ステップのBASICプログラムを開発した。

  • パソコン上のアプリケーション・プログラムから、LAN経由でサーバーのRDB(リレーショナル・データベース)にアクセスできる。これを同一パソコン上で市販の統合ソフトなどに渡して自由に加工することも可能だ。

  • 当初はシステム部門が本社工場を含む全国10工場のシステム化を計画していたが、本社工場は「必要な情報を、必要なときに引き出して加工できる」ことを重視。あえて単独開発に踏み切った。


1991年秋、トヨタ自動車の本社工場で、パソコンLAN(ローカル・エリア・ネットワーク)をべ一スにエンドユーザー'コンピューティングを実現する業務支援システムが全面稼働した。
写真1●本社工場OAシステムの初期画面。
パソコンの電源を入れた 後、プログラム3本を自動的にACOS3300からダウン・ロードして いる
「本社工場OA(オフィス・オートメーション)システム」である。
エンドユーザーである本杜工場工務部の職員が自分達で設計・開発し、保守・運用まで行っている。
名前は「OA」だが、生産管理、原価管理、保全管理、人事・教育など、 工場内で発生するほとんどの主要な日常業務を処理する。
さらに、業務で使うデータをLotus1-2-3などのパソコン用パッケージ・ソフトに渡して容易 に分析・加工できるなど、非定型処理の仕組みにも工夫を凝らしている。
今後のエンドユーザー指向の情報システム像を考える上で、参考になる点の多い先進的なシステムだ。

パソコンのアプリから、LAN経由でサーバーのRD8にアクセス

このシステムを構築するため、全社基幹システムの大型汎用機とは別に、 データベース・サーバーとして使う汎用機1台と約90台のパソコンをつないだLANを工場内に導入した。
パソコンは製造拠点各所や工務部のオフィスなどに分散配置している。
ユーザーは、パソコン上のアプリケーション・プログラムからLAN経由でサーバーのRDB(リレーショナル・データベース)にアクセスし、 必要なデータを検索したり、更新することができる。
取り出したデータを同一パソやワープロなどのパッケージ・ソフトに渡して加工することも可能だ。
典型的なクライアント/サーバー型のシステムである。
大部分のアプリケーション・プログラムはBASIC言語で開発した。
パソコンとはいえ、1000ステップ程度のプログラム約400本で構成する大規模なシステムだ。
プログラムは各パソコンの40メガバイトのハードディスクに収納している(表1)。

表1●トヨタ自動卓本社工場OAシステムの概要
システムの狙い エンドユーザーが必要に応じて自由にデータベースを検索し、随時評価したり加工できる体制を作る
対象業務 作業能率管理、原価管理、保金管理、生産管理、 人事、一般事務など
システムの形態 クライアント/サーバー型
ハードウエア サーバー:ACOS3300 /クライアント:PC・9801、N5200
LANト B4680U(イーサネット)
データベースソフト RlQSU(サーバー用・リレーショナル型)
通信ソフト COM・XE
開発言語 サーバー側:IDLU(第4世代言語謂) クライアント側:BASlC(他にLotus1・2・3などのパ ッケージ・ソフトを利用)
BASICプログラム本数 約400(1本当たり約1000ステップ)
開発期間 89年8月〜91年8月


本社工場は他9工場とは別にエンドユーザーが開発・運用

トヨタが本杜工場など全国10工場を対象に、工場OA化プロジェクトを発足させたのは88年8月のことである。
当初はシステム部門が全工場のシステムを開発する予定だった。
ところが、パソコンによるプログラム開発の経験があり、ソフト資産のあった本社工場は自分達で設計・開発すると主張。
約半年問の議論の末、ついに独自路線を選んだ。
全社の情報システムを企画し、開発予算を管理するのはCIS(Commu-nicationandInformationSystem)企画部の役割である。
同部部長の改田護取締役(120ぺ一ジのミニインタビュー参照)は、 「これまでも工場のFA(ファクトリ・オートメーション)や研究所のシステムなどはエンドユーザーに開発を任せたことがあったが、 本格的なOAシステムは今回が初めて」と言う。
写真2 ●本社工場OAシステムの開発チーム・リーダー、宮本幸雄本 社工場工務部次長。
「エンドユーザーが自由に情報を引き出し、加工 できる環境を実現するにはバソコンLANしかないと思った」
開発を担当したのは、エンドユーザー部門の宮本幸雄本社工場工務部次長や浅井釣同部課長など7人。
開発プロジェクトが発足するまでは、特にシステム開発を専門にしていたわけではなく、 それぞれ工務部本来の業務を抱えていた人々だ、 しかしメンバーの大半はBASICによる開発の経験があった。
使いやすいユーザー・インタフェースを持つサーバーRDBの検索ツールや、 RDBにデータを複数のパッケージ・ソフト用のデータに自動変換する機能を自分達で開発するなど、技術も高度だ。
エンドユーザーが常に最新プログラムを利用できるように、パソコンの電源を入れると 、サーバーに登録してある新しいプログラムを自動的に取り込む、という仕組みも開発した(118ぺ一ジや121ぺ一ジを参照)。

本社工場はアプリをパソコン上で稼働全社ホストと交換するデータは共通

図1を見ていただきたい。

図1●トヨタ自動車の工場OAシステムの構成。
本社工場はクライアント/サーバー型システムを、他の9工場はホストー端末型システムを 採用し、同一目的のシステムを2系統の体制で開発している。
騒は主なアプリケーション・プロクラムの所在を示す


本社工場は日本電気の、他の9工場は東芝のハードウエアを採用した。
本杜工場のシステムはクライアント」サーバー型である。
データベース・サーバーの汎用機ACOS3300とパソコンPC-9801(一部はN5200)がLANによって結ばれている。
大部分のアプリケーションは、クライアントであるPC-9801上にある。
一方、他の9工場はオフコンV7060を部門ホストとし、この上でアプリケーションを動かす、ホストー端末型のシステムだ。
端末にはJ-3100(一部はJ-3300)を使用する。
もちろん両システムには共通点もある。
例えば、部門コンピュータのACOS3300とV7060が、全社事務系ホストであるIBM3090とやり取りするデータの項目や内容は全く同じである。
部門コンピュータは全社ホストから1日1回の割合で、RJE(リモート・ジョブ・エントリ)によってデータを受け取っている。

バッチ処里処理中心では要求が満たせないBAS1C経験者が開発をリード

本社工場工務部があえて独自システムの開発に踏み切った理由はいくつかある(図2)。
図2●本社工場工務部が独自のシステム開発に踏み切った理由
  • 従来のようなバッチ処理中心のホスト−端末型システムでは、必要な情報を随時引き出し、自由に加工できるシステムを実現するのが難しい

  • 本社工場工務部の開発メンバーは、従来からBASlC言語でプログラムを開発したり、パッケージ・ソフトを利用した経験があった

  • 日本電気PC-9801のハードやソフトの資産を生かしたい第4世代言語など、サーバー側の開発環境も評価した
第1は「必要なデータを即座に取り寄せ、その場で加工して評価したい」(宮本次長)という要求が強かったこと。
これまで利用してきたバッチ処理中心のホスト−端末型システムは、「システム部に依頼してデータが出力されるのを数週間も待つことがあった。
その間に現場の情報に対する二一ズも変わってしまう」(同)という。
これが最も切実な理由だ。
第2の理由は、前述したようにパソコンによるアプリケーション開発の経験と実績があったことだ。
開発を担当した7人のうち、2人は既にBASICで業務プログラムを開発した経験があり、他にも3人がBASICの知識を持っていた。
本杜工場が日本電気のハードを選んだのは、PC-9801で開発したプログラム資産を生かしたい、というのが最大の理由だ。
OA化プロジェクトがスタートした当時、本社工場には既に数10台のPC-9801が導入されており、 エンドユーザーにとっても馴染みのある利用環境の方がよいと考えた。
そのほか、表計算、ワープロ、データベースなどのパソコン用パッケージ・ソフトや、ACOS用のRDBであるRIQSII、 第4世代言語のIDLUなど、サーバー側のアプリケーションの開発環境も評価した。
本杜工場にとってACOSのアプリケーション開発は全く未経験だったが、開発メンバーのうちBASICの経験のない2人が、IDLUを習得して対応した。
PC-9801上のBASICプログラムがLAN経由でACOSのRIQSIIにアクセスするためのインタフェースのソフト開発は、日本電気が請け負った。
クライアント側のハードとサーバー側のハードのベンダーを共通にしたことで、 このような技術的なサポートを受けやすかったというメリットもあった。

パソコンと汎用機を有機的に連携させるソフト群

以下では、本杜工場OAシステムのメニュー構成や基本的なシステムの利用方法の例を示そう。
サーバーとバソコンに搭載するソフトの構成にも触れる。
まず表2を見ていただきたい。

表2●トヨタ自動車の本社工場OAシステムのメイン・メニュー。
←→カーソルで@nDを選択し、↑↓カーソルで項目を選択する。
クライアン トのバソコンごとに使用頻度の高い項目を登録でき、システムを立ち上げると自動的にその項目を表示する
@ACOSA簡易ソフトB工場システムC工場システム2D支援ツール
プログラム開発システム
図形電送システム
文書電送システム
Qpon-RDB
TQF(ACOS-RDB)
ホスト(ACOS)システム
統合ソフトファラオーN

データベースPC-PAL
グラフPC-GRAPH
ワープロ新松
統合ソフトLotusl-2-3
製図ソフトCANDY4
グラフTheGRAPH
ワープロ一太郎
作絵ソフト花子
マスター更新システム
油脂/補助材システム
保全(ACOS)システム
合格数/工数システム
原価/能率資料システム
素材/購入品システム
標準作業表システム
ホスト(ACOS)システム
品質管理システム
生産管理システム
安全衛生システム
人事教育システム
予算管理システム
特定調達システム
保全履歴システム
鍛造・型システム
MlFES起動
エコロジー起動
MS・DOS起動
QponDiskU
Qpon外字
QPonCAD
QPonバ一コード
QPonゲーム
Qponはシステムを開発したエンドユーザー部門の代表者の名前にちなんだもの サーバーACCS3300に関係するメニュー @はデータベース
本社工場OAシステムのメイン・メニューは5つのカテゴリに分類されている。
ユーザーがパソコンの電源を入れると、これらのうちの1つのカテゴリが表示され、←→カーソルによってカテゴリを変更できる。
さらに↑↓カーソルで、利用したい項目を選択する。
メニューは階層的に組み立てられており、各階層では画面に表示された選択枝をファンクション・キー(f・1、f・2など)によって選ぶ。
使い勝手を考慮し、階層を飛び越えてメニューを選択することもできるように設計している。
ユーザーが日常的に利用するのは、BASICで開発したB、Cの業務システムである。
これらのアプリケーション・プログラムは、LAN経由でサーバーのRDBにアクセスし、データを処理する。
@はサーバーに直接関係するメニュー。
特に宮本次長らが独自に開発したQpon-RDBと呼ぶソフトは、RDBを容易に検索できるユーザー・インタフェースを提供し、 パソコン用パッケージ・ソフトヘのデータ変換機能などを持つ高度なツールだ(118ぺ一ジ参照)。
A、Dのように、パツケージ・ソフトやツールを数多く用意し、 ユーザーが使い慣れたソフトでデータを分析したり資料を作成できるよう配慮しているのも特徴である。


主なユーザーは製造拠点の管理者

システムを利用するのは、主に工場内の各製造拠点の管理者(現場監督)である。
ユーザーは毎日の生産状況や労働状況に関するデータを入力したり、設傭の故障状況を画面上に出力してチェックする。
メニューを掘り下げていけば、故障原因の履歴を出力するなど、より詳細な分析も可能だ。
データを統合ソフトなどに渡し、ユーザー独自の分析を加えることもできる。
基本的な利用の仕方の例として、各生産ラインで製造する部品の合格数や、 費やした工数(人数や時間)などを入力する画面を写真3に示した。
メイン・メニューでB合格数/工数入カシステムを選択し、日付やユーザーの所属を入力すると、写真3の画面となる。
ユーザーは生産ライン名、人員の数、部品の品番、操業時間などを表中に入力していく。
操業時間の項目にカーソルを持っていくと、操業開始時間と・終了時間などを入力するためのウインドウ(水色)が開く。
この数値を入れてやると自動的に操業時間を計算して表中に書き込む、という工夫をしている。


BASlCアプリ、パッケージ、IDLUアプリを切り替えて利用

本社工場OAシステムで使用する基本的なソフトの構成を図3に示した。


図3●本社工場OAシステムの基本ソフトウエアの構成。
PC-RDBサーバーはRDBの表の操 作条件をSQL文に、RlQSIIサーバーはSQL文をDML(データ操作言語)に変換する。
COM- XEは通信ソフト


ユーザーが利用するアプリケーションは3種類に大別できる。
第1にBASICで開発したアプリケーション、第2に表計算などのパッケージ・ソフト、第3にIDLUで開発したACOS上のアプリケーションである。
IDLUアプリケーションはETOS52GというACOSの端末エミュレータを使って利用する。
MS-DOSモードに戻ることなく、ファンクション・キーによってBASICプログラム、パッケージ・ソフト、IDLUプログラムを切り替えて使用できる。
BASICプログラムがACOSのRIQSUと通信してデータをやり取りする過程では、PC-9801上のPC-RDBサーバー、 ACOS上のRIQSUサーバー、それにCOM-XEという3つのソフトが機能する。
PC-RDBサーバーは、RDBの表の操作条件をRDB用検索言語であるSQL文に変換する。
RIQSUサーバーはCOM-XEを介してSQL文を受け取り、RIQSUがディスク中のデータ を読み出したりディスクに書き込んだりするための言語、DML(データ操作言語)に変換する。

サーバーRDBの検索ツールをBASICで開発

写真4●独自開発したソフトQponRDBでパソコンからサーバーのRDB、RIQSUを検索する(a)。
検索条件(年月、生産ラインなど)やソート条件(日付の昇降順など)を入力するだけで、RlQSUのデータをパソコン上に読み込める(b)
以下では、データの検索や加工の柔軟性を高めるツールについて述べよう。
次に、データを多面的に分析していく手法の例を紹介する。
エンドユーザーが自分達で開発したツールの中でも、特に有用なのが前述したQpon-RDBである。
パソコン画面上に簡単な検索条件を入力するだけで、即座にサーバーRDBのデータを引き出して表示する機能や、 検索したデータを各種のパッケージ・ソフト用データに変換できる機能を持っている。
以下で説明しよう。
まず、サーバーRDBの汎用検索ツールである(117ぺ一ジの写真4)。
写真4(a)は検索条件などを入力する画面である。
この例では、ある製造拠点の生産状況に関するRDBの表(名前は“QLINSTOP")を対象に、「年月」から「遅れ」までの11項目を 表示するよう指示している(「取込指定」)。
検索条件は、「年月」が199202
(1992年2月)、「(生産)ライン」が1である。
さらに「日」や「直」を昇順で表示するよう、ソート条件も入力した。
「直」は昼間か夜間かを示す。
これらの条件で検索を実行したのが写真4(b)である。
BASlCプログラムを自動生成条件を変数に代えて汎用化も可能このツールを使ってRDBを検索すると、 検索手順を自動的にBASICプログラムに変換するソフトも開発した。
写真4の条件で検索した時に自動生成したプログラムの一部を117ぺ一ジの図4に示した。

図4●写真4(a)の条件でRDBを検索した時に自動生成したBASlCのプログラム。
プログラム 中にSQL文を文字例として組み込むのが特徴(下の例では5000行以降)。
1360行で、メモリー上 に展開したSQL文を探し、RDBに渡してやるためのアセンブラ・サブルーチンを呼んでいる
..........................................................
..........................................................

1350	*C7
1360	CALL RDBSUB(A$(O),KENSUU$,SQL$(0),RDBSTS$,BFCODE$,KlNOU%)
..........................................................
..........................................................
		、
4990	*ACOS
5000	SOL$(O)="DECLARE CUR1 CURSOR"
5010	SQL$(1)="F0RS ELECT 年月,日,ライン,直,係,計画,実績,十,残業,停止,"
5020	SQL$(2)="遅れ"
5030	SQL$(3)="FROM QLINSTOP"
5040	SQL$(4)="WHERE"
5050	SQL$(5)="年月=199202"
5060	SQL$(6)="AND ライン=N'1'"
5070	SQL$(7)="ORDER BY 日 ASC, 直 ASC"
5080	SQL$(8)=""
5090	GOSUB *DEC
5100	SQL$(0)="0PEN CUR1":SQL$(1)= :GOSUB *OPEN
5110	BYT=62
5120	QLOF=11:QDlR$="QLlNSTOP"
5130	SQL$(0)="FETCH CUR1 lNTO:AK、:AJ,:Al,:AH,:AG,:AF,:AE,:AD,:AC,:AB.:AA"
5140	SQL$(1)=""
..........................................................
..........................................................


プログラムの1360行で呼んでいるサブルーチンRDBSUBはアセンブラで書かれている。
これは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)。


図5 ●ACOS3300のRDB、RlQSUIからパソコン用簡易ソフトなどへのデータ変換。
独自開発 したソフトQPon-RDBやQPonDiskで実行する。
このほか、市販のBM一サザンも導入する 予定



このほか、MML(マイクロ・メインフレーム・リンク)機能を持った統合ソフトのファラオNは、直接RDB のデータを操作できる。
またドッドウェルB・M・SのBM一サザンと呼ぶソフトの導入も検討している。
これはQpon-RDBと同様に、RDBのデータをパッケージ・ソフト用データに変換する機能を持っている。
Lotus1-2-3のほか、Qpon-RDBでは扱えない表計算ソフトの桐やMultiplanのデータに変換できる。
このほかデータ変換ツールのQponDiskを使うと、DiskBASIC、MS-DOS、PTOS(N5200)、IBM EBCDICのデータを、 他のいずれのデータに変換することも可能だ。

多面的な分析が可能な画面構成表示を工夫し、基本的なグラフも用意

実際の業務に沿って、データを多面的に分析する例を紹介する。
メイン・メニューBの保全システムによる設備故障の分析である(119ぺ一ジ写真5)。
写真5●保全システムによる設備榔章の分析の例。
91年12月度に故障の多かった設備(機番)の一覧から、ある設備(SP-3719)を選んで故障履歴を表示した(a)。
これをグラフ化したのが(b)。
故障の内容も詳細に分析できる(c)
写真5(a)は、9!年12月に故障の多かった設備を、故障件数の順に列記した一覧表(青色の部分)である。
修理時間、機械の停止時間、修理工数もわかる。
各設備の故障履歴も同一画面上に表示できる。
写真の例ではNO.3の設備(緑色の文字に変わっている)に注目して、過去1年の月別の故障履歴を表示している(白色の部分)。
ここで、画面右下に示した「グラフ」をファンクション・キーで選ぶと、故障の件数、修理の時間、工数や機械の 停止時間の月別履歴をグラフ化して表示する(写真5(b))。
パッケージ・ソフトを利用しなくても、このような簡単なグラフ化機能はメニューの各所に用意されている。
写真5(c)はNO.3の設備の故障内容の履歴を示している(青色の部分)。
この中で、修理時間や修理工数が際立っている12月10日の故障(緑色の文字に変わっている)に注目し、さらに 詳しい故障内容を表示した(オレンジ色の部分)。
このように、ユーザーの思考の流れに沿って多面的に分析を進めていけるような画面構成を考慮している。

エンドユーザー自身がシステムを管理するだめの工夫

本社工場OAシステムには、エンドユーザー自身が管理し保守するシステムゆえの工夫が施されている。
その仕組みを紹介しよう。
これまでは、新しいプログラムを開発するとフロッピ・ディスクに入れて、担当者がパソコンを巡回しながらインストーノレしていた。
しかしパソコンの数は現在約90台で、今後も増えていくことを考えると、その負荷は大きい。
そこで、パソコンがサーバーから新しいプログラムを自動的にダウンロードする方法を採用した(図6)。


図8●新たに開発・修正したプログラムをパソコンにダウンロードする際、パソコン側が取りに行く方式を採用した(a)。
必要最小限のプログラムのみをダウンロードする工夫もしている(b)
本社工場が採用した方法

パソコンの電源を入れると必要なプログラムをサーバーに取りに行く
一般的な方法

ホストからプログラムを一方的に配信すると、パソコンの電源が切られていたり、他のプログラムを実行中の場合、失敗する。
(b)ダウンロードを効率化する工夫
(パソコンにダウンロードするプログラムの管理データベース
パソコンNOプログラム更新日時
001[A]91.09.01 10:00
002[A]91.10.05 18:30


サーバーに登録されたプログラムの管理データベース
プログラム名プログラム登録日時
PDS[B]91.10.01 09:00
[C]A:\ MENU.BAS91.09.15 09:15
A:\ MENU.BAS91.08.30 14:00
[C]A:\ GENKA.BAS91.10.01 08:30
@パソコンの電源を入れると、パソコンのプログラム更新日時Mとサーバーの プログラム登録目時Gを比較する
Aパソコン001は91年9月1日10時一91年10月1日9時の問に登録されたプログラム [c]のみをダウンロードする。
パソコンO02はダウンロードしない


新しいプログラムはパソコン側が取りに行く新規に開発したプログラムや既存のプログラムに修正を加えたものは、まずサーバーに登録される。
普通は、サーバーが定期的に信号を発して各パソコンの状態を調べ、プログラムを送信するという方法をとる。
しかし、パソコンの電源が切られていたり、ユーザーがアプリケーションを実行していたりするとプログラムを送信できず、 LAN上の通信のオーバー・ヘッドも問題になる。
そこでこれとは逆に、ユーザーがパソコンの電源を入れると、サーバーに信号を送って新しいプログラムをダウンロードするという方式を採用した。
こうすれば、ユーザーは常に最新のプログラムを利用することができる。
まさにエンドユーザーの発想だからこそ開発できた管理ツールといえよう。
各パソコンは、新しいプログラムがサーバー側に登録された時期と、自分のシステムのプログラム更新時期とを 比較し、効率的に未登録のプログラムのみをダウンロードするように工夫している(113ぺ一ジの写真1を参照)。
アクセス権の管理はサーバー側でRDBの表定義でユーザーを指定最後にセキュリティの問題に触れておこう。
本杜工場OAシステムでは、パソコンからサーバーRDBのデータを検索できるだけでなく、データを書き換えたり、追加することも許している。
「エンドユーザー・コンピューテイングと言うからには、ユーザーにいじられて困るデータはない、というのが基本的な考え方」(宮本次長)だ。
しかしどうしてもデータの書き込みを制限する必要がある場合は、サーバーRDBの表を定義する時にアクセス可能なユーザー・コードを指定することで対処している。

(吉田琢也)

-----
ミニインタビュー/改田取締役CIS企画部長

  トヨタの情報システムに対する取り組み方を説明してほしい。
  以前のシステム部門は、エンドユーザーの要望を聞いてそれに答えるだけの受け身の存在だった。
それではいけないという反省から、全社の中での情報システムの位置づけを明確にし、システム化の優先順位や、予算、人員などを決定するCIS企画部を設立した。
基本的には情報システムの開発はCIS企画部の計画に従って行う。
しかし、今回の本社工場のようにエンドユーザーが自分達でシステムを開発したいという意向にはできる限り答えていくつもりだ。
ユーザー自身がやる気になってくれないシステムはうまく機能しないからだ。
 エンドユーザー自身がシステムを開発するメリットは何か。
  私も元はユーザー部門に在籍していた。
当時の経験から言えることだがシステム部門から情報システムの導入に伴って業務改善を指示されると、どうも高圧的な感じを受けて素直に聞けないことが多い。
ところがユーザーか自分達でシステムを開発すると、自発的に仕事の仕組みを整理してコンピュータを上手に使いこなそう、という意識が生まれる。
ここが一番違う点だ。
 これからの情報システムの課題は何か。
  全社ホスト、部門コンピュータ、パソコンのそれぞれにどのようなデータを載せたらよいか、というデータの切り分けの問題がある。
例えば全杜ホストは必ずしも全工場の人事や経理に関するデータを持つ必要はないという考え方もある。
データベースの整備はCIS企画部にとって大きな課題だ。
教育についての課題も多い。
システム部門では以前から大型機の教育を実施しているが、パソコンや、中型機とパソコンとのインタフェースに関する教育が遅れており、今年から始める計画だ。
またエンドユーザーの中にシステム化を推進するための核となる人物を育てる教育も必要。
情報システム部の人員も限られており、ユーザーの要求に答えきれなくなってきたからだ。