JP2720754B2 - グループウェア開発支援システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数の作業者が各作業
者間の連絡に電子メールを利用して行う一連の作業の実
行を支援するグループウェアの設計・開発を支援するグ
ループウェア開発支援システムと、該グループウェアに
おいて作業者間の連絡に用いられる電子メールの送受信
を行う電子メール送受信装置に関する。

【０００２】

【従来の技術】複数の作業者が行う作業の実行を支援す
るシステムは、一般にグループウェアと呼ばれている。
その中で、全作業者が同時に作業を行うことを前提とし
たものをリアルタイム型のグループウェアと呼び、その
ような前提のないものを非リアルタイム型のグループウ
ェアと呼ぶ。本発明は主として非リアルタイム型のグル
ープウェアを対象としたものである。

【０００３】非リアルタイム型のグループウェアでは、
通常、作業者間の連絡には電子メールを用いる。電子メ
ールを連絡手段として用いて、複数の作業者の間でのや
りとりを支援するグループウェアシステムとしては、事
務帳票を電子メール化して帳票記入・承認等の作業を支
援するものが代表的である。これはオフィスオートメー
ションシステムとして用いられているグループウェアの
例である。このような、電子メールを連絡手段として用
いられるオフィスオートメーション向きのグループウェ
アのことを、本願においては、以下単にグループウェア
と呼ぶことにする。グループウェアを開発する際には、
オフィスの業務手順をシステムに組み込むための開発支
援システムが必要である。グループウェアの開発支援シ
ステムに関する過去の特許出願の例としては、以下のも
のがある。

【０００４】〔特開平4-76768 〕明細書では、電子帳票
を設計し作成する、電子帳票作成装置について詳述され
ている。この電子帳票作成装置では、電子帳票の設計時
に、データの入力に応じて印刷、承認、複写、転記等の
帳票処理部品を起動する処理手順を予め定義しておくこ
とができる。また、〔特開昭63-141176 〕明細書では、
電子メールを伝票として利用し、事務処理を行うための
電子伝票システムについて詳述されている。この電子伝
票システムは、事務処理フロー管理機構と事務処理自動
化処理プログラム起動・監視機構を備えており、事務処
理フロー管理機構が伝票の内容の条件に合致した次の伝
票処理あるいは伝票転送先を自動的に決定し、特に伝票
処理が必要な場合には事務処理自動化処理プログラム起
動・監視機構が該当する処理プログラムを自動的に起動
する。

【０００５】学会論文による公開の例としては、情報処
理学会第42回全国大会4T-6, および情報処理学会第44回
全国大会4M-4で発表されているBrownie システムがあ
る。Brownie は、一つのフォームを電子メールとして作
業者間で受け渡しし、各作業者がそれぞれの役割に応じ
てフォームへの記入を行う。また、グループワークの流
れの記述方法についても開示している。

【０００６】

【発明が解決しようとする課題】上述した従来のグルー
プウェア開発支援システムは、以下の具体例に示すよう
な支援システムの利便性、支援システムが扱える転送形
態の多様性に欠けるという問題点があった。〔特開昭63
-141176 〕の例から分るように、グループウェアにおけ
る電子メールの転送順や処理プログラム起動条件を定義
することはできても、その定義方法は、特殊なプログラ
ミング言語あるいは条件表に記入するという方法による
しかなく、電子メール転送方式や電子メールからのアプ
リケーション起動方式に関して専門知識を有しない開発
者が容易に定義できるものとはなっていない。

【０００７】〔特開平4-76768 〕〔特開昭63-141176
〕から分るように、電子的な帳票あるいは伝票がある
条件を満たした場合、所定のある処理プログラムを起動
することのできるシステムでも、例えば処理を終了した
後さらに別の作業者に処理済の伝票あるいは帳票を電子
メールにて転送するというような、人手による記入とシ
ステムによる処理が混在する一連の手順を一貫して設計
することはできない。また、Brownie は、グループワー
クの流れの記述方式を開示しているが、流れの記述を直
接設計結果として開発支援システムで利用することがで
きない。 オフィスオートメーションシステムでの、一連の作業
における各作業者の役割は「係長」「課長」等の組織に
密着した固定的なものしか提供されておらず、そのた
め、例えば「査閲者」「承認責任者」等、組織よりもむ
しろ一連の作業の各ステップに関連する役割の名称を使
ってグループウェアの設計を行う場合、実際にどの具体
的な作業者が各役割に就くかはあとで決めるような開発
方式をとることができない。 対象となる一連の作業は計算機上で帳票記入等の文書
編集を中心として複数の作業者の間で逐次行われる作業
に限られており、例えば計算機を利用しない会議、ある
いはオンラインリアルタイム会議システムのような計算
機を利用した会議を途中にはさんだ一連の作業に関して
は、対象とすることができない。 複数のソフトウェアモジュールが互いの自律的目標を
動的に調整しながら最適な解を自動的に求める、いわゆ
るマルチエージェントシステムを利用した一連の作業を
対象とすることができない。 すべての作業者は同じ計算機の種別、同じネットワー
クを利用し、さらに同じ編集プログラムを利用しなけれ
ばならない等の制限があり、作業者の嗜好や作業環境の
個人的な相違を反映した柔軟なシステムの構築を支援す
ることができない。 複数の電子メールの到来を待ち合わせてから次の動作
を開始するようなソフトウェアオブジェクトあるいは作
業者の設計ができない。 電子メールの転送順に関してよく使われるパターンを
登録して再利用することができない。

【０００８】

【課題を解決するための手段】第１の発明は、複数のノ
ード間で電子メールを受け渡ししながら一連の作業を遂
行するのに使用されるグループウェアシステムの開発を
支援するグループウェア開発支援システムにおいて、前
記ノードが作業者を表現する作業者対応ノードおよび前
記電子メールを少なくとも入力あるいは出力とするソフ
トウェアオブジェクトを表現するソフトウェアノードの
二種類であって、前記ノード間で受け渡しされる前記電
子メールの様式を視覚的に定義し様式定義情報として出
力する様式定義手段と、前記ソフトウェアオブジェクト
の動作条件情報を定義しオブジェクト定義情報として出
力するオブジェクト定義手段と、受け渡しされる前記電
子メールの前記複数のノードにおける転送ルートと前記
転送ルートにおける前記ノード間で受け渡しされる前記
電子メールの様式とを視覚的に定義し転送順定義情報と
して出力する転送順定義手段と、前記様式定義情報と前
記転送順定義情報に基づき前記転送ルートにおける前記
作業者対応ノードの前記電子メールの編集動作を指示す
る第一の電子メール利用環境定義情報を生成し、また前
記様式定義情報と前記オブジェクト定義情報および前記
転送順定義情報に基づいて前記ソフトウェアノードにお
ける前記ソフトウェアオブジェクトの前記電子メールの
転送動作を指示する第二の電子メール利用環境定義情報
と前記ソフトウェアオブジェクトの個別動作を実行する
に必要な処理プログラムコードとを生成する生成手段と
を有することを特徴とし、上述したおよびに挙げた
課題を解決する。

【０００９】また、第２の発明は、複数のノード間で電
子メールを受け渡ししながら一連の作業を遂行するのに
使用されるグループウェアシステムの開発を支援するグ
ループウェア開発支援システムにおいて、前記ノードが
作業者を表現する作業者対応ノードおよび前記電子メー
ルを少なくとも入力あるいは出力とするソフトウェアオ
ブジェクトを表現するソフトウェアノードの二種類であ
って、前記ノード間で受け渡しされる前記電子メールの
様式を視覚的に定義し様式定義情報として出力する様式
定義手段と、前記ソフトウェアオブジェクトの動作条件
情報を定義しオブジェクト定義情報として出力するオブ
ジェクト定義手段と、受け渡しされる前記電子メールの
前記複数のノードにおける転送ルートと前記転送ルート
における前記ノード間で受け渡しされる前記電子メール
の様式とを視覚的に定義し転送順定義情報として出力す
る転送順定義手段と、前記作業者対応ノードの各々に対
して役割名称と作業者個人の名前との対応を定義し役割
対応定義として出力する役割対応定義手段と、前記様式
定義情報と前記転送順定義情報と、前記役割対応定義に
基づき前記転送ルートにおける前記作業者対応ノードの
前記電子メールの編集動作を指示する第一の電子メール
利用環境定義情報を生成し、また前記様式定義情報と前
記オブジェクト定義情報および前記転送順定義情報に基
づいて前記ソフトウェアノードにおける前記ソフトウェ
アオブジェクトの前記電子メールの転送動作を指示する
第二の電子メール利用環境定義情報と前記ソフトウェア
オブジェクトの個別動作を実行するに必要な処理プログ
ラムコードとを生成する生成手段とを有することを特徴
とし、上述したに挙げた課題を解決する。

【００１０】さらに第３の発明は、第１、第２の発明に
おいて、前記転送順定義手段にて前記転送ルートにおけ
る前記ノード間で受け渡しされる前記電子メールの様式
が指定されていない場合に、前記様式が指定されていな
い前記電子メールの受け渡しに関する前記電子メールの
送信側ノードである前記ソフトウェアノードの前記ソフ
トウェアオブジェクトに関して、作業の完了を示す予め
定められた様式の電子メールを自動的に生成し転送する
ことを記述した前記ソフトウェアオブジェクト用の処理
プログラムコードを生成する生成手段とを有することを
特徴とし、上述したに挙げた課題を解決する。

【００１１】さらにまた、第４の発明は、第１、第２、
第３の発明において、前記転送順定義手段にて前記ソフ
トウェアノードの一つとして前記電子メールを少なくと
も入力または出力とし複数の作業者による会議を表現す
る会議仮想オブジェクトノードが記述された場合に、前
記会議仮想オブジェクトノードに関して前記電子メール
入力を会議資料として発信元以外の前記会議参加の全作
業者対応ノードに配布し、かつ議事録様式の前記電子メ
ールを予め指定された書記ノードに配布することを指示
する第三の電子メール利用環境定義情報を生成する前記
生成手段を備えたことを特徴とし、上述したに挙げた
課題を解決する。

【００１２】さらにまた、第５の発明は、第４の発明に
おいて、前記会議仮想オブジェクトが計算期間ネットワ
ークを介してリアルタイムにコミュニケーションを行う
オンラインリアルタイム会議システムであることを特徴
とし、上述したに挙げた課題を解決する。

【００１３】さらにまた、第６の発明は、第１から第５
の発明のうちいずれか１つに記載された発明において、
前記転送順定義手段にて複数の前記ソフトウェアノード
間で協調を意味する相互関係が定義されていた場合は、
前記協調を意味する相互関係を有する前記ソフトウェア
ノードに関して、自己目標を動的に調整しながら最適な
解を自動的に求めるマルチエージェント処理を実行する
ように記述された前記ソフトウェアオブジェクト用の処
理プログラムコードを生成する前記生成手段を備えたこ
とを特徴とし、上述したに挙げた課題を解決する。

【００１４】さらにまた、第７の発明は、第１から第６
の発明のうちいずれか１つに記載された発明において、
前記作業者対応ノードとして用いられる個別の計算機お
よび前記作業者対応ノードが属するネットワークの種類
および前記作業者対応ノードの利用する個別の編集プロ
グラムや電子メール利用環境等を含む作業環境を定義し
作業環境定義情報を出力する作業環境定義手段を備え、
前記作業者対応ノードに関して前記作業環境定義情報で
指定された前記作業環境で前記電子メールの転送動作お
よび前記電子メールの編集動作を行うように指示する第
五の電子メール利用環境定義情報を生成する前記生成手
段を備えたことを特徴とし、上述したに挙げた課題を
解決する。

【００１５】さらにまた、第８の発明は、第１から第７
の発明のうちいずれか１つに記載された発明において、
前記転送順定義手段にて複数の電子メール入力を持つ前
記ソフトウェアノードが定義された場合には、複数の電
子メール入力を持つ前記ソフトウェアノードに関して、
前記複数の電子メール入力の完了を待ち合わせてから前
記ソフトウェアオブジェクトが動作を開始するように指
示する第六の電子メール利用環境定義情報を生成する前
記生成手段を備えたことを特徴とし、上述したに挙げ
た課題を解決する。

【００１６】さらにまた、第９の発明は、第１から第８
の発明のうちいずれか１つに記載された発明において、
前記転送順定義手段が、予め登録された転送順のパター
ンを検索して再利用する再利用手段を有することを特徴
とし、上述したに挙げた課題を解決する。

【００１７】最後に、第１０の発明は、計算機ネットワ
ークから電子メールを受信する電子メール受信手段と前
記電子メールに関する条件と動作に関する対応関係を定
義した電子メール利用環境定義ファイルを読み込んで解
釈する環境解釈手段と前記環境解釈手段から前記対応関
係を受け取り前記電子メール受信手段から電子メールを
受け取り前記電子メールに前記条件が成立した場合に前
記条件に対応する動作を実行する制御手段とを有する電
子メール送受信装置において、前記電子メール利用環境
定義ファイルがさらに電子メール受信端末の識別名と電
子メール編集ソフトウェアの種別の定義情報を保持し、
前記環境解釈手段が前記端末の識別名と前記電子メール
編集ソフトウェアの種別の定義を解釈し、前記制御手段
が前記環境解釈手段から渡された前記端末の識別名の定
義に従って前記端末との接続を行うとともに前記環境解
釈手段から渡された前記電子メール編集ソフトウェアの
種別の定義に従って前記端末に前記電子メール編集ソフ
トウェアの選択を指示することを特徴とする。

【００１８】

【実施例】次に、本発明について図面を参照して説明す
る。

【００１９】図１は、請求項1 に記載された第１の発明
であるグループウェア開発支援システムの一実施例を示
すブロック図である。グループウェア開発支援システム
1 は、定義部2 と生成手段6 からなり、定義部2 は様式
定義手段3,オブジェクト定義手段4,転送順定義手段5 を
含んでいる。定義部2 は入出力装置7(例えばディスプレ
イ、キーボード、マウス) と結合しており、本グループ
ウェア開発支援システムの利用者たる開発者は、入出力
装置7 を通して定義部2 に含まれている三つの定義手段
を操作し、必要な定義を行うことができる。様式定義手
段3 は、電子メールの様式を定義し、様式定義を生成手
段6 に送る。オブジェクト定義手段4 は、電子メールを
少なくとも入力あるいは出力とするソフトウェアオブジ
ェクト(ソフトウェアモジュールと同等) を定義し、そ
の定義を生成手段6 に送る。転送順定義手段5 は、開発
対象である目標システムの複数の作業者あるいは複数の
ソフトウェアオブジェクトの間で受け渡しされる電子メ
ールの転送順と、受け渡し作業毎に用いられる様式を定
義し、その定義を生成手段6 に送る。生成手段6 は様式
定義手段3,オブジェクト定義手段4,転送順定義手段5 か
らそれぞれ定義結果を受け取り、目標システムにおける
各作業者の電子メール利用環境と、各ソフトウェアオブ
ジェクトの動作を決定するコードを生成し、生成結果を
記憶装置8 に格納する。

【００２０】以下、図２から図４までを用いて、様式定
義手段3 について説明する。図２は、図１におけるグル
ープウェア開発支援システムの様式定義手段3 で定義さ
れる様式構成図の一例である。図２では、質問票という
様式を定義している。質問票21は7 つのフィールド( ラ
ベル22, ラベル23, ラベル24, ラベル25, 記入欄26,選
択欄27, 記入欄28) からなっている。このうち、記入欄
26, 記入欄28には作業者が文字を記入することができ
る。また、選択欄27では、作業者が選択子を選択するこ
とができる。

【００２１】図３は、入出力装置7 を介して様式定義手
段3 を利用する場合の画面の一例を示す図である。画面
31はマルチウィンドウシステムによる表示を行ってい
る。編集ウィンドウ32は、様式の編集を行うエディタを
提供する。この例の場合、図２の例で示した質問票を編
集しており、質問票は編集ウィンドウ32の中で、編集結
果33が実物通り表示されている。メニューウィンドウ34
は、編集ウィンドウ32の中に編集結果33の如き様式を得
るために、様式の要素であるフィールドを選択するため
に用いる。

