JPH1083420A - モデルベースの業務支援システムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】 ユーザの業務全般を支援し、かつ、業務の変
更に柔軟に対応することが課題である。 【解決手段】 文書検索等のサービス要求を受け取る
と、サービス実行モジュール２３はモデル管理モジュー
ル２７内の対応するサービスモデル３５を取り出し、そ
れに記述されたサービスを、業務モデル３１を参照しな
がら実行する。このとき、ツール制御モジュール２５
に、サービスに必要な文書管理ツール２９等の起動／制
御を依頼する。また、モデル操作モジュール２４は、シ
ステム管理者の指示に従って、業務モデル３１とサービ
スモデル３５の定義／変更を行い、定義情報作成モジュ
ール２６は、その定義／変更内容を対応するツールに反
映させる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、企業等における業
務の効率化を支援するサービスを行う業務支援システム
およびその方法に関する。

【０００２】

【従来の技術】近年、企業における業務の効率化をはか
るために、リエンジニアリングやコンカレントエンジニ
アリングが提唱されている。それらを支援し、文書等の
リソースを管理する計算機用のシステムとして、文書管
理／共有ツール、ワークフローツールなどのソフトウェ
アツールを組み込んだアプリケーションシステムの開発
が盛んである。このようなシステムは、企業等の組織に
おいて、文書の電子化による情報共有と作業の効率化を
実現する鍵となっている。

【０００３】図２１は、従来の業務支援システムの構成
を示している。図２１のシステムにおいて、ユーザがユ
ーザインタフェース１から文書検索などのサービスを要
求する指示を入力すると、そのサービス要求は、制御モ
ジュール２を介してサービス実行モジュール３に伝えら
れる。

【０００４】ユーザに提供するサービスの内容は、あら
かじめサービス実行モジュール３内にプログラミングさ
れており、サービス実行モジュール３はデータベース管
理モジュール４にアクセスしながら、指示されたサービ
スを実行する。データベース管理モジュール４には、ど
のような文書フォーマットや文書が存在するかといった
文書情報５が格納されている。

【０００５】例えば、文書検索が指示された場合は、サ
ービス実行モジュール３はデータベース管理モジュール
４内で文書情報５を検索して、対応する文書を取り出
し、それをユーザに提示する。

【０００６】従来の業務支援システムが提供するサービ
ス用ツールとしては、次のようなものが挙げられる。 （１）ＰＣＴＥ（Portable Common Tools Environment
s） ＣＡＳＥ（Computer Aided Software Engineering ）の
国際標準であるＰＣＴＥでは、文書間の関係定義を中心
とした文書リポジトリ（repository）と、これを利用す
るツールの利用が考慮されている。 （２）グループウェアツール 最近の文書管理／共有ツールの１種であるグループウェ
アツールでは、複数のユーザ間での文書共有機能が提供
されているものが多い。例えば、現在最も普及している
グループウェアツールであるロータスノーツは、基本的
に電子メールに基づいた文書データベースであり、フォ
ームと呼ばれるテンプレートを用いて文書の種類を定義
している。そして、このフォームを共有することで、文
書検索機能を提供している。 （３）ワークフローツール 組織内における作業をモデル化するツールとして、近
年、ワークフローツールが開発されてきている。ワーク
フローツールでは、作業の流れを定義しておき、それに
従って作業員に指示を出す機能が提供されている。

【０００７】

【発明が解決しようとする課題】しかしながら、従来の
業務支援システムには次のような問題がある。ＢＰＲ
（Business Process Reengineering）等でも知られてい
るように、業務の遂行過程においては、組織や文書や作
業手順は頻繁に変更される。また、コンピュータ技術や
ソフトウェア技術の発展に伴い、ユーザに提供されるサ
ービスの変化にも著しいものがある。このような激しい
変化に対応するため、業務支援システムの変更は必須で
あるが、システムを変更するためにはサービス実行モジ
ュール３のプログラムを変更する必要がある。

【０００８】従来のデータベース管理モジュール４は、
文書情報５の登録や参照ができるといった範囲にとどま
り、これを変更しても、ユーザに提供されるサービスの
内容が変化することはない。

【０００９】また、ＰＣＴＥでは、文書リポジトリと作
業定義との関係が考慮されておらず、グループウェアツ
ールでも、同様に、文書と作業との関係は定義できな
い。グループウェアツールにおいては、電子メールを用
いて作業指示を出すことはできるが、その実現には対応
するプログラムを作成する必要がある。また、ワークフ
ローツールでは、多くの場合、作業を定義された順序に
指示していく機能が重視され、文書や組織との間の関係
は定義できない。

【００１０】このように、従来のツールは、個々のツー
ルの持つ機能によって、それぞれ情報共有やワークフロ
ー等の企業活動の一部を支援することができるが、企業
活動全般を支援することはできない。また、支援サービ
スの変化に対応するためには、その都度、プログラムコ
ードを変更することが要求されるが、実際には、このよ
うな運用方法は極めて煩雑であり、現実的ではない。

【００１１】したがって、従来の業務支援システムに
は、企業活動全般を支援するための拡張性や柔軟性に欠
けているという問題がある。本発明の課題は、適切なツ
ールを自動的に起動したり、適切なリソースを自動的に
利用することによって、ユーザの業務全般を支援するこ
とができ、かつ、容易に作成／変更が可能な業務支援シ
ステムおよびその方法を提供することである。

【００１２】

【課題を解決するための手段】図１は、本発明の業務支
援システムの原理図である。図１の業務支援システム
は、サービス手段１１、業務モデル記憶手段１２、サー
ビスモデル記憶手段１３、およびモデル操作手段１４を
備える。

【００１３】業務モデル記憶手段１２は、ユーザの業務
を表す業務モデルを記憶し、サービスモデル記憶手段１
３は、ユーザに提供されるサービスを表すサービスモデ
ルを記憶する。

【００１４】サービス手段１１は、ユーザからサービス
要求を受け取ったとき、上記業務モデルを参照しなが
ら、上記サービスモデルに対応するサービスを提供す
る。ここで、業務モデルとは、ユーザの業務に関連する
組織、文書、作業等の情報と、それらの間の関係を静的
に定義したデータ構造を指し、サービスモデルとは、業
務モデルから取り出された情報を用いてユーザに提供可
能な処理の記述を指す。サービスモデルが記述する処理
の内容としては、例えば、仕様書等の文書が更新された
ときに、その文書をアクセスしている技術者に、文書が
変更されたことを通知する処理が考えられる。

【００１５】サービス手段１１は、ユーザのサービス要
求に対応するサービスモデルを取り出してそれを解釈
し、業務モデルを参照しながら、そのサービスモデルに
記述された処理を実行する。このとき、必要に応じてソ
フトウェアツールを呼び出し、それを利用することがで
きる。

【００１６】このような構成によれば、業務モデルとサ
ービスモデルが独立に定義されるため、例えば組織が変
更された場合は業務モデルのみを変更すればよく、サー
ビスが変更された場合はサービスモデルのみを変更すれ
ばよい。また、これらのモデルは、実際に処理を実行す
るサービス手段１１とは独立に保存されているので、変
更された部分のデータのみを容易に書き換えることがで
き、サービス手段１１自身は変更する必要がない。

【００１７】したがって、業務モデルとサービスモデル
の拡張や変更が容易に行え、サービス手段１１やソフト
ウェアツールの汎用性が高まるため、システム全体の柔
軟性が向上する。このため、様々なサービスに対応可能
なアプリケーションシステムを構築することができる。

【００１８】また、業務モデル記憶手段１２は、例え
ば、組織構成を表す組織モデル、文書構成を表す文書モ
デル、および作業手順を表す作業モデルから成る業務モ
デルを記憶する。

【００１９】これらの組織モデル、文書モデル、および
作業モデルは、業務モデル記憶手段１２内で、適当なリ
ンク等を用いて互いに関係付けられており、サービス手
段１１は、これらのモデルの間の関係をたどりながら必
要な情報を取り出し、その情報を用いてサービスを提供
する。

【００２０】例えば仕様書が更新された場合、サービス
手段１１は、その仕様書と関係付けられている作業を検
索し、その作業に関係付けられている技術者を検索し
て、得られた技術者全員に、仕様書の更新を通知する電
子メール等を送ることができる。

