JP5443945B2 - プロジェクト計画装置およびプロジェクト計画プログラム - Google Patents

Description

本発明は、コンピュータを用いて複数のタスクからなるプロジェクトを計画するプロジェクト計画装置に関し、特に、制約条件の理論（Theory of Constraint；ＴＯＣ)に従ってプロジェクトを計画する際の合流バッファの挿入を自動的に行えるプロジェクト計画装置およびプロジェクト計画プログラムに関する。

ゴールドラット博士によって提唱された制約条件の理論（以下、「ＴＯＣ」とも表記する。）に従って、複数のタスク（作業）からなるプロジェクトを計画するシステムとして、下記特許文献１に記載された医療マネジメント支援システムがある。このシステムでは、サーバが、情報処理端末機からのアクセスに応じて、患者に対する一連の臨床行為をタスクとして並べ、各タスクの完了基準、所要時間、及び、リソースを設定して、クリティカルチェーン（以下、「C.C.」とも表記する。）を決定する。なお、C.C.とは、「それが遅れると全体が遅れる」というタスクをタスクの依存関係（順序関係）によって繋げたチェーンであり、ＴＯＣでいう「制約条件」に相当するものである。そして、所要時間内でタスクが完了しない場合の猶予時間として、プロジェクトのC.C.上のタスクの遅延からプロジェクトを保護するためのプロジェクトバッファと、C.C.に合流する作業又は作業群の遅延からプロジェクトを保護するためのフィーディングバッファ（合流バッファ）とを挿入して、患者毎のプロジェクトネットワーク図を作成し、情報処理端末機の表示部に表示させている。また、タスクが複数のサブタスク（子タスク）を含む場合、サブタスクの設定を可能としている（特許文献１の段落０１２６及び図３２参照）。

特開２００７−１４０６０７号公報

ところが、タスクに親子関係（階層関係）がある場合には、別々の親タスクの配下にある子タスク同士が同じリソースを必要とする場合や、ある親タスクの子タスクの成果物を他の親タスクの子タスクが利用する場合が生じ、子タスク同士で階層的には無関係であるにも係わらず依存関係が発生することがある。このように、タスクが階層関係を有する場合には、階層を跨った依存関係が発生することがあり、依存関係が複雑であるため、上記医療マネジメント支援システムを含めて従来のプロジェクト計画システムでは、適切にC.C.を決定することができないという問題があった。

本発明は、上述した問題を解決するものであり、階層関係を有するタスクを含むプロジェクトに対しても、適切にC.C.を決定することが可能なプロジェクト計画装置およびプロジェクト計画プログラムを提供することを目的とする。

本発明のプロジェクト計画装置は、入力部と表示部とを備え、制約条件の理論に従ってプロジェクトを計画するためのプロジェクト計画装置であって、タスク同士の階層関係には、子タスクを実行するためには、親タスクの全ての先行タスクが完了していなければならず、親タスクの後続タスクを実行するためには、全ての子タスクが完了していなければならない、というテクニカルな依存関係があるものにおいて、前記入力部を用いたユーザの操作に応じて、プロジェクト遂行に必要な各タスクの所要時間を示す情報、及び、各タスクの実行に必要なリソースを示す情報の入力を受けるとともに、タスク同士の順序関係を示す情報、及び、タスク同士の階層関係を示す情報の入力を受けて所定の領域に記憶しておく情報取得手段と、前記記憶しておいた所要時間を示す情報と前記リソースを示す情報と前記順序関係を示す情報と前記階層関係を示す情報とに基づいて、前記順序関係と前記階層関係とに従うように、かつ、前記階層関係における下位のタスクを持たないタスク（以下、「末端タスク」という。）間で、各タスクの実行時にそれぞれが必要とするリソースが競合するか否かを判断して、競合するものにおいては所定のルールでリソースが時間的に重複しないように、各タスクの順序を決定し、当該順序に従って各タスクを示す要素を配置した第１の工程図を作成し、前記表示部に表示する工程図作成手段と、前記階層関係における下位のタスクを持つタスク（以下、「親タスク」という。）の開始点と終了点とを仮想的なノード（以下、「仮想ノード」という。）とし、前記順序関係に基づいて、末端タスク及び仮想ノードで構成される仮想的な工程図を対象として、前記プロジェクトにおけるクリティカルチェーン上にある末端タスク及び仮想ノードを決定し、前記第１の工程図または前記第１の工程図から作成した第２の工程図の少なくとも一方に、前記クリティカルチェーン上の末端タスクを示す要素を、前記クリティカルチェーン上にない末端タスクを示す要素とは区別可能に表示するクリティカルチェーン決定手段と、を備える。

さらに、前記クリティカルチェーン上の末端タスク、及び、開始点の仮想ノードがクリティカルチェーン上にある親タスクを基点となるタスクとして、前記基点となるタスクに合流する末端タスクであって前記クリティカルチェーン上にない末端タスクを探索し、見つかった末端タスクの直後に合流バッファを設定し、当該合流バッファを示す要素を前記第１の工程図または前記第２の工程図の少なくとも一方に表示する合流バッファ設定手段を備える。

また、前記クリティカルチェーン上の末端タスクまたは前記クリティカルチェーン上の仮想ノードに合流する、末端タスクまたは仮想ノードであって前記クリティカルチェーン上にないものを探索し、見つかった末端タスク、及び、見つかった仮想ノードに対応する親タスクの開始点または終了点の直後に、合流バッファを設定し、当該合流バッファを示す要素を前記第１の工程図または前記第２の工程図の少なくとも一方に表示する合流バッファ設定手段を備えることとしてもよい。

本発明のプロジェクト計画プログラムは、制約条件の理論に従ってプロジェクトを計画するためのプロジェクト計画プログラムであって、タスク同士の階層関係には、子タスクを実行するためには、親タスクの全ての先行タスクが完了していなければならず、親タスクの後続タスクを実行するためには、全ての子タスクが完了していなければならない、というテクニカルな依存関係があるものにおいて、入力部と表示部とを備えたコンピュータを、前記入力部を用いたユーザの操作に応じて、プロジェクト遂行に必要な各タスクの所要時間を示す情報、及び、各タスクの実行に必要なリソースを示す情報の入力を受けるとともに、タスク同士の順序関係を示す情報、及び、タスク同士の階層関係を示す情報の入力を受けて所定の領域に記憶しておく情報取得手段、前記記憶しておいた所要時間を示す情報と前記リソースを示す情報と前記順序関係を示す情報と前記階層関係を示す情報とに基づいて、前記順序関係と前記階層関係とに従うように、かつ、前記階層関係における下位のタスクを持たないタスク（以下、「末端タスク」という。）間で、各タスクの実行時にそれぞれが必要とするリソースが競合するか否かを判断して、競合するものにおいては所定のルールでリソースが時間的に重複しないように、各タスクの順序を決定し、当該順序に従って各タスクを示す要素を配置した第１の工程図を作成し、前記表示部に表示する工程図作成手段、及び、前記階層関係における下位のタスクを持つタスク（以下、「親タスク」という。）の開始点と終了点とを仮想的なノード（以下、「仮想ノード」という。）とし、前記順序関係に基づいて、末端タスク及び仮想ノードで構成される仮想的な工程図を対象として、前記プロジェクトにおけるクリティカルチェーン上にある末端タスク及び仮想ノードを決定し、前記第１の工程図または前記第１の工程図から作成した第２の工程図の少なくとも一方に、前記クリティカルチェーン上の末端タスクを示す要素を、前記クリティカルチェーン上にない末端タスクを示す要素とは区別可能に表示するクリティカルチェーン決定手段、として機能させる。

さらに、前記コンピュータを、前記クリティカルチェーン上の末端タスク、及び、開始点の仮想ノードがクリティカルチェーン上にある親タスクを基点となるタスクとして、前記基点となるタスクに合流する末端タスクであって前記クリティカルチェーン上にない末端タスクを探索し、見つかった末端タスクの直後に合流バッファを設定し、当該合流バッファを示す要素を前記第１の工程図または前記第２の工程図の少なくとも一方に表示する合流バッファ設定手段として機能させる。

また、前記コンピュータを、前記クリティカルチェーン上の末端タスクまたは前記クリティカルチェーン上の仮想ノードに合流する、末端タスクまたは仮想ノードであって前記クリティカルチェーン上にないものを探索し、見つかった末端タスク、及び、見つかった仮想ノードに対応する親タスクの開始点または終了点の直後に、合流バッファを設定し、当該合流バッファを示す要素を前記第１の工程図または前記第２の工程図の少なくとも一方に表示する合流バッファ設定手段
として機能させることとしてもよい。