【００２２】編集の方法は以下の通りである。開発者
は、まずメニューウィンドウ34に示されている外枠、ラ
ベル、記入欄、選択欄の4 つのメニューの中から、マウ
スで一つをクリックして選択する( 第一のクリック) 。
次に開発者は、編集ウィンドウ32の中でマウスをクリッ
クする( 第二のクリック) 。その結果、第二のクリック
をした地点に、第一のクリックで選択したフィールドま
たは外枠が配置される。次に開発者は配置されたフィー
ルドの四角の任意の一端をマウスでドラッグして変形
し、必要な変形を繰り返して所望の様式の形を得る。以
上の手順に従って、外枠とすべてのフィールドの配置を
行うことができる。ただし、選択欄に関しては、一つ一
つの選択子をさらに定義しなければならない。この場
合、選択欄上でマウスをダブルクリックすると、詳細定
義ウィンドウ35がポップアップされて現れる。開発者
は、詳細定義ウィンドウ35の中で選択子を定義すること
ができる。ラベル欄中の文字列についても、同様に、詳
細定義ウィンドウを用いて定義する。

【００２３】図４は、様式定義手段3 から生成手段6 に
渡される様式定義の記述例である。この例は図２の質問
票を表現したものである。なお、行番号は説明の便宜上
付加したものである。1 行目は、外枠の幅と高さを示
す。2, 8, 14, 19,25, 30, 36行目は、フィールド定義
の開始を示し、各行のnameの直後にある語(label0, TE0
など) はフィールドの名称である。フィールドの名称は
自動的に付加される。7,13, 18, 24, 29, 35, 41 行目
はフィールド定義の終了を示す。3, 9, 15, 20, 26, 3
1, 37行目は、フィールドの種別を示す。LabelType は
ラベル欄、TextTypeは記入欄、SelectionType は選択欄
である。4, 10, 16, 21, 27, 32, 38 行目は、それぞれ
フィールドの左肩の位置を外枠の左肩からの相対座標で
示したものである。5, 11, 22, 33 行目は、ラベル型フ
ィールドの文字列を定義する。39行目は、選択型フィー
ルドの選択子を定義する。6, 12, 17, 23,28, 34, 40行
目はそれぞれフィールドの幅と高さを示すサイズ値であ
る。なお、例えば「質問票」ラベルフィールドの幅が6
行目で示すように328 であり、1 行目で示す外枠の幅33
0 と一致しないのはフィールドの両端の罫線の幅の分が
差し引かれているからである。

【００２４】ここでは最も簡単な様式定義手段の実施例
を説明したが、より高機能の様式定義手段としては、 1. フィールドの種別として図形記述欄、音声録音欄、
数値記入欄、日付記入欄等を追加する。 2. 選択欄の場合、一度に選択できる数の最大数、最小
数を定義可能にする。 3. フィールド間に引く罫線の幅、パターン( 破線か、
実線か、等) を定義できるようにする。 4. 数値記入欄の場合、記入可能な最大値、最小値を定
義できるようにする。 等の機能を追加したものが考えられる。

【００２５】次に、図５を用いて、オブジェクト定義手
段4 について説明する。

【００２６】オブジェクト定義手段4 は、開発者に対し
てオブジェクト定義記述の可能なテキストエディタの形
式で提供する。図５は、オブジェクトを定義した例であ
る。ただし、図５では、説明の便宜のため、行番号を付
加してある。1 行目は、オブジェクトの名前QuestionRe
corderを定義している。2 行目は、本オブジェクトは入
力として質問票を電子メールで受け取ることを示してお
り、定義中ではm で参照することを宣言している。4 行
目から12行目までは、本オブジェクトで実行されるソフ
トウェアプログラムによる処理を定義している。5 行目
から7 行目までは、図２の様式の質問票における選択欄
27( 図４では、36行目から41行目において、menu0 と
いう名称で定義されている) の内容が"a) 技術" である
場合の処理について定義している。まず、5 行目におい
て選択欄27の内容が"a) 技術" であるかどうかを判定
し、もし選択欄27の内容が"a) 技術" であれは、6 行目
において図２における記入欄26( 図４においては14行目
から18行目においてTE0 という名称で定義されている)
の内容を、技術質問記録という名前のデータベースに登
録する。ここでは、データベースへの登録はadd_dbとい
う関数で実現できるものとしている。9 行目から12行目
までは、5 行目から7 行目までと同様の方法で、選択欄
27の内容が"b) 事務" である場合の処理について定義し
ている。14行目では、本オブジェクトの出力が、入力と
同じく、質問票という様式で、定義中でm で参照された
ものであることを示している。15行目は、オブジェクト
QuestionRecorderの定義の終了を示している。

【００２７】オブジェクト定義手段4 は、図５に示した
オブジェクト定義記述を、そのまま生成手段6 に渡す。
なお、説明を簡単にするため、例えば図５の5 行目で用
いているmenu0 という選択欄27を示す名前は、様式定義
手段3 によって自動的に生成された名前をそのまま用い
ている。したがって、この実施例では、オブジェクト定
義手段4 利用時に開発者がオブジェクト定義を行うため
に、様式定義手段3 で自動的に生成された名前を調査す
る手間が発生するという問題が生じる。この問題を解決
するためには、様式定義手段3 において欄の名称を開発
者が定義する機能を提供すれば良い。

【００２８】次に図６から図１１までを用いて転送順定
義手段5 について説明する。図６は、開発者が、転送順
定義手段5 を利用して定義する転送順の例を示すチャー
ト図である。このチャート図は、ノードと、ノードを接
続するアークからなるグラフ図であって、61a, 61b, 61
c, 61d がノード、62a, 62b, 62c がアークである。ノ
ードのうち、61a, 61c, 61d は作業者をアイコンで表
し、61b はソフトウェアオブジェクトを円で表してい
る。63a, 63b, 63c, 63dはノードの名称を示すラベルで
あり、63a,63c, 63dは作業者の名前、63b はソフトウェ
アオブジェクトの名称( 図５で定義したQuestionRecord
erという名称) を示している。アーク62a, 62b, 62c は
それぞれノード間の電子メールの受け渡しを表現してい
る。四角形64a, 64b, 64c は、それぞれアーク62a, 62
b, 62c の表現する電子メール受け渡しが様式を持って
いることを示し、その様式の名称はそれぞれラベル65a,
65b, 65c で指定されている。ラベル65a, 65bに於いて
指定されている「質問票」という様式は、図２で定義し
たものである。また、ラベル65c で指定されている「回
答票」という様式は、本実施例の説明中では省略した
が、図２で定義した「質問票」を利用した質問に対する
回答を電子メールで行う為の様式である。

【００２９】この図６のチャート図は、以下に示す転送
順を意味する。 1. 山田太郎は、「質問票」という様式を利用して質問
を作成し、電子メールとしてソフトウェアオブジェクト
QuestionRecorderに送る。 2. ソフトウェアオブジェクトQuestionRecorderは、図
５の定義に従って、質問の履歴をデータベースに登録
し、質問票を鈴木花子に転送する。 3. 鈴木花子は、質問に対する回答を、様式「回答票」
を使って作成し、山田太郎に電子メールとして送付す
る。

【００３０】図７は、入出力装置7 を介して転送順定義
手段5 を利用する場合の画面の一例を示す図である。画
面71はマルチウィンドウシステムによる表示を行ってお
り、その中に転送順定義ウィンドウ72が表示されてい
る。転送順定義ウィンドウ72は、転送順定義手段5 を利
用するためのウィンドウである。転送順定義ウィンドウ
72は、ボタン73a, 73b, 73c, 73d, 73e と編集ウィンド
ウ74を持つ。図７では、すでに編集が終了し、編集ウィ
ンドウ74の中に図６で示した例のチャート図が完成して
いるところを示しているが、この例で示されるように、
編集ウィンドウ74は、チャート図を編集するためのウィ
ンドウである。

【００３１】次に、チャート図の編集方式の一実施例を
示す。チャート図を編集するには、ボタン73a, 73b, 73
c, 73dを利用する。 1. ボタン73a をマウスでクリックすると、図８のメニ
ュー81に示す如く、予め登録された作業者の一覧がメニ
ュー形式で表示される。開発者はメニュー81の中から作
業者を一つ選択し、次に編集ウィンドウ74中の一点でマ
ウスをクリックすると、その地点に作業者アイコンを配
置することができる。 2. ボタン73b をクリックすると、図９のメニュー91に
示す如く、オブジェクト定義手段4 で定義されたソフト
ウェアオブジェクトの一覧がメニュー形式で表示され
る。開発者は、メニュー91の中からソフトウェアオブジ
ェクトを一つ選択し、次に編集ウィンドウ74中の一点で
マウスをクリックすると、その地点にソフトウェアオブ
ジェクトを配置することができる。 3. 以上のようにして、すべてのノード( 作業者または
ソフトウェアオブジェクト) の配置を終了した後、開発
者はアークの定義を行う。アークの定義を行うには、ま
ずボタン73c をクリックし、次にアークの始点ノードを
マウスでクリックし、マウスボタンを押したままアーク
の終点ノードまで移動し、マウスボタンを離す。 4. 開発者は、最後に様式の指定を行う。様式の指定
を行うには、まずボタン73dをマウスでクリックする。
その結果、図１０のメニュー101 に示す如く、様式定義
手段3 で定義された様式の一覧が、メニュー形式で表示
される。開発者はメニュー101 の中から所望の様式を選
んでマウスでクリックし、次に編集ウィンドウ74中に定
義されているアークの一つを選んでマウスでクリックす
る。

【００３２】すると、該アークで示される電子メールの
受け渡しの様式は、メニュー101 の中から選んで選択さ
れた該様式と指定される。以上の操作により、チャート
図の編集が終了すると、最後に開発者はボタン73e をマ
ウスでクリックして転送順定義を終了する。なお、この
ようなチャート図の編集ソフトウェアは、鼎( かなえ)
（商標；日本電気株式会社）に含まれているグラフ構造
エディタ部品を利用すると容易に構築できる。

【００３３】図１１は、図６で例示されたチャート図に
よる転送順を転送順定義手段5 で定義した場合に、転送
順定義手段5 から生成手段6 に渡される転送順定義の一
例を示す図である。ただし、説明の便宜のために行番号
を付加してある。1 行目から3 行目までは、転送順定義
で用いる作業者、ソフトウェアオブジェクト、様式をそ
れぞれ宣言する記述である。5 行目から8 行目までは、
チャート中の4 つのノードを順に定義している。例えば
5 行目では、node1 が山田太郎という作業者ノードであ
ることを示している。10行目から12行目までは、アーク
の定義である。例えば10行目では、node1 からnode2 へ
向かうarc1というアークがあることを示している。14行
目から16行目までは、各アークで示される電子メールの
受け渡しに用いられる様式を定義する記述である。例え
ば、14行目は、arc 1 で示される電子メールの受け渡し
が様式「質問票」であることを示している。

【００３４】次に、図１２から図１７までを用いて、生
成手段6 の動作について説明する。生成手段6 は、様式
定義手段3 から図４に例示した様式定義記述を、オブジ
ェクト定義手段4 から図５に例示したオブジェクト定義
記述を、転送順定義手段5 から図１１に例示した転送順
定義記述を、それぞれ受け取る。これら三つの記述はい
ずれも計算機処理が可能な形式的な記述となっているた
め、生成手段6 は各作業者およびソフトウェアオブジェ
クトの間での電子メールの転送順序と、各電子メール転
送における電子メールの受け渡しで用いられる様式を、
容易に判定できる。次に、生成手段6 は、図１１に例示
した転送順定義記述に現れる各作業者に関して電子メー
ル利用環境を生成し、各ソフトウェアオブジェクトに関
して、ソースコードの一部を生成するが、ここでは、作
業者のうち鈴木花子( 図６のノード61c)と、ソフトウェ
アオブジェクトQuestionRecorder (図６のノード61b)を
例にとって、説明する。

【００３５】まず、図１２から図１４までを使って、鈴
木花子の例について説明する。

【００３６】図１２は、本発明のグループウェア開発支
援システムによって開発されたグループウェアを利用す
る各作業者が、グループウェア利用時に用いるソフトウ
ェアの構成例を示すブロック図である。グループウェア
利用ソフトウェア120 は、ワークステーション等の計算
機上で動作するソフトウェアであって、各作業者1 人に
つき、1 個ずつ存在する。作業者は入出力装置128 を介
してグループウェア利用ソフトウェア120 を利用する。
グループウェア利用ソフトウェア120 は、少なくとも環
境解釈手段121 、制御手段122 、ユーザインタフェース
手段123 、電子メール受信手段124 、電子メール送信手
段125 から構成されている。電子メール受信手段124 と
電子メール送信手段125 は、ネットワーク接続装置126
を介してネットワークバス129 と接続されており、他の
作業者の利用するグループウェア利用ソフトウェア、あ
るいはソフトウェアオブジェクトとの間で、各々電子メ
ールの受信と送信が可能である。ユーザインタフェース
手段123 は、入出力装置128 と接続されており、作業者
との間でなされる入出力を一括して管理する。この入出
力には、電子メールの読み書き、制御手段122 に対する
作業者からのコマンド入力、および制御手段122 から作
業者に出力されるメッセージが含まれる。制御手段122
は、電子メール受信手段124 が電子メールを受信した
時、およびユーザインタフェース手段123 が作業者から
のコマンドを受け取った時に起動され、グループウェア
利用ソフトウェア120 に含まれる他の手段を制御し、必
要に応じてユーザインタフェース手段123 を通じて作業
者に対してメッセージを送る。制御手段122 は、これら
の制御やメッセージ出力を行う際、環境解釈手段121 を
通じて外部ファイルである電子メール利用環境定義127
を参照し、制御の方針を決定する。

【００３７】グループウェア利用ソフトウェア120 は以
上のように構成されているので、電子メール利用環境定
義127 の内容によって、グループウェア利用ソフトウェ
ア120 の動作は変化する。この、電子メール利用環境定
義127 を生成することが、生成手段6 の役割である。

【００３８】図１３は図６の例において、作業者鈴木花
子が用いるグループウェア利用ソフトウェア120 の参照
する電子メール利用環境定義127 を、生成手段6 が生成
した電子メール利用環境生成例である。但し、説明の便
宜のため、行番号を付加してある。1 行目と6 行目は、
2 行目から5 行目までの動作を、 ・受信した電子メールの様式が質問票である ・受信した電子メールの差出人がソフトウェアオブジェ
クトQuestionRecordである という二つの条件が成立した時に実行することを示して
いる。ここでReceivedMailは受信した電子メールを示す
語である。2 行目から5 行目までは、その時の具体的な
動作であり、2 行目は受け取った電子メールを作業者に
提示すること、3行目は、回答票を新たに作成し、それ
をA と呼ぶこと、4 行目はA を作業者に編集させるこ
と、5 行目は編集済のA を山田太郎に電子メールとして
送信することを示している。

【００３９】図１４は、図１３に示した内容の電子メー
ル利用環境が生成され、図１２の電子メール利用環境定
義127 として用いられた場合、鈴木花子の利用するグル
ープウェア利用ソフトウェア120 が、作業者鈴木花子に
提示する画面構成の一例を示す図である。画面には質問
回答ウィンドウ141 が現れる。質問回答ウィンドウ141
は、質問票提示サブウィンドウ143,回答票編集サブウィ
ンドウ144 、作業終了ボタン142 から成っており、作業
者鈴木花子は、質問票提示サブウィンドウ143にて提示
されている山田太郎からの質問( 図１３の2 行目に従っ
て表示されたもの) に対して、回答票編集サブウィンド
ウ144 を利用して回答票を編集する( 図１３の3 行目と
4 行目に従って、編集環境が作成される) 。最後に、作
業終了ボタン142 をマウスでクリックすると、編集終了
とみなされ、( 図１３の5 行目に従って) 回答票が山田
太郎に送られる。

