JP2010067039A - プロジェクト管理システム及びプログラム - Google Patents

Abstract

【課題】プロジェクト管理システムにおける管理者の負担を減らし、精度の高い進捗管理を可能にするとともに、作業者による作業状態の変更を検出し、プロジェクト管理者に通知できるようにする。
【解決手段】作業工程状態変更検出サーバー２は、作業が開始されている作業工程に依存している、先行作業工程の状態変更を検出する機能と、その検出結果を利用者５に知らせる機能を持っている。利用者５が端末装置４を用いて工程状態管理サーバー３に変更コマンドを送信すると、その直前で作業工程状態変更検出サーバー２が送信されるコマンドを監視している。作業工程状態変更検出サーバー２は、工程状態の変更を検出し、それが関連工程の状態に関わるものであれば、その変更をメールで管理者に伝える。
【選択図】 図１

Description

本発明は、コンピュータによりプロジェクトの進行管理のサポートを行うためのプロジェクト管理システム 、及びそのシステムをコンピュータにより実現するプログラムに関する。

一般にプロジェクト管理システムでは、プロジェクト全体の仕事（もしくは成果物）を、その仕事を構成する細かな作業工程（もしくは中間成果物）に別けて記述し（これをＷＢＳ：Work Breakdown Structureと呼ぶ）、また、その各々の作業工程の間の依存関係（例えば、ある作業工程は別の作業工程が終了するまで開始できない等）を定義することによってプロジェクト全体を管理する。

ＷＢＳとは、プロジェクトの計画を立てる際に、実施されなければならない全ての作業を洗い出し、またプロジェクトの管理単位を明確化するために広く用いられている手法、もしくは結果として得られるプロジェクトの構成図表であり、工数の見積りや作業の分担、日程計画（ガントチャート、ネットワーク図など）、予算/コスト管理、リスク管理、進捗管理といったものに使われ、プロジェクト管理全体の基礎となるものである。

ＷＢＳでは、まずプロジェクトの成果物もしくは仕事を、大きな単位からできるだけ細かな単位へと分割していき、これによりプロジェクトをツリーのような階層に構造化していく。ＷＢＳにおける重要な指標が「１００パーセントルール」である。このルールは「次の分解レベル（子供のレベル）は、親の要素の全ての作業を表してなければならない」といったもので、この指標に従ってプロジェクトを記述することにより、必要な全ての作業が包括されていることが保証される。

ＷＢＳの最下層のレベルの要素はプロジェクト実施の際の管理単位となる。これらはワークパッケージと呼ばれ、通常最小の成果物を表しているが、成果物が管理単位として大きすぎる場合には、さらにそれら成果物を得るための作業（タスク、アクティビティ）へと細分化される場合もある。全ての作業が定義されると、各々の管理単位に資源（所要時間や担当者、予算）を割り当て、これによりプロジェクトを定量的に管理する事が可能となる。

図３３にＷＢＳによってプロジェクトを作業工程へと分割した例を示す。各作業工程は必要であればさらに細かなレベルの作業工程へと完全に分解される。ここで、分解されていない作業工程を特に「端点作業工程」（図中太枠の作業工程）、また分解された下位のレベルの作業工程の概要を表す作業工程を特に「概要作業工程」と呼ぶ。

図３４に図３３のＷＢＳによるプロジェクトの作業工程への分解結果を、分解のレベル毎に階層的に書き表したものを示す。分解結果は図のようにプロジェクト・仕事を根（ルート）とした木（ツリー）構造をなす。この場合、節の部分に位置する作業工程が「概要作業工程」であり、葉の部分に位置する作業工程が「端点作業工程」となる。

プロジェクト管理における特に重要な要素の一つに進捗管理が挙げられる。基本的には個々の作業工程の進捗状況を計測し、それらを総合的に判断することによってプロジェクト全体の進捗状況が判断される。従って、精度良くプロジェクトの進捗を管理するためには、個々の作業工程の進捗状況を正確に計測することが必要となり、そのために様々な方法が提案されている。

例えば、ＭＳ−Projectでは、各作業工程（ＭＳ−Projectではタスクと呼ばれる）の担当者が、その作業工程の主観的な進捗度（作業開始前を０％、作業完了を１００％とした百分率）を入力する方法を用いており、多くのシステムが類似の方法を採用している。

