JP5144458B2 - 作成文書ナビゲーションシステム - Google Patents

Description

本発明は、文書の作成や検索を支援する技術分野に関連し、特に、個別性の高いプロジェクトで使用をする文書の作成や検索を支援する作成文書ナビゲーションシステムに関するものである。

企業等の事業者は、品質、環境、信頼性、コンプライアンス又は内部統制などの要請に応じて、様々な業務の手順を文書化し、その文書の記述に従って業務を行い、予め定められた様式の文書（書類）に個々の業務の結果を記録している。また、事業者は、他の事業者と協調して業務を遂行する際には、文書にて必要な情報の伝達をしている。

特許文献１には、OEM製品開発に必要な情報について、製品製造工程等と仕様情報とを関連させることで、仕様の更新等の情報を各社で共有可能な手法が開示されている。
特許文献２には、プロジェクトの各工程で作成すべきアウトプット文書の空の実体を当該工程と関連させて文書管理データベースに登録し、各工程で参照すべき文書へのリンクと共に工程と関連づけることで、進捗状況を管理する手法が開示されている。
特許文献３には、クライアント・サーバーにて、文書をURLで管理し、文書毎に開示対象を特定する識別情報を付加する手法が開示されている。

特開2003-122818号公報 特開2003-141320号公報 特開平11-66053号公報

［技術的課題１］しかしながら、上記従来例では、多数のプロジェクトが時期をずらして存在し、個々のプロジェクトの管理のために作成すべき文書が他種類で多数ある際には、コンピュータ・システム及び情報技術（IT）を使用して、予め定められた様式に従った文書の作成を支援することが難しい。
［技術的課題２］さらに、上記従来例では、例えば品質管理や安全管理等のプロジェクトの管理に必要な文書の把握、作成及びスケジュール管理は、結局、問い合わせと応答や必要文書の探索などを含め、手作業となってしまう。すなわち、作業要領書や業務手順書があっても、個別のプロジェクト毎に個別の問い合わせにて応答する業務があり、人手や教育のみでは、文書を活用した業務の構築が難しい。

［技術的課題３］特に、建設業では、上記課題１及び２がより顕著である。すなわち、建設業では、プロジェクトは個々に受注した建築土木工事であり、その建設生産空間（作業所であるプロジェクト）は予め定められた建物内ではなく、様々な関係者が関与する。プロジェクトで生じる情報は、その情報の種類に応じて、工事発注者、建設会社の各部署の社員、設計会社社員、工事専門業者、プロジェクトのジョイント・ベンチャー各社の社員など多様である。そして、個々のプロジェクトは独立して開始し、独立して竣工する一方、安全管理や品質管理の新たな課題についてはプロジェクトに横断的に適用する必要がある。

［発明の目的］この発明の目的は、多数のプロジェクトが時期をずらして存在していても、プロジェクトの管理に必要な文書の使用（準備や作成）及び管理をコンピュータ・システムの利用により支援し、ひいては、予め定められた手順書や様式文書をプロジェクトにて最大限活用されることを促すことにある。
すなわち、本発明は、文書活用型の業務の推進に有用な情報技術（IT）を提供することを、その目的とする。

［着眼点］本発明の複数の発明者は、プロジェクトは多様であっても、品質、安全、環境、財務、コンプライアンス等の管理業務については、一定程度抽象化した複数の共通する時系列のイベントがあり、各イベントと文書とは交差関係にある、という点に着目した。そして、イベントの発生タイミングと文書の使用（例えば、イベントまでの準備と、イベント後の作成）とを関連づけることで、情報技術を適用して文書の使用及び管理を支援できる、との着想に至った。

［課題解決手段１］そこで、実施例１に対応する本発明は、複数の端末とネットワークを介して接続され当該端末とデータを送受信するサーバーと、前記端末から送信されるデータを格納すると共に前記端末からの要求に応じたデータを検索し前記サーバーに返すデータベースとを備えている。
そして、前記データベースが、予めデータを登録しておくマスターとして、イベント種別コードをキーとして所定のプロジェクトに割り当てられるイベント種別の属性を格納するイベント種別マスターと、様式文書IDをキーとして各プロジェクトで使用する様式文書の属性を格納する様式文書マスターと、前記イベント種別コード及び前記様式文書IDとをキーとして前記イベントと前記様式文書との関係の属性を格納するイベント文書関連マスターとを保持している。

前記データベースはさらに、個別の前記プロジェクトの開設時及び開設後に送受信するデータを格納するテーブルとして、プロジェクトIDをキーとして前記プロジェクトの属性を格納するプロジェクトテーブルと、前記プロジェクトIDと前記イベント種別コードとをキーとして当該プロジェクトに割り当てられたイベントの属性を格納するプロジェクト・イベントテーブルとを保持している。
そして、前記イベント文書関連マスターが、前記属性として、各イベントに含まれる様式文書IDを有すると共に、当該様式文書について、当該イベントの実施までに準備をする準備文書と、当該イベントの実施後に作成をする作成文書との区分を管理する使用区分を有している。
また、前記プロジェクト・イベントテーブルが、前記属性として、前記割り当てられたイベントの予定及び実施のスケジュールを有している。

さらに、前記サーバーが、前記端末の操作に応じて前記個別のプロジェクトを開設する際に、前記プロジェクトの属性の入力を促して前記プロジェクト・テーブルに格納すると共に、当該プロジェクトへの前記イベント種別の割り当て操作を促して割り当てられたイベント種別をイベントとして前記プロジェクト・イベントテーブルに格納するプロジェクト開設部を備えている。
そして、サーバーは、前記プロジェクトが開設された際に、前記端末に当該プロジェクトのイベントの一覧及びスケジュールを表示して、当該各イベントの前記スケジュールの確認又は入力を促し、当該確認又は入力される前記各イベントのスケジュールを前記プロジェクト・イベントテーブルに格納するイベント日付管理部と、前記端末から前記プロジェクトの表示が要求された際に、前記当該プロジェクトに含まれるイベントの一覧及びスケジュールを表示制御すると共に、当該各イベントの表示に際して、当該イベントに含まれる前記様式文書を前記使用区分に応じて前記準備文書と前記作成文書とに区分けして表示制御することで、当該スケジュールに応じて、当該様式文書を様式とする関連文書の準備及び作成を促す作業予定管理部とを備えた、という構成を採っている。
本発明はさらに、前記データベースが、前記複数のイベント種別のセットをイベントグループとして識別するイベントグループコードと、当該イベントグループでの唯一のセットを特定するイベントグループセットコードとをキーとして、当該イベントグループセットの属性を格納するイベントグループマスターを保持し、当該イベントグループマスターが、前記イベントグループセットの属性として、当該イベントグループでのイベント種別のイベントランクを特定するイベントランク初期値を有している。
そして、前記サーバーの前記プロジェクト開設部が、前記プロジェクトの開設に際して、前記イベントグループが指定された際に、前記イベントグループセットコードの入力を促して、イベントグループセットを特定し、当該イベントグループセットでの各イベント種別のイベントランクを前記初期値として当該イベントグループセットを案内する開設支援処理を備えた。
これにより、上記技術的課題を解決した。

本発明は、本明細書の記載及び図面を考慮して各請求項記載の用語の意義を解釈し、各請求項に係る発明を認定すると、請求項に係る発明は、下記のように作用し、上記背景技術等との関連において次の有利な効果を奏する。

本課題解決手段は、イベント日付管理部が、プロジェクトに属するイベントのスケジュールを管理し、作業予定管理部が、イベントの表示に際して、当該イベントに予め割り当てられた準備文書と作成文書とを区分けして表示制御する。

従って、本課題解決手段のサーバー１０は、作業所等の端末に、プロジェクトに属するイベントの一覧を表示し、各イベントのスケジュールを表示し、さらに、このスケジュールのイベントまでに準備すべき文書と、イベント後に作成すべき文書を表示制御する。

このため、プロジェクトの遂行者は、使用（準備及び作成）すべき文書について、どのイベントとの関係で使用すべきであり、文書単位でその予定日等のスケジュールを事前に把握することができる。
そして、上記開設支援処理が、前記プロジェクトの開設に際して、イベントグループセットでの各イベント種別のイベントランクを前記初期値として当該イベントグループセットを案内するため、担当者は、イベントグループセット毎に予め定められたセットのイベント群を何ら文書等を参照することなく知ることができ、そのままプロジェクト開設をすることもできき、また、当該プロジェクトで特有に必要のあるイベントや、不要なイベントを指定することで、当該イベントグループに含まれるイベントの固有のセットを当該プロジェクトに割り当てることができる。
これにより、プロジェクトに必要な業務と文書との乖離を抑制し、文書活用型の業務スタイルを推進することができる。

＜全体構成・機能＞
発明を実施するための最良の形態として、３つの実施例を開示する。実施例１は図１に示す作成文書ナビゲーションシステムであり、実施例２は図２５に示す文書検索システムであり、実施例３は図３２に示す文書項目管理システムである。これら各実施例は、単一の例えばドキュメント・コントロールシステムを機能別・特徴別に整理した部品や別バージョンと捉えることもでき、名称は任意である。ここでは、実施例１から３までを含めて実施形態という。

図１を参照すると、本実施形態のシステムは、各実施例に共通して、複数の端末１ａ，２ａ，３ａ（以下端末１ａを本支店や作業所等のユーザにかかわらず「端末１ａ」と表記する）とネットワーク６を介して接続され当該端末１ａとデータを送受信するサーバー１０と、前記端末１ａから送信されるデータを格納すると共に前記端末１ａからの要求に応じたデータを検索し前記サーバー１０に返すデータベース（マスター４０及びテーブル６０）とを備えている。また、サーバー１０は、協調システム７０と接続され、種々のデータを要求し受信する。
協調システム７０としては、端末１ａの操作者となる人事情報を管理する人事・作業者管理システム７２と、この人事システム７２と協調して操作者がアクセス可能なデータを特定してそのアクセスを管理するアクセス管理システム７４と、端末１ａの操作者間で予め定められた承認が必要な際に当該承認のワークフローを管理する承認ワークフローシステム７６と、プロジェクトに関連する事業者間の見積を処理する見積システム７８等とがある。

ネットワーク６とサーバー１０とはルーター等の通信制御部７を介して接続されている。サーバー１０は、端末１ａの操作による要求に応じて、マスター４０と、テーブル６０とに格納されたデータを検索し、検索結果に予め定められた書式を適用して端末１ａに送信する。
データベースは、図１、図２５及び図３２に示すマスター４０及びテーブル６０を直接に外部記憶装置等に格納するようにしてもよいし、リレーショナル・データベースや、オブジェクト指向データベースや、メインフレームに応じた態様等でデータを格納しておき、データベース・マネージメントシステムの処理により各図に示すテーブル６０を生成するようにしてもよい。データベースは論理的に接続されていれば、分散されていてもよい。本実施形態に特有なデータ構造については、エンティティー・リレーションシップ（ER）を後述する（図８，９）。

通信制御にTCP/IPを使用し、端末１ａのブラウザーソフトウエアからの要求に応じてHTMLその他のマークアップ言語のページデータを生成し、端末１ａに表示制御する仕組みでは、サーバー１０はWebアプリケーション・サーバー１０となる。すなわち、サーバー１０は、予め用意されたページデータのみを送信するのではなく、マスター４０とテーブル６０に蓄積されたデータを検索し、予め定められた書式でページデータを生成する。
サーバー１０は、マスター４０とテーブル６０と協調して端末１ａにデータを送信する。このために、端末１ａの操作者の状態と目的とに応じて、様々な機能を提供する。
本実施形態に特有なデータ構造を前提として、一定の機能目的毎に、処理をユニット化するとよい。一般的に、Webアプリケーション・サーバー１０を使用したアプリケーション・サービス・プロバイダー（ASP）のシステムでは、端末１ａのブラウザーの画面にボタン、ポップアップメニュー、入力ボックス、コンボボックス、チェックボックス等のグラフィカル・ユーザー・インタフェース（GUI）を配置し、GUIの操作に応じて実行すべき処理を特定する。従って、逐次処理ではなく、イベント駆動型の実装となる。
この実装については、データベースの態様との関係も併せて多様な開発環境とプログラム言語の選定が可能であるところ、本実施形態は、特定の開発環境等に依存せずに実施することができる。図１等に示すサーバー１０の構成要素は、それぞれ独立して実装できる情報処理のユニットである。実装については、共通部分を増加させ、またプレゼンテーション（端末１ａとの応答部分）の独立性を高める等のことが可能である。特定の開発環境・実行環境では、各部の処理内容として記述する部分を新たなコーディングではなく実行環境が受け持つこともある。例えば、多くの実行環境では、端末１ａとサーバー１０との通信や、端末１ａの画面のドット毎の色及び階調の計算等は、サーバー１０の実行環境や端末１ａのオペレーティング・システムが実行する。サーバー１０は、HTMLやXMLその他の言語規約に従ったデータを生成し端末１ａに送信することで、そのデータの表示制御をする。

図２を参照すると、本実施形態に関連する主体（アクター）は、作業所（プロジェクト）と、品質等の管理と、支店とである。作業所は、プロジェクトそのものであり、工事現場であり、また、工事関係者がオフィスで使用をする端末１ａを含む。管理は、品質管理や安全管理に必要な実施要領等の文書を作成し、承認し、発行し、プロジェクトの安全や品質を管理する。本実施形態は品質管理以外の管理に適用できるが、開示例として、以下品質管理を例とする。
この品質管理の文書には、手順書等の文書と、プロジェクトで実際に作成すべき文書の様式となる様式文書とを含む。本実施形態は、様式文書を電子的に取り扱う。プロジェクトである作業所は、様式文書を使用して、手順書等に従って文書を作成する。品質管理は、プロジェクトの進捗に応じて、品質管理上必要な作業を作業所で行うこともある。また、改善活動の一環として、文書の整理や更新、実際に収集した各プロジェクトで作成した文書の分析等を行う。支店は、プロジェクトの業務遂行に直接的に関与する。建設業であれば、土木部、建築部、営業部、設計部等である。作業所が作成する文書の提出先は、予め、支店の各部か、（品質）管理となる。

本実施形態のユースケースは、作業所との関係では、文書の作成支援U10がある。個別の文書をどのように使用すべきかについては、手順書と様式文書とに予め定められているが、個々のプロジェクトの個々のイベントにて使用する文書を確実に手順書に従いつつ確認し、指示し、遵守する作業は複雑である。例えば、どの時点でどの文書を作成すべきであるのかについては、作業者と支店担当者との間で個別に問い合わせ、電子メールや郵送等で書類の送受信をしている例が多く、ITによる効率化が課題であった。この文書使用支援U10としては、イベント毎の必要書類表示U11や、使用予定文書の期限管理U12や、プロジェクトに独自の個別文書の登録U13や、各文書の送信先（宛先担当者、格納すべきシステム上の所在）の特定支援U14などがある。

（品質）管理では、まず人手による作業として、膨大な文書数の削減や共通化のために、用途、必要性、作成時期及び実効性等の判断を行う。その上で、本実施形態に特有な点として、イベントとイベントに必要な様式文書とをデータ構造として紐付けする。そして、プロジェクトに必要なイベントの一覧を予め定めておく。すると、イベントのスケジュール（日程）と、文書を使用（準備及び作成）するスケジュールとをデータ構造として関連させることができる。

