ソフトウェア開発プロジェクトにおける開発計画の分析| 品質，生産性との関連性 |稲垣 勝巳 y ，高木 徳生 y ，坂本 啓司 y
水野 修 z ，菊野 亨 zy オムロン (株) ソーシアル事業グループ 開発・生産センタ
Phone (0775)65-5071

FAX (0775)65-5579

e-mail : inagaki@eftses.krc.omron.co.jpz大阪大学 大学院基礎工学研究科 情報数理系専攻

本研究ではソフトウェアプロジェクトのための開発計画の良さ (コスト予測の精度の高さ) が出荷後のソフトウェアの品質 (フィールド 品質) と開発チームの生産性に及ぼす影響について，31 件の実際のプロジェクトから収集したデータを用いて分析する．得られた主な結論は次の通りである．(1) 開発計画が標準手順に準拠している度合と，実際に計画通りに実行される度合が高いほどその計画のコスト予測の精度が上がる．(2) コスト予測の精度が 10%未満のプロジェクトとそれが 10%以上のプロジェクトではフィールド 品質とチーム生産性のいずれも有意的な差がある (有意水準 5%の統計的仮説検定より)．
キーワード : ソフトウェアプロジェクト，開発計画，ソフトウェア品質，生産性，統計的仮説検定

E ects of Cost Estimation Accuracy onQuality and Productivity
Katsumi Inagakiy , Yasunari Takagiy , Keishi Sakamotoy ,Osamu Mizunoz and Tohru Kikunoz

y Development and Production H.Q., Social Systems Business Group,
OMRON Corporation, Japan
Phone +81-775-65-5071

FAX +81-775-65-5579

e-mail : inagaki@eftses.krc.omron.co.jpzDepartment of Informatics and Mathematical Sciences,

Graduate School of Engineering Science, Osaka University

This paper discusses the e ects of the estimation accuracy(measured by relative error, RE ) forsoftware development cost on both the quality(measured by F R) of the delivered codes and the productivity(measured by P T ) of the development team. Using actual data on the thirty one projects at OMRON Corp.,
the followings are veri ed by statistical analysis : (1) The higher the completeness of development plan is, thesmaller the RE is. (2) Both F R and P T are signi cantly di erent between projects with 010% < RE < 10%
and projects with RE  10%.
Keywards: software project, development plan, software quality, productivity, test of statistical hypotheses

1 まえがき
ソフトウェア開発における品質と生産性向上の重要性が指摘されている．もっとも有望な取り組みとしてプロセス改善 [2] が注目され，多くの試みが報告されてきている [3][6][8][9]．
プロセス改善をより効果的に実現するためには適切な開発計画の作成とその実施が必要となる [1][12]．もし不適切な計画を与えられり，計画は適切であるがその履行に問題があると，せっかくの改善計画も計画倒れとなり実行できないために，結局はプロセス改善に失敗すると考えられる．
開発現場にとって開発計画の作成と履行の適切さを判断する直観的で，かつ，受け入れやすい 1 つの基準
は開発コストが 見積り通りであったかど うかである[13][14][15]．一般的に開発コストは働いた人間の延べ人数に近似的に等しいと考えられるので，開発期間 (作業時間) や作業者の技術レベルなども間接的に含めて評価されていると考えてもよい．
ここで，この開発計画の適切さを開発コストが見積りから大きく崩れなかったことと考える理由は，そうしたプロジェクトでは品質や生産性が安定しており，しかもよい値を示しているためである．ここで品質とは出荷後の製品に含まれるフォールト数 (フィールド品質) のことであり，生産性とはチーム当たりの開発規模をその開発に要した延べ工数で割って求めたもの(チーム生産性) とする．
そこで本研究では「開発コストの見積りが大きく崩れなかったプロジェクトでは品質や生産性が安定している．しかも品質や生産性の値そのものも高い」こと
を開発現場で収集した 31 件のプロジェクトのデータを利用して示すことを目的とする．
その準備として，開発コストの見積りのずれの少ない (すなわち，コスト予測精度の高い) 開発計画の状況を詳細に調べる．そのためにプロセス改善グループ(SEPG: Software Engineering Process Group) で行った「開発計画の評価」に基づいて，その評価点と予測精度の大小の関係を調べる．
次に，予測精度の大小とフィールド 品質の関連性，および，予測精度の大小とチーム生産性の関連性について調べる．なお，分析に当たっては，有意水準 5%の統計的仮説検定を用いる．

