Information-technology Promotion Agency, Japan 定量的品質管 … · プロジェクト管理プロセスと品質保証（qa)プロセスのテーラリングプロジェクトのリスクを分類して「群」に割り振り、その群単位に順次評価しプロジェクト

SEC Software Engineering for Mo･No･Zu･Ku･Ri

Software Engineering Center 1

Information-technology Promotion Agency, Japan

Software Engineering Center

定量的品質管理とメトリクス活用促進

～メトリクス活用のアプローチ～

独立行政法人情報処理推進機構(IPA) 技術本部ソフトウェア・エンジニアリング・センター(SEC)

三毛功子

エンタプライズ系総合セミナー第3日：「ソフトウェア開発における定量的管理と標準化」

2013年3月6日 13時50分～15時05分（75分）


Software Engineering Center 2 エンタプライズ系総合セミナー, 2013-03-06 Copyright © 2009-2013 IPA, All Rights Reserved.

目次

1. はじめに

2.定量的品質予測のススメ

3. 利用目的別メトリクス一覧表

4. リスク予防への活用のアプローチ

5. おわりに



①ＳＥＣが提供する定量関連のコンテンツ・ツール群

SECコンテンツ（今回の説明）



②SECのデータ白書

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

「ソフトウェア開発データ白書」（2012年度：27企業、3089プロジェクトのデータ）

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

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

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

1774

942

1418

2056

2005 2006 2008 2007

2584

2327

2009 2010 2011

プロジェクト評価の基礎となるデータの蓄積

3089

2012 2013



1. はじめに




5. おわりに



①定量的品質管理の考え方

ITシステムの障害の影響が深刻化し、高品質な情報システムが求められている「品質を高める」＝品質を測定する物差しが必要

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

定量的品質予測が必要

定量的品質予測のためにどうやって品質を予測すればいいか

そのためには、何をどのように測定すればいいのか

2006年から2008年まで定量データ分析部会（データ白書のデータ提

供、レビューを実施）のWG2で参加企業（７社、１大学）が実際に取り組んでいる品質予測の手法を整理

2008年から2010年まで、メンバーを追加して、上流工程に焦点をあててプロセス（特に組織的準備）と定量的品質管理の阻害要因を整理



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

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

人の作業

データの受渡し

作業の流れ分析・モデル化モデル

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

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

要件定義基本設

計詳細設

計製作

総合テスト

結合テスト

【プロジェクト】データ

計画（P) 対策（A)

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

モデルの改善・見直し

単体テスト

測定（D) 分析･予測（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

品質不良と予測

レビュー指摘密度

ゾーン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

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

① ここの値から

②ここの値を予測する

ゾーン分析

どうみるか

管理図分析

曲線近似分析

トレンド分析

チェックリスト分析



システムリスク

S1S2S3S4S5

23455P5

23444P4

22333P3

22222P2

11111P1プロジェクトリスク

システムリスク

S1S2S3S4S5

23455P5

23444P4

22333P3

22222P2

11111P1プロジェクトリスク

統合リスク

小

大

大

小

S2システムリスク総合評価（ランク）

・・・・・・・・・・

20102信頼性

30103社会性・公共性

評価重み評価システムリスク

S2システムリスク総合評価（ランク）

・・・・・・・・・・

20102信頼性

30103社会性・公共性

評価重み評価システムリスク

P3プロジェクトリスク総合評価（ランク）

・・・・・・・・・・

824要求納期

551新規／継続

評価重み評価プロジェクトリスク

P3プロジェクトリスク総合評価（ランク）

・・・・・・・・・・

824要求納期

551新規／継続

評価重み評価プロジェクトリスク

プロジェクト管理プロセスと品質保証（QA)プロセスのテーラリングプロジェクトのリスクを分類して「群」に割り振り、その群単位に順次評価しプロジェクトランク付けする

社会性・公共性、信頼性、性能等、これから開発するシステムの重さを表す要素群。

開発にあたるプロジェクトが内包するリスク、あるいはプロジェクトが置かれる環境・状況が呈するリスクの大きさを表す要素群

統合リスク

②事例組織的準備事例



プロジェクト管理プロセスのテーラリング

