JP2011053905A - 開発プロセス評価管理システムおよび開発プロセス評価管理方法ならびに開発プロセス評価管理プログラム - Google Patents

Abstract

【課題】スキルを必要とする閾値設定等の煩雑な情報設定を前提とすることなく、プロジェクトの進捗状況を的確に把握して迅速な対策を講ずる。
【解決手段】プロジェクトの稼働日数（ｘｉ）毎の遅れ工数累計（ｙｉ）に関する複数のデータ（ｘｉ，ｙｉ）を収集し、評価実施日を含む過去の５日分のデータについて最小自乗法にて回帰直線を求め、この回帰直線の傾き角度θの変化に基づいて、過去の統計等に基づく煩雑な閾値等の情報を必要とすることなく、プロジェクトの進捗状況を的確に把握し、迅速な対策を講ずることを可能にする。
【選択図】図２

Description

本発明は、開発プロセス評価管理システムおよび開発プロセス評価管理方法ならびに開発プロセス評価管理プログラムに関する。

たとえば、組込システム等の製品の開発プロジェクトでは、比較的小人数で開発が遂行されるために、新製品開発をしている場合でも、既存製品の保守（問合せ、クレーム対応）、新技術の導入よる想定外の問題の発生、作業実行時の仕様の詳細な検討による工数の増大、等の要因により、計画に対し遅延を生じることが多く、リアルタイムな進捗状況の把握および工数の見直しが必要となる。

そのため、当初計画と進捗実績との差異だけでなく、開発作業中の工数増大を考慮したプロジェクト管理技術が望まれている。
このような、プロジェクト管理の方法としては、たとえば、以下の特許文献１および特許文献２に開示された技術が知られている。

すなわち、特許文献１には、見込み値−計画値＜閾値、のような判定論理により、計画値と見込み値の差分が、過去のデータや経験則によって求めた閾値を越えた場合に異常と判定する技術が開示されている。

なお、この特許文献１の場合、見込み値は、既定のデータとして存在するものとしているが、見込み値の入力時期や入力方法などの実際の運用面での具体的な開示はなされていない。

また、特許文献２には、プログラムのソースコードと残作業工数からコーディング完了時期を予想する技術が開示されているが、プログラムの開発プロセスの中の一部の進捗管理にしか使用できず、汎用性に乏しい。

特開２００７−２６３７８号公報 特開２００６−１２７０２０号公報

すなわち、上述の従来技術には、以下のような技術的課題がある。
第１に、経験に基づく閾値と単純比較する異常判定では、遅延状況の時間的な変化を判断していないため、工程遅延が増加傾向にあるのか、遅れているものの沈静化しているのか、遅れが改善傾向にあるのか、等の推移が分かり難い。

第２に、閾値は、プロジェクト管理に携わる担当者のスキル（基礎的な能力、開発経験年数、類似業務への従事経験の有無等）、作業の難易度、異常によって予想されるリスクの大小などによって決めるが、これらは定性的な物差しでしかなくこれらの係数を絶対値で決めることは非常に難しい。

本発明の目的は、スキルを必要とする閾値設定等の煩雑な情報設定を前提とすることな
く、プロジェクトの進捗状況を的確に把握して迅速な対策を講ずることが可能な技術を提供することにある。

本発明の第１の観点は、クライアント及びサーバを含む開発プロセス評価管理システムであって、
前記サーバは、
プロジェクトの管理情報を格納するプロジェクト管理テーブルと、
前記プロジェクトの進捗状況の異常の有無を評価するための判定基準情報を格納するプロジェクト評価テーブルと、
前記プロジェクト管理テーブルから、プロジェクト進捗履歴情報として、個々の稼働日毎の遅れ工数累計と、複数の前記稼働日の前記遅れ工数累計の回帰直線の傾き角度を求める評価手段と、
前記プロジェクト評価テーブルと、前記傾き角度から、前記プロジェクトの前記異常の発生および復旧を検出する異常発生復旧チェック手段と、
を有し、
前記クライアントは、
前記プロジェクトの進捗情報の入力を受け付ける入力手段と、
前記プロジェクトの進行に伴う現在までの進捗状態と、前記評価手段による評価結果を表示する表示手段と、
を有する
開発プロセス評価管理システムを提供する。

本発明の第２の観点は、プロジェクトにおける稼働日の各々の遅れ工数累計を集計する第１ステップと、
過去の複数の前記稼働日と前記遅れ工数累計の組合せから得られる回帰直線の傾き角度を求める第２ステップと、
前記傾き角度に基づいてプロジェクトの進捗状況を評価する第３ステップと、
を含む開発プロセス評価管理方法を提供する。

本発明の第３の観点は、プロジェクトにおける稼働日の各々の遅れ工数累計を集計する第１ステップと、
過去の複数の前記稼働日と前記遅れ工数累計の組合せから得られる回帰直線の傾き角度を求める第２ステップと、
前記傾き角度に基づいてプロジェクトの進捗状況を評価する第３ステップと、
をコンピュータに実行させる開発プロセス評価管理プログラムを提供する。

本発明によれば、スキルを必要とする閾値設定等の煩雑な情報設定を前提とすることなく、プロジェクトの進捗状況を的確に把握して迅速な対策を講ずることが可能な技術を提供することができる。

