システム開発プロジェクトリスクの確率的評価に関する研究

Copyrightⓒ2014 Biomedical Fuzzy Systems Association

[Original article]

（2014 年 月 日 Accepted）

シ

シス

ステ

テム

ム開

開発

発プ

プロ

ロジ

ジェ

ェク

クト

トリ

リス

スク

クの

の確

確率

率的

的評

評価

価に

に関

関す

する

る研

研究

究

持

持田

田

信

信冶

冶

１１ １）流通科学大学 商学部 経営学科 要 要約約：： ビジネスシステム構築迅速化のために確実なプロジェクトマネジメントが求められ ている。しかし顧客からの要求仕様やプロジェクトの実行環境には不確実な要因や主観的な 要因があり遅延を引き起こす。特に、曖昧な内容を含む要求仕様は費用超過や納期遅延の原 因となる。そこで本研究は顧客が提示する要求仕様中の不確実要因を明らかにするためにコ ストシェアレートを提案する。コストシェアレートとはある要求仕様実現に必要な費用が開 発費用全体に占める費用割合のことであり、コストシェアレートは要求仕様の重要性を反映 する。更に本研究はプロジェクト中の不確実要因に起因する遅延を予測するために、ベイジ アンネットワークを用いた確率的手法を提案する。そして本研究はコストシェアレートとベ イジアンネットワークを用いたプロジェクトリスク予測ツールの開発を行い、予測ツールを 使用してプロジェクト環境の違いによるプロジェクトリスクを予測した。その結果、予測ツ ールの結果は実際のプロジェクトの実行状況に合うことが示され、本手法の有効性が示され た。今後、本手法の展開により確実なプロジェクトマネジメントの実現と顧客との友好な関 係の構築が期待できる。 キ キーーワワーードド：：リスク分析，システム開発プロジェクト，要求書分析，ベイジアン推定

A Study of probabilistic risk Evaluation for System Development Project

Shinji MOCHIDA

1

1) Faculty of Commerce University of Marketing and Distribution Sciences Kobe, Japan

Abstract: In order to build a business system quickly, more efficient project management is needed. However,

uncertain and subjective factors in requirements from customer cause cost overruns or schedule delays in the project. Furthermore, uncertain and subjective factors can lead to misunderstandings and false estimates when converting requirements into specifications or scheduling within a project. Thus this paper proposes cost share rate and probabilistic risk evaluation method with Bayesian estimation for project management to accurately assess the project risk. Cost share rate is defined as the percentage of total cost assigned to each requirement. This paper proposes cost share rate to evaluate risks of requirements. Also the attention must be paid to the fact that here are plus risks and minus risks in project and that the estimation usually takes only minus risks into account. In addition, the estimation has subjective factors, for example productivity and skills of the programmer. Thus this paper did the research using the cost share rate and Bayesian estimation to predict costs and show the potential for project risk management. If this method would work well, efficient project management would be able to realize and there would be better relationships between customers and system developers.

Keywords: Risk Evaluation, System Development Project, Requirements Analysis, Bayesian estimation

Shinji MOCHIDA

3-1, Gakuen-Nishimachi, Nishiku, Kobe, Japan, 651-2188 Phone + 81-78-796-4977

e-mail: [email protected]

47 （2020 年 4 月 10 日 Accepted）

2

1. は

はじ

じめ

めに

に

