JP2006260112A - プロジェクト管理システム、プロジェクト管理方法、プログラム及び記憶媒体 - Google Patents

Abstract

【課題】 プロジェクトの状況を客観的に評価できるプロジェクト管理システムを提供する。特に、リスクが高まった項目を視覚化できるようにして、意思決定の手遅れを防ぐことができるようにする。
【解決手段】 プロジェクト管理システム１内の管理指標管理部２が各プロジェクトの各プロセスで出てくる成果物など管理データを随時取得し、プロジェクト管理部３が、指定されたプロジェクトで発生する可能性のあるリスクを、発生した場合の影響度と発生可能性の度合いから定量化して順位を付け、順位が高まったリスクを抽出してそのリスクの可視化情報を作成し、その可視化情報をプロジェクト管理者側装置へ送信する構成にした。
【選択図】 図２

Description

本発明は、パーソナルコンピュータなど情報処理装置上に実現できる、コンピュータプログラムを生産（開発）するプロジェクトにおけるプロジェクト管理システムに係り、特に、リスクなどを管理するプロジェクト管理技術に関する。

近年、各種製品における機能の増加によってソフトウェア（コンピュータプログラム）規模が増大するとともに、製品を素早く世の中に出すために開発期間の短縮が求められている。このような傾向により、ソフトウェア開発者のスキルや生産性だけでなく、プロジェクト管理の方法によってもプロジェクトの成否が決定する時代になってきている。例えば、プロジェクトにおける開発状況を正確に把握し、素早く対応するようなプロジェクトの進め方が必要になってきているのである。また、プロジェクト管理の手法も個人のスキルに委ねるのではなく、一元化、効率化することが必要になってきている。
プロジェクト管理の指標としては、スケジューリング、コスト、ソフトウェア品質、人的スキル、リスク管理などが挙げられ、これらをいかにうまく管理していくのかが重要である。それに対して、一般に市販されているプロジェクト管理ツールでは、スケジュールに対する差異分析、プロジェクトマネージャの主観による段階的評価などにとどまっており、プロジェクトをいろいろな側面から、客観的に評価するようなものはまだ存在しない。プロジェクトマネージャも、プロジェクトのどこに問題があるのかを客観的に見られる指標がなく、過去のプロジェクトで得られた勘と経験に基づいて管理を行なっている。同様に、上級マネージャがプロジェクトの状況を正確に且つ客観的に把握できる手段もなかった。
このような背景から、特許文献１に示された従来技術では、上級マネージャが管理下のプロジェクトの評価結果を評価点として点数化し、プロジェクト自体の評価を行う技術が示されている。
また、特許文献２に示された従来技術では、アウトプット文書を視覚的に管理することによって進捗管理を行う技術が示されている。具体的には、プロジェクトの遂行時に参照される参照文献と作成されるアウトプット文書を管理する文書管理データベースと、プロジェクトの計画時に、プロジェクトの各工程で作成すべき前記アウトプット文書の空の実体を前記文書管理データベースへ登録し、この登録した空の実体および前記参照文書へのリンク情報を前記工程と関連づけて登録し、プロジェクトの進捗状況を管理するプロジェクト情報管理データベースとを備えている。そして、前記工程ごとに、工程名と、その工程のスケジュールの長さに合わせたタイトルバーおよびその工程の進捗状況を表す進捗バーとを対応づけて表示させ、前記工程の要員とその要員が担当する進捗状況を視覚的に把握できるようにしている。
特開２００３−１９６４４７公報 特開２００３−１４１３２０公報

しかしながら、前記特許文献１に示された従来技術では、決められたチェックリストに対してプロジェクトマネージャが評価する方法を採用しており、進捗状況の評価がプロジェクトマネージャの主観による評価であるとか、トレンドに追従することができないとか、欲しいときに欲しい情報を得ることができないといった問題がある。
また、特許文献２に示された従来技術では、視覚化の対象がアウトプット文書に限られている。
本発明の目的は、このような従来技術の問題を解決しようとするものであり、具体的には、プロジェクトの状況をプロジェクトマネージャの主観によらず、客観的に評価できるプロジェクト管理システムを提供することにある。特に、リスクが高まった項目を視覚化するとともに、今後のトレンドなどを添えることで、意思決定の手遅れを防ぐことができるようにする。

