JP2006085277A - プロジェクト管理装置 - Google Patents

Abstract

【課題】 プロジェクトの状況を視覚を通じて客観的に評価できるプロジェクト管理装置を提供する。
【解決手段】 プロジェクトにおける端末Ａ１、Ｂ１等より受信したインプットデータに基づいて管理すべきプロジェクトの状況の一側面を表す指標であるプロジェクト管理指標があって、前記プロジェクト管理指標に基づいてプロジェクトの評価を行い、プロジェクトマネージャ側の端末ＭＡ、ＭＢ、…に対して該評価に関する一連のデータを送信するプロジェクト管理装置ＰＭにおいて、前記プロジェクト管理指標に係るデータであるプロジェクト管理指標データを生成するプロジェクト管理指標生成手段１と、前記プロジェクト管理指標データを可視化するデータ可視化手段３を有する。
【選択図】 図１

Description

本発明は、ソフトウェアを開発するプロジェクトにおけるプロジェクト管理装置に関する。

近年、各種製品における機能の増加が求められることにより、ソフトウェア規模が増大する一方で、素早く製品を世の中に出すためにソフトウェアの開発期間の短縮が求められる傾向にある。このような傾向により、開発者のスキル向上、生産性の増大だけでなく、プロジェクト管理の方法によって、ソフトウェア開発におけるプロジェクトの成否が決定する時代になってきている。

プロジェクト管理の方法の一例としては、現状のプロジェクトの進捗状況、将来起こりうるリスクの発生可能性の有無等を正確に把握するものがあるが、そのようにして素早く対応するようなプロジェクトの進め方が必要になってきている。また、プロジェクト管理の手法もプロジェクトマネージャ個人のスキルに委ねるのではなく、一元化・効率化するためにプロジェクトマネージャ・開発者等、各人で管理状態を共有して把握することが必要になってきている。

プロジェクト管理を行うときには、管理すべきプロジェクトの状況の一側面を表す指標（以下「プロジェクト管理指標」という。）を採りあげ、各指標について適当な方法により評価していく。プロジェクト管理指標としては、スケジューリング、コスト、ソフトウェア品質、人的スキル、リスク等が挙げられ、プロジェクトの成否においてはこれらのプロジェクト管理指標をいかにうまく管理していくかが重要である。

しかし、一般に市販されているプロジェクト管理ツールは、スケジュールに対する差異分析により評価するものであったり、プロジェクトマネージャの主観による段階的評価によるものであるものが多い。このような評価方法では、一のプロジェクトの状況に対し、各ツールを使用しても異なる評価結果が出力される可能性が高くなる。一のプロジェクト管理指標に対しても同様である。従って、各プロジェクトマネージャ・開発者間で統一的な見解が得られず、プロジェクトの成否の決定に支障をきたす。

プロジェクトマネージャにおいても、プロジェクトのどこに問題があるのかを客観的に閲覧できるプロジェクト管理指標がなく、過去のプロジェクトで得られた勘と経験に基づいて管理を行なってきている。同様に、上級マネージャがプロジェクトの状況を正確にかつ客観的に把握できる手段もないのが現状である。プロジェクトをいろいろな側面から、客観的に評価する方法が求められている。

さらにプロジェクト管理指標によっては、プロジェクトの進捗状況に応じてその指標の重要性が変化するものがある。例えば、開発当初はソフトウェアの早期構築を果たすために品質に係るリスクのプロジェクト管理指標が重要であるが、終盤にかけては納期に係るリスクのプロジェクト管理指標が重要である。評価の精度を高めるためには、このような指標に対しその評価方法をプロジェクトの進捗状況に応じて適宜設計変更する方が良い場合がある。いわばプロジェクトに係るトレンドに追従した評価方法が求められている。

特許文献１の「プロジェクト管理システム、プログラムおよび記憶媒体」では、アウトプット文書を視覚的に管理することによって進捗管理を行なう技術が示されている。視覚的に行う故、客観性は確保されているものの、プロジェクトにおける様々なプロジェクト管理指標でプロジェクトの現状を視覚化するために、アウトプット文書に限定することは実状に沿わない。

