本日お話しすること

JaSST’09
JaSST
09 Shikoku



ソフトウェア品質の定義と変遷
そもそも測定すべき品質とは何かを今一度ふりかえります。

ソフトウェア品質の定義と変遷，
ソフトウ
ア品質の定義と変遷，その測定の考え方



ソフトウェア品質の測定とその留意点
実際の測定にあたって、その概要と留意点をお話しします。

 目次【第１部】 ソフトウェア品質の定義と変遷【第２部】 ソフトウェア品質の測定とその留意点

２００９－６－２５２００９
６ ２５NARAコンサルティング
奈良 隆正

2

1

背景ーSQuBOKガイドから
SQuBOKガイドから

ソフトウェア品質の基本概念とマネジメント

ソフトウェアの位置付けの変化（出展：SQuBOKガイド）

ＩＴシステムは今や社会インフラの一部
ＩＴシステムは今や社会インフラの部
ソフトウェアはすべての産業のコアテクノロジ


ソフトウェア品質を起因とする事故の発生

品質の概念
品質の定義（先人の洞察）
ソフトウェア品質モデル（歴史、標準化）
更にシステムとしての品質へ

ソフトウェア品質に起因するトラブルが後を立たない
ソフトウ アの位置付けの変化に伴い、経済活動 の影響が拡大
ソフトウェアの位置付けの変化に伴い、経済活動への影響が拡大

ディペンダビリティ、セキュリティ、ユーザビリティ、セーフティ日本のソフトウェア品質向上への取り組み不十分


ソフトウェア品質向上への取り組みは、各社に依存
ソフトウェア品質向上の技術（方法論）は、未整理
先人の知識や経験は 暗黙値のまま
先人の知識や経験は、暗黙値のまま
ソフトウェア品質向上技術は将来最も重要な技術

品質のマネジメント
質
品質のよい製品・サービスを提供するために組織を指揮し、管理すること
品質コントロ ル 品質保証 改善 測定 評価
品質コントロール、品質保証、改善、測定・評価
ソフトウェアの品質マネジメントの特徴
Ｖ＆Ｖ (Verification & Validation)、検査

3

4

®

SQuBOK に垣間見る日本的品質管理の特徴（１／２）

®

SQuBOK に垣間見る日本的品質管理の特徴（２／２）

「品質」



仕事の質，サービスの質，情報の質，工程の質，部門の質，人の質，システムの質，
会社の質など，これら全てを含めた「質」
「品質保証」

より上流で“悪さ”の知識を子細に活用し障害を排除していく※ただ単にきちんと作る、という意味ではない
「次工程はお客様」



「人間性尊重」「組織活性化」「小集団活動」
人間性尊重」 組織活性化」 小集団活動」「5ゲン主義」

「全員参加「全員参加」

お客様に安心して使って頂けるような製品を提供するための全ての活動

他の工程を助けるような改善を進め，全体最適へと向かっていく※プロダクトとプロセスが、特定された要求に合致しているかどうかという観点の十分な確信を提供する活動ではない「改善」
不十分でもとにかく動き出して全員が今より高いところを目指してプロセスそのものを改善しながら進める※欧米流の,プロセスを定義してその通りに実行していることを確認することではない

「品質の作り込み」「品質第一」
品質を高めることによって手戻りや作業のムダを省き，継続的な納期の短縮やコストダウンにつなげていく※納期を厳守するために必要な作業を省くのではない

現場・現物・現実 ＋ 原理・原則
品質管理はスタッフだけではなく、現場も経営陣も一丸となって進めなければならない
関係者全員が納得してベクトルをあわせ 目標達成のために取り組む
関係者全員が納得してベクトルをあわせ，目標達成のために取り組む
現場中心のため隅々まで改善が行き届くとともに，全員が自ら考えて行動する組織を構築できる

5

6

ソフトウェア品質知識体系ガイドとは？
品質知識体系
®

SQuBOK ガイド【第１部】

Guide to the Software Qu
Quality Body of Knowledge

ソフトウェア品質の定義と変遷

日本発のＢＯＫ！

測定の話に入る前に、そもそも測定すべき品質とは何でしょうか？
ソフトウェアの品質、品質保証について、これまでに経験した知識が、どのように定義 表現されてきたのかを振り返りますように定義、表現されてきたのかを振り返ります。

SQuBOK策定部会 編
2007年11月 オ
オーム社より出版
ム社より出版
3500円®

cf. PMBOK ガイド : プロジ
プロジェクトマネジメント知識体系ガイド
クトマネジメント知識体系ガイド（A Guide to the Project Management Body of Knowledge）

SWEBOK®

: ソフトウェアエンジニアリング基礎知識体系（Guide to the Software Engineering Body of Knowledge）

7＃注【KA(n)やS-KA（n.n.n）の表示が有るスライドはSQuBOKガイドからの引用です】

8品質の定義の変遷（1/3）

品質の定義の変遷（2/3）

1. JIS（JIS）Ｚ８１０１ 品質管理用語）およびＩＳＯ８４０２では、品質を以下のように定義している。
質を以下のように定義している

『品質は「要求に対する適合」である 』『品質は「要求に対する適合」である。』
●JISの品質の定義：『品物又はサ ビスが 使用目的を満たしているかどうかを決定するた『品物又はサ－ビスが、使用目的を満たしているかどうかを決定するための評価の対象となる固有の性質・性能の全体。』

クロスビ－（Ｐ．Ｃｒｏｓｂｙ）の定義：
ワインバ－グ（G.M.Weinberg）の定義：『品質は誰かにとっての価値である。』
品質は誰かにとっての価値である。』●ISOの品質の定義：『製品またはサ－ビスが明示または暗黙のニ－ズを満たす能力として有している特徴および特性の全体。』

ソフトウェア工学の専門家による定義

品質保証という観点からの品質
品質にはユ－ザにとっての「価値」である。



近代的品質管理における品質
品質は、ユ－ザにとっての「満足度」である。
「品質とは、ユ－ザの要求（ニ－ズ、使用目的）を満足させるために製品（含むサ ビス）のもつべき特性である 」
品（含むサ－ビス）のもつべき特性である。」「満足度（ＣＳ：カスタマ－、サティスファクション）」は、アメリカのマルコム・ボル
トリッジ国家品質賞のスロ－ガンであり、日本に逆輸入された