前記した課題を解決するために、請求項１記載の発明では、プロジェクトで発生する可能性のあるリスクを、発生した場合の影響度と発生可能性の度合いから定量化して順位を付けることにより、リスクを監視するリスク監視手段を備えたプロジェクト管理システムにおいて、前記順位が高まったリスクを抽出してそのリスク情報を可視化する可視化手段を備えた。
また、請求項２記載の発明では、請求項１記載の発明において、前記順位が高まったリスクのリスク情報をプロジェクト管理者側装置へ通知するリスク通知手段を備えた。
また、請求項３記載の発明では、請求項１または請求項２記載の発明において、前記リスク情報として、順位がどれくらい高まったか、順位が高まった要因、及び／又は今後のトレンドを可視化する構成にした。
また、請求項４記載の発明では、請求項１または請求項２記載の発明において、前記発生した場合の影響度を、品質に与える影響、コストに与える影響、及び／又は納期に与える影響という視点から評価して求める構成にした。
また、請求項５記載の発明では、請求項４記載の発明において、前記品質に与える影響、コストに与える影響、および納期に与える影響のそれぞれに重み付けをして前記影響度を求める構成にした。
また、請求項６記載の発明では、請求項５記載の発明において、前記重み付けの値をプロジェクトの時間的推移に応じて変化させる構成にした。
また、請求項７記載の発明では、プロジェクトで作成されたコンピュータプログラムのソースコード量の実績値を取得することによりその実績値の計画値との作成量差分を可視化する作成量差分可視化手段を備えたプロジェクト管理システムにおいて、前記作成量差分が所定量以上拡大したコンピュータプログラムについて前記作成量差分の拡大状況を示す作成量差分情報を可視化するように前記作成量差分可視化手段を構成した。
また、請求項８記載の発明では、請求項７記載の発明において、前記作成量差分情報をプロジェクト管理者側装置へ通知する作成量差分通知手段を備えた。
また、請求項９記載の発明では、請求項７または請求項８記載の発明において、前記作成量差分情報として、実績値と計画値との差分量、今後のトレンド、及び／又は作成量差分の拡大した要因の候補を可視化する構成にした。
また、請求項１０記載の発明では、プロジェクトで作成されたコンピュータプログラムのテストの消化率を取得することによりその実績値の計画値とのテスト差分を可視化するテスト差分可視化手段を備えたプロジェクト管理システムにおいて、前記テスト差分が所定量以上拡大したコンピュータプログラムについて前記テスト差分の拡大状況を示すテスト差分情報を可視化するように前記テスト差分可視化手段を構成した。

また、請求項１１記載の発明では、請求項１０記載の発明において、前記テスト差分情報をプロジェクト管理者側装置へ通知するテスト差分通知手段を備えた。
また、請求項１２記載の発明では、請求項１０または請求項１１記載の発明において、前記テスト差分情報として、実績値と計画値との差分量、今後のトレンド、及び／又はテスト差分の拡大した要因の候補を可視化する構成にした。
また、請求項１３記載の発明では、プロジェクトで作成されたコンピュータプログラムの欠陥発見件数を取得することによりその実績値の計画値との欠陥数差分を可視化する欠陥数差分可視化手段を備えたプロジェクト管理システムにおいて、前記欠陥数差分が所定量以上拡大したコンピュータプログラムについて前記欠陥数差分の拡大状況を示す欠陥数差分情報を可視化するように前記欠陥数差分可視化手段を構成した。
また、請求項１４記載の発明では、請求項１３記載の発明において、前記欠陥数差分情報をプロジェクト管理者側装置へ通知する欠陥数差分通知手段を備えた。
また、請求項１５記載の発明では、請求項１３または請求項１４記載の発明において、前記欠陥数差分情報として、実績値と計画値との差分量、今後のトレンド、及び／又は結果数差分の拡大した要因の候補を可視化する構成にした。
また、請求項１６記載の発明では、プロジェクトで発生する可能性のあるリスクを、発生した場合の影響度と発生可能性の度合いから定量化して順位を付けることにより、リスクを監視するプロジェクト管理方法において、前記順位が高まったリスクを抽出し、抽出したリスクについて可視化情報を作成し、その可視化情報をプロジェクト管理者側へ通知する構成にした。

また、請求項１７記載の発明では、プロジェクトで作成されたコンピュータプログラムのソースコード量を取得することによりその実績値の計画値との作成量差分を可視化するプロジェクト管理方法において、前記作成量差分が拡大したコンピュータプログラムについて前記作成量差分の拡大状況を示す可視化情報を作成し、その可視化情報をプロジェクト管理者側へ通知する構成にした。
また、請求項１８記載の発明では、プロジェクトで作成されたコンピュータプログラムのテストの消化率を取得することによりその実績値の計画値とのテスト差分を可視化するプロジェクト管理方法において、前記テスト差分が拡大したコンピュータプログラムについて前記テスト差分の拡大状況を示す可視化情報を作成し、その可視化情報をプロジェクト管理者側へ通知する構成にした。
また、請求項１９記載の発明では、プロジェクトで作成されたコンピュータプログラムの欠陥発見件数を取得することによりその実績値の計画値との欠陥数差分を可視化するプロジェクト管理方法において、前記欠陥数差分が拡大したコンピュータプログラムについて前記欠陥数差分の拡大状況を示す可視化情報を作成し、その可視化情報をプロジェクト管理者側へ通知する構成にした。
また、請求項２０記載の発明では、情報処理装置上で実行されるプログラムにおいて、請求項１６乃至請求項１９のいずれか１項に記載のプロジェクト管理方法のプロジェクト管理を実行させるようにプログラミングされている構成にした。
また、請求項２１記載の発明では、プログラムを記憶した記憶媒体において、請求項２０記載のプログラムを記憶した。

本発明によれば、プロジェクトで発生する可能性のあるリスクを、発生した場合の影響度と発生可能性の度合いから定量化して順位を付けることにより監視できるので、プロジェクトの状況をプロジェクトマネージャの主観によらず客観的に評価できる。また、順位が高まったリスクを抽出してそのリスク情報を可視化できるので、順位が上位でなくても放っておけば問題が大きくなるリスクが可視化され、したがって、問題に対して素早く対応できる。
また、順位がどれくらい高まったかとか、今後のトレンドを可視化できるので、早急な対応が必要か否かを正確に把握できる。また、順位の高まった要因が可視化されるので、適切で素早い対応が可能になる。

