(57)【要約】  【課題】複数の管理方法を用いて統合的にプロジェクトを管理する。  【解決手段】プロジェクト管理装置１は、前記プロジェクトに含まれるタスクの設定情報と、進捗状況と、を収集する。また、第一の形式の工程表と、第二の形式の工程表と、を一つの工程表として生成する。【選択図】図１
2015049710.tif 000002
【特許請求の範囲】
【請求項１】
プロジェクトを管理するためのプロジェクト管理装置であって、
前記プロジェクトに含まれるタスクの設定情報と、進捗状況と、を収集する情報収集部と、
前記プロジェクトに関する第一の形式の工程表と、第二の形式の工程表と、を生成する工程表生成部と、
生成された前記工程表を出力する出力制御部と、を有する
ことを特徴とするプロジェクト管理装置。
【請求項２】
請求項１に記載のプロジェクト管理装置であって、
前記第一の形式の工程表は、ガントチャートである
ことを特徴とするプロジェクト管理装置。
【請求項３】
請求項１又は２に記載の監視装置であって、
前記第二の形式の工程表は、ＣＣＰＭである
ことを特徴とするプロジェクト管理装置。
【請求項４】
請求項１から３の何れか一項に記載のプロジェクト管理装置であって、
前記工程表生成部は、
前記第一の形式の工程表と、前記第二の形式の工程表と、を結合した第３の形式の工程表を、さらに生成する
ことを特徴とするプロジェクト管理装置。
【請求項５】
請求項１から４の何れか一項に記載のプロジェクト管理装置であって、
前記工程表の形式の選択を受け付ける入力制御部を、さらに備え、
前記工程表生成部は、
受け付けた形式の工程表を生成する
ことを特徴とするプロジェクト管理装置。
【請求項６】
請求項２から５の何れか一項に記載のプロジェクト管理装置であって、
前記ガントチャートに含まれるバッファを、前記タスクごとに表示する
ことを特徴とするプロジェクト管理装置。
【請求項７】
プロジェクトを管理するためのプロジェクト管理装置のプログラムであって、
前記プログラムは、
前記プロジェクトに含まれるタスクの設定情報と、進捗状況と、を収集する収集ステップと、
前記プロジェクトに関する第一の形式の工程表と、第二の形式の工程表と、を生成する生成ステップと、
生成された前記工程表を出力する出力ステップと、を前記プロジェクト管理装置に実行させる
ことを特徴とするプログラム。
【請求項８】
プロジェクトを管理するためのプロジェクト管理方法であって、
前記プロジェクトに含まれるタスクの設定情報と、進捗状況と、を収集する収集ステップと、
前記プロジェクトに関する第一の形式の工程表と、第二の形式の工程表と、生成する生成ステップと、
生成された前記工程表を出力する出力ステップと、を含む
ことを特徴とするプロジェクト管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロジェクト等の管理におけるプロジェクト管理装置、プログラム、及び管理方法に関する。
【背景技術】
【０００２】
プロジェクト等を管理するための管理方法や、各管理方法で用いられる工程表（例えば、ガントチャート）が知られている。ガントチャートは、横軸に日時、縦軸にタスクを示し、各タスクの実施計画を横棒グラフで図示するものである。
【０００３】
例えば、引用文献１には、ガントチャートのバーの高さを、リソース行の高さに対応付けることによって、作業が集中する期間における作業量の把握を支援することが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−２３０３８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、ガントチャートによるプロジェクト管理には、プロジェクト納期を守るために、各タスクの工期に安全余裕（バッファ）が含まれるのが一般的である。しかしながらバッファが含まれることによって、作業者には、予定工期の期限を守りさえすればよいという意識が働いてしまう。その結果、例え期限前にタスクが終了したとしても、作業者が次のタスクに進むことなく、無駄にバッファを消費してしまう場合があった。
【０００６】
そこで提案されたのが、ＣＣＰＭ（Critical Chain Project Management）と呼ばれる新しい管理方法である。ＣＣＰＭでは、各タスクをバッファを含めない限界の工期で設定しておき、遅延はプロジェクト全体に対して設けられているプロジェクトバッファによって吸収する。よって各タスクは、常に限界の予定工期により管理されるため、作業者の納期に対する意識による遅延が生じ難い。
【０００７】
ところで、社内での管理に所定の管理方法を用いているにも関わらず、顧客に対しては他の管理方法に基づく報告を行わなければならない場合がある。例えば、社内でＣＣＰＭを用いた管理を行っていても、顧客からガントチャートによる工程表を要求されれば、管理者はプロジェクトを複数の管理方法によって二重管理せざるを得ず、煩雑な作業が生じる可能性があった。
【０００８】
そこで、本発明は、複数の管理方法を用いて統合的にプロジェクトを管理することを目的とする。
【課題を解決するための手段】
【０００９】
本願は、上記課題の少なくとも一部を解決する手段を複数含んでいるが、その例を挙げるならば、以下のとおりである。
【００１０】
上記の課題を解決するための本発明の第一の態様は、プロジェクトを管理するためのプロジェクト管理装置であって、前記プロジェクトに含まれるタスクの設定情報と、進捗状況と、を収集する情報収集部と、前記プロジェクトに関する第一の形式の工程表と、第二の形式の工程表と、を生成する工程表生成部と、生成された前記工程表を出力する出力制御部と、を有することを特徴とする。
【００１１】
上記の第一の工程表は、ガントチャートであることを特徴とする。
【００１２】
上記の第二の工程表は、ＣＣＰＭであることを特徴とする。
【００１３】
上記の工程表生成部は、前記第一の形式の工程表と、前記第二の形式の工程表と、を結合した第３の形式の工程表を、さらに生成することを特徴とする。
【００１４】
上記のプロジェクト管理装置は、前記工程表の形式の選択を受け付ける入力制御部を、さらに備え、前記工程表生成部は、受け付けた形式の工程表を生成することを特徴とする。
【００１５】
上記のプロジェクト管理装置は、前記ガントチャートに含まれるバッファを、前記タスクごとに表示することを特徴とする。
【００１６】
上記の課題を解決するための本発明の第二の態様は、プロジェクトを管理するためのプロジェクト管理装置のプログラムであって、前記プログラムは、前記プロジェクトに含まれるタスクの設定情報と、進捗状況と、を収集する収集ステップと、前記プロジェクトに関する第一の形式の工程表と、第二の形式の工程表と、を生成する生成ステップと、生成された前記工程表を出力する出力ステップと、を前記プロジェクト管理装置に実行させることを特徴とする。
【００１７】
上記の課題を解決するための本発明の第三の態様は、プロジェクトを管理するためのプロジェクト管理方法であって、前記プロジェクトに含まれるタスクの設定情報と、進捗状況と、を収集する収集ステップと、前記プロジェクトに関する第一の形式の工程表と、第二の形式の工程表と、生成する生成ステップと、生成された前記工程表を出力する出力ステップと、を含むことを特徴とする。
【００１８】
上記した以外の課題、構成、及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態に係るプロジェクト管理装置１の機能構成の一例を示す図。
【図２】タスク情報テーブル１２１０の一例を示す図。
【図３】進捗情報テーブル１２２０の一例を示す図。
【図４】各タスクの進捗状況に関する入力情報を取得するためのユーザーインターフェイス画面２０の一例を示す図。
【図５】コンピューター３００のハードウェア構成の一例を示す図。
【図６】工程表生成処理の一例を示すフロー図。
【図７】選択画面５５の一例を示す図。
【図８】工程表画面６０の一例を示す図。
【図９】工程表画面７０の一例を示す図。
【図１０】両形式の工程表画面８０の一例を示す図。
【図１１】両形式の工程表画面９０の一例を示す図。
【図１２】両形式の工程表画面９９の一例を示す図。
【図１３】進捗率とバッファ消費率の関係を示すグラフ。
【発明を実施するための形態】
【００２０】
以下、本発明の一実施形態について、図面を参照して説明する。
【００２１】
図１は、本発明の一実施形態に係るプロジェクト管理装置１の機能構成の一例を示す図である。
【００２２】
プロジェクト管理装置１の構成は、本願発明の特徴を説明するにあたって主要構成を説明したものであって、下記の構成に限られない。また、一般的な装置が備える構成を排除するものではない。
【００２３】
プロジェクト管理装置１は、制御部１１０と、記憶部１２０と、を有する。
【００２４】
記憶部１２０には、タスク情報記憶部１２１と、進捗情報記憶部１２２と、が含まれる。
【００２５】
タスク情報記憶部１２１は、プロジェクト中に含まれるタスクの設定に関する情報（以下、「タスク情報」とも称する）を格納する。
【００２６】
タスクの設定に関するタスク情報は、例えば、図２（タスク情報テーブル１２１０の一例を示す図）に示すように構成される。タスク情報テーブル１２１０には、１つのプロジェクトの含まれるタスクのタスク識別情報１２１１と、工期１２１２と、開始予定日１２１３と、実績開始日１２１４と、終了予定日１２１５と、実績終了日１２１６と、最速工期１２１７と、担当１２１８と、依存関係タスク１２１９と、表示順１２１１１と、を関連付けたレコードが格納される。
【００２７】
タスク識別情報１２１１は、タスクを特定する識別情報であり、例えば、各タスクに固有の名前等の識別子である。工期１２１２は、対応するタスクが開始してから終了するまでに要する、バッファを含む予定日数である。開始予定日１２１３は、対応するタスクの開始予定日である。実績開始日１２１４は、対応するタスクが実際に開始された日である。終了予定日１２１５は、対応するタスクのバッファを含む終了予定日であり、例えば、開始予定日１２１３から工期１２１２が経過した日の日付である。実績終了日１２１６は、対応するタスクが実際に終了した日である。最速工期１２１７は、対応するタスクが開始してから終了するまでに要する、バッファを含まない予定日数である。これは即ち、当該タスクを最速で終了させるのに要する日数であり、例えば、対応するタスクの工期１２１２からバッファを除いた日数である。担当１２１８は、対応するタスクに関する情報であり、例えば、タスクの担当者名である。依存関係タスク１２１９は、タスクの開始条件となる終了タスクの識別情報である。表示順１２１１１は、後述のタスク表示領域５１を構成する際に用いられる項番である。
【００２８】
図１に戻って、進捗情報記憶部１２２は、各タスクの進捗状況に関する情報（以下、「進捗情報」とも称する）を格納する。
【００２９】
各タスクの進捗状況に関する情報は、例えば、図３（進捗情報テーブル１２２０の一例を示す図）に示すように構成される。進捗情報テーブル１２２０には、報告日１２２１と、タスク識別情報１２２２と、予測残日数１２２３と、達成率１２２４と、を関連付けたレコードが格納される。これらの情報は、利用者からの報告内容に基づいて蓄積される。
【００３０】
報告日１２２１は、進捗状況が報告された日付であり、例えば、後述のインターフェイス画面等を介して、当日の進捗状況の報告がなされた日の日付である。なお、別日に過去のある日付の進捗状況を報告する場合であっても、その進捗時点である過去の日付が報告日となる。タスク識別情報１２２２は、タスクを特定するための識別情報であり、例えば、各タスクに固有の名前等の識別子である。予測残日数１２２３は、バッファを含まない残日数である。達成率１２２４は、報告日１２２１の時点におけるタスクの達成率である。
【００３１】
なお、上述した予測残日数や達成率は、タスクの進捗状況を表す尺度である。なお、尺度は一つでも複数でもよい。例えば、予測残日数からタスク達成率を算出してもよく、また、達成率からタスクの予測残日数を算出することも可能である。
【００３２】
図１に戻って、制御部１１０は、情報収集部１１１と、工程表生成部１１２と、出力制御部１１３と、入力制御部１１４と、を有する。
【００３３】
情報収集部１１１は、入力制御部１１４を介して取得した入力情報に基づいて情報を収集する。情報収集部１１１は、例えば、利用者から各タスクの設定に関する入力情報を取得し、タスク情報テーブル１２１０を生成する。また、情報収集部１１１は、例えば、利用者から各タスクの進捗状況に関する入力情報を取得し、進捗情報テーブル１２２０を生成する。
【００３４】
このような入力情報は、後述の出力制御部１１３が作成した入力情報を取得するための任意のユーザーインターフェイス画面を介して取得される。図４に、各タスクの進捗状況に関する入力情報を取得するためのユーザーインターフェイス画面２０の一例を示す。ユーザーインターフェイス画面２０は、報告日選択領域２１と、タスク表示領域２２と、を含んでいる。利用者はまず、報告日選択領域２１から報告日（ここでは、当日とする）を選択する。すると、当該報告日（当日）における進行中タスクと未着手タスクとの一覧が、タスク表示領域２２に表示される。利用者は、タスク表示領域２２から、タスクの実績開始日、予測残日数、実績終了日を入力することで、当日の進捗状況を報告することができる。なお、達成率についても、入力可能な構成としてもよい。
【００３５】
図４に示す例の場合、報告日「４月４日」が選択されている。情報収集部１１１は、報告日が選択されると、報告日の時点で進行中及び未着手のタスクを、タスク情報テーブル１２１０から読み出し、タスク表示領域２２を生成する。なお、進行中のタスクは、実績開始日１２１４に日付が格納されており、さらに、実績終了日１２１６に日付が格納されていないレコードを抽出することで特定できる。また、未着手のタスクは、実績開始日１２１４に日付が格納されていないレコードを抽出することで特定できる。
【００３６】
情報収集部１１１は、このようなタスク表示領域２２から入力されるタスクの予測残日数等の進捗情報に従って、図３に示すような進捗情報テーブル１２２０に、新たなレコードを作成して、進捗情報とする。そして、図２に示すタスク情報テーブル１２１０の該当タスクのレコードに、タスクが開始された場合には実績開始日１２１４を、タスクが終了した場合には実績終了日１２１６を格納する。
【００３７】
ここで、予測残日数から達成率（％）を算出する場合、情報収集部１１１は、例えば、入力された当該タスクの実績開始日１２１４から報告日までの経過時間（ここでは例えば、実績開始日４月１日から報告日４月４日までの４日間）を求め、予測残日数（ここでは例えば、１２日間）と加算して予測工期（１６日間）を算出し、経過時間の予測工期に対する割合（２５％）を達成率として扱うことができる。なお、達成率を入力させて、予測残日数を算出してもよい。
【００３８】
工程表生成部１１２は、タスク情報及び進捗情報から、所定の形式の工程表を生成する。工程表生成部１１２は、例えば、タスク情報テーブル１２１０、及び進捗情報テーブル１２２０に基づいて、ガントチャート形式、及びＣＣＰＭ形式の工程表を表示するための工程表画面の表示情報を生成する。
【００３９】
出力制御部１１３は、後述する自装置の出力装置３６０を介して、工程表画面の出力を制御する。出力制御部１１３は、例えば、工程表生成部１１２が作成した表示情報を取得すると、自装置の出力装置３６０を介して工程表画面の出力を制御する。また、出力制御部１１３は、例えば、入力制御部１１４を介して入力情報を取得するためのユーザーインターフェイス画面の表示情報を生成し、自装置の出力装置３６０を介して工程表画面の出力を制御する。なお、出力制御部１１３は、自装置のみならず、他装置の出力装置における工程表画面の出力を制御してもよい。例えば、出力制御部１１３は、工程表画面を印刷装置３８０に出力し、工程表の印刷を行う。なお、出力制御部１１３は、工程表画面とは別に、印刷専用の画面を生成して、出力してもよい。
【００４０】
入力制御部１１４は、後述する自装置の入力装置３５０を介した情報の入力を制御する。入力制御部１１４は、例えば、利用者から各タスクの設定に関する入力情報を取得するためのユーザーインターフェイス画面に対する入力を受け付ける。また例えば、入力制御部１１４は、各タスクの進捗状況に関する入力情報を取得するためのユーザーインターフェイス画面に対する入力を受け付ける。なお、入力制御部１１４は、通信部１３０を介した情報の入力を制御してもよい。
【００４１】
通信部１３０は、ＩＴ機器ネットワークと接続し、ＩＴ機器ネットワークを介した情報の送受信を行う。このように、プロジェクト管理装置１は、いわゆるＩＴ機器としての機能を備え、ネットワーク（以下、「ＩＴ機器ネットワーク」ともいう。）を介して他の装置と互いに通信可能に構成されていてもよい。ＩＴ機器ネットワークは、例えば、ＩＥＥＥ８０２．３の規格のＬＡＮであり、ルーターなどの通信機器を介して、インターネットに接続されている。ＩＴ機器ネットワークでは、通信プロトコルとして、例えば、ＩＰ（Internet Protocol）などが用いられる。
【００４２】
上述したプロジェクト管理装置１は、例えば、図５（コンピューター３００のハードウェア構成の一例を示す図）に示すような、ＣＰＵ（Central Processing Unit）３１０と、メモリー３２０と、ＨＤＤ等の外部記憶装置３３０と、無線や有線により通信ネットワークに接続するための通信装置３４０と、マウスやキーボードなどの入力装置３５０と、液晶ディスプレイなどの出力装置３６０と、ＤＶＤ（Digital Versatile Disk）などの記録媒体に対する情報の読書きを行う読書装置３７０と、プリンタなどの印刷装置３８０と、を備えるコンピューター３００で実現できる。印刷装置３８０は、通信装置３４０等を介してコンピューター３００の外部に接続されるようにしてもよい。
【００４３】
例えば、制御部１１０は、外部記憶装置３３０に記憶されている所定のプログラムをメモリー３２０にロードしてＣＰＵ３１０で実行することで実現可能である。記憶部１２０は、ＣＰＵ３１０がメモリー３２０又は外部記憶装置３３０を利用することにより実現可能である。通信部１３０は、ＣＰＵ３１０が通信装置３４０を利用することで実現可能である。
【００４４】
上記の所定のプログラムは、通信装置３４０を介してネットワークから、外部記憶装置３３０にダウンロードされ、それから、メモリー３２０上にロードされてＣＰＵ３１０により実行されるようにしてもよい。また、通信装置３４０を介してネットワークから、メモリー３２０上に直接ロードされ、ＣＰＵ３１０により実行されるようにしてもよい。また、コンピューター３００が、読書装置３７０にセットされた記憶媒体から、上記の所定のプログラムを、外部記憶装置３３０あるいはメモリー３２０にロードするようにしてもよい。
【００４５】
上記の図１のプロジェクト管理装置１の構成は、理解を容易にするために、主な処理内容に応じて分類したものである。構成要素の分類の仕方や名称によって、本願発明が制限されることはない。プロジェクト管理装置１の構成は、処理内容に応じて、さらに多くの構成要素に分類することもできる。また、１つの構成要素がさらに多くの処理を実行するように分類することもできる。また、各構成要素の処理は、１つのハードウェアで実行されてもよいし、複数のハードウェアで実行されてもよい。また、各構成要素の処理は、１つのプログラムで実現されてもよいし、複数のプログラムで実現されてもよい。
【００４６】
また、上記の図２及び図３の各情報のテーブルは一例であり、図示した例に限られない。また、各情報は、テーブル構造に限られず、他のデータ構造であってもよい。
【００４７】
次に、上記のプロジェクト管理装置１で実現される動作について説明する。
【００４８】
図６は、工程表生成処理の一例を示すフロー図である。ここでは便宜上、基本設計「機能１」〜「機能３」から成立する１つのプロジェクトがタスク情報テーブルに格納されている場合を想定して、以下、説明する。
【００４９】
本フローは、例えば、工程表生成部１１２が出力制御部１１３に、出力装置３６０を介してどのような形式の工程表を生成するか否かの選択を受け付ける選択画面を表示させ、その選択を受け付けることで開始される。出力制御部１１３は例えば、図７（選択画面５５の一例を示す図）に示すような工程表の形式選択領域５６を有する選択画面５５（ダイアログボックス）を表示し、入力制御部１１４は、入力装置３５０を介して選択された情報の入力情報を取得する。なお、工程表の形式は、「ガントチャート」、「ＣＣＰＭ」「ガントチャート＋ＣＣＰＭ」の３つから選択可能であるものとする。
【００５０】
どの形式の工程表が選択された場合でも、工程表生成部１１２はまず、縦軸と横軸を描画する（ステップＳ４２）。
【００５１】
具体的には、工程表生成部１１２は、工程表の縦軸と横軸を構成する。図８に、ガントチャート形式の工程表画面６０の一例を、図９に、ＣＣＰＭ形式の工程表画面７０の一例を示す。
【００５２】
例えば、工程表生成部１１２はまず、縦軸にタスクを配置し、タスク表示領域５１を構成する。具体的に工程表生成部１１２は、タスク情報テーブル１２１０を参照し、各レコードのタスク識別情報１２１１を、縦軸に並べて配置する。なお、その順序はここでは、タスク情報テーブル１２１０の表示順１２１１１に格納される項番に基づくものとするが、開始予定日または実績開始日の順としてもよい。本例においては、プロジェクトに含まれる基本設計「機能１」〜「機能３」の３つのタスクが、表示順１２１１１の順に並べられたタスク表示領域５１が構成される。なお、本例では、各タスクに応じた罫線により、各タスクに行エリア５７が構成されているものとする。
【００５３】
そして工程表生成部１１２は、横軸に日付を配置し、日付表示領域５２を構成する。日付には少なくとも、縦軸に配置された各タスクの開始予定日または実績開始日から、終了予定日までの日付が含まれている。なお、終了予定日が延期する場合を考慮して、終了予定日から所定の期間先の日付までが描画されることが望ましい。ここでは例えば、基本設計「機能１」の実績開始日「４月１日」から、少なくとも基本設計「機能３」の終了予定日「４月２５日」までの日付によって、日付表示領域５２が構成される。
【００５４】
次に、工程表生成部１１２は、シンボルを描画する（ステップＳ４３）。
【００５５】
具体的に、工程表生成部１１２は例えば、横軸に対して当日（本例では、当日に最新の報告が行われているものとする）の位置を示すシンボル５３、期限の位置を示すシンボル５４を配置する。なお、期限の位置は、例えば、縦軸に構成されたタスクのうち、最も遅い終了予定日、または、別途予め記憶される納期等である。ここでは例えば、基本設計「機能３」の終了予定日「４月２５日」が、期限と判断され、その該当位置にシンボル５４が配置される。もちろん、予め別に期限が設定されている場合にはそれを用いることもできる。また、ＣＣＰＭのみが選択された場合は、進捗管理線５８をさらに描画してもよい。進捗管理線５８は、例えば、表中で当日位置を示す縦線である。
【００５６】
次に、ガントチャート形式の工程表を作成する場合について説明する。工程表生成部１１２は、ガント形式のチャートを描画する（ステップＳ４４）。
【００５７】
具体的には、工程表生成部１１２はまず、図８に示すようなチャート６１を生成し配置する。チャート６１は、タスク表示領域５１に割り当てられた各タスクの行エリア５７において、当該タスクの開始予定日から終了予定日までの日付に応じた横棒グラフを展開したものである。従って工程表生成部１１２は、タスク情報テーブル１２１０から、各タスクの開始予定日１２１３と終了予定日１２１５とを取得して、日付表示領域５２に応じたチャート６１を構成する。
【００５８】
次に、工程表生成部１１２は、進捗管理線（稲妻線）を描画する（ステップＳ４５）。
【００５９】
具体的には、工程表生成部１１２は、図８に示すような進捗管理線（稲妻線）６２を生成し配置する。進捗管理線（稲妻線）６２は、報告日（当日）におけるタスクの進捗を表すものであり、当日を示す縦線と、タスクのチャート６１における進捗割合位置と、を結ぶ線である。従って、工程表生成部１１２は、タスク表示領域５１に割り当てられた各タスクについて、進捗情報テーブル１２２０から各タスクごとに最新のレコードを抽出し、その達成率１２２４を取得する。そして、当該タスクのチャート６１における割合位置と、当日とを結ぶ進捗管理線（稲妻線）６２を生成する。図８に示す例の場合、進行中である「機能１」のタスクが４月４日の時点で２５％までしか達成されていないため、４月４日の線とチャート６１の２５％の割合位置が結ばれ、タスクの進捗が遅延している旨を示す進捗管理線（稲妻線）６２が表示されることとなる。
【００６０】
なお、報告日時点で完了予定となっているタスクで実際に完了したタスク、または、報告日時点で未着手予定となっているタスクで実際に未着手のタスクについては、予定どおりの進捗であるため、当該タスクの達成率の割合位置とは結ばず、進捗管理線（稲妻線）は報告日の位置に縦線を描画する。図８に示す例の場合、「機能２」および「機能３」は、報告日（４月４日）時点で未着手予定のタスクで実際に未着手であるため、進捗管理線（稲妻線）は個々のタスクのチャートの０%の位置とは結線せず、報告日(４月４日)の位置に縦線を描画する。
【００６１】
このように、工程表生成部１１２は、ステップＳ４２〜Ｓ４５の処理により、工程表画面６０の表示情報を生成する。そして、工程表生成部１１２は、生成した表示情報を出力制御部１１３へと出力して、本フローを終了する。
【００６２】
次に、ＣＣＰＭ形式の工程表を作成する場合について説明する。工程表生成部１１２は、ＣＣＰＭ形式のチャートを描画する（ステップＳ４６）。
【００６３】
具体的には、工程表生成部１１２は、図９に示すようなチャート７１を生成して配置する。ＣＣＰＭ形式のチャート７１は、完了したタスクは完了するまでに要した実際の期間（実績開始日から実績終了日までの期間）、進行中のタスクはこれまでに要した期間（実績開始日から最新の報告日までの期間）に予測残日数を合計した期間、未着手のタスクは最速工期、をそれぞれ表す横棒グラフである。なお、ＣＣＰＭにおけるスケジューリングについては、公知のどのような方法を用いてもよい。以下にその一例を示す。
【００６４】
工程表生成部１１２はまず、タスク情報テーブル１２１０の依存関係タスク１２１９からタスクの依存関係を辿り、クリティカルチェーン（プロジェクトの全工程について、リソースを考慮した上で最も時間のかかる作業経路）に属するタスクと、当該クリティカルチェーンに合流する非クリティカルチェーンに属するタスクと、を判別する。
【００６５】
そして、工程表生成部１１２は、進捗情報テーブル１２２０から、各タスクごとに最新のレコードを抽出し、達成率１２２４が１００％のタスク（完了したタスク）については、タスク情報テーブル１２１０の実績開始日１２１４から実績終了日１２１６までの期間を示す横棒グラフ７１を、当該タスクの行エリア５７に構成する。
【００６６】
また、工程表生成部１１２は、達成率１２２４が０％を超え１００％未満のタスク（進行中のタスク）については、これまでに要した実績開始日１２１４から報告日１２２１までの期間に、予測残日数１２２３を合計した期間についての横棒グラフ７１を、当該タスクの行エリア５７に構成する。
【００６７】
さらに、工程表生成部１１２は、達成率が０％のタスク（未着手のタスク）について、クリティカルチェーンに属するタスクは、前タスクの完了時期を起点として、最速工期１２１７を加えた日付までの期間についての横棒グラフ７１を、当該タスクの行エリア５７に構成する。また、非クリティカルチェーンに属するタスクには、その完了時期に所定の合流バッファを持たせた期間についての横棒グラフを、当該タスクの行エリア５７に構成する（図示しない）。すなわち、非クリティカルチェーンに属するタスクに後続のクリティカルチェーンに属するタスクが遅れないように、クリティカルチェーンと非クリティカルチェーンとの連結部分に、合流バッファが配置される。
【００６８】
なお、図９には、各タスクの依存関係を示す矢印線７４を描画した例を示している。ここでは、基本設計「機能１」に続いて基本設計「機能２」、基本設計「機能２」に続いて基本設計「機能３」が開始されるクリティカルチェーンが設定されている。
【００６９】
また、工程表生成部１１２は、各チャートについて、当日までの部分（既にタスクが完了している部分）と、当日より後の部分（未だタスクが完了していない部分）と、の形式を異なるように構成してもよい。形式とは例えば、色、模様、太さや形等の、視認が可能なものであればどのようなものであってもよい。図９の例では、完了した部分については塗りつぶしを適用したチャート７１を描画している。
【００７０】
次に、工程表生成部１１２は、バッファを描画する（ステップＳ４７）。
【００７１】
具体的には、工程表生成部１１２はまず、縦軸にバッファ表示領域７２を追加する。バッファ表示領域７２はプロジェクト単位に設けられ、その行エリアにバッファチャート７３が描画される。工程表生成部１１２は、タスク情報テーブル１２１０を参照して、プロジェクトバッファを算出する。例えば、プロジェクトバッファは、プロジェクトの納期と、当該プロジェクトを構成する全タスクが最速で終了する日との差である。図２に示す例では、プロジェクト納期が「４月２５日」、最速工期５日の基本設計「機能１」が最速で終了する日が「４月５日」、最速工期７日の基本設計「機能２」が最速で終了する日が「４月１２日」、最速工期５日の基本設計「機能３」が最速で終了する日が「４月１７日」であるから、プロジェクト納期「４月２５日」と全タスクが最速で終了する日「４月１７日」との差である８日間が、プロジェクトバッファとして設けられた日数となる。そして工程表生成部１１２は、全タスクが最速で終了する日から、プロジェクトバッファ日数分の期間を示すバッファチャート７３を該当するバッファの行エリアに構成する。このように、工程表生成部１１２は、ステップＳ４２、Ｓ４６、及びＳ４７の処理により、工程表画面７０の表示情報を生成する。そして、工程表生成部１１２は、生成した表示情報を出力制御部１１３へと出力して、本フローを終了する。
【００７２】
なお、工程表生成部１１２は、バッファチャートについても、既に消化された部分と、未消化の部分と、の形式を異なるように構成する。図９の例では、最終タスクである基本設計「機能３」の終了予定日が、期限「４月２５日」を超過した「４月２８日」であり、８日間のプロジェクトバッファを全て使い尽くす見通しとなっている。従って、バッファチャート全域に塗りつぶしを適用したバッファチャート７３が描画されている。これにより、利用者は直感的にバッファの消費を理解することができる。
【００７３】
次に、ガントチャート形式及びＣＣＰＭ形式の両形式の工程表を作成する場合について説明する。まず、工程表生成部１１２は、ガント形式のチャートを描画する（ステップＳ４８）。
【００７４】
図１０は、ガントチャート形式及びＣＣＰＭ形式を結合した形式の工程表画面８０の一例を示す図である。
【００７５】
なお、本ステップは、ステップＳ４４と略同様の処理であるため、詳細な説明は省略する。但し、工程表生成部１１２は、後述のＣＣＰＭ形式のチャート７１と重ならないよう、チャート６１を配置する。
【００７６】
そして、工程表生成部１１２は、進捗管理線（稲妻線）６２を描画する（ステップＳ４９）。
【００７７】
本ステップは、ステップＳ４５と略同様の処理であるため、詳細な説明は省略する。
【００７８】
さらに、工程表生成部１１２は、ＣＣＰＭ形式のチャートを描画する（ステップＳ５０）。
【００７９】
本ステップは、ステップＳ４６と略同様の処理であるが、工程表生成部１１２は、ＣＣＰＭ形式のチャート７１を、ステップＳ４８で構成したガント形式のチャート６１に重ならないよう配置する。図１０に示す例では、ガント形式のチャート６１の下に、ＣＣＰＭ形式のチャート７１を描画するよう構成されているが、これに限らず、ＣＣＰＭ形式のチャートの下にガント形式のチャートを配置してもよい。
【００８０】
最後に、工程表生成部１１２は、バッファを描画する（ステップＳ５１）。
【００８１】
本ステップは、ステップＳ４６と略同様の処理であるため、詳細な説明は省略する。工程表生成部１１２は、ステップＳ４２、及びＳ４８〜Ｓ５１の処理により、工程表画面８０の表示情報を生成する。そして、工程表生成部１１２は、生成した表示情報を出力制御部１１３へと出力して、本フローを終了する。
【００８２】
なお上記では便宜上、出力制御部１１３へと出力された表示情報を工程表画面として説明したが、必ずしも工程表画面として出力装置３６０に表示される必要はなく、印刷装置３８０で印刷され、紙媒体として出力されてもよい。
【００８３】
上記の図６のフローチャートの処理単位は、制御部１１０の処理を理解容易にするために、主な処理内容に応じて分割したものである。処理単位の分割の仕方や名称によって、本願発明が制限されることはない。制御部１１０の処理は、処理内容に応じて、さらに多くの処理単位に分割することもできる。また、１つの処理単位がさらに多くの処理を含むように分割することもできる。また、上記のフローチャートの処理順序も、図示した例に限られるものではない。
【００８４】
また、上記の図７〜１０の各ユーザーインターフェイス画面の構成は、図示された例に限られない。
【００８５】
以上、本発明の一実施形態について説明した。本実施形態によれば、プロジェクト等の管理において、複数の管理方法を統合的に用いた管理が可能である。よって、両者を比較してプロジェクトを管理することができる。また、一方の管理方法でプロジェクトを管理している場合でも、対外的には他方の管理方法で管理されたチャートを利用することも可能である。
【００８６】
また、ＣＣＰＭについての最速工期を設定しておくだけで、ガントチャートと同様の手法によるタスクの設定及び進捗の管理が可能となる。従って、複数の情報テーブルによる煩雑な二重管理を必要とせず、簡便な作業で異なる種類の工程表を出力できる。
【００８７】
さらに、一つの工程表に、異種の管理方法によるチャートを表示することが可能であるため、利用者は異なる側面から、進捗状況を比較し、把握することができる。
【００８８】
なお、以上の本発明の実施形態は、本発明の要旨と範囲を例示することを意図し、限定するものではない。多くの代替物、修正、変形例は当業者にとって明らかである。
【００８９】
例えば、ユーザーインターフェイス画面２０の構成は上記のものに限らず、例えば、情報収集部１１１は、タスク情報テーブル１２１０から依存関係タスク１２１９を読み出し、前タスクが進行中や未着手のタスクについては、非表示としてもよい。また、担当者名を指定させ、当該担当者が担当するタスクのみを表示してもよい。
【００９０】
また例えば、工程表生成部１１２は、工程表生成の際に、利用者に期間を入力させ、当該期間における工程表を生成してもよい。また、担当者を指定させ、当該担当者が担当するタスクについての工程表を生成することもできる。
【００９１】
さらに、工程表生成部１１２は、タスクごとに設けられるタスクバッファを、さらに表示するようにしてもよい。具体的には、例えば、図１１（ガントチャート形式及びＣＣＰＭ形式の両形式の工程表画面９０の一例を示す図）に示すように、ガント形式のチャート６１の其々に対し、各タスクごとに設けられているタスクバッファ（開始予定日から終了予定日までの日数と、最速工期との差）を示すバッファチャート９１が表示される。
【００９２】
また、バッファチャート９１は、対応するタスクにおいてバッファが消費されているか否かによりその表示の形式を異なるように構成してもよい。例えば、図１１においては、基本設計「機能１」の終了予定日が、最速工期である「４月５日」を大幅に上回る「４月１６日」であり、既に３日間のタスクバッファを全て使い尽くす見通しとなっている。よって、バッファチャート９１は全域が塗りつぶされて表示されている。これに対し、未着手の基本設計「機能２」及び「機能３」では、当該タスクのバッファチャート９１は未消費であるため、塗りつぶされていない状態で表示されている。
【００９３】
また例えば、タスクバッファの表示形式をさらに詳細に分けてもよい。具体例を、図１２（ガントチャート形式及びＣＣＰＭ形式の両形式の工程表画面９９の一例を示す図）に示す。本図では便宜上、チャート上に適宜日数を表示している。
【００９４】
図１２の例では、基本設計「機能１」が最速工期である５日で完了しており、現在、基本設計「機能２」が進行中である。なお、当日である４月１１日時点では、「機能２」は開始されてから既に６日が経過しており、予測残日数は２日である。従って、当該タスクには計８日が費やされる予定であり、達成率は４月１１日時点で７５％と算出される。図２より、「機能２」の最速工期は７日であるから、タスクバッファ３日のうち、１日が消費される見通しであると言える。よって同様にプロジェクトバッファについても、１日が消費される見通しとなる。
【００９５】
そこで、「機能２」のバッファチャート９３は、消費される１日分と、未消費である残りの２日分と、が異なる形式で表示される。なお、その形式は例えば、予め用意される図１３（進捗率とバッファ消費率の関係を示すグラフ）に示すようなバッファ傾向グラフによって特定することができる。
【００９６】
図示するように、バッファ傾向グラフは、横軸に進捗率を、縦軸にバッファ消費率をとり、そのグラフ領域を「危険」「注意」「安全」の３つのゾーンに分けたものである。本例においては、進捗率０％，バッファ消費率１５％の目盛と、進捗率１００％，バッファ消費率８０％の目盛と、が直線で結ばれ、このラインよりも下側の領域が安全ゾーン８８と規定されている。一方で、進捗率０％，バッファ消費率３０％の目盛と、進捗率１００％，バッファ消費率１００％の目盛と、を結ぶラインより上側の領域は危険ゾーン６６、安全ゾーン８８と危険ゾーン６６との間は、注意ゾーン７７と規定されている。
【００９７】
進捗状況をこのようなバッファ傾向グラフ上にプロットすることで、クリティカルチェーン上の遅れをバッファの消費率として可視化することができる。そして、プロットされた領域と、バッファの表示形式を紐付けておくことで、バッファ傾向グラフからバッファチャートの表示形式を決定することも可能である。例えば、プロットされた領域が安全ゾーン８８であれば青色や緑色、注意ゾーン７７であれば黄色、危険ゾーン６６であれば赤色で、該当バッファチャートを塗りつぶす。
【００９８】
図１２を例に挙げると、４月１１日時点で、「機能２」のタスクの進捗率（達成率）は７５％（８日中６日）、「機能２」のタスクバッファの消費率は約３３％（３日中１日）である。従って、バッファ傾向グラフ上では、このような状況が点Ａとしてプロットされる。点Ａが存在するのは安全ゾーン８８であるから、「機能２」のタスクバッファのバッファチャート９３の消費部分は、現在の進捗状況が安全であることを示す青色や緑色で表示される。
【００９９】
一方、図１２のプロジェクトバッファのバッファチャート９５で考えると、４月１１日時点で、プロジェクト全体の進捗率（達成率）は約６１％（１８日中１１日）、プロジェクトバッファの消費率は１２．５％（８日中１日）である。従って、バッファ傾向グラフ上では、このような状況が点Ｂとしてプロットされる。点Ｂが存在するのは安全ゾーン８８であるから、プロジェクトバッファのバッファチャート９５の消費部分も、現在の進捗状況が安全であることを示す青色や緑色で表示される。上記のような構成により、利用者はさらに視覚的に進捗状況を捉えることが可能である。
【０１００】
さらに例えば、工程表生成部１１２は、タスク情報テーブル１２１０の担当１２１８から各タスクごとの担当者名等の情報を取得し、図１１及び１２に示すような、リソース表示領域９９９に表示させてもよい。これによれば、利用者は、タスクごとにより多くの情報を把握することができる。
【符号の説明】
【０１０１】
１：プロジェクト管理装置、２０：ユーザーインターフェイス画面、２１：報告日選択領域、２２：タスク表示領域、５１：タスク表示領域、５２：日付表示領域、５３：シンボル、５４：シンボル、５５：選択画面、５６：形式選択領域、５７：行エリア、６０：工程表画面、６１：チャート、６２・６３：進捗管理線（稲妻線）、７０：工程表画面、７１：チャート、７２：バッファ表示領域、７３・９５：プロジェクトバッファチャート、７４：矢印線、８０：工程表画面、９０：工程表画面、９１〜９４：タスクバッファチャート、９９９：リソース表示領域、１１０：制御部、１１１：情報収集部、１１２：工程表生成部、１１３：出力制御部、１１４：入力制御部、１２０：記憶部、１２１：タスク情報記憶部、１２２：進捗情報記憶部、１３０：通信部、１２１０：タスク情報テーブル、１２２０：進捗情報テーブル。
【図１】
2015049710.tif 000003
【図２】
2015049710.tif 000004
【図３】
2015049710.tif 000005
【図４】
2015049710.tif 000006
【図５】
2015049710.tif 000007
【図６】
2015049710.tif 000008
【図７】
2015049710.tif 000009
【図８】
2015049710.tif 000010
【図９】
2015049710.tif 000011
【図１０】
2015049710.tif 000012
【図１１】
2015049710.tif 000013
【図１２】
2015049710.tif 000014
【図１３】
2015049710.tif 000015