9

品質の定義の変遷（3/3）


10

品質の概念 KA(1.1)
品質の概念ーKA(1.1)

英国ＰＲＡＸＩＳ社（ソフト企業）のマ－チン・ト－マスのコメントジェ－ムス・マ－チンの定義システムが本稼動する時、どこまで真のビジネス（ユーザ）ニ－ズに合っているかということ。


開発期間が長年にわたるソフトウェア開発を意識した考え方、完成時にはユ－ザニ－ズ自体が変化しているとの認識⇒ＲＡＤの必要性

11（１）利害関係者の視点による定義（Garvin)
超越した視点：品質が何かを認識はできるが定義は困難である
超越した視点
品質が何かを認識はできるが定義は困難である
ユーザの視点：品質が目的に適合しているか
製造者の視点：品質が仕様に準拠しているか
製品の視点 品質が固有の製品特性に結び付いているか
製品の視点：品質が固有の製品特性に結び付いているか
価値に基づいた視点：品質は顧客が対価として支払う額に依存する『カスタマ 、サティスファクション（顧客満足度）は、我々のゴ『カスタマ－
サティスファクション（顧客満足度）は 我々のゴ－ルである
ルである、
しかしカスタマー（顧客）の視点は毎月でも変わりうる。』

（２）満足感と物理的充足度合いによる定義（狩野)当たり前品質要素：
それが充足されれば当たり前と受け取られるが 不十分であれば不満をそれが充足されれば当たり前と受け取られるが、不十分であれば不満を引き起こす品質要素
一元的品質要素：
それが充足されれば満足 不十分であれば不満を引き起こす品質要素
それが充足されれば満足、不十分であれば不満を引き起こす品質要素
魅力的品質要素：
それが充足されれば満足を与えるが、不十分であってもしかたがないと受け取られる品質要素
12

狩野モデル

魅力的品質

顧客の満足感満足

それが充足されていれば満足を与えるが、不充足であってもしかたがな と受けとられる品質要素
しかたがないと受けとられる品質要素。

気に入る

顧客の声（Positive
顧客の声（
Positive ）
魅力的品質

不充足

充足
一元的品質

当たり前

一元的品質

物理的充足状況

仕方ない

それが充足されれば満足、不充足であれば不満を引き起こす
それが充足されれば満足不充足であれば不満を引き起こす
品質要素。

当り前品質

当り前品質

気に入らない顧客の声（Negative
顧客の声（
Negative ）それが充足されれば当り前と受けとられるが、不充足であれ
ば不満を引き起こす品質要素。

不満足
出展：ＭＯＴテキスト製作委員会
13

品質の概念ー KA(1.1)
品質の概念

ソフトウ ア品質の考え方（広義と狭義）
ソフトウェア品質の考え方（広義と狭義）

そのほか、色々な人の色々な定義

●Joseph M
M.Juran;Juran; 二つの視点

14

プロダクトの特性（Feature)が顧客のニーズに応えることで満足を提供する
不備：deficiencies（障害や誤り）から免れる

ソフトウエアを中心とするシステム開発において品質を考える際は、狭義と広義の両面から考える必要が有る。狭義には、「ソフトウエア仕様書に記述（定義）された機能が実現されている事の確認」であり、広義には「ユーザ要求への適合度、すなわちシス
テム完成度の確認」である。
品●Roger S.Pressman；ソフトウェアの品質を記述するのは困難といいつつ


機能および性能に関する明示的な要求事項、明確に文書化された開発標準、および職業的 開発が行われた全てのソフトウ ア 期待される暗黙の特性
および職業的に開発が行われた全てのソフトウェアに期待される暗黙の特性に対する適合

各製品が備えるべき一式の品質特性のことであり、プロジェクトの種類に応じて異なった優先度がつくべきもの●石川馨 「狭義の品質 と「広義の品質●石川馨；「狭義の品質」と「広義の品質」⇒Qualityを「質」と捕らえる
Q lit を「質 と捕らえる
狭義の品質；製品の品質⇒欧米流の考え
 広義の品質；仕事、サ
広義の品質；仕事、サービス、情報、工程、部門、人、システム、会社の全てを、情報、 程、部門、人、シ テ 、会社の全てを
含めた質


満足度

ユーザ
適合

●Robert L.Glass;品質は製品によって変わり全てに共通の品質の定義は
ない

製品規格
適

ユーザ
ザ
（市場･特定顧客)の
要求

適合
設計品質
外部仕様

15

質＝ユーザの満足度
ザ製 品
適合合（広義の品質）

ソフトウェアの仕様書適合（狭義の品質）
適合（狭義
品質）
プログラム
プログラム品質
内部仕様
16

品質の概念ー KA(1.1)
品質の概念

品質の概念ー KA(1.1)
品質の概念




ソフトウェア品質を議論する場合の要点

ISO,IECなどにおける品質の定義
ISO9000：2005
本来備わっている特性の集まりが、要求事項を満たす程度
ISO/IEC 25000：2005
指定された特定の条件で利用する場合の、明示的又は暗示的なニーズを満たすソフトウェア製品の能力
ISO/IEC９１２６ １ ２００１ １４５９８－１：１９９８
ISO/IEC９１２６－１：２００１、
１４５９８ １ １９９８ある“もの”の明示された、または暗黙の必要性を満たす能力に関する特性の全体（ISO8042 1994用語の定義を使用）
特性の全体（ISO8042:1994用語の定義を使用）
IEEE Std 610-12:1900（１）システム、コンポーネント，またはプロセスが指定された要求を満たしている度合い（２）システム、コンポーネント，またはプロセスが顧客またはユーザのニーズ（必要性）または期待を満たしている度合い
ニズ（必要性）または期待を満たしている度合い「時間」についての概念「コスト」の概念
ト」の概念「必要な機能」が実現していること「使いやすい」こと「想定されている時間内」に機能を実行できること「実行時に故障を起こさない」こと「導入や学習」が容易なこと「導入後の維持や拡張」が容易なこと

