JP2013190972A - プロジェクト管理支援システムおよびプロジェクト管理支援プログラム - Google Patents

Abstract

【課題】システム構築プロジェクトにおけるタスクの実施に対して影響する様々な要因に対して、タスクを実施する担当者毎の生産性をより的確に把握して、タスクのスケジュールに柔軟に反映させることを可能とするプロジェクト管理支援システムを提供する。
【解決手段】プロジェクトで実施すべき１つ以上のタスクを定義してタスクＤＢ２１に登録するスケジュール作成部１０と、プロジェクトメンバーからのタスクの実施を担当する旨および作業工数の自己申告を受け付けて、当該プロジェクトメンバーを当該タスクの担当者としてタスクＤＢ２１に記録された対応するタスクに登録する申告登録部２０とを有し、スケジュール作成部１０は、プロジェクトマネージャーからの指示に基づいて、タスクＤＢ２１に登録された各タスクについてのスケジューリングを行う。
【選択図】図１

Description

本発明は、プロジェクトの管理技術に関し、特に、システム構築プロジェクトにおいて、スケジュール管理を柔軟に行うことを可能とするプロジェクト管理支援システムおよびプロジェクト管理支援プログラムに適用して有効な技術に関するものである。

従来、例えば、情報処理システムの構築などのプロジェクトでは、スケジュールを作成して管理するにあたり、まず必要な作業をタスクとして定義し、これに基づいてガントチャート等を作成し、各タスクの見積工数と標準工数（例えば、１人月あたりの処理量など）に基づいて適当な量のリソース（作業者などの人や物、金）を割り当てるという形態がとられるのが一般的である。

例えば、特開２００２−９２２８２号公報（特許文献１）には、プロジェクトを遂行するために必要な人員、機材、能力、資格を含む資源に関するリソース情報に基づいて、階層別業務単位毎にリソースと時間を割り当てて実行計画を作成する階層別業務実行計画作成手段と、予算作成に必要な予算作成情報に基づいて、階層別業務単位毎に階層別業務予算を作成する階層別業務予算作成手段と、前記階層別業務実行計画作成手段によって作成された実行計画と、前記階層別業務予算作成手段によって作成された階層別業務予算と、に基づいて所定の演算手法により意思決定のための判断指標を作成する意思決定指標作成手段と、前記意思決定指標作成手段によって作成された判断指標を表示する表示手段と、を備えることで、プロジェクトを遂行するための正しい活動を管理・評価でき、計画、実行、確認段階での管理者の意思決定を支援するプロジェクト管理支援装置等が記載されている。

特開２００２−９２２８２号公報

しかしながら、プロジェクトの遂行に際しては、様々な要因に基づいて、各タスクの進捗が遅れたり、逆に早まったりすることも多く、必ずしも作成・定義したスケジュール通りに進捗しないことが多々ある。

例えば、各担当者（リソース）のスキルや得意分野に応じて実際の作業に要する工数が標準工数とは異なってくることは通常である。これ以外にも、開発に使用されるプログラミング言語やツール、開発手法など、開発環境において利用される技術面での相違により生産性が異なってくる場合もある。また、チームやグループの人数やメンバーの編成などの人的環境によって生産性が異なってくる場合もある。前工程での成果物の品質によって後工程の生産性が影響されることも通常経験される。これらの要素を考慮しつつ各タスクの工数を見積もってスケジュールを作成することはなかなか困難である。

また、スケジュールに従った各タスクの実施状況の管理について、例えば、タスクの進捗が遅れる場合は、後続のタスク、ひいてはプロジェクト全体に影響が及ぶことから注意深くチェックされ、追加のリソース投入などによりリカバリーが図られることが多い。

一方、タスクの進捗が予定よりも早くなる場合は、後続のタスクへの影響がないことからあまりチェックされない場合が多い。タスクの担当者も、タスクが早く完了したことを敢えて報告せず、当初の予定通りに完了したものとして報告する場合も多い。その結果、早期に完了したタスクの担当者は、予定されていたタスクの終了日まで無駄に過ごすことになる。さらに、まだ作業の実施中であるということをアピールするため、無駄に作業を膨らませたり、他のチームの作業に無用な干渉をしたりなどの悪影響を生じる場合すらある。実際上は、タスクを早期に完了させることができる担当者は能力が高いことが多く、このような担当者の作業余力、すなわち「空き」を無為に浪費することはプロジェクトの効率的な遂行に対して損失となる。

