JPH05191448A - メールの送付先決定方式 - Google Patents

Abstract

(57)【要約】 【目的】 複数の組織の体制（部署）間で定型文書の電
子メールを授受する方式において、各端末に分散して所
有する体制・機能情報によりメールの送付先を自動的に
決定し、ユーザ負担を低減する。 【構成】 通信路で接続された端末（メール管理サーバ
及び体制・機能サーバ）は、各メール（文書）の種別毎
に、メールの送付先決定のための情報（体制情報２１
２、機能情報２１１、及びこれら情報により定型化して
記述されたメール送付ルートを示す送付規則）を格納し
ている。メールを送付するとき、この情報が参照される
ことによってメール種別に応じた送付ルートが自動的に
決定される。なお、体制・機能情報を各部署（体制）に
分散して所有する場合、複数の組織の体制に亘るそれら
情報の管理を局所化し、複数メールシステムでの共有も
可能となる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、組織の各部署間や部局
間で、種々の伝票類や、命令書、通達書等の定められた
様式をもった文書を電子メールにより送付するメールの
送付先決定方式に係り、特に、メールの送付先を自動的
に決定することにより業務を遂行して行くことのできる
メールの送付先決定方式に関する。

【０００２】

【従来の技術】従来、企業内において電子メールを送付
する場合、送付先の決定方式として発信者が発信の都度
その送付先を指示する方式、あるいは、あらかじめ定め
られたメール種別毎に（例えば、交通費請求書、旅費請
求書、文房具購入台帳など各種の伝票の種別毎に）送付
先をシステムに登録しておき、発信時にシステムがその
情報を検索し送付先を決定する方式が知られている。ま
た、システムに登録される送付先として、事務処理フロ
ーを用いているものも知られている。この種の電子メー
ルシステムの公知例としては例えば特開昭６３−１４１
１７６号公報記載の方式がある。

【０００３】

【発明が解決しようとする課題】上記従来技術では、メ
ールの送付先（宛先）を決定するのに、各種の伝票の伝
票番号毎に直接送付先の担当者の氏名を登録して用いて
おり、体制情報（企業体等組織を構成する各部局、課、
係、係員氏名等の各部署間の関係、つながりを示す情
報、即ち、組織図）や機能情報（個々の部署の実際の業
務内容やその部署における担当者の役割分担を示す情
報）などは全く考慮されなかった。

【０００４】送付先の決定に組織の体制情報のみを用い
ることも考えられるが、組織の体制（組織を形作ってい
る各々の部局、課、係、係員等の各部署）などは必ずし
も個々の役割分担を反映しているとはいえない。従っ
て、従来技術では、体制（各部署）の変更頻度は比較的
少なくても、体制が複数の組織に跨る場合、それぞれの
組織内で担当者の役割が度々変更されるケースが多いた
め、宛先を部署名または担当者としただけでは、正確で
なく、誤送付や送付洩れが生じるおそれがあった。さら
に、各部署での担当者の出入りが多いために、システム
に登録した情報を書き替え保守する頻度も多く、同じ企
業組織で複数のメールシステムを使用している場合など
では、それぞれのメールシステム単位に宛先の情報を登
録しておかなければならず、その登録作業や、送付先決
定作業が重複するという問題が発生していた。

【０００５】従って、本発明の目的は、上記従来技術の
問題点を解消し、ユーザ負担による送付先決定を廃止し
て、ユーザが送付の度にその送付先を意識する必要がな
く、メール管理プログラム側で体制情報及び機能情報を
もとにメール送付の定型化された送付規則により自動的
に送付先決定を行うことによって、ユーザ側での送付先
管理の負担を低減するとともに、誤送付や送付洩れのな
いメールの送付先決定方式を提供することにある。

【０００６】本発明の他の目的は、メール使用プログラ
ム側でメール送付先に関する処理を廃止しメール管理プ
ログラム側で一括管理・処理を行うことでメール使用プ
ログラム側のメール送付先に関する処理を単純化し、メ
ール送付先管理処理を統一化させ、組織の体制がたえず
変化する系でのメールの情報システム化を推進すること
のできるメールの送付先決定方式を提供することにあ
る。

【０００７】

【課題を解決するための手段】上記目的を達成するた
め、本発明は、通信回線で相互に接続された計算機を用
いて、１つの組織内または複数の間の体制間で、定めら
れた様式を持った文書のメールを授受するメールの送付
先決定方式において、分散して所有される組織の体制情
報及び機能情報とメールの送付規則とをリンクさささせ
ることにより、メールの送付先を決定するように構成す
る。