本発明の一実施の形態に係る開発プロセス評価管理方法を実施する開発プロセス評価管理システムにおける評価処理の原理を説明するための稼働日数と遅れ工数累計との関係の一例を示す線図である。 図１の線図のデータに対応した回帰直線の傾き角度の変化を示す線図である。 本発明の一実施の形態である開発プロセス評価管理方法を実施する開発プロセス評価管理システムの構成概要を示す図である。 本発明の一実施の形態である開発プロセス評価管理システムにおけるプロジェクト管理テーブルの構成を示す図である。 本発明の一実施の形態である開発プロセス評価管理システムにおけるプロジェクト評価テーブルの構成を示す図である。 本発明の一実施の形態である開発プロセス評価管理システムにおける連絡先登録テーブルの構成を示す図である。 本発明の一実施の形態である開発プロセス評価管理システムにおける連絡先判定テーブルの構成を示す図である。 本発明の一実施の形態である開発プロセス評価管理システムにおける動作設定テーブルの構成を示す図である。 本発明の一実施の形態である開発プロセス評価管理システムにおける進捗入力画面を示す図である。 本発明の一実施の形態である開発プロセス評価管理システムにおけるプロジェクト進捗履歴情報の構成例を示す図である。 図１０に例示されたプロジェクト進捗履歴情報のデータから最小自乗法の演算式で求めた傾き角度θを示す線図である。 本発明の一実施の形態に係る開発プロセス評価管理システムの全体的な動作を説明する処理の一例を示すフローチャートである。 本発明の一実施の形態に係る開発プロセス評価管理システムの評価処理実行部の評価処理監視部である評価処理起動タスクの処理の一例を示すフローチャートである。 本発明の一実施の形態に係る開発プロセス評価管理システムにおける評価処理のメインフローを示すフローチャートである。 本発明の一実施の形態に係る開発プロセス評価管理システムにおける異常判定の一例を示すフローチャートである。

以下、図面を参照しながら、本発明の一実施の形態について詳細に説明する。
まず、本実施の形態における開発プロセス評価管理技術の原理を図１および図２を参照して説明し、その後、当該原理を具現化した開発プロセス評価管理システム等について、具体的に説明する。

本実施の形態では、一態様として、稼働日（ｘｉ）毎の遅れの累積である遅れ工数累計（ｙｉ）をＸ−Ｙ座標でグラフ化し、遅延に対する変化度を示す変化量として、最小二乗法によって求められた回帰直線の傾き角度θを用い、この回帰直線の傾き角度θにより、開発工程等の進捗の遅延を検出する技術を例示する。

進捗の遅れが増えることは、回帰直線が示す遅れの傾き角度θが負の方向に増加することであり、たとえば、この傾き角度θの増加量を現在日（評価実施日）を含む過去の５日間の遅れ日数についての回帰直線の傾き角度θを、最小二乗法を用いて求める。

なお、傾き角度θ[度]は、後述の（式５）および（式６）で定められる回帰直線：ｙ＝ａｘ＋ｂ、の傾きをａ、円周率をπ、とすると、
θ［度］＝ｔａｎ^−１（ａ）×１８０／π ………（式１）
で求められる。

図１は、Ｘ軸を工程（稼働日（ｘｉ））、Ｙ軸を遅れ工数（ｙｉ）とした時のグラフである。
また、図２は、図１のグラフのデータ（ｘｉ，ｙｉ）から、当日〜４日前の実働期間で５日（この場合、土曜と日曜の休日を含む１週間に相当）分の回帰直線の傾き角度θのデ
ータの折れ線グラフである。

すなわち、図２は、５日目の稼働日から毎日、過去の５日間のデータ（ｘｉ，ｙｉ）について回帰直線の傾き角度θを求めてプロットした折れ線グラフである。
図２に例示されているように、遅れ工数が急激に増大（予定工数に対して、マイナス方向）している時は、傾き角度θはマイナスの傾きとなる。

その後、遅れが挽回できていないものの安定していれば傾き角度θはゼロになってくる。また、遅れが改善した場合は、傾き角度θがプラス方向に向いてくることが分かる。
更に、本実施の形態の場合、傾き角度θの特定の値によって、開発工程の進捗状況に関して下記のことが分かる。

すなわち、傾き角度θ＝−２６．６度、の場合、約０．５人日の割合で遅れていることがわかる。
また、傾き角度θ＝−４５度、の場合、１週間（実働で５日間）全く作業が進んでいないことを示す。

また、傾き角度θ＜−４５度、の場合、すなわち、マイナス方向にθの絶対値が４５より大きくなる場合、見積もりの誤りにより残工数が急激に増えたことが分かる。
これにより、開発プロセスの進捗状態において、遅れが増大しているのか、安定しているのか、前倒しになっているのか、等の動的な変化が、回帰直線の傾き角度θに基づいて自動的に判断することが可能となり、迅速な対応ができる。

また、傾き角度θの変化を折れ線グラフで可視化して表示することにより、開発プロセスの進捗状況の異常や回復を、管理者等が直感的に迅速に判断することが可能となる。
また、開発プロセスの進捗の評価において、傾き角度θを絶対値としてのみ使用するのではなく、傾き角度θの変化量が連続して増加した回数（この場合、日数）で判定することにより、たとえば、特許文献１で実施しているような、経験に基づいた複雑な閾値の絶対量を求めて設定する等の煩雑な準備作業が不要となる。

以下、本発明の実施の形態について、詳細に説明する。
図３は、本発明の実施の形態に係る開発プロセス評価管理方法を実施する開発プロセス評価管理システムの構成概要を示す図である。

図３において本発明の実施の形態に係る開発プロセス評価管理システムは、サーバ１０と、クライアントである管理者用端末２０，担当者用端末３０とにより構築され、ネットワーク１５を介してサーバ及びクライアントが通信可能に接続されている。なお、ネットワークは、有線、無線を問わず既存の公衆網、ＬＡＮ、ＷＡＮなどを用いることができる。

図３において、サーバ１０は、プロジェクトの管理情報を格納するためのプロジェクト管理テーブル１と、プロジェクトを評価するための作業計画に対する上限、下限、上々限、下々限などの数段階の判定閾値を格納するプロジェクト評価テーブル２と、異常発生時の連絡先のアドレスを格納する連絡先登録テーブル３と、異常発生の内容に応じて連絡先を判定するための連絡先判定テーブル４と、異常の監視方法を設定する動作設定テーブル５と、担当者により入力されたプロジェクトの進捗情報を保持するプロジェクト進捗情報保持部６と、プロジェクト進捗履歴情報７と、をデータベース８に備えている。

