JP7160789B2 - プロジェクト管理システム、プロジェクト管理方法、およびプログラム - Google Patents

Description

本発明は、プロジェクト管理システム、プロジェクト管理方法、およびプログラムに関する。

複数のプロジェックトの進捗状況の管理を支援するプロジェクト管理システムが開示されている（特許文献１）。

特開２０１６―１１８８３２号公報

特許文献１に記載のシステムでは、プロジェクトにおいて、完了、遅延、および遅延なしを示すステータスごとにタスクを分類し、該ステータスに分類されるタスクの割合をそれぞれ算出して、当該タスクの割合をグラフ形式で表示させる。これにより、管理者はプロジェクトの進捗状況を視覚的に把握できる。

しかしながら、特許文献１に記載のシステムでは、作業実施予定に対してタスクの進捗が遅延しているか否かにつき算出し、プロジェクト全体の進捗状況を視覚的に把握できるものの、タスクごとの進捗につき標準的な進捗との関係について定量的な評価をしていない。すなわち、当該システムでは、繰り返し型開発モデルのプロジェクトにおいて、具体的にどのタスクでどの程度の遅延が生じているかなど、遅延の原因の把握が不十分になる虞があった。

そこで、本発明は、上記の課題を解決するために、プロジェクトのタスクごとに、実際の進捗度と標準的な進捗度との関係をスコア化して表示装置に表示させ、管理者がプロジェクト全体を的確に管理できるシステムを提供することを目的とする。

本発明の一態様に係るプロジェクト管理システムは、繰り返し型開発モデルでプロジェクトを遂行する複数の作業グループが複数のタスクを処理する状況において、各作業グループの各タスクの状態を示すタスク情報を受け付ける受付部と、前記タスク情報に基づいて、所定の時点における、前記各作業グループの前記各タスクにおける実際の進捗度を特定する進捗度特定部と、前記所定の時点において、前記各作業グループにおける、前記実際の進捗度と、前記各タスクに対応する標準的な進捗度との関係を示す第１スコアを算出する第１スコア算出部と、前記各作業グループの前記第１スコアを表示装置に表示する処理を実行する表示処理部と、を備える。

本発明の一態様に係る繰り返し型開発方法は、コンピュータが、繰り返し型開発モデルでプロジェクトを遂行する複数の作業グループそれぞれの複数のタスクそれぞれの状態を示すタスク情報を受け付けることと、前記タスク情報に基づいて、所定の時点における、各作業グループの各タスクにおける実際の進捗度を特定することと、前記所定の時点において、前記各作業グループにおける、前記実際の進捗度と、前記各タスクに対応する標準的な進捗度との関係を示す第１スコアを算出することと、前記各作業グループの前記第１スコアを表示装置に表示する処理を実行することと、を実行する。

本発明の一態様に係るプログラムは、コンピュータに、繰り返し型開発モデルでプロジェクトを開発する複数の作業グループそれぞれの複数のタスクそれぞれの状態を示すタスク情報を受け付けることと、前記タスク情報に基づいて、所定の時点における、各作業グループの各タスクにおける実際の進捗度を特定することと、前記所定の時点において、前記各作業グループにおける、前記実際の進捗度と、前記各タスクに対応する標準的な進捗度との関係を示す第１スコアを算出することと、前記各作業グループの前記第１スコアを表示装置に表示する処理を実行することと、を実行させる。

本発明によれば、繰り返し型開発モデルで処理するプロジェクトにおいて、スコア化されたタスクの進捗状況を表示装置に表示させることで、管理者が当該プロジェクト全体を的確に管理できる。

アジャイルソフトウェア開発手法の組織体制の一例を示す図である。 プロジェクト管理システムの構成を示す図である。 実際の進捗度と閾値との関係を示すバーンダウンチャートある。 第１スコアと距離との対応関係を示すグラフである。 バーンダウンチャートを示す図である。 第１スコアと第２スコアとの関係をドリルダウン形式で示した図である。 プロジェクト管理システムの処理手順の一例を示すフロー図である。 コンピュータのハードウェア構成の一例を示す図である 影響度テーブルの一例を示す図である。 画像取得部で取得されたタスク整理画像を示す図である。

