(57)【要約】【課題】  複数の機能よりなる業務ソフトの複数機能を複数のチームで同時開発するプロジェクトの管理において、プロジェクトの最終段階になってから発覚するケースが多い、仕様が未確定のままであると全体に影響を及ぼしやすい開発機能をプロジェクト開始時に定量的に評価する手法と、プロジェクト途中で、仕様が発散しそうな業務を早期発見する手段を提供することを目的とする。【解決手段】  仕様が未確定のままであると全体に影響を及ぼしやすい開発機能は、プロジェクトメンバが初期に全体設計情報をもとに把握し、設計・開発段階に入った後では、該当機能を実際に担当するプログラム設計者やプログラマは、業務仕様の提示度合いの十分性を認識し、業務仕様の提示度合いの変化や、業務仕様の変更は、これをプログラム設計者やプログラマが開発規模の見直値に反映させることに着目してなしたものである。【選択図】  図３
2007172293.tif 000002
【特許請求の範囲】
【請求項１】
一つ又は複数の機能で構成される業務ソフトの開発プロジェクトを管理するためのプロジェクト管理プログラムであって、コンピュータを以下のように機能させるプロジェクト管理プログラムにおいて、
前記業務ソフトを構成する１以上の機能の仕様が他の機能の仕様に対して影響を及ぼす度合いを含む開発難易度を影響する機能範囲により定量的に評価して第１の定量値を算出する手段と、
該機能の仕様確定度合いを評価する手段と、
該機能の所定時期における開発規模の見積値を記録する手段と、
該機能の開発時における開発規模の見直値を記録する手段と、
前記見直値を前記見積値と比較することで、定量的に評価して第２の定量値を算出する手段と、
前記業務ソフトの複雑さを示す値、前記機能の仕様確定度合いの評価値、前記第１の定量値および前記第２の定量値を用いて、所定の規則に従って演算をすることにより、該機能の開発における前記業務ソフト全体に影響を及ぼしうる事態が生じていることを示す危険度を算出する手段として、前記コンピュータを機能させることを特徴とするプロジェクト管理プログラム。
【請求項２】
請求項１に記載のプロジェクト管理プログラムにおいて、
前記コンピュータを、さらに、
前記危険度の数値を過去に記録された該機能の危険度数値と比較評価してその相対的な変化を表示する手段として機能させることを特徴とするプロジェクト管理プログラム。
【請求項３】
請求項２のいずれかに記載のプロジェクト管理プログラムにおいて、
前記表示する手段を、開発機能ごとの危険度およびその変化を表示する手段として機能させることを特徴とするプロジェクト管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は業務分野でのソフトウェア開発におけるプロジェクト管理を行う技術に関する。特に、仕様確定度合いの低い機能部分を発見しプロジェクト混乱のリスクを未然に防止することに好適なプロジェクト管理方法及びこれを実現するプログラムに関する。
【背景技術】
【０００２】
一般に業務ソフトの開発プロジェクトは、プロジェクトマネージャなどのプロジェクト管理者とプログラム設計者・プログラマなどの開発チームにより構成される。従来のプロジェクト管理方法は、一般にＷＢＳ法に基づいている。ＷＢＳ法によるプロジェクトの計画はプロジェクトに必要な最終成果物、中間成果物の洗出しと、各成果物の作成に必要な作業構成ＷＢＳ（ＷＯＲＫ  ＢＲＥＡＫＤＯＷＮ  ＳＴＲＵＣＴＵＲＥ）を作成し、各作業や作業別の工数等を見積り、作業者を割り当てることによりプロジェクトを計画する。ＷＢＳ法によるプロジェクトの管理はプロジェクト開始後の、各作業ごとの実行結果を計画時の見積と比較しプロジェクトで発生する問題の早期発見と早期対策を目指すものであり、線表（工程表）管理の形式で予定線表に実績を上書することで予定期日とのずれにより問題発見することが多い。
【０００３】
しかしながら、この管理手法では、業務分野でのソフトウェア開発におけるプロジェクト管理にありがちな、プロジェクトの前提となる最終成果物の一部機能に関する顧客要求に対応する仕様確定度があいまいなままの場合にプロジェクトマネージャがこれを定量的に発見することが難しく、またこの仕様が他の機能の仕様にも影響を与えている場合は、プロジェクトの最終段階になってから、複数機能にまたがる仕様変更を発生させプロジェクトの混乱を発生させることがあるという問題があった。これを指して一般に「線表に問題が現れた時には手遅れになっているケースが多い」などとも言われている。
【０００４】
【特許文献１】特開２００４−１８５３４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の課題は複数の機能よりなる業務ソフトウェア開発プロジェクト、特に業務ソフトの複数機能を複数のチームで同時開発するプロジェクトの管理面において、プロジェクトの最終段階になってから発覚するケースが多い、仕様が未確定のままであると全体に影響を及ぼしやすい開発機能をプロジェクト開始時に定量的に評価する手法と、プロジェクト途中において、仕様が発散しかかっている業務を早期発見する手段を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、プロジェクトの前提となる最終成果物の一部機能に関する顧客要求に対応する仕様確定度があいまいなままの場合にプロジェクト管理者がこれを定量的に発見することが難しい反面、（１）仕様が未確定のままであると全体に影響を及ぼしやすい開発機能は、プロジェクト管理者が初期に全体設計情報をもとに把握できる、（２）設計・開発段階に入ったあとでは、該当機能を実際に担当するプログラム設計者やプログラマは、業務仕様の提示度合いの十分性を認識しやすいこと、（３）業務仕様の提示度合いの変化や、業務仕様の変更は、これをプログラム設計者やプログラマは開発規模の見直値に反映させやすいことに着眼してなしたものである。
【０００７】
より具体的には、以下のとおりの構成を有する。（１）該業務ソフトを構成する一つまたは複数の機能の仕様が他の機能の仕様に対して影響を及ぼす度合い等（ここでは開発難易度と呼ぶ）を影響する機能範囲により定量的に評価する手段と、（２）該機能の仕様確定度合い等が低い度合い等を定量的に評価する手段と、（３）該機能の「開発規模の見積値」を記録する手段と、（４）該機能の開発時に「開発規模の見直値」を記録する手段と、（５）該「開発規模の見直値」を該「開発規模の見積値」を基準に定量的に評価する手段と、（６）該「システムの複雑さ」と「該機能の仕様確定度合いが低い度合い等の定量的評価結果」と「該開発規模の見直値を該開発規模の見積値を基準に定量的に評価した結果」に乗算等の演算をすることにより該機能の開発において該機能のみならず該業務ソフト全体に影響を及ぼしうる事態が生じていることを示す数値を該機能に対応して一つ計算する手段（この数値を該機能の危険度と呼ぶことにする）と、（７）該危険度の数値を（プロジェクトの進行にあわせて）一回又は複数回評価記録する手段と、（８）該危険度の数値を過去に記録された該機能の危険度数値と比較評価してその相対的な変化を評価表示する手段と、（９）（プロジェクト管理者が判断するために）開発機能ごとの危険度数値およびその相対的な変化を該プロジェクトの構成機能の一覧とともに表示する手段を設ける。
【発明の効果】
【０００８】
本発明によれば、仕様確定度合いの低い機能部分を発見しプロジェクト混乱のリスクを未然に防止することが可能になる。
【発明を実施するための最良の形態】
【０００９】
本発明の一実施例を下記に示す。
本実施例は市販の表計算ソフトウェア製品の開発による例にして説明している。市販の表計算ソフトウェア製品が表形式の画面入出力機能をもち、また数式を定義すれば計算する機能があることは良く知られているため以下では煩雑さを避けるためデータの入出力と計算式とのリンクについての説明を省略している。また、市販の表計算ソフトウェア製品にマクロプログラムとしてユーザが設定するプログラムも、当業者ならば本実施形態の表現を読めば通常のプログラム設計能力により作成できるため以下では煩雑さを避けるためプログラム構造の記述は省略している。
【００１０】
図１は、本プログラムのプロジェクト管理者の入力画面例の１つを表している。見出し部分、プログラムが自動で計算して出力する部分，及び利用者が入力する部分で構成している。なお、図面において、見出し部分とプログラムが自動で計算して出力する部分は、利用者が入力する部分と区別するための網掛け表示の実施は見易さを損ないやすくかつ当業者ならば区別できるため、あえて省略してある。
【００１１】
利用者はプロジェクトマネージャなどのプロジェクト管理者とプログラム設計者・プログラマなどの開発チームの2種類に大別される。
まずプロジェクトマネージャなどのプロジェクト管理者は、プロジェクトの開始前もしくはプロジェクトの開始時に、管理対象のプロジェクトが開発する業務ソフトの１次機能名（項目１０１）及び2次機能名（項目１０２）を入力する。次に「開発規模の見積値」（項目１０３）を入力する。
【００１２】
続いて、各機能をいくつかの観点で評価する。この例では、システムの複雑度（項目１０４）と信頼性と性能の要求レベル（項目１０５）を定められた記号から選択して入力する。システムの複雑度（項目１０４）はシステム構築時に変更（例えば仕様確定遅延の上で思わぬ変更）が生じた場合に、プロジェクト内で手戻りが波及する影響範囲を評価する。
【００１３】
本実施例では、影響範囲が（該2次機能及び下位階層と直上１次機能階層の下位範囲内）の場合記号▽を選択する仕様になっている。この場合評価値  ３がアサインされる。影響範囲が（直上の１次機能以外の１次機能の範囲内に影響する）場合記号×を選択する仕様になっている。この場合評価値  ５がアサインされる。影響範囲が（該2次機能及び下位階層に限定される）場合記号・を選択する仕様になっている。この場合評価値  １がアサインされる。一般のプロジェクト運営において、開発機能は１次機能を単位として開発チーム編成する場合が多く、２次機能を単位として設計者・プログラマに業務アサインする場合が多い。このため上記評価により記号×は他開発チームへの影響可能性を示し、記号▽は同一開発チーム内の他の設計者・プログラマへの影響可能性を示す。
【００１４】
信頼性と性能の要求レベル（項目１０５）は、同様に該2次機能に問題が生じた場合に人命に関わる損害が予想される場合は×を選択する。この場合評価値  ２がアサインされる。高い財政上の損失が予想される場合は▽を選択する。この場合は評価値  １．８がアサインされる。復旧可能な損失が予想される場合は□を選択する。この場合は評価値  １．５がアサインされる。  :簡単に復旧可能な損失が予想される場合は△を選択する。この場合は 評価値  １．２がアサインされる。使用できればよい場合は・を選択する。この場合は評価値  １がアサインされる。開発難易度（項目１０６）はシステムの複雑度（項目１０４）の評価値と信頼性と性能の要求レベル（項目１０５）の乗算結果を表示している。
【００１５】
尚、業務/機能一覧見出し（項目１０７）、開発規模の見積値の見出し（項目１０８）、入力年月日見出し及び利用者入力部（項目１０９）、開発規模の見積値の決定イベント（項目１１０）、開発規模の見積値の合計値表示部（項目１１１）、開発規模の見積値の単位（項目１１２）については今回の請求項と直接には関係しないため煩雑を避けるため説明を省略する。
【００１６】
図２は、図１に示した本プログラムのプロジェクト管理者の入力画面例の１つで（項目２０１）はシステムの複雑度入力機能の選択表示を示している。システムの利用者であるプロジェクトマネージャなどのプロジェクト管理者は、×、▽、・などの記号を選択することによりプログラムのシステム複雑度評価値が設定される構造になっている。本実施例ではシステムの複雑度の入力補助ポップアップ画面（項目２０２）を該複雑度入力時に表示してプログラムの利用者を支援している。
【００１７】
以上により、（１）該業務ソフトを構成する一つまたは複数の機能の仕様が他の機能の仕様に対して影響を及ぼす度合い等（ここでは開発難易度と呼ぶ）を影響する機能範囲により定量的に評価する手段と（２）該機能の仕様確定度合い等が低い度合い等を定量的に評価する手段と、（３）該機能の「開発規模の見積値」を記録する手段と（４）該機能の開発時に「開発規模の見直値」を記録する手段を実現している。
【００１８】
図３は、プロジェクト管理者の入力画面例とプログラム設計者・プログラマなどの開発チームの入力画面例である。通常はプロジェクト開始後の工程会議の前に入力する。図１に示した本プログラムのプロジェクトマネージャ等のプロジェクト管理者の入力画面と並列に並べて、管理対象のプロジェクトが開発する業務ソフトの１次機能名、及び2次機能名ごとに,業務仕様の提示度合（項目３０１）と開発規模の見直値（項目３０２）を入力する。
【００１９】
業務仕様の提示度合（項目３０１）入力時に利用者は、業務仕様の提示度合いを選択入力する。該業務機能に係る文書による業務仕様提示度合が8割未満の場合は、記号×を選択入力するがこのときプログラムは評価値  ３をアサインする。該業務機能に係る文書による業務仕様提示度合が8割方の場合は記号▽を選択するがこのときプログラムは評価値  ２をアサインする。該業務に係る文書による業務仕様提示度合が１００％である場合は記号・を選択するがこのときプログラムは評価値  １をアサインする。
【００２０】
開発規模の見直値（項目３０２）を入力すると、プログラムは、図１の（項目１０３）により入力した該機能の「開発規模の見積値」を分母に、該入力を分子にして規模比（項目３０３）を計算する。プログラムはこのとき該開発規模の見直しによる増減（ここでは規模比という）を評価し、その結果が当初比増加  ２０％以上の場合は評価値    ５をアサインする。当初比増加  ５〜２０％の場合は 評価値  ３をアサインする。当初比増加  ５％未満の場合は評価値  １をアサインする。    
危険度評価回次（０１）（項目３０４）は図１の開発難易度（項目１０６）と業務仕様の提示度合い（項目３０１）の評価値と、規模比（項目３０３）の評価値の乗算結果を表示している。
【００２１】
図３の業務仕様提示度合（項目３０５）、開発規模の見直値（項目３０６）、規模比（項目３０７）、及び危険度評価回次（０２）（項目３０８）は、入力時期が後になる点をのぞけば（入力時期として次の工程会議前を想定）前述の定義と同じである。危険度前回比（項目３０９）は、危険度評価回次（０１）（項目３０４）の値から危険度評価回次（０２）（項目３０８）の値を減算し、その結果がマイナスであれば記号↓を表示し、０であれば記号―を表示し、プラスであれば記号↑を表示する。
【００２２】
図４は、図３に示した本プログラムの開発チームの入力画面例の１つで（項目４０１）は業務仕様提示度合の選択表示を示している。システムの利用者は、×、▽、・などの記号を選択することによりプログラムの業務仕様提示度合評価値が設定される構造になっている。本実施例では（項目４０２）業務仕様提示度合の選択表示入力補助ポップアップ画面を該業務仕様提示度合の入力時に同時に表示しプログラムの利用者を支援している。
【００２３】
以上により（５）該「開発規模の見直値」を該「開発規模の見積値」を基準に定量的に評価する手段と（６）該「システムの複雑さ」と「該機能の仕様確定度合いが低い度合い等の定量的評価結果」と「該開発規模の見直値を該開発規模の見積値を基準に定量的に評価した結果」に乗算等の演算をすることにより該機能の開発において該機能のみならず該業務ソフト全体に影響を及ぼしうる事態が生じていることを示す数値を該機能に対応して一つ計算する手段（この数値を該機能の危険度と呼ぶことにする）と、（７）該危険度の数値を（プロジェクトの進行にあわせて）一回又は複数回評価記録する手段と、（８）該危険度の数値を過去に記録された該機能の危険度数値と比較評価してその相対的な変化を評価表示する手段と、（９）（プロジェクトメンバが判断するために）開発機能ごとの危険度数値およびその相対的な変化を該プロジェクトの構成機能の一覧とともに表示する手段を実現している。
【００２４】
図５は、本プログラムの開発チームの入力画面例の１つで、3次機能名以下を担当するプログラム設計者、プログラマを利用者として想定した入力画面である。１次機能名（項目５０１）及び２次機能名（項目５０２）は、図１に示した１次機能名（項目１０１）及び2次機能名（項目１０２）と同じものを入力する。３次機能名（項目５０３）および４次機能名（項目５０４）は２次機能名（項目５０２）の下位機能名を入力する。開発規模（項目５０５）及び業務仕様提示度合（項目５０６）は、該機能の規模見直値を入力する。
【００２５】
プログラムは開発規模の合計値（項目５０７）を計算する。また業務仕様提示度合の最悪値（項目５０８）を比較演算して決定する。上記入力後の利用者のプログラム起動により、プログラムは危険度評価回次（項目５０９）及び１次機能名（項目５０１）及び２次機能名（項目５０２）をもとに、開発規模の合計値（項目５０５）および業務仕様提示度合の最悪値（項目５０８）を図３の（項目３０６）および(項目３０７)に入力する。
【００２６】
開発規模管理単位（項目５１０）、プロジェクト名（項目５１１）、規模評価タイミング（項目５１２）および合計見出し（項目５１３）については今回の請求項と直接には関係しないため煩雑を避けるため説明を省略する。
【００２７】
以上により（２）該機能の仕様確定度合い等が低い度合い等を定量的に評価する手段に該機能の下位階層の機能の仕様確定度合い等が低い度合いを集約する手段と、（３）該機能の「開発規模の見積値」を記録する手段に該機能の下位階層の機能の見積値を集約する手段と（４）該機能の開発時に「開発規模の見直値」を記録する手段に、該機能の下位階層の機能見直値を集約する手段を実現している。
【００２８】
以上説明した本実施形態（例）によれば、業務分野でのソフトウェア開発におけるプロジェクト管理にありがちな、仕様確定度があいまいなままでプロジェクトマネージャが発見することが難しい問題が生じている開発機能を早期に発見し、プロジェクトの最終段階になってから複数機能にまたがる仕様変更などのプロジェクトの混乱を抑止する効果がある。また開発チームの入力する４次機能単位の開発規模見直し値の増減や仕様の提示度合いを集約して２次開発機能単位に集約して危険度と共に一覧表示するため、プロジェクト管理者は集約作業をすることなく危険度の高い順番に２次開発機能を評価することができる。また２次開発機能単位に自動的にその危険度の増減を計算して記号表示するため、プロジェクト管理者は計算作業をすることなく危険度の増減を一目瞭然に知ることができる。これらによりプロジェクト管理者はより容易に問題の生じている２次開発機能と問題の生じていない２次開発機能を識別することができるため、問題の生じている２次開発作業への対策に集中できるなどの効果がある。
【図面の簡単な説明】
【００２９】
【図１】本プログラムのプロジェクト管理者の入力画面例の１つ
【図２】図１に示した本プログラムのプロジェクト管理者の入力画面例の１つ
【図３】プロジェクト管理者の入力画面例とプログラム設計者・プログラマなどの開発チームの入力画面例
【図４】図３に示した本プログラムの開発チームの入力画面例の１つ
【図５】本プログラムの開発チームの入力画面例の１つ
【符号の説明】
【００３０】
１０１    １次機能名
１０２    2次機能名
１０３    開発規模の見積値
１０４    システムの複雑度
１０５    信頼性と性能の要求レベル
１０６    開発難易度
１０７    業務/機能一覧見出し
１０８    開発規模の見積値の見出し
１０９    入力年月日見出し及び利用者入力部
１１０    開発規模の見積値の決定イベント
１１１    開発規模の見積値の合計値表示部
１１２    開発規模の見積値の単位
２０１    システムの複雑度入力機能の選択表示
２０２    システムの複雑度の入力補助ポップアップ画面
３０１    業務仕様の提示度合
３０２    開発規模の見直値
３０３    規模比
３０４    危険度評価回次（０１）
３０５    業務仕様提示度合
３０６    開発規模の見直値、
３０７    規模比
３０８    危険度評価回次（０２）
３０９    危険度前回比
４０１    業務仕様提示度合の選択表示
４０２    業務仕様提示度合の選択表示入力補助ポップアップ画面
５０１    １次機能名
５０２    ２次機能名
５０３    ３次機能名
５０４    ４次機能名
５０５    開発規模
５０６    業務仕様提示度合
５０７    開発規模の合計値
５０８    業務仕様提示度合の最悪値
５０９    危険度評価回次
５１０    開発規模管理単位
５１１    プロジェクト名
５１２    規模評価タイミング
５１３    合計見出し
【図１】
2007172293.tif 000003
【図２】
2007172293.tif 000004
【図３】
2007172293.tif 000005
【図４】
2007172293.tif 000006
【図５】
2007172293.tif 000007