特許文献２の「プロジェクト管理システム」では、上級マネージャが管理下のプロジェクトの評価結果を評価点として点数化し、プロジェクト自体の評価を行なう技術が示されている。点数化することにより客観性が確保されているともいえるが、ある決められたチェックリストに対してプロジェクトマネージャが評価する方法を採用している。従って、プロジェクトマネージャの主観による評価であるのと同時に、プロジェクトに係るトレンドに追従することができず、欲しい時に欲しい情報を得ることができないといった問題点がある。
特開２００３−１４１３２０号公報 特開２００３−１９６４４７号公報

上記事情を鑑みて本発明の課題は、プロジェクトの状況を視覚を通じて客観的に評価できるプロジェクト管理装置を提供することである。その際、必要に応じてプロジェクトの状況を常に見ることができ、問題に対して評価方法を適宜設計変更することにより素早く対応できるようにする。

上記課題を解決する本発明の態様は、プロジェクトにおける端末より受信したインプットデータに基づいて管理すべきプロジェクトの状況の一側面を表す指標であるプロジェクト管理指標があって、前記プロジェクト管理指標に基づいてプロジェクトの評価を行い、プロジェクトマネージャ側の端末に対して該評価に関する一連のデータを送信するプロジェクト管理装置において、前記プロジェクト管理指標に係るデータであるプロジェクト管理指標データを生成するプロジェクト管理指標生成手段と、前記プロジェクト管理指標データを可視化するデータ可視化手段を有するものである。

このプロジェクト管理装置は、プロジェクトの進捗状況に応じて種々の前記インプットデータを構成するパラメータを設計変更する経時変更手段を有することにより、プロジェクトに係るトレンドに追従した評価を行うことができる。

前記プロジェクト管理指標として、プロジェクトおけるリスクの重要度があり、前記プロジェクト管理指標データは、前記リスクの重要度を定量化したデータである。
このプロジェクト管理指標データは、前記リスクの重要度の定量化において、前記リスクの発生可能性及び前記リスクの影響度の双方を定量化し、定量化された前記リスクの発生可能性及び前記リスクの影響度の双方に基づいて順位付けされる。さらに、前記インプットデータを構成するパラメータの一部である品質、コスト、納期に基づいて、前記リスクの影響度を定量化すると良い。

そして、前記経時変更手段は、品質、コスト、納期に係る前記パラメータに対し、時間的推移に応じた重み付けの変更を行うことにより、プロジェクトに係るトレンドに追従した評価を行うことができる。

一方、前記インプットデータは、プロジェクトにおけるソースコード量、ソースコードの品質、テスト消化数、ソフトウェア欠陥発見数、メンバのスキルの何れかであり、前記プロジェクト管理指標は、ソースコード量、ソースコードの品質、テスト消化数、ソフトウェア欠陥発見数、メンバのスキルに係る所定の基準値と、プロジェクトの実績として表されるソースコード量、ソースコードの品質、テスト消化数、ソフトウェア欠陥発見数、メンバのスキルに係る値を各々比較した比較結果であり、前記プロジェクト管理指標データは、前記比較結果を定量化したデータである。

以上のプロジェクト管理指標データに基づいて対象となるプロジェクトの評価を行い、その評価に対する結果に係るデータであるプロジェクト評価結果データを生成するプロジェクト評価結果生成手段をさらに有する。前記プロジェクトの評価は、プロジェクトにおける失敗確率若しくは危険度又はそれらの組合せに基づく評価であり、前記プロジェクト評価結果データは、前記失敗確率及び前記危険度を定量化したデータであると良い。

本発明のプロジェクト管理装置は、プロジェクトの状況を視覚を通じて客観的に評価できる。その際、必要に応じてプロジェクトの状況を常に見ることができ、問題に対して評価方法を適宜設計変更することにより素早く対応できる。

以下、本発明のプロジェクト管理装置を実施するための最良の形態を説明する。説明の際には本明細書と同時に添付する図面を参照することにする。

図１に本形態で取り扱うプロジェクト管理装置ＰＭをネットワークに接続したときのシステム全体の構成ブロック図を示す。このシステムにはプロジェクト管理装置ＰＭの他に種々の端末が接続している。各種端末は所定の入力手段、表示手段を備えているものとする。以下、図１を参照してプロジェクト管理装置等に関する説明をする。