品質管理のためのユースケースでは、イベントと当該各イベントに紐づけられた様式文書との登録U20や、当該様式文書の更新U21がある。様式文書の更新U21では、更新した様式文書の配布をコンピュータ・システムで行うのみならず、様式文書を更新するための人手での作業をどのように支援できるかも課題となる。例えば、過去に実際に提出された文書のデータをコンピュータ・システムにより整理できるとよい。また、様式文書には、特定の様式はなく任意のファイル形式及び様式で報告等すべき文書を含めても良い。

さらに、品質管理のために、品質管理に役立つ一覧の生成U22や、串刺抽出U23の実装が望まれる。串刺抽出U23は、多数のプロジェクトの進捗が異なることに対応して、イベントを特定することで、当該イベントをすでに完了したプロジェクトと、当該イベントを予定とするプロジェクトとを抽出し、さらに送信済、承認済又は使用予定の文書を抽出する情報処理である。そして、文書名を特定することで、同様に、イベントとプロジェクトと文書とを抽出U24できるとよい。また、様式文書と、様式文書の文書項目とを管理U26するために有用な機能が望まれる。その他、イベントとそのスケジュール（実施予定日や期限）及び必要な文書をプロジェクト及び支店に伝達U30する支援ができるとよい。文書の記録保存は品質管理やアフターサービスにて要請されているところ、文書管理及び記録保存U32の確実性及び効率性を高めるための機能があるとよい。

支店の各部との関係では、工程等の伝達U30、文書記録保存U32等の他、プロジェクト（作業所）を横断的に進捗管理U31したいという要望が強い。この要望には、イベントから使用予定を含む文書とそのプロジェクトを抽出U23する機能が有用となる。また、プロジェクト（作業所）で異常が発生した際の緊急対応支援U33について、同種の異常を他のプロジェクトから検索できないか等、コンピュータ・システムを用いてどのような効果性及び実効性の向上を図ることができるかも課題となる。例えば、何らかの項目でプロジェクトとイベントを検索U２５する機能が考えられる。
上述の各機能をコントロールする主体については、組織によっては管理が行うところを支店が行い、支店が行う機能を現場（作業所）が行うこともある。これは、様々なデータ及び操作（例えばGUIの表示）のアクセス権限を設定することで実現できる。

図３に、本実施形態のコンピュータの接続関係の一例を示す。本実施形態は、本支店１と、複数のプロジェクト（作業所の現場及び作業所の関係者のオフィス）２，３，４とをネットワーク６を介して接続する。本支店１にサーバー１０を設置しているが、ネットワーク６で接続されていれば他の場所にサーバー１０を設置してもよい。本支店１には、端末１ａ₁，１ａ₂，… １ａ_nがあり、本支店各部及び品質等の管理の操作者が使用する。作業所３，４，５はそれぞれ異なるプロジェクトであり、ルーター７A，７B，７C又は７Dを介して端末２ａ_n，３ａ_n及び４ａ_nと接続されている。サーバー１０は、各作業所３，４，５の各端末２ａ_n，３ａ_n，４ａ_nとの間でデータを送受信させる。

＜交差関係＞
次に、本実施形態の特徴となる情報処理に適用する考え方を説明する。
図４を参照すると、作業所２での工事等のプロジェクトは、複数のイベント（タスク、アクション）と、複数の文書とが関係する。人手により整理したところ、例えば品質管理等の管理のイベントは、工事の進捗に応じて次工程へと順次又は並列に進む。そして、各イベントの完了にそれぞれ必要な文書がある。図４横軸が工事の進捗に応じたイベントを示し、縦軸に文書を示す。イベントは、工事着工会議、品質管理計画書、中間検査、完成検査、AS（アフターサービス）保存書類等である。「品質管理計画書」や、「AS保存書類」自体は、イベントやタスクではなく、文書（群）である。ここでは、品質や安全の管理業務のイベントやタスクとして、「保存書類」という工程（プロセス）を定義し、それを従前のプロジェクト管理手法でのタスクやイベントと同様の取り扱いをする。
この書類群のタスク化と各イベントで使用をする書類との関係を、交差関係という。

図４に示す工事概要書や、全体工程表は、完成検査以外の業務プロセス（イベント）で使用する。そして、工事概要書は、全てのイベントで同一の文書を重複して使用する一方、全体工程表は工事の進捗に応じて更新されていく。また、完成検査記録のように、特定のイベントのみで使用する文書もある。本実施形態の考え方は、交差関係を前提として、プロジェクトと文書との関係をITで効果的に利用可能に紐づけるために、直接関連させるのではなく、イベントを間に置く。すなわち、プロジェクトと文書とを直接に関連させるのではなく、プロジェクトとイベントを関連付け、そのイベントと文書とを関連付ける。

図５（A）に示すように、本実施形態では、プロジェクトが複数のイベントを有し、イベントが、複数の文書を有する。そして、交差関係から、単独使用の文書（図５（A）の文書４，文書７，文書８及び文書９）と、重複する文書（図５（A）の文書１，文書２，文書５及び文書６）と、重複かつ更新する文書（図５（A）の文書２及び文書６）とがある。異なるイベントで重複して使用をする文書は、図４及び図５（A）に示す例では、工事概要書や全体工程表である。そして、工事概要書は更新なし（異なるイベントで同一の内容のファイルとなる）であり、全体工程表は更新あり（異なるイベントでプロジェクトの進捗に応じて更新される）である。
「重複」は、ユーザーの操作により、同一のプロジェクトにて異なるイベントで同一の様式文書が使用される場合をいう。特に、その様式文書が新しい版等に変更された際にその変更が適用されるべき文書群は重複している。重複のうち、プロジェクトの進捗に応じて更新される文書と、更新されない文書とがある。この重複や更新はユーザーによって管理されるが、実施の例によっては、フラグ等を用いてシステム的に管理するようにしても良い。

次に、同一名称のイベントを異なる日付で２回以上実施することを検討する。例えば、あるプロジェクトでは、品質管理計画書というイベントを異なる日付で２回行うとする。この場合、図５（B）に示すように、先の日付のイベント２ａと、後の日付のイベント２ｂとで重ねて使用する文書と別途作成すべき文書とが生ずる。ここでは、あるイベントが２回以上当該プロジェクトに割り当てられる際に、当該文書の属性として、準備文書であるのか、作成文書であるのかの区分を活用する。
すなわち、準備文書は、そのイベントまでに準備する文書で、例えば会議に必要な文書（書類）である。作成文書はそのイベント後に作成する文書で、例えば当該会議での審議に応じてとりまとめる文書や当該会議の議事録等である。図５（B）に示す例では、準備文書（文書１０，文書１１）と、作成文書（文書１２，文書１３）とがある。
イベント２ａでは、文書１０及び文書１１を当該イベント２ａの日付までに準備し、その後文書１２を作成する。そして、イベント２ｂでは、準備文書である文書１０及び文書１１はイベント２ａと同一の文書とし、一方、文書１２にかえて、文書１３を作成する。
同一のイベントを２以上割り当てる際には、準備文書は、その性質から、両方のイベントにて共通して使用することができる。このため、同一のファイル（文書１０及び文書１１）を使用する。一方、作成文書については、異なるファイル（文書１２又は文書１３）を使用する。
また、イベントと文書との関係では、準備文書と作成文書との区分けが重要である。準備文書は、当該イベントまでに準備すべき文書であり、作成文書は、当該イベントの完了後に作成すべき文書である。ある様式文書が準備文書であるか作成文書であるかは、イベントと文書との関係が定まることによって定まる。あるイベントの議事録という様式文書は、当該イベントとの関係では作成文書であり、より後工程のイベントとの関係では準備文書となる。
そして、同一のイベントが２以上割り当てられる際（例えば、同一名称のイベントを２回以上開催する場合）に、この準備文書と作成文書との区分けを利用することができる。すなわち、準備文書の場合、両方の開催にて共通のものを使用することができる。一方、作成文書は異なる文書となる。このため、準備文書との区分は、同一のイベントが２以上割り当てられる際の重複である。
このように、本実施形態では、イベントと文書とを関連させることで、第１に、ITを用いて自動的にイベントと関連した文書の準備や作成のスケジュールを明示し、第２に、イベントと文書とを重複して紐付けしつつ、イベント毎の文書を単位として準備及び作成を情報処理により管理することができる。

また、図６に示すように、イベントを単位として、イベントの発生タイミングを予め定めておくことができる。例えば、工事着工会議は、工事決定後１４日以内に行う。工事決定というイベント（本実施形態で扱う管理上のイベントではないこともある）をイベントを起算点として、１４日以内が当該工事着工会議というイベントの予定日（スケジュール）となる。工事基本計画検討会や、品質管理計画書というイベントであれば、工事引継というイベントを起算点として、その１ヶ月以内や６０日以内が予定日となる。工事基本計画検討会の予定日が定まると、このイベントに含まれる文書（工事概要書から工事基本計画検討会議事録まで）の予定日の初期値を定めることができる。
本実施形態で、イベントの「スケジュール」は、イベントの予定日、実施予定日、実施日、これら予定日の定まり方（発生タイミング区分と発生タイミング依存）、実際の予定日等である。イベントによって、発生タイミング依存を固定とし、予定日を具体的な日付とするものもあれば、発生タイミング区分を前工程依存とし、発生タイミング依存を前工程の予定日に加算すべき日数とするものもある。すなわち、ここでは、スケジュールは、端末１ａの使用者に予定日を伝達する役割を果たせば良い。
工事基本計画検討会というイベントでは、工事概要書、全体工程表、総合仮設計画図、地下施工計画図及び地上施工計画図は、予め準備文書に区分されている。このため、実施形態では、この工事基本計画検討会というイベントのスケジュール（予定日）までにこれらの文書の準備を促す。また、その他使用（作成）した書類や、議事録が作成文書である。これら作成文書は、工事基本計画検討会というイベントが実行された後に作成される。
また、この工事基本計画検討会というイベントが、２回開催される場合、使用区分が準備の文書群は共通して使用され、使用区分が作成である文書は別途作成される。

図７に、各イベントで重複する文書の例と、各イベントを経て更新される文書の例とを示す。各イベントを経て更新される文書であっても、全てのイベントで必ず更新されるとは限らず、個々のプロジェクトによっては同一内容の文書を複数のイベントで使用することもある。図７に示す例では、工事概要書は、複数のイベントで同一の文書である。一方、全体工程表は、プロジェクトの進展に応じて記載が充実する文書であり、初期の周知会等で使用される全体工程表と、竣工に近いイベントで使用される全体工程表とは同一ではなく、上書きや追加がなされ、更新されている。
図６に示す準備と作成との使用区分の設定は、プロジェクトに当該イベントと文書とを割り当てる担当者が行い、当該使用区分に応じて、関係者の端末１ａに当該イベント、イベントのスケジュール（予定日）及び文書を表示する際に、準備文書と作成文書とを分けて表示することが好ましい。すると、イベントの予定日までに作業すべき対象の文書とイベントの実行後に作成すべき対象の文書とを一目で把握することができるようになる。
一方、図７に示す文書の重複と更新とについては、当該プロジェクトに同一の様式文書が割り当てられているか否かと、割り当てられている場合に例えば作成の版数が異なるか否かなどの既存のデータから自動的に重複及び更新の状態を情報処理として読み出すことができるため、使用区分の設定と異なり、情報処理として自動的に行うようにしても良い。この重複及び更新が例えばフラグ等で管理されると、特定の様式文書を検索キーとしたイベント及びプロジェクトの検索等の情報処理の速度を高めることができる。また、様式文書の変更の実際のプロジェクトへの影響等を把握するための検索処理も容易となる。

このように、本実施形態の全体構造は、複数のプロジェクトでのプロジェクトに関して、品質等の管理のために、イベントと書類との交差関係を前提に、プロジェクトとイベントとを関連させ、イベントと文書とを関係させ、準備と作成とを区分し、さらに、必要に応じて各文書の重複及び更新を管理するものである。

＜データ構造＞
図８及び図９はER図であり、実施例１から３にて使用する。実施例３では、別途特有なデータ構造がある。図８にマスター４０の一例を示し、図９にテーブル６０の一例を示す。マスター４０は、予め定めたデータを格納する。テーブル６０は、プロジェクト毎の個別のデータを格納する。マスター４０及びテーブル６０は、エンティティー（実体）を有する。ここでは、エンティティーに図１に示す符号と同一の符号を付する。また、プロジェクトと作業所とは同一の単位であり、１つの固有のプロジェクトは、本実施形態上、１つの固有の作業所を持つ（工事現場の数ではない）。このERは、本実施形態の情報処理と関連する部分のみを抽出して整理した一例であり、サーバー１０の動作中に各テーブル６０に相当するデータ構造が当該サーバー１０の主メモリに展開されればよく、他のER構成としつつ、動的に各テーブル６０を生成するようにしてもよい。その場合も、データの項目となる属性を唯一に特定するキーについては、本実施形態の情報処理との関係では、図８及び図９に示す構造に整理される。

様式文書マスター４８は、様式文書IDをキーとして、登録者、所管部、タイトル、説明文、様式文書所在等を唯一に識別する。ER図は三段あり、上段がエンティティーの名称であり、例えば様式文書である。中段が当該実体の属性を特定するためのキーであり、例えば様式文書IDである。様式文書を支店毎に管理する場合には、支店IDをキーに含めると良い。以下、説明を簡略とするために支店毎ではなく全社単位で様式文書IDを採番する例を説明する。他のマスター４０についても同様である。様式文書IDで識別されるデータは、その属性として、ER下段の項目を有する。様式文書を登録した登録者ID、様式文書を管理する所管部ID、様式文書に応じて準備・作成される関連文書の提出先となる提出先ID、様式文書のタイトル、様式文書の説明文となる文字列等である。様式文書所在の「所在」は、物理的な外部記憶装置の特定のディレクトリーのファイル名としても良いが、URL等で一段階抽象化することが望ましい。所在を実際のファイル名ではなく他のコードとしておくと、別のファイル管理システムを使用してファイルの版を管理し、また、使用予定の文書の格納予定先を予めコード化しておくことができる。様式文書に応じてプロジェクトのイベントで使用され送信される関連文書の格納先についても、この所在と同様である。この格納先は、プロジェクトの進捗に応じて複数定義される際には、進捗に応じた格納先を別途のデータ構造にて管理すると良い。

なお、様式文書は、現に存在するファイル形式のファイルとして予め保存しておくのではなく、様式文書の構造と名称のみを定めておき、ダウンロード（配布）の要求があった際に動的にファイルを生成するようにすることもできる。この場合、所在をファイル名自体ではなく、抽象化しておくことが有用である。文書の構造は、例えば、文書に含まれる文書項目の体系である。

様式文書マスター４８にて、初版登録日やファイルタイプという属性が（）で図示されている。この（）の属性は、他の情報からプログラムの実行時に計算できるデータであるが、整合性をプログラマが管理することで、情報処理をしやすいように重畳して保持することもできる属性であることを意味する。例えば、様式文書が登録されている場合には、ファイルタイプは当該ファイルの拡張子等にアクセスすれば判明する。しかし、ファイルタイプをデータベースにて別途管理すると、ファイルの登録時に当該属性を更新する処理が必要となるものの、使用予定のファイルタイプを予め登録することも可能となる。ER図の（）の表記については他の属性についても同様に重畳であることを示す。

