ソフトウェア開発見積りの課題と解決方法•COCOMO さまざまな見積り •一方、キャリブレーション（較正）の必要性の認識 •多数のデータから

CoBRA研究会幹事

Copyright ©2012 MRI, All Rights Reserved

ソフトウェア開発見積りの課題と解決方法

～見積り手法の歴史とCoBRA法～

2012年6月14日

先進ソリューションセンター

石谷靖

（IPA/SEC戦略意思決定プロセス強化WG委員）

SDM公開講座

「現代ソフトウエアエンジニアリングの俯瞰図」

2 Copyright ©2012 MRI, All Rights Reserved

ご紹介の内容

１．見積りにおける課題２．見積り手法の歴史と蓄積３．見積り根拠の「見える化」４．CoBRA法の概要５．CoBRAモデルの構築方法６．CoBRAモデルの応用７．事例紹介


ご紹介の内容



プロジェクト・マネジメントの中核

契約

プロジェクトの

全体把握

プロジェクト

マネジメント

プロセス改善

予実分析

規模・体制

インプット

見積りゴール

•コストマネジメント

•リソースマネジメント

•進捗マネジメント

•リスクマネジメント

•スコープマネジメント

•品質マネジメント

1.1 プロジェクトマネジメントにおける見積りの位置づけ

１．見積りにおける課題


1.2 プロジェクトにおける大きな課題の一つ

「プロジェクトを大失敗させる原因は二つある。ひとつは、見積りミスだ」

楽観的な見積り：見積り根拠があいまいで、必要な要素をきちんと見積もっていない。

早期の見積り：作るものが決まっていない状況で見積りを行う。

目標と見積りの混同：営業、マーケティング担当者や顧客の事情で決定される。

一度決まったら修正されない見積り

時間の余裕がないことが多い（十分に取り組めない）。

⇒ムリなプロジェクト

「もうひとつは、仕様未凍結だ」

⇒仕様の細部が決まらない。仕様が変化し続ける。

※上記の見積りミスにつながる原因の一つ

⇒ムリなプロジェクト

ロバート・グラス、「ソフトウェア開発55の真実と10のウソ」、2005



1.3 見積りミスを引き起こす原因

Capers Jones, “Social and Technical Reasons for Software Project Failures”, Crosstalk, June, 2006

1. 要求が完全に決定される前に、正式な見積りが求められる。

2. 新しい要求が加えられても、見積りは変更されない。

3. 主要なソフトウェア開発プロジェクトでも、見積りツールが使われない。

4. 実績データがなく見積りのキャリブレーション（較正）ができない。

5. 保守的な見積りは採用されず、挑戦的な見積りで置き換えられる。

LM. Liard & M.C. Brenman, “Software Measurement and Estimation: A Practical Approach”, John Wiley & Sons, Inc., 2006 次の場合に見積りミスが発生する。

1．見積りに関して根拠をきちんと説明できない場合

2．期間と工数に関して、「望み」と「見積り」が混同されている場合

3．期待に基づいて計画が立てられる場合

4．要求が曖昧な場合、要求が変化し、増加していく場合

5．成果物の品質が悪い（顧客の満足が得られない）ことが判明した場合



1.4 見積りの国内の実践状況

ベンダ企業 2005年（JISA調査）

PL・担当者の経験に基づく（30%強）類似プロジェクトからの類推（30%強）

2012年（IPA/SEC調査、組込み系）個人の経験に基づいた（20%弱）過去のデータの実績に基づいた（40%弱）

2012年（IPA/SEC調査、エンタプライズ系）個人の経験に基づいた（10%強）過去のデータの実績に基づいた（35%）

※属人的な方法が減少している一方、類推的な方法が残る。

ユーザ企業相見積りという手段が基本

※2005年度JUAS企業IT動向調査基本的に、基準を持つよりは受身ベンダの見積りに依存

委託先への満足度 ※2010年度JUAS企業IT動向調査「価格」への満足22%、「見積り金額の妥当性」は

19%（普通が50%弱、不満が35%）

過去の類似シ

ステムからの

類推, 32.0%

PL.・担当者

の経験, 32.0%

モデル的

手法, 7.0%

積み上

げ, 28.0%

その他, 1.0%

社内の見積り

基準に基づい

た, 29.1%

過去の実績

データに基づ

いた, 38.8%

個人の経験に

基づい

た, 16.8%

与えられた条

件に合せ

た, 10.1%

見積りしな

かった, 1.0%

わからな

い, 4.3%

社内の見積り

基準に基づい

た, 41.0%過去の実績

データに基づ

いた, 34.5%

個人の経験に

基づい

た, 12.7%

与えられた

条件に合

せた, 8.6%

見積りし

なかっ

た, 0.1%

わからな

い, 3.1%

2005年JISA調査

2012年IPA/SEC調査*1

組込み

エンタ

プライズ

*1ソフトウェア産業の実態把握に関する調査、IPA/SEC、2012 2012年IPA/SEC調査*1



1.5 見積りにおける課題(1)

見積り根拠が明確になっていない（規模、工数、工期）「KKD：Kan（勘）とKeiken（経験）とDokyo（度胸）」による見積り

見積りに必要な情報がはっきりしていない規模、工数・コスト、工期を見積もるために根拠の情報がない

見積り方法もその場限り上記情報を使った規模、工数・コスト、工期の見積り方法が明確でない

生産性に影響を及ぼす要因が多種多様（工数）規模は、基本的に考慮される。

一方で、次のような要因も考慮に入れる必要がある。

品質など見えないものの影響

プロジェクトの状況の影響開発の中心は人手

スケジュールの制約

コミュニケーション状況

要求の安定性

・・・・・

影響要因が分かっている場合でも定量化が難しい

見積り工数

規模

指定ソフト・ハードの安定性

要求の安定性

開発ｽｹｼﾞｭｰﾙの制約

性能要求の高さ

信頼性要求の高さ

コミュニケーション（関係部署の数）



実績プロジェクトデータ例：規模と工数の関係

IPA/SEC「定量データに基づくプロジェクト診断支援ツール」（2007年12月より）

https://sec.ipa.go.jp/project_assessment/TopMenu.do （無料利用者登録必要）

規模（ファンクションポイント）と工数（人時）との関係例