【００２１】また、モデル操作手段１４は、業務モデル
およびサービスモデルを作成したり、変更したりするこ
とができる。従来の業務支援システムでは、組織等の情
報に変更があれば、一旦システムの運用を中止して、サ
ービスを記述したプログラムを書き換える必要があっ
た。しかし、図１のシステムの運用時においては、モデ
ル操作手段１４を介して、随時、モデルの必要な部分を
変更することができ、業務の日常的な変更にも十分対応
することができる。したがって、ユーザは、業務の変更
を前提としてシステムを運用することが可能になる。

【００２２】例えば、図１のサービス手段１１は、実施
形態の図２におけるサービス実行モジュール２３、ツー
ル制御モジュール２５、および定義情報作成モジュール
２６に対応し、業務モデル記憶手段１２およびサービス
モデル記憶手段１３はモデル管理モジュール２７に対応
し、モデル操作手段１４はモデル操作モジュール２４に
対応する。

【００２３】

【発明の実施の形態】以下、図面を参照しながら、本発
明の実施の形態を詳細に説明する。本発明においては、
変更される可能性のある組織構成、文書構成、および作
業手順を業務に関するモデルとして、ソフトウェアツー
ルとは独立に定義することで、業務形態の拡張と変更を
容易にする。

【００２４】また、支援サービス自身も独立にモデル化
することで、文書管理／共有ツールやワークフローツー
ル等のソフトウェアツールを統合して利用することの可
能なアプリケーションシステムを構築する。サービス
は、プログラムではなく、モデルとして用意されるの
で、その作成、削除、変更を容易に行うことができる。

【００２５】図２は、実施形態の業務支援システムの構
成図である。図２の業務支援システムは、グラフィカル
・ユーザインタフェース（ＧＵＩ）２１、制御モジュー
ル２２、サービス実行モジュール２３、モデル操作モジ
ュール２４、ツール制御モジュール２５、定義情報作成
モジュール２６、モデル管理モジュール２７、およびワ
ークフローツール２８や文書管理ツール２９等の各種ソ
フトウェアツールを備える。

【００２６】文書管理ツール２９としては、例えばワー
ドプロセッサやグループウェアツールが含まれる。モデ
ル管理モジュール２７が管理する業務モデル３１は、企
業等の組織における業務内容をモデル化したもので、組
織モデル３２、文書モデル３３、および作業モデル３４
から成る。また、サービスモデル３５は、業務の効率化
に必要なサービスを、業務モデル３１を利用して定義し
たモデルである。

【００２７】従来のシステムでは、文書がデータベース
として参照できるのみであったのに対して、本発明のシ
ステムでは、文書を組織や作業と関係付けることがで
き、これらの関係に基づいてサービスが実現される。こ
れらの業務モデル３１およびサービスモデル３５は、シ
ステムを運用する前に、あらかじめシステム管理者等に
よって定義され、運用中に随時変更することもできる。

【００２８】ＧＵＩ２１は、エンドユーザまたはシステ
ム管理者に提供されるインタフェースであり、エンドユ
ーザは、この画面からサービス要求を入力して、作業を
開始したり文書を検索したりすることができ、システム
はこの画面を通してユーザに必要な指示を行う。システ
ム管理者は、この画面からモデルの定義や変更を行うこ
とができるが、ＧＵＩ２１を用いずに、直接、制御モジ
ュール２２に指示を与えてもよい。

【００２９】制御モジュール２２は、エンドユーザから
のサービス要求やシステム管理者からの指示に基づい
て、サービス実行モジュール２３やモデル操作モジュー
ル２４を制御する。

【００３０】サービス実行モジュール２３は、モデル管
理モジュール２７内の業務モデル３１とサービスモデル
３５を参照しながら、要求されたサービスを実現する。
このとき、必要に応じてツール制御モジュール２５に処
理を依頼する。また、モデル操作モジュール２４は、こ
れらの業務モデル３１とサービスモデル３５を新たに定
義したり、変更したりする処理を行い、定義・変更が行
われたことを定義情報作成モジュール２６に通知する。

【００３１】定義情報作成モジュール２６は、モデル操
作モジュール２４からの通知に基づいて業務モデル３１
とサービスモデル３５を参照し、各ツールに必要な定義
情報３６を作成する。この定義情報３６としては、ツー
ルに対するコマンド等が用いられる。これにより、組
織、文書、作業等の定義・変更が、対応するツールの動
作環境に反映される。

【００３２】ツール制御モジュール２５は、サービス実
行モジュール２３から各ツールを利用するために必要な
情報を受け取り、定義情報３６を用いて必要なツールを
自動的に起動し、それを制御する。あるいはまた、必要
に応じて業務モデル３１とサービスモデル３５を参照す
ることもできる。これにより、ユーザから要求されたサ
ービスを実行するために必要なツールが、自動的に起動
される。

【００３３】このような構成によれば、エンドユーザ
は、どのようなツールを利用するかを意識することな
く、作業開始や文書検索等のサービスを要求することが
でき、必要なツールが自動的に提供される。

【００３４】また、従来、サービス実行モジュール３の
プログラムとして記述されていた種々のサービスは、図
２のシステムでは、モデル管理モジュール２７内に定義
されるサービスモデル３５に従って実現される。サービ
スモデル３５は、業務モデル３１とともに随時変更する
ことが可能であり、その変更は自動的にサービスの内容
に反映される。以下では、エンドユーザとシステム管理
者を含めて、単に、ユーザと呼ぶことにする。

【００３５】図３は、図２の業務支援システムを実現す
る情報処理装置（コンピュータ）の構成図である。図３
の情報処理装置は、ＣＰＵ（中央処理装置）４１、メモ
リ４２、外部記憶装置４３、ディスプレイ４４、入力装
置４５、媒体駆動装置４６、およびネットワーク接続装
置４７を備え、それらの各装置はバス４８により互いに
結合されている。

【００３６】ＣＰＵ４１は、メモリ４２に格納されたプ
ログラムを実行して、ＧＵＩ２１、制御モジュール２
２、サービス実行モジュール２３、モデル操作モジュー
ル２４、ツール制御モジュール２５、定義情報作成モジ
ュール２６、各種ソフトウェアツール等の処理を実現す
る。

【００３７】メモリ４２には、上述のプログラムの他
に、処理に用いられるデータが格納されている。メモリ
４２としては、例えばＲＯＭ（read only memory）、Ｒ
ＡＭ（random access memory）等が用いられる。

【００３８】外部記憶装置４３は、例えば、磁気ディス
ク装置、光ディスク装置、光磁気ディスク（magneto-op
tical disk）装置等であり、業務モデル３１とサービス
モデル３５を記憶するモデル管理モジュール２７のデー
タベースとして使用される。また、外部記憶装置４３に
上述のプログラムとデータを保存しておき、必要に応じ
て、それらをメモリ４２にロードして使用することもで
きる。

【００３９】入力装置４５は、例えばキーボード、ポイ
ンティングデバイス等に相当し、ユーザからの要求や指
示の入力に用いられ、ディスプレイ４４の画面には、シ
ステムからのメッセージや視覚化されたモデル等が表示
される。

【００４０】媒体駆動装置４６は、可搬記録媒体４９を
駆動し、その記録内容にアクセスする。可搬記録媒体４
９としては、メモリカード、フロッピーディスク、ＣＤ
−ＲＯＭ（compact disk read only memory ）、光ディ
スク、光磁気ディスク等、任意のコンピュータ読み取り
可能な記録媒体が用いられる。この可搬記録媒体４９に
上述のプログラムとデータを格納しておき、必要に応じ
て、それらをメモリ４２にロードして使用することがで
きる。

【００４１】ネットワーク接続装置４７は、ＬＡＮ（lo
cal area network）等の任意のネットワーク（回線）を
介して外部の情報提供者の装置５０と通信する。これに
より、必要に応じて、上述のプログラムとデータを装置
５０からネットワークを介して受け取り、それらをメモ
リ４２にロードして使用することができる。

【００４２】次に、図４から図１０までを参照しなが
ら、業務モデル３１とサービスモデル３５をオブジェク
トを用いて構成した例について説明する。ここで、オブ
ジェクトとは、データとそれに適用される手続きの組か
ら成るデータ構造を表す。

【００４３】図４は、業務モデル３１とサービスモデル
３５のデータ構造の例を示している。図４に示される組
織モデル３２、文書モデル３３、および作業モデル３４
において、クラスレベルのオブジェクトはインスタンス
レベルのオブジェクト構造を定義し、インスタンスレベ
ルのオブジェクトは具体的なモデルを表す。