作業成果物と設計作業の状況から、プロジェクトの設計品質を評価し開発作業を次工程に進めてよいかどうかを判定するゲートレビューを、統合リスクとコストからテーラリングし、プロジェクト特性に応じた質・量で実施する。

品質保証（QA)プロセスのテーラリング

品質保証（QA）の活動を、統合リスクとコストからテーラリングする。

○事業部として実施○部として実施YY百万円以上

○事業部として実施○事業部として実施ZZ百万円以上開発コスト

○全社として実施○全社として実施統合リスク１、２

○部として実施ーXX百万円以上

製造開始可否判定詳細設計開始可否判定

○事業部として実施○部として実施YY百万円以上

○事業部として実施○事業部として実施ZZ百万円以上開発コスト

○全社として実施○全社として実施統合リスク１、２

○部として実施ーXX百万円以上

製造開始可否判定詳細設計開始可否判定

・「標準QA」は、業務規程に照らしたプロジェクト監視を主体に品質保証する

・「CL」は、プロジェクト個別に作成したチェックリストを使用して品質保証する

・「V2」は、成果物の検証および妥当性確認を品質保証部署独自に実施する

標準QA+CL+V2標準QA+CL標準QA５

標準QA+CL+V2標準QA+CL+V2標準QA４

標準QA+CL+V2標準QA+CL+V2標準QA+CL３

標準QA+CL+V2標準QA+CL+V2標準QA+CL+V2１、２統合リスク

YY百万円以上XX百万円以上XX百万円未満

開発コスト

・「標準QA」は、業務規程に照らしたプロジェクト監視を主体に品質保証する

・「CL」は、プロジェクト個別に作成したチェックリストを使用して品質保証する

・「V2」は、成果物の検証および妥当性確認を品質保証部署独自に実施する

標準QA+CL+V2標準QA+CL標準QA５

標準QA+CL+V2標準QA+CL+V2標準QA４

標準QA+CL+V2標準QA+CL+V2標準QA+CL３

標準QA+CL+V2標準QA+CL+V2標準QA+CL+V2１、２統合リスク

YY百万円以上XX百万円以上XX百万円未満

開発コスト



レビュープロセスのテーラリング

個々のレビュー対象成果物に対して、特徴に応じたレビュープロセスをテーラリング【対象成果物】

設計ドキュメント（要件定義書、基本設計書、外部仕様書、内部仕様書、運用マニュアル等）【レビュー実施手順選択に用いる成果物特徴】

成果物サイズ（A４換算ページ数）

成果物の重要度（重要／通常、レビュー責任者が判断する）

非熟練者（開発経験２年未満の者など）が担当した成果物のレビュー実施手順を別途定める。

【レビュー実施手順の構成項目】（ △選択、 ◎必須）

部分レビュー： △ 急ぎ過ぎを防ぐため、ミーティング１回でレビューする量を制限する。

自己チェック： ◎ 作成基準違反、誤字脱字、体裁の乱れ、あいまい表現をチェックし是正する。

概要説明： △ レビューアに対し、レビュー実施に必要な情報を提供し質問に答える。

レビュー手法： ◎ 個人レビュー／ウォークスルー／チームレビューを組み合せる。

レビューツール： △ 観点の特定／チェックリストの整備を事前に行い適用する。

レビュー記録： ◎ 所定の記録項目を記録し保管する。

レビュー分析： ◎ レビューが効果的・効率的に実施できたかどうかを振り返り改善する。



手順１）品質管理レベルの評価成果物サイズ（大／小）と重要度（重要／通常）を組み合せた４区分（非熟練者分を含めると６区分）で管理レベルを評価する。

手順２）管理方法の選択成果物特徴に応じて負担軽重に配慮したドキュメントレビュー実施手順を選択する

B-2B-1通常部分

(C-2)(C-1)（非熟練者）

A-2A-1重要部分成果物の重要度