2 研究の背景と目的
2.1

背景

オムロン (株) ソーシアル事業グループでは，この 5年間にわたって，全ての開発プロジェクトにおいてソフトウェア品質と開発チームの生産性の向上を目的としたプロセス改善活動を展開してきている [6][9]．このプロセス改善活動には専任者が割り当てられ，ソフトウェアメトリクス [1][7][10] を利用した改善活動を行なっている．ソフトウェアメトリクスは，プロセス改善活動の効果を定量的に検証するために利用されており，次のようなデータが各プロジェクトにおいて収集されてきた．

 開発計画 開発規模 工程ごとの工数
 工程ごとのフォールト数 出荷後のフォールト数
また，年度ごとに収集されたデータを集計し，傾向を分析してきている．特に開発計画の作成には力を入れてきたため，どれくらいのプロジェクトでプロジェ
クト管理手順に準拠した開発計画書が作成されているかという割合は年々上昇している [8]．その結果としてプロジェクトの予測した開発コストと実績値の差 (計画のコスト予測精度と呼ぶ) が小さくなっていく傾向にある．なお，収集されている開発コストは金額を単位とするものと人月を単位とするものがあるが，ここでは人月に対する値を用いるものとする．
一方，出荷後一定期間内に発見されるソフトウェアフォールトの件数 (フィールド 品質と呼ぶ) も安定化，かつ，減少する傾向にある．それと同時に再利用分も含めて開発者の全ての生産性 (チーム生産性と呼ぶ) も年々安定化し，かつ，向上する傾向にある．
そこで，ソフトウェア品質の向上と開発者生産性の向上の両方にとって開発計画のコスト予測精度の向上が有効であるのではないだろうかと推測するに至った．

2.2

研究の目的

2.1で述べたような事情から，本研究では次の 3 つの命題 (A1), (A2), (A3) が成り立つことをオムロン (株)ソーシアル事業グループにおいて実施した 31 件のプロジェクトの開発データを用いて実証することを目指す．
(A1) 開発計画が標準手順に準拠している度合が高いほどその計画のコスト予測精度も高い．

1 1 1 制定されているプロジェクト計画のための標準手続きに従って開発計画が作成されていて，しかもその計画通りに実行されたプロジェクトのコスト変動は小さいことを主張する．

(A2) コスト予測精度の高い開発計画の下で実施されたプロジェクトにおいてはフィールド 品質も高い．

1 1 1 結果的にほぼ見積り通りの開発コストで終了したプロジェクトにおいては，開発されたプロダ

クトの出荷後一定期間内に発見されるフォールトの数が少ないことを主張する．

(A3) コスト 予測精度の高い開発計画の下で実施されたプロジェクトにおいてはそのチーム生産性が高い．

1 1 1 ほぼ見積り通りの開発コストで終了したプロ
ジェクトにおいては，そのプロジェクトに参加した開発者全員の生産性 (平均的な意味での生産性)が高いことを主張する．

3.2

ソフト ウェア開発に関するメト リクス

本研究ではソフトウェア開発を品質と生産性の両面から分析，評価するため次のメトリクス [1][7][12] を用いる．

1. 開発規模 SLC
再利用分も含めて設計，コーディングしたソースコードの行数を表す．但し，コメント行は全て除いて集計する．なお，再利用分についてはその修正の度合に応じて行数を計算している．
以降では次の記号を用いる．

3

メト リクスの定義

3.1

開発プロセスモデル

SLC 1 1 1 開発規模 (単位は Kstep である)．
newSLC 1 1 1 新規開発した部分のソースコードのオムロン (株) ソーシアル事業グループでは，ATM(Automated Teller Machines)，POS(Point OfSales) 端末，券売機などの多くのソフトウェア組込み型機器を製造している．このような組み込み型ソフトウェアの開発は図 1に示す開発プロセスに従って行われる．
開発プロセスは設計フェーズとディバッグフェーズに分けられる．設計フェーズの 1 つの特徴は各設計作業工程，コーディング作業工程の後に必ずレビュー作業工程が配置されていることである．一方，ディバッグフェーズの特徴は単体，統合，機能，検証の４種類の異なる目的を持ったテスト，ディバッグが繰り返されていることである．