【００４４】また、メタクラスレベルのＰｒｏｊｅｃｔ
Ｍａｎａｇｅｒオブジェクト５１、ＤｏｃｕｍｅｎｔＭ
ａｎａｇｅｒオブジェクト５２、ＴａｓｋＭａｎａｇｅ
ｒオブジェクト５３は、ユーザが組織、文書、作業のそ
れぞれのクラスレベルのモデルを定義することを管理す
る。

【００４５】例えば、組織モデル３２のクラスレベルの
Ｐｒｏｊｅｃｔオブジェクト６１は、ＤｅｓｉｇｎＴｅ
ａｍオブジェクト６２、ＭａｋｅＴｅａｍオブジェクト
６３、およびＴｅｓｔＴｅａｍオブジェクト６４から構
成されることをモデル化するように、ユーザが指示した
とする。すると、メタクラスレベルのＰｒｏｊｅｃｔＭ
ａｎａｇｅｒオブジェクト５１は、Ｐｒｏｊｅｃｔオブ
ジェクト６１と、各オブジェクト６２、６３、６４との
間に、図４の実線で示すようなリンクを張る。

【００４６】ここで、ＤｅｓｉｇｎＴｅａｍオブジェク
ト６２は設計部門を表し、ＭａｋｅＴｅａｍオブジェク
ト６３は生産部門を表し、ＴｅｓｔＴｅａｍオブジェク
ト６４はテスト部門を表す。

【００４７】また、同様にして、ＤｏｃｕｍｅｎｔＭａ
ｎａｇｅｒオブジェクト５２は、Ｄｏｃｕｍｅｎｔオブ
ジェクト６５と、ＤｅｓｉｇｎＤｏｃオブジェクト６
６、ＭａｋｅＤｏｃオブジェクト６７、ＴｅｓｔＤｏｃ
オブジェクト６８の各々との間にリンクを張り、Ｔａｓ
ｋＭａｎａｇｅｒオブジェクト５３は、Ｔａｓｋオブジ
ェクト６９と、ＤｅｓｉｇｎＴａｓｋオブジェクト７
０、ＭａｋｅＴａｓｋオブジェクト７１、ＴｅｓｔＴａ
ｓｋオブジェクト７２の各々との間にリンクを張る。

【００４８】ここで、ＤｅｓｉｇｎＤｏｃオブジェクト
６６、ＭａｋｅＤｏｃオブジェクト６７、ＴｅｓｔＤｏ
ｃオブジェクト６８は、それぞれ設計文書、生産を管理
する文書、テストを管理する文書を表し、Ｄｅｓｉｇｎ
Ｔａｓｋオブジェクト７０、ＭａｋｅＴａｓｋオブジェ
クト７１、ＴｅｓｔＴａｓｋオブジェクト７２は、それ
ぞれ設計工程、生産工程、テスト工程を表す。

【００４９】さらに、破線で示すように、組織モデル３
２と文書モデル３３の間の参照関係、および文書モデル
３３と作業モデル３４の間の参照関係も設定される。こ
こでは、Ｐｒｏｊｅｃｔオブジェクト６１とＤｏｃｕｍ
ｅｎｔオブジェクト６５が関係付けられ、Ｄｏｃｕｍｅ
ｎｔオブジェクト６５とＴａｓｋオブジェクト６９が関
係付けられている。

【００５０】同様に、ＤｅｓｉｇｎＴｅａｍオブジェク
ト６２、ＭａｋｅＴｅａｍオブジェクト６３、Ｔｅｓｔ
Ｔｅａｍオブジェクト６４は、それぞれ、Ｄｅｓｉｇｎ
Ｄｏｃオブジェクト６６、ＭａｋｅＤｏｃオブジェクト
６７、ＴｅｓｔＤｏｃオブジェクト６８と関係付けら
れ、ＤｅｓｉｇｎＤｏｃオブジェクト６６、ＭａｋｅＤ
ｏｃオブジェクト６７、ＴｅｓｔＤｏｃオブジェクト６
８は、それぞれ、ＤｅｓｉｇｎＴａｓｋオブジェクト７
０、ＭａｋｅＴａｓｋオブジェクト７１、ＴｅｓｔＴａ
ｓｋオブジェクト７２と関係付けられている。また、こ
れらのメタクラスレベルのオブジェクトは、クラスレベ
ルのオブジェクトが対応するインスタンスレベルのオブ
ジェクトを生成することも管理する。インスタンスレベ
ルのオブジェクトは生成される際に、クラスレベルの構
造に従って生成されると同時に、対応するクラスオブジ
ェクトとの関係も保持される。

【００５１】例えば、ＰｒｏｊｅｃｔＸオブジェクト８
１、ＤｅｓｉｇｎＴｅａｍＡオブジェクト８２、Ｍａｋ
ｅＴｅａｍＢオブジェクト８３、およびＴｅｓｔＴｅａ
ｍＢオブジェクト８４は、対応するクラスレベルのＰｒ
ｏｊｅｃｔオブジェクト６１、ＤｅｓｉｇｎＴｅａｍオ
ブジェクト６２、ＭａｋｅＴｅａｍオブジェクト６３、
およびＴｅｓｔＴｅａｍオブジェクト６４と同様に、リ
ンクで結合されている。

【００５２】また、ＰｒｏｊｅｃｔＸオブジェクト８
１、ＤｅｓｉｇｎＴｅａｍＡオブジェクト８２、Ｍａｋ
ｅＴｅａｍＢオブジェクト８３、およびＴｅｓｔＴｅａ
ｍＢオブジェクト８４は、それぞれ、Ｐｒｏｊｅｃｔオ
ブジェクト６１、ＤｅｓｉｇｎＴｅａｍオブジェクト６
２、ＭａｋｅＴｅａｍオブジェクト６３、およびＴｅｓ
ｔＴｅａｍオブジェクト６４と関係付けられる。

【００５３】他のモデルのインスタンスレベルのオブジ
ェクトであるＤｏｃｕｍｅｎｔ１オブジェクト８５、Ｄ
ｅｓｉｇｎＤｏｃ１オブジェクト８６、ＭａｋｅＤｏｃ
１オブジェクト８７、ＴｅｓｔＤｏｃ１オブジェクト８
８、Ｔａｓｋオブジェクト８９、ＤｅｓｉｇｎＴａｓｋ
１オブジェクト９０、ＭａｋｅＴａｓｋ１オブジェクト
９１、およびＴｅｓｔＴａｓｋ１オブジェクト９２も同
様にして生成され、それぞれ対応するクラスレベルのオ
ブジェクトと関係付けられる。

【００５４】さらに、インスタンスレベルの異なるモデ
ル間の参照関係もまた、破線で示すように、クラスレベ
ルと同様に設定される。例えば、ＤｅｓｉｇｎＴｅａｍ
Ａオブジェクト８２とＤｅｓｉｇｎＤｏｃ１オブジェク
ト８６とが関係付けられるとともに、ＤｅｓｉｇｎＤｏ
ｃ１オブジェクト８６とＤｅｓｉｇｎＴａｓｋ１オブジ
ェクト９０とが関係付けられる。

【００５５】ただし、これらのオブジェクト間の関係付
けは、時間的に同時に行われる必要はない。したがっ
て、ある時点では、組織モデル３２と文書モデル３３の
間、または、文書モデル３３と作業モデル３４の間に、
互いに関係付けられたオブジェクトが存在しないことも
ある。

【００５６】ここでは、組織モデル３２、文書モデル３
３、作業モデル３４の各モデルのメタクラスレベルのオ
ブジェクトは、クラスレベルのオブジェクトを定義した
り、クラスレベルのオブジェクトからインスタンスレベ
ルのオブジェクトを作成したりする動的なオブジェクト
として生成される。また、クラスレベルおよびインスタ
ンスレベルのオブジェクトは、属性データのみを有する
静的なオブジェクトとして生成される。

【００５７】これに対して、サービスモデル３５はルー
ルの形で記述され、上述の業務モデル３１の各オブジェ
クトとは別に、知識ベースオブジェクトとして管理され
る。図４においては、サービスモデル３５はメタクラス
レベルとクラスレベルに存在する。メタクラスレベルの
メタクラス知識ベースオブジェクト１０１には、メタク
ラスレベルおよびインスタンスレベルのオブジェクトを
参照するサービスが記述され、クラスレベルのクラス知
識ベースオブジェクト１０２には、クラスレベルのオブ
ジェクトを参照するサービスが記述される。