小目安：10頁((A4)以下

大目安：11頁(A4)以上

成果物のサイズレビュー

実施手順

B-2B-1通常部分

(C-2)(C-1)（非熟練者）

A-2A-1重要部分成果物の重要度

小目安：10頁((A4)以下

大目安：11頁(A4)以上

成果物のサイズレビュー

実施手順

――――△△概要説明

○○○○○○レビュー分析

○○○○○○レビュー記録

――○○○○チェックリスト

――○○○○特定観点ツール

――△△○○チームレビュー

△△――――ウォークスルー

○○○○○○パスアラウンド

○○○○――ピアデスクチェック

個人レ

ビュー

レビュー手法

○○○○○○自己チェック

―（推奨）○

―（推奨）○

―（推奨）○部分レビュー

212121サイズ（1大>10頁, 2小<=10頁）

CBA重要度（A重要,B通常,C非熟練者）

――――△△概要説明

○○○○○○レビュー分析

○○○○○○レビュー記録

――○○○○チェックリスト

――○○○○特定観点ツール

――△△○○チームレビュー

△△――――ウォークスルー

○○○○○○パスアラウンド

○○○○――ピアデスクチェック

個人レ

ビュー

レビュー手法

○○○○○○自己チェック

―（推奨）○

―（推奨）○

―（推奨）○部分レビュー

212121サイズ（1大>10頁, 2小<=10頁）

CBA重要度（A重要,B通常,C非熟練者）



評価事例：管理図分析

閾値モデル

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

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

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

管理図分析

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

UCL

LCL

品質不良と予測

レビュー指摘密度



■目的

ドキュメントの品質予測

レビューの投入工数、欠陥検出状況

同一ドキュメントのピアレビューと公式レビューの比較

■分析項目と分析の観点

レビュープロセスとプロダクトの双方を分析し、総合評価で行う。

レビュープロセスの分析

レビュープロダクトの分析

ドキュメントの品質評価・予測

レビューの投入時間の適切性レビュー体制

指摘件数の妥当性欠陥の属性品質目標の達成状況



評価と対策 ①

①

a.

b.

d.

Ｃ.



指摘分類の分析パレート図により指摘分類を分析

この事例では、上流工程のシステム要件の指摘（3*の指摘分類）が全体の70%を占めているので、発生部分の再点検が必要と判断できる



評価事例：ゾーンモデル

⑧

⑦適切な範囲

① ②

⑤ ⑥

⑨ ③ ④

テスト密度

欠陥密度

欠陥密度の標準

テスト密度の標準

●

●

下限

下限

上限

上限

ゾーン評価品質

第2ゾーンテスト効率がやや悪、テスト内容点検低←点検順位→高

第3ゾーンテスト内容が適切か点検

第4ゾーンテスト効率がやや悪、テスト内容点検

第5ゾーン

第1ゾーン一応品質は良好、テスト効率も計画通り。良

前工程の品質確保不足、内容点検

第6ゾーン前工程の品質確保不足、内容点検

第7ゾーンテスト不足、前工程の品質確保不足、内容点検

第8ゾーンテスト不足、前工程の品質確保不足、内容点検

第9ゾーンテスト不足、内容点検



⑧

⑦適切な範囲

① ②

⑤ ⑥

⑨ ③ ④

テスト密度

欠陥密度

機能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

500

1000

1500

2000

2500

3000

テスト日数

テス

ト項

目数

0

100

200

300

400

500

600

障害

数

テスト消化実績


累積欠陥数

欠陥未解決数

信頼度成長モデル使用にあたっては、

• テストに極端な偏りがない事。

• テストの網羅性が十分確保できている。

• テスト項目の消化状況。

• 未解決欠陥件数。

をあわせて評価。


テスト消化実績

累計欠陥数

欠陥未解決数



0

2

4

6

8

10

12

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

フェーズ

件/K

L

期待値

上限値

下限値

成功

0

2

4

6

8

10

12

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

フェーズ

件/K

L

期待値

上限値

下限値

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

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

時系列に減少

バラツキ小さい

結合テストで増加

バラツキ大きい

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

評価事例：トレンドモデル

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

失敗



③おわりに

「突然死」の兆候は、品質評価で察知する

プロジェクト状況の突然の悪化

稼働時期の突然の延期

定量的品質管理は絶対ではない

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

是非、ご活用ください。

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

品質の弱い点を見つけ出すためのきっかけ

弱点を重点的に追いかけるための手法



1. はじめに

2. 定量的品質予測のススメ



5. おわりに



SEC成果を熟知したコンサルタントならば、、

きちんと定量管理したいユーザ

データ白書定量的品質予測のススメ見える化

【課題】：ＳＥＣ活動成果物の中でメトリクスやその活用例、ノウハウ等がありますが、それらを横並びに見たり、直面している課題（目的）に適したメトリクスを探し出すことは容易ではありません。

SEC活動の成果物の中でメトリクスやその活用事例、どん

なものがあるのか？？

どなたが、どんな時に、どのような目的のために使いますか？・・・それならばこのSECBOOKSのこのメトリクスを使った定量管理をされてはいかがですか？

SECのメトリクスに関するノウハウ群

①はじめに



①様々な質問に対応できる分類項目ができた。

②データ白書、定量的品質予測、見える化などの情報を整理ができた。ユーザ用約90,ベンダ用約210行の利用シーン（利用シーンごと１行の形なので同じメトリクスが複数回現れることがあります）

メトリクス管理の基盤になる。

【将来】現在はSECの成果物だけなので、他団体にもコンテンツ提供のご協力をお願いして日本のメトリクス知見の基盤としたい。

メトリクス一覧表の管理項目をどうすれば欲しい情報にたどり着けるか

利用目的別メトリクス一覧表

【検討結果】：どのように分類すれば、欲しい情報にたどり着けるかをSECの成果物を整理しながら検討し、下記①、②を実施、“利用目的別メトリクス一覧表”として実現しました。 ①様々な質問に対応できる分類項目の作成 ②SECのメトリクス関係書籍の主なメトリクスを整理



利用目的別メトリクス一覧表とは利用目的別メトリクス一覧表は、SECで検討された主なメトリクスを目的カテゴリや利用者、工程などの管理項目によって分類したものです。

この表に検索機能を追加しました。

この表により利用者はSECのメトリクスに関して利用目的にあったメトリクスを簡単に見つけだすことができます。

フェーズや利用シーン、目的などの検索の他に測定要素、基本/導出測定量のようなボトムアップの検索も可能です。

本一覧表に自社のメトリクスを追加することもできます。

注）目的別メトリクス一覧表は、SECが2010年度実施した“「定量的管理基盤メトリクス分類表有効性調査」報告書の”メトリクス分類表“をベースにしています。報告書URL： http://sec.ipa.go.jp/reports/20120302_2.html

メトリクス名称目的カテゴリ利用者工程利用方法・・・・参照

レビュー指摘密度品質管理・開発部門設計フェーズ参照書籍1 ・・・参照書籍1

レビュー指摘件数品質利用者２ YYフェーズ参照書籍2 ・・・参照書籍2

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

メトリクスN 目的N 利用者N ZZフェーズ参照書籍N3 ・・・・・・参照書籍N3



・分類項目

メトリクス一覧表の構造は｢プロセス，ステークホルダ，利用シーン，メトリクス，測定方法，利用方法,参照情報等」からなります。

“利用シーン”に注目し、目的と評価質問の記述ルールを定め、目的の種別を追加することにより、利用シーンの粒度を一定にし、検索性を容易にする工夫を行いました。

②利用目的別メトリクス一覧表の仕組み

利用目的別メトリクス一覧表の利用シーンは、GQMパラダイムの考え方を取り入れています。 “何を解決したいのか”、“何を知りたいのか”などの目的を設定し、その目的を遂行するための尺度を定義して初めて、計測を行うという、GQMのトップダウンのアプローチを一覧表という形式で整理しています。

GQMモデルを階層構造で示した一般的な例

利用シーン

メトリクス



項目（大分類）説明

ソフトウｪアライフサイクルプロセス共通フレーム2007のアクティビティ

ステークホルダ

発注者／受注者

メトリクスを利用する者

発注者：経営層、業務部門、品質保証部門、情報システム部門

受注者：経営層、管理部門、開発部門

利用シーン

（Goal)

（Qｕｅｓｔｉｏｎ)