プロジェクト管理テーブル１、プロジェクト評価テーブル２、プロジェクト進捗情報保持部６、プロジェクト進捗履歴情報７は、機能毎に複数存在する。
またサーバ１０は、日報処理部１１、評価処理監視部１２（異常発生復旧チェック手段）、評価処理部１３（評価手段）からなる評価処理実行部１４（開発プロセス評価管理プログラム）を備えている。

日報処理部１１は、プロジェクトに携わる担当者から入力されたプロジェクト進捗情報を日報として処理するとともにプロジェクト管理テーブル１に格納されたプロジェクトの管理情報を基に開発フェーズ毎の作業実績工数を算出する。

評価処理監視部１２は、動作設定テーブル５に設定されたプロジェクトの進捗評価にかかる異常の監視方法に基づいて評価処理監視タスクを実行する。
評価処理部１３は、日報処理部１１により処理された情報および評価処理監視部１２で実行される評価処理監視タスクの結果に基づいて評価処理を行なう。

そして評価処理部１３が行なうプロジェクトの進捗評価により、異常の発生・復旧が認められた場合には、連絡先判定テーブル４を参照して所定の連絡先の判定を行ない、判定結果に応じて評価処理実行部１４からネットワーク１５を介して関係者に異常の発生・復旧を連絡先登録テーブル３に登録されているアドレスを元に自動的に通知する。

なお、図示はしていないが、サーバとしての機能を実現するためのハードウェア資源として、例えば、ＣＰＵ、記憶装置、入出力装置、各種インターフェースなど、を周知の構成として備えており、また当然ながら、上記のごとき機能を実現させるためのプログラムを上記記憶装置内に格納している。

データベース８は上述の記憶装置により実現され、また、評価処理実行部１４内の各構成は、上述のＣＰＵ、記憶装置、各種インターフェース等のハードウェア資源と後述する処理フローを実行する各種プログラムにより実現される。

一方、クライアントとしての管理者用端末２０は、上記した所定のテーブルに情報(プロジェクト初期情報)を入力するための設定画面２１（入力手段）と、プロジェクトの進行に伴う現在までの進捗状態を表示する進捗状態表示画面２２（表示手段）とを備えている。

また、クライアントとしての担当者用端末３０は、プロジェクトの進捗情報を入力するための進捗入力画面３１（入力手段）と、プロジェクトの進行に伴う現在までの進捗状態を表示する進捗状態表示画面３２（表示手段）と、を備えている。

なお、図示はしていないが、クライアントとしての機能を実現するためのハードウェア資源として、例えば、ＣＰＵ、記憶装置、入出力装置、各種インターフェースなど、を周知の構成として備えており、また上記のごとき機能を実現させるためのプログラムを上記記憶装置内に格納している。

図４は、図３のサーバ内に設けられたプロジェクト管理テーブルの構成を示す図である。図４においてプロジェクト管理テーブル１は、以下の各展開項目から構成される。
すなわち、プロジェクト管理テーブル１は、開発フェーズ４１、開発ステップ４２、開発フェーズ毎の開始予定日４３、開発フェーズ毎の終了予定日４４、開発フェーズ毎の投入人数である投入マンパワー４５（投入ＭＰ)から構成されている。

ここで、同一の開発ステップで参加人数が変わる場合は、フェーズを分けて入力する。
なお、プロジェクト管理テーブル１の情報は、プロジェクトの進捗情報の計画（予定）欄の情報と重複するため、プロジェクトの進捗情報の計画（予定）欄の情報を、このプロ
ジェクト管理テーブル１の情報を基に生成しても良い。

図５は、図３のサーバ内に設けられたプロジェクト評価テーブルの構成を示す図である。
本実施の形態の場合、プロジェクト評価テーブル２には、連続して増加、又は、減少した傾き角度θの判定のための閾値が設定されている。

本実施例では、角度連続増加数５１を判定する閾値として、工程の進捗の上々限５２、上限５３、下限５４、下々限５５の警告範囲を設けており、上々限５２、上限５３は、工程の進みを、下限５４、下々限５５は工程の遅れを示している。なお、これらの段階の数については必要に応じて、増減してもかまわない。

図６は、図３のサーバ内に設けられた連絡先登録テーブルの構成を示す図である。
図６に示す連絡先登録テーブル３には、氏名６１、登録者種別６２、連絡先メールアドレス６３、電話番号６４が項目として設けられている。なお、登録者種別６２としては、本プロジェクト遂行にかかる職制が用いられている。

図７は、図３のサーバ内に設けられた連絡先判定テーブルの構成を示す図である。
図７に示す連絡先判定テーブル４は、開発段階を示すフェーズＦ−１〜Ｆ−８の各々毎に設けられている。

個々の連絡先判定テーブル４には、該当フェーズを示すフェーズ７１、上級管理者７２、プロジェクトマネージャ７３（ＰＭ）、担当者７４（担当者Ａ）、担当者７５（担当者Ｂ）、等が連絡先に登録され、これに対して、図５で説明したように予定(計画)に対し上々限５２、上限５３、下限５４、下々限５５、傾き角度θ＝−４５度、−４５度＞θ、の６種類の異常や事象の発生７６、復旧７７における動作を示す項目（欄）が設けられている。

図７の各欄において、○は通知要を、−は通知否を表している。
そして、後述のプロジェクト進捗履歴情報７に基づいて評価されたプロジェクト進捗状況が、図５に示したプロジェクト評価テーブル２によって異常判定され、異常や特定事象の発生が認められた場合に、その発生内容に応じて、この連絡先判定テーブル４を用いて、上級管理者７２から担当者Ｂ７５の中のだれに対して通知を要するかを判定する。

