JP2003296528A

JP2003296528A - 開発プロセスのテーラリングシステム、及びテーラリング方法

Info

Publication number: JP2003296528A
Application number: JP2002095026A
Authority: JP
Inventors: Kazutoshi Shimanaka; 一俊島中
Original assignee: NTT Comware Corp
Current assignee: NTT Comware Corp
Priority date: 2002-03-29
Filing date: 2002-03-29
Publication date: 2003-10-17

Abstract

(57)【要約】【課題】どの様なプロセスで開発作業を行うかを決定
することは、経験の浅いマネージャにとって困難なもの
であった。そのために、組織は標準の開発プロセスを定
義し対処している。しかし、この様な開発プロセスは、
組織の全プロジェクトに適合するよう形成されており、
小さなプロジェクトに対しては過剰なプロセスとなりが
ちであった。【解決手段】標準開発プロセスのアクティビティー毎
のリスクデータと、リスク根拠となる入力データを基
に、許容リスクレートを決定するためのリスク演算部１
１と、許容リスクレートを基に、標準開発プロセスを構
成する各アクティビティー毎に、プロジェクト管理プロ
セスに取り込むか否かを決定するテーラリング部１２を
設ける。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、開発プロセスのテ
ーラリングシステム、及びテーラリング方法関するもの
であり、特に、経験の浅いマネージャーでもプロジェク
トのリスクに合わせた適正な開発プロセスを作成可能な
様に、標準プロセスをリスクに合わせてテーラリングで
きる開発プロセスのテーラリングシステム、及びテーラ
リング方法に関する。

【０００２】

【従来の技術】開発への着手にあたり、どの様なプロセ
スで開発作業を行うかの決定は、プロジェクトのマネー
ジャの大きな悩みとなる。特に新規の開発プロジェクト
においては、過去に類似するプロジェクトの経験がない
経験の浅いマネージャにとって、この決定は非常に困難
なものとなる。そのために、組織は標準の開発プロセス
を定義して対処している。しかし、通常この様な開発プ
ロセスは、定義やメンテナンスにかかるコストやリスク
管理の観点で組織の全プロジェクトに適合するよう形成
されている。このため、一般に小さなプロジェクトに対
しては重い過剰なプロセスとなりがちである。この様な
過剰プロセスは開発コストの増加につながりソフトウェ
アの原価を上昇させてしまう。そのため、経験の浅いマ
ネージャでもプロジェクトのリスクに合わせた適正な開
発プロセスをできるようにするための、標準プロセスを
リスクに合わせてテーラリングできる開発プロセスのテ
ーラリングシステムの提供が望まれていた。

【０００３】また、従来のテーラリングシステムにおい
ては、以下のような問題もあった。・従来は属人的なノウハウを元に特定な人間のみが勘に
頼ってテーラリングを実施していた。・テーラリングはノウハウのある特定の人間にしかでき
ない作業であったため、非効率であった。・作業者のスキルレベルによってテーラリングしたプロ
セスの妥当性が均質にならない問題があった。

【０００４】

【発明が解決しようとする課題】本発明は、上記課題に
鑑みてなされたものであり、開発対象となるプロジェク
トの見積り根拠（入出力コンポーネント情報、蓄積コン
ポーネント情報）を入力し、さらにプロジェクトのリス
ク根拠となるメンバーのスキル、要求仕様の確度、納期
の厳しさ、品質の与えるの影響度等を入力することによ
ってプロジェクトのリスクに見合ったテーラリングを行
うことを可能にする開発プロセスのテーラリングシステ
ム、及びテーラリング方法を提供することを目的とす
る。

【０００５】

【課題を解決するための手段】本発明は、上述した課題
を解決すべくなされたもので、本発明の開発プロセスの
テーラリングシステムは、開発リスクにより開発プロセ
スのテーラリングを行う開発プロセスのテーラリングシ
ステムであって、対象となるプロジェクトの標準開発プ
ロセスを登録した開発管理データベースと、標準開発プ
ロセスのアクティビティー毎のリスクデータを登録した
開発プロセスデータベースと、見積り根拠となる入力デ
ータからプロジェクトの属性値（少なくとも工期、工
数、規模を含む）を見積るプロジェクト属性見積手段
と、前記標準開発プロセスのアクティビティー毎のリス
クデータと、リスク根拠となる入力データを基に、許容
リスクレートを決定するための手段と、前記許容リスク
レートを基に、標準開発プロセスを構成する各アクティ
ビティー毎に、プロジェクト管理プロセスに取り込むか
否かを決定するテーラリング手段とを具備することを特
徴とする。これにより、従来、テーラリング技術は属人
的なノウハウであり、ノウハウのない人間には不可能な
作業であったが、本発明の本テーラリングシステムを用
いることによって経験の浅い間でも適正なテーラリング
を行うことができ、均質な作業レベルが確保できる。

【０００６】また、本発明の開発プロセスのテーラリン
グシステムは、前記標準開発プロセスのアクティビティ
ー毎のリスクデータが、過去に実施されたプロジェクト
におけるプロジェクト管理プロセスの実施率を基に算定
される手段をさらに具備することを特徴とする。これに
より、過去の実績に基づいた適正なテーラリングを行う
ことができる。

【０００７】また、本発明の開発プロセスのテーラリン
グシステムは、前記リスク根拠には、少なくともプロジ
ェクトメンバーのスキル、経験、及び新技術の適用の要
素が含まれることを特徴とする。これにより、プロジェ
クトを構成するメンバーの実情に即して、適正なテーラ
リングを行うことができる。

【０００８】また、本発明の開発プロセスのテーラリン
グシステムは、前記許容リスクレートを求める際には、
各アクティビティーについて、プロジェクトの工期、工
数、規模ごとに許容リスクレートを求める手段と、前記
工期、工数、規模ごとに求めた許容リスクレート中の最
大の許容リスクレートを、当該アクティビティーの許容
リスクレートとして決定する手段とをさらに具備するこ
とを特徴とする。これにより、工期、工数、規模に応じ
た適正なテーラリングを行うことができる。

【０００９】また、本発明の開発プロセスのテーラリン
グ方法は、開発リスクにより開発プロセスのテーラリン
グを行う開発プロセスのテーラリング方法であって、対
象となるプロジェクトの標準開発プロセスを開発管理デ
ータベースに登録する手順と、標準開発プロセスのアク
ティビティー毎のリスクデータを開発プロセスデータベ
ースに登録する手順と、見積り根拠となる入力データか
らプロジェクトの属性値（少なくとも工期、工数、規模
を含む）を見積るプロジェクト属性見積手順と、前記標
準開発プロセスのアクティビティー毎のリスクデータ
と、リスク根拠となる入力データを基に、許容リスクレ
ートを決定するための手順と、前記許容リスクレートを
基に、標準開発プロセスを構成する各アクティビティー
毎に、プロジェクト管理プロセスに取り込むか否かを決
定するテーラリング手順とを含むことを特徴とする。こ
れにより、従来、テーラリング技術は属人的なノウハウ
であり、ノウハウのない人間には不可能な作業であった
が、本発明の本テーラリングシステムを用いることによ
って経験の浅い間でも適正なテーラリングを行うことが
でき、均質な作業レベルが確保できる。

【００１０】また、本発明の開発プロセスのテーラリン
グ方法は、前記標準開発プロセスのアクティビティー毎
のリスクデータが、過去に実施されたプロジェクトにお
けるプロジェクト管理プロセスの実施率を基に算定され
る手順をさらに含むことを特徴とする。これにより、過
去の実績に基づいた適正なテーラリングを行うことがで
きる。

【００１１】また、本発明の開発プロセスのテーラリン
グ方法は、前記リスク根拠には、少なくともプロジェク
トメンバーのスキル、経験、及び新技術の適用の要素が
含まれることを特徴とする。これにより、プロジェクト
を構成するメンバーの実情に即して、適正なテーラリン
グを行うことができる。