本システムを利用して複数のプロジェクトＡ、Ｂ、Ｃ、…が実行されていく。端末Ａ１、Ａ２、…はプロジェクトＡに携わる開発者がそのソフトウェア開発を行うときに使用する端末である。同様に端末Ｂ１、Ｂ２、…はプロジェクトＢに携わる開発者が、端末Ｃ１、Ｃ２、…はプロジェクトＣに携わる開発者が使用する端末である。端末Ａ１、Ｂ１等から各プロジェクトにおける成果物としてのデータやその成果物に付随したプロジェクト管理に必須な種々のデータがプロジェクト管理装置ＰＭにインプットデータとして送信される。インプットデータの代表的なものとしては、要求仕様書、設計仕様書、リスク、ソースコード量、アウトプット品質、テスト消化数、ソフトウェア欠陥発見数、メンバのスキル、工数、コスト、納期などが挙げられる。

プロジェクト管理装置ＰＭは、プロジェクト管理指標データベースＤＢ１、プロジェクト評価結果データベースＤＢ２、プロジェクト管理指標生成手段１、プロジェクト評価結果生成手段、データ可視化手段３及び経時変更手段４を有して構成されている。

プロジェクト管理指標生成手段１は端末Ａ１、Ｂ１、…より受信したインプットデータを基にしてインプットデータの種類に応じたプロジェクト管理指標に係るデータ（以下「プロジェクト管理指標データ」という。）を生成する。プロジェクト評価結果生成手段２は生成されたプロジェクト管理指標データに基づいて対象となるプロジェクトの評価を行い、その評価に対する結果に係るデータ（以下「プロジェクト評価結果データ」という。）を生成する。プロジェクトの評価対象としては、プロジェクトの失敗確率やプロジェクトの危険度などが挙げられる。

データ可視化手段３はプロジェクト管理指標データまたはプロジェクト評価結果データを視覚を通じて表示しうる形式に処理する。つまり、プロジェクト管理指標データまたはプロジェクト評価結果データに基づいたプロジェクト管理指標またはプロジェクト評価結果の内容をシステムに接続されている端末の表示手段にグラフ、表、チャートなどとして視覚を通じて表示しうるものに加工する。

経時変更手段４はプロジェクトの進捗状況に応じて種々のインプットデータを構成するパラメータを設計変更する。パラメータを設計変更したインプットデータはプロジェクト管理指標生成手段１に送信される。ここでいうパラメータの設計変更とは、インプットデータを構成するパラメータの種類、数、重み付けの割り振り、その他のプロジェクト進捗状況をトレンドに追従するように精度良く表現しうる変更をいう。

プロジェクト管理指標データベースＤＢ１は、プロジェクト管理指標生成手段１により生成されたプロジェクト管理指標データを格納する。プロジェクト評価結果データベースＤＢ２は、プロジェクト評価結果生成手段２により生成されたプロジェクト評価結果データを格納する。双方のデータベースに格納するプロジェクト管理指標データまたはプロジェクト評価結果データには、データ可視化手段３により加工されたもの、経時変更手段４により設計変更されたものも含まれる。

端末ＭＡ、ＭＢ、ＭＣ、…はそれぞれプロジェクトＡ、Ｂ、Ｃ、…におけるプロジェクトマネージャが使用する端末である。また端末ＧＭはプロジェクトＡ、Ｂ、Ｃ、…といった複数のプロジェクトを管理する上級プロジェクトマネージャが使用する端末である。端末ＭＡ、ＭＢ、ＭＣ、…及び端末ＧＭは所定の入力を行い、プロジェクト管理装置ＰＭにアクセスすることにより、プロジェクト管理指標データベースＤＢ１またはプロジェクト評価結果データベースＤＢ２に格納された各種データを読み出す。読み出したデータ対し自身の端末の表示手段にプロジェクト管理指標、プロジェクト評価結果を表示する。各プロジェクトマネージャはそれらの表示内容から自身のプロジェクトの現状把握と意志決定を行っていく。

次にプロジェクト管理装置ＰＭに入力されるインプットデータに応じて処理されるプロジェクト管理装置ＰＭの処理動作をインプットデータの種類に応じて具体的に説明する。

インプットデータがプロジェクトのリスクに係るデータである場合には、プロジェクト管理装置ＰＭの図２に記載したフローチャートのように処理していく。