また特許文献に記載されたものとしては、プロジェクトで作成される文書の作成状況により進捗を管理するもの（特許文献１）、プロジェクトの成果物の作成状況によって管理するもの（特許文献２）、重要度に応じた点数と移行のための許可条件とを組み合わせて管理するもの（特許文献３）、定型フォーマット化された業務報告から進捗データを得るもの（特許文献４）、実績の承認状態の情報によって管理するもの（特許文献５）などが知られている。

上述の通り、一般的にプロジェクトにおける各作業工程には依存関係があり、プロジェクト管理システムでは、プロジェクトの計画時にＷＢＳを作成するとともに各作業工程の間の依存関係も定義できるようになっている。例えば、ある作業工程Ｂを行うためには別の作業工程Ａの結果が必要であり、従って作業工程Ａが完了するまで作業工程Ｂを開始できない場合がこれに該当する。この例では、作業工程Ｂは作業工程Ａに依存しており、作業工程Ａを先行作業工程、作業工程Ｂを後続作業工程と呼ぶ。また、先行作業工程が完了するまで後続作業工程を開始できないような依存関係をＦ−Ｓ（Finish−Start）関係、先行作業工程が開始するまで後続作業工程も開始できないような依存関係をＳ−Ｓ（Start−Start）関係と呼ぶ。

図３５は図３４に依存関係の例を加えたものである。この図では矢印が依存関係を表しており、矢印の開始点にある作業工程が依存する側（後続作業工程）、矢印の指し示している先が依存される側（先行作業工程）を表している。また、矢印に付けられている「Ｆ」又は「Ｓ」の文字は依存の種類を表し、「Ｆ←Ｓ」はＦ−Ｓ関係を、「Ｓ←Ｓ」はＳ−Ｓ関係を表している。

依存関係を理解しやすくするために、図３５をさらに図３６のように棒チャート（一般的にはガントチャートと呼ばれる）で書き換える。ここで、横軸が時間（左から右へ行く程過去から未来を表す）、各作業工程の長さは、その作業工程に要する時間的な工数を表している。

先行作業工程のある作業工程においては、その工程が開始されていない理由が（１）先行作業工程（もしくはそのさらに先行作業工程）が終了（Ｆ−Ｓ関係の場合）もしくは開始（Ｓ−Ｓ関係の場合）されていないために、その工程を「開始できない」のか、（２）単にその工程の実施担当者が多忙などの理由により「開始していない」だけなのか、といった二つの場合がある。もし、プロジェクトに計画遅れが生じ作業工程毎に対策が必要になった場合、上記それぞれの場合において管理者の対処方法も異なってくる。つまり、適切な対処を行うためには作業工程毎に依存関係とその種別及び先行作業工程の状態を把握する必要が生じてくる。

大規模なプロジェクトではＷＢＳの階層も深くなり、作業工程の数が数百にものぼるし、また一つの作業工程が複数の別の作業工程に依存していることも普通であることから、ある作業工程からすべての先行作業工程を辿って状態を確認することは大変に手間がかかり、場合によっては非常に困難である。

上述の従来技術はいずれも各作業工程が開始された後の進捗状況は把握できるが、プロジェクト全体もしくはより上位のＷＢＳの階層レベルで作業工程を俯瞰した場合の状態が容易には把握できない。また、前述のように作業工程がまだ開始されていない場合、その作業工程の担当者以外が、何故その作業工程が開始されていないのかを把握するのは困難である。従って、仮にプロジェクトのいずれかの作業工程で問題が発生していても、管理者はもちろん作業担当者も適切な対応を迅速に行うことが困難となっている。

また、多くのプロジェクト管理システムは、その基本構成要素であるタスクの状態を、各作業者に入力させるものが殆どである。このような場合、作業者が悪意を持って、あるいは過失により、タスク状態を変更した場合、誰が変更したか分からない可能性が高い。また、管理者１人がタスク状態を入力しているような場合も、タスクの数が多くその構成も複雑な場合、やはり過失により操作ミスを犯し、変更すべきではないタスクの状態を変更してしまい、それに気付かない可能性がある。変更されたタスク状態が"完了"或いは"中止"の場合、後工程で作業中の作業が即座に"待ち"の状態になり、プロジェクトそのものの状態が巻き戻ってしまう。