Design Phase
Concept Design(CD)Concept Design Review(CDR)
Function Design(FD)FunctionDesign Review(FDR)
Structure Design(SD)
Structure Design Review(SDR)
ModuleDesign(MD)
Module Design Review(MDR)

Debug Phase
Unit Test(UT)
Unit Debug(UDB)
Integration Test
(IT)
Integration Debug(IDB)
Function Test
(FT)
Function Debug(FDB)
Verification Test
(VT)
Verification Debug(VDB)

Coding(PG)
Coding Review
(PGR)

行数．

slgSLC 1 1 1 若干の修正を行って再利用した部分のソースコードの行数．

extSLC 1 1 1 大幅な修正を行った上で再利用したソースコードの行数．

;

1 1 1 補正係数．

このとき開発規模 SLC は次式で定義される．

SLC = newSLC +2 slgSLC + 2 extSLC

2. フィールド 品質 F R
ソフトウェア出荷後の一定期間 (6ヵ月) 以内に発見されるフォールトの件数をその開発規模で正規化したもので，作成されたソフトウェアプロダクトの品質を測る．
以降では次の記号を用いる．

FR 1 1 1 ソフトウェアのフィールド 品質 (単位は件/Kstep である)．
#Fault 1 1 1 出荷後の６ヵ月間に発見されたフォールトの総数．
このときフィールド 品質 FR は次式で定義される．

FR =#F ault

SLC

3. チーム生産性 P T
プロジェクトに参加した開発チームの開発者全員の生産性の平均値を測る．具体的には，その開発チームで作成した全てのソフトウェアの開発規模をその開発に要した延べ工数で割って求める．
以降では次の記号を用いる．

図 1: 開発プロセスモデル

PT 1 1 1 チーム生産性 (単位は Kstep/人月 である) ．

E ort 1 1 1 開発に要した人月の総和．ているか，などと同時に，WBS 中で定義された各作業が PERT 図上でも矛盾なく定義されていることを確認する．成果物一覧表については各作業での出力プロダクトが定義されていることを確認する．

このときチーム生産性 P T は次式で定義される．

PT =
3.3

SLCEffort

次に実行したプロジェクトの計画の充足度 satCTに関しては次の 2 点を中心に評価する．

開発計画に関するメト リクス

1. コスト予測精度 RE(e) ソフトウェアレビュー

開発計画の適切さ，あるいは，妥当さを直観的に測るためのもので，計画段階で想定した開発に要するコストと実際にかかったコストの差を評価する．ここでは，コストの単位は人月とする．

(f) 進捗管理
具体的には，品質と相関が高いことが確認されているソフトウェアレビュー [10] が十分に行われていることをレビュー工数比率というメトリクス(レビュー工数を開発工数で割った値) を用いて評価する．更に，開発計画を忠実に守ってプロジェクトを進めるために，その実行を支援するための進捗管理がなされてきたことを管理者へのインタビュー，各種管理支援ツールの利用状況の調査を通じて行う．

以降では，次の記号を用いる．

RE 1 1 1 開発コストの見積りと実績の差を見積りで正規化したもの (単位は % とする)．
actCOST 1 1 1 プロジェクトで実際にかかったコスト (単位は人月とする)．
estCOST 1 1 1 開発コストの見積りの値 (単位は人月とする)．

以降では，次の記号を用いる．

CT 1 1 1 開発計画の完全度 (単位は点で，100 点を満点とする)．
crtCT 1 1 1 SEPG の担当者が文書 (a)-(d) が手順に準拠している度合を 50 点を満点として評

このときコスト予測精度 RE は次式で定義される．

RE =actCOST 0 estCOST
2 100
estCOST

2. 完全度 CT価した値．