ばらついたデータを説明する関係の発見が必要




ソフトウェアの見積りを難しくしている原因（規模、工数、工期）

過去データの欠落・精度の確保

工数データの把握が難しい。

規模データの一貫性の欠落（単位、数え方の一貫性）

分析が難しい

データを集約しても、傾向の分析が難しい。

見積り実施者の傾向（規模、工数、工期）

「ほとんどのコスト見積りは低すぎる傾向がある」（DeMarco-Glassの法則）

不必要な作業を追加するよりは、作業項目を忘れる。

ソフトウェアの機能も同様に忘れられているものの方が多い。

データ等の根拠がない場合は「楽観的に」なりがちである。

不慮の事態が起こりがち：安定した開発はない

「早期の見積り」「時間をかけず、熟慮しないで実施」

「目標」を「見積り」としてしまう。

現実には混同しがちだが、全く違うものを同一視している。

例：入札額と見積り額は本来違うもの「法則」の出典（以下、同じ）：

A. Endres, 、D. Rombach, A Handbook of Software and Systems Engineering

1/E, Pearson Education, 2003,（邦訳：吉舗紀子訳、ソフトウェア工学・システム工学ハンドブック、コンピュータエイジ社、2005）




時間

最終的な規模

データ項目数

ﾌｧﾝｸｼｮﾝ･ﾎﾟｲﾝﾄ数ソースｺｰﾄﾞ行数

ぶれ幅

類似ｼｽﾃﾑ

規模現実には

推測

実際に使える情報規模見積りで使いたい

確定情報

要求機能複雑さ

部分的な情報からの見積り（規模）

細部が決まっていない状況で、見積りを行う場合が多い

（予算決めなど早い段階）

⇒ 部分的な情報から、推測するしかない。

⇒ 実際とぶれがでることは避けられない

システム化の方向性

設計システム化計画

製作要件定義

B. Boehm, Software Engineering Economics,1984

IPA/SEC編、ソフトウェア開発見積りガイドブック、オーム社、2006

数値例:

4～1|

4倍




システム化の方向性

設計システム化計画時間製作要件定義

規模

当初の想定機能（規模）

最終的な機能（規模）

規模の増加

決めたことが変わっていく（規模）

開発当初の想定機能は、一般に工程が進むにしたがって膨張する。

⇒見えていなかった要件が見えてくる。

⇒最初の見積りと当然ぶれがでる

数値例：1か月に2%増加

Capers Jones、ソフトウェア見積りのすべて第2版、共立出版、2009

IPA/SEC編、ソフトウェア開発見積りガイドブック、オーム社、2006に基づき改変



ご紹介の内容



2.1 見積り手法に関する大きな流れ

1960年代 1970年代 1980年代 1990年代 2000年代

ソフトウェア開発（工学）の黎明期

見積りモデル

提案の時代見積りモデルの成熟期

ツールの成熟

機械学習の応用熟練者の知識活用の再認識

•マネジメントの一環として、見積りが既に課題

•様々な関係式

•規模に対する注目（ファンクション・ポイント）

•重要文献（基本指針）の出現

•パラメトリック手法

•COCOMO

•さまざまな見積りツール

•一方、キャリブレーション（較正）の必要性の認識

•多数のデータから予測（多様な機械学習アルゴリズムの適用）

•プロジェクトマネジメントの体系化（WBS）

•1990年代後半から

データと熟練者の知識の融合

ハードウェアコストの一部 ⇒

ソフトウェア比率とコストの増大 ⇒ 残り続ける「勘」「経験」「度胸」（KKD)の習慣

コンピュータ黎明⇒大型計算機（汎用機）⇒オープン化⇒さらなるオープン化

経験に基づく見積もりが30%以内（2005年）

類推見積りが40％弱（2012年）

2．見積り手法の歴史と蓄積


2.2 ソフトウェアにおける見積りに関する歴史と蓄積(1/4)

最初の研究は、1950年代から60年代

最初の論文：V. Norden, 1958

“Curve Fitting for a Model of Applied Research and Development Scheduling”

初期の論文から多くの変動要因を考慮

Nelson, E.A., “Management Handbook for the Estimation of Computer Programming Cost”, TM-3224, SDC, 1966

169のプログラミング事例を統計的に分析

6つの工程に分類

「プログラム設計、コーディング及びテスト」について、工数計算式を定義

「計画及びコスト見積り」、「分析・設計」、「統合テスト」、「インストール」、「保守」については、基本的に過去のプログラミング経験に基づく類推

Nelson-Jonesの法則：「多くの要素が開発生産性に影響を及ぼす（増加要因）」

工程ごとに要因の設定

要求関連

設計要求定義のあいまいさ、運用要求に関する知識の欠如、システムにおける機能数

設計・コーディング関連

命令数の数、サブプログラムの数、内部や外部向けの文書の数、プログラムの種類

その他、データ処理関連、開発環境の要因



2.2 ソフトウェアにおける見積りに関する歴史と蓄積(2/4) 1970年代は、見積りモデルの時代

多様なモデルの提案コスト要因を含む算出方式

例：基本式：変動要因例：インターフェイスの複雑さが不安定であれば、29%増加

C.E. Walston, C.P. Felix. A Method of Programming Measurement and Estimation" IBM Systems Journal, vol. 16, No. 1, 1977

例：SLIMモデル（L.H.Putnam）

Tpは人員がピーク時の時間 Ckは定数（技術的な適用度合い応じて変わる）工数の分布の前提として、「レイリー分布」「工数」と「規模」と「時間」のトレードオフを表現

例：規模指標として、ファンクション・ポイントの萌芽 A.J. Albrecht, Measuring Application Development Productivity, Proceedings of the Joint SHARE,

GUIDE, and IBM Application Developments Symposium, 1979

1970年代のモデルにおける課題ソフトウェア開発に影響を及ぼす変動要因は多数あり、何を選択すればよいのか。モデルによって、重視する要素に違い

プロジェクトサイズコスト変動要因熟練者の判断まだ、組合せを考えるまでには至っていなかった

34

31

pk TEffortCSize

107.552.50

8

6

4

2

0

t

y

t

y

5.76*t*exp(-0.08*t^2)

)2