利用目的とメトリクスを利用することで得られる評価に関する質問

利用目的：目的概要、目的詳細（対象物、着眼点、目的（動作））

種別：測定、計画、予測、比較

カテゴリ：メトリクスの分類（規模、工期、工数、コスト、品質、生産性、その他）

評価質問：対象物、対象属性、比較対象、理想状態、要求状態

メトリクス

（MetrIcs)

適用方法：適用する上での概要

導出式：メトリクスの算出式と（基本）測定量の説明

定義と解釈：メトリクス値が取りうる範囲、判断基準又は解釈の仕方

基本測定量入手先・測定フェーズ基本測定量の主な入手先

基本測定量の測定フェーズ

測定方法、利用方法、

参照情報

基本測定量の測定方法、メトリクスの利用方法と備考（利用上の留意点など）、メトリクスの出典となっているSEC BOOKS → 参照先

よく使われているメトリクス

定量的品質予測のススメから１３メトリクス、データ白書のスタンドアロン型分析ツールから１１パターン、見える化総集編（上流、下流の重要項目）から抜粋

基本測定量としては、発注者、受注者とも10数種類

利用目的別メトリクス一覧表の主な項目は以下のとおりです。ソフトウェアライフサイクルプロセス毎に記載されています。利用シーンはGQMのGoalとQuestionの部分にあたります。参照情報としてメトリクスの出典となっているSEC BOOKの参照情報が記載されています。