そこで本発明の目的は、システム構築プロジェクトにおけるタスクの実施に対して影響する様々な要因に対して、タスクを実施する担当者毎の生産性をより的確に把握して、タスクのスケジュールに柔軟に反映させることを可能とするとともに、担当者の「空き」が生じた場合でも、これが有効に活用されるように動機付けすることを可能とするプロジェクト管理支援システムおよびプロジェクト管理支援プログラムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるプロジェクト管理支援システムは、システム構築プロジェクトにおける各タスクのスケジュール、および各タスクに割り当てるプロジェクトメンバーの管理を支援するシステムであって、プロジェクトで実施すべき１つ以上のタスクを定義してタスク記録手段に登録するスケジュール作成部と、プロジェクトメンバーからのタスクの実施を担当する旨および作業工数の自己申告を受け付けて、当該プロジェクトメンバーを当該タスクの担当者として、前記タスク記録手段に記録された対応するタスクに登録する申告登録部とを有し、前記スケジュール作成部は、プロジェクトマネージャーからの指示に基づいて、前記タスク記録手段に登録された各タスクについてのスケジューリングを行うことを特徴とするものである。

また、本発明は、コンピュータを上記のようなプロジェクト管理支援システムとして動作させるプログラムにも適用することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、システム構築プロジェクトにおけるタスクの実施に対して影響する様々な要因に対して、タスクを実施する担当者毎の生産性をより的確に把握して、タスクのスケジュールに柔軟に反映させることが可能となるとともに、担当者の「空き」が生じた場合でも、これが有効に活用されるように動機付けすることが可能となる。

本発明の一実施の形態であるプロジェクト管理支援システムの構成例について概要を示した図である。 本発明の一実施の形態におけるプロジェクトＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態におけるタスクＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における実績ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態におけるリソースＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における生産性ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態におけるプロジェクトのタスクのスケジュール管理の処理の流れの例について概要を示したフローチャートである。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜概要＞
本発明の一実施の形態であるプロジェクト管理支援システムは、システム構築プロジェクト（以下では単に「プロジェクト」と記載する場合がある）における各タスクのスケジュール、および各タスクに割り当てるリソース（作業の担当者）の管理を主に支援するシステムである。本実施の形態では、例えば、プロジェクトにおいて実施される各タスクについてのスケジュールを作成する際、タスクで必要となる標準工数もしくは担当者から申告された作業工数に対して、割り当てた担当者の生産性を示す指標に基づいて補正を行い、補正結果の工数に基づいてスケジュールを調整することを可能とする。

各担当者の生産性については、例えば、スキルや得意分野など、当該担当者に固有の属性としての指標だけでなく、当該プロジェクトにおける技術的、人的なものを含む環境面での指標も含まれる。また、過去のプロジェクトも含むこれまでの各タスクの実施（当該タスクでの実施状況だけでなく後工程や他のプロジェクト等に与えた影響も考慮）によって蓄積された実績情報に基づいてこれらの指標の値を補正することで、担当者の成長なども反映させつつ、可能な限り実態に即した実質的、総合的な意味での生産性の指標とすることを可能とする。

上述したように、プロジェクトの遂行に際しては、様々な要因に基づいて、各タスクの進捗が遅れたり、逆に早まったりすることも多く、必ずしも標準工程に基づいて作成・定義したスケジュール通りに進捗しないことが多々ある。例えば、システム開発のプロジェクトでは、一般的に、設計や開発、問題解決などに関するタスクについては、担当者間のスキル等の個人差に起因する生産性の差が大きいとされる。例えば、同じ担当者でも作業内容や求められるスキル等によって生産性が異なる場合があり、設計は得意だが開発は苦手であるとか、コーディングは遅いがバグフィックスは速い、使用するプログラミング言語においてＪａｖａ（登録商標）は得意だがＣＯＢＯＬは苦手であるなど、種々の要素で生産性の相違があり得る。

また、システム開発の環境面において、利用する技術やその進歩によって生産性が異なる場合がある。例えば、自動ソースコード生成ツールや、テスト自動化ツール、その他各種開発ツールを利用することによって生産性が向上することが考えられる。また、アジャイル開発などの新しい開発手法を採用することによっても生産性は異なり得る。また、外販モジュールの再利用や他のＡＳＰ（Application Service Provider）サービスの利用など、利用型の開発形態をとることによっても生産性は異なり得る。

また、システム開発の環境面における人的な側面によっても生産性が異なる場合がある。例えば、タスクを実施する際のチームの人数が増えるほど生産性が低下するという場合や、メンバーの組み合わせなどの編成によって生産性が異なるという場合もあり得る。チーム内に１人飛び抜けて能力の高いメンバーがいるような場合、他のメンバーが少し質問等するだけで課題が解決されるなど、（他のメンバー、ひいてはタスクとしての）生産性が向上する場合もある。