exp()(2

2

b

t

b

tktM

工期

人員割当


3TimenEffort


1980年代（1980年前後を含む）はパラメトリック手法の提示

様々な規模や環境のデータを用いて、パラメトリックなモデルの構築

Basiliのメタモデル：

一方、主要な結論として、ある環境で構築されたモデルはそのままでは他の環境での精度が良くない。

⇒キャリブレーション（較正）を行う必要がある。

（Kitchenham & Taylor, 1985; Kemerer, 1987)


COCOMOモデル（1981年）見積モデルに関する体系的なモデル

Boehmにより開発南カリフォルニア大学、当時はTRW

工数の説明変数として、規模、コスト変動要因

規模と工数の関係は、非線形の指数関数

15

194.2

i i

E EMSizePM

4.18

2.36

1.87

1.66

1.57

1.56

1.51

1.49

1.34

1.32

1.23

1.23

1.2

1 1.5 2 2.5 3 3.5 4 4.5

Personnel/team capability

Product complexity

Required reliability

Timing constraint

Applicatoins experiece

Storage constaint

Modern programming practices

Software tools

Virtual machine experience

Turnaround time

Schedule constraint

Data base size

Language Experience

は変動の係数は定数、MR,, cba

cSizeaMRE b




1990年代における機械学習方式の適用

ソフトウェア開発は複雑で動的なプロセスであり、生産性における変化の因果関係を説明するには知識が少ないとの認識の下、データに語らせる方式が多数取られた。

機械学習アルゴリズムの適用(Briandら, 1992)

ニューラルネットワークの適用(Jørgensen, 1995; Finnieら, 1997)

CART Regression treeの適用(Srinivasan & Fisher, 1995; Kitchenham, 1998)

基本的に、パターンに分類して見積りを行うもの

1990年代後半から2000年代：熟練者の判断活用に対する再認識

熟練者は、自らの経験と知見により、見積り方法を「暗黙的に」確立

⇒熟練者の見積りの効率化・高精度化

⇒熟練者の知見を活用したモデルの構築

主観的な見積り (Höst & Wohlin,1998; Stensrud & Myrtveit, 1998)

熟練者の知見を活用した定量化（CoBRA） (Briandら. 1998a)



2.3 見積り手法と関連技術の動向（まとめ）

規模指標

工数見積り

1950年代 1960年代 1970年代 1980年代 1990年代 2000年代

★’76 Cyclomatic複雑度

★’77 Software Science(HALSTEAD)

★’79 FP

★’87 ﾌｨｰﾁｬｰﾎﾟｲﾝﾄ

★’89 MKII FP ★’00 COSMIC-FFP

★’97 CoBRA法

★’97 COCOMOⅡ ★’81 COCOMO

★’05 NESMA(FP)

★’58 最初の論文

※SLOC（ソースコード行）命令数(Instructions)

★’78 SLIM

★’86 COMPO

★90年代機械学習アルゴリズム

★’73 PRICE-S

★90年代後半から熟練者知識活用

★’88 SEER-SEM

★’63 NELSON

★’93 Use Caseポイント ★’91 オブジェクトポイント



ご紹介の内容



3.1 見積りの見える化とモニタリングとコントロール（解決方針）対策①：見積り手法の確立

前提（インプット）とアウトプットの明確化アウトプットの算出根拠の明確化と再現性の確保 ⇒見積りモデルの確立

対策②：見積りの妥当性の確保複数の視点からのチェック特に、見積りの前提が曖昧な場合は様々な立場・可能性からのチェック／シミュレーション ⇒複数の見積り方法によるレビュー ⇒対策①の実現による前提を変えたシミュレーションはその一つ

対策③：モニタリングとコントロールと再見積り曖昧な状況であっても、前提とインプットを仮説として置き、見積り明確になるとともに、前提とインプットを見直して、再見積りまた、変化する条件（要求内容）に対して、前提とインプット見直しによる再見積りとコントロール同時に、前提とインプットが成立するように、マネジメントによるコントロール ⇒前提条件とインプットの変化のモニタリング ⇒コントロールによるブレ防止と再見積りによる変化への追随 ⇒対策①の実現により可能となる

対策④：目標と見積りの峻別

見積りは前提条件とインプットに基づいて算出目標と見積りの差異は、見積り（手法）で解決するのではなく、マネジメントで解決 ⇒見積りプロセスの確立 ⇒対策①の実現により可能となる

本日の主題

すべての対策の出発点

3．見積り根拠の「見える化」


3.2 見積り根拠の「見える化」の重要性

見積り根拠が「見えない」ことによる問題


ユーザ（発注者）

• 金額（工数）の妥当性が分からない。

• 危険性（予算不足・過剰）が分からない。

• 無理な値下げによる品質低下。

• 根拠のある価格交渉ができない。

ベンダ（受注者）

• 見積りの妥当性を説明できない。

• 予算が厳しいことを納得してもらえない。

• 予算に合わせて工数をコントロールできない。

見積り根拠の「見える化」＝コスト構造の「見える化」が重要


3.3 見積り根拠の「見える化」の課題

規模だけでは工数を説明できない。

工数の「ブレ」を説明できる手段が必要。

×

×

×

×

××

×

×

×

××

×

×

×

××

×

規模

工数

規模がほぼ同じでも、必要な工数に違いがある。

この違いを把握し、説明する



3.4 「見える化」の具体的な解決策～CoBRA法～

１．組織固有のコスト変動要因をモデル化

CoBRA法の5つの特徴

２．コスト変動要因に、熟練者の優れた「勘」「経験」を反映

４．予算超過リスクの定量評価を実現

５．プロセス改善のポイントを把握

３．工数のコントロールを実現

（*）Cost Estimation, Benchmarking, and Risk Assessment



ご紹介の内容



45人月でしょ！おぉ！！！

熟練者（経験20年）

担当者（経験5年）

RFP

4.1 CoBRA法のコンセプト～「勘」「経験」を見える化する

優れた「勘」「経験」を見積りに活用

ベテランの見積りは妥当なことが多い

将来の見通しについては「勘」「経験」に頼らざるを得ない

「勘」「経験」のみの見積りには問題が・・・

「勘」「経験」を有するベテラン以外は使えない（ノウハウ共有が困難）

見積り結果の正しさを説明することが難しい