(a)対象 (b)着眼点 (ｃ)目的(動作）

(a)対象物 (b)対象属性（c)比較対象 (d)理想状態 (e)要求状態

供給者との契約の準備、交渉を行いたい

供給者から提示された規模の見積値の要件に対する妥当性を評価し、発注者と供給者で合意する

供給者から提示された見積規模

要件に対する妥当性

発注者と供給者で合意する

計画規模供給者から提示された見積規模はあらかじめ見込んだ見積規模とどれくらい差があるか。

見積規模供給者から提示された規模の見積値

あらかじめ見込んでいる数値

同値差が小さい

←評価質問の構成要素目的(概要) 目的の詳細化(a，ｂ，c)

←目的の構成要素種別カテゴリ評価質問(ａ，ｂ，ｃ，ｄ，

ｅ)

利用シーン

目的の構成要素

(a)対象 (b)着眼点 (c)目的(動作)

「＿＿＿＿」の「＿＿＿＿」を

「＿＿＿＿」について

「＿＿＿＿」する

(a)対象物 (b)対象属性 (c)比較対象 (d)理想状態 (e)要求状態

「＿＿＿」の「＿＿＿」が「＿＿＿」に比べて

「＿＿＿」（よう）に

「＿＿＿」か？

評価質問の構成要素

① ② ③ ④

・分類項目の工夫点 GQMの考え方を適用する際に、粒度の均一化や網羅性の向上の為にテンプレートを用意いたしました。

具体的には、下記を実施しています。

• 目的詳細化、評価質問に関しては、構成要素に分解して記載方法を統一

• 種別（測定、計画、予測、比較）カテゴリ（規模、工数、工期etc.）などカテゴライズを実施



③検索機能の使い方

① 「発注者」「受注者」各シートの左上部にある「条件設定抽出」ボタンを押下します。検索ダイアログが表示されます。検索対象は現在開いているシート（「発注者」「受注者」のいずれか）です。

② 検索条件を入力します。

検索項目間はAnd条件、検索項目内の選択肢はOr条件で結合されます。

条件指定されない検索項目については、すべての選択肢が選択された場合と同様の条件となります。

*選択肢は「発注者」「受注者」の各シートごとにデータを読み込んでおり、「ステークホルダ」「基本測定量」の選択肢は発注者用と受注者用で異なります。

検索ダイアログ（発注者用）

発注者シート



③ 「検索」ボタンを押下します。

④ 「検索結果」シートが作成され、入力した検索条件と条件に該当するメトリクスが表示されます。

クリック

検索結果シート

入力した検索条件

検索条件に該当するメトリクス



⑤ 「検索結果」シートの「メトリクスの名称」列のリンクをクリックすると、該当するシート（「発注者」または「受注者」）の該当行へジャンプします。

該当行は背景色が水色に変わります。

検索結果シート

発注者シート



利用目的別メトリクス一覧表は、以下の点にご留意ください利用目的別メトリクス一覧表（検索機能付き）は、ダウンロードして各利用者の環境で使用するものです。下記の環境について動作確認をしております。

利用目的別メトリクス一覧表にはメトリクスを自由に追加できます。

