JP4399127B2

JP4399127B2 - 文書管理方法及び装置並びにその処理プログラム及びそれを格納した記憶媒体

Info

Publication number: JP4399127B2
Application number: JP2001142560A
Authority: JP
Inventors: 光彦吉村; 憲之村上; 恭弘南部; 勇次河岸
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2001-05-14
Filing date: 2001-05-14
Publication date: 2010-01-13
Anticipated expiration: 2021-05-14
Also published as: CA2385814A1; EP1258818A2; JP2002342317A; CA2385814C; EP1258818A3; US20020169753A1; US7089268B2

Description

【０００１】
【発明の属する技術分野】
本発明は、文書管理技術における文書の変更通知に関わるものである。
【０００２】
【従来の技術】
従来の文書管理システムとして、以下のものが知られている。特開平１０−２６９０７１においては、複合ドキュメントにおいてドキュメント要素を共用する場合、共用ドキュメント要素が変更されたことを、複合ドキュメントの利用者に通知するシステムが述べられている。
【０００３】
特開平１０−２２２５３４においては、類似語をもつ文書間の関連に基づいて変更通知を行うシステムが述べられている。特開平１０−３０２０１４では、ユーザの文書閲覧履歴をログ情報として管理し、文書変更が行われた際には、ログ情報に基づいて、過去参照したユーザに対し文書変更通知を行うシステムが述べられている。
【０００４】
特開平１１-１５７１６では、ウェッブサーバ上で管理する文書が更新された時に、クライアント側に文書変更通知を行うシステムが述べられている。米国特許５，６２３，６５５では、共有文書が更新された時に、この共有文書を参照してユーザに対して、メールなどを用いた文書変更通知を行うシステムが述べられている。
【０００５】
米国特許６，０８８、７０７では、ウェッブサーバ上で管理される文書の変更通知を行い、更新されたサイトの一覧と、変更内容の表示を行うものである。
【０００６】
また、Standard Generalized Markup Language（SGML）、eXtensible Markup Language（XML）などの構造化文書記述言語などを用い、あらかじめ文書の構成要素単位に文書関連づけを定義したテンプレート文書を作成し、前述したテンプレート文書に基づいた文書管理を行うシステムが知られている。
【０００７】
【発明が解決しようとする課題】
ソフトウェアや医薬品などの新製品の開発業務では、製品開発プロジェクトを遂行するために、複数の作業者が共同で、多種多様な種類の文書を作成する場合がある。たとえば、製品開発を行うに当たっては、作業者Aがプロジェクト全体の方針をまとめた「プロジェクト文書」を作成し、「プロジェクト文書」に基づいたサブタスク毎に作業者B、Cが各自の「サブタスク文書」を作成する。作業者Aの作成した「プロジェクト文書」には、全体スケジュールなどの内容が含まれており、作業者Bは「プロジェクト文書」を参照しながら、「サブタスク文書」の作成を行う。作業者Aが「プロジェクト文書」における全体スケジュールを変更すると、作業者Bは「プロジェクト文書」の変更内容に基づいて「サブタスク文書」の変更を行うことになる。上記のように、複数作業者が共同で文書作成を行う業務では、作成文書の種類や文書同士の関連が複雑になるにつれ、他の文書作成者に対して文書変更通知を忘れることがある。この結果、他作業者は古いバージョンの文書に基づいて作業を行い、最終的には不要な文書作成業務を行ってしまう。つまり、文書変更通知が正しく行われないため、文書作成作業において手戻りが生じる。
【０００８】
従来技術の文書変更通知では、作業者に応じてどのように文書変更通知を行うべきかが考慮されていない。従来システム上で前記の「プロジェクト文書」を管理した場合、プロジェクト文書の作成者や、これを常時参照するユーザにとっては、文書変更通知を受け取ることができる。しかし、「プロジェクト文書」以外のサブタスク文書作成者には、文書変更通知が届かない。常に自分の関連する文書を意識して、担当範囲外の文書の更新状況を調べざるをえない。担当以外の文書の状態を確認する事に多くの手間や工数を要する。システムの機能として、関連文書の更新状況を容易に確認する支援機能がないため、文書作成作業において手戻りが発生するという課題が生じる。
【０００９】
本発明の目的は、文書の登録または変更の通知を送るユーザが検索可能な文書管理方法およびシステムを提供することにある。
【００１０】
【課題を解決するための手段】
本発明では、上記課題を改善するために、ユーザが登録または更新した文書を管理する文書管理方法において、以下の処理を行う。
【００１１】
格納した文書を登録または更新するユーザに当該文書の登録または更新を知らせるユーザおよびキーワードとを対応付けて保持しておく。上記更新したユーザが上記文書を更新したとき設定された検索条件で上記キーワードを検索する。該当キーワードに対応する上記変更を知らせるユーザに文書変更を通知する。各ユーザはこのシステム側が生成した変更通知情報により、参照している文書のいずれが更新されたかを知ることができる。
【００１２】
【発明の実施の形態】
本実施例の概要を図１に示す。これを用いて本発明の概略を説明する。
本発明では、まず文書管理Database（以下DBと略す）１００において、文書変更通知モデル１１０を管理する。文書変更通知モデル１１０は、文書種別１１１、キーワード１１２、文書種別間の関連１１３よりなる。
文書種別１１１は業務などで扱われる文書種別を表すものであり、図１上では、文書種別の例として、「プロジェクト方針書」、「DB仕様書」、「画面仕様書」そして「DB内部設計書」を示している。
【００１３】
キーワード１１２は、各々の文書種別毎に定義するキーワードである。図１に示すように、各文書種別１１１は、文書種別毎に必要とされるキーワードの一覧を保持する。このキーワードは、例えば各文書種別毎に必要とされる章や節などのタイトルをキーワード一覧として登録しておくものである。例えば図１の文書種別「プロジェクト方針書」では、キーワードの一覧として、「スケジュール」、「DB開発方針」、「画面開発方針」が登録されている。他の文書種別である「DB仕様書」「画面仕様書」そして「DB内部設計書」についても同様にキーワードを保持している。
【００１４】
文書種別間の関連１１３は、すでに述べた文書種別に対し、「どの文書を参照して次の文書を作成するか」を示すための関連づけを行うものである。図１の例では、文書種別間の関連づけ１１３は、「プロジェクト方針書」と「画面仕様書」を向きのもつ矢印で関連づけている。そしてこのことは、「プロジェクト方針書」の内容を参照することにより「画面仕様書」が作成されることを示している。そして、前述したキーワード１１２は、文書参照関係の関連づけ１１３が定義されている文書種別間のみにおいて、キーワード同士の対応関係を定義することが許されている。例えば図１では「プロジェクト方針書」と「画面仕様書」が、文書参照関係の関連づけ１１３によって関連づけられているので、このことは「プロジェクト方針書」のキーワード「スケジュール」が変更された場合には、「画面仕様書」のキーワード「スケジュール」に対して変更通知を行うことを示している。
【００１５】
以上、本発明の文書変更通知モデル１１０を説明した。
次に文書変更通知モデル１１０に基づく、本発明の処理概要を説明する。図１を用いて、文書登録者１と文書登録者２との間での処理例を説明する。
【００１６】
まず文書登録者１は、文書ファイル「PJ.doc」の登録を行う。登録時には、図５に示す文書更新画面１８０を用いる。文書登録・更新画面１８０において、まず文書ファイルに応じた文書種別名１８２を選択する。この場合、文書種別「プロジェクト方針書」を選択するものとする。すると、文書登録画面１８０の文書種別キーワード一覧１８３上に、登録すべき文書種別に対応したキーワードの一覧が表示される。図５の例では、プロジェクト方針書のキーワードとして定義されているスケジュール、DB開発方針、画面開発方針、を表示している。文書登録者１は、文書登録画面１８０画面から必要となるキーワードを選択する。例えば画面開発方針を選択する。すると、この選択した項目を変更キーワード一覧１８５に表示する。この変更キーワードと登録すると、システム側において、図１に示すように文書ファイル「PJ.doc」と、キーワード「画面開発方針」との間を関連づけ、システム上に登録する。この関連づけを、「キーワード・文書ファイル間の関連づけ」と呼ぶ。図１では「キーワード・文書ファイル間の関連づけ１０」としてこの関連づけの例を示している
すると、図１より明らかなように、PJ.docとGUI.docは、文書変更通知モデル１００を通じて、間接的に対応づけられている。システム側が、文書変更通知モデル１００において管理されている対応関係をたどることにより、対応先文書GUI.docを検出することができる。図１では、システム側でたどる対応関係の流れを実線１１４にて示している。システム内部で検出された文書変更の結果は、一旦，文書変更通知情報１４０として保持する。なお、以下では、変更の発生元となる文書ファイルのことを変更元文書ファイルと呼び、実線１１４などの対応関係をたどることにより検出した文書ファイルのことを影響先文書ファイルと呼ぶことにする。
【００１７】
次に、文書登録者２が、文書管理システムにログインする。すると、システム側では、ユーザ情報１４０を用いてユーザ認証とユーザの担当する文書種別の検出を行う。そして引き続きシステム側では、文書変更通知情報１４０を参照することにより、ログインユーザに基づいた文書変更情報の検出と通知処理を行う。図６に文書変更通知画面１９０を示す。この画面上には、各ユーザの登録文書に対する変更通知情報を表示する。図６に示す文書変更通知画面１９０を通じて、文書登録者２は、自文書GUI.docに影響を与える変更がなされたことを知ることができる。図６の文書変更通知画面１９０において、１９６にて示す登録文書名GUI.docをマウス等で選択すると、「変更文書・キーワード一覧１９４」に、変更元文書PJ.docの変更理由、キーワードなどの詳細情報を表示する。
【００１８】
次に、図１におけるユーザ情報１３０と文書変更通知情報１４０を説明する。図１に示すように、ユーザ情報１３０は、識別子U_ID１３１と、ユーザ名１３２、パスワード１３３、文書種別１３４よりなる。文書種別名１３４には、各ユーザが文書作成を担当する文書種別名を格納する。
【００１９】
図４に示すように、文書変更通知情報１４０は、変更元文書情報４１０、影響先文書情報４２０より構成される。変更元文書情報４１０には、変更側の文書ファイルに対する管理情報を格納する。変更元文書情報４１０は、識別子であるKW_ID４１１、文書種別４１２、文書名４１３、ユーザ名４１４、登録日時４１５、キーワード４１６、変更理由４１７よりなる。ユーザ名４１４の値は、ユーザ名１３２に含まれるものである。キーワード４１６には、文書ファイル上で更新した内容に対応して、文書登録者が選択したキーワードを格納する。変更理由４１７には、キーワード４１６に対応して「どのような理由でどのような修正をおこなったか」を説明するためのコメントを格納する。
【００２０】
影響先文書情報４２０には、変更文書により影響をうける側の文書に対する管理情報を格納する。影響先文書情報４２０は、識別子であるIKW_ID４２１、影響先文書種別４２２、影響先文書名４２３、影響先ユーザ名４２４、影響先キーワード４２５、更新元KW_ID４２６よりなる。影響先文書種別４２２、影響先文書名４２３、影響先ユーザ名４２４、影響先キーワード４２５には、おのおの影響先文書側の文書種別、文書名、ユーザ名、キーワードを格納する。更新元KW_ID４２６には、変更側文書ファイルの情報を変更元文書情報４１０より特定するためのKW_ID４１１を格納する。
【００２１】
以上で、本発明にて管理する内部情報の説明を終える。以下では、本発明を実現するための詳細な処理について説明を行う。本発明のシステム構成例を図３に示す。図３では、文書管理システム３４０と端末３１０．３２０、３３０と、文書管理DB１００が示されている。文書管理システム３４０と端末との間は、Local Area Network(LAN)３５０や、Internet３３０などのネットワークより接続されている。図では一部省略しているが、文書管理システム３４０および端末３１０．３２０、３３０は、通常のコンピュータがもつCPU、記憶装置およびマウス・キーボードなどの入力装置を備えているものとする。
【００２２】
文書管理DB１００には、図１に示した文書変更通知モデル１１０および文書ファイル１２０、文書変更通知情報１３０、ユーザ情報１４０を保持する。文書管理システム３４０の主記憶装置３４２には、定義情報登録処理１５０、文書登録処理１６０、文書変更通知処理１７０、を配置する。端末３１０の主記憶装置３１２には、文書管理システム３４０上のアプリケーションを利用するためのブラウザ３１３が配置されている。本ブラウザを利用することにより、端末側で、本発明で述べる一連の機能を操作する。
【００２３】
なお、図２に示す構成は一例である。本発明では、ネットワーク構成やプロトコルについては、既存技術を利用するため、図２以外の構成のみに限定されない。図に示すネットワークには、LANなどに限らず、他の方式によるネットワーク接続において本発明内容を実現することが可能である。そしてサーバ構成についても、本発明の内容を、Webサーバ、ゲートウェイサーバーなどを適宜追加した構成で実現することが可能である。また、本発明の内容を、Webベースのアプリケーションソフトウェアとして実現することも可能である。また、文書管理システムと端末における処理配置についても、図２に示すものに限らない。例えばすべての処理を端末側に配置するなどの構成が、図２以外の構成として考えられる。これは、ソフトウェアのモジュール配置を変更するのみで可能であり、本発明の内容には影響を与えない。
【００２４】
以下では、各処理の詳細について図面を用いて説明する。まず、本発明のメイン処理フローを、図７を用いて説明する。ステップ７０１では、システムのログイン画面を表示する。このログイン画面は、ユーザ名とパスワード入力が可能である。ステップ７０２では、ユーザから入力されたユーザ名とパスワードが、図４におけるユーザ情報１３０上に存在するかを判定する。存在した場合にはステップ７０３を行い。存在しなかった場合には、システムを終了する。
ステップ７０３では、ログインユーザに対応した文書種別を、図４におけるユーザ情報１３０より取得する。
ステップ７０４では、図６に示す文書更新通知画面１９０を開く。
ステップ７０５では、文書更新通知処理１７０を行う。これについては後述する。
ステップ７０６では、図６に示す文書更新通知画面１９０のメニュー「定義情報登録１９２」が選択されたか否かを判定する。
ステップ７０７では、定義情報登録処理１５０を行う。これについては後述する。
ステップ７０８では、図６に示す文書更新通知画面１９０のメニュー「文書登録・更新１９１」が選択されたか否かを判定する。
ステップ７０９では、文書登録処理１６０を行う。これについては図８のフローについて説明を行う。
ステップ７１０では、図６に示す文書更新通知画面１９０のボタン「終了１９５」が選択されたか否かを判定する。
【００２５】
以下、図７の補足説明を行う。図７のフローでは、ユーザがシステムに対してログインを行った後、図６に示す文書更新通知画面１９０を表示する（ステップ７０４）。そして図６に示すように、文書更新通知画面１９０上のメニュー上には、「定義情報１９２」「文書登録・更新１９１」のメニュー項目がある。これらのメニュー項目を選択することにより、定義情報登録処理１５０（ステップ７０７）や文書登録処理１６０（ステップ７０９）を行う。
【００２６】
操作画面の順序としては、図７のステップ７０４に示す通りに、図５に示す更新通知画面１９０を先に表示する。しかし、システムセットアップ直後の作業手順としては、まず定義情報を登録し、次に文書登録処理を行い、最後に文書更新通知を行う。そこで以下の説明を、作業手順に基づいて行うことにする。まず図７のステップ７０７「定義情報登録処理１５０」について説明を行い、次にステップ７０９「文書登録処理１６０」について説明を行う。
【００２７】
なお、文書管理システムにおいては、登録文書を更新するに当たっては、文書管理システム３４０より、端末３１０，３２０、３３０側に、文書ファイルをダウンロードする機能が必要となる。本実施例では、この文書ファイルのダウンロード機能を、従来技術にもとづいて実現するため、詳細な説明は省略する。
【００２８】
次に、図７のステップ７０７である「定義情報登録処理１５０」について説明を行う。図１に示すように、この処理では文書変更通知モデルの定義１５１を行う。
【００２９】
既に述べたように、ユーザがログインした後に、図６の文書変更通知画面１６０のメニューから、「定義情報」１９１を選択した場合に、「定義情報登録処理１５０」を行う。この処理では、まず図１に示した文書変更管理モデル１００をそのままグラフィック表示した画面が表示される。この画面上にて、マウスやキーボードなどを用いた操作により。文書種別毎に新たなキーワード追加を行なったり、文書種別間の関連づけを操作する。そして、これに対応する情報を、本システム上にて管理する。「定義情報登録処理１５０」を終えると、図６の文書更新通知画面１９０に戻る。
【００３０】
次に図７におけるステップ７０９「文書登録処理１６０」について説明を行う。図１に示すように、この処理では１６１から１６３の一連の処理を行う。
【００３１】
文書種別・キーワード指定１６１では、図５に示す文書登録画面１８０を表示し、ユーザが文書種別やキーワードの指定を行う。ここでは、図５の文書登録画面１８０上にて、必要となる値指定や入力を行う。まず、ユーザが、図５に示す文書登録画面１８０上にて、文書ファイル名１８１、文書種別１８２の指定を行う。システム側にて、文書種別に応じたキーワードを表示する。図５に示すように、文書種別キーワード一覧１８３上に登録文書ファイルの文書種別に対応したキーワード一覧を表示する。図５の例では、プロジェクト方針書のキーワードとして定義されているスケジュール、DB開発方針、画面開発方針、を表示する。文書登録者１は、文書登録画面１８０画面から必要となるキーワードを選択する。例えば「画面開発方針」を選択する。すると、システム側では、この選択項目を変更キーワード一覧１８５に表示する。そして、ユーザが図５の変更キーワード一覧１８５上に示されている「変更理由」に対して、変更理由を入力する。ここで、ユーザが、図５の登録１８７を押した場合にのみ、以下処理１６２、１６３を行う。ユーザが、取り消し１８６を押した場合には、文書登録処理１６０を直ちに終了する。
【００３２】
キーワード・文書ファイル間の関連登録１６２では、キーワード・文書ファイル間の関連づけを登録する。図１では、キーワード・文書ファイル間の関連づけ１０が示されており、これを文書管理DB１００上に登録する。
【００３３】
文書変更通知情報の生成１６３では、文書変更通知情報１４０の生成処理を行う。本処理の詳細を更にサブステップ毎にわけて説明する。
【００３４】
第１サブステップでは、図５の文書登録画面１８０上で入力した文書種別、文書ファイル名、変更キーワードの値を条件とし、対応すべき文書種別とキーワードを文書変更通知モデル１００より取得する。例えば、図１の文書変更通知モデル１００からは、「プロジェクト方針書」におけるキーワード「画面開発方針」を取得する。
【００３５】
第２サブステップでは、文書変更通知モデルから、「第１ステップで得た文書種別と文書間関連づけをもち、変更キーワードと同一のキーワードをもつ」という検索条件を満たす、文書種別、キーワードを取得する。例えば、図１の例において文書種別「プロジェクト方針書」とキーワード「画面開発方針」を検索条件とすると、文書種別「画面仕様書」とキーワード「画面開発方針」を検索結果として得る。
【００３６】
第３サブステップでは、キーワード・文書ファイル間の関連づけを参照することにより、第２サブステップで得た文書種別、キーワードと対応づけられている文書ファイル名を検出する。例えば図１の例では、「キーワード・文書ファイル間の関連づけ１０」により、文書種別「画面仕様書」のキーワード「画面開発方針」に対し文書ファイル「GUI.doc」が対応づけられている。そこでこの例では、文書ファイル「GUI.doc」を検出結果として得る。
【００３７】
第４ステップでは、第２サブステップで得た文書種別、キーワードと、第３サブステップで得た文書ファイル名を、図４の影響先文書情報４２０に登録する。例えば、上記に説明した例に基づく場合には、図４の影響先文書情報４２０において、IKW_ID=3で示すレコード情報を登録することになる。以上、文書変更通知情報の生成について説明を行った。
【００３８】
次に図７のステップ７０５である「文書変更通知処理１７０」について説明を行う。本処理は、文書変更通知情報に基づいた内容を、図６の文書変更通知画面１９０に示す。図１に示すように、文書変更通知処理１７０は、ユーザ判定１７１、文書更新通知情報の表示１７２よりなる。
【００３９】
ユーザ判定１７１では、ログインユーザ名を影響元文書情報４２０の影響先キーワードに対する絞り込み条件と用いることで、ログインユーザに関係のある影響元文書情報４２０のみを取得する。
【００４０】
文書更新通知情報の表示１７２では、ユーザ判定１７１で取得した情報に基づいて、図６の文書変更通知画面１９０を表示する。そして、ユーザの操作に応じた、画面制御処理を行う。例えば、ユーザが変更影響状況１９３から、１９６にて示す個所を選択すると、選択内容に応じた詳細な情報を「変更文書・キーワード一覧１９４」上に表示する。この表示処理は、システム側にて、影響元文書情報４２０を、ユーザ名と変更影響状況１９３の登録文書名に基づいて絞り込み、この絞り込み結果を「変更文書・キーワード一覧１９４」上に表示することで行う。なお、ユーザが終了ボタン１６５を選択した場合にはシステムを終了する。
以上、実施例１の説明を終える。本実施例により以下の効果が得られる。まず、各作業者が担当以外の文書を意識することなく、文書登録・更新および状況監視を行うことができる。文書登録を行うに当たっては、担当文書の関係するキーワードのみを意識して、登録・更新処理を行えばよい。そして文書の状況監視にあたっては、担当文書名を軸として、変更元文書を知ることができる。このため、担当文書以外の文書を意識しながら、文書管理を行う必要がなくなる。また、本発明では、文書ファイルの形式を問うことなく、文書間の変更通知を行うことができる。これにより、作業者が利用する文書作成ツールに関わらず、関連文書の変更をしることができる。課題において述べた、文書作成作業の手戻りを防止すると同時に、作業者が文書作成ツールを自由に選択することができる。
【００４１】
次にこの実施例１のバリエーションである他の実施例を説明する。
実際の業務では、それぞれの文書種別に対しては、その文書種別が作成される期間がある。例えば、図８に示すように、プロジェクト方針書はシステムの分析期間中に、DB仕様書、画面仕様書などは設計期間中に、DB内部設計書は実装期間中に作成される。こうした文書作成期間をもつ場合、実施例1で述べた変更通知方法では不十分な点がある。実装期間に入った時点で、分析期間中に作成するプロジェクト方針書が変更された場合には、直接対応づけられている「DB仕様書」「画面仕様書」に対してのみ通知するだけでは不十分である。前工程での文書を変更した場合には、実装期間において現在作成中である「DB内部設計書」などに対し、変更通知を行うことを必要とする場合がある。つまり、文書作成期間に基づく文書変更通知処理が必要な場合がある。
【００４２】
しかし、実施例１では、文書作成期間を文書変更通知の条件しては利用されていない。
そこでこうした課題に対応した実施例２を、図８にもとづいて説明する。図８では、文書作成期間を管理するために「ステージ１１５」が追加されている。ここでいうステージとは、文書作成業務の進捗状況を時系列に区分けした期間のことである。例えば、図８の例ではステージとして「分析期間」、「設計期間」、「実装期間」の３ステージに区分される。このうち、一つが現在の文書作成期間を示しているものとして、「現行ステージ」１１６として指定することができる。ステージ１からステージ３は、文書作成タイミングの時系列順序を表し、文書作成業務がすすむにつれ、「現行ステージ１１６」が、「分析期間」、「設計期間」、「実装期間」の順に推移する。なお、文書種別１１１はこのステージのいずれかに属するようにして配置される。例えば図１２では「プロジェクト方針書」が、ステージ「分析期間」に属していることを示している。
【００４３】
「文書作成期間に基づく文書変更通知処理」では、文書変更が行われた場合には、現行ステージに所属する文書種別まで間接的に文書種別間の関連をたどる。そして既に述べたのと同様な処理により文書変更通知情報の生成処理を行う。以下、例を用いて説明する。
【００４４】
例えば、現行ステージ＝設計期間の場合に、文書ファイルPJ.docが変更されたとする。この場合には、文書ファイルPJ.doc,GUI.docに対してのみ変更通知を行う。
次に、現行ステージ＝実装期間の場合に、文書ファイルPJ.docが変更されたとする。この場合には、文書種別「DB内部設計書」が間接的ではあるが、文書種別「プロジェクト方針書」と関連づけられている。そして「DB内部設計書」は、現行ステージに属する文書種別である。このため、「DB内部設計書」に関連づけられている文書ファイルについても変更通知の対象となる。つまりこの場合には、文書ファイルPJ.doc,GUI.docとDBI.docに対して変更通知が行われる。また、前工程のステージで、本来完成している文書を変更するに当たっては、ずさんな改竄を防止するため、上長の承認を得るなどの処理が必要とされる場合がある。こうした場合の課題を改善するには、ステージの状態により文書登録画面の入力項目を制御するなどの拡張を実施例１に対して行う。
【００４５】
本実施例２の処理は、実施例１で述べた処理を上記の考えに基づき、修正を加えることで実現できるため、詳細な説明は省略する。
【００４６】
この実施例２により、文書作成期間に基づく文書変更通知処理が必要な場合の課題を改善する。
【００４７】
実施例１では、異なる文書種別間でのキーワードにおいて、同一名称をもつキーワードどうしの関連を用いて文書変更通知を行っている。実際には文書種別が異なる場合には、同じ中身を表現するにあたっても、各セクション名（本発明ではキーワードに相当する）に対して、別のセクション名で表現する場合がある。また、ある一文書の一セクションに対応する変更が、複数文書の複数セクションに対して影響を与える場合がある。実施例１では、こうしたキーワード名称が異なる場合の課題に対して十分対応できていない。
【００４８】
そこでこの課題に対応した実施例３を、図９に基づいて説明する。図９では、文書種別間において、キーワードが異なる場合を取り扱うために、キーワード間を対応づける「キーワード変換対応」１１７を新たに追加する。図９に示すように、「各文書種別毎にキーワードの語句としては異なるが、変更通知の関係をもつキーワード」同士を対応づける。例えば「プロジェクト方針書」におけるキーワード「全体スケジュール」と、「DB仕様書」におけるキーワード「DBスケジュール」とを対応づける。キーワード変換対応１１７により、実施例１とは異なり、語句が異なるキーワード間にて、変更通知処理を可能とする。「プロジェクト方針書」におけるキーワード「全体スケジュール」が更新された場合には、キーワード変換対応１１７をたどることにより、影響先である「DB仕様書」におけるキーワード「DBスケジュール」を検出する。以下の処理を既に述べた実施例１と同様に行うことにより、文書変更通知情報の生成を行う。本実施例で述べたキーワード間の対応管理により、キーワード名称が異なる場合の課題の改善を図る。
従来技術で述べたように、文書ファイルとしてXML文書とよばれる構造化文書がある。文書管理システムでは、文書ファイルとして特にXML文書などの構造化文書が用いる場合がある。SGML、XMLなどの従来技術では、文書ファイル形式に対して柔軟性を与えることができない。文書作成作業を効率的に進めるためには、作業者が各自に応じた文章作成ツールを利用することが望ましい。作業者側は、各自の状況やスキルに応じた文章作成ツールを利用することを望んでいる。しかし、SGML、XMLなどの構造化文書を前提とした技術では、固定された文書テンプレートを前提条件とするため、「作業者別に、異なる文章作成ツールを利用したい」という作業者側の要求に対応できない。
【００４９】
この場合に、XML文書対応として特に機能強化した実施例を、実施例４として説明する。
実施例４を、図１０に基づいて説明を行う。図１０には、特にXML文書を含む形態で文書変更通知モデル１１０を実現する場合を示している。図１０ではXML文書であるPJ.xml、IDB.xmlと、XML以外の文書ファイルであるGUI.docを混在する形態で管理している。管理対象となる文書ファイルがXML文書である場合には、文書ファイルとキーワードの対応関係に加えて、XML文書内部に含まれるタグとキーワードとの対応づけをも管理する。図１０ではキーワード「画面開発方針」とPJ.xmlのタグGUIとが対応付けられている場合を示している。
【００５０】
本実施例でのべた、タグとキーワード間の対応を用いることにより、既に述べた文書変更通知処理をXML文書間や、XML文書と非XML文書間で行うことが可能になる。
【００５１】
実施例１では、文書変更通知を行うにあたり、独自の文書更新通知画面を用いている。しかし、こうした個別のシステム画面を起動する作業は、ユーザ側にとって負担になることが想定される。そこで、この課題を改善するため、文書管理システムの画面により変更通知を行うのではなく、ユーザが常時利用していると想定されるメール管理システムと連携する実施例を、実施例５として述べる。
【００５２】
再度、図３を用いて、メール管理システム３６０を利用した場合の実施例５を説明する。本実施例の構成では、主記憶装置３４２上のメール送信処理１４１０を新た利用する。メール連携による文書変更通知を行うに当たっては、まず実施例１で述べた文書登録処理１６０を行う。次にメール送信処理１４１０において、影響先文書情報４２０からユーザ別にメールを作成し送信する処理を行う。メール送信に当たっては、個別ユーザのメールアドレス等が必要になるので、これについては、ユーザ情報１３０にメールアドレスの項目追加を行い、予め登録しておくものとする。
【００５３】
本実施例により、文書管理システムを別途起動せずに、ユーザが利用する電子メールシステムを通じて、文書の変更状況を知ることが可能になる。
【００５４】
実施例１では、文書変更通知モデルとして、文書種別毎に一種類キーワードリストを保持する。一方、実際の業務では、一種類の文書ファイルが様々な観点から分類されることがある。しかし、実施例１では、文書種別毎にキーワードリストを一種類しか保持していないため、様々な観点から、一つの文書ファイルを分類することができない。
【００５５】
そこで前段落の課題を改善するため、複数のキーワードリストを管理・利用する実施例６を述べる。本実施例については詳細に説明を行う。実施例６は、以下の点が、実施例１と異なる。図１１の文書変更通知モデル１１０に示すように、定義時には、文書種別毎に利用するキーワードの一覧を複数種類登録できる。文書登録時には、複数のキーワード一覧の内、いずれのものを用いるかを選択できる。そして変更通知先を特定するための変更通知条件を指定することができる。
以下、図１１を用いて、実施例２における処理について説明を行う。
定義情報登録処理１１３０では、実施例１と同様に文書変更通知モデルの定義を行う。文書変更通知モデルの定義１１３１では、実施例１と異なる文書変更通知モデル１５１０に対する定義を行う。
【００５６】
文書変更通知モデルの定義１１３１では、図１１における。文書変更通知モデル１１１０を管理する。このモデルでは、各文書種別１１１に対して、複数のキーワード一覧をもつことができ、キーワード一覧にはおのおのを識別する名称がつけられる。例えば、図１１の「プロジェクト方針書」では、製品名キーワード１１１１、セクション名キーワード１１１２をもつ。「画面仕様書」では、開発環境名１１１３、製品名キーワード１１１４、セクション名キーワード１１１５を持っている。これらのキーワード一覧は、キーワードの分類や、キーワードの別名を管理するための複数項目をもつことができる。例えば、製品名キーワード１１１１は製品コードと製品名よりなる。他のキーワード一覧についても、同様であり、複数の項目をもつ。
【００５７】
なお、文書種別毎にキーワード一覧を定義するにあたっては、いくつかの手段がある。第一の手段として、図１１に示すように、個別の文書種別毎にキーワード一覧作成するようにしてもよい。また別の手段として、外部マスタを利用する方法がある。まず外部に例えば「セクション名キーワードマスタ」などのマスタを別にもうける。そしてこのマスタから必要なものを選択し、文書種別毎に文書種別とマスタ上のレコードとの関連づけを管理する。このようにしても、結果的には、図１５に示すのと同様なキーワード一覧が管理できる。
【００５８】
文書登録処理１１４０では、図１２に示す文書登録画面１１５０を用いて、登録処理を行う。
文書種別・キーワード指定１１４１では、実施例１と同様に、文書種別と文書ファイル名を指定する。実施例１とは異なり実施例６の文書登録画面１１５０では、図１２に示すキーワード一覧１１５３が追加されている。図１２上のキーワード一覧１１５３には、キーワード指定に利用する一覧表の名前を表示する。ユーザが必要に応じてキーワード一覧名を指定できる。ここで指定したキーワード一覧名に基づいたキーワード一覧を「文書種別キーワード一覧１１５４」に表示する。これらの内、選択したキーワードが「ファイル選択キーワード一覧１１５５」および「変更キーワード一覧１１５６」に追加される。「ファイル選択キーワード一覧１１５５」には、キーワード一覧名毎のキーワードを表示する。「変更キーワード一覧１１５６」には、複数のキーワード一覧にまたがったキーワードを表示する。例では、製品名一覧とセクション一覧から選択したキーワードの一覧を表示している。
【００５９】
変更通知条件指定１１４２では、図１２上の変更通知条件１１５２において、変更通知条件の指定を行う。ここでいう変更通知条件とは、文書変更通知情報を生成する際に条件として利用するキーワード一覧名のことである。このキーワード一覧名の間にはANDやORといった論理結合を利用できる。図１２上の変更通知条件１１５２には、「製品名一覧 AND セクション一覧」が入力されている。これは、変更元文書ファイルと影響先文書ファイルが、製品名一覧とセクション名一覧の双方にて対応づけられていることが、文書変更通知の前提条件となることを示している。これについては、例を用いて後述する。
【００６０】
キーワード・文書ファイル間の関連登録１１４３では、各キーワード一覧と文書ファイルとの関連づけの登録を行う。例えば図１１の例では、PJ.docと製品名一覧１１１１、セクション名一覧１１１２とを関連づけたものを、文書管理DB１００に登録する。
【００６１】
文書変更通知情報の生成１１４４では、変更通知条件指定１１４２で指定した条件に基づき、文書変更通知情報１１２０の作成を行う。文書変更通知情報の生成１１４４では、「キーワード一覧単位の影響先文書ファイル検出１１４５」、「変更通知条件による絞り込み１１４６」を行う。
【００６２】
キーワード一覧単位の影響先文書ファイル検出１１４５では、実施例１で述べたのと同様な処理を各キーワード一覧別に行うことで、影響先文書ファイルを検出する。まず、文書変更通知モデル上のキーワードで、文書間関連をもち、同一のキーワード一覧上に同一キーワードが存在するものを検出する。例えば、製品名一覧１１１１における製品名「ABC」を更新キーワードとする場合には、「画面仕様書」の製品名一覧１１１４におけるキーワードである製品名「ABC」を検出する。次に、実施例１と同様に「画面仕様書」の製品名一覧１１１４における製品名「ABC」と対応づけられている文書ファイルを検出する。この場合にはGUI1.docを検出する。以上が製品名一覧のキーワードに着目して得られる影響先文書ファイルである。同様な処理を、セクション名一覧１１１２に対して行う。セクション名一覧１１１２における製品名「スケジュール」から影響先文書ファイルとしてGUI1.doc、GUI2.docを検出する。
【００６３】
変更通知条件による絞り込み１１４６では、既に述べた変更通知条件に基づいて、最終的に変更通知を行うための影響先文書ファイルを絞り込む。図１１の例では、すでに説明した処理により、影響先文書ファイルとしてGUI1.doc、GUI2.docを検出する。一方、図１２の変更通知条件指定１１４２では、「製品名一覧 AND セクション一覧」が変更通知条件として指定されている。既に検出した影響先文書ファイルより、この条件に基づくものを絞り込む。影響先文書ファイルとしてGUI1.doc、GUI2.docの内、製品名一覧とセクション一覧といった双方のキーワード一覧から検出された影響先文書ファイルは、GUI1.docのみである。「変更通知条件による絞り込み１１４６」では、このGUI1.docに対してのみ、文書変更通知情報１１２０における影響先文書情報を生成する。なお、実施例２の文書変更通知情報１１２０は、実施例１の変更元文書情報４１０と影響先文書情報４２０に対し、各々「キーワード一覧名」、「影響先キーワード一覧名」の項目を追加したテーブルより構成される。
【００６４】
以上で、実施例６の説明を終わる。実施例６により、様々な観点から文書ファイルを分類し、この分類に基づいた文書変更通知を行うことが可能になる。
【００６５】
また、以上のべた複数の実施例を組み合わせることも、すでに説明した内容に基づき容易に実現可能である。例えば、すでに説明した実施例の構成を組み合わせることにより、文書変更通知時にメール連携を行い、XML文書を管理対象とする文書変更通知方法などを実施できる。
【００６６】
以上によれば、各作業者が担当以外の文書を意識することなく、文書登録・更新および状況監視を行うことができる。文書登録を行うに当たっては、担当文書の関係するキーワードのみを意識して、登録・更新処理を行えばよい。そして文書の状況監視にあたっては、担当文書名を軸として、変更元文書を知ることができる。このため、担当文書以外の文書を意識しながら、文書管理を行う必要がなくなる。
【００６７】
また、文書ファイルの形式を問うことなく、文書間の変更通知を行うことができる。これにより、作業者が利用する文書作成ツールに関わらず、関連文書の変更をしることができる。課題において述べた、文書作成作業の手戻りを防止すると同時に、作業者が文書作成ツールを自由に選択することができる。
【００６８】
【発明の効果】
本発明によれば、文書の登録または変更の通知を送るユーザが検索可能となる。
【図面の簡単な説明】
【図１】実施例１の処理構成図
【図２】実施例１の概要説明図
【図３】実施例のシステム構成図
【図４】実施例１のユーザ情報、文書変更通知情報のテーブル構成図
【図５】実施例１の文書登録画面
【図６】実施例１の文書変更通知画面
【図７】実施例１の文書変更通知メイン処理のフロー図
【図８】実施例２の文書変更通知モデル
【図９】実施例３の文書変更通知モデル
【図１０】実施例４の文書変更通知モデル
【図１１】実施例６の処理構成図
【図１２】実施例６の文書登録画面
【符号の説明】
１００．．．文書管理DB
１１０．．．文書変更通知モデル
１２０．．．文書ファイル
１３０．．．ユーザ情報
１４０．．．文書変更通知情報
１５０．．．定義情報登録処理
１６０．．．文書登録処理
１７０．．．文書変更通知処理