本発明によれば、階層関係を有するタスクを含むプロジェクトに対しても、適切にC.C.を決定することができる。

本発明の実施形態に係るプロジェクト計画装置のブロック構成図である。 同プロジェクト計画装置が行う処理のフローチャートである。 同フローチャートの続きである。 ユーザが入力した状態のネットワーク図作成画面の例である。 プロジェクトネットワーク図が表示されたネットワーク図作成画面の例である。 親タスクと子タスク及び先行タスクとの依存関係を説明するための図である。 図５の依存関係の模式図である。 図４のプロジェクトネットワーク図においてC.C.上のタスクを区別可能に表示したものである。 図７のプロジェクトネットワーク図から作成した工程表の図である。 図８の工程表において合流バッファを挿入したものである。 図７において合流バッファが必要となる部分を模式図で表したものである。 図７において合流バッファが必要となる他の部分を模式図で表したものである。 図７において合流バッファが必要となるまた他の部分を模式図で表したものである。 図８の工程表において合流バッファを、C.C.に合流する親タスクの開始点・終了点についてはその直後に挿入した図である。 依存関係が明示された階層構造を持つタスクの例である。 依存関係が明示された階層構造を持つタスクの他の例である。 依存関係が明示された階層構造を持つタスクのまた他の例である。 再帰的処理により合流バッファを挿入すべき末端タスクを探索する処理のフローチャートである。 図１７−１の処理における上位方向探索処理のフローチャートである。 図１７−２の処理における下位方向探索処理のフローチャートである。 図７のプロジェクトネットワーク図において依存関係を明示したものである。 ループ処理により合流バッファを挿入すべき末端タスクを探索する処理のフローチャートである。 図１９−１の処理における下位方向探索処理のフローチャートである。 末端タスクを説明するための図である。

以下、本発明の一実施形態を図面に基づいて説明する。

図１に示すように、実施形態のプロジェクト計画装置３は、ＴＯＣに基づいて、商品開発、建設工事、ソフトウェア開発等、種々のプロジェクトを計画するための装置であり、サーバ装置（以下、「サーバ」と略す。）１と、サーバ１に通信回線（実施形態ではイントラネット）を介して接続されることによりサーバ１と交信可能な複数のクライアント装置（以下、「クライアント」と略す。）２とから構成されている。

サーバ１は、１又は複数のコンピュータからなり、入力部１１、演算・制御部１２、記憶部１３、通信部１４、及び、表示部１５を備えている。サーバ１には、ＯＳ（オペレーティング・システム）及びそのＯＳ上で動作するＷｅｂサーバプログラムやプロジェクト管理プログラム等の各種プログラムがインストールされている。入力部１１は、キーボードやマウス等から構成されて、ユーザの操作に応じて各種情報や各種指令等を演算・制御部１２に入力する。記憶部１３は、半導体メモリ、ハードディスク装置、コンパクト・ディスク装置等から構成され、各プロジェクトのプロジェクトデータを記憶する。演算・制御部１２は、ＣＰＵ、ＣＰＵのワークエリアとなるＲＡＭ、固定データを格納したＲＯＭ等から構成されている。通信部１４は、通信回線を介してサーバ１とクライアント２を含む他のコンピュータとを接続するときのインタフェースとなる部分である。表示部１５は、液晶ディスプレイ等から構成され、演算・制御部１２からの表示命令に応じて各種の画面を表示する。

プロジェクト管理プログラムは、ユーザが入力したプロジェクト名等のデータに基づいて、プロジェクトデータを作成して記憶部１３に格納し、また、クライアント２から受信したプロジェクトの詳細データを、当該プロジェクトのプロジェクトデータに追加して記憶部１３に格納するように、サーバ装置１を機能させるプログラムである。

各クライアント２は、パーソナル・コンピュータであり、図１に示すように、入力部２１、演算・制御部２２、記憶部２３、通信部２４、及び、表示部２５を備えている。各クライアント２には、ＯＳとＷｅｂブラウザやプロジェクト計画プログラム等そのＯＳ上で動作するプログラムとがインストールされている。入力部２１は、マウス等のポインティング・デバイスやキーボード等から構成されて、ユーザの操作に応じて各種データや各種指令等を演算・制御部２２に入力するものである。記憶部２３は、半導体メモリ、ハードディスク装置、コンパクト・ディスク装置等から構成されている。演算・制御部２２は、ＣＰＵ、ＣＰＵのワークエリアとなるＲＡＭ、固定データを格納したＲＯＭ等から構成されている。通信部２４は、通信回線を介してクライアント２とサーバ１等他のコンピュータとを接続するときのインタフェースとなる部分である。表示部２５は、液晶ディスプレイ等から構成され、演算・制御部２２からの表示命令に応じて各種の画面を表示する。

プロジェクト計画プログラムは、クライアント２を、上述した情報取得手段、工程図作成手段、クリティカルチェーン決定手段、及び、合流バッファ設定手段として機能させるためのものであり、このプロジェクト計画プログラムに従って動作することにより、演算・制御部２２は、入力部２１、記憶部２３、通信部２４及び表示部２５と協働して、上述した情報取得手段、工程図作成手段、クリティカルチェーン決定手段、及び、合流バッファ設定手段として機能する。

次に、プロジェクト計画装置３の動作について、図２―１、２−２のフローチャートを用いて説明する。図２−１、２−２では、ユーザの行う操作を二点鎖線で示している。プロジェクト管理者であるユーザが、サーバ１においてプロジェクト管理プログラムを起動し、表示されたプロジェクト一覧画面（図示せず。）において、所定のボタンのクリック等、所定の操作を行うと、サーバ１は、プロジェクト名やプロジェクトリーダー名等を入力可能な新規プロジェクト作成画面（図示せず。）を表示部１５に表示する（図２−１のステップＳ１０１）。ユーザが新規プロジェクト作成画面において、プロジェクト名と、プロジェクトの開始時期及び終了時期とを入力し、所定のボタンのクリック等、所定の登録操作を行うと（Ｓ１０２）、サーバ１は、入力されたデータを含むプロジェクトデータを作成し、記憶部１３に格納する（Ｓ１０３）。

次に、プロジェクト計画者であるユーザは、クライアント２においてプロジェクト計画プログラムを起動する。すると、クライアント２は、サーバ１からプロジェクトデータを受信して、プロジェクトデータ内のプロジェクト名を選択可能に表示するプロジェクト選択画面（図示せず。）を表示部２５に表示する（Ｓ１０４、Ｓ１０５）。ユーザがプロジェクト選択画面において、プロジェクト名の選択等、所定の選択操作を行うと（Ｓ１０６）、クライアント２は、選択されたプロジェクト名を持つプロジェクトについて、プロジェクトネットワーク図を作成するためのネットワーク図作成画面（図３参照）を表示部２５に表示する（Ｓ１０７）。

〈情報取得ステップ〉図３に示すように、ネットワーク図作成画面は、タスクボックスＴ１、Ｔ２、…（区別しないときは「タスクボックスＴ」という。）等を配置することにより、プロジェクトネットワーク図を作成可能に構成されている。プロジェクトネットワークとは、プロジェクト内のタスク同士の順序関係及び階層関係を示すネットワークであり、タスクボックスＴは、プロジェクトネットワークを表したプロジェクトネットワーク図においてタスク（作業）を示す要素に相当する。

図３は、既にユーザが必要な情報を入力した状態のネットワーク図作成画面であるが、最初に表示されたネットワーク図作成画面は、プロジェクト名が表示されたゴールボックスＧが配置されるとともに、その前（左側）に、情報が未入力のタスクボックスＴが、１つ配置された状態である。ゴールボックスＧは、プロジェクトのゴール（すなわち、プロジェクトの完了期限（納期、締切り））を示すものである。

ユーザは、かかるネットワーク図作成画面において、プロジェクトの遂行に必要な各タスクについて、画面上のタスクボタン（図示せず）をクリックしてから配置位置をクリックする等、入力部２１を用いて所定の操作を行うことにより、タスクボックスＴを配置し、ゴールボックスＧまたは他のタスクボックスＴと矢印Ｙで結ぶ。なお、図面では矢印Ｙ１、Ｙ２、…と符号「Ｙ」の後に数字を付して区別しているが、これらを区別しないときは、「矢印Ｙ」という。ユーザは、ゴールボックスＧから遡るようにタスクボックスＴを配置して矢印Ｙで結んで行く。タスクボックスＴ同士を結ぶ矢印Ｙは、その両端に連結されているタスク同士の順序関係を示す情報に相当し、矢印の先端側に連結されているタスク（矢印Ｙ３、Ｙ６、Ｙ７であればタスクＴ８）の方が、矢印の基端側に連結されているタスク（矢印Ｙ３、Ｙ６、Ｙ７であれば、それぞれ、タスクＴ３、Ｔ６、Ｔ７）よりも後に実行されるものであることを示している。