特開２００３−１０８７３５号公報 特開２００３−６７１８８号公報 特開２００３−６３９９号公報 特開２００５−１４８９３３号公報 特開平１１−２５０１２５号公報

本発明は、このような問題を解決するためになされたもので、その目的は、複数の作業工程及び各作業工程間の依存関係によってプロジェクトを表現するとともに、各作業工程の進捗状態によってプロジェクトを管理するプロジェクト管理システムにおける管理者の負担を減らし、精度の高い進捗管理を可能にするとともに、作業者による作業状態の変更を検出し、プロジェクト管理者に通知できるようにすることである。

本発明は、複数の作業工程及び各作業工程間の依存関係によってプロジェクトを表現するとともに、各作業工程の進捗状態によってプロジェクトを管理するプロジェクト管理システムであって、各作業工程の状態をその作業工程が依存している別の作業工程の状態に応じて求める手段と、作業が開始されている作業工程に依存している、先行作業工程の状態変更を検出する先行作業工程状態変更検出手段と、前記先行作業工程状態変更検出手段の検出結果を通知する状態変更通知手段とを有することを特徴とするプロジェクト管理システムである。

本発明によれば、プロジェクト管理システムにおける管理者の負担を減らし、精度の高い進捗管理を行えるとともに、作業者による作業状態の変更を検出し、プロジェクト管理者に通知することができる。

以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
図１は、本発明の第１の実施形態のプロジェクト管理システムの構成を示す図である。このプロジェクト管理システムは、作業工程状態変更検出サーバー２と、工程状態管理サーバー３と、利用者（担当者、管理者）５が操作可能な複数の端末装置（パーソナルコンピュータなど）４とを備え、作業工程状態変更検出サーバー２及び端末装置４がネットワーク１に接続されている。

本実施形態では、作業工程毎の進捗を示す属性（例えば、進捗度合を示す百分率の値など）の他に、作業工程の状態を定義し、システムが自動的に状態を遷移させることにより、作業担当者や管理者が適切な対応をとれるようにした。

作業工程の状態として「開始可能」、「待ち」、「作業中」、「完了」、及び「中止」を定義し、各作業工程は必ずいずれかの状態をとるようにする。例えば各状態における端点作業工程の担当者の取るべき対応は以下の通りである。

開始可能：その作業工程は開始できる状態なので、できるだけ早く作業を始める。
待ち：作業工程は開始できないので、状態が「開始可能」へと遷移するまで待つ。状態が「開始可能」に遷移した際にすぐに作業を開始できるように、必要であれば準備しておく。また、必要であれば先行作業工程の担当者に働きかけて、その作業工程の進行を促す。
作業中：作業を進めて、予定通り作業を終わらせるようにする。
完了、中止：作業は既に終了しているので、通常、担当者がこの作業工程を気にする必要は無い。

また、同様に上位レベルの作業工程（概要作業工程）及び最上位のプロジェクトの担当者（通常はその下位にある作業工程の管理者やプロジェクト管理者）の取るべき対応は以下の通りになる。

開始可能：下位に開始が可能となっている作業工程がある。該当作業工程について、できるだけ早く作業が開始されるように担当者に開始を促す指示を与える。
待ち：下位に開始可能な作業工程は存在しない。状態が「開始可能」へと遷移するまで待つ。状態が「開始可能」に遷移した際にすぐに作業を開始できるように、下位の作業工程の担当者に必要であれば準備するように指示しておく。
作業中：作業を進行中である。予定通り作業が終わるように、該当する作業工程とその担当者に注意を払う。
完了、中止：下位レベルの作業は既に全て終了しているので、通常、担当者がこの作業工程を気にする必要は無い。