【００４０】次に、図１５から図１７までを使って、Qu
estionRecorderの例について説明す。図１５は、本発明
のグループウェア開発支援システムによって開発された
グループウェアを構成するソフトウェアオブジェクトに
関して、ソフトウェアオブジェクトの一実施例を示すブ
ロック図である。ソフトウェアオブジェクト150 は、ワ
ークステーション等の計算機上で動作するソフトウェア
である。ソフトウェアオブジェクト150 は少なくとも電
子メール受信手段154,電子メール送信手段155,制御手段
152,処理手段153,環境解釈手段151 から構成されてい
る。電子メール受信手段154 と電子メール送信手段155
は、ネットワーク接続装置156 を介してネットワークバ
ス159 と接続されており、作業者の利用するグループウ
ェア利用ソフトウェア、あるいは他のソフトウェアオブ
ジェクトとの間で、各々電子メールの受信と送信が可能
である。制御手段152 は、電子メール受信手段154 が電
子メールを受信した時、処理手段153 が処理を終了した
時、あるいは他のイベント(電子メール送信手段155 が
送信に成功あるいは失敗した時、ソフトウェアオブジェ
クト150 がタイマを内蔵している場合には所定の時刻に
なった時等) が発生した時に起動され、ソフトウェアオ
ブジェクト150 に含まれている他の手段を制御し、必要
に応じて処理手段153 に処理を依頼する。また、制御手
段152 は、これらの制御を行う際、環境解釈手段151 を
通じて外部ファイルである電子メール利用環境定義157
を参照し、制御の方針を決定する。処理手段153 は、制
御手段152 から処理を依頼されると、必要に応じて外部
に蓄積されている、単数または複数の処理プログラム15
8 を利用して処理を実行し、処理結果を制御手段152 に
返す。制御手段152 は、処理手段153 に処理を依頼する
時、必要に応じて受信した電子メールを渡す。また、処
理手段153 は処理結果を制御手段152 に返すとき、必要
に応じて、ソフトウェアオブジェクト150 が次に送信し
なければならない電子メールの所定の様式にしたがった
形式に整えてから渡す。処理手段153 が処理プログラム
158 を利用する方式としては、 1. 処理プログラム158 は、それぞれ単体で動作するプ
ログラムとして用意されており、処理手段153 はオペレ
ーティングシステムを介してそれらのプログラムを呼び
出して実行する。 2. 処理プログラム158 は、それぞれプログラムソース
コードの一部として用意されており、処理手段153 の作
成時には、それらのソースコードを内包してコンパイル
され、実行時には処理手段153 の内部に処理プログラム
158 が含まれている。 3. 処理プログラム158 は、それぞれ実行時ライブラリ
として用意されており、処理手段153 の作成時にそれら
のライブラリをリンクする。 4. 処理プログラム158 は、実際にはデータとして用意
されており、処理手段153は、処理実行時に処理プログ
ラム158 を参照・解釈し、処理を実行する。 5. 以上の方式の混在。 等が考えられる。

【００４１】ソフトウェアオブジェクト150 は以上のよ
うに構成されているので、電子メール利用環境定義157
の内容, および処理プログラム158 の内容によって、ソ
フトウェアオブジェクト150 の動作は変化する。これら
の、電子メール利用環境定義157 および処理プログラム
158 を生成することが、生成手段6 の役割である。図１
６は、QuestionRecorderの例に関して、生成手段6 が生
成する電子メール利用環境定義157 の一例である。ただ
し、説明の便宜のため、図１６には、行番号を付加して
ある。1 行目と4 行目は、2 行目と3 行目の動作を ・受信した電子メールの様式が質問票である。

【００４２】・受信した電子メールの差出人が山田太郎
である。 という二つの条件が成立した時に実行することを示して
いる。ここで、ReceivedMailは受信した電子メールを示
す語である。2 行目と3 行目は、その時の具体的な動作
であり、2 行目は処理proc_QuestionRecorder_1 を呼び
出し、ReceivedMailをそのときに渡し、結果をA とする
ことを表している。3 行目は、A を鈴木花子に電子メー
ルとして送信することを示している。

【００４３】図１７は、QeestionRecorderの例に関し
て、生成手段6 が生成する処理プログラム158 の一例で
ある。ただし、説明の便宜のために行番号を付加してあ
る。ここでは、実際には処理プログラム158 としてはC
の関数を生成することにし、処理手段153 の作成時に生
成されたC 関数を同時にコンパイルリンクして、処理手
段153 を得るという方式を採用する事にする。1 行目
は、処理手段153 から呼び出された時に受け渡される電
子メールデータの形式が、質問票型へのポインタである
ことを示している。2 行目から8 行目までは、図５のソ
フトウェアオブジェクトの定義にそのまま対応してい
る。ただし、図５で質問票となっていたものは、図１７
では質問票型へのポインタm となっている。なお、strc
mpは文字列の比較をする標準ライブラリ関数で、文字列
が一致した時に0 を返す。add_db関数は、別に用意され
ているものとする。9 行目は、質問票( ポインタm が指
している) をそのまま処理手段153 に返すことを示して
いる。

【００４４】生成手段6 は、以上に説明したように、作
業者に対しては電子メール利用環境定義127 を、ソフト
ウェアオブジェクトに対しては電子メール利用環境定義
157と処理プログラム158 を生成する。これらの三つの
生成物によって、各作業者の利用するグループウェア利
用ソフトウェア120 と、各ソフトウェアオブジェクト15
0 は、転送順定義手段5 で定義された転送順にしたがっ
た電子メール転送を行う事ができる。また、各ソフトウ
ェアオブジェクト150 はオブジェクト定義手段4 で定義
した処理を開発者の意図にしたがって実行する事ができ
る。

【００４５】次に、請求項2 に記載された第２の発明で
あるグループウェア開発支援システムの実施例について
説明する。第１の発明によるグループウェア開発支援シ
ステムでは、例えば図２から図１７までを用いて説明し
た例では、質問者は常に山田太郎であり、回答者は常に
鈴木花子に固定されてしまう。このような問題を解決す
るのが第２の発明によるグループウェア開発支援システ
ムである。図１８は、第２の発明のグループウェア開発
支援システムの一実施例を示すブロック図である。グル
ープウェア開発支援システム181 は、定義部182 と生成
手段186 からなり、定義部182 は様式定義手段183,オブ
ジェクト定義手段184,転送順定義手段185,役割対応定義
手段186 を含んでいる。定義部182 は入出力装置187 (
例えばディスプレイ、キーポード、マウス) と結合して
おり、本グループウェア開発支援システムの開発者は、
入出力装置187 を通して定義部182 に含まれている四つ
の定義手段を操作し、必要な定義を行うことができる。
様式定義手段183 は、電子メールの様式を定義し、様式
定義を生成手段186 に送る。オブジェクト定義手段184
は、電子メールを少なくとも入力あるいは出力とするソ
フトウェアオブジェクト( 別称；ソフトウェアモジュー
ル) を定義し、その定義を生成手段186 に送る。転送順
定義手段185 は、開発対象システムの複数の役割あるい
は複数のソフトウェアオブジェクトの間で受け渡しされ
る電子メールの転送順と、受け渡し作業毎に用いられる
様式を定義し、その定義を生成手段186 に送る。役割対
応定義手段189 は、転送順定義手段185 での転送順定義
の際に用いた役割名称と、実際の作業者との対応関係を
定義し、生成手段186 に送る。生成手段186 は様式定義
手段183,オブジェクト定義手段184,転送順定義手段185,
役割対応定義手段189 からそれぞれ定義結果を受け取
り、目標システムにおける各作業者の電子メール利用環
境と、各ソフトウェアオブジェクトの少なくとも一部の
動作を決定するコードを生成し、生成結果を記憶装置18
8 に格納する。請求項2 によるグループウェア開発支援
システムは、転送順定義手段185 と役割対応定義手段18
9 を除き他は基本的に請求項1 によるものと同じ( ただ
し、生成手段186 は、役割対応定義手段から役割名称と
作業者個人の名前の対応をさらに受け取る) なので、こ
れら二つの手段についてのみ、実施例を説明する。図１
９は、開発者が、転送順定義手段185 を用いて定義する
転送順の例を示すチャート図である。このチャート図
は、ノードと、ノードを接続するアークからなるグラフ
図であって、191a, 191b, 191c, 191dがノード、192a,
192b, 192cがアークである。ノードのうち、191a, 191
c, 191dは作業者をアイコンで表し、191bはソフトウェ
アオブジェクトを円で表している。193a, 193b, 193c,
193dはノードの名称を示すラベルであり、193a, 193c,
193dは役割の名前、193bはソフトウェアオブジェクトの
名称を示している。アーク192a, 192b, 192cはそれぞれ
ノード間の電子メールの受け渡しを表現している。四角
形194a, 194b, 194cは、それぞれアーク192a, 192b, 19
2cの表現する電子メール受け渡しが様式を持っているこ
とを示し、その様式の名称はそれぞれラベル195a, 195
b, 195cで指定されている。ラベル195a, 195b,195c に
於いて指定されている「質問票」「回答票」という様式
は、様式定義手段183 で定義したものであるが、定義方
法は第１の発明の実施例と同様なので、詳細な説明は省
略する。図２０は、開発者が、役割対応定義手段189 を
用いて定義する役割名称と実際の作業者の名前との対応
表の一例を示したものである。項目201a, 201bは役割の
名称を示し、項目202a, 202bは実際の作業者の名前を示
す。この例では、質問者は実際には山田太郎であり、回
答者は実際には鈴木花子である。よって、図１９，図２
０の如く定義を行った場合、生成されるグループウェア
は第１の発明の実施例にて図１２から図１７を用いて説
明したものと同じである。

【００４６】続いて、請求項3 に記載された第３の発明
であるグループウェア開発支援システムの一実施例につ
いて、図２１から図２２までを用いて説明する。図２１
は、グループウェアの開発者が、第３の発明によるグル
ープウェア開発支援システムを利用した場合、転送順定
義手段を利用して定義する転送順の一例を示すチャート
図である。図６あるいは図１９と同様に、チャート図
は、ノードと、ノードを接続するアークからなるグラフ
図であって、211a, 211b, 211c, 211dがノード、212a,
212b, 212cはアークである。アークは電子メールの受け
渡しを示す。ノードのうち、211a, 211dは作業者であ
り、211b, 211cはソフトウェアオブジェクトである。21
3a, 213b, 213c, 213dはノードの名称を示すラベルてあ
って、213aと213dは役割の名称、213bと213cはソフトウ
ェアオブジェクトの名称である。四角形214aと214cはそ
れぞれアーク212aと212cの表現する電子メールの受け渡
しが様式を持っていることを示し、その様式の名称はそ
れぞれラベル215aと215cで指定されている。ここで、図
２１が図６あるいは図１９と異なる点は、アーク212bの
様式が指定されていないことである。ここでは、様式の
指定のないことを強調するために、アーク212bは破線で
示してある。図２２は、図２１で示したチャート図の表
す転送順に従って第３の発明によるグループウェア開発
支援システムが生成するグループウェアが、アーク212b
に対応して受け渡しする電子メールの一例を示す図であ
る。ただし、図２２では、説明の便宜のため行番号を付
加してある。図２２の電子メールは、ユニックス(UNIX)
等のオペレーティングシステムで利用される電子メール
の形式(RFC822 仕様)に従っている。1 行目から3 行目
までは電子メールのヘッダであり、4 行目はヘッダの終
了を示す空行、5 行目から7 行目までが電子メールの本
文である。1 行目は、電子メールの発信人を示すもの
で、この場合、ソフトウェアオブジェクトReportCollec
tor である。2 行目は電子メールの宛先を示すもので、
この場合、ソフトウェアオブジェクトNotifierである。
3 行目は電子メールの標題であり、この場合、標題はAu
tomatic Reporting Mailとなっている。本実施例では、
転送順定義時に、様式を指定しない電子メールとして定
義されたものについては、自動的にこの標題がつけられ
るものと仮定している。5 行目から7 行目までは、グル
ープウェア開発支援システムによって自動的に生成され
た本文である。5 行目は、図２２の電子メールが通知す
る内容が、報告書様式の電子メールが山田太郎からRepo
rtController(1行目に示された発信人) に、電子メール
の識別コード(message-id) <9303040850.AA01388> で送
られたことであることを示している。なお、山田太郎は
図２１の213aで示される役割「担当者」を実際に受け持
つ作業者の名前であると仮定している。6 行目は、5 行
目で示した事象の発生時刻を示している。7 行目は、転
送順定義の識別番号(scenario-id) が＜g8340398＞であ
ることを示している。本第３の発明によるグループウェ
ア開発支援システムは、図２２に例示される電子メール
がアーク212bに対応する電子メールとして送信されるよ
うなグループウェアを生成する。すなわち、ReportColl
ector を図１５の構造に従って生成する際、処理プログ
ラム158 としては、報告書を担当者から受信した際に起
動されるプログラムとして、以下のステップから成るも
のを生成する。

【００４７】ステップ1:図２２の5 行目から7 行目に相
当する本文を用意する。ただし、5 行目の「＜93030408
50.AA01388>」、6 行目の「Thu, 04 Mar 93 17:50:19 +09
00 」の部分は空欄にしておく。5 行目の「山田太郎」
の部分は役割対応定義手段によって担当者に割り当てら
れた作業者の名前で置き換えておく、7 行目の「＜g834
0398＞」の部分は、転送順定義手段で定義した転送順の
識別名(この識別名は、ここでは転送順定義手段が自動
的に採番したもであるとするが、開発者が命名するよう
な方式をとってもかまわない) に置き換えておく。 ステップ2: 5行目の前記空欄を、ReportCollector が受
け取った電子メールの識別名で置き換える。 ステップ3: 6行目の前記空欄を、ReportCollector が受
け取った電子メールのヘッダに示された時刻に置き換え
る。 ステップ4:ステップ3 までで出来上がった文章をNotifi
erを宛先として、電子メール送信する。

【００４８】また、本第３の発明によるグループウェア
開発支援システムは、ソフトウェアオブジェクトNotifi
erを図１５の構造に従って生成する際、電子メール利用
環境定義157 としては、図２２の形式の電子メールをRe
portCollector から受け取った場合には報告完了通知書
を自動的に作成して報告管理者に送信するような定義を
生成すればよい。

【００４９】次に、請求項4 に記載された第４の発明で
あるグループウェア開発支援システムの一実施例につい
て、図２３から図２４までを用いて説明する。図２３
は、グループウェアの開発者が、本第４の発明によるグ
ループウェア開発支援システムを利用した場合、転送順
定義手段を利用して定義する転送順の一例を示すチャー
ト図である。図６あるいは図１９と同様に、チャート図
は、ノードと、ノードを接続するアークからなるグラフ
図であって、231a, 231b, 231c,231dがノード、232a, 2
32b, 232c はアークである。アークは電子メールの受
け渡しを示す。ノードのうち、231a, 231b, 231dは作業
者であり、233cは会議仮想オブジェクトである。233a,2
33b, 233c, 233d はノードの名称を示すラベルであっ
て、233a, 233b, 233dは役割の名称、233cは会議仮想オ
ブジェクトの名称である。四角形234a, 234b, 234cはそ
れぞれアーク232a, 232b, 232c で示される電子メール
の受け渡しにおいて様式が指定されていることを示し、
その様式はラベル235a, 235b, 235cでそれぞれ指定され
ている。これら三つの様式、すなわち市場動向報告書、
為替動向報告書、議事録については様式定義手段ですで
に定義されているものとする。図２３においては、会議
仮想オブジェクト231cが用いられている点が図６あるい
は図１９と異なるので、ここでは、会議仮想オブジェク
トについてのみ説明する。会議仮想オブジェクトは、入
力される電子メールを会議参加者全員に配布し、会議終
了後に議事録を作成する環境を作業者に提供するオブジ
ェクトである。すでに、図５を用いて説明したように、
ソフトウェアオブジェクトは、オブジェクト定義手段に
よって定義されるが、本実施例においては、これと同様
の方法で会議仮想オブジェクトの定義が行えるようにす
るため、オブジェクト定義手段に会議仮想オブジェクト
の定義機能を付加してあるものとする。

【００５０】図２４は、会議仮想オブジェクトをオブジ
ェクト定義手段を利用して定義した例である。ただし、
図２４では説明の便宜のため、行番号を付加してある。
1 行目は会議仮想オブジェクトの定義開始宣言であり、
その名称がStrategicMeetingであることを示している。
2 行目は、会議仮想オブジェクトが受け取る電子メール
の様式の指定である。すなわち、この会議仮想オブジェ
クトは、市場動向報告書と為替動向報告書の様式で書か
れた二つの電子メールを受け取ると、会議の開始できる
状態になる。4 行目は、会議の出席者を役割の名称で示
している。すなわち、この会議には、議長、書記、市場
動向報告者、為替動向報告者、営業課長、販促課長の6
人が出席することが示されている。5 行目は会議の出力
である電子メールを作成する作業者が指定されている。
この場合は書記が会議の出力である電子メールを作成す
る。7 行目は、会議の出力である電子メールの様式が議
事録であることを示している。生成手段は、図２３およ
び図２４のように定義された会議仮想オブジェクトに対
応して、以下に述べるような方式のグループウェアを生
成する。