まず各プロジェクトにおける端末よりリスクに係るデータがインプットデータとして入力される（Ｓ１）。リスクとして採りあげる内容はプロジェクトに応じて設定すればよい任意的なものである。次に、プロジェクト管理指標生成手段１が入力されたリスクに係るデータより、リスクに係るプロジェクト管理指標データを生成する（Ｓ２）。そのデータのプロジェクト管理指標はプロジェクトで発生する発生可能性及びプロジェクトに与える影響度をプロジェクトのリスクのパラメータとしている。次にそのデータに係るプロジェクト管理指標を基にして、発生可能性・影響度といったパラメータを視点とした優先順位を決定し、リスクの重要度を定量化する（Ｓ３）。定量化する際にはデータ可視化手段３の機能により、リスクに係るプロジェクト管理指標のリスト一覧データを作成する。作成したリスト一覧の一例を図３に記載しておく。

図３のリスト一覧の項目について説明する。「順位」はリスクをその重要度の高いものから並べた順位付けになっている。「カテゴリ」はリスクの種類を表わし、例えば「技術」、「開発体制」、「開発環境」、「個人スキル」などがある。「リスク」はリスクの内容とその原因となるものを記述する。「発生可能性」はリスクが顕在化する可能性を表わし、例えば、Ａ、Ｂ、Ｃの三段階で評価する。「影響度」はリスクが顕在化したときのプロジェクトへの影響度を表わし、例えば、Ａ、Ｂ、Ｃの三段階で評価する。「対策」はリスクを回避、軽減、転化するための現状の施策を表わしている。

リスク重要度は「影響度」や「発生可能性」によって算出される。算出方法は、両パラメータの乗算値でも良いし、両パラメータの加算値でも良いし、各パラメータに重み付けをしそこから算出された値でも良い。これ以外のパラメータがあればそれを取り入れて、算出するようにしても良い。以上によりリスクの重要度を算出し、優先順位付けを行なう。

以上の処理により定量化したデータを端末ＭＡ、ＭＢ等に送信し、その表示手段に表示させる（Ｓ４）。このように可視化したデータを表示することによって、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況を定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。

このようなリスクの一覧表示において、「影響度」の項目においてさらに「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」といったパラメータを設けることによりリスクの定量化の精度を上げることができる。図４には「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」の項目を設けたリスクに係るプロジェクト管理指標のリスト一覧が記載されている。各項目をＡ、Ｂ、Ｃの三段階で評価する。これらの影響度と発生可能性から、ある一定の算出式でリスクを評価する。

例えば、ランクＡのリスクを５点、ランクＢのリスクを３点、ランクＣのリスクを１点の配点とし、「品質」、「コスト」、「納期」に対する配点の加算値と、「発生可能性」の配点との乗算値をリスクの評価点とする。つまり、「評価点＝（品質＋コスト＋納期）×発生可能性」である。

このようにすると、リスクＸＸＸの評価点は（５＋３＋３）×５＝５５点となる。他のリスクも同じ算出式によって評価点を出し、評価点の大きいものから順位付けする。評価点の大きいものが重大なリスクであり、大きくプロジェクトに影響を与えるものになる。

リスクの評価点の合計をプロジェクト全体が抱えるリスクの大きさとして定量的に見ることもできる。また、重要なリスクだけに注目するならば、リスク評価点のトップ１０のみを加算したものを指標として定量的に見ることもできる。評価点の算出式はプロジェクトの大きさや性質、扱うドメインによって変わる可能性がある。

このように可視化したデータを表示することによって、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況をより定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。

さらにリスクの一覧表示の「影響度」に対し、細分化した「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」それぞれにおいて、経時変更手段４がその重み付けをプロジェクトの時間的推移に応じて変えていく。図５にはプロジェクトの開始時から終了時までの「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」の重み付けの時間的推移を表したグラフが記載されている。図５に示すように、プロジェクトの開始時では品質面の早期構築を行なわなければならないので、「品質」に重きを置いたリスク評価を行なう。プロジェクトの中盤から後半にかけては、「品質」よりも「納期」が重要な項目となってくるので、「納期」の割合を増やす。

