ソフトウェア開発データ白書2009と定量データの...

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

Software Engineering CenterCopyright© 2010 Information-technology Promotion Agency, Japan. All rights reserved.

SEC主催セミナー

IPA 独立行政法人情報処理推進機構

SEC ソフトウェア・エンジニアリング・センター

（東京）2010年10月08日

ソフトウェア開発データ白書２００９と定量データの活用方法

研究員森下哲成

研究員三毛功子

研究員小椋隆

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

1Software Engineering CenterSEC主催セミナー（東京）2010年10月08日 Copyright© 2010 ＩＰＡ, All rights reserved.

本日の内容

１．はじめに

２．定量データ活用の背景

３．定量データ活用の利点と課題

４．定量データの実践的活用方法と事例

４-１．活用その１（品質）

品質予測

４-２．活用その２（工数・工期）

①見積り

②計画

③コントロール

④評価

５．実践的活用をサポートするツール

６．まとめ



はじめに（本セミナーの目的）

本セミナーの目的は、「ソフトウェア開発データ白書2009」や「定量データに基づくプロジェクト診断支援ツール」の見方・活用方法だけでなく、収集～活用サイクルを回し、見積を含む定量的なプロジェクトマネジメントにおける、

データの活用の仕方やポイントを理解するデータの活用の仕方やポイントを理解する

ことです。

また、データ活用者の視点に立った適用場面や、具体的なアクションの事例を交えて紹介・解説することで、

「分かる」から「使える・できる」ための実践力向上「分かる」から「使える・できる」ための実践力向上

につなげていただきたいと考えています。



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



市場競争の激化

トラブルの多発

・低コスト、短期開発・多機能、高性能

安全・安心の確保要請が増大

・信頼のおけるマネジメント・トラブル発生未然抑止

人海戦術的な対処方法での対応

不適切な見積、生産性の見誤り

システムへの要求が増大

理理想想

現現実実

KKD（勘、経験、度胸）

定量データに裏付けられたマネジメントの実施が不十分

ネットワークの普及

ビジネスモデルの転換

リスクの増大

ＩＴ産業を取り巻く環境

期待・ニーズ



ユーザベンダ

ユーザ・ベンダ間の納得感の欠如

【事業計画】・事業目的・事業領域／規模・投資／回収・事業スケジュール

【プロジェクト計画】・開発目的・スコープ／規模・予算・開発スケジュール

要件

実現性

整合

「やりたいこと」と「できること」の整合が必要だが…

・共有しやすい見積り手法がない

・初期の仕様は固めにくく、早期契約時の適切な見積りが困難

・要件決定の遅れ、プロジェクト途中での仕様変更の発生など

両者間の無理、不整合によるプロジェクトの破綻



社会的な動向への対応

「成果の確実性」とは、以下の３つの要素について、信頼性をもって見積ることができること。

・工事収益総額：工事契約の対価（受注額）。工事完成能力が必要。

・工事原価総額：完成までの原価総額。実原価との比較と見直しが必要。

・工事進捗度：決算日における開発の進捗率。客観的把握が必要。

⇒ 高い精度と確実性、客観性が求められる。

定量的マネジメントの強化、実践が急務

◆工事進行基準の適用

プロジェクトの進捗部分について「成果の確実性」が認められる場合

に適用される。



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



ユーザユーザ

ベンダベンダ

定量データの必要性

経営層

業務・情報システム部門組織長・スタッフ

プロジェクト管理者

・IT投資、概略計画の妥当性、実現性の目安

・予算数値、根拠の制御・ベンダからの見積の比較と評価、強み／弱みの認識

・計画策定、目標値の制定、QCDの妥当性評価・予実差異の分析、完了評価、開発能力の評価

経営層

プロジェクトマネージャプロジェクトリーダ

・自社の強み・弱み、生産性などの開発力の認識

・規模、工数、工期、品質の見積り、計画策定、制御・オフショア等、外部委託先評価

PMO品質保証部門

・定量データベースの構築・自社プロジェクトのベンチマーキング、モニタリング

定量データが十分集まれば・・・こんな活用ができる

ユーザ、ベンダ間の合意形成ユーザ、ベンダ間の合意形成



定量データ活用の一例

他社(■)と比べて、我が社の開発(▲)は短納期でキケン？？

⇒ どのプロジェクトも同じ傾向を示している。これは立派な『我が社の強み』！



定量データ活用における課題

何となくイメージはついている。でも、あと一歩が踏み出せない何となくイメージはついている。でも、あと一歩が踏み出せない……

●どれくらいパワーがかかるのか？

⇒ 管理者（管理組織）や開発現場の負荷が気になる。

●データを効率よく収集、分析できるか？

⇒ どのような環境やツールを用意すればよいのか分からない。

●開発現場のマネジメントをどうすべきか？

⇒ 現場の反発に遭った場合、どう対処するのが良いのだろう。

●定量化のメリットをどのように説明するか？

⇒ 現場を説得し、巻き込むための材料がない。

要因は？



定量化に取組む前の「取組み」

闇雲に取り組んでも成果は出ない。なぜなら…

①主にＱＣＤの観点で目的とすべきこと、つまり

「問題意識と改善の必要性」が明確でなければならない。

②目的実現によって「何が得られるのかを具体的」に示し、

関係者間で理解、共有しておく必要がある。

③定量化活動(プロジェクト)のオーナーを明確にし、その

人が「強い意志を持って推進する」ことが重要である。

④欲張ることなく「コアな問題・課題の解決に絞り込んで」

取り組むべきである。



課題と対応事例①

Ａ社の事例：費用対効果の説明

【課題】

収益に直接結びつけることが難しい定量データ活用の費用対効果をどのように説明するか？

【対応策】

目標：赤字0 ＝トラブルプロジェクトの撲滅

施策：定量的プロジェクトマネジメントの強化と組織的推進

結果：部門毎に、赤字、トラブル（実行予算オーバー）の額と、定量データ活用度合を、経年変化を交えて相対評価

補足：現場の監視（モニタリング）のためにレビューや監査が必要で、実際のトラブル撲滅に効果を発揮



課題と対応事例②

Ｂ社の事例：利用価値のあるデータ

【課題】

収集した全社データから分かることを単純にフィードバックしても現場では使えないと言われてしまう。

【対応策】

目標：現場からのデータ提供～活用のサイクルの確実な実施

施策：特定部門およびそこの顧客別のデータ白書を作成

結果：自部門のためのデータ提供という意識があり、定量化に取り組む納得感が高い

補足：データの傾向の有無に関わらず、強み・弱みの評価、対策を行うことで、現場との信頼関係構築が可能



課題と対応事例③

Ｃ社の事例：開発の目標設定と評価

【課題】

生産性向上に特化し、開発時の目標設定と評価を確実に実施するための施策をどうするか？

【対応策】

目標：ＦＰによる生産性の計測および評価

施策：要件定義終了時の生産性目標と、リリース後の実績を会議で確認

結果：生産性目標の設定および評価の定着

補足：実行に強制力を持たせるとともに、担当役員含め、会議の中で繰り返しＦＰ（生産性）に言及することが重要



ＳＥＣの取組みとデータ白書の目的

メーカー系、ユーザ系、独立系の複数のベンダからデータを収集メーカー系、ユーザ系、独立系の複数のベンダからデータを収集

「ソフトウェア開発データ白書」として公開（2009年度は22企業、2327プロジェクトのデータ）

・モノサシとしての精度を高めていく精度を高めていく

・新たなモノサシや課題抽出の切り口を提案する切り口を提案する

■日本のソフトウェア業界発展のために

定量的アプローチによる定量的アプローチによる科学的マネジメントの普及拡大へ科学的マネジメントの普及拡大へ

◆ 企業間で共通認識できる『ものさし』や他社と比較できる基準データの提供◆ 主要な要素の統計データの提供と、相互の関係の分析情報の提供◆ 収集データの項目定義および収集用フォームの提供

◆ 企業間で共通認識できる『ものさし』や他社と比較できる基準データの提供◆ 主要な要素の統計データの提供と、相互の関係の分析情報の提供◆ 収集データの項目定義および収集用フォームの提供

2009年9月出版



1774

データ収集・分析の方針

942 1418 2056

2005 2006 2008 データ白書20092007

企業横断的データ分析基盤構築

新期開発プロジェクト拡充

改修開発プロジェクト拡充