所定の書式の記述方法に従って追加していただくと検索機能が維持できます。

導出測定量の追加の場合は、少し作業が複雑になりますので、詳細は利用目的別メトリクス一覧表の“「メトリクスの追加等」シート”に説明しています。

本一覧表の利用について、詳細は利用許諾書を参考にしてください。



（参考）利用シナリオ

利用目的別メトリクス一覧表の利用例を説明します。

① 「よく使われているメトリクス」からの検索



まずは、目的やフェーズを特に限定せず、どんなメトリクスがよく使われているのかを全般的に知りたい。その中で、自社のプロジェクトで使えそうなものを詳しく見ていこう。

1) 「よく使われているメトリクスに限定して検索」にチェックを入れて検索

①「よく使われているメトリクス」からの検索よく使われているメトリクスを見る基本測定量に絞るフェーズを絞る導出測定量を見るメトリクスの詳細を調べる

発注者



たくさん出てきた！これらのメトリクスはどんな測定量が基本になっているんだろう。何を測ればいいのか「基本測定量」にさらに限定して見てみよう。

「よく使われているメトリクスに限定して検索」条件での検索結果

2)「よく使われているメトリクスに限定して検索」と「基本測定量」にチェックを入れて検索

「基本測定量」に絞る




基本測定量が同じでも、測定フェーズが異なるものがある。今度は、自社でデータが測定しやすそうなテストフェーズに限定して見てみよう。

「よく使われているメトリクスに限定して検索」かつ「基本測定量」条件での検索結果

3)「よく使われているメトリクスに限定して検索」と「基本測定量」にチェックを入れ、「基本測定量測定フェーズ」で「テスト」を選択して検索

「テスト」フェーズに絞る




テストフェーズでの測定量としては、「欠陥数」や「テスト項目数」が自社で測定しやすそうだ。この測定量を含む導出測定量を見てみよう。

「よく使われているメトリクスに限定して検索」、「基本測定量」、基本測定量測定フェーズが「テスト」条件での検索結果

4)「よく使われているメトリクスに限定して検索」と「導出測定量」にチェックを入れ、「基本測定量測定フェーズ」で「テスト」を選択、「基本測定量」で「欠陥数」と「テスト項目数」を選択して検索

「欠陥数」「テスト項目数」を含む

導出測定量を見る




「欠陥数」と「実績規模」を測定して「欠陥密度」を導き出せるんだな。このメトリクスは自社で使えそうだ。参照されている書籍から詳細を見てみよう。

「よく使われているメトリクスに限定して検索」、「導出測定量」、基本測定量測定フェーズが「テスト」、基本測定量が「欠陥数」または「テスト項目数」条件での検索結果

5)「SEC BOOKSのリファレンス情報」列に表示されている書籍（この例では「定量的品質予測のススメ」）を参考にする。 http://sec.ipa.go.jp/publish/index.html#teiryo, http://sec.ipa.go.jp/publish/index.html#teiryo2


検索結果の「メトリクスの名称」を

クリックして、元の表にジャンプ



1. はじめに




5. おわりに



メトリクス一覧表（メトリクス分類表から該当メトリクスの該当項目を抜粋

入力レベル＝初心組織規模＝小

他メトリクス

文献・論文事例への参照情報

メトリクスリポジトリ

リファレンス文献・論文事例

参照

メトリクス分類表や他メトリクスなどメトリクス関連情報を格納

レベルや組織規模を入力すると

どのようなメトリクスをどう使えば

よいかが参照できる。

こんなメトリクスを

こう使う

①はじめに

大切



Mission

Vision

Goal ・役に立つメトリクスの事例・考え方などの提供・各レベルで使用する適切なメトリクスの提供（SEC）・適切なメトリクス使用のための選択手段の提供（SEC) ・効果的な提供を行うためのメトリクス基盤整備（SEC)

・ITに関するメトリクスを使用しての経営リスクの解消・定量データに基づく管理手法による効率的なマネジメント

・経営レベルからプロジェクトレベルまで、各レベルの適切な管理方法の実施・適切なメトリクス使用による効率的なマネジメントの実施・発注者、受注者相互の円滑なコミュニケーションの確立

定量的管理基盤活動の考え方



②基本的考え方