図３の例で説明すれば、タスクボックスＴ８は最初から表示されているので、矢印Ｙ８でゴールボックスＧと結び、そのタスクボックスＴ８に、プロジェクトの完了直前に必要なタスク「統合テストする」についての情報を入力する。各タスクボックスＴは、そのタスクボックスＴで示されるタスクの内容（名称でもよい。）、ＩＤ（識別情報）、実行に必要な所要時間、及び、実行に必要なリソースの情報（リソース名及び数量）を入力可能に構成されており、タスクボックスＴ８では、タスクの内容「統合テストする」、所要時間として３日を示す「３ｄ」、リソースを示す情報としてリソース名「リソースＢ」とその数量「１」が入力されている。なお、リソースには、人、機械、資材等があり、したがって、リソース名としては、職種名、資格名、個人名、装置名、資材名等がある。各タスクボックスＴは、必要に応じてリソース欄Ｒが複数行設けられるように構成されている。また、所要時間は、そのタスクを完了できる可能性が５０％程度の時間とする。また、ＩＤは自動的に決定されるように構成してもよい。

次に、ユーザは、タスクボックスＴ８で示されているタスクの直前に完了しておくことが必要なタスクのタスクボックスＴを、タスクボックスＴ８の前に配置し、タスクボックスＴ８と矢印で結ぶとともに、それらのタスクボックスＴに情報を入力する。図３の例では、タスクボックスＴ３、Ｔ６、Ｔ７を配置し、それぞれ、矢印Ｙ３、Ｙ６、Ｙ７でタスクボックスＴ８と結んでいる。

一方、タスクが複数のタスクからなる場合には、前者のタスクを記載せずに後者の複数のタスクを同一階層として記載することもできるが、後者の複数のタスクの各々を子タスク、前者のタスクを親タスクとして、階層関係（親子関係）があるタスクとして記載することもできる。階層関係があるタスクとは、他のタスクを含むタスク、及び、他のタスクに含まれるタスクをいい、前者を親タスク、後者を子タスクという。親タスクとは、階層関係における下位のタスクを持つタスクであり、子タスクとは階層関係における上位のタスクを持つタスクである。図３では、例えば、タスクボックスＴ３、Ｔ３１、Ｔ３２で示されるタスクは階層関係を持ち、タスクボックスＴ３で示されるタスクは親タスク、タスクボックスＴ３１、Ｔ３２で示されるタスクはそれぞれ子タスクである。具体的には、ユーザは、入力部２１を用いて所定の操作を行うことにより、図３のタスクボックスＴ３のように、その子タスクのタスクボックスＴ３１、Ｔ３２を、親タスクのタスクボックスＴ３の下に配置する。子タスクのタスクボックスＴは、図３に示すように、図形や線（ここでは、子タスクを囲む四角形、及び、その四角形と親タスクのタスクボックスＴとを結ぶ点線）を用いて、親タスクのタスクボックスＴと連結されている。この連結のための図形や線が、タスク同士（親タスクと子タスク）の階層関係を示す情報に相当する。なお、タスクボックスＴ３１、Ｔ３２のように、同一の親タスクに含まれる子タスク同士に順序関係がある場合には、ユーザは、矢印Ｙでその順序関係を定義する。また、別々の親タスクに含まれる子タスク同士に順序関係がある場合にも、ユーザは、矢印Ｙでその順序関係を定義する。

以上のようにして、ユーザは、図３に示すようにゴールボックスＧ及び各タスクボックスＴを配置して、タスク同士の順序関係や階層関係を定義するとともに、ゴールボックスＧ及び各タスクボックスＴに必要な情報を入力した後、画面上の所定のボタンのクリック等、所定の確定操作を行う（Ｓ１０８）。

〈工程図作成ステップ〉すると、クライアント２は、入力された各タスクの所要時間を示す情報とリソースを示す情報と順序関係を示す情報と階層関係を示す情報とに基づいて、入力された順序関係を示す情報（矢印Ｙ）で示された順序関係に従うように、かつ、末端タスク間でリソースが競合しないように、タスクの順序を決定する（Ｓ１０９）。末端タスクとは、階層関係における下位のタスクを持たないタスクをいう。例えば、図２０の例では、親タスクの下位（配下）に子タスク１〜４が、子タスク３の下位に孫タスク１、２が存在しており、子タスク１、子タスク２、子タスク４、孫タスク１、及び、孫タスク２が末端タスクとなる。以下、階層関係があるタスクを、階層構造を持つタスク、階層関係がないタスクを、階層構造を持たないタスクともいう。クライアント２は、決定した順序に従って各タスクのタスクボックスＴを配置したプロジェクトネットワーク図（第１の工程図に相当。）を作成し、図４に示すように、ネットワーク図作成画面に表示する（Ｓ１１０）。

階層を有するタスクの順序関係（依存関係）について説明する。図５に示すように、子タスクを含む親タスク（以下、「グループタスク」ともいう。）がある場合、親タスクとその前後のタスク及び配下の子タスクとの間には、(1)子タスクを実行するためには、親タスクの全ての先行タスクが完了していなければならない、(2)親タスクの後続タスクを実行するためには、全ての子タスクが完了していなければならない、というテクニカルな依存関係がある。なお、ここでは、先行タスクの成果物を使用しないとそのタスクが開始できないような関係にあるとき、先行タスクとそのタスクとはテクニカルな依存関係があるという。すなわち、トポロジー的には、図６に示すように、親タスクの開始点と終了点に、サブネットワークＳを挟む仮想的なノード（イベントノード）Ｅが存在するのと同じ構造になる。

また、全く無関係な階層位置にあり、テクニカルな依存関係がないタスク同士であっても、リソースによって依存関係が発生する場合もある。図３に示す例では、互いに無関係な階層位置にあるタスクボックスＴ３１、Ｔ６１、Ｔ７２で示されるタスクが、同じ時期に同じリソースＡを必要としている。そこで、クライアント２は、タスクボックスＴ３１、Ｔ６１、Ｔ７２の順序を、所定のルールで（ここでは、プロジェクトネットワーク図において上にあるタスクボックスＴが左になるように）決定することにより、リソースの競合を解消する。すなわち、互いに無関係な階層位置にあるタスクボックスＴ３１、Ｔ６１、Ｔ７２が、同じ時期に同じリソースＡを必要とするために、互いに依存する（順序を持つ）関係となる。
このためには、各タスクの実行に必要なリソースを示す情報の入力を受けるとともに、タスク同士の順序関係を示す情報、及び、タスク同士の階層関係を示す情報の入力を受けて所定の領域に記憶しておく必要があるし、また、タスクの実行順序に関しては、各タスクの実行時にそれぞれが必要とするリソースが競合するか否かを判断して、競合するものにおいては上記ルールでリソースが時間的に重複しないように、同タスクの順序を決定する必要がある。

また、クライアント２は、タスクボックスＴ３１、Ｔ６１、Ｔ７２以外のタスクボックスＴの順序は矢印Ｙにより決定する。したがって、クライアント２は、図４に示すように、タスクボックスＴ７２より前（プロジェクトネットワーク図においては左側）にタスクボックスＴ６１が、タスクボックスＴ６１より前にタスクボックスＴ３１が配置されるように、かつ、矢印Ｙで示された順序関係が変わらないように、関係するタスクボックスＴをずらすことにより、プロジェクトネットワーク図を完成する。なお、リソースの競合による順序関係は、点線矢印で表す。

なお、図３の例では、階層関係が２階層までであったが、親タスクが子タスクを含み、その子タスクがさらに子タスク（すなわち、孫タスク）を含む等、階層関係が３階層以上ある場合にも、クライアント２は、末端タスクを対象として（すなわち、グループタスクを最下層のタスクまで展開して）、リソースが競合しているか否かを判定し、タスクボックスＴをずらすことによりその競合を解消して、プロジェクトネットワーク図を完成する。

〈クリティカルチェーン決定ステップ〉ユーザが、プロジェクトネットワーク図が表示されたネットワーク図作成画面において、所定のボタンのクリック等、所定のC.C.決定指示操作を行うと（Ｓ１１１）、クライアント２は、末端タスクを対象として、上記のように決定したタスクの順序に基づいて、C.C.を決定する（Ｓ１１２）。