（説明力の不足）

解決策：「形式知化し、実績データで検証」

モデル化により、優れたノウハウを共有

「勘」「経験」の正しさを「実績データ」で検証

4．CoBRA法の概要

新しい科学的な「KKD」

勘

（K）

データ

（D）

経験

（K)


4.2 CoBRA法における工数見積りの考え方

規模

工数

α ×規模

CO ×

×

×

× × ×

×

×

×

×

×

×

×

×

×

×

×

「規模がほぼ同じでも、かかる工数に違いがある。」 ⇒ 現実の工数を、ベースの生産性α と、そこからのオーバーヘッド（CO）により説明



実績データに照らして、変動要因とその定量化を検証し、α を計算

4.3 CoBRA法の工数見積り式

工数＝ α × 規模 × （１＋ Σ COi ）

過去プロジェクト規模工数

PJ-1 10.3KLOC 9.2人月






････････････････

コスト変動要因のオーバヘッドを考慮

経験豊富なPL等の熟練者の知見を基に、変動要因とその影響を定量化

確率

影響度(%)

C氏

B氏

A氏

補完



4.4 CoBRA法の位置づけ

見積り手法

データ駆動型

• COCOMO • OSR® • CART • ANOVA

過去のプロジェクトデータに基づく

経験ベース型

• 専門家による見積り

• 見積りミーティング

• デルファイ法

基本的に熟練者の経験のみを利用

ハイブリッド型

過去のプロジェクトデータと熟練者の経験を利用

3名程度の熟練者と10個程度の

実績データから見積りモデル構築

•CoBRA法



4.5 工数見積りの手順

工数見積りの手順

①規模の推定

②変動要因の

影響度の評価

③見積りの実行

見積もる対象のプロジェクトの開発量（規模）を想定

各変動要因の影響度を評価

（0～3の4段階）

見積りを実行し、結果を確認

（ツールを使用）

工数＝ α × 規模 × （１＋ Σ COi ） ① ② ③



4.6 ツールでの見積り手順 ①想定規模の入力

① 想定規模を入力



4.6 ツールでの見積り手順 ②変動要因レベルの入力

② 変動要因のレベルを入力

① 想定規模を入力



4.6 ツールでの見積り手順 ③見積りの実行と結果の確認

見積り結果

予算超過確率

感度分析

③ 見積り実行

② 変動要因のレベルを入力



4.7 CoBRAツール（IPA/SEC提供）

簡易ツール CoBRA法の体験版

IPA/SECのホームページにログイン後に、所定のURLから使用 http://sec.ipa.go.jp/tool/cobra/

２００７年度の実証実験の集約データを参考値として搭載

Webブラウザがあれば利用可能

統合ツール CoBRA法のフル機能版

Excelアプリケーション

IPA/SECのホームページからダウンロードして利用

一から独自の見積りモデルを作成


http://sec.ipa.go.jp/tool/cobra/


0

100

200

300

400

500

600

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

度数

予算

超過

確率

見積り工数 [人月]

見積り工数分布及び予算超過確率

6.3%

6.7%

8.3%

10.6%

11.6%

16.2%

16.4%

17.8%

25.2%

29.5%

0.0% 10.0% 20.0% 30.0% 40.0%

プロジェクトマネージャの経験・知識

関係者の数

顧客の参画度合い

開発期間の厳しさ

チームの経験・知識

信頼性要求のレベル

システムの複雑さ

業務の複雑さ

要求変更の発生想定時期

見積り時の要求内容の曖昧さ

変動要因の寄与度

0.2

0.4

0.6

0.8

1.0

工数

予算超過確率

960 1420880 1260660

見積値（中央値）

0.1

4.8 CoBRAモデルの利用シーン

コストマネジメントリスクマネジメントプロセス改善

プロジェクトマネージャ

PMO、品質管理部門

24.6

19.4

16.8

15.5

9.8

0.0 10.0 20.0 30.0 40.0

要求変更の度合い


業務の複雑さ


システムの複雑性

[%]

工数見積り

工数変動幅の確認

予算超過リスクの評価

影響度の高い要因の把握

影響度の高い要因の対策と解消

960 1420880 1260660

工数のコントロール



4.9 CoBRA法の歩み

1997年、独フラウンホーファ財団実験的ソフトウェア工学研究所（IESE）により発表 http://www.cobrix.org/index.html

国内実証実験（2007年8月～2008年3月） 8社でCoBRAモデルの構築

金融・保険、製造、情報提供の3分野

複数の規模メトリクス（ソースコード行数、ファンクションポイント、画面数）によるモデル構築

CoBRA研究会発足（2009年5月） CoBRAモデル構築経験のある企業による自主的な研究会

http://cobra.mri.co.jp

10組織（2012年6月現在） (株)アイネス、(株)NTTデータセキスイシステムズ、沖電気工業(株)、人事院（CIO補佐官）、

大同生命(株)、日新情報システム開発(株)、(株)日立製作所、ボーズ・オートモーティブ(株)、

（株)三菱総合研究所、三菱電機(株) ※50音順

ガイド発刊 CoBRA法入門－「勘」を見える化する見積り手法－（2011年4月、オーム社）

支援ツールの無料公開（2010年3月）（独）情報処理推進機構ソフトウェア・エンジニアリング・センター

「CoBRA法に基づく見積り支援ツール」（http://sec.ipa.go.jp/tool/cobra/）


http://www.cobrix.org/index.html

http://cobra.mri.co.jp/

http://sec.ipa.go.jp/tool/cobra/


ご紹介の内容



5.1 CoBRAモデルの構築手順

CoBRAモデルの構築手順

①変動要因の抽出・定義

②実績データの収集

③モデルの構築

熟練者2、3名の協力の下に、変動要因を抽出・定義し、工数への影響度を設定

過去プロジェクト10件程度について、

規模と工数の実績データを収集し、各変動要因のレベルを設定

支援ツールを用いて見積りモデルを構築し、見積り精度を確認

工数＝ α × 規模 × （１＋ Σ COi ）

② ①

③

5 ．CoBRAモデルの構築方法

④見積り精度の改善モデルを見直し、見積り精度を改善

初期モデル

改善モデル


5.2 【手順1】変動要因の抽出・定義 ①変動要因の洗い出し