以下に、本発明の一実施形態におけるプロジェクト管理システム１０について、図面を参照して詳細に説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。すなわち、本発明は、その趣旨を逸脱しない範囲で種々変形し、または各実施例を組み合わせるなどして実施することができる。また、以下の図面の記載において、同一または類似の部分には同一または類似の符号を付して表している。
＝＝＝プロジェクト管理システム１０の概要＝＝＝

プロジェクト管理システム１０は、例えば、繰り返し型開発手法でプロジェクトを遂行する複数の作業グループが複数のタスクを処理する状況において、当該プロジェクトを適切に管理するためのシステムである。

ここで、繰り返し型開発手法は、アジャイルソフトウェア開発手法または反復型開発手法などである。以下、一例として、繰り返し型開発手法を、アジャイルソフトウェア開発手法として説明する。

アジャイルソフトウェア開発手法は、例えば、開発する対象を多数の小さな機能に分割し、１つの機能を１つの反復で開発する手法である。アジャイルソフトウェア開発手法では、反復しながら追加的に機能を開発していく。すなわち、アジャイルソフトウェア開発手法においては、計画、要求分析、設計、実装、テスト、および文書化などを１つの反復で実行するため、１つの反復を小規模なソフトウェア開発プロジェクトと同じように処理する。

図１は、アジャイルソフトウェア開発手法の組織体制の一例を示す図である。図１に示すように、アジャイルソフトウェア開発手法においては、開発する対象の分割された機能ごとに、作業グループを編成する。アジャイルソフトウェア開発手法では、例えば、複数の作業グループを、一つにまとめることや、特定のカテゴリーでグルーピングすることも可能である。

プロジェクト管理システム１０では、アジャイルソフトウェア開発手法において、複数の作業グループそれぞれの進捗状況を管理することで、プロジェクトに係る担当者が容易に進捗状況を把握し、プロジェクトを円滑に進めることができる。進捗状況の管理については後述する。

以下、プロジェクト管理システム１０を、一例として、アジャイルソフトウェア開発手法に適用した場合の構成について説明する。なお、プロジェクト管理システム１０は、アジャイルソフトウェア開発手法（スクラム開発手法、エクストリーム・プログラミング、およびユーザ機能駆動開発手法などを含む）とは異なる開発手法、例えば、上述した反復型開発手法など、システム開発のプロジェクトにおいて、それぞれのタスクを処理する作業グループに対して進捗状況の管理が求められるような開発手法に広く適用できる。
＝＝＝プロジェクト管理システム１の構成＝＝＝

図２を参照して、プロジェクト管理システム１０の構成について説明する。図２は、プロジェクト管理システム１０の構成を示す図である。図２に示すように、プロジェクト管理システム１０は、記憶部１１と、受付部１２と、進捗度特定部１３と、閾値判定部１４と、警告出力部１５と、第１スコア算出部１６と、第２スコア算出部１７と、表示処理部１８とを含む。

記憶部１１は、各種情報を格納する。

受付部１２は、複数の作業グループそれぞれの複数のタスクそれぞれの状態を示すタスク情報を受け付ける。受け付けられたタスク情報は、記憶部１１に格納される。ここで、タスクとは、例えば作業グループが開発する機能を構成する一つの単位機能とする。また、タスクそれぞれの状態とは、例えば、タスクが処理待ちであること、処理中であること、または処理済みであることなどを示す。なお、受付部１２は、例えば、タスク情報を、後述する入力Ｉ／Ｆ部１０４を介して操作者から取得してもよいし他の装置から取得してもよく、受け付ける経路は限定されない。

進捗度特定部１３は、受付部１２で受け付けたタスク情報に基づいて、所定の時点における、複数の作業グループそれぞれの複数のタスクにおける実際の進捗度を特定する。ここで、進捗度とは、例えば、処理しなければならない残りのタスクの処理に必要な処理時間である。当該処理時間は例えば作業グループが決定する。これにより、後述するバーンダウンチャートを作成できるため、管理者は適切にタスクの進捗状況を把握できる。進捗度特定部１３で特定される進捗度については、バーンダウンチャート（図５）を用いて後述する。

なお、進捗度は、当該作業グループが処理しなければならない全てのタスクの処理に要する処理時間に対する、処理しなければならない残りのタスクの処理に要する処理時間の割合であってもよい。以下においては、説明の便宜のため、一例として、進捗度を、処理しなければならない残りのタスクの処理に係る処理時間として説明する。