【００１２】また、本発明の開発プロセスのテーラリン
グ方法は、前記許容リスクレートを求める際には、各ア
クティビティーについて、プロジェクトの工期、工数、
規模ごとに許容リスクレートを求める手順と、前記工
期、工数、規模ごとに求めた許容リスクレート中の最大
の許容リスクレートを、当該アクティビティーの許容リ
スクレートとして決定する手順とをさらに含むことを特
徴とする。これにより、工期、工数、規模に応じた適正
なテーラリングを行うことができる。

【００１３】また、本発明のコンピュータ読み取り可能
な記録媒体は、開発リスクにより開発プロセスのテーラ
リングを行う開発プロセスのテーラリングシステム内の
コンピュータに、対象となるプロジェクトの標準開発プ
ロセスを開発管理データベースに登録する手順と、標準
開発プロセスのアクティビティー毎のリスクデータを開
発プロセスデータベースに登録する手順と、見積り根拠
となる入力データからプロジェクトの属性値を見積るプ
ロジェクト属性見積り手順と、前記標準開発プロセスの
アクティビティー毎のリスクデータと、リスク根拠とな
る入力データを基に、許容リスクレートを決定するため
の手順と、前記許容リスクレートを基に、標準開発プロ
セスを構成する各アクティビティー毎に、プロジェクト
管理プロセスに取り込むか否かを決定するテーラリング
手順とを実行させるためのプログラムを記録したコンピ
ュータ読み取り可能な記録媒体である。

【００１４】また、本発明のコンピュータプログラム
は、開発リスクにより開発プロセスのテーラリングを行
う開発プロセスのテーラリングシステム内のコンピュー
タに、対象となるプロジェクトの標準開発プロセスを開
発管理データベースに登録する手順と、標準開発プロセ
スのアクティビティー毎のリスクデータを開発プロセス
データベースに登録する手順と、見積り根拠となる入力
データからプロジェクトの属性値を見積るプロジェクト
属性見積り手順と、前記標準開発プロセスのアクティビ
ティー毎のリスクデータと、リスク根拠となる入力デー
タを基に、許容リスクレートを決定するための手順と、
前記許容リスクレートを基に、標準開発プロセスを構成
する各アクティビティー毎に、プロジェクト管理プロセ
スに取り込むか否かを決定するテーラリング手順とを実
行させるためのプログラムである。

【００１５】

【発明の実施の形態】［本発明の背景思想の説明］本発
明のテーラリングシステムの理論的根拠、及び本発明に
よるテーラリングシステムの効果の裏付けとなる資料に
ついては、後述する［補足資料］の項で詳細に説明する
ため、ここでは、その概略についてだけ説明すると、

【００１６】・本発明におけるテーラリングシステム
は、プロジェクトが全社的な標準の下で開発作業が進め
られており、生産管理データ（または開発管理データ）
によるプロジェクト管理が制度化している場合に適用さ
れるシステムである。

【００１７】・また、プロセスアセスメント手法として
は、基本的にＳＰＡ（ＩＳＯ／ＩＥＣ１５５０４）を参
考とし、その能力水準をアレンジした図１５に示す３つ
の水準で評価を行う。

【００１８】・また、生産管理データを評価するために
ＳＬＣＰ−ＪＣＦ９８を用いる。ＳＬＣＰ−ＪＣＦ９８
は、ＳＰＡのプロセスモデルであるＳＬＣＰをプロジェ
クトに実装するための規格に準拠しつつ各アクビティー
に具体的なタスクと成果物を定義したフレームワークで
ある。