C.C.（クリティカルチェーン）とは、リソースの競合を考慮して、「それが遅れると全体が遅れる」という末端タスクを繋げたチェーンであり、ＴＯＣでいう「制約条件」に相当するものである。すなわち、本実施形態では、C.C.上のタスクは末端タスクである。チェーンとは、タスク同士の依存関係（テクニカルな依存関係及びリソースによる依存関係の両方を含む。）によって順序付けられているタスクの並び（繋がり）であり、その種類として、C.C.、合流チェーンがある。合流チェーンとは、C.C.に合流する末端タスクから遡りつつ、C.C.上にない末端タスクを繋げた（すなわち、C.C.上の末端タスクにぶつかった所で若しくは先行タスクがなくなった所で終了する）チェーンをいう。なお、チェーンは、複数の末端タスクからなるものとは限らず、１つの末端タスクからなるものもある。

クライアント２は、親タスクの開始点と終了点とを仮想的なノードＥとしたときに、矢印Ｙで示される順序関係（テクニカルな依存関係）及びリソースによる依存関係に基づいて、末端タスク及びノードＥで構成される仮想的な工程図（例えば図６に示すような工程図）を対象として、ゴールから全てのチェーンをそのチェーンの最初のタスクまで遡ることにより、最も時間が長く掛かるチェーンをC.C.と判定し、C.C.上にある末端タスク及びノードＥを決定する。換言すれば、クライアント２は、末端タスクを対象として（すなわち、階層構造を持つタスクについては最下層のタスクまで分解（展開）して）、かつ、ノードＥを末端タスクと同列に扱って、ゴールから全てのチェーンをそのチェーンの最初のタスクまで遡り、最も時間が長く掛かるチェーンをC.C.と判定する。なお、最も時間が長く掛かるチェーンが複数ある場合には、所定のルールに従ってC.C.を決定する。ここでは、プロジェクトネットワーク図において上になるチェーンをC.C.とする。

このように、クライアント２は、グループタスクの開始点、終了点に相当するノードＥも末端タスクと同列に扱ってC.C.を決定し、内部的には、どのノードＥがC.C.上にあるかという情報も持っている。なお、開始点に相当するノードＥがC.C.上にあるとき、開始点がC.C.上にあるといい、終了点に相当するノードＥがC.C.上にあるとき、終了点がC.C.上にあるという。

そして、クライアント２は、図７に示すように、プロジェクトネットワーク図において、C.C.上の末端タスクのタスクボックスＴを、C.C.上にない末端タスクのタスクボックスＴとは色を変えることにより、区別可能に表示する（図２−２のステップＳ１１３）。図７では、地の部分に網掛けが施されたタスクボックスＴ１、Ｔ３１、Ｔ６１、Ｔ７２、Ｔ７３、Ｔ８が、C.C.上にあるタスクボックスＴである。

なお、親タスクのタスクボックスＴは、その開始点あるいは終了点のいずれか一方においてC.C.上にある場合には、C.C.上のタスクボックスＴと同様に色を変えて表示される。図７では、タスクボックスＴ３は開始点が、タスクボックスＴ７は終了点がC.C.上にあるため、色を変えて表示されている。

次に、ユーザが、プロジェクトネットワーク図が表示されたネットワーク図作成画面において、所定のボタンのクリック等、所定の工程表表示操作を行うと（Ｓ１１４）、クライアント２は、プロジェクトネットワーク図から工程表（第２の工程図に相当。）を作成し、図８に示すように表示部２５に表示する（Ｓ１１５、１１６）。図８の工程表は、ガントチャートと称される種類のものであり、各タスクが所要時間に応じた長さを有するバー（横棒）Ｂで表示されている。なお、図中は、バーＢ１、Ｂ２、…というように符号「Ｂ」に数字を付して区別しているが、区別しないときは「バーＢ」という。バーＢ１、Ｂ２、…は、それぞれ、タスクボックスＴ１、Ｔ２、…に対応している。また、親タスクは両端部に下向き三角形が付された黒色のバーＢで示され、C.C.上のタスクは斜め縞模様のバーＢで表示されることにより、C.C.上にないタスクとは区別可能に表示される。バーＢは、工程表においてタスクを示す要素である。また、ネットワーク図作成画面において入力されたタスク同士の順序関係は実線矢印で、タスク同士のリソースによる依存関係は点線矢印で示されている。

また、クライアント２は、図８の工程表の「ＣＣ上」と表示された欄において、各タスクがC.C.上にあるか否かを、ある場合には「True」、無い場合には「False」として示す。なお、親タスクの場合には、欄の左側にその開始点が、欄の右側にその終了点がC.C.上にあるか否かを示す。

なお、本実施形態では、図４の状態のC.C.決定前のプロジェクトネットワーク図から工程表を作成することも可能であり、その場合には、C.C.が表示されていない（斜め縞模様のバーＢ、及び、「True」、「False」の表示がない）工程表が作成されて表示される。そして、かかる工程表が表示された画面においてユーザが所定のC.C.決定指示操作を行うと、クライアント２は、プロジェクトネットワーク図においてC.C.を決定するときと同様に、C.C.を決定し、工程表に図８に示すように表示する。

〈合流バッファ設定ステップ〉次に、ユーザが、C.C.付き工程表が表示された画面において、所定のボタンのクリック等、所定のバッファ挿入指示操作を行うと（Ｓ１１７）、クライアント２は、工程表を解析して、バッファ（合流バッファとプロジェクトバッファ）の挿入位置と長さとを決定し（Ｓ１１８）、バッファが挿入された工程表を、図９に示すように表示部２５に表示する（Ｓ１１９）。バッファは下辺が上辺より短い台形で表されている。また、図中、プロジェクトバッファには符号Ｐ、合流バッファには符号Ｆ及び数字を付している。なお、合流バッファＦ１、Ｆ２、…を区別しないときは、「合流バッファＦ」という。

プロジェクトバッファＰは、プロジェクトのC.C.上のタスクの遅延からプロジェクトを保護する（すなわち、C.C.上のタスクが遅れても、プロジェクトが遅れないようにする）ための猶予時間（余裕時間）であり、ゴール直前のタスクとゴールとの間に挿入され、長さはC.C.の長さに応じて、例えば、C.C.の長さの1/2というように決定される。

また、合流バッファＦは、C.C.に合流する合流チェーンの遅延からC.C.を保護する（すなわち、C.C.に合流する合流チェーンが遅れても、C.C.が遅れないようにする）ための猶予時間であり、C.C.に合流するタスクであってそれ自身はC.C.上にないものの直後に設けられ、合流バッファＦの長さは、その合流バッファＦが挿入されるタスクが乗っている合流チェーンの長さに応じて、例えば、その合流チェーンの長さの1/2というように決定される。

ところで、階層構造を有するプロジェクトでは、親タスクの途中から階層的に無関係なタスクにC.C.が移ったり、階層的に無関係なタスクから親タスクの途中にC.C.が入ってきたりすることがある。図８の例では、バーＢ１、Ｂ３１、Ｂ６１、Ｂ７２、Ｂ７３、Ｂ８が、C.C.上のタスクを示しているが、バーＢ３で表される親タスクの途中からバーＢ６で表される親タスクにC.C.が移り、バーＢ６で表される親タスクの途中からバーＢ７で表される親タスクの途中にC.C.が移っている。すなわち、親タスクの開始点や終了点はC.C.上にないが、その子タスクがC.C.上にあるという場合があり得る。

以下、クライアント２が行う合流バッファの挿入位置の判定手法について説明する。図１０〜１２は、図７において合流バッファが必要となる部分を、親タスクの開始点と終了点に相当するノードＥを明示して、C.C.決定後の仮想的な工程図の一部として模式図で表したものである。なお、図１０〜１２では、各ノードには区別のために符号「Ｅ」の後に数字を付している。以下、「タスクボックス」を単に「タスク」ともいう。また、C.C.上のタスクＴ及びノードＥには斜め縞模様を付している。

図１０では、親タスクＴ３の開始点のノードＥ１はC.C.上にあり、タスクＴ２は、それ自身はC.C.上にないが、ノードＥ１に合流するので、タスクＴ２の直後は合流バッファの挿入箇所（合流箇所）と判断できる。また、C.C.はタスクＴ３１からタスクＴ６１に移っており、親タスクＴ３の終了点のノードＥ２は、それ自身はC.C.上にないが、C.C.上のタスクＴ８に合流していることから、ノードＥ２の直後は合流箇所と判断できる。

また、図１１では、タスクＴ３１、及び、親タスクＴ６の配下の子タスクＴ６１は、いずれもC.C.上にあるが、親タスクＴ６の開始点のノードＥ３は、それ自身はC.C.上にない。しかし、ノードＥ３は、C.C.上のタスクＴ６１に合流することから、ノードＥ３の直後は合流箇所と判断できる。また、タスクＴ６１からタスクＴ７２にC.C.が移っており、親タスクＴ６の終了点のノードＥ４は、それ自身はC.C.上にないが、C.C.上のタスクＴ８に合流していることから、ノードＥ４の直後は合流箇所と判断できる。

