CoBRA研究会幹事
熟練者の「勘」を見える化するCoBRA法
2012年6月1日
先進ソリューションセンター
石谷 靖
１．見積り根拠の「見える化」
２．CoBRA法の概要
３．CoBRAモデルの構築方法
４．CoBRAモデルの応用
２．CoBRA法の概要
３．CoBRAモデルの構築方法
４．CoBRAモデルの応用
1.1 見積り根拠の「見える化」の重要性
見積り根拠が「見えない」ことによる問題
ユーザ（発注者）
• 金額（工数）の妥当性が
分からない。
• 危険性（予算不足・過剰）
が分からない。
• 無理な値下げによる品
質低下。
• 根拠のある価格交渉が
できない。
ベンダ（受注者）
• 見積りの妥当性を説明
できない。
• 予算が厳しいことを納得
してもらえない。
• 予算に合わせて工数をコ
ントロールできない。
見積り根拠の「見える化」 ＝ コスト構造の「見える化」 が重要
1.2 見積り根拠の「見える化」の課題
規模だけでは工数を説明できない。
工数の「ブレ」を説明できる手段が必要。
×
×
×
×
×
×
×
×
×
×
×
×
×
×
×
×
×
規模
工
数
規模がほぼ同じでも、必要な
工数に違いがある。
1.3 「見える化」の具体的な解決策 ～CoBRA法～
１．組織固有のコスト変動要因をモデル化
CoBRA法の5つの特徴
２．コスト変動要因に、熟練者の優れた「勘」「経験」を反映
４．予算超過リスクの定量評価を実現
５．プロセス改善のポイントを把握
３．工数のコントロールを実現
２．CoBRA法の概要
３．CoBRAモデルの構築方法
４．CoBRAモデルの応用
45人月でしょ！
おぉ！！！
熟練者
（経験20年）
担当者
（経験5年）
RFP
2.1 CoBRA法のコンセプト ～「勘」「経験」を見える化する
優れた「勘」「経験」を見積りに活用
ベテランの見積りは妥当なことが多い
将来の見通しについては「勘」「経験」に頼らざ
るを得ない
「勘」「経験」のみの見積りには問題が・・・
「勘」「経験」を有するベテラン以外は使えない
（ノウハウ共有が困難）
見積り結果の正しさを説明することが難しい
（説明力の不足）
解決策： 「形式知化し、実績データで検証」
モデル化により、優れたノウハウを共有
「勘」「経験」の正しさを「
実績データ
」で検証
新しい
科学的な
「KKD」
勘
（K）
データ
（D）
経験
（K)
2.2 CoBRA法における工数見積りの考え方
工数
α×規模
CO
×
×
×
×
×
×
×
×
×
×
×
×
×
×
×
×
×
「規模がほぼ同じでも、かかる工数に違いがある。」
⇒ 現実の工数を、ベースの生産性αと、そこからの
オーバーヘッド（CO）により説明
実績データ
に照らして、変動要因と
その定量化を検証し、
α
を計算
2.3 CoBRA法の工数見積り式
工数 ＝
α
×
規模
× （
１ ＋ Σ
CO
i
）
過去プロジェクト
規模
工数
PJ-1
10.3KLOC
9.2人月
PJ-2
8.8KLOC
7.5人月
PJ-3
21.3KLOC 18.7人月
PJ-4
42.5KLOC 52.1人月
PJ-5
5.2KLOC
6.3人月
PJ-6
22.3KLOC 18.2人月
･･･････
･････
････
コスト変動要因のオーバヘッドを考慮
経験豊富な
PL等の
熟練者の知見
を
基に、変動要因とその影響を定量化
確率
影響度(%)
C氏
B氏
A氏
補完
2.4 CoBRA法の位置づけ
見積り手法
データ駆動型
• COCOMO
• OSR®
• CART
• ANOVA
過去のプロジェクト
データに基づく
経験ベース型
• 専門家による見積り
• 見積りミーティング
• デルファイ法
基本的に熟練者の経験
のみを利用
ハイブリッド型
過去のプロジェクトデータと
熟練者の経験を利用
3名程度の熟練者と10個程度の
実績データから見積りモデル構築
•
CoBRA法
2.5 工数見積りの手順
工数見積りの手順
①規模の推定
②変動要因の
影響度の評価
③見積りの実行
見積もる対象のプロジェクトの開発量
（規模）を想定
各変動要因の影響度を評価
（0～3の4段階）
見積りを実行し、結果を確認
（ツールを使用）
工数 ＝ α × 規模 × （ １ ＋ ΣCOi ）
①
②
③
2.6 ツールでの見積り手順 ①想定規模の入力
① 想定規模
を入力
2.6 ツールでの見積り手順 ②変動要因レベルの入力
② 変動要因
のレベルを
入力
① 想定規模
を入力
2.6 ツールでの見積り手順 ③見積りの実行と結果の確認
見積り結果
予算超過確率
感度分析
③ 見積り実行
② 変動要因
のレベルを
入力
2.7 CoBRAツール （IPA/SEC提供）
簡易ツール
CoBRA法の体験版
IPA/SECのホームページにログイン後に、所定のURLから使用
http://sec.ipa.go.jp/tool/cobra/
２００７年度の実証実験の集約データを参考値として搭載
Webブラウザがあれば利用可能
統合ツール
CoBRA法のフル機能版
Excelアプリケーション
IPA/SECのホームページからダウンロードして利用
一から
独自の見積りモデルを作成
100 200 300 400 500 600 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.2 0.4 0.6 0.8 1.0 工数 予算超過 確率 960 1420 880 1260 660 見積値（中央値） 0.1
2.8 CoBRAモデルの利用シーン
コストマネジメント
リスクマネジメント
プロセス改善
プロジェクトマネージャ
PMO、品質管理部門
24.6 19.4 16.8 15.5 9.8 0.0 10.0 20.0 30.0 40.0 要求変更の度合い 見積り時の要求内容の曖昧さ 業務の複雑さ 信頼性要求のレベル システムの複雑性 [%]工数見積り
予算超過リスクの評価
影響度の高い要因の対策と解消
2.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
9組織 （2011年7月現在）
(株)アイネス、(株)NTTデータセキスイシステムズ、沖電気工業(株)、人事院（CIO補佐官）、
大同生命(株)、日新情報システム開発(株)、(株)日立製作所、（株)三菱総合研究所、三菱電機(株)
※50音順
ガイド発刊
CoBRA法入門 －「勘」を見える化する見積り手法 （2011年4月、オーム社）
支援ツールの無料公開 （2010年3月）
（独）情報処理推進機構 ソフトウェア・エンジニアリング・センター
「CoBRA法に基づく見積り支援ツール」 （
http://sec.ipa.go.jp/tool/cobra/
）
１．見積り根拠の「見える化」
２．CoBRA法の概要
３．CoBRAモデルの構築方法
４．CoBRAモデルの応用
５．事例紹介
3.1 CoBRAモデルの構築手順
CoBRAモデルの構築手順
①変動要因の抽出・定義
②実績データの収集
③モデルの構築
熟練者
2、3名
の協力の下に、変動要因
を抽出・定義し、工数への影響度を設定
過去プロジェクト
10件程度
について、
規模と工数の実績データを収集し、各
変動要因のレベルを設定
支援ツール
を用いて見積りモデルを
構築し、見積り精度を確認
工数 ＝ α × 規模 × （ １ ＋ ΣCOi ）
②
①
④見積り精度の改善
モデルを見直し、見積り精度を改善
初期モデル
改善モデル
3.2 【手順1】変動要因の抽出・定義 ①変動要因の洗い出し
熟練者2、3名の協力を得て、自組織に特有の変動要因をブレーンストーミン
グにより抽出
抽出例
（簡易法）
変動要因のサンプルから、自組織に当てはまるものを選ぶ
工数
関係者の
協力度合い
(CO1)
要件の不安定性
(CO8)
要件管理の
確実さ(CO7)
既存システム
の整備状況
(CO10)
ソフトの複雑さ
(CO9)
開発期間の
制約(CO6)
信頼性要求の
レベル(CO5)
性能要求の
レベル(CO3)
ユーザビリティ要求
のレベル(CO2)
チームの
知識・経験
(CO4)
3.2 【手順1】変動要因の抽出・定義 ②変動要因の定義
熟練者2、3名の協力を得て、
ブレーンストーミング
により定義を取りまとめ
定義例
（簡易法）
定義のサンプルから、自組織に当てはまるものを選ぶ
IPA/SECの変動要因セット（19種）
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％以上
･･
･･･････
･････
････
････
････
････
工数への影響大
影響なし
3.2 【手順1】変動要因の抽出・定義 ③工数への影響度の評価
熟練者に対するアンケート、インタビューにより影響度を収集
【例】 CO1：関係者の協力度合い
最低
もっとも可能性のある
最大
関係者の協力がほとんど得られない場合（レベ
ル3の場合）、工数は何％増えますか？
１５%
３０%
６０%
60%
30%
15%
Ａさんの回答
50%
20%
Ｂさんの回答
110%
40%
75%
Ｃさんの回答
複数名に回答
３点の幅をもって確認
レベル3の場合の影響度を確認
他の変動要因についても、同様に設定
三角分布と呼ぶ
確
率
確
率
確
率
確
率
3.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 ・・・
＜例＞
3.2 【手順3】モデルの構築 ①ΣCOの計算 （1/2）
ΣCOi の計算手順
各変動要因のレベルを 0～3 の4段階で評価
各変動要因について、COiを計算 （右図）
複数の三角分布から１つをランダムに選択
選んだ三角分布を、レベルに応じて変更
変更後の三角分布から、１点のコスト増加割合
をランダムに選び、COi とする。
COiを全変動要因について合計し、ΣCOi を
得る。
変動要因
CO1
CO2
CO3
CO4
CO5
・・・
レベル
1
0
2
1
3
③ コスト増加割合をランダムに選び、
② 値を1/3倍 （レベルが1なので）
① ランダムに1つを選択
＜CO1の例＞
ツールで実施
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
660 700 740 790 830 870 910 960 10
00
10
40
10
80
11
20
11
70
12
10
12
50
12
90
13
40
13
80
14
20
見積工数
超過確率
0
50
100
150
200
250
300
350
400
450
120 130 140 150 160 170 180 190 200 210 220 230 (%)
コストオーバヘッド （
ΣCOi）
3.2 【手順3】モデルの構築 ①ΣCOの計算 （2/2）
以上を多数回（例えば5,000回）実施し、ΣCOiの分布を得る。
多数回計算することで、分布が安定
計算は専用ツールで実施
分布の中央値をΣCOi として採用
得られた分布の
中央値を採用
ツールで実施
3.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
･･･
･･･
･･･
･･･
･･･
ツールで実施
相対誤差(%)
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別の見積り誤差率
3.2 【手順4】見積り精度の改善
見積り精度（見積り誤差の程度）の確認
MMRE： 見積り誤差率の平均値
Pred.25： 見積り誤差率が25%以内のプロジェクトの割合
初期モデルの見積り精度：
MMREが30～40%
見積り誤差の原因
変動要因の見落とし
実績データの計測ミス
変動要因のレベルの評定ミス
（⇒ レベルの定義が曖昧）
・・・
モデルの見直しを繰り返し、見積り精度を向上
見積り精度の向上以外の効果
自組織の
コスト構造に対する理解が深まる
気付かなかった特徴に対する「気付き」
3.3 CoBRAモデル構築のスケジュール例
2ヶ月で構築する場合の例
実施内容
1, 2週
3, 4週
5, 6週
7, 8週
変動要因の抽出と定義
変動要因の影響度の収集
プロジェクト情報の収集
初期モデル構築と改良点の
分析
モデルパメータの見直し
見直し結果の評価
主要なマイルストーン
▲
ｷｯｸｵﾌ
▲
改善ﾓﾃﾞﾙ
完成
▲
初期ﾓﾃﾞﾙ
完成
１．見積り根拠の「見える化」
２．CoBRA法の概要
３．CoBRAモデルの構築方法
４．CoBRAモデルの応用
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
度数
予算超過確率
見積り工数 [人月]
工数を指定して、その工数を超過する確率を計算
予算超過確率を指定して、見積り工数を逆算
（予算超過確率20% ⇒ 62人月で見積もる）
4.1 予算超過リスクの分析
見積り工数： 59人月
6.3%
6.7%
8.3%
10.6%
11.6%
16.2%
16.4%
17.8%
25.2%
29.5%
プロジェクトマネージャの経験・知識
関係者の数
顧客の参画度合い
開発期間の厳しさ
チームの経験・知識
信頼性要求のレベル
システムの複雑さ
業務の複雑さ
要求変更の発生想定時期
見積り時の要求内容の曖昧さ
変動要因の寄与度
4.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
度数
予算超過確率
見積り工数 [人月]
4.3 工数のコントロール （影響度の低減例）
0
50
100
150
200
250
300
350
400
450
500
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
度数
超過確率
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%
②プロトタイピングで要求を早期
明確化。「見積り時の要求内
容の曖昧さ」の影響を軽減
（レベル「２」→「１」に）
4.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
・・・
4.5 プロセス改善への応用
手順
1.
CoBRAモデルを組織で活用し、プロジェクトの変動要因データを蓄積
2.
変動要因を分析
複数プロジェクトで
共通に影響度の高い要因
の有無
3.
共通要因の軽減・解消に向けた対策の検討
各要因ごとに改善計画
変動要因
データ
プロジェクト
プロジェクト
プロジェクト
共通要因
分析
対策検討
プロジェクト
プロジェクト
プロジェクト
変動要因
影響の軽減策の例
チームの経験・知識
●メンバ教育
●要員確保計画の策定・実施
プロジェクトマネー
ジャの経験・知識
●プロジェクトマネージャの教育
●プロジェクトマネージャの支援体制の整備
システムの複雑さ
●システム可視化ツール等の導入
信頼性要求のレベル
●業務要求に応じた妥当な品質レベルを提案
（過剰品質の回避）
●高信頼性技術・手法の導入
見積り時の要求内容
の曖昧さ
●プロトタイピングプロセスの導入
●顧客の意思決定支援
２．CoBRA法の概要
３．CoBRAモデルの構築方法
４．CoBRAモデルの応用
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見積りセミナー
オフショアパートナー企業への導入と活用事例：三菱電機殿
背景
2007年に自社内向けのCoBRAモデルを構築
構築には成功したが、見積りプロセスとして組み込むまでにはいかなかった。
ソフトウェア開発においては、国内パートナー会社に加えて、２００４年度から海外
オフショアの活用が拡大傾向
海外オフショアの作業見積りは、プログラム開発が中心であり、発注元の事業分
野にはあまり影響されない
モデルを一つ作れば、すべての案件に適用できる可能性
目的
従来の標準生産性による見積りと平行して、変動要因（リスク）を考慮した見積り
を作成し受発注側で共通認識を実現すること
継続的に開発を委託している会社とは同じゴールを目指すWin-Winの関係が構
築できている。CoBRA法による見積りを通じて、両者でリスクの影響度、優先度
及び対応策について認識を合わせ、力を合わせてリスクをコントロールできるよう
になることを期待
ＣｏＢＲＡモデルの構築
【モデル構築体制】 オフショア先 合計10名
（マネージャクラス：2名、開発リーダークラス：8名）
【モデル構築支援】 委託元 2名
【対象プロジェクト数】 17プロジェクト
（内3プロジェクトはモデル構築途中に除外）
【抽出された要因数】 12個
【導入のポイント】
双方トップレベルで、目的の確認と共通認識（
重要！
）
双方で、推進体制の構築、標準プロセスへの組込み
現地での説明会（関係者への周知）
IPA/SECツールの活用
モデル（変動要因）
プロジェクト要因
プロダクト要因
プロセス要因
人的要因
Ｃ０１
オフショアメンバーの開発技術スキル
Ｃ０４
当社（日本側）とオフショアチームの
コミュニケーション
Ｃ０２
当社（日本側）の業務経験・知識
Ｃ０３
オフショアメンバーの開発プロセスの
経験・知識
Ｃ０５
オフショアメンバーの業務経験・知識
Ｃ０６
オフショアＰＬのマネージャ経験・知識
Ｃ０７
オフショア担当の開発期間の制約
Ｃ０８
見積り時の要求内容の曖昧さ
Ｃ０９
業務（データ）の複雑さ
Ｃ１０
システムの複雑性
Ｃ１１
フレームワークの利用可能度
Ｃ１２
当社（日本側）の参画度合い
工数
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つが満たされる。 ・日本側窓口が専任である。 ・日本側窓口のレスポンスが良い。（３日間 下記のすべてを満たす。 ・日本側窓口が兼任。 ・日本側窓口のレスポンスが悪い。（３日間