【００１９】[本発明によるテーラリングシステムの構
成］図１は、本発明によるテーラリングシステムの構成
を示すブロック図であり、図１に示すテーラリングシス
テム１を構成する各部は、以下の機能を有する。

【００２０】・リスク演算部１１は、開発プロセスデー
タベース１７からプロセスの簡易化が可能なプロジェク
トの許容リスクレート（許容リスク値）を求める。ま
た、入力したリスク根拠２１に従って許容リスクレート
を補正する。なお、リスク根拠２１には、「プロジェク
トメンバーのスキル」、「要求仕様の確度」、「納期の
厳しさ」などがある。

【００２１】・テーラリング部１２は、入力した見積り
根拠２０に対応する開発リスクデータを特定し、開発プ
ロセスデータベース（ＤＢ）１７から開発リスクデータ
を読み出す。また、リスク演算部１１から補正後の許容
リスクレートを得て、読み出した開発リスクデータと比
較分析し、開発プロセスのテーラリングを行う。なお、
見積り根拠２０には、「入出力コンポーネント情報」や
「蓄積コンポーネント情報」がある。なお、「入出力コ
ンポーネント」とは、入出力画面、入出力ファイル、入
出力電文、入出力帳票等を示し、「蓄積コンポーネン
ト」とは、DBテーブル、論理ファイル等を示す。また、
コンポーネント情報とは、コンポーネントの種別と数を
示す。

【００２２】・開発プロセスデータベース部１７は、標
準開発プロセスのアクティビティー毎のリスクデータを
保存するデータベースである。なお、アクティビティー
とは、ＳＬＣＰ−ＪＣＦ９８で規定されるアクティビテ
ィーである。

【００２３】・プロセスデータ編集部１８は、開発管理
データベース１９に登録されたデータから、標準開発プ
ロセスのアクティビティー毎にリスクデータを作成す
る。また、システム機能規模値と開発規模値とを対応づ
けして見積りデータベース１６を作成する。

【００２４】・開発規模見積り部１３は、入力された開
発対象システムへの「入出力コンポーネント情報」と
「蓄積コンポーネント情報」に予め割り当てられた機能
規模値を読み出し、全てのコンポーネントの機能規模値
を総計してシステム機能規模値を決定する。また、シス
テム機能規模値から対応する開発規模を見積りデータベ
ース１６から読み出す。なお、コンポーネント種別の追
加／削除と各コンポーネントに割り当てられる機能規模
値の修正を行う。

【００２５】・工期見積り部１４は、システム機能開発
規模値から対応する開発工期を見積りデータベース１６
から読み出す。

【００２６】・工数見積り部１５は、システム機能規模
値から対応する開発工数を見積りデータベース１６から
読み出す。

【００２７】［許容リスクと許容リスクの導出処理につ
いて］（１）最初にリスク演算部１１における許容リスクレー
トの導出処理について説明する。図２は、開発プロセス
データベース１７内のプロジェクト管理プロセス実施率
のデータイメージを示す図であり、開発規模とプロジェ
クト管理プロセス（管理）の関係を示す図である。図２
において、横軸はＳＬＣＰ−ＪＣＦ９８に規定されるア
クティビティー項目の番号、縦軸はプロジェクト管理プ
ロセス管理の実施率を示しており、各層別グループ（個
々のグラフ）は開発規模（単位ｋｌｏｃ）別のグループ
を示している。

【００２８】図２に示すように、プロジェクトのリスク
（プロジェクト管理プロセス実施率）を把握し、それに
応じたプロセスを簡易化しても良い許容リスクレートの
設定を行う。このため、許容リスクレート以下では確か
に上記層別グループ間のプロジェクト管理プロセス実施
率に差があることを示す必要がある。そこで、統計的検
定を用いて層別したグループのプロセス実施率の差を証
明し許容リスクを求める。なお、この統計的検定につい
ては、後述する［補足資料］の項目で説明する。開発プロセスデータベース１７に記録されたデータか
ら、プロセス実施率の平均値が最大の層別グループのプ
ロセスを基準プロセスとする。図２において、破線で示
すレベルが基準プロセスａとなる。基準プロセスａと他の層別グループのプロセスとの差
を検定するため、帰無仮説として「各々のグループ間で
プロセス実施率の平均値に差は無い」を設定する。プロセス実施率の平均値が高いグループから基準プロ
セスとの差異を検定し、帰無仮説が最初に棄却される層
別グループのプロセス実施率の平均値を許容リスクレー
トとする。

【００２９】（２）次に、求めた許容リスクレート（許
容リスク値）の補正を行う。図３は、許容リスクの補正
について説明するための図である。下記の表に示す項目を３段階で評価して０点から２点
までのリスク評価値を決定する。

【表１】全ての項目のリスク評価値を加算して下式を適用して
許容リスクレートの補正係数を作成する。許容リスクレート補正係数＝（０．５＋（Σリスク評価
値）×０．１２５）許容リスクレートの補正補正後許容リスクレート＝補正前許容リスクレート×補
正係数以上のようにして求めた許容リスクレート以下の
プロジェクト管理プロセス実施率であるアクティビティ
ーについては、プロセスの管理対象から除外することに
なる。

【００３０】［標準プロセステーラリング手順］次に、
テーラリング部１２の標準プロセステーラリング手順に
ついて説明する。図４は、テーラリング手順の処理フロ
ーを示す図であり、以下、図４を基にテーラリング手順
について説明する。

【００３１】対象となるシステムの見積り根拠を基に
システム機能規模を求め、図１０〜図１２に示す表に最
小二乗法を用いて得られる回帰式を適用して、プロジェ
クトの各属性値（工数、工期、開発規模）を見積る（ス
テップＳ１）。なお、図２９に具体例を示す。図２９に
示す例は、図１１に示すシステム機能規模と開発工数と
の関係の表から、回帰関数と散布図を求めた例である。

【００３２】プロジェクト管理プロセス実施率表の値
をプロジェクトのリスクレートと見なし、見積りしたプ
ロジェクト属性値が該当するデータ範囲のリスクレート
を決定する（ステップＳ２）。

【００３３】当該プロジェクトの特性（メンバーのス
キルや経験および新技術の適用など）によって許容リス
クレートを補正する（ステップＳ３）。

【００３４】工期、工数、規模で決定したリスクレー
トのうちアクティビティー毎にリスクレートが最大のも
のを選択し、プロジェクトの許容リスクレートと比較す
る（ステップＳ４、Ｓ５）。

【００３５】比較の結果、アクティビティーのリスク
レートが許容リスクレートを超えるものはプロジェクト
管理プロセスに取り込む（ステップＳ６）。

【００３６】比較の結果、アクティビティーのリスク
レートが許容リスクレート以下の物はプロジェクト管理
プロセスから外すことを推奨する（ステップＳ７）。

【００３７】上記の手順によるプロジェクト管理プロセ
スのテーラリングの具体例を以下に示す。

【００３８】仮に、図４のステップＳ１によって、プロ
ジェクトの見積り結果を２５人月、３ヶ月、１８ｋｌと
して、プロジェクト管理プロセス計画を作成する。

【００３９】＜許容リスクレートの設定＞まず、図５
（ａ）からプロジェクト管理実施率の平均値が最大の５
００人月以上の層別グループを基準プロセスとする。そ
して、基準プロセスとそれ以外の層別グループのプロジ
ェクト管理プロセス実施率の平均値を、帰無仮説に「各
々のグループ間でプロセス実施率の平均値に差はない」
とおいて、ｔ検定を用いて統計的に検定する。この検定
はプロジェクト管理プロセス実施率の平均値で降順に層
別グループを選んで行う。なお、検定における有意差に
はここでは１％を用いることにする。この結果、最初に
有意差ありとして帰無仮説が棄却される２０〜６０人月
の層別グループのプロジェクト管理プロセス実施率の平
均である３５．３％を許容リスク値（工数）とする。以
下同様に、開発規模、工期の許容リスク値を算出し、最
終的に値が最低のものを許容リスク値として設定する。

【００４０】＜テーラリング作業＞まず、図５（ａ）に
示すプロジェクト管理プロセス実施率表（工数）から工
数のリスクレートを選択する。この場合、見積り値は２
５人月なので、データ範囲２０〜６０のリスクレートを
決定する。同様に、図５（ｂ）に示す規模、図５（ｃ）
に示す工期のリスクレートを決定し、アクティビティー
毎にリスクレートが最大なものを選択し、図６に示すリ
スクレートの表を得る。なお、図５〜図７におけるアク
ティビティーとは、ＳＬＣＰ−ＪＣＦ９８のアクティビ
ティー番号を示す。

【００４１】＜リスク演算部の許容リスク値の補正＞次
に、プロジェクトの特性からプロジェクトの許容リスク
レートを補正する。状況から判断したプロジェクトの特
性は以下の通りである。（ア）メンバーのスキルは非常に高い。（イ）要求仕様の確度は中程度（ウ）納期の厳しさは低い（エ）品質の与える影響は高いこの特性を下記の表に適用してリスク評価値を決定す
る。

【表２】次に、リスク評価値の総計を以下の式に代入して許容リ
スク値の補正係数を作成する。許容リスクレート補正係数＝（０．５＋（Σリスク評価値）×０．１２５）＝（０．５＋３×０．１２５）＝０．８７５そして次式により補正後の許容リスク値を算出する。補正後許容リスク値＝３５．３×０．８７５＝３１こうして算出した補正後許容リスク値と図６に示すアク
ティビティーのリスクレートを比較し、最終的に図７に
示すようなプロジェクト管理プロセス計画（テーラリン
グ指針）を作成することができる。

【００４２】[プロセスデータ編集部における処理］ま
た、プロセスデータ編集部１８では、以下の処理を行
う。（１）開発プロセスデータベース１７内のリスクデータ
の編集図８に、ＳＬＣＰ−ＪＣＦ９８と「実施」と「管理」の
マッピングイメージを示す。すなわち、ＳＬＣＰ−ＪＣ
Ｆ９８の定義するアクビティー中の一部タスクが、別の
タスクを管理する意味合いがある点に注目し、管理を目
的とするタスクとそれ以外を分類し、管理目的のタスク
に「管理」の水準を、それ以外に「実施」の水準を割り
当てる。開発管理データベース１９内のＳＬＣＰ−ＪＣＦ９８
で定義するアクティビティーに該当するデータ項目をマ
ッピングし、データ検索して有効データ数を計測する。計測結果を調査対象組織の全プロジェクト数で割った
パーセンテージを算出する。そして、図９に示す開発プロセスデータベース内のリ
スクデータイメージのように、データを工数、工期、開
発規模の各々について大きさで層別したグループに分割
し開発プロセスデータベース１７を作成する。（２）また、プロセスデータ編集部１８は見積りデータ
ベース１６内の見積りデータの編集を行う。すなわち、
開発管理データベース１９からプロジェクトの開発規
模、開発工数、開発工期とシステム機能規模を関連付け
たテーブルを作成する。

【００４３】［各見積り部における処理の説明］（１）開発規模見積り部１３における処理開発規模見積りデータに最小二乗法を用いて下記の様な
相関関数を導き、下記の式によってシステム機能規模か
ら開発規模を算出する。開発規模＝相関係数×システム
機能規模＋切片図１０に開発規模見積りデータの例を示
す。（２）工期見積り部１４における処理開発工期見積りデータに最小二乗法を用いて下記の様な
相関関数を導き、下記の式によってシステム機能規模か
ら開発工期を算出する。開発工期＝相関係数×システム
機能規模＋切片図１１に開発規模見積りデータの例を示
す。（３）工数見積り部１５における処理開発工数見積りデータに最小二乗法を用いて下記の様な
相関関数を導き、下記の式によってシステム機能規模か
ら開発工数を算出する。開発工数＝相関係数×システム
機能規模＋切片図１２に開発規模見積りデータの例を示
す。

【００４４】以上、本発明の実施の形態について説明し
たが、本発明は、上述の図示例にのみ限定されるもので
はなく、本発明の要旨を逸脱しない範囲内において種々
変更を加え得ることは勿論である。

【００４５】また、図１のテーラリングシステムを構成
する各部は専用のハードウエアにより実現されるもので
あってもよく、また、テーラリングシステムを構成する
各部の機能を実現するためのプログラムをコンピュータ
読み取り可能な記録媒体に記録して、この記録媒体に記
録されたプログラムをコンピュータシステムに読み込ま
せ、実行することによりテーラリングシステムの処理を
行ってもよい。なお、ここでいう「コンピュータシステ
ム」とは、ＯＳや周辺機器等のハードウェアを含むもの
とする。

【００４６】また、「コンピュータシステム」は、ＷＷ
Ｗシステムを利用している場合であれば、ホームページ
提供環境（あるいは表示環境）を含むものとする。ま
た、「コンピュータ読み取り可能な記録媒体」とは、フ
レキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−
ＲＯＭ等の可般媒体、コンピュータシステムに内蔵され
るハードディスク等の記憶装置のことをいう。さらに
「コンピュータ読み取り可能な記録媒体」とは、インタ
ーネット等のネットワークや電話回線等の通信回線を介
してプログラムを送信する場合の通信線のように、短時
間の間、動的にプログラムを保持するもの(伝送媒体な
いしは伝送波)、その場合のサーバやクライアントとな
るコンピュータシステム内部の揮発性メモリのように、
一定時間プログラムを保持しているものも含むものとす
る。また上記プログラムは、前述した機能の一部を実現
するためのものであっても良く、さらに前述した機能を
コンピュータシステムにすでに記録されているプログラ
ムとの組み合わせで実現できるもの、いわゆる差分ファ
イル（差分プログラム）であっても良い。

【００４７】［補足資料］本発明のテーラリングシステ
ムの背景思想を示す補足資料について説明する。この補
足資料の標題は「生産管理データ活用による開発プロセ
スのテーラリング指針構築について」である。なお、本
発明の実施の形態の項での説明と重複して説明される部
分もある。

【００４８】あらまし一般的に組織的なプロジェクト管
理プロセス定義は、コストやリスク管理の観点から、多
様なプロジェクトに適用することが前提となりがちであ
る。このため、開発計画時にプロジェクトの特性に合わ
せてプロジェクト管理プロセスをカスタマイズするのが
通例である。ところが、この作業は百戦錬磨のＰＭ（プ
ロジェクトマネージャ）にとっては腕の見せ所である
が、新米マネージャーには非常に辛い作業となる。そこ
で、我々は新米マネージャーの拠所とすべく生産管理デ
ータを活用することによって、プロジェクト管理プロセ
スをカスタマイズするためのガイドラインを作成した。
本論文においては我々が得たガイドラインの一部を紹介
すると共に検討過程をテーラリング指針の構築方法の一
例として提案する。

【００４９】１．はじめに開発への着手にあたりどの様なプロジェクト管理プロセ
スで作業を行うかの決定はマネージャーへの大きな悩み
となる。特に新規の開発で、過去に類似プロジェクトの
経験がないマネージャーには、この決定は非常に辛いも
のとなる。こうした折りに、プロジェクト管理プロセス
の管理ガイドラインが存在することはプロジェクトマネ
ージャーを大きく勇気づける。しかし、通常この様な管
理ガイドラインは組織の全プロジェクトを対象に作成さ
れていて、個別のプロジェクトにチューンされたもので
はない。このため、一般に小さなプロジェクトに対して
は重いプロジェクト管理プロセスとなりがちである。こ
のことがプロジェクトに管理ガイドラインを疎ませる大
きな要因となっていると考えられる。

【００５０】そこで、我々は新米マネージャーでもプロ
ジェクトの特性に合わせてプロジェクト管理プロセスの
テーラリングを独自に行うことが可能な基準の用意を目
指した。そして、この基準は無理な理想を押しつけるや
り方を避け、実際のプロジェクトの実情に留意する方針
とした。このため、過去の生産データがプロジェクトの
プロジェクト管理プロセスそのものであることを利用
し、プロジェクト管理プロセスとその出力である生産管
理データを関連付けて分析することによってより実践的
なテーラリング指針を作成する。

【００５１】２．生産管理データを用いたプロセスアセ
スメントＮＴＴコムウェアでは、プロジェクトは全社的な標準の
下で開発作業をすすめており、生産管理データによるプ
ロジェクト管理を制度化している。図１３にＮＴＴコム
ウェアにおける生産管理システムの概念図を示す。図１
３において、プロジェクトは、プロジェクト管理支援ツ
ール（ＣＯＭＳ−ＰＲＯ）のサポートによって生産管理
データを生産管理データベース（ＣＯＭＳ−ＩＮＦ）に
入力し管理業務へ活用する。また、生産管理データは、
プロジェクトが終了した後にもＤＢ（データベース）化
されて次期開発のための管理モデルや見積もり根拠とし
て活用される。このＤＢ化される内容は、開発計画、成
果物とマイルストーンのレビューや試験の計画と実績、
プロジェクト完了報告、そしてフィールド品質などのデ
ータが対象である。

【００５２】そして、我々は図１４に示す様に生産管理
データがプロセス活動の結果である点に注目し、各組織
のプロセスアセスメント手法を確立した。通常プロセス
アセスメントはプロジェクトや管理組織のキーマンに対
するインタビューによって進められる。このため、アセ
スメントはその対象組織の規模が大きければ大きいほど
多くの経営資源が必要となる。これは、例としてプロジ
ェクトに理解を得るための説明会開催、開発作業への影
響を最小限とするためのインタビュースケジュール作成
などの社内調整が挙げられる。また、実際インタビュー
を実施し、その後の結果集計や問題定義にも時間と工数
を要しフィードバックの即時性を失うと共に経費も嵩む
傾向がある。こうしたアセスメントの問題に対処するた
めに、我々は生産管理データを用いたプロジェクトに影
響を与えない、生産管理データによるセルフアセスメン
ト手法を確立した。ただし、本アセスメント方式は本格
的なインタビュー方式に比較すると表層的である点は否
めない。そこで、アセスメントの目的を下記の様に絞り
込んだものとした。・組織の全体像を映し出す。・継続的なマネジメントのコミットメントを生み出す。・プロセス改善計画作成時にアセスメント結果を有益な
情報源として利用する。

【００５３】３．プロセスアセスメント手法３．１評価モデルと評価水準我々が確立したセルフアセスメント手法は、基本的にＳ
ＰＡ（ＩＳＯ／ＩＥＣ１５５０４）を参考にした。た
だ、ＳＰＡの能力水準の５段階を開発管理データに適用
して評価するのは困難であった。そこで、現実的な水準
としてＳＰＡの能力水準をアレンジし図１５に示す３つ
の水準で評価を行った。そして我々は生産管理データを
図１５に示す能力水準で評価するためにＳＬＣＰ−ＪＣ
Ｆ９８を用いた。ＳＬＣＰ−ＪＣＦ９８は、１９９５年
に国際規格となったソフトウェアライフサイクルプロセ
ス（ＩＳＯ／ＩＥＣ１２２０７）で定義された作業項目
に日本のソフトウェア産業の特性を加えて独自に作成さ
れた共通フレームである。共通フレ−ムとは、システム
開発作業に関連する作業群を定義した二者間取引での共
通の物差しで、システム開発の作業範囲、作業内容など
を明確化したものである。なお、日本のソフトウェア産
業の特性として加えられた点は、対象範囲の拡大（企
画プロセス、システム監査プロセス）、タスク名称の
付与、作業項目の追加の３点である。

【００５４】実際の生産管理データと図１５に示す水準
とのマッピングには下記のルールを適用した。・ＳＬＣＰ−ＪＣＦ９８の定義するアクビティーと社内
作業標準中の定義を付き合わせて「定義」の水準を割り
当てる。・ＳＬＣＰ−ＪＣＦ９８の定義するアクビティー中の一
部タスクが、別のタスクを管理する意味合いがある点に
注目し、管理を目的とするタスクとそれ以外を分類し、
管理目的のタスクに「管理」の水準を、それ以外に「実
施」の水準を割り当てる。なお、図１６と図１７に実際
の割り当てイメージを示す。

【００５５】３．２評価基準プロセスの評価水準毎の評価基準を以下に示す。（１）「定義」の評価基準成果物の定義有無をアクビティーの有無に置き換えて評
価し、評価基準は有り無しの「０」、「１」判定を用い
る。（２）「実施」と「管理」の評価基準生産管理ＤＢ中の該当テーブルの該当データ項目を検索
し,有効データの有無によって評価する。そして、組織
としての評価は、検索の結果、有効データが登録されて
いるプロジェクト数を調査対象組織の全プロジェクト数
で割ったパーセンテージで評価を行う。

【００５６】３．３調査結果のイメージ調査結果は、効果的な状況把握の目的で図１８に示すプ
ロジェクト管理成熟度分析チャート（「ＰＭＭＡＣ」と
もいう）にまとめる。ＰＭＭＡＣは、プロジェクトの実
施状況をＳＬＣＰ−ＪＣＦ９８のアクティビティー毎に
評価したドーナツグラフを３重に表示した物である。グ
ラフの各々は図１６の水準に対応しており内側から定
義、実施、管理を示す。また、ドーナツグラフ内の円グ
ラフは外側のドーナツグラフと対応しており、区切られ
た区画はＳＬＣＰ−ＪＣＦ９８の定義によるプロセスを
示している。また、ドーナツグラフの区画内の数字はＳ
ＬＣＰ−ＪＣＦ９８のアクティビティーに付けられた項
番に対応している。なお、ＰＭＭＡＣの評価単位はアク
ティビティーであるが、アクティビティーは複数のタス
クで構成される。そこで、代表タスクを決定しアクティ
ビティーの評価結果には（２）で示したタスクの評価結
果をそのまま適用する。

【００５７】４．調査結果の実例４．１ＰＭＭＡＣによる分析結果図１９及び図２０は社内のＡ、Ｂ２つの組織に対して実
際に行った調査結果を、ＰＭＭＡＣ化したものである。
なお、表示はＳＬＣＰ−ＪＣＦ９８の主ライフサイクル
を対象とした。また、空欄は生産管理ＤＢに該当テーブ
ル定義が無かった物である。つまり、空欄は組織的なデ
ータ管理を行っていないことを示している。しかし、こ
れは戦略的な管理の結果の場合が考えられるため「空欄
＝悪」ではない。ただし、当該組織の管理実態を映す鏡
であり、次期管理システム開発のロードマップ作成への
活用が期待される。まず、Ａ、Ｂ両組織とも１．１取得
（注１）、１．２供給プロセスの実現度が高く全社的に
も実施が徹底している事が解る。一方、１．５保守、
１．６運用プロセスは、標準に定義はあるが実施、管理
で両者とも空欄が多く全社的な状況把握が弱いといえ
る。注１：数字はＳＬＣＰ−ＪＣＦ９８のプロセスに付けら
れた項番を示し、ＰＭＭＡＣ内部の円グラフの番号に一
致する。注２：ＰＭＭＡＣの区画の欠番はＳＬＣＰ−ＪＣＦ９８
が定義するアクティビティーに成果物定義が無いためで
ある。

【００５８】次に、組織Ａは、「実施」「管理」の実現
度は低いが、組織的なプロセス定義の網羅度がすばらし
い。そして、１．４開発プロセスについては、上流工程
の実現度が高く下流工程が低い傾向が見える。一方、組
織Ｂは、組織Ａに比較して「実施」「管理」の実現度は
高い。しかし、逆に組織的なタスク定義は弱い。そし
て、１．４開発プロセスについては、上流よりも下流の
実現度が高い傾向が見える。

【００５９】４．２ＰＭＭＡＣによる分析結果の考察まず、全社的な観点から、１．１取得プロセスが強いの
は、外注比率が高い会社の戦略を色濃く反映したものと
考えられる。次に、組織レベルに目を転じると、組織Ａ
は社内においても特に外注比率が高い特徴があり、上流
工程重視の傾向は、分析/設計に重点を置く組織の戦略
が確認できる。一方、組織Ｂの下流重視の傾向は、特殊
な試験環境が必要で、ＮＴＴコムウェア社内に実機試験
環境を用意するなど、試験によってソフトウェア品質を
確保しようとする組織の姿勢が確認できる結果である。
また、ＰＭＭＡＣのパターンから組織Ｂは、基本的なプ
ロセス活動が根付いていると考えられ、組織のプロセス
能力成熟度が高いと判断できる。このことから、組織Ａ
は、成熟度が低いのに開発プロセス定義を詳細に実施す
るトップ゜ダウン的な文化で、逆に組織Ｂは組織的な定
義よりプロジェクトの自主性を重んじるボトムアップ的
な文化と分析できる。

【００６０】一般にプロセス定義が曖昧な組織の場合、
明確なプロセス定義の推進を改善提案としがちである。
ところが、ＰＭＭＡＣの調査結果からプロセス定義が曖
昧なボトムアップ文化の方が実施レベルの実現度が高
く、トップダウン文化の方が実施レベルの実現度が曖昧
である事が分かる。そして、社内の別の調査からもトッ
プダウン文化の問題プロジェクト発生率が高いという報
告がある。つまり、ＰＭＭＡＣの結果は、安易なプロセ
ス定義よりもプロセス活動の定着を優先すべきであるこ
とを示唆している。これは、ＣＭＭが成熟度レベル３の
ＫＰＡで組織的な標準化を扱っている点を裏付ける結果
であり、興味深いものである。以上のようにＰＭＭＡＣ
は各組織のプロジェクト管理プロセスの状況を良く表し
ている。このことから、我々の確立したセルフアセスメ
ント手法は当初設定した目標に照らして有効性は十分で
あるといえる。

【００６１】５．戦略的プロジェクト管理プロセスの構
築５．１理想のプロジェクト管理プロセスこれまで示したとおり、我々は組織のプロジェクト管理
の状況を的確に映し出すことが可能となった。ただ、こ
こで問題になったのは、全社的なプロジェクト管理プロ
セス実施度の不条理な低さである。当初、我々は模範的
なプロジェクトが多い組織ＢではＣＭＭやＳＰＡがモデ
ルとしている様にプロジェクト管理プロセスを潔癖に実
施しているだろうと予測した。確かに組織Ａとの比較分
析により相対的にはこのモデルは肯定された。ところ
が、組織Ｂのプロジェクト管理プロセス実施度も絶対値
的には必ずしも高いとは言えず、潔癖なモデルに照らし
てプロセス能力成熟度が高い根拠とするにはやや妥当性
に問題がある。しかし、問題プロジェクトも少なく実質
的に成熟度が高いと考えられる組織Ｂの状況に矛盾して
いる。そこで、この原因として我々は次の様な仮説を立
てた。即ち、プロジェクトは既成の標準に潔癖に従うの
ではなく、その特性に応じ適切にプロジェクト管理プロ
セスを構築し、結果的にプロジェクト管理プロセスの実
施率が低下していると考えた。その根拠として以下の点
が上げられる。・いわゆる失敗プロジェクト数が少なく、プロセス能力
成熟度は高いと判断できる。・ＰＭＭＡＣによる分析結果から基本的なプロセス活動
自体は根付いている。・組織的な成果物定義やプロセス記述が曖昧なため、臨
機応変な効率的プロセス定義がやり易い。

【００６２】以上より、我々は組織Ｂのプロジェクト管
理プロセスを更に詳細に分析することによって、上記仮
説を検証し、戦略的なプロジェクト管理プロセスを構築
するためのテーラリング指針の作成を目指した。なお、
戦略的なプロジェクト管理プロセス構築とは、徒に潔癖
な管理プロセスを構築するのではなく、効果的でしかも
無駄のないプロジェクト管理プロセスの構築を意味して
いる。ところで、我々の活動は社内に限定した活動であ
り、ＳＬＣＰが定義している「２，支援ライフサイクル
プロセス」や「３，組織に関するライフサイクルプロセ
ス」といった全社的な活動に関しては基本的に組織間で
の変化はない。このため、これ以降プロセスの範囲を組
織間の調査データに変動が予想される「１．４開発プロ
セス」に限定して論ずることとする。また、前提として
調査対象として用いるプロジェクトは全て完了済みであ
り、いわゆる失敗プロジェクトは含めない。つまり、分
析対象は、所期の目的を果たした成功プロジェクトのプ
ロジェクト管理プロセスとする。

【００６３】５．２プロジェクト管理プロセスの分析分析対象は、前節で定義したとおりＳＬＣＰ−ＪＣＦ９
８が定義する１．４開発プロセスのアクティビティーと
する。図２８に分析対象の１．４開発プロセスを構成す
るアクティビティーとその項番を示す。そして、我々は
以下に示す手順によりプロジェクト管理プロセスの特徴
を分析した。プロジェクトをその属性値（工数、工期、開発規模）
で層別してグループ分けする。グループ分けしたプロジェクトに対して３章で論じた
方法によってプロセスデータを集計する。集計結果は、横軸に図２８に示すアクティビティー
を、そして縦軸の３．３節（２）で定義した各々の実施
率を取った折れ線グラフに表示する。

【００６４】なお、層別の基準は、最初に層別してでき
るグループ数を決め、グループ毎のプロジェクト数に大
きな開きが発生しないように水準値を決定した。ところ
で、我々はプロジェクト管理プロセスの実施状況を「実
施」と「管理」の２っの水準で把握したが、本論文にお
いては、紙面の都合によりプロジェクトの属性値とプロ
ジェクト管理プロセスの関係分析に「管理」の水準のみ
を扱うことにする。ただし、「実施」と「管理」の特徴
はほぼ等しいものであり分析結果は「管理」で代表可能
である。

【００６５】５．３プロジェクト管理プロセスの特徴（１）工数とプロジェクト管理プロセス図２１に組織Ｂのプロジェクト管理プロセス（管理）を
工数の大小で層別したグラフを示す。工数とプロジェク
ト管理プロセスとの関係分析の結果から以下に示す特徴
が見える。・全体的に工数が小さくなるに従いプロジェクト管理プ
ロセスを簡易化している傾向がある。・工数が大きくなるに従いグラフが平坦になり上流工程
重視の傾向がある。・工数が小さいプロジェクトほど製造工程のプロジェク
ト管理プロセスを簡易化している傾向がある。

【００６６】（２）工期とプロジェクト管理プロセス図２２に組織Ｂのプロジェクト管理プロセス（管理）を
工期の長短で層別したグラフを示す。工期とプロジェク
ト管理プロセスとの関係分析の結果から以下に示す特徴
が見える。・全体的に工期が短いプロジェクトほどプロジェクト管
理プロセスを簡易化している傾向がある。・工期が長いプロジェクトほどグラフが平坦になり上流
工程重視の傾向がある。・工期が短いプロジェクトほど製造工程のプロジェクト
管理プロセスを簡易化している傾向がある。

【００６７】（３）開発規模とプロジェクト管理プロセ
ス図２３に組織Ｂのプロジェクトのプロジェクト管理プロ
セス（管理）を開発規模の大小で層別したグラフを示
す。開発規模とプロジェクト管理プロセスとの関係分析
の結果から以下に示す特徴が見える。・全体的に開発規模が小さいプロジェクトほどプロジェ
クト管理プロセスを簡易化している傾向がある。・開発規模が大きいプロセスはより平坦なプロセスとな
っており、上流工程重視の傾向が見える。・開発規模が小さいプロジェクトほど製造工程のプロジ
ェクト管理プロセスを簡易化している傾向がある。

【００６８】５．４プロジェクト管理プロセスの把握結
果に対する考察プロジェクトの失敗リスクは一般にその規模が大きくな
るに従って増加すると言われる。そして、図２１〜図２
３に見られるとおりプロジェクトの規模に関連付けされ
る各プロジェクト属性値の増加に伴いプロジェクト管理
プロセスの実施率が増加している。

【００６９】これは、図２４に示すようにプロジェクト
が失敗リスクに対抗してプロジェクト管理プロセスの実
施率を増加した結果であると考えられ、プロジェクト管
理プロセスの実施率はプロジェクトのリスクと等価であ
ると考えられる。

【００７０】また、アクティビティーを省きプロジェク
ト管理プロセスを簡易化しているプロジェクトを含めて
調査対象は５．１節に示したとおり全て成功プロジェク
トである。つまり、アクティビティーを省きプロジェク
ト管理プロセスを簡略化したプロジェクトは、そのリス
クに見合った適正な管理プロセス構築したと考えられ
る。実際、大規模でリスクが大きいプロジェクトのプロ
ジェクト管理プロセスの実施率は高水準にあり、プロセ
ス能力成熟度の高さの根拠としても妥当性を帯びるもの
である。この結果、我々が当初設定した仮説は十分説明
されており、プロジェクトのリスクという特性に見合っ
たプロジェクト管理プロセスの構築が可能と考えられ
る。

【００７１】また、一般にプロセス能力成熟度が低い組
織は、いわゆる失敗プロジェクトが多い点で特徴づけら
れる。そして、ＣＭＭに代表されるプロセス能力成熟度
モデルはプロジェクト管理プロセスを構成するアクティ
ビティーのカバレージを拡大することによって成熟度が
向上すると定義している。しかし、本調査結果は失敗プ
ロジェクトを出すことなくプロジェクト管理プロセスを
構成するアクティビティーの削減が可能であることを示
した。このことから、対象組織のプロジェクトの特性に
よってはプロセス能力成熟の判断基準は変化して良いこ
とを示唆していると考えられる。即ち、コストダウンと
いう企業目標を考えた場合、プロジェクト特性によって
は工数増に繋がる徒に緻密な管理プロセス構築は必要な
いことを示唆していると考えられる。

【００７２】最後に、プロジェクトの各属性とプロジェ
クト管理プロセスのグラフは各々形状や全体的な実施率
が微妙に異なっている。５．２節で記述したとおり、層
別したグループのプロジェクト数は水準値を調整して大
まかではあるが一致させた。このため、もし属性間に深
い関連があって層別したグループのプロジェクトが同一
になるならば、プロジェクト管理プロセスは属性間で一
致するはずである。しかし、結果は一致しておらず、プ
ロジェクトの属性は各々独立であると判断できる。つま
り、プロジェクト管理プロセスが変わる要因として、プ
ロジェクト属性の単一の側面のみに注目すべきでなく、
複数の属性を総合的に判断すべきであると考えられる。

【００７３】５．５戦略的なプロジェクト管理プロセ
ス構築への応用開発プロジェクトにはリスクが付き物である。それに対
抗しプロジェクトを成功に導くには、プロジェクト管理
プロセスの強化が鍵であることに間違いはない。しか
し、プロジェクトのリスクを過大に評価し、過剰なプロ
ジェクト管理プロセスを構築するのは無用なオーバヘッ
ドコストの増大を招くことになり、結果として顧客満足
を得ることができない。すなわち、プロジェクトのリス
クに見合った適正なプロジェクト管理プロセスに標準プ
ロセスをテーラリングする必要があると考えられる。前
節の考察結果から、プロジェクト管理プロセス実施率は
プロジェクトのリスクの大きさを示す指標であると考え
られる。そして、図２１〜図２３で示したとおり、プロ
ジェクト管理プロセス実施率は、プロジェクトの属性値
の大きさに連動している。つまり、プロジェクト属性値
によって、プロジェクトのリスクを把握することができ
ると考えられる。一方、プロジェクトのリスクを把握
し、それに応じたプロセスを構築するため、図３に示す
ようにプロセスを簡易化しても良い許容リスク値の設定
を考える。そのためには、許容リスク値以下では確かに
プロジェクト管理プロセス実施率に差があることを示す
必要がある。そこで、統計的検定を用いて層別したグル
ープのプロセス実施率の差を証明し許容リスク値を求め
る。

【００７４】以上より、プロジェクト計画立案時を想定
したプロジェクト管理プロセスのテーラリング手順を以
下のとおり提案する。

【００７５】＜許容リスク値の設定＞５．２節〜に示した手順でアセスメント結果を編
集する。編集したアセスメント結果からプロセス実施率の平均
値が最大の層別グループのプロセスを基準プロセスとす
る。基準プロセスと他の層別グループのプロセスとの差を
検定するため、帰無仮説として「各々のグループ間でプ
ロセス実施率の平均値には差は無い」を設定する。プロセス実施率の平均値が高いグループから基準プロ
セスとの差異を検定し、帰無仮説が最初に棄却される層
別グループのプロセス実施率の平均値を許容リスク値と
する。

【００７６】＜テーラリング作業＞当該プロジェクトの各属性値（工数、工期、開発規
模）を見積もる。図２５に示すプロジェクト管理プロセス実施率表の値
をプロジェクトのリスクとみなし、見積りしたプロジェ
クト属性値が該当するデータ範囲のリスク値を決定す
る。当該プロジェクトの特性（メンバーのスキルや経験お
よび新技術の適用等）によって許容リスク値を補正す
る。工期、工数、規模で決定したリスク値のうちアクティ
ビティー毎にリスク値が最大のものを選択し、プロジェ
クトの許容リスク値と比較する。比較の結果、そのリスク値が許容リスク値を越えるア
クティビティーはプロジェクト管理プロセスに取り込
む。また、比較の結果、そのリスク値が許容リスク値以下
のアクティビティーは基本的にプロジェクト管理プロセ
スから外すことを推奨する。

【００７７】次に、プロジェクトの見積り結果を仮に２
５人月、３ヶ月、１８ｋｌとしてプロジェクト管理プロ
セス計画を作成する。

【００７８】＜許容リスクレートの設定＞まず、図２５
（ａ）に示す表からプロジェクト管理プロセス実施率の
平均値が最大の５００人月以上の層別グループを基準プ
ロセスとする。そして、基準プロセスとそれ以外の層別
グループのプロジェクト管理プロセス実施率の平均値
を、帰無仮説に「各々のグループ間でプロセス実施率の
平均値に差はない」とおいて、ｔ検定を用いて統計的に
検定する。この検定は、プロジェクト管理プロセス実施
率の平均値で降順に層別グループを選んで行う。なお、
検定における有意差にはここでは１％を用いることにす
る。この結果、最初に有意差ありとして帰無仮説が棄却
される２０〜６０人月の層別グループのプロジェクト管
理プロセス実施率の平均である３５．３％を許容リスク
値（工数）とする。以下同様に、開発規模、工期の許容
リスク値を算出し、最終的に値が最低のものを許容リス
ク値として設定する。ここでは、工数の許容リスク値が
最低であるとして３５．３％を許容リスク値に設定す
る。

【００７９】＜テーラリング作業＞まず、図２５（ａ）
に示すプロジェクト管理プロセス実施率表（工数）から
工数のリスクレートを選択する。この場合、見積り値は
２５人月なので、データ範囲２０〜６０のリスクレート
を決定する。同様に、図２５（ｂ）に示す規模、図２５
（ｃ）に示す工期のリスクレートを決定し、アクティビ
ティー毎にリスクレートが最大なものを選択し図２６に
示すリスクレートの表を得る。なお、図２５〜図２７に
おけるアクティビティーとは、ＳＬＣＰ−ＪＣＦ９８の
アクティビティー番号を示す。

【００８０】＜リスク演算部の許容リスク値の補正＞次
に、プロジェクトの特性からプロジェクトの許容リスク
レートを補正する。状況から判断したプロジェクトの特
性は以下の通りである。（ア）メンバーのスキルは非常に高い。（イ）要求仕様の確度は中程度（ウ）納期の厳しさは低い（エ）品質の与える影響は高いこの特性を下記の表に適用してリスク評価値を決定す
る。

【表３】次に、リスク評価値の総計を以下の式に代入して許容リ
スク値の補正係数を作成する。許容リスクレート補正係数＝（０．５＋（Σリスク評価値）×０．１２５）＝（０．５＋３×０．１２５）＝０．８７５そして次式により補正後の許容リスク値を算出する。補正後許容リスク値＝３５．３×０．８７５＝３１

【００８１】こうして算出した補正後許容リスク値と図
６に示すアクティビティーのリスクレートを比較し、最
終的に図２７に示すようなプロジェクト管理プロセス計
画（テーラリング指針）を作成することができる。

【００８２】６．まとめ６.１生産管理データを用いた効率的なセルフアセスメ
ント手法の確立我々は、ＳＬＣＰ−ＪＣＦ９８と生産管理データを用い
た独自のセルフアセスメント方式を確立し、その有効性
を確認した。我々が提案する手法は、完璧なアセスメン
トを目的としたものではないが、少ない経営資源によっ
て実施可能でしかもアセスメントの基本機能は満足して
いることが確認できた。この我々が実施した活動は、作
業標準や生産管理データが整備されている別組織におい
ても適用が可能である。その意味で我々は、ここに報告
した手順によって、効率的なセルフアセスメントの手法
が提案できたと考える。また、このセルフアセスメント
方式は生産管理データのデータ内容には言及せずデータ
の有無にのみ注目することにより、これまではサンプル
外とした低精度のデータや、データの欠損さえも情報と
しての活用を可能としデータの有効活用を実現した。

【００８３】６．２セルフアセスメント結果の有効活用我々は、提案したセルフアセスメント方式の実践により
収集した情報分析結果から、プロジェクトのリスクに応
じた適正なプロジェクト管理プロセスの構築が可能であ
ることを報告した。そして、この考えに従いプロセス能
力成熟度の判断基準は、プロジェクト管理プロセスを構
成するアクティビティーのカバレージという画一なもの
ではなくプロジェクト特性によって変わり得ることを主
張した。すなわち、コストダウンという企業目標を考え
た場合、アセスメントモデルを盲信し工数増に繋がる徒
に緻密な管理プロセス構築は必要ないと考えられる。こ
の提案によって、我々のセルフアセスメント方式はより
実践的で競争力のある改善提案を導くと考えられる。

【００８４】６．３プロジェクトによるプロジェクト管
理プロセスのテーラリング指針我々は、プロジェクトのリスクによるプロジェクト管理
プロセスのテーラリング指針を作成し、プロジェクトマ
ネージャのプロジェクト計画作成を支援した。この結果
は、全ての組織に適用できる結果ではないが、少なくと
も被調査組織内における現実的なテーラリング指針とな
り得るし、分析方法は組織を選ばないと考えられる。そ
うした意味で、我々は戦略的なプロジェクト管理プロセ
ス構築に向けたテーラリング指針作成の手法を提案出来
たと考える。

【００８５】

【発明の効果】以上説明したように、本発明の開発プロ
セスのテーラリングシステム及びテーラリング方法にお
いては、標準開発プロセスのアクティビティー毎のリス
クデータと、リスク根拠となる入力データを基に、許容
リスクレートを決定し、この許容リスクレートを基に、
標準開発プロセスを構成する各アクティビティー毎に、
プロジェクト管理プロセスに取り込むか否かを決定する
ようにしたので、これにより、従来、テーラリング技術
は属人的なノウハウであり、ノウハウのない人間には不
可能な作業であったが、本発明の本テーラリングシステ
ムを用いることによって経験の浅い間でも適正なテーラ
リングを行うことができ、均質な作業レベルが確保でき
る。

【００８６】また、本発明の開発プロセスのテーラリン
グシステム及びテーラリング方法においては、標準開発
プロセスのアクティビティー毎のリスクデータが、過去
に実施されたプロジェクトにおけるプロジェクト管理プ
ロセスの実施率を基に算定されるようにしたので、これ
により、過去の実績に基づいた適正なテーラリングを行
うことができる。

【００８７】また、本発明の開発プロセスのテーラリン
グシステム及びテーラリング方法においては、前記リス
ク根拠には、少なくともプロジェクトメンバーのスキ
ル、経験、及び新技術の適用の要素が含まれるようにし
たので、これにより、プロジェクトを構成するメンバー
の実情に即して、適正なテーラリングを行うことができ
る。

【００８８】また、本発明の開発プロセスのテーラリン
グシステム及びテーラリング方法においては、許容リス
クレートを求める際には、各アクティビティーについ
て、プロジェクトの工期、工数、規模ごとに許容リスク
レートを求め、さらに工期、工数、規模ごとに求めた許
容リスクレート中の最大の許容リスクレートを、当該ア
クティビティーの許容リスクレートとして決定するよう
にしたので、これにより、工期、工数、規模に応じた適
正なテーラリングを行うことができる。

【図面の簡単な説明】

【図１】本発明によるテーラリングシステムの概要を
説明するための図である。

【図２】開発プロセス内のプロセス実施率のデータイ
メージを示す図である。

【図３】許容リスクの補正について説明するための図
である。

【図４】テーラリング手順の処理フローを示す図であ
る。

【図５】開発プロセスデータベース内のリスクデータ
の例を示す図である。

【図６】アクティビティー毎のリスクレートの例を示
す図である。

【図７】得られるテーラリング指針の例を示す図であ
る。

【図８】ＳＬＣＰ−ＪＣＦ９８と「実施」と「管理」
のマッピングイメージを示す図である。

【図９】開発プロセスデータベース内のリスクデータ
イメージを示す図である。

【図１０】開発規模見積りデータの例を示す図であ
る。

【図１１】開発工期見積りデータの例を示す図であ
る。

【図１２】開発工数見積りデータの例を示す図であ
る。

【図１３】生産管理システムの概念図を示す図であ
る。

【図１４】生産管理データによるプロセスアセスメン
トの概念を示す図である。

【図１５】プロセス評価の水準を示す図である。

【図１６】ＳＬＣＰ−ＪＣＦ９８と「定義」のマッピ
ングイメージを示す図である。

【図１７】ＳＬＣＰ−ＪＣＦ９８と「定義」と「定
義」のマッピングイメージを示す図である。

【図１８】プロジェクト管理成熟度分析チャート（Ｐ
ＭＭＡＣ）の例を示す図である。

【図１９】組織Ａの調査結果のＰＭＭＡＣを示す図で
ある。

【図２０】組織Ｂの調査結果のＰＭＭＡＣを示す図で
ある。

【図２１】工数とプロセス管理プロセスとの関係を示
す図である。

【図２２】工期とプロセス管理プロセスとの関係を示
す図である。

【図２３】規模とプロセス管理プロセスとの関係を示
す図である。

【図２４】開発規模とプロジェクトのリスクの関係を
示す図である。

【図２５】リスクデータの例を示す図である。

【図２６】アクティビティー毎のリスクレートの例を
示す図である。

【図２７】テーラリング指針の例を示す図である。

【図２８】ＳＬＣＰ−ＪＣＦ９８が定義する１．４開
発プロセスのアクティビティーを示す図である。

【図２９】回帰関数と散布図の例を示す図である。

【符号の説明】

１テーラリングシステム１１リスク演算部１２テーラリング部１３開発規模見積り部１４工期見積り部１５工数見積り部１６見積りデータベース１７開発プロセスデータベース１８プロセスデータ編集部１９開発管理データベース

Claims

【特許請求の範囲】

【請求項１】開発リスクにより開発プロセスのテーラ
リングを行う開発プロセスのテーラリングシステムであ
って、対象となるプロジェクトの標準開発プロセスを登録した
開発管理データベースと、標準開発プロセスのアクティビティー毎のリスクデータ
を登録した開発プロセスデータベースと、見積り根拠となる入力データからプロジェクトの属性値
（少なくとも工期、工数、規模を含む）を見積るプロジ
ェクト属性見積手段と、前記標準開発プロセスのアクティビティー毎のリスクデ
ータと、リスク根拠となる入力データを基に、許容リス
クレートを決定するための手段と、前記許容リスクレートを基に、標準開発プロセスを構成
する各アクティビティー毎に、プロジェクト管理プロセ
スに取り込むか否かを決定するテーラリング手段とを具
備することを特徴とする開発プロセスのテーラリングシ
ステム。
【請求項２】前記標準開発プロセスのアクティビティ
ー毎のリスクデータが、過去に実施されたプロジェクト
におけるプロジェクト管理プロセスの実施率を基に算定
される手段をさらに具備することを特徴とする請求項１
記載の開発プロセスのテーラリングシステム。
【請求項３】前記リスク根拠には、少なくともプロジ
ェクトメンバーのスキル、経験、及び新技術の適用の要
素が含まれることを特徴とする請求項１または請求項２
に記載の開発プロセスのテーラリングシステム。
【請求項４】前記許容リスクレートを求める際には、
各アクティビティーについて、プロジェクトの工期、工
数、規模ごとに許容リスクレートを求める手段と、前記工期、工数、規模ごとに求めた許容リスクレート中
の最大の許容リスクレートを、当該アクティビティーの
許容リスクレートとして決定する手段とをさらに具備す
ることを特徴とする請求項１から請求項３のいずれかに
記載の開発プロセスのテーラリングシステム。
【請求項５】開発リスクにより開発プロセスのテーラ
リングを行う開発プロセスのテーラリング方法であっ
て、対象となるプロジェクトの標準開発プロセスを開発管理
データベースに登録する手順と、標準開発プロセスのアクティビティー毎のリスクデータ
を開発プロセスデータベースに登録する手順と、見積り根拠となる入力データからプロジェクトの属性値
（少なくとも工期、工数、規模を含む）を見積るプロジ
ェクト属性見積手順と、前記標準開発プロセスのアクティビティー毎のリスクデ
ータと、リスク根拠となる入力データを基に、許容リス
クレートを決定するための手順と、前記許容リスクレートを基に、標準開発プロセスを構成
する各アクティビティー毎に、プロジェクト管理プロセ
スに取り込むか否かを決定するテーラリング手順とを含
むことを特徴とする開発プロセスのテーラリング方法。
【請求項６】前記標準開発プロセスのアクティビティ
ー毎のリスクデータが、過去に実施されたプロジェクト
におけるプロジェクト管理プロセスの実施率を基に算定
される手順をさらに含むことを特徴とする請求項５記載
の開発プロセスのテーラリング方法。
【請求項７】前記リスク根拠には、少なくともプロジ
ェクトメンバーのスキル、経験、及び新技術の適用の要
素が含まれることを特徴とする請求項５または請求項６
に記載の開発プロセスのテーラリング方法。
【請求項８】前記許容リスクレートを求める際には、
各アクティビティーについて、プロジェクトの工期、工
数、規模ごとに許容リスクレートを求める手順と、前記工期、工数、規模ごとに求めた許容リスクレート中
の最大の許容リスクレートを、当該アクティビティーの
許容リスクレートとして決定する手順とをさらに含むこ
とを特徴とする請求項５から請求項７のいずれかに記載
の開発プロセスのテーラリング方法。
【請求項９】開発リスクにより開発プロセスのテーラ
リングを行う開発プロセスのテーラリングシステム内の
コンピュータに、対象となるプロジェクトの標準開発プロセスを開発管理
データベースに登録する手順と、標準開発プロセスのアクティビティー毎のリスクデータ
を開発プロセスデータベースに登録する手順と、見積り根拠となる入力データからプロジェクトの属性値
を見積るプロジェクト属性見積手順と、前記標準開発プロセスのアクティビティー毎のリスクデ
ータと、リスク根拠となる入力データを基に、許容リス
クレートを決定するための手順と、前記許容リスクレートを基に、標準開発プロセスを構成
する各アクティビティー毎に、プロジェクト管理プロセ
スに取り込むか否かを決定するテーラリング手順とを実
行させるためのプログラムを記録したコンピュータ読み
取り可能な記録媒体。
【請求項１０】開発リスクにより開発プロセスのテー
ラリングを行う開発プロセスのテーラリングシステム内
のコンピュータに、対象となるプロジェクトの標準開発プロセスを開発管理
データベースに登録する手順と、標準開発プロセスのアクティビティー毎のリスクデータ
を開発プロセスデータベースに登録する手順と、見積り根拠となる入力データからプロジェクトの属性値
を見積るプロジェクト属性見積手順と、前記標準開発プロセスのアクティビティー毎のリスクデ
ータと、リスク根拠となる入力データを基に、許容リス
クレートを決定するための手順と、前記許容リスクレートを基に、標準開発プロセスを構成
する各アクティビティー毎に、プロジェクト管理プロセ
スに取り込むか否かを決定するテーラリング手順とを実
行させるためのプログラム。