図面 (/)

技術 プロジェクトでの依存性の関係のあるタスク間のコミュニケーションのコスト管理を提供する方法

出願人 小川恒生
発明者 小川恒生
出願日 2009年7月2日 (11年4ヶ月経過) 出願番号 2009-157855
公開日 2011年1月20日 (9年10ヶ月経過) 公開番号 2011-013958
状態 未査定
技術分野 特定用途計算機
主要キーワード 作業実態 長けた スケジュール状況 所要期間 後続タスク 先行タスク 最終期限 ステークホルダ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2011年1月20日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (6)

課題

従来のプロジェクト管理アプリケーションにおけるガントチャートタスクは、実行順序依存関係制約されているが、現実的にはその依存関係だけでは関連するタスクの作業担当者が行うコミュニケーションコストは表現できない。このため、このコミュニケーションコストを、タスクに必要な工数としてバーチャートとして表示し集計可能にすることが、プロジェクト管理の精度と有効性の観点から課題であった。

解決手段

本特許の目的は、実行順序の依存関係にあるタスクにコミュニケーションコストを示すバーチャートの重なり箇所を設け、合わせてその関連を示す矢印を表示し、合わせてその重なりをタスクの工数として集計可能とすること。

概要

背景

一般的に、ソフトウェア開発アプリケーションエンジニアリングの分野では、プロジェクト計画プロジェクト管理業務として行われている。そのプロジェクト管理手法は、プロジェクトマネージャががメンバータスク細部まで明確に定めて厳格に管理を行うことが前提である。これらのタスクの洗い出しを階層的に行ったリストをWBS(Work Breakdown Structure)と呼ぶ。

従来、このプロジェクト管理業務を支援するアプリケーションでのガントチャート(Ganttchart) を用いた工程管理画面では、WBSで分解したタスクを縦軸にし、その期間を横軸として表現している。縦軸に書き出されるタスクは、処理の最小単位作業工程として表現される。これに、その作業工程の所要期間バーチャートとして表し、その各タスクに実行順序依存関係を付け加えることで、ガントチャートとしていた。

ところで、一般的にガントチャートはタスクの依存関係を論理的に次の4つのパターンとしている。

タスクの依存関係
(1)FS(終了−開始)
must Finish task A to Start task B
= 「タスクBを着手するためには、タスクAが完了されていなければならない」
(2)SS(開始−開始)
must Start task A to Start task B
= 「タスクBを着手するためには、タスクAが着手されていなければならない」
(3)FF(終了−終了)
must Finish task A to Finish task B
= 「タスクBを終了するためにはタスクAが終了されていなければならない」
(4)SF(開始−終了)
must Start task A to Finish task B
= 「タスクBを終了するためにはタスクAが着手されていなければならない」

上記理論を背景として、業務の進捗管理を効率的に行うことを目的として、「MS−PROJECT」(マイクロソフト商標)等のプロジェクト管理ツールが提供されてきた。

また、プロジェクトにおけるコミュニケーショントラブルを削減するために、ステークホルダに対して自動的に適切な連絡を行うことにより、プロジェクトの変更管理方法および装置が発案されている(例えば特許文献1参照)。

概要

従来のプロジェクト管理アプリケーションにおけるガントチャートのタスクは、実行順序の依存関係で制約されているが、現実的にはその依存関係だけでは関連するタスクの作業担当者が行うコミュニケーションのコストは表現できない。このため、このコミュニケーションコストを、タスクに必要な工数としてバーチャートとして表示し集計可能にすることが、プロジェクト管理の精度と有効性の観点から課題であった。本特許の目的は、実行順序の依存関係にあるタスクにコミュニケーションコストを示すバーチャートの重なり箇所を設け、合わせてその関連を示す矢印を表示し、合わせてその重なりをタスクの工数として集計可能とすること。

目的

効果

実績

技術文献被引用数
0件
牽制数
1件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ガントチャートに示されるプロジェクト管理画面において、実行順序依存関係のあるタスク担当者間コミュニケーション期間を既存のタスクの期間を延長したバーチャートとして、該当タスクを表示するステップを含むことを特徴とする方法。