イベント種別マスター４４は、現実のイベントのひな形となるデータ構造上の実体である。本実施形態で使用するイベント種別は、全て、ユニークなイベント種別コードを持つ。上述のように、イベント種別の定義を支店毎に行う場合には、［支店ID］をキーに含める。下段は、当該実体についてそのユニークなイベント種別コードにより唯一に特定される属性である。属性は、特定の項目であることが管理されているデータである。イベント種別コードで識別されるイベント種別を、プロジェクトに割り当てることで、当該プロジェクトのイベントとする。
例えば、イベント種別は、イベント種別コードにより識別され、固有のイベント種別名と、発生タイミング区分と、発生タイミング依存とを持つ。発生タイミング区分は、例えば日時指定や、前工程依存等である。発生タイミング依存は、固定や、前工程からの日数等である。スケジュールが固定の日付の際には、発生タイミング区分が日付指定、発生タイミング区分が固定となり、この場合、プロジェクトの開設やその直後にプロジェクトに関与するユーザーに予定日等の入力を促す。発生タイミング区分と発生タイミング依存とからスケジュールを計算できる際には、イベント日付管理部１８が計算すると良い。このように、唯一のイベント種別コードで識別されるイベントは、唯一のイベント種別名と、唯一の発生タイミング区分及び発生タイミング依存を属性として持つ。
所属イベントグループコードは、イベントグループマスター４５の複合キーの一つであり、イベントグループが定義されている場合に、当該イベント種別が所属するイベントグループコードを格納する。例えば、イベント種別である作業所基本情報が、イベントグループである共通に所属する場合、作業所基本情報のイベント種別の所属イベントグループコードにイベントグループ共通のコードを格納する。
次工程イベント区分コードは、イベント種別の順序を管理するもので、当該イベント種別の次のイベント種別のイベント種別コードを格納する。

イベント文書関連マスター５０は、イベント種別コードと、様式文書IDとの複合キーを特定することで、当該イベント種別に予め割り当てられた様式文書を特定する。概念的には、特定のイベント種別に関連づけられる様式文書のセットを管理することとなる。イベント種別コードと様式文書IDとを指定し、当該様式文書が当該イベント種別に割り当てられている際に、関連フラグをオンとする。イベント種別コードのイベント種別に含まれない様式文書IDについては、関連フラグをオフとするデータを登録することもできるが、オフとなるデータを登録せず、オンのデータのみから実行時にビューとなるテーブル６０を生成すると良い。
イベント文書関連マスター５０は、属性として、当該イベント種別に割り当てられる文書の使用区分５３を有する。使用区分５３は、当該イベント種別にて、当該文書が、そのイベントの実施予定日までに準備すべき文書であるのか、それとも、当該イベントの議事録のようにイベントの実施後に作成すべき文書であるのかを区分するコードである。使用区分５３としては、準備や作成の他、当該イベントにとっては参考文書で準備文書の一種である参考や、イベント実施後に確定させ種々の管理上保存対象となる作成文書の一種である保存等の区分を使用するようにしても良い。本実施例では、使用区分５３としては準備と作成とを使用する。
この使用区分５３を、様式文書マスター４８ではなく、イベント文書関連マスター５０で管理するのは、同一の様式文書であっても、割り当てられるイベントによって、準備である場合と、作成である場合とがあることによる。例えば、議事録は、当該イベントが実施された後に作成するが、前回の会議の議事録が次のイベントの準備書類であることもある。
なお、使用区分５３の初期値を様式文書マスター４８に登録しておき、この使用区分５３をプロジェクト開設時に個別に指定する操作を支援するようにしても良い。

このイベント文書関連マスター５０は、当該イベント種別コードでの様式文書が重複及び更新であるか否かの属性を有することもできる。この重複及び更新をフラグ管理しなくとも、本実施形態による作成文書ナビゲーションシステムを構築することができる。しかし、文書の版をより高度に自動的に管理したり、重複した文書の検索速度を飛躍的に高めようとする際には、重複及び更新をフラグ管理しても良い。この場合、重複フラグ５４がオンの場合には複数のイベントで重複して使用することを示し、オフの場合には特定のイベントに単独で使用することを示す。重複フラグ５４がオンの場合で、更新フラグ５６もオンの際には、更新される文書であり、重複フラグ５４がオンで更新フラグ５６がオフの場合には、更新なしに重複して使用される文書であることを示す。この重複フラグ５４等は、プロジェクトに割り当てられる複数のイベントの組み合わせに応じて、重複する場合と重複しない場合等がある。このため、重複フラグ５４等は、様式文書マスター４８ではなく、イベント文書関連マスター５０で管理すると良い。また、重複フラグ５４と更新フラグ５６とは、イベント文書関連マスター５０の関連文書フラグとプロジェクトイベント文書テーブル６４の作成版数等とのデータから情報処理によりバッチ処理やリアルタイム処理にて生成することができる。すなわち、使用区分と異なり、人手による管理は不要である。そして、重複フラグ５４と更新フラグ５６とを使用すると、種々の検索や抽出の情報処理を簡易とし、また処理速度を向上させることができる。

イベントグループマスター４５は、イベントグループコードと、イベント種別コードと、イベントセットコードとを複合キーとして、当該イベントグループに属するイベント種別のイベントランク初期値を有する。イベントグループコードは、例えばイベントグループ名「共通」を特定し、イベント種別は、イベントグループ名「共通」に含まれるイベント種別名「作業所基本情報」を特定する。そして、イベントグループマスター４５は、このイベント種別のイベントランクの初期値を格納する。イベントランクは様々な使用が可能であるが、例えば、イベントセットコードで指定される際に、当該イベント種別を「やる・やらない」の２値をイベントランクとすることができる。この場合、イベントグループを特定し、イベントセットコードを指定すると、そのグループでの特定のイベントのセットを初期値として表示することができる。イベントランクをA,B,C等としておき、イベント種別（ランクA）の場合の様式文書のセットと、イベント種別（ランクB）の場合の様式文書のセットとを異ならせておくこともできる。
このイベントグループは、管理上、プロジェクトの種別（態様や規模）に応じて品質・安全等の管理水準が異なり、必要なイベント種別や使用する様式文書が若干異なる場合に、プロジェクトの開設操作を容易とする役割を果たす。例えば、イベントグループを定義し、最も高水準の管理でのイベント種別のセットを基本として、イベントランクを「やる」とし、中水準や低水準では不要となるイベント種別や様式文書について、「やらない」とする。このイベントランクによる管理では、中水準や低水準のイベント種別群を別途定義することによる操作の煩雑さを抑止することができ、使用をする様式文書の更新等がある際に、その更新処理を単純にすることができる。
管理業務では、すべきことをリストアップするよりも、不要なことを削除する方が効率的で、確実である。漏れのないことを文書等の規程と照らし合わせる作業は負荷が高く、人手でするには熟練と高度な注意力とが必要となる。一方、イベントグループを使用すると、すべき可能性のあるイベントのセットを記憶しておき、提示することができる。

また、図１には示していない実体として、様式文書項目名テーブル５８を有するようにしても良い。これは、文書項目を使用してITにより文書管理するために使用する。例えば、文書を特定のファイル形式のファイルではなく、文書項目の集合体として取り扱う場合や、文書の全ての文書項目を管理しなくとも、特定の文書項目について検索や書込等の情報処理の対象とする際に使用する。文書は複数の文書項目からなる。このため、文書IDと文書項目IDとを複合キーとして、属性を管理する。上位文書項目IDは、文書項目が階層的である際に使用する。文書項目検索区分コード及びコード名は、特定の検索対象として特定の文書項目を使用するか否かなど、検索の種類を識別できる。

図９を参照すると、個別のプロジェクト毎のデータを格納するデータ構造として、本実施形態では、プロジェクトテーブル６１と、プロジェクト・イベントテーブル６２と、プロジェクト・イベント文書テーブル６４とを使用する。
プロジェクトテーブル６１は、プロジェクトIDをキーとして、プロジェクト名や、作業所所長名や、工期（自）や、工期（至）などの属性を有する。プロジェクト・イベントテーブル６２は、プロジェクトIDと、イベント種別コードと、必要なイベント種別コードの枝番とを複合キーとする。プロジェクトの開設時に、イベント種別をプロジェクトに割り当てることで、当該イベント種別を当該プロジェクトのイベントとする。このイベントには、予めイベント種別に割り当てられた様式文書が関連付けられる。
イベントはスケジュールを管理する単位であり、同一のイベント種別について、２以上のイベントとして異なるスケジュールで管理する際には、プロジェクトテーブル６１での枝番を増加させたイベントを割り当てる。枝番を増加させたイベントには、使用区分５３が作成である文書を別途関連づけると良い。使用区分５３が準備である文書は、通常、元のイベントに割り当てられて準備した文書をそのまま使用できる。

プロジェクト・イベントテーブル６２は、属性として、イベント名（イベント種別名ではなく、当該プロジェクトに割り当てたことによりイベント種別からイベントとなった当該イベントの名称）、イベントランク、スケジュールに関する情報（例えば、プロジェクト開始とほぼ同時に登録する予定日、作業所のユーザーが進捗に応じて登録する実施予定日、当該イベントの実施日）などを有する。
また、このイベントに割り当てられた全文書数、送信済文書数、準備文書の処理数と未処理数や、作成文書の処理数と未処理数を重畳的に管理しても良い。この場合、単一の又は複数のプロジェクトに属するイベントの一覧を表示する際に、「（送信文書数／全文書数）」など、文書の使用や処理状況を集約した情報を表示しやすい。全文書に対して、イベントの実施予定日前での表示では準備文書の「（未処理数／処理数）」を表示し、実施予定日後は作成文書の「（未処理数／処理数）」を集約として表示するようにしても良い。

プロジェクト・イベント文書テーブル６４は、プロジェクトIDと、イベント種別コード及び枝番と、様式文書IDとの複合キーで属性保持する。プロジェクト・イベント文書テーブル６４は、属性として、様式文書に応じた個別文書の送信者ID、送信日、承認者ID、承認日、作成版数等を有する。

また、実施例１では、作業所に独自の個別文書をアップロードする個別文書管理処理が行われる。この場合、様式文書IDとして、プロジェクトIDと、当該プロジェクト内で文書を特定するユニークな番号を付与することで、当該プロジェクト・イベント文書テーブル６４にて一体的に管理できる。様式文書IDにプロジェクトID又は本支店各部のID等を数桁含めると、様式文書及び文書にユニークな番号を各プロジェクト及び本支店各部毎に管理することができる。

以下、単にプロジェクト、イベント、文書等というときには、それらの実体をユニークに特定する唯一の又は複数のIDやコードにより特定されるもので、名前を有するデータである。そして、端末１ａでの表示制御等では名前を表示し、情報処理上の特定ではID又はコードを使用して特定する。例えば、「イベントの一覧を表示する」というときには、「プロジェクトIDとイベント種別コード・枝番（及び必要なランク）で特定されるイベントのイベント名というデータを一覧表示する」ことを意味する。また、図１等に示す情報処理ユニットとしての各部が、「イベントを特定（検索、抽出）し」というときには、当該イベントのイベント種別コード等を特定（検索、抽出）することを意味する。

次に、本実施形態の実施例１を開示する。
＜作成文書ナビ：マスター登録処理＞
図１０に、マスター登録処理の一例を示す。マスター４０への登録は、登録用の画面（GUI）を用意すると良い。また、様式文書の一覧等が別途データとして管理されている際には、表計算ソフト等での作成・整理を促して画面操作を介さずにデータの読み取りにより登録するようにしてもよい。実施例１では、図１１等の画面を使用して、マスター４０への登録を行う。実施例１のシステムは、様式文書管理部１３と、イベント種別管理部１５とを備える。様式文書管理部１３は、様式文書マスター４８の属性の名称等を端末１ａに表示制御して属性の入力を促し、入力される項目を様式文書マスター４８に格納する。また、様式文書管理部１３は、様式文書の版の管理を行う。イベント種別管理部１５は、イベント種別の属性の入力を促し、イベント種別マスター４４に格納する。イベント種別管理部１５は、さらに、イベントグループの設定を促し、イベントグループマスター４５の属性をイベントグループマスター４５に格納する。イベント種別管理部１５は、また、イベント種別と様式文書との紐付けを促し、イベント種別と様式文書との組み合わせを管理する。

図１０に示すように、様式文書管理部１３は、様式文書を特定させ、例えば図１１に示すドキュメント設定画面８０を使用して、様式文書マスター４８の属性の入力を促して、格納する（ステップS１０）。様式文書自体は、予め人手により整備し、そのファイルの登録を促す。様式文書等の所在を抽象化する際には、サーバー１０は、登録される文書を所定のディレクトリーに格納し、「所在」との関連づけを生成して、所在管理用のテーブル６０等を更新する。続いて、イベント種別管理部１５は、イベント種別を特定させ、イベント種別マスター４４の属性を登録する（ステップS１１）。イベント種別管理部１５は、例えば図１２（A）に示すイベント種別管理画面８１の新規作成ボタン又は編集ボタンを表示して操作を促し、図１２（B）に示すイベント種別設定画面８２を表示し、イベント種別名、イベント名とを関連させ、発生タイミング区分や発生タイミング依存を登録させる。さらに、必要に応じて、イベント種別を組み合わせてイベントグループを登録する（ステップS１２）。
続いて、イベント種別管理部１５は、図１３に示すイベント種別設定画面８２等を使用して、登録したイベントに含まれる様式文書を登録する（ステップS１３）。最後に、必要に応じて、イベントグループの各イベント種別と、イベントランク初期値とを関連付ける（ステップS１４）。例えば、一群のイベント種別について、イベントセットコード毎に、各イベントランクの場合のイベント種別の組み合わせを特定できるように、各イベント種別のイベントランク初期値を登録する。

図１１を参照すると、様式文書管理部１３は、様式文書の登録（S１０）にて、ドキュメント設定画面８０を使用することができる。書類名称は、図８に示すタイトルである。プロジェクト種別やジャンルは、予め定められた選択肢から選択する。図中逆三角のGUIはコンボボックスであることを示す。その他、左上の影があるボックス（例えば書類名称の右側のボックスで、支店写真報告と入力されているボックス）は入力可能であることを示し、右下に影があるボックス（例えば右上のこの書類を抹消するボタン）はボタンであることを示す。提出先は、文字データでの入力を促しているが、所属部門IDと確実に関連する入力を促し、承認ワークフロー７６等との連携を図るようにしても良い。有効開始時期は、当該様式文書を現実のプロジェクトに適用させる開始日であり、図１１に示す例では、即時反映と、日付指定との一方の選択を促す。保存図書フラグは、プロジェクトの作業の記録として保存が求められる文書の様式文書の場合にオンとする。保存図書フラグがオンの様式文書について、「保存書類」等の名称の特別なイベント種別と自動的に関連させるようにしてもよい。