熟練者2、3名の協力を得て、自組織に特有の変動要因をブレーンストーミングにより抽出

抽出例

（簡易法）

変動要因のサンプルから、自組織に当てはまるものを選ぶ

IPA/SECの変動要因セット（19種）

「CoBRA法入門」付録Aに掲載の変動要因事例（ベンダ企業、ユーザ企業別）

工数

関係者の協力度合い

(CO1)

要件の不安定性(CO8)

要件管理の確実さ(CO7)

既存システムの整備状況

(CO10)

ソフトの複雑さ(CO9)

開発期間の制約(CO6)

信頼性要求のレベル(CO5)

性能要求のレベル(CO3)

ユーザビリティ要求のレベル(CO2)

チームの知識・経験

(CO4)



5.2 【手順1】変動要因の抽出・定義 ②変動要因の定義

熟練者2、3名の協力を得て、ブレーンストーミングにより定義を取りまとめ

定義例

（簡易法）

定義のサンプルから、自組織に当てはまるものを選ぶ

IPA/SECの変動要因セット（19種）

「CoBRA法入門」付録Aに掲載の変動要因事例（ベンダ企業、ユーザ企業別）

CO 変動要因定義レベル３レベル２レベル１レベル0

CO1 関係者の協力度合い

関係者が回答期限を守る度合い

5％未満 5％以上50％未満

50％以上100％未満

100%

CO2 ユーザビリティ要求

利用者の特性 IT未経験者（一般）

IT経験者（一般）

組織内不特定特定メンバ

CO3 性能の要求レベル

応答時間例外なく反応時間1秒以内

50％の確率で1秒以内

例外なく3秒以内

50％の確率で3秒以内

CO4 チームの知識・経験

社内ﾗﾝｸによる割合

標準ﾒﾝﾊﾞが40％未満

標準ﾒﾝﾊﾞが40～60％未満

標準ﾒﾝﾊﾞが60～80％未満

標準ﾒﾝﾊﾞが80％以上

･･････････････････････････････

工数への影響大影響なし



5.2 【手順1】変動要因の抽出・定義 ③工数への影響度の評価

熟練者に対するアンケート、インタビューにより影響度を収集

（簡易法）

IPA/SECの変動要因セット（19種）の影響度の数値をそのまま使う

【例】 CO1：関係者の協力度合い最低もっとも可能性のある最大

関係者の協力がほとんど得られない場合（レベル3の場合）、工数は何％増えますか？

１５% ３０% ６０%

60% 30% 15%

Ａさんの回答

50% 20%

Ｂさんの回答

110% 40% 75%

Ｃさんの回答複数名に回答

３点の幅をもって確認

レベル3の場合の影響度を確認

他の変動要因についても、同様に設定三角分布と呼ぶ

確率

確率

確率

確率



5.2 【手順2】実績データの収集

規模、工数の実績データを6～10件用意

規模、工数の単位は、プロジェクト間で統一されていれば、何を使用しても良い。

各変動要因の工数への影響度を4段階（0～3）で評価

レベル0：工数に無影響

レベル3：工数に最も強く影響

レベル1、2：その中間段階の影響

番号

プロジェクト名称

規模［KSLOC］

工数［人月］

CO1 CO2 CO3 CO4 CO5 CO6 ・・・

1 プロジェクト1 10.3 9.2 0 1 1 1 1 1 ・・・ 2 プロジェクト2 8.8 7.5 1 2 2 3 3 1 ・・・ 3 プロジェクト3 21.3 18.7 0 1 1 0 1 1 ・・・ 4 プロジェクト4 42.5 52.1 0 2 1 1 2 2 ・・・ 5 プロジェクト5 5.2 6.3 0 1 0 0 1 1 ・・・ 6 プロジェクト6 22.3 18.2 1 1 1 1 2 2 ・・・

＜例＞



5.2 【手順3】モデルの構築 ①Σ COの計算（1/2）

Σ COi の計算手順

各変動要因のレベルを 0～3 の4段階で評価

各変動要因について、COiを計算（右図）

複数の三角分布から１つをランダムに選択

選んだ三角分布を、レベルに応じて変更

変更後の三角分布から、１点のコスト増加割合をランダムに選び、COi とする。

COiを全変動要因について合計し、Σ COi を得る。

変動要因 CO1 CO2 CO3 CO4 CO5 ・・・

レベル 1 0 2 1 3

③ コスト増加割合をランダムに選び、COiとする

② 値を1/3倍（レベルが1なので）

① ランダムに1つを選択

＜CO1の例＞

ツールで実施



0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

660

700

740

790

830

870

910

960

1000

1040

1080

1120

1170

1210

1250

1290

1340

1380

1420

見積工数

超過

確率

0

50

100

150

200

250

300

350

400

450

120 130 140 150 160 170 180 190 200 210 220 230 (%)

コストオーバヘッド（ΣCOi）

5.2 【手順3】モデルの構築 ①Σ COの計算（2/2）

以上を多数回（例えば5,000回）実施し、Σ COiの分布を得る。

多数回計算することで、分布が安定

計算は専用ツールで実施

分布の中央値をΣ COi として採用

得られた分布の中央値を採用

ツールで実施



5.2 【手順3】モデルの構築 ②α の計算

過去のプロジェクト・データを使って回帰分析し、α を計算

回帰分析

PJ実績規模工数 Σ COi （%）規模×(1＋Σ COi)

PJ-1 10.3KLOC 9.2人月 46.3 15.1

PJ-2 8.8KLOC 7.5人月 75.0 15.4

PJ-3 21.3KLOC 18.7人月 39.0 29.6

PJ-4 42.5KLOC 52.1人月 71.2 72.8

PJ-5 5.2KLOC 6.3人月 30.9 6.8

PJ-6 22.3KLOC 18.2人月 59.0 35.5

･･･････････････

工数＝α ×規模×（１＋Σ COi）

ツールで実施



相対誤差(%)

22.8%

56.7%

31.9% 29.7%

41.1%

6.3%

53.5%

8.1%

18.8%

3.1%

25.4%

0.0%

10.0%

20.0%

30.0%

40.0%

50.0%

60.0%

70.0%

80.0%

1 2 3 4 5 6 7 8 9 10 11