このように、様々な要因に基づいてタスクの生産性は変動し、これを考慮したスケジューリングはなかなか困難である。そこで、このような生産性の変動や担当者間での相違などを考慮したタスクのスケジューリングを可能とし、また、生産性が高いために早期に作業の実施を完了した担当者の「空き」を有効に活用できるようにするため、本実施の形態では、タスクのスケジューリングに際して担当者からの自己申告制をとるものとする。

すなわち、実施すべきタスクに対して、各担当者もしくはチームが、どこまでのタスクをどれだけの期間で実施するのかを自己申告（登録）するものとし、プロジェクトマネージャーは、原則として自己申告された内容に基づいて各タスクをスケジューリングする。なお、自己申告制とすると、過少申告する（期間を長く、もしくは工数を多く申告する）ことが考えられる。そこでこれを防止するため、例えば、各タスクについて標準工数（もしくはこれに基づいて算出した作業日数）と比較することで過小か否かを判断できるようにする。また、「空き」ができた場合に他のメンバーやタスクをサポートした場合、これを評価できる（例えば、人事考課や、外部ベンダーに支払う作業者の単価などに反映させる）ようにする。

また、各タスクの実施についての実績を的確に把握し、蓄積された実績情報に基づいて自己申告の信頼の程度に係る情報（例えば信頼度）を求める。求めた信頼度に基づいて各担当者の自己申告の内容を補正し、タスクのスケジューリングに反映させるようにしてもよい。また、蓄積された実績情報と自己申告（信頼度により補正したもの）とに基づいて、各種要因を考慮した生産性もしくはその補正に係る情報を求める。求めた生産性もしくはその補正に係る情報に基づいて各担当者の自己申告（信頼度により補正したもの）をさらに補正し、タスクのスケジューリングに反映させるようにしてもよい。

＜システム構成＞
図１は、本発明の一実施の形態であるプロジェクト管理支援システムの構成例について概要を示した図である。プロジェクト管理支援システム１は、例えば、ＰＣ（Personal Computer）やサーバなどのコンピュータシステムにより構成され、ソフトウェアにより実装されるスケジュール作成部１０、申告登録部２０、実績登録部３０、リソース登録部４０、および生産性評価部５０などの各部を有する。また、データベースやファイルテーブル等により実装されるプロジェクトデータベース（ＤＢ）１１、タスクデータベース（ＤＢ）２１、実績データベース（ＤＢ）３１、リソースデータベース（ＤＢ）４１、および生産性データベース（ＤＢ）５１などの各テーブルと、標準工数情報１２のデータを有する。

スケジュール作成部１０は、プロジェクトＤＢ１１に登録されたシステム構築プロジェクトについて、プロジェクトマネージャー等のユーザにより作成・定義された実施すべきタスクをタスクＤＢ２１に登録するとともに、後述する申告登録部２０を介して受け付けてタスクＤＢ２１に登録された、各タスクについて作業を実施する担当者（リソース）もしくはチームについての自己申告の情報に基づいて、各タスクについてのスケジューリングを行う。ここでのスケジュールに対しては、例えば、リソースＤＢ４１から取得した対象の担当者の自己申告の信頼度の情報や、生産性ＤＢ５１から取得した各担当者の生産性の情報、標準工数情報１２から取得した各タスクの作業について予め定義された標準的な工数の情報などに基づいて所定のルールに従って補正や調整を行うことができる。

一方で、当該補正を含むスケジューリングの処理に際して、変更することができない前提条件や制約条件を予め設定しておき、これに基づいて補正や調整が可能なスケジュールの範囲を制限するようにしてもよい。例えば、開発に使用するハードウェアやソフトウェアの納入時期や、性能テスト実施時における機器の台数やスペックなど、タスクの実施状況に影響を与え得る内容が考えられる。

申告登録部２０は、タスクＤＢ２１に登録されている各タスクのうちの所定のもの（例えば、直近で実施されるものとしてプロジェクトマネージャー等のユーザから指定されたフェーズに含まれる各タスクなど）について、自身（もしくは自チーム）が担当する旨の自己申告をプロジェクトメンバーから受け付けて、その内容をタスクＤＢ２１の該当のタスクに登録する。ここでは、例えば、プロジェクトメンバーもしくはチームは、１つ以上のタスクに対して自身が担当する旨とその作業工数（もしくは作業日数）の情報を少なくとも登録する。

実績登録部３０は、実施された各タスクについて、その実施状況についての実績の情報を取得して実績ＤＢ３１に登録する。実績情報には、例えば、当該タスクの開始・終了が把握できる情報に加えて、終了していない場合には進捗状況を把握することができる情報（例えば、予定された作業のうちどの程度が完了しているかなど）を含んでいてもよい。リソース登録部４０は、プロジェクトの各タスクを実施するのに必要となる各種のリソースの情報を取得してリソースＤＢ４１に登録する。ここで登録されるリソースは主にプロジェクトメンバーなどの人的リソースであるが、例えば、ハードウェアやソフトウェア、場所などの物的リソースを含んでいてもよい。