【００５１】・転送順定義における会議仮想オブジェク
トの位置に、ソフトウェアオブジェクトを一つ生成す
る。これが会議仮想オブジェクトStrategicMeetingを実
現する実体であり、名称もStrategicMeetingとする。St
rategicMeetingの構造は図１５に示したものと同じであ
る。 ・StrategicMeetingの電子メール利用環境定義157 に
は、図２５に例として示すコードを生成する。図２５に
ついては後述する。 ・StrategicMeetingの処理プログラム158 には特に何も
定義しない。 ・書記のグループウェア利用ソフトウェアは、図１２に
示した構造で生成される。書記の電子メール利用環境定
義127 には、図２６に例として示すコードを生成する。
図２６については後述する。

【００５２】図２５、および図２６の説明に入る前に、
本実施例での役割対応定義についての仮定を行う。ここ
では、市場動向報告者が佐藤幸三、為替動向報告者が福
田孝司、議長が田中美佐子、書記が中川二郎、営業課長
が矢野昭子、販促課長が小川通夫、営業担当重役が鈴木
花子と、それぞれ定義されているものとする。図２５
は、StrategicMeetingの電子メール利用環境定義157 に
対して生成されるコードの一例である。ただし、説明の
便宜のため行番号を付加してある。1 行目は使用する変
数の初期化であり、m とn をそれぞれ0 に設定してい
る。BEGINは予約語であり、StrategicMeeting が動作
開始時にBEGIN の直後の｛｝内のコードを実行すること
を示している。2 行目から5 行目までは、市場動向報告
書を佐藤幸三( 市場動向報告者) から受け取った場合の
動作を示している。ここで、ReceivedMailは、図１３，
図１６の場合と同様に受信したメールを示す語である。
3 行目は、受信したメールを変数X に一時退避してい
る。4 行目は変数m を一増やすことを示している。6 行
目から9 行目までは、為替動向報告書を福田孝司( 為替
動向報告者) から受け取った場合の動作を示している。
7 行目は受信したメールを変数Y に退避している。8 行
目は変数n を一増やすことを示している。10行目から14
行目は、市場動向報告書と為替動向報告書が出揃ったと
きのStrategicMeegting の動作を示している。二つの報
告書が揃うと、m とn が共に正数になるため、10行目の
if条件が成立し、11行目から15行目までが実行される。
11行目は変数m とn をともに0 にリセットする。12行目
では、X に退避した市場動向報告書を佐藤幸三以外の会
議参加者に送付する。13行目では、Y に退避した為替動
向報告書を福田孝司以外の会議参加者に送付する。14行
目は議事録様式の電子メールを作成し、それをA とす
る。15行目はA を中川二郎( 書記) に送る。なお、図２
５においては、2 行目で市場動向報告書の条件につい
て、6 行目で為替動向報告書の条件について記述してい
るが、これは市場動向報告書を為替動向報告書よりも早
く受信しなければならないという意味ではない。利用環
境定義は、逐次実行されるものではなく、成立した条件
(BEGIN等の予約語と、ifの直後に示される条件とを含
む) に対応する実行文がいつでも実行されるものであ
る。したがって、市場動向報告書と為替動向報告書はど
ちらが先にStrategicMeetingに受信されてもよく、両方
が出揃った時点でm とn が共に正になる。図２６は、書
記である中川二郎の利用するグループウェア利用ソフト
ウェアのために生成される電子メール利用環境定義127
のコードの一例である。ただし、説明の便宜のために行
番号を付加してある。中川二郎は、StrategicMeetingか
ら議事録を受け取ると、それをいつでも編集することが
でき(2行目) 、編集後は営業担当重役である鈴木花子に
それを送付する(3行目) 。

【００５３】以上のように生成されたグループウェアを
利用すると、市場動向報告書と為替動向報告書が出揃っ
た時点でいつでも会議を開くことができ、議事録もすぐ
に編集して報告先( この例の場合、営業担当重役) に間
違いなく送ることができる。

【００５４】次に、請求項5 に記載された第５の発明で
あるグループウェア開発支援システムの一実施例につい
て図２７を用いて説明する。第５の発明によるグループ
ウェア開発支援システムは、第４の発明によるグループ
ウェア開発支援システムに、会議の実現方法としてオン
ラインリアルタイム会議システムの利用を可能とする機
能を付加したものである。オンラインリアルタイム会議
システムとしては、例えば、MERMAID がある。MERMAID
については、例えば情報処理学会論文誌の第32巻第9 号
の1200ページから1209ページに記載されている。MERMAI
D を利用すると、会議参加者は、ワークステーションを
利用して在席したまま他の会議参加者とマルチメディア
ネットワークを通じて会話できる他、会議を行いながら
一人で、あるいは他の会議参加者と共同で、ワークステ
ーションに蓄積されている文書の編集を行うことができ
る。また、MERMAID には、議長が他の参加者に呼び掛け
て会議を召集する機能がある。図２７は、既に説明した
図２３の転送順定義に従った一連の作業において、会議
仮想オブジェクト231cの実現方法としてMERMAID を利用
する場合の、会議仮想オブジェクト231 c の図２４に代
わるオブジェクト定義記述例である。但し、説明の便宜
のため、図２７においては行番号を付加してある。図２
７の1,2,5,9 行目は、それぞれ図２４の1,2,4,7 行目と
同じである。3 行目は、会議ツールとしてMERMAIDを使
用することを示している。6 行目は、会議の召集者が議
長であることを示している。7 行目は、議事録の作成
が、書記と営業課長の共同で行われることを示してい
る。生成手段は、図２３と図２７で定義された会議仮想
オブジェクトに対応して、以下に述べるような方式のグ
ループウェアを生成する。

【００５５】・転送順定義における会議仮想オブジェク
トの位置に、ソフトウェアオブジェクトを一つ生成す
る。これが会議仮想オブジェクトStrategicMeetingを実
現する実体であり、名称もStrategicMeetingとする。St
rategicMeetingの構造は図１５に示したものと同じであ
る。 ・StrategicMeetingの電子メール利用環境定義157 に
は、図２８に例として示すコードを生成する。図２８に
ついては後述する。 ・StrategicMeetingの処理プログラム158 には特に何も
定義しない。 ・議長のグループウェア利用ソフトウェアは、図１２に
示した構造で生成される。議長の電子メール利用環境定
義127 には、図２９に例として示すコードを生成する。
図２９については後述する。 ・議長用のMERMAID 初期化ファイルには、図２７の5 行
目で示された参加者を登録する。( 本実施例の生成手段
は、これまでの実施例の生成手段に加えて、MERMAID 初
期化ファイルの生成機能が付加されていなければならな
い) ・書記のグループウェア利用ソフトウェアも、図１２に
示した構造で生成される。書記の電子メール利用環境定
義127 には、図３０に例として示すコードを生成する。
図３０については後述する。 ・書記用のMERMAID 初期化ファイルには、議事録( 図３
０で/tmp/foobar というファイル名となっているので、
正確にはこのファイル) を営業課長とで編集する旨を記
しておく。

【００５６】なお、上記説明文で、MERMAID の初期化フ
ァイルとは、MERMAID の立ち上げ時に参照されるファイ
ルであって、会議の参加者のリスト、共同編集する文書
ファイルのリスト等の情報を含んだものである。図２
８，図２９、および図３０の説明に入る前に、本実施例
での役割対応定義についての仮定を行う。ここでは、図
２５，図２６の場合と同様に、市場動向報告者が佐藤幸
三、為替動向報告者が福田孝司、議長が田中美佐子、書
記が中川二郎、営業課長が矢野昭子、販促課長が小川通
夫、営業担当重役が鈴木花子と、それぞれ定義されてい
るものとする。図２８は、StrategicMeetingの電子メー
ル利用環境定義157 に対して生成されるコードの一例で
ある。ただし、説明の便宜のため行番号を付加してあ
る。図２８は図２５と同一である。図２９は、議長であ
る田中美佐子の利用するグループウェア利用ソフトウェ
アのために生成される電子メール利用環境定義127 のコ
ードの一例である。ただし、説明の便宜のために行番号
を付加してある。1 行目は変数m とn を0 に初期化して
いる。2 行目から7 行目までは、StrateticMeetingから
市場動向報告書と為替動向報告書が送られて来るのを待
っている。両方の報告書が送られて来るとmとn が双方
とも正数となり、9,10行目が実行される。9 行目はm と
n を0 に再初期化する。10行目のappend_menu は、ユー
ザインタフェース手段123 に、新たなグラフィクユーザ
インタフェースによるメニューを追加することを示す。
このメニューの名称はMERMAID であり、このメニューを
選択するとコマンドmermaid が実行され、実行終了時に
は変数T が真になることを示している。12行目では、該
変数T が真であるかどうかをチェックしている。T が真
であれば、すなわちmermaid コマンドの実行が終了して
いれば、13行目と14行目を実行する。13行目は、作業の
完了を示す様式のない電子メールを自動的に生成し、そ
れをX とすることを示している。14行目は、X を書記中
川二郎に送っている。図３０は、書記である中川二郎の
利用するグループウェア利用ソフトウェアのために生成
される電子メール利用環境定義127 のコードの一例であ
る。ただし、説明の便宜のために行番号を付加してあ
る。1 行目の条件が成立すると、すなわち、議事録をSt
rategicMeetingから受け取ると、2 行目の定義により、
それを一旦ファイル/tmp/foobar に格納する。このファ
イル名"/tmp/foobar" は生成手段が自動的に決定したも
のである。4 行目の条件は、議長田中美佐子からSIGNAL
形式（様式定義のない電子メールをSIGNAL形式の電子メ
ールと呼ぶことにする）の電子メールを受け取ったとき
に成立する。すなわち、図２９の定義によればSIGNAL形
式の電子メール(X) は会議の終了したときに送られるも
のであるから、図３０の4 行目の条件は会議の終了した
後に成立する。会議の終了した時点で、議事録は完成し
ている( なぜならば、書記用のMERMAID 初期化ファイル
の指定により、議事録は営業課長との共同編集でMERMAI
D 中で作成されているからである) 。5行目は、完成し
た議事録ファイル/tmp/foobar を読みだして、それをC
とすることを示している。6 行目は、議事録C を営業担
当重役鈴木花子に送ることを示している。

【００５７】引き続いて、請求項6 に記載された第６の
発明であるグループウェア開発支援システムの実施例に
ついて、図３１から図３４までを用いて説明する。図３
１は、本第６の発明によるグループウェア開発支援シス
テムの一実施例において、開発者が転送順定義手段を用
いて定義する転送順の一例を表すチャート図である。図
３１はノードとアークからなるグラフ図であって、311
a, 311b, 311c, 311d,311e がノード、312a, 312b, 312
c, 312dがアークである。ノードのうち、311a,311b,311
e は作業者を表し、311c, 311dはソフトウェアオブジェ
クトを表す。313a, 313b,313c, 313d, 313e はノードの
ラベルであり、このうち313a, 313b, 313eは役割の名称
を示し、313c, 313dはソフトウェアオブジェクトの名称
を示す。アークのうち、312a,312b, 312d は電子メール
の受け渡しを示し、四角形314a,314b, 314dはそれぞれ
アーク312a, 312b, 312 d で示される電子メールの受け
渡しには様式が指定されていることを示し、アークのラ
ベル315a, 315b, 315dはそれらの様式が各々テスト実績
報告書、予算実績報告書、出荷可能性報告書であること
を示している。これらの様式は既に様式定義手段を用い
て定義済であると仮定する。アーク312cは協調を意味す
る相互関係を定義するものである。ここで、協調とは、
第一に、互いに自己の目標を持つ複数のソフトウェアオ
ブジェクトが、各々が自己の目標を達成するために何ら
かのソフトウェア実行を行う場合に、各ソフトウェアオ
ブジェクトにおける目標の達成が他のソフトウェアオブ
ジェクトの目標の達成と同時には実現できない場合に、
目標の調整を自動的に行うことをいう。また、第二に、
ある自己の目標を持つソフトウェアオブジェクトが、目
標達成のための手段あるいはソフトウェア実行方式のす
べてを自身では持たない場合に、その目的達成のための
助力をする手段を持つ他のソフトウェアオブジェクトに
助力を求める仕組みのことを言う。このような協調を行
うソフトウェアオブジェクトの構成方式は一通りではな
いが、その方式の例は、例えば近代科学社刊「レクチャ
ーノートソフトウェア工学２、マルチエージェントと協
調計算１」( 中島秀之編、ISBN 4-7649-0202-8) に多数
示されている。図３１の例は、ソフトウェアの品質と予
算の管理に関わる一連の作業を表したもので、上記第一
の協調の定義の一例になっている。一般にソフトウェア
の出荷の前には、テストの実績から品質を予測し、出荷
できる品質に達してるかどうかの判断が必要である。一
方、品質を上げるためにはテスト工数が必要で、限られ
た予算ではテストの実績を積んで品質を上げようにも限
度がある。図３１において、ソフトウェアオブジェクト
QualityManager 311c は、テスト実績報告書を受け取っ
て、品質を予測し、品質が低ければより多くのテストが
必要と判断する。すなわち、QualityManager 311c の自
己の目標とは、品質の向上である。一方、ソフトウェア
オブジェクトBudgetManager 311d は、予算実績報告書
を受け取って予算の消化状況を監視し、できるだけ低い
予算で出荷しようとする。すなわち、BudgetManager 31
1dの自己の目標とは、コストダウンである。よって、Qu
alityManager 311c とBudgetManager 311dのそれぞれの
自己の目標は、同時には達成することができないので、
目標のレベルを調整する協調活動がこれら二つのソフト
ウェアオブジェクトの間で必要である。協調の結果、出
荷の可否および出荷までに必要な予算の見積が出来上が
ると、BudgetManager 311dは結果を出荷可能性報告書と
して生成し、出荷担当者311eに電子メールとして送信す
る。図３２は、図３１の311c, 311dのように協調活動を
行うソフトウェアオブジェクトの構成の一例を示すブロ
ック図である。図１５と異なるのは、ソフトウェアオブ
ジェクト1 50aの内部にプラン生成手段321,協調手段322
が追加されたことである。環境定義手段151a, 制御手
段152a, 電子メール受信手段154a, 電子メール送信手段
155a, ネットワーク接続装置156a、電子メール利用環境
定義157a, 処理プログラム158a, ネットワークバス159a
は、それぞれ図１５の環境定義手段151,制御手段152,電
子メール受信手段154,電子メール送信手段155,ネットワ
ーク接続装置156、電子メール利用環境定義157,処理プ
ログラム158,ネットワークバス159 と同じものである。
処理手段153aは、図１５の処理手段153 の機能に加え
て、プラン生成手段321 に目標を与えて起動する機能を
追加として持っている。プラン生成手段321 は、処理手
段153aから起動されると、目標を達成するための計画(
プラン) を作成し、目標の達成が可能ならば目標を協調
手段322 に通知する。協調手段322 はプラン生成手段32
1 から目標を通知されると、外部のソフトウェアオブジ
ェクトとの間で協調活動を行う。協調活動は、物理的に
はネットワークを介して行われるので、ネットワーク接
続装置156aを利用することになる。協調手段322 は、協
調活動が終了すると、協調結果として目標が変更された
場合は、変更後の目標をプラン生成手段321 に返す。プ
ラン生成手段321 は協調手段322から変更後の目標を渡
されると、変更後の目標を実現するプランの作成が可能
かどうかを調査し、可能でなければ再度目標を修正して
協調手段322 に渡す。このようにプラン生成手段321 と
協調手段322 の間では何回か目標の修正が行われるが、
最終的に目標とプランが決定すると、プラン決定手段32
1 は処理手段153aに最終的に決定した目標とプランを返
す。また、最終的に目標の達成が不可能な場合( 例え
ば、協調相手のソフトウェアオブジェクトとの間で目標
の折り合いがつかない場合) 、目標達成不可能な旨を処
理手段153aに返す。