【００５８】図５は、企業における業務モデル３１を視
覚化した表示画面の例を示している。図５の業務モデル
３１はクラスレベルのモデルを表し、“開発作業”等の
各矩形がクラスレベルの１つのオブジェクトに対応す
る。

【００５９】作業モデル３４の例としては、“開発作
業”という作業が定義されている。この“開発作業”
は、“調査”、“検討”、“開発”、“統合テスト”と
いう４つのサブ作業から構成されており、そのことは
“ｃｏｎｓｉｓｔ ｏｆ”というリンクにより表されて
いる。また、これらのサブ作業をこの順番に実行するこ
とは、“ｎｅｘｔ ｔｏ”というリンクによって表され
ている。

【００６０】文書モデル３３では、“研究計画書”、
“バグレポート”、“仕様書”、“開発依頼書”、“議
事録”の５つの文書が定義されており、これらは“ｉｓ
−ａ”というリンクにより“文書”と関係付けられてい
る。

【００６１】組織モデル３２では、組織としての“富士
通研究所”が“ソフトウェア研究部”と“メディア研究
部”から構成されていることが、“ｃｏｎｓｉｓｔ ｏ
ｆ”というリンクにより表されている。実際には、“富
士通研究所”はもっと多くの組織から成っているが、こ
こでは他の組織は省略されている。同様にして、“ソフ
トウェア研究部”は、“プロジェクト１”と“プロジェ
クト２”という２つの組織から構成されている。

【００６２】また、“富士通研究所”に属する人は“研
究員”であり、その職務上の役割によって“設計者”、
“プログラマ”、“マネージャ”に分類されている。
“富士通研究所”と“研究員”は“ｂｅｌｏｎｇ ｔ
ｏ”というリンクにより関係付けられ、“研究員”と
“設計者”、“プログラマ”、“マネージャ”とは、そ
れぞれ“ｉｓ−ａ”というリンクにより関係付けられて
いる。

【００６３】さらに、これらの３つのモデルの間にも互
いに関係が定義される。まず、作業モデル３４に対して
は、各作業に必要な文書（書類）が定義される。例え
ば、“開発作業”を行う際には“開発依頼書”が必要で
あり、これらの間には“ｂｅｌｏｎｇ ｔｏ”というリ
ンクが張られる。同様に、“検討”というサブ作業も
“ｂｅｌｏｎｇ ｔｏ”というリンクにより“仕様書”
と関係付けられている。

【００６４】また、各サブ作業に対しては、その作業を
実行するためにどんな役割を持った人が必要であるか
が、“ｒｏｌｅ”というリンクによって表現される。例
えば、“開発作業”を指示するのは“マネージャ”であ
り、“調査”や“検討”を行うのは“設計者”であり、
“開発”や“統合テスト”を行うのは“プログラマ”の
役割である。

【００６５】また、各組織や個人に必要な書類も“ｂｅ
ｌｏｎｇ ｔｏ”というリンクにより定義される。例え
ば、“ソフトウェア研究部”には“研究計画書”という
書類が関係付けられている。

【００６６】このようにモデルの内容を図で表示するこ
とで、モデルの編集が容易になる。図を用いたモデルの
編集は、既存のＣＡＳＥツールやＣＡＤ（Computer Aid
ed Design ）ツールを用いることで実現され、これによ
り、複雑なオブジェクト間の関係を容易に定義したり変
更したりすることができるようになる。

【００６７】図４で示した各モデルの内容は、インスタ
ンスレベルおよびクラスレベルのオブジェクトが追加さ
れるにつれて、増大する。これらのモデルの内容を、テ
ーブル構造でデータべース化することにより、ユーザは
過去の任意の時点における組織や文書や作業状況等を確
認することが可能になる。

【００６８】ここでは、モデル操作モジュール２４が、
モデルの内容を表すオブジェクトテーブルをモデル管理
モジュール２７内に作成しておく。そして、モデルを定
義・変更した場合は、対応するオブジェクト名と作成日
または削除日をこのオブジェクトテーブルに記録する。
ユーザが確認の問い合わせを入力すると、サービス実行
モジュール２３はモデル管理モジュール２７を参照し
て、オブジェクトテーブルの内容をディスプレイ４４に
表示する。

【００６９】図６は、表示されたオブジェクトテーブル
の例を示している。図６のオブジェクトテーブルには、
オブジェクト名、オブジェクトタイプ、作成日、削除日
の各項目が設けられている。

【００７０】例えば、組織モデル３２のオブジェクト
“ソフトウェア研究部”のタイプは“部”であり、それ
は１９９３年４月１日に作成されたことが分かる。削除
日の欄の“−”はまだ削除されていないことを表す。ま
た、作業モデル３４のオブジェクト“Ａ製品開発作業”
のタイプは“作業”であり、それは１９９４年４月１日
に作成され、同じ日に削除されたことが分かる。

【００７１】モデル操作モジュール２４は、オブジェク
トテーブル以外に、各オブジェクト間の関係を表すリン
クの作成日等をテーブル化したリンクテーブルも作成
し、モデル管理モジュール２７に格納しておく。これに
より、ユーザは過去の任意の時点における参照関係等を
確認することも可能になる。このリンクテーブルの例に
ついては後述することにする。

【００７２】図７は、図４のサービスモデル３５を構成
するメタクラス知識ベースオブジェクト１０１、クラス
知識ベースオブジェクト１０２の構造の例を示してい
る。図７においては、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ
オブジェクト５２、ＴａｓｋＭａｎａｇｅｒオブジェク
ト５３、ＰｒｏｊｅｃｔＭａｎａｇｅｒオブジェクト５
１のそれぞれに対応するサービスの記述が格納されてい
る。以下、図８から図１０までを参照しながら、それぞ
れのサービスの記述の例を説明する。

【００７３】図８は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ
オブジェクト５２に基づいて実行されるサービスの例を
示している。その内容は、“もし属性が設計（ＤＥＳＩ
ＧＮ）であるようなインスタンスレベルの文書が追加さ
れたなら、それに関係付けられている担当者に、ＭＳＧ
ＦＩＬＥというファイルの内容の電子メールを送る”と
いうものである。

【００７４】対応するサービスの記述は、“Ｗｈｅｎ
Ｉｆ−ａｄｄ−ｉｎｓｔａｎｃｅ（Ｘ）＆ｔｙｐｅ
（Ｘ）＝ＤＥＳＩＧＮ ｔｈｅｎ ｍａｉｌ（Ｘ．ａｓ
ｓｏｃ−ｐｅｒｓｏｎ，ＭＳＧＦＩＬＥ）；”のように
なり、例えば、図８の最下段に示したようなメッセージ
が関係者に送られる。

【００７５】ここでは、ＭＳＧＦＩＬＥにあらかじめ用
意された固定メッセージに、斜体の太字で示された語句
が埋め込まれている。“プログラム仕様書”は追加され
た文書名を表し、“山田一郎”はその文書の作成者を表
し、“マルチメディアプログラム開発”はその文書が属
する作業名を表す。このメッセージの受信者は、“プロ
グラム仕様書”の存在を知り、直ちにこれを業務に利用
することができる。

【００７６】このサービスの記述は、モデル操作モジュ
ール２４により定義されたときに、ＤｏｃｕｍｅｎｔＭ
ａｎａｇｅｒオブジェクト５２が解釈可能な形に翻訳さ
れて、モデル管理モジュール２７に格納される。

【００７７】そして、モデル操作モジュール２４からの
指示に従って、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒオブジ
ェクト５２が文書モデル３３のインスタンスを生成した
時に、それが自動的にフック（hook）されて、サービス
実行モジュール２３により実行される。ここで、“フッ
クされる”とは、サービスの記述に記された条件に適合
することを意味する。

【００７８】図９は、ＴａｓｋＭａｎａｇｅｒオブジェ
クト５３に基づいて実行されるサービスの例を示してい
る。その内容は、“もし属性が会議（ＭＥＥＴＩＮＧ）
であるような作業が終了したら、議事録を添付して関係
者にＭＳＧＦＩＬＥというファイルの内容の電子メール
を送る”というものである。