satCT 1 1 1 SEPG の担当者が，項目 (e),(f) について対応する方法で 50 点を満点として評価し開発計画がプロジェクト管理手順に準拠して作成され，しかもその計画通りにプロジェクトが進むように進捗管理がなされている度合を測るためのもの．したがって，計画の完全度 CT の評価は計画作成の正確度 crtCT と計画実行の充足度 satCTの 2 つの観点から行う．
まず，開発計画の正確度 crtCT に関しては，次の4 つの文書を中心に評価する．

た値．
このとき開発計画の完全度 CT は次式で定義される．

CT = crtCT + satCT

4

開発データ

(b) プロジェクト体制図

4.1

プロジェクト の特性(c) PERT 図 (Program Evaluation and Review
Technique)[12]2.1の背景や 3.1の開発プロセスでも説明したように，本研究で分析の対象とするプロジェクトはいずれもオムロン (株) で行っている組込みソフトウェアの開発である．
詳細は省略するが，これらの組込みソフトウェアは非常に複雑な機能を実現している．更に，出荷後に発見されたフォールトを修正するには高い費用を要するため，開発チームに対しては特に高い信頼性が要求されることになる．
ソフトウェアの開発はシステムハードウェアの開発と並行して行われるため，全体的なプロジェクトの管理が必要となる．一般にこの種の開発においては，製(a) WBS (Work Breakdown Structure) [11][12](d) 成果物一覧表
具体的には，WBS における各作業の詳細化が概ね 2 人月以下のレベルになっているか，各作業毎の担当者，責任者が明記されているかを評価する．
次に，プロジェクト体制図については WBS 中に現れるプロジェクトの体制がプロジェクト体制図と整合性がとれていることを確認する．PERT 図については開発期間，工数，要員などの制約条件を満たすか否か，クリティカルパスが明確になっ表 1: 開発計画の評価品の仕様はハードウェア設計の制約を強く受けることになる．
オムロン (株) の場合には，画面構成，帳票の構成，処理の流れ，処理速度などについては顧客からの要求仕様の変更が発生することもある．しかし，ハードウェ
アとのインタフェース部分や OS(Operating System)などは社内で決定できるために，開発途中で変化することは少ない [6]．
今回の分析で対象とした 31 件のプロジェクトは次の3 種類に分類される．

テーマ名P S1P B1P B2P B3
P B4P B5P B6P R1P R2
P R3
P R4P R5P R6
P R7P R8P R9P R10(1) 銀行関連の 6 プロジェクト 1 1 1 ATM，振込，記帳など

P B 1 ; P B 2 ; 1 1 1 ; P B6(2) 鉄道関連の 24 プロジェクト 1 1 1 自動改札，券売機，清算機など

P R1 ; P R2 ; 1 1 1 ; P R24(3) 流通関連の 1 プロジェクト 1 1 1 POS ターミナルなど

4.2

P S1

開発計画の評価分析で対象とした開発プロジェクトは全部で 31 件であるが，開発計画の評価に利用できる開発プロジェ
クトはその内の 17 件に限られる．件数が減った主な理由は年数を経ているために担当者への直接のインタビューができず，一部のデータに不備が生じたためである．
表 1に開発計画の評価結果を示す．
表 1で評価の A, B, C, D は次の基準で判定している．

5

C : 25  CT < 50
D : 0  CT < 25
表 1より A は 2 件，B は 8 件，C は 7 件となっていることが分かる．

4.3

プロジェクト の評価分析に用いた各プロジェクトに対しては，4.2で説明した開発計画の他に，開発規模 SLC ，出荷後 6ヵ月間に発見されたフォールトの総数 #F ault，開発に要した人月の総和 Effort，開発コストの見積り estCOSTとその実績 actCOST などのメトリクスの値が収集されている．
これらのメトリクスの値そのものは企業の秘密に属するものなので，残念ながらそれらは公表できない．

satCTCT評価

121239183919232626261932
1230
23122535354540
2535303030302525352025255047478458645453565656
4457475048
3775

CCAB
B
B
B
B
B
B
C
B
C
C
C
C
A

分析

ここでは 31 件の実際のプロジェクトから収集したデータを用いて，2.2の命題 (A1),(A2),(A3) が成立するか否かについて検証してみる．その準備として，コスト予測精度 RE を算出した結果を表 2に示す．表 2
中でコスト予測精度 RE についてさらに 3 つのクラス
C0 ; C+ ; C0 に分類している．その分類の基準は次の通りとする．