【００５８】図３３は、図３１の二つのソフトウェアオ
ブジェクトのうち、BudgetManagerに関して、開発者が
オブジェクト定義手段を用いて定義した、オブジェクト
定義の一例である。ただし、説明の便宜のため行番号を
付加してある。1 行目は、オブジェクトの名前BudgetMa
nager を定義している。2 行目は本オブジェクトは入力
として予算実績報告書を電子メールで受け取ることを示
しており、定義中ではy で参照することを宣言してい
る。4 行目から12行目までは、本オブジェクトで実行さ
れるソフトウェアプログラムによる処理を定義してい
る。5 行目から6 行目までは変数宣言であり、5 行目で
は整数x を、6 行目では「出荷可能性報告書」型へのポ
インタa を宣言している。8 行目のcall_coordination
は、プラン生成手段の呼び出しを示している。呼び出し
の第一パラメータのMINIMIZEはcall_coordination 専用
の予約語で、第二パラメータで渡される値を最大値とし
てできるだけ小さい値を最終結論として得ることを、本
オブジェクトの協調時の目標とすることを示すものであ
るとする。この、第二パラメータは、予算実績報告書に
記された「残余予算」欄に示される金額を、工数( 人
時) の値に換算したものであるとする。MANHOUR_YEN は
換算のために用いる定数である。協調の結果はx に代入
される。ただし、協調に失敗したときは負の値が入る。
9 行目は、出荷可能性報告書の様式を新たに生成し、そ
れをa で参照することを示している。10行目は、出荷可
能性報告書の「可否」欄に、x が正またはゼロならば"y
es" を、x が負ならば"no"を書き込むことを示してい
る。11行目は、出荷可能性報告書の「要求工数」欄に、
x の値を書き込むことを示している。14行目は、本オブ
ジェクトの出力が出荷可能性報告書様式の電子メール
で、定義中ではa で参照されたものであることを示す。
15行目は、オブジェクト定義の終了を示す。

【００５９】図３３のオブジェクト定義を受け取った生
成手段は、BudgetManager の処理プログラム158aとして
例えば図３４のようなコードを出力する。ただし、図３
４では、説明の便宜のため、行番号を付加してある。図
３４は、図３３の4 行目から12行目の部分をC 言語の関
数形式として整えたものである。ただし、5 行目では、
転送順定義から得られる情報を利用して、協調の相手が
QualityManagerであることを指定している。また、10行
目では、a を返却値として制御手段152aに返すことを指
定している。

【００６０】この例における協調は以下のように実施さ
れる。BudgetManager は図３４の5行目で示されるよう
に、残余予算で使える工数を最大値として、できるだけ
少ない工数投入で済ませるという目標を持っているが、
一方のQualityManagerは、基準品質を維持するのに最低
必要な工数を最小値として、できるだけ多くの工数を品
質向上のために投入するという目標を持つ。BudgetMana
ger とQualityManagerは、この両方の目標が成立するよ
うに、最終的な投入工数を決定する。その決定方法に関
しては、プラン生成手段321 と協調手段322 の実現方式
により様々であるが、この場合単純には、例えば「Budg
etManager の許容する最大値が、QualityManagerの要求
する最小値と比較して大きいか等しければ、両者の平均
を結論とし、さもなければ協調不可能とする」のような
方式であっても構わない。

【００６１】図３１の例では、協調を行うソフトウェア
オブジェクトは2 個であったが、3個以上の例も可能で
ある。

【００６２】次に、請求項7 に記載された第７の発明で
あるグループウェア開発支援システムの一実施例につい
て、図３５から図３８までを用いて説明する。

【００６３】これまでの実施例の説明では、目標システ
ムの利用時に、作業者が用いるグループウェア利用ソフ
トウェアの構成は、図１２のごときものであると仮定し
てきた。図１２の構成は、計算機のオペレーティングシ
ステムとして主にユニックス(UNIX)を仮定している。し
かし、実際には作業者によっては日常作業に異なるオペ
レーティングシステム、例えばマイクロソフト社のウィ
ンドウズ(MS-Windows)を使用している場合がある。すべ
ての作業者に対して同一の計算機やオペレーティングシ
ステムを使用させるのは設備投資や習慣性の問題から現
実的には無理があるため、グループウェアは異なる計算
機、オペレーティングシステム間で利用できることが望
ましい。

【００６４】また、同じオペレーティングシステムであ
っても、例えばエディタにはいくつかの種類があり、利
用者によって好みのものを用いているという現実があ
り、グループウェアは作業者の用いるエディタの種類に
関わらず利用できることが望ましい。さらに、異なる計
算機は異なるネットワークに接続されていることがある
ため、グループウェアの用いる電子メールは、異なるネ
ットワークの間で通信できることが望ましい。以下に述
べる、本第７の発明によるグループウェア開発支援シス
テムの実施例は、作業者の用いるオペレーティングシス
テム、エディタの違い、作業者の用いる計算機の接続さ
れているネットワークの違い等をグループウェアの開発
時にあらかじめ定義しておくことにより、適切なグルー
プウェアを生成できるようにしたものである。図３５
は、本第７の発明によるグループウェア開発支援システ
ムの一実施例を示すブロック図である。図３５は、図１
に作業者環境定義手段359 を追加した形になっている。

【００６５】グループウェア開発支援システム351 は、
定義部352 と生成手段356 からなり、定義部352 は様式
定義手段353,オブジェクト定義手段354,転送順定義手段
355,作業者環境定義手段359 を含んでいる。定義部352
は入出力装置357(例えばディスプレイ、キーボード、マ
ウス) と結合しており、本グループウェア開発支援シス
テムの利用者たる開発者は、入出力装置357 を通して定
義部352 に含まれている四つの定義手段を操作し、必要
な定義を行うことができる。様式定義手段353,オブジェ
クト定義手段354,転送順定義手段355 は、それぞれ図１
で説明した様式定義手段3,オブジェクト定義手段4 , 転
送順定義手段5 と同じものであっても構わない。作業者
環境定義手段359 は、グループウェアの開発者が、各作
業者の利用する個別の計算機およびネットワークの種
類、および各作業者の利用する個別の編集プログラムや
電子メール利用環境等の嗜好等を含む作業者環境を定義
するために用いるものである。ここでは、これらを総称
して作業者環境定義と呼ぶ事にする。生成手段356 は様
式定義手段353,オブジェクト定義手段354,転送順定義手
段355,作業者環境定義手段359 からそれぞれ定義結果を
受け取り、目標システムにおける各作業者の電子メール
利用環境と、各ソフトウェアオブジェクトの少なくとも
一部の動作を決定するコードを生成し、生成結果を記憶
装置358 に格納する。

【００６６】図３６は、開発者が、入出力装置367 を介
して作業者環境定義手段357 を用いて作業者環境の定義
を行う場合の、画面の一例を示す画面図である。画面36
1 はマルチウィンドウシステムによる表示を行ってお
り、その中には作業者環境定義ウィンドウ362 が表示さ
れている。作業者環境定義ウィンドウ362 を利用して行
う作業者環境定義は、表形式で行うことになるが、この
表は、363, 364, 365, 367, 328 の５つの列から成って
いる。各列とも、第一行は列の定義内容を示すラベルで
あり、第二行以降が実際の定義である。

【００６７】列363 は、作業者名を記入する列である。
この例では山田太郎と鈴木花子の二人の作業者に関する
定義を行っている。列364 には各作業者が使用するマシ
ンの名前を記入する。この例では、山田太郎がcsls23,
鈴木花子がkclpc1というマシンを使用することが定義さ
れている。ただし、鈴木花子の使用するkclpc1は、別の
マシンkcls1 に接続して使用されることがカッコ内に示
されている。このように記述された場合には、鈴木花子
のグループウェア利用ソフトウェアはkclpc1を端末側、
kcls1 をホスト側とする二つのマシンで構成されること
になる。詳しくは図３７を用いて後に詳述する。列365
では、各作業者の用いるマシンのオペレーティングシス
テム(OS)を定義する。この場合、山田太郎の用いるオペ
レーティングシステムはUNIX、鈴木花子の用いるオペレ
ーティングシステムはkclpc1がWindows で、kcls1 がUN
IXである。列366 では、各作業者の用いるマシンの接続
されているネットワークの名称を定義する。この場合、
csls23の接続されているのはcs-net、kcls1 の接続され
ているのはobp-net である。kclpc1はkcls1 に接続され
ているため、ネットワークには直接接続されない。列36
7 では各作業者の用いるエディタの名称を定義する。こ
の場合、山田太郎が用いるのはＧ社エディタ、鈴木花子
の用いるのはＪ社エディタである。

【００６８】図３７は、図３６の作業者環境定義で鈴木
花子の例に示されたように、作業者のグループウェア利
用ソフトウェアを二つのマシンで構成する場合の、構成
を示すブロック図である。グループウェア利用ソフトウ
ェアは、3700a と3700b の二つから構成されている。こ
のうち、3700a はホスト側のマシン、すなわち図３６に
定義された鈴木花子の環境ではkcls1 上で実現される部
分である。一方、3700b は、端末側のマシン、すなわち
図３６に定義された鈴木花子の環境ではkclpc1で実現さ
れる部分である。両者は通信手段3710a,3710b を用いて
相互に通信可能である。グループウェア利用ソフトウェ
アのうち3700a は、少なくとも、環境解釈手段3701, 制
御手段3702、通信手段3710a,電子メール受信手段3704,
電子メール送信手段3705から構成されている。電子メー
ル受信手段3704と電子メール送信手段3705は、ネットワ
ーク接続装置3706を介してネットワークバス3709と接続
されており、他の作業者の利用するグループウェア利用
ソフトウェア、あるいはソフトウェアオブジェクトとの
間で、各々電子メールの受信と送信が可能である。制御
手段3702は、電子メール受信手段3704が電子メールを受
信した時、および通信手段3710a が作業者からのコマン
ドを受け取った時に起動され、グループウェア利用ソフ
トウェア3700a に含まれる他の手段を制御し、必要に応
じて通信手段3710a を介して作業者に対してメッセージ
を送る。制御手段3702は、これらの制御やメッセージ出
力を行う際、環境解釈手段3701を通じて外部ファイルで
ある電子メール利用環境定義3707を参照し、制御の方針
を決定する。通信手段3710a,3710b の間の通信方法に
は、シリアルラインインタフェースを用いる方法、ネッ
トワークバス3709を用いる方法等多数あるが、いずれに
せよ、通信手段3710a, 3710bを通じて、制御手段3702は
ユーザインタフェース手段3703に指令やデータを送った
り、ユーザインタフェース手段3703からユーザコマンド
やデータを受け取ったりすることができる。ユーザイン
タフェース手段も3703は、入出力装置3708を介して作業
者との対話を行うことができる。

【００６９】図３８は、図３６による作業者環境定義
と、図６による転送順定義を生成手段に入力した場合、
生成手段から出力される、鈴木花子用の電子メール利用
環境定義3707の一例を示す図である。ただし、図３８で
は説明の便宜のため、行番号を付加してある。

【００７０】図３８は、図１３で示した例と一部を除い
て同じである。1 行目のIF_NODE=kclpc1は、鈴木花子の
グループウェア利用ソフトウェアが、インターフェース
ノード( すなわち、端末) マシンとして、kclpc1を利用
することを示している。また、1 行目のOS=Windows, ED
ITOR= Ｊ社エディタは、kclpc1のOSがWindows であり、
鈴木花子の利用するエディタがＪ社エディタであること
を示している。3 行目から6 行目までおよび8 行目は、
図１３の1 行目から4 行目までおよび6 行目と同じであ
る。7 行目では、山田太郎の存在するネットワーク名の
情報をメールの送り先情報として付加している。制御手
段3702は、図３８に示された電子メール利用環境定義の
情報を用いて、制御を実行する。例えば、図３８の6 行
目を実行するとき、A の編集はホスト側のマシンだけで
は行えないので、以下の手順を実施することになる。 1. 端末マシンkclpc1を探し、通信手段3710a, 3710bを
通じて接続する。 2. kclpc1のユーザインタフェース手段3703に、A を送
信する。 3. kclpc1上でＪ社エディタ( 図３７には示されていな
いが、マシンkclpc1で利用可能な形で準備されているも
のとする) を立ち上げ、A を編集するように、ユーザイ
ンタフェース手段3703に指令する。 4. 編集が終了したらユーザインタフェース手段3703か
ら編集済のA を受け取る。なお、本実施例では、主に端
末側に関する情報( 例えば使用するエディタ名) も、ホ
スト側で用いる電子メール利用環境定義3707の一部とし
て生成する方式をとっているが、端末側のグループウェ
ア利用ソフトウェア3700b にも別の電子メール利用環境
定義ファイルを接続し、該端末側の電子メール利用環境
定義ファイルに対して、端末側に関する情報を生成する
という方式をとることもできる。

【００７１】次に、請求項8 に記載された第８の発明で
あるグループウェア開発支援システムの一実施例につい
て、図３９から図４１までを用いて説明する。

【００７２】図３９は、グループウェアの開発者が、本
第８の発明によるグループウェア開発支援システムを利
用した場合、転送順定義手段を利用して定義することの
できる転送順の一例を示すチャート図である。チャート
図は、ノードと、ノードを接続するアークからなるグラ
フ図であって、391a, 391b, 391c, 391dがノード、392
a, 392b, 392cがアークである。ノード391a, 391dは作
業者、391b, 391cはソフトウェアオブジェクトである。
ラベル393a, 393b, 393c, 393dはノードの名称を示すラ
ベルであって、393a, 393dは作業者の役割の名称を、39
3b, 393cはソフトウェアオブジェクトの名称を、それぞ
れ示している。四角形394a, 394cはそれぞれアーク392
a, 392cでそれぞれ示された電子メールの受け渡しが様
式を持つことを示し、その様式名は、ラベル395a,395c
で示されている。アーク392bは破線で示されているが、
これは、図２１のアーグ212bと同様に、様式が示されて
おらず、すなわち、このアークに対応する電子メールは
ソフトウェアオブジェクト391bの動作の完了時に自動的
に送られるものである。

【００７３】図３９においては、ソフトウェアオブジェ
クト391bには入力が存在していないが、ここでは、ソフ
トウェアオブジェクト391bには、ある指定された時刻を
待つという手続きが定義されているものとする。該手続
きはオブジェクト生成時に起動され、該時刻が来ると終
了するものとする。すなわち、アーク392bで表現される
電子メールは、ある指定時刻になると送られるものとす
る。図４０は、図３９のチャート図で示される転送順定
義に関して、MailDelayerソフトウェアオブジェクト391
cのオブジェクト定義を行った例である。ただし、説明
の便宜のため、行番号を付加してある。1 行目はオブジ
ェクトの名称である。2 行目は、MailDelayer が二つの
入力を持つことを示している。そのうちの一つはTrigge
rMakerから送られてくるSIGNAL (自動的に生成された電
子メール)であることを示している。ここで、カッコ書
きは電子メールの発信元を特に示したいときに用いるも
のとする。3 行目は出力が報告書であることを示し、4
行目は、オブジェクトの定義の終了を示す。

【００７４】図４１は、図３９のチャート図で示される
転送順定義と、図４０で示されるMailDelayerのオブジ
ェクト定義を生成手段に与えた場合に、生成手段が生成
する、MailDelayerの電子メール利用環境定義の一例を
示す図である。ただし、説明の便宜のため行番号を付加
してある。また、役割対応定義として、担当者は山田太
郎、報告管理者は鈴木花子と、それぞれ定義されている
ものと仮定している。ここで、電子メールの待ち合わせ
を実現している方式は図２５および図２８で示したもの
と同じである。まず、1 行目は使用する変数の初期化で
あり、m とn をそれぞれ0 に設定している。BEGIN は予
約語であり、動作開始時にBEGIN の直後の｛｝ 内のコ
ードを実行することを示している。2 行目から5 行目ま
では、報告書を担当者である山田太郎から受け取った場
合の動作を示している。ReceivedMailは受け取ったメー
ルを示す語である。3 行目は、受け取ったメールをA と
いう内部変数に一旦蓄積することを示している。4 行目
は、変数m を一増やすことを示している。6 行目から8
行目までは、TriggerMaker からSIGNAL型の電子メール
を受け取ったときの動作を示しているが、このときの動
作は、7 行目に記されているように、n を一増やすこと
だけである。9 行目から12行目までは、SIGNAL型のメー
ルと報告書とを両方受け取った後に行われる動作を示し
ている。二つの電子メールが揃うと、m とn が共に正数
になるため、9 行目のif条件が成立し、10行目と11行目
が実行される。10行目は変数m とn を共に0 にリセット
する。11行目は、先にA として保存しておいた報告書を
鈴木花子に送信する。