生産性評価部５０は、実績ＤＢ３１に蓄積されたタスク実施の実績に係る情報に基づいて、各リソース（プロジェクトメンバーなどの作業担当者）についての生産性の情報をそれぞれ計算し、生産性ＤＢ５１に登録する、もしくは生産性ＤＢ５１の内容を更新する。また、各担当者についての自己申告の信頼度の情報をそれぞれ計算し、リソースＤＢ４１に登録する、もしくはリソースＤＢ４１の内容を更新する。ここでの処理は、例えば、バッチ処理により定期的に実行されるようにする。生産性評価部５０での処理の完了後、例えば、ユーザは、スケジュール作成部１０により各タスクのスケジュールを修正するなどの措置をとることができる。

＜データ構成＞
図２は、プロジェクトＤＢ１１のデータ構成の例について概要を示した図である。プロジェクトＤＢ１１は、管理対象のシステム構築ブロジェクトについてその書誌的な内容を保持するテーブルである。データ項目として、例えば、プロジェクトＩＤ、プロジェクト名、対象システム、顧客名、期間、予算、契約形態、開発手法、及び責任者などの各項目を有する。キー項目はプロジェクトＩＤである。

プロジェクトＩＤの項目は、各プロジェクトを一意に識別するために割り振られたＩＤの情報を保持する。プロジェクト名の項目は、対象のプロジェクトの名称の情報を保持する。対象システムの項目は、対象のプロジェクトにおいて開発対象とするシステムの名称や概要等の情報を保持する。顧客名の項目は、対象のプロジェクトの顧客の情報を保持する。期間および予算の項目は、それぞれ、対象のプロジェクトの期間および予算の情報を保持する。契約形態の項目は、対象のプロジェクトにおける顧客との契約形態（例えば、請負や業務委託など）の情報を保持する。開発手法の項目は、対象のプロジェクトにおいて利用する開発手法（メソドロジー）の情報を保持する。開発ツールや言語等の情報を含んでいてもよい。責任者の項目は、対象のプロジェクトの責任者（プロジェクトマネージャーなど）の情報を保持する。

図３は、タスクＤＢ２１のデータ構成の例について概要を示した図である。タスクＤＢ２１は、プロジェクトにおいて実施される（もしくは実施された）各タスクについてその内容を保持するテーブルである。データ項目として、例えば、タスクＩＤ、タスク名、プロジェクトＩＤ、フェーズ、前提タスク、次タスク、期間、工数、担当者、自己申告フラグ、および作業内容などの各項目を有する。キー項目はタスクＩＤとプロジェクトＩＤの複合キーである。

タスクＩＤの項目は、プロジェクト内で各タスクを一意に識別するために割り振られたＩＤの情報を保持する。タスク名の項目は、対象のタスクの名称の情報を保持する。プロジェクトＩＤの項目は、対象のタスクが実施されるプロジェクトのＩＤの情報を保持する。この項目は、上述の図２において示したプロジェクトＤＢ１１のプロジェクトＩＤの項目に対応する。フェーズの項目は、対象のプロジェクトにおいて対象のタスクが実施されるフェーズの情報を保持する。前提タスクおよび次タスクの項目は、それぞれ、対象のタスクの実施を開始するための前提となる（もしくは前工程の）１つ以上のタスク、および対象のタスクの完了を条件として開始される（もしくは後工程の）１つ以上のタスクが存在する場合にそのＩＤの情報を保持する。

期間および工数の項目は、それぞれ、対象のタスクの実施に要するものとして見積もられた期間（もしくは開始日と終了日）および工数の情報を保持する。担当者および自己申告フラグの項目は、それぞれ、対象のタスクを実施する担当者として割り当てられたプロジェクトメンバーの情報、および当該プロジェクトメンバー（もしくは当該プロジェクトメンバーが属するチームや組織）が自己申告によって担当者として割り当てられたものであるか否かを示す情報を保持する。作業内容の項目は、対象のタスクにおいて実施される作業の内容や作成する成果物などに係る情報を保持する。

図４は、実績ＤＢ３１のデータ構成の例について概要を示した図である。実績ＤＢ３１は、プロジェクトにおいて実施された各タスクについて、その実施状況についての実績の情報を保持するテーブルである。データ項目として、例えば、プロジェクトＩＤ、タスクＩＤ、開始日、終了日、進捗状況、成果物、参照タスク、サポート者、およびバグ件数などの各項目を有する。キー項目はプロジェクトＩＤとタスクＩＤの複合キーである。