【００７９】対応するサービスの記述は、“Ｗｈｅｎ
Ｉｆ−ｆｉｎｉｓｈ−ｔａｓｋ−ｉｎｓｔａｎｃｅ
（Ｘ）＆ｔｙｐｅ（Ｘ）＝ＭＥＥＴＩＮＧ ｔｈｅｎ
ｍａｉｌ（Ｘ．ａｓｓｏｃ−ｐｅｒｓｏｎ，ＭＳＧＦＩ
ＬＥ）；”のようになり、例えば、図９の最下段に示し
たようなメッセージが関係者に送られる。

【００８０】ここでは、ＭＳＧＦＩＬＥにあらかじめ用
意された固定メッセージに、斜体の太字で示された語句
が埋め込まれている。“マルチメディア開発会議”は終
了した作業名を表し、“５月１５日”はその会議の開催
日を表し、“第１会議室”はその会議の開催場所を表
し、“マルチメディア会議議事録”はその会議の議事録
名を表す。このメッセージの受信者は、“マルチメディ
ア会議議事録”の存在を知り、直ちにこれを業務に利用
することができる。

【００８１】このサービスの記述は、モデル操作モジュ
ール２４により定義されたときに、ＴａｓｋＭａｎａｇ
ｅｒオブジェクト５３が解釈可能な形に翻訳されて、モ
デル管理モジュール２７に格納される。そして、作業モ
デル３３に定義された会議が終了したという情報が入力
されると、それが自動的にフックされて、サービス実行
モジュール２３により実行される。

【００８２】図１０は、ＰｒｏｊｅｃｔＭａｎａｇｅｒ
オブジェクト５１に基づいて実行されるサービスの例を
示している。その内容は、“もし新しい構成員が追加さ
れたら、その構成員に対して、その人自身が属している
組織に関連する文書のリストをＭＳＧＦＩＬＥというフ
ァイルの内容に添付した電子メールを送る”というもの
である。

【００８３】対応するサービスの記述は、“Ｗｈｅｎ
Ｉｆ−ａｄｄ−ｎｅｗ−ｐｅｒｓｏｎ（Ｘ） ｔｈｅｎ
Ｇｒｏｕｐ＝Ｘ．ｂｅｌｏｎｇ−ｇｒｏｕｐ， ｍａ
ｉｌ（Ｘ，ＭＳＧＦＩＬＥ）；”のようになり、例え
ば、図１０の最下段に示したようなメッセージが新構成
員に送られる。

【００８４】ここでは、ＭＳＧＦＩＬＥにあらかじめ用
意された固定メッセージに、斜体の太字で示された語句
が埋め込まれている。“山田一郎”は新しい構成員名を
表し、“マルチメディアプログラム開発”はその配属先
の組織名を表し、“プログラム仕様書”、“マルチメデ
ィアシステム開発計画書”、および“５月度全体会議議
事録”はそのグループに関連する文書のリストを表す。
このメッセージの受信者“山田一郎”は、これらの文書
にアクセスして、直ちに新しい配属先とその業務の概要
を把握することができる。

【００８５】このサービスの記述は、モデル操作モジュ
ール２４により定義されたときに、ＰｒｏｊｅｃｔＭａ
ｎａｇｅｒオブジェクト５１が解釈可能な形に翻訳され
て、モデル管理モジュール２７に格納される。そして、
モデル操作モジュール２４からの指示に従って、Ｐｒｏ
ｊｅｃｔＭａｎａｇｅｒオブジェクト５１が組織モデル
３２の構成員のインスタンスを生成した時に、それが自
動的にフックされて、サービス実行モジュール２３によ
り実行される。

【００８６】このように、サービスモデル３５に基づく
サービスは、業務モデル３１を参照しながら自動的に実
行されて、ユーザに提供される。図８のＤｏｃｕｍｅｎ
ｔＭａｎａｇｅｒオブジェクト５２のサービスの例、お
よび図１０のＰｒｏｊｅｃｔＭａｎａｇｅｒオブジェク
ト５１のサービスの例は、新たにインスタンスが生成さ
れるときに起動されるサービスなので、インスタンス生
成に関するメタクラス知識ベース１０１に格納される。

【００８７】これに対して、図９のＴａｓｋＭａｎａｇ
ｅｒオブジェクト５３の例は、特定のクラスに対応する
すべてのインスタンスに共通するサービスなので、クラ
ス知識ベース１０２に格納される。

【００８８】図８および図９に示したように、業務モデ
ル３１を用いることによって、書類が作成または更新さ
れたときに、その書類に関係する人に自動的にそのこと
を通知することができる。このような通知サービスを関
連通知と呼ぶことにする。

【００８９】例えば、図５の業務モデル３１において、
“統合テスト”を行っている人が“開発依頼書”に対し
て、テスト結果に基づく更新を行うと、業務モデル３１
上のリンクをたどって関係者がリストアップされ、それ
らの人に“開発依頼書”が更新されたことが通知され
る。

【００９０】具体的には、“開発依頼書”とリンク“ｂ
ｅｌｏｎｇ ｔｏ”により繋がっている“開発作業”が
検索され、リンク“ｃｏｎｓｉｓｔ−ｏｆ”によりそれ
と繋がっている“調査”、“検討”、“開発”、“統合
テスト”の各サブ作業が得られる。次に、それらの各サ
ブ作業および“開発作業”とリンク“ｒｏｌｅ”により
繋がっている役割名“設計者”、“プログラマ”、“マ
ネージャ”が検索される。

【００９１】そして、それらの各役割に対応するイスタ
ンスである個人に対して、電子メール等により、“開発
依頼書”の更新が自動的に通知される。こうして、“開
発依頼書”に関係付けられたすべての人に対して関連通
知が行われる。

【００９２】同様の関連通知サービスの例としては、次
のようなものがある。 サービス−１ もし、文書“Ｐｒｏｄｕｃｔ”が更新されたら、“Ｐｒ
ｏｄｕｃｔ” ｂｅｌｏｎｇｓ ｔｏ “Ｗｏｒｋ”の
関係にある作業“Ｗｏｒｋ”を探す。次に、そのような
“Ｗｏｒｋ”すべてについて、“Ｗｏｒｋ” ｃｏｎｓ
ｉｓｔ−ｏｆ“Ｓｕｂｗｏｒｋ”の関係にあるサブ作業
“Ｓｕｂｗｏｒｋ”を探す。次に、そのような“Ｓｕｂ
ｗｏｒｋ”すべてについて、“Ｐｅｒｓｏｎ” ｒｏｌ
ｅ “Ｓｕｂｗｏｒｋ”の関係にある“Ｐｅｒｓｏｎ”
を探す。そして、そのような“Ｐｅｒｓｏｎ”すべてに
対して、“Ｐｒｏｄｕｃｔ”が更新されたという通知を
行う。

【００９３】このような関連通知を行うことで、作成／
更新された文書の情報を、関係者が直ちに共有すること
ができる。これらの関係者は、常に最新の情報に従って
作業を行えるので、業務が効率化される。

【００９４】さらに、業務モデル３１を用いることによ
って、ある作業が開始された際に、その作業によって将
来更新される可能性のある文書をアクセスしている人に
対して、通知を行うことができる。このように、文書が
更新される前に、その文書が更新される可能性があるこ
とを通知するサービスを、先行通知と呼ぶことにする。

【００９５】例えば、あるシステムの“開発作業”のサ
ブ作業である“検討”において、“仕様書”が作成さ
れ、その“仕様書”に基づいてサブ作業“開発”が行わ
れているものとする。このとき、同じシステムについて
新たな“開発作業”が始まったとする。この時点ではま
だ“仕様書”は変更されていないが、この新しい作業が
進めば、サブ作業“検討”において“仕様書”が変更さ
れることが分かる。

【００９６】この場合、現在行っているサブ作業“開
発”は無駄になる可能性があるので、“仕様書”が変更
される可能性があることを、前もってサブ作業“開発”
の担当者に通知しておく。

【００９７】このような先行通知を行うことで、文書が
変更される前に、関係者がその情報を得ることができ
る。これにより、これらの関係者は作業のスケジュール
を変更するなどの処置をとることができるので、このサ
ービスは業務の効率化に大きく寄与する。

【００９８】次に、図１１から図１４までを参照しなが
ら、サービス実行モジュール２３、モデル操作モジュー
ル２４、ツール制御モジュール２５、定義情報作成モジ
ュール２６の処理のフローを説明する。