閾値判定部１４は、所定の時点において、進捗度特定部１３で特定された実際の進捗度が、所定の閾値を超えているか否かを判定する。図３は、実際の進捗度と閾値との関係を示すバーンダウンチャートある。バーンダウンチャートは、プロジェクト全体または所定の作業グループにおいて、所定の時点で処理しなければならない残りのタスクの処理に必要な時間をプロットした図である。図３においては、縦軸に処理時間を示し、横軸に経過した日数（日付などでもよい）を示す。また、実際の進捗度を実線で示し、標準的な進捗度を破線で示し、危険進捗指標を一点鎖線で示し、警告進捗指標を二点鎖線で示す。ここで、標準的な進捗度とは、所定のタスクについて、期日までに処理を完了させるための、所定の時点における理想的な進捗度である。危険進捗指標とは、例えば期日までに処理を完了させることが著しく困難である進捗度である。警告進捗指標は、例えばこのままでは期日までに処理を完了させられない可能性がある進捗度である。

閾値判定部１４は、所定の時点において実際の進捗度が所定の閾値を超えているか否かを判定する。具体的に述べると、図３に示すように、経過した日数が「１６」日では、実際の進捗度が「２００」時間であり、警告進捗指標が「１３０」時間であるため、閾値判定部１４は、所定の閾値たる警告進捗指標を超えていると判定する。これにより、タスクの処理が順調であるか否かを判定できるため、管理者は、適切なタイミングで作業グループを支援して、プロジェクトを円滑に処理できる。

なお、閾値判定部１４は、所定の時点において、実際の進捗度が、警告進捗指標に代えて危険進捗指標を超えているか否かを判定してもよい。また、閾値判定部１４は、所定の時点において、後述する第１スコア算出部１６で算出された第１スコアが、所定の閾値を超えているか否かを判定してもよい。

警告出力部１５は、閾値判定部１４において所定の閾値を超えていると判定された場合、所定の警告信号を出力する。警告信号に基づいて、後述する表示処理部１８において、表示装置１０７に警告情報を表示させる。これにより、プロジェクトの管理者は、タスクの処理が滞っている作業グループを知ることができるため、該作業グループに対する適切な対策を実行できる。

第１スコア算出部１６は、所定の時点において、所定の作業グループにおける、所定のタスクの実際の進捗度と、所定のタスクの標準的な進捗度との関係を示す第１スコアを算出する。ここで、第１スコアは、例えば標準的な進捗度と重なる場合、進捗度を「１００」とし、当該タスクの処理に遅れがないことを示す。一方、所定の時点において危険進捗指標と重なる場合、進捗度を「０」とし、処理に著しい遅れが生じていることを示す。すなわち、第１スコア算出部１６は、第１スコアを、進捗度が標準的な進捗度から危険進捗指標に近づくに従って、例えば一次関数的に減少するよう算出してもよい。これにより、管理者は、タスクの進捗状況を定量的に確認できるため、適切・迅速に作業状況を把握できる。

なお、第１スコア算出部１６は、第１スコアを、進捗度が標準的な進捗度から危険進捗指標に近づくに従って、例えば二次関数的に減少するよう算出してもよい。図４を参照しながら、具体的に説明する。図４は、第１スコアと距離との対応関係を示すグラフである。図４において、縦軸は第１スコアを示し、横軸は標準的な進捗度に対する実際の進捗度の距離を示す。なお、横軸に示す距離は、例えば、所定の時点における標準的な進捗度と危険進捗度指標との距離が、その最大値となる。図４に示すように、第１スコア算出部１６において、進捗の遅れが小さいほど、第１スコアの変動幅を大きくする。これにより、ウォータ－フォール開発手法に比べ、小さい進捗の遅れが多く発生するアジャイルソフトウェア開発に対して、管理者が迅速に進捗の遅れを把握できる。一方、第１スコア算出部１６において、進捗の遅れが大きいほど、第１スコアの変動幅を小さくする。これにより、ウォータ－フォール開発手法に比べ、多くの小さいタスクを処理するアジャイルソフトウェア開発において、プロジェクト全体の進捗状況を適切に把握できる。以下、便宜上、第１スコアは、進捗度が標準的な進捗度から危険進捗指標に近づくに従って、一次関数的に減少することとして説明する。第１スコア算出部１６で算出される第１スコアについては、バーンダウンチャート（図５）を用いて具体的に後述する。