端点作業工程の状態を決定するための規則の例を以下のア〜オに示す。
ア：端点作業工程が新しく作られた際、状態は「開始可能」になる。
イ：各端点作業工程の担当者は、状況に応じて作業工程の状態を変更する。
− 作業工程が開始された場合、状態を「作業中」に変更する。
− 作業工程が完了した場合、状態を「完了」に変更する。
− 作業工程が完了することなく途中で終了された場合、状態を「中止」に変更する。
ウ：状態が「開始可能」な端点作業工程に依存先（先行作業工程）がある場合、もしくは上位に位置する一つ以上の概要作業工程に依存先（先行作業工程）がある場合で、以下のような先行作業工程が一つでも存在している場合、端点作業工程の状態はシステムにより自動的に「待ち」に設定される。・・・ａ
− 依存関係がＦ−Ｓ関係で、その状態が「待ち」、「開始可能」、「作業中」のいずれかの先行作業工程。
− 依存関係がＳ−Ｓ関係で、その状態が「待ち」、「開始可能」のいずれかの先行作業工程。
エ：状態が「待ち」の端点作業工程に依存先（先行作業工程）がある場合、もしくは上位に位置する一つ以上の概要作業工程に依存先（先行作業工程）がある場合で、以下のような先行作業工程が一つも存在しなくなった場合、端点作業工程の状態はシステムにより自動的に「開始可能」に設定される。・・・ｂ
− 依存関係がＦ−Ｓ関係で、その状態が「待ち」、「開始可能」、「作業中」のいずれかの先行作業工程。
− 依存関係がＳ−Ｓ関係で、その状態が「待ち」、「開始可能」のいずれかの先行作業工程。
オ：もし端点作業工程の状態が、担当者により既に「作業中」、「完了」、「中止」のいずれかに設定されている場合には、システムによって自動的に状態が変更されることはない。

以上の規則に対応した状態遷移図を図２に示す。この図において、太い実線の矢印は全ての作業工程についてのシステムによる自動遷移を示し、点線の矢印は依存している作業工程についてのシステムによる自動遷移を示す。また、細い実線の矢印は担当者の操作による遷移を示す。各端点作業工程は初期状態では「開始可能」であり、担当者は作業を開始して状態を手動で「作業中」へと変更する。また、作業開始前に当該端点作業工程もしくはその上位レベルの依存関係が設定された場合、先行作業工程の状態及び上述した規則に従って当該端点作業工程の状態がシステムによって自動設定される。

概要作業工程の状態を決定するための規則の例を以下に示す。
概要作業工程の状態は以下の条件カ〜コに従って、常にシステムによって自動的に設定される。担当者が手動で状態を変更することはできない。
カ：「待ち」状態
；下位に少なくとも一つの「待ち」状態の作業工程があり、かつ下位に「開始可能」及び「作業中」状態の作業工程が一つもない場合、概要作業工程はシステムにより自動的に「待ち」状態に設定される。
キ：「開始可能」状態
− 下位に少なくとも一つの「開始可能」状態の作業工程があり、かつ下位に「作業中」状態の作業工程が一つもない場合、概要作業工程はシステムにより自動的に「開始可能」状態に設定される。
ク：「作業中」状態
− 下位に少なくとも一つの「作業中」状態の作業工程がある場合、概要作業工程はシステムにより自動的に「作業中」状態に設定される。
ケ：「完了」状態
− 全ての下位の作業工程の状態が「完了」もしくは「中止」で、かつ少なくともそのうち一つの状態が「完了」である場合、概要作業工程はシステムにより自動的に「完了」状態に設定される。
コ：「中止」状態
− 全ての下位の作業工程の状態が「中止」である場合、概要作業工程はシステムにより自動的に「中止」状態に設定される。

例として、図３６のプロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを、図３〜図１７に時系列で示す。

最初は図３に示すように、端点作業工程では「作業工程（小）その６」のみ「開始可能」であり、その他は「待ち」である。従って、概要作業工程では「作業工程（小）その６」の上位の「作業工程（大）その２」のみ「開始可能」であり、「プロジェクト・仕事」も開始可能である。

「作業工程（小）その６」が開始されると、図４に示すように、「作業工程（小）その６」、「作業工程（大）その２」、及び「プロジェクト・仕事」が「作業中」に変化する。

「作業工程（小）その６」の作業が完了すると、図５に示すように、「作業工程（小）その６」が「完了」に変化するとともに、「作業工程（小）その６」とＦ−Ｓ関係を持つ「作業工程（小）その１」が「開始可能」に変化するとともに、その上位の概要作業工程である「作業工程（中）その１」、さらに上位の「作業工程（大）その１」、及び「プロジェクト・仕事」が「開始可能」に変化する。

「作業工程（小）その１」が開始されると、図６に示すように、「作業工程（小）その１」、「作業工程（中）その１」、「作業工程（大）その１」、及び「プロジェクト・仕事」が「作業中」に変化するとともに、「作業工程（小）その１」とＳ−Ｓ関係を持つ「作業工程（小）その２」が「開始可能」に変化する。「作業工程（小）その２」が開始されると、図７に示すように、「作業工程（小）その２」が「作業中」に変化する。