【０００８】ここで、メールの送付規則とは、メール
（文書）の種別毎に、各部署及び各機能間の最初から最
後までの文書の流れ（送付ルート）を記述したものをい
い、予めテーブルの形で格納されているものである。記
述は体制情報及び機能情報、ステップ名、それに必要に
応じて氏名や特殊表現を付加して行われる。この送付規
則テーブルは、体制情報及び機能情報テーブルと共にメ
ール管理プログラム側で一括格納・管理される。

【０００９】また、従来のような送付担当者による送付
先設定を併用することもでき、この場合、担当者により
設定された送付先を、上記組織の体制情報及び機能情報
と、メールの送付規則により決定された送付先と照合
し、両送付先に矛盾がないときだけ送付を行うようにす
ることができる。

【００１０】メールの送付先を氏名やアドレス以外の他
の手段すなわち体制や機能で記述することによって、送
付先を各部署の直接の担当者とは切り離し、部署単位で
担当者を自由に変更するように構成することができる。

【００１１】

【作用】上記構成に基づく作用を説明する。

【００１２】本発明は、メール（文書）の様式（種別）
が特定されれば、送付ルート（送付規則）も特定される
という考えに基いている。本発明によれば、組織の体制
情報及び機能情報を、メールの送付規則とリンクさせる
ことにより送付先を決定するようにしたので、メールの
送付ルートが規則に従ってメール（文書）種別毎に定型
化されて一義的に決定される結果、正確で確実なものな
り、ルート漏れ、情報伝達漏れ（連絡漏れ）を防止する
ことが可能となる。これに伴い、送付ルートは、文書の
各種別毎に自動的に決定されるので、ユーザがいちいち
文書毎に送付先を意識する必要がなくなる。また、送付
ルートの規則に、送付先の固定的な部分（ほとんど更新
の行なわれない部分）と流動的な部分（ひんぱんに更新
される部分）を分けて記述でき、あるいは、固定的な部
分のみ記述し、担当者氏名のような流動的な部分は記述
しないようにすることもできる。したがって、１つの組
織内だけでなく複数の組織の体制間に亘るメールシステ
ムを構築することができる。

【００１３】

【実施例】以下に、本発明の実施例を図によって説明す
る。

【００１４】図１は本発明の一実施例におけるシステム
構成を示した図である。通信路１０１に計算機（端末）
１１１〜１１４が接続されている。計算機１１１は、メ
ールの送付先を決定するための情報（最上位の体制・機
能情報１３１、メール送付規則１４１）を持ち、送付先
を決定する処理を行うメール管理サーバである。計算機
１１２は、メールを送付する計算機で、計算機１１４に
メールを送付するものとする。計算機１１３は、メール
の送付先を決定するための情報（体制・機能情報１３
２）を持ち、送付先を決定する処理を行うための情報を
提供する体制・機能管理サーバである。サーバである計
算機１１１と計算機１１３にはメール管理プログラム１
２１、１２３がある。メールを送受信する計算機１１２
と１１４にはメール処理プログラム群１２２、１２４が
存在している。

【００１５】図２は本実施例における組織の体制・機能
情報１３１，１３２の構造を示した図である。情報テー
ブル２０１はシステム全体の機能と対応する部署に関す
る情報を管理している。同様にそれぞれの下位の体制
（部署）毎に機能と対応する部署を定義した情報テーブ
ル２０２、２０３、２０４などがある。機能名が２１１
に示されそれに対応する部署２１２および氏名２１３で
情報テーブルを構成している。情報テーブル２０１から
２０２、２０３、２０４とたどることにより、最終的に
氏名を得ることができる構造となっている。この情報テ
ーブルは体制に応じて部署単位の階層構造となってお
り、図１のメール管理サーバ１１１及び体制・機能管理
サーバ１１３内で管理される。

【００１６】図３は本実施例におけるメール送付規則１
４１の構造を示した図である。本実施例では、例えば旅
費計算書、備品購入書のような伝票類、あるいは命令
書、プロジェクト通達書などの文書に送付に適用され
る。送付規則（３０１）は様式の異なるメール種別毎に
作成している。これは、様式（フォーマット）が特定さ
れる毎に、送付ルート従ってメール送付規則が特定され
ると考えられるからである。ステップ３０２は、メール
を送付するタイミングを示している。対象３０３は、ス
テップに対応する送付先を格納している。３０４はメー
ルの対象（送付先）の記述方法について示している。図
２の体制・機能情報より得られる＜部署名＞、＜機能名
＞、＜氏名＞および図３の送付規則より得られる＜ステ
ップ名＞と＜特殊表現＞の組合わせにより対象を記述す
る。