なお、第１スコアは、所定の時点までに累積される第１スコアの合計を平均した値であってもよい。これにより、期間における第１スコアを採用するため、第１スコアの信頼性が向上する。また、第１スコア算出部１６は、標準的な進捗度（例えば１００時間）と実際の進捗度（例えば１２０時間）との乖離（２０時間）を、標準的な進捗時間に対する割合（２０％）として算出し、当該割合を標準的な進捗度「１００」から減算（例えば８０）して、第１スコアを算出してもよい。

また、第１スコア算出部１６は、第１スコアに加えて各種指標を付加してもよい。ここで、各種指標とは、例えば、ソースコード行数、ユニットテスト件数、自動結合テスト件数、ビルド失敗数、コミット回数・時間、完了済タスク数、割り込み作業数、または延べ時間などである。これにより、第１スコアに具体的な定量的指標を付加することで、管理者は、より適切・迅速に作業状況を把握できる。

ここで、図５を参照して、進捗度特定部１３で特定される進捗度、および第１スコア算出部１６で算出される第１スコアにつき、具体的に説明する。図５は、バーンダウンチャートを示す図である。図５においては、縦軸に処理時間を示し、横軸に経過した日数（日付などでもよい）を示す。図５においては、実際の進捗度を実線で示し、標準的な進捗度を破線で示し、危険標準指標を一点鎖線で示す。

図５に示すように、進捗度特定部１３において、実際の進捗度が、例えば経過した日数が「１１」日の時点で「１８０」時間と特定される。これは、経過した日数が「１１」日の時点で、タスクを処理するために、あと「１８０」時間が必要であることを示す。そして、図５では、経過した日数が「１１」日の時点で、実際の進捗度である「１８０」時間と標準的な進捗度である「１２０」時間との乖離が「６０」時間であるため、タスクの処理が遅れていることが示されている。

また、図５に示すように、第１スコア算出部１６において、第１スコアが、例えば経過した日数が「１１」日の時点で「５０」と算出される。具体的に述べると、経過した日数が「１１」日において、標準的な進捗度が「１２０」時間であり、危険進捗指標が「２４０」時間である。この場合、標準的な進捗度「１２０」時間を第１スコア「１００」とし、危険進捗指標「２４０」時間を第１スコア「０」とする。進捗度が「１２０」時間から「２４０」時間に近づくに従って、例えば所定の割合（例えば一次関数的）で第１スコアが小さくなる。したがって、実際の進捗度「１８０」時間の第１スコアは「５０」となる。

第２スコア算出部１７は、例えば、複数の作業グループそれぞれにおける第１スコアの平均値を、プロジェクトの第２スコアとして算出する。なお、第２スコアは、第１スコアの平均値とすることに限定されないが、第１スコアの平均値を採用することが最も望ましい。図６は、第１スコアと第２スコアとの関係をドリルダウン形式で示した図である。図６において、例えば、紙面下側の末端のオブジェクト１６ａ，１６ｂには、複数の作業グループ（例えば「現金グループ」「銀行グループ」）それぞれについて第１スコアが示されている。また、オブジェクト１６ａ，１６ｂと関連付けされた中段のオブジェクト１７ｂには、複数の作業グループをまとめるグループ（例えば「入金グループ」）について第２スコアが示されている。なお、中段のオブジェクト１７ａ～１７ｃと関連付けされた最上段のオブジェクト１７ｄにも第２スコア（中段のオブジェクト１７ａ～１７ｃの第２スコアの平均値）が示されている。これにより、管理者は、プロジェクト全体の進捗状況を俯瞰的に把握できるため、適切なプロジェクト進行を実現できる。なお、図６は、一例を示すものであり、その階層構造については、作業グループの編成に応じて変更されうる。

また、第２スコア算出部１７は、第２スコアとして、所定のオブジェクトの下段に位置する第１スコア（または第２スコア）の最低値、最大値、および平均値のうち、少なくともいずれかを算出してもよい。これにより、プロジェクト全体のうち、どの作業グループで遅延を生じているかなどにつき容易に把握できるため、より適切なプロジェクト進行を実現できる。