【００７５】なお、図４１においては、2 行目で報告書
の条件について、6 行目でSIGNAL型メールの条件につい
て記述しているが、これは報告書をSIGNAL型メールより
も早く受信しなければならないという意味ではない。利
用環境定義は、逐次実行されるものではなく、成立した
条件(BEGIN等の予約語と、ifの直後に示される条件とを
含む) に対応する実行文がいつでも実行されるものであ
る。したがって、報告書とSIGNAL型メールはどちらが先
にMailDelayer に受信されてもよく、両方が出揃った時
点でm とn が共に正になる。

【００７６】以上のように生成されたグループウェアを
利用すると、複数の電子メールの待ち合わせが実現でき
るので、より複雑な転送順を定義できることになる。

【００７７】次に、図４２から図４５までを用いて、請
求項9 に記載された第９の発明であるグループウェア開
発支援システムの一実施例を説明する。

【００７８】図４２は、本第９の発明によるグループウ
ェア開発支援システムで利用可能な、転送順のパターン
の一例を示すチャート図である。このようなパターン
は、あらかじめ転送順定義手段を用いて、定義・登録を
行っておくことになる。これまでと同様に、図４２はノ
ードとアークからなるグラフ図であって、421a, 421b,4
21cがノード、422a, 422b, 422c, 422d, 422eがアーク
である。三角形427a, 427bもノードであるが、これらは
パターン定義の場合に特有に用いられるもので、外部と
の結合端子である。427aは入端子、427bは出端子であ
る。ノード421a, 421b, 421cはいずれも作業者であり、
ラベル423a, 423b, 423cはそれぞれノード421a, 421b,
421cの役割名称を示す。この例の場合、ラベル423aと42
3cは同一であり、すなわち、421aと421cは同一人物を表
すノードである。アークのうち、422b, 422c, 422dはそ
れぞれ電子メールの受け渡しを示すアークであり、四角
形424b, 424c, 424dによってそれらはいずれも様式を持
つことが示されている。その様式名はそれぞれラベル42
5b, 425c,425d で示されるように、「書類X 」である。
アーク422aと422eは、図２１のアーク212bと同様に破線
で示されているが、これは即ち動作の完了を示す、自動
生成された様式のない電子メールの受け渡しを示すアー
クである。アーク422a, 422eと結合端子427a, 427bにつ
いては詳しく後述する。

【００７９】図４２のチャート図において、これまでの
実施例で説明したチャート図こと異なる点に、電子メー
ルの転送順が分岐していることがある。本例では、ノー
ド421bから二つのアーク422c, 422dが分岐して出てい
る。転送順の分岐は、この例のように転送順のパターン
登録時のみ可能なのではなく、これまでの実施例で説明
して来た通常の転送順定義においても導入可能な機能で
ある。本実施例においては、この、転送順の分岐の許容
についても説明する。図４２では、アーク422cと422dに
それぞれラベル426c, 426dが付いている。この二つのラ
ベルは、ノード421bにおける分岐先の参照のために用い
るもので、ここでは転送順定義手段によって自動的に作
成されるものと仮定する。

【００８０】第８の発明までの実施例の説明では、作業
者に関する定義はすべて視覚的なチャート図のみで行う
こととしたが、分岐を行う場合には、分岐条件の定義を
行う為に、チャート図だけで定義を行うことは困難であ
る。そこで、図７に示すような転送順の定義中に、作業
者のノードの部分をマウスでダブルクリックすると、作
業者の詳細を定義するウィンドウを呼び出して、詳細定
義を行えるようにする。

【００８１】図４３は、図４２の添削者ノード421bに関
して、詳細な定義を行っている作業者詳細定義ウィンド
ウの画面の一例を示す画面図である。作業者詳細定義ウ
ィンドウ431 は、ラベル432,入出力参照サブウィンドウ
433,詳細定義記述サブウィンドウ434 から成っている。
ラベル432 は編集中の作業者ノード( この場合421b)の
名称を示すもので、この例では「添削者」である。入出
力参照サブウィンドウ433 は、編集中のノード421bへの
電子メールの入力と、該ノード421bからの電子メールの
出力の一覧を示したものである。このうち第三列の"OR"
は、開発者が記入した部分で、出力Ａ( 図４２のアーク
422dに対応) と出力Ｂ( 図４２のアーク422cに対応) の
どちらか一方のみが出力されることを、開発者が選択し
たことを示している。もしここに"AND" を記入すると、
422d, 422cの両方のアークに電子メール( すなわち、書
類Ｘ) を出力することになる。詳細定義記述サブウィン
ドウ434 は、開発者が記述する部分であり、開発者は、
アーク422d, 422cへの分岐条件を含めた、ノード421bの
仕様の記述を行う。ただし、図４３の詳細定義記述サブ
ウィンドウ434 の中では、説明の便宜のため、行番号を
付加してある。1 行目は、添削者421bが、書類X の「コ
メント欄」に書き込みを行うことを示している。すなわ
ち、書類X のフィールドの中に、「コメント欄」という
名前のものがあれば、添削者421bはそこにのみ記入でき
ることを示している。このような記入制限は、第８の発
明までの実施例では説明しなかったが、本実施例のよう
に、作業者詳細定義ウィンドウ431 を導入すれば、この
ような記入制限を行うことも可能である。2 行目のask-
to-user は三つ以上のパラメータを持つキーワードで、
第一パラメータは作業者に提示される文字列を示し、第
二パラメータ以降は、作業者が選択可能な選択子とその
選択子が選択された場合の分岐先を示す。したがって、
この例では「書き直しを求めますか？」という文字列
と、"YES", "NO" の二つの選択子が作業者、すなわち添
削者に提示され、作業者が選択子"NO"を選択すればA 、
すなわちアーク422dに分岐し、"YES" を選択すればB 、
すなわちアーク422cに分岐する。詳細定義記述サブウィ
ンドウ434 の内部で定義された作業者の作業詳細は、生
成手段によって作業者の利用するグループウェア利用ソ
フトウェアが参照する電子メール利用環境定義の中に、
適切な変換の後に出力されることになる。

【００８２】なお、図４２の例では、転送順の分岐が作
業者ノード421bにおいて発生したが、ソフトウェアオブ
ジェクトに於いて分岐する例も考えられる。このような
例では、オブジェクト定義中に、分岐の判断基準を示す
記述を含める必要がある。例えば、入力された電子メー
ルの様式のあるフィールドの内容を読み取り、読み取ら
れた内容によって分岐するなどの方式がある。ところ
で、図４２のノード421aは、422a, 422cの二つのアーク
が入力として指定されている。第８の発明の実施例で
は、このような複数入力はすべて「待ち合わせ」と解釈
してきたが、本実施例では、複数入力に関して待ち合わ
せを行う(AND) か、いずれかの入力が入ったときにノー
ドが動作を開始する(OR)かを、やはり作業者詳細定義ウ
ィンドウの中で指定するものとする。図４２の例の場合
は、アーク422bとアーク422cがループを形成しているた
め、ノード421aにおいてはアーク422aからの入力は最初
の一回だけであるのに対しアーク422cからの入力はその
後何度も起こる可能性がある。したがって、アーク422a
とアーク422cの待ち合わせを行うことはできないので、
ORを指定することになる。

【００８３】続いて、図４２のチャート図に示されるよ
うに設計され登録された転送順のパターンを、再利用す
る場合の例について説明する。ここでは、図４２のパタ
ーンが「添削パターン」として登録されているものと仮
定する。

【００８４】図４４は、グループウェア開発者が、転送
順の定義時に、図４２のチャート図で示される添削パタ
ーンを再利用して転送順の定義を行った場合の例を示す
チャート図である。図４４において、441a, 441b, 441
c, 441dはノード、442a, 442b, 442cはアークである。
ノードのうち、441a, 441c, 441dは作業者であり、441b
は再利用されたパターンである。ノードのラベル443a,
443c, 443dはそれぞれ作業者ノード441a,441c, 441d の
役割の名称を示す。四角形444cはアーク442cで示される
電子メールの受け渡しでは、電子メールが様式を持って
いることを示しており、その様式はラベル445cで示され
る「調査報告書」である。さて、アーク442aと442bは添
削パターンノード441bに付属する三角形446a, 446bとそ
れぞれ結合されている。三角形446a,446b は添削パター
ンの結合端子を示すものであって、図４２の結合端子42
7a,427b にそれぞれ対応している。したがって、これら
の結合端子と接続されているアーク442a,442b はそれ
ぞれ図４２のアーク422a,422e と結合することになる。
アーク442a,442b はいずれも破線で示されるアークであ
り、422a,422e と同種であるため、図４４と図４２の結
合は可能である。破線で示すアークは本来始点ノードの
動作の完了時に自動的に送られる電子メールを示すもの
であるが、ノード441aは入力がなく、動作も定義されて
いない。この場合、図４４の転送順定義にしたがって生
成されたグループウェアの起動時に無条件でアーク442a
で示される電子メール転送が行われることになる。さ
て、添削パターンを定義するチャート図（図４２）と、
添削パターンを再利用するチャート図（図４４）は、役
割の名称と書類の名称の対応付けを行わなければ結合が
できない。そのために必要な定義を開発者が行うために
利用されるのがパターン再利用定義ウィンドウであり、
パターンを示すノード、この場合はノード441bをマウス
でダブルクリックすると呼び出されるものとする。図４
５は、図４４の添削パターンノード441bをダブルクリッ
クして呼び出される、パターン再利用定義ウィンドウの
一実施例を示す画面図である。パターン再利用定義ウィ
ンドウ451 は、二つの列452a, 452bから成る表を持って
いる。左の列452aは、図４２に示す添削パターンを定義
するチャート図で用いられている役割および様式の名称
の一覧であり、転送順定義手段において自動的に生成さ
れる。右の列452bは、パターンを再利用して定義中の転
送順定義( 図４４) にて用いられている役割および様式
の名称を記入する列であり、ここはグループウェア開発
者が記入する。この例の場合、執筆者は調査担当者に、
添削者は課長に、書類Ｘは調査報告書に対応付けられて
いる。調査担当者および課長については、生成手段がグ
ループウェアを生成する場合には、さらに役割対応定義
手段にて定義された実際の作業者の名前に置き換えて生
成される。課長に関しては図４４には現れて来ないが、
図４５で定義されているため、役割対応定義手段では課
長に関する定義も必要になる。図４４の調査担当者と、
図４２の執筆者は、アイコン( 人物の形で示されたノー
ドの形状) が異なるが、これはパターンの再利用の上で
何ら問題にはならない。

【００８５】図４２の添削パターンのチャート図と、図
４４の転送順定義のチャート図とを、図４５のパターン
再利用定義に従って結合すると、アーク442aとアーク42
2aとの結合で定義されるアークは、調査担当者から調査
担当者への電子メール転送、すなわち、同一人物間での
電子メール転送ということになる。このような同一人物
間、あるいは同一ソフトウェアオブジェクト間での電子
メール転送を示すアークは、以下の規則により解釈する
ものとする。すなわち、始点ノードで定義された動作が
完了したのち、終点ノードで定義された動作を実行する
という規則である。ソフトウェアオブジェクトの場合、
これは状態遷移に相当する。この規則は破線によるアー
クの場合も、実線によるアークで様式が指定されている
場合も同じように適用する。アーク422eとアーク442bの
結合に関しても同様である。

【００８６】以上の説明のように、図４４で示される転
送順定義では、添削パターンを再利用して、調査担当者
が、調査報告書を課長に添削してもらった後に調査とり
まとめ役に提出するという転送順が定義されていること
になる。次に、第１の発明から第９の発明までの実施例
で説明したグループウェア開発支援システムの生成手段
の詳細な実施例を説明する。ここでは、全ての発明で提
供する機能を包含したグループウェア開発支援システム
を想定し、これまでに説明したどの実施例にも適用可能
な生成手段の構成方法について述べる。

【００８７】図４６は、生成手段の生成手順の概略を示
すフローチャート図である。 ステップ461 ：第９の発明の実施例で述べた転送順パタ
ーンが、転送順定義において用いられている場合、パタ
ーンの展開を行って、元の転送順定義をパターンの無い
転送順定義に変換する。第４の発明，第５の発明に関す
る実施例でした会議仮想オブジェクトも転送順パターン
の一種として扱い、展開を行う。 ステップ462 ：第２の発明の実施例で述べた役割対応定
義が行われている場合には、役割名を作業者の実名に変
換する。 ステップ463 ： 転送順定義に現れるグラフのノード毎
に必要な情報を整理する。転送順定義に同一のノードが
複数回現れている場合には、それらをまとめる。 ステップ464 ：転送順定義のうち、各作業者ノードに関
連するファイル、すなわち作業者用の電子メール利用環
境定義ファイルを生成する。 ステップ465 ：転送順定義のうち、各ソフトウェアオブ
ジェクトノードに関連するファイル、すなわち各ソフト
ウェアオブジェクト用の電子メール利用境定義ファイル
と、処理プログラムファイルを生成する。 ステップ466 ：その他に必要なファイルを生成する。こ
れまでの実施例で説明した中では、MERMAID 用の初期化
ファイルがこれに当たる。 以下に、符号461 から466 までの各ステップについて説
明する。

【００８８】ステップ461 では、例えば図４２に示した
ようなパターンを、それを利用する例えば図４４のよう
な転送順定義にあてはめて展開を行う。この際、図４５
のパターン再利用定義ウィンドウで定義した対応表に従
って、役割名と様式名の変更を行う。ステップ461 にお
いてもう一つの必要な作業は、会議仮想オブジェクトの
展開である。例えば、図２３に示した、会議仮想オブジ
ェクトを用いた転送順定義は、図２４に示したオブジェ
クト定義のもとでは図４７のように展開される。( 実際
にはチャートを描く訳ではなく、生成手段内部で記号的
に展開されるが、ここでは説明のためチャートを用いて
いる。) 図２３から図４７への展開方式については、図
２３と図２４の説明の項で既に概略を示したが、詳細に
説明すると、 1. 会議仮想オブジェクトに代えて、ソフトウェアオブ
ジェクトを一個置く。ここでは、仮に会議仮想オブジェ
クトと同じ名前のStrategicMeetingで呼ぶ。 2. ソフトウェアオブジェクトStrategicMeetingから、
資料送付者を除く参加者全員に資料を配布するアークを
生成する。 3. ソフトウェアオブジェクトStrategicMeetingは、議
事録様式を生成するが、それを書記( 正確には、Output
Maker と指定された役割) に送信するためのアークを生
成する。議事録様式とは、もとの転送順定義( 図２３)
で会議仮想オブジェクトから出力されるアークに指定さ
れた様式である。 4. 書記から、外部( 会議仮想オブジェクトからの出力
アークの行き先) に、議事録様式を送信するアークを生
成する。 である。すなわち、図２３の会議仮想オブジェクト231c
は、ソフトウェアオブジェクト471aと、作業者オブジェ
クト471b, 471c, 471d, 471e, 471f, 471gに展開され
る。( 図４７では、作業者オブジェクトのアイコンを仮
に5 角形で表現している。) これらは、会議の参加者で
ある。ソフトウェアオブジェクト471aは、会議仮想オブ
ジェクト231cに入力される電子メールを展開された作業
者オブジェクト471b, 471c, 471d,471e, 471f, 471g に
配布する。これを各々アーク472b,472c, 472d, 472e, 4
72f, 472gで表現してある。( ここでは、煩雑さを避け
るために一つのアークに二つ以上の様式指定を示す四角
形を付加しているが、実際には四角形の数だけアークが
あるチャートと等価であるものとする。) ただし、為替
動向報告者に対する為替動向報告書の配布と、市場動向
報告者に対する市場動向報告書の配布は行っていない。
さらに、ソフトウェアオブジェクト471aは議事録様式を
生成し、書記ノード471bに送付する。

【００８９】図４８は、会議仮想オブジェクトの実現方
法としてMERMAID を用いた場合、すなわち図２７の会議
仮想オブジェクト定義を用いた場合の、図２３の展開例
である。図４７との違いは、議長ノード481h, 書記ノー
ド481i, アーク482h, 482i,482jが追加されたことであ
る。議長は図２７でOriginatorと宣言されているため、
MERMAID を起動する義務がある。この義務については議
長ノード471gの属性として記録しておく。新しい議長ノ
ード481hは、MERMAID 終了後の議長の状態を示すノード
である。新しい書記ノード481iは、MERMAID 開始後の書
記の状態を示すノードである。アーク482hはMERMAID の
終了によって発生する議長の状態遷移を示している。同
一ノード間の破線アークが状態遷移を表すことは、図４
２の説明で述べた。アーク482iは、MERMAID の開始によ
って発生する書記の状態遷移を示している。アーク482j
は議長から書記へのSIGNAL型の電子メール送信を表現す
るもので、MERMAID の終了を書記に通知する。( このア
ークは後に図２９の13,14行を生成する。)次に図４６の
ステップ462 について説明する。このステップでは、役
割対応定義手段で定義された役割対応定義( 例: 図２
０) に従って、役割名称を作業者の実名に変換する。転
送順パターンはすでにステップ461 で展開されているの
で、ステップ462 が終わると、転送順定義から役割名称
は一切なくなり、すべてが作業者の実名に置き換えられ
る。