次に図８に示すように、「作業工程（小）その１」より早く「作業工程（小）その２」が完了し、その後、図９に示すように、「作業工程（小）その１」が完了する。「作業工程（小）その１」が「完了」に変化すると、「作業工程（中）その１」は「待ち」に変化する。また、「作業工程（小）その１」とＦ−Ｓ関係を持つ「作業工程（中）その２」、及び既に完了した「作業工程（小）その６」とＦ−Ｓ関係を持つ「作業工程（小）その４」が「開始可能」に変化する。また、上位の「作業工程（大）その１」、「プロジェクト・仕事」も「開始可能」に変化する。

「作業工程（小）その４」及び「作業工程（中）その２」が開始されると、図１０に示すように、それらが「作業中」に変化するとともに、上位の「作業工程（大）その１」、「プロジェクト・仕事」が「作業中」に変化する。

以後、「作業中」の作業工程が完了すると、その作業工程にＦ−Ｓ関係を有する作業工程が順次「開始可能」→「作業中」→「完了」に変化することで、図１７に示すように、全ての作業工程が完了する。

次に作業者がタスクの状態を変化させた場合の動作について説明する。
図１８にタスクの関係を示す。タスクＴがルートとなるタスクである。各タスクの持っているサブタスクは以下の通りである。
Ｔ：Ｔ１，Ｔ２、Ｔ１：Ｔ１１，Ｔ１２、Ｔ１１：Ｔ１１１，Ｔ１１２，Ｔ１１３、Ｔ１２：Ｔ１２４，Ｔ１２５、Ｔ２：Ｔ２０１，Ｔ２０２

タスクＴ，Ｔ１，Ｔ２，Ｔ１１，Ｔ１２，Ｔ１１１，Ｔ１１２，Ｔ１１３，Ｔ１２４，Ｔ１２５，Ｔ２０１，Ｔ２０２は、それぞれ図３の「プロジェクト・仕事」、「作業工程（大）その１」、「作業工程（大）その２」、「作業工程（中）その１」、「作業工程（中）その２」、「作業工程（小）その１」、「作業工程（小）その２」、「作業工程（小）その３」、「作業工程（小）その４」、「作業工程（小）その５」、「作業工程（小）その６」、「作業工程（小）その７」に対応する。

図１９にタスクメタデータテーブルを示す。このテーブルは、タスクＩＤ、変更時上位通知フラグ、前工程タスクＩＤ、上位タスクＩＤ、及び担当者メールアドレスからなり、工程状態管理サーバー３に保存されている。また、工程状態管理サーバー３には、各作業工程の現在の状態を示すテーブルも保存されている。

図２０にコマンドの一例を示す。コマンドの形式はコマンド種別、対象タスクＩＤ、及びパラメータからなる。このコマンドはタスクの状態を変更する際に作業者の手により発行されるものであり、図の例はタスクＩＤがＴ１１２のタスクを"完了"の状態に変更するものである。各タスクに関連（ここでは依存関係）するタスクとして、ここでは上位タスクを指定している。また、タスクの状態としては、Ｔ２０１とＴ１１１が"完了"、Ｔ１１２とＴ１２４が"作業中"、その他は"待ち"である。

図２１は、タスク状態を変更するコマンドが発行された場合の作業工程状態変更検出サーバー２の動作を示すフローチャートである。このフローは、作業工程状態変更検出サーバー２内の記憶媒体に記憶されているコンピュータプログラムに基づいて実行される。

作業工程状態変更検出サーバー２は、作業が開始されている作業工程に依存している、先行作業工程の状態変更を検出する機能と、その検出結果を利用者に知らせる機能を持っている。利用者５が端末装置４を用いて工程状態管理サーバー３に変更コマンドを送信すると、その直前で作業工程状態変更検出サーバー２が送信されるコマンドを監視している。図１８のＴ１１１が完了状態にあるとき、利用者５が端末装置４からコマンド"ＣＨＧ，Ｔ１１１，作業中"を送信したとする。作業工程状態変更検出サーバー２はコマンドから対象タスクＩＤ（Ｔ１１１）、パラメータ（作業中）を取り出し、図２１に示すフローを実行する。