表示処理部１８は、複数の作業グループそれぞれの第１スコアおよび第２スコアを表示装置１０７に表示させる。複数の作業グループそれぞれの第１スコアと、第１スコアと関連付けられた第２スコアと、を例えばドリルダウン形式で、表示装置１０７に表示する。これにより、管理者は、パーソナルコンピューター上でプロジェクトの進捗状況を容易に把握できる。
＝＝＝プロジェクト管理システム１０の処理手順＝＝＝

図７を参照して、プロジェクト管理システム１０の処理手順について説明する。図７は、プロジェクト管理システム１０の処理手順の一例を示すフロー図である。

まず、Ｓ１００において、プロジェクト管理システム１０は、管理者の入力操作または他装置からの入力によって、タスクそれぞれのタスク情報を受け付ける。

次に、Ｓ１０１において、プロジェクト管理システム１０は、進捗度特定部１３において、タスクそれぞれの所定の時点における進捗度を特定する。進捗度は、例えば作業グループによって入力される。

次に、Ｓ１０２において、プロジェクト管理システム１０は、進捗度が所定の閾値（例えば警告進捗指標）を超えているか否かを判定する。進捗度が所定の閾値を超えていると判定された場合（Ｓ１０２：ＹＥＳ）、警告出力部１５は警告信号を出力する（Ｓ１０３）。これにより、管理者はタスクの進捗に遅れが生じていることを把握できる。そして、処理をＳ１０４に移行させる。進捗度が所定の閾値以下の場合（Ｓ１０２：ＮＯ）、処理をＳ１０４に移行させる。

次に、Ｓ１０４において、プロジェクト管理システム１０は、第１スコア算出部１６において、所定の時点におけるタスクそれぞれの第１スコアを算出する。

次に、Ｓ１０５において、プロジェクト管理システム１０は、第２スコア算出部１７において、第１スコアの平均値を第２スコアとして算出する。

次に、Ｓ１０６において、プロジェクト管理システム１０は、表示処理部１８において、図６に示すように、第１スコアおよび第２スコアをドリルダウン形式で表示装置１０７に表示する。これにより、管理者は、プロジェクト全体の進捗状況を容易に把握できるとともに、進捗が滞っているタスクを容易に把握できるため、適切な対策を実行できる。
＝＝＝ハードウェア＝＝＝

図８を参照して、プロジェクト管理システム１０をコンピュータ１００により実現する場合のハードウェア構成の一例を説明する。なお、プロジェクト管理システム１０の各種機能は、複数台の装置に分けて実現することもできる。

図８は、コンピュータのハードウェア構成の一例を示す図である。図８に示すように、コンピュータ１００は、プロセッサ１０１と、メモリ１０２と、記憶装置１０３と、入力Ｉ／Ｆ部１０４と、データＩ／Ｆ部１０５と、通信Ｉ／Ｆ部１０６、及び表示装置１０７を含む。

プロセッサ１０１は、メモリ１０２に記憶されているプログラムを実行することによりコンピュータ１００における各種の処理を制御する制御部である。

メモリ１０２は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の記憶媒体である。メモリ１０２は、プロセッサ１０１によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。

記憶装置１０３は、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶装置１０３は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。

入力Ｉ／Ｆ部１０４は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ部１０４の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイス等が挙げられる。入力Ｉ／Ｆ部１０４は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等のインタフェースを介してコンピュータ１００に接続されても良い。

データＩ／Ｆ部１０５は、コンピュータ１００の外部からデータを入力するためのデバイスである。データＩ／Ｆ部１０５の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置等がある。データＩ／Ｆ部１０５は、コンピュータ１００の外部に設けられることも考えられる。その場合、データＩ／Ｆ部１０５は、例えばＵＳＢ等のインタフェースを介してコンピュータ１００へと接続される。

通信Ｉ／Ｆ部１０６は、コンピュータ１００の外部の装置と有線又は無線により、インターネットＮを介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ部１０６は、コンピュータ１００の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ部１０６は、例えばＵＳＢ等のインタフェースを介してコンピュータ１００に接続される。

表示装置１０７は、各種情報を表示するためのデバイスである。表示装置１０７の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ウェアラブル・デバイスのディスプレイ等が挙げられる。表示装置１０７は、コンピュータ１００の外部に設けられても良い。その場合、表示装置１０７は、例えばディスプレイケーブル等を介してコンピュータ１００に接続される。また、入力Ｉ／Ｆ部１０４としてタッチパネルが採用される場合には、表示装置１０７は、入力Ｉ／Ｆ部１０４と一体化して構成することが可能である。
＝＝＝その他の実施形態＝＝＝
＜＜第１のその他の実施形態＞＞