請求項2

該当タスク毎コミュニケーションコストを入力するステップと、該当タスク毎のコミュニケーションコストを集計するステップおよび、該当タスクの工数としてコミュニケーションコストを合計するステップを有する請求項1に記載の方法。

技術分野

背景技術

0002

一般的に、ソフトウェア開発、アプリケーションエンジニアリングの分野では、プロジェクト計画がプロジェクト管理業務として行われている。そのプロジェクト管理手法は、プロジェクトマネージャががメンバータスク細部まで明確に定めて厳格に管理を行うことが前提である。これらのタスクの洗い出しを階層的に行ったリストをWBS(Work Breakdown Structure)と呼ぶ。

0003

従来、このプロジェクト管理業務を支援するアプリケーションでのガントチャート(Ganttchart) を用いた工程管理画面では、WBSで分解したタスクを縦軸にし、その期間を横軸として表現している。縦軸に書き出されるタスクは、処理の最小単位作業工程として表現される。これに、その作業工程の所要期間バーチャートとして表し、その各タスクに実行順序依存関係を付け加えることで、ガントチャートとしていた。

0004

ところで、一般的にガントチャートはタスクの依存関係を論理的に次の4つのパターンとしている。

0005

タスクの依存関係
(1)FS(終了−開始)
must Finish task A to Start task B
= 「タスクBを着手するためには、タスクAが完了されていなければならない」
(2)SS(開始−開始)
must Start task A to Start task B
= 「タスクBを着手するためには、タスクAが着手されていなければならない」
(3)FF(終了−終了)
must Finish task A to Finish task B
= 「タスクBを終了するためにはタスクAが終了されていなければならない」
(4)SF(開始−終了)
must Start task A to Finish task B
= 「タスクBを終了するためにはタスクAが着手されていなければならない」

0006

上記理論を背景として、業務の進捗管理を効率的に行うことを目的として、「MS−PROJECT」(マイクロソフト商標)等のプロジェクト管理ツールが提供されてきた。

0007

また、プロジェクトにおけるコミュニケーショントラブルを削減するために、ステークホルダに対して自動的に適切な連絡を行うことにより、プロジェクトの変更管理方法および装置が発案されている(例えば特許文献1参照)。

先行技術

0008

特願2003−26129 公報

発明が解決しようとする課題

0009

本発明が解決しようとする対象業務は、プロジェクト型業務におけるプロジェクト管理業務である。

0010

組織が行う活動には、定型業務とプロジェクト型業務の2種類がある。
・定型業務:日常的、反復的で、組織が存続する限り続行される一連のタスク。
・プロジェクト型業務:反復的、継続的ではない活動を指し一回限りのタスク。

0011

プロジェクト型業務とは、反復的、継続的でない活動を示す。つまり、プロジェクトは1回限りの一時的な活動であるり、多くの場合、組織の戦略的目標を達成するために実施される。プロジェクトは、新しい計画製品または活動を特定の終了日までに作成または完了することによって終わる一連のタスクである。

0012

上で述べたように、プロジェクト型業務であるソフトウェア開発、アプリケーションエンジニアリング等の分野での、ある一つのタスクを実行するプロセスにおいて、新たな課題の発生とその解決のためのプロセスが常に必要となる業務では、プロジェクト管理者だけによって全てのタスクの作業者との関係を調整することは非常に非効率である。

0013

上記の領域でのプロジェクト管理においては、コミュニケーション管理重要性が指摘されてきた。インターネット<URL: http://www.thinkit.co.jp/free/project/1/7/1.html>

0014

それにもかかわらず、プロジェクトは不具合もつれにもつれて収拾がつかなくなることがしばしばあり、そうしたトラブルの元をたどると、コミュニケーションの不備にたどりつく。

0015