例えば、図６に示すような重み付けとした場合、プロジェクト前半では、図７のリスクに係るプロジェクト管理指標のリスト一覧に示すように
リスクＸＸＸの評価点 = (5×0.8+3×0.1+3×0.1)×5 = 23
リスクＹＹＹの評価点 = (1×0.8+3×0.1+5×0.1)×5 = 8
となる。

またプロジェクト後半では、図８のリスクに係るプロジェクト管理指標のリスト一覧に示すように
リスクＸＸＸの評価点 = (5×0.2+3×0.2+3×0.6)×5 = 17
リスクＹＹＹの評価点 = (1×0.2+3×0.2+5×0.6)×5 = 19
となる。

このようにプロジェクトの時間的推移とともにリスク影響度を変化させることにより、時期に応じて正しくリスク影響度が評価できることになる。いわば、トレンドに追従した評価が可能となる。

一方、インプットデータが一のプロジェクトで使用されるソースコード量に係るデータである場合には、計画レベルで使用されると予想するソースコード量と実績レベルで使用したソースコード量に係るデータを使用して、プロジェクト管理指標生成手段１は双方のソースコード量の差分をプロジェクト管理指標としたプロジェクト管理指標データを生成する。

反復型のソフトウェア開発においては、プロジェクト前半で使用されるソースコード量は緩やかに増えるが、プロジェクト後半になると大幅に使用されることが予想される。計画レベルのソースコード量は、このような予想の他に過去の実績や機能数などから見積もることができる。

実績レベルのソースコード量は、常時計測するか一定間隔でチェックポイントを設け、各チェックポイントで計測するようにしても良い。チェックポイントは何らかのマイルストーンでも良いし、反復型のソフトウェア開発におけるイテレーションの終了時としても良い。ソースコードが何らかのリポジトリで管理されている場合は、リポジトリのソースコードに対して計測することにより、アンコンシャスにソースコード量の常時計測が可能となる。

データ可視化手段３は、プロジェクト管理指標データを基にして計画レベルのソースコード量と実績レベルのソースコード量の時間的推移をグラフ化したデータを生成する。生成したグラフを図９に示す。時間軸中の「Ａ」、「Ｂ」はチェックポイントに相当する。Ａ時点では計画レベルのソースコードに対して実績レベルのソースコードが上回っているので、プロジェクトとしては進んでいることになる。Ｂ時点では計画レベルのソースコードに対して実績レベルのソースコードが下回っているので、プロジェクトとしては遅れていることになる。

このようにソースコード量を可視化することによって、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況を定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。経時変更手段４の機能により、プロジェクトの進捗状況に応じて、計画レベルのソースコード量やチェックポイントの位置を適宜変更することによりプロジェクト管理指標における差分を精度良く表すことも可能である。

インプットデータが一のプロジェクトで使用されるソースコードの品質に係るデータである場合には、所定の評価項目を設けて各項目毎において品質を特定する。プロジェクト管理指標生成手段１はソースコードの関数単位または全体でのプロジェクト管理指標データを生成する。

ソースコードの品質の計測には大きく２種類ある。一つはツール等を使用した客観的評価での品質測定、もう一つはインスペクション等の主観的評価による品質測定である。データ可視化手段３は客観的・主観的評価に基づくプロジェクト管理指標のリスト一覧を生成する。プロジェクト管理指標生成手段１は双方の評価または両方を組み合わせた評価に基づくソースコードの品質に係るプロジェクト管理指標データを生成する。

客観的評価は、例えば図１０のリスト一覧に示すような項目でソースコードの構造に応じて客観的な数値が測定できる。この例では全ての関数を対象に、客観的評価項目とその基準値として、「ソフトウェアの複雑さ」が７以下、「カバレッジ率」が90%以上、「ネストの深さ」が5以下、「コード行数」が100以下を挙げている。

func1()はコード行数が100以下でないため、品質が悪いと評価される。func2()、func3()は両方とも基準値を満たしているため、品質が良いと評価される。func4()はソフトウェアの複雑さが7以下でないため、品質が悪いと評価される。ここでは、良い、悪いの2段階評価の例を示したが、基準となる数値を区切り、数段階で評価することも可能である。

主観的評価は、インスペクタが主観で評価するか欠陥を発見するためのチェックシートを使用して評価する。ある程度定量的に測定するためには、チェックシート等で、機械的に測定できるような方法を取る。図１１にインスペクションチェックシートの例を示す。この例では、func3()、func4()にチェック項目を満たさない項目があるので、これらは品質が悪いと評価される。func1()、func2()は品質が良いと評価される。