17

品質保証の定義（私の経験①）

日本的な品質保証の定義（私の経験②）



消費者の要求する品質が十分に満たされている事を保証するために 生産者が行なう体系的活動
めに、生産者が行なう体系的活動。
（JISハンドブック 品質管理 1995）

ある“もの”が品質要求事項を満たすことについての十分な信頼感を供するために、品質システムの中で実施され、必要に応じて実証される、すべての計画的かつ体系的な活動。
（ISO8042品質―用語 1994）



18

品目又は製品が、定められた技術的な要求事項に適合することにより 十分な信頼を得るために必要な すべての計画的体系
により、十分な信頼を得るために必要な、すべての計画的体系的な活動の型。
（ANSI/IEEE729 ソフトウェア工学用語集 1994）19

品質保証は品質管理の真髄。消費者が安心して、満足して買うことができ それを使用して安心感 満足感をもち しかも長く使ことができ、それを使用して安心感、満足感をもち、しかも長く使用することができるという品質を保証すること。
（石川 馨 1981）



お客様に安心して使っていただけるような製品を提供するためのすべての活動。
（飯塚先生 2005）

品質保証活動とは、品質リスク（バグがあるかもしれない）を最小にする活動である バグが無いことを保証する活動ではないにする活動である。バグが無いことを保証する活動ではない。
（西 先生 ２００６）20

私なりの品質保証の定義（私の経験③）


品質保証の考え方（①）ー S
品質保証の考え方（①）
S-KA(1.2.2)
KA(1.2.2)

これらの定義を私なりに解釈すると．．．



1. ユーザ（消費者）が満足する製品またはサービスの品質を保証するための組織的 体系的活動証するための組織的、体系的活動。
2. 品質保証はアクティビティ（活動）でありワーク（作業）ではな
い。管理のPDCAが廻らないと上手く行かない。
3. ソフトウェア品質保証は；
全工程、全組織・全員参加、多岐に渡る活動「品質保証」；
用語の意味は国や地域によって必ずしも同 ではない
用語の意味は国や地域によって必ずしも同一ではない
ＩＳＯ９０００：２００５の定義；
品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マ
ネージメントの一部
 品質マネージメント：品質に関して組織を指揮し、管理するために調整された
品質マネ ジメント：品質に関して組織を指揮し 管理するために調整された活動。
⇒品質計画、品質管理、品質保証、品質改善から構成


品質保証の活動範囲は品質マネージメントのうち、品質計画、 品質管理、品質改善を除いた部分＜＜良くある誤解＞＞
 品質保証は品質保証部門の仕事であり、そこが頑張ってやるもの。
21

22

改善の考え方ー S-KA(1.2.4)

品質保証の考え方（②）ー S
品質保証の考え方（②）
S-KA(1.2.2)
KA(1.2.2)
「日本的品質保証」；お客様を満足させる活動の総称

「欧米的品質保証」；「改善」；ボトムアップ的かつ系統的現場活動
仕事の改善、プロセスの改善、製品品質改善がある
改善計画と目標を立て目標に向けた改善計画を実行
改善の成果がどう実現されたか評価し、再度計画を立て、これを繰り返す⇒ＰＤＣＡや改善（KAIZEN）の方法として確立された品質改善は現状の品質を把握（測定）し、ビジネス目標に合致する品質
目標が重要

お客様に安心して使っていただけるような製品を提供するための全ての活動
品質保証は品質管理の真髄
活動内容について「実証」することを必ずしも重要視していない
お客様が満足したという結果をもって品質保証活動の成果を測る


ＰＤＣＡ （Ｔ－１．２．３．１）計画（Plan→目標、目的）、実施（Do→計画に基き）、評価（Check→結果
計画（Plan→目標
目的） 実施（Do→計画に基き） 評価（Check→結果
調査）、改善（Action→評価結果に基き処置） プロセスを順に実施し、最後の改善を次の計画に結びつける

品質保証していることの「実証」重要視して発展品質保証していることの「実証重要視して発展（契約社会という文化的な背景がある）【目的】：全体のレベルアップを図る【効果】：目的を合理的、効果的に達成する 【留意点】：管理項目と目標値の決定、データ採取、データに基づく論理的判
断 作業標準の見直し 再発防止の処置などが重要
断、作業標準の見直し、再発防止の処置などが重要
●欧米の品質保証の解釈と日本の品質保証に対する解釈には大きな差がある●但し、顧客満足を目的とした活動と位置付ける点では同じである

23

24

ソフトウェアの特徴
ソフトウ
アの特徴


（ご参考）ソフトウ ア工学の問題（ご参考）ソフトウェア工学の問題

ソフトウェアの特徴

 ソフトウェアには；

項 番

特徴と問題点１＜論理の集合であること＞
・論理の正確な設計が困難
・論理の信頼性の高いテストが困難
・正確な開発規模の見積りが困難(1)構造設計とそれに基づくレビュー(2)システムマチックなテスト＜目に見えないこと＞
・品質管理が困難
・工程管理が困難(1)品質のビジ アル化(1)品質のビジュアル化(2)開発工程のビジュアル化＜個人への依存が高いこと ＞
・個人差が大きい・多人数の共同作業(1)開発手法の標準化と自動化(2)再利用技術(3)教育＜ユーザニーズと直結していること ＞
・ユーザニーズの正確な理解が困難
・使用条件の正確な把握が困難
・なかなか仕様が決まらない・システムは生き物である（成長する）(1)要求仕様分析手法(2)実使用条件でのテストによる検証

２

３

４

信頼性向上 の配慮
信頼性向上への配慮

複雑性がある ソフトウェア開発の難しさの元順応性がある 如何なる課題にも対応できる

不可視性である
 目に見えない

変更可能性がある
 仕様が決らなくても先に進める（ex. System Simulation Test）

25

ソフトウェアの品質マネジメントの特徴（１）ー SKA(1.2.4)
ソフトウェアの品質マネジメントの特徴（１）

ハードウェアの品質管理技法をそのまま適用することが難しい