相対誤差(%)

8.9%

23.9%

10.3%

18.0% 17.9% 17.4%

25.5%

13.3%

4.6% 6.1%

19.2%

0.0%

10.0%

20.0%

30.0%

40.0%

50.0%

60.0%

70.0%

80.0%

1 2 3 4 5 6 7 8 9 10 11

PJ別の見積り誤差率

5.2 【手順4】見積り精度の改善

見積り精度（見積り誤差の程度）の確認

MMRE：見積り誤差率の平均値

Pred.25：見積り誤差率が25%以内のプロジェクトの割合

初期モデルの見積り精度： MMREが30～40%

見積り誤差の原因

変動要因の見落とし

実績データの計測ミス

変動要因のレベルの評定ミス（⇒ レベルの定義が曖昧）

・・・

モデルの見直しを繰り返し、見積り精度を向上

見積り精度の向上以外の効果

自組織のコスト構造に対する理解が深まる

気付かなかった特徴に対する「気付き」

構築した見積りモデルに対する「愛着」が湧く（⇒ 導入に対する抵抗を軽減）



5.3 CoBRAモデル構築のスケジュール例

2ヶ月で構築する場合の例

実施内容 1, 2週 3, 4週 5, 6週 7, 8週

変動要因の抽出と定義

変動要因の影響度の収集

プロジェクト情報の収集

初期モデル構築と改良点の分析

モデルパメータの見直し

見直し結果の評価

主要なマイルストーン ▲ ｷｯｸｵﾌ

▲ 改善ﾓﾃﾞﾙ

完成

▲ 初期ﾓﾃﾞﾙ

完成



ご紹介の内容



0

100

200

300

400

500

600

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

49 50 52 53 54 56 58 59 61 62 64 65 67 68 70 72

度数

予算

超過

確率


工数を指定して、その工数を超過する確率を計算

（56人月の見積り ⇒ 予算超過確率85%）

予算超過確率を指定して、見積り工数を逆算（予算超過確率20% ⇒ 62人月で見積もる）

6.1 予算超過リスクの分析

6．CoBRAモデルの応用

見積り工数： 59人月


6.3%

6.7%

8.3%

10.6%

11.6%

16.2%

16.4%

17.8%

25.2%

29.5%

0.0% 10.0% 20.0% 30.0% 40.0%


関係者の数






業務の複雑さ




6.2 工数のコントロール（影響度の高い要因の確認）

感度分析により、影響度の高い要因を把握例では、「見積り時の要求内容の曖昧さ」、「要求変更の発生想定時期」の影響度が高い

見積り時の要求内容の曖昧さ：レベル「２」

要求変更の発生想定時期：レベル「２」

影響度の高い要因について、軽減策を検討例えば、顧客とのQ&Aを通じて「見積り時の要求内容の曖昧さ」の軽減を図る



0

100

200

300

400

500

600

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

49 50 52 53 54 56 58 59 61 62 64 65 67 68 70 72

度数

予算

超過

確率


6.3 工数のコントロール（影響度の低減例）

0

50

100

150

200

250

300

350

400

450

500

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

47 48 48 50 51 52 53 55 56 57 58 60 61 62 63 65

度数

超過

確率


6.3%

6.7%

8.4%

10.6%

11.6%

14.8%

16.2%

16.4%

17.8%

25.1%

0.0% 10.0% 20.0% 30.0%


関係者の数







業務の複雑さ



①最初の見積り： 59人月

56人月だと予算超過確率85%

②プロトタイピングで要求を早期明確化。「見積り時の要求内容の曖昧さ」の影響を軽減（レベル「２」→「１」に）

③再見積り： 56人月でも大丈夫！



6.4 重点管理プロジェクトの把握

コストオーバーヘッドによる難易度比較複数の開発プロジェクトのコストオーバーヘッド（Σ CO）を比較。

Σ COが大きなプロジェクトを、難易度の高いプロジェクトとして抽出。オーバーヘッドが大きなプロジェクトほど、工数の変動量も大きい。

従って、工数超過の可能性が高い。

該当プロジェクトを重点監視対象対策案工数の予実乖離を定期的に監視

変動要因のレベルの軽減策を実施

プロジェクト規模 (FP)

見積り工数(人月)

Σ CO CO1 CO2 CO3 CO4 CO5 ・・・重点監視対象

Aシステム開発 1,200.0 78.9 174.2% 2 1 3 2 2 ・・・

Bシステム改修 500.0 31.5 164.1% 2 2 1 1 1 ・・・

Cシステム更改 700.0 65.5 290.5% 2 3 2 3 3 ・・・

Dシステム開発 800.0 48.3 153.3% 2 2 2 1 1 ・・・

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

プロジェクト規模 (FP)

見積り工数(人月)

Σ CO CO1 CO2 CO3 CO4 CO5 ・・・重点監視対象

Aシステム開発 1,200.0 78.9 174.2% 2 1 3 2 2 ・・・

Bシステム改修 500.0 31.5 164.1% 2 2 1 1 1 ・・・

Cシステム更改 700.0 65.5 290.5% 2 3 2 3 3 ・・・

Dシステム開発 800.0 48.3 153.3% 2 2 2 1 1 ・・・

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

✓



6.5 プロセス改善への応用

手順

1. CoBRAモデルを組織で活用し、プロジェクトの変動要因データを蓄積

2. 変動要因を分析

複数プロジェクトで共通に影響度の高い要因の有無

3. 共通要因の軽減・解消に向けた対策の検討

各要因ごとに改善計画

変動要因

データ

プロジェクト

プロジェクト

プロジェクト

共通要因

分析

対策検討

改善計画

プロジェクト

プロジェクト

プロジェクト

変動要因影響の軽減策の例

チームの経験・知識 ●メンバ教育 ●要員確保計画の策定・実施


●プロジェクトマネージャの教育 ●プロジェクトマネージャの支援体制の整備

システムの複雑さ ●システム可視化ツール等の導入

信頼性要求のレベル ●業務要求に応じた妥当な品質レベルを提案（過剰品質の回避） ●高信頼性技術・手法の導入


●プロトタイピングプロセスの導入 ●顧客の意思決定支援

・・・・・・・・・・・



ご紹介の内容