C0 : 010 < RE < 10C+ : RE  10A : 75  CT  100
B : 50  CT < 75

crtCT

C0 : RE  010

0

つまり，C0 はコスト予測精度が 10%〜10% の範囲に入っているもの，C0 ; C + はそれぞれ予測精度が10% 以下，10% 以上となってしまっているものを表している．

05.1

コスト 予測精度の評価 (A1)

1. クラス同士の比較
ここでは開発計画の完全度 CT とコスト予測精度RE の関連を調べる．そのため，表 1に示した CTの評価 (クラス A, B, C, D) と RE のクラス分け(C0 ; C+ ; C0 ) の関係をまとめた結果を表 3に示す．
表 3中の数字は対応するプロジェクトの件数を表す．
表 3より，クラス A(すなわち，プロジェクトの開発計画が指定された手順に準拠して作成され，か表 3: CT と RE の関連

表 2: コスト予測精度の評価
プロジェクト名P B1
P B2
P B3
P B4P B5P B6P R1P R2
P R3P R4P R5
P R6P R7P R8P R9P R10P R11P R12P R13P R14P R15P R16P R17P R18
P R19
P R20
P R21
P R22
P R23
P R24
P S1

コスト予測精度
クラス分け

RE (%)-21619-253-17
1-2-5-17142413221926
2-10139-29
66-1-3
11-2011C0C0C+
C0C0C0C0C0C0C0C+
C+
C0C+
C+
C0C+
C0C0C0C+
C0C0C0C0C0C0C+
C0C0C+つ，その計画通りにプロジェクトが実行される度合がもっとも高い) プロジェクトのコスト予測精度はクラス C0 (見積りと実績値のずれが最も小さい) プロジェクトとなっていることが分かる．反対に，クラス C(開発計画の作成が手順に準拠している度合やプロジェクトの実行が計画通りに履行される度合が最も低い) プロジェクトのほとんどはクラス C0 や C+ に属しており，コスト予測精度も高くないことが分かる．

2. 値の比較
次に，同種のプロジェクトだけを取り出して CTと RE の値の相関 [4][5] を調べてみる．表 1と表 2に共通に含まれている P R1 〜P R10 について CTと RE の値の間での相関係数を求めてみると次のCT のクラス分け

ABCDRE のクラス分け
C0 C0 C+022024100240ようになった．

CT と RE の間の相関係数 = 00:47
crtCT と RE の間の相関係数 = 00:60従って，今回の分析については鉄道関連のプロジェ
クトだけに限定して見ると，開発計画の評価 CTとコスト予測精度 RE の間，また，開発計画の完成度 crtCT とコスト予測精度 RE の間にはそれぞれ (決して強くはないが ) 相関があることが分かる．

5.2

フィールド 品質 F R (A2)

ここではフィールド品質 F R についての命題 (A2) を検証するため次の統計的仮説検定 [4][5] を行う．

クラス C0 ; C+ ; C0 に属するプロジェクトのフィール
ド 品質 F R の平均をそれぞれ 0 ; + ; 0 とする．

1. クラス C0 と C+
仮説 H0 : + = 0
対立仮説 H1 : + > 0
有意水準 = 0:05 として検定すると，この仮説
H0 は棄却される．

0つまり，開発計画のコ スト 予測精度が 10%〜10% の範囲に入っている (クラス C0 ) のプロジェ
クトとそのコスト予測精度が 10%以上となってしまう (クラス C+ ) のプロジェクトとでは，そこで作成されたソフトウェアプロダクトのフィールド品質に有意的な差のあることが分かった．

2. クラス C0 と C0
同様に統計的検定を行うと，フィールド 品質に関しては (仮に = 0:1 としても)2 つのクラス C0 とC0 の間で有意的な差が無いことが分かった．

5.3

チーム生産性 P T (A3)

ここではチーム生産性 P T についての命題 (A3) を検証するため次の統計的仮説検定を行う．
クラス C0 ; C+ ; C0 に属するプロジェクトのチーム生
産性 P T の平均をそれぞれ 0 ; + ; 0 とする．