図８は、図３のサーバ内に設けられた動作設定テーブルの構成を示す図である。
図８において動作設定テーブル５は、図３に示した担当者用端末３０から入力された「プロジェクトの進捗情報」（日報）から抽出されたプロジェクト進捗履歴情報７に基づいて、サーバ１０におけるプロジェクトを評価する評価処理の実行時間を指定するためのものである。

本実施の形態の動作設定テーブル５では、具体的には、図８に示すような、評価処理起動方法８１、評価処理実行時刻８２、日指定フラグ８４、日報入力遅延監視日８５、日報入力遅延監視日８６、日報入力遅延監視日８７の情報を含む構成となっている。

評価処理起動方法８１としては、以下の３種類の指定を設けている。すなわち、
（１）フラグ=０：評価処理を実行しない
（２）フラグ=１：入力完了時に実行
（３）フラグ=２：評価処理実行時刻に実行 １回／１日
評価処理実行時刻８２では、時間、分を指定する。そしてこの時間は、日報入力チェックを行なう時間にも使用される。

日替わり日指定フラグ８４は、評価処理実行時刻の当日をチェック日とするか、前日をチェック日とするかを指定する。
フラグ=０は前日、フラグ=１の場合は当日とする。例えば、評価処理実行時刻を、０１：００とした場合は前日(フラグ=０)を指定する。夕方の１８：００にする場合は、当日(フラグ=１)を指定する。

日報入力遅延監視日８５は、担当者に、入力遅延の連絡の有無と連絡する場合に、何日分遅れたら連絡するかを定義する。
日報入力遅延監視日８６は、ＰＭ(プロジェクトマネージャ)に、入力遅延の連絡の有無と連絡する場合に、何日分遅れたら連絡するかを定義する。

日報入力遅延監視日８７は、上級管理者に、入力遅延の連絡の有無と連絡する場合に、何日分遅れたら連絡するかを定義する。
なお、本実施の形態の例では以下の理由のため、１回／日評価作業を行うテーブルとしている。すなわち、プロジェクトの進捗管理には迅速性を要求されるため、１週間に１回では、遅いからである。

ただし、評価処理を無効とした場合は、入力完了後に評価処理が動作するが、プロジェクトの参加人数によっては、同時に入力されるとサーバ１０の負荷が高くなるので、注意が必要となる。

図９に、端末からプロジェクトの進捗情報をプロジェクト進捗情報保持部６に入力する進捗入力画面３１の構成例を示す。
プロジェクト進捗情報保持部６は、項目９１、開発フェーズ９２、担当者９３、残工数９４、集計工数９５、進捗率９６、予定マンパワー欄９７、実績マンパワー欄９８で構成され、進捗入力画面３１もこの構成に対応した同様な構成となっている。

計画時に、項目９１に対応した開発フェーズ９２、担当者９３に対応した予定マンパワー欄９７に日毎の予定マンパワー（ＭＰ）（単位：時間）を入力する。
コーディング作業など複数人で作業を行う場合には、担当者毎に進捗管理できるように項目９１（ＮＯ．）を分けて入力する。

運用時には、実績マンパワー欄９８に、実績の作業工数（単位：時間）を１日に１回入力する。
残工数９４は、通常「残工数＝予定工数−実績工数」、で自動的に求められるが、作業を進めていくに従って計画に対して工数が増減した場合は、残工数を手入力する。

集計工数９５には、「予定」と「作業」の二つを上下の二欄に対照して表示し、「予定」は、予定マンパワー欄９７の集計結果を示し、「作業」は、作業工数の集計結果を示し、予定工数と単位を表すために、実績マンパワー欄９８に入力された実績の作業工数から自動的に人日で集計する。

進捗率９６は、下記で自動計算される。
進捗率＝作業工数／（作業工数＋残工数） ………（式２）
尚、図９の例では、予定工数の２０日に対して、実績マンパワー欄９８では、稼働日数１０１で４日目までの作業工数を入力したものを示している。

図１０に、本実施の形態のプロジェクト進捗履歴情報の構成例を示す。
このプロジェクト進捗履歴情報７は、図９の進捗情報の進捗入力画面３１のデータから
評価処理部１３によって自動的に生成される。

プロジェクト進捗履歴情報７は、稼働日数１０１、実動日付１０２、残工数１０３、予定工数１０４、作業工数１０５、当日の遅れ工数１０６、遅れ工数累計１０７、傾き角度１０８（傾き角度θ）が、稼働日数１０１毎に格納されるテーブルである。

なお、稼働日数１０１は、実働の経過日数を示し、後述のｘｉに相当する。
このうち、実動日付１０２、残工数１０３、予定工数１０４、作業工数１０５は、進捗入力画面３１のプロジェクト進捗情報からコピーされる。

すなわち、実動日付１０２は、進捗入力画面３１の日付の実稼動日に対応する。
同様に、残工数１０３は、進捗入力画面３１の残工数９４に対応する。
同様に、予定工数１０４は、進捗入力画面３１の日毎の予定ＭＰを人日に変換したものに対応する。

同様に、作業工数１０５は、進捗入力画面３１の日毎の実績ＭＰを人日に変換したものに対応する。
一方、当日の遅れ工数１０６、遅れ工数累計１０７、傾き角度１０８は計算で求められる。

すなわち、当日の遅れ工数１０６は、下記の式にて求める。
当日の遅れ工数＝−１×｛当日の作業の遅れ＋工数見直しよる作業の遅れ｝ ＝ −１×｛（当日の予定工数−当日の作業工数）＋（前日の残工数−当日の残工数＋当日の予定工数）｝ ………… （式３）
また、遅れ工数累計１０７は、下記の式にて求める。この遅れ工数累計１０７は、後述のｙｉに相当する。