以下、図面により本発明の実施形態を詳細に説明する。但し、この実施形態に記載される構成要素、種類、組み合わせ、形状、その相対位置などは特定的な記載がない限りこの説明の範囲をそれのみに限定する主旨ではなく、単なる説明例に過ぎない。
図１は本発明のプロジェクト管理システムの一実施形態を示すパーソナルコンピュータなど情報処理装置のハードウェア構成図である。図示したように、このプロジェクト管理システムは、ハードウェアとして、プログラムに従ってこの装置全体を制御するＣＰＵ１１、そのプログラムの一部および固定データの一部を記憶しておくＲＯＭ１２、ＣＰＵ１１が実行時にワークメモリとして用いたり、ハードディスク記憶装置から読み出した前記プログラムの一部（後述する実施例の動作フローを実行するプログラムなど）および各種データを記憶したりするＲＡＭ１３、そのＲＡＭ１３に読み出すプログラムやデータを保存しておくハードディスク記憶装置（ＨＤＤ）１４、利用者がデータや指示を入力するための入力手段を制御する入力インタフェース１５、前記入力手段であるキーボード１６およびマウス１７、前記入力手段による入力の際にメッセージや選択内容を表示したり処理結果を表示したりする表示装置１８、公衆電話網や所謂インターネットなどデータ通信網を介して外部の情報処理装置などと通信する通信装置１９などを備えている。

図２は、この実施形態のプロジェクト管理システムを示す構成図である。このプロジェクト管理システム１は前記したハードウェアおよびソフトウェア（プログラム）により実現される。また、このシステムの利用者は、各プロジェクトのプロジェクトマネージャおよびメンバ、複数のプロジェクトを管理する上級マネージャなどである。例えば図２に示したように３つのプロジェクトがあった場合は、プロジェクトＡのプロジェクトマネージャとメンバ、プロジェクトＢのプロジェクトマネージャとメンバ、プロジェクトＣのプロジェクトマネージャとメンバ、それらのプロジェクトを監視する上級マネージャが対象となる。
このプロジェクト管理システム１への入力は、それぞれのプロジェクトにおける成果物や、その他成果物には表れない様々なデータである。例えば、要求仕様書、設計仕様書、リスク一覧、ソースコード量、アウトプット品質、テスト消化数、ソフトウェア欠陥発見数、メンバのスキル、工数、コストなどが挙げられる。
この例では、管理指標管理部２がプロジェクトＡ、プロジェクトＢ、プロジェクトＣのそれぞれから前記した成果物やその他様々なデータを取り入れる。また、これらの入力データの大半は利用者の操作なしに本システムに入力されるように構成している。例えば、リスク一覧が更新されたらそのデータが自動的に本プロジェクト管理システム内の管理指標管理部２に入力されるような構成であり、また、ソフトウェアの欠陥数を管理するデータベースシステムを備えた構成では、そのデータベースシステムとリンクすることにより管理対象のソフトウェアの欠陥数がデータベースシステムから本プロジェクト管理システム１の管理指標管理部２へ自動的に入力されるように構成しているのである。このような構成により、このプロジェクト管理システム１では、プロジェクトマネージャや上級マネージャがプロジェクトの状況を好きなときに把握することができる。

このプロジェクト管理システム１の管理指標管理部２およびプロジェクト評価部３はこれらの入力データから管理指標とプロジェクト評価値を生成・管理する。例えば、リスク管理指標、ソースコード完成率、テスト消化率、ソフトウェア欠陥発見数、メンバのスキル値などを生成したり、管理したりするのである。リスク管理指標とは、リスクの発生確率とか、後述するプロジェクトへの影響度などである。リスクの発生確率は例えばある時点のソースコード完成率やテスト消化率が計画値より低いほど大となるし、ソフトウェア欠陥発見数が大きいほど大となる。
また、このプロジェクト管理システム１ではプロジェクト評価部３が管理指標などを利用者に見易い形式で伝える。また、このプロジェクト評価部３はこのような管理指標をもとにプロジェクトの失敗確率や危険度などリスクを判断し、プロジェクト評価値として利用者に伝える。
これにより、プロジェクトマネージャや上級マネージャは、以上の動作によって定量化されたプロジェクトの管理指標とプロジェクト評価値を得ることができ、自プロジェクトの現状把握と意思決定に役立てることができる。また、このプロジェクト管理システム１では様々なプロジェクトのデータやナレッジが蓄積されるので、プロジェクトを跨った行政も可能となる。また、システム自体も進化していくことができる。
なお、以上の説明では、複数のプロジェクトを対象としているが、本発明は単体のプロジェクトに対しても適用できる。