また、プロジェクト管理システム１０は、課題取得部（不図示）および影響度特定部（不図示）を有していてもよい。記憶部１１は、例えば影響度テーブル１１ａを有する。図９は、影響度テーブル１１ａを示す図である。図９に示すように、影響度テーブル１１ａには、課題大分類項目、課題小分類項目、および影響度項目が含まれる。課題大分類項目とは、例えば「要件の誤り」や「ソフトウェアの誤り」など課題の上位概念を示す項目である。課題中分類項目とは、例えば課題大分類項目に含まれる具体的な課題を示す項目である。影響度項目とは、課題中分類項目に示されるそれぞれの課題に対応する影響度を示す。ここで、影響度は、例えば、タスクの処理に与える影響がない課題に対しては「１」を設定し、タスクの処理に与える影響が大きい課題になるにつれて、「１」を超えるより大きな値を設定する。なお、図９の影響度テーブル１１ａは一例を示すものであり、それぞれの項目、該項目に示される課題の内容、および影響度の数値は限定されない。

課題取得部は、複数の作業グループにおいて処理中のタスクで生じた課題に関する課題情報を取得する。そして、影響度特定部は、影響度テーブル１１ａを参照して、課題取得部で取得された課題情報に対応する影響度を特定する。第１スコア算出部１６は、実際の進捗度と所定の標準的な進捗度との乖離と、影響度特定部で特定された影響度とに基づいて、第１スコアを算出する。

具体的には、実際の進捗度が「９０時間」で、標準的な進捗度が「８０時間」である場合、乖離は「１０時間」と特定され、タスクで「プログラム機能不備」の課題が生じている場合、影響度は影響度テーブル１１ａを参照して「１．１０」と特定される。第１スコア算出部１６は、例えば、当該乖離「１０時間」に影響度「１．１０」を掛けることで、影響度に応じた乖離「１１時間」を算出できる。算出された乖離「１１時間」に基づき、上述したように第１スコアを算出する。すなわち、影響度が大きいほど当該乖離が実質的に大きくなるため、第１スコアが減少する。これにより、タスクの処理において生じた課題を、第１スコアに反映できるため、管理者は作業グループそれぞれの状況につき、より適切に管理できる。なお、影響度は一つとは限らず、当該乖離に複数の影響度を掛けてもよい。
＜＜第２のその他の実施形態＞＞

また、繰り返し型開発システムは、画像取得部（不図示）を有していてもよい。画像取得部は、複数の作業グループそれぞれが担当する複数のタスクそれぞれの状態を含むタスク整理画像を取得する。図１０は、画像取得部で取得されたタスク整理画像を示す図である。タスク整理画像は、例えばタスクが記載された付箋をボードに貼付した様子を示す画像である。図１０に示すように、タスク整理画像には、処理待ちのタスクを示す第１部分画像１９ａ、処理中のタスクを示す第２部分画像１９ｂ、および処理済みのタスクを示す第３部分画像１９ｃを含む。

進捗度特定部１３は、画像取得部で取得されたタスク整理画像に基づいて、所定の時点における実際の進捗度を特定する。具体的には、周知の画像処理技術を用いて、第１部分画像１９ａ、第２部分画像１９ｂ、および第３部分画像１９ｃから、例えば処理待ちのタスク数（図１０では「８」）、処理中のタスク数（図１０では「１２」）、および処理済のタスク数（図１０では「３」）を特定する。ここで、例えば、第１および第２部分画像１９ａ，１９ｂから、未処理のタスクの個数をカウントし、未処理のタスク数を特定する（図１０の例では「２０」）。なお、繰り返し型開発システムは、未処理のタスク数に基づいて、自動的に実際の進捗度を算出してもよいし、管理者が実際の進捗度を算出してもよい。これにより、例えばボードに未処理のタスクに関する付箋を貼付している状況を撮影すると、実際の進捗度が特定されるため、管理者の入力手間などを縮減できる。
＜＜第３のその他の実施形態＞＞