遅遅れ工数累計＝前日の遅れ工数＋（当日の予定工数−作業工数） ……（式４）
また、傾き角度１０８（傾き角度θ）は、以下のような、最小二乗法の演算式にて求める。

すなわち、稼働日数１０１毎のｘｉとｙｉの組であるｎ個のデータ（ｘ１，ｙ１），（ｘ２，ｙ２），．．．（ｘｎ，ｙｎ）があり、その回帰直線をｙ＝ａｘ＋ｂとした時、
下記の（式５）および（式６）に例示される演算式で、ａ：傾き、ｂ：切片が、それぞれ求められる。

本実施の形態の場合、５つのデータ、すなわち稼働日数１０１の連続した５日分から回帰直線の傾きａ（すなわち、傾き角度θ）を求めるため、最初の４日間については、データはない。

本例では、４月８日以降、４月１５日になるまで、作業はしているが進捗が無かった場合を示している。
このため、遅れ、すなわち遅れ工数累計１０７が、毎日増えており、稼働日数１０１の５日連続で同じ残工数のため、傾き角度θが、負の方向に徐々に増えていることが分かる。

図１１は、図１０に例示されたプロジェクト進捗履歴情報７のデータから最小自乗法の演算式で求めた、回帰直線の傾き角度θをグラフ化したものである。
この図１１の例では、横軸に稼働日数１０１、縦軸に、その日の傾き角度θの値がプロットされた折れ線グラフ１１０となっている。

なお、この折れ線グラフ１１０を、管理者用端末２０や担当者用端末３０の進捗状態表示画面２２や進捗状態表示画面３２として表示することもできる。
その場合、折れ線グラフ１１０の形と、横軸の稼働日数１０１から、遅れ工数の推移、すなわち、遅れ（異常）の発生（折れ線グラフ１１０が右肩下がり）、回復（折れ線グラフ１１０が右肩上がり）、正常（折れ線グラフ１１０が水平）等の進捗状態を直感的に把握することが可能となる。

図１２は、本発明の実施の形態に係る開発プロセス評価管理システムの全体的な動作を説明する処理の一例を示すフローチャートである。
図１２に示す処理フローを、図３に示した開発プロセス評価管理システムの構成概要とともに説明する。

図１２の処理フローにおいて、左側に示す処理フロー（ａ）は、図３に示す管理者用端末２０を使ったＰＭ（プロジェクトマネージャ）によるプロジェクト初期設定（ステップＳ２０）を示すもので、ＰＭ（プロジェクトマネージャ）は、プロジェクト開始時に図３に示したサーバ１０内のデータベース８の各種テーブルへの設定を行なう（ステップＳ２１）。

すなわち、プロジェクトの管理情報を格納するためのプロジェクト管理テーブル１、プ
ロジェクトを評価するための作業計画に対する上限５３、下限５４、上々限５２、下々限５５などの数段階の判定閾値を格納するプロジェクト評価テーブル２、異常発生時の連絡先のアドレスを格納する連絡先登録テーブル３、異常発生の内容に応じて連絡先を判定するための連絡先判定テーブル４、および、異常の監視方法を設定する動作設定テーブル５、のそれぞれに対して設定登録を行なう。

次いで図１２の中央及び右側に示す処理フロー（ｂ），処理フロー（ｃ）に示すように、サーバ処理（ステップＳ１０）では、まず、サーバ１０は進捗データ(画面)のクライアント(図３に示す担当者用端末３０)への送信を行なう（ステップＳ１１）。

担当者端末処理（ステップＳ３０）では、担当者は、担当者用端末３０を使って進捗入力画面の呼び出しを行なう（ステップＳ３１）。これらの処理は、通常のクライアント・サーバシステムにおけるログオン処理に相当する。そして、担当者は、その日における作業を実施した後に、その日の作業に対応する作業時間（日報）を入力し、サーバ１０内の評価処理実行部１４に入力データを送信する（ステップＳ３２）。

これを受けて処理フロー（ｂ）では、評価処理実行部１４内の日報処理部１１で担当者用端末３０から送信された日報の登録を行なう（ステップＳ１２）。
このステップＳ１２の処理においては、データベース８におけるプロジェクト進捗情報保持部６にデータが登録される。

日報の登録がなされたら、評価処理実行部１４内の評価処理監視部１２により、動作設定テーブル５（図８参照）の設定内容を参照して、評価処理を実行してよいかどうかを判定し、図８に示す評価処理の実行方法におけるフラグが「入力完了時実行」の設定の場合には（ステップＳ１３：Yes）、評価処理実行部１４内の評価処理部１３により、入力されたデータの［評価処理］を実行する（ステップＳ１４）。

この［評価処理］については後述する。そして［評価処理］の実行の結果、新規に異常が発生した場合（ステップＳ１５：Yes）は、評価処理実行部１４内の評価処理部１３からネットワーク１５を経てクライアント（担当者端末）に評価結果としての異常情報の通知を行なう（ステップＳ１６）。この異常情報の通知についても後述する。

一方、処理フロー（ｃ）における担当者端末（クライアント）処理では、評価処理実行部１４から評価結果を受信した場合には、端末画面に評価結果の表示を行なう（ステップＳ３３）。

図１３は、評価処理実行部１４の評価処理監視部１２である評価処理起動タスクの処理の一例を示すフローチャートである。
図１３の左側に示す処理フロー（ａ）は、評価処理起動タスクのメインフローを示すもので、サーバ１０の起動時に起動され、常時、評価処理の起動監視を行なっている。この評価処理起動タスクの処理は、上述したように評価処理実行部１４内の評価処理監視部１２において実施する。

この評価処理タスクは、サーバ１０の起動時に、起動され常時動作しており、指定時間に評価処理を実行するための処理である。
まず、「動作設定テーブル５」を参照し（ステップＳ４１）、「評価動作設定」テーブルの「評価処理の起動方法」＝２（評価処理実行時刻に実行）であれば、動作設定テーブル５から評価処理実行時間を読み出し（ステップＳ４２）、評価処理実行時間の時間になるまで待つ（ステップＳ４２ａ）。