以下、前記した実施形態のプロジェクト管理システム１で実施される本発明の各実施例について説明する。
［実施例１］
この実施例のプロジェクト管理システム１では、当該プロジェクトで発生する可能性のあるリスクを抽出し、発生した場合の影響度と発生可能性の度合いから定量化して順位を付け、その順位が高まったリスクの可視化情報を作成する。さらに、その可視化情報をプロジェクト管理者などへ通知する。また、その通知に際して、可視化情報（リスク通知情報）の付帯情報として、順位がどれくらい高まったか、順位が高まった要因、および今後のトレンドなども通知する。なお、この実施例では、請求項記載のリスク監視手段が管理指標管理部２およびプロジェクト評価部３により実現され、可視化手段がプロジェクト評価部３により実現され、リスク通知手段が通信装置１９により実現される。
図３にこの実施例の説明図、図４に動作フロー図を示す。以下、図３や図４などに従ってこの実施例の動作を説明する。
この実施例のプロジェクト管理システム１は、リスクの高まったリスクの可視化に際して、利用者（プロジェクトのマネージャまたはそのプロジェクトに参加しているメンバの誰か）にプロジェクト名などを指示させる（Ｓ１）。プロジェクト名はあらかじめ登録されていて、プロジェクト管理システム１はそのプロジェクト名一覧を読み出し表示させ、選択させるのである。
続いて、プロジェクト管理システム１は、指示されたプロジェクトについて、現時点におけるリスク現象（管理指標項目の値など）を取り出し（Ｓ２）、それぞれのリスク現象についてリスクをランク付けする（Ｓ３）。具体的には、プロジェクト評価部３が、管理指標管理部２により取り込まれている当該プロジェクトの管理指標のデータをそのまま用いたり計算を加えたりして得た、ソースコード完成率、テスト消化率、ソフトウェア欠陥発見数、メンバのスキル値などを当該プロジェクトに与える影響度という視点、および当該プロジェクトにおける発生可能性という視点からＡ、Ｂ、Ｃの３段階で評価するのである。なお、各リスク現象はその内容に対応づけて属するランクを登録しておく。
次に、各リスクの重要度を算出する（Ｓ４）。重要度の算出方法は、例えばランクＡは５点、Ｂは３点、Ｃは１点というように定量値化し、その定量化値を用いて２つの値の乗算値を重要度としてもよいし、両定量化値の加算値でもよいし、両定量化値に重み付けをし、そこから算出された値でもよい。影響度および発生可能性以外の視点があればそれを取り入れて、算出するようにしてもよい。
続いて、プロジェクト評価部３は重要度算出結果をもとに図５に示したようなリスク一覧を可視化情報として作成する（Ｓ５）。

図５において、「順位」とはリスクの重要度の高い（大きい）ものから並べた順位である。但し、リスク一覧の表示対象としては重要度の高まったものを挙げている。「カテゴリ」はリスクの種類を表わし、例えば技術、開発体制、開発環境、個人スキルなどがある。「リスク」は前記したリスク現象から予測されるリスク内容またはリスクの原因を表し、例えば「納期遅れの発生」というようなことを記述する。「発生可能性」はリスクが顕在化する可能性を表わし、前記したように例えばＡ、Ｂ、Ｃの３段階で表示する。「影響度」はリスクが顕在化したときのプロジェクトへの影響度を表わし、同様に例えばＡ、Ｂ、Ｃの３段階で表示する。「対策」はリスクを回避、軽減、転嫁するために現状に対して施す施策を表わす。なお、次に示すように、リスク現象・リスク・原因を対応づけてあらかじめ登録しておき、登録された対応付けを参照して対応する対策を可視化する。
・技術（非機能要件）・プロセス
現象：割り当てられるＲＯＭ容量が確定していない。
リスク：確定したＲＯＭ容量に対するオーバーフロー
原因：企画仕様が曖昧
対策：開発開始時から現状までのメモリ使用量推移から、最終使用量を自動的に予測し、企画へ提案する。
・開発体制
現象：アーキテクト（要員の１つ）の工数が増大している。
リスク：アーキテクチャ構築の遅れによる後工程の停滞
原因：アーキテクトがアーキテクチャ以外の業務をこなしている。
対策：ビルド担当者の確保、テスト担当者の増員
・スキル
現象：アウトプットされたソースコード量が少ない。
リスク：納期遅れの発生
原因：分析（要求分析・モデリング）スキル不足（プログラミングスキルではない）
対策：メンタリングの実施

なお、図５には示していないが、可視化する際、所定期間前の順位を保存しておき、そのときに比べて順位がどれくらい高まったかとか、今後のトレンドを可視化する構成も可能である。今後のトレンドについては、すでに終了している複数のプロジェクトのカテゴリごとのリスクトレンドと当該プロジェクトの当該カテゴリのリスクのこれまでの順位の推移から当該カテゴリの重要度の推移を予測し、例えばこれまでの順位の推移とこれからの順位の推移を可視化するのである。
最後に、前記した可視化内容をネットワークを介してプロジェクトマネージャおよびその上級マネージャに通知する（Ｓ６）。
こうして、この実施例によれば、各リスク対象の重要度を算出し、重要度の高まったリスクを重要度の順位などもわかるように可視化できるので、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況を主観によらず定量的に把握することができるし、問題が大きくなる前に素早く対応できる。また、プロジェクト管理システムを起動させることにより、プロジェクトの状況を見たいときに見ることができ、問題に対して素早く対応できる。
また、順位が高まったリスクのリスク情報をプロジェクト管理者側装置へ通知できるので、プロジェクト管理者が離れた場所にいてもプロジェクトの状況を定量的に把握することができる。また、順位がどれくらい高まったかとか、今後のトレンドを可視化できるので、早急な対応が必要か否かを正確に把握できる。また、順位の高まった要因が可視化されるので、適切で素早い対応が可能になる。
なお、前記においては、利用者の操作に応じて各カテゴリのリスクをランク付けし、各リスクの重要度を定量化し、重要度の高まったリスクを提示したが、管理指標の変化に伴い自動的に、他のカテゴリのリスクを表示一覧に追加したり重要度の順位を変更したりした可視化情報を作成し、プロジェクトマネージャなどへ通知する構成も可能である。重要度の増したリスクをプロジェクト管理者に知らせるメカニズムをあらわしたものが図６である。このような構成では、変化への対応が手遅れにならないで済む。