26

ソフトウェアの品質マネジメントの特徴（２） ーS-KA(1.2.4)
S KA(1.2.4)


規模の増大が二つの問題を生む
それぞれの技術者が全体を把握できない

ソフトウェアが物理的実態を持たない



開発の見通しが悪くなることで障害を作り込みやすい

開発人数が増大しコミュニケーションの密度が低下する

ソフトウェアは設計の自由度が高く論理矛盾等障害を作り込みやすい

ティームワークの確保が難しい

ソフトウェアは測定すべき物理特性が殆ど存在しない

知的作業の質に悪影響を及ぼし、信頼性を低下させる

そもそも 何を測定すべきかについて統一した見解がない
そもそも、何を測定すべきかについて統一した見解がない

ソフトウェアの仕様は殆どが自然言語で記述される


曖昧性が高く矛盾を引き起こしやすい

設計の自由度を高めないようにする

ソフトウェア開発は人間の知的作業によって行われる


モチベーションが大きく作用し品質
モチベ
ションが大きく作用し品質、生産性に影響を与える
生産性に影響を与える

定石やデザインパターン等の活用

品質向上に寄与する指標の検討
仕様のレビューや管理の充実
開発の“悪さ”の知識を抽出し開発の
悪さ の知識を抽出し、体系化して蓄積体系化して蓄積

ソフトウェア開発はティーム開発である


ソフトウェアエンジニアリングの充実が必要
ソフトウ
ア ンジ アリングの充実が必要

ティームワーク、リーダシップ、コミュニケーションが重視されるティ
ムワ ク、リ ダシップ、コミュニケ ションが重視される
27

28

第２回プロジェクト実態調査【第２部】（出展：日経コンピュータ、２００８、１２月１日号）□

ソフトウェア品質の測定と，その留意点

定量的管理と成功率ーー 無し：２４．３％
無し：２４ ３％□

ソフトウェア品質の測定と結果の活用は高品質なソフトウェアの開発に必要不可
欠です。しかしながら、目的が明確ではない測定や、測定条件が異なる他の組織の基準値の安易な利用は、必ずしも高品質なソフトウェア開発にはつながっては
基準値 安易な利用は、必ずしも高品質な
ウ
開発 は ながはいきません。
第２部では、この“ソフトウェア測定”と“メトリックス”に焦点をあて、本来どのよう
第２部では、このソフトウェア測定 と メトリックス に焦点をあて、本来どのように測定し、活用すべきなのかを過去の経験とSQuBOKからお話しします。
＃注【ＫＡ（Ｎ）やＳ－ＫＡ（ＮＮＮ）で始まるスライドはＳＱuＢＯＫガイドからの引用
です】
29

はじめに


２００３）

□

遵守率（％）

（２００８

２００３）

成果物 １８．０
１８ ０ ８．７
８ ７

５１ ９ ４６．４
５１．９
４６ ４

コスト

１４．８

５．１

６３．２

７６．２

進捗

２９．９

１２．８

５４．６

５４．９

□

プロジェクト成功率：３１．１％（２６．７％、２００３）30

ソフトウ ア測定の考え方とメトリックス(1/2)
ソフトウェア測定の考え方とメトリックス(1/2)

製品開発における測定はコアコンピタンス



計測は品質管理、プロジェクト管理のみならず、あらゆる管理（制御）の基本である（私の経験）「測れないものは制御できない（トム．デマルコ）」

計測を確実にするために
メトリックスが必要

ソフトウェアメトリックスは代用特性である
メトリックスは必要性と目的に合わせて定義されなければ成らない
 メトリックスは常に見直しが不可欠である

計測結果は活用されなければ意味がない

計測の容易（可能）な尺度を選択
計測を容易にする仕掛けとツールの導入

計測実績データの蓄積
計測実績デタの蓄積．評価
評価

活用の基本はプロセスへのフィードバックである 活用されないデータは精度が劣化してゆく

計測条件（コンテキスト）の明確な実績データの収集．蓄積
計測条件が異なるデータ（絶対値）の比較は意味が無い 実績データの分析．評価
 評価基準の設定



最近散見される問題


計測を確実にするために計測が容易であること



定量的管理の実態（％）（２００８「物、事を計測し評価する能力」「物事を計測し評価する能力」
NASAが使う部品の信頼度はsix nine⇒計測できたことが凄い

有り：４５．６％

慣習によって意味を理解せず計測していないか？

31

32

ソフトウ ア測定の考え方とメトリックス(2/2)
ソフトウェア測定の考え方とメトリックス(2/2)


品質特性（信頼性品質指標）メトリックスの例

メトリックスは代用特性であり、常に整合性を評価することが重要 メトリックスは品質特性およびプロセスとの結びつきが明確
要。メトリックスは品質特性およびプロセスとの結びつきが明確であること（先人の経験）

品質特性

副特性

残存誤り密度
成熟性
無欠陥性



計測尺度
誤り密度

試験密度
エラー収束率
収束率

経験的、品質特性のメトリックス
試験実施率

信頼性メトリックスの例を次のスライドに掲示

ダウン発生率信頼性



経験的、プロセスのメトリックス

誤入力誤操作検出率
誤り許容性

プロセスメトリックスの例を次のスライドに掲示

平均故障発生間隔
稼働率
平均ダウン時間
可用性

平均エラー修正時間（注 1）

平均復旧時間定義[件]
誤り件数
成果物の量 [行]最終成果物に含まれた誤り件数 [件]
最終成果物の量
[行]
テストの量
[項目]
成果物の量
[行]
[個]
総摘出
総摘出エラー数
数
信頼度成長曲線の飽和点[個]（＝推定総エラー数）
実施されたテストの量 [項目]
予定されたテストの量 [項目]
ダウンに至った回数 [回]発生障害件数[件]
システムのチェック機能によって[回]検出された誤入力・誤操作の数[回]記録された誤入力・誤操作の数記録された誤入力
誤操作の数[時間]
システムの総稼働時間観測された故障発生件数[回]稼動状態にあった総時間数 [時間]
[時間]
観測時間数
稼動状態にあ た総時間数 [時間]稼動状態にあった総時間数観測されたダウンの回数[回]
エラーの修正に要した時間の総和 [人時]観測中に修正されたエラーの総件数 [件]
復旧に要した総時間 [時間]観測されたダウンの回数 [回]（注 1）平均エラー寿命ともいう。