ステップＳ４１で無効（Ｎｏ）の場合は、一定時間処理を停止し（ステップＳ４３）、再度定義があるかどうかをチェックする。これは、サーバ起動後に、設定が変更されても評価処理が実行されるようにするためである。

上述のステップＳ４２ａの後、評価処理実行時間が到来したら、スリープ中に「評価処理実行時刻」が変更されていないか確認するために、現時刻と比較し（ステップＳ４２ｂ）、変更がなければ対象となる全ての日報（プロジェクト進捗情報保持部６）が入力されているか「日報（プロジェクト進捗情報保持部６）の入力チェック」処理でチェックする（ステップＳ４４、ステップＳ４５）。

なお、上述のステップＳ４２ｂで変更があったと判定され場合（Ｎｏ）は、タスクの先頭のステップＳ４１に戻り再度、評価処理実行時刻を待つ。
その後、動作設定テーブル５の評価処理起動方法８１が、「評価処理実行時間に実行」の定義がされている場合には（ステップＳ４６）、評価処理を呼び出す（ステップＳ４７）。

図１３の右側の処理フロー（ｂ）に示す「日報（「プロジェクト進捗情報」）の入力チェック」処理は、上級管理者、ＰＭ（プロジェクトマネージャ）、担当者毎に指定されている最終入力の遅延日をチェックし、入力がされていない場合には、未入力通知を下記手順で行なう（ステップＳ５１）。すなわち、監視が有効であった場合には、現在日と動作設定テーブル５に定義されている日替わり日指定フラグ８４から入力が完了すべき「入力確認日」を決定する。

日替わり日指定フラグ８４において、
日替わり日指定フラグ＝０（前日指定）：現在日の前日をチェックする「入力確認日」とする（ステップＳ５２）
日替わり日指定フラグ＝１（当日指定）：現在日をチェックする「入力確認日」とする（ステップＳ５３）
次いで「プロジェクト進捗情報」の入力が完了すべき「入力確認日」から過去に遡って、図９に示す当該月の作業日の時間を入力する欄の２列目に入力がされている月日で最終入力日を見つけ（ステップＳ５４）、実稼動日（休日を除く、勤務日）を除いた「入力確認日」と「最終入力日」の差分を求める（ステップＳ５５）。

なお、実稼動日は、「プロジェクトの進捗情報」の日毎の予定時間の入力がない日で判断するか、別途稼動日、非稼動日を設定するテーブルを設けても良い。そしてその差分が、上級管理者、ＰＭ（プロジェクトマネージャ）、担当者毎に指定されている遅延日（図８に示す動作設定テーブル５の日報入力遅延監視日８５から日報入力遅延監視日８７の定義参照）以上であれば、対象者に連絡を行う（ステップＳ５６〜ステップＳ６４）。

図１４に、評価処理のメインフローを示す。この評価処理は、上述のステップＳ４７で呼び出される処理である。
まず、プロジェクト進捗情報保持部６のプロジェクトの進捗情報からプロジェクト進捗履歴情報７を生成または更新する（ステップＳ７１）（第１ステップ）。

そして、評価処理をプロジェクト開始前から５日以上経過してから開始させるため、プロジェクト開始前から５日以上経過しているか判定する（ステップＳ７２）。
これは、上述のように、最小二乗法で求める傾きを、稼働日数１０１の５日分の５つのデータから求めているためである。

そして、５日以上経過していると判定されたら、まず、現在日（評価実施日）を含む過
去の５日分の回帰直線を求め、傾き角度θを算出する（ステップＳ７３）（第２ステップ）。

その後、後述の図１５に例示される「異常判定」処理を呼び出す（ステップＳ７４）（第３ステップ）。
そして、「異常判定」処理で異常が発生していると判定された場合は（ステップＳ７５）、図７の連絡先判定テーブル４を参照して異常の情報を通知する（ステップＳ７６）。

なお、このとき、上述の図１１の折れ線グラフ１１０の情報を同時に通知してもよい。
図１５は、本実施の形態の異常判定の一例を示すフローチャートである。
本実施の形態の場合、傾き角度θが−４５度より小さい場合（負で絶対値が４５度より大きい場合）は、見直しによる工数の増大が発生したと判断できるので、これを最優先に判定する。

その次に、傾き角度θ＝−４５度の場合は、作業の進捗が１週間（５日）停滞していることを示すので、これを2番目に判定する。
その後、傾き角度θの連続異常発生回数の上々限５２、上限５３、下々限５５、下限５４の順に判定を行う。

異常判定に際しては、−４５度＞傾き角度θの判定については、実稼動日（稼働日数１０１）で５日分のデータが収集されていないと判定できないので、実稼動日で５日目以降の判定となる。

また、異常からの復旧の判定に関しては、実稼動日で５日目が最初の判定日であり、最初に異常を検出する日となるので、実稼動日で６日目以降に復旧判定ができる。
同様に、上々限５２、上限５３、下々限５５、下限５４による連続異常回数の判定は、図５のプロジェクト評価テーブル２のデータが集まってから行う。

いずれも新規に異常が発生した場合のみ異常通知を行い、発生条件を満たさなくなった（異常が復旧した）場合は、復旧通知を行う。
すなわち、図１５に例示される本実施の形態の進捗状況の異常判定では、まず、「傾き角度θが−４５度より小さいか（θ＜−４５度）」を判定し（ステップＳ８１）、小さい場合には、さらに、「稼動日が５日目か、又は前日の傾き角度θが−４５度より小さいか」を判定し（ステップＳ８２）、小さい場合には、「異常発生」として戻る（ステップＳ８３）。