［実施例２］
この実施例では、実施例１において、リスクの影響度を品質、コスト、納期といった視点から判定する。例えば、品質に対してどれだけの影響力のあるリスクかを判断して、Ａ、Ｂ、Ｃの３段階でランク付けするのである。同様にして、コスト、納期に対しても３段階でランク付けする。これらの影響度と発生可能性から、所定の算出式でリスクの評価点を出す。例えば、ランクＡのリスクを５点、ランクＢのリスクを３点、ランクＣのリスクを１点の配点とし、下記のように品質、コスト、納期に対する配点の加算値と、発生可能性の配点との乗算値をリスクの評価点とする。
評価点＝（品質＋コスト＋納期）×発生可能性
このようにすると、図７に示したように、リスクＸＸＸの評価点は
（５＋３＋３）×５＝５５
となる。なお、各リスク現象の品質、コスト、納期に関するランクは内容に対応づけてあらかじめ登録しておく。
他のリスクも同じ算出式によって評価点を出し、評価点の大きいものから順位付けする。評価点の大きいものが重大なリスクであり、大きくプロジェクトに影響を与えるものになる。
また、各カテゴリのリスクの評価点の合計をプロジェクト全体が抱えるリスクの大きさとして定量的に見ることもできる。また、重要なリスクだけに注目するならば、例えばリスク評価点のトップ１０のみを加算したものを指標として定量的に見ることもできる。また、評価点の算出式はプロジェクトの大きさや性質、扱う問題領域（ドメイン）によって変えることも可能である。
この実施例では、前記したようにして定量値化した各リスクのうちリスクが高まったものを可視化することにより、プロジェクトマネージャおよびその上級マネージャがプロジェクトの状況を定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。また、影響度を、品質に与える影響やコストに与える影響、納期に与える影響という視点から評価して求めるので、リスク評価の精度が向上する。

［実施例３］
この実施例では、リスクの影響度に対する要因の重み付けを行う。また、この重み付けをプロジェクトの時間的推移に応じて変えていく。例えば図８に示したように、プロジェクトの開始時では品質面の早期構築を行わなければならないので、品質に重きを置いたリスク評価を行う。プロジェクトの中盤から後半にかけては、品質よりも納期が重要な項目となってくるので、納期の割り合いが増えてくる。例えば図９に示したような重み付けとした場合、プロジェクト前半では、
リスクＸＸＸの評価点＝（５×０．８＋３×０．１＋３×０．１）×５＝２３
リスクＹＹＹの評価点＝（１×０．８＋３×０．１＋５×０．１）×５＝８
となる。このリスクのリストを図１０に示す。
また、プロジェクト後半では、
リスクＸＸＸの評価点＝（５×０．２＋３×０．２＋３×０．６）×５＝１７
リスクＹＹＹの評価点＝（１×０．２＋３×０．２＋５×０．６）×５＝１９
となる。このリスクリストを図１１に示す。
なお、図１０および図１１は重み付けによって順位が変わってくることを示したものであり、表示イメージ（可視化イメージ）ではない。また、時間的推移に関係なく重み値が常に０であるようなリスク現象もある。
このように、この実施例では、リスク影響度に対する要因の重み付けを行うので、リスク影響度をより正しく評価できる。また、プロジェクトの時間的推移とともにリスク影響度に対する要因の重み付けを変化させる構成では、リスク影響度を時期に応じて正しく評価できる。

［実施例４］
この実施例では、当該プロジェクトで生産（開発）されるソフトウェア（プログラム）のソースコード量の推移を取得することにより計画との差分を可視化する。なお、この実施例では、請求項記載の作成量差分可視化手段がプロジェクト評価部３により実現され、作成量差分通知手段が通信装置１９により実現される。
図１２に、この実施例の動作フローを示す。以下、図１２などに従ってこの実施例の動作を説明する。
まず、管理指標管理部２が、プロジェクト計画時に見積られた、開発（生産）予定の各ソフトウェアのソースコード量のトレンドをデータベースシステムなどから取得する（Ｓ１１）。一般に良く知られている反復型開発の例では、図１３に示したようにプロジェクト開始当初からソースコード量が増え、またプロジェクト後半になると大幅に増えていくことが予想される。計画時のソースコード量は、過去の実績や機能数などから見積もることができる。
次に、管理指標管理部２は、生産された各ソフトウェアの実績レベルのソースコード量を各チェックポイントで、または常時、データベースシステムなどから取得する（Ｓ１２）。チェックポイントは何からのマイルストーンでもよいし、反復型開発では反復（イテレーション）の終了時としてもよい。生産されたソースコード量が何らかのリポジトリ（データベース的な記憶・管理手段）で管理されている場合は、リポジトリのソースコード量を参照することにより、無意識的に常時ソースコード量の取得が可能となる。
このように実績レベルのソースコード量が取得されると、続いて、プロジェクト評価部３が各ソフトウェアの計画値と実績値との差異を求め（Ｓ１３）、この差異を管理指標とする。図１３に示した例では、Ａ時点では計画に対して実績が上回っているので、プロジェクトとしては進んでいることになる。Ｂ時点では計画に対して実績が下回っているので、プロジェクトとしては遅れていることになる。