33

34

プロセスメトリックスの例(1/3)
項番
1

工程
基本
設計

2

機能
設計

3

構造
設計
／
詳細
設計

1.
2
2.
3.
4.
5.
6.
1.
2.
3.
4.
5.
6.
7
7.
1.
2.
3.
4
4.
5.
6.
7.
8.

品質指標
ドキュメント不良件数
ドキュメント不良件数／頁
DR 指摘件数／頁
投入工数／頁
検完遅延日数
ドキ メ ト検査実施回数
ドキュメント検査実施回数
ドキュメント不良件数
ドキュメント不良件数／頁
DR 指摘件数／頁
投入工数／頁
検完遅延日数
変更指示件数ドキュメント検査実施回数
ドキュメント不良件数
ドキュメント不良件数／頁
DR 指摘件数／頁
投入工数／頁
検完遅延日数
テスト項目数／KS
変更指示件数ドキュメント検査実施

単位
件
件／頁
件／頁
人 H／頁
日
回
件
件／頁
件／頁
人 H／頁
日
件
回
件
件／頁
件／頁
人 H／頁
日
個／KS
件
回

管理レベル
プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プ グ ム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位ﾌﾟﾛｸﾞﾗﾑ、ﾓｼﾞｭｰﾙ単位
プログラム単位プログラム単位

プロセスメトリックスの例(2/3)
備考

項番
4
5

35

工程
コーデ
ィング
単体
テスト

1.
2
2.
1.
2.
3.
4.
5.
6.
7
7.

品質指標
投入工数／ステップ
フラグ数
不良摘出件数（累積）不良摘出件数／KS
テスト項目進捗度
不良摘出件数／投入工数
不良摘出件数／マシン時間
テストプログラム消化率
不良率（不良摘出件数／
テスト項目数）単位
人 H／ｽﾃｯﾌﾟ
個
件
件／KS
％
件／人 H
％
％
％

管理レベル
プログラム単位ﾌﾟﾛｸﾞﾗﾑ
ﾌﾛｸ ﾗﾑ、ﾓｼ
ﾓｼﾞｭｰﾙ単位
ﾙ単位
ﾌﾟﾛｸﾞﾗﾑ、ﾓｼﾞｭｰﾙ単位
モジュール単位モジュール単位モジュール単位モジュール単位モジュール単位モジ
モジュール単位
ル単位

備考

成長曲線

36

プロセスメトリックスの例(3/3)
項番

工程

6

プログ
ラムテ
スト

7

製品
検査

品質指標

単位

1. 不良摘出件数（累積）件
2 不良摘出件数／KS
2.
件／KS
3. テスト項目進捗度％
4. 不良摘出件数／投入工数件／人 H
5. 不良摘出件数／マシン時間％
6. テストプログラム消化率％
7. 設計総合耐久テストの故障率件／H
8. 探針での不良率％
9 探針での故障率
9.
件／H
10. 探針での推定残不良数件
11. 不 良 率 （ 不 良 摘 出 件 数 ／％テスト項目数）
1. 不合格件数件
2. 不合格件数／KS件／KS
3. 製品検査実施回数回
4 故障率（1/MTBF）
4.
件／H
5. MTBD
H／件
6. 不良率％7. 不良摘出件数（累積）
件

管理レベル

備考

ﾌﾟﾛｸﾞﾗﾑ、ﾓｼﾞｭｰﾙ単位
モジュール単位モジュール単位モジュール単位モジュール単位モジュール単位ｼｽﾃﾑ、ﾌﾟﾛｸﾞﾗﾑ単位
プログラム単位プログラム単位プログラム単位成長曲線

ｼｽﾃﾑ、ﾌﾟﾛｸﾞﾗﾑ単位
プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位プログラム単位

古典的な３大メトリックス（デバッグ効
率）

（設計発見
不良）

◆

開発規模

◆

開発工数

◆

バグ
バグ数

ー

未だに取り続けているが有効に活用されているか疑問

ー未だに取っていない組織がある、驚き！

ー

SEI(CMMIティーム）はコアメトリックスと呼んでいる～

新しいことのように言っている

～

37

38

ソフトウェア品質特性（ISO/IEC 9126シリーズ）①

品質特性の概要（１／２）

外部及び内部
品質

１．機能性（functionality)

機能性

信頼性

使用性

効率性

保守性

移植性

機能の集合の存在及びそれらの明示された性質の存在をもたらす属性の集合
機能は、明示的又は暗示的な必要性を満たすものとする

２．信頼性（reliability)
合目的性
正確性
相互運用
性
ｾｷｭﾘﾃｨ

成熟性
障害許容性
回復性

機能性標
準適合性

信頼性標準
適合性

理解性
習得性
運用性
魅力性

時間効率
性
資源効率
性

解析性
変更性
安定性
試験性

環境適応性
設置製
共存性
置換性

明示された条件の下で、明示された期間、ソフトウェアの達成のレベルを維持するソフトウェアの能力をもたらす属性の集合

３．使用性（usability)
ー

使用性標
準適合性

効率性標
準適合性

保守性標
準適合性

移植性標準
適合性

明示的又は暗示的な利用者の集合が、使用するために必要とする労力及び個々の使用結果による評価に影響する属性の集合

図1.1.1 外部及び内部品質のための品質モデル[出典：JIS X 0129-1:2003 ソフトウェア製品の品質 － 第1部：品質モデル，p. 9 図4]3940

品質特性の概要（２／２）

【参考】ソフトウェア品質特性（ISO/IEC 9126シリーズ）②４．効率性（efficiency)

利用時の品質明示的な条件の下で、ソフトウェアの達成のレベルと使用する資源の量との間の関係に影響する属性の集合

５．保守性（maintainability)

有効性

仕様化された改定を行うために必要な労力に影響する属性の集合

