コラム・特集

7.4 OISユーザー・インターフェイス

IEハンドブック
第12部 コンピュータと情報処理システム

第7章 オフィス・オートメーション

7.4 OISユーザー・インターフェイス

事務作業者が容易に学べ,かつ使いこなせるような高級事務言語は,当然のことながらOISの効果的な維持発展を促がす。しかし,事務作業固有の,または言語開発につきものの複雑さゆえ,このような言語の確立は困難であろう。それにもかかわらず,現在の技術水準でユーザーが多種のアプリケーション・システムを維持運営していけるような,それも最低限の教育しか必要としないような,高級事務言語の開発を予測することは,まんざら常識外れでもない。

その言語は,WP(ワードプロセッサー)と,データベース管理装置を併有し,そ れによってユーザーは,データベースの定義,維持および問合せが可能となり,また,選択され処理されたデータベースの情報を,報告書や文書に盛り込むことができるようになろう。複雑なデータ構造を制御するための,洗練されたデータベース管理システムの良い例としては, ミクロ・データベース・シス テムがあげられる。これは,商業的にも成功したマイクロ・コンピュータを用いたシステムである。WPとデーターベース管理機能により,事務作業者は,一般のオフィスにおけるアプリケーションを,学者のオフィスにおいてそれを開発するのと同様に,開発することができる。 OISで用いられる2種の言語が以下に示され,自動化OISとユーザー間のインターフェイスに関して,その後に論じる。

例示事務処理言語
「例示事務処理言語」(The Office Procedure by Example Language:OBE)は ,オフィスおよび実 務のアプリケーションの自動化のために使用される目的で作られた,非常手続向き言語である。OBEは ,IBMの 調査プロジェクトの結果生まれた。例示照会プログラム (Ouery‐by-Example: OBE)の拡張バージョンである。OBE言語により,事務作業者は,データベースの維持が可能になり,また,ワーク・ステーションでデータベース情報を用いて,表やフォーム等の文書作成が可能となる。多種の算術計算も可能である。また,OBEでは,操作中に何か重大な事故が起こったなら,ただちに実行できるような,プログラム・セーブ装置を備えている。OBEにおけるコミュニケーションは,電子メイルシステムを用いている。

OBEの基本的な目的は,2次元のフォームである。フォームを,サンプル・データで埋めることによって,ユーザーは,データベース’情報をどのようにフォームの上に並べるかを規定できる。サンプル・データによって作られたフォームの仕様は,実行したときに文書を作り出す自動的な手続きを設定する。この文書はさらに編集を 加えることができ,また,ネットワーク網における他のワーク・ステーションに伝送することもできる。

図表12.7.1は,OBEスタイルで書かれた自動化された手続きを例示している。こ の手続きは,ある管理者の下に配属された,新しい従業員のリストを出力するものである。この手続きは,ユーザーの介入なしに,月にー度自動的に行われるように設定されている。報告書は, 電子メイルシステムにより,自動的に相当する管理者へ送られる。

この手続きの仕様は,(1)2つのデータベースの 参照,(2)条件の問合せ,(3)フォームをつくるためのひな 型,(4)トリガー(開始)命令,(5)センド(送り)命令,からなる。

手続きを記述する第1のデータベースであるAPPL ICANT(求職者データベース)には,(1)名前,(2)状態(H=採用,R=不採用,W=就職:すでに働いている) (3)職階,(4)採用日(状態がHかWの 場合のみ),(5)所属部署,が含まれる。DEPARTMENT(部 署)データベースは,部署および,部署の管理者の名前からなっている。下線を引いた文字,N,DP,D,Mは,例題としての要素である。例題要素が,データベースの記述部と,フォームのサンプルに書いてあるということは, データベースの情報がフォームに移されることを意味じている。この手続きでは,APPLICANTとDEPARTMENTは ,DEDTという名の部署名フィールドで関連づけられる。部署名フィールドは,両データベースに共通である。この相互参照の結果,Mは,各部署の管理者の名前の格納場所となる。APPLICANTデータベースの状態フィールド にある文字Hは,固定的であり,Hの状態の求職者のみが,この手続きでアクセス されることを表わしている。さらに条件ボックスが,ど んな求職者が報告されるべきかの制約を設定する。この 仕様では,採用日が1980年の人間が対象になっている。 OBEの自 動スケジュール機能が,日常的に処理されるべきリストをメンテナンスする。

これは,自動的に, 適切な時期がくると実行するようにスケジュールする機能である。トリガー命令であるTRI(MONTHLY) およびSEND(TRI)ATOMコマンドは,毎月, 報告が自動的に,手紙Aの宛名に書かれた管理者のもとへ送られることを指定している。この手続きが実行されると,ただちに,図表12.7.2に 示すような報告が作成される。図表12.7.2は ,このフォームを作るのに用いられるデータベースの内容をも示している。

OBEにおけるデータベースの完全性は,完全性保全機能により守られる。保全機能とは,更新データを,その値が妥当であることを確認するため,データベースに矛盾がないことを確認するために編集することを含む。 保全機能は無条件で,もしくはある特殊なデータベース 操作を行ったときだけに,働かせることができる。前述のように,手続きを指定した時間に自動的に実行させる のに加え,指定した事柄(例えば当座借越等)が起こると自動的に実行させることもできる。そのようにやらせるための条件は,単純なものであるか,それら を組み合わせたものである。

業務定義言語
業務定義言語(BDL)は IBMの Thomas J.Watson調査センターで開発されたもので,とくに実務データ処理用に設計された高級言語である。BLDセ ンターでの観察により明らかにされた。事務データ処理についての見解は,その主な作業は文書処理である,というものであった。文書は,準備作成され,コミュニケーションをとるために部課の間を単独に,もしくはグループをなして送付される。これらの文書は,後に取引を記録したり,参照するのにも用いられる。これらの文書の準備作成に含まれる数値的な作業は,通常,非常に低いレベ ルである。