次に、プロジェクト評価部３は各ソフトウェアの差分が所定量以上拡大したか否かを判定する（Ｓ１４）。そして、所定量以上拡大したソフトウェアがあれば（Ｓ１４でＹｅｓ）、そのソフトウェアについて通知情報として現時点の差分量および図１３に示したような可視化を行うための可視化情報を作成する（Ｓ１５）。なお、図１３には示していないが、今後のトレンドや差分が拡大した要因の候補なども可視化する。今後のトレンド可視化の実現方法は実施例１と同様である。また、前記要因候補は例えば個々のリスク内容と組み合わせて実施例１と同様にあらかじめ登録しておき、この差分可視化に際しては実施例１と同様にして増大したリスク内容を抽出し、そのリスク内容に対応づけられた要因候補を可視化する。
続いて、そのような可視化情報を、登録されている当該プロジェクトのプロジェクトマネージャなどへ出す（図６参照）（Ｓ１６）。例えばネットワークを介してプロジェクトマネージャなどへ送るのである。
このように、この実施例によれば、ソースコード量の計画値と実績値との差異およびその推移を可視化すること（図１３のような図を表示すること）により、プロジェクトマネージャおよびその上級マネージャがソースコード生産に関するプロジェクトの状況を定量的に把握することができるし、リスクの重要度を知ることができる。また、可視化情報をプロジェクト管理者側装置へ通知できるので、プロジェクト管理者が離れた場所にいてもソースコード生産に関するプロジェクトの状況を定量的に把握することができる。また、今後のトレンドなどを可視化できるので、早急な対応が必要か否かを正確に把握できる。また、順位の高まった要因が可視化されるので、適切で素早い対応が可能になる。

［実施例５］
この実施例では、当該プロジェクトで生産されるソフトウェア（プログラム）のテストの消化率トレンドを取得することにより実績値と計画値との差分を可視化する。なお、この実施例では、請求項記載のテスト差分可視化手段がプロジェクト評価部３により実現され、テスト差分通知手段が通信装置１９により実現される。
図１４に、この実施例の動作フローを示す。以下、図１４などに従ってこの実施例の動作を説明する。
まず、管理指標管理部２が、プロジェクト計画時に見積られた、開発（生産）予定の各ソフトウェアのテスト消化率のトレンドをデータベースシステムなどから取得する（Ｓ２１）。一般に良く知られている反復型開発の例では、図１５に示したようにプロジェクト開始当初からテストが行われ、また、プロジェクト後半になると大幅にテストが消化されていくことが予想される。計画時のテスト消化率は、過去の実績、機能数、品質保証値などから見積ることができる。
この後、管理指標管理部２は、各ソフトウェアの実績レベルのテスト消化率を各チェックポイントで、または常時、データベースシステムなどから取得する（Ｓ２２）。チェックポイントは何からのマイルストーンでもよいし、反復型開発では反復の終了時としてもよい。テスト消化率の実績値が何らかのリポジトリで管理されている場合は、そのリポジトリのテスト消化率の実績値を参照することにより、無意識的に常時、テスト消化率の実績値を取得することが可能となる。
このように実績レベルでのテスト消化率が取得されると、続いて、プロジェクト評価部３が各ソフトウェアの計画値と実績値との差異を求め（Ｓ２３）、この差異を管理指標とする。図１５に示した例では、Ａ時点では計画に対して実績が下回っているので、プロジェクトとしては遅れていることになる。Ｂ時点では計画に対して実績が上回っているので、プロジェクトとしては進んでいることになる。

次に、プロジェクト評価部３はその差分が所定量以上拡大したソフトウェアがあるか否かを判定する（Ｓ２４）。そして、所定量以上拡大したソフトウェアがあれば（Ｓ２４でＹｅｓ）、通知情報として現時点での差分および図１５に示したような可視化を行うための可視化情報を作成し（Ｓ２５）、その可視化情報を登録されている当該プロジェクトのプロジェクトマネージャなどへ出す（図６参照）（Ｓ２６）。例えばネットワークを介してプロジェクトマネージャなどへ送るのである。
なお、図示していないが、今後のトレンド、差分拡大の要因の候補などを可視化する構成も可能である。
このように、この実施例では、テスト消化率の計画値と実績値との差異およびその推移を可視化すること（図１５のような図を表示すること）により、プロジェクトマネージャおよびその上級マネージャがテスト消化の状況を定量的に把握することができ、したがって、プロジェクトを成功に導くことができるようになる。また、可視化情報をプロジェクト管理者側装置へ通知できるので、プロジェクト管理者が離れた場所にいてもテスト消化に関するプロジェクトの状況を定量的に把握することができる。また、今後のトレンドを可視化する構成では早急な対応が必要か否かを正確に把握できる。また、差分拡大の要因の候補を可視化する構成では適切で素早い対応が可能になる。