・生産性の層別分析拡充（要求レベル、スキル等）

・母体規模の工数への影響

■対象プロジェクト：アプリケーションソフトウェアやシステムを開発するプロジェクト■対象時期：直近3年を優先■分析の観点：プロジェクトの特徴を表す代表的な要素に着目し、各々の関係を分析

収集項目（プロジェクトタイプ）

収集項目（プロジェクトタイプ）

開発種別アーキテクチャ業種

開発言語開発ライフ

サイクルモデルプラットフォーム

代表的な要素代表的な要素

生産性信頼性

工期規模工数

2327規模要素と工数の関係，

生産性層別分析



データ白書２００９の構成

1章背景と本書の目的

2章収集データについて

3章分析について

4章収集データのプロファイル

5章プロジェクトの主要要素の統計

6章工数、工期、規模の関係の分析（生産性も含む）

7章信頼性の分析

8章工程別の分析

9章予実分析、生産性クロス分析付録A～G

データ項目の定義や収集データ年別プロファイル等々

データ全体のプロファイル

方針に基づく分析結果

データ収集方針分析の方針、データの基準

予実、生産性の差の特徴をミニテーマ分析



0

1

2

3

4

5

6

7

8

～25

～50

～75

～100

～125

～150

～175

～200

～225

～250

～275

275超

プロジェクト件数 [件]

企業数

【参考】データ提供状況

■データ提供企業一覧（22社：50音順 2009年3月31日現在）

TIS株式会社東芝情報システム株式会社日本ユニシス株式会社株式会社野村総合研究所パナソニック株式会社株式会社日立システムアンドサービス株式会社日立製作所日立ソフトウェアエンジニアリング株式会社富士通株式会社三菱電機インフォメーションシステムズ株式会社リコーソフトウエア株式会社

・NECソフト株式会社・NTTソフトウェア株式会社・株式会社 NTTデータ・沖ソフトウェア株式会社・沖電気工業株式会社・キヤノンIT ソリューションズ株式会社・株式会社構造計画研究所・株式会社 CSKシステムズ・新日鉄ソリューションズ株式会社・住友電工情報システム株式会社・大同生命保険株式会社

【データ白書2009】図表2-2-1●データ提供件数（2327プロジェクト）



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



定量的品質予測がなぜ必要か？

高品質な情報システムが求められている情報システム障害の社会的影響が深刻化

金融システム、交通管制、生産機械、生産管理、物流管理・・・・

携帯電話、自動車、大画面テレビ、エアコン、パソコン・・・

「品質を高める」＝品質を測定する物差しが必要計測できないものは制御できない

「品質が高い」＝開発者から利用者への説明責任

>>定量的品質評価が必要

「動いてみないと分からない」では・・・

定量的な品質測定・品質予測

品質向上施策の効果測定

で品質を制御し、品質目標を達成する



品質予測の考え方について

品質の測定と予測の枠組み

(注）測定、対策はそれぞれの工程で実施される。

蓄積データ人の作業

データの受渡し

作業の流れ

分析・モデル化

分析・モデル化モデルモデル

【プロジェクト】【プロジェクト】

《プロジェクト生産活動》

要件定義

要件定義

基本設計

基本設計

詳細設計

詳細設計製作製作総合

テスト

総合テスト

結合テスト

結合テスト

【プロジェクト】

データ

計画（P)計画（P) 対策（A)対策（A)

《プロジェクトマネジメント活動》

モデルの改善・見直し

単体テスト

単体テスト

データ蓄積データ蓄積

測定（D)測定（D) 分析･予測（C)分析･予測（C)



測定単位（例）

測定単位を小さくして品質データ（欠陥数など）を測定することにより、詳細な品質管理・分析が可能

その測定値を集計することにより当該工程の品質管理・分析が可能

工程基本設計詳細設計製作単体テスト結合テスト総合テスト

ｼｽﾃﾑ・ｻﾌﾞｼｽﾃﾑ

◎ ◎

◎ ◎ ◎ ◎

● ◎ ◎ ◎ ◎ ◎

● ◎ ◎ ● ●● ●

分解粒度

測定単位の

業務機能

プログラム数100L～１KL －

想定規模

100KL～1ML

20KL～50KL

数KL～10KL

●：その工程完了時に最小の測定単位、◎：その工程で主に着目する測定単位

測定単位

詳細に調べる場合




代表的な基本測定量と導出測定量

対象工程測定量単位測定方法

全工程規模 FP

LOC

Function Point (FP) では測定方法、LOCは測定

ルールを明確にする

作業工数人時

設計工程レビュー回数回数

レビュー時間人時 Σ 各レビューアのレビュー実施時間

レビュー対象規模ページ数レビュー対象ドキュメント量（A４換算ページ数）

レビュー指摘件数件数レビュー記録票の指摘事項数

テスト工程欠陥数件数障害連絡票の欠陥数

テスト項目数項目数テスト仕様書の項目数

基本測定量

導出測定量

対象工程測定量単位算出方法

設計工程レビュー指摘密度件数÷FP，LOC

件数÷ページ数

レビュー指摘件数÷規模

レビュー指摘件数÷レビュー対象規模

レビュー工数密度人時÷FP，LOC

人時÷ページ数

レビュー時間÷規模

レビュー時間÷レビュー対象規模

レビュー指摘効率人時÷件数レビュー指摘件数÷レビュー工数

テスト工程欠陥密度件数÷FP，LOC 欠陥数÷規模

テスト密度項目数÷FP，LOC テスト項目÷規模

品質改善の立案には、属性情報も必要です




モデル名称概要用途