まずステップＳ１で、タスクメタデータテーブル（図１９）を参照して、変更時上位通知フラグ（ここでは"１"）と上位タスクＩＤ（ここでは"Ｔ１１"）を取得する。次いでステップＳ２で、上位タスクＩＤ"Ｔ１１"を対象タスクＩＤとし、ステップＳ３で、変更時上位通知フラグが"１"か否か調べる。

ここでは"１"であるから、ステップＳ４に進み、対象タスクＩＤがタスクＩＤと一致する行をタスクメタデータテーブルより取得する。ここでは、上から２行目が取得される。次いでステップＳ５に進み、取得された行の担当者メールアドレス（ここでは"admin1@abc.com"）に、下記の変更通知メールを送信する。
Title：タスク状態変更通知、本文：タスクＩＤ；Ｔ１１１、"作業中"に変更されました。

このように１回目のステップＳ３〜Ｓ５のループの実行では、タスクＩＤ：Ｔ１１の管理者である"admin1@abc.com"宛に変更通知メールが送信される。同様に、次回（２回目）のステップＳ３〜Ｓ５のループの実行では、タスクＩＤ：Ｔ１の管理者である"admin@abc.com"宛に変更通知メールが送信される。

本実施形態のプロジェクト管理システムによれば、プロジェクト全体もしくはより上位のＷＢＳの階層レベルで作業工程を俯瞰した場合の状態を容易に把握することができる。また、作業工程がまだ開始されていない場合、その作業工程の担当者以外が、何故その作業工程が開始されていないのかを容易に把握することができる。これにより、仮にプロジェクトのいずれかの作業工程で問題が発生していても、管理者及び作業担当者は適切な対応を迅速に行うことができる。従って、プロジェクト管理システムにおける管理者の負担を減らし、精度の高い進捗管理を行うことができる。

また、本実施形態のプロジェクト管理システムによれば、タスク状態の変更を検出し、それが関連工程（ここでは依存関係を有する工程）の状態に関わるものであれば、その変更を管理者に伝えることができる。また、タスク状態の変更をメールで通知することによって、作業者が作業場所を選ばずにタスク状態変更通知を受信することができる。

［第２の実施形態］
図２２は、本発明の第２の実施形態のプロジェクト管理システムの構成を示す図である。この図において、図１と同一又は対応する構成要素には図１で使用した参照符号を付した。

このプロジェクト管理システムは、第１の実施形態のプロジェクト管理システムに対し、作業工程状態変更管理サーバー６を付加したものである。作業工程状態変更管理サーバー６は、作業工程状態変更検出サーバー２から変更の検出を通知されると、変更内容によって変更予定を記録する機能を持っている。

図２３は、利用者５が端末装置４を操作して、タスク状態を変更する場合のシステムの動作を示すフローチャート（タスク変更申請書作成処理フロー）である。このフローにおいて、［ ］内の動作は利用者５の操作である。また、図２４は図２３のフローに対応するシーケンス図である。

図１８のタスクＴ１１１が"完了"状態にあるとき、利用者５がＴ１１１の状態を"作業中"に変更したいとする。利用者５は端末装置４を操作して、図２５Ａに示されているように、変更申請書作成画面を開き（図２３のステップＳ１０）、変更対象タスクＩＤを記入した後に"作成"ボタンを押下する（ステップＳ１１）。

ステップＳ１２で、端末装置４は、作業工程状態変更検出サーバー２を介して作業工程状態管理サーバー３内のテーブルを参照し、対象タスクＩＤ（ここではＴ１１１）の現在の状態（メタ情報）を取得し、ステップＳ１３で、"完了"もしくは"中止"か否か調べる。

"完了"もしくは"中止"の場合は、ステップＳ１４に進み、対象タスクＩＤを基にタスクメタデータテーブルの変更時上位通知フラグを取得し、ステップＳ１５で、変更時上位通知フラグが"１"か否か調べる。

ここで、図１９に示されているように、タスクＴ１１１の変更時上位通知フラグが"１"である場合は、ステップＳ１６に進み、申請者メールアドレス、変更後の状態、理由入力ボックスを端末装置４の画面に表示する。図２５Ｂに示されているように、ステップＳ１７で、利用者５が変更後の状態、理由及び自分のメールアドレスを入力した後に、ステップＳ１８で、"送信"ボタンを押下すると、入力された情報が作業工程状態変更検出サーバー２を介して作業工程状態変更管理サーバー６へ送信され、ステップＳ１９で、作業工程状態変更管理サーバー６は、タスク変更申請テーブルに新たな行を追加する。図２６に追加された行を示す。