プロジェクトＩＤおよびタスクＩＤの項目は、それぞれ、対象のタスクが実施されるプロジェクトのＩＤおよび対象のタスクのＩＤの情報を保持する。これらの項目は、それぞれ、上述の図２において示したプロジェクトＤＢ１１のプロジェクトＩＤの項目および図３において示したタスクＤＢ２１のタスクＩＤの項目に対応する。

開始日および終了日の項目は、それぞれ、対象のタスクの実施の開始日および終了日の情報を実績情報として保持する。進捗状況の項目は、対象のタスクが実施中である場合に、その進捗状況を把握できる情報（例えば作業や進捗率や完成した成果物の割合など）を保持する。なお、これらの実績情報は、例えば、既に作業が完了しているのに作業中であると報告したり、逆に作業が遅延しているのに完了したと報告したりするなどの実態とは異なる報告を防止すべく、自動・手動での入力に関わらず、可能な限り的確な実績情報を取得する手段を設けるものとする。

成果物および参照タスクの項目は、それぞれ、対象のタスクにおいて作成された成果物（ドキュメントやソースコード、テストケースなど）、および当該成果物を作成する際に再利用もしくは参照した他の成果物に対応するタスクのＩＤの情報を保持する。サポート者の項目は、対象のタスクの実施の際に担当者以外の他のプロジェクトメンバー等によるサポートを受けた場合に、当該サポート者（もしくはチーム）を特定するための情報を保持する。

なお、これらの情報から把握することができる、成果物を再利用等されたり、他のプロジェクトメンバーをサポートしたりした担当者については、例えば、所定の基準に基づいて後述するリソースＤＢ４１等に評価ポイントとして計上して記録するなどにより、生産性の情報などとともに当該担当者の評価指標の一つとして用いることが可能であり、タスク実施能力の高い担当者の「空き」が有効活用されるよう動機付けするための手段の一つとして用いることも可能である。

バグ件数の項目は、対象のタスクでの作業や成果物に起因して発生したと認められるバグの件数を保持する。ここでのバグは、例えば、テストフェーズにおいてテストケースの抽出の漏れや不備などのバグがあった場合に、その原因が先行する設計フェーズで作成されたドキュメントの不備にあった場合、設計フェーズにおいて当該ドキュメントを作成したタスクや、そのレビューのタスクなど、当該バグを埋め込んだと考えられるタスクに計上する。対象のプロジェクトにおける後のフェーズで発見されたバグに限らず、プロジェクト終了後のシステムの稼働・サービス段階で発見されたバグであっても同様である。

なお、バグが発見されたタスクと、当該バグを埋め込んだ原因のタスクとの関係については、分析の結果としてプロジェクトマネージャー等が入力・指定するようにしてもよいし、バグが発見されたフェーズやタスクの実施内容などに基づいて定型的に決まるような場合は自動で設定するようにしてもよい。

図５は、リソースＤＢ４１のデータ構成の例について概要を示した図である。リソースＤＢ４１は、タスクの実施に用いることができる各リソース（本実施の形態では人的リソースとする）について、そのタスク実施能力に係る内容を含む情報を保持する。データ項目として、例えば、リソースＩＤ、氏名、所属グループ、スキル、および自己申告信頼度などの各項目を有する。キー項目はリソースＩＤである。

リソースＩＤの項目は、各リソースを一意に識別するために割り振られたＩＤの情報を保持する。氏名および所属グループの項目は、それぞれ、対象のリソース（担当者）の氏名および所属する組織やチーム、グループなどの情報を保持する。スキルの項目は、対象のリソースが有するスキルに係る情報を保持する。ここでは、例えば、１つ以上のスキル項目について保有するスキルレベルの情報を保持する。

自己申告信頼度の項目は、タスクへのリソースの割り当ての際に、対象のリソース（担当者）が当該タスクを実施する旨を自己申告した場合に、実施に要する期間として申告された期間の信頼度を示す情報を保持する。例えば、過去の実績において対象の担当者が申告したタスクの所要期間と、当該タスクの実施に実際に要した期間との差に基づいて所定の方法により算出する。この情報により、例えば、対象の担当者はタスクの実施を自己申告する場合に所要期間を過少申告する傾向があるか否か、ある場合にはどの程度かなどを把握することができ、タスクのスケジューリングの際にこれを考慮することができる。

図６は、生産性ＤＢ５１のデータ構成の例について概要を示した図である。生産性ＤＢ５１は、タスクの実施に用いることができる各リソース（本実施の形態では人的リソースとする）についてのタスク実施の際の生産性に係る情報を保持する。データ項目として、例えば、リソースＩＤ、フェーズ、基本生産性、および補正係数などの各項目を有する。キー項目はリソースＩＤとフェーズの複合キーである。