［実施例６］
この実施例では、当該プロジェクトで生産されるソフトウェア（プログラム）の欠陥発見件数を取得してその状況を可視化する。なお、この実施例では、請求項記載の欠陥数差分可視化手段がプロジェクト評価部３により実現され、欠陥数差分通知手段が通信装置１９により実現される
テストによるソフトウェア欠陥発見件数の累積値は図１７に示したようにテスト開始当初から増えていき、プロジェクト後半になると発見数が少なくなり、曲線が平坦になっていくことが予想される。図１６に、この実施例の動作フローを示す。以下、図１６などに従ってこの実施例の動作を説明する。
まず、管理指標管理部２が、各ソフトウェアの実績レベルでの欠陥発見件数を各チェックポイントで、または常時、データベースシステムなどから取得する（Ｓ３１）。チェックポイントは何からのマイルストーンでもよいし、反復型開発では反復の終了時としてもよい。欠陥発見件数が何らかのリポジトリで管理されている場合は、リポジトリの欠陥発見件数を参照することにより、無意識的に常時欠陥発見件数の取得が可能となる。
次に、管理指標管理部２により取得された欠陥発見件数の実績を用いて、プロジェクト評価部３が各ソフトウェアの欠陥発見件数の増加傾向をチェックする（Ｓ３２）。図１７に示した例では、Ａ時点では欠陥発見件数が増加傾向であるので、プロジェクトとしてはまだ初期段階であることが分かる。Ｂ時点では増加傾向が鈍ってきているのでプロジェクトの後半に差し掛かっていることが分かる。このような実績値が得られている場合は問題ないが、例えばプロジェクトの後半で欠陥発見件数が相変わらず増加しているようであれば、プロジェクトが正常に進んでいない可能性がある。
そのため、プロジェクト評価部３は実施例４と同様にして各ソフトウェアの欠陥発見数の計画値を取得し、各ソフトウェアの欠陥発見数実績値の増加傾向が計画どおりか否かを判定する（Ｓ３３）。そして、増加傾向が計画値以上拡大したソフトウェアがあれば（Ｓ３３でＹｅｓ）、そのソフトウェアについて通知情報として現時点での計画値との差分量および図１７に示したような可視化情報を作成し（Ｓ３４）、その可視化情報を登録されている当該プロジェクトのプロジェクトマネージャなどへ出す（図６参照）（Ｓ３５）。例えばネットワークを介してプロジェクトマネージャなどへ送るのである。なお、今後のトレンド、差分拡大の要因の候補なども可視化する構成も可能である。

このように、この実施例では、欠陥発見件数推移や現時点における計画値との差分量を可視化することにより、プロジェクトマネージャおよびその上級マネージャが生産されたソフトウェアの欠陥発見件数の状況を定量的に把握することができるようになり、プロジェクトを成功に導くことができるようになる。また、可視化情報をプロジェクト管理者側装置へ通知できるので、プロジェクト管理者が離れた場所にいてもソフトウェアの欠陥発見件数に関するプロジェクトの状況を定量的に把握することができる。また、今後のトレンドを可視化できるので、早急な対応が必要か否かを正確に把握できる。また、差分拡大の要因の候補が可視化されるので、適切で素早い対応が可能になる。
以上、本発明の実施例を一実施形態について説明したが、説明したようなプロジェクト管理方法に従ってプログラミングしたプログラムを着脱可能な記憶媒体に記憶し、その記憶媒体をこれまで本発明によったプロジェクト管理を行なえなかったパーソナルコンピュータなど情報処理装置に装着することにより、または、そのようなプログラムをネットワーク経由でそのような情報処理装置へ転送することにより、そのような情報処理装置においても本発明によったプロジェクト管理を行なうことができる。

本発明の一実施形態を示すプロジェクト管理システムを構成する情報処理装置のハードウェア構成図。 本発明の一実施形態を示すプロジェクト管理システムの構成ブロック図。 本発明の第１の実施例を示すプロジェクト管理システムの説明図。 本発明の第１の実施例を示すプロジェクト管理システムの動作フロー図。 本発明の第１の実施例を示す、プロジェクト管理システムの表示図。 本発明の第１の実施例を示すプロジェクト管理システムの他の説明図。 本発明の第２の実施例を示すプロジェクト管理システムの表示図。 本発明の第３の実施例を示すプロジェクト管理システムの説明図。 本発明の第３の実施例を示すプロジェクト管理システムの他の説明図。 本発明の第３の実施例を示すプロジェクト管理システムの他の説明図。 本発明の第３の実施例を示すプロジェクト管理システムの他の説明図。 本発明の第４の実施例を示すプロジェクト管理システムの動作フロー図。 本発明の第４の実施例を示すプロジェクト管理システムの表示図。 本発明の第５の実施例を示すプロジェクト管理システムの動作フロー図。 本発明の第５の実施例を示すプロジェクト管理システムの表示図である。 本発明の第６の実施例を示すプロジェクト管理システムの動作フロー図。 本発明の第６の実施例を示すプロジェクト管理システムの表示図。

符号の説明

１ プロジェクト管理システム、２ 管理指標管理部、３ プロジェクト評価部、１１ ＣＰＵ、１８ 表示装置、１９ 通信装置

Claims (21)