一方、ステップＳ８１でＮＯの場合には、まず、「稼動日が６日以降で、且つ前日の傾き角度θが−４５度以上か」を判定し（ステップＳ８４）、条件成立（ＹＥＳ）の場合には、仮に「異常復旧」とし（ステップＳ８５）、さらに「傾き角度θ＝−４５度か」を判定し（ステップＳ８６）、条件成立の場合には、さらに、「稼動日が５日目か、又は前日の傾き角度θが−４５度以外か」を判定し（ステップＳ８７）、条件成立の場合には、最終的に「異常発生」とし（ステップＳ８８）、不成立の場合には、最終的に「異常復旧」として戻る。

一方、上述のステップＳ８６で、不成立（傾き角度θ≠−４５度）の場合には、まず、「稼動日が６日以降で、且つ前日の傾き角度θが−４５度か」を判定し（ステップＳ８９）、条件成立の場合には、仮に「異常復旧」とみなす（ステップＳ９０）。

さらに、「プロジェクト評価テーブルの下々限に設定してある回数分データが収集されており、そのデータが連続して、前日の値よりも傾き角度θが小さいか」を判定し（ステ
ップＳ９１）、条件成立の場合には、さらに、「稼働日数と下々限に設定してある回数の和を経過しているか、又は前日に下々限異常が発生してないか」を判定し（ステップＳ９２）、条件成立の場合には最終的に「異常発生」と判定して戻り（ステップＳ９３）、不成立の場合には、最終的に上述のステップＳ９０の「異常復旧」と判定して戻る。

一方、上述のステップＳ９１で、不成立の場合には、まず、「前日に下々限異常が発生しているか」を判定し（ステップＳ９４）、条件成立の場合には、仮に「異常復旧」とする（ステップＳ９５）。

さらに、「プロジェクト評価テーブルの下限に設定してある回数分データが収集されており、且つ、そのデータの傾き角度θが連続して、前日の傾き角度θの値よりも小さいか」を判定し（ステップＳ９６）、条件成立の場合には、さらに、「稼働日数と下限に設定してある回数の和を経過しているか、又は、前日に下限異常が発生してないか」を判定し（ステップＳ９７）、条件成立の場合には最終的に「異常発生」として戻り（ステップＳ９８）、不成立の場合には、最終的に上述のステップＳ９５の「異常復旧」と判定して戻る。

一方、上述のステップＳ９６で不成立の場合には、「前日に下限異常が発生しているか」を判定し（ステップＳ９９）、条件成立の場合には、仮に「異常復旧」とする（ステップＳ１００）。

さらに、「プロジェクト評価テーブル２の上限に設定してある回数分データが収集されており、そのデータが連続して、前日の傾き角度θの値よりも傾き角度θが大きいか」を判定し（ステップＳ１０１）、条件成立の場合にはさらに、「稼動日数と上々限に設定してある回数の和を経過しているか、又は前日上々限異常が発生してないか」を判定し（ステップＳ１０２）、条件成立の場合には、最終的に「異常発生」と判定して戻る（ステップＳ１０３）。

一方、上述のステップＳ１０１で、不成立の場合には、「前日に上々限の異常が発生しているか」を判定し（ステップＳ１０４）、条件成立の場合には仮に「異常復旧」とみなし、さらに、「プロジェクト評価テーブルの上限に設定してある回数分データが収集されており、そのデータが連続して、前日の傾き角度θの値よりも傾き角度θが大きいか」を判定し（ステップＳ１０６）、条件成立の場合には、さらに、「稼動日と上限に設定してある回数の和だけ経過しているか、または前日に上限異常が発生してないか」を判定し（ステップＳ１０７）、条件成立の場合には、最終的に「異常発生」と判定して戻り（ステップＳ１０８）、不成立の場合には、最終的に、上述のステップＳ１０５の「異常復旧」と判定して戻る。

一方、上述のステップＳ１０６で不成立の場合には、「前回上限の異常が発生しているか」を判定し（ステップＳ１０９）、条件成立の場合には、最終的に「異常復旧」と判定し（ステップＳ１１０）、不成立の場合も、上述のステップＳ１０５の「異常復旧」と判定して戻る。

このように、本実施の形態によれば、開発プロセスの進捗状況の異常の有無等を、評価処理部１３において、稼働日数１０１と遅れ工数累計１０７に基づく回帰直線の傾き角度θを演算し、遅れの増加等の異常を傾き角度θの負の方向への増加として検出することにより、煩雑な閾値を設定する等の前提作業を必要とすることなく、的確に開発プロジェクトの異常の監視が可能となる。

このため、評価処理部１３は、傾き角度θに基づいて、プロジェクトの遅れがそのまま
増大しているのか、沈静化しているのか自動的に判断することができるので、開発フェーズが予定どおり進んでいるかを自動的に、関係者に連絡することができ、管理者の負担を軽減することができる。

更に、遅れを示す傾き角度θの変化を折れ線グラフ１１０のように可視化して関係者の管理者用端末２０や担当者用端末３０に表示することで、各関係者は、熟練等を必要とすることなく、直感的にプロジェクトの進捗状況の問題点を正確に把握することができる。

すなわち、本実施の形態によれば、スキルを必要とする閾値設定等の煩雑な情報設定を前提とすることなく、プロジェクトの進捗状況を的確に把握して迅速な対策を講ずることが可能な技術を提供することができる。

なお、本発明は、上述の実施の形態に例示した構成に限らず、その趣旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
たとえば、サーバ１０と管理者用端末２０、またはサーバ１０と担当者用端末３０を一つのパーソナルコンピュータ等の情報処理装置で構成し、この一つの情報処理装置で開発プロセス評価管理システムを実現する構成としてもよい。