さらに、図１２では、タスクＴ７１は、それ自身はC.C.上にないが、C.C.上のタスクＴ７２に合流することから、タスクＴ７１の直後は合流箇所と判断できる。また、親タスクＴ７の終了点のノードＥ６はC.C.上にあり、タスクＴ７４は、それ自身はC.C.上にないが、ノードＥ６に合流することから、タスクＴ７４の直後は合流箇所と判断できる。

以上のように、親タスクの開始点及び終了点のノードＥを末端タスクと同列に扱うことにより、合流バッファＦの挿入位置を判定できる。図７のプロジェクトネットワーク図をガントチャートで表した図８の工程表において、以上のようにして合流箇所を判定し、合流バッファＦを挿入したものを、図１３に示す。図１３では、タスクＴ２を示すバーＢ２の直後に合流バッファＦ１、タスクＴ７１を示すバーＢ７１の直後に合流バッファＦ６、タスクＴ７４を示すバーＢ７４の直後に合流バッファＦ７が挿入されている。また、タスクＴ３を示すバーＢ３の終了点の直後に合流バッファＦ８、タスクＴ６を示すバーＢ６の開始点、終了点の直後にそれぞれ合流バッファＦ９、Ｆ１０が挿入されている。

図１３では、グループタスクの開始点または終了点がC.C.に合流する場合、その直後に直接合流バッファＦを挿入している。かかる図１３に示す状態の工程表を表示部２５に表示させることとしてもよいが、グループタスクの開始点と終了点は仮想的なノードＥであって、実際に稼働時間のあるタスクではないため、その直後に合流バッファＦを挿入するのは、直感的に理解し難い。そのため、本実施形態では、上述したような親タスクの開始点及び終了点のノードＥを末端タスクと同列に扱うことにより、合流バッファＦの挿入位置を判定する方法は用いず、図１３に示すような工程表も表示しない。その代わりに、クライアント２は、図１７−１〜１７−３に示すように、階層構造を持つタスクを辿ることにより、C.C.上のタスクに合流する末端タスクであってそれ自身はC.C.上にないもの（すなわち、合流バッファＦを挿入すべきタスク）を発見する。そして、そのタスクから合流先のC.C.上のタスクまで明示的に依存関係を作成し、そのタスクの直後に合流バッファＦを挿入することとする。以下、再帰的処理により末端タスクを探索して合流バッファを挿入する方法について、図１４〜１６の例、及び、図１７−１〜１７−３を用いて説明する。図１４〜１６では、図１０〜１２と同様に、C.C.上のタスクＴ及びノードＥを斜め縞模様が付された矩形で示している。

図１４に示す例は、タスクＴ１６から階層的に無関係なタスクＴ１８３にC.C.がつながっている。タスクＴ１８３は三重になった階層構造の末端タスクである。そして、タスクＴ１８３を配下に置く最も上位の親タスクＴ１８に対し、テクニカルな依存関係により先行するタスクＴ１７も、三重の階層構造を有している。このように、グループタスクは何重にも入れ子になっている可能性がある。

まず、クライアント２は、図１７−１に示すように、基点となるC.C.上のタスク（図１４の例ではタスクＴ１８３）についての〈見つかった末端タスクの一覧〉を初期化する（Ｓ２０１）。なお、基点となるC.C.上のタスク（以下、単に「基点となるタスク」ともいう。）は、C.C.上の末端タスク、及び、開始点がC.C.上にある親タスクであり、〈見つかった末端タスクの一覧〉とは、見つかった末端タスクの一覧を記憶する記憶領域を示す。次に、クライアント２は、基点となるC.C.上のタスクを対象として、上位方向に合流する末端タスクを探す処理（以下、「上位方向探索処理」という。）を行い（Ｓ２０２）、処理を終える。処理を終えたときに〈見つかった末端タスクの一覧〉に記憶されている末端タスクが、合流バッファを挿入すべきタスクとなる。

〈上位方向探索ステップ〉図１７−２に示すように、上位方向探索処理では、クライアント２は、対象としているタスク（図中〈あるタスク〉と表示。）の各先行タスクについて、下位方向に合流する末端タスクを探す処理（以下、「下位方向探索処理」という。）を行う（Ｓ３０１、３０２）。なお、先行タスクとはテクニカルな依存関係またはリソースによる依存関係により先行するタスクをいう。図１４の例では、まず、タスクＴ１８３を対象とするが、タスクＴ１８３は先行タスクＴ１６を持つため、クライアント２は、タスクＴ１６についてステップＳ３０２の下位方向探索処理を行う。下位方向探索処理では、後述するように、ステップＳ４０１で対象とするタスクが子タスクを持つか否かが判定され、タスクＴ１６は子タスクを持たないので、ステップ４０４に進んで、C.C.上にあるか否かが判定され、タスクＴ１６はC.C.上にあるので、ステップ４０４でNOと判定されて、下位方向探索処理を抜ける。そして、タスクＴ１８３は、タスクＴ１６以外に先行タスクを持たないため、ステップＳ３０４に進む。

ステップＳ３０４では、対象としているタスクが親タスクを持つか否かを判定する。そして、親タスクを持たなければ上位方向探索処理を抜けて、図１７−１に示す処理に戻って処理を終える。一方、親タスクを持っていれば、親タスクの開始点がC.C.上にあるか否かを判定し（Ｓ３０５）、C.C.上にあれば、上位方向探索処理を抜けて、図１７−１に示す処理に戻って処理を終えるが、C.C.上に無ければ、親タスクを対象として、さらに上位方向探索処理を行う（Ｓ３０６）。

図１４の例では、対象としているタスクＴ１８３は親タスクＴ１８２を持つので、クライアント２は、親タスクＴ１８２の開始点がC.C.上にあるか否かを判定し（Ｓ３０５）、親タスクＴ１８２の開始点はC.C.上に無いので、親タスクＴ１８２を対象として、さらに上位方向探索処理を行う（Ｓ３０６）。タスクＴ１８２は先行タスクを持たないので、下位方向探索処理は行わず、タスクＴ１８２の親タスクＴ１８１について、その開始点がC.C.上にあるか否かを判定し（Ｓ３０５）、C.C.上に無いので、親タスクＴ１８１を対象として、さらに上位方向探索処理を行う（Ｓ３０６）。タスクＴ１８１は、先行タスクを持たないので、下位方向探索処理は行わず、タスクＴ１８１の親タスクＴ１８について、その開始点がC.C.上にあるか否かを判定し（Ｓ３０５）、C.C.上に無いので、親タスクＴ１８を対象として、さらに上位方向探索処理を行う（Ｓ３０６）。親タスクＴ１８を対象とする上位方向探索処理では、親タスクＴ１８は先行タスクＴ１７を持っているので、クライアント２は、タスクＴ１７を対象として、下位方向探索処理を行う。

〈下位方向探索ステップ〉図１７−３に示すように、下位方向探索処理では、クライアント２は、対象としているタスクが子タスクを持つか否かを判定し（Ｓ４０１）、持つ場合には、その最後尾の各子タスクについて、下位方向探索処理をさらに行う（Ｓ４０２、４０３）。なお、最後尾の子タスクとは、同じ親タスクの直下（１つ下の階層）の子タスクの中で順序が最も遅いタスクをいい、例えば、図１６の親タスクＴ１３を対象とするときは、タスクＴ１３２、Ｔ１３４となる。一方、子タスクを持たない場合には、対象としているタスクがC.C.上にあるか否かを判定し、C.C.上に無い場合にのみ、そのタスクを〈見つかった末端タスクの一覧〉に追加する（Ｓ４０４、４０５）。

図１４の例では、下位方向探索処理において最初に対象とされるタスクＴ１７は、子タスクＴ１７１を持つので（Ｓ４０１でYES）、クライアント２は、子タスクＴ１７１を対象として、さらに下位方向探索処理を行い（Ｓ４０２、４０３）、子タスクＴ１７１は子タスクＴ１７２を持つので（Ｓ４０１でYES）、クライアント２は、子タスクＴ１７２を対象として、さらに下位方向探索処理を行い（Ｓ４０２、４０３）、子タスクＴ１７２は子タスクＴ１７３を持つので（Ｓ４０１でYES）、子タスクＴ１７３を対象として、さらに下位方向探索処理を行う（Ｓ４０２、４０３）。子タスクＴ１７３を対象とする下位方向探索処理において、子タスクＴ１７３は、子タスクを持たず（Ｓ４０１でNO）、C.C.上にないので（Ｓ４０４でYES）、クライアント２は、子タスクＴ１７３を〈見つかった末端タスクの一覧〉に追加し（Ｓ４０５）、下位方向探索処理を抜けて、上位方向探索処理に戻る。