また、繰り返し型開発システムは、第１スコア算出部１６において、第１スコアに加えて、当該タスクに参画しているメンバーを特定してもよい。これにより、第１スコアが高いタスク、または第１スコアが低いタスクに参画しているメンバーを確認でき、メンバー間の相性などを分析できるため、管理者は、タスクの処理に対して最適なメンバーを選定できる。表示処理部１８は、第１スコアとともに特定されたメンバーを表示装置１０７に表示する。
＜＜第４のその他の実施形態＞＞

また、繰り返し開発システムは、報告書作成部（不図示）を有していてもよい。報告書作成部は、進捗度特定部１３で特定された進捗度、第１スコア算出部１６で算出された第１スコア、または課題取得部で取得された課題情報などを、所定の報告様式に反映させて、報告書を作成する。これにより、管理者において、報告書作成手間を縮減できる。なお、表示処理部１８は、作成された報告書を表示装置１０７に表示する。
＜＜第５のその他の実施形態＞＞

また、繰り返し開発システムは、バックログ作成部（不図示）を有していてもよい。バックログ作成部は、例えば、タスク情報に基づいて、管理者によってタスクごとに優先度や進捗状況（時間）などが設定され、当該設定された内容に応じて、タスクを整理する。これにより、プロジェクトの進捗状況を、管理者および作業グループが共有把握できるため、繰り返し型開発プロジェクトを円滑に進行できる。
＝＝＝まとめ＝＝＝

本実施形態におけるプロジェクト管理システム１０は、繰り返し型開発モデルでプロジェクトを遂行する複数の作業グループが複数のタスクを処理する状況において、複数の作業グループそれぞれの複数のタスクそれぞれの状態を示すタスク情報を受け付ける受付部１２と、タスク情報に基づいて、所定の時点における、複数の作業グループそれぞれの複数のタスクにおける実際の進捗度を特定する進捗度特定部１３と、所定の時点において、複数の作業グループそれぞれにおける、実際の進捗度と、複数のタスクに対応する標準的な進捗度との関係を示す第１スコアを算出する第１スコア算出部１６と、複数の作業グループそれぞれの第１スコアを表示装置１０７に表示する処理を実行する表示処理部１８と、を備える。本実施形態によると、管理者は、プロジェクト全体の進捗状況を俯瞰的に把握できるため、適切なプロジェクト進行を実現できる。

また、本実施形態におけるプロジェクト管理システム１０は、複数の作業グループそれぞれにおける第１スコアの平均値を、プロジェクトの第２スコアとして算出する第２スコア算出部１７をさらに備え、表示処理部１８は、第１スコア算出部１６で算出された複数の作業グループそれぞれの第１スコアと、第２スコア算出部１７で算出されたプロジェクトの第２スコアと、を関連付けて表示装置１０７に表示する処理を行う。本実施形態によると、管理者は、プロジェクト全体のうち、どの作業グループで遅延を生じているかなどにつき容易に把握できるため、より適切なプロジェクト進行を実現できる。

また、本実施形態におけるプロジェクト管理システム１０は、所定の時点において、進捗度特定部１３で特定された実際の進捗度が所定の閾値を超えているか否かを判定する閾値判定部１４と、閾値判定部１４において所定の閾値を超えていると判定された場合、所定の警告を出力する警告出力部１５と、をさらに備える。本実施形態によると、管理者は、タスクの処理が滞っている作業グループを知ることができるため、該作業グループに対する適切な対策を実行できる。

また、本実施形態におけるプロジェクト管理システム１０は、複数の作業グループそれぞれから、所定のタスクを処理するための課題を取得する課題取得部と、所定の情報を参照して、課題取得部で取得された課題に基づいて、所定のタスクを処理するための影響度を特定する影響度特定部と、をさらに備え、第１スコア算出部１６は、実際の進捗度と所定の標準的な進捗度との関係と、影響度特定部で特定された影響度と、に基づいて、第１スコアを算出する。本実施形態によると、タスクの処理において生じた課題を、第１ステータスに反映できるため、管理者は作業グループそれぞれの状況につき、より適切に管理できる。

また、本実施形態におけるプロジェクト管理システム１０は、複数の作業グループそれぞれが担当する複数のタスクそれぞれの状態を含む画像情報を取得する画像取得部をさらに備え、進捗度特定部１３は、画像情報に基づいて、所定の時点における、複数の作業グループそれぞれの複数のタスクにおける実際の進捗度を特定する。本実施形態によると、例えばボードに未処理のタスクに関する付箋を貼付している状況を撮影すると、実際の進捗度が特定されるため、管理者の入力手間などを縮減できる。