このようにソースコードの品質を可視化することによって、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況を定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。

インプットデータが一のプロジェクトでなされるテストのテスト消化率に係るデータである場合には、計画レベルでなされると予想されるテストのテスト消化率と実績レベルでなされたテストのテスト消化率を使用して、プロジェクト管理指標生成手段１は双方のテスト消化率の差分をプロジェクト管理指標としたプロジェクト管理指標データを生成する。

反復型のソフトウェア開発においては、プロジェクト前半でなされるテストは緩やかに増えるが、プロジェクト後半になると大幅にテストがなされることが予想される。計画レベルのテスト消化率は、このような予想の他に過去の実績、機能数、品質保証値などから見積もることができる。

実績レベルのテスト消化率は、常時計測するか一定間隔でチェックポイントを設け、各チェックポイントで計測するようにしても良い。チェックポイントは何らかのマイルストーンでも良いし、反復型のソフトウェア開発におけるイテレーションの終了時としても良い。テストの実績が何らかのリポジトリで管理されている場合は、リポジトリのテストの実績に対して計測することにより、アンコンシャスにソースコード量の常時計測が可能となる。

データ可視化手段３は、プロジェクト管理指標データを基にして計画レベルのテスト消化率と実績レベルのテスト消化率の時間的推移をグラフ化したデータを生成する。生成したグラフを図１２に示す。時間軸中の「Ａ」、「Ｂ」はチェックポイントに相当する。Ａ時点では計画レベルのテスト消化率に対して実績レベルのテスト消化率が下回っているので、プロジェクトとしては遅れていることになる。Ｂ時点では計画レベルのテスト消化率に対して実績レベルのテスト消化率が上回っているので、プロジェクトとしては進んでいることになる。

このようにテスト消化率を可視化することによって、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況を定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。経時変更手段４の機能により、プロジェクトの進捗状況に応じて、計画レベルのテスト消化率やチェックポイントの位置を適宜変更することによりプロジェクト管理指標における差分を精度良く表すことも可能である。

インプットデータが一のプロジェクトでなされるソフトウェアの欠陥発見件数に係るデータである場合には、実績レベルで生じたソフトウェアの欠陥発見件数を利用してプロジェクト管理指標生成手段１はその増加傾向をプロジェクト管理指標としたプロジェクト管理指標データを生成する。

反復型のソフトウェア開発においては、プロジェクト前半でなされるテストは急激に増えるが、プロジェクト後半になると緩やかに増えていくことが予想される。

実績レベルの欠陥発見件数は、常時計測するか一定間隔でチェックポイントを設け、各チェックポイントで計測するようにしても良い。チェックポイントは何らかのマイルストーンでも良いし、反復型のソフトウェア開発におけるイテレーションの終了時としても良い。欠陥発見件数が何らかのリポジトリで管理されている場合は、リポジトリの欠陥発見件数を計測することにより、アンコンシャスに欠陥発見件数の常時計測が可能となる。

データ可視化手段３は、プロジェクト管理指標データを基にしてソフトウェアの欠陥発見件数の時間的推移をグラフ化したデータを生成する。生成したグラフを図１３に示す。時間軸中の「Ａ」、「Ｂ」はチェックポイントに相当する。Ａ時点では欠陥発見件数の増加傾向が急激であるため、プロジェクトとしてはまだ初期段階であることがわかる。Ｂ時点では増加傾向が緩やかであるため、プロジェクトの後半に差し掛かっていることが分かる。このような指標が得られている場合は問題ないが、プロジェクトの後半で欠陥発見件数が変わらず増加しているようであれば、プロジェクトが正常に進んでいない可能性がある。

このように欠陥発見件数を可視化することによって、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況を定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。

インプットデータが一のプロジェクトに携わるメンバのスキルに係るデータである場合には、計画レベルで向上すると予想されるメンバのスキルと実績レベルで向上したメンバのスキルを使用して、プロジェクト管理指標生成手段１は双方のメンバのスキルの差分をプロジェクト管理指標としたプロジェクト管理指標データを生成する。