上位方向探索処理では、クライアント２は、対象としているタスクの先行タスクで、まだ下位方向探索処理を行っていないものが存在すれば、その先行タスクについて下位方向探索処理を行い、存在しなければステップＳ３０４に進む。図１４の例では、タスクＴ１８に先行するタスクはタスクＴ１７のみであるので、クライアント２はステップＳ３０４に進む。そして、クライアント２は、ステップＳ３０４で、対象としているタスクＴ１８は親タスクを持たないと判定し、図１７−１に示す処理に戻って処理を終える。処理を終えたとき、〈見つかった末端タスクの一覧〉には、タスクＴ１７３が記憶されている。

以上のようにして、クライアント２は、合流バッファを挿入すべきタスクを取得し、取得したタスクと、基点となるC.C.上のタスクとの依存関係を明示する。図１４の例では、二点鎖線矢印に示すように、タスクＴ１７３とタスクＴ１８３との依存関係が明示される。

クライアント２は、基点となるタスクに対し、それぞれ、図１７−１〜１７−３に示す方法で、合流バッファを挿入すべきタスクを取得する。図１５に示す例では、タスクＴ１２１を基点としたとき、末端タスクＴ１０、Ｔ１１が取得される。また、図１６に示す例では、タスクＴ１５を基点としたとき、末端タスクＴ１３２、Ｔ１３４が取得される。なお、図１５、１６の二点鎖線矢印は、基点となるタスクと取得したタスクとの依存関係を明示したものである。

また、図１７−１〜１７−３に示す方法によれば、図７の例では、タスクＴ３（開始点がC.C.上にある親タスクに相当。）に対してタスクＴ２が、タスクＴ６１に対してタスクＴ４、Ｔ５が、タスクＴ７２に対してタスクＴ７１が、タスクＴ８に対してタスクＴ３２、Ｔ６２、Ｔ７４が、合流バッファを挿入すべきタスクとして取得される。クライアント２は、取得したタスクとC.C.上のタスクとの依存関係が、プロジェクトネットワーク図上で矢印Ｙで明示されていない場合には、依存関係を明示する。

図１８は、図７に示すプロジェクトネットワーク図において、合流バッファを挿入すべきタスクとして取得したタスクと、基点となるC.C.上のタスクとの依存関係を明示したものであり、図７では明示されていなかったタスクＴ４、Ｔ５とタスクＴ６１との依存関係、及び、タスクＴ３２、Ｔ６２、Ｔ７４とタスクＴ８との依存関係が二点鎖線矢印で明示されている。なお、タスクＴ２とタスクＴ３との依存関係等は、既に矢印Ｙ２等で明示されているので、二点鎖線矢印での表示は行わない。

そして、クライアント２は、上記のように取得した末端タスクの直後に合流バッファＦを挿入する。すなわち、図９に示すように、合流バッファＦ１〜Ｆ７が挿入されることとなる。図９と図１３とを比較すれば、親タスクＴ３、Ｔ６を示すバーＢ３、Ｂ６の開始点や終了点に挿入されていた合流バッファＦ８、Ｆ９、Ｆ１０が、合流バッファＦ２、Ｆ３、Ｆ４、Ｆ５に置き換えられているのが分かる。

図２−２に戻って説明すれば、ユーザがクライアント２において所定の登録操作を行うと（Ｓ１２０）、クライアント２は、ゴールボックスＧのプロジェクト名等、各タスクＴの識別情報、所要時間を示す情報、必要なリソースを示す情報、タスクＴ同士の順序関係を示す情報、タスクＴ同士の依存関係を示す情報、C.C.に関する情報（C.C.上のタスクＴやノードＥの識別情報や順序等）、及び、バッファに関する情報（プロジェクトバッファＰ及び合流バッファＦの挿入位置や長さ等）を含む詳細データを、サーバ１に送信し（Ｓ１２１）、サーバ１は、受信した詳細データを当該プロジェクトのプロジェクトデータに追加して記憶（格納）する（Ｓ１２２）。

以上説明したように、プロジェクト計画装置３は、親タスクの開始点と終了点とを仮想的なノードＥとし、矢印Ｙで示される順序関係及びリソースによる依存関係に基づいて末端タスク及びノードＥで構成される仮想的な工程図を対象として、C.C.上にある末端タスク及びノードＥを決定するので、階層構造を持つタスクを含むプロジェクトに対しても、最も時間が掛かるチェーンを適切に選び出してC.C.を決定することができる。そして、工程表にC.C.上の末端タスクを示す要素を、C.C.上にない末端タスクを示す要素とは区別可能に表示するので、ユーザにC.C.を視覚的に示すことができる。

そして、C.C.上の末端タスク、及び、開始点がC.C.上にある親タスクを、基点となるタスクとして、かかる基点となるタスクに合流する末端タスクであってC.C.上にない末端タスクを探索し、見つかった末端タスクの直後に合流バッファを設定するので、階層関係を有するタスクを含むプロジェクトに対しても、合流バッファを適切な位置に自動的に挿入することができる。例えば、図７のタスクＴ３１、Ｔ６１、Ｔ７２のように階層を跨ってC.C.が移るようなプロジェクトであっても、図９の合流バッファＦに示すように、C.C.に合流する末端タスクであってそれ自身はC.C.上にないもの（すなわち、合流チェーンの末尾の末端タスク）の直後に、合流バッファを挿入できる。

なお、上記実施形態では、再帰的処理により、合流バッファを挿入すべき末端タスクを探索したが、再帰的処理はループ処理に置換できることが一般に知られている。以下、ループ処理による合流バッファを挿入すべき末端タスクの探索方法について、図１９−１、１９−２を用いて説明する。

基点となるC.C.上のタスクは、図１７−１〜１７−３の方法と同じく、C.C.上の末端タスク、及び、開始点がC.C.上にある親タスクである。また、先行タスクの意味も、図１７−１〜１７−３の方法と同じである。まず、〈見つかった末端タスクの一覧〉を初期化し（図１９−１のステップＳ５０１）、基点となるC.C.上のタスクを、処理対象である〈あるタスク〉として処理を開始する（Ｓ５０２）。そして、あるタスクの各先行タスクについて、後述する下位方向に合流する末端タスクを探す処理（以下、「下位方向探索処理」という。）を行う（Ｓ５０４、５０５）。次に、対象としているタスクに親タスクがあり、かつ、その開始点がC.C.上にないか否かを判定し（Ｓ５０６）、ステップＳ５０６でYESであれば、対象とするタスクを、現在対象としているタスクの親タスクに置換して（Ｓ５０７）、ステップＳ５０５に戻り、NOであれば処理を終える。処理終了時に〈見つかった末端タスクの一覧〉に記憶されているタスクが、合流バッファを挿入すべき末端タスクである。

下位方向探索処理では、記憶領域〈探索対象タスクの一覧〉を初期化して、現在対象としている先行タスクを〈探索対象タスクの一覧〉に追加する（図１９−２のステップＳ６０１）。そして、〈探索対象タスクの一覧〉が空でない間、〈探索対象タスクの一覧〉から処理対象とするタスク〈対象タスク〉を１つ取り出して（Ｓ６０２、６０３）、ステップＳ６０４〜６０９で示す処理（以下、「探索ループ処理」という。）を繰り返す。

探索ループ処理では、〈対象タスク〉が子タスクを持つか否かを判定し（Ｓ６０４）、持つ場合には、その〈対象タスク〉の各子タスクについて、その子タスクがその子タスクの階層で最後尾であるか否かを判定する（Ｓ６０６）。そして、その子タスクがその子タスクの階層で最後尾である場合にのみ、その子タスクを〈探索対象タスクの一覧〉に追加する（Ｓ６０７）。一方、ステップ６０４で、〈対象タスク〉が子タスクを持たないと判定した場合には、その〈対象タスク〉がC.C.上にあるか否かを判定し（Ｓ６０８）、C.C.上にない場合にのみ、その〈対象タスク〉を〈見つかった末端タスクの一覧〉に追加する（Ｓ６０９）。