様式文書所在は、図１１に示す例では、格納フォルダ設定の操作により入力する。この例では、プロジェクトのイベントで使用される文書は、ネットワーク上のディレクトリー構造を有する記憶装置（ファイルシステム）に格納される。端末１ａのユーザーには、ディレクトリー構造と同一の又は抽象化したフォルダ構成を提供する。プロジェクトの進捗に応じてフォルダ構成を変化させる例では、図１１に示すように、同一の様式文書について、プロジェクトの進捗（建築概算業務、建築積算業務等）毎にフォルダ（D-1 XX, D2 XXX等）の選択を促す。なお、アクセス制御は、フォルダと、当該プロジェクトに関与する立場（施工会社、JV、常駐、非常駐、業者、施主、設計等）に応じて定める。アクセス制御は、表示、読み取り、書込更新等のファイル操作の可否である。

図１１に示す例では、様式文書を特定すると、使用中イベント一覧を表示する。ここでは、支店写真報告というタイトルの様式文書は、イベント種別名が共通でイベント名が支店写真報告（月曜日）及び支店写真報告（木曜日）のイベントに割り当てられている。

図１２（A）を参照すると、イベント種別管理部１５は、イベント種別管理画面８１を端末１ａに表示制御する。イベント種別管理画面８１は、イベント種別を特定して、当該イベント種別の管理を促す。図１２（A）に示すイベント種別共通は、実際にはイベントグループであり、複数のイベント名を含んでいる。保存書類（編集不可）は特殊なイベントで、当該プロジェクトで使用される文書のうち、様式文書マスター４８の保存図書フラグがオンである保存図書を予め関連づけたイベントである。作業所基本情報は、プロジェクトの基本的な情報取り扱うイベントである。このイベントには、図１２（A）に示す例では４つの様式文書が関連づけられている。
このイベント種別管理画面８１には、各種ボタンが配置され、イベント種別の新規作成（図１２（B）へ）、編集（図１２（B）へ）、削除、イベントグループ管理、イベント書類管理（図１３へ）、イベントランク管理（図１５へ）、イベント順序の変更等の操作を促している。

図１２（B）を参照すると、イベント種別管理部１５は、イベント種別管理画面８１の新規作成ボタン及び編集ボタンの操作と関連付けられたイベント種別設定画面８２を使用する。例えばボタンの押下の操作を受信した際に関連付けられた別の画面を表示する。別の表現では、新規作成等のリンクがクリックされた際に当該リンク先のページ（画面）を表示する。イベント種別管理部１５は、イベント種別設定画面８２を使用して、当該イベントのスケジュールの態様（発生タイミング区分や発生タイミング依存）の登録を促す。

図１３を参照すると、イベント種別管理部１５は、イベント種別文書設定画面８３を使用して、イベント種別に属する文書の指定を促す。図１３に示す画面にて追加ボタンを操作すると、様式文書を検索する画面を表示し、様式文書の特定を促す。様式文書が追加されると、当該イベント種別文書設定画面８３にて、当該様式文書に応じて使用される文書の使用区分５３の登録を促す。例えば、全体工程表はこの工事着工会議の実施予定日までに準備すべき書類であるため、使用区分５３を準備とする。また、工事着工会議議事録という書類は、当該イベントの実施後に作成すべき書類であるため、使用区分５３を作成とする。管理部署名は、様式文書の管理部署で、様式文書マスター４８から読み出したものを表示する。
このイベント種別文書設定画面８３で設定されるイベント種別と様式文書との関係は、イベント種別毎の様式文書のセットを予め登録しておくものである。様式文書のセットを有するイベント種別が、新規の個別なプロジェクトに割り当てられると、当該イベント種別に対応するイベントに、この様式文書のセットが自動的に割り当てられる。どのイベント種別にて、どの様式文書を使用するのか、という組織の知識をITに組み込み、ITの支援を受けながらプロジェクトに様式文書を割り当てることができるようになる。
この様式文書のセットの使用により、イベントを介して様式文書をプロジェクトに漏れなく割り当てられる可能性の大幅な向上を前提として、当該イベントの予定日と文書の使用（準備、事後の作成）とを関連させて、各プロジェクトの遂行者へ文書作成に関する

次に、図１４を参照して、イベントグループとイベント種別との関係を説明する。イベントグループは、イベント種別である「ABC」のいずれかのイベント、「ab」のいずれかのイベント、「あい」ののいずれかのイベントのセットである。セット１の列のイベントは「A, a, あ」である。セット２の列のイベントは「B, b, あ」である。
イベント種別は、各プロジェクト開設時に当該プロジェクトへの割り当て時の単位であり、イベントは端末１ａに表示する単位である。プロジェクトへのイベントの割り当ては、イベント種別毎にランクを設定し、ランクの該当するイベントが各プロジェクトに割り当てられることになる。例えば、図１４の一番上のイベント種別で、ランクAに設定すると、そのプロジェクトにはイベント（ランクA）が割り当てられる。ランクBに設定すると、そのプロジェクトにはイベント（ランクB）が割り当てられる。要は、プロジェクトを割り当てるときには、イベント種別毎にランクを一つずつ設定することで決まる。
グループのセットは、プロジェクトの開設を容易とするためのイベントランクの初期値である。

図１５は、イベント種別管理画面８１のイベントランク管理用のボタン操作に応じて表示する画面で、イベントランク管理画面８４である。イベントランク管理画面８４では、イベント種別名（又はイベントグループ名）を特定して、当該イベント種別又はイベントグループのイベントランクの編集を促す。「共通」では、必要又は不要というイベントランクの値があり、２値であるため、イベントランクは２である。また、建築：品質管理ISOというイベントグループについては、やる又はやらないというイベントランクの値があり（図１７参照）、イベントランク数は２である。このランク編集では、イベントグループのセットコードを用いて、イベント種別毎にイベントランクの初期値を指定することもできる。例えば、建築：品質管理ISOというイベントグループでは、セットが４種類あり、そのうちの１つを指定すると、イベントグループに属する全てのイベント種別のイベントランク初期値（やる・やらない）を特定できる。この場合も、イベントランク数は２である。

＜作成文書ナビ：プロジェクト開設処理＞
再度図１及び図８を参照すると、実施例１の作成文書ナビゲーションシステム（作成文書ナビ）は、予めデータを登録しておくマスター４０として、イベント種別コードをキーとして所定のプロジェクトに割り当てられるイベント種別の属性を格納するイベント種別マスター４４と、様式文書IDをキーとして各プロジェクトで使用する様式文書の属性を格納する様式文書マスター４８と、前記イベント種別コード及び前記様式文書IDをキーとして前記イベントと前記様式文書との関係の属性（様式文書ID等）を格納するイベント文書関連マスター５０とを保持している。

そして、このイベントでの当該様式文書について、使用区分５３が定義されている。この使用区分５３は、イベントに帰属する様式文書のステータスであり「イベントまでに準備する文書」と「イベント後に作成する文書」との２つのステータス（値）を採るようにしても良いし、さらに「準備文書のうち当該イベントでは参考である文書」等のステータスを追加しても良い。また、使用区分５３をステータスではなく、準備文書フラグとし、準備文書フラグがオンのときに準備文書で、オフのときに作成文書という取り扱いをしても良い。

実施例１の作成文書ナビは、個別のプロジェクトの開設時及び開設後に送受信するデータを格納するテーブル６０として、プロジェクトIDをキーとして前記プロジェクトの属性を格納するプロジェクトテーブル６１と、プロジェクトID及び前記イベント種別コードをキーとして当該プロジェクトに割り当てられたイベントの属性を格納するプロジェクト・イベントテーブル６２とを保持している。
このプロジェクト・イベントテーブル６２は、前記属性として、前記割り当てられたイベントの予定及び実施のスケジュールを有する。

さらに、サーバー１０は、プロジェクト開設部１２と、イベント日付管理部１８と、作業予定管理部２２とを備えている。また、サーバー１０は、プロジェクト開設部１２と作業予定管理部２２の一部の機能を独立させたイベント文書特定部１９を備えるようにしても良い。
プロジェクト開設部１２は、前記端末１ａの操作に応じて前記個別のプロジェクトを開設する際に、プロジェクトの属性の入力を促して前記プロジェクトテーブル６１に格納する。この属性は、例えば、プロジェクト名、作業所所長名、工期等である。登録者IDは端末１ａへのログインユーザーのIDや、当該ログインユーザーの所属部署のID等を自動的に登録するようにしても良い。
また、プロジェクト開設部１２は、当該プロジェクトへの前記イベント種別の割り当て操作を促して割り当てられたイベント種別をイベントとしてプロジェクト・イベントテーブル６２に格納する。すなわち、プロジェクトにイベント種別が割り当てられるとイベントとなり、当該イベントのイベント種別に予め割り当てられている様式文書のセットが当該イベントとの関係で当該開設されるプロジェクトにて特定される。このように、開設するプロジェクトに様式文書のセットが割り当てられる。

そして、実施例１では、プロジェクト開設部１２が、または、イベント文書特定部１９が、多数の様式文書のうち、当該イベントに属する前記様式文書を特定する。そして、イベントと様式文書の組み合わせに応じて、この様式文書の前記使用区分５３を特定する。プロジェクト開設部１２は、この特定した様式文書をイベント毎に表示して、過不足の確認及び必要な様式文書の追加・削除を当該プロジェクト開設時に各プロジェクト毎に促して更新しても良い。さらに、各様式文書の使用区分５３について、イベント文書関連マスター５０の使用区分５３の値を初期値として、確認及び更新を促すようにしても良い。

プロジェクト開設部１２は、当該イベント種別をプロジェクトに割り当てられた際に、イベント種別に予め割り当てられた様式文書のセットを、当該開設するプロジェクトのイベントに自動的に割り当て、様式文書を特定可能とする。または、プロジェクト開設時に様式文書のセットと使用区分５３の初期値を表示して、確認や更新を促すようにしても良い。プロジェクト開設部１２は、様式文書を特定するのみならず、プロジェクト・イベント文書テーブル６４に当該様式文書の属性を様式文書マスター４８とは別に格納するようにしても良い。
そして、プロジェクト開設部１２は、イベント文書関連マスター５０を参照することで、当該イベントに割り当てられている様式文書の使用区分５３を特定することができる。

イベント日付管理部１８は、前記プロジェクトが開設された際に、前記端末１ａに当該プロジェクトのイベントの一覧及びスケジュールを表示して、各イベントのスケジュールを前記プロジェクト・イベントテーブル６２に格納する。

作業予定管理部２２は、前記端末１ａ，２ａから前記プロジェクトの表示が要求された際に、当該プロジェクトに含まれるイベントの一覧及びスケジュールを表示制御すると共に、イベントの表示に際して、当該イベントに含まれる前記様式文書を前記使用区分５３に応じて、「イベントまでに予め準備する文書（準備文書）」と、「イベント後に作成する文書（作成文書）」とに区分けして表示制御することで、当該スケジュールに応じて、当該様式文書を様式とする関連文書の準備及び作成を促す。
また、作業予定管理部２２は、表示したイベントについて、当該イベントを２回開催する際には、２回目以降のイベントの登録を促し、当該２回目以降のイベントに枝番を付して管理する。同一のイベント種別について２以上の登録を促すのは、予定日の管理をイベント単位としていることによる。すなわち、同一のイベント種別について予定日が２以上あれば、個々に枝番を付して異なる予定日のイベントとして管理する。この枝番での管理は、図５（B）に示すイベント２ａとイベント２ｂとがある際、このａとｂとが枝番に相当する。図９に示すプロジェクト・イベントテーブル６２では枝番を複合キーの１つとしている。図１９（A）に示す例では枝番は数字であり、○○品質向上協議会というイベント種別について２つのイベントが登録されている。

さらに、プロジェクト開設の支援のために、イベントグループを使用しても良い。
この例では、マスター４０が、前記複数のイベント種別のセットをイベントグループとして識別するイベントグループコードと、当該イベントグループでの唯一のセットを特定するイベントグループセットコードとをキーとして、当該イベントグループセットの属性を格納するイベントグループマスター４５を保持している。そして、当該イベントグループマスター４５が、前記イベントグループセットの属性として、当該イベントグループでのイベント種別のイベントランクを特定するイベントランク初期値を有する。

そして、サーバー１０の前記プロジェクト開設部１２が、イベントグループを処理するための開設支援処理３１を備える。開設支援処理３１は、前記プロジェクトの開設に際して、前記イベントグループが指定された際に、前記イベントグループセットコードの入力を促して、イベントグループセットを特定し、当該イベントグループセットでの各イベント種別のイベントランクを前記初期値として当該イベントグループセットを案内する。

図１６は、プロジェクト開設処理の一例を示すフローチャートである。まず、本支店１の担当者が、端末１ａを操作して、プロジェクトの開設を指示する（ステップS２０）。すると、プロジェクト開設部１２は、プロジェクト名等のプロジェクトの属性の入力を促し、プロジェクトテーブル６１に格納する（ステップS２１）。続いて、プロジェクト開設部１２は、当該プロジェクトへのイベント種別の割り当てを促し（ステップS２２）、プロジェクトに属するイベントをプロジェクト・イベントテーブル６２に格納する。

イベントグループを使用する例では（ステップS２３）、プロジェクト開設部１２は、開設支援処理３１として、前記イベントグループが指定された際に、前記イベントグループセットコードの入力を促してイベントグループセットを特定する（ステップS２４）。開設支援処理３１は、続けて、当該イベントグループセットでの各イベント種別のイベントランクを前記初期値として当該イベントグループセットを案内する（ステップS２５）。例えば、図１７に示す各イベントのイベントランク初期値に応じて「やる」「やらない」を表示し、編集を促すことで、イベントグループセットを案内する。そして、イベント種別とそのイベントランクの確認又は更新を促して、そのイベントランクのイベント種別をプロジェクトに割り当てる（ステップS２６）。

プロジェクト開設処理は、プロジェクトへのイベントの割り当て（ステップS２１から２２）と、予めイベント種別に割り当てられた様式文書を当該プロジェクトで使用するか否かの調整と、プロジェクトのイベントの一覧表示に際して、各イベントのスケジュールの入力又は確認を促す処理とにより、完了する。スケジュールの入力又は確認処理（イベント日付管理部１８及び作業予定管理部２２）については、図１８に示すプロジェクト表示処理のフローで説明する。

図１６に示す例では、さらに、イベント文書特定部１９が、イベント文書関連マスター５０を参照して、プロジェクトに割り当てられたイベントと、様式文書との関係を特定する。まず、イベント種別コードから様式文書を特定する（ステップS２７）。次に、様式文書マスター４８を参照して、様式文書の所在や格納先を特定する（ステップS２８）。さらに、様式文書の使用区分５３を特定する（ステップS２９）。当該プロジェクトと文書との関係に関する特定は、プロジェクト・イベント文書テーブル６４等に格納するようにしても良いし、ビューとなるテーブル６０を生成するようにしても良いし、端末１ａの表示や検索等の必要に応じて毎回イベント文書特定部１９による処理をするようにしても良い。

図１６に示す各工程は、図１に示すサーバー１０の各部に対応し、そして、図１６等に示すフローチャートはプログラムを実行するサーバー１０等のコンピュータにより動作させることができる。そのプログラムは、各部又は各工程に応じた指令を有する。各指令を有するプログラムは、ネットワークを介してサーバー１０となるコンピューターに導入するようにしても良いし、プログラムを記録する記録媒体１１Aをサーバー１０のディスクドライブに挿入して、サーバー１０に導入するようにしてもよい。