ステップＳ１３で、"完了"もしくは"中止"でなかった場合は、ステップＳ２０へ進み、図２７に示すような変更申請却下メッセージ画面を端末装置４に表示して処理を終える。

図２８は、端末装置４によりタスク変更申請書が作成され、作業工程状態変更管理サーバー６によりタスク変更申請テーブルに新たな行が追加されたときに、上位タスクの管理者に変更申請メールを送信する処理のフロー（タスク変更申請書登録完了後処理フロー）である。このフローは、作業工程状態変更管理サーバー６内の記憶媒体に記憶されているコンピュータプログラムに基づいて実行される。

まずステップＳ２１で、タスク変更申請テーブルより、新たに作成された申請ＩＤから変更タスクＩＤを取得する。ここでは、図２６より"Ｔ１１１"が取得される。次いでステップＳ２２で、変更タスクＩＤ"Ｔ１１１"を基に、タスクメタデータテーブル（図１９）より、変更時上位通知フラグ（ここでは"１"）を取得し、ステップＳ２３で、変更タスクＩＤ"Ｔ１１１"を基に、タスクメタデータテーブルより、上位タスクＩＤ（ここでは"Ｔ１１"）を取得する。

次にステップＳ２４で、上位タスクＩＤ"Ｔ１１"を基に、タスクメタデータテーブルより、担当者メールアドレス（ここでは"admin1@abc.com"）を取得し、ステップＳ２５で、下記の変更申請メールを送信する。なお、下記の変更申請メール本文中の"ＡＰ１"は申請ＩＤである。
Title：タスク状態変更申請、本文：タスクＩＤ；Ｔ１１１、申請書ＵＲＬ；http//abc.com/Ｔ/approval.do&id＝ＡＰ１

変更申請メールを受け取ったタスクＴ１１の管理者により、図２９に示されているタスク変更申請通知メール受信後処理フローが実行される。
まずステップＳ３１で、図３０に示されている、端末装置４に表示されている変更申請承認画面の理由欄を見て、申請を承認するか却下するかを決定し、対応するボタンを押下する。承認した場合は、ステップＳ３２で、図３１に示されているように、申請ＩＤ＝ＡＰ１のタスク変更申請テーブルの許可ステータスを"承認"に変更する。

次いでステップＳ３３で、変更タスクＩＤ（ここでは"Ｔ１１１"）を基に、タスクメタデータテーブルから変更時上位通知フラグ（ここでは"１"）を取得し、ステップＳ３４で、変更時上位通知フラグが"１"か否か調べる。

ここでは、変更時上位通知フラグが"１"であるから、ステップＳ３５に進み、図３１に示されているように、新たに申請ＩＤ"ＡＰ２"を作成し、その発生元申請ＩＤには申請ＩＤ"ＡＰ１"を、変更タスクＩＤには上位工程ＩＤ"Ｔ１１"を、申請者メールアドレスにはタスクＴ１１の担当者メールアドレスを設定する。これにより、タスク変更申請書登録後処理（図２８）が呼び出され、タスクＴ１の管理者(admin@abc.com)に変更申請メールが送信される。

さらにタスクＴ１の管理者が変更申請承認画面上の"承認"ボタンを押下したとき、図２９のステップＳ３６〜Ｓ３９が実行され、申請者(worker1@abc.com)に変更が承認された旨のメールが送られ、作業工程変更検出サーバー２には変更タスクＩＤ(Ｔ１１１)と許可ステータス(実行中)が送信される。このメールを以下に示す。
Title：タスク状態変更通知、本文：タスクＩＤ；Ｔ１１１、"作業中"に変更されました。

変更タスクＩＤと許可ステータスを受信した作業工程変更検出サーバー２は、図３２に示されているタスク変更申請結果受信後処理フローのステップＳ４１〜Ｓ４３を実行するにより、工程状態管理サーバー３へ変更コマンド"ＣＨＧ，Ｔ１１１，作業中"を送信する。

このように、本実施形態のプロジェクト管理システムによれば、タスク状態の変更を検出し、それが関連工程の状態に関わるものであれば、その変更を管理者に伝え、管理者が許可するまではタスク状態を変更しないようにすることができる。