図１９−１、１９−２に示す方法は、次のように記述できる。すなわち、基点となるC.C.上のタスクを最初の対象タスクとして、対象タスクの各先行タスクについて下位方向探索処理を行い、続けて、上位方向に、開始点がC.C.上にない親タスクが続く間、親タスクを新たな対象タスクとして、各先行タスクの下位方向探索処理を繰り返す。下位方向探索処理では、初期状態で先行タスクのみを含む探索対象タスクの一覧を用意し、この一覧が空になるまで、対象タスクをひとつずつ取り出しながら、探索ループ処理を繰り返す。探索ループ処理では、対象タスクが子タスクをもたない場合は、対象タスクがC.C.上になければ、それを合流する末端タスクの一覧に含め、対象タスクが子タスクをもつ場合は、対象タスクの各子タスクについて、子タスクがその子タスクが存在する階層内で最後尾であれば、それを探索対象タスクの一覧に追加する。

以上のように、ループ処理により、合流バッファを挿入すべき末端タスクを探索することも可能である。

また、図１７−１〜１７−３に示す方法、及び、図１９−１、１９−２に示す方法のように、階層構造を持つタスクを上位方向や下位方向に辿ることにより、C.C.に合流する末端タスクであってそれ自身はC.C.上にないものを探索して、その直後に合流バッファを挿入する方法ではなく、図１０〜１２を用いて上述したように、親タスクの開始点及び終了点を仮想的なノードとして末端タスクと同列に扱うことにより、合流バッファの挿入位置を判定する方法により、図１３に示すように合流バッファＦを挿入してもよい。

すなわち、C.C.上の末端タスクまたは仮想ノードＥに合流する末端タスクまたは仮想ノードＥであってC.C.上にないものを探索し、見つかった末端タスク、及び、見つかった仮想ノードＥに対応する親タスクの開始点または終了点の直後に、合流バッファを設定し、その合流バッファを示す要素をプロジェクトネットワーク図またはガントチャートの少なくとも一方に表示してもよい（図１３参照）。この方法であっても、上述した図１７−１〜１７−３や、図１９−１、１９−２に示すような方法と同様に、階層構造を有するタスクを含むプロジェクトに対して適切な位置に合流バッファを挿入可能である。

図９と図１３とを比較すれば、上述したように合流バッファＦ３、Ｆ４が合流バッファＦ９に、合流バッファＦ２が合流バッファＦ８に、合流バッファＦ５が合流バッファＦ１０に置き換わっているが、いずれの場合でも、時間的（稼働時間的）には、C.C.に合流する末端タスクであってそれ自身はC.C.上にないタスクＴ４、Ｔ５、Ｔ３２、Ｔ６２（それぞれ、バーＢ４、Ｂ５、Ｂ３２、Ｂ６２で表されている。）の直後に合流バッファＦが挿入されている。なお、図１３によるときの合流バッファＦの長さは、合流する最も長い合流チェーンの長さに応じて決定される。

また、図１７−１〜１７−３、及び、図１９−１、１９−２を用いて説明したように、C.C.上の末端タスク及び開始点がC.C.上にある親タスクを基点となるタスクとして、基点となるタスクに合流する末端タスクであってC.C.上にない末端タスクを探索し、見つかった末端タスクの直後に合流バッファを設定する手段、及び、図１０〜１２を用いて説明したように、C.C.上の末端タスクまたはC.C.上の仮想ノードに合流する、末端タスクまたは仮想ノードであってC.C.上にないものを探索し、見つかった末端タスク、及び、見つかった仮想ノードに対応する親タスクの開始点または終了点の直後に、合流バッファを設定する手段のいずれをもクライアント２が備えるように構成し、ユーザがどちらの手段で合流バッファを挿入するかを選択可能に構成してもよい。

また、上記実施形態では、工程表（ガントチャート）にのみ合流バッファを挿入しているが、プロジェクトネットワーク図にも合流バッファを挿入するようにしてもよい。また、プロジェクトネットワーク図にはクリティカルチェーンを表示せず、工程表にのみ表示させるようにしてもよい。また、工程図として、プロジェクトネットワーク図のみ、或いは、工程表のみの実施形態も採り得る。さらに、工程図は、各タスクを示す要素を順序付けて配置することにより工程を示すものであればよく、上記のものに限られない。

また、上記実施形態では、実質的にクライアント２がプロジェクト計画装置３として構成されているが、サーバ１にもプロジェクト計画プログラムをインストールすることにより、サーバ１もプロジェクト計画装置３として構成できる。すなわち、同一のプロジェクトについて、クライアント２とサーバ１とで分担して計画することも可能である。また、作成した計画をクライアント２で修正したり、サーバ１で修正したりすることも可能である。

また、上記実施形態では、プロジェクト計画装置３をサーバ・クライアント型として構成したが、スタンドアロン型として構成してもよい。例えば、プロジェクトデータを共有する必要がない場合等には、上記ステップＳ１０５〜１２０の処理もサーバ１で行い、ステップＳ１０４及びＳ１２１の処理を無いものとすれば、サーバ１がスタンドアロン型のプロジェクト計画装置３となる。逆に、上記ステップＳ１０１〜１０３、及び、Ｓ１２２の処理もクライアント２で行うようにして、ステップＳ１０４及びＳ１２１の処理を無いものとすれば、クライアント２がスタンドアロン型のプロジェクト計画装置３となる。

１…サーバ
２…クライアント
３…プロジェクト計画装置
２１…入力部
２５…表示部
Ｅ…ノード
Ｆ…合流バッファ

Claims (8)

1. 入力部と表示部とを備え、制約条件の理論に従ってプロジェクトを計画するためのプロジェクト計画装置であって、
   タスク同士の階層関係には、子タスクを実行するためには、親タスクの全ての先行タスクが完了していなければならず、親タスクの後続タスクを実行するためには、全ての子タスクが完了していなければならない、というテクニカルな依存関係があるものにおいて、
   前記入力部を用いたユーザの操作に応じて、プロジェクト遂行に必要な各タスクの所要時間を示す情報、及び、各タスクの実行に必要なリソースを示す情報の入力を受けるとともに、タスク同士の順序関係を示す情報、及び、タスク同士の階層関係を示す情報の入力を受けて所定の領域に記憶しておく情報取得手段と、
   前記記憶しておいた所要時間を示す情報と前記リソースを示す情報と前記順序関係を示す情報と前記階層関係を示す情報とに基づいて、前記順序関係と前記階層関係とに従うように、かつ、前記階層関係における下位のタスクを持たないタスク（以下、「末端タスク」という。）間で、各タスクの実行時にそれぞれが必要とするリソースが競合するか否かを判断して、競合するものにおいては所定のルールでリソースが時間的に重複しないように、各タスクの順序を決定し、当該順序に従って各タスクを示す要素を配置した第１の工程図を作成し、前記表示部に表示する工程図作成手段と、
   前記階層関係における下位のタスクを持つタスク（以下、「親タスク」という。）の開始点と終了点とを仮想的なノード（以下、「仮想ノード」という。）とし、前記順序関係に基づいて、末端タスク及び仮想ノードで構成される仮想的な工程図を対象として、前記プロジェクトにおけるクリティカルチェーン上にある末端タスク及び仮想ノードを決定し、前記第１の工程図または前記第１の工程図から作成した第２の工程図の少なくとも一方に、前記クリティカルチェーン上の末端タスクを示す要素を、前記クリティカルチェーン上にない末端タスクを示す要素とは区別可能に表示するクリティカルチェーン決定手段と、
   を備え、
   前記クリティカルチェーン上の末端タスク、及び、開始点の仮想ノードがクリティカルチェーン上にある親タスクを、基点となるタスクとして、前記基点となるタスクに合流する末端タスクであって前記クリティカルチェーン上にない末端タスクを探索し、見つかった末端タスクの直後に合流バッファを設定し、当該合流バッファを示す要素を前記第１の工程図または前記第２の工程図の少なくとも一方に表示する合流バッファ設定手段、
   を備えることを特徴とするプロジェクト計画装置。
2. 前記合流バッファ設定手段は、
   下位方向探索処理では、
   対象としているタスクが子タスクを持つか否かを判定し、
   子タスクを持つ場合には、その同じ親タスクの１つ下の階層の子タスクの中で順序が最も遅い各子タスク（以下、「最後尾の子タスク」という。）について、当該下位方向探索処理をさらに行い、
   子タスクを持たない場合には、対象としているタスクがクリティカルチェーン上に無い場合にのみ、当該対象としているタスクを見つかった末端タスクの一覧に追加するものとし、
   上位方向探索処理では、
   対象としているタスクに対してテクニカルな依存関係またはリソースによる依存関係により先行することになる各タスク（以下、「先行タスク」という。）について、下位方向に合流する末端タスクを探す前記下位方向探索処理を行ない、
   その後、対象としているタスクが親タスクを持つか否かを判定し、親タスクを持たなければ当該上位方向探索処理を抜け、一方、親タスクを持っていれば、親タスクの開始点がクリティカルチェーン上にあるか否かを判定し、クリティカルチェーン上にあれば、当該上位方向探索処理を抜け、クリティカルチェーン上に無ければ、親タスクを対象として、さらに当該上位方向探索処理を行うものとし、かつ、
   前記合流バッファ設定手段は、
   クリティカルチェーン上の末端タスク、及び、開始点がクリティカルチェーン上にある親タスクを基点となるタスクとし、基点となるタスクを対象として、上位方向に合流する末端タスクを探す前記上位方向探索処理を行い、処理を終えたときに前記見つかった末端タスクの一覧に記憶されている末端タスクを、合流バッファを挿入すべきタスクとすることを特徴とする請求項１に記載のプロジェクト計画装置。