Claims

表示装置を有する端末装置とネットワークを介して接続され、処理装置と記憶装置とを備えた文書管理システムにおける文書管理方法において、前記処理装置は、予め文書種別ごとに、当該文書種別の文書を参照して次に作成される他の文書の文書種別を表す参照関連情報を文書変更通知モデル情報として前記記憶装置に格納し、
登録に係る文書の文書識別情報と当該文書の文書種別との入力を前記端末装置から受け付け、
前記入力された文書識別情報と当該文書識別情報によって識別される文書の文書種別と前記登録に係る文書を登録したユーザの識別情報とを対応付けて変更元文書情報として前記記憶装置に格納し、
更新される文書の文書種別に対応する文書変更通知モデル情報の参照関連情報に係る文書種別をキーとして前記変更元文書情報から文書識別情報とユーザの識別情報とを読み出し、
読み出した文書識別情報を当該更新の影響が及ぶ影響先文書情報として前記記憶装置に登録し、
ユーザからの文書更新通知情報の要求に応じて、当該ユーザの識別情報に対応する影響先文書情報を前記端末装置に出力することを特徴とする文書管理方法。
表示装置を有する端末装置とネットワークを介して接続され、処理装置と記憶装置とを備えた文書管理システムにおいて、
前記記憶装置は、文書種別ごとに、当該文書種別の文書を参照して次に作成されるべき他の文書の文書種別である参照関連情報を文書変更通知モデル情報として格納し、
前記端末装置は、登録に係る文書の文書識別情報と当該文書の文書種別との入力を受け付け、
前記記憶装置は、前記端末装置から入力される文書識別情報と当該文書の文書種別と前記登録に係る文書を登録したユーザの識別情報とを対応付けて変更元文書情報として格納し、
前記処理装置は、更新に係る文書の文書種別に対応する文書変更通知モデル情報の参照関連情報に係る文書種別をキーとして前記変更元文書情報から文書識別情報とユーザの識別情報とを読み出し、
前記記憶装置は、当該読み出した文書識別情報を当該更新の影響が及ぶ影響先文書情報として格納し、
前記処理装置は、ユーザからの文書更新通知情報の要求に応じて、当該ユーザの識別情報に対応する影響先文書情報を前記端末装置に出力することを特徴とする文書管理システム。
表示装置を有する端末装置とネットワークを介して接続され、処理装置と記憶装置とを備えたコンピュータに、以下のステップを有する文書管理方法を実行させるためのプログラム：
前記処理装置が、
文書種別ごとに、当該文書種別の文書を参照して次に作成されるべき他の文書の文書種別を表す参照関連情報を文書変更通知モデル情報として前記記憶装置に格納するステップ、
登録に係る文書の文書識別情報と当該文書の文書種別との入力を前記端末装置から受け付けるステップ、
前記入力された文書識別情報と当該文書識別情報によって識別される文書の文書種別と前記登録に係る文書を登録したユーザの識別情報とを対応付けて変更元文書情報として前記記憶装置に格納するステップ、
更新される文書の文書種別に対応する文書変更通知モデル情報の参照関連情報に係る文書種別をキーとして前記変更元文書情報から文書識別情報とユーザの識別情報とを読み出すステップ、
読み出した文書識別情報を当該更新の影響が及ぶ影響先文書情報として前記記憶装置に登録し、
ユーザからの文書更新通知情報の要求に応じて、当該ユーザの識別情報に対応する影響先文書情報を前記端末装置に出力するステップ。