【００１７】ここで、 〈部署名〉は、図２の体制・機能情報の各情報テーブル
名称であり 〈機能名〉は、図２の機能の欄に示す機能名称であり 〈氏名〉は、図２の氏名の欄に示す名称であり 〈ステップ名〉は、本図（図３）のステップの欄に示す
名称であり 〈特殊表現〉として、「＊」は、各ステップにおけるメ
ール送付者（送り元担当者）の所属部署を示し「＊Ｕ」
は、図２のテーブルの階層構造において、現在のテーブ
ルにより１階層上位のテーブル（例えば送付者の上司）
を示し、「＊Ｄ」は、現在のテーブルにより１階層下位
のテーブル（例えば送付者の部下）を示す。上記５種類
の名称を、「．」で結合して送付先を記述する。また、
階層を特定したい場合、（＋ｎ）でｎ階層目を意味す
る。以上により、メール送付規則の送付先及びメール送
付時の送付先として使用できる。 （例：図２の情報を使用して記述したケース） （１） 〈部署名〉．〈機能名〉で記述したケース 企画部．代表………………………送付先Ｂ 企画部．課長………………………送付先Ｃ （２） 〈機能名〉で記述したケース 企画（＋４）………………………送付先Ｅ また、図３において、１行目（第１ステップ）は、送付
元担当者が自分の所属する代表「＊．代表」に対し、発
行前承認を求めるための送付を示す。２行目以下では、
その１つ上のステップの送付先が次の送付元となる。例
えば、２行目は、１行目の「＊．代表」が「企画．課
長」に発行を求めるための送付を示し、３行目は、「企
画．課長」が回答例示して最初の送付元本人「＊．企
画」に戻すことを示す。

【００１８】図４は本実施例におけるメールの送付先決
定処理の流れを示した図である。それぞれのツール（例
えば伝票入出力部）より出された送付指示（４０１）を
受け取った分散側のメール管理プログラムはメールの種
別を判断する（４０２）（通常は、ツールとメール種別
は１対１に対応すると考えても良い）。次にメール管理
サーバにメール種別で送付規則を照会し送付すべきメー
ルの現在のステップを判断する（４０３）。以上の情報
より、送付先を決定する処理を行う。まずメール送付規
則より、送付対象を判定し必要な体制・機能情報をメー
ル管理サーバ及び体制・機能管理サーバに照会し、送付
先を決定する（４０６）。以上の処理を送付先の氏名が
すべて決定するまで繰り返す（４１１）。これは、図２
の各階級のテーブルが各部署の計算機に分散して格納さ
れている場合には、それらの計算機に順に問い合わせて
行かなければ、決定できないためである。次に送付先の
設定（４０７）があれば、決定した送付先と比較（４０
８）し、相違がなければ送付（４１０）を行う、相違が
あれば送付処理を中止（４０９）する。このステップ４
０７は必要に応じて設けられたもので、上記のようにし
てメール送付規則に基いて決定された送付先と、更に従
来のように送付担当者の考えで設定された送付先とを比
べて、両送付先が一致したことを確認した上で送付を行
うようにすれば、更に送付誤りをなくすことができる
（例えば：規則で決定した送付先が現在廃止されている
場合などのチェックができる）。

【００１９】以下に、本発明の他の実施例について説明
する。

【００２０】前述の実施例では、メール管理サーバ（１
１１）と複数の体制・機能管理サーバ（１１３等）を有
していたが、１台の管理サーバに、これらメール管理サ
ーバ１１１と体制・機能管理サーバの有するすべての機
能を持たせるようにしてもよい。

【００２１】また、前述の実施例では、体制・機能情報
をメール管理サーバ及び体制・機能管理サーバに照会
し、正しい送付先が判ってからこの送付先にメールを送
付するようにしていたが、送付元で判断できる範囲の適
当な管理サーバにとりあえずメールを送付し、以降の送
付先の調査決定をメールを受けた管理サーバが行い、最
終的な結果を送付元の管理サーバに報告するようにして
もよい。