CoBRA法の実績：公開事例 IPA/SECとIESEの共同研究

沖電気殿、2005年 SEC Journal No.7 「ハイブリッドなコスト見積りモデルの反復的な構築方法について」、2006年

「CoBRA法入門」の事例（2007年）日立製作所殿

SEC Journal No.13 「CoBRA法に基づく工数見積りモデル構築への取り組み」、2008年プロジェクトマネジメント学会誌、Vol 10、No.6、2008年

NTTデータセキスイシステムズ殿三菱電機殿アイネス殿日新火災海上保険殿

日本IBM殿（2010年）社内のアプリケーション開発部門が開発要求元に提出する見積り

SEC Journal No.26 「CoBRA法を使った見積りモデル構築のポイント」、2011年

NTTデータセキスイシステムズ殿（2007年～現在）部内でCoBRAモデルによる見積りを制度化。内部コストのマネジメントに利用。

SEC見積りセミナー

三菱電機殿（2011年～現在）オフショアパートナー企業への導入と活用。共同でモデルを構築し、見積りプロセスに組込む。

SEC見積りセミナー

7．事例紹介


オフショアパートナー企業への導入と活用事例：三菱電機殿

背景

2007年に自社内向けのCoBRAモデルを構築

構築には成功したが、見積りプロセスとして組み込むまでにはいかなかった。

ソフトウェア開発においては、国内パートナー会社に加えて、２００４年度から海外オフショアの活用が拡大傾向

海外オフショアの作業見積りは、プログラム開発が中心であり、発注元の事業分野にはあまり影響されない

モデルを一つ作れば、すべての案件に適用できる可能性

目的

従来の標準生産性による見積りと平行して、変動要因（リスク）を考慮した見積りを作成し受発注側で共通認識を実現すること

継続的に開発を委託している会社とは同じゴールを目指すWin-Winの関係が構築できている。CoBRA法による見積りを通じて、両者でリスクの影響度、優先度及び対応策について認識を合わせ、力を合わせてリスクをコントロールできるようになることを期待

（出典）岩切博氏（三菱電機）、「オフショアマネジメントツールとしてのCoBRA法」、SECセミナー講演資料、2012年5月に基づく

7．事例紹介


ＣｏＢＲＡモデルの構築

【モデル構築体制】オフショア先合計10名（マネージャクラス：2名、開発リーダークラス：8名）

【モデル構築支援】委託元 2名

【対象プロジェクト数】 17プロジェクト（内3プロジェクトはモデル構築途中に除外）

【抽出された要因数】 12個

【導入のポイント】双方トップレベルで、目的の確認と共通認識（重要！）

双方で、推進体制の構築、標準プロセスへの組込み

現地での説明会（関係者への周知）

IPA/SECツールの活用

（出典）岩切博氏（三菱電機）、「オフショアマネジメントツールとしてのCoBRA法」、SECセミナー講演資料、2012年5月

7．事例紹介


モデル（変動要因）

プロジェクト要因

プロダクト要因

プロセス要因

人的要因

Ｃ０１

オフショアメンバーの開発技術スキル

Ｃ０４

当社（日本側）とオフショアチームのコミュニケーション

Ｃ０２

当社（日本側）の業務経験・知識

Ｃ０３

オフショアメンバーの開発プロセスの経験・知識

Ｃ０５

オフショアメンバーの業務経験・知識

Ｃ０６

オフショアＰＬのマネージャ経験・知識

Ｃ０７

オフショア担当の開発期間の制約

Ｃ０８


Ｃ０９

業務（データ）の複雑さ

Ｃ１０

システムの複雑性

Ｃ１１

フレームワークの利用可能度

Ｃ１２

当社（日本側）の参画度合い

工数


7．事例紹介


CO# レベル0定義レベル1定義レベル2定義レベル3定義

Ｃ０１ 80％以上確保（例．6人のうち5人以上） 65％以上80％未満確保（例．6人のうち4人） 50％以上65％未満確保（例．6人のうち3人） 50％未満確保（例．6人のうち2人以下）

Ｃ０２リーダに知識・経験があり、メンバの誰かはサポート可能。

リーダのみ知識・経験がある。リーダに知識・経験がないが、メンバの誰かはサポート可能。

全員が初めての業務。

Ｃ０３下記のすべてを満たす。

・過去一緒に同じプロセスでした経験がある。

・様式も既に確定している。

・設計基準、コーディングが確定している。

下記のいずれか２つを満たす。




下記のいずれか１つを満たす。




プロセスは経験なし、様式、設計基準、コーディングも確定していない。

Ｃ０４日本側プロジェクトPM、PLと一緒にプロジェクト開発経験があり。

日本側プロジェクトPMまたはPLのどちらかと一緒にプロジェクト開発経験があり。

日本側プロジェクトのTL、メンバーと一緒にプロジェクト開発経験があり。

日本側PJ担当部署とのプロジェクト開発経験がない。

Ｃ０５リーダに知識・経験があり、メンバの誰かはサポート可能。

リーダのみ知識・経験がある。リーダに知識・経験がないが、メンバの誰かはサポート可能。

全員が初めての業務。

Ｃ０６プロジェクトマネージャの経験本数が6件以上、又は経験年数で丸3年以上。

プロジェクトマネージャの経験本数が3件以上（6件未満）、又は経験年数で丸2年以上（3年未満）。

プロジェクトマネージャの経験本数が1件以上（3件未満）、又は経験年数で丸1年以上（2年未満）。

プロジェクトマネージャを未経験（今回が初めての経験）。

Ｃ０７妥当な工期どおり。またはそれ以上の期間がある。

妥当な工期から、10％未満圧縮。妥当な工期から、10％以上30％未満圧縮。妥当な工期から、30％以上圧縮。

Ｃ０８要求仕様書があり、設計仕様をイメージできる要求事項の比率が9割以上。

要求仕様書があり、設計仕様をイメージできる要求事項の比率が7割以上9割未満。

要求仕様書があり、設計仕様をイメージできる要求事項の比率が5割以上7割未満。

下記のいずれかを満たす。

・要求仕様書がない（口頭のみ）。

・設計仕様をイメージできる要求事項の比率が5割未満。

Ｃ０９・テーブル数：10未満。

・外部I/Fのフォーマット数：0（なし）。