1. クラス C0 と C+

参考文献

仮説 H0 : + = 0
対立仮説 H1 : + < 0
有意水準 = 0:05 として検定すると，この仮説
H0 は棄却される．

0以上より，開発計画のコスト予測精度が 10%〜10% の範囲に入っている (クラス C0 ) のプロジェ
クトとそのコスト予測精度が 10%以上となってしまう (クラス C+ ) のプロジェクトとでは，それぞれの開発チームの生産性に有意的な差のあることが分かった．

2. クラス C0 と C0
同様に統計的検定を行うと，チーム生産性に関しても (仮に = 0:1 としても)2 つのクラス C0 とC0 の間で有意的な差が無いことが分かった．

6 むすび
本研究ではプロジェクトの計画段階で立てたコスト見積りと実際に要したコストの実績値の差に注目し，その差が小さいプロジェクトは品質と生産性の両方で見たときに優れていることを実際のプロジェクトから収集したデータを用いて検証することを試みた．その結果，その差が 10%〜10% の範囲にあるプロジェク
トと 10%を超えてしまうプロジェクトの間では有意的な差があることを示すことができた．

0

更に，そうした見積りの差が生じる要因として作成された開発計画の正確さ crtCT とそれを運用する場合の進捗管理の十分さの度合 satCT などを考えた．分析の結果，そうしたメトリクスの値が高いほど，見積りの差が小さくなる傾向にあることが分かった．
今後の課題としては，次の (1)〜(3) がある．

(1) 開発計画の完全度 CT を客観的に評価する手順の確立とツール化(2) コスト予測精度 RE が 010% 以下あるいは +10%以上になったプロジェクトの詳細分析(3) 分析結果を開発現場にフィードバックする方法論についての検討

謝辞
日頃から我々の研究活動に対し多大の御協力を賜わり，また今回のデータ分析について貴重なご意見を頂いた大阪大学大学院基礎工学研究科 楠本真二講師に深謝致します．

[1] Fenton N. E. and P eeger S. L. : \Software
Metrics : A rigorous & practical approach",
PWS Publishing (1997).
[2] Humphrey W. S. : Managing the Software Process, Addison Wesley, Reading, MA (1989).
[3] Humphrey W. S., Snyder T. and Willis R.
: \Software Process Improvement at Hughes Aircraft", IEEE Software, 8(4), pp.11-23(1991).
[4] 池田央 : \統計ガ イドブック", 新曜社 (1989).
[5] 石村貞男 : \統計解析のはなし ", 東京図書(1989).
[6] 岸田孝一監修 (アルフォンゾ・フェジッタ，アレキサンダー・ウルフ編) : \ソフトウェアプロセ
スのトレンド ", 海文堂 (1997).
[7] Moller K. H. and Paulish D. J. : \Software
Metrics : A practitioner's guide to improved
product development", IEEE Press (Chapman& Hall Computing) (1993).
[8] 新原直樹，高木徳生，稲垣勝巳 : \計画精度か
ら見たプロセス改善活動の分析", ソフトウェアシンポジウム'96 予稿集, pp.153-159 (1996).
[9] Tanaka T., Sakamoto K., Kusumoto S. andKikuno T. : \Improvement of Software Process by Process Visualization and Bene t Estimation", Proc. of the 17th ICSE, pp.123-132(1995).
[10] Takagi Y., Tanaka T., Niihara N., Sakamoto K., Kusumoto S. and Kikuno T. : \Analysis of Review's E ectiveness based on Software Metrics", Proc. of the 6th International
Symposium on Software Reliability Engineering, pp.34-39 (1995).
[11] Tausworthe R. C. : \The Work Breakdown
Structure in software project management", Journal of Systems and Software, vol.1,pp.181-186 (1980).
[12] 山田茂，高橋宗雄 : \ソフトウェアマネジメン
トモデル入門" , 共立出版社 (1993)[13] Project Estimating, American Programmer,Vol.9, No.6 (1996)

[14] Project Estimating part II, American Programmer, Vol.9, No.7 (1996)[15] Death March Project, American Programmer,
Vol.10, No.2 (1997)