目的：プロジェクト目標が未達成にならない事を目的として、ユーザー・ベンダー双方が協調する枠組みや考え方を提供する手段： ①ユーザー企業とベンダー企業の品質保証やプロジェクト管理のエキスパートに集まっていただき、実際に現場で生じている問題をあげてもらい、リスクとして捉え、リスクの発現を予防する仕組みについて検討する ②プレストン・G・スミス、ガイ・M・メリット（澤田美樹子訳）『実践・リスクマネジメント』生産性出版（2003）のリスクモデルに当てはめて整理する結果： ①ユーザーとベンダーが協調してリスクの発現を予防する枠組みを構築し、現場適用の道筋（基本的考え方、その活用方法）を示せた ②検討結果の知見からテンプレートを作成し、テンプレートを用いて委員の事例を纏めた

本テンプレートで自分の状況を整理するとリスクの発現を予防する枠組みにあった形で纏める事ができる上、検討メンバの事例を合わせて提供することによって整理するヒントも得ることができる。枠組みとはリスクとそのリスク発現の要因を中心にすえ、リスクの発現を防ぐために”リスク発現の要因”に対してどのような予防策を打つかその予防策の効果をどのようにとらえるかと”リスク発現の要因”に対してその兆しをどう把握するかの関係を明確にしたものである。



リスク事象影響総損失量

リスク事象のドライバー

影響のドライバー

リスク事象の発生確率

影響の発生確率

• リスク事象：損失を引き起こす出来事（または状態）

• 影響：リスク事象が発生した結果として、生じる可能性のある潜在的な損失

• 総損失量：リスク事象が発生した場合に生じる損失の大きさ。日数または金額で表現。

• リスク事象のドライバー：プロジェクト環境の中に存在し、リスク事象の発生を導くもの。

• 影響のドライバー：影響の発生につながる、プロジェクト環境中に存在しているもの。

• 予防計画：リスク事象の発生確率を減らす目的で行う行動計画。リスク事象のドライバーに取り組むために立案される。

• 不測事態対応計画：リスクが発生した後に行う行動計画。影響のドライバーに取り組むために立案される。コンティンジェンシー計画のこと。

標準リスクモデル

プレストン・G・スミス、ガイ・M・メリット（澤田美樹子訳）『実践・リスクマネジメント』生産性出版（2003）

予防計画不測事態対応計画

参考にしたリスクモデル

このモデルは「リスク事象」と「影響」を分け、因果関係を明確にし、それぞれを引き起こす要因（ドライバー）を識別することで、「リスク事象」に結びつかない課題などが混入しにくくなるという利点を持つ。



影響（プロジェクト目標

達成の阻害）リスク事象

リスク事象ドライバー

総損失量

影響のドライバー

リスク事象ドライバーの予防策

影響のドライバーの予防策

ｰ回避：ドライバーを生み出さないようにする予防策ｰ軽減：ドライバーを無効化し、リスク事象の発生確率を減少させる予防策

メトリクス

-- ①リスク事象ドライバーの有無を把握-- ②予防策の有効性を確認

①

②

• リスク事象：損失を引き起こす出来事 • 影響：リスク事象が発生した結果として、生じる可能性のある潜在的な損失 • リスク事象ドライバー：プロジェクト環境の中に存在し、リスク事象の発生を導くもの。

• リスク事象ドライバーの予防策：リスク事象の発生確率を減らす目的で行う行動計画。リスク事象ドライバーに取り組むために立案される。対応区分としては回避・軽減。

• メトリクス：リスク事象ドライバの予防策の有効性を確認したり、リスク事象ドライバの有無を把握する。定量的/定性的

今回はスコープ外

• 影響のドライバ：：影響の発生につながる、プロジェクト環境中に存在しているもの

• 影響のドライバの予防策（対応策）：リスクが発生したあとに行う行動計画。影響のドライバーに取り組むために立案される。コンテンジェンシー計画のこと

• 総損失量：リスク事象が発生した場合に生じる損出の大きさ

追加部分

検討したリスクモデル



リスクモデルの事例（案）

2013/2/26

リスク事象リスク事象ドライバ

リスク事象ドライバの予防策

【対応区分】：回避：軽減

予防策の有効性を確認する