閾値モデルある尺度の閾値（UCL（上部管理限界線）／LCL (下部管理限界線）によって分類するモデル

測定値と閾値（UCL／LCL）との比較から測定対象（プロダクト）の品質を予測する

ゾーンモデル複数の尺度の組からなる空間をゾーンに分類するモデル

データから直接、特徴や傾向が見えない場合、次のステップの対策を絞り込みたい場合に測定値がどのゾーンに属するかで、測定対象（プロダクト）の品質を予測する

関数モデルｎ個の尺度の値の関係を統計的な回帰式（近似関数）で表すモデル

過去から現時点までの品質測定値から現時点以降の、測定対象（プロダクト）の品質を予測する

トレンドモデルある尺度の時間的推移のパターンを分類するモデル

測定値がどのような推移のパターンを辿るかでプロダクトやプロジェクトの品質を予測する

チェックリスト有識者のノウハウを予めリスト化するモデル

チェック状況から、プロダクトやプロジェクトの品質を予測する

品質モデル一覧




分析名称（モデル名）

概要

管理図分析（閾値モデル）

データの分布がUCLとLCLに対してどの位置にプロットされるかを見て、データが正常値であるか外れ値であるかを判断する分析方法

ゾーン分析（ゾーンモデル）

与えられた分析のテーマを、ある特徴に着目した視点によってゾーンに分割し、各ゾーン毎に分析を行う

曲線近似分析

（関数モデル）

二つのデータ列の関係を回帰式と呼ぶ近似曲線で代替することで分析を行う

トレンド分析（トレンドモデル）

過去のプロジェクトの実績データの時間的なパターンと、現在のプロジェクトの実績データのトレンドを比較し、過去のプロジェクトの最終品質と同等な結果となるかを予測する分析である

チェックリスト分析

（チェックリスト）

チェックリストは、与えられたテーマに対してチェックする項目をリストにしたものである

分析一覧UCL

LCL

品質不良と予測

レビュー指摘密度

ゾーン4ゾーン3ゾーン9



尺度

尺

度

単体テスト結合テスト総合テスト

検出欠陥密度

UCL

CL

LCL

Xプロジェクト

Yプロジェクト

要求分析のレビュー指摘チェックリスト

大分類小分類レビュー指摘事項評価重みﾎﾟｲﾝﾄ備考

全体網羅性記載内容の範囲についての記述があり、明確か ○ Ａ 1.2

要求の網羅性について記載があるか ○ Ｂ 1.0

要求に漏れがないかの確認をしているか × Ａ 0.0

整合性内容に矛盾がないか ○ Ａ 1.2

要求の粒度は揃っているか × Ｂ 0.0

了解性主語が明確であるか ○ Ｃ 0.8

事実と推測が分離しているか ○ Ｂ 1.0

数値表現できるところは数値で表現しているか ○ Ａ 1.2

※ 評価（○：1､×：0）､重み（A：1.2､B：1.0､C：0.8） 6.4

近似曲線二つの要因を回帰式で分析

① ここの値から

を

管理図分析

曲線近似分析

ゾーン分析


トレンド分析




品質予測の実例

1.要求分析・設計における品質予測設計工程（要件定義、基本設計、詳細設計）における設計時の品質予測

2.プロダクト品質予測製作やテスト工程（単体テスト、結合テスト、総合テスト）における品質予測

3.プロジェクト品質予測「良い品質のプロダクトは健全なプロジェクト運営から生まれる」という前提をもとにしたプロジェクトの品質予測



要求分析・設計における品質予測目的：現工程の設計品質と後工程の計画の見直し

要求分析・設計製造試験

欠陥の混入新たな欠陥の混入

未発見の欠陥未発見の欠陥未発見の欠陥

欠陥

測定・分析

予測

レビュー実施

データ収集・精査

データ分析・評価品質予測・工程終了判断

現工程の品質予測後工程の品質予測

チェックリスト




要求分析・設計における品質予測の事例（閾値モデル）閾値モデル

概要ある尺度の閾値によって分類するモデル

ＵＣＬ（上部管理限界線ＵｐｐｅｒＣｏｎｔｒｏｌＬｉｍｉｔ）

ＬＣＬ（下部管理限界線ＬｏｗｅｒＣｏｎｔｒｏｌＬｉｍｉｔ）

管理図分析

データの分布がＵＣＬとＬＣＬに対して、どの位置にあるかで、データが正常値であるか外れ値であるかを判定する

UCL

LCL


レビュー指摘密度




要求分析・設計における品質予測の事例（関数モデル）

レビュー工数密度とレビュー指摘密度の散布図

レビュー工数密度（工数／ページ）

レビュー指摘密度（件／ページ）

サブシステムB

サブシステムA

サブシステムC

サブシステムD

サブシステムE

特異点

近似式




要求分析・設計における品質予測の事例（チェックリスト）チェックリスト

概要有識者のノウハウを予めリスト化するモデル


チェックリストは与えられたテーマに対しチェックする項目をリスト化し、重み付けをして分析を行う

要求分析のレビュー指摘チェックリスト

大分類小分類レビュー指摘事項評価重みﾎﾟｲﾝﾄ備考

全体網羅性記載内容の範囲についての記述があり、明確か ○ Ａ 1.2

要求の網羅性について記載があるか ○ Ｂ 1.0

要求に漏れがないかの確認をしているか × Ａ 0.0

整合性内容に矛盾がないか ○ Ａ 1.2

要求の粒度は揃っているか × Ｂ 0.0

了解性主語が明確であるか ○ Ｃ 0.8

事実と推測が分離しているか ○ Ｂ 1.0

数値表現できるところは数値で表現しているか ○ Ａ 1.2

※ 評価（○：1､×：0）､重み（A：1.2､B：1.0､C：0.8） 6.4




プロダクト品質予測目的：現工程のプロダクト品質の予測と後工程の計画の見直し。


欠陥の混入欠陥の混入

未発見の欠陥

レビューによる欠陥の除去

未発見の欠陥未発見の欠陥

欠陥

測定・分析

予測


欠陥の混入欠陥の混入

未発見の欠陥



未発見の欠陥未発見の欠陥

欠陥

測定・分析

予測

欠陥

測定・分析

予測

データ収集・精査

品質予測

試験実施

工程終了判断




プロダクト品質予測の事例（閾値モデル）閾値モデル

概要ある尺度の閾値によって分類するモデル

ＵＣＬ（上部管理限界線ＵｐｐｅｒＣｏｎｔｒｏｌＬｉｍｉｔ）

ＬＣＬ（下部管理限界線ＬｏｗｅｒＣｏｎｔｒｏｌＬｉｍｉｔ）

管理図分析

データの分布がＵＣＬとＬＣＬに対して、どの位置にあるかで、データが正常値であるか外れ値であるかを判定する

UCL

LCL


欠陥密度




⑧

⑦適切な範囲

① ②

⑤ ⑥

⑨ ③ ④

テスト密度

欠陥密度

プロダクト品質予測の事例（ゾーンモデル）

欠陥密度の標準

テスト密度の標準

▲

●

下限

下限

上限

上限




プロダクト品質予測の事例（ゾーンモデルによる品質トレース）

目標（100%）

テスト項目の消化率

欠陥

密度




⑧

⑦適切な範囲

① ②

⑤ ⑥

⑨ ③ ④

テスト密度

欠陥密度

プロダクト品質予測の事例（ゾーンモデル）

機能ID 規模(KLOC) 達成率目標実績達成率目標実績

A 19.20 136.3% 80.0 109.00 177.8% 9.0 16.00 前工程の品質確保不足、ﾃｽﾄ内容点検

B 9.90 75.0% 80.0 60.00 115.6% 9.0 10.40 テスト不足前工程の品質確保不足、内容点検

C 4.80 85.3% 80.0 68.20 58.9% 9.0 5.30 テスト不足、内容点検

D 10.14 112.2% 80.0 89.72 111.1% 9.0 10.00 一応品質は良好、テスト効率も計画通り

サブシステム全体 44.04 101.3% 80.0 81.00 103.3% 9.0 9.30

↑基準(100%） ↑基準(100%）

品質評価（ゾーン位置から選択)(結合テスト)テスト密度 (結合テスト)欠陥密度

●サブシステム全体◆機能Ａ■機能Ｂ▲機能Ｃ▼機能Ｄ

●

◆

■

▲

▼




測定単位（例）

測定単位を小さくして品質データ（欠陥数など）を測定することにより、詳細な品質管理・分析が可能

その測定値を集計することにより当該工程の品質管理・分析が可能

工程基本設計詳細設計製作単体テスト結合テスト総合テスト

ｼｽﾃﾑ・ｻﾌﾞｼｽﾃﾑ

◎ ◎

◎ ◎ ◎ ◎

● ◎ ◎ ◎ ◎ ◎

● ◎ ◎ ● ●● ●

分解粒度

測定単位の

業務機能

プログラム数100L～１KL －

想定規模

100KL～1ML

20KL～50KL

数KL～10KL

●：その工程完了時に最小の測定単位、◎：その工程で主に着目する測定単位

測定単位

機能Ａは、プログラム単位の分析も必要




プロダクト品質予測の事例（関数モデル）

対象フェーズ：総合テストグラフ作成日：2006/2/15

テスト開始日：2006/1/15テスト終了日：2006/3/31

総障害数：456 件総障害修正数：253 件

障害推定結果推定障害数 : 550.0 件95%到達時点 : 1.6 週目

信頼度成長モデル

2006/1/1

2006/1/8

2006/1/15

2006/1/22

2006/1/29

2006/2/5

2006/2/12

2006/2/19

2006/2/26

2006/3/5

2006/3/12

2006/3/19

2006/3/26

2006/4/2

0

100

200

300

400

500

600

累積障

害件数

累積障害件数推定障害件数

テストの進捗

累積欠陥数

①

②

③

④




プロダクト品質予測の事例

テスト消化実績

テスト消化計画

累積欠陥数

欠陥未解決数

信頼度成長モデル使用にあたっては、• テストに極端な偏りがない事。• テストの網羅性が十分確保できている。• テスト項目の消化状況。• 未解決欠陥件数。

をあわせて評価。

0

500

1000

1500

2000

2500

3000

テスト日数

テス

ト項

目数

0

100

200

300

400

500

600

障害

数


テスト消化計画テスト消化実績

累計欠陥数欠陥未解決数



プロジェクト品質予測

目的：現工程：健全な運営状態を維持できているか。

後工程：計画通りの目標を達成できるか。

アプローチ

定量データによりプロジェクトの現状を捉える。

プロジェクト途上の状況が最終結果に及ぼす影響を蓄積データから分析する。

因果関係について仮説を立て、定量的な裏づけからモデル化する。




0

2

4

6

8

10

12

プログラム試験ソフトウェア試験システム試験

フェーズ

件/KL

期待値

上限値

下限値

0

2

4

6

8

10

12


フェーズ

件/KL

期待値

上限値

下限値

成功成功

0

2

4

6

8

10

12


フェーズ

件/KL

期待値

上限値

下限値

0

2

4

6

8

10

12


フェーズ

件/KL

期待値

上限値

下限値

単体テスト結合テスト総合テスト単体テスト結合テスト総合テスト

テストにおける欠陥密度の例

時系列に減少

時系列に減少

バラツキ小さい

バラツキ小さい

結合テストで増加

結合テストで増加

バラツキ大きい

バラツキ大きい

総合テストでの検出率高い

プロジェクト品質予測の事例（トレンドモデル）

試験フェーズにおける計画達成と未達成プロジェクトを調査したところ、誤り検出率やヒット率に顕著な傾向

失敗失敗





0.90

1.00

1.10

0.85 1.00 1.15

ＳＰＩ

ＣＰＩ

10/17

10/31 11/7

11/14

11/28

12/5

12/12

どちらも効率が良く、問題なし

コストの効率は良いが、スケジュ－ルの

効率が悪い

スケジュールの効率は良いが、コストの

効率が悪い

どちらも効率が悪い。ピンチ領域

スケジュール遅れが発生する！？

EVMを活用したプロジェクト品質予測事例スケジュール効率（SPI）とコスト効率（CPI）のトレンドからプロジェクトの今後

の状態を予測。

11/21

SPI(Schedule Performance Index） = EV / PV PV（Planned Value）：計画どおり実施できた場合のコスト

CPI(Cost Performance Index） = EV / AC EV（Earned Value）：実績進捗で消費しているはずのコスト

AC（Actual Cost）：実績とし消費したコスト



「突然死」の兆候は、品質評価で察知するプロジェクト状況の突然の悪化

稼働時期の突然の延期

定量的品質予測は絶対ではない

ＳＥＣより「定量的品質予測のススメ」が出版されています。

是非、ご活用ください。

毎月の報告の中に破綻の兆候は隠れています

品質の弱い点を見つけ出すためのきっかけ弱点を重点的に追いかけるための手法




目次・構成

定量的品質予測のススメ目次

刊行にあたって

はじめに

第1 章本書を手にとられた方へ…………… 6

1.1 今、品質確保が急務

1.2 品質予測の必要性

1.3 本書の目的

1.4 品質予測へのアプローチ

1.5 本書が扱うテーマ

第2 章品質予測の考え方…………………10

2.1 品質予測の枠組み

2.2 品質測定の基本事項

2.2.1 測定単位（品質管理単位）

2.2.2 測定量

［コラム］「障害」と「欠陥」の違い

［コラム］尺度の定義

2.3 品質予測で用いるモデルと分析手法

2.3.1 品質予測のモデル整理

［コラム］モデル化時の注意点

2.3.2 管理図分析の使用例

［コラム］管理図の見かた

2.3.3 ゾーン分析の使用例

2.3.4 回帰分析の使用例

2.3.5 トレンド分析の使用例

2.3.6 チェックリスト分析の使用例

2.3.7 モデル利用上の注意点

第3 章品質予測の実際… …………………28

3.1 要求分析・設計における品質予測

3.1.1 目的と狙い

3.1.2 アプローチ

［コラム］ IT プロジェクトのシステム開発におけるレビュー実施の注意点

3.1.3 方法（項目、手法）

［コラム］仕様変更による影響度合いの定量化

3.1.4 品質評価・予測の適用領域と分析指針

3.1.5 要求分析・設計の品質予測のまとめ

3.1.6 事例：レビュー評価によるドキュメントの品質予測

3.1.7 事例：レビュー不足の予測＆是正

3.1.8 事例：プロセスパフォーマンスモデルを活用した潜在誤り予測

3.2 プロダクト品質の予測



［コラム］ホワイトボックステスト・ブラックボックステスト…


3.2.4 適用上の注意点

3.2.5 事例：ゾーン分析事例

3.2.6 事例：信頼度成長モデル

3.2.7 事例：受入れテストでの品質予測…

3.2.8 事例：パフォーマンス測定からの品質目標状況の予測＆是正…

3.3 プロジェクトの品質予測




3.3.4 適用領域

3.3.5 事例：EVM を活用したプロジェクト品質予測

3.3.6 事例：プロセスパフォーマンスベースラインを活用したプロジェクト品質予測

ANNEX… ………………………………………………84

A ソフトウェア測定プロセス

B ソフトウェア信頼度成長モデル

C 必須となる記録項目、測定事例

参考文献

索引

執筆・監修者



続定量的品質予測のススメ【目次】

本書を手に取られた方へ 5Ⅰ．上流工程で定量的品質管理を行うためのアプローチ 7

1 本編の概要 82 組織的準備：標準プロセスとガイドラインの整備 143 目標設定：品質管理方法と目標の設定 174 測定：品質データの測定と収集 305 分析・対策：品質分析と対策の実施 366 モデルを使った評価・分析方法と対策の実践例 47

Ⅱ．定量的品質管理に一歩を踏み出すためのアドバイス 651. 定量データが上手く収集できない 712. データから上手く問題点が見出せない 993. 効果のあるアクションに結びつかない 1074. 全般的な課題 115

付録1. 設計品質評価プロセスの事例 120付録2. 設計評価の世の中の動向 126付録3. 世界の品質評価事情 127参考文献 130

PT1

PT2

委託調査他

2010年度公開予定

信頼性向上のための情報システム開発上流工程における品質評価手法に関する調査



Ⅰ．上流工程で定量的品質管理を行うためのアプローチ

基本的な考え方を理解して

コラムで考え方の理解を深めて

事例で具体的な方法を習得

事例考え方

コラム



Ⅱ．定量的品質管理に一歩を踏み出すためのアドバイス

定量的品質管理ができていない

1. 定量データが上手く収集できない

1.1 どんなデータ（指標）を集めればよいか分からない

1.2 どのようにデータを収集すればよいか分からない

1.3 測定やデータ収集に手間がかかり進まない

2. データから上手く問題点が見出せない

2.1 どう分析したら問題が見えるかが分からない

2.2 分析しても問題が上手く見えてこない

2.3 基準値の決め方が分からない

3. 効果のあるアクションに結びつかない

3.1 問題の原因をどう分析してよいか分からない

3.2 分析結果からどのように行動すればよいか分からない

3.3 もっと早く問題を察知できるようになりたい

4. 全般的な課題

阻害要因ツリー



Ⅱ．定量的品質管理に一歩を踏み出すためのアドバイス

定量的品質管理導入のヒントを提供

阻害要因

対応策



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



ソフトウェア開発ライフサイクルから見た活用事例

定量データの活用場面は様々である。

ここではソフトウェア開発ライフサイクルを通した見積りから評価までの

プロジェクトマネジメントを対象に、定量データの活用ポイントや事例を示し定量データの活用ポイントや事例を示し、

実践的な利用につなげることを目的とする。

以下の場面についての活用ポイントや事例を示す。

・見積り・計画（プロジェクト計画策定）・コントロール・評価

基本設計詳細設計製作結合ﾃｽﾄ総合ﾃｽﾄ

定量的プロジェクト管理・マネジメント見積り評価プロジェクト

計画

赤枠内を対象とする



見積り

以下の「工数の見積り」、「工期の見積り」における活用ポイントを示す。

１．「工数の見積り」のデータ活用ポイント

⇒ 規模に基づく工数の妥当性確認について（50%信頼幅による妥当性検証の方法）

２．「工期の見積り」のデータ活用ポイント

⇒ 工数に基づく工期の妥当性確認について（95%信頼幅での限界認識の方法）

見積り・予測

要件の洗い出し

見積り活動

規模の見積り工数の見積り工期の見積り


定量的プロジェクト管理・マネジメント見積り評価プロジェクト計画



規模と工数、工数と工期：データ分析のねらい

プロジェクトの規模と工数や、工数と工期との間に定式性や特性を見出し、適正な工数や工期の範囲を目安にできるようにする

傾向や相関が見えれば・・・

・見積や計画の妥当性確認に利用

・工数、工期短縮目標の目安に利用

①５０％の信頼幅の上下限内に入っていれば妥当性が高いとみなす。

②工数・工期短縮の要求に対し、それが対応可能かどうか、信頼幅９５％の下限値を限界の目安とする。

工数

規模下限50%

上限50%

▲

妥当性の目安

工期（月数）

工数

下限95%

上限95%

▲

工期短縮限界



白書の表記と見方の留意点(1)

ソフトウェア開発プロジェクトのデータは正規分布していないことが多い。(（例）規模の分布：規模の大きい方に裾野が長い分布）

⇒ 対数に変換するとほぼ正規分布と見なせることが多い。かつ、裾野を含めた全体の状況が見やすい

⇒ 「正規分布」であることを前提としてとしている相関係数の有意性や回帰式の予測値の信頼区間推定を求めることができる

FP実績値(調整前) N=211

0

10

20

30

40

～100

～300

～500

～700

～900

～1100

～1300

～1500

～1700

～1900

～2100

～2300

2401～

FP実績値(調整前)

件数

Log (FP実績値(調整前)) N=211

0

5

10

15

20

25

30

35

40

45

1.11

1.32

1.52

1.72

1.93

2.13

2.33

2.54

2.74

2.94

3.15

3.35

3.55

3.76

3.96

次の級

Log (FP実績値(調整前))

件数

※ 「プロジェクトデータ分析の指針と分析事例」：古山恒夫、SEC journal No3、 pp6~pp13、 2005 による

対数スケール化

正規分布

裾野の分布が分かり易い



白書の表記と見方の留意点(2)

FP規模と工数 (新規開発、IFPUGグループ) N=188

0

50,000

100,000

150,000

200,000

250,000

300,000

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000


実績

工数

(開発

5工

程)[人

時]

y(50%)

y(-50%)

実績値

Copyright IPA SEC

もとのデータと対数変換後のデータの見方・両方もしくは一方のデータを対数スケールに変換すると相関が明確化

⇒ 白書では散布図の表記において、必要に応じ対数スケール表示を取り入れている

・元のスケールに戻すと有効範囲（誤差）は右上方向に開くもとのデータに戻し、５０％の信頼幅を示すと・・・

⇒ 規模や工数が大きくなるに伴い信頼幅が広がるため、規模と工数の関係など、妥当性の検証時はそれを考慮して判断する必要がある

規模に対する工数の回帰の50％信頼幅

FP規模と工数 (新規開発、IFPUGグループ) N=188

0

1

2

3

4

5

6

0 1 2 3 4 5


実績

工数

(開発

5工

程)[人

時]

log(y)(50%)

log(y)(-50%)

実績値

10 100 1,000 10,000 100,0001

1,000,000

100,000

10,000

1,000

100

10

1Copyright IPA SEC

もとのスケールに戻す対数表示



1

10

100

1,000

10,000

100,000

1,000,000

10,000,000

1 10 100 1,000 10,000 100,000


実績工

数(開

発5工

程)[人

時]

Copyright IPA SEC

N=262

ポイント：規模と工数の分析結果とデータの見方(1)

データの関係性

新規開発、IFPUGグループ

データ白書2009

P129，図表6-4-11

・ＦＰ規模と工数には正の「相関」が認められる。

例）新規開発、IFPUGグループ

工数＝ A × （ＦＰ規模）**B B＝1.19 （Aは係数、相関係数R=0.87）

（B = 1.19 の場合、FP規模が2倍になると、工数は約2.28倍になる。）

FP規模と工数 (新規開発、IFPUGグループ) 対数表示

0

50,000

100,000

150,000

200,000

250,000

300,000

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000


実績

工数

(開発5工程

)[人

時]

y(50%)

y(-50%)

Copyright IPA SEC

N=262

データ白書2009

P128，図表6-4-9

FP規模と工数 (新規開発、IFPUGグループ) 信頼幅50%付き



事例：規模と工数のデータの使い方

利用イメージ・事例

例）新規開発、IFPUGグループ

4,000FPの規模のプロジェクト工数は、

50％の信頼幅の曲線を読み取ると

⇒

約40,000人時から1１0,000人時

（約250人月～690人月）の範囲。

これを、妥当性の目安とする。

留意点

規模が大きくなると規模の増加率以上に工数が増大する

⇒ 一般的に規模が大きくなると関係者も多くなり、間接的な工数が増加する。

・品質保証、技術支援、関係者間の調整（コミュニケーション・オーバーヘッド）・ベンダ、ユーザの質や役割といった要素の影響等

0

50,000

100,000

150,000

200,000

250,000

300,000

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000


実績

工数

(開発

5工

程)[人

時]

y(50%)

y(-50%)

Copyright IPA SEC

N=262

データ白書2009

P128，図表6-4-9

FP規模と工数 (新規開発、IFPUGグループ) 信頼幅50%付き

40,000

110,000

▲



開発5工程の工数と工期 (新規開発) 信頼幅50%、95%付き

Copyright IPA SEC0

5

10

15

20

25

30

35

0 50,000 100,000 150,000 200,000 250,000 300,000

実績工数(開発5工程) [人時]

実績

月数

(開発

5工

程)[月

]

y(50%) y(-50%)

y(95%) y(-95%)

Copyright IPA SEC

N=430

ポイント：工数と工期の分析結果とデータの見方

・新規開発では工数と工期には正の「相関」が認められる

⇒ ばらつきはあるが、工期（月数）は工数の３乗根に概ね比例している。

例）新規開発、開発５工程

工期＝ A × （工数）* * 0.31 （Aは係数、相関係数 R = 0.70）

・散布図の分布状況

信頼幅95％の下限値より下にはプロジェクトがほとんどない。

⇒ 工数に対する工期の実現可能性を考える上で目安になりそうである。


※工数に対する工期の回帰の50％、95％信頼幅付き

新規開発（開発5工程）

データ白書2009

P118，図表6-3-2



例）新規開発、開発５工程

・工数が約60,000人時

（約375人月）の場合、

工期（月数）の中央値は

12～13ヶ月である。

・信頼幅95％の下限値の

工期（月数）を見てみると

約５ヶ月である。

⇒ 工期短縮には限界がある12ヶ月から工期短縮を目指しても、5ヶ月以下にするには

無理があるかもしれない。

また、50%の下限値は約9ヶ月であり、目標の目安として考えられる。

Copyright IPA SEC

0

5

10

15

20

25

30

35

0 50,000 100,000 150,000 200,000 250,000 300,000

実績工数(開発5工程) [人時]

実績

月数

(開発

5工

程)[月

]

y(50%) y(-50%)

y(95%) y(-95%)

Copyright IPA SEC

N=430

事例：工数と工期のデータの使い方


12～13

開発5工程の工数と工期 (新規開発) 信頼幅50%、95%付き

（60,000、5.0)



ソフトウェア改良開発における見積りは、新規開発に比べて、以下のように

改良開発の特質を考慮したテスト量の見積りが重要である。

・既存の母体システムにおける品質面での考慮（既存システムの品質が思わしくない場合、品質を確保する作業が必要）

・テスト巻き込み規模（変更の際に影響を受ける部分を表す規模）の把握

データ白書2009では、改良開発のプロジェクトを対象に、SLOC規模とテスト

ケース数の関係を母体規模別に示している。

・母体規模を大・中・小の３つに分ける。（大は200以上、中は50～200未満、小は50未満：単位KSLOC）

・それぞれ「母体規模大」、「母体規模中」、「母体規模小」とし、散布図の中で識別して示す。

【参考】母体規模別のＳＬＯＣとテストケース数(1)

改良開発の見積りにおけるテスト量について



0

5,000

10,000

15,000

20,000

25,000

0 100,000 200,000 300,000 400,000 500,000 600,000 700,000

実効SLOC実績値

テストケース数_総

合テスト（ベンダ確認） a：母体規模小

b：母体規模中

c：母体規模大

Copyright IPA SEC

N=77

実効SLOC実績値は母体を含まない規模である。

・実効SLOC実績値が100KSLOC以下でテストケース数の大きなプロジェクには、母体規模が大きいプロジェクトが多い。

・実効値としての規模だけではなく、母体の規模も考慮し、テストケース数や、生産性を加味した見積りや計画策定が必要。

【参考】母体規模別のＳＬＯＣとテストケース数(2)

SLOC規模とテストケース数（総合テスト（ベンダ確認））（改良開発、母体規模別）データの関係性



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



計画（プロジェクト計画策定）

計画策定時のスケジュール、工数割振りにおけるデータ活用ポイント

１．工数、工期の妥当性の確認

⇒ プロジェクト全体、工程別の工期、工数の適正度の評価⇒ 計画実現の達成度、リスク度の把握

２．工数（要員）山積みの妥当性の確認

⇒ 工数比率と工期比率を利用した工数山積み妥当性確認の方法

⇒ 計画実現の達成度、リスク度認識

⇒ 工程別の実績工数比率からの妥当性確認





工期、工数の妥当性の確認

プロジェクト計画の策定時には、見積りのアウトプットである工数や

工期、マスタスケジュール、様々な前提条件などから、さらに詳細・

具体的な計画を作成する。

計画策定においては、定量データを活用し、計画案の作成、妥当性の

確認などを行い、実現性の高い計画とすることが重要である。

その際、見積り時にも利用した工数と工期の関係、規模と工数の関係

のデータを活用することができる。

・信頼幅を利用し、工期のリスク度合いや生産性度合いを把握する。

・工数と工期、規模と工数の両者の関係から、妥当性を確認する。



事例：計画策定時における開発条件の検討(1)

想定シーン：計画局面における開発条件の検討。

定量データの利用目的：システム開発における、規模、工数、工期からの適切な計画案の策定。

見方・使い方：


赤▲：当初案

緑▲：計画変更提案

規模と工数の軸反転工数と工期



事例：計画策定時における開発条件の検討(2)

(1)図表から認識できること

・想定工数に対し工期が信頼幅線下位50％以下と相対的に短くリスクが高い。

・しかし規模は反転した信頼幅線の右50％の近傍で、相対的に工数は多め（低生産性）である。

(2)利用・想定事例

ケース１：発注側の要件として工期を優先する場合、開発規模を小さくするため機能を削減するか、または分割開発により工期をずらし、機能毎の優先度と必要時期を協議する。

ケース２：発注側が工期に拘らない場合、コストを守ることを前提に、工期を50％信頼幅の中央部近傍の12～14ヵ月を提案する。

ケース３：開発対象機能(規模)を優先する場合、工期を12～14ヵ月で提案すると共に、工数を50％信頼幅の中央部近傍の80,000人時を提案する。（図中の緑▲位置）



工数山積みの妥当性の確認

工程別の工数、工期比率の関係を見出し、プロジェクト全体から、さらに詳細な見積、計画、評価などに利用できるようにする

見積り結果として引き継がれた工数、工期、マスタスケジュールなど

に基づき、実際の要員割振りまで考慮した詳細なプロジェクト計画を

策定する過程で、工数山積みの妥当性を確認することも必要である。

「データ白書」では、以下の点も一つの目的として、工数比率および

工期比率のデータを提供している。



ポイント：工数比率と工期比率のデータ活用

工数比率や工期比率がモデル化できれば・・・

・開発プロジェクトの見積や計画時に利用

⇒ 各工程にどの位の工数と期間がかかるか、要員を各工程に何人くらい投入するか

① 開発すべきシステムの構築に必要な総工数、全体工期を算出

② 工数比率によって、各工程に必要な工数を算出

③ 工期比率によって、各工程に必要な期間を算出

④ 上記②と③から、各工程に必要な要員数を算出

基本設計詳細設計製作結合テスト総合テスト

工数

工期

要員数

合計

②

④

①③



・比率が高い工程には「それだけ多くの作業工数がかかる」ということになる。

・プロジェクト全体の工数の35％弱を製作工程が占めている。・要件定義の工程は、プロジェクト特性により異なる場合もあり、同じ尺度としての見方は難しい面もあるので、あくまでも目安として参照する。

工数比率・・・各開発工程を実施するのに必要な作業工数の比率

工程 N 最小 P25 中央 P75 最大平均標準偏差基本設計 428 0.001 0.095 0.147 0.205 0.589 0.161 0.096詳細設計 428 0.016 0.114 0.166 0.220 0.613 0.174 0.086製作 428 0.018 0.272 0.349 0.449 0.847 0.370 0.148結合テスト 428 0.002 0.106 0.155 0.211 0.938 0.167 0.096総合テスト(ベンダ確認) 428 0.000 0.061 0.117 0.175 0.564 0.128 0.087

（新規開発）

データ白書2009

P239，図表8-1-8

データの関係性・留意点

データ白書2009

P239，図表8-1-9

要件定義工程も含めた工程別の実績工数の比率の基本統計量（新規開発） (単位：比率)工程 N 最小 P25 中央 P75 最大平均標準偏差

要件定義 232 0.001 0.046 0.082 0.133 0.672 0.101 0.085開発5工程 232 0.328 0.867 0.918 0.954 0.999 0.899 0.085

ポイント：工数比率の分析結果とデータの見方



工程 N 最小 P25 中央 P75 最大平均標準偏差基本設計 115 0.016 0.155 0.230 0.302 0.522 0.234 0.107詳細設計 115 0.026 0.143 0.189 0.248 0.645 0.201 0.093製作 115 0.047 0.209 0.260 0.350 0.902 0.280 0.118結合テスト 115 0.016 0.091 0.143 0.185 0.386 0.146 0.068総合テスト(ベンダ確認) 115 0.014 0.074 0.121 0.184 0.571 0.140 0.091

工期比率・・・各開発工程を実施するのに必要とされる期間

・比率が高い工程には「それだけ長い作業期間を要する」ということになる。

・プロジェクト期間全体の約３０％（1/5～1/3）を製作工程が占めている。

・これは必ずしも比率が高い工程に多くの要員が必要ということではない。⇒ 要員数が少なくても工程の期間が長いと、工程全体の工数は多くなる。

（新規開発）

データ白書2009

P236，図表8-1-2

データの関係性・留意点

(単位：比率)工程 N 最小 P25 中央 P75 最大平均標準偏差

要件定義 70 0.032 0.098 0.143 0.232 0.466 0.173 0.102開発5工程 70 0.534 0.768 0.857 0.902 0.968 0.827 0.102

データ白書2009

P237，図表8-1-3

要件定義工程も含めた工程別の実績月数の比率の基本統計量（新規開発）

ポイント：工期比率の分析結果とデータの見方



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



コントロール

プロジェクト遂行中の管理、コントロールにおけるデータ活用のポイント

１．生産性データによる実績評価

⇒ 層別した生産性データの利用と留意点

２．計画（ベースライン）からの差異発生時の今後の見通し

⇒ 現在までの生産性評価からの今後の予測の考え方

⇒ 工数、工期比率からの現在以降の再見積りと評価





生産性データによる実績評価

生産性の傾向を把握して、見積りや計画の妥当性確認、実績の評価などに利用できるようにする

層別による生産性に、傾向や相関が見えれば・・・

・層別した生産性データの利用

⇒ 対象とするプロジェクトの特性と類似したものの、データを参考にすることができる。

「データ白書」では、様々な層別により生産性データを提供している。

例）

・規模による層別：規模の大小で使い分ける

・要員数による層別：月あたりの要員数の大小で使い分ける

・業種による層別：業種別の生産性データを使い分ける



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

01,000

2,000

3,000

4,000

5,000

6,000

7,000

8,000

9,000

10,000

11,000

12,000

13,000

14,000

15,000

16,000

17,000

18,000

19,000

20,000

21,000

22,000


FP生産

性(FP/開

発5工

程工

数)

Copyright IPA SEC

N=262

3,000FP

以上

1,000FP

以上

3,000FP

未満

400FP

以上

1,000FP

未満

400FP

未満

FP規模

0.80

0.70

0.60

0.50

0.40

0.30

0.20

0.10

0.00

FP

生

産

性

[FP／人時]

ポイント：規模と生産性の傾向

新規開発、IFPUGグループ：規模と生産性

[FP/人時]

[FP]

FP規模別

[FP/人時]

データ白書2009

P137，図表6-5-5

データ白書2009

P137，図表6-5-6

FP規模別FP生産性


・規模を1000FP未満と1000FP以上に層別すると、後者のグループの生産性は前者より低い。

・小規模では生産性のばらつきが大きく、大規模では生産性に上限があるように見える。



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140

月あたりの要員数 [人]

FP生

産性(FP/開

発5工程

工数)

Copyright IPA SEC

N=139

ポイント：月あたりの要員数と生産性の傾向

新規開発、IFPUGグループ：月あたりの要員数と生産性

[FP/人時] [FP/人時]

月あたりの要員数

データ白書2009

P144，図表6-5-19

データ白書2009

P144，図表6-5-20


・要員数が１０人以上の場合、FP生産性は要員数１０人未満に比べてかなり低い。（大人数の開発体制では、生産性に上限があるように見える）

月あたりの要員数とFP生産性(新規開発、IFPUGグループ)



ポイント：業種と生産性の傾向

生産性の差の分析（例）：業種別生産性

業種（大分類） N 生産性（中央値）

製造業３９ 0.118

情報通信業２１ 0.102

卸売・小売業３０ 0.067

金融・保険業６９ 0.043

公務（他）１３ 0.094

[FP/人時]

業種による生産性の差が

見られる

白書2009、139Pより

製造業

＞金融・保険業

製造業と金融・保険業の比較（新規開発）（データは中央値）

業種規模工数工期月当たりの要員数

製造業 575FP80.5KSLOC

6,764人時 6.6ヶ月 5.9人

金融・保険業 783FP114.9KSLOC

15,795人時 8.1ヶ月 11.4人

「金融・保険業」は他の業種と比べて生産性が低いと読み取れるが、規模や体制の他にも業種、言語など多くの要因が影響しており、生産性の単純比較はできない。



ポイント：生産性データ利用時の留意点


①ある局面において、これまでの実績工数とプロジェクトの規模から生産性を算出する。

②収集した定量データの規模と工数の相関から、プロジェクトの規模に対応する工数（統計値）を求め、生産性を算出する。

③両者を比較し、乖離の度合いとその原因を調べ、妥当性を評価する。

留意点

・工数と開発規模の相関関係やデータ領域を考慮し、自己の生産性の位置がどの領域にあるかにより、生産性効率を評価する。

・ソフトウェア開発プロジェクトのデータは、正規分布をしていない場合が多い。

⇒ 全体のプロファイルを表す数値としては、中央値の方が平均値よりも適切であることが多い。

収集したデータの特徴、傾向を把握し、活用することが重要である。



c：中位,

d：低い

a：極めて高い,

b：高い

要求レベル

30.00

20.00

10.00

0.00

SLOC

生

産

性

[SLOC／人時]

c：中位,

d：低い


b：高い

要求レベル

0.80

0.70

0.60

0.50

0.40

0.30

0.20

0.10

0.00

FP

生

産

性

[FP／人時]

c：中位,

d：低い


b：高い

要求レベル

0.80

0.70

0.60

0.50

0.40

0.30

0.20

0.10

0.00

FP

生

産

性

[FP／人時]

c：中位,

d：低い


b：高い

要求レベル

30.00

20.00

10.00

0.00

SLOC

生

産

性

[SLOC／人時]

【参考】信頼性要求のレベルと生産性


データ白書2009

P158，図表6-5-51

要求レベル（信頼性）別FP生産性箱ひげ図

（新規開発、IFPUGグループ）

データ白書2009

P147，図表6-5-26

要求レベル（信頼性）別FP生産性箱ひげ図

（改良開発、IFPUGグループ）

要求レベル（信頼性）別SLOC生産性箱ひげ図

（新規開発、主開発言語グループ）

データ白書2009

P184，図表6-7-22

要求レベル（信頼性）別SLOC生産性箱ひげ図

（改良開発、主開発言語グループ）

データ白書2009

P194，図表6-7-44

FPの新規開発と改良開発、SLOCの新規開発と改良開発とでは、傾向が異なる。



差異発生時の今後の見通しについて

プロジェクトが進むに従い、当初の計画と実績に差異が発生する場合

がある。（例えば作業進捗や消化工数など。）

プロジェクトコントロールにおいて、差異を吸収して計画通りに完了

させるため、何らかの手を打つかどうかを判断し、対応することが

必要である。

・当初不明確であった情報、条件などが明確になれば、さらに精度の高い残作業の見積り（残りの工程の予定）を行う。

・再度測定した規模、これまでに掛かった期間、消化した工数、実績からみた生産性などから、今後の実現性を検証する。

ここでは、プロジェクトがある途中の工程を終えた段階で、定量的に

現状把握を行い、今後の見通しについて評価する事例をあげる。



基本設計工程が終わった段階で、後工程を見通す際の注意点

事例：工数比率と工期比率のデータの使い方

利用イメージ・事例：基本設計までの工期から全工期を予測すると？

データ白書2009

P236，図表8-1-1

工程別の工期比率の箱ひげ図読み方：

基本設計工程は全工期の概ね15-30％を占める。

中央値： 23.0%

使い方：

基本設計工程にかかった工期から、それ以降の

工期は約2.3～5.6倍かかると予測できる。

中央値で見ると：約３．３倍

計画値で全工程６ヶ月半のプロジェクトの場合：

基本設計１．５ヶ月の予定が２ヶ月かかった。 ⇒ ２週間遅れ、計画上残り４ヶ月半。

基本設計以降の工期は、（２＊３．３＝６．６）から、あと約６ヶ月半はかかる可能性。

！基本設計が２週間遅れただけと安易に考えていると、実質２ヶ月も遅れるリスクを見落とすことになる。



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



評価

プロジェクト完了時の工数、工期、生産性などのプロジェクト評価

１．開発力の評価

⇒ プロジェクト完了時の規模、工期、工数、生産性の評価

見積算定者やPM自身が、次の案件・プロジェクトで役に立てるため、

分析・蓄積・再利用の観点からの定量データ活用が重要である。



予実差の程度や傾向を見出し、実績値からなる統計データに対して、変動を見込む目安として利用できるようにする



0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

0 50,000 100,000 150,000 200,000 250,000 300,000 350,000

計画工数(プロジェクト全体：基本設計開始時点)

実績

工数

(プロジェクト全

体)

a：新規開発

b：改修・保守

c：再開発

d：拡張

Copyright IPA SEC

N=804

0

50

100

150

200

250

300

～-0.8

～-0.6

～-0.4

～-0.2

～0.0

～0.2

～0.4

～0.6

～0.8

～1.0

～1.2

～1.4

～1.6

～1.8

～2.0

～2.2

～2.4

～2.6

～2.8

～3.0

3.0超

←計画内工数の計画超過率超過→

件数

0

50

100

150

200

250

300

350

400

～-0.50

～-0.45

～-0.40

～-0.35

～-0.30

～-0.25

～-0.20

～-0.15

～-0.10

～-0.05

～0.00

～0.05

～0.10

～0.15

～0.20

～0.25

～0.30

～0.35

～0.40

～0.45

～0.50

～0.55

～0.60

0.6超

←計画内工期の計画超過率超過→

件数

0

10

20

30

40

50

60

70

80

～-0.6

～-0.5

～-0.4

～-0.3

～-0.2

～-0.1

～0.0

～0.1

～0.2

～0.3

～0.4

～0.5

～0.6

～0.7

～0.8

～0.9

～1.0

～1.1

～1.2

1.2超

←計画内 FP規模の計画超過率超過→

件数

ポイント：データ白書に見る予実差異

超過率＝｛実績値 - 計画値｝÷計画値

FP規模中央値0.0％

平均9.2％増加

工数中央値2.3％

平均48.3％超過

工期中央値0％平均5.4％超過

データ白書2009

P264，図表9-1-4

データ白書2009

P268，図表9-1-13

データ白書2009

P267，図表9-1-10

データ白書2009

P267，図表9-1-8

・規模・工数・工期ともに超過傾向・実績工数は超過傾向が他より大きい

FP規模の計画と実績の差の比率の分布工期の計画と実績の差の比率の分布

工数の計画と実績工数の計画と実績の差の比率の分布



事例：プロジェクト完了時の評価

想定シーン：PMによるプロジェクト完了時のプロジェクト評価。

定量データの利用目的：短期開発のため要注意プロジェクトと指定し重点監視したが、計画時（100,000人時、12ヵ月）の予定が、実績（130,000人時、13ヵ月）となった。結果から見て開発力が妥当な範囲か評価したい。

見方・使い方：


緑▲：計画値

赤▲：実績値

赤＋：実績自己の位置



事例：プロジェクト完了時の評価

(1)図表から認識できること

・工数と工期の信頼幅線下位50％を下回り、計画段階から工期が厳しく挑戦的な工期であった。実績も同様で、工数の割に工期が厳しく、短期での開発力、管理力が備わっていることが分かる。

・工数が30％増加しているが、工期を守るためのトレードオフと推察できる。

(2)利用・想定事例

ケース１：平均要員数60人規模のプロジェクトを短期で開発・管理できる能力がある。これを強みと捉え、実践した施策、手法をプロセスとして文書化する。

ケース２：短工期に対応できる工程別工期比を自社の特徴と捉え、新たなプロジェクトに際しても適用する。



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 10,000 11,000 12,000 13,000


FP生産

性(FP/開発

5工程

工数)

a：レベル6、レベル7

b：レベル5

c：レベル4

d：レベル3

Copyright IPA SEC

N=109

0

10

20

30

40

50

60

70

80

90

0 500,000 1,000,000 1,500,000 2,000,000 2,500,000 3,000,000 3,500,000 4,000,000

実効SLOC実績値

SLOC生産

性(SLOC/開発

5工程

工数

)

a：レベル6、レベル7

b：レベル5

c：レベル4

d：レベル3

Copyright IPA SEC

N=79

【参考】規模とＰＭスキル

データの関係性データ白書2009

P275，図表9-2-6

PMスキル別のFP規模とFP生産性（新規開発） PMスキル別のSLOC規模とSLOC生産性（新規開発）

データ白書2009

P278，図表9-2-9

新規開発プロジェクトを対象にFP規模とFP生産性、SLOC規模とSLOC生産性をPMスキル別に層別して示している。

⇒ 規模の小さいプロジェクトは生産性のばらつきが大きく、PMスキルの分布もばらついている。規模の大きいプロジェクトは生産性が低い傾向と同時に、PMスキルが高い傾向が見られる。



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



ＳＥＣが提供するツール群

②定量データの投入

④収集データの精査 ③定量データの送付

データ提供企業IPA/SEC

データ収集サイクル

①定量データの収集依頼

■収集ツール

⑦文書化・編集

⑥白書コンテンツ決定

⑤分析・コンテンツ作成

機密室

機密室

SECデータ

⑧データの引継ぎ

⑨コンテンツ作成

開発5工程の工数と工期 (新規開発) N=185

0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000

実績工数（開発5工程） [人時]

実績

月数(開

発5工

程)[月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC ⑩プロジェクト診断引継データ

■診断支援ツール（Webサイト）

一般利用者（企業）

■分析ツール

■スタンドアロン型診断支援ツール

データ登録

データ出力


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200 ,000 250,000 300 ,000


実績

月数(開

発5工程

)[月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200 ,000 250,000 300 ,000


実績

月数(開

発5工程

)[月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200 ,000 250,000 300 ,000


実績

月数(開

発5工程

)[月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC

簡易分析自社蓄積データ



プロジェクト診断支援ツール（Ｗｅｂ）

プロット可能図表一覧利用者が登録したデータが、どの図表にプロットできるのかを一覧で表示する。

信頼幅％指定信頼幅を引くことができる散布図の場合、その値を任意に指定することができる。

自社プロジェクトデータ属性表示

散布図にプロットされたデータの番号と名称がマウスオーバーで表示される。

人時／人月切替え散布図および箱ひげ図の工数をどちらの単位で表示するか選択することができる。

機能特徴

自社データのプロット１件または複数件のプロジェクトデータを入力し、統計図表上に自社データの位置をプロットすることができる。自社データのみの表示も可能。機密保全のため、入力したプロジェクトデータはログオフ時にすべて破棄され、サーバ等には一切残らない。

図表の拡大と縮小散布図を拡大、縮小する。プロットが局所に密集している場合、拡大によって、その部分の状況をより詳細に確認することができる。拡大する際の基点の指定も可能。

データ種別の選択種別分類した散布図で、特定の種別だけに絞って描画することができる。

ＸＹ軸の反転各社の評価軸に合わせて、散布図のＸＹ軸を反転させることができる。

対数グラフの表示散布図に通常表示と対数表示がある場合、ボタンひとつで表示を切り替えることができる。通常表示では分かりづらい傾向が、両対数変換すると見えてくる可能性がある。

図表のコピー＆印刷 WORDやEXCEL等で作成した文書に統計図表を貼り込んだり、画面を印刷したりすることができる。

ソフトウェア開発データ白書の統計情報を活用し、ソフトウェア開発におけるQCDの見える化を支援するツール

2007年12月25日よりＳＥＣのWebサイトで公開、稼働中！



プロジェクト診断支援ツール画面イメージ



自己データを容易な画面入力で蓄積可能入力項目を約50項目に絞った簡易入力フォームを用意

入力項目は極力選択式にしてあり、入力が簡単である

入力データの自動精査が行えるので、蓄積データの精度が高い

ボタン一つで入力プロジェクトデータを蓄積できる複雑なDBシステムを構築する必要がなく、簡便にデータを蓄積できる

自己データを利用して白書と同じ分析図表が簡単にできる自己データを基に見積もり、プロジェクト計画の参考になる図表ができる

自己データなので他社データを利用するより正確である

自己データでベンチマーキングができる

自身の開発の特徴、傾向の客観的把握ができる

スタンドアロンで動作するため、手軽かつ気楽に扱える

WebからのデータのアップロードによりＳＥＣデータとの比較も可能である

他社と比較して自己の強み、弱みを認識できる

デスクトップ上で自己のプロジェクト情報を活用し、

自己のソフトウェア開発におけるQCDの見える化を支援するツール

スタンドアロン型プロジェクト診断支援ツール



スタンドアロン型ツールの機能と特徴

機能

データ入力（入力フォーム切替え）

図表作成

以下の図表を作成することができる。

1. 工数－工期：散布図2. 規模－工数（FP) ：散布図3. 規模－工数（SLOC) ：散布図4. 規模－生産性（FP）：散布図5. 規模－生産性（SLOC）：散布図6. 工数別月数比：基本統計量7. 工程別工数比：基本統計量

種別や業種など7項目で絞込みができる。

8. 規模－発生不具合数（FP）：散布図9. 規模－発生不具合数（SLOC）：散布図

10. 規模－発生不具合密度（FP）：散布図11. 規模－発生不具合密度（SLOC）：散布図12. レビュー指摘件数（FP）：基本統計量13. レビュー指摘件数（SLOC）：基本統計量14. レビュー指摘件数（工数）：基本統計量

データ精査

CSV出力

データ一括取込

データ一括出力

同一フォーマットの別ファイルのプロジェクトデータを一括して取り込む。

登録されているプロジェクトデータを、編集可能な状態で別ファイルに出力する。

特徴

簡易版（必須項目数：15）と全体版（必須項目数：41）の2種類のフォームで登録することができる。図表の作成は、簡易版による入力で問題ない。全体版を利用すれば、1つのプロジェクトデータで、最大約400項目まで登録可能。

Webツールにアップロード可能なCSV形式のファイルを出力する。

入力データの自動精査が可能で、管理データの精度を高めることができる。



記入フォーム



図表選択



規模（ＦＰ）と工数の関係

規模－工数（FP）

0

5000

10000

15000

20000

25000

0 200 400 600 800 1000 1200 1400

FP実績値

実績工数

[人時]



工程別工数比（基本統計量）

0.0120.0820.1020.090.0810.0720.06110実績工数総合テスト（比率）

0.0210.1030.1290.1220.1060.0810.07810実績工数結合テスト（比率）

0.0750.6210.7240.6950.6150.5550.5110実績工数製作（比率）

0.0230.1060.1430.1250.1040.0830.07910実績工数詳細設計（比率）

0.0230.0880.1220.1070.0890.0690.05610実績工数基本設計（比率）

標準偏差平均最大P75中央P25最小N

0.0120.0820.1020.090.0810.0720.06110実績工数総合テスト（比率）

0.0210.1030.1290.1220.1060.0810.07810実績工数結合テスト（比率）

0.0750.6210.7240.6950.6150.5550.5110実績工数製作（比率）

0.0230.1060.1430.1250.1040.0830.07910実績工数詳細設計（比率）

0.0230.0880.1220.1070.0890.0690.05610実績工数基本設計（比率）

標準偏差平均最大P75中央P25最小N



本日の内容

１．はじめに





品質予測


①見積り

②計画


④評価


６．まとめ



より良いソフトウェア開発と業界の発展のために

プロジェクトのデータ収集をしましょう！

定量データのご提供、随時募集中です！

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

IPA（独立行政法人情報処理推進機構） http://www.ipa.go.jp/

SEC（ソフトウェア・エンジニアリング・センター） http://sec.ipa.go.jp/

・データ白書はデータの宝庫ではあるが、

全ての答えがそこにある訳ではない・見積や計画策定について、過去の事例を参考に、

まずは自分で行うことが重要

・自分の見積や計画の妥当性を確認するために、データ白書を紐解く

最後に

ソフトウェア開発データ白書2009と 定量データの...

Documents

ソフトウェア開発データ白書2009と定量データの...