図１７を参照すると、イベントグループを使用する例では、支店担当者等のプロジェクト開設の担当者に対して、例えば、「建築：品質管理ISO」というイベントグループでの標準的なイベントのセットを提示することができる。イベントグループは、図１７に示す例では、着工前会議から工事反省会までの一連の品質管理業務である。
さらに、イベントグループセットとイベントランク初期値とを使用する例では、開設支援処理３１は、イベントグループセットコードであるA，B，C又はDが特定されると、イベントグループマスター４５を参照して、当該セットコード（A，B，C又はD）での各イベントのイベントランク初期値（やる又はやらない）を読み出し、図１７に示すイベントランク設定画面８５に表示する。このため、担当者は、イベントグループセット毎に予め定められたセットのイベント群を何ら文書等を参照することなく知ることができ、そのままプロジェクト開設をすることもできる。そして、個別のプロジェクトの開設にて、当該プロジェクトで特有に必要のあるイベントや、不要なイベントを指定することで、当該イベントグループに含まれるイベントの固有のセットを当該プロジェクトに割り当てることができる。

・プロジェクト開設処理の作用効果
このプロジェクト開設処理では、イベント日付管理部１８が、プロジェクトに属するイベントのスケジュールを管理し、作業予定管理部２２が、イベントの表示に際して、当該イベントの準備文書と作成文書とを区分けして表示制御する。従って、端末１ａに、プロジェクトに属するイベントの一覧を表示し、各イベントのスケジュールを表示し、さらに、このスケジュールのイベントまでに準備すべき文書と、イベント後に作成すべき文書を表示制御する。

このため、プロジェクトの遂行者は、使用（準備及び作成）すべき文書について、どのイベントとの関係で使用すべきであり、文書単位でその予定日等のスケジュールを事前に把握することができる。これにより、プロジェクトに必要な業務と文書との乖離を抑制し、文書活用型の業務スタイルを推進することができる。
特に、プロジェクトの直接の業務（例えば工事の遂行）自体ではなく、安全、品質、財務、コンプライアンス等の管理業務について、文書群の名称等を予めイベントとすることで、提出すべき文書を事前に周知徹底し、その予定日等のスケジュールをプロジェクト遂行者に表示制御することができる。

このように、情報技術を用いて文書活用型の業務スタイルを推進することにより、プロジェクトで使用する手法や技術についての管理能力が高まる。すなわち、本実施例は、 プロジェクトの遂行者に対して、作業要領書や手順書等の配布により文書活用を促すのではなく、情報技術を使用して、強制的に、イベントの予定と、提出すべき文書とをイベント実施予定日等の日付とともに表示するため、情報技術を用いて文書活用型業務を行う体制を強固に構築することができる。

この情報技術を用いた文書活用型業務体制の構築により、プロジェクト実施のばらつきを減少させ、さらには、品質管理が難しくなる新技術のプロジェクトへの適用も、強固な文書活用型業務により安定して管理可能となる。
そして、管理業務が実施要領書や手順書として発行され、その手順上作成が必要とされる文書について、予めイベントとの関係で登録しておくことで、必ずしも全ての手順書に精通していない社内外のプロジェクト担当者であっても、プロジェクトの進捗に応じて作成すべき文書を、一覧として把握することができ、個々の手順書の理解向上にも役立つ。

また、多数のプロジェクトについて、同一のイベント群と、文書群とを使用し、スケジュールの事前周知により文書活用型の業務スタイルを推進することで、実施要領書自体や文書の文書項目自体に改善すべき対象がある際に、その改善事項を発見しやすくなる。すなわち、様式文書及び予定日の事前周知というプロセスを情報技術により確保するため、個々のプロジェクトに特有の課題と、実施要領自体の課題とを切り分けて、共通する実施要領等自体の改善項目を抽出しやすくなる。すると、実施例１から３によるシステムをさらに進化させることができる。
これにより、プロジェクトに関する業務、特に管理業務上作成が必要な文書について、問い合わせ及び応答の作業を減らすことができる。またこれは、本支店での人事異動での引継の容易性を向上させる。そして、イベントと含まれる使用予定の文書とを情報技術により周知することで、個別のプロジェクトにて、実施要領書等に従った業務が推奨され、手戻り発生を防止することでプロジェクトに要するコストのばらつきを抑制することができる。

さらに、作成すべき文書が予め定まり、その文書はイベントと関連づけられているため、プロジェクト進行中（施工中）から文書の保存場所が論理的に準備されており、実際に文書を作成したときに、プロジェクトの担当者は、その文書がどの業務に関連しているのかを理解しやすく、当該文書をアップロード（保存）すべき所在等の探索も容易となる。

＜作成文書ナビ：表示処理＞
作業予定管理部２２は、図１８に示す情報処理に従って登録されているプロジェクトに関するデータを、端末１ａの操作に応じて表示制御する。

図１８は、プロジェクトの表示処理の一例を示すフローチャートである。端末１ａの操作に応じて、作業予定一覧表示が指示され、その要求を受信すると（ステップS４０）、サーバー１０は、当該プロジェクトに含まれるイベントの一覧を生成する（ステップS４１）。続いて、各イベントに含まれる文書を特定し（ステップS４２）、例えば図１９に示すイベントの一覧と、例えば図２０に示す各イベントに含まれる文書の一覧とを生成する。

続いて、文書一覧での情報を、イベント単位に集約するための集約ルールを読み込む（ステップS４３）。集約ルールは、例えば、イベントに含まれる全文書の数や処理済の文書数という集約等のルールである。このルールは、システム開発時点で特定のルールとしておくようにしても良いし、本支店担当者が個別のプロジェクト毎に選択できるようにしても良い。サーバー１０は、集約ルールに従って文書の属性（予定日などスケジュールや使用区分５３）を読み込み（ステップS４４）、文書属性を当該ルールに従って集約処理する（ステップS４５）。

そして、イベントの操作に応じて、集約したデータにてイベントの一覧を表示する（ステップS４６）。例えば、図２１に示す図中左側の各イベントに付加された分数表示は、当該イベントに属する処理済の書類数と全書類数との比である。
イベントの表示に際して、プロジェクト開設時に割り当てた枝番１のイベントから派生するイベントで、枝番１のイベントのスケジュールとは別のスケジュールとなるイベントがある際には、別枝番のイベントの追加を促す（ステップS４７）。例えば、図１９（A）のプロジェクト・イベント一覧画面８６にて、各イベントの図中左端部にてプラスマークのボタンを配置し、当該ボタンの操作により別枝番のイベントの登録をするように促す。図１９（A）に示す○○品質向上協議会との枝番１のイベントについて、○○品質向上報告という新たな枝番のイベントが入力されると（ステップS４８）、図１９に示すように、別途のスケジュール管理が可能な枝番２のイベントを追加する。

イベント一覧の表示に応じて、予定日等のスケジュールが入力編集されると（ステップS４９）、イベントのスケジュールを更新する（ステップS５０）。また、個別文書登録要求を受信すると（ステップS４９）、まず、文書タイトル等を登録する（ステップS５０）。

図１９（A）を参照すると、プロジェクト・イベント一覧画面８６では、○○物流センター建設工事という名のプロジェクトに属するイベントとして、イベント種別共通から割り当てられた作業基本情報や、○○品質向上協議会等のイベントが表示される。イベント名はリンクとなっており、例えば建築：品質管理ISOの表示が操作されると、図１９（B）に示すイベント一覧画面８７を表示する。
イベント一覧画面８７では、イベント日付の設定を促す。マスター登録時及びプロジェクト開設時に登録したデータを使用して、イベント予定日を表示しても良いし、作業所の担当者に日付入力を促しても良い。予定日と実施予定日との使い分けについては、例えば、プロジェクト開設時又はその直後に、イベント予定日の確認又は入力を促し、個別のイベントが近くなり関係者の会議等の案内に至った際にイベント実施予定日の入力を促すようにしても良い。

図２０を参照すると、イベント文書一覧画面８８では、文書を、使用区分５３による準備又は作成の区分に応じて、イベント実施日までに準備する書類と、イベント実施により作成する書類とに区分けして表示する。従って、予定日又は実施予定日が表示されると、その日までに準備する書類の一覧と、実施予定日の直後に作成すべき書類とが区分けして表示される。この使用区分５３を用いた文書の区分けにより、イベントと文書との関係のみならず、イベントの文書作成のタイミングの関係をも明確に表示することができる。これにより、スケジュールに応じた文書の使用を促すことができる。

この図２０に示す例では、イベント名は建築・品質パトロールであり、九州新幹線（鹿児島）○○基地建物新築という名のプロジェクトの一部である。所長名や工期等のプロジェクトの属性を表示し、予定日、実施予定日等のスケジュールを表示する。実施日は、当該実施の完了を業務として確定した際に登録する等の取り決めに応じて、例えば、実施日入力及び更新は、作業所ではなく、支店又は本部の担当者のみ操作可能としてもよい。
この品質パトロールでは、３つの文書を準備し、実施後に２つの文書を作成する。図中版数は、プロジェクト・イベント文書テーブル６４の作成版数であり、様式版数ではない。GUI操作としては、例えば、各文書の左端のチェックボックスをチェックして、様式文書ダウンロードボタンを操作すると、当該文書の様式文書IDから、様式文書マスター４８を参照して、様式文書所在を読み出し、当該所在にあるファイルを当該端末１ａに転送し、表示制御する。図２０に示す例では、文書一覧として、作成版数、送信の有無及び送信日、承認の有無及び承認日を一覧として表示する。
なお、この建築・品質パトロールIを２回行う場合には、２回目の枝番を２として、準備文書については共通とし、作成文書は別途の文書となる。

図２１を参照すると、イベント文書一覧画面８８では、当該プロジェクトの品質管理に関するイベントの一覧を表示し、選択されたイベントについて、提出済の文書と、使用予定の文書とを表示する。イベントである図面検討にて（２/４）とあるのは、送信済文書数／全文書数の集約処理の結果である。この集約は、使用区分５３及び表示日に応じた集約としても良い。

図２２を参照すると、品質管理の図面検討会の文書画面８９では、文書のタイトルと、様式文書の所在（図２２ではURL）と、複数のイベントで重複して使用する文書である際には、直近のイベントの所在と、予定日等を表示する。図２２に示す例では、スケジュールとして、提出の予定日及び実施日、承認の予定日及び実施日を取り扱っている。また、複数のイベントで重複して同一の様式文書に応じた関連文書を使用する際には、直近文書を表示する。この図２２に示す例では直近文書なしとなっている。

・表示処理の作用効果
図１６に示すプロジェクト開設処理をすると、図１８に示す表示処理により、図１９に示すイベントと予定日との一覧と、当該イベントにリンクした文書の一覧とを表示することができる。特に、実施例１の表示制御では、提出済の文書のみを検索するのではなく、使用予定の文書のタイトルを使用区分５３に応じて表示することができる。

＜作成文書ナビ：集約処理＞
実施例１では、文書単位の情報を、イベント単位の情報へと集約する処理を行う。この例では、サーバー１０が、集約ルール管理部２４と、集約処理部２６とを備えている。

集約ルール管理部２４は、前記文書の属性の種別に応じて、当該文書の属性をイベント単位に集約する予め定められた集約ルールを保持する。集約ルールとしては、イベントに含まれる複数の文書のステータス（未処理、送信済、承認済）を集約するルールがある。例えば、プロジェクトの文書作成担当者向けには、送信済／全文書との数の表示が望ましい。
また、送信日・承認日等は文書毎に個別に管理されるところ、イベント単位で表示する際には、最も早い日付や最も遅い日付に集約するルールとしてもよい。「最も早い日付」は、言語処理系に応じて例えば１９７０年１月１日を起算点として秒の値で年月日を管理する際には、その数値が最も小さい日である。集約処理の対象は、個別の文書単位で管理されるデータであって、イベントの一覧で表示するデータである。「集約ルールを保持」するには、集約ルールを予め外部記憶装置等に格納しておき、実行時に読み出すようにしても良いし、端末１ａからの動的な指定に応じて主メモリに集約ルールを展開するようにしても良い。

集約処理部２６前記端末１ａに前記イベントの一覧を表示する際に、前記文書の属性の種別に応じて前記集約ルールを特定し、当該集約ルールに従って文書の属性をイベント単位に集約する。集約処理部２６は、図１７に示すステップS４３、S４４及びS４５の処理をする。

集約ルールは、文書のステータスに応じた数、 重複して使用をする文書数、予定日等の日付、提出先、全文書の全文書項目数等が考えられる。提出先については、送信日が最も早い提出先か同日であれば文書IDが小さいものとしつつ、提出先数を表示するようにしても良い。

・集約処理の作用効果
集約処理では、集約ルール管理部２４が、集約ルールを保持し、集約処理部２６が、イベントの一覧を表示する際に、当該イベントに含まれる文書の状況を簡易に表示するために、数や日付等を集約ルールに従って一覧表示可能に集約する。
従って、端末１ａの操作者は、使用に習熟するに従い、集約表示のみを確認することで、当該イベントに含まれる文書についてどのような作業が必要であるかを把握できるようになり、また、集約表示により、当該イベントに含まれる文書の一覧を確認すべきか否かの正確な判断を促すことができるようになる。すなわち、イベントと文書との階層的な管理を浸透させることができる。また、本支店の担当者が各プロジェクトの進捗を把握する際にも、この集約処理による表示が有用である。
この集約処理により、さらに、文書活用型の業務スタイルを情報技術の利用により推進することができる。

＜作成文書ナビ：個別使用予定登録処理＞
実施例１では、予め定められた文書のみならず、プロジェクトに固有の個別文書の登録を可能とする。この例では、様式文書マスター４８が、当該様式文書として、当該関連文書の様式を特定しない個別様式文書を有する。そして、前記テーブル６０として、プロジェクトIDと、イベント種別IDに応じたイベントIDと、様式文書IDに応じた個別文書IDとをキーとして特定のプロジェクトに特定のイベントで使用される個別文書の属性を格納するプロジェクト・イベント文書テーブル６４を有する。さらに、前記サーバー１０が、個別文書管理部２８を備える。

個別文書管理部２８は、前記端末１ａの操作に応じて前記プロジェクトを表示する際に、当該プロジェクトの各イベントで前記個別様式文書に応じた個別文書の使用予定の登録操作を促すと共に、当該端末１ａの操作に応じて当該個別文書が属する前記イベントと前記使用予定の文書タイトルとが入力された際には、当該使用予定の前記個別文書の前記文書タイトルを前記プロジェクト・イベント文書テーブル６４に追加する。
「登録操作を促す」には、例えば、その操作が可能となる操作用のボタンを画面に表示する。そして、個別文書管理部２８は、個別文書の登録に先立ち、個別文書の使用予定の登録を促して、登録された際には、プロジェクト・イベント文書テーブル６４を更新する