メトリクス

リスク事象ドライバの有無を把握

部門間力関係のアンバランス

プロジェクトの進行阻害（仮）

【回避】フェーズ毎に制約事項・スコープ・納期調整のイベントを設置する制約事項・スコープ・調整イベント数/プロジェクト全期間【軽減】プロジェクト外の目的やその優先順位を可視化する目的・優先順位記載数

・プロジェクトと連携する営業上の目的や利益がある - ある/ない・異なる役割を持つステイクホルダ間で指導・統括関係がある -関係数/ステイクホルダー数などなど



テンプレート



適用プロセス（案）

リスクの描出対応の検討評価・維持

対応がフィットしない場合、テンプレートの見直し・再確認を行う

対策の効果が確認できない場合、対応の選択を見直す

対策の効果が確認できない場合、対応策の実施方法やメトリクスの見直しを行う

•テンプレートの作成 •記載内容の確認 •プロジェクト実態との整合性確保

• プロジェクト内リスク事象ドライバーの把握・特定 • ステイクホルダー間でのリスクの共有 • 対応の選択

•メトリクス等を用いた対応の有効性評価 • 評価結果に基づくメトリクス等の見直し • リスク事象予防モデルへのフィードバック



③成果物

成果物の構成（案）名称

ITプロジェクトリスクへのリスク予防の実践的アプローチ（仮）～ユーザー／ベンダーの協調によるリスクへの対処

概要 ITプロジェクトの開発時にユーザーとベンダーの対立を予防する為の考え方をまとめた

目的プロジェクト目標が未達成にならない事を目的として、ユーザー・ベンダー双方が協調する枠組みや考え方を提供する。

対象者ユーザー：情シ部門、IT企画、PL ベンダー：PMO、PL、設計者

目次（案）初めに（本書の説明、構成）第１部（解説編）１．ITプロジェクトのリスクへの対処２．“リスク事象”の予防モデル３．リスク事象予防モデルの使い方

第２部（資料編）１．適用例の前提条件２．個別リスク事象ドライバ説明書

付録あとがき

3月27日公開予定



1. はじめに




5. おわりに



高信頼性、短納期など難易度が高くなったソフトウェア開発にとって定量データによるソフトウェア開発管理（見える化アプローチ）は有益である。

定量的ソフトウェア開発管理を実施するには、下記が必要である。

ＳＥＣでは定量関連の活動成果をHPで提供しております。

是非、ご活用ください。

次工程に進めるための最終的判断には、定性情報などと合わせて、多面的にみる必要がある

数値に意味を持たせるためデータの定義、ルールなど準備が必要

５．おわりに

経験 → 見える化、共有化

過去データの蓄積から見積もり精度向上、日々のデータによる品質コントロール等



（参考）関連URL 見える化

ITプロジェクトの見える化～総集編、～上流工程編、～中流工程編、下流工程編

http://sec.ipa.go.jp/publish/index.html#ent

定量的品質予測定量的品質予測のススメ、続定量的品質予測のススメ

http://sec.ipa.go.jp/publish/index.html#ent

ソフトウェア開発データ白書２０１０－２０１１ http://sec.ipa.go.jp/publish/tn10-002.html

データ白書の見方と定量データ活用ポイント http://sec.ipa.go.jp/reports/20110331_2.html

スタンドアロン型プロジェクト診断支援ツール http://sec.ipa.go.jp/tool/pasa.html

定量データに基づくプロジェクト診断支援ツール http://sec.ipa.go.jp/tool/pasa.html

定量的プロジェクト管理ツール http://sec.ipa.go.jp/reports/20111114_2.html

利用目的別メトリクス一覧表 http://sec.ipa.go.jp/reports/20120302_2.html

Documents

Information-technology Promotion Agency, Japan 定量的品質管 … · プロジェクト管理プロセスと品質保証（qa)プロセスのテーラリング プロジェクトのリスクを分類して「群」に割り振り、その群単位に順次評価しプロジェクト

Information-technology Promotion Agency, Japan 定量的品質管 … · プロジェクト管理プロセスと品質保証（qa)プロセスのテーラリングプロジェクトのリスクを分類して「群」に割り振り、その群単位に順次評価しプロジェクト