生産性

安全性

満足性

６．保守性（portability)py)
ソフトウェアのある環境から他の環境へ移す際の、そのソフトウェアの図 1.1.2

能力をもたらす属性の集合

利用時の品質のための品質モデル[出典：JIS X 0129-1:2003 ソフトウェア製品の品質－ 第1部：品質モデル，p. 13図5]

41

ソフトウェア品質特性(メトリックス例）-1/6

42

ソフトウェア品質特性(メトリックス例）-2/6
2/6

１．機能性（functionality)
ー 機能の集合の存在及びそれらの明示された性質の存在をもたらす属性の集合
機能は、明示的又は暗示的な必要性を満たすものとする

２ 信頼性（reliability)
２．信頼性（reliability)ー

明示された条件の下で、明示された期間、ソフトウェアの達成のレベルを維持するソフトウェアの能力をもたらす属性の集合○

合目的性；ユーザ改良件数、仕様の改定率○○ 正確性；ユーザから要求された数値精度の実現率、正確性；ユ ザから要求された数値精度の実現率○ 障害許容性；誤入力．誤操作検出力、単位障害あたりの説明書と実動作の合致度

ダウン回数○ 相互運用性；データ形式の合致度、インターフェースや相互運用性 デ タ形式の合致度 インタ
スや○プロトコルの合致度○

セキュリティ；暗号化率、アクセス履歴保有率○

機能性標準適合性；関連する全ての規格中、遵守している

成熟性；平均故障間隔（ＭＴＢＦ） 平均故障寿命（ＭＴＴＦ）
成熟性；平均故障間隔（ＭＴＢＦ）、平均故障寿命（ＭＴＴＦ）

回復性；平均修復時間（MTTR）、平均ダウンタイム（MDT）○ 信頼性標準適合性；関連する全ての規格中、遵守している
信頼性標準適合性 関連する全
規格中 遵守
る
項目の割合

項目の割合
43

44

ソフトウェア品質特性(メトリックス例）-3/6
3/6

ソフトウェア品質特性(メトリックス例）-4/6
4/6

３ 使用性（usability)
３．使用性（usability)

４ 効率性（ ffi i
４．効率性（efficiency))ーー

明示的又は暗示的な利用者の集合が、使用するために必要とする労力明示的な条件の下で、ソフトウェアの達成のレベルと使用する資源の量

及び個々の使用結果による評価に影響する属性の集合との間の関係に影響する属性の集合○ 理解性；デモが用意されている機能の数○ 時間効率性；処理速度（CPU実行時間、入出力処理時間など）、
時間効率性；処理速度（CPU実行時間 入出力処理時間など）○

習得性；マニュアル装備率、学習機能装備率○

運用性；メッセ ジ的確度 キ タッチ数 レスポンス時間
運用性；メッセージ的確度、キータッチ数、レスポンス時間○

魅力性；利用者にとって魅力的である機能の数処理能力（トランザクション処理件数など）○

資源効率性 資源使用量（CPU使用量 メ リ使用量など）
資源効率性；資源使用量（CPU使用量、メモリ使用量など）、
資源使用率（単位時間当たりの、CPU利用率、○ 信頼性標準適合性；関連する全ての規格中、遵守している
信頼性標準適合性 関連する全
規格中 遵守る

メモリ利用率など）

項目の割合

○

効率性標準適合性；関連する全ての規格中、遵守している
項目の割合

45

46

ソフトウェア品質特性(メトリックス例）-5/6
5/6

ソフトウェア品質特性(メトリックス例）-6/6
6/6

５ 保守性（maintainability)
５．保守性（maintainability)

６ 保守性（portability)
６．保守性（portability)ーー

仕様化された改定を行うために必要な労力に影響する属性の集合

ソフトウェアのある環境から他の環境へ移す際の、そのソフトウェアの能力をもたらす属性の集合○

解析性；誤り箇所識別率、診断機能の装備率○

変更性；ＫＬＯＣあたりの修正実施時間
変更性；ＫＬＯＣあたりの修正実施時間、○

環境適応性；適用可能機種／ＯＳ数、変更せずに使用できる
デ タの割合データの割合○障害１件あたりの修正実施時間

設置性；ソースコードの変更率、移行ツールの適用できる割合○ 安定性；モジュールの結合度
安定性
ジ
の結合度

○ 共存性；共通資源を他のソフトウェアと共存できる割合
共存性 共通資源を他のトウ アと共存できる割合○

試験性；KLPCあたりのテスト時間、障害１件あたりのテスト時間○○

保守性標準適合性；関連する全ての規格中、遵守している

置換性；置換前のソフトウェアと比べて、実現できる機能や
性能の割合

○

項目の割合

保守性標準適合性；関連する全ての規格中、遵守している
項目の割合

47

48

【参考】 メトリックス定義の代表的な技法

GQMモデル例*

 GQMパラダイム「ソフトウェアの修正依頼処理」の「適時性（処理にかかる時間の妥当性）」を「プロジェクトマ
プネージャ」の立場から「改善」する

Goal
Question

Basili教授らによって提案された総合的なソフト
ウェア計測の枠組み“計測はトップダウンに行われるべきである”
 まず計測目標があって，その目標を遂行するた
まず計測目標があ て，その目標を遂行するために尺度（メトリクス）が定義され，計測されるべき“データ分析は何らかの目的や仮説に基づいて行
われるべきである”
 例）コスト予測，コスト改善，品質改善例）
善質 善 etc.

ソフトウェアの修正依頼処理にかかる時間は？

平均処理時間処理時間は改善されたか？

処理時間の標準偏差

処理時間が上限を超える場合の割合は？

マネージャの満足度の主観的評価値

平均的な処理時間／
標準的な平均処理時間

Metric*井上克郎, 松本健一, 飯田元 著 「ソフトウェアプロセス」 共立出版，2000.
49

50

GQMモデル(1)GQMモデル(2)構成管理データ（CVS）と障害管理データ（GNATS）のデータから
フ イル変更パタ ンを解析し 企業における特定のプロジ クト
ファイル変更パターンを解析し，企業における特定のプロジェクトにおいて，プロジェクトマネージャの視点から，不安定な要求・不完全な設計・劣悪なソースコード品質について評価する