個別文書の取り扱いについては、マスター４０にて「個別文書」や「報告」というイベントを登録しておき、文書項目を特定しない文書様式を準備しておくようにしても良いし、各イベントに「その他必要な文書」という様式文書を準備しておくようにしても良い。作業要領書や手順書にて、品質管理上の異常が発生した際の報告や記録の手順が定められており、通常は使用しない文書を使用する際には、例えば、「品質管理例外報告」等のイベントを使用して個別文書の登録を促すようにしても良い。また、様式文書を準備せずに、プロジェクトにて作成した文書ファイルの登録を受信するようにしてもよい。

実施例１の個別使用予定登録処理では、プロジェクトの端末１ａの操作に応じて、作成された個別文書の登録に先だって、使用予定の登録を促す。すなわち、個別文書管理部２８は、イベントの一覧と、関連文書の一覧とを表示しつつ、これに含まれない個別文書の作成が予定されている際には、その個別文書が帰属すべきイベントと、文書タイトルとの入力を促す。なお、個別文書の登録は、別枝番のイベントについてのみ可能とする要件定義としても良い。

再度図２０を参照すると、イベント文書一覧画面８８では、使用予定追加ボタンが表示されている。この使用予定追加ボタンの表示は、個別文書の使用予定の登録を促すものである。このボタンが操作されると、図示しない使用予定追加用の画面を表示して、所属するイベント名（図２０の表示では工事着工会議を初期値表示する）、文書タイトル、予定日、提出先等の登録を促す。

・個別使用予定登録処理の作用効果
個別文書管理部２８は、個別文書の登録に先立ち、個別文書の使用予定の登録を促して、登録された際には、プロジェクト・イベント文書テーブル６４を更新する。すると、その後に当該プロジェクトのイベントの一覧を表示すると、プロジェクト担当者や、本支店担当者間にて、使用予定を共有することができる。個別文書自体の登録ではなく、使用予定を登録することで、一定状況下では作成不要であるが、例外の発生がある際には提出すべき文書を管理対象とすることができる。例えば、プロジェクトの進捗との関係では、早期完了や遅延等のスケジュールに関する例外や、品質管理との関係では工事での異常の発見の報告などがある。これらは、事象が発生しなければ文書とする必要はない。しかし、事象が発生した際に文書化すべきとされている際には、その作成要領等のルールを個別文書の使用予定を登録可能とするという情報技術により、管理対象に含めることが可能となる。この個別文書の使用予定の登録処理は、品質管理等の管理活動の課題の早期把握に役立つ。

＜作成文書ナビ：記録台帳生成処理＞
実施例１では、使用予定を含む記録台帳の生成処理をする。記録台帳は、例えば品質管理等の管理上の要請で予め定められた文書管理規定等に従って文書を保管する際の台帳である。記録台帳は、通常、一連のプロジェクトが完了した後に、当該プロジェクトの遂行にて使用をした文書群を管理するために作成する。一方、本実施例では、プロジェクトの進行途中で、その完了を待たずに、監査や報告等何らかの管理及び統制ために記録台帳を任意のタイミングで生成する。この記録台帳生成処理は、作成文書ナビゲーションシステムに必須の機能ではなく、付加的なものである。この付加的な機能を実現するために、重複フラグ５４及び更新フラグ５６を使用すると情報処理が簡便となる。
この例では、同一のプロジェクトに属する複数の異なるイベントにて、重複して使用される文書の管理が課題となる。この例では、情報処理を容易とするために、マスター４０のイベント文書関連マスター５０が、各関連文書について、同一プロジェクト内の複数のイベントで重複して使用されるか否かを示す重複フラグ５４と、当該重複して使用される当該文書が各イベントの進捗に応じて更新されるか否かを示す更新フラグ５６とを有する。そして、プロジェクト・イベント文書テーブル６４が、前記属性として、文書ファイル所在を有する。
重複フラグ５４については、プロジェクトの開設に際して、プロジェクト開設部１２等が、イベントに様式文書が割り当てられた際に、当該様式文書が当該プロジェクトの他のイベントでも使用されているか否かを検索し、使用されている際に当該重複フラグ５４をオンとすると良い。その他、ユーザーによって同一の様式文書が複数のイベントに割り当てられた際に重複フラグ５４をオンとするようにしても良い。
更新フラグ５６については、端末１ａの操作に応じて文書を登録する際に、当該文書に対応する様式文書の重複フラグがオンであると、直近の文書の版数と今回の版数とを比較して異なる場合に更新フラグ５６をオンとすると良い。または、上書きされる際に、版数を増加させるとともに更新フラグ５６がオフである場合にはオンに更新するようにしても良い。

そして、この付加的な実施例（記録台帳生成処理）では、前記サーバー１０が、記録台帳生成部３０を備える。記録台帳生成部３０は、前記端末１ａから記録台帳生成が指示された際に、前記プロジェクト・イベントテーブル６２と、前記プロジェクト・イベント文書テーブル６４とを参照して、当該プロジェクトの提出済及び使用予定の文書の一覧を生成する。提出済の文書には送信日が格納されており、使用予定の文書には送信日が格納されていない。

図２３を参照すると、前記記録台帳生成の前記プロジェクトが特定された際に、当該プロジェクトの前記各イベントを特定し（ステップS６１）、特定されたイベントに含まれる文書を特定する（ステップS６２）。処理開始時は最初の文書を特定し、繰り返し処理の際には次の文書を特定する。

そして、当該特定した文書が前記使用予定である際には、当該使用予定の文書について、重複フラグ５４を読み出して（ステップS６３）、重複フラグ５４がオンの際には予定日と直近のイベントとを読み出し（ステップS６４）、重複フラグ５４がオフの際には予定日を読み出す（ステップS６５）。「直近のイベント」は、処理中の文書について送信日がある文書を含む他のイベントのうち、処理中の予定日に最も近いイベントをいう。また、送信日がある文書のうち、送信日が最も処理日時に近い提出済の文書を特定し、当該文書のイベントを直近のイベントとしても良い。

当該重複フラグ５４がオンの文書について、さらに、更新フラグ５６を読み出して（ステップS６６）、更新フラグ５６がオンの際には更新表示を保持し（ステップS６７）、更新フラグ５６がオフの際には重複表示を保持する（ステップS６８）。「更新表示」は、当該文書が更新されるべきものであることを端末１ａの操作者に伝達するもので、文字や記号であり、同様に、重複表示は、更新されない重複して使用すべき文書であることを操作者に伝達する文字や記号である。更新フラグ５６はオン又はオフのいずれかであるため、重複フラグ５４がオンで使用予定の文書については、更新表示又は重複表示の一方が読み出される。各表示の「保持する」という処理は、当該文字や記号を実際に読み出す処理でも良いし、当該更新フラグ５６自体をその後の情報処理で利用可能に主メモリに保持しておくことでも良い。

当該イベントの全ての文書について繰り返して（ステップS６９）、文書一覧を生成する（ステップS７０）。この文書一覧の生成に際しては、文書のタイトルや作成者、提出先等を読み出して一覧とする。そして、当該使用予定の文書については、前記読み出した前記予定日、直近のイベントと、前記保持した重複表示又は更新表示を当該イベントの前記文書の一覧に追加する。提出済の文書については前記送信日と前記文書ファイル所在とを当該文書の一覧に追加するさらに、当該プロジェクトの全てのイベントの文書の一覧を生成するまで繰り返し（ステップS７１）、当該プロジェクトの全てのイベントの文書の一覧を表示制御する（ステップS７２）。

図２４を参照すると、使用予定及び重複表示を含む記録台帳は、イベントの順序で、イベント名、文書タイトル、処理済文書について送信日、使用予定文書についてイベントの予定日、それぞれの所在、重複する文書については直近のイベント名（での文書の所在としても良い）、使用予定の文書について重複表示又は更新表示が含まれる。図２４の文書の構造は、図５（A）に示したものと同一である。イベント１には、文書１から文書４が含まれており、提出されている。このため、予定日欄のデータを表示せず、所在をURLで表示している。イベント２については、３つの文書が提出され、２つの文書が使用予定となっている。文書２は、2/20日が予定日である。この文書２は重複ありで、所在の代わりに直近のイベント（ここでは、イベント１）を表示することで関連文書を案内している。文書６については、直近のイベントはない。イベント３は、すべての使用予定である。文書２については、イベント１が直近のイベントであり、1/15に提出された文書から更新することとなる。イベント２の文書２が提出されると、直近イベントが当該イベント２となる。文書５については、提出されていないが、実質的に文書の作成がされているとみることもできる。
このように、記録台帳生成処理では、使用予定の文書とその属性とを示すことで、当該プロジェクトの完了前に、最終的な記録台帳の全体的構成をプロジェクトの進捗に応じて生成することができる。

・記録台帳生成処理の作用効果
記録台帳生成部３０が、文書単位の重複フラグ５４と更新フラグ５６とを使用して、使用予定で重複する文書については直近のイベント名を読み出し、さらに重複表示又は更新表示を保持する。そして、イベントとの関係で、処理済の文書一覧と、使用予定文書の一覧とを記録台帳に含め、使用予定の文書については、直近のイベントと、重複表示及び更新表示を一覧に含める。このため、記録台帳生成処理を実行した段階でのプロジェクトの進捗に応じて、文書記録の一覧と、使用予定の一覧とを生成することができる。さらに、使用予定の文書については、すでに存在する関連文書のイベント名を示すことで、当該文書がどのように作成されるかについて一定の予想を表示することができる。特に、当該文書が更新されるか否かを重複表示又は更新表示にて表示するため、使用予定の文書の記録がどのようになるのかを、事前に表示することができる。すると、最終的な記録台帳のイメージをプロジェクト関係者で共有することができ、文書活用型の業務の推進を図ることができる。

＜作成文書ナビ：版管理処理＞
様式文書マスター４８の様式文書所在と、プロジェクト・イベント文書テーブル６４の文書ファイル所在とは、物理的な外部記憶装置上のオペレーティング・システムやネットワーク上の実際のファイル名ではなく、当該ファイル名を特定可能な一段階抽象化したロケーションのデータであることが望ましい。この所在は、TCP／IPとWebアプリケーション・サーバー１０の組み合わせの場合にはURLとすればよい。この場合、各文書について所在を唯一としておき、実際の文書ファイルの保管を複数可能な構成とすると、文書の版を管理しつつ、端末１ａの操作者に対しては各文書について唯一のアップロード先という判りやすいインタフェースを提供することができる。

版の管理をするには、例えば、様式文書や文書が上書きされる際に、既存のファイルを当該文書IDと版数との関係で保存する。そして、過去のファイルを参照する指令を受信した際には、版数と過去のファイルの所在とを端末１ａに表示し、ダウンロード可能とするとよい。版と文書ファイルの関係では、文書ID毎に唯一のディレクトリーを関係させ、そのディレクトリーに複数の版のそれぞれのファイルを格納するようにしても良いし、過去の上書きされたファイルを別のディレクトリーに集め、様式文書又は文書の別と、プロジェクトと、イベントと、版とを特定することで、上書きされた文書を特定できるように管理すると良い。

・版管理処理の作用効果
版管理処理をし、端末１ａの操作者に１つの文書について１つの所在を表示しつつ、上書きされた過去の文書を別途保管しておくと、通常のアクセス権での通常の操作で文書を消去することがないため、文書の改ざんや不注意による削除が不可能となり、プロジェクトの管理業務で配慮すべき事項を減少させ、効果を高めることができる。

＜作為文書ナビ：文書の重複更新管理処理＞
文書単位の重複フラグ５４と更新フラグ５６との使用により、上記記録台帳生成部３０の処理が可能となる他、図２２に示したように、重複文書の有無と、その所在とを端末１ａの操作者に表示することができる。
・文書の重複更新管理処理の作用効果
重複及び更新を情報処理により管理して端末１ａに表示するため、重複する文書の作成負荷を軽減することができる。

次に、本実施形態の実施例２を開示する。
＜プロジェクト検索処理：イベント名＞
図２５を参照すると、実施例２の文書検索システムは、実施例１の作成文書ナビゲーションシステムと同様に、端末１ａと、サーバー１０と、データベース４０，６０とを備えている。
そして、マスター４０として、イベント種別マスター４４と、イベント文書関連マスター５０とを保持している。テーブル６０として、プロジェクトテーブル６１と、プロジェクト・イベントテーブル６２と、プロジェクト・イベント文書テーブル６４とを保持している。
これらの構成は実施例１と同様である。また、テーブル６０には、実施例１の手法か同様の手法で複数のプロジェクトのデータが格納されているとする。イベントグループは利用しても利用していなくても良い。

実施例２は、いくつかの詳細がある。すなわち、イベントでの検索処理（第１）、様式文書での検索処理（第２）、適用技術での検索処理（第３）、イベント目的区分での検索処理（第４）である。いずれの詳細についても、検索のキーを用いて、まず、イベントを特定し、その後、プロジェクトを串刺しで検索する。従って、イベントの検索処理が基本的な情報処理となり、この情報処理は、実施例１により生成されるテーブル６０と協調して動作する。

イベントで検索処理する実施例２では、その特有の構成として、プロジェクト・イベントテーブル６２が、属性として、各イベントの完了予定日である予定日を有する。そして、前記プロジェクト・イベント文書テーブル６４が、属性として、前記文書の送信日及び予定日を有する。
さらに、当該実施例２では、前記端末の操作に応じてイベントを指定した検索が要求された際に動作する検索処理として、前記サーバー１０が、第１イベント一覧生成部１０２と、第１プロジェクト一覧生成部１０４と、文書一覧生成部１０６とを備えている。この各生成部は、実施例１で開示したイベント文書特定部１９の機能を利用するため、イベント文書特定部１９が、各生成部を備えると構成しても良い。

図２６を参照すると、第１イベント一覧生成部１０２は、前記マスター４０のイベント種別マスター４４を参照してイベント一覧を生成し、当該イベント一覧を前記端末１ａに送信し、検索対象とするイベントの指定を促す（ステップS８０）。すなわち、マスター４０に予め登録されているイベントの一覧を生成して、これを検索対象のキーとすべく、端末１ａに表示する。

次に、第１プロジェクト一覧生成部１０４は、前記端末１ａの操作に応じて前記イベントが指定された際に、前記プロジェクト・イベントテーブル６２を参照して当該イベントを含むプロジェクト一覧を生成し（ステップS８１）、当該予定日を含むプロジェクト一覧を前記端末に表示制御することで、当該プロジェクトの指定を促す（ステップS８２）。プロジェクト・イベントテーブル６２には、着手や完了していないイベントについても、予定日とともにイベント名が格納される。従って、プロジェクトの一覧には、完了、着手済及び未着手のプロジェクトが含まれる。イベントが完了しているプロジェクトについては、業務完了日を一覧に含めるようにしても良い。業務完了日は、含まれる全ての文書に送信日がある場合で、最も遅い送信日を業務完了日とすると良い。システム開発要件によっては、送信日ではなく、承認日としても良い。また、文書の送信日とは別途業務完了日を取り扱う際には、図９に示すプロジェクトイベントテーブル６２にて、属性に業務完了日を含めると良い。