反復型のソフトウェア開発において、データ可視化手段３は、プロジェクト管理指標データを基にして計画レベルのメンバのスキルと実績レベルのメンバのスキルの一覧表にしたデータを生成する。図１４には、その一覧表をスキルレベルに応じて記載している。各反復でのスキルレベル該当人数を「スキルレベル（計画）」のように予定する。この表ではスキルレベル１からスキルレベル４に対して、技術的な難易度に応じた要件を定義している。

例えば、反復４では、「オブジェクト指向による開発ができる」メンバが２人になると予測している。これに対して、実績レベルでのスキルレベル該当人数は３人であり、プロジェクトの好調さが窺える。そして、その人数の差異をプロジェクト管理指標とする。

このようにメンバのスキルの計画と実績の差異を可視化することによって、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況を定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。

以上で説明した各種のプロジェクト管理指標を一部または全部を使用して、プロジェクト評価結果生成手段２がプロジェクト評価結果データを生成してプロジェクトの評価を行う。この評価を「失敗確率」、「危険度」をパラメータとして定量的に行う。「危険度」に関してはさらに「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」といったパラメータを設けることにより危険度の定量化の精度を上げる。

「失敗確率」は、このままの状態でプロジェクトを進めた場合に「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」が守られない確率を表す。プロジェクトによっては、これ以外の指標も決定的要素になりうる場合があるので、プロジェクトに合わせて失敗の基準を設けても良い。

「危険度」は、「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」にどれだけの影響を及ぼすかを表す。表示形式としては例えば、以下のような５段階で評価する。
Ａ：項目に対して必ず大きな影響が出る
Ｂ：項目に対して大きな影響が出る可能性がある
Ｃ：項目に対して必ず小さな影響が出る
Ｄ：項目に対して小さな影響が出る可能性がある
Ｅ：現状では影響なし

定量的に行う際には、データ可視化手段３の機能により、プロジェクト評価のリスト一覧データを作成する。作成したリスト一覧の一例を図１５に記載しておく。その際、経時変更手段４の機能により、「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」の重み付けをプロジェクトの時間的推移に応じて変えていくこともできる。このように可視化したデータを端末ＭＡ、ＭＢ等に表示させることにより、プロジェクトマネージャおよび上級マネージャがプロジェクトの状況を定量的に把握することができるようになる。

なお、上述した形態は本発明を実施するための最良の形態であるがこれに限定する主旨ではない。従って、本発明の要旨を変更しない範囲において種々変形することが可能である。例えば、上記形態で取り扱ったプロジェクトは複数であったが、単体のプロジェクトに対しても適用することができる。また、プロジェクトの評価を「失敗確率」、「危険度」で定量的に表わす例を示したが、もちろん他の方法で定量的な評価を行なっても良い。

また、プロジェクト管理装置ＰＭに入力されるインプットデータはアンコンシャスに入力されるものが良い。例えば、リスクの一覧が更新された場合にそのデータがプロジェクト管理装置ＰＭに入力されるような仕組みとする。ソフトウェアの欠陥数を管理するデータベースがあるなら、それとリンクすることでアンコンシャスにデータが入力されるような仕組みを作る。このような仕組みにより、プロジェクトマネージャがプロジェクトのトレンドを常に把握することができる。

プロジェクト管理ツール・プロジェクト管理の仕組み・プロジェクトオフィス・プロジェクトマネジメント支援・プロジェクトマネジメント教育・プロジェクトのコンサルティング業務その他の事業において、本発明のプロジェクト管理装置を適用しうる。この装置には様々なデータやナレッジが蓄積されていくため、各事業に跨った利用性も見込める。

プロジェクト管理装置ＰＭをネットワークに接続したときのシステム全体の構成ブロック図である。 リスクに係るデータが入力された場合のプロジェクト管理装置ＰＭに関する動作処理を表すフローチャートである。 リスクに係るプロジェクト管理指標のリスト一覧の一例である。 リスクに係るプロジェクト管理指標のリスト一覧の一例である。 プロジェクトの開始時から終了時までの「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」の重み付けの時間的推移を表したグラフである。 「品質（Ｑ）」、「コスト（Ｃ）」、「納期（Ｄ）」の重み付けの一例を表した表である。 リスクに係るプロジェクト管理指標のリスト一覧の一例である。 リスクに係るプロジェクト管理指標のリスト一覧の一例である。 計画レベルのソースコード量と実績レベルのソースコード量の時間的推移を表したグラフである。 客観的評価によるソースコードの品質に係るプロジェクト管理指標のリスト一覧の一例である。 主観的評価によるソースコードの品質に係るプロジェクト管理指標のリスト一覧の一例である。 テスト消化率の時間的推移を表したグラフである。 ソフトウェアの欠陥発見件数の時間的推移を表したグラフである。 メンバのスキルに係るプロジェクト管理指標のリスト一覧の一例である。 プロジェクト評価のリスト一覧の一例である。