また、プロジェクト型業務での重要なコミュニケーションコストの多くは、前工程のタスクと後工程との引継ぎ時に発生する。そこで、これをこれまでのガントチャートのタスクの依存関係で捉えなおすと、SFの関係になる。つまり、「タスクBを終了するためにはタスクAの引き継が開始されていなければならない」 となるが、一般的にSFの関係はほとんど使われないようである。

0016

その上、プロジェクト管理業務を支援するアプリケーションで具体的にコミュニケーションのコストを表示して、集計可能としているものは見当たらない。また、コミュニケーションのコストを独立したタスクとして追加すると、WBSのリストがその分長くなり、管理工数が増大するという欠点がある。

0017

そもそも、WBSとガントチャートの手法は最初に業務全体をWBSで詳細レベルまでモデリングして管理する方式であり、基本的にタスク間の関係はプロジェクト管理者によって管理されることを前提としている。このため、既存のツールは別々のタスクを実行する担当者間の関係が管理者によって制御可能ないわゆる定型業務や繰り返し行われる生産プロセスのような業務に対しては有効であった。

0018

しかし、プロジェクト型業務では業務の種類が異なるにもかかわらず現状では、担当者同士のコミュニケーションコストを考慮しない理論を前提でプロジェクト管理を行っている。このため、本来各タスクのコストであるコミュニケーションコストが、既存のプロジェクト管理業務を支援するアプリケーションでは明示的に表示されていないだけでなく、タスクが必要とする工数として集計されていなかった。

0019

このように、従来のプロジェクト管理者の手腕に依存する状態を表したままのWBSとガントチャートの手法を利用すると、手段が行為を制限することなる。つまり、本来は関連する担当者間のコミュニケーションであるべきところが、プロジェクト管理者を介したコミュニケーションに置き換えられてしまう。このため、コミュニケーションに長けたプロジェクト管理者が必要となる。

0020

つまり、プロジェクト型業務において、現在のガントチャートのままでは本来のあるべきタスクの依存関係を表していない。このためプロジェクトの多くは、計画と作業実態乖離を引き起こすか、過剰な工数見積もりをしたスケジュールで作業を実施するかの結果が導かれる。

0021

以上のことから、このコミュニケーションコストを、タスクに必要な工数としてバーチャートとして表示し集計可能にすることが、コミュニケーションを管理するため必要である。そして、このコミュニケーションの数だけプロジェクトの不確定性が増大することが、プロジェクト型業務の課題として存在する。

0022

従って正しく捕らえなおすとプロジェクト型業務は、時間的な前後関係のあるタスクを実行する担当者同士が直接コミュニケーションを図ることにより業務を円滑に運営することが前提である。要するに、このコミュニケーションコストをタスクに必要な工数としてバーチャートとして表示し集計可能にすることが、プロジェクト管理の困難性を可視化する観点から課題であった。

課題を解決するための手段

0023

上記課題を達成するためになされた本発明 は、タスク間のコミュニケーションをそれぞれのタスクの担当者が主体となってコミュニケーションを行うことを表現するために、ガントチャートでのSFの依存性の関係であってもバーチャートに重なり箇所を設けて表現し、この重なりによってタスク間のコミュニケーションコストを表示させる表示制御部を有する。

0024

また、これまでのタスクの作業工数とは別にコミュニケーションコストを入力するステップと、該当タスク毎のコミュニケーションコストを集計するステップと、該当タスクの工数としてコミュニケーションコストを合計するステップを有する。

0025

ただし、タスク間のコミュニケーションコストの重なりの期間は半日から1日である。半日より短い期間の計画は、計画を立てることが煩雑になり、1日より長いコミュニケーション期間になる場合は、独立したタスクとして定義することが適切である。

発明の効果

0026

本発明によれば、タスクの連携に掛かるコミュニケーションコストを集計することにより、本来のタスクの工数が把握可能となる。併せて、現実的な計画の立案とその計画に沿ったプロジェクトの進行が可能となる。

図面の簡単な説明

0027

は、本発明の基本理論を表示した図である。
は、一般的なガントチャートの4種類の論理的なタスクの依存関係を示す図である。
は、本発明の好適な実施状況をを示す図である。
は、計画(Plan)、指示(Instruction)、実行(Action)およびマイルストーン(Milestone)を表す図である。
は、コミュニケーションコストとして工数を入力し、タスクの工数とコミュニケーションコストが集計された結果を表す図である。