ビジネスシステムの迅速に構築のために、確実なプロ ジェクトマネジメントが求められている。以降ビジネス システム構築プロジェクトを単にプロジェクトと呼ぶ。。 しかしプロジェクトには不確実な要因があり、不確実な 要因はプロジェクト遅延を引き起こし、予算超過となる。 従ってプロジェクトマネジメントはリスクを全て費用 に換算して対応の優先順位をつける、ところが、一般的 なプロジェクトマネジメントでは図 1 に示す様に全行 程が終了すると予算も終了する前提で計画を行うため、 実際の作業進捗と費用消化状況は連動していない。従っ て、図 1 に示す計画を用いてプロジェクトをマネジメン トすることは困難である。そこで、作業の進捗を金銭的 価値に換算して、消化した費用と比較することにより作 業の進捗をマネジメントしようとするEVM(Earned Value Management）がある[1]。EVM でのバリューとは作業の 進捗により得られた出来高を費用換算したものであり、 EVM では進捗を既に獲得したバリューで評価する。図 2 に筆者が過去にプロジェクトマネージャーとして参加 したプロジェクトにおける費用消化率とEVM の関係を 示す。図 2 が示す様にバリューを計測できるのは内作を 行う設計費だけであり、外注費についてはバリューの測 定はできない。しかも先行的に導入した設備費用のバリ ューの計測はできず、消化した費用と実際に得たバリュ ーには乖離がある[2][3]。しかも後行程で欠陥が発見され た場合、既に得られたバリューが減ることになり、EVM による正確なプロジェクトの進捗管理は困難である。 図 1 プロジェクトマネジメントに於ける予算と行程

2. プ

プロ

ロジ

ジェ

ェク

クト

ト中

中の

の不

不確

確実

実要

要因

因

表 1 に示す様にプロジェクトの計画と実行には不確 実な要因が存在する。例えば、不確実な要因の１つに要 求仕様の精度がある。要求仕様の精度とは仕様に内在す る改定の可能性であり、仕様改定は設計変更とシステム 変更となり、行程遅延や費用超過を引き起こす。そして、 要求の仕様の精度は見積もり精度を左右して、リスクが 発現して予算超過となる。予算超過となる理由は不適切 な見積もりは無理な計画となり、リスクが発現して結果 的に納期や品質を確保できないからである。加えて、新 技術の導入やプロジェクトマネージャーやプログラマ ーのスキルもプロジェクトリスク発現要因となる。一方、 開発要員の高いスキルや類似システムの開発経験はプ ラスリスクであり、費用低減の可能性を高める不確実要 因である。プロジェクトの遂行を不確実する要因がプロ ジェクトリスクであり、ISO31000(International Organiza-tion for StandardizaOrganiza-tion)では、リスクとはプロジェクトの実 行を不確実にする要因であり、リスクにはプラスとマイ ナスが存在するとされている_{[4][5]（表 1 参照）。以降プ} ロジェクトリスクを単にリスクと呼ぶ。そこで、本研究 ではプロジェクトにおける不確実要因とリスクの関係 を考慮した確率的プロジェクトリスク評価手法を提案 する。具体的にはプロジェクト中に存在するプラスとマ イナスのリスク（表 1 参照）をベイジアンネットワーク に表現してプロジェクトリスクを予測する手法である。 図 2 EVM によるプロジェクトマネジメントの実際 表 1 プロジェクト中のリスクの種類 48

1. は

はじ

じめ

めに

に

ビジネスシステムの迅速に構築のために、確実なプロ ジェクトマネジメントが求められている。以降ビジネス システム構築プロジェクトを単にプロジェクトと呼ぶ。。 しかしプロジェクトには不確実な要因があり、不確実な 要因はプロジェクト遅延を引き起こし、予算超過となる。 従ってプロジェクトマネジメントはリスクを全て費用 に換算して対応の優先順位をつける、ところが、一般的 なプロジェクトマネジメントでは図 1 に示す様に全行 程が終了すると予算も終了する前提で計画を行うため、 実際の作業進捗と費用消化状況は連動していない。従っ て、図 1 に示す計画を用いてプロジェクトをマネジメン トすることは困難である。そこで、作業の進捗を金銭的 価値に換算して、消化した費用と比較することにより作 業の進捗をマネジメントしようとするEVM(Earned Value Management）がある[1]。EVM でのバリューとは作業の 進捗により得られた出来高を費用換算したものであり、 EVM では進捗を既に獲得したバリューで評価する。図 2 に筆者が過去にプロジェクトマネージャーとして参加 したプロジェクトにおける費用消化率とEVM の関係を 示す。図 2 が示す様にバリューを計測できるのは内作を 行う設計費だけであり、外注費についてはバリューの測 定はできない。しかも先行的に導入した設備費用のバリ ューの計測はできず、消化した費用と実際に得たバリュ ーには乖離がある[2][3]。しかも後行程で欠陥が発見され た場合、既に得られたバリューが減ることになり、EVM による正確なプロジェクトの進捗管理は困難である。 図 1 プロジェクトマネジメントに於ける予算と行程

2. プ

プロ

ロジ

ジェ

ェク

クト

ト中

中の

の不

不確

確実

実要

要因

因

表 1 に示す様にプロジェクトの計画と実行には不確 実な要因が存在する。例えば、不確実な要因の１つに要 求仕様の精度がある。要求仕様の精度とは仕様に内在す る改定の可能性であり、仕様改定は設計変更とシステム 変更となり、行程遅延や費用超過を引き起こす。そして、 要求の仕様の精度は見積もり精度を左右して、リスクが 発現して予算超過となる。予算超過となる理由は不適切 な見積もりは無理な計画となり、リスクが発現して結果 的に納期や品質を確保できないからである。加えて、新 技術の導入やプロジェクトマネージャーやプログラマ ーのスキルもプロジェクトリスク発現要因となる。一方、 開発要員の高いスキルや類似システムの開発経験はプ ラスリスクであり、費用低減の可能性を高める不確実要 因である。プロジェクトの遂行を不確実する要因がプロ ジェクトリスクであり、ISO31000(International Organiza-tion for StandardizaOrganiza-tion)では、リスクとはプロジェクトの実 行を不確実にする要因であり、リスクにはプラスとマイ ナスが存在するとされている_{[4][5]（表 1 参照）。以降プ} ロジェクトリスクを単にリスクと呼ぶ。そこで、本研究 ではプロジェクトにおける不確実要因とリスクの関係 を考慮した確率的プロジェクトリスク評価手法を提案 する。具体的にはプロジェクト中に存在するプラスとマ イナスのリスク（表 1 参照）をベイジアンネットワーク に表現してプロジェクトリスクを予測する手法である。 図 2 EVM によるプロジェクトマネジメントの実際 表 1 プロジェクト中のリスクの種類 3. 研研究究背背景景とと本本研研究究のの特特徴徴 従来のプロジェクトマネジメントに関する研究は費 用見積もりの精度向上や生産性向上に関する研究であ った[6] [7]。あるいは機械設計に於ける仕様の改定回数を 予測する研究であった[8]。しかし、プロジェクト中の不 確実要因に着目したリスクマネジメントに関するもの はない。例えば、プロジェクトに於ける不確実な要因に は顧客からの要求仕様中の曖昧な点や、プロジェクトに 従事するプロジェクトマネージャーやプログラマーの スキルがあり、プロジェクトの予算には不確実要因に対 する予備費として10％から 20％の費用を積み上げる、 しかしこの予備費の内訳を科学的に分析しようとする 研究はない。一方、従来のプロジェクトにおける見積も り方法としてCOCOMO 法やファンクションポイント法 があり、従来の手法では不確実な要因を幾つかの係数で 表現する。例えば、COCOMO 法では補正係数である[1]。 そこで、本研究ではまず、要求仕様の精度とプロジェク ト費用の関係について述べ、次にプロジェクト中の不確 実要因をベイジアンネットワークで表現してプロジェ クトの遅延確率を取得することを提案する。これまでに 顧客要求仕様の精度を始めとするプロジェク中の不確 実要因とプロジェクトリスクの関係について分析した 研究は無い。

4

4.

.

プ

プロ

ロジ

ジェ

ェク

クト

トリ

リス

スク

クと

と不

不確

確実

実要

要因

因

４．１ コストシェアレート 重要度の高い要求仕様の度重なる変更は予算超過や 納期遅延を引き起こす。そこで、本研究では要求仕様の 重要度を評価するためにコストシェアレートを提案す る。コストシェアレートとは各要求仕様の実現に必要な 費用が総費用に占める割合のことである。式(1)に費用と コストシェアレートの関係を示す。式(1)のコストシェア レート(Sri )はi 番目の要求仕様実現に必費用が総費用(C) に占める割合のことであり、i 番目の要求仕様実現に必 要な費用がCri である。 従って大きなコストシェアレー トを持つ要求仕様は大きな開発費用を必要とするため、 システム開発における重要度が高いことになる。 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖 = 𝐶𝐶𝐶𝐶 × 𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖 (1) Cri：i 番目の要求仕様実現に必要な費用 C：プロジェクト構築のための総費用 Sri：i 番目の要求仕様のコストシェアレート 一般的に、プロジェクトの費用見積もりは、システム構 築工数や開発の難易度に基づいて算出を行い、要求仕様 別の費用は算出されないため、算出された総費用は顧客 のシステムイメージと乖離しており、後の仕様変更の原 因となる。例えば、複雑な画面展開は多くの費用を必要 とするにも拘わらず、顧客には費用の必要性が認識され ないため、多くの場合において、後に費用低減のために 画面の簡易化や画面数の削減が発生して仕様変更とな る。加えて、顧客にはベンダーが設定した費用分類によ って費用が提示され、顧客が提示した要求仕様と費用分 類が紐づけされていないため、後に仕様変更が発生する 原因となる。ベンダーが設定した費用分類とは、例えば 設計、開発、試験、インストール、打ち合せ、書類作成 である。そこで、プロジェクトリスク低減を図るために、 仕様別のコストシェアレートを算出してリスクを可視 化することを提案する。リスクの可視化ができれば、リ スクの低減が期待できる。コストシェアレートの大きい 仕様に内在する曖昧さはプロジェクトリスクを高める。 図 図 3 に過去のプロジェクトにおける開発費用をコスト シェアレート表示した例を示す。図図 3 の横軸は顧客から の要求仕様NO.を示し、縦軸は要求仕様のコストシェア レート(%)である。 図 3 コストシェアレート（見積もり費用分類に基づく） ４．２ 要求仕様中の不確実要因とリスク プロジェクトを計画通りに終えるためには正確な見 積もりが必要となる。しかしプロジェクトには表 1 に示 す様にマイナスとプラスのリスクがあり、リスクの正確 な評価が見積もり精度を左右する。表 2 のリスク値は過 去のあるプロジェクトについて３人のプロジェクトス タッフから得た主観的な値であり、要求仕様が属する分 類別のリスクの大きさを示している。リスクの大きさは 対応費の確保割合で示されており、曖昧性や不確実性を

4 反映している。表 2 中のリスク値は当初費用に上乗せす る予備費の割合であり、例えばスタッフ１は設計分類に 属する仕様には_{20％の予備費が必要であると回答して} いる。本論文ではプロジェクト実行に必要な費用を当初 費用と呼び、リスク対応費を含めた費用を総費用又は単 に費用と呼ぶ、またリスク対応費を単にリスクと呼ぶ。 表 2 中のリスク値の大きい要求仕様分類は精度が低い、 又は実現の難易度が高い要求仕様を含む分類であるこ とを示す。そして表 2 の合計は金銭的損失に換算したリ スクへの対応費であり、リスク対応費は当初費用の20％ となることを示している。20％のリスク対応費は、一般 的なプロジェクトにおけるリスク対策費と等しい。例え ば、一般的なプロジェクトではコンテンジェンシー予備 費として当初費用の_{10％を確保する、加えてマネジメン} ト予備費として当初費用の数％を加えた、合計費として、 当初費用の約_{20％をリスク対策費として計画する。つま} り本結果は一般的なプロジェクトではリスク対応費と して当初費用の 20％をリスク対策費として確保する根 拠を与える。図 4 は図 3 に示したコストシェアレート にリスクを追加表示している。リスクはコストシェアレ ートに変換されている。式（2）はi 番目の要求仕様実現 に必要なコストシェアレートの算出方法を示しており、 要求仕様実現に必要なコストシェアレート(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_{𝑖𝑖𝑖𝑖} )は各 要求仕様中のアイテム別のコストシェアレート(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_{𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖} ) にアイテム別の遅延確率を含む費用割合(𝑅𝑅𝑅𝑅𝐶𝐶𝐶𝐶_{𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖} )を掛け合 わせた合計である。アイテムとは設計、開発、試験、打 ち合せ、インストール、書類作成であり、それぞれのア イテム別のリスクは表 2 のリスク値の平均を使用して いる。従って、図 _{4 が示す様に各要求仕様が持つリスク} のコストシェアレートを予測できれば、正確な費用の算 出が可能となる。本手法はまずプロジェクトの当初費用 が与えられることが前提であり、本手法は要求仕様別の リスク分析を提供する。本手法を用いて、当初費用の見 直しとリスクを含めた総費用の算出を繰り返すことに より手戻りが生じない適切なプロジェクトの計画が可 能となる。仕様の変更は手戻りと遅延につながり、無駄 な費用を必要とする。そこで、本手法により仕様の精度 向上が達成されれば、適切な費用計画が実現する。 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖= �𝑚𝑚𝑚𝑚_{𝑖𝑖𝑖𝑖=1}(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖× 𝑅𝑅𝑅𝑅𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖) (2) 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖：i 番目の要求仕様実現に必要なリスクを含む費用 をコストシェアレート表示したもの 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 ：i 番目の要求仕様中のｎ番目のアイテムの費用を コストシェアレート表示したもの 𝑅𝑅𝑅𝑅𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 ：i 番目の要求仕様中ｎ番目のアイテムの遅延確率 を含む費用割合 表 2 要求仕様分類別のリスク対応費の確保の割合 図 4 リスク込みのコストシェアレート ４．３ 要求仕様分析とコストシェアレート 表 2 に示したリスク値つまり、要求仕様別のリスク対 応費の確保割合はスタッフから得た値であった。しかし 言語的な要求仕様分析から要求仕様別のリスク値を得 ることができれば、コストシェアレートの自動計算が期 待できる。更に図 4 に示す様にプロジェクトの費用を要 求仕様別に分析して可視化できれば精度の低い要求仕 様を見直すことが可能となり、精度の高い費用算出が可 能となる。そこで、要求仕様分析からコストシェアレー トを算出する手法を提案する。以下に、ある過去のプロ ジェクトからコストシェアレートを算出する手順を示 す[9]。本例では i 番目の要求仕様のリスクを含まないコ ストシェアレート(Cri)の予測を行う。 （１） 要求仕様からのキーワード抽出 本ステップでは要求仕様を英語に翻訳して言語解析 を行い、キーワードを抽出する。図 _{5 に例を示す。要求} 仕様を翻訳する理由は英語では、文が分かち書きされて いるため、形態素解析が正確に行えるからである。次に 仕様区分 リスク値＊ ( スタッフ1) リスク値 ( スタッフ2) リスク値 ( スタッフ3) リスク値 平均 設計 0.2 0.3 0.2 0.2 開発 0.3 0.5 0.3 0.4 試験 0.1 0.5 0.1 0.2 打ち合せ 0.1 0.3 0.1 0.2 インストール 0.1 0.1 0.1 0.1 書類作成 0.1 0.2 0.1 0.1 合計 0.9 1.9 0.9 1.2 ＊リスク値　見積もりの各区分に加算する予備費の割合 50

反映している。表 2 中のリスク値は当初費用に上乗せす る予備費の割合であり、例えばスタッフ１は設計分類に 属する仕様には_{20％の予備費が必要であると回答して} いる。本論文ではプロジェクト実行に必要な費用を当初 費用と呼び、リスク対応費を含めた費用を総費用又は単 に費用と呼ぶ、またリスク対応費を単にリスクと呼ぶ。 表 2 中のリスク値の大きい要求仕様分類は精度が低い、 又は実現の難易度が高い要求仕様を含む分類であるこ とを示す。そして表 2 の合計は金銭的損失に換算したリ スクへの対応費であり、リスク対応費は当初費用の20％ となることを示している。20％のリスク対応費は、一般 的なプロジェクトにおけるリスク対策費と等しい。例え ば、一般的なプロジェクトではコンテンジェンシー予備 費として当初費用の_{10％を確保する、加えてマネジメン} ト予備費として当初費用の数％を加えた、合計費として、 当初費用の約_{20％をリスク対策費として計画する。つま} り本結果は一般的なプロジェクトではリスク対応費と して当初費用の20％をリスク対策費として確保する根 拠を与える。図 4 は図 3 に示したコストシェアレート にリスクを追加表示している。リスクはコストシェアレ ートに変換されている。式（2）はi 番目の要求仕様実現 に必要なコストシェアレートの算出方法を示しており、 要求仕様実現に必要なコストシェアレート(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_{𝑖𝑖𝑖𝑖} )は各 要求仕様中のアイテム別のコストシェアレート(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_{𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖} ) にアイテム別の遅延確率を含む費用割合(𝑅𝑅𝑅𝑅𝐶𝐶𝐶𝐶_{𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖} )を掛け合 わせた合計である。アイテムとは設計、開発、試験、打 ち合せ、インストール、書類作成であり、それぞれのア イテム別のリスクは表 2 のリスク値の平均を使用して いる。従って、図 _{4 が示す様に各要求仕様が持つリスク} のコストシェアレートを予測できれば、正確な費用の算 出が可能となる。本手法はまずプロジェクトの当初費用 が与えられることが前提であり、本手法は要求仕様別の リスク分析を提供する。本手法を用いて、当初費用の見 直しとリスクを含めた総費用の算出を繰り返すことに より手戻りが生じない適切なプロジェクトの計画が可 能となる。仕様の変更は手戻りと遅延につながり、無駄 な費用を必要とする。そこで、本手法により仕様の精度 向上が達成されれば、適切な費用計画が実現する。 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖= �𝑚𝑚𝑚𝑚_{𝑖𝑖𝑖𝑖=1}(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖× 𝑅𝑅𝑅𝑅𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖) (2) 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖：i 番目の要求仕様実現に必要なリスクを含む費用 をコストシェアレート表示したもの 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 ：i 番目の要求仕様中のｎ番目のアイテムの費用を コストシェアレート表示したもの 𝑅𝑅𝑅𝑅𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 ：i 番目の要求仕様中ｎ番目のアイテムの遅延確率 を含む費用割合 表 2 要求仕様分類別のリスク対応費の確保の割合 図 4 リスク込みのコストシェアレート ４．３ 要求仕様分析とコストシェアレート 表 2 に示したリスク値つまり、要求仕様別のリスク対 応費の確保割合はスタッフから得た値であった。しかし 言語的な要求仕様分析から要求仕様別のリスク値を得 ることができれば、コストシェアレートの自動計算が期 待できる。更に図 4 に示す様にプロジェクトの費用を要 求仕様別に分析して可視化できれば精度の低い要求仕 様を見直すことが可能となり、精度の高い費用算出が可 能となる。そこで、要求仕様分析からコストシェアレー トを算出する手法を提案する。以下に、ある過去のプロ ジェクトからコストシェアレートを算出する手順を示 す[9]。本例では i 番目の要求仕様のリスクを含まないコ ストシェアレート(Cri)の予測を行う。 （１） 要求仕様からのキーワード抽出 本ステップでは要求仕様を英語に翻訳して言語解析 を行い、キーワードを抽出する。図 _{5 に例を示す。要求} 仕様を翻訳する理由は英語では、文が分かち書きされて いるため、形態素解析が正確に行えるからである。次に 仕様区分 リスク値＊ ( スタッフ1) リスク値 ( スタッフ2) リスク値 ( スタッフ3) リスク値 平均 設計 0.2 0.3 0.2 0.2 開発 0.3 0.5 0.3 0.4 試験 0.1 0.5 0.1 0.2 打ち合せ 0.1 0.3 0.1 0.2 インストール 0.1 0.1 0.1 0.1 書類作成 0.1 0.2 0.1 0.1 合計 0.9 1.9 0.9 1.2 ＊リスク値　見積もりの各区分に加算する予備費の割合 図 6 に各要求仕様中に出現するキーワードの出現状況 をカウントする様子を示す。左側のキーワードは全要求 仕様から抽出したす全てのキーワードが並んでおり、各 要求仕様別に出現したキーワードをカウントする。 （２） オーバーラッピングキーワードの取得 オーバーラッピングキーワードとは2 つ以上の要求仕 様に出現するキーワードのことであり、オーバーラッピ ングキーワードの出現状況を分析することにより、要求 仕様間の関係と要求仕様の重要性が分析できる。図 7 に 要求仕様Req01からのReq05オーバーラッピングキーワ ードの取得例を示す。図 8 は要求仕様Req01 のオーバー ラッピングキーワードを示し、Req01 と他の要求仕様と の関係を示す。また、要求仕様の属する分野の特定もオ ーバーラッピングキーワードの取得と同様に用語辞書 中のキーワードと各要求仕様中のキーワードを突き合 わせて要求仕様の属する分野を特定する。用語辞書は仕 様分類を代表するキーワードを含み、仕様分類は基本設 計及び設計、画面作成、ロジックプログラムミング、そ の他である。 （３） ファーストオーダの取得 ファーストオーダとは各要求仕様と他の要求仕様との 関係であり、ある要求仕様と他の要求仕様間においてオ ーバーラッピングキーワードが存在する場合には２つ の仕様間には関係があるとする。例えば図 7 において要 求仕様Req01と要求仕様Req02の間には６個のオーバー ラッピングキーワードが存在するため、要求仕様_Req01 のファーストオーダを１つカウントする。同様に、要求 仕様Req01は他の１７個の要求仕様との間にオーバーラ ッピングキーワードを持つため、要求仕様Req01 のファ ーストオーダは１７である。 （４） コストシェアレートの予測 回帰分析を用いてコストシェアレートの予測を行う。 式(3)に回帰式を示す。回帰分析のパラメータはオーバ ーラッピングキーワード数、出現キーワード数、要求仕 様の属する分野である。 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑖𝑖𝑖𝑖 = 0.19X1 + 0.023X2 + 0.47X3 -0.871 (3) Cri: 費用予測(コストシエアレート) X1: 各要求仕様のオーバーラッピングキーワード数 X2: 各要求仕様が持つキーワードの数 X3: 各要求仕様の分類、要求仕様の分類は基本設計、設 計、画面作成、ロジックプログラムミング、その他であ り、各分野のキーワードを含む用語辞書と各仕様から抽 出したキーワードとの突合せで所属分野を特定する。 図 図 9 は過去のプロジェクトについて式(3)を用いて分析 したコストシェアレートと３人のスタッフから得たコ ストシェアレートを比較表示している。スタッフ値は3 人のスタッフからの値の平均による主観値である。 図 5 キーワード抽出の例 図 6 キーワードの出現頻度の例 図 7 オーバーラッピングキーワードの例 図 _{8 仕様間の関係分析の例（仕様１と他の要求仕様）}

Req01 Req02 Req03 Req04 Req05

system system When When lending achieves reads equipment equipment return taking tag passes passes history

out pasted gate gate display

equipment taking direction direction information efficiency out taking return equipment

6 図 9 コストシェアレート予測値とスタッフからの値 ４．４ コストシェアレートの自動計算 図 9 は要求仕様を言語解析して特徴量を抽出して演 算を行うことにより、コストシェアレートを自動取得で きる可能性を示している。しかし、今後、より大規模な プロジェクト分析の場合には広範囲な専門語を含む用 語辞書の準備と分類精度の向上が必要である。例えば、 今回は抽出したキーワードと用語辞書中のキーワード との突合せを行い、マッチしたキーワードが最も多く属 する分野を仕様分類とした、しかし更に、要求仕様の分 野分類の精度を上げるためには出現キーワードの関係 を考慮する等の分類手法の更なる研究が必要である。

5

5.

.

プ

プロ

ロジ

ジェ

ェク

クト

トの

の遅

遅延

延予

予測

測

５．1 要求仕様別の作業遅延予測 プロジェクトの遅延により費用超過が生じ、プロジェ クトリスクとなる。プロジェクトが遅延するか否かは各 タスクの進捗状況による。そこで本研究では各タスクの 遅延確率：P を式(4）の様に定義する。式(4）中の𝐷𝐷𝐷𝐷 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷は計 画日数と実際にタスク完了にかかった日数の割合、つま りタスクの達成度合いであり、式(4）のPi は i 番目のタ スクが遅延する確率である。ただし、計画日数より早く タスクが完了した場合にもPi は 0 より小さくならない。 理由はプロジェクトマネジメントでは計画日数より早 くタスクが完了した場合も単にタスク完了であり、ステ ータスとしてはスケジュール通りとして判断するから である。次に過去の実際のプロジェクトにおける各タス クの進捗状況（表 3 参照）を(5)式に示すβ関数に適応す ることにより表 4 に示すパラメータを得た。表 4 のパ ラメータからプロジェクトの遅延確率を予測した結果 を図 _{10 に示す。図 10 の横軸は各タスクの開始時間で} あり、全工期を_{0 から1 に正規化している。そして縦軸} は各タスクが遅延する確率を示す。例えば開始時期が0 に近いタスクである計画に属するタスクの行程が遅れ る確率は 0.69 であり、タスク全体の遅延確率の平均は 0.225 である。

𝑃𝑃𝑃𝑃

𝑖𝑖𝑖𝑖

= 1 −

_{𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷}𝐷𝐷𝐷𝐷𝑖𝑖𝑖𝑖_{𝑖𝑖𝑖𝑖}

(4) Pi:遅延確率 Dｐi:計画日数 Di:実作業日数 i:i 番目のタスク 表 3 タスクの進捗状況 (5) 表 4 取得したβ関数のパラメータ C C αα ββ 0 0..884400 11..002211 33..004488 図 10 プロジェクト中のタスクの遅延予測 過去のあるプロジェクトのコストシェアレートに要求 仕様分類別の遅延確率（図 _{10 参照）を掛けて得た結果} を表 5 に示す。仕様分類は基本設計、設計、製作、試験、 図書であり、コストシェアレートは３人のスタッフから 得た主観値である。表 5 の結果から遅延リスクを含むプ タスク

NO. 分類 a:予定作_業日 b:実作業_日数 c:作業遅_れb-a d：達成_度合い 遅延確率_1-d

1 計画 11 35 24 0.31 0.69 2 主設計1 11 16 5 0.69 0.31 3 主設計2 11 11 0 1 0 4 詳細設計1 18 18 0 1 0 5 詳細設計2 16 25 9 0.64 0.36 6 詳細設計3 27 27 0 1 0 7 プログラミング1 9 9 0 1 0 8 プログラミング2 32 31 -1 1.03 0 9 プログラミング3 26 24 -2 1.08 0 10 プログラミング4 39 62 23 0.63 0.37 11 プログラミング5 3 3 0 1 0 12 ドキュメント 1 1 0 1 0 13 テスト 3 2 -1 1 0 1 1

₍

₁

₎

)

(

_x

₌

_c

_×

_x

α−

₋

_x

β−

f

7 ロジェクトの費用予測は当初費用の約 10％増しとなっ ており、一般的なプロジェクト計画では_{10％程から20%} の費用をリスク対策費として計画することに適合する。 また表 5 の結果から主設計や設計に関する仕様の精度 はプロジェクトリスクを左右することが解る。一方、製 作、試験や図書作成には遅延リスクが無いことが解る。 表 5 要求仕様別遅延確率 ５．2 ベイジアン推定 プロジェクトには表 1 に示す様な不確実要因があり、 プロジェクトの遂行を不確実にする。そこで本研究では 条件付き確率とベイズ推定の式（6）を使用してプロジェ クトリスクを推定する方法を提案する。 (6) 以下にベイズ推定の例を示す。本例ではプロジェクトが 予定通り進む確率とスタッフからの進捗に関するレポ ートの信頼性に関する確率の関係を考える。プロジェク トが計画通りに終了する確率をＡ、そしてスタッフから の進捗に関するレポートの信頼性の確率をＢとする。そ してＡ＝0.9、Ｂ＝0.7 とすると、プロジェクトが実行さ れる世界の確率状況は図 11 となる。

A

A

A:Project B:Report

(0.1) (0.3) (0.7) (0.3) (0.7) (0.9)

B

B

図 11 報告を受ける前の世界確率の図

次に機械学習システムのWeka (Waikato Environment for Knowledge Analysis) [10]を使用してプロジェクトが実行

される世界の確率状況を表現した様子を図 _{12 に示す。}

図 12 と図 13 は Weka 上の Project ノードと Report ノー

ドに表 6 と表 7 の条件付き確率を与えている様子を示 す。Weka のベイジアンネットワーク表示では確率0.9 は 9000、そして確率 0.7 は 6599 と表示されている（図 12 参照）。 表 6 Weka 上のProject ノードの条件付き確率 プロジェクトの状況 計画 遅延 確率 0.9 0.1 表 7 Weka 上のReport ノードの条件付き確率 図 12 プロジェクトのベイジアンネットワーク表示 図 13 Project とReport に条件付き確率を与えている様子 次に、スタッフがプロジェクトの進捗は計画通りと報告 した後のプロジェクトの実行世界は表 8 と図 14 に示す 様になり、Ａの確率は式(7)に示す通り0.95 となる。 そして図図 15 は Weka での表示を示す。ベイジアン推定 ではエビデンスと呼ばれる状況報告が与えられること により、事象の確率世界が変化する。本例でのエビデン 要求 仕様ＮＯ 分野 行程遅延 確率 予測超 過費用 費用 予測 1 計画 6.4 0.100 0.64 7.02 2 主設計 10.6 0.225 2.39 13.03 3 製作 2.1 0.000 0.00 2.13 4 設計 4.3 0.225 0.96 5.21 5 製作 2.1 0.000 0.00 2.13 6 製作 12.8 0.000 0.00 12.77 7 設計 6.4 0.225 1.44 7.82 8 設計 21.3 0.225 4.79 26.06 9 設計 12.8 0.225 2.87 15.64 10 その他 12.8 0.000 0.00 12.77 11 製作 8.5 0.000 0.00 8.51 合計 100.0 13.09 113.09 コストシェ アレート(%) 52

図 9 コストシェアレート予測値とスタッフからの値 ４．４ コストシェアレートの自動計算 図 9 は要求仕様を言語解析して特徴量を抽出して演 算を行うことにより、コストシェアレートを自動取得で きる可能性を示している。しかし、今後、より大規模な プロジェクト分析の場合には広範囲な専門語を含む用 語辞書の準備と分類精度の向上が必要である。例えば、 今回は抽出したキーワードと用語辞書中のキーワード との突合せを行い、マッチしたキーワードが最も多く属 する分野を仕様分類とした、しかし更に、要求仕様の分 野分類の精度を上げるためには出現キーワードの関係 を考慮する等の分類手法の更なる研究が必要である。

5

5.

.

プ

プロ

ロジ

ジェ

ェク

クト

トの

の遅

遅延

延予

予測

測

５．1 要求仕様別の作業遅延予測 プロジェクトの遅延により費用超過が生じ、プロジェ クトリスクとなる。プロジェクトが遅延するか否かは各 タスクの進捗状況による。そこで本研究では各タスクの 遅延確率：P を式(4）の様に定義する。式(4）中の𝐷𝐷𝐷𝐷 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷は計 画日数と実際にタスク完了にかかった日数の割合、つま りタスクの達成度合いであり、式(4）のPi は i 番目のタ スクが遅延する確率である。ただし、計画日数より早く タスクが完了した場合にもPi は 0 より小さくならない。 理由はプロジェクトマネジメントでは計画日数より早 くタスクが完了した場合も単にタスク完了であり、ステ ータスとしてはスケジュール通りとして判断するから である。次に過去の実際のプロジェクトにおける各タス クの進捗状況（表 3 参照）を(5)式に示すβ関数に適応す ることにより表 4 に示すパラメータを得た。表 4 のパ ラメータからプロジェクトの遅延確率を予測した結果 を図 _{10 に示す。図 10 の横軸は各タスクの開始時間で} あり、全工期を_{0 から1 に正規化している。そして縦軸} は各タスクが遅延する確率を示す。例えば開始時期が0 に近いタスクである計画に属するタスクの行程が遅れ る確率は 0.69 であり、タスク全体の遅延確率の平均は 0.225 である。

𝑃𝑃𝑃𝑃

𝑖𝑖𝑖𝑖

= 1 −

_{𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷}𝐷𝐷𝐷𝐷𝑖𝑖𝑖𝑖_{𝑖𝑖𝑖𝑖}

(4) Pi:遅延確率 Dｐi:計画日数 Di:実作業日数 i:i 番目のタスク 表 3 タスクの進捗状況 (5) 表 4 取得したβ関数のパラメータ C C αα ββ 0 0..884400 11..002211 33..004488 図 10 プロジェクト中のタスクの遅延予測 過去のあるプロジェクトのコストシェアレートに要求 仕様分類別の遅延確率（図 _{10 参照）を掛けて得た結果} を表 5 に示す。仕様分類は基本設計、設計、製作、試験、 図書であり、コストシェアレートは３人のスタッフから 得た主観値である。表 5 の結果から遅延リスクを含むプ タスク

NO. 分類 a:予定作_業日 b:実作業_日数 c:作業遅_れb-a d：達成_度合い 遅延確率_1-d

1 計画 11 35 24 0.31 0.69 2 主設計1 11 16 5 0.69 0.31 3 主設計2 11 11 0 1 0 4 詳細設計1 18 18 0 1 0 5 詳細設計2 16 25 9 0.64 0.36 6 詳細設計3 27 27 0 1 0 7 プログラミング1 9 9 0 1 0 8 プログラミング2 32 31 -1 1.03 0 9 プログラミング3 26 24 -2 1.08 0 10 プログラミング4 39 62 23 0.63 0.37 11 プログラミング5 3 3 0 1 0 12 ドキュメント 1 1 0 1 0 13 テスト 3 2 -1 1 0 1 1

₍

₁

₎

)

(

_x

₌

_c

_×

_x

α−

₋

_x

β−

f

ロジェクトの費用予測は当初費用の約 10％増しとなっ ており、一般的なプロジェクト計画では_{10％程から20%} の費用をリスク対策費として計画することに適合する。 また表 5 の結果から主設計や設計に関する仕様の精度 はプロジェクトリスクを左右することが解る。一方、製 作、試験や図書作成には遅延リスクが無いことが解る。 表 5 要求仕様別遅延確率 ５．2 ベイジアン推定 プロジェクトには表 1 に示す様な不確実要因があり、 プロジェクトの遂行を不確実にする。そこで本研究では 条件付き確率とベイズ推定の式（6）を使用してプロジェ クトリスクを推定する方法を提案する。 (6) 以下にベイズ推定の例を示す。本例ではプロジェクトが 予定通り進む確率とスタッフからの進捗に関するレポ ートの信頼性に関する確率の関係を考える。プロジェク トが計画通りに終了する確率をＡ、そしてスタッフから の進捗に関するレポートの信頼性の確率をＢとする。そ してＡ＝0.9、Ｂ＝0.7 とすると、プロジェクトが実行さ れる世界の確率状況は図 11 となる。

A

A

A:Project B:Report

(0.1) (0.3) (0.7) (0.3) (0.7) (0.9)

B

B

図 11 報告を受ける前の世界確率の図

次に機械学習システムの Weka (Waikato Environment for Knowledge Analysis) [10]を使用してプロジェクトが実行

される世界の確率状況を表現した様子を図 _{12 に示す。}

図 12 と図 13 は Weka 上の Project ノードと Report ノー

ドに表 6 と表 7 の条件付き確率を与えている様子を示 す。Weka のベイジアンネットワーク表示では確率0.9 は 9000、そして確率 0.7 は 6599 と表示されている（図 12 参照）。 表 6 Weka 上のProject ノードの条件付き確率 プロジェクトの状況 計画 遅延 確率 0.9 0.1 表 7 Weka 上のReport ノードの条件付き確率 図 12 プロジェクトのベイジアンネットワーク表示 図 13 Project とReport に条件付き確率を与えている様子 次に、スタッフがプロジェクトの進捗は計画通りと報告 した後のプロジェクトの実行世界は表 8 と図 14 に示す 様になり、Ａの確率は式(7)に示す通り0.95 となる。 そして図図 15 は Weka での表示を示す。ベイジアン推定 ではエビデンスと呼ばれる状況報告が与えられること により、事象の確率世界が変化する。本例でのエビデン 要求 仕様ＮＯ 分野 行程遅延 確率 予測超 過費用 費用 予測 1 計画 6.4 0.100 0.64 7.02 2 主設計 10.6 0.225 2.39 13.03 3 製作 2.1 0.000 0.00 2.13 4 設計 4.3 0.225 0.96 5.21 5 製作 2.1 0.000 0.00 2.13 6 製作 12.8 0.000 0.00 12.77 7 設計 6.4 0.225 1.44 7.82 8 設計 21.3 0.225 4.79 26.06 9 設計 12.8 0.225 2.87 15.64 10 その他 12.8 0.000 0.00 12.77 11 製作 8.5 0.000 0.00 8.51 合計 100.0 13.09 113.09 コストシェ アレート(%)

8 スはスタッフが報告したプロジェクトの進捗は計画通 りである。 表 8 報告を受けた後の世界確率

A

A

A:Project B:Report

(0.1) (0.3) (0.7) (0.3) (0.7) (0.9)

B

B

図 14 報告を受けた後の世界確率の図 Ｐ Ｐ_{(𝑨𝑨𝑨𝑨|𝑩𝑩𝑩𝑩) =}ＰＰ(𝑩𝑩𝑩𝑩|𝑨𝑨𝑨𝑨)𝑷𝑷𝑷𝑷(𝑨𝑨𝑨𝑨) 𝑷𝑷𝑷𝑷(𝑩𝑩𝑩𝑩) =_{𝟎𝟎𝟎𝟎. 𝟕𝟕𝟕𝟕 × 𝟎𝟎𝟎𝟎. 𝟗𝟗𝟗𝟗 + 𝟎𝟎𝟎𝟎. 𝟑𝟑𝟑𝟑 × 𝟎𝟎𝟎𝟎. 𝟏𝟏𝟏𝟏}𝟎𝟎𝟎𝟎. 𝟕𝟕𝟕𝟕 × 𝟎𝟎𝟎𝟎. 𝟗𝟗𝟗𝟗 = 𝟎𝟎𝟎𝟎. 𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗 (7) 図 15 報告を受けた後のベイジアンネットワーク表示 ５．３ プロジェクトリスクのネットワーク表現 プロジェクトリスクが生じる主な要因として顧客か らの要求仕様の精度やプロジェクトマネージャーやプ ログラマーのスキルと見積もり精度がある。そこで、こ の上記要因とプロジェクトの遅延確率の関係をベイジ アンネットワークで表現した様子を図 16 に示す。本ベ イジアンネットワークではプロジェクトリスクはプロ ジェクトの遅延確率である。以降、プロジェクトリスク はプロジェクトの遅延確率とする。表 _{9 は図}図 16 の要因 が取りうる値を示す。ベイジアンネットワークはインフ ルーエンスダイアグラム_{[11]の意思決定ノードと不確定} ノードがないものであり、親ノードと子ノード間の関係 を条件付き確率で表現する。図 16 中の親ノードはプロ ジェクトの遅延確率（_{PPD）であり、子ノードにエビデ} ンスが与えられると親が示す世界の確率が変化する。 図 16 プロジェクトリスクのベイジアンネットワーク 表 9 ベイジアンネットワーク中の要因の内容 ５．４ ベイジアンネットワークと遅延予測 表 _{9 の要素を WeKa で表現したものを図 17 に示す。} 図 17 中のプロジェクトの遅延確率（PPD）は Pro+と表 現される。図 17 のベイジアンネットワーク中の条件付 き確率の初期値は表10 の通りである。そして表10 はプ ロジェクト中のリスク要因とプロジェクトの状態との 関係を示す。状態とはプロジェクトが遅延するか計画通 り進捗するかである。また表10 の条件付き確率は 5 人 のプロジェクトマネージャーからヒアリングした値の 平均である。そしてプロジェクトの遅延確率（PPD）の 初期値として0.5 を与えた後にベイジアンネットワーク にエビデンスを与える。与えるエビデンス（Case１）は AE:見積精度と SPM：プロジェクトマネージャーのスキ ルがStandard、STP：プログラマーのスキルがHigh、AR： 要求仕様の精度が_{Low であり、この時プロジェクトが遅} 延する確率は約0.26 となる（図 18 参照)。一方、エビデ ンス（Case２）をWeKa（図図17 参照）に与えた場合の遅 延確率は0.125 となる(図 19 参照)。Case２のエビデンス はAE:見積精度、SPM：プロジェクトマネージャーのス キル、AR：要求仕様の精度がStandard、そしてSTP：プ ログラマーのスキルがHigh である。表 11 に以上のCas1 とCase2 のエビデンスを与えた時のプロジェクトの遅延 確率を示す。 PP SP AE AR ST 要素 名称

AE 見積精度 Low Standard High SPM プロマネのスキル Low Standard High ＳＴＰ プログラマーのスキル Low Standard High ＡＲ 要求仕様の精度 Low Standard High PPD プロジェクトリスク 遅延する 遅延しない （プロジェクト遅延確率） エビデンスとして取りうる値 9 図 17 リスクのベイジアンネットワーク表現 表 10 プロジェクトの条件付き確率 図 18 リスク予測（Case1） 図 19 リスク予測（Case2） 表 11 リスク要因の状況と遅延リスク 表 11 に示す CASE 別の遅延リスクを、ある過去のプロ ジェクトに適応した場合の費用予測と実費用の対比を 表 12 に示す。本例では見積精度とプロジェクトマネー ジャーのスキルはStandard で、プログラマーのスキルが High の条件下では、顧客の要求仕様の精度が High から Low に代わることにより費用超過が当初費用の約 10％ から20％に変化することを示しており、実際のプロジェ クトの実行状況に近い。実際に本プロジェクトでは仕様 の変更が多発しており、実際に必要とした費用は当初費 用の約20%増しである。以上から、表 12 の結果は実際 のプロジェクトの実行環境において費用が超過する根 拠を与える。一般的なプロジェクト環境では、プログラ マーの教育や、プログラムの部品化により高いスキルを 持つプログラマーを準備することが可能であり、見積り とプロジェクトマネージャーのスキルは標準的である。 しかし、要求仕様の精度は不確実である。また、表 12 の

Case1 と Case2 の違いも要求仕様の精度が Standard か Low かであり、顧客からの要求仕様に変更が発生するか 否かがプロジェクトリスクを左右する。従って、本結果 から要求仕様を言語解析してコストシェアレートの自 動算出を行い、更にプロジェクト中の不確実要因の状況 を観測することにより、リスク対応費込みのプロジェク ト費用を予測しようとする本手法の有効性が示された。 表 12 リスク予測と実費用

プロジェクト状態 Low Standard High Sum 遅延 0.7 0.2 0.1 1.0 計画通り 0.1 0.2 0.7 1.0

プロジェクト状態 Low Standard High Sum 遅延 0.6 0.3 0.1 1.0 計画通り 0.1 0.3 0.6 1.0

ＳＴＰ：プログラマーのスキル プロジェクト状態 Low Standard High Sum

遅延 0.6 0.3 0.1 1.0 計画通り 0.1 0.3 0.6 1.0

プロジェクト状態 Low Standard High Sum 遅延 0.5 0.3 0.2 1.0 計画通り 0.2 0.3 0.5 1.0 AE:見積精度 見積精度に関する条件確率 ＡＲ：要求仕様の精度 要求事項の精度に関する条件確率 プログラマーのスキルに関する条件確率 プロジェクトマネージャーのスキルに関する条件確率 ＳＰＭ：プロジェクトマネージャーのスキル 要素 名称 Case1 Case２ AE 見積精度 Standard Standard SPM プロマネのスキル Standard Standard ＳＴＰ プログラマーのスキル High High ＡＲ 要求仕様の精度 Low Standard PPD プロジェクトリスク(Pro+) 0.26 0.125 （プロジェクト遅延確率） 要求 仕様ＮＯ 分分野野 B B::リリススクク ((CCaassee11)) C C::リリススクク ((CCaassee22)) 費 費用用予予測測 * *((11++BB)) 費 費用用予予測測 A A**((11++CC)) 実 実費費用用 1 計画 6.4 0.125 0.26 7.18 8.06 10.6 2 主設計 10.6 0.125 0.26 11.97 13.44 10.6 3 製作 2.1 0.125 0.26 2.39 2.69 2.1 4 設計 4.3 0.125 0.26 4.79 5.37 8.5 5 製作 2.1 0.125 0.26 2.39 2.69 2.1 6 製作 12.8 0.125 0.26 14.36 16.12 17.0 7 設計 6.4 0.125 0.26 7.18 8.06 8.5 8 設計 21.3 0.125 0.26 23.94 26.87 12.8 9 設計 12.8 0.125 0.26 14.36 16.12 25.5 10 その他 12.8 0.125 0.26 14.36 16.12 17.0 11 製作 8.5 0.125 0.26 9.57 10.75 12.77 100.00 112.50 126.31 127.7 A A::ココスストトシシェェ ア アレレーートト((%%)) 54

スはスタッフが報告したプロジェクトの進捗は計画通 りである。 表 8 報告を受けた後の世界確率

A

A

A:Project B:Report

(0.1) (0.3) (0.7) (0.3) (0.7) (0.9)

B

B

図 14 報告を受けた後の世界確率の図 Ｐ Ｐ_{(𝑨𝑨𝑨𝑨|𝑩𝑩𝑩𝑩) =}ＰＰ(𝑩𝑩𝑩𝑩|𝑨𝑨𝑨𝑨)𝑷𝑷𝑷𝑷(𝑨𝑨𝑨𝑨) 𝑷𝑷𝑷𝑷(𝑩𝑩𝑩𝑩) =_{𝟎𝟎𝟎𝟎. 𝟕𝟕𝟕𝟕 × 𝟎𝟎𝟎𝟎. 𝟗𝟗𝟗𝟗 + 𝟎𝟎𝟎𝟎. 𝟑𝟑𝟑𝟑 × 𝟎𝟎𝟎𝟎. 𝟏𝟏𝟏𝟏}𝟎𝟎𝟎𝟎. 𝟕𝟕𝟕𝟕 × 𝟎𝟎𝟎𝟎. 𝟗𝟗𝟗𝟗 = 𝟎𝟎𝟎𝟎. 𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗 (7) 図 15 報告を受けた後のベイジアンネットワーク表示 ５．３ プロジェクトリスクのネットワーク表現 プロジェクトリスクが生じる主な要因として顧客か らの要求仕様の精度やプロジェクトマネージャーやプ ログラマーのスキルと見積もり精度がある。そこで、こ の上記要因とプロジェクトの遅延確率の関係をベイジ アンネットワークで表現した様子を図 16 に示す。本ベ イジアンネットワークではプロジェクトリスクはプロ ジェクトの遅延確率である。以降、プロジェクトリスク はプロジェクトの遅延確率とする。表 _{9 は図}図 16 の要因 が取りうる値を示す。ベイジアンネットワークはインフ ルーエンスダイアグラム_{[11]の意思決定ノードと不確定} ノードがないものであり、親ノードと子ノード間の関係 を条件付き確率で表現する。図 16 中の親ノードはプロ ジェクトの遅延確率（_{PPD）であり、子ノードにエビデ} ンスが与えられると親が示す世界の確率が変化する。 図 16 プロジェクトリスクのベイジアンネットワーク 表 9 ベイジアンネットワーク中の要因の内容 ５．４ ベイジアンネットワークと遅延予測 表 _{9 の要素を WeKa で表現したものを図 17 に示す。} 図 17 中のプロジェクトの遅延確率（PPD）は Pro+と表 現される。図 17 のベイジアンネットワーク中の条件付 き確率の初期値は表10 の通りである。そして表10 はプ ロジェクト中のリスク要因とプロジェクトの状態との 関係を示す。状態とはプロジェクトが遅延するか計画通 り進捗するかである。また表10 の条件付き確率は 5 人 のプロジェクトマネージャーからヒアリングした値の 平均である。そしてプロジェクトの遅延確率（PPD）の 初期値として0.5 を与えた後にベイジアンネットワーク にエビデンスを与える。与えるエビデンス（Case１）は AE:見積精度と SPM：プロジェクトマネージャーのスキ ルがStandard、STP：プログラマーのスキルがHigh、AR： 要求仕様の精度が_{Low であり、この時プロジェクトが遅} 延する確率は約0.26 となる（図 18 参照)。一方、エビデ ンス（Case２）をWeKa（図図17 参照）に与えた場合の遅 延確率は0.125 となる(図 19 参照)。Case２のエビデンス はAE:見積精度、SPM：プロジェクトマネージャーのス キル、AR：要求仕様の精度がStandard、そしてSTP：プ ログラマーのスキルがHigh である。表 11 に以上のCas1 とCase2 のエビデンスを与えた時のプロジェクトの遅延 確率を示す。 PP SP AE AR ST 要素 名称

AE 見積精度 Low Standard High SPM プロマネのスキル Low Standard High ＳＴＰ プログラマーのスキル Low Standard High ＡＲ 要求仕様の精度 Low Standard High PPD プロジェクトリスク 遅延する 遅延しない （プロジェクト遅延確率） エビデンスとして取りうる値 図 17 リスクのベイジアンネットワーク表現 表 10 プロジェクトの条件付き確率 図 18 リスク予測（Case1） 図 19 リスク予測（Case2） 表 11 リスク要因の状況と遅延リスク 表 11 に示す CASE 別の遅延リスクを、ある過去のプロ ジェクトに適応した場合の費用予測と実費用の対比を 表 12 に示す。本例では見積精度とプロジェクトマネー ジャーのスキルはStandard で、プログラマーのスキルが High の条件下では、顧客の要求仕様の精度が High から Low に代わることにより費用超過が当初費用の約 10％ から20％に変化することを示しており、実際のプロジェ クトの実行状況に近い。実際に本プロジェクトでは仕様 の変更が多発しており、実際に必要とした費用は当初費 用の約20%増しである。以上から、表 12 の結果は実際 のプロジェクトの実行環境において費用が超過する根 拠を与える。一般的なプロジェクト環境では、プログラ マーの教育や、プログラムの部品化により高いスキルを 持つプログラマーを準備することが可能であり、見積り とプロジェクトマネージャーのスキルは標準的である。 しかし、要求仕様の精度は不確実である。また、表 12 の

Case1 と Case2 の違いも要求仕様の精度が Standard か Low かであり、顧客からの要求仕様に変更が発生するか 否かがプロジェクトリスクを左右する。従って、本結果 から要求仕様を言語解析してコストシェアレートの自 動算出を行い、更にプロジェクト中の不確実要因の状況 を観測することにより、リスク対応費込みのプロジェク ト費用を予測しようとする本手法の有効性が示された。 表 12 リスク予測と実費用

プロジェクト状態 Low Standard High Sum 遅延 0.7 0.2 0.1 1.0 計画通り 0.1 0.2 0.7 1.0

プロジェクト状態 Low Standard High Sum 遅延 0.6 0.3 0.1 1.0 計画通り 0.1 0.3 0.6 1.0

ＳＴＰ：プログラマーのスキル プロジェクト状態 Low Standard High Sum

遅延 0.6 0.3 0.1 1.0 計画通り 0.1 0.3 0.6 1.0

プロジェクト状態 Low Standard High Sum 遅延 0.5 0.3 0.2 1.0 計画通り 0.2 0.3 0.5 1.0 AE:見積精度 見積精度に関する条件確率 ＡＲ：要求仕様の精度 要求事項の精度に関する条件確率 プログラマーのスキルに関する条件確率 プロジェクトマネージャーのスキルに関する条件確率 ＳＰＭ：プロジェクトマネージャーのスキル 要素 名称 Case1 Case２ AE 見積精度 Standard Standard SPM プロマネのスキル Standard Standard ＳＴＰ プログラマーのスキル High High ＡＲ 要求仕様の精度 Low Standard PPD プロジェクトリスク(Pro+) 0.26 0.125 （プロジェクト遅延確率） 要求 仕様ＮＯ 分分野野 B B::リリススクク ((CCaassee11)) C C::リリススクク ((CCaassee22)) 費 費用用予予測測 * *((11++BB)) 費 費用用予予測測 A A**((11++CC)) 実 実費費用用 1 計画 6.4 0.125 0.26 7.18 8.06 10.6 2 主設計 10.6 0.125 0.26 11.97 13.44 10.6 3 製作 2.1 0.125 0.26 2.39 2.69 2.1 4 設計 4.3 0.125 0.26 4.79 5.37 8.5 5 製作 2.1 0.125 0.26 2.39 2.69 2.1 6 製作 12.8 0.125 0.26 14.36 16.12 17.0 7 設計 6.4 0.125 0.26 7.18 8.06 8.5 8 設計 21.3 0.125 0.26 23.94 26.87 12.8 9 設計 12.8 0.125 0.26 14.36 16.12 25.5 10 その他 12.8 0.125 0.26 14.36 16.12 17.0 11 製作 8.5 0.125 0.26 9.57 10.75 12.77 100.00 112.50 126.31 127.7 A A::ココスストトシシェェ ア アレレーートト((%%))

10

6

6.

.

プ

プロ

ロジ

ジェ

ェク

クト

トリ

リス

スク

ク予

予測

測ツ

ツー

ール

ル

本研究ではプロジェクトリスクを予測するツールを 開発した。本ツールは要求仕様別のコストシェアレート とベイジアンネットワークの条件付き確率を与えるこ とにより、要求仕様別のリスクを含む予想費用を表示す る。図 20 はPPD ノードに条件付き確率の初期値として 遅延が0.5、計画通りが0,5 を与えている様子を示す。そ して図 21 は SPM ノードにエビデンスとして Low を与 えている様子を示す。本システムの条件付き確率データ 形式はWeka のデータ形式と互換である。図 22 はある プロジェクトのリスクを含む費用を予想した例を示す。 幾つかのプロジェクト環境別に本システムを使用して 得た遅延確率を表 _{13 に示す。一般的にスキルの高いプ} ログラマーを準備することは可能である。しかしスキル の高いプロジェクトマネージャーは限られており、全て のプロジェクトにスキルの高いプロジェクトマネージ ャーを配置することは難しく、プロジェクトリスクは顧 客からの要求仕様の精度次第である。従って表表 13 の示 す結果は実際のプロジェクトの実行環境に近い。要求仕 様の精度とは仕様の変更が発生するか否かである。従っ てプロジェクトの遅延リスクを下げるためには要求仕 様の精度を上げることが必要である。そこで要求仕様の 精度を上げるために本ツールを使用して、要求仕様別の リスクを可視化して、リスクの高い要求仕様が明らかに することができれば、要求仕様の精度向上が可能となり、 結果的にプロジェクトリスクの低減が期待できる。 図 20 条件付き確率データ（一部） 図 21 エビデンスデータの例（一部） 図 22 要求仕様別の予想費用表示 表 13 リスク要因の条件別のプロジェクトリスク

7. 結

結論

論

本論文では確実なプロジェクトマネジメントの実現 を目指して、プロジェクトリスクの確率的評価方法を提 案して、その有効性を示した。具体的には、本研究はプ ロジェクトリスクの確率的評価を実現するために、まず、 コストシェアレートによる要求仕様の精度評価を提案 した。コストシェアレートとは、ある要求仕様を実現す るために、必要な費用がシステム全体の開発費用に占め る費用割合のことであり、開発費に加えて、リスク分を コストシェアレート表示したものは要求仕様の重要性 を可視化する。そして、本研究は自然言語処理を用いた 要求仕様分析によるコストシェアレートの自動算出の 可能性を示した。要求仕様分析からコストシェアレート の自動算出が可能になれば、コストシェアレートに基づ く要求仕様の重要性評価が可能となり、初期のリスク回 避が可能となる[12]。次に、本研究は、コストシェアレー トとベイジアンネットワークを用いたプロジェクトリ スク予測ツールを開発した。本ツールは顧客が提示する 要求仕様の曖昧さ、プロジェクトマネージャーとプログ ラマーのスキルと見積もり精度の関係をベイジアンネ ットワークに展開して、プロジェクトリスクを予測する。 そして本研究は幾つかのプロジェクト環境におけるプ ロジェクトリスクを算出した。その結果、本プロジェク トリスク予測ツールのリスク予測は現場のプロジェク トマネージャーからのヒアリング結果や実際のプロジ ェクトの実行状況に合うことが示され、本手法の有効性 が示された。今後、本ツールを発展させることにより、

要素 名称 Case1 Case２ Case3 Case4 AE 見積精度 Standard Standard Standard Standard SPM プロマネのスキル Standard Standard High High ＳＴＰ プログラマーのスキル High High Standard High ＡＲ 要求仕様の精度 Low Standard Standard Low PPD プロジェクトリスク(Pro+) 0.26 0.125 0.142 0.056 （プロジェクト遅延確率） <DEFINITION> <FOR>PPD</FOR> <TABLE> 0.5 0.5 </TABLE> </DEFINITION> <DATA> <NAME>SPM</NAME> //エビデンスの与え方は１列目、2 列目で与える <EVIDENCE>Low</EVIDENCE> <RESULT> </DATA> 11 プロジェクトリスクの可視化が可能となり、確実なプロ ジェクトマネジメントが期待できる。

8. 考

考察

察

本研究で提案したコストシェアレートは、プロジェク ト開始当初の要求仕様を言語解析することにより算出 している。しかし、実際のプロジェクトではプロジェク トが進むに従い、要求仕様の優先順位が変化してプロジ ェクトの複雑度が変化するため、精度の高いプロジェク トマネジメントのためには、要求仕様の重要度の変化予 測を行う必要がある。一方、筆者は時間軸に沿った人の 主観の変化を模擬する方法として３秒ルールインテリ ジェンスを提案している。３秒ルールインテリジェンス は人の価値観が周囲の状況や目的の変化により、常に変 化して人の判断に揺らぎを与える様子を模擬しようと する考えであり、３秒ルールインテリジェンスは人と同 様に３秒未来までの価値観の揺らぎに従い、物事の優先 順位付けを行う[13]。ところで、プロジェクトマネジメン トでは、プロジェクトが進むに従い、要求仕様の重要性 が変化する背景にはシステムの各機能に対するユーザ の価値観の変化が存在する。そこで、今後、３秒ルール インテリジェンスによる価値観の変化予測を考慮した コストシェアレートの算出手法が期待される。

謝

謝辞

辞

本研究はJSPS 科研費 17K00354 の助成を受けた。 本研究のデータ分析に助言を頂いた横浜国立大学の満行泰 河准教授に感謝申し上げる。また、データ提供を頂いた（株） インターリンクの中尾明一郎氏と森尚久氏、そして（株）テ クノソリューションの坂口憲一氏に感謝申し上げる。

参

参考

考文

文献

献

[1] 金子則彦, プロジェクトマネージャー完全教本, 日 本経済新聞出版社, 2010 [2] 持田 信治,プロジェクト管理にための知識検索機能 実現に向けて,バイオメディカル・ファジィ・システム学 会誌 Vol.14, No2, 15-22, 2012

[3] A Guide to the Project Management Body of Knowledge (日本語訳),Project Management Inst, 2009

[4] 対訳 ISO 31000:2009(JIS Q 31000:2010)リスクマネジ メントの国際規格, 日本規格協会, 2010 [5] ISO31000:2009 リスクマネジメント解説と適用ガイド, 日本規格協会_{, 2010} [6] 満行泰河，大和裕幸，稗方和夫，モーザー ブライア ン，磯沼 大，岡田伊策，笈田佳彰，システム開発プロジ ェクトにおける手戻りリスクを考慮したタスク優先ル ール設計に関する研究, 日本機械学会論文集 Vol.82, 2016

[7] Shinji Mochida,A Study on Method of Measuring Perfor-mance for Project Management, 20th ISPE International Conference on Concurrent Engineering IOS Press Ebooks, US, pp.264-273, 2013

[8] Beshoy Morkos,James Mathieson,Joshua D. Summers” Comparative analysis of requirements change prediction models: manual, linguistic, and neural network”, Research in Engineering Design Vol.25, Springer, US, 2014, 139-156, 2014

[9] Shinji Mochida, James Righter, Joshua D. Summers, A Study of Project Cost Management Based on Requirements Analysis, International Journal of BMFSA Vol. 21, No. 1, pp.21-27, 2016

[10] 藤田一弥, 見えないものをさぐる, オーム社, 2015 [11] Ronald A. Howard and James E. Matheson, Influence Diagrams, Decision Analysis Vol. 2, No. 3, September 2005, pp. 127-143, 2005 [12] 最新リスクマネジメントがよ～くわかる本, 東京海 上日動リスクコンサルティング, 2012 [13] 持田 信治,3 秒ルールＡＩ実現に関する研究,日本 経営システム学会第62 回全国研究発表大会講演論文集、 138-139, 2019 持 持田田 信信治治（（ももちちだだ ししんんじじ）） 流通科学大学 商学部 教授 1984 年 九州工業大学情報工学科卒業 知識蓄積システムの構築に関する研究 に興味ありバイオメディカル・ファジ イ･システム学会、日本経営システム学 会各会員 56