BDL設計の目的は,事務作業者が構造的でモジュール化されており,文書化およびメンテナンスが容易であ るプログラムを書けるような言語を創り出すことであった。目的を達成するために,設計者が採った手段は,すべてのアルゴリズムを,意味の判り易い用語で書ける言語を供給するというものであった。BDLは ,一般的な事務データ処理用に設計されたものではあるが,その開発においての設計哲学には,来たるべきOIS言語の設計にも適合する,という青写真があった。

BDLにおける基本的な要素は,文書,ステップ,パスおよびファイルである。文書は,ステップやプログラムの入出力媒体としての役割を果たす。ステップは,文書処理のための処理の動きを連続してつづったものであり,プログラムはステップの連続である。各ステップは, これ以下分割できない原始ステップか,または原始ステップの複合形である。原始ステップは,標準的な,前もっ て決められた文書の変換を表わすか,またはステップの入出力行動を記述した,ユ ーザーの書いたルーチンを表わす。複合ステッ プは原始ステップに分解することができる。各ステップは,「部」のような組織の単位にあてはまる。複合ステップ のネスティング(入れ子)は,組織の階層構造を反映するように 意図されている。パスはステップ間の文書の流れを表わす。ファイ ルは,文書を長期間保存しておく場所として用いられる 。

DFCアプリ ケーション・システムは,文書の処理や文書の流れの中に含まれる組織単位の言葉を用いて,図形的に定義される。基本的なダイアグラムの構成要素は,長方形,円および矢印であり,それぞれステップ,ファイル,パスを表わす。データの流れが分岐しているのは, 文書のコピーがそのパスに沿って送られることを示す。 図表12.7.3は,販売処理システムをDFCで表示したものである。

こ の販売処理システムは,3つの主たる 複合ステップ, すなわち,顧客サービ ス ,荷積み,売掛金処理からなる。

各複合ステップの内部構造は,より基本的なステップと,データ・フローによりさらに定義される。その定義され たステップもまた,他のDFCダイアグラムで定義される複合ステップであってもよい。すべてのステップがこれ以上分割できない原始ステップであれば,システムは完全に記述されたことになる。

この販売処理の例は,OISとデータ処理アプリケー ションの両方の見地を兼ね備えている点で特に興味深い。顧客サービス・ステップでは,送り状を作成し,支払条件の承認をする。送り状作成ステップは,ワーク・ステーションでそこの秘書により遂行される。秘書は未記入の送り状に,顧客名,住所,製品番号,数量の欄を埋めていく。その後の手続きは,価格ファイルにアクセスして, 製品単価,製品毎の価格および合計金額を埋めることである。量後に秘書が,できた送り状を見直し,必要ならば修正を加え,掛売の承認をとるためのワーク・ステーションヘこれを送る。

会計担当者は,通常の注文における支払条件を承認する場合の一般的な方針を持っているので,一般的な承認の枠外で承認するような特別なケースの時だけ関与すればよい。このような特別なケースでは,ワーク・ステー ションは,その顧客との今までの取引の経歴と共に,間題の送り状を表示するようにプログラムされている。いずれにしても,承認された送り状は荷積みへと送られる。 荷積ステップ,および売掛金処理ステップは,日常的なデータ処理のシステムであり,自主的な手続きを必要とせず,ほとんど人間が操作することなしに決まりきったアルゴリズムを実行するという点で,OISと は異なる。Accum(蓄積)機能は,送り状を深夜まで待たせておき,深夜に今日1日のすべての送り状を,荷積データ処理システムヘ投入する。荷積データ処理システムは, 決められた優先順位に従って,注文を満たしていき,在庫情報を更新し,発送計画をたてる。作業者は,自動化された倉庫では,注文された品物が包装されるのを監視し,おのおのが終わったならば,それをシステムに知らせればよい。システムは荷積通知書を発行する。同様に, 売掛金処理システムでは,売掛金ファイルと送り状ファ イルを更新するための入カデータとして,この荷積通知書を受け入れる。

DTCは,DFCの中の原始ステップの,実際の計算方法を定義するために用いられる。理論的には,どのようなプログラミング言語でも,DTC言語の代わりに用いることはできる。前述例のとおり,OIS言 語や,実務データ処理言語は,どちらも複合システムを実施させることができるのである。このDTC言語は,すべてのステップに対し,総括的な構造をとっており,実務デー夕志向のビルトイン制御構造という点で,プログラマーに利点をもたらす。

結果的にプログラムが簡単になる代わりに,われわれは言語の柔軟性においては損をしている。プ ログラマーは,入力文書から出力文書を作るための変換を定義する際に,制御構造を利用する。出力文書の各フィールドに必要な計算は,必要に応じて,算術演算子,論理演算子や比較演算子を用いて記述される。DFC実行時のメカニズムによって,文書が入カパス上で入力可能であり,それ以前のステップが完了していれば,たちどころにステップを実行することができる。

 本コラムは絶版となっている「IEハンドブック(サルベンティ編・日本能率協会訳・1986)」をアーカイブとして掲載するものです。このハンドブックの各章は多くの事例と理論を通して生産性向上に対するアイデアを提供するべく専門家によって執筆されています。基盤をなしているIEの考え方・原則はインダストリアル・エンジニアリングにかかわるすべてのひとに有用でしょう。

関連記事一覧

2019ものづくり公開セミナーガイド

B2Bデジタルマーケティングセミナー

ものづくり人材育成ソリューション

マーケティング分野オンラインセミナー