Goal

Question ファイル変更レベル（FCM）は？

ファイルの変更者数は（ONR）？

変更行数は（LCC）？

重要度の高いバグの修正数の曲線は？

ファイル毎の変更者
数（ＣＶＳ）

ファイル毎の変更行
数（CVS）

バグに関するGNATSデータを分析することによって，企業バグに関するGNATSデタを分析することによって 企業における特定のプロジェクトにおいて，プロジェクトマネー
ジャの視点から，プロダクトの品質を評価する

Question

変更理由は？

ファイル毎の変
更回数（CVS）
MetricGoal

変更動機：バグ＝B，機能変更＝CR（ＧＮＡＴＳ）

重要度毎のバグの修正数（GNATS)
Metric

優先度が高いバグが未解決となっている時間の平均は？

優先順位毎のバグの修正数（ＧＮＡＴＳ）

優先順位毎のバグの修正完了日（ＧＮＡＴＳ）

優先順位毎のバグの登録日（ＧＮＡＴＳ）
出展：ＥＡＳＥプロジェクト

出展：ＥＡＳＥプロジェクト
51

52



メトリックス ＫＡ(3.1)
メトリックス－ＫＡ(3.1)

ソフトウェア測定の考え方－
ソフトウ
ア測定の考え方 S
S-KA(1.2.5)
KA(1.2.5)“もの”の測定可能な特徴を属性と呼び、属性を測定する方法と尺度を合わせた概念の集合が トリック
尺度を合わせた概念の集合がメトリックス



２種類のメトリックス

目的、方法（操作の場合）、尺度、活用のプロセスを明らかにする
測定目的とメトリックスを結びつけることが重要（例；GQM）
属人性を排した形で測定方法を定義することが重要
名義尺度 順序尺度 間隔尺度 比率尺度のどれを用いるか定義
名義尺度、順序尺度、間隔尺度、比率尺度のどれを用いるか定義

プロダクトメトリックス；製品の属性を測定する


ソフトウェア品質メトリックス、規模メトリックスなど

プロセスメトリックス；プロセスの属性を測定する

ソフトウェアの測定はISO/IEC 15939:2002で定義
メトリックスには基本メトリックスと導出メトリックスがある(JIS X 0141では基本測定量と導出測定量）
測定にあたり；

開発プロセスの個々の作業や手順全体に関するメトリックス
作業に影響を与える人や組織といった開発基盤に関するメトリックス



メトリックスを用いる目的；
製品やプロセスの品質を定量的に把握．評価し、継続的に改善すること
製品やプロセスの品質を定量的に把握評価し 継続的に改善すること
製品とプロセスの両方に焦点を当てて、改善することが重要
どの様なメトリックスを用いるかは、何を目的にどの様な目標を設定するかで決定

測定プロセスの共通的な枠組み（ISO/IEC 15939:2002）；
測定に対するコミットメントの確立および保持測定プロセスの計画
測定プロセスの遂行
測定の評価● 測定プロセスとは、測定の目的や方法、尺度の定義、選択、適用を改善するために必要な手順

53

測定理論 ～用語の定義（１）～
用語の定義（１）

S-ＫＡ(3.1.1)
S
ＫＡ(3.1.1)

 測定尺度；54

測定理論 ～用語の定義（2）～
用語の定義（2）S-ＫＡ(3.1.1)
S
ＫＡ(3.1.1)
 評価基準；測定可能な特徴を示す属性を計量するもの

プロセス、製品、プロジェクト、または資源の価値や品質を評価するときのプロセス、製品、プロジ
クト、または資源の価値や品質を評価するときの基準

 一定の尺度で物事を測定することにより、客観的な評価や判断を可能とする

 品質特性または品質副特性の評定水準に基づいて、ソフトウェア製品品質の総合評価が客観的に行えるようにする

 品質メトリックス；
ソフトウ アの品質特性 副特性を定量的に計測するもの
ソフトウェアの品質特性、副特性を定量的に計測するもの

 測定プロセス；

 ソフトウェア製品の品質特性、副特性を定義し、測定、評価を可能とする

メトリックスを実際に計測するプロセス

 測定値；

 開発済みのソフトウェアメトリックスを計測し、当該ソフトウェア自体の評価、他ソフト開発済みのソフトウ アメトリックスを計測し 当該ソフトウ ア自体の評価 他ソフト
ウェアとの比較、今後の保守のスケジュール、投入人月の見積りに使用する。
 開発中のソフトウェアメトリックスを計測し、開発プロセスを動的に制御しながら、ソフト
発発飛 」
ウェアを計画どおりに効率よく開発する「ソフトウェア開発の計器飛行」を可能にする

属性に割り当てられた「値」（直接測定値と間接測定値）
 測定可能な特徴を値で示し、測定対象の実体や状況を具体的に把握する

 指標；
予測や見積り、評価等の情報ニーズに基づいて示す数値または変数
 予測や見積りの際の目安や補助、組織やプロジェクトの達成度合いの評価基準に用いる 評定水準；測定尺度を分類するために使われる順序尺度上の点
 ソフトウェア種別や利用者の要求等を考慮して、評価目的ごとの品質要求水準を明確にする
55

 評価プロセス；
ソフトウェアメトリックスを使用して計測した結果を評価する
 ソフトウェア製品の品質評価を計画的に実施して、客観的、効率的な評価がソフトウ ア製品の品質評価を計画的に実施して 客観的 効率的な評価が行えるようにする● 参考規格；ISO/IEC15939:2002、9126
参考規格；ISO/IEC15939:2002、9126-1:2001、9126-2:2003、
1:2001、9126 2:2003、
TR9126-4:2004、14598-1:1998、2382-14:1997、
IEEE std610.12-1990、IEC60050-191:1990
56

ＩＳＯ/ＩＥＣ9126 品質評価プロセスモデル

測定理論 ～留意事項(1)～
留意事項(1)
S-ＫＡ(3.1.1)
S
ＫＡ(3.1.1)

明示的または暗示的必要性 測定尺度；管理上の要求X0129およびその他技術情報

独自に定義した測定尺度を用いる場合には、其の定義や測定手順等を独自に定義した測定尺度を用いる場合には其の定義や測定手順等を明らにし、測定尺度を共有する関係者間で十分な認識合わせを行う必要
が有る

要求定義

品質要求仕様

品質要求定義ソフトウェア

測定法

評定水準

総合評価

選択

設定

基準設定

 品質メトリックス；

準備製品または中
間製品

開発

測定値
測

定
評

定

設定された
水準
総合評価

評価
結果（受入れ可否）

出典）東基衛（他編） 『ソフトウェア品質評価ガイドブック』 日本規格協会 1994年。
出典）東基衛（他編）：『ソフトウェア品質評価ガイドブック』、日本規格協会、
年（（１）分解された品質の副特性を単一の値で表現することは難しく、複数の測定値）分解さ
品質 副特性 単
値 表現すと 難しく 複数 測定値
から総合的に評価する必要がある（２）複数の測定値に重みづけして、単一の代表値を算出すると、計測した値の本
来の意味が失われる危険性がある（３）品質の副特性と測定値の相関関係や精度をトレースする必要が有る（４）品質の副特性 の分解には、いくつかの方法があり、したがって、計測値も、（４）品質の副特性への分解には、いくつかの方法があり、したがって、計測値も、一意には定まらない（５)測定を負担のかかり過ぎない計測方法を採用すべきである（６）例えば ユーザビリティのように 定量的な測定が困難な品質特性もある そ（６）例えば、ユーザビリティのように、定量的な測定が困難な品質特性もある。その場合は、主観的評価や、聞き取り調査等の方法も考慮する