3. 前記合流バッファ設定手段は、
   探索ループ処理では、対象タスクが子タスクをもたない場合は、対象タスクがクリティカルチェーン上になければ、それを合流する末端タスクの一覧に含め、対象タスクが子タスクをもつ場合は、対象タスクの各子タスクについて、子タスクがその子タスクが存在する階層内で最後尾であれば、それを探索対象タスクの一覧に追加し、
   下位方向探索処理では、初期状態で先行タスクのみを含む探索対象タスクの一覧を用意し、この一覧が空になるまで、対象タスクをひとつずつ取り出しながら、前記探索ループ処理を繰り返すものとし、かつ、
   前記合流バッファ設定手段は、
   前記基点となるタスクを最初の対象タスクとして、対象タスクの各先行タスクについて前記下位方向探索処理を行い、続けて、上位方向に、開始点がクリティカルチェーン上にない親タスクが続く間、親タスクを新たな対象タスクとして、各先行タスクの前記下位方向探索処理を繰り返すことにより、前記合流バッファを挿入すべき末端タスクを探索することを特徴とする請求項１に記載のプロジェクト計画装置。
4. 前記合流バッファ設定手段は、
   前記クリティカルチェーン上の末端タスクまたは前記クリティカルチェーン上の仮想ノードに合流する、末端タスクまたは仮想ノードであって前記クリティカルチェーン上にないものを探索し、見つかった末端タスク、及び、見つかった仮想ノードに対応する親タスクの開始点または終了点の直後に、合流バッファを設定し、当該合流バッファを示す要素を前記第１の工程図または前記第２の工程図の少なくとも一方に表示することが可能であることを特徴とする請求項１に記載のプロジェクト計画装置。
5. 制約条件の理論に従ってプロジェクトを計画するためのプロジェクト計画プログラムであって、タスク同士の階層関係には、子タスクを実行するためには、親タスクの全ての先行タスクが完了していなければならず、親タスクの後続タスクを実行するためには、全ての子タスクが完了していなければならない、というテクニカルな依存関係があるものにおいて、入力部と表示部とを備えたコンピュータを、
   前記入力部を用いたユーザの操作に応じて、プロジェクト遂行に必要な各タスクの所要時間を示す情報、及び、各タスクの実行に必要なリソースを示す情報の入力を受けるとともに、タスク同士の順序関係を示す情報、及び、タスク同士の階層関係を示す情報の入力を受けて所定の領域に記憶しておく情報取得手段、
   前記記憶しておいた所要時間を示す情報と前記リソースを示す情報と前記順序関係を示す情報と前記階層関係を示す情報とに基づいて、前記順序関係と前記階層関係とに従うように、かつ、前記階層関係における下位のタスクを持たないタスク（以下、「末端タスク」という。）間で、各タスクの実行時にそれぞれが必要とするリソースが競合するか否かを判断して、競合するものにおいては所定のルールでリソースが時間的に重複しないように、各タスクの順序を決定し、当該順序に従って各タスクを示す要素を配置した第１の工程図を作成し、前記表示部に表示する工程図作成手段、
   及び、
   前記階層関係における下位のタスクを持つタスク（以下、「親タスク」という。）の開始点と終了点とを仮想的なノード（以下、「仮想ノード」という。）とし、前記順序関係に基づいて、末端タスク及び仮想ノードで構成される仮想的な工程図を対象として、前記プロジェクトにおけるクリティカルチェーン上にある末端タスク及び仮想ノードを決定し、前記第１の工程図または前記第１の工程図から作成した第２の工程図の少なくとも一方に、前記クリティカルチェーン上の末端タスクを示す要素を、前記クリティカルチェーン上にない末端タスクを示す要素とは区別可能に表示するクリティカルチェーン決定手段、
   として機能させるとともに、
   前記クリティカルチェーン上の末端タスク、及び、開始点の仮想ノードがクリティカルチェーン上にある親タスクを基点となるタスクとして、前記基点となるタスクに合流する末端タスクであって前記クリティカルチェーン上にない末端タスクを探索し、見つかった末端タスクの直後に合流バッファを設定し、当該合流バッファを示す要素を前記第１の工程図または前記第２の工程図の少なくとも一方に表示する合流バッファ設定手段
   として機能させることを特徴とするプロジェクト計画プログラム。
6. 前記コンピュータが前記合流バッファ設定手段として機能可能であり、さらに、当該合流バッファ設定手段は、
   下位方向探索処理では、
   対象としているタスクが子タスクを持つか否かを判定し、
   子タスクを持つ場合には、その同じ親タスクの１つ下の階層の子タスクの中で順序が最も遅い各子タスク（以下、「最後尾の子タスク」という。）について、当該下位方向探索処理をさらに行い、
   子タスクを持たない場合には、対象としているタスクがクリティカルチェーン上に無い場合にのみ、当該対象としているタスクを見つかった末端タスクの一覧に追加するものとし、
   上位方向探索処理では、
   対象としているタスクに対してテクニカルな依存関係またはリソースによる依存関係により先行することになる各タスク（以下、「先行タスク」という。）について、下位方向に合流する末端タスクを探す前記下位方向探索処理を行ない、
   その後、対象としているタスクが親タスクを持つか否かを判定し、親タスクを持たなければ当該上位方向探索処理を抜け、一方、親タスクを持っていれば、親タスクの開始点がクリティカルチェーン上にあるか否かを判定し、クリティカルチェーン上にあれば、当該上位方向探索処理を抜け、クリティカルチェーン上に無ければ、親タスクを対象として、さらに当該上位方向探索処理を行うものとし、かつ、
   前記合流バッファ設定手段は、
   クリティカルチェーン上の末端タスク、及び、開始点がクリティカルチェーン上にある親タスクを基点となるタスクとし、基点となるタスクを対象として、上位方向に合流する末端タスクを探す前記上位方向探索処理を行い、処理を終えたときに前記見つかった末端タスクの一覧に記憶されている末端タスクを、合流バッファを挿入すべきタスクとすることを特徴とする請求項５に記載のプロジェクト計画プログラム。
7. 前記コンピュータが前記合流バッファ設定手段として機能可能であり、さらに、当該合流バッファ設定手段は、
   探索ループ処理では、対象タスクが子タスクをもたない場合は、対象タスクがクリティカルチェーン上になければ、それを合流する末端タスクの一覧に含め、対象タスクが子タスクをもつ場合は、対象タスクの各子タスクについて、子タスクがその子タスクが存在する階層内で最後尾であれば、それを探索対象タスクの一覧に追加し、
   下位方向探索処理では、初期状態で先行タスクのみを含む探索対象タスクの一覧を用意し、この一覧が空になるまで、対象タスクをひとつずつ取り出しながら、前記探索ループ処理を繰り返すものとし、かつ、
   前記合流バッファ設定手段は、
   前記基点となるタスクを最初の対象タスクとして、対象タスクの各先行タスクについて前記下位方向探索処理を行い、続けて、上位方向に、開始点がクリティカルチェーン上にない親タスクが続く間、親タスクを新たな対象タスクとして、各先行タスクの前記下位方向探索処理を繰り返すことにより、前記合流バッファを挿入すべき末端タスクを探索することを特徴とする請求項５に記載のプロジェクト計画プログラム。
8. 前記コンピュータが前記合流バッファ設定手段として機能可能であり、さらに、当該合流バッファ設定手段は、
   前記クリティカルチェーン上の末端タスクまたは前記クリティカルチェーン上の仮想ノードに合流する、末端タスクまたは仮想ノードであって前記クリティカルチェーン上にないものを探索し、見つかった末端タスク、及び、見つかった仮想ノードに対応する親タスクの開始点または終了点の直後に、合流バッファを設定し、当該合流バッファを示す要素を前記第１の工程図または前記第２の工程図の少なくとも一方に表示することを特徴とする請求項５記載のプロジェクト計画プログラム。

Images