【００２２】更に、前述の実施例では、送付先を決定す
る情報（体制・機能情報１３１、メール送付規則１４
１）をメール管理サーバ１１１が一括集中して有してい
たが、最上位の体制・機能情報とメール送付規則のみを
メール管理サーバ１１１が持ち、それにより下位の体制
・機能情報は、ローカルの（各部署の）計算機が分散し
て持つようにし、それぞれの計算機内または、通信路１
０１で接続された任意の計算機内で処理を行うこともで
きる。また、体制・機能情報とメール送付規則を別々の
計算機で分散管理することもできる。

【００２３】上記実施例では、計算機１１２を発信側、
計算機１１４を受信側としたが、逆に計算機１１４を発
信側、１１２を受信側としてもよい。

【００２４】

【発明の効果】以上詳しく述べたように、本発明によれ
ば、メール（文書）の種別毎に体制情報及び機能情報で
メール送付ルートを定型化し特定するように記述したメ
ール送付規則を用いることによって、実際のメール送付
の際に、送付者がいちいちその送付先を意識することな
く、この送付先を自動的に正確に決定することができ
る。また、通信回路で相互に接続された計算機（端末）
を用いて、特定の様式を持ったメールの送付先の決定が
メール管理サーバまたは体制・機能管理サーバで分散し
た体制・機能情報を参照することにより可能になり、ユ
ーザの送付先決定に関する負担を低減し、メールの送付
ルートを定型化させたメールの運用が可能となる。

【００２５】また、体制情報及び機能情報を各部署（体
制）に分散して所有させる場合、複数の組織に亘るそれ
ら体制情報および機能情報の管理を局所化し、複数メー
ルシステムでの共有も可能となる。

【図面の簡単な説明】

【図１】本発明の一実施例のシステム構成図である。

【図２】本発明の一実施例の組織の体制情報及び機能情
報の情報テーブルの構成図である。

【図３】本発明の一実施例のメール送付規則のテーブル
の構成図である。

【図４】本発明の一実施例のメールの送付先決定処理の
流れ図である。

【符号の説明】

１０１ 通信路 １１１ 計算機（メール管理サーバ） １１２ 計算機（発信側） １１３ 計算機（体制・機能管理サーバ） １１４ 計算機（受信側） １２１ メール管理プログラム １２２ メール処理プログラム群 １２３ メール管理プログラム １２４ メール処理プログラム群 １３１ 最上位の体制・機能情報 １３２ 体制・機能情報 １４１ メール送付規則 ２０１ 最上位のの体制・機能情報テーブル ２０２ 企画部の体制・機能情報テーブル ２０３ 第１課の体制・機能情報テーブル ２０４ 第１係の体制・機能情報テーブル ２１１ 機能名称 ２１２ 部署名称 ２１３ 氏名名称 ３０１ メール送付規則（メール種別単位） ３０２ ステップ ３０３ 対象（送付先） ３０４ 対象の記述方法 ４０１ 送付指示処理 ４０２ メール種別判断処理 ４０３ 現在のステップ判断処理 ４０６ 体制・機能情報による送付先決定処理 ４０７ 送付先の設定判定処理 ４０８ 送付先のチェック処理 ４０９ 送付中止処理 ４１０ 送付処理 ４１１ 送付先決定完了チェック処理

───────────────────────────────────────────────────── フロントページの続き (72)発明者 中島 寛美 神奈川県川崎市幸区鹿島田890番地の12 株式会社日立製作所情報システム開発本部 内

Claims (3)

【特許請求の範囲】
1. 【請求項１】 通信回路で相互に接続された計算機を用
   いて、１つの組織内または複数の組織の間の体制間で、
   定められた様式を持った文書のメールを授受するメール
   の送付先決定方式において、分散して所有される組織の
   体制情報及び機能情報とメールの送付規則とをリンクさ
   せることにより、メールの送付先を決定することを特徴
   とするメールの送付先決定方式。
2. 【請求項２】 メールの送付先をそれぞれの組織の体制
   や機能で記述することにより、実際の送付先をその時の
   組織の体制及び機能に応じて決定することを特徴とする
   請求項１記載のメールの送付先決定方式。
3. 【請求項３】 担当者により設定された送付先を、組織
   の体制情報，機能情報及びメールの送付規則により決定
   された送付先と照合し、設定された送付先と決定された
   送付先とに矛盾がないことを検証することを特徴とする
   請求項１または２記載のメールの送付先決定方式。