57

58

測定理論 ～留意事項（2）～
留意事項（2）
S-ＫＡ(3.1.1)
S
ＫＡ(3.1.1)

測定理論 ～留意事項（3）～留意事項（3）
S-ＫＡ(3.1.1)
S
ＫＡ(3.1.1)

 測定値；

 評価基準；測定値（デ タ）と使用した測定尺度や属性は常にセットで示し、“データ測定値（データ）と使用した測定尺度や属性は常にセットで示し
デ タの一人歩き”を避ける配慮が必要である

 指標；

評価基準の確立と運営には 組織的な評価技術の管理が不可欠である
評価基準の確立と運営には、組織的な評価技術の管理が不可欠である

 測定プロセス；

指標と一緒に、その確信度や重要性等を定量的に示し、分析、評価の手助けとする

 評定水準；評定水準

どの時点で、どの要素を、どのように計測するかを予め明確にする

 評価プロセス；
プ

品質は与えられた必要性によって決定されるものであるため、評定水準
は品質の評価目的に応じて設定する必要がある

メトリックスによる測定は場当たり的に実施するのではなく、組織やプロ
ジェクトごとに明確に定義されたプロセスの中へ組み入れて実施すべきである（補足）測定プロセスはISO/IEC 15939に基づいてソフトウェア一般の測定、評価プロセスを、評価プロセスはISO/IEC 14598-1に基づいてソフトウェア製
品品質の測定、評価プロセスを解説している

59

60

まとめ① 品質の定義と品質保証


まとめ② ソフトウ
ソフトウェア測定
ア測定

１．品質の定義と解釈① 品質は長い間、「要求に対する適合」とされてきたが、近年は「ユ品質は長い間 「要求に対する適合」とされてきたが 近年は「ユーザにザにとっての価値」、「ユーザに取っての満足度」、「真のビジネスニーズに合っている度合い」などが主流である。
② 日本は,仕事、サービス、情報、工程、部門、人、システム、会社の全てを
日本は 仕事 サ ビス 情報
程 部門 人 シス ム 会社 全てを含めた質を表す傾向がある。

２．品質保証ーこの用語の解釈は、国や地域で異なる。
① 日本的品質保証；お客様に安心感を与え、お客様を満足させるための全ての活動の総評であり、必ずしも活動内容を実証することを重要視していない。
② 欧米的品質保証；品質保証活動をしていることの実証を重要視している。
欧米的品質保証；品質保証活動をしていることの実証を重要視している
此れは契約社会という文化的な背景が影響している。

 ソフトウェア測定
ソフトウ ア測定①計測は品質管理、プロジェクト管理のみならず、あらゆる管理（制御）基本である。
ゆる管理（制御）基本である②計測を確実にするためには、計測が容易であること、
計測実績デ タの蓄積 評価が重要である
計測実績データの蓄積、評価が重要である。
③測定にあたり、目的、方法、尺度、活用のプロセスを明らかにすることが重要である。
明らかにすることが重要である

計測事象＝因果関係＋バイアス＋偶発性（出（出展；長崎大中村先生ーJASPIC講演より）
長崎大中村先生
S C講演より）

61

62

終わりに

まとめ③ ソフトウェアメトリックス（１）ただ何となく慣習に従って計測してませんか メトリックス①メトリックスは、属性を測定する「方法と尺度」を合わ①メトリックスは属性を測定する「方法と尺度 を合わせた概念の集合と考えられる。
②メトリックスを用いる目的は 製品やプロセスの品質②メトリックスを用いる目的は、製品やプロセスの品質を定量的に把握・評価し、「継続的に改善をする」こ
とである。
とである
③メトリックスによる評価は、単一ではなく複数を用いて総合的に行うことが望ましい。
て総合的に行うことが望ましい④測定値は測定条件（コンテキスト）が異なると意味が変わってくる。
変わってくる
測定値は方法、尺度、属性をセットで示し”データの一人歩き”を避ける配慮が必要である。
人歩き を避ける配慮が必要である。

（２）何故このメトリックスが必要か考えたことは有りますか（３）計測結果はフィードバック（活用）されていますか⇒先ず、データを採取したプロジェクトとメンバーへ⇒そして、プロセスへの反映（４）数値目標をクリアすることが目的になってませんか（本来の施策が実施されていますか？）～メトリックスと測定を考え直してみよう～
メトリックスと測定を考え直してみよう～ご清聴有難う御座いました～63

64