【００９９】図１１は、ユーザからのサービス要求を受
け取った場合の、サービス実行モジュール２３の処理フ
ローチャートである。図１１において処理が開始される
と、サービス実行モジュール２３は、まず制御モジュー
ル２２からサービス要求を受け取る（ステップＳ１）。
次に、要求に対応するサービスモデル３５をモデル管理
モジュール２７内で検索し（ステップＳ２）、必要に応
じて業務モデル３１を参照しながら、そのサービスを実
行する（ステップＳ３）。

【０１００】このとき、ソフトウェアツールを使用する
必要があるかどうかを判定し（ステップＳ４）、使用し
ない場合は処理を終了する。いずれかのツールを使用す
る場合は、ツール制御モジュール２５を起動してツール
の制御を依頼し（ステップＳ５）、処理を終了する。

【０１０１】図１２は、サービス実行モジュール２３に
より起動されたツール制御モジュール２５の処理フロー
チャートである。図１２において処理が開始されると、
ツール制御モジュール２５は、まずサービス実行モジュ
ール２３より、起動するべきツールとそのツールに指示
すべき処理内容とを受け取る（ステップＳ１１）。次
に、そのツールに対応する定義情報３６を作成し（ステ
ップＳ１２）、それをツールに与えて処理を終了する。

【０１０２】図１３は、モデル操作モジュール２４の処
理フローチャートである。図１３において処理が開始さ
れると、モデル操作モジュール２４は、まずユーザが入
力したモデルの定義・変更の指示を、制御モジュール２
２から受け取り（ステップＳ２１）、それが定義指示か
変更指示かを判定する。

【０１０３】モデルの変更の場合は、対応するモデルを
モデル管理モジュール２７内で検索し（ステップＳ２
３）、そのモデルを指示に従って変更する（ステップＳ
２４）。そして、モデルが変更されたことを定義情報作
成モジュール２６に通知して（ステップＳ２５）、処理
を終了する。

【０１０４】また、モデルの定義の場合は、指示された
モデルを新たに作成し（ステップＳ２６）、モデルが定
義されたことを定義情報作成モジュール２６に通知して
（ステップＳ２５）、処理を終了する。

【０１０５】図１４は、定義情報作成モジュール２６の
処理フローチャートである。図１４において処理が開始
されると、定義情報作成モジュール２６は、まずモデル
操作モジュール２４より、モデルの定義・変更に関する
情報を受け取る（ステップＳ３１）。

【０１０６】次に、そのモデルに対応するモデル対応サ
ービスのサービスモデル３５をモデル管理モジュール２
７内で検索し（ステップＳ３２）、必要に応じて業務モ
デル３１を参照しながら、そのモデル対応サービスを実
行する（ステップＳ３３）。そして、定義情報３６を作
成してそれをツールに与え、処理を終了する。

【０１０７】ここで、モデル対応サービスとは、モデル
の定義・変更に対応して、関連するツールの定義情報３
６を自動的に作成し、それをツールに反映させるサービ
スを意味する。このようなモデル対応サービスの例とし
ては、次のようなものがある。

【０１０８】サービス−２ もし、作業Ｗに新しいサブ作業ＳＷが追加されたなら、
ワークフローツール２８に対して、ａｄｄ−ｎｅｗｔａ
ｓｋ（ＳＷ，Ｗ）というコマンドを送る。

【０１０９】このコマンドは、ワークフローツール２８
が管理する作業Ｗに新たなサブ作業ＳＷを追加する指示
を表し、ワークフローツール２８に対する定義情報３６
に相当する。

【０１１０】モデル対応サービスを利用することで、業
務モデル３１が定義されたとき、定義情報作成モジュー
ル２６は自動的に定義情報３６を作成することができ
る。このとき、定義情報作成モジュール２６は、各ツー
ルを起動／制御するために必要な情報を業務モデル３１
から抽出して、定義情報３６を作成する。

【０１１１】例えば、図５の作業モデル３４では、“開
発作業”が４つのサブ作業から構成されていることが
“ｃｏｎｓｉｎｔ−ｏｆ”関係により定義されており、
それらのサブ作業間の実行順序が“ｎｅｘｔ ｔｏ”関
係によって定義されている。

【０１１２】そこで、定義情報作成モジュール２６は、
これらの関係からワークフローツール２８を利用するた
めに必要な情報を自動的に生成して、ワークフローツー
ル２８に入力する。しかし、システムのユーザは、この
ワークフローツール２８の定義情報３６のデータ構造を
知っておく必要はない。

【０１１３】同様のことは、業務モデル３１が変更され
た際にも行われる。例えば、新しいサブ作業が追加され
た際には、自動的にワークフローツール２８の情報も変
更される。また、使用ツールが変更された際には、定義
情報作成モジュール２６のみを変更すればよく、業務モ
デル３１自体を変更する必要はない。

【０１１４】このようにして、ユーザはどのようなツー
ルが使われているかを意識する必要はなく、業務モデル
３１およびサービスモデル３５を管理することによっ
て、企業活動の変化に対応していくことができる。

【０１１５】例えば、クラスレベルのＴａｓｋオブジェ
クト６９やＤｅｓｉｇｎＴａｓｋオブジェクト７０等に
は、その作業の手順が記述されている。ツール制御モジ
ュール２５または定義情報作成モジュール２６は、この
作業手順に従って、ワークフローツール２８が必要とす
る作業手順の定義ファイルを作成することができる。そ
して、これらのモジュール２５、２６は、その定義ファ
イルを定義情報３６としてワークフローツール２８に与
えて、それを制御する。

【０１１６】また、文書管理ツール２９を動作させるに
は、定義情報３６として、文書間の関係を規定した関係
テーブルが必要となる。そこで、ツール制御モジュール
２５または定義情報作成モジュール２６は、Ｄｏｃｕｍ
ｅｎｔオブジェクト６５やＤｅｓｉｇｎＤｏｃオブジェ
クト６６等のクラスオブジェクトの定義内容に従って関
係テーブルを作成する。インスタンスレベルのオブジェ
クトの情報は、その関係テーブルおよび文書管理ツール
２９に従って格納される。

【０１１７】このように、ツールによって必要な情報は
異なるため、ツール毎にそれぞれ異なる定義情報３６が
生成される。さらに、組織モデル３２を利用することに
よって、ユーザの所属に応じて適切にツールの定義情報
３６を作成することができる。例えば、ワークフローツ
ール２８を利用する際には、各サブ作業の作業者を割り
当てることが必要であるが、本システムでは、ユーザが
所属する組織から適切な作業員を選んで自動的に割り当
てることができる。これは、次のようなサービスにより
実現される。

【０１１８】サービス−３ もし、ユーザＡが作業Ｗの実行を指示したら、作業Ｗか
ら“ｃｏｎｓｉｓｔ−ｏｆ”関係をたどって各サブ作業
ＳＷを検索する。次に、各サブ作業ＳＷから“ｒｏｌ
ｅ”関係をたどって対応する役割Ｒを検索し、ユーザＡ
が属する組織の中から、役割Ｒを持っている研究員Ｂを
検索する。次に、ワークフローツール２８に対して、サ
ブ作業ＳＷの作業者として研究員Ｂを割り当てるよう
に、ツール制御モジュール２５に通知する。

【０１１９】このサービスをサービス実行モジュール２
３が実行すると、ツール制御モジュール２５は、ｓｅｔ
−ｒｏｌｅ（ＳＷ，Ｂ）というコマンドを、定義情報３
６としてワークフローツール２８に送る。このコマンド
は、ワークフローツール２８が管理するサブ作業ＳＷの
作業者として、研究員Ｂを割り当てることを指示してい
る。

【０１２０】例えば、図５のサブ作業“開発”の場合、
リンク“ｒｏｌｅ”をたどることにより役割“プログラ
マ”が検索される。この“プログラマ”のインスタンス
として、３人の個人名ＡＡＡ、ＢＢＢ、ＣＣＣが存在し
たとする。次に、ユーザＡが属する組織が“プロジェク
ト１”で、そのインスタンスとして、５人の個人名ＢＢ
Ｂ、ＤＤＤ、ＥＥＥ、ＦＦＦ、ＧＧＧが存在したとす
る。このとき、“プロジェクト１”に属する“プログラ
マ”であるＢＢＢが、サブ作業“開発”の作業者として
割り当てられる。

