(57)【要約】【課題】従来のプロジェクト管理アプリケーションにおけるガントチャートのタスクは、実行順序の依存関係で制約されているが、現実的にはその依存関係だけでは関連するタスクの作業担当者が行うコミュニケーションのコストは表現できない。このため、このコミュニケーションコストを、タスクに必要な工数としてバーチャートとして表示し集計可能にすることが、プロジェクト管理の精度と有効性の観点から課題であった。【解決手段】本特許の目的は、実行順序の依存関係にあるタスクにコミュニケーションコストを示すバーチャートの重なり箇所を設け、合わせてその関連を示す矢印を表示し、合わせてその重なりをタスクの工数として集計可能とすること。【選択図】図１
2011013958.tif 000002
【特許請求の範囲】
【請求項１】
ガントチャートに示されるプロジェクト管理画面において、実行順序の依存関係のあるタスクの担当者間のコミュニケーション期間を既存のタスクの期間を延長したバーチャートとして、該当タスクを表示するステップを含むことを特徴とする方法。
【請求項２】
該当タスク毎にコミュニケーションコストを入力するステップと、該当タスク毎のコミュニケーションコストを集計するステップおよび、該当タスクの工数としてコミュニケーションコストを合計するステップを有する請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロジェクト管理業務を支援するアプリケーションでのガントチャートを用いた工程管理画面におけるタスク管理方法に関する。
【背景技術】
【０００２】
一般的に、ソフトウェア開発、アプリケーションエンジニアリングの分野では、プロジェクト計画がプロジェクト管理業務として行われている。そのプロジェクト管理手法は、プロジェクトマネージャががメンバーのタスクを細部まで明確に定めて厳格に管理を行うことが前提である。これらのタスクの洗い出しを階層的に行ったリストをＷＢＳ（Ｗｏｒｋ  Ｂｒｅａｋｄｏｗｎ  Ｓｔｒｕｃｔｕｒｅ）と呼ぶ。
【０００３】
従来、このプロジェクト管理業務を支援するアプリケーションでのガントチャート（Ｇａｎｔｔｃｈａｒｔ） を用いた工程管理画面では、ＷＢＳで分解したタスクを縦軸にし、その期間を横軸として表現している。縦軸に書き出されるタスクは、処理の最小単位の作業工程として表現される。これに、その作業工程の所要期間をバーチャートとして表し、その各タスクに実行順序の依存関係を付け加えることで、ガントチャートとしていた。
【０００４】
ところで、一般的にガントチャートはタスクの依存関係を論理的に次の４つのパターンとしている。
【０００５】
タスクの依存関係
（１） ＦＳ（終了−開始）
ｍｕｓｔ  Ｆｉｎｉｓｈ  ｔａｓｋ  Ａ  ｔｏ  Ｓｔａｒｔ  ｔａｓｋ  Ｂ
＝ 「タスクBを着手するためには、タスクAが完了されていなければならない」 
（２）ＳＳ（開始−開始）
ｍｕｓｔ  Ｓｔａｒｔ  ｔａｓｋ  Ａ  ｔｏ  Ｓｔａｒｔ  ｔａｓｋ  Ｂ
＝ 「タスクBを着手するためには、タスクAが着手されていなければならない」 
（３） ＦＦ（終了−終了）
ｍｕｓｔ  Ｆｉｎｉｓｈ  ｔａｓｋ  Ａ  ｔｏ  Ｆｉｎｉｓｈ  ｔａｓｋ  Ｂ
＝ 「タスクBを終了するためにはタスクAが終了されていなければならない」 
（４）ＳＦ（開始−終了）
ｍｕｓｔ  Ｓｔａｒｔ  ｔａｓｋ  Ａ  ｔｏ  Ｆｉｎｉｓｈ  ｔａｓｋ  Ｂ
＝ 「タスクBを終了するためにはタスクAが着手されていなければならない」 
【０００６】
上記理論を背景として、業務の進捗管理を効率的に行うことを目的として、「ＭＳ−ＰＲＯＪＥＣＴ」（マイクロソフトの商標）等のプロジェクト管理ツールが提供されてきた。
【０００７】
また、プロジェクトにおけるコミュニケーショントラブルを削減するために、ステークホルダに対して自動的に適切な連絡を行うことにより、プロジェクトの変更管理方法および装置が発案されている（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特願２００３−２６１２９ 公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明が解決しようとする対象業務は、プロジェクト型業務におけるプロジェクト管理業務である。
【００１０】
組織が行う活動には、定型業務とプロジェクト型業務の２種類がある。
・定型業務：日常的、反復的で、組織が存続する限り続行される一連のタスク。
・プロジェクト型業務：反復的、継続的ではない活動を指し一回限りのタスク。
【００１１】
プロジェクト型業務とは、反復的、継続的でない活動を示す。つまり、プロジェクトは１回限りの一時的な活動であるり、多くの場合、組織の戦略的目標を達成するために実施される。プロジェクトは、新しい計画、製品または活動を特定の終了日までに作成または完了することによって終わる一連のタスクである。
【００１２】
上で述べたように、プロジェクト型業務であるソフトウェア開発、アプリケーションエンジニアリング等の分野での、ある一つのタスクを実行するプロセスにおいて、新たな課題の発生とその解決のためのプロセスが常に必要となる業務では、プロジェクト管理者だけによって全てのタスクの作業者との関係を調整することは非常に非効率である。
【００１３】
上記の領域でのプロジェクト管理においては、コミュニケーション管理の重要性が指摘されてきた。インターネット＜ＵＲＬ： http://www.thinkit.co.jp/free/project/1/7/1.html＞
【００１４】
それにもかかわらず、プロジェクトは不具合がもつれにもつれて収拾がつかなくなることがしばしばあり、そうしたトラブルの元をたどると、コミュニケーションの不備にたどりつく。
【００１５】
また、プロジェクト型業務での重要なコミュニケーションコストの多くは、前工程のタスクと後工程との引継ぎ時に発生する。そこで、これをこれまでのガントチャートのタスクの依存関係で捉えなおすと、ＳＦの関係になる。つまり、「タスクBを終了するためにはタスクAの引き継が開始されていなければならない」 となるが、一般的にＳＦの関係はほとんど使われないようである。
【００１６】
その上、プロジェクト管理業務を支援するアプリケーションで具体的にコミュニケーションのコストを表示して、集計可能としているものは見当たらない。また、コミュニケーションのコストを独立したタスクとして追加すると、ＷＢＳのリストがその分長くなり、管理工数が増大するという欠点がある。
【００１７】
そもそも、ＷＢＳとガントチャートの手法は最初に業務全体をＷＢＳで詳細レベルまでモデリングして管理する方式であり、基本的にタスク間の関係はプロジェクト管理者によって管理されることを前提としている。このため、既存のツールは別々のタスクを実行する担当者間の関係が管理者によって制御可能ないわゆる定型業務や繰り返し行われる生産プロセスのような業務に対しては有効であった。
【００１８】
しかし、プロジェクト型業務では業務の種類が異なるにもかかわらず現状では、担当者同士のコミュニケーションコストを考慮しない理論を前提でプロジェクト管理を行っている。このため、本来各タスクのコストであるコミュニケーションコストが、既存のプロジェクト管理業務を支援するアプリケーションでは明示的に表示されていないだけでなく、タスクが必要とする工数として集計されていなかった。
【００１９】
このように、従来のプロジェクト管理者の手腕に依存する状態を表したままのＷＢＳとガントチャートの手法を利用すると、手段が行為を制限することなる。つまり、本来は関連する担当者間のコミュニケーションであるべきところが、プロジェクト管理者を介したコミュニケーションに置き換えられてしまう。このため、コミュニケーションに長けたプロジェクト管理者が必要となる。
【００２０】
つまり、プロジェクト型業務において、現在のガントチャートのままでは本来のあるべきタスクの依存関係を表していない。このためプロジェクトの多くは、計画と作業実態の乖離を引き起こすか、過剰な工数見積もりをしたスケジュールで作業を実施するかの結果が導かれる。
【００２１】
以上のことから、このコミュニケーションコストを、タスクに必要な工数としてバーチャートとして表示し集計可能にすることが、コミュニケーションを管理するため必要である。そして、このコミュニケーションの数だけプロジェクトの不確定性が増大することが、プロジェクト型業務の課題として存在する。
【００２２】
従って正しく捕らえなおすとプロジェクト型業務は、時間的な前後関係のあるタスクを実行する担当者同士が直接コミュニケーションを図ることにより業務を円滑に運営することが前提である。要するに、このコミュニケーションコストをタスクに必要な工数としてバーチャートとして表示し集計可能にすることが、プロジェクト管理の困難性を可視化する観点から課題であった。
【課題を解決するための手段】
【００２３】
上記課題を達成するためになされた本発明 は、タスク間のコミュニケーションをそれぞれのタスクの担当者が主体となってコミュニケーションを行うことを表現するために、ガントチャートでのＳＦの依存性の関係であってもバーチャートに重なり箇所を設けて表現し、この重なりによってタスク間のコミュニケーションコストを表示させる表示制御部を有する。
【００２４】
また、これまでのタスクの作業工数とは別にコミュニケーションコストを入力するステップと、該当タスク毎のコミュニケーションコストを集計するステップと、該当タスクの工数としてコミュニケーションコストを合計するステップを有する。
【００２５】
ただし、タスク間のコミュニケーションコストの重なりの期間は半日から１日である。半日より短い期間の計画は、計画を立てることが煩雑になり、１日より長いコミュニケーション期間になる場合は、独立したタスクとして定義することが適切である。
【発明の効果】
【００２６】
本発明によれば、タスクの連携に掛かるコミュニケーションコストを集計することにより、本来のタスクの工数が把握可能となる。併せて、現実的な計画の立案とその計画に沿ったプロジェクトの進行が可能となる。
【図面の簡単な説明】
【００２７】
【図１】は、本発明の基本理論を表示した図である。
【図２】は、一般的なガントチャートの４種類の論理的なタスクの依存関係を示す図である。
【図３】は、本発明の好適な実施状況をを示す図である。
【図４】は、計画（Ｐｌａｎ）、指示（Ｉｎｓｔｒｕｃｔｉｏｎ）、実行（Ａｃｔｉｏｎ）およびマイルストーン（Ｍｉｌｅｓｔｏｎｅ）を表す図である。
【図５】は、コミュニケーションコストとして工数を入力し、タスクの工数とコミュニケーションコストが集計された結果を表す図である。
【発明を実施するための最良の形態】
【００２８】
本発明の実施においては、上記課題を解決するための手段に加え、 タスクの役割としての属性を追加することが望ましい。
【００２９】
また、タスクの重なり箇所が発生した場合、スケジュールアプリケーションから該当担当者のスケジュールを受信して表示する機能を備えてもよい。
【００３０】
また、タスクの重なり箇所が発生した場合、上記の該当担当者のスケジュール状況を含め、該当担当者にその重なり状況ををメールなどにより通知するための機能を備えてもよい。
【００３１】
また、タスクの重なり箇所が発生した場合、該当担当者にその重なり期間での会議室等の状況をなどを上記メールで合わせて通知するための機能を備えてもよい。
【００３２】
また、タスク数とタスクの工数とコミュニケーションコストから、プロジェクトの不確定性を計算するプログラムを備えてもよい。
【００３３】
まず図１に基づき、本実施の形態に係わる実施状況を説明する。
図1は、本発明の基本理論を表示した図である。 前工程と後工程のタスクの重なりとその関連を示す矢印を示す。タスク間のコミュニケーションコストの重なりの期間が生じていることを、明確に示すための形状としている。
【００３４】
図２は、一般的なガントチャートの４種類の論理的なタスクの依存関係を示す図である。これは、これまでのタスクの依存関係を示す矢印の形状である。
【００３５】
図３は本発明の好適な実施状況をを示す図である。ガントチャートは、ロールに開始日と終了日を持った帯で表し、先行タスクと後続タスクの関連を矢印で結び、この結ばれた状態をネットワークと呼ぶ。このアプリケーションでは、プロジェクトをＷＢＳに基づいて展開したタスクでの役割（ロール）を定義したものを縦軸とし、それぞれに役割の属性を付加する。
【００３６】
本発明の好適な実施状況において、タスクの属性は図４に示すように、計画（Ｐｌａｎ）１０１、指示（Ｉｎｓｔｒｕｃｔｉｏｎ）１０２、実行（Ａｃｔｉｏｎ）１０３およびマイルストーン（Ｍｉｌｅｓｔｏｎｅ）１０４は、それぞれ独自の形状を持つ。
【００３７】
この、ロールの役割としての属性は、Ｐｌａｎ１０１はプロジェクトマネージャの役割、Ｉｎｓｔｒｕｃｔｉｏｎ１０２はリーダの役割、Ａｃｔｉｏｎ１０４は担当者の役割と定義する。マイルストーン１０４はロールの期限以外の守らなければならない最終期限を示す。
【００３８】
Ｐｌａｎ１０４でプロジェクトマネージャは進捗管理を行い、Ｉｎｓｔｒｕｃｔｉｏｎ１０２でリーダは工程管理を行う。リーダは、そのほかに作業指示、課題管理、実績管理を行い、作業の実施状況の報告をプロジェクトマネージャに行う。
【００３９】
ただし、コミュニケーションコストの明示的な追加は、タスクの役割がＡｃｔｉｏｎ１０３の場合のみ表示するればよい。Ｐｌａｎ１０１とＩｎｓｔｒｕｃｔｉｏｎ１０２の役割はコミュニケーションが主な仕事になるため、コミュニケーションコストを新たに付け加える必要はない。
【００４０】
また、ＳＦの関係で、後作業を前倒しする場合と遅らせる場合を図５に示す。
【００４１】
後続タスクの開始を前倒しする場合で例えば、後続タスクの最初の前準備作業は先行タスクの終了を待たずに始められるような場合において、後続タスクを開始してから先行タスクが終了するまでの期間を「リードタイム」と呼ぶ。
【００４２】
また、後続タスクの開始を遅らせる場合で例えば部品が搬入されるまで始められない場合において、先行タスクが終了してから後続タスクを開始するまでの期間を「ラグタイム」と呼ぶ。 
【００４３】
上記「リードタイム」の場合においても、後続タスクの最初の前準備作業は先行タスクとのコミュニケーション、つまり先行タスクと後続タスクの担当者での共同作業のため、本発明とは異なる。
【００４４】
従って、上述した実施の形態の様にプロジェクト型業務のタスクの役割を明確にすることは、コミュニケーションコストとその発生箇所を明確にしプロジェクト計画の立案精度を高め、結果としてプロジェクト管理の有効性が高まる。
【符号の説明】
【００４５】
１０１  計画（Ｐｌａｎ）
１０２  指示（Ｉｎｓｔｒｕｃｔｉｏｎ）
１０３  実行（Ａｃｔｉｏｎ）
１０４  マイルストーン（Ｍｉｌｅｓｔｏｎｅ）
【図１】
2011013958.tif 000003
【図２】
2011013958.tif 000004
【図３】
2011013958.tif 000005
【図４】
2011013958.tif 000006
【図５】
2011013958.tif 000007