リソースＩＤの項目は、対象のリソースの情報を保持する。この項目は、上述の図５において示したリソースＤＢ４１のリソースＩＤの項目に対応する。フェーズの項目は、対象のリソースにおける生産性把握の対象となるプロジェクトのフェーズの情報を保持する。基本生産性の項目は、対象のリソースおよびフェーズにおける基本となる生産性を示す値を保持する。この値は、例えば、対象のフェーズで行われる各タスクについて、標準工数等に基づいて算出される期間や工数に対して、保有スキルや経験、成長等の要素を考慮してある程度定型的に求めることができる基本的な生産性として求めることができる。

補正係数の項目は、上記の基本生産性の値に対して、上述の図４において示した実績ＤＢ３１に蓄積された対象のリソース（担当者）の過去のタスク実施の実績情報等を分析、考慮して、所定の方法により求めた補正係数の値を保持する。基本生産性や補正係数の項目は、フェーズ単位ではなく、これに含まれる各タスクでの作業項目や種類（例えばドキュメント作成やコーディング等）、利用技術（プログラミング言語や基盤に用いられる製品技術等）など、タスクでの実施作業における種々の要素毎に細分化して設定できるようにしてもよい。

また、例えば、実績ＤＢ３１から把握される各タスクに起因するバグ件数の多さによって、基本生産性もしくは特定の要素の補正係数の値を生産性が低くなるように調整してもよい。また、他のタスクの成果物等を再利用している場合や、他のプロジェクトメンバーのサポートを受けている場合は、その影響を考慮（除外）した形で基本生産性もしくは補正係数の値を算出するようにしてもよい（例えば、作成したソースコードのうちの再利用したソースコードの割合に基づいて調整する等）。

また、タスク実施の際のチームやグループ、組織などのメンバー構成や編成などの環境面での情報について、例えば、データマイニング等の技術や統計的手法を利用して分析し、生産性が向上する／低下するメンバーの組み合わせなどの情報を算出して、基本生産性もしくは特定の要素の補正係数の値に反映させるようにしてもよい。

なお、上述の図２〜図６で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

＜処理の流れ＞
図７は、本実施の形態におけるプロジェクトのタスクのスケジュール管理の処理の流れの例について概要を示したフローチャートである。スケジュール管理に際して、前提として、プロジェクトメンバー等の人的リソースの情報が予めプロジェクト管理支援システム１のリソース登録部４０によりリソースＤＢ４１に登録されているものとする。また、各リソースについて予め設定・算出された生産性に係る情報が生産性ＤＢ５１に登録されているものとする。また、各種作業についての標準的な工数（例えば、１人月あたりのドキュメント作成数やコーディングの行数など）の情報が標準工数情報１２に定義されているものとする。

スケジュール管理処理を開始すると、まず、プロジェクトマネージャー等のユーザは、プロジェクト管理支援システム１のスケジュール作成部１０等を介して、管理対象のプロジェクトに係る情報をプロジェクトＤＢ１１に登録する（Ｓ０１）。その後、当該プロジェクトに対して別途ＷＢＳ（Work Breakdown Structure）を作成する等により実施すべきタスクを定義し、定義された各タスクに係る情報を、スケジュール作成部１０等を介してタスクＤＢ２１に登録する（Ｓ０２）。

その後、例えば直近の１ヶ月程度の間に実施されるべきタスクについて、各プロジェクトメンバーに対して担当する旨の自己申告を募り、希望するプロジェクトメンバーから申告登録部２０を介して受け付けた自己申告の内容をタスクＤＢ２１に登録する（Ｓ０３）。登録は、各プロジェクトメンバーが独自に行なってもよいし、プロジェクトマネージャー等が申告を受けて登録してもよい。自己申告の内容には、上述したように、対象のタスクと担当者（担当チーム）、実施に要する期間や工数などの情報が含まれる。なお、自己申告によって担当者が割り当てられたタスクには、タスクＤＢ２１において自己申告フラグを設定する。

次に、ステップＳ０３にて自己申告により担当者が割り当てられたタスクについて、スケジュール作成部１０により、当該担当者の生産性（タスク実施能力）等の情報に基づいて期間や工数の値を補正する（Ｓ０４）。例えば、対象のタスクを実施する担当者について、生産性ＤＢ５１から対象のフェーズについての基本生産性の値を取得し、さらに、タスクの作業内容等に合致する補正係数の値を取得して基本生産性に反映させることで生産性を算出し、この値に基づいて期間や工数の値を補正する。

