プロセス情報管理装置および方法およびプロセス情報管理プログラムを記録した記憶媒体
【課題】 開発業務や日常業務のプロセスを定義および関連する各種情報を管理するプロセス情報管理装置において、属性を持った意味のあるまとまりであるタスクのくくりを維持しながら、様々なタスクの制御フローの記述や変更を、ＧＵＩを使用してインタラクティブに行なうことが難しい、という課題があった。
【解決手段】 属性を持ったタスク、属性を持ったタスクグループ、タスク順序、を定義する手段に加え、タスクグループを越えたタスク順序を定義する仕組み、処理を優先するタスク順序を定義する仕組み、タスクグループの展開・縮小表示を行なう仕組み、他の業務プロセスを参照する仕組み、を提供することによって、上記課題を解決する。
【解決手段】 属性を持ったタスク、属性を持ったタスクグループ、タスク順序、を定義する手段に加え、タスクグループを越えたタスク順序を定義する仕組み、処理を優先するタスク順序を定義する仕組み、タスクグループの展開・縮小表示を行なう仕組み、他の業務プロセスを参照する仕組み、を提供することによって、上記課題を解決する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、開発業務や日常業務のプロセスを定義し、定義された業務プロセスと関連する各種情報を管理する装置および方法に関する。
【背景技術】
【０００２】
ＰＭＢＯＫ等のプロジェクト管理の方法論においては、プロジェクトで実施すべき全ての細分化された作業（タスク）の一覧をＷＢＳ（ワーク・ブレークダウン・ストラクチャ）と呼ばれる階層構造を持った一覧表で管理し、これに従ってプロジェクトを遂行することが推奨されている。
【０００３】
また、ＷＢＳとガントチャートをベースにして、プロジェクトのタスク、スケジュール、リソースを統合的に管理するソフトウェアとしては、米国マイクロソフト社のソフトウェア「Ｍｉｃｒｏｓｏｆｔ Ｐｒｏｊｅｃｔ（ＭＳ Ｐｒｏｊｅｃｔ）」がよく知られている。（「マイクロソフト」「Ｍｉｃｒｏｓｏｆｔ」は登録商標）
一方、ソフトウェアの処理フローや業務フローを記述する方法としては、フローチャートやＵＭＬのアクティビティ図などが使用可能である。ここで言う「フロー」とは、処理の順序のことである。
【０００４】
ＭＳ Ｐｒｏｊｅｃｔを使用すれば、あるタスクの前に行なうべきタスク（先行タスク）、あるタスクの後に行なうべきタスク（後続タスク）を定義することが可能である。さらに、先行タスクが完了する前に後続タスクに着手する設定（リードタイムの設定）や、先行タスクの完了後に一定の待ち時間を設けて後続タスクに着手する設定（ラグタイムの設定）、も可能である。
【０００５】
また、アクティビティ図を使用すれば、後続処理を条件（ガード条件）によって複数の処理に分岐させる設定（分岐処理）や、いったん分岐した処理を元の１本の処理に戻す設定（合流処理）が可能である。さらに、同期バーを使用することで、並行して処理に着手できる設定（並行処理）、複数の処理が全て完了しないと後続の処理に移れない設定（待機処理）、も可能である。
【０００６】
アクティビティ図では、入れ子構造の表記をすることによって、フローのある部分の処理を詳細化することができ、同様にＷＢＳでは、ツリーの親子関係によって、処理の詳細化を表現することができる。
【０００７】
特許文献１では、フロー制御の記述をグラフィカル・ユーザ・インターフェイス（ＧＵＩ）を利用して、インタラクティブに行ない、見やすくレイアウトする技術が開示されている。
【０００８】
特許文献２では、タスクを実施する際に、タスクを実施する際に必要なドキュメント、タスクの成果物、参照すべき画像ファイルなどの関連オブジェクトを、タスクにひも付けて管理する技術が開示されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００５−０８４７２５号公報
【特許文献２】特開２００６−１０７１４１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
さて、実際に開発業務や日常業務のプロセスを定義する際には、開発フェーズや業務担当部門ごとに、その範囲内でタスク群を抽出し、それらをひとくくりにしてグループ化したい場合がある。さらに、タスクやタスクをひとくくりにグループ化したもの（タスクグループと呼ぶ）に対して、それぞれ一意の属性を付加することによって、ある開発フェーズで実施すべきタスクやドキュメント等のタスク関連オブジェクトを明確にする、あるいは、ある担当部門が管理すべきタスクやタスク関連オブジェクトを明確にする、ということを実現したい場合がある。しかし一方では同時に、タスクグループの例である、開発フェーズや業務担当部門を越えて、先行可能なタスク、待機すべきタスク、というものも存在する。
【００１１】
しかしながら、上記従来の技術例では、複数のタスクをひとくくりにしてグループ化する場合、上位のタスクから下位のタスク群を作成しこれをグループ化するか（タスクの詳細化）、あるいは下位のタスク群をグループ化して上位のタスクを定義するか（タスクの一般化）、のどちらかの用途であった。または、タスクグループに属性が設定されていても、タスクグループ内のタスクフローの制御に関しては、上記のタスクの詳細化、あるいはタスクの一般化以外の指定はできなかった。
【００１２】
すなわち、同一のタスクグループ内でのタスクフローは、開始タスクおよび終了タスクが一意に固定されており、それを変更したり、タスクグループを越えて先行処理や待機処理を記述することはできない、という課題があった。
【００１３】
本発明では、属性を持った意味のあるまとまりであるタスクのくくり（タスクグループ）を維持しながらも、タスクフローの制御をＧＵＩ上でインタラクティブに変更することを可能にして、業務プロセス定義、および業務プロセスに関わる各種情報の管理を行なうユーザの利便性を向上させる装置を提供することを目的としている。
【課題を解決するための手段】
【００１４】
前述の課題を解決するため、本発明のプロセス情報管理装置は、タスク定義手段と、タスク属性定義手段と、タスクグループ定義手段と、タスクグループ属性定義手段と、タスク順序定義手段と、業務プロセステンプレート保存手段と、タスクグループ表示切換手段と、参照業務プロセステンプレート定義手段と、を設けた。
【００１５】
請求項１に記載した発明により、タスク定義手段は、特定の業務プロセスを細分化した複数のタスクを定義し、描画オブジェクトとして表示し、タスク属性定義手段は、タスクに関連する複数の属性情報を定義し、タスクグループ定義手段は、複数のタスクを分類および階層化し、描画オブジェクトとして表示し、タスクグループ属性定義手段は、タスクグループに関連する複数の属性情報を定義し、該属性情報は該タスクグループに含まれる全てのタスクに共通の属性とし、タスク順序定義手段は、第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義し、接続を示すコネクタを描画オブジェクトとして表示し、業務プロセステンプレート保存手段は、作成された一連の手順を該業務プロセスのテンプレートとして保存する。
【００１６】
請求項２に記載した発明により、タスク順序定義手段は、互いに異なるタスクグループに所属する、第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義する。
【００１７】
請求項３に記載した発明により、タスクグループ表示切換手段は、タスクグループ内に存在するタスクおよびタスクグループを示す描画オブジェクトを画面上に表示するか（展開表示）、表示しないか（縮小表示）を切り換え、かつ、タスク順序定義手段で定義されたコネクタが該タスクグループに接続する場合に該コネクタの表示状態を切り換える。
【００１８】
請求項４に記載した発明により、参照業務プロセステンプレート定義手段は、第１の業務プロセステンプレート上で、第２の業務プロセステンプレートを参照として定義し、描画オブジェクトとして表示し、タスク順序定義手段は、前記参照業務プロセステンプレートとのタスク順序を定義する。
【００１９】
請求項５に記載した発明により、タスク順序定義手段は、タスク、タスクグループ、参照業務プロセステンプレート、の間に定義される複数のタスク順序のうち、特定のタスク順序の定義を優先して判断する。
【００２０】
請求項６に記載した発明により、前述の課題を解決する、プロセス情報管理システムのデータ処理方法を提供する。
【００２１】
請求項７に記載した発明により、前述の課題を解決する、プロセス情報管理システムのデータ処理方法をコンピュータに機能させるためのプログラムを記録したコンピュータ読み取り可能な記憶媒体を提供する。
【発明の効果】
【００２２】
本発明により、属性を持った意味のあるまとまりであるタスクのくくり（タスクグループ）を維持しながらも、タスクフローの制御をＧＵＩ上でインタラクティブに変更することを可能にして、業務プロセス定義、および業務プロセスに関わる各種情報の管理を行なうユーザの利便性を向上させるという効果がある。
【００２３】
本発明の請求項１にかかる装置では、属性を持ったタスク、属性を持ったタスクグループ、タスクを実行する順序、をＧＵＩ上でインタラクティブに定義し、業務プロセステンプレートとして保存することができる。
【００２４】
本発明の請求項２にかかる装置では、入れ子構造や並列構造になったタスクグループを越えた制御フロー（特殊タスク手順）を定義することができる。
【００２５】
本発明の請求項３にかかる装置では、ＧＵＩ上でタスクグループを展開または縮小表示することができ、かつ、縮小表示状態でも、タスクグループ内部の制御フローを表現することができる。
【００２６】
本発明の請求項４にかかる装置では、他の業務プロセステンプレートを参照して利用することができる。
【００２７】
本発明の請求項５にかかる装置では、特定のタスク順序の定義を優先させる制御フロー（優先タスク手順）を定義することができる。
【図面の簡単な説明】
【００２８】
【図１】本発明の第１実施形態にかかるプロセス情報管理装置のハードウェア構成を示すブロック図である。
【図２】本発明の実施形態にかかるプロセス情報管理装置で業務プロセスを作成する手順を示すフローチャートである。
【図３】本実施例における標準的な業務プロセステンプレートを定義した例である。
【図４】フォルダを越えるタスク順序を定義した例である。
【図５】フォルダを越えるタスクの移動を実行した例である。
【図６】フォルダを越えるタスク順序を定義した双方のフォルダを縮小表示した場合の画面表示例である。
【図７】フォルダを越えるタスク順序を定義した一方のフォルダを縮小表示した場合の画面表示例である。
【図８】ある業務プロセスから他の業務プロセスを参照した場合の例である。
【図９】複数のタスク手順が定義されている場合の優先タスク手順を定義した例である。
【図１０】本実施例の図１０の制御フローを示すアクティビティ図である。
【図１１】タスク属性入力画面の例である。
【図１２】本実施例の図３の制御フローを示すアクティビティ図である。
【図１３】本実施例の図４の制御フローを示すアクティビティ図である。
【図１４】本実施例の図９における制御フローを示すアクティビティ図である。
【図１５】本実施例の図１０の制御フローを示すアクティビティ図である。
【図１６】本実施例の図１７における制御フローを示すアクティビティ図である。
【図１７】本実施例の図９におけるコネクタ（９１０）が通常のタスク手順（通常タスク手順と呼ぶ）を示すコネクタである場合の例である。
【発明を実施するための形態】
【００２９】
以下、本発明にかかる一実施形態のプロセス情報管理装置を図面を参照して詳細に説明する。
【００３０】
［第１実施形態］
［システム構成と動作手順］
図１は、本発明の第１実施形態にかかるプロセス情報管理装置のハードウェア構成を示すブロック図である。
【００３１】
本発明の実施形態にかかるプロセス情報管理装置（以下、本装置）のサーバコンピュータ（以下、サーバ）および各クライアントコンピュータ（以下、クライアント）は、同様のハードウェア構成である。また、サーバとクライアントは物理的に１つのハードウェアであってもよい。
【００３２】
図１において、１１はマウスやキーボードなどの入力装置、１２はＲＯＭ、１３はハードディスクドライブ（ＨＤＤ）、ＦＤドライブ（ＦＤＤ）、ＣＤドライブ、ＤＶＤドライブなどの記憶装置、１４はＲＡＭ、１５はＣＰＵ、１６はＬＣＤやＣＲＴなどの出力装置、１７はネットワークＩ／Ｆ、１８はシステムバス、１９はＬＡＮである。
【００３３】
サーバと各クライアントは、ネットワークＩ／Ｆ１７を介してＬＡＮ１９に接続されており、サーバ上で動作している本装置と必要なデータのやり取りを行う。
【００３４】
本装置のプログラムおよび必要なデータは、システムが動作するサーバ上の記憶装置１３に格納されており、ＲＡＭ１４に取り込まれる。プログラムおよびデータがＲＯＭ１２に格納されている場合は、ＲＯＭ１２からＲＡＭ１４に読み込まれる。ＣＰＵ１５は、ＲＡＭ１４にアクセスしてプログラムを動作させる。
【００３５】
ユーザは、クライアントの出力装置１６に表示された画面の指示に従い、クライアントの入力装置１１を使用して、必要な情報を入力または指示する。入力データは、クライアントのＣＰＵ１５に伝えられ、ネットワークＩ／Ｆ１７とＬＡＮ１９を介してサーバに送信される。サーバで処理された結果は、ネットワークＩ／Ｆ１７とＬＡＮ１９を介して、再びクライアントに送信され、クライアントの出力装置１６の画面に表示される。
【００３６】
［標準的な業務プロセスの作成］
図２は、本発明の実施形態にかかるプロセス情報管理装置で業務プロセスを作成する手順を示すフローチャートである。
【００３７】
本実施例では、開発業務や日常業務の一連の流れを定義したもの、を「業務プロセス」または単に「プロセス」と呼ぶことにする。また、業務プロセスを雛型として保存したものを特に「業務プロセステンプレート」と呼ぶ。
【００３８】
図２のフローチャートにしたがって、これより図３と図１１を参照しながら、本実施例における標準的な業務プロセステンプレート作成する手順を詳細に説明する。
【００３９】
まず、ユーザは業務プロセスの名称を決め、業務プロセスを作成する（Ｓ２０１）。マウスなどの入力装置１１（以下、単にマウス）でメニューから「業務プロセス新規作成」をクリックすることなどで、業務プロセスが新規に作成されると、出力装置１６には「プロセス１（３０１）」の編集画面が表示される。
【００４０】
次に、ユーザは、その業務プロセスの中で実施しなければならないタスク（作業）を洗い出した上で、いくつでもタスクを定義する（Ｓ２０２）。タスクを示す描画オブジェクトの形状（例えば矩形）は、あらかじめＲＡＭ１４に格納されており、出力装置１６上に雛型の描画オブジェクトとして表示されている。ユーザは、マウスでタスクを示す雛型の描画オブジェクトを「プロセス１（３０１）」上にドラッグするなどの方法で、タスクを配置して行く。この時点では、タスクの詳細情報は、まだ完全に入力されていなくてもよい。
【００４１】
例えば、タスクのタイトルを「タスク０１」と、キーボードなどの入力装置１１（以下、単にキーボード）で入力し、配置場所をマウスで指示することにより「タスク０１（３１０）」が作成される。同様の操作で、「タスク０２（３１１）」から「タスク０８（３１２）」までのタスクを「プロセス１（３０１）」上に定義、配置する。なお、タスクを作成する順番は、タスクを実行する順序（タスク順序と呼ぶ）とは無関係に定義して行くことができる。
【００４２】
次に、ユーザは、定義済のタスクに対してその属性を定義することができる（Ｓ２０３）。定義済のタスクを示す描画オブジェクトをマウスでダブルクリックするなどの方法で指定すると、図１１に示すタスク属性入力画面（１１０１）が表示される。タスク属性入力画面（１１０１）には、タスクの詳細な内容を記述した文章（１１０３）、タスクの内容を示唆するキーワード（１１０４）、タスクの日程（開始予定日や終了予定日など）（１１０５）、その他の属性（１１０６）を記述することができる。
【００４３】
また、それぞれのタスクに、複数のナレッジを紐付けることもできる。ここで言うナレッジとは、そのタスクに関係のある設計書やメモ書きなどのファイル、図面や画像ファイル、関連Ｗｅｂページへのリンク情報、関連ファイルの格納フォルダへのリンク情報などを総称したものである。このようにして、各タスクの内容を詳細化して行く。なお、タスク属性を入力する順番は、タスク順序やタスクを作成した順番とは無関係に定義して行くことができる。
【００４４】
次に、タスクのグルーピング（ひとくくりにしてグループ化すること）を行う（Ｓ２０４）。グルーピングは「フォルダ」と呼ばれるものを用いて行う。本実施例では、プロセス内で、複数のタスクをひとくくりにしたものを「フォルダ」または「タスクグループ」と定義する。フォルダは、タスクとフォルダを内部に包含することができる。また、フォルダに所属しないタスクも存在可能である。
【００４５】
「プロセス１（３０１）」を例に取って操作を説明する。まず「フォルダ１１（３０４）」を作成し、その中に「タスク０１（３１０）」と「タスク０２（３１１）」を移動させる。移動は、マウスを使ってタスクをドラッグ・アンド・ドロップすることなどで行なえる。フォルダの作成方法は、タスクの場合と同様で、フォルダを示す描画オブジェクトの形状（例えば角丸矩形）は、あらかじめＲＡＭ１４に格納されており、出力装置１６上に雛型の描画オブジェクトとして表示されている。ユーザは、マウスでフォルダを示す雛型の描画オブジェクトを「プロセス１（３０１）」上にドラッグするなどの方法で、フォルダを配置して行く。この時点では、フォルダの詳細情報は、まだ完全に入力されていなくてもよい。
【００４６】
同様に「フォルダ２１（３０６）」を作成し、その中に「タスク０３（３１３）」と「タスク０４（３１４）」を移動させる。また「フォルダ１２（３０５）」を作成し、その中に「タスク０８（３１２）」を移動させる。また「フォルダ２２（３０７）」を作成し、その中に「タスク０５（３１５）」と「タスク０６（３１６）」を移動させる。また「フォルダ１（３０２）」を作成し、その中に「タスク０１」と「タスク０２」を含んだ「フォルダ１１（３０４）」と、「タスク０８」を含んだ「フォルダ１２（３０５）」を移動させる。また「フォルダ２（３０３）」を作成し、その中に「タスク０３」と「タスク０４」を含んだ「フォルダ２１（３０６）」と、「タスク０５」と「タスク０６」を含んだ「フォルダ２２（３０７）」を移動させる。
【００４７】
なお、タスクのグルーピングを行う順番は決められているわけではなく、ユーザはプロセス全体を眺めてグルーピングした方がよいと判断した部分から、フォルダにまとめるという操作を行なうことができる。例えば、先ほどの例では「フォルダ１（３０２）」から作成し、タスク群を内部に入れていったが、「フォルダ１２（３０５）」から先に、グルーピングすることも可能である。あるいは、「フォルダ１（３０２）」に「フォルダ１１（３０４）」を入れる操作を先に行なうことも可能である。また、フォルダを作成する順番は、フォルダ間のタスク群を実行する順序とは無関係に定義して行くことができる。
【００４８】
次に、ユーザは、定義済のフォルダに対してその属性を定義することができる（Ｓ２０５）。定義済のフォルダを示す描画オブジェクトをマウスでダブルクリックするなどの方法で指定すると、図１１のタスク属性入力画面と同様の、フォルダ属性入力画面が表示される。フォルダ属性入力画面には、フォルダの詳細な内容を記述した文章、フォルダの内容を示唆するキーワード、フォルダの日程（開始予定日や終了予定日など）、その他の属性を記述することができる。また、タスクと同様、それぞれのフォルダに、複数のナレッジを紐付けることもできる。
【００４９】
各タスクはタスク属性を複数持つことができるが、タスクは上位のフォルダが持つ複数のフォルダ属性を継承することもできる。つまり、タスクが１つのフォルダにくくられた時、それらのタスクは、自タスクが持つタスク属性群、自タスクの上位フォルダ群が持つタスクフォルダ属性群を全て参照することができる。
【００５０】
次に、タスクを実行する順序を決めて行く（Ｓ２０６）。本実施例では、タスクとタスクだけではなく、タスクとフォルダ、フォルダとフォルダ、およびこれらと、後述する参照業務プロセステンプレート、の間に定義される実行順序の依存関係を総称して「タスク順序」と呼ぶことにする。タスク順序を定義すると、該当する２つの描画オブジェクト間に、タスク順序を示す矢印付きの線（コネクタと呼ぶ）が表示される。タスク順序の定義を行なう操作は、例えば、「タスク０１（３１０」をシフトキーを押しながらマウスでクリックし、次に「タスク０２（３１１）」をシフトキーを押しながらマウスでクリックすれば、コネクタ（３２０）が、作成される。
【００５１】
「プロセス１（３０１）」を例に取って操作を説明する。まず「フォルダ１１（３０４）」内の「タスク０１（３１０）」から「タスク０２（３１１）」へコネクタ（３２０）を引く。次に「フォルダ２１（３０６）」内の「タスク０３（３１３）」から「タスク０４（３１４）」へコネクタ（３２２）を引く。また「フォルダ２２（３０７）」内の「タスク０５（３１５）」から「タスク０６（３１６）」へコネクタ（３２３）を引く。また「フォルダ２（３０３）」から「プロセス１（３０１）」直下の「タスク０７（３１７）」にコネクタ（３２５）を引く。また「フォルダ１（３０２）」から「フォルダ２（３０３）」へコネクタ（３２１）を引く。
【００５２】
これらのコネクタは業務プロセスの順に従って、例えば業務プロセス内で最初に着手すべきタスクから順番に引いて行く必要はなく、特定のタスク間もしくはフォルダ間もしくはタスクとフォルダ間の前後関係が確定した時点でその部分からコネクタを引くことができる。もちろん、業務プロセスが変わるたびに、既存のコネクタの接続タスクを変更すること、既存のコネクタを削除することができる。
【００５３】
コネクタはそれ自身が、先行タスクと後続タスクの情報を格納する領域を持っている。例えば、コネクタ（３２０）には先行タスクとして「タスク０１（３１０）」の情報、後続タスクとして「タスク０２（３１１）」の情報が、コネクタ（３２５）には先行タスクとして「フォルダ２（３０３）」の情報、後続タスクとして「タスク０７（３１７）」の情報が、それぞれ格納されている。
【００５４】
ユーザは、Ｓ２０２〜Ｓ２０６のステップを繰り返しながら、業務プロセスを作成していく。なお、Ｓ２０２〜Ｓ２０６の各ステップは順不同であり、ユーザはどのような順番で処理を行ってもよい。例えば、先にフォルダを作成してからその中にタスクを作成してもよいし、コネクタが付いた複数のタスク群をフォルダでくくる操作をしてもよい。また、同一のステップの処理を何度行っても良い。本装置のグラフィカル・ユーザ・インターフェイス（ＧＵＩ）上で、ユーザがこのようにインタラクティブに、タスク、フォルダ、およびコネクタを配置して行くことにより、思考を妨げられることなく、円滑に思い通りの業務プロセスを作成することができる。
【００５５】
最後にユーザは、定義した業務プロセスを記憶装置１３に保存する（Ｓ１０６）。ユーザは、マウスでメニューから「業務プロセス保存」をクリックすることなどで、作成完了または作成途中の業務プロセスを、業務プロセスの雛型である「業務プロセステンプレート」として保存する。作成途中の業務プロセスを再編集する場合には、Ｓ２０１において、新規に業務プロセスを作成する代わりに、業務プロセステンプレートを記憶装置から呼び出せばよい。
【００５６】
［タスク処理フローの説明］
本装置で適用可能なタスク処理フローとその表記ルールについて、以下に説明する。
【００５７】
図３の例では、「タスク０１（３１０）」から「タスク０２（３１１）」に向けてコネクタ（３２０）が引かれている。これは、「タスク０１（３１０）」が完了してから、次の「タスク０２（３１１）」に着手できる、という意味である。（先行タスクと後続タスクの指定）
図１０の例では、「タスク０１（１０１０）」から「タスク０２（１０１１）」と「タスク０３（１０１２）」に向けてコネクタが引かれている。これは、「タスク０１（１０１０）」が完了した後、次の「タスク０２（１０１１）」と「タスク０３（１０１２）」を同時並行で着手できる、という意味である。一般に、あるタスクの後続タスクとして複数のタスクが指定されている場合には、先行タスクが完了したら、後続タスク群は同時並行で着手できる、という意味である。（後続タスクの並行処理指定）
また図１０の例では、「タスク００（１０１５）」が完了すると、「フォルダ１（１００２）」内のタスクに着手できるが、「フォルダ１（１００２）」の直下にあり、先行タスクがないタスクまたはフォルダ、すなわち、「タスク０１（１０１０）」、「フォルダ１１（１００３）」内の先頭タスク、「フォルダ１２（１００４）」内の先頭タスク、が同時並行で着手できる。このように、後続タスクがフォルダである場合には、「タスク００（１０１５）」から、「タスク０１（１０１０）」、「フォルダ１１（１００３）」、「フォルダ１２（１００４）」のそれぞれにコネクタを引くことなく、直接「フォルダ１（１００２）」にコネクタを引くことによって、並行処理を表現できる。（先頭タスクの並行処理指定）
また図３の例では、「フォルダ１（３０２）」の内部は、サブフォルダ（入れ子になった子のフォルダ）も含め、「フォルダ１１（３０４）」、「フォルダ１２（３０５）」、「タスク０１（３１０）」、「タスク０２（３１１）」、「タスク０８（３１２）」で構成されている。この場合、後続タスクである「フォルダ２（３０３）」に着手できるのは、「フォルダ１（３０２）」のタスクが全て完了してから、ということになる。
【００５８】
また図３の例では、「タスク０４（３１４）」の先行タスクとして「タスク０３（３１３）」と「タスク０５（３１５）」が指定されている。これは「タスク０３（３１３）」と「タスク０５（３１５）」の両方が完了しないと、「タスク０４（３１４）」に着手することができない、という意味である。あるタスクの先行タスクとして複数のタスクが指定されている場合には、先行タスクの全てが完了するまで、後続タスクには着手できない、という意味である。（待機処理指定）
以上説明したタスク処理フロー表記ルールを適用すると、図３の例では、「フォルダ１（３０２）」の処理が完了したら「フォルダ２（３０３）」の処理に着手できることになる。「フォルダ２（３０３）」の先頭タスクは「フォルダ２１（３０６）」と「フォルダ２２（３０７）」で、この二者は同時に着手できる。また、各フォルダ内の先頭タスクは、それぞれ「タスク０３（３１３）」と「タスク０５（３１５）」であることから、「タスク０３（３１３）」と「タスク０５（３１５）」が同時並行で着手できる、ということになる。
【００５９】
先ほど説明した「フォルダ１（３０２）」内の処理と同様に、「タスク０３（３１３）」と「タスク０４（３１４）」が完了することで「フォルダ２１（３０６）」の処理が完了し、「タスク０５（３１５）」と「タスク０６（３１６）」が完了することで「フォルダ２２（３０７）」の処理が完了する。そして「フォルダ２１（３０６）」と「フォルダ２２（３０７）」の処理が完了することで、「フォルダ２（３０３）」の処理が完了することになる。
【００６０】
［ＵＭＬアクティビティ図の説明］
本装置の制御フローの記述は、従来技術であるＵＭＬアクティビティ図（以下、単にアクティビティ図）の表現を用いても表現することができる。
【００６１】
図１２は、本実施例の図３の制御フローを示すアクティビティ図である。
【００６２】
簡単にアクティビティ図の表記について説明する。１２０１はフローの開始、１２０２はフローの終了を意味する。また、１２０５などタスクとタスクを繋ぐ矢印はタスクの実行順序を示す。例えば、「タスク０１（１２１０）」が「タスク０２（１２１１）」の先行タスクであるとき、１２０５の矢印を引く。
【００６３】
１２０３と１２０４は「同期バー」と呼ばれるものである。１２０３の同期バーは並行処理を意味する。この例では、同期バー（１２０３）に後続する「タスク０１（１２１０）」と「タスク０８（１２１２）」が同時に並行して着手できることを示している。また、１２０４の同期バーは待機処理を意味する。この例では、同期バー（１２０４）の後続する「タスク０７（１２１７）」は、同期バー（１２０４）に先行する「タスク０４（１２１４）」と「タスク０６（１２１６）」の両方の完了を待って着手できることを意味している。
【００６４】
図１５は、本実施例の図１０の制御フローを示すアクティビティ図である。
【００６５】
［フォルダの適用事例］
ここで図３を用いて、フォルダを開発業務プロセスに適用した事例について説明する。
【００６６】
開発業務プロセスは、多数のタスクから構成される。一般に、開発業務には、開発のマイルストーンを設定したり、開発物の完成度を高めて行く段階を定義するために「フェーズ」という概念がある。例えば、ある開発業務プロセスが、フェーズα、フェーズβ、フェーズγ、という３つのフェーズで構成されているとする。このような場合、タスク群をフェーズごとにくくって、フォルダで管理することができる。
【００６７】
例えば、フェーズαで実施すべきタスクである、「タスク０１（３１０）」、「タスク０２（３１１）」、「タスク０８（３１２）」には、「フェーズα」という共通の属性を持たせたい。そこで「フォルダ１（３０２）」を「フェーズαで実施すべきタスク群」という意味で使用し、そのフォルダ属性の１つとして「フェーズα」を付与する。同様にして、フェーズβで実施すべきタスクである、「タスク０３（３１３）」、「タスク０４（３１４）」、「タスク０５（３１５）」、「タスク０６（３１６）」を、「フォルダ２（３０３）」でくくり、そのフォルダ属性の１つとして「フェーズβ」を付与する。
【００６８】
さらに、例えば「タスク０１（３１０）」と「タスク０８（３１２）」に紐付けたナレッジファイルにも、タスク属性が持つナレッジへのリンク情報から「フェーズα」という属性を付与することも可能となる。これを実現すれば、「フェーズαで実施すべきタスク」に加えて「フェーズαのタスクで作成したナレッジファイル」という情報を特定することもできるようになる。
【００６９】
さて、開発業務には、フェーズとは独立して、その業務の「担当部門」という概念もある。例えば、ある開発業務プロセスが、フェーズα、フェーズβ、フェーズγ、という３つのフェーズで構成されており、さらに、Ａ部門とＢ部門という２つの担当部門が開発業務に携わっているとする。このような場合、タスク群をフェーズごとにくくって、フォルダで管理し、さらに、担当部門ごとのフォルダを作成することもできる。
【００７０】
例えば、フェーズαを表す「フォルダ１（３０２）」の内部で、Ａ部門が担当する「タスク０１（３１０）」および「タスク０２（３１１）」と、Ｂ部門が担当する「タスク０８（３１２）」があったとする。このような場合も、フォルダを適用することができる。すなわち、「フェーズαでＡ部門が担当するタスク群」として「フォルダ１１（３０４）」を、「フェーズαでＢ部門が担当するタスク群」として「フォルダ１２（３０５）」を作成し、フェーズを表すフォルダ属性とは別のフォルダ属性に、それぞれ「Ａ部門」、「Ｂ部門」を付与すればよい。同様に、フェーズβを表す「フォルダ２（３０３）」の内部でも、Ａ部門が担当する「タスク０３（３１３）」および「タスク０４（３１４）」をくくった「フォルダ２１（３０６）」と、Ｂ部門が担当する「タスク０５（３１５）」および「タスク０６（３１６）」をくくった「フォルダ２２（３０７）」を作成し、担当部門を表すフォルダ属性を付与すればよい。
【００７１】
このように、フォルダをうまく適用することで、担当部門とフェーズという２つの切り口から、タスク群をくくることができ、各タスクおよびタスクに紐づくナレッジに、部門を表すフォルダ属性とフェーズを表すフォルダ属性を付与することができる。これにより、例えば、「タスク０５（３１５）」は「フェーズβでＢ部門が行うタスク」であることが分かる。また、「フェーズαでＡ部門が担当するタスク」は「タスク０１（３１０）」と「タスク０２（３１１）」であることも分かる。さらに、「Ｂ部門が（フェーズαで）作成したナレッジファイル」という情報を特定することもできるようになる。
【００７２】
［フォルダを越えるタスク順序の定義］
図４は、フォルダを越えるタスク順序を定義した例である。
【００７３】
図３と図４はタスクとフォルダの配置は同じだが、図４では「タスク０１（４１０）」から「タスク０５（４１５）」へのコネクタが追加されている。本装置では、このようなフォルダ順序を越えるタスク順序の定義も可能である。
【００７４】
図４はフェーズαのタスクの１つである「タスク０１（４１０）」が完了したら、フェーズα全体の完了を待たずに、フェーズβのタスクの１つである「タスク０５（４１５）」に先行して着手することができる、という意味になる。実際の開発業務においても、このような運用を行なって、開発期間の短縮を図ることは行なわれている。ただし、あくまでも、「タスク０１（４１０）」はフェーズαの、「タスク０５（４１５）」はフェーズβのタスクである、ということに変わりはない。フォルダ属性は維持されているので、本実施例では、これを実現することが可能である。
【００７５】
図１３は、本実施例の図４の制御フローを示すアクティビティ図である。図４は図３にコネクタ（４２６）が追加されただけであるが、図１２と図１３を比較すると、アクティビティ図の表記では大きく変化することがわかる。
【００７６】
［フォルダを越えるタスクの移動］
図５は、フォルダを越えるタスクの移動を実行した例である。
【００７７】
図４と図５は、タスクとフォルダの接続関係は同じだが、「タスク０５（５１５）」の上位フォルダが異なる。これは、例えばマウスを使ってタスクをドラッグ・アンド・ドロップする方法で、図４の「タスク０５（４１５）」を、「フォルダ２２（４０７）」から「フォルダ１２（４０５）」に移動することによって実現している。
【００７８】
これを実際の開発業務に適用すると、これまで「タスク０５（４１５）」はＢ部門がフェーズβで行っていたが、このタスクは同じＢ部門がフェーズαの段階から行ったほうが、開発の効率がよいと判断された場合などが考えられる。このとき、「タスク０５（４１５）」に接続されているコネクタ（５２３）、コネクタ（５２４）、コネクタ（５２６）は、そのままの接続状態で維持されるため、タスク順序には変動はない。このように、コネクタが接続された状態のタスクやフォルダを、フォルダのくくりを越えて移動することにより、タスク順序を変えることなく、一部の属性を変更することが可能となる。図４と図５の例では、「タスク０５」が継承するフォルダ属性のうち、フェーズを表す属性が「フェーズβ」から「フェーズα」に変化した。
【００７９】
タスク順序に変動は無いため、図５の制御フローを示すアクティビティ図は図１３であり、図４のアクティビティ図と同じである。
【００８０】
［フォルダの展開・縮小表示１］
本装置の出力装置１６に表示されるＧＵＩは、フォルダの内部に存在するタスクおよびフォルダの表示と非表示を切り換えることができる。以降、前者をフォルダ展開表示、後者をフォルダ縮小表示と呼ぶ。
【００８１】
図６は、フォルダを越えるタスク順序を定義した双方のフォルダを縮小表示した場合の画面表示例である。
【００８２】
図４は、全てのフォルダ内のタスクおよびフォルダが表示されたフォルダ展開表示状態である。図４と同じプロセスで、「フォルダ１（４０２）」と「フォルダ２（４０３）」をフォルダ縮小表示に変更すると、図６の表示になる。フォルダ展開・縮小表示の操作は、例えば、展開・縮小表示状態を変更したいフォルダをマウスで選択してから、画面上の「フォルダ展開・縮小」ボタンをクリックすることなどで、実現できる。フォルダ展開表示とフォルダ縮小表示の状態は、「フォルダ展開・縮小」ボタンをクリックするたびに切り換わる。
【００８３】
フォルダ展開表示状態（図４）で、「フォルダ２（４０３）」と「タスク０７（４１７）」を繋いでいたコネクタ（４２５）は、フォルダ縮小表示状態（図６）になったときにも、「フォルダ２（６０３）」と「タスク０７（６１７）」を繋ぐコネクタ（６２５）に相当し、コネクタ形状は実線の矢印のままである。同様に、フォルダ展開表示状態（図４）の「フォルダ１（４０２）」と「フォルダ２（４０３）」を繋いでいたコネクタ（４２１）は、フォルダ縮小表示状態（図６）においても、「フォルダ１（６０２）」と「フォルダ２（６０３）」を繋ぐコネクタ（６２１）に相当し、コネクタ形状は実線の矢印のままである。
【００８４】
フォルダ展開表示状態（図４）で、フォルダを越えるタスク順序を定義した、「フォルダ１（４０２）」の中の「タスク０１（４１０）」と「フォルダ２（４０３）」の中の「タスク０５（４１５）」とを繋ぐコネクタ（４２６）は、フォルダ縮小表示状態（図６）になったときに、「フォルダ１（６０２）」と「フォルダ２（６０３）」を繋ぐコネクタ（６２６）に相当する。このようにフォルダを越えるタスク順序を定義したことを、双方のフォルダが縮小表示状態であっても識別するために、例えば、コネクタ形状を破線の矢印に変えている。フォルダ間を接続している実線のコネクタ（６２１）は、そのまま存在しているので、結果として、「フォルダ１（６０２）」と「フォルダ２（６０３）」を繋ぐコネクタは、コネクタ（６２１）とコネクタ（６２６）の２本になる。
【００８５】
タスク順序に変動は無いため、図６の制御フローを示すアクティビティ図は図１３であり、図４のアクティビティ図と同じである。
【００８６】
［フォルダの展開・縮小表示２］
図７は、図４にあるフォルダを越えるタスク順序を定義した一方のフォルダを縮小表示した場合の画面表示例である。
【００８７】
図７は、図４の「フォルダ１（４０２）」のみをフォルダ縮小表示状態にしたものである。フォルダ展開表示状態（図４）で、「フォルダ１（４０２）」と「フォルダ２（４０３）」を繋いでいたコネクタ（４２１）は、フォルダ１の縮小表示状態（図７）においても、「フォルダ１（７０２）」と「フォルダ２（７０３）」を繋ぐコネクタ（７２１）に相当し、コネクタ形状は実線の矢印のままである。
【００８８】
フォルダ展開表示状態（図４）で、「フォルダ１（４０２）」の中の「タスク０１（４１０）」と「フォルダ２（４０３）」の中の「タスク０５（４１５）」とを繋ぐコネクタ（４２６）は、フォルダ１の縮小表示状態（図７）では、「フォルダ１（７０２）」と「フォルダ２（７０３）」の中の「タスク０５（７１５）」を繋ぐコネクタ（７２６）に相当する。このようにフォルダを越えるタスク順序を定義したことを、一方のフォルダが縮小表示状態であっても識別するために、例えば、コネクタ形状を破線の矢印に変えている。
【００８９】
同様に、図４の「フォルダ２（４０３）」のみをフォルダ縮小表示状態にした場合には、図４のコネクタ（４２１）に相当するコネクタ形状は実線の矢印のまま表示され、図４のコネクタ（４２６）に相当するコネクタ形状は、縮小表示状態にした「フォルダ２」への点線の矢印で表示されることにあなる。
【００９０】
以上［フォルダの展開・縮小表示１］および［フォルダの展開・縮小表示２］の説明により、タスク順序を定義している２つのフォルダの双方または一方が縮小表示状態であっても、これらのフォルダ間でフォルダを越えるタスク順序を定義していることを、ユーザが識別することができる。
【００９１】
タスク順序に変動は無いため、図７の制御フローを示すアクティビティ図は図１３であり、図４のアクティビティ図と同じである。
【００９２】
［他の業務プロセステンプレートの参照］
図８は、ある業務プロセスから他の業務プロセスを参照した場合の例である。
【００９３】
図８では、別に作成した他の業務プロセステンプレートへの参照（参照業務プロセステンプレートと呼ぶ）を「ショートカット」という描画オブジェクトで示している。参照業務プロセステンプレートを示す描画オブジェクトの形状（例えばタスクとは枠線の色が異なる矩形）は、あらかじめＲＡＭ１４に格納されており、出力装置１６上に雛型の描画オブジェクトとして表示されている。ユーザは、マウスで参照業務プロセステンプレートを示す雛型の描画オブジェクトを「プロセス２（８０１）」上にドラッグするなどの方法で、参照業務プロセステンプレートを配置していく。
【００９４】
配置したショートカットがどの業務プロセステンプレートを参照するかは、例えば、ショートカットをマウスの右ボタンでクリックして表示されるメニューで「参照業務プロセスの選択」を選択し、さらに、表示される業務プロセスの一覧から、既に作成済の業務プロセステンプレートを選択すればよい。
【００９５】
図８の例では、「ショートカット０１（８０３）」は、「ユニットＡの設計手順」を定義した業務プロセステンプレートへのショートカットを、「ショートカット０２（８０４）」は「ユニットＢの設計手順」を定義した業務プロセステンプレートへのショートカットを、「ショートカット０３（８０５）」は「ユニットＣの設計手順」というプロセスへのショートカットを、それぞれ表している。
【００９６】
これを実際の開発業務に適用すると、ある機器の構造が機能別に複数のユニットに分かれており、それを各ユニット担当者が別々に開発する場合などがある。それぞれのユニットの設計手順は、各ユニットの開発業務ノウハウに詳しい担当者が別々の業務プロセステンプレートとして作成する。
【００９７】
例えば、業務プロセス「ユニットＡの設計手順」の作成を作成者Ａが、業務プロセス「ユニットＢの設計手順」の作成を作成者Ｂが、業務プロセス「ユニットＣの設計手順」の作成を作成者Ｃが、それぞれ担当し、全体責任者Ｄが、それぞれのユニットをまとめて機器全体の開発業務プロセスを作成する、という場合である。
【００９８】
図８の例では、ある機器を構成するユニットが、ユニットＡ、ユニットＢ、ユニットＣ、の３つだった場合、別々に作成された、ユニットＡ、ユニットＢ、ユニットＣ、の各設計手順の業務プロセステンプレートを示すショートカットを、「プロセス２（８０１）」上に配置して、これらのタスク順序を定義するだけで、機器全体の開発業務プロセスが完成する。
【００９９】
さらに、類似の機器を開発する際、すなわち、機器を構成するユニットの一部のみが異なる場合にも、業務プロセステンプレートの参照がうまく適用できる。例えば、類似の機器を構成するユニットが、ユニットＢ、ユニットＣ、ユニットＤ、の３つだった場合は、ユニットＢとユニットＣの設計手順を定義した業務プロセステンプレートは既に作成済であるので、これらについては、各設計手順の業務プロセステンプレートを示すショートカットを用い、ユニットＤの設計手順を定義した業務プロセステンプレートだけを新規に作成すればよい。
【０１００】
このように、参照業務プロセステンプレートを利用することで、同じ内容の業務プロセスを再利用することが可能となり、一部の業務プロセス（例えば、あるユニットの設計手順）を変更しても、全体の業務プロセス（例えば、ある機器全体の設計手順）に影響を与えないことも可能となる。
【０１０１】
参照業務プロセステンプレートも、先に説明したフォルダの展開・縮小表示と同様に、展開・縮小表示が可能である。業務プロセステンプレートを示すショートカット展開・縮小表示の操作は、例えば、展開・縮小表示状態を変更したいショートカットをマウスで選択してから、画面上の「フォルダ展開・縮小」ボタンをクリックすることなどで、実現すればよい。ショートカット展開表示とショートカット縮小表示の状態は、「フォルダ展開・縮小」ボタンをクリックするたびに切り換わる。
【０１０２】
［優先タスク手順の設定］
図９は、複数のタスク手順が定義されている場合の優先タスク手順を定義した例である。
【０１０３】
図１４は、本実施例の図９における制御フローを示すアクティビティ図である。
図１７は、本実施例の図９におけるコネクタ（９１０）が通常のタスク手順（通常タスク手順と呼ぶ）を示すコネクタだった場合の例である。
【０１０４】
図１６は、本実施例の図１７における制御フローを示すアクティビティ図である。
【０１０５】
図９では、「フォルダ１（９０３）」の中の「タスク０３（９０６）」から「タスク０４（９０５）」に引かれているコネクタ（９１０）が示すタスク手順が、他の、コネクタ（９１２）、コネクタ（９１１）が示すタスク手順より優先する場合の例を示している。コネクタ（９１０）が示すタスク手順を「優先タスク手順」、優先タスク手順を示す描画オブジェクトを「優先コネクタ」と呼ぶことにする。
【０１０６】
図１７は、図９において、コネクタ（９１０）が優先コネクタではなく、通常のタスク手順（通常タスク手順と呼ぶ）を示すコネクタ（通常コネクタと呼ぶ）だった場合を表していて、タスクの制御フローは以下のようになる。
【０１０７】
「タスク０１（１７０２）」から始まり、「フォルダ１（１７０３）」に制御が移り、「フォルダ１（１７０３）」の先頭タスクである「タスク０２（１７０４）」と「タスク０３（１７０６）」が同時に着手できる。「タスク０５（１７０７）」は「タスク０３（１７０６）」が完了すれば着手できるが、「タスク０４（１７０５）」は「タスク０２（１７０４）」と「タスク０３（１７０６）」の両方が完了しないと着手できない。「タスク０４（１７０５）」と「タスク０５（１７０７）」が完了し、「フォルダ１（１７０３）」の中の全てのタスクが完了した後、「タスク０６（１７０８）」に着手できる。
【０１０８】
図１６は、この制御フローをアクティビティ図で表現したものである。
【０１０９】
一方、図９において、コネクタ（９１０）は優先コネクタであるため、図１７と比べてタスクの制御フローは以下のように変わる。
【０１１０】
「タスク０１（９０２）」から始まり、「フォルダ１（９０３）」に制御が移り、「フォルダ１（９０３）」の先頭タスクである「タスク０２（９０４）」と「タスク０３（９０６）が同時に着手できる。そして、「タスク０３（９０６）」が完了すると、コネクタ（９１１）が繋がっている「タスク０５（９０７）」と優先コネクタ（９１０）が繋がっている「タスク０４（９０５）」が同時に着手できる。つまりこの場合、「タスク０４（９０５）」の先行タスクには「タスク０２（９０４）」が定義されているがこれは無視され、「タスク０３（９０６）」が完了した時点で、「タスク０２（９０４）」の状態に関わらず、優先コネクタ（９１０）が繋がっている先の、「タスク０４（９０５）」に着手できることになる。一方、「タスク０２（９０４）」が完了しても、「タスク０３（９０６）」の完了を待たないと、「タスク０４（９０５）」には着手できない。
【０１１１】
図１４は、この制御フローをアクティビティ図で表現したものである。
【０１１２】
優先タスク手順は、業務プロセスを一時的に変更する場合などに使うことができる。通常タスク手順の定義も、残されているので、一時的に変更した業務プロセスを元の通常の業務プロセスに戻すことも簡単にできるという利点がある。
【０１１３】
なお、優先タスク手順を示すコネクタは、図９のコネクタ（９１０）では、単に点線で表示されているが、フォルダを越えるタスク順序を定義してあり、双方または一方のフォルダが縮小表示状態の場合のコネクタ（点線）と区別できるよう、線の色を変える、点線ではなく一点鎖線にする、などで識別しやすくする。
【符号の説明】
【０１１４】
１１ 入力装置
１２ ＲＯＭ
１３ 記憶装置
１４ ＲＡＭ
１５ ＣＰＵ
１６ 出力装置
１７ ネットワークＩ／Ｆ
１８ システムバス
１９ ＬＡＮ
Ｓ２０２ タスク定義手段
Ｓ２０３ タスク属性定義手段
Ｓ２０４ タスクグループ定義手段
Ｓ２０５ タスクグループ属性定義手段
Ｓ２０６ タスク順序定義手段
Ｓ２０７ 業務プロセステンプレート保存手段
【技術分野】
【０００１】
本発明は、開発業務や日常業務のプロセスを定義し、定義された業務プロセスと関連する各種情報を管理する装置および方法に関する。
【背景技術】
【０００２】
ＰＭＢＯＫ等のプロジェクト管理の方法論においては、プロジェクトで実施すべき全ての細分化された作業（タスク）の一覧をＷＢＳ（ワーク・ブレークダウン・ストラクチャ）と呼ばれる階層構造を持った一覧表で管理し、これに従ってプロジェクトを遂行することが推奨されている。
【０００３】
また、ＷＢＳとガントチャートをベースにして、プロジェクトのタスク、スケジュール、リソースを統合的に管理するソフトウェアとしては、米国マイクロソフト社のソフトウェア「Ｍｉｃｒｏｓｏｆｔ Ｐｒｏｊｅｃｔ（ＭＳ Ｐｒｏｊｅｃｔ）」がよく知られている。（「マイクロソフト」「Ｍｉｃｒｏｓｏｆｔ」は登録商標）
一方、ソフトウェアの処理フローや業務フローを記述する方法としては、フローチャートやＵＭＬのアクティビティ図などが使用可能である。ここで言う「フロー」とは、処理の順序のことである。
【０００４】
ＭＳ Ｐｒｏｊｅｃｔを使用すれば、あるタスクの前に行なうべきタスク（先行タスク）、あるタスクの後に行なうべきタスク（後続タスク）を定義することが可能である。さらに、先行タスクが完了する前に後続タスクに着手する設定（リードタイムの設定）や、先行タスクの完了後に一定の待ち時間を設けて後続タスクに着手する設定（ラグタイムの設定）、も可能である。
【０００５】
また、アクティビティ図を使用すれば、後続処理を条件（ガード条件）によって複数の処理に分岐させる設定（分岐処理）や、いったん分岐した処理を元の１本の処理に戻す設定（合流処理）が可能である。さらに、同期バーを使用することで、並行して処理に着手できる設定（並行処理）、複数の処理が全て完了しないと後続の処理に移れない設定（待機処理）、も可能である。
【０００６】
アクティビティ図では、入れ子構造の表記をすることによって、フローのある部分の処理を詳細化することができ、同様にＷＢＳでは、ツリーの親子関係によって、処理の詳細化を表現することができる。
【０００７】
特許文献１では、フロー制御の記述をグラフィカル・ユーザ・インターフェイス（ＧＵＩ）を利用して、インタラクティブに行ない、見やすくレイアウトする技術が開示されている。
【０００８】
特許文献２では、タスクを実施する際に、タスクを実施する際に必要なドキュメント、タスクの成果物、参照すべき画像ファイルなどの関連オブジェクトを、タスクにひも付けて管理する技術が開示されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００５−０８４７２５号公報
【特許文献２】特開２００６−１０７１４１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
さて、実際に開発業務や日常業務のプロセスを定義する際には、開発フェーズや業務担当部門ごとに、その範囲内でタスク群を抽出し、それらをひとくくりにしてグループ化したい場合がある。さらに、タスクやタスクをひとくくりにグループ化したもの（タスクグループと呼ぶ）に対して、それぞれ一意の属性を付加することによって、ある開発フェーズで実施すべきタスクやドキュメント等のタスク関連オブジェクトを明確にする、あるいは、ある担当部門が管理すべきタスクやタスク関連オブジェクトを明確にする、ということを実現したい場合がある。しかし一方では同時に、タスクグループの例である、開発フェーズや業務担当部門を越えて、先行可能なタスク、待機すべきタスク、というものも存在する。
【００１１】
しかしながら、上記従来の技術例では、複数のタスクをひとくくりにしてグループ化する場合、上位のタスクから下位のタスク群を作成しこれをグループ化するか（タスクの詳細化）、あるいは下位のタスク群をグループ化して上位のタスクを定義するか（タスクの一般化）、のどちらかの用途であった。または、タスクグループに属性が設定されていても、タスクグループ内のタスクフローの制御に関しては、上記のタスクの詳細化、あるいはタスクの一般化以外の指定はできなかった。
【００１２】
すなわち、同一のタスクグループ内でのタスクフローは、開始タスクおよび終了タスクが一意に固定されており、それを変更したり、タスクグループを越えて先行処理や待機処理を記述することはできない、という課題があった。
【００１３】
本発明では、属性を持った意味のあるまとまりであるタスクのくくり（タスクグループ）を維持しながらも、タスクフローの制御をＧＵＩ上でインタラクティブに変更することを可能にして、業務プロセス定義、および業務プロセスに関わる各種情報の管理を行なうユーザの利便性を向上させる装置を提供することを目的としている。
【課題を解決するための手段】
【００１４】
前述の課題を解決するため、本発明のプロセス情報管理装置は、タスク定義手段と、タスク属性定義手段と、タスクグループ定義手段と、タスクグループ属性定義手段と、タスク順序定義手段と、業務プロセステンプレート保存手段と、タスクグループ表示切換手段と、参照業務プロセステンプレート定義手段と、を設けた。
【００１５】
請求項１に記載した発明により、タスク定義手段は、特定の業務プロセスを細分化した複数のタスクを定義し、描画オブジェクトとして表示し、タスク属性定義手段は、タスクに関連する複数の属性情報を定義し、タスクグループ定義手段は、複数のタスクを分類および階層化し、描画オブジェクトとして表示し、タスクグループ属性定義手段は、タスクグループに関連する複数の属性情報を定義し、該属性情報は該タスクグループに含まれる全てのタスクに共通の属性とし、タスク順序定義手段は、第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義し、接続を示すコネクタを描画オブジェクトとして表示し、業務プロセステンプレート保存手段は、作成された一連の手順を該業務プロセスのテンプレートとして保存する。
【００１６】
請求項２に記載した発明により、タスク順序定義手段は、互いに異なるタスクグループに所属する、第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義する。
【００１７】
請求項３に記載した発明により、タスクグループ表示切換手段は、タスクグループ内に存在するタスクおよびタスクグループを示す描画オブジェクトを画面上に表示するか（展開表示）、表示しないか（縮小表示）を切り換え、かつ、タスク順序定義手段で定義されたコネクタが該タスクグループに接続する場合に該コネクタの表示状態を切り換える。
【００１８】
請求項４に記載した発明により、参照業務プロセステンプレート定義手段は、第１の業務プロセステンプレート上で、第２の業務プロセステンプレートを参照として定義し、描画オブジェクトとして表示し、タスク順序定義手段は、前記参照業務プロセステンプレートとのタスク順序を定義する。
【００１９】
請求項５に記載した発明により、タスク順序定義手段は、タスク、タスクグループ、参照業務プロセステンプレート、の間に定義される複数のタスク順序のうち、特定のタスク順序の定義を優先して判断する。
【００２０】
請求項６に記載した発明により、前述の課題を解決する、プロセス情報管理システムのデータ処理方法を提供する。
【００２１】
請求項７に記載した発明により、前述の課題を解決する、プロセス情報管理システムのデータ処理方法をコンピュータに機能させるためのプログラムを記録したコンピュータ読み取り可能な記憶媒体を提供する。
【発明の効果】
【００２２】
本発明により、属性を持った意味のあるまとまりであるタスクのくくり（タスクグループ）を維持しながらも、タスクフローの制御をＧＵＩ上でインタラクティブに変更することを可能にして、業務プロセス定義、および業務プロセスに関わる各種情報の管理を行なうユーザの利便性を向上させるという効果がある。
【００２３】
本発明の請求項１にかかる装置では、属性を持ったタスク、属性を持ったタスクグループ、タスクを実行する順序、をＧＵＩ上でインタラクティブに定義し、業務プロセステンプレートとして保存することができる。
【００２４】
本発明の請求項２にかかる装置では、入れ子構造や並列構造になったタスクグループを越えた制御フロー（特殊タスク手順）を定義することができる。
【００２５】
本発明の請求項３にかかる装置では、ＧＵＩ上でタスクグループを展開または縮小表示することができ、かつ、縮小表示状態でも、タスクグループ内部の制御フローを表現することができる。
【００２６】
本発明の請求項４にかかる装置では、他の業務プロセステンプレートを参照して利用することができる。
【００２７】
本発明の請求項５にかかる装置では、特定のタスク順序の定義を優先させる制御フロー（優先タスク手順）を定義することができる。
【図面の簡単な説明】
【００２８】
【図１】本発明の第１実施形態にかかるプロセス情報管理装置のハードウェア構成を示すブロック図である。
【図２】本発明の実施形態にかかるプロセス情報管理装置で業務プロセスを作成する手順を示すフローチャートである。
【図３】本実施例における標準的な業務プロセステンプレートを定義した例である。
【図４】フォルダを越えるタスク順序を定義した例である。
【図５】フォルダを越えるタスクの移動を実行した例である。
【図６】フォルダを越えるタスク順序を定義した双方のフォルダを縮小表示した場合の画面表示例である。
【図７】フォルダを越えるタスク順序を定義した一方のフォルダを縮小表示した場合の画面表示例である。
【図８】ある業務プロセスから他の業務プロセスを参照した場合の例である。
【図９】複数のタスク手順が定義されている場合の優先タスク手順を定義した例である。
【図１０】本実施例の図１０の制御フローを示すアクティビティ図である。
【図１１】タスク属性入力画面の例である。
【図１２】本実施例の図３の制御フローを示すアクティビティ図である。
【図１３】本実施例の図４の制御フローを示すアクティビティ図である。
【図１４】本実施例の図９における制御フローを示すアクティビティ図である。
【図１５】本実施例の図１０の制御フローを示すアクティビティ図である。
【図１６】本実施例の図１７における制御フローを示すアクティビティ図である。
【図１７】本実施例の図９におけるコネクタ（９１０）が通常のタスク手順（通常タスク手順と呼ぶ）を示すコネクタである場合の例である。
【発明を実施するための形態】
【００２９】
以下、本発明にかかる一実施形態のプロセス情報管理装置を図面を参照して詳細に説明する。
【００３０】
［第１実施形態］
［システム構成と動作手順］
図１は、本発明の第１実施形態にかかるプロセス情報管理装置のハードウェア構成を示すブロック図である。
【００３１】
本発明の実施形態にかかるプロセス情報管理装置（以下、本装置）のサーバコンピュータ（以下、サーバ）および各クライアントコンピュータ（以下、クライアント）は、同様のハードウェア構成である。また、サーバとクライアントは物理的に１つのハードウェアであってもよい。
【００３２】
図１において、１１はマウスやキーボードなどの入力装置、１２はＲＯＭ、１３はハードディスクドライブ（ＨＤＤ）、ＦＤドライブ（ＦＤＤ）、ＣＤドライブ、ＤＶＤドライブなどの記憶装置、１４はＲＡＭ、１５はＣＰＵ、１６はＬＣＤやＣＲＴなどの出力装置、１７はネットワークＩ／Ｆ、１８はシステムバス、１９はＬＡＮである。
【００３３】
サーバと各クライアントは、ネットワークＩ／Ｆ１７を介してＬＡＮ１９に接続されており、サーバ上で動作している本装置と必要なデータのやり取りを行う。
【００３４】
本装置のプログラムおよび必要なデータは、システムが動作するサーバ上の記憶装置１３に格納されており、ＲＡＭ１４に取り込まれる。プログラムおよびデータがＲＯＭ１２に格納されている場合は、ＲＯＭ１２からＲＡＭ１４に読み込まれる。ＣＰＵ１５は、ＲＡＭ１４にアクセスしてプログラムを動作させる。
【００３５】
ユーザは、クライアントの出力装置１６に表示された画面の指示に従い、クライアントの入力装置１１を使用して、必要な情報を入力または指示する。入力データは、クライアントのＣＰＵ１５に伝えられ、ネットワークＩ／Ｆ１７とＬＡＮ１９を介してサーバに送信される。サーバで処理された結果は、ネットワークＩ／Ｆ１７とＬＡＮ１９を介して、再びクライアントに送信され、クライアントの出力装置１６の画面に表示される。
【００３６】
［標準的な業務プロセスの作成］
図２は、本発明の実施形態にかかるプロセス情報管理装置で業務プロセスを作成する手順を示すフローチャートである。
【００３７】
本実施例では、開発業務や日常業務の一連の流れを定義したもの、を「業務プロセス」または単に「プロセス」と呼ぶことにする。また、業務プロセスを雛型として保存したものを特に「業務プロセステンプレート」と呼ぶ。
【００３８】
図２のフローチャートにしたがって、これより図３と図１１を参照しながら、本実施例における標準的な業務プロセステンプレート作成する手順を詳細に説明する。
【００３９】
まず、ユーザは業務プロセスの名称を決め、業務プロセスを作成する（Ｓ２０１）。マウスなどの入力装置１１（以下、単にマウス）でメニューから「業務プロセス新規作成」をクリックすることなどで、業務プロセスが新規に作成されると、出力装置１６には「プロセス１（３０１）」の編集画面が表示される。
【００４０】
次に、ユーザは、その業務プロセスの中で実施しなければならないタスク（作業）を洗い出した上で、いくつでもタスクを定義する（Ｓ２０２）。タスクを示す描画オブジェクトの形状（例えば矩形）は、あらかじめＲＡＭ１４に格納されており、出力装置１６上に雛型の描画オブジェクトとして表示されている。ユーザは、マウスでタスクを示す雛型の描画オブジェクトを「プロセス１（３０１）」上にドラッグするなどの方法で、タスクを配置して行く。この時点では、タスクの詳細情報は、まだ完全に入力されていなくてもよい。
【００４１】
例えば、タスクのタイトルを「タスク０１」と、キーボードなどの入力装置１１（以下、単にキーボード）で入力し、配置場所をマウスで指示することにより「タスク０１（３１０）」が作成される。同様の操作で、「タスク０２（３１１）」から「タスク０８（３１２）」までのタスクを「プロセス１（３０１）」上に定義、配置する。なお、タスクを作成する順番は、タスクを実行する順序（タスク順序と呼ぶ）とは無関係に定義して行くことができる。
【００４２】
次に、ユーザは、定義済のタスクに対してその属性を定義することができる（Ｓ２０３）。定義済のタスクを示す描画オブジェクトをマウスでダブルクリックするなどの方法で指定すると、図１１に示すタスク属性入力画面（１１０１）が表示される。タスク属性入力画面（１１０１）には、タスクの詳細な内容を記述した文章（１１０３）、タスクの内容を示唆するキーワード（１１０４）、タスクの日程（開始予定日や終了予定日など）（１１０５）、その他の属性（１１０６）を記述することができる。
【００４３】
また、それぞれのタスクに、複数のナレッジを紐付けることもできる。ここで言うナレッジとは、そのタスクに関係のある設計書やメモ書きなどのファイル、図面や画像ファイル、関連Ｗｅｂページへのリンク情報、関連ファイルの格納フォルダへのリンク情報などを総称したものである。このようにして、各タスクの内容を詳細化して行く。なお、タスク属性を入力する順番は、タスク順序やタスクを作成した順番とは無関係に定義して行くことができる。
【００４４】
次に、タスクのグルーピング（ひとくくりにしてグループ化すること）を行う（Ｓ２０４）。グルーピングは「フォルダ」と呼ばれるものを用いて行う。本実施例では、プロセス内で、複数のタスクをひとくくりにしたものを「フォルダ」または「タスクグループ」と定義する。フォルダは、タスクとフォルダを内部に包含することができる。また、フォルダに所属しないタスクも存在可能である。
【００４５】
「プロセス１（３０１）」を例に取って操作を説明する。まず「フォルダ１１（３０４）」を作成し、その中に「タスク０１（３１０）」と「タスク０２（３１１）」を移動させる。移動は、マウスを使ってタスクをドラッグ・アンド・ドロップすることなどで行なえる。フォルダの作成方法は、タスクの場合と同様で、フォルダを示す描画オブジェクトの形状（例えば角丸矩形）は、あらかじめＲＡＭ１４に格納されており、出力装置１６上に雛型の描画オブジェクトとして表示されている。ユーザは、マウスでフォルダを示す雛型の描画オブジェクトを「プロセス１（３０１）」上にドラッグするなどの方法で、フォルダを配置して行く。この時点では、フォルダの詳細情報は、まだ完全に入力されていなくてもよい。
【００４６】
同様に「フォルダ２１（３０６）」を作成し、その中に「タスク０３（３１３）」と「タスク０４（３１４）」を移動させる。また「フォルダ１２（３０５）」を作成し、その中に「タスク０８（３１２）」を移動させる。また「フォルダ２２（３０７）」を作成し、その中に「タスク０５（３１５）」と「タスク０６（３１６）」を移動させる。また「フォルダ１（３０２）」を作成し、その中に「タスク０１」と「タスク０２」を含んだ「フォルダ１１（３０４）」と、「タスク０８」を含んだ「フォルダ１２（３０５）」を移動させる。また「フォルダ２（３０３）」を作成し、その中に「タスク０３」と「タスク０４」を含んだ「フォルダ２１（３０６）」と、「タスク０５」と「タスク０６」を含んだ「フォルダ２２（３０７）」を移動させる。
【００４７】
なお、タスクのグルーピングを行う順番は決められているわけではなく、ユーザはプロセス全体を眺めてグルーピングした方がよいと判断した部分から、フォルダにまとめるという操作を行なうことができる。例えば、先ほどの例では「フォルダ１（３０２）」から作成し、タスク群を内部に入れていったが、「フォルダ１２（３０５）」から先に、グルーピングすることも可能である。あるいは、「フォルダ１（３０２）」に「フォルダ１１（３０４）」を入れる操作を先に行なうことも可能である。また、フォルダを作成する順番は、フォルダ間のタスク群を実行する順序とは無関係に定義して行くことができる。
【００４８】
次に、ユーザは、定義済のフォルダに対してその属性を定義することができる（Ｓ２０５）。定義済のフォルダを示す描画オブジェクトをマウスでダブルクリックするなどの方法で指定すると、図１１のタスク属性入力画面と同様の、フォルダ属性入力画面が表示される。フォルダ属性入力画面には、フォルダの詳細な内容を記述した文章、フォルダの内容を示唆するキーワード、フォルダの日程（開始予定日や終了予定日など）、その他の属性を記述することができる。また、タスクと同様、それぞれのフォルダに、複数のナレッジを紐付けることもできる。
【００４９】
各タスクはタスク属性を複数持つことができるが、タスクは上位のフォルダが持つ複数のフォルダ属性を継承することもできる。つまり、タスクが１つのフォルダにくくられた時、それらのタスクは、自タスクが持つタスク属性群、自タスクの上位フォルダ群が持つタスクフォルダ属性群を全て参照することができる。
【００５０】
次に、タスクを実行する順序を決めて行く（Ｓ２０６）。本実施例では、タスクとタスクだけではなく、タスクとフォルダ、フォルダとフォルダ、およびこれらと、後述する参照業務プロセステンプレート、の間に定義される実行順序の依存関係を総称して「タスク順序」と呼ぶことにする。タスク順序を定義すると、該当する２つの描画オブジェクト間に、タスク順序を示す矢印付きの線（コネクタと呼ぶ）が表示される。タスク順序の定義を行なう操作は、例えば、「タスク０１（３１０」をシフトキーを押しながらマウスでクリックし、次に「タスク０２（３１１）」をシフトキーを押しながらマウスでクリックすれば、コネクタ（３２０）が、作成される。
【００５１】
「プロセス１（３０１）」を例に取って操作を説明する。まず「フォルダ１１（３０４）」内の「タスク０１（３１０）」から「タスク０２（３１１）」へコネクタ（３２０）を引く。次に「フォルダ２１（３０６）」内の「タスク０３（３１３）」から「タスク０４（３１４）」へコネクタ（３２２）を引く。また「フォルダ２２（３０７）」内の「タスク０５（３１５）」から「タスク０６（３１６）」へコネクタ（３２３）を引く。また「フォルダ２（３０３）」から「プロセス１（３０１）」直下の「タスク０７（３１７）」にコネクタ（３２５）を引く。また「フォルダ１（３０２）」から「フォルダ２（３０３）」へコネクタ（３２１）を引く。
【００５２】
これらのコネクタは業務プロセスの順に従って、例えば業務プロセス内で最初に着手すべきタスクから順番に引いて行く必要はなく、特定のタスク間もしくはフォルダ間もしくはタスクとフォルダ間の前後関係が確定した時点でその部分からコネクタを引くことができる。もちろん、業務プロセスが変わるたびに、既存のコネクタの接続タスクを変更すること、既存のコネクタを削除することができる。
【００５３】
コネクタはそれ自身が、先行タスクと後続タスクの情報を格納する領域を持っている。例えば、コネクタ（３２０）には先行タスクとして「タスク０１（３１０）」の情報、後続タスクとして「タスク０２（３１１）」の情報が、コネクタ（３２５）には先行タスクとして「フォルダ２（３０３）」の情報、後続タスクとして「タスク０７（３１７）」の情報が、それぞれ格納されている。
【００５４】
ユーザは、Ｓ２０２〜Ｓ２０６のステップを繰り返しながら、業務プロセスを作成していく。なお、Ｓ２０２〜Ｓ２０６の各ステップは順不同であり、ユーザはどのような順番で処理を行ってもよい。例えば、先にフォルダを作成してからその中にタスクを作成してもよいし、コネクタが付いた複数のタスク群をフォルダでくくる操作をしてもよい。また、同一のステップの処理を何度行っても良い。本装置のグラフィカル・ユーザ・インターフェイス（ＧＵＩ）上で、ユーザがこのようにインタラクティブに、タスク、フォルダ、およびコネクタを配置して行くことにより、思考を妨げられることなく、円滑に思い通りの業務プロセスを作成することができる。
【００５５】
最後にユーザは、定義した業務プロセスを記憶装置１３に保存する（Ｓ１０６）。ユーザは、マウスでメニューから「業務プロセス保存」をクリックすることなどで、作成完了または作成途中の業務プロセスを、業務プロセスの雛型である「業務プロセステンプレート」として保存する。作成途中の業務プロセスを再編集する場合には、Ｓ２０１において、新規に業務プロセスを作成する代わりに、業務プロセステンプレートを記憶装置から呼び出せばよい。
【００５６】
［タスク処理フローの説明］
本装置で適用可能なタスク処理フローとその表記ルールについて、以下に説明する。
【００５７】
図３の例では、「タスク０１（３１０）」から「タスク０２（３１１）」に向けてコネクタ（３２０）が引かれている。これは、「タスク０１（３１０）」が完了してから、次の「タスク０２（３１１）」に着手できる、という意味である。（先行タスクと後続タスクの指定）
図１０の例では、「タスク０１（１０１０）」から「タスク０２（１０１１）」と「タスク０３（１０１２）」に向けてコネクタが引かれている。これは、「タスク０１（１０１０）」が完了した後、次の「タスク０２（１０１１）」と「タスク０３（１０１２）」を同時並行で着手できる、という意味である。一般に、あるタスクの後続タスクとして複数のタスクが指定されている場合には、先行タスクが完了したら、後続タスク群は同時並行で着手できる、という意味である。（後続タスクの並行処理指定）
また図１０の例では、「タスク００（１０１５）」が完了すると、「フォルダ１（１００２）」内のタスクに着手できるが、「フォルダ１（１００２）」の直下にあり、先行タスクがないタスクまたはフォルダ、すなわち、「タスク０１（１０１０）」、「フォルダ１１（１００３）」内の先頭タスク、「フォルダ１２（１００４）」内の先頭タスク、が同時並行で着手できる。このように、後続タスクがフォルダである場合には、「タスク００（１０１５）」から、「タスク０１（１０１０）」、「フォルダ１１（１００３）」、「フォルダ１２（１００４）」のそれぞれにコネクタを引くことなく、直接「フォルダ１（１００２）」にコネクタを引くことによって、並行処理を表現できる。（先頭タスクの並行処理指定）
また図３の例では、「フォルダ１（３０２）」の内部は、サブフォルダ（入れ子になった子のフォルダ）も含め、「フォルダ１１（３０４）」、「フォルダ１２（３０５）」、「タスク０１（３１０）」、「タスク０２（３１１）」、「タスク０８（３１２）」で構成されている。この場合、後続タスクである「フォルダ２（３０３）」に着手できるのは、「フォルダ１（３０２）」のタスクが全て完了してから、ということになる。
【００５８】
また図３の例では、「タスク０４（３１４）」の先行タスクとして「タスク０３（３１３）」と「タスク０５（３１５）」が指定されている。これは「タスク０３（３１３）」と「タスク０５（３１５）」の両方が完了しないと、「タスク０４（３１４）」に着手することができない、という意味である。あるタスクの先行タスクとして複数のタスクが指定されている場合には、先行タスクの全てが完了するまで、後続タスクには着手できない、という意味である。（待機処理指定）
以上説明したタスク処理フロー表記ルールを適用すると、図３の例では、「フォルダ１（３０２）」の処理が完了したら「フォルダ２（３０３）」の処理に着手できることになる。「フォルダ２（３０３）」の先頭タスクは「フォルダ２１（３０６）」と「フォルダ２２（３０７）」で、この二者は同時に着手できる。また、各フォルダ内の先頭タスクは、それぞれ「タスク０３（３１３）」と「タスク０５（３１５）」であることから、「タスク０３（３１３）」と「タスク０５（３１５）」が同時並行で着手できる、ということになる。
【００５９】
先ほど説明した「フォルダ１（３０２）」内の処理と同様に、「タスク０３（３１３）」と「タスク０４（３１４）」が完了することで「フォルダ２１（３０６）」の処理が完了し、「タスク０５（３１５）」と「タスク０６（３１６）」が完了することで「フォルダ２２（３０７）」の処理が完了する。そして「フォルダ２１（３０６）」と「フォルダ２２（３０７）」の処理が完了することで、「フォルダ２（３０３）」の処理が完了することになる。
【００６０】
［ＵＭＬアクティビティ図の説明］
本装置の制御フローの記述は、従来技術であるＵＭＬアクティビティ図（以下、単にアクティビティ図）の表現を用いても表現することができる。
【００６１】
図１２は、本実施例の図３の制御フローを示すアクティビティ図である。
【００６２】
簡単にアクティビティ図の表記について説明する。１２０１はフローの開始、１２０２はフローの終了を意味する。また、１２０５などタスクとタスクを繋ぐ矢印はタスクの実行順序を示す。例えば、「タスク０１（１２１０）」が「タスク０２（１２１１）」の先行タスクであるとき、１２０５の矢印を引く。
【００６３】
１２０３と１２０４は「同期バー」と呼ばれるものである。１２０３の同期バーは並行処理を意味する。この例では、同期バー（１２０３）に後続する「タスク０１（１２１０）」と「タスク０８（１２１２）」が同時に並行して着手できることを示している。また、１２０４の同期バーは待機処理を意味する。この例では、同期バー（１２０４）の後続する「タスク０７（１２１７）」は、同期バー（１２０４）に先行する「タスク０４（１２１４）」と「タスク０６（１２１６）」の両方の完了を待って着手できることを意味している。
【００６４】
図１５は、本実施例の図１０の制御フローを示すアクティビティ図である。
【００６５】
［フォルダの適用事例］
ここで図３を用いて、フォルダを開発業務プロセスに適用した事例について説明する。
【００６６】
開発業務プロセスは、多数のタスクから構成される。一般に、開発業務には、開発のマイルストーンを設定したり、開発物の完成度を高めて行く段階を定義するために「フェーズ」という概念がある。例えば、ある開発業務プロセスが、フェーズα、フェーズβ、フェーズγ、という３つのフェーズで構成されているとする。このような場合、タスク群をフェーズごとにくくって、フォルダで管理することができる。
【００６７】
例えば、フェーズαで実施すべきタスクである、「タスク０１（３１０）」、「タスク０２（３１１）」、「タスク０８（３１２）」には、「フェーズα」という共通の属性を持たせたい。そこで「フォルダ１（３０２）」を「フェーズαで実施すべきタスク群」という意味で使用し、そのフォルダ属性の１つとして「フェーズα」を付与する。同様にして、フェーズβで実施すべきタスクである、「タスク０３（３１３）」、「タスク０４（３１４）」、「タスク０５（３１５）」、「タスク０６（３１６）」を、「フォルダ２（３０３）」でくくり、そのフォルダ属性の１つとして「フェーズβ」を付与する。
【００６８】
さらに、例えば「タスク０１（３１０）」と「タスク０８（３１２）」に紐付けたナレッジファイルにも、タスク属性が持つナレッジへのリンク情報から「フェーズα」という属性を付与することも可能となる。これを実現すれば、「フェーズαで実施すべきタスク」に加えて「フェーズαのタスクで作成したナレッジファイル」という情報を特定することもできるようになる。
【００６９】
さて、開発業務には、フェーズとは独立して、その業務の「担当部門」という概念もある。例えば、ある開発業務プロセスが、フェーズα、フェーズβ、フェーズγ、という３つのフェーズで構成されており、さらに、Ａ部門とＢ部門という２つの担当部門が開発業務に携わっているとする。このような場合、タスク群をフェーズごとにくくって、フォルダで管理し、さらに、担当部門ごとのフォルダを作成することもできる。
【００７０】
例えば、フェーズαを表す「フォルダ１（３０２）」の内部で、Ａ部門が担当する「タスク０１（３１０）」および「タスク０２（３１１）」と、Ｂ部門が担当する「タスク０８（３１２）」があったとする。このような場合も、フォルダを適用することができる。すなわち、「フェーズαでＡ部門が担当するタスク群」として「フォルダ１１（３０４）」を、「フェーズαでＢ部門が担当するタスク群」として「フォルダ１２（３０５）」を作成し、フェーズを表すフォルダ属性とは別のフォルダ属性に、それぞれ「Ａ部門」、「Ｂ部門」を付与すればよい。同様に、フェーズβを表す「フォルダ２（３０３）」の内部でも、Ａ部門が担当する「タスク０３（３１３）」および「タスク０４（３１４）」をくくった「フォルダ２１（３０６）」と、Ｂ部門が担当する「タスク０５（３１５）」および「タスク０６（３１６）」をくくった「フォルダ２２（３０７）」を作成し、担当部門を表すフォルダ属性を付与すればよい。
【００７１】
このように、フォルダをうまく適用することで、担当部門とフェーズという２つの切り口から、タスク群をくくることができ、各タスクおよびタスクに紐づくナレッジに、部門を表すフォルダ属性とフェーズを表すフォルダ属性を付与することができる。これにより、例えば、「タスク０５（３１５）」は「フェーズβでＢ部門が行うタスク」であることが分かる。また、「フェーズαでＡ部門が担当するタスク」は「タスク０１（３１０）」と「タスク０２（３１１）」であることも分かる。さらに、「Ｂ部門が（フェーズαで）作成したナレッジファイル」という情報を特定することもできるようになる。
【００７２】
［フォルダを越えるタスク順序の定義］
図４は、フォルダを越えるタスク順序を定義した例である。
【００７３】
図３と図４はタスクとフォルダの配置は同じだが、図４では「タスク０１（４１０）」から「タスク０５（４１５）」へのコネクタが追加されている。本装置では、このようなフォルダ順序を越えるタスク順序の定義も可能である。
【００７４】
図４はフェーズαのタスクの１つである「タスク０１（４１０）」が完了したら、フェーズα全体の完了を待たずに、フェーズβのタスクの１つである「タスク０５（４１５）」に先行して着手することができる、という意味になる。実際の開発業務においても、このような運用を行なって、開発期間の短縮を図ることは行なわれている。ただし、あくまでも、「タスク０１（４１０）」はフェーズαの、「タスク０５（４１５）」はフェーズβのタスクである、ということに変わりはない。フォルダ属性は維持されているので、本実施例では、これを実現することが可能である。
【００７５】
図１３は、本実施例の図４の制御フローを示すアクティビティ図である。図４は図３にコネクタ（４２６）が追加されただけであるが、図１２と図１３を比較すると、アクティビティ図の表記では大きく変化することがわかる。
【００７６】
［フォルダを越えるタスクの移動］
図５は、フォルダを越えるタスクの移動を実行した例である。
【００７７】
図４と図５は、タスクとフォルダの接続関係は同じだが、「タスク０５（５１５）」の上位フォルダが異なる。これは、例えばマウスを使ってタスクをドラッグ・アンド・ドロップする方法で、図４の「タスク０５（４１５）」を、「フォルダ２２（４０７）」から「フォルダ１２（４０５）」に移動することによって実現している。
【００７８】
これを実際の開発業務に適用すると、これまで「タスク０５（４１５）」はＢ部門がフェーズβで行っていたが、このタスクは同じＢ部門がフェーズαの段階から行ったほうが、開発の効率がよいと判断された場合などが考えられる。このとき、「タスク０５（４１５）」に接続されているコネクタ（５２３）、コネクタ（５２４）、コネクタ（５２６）は、そのままの接続状態で維持されるため、タスク順序には変動はない。このように、コネクタが接続された状態のタスクやフォルダを、フォルダのくくりを越えて移動することにより、タスク順序を変えることなく、一部の属性を変更することが可能となる。図４と図５の例では、「タスク０５」が継承するフォルダ属性のうち、フェーズを表す属性が「フェーズβ」から「フェーズα」に変化した。
【００７９】
タスク順序に変動は無いため、図５の制御フローを示すアクティビティ図は図１３であり、図４のアクティビティ図と同じである。
【００８０】
［フォルダの展開・縮小表示１］
本装置の出力装置１６に表示されるＧＵＩは、フォルダの内部に存在するタスクおよびフォルダの表示と非表示を切り換えることができる。以降、前者をフォルダ展開表示、後者をフォルダ縮小表示と呼ぶ。
【００８１】
図６は、フォルダを越えるタスク順序を定義した双方のフォルダを縮小表示した場合の画面表示例である。
【００８２】
図４は、全てのフォルダ内のタスクおよびフォルダが表示されたフォルダ展開表示状態である。図４と同じプロセスで、「フォルダ１（４０２）」と「フォルダ２（４０３）」をフォルダ縮小表示に変更すると、図６の表示になる。フォルダ展開・縮小表示の操作は、例えば、展開・縮小表示状態を変更したいフォルダをマウスで選択してから、画面上の「フォルダ展開・縮小」ボタンをクリックすることなどで、実現できる。フォルダ展開表示とフォルダ縮小表示の状態は、「フォルダ展開・縮小」ボタンをクリックするたびに切り換わる。
【００８３】
フォルダ展開表示状態（図４）で、「フォルダ２（４０３）」と「タスク０７（４１７）」を繋いでいたコネクタ（４２５）は、フォルダ縮小表示状態（図６）になったときにも、「フォルダ２（６０３）」と「タスク０７（６１７）」を繋ぐコネクタ（６２５）に相当し、コネクタ形状は実線の矢印のままである。同様に、フォルダ展開表示状態（図４）の「フォルダ１（４０２）」と「フォルダ２（４０３）」を繋いでいたコネクタ（４２１）は、フォルダ縮小表示状態（図６）においても、「フォルダ１（６０２）」と「フォルダ２（６０３）」を繋ぐコネクタ（６２１）に相当し、コネクタ形状は実線の矢印のままである。
【００８４】
フォルダ展開表示状態（図４）で、フォルダを越えるタスク順序を定義した、「フォルダ１（４０２）」の中の「タスク０１（４１０）」と「フォルダ２（４０３）」の中の「タスク０５（４１５）」とを繋ぐコネクタ（４２６）は、フォルダ縮小表示状態（図６）になったときに、「フォルダ１（６０２）」と「フォルダ２（６０３）」を繋ぐコネクタ（６２６）に相当する。このようにフォルダを越えるタスク順序を定義したことを、双方のフォルダが縮小表示状態であっても識別するために、例えば、コネクタ形状を破線の矢印に変えている。フォルダ間を接続している実線のコネクタ（６２１）は、そのまま存在しているので、結果として、「フォルダ１（６０２）」と「フォルダ２（６０３）」を繋ぐコネクタは、コネクタ（６２１）とコネクタ（６２６）の２本になる。
【００８５】
タスク順序に変動は無いため、図６の制御フローを示すアクティビティ図は図１３であり、図４のアクティビティ図と同じである。
【００８６】
［フォルダの展開・縮小表示２］
図７は、図４にあるフォルダを越えるタスク順序を定義した一方のフォルダを縮小表示した場合の画面表示例である。
【００８７】
図７は、図４の「フォルダ１（４０２）」のみをフォルダ縮小表示状態にしたものである。フォルダ展開表示状態（図４）で、「フォルダ１（４０２）」と「フォルダ２（４０３）」を繋いでいたコネクタ（４２１）は、フォルダ１の縮小表示状態（図７）においても、「フォルダ１（７０２）」と「フォルダ２（７０３）」を繋ぐコネクタ（７２１）に相当し、コネクタ形状は実線の矢印のままである。
【００８８】
フォルダ展開表示状態（図４）で、「フォルダ１（４０２）」の中の「タスク０１（４１０）」と「フォルダ２（４０３）」の中の「タスク０５（４１５）」とを繋ぐコネクタ（４２６）は、フォルダ１の縮小表示状態（図７）では、「フォルダ１（７０２）」と「フォルダ２（７０３）」の中の「タスク０５（７１５）」を繋ぐコネクタ（７２６）に相当する。このようにフォルダを越えるタスク順序を定義したことを、一方のフォルダが縮小表示状態であっても識別するために、例えば、コネクタ形状を破線の矢印に変えている。
【００８９】
同様に、図４の「フォルダ２（４０３）」のみをフォルダ縮小表示状態にした場合には、図４のコネクタ（４２１）に相当するコネクタ形状は実線の矢印のまま表示され、図４のコネクタ（４２６）に相当するコネクタ形状は、縮小表示状態にした「フォルダ２」への点線の矢印で表示されることにあなる。
【００９０】
以上［フォルダの展開・縮小表示１］および［フォルダの展開・縮小表示２］の説明により、タスク順序を定義している２つのフォルダの双方または一方が縮小表示状態であっても、これらのフォルダ間でフォルダを越えるタスク順序を定義していることを、ユーザが識別することができる。
【００９１】
タスク順序に変動は無いため、図７の制御フローを示すアクティビティ図は図１３であり、図４のアクティビティ図と同じである。
【００９２】
［他の業務プロセステンプレートの参照］
図８は、ある業務プロセスから他の業務プロセスを参照した場合の例である。
【００９３】
図８では、別に作成した他の業務プロセステンプレートへの参照（参照業務プロセステンプレートと呼ぶ）を「ショートカット」という描画オブジェクトで示している。参照業務プロセステンプレートを示す描画オブジェクトの形状（例えばタスクとは枠線の色が異なる矩形）は、あらかじめＲＡＭ１４に格納されており、出力装置１６上に雛型の描画オブジェクトとして表示されている。ユーザは、マウスで参照業務プロセステンプレートを示す雛型の描画オブジェクトを「プロセス２（８０１）」上にドラッグするなどの方法で、参照業務プロセステンプレートを配置していく。
【００９４】
配置したショートカットがどの業務プロセステンプレートを参照するかは、例えば、ショートカットをマウスの右ボタンでクリックして表示されるメニューで「参照業務プロセスの選択」を選択し、さらに、表示される業務プロセスの一覧から、既に作成済の業務プロセステンプレートを選択すればよい。
【００９５】
図８の例では、「ショートカット０１（８０３）」は、「ユニットＡの設計手順」を定義した業務プロセステンプレートへのショートカットを、「ショートカット０２（８０４）」は「ユニットＢの設計手順」を定義した業務プロセステンプレートへのショートカットを、「ショートカット０３（８０５）」は「ユニットＣの設計手順」というプロセスへのショートカットを、それぞれ表している。
【００９６】
これを実際の開発業務に適用すると、ある機器の構造が機能別に複数のユニットに分かれており、それを各ユニット担当者が別々に開発する場合などがある。それぞれのユニットの設計手順は、各ユニットの開発業務ノウハウに詳しい担当者が別々の業務プロセステンプレートとして作成する。
【００９７】
例えば、業務プロセス「ユニットＡの設計手順」の作成を作成者Ａが、業務プロセス「ユニットＢの設計手順」の作成を作成者Ｂが、業務プロセス「ユニットＣの設計手順」の作成を作成者Ｃが、それぞれ担当し、全体責任者Ｄが、それぞれのユニットをまとめて機器全体の開発業務プロセスを作成する、という場合である。
【００９８】
図８の例では、ある機器を構成するユニットが、ユニットＡ、ユニットＢ、ユニットＣ、の３つだった場合、別々に作成された、ユニットＡ、ユニットＢ、ユニットＣ、の各設計手順の業務プロセステンプレートを示すショートカットを、「プロセス２（８０１）」上に配置して、これらのタスク順序を定義するだけで、機器全体の開発業務プロセスが完成する。
【００９９】
さらに、類似の機器を開発する際、すなわち、機器を構成するユニットの一部のみが異なる場合にも、業務プロセステンプレートの参照がうまく適用できる。例えば、類似の機器を構成するユニットが、ユニットＢ、ユニットＣ、ユニットＤ、の３つだった場合は、ユニットＢとユニットＣの設計手順を定義した業務プロセステンプレートは既に作成済であるので、これらについては、各設計手順の業務プロセステンプレートを示すショートカットを用い、ユニットＤの設計手順を定義した業務プロセステンプレートだけを新規に作成すればよい。
【０１００】
このように、参照業務プロセステンプレートを利用することで、同じ内容の業務プロセスを再利用することが可能となり、一部の業務プロセス（例えば、あるユニットの設計手順）を変更しても、全体の業務プロセス（例えば、ある機器全体の設計手順）に影響を与えないことも可能となる。
【０１０１】
参照業務プロセステンプレートも、先に説明したフォルダの展開・縮小表示と同様に、展開・縮小表示が可能である。業務プロセステンプレートを示すショートカット展開・縮小表示の操作は、例えば、展開・縮小表示状態を変更したいショートカットをマウスで選択してから、画面上の「フォルダ展開・縮小」ボタンをクリックすることなどで、実現すればよい。ショートカット展開表示とショートカット縮小表示の状態は、「フォルダ展開・縮小」ボタンをクリックするたびに切り換わる。
【０１０２】
［優先タスク手順の設定］
図９は、複数のタスク手順が定義されている場合の優先タスク手順を定義した例である。
【０１０３】
図１４は、本実施例の図９における制御フローを示すアクティビティ図である。
図１７は、本実施例の図９におけるコネクタ（９１０）が通常のタスク手順（通常タスク手順と呼ぶ）を示すコネクタだった場合の例である。
【０１０４】
図１６は、本実施例の図１７における制御フローを示すアクティビティ図である。
【０１０５】
図９では、「フォルダ１（９０３）」の中の「タスク０３（９０６）」から「タスク０４（９０５）」に引かれているコネクタ（９１０）が示すタスク手順が、他の、コネクタ（９１２）、コネクタ（９１１）が示すタスク手順より優先する場合の例を示している。コネクタ（９１０）が示すタスク手順を「優先タスク手順」、優先タスク手順を示す描画オブジェクトを「優先コネクタ」と呼ぶことにする。
【０１０６】
図１７は、図９において、コネクタ（９１０）が優先コネクタではなく、通常のタスク手順（通常タスク手順と呼ぶ）を示すコネクタ（通常コネクタと呼ぶ）だった場合を表していて、タスクの制御フローは以下のようになる。
【０１０７】
「タスク０１（１７０２）」から始まり、「フォルダ１（１７０３）」に制御が移り、「フォルダ１（１７０３）」の先頭タスクである「タスク０２（１７０４）」と「タスク０３（１７０６）」が同時に着手できる。「タスク０５（１７０７）」は「タスク０３（１７０６）」が完了すれば着手できるが、「タスク０４（１７０５）」は「タスク０２（１７０４）」と「タスク０３（１７０６）」の両方が完了しないと着手できない。「タスク０４（１７０５）」と「タスク０５（１７０７）」が完了し、「フォルダ１（１７０３）」の中の全てのタスクが完了した後、「タスク０６（１７０８）」に着手できる。
【０１０８】
図１６は、この制御フローをアクティビティ図で表現したものである。
【０１０９】
一方、図９において、コネクタ（９１０）は優先コネクタであるため、図１７と比べてタスクの制御フローは以下のように変わる。
【０１１０】
「タスク０１（９０２）」から始まり、「フォルダ１（９０３）」に制御が移り、「フォルダ１（９０３）」の先頭タスクである「タスク０２（９０４）」と「タスク０３（９０６）が同時に着手できる。そして、「タスク０３（９０６）」が完了すると、コネクタ（９１１）が繋がっている「タスク０５（９０７）」と優先コネクタ（９１０）が繋がっている「タスク０４（９０５）」が同時に着手できる。つまりこの場合、「タスク０４（９０５）」の先行タスクには「タスク０２（９０４）」が定義されているがこれは無視され、「タスク０３（９０６）」が完了した時点で、「タスク０２（９０４）」の状態に関わらず、優先コネクタ（９１０）が繋がっている先の、「タスク０４（９０５）」に着手できることになる。一方、「タスク０２（９０４）」が完了しても、「タスク０３（９０６）」の完了を待たないと、「タスク０４（９０５）」には着手できない。
【０１１１】
図１４は、この制御フローをアクティビティ図で表現したものである。
【０１１２】
優先タスク手順は、業務プロセスを一時的に変更する場合などに使うことができる。通常タスク手順の定義も、残されているので、一時的に変更した業務プロセスを元の通常の業務プロセスに戻すことも簡単にできるという利点がある。
【０１１３】
なお、優先タスク手順を示すコネクタは、図９のコネクタ（９１０）では、単に点線で表示されているが、フォルダを越えるタスク順序を定義してあり、双方または一方のフォルダが縮小表示状態の場合のコネクタ（点線）と区別できるよう、線の色を変える、点線ではなく一点鎖線にする、などで識別しやすくする。
【符号の説明】
【０１１４】
１１ 入力装置
１２ ＲＯＭ
１３ 記憶装置
１４ ＲＡＭ
１５ ＣＰＵ
１６ 出力装置
１７ ネットワークＩ／Ｆ
１８ システムバス
１９ ＬＡＮ
Ｓ２０２ タスク定義手段
Ｓ２０３ タスク属性定義手段
Ｓ２０４ タスクグループ定義手段
Ｓ２０５ タスクグループ属性定義手段
Ｓ２０６ タスク順序定義手段
Ｓ２０７ 業務プロセステンプレート保存手段
【特許請求の範囲】
【請求項１】
複数の描画オブジェクトを生成し画面上に配置する操作、描画オブジェクトの関連付けを行なう操作、描画オブジェクトの移動・複写・削除操作、が可能なグラフィカル・ユーザ・インターフェイスを備えたプロセス情報管理装置であって、
特定の業務プロセスを細分化した複数のタスクを定義し、描画オブジェクトとして表示するタスク定義手段と、
前記タスク定義手段で定義されたタスクに関連する複数の属性情報を定義するタスク属性定義手段と、
複数のタスクを分類および階層化し、描画オブジェクトとして表示するタスクグループ定義手段と、
前記タスクグループ定義手段で定義されたタスクグループに関連する複数の属性情報を定義し、該属性情報は該タスクグループに含まれる全てのタスクに共通の属性とするタスクグループ属性定義手段と、
第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義し、接続を示すコネクタを描画オブジェクトとして表示するタスク順序定義手段と、
前記タスク定義手段、前記タスク属性定義手段、前記タスクグループ定義手段、前記タスクグループ属性定義手段、前記タスク順序定義手段、を使用して作成された一連の手順を該業務プロセスのテンプレートとして保存する業務プロセステンプレート保存手段と、
を有することを特徴とするプロセス情報管理装置。
【請求項２】
請求項１のタスク順序定義手段は、互いに異なるタスクグループに所属する、第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義する、
ことを特徴とするプロセス情報管理装置。
【請求項３】
請求項１または請求項２の構成に加え、
タスクグループ内に存在するタスクおよびタスクグループを示す描画オブジェクトを画面上に表示するか（展開表示）、表示しないか（縮小表示）を切り換え、かつ、タスク順序定義手段で定義されたコネクタが該タスクグループに接続する場合に該コネクタの表示状態を切り換えるタスクグループ表示切換手段と、
を有することを特徴とするプロセス情報管理装置。
【請求項４】
請求項１から請求項３のいずれかの構成に加え、
第１の業務プロセステンプレート上で、第２の業務プロセステンプレートを参照として定義し、描画オブジェクトとして表示する参照業務プロセステンプレート定義手段と、
を有することを特徴とし、
タスク順序定義手段は、前記参照業務プロセステンプレートとのタスク順序を定義する、
ことを特徴とするプロセス情報管理装置。
【請求項５】
請求項１から請求項４のタスク順序定義手段は、タスク、タスクグループ、参照業務プロセステンプレート、の間に定義される複数のタスク順序のうち、特定のタスク順序の定義を優先して判断する、
ことを特徴とするプロセス情報管理装置。
【請求項６】
複数の描画オブジェクトを生成し画面上に配置する操作、描画オブジェクトの関連付けを行なう操作、描画オブジェクトの移動・複写・削除操作、が可能なグラフィカル・ユーザ・インターフェイスを備えたプロセス情報管理システムのデータ処理方法であって、
特定の業務プロセスを細分化した複数のタスクを定義し、描画オブジェクトとして表示するタスク定義工程と、
前記タスク定義工程で定義されたタスクに関連する複数の属性情報を定義するタスク属性定義工程と、
複数のタスクを分類および階層化し、描画オブジェクトとして表示するタスクグループ定義工程と、
前記タスクグループ定義工程で定義されたタスクグループに関連する複数の属性情報を定義し、該属性情報は該タスクグループに含まれる全てのタスクに共通の属性とする タスクグループ属性定義工程と、
第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義し、接続を示すコネクタを描画オブジェクトとして表示する タスク順序定義工程と、
前記タスク定義工程、前記タスク属性定義工程、前記タスクグループ定義工程、前記タスクグループ属性定義工程、前記タスク順序定義工程、を使用して作成された一連の手順を該業務プロセスのテンプレートとして保存する業務プロセステンプレート保存工程と、
を有することを特徴とするプロセス情報管理システムのデータ処理方法。
【請求項７】
複数の描画オブジェクトを生成し画面上に配置する操作、描画オブジェクトの関連付けを行なう操作、描画オブジェクトの移動・複写・削除操作、が可能なグラフィカル・ユーザ・インターフェイスを備えたプロセス情報管理システムのデータ処理方法をコンピュータに機能させるためのプログラムを記録したコンピュータ読み取り可能な記憶媒体であって、
特定の業務プロセスを細分化した複数のタスクを定義し、描画オブジェクトとして表示するタスク定義工程と、
前記タスク定義工程で定義されたタスクに関連する複数の属性情報を定義するタスク属性定義工程と、
複数のタスクを分類および階層化し、描画オブジェクトとして表示する タスクグループ定義工程と、
前記タスクグループ定義工程で定義されたタスクグループに関連する複数の属性情報を定義し、該属性情報は該タスクグループに含まれる全てのタスクに共通の属性とする タスクグループ属性定義工程と、
第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義し、接続を示すコネクタを描画オブジェクトとして表示するタスク順序定義工程と、
前記タスク定義工程、前記タスク属性定義工程、前記タスクグループ定義工程、前記タスクグループ属性定義工程、前記タスク順序定義工程、を使用して作成された一連の手順を該業務プロセスのテンプレートとして保存する業務プロセステンプレート保存工程と、
を有することを特徴とするプログラムを記録したコンピュータ読み取り可能な記憶媒体。
【請求項１】
複数の描画オブジェクトを生成し画面上に配置する操作、描画オブジェクトの関連付けを行なう操作、描画オブジェクトの移動・複写・削除操作、が可能なグラフィカル・ユーザ・インターフェイスを備えたプロセス情報管理装置であって、
特定の業務プロセスを細分化した複数のタスクを定義し、描画オブジェクトとして表示するタスク定義手段と、
前記タスク定義手段で定義されたタスクに関連する複数の属性情報を定義するタスク属性定義手段と、
複数のタスクを分類および階層化し、描画オブジェクトとして表示するタスクグループ定義手段と、
前記タスクグループ定義手段で定義されたタスクグループに関連する複数の属性情報を定義し、該属性情報は該タスクグループに含まれる全てのタスクに共通の属性とするタスクグループ属性定義手段と、
第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義し、接続を示すコネクタを描画オブジェクトとして表示するタスク順序定義手段と、
前記タスク定義手段、前記タスク属性定義手段、前記タスクグループ定義手段、前記タスクグループ属性定義手段、前記タスク順序定義手段、を使用して作成された一連の手順を該業務プロセスのテンプレートとして保存する業務プロセステンプレート保存手段と、
を有することを特徴とするプロセス情報管理装置。
【請求項２】
請求項１のタスク順序定義手段は、互いに異なるタスクグループに所属する、第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義する、
ことを特徴とするプロセス情報管理装置。
【請求項３】
請求項１または請求項２の構成に加え、
タスクグループ内に存在するタスクおよびタスクグループを示す描画オブジェクトを画面上に表示するか（展開表示）、表示しないか（縮小表示）を切り換え、かつ、タスク順序定義手段で定義されたコネクタが該タスクグループに接続する場合に該コネクタの表示状態を切り換えるタスクグループ表示切換手段と、
を有することを特徴とするプロセス情報管理装置。
【請求項４】
請求項１から請求項３のいずれかの構成に加え、
第１の業務プロセステンプレート上で、第２の業務プロセステンプレートを参照として定義し、描画オブジェクトとして表示する参照業務プロセステンプレート定義手段と、
を有することを特徴とし、
タスク順序定義手段は、前記参照業務プロセステンプレートとのタスク順序を定義する、
ことを特徴とするプロセス情報管理装置。
【請求項５】
請求項１から請求項４のタスク順序定義手段は、タスク、タスクグループ、参照業務プロセステンプレート、の間に定義される複数のタスク順序のうち、特定のタスク順序の定義を優先して判断する、
ことを特徴とするプロセス情報管理装置。
【請求項６】
複数の描画オブジェクトを生成し画面上に配置する操作、描画オブジェクトの関連付けを行なう操作、描画オブジェクトの移動・複写・削除操作、が可能なグラフィカル・ユーザ・インターフェイスを備えたプロセス情報管理システムのデータ処理方法であって、
特定の業務プロセスを細分化した複数のタスクを定義し、描画オブジェクトとして表示するタスク定義工程と、
前記タスク定義工程で定義されたタスクに関連する複数の属性情報を定義するタスク属性定義工程と、
複数のタスクを分類および階層化し、描画オブジェクトとして表示するタスクグループ定義工程と、
前記タスクグループ定義工程で定義されたタスクグループに関連する複数の属性情報を定義し、該属性情報は該タスクグループに含まれる全てのタスクに共通の属性とする タスクグループ属性定義工程と、
第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義し、接続を示すコネクタを描画オブジェクトとして表示する タスク順序定義工程と、
前記タスク定義工程、前記タスク属性定義工程、前記タスクグループ定義工程、前記タスクグループ属性定義工程、前記タスク順序定義工程、を使用して作成された一連の手順を該業務プロセスのテンプレートとして保存する業務プロセステンプレート保存工程と、
を有することを特徴とするプロセス情報管理システムのデータ処理方法。
【請求項７】
複数の描画オブジェクトを生成し画面上に配置する操作、描画オブジェクトの関連付けを行なう操作、描画オブジェクトの移動・複写・削除操作、が可能なグラフィカル・ユーザ・インターフェイスを備えたプロセス情報管理システムのデータ処理方法をコンピュータに機能させるためのプログラムを記録したコンピュータ読み取り可能な記憶媒体であって、
特定の業務プロセスを細分化した複数のタスクを定義し、描画オブジェクトとして表示するタスク定義工程と、
前記タスク定義工程で定義されたタスクに関連する複数の属性情報を定義するタスク属性定義工程と、
複数のタスクを分類および階層化し、描画オブジェクトとして表示する タスクグループ定義工程と、
前記タスクグループ定義工程で定義されたタスクグループに関連する複数の属性情報を定義し、該属性情報は該タスクグループに含まれる全てのタスクに共通の属性とする タスクグループ属性定義工程と、
第１のタスクと第２のタスク間、第１のタスクグループと第２のタスクグループ間、タスクとタスクグループ間、のいずれかを実行する順序を定義し、接続を示すコネクタを描画オブジェクトとして表示するタスク順序定義工程と、
前記タスク定義工程、前記タスク属性定義工程、前記タスクグループ定義工程、前記タスクグループ属性定義工程、前記タスク順序定義工程、を使用して作成された一連の手順を該業務プロセスのテンプレートとして保存する業務プロセステンプレート保存工程と、
を有することを特徴とするプログラムを記録したコンピュータ読み取り可能な記憶媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１１−５９７７０（Ｐ２０１１−５９７７０Ａ）
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願番号】特願２００９−２０５７９９（Ｐ２００９−２０５７９９）
【出願日】平成２１年９月７日（２００９．９．７）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願日】平成２１年９月７日（２００９．９．７）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]