符号の説明

Ａ１、Ａ２、… 端末
Ｂ１、Ｂ２、… 端末
Ｃ１、Ｃ２、… 端末
ＭＡ、ＭＢ、… 端末
ＧＭ 端末
ＰＭ プロジェクト管理装置
ＤＢ１ プロジェクト管理指標データベース
ＤＢ２ プロジェクト評価結果データベース
１ プロジェクト管理指標生成手段
２ プロジェクト評価結果生成手段
３ データ可視化手段
４ 経時変更手段

Claims (9)

1. プロジェクトにおける端末より受信したインプットデータに基づいて管理すべきプロジェクトの状況の一側面を表す指標であるプロジェクト管理指標があって、前記プロジェクト管理指標に基づいてプロジェクトの評価を行い、プロジェクトマネージャ側の端末に対して該評価に関する一連のデータを送信するプロジェクト管理装置において、
   前記プロジェクト管理指標に係るデータであるプロジェクト管理指標データを生成するプロジェクト管理指標生成手段と、
   前記プロジェクト管理指標データを可視化するデータ可視化手段を有することを特徴とするプロジェクト管理装置。
2. プロジェクトの進捗状況に応じて種々の前記インプットデータを構成するパラメータを設計変更する経時変更手段を有することを特徴とする請求項１に記載のプロジェクト管理装置。
3. 前記プロジェクト管理指標は、プロジェクトおけるリスクの重要度であり、
   前記プロジェクト管理指標データは、前記リスクの重要度を定量化したデータであることを特徴とする請求項１または２に記載のプロジェクト管理装置。
4. 前記リスクの重要度の定量化において、前記リスクの発生可能性及び前記リスクの影響度の双方を定量化し、定量化された前記リスクの発生可能性及び前記リスクの影響度の双方に基づいて順位付けされたプロジェクト管理指標データが生成されることを特徴とする請求項３に記載のプロジェクト管理装置。
5. 前記インプットデータを構成するパラメータの一部である品質、コスト、納期に基づいて、前記リスクの影響度を定量化したプロジェクト管理指標データが生成されることを特徴とする請求項４に記載のプロジェクト管理装置。
6. 前記経時変更手段は、品質、コスト、納期に係る前記パラメータに対し、時間的推移に応じた重み付けの変更を行うことを特徴とする請求項５に記載のプロジェクト管理装置。
7. 前記インプットデータは、プロジェクトにおけるソースコード量、ソースコードの品質、テスト消化数、ソフトウェア欠陥発見数、メンバのスキルの何れかであり、
   前記プロジェクト管理指標は、ソースコード量、ソースコードの品質、テスト消化数、ソフトウェア欠陥発見数、メンバのスキルに係る所定の基準値と、プロジェクトの実績として表されるソースコード量、ソースコードの品質、テスト消化数、ソフトウェア欠陥発見数、メンバのスキルに係る値を各々比較した比較結果であり、
   前記プロジェクト管理指標データは、前記比較結果を定量化したデータであることを特徴とする請求項１または２に記載のプロジェクト管理装置。
8. 前記プロジェクト管理指標データに基づいて対象となるプロジェクトの評価を行い、その評価に対する結果に係るデータであるプロジェクト評価結果データを生成するプロジェクト評価結果生成手段を有することを特徴とする請求項１から７記載のプロジェクト管理装置。
9. 前記プロジェクトの評価は、プロジェクトにおける失敗確率若しくは危険度又はそれらの組合せに基づく評価であり、
   前記プロジェクト評価結果データは、前記失敗確率及び前記危険度を定量化したデータであることを特徴とする請求項８に記載のプロジェクト管理装置。

Images