【００９０】次に、図４６のステップ463 について説明
する。ステップ463 の概略は 1. 同種のノード、すなわち、同じ作業者、あるいは同
じ名称のオブジェクトが、転送順定義中に複数回現れて
いれば、それらをひとまとめにし、 2. 各ノードに入力される可能性のあるアークについ
て、様式とアークの始点をキーとする一覧表( ノードデ
ータ表) を作成し、 3. 各アークに対応するアクションを生成するのに必要
なデータを、前記ノードデータ表に書き込む。 である。

【００９１】図４９は、図４８に示した「書記」( 中川
二郎) のノード471b, 482iに関するノードデータ表を生
成した例である。また、図５０は、図４２と図４４で示
した転送順定義を展開した場合の、調査担当者に関する
ノードデータ表を生成した例である。ただし、図５０
は、課長が「石黒恵」、調査とりまとめ役が「関本正」
という実作業者名であるという仮定で作成した。

【００９２】図４９は491, 492, 493, 494, 495 の5 つ
のデータ行からなっている。行491,行492 は図４８のア
ーク472bで示される為替動向報告書および市場動向報告
書の受信を示している。このとき待ち合わせを行わず、
アクションがshow (受信したメールを表示する) である
ということはMERMAID 利用時のノードデータ表作成方式
として定められているものとする。行493 も、アーク47
2bに対応するが、これは議事録の受信を意味する。この
とき、議事録をいったんファイルに蓄積し(store /tmp/
foobar) 、次の状態に遷移する(state 4) ことになって
いるが、これもMERMAID 利用時のノードデータ表作成方
式として定められている。行494 はアーク482iによって
状態遷移したノード481iに関するデータである。STATE-
TRNSは状態遷移を示すキーワードで、この場合発信元は
指定しない。ここではアーク482jとの間で待ち合わせを
行うことが指定されている( 待ち合わせ「5 」で示され
ている) が、これもMERMAID 利用時のノードデータ作成
方式として定められている。行495 は、アーク482j に
対応している。この場合行494 との待ち合わせを行い、
議事録ファイルを取り出して鈴木花子に送り出す。この
アクションもMERMAID 利用時のノードデータ表作成方式
として定められている。

【００９３】図５０は、501, 502, 503, 504, 505 の5
つのデータ行からなっている。行501 は、図４４のノー
ド441aに対応している。BEGIN はアークの流入がないこ
とを示すキーワードであって、BEGIN が使われる場合に
は発信元は指定されない。ここではアーク442aが状態遷
移を表すので、行502 への遷移を示すアクション(state
2) が示されている。行502 は、ノード421aに流入する
アーク422a( アーク442aと同一) に対応する。ここで
は、調査報告書( 図４２の書類X に対応) を新たに作成
し、それを編集して石黒恵( 添削者) に送る。行503 は
ノード421aに流入するアーク422cに対応する。様式に関
して「F(承認)=NO」と示されているが、これは、「調査
報告書の承認フィールドがNOである場合」という意味で
ある。次の行504 は、ノード421cに流入するアーク422d
に対応しているが、様式と発信元だけでは行503,504 の
どちらのケースか判定できないので、ここではフィール
ドの値まで調査する。ここでは、承認フィールドは図４
３の詳細定義記述サブウィンドウ434 の2 行目で示され
ているask-to-user のアクションで、YES またはNOの値
が自動的に書き込まれているものとしている。行505
は、図４４のノード441cに対応する。

【００９４】図５１は、図３１のソフトウェアオブジェ
クトノード311d BudgetManagerに関して生成されたノー
ドデータ表の例である。図５１は、行511 のみから成っ
ている。proc_BudgetManger_1 は、図３３で定義されて
いるProcedure に関して自動的に付けられた名前であ
る。ソフトウェアオブジェクトの場合、様式の生成や協
調作業等はすべて開発者によってオブジェクト定義中に
記述される。この場合proc_BudgetManger_1 にそれらの
アクションが記載されているので、ノードデータ表のレ
ベルでは手続き呼び出しと電子メール送信のことだけを
記入しておけば良い。

【００９５】以上説明した、図４９，図５０、図５１の
ようなノードデータ表を作成するステップ463 について
再度詳細に説明する。ステップ463 は、各ノード( 同種
ノードが複数現れている場合はそれらをまとめたもの)
について、以下の処理を行う。 1. ノードすべてに流入するアークについて、様式(SIGN
AL,状態遷移を含む) と、発信元( 状態遷移の場合を除
く) の組を作成する。流入のない場合はBEGINとする。 2. ノードに流入するアークついて、前記様式と発信元
の組が二回以上現れていないことを確認する。もし、二
回以上現れていたら、図５０の行503,504 の例のよう
に、様式中の特定のフィールドの値が特定できるかどう
か調査する。(図５０の例では図４３で承認フィールド
の値が指定されているので特定できる。) 様式と発信元
が同じ組み合わせで、特定のフィールドの値でも区別で
きないアークが複数ある場合は、エラーとする。 3. ノードデータ表の様式と発信元の欄を、前ステップ
で調査したデータに基づき記入する。 4. 会議仮想オブジェクトのように、アクションがあら
かじめ定められている部分に関しては、定められた通り
に待ち合わせとアクションの部分を生成する。

【００９６】5. 待ち合わせの有無をチェックし、ノー
ドデータ表の待ち合わせ欄を埋める。 6. 作業者ノードの場合、以下の規則に従ってアクショ
ン欄を生成する。 (a) 入力様式と出力様式が同じ場合、edit ＜様式名＞,
send < 様式名＞ to ＜宛先＞ をアクションとする。 (b) 入力様式と出力様式が異なる場合、show ＜入力様
式名＞, create < 出力様式名＞, send < 様式名＞ to
＜宛先＞ をアクションとする。 (c) 上記の例外として、SIGNALが出力の場合には、crea
te_signal_messag send<SIGNA L> to < 宛先＞ がアク
ションとなる。 7. ソフトウェアオブジェクトノードの場合、以下の規
則に従ってアクション欄を生成する。 (a) オブジェクト定義のProcedure の部分に一意の名前
をつけ、C の関数とし、保存しておく。(Procedureの定
義は、関数の型、名前、引数の宣言、return文を加える
だけでC の関数としての体裁が整う。) この関数はステ
ップ465で使用する。 (b) 前記関数を第一のアクションとする。 (c) send ＜出力様式名＞ to ＜宛先＞ を第二のアクシ
ョンとする。

【００９７】続いて、図４６のステップ464 について説
明する。このステップはステップ463 で作成した作業者
ノード用のノードデータ表を元にして、各作業者用の電
子メール利用環境定義を以下の手順により生成する。 1.作業者環境定義がある場合は、環境宣言を生成する。
( 図３７，図３８の例参照) 2.ノードデータ表の様式と発信元の欄を参考に、条件部
(BEGIN, if等で始まる行) を、アクション欄を参考に、
アクション部( 条件部の成立によって実行される行) を
生成する。このとき、以下の点に注意する。

【００９８】・必要に応じて一時変数を利用する。(
例、図１３の3 行のA) ・待ち合わせがある場合は、その処理を行う( 例、図４
１の1,4,7,9,10行のmとn による処理) ・会議仮想オブジェクトの場合のように、特殊な生成方
式がある場合はそれに従う。

【００９９】続いて、図４６のステップ465 について説
明する。このステップはステップ463 で作成したソフト
ウェアオブジェクト用ノードデータ表を元にして、各ソ
フトウェアオブジェクト用の電子メール利用環境定義
と、処理プログラムを生成する。以下の手順による。 1.ステップ463 で、オブジェクト定義のProcedure 部分
から抜き出してC の関数に変更したものを処理プログラ
ムとして出力する。 2.電子メール利用環境定義の生成方法は、作業者ノード
の場合に準じる。ただし、処理プログラムの呼出しはdo
_proc を利用する。

【０１００】最後に、図４６のステップ466 について説
明する。このステップは例えば、MERMAID を利用した場
合のMERMAID 用初期化ファイルの生成等、特殊な場合に
のみ実行される。MERMIAD を利用する場合の生成内容
は、既に実施例で説明した通りであり、議長と書記に対
して専用の初期化ファイルを決められた方式で生成す
る。会議ツールとしてMERMAID 以外のものを利用する場
合、あるいは新たに特殊な転送パターンやツールを導入
した場合等には、生成方式をその都度生成手段に組み込
んでおく必要がある。引き続いて、本願の発明のうち、
グループウェア開発支援システム本体関連以外の発明で
あって、請求項10に記載された第１０の発明である電子
メール受信ソフトウェアの実施例について説明する。図
３７を用いて説明したグループウェア利用ソフトウェア
3700a が、第１０の発明による電子メール受信ソフトウ
ェアの実施例になっている。図３７のグループウェア利
用ソフトウェア3700a は、通信手段3710a を持つ。制御
手段3702が、通信手段3710a を制御して通信相手の端末
の持つ通信手段3710b を探すとき、図３８の如き電子メ
ール利用環境定義で指定された識別名を持つ端末を選択
して探し出して接続する。このとき、電子メール利用環
境定義ファイルで指定された電子メール編集ソフトウェ
アの名称は、環境解釈手段3701から制御手段3702に渡さ
れ、さらに制御手段3702から通信手段3710a,通信手段37
10b を介して端末側のユーザインタフェース手段3703に
渡され、ユーザインタフェース手段3703は指定された電
子メール編集ソフトウェアを起動することになる。

【０１０１】

【発明の効果】以上説明したように、本発明のグループ
ウェア開発支援システムは、以上のように構成されてい
るので、支援システムの利便性、支援システムが扱える
転送形態の多様性に優れるという効果があり、具体的に
は、 1.特に専用言語等の専門知識を有しない開発者でも、電
子メールを利用したグループウェアの開発が容易に行え
る。 2.作業者と処理プログラム( オブジェクト) との間での
自由な電子メール転送順を設定でき、人手による記入と
システムによる処理が混在する一連の手順を一貫して設
計できる。 3.請求項2 によるグループウェア開発支援システムで
は、実際にどの具体的な作業者が各役割に就くかはあと
で決めるような開発方式をとることができる。 4.請求項3 によるグループウェア開発支援システムで
は、作業の完了を示す電子メールを自動的に生成し受け
渡すようなグループウェアを生成することができる。 5.請求項4 によるグループウェア開発支援システムで
は、会議を途中にはさんだ一連の作業を支援するグルー
プウェアの開発を支援することができる。特に、請求項
5 によるグループウェア開発支援システムでは、オンラ
インリアルタイム会議システムを利用できる。 6.請求項6 によるグループウェア開発支援システムで
は、複数のソフトウェアモジュールが互いの自律的目標
を動的に調整しながら最適な解を自動的に求める、いわ
ゆるマルチエージェントシステムを利用するグループウ
ェアを生成することができる。 7.請求項7 によるグループウェア開発支援システムで
は、作業者の嗜好や作業環境を反映した柔軟なシステム
の構築を支援することができる。 8.請求項8 によるグループウェア開発支援システムで
は、複数の電子メールの到来を待ち合わせてから次の動
作を開始するような転送順を定義することができる。 9.請求項9 によるグループウェア開発支援システムで
は、電子メールの転送順に関してよく使われるパターン
を予め定義しておき、それを再利用して効率的にグルー
プウェアの開発を行うことが可能である。 10. 総じて、本発明によるグループウェア開発支援シス
テムは、グループウェアの開発を大幅に省力化し、開発
効率を上げる。

【図面の簡単な説明】

【図１】第１の発明のグループウェア開発支援システム
の一実施例を示すブロック図である。

【図２】図１の様式定義手段3 で定義される様式の例を
示す図である。

【図３】図１の様式定義手段3 を利用する場合の画面の
一例を示すである。

【図４】図１の様式定義手段3 から生成手段6 に渡され
る様式定義の記述例を示す図である。

【図５】オブジェクトを定義した例を示す図である。

【図６】転送順定義手段5 を利用して定義する転送順の
例を示すチャート図である。

【図７】入出力装置7 を介して転送順定義手段5 を利用
する場合の画面の一例を示す画面図である。

【図８】メニューを示す図である。

【図９】メニューを示す図である。

【図１０】メニューを示す図である。

【図１１】図６のチャート図による転送順を定義した場
合に、転送順定義手段5 から生成手段6 に渡される転送
順定義の一例を示す図である。

【図１２】本発明のグループウェア開発支援システムに
よって開発されたグループウェアを利用する作業者用ノ
ードの構成例を示すブロック図である。

【図１３】図６の例において、作業者鈴木花子が用いる
グループウェア利用ソフトウェア120 の参照する電子メ
ール利用環境定義127 の生成例を示す図である。

【図１４】鈴木花子の利用するグループウェア利用ソフ
トウェア120 が、作業者鈴木花子に提示する画面の一例
を示す画面構成図である。

【図１５】本発明のグループウェア開発支援システムに
よって開発されたグループウェアを利用するソフトウェ
アオブジェクトの構成例を示すブロック図

【図１６】図６のソフトウェアオブジェクトQuestionRe
corderに関して、生成された電子メール利用環境定義15
7 の一例を示す図である。

【図１７】図６のソフトウェアオブジェクトQeestionRe
corderに関して、生成された処理プログラム158 の一例
を示す図である。

【図１８】第２の発明のグループウェア開発支援システ
ムの一実施例を示すブロック図である。

【図１９】転送順定義手段185 を用いて定義する転送順
の例を示すチャート図である。

【図２０】役割対応定義手段189 を用いて定義する役割
名称と名前との対応表の一例を示す図である。

【図２１】第３の発明によるグループウェア開発支援シ
ステムを利用した場合の転送順定義手段を利用して定義
する転送順の一例を示すチャート図である。

【図２２】図２１のチャート図の表すアーク212bに対応
して受け渡しする電子メールの一例を示す図である。

【図２３】第４の発明によるグループウェア開発支援シ
ステムを利用した場合の転送順定義手段を利用して定義
する転送順の一例を示すチャート図である。

【図２４】会議仮想オブジェクト231cをオブジェクト定
義手段を利用して定義した例を示す図である。

【図２５】図２３のStrategicMeetingの電子メール利用
環境定義 157に対して生成されるコードの一例を示す図
である。

【図２６】書記の利用するグループウェア利用ソフトウ
ェアのために生成される電子メール利用環境定義127 の
コードの一例を示す図である。

【図２７】図２３の会議仮想オブジェクト231cとしてオ
ンラインリアルタイム会議システムを利用する場合の、
会議仮想オブジェクト231cのオブジェクト定義記述の一
例を示す図である。

【図２８】オンラインリアルタイム会議システムを利用
する場合の図２３のStrategicMeetingの電子メール利用
環境定義 157に対して生成されるコードの一例を示す図
である。

【図２９】オンラインリアルタイム会議システムを利用
する場合、議長の利用するグループウェア利用ソフトウ
ェアのために生成される電子メール利用環境定義127 の
コードの一例を示す図である。

【図３０】オンラインリアルタイム会議システムを利用
する場合の、書記の利用するグループウェア利用ソフト
ウェアのために生成される電子メール利用環境定義127
のコードの一例を示す図である。

【図３１】第６の発明によるグループウェア開発支援シ
ステムにおいて、転送順定義手段を用いて定義する転送
順の一例を表すチャート図である。

【図３２】協調活動を行うソフトウェアオブジェクトの
構成の一例を示すブロック図である。

【図３３】図３１のBudgetManager に関して、クト定義
手段を用いて定義したオブジェクト定義の一例を示す図
である。

【図３４】図３３のオブジェクト定義から生成手段が、
BudgetManagerの処理プログラム158aとして生成するコ
ードの一例を示す図である。

【図３５】第７の発明によるグループウェア開発支援シ
ステムの一実施例を示すブロック図である。

【図３６】入出力装置357 を介して作業者環境定義手段
359を用いて作業者環境の定義を行う場合の、画面の一
例を示す画面図である。