さらに、文書一覧生成部１０６は、前記プロジェクト一覧の各プロジェクトについて、前記プロジェクト・イベント文書テーブル６２を参照して、当該イベントに含まれる文書を特定し、当該特定した文書の送信日又は対応するイベントの予定日を含む文書一覧を生成し、表示制御する（ステップS８３）。各プロジェクトについて、文書一覧を生成する。ここでは、複数のプロジェクトのうち唯一のプロジェクトを対象としても良いし、端末１ａの操作に応じて一部のプロジェクトを対象としても良い。また、端末１ａの操作に応じて文書一覧を生成しても、事前に生成しても、プロジェクトの一覧と一体化すべくプロジェクトの一覧の表示制御と同期して生成するようにしても良い。
使用区分を利用する例では、準備の際には実施予定日の１週間前、使用の際には実施予定日の１週間後などの実施予定日との関係で実際に当該文書の準備又は作成の期限を定めておくと良い。この場合、上記イベントを単位とした予定日を、個別の文書の使用予定日とすることができる。

図２７に示す工事着工会議の検索結果画面９０は、この工事着工会議というイベント名を使用した検索処理によるプロジェクト一覧を表示したものである。検索した時点で、当該イベントを含むプロジェクトが多数有る。例えば、汐留プロジェクト新築工事という名称のプロジェクト（プロジェクト）は、この工事着工会議が2008年1月13日に完了している。霞ヶ関○○庁舎のプロジェクトでは、工事着工会議を3/15までに行う予定となっている。このように、イベント名を特定することで、当該イベントが完了したプロジェクトと、業務予定とするプロジェクトとの一覧を生成することができる。
また、この工事着工会議の検索結果画面９０にて、端末１ａの操作者が、霞ヶ関○○庁舎を操作すると、当該プロジェクトの当該イベントの文書の結果検索画面９１を表示制御する。ここでは、３種類の決定工事引継書が処理済で、他の２つが作成予定となっている。

・イベント名での検索処理の作用効果
第１プロジェクト一覧生成部１０４が、指定されたイベントを検索キーとして当該イベントを含む個別のプロジェクトの一覧を生成し、文書一覧生成部１０６が、検索された各プロジェクトの文書一覧を生成し、そして、プロジェクトの一覧には、着手済又は未着手の状態での予定日が含まれ、文書一覧には、文書の送信日又は予定日が含まれる。
このため、イベントを特定すると、当該イベントが、完了、着手済及び未着手の状態（ステータス）のプロジェクトの一覧を生成することができる。すなわち、イベントを予定としているプロジェクトを含めて多数のプロジェクトを横断的に串刺しで検索し、抽出することができる。このため、例えば、あるイベントを改善する際に、適用対象とすべきプロジェクト（プロジェクト）を人手によらず情報技術により素早く特定することができる。従って、改善の早期反映と徹底を支援することができる。また、特定のイベントの特定の文書を更新する際など、イベントの指定によりプロジェクト串刺しで文書を探すことができる。
これらにより、品質や安全や財務等の管理活動に必要な作業や時間を見える化し、管理業務のコスト測定精度を向上させることができる。また逆に、任意にイベントを指定したプロジェクト串刺しの文書検索が可能となることから、プロジェクトを串刺する現状把握を端末１ａの操作によってすることができ、品質管理等の管理活動の課題を早期把握することができる。

＜プロジェクト検索処理：文書名＞
再度図２５を参照すると、様式文書の指定による検索をする実施例２による文書検索システムは、次の構成を採用する。すなわち、前記マスター４０が、様式文書のIDをキーとして当該様式文書の属性を格納する様式文書マスター４８を保持する。そして、前記サーバー１０又はそのイベント文書特定部１９が、様式文書一覧生成部１１０と、第２イベント一覧生成部と、第２プロジェクト生成部１１４とを備えている。

図２８を参照すると、様式文書一覧生成部１１０は、前記様式文書マスター４８を参照して、様式文書一覧を生成して前記端末に表示制御すると共に、検索対象とする前記様式文書の指定を促す（ステップS９０）。すなわち、予め定められている様式文書の一覧を生成する。この表示制御では、文書名の検索を促して当該様式文書一覧から検索結果となる文書名を表示したり、所管部での区分けをして表示したり、登録済みの文書情報を表示させることができる。

次に、第２イベント一覧生成部１１２は、前記様式文書が指定された際に、前記イベント種別マスター４４を参照して当該様式文書を含むイベント一覧を生成する（ステップS９１）。様式文書は、複数のイベントで使用されることがあるため、関連付けられているイベントは２以上となることがある。

そして、第２プロジェクト生成部１１４は、当該イベント一覧の各イベントについて、前記プロジェクト・イベントテーブル６２を参照して、当該イベントを含む前記プロジェクトを特定し、当該プロジェクト一覧を生成する（ステップS９２）。さらに、このプロジェクト一覧を表示し（ステップS９３）、そのプロジェクト一覧からプロジェクトが指定された際には、当該プロジェクトでの文書の一覧や内容が表示される（ステップS９４）。

この文書を検索キーとする検索結果は、図２７に示すプロジェクト名の一覧画面となる。プロジェクト名の操作に応じた表示では、当該プロジェクト名と、当該プロジェクトにて検索キーとなる文書を使用するイベントの一覧とを表示すると良い。

また、この文書名を検索キーとする検索処理では、文書名を任意としつつ、文書のステータスで検索可能としても良い。この場合、ステップS９０にて、指定される文書のステータスの指定を促して、文書を特定すると良い。図２９に、使用予定のステータスを有する文書の一覧を検索した結果を示す。

・文書名での検索処理の作用効果
第２プロジェクト一覧生成部１１２が、指定された様式文書を含むイベントを検索キーとして当該イベントを含む個別のプロジェクトの一覧を生成し、文書一覧生成部１０６が、検索された各プロジェクトの文書一覧を生成し、そして、プロジェクトの一覧には、着手済又は未着手の状態での予定日が含まれ、文書一覧には、文書の送信日又は予定日が含まれる。
このように、様式文書を指定すると、当該様式文書を使用したプロジェクトと、使用する（使用予定）プロジェクトの一覧を情報処理により生成することができる。このため、様式文書を更新する際に早期反映と徹底をすることができる。また、担当者は、様式文書を指定するだけでプロジェクトの一覧を得ることができるため、業務に必要な文書を探す時間を短縮することができる。
そして、同一の又は複数のプロジェクトから文書をダウンロードする際にも、様式文書名や、文書のステータスに応じて検索し、文書を特定できるため、例えば、特定のイベントの処理済の文書の一覧を表示させ、一括してダウンロードする等の情報処理も可能となる。
さらに、あるプロジェクトで緊急事態が発生し、その緊急事態は他のプロジェクトで経験したことがある場合などには、緊急事態に関連する様式文書を指定することで、当該他のプロジェクトがどのプロジェクトであるのか、検索処理により早急に発見することができるようになる。

＜プロジェクト検索処理：適用技術＞
サーバー１０又はそのイベント文書特定部１９は、適用技術をキーとした検索を実装するようにしても良い。文書名での検索と同様に、イベントを特定できれば、第２プロジェクト一覧生成部を用いてプロジェクトの一覧を生成することができる。適用技術をデータ構造に組み込むには、既存の文書の既存の文書項目を利用しても良いし、適用技術を記載する様式文書をプロジェクトの早い段階でのイベントに含めるようにしても良い。しかし、適用技術の一覧を生成し、表示又は検索可能としておくことが望ましい。

図３０は、適用技術をキーとした検索処理の一例を示すフローチャートである。まず、適用技術の一覧を階層的に表示するか、技術用語にて検索処理することで、適用技術を特定する（ステップS１００）。続いて、適用技術から文書を特定する（ステップS１０１）。例えば、適用技術を記載する文書群を特定し、文書内部のデータを検索する等して、当該技術を適用しているか否かを情報処理により判定する。当該技術を提供していることを示す文書を特定すると、その後は、図２８に示すステップS９１以下の処理と同様である。

・適用技術での検索処理の作用効果
適用技術を検索キーとする検索処理では、技術名から、その技術を適用していることを示す文書を特定し、この文書からイベントを特定し、イベントからプロジェクトを特定する。
これにより、特定の技術を使用しているプロジェクトを情報検索により抽出することができ、技術の具体化を任意のタイミングで確認し、また、開発中の技術に関連する技術の適用状況やその推移を容易に把握することができる。例えば、新しい画期的な測定技術が開発され運用可能となった際に、その新しい測定技術を利用可能なプロジェクトを検索することができる。また、品質管理活動にて、特定の技術についての品質管理の課題が明らかになった際に、同様の技術を使用している他のプロジェクトを素早く検索し、早期対応をすることができる。さらに、この適用技術での横断的な知識を検索可能となると、プロジェクトに新しい技術を適用する際の一般的な課題やコストが「見える化」され、これにより、新技術を適用するコストを見積もる精度の向上や安定化を見込むことができる。

＜プロジェクト検索処理：イベント目的区分＞
実施例２では、イベントの種類を示すイベント目的区分から、プロジェクトを検索できるようにしても良い。イベント目的区分は、多様な利用が可能である。例えば、品質管理は、PDCAサイクルを回すことによって行うところ、品質管理に関するイベントは、プランP、実行D、チェックＣ、是正措置Aのいずれかである。例えば、図１８に示すイベントのうち、検討会はPであり、品質パトロールや監査、検査はCである。従って、各イベントは、PDCAのいずれかの区分に属させることができる。すると、膨大なイベントのうち、チェックに関するイベントのみの一覧と、チェックに関する文書の一覧を生成することができる。しかも、実施例２では、使用予定の文書も含まれる。このように、イベント目的区分を定義し、利用すると、管理活動を効率化することができる。

また、イベント目的区分は、複数者の日程調整が必要なもの、厳格な規定に従った文書記録が必要なもの等、イベントの態様のコード化に使用することもできる。さらに、各イベントにて検討対象となる技術分野や知的財産権を整理しておき、技術分野や知的財産権からプロジェクトを検索できるように紐づけても良い。

図３１は、イベント目的区分での検索処理の一例を示すフローチャートである。まず、イベント目的区分の一覧を表示し又は検索を促す等として、イベント目的区分を特定する（ステップS１１０）。次に、イベント目的区分から、当該イベント目的区分に適合するイベント群を特定する（ステップS１１１）。イベントが特定されると、その後の処理は図２８及び図３０に示すステップS９１からS９４と同様である。
・イベント目的区分での検索処理の作用効果
イベントを概念的に区分けするコードを定義し、利用することで、様々な切り口での検索が可能となる。

次に、本実施形態の実施例３を開示する。実施例３は、重複項目データ生成処理２２０と、重複項目データ書込処理２３０とを有する。
＜文書項目管理：重複項目データ生成＞
図３２を参照すると、実施例３の文書項目管理支援システムは、実施例１及び実施例２と同様に、サーバー１０と、データベース４０，６０とを備え、マスター４０が、イベント種別マスター４４と、様式文書マスター４８と、イベント文書関連マスター５０とを備えている。そして、テーブルが、プロジェクト・イベントテーブル６２と、プロジェクト・イベント文書テーブル６４とを備えている。

さらに、実施例３の重複項目データ生成処理２２０に特有の構成として、マスター４０が、文書項目のIDをキーとして文書項目の属性を格納する文書項目テーブル２０２と、前記様式文書のIDと前記文書項目のIDとをキーとして前記様式文書と前記文書項目との関係を格納する文書項目様式文書マスター２０４とを保持している。そして、テーブル６０として、プロジェクトのIDと前記文書項目のIDとをキーとして前記プロジェクト毎の文書項目の属性を記憶するプロジェクト文書項目テーブル２０６を保持している。文書項目様式文書マスター２０４は、例えば、属性として、要否フラグを有し、文書項目IDと文書IDとを指定すると、当該文書IDの文書に当該文書項目が含まれるか否かを特定するようにしても良い。

さらに、重複データ生成処理２２０では、前記文書項目様式文書マスター２０４が、属性として項目重複フラグ２０８を有している。文書項目様式文書マスター２０は、文書に含まれている文書項目を特定する。そして、項目重複フラグ２０８は、この文書項目が、他の文書にも含まれているか否かを識別する。この項目重複フラグ２０８は、大量の文書の大量の文書項目のうち、情報処理により串刺し的に対象としたい文書項目に限定してオンとするようにしても良い。また、項目重複フラグ２０８がオンの際に、当該重複する文書の文書IDをマスター４０として管理し、文書IDと文書項目IDとにより情報処理時に動的に生成しても良い。

そして、前記プロジェクト文書項目テーブル２０６が、属性として項目更新フラグ２１０を有している。この項目更新フラグ２１０は、複数の文書にて使用される文書項目が、複数の文書の作成に応じて、すなわち、イベントの進捗に応じて更新されているか否かを制御するためのフラグである。この項目更新フラグ２１０は、サーバー１０が情報処理によりオン、オフを制御する。

また、実施例３のサーバー１０は、プロジェクト内イベント一覧生成部２２２と、重複文書項目一覧生成部２２６と、更新文書項目データ抽出部２２８とを備えている。この生成部及び抽出部は、実施例１にて開示したイベント文書特定部１９の機能に依存するため、イベント文書特定部１９が、各生成部及び抽出部を備えるように構成しても良い。

まず、プロジェクト内イベント一覧生成部２２２は、プロジェクトが指定された際に、前記プロジェクト・イベントテーブル６２を参照して当該プロジェクトに含まれるイベントを特定し、当該イベント一覧を生成する。

図３３を参照すると、文書一覧生成部２２４は、各イベントについて、前記プロジェクト・イベント文書テーブル６２を参照して、当該イベントと当該イベントに含まれる文書との対を特定し、当該文書一覧を生成する（ステップS１２０）。文書一覧には、イベント名と、文書名とが含まれる。

次に、重複文書項目一覧生成部２２６は、前記文書項目様式文書マスター２０４を参照して、前記文書項目の前記項目重複フラグ２０８を読み出して（ステップS１２２）、当該項目重複フラグがオンの際には（ステップS１２３）、文書項目と文書との対を含む重複文書項目一覧を更新し（ステップS１２４）、ステップS１２５に進む。項目重複フラグがオフの際にもステップS１２５に進む。ステップS１２５では、同一文書の全文書項目についてステップS１２２からS１２４の処理が完了したか否かを確認し、完了していなければ、同一文書の次文書項目を特定し（ステップS１２６）、同一文書の全文書項目について処理が完了するまで繰り返す。同一文書の全文書項目について処理が完了すると、当該イベントに含まれる全ての文書について処理完了したか否かを確認し、完了していなければ、次文書を特定して（ステップS１２６）、処理を繰り返す。
この文書項目での繰り返しと、文書での繰り返しとが完了すると、当該イベントに含まれる全ての文書の全ての文書項目のうち、重複がある文書項目の一覧と、各文書項目が重複している２以上の文書（文書群）との対が重複文書項目一覧として生成される。

重複文書項目一覧が生成されると、重複更新文書項目データ抽出部２２８は、前記文書項目の内容である項目データを重複する文書から読み出して（ステップS１２７）、比較する（ステップS１２８）。重複する文書は３以上のことがあり、３以上の場合には３つの文書項目データを比較する。具体的には、更新文書項目データ抽出部２２８は、当該文書項目文書一覧を参照して、当該文書項目の前記文書を特定し、当該各文書項目の項目データを比較して一致又は不一致を判定する。例えば、文書項目文書一覧の文書を特定し、文書IDから当該文書の所在を特定し、この文書を当該所在から読み出してサーバー１０の主メモリに展開して、主メモリ上の文書項目のフィールドを特定して、当該文書項目データを読み出す。そして、文書項目文書一覧の全ての文書についても同様とし、例えば、全ての文書項目データが一致しているか否かを比較する。