なお、期間や工数についての過少申告を抑止するために、標準工数情報１２に設定された標準工数に基づいて、申告する期間や工数の値には一定の制限を設けるようにするのが望ましい。また、生産性による補正に先立って、リソースＤＢ４１に設定された自己申告信頼度の値に基づいて、自己申告による期間や工数の値を補正しておくようにしてもよい。担当者が割り当てられなかった（自己申告がなかった）タスクについては、プロジェクトマネージャーがスケジュール作成部１０もしくは申告登録部２０を介して担当者を割り当て、標準工数と当該担当者の生産性の情報とに基づいて期間や工数を設定するものとする。

その後、プロジェクトマネージャーは、タスクＤＢ２１に登録された各タスクについて、設定された期間や工数に基づいて、各種の制約条件を加味しながら開始日および終了日を設定して、スケジュール作成部１０を介してタスクＤＢ２１に登録し、実際のスケジュールを作成する（Ｓ０５）。ここでの制約条件としては、上述したように、例えば、開発に使用するハードウェアやソフトウェアの納入時期や、性能テスト実施時における機器の台数やスペックなどが考えられる。

その後、作成されたスケジュールに基づいて未実施のタスクが順次実施される。タスクが実施されると（Ｓ０６）、その実施に係る実績を把握して、実績登録部３０により実績ＤＢ３１に蓄積する（Ｓ０７）。実績の把握の手法は、タスクの作業内容に応じて種々のものが考えられ、その内容に応じて、実績登録部３０が自動で実績情報を取得・収集することが可能な場合や、プロジェクトマネージャーや担当者等が手動で登録する場合があり得る。

実績情報の内容も、タスクの実施完了までに要した期間の他に、例えば、成果物の作成量として、ドキュメントのページ数や、レビューでの指摘件数、テストケース数などにより把握するものなど、種々のものが考えられる。なお、コーディングの際のコード行数については、多ければよいというものではなく、適切に設計されたプログラムほど簡潔で短くなる傾向があることや、他で作成されたコードを再利用した量などについても考慮する必要がある。また、バグ件数についても実績として把握する必要があるが、上述したように、後工程や、プロジェクト終了後のシステムの稼働・サービス段階で発見された場合も含め、対象のタスクでの作業や成果物に起因して発生したと認められるバグの件数を保持するものとする。バグの修復に要した工数などに応じて件数に重み付けしてもよい。

その後、ステップＳ０７にて更新された実績ＤＢ３１に蓄積された実績情報の内容に基づいて、生産性評価部５０により、各担当者（リソース）の生産性等の値を更新する（Ｓ０８）。具体的には、当該タスクの実績情報と、当該タスクに起因したものと判断されて当該タスクに計上されたバグ件数、および蓄積された実績情報の中で関連する（対応する）過去のタスクに起因したものとして当該過去のタスクに計上されたバグの件数の情報等に基づいて、例えば、生産性ＤＢ５１における既存の補正係数の値を再計算する、もしくは新たに補正係数を算出する。また、リソースＤＢ４１における自己申告信頼度の値を再計算する。このように、蓄積された実績情報に基づいてこれらの生産性等の値を継続的に更新していくことで、担当者の成長なども考慮に入れたより適切な生産性の評価が可能となり、より適切なタスクのスケジューリングが可能となる。

なお、プロジェクト終了後のシステムの稼働・サービス段階でバグが発見された場合であっても、バグの起因となったタスクのバグ件数に計上するとともに、ステップＳ０８と同様の処理によって関連する各担当者の生産性の値を再計算して更新しておくものとする。

その後、ステップＳ０８で更新された生産性等の値に基づいて、必要に応じて、スケジュール作成部１０による自動もしくは手動で未実施の他のタスクについての定義内容（実施期間や工数など）を更新し（Ｓ０９）、プロジェクトマネージャーにより各タスクのスケジュールを調整する（Ｓ１０）。ステップＳ０９およびＳ１０の処理は、タスクの担当者が割り当てられていないタスクについては、上記のステップＳ０２〜Ｓ０５における処理と同様となる場合もある。上記のＳ０６〜Ｓ１０の一連の処理をプロジェクトにおいて実施されるべき各タスクについて繰り返すことでスケジュール管理を行う。

以上に説明したように、本発明の一実施の形態であるプロジェクト管理支援システムによれば、プロジェクトにおいて実施すべきタスクに対して、各担当者もしくはチームが、どこまでのタスクをどれだけの期間で実施するのかを自己申告（登録）するものとし、プロジェクトマネージャーは、原則として自己申告された内容と、自己申告の信頼度および生産性に係る情報とに基づいて、自己申告の内容を補正し、タスクのスケジューリングに反映させることを可能とする。これにより、各タスクについての所要期間や工数（自己申告）を適宜補正しながら、柔軟にタスクのスケジュールを調整し、タスク実施能力の高いリソース（担当者）の「空き」が有効に活用されるように動機付けしながら管理することが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、システム構築プロジェクトにおいて、スケジュール管理を柔軟に行うことを可能とするプロジェクト管理支援システムおよびプロジェクト管理支援プログラムに利用可能である。