本発明は、グループウェア、コラボレーション、ソフトウェア、作業管理ツール等の、複数の端末装置がネットワークインフラを介して動作する、情報共有システムに応用可能である。

本発明の第１の実施形態のプロジェクト管理システムの構成を示す図である。 本発明の第１の実施形態のプロジェクト管理システムにおける状態遷移図を示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態において、プロジェクト内の各作業工程の状態が、プロジェクトの開始時から終了時までにどのように変化していくかを時系列で示す図である。 本発明の第１の実施形態におけるタスクの関係を示す図である。 本発明の第１の実施形態におけるタスクメタデータテーブルを示す図である。 本発明の第１の実施形態におけるコマンドの一例を示す図である。 本発明の第１の実施形態において、タスク状態を変更するコマンドが発行された場合の作業工程状態変更検出サーバーの動作を示すフローチャートである。 本発明の第２の実施形態のプロジェクト管理システムの構成を示す図である。 本発明の第２の実施形態において、利用者がタスク状態を変更する場合のシステムの動作を示すフローチャートである。 本発明の第２の実施形態におけるタスク変更申請時のシーケンス図である。 本発明の第２の実施形態における変更申請書作成画面を示す図である。 本発明の第２の実施形態におけるタスク変更申請テーブルの新たな行を示す図である。 本発明の第２の実施形態における変更申請却下メッセージを示す図である。 本発明の第２の実施形態において、タスク変更申請書が作成され、タスク変更申請テーブルに新たな行が追加されたときに、上位タスクの管理者に変更申請メールを送信する処理のフローである。 本発明の第２の実施形態におけるタスク変更申請通知メール受信後処理フローである。 本発明の第２の実施形態における変更申請承認画面を示す図である。 本発明の第２の実施形態におけるタスク変更申請テーブルを示す図である。 本発明の第２の実施形態におけるタスク変更申請結果受信後処理フローである。 ＷＢＳによってプロジェクトを作業工程へと分割した例を示す図である。 図３３のＷＢＳによるプロジェクトの作業工程への分解結果を分解のレベル毎に階層的に書き表したものを示す図である。 図３４に作業工程間の依存関係の例を加えた図である。 図３５を棒チャートに書き換えた図である。

符号の説明

２・・・作業工程状態変更検出サーバー、３・・・工程状態管理サーバー、４・・・端末装置、５・・・利用者、６・・・作業工程状態変更管理サーバー。

Claims (6)

1. 複数の作業工程及び各作業工程間の依存関係によってプロジェクトを表現するとともに、各作業工程の進捗状態によってプロジェクトを管理するプロジェクト管理システムであって、
   各作業工程の状態をその作業工程が依存している別の作業工程の状態に応じて求める手段と、作業が開始されている作業工程に依存している、先行作業工程の状態変更を検出する先行作業工程状態変更検出手段と、前記先行作業工程状態変更検出手段の検出結果を管理者に通知する状態変更通知手段とを有することを特徴とするプロジェクト管理システム。
2. 請求項１に記載されたプロジェクト管理システムにおいて、
   作業工程の状態の変更申請を検出する作業工程状態変更申請検出手段と、その検出結果を管理者に通知する状態変更申請通知手段とを有することを特徴とするプロジェクト管理システム。
3. 請求項１又は２に記載されたプロジェクト管理システムにおいて、
   前記状態変更通知手段は、メールにより通知することを特徴とするプロジェクト管理システム。
4. 請求項１〜３のいずれかに記載されたプロジェクト管理システムにおいて、
   各作業工程は階層的構造を持ち、上位階層の作業工程がその下位に位置する作業工程の概要を表すものであり、上位階層の状態は下位に位置する全ての作業工程の状態を反映したものであることを特徴とするプロジェクト管理システム。
5. 請求項１〜４のいずれかに記載されたプロジェクト管理システムにおいて、
   各作業工程の状態を「開始可能」、「待ち」、「作業中」、「完了」、「中止」により表すことを特徴とするプロジェクト管理システム。
6. 複数の作業工程及び各作業工程間の依存関係によってプロジェクトを表現するとともに、各作業工程の進捗状態によってプロジェクトを管理するプロジェクト管理システムのコンピュータを、請求項１〜５のいずれかに記載されたプロジェクト管理システムの各手段として機能させるためのプログラム。

Images