発明を実施するための最良の形態

0028

本発明の実施においては、上記課題を解決するための手段に加え、タスクの役割としての属性を追加することが望ましい。

0029

また、タスクの重なり箇所が発生した場合、スケジュールアプリケーションから該当担当者のスケジュールを受信して表示する機能を備えてもよい。

0030

また、タスクの重なり箇所が発生した場合、上記の該当担当者のスケジュール状況を含め、該当担当者にその重なり状況ををメールなどにより通知するための機能を備えてもよい。

0031

また、タスクの重なり箇所が発生した場合、該当担当者にその重なり期間での会議室等の状況をなどを上記メールで合わせて通知するための機能を備えてもよい。

0032

また、タスク数とタスクの工数とコミュニケーションコストから、プロジェクトの不確定性を計算するプログラムを備えてもよい。

0033

まず図1に基づき、本実施の形態に係わる実施状況を説明する。
図1は、本発明の基本理論を表示した図である。 前工程と後工程のタスクの重なりとその関連を示す矢印を示す。タスク間のコミュニケーションコストの重なりの期間が生じていることを、明確に示すための形状としている。

0034

図2は、一般的なガントチャートの4種類の論理的なタスクの依存関係を示す図である。これは、これまでのタスクの依存関係を示す矢印の形状である。

0035

図3は本発明の好適な実施状況をを示す図である。ガントチャートは、ロール開始日と終了日を持った帯で表し、先行タスク後続タスクの関連を矢印で結び、この結ばれた状態をネットワークと呼ぶ。このアプリケーションでは、プロジェクトをWBSに基づいて展開したタスクでの役割(ロール)を定義したものを縦軸とし、それぞれに役割の属性を付加する。

0036

本発明の好適な実施状況において、タスクの属性は図4に示すように、計画(Plan)101、指示(Instruction)102、実行(Action)103およびマイルストーン(Milestone)104は、それぞれ独自の形状を持つ。

0037

この、ロールの役割としての属性は、Plan101はプロジェクトマネージャの役割、Instruction102はリーダの役割、Action104は担当者の役割と定義する。マイルストーン104はロールの期限以外の守らなければならない最終期限を示す。

0038

Plan104でプロジェクトマネージャは進捗管理を行い、Instruction102でリーダは工程管理を行う。リーダは、そのほかに作業指示、課題管理、実績管理を行い、作業の実施状況の報告をプロジェクトマネージャに行う。

0039

ただし、コミュニケーションコストの明示的な追加は、タスクの役割がAction103の場合のみ表示するればよい。Plan101とInstruction102の役割はコミュニケーションが主な仕事になるため、コミュニケーションコストを新たに付け加える必要はない。

0040

また、SFの関係で、後作業前倒しする場合と遅らせる場合を図5に示す。

0041

後続タスクの開始を前倒しする場合で例えば、後続タスクの最初の前準備作業は先行タスクの終了を待たずに始められるような場合において、後続タスクを開始してから先行タスクが終了するまでの期間を「リードタイム」と呼ぶ。

0042

また、後続タスクの開始を遅らせる場合で例えば部品搬入されるまで始められない場合において、先行タスクが終了してから後続タスクを開始するまでの期間を「ラグタイム」と呼ぶ。

0043

上記「リードタイム」の場合においても、後続タスクの最初の前準備作業は先行タスクとのコミュニケーション、つまり先行タスクと後続タスクの担当者での共同作業のため、本発明とは異なる。

0044

従って、上述した実施の形態の様にプロジェクト型業務のタスクの役割を明確にすることは、コミュニケーションコストとその発生箇所を明確にしプロジェクト計画の立案精度を高め、結果としてプロジェクト管理の有効性が高まる。

0045

101計画(Plan)
102 指示(Instruction)
103 実行(Action)
104マイルストーン(Milestone)

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