1. プロジェクトで発生する可能性のあるリスクを、発生した場合の影響度と発生可能性の度合いから定量化して順位を付けることにより、リスクを監視するリスク監視手段を備えたプロジェクト管理システムにおいて、前記順位が高まったリスクを抽出してそのリスク情報を可視化する可視化手段を備えたことを特徴とするプロジェクト管理システム。
2. 請求項１記載のプロジェクト管理システムにおいて、前記順位が高まったリスクのリスク情報をプロジェクト管理者側装置へ通知するリスク通知手段を備えたことを特徴とするプロジェクト管理システム。
3. 請求項１または請求項２記載のプロジェクト管理システムにおいて、前記リスク情報として、順位がどれくらい高まったか、順位が高まった要因、及び／又は今後のトレンドを可視化する構成にしたことを特徴とするプロジェクト管理システム。
4. 請求項１または請求項２記載のプロジェクト管理システムにおいて、前記発生した場合の影響度を、品質に与える影響、コストに与える影響、及び／又は納期に与える影響という視点から評価して求める構成にしたことを特徴とするプロジェクト管理システム。
5. 請求項４記載のプロジェクト管理システムにおいて、前記品質に与える影響、コストに与える影響、および納期に与える影響のそれぞれに重み付けをして前記影響度を求める構成にしたことを特徴とするプロジェクト管理システム。
6. 請求項５記載のプロジェクト管理システムにおいて、前記重み付けの値をプロジェクトの時間的推移に応じて変化させる構成にしたことを特徴とするプロジェクト管理システム。
7. プロジェクトで作成されたコンピュータプログラムのソースコード量の実績値を取得することによりその実績値の計画値との作成量差分を可視化する作成量差分可視化手段を備えたプロジェクト管理システムにおいて、前記作成量差分が所定量以上拡大したコンピュータプログラムについて前記作成量差分の拡大状況を示す作成量差分情報を可視化するように前記作成量差分可視化手段を構成したことを特徴とするプロジェクト管理システム。
8. 請求項７記載のプロジェクト管理システムにおいて、前記作成量差分情報をプロジェクト管理者側装置へ通知する作成量差分通知手段を備えたことを特徴とするプロジェクト管理システム。
9. 請求項７または請求項８記載のプロジェクト管理システムにおいて、前記作成量差分情報として、実績値と計画値との差分量、今後のトレンド、及び／又は作成量差分の拡大した要因の候補を可視化する構成にしたことを特徴とするプロジェクト管理システム。
10. プロジェクトで作成されたコンピュータプログラムのテストの消化率を取得することによりその実績値の計画値とのテスト差分を可視化するテスト差分可視化手段を備えたプロジェクト管理システムにおいて、前記テスト差分が所定量以上拡大したコンピュータプログラムについて前記テスト差分の拡大状況を示すテスト差分情報を可視化するように前記テスト差分可視化手段を構成したことを特徴とするプロジェクト管理システム。
11. 請求項１０記載のプロジェクト管理システムにおいて、前記テスト差分情報をプロジェクト管理者側装置へ通知するテスト差分通知手段を備えたことを特徴とするプロジェクト管理システム。
12. 請求項１０または請求項１１記載のプロジェクト管理システムにおいて、前記テスト差分情報として、実績値と計画値との差分量、今後のトレンド、及び／又はテスト差分の拡大した要因の候補を可視化する構成にしたことを特徴とするプロジェクト管理システム。
13. プロジェクトで作成されたコンピュータプログラムの欠陥発見件数を取得することによりその実績値の計画値との欠陥数差分を可視化する欠陥数差分可視化手段を備えたプロジェクト管理システムにおいて、前記欠陥数差分が所定量以上拡大したコンピュータプログラムについて前記欠陥数差分の拡大状況を示す欠陥数差分情報を可視化するように前記欠陥数差分可視化手段を構成したことを特徴とするプロジェクト管理システム。
14. 請求項１３記載のプロジェクト管理システムにおいて、前記欠陥数差分情報をプロジェクト管理者側装置へ通知する欠陥数差分通知手段を備えたことを特徴とするプロジェクト管理システム。
15. 請求項１３または請求項１４記載のプロジェクト管理システムにおいて、前記欠陥数差分情報として、実績値と計画値との差分量、今後のトレンド、及び／又は結果数差分の拡大した要因の候補を可視化する構成にしたことを特徴とするプロジェクト管理システム。
16. プロジェクトで発生する可能性のあるリスクを、発生した場合の影響度と発生可能性の度合いから定量化して順位を付けることにより、リスクを監視するプロジェクト管理方法において、前記順位が高まったリスクを抽出し、抽出したリスクについて可視化情報を作成し、その可視化情報をプロジェクト管理者側へ通知することを特徴とするプロジェクト管理方法。
17. プロジェクトで作成されたコンピュータプログラムのソースコード量を取得することによりその実績値の計画値との作成量差分を可視化するプロジェクト管理方法において、前記作成量差分が拡大したコンピュータプログラムについて前記作成量差分の拡大状況を示す可視化情報を作成し、その可視化情報をプロジェクト管理者側へ通知することを特徴とするプロジェクト管理方法。
18. プロジェクトで作成されたコンピュータプログラムのテストの消化率を取得することによりその実績値の計画値とのテスト差分を可視化するプロジェクト管理方法において、前記テスト差分が拡大したコンピュータプログラムについて前記テスト差分の拡大状況を示す可視化情報を作成し、その可視化情報をプロジェクト管理者側へ通知することを特徴とするプロジェクト管理方法。
19. プロジェクトで作成されたコンピュータプログラムの欠陥発見件数を取得することによりその実績値の計画値との欠陥数差分を可視化するプロジェクト管理方法において、前記欠陥数差分が拡大したコンピュータプログラムについて前記欠陥数差分の拡大状況を示す可視化情報を作成し、その可視化情報をプロジェクト管理者側へ通知することを特徴とするプロジェクト管理方法。
20. 情報処理装置上で実行されるプログラムにおいて、請求項１６乃至請求項１９のいずれか１項に記載のプロジェクト管理方法のプロジェクト管理を実行させるようにプログラミングされていることを特徴とするプログラム。
21. 請求項２０記載のプログラムを記憶したことを特徴とする記憶媒体。

Images