１０…プロジェクト管理システム、１１…記憶部、１２…受付部、１３…進捗度特定部、１４…閾値判定部、１５…警告出力部、１６…第１スコア算出部、１７…第２スコア算出部、１８…表示処理部

Claims (6)

1. 繰り返し型開発モデルでプロジェクトを遂行する複数の作業グループのそれぞれが複数のタスクを処理する状況において、各作業グループが処理する各タスクの状態を示すタスク情報を受け付ける受付部と、
   前記タスク情報に基づいて、所定の時点における、各作業グループが処理する前記各タスクの実際の進捗度を特定する進捗度特定部と、
   前記各作業グループから、所定のタスクを処理するための課題を取得する課題取得部と、
   所定の情報を参照して、前記課題取得部で取得された前記課題に基づいて、前記所定のタスクを処理するための影響度を特定する影響度特定部と、
   前記所定の時点において、各作業グループにおける、前記実際の進捗度と前記各タスクの標準的な進捗度との関係と、前記影響度特定部で特定された影響度と、に基づいて、第１スコアを算出する第１スコア算出部と、
   各作業グループの前記第１スコアを表示装置に表示する処理を実行する表示処理部と、
   を備えるプロジェクト管理システム。
2. 前記各作業グループにおける前記第１スコアの平均値を、前記プロジェクトの第２スコアとして算出する第２スコア算出部
   をさらに備え、
   前記表示処理部は、前記第１スコア算出部で算出された前記各作業グループの前記第１スコアと、前記第２スコア算出部で算出された前記プロジェクトの前記第２スコアと、を関連付けて前記表示装置に表示する処理を行う
   請求項１に記載のプロジェクト管理システム。
3. 前記所定の時点において、前記進捗度特定部で特定された前記実際の進捗度が所定の閾値を超えているか否かを判定する閾値判定部と、
   前記閾値判定部において前記所定の閾値を超えていると判定された場合、所定の警告を出力する警告出力部と、
   をさらに備える請求項１または請求項２に記載のプロジェクト管理システム。
4. タスクの状態ごとに区分けされたボード上の領域に貼付された、前記各作業グループが担当する前記各タスクを示す付箋が映る画像情報を取得する画像取得部
   をさらに備え、
   前記進捗度特定部は、前記画像情報に基づいて、前記所定の時点における、前記各作業グループの前記各タスクにおける前記実際の進捗度を特定する
   請求項１乃至請求項３のいずれか一項に記載のプロジェクト管理システム。
5. コンピュータが、
   繰り返し型開発モデルでプロジェクトを遂行する複数の作業グループそれぞれの複数のタスクそれぞれの状態を示すタスク情報を受け付けることと、
   前記タスク情報に基づいて、所定の時点における、各作業グループの各タスクにおける実際の進捗度を特定することと、
   前記各作業グループから、所定のタスクを処理するための課題を取得することと、
   所定の情報を参照して、前記取得された課題に基づいて、前記所定のタスクを処理するための影響度を特定することと、
   前記所定の時点において、前記各作業グループにおける、前記実際の進捗度と前記各タスクに対応する標準的な進捗度との関係と、前記特定された影響度と、に基づいて、第１スコアを算出することと、
   前記各作業グループの前記第１スコアを表示装置に表示する処理を実行することと、
   を実行するプロジェクト管理方法。
6. コンピュータに、
   繰り返し型開発モデルでプロジェクトを遂行する複数の作業グループそれぞれの複数のタスクそれぞれの状態を示すタスク情報を受け付けることと、
   前記タスク情報に基づいて、所定の時点における、各作業グループの各タスクにおける実際の進捗度を特定することと、
   前記各作業グループから、所定のタスクを処理するための課題を取得することと、
   所定の情報を参照して、前記取得された課題に基づいて、前記所定のタスクを処理するための影響度を特定することと、
   前記所定の時点において、前記各作業グループにおける、前記実際の進捗度と前記各タスクに対応する標準的な進捗度との関係と、前記特定された影響度と、に基づいて、第１スコアを算出することと、
   前記各作業グループの前記第１スコアを表示装置に表示する処理を実行することと、
   を実行させるためのプログラム。
   

Images