・テーブル数：10以上45未満。

・外部I/Fのフォーマット数：1以上15未満。

・テーブル数：45以上100未満。

・外部I/Fのフォーマット数：15以上30未満。

・テーブル数：100以上。

・外部I/Fのフォーマット数：30以上。

ＣO１０画面、帳票、アルゴリズムのすべてにおいて複雑なものがない。

画面、帳票、アルゴリズムのいずれか1つが複雑。

画面、帳票、アルゴリズムのいずれか2つが複雑。

画面、帳票、アルゴリズムのすべてが複雑。

ＣO１１過去に使用したフレームワークがそのまま使用できる。

日本側の案件で過去に使ったものが流用できる。

日本側の案件では流用できるフレームワークがないが、ｵﾌｼｮｱ側には類似のフレームワークがある。

全く新規に利用するフレームワークである。

ＣO１２下記のすべてを満たす。

・日本側窓口が専任

・日本側窓口のレスポンスが良い。（３日間以内の回答）

・利用者（エンドーユーザ）が参加している。

下記のいずれか2つが満たされる。

・日本側窓口が専任である。


・利用者（エンドーユーザ）が参画している。

下記のいずれか1つが満たされる。

・日本側窓口が専任である。


・利用者（エンドーユーザ）が参画している。

下記のすべてを満たす。

・日本側窓口が兼任。

・日本側窓口のレスポンスが悪い。（３日間以内に回答がない）

・利用者（エンドーユーザ）が参画していない。

変動要因の定義参考


7．事例紹介


モデル構築と改善～最終モデル完成

工数算定式工数= α × 規模 × (1 + Σ COi) α =0.44

参考


7．事例紹介


変動要因モデルの特徴

CO# 要因名称カテゴリ変動要因の主な関係先

オフショア側日本側システム要件

Ｃ０１オフショアメンバーの開発技術スキル人的要因 ●

Ｃ０２当社（日本側）の業務経験・知識 ●

Ｃ０３オフショアメンバーの開発プロセスの経験・知識 ●

Ｃ０４当社（日本側）とオフショアチームのコミュニケーション ● ●

Ｃ０５オフショアメンバーの業務経験・知識 ●

Ｃ０６オフショアＰＬのマネージャ経験・知識 ●

Ｃ０７オフショア担当の開発期間の制約プロジェクト要因 ●

Ｃ０８見積り時の要求内容の曖昧さプロダクト要因 ●

Ｃ０９業務（データ）の複雑さ ●

ＣO１０システムの複雑性 ●

ＣO１１フレームワークの利用可能度 ●

ＣO１２当社（日本側）の参画度合いプロセス要因 ●

オフショア先は物作りが主体作業のため、開発作業を進める「人的要因」と、開発のインプットとなる「システム要件」の変動要因を重視

→開発する「システム要件」の明確化と、オフショア側の適切な「開発体制」作りがポイント


7．事例紹介


導入・活用の効果：結果

見積り工数に大きく影響する変動要因を「全て」「定量的に」相互に共通認識できるようになった。

その結果、プロジェクト推進中に適切にリスクをコントロールすることにより、プロジェクトを成功（品質、工期）へと導く確率が向上

変動要因の共通認識の深化

完了時点で、再度変動要因（ＣＯ）の状況を評価することにより、「見積り時点、計画時点の問題」を再認識

完了時点で、再度変動要因（ＣＯ）の状況を評価することにより、「プロジェクト遂行時の変動要因コントロールの問題」を再認識

パートナー企業との相互信頼関係強化

コミュニケーションのツールとして、お互いに主なリスクの認識に効果

パートナー内部として、リスクを明記することで、リスクを軽減

ＣｏＢＲＡ手法の運用に伴って、過去の分析結果により見積精度の改善に役立つ


7．事例紹介


導入・活用の効果：前提条件

Ｗｉｎ-Ｗｉｎの関係が出来上がっているパートナーとの取引

または、ＣｏＢＲＡ導入をきっかけとして、双方で強いパートナー関係の構築を望むこと

発注金額のみが優先されるプロジェクトではないこと

開発規模が途中で大きく変動しないような比較的安定したプロジェクト、またはコントロール可能なプロジェクトであること


7．事例紹介


おわりに


まとめ：見積りの課題の解決方針

対策①：見積り手法の確立

⇒見積りモデルの確立

対策②：見積りの妥当性の確保

⇒複数の見積り方法によるレビュー

⇒見積りモデルによる前提を変えたシミュレーションはその一つ

対策③：モニタリングとコントロールと再見積り

⇒見積りモデルに対する前提条件とインプットの変化のモニタリング

⇒コントロールによるブレ防止と再見積りによる変化への追随

（見積りモデルによる条件を変えてのシミュレーション）

対策④：目標と見積りの峻別

⇒見積りモデルを活用した見積りプロセスの確立



まとめ：CoBRA法の特徴

自組織のコンテキストに合った見積りモデルの構築を可能とする。

モデル構築に必要なもの

実績の拡大

１．組織固有のコスト変動要因をモデル化

２．コスト変動要因に、熟練者の優れた「勘」「経験」を反映

１．熟練者2、3名の協力

２．過去プロジェクト10件程度

１．内部コストのマネジメント（見積りとコントロール）

２．オフショア・パートナーとの見積り時のコミュニケーション手段


まとめ：CoBRA法の効果

CoBRA法プロセス改善

組織に共通する要因を把握し、軽減・解消

工数の説明力向上コスト変動要因と

影響度の見える化

コストマネジメント力向上工数コントロールのポイント（影響度の高い要因）の把握

見積りリスク把握工数変動量から

予算超過確率を把握

アセット化と属人性排除熟練者の優れた知見をモデル化し、共有・活用


ご静聴ありがとうございました。

Email：[email protected]

ソフトウェア開発見積りの課題と解決方法

～見積り手法の歴史とCoBRA法～

mailto:[email protected]

Documents

ソフトウェア開発見積りの課題と解決方法•COCOMO さまざまな見積り •一方、キャリブレー ション（較正）の必要 性の認識 •多数のデータから

ソフトウェア開発見積りの課題と解決方法•COCOMO さまざまな見積り •一方、キャリブレーション（較正）の必要性の認識 •多数のデータから