【０１２１】次に、図１５から図２０までを参照しなが
ら、業務モデル３１の変更例について説明する。図１５
は、画面表示された変更前の作業モデル３４を示してい
る。図１５の作業モデル３４において、“開発作業”は
“調査”、“開発”、“統合テスト”の３つのサブ作業
から成っている。ここで、“調査”と“開発”の間に新
たにサブ作業“検討”を付け加えると、作業モデル３４
は図１６に示すように変更される。

【０１２２】このとき、作業モデル３４を表す前述のオ
ブジェクトテーブルとリンクテーブルは、変更前には図
１７に示すようになり、変更後には図１８に示すように
なる。

【０１２３】図１７において、オブジェクトテーブルに
は、４つのクラスレベルのオブジェクト“開発作業”、
“調査”、“開発”、“統合テスト”が登録され、それ
らの作成日が記されている。これらの４つのオブジェク
トは、いずれも４月に作成されている。リンクテーブル
には、これらの各オブジェクト間の関係を表すリンク自
身がオブジェクトとして登録され、各リンクのリンク元
およびリンク先のオブジェクト名と作成日が記されてい
る。

【０１２４】例えば、リンクテーブル内の１番目のリン
ク“ｃｏｎｓｉｓｔ−ｏｆ”は、“開発作業”と“調
査”を関係付けるリンクであり、４番目のリンク“ｎｅ
ｘｔｔｏ”は、“調査”と“開発”を関係付けるリンク
であることが分かる。これらのリンクの作成日は、上記
オブジェクトの作成日と同じ４月になっている。

【０１２５】これに対して、図１８のオブジェクトテー
ブルにおいては、新たなオブジェクト“検討”が５月に
作成されたことが記されている。これに対応して、リン
クテーブルにも、新たに３つのリンク“ｃｏｎｓｉｓｔ
−ｏｆ”、“ｎｅｘｔ ｔｏ”、“ｎｅｘｔ ｔｏ”が
５月に付け加えられている。これらのリンクは、“検
討”と他の既存のオブジェクトとの関係を定義してい
る。

【０１２６】また、“調査”と“開発”の間にサブ作業
“検討”が挿入されたのに伴い、“調査”と“開発”を
結合していたリンク“ｎｅｘｔ ｔｏ”が５月に削除さ
れたことが分かる。

【０１２７】このように、オブジェクトテーブルとリン
クテーブルを用いて業務モデル３１の更新履歴を管理す
ることで、過去の任意の時点における業務モデル３１の
構成を再現し、ユーザに提示することが可能になる。

【０１２８】同様に、図１９は画面表示された変更前の
組織モデル３２を示しており、図２０は変更後の組織モ
デル３２を示している。図２０においては、“メディア
研究部”と“プロジェクト２”が新たな組織として付け
加えられている。この変更に伴い、組織モデル３２のオ
ブジェクトテーブルとリンクテーブルも、図１８の場合
と同様にして更新される。

【０１２９】サービスモデル３５についても同様にし
て、その更新履歴を管理することができる。このような
モデルの変更は、ＧＵＩ２１を介して、ディスプレイ４
４の画面上でユーザが指示し、新たなモデルの定義も、
同様に画面上で行うことができる。

【０１３０】ところで、クラスレベルの業務モデル３１
が変更された場合、新たに追加されるインスタンスレベ
ルのオブジェクトは、変更後のクラスレベルのオブジェ
クトに従って生成される。この新たなインスタンスオブ
ジェクトと、変更前に既に生成されていた他のインスタ
ンスオブジェクトとの関係を付ける際には、以下の２通
りの方法がある。 （方法１）新たに他のオブジェクトとの関係を付けるこ
とはできないようにする。 （方法２）変更前のクラスレベルのモデルに従って、他
のオブジェクトとの関係を付ける。

【０１３１】ここで、変更前のインスタンスか変更後の
インスタンスかの区別は、インスタンス生成時にクラス
レベルとの対応関係が付けられているので、判断可能で
ある。

【０１３２】インスタンスレベルのオブジェクトを消去
する場合は、それと対応付けられているクラスレベルの
オブジェクト、および他のインスタンスレベルのオブジ
ェクトとの関係付けのリンク情報を消去しておく。ま
た、インスタンスオブジェクトの内容のみを更新する場
合は、リンク情報をそのまま残しておく。

【０１３３】以上説明したように、本発明の業務支援シ
ステムでは、従来のようにソフトウェアツールをもとに
して構築されたシステムと異なり、業務やサービスのモ
デルに基づいて、自動的に必要なツールや文書等のリソ
ースを呼び出すことができる。したがって、ユーザはツ
ールやリソースの存在を意識せずに、業務を遂行するこ
とが可能となる。

【０１３４】また、従来のように個別かつ直接的に必要
な情報を定義してシステムを構築するのではなく、本発
明のシステムでは、モデルに定義されている情報を用い
て、間接的にツールに必要な情報を作成し、ツールを制
御する。この方式によって、同種或いは異種のツール間
で、組織／作業／文書に関する同じ情報を共有し、情報
の一貫性を保つことができる。

【０１３５】さらに、サービスに対するツールの組み込
み方法を一元化するため、ツール毎に個別にプログラミ
ングする必要がなく、システム構築のコスト削減に寄与
する。

【０１３６】以上の実施形態において、業務モデル３１
およびサービスモデル３５を、オブジェクトを用いて構
成しているが、これらのモデルの構成方法はこれに限ら
れず、任意のデータ構造を用いることができる。また、
業務モデル３１が対象とする組織は、必ずしも企業のよ
うな営利団体でなくてもよく、例えばボランティア組織
のような非営利団体の業務管理にも、本発明の業務支援
システムを適用することができる。

【０１３７】

【発明の効果】本発明によれば、業務内容に伴って頻繁
に変更される組織、文書、作業手順、および提供サービ
スを、モデルとして独立に定義することができる。これ
により、これらのモデル部分を、他の実装部分と分け
て、容易に変更することが可能になる。また、ツールや
リソースを自動的に起動したり、利用したりすることが
でき、ユーザはそれらの存在を意識することなく、業務
を遂行することができる。

【図面の簡単な説明】

【図１】本発明の業務支援システムの原理図である。

【図２】業務支援システムの構成図である。

【図３】情報処理装置の構成図である。

【図４】モデルの構造を示す図である。

【図５】業務モデルの表示画面を示す図である。

【図６】オブジェクトテーブルの例を示す図である。

【図７】サービスモデルの構造を示す図である。

【図８】ＤｏｃｕｍｅｎｔＭａｎａｇｅｒのサービスの
例を示す図である。

【図９】ＴａｓｋＭａｎａｇｅｒのサービスの例を示す
図である。

【図１０】ＰｒｏｊｅｃｔＭａｎａｇｅｒのサービスの
例を示す図である。

【図１１】サービス実行モジュールの処理フローチャー
トである。

【図１２】ツール制御モジュールの処理フローチャート
である。

【図１３】モデル操作モジュールの処理フローチャート
である。

【図１４】定義情報作成モジュールの処理フローチャー
トである。

【図１５】変更前の作業モデルの画面を示す図である。

【図１６】変更後の作業モデルの画面を示す図である。

【図１７】変更前の作業モデルに対応するテーブルを示
す図である。

【図１８】変更後の作業モデルに対応するテーブルを示
す図である。

【図１９】変更前の組織モデルの画面を示す図である。

【図２０】変更後の組織モデルの画面を示す図である。

【図２１】従来の業務支援システムを示す図である。

【符号の説明】

１ ユーザインタフェース ２、２２ 制御モジュール ３、２３ サービス実行モジュール ４ データベース管理モジュール ５ 文書情報 １１ サービス手段 １２ 業務モデル記憶手段 １３ サービスモデル記憶手段 １４ モデル操作手段 ２１ ＧＵＩ ２４ モデル操作モジュール ２５ ツール制御モジュール ２６ 定義情報作成モジュール ２７ モデル管理モジュール ２８ ワークフローツール ２９ 文書管理ツール ３１ 業務モデル ３２ 組織モデル ３３ 文書モデル ３４ 作業モデル ３５ サービスモデル ３６ 定義情報 ４１ ＣＰＵ ４２ メモリ ４３ 外部記憶装置 ４４ ディスプレイ ４５ 入力装置 ４６ 媒体駆動装置 ４７ ネットワーク接続装置 ４８ バス ４９ 可搬記録媒体 ５０ 情報提供者の装置 ５１、５２、５３、６１、６２、６３、６４、６５、６
６、６７、６８、６９、７０、７１、７２、８１、８
２、８３、８４、８５、８６、８７、８８、８９、９
０、９１、９２、１０１、１０２ オブジェクト