この比較の情報処理の結果、前記一致の際には、当該文書項目について当該文書で項目更新フラグ２１０をオフとし（ステップS１３０）、前記不一致の場合には、当該項目更新フラグ２１０をオンとして（ステップS１３１）、当該項目データと、前記文書と、前記イベントとを含む更新文書項目データ一覧を生成する（ステップS１３２）。すなわち、更新文書項目データ抽出部２２８は、複数の文書で同一の文書項目について、個別のプロジェクトで内容が更新されている際に、当該更新されている文書項目データの一覧を生成する。

さらに、重複する全文書項目についてステップS１２７からS１３２まで完了したか否かを確認し（ステップS１３３）、完了していない際には次文書項目を指定して（ステップS１３４）、処理を完了するまで処理を繰り返す。そして、更新文書項目データの一覧を表示制御する（ステップS１４３）。

図３４に、文書項目内容一覧の一例を示す。文書の重複更新の構造は図５（A）及び図２４に示すものと同一であり、各文書は文書項目を少なくとも３つ有するとする。図示の都合上、重複のない文書項目と、重複有りで更新なしの文書項目については、文書項目１-３等の集約表示をする。文書項目１は、イベント１とイベント２とで重複して使用されているが、更新がないため、ここでは文書項目データを表示しない。文書項目２及び３も同様である。文書２の文書項目４は、イベント１，２及び３で使用され、更新されている。このため、文書項目データを表示して、どのように更新されているかの内容を伝達している。文書項目５及び６についても同様である。文書３の文書項目７は、イベント１の文書３と、イベント３の文書９で使用され、更新されるため、文書項目データを表示している。異なる文書で同一の文書項目が抽出されるのは、項目重複フラグ２０８がマスターレベルでオンとされており、ステップS１２３以降の繰り返し処理により文書項目重複文書の一覧を更新する処理による。文書６は、文書単位では重複し更新されるが、文書項目単位では、文書項目１６が重複更新であり、文書項目１７及び１８は重複なしであることが判る。
・重複項目データ生成処理の作用効果
重複項目データ生成処理では、重複文書項目一覧生成部２２６が、前記文書項目の前記項目重複フラグ２０８がオンの文書項目と文書との対を含む文書項目文書一覧を生成し、更新文書項目データ抽出部２２８が、複数の文書で同一の文書項目について、個別のプロジェクトで内容が更新されている際には、当該項目データと、前記文書と、前記イベントとを含む更新文書項目データ一覧を生成する。そして、複数のプロジェクトについて当該重複項目データ生成処理を実行すると、マスターの文書項目様式文書マスター２０４の項目重複フラグ２０８をオンとしておくだけで、プロジェクト毎に更新文書項目データの一覧を生成することができる。
このため、様式文書の所管部の担当者は、様式文書を改善し更新を発行しようとする際など、文書項目を管理するときに、実際のプロジェクトでの具体的に入力されたデータの一覧を容易に入手することができる。すなわち、様式文書が現場にてどのように使用されているかを測定することができる。
この更新文書項目データ一覧は、様式文書を改善する根拠となり、全ての文書の全ての文書項目について一度に洗い出しや改善をするのではなく、重点項目から順次見直しをする品質管理等のPDCAサイクルにあわせた管理業務を推進することができる。そして、一定程度文書項目の測定がなされ様式文書の改善が進むと、見かけ上文書単位で管理しつつ、情報処理を文書項目単位で行うことが可能となる。例えば、プロジェクト遂行者は、表計算ソフトウエアやワードプロセッシングソフトウエアを使用して文書を作成しつつ、その文書項目をXML等のデータ構造に変換し、予め定めたルールに従って、文書項目を単位としてプロジェクト関係者に情報伝達をすることができるようになる。この文書項目単位での情報処理をするには、現状の様式文書の整理や、実際の使用例等の情報収集に人手による膨大な作業負荷が生ずるが、重複項目データ生成処理を順次行うことで、通常業務を行いつつ、文書項目での管理に向けた現状の整理を行うことができる。

＜文書項目管理：重複項目データ書込＞
実施例３では、文書項目が重複する文書がある際に、既存の重複文書の文書項目のデータを、新たに作成する文書の文書項目に書き込む処理（重複項目データ書込処理）をする。この例では、特に、文書項目のIDをキーとして文書項目の属性を格納する文書項目テーブル２０２と、前記様式文書のIDと前記文書項目のIDとをキーとして、前記様式文書と前記文書項目との関係を格納する文書項目様式文書マスター２０４とを保持し、前記文書項目様式文書マスター２０４が、属性として項目重複フラグ２０８を有する。そして、前記サーバー１０が、図３２に示す重複項目データ書込処理２３０として、文書項目特定部２３２と、同一項目文書特定部２３４と、直近項目データ書込部２３６とを備える。

図３５に示すように、文書項目特定部２３２は、前記端末１ａの操作に応じて前記様式文書を配布する際に、前記文書項目様式文書マスター２０４を参照して、当該様式文書の前記文書項目を特定する（ステップS１４０）。
次に、同一項目文書特定部２３４は、項目重複フラグを読み出して（ステップS１４１）、オフの際には、次の文書項目を特定して（ステップS１４２）、S１４１に処理を戻し、オンの際には、前記プロジェクト・イベント文書テーブル６４を参照して直近のイベントと当該イベントに含まれる文書群を特定し（ステップS１４３）、前記文書項目様式文書マスター２０４を参照して当該文書群から同一文書項目を有する前記文書（同一項目文書）を特定する（ステップS１４４）。

さらに、直近項目データ書込部２３６は、当該同一文書項目を有する直近の前記イベントの前記文書の前記項目データを読み出して（ステップS１４６）、当該配布する前記文書の対応する前記文書項目に書き込む（ステップS１４７）。これを繰り返し（ステップS１４８，S１４９）、重複項目データを書き込んだ配布文書を端末１ａに送信する（ステップS１５０）。

・重複項目データ書込処理の作用効果
これにより、重複した項目がある文書の作成負荷を軽減すると共に、当該文書のチェック負担をも軽減することができる。

＜文書項目管理：文書作成時にXML化＞
図３３に示す文書項目単位の管理が進捗すると、全ての文書の全ての文書項目を明示的に抽出しておき、管理できるようになっていく。この場合、端末１ａに文書を表示しつつ、データの送受信や、受信した個別のデータの処理については、文書単位とする必要がなくなる。出願人の見積システムで実現しているが、端末１ａにて表計算ソフトのファイルとして登録すると、個別の文書項目を抽出して予め定義された構造（例えば、マークアップランゲージの文書型定義）でのXMLファイルを送信し、受信側では予め定められたルールに従ってXMLファイルの文書項目を情報処理上利用可能である。このように、プロジェクトの管理に関する文書についても、文書項目単位で管理し、XML化することができる。
・XML化処理の作用効果
XML化により、重複作業の低減を推進すると、作成、チェック及び承認に関して、更新されるべきデータ項目に対する作業に集中することができるようになる。また、ほぼ同種類の文書を複数の部門に報告する業務手順についても、XML化により、１つの文書作成により各部門が必要なデータ項目に切り分けて再構築し、関連部門全体へのより素早い報告が可能となる。また、XML化しても、使用予定については文書単位で管理し、この文書の所在を抽象化しているため、XMLのデータ項目の集合から必要時に動的に文書ファイルを生成することもできる。

本発明の一実施形態の構成例を示すブロック図である。（実施例１） 本発明の一実施形態の構成例を示すユースケース図である。 本実施形態でのシステム構成の概念図である。 本実施形態でのイベントと文書との交差関係を示す説明図である。 図５（A）は異なるイベントで同一又は異なるの様式文書を重複して使用する例を示す説明図で、図５（B）は同一のイベントで同一又は異なる様式文書を使用する例を示す説明図である。 文書の交差関係に基づいた書類リストの一例を示す説明図である。 イベントと文書の関係例を示す説明図である。 本実施形態でのマスターの構成例を示す簡易ER図である。 本実施形態でのテーブルの構成例を示す簡易ER図である。 マスターの登録処理の一例を示す説明図である。 様式文書を登録するためのドキュメント設定画面の一例を示す説明図である。 図１２（A）はイベントランク管理画面の一例を示す説明図であり、図１２（B）はイベント種別設定画面の一例を示す説明図である。 イベント種別に様式文書を割り当てるイベント種別文書設定画面の一例を示す図である。 イベントグループの一例を示す説明図である。 イベントランク管理画面の一例を示す説明図である。 プロジェクト開設処理の一例を示すフローチャートである。 イベントグループセットからプロジェクトに割り当てるイベントを編集するイベントランク設定画面の一例を示す説明図である。 プロジェクトの表示処理の一例を示すフローチャートである。 図１９（A）はプロジェクト・イベントの一覧画面の一例を示す図で、図１９（B）はイベント一覧画面の一例を示す図である。 プロジェクトでの使用予定の準備文書と作成文書を一覧表示するイベント文書一覧画面の一例を示す説明図である。 イベント文書一覧画面にて集約処理の結果と使用予定とを表示する一例を示す説明図である。 イベント文書一覧画面にて様式文書の所在等を表示する一例を示す説明図である。 記録台帳の生成処理の一例を示すフローチャートである。 使用予定及び重複表示を含む記録台帳の一例を示す説明図である。 本発明の一実施形態の一例を示すブロック図である（実施例２） イベント名によるプロジェクトの検索処理の一例を示すフローチャートである。 イベント名によるプロジェクトの検索結果の一例を示す説明図である。 文書名によるプロジェクトの検索処理の一例を示すフローチャートである。 未作成書類等の一覧表示の一例を示す説明図である。 適用技術をキーとした検索処理の一例を示すフローチャートである。 イベント目的区分での検索処理の一例を示すフローチャートである。 本発明の一実施形態の一例を示すブロック図である（実施例３） 項目更新データ一覧の生成処理の一例を示すフローチャートである。 文書項目データ一覧の一例を示す説明図である。 重複する配布文書に項目データを書き込む処理の一例を示すフローチャートである。

符号の説明

１ａ，２ａ，３ａ 端末
１０ サーバー
１２ プロジェクト開設部
１３ 様式文書管理部
１５ イベント種別管理部
１７ イベントグループ処理
１８ イベント日付管理部
２２ 作業予定管理部
２４ 集約ルール管理部
２６ 集約処理部
２８ 個別文書管理部
３０ 記録台帳生成部
４０ マスター
４４ イベント種別マスター
４５ イベントグループマスター
４８ 様式文書マスター
５０ イベント文書関連マスター
５３ 使用区分
５８ 様式文書項目マスター
６０ テーブル
６１ プロジェクトテーブル
６２ プロジェクト・イベントテーブル
６４ プロジェクト・イベント文書テーブル

Claims (2)

1. 複数の端末とネットワークを介して接続され当該端末とデータを送受信するサーバーと、前記端末から送信されるデータを格納すると共に前記端末からの要求に応じたデータを検索し前記サーバーに返すデータベースとを備え、
   前記データベースが、
   予めデータを登録しておくマスターとして、
   イベント種別コードをキーとして所定のプロジェクトに割り当てられるイベント種別の属性を格納するイベント種別マスターと、様式文書IDをキーとして各プロジェクトで使用する様式文書の属性を格納する様式文書マスターと、前記イベント種別コード及び前記様式文書IDをキーとして前記イベントと前記様式文書との関係の属性を格納するイベント文書関連マスターと、を保持すると共に、
   個別の前記プロジェクトの開設時及び開設後に送受信するデータを格納するテーブルとして、
   プロジェクトIDをキーとして前記プロジェクトの属性を格納するプロジェクトテーブルと、前記プロジェクトID及び前記イベント種別コードをキーとして当該プロジェクトに割り当てられたイベントの属性を格納するプロジェクト・イベントテーブルとを保持し、
   前記イベント文書関連マスターが、前記属性として、各イベントに含まれる様式文書IDを有すると共に、当該様式文書について、当該イベントの実施までに準備をする準備文書と、当該イベントの実施後に作成をする作成文書との区分を管理する使用区分を有し、
   前記プロジェクト・イベントテーブルが、前記属性として、前記割り当てられたイベントの予定及び実施のスケジュールを有し、
   前記サーバーが、
   前記端末の操作に応じて前記個別のプロジェクトを開設する際に、前記プロジェクトの属性の入力を促して前記プロジェクト・テーブルに格納すると共に、当該プロジェクトへの前記イベント種別の割り当て操作を促して割り当てられたイベント種別をイベントとして前記プロジェクト・イベントテーブルに格納するプロジェクト開設部と、
   前記プロジェクトが開設された際に、前記端末に当該プロジェクトのイベントの一覧及びスケジュールを表示して、当該各イベントの前記スケジュールの確認又は入力を促し、当該確認又は入力される前記各イベントのスケジュールを前記プロジェクト・イベントテーブルに格納するイベント日付管理部と、
   前記端末から前記プロジェクトの表示が要求された際に、前記当該プロジェクトに含まれるイベントの一覧及びスケジュールを表示制御すると共に、当該各イベントの表示に際して、当該イベントに含まれる前記様式文書を前記使用区分に応じて前記準備文書と前記作成文書とに区分けして表示制御することで、当該スケジュールに応じて、当該様式文書を様式とする関連文書の準備及び作成を促す作業予定管理部と、を備え、
   前記データベースが、前記複数のイベント種別のセットをイベントグループとして識別するイベントグループコードと、当該イベントグループでの唯一のセットを特定するイベントグループセットコードとをキーとして、当該イベントグループセットの属性を格納するイベントグループマスターを保持し、
   当該イベントグループマスターが、前記イベントグループセットの属性として、当該イベントグループでのイベント種別のイベントランクを特定するイベントランク初期値を有し、
   前記サーバーの前記プロジェクト開設部が、前記プロジェクトの開設に際して、前記イベントグループが指定された際に、前記イベントグループセットコードの入力を促して、イベントグループセットを特定し、当該イベントグループセットでの各イベント種別のイベントランクを前記初期値として当該イベントグループセットを案内する開設支援処理を備えた、
   ことを特徴とする作成文書ナビゲーションシステム。
2. 前記様式文書マスターが、前記様式文書として、当該関連文書の様式を特定しない個別様式文書を有し、
   前記データベースが、前記テーブルとして、プロジェクトIDと、イベント種別IDに応じたイベントIDと、様式文書IDに応じた個別文書IDとをキーとして特定のプロジェクトに特定のイベントで使用される個別文書の属性を格納するプロジェクト・イベント文書テーブルを有し、
   前記サーバーが、
   前記端末の操作に応じて前記プロジェクトを表示する際に、当該プロジェクトの各イベントで前記個別様式文書に応じた個別文書の使用予定の登録操作を促すと共に、当該端末の操作に応じて当該個別文書が属する前記イベントと前記使用予定の文書タイトルとが入力された際には、当該使用予定の前記個別文書の前記文書タイトルを前記プロジェクト・イベント文書テーブルに追加する個別文書管理部を備えた、
   ことを特徴とする請求項１記載の作成文書ナビゲーションシステム。

Images