１…プロジェクト管理支援システム、
１０…スケジュール管理支援システム、１１…プロジェクトデータベース（ＤＢ）、１２…標準工数情報、
２０…申告登録部、２１…タスクデータベース（ＤＢ）、
３０…実績登録部、３１…実績データベース（ＤＢ）、
４０…リソース登録部、４１…リソースデータベース（ＤＢ）、
５０…生産性評価部、５１…生産性データベース（ＤＢ）。

Claims (6)

1. システム構築プロジェクトにおける各タスクのスケジュール、および各タスクに割り当てるプロジェクトメンバーの管理を支援するプロジェクト管理支援システムであって、
   プロジェクトで実施すべき１つ以上のタスクを定義してタスク記録手段に登録するスケジュール作成部と、
   プロジェクトメンバーからのタスクの実施を担当する旨および作業工数の自己申告を受け付けて、当該プロジェクトメンバーを当該タスクの担当者として、前記タスク記録手段に記録された対応するタスクに登録する申告登録部とを有し、
   前記スケジュール作成部は、プロジェクトマネージャーからの指示に基づいて、前記タスク記録手段に登録された各タスクについてのスケジューリングを行うことを特徴とするプロジェクト管理支援システム。
2. 請求項１に記載のプロジェクト管理支援システムにおいて、
   さらに、各タスクの実施状況に係る実績情報を取得して実績記録手段に蓄積する実績登録部と、
   前記実績記録手段に記録された実績情報に基づいて、各担当者についての自己申告の信頼の程度に係る情報を算出してリソース記録手段に記録する生産性評価部とを有し、
   前記スケジュール作成部は、前記リソース記録手段に記録された各担当者の自己申告の信頼の程度に係る情報に基づいて、プロジェクトメンバーから受け付けた自己申告における作業工数を補正することを特徴とするプロジェクト管理支援システム。
3. 請求項１に記載のプロジェクト管理支援システムにおいて、
   さらに、各タスクの実施状況に係る実績情報を取得して実績記録手段に蓄積する実績登録部と、
   前記実績記録手段に記録された実績情報に基づいて、各担当者についてのタスクでの作業内容に応じた生産性に係る情報を算出して生産性記録手段に記録する生産性評価部とを有し、
   前記スケジュール作成部は、前記生産性記録手段に記録された担当者のタスクでの作業内容に応じた生産性に係る情報に基づいて、当該担当者が実施するタスクの作業工数を補正することを特徴とするプロジェクト管理支援システム。
4. 請求項１に記載のプロジェクト管理支援システムにおいて、
   さらに、各タスクの実施状況に係る実績情報として、タスクの実施に際してサポートを受けた他の担当者の情報および／またはタスクの実施に際して再利用した他のタスクの成果物の情報を含む情報を取得して実績記録手段に蓄積する実績登録部と、
   前記実績記録手段に記録された実績情報に基づいて、当該他の担当者および／または当該他のタスクの担当者の情報を取得して、これらの担当者についての評価に係る情報として記録する生産性評価部を有することを特徴とするプロジェクト管理支援システム。
5. 請求項１〜４のいずれか１項に記載のプロジェクト管理支援システムにおいて、
   前記スケジュール作成部は、タスクについてプロジェクトメンバーから受け付ける自己申告における作業工数を、当該タスクの作業内容に対して予め定義された標準工数に対する一定の範囲に制限することを特徴とするプロジェクト管理支援システム。
6. システム構築プロジェクトにおける各タスクのスケジュール、および各タスクに割り当てるプロジェクトメンバーの管理を支援するプロジェクト管理支援システムとしてコンピュータを動作させるプロジェクト管理支援プログラムであって、
   プロジェクトで実施すべき１つ以上のタスクを定義してタスク記録手段に登録するスケジュール作成処理と、
   プロジェクトメンバーからのタスクの実施を担当する旨および作業工数の自己申告を受け付けて、当該プロジェクトメンバーを当該タスクの担当者として前記タスク記録手段に記録された対応するタスクに登録する申告登録処理とを実行し、
   前記スケジュール作成処理は、プロジェクトマネージャーからの指示に基づいて、前記タスク記録手段に登録された各タスクについてのスケジューリングを行うことを特徴とするプロジェクト管理支援プログラム。

Images