フロントページの続き (72)発明者 大久保 隆夫 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 金谷 延幸 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 堀田 勇次 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内

Claims (21)

【特許請求の範囲】
1. 【請求項１】 ユーザの業務を表す業務モデルを記憶す
   る業務モデル記憶手段と、 前記ユーザに提供されるサービスを表すサービスモデル
   を記憶するサービスモデル記憶手段と、 前記ユーザからサービス要求を受け取ったとき、前記業
   務モデルを参照しながら、前記サービスモデルに対応す
   るサービスを提供するサービス手段とを備えることを特
   徴とする業務支援システム。
2. 【請求項２】 前記業務モデル記憶手段は、組織構成を
   表す組織モデル、文書構成を表す文書モデル、および作
   業手順を表す作業モデルのうち少なくとも１つを含む前
   記業務モデルを記憶することを特徴とする請求項１記載
   の業務支援システム。
3. 【請求項３】 前記業務モデル記憶手段は、組織を構成
   する構成員および該構成員の所属を表す組織モデルを含
   む前記業務モデルを記憶し、前記サービス手段は、構成
   員や所属に応じたサービスを提供することを特徴とする
   請求項１記載の業務支援システム。
4. 【請求項４】 前記業務モデル記憶手段は、組織構成を
   表す組織モデル、文書構成を表す文書モデル、および作
   業手順を表す作業モデルを含む前記業務モデルを記憶
   し、該組織モデル、文書モデル、および作業モデルは互
   いに関係付けられており、前記サービス手段は、該組織
   モデル、文書モデル、および作業モデルの間の関係をた
   どりながら必要な情報を取り出し、該情報を用いて前記
   サービスを提供することを特徴とする請求項１記載の業
   務支援システム。
5. 【請求項５】 前記サービス手段は、組織、文書、作業
   のいずれかの内容に変更があったとき、該業務モデルを
   用いて該変更に関連する構成員を検索し、該変更があっ
   たことを該構成員に通知することを特徴とする請求項４
   記載の業務支援システム。
6. 【請求項６】 前記業務モデル記憶手段は、組織構成を
   表す組織モデルと文書構成を表す文書モデルを含む前記
   業務モデルを記憶し、前記サービス手段は、該業務モデ
   ルを用いて、新たに作成された文書に関連する構成員を
   検索し、該文書が作成されたことを該構成員に通知する
   ことを特徴とする請求項１記載の業務支援システム。
7. 【請求項７】 前記業務モデル記憶手段は、組織構成を
   表す組織モデルと文書構成を表す文書モデルを含む前記
   業務モデルを記憶し、前記サービス手段は、該業務モデ
   ルを用いて、更新された文書に関連する構成員を検索
   し、該文書が更新されたことを該構成員に通知すること
   を特徴とする請求項１記載の業務支援システム。
8. 【請求項８】 前記業務モデル記憶手段は、組織構成を
   表す組織モデル、文書構成を表す文書モデル、および作
   業手順を表す作業モデルを含む前記業務モデルを記憶
   し、前記サービス手段は、該業務モデルを用いて、開始
   された作業に基づいて更新される可能性のある文書に関
   連する構成員を検索し、該文書が更新される可能性のあ
   ることを該構成員に通知することを特徴とする請求項１
   記載の業務支援システム。
9. 【請求項９】 前記業務モデルおよび前記サービスモデ
   ルの少なくとも１つを変更することのできるモデル操作
   手段をさらに備えることを特徴とする請求項１記載の業
   務支援システム。
10. 【請求項１０】 前記業務モデルおよび前記サービスモ
    デルの少なくとも１つの内容を視覚的に表示するグラフ
    ィック・ユーザインタフェース手段をさらに備え、ユー
    ザが該グラフィック・ユーザインタフェース手段を介し
    て、前記業務モデルおよび前記サービスモデルの少なく
    とも１つを定義／変更することができることを特徴とす
    る請求項１記載の業務支援システム。
11. 【請求項１１】 前記サービス手段は、前記業務モデル
    を参照しながら、ソフトウェアツールを運用するために
    必要となる定義情報を生成し、該定義情報を該ソフトウ
    ェアツールに与える定義情報生成手段を備えることを特
    徴とする請求項１記載の業務支援システム。
12. 【請求項１２】 前記サービス手段は、前記業務モデル
    を参照しながら、ソフトウェアツールを運用するために
    必要となる定義情報を生成し、該定義情報を該ソフトウ
    ェアツールに与えて、該ソフトウェアツールを起動する
    ツール制御手段を備えることを特徴とする請求項１記載
    の業務支援システム。
13. 【請求項１３】 前記業務モデルおよび前記サービスモ
    デルの少なくとも１つの更新履歴を蓄える履歴記憶手段
    をさらに備えることを特徴とする請求項１記載の業務支
    援システム。
14. 【請求項１４】 ユーザの業務を表す業務モデルを記憶
    する業務モデル記憶手段と、 前記ユーザからサービス要求を受け取ったとき、前記業
    務モデルを参照しながら、ソフトウェアツールを運用す
    るために必要となる定義情報を生成し、該定義情報を該
    ソフトウェアツールに与えて、該ソフトウェアツールを
    起動するツール制御手段とを備えることを特徴とする業
    務支援システム。
15. 【請求項１５】 ユーザの業務を表す業務モデルを記憶
    する業務モデル記憶手段と、 前記業務モデルが変更されたとき、ソフトウェアツール
    を運用するために必要となる定義情報を、変更された業
    務モデルに応じて生成し、該定義情報を該ソフトウェア
    ツールに与える定義情報生成手段とを備えることを特徴
    とする業務支援システム。
16. 【請求項１６】 コンピュータのためのプログラムを記
    録した記録媒体であって、 ユーザの業務を表す業務モデルを作成する機能と、 前記ユーザに提供されるサービスを表すサービスモデル
    を作成する機能と、 前記ユーザからサービス要求を受け取ったとき、前記業
    務モデルを参照しながら、前記サービスモデルに対応す
    るサービスを提供する機能とを前記コンピュータに実現
    させるためのプログラムを記録したコンピュータ読み取
    り可能な記録媒体。
17. 【請求項１７】 コンピュータのためのプログラムを記
    録した記録媒体であって、 ユーザの業務を表す業務モデルを作成する機能と、 前記ユーザからサービス要求を受け取ったとき、前記業
    務モデルを参照しながら、ソフトウェアツールを運用す
    るために必要となる定義情報を生成し、該定義情報を該
    ソフトウェアツールに与えて、該ソフトウェアツールを
    起動する機能とを前記コンピュータに実現させるための
    プログラムを記録したコンピュータ読み取り可能な記録
    媒体。
18. 【請求項１８】 コンピュータのためのプログラムを記
    録した記録媒体であって、 ユーザの業務を表す業務モデルを作成する機能と、 前記業務モデルが変更されたとき、ソフトウェアツール
    を運用するために必要となる定義情報を、変更された業
    務モデルに応じて生成し、該定義情報を該ソフトウェア
    ツールに与える機能とを前記コンピュータに実現させる
    ためのプログラムを記録したコンピュータ読み取り可能
    な記録媒体。
19. 【請求項１９】 ユーザの業務を表す業務モデルを作成
    し、 前記ユーザに提供されるサービスを表すサービスモデル
    を作成し、 前記ユーザからサービス要求を受け取ったとき、前記業
    務モデルを参照しながら、前記サービスモデルに対応す
    るサービスを提供することを特徴とする業務支援方法。
20. 【請求項２０】 ユーザの業務を表す業務モデルを作成
    し、 前記ユーザからサービス要求を受け取ったとき、前記業
    務モデルを参照しながら、ソフトウェアツールを運用す
    るために必要となる定義情報を生成し、 該定義情報を該ソフトウェアツールに与えて、該ソフト
    ウェアツールを起動することを特徴とする業務支援方
    法。
21. 【請求項２１】 ユーザの業務を表す業務モデルを作成
    し、 前記業務モデルが変更されたとき、ソフトウェアツール
    を運用するために必要となる定義情報を、変更された業
    務モデルに応じて生成し、 該定義情報を該ソフトウェアツールに与えることを特徴
    とする業務支援方法。