１ プロジェクト管理テーブル
２ プロジェクト評価テーブル
３ 連絡先登録テーブル
４ 連絡先判定テーブル
５ 動作設定テーブル
６ プロジェクト進捗情報保持部
７ プロジェクト進捗履歴情報
８ データベース
１０ サーバ
１１ 日報処理部
１２ 評価処理監視部
１３ 評価処理部
１４ 評価処理実行部
１５ ネットワーク
２０ 管理者用端末
２１ 設定画面
２２ 進捗状態表示画面
３０ 担当者用端末
３１ 進捗入力画面
３２ 進捗状態表示画面
４１ 開発フェーズ
４２ 開発ステップ
４３ 開始予定日
４４ 終了予定日
４５ 投入マンパワー
５１ 角度連続増加数
５２ 上々限
５３ 上限
５４ 下限
５５ 下々限
６１ 氏名
６２ 登録者種別
６３ 連絡先メールアドレス
６４ 電話番号
７１ フェーズ
７２ 上級管理者
７３ プロジェクトマネージャ
７４ 担当者
７５ 担当者
７６ 発生
７７ 復旧
８１ 評価処理起動方法
８２ 評価処理実行時刻
８４ 日指定フラグ
８５ 日報入力遅延監視日
８６ 日報入力遅延監視日
８７ 日報入力遅延監視日
９１ 項目
９２ 開発フェーズ
９３ 担当者
９４ 残工数
９５ 集計工数
９６ 進捗率
９７ 予定マンパワー欄
９８ 実績マンパワー欄
１０１ 稼働日数
１０２ 実動日付
１０３ 残工数
１０４ 予定工数
１０５ 作業工数
１０６ 当日の遅れ工数
１０７ 遅れ工数累計
１０８ 傾き角度
１１０ 折れ線グラフ
θ 傾き角度

Claims (11)

1. クライアント及びサーバを含む開発プロセス評価管理システムであって、
   前記サーバは、
   プロジェクトの管理情報を格納するプロジェクト管理テーブルと、
   前記プロジェクトの進捗状況の異常の有無を評価するための判定基準情報を格納するプロジェクト評価テーブルと、
   前記プロジェクト管理テーブルから、プロジェクト進捗履歴情報として、個々の稼働日毎の遅れ工数累計と、複数の前記稼働日の前記遅れ工数累計の回帰直線の傾き角度を求める評価手段と、
   前記プロジェクト評価テーブルと、前記傾き角度から、前記プロジェクトの前記異常の発生および復旧を検出する異常発生復旧チェック手段と、
   を有し、
   前記クライアントは、
   前記プロジェクトの進捗情報の入力を受け付ける入力手段と、
   前記プロジェクトの進行に伴う現在までの進捗状態と、前記評価手段による評価結果を表示する表示手段と、
   を有する
   ことを特徴とする開発プロセス評価管理システム。
2. 請求項１記載の開発プロセス評価管理システムにおいて、
   前記サーバの前記評価手段は、最小自乗法によって前記回帰直線を決定することを特徴とする開発プロセス評価管理システム。
3. 請求項１記載の開発プロセス評価管理システムにおいて、
   前記クライアントの前記表示手段では、前記評価結果として、前記稼働日に対する前記傾き角度の変化を示す折れ線グラフを表示することを特徴とする開発プロセス評価管理システム。
4. プロジェクトにおける稼働日の各々の遅れ工数累計を集計する第１ステップと、
   過去の複数の前記稼働日と前記遅れ工数累計の組合せから得られる回帰直線の傾き角度を求める第２ステップと、
   前記傾き角度に基づいてプロジェクトの進捗状況を評価する第３ステップと、
   を含むことを特徴とする開発プロセス評価管理方法。
5. 請求項４記載の開発プロセス評価管理方法において、
   前記第２ステップでは、複数の前記稼働日と前記遅れ工数累計の組合せから最小自乗法によって前記回帰直線を決定することを特徴とする開発プロセス評価管理方法。
6. 請求項４記載の開発プロセス評価管理方法において、
   前記第３ステップでは、
   前記稼働日に対する前記傾き角度の変化を折れ線グラフとして表示することを特徴とする開発プロセス評価管理方法。
7. 請求項４記載の開発プロセス評価管理方法において、
   前記第３ステップでは、
   前記傾き角度が、負の方向に変化した回数が所定の閾値に到達した場合に前記プロジェクトの進捗状況に異常が発生したと評価し、
   前記傾き角度が正の方向に変化した回数が所定の閾値に到達した場合に前記プロジェクトの進捗状況の前記異常が回復したと評価する、ことを特徴とする開発プロセス評価管理
   方法。
8. プロジェクトにおける稼働日の各々の遅れ工数累計を集計する第１ステップと、
   過去の複数の前記稼働日と前記遅れ工数累計の組合せから得られる回帰直線の傾き角度を求める第２ステップと、
   前記傾き角度に基づいてプロジェクトの進捗状況を評価する第３ステップと、
   をコンピュータに実行させることを特徴とする開発プロセス評価管理プログラム。
9. 請求項８記載の開発プロセス評価管理プログラムにおいて、
   前記第２ステップでは、複数の前記稼働日と前記遅れ工数累計の組合せから最小自乗法によって前記回帰直線を決定することを特徴とする開発プロセス評価管理プログラム。
10. 請求項８記載の開発プロセス評価管理プログラムにおいて、
    前記第３ステップでは、
    前記稼働日に対する前記傾き角度の変化を折れ線グラフとして表示することを特徴とする開発プロセス評価管理プログラム。
11. 請求項８記載の開発プロセス評価管理プログラムにおいて、
    前記第３ステップでは、
    前記傾き角度が、負の方向に変化した回数が所定の閾値に到達した場合に前記プロジェクトの進捗状況に異常が発生したと評価し、
    前記傾き角度が正の方向に変化した回数が所定の閾値に到達した場合に前記プロジェクトの進捗状況の前記異常が回復したと評価する、ことを特徴とする開発プロセス評価管理プログラム。