【図３７】グループウェア利用ソフトウェアを二つのマ
シンで構成する場合の、構成を示すブロック図である。

【図３８】図３６による作業者環境定義と図６による転
送順定義に基き生成手段から出力される鈴木花子用の電
子メール利用環境定義3707の一例を示す図である。

【図３９】第８の発明によるグループウェア開発支援シ
ステムを利用した場合、転送順定義手段を利用して定義
された転送順の一例を示すチャート図である。

【図４０】図３９のチャート図で示される転送順定義に
関して、 MailDelayerソフトウェアオブジェクト391cの
オブジェクト定義を行った例を示す図である。

【図４１】図３９のチャート図で示される転送順定義
と、図４０で示されるMailDelayerのオブジェクト定義
に基き生成手段が生成する、MailDelayer の電子メール
利用環境定義の一例を示す図である。

【図４２】第９の発明によるグループウェア開発支援シ
ステムで利用可能な、転送順のパターンの一例を示すチ
ャート図である。

【図４３】図４２の添削者ノード421bに関する、作業者
詳細定義ウィンドウの画面の一例を示す画面図である。

【図４４】図４２のチャート図で示される添削パターン
を再利用して転送順の定義を行った場合の例を示すチャ
ート図である。

【図４５】パターン再利用定義ウィンドウの一実施例を
示す画面図である。

【図４６】生成手段の生成手順の概略を示すフローチャ
ート図である。

【図４７】図２４に示したオブジェクト定義のもとでの
図２３の展開例を示すチャート図である。

【図４８】図２７の会議仮想オブジェクト定義を用いた
場合の、図２３の展開例を示すチャート図である。

【図４９】図４８のノード471b, 482iに関するノードデ
ータ表を生成した例を示す図である。

【図５０】図４２と図４４で示した転送順定義を展開し
た場合の、調査担当者に関するノードデータ表を生成し
た例を示す図である。

【図５１】図３１のノード311dに関して生成されたノー
ドデータ表の例を示す図である。

【符号の説明】

１ グループウェア開発支援システム ２ 定義部 ３ 様式定義手段 ４ オブジェクト定義手段 ５ 転送順定義手段 ６ 生成手段 ７ 入出力装置 ８ 記憶装置 ３１ 画面 ３２ 編集ウィンドウ ３３ 編集結果 ３４ メニューウィンドウ ６１ａ〜６１ｄ ノード ６２ａ〜６２ｃ アーク ６３ａ〜６３ｄ ノードの名称を示すラベル ６４ａ〜６４ｃ 四角形 ６５ａ〜６５ｃ 様式を指定するラベル ７１ 画面 ７２ 転送順定義ウィンドウ ７３ａ〜７３ｅ ボタン ７４ 編集ウィンドウ １２０ グループウェア利用ソフトウェア １２１ 環境解釈手段 １２２ 制御手段 １２３ ユーザインタフェース手段 １２４ 電子メール受信手段 １２５ 電子メール送信手段 １２６ ネットワーク接続装置 １２７ 電子メール利用環境定義 １２８ 入出力装置 １２９ ネットワークバス １５０ ソフトウェアオブジェクト １５１ 環境解釈手段 １５２ 制御手段 １５３ 処理手段 １５４ 電子メール受信手段 １５５ 電子メール送信手段 １５６ ネットワーク接続装置 １５７ 電子メール利用環境定義 １５８ 処理プログラム １５９ ネットワークバス １８１ グループウェア開発支援システム １８２ 定義部 １８３ 様式定義手段 １８４ オブジェクト定義手段 １８５ 転送順定義手段 １８６ 生成手段 １８７ 入出力装置 １８８ 記憶装置 １８９ 役割対応定義手段 １９１ａ〜１９１ｄ ノード １９２ａ〜１９２ｃ アーク １９３ａ〜１９３ｄ ノードの名称を示すラベル １９４ａ〜１９４ｃ 四角形 １９５ａ〜１９５ｃ 様式を指定するラベル ２０１ａ，２０１ｂ 項目 ２０２ａ，２０２ｂ 項目 ２１１ａ〜２１１ｄ ノード ２１２ａ〜２１２ｃ アーク ２１３ａ〜２１３ｄ ノードの名称を示すラベル ２１４ａ，２１４ｃ 四角形 ２１５ａ，２１５ｃ 様式を指定するラベル ２３１ａ〜２３１ｄ ノード（231cは会議仮想オブジ
ェクト) ２３２ａ〜２３２ｃ アーク ２３３ａ〜２３３ｄ ノードの名称を示すラベル ２３４ａ〜２３４ｃ 四角形 ２３５ａ〜２３５ｃ 様式を指定するラベル ３１１ａ〜３１１ｅ ノード ３１２ａ〜３１２ｄ アーク ３１３ａ〜３１３ｅ ノードの名称を示すラベル ３１４ａ，３１４ｂ，３１４ｄ 四角形 ３１５ａ，３１５ｂ，３１５ｄ 様式を指定するラベ
ル １５０ａ ソフトウェアオブジェクト １５１ａ 環境解釈手段 １５２ａ 制御手段 １５３ａ 処理手段 １５４ａ 電子メール受信手段 １５５ａ 電子メール送信手段 １５６ａ ネットワーク接続装置 １５７ａ 電子メール利用環境定義 １５８ａ 処理プログラム １５９ａ ネットワークバス ３２１ プラン生成手段 ３２２ 協調手段 ３５１ グループウェア開発支援システム ３５２ 定義部 ３５３ 様式定義手段 ３５４ オブジェクト定義手段 ３５５ 転送順定義手段 ３５６ 生成手段 ３５７ 入出力装置 ３５８ 記憶装置 ３５９ 作業者環境定義手段 ３６１ 画面 ３６２ 作業者環境定義ウィンドウ ３６３〜３６７ 列 ３７００ａ，３７００ｂ グループウェア利用ソフト
ウェア ３７０１ 環境解釈手段 ３７０２ 制御手段 ３７０３ ユーザインタフェース手段 ３７０４ 電子メール受信手段 ３７０５ 電子メール送信手段 ３７０６ ネットワーク接続装置 ３７０７ 電子メール利用環境定義 ３７０８ 入出力装置 ３７０９ ネットワークバス ３７１０ａ，３７１０ｂ 通信手段 ３９１ａ〜３９１ｄ ノード ３９２ａ〜３９２ｃ アーク ３９３ａ〜３９３ｄ ノードの名称を示すラベル ３９４ａ，３９４ｃ 四角形 ３９５ａ，３９５ｃ 様式を指定するラベル ４２１〜４２１ｃ ノード ４２２ａ〜４２２３ アーク ４２３ａ〜４２３ｃ ノードの名称を示すラベル ４２４ｂ〜４２４ｄ 四角形 ４２５ｂ〜４２５ｄ 様式を指定するラベル ４２６ｃ，４２６ｄ 分岐先の参照のために用いるラ
ベル ４２７ａ，４２７ｂ 結合端子 ４３１ 作業者詳細定義ウィンドウ ４３２ ラベル ４３３ 入出力参照サブウィンドウ ４３４ 詳細定義記述サブウィンドウ ４４１ａ〜４４１ｄ ノード ４４２ａ〜４４２ｃ アーク ４４３ａ，４４３ｃ，４４３ｄ ノードの名称を示す
ラベル ４４４ｃ 四角形 ４４５ｃ 様式を指定するラベル ４４６ａ，４４６ｂ 結合端子 ４７１ａ〜４４１ｇ ノード ４７２ｂ〜４７２ｇ アーク ４８１ｈ，４８１ｉ ノード ４８２ｈ〜４８２ｊ アーク

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 「電子情報通信学会論文誌」ＶＯＬ. Ｊ75−Ｄ−ＩＩ，ＮＯ．11（1992−11) Ｐ．1874−1883 ＭＡＬＯＮＥ，Ｔ．Ｗ．ＥＴ Ａ Ｌ，”ＥＸＰＥＲＩＭＥＮＴＳ ＷＩＴ Ｈ ＯＶＡＬ：Ａ ＲＡＤＩＣＡＬＬＹ ＴＡＩＬＯＲＡＢＬＥ ＴＯＯＬ Ｆ ＯＲ ＣＯＯＰＥＲＡＴＩＶＥ ＷＯＲ Ｋ”，ＣＳＣＷ’92 ＰＲＯＣＥＥＤＩ ＮＧＳ（1992），Ｐ．292−305

Claims (10)

(57)【特許請求の範囲】
1. 【請求項１】複数のノード間で電子メールを受け渡しし
   ながら一連の作業を遂行するのに使用されるグループウ
   ェアシステムの開発を支援するグループウェア開発支援
   システムにおいて、前記ノードが作業者を表現する作業者対応ノードおよび
   前記電子メールを少なくとも入力あるいは出力とするソ
   フトウェアオブジェクトを表現するソフトウェアノード
   の二種類であって、 前記ノード間で受け渡しされる前記
   電子メールの様式を視覚的に定義し様式定義情報として
   出力する様式定義手段と、前記ソフトウェアオブジェクト の動作条件情報を定義し
   オブジェクト定義情報として出力するオブジェクト定義
   手段と、 受け渡しされる前記電子メールの前記複数のノードにお
   ける転送ルートと前記転送ルートにおける前記ノード間
   で受け渡しされる前記電子メールの様式とを視覚的に定
   義し転送順定義情報として出力する転送順定義手段と、前記様式定義情報と前記転送順定義情報に基づき前記転
   送ルートにおける前記作業者対応ノードの前記電子メー
   ルの編集動作を指示する第一の電子メール利用環境定義
   情報を生成し、また前記様式定義情報と前記オブジェク
   ト定義情報および前記転送順定義情報に基づいて前記ソ
   フトウェアノードにおける前記ソフトウェアオブジェク
   トの前記電子メールの転送動作を指示する第二の電子メ
   ール利用環境定義情報と前記ソフトウェアオブジェクト
   の個別動作を実行するに必要な処理プログラムコードと
   を生成する生成手段と を有することを特徴とするグルー
   プウェア開発支援システム。
2. 【請求項２】複数のノード間で電子メールを受け渡しし
   ながら一連の作業を遂行するのに使用されるグループウ
   ェアシステムの開発を支援するグループウェア開発支援
   システムにおいて、 前記ノードが作業者を表現する作業者対応ノードおよび
   前記電子メールを少なくとも入力あるいは出力とするソ
   フトウェアオブジェクトを表現するソフトウェアノード
   の二種類であって、前記ノード間で受け渡しされる前記
   電子メールの様式を視覚的に定義し様式定義情報として
   出力する様式定義手段と、前記ソフトウェアオブジェクト の動作条件情報を定義し
   オブジェクト定義情報として出力するオブジェクト定義
   手段と、 受け渡しされる前記電子メールの前記複数のノードにお
   ける転送ルートと前記転送ルートにおける前記ノード間
   で受け渡しされる前記電子メールの様式とを視覚的に定
   義し転送順定義情報として出力する転送順定義手段と、前記作業者対応ノードの各々に対して 役割名称と作業者
   個人の名前との対応を定義し役割対応定義として出力す
   る役割対応定義手段と、前記様式定義情報と前記転送順定義情報と、前記役割対
   応定義に基づき前記転送ルートにおける前記作業者対応
   ノードの前記電子メールの編集動作を指示する第一の電
   子メール利用環境定義情報を生成し、また前記様式定義
   情報と前記オブジェクト定義情報および前記転送順定義
   情報に基づいて前記ソフトウェアノードにおける前記ソ
   フトウェアオブジェクトの前記電子メールの転送動作を
   指示する第二の電子メール利用環境定義情報と前記ソフ
   トウェアオブジェクトの個別動作を実行するに必要な処
   理プログラムコードとを生成する生成手段と を有するこ
   とを特徴とするグループウェア開発支援システム。
3. 【請求項３】前記転送順定義手段にて前記転送ルートに
   おける前記ノード間で受け渡しされる前記電子メールの
   様式が指定されていない場合に、前記様式が指定されて
   いない前記電子メールの受け渡しに関する前記電子メー
   ルの送信側ノードである前記ソフトウェアノードの前記
   ソフトウェアオブジェクトに関して、作業の完了を示す
   予め定められた様式の電子メールを自動的に生成し転送
   することを記述した前記ソフトウェアオブジェクト用の
   処理プログラムコードを生成する生成手段とを有するこ
   とを特徴とする請求項１または２に記載のグループウェ
   ア開発支援システム。
4. 【請求項４】前記転送順定義手段にて前記ソフトウェア
   ノードの一つとして前記電子メールを少なくとも入力ま
   たは出力とし複数の作業者による会議を表現する会議仮
   想オブジェクトノードが記述された場合に、前記会議仮
   想オブジェクトノードに関して前記電子メール入力を会
   議資料として発信元以外の前記会議参加の全作業者対応
   ノードに配布し、かつ議事録様式の前記電子メールを予
   め指定された書記ノードに配布することを指示する第三
   の電子メール利用環境定義情報を生成する前記生成手段
   を備えたことを特徴とする請求項１、２または３に記載
   のグループウェア開発支援システム。
5. 【請求項５】前記会議仮想オブジェクトが計算期間ネッ
   トワークを介してリアルタイムにコミュニケーションを
   行うオンラインリアルタイム会議システムであることを
   特徴とする請求項４に記載のグループウェア開発支援シ
   ステム。
6. 【請求項６】前記転送順定義手段にて複数の前記ソフト
   ウェアノード間で協調を意味する相互関係が定義されて
   いた場合は、前記協調を意味する相互関係を有する前記
   ソフトウェアノードに関して、自己目標を動的に調整し
   ながら最適な解を自動的に求めるマルチエージェント処
   理を実行するように記述された前記ソフトウェアオブジ
   ェクト用の処理プログラムコードを生成する前記生成手
   段を備えたことを特徴とする請求項１、２、３、４また
   は５に記載のグループウェア開発支援システム。
7. 【請求項７】前記作業者対応ノードとして用いられる個
   別の計算機および前記作業者対応ノードが属するネット
   ワークの種類および前記作業者対応ノードの利用する個
   別の編集プログラムや電子メール利用環境等を含む作業
   環境を定義し作業環境定義情報を出力する作業環境定義
   手段を備え、 前記作業者対応ノードに関して前記作業環境定義情報で
   指定された前記作業環境で前記電子メールの転送動作お
   よび前記電子メールの編集動作を行うように指示する第
   五の電子メール利用環境定義情報を生成する前記生成手
   段を備えたことを特徴とする請求項１、２、３、４、５
   または６に記載のグループウェア開発支援システム。
8. 【請求項８】前記転送順定義手段にて複数の電子メール
   入力を持つ前記ソフトウェアノードが定義された場合に
   は、複数の電子メール入力を持つ前記ソフトウェアノー
   ドに関して、前記複数の電子メール入力の完了を待ち合
   わせてから前記ソフトウェアオブジェクトが動作を開始
   するように指示する第六の電子メール利用環境定義情報
   を生成する前記生成手段を備えたことを特徴とする請求
   項１、２、３、４、５、６または７に記載のグループウ
   ェア開発支援システム。
9. 【請求項９】前記転送順定義手段が、予め登録された転
   送順のパターンを検索して再利用する再利用手段を有す
   ることを特徴とする請求項１、２、３、４、５、６、７
   または８に記載のグループウェア開発支援システム。
10. 【請求項１０】計算機ネットワークから電子メールを受
    信する電子メール受信手段と前記電子メールに関する条
    件と動作に関する対応関係を定義した電子メール利用環
    境定義ファイルを読み込んで解釈する環境解釈手段と前
    記環境解釈手段から前記対応関係を受け取り前記電子メ
    ール受信手段から電子メールを受け取り前記電子メール
    に前記条件が成立した場合に前記条件に対応する動作を
    実行する制御手段とを有する電子メール送受信装置にお
    いて、 前記電子メール利用環境定義ファイルがさらに電子メー
    ル受信端末の識別名と電子メール編集ソフトウェアの種
    別の定義情報を保持し、前記環境解釈手段が前記端末の
    識別名と前記電子メール編集ソフトウェアの種別の定義
    を解釈し、前記制御手段が前記環境解釈手段から渡され
    た前記端末の識別名の定義に従って前記端末との接続を
    行うとともに前記環境解釈手段から渡された前記電子メ
    ール編集ソフトウェアの種別の定義に従って前記端末に
    前記電子メール編集ソフトウェアの選択を指示すること
    を特徴とする電子メール送受信装置。