横断的アプローチによる ソフトウェア開発データの分析 ～高信頼性定量化部会 信頼性メトリクス WG 検討報告書～ 2015 年 4 月 16 日 高信頼性定量化部会 信頼性メトリクス WG 独立行政法人情報処理推進機構（ＩＰＡ） 技術本部 ソフトウェア高信頼化センター（ＳＥＣ） 目次 はじめに ............................................................................................................................ 1 1. 2. 3. 4. 5. 背景と目的 ................................................................................................................. 4 1.1 背景 ................................................................................................................... 4 1.2 分析の目的 ......................................................................................................... 4 1.3 アプローチ－横断的分析アプローチ ....................................................................... 4 1.4 留意点 ................................................................................................................ 5 信頼性に影響するプロセス要因の分析 ........................................................................... 6 2.1 分析の狙い ......................................................................................................... 6 2.2 分析方法 ............................................................................................................ 6 2.3 分析結果 .......................................................................................................... 11 2.4 評価 ................................................................................................................. 15 システムリスクと開発工数の関係分析 ............................................................................ 17 3.1 分析の狙い ....................................................................................................... 17 3.2 分析方法 .......................................................................................................... 17 3.3 分析結果 .......................................................................................................... 19 3.4 評価 ................................................................................................................. 20 考察 ........................................................................................................................ 21 4.1 信頼性に影響するプロセス要因の分析について ..................................................... 21 4.2 システムリスクと開発工数の関係分析について ........................................................ 21 4.3 横断的分析アプローチについて ........................................................................... 22 おわりに ................................................................................................................... 23 参考文献......................................................................................................................... 23 付録 1 信頼性メトリクス WG 検討メンバ .............................................................................. 24 付録 2 信頼性メトリクス WG 開催日 ................................................................................... 25 付録 3 各社の管理指標調査結果の集計サマリ .................................................................... 26 付録 4 分析用集計ツールの入力用シート ........................................................................... 27 付録 5 分析用集計ツールの報告用シート ........................................................................... 28 別添資料 分析用集計ツール（Excel ファイル） ..................................................................... 28 i © IPA, Japan. 2015 All rights reserved はじめに 独立行政法人情報処理推進機構ソフトウェア高信頼化センター(以下、IPA/SEC という)では、ソフトウ ェア開発における定量的管理の普及促進を目的に、開発プロセスの標準化や見える化手法、定量的 品質管理手法などの調査・検討を行っている。 IPA/SEC のメトリクス分析に関する 2014 年度の活動の一つとして、高信頼性定量化部会の活動があ る。高信頼性定量化部会では、その配下にテーマごとのいくつかの作業グループ（WG）を設けた。その 一つが、「信頼性メトリクス WG」である。 本書は、信頼性メトリクス WG の 2014 年度の検討報告書である。 【目的】 信頼性メトリクス WG の 2014 年度の検討の目標は、次の二つの命題をデータで実証することで ある。これらは当たり前のようではあるが、データによって明確に実証されていないのが現状である。 これらの命題の実証を通じて、IT 利用企業と IT ベンダーにおける IT システム品質確保に必要な 認識の浸透を図り、IT 業界の健全な発展に貢献することを狙う。 ＜命題＞ 信頼性に影響する開発プロセス要因についての分析 ⇒命題①：「開発の早い段階から品質をコントロールすれば結果指標が良くなる」 システムリスクと開発工数の関係分析 ⇒命題②：「高度なＩＴシステム（システムリスクの高いソフトウェア）の開発には、それ相応の品質 保証（レビュー、テスト等）の工数が必要である。」 【分析アプローチ】 横断的分析アプローチ 分析方法を共通化した上で各委員の所属企業（以下、各組織という）が分析した結果を持ち 寄り、それらを横通しで分析して集約するアプローチ（以下、横断的分析アプローチという）を新 たに試行した。 ［理由］ より良い分析結果を得るためには、次のような条件が揃ったデータを用いることが望ましい。 ・メトリクスと計測手法 ・データ収集の対象領域（品質マネジメントの成熟度、業種ドメイン等） ・外れ値/異常値の除外 そこで、各組織の中においては、開発プロジェクトの背景や特性等の定性的な情報を踏ま えながらほぼ均質なデータを揃えられることに着目して、上記の命題を実証するために各組 織のデータ（以下、組織データという）をそれぞれの組織ごとに分析した上で集約するアプロ ーチを新規に試行することとした。 1 © IPA, Japan. 2015 All rights reserved 指標の選定 各組織共通の分析に用いる指標（及びデータ項目）については、各組織で用いられている管 理指標を、測定状況、有用性及び実証性の観点から調査した結果に基づいて選定した。 （「付録 3 各社の管理指標調査結果の集計サマリ」参照） 【検討の評価】 二つの命題をデータによって実証できた。 命題①：「開発の早い段階から品質をコントロールすれば結果指標が良くなる」 概ね、上流での不具合摘出比率は良群の方が高い傾向と、下流での（テスト時の） 不具合検出密度（不具合検出数／開発規模）は良群の方が低い傾向が見られた。 ＜新規開発の場合＞ ◇下流での（テスト時の）不具合検出数／開発規模は、良群の方がやや低い。 ◇不具合検出数／テスト項目数は、良群の方がやや低い。 ◇総欠陥数／開発規模は、良群の方がやや低い。 ＜改良開発の場合＞ ◇レビュー指摘数／開発規模は、良群の方がやや高い。 ◇上流工程での欠陥摘出比率は、良群の方が高い。 ◇下流での（テスト時の）不具合検出数／開発規模は、良群の方が低い。 ◇不具合検出数／テスト項目数は、良群の方が低い。 命題②：「高度なＩＴシステム（システムリスクの高いソフトウェア）の開発には、それ相応の 品質保証（レビュー、テスト等）の工数が必要である。」 開発規模の影響を吟味する必要性があるものの、開発規模当たりの総開発工数と総テスト 工数については、システムリスクが高い場合の方が工数の平均値が大きくなる傾向が確認 できた。一方、総テスト項目数については、システムリスクが高い場合と低い場合で平均値 に差があるとは言えないことが確認できた。 ◇仮説 H1「規模当たりの総開発工数（総開発工数／開発規模）は多くなる」については、 仮説を部分的に支持するという結果が得られた。 ◇仮説 H2「規模当たりの総テスト工数（総テスト工数／開発規模）は多くなる」につい ては、仮説を概ね支持するという結果が得られた。 ◇仮説 H3「規模当たりの総テスト項目数（総テスト項目数／開発規模）は多くなる」 に ついては、仮説を支持するという結果は得られなかった。 2 © IPA, Japan. 2015 All rights reserved 分析アプローチとして、横断的分析アプローチの有効性を確認できた。 【今後の検討課題】 横断的分析アプローチの有効性が確認できたので、より精緻な分析や、信頼性変動要因間の 相関分析、工期短縮の限界の分析などの新たな分析に引き続き取り組んで行きたい。 3 © IPA, Japan. 2015 All rights reserved 1. 背景と目的 1.1 背景 品質のよい IT システムを開発することは IT ベンダーの責務である。その責務を果たすのに必要な組 織能力を、IT ベンダーは獲得し、維持し、継続的に向上させていく必要がある。特に重要インフラ分野 などの高度ＩＴシステムにおいては、要求された機能性をソフトウェアとして正しく実現することはもちろん、 高い信頼性水準を満たすといった基本的な品質要求の確実な実現が求められる。このような基本的な 品質要求を満たすために必要な組織能力の向上を目指した取り組みが IT ベンダーには求められる。 「品質を追求すれば生産性は後からついてくる」というように、コスト削減とプロジェクト管理の鍵は、品 質不良に起因する手戻り作業の削減であり、開発プロセスの早い段階から品質を作り込むことである。 そのためには、レビュー、テスト、第三者検証などの品質評価及び品質保証検討に一定の品質保証の 工数を投入する必要がある。しかし、低価格と短納期への強いプレッシャーのために、そうした検討に十 分な品質保証の工数と期間を確保できず、納期優先でＩＴシステムを稼動させざるを得ないことが多々 ある。 このような状況は、IT ベンダーにおける組織能力の向上を目指した取り組みの阻害要因となり、結果 として IT システムの品質低下につながる。そして、IT システムの品質低下は、ＩＴシステムの利用企業だ けでなく、それらの最終利用者である国民にとって不利益となる。 IT システムの品質を確保し、安心・安全な IT 社会を実現するためには、まず、IT ベンダーが①「開発 プロセスの早い段階から品質をコントロールすれば結果指標が良くなる」ことを認識する必要がある。ま た、ＩＴ利用企業においては、②「高度なＩＴシステムの開発にはそれ相応の品質保証（レビュー、テスト 等）の工数が必要である」ことを認識する必要がある。そして、こうした共通認識が得られた上で、ＩＴシス テム開発案件の価格と納期の適正化が図られることが、高度ＩＴシステムの品質向上にとって不可欠で ある。 1.2 分析の目的 本 WG におけるデータ分析の目的は、1.1 節で述べた①と②の二つの命題、すなわち ① 開発プロセスの早い段階から品質をコントロールすれば結果指標が良くなる ② 高度なＩＴシステムの開発にはそれ相応の品質保証の工数が必要である の正しさを実証することである。これらの命題の実証を通じて、IT 利用企業と IT ベンダーにおける IT シ ステム品質確保に必要な認識の浸透を図り、IT 業界の健全な発展に貢献することが狙いである。 1.3 アプローチ－横断的分析アプローチ より良い分析結果を得るためには、メトリクスと計測手法、データ収集の対象領域、外れ値/異常値の 4 © IPA, Japan. 2015 All rights reserved 除外等の条件が揃ったデータを用いることが望ましい。そこで、各組織の中においては、開発プロジェ クトの背景や特性等の定性的な情報を踏まえながらほぼ均質なデータを揃えられることに着目して、上 記の命題を実証するために次のような横断的分析アプローチを新規に試行することとした。 「WG 委員の所属組織において蓄積されたソフトウェア開発プロジェクトデータに対して共通の分析方 法を適用し、それぞれの組織で得られた分析結果を集約する。その際、規模、不具合、テスト項目など の測定方法の定義は各組織に委ね、それぞれの組織で運用している基準に則って測定する。また、各 組織における分析結果が妥当なサンプルに基づいたものになるよう、プロジェクトの実施時期や業種な どを考慮して分析対象とするデータを選定し、外れ値とみなせるプロジェクトは除外するなど、データ分 析に必要な手続きを実施する。」 1.4 留意点 横断的分析アプローチの採用により、分析結果を解釈する上で留意すべき事項がある。以下、主な 留意点を述べる。 不具合として測定している対象及びその測定方法は組織によって異なる。例えば、現象を不具合とし て測定しているのか、原因を不具合として測定しているのかは、組織によって異なる。また、レビューで 摘出した不具合と、テストで検出した不具合について、それらの重みを考慮しているか否かなどは、組 織によって異なる。 同様に、テスト対象としている範囲も異なる。例えば、改良開発において新規に開発したソフトウェア に対するテスト項目を測定としているのか、流用元のソフトウェアの修正後に実施したリグレッションテス トのテスト項目を測定対象に含めているか否かなど、組織によって異なる。 加えて、2 章の「信頼性に影響するプロセス要因の分析」における良群否群、すなわち品質について 成功したプロジェクトと失敗したプロジェクトの分類基準も、組織によって異なる。例えば、リリース後に検 出された不具合密度の大小で良群否群を分けていたり、その他の情報も含めた社内基準を達成したか 否かで分けていたりなど、組織によって異なる。 5 © IPA, Japan. 2015 All rights reserved 2. 信頼性に影響するプロセス要因の分析 2.1 分析の狙い 「開発の早い段階から品質をコントロールすれば結果指標が良くなる」という命題①を、データに基 づいて実証し、「ソフトウェアの信頼性向上」を促進する。 2.2 分析方法 以下の手順でデータ収集及び分析を実施した。 (1) 管理指標の選定 まず、開発プロセスに関する管理指標として一般的な、次表の 12 個について、各組織での測定 状況、有用性及び実証性を調査した。 管理指標の候補一覧表 分類 上流工程 管理指標 レビュー指摘数／レビュー工数 レビュー指摘数／成果物規模 レビュー工数／成果物規模 レビュー工数／開発工数 上流工程での欠陥摘出比率 下流工程 成果物規模／レビュー時間 開発工数／成果物規模 レビュー工程別の欠陥除去比率 不具合検出数／テスト工数 不具合検出数／成果物規模 テスト工数／成果物規模 テスト項目数／成果物規模 意味 レビュー工数当たりの欠陥摘出数 成果物規模当たりの欠陥検出数 成果物規模当たりのレビュー工数 開発工数に対するレビュー工数の比率 上流での欠陥混入数（の予測値）に対する，レビューでの 欠陥摘出数の合計 レビュー時間当たりの成果物規模 成果物規模当たりの開発工数 指摘＋見逃し欠陥数に対する，見逃し欠陥数の比率 テスト工数当たりの不具合検出数 成果物規模当たりの不具合検出数 成果物規模当たりのテスト工数 成果物規模当たりのテスト項目数 目的の例 レビューの十分性，効率性を評価 レビューの十分性，有効性を評価 レビュー工数の十分性を評価 レビュー工数の十分性を評価 レビューの有効性を評価 レビューの効率性，適切性を評価 開発作業への投入工数の十分性，生産性を評価 レビューの有効性を評価 テストの十分性、効率性を評価 テストの十分性を評価 テストの十分性を評価 テスト項目の十分性を評価 （注 1）成果物規模としては、開発規模を採用することとした。 （注 2）／は÷を意味する。 これら 12 個の管理指標は、次の文献などを参考に挙げた。 ライルド，L. M., ブレナン, M. C.（2009）『演習で学ぶソフトウェアメトリクスの基礎』（野中誠・鷲崎弘 宜訳）日経 BP 社. 誉田直美（2010）『ソフトウェア品質会計』日科技連出版社 野中誠・小池利和・小室睦（2012）『データ指向のソフトウェア品質マネジメント』日科技連出版社 情報処理推進機構ソフトウェアエンジニアリングセンター (編集)（2008）『定量的品質予測のススメ ～IT システム開発における品質予測の実践的アプローチ～（SEC BOOKS）』オーム社. 調査結果については、「付録 3 各社の管理指標調査結果の集計サマリ」参照。 次に、この調査結果に基づいて、より効果的な管理指標と判断できる次の 5 個の管理指標に絞 って分析に用いることとした。 ① レビュー指摘数／開発規模 6 © IPA, Japan. 2015 All rights reserved ② レビュー工数／開発規模 ③ 上流工程での欠陥摘出比率 ④ 不具合検出数／開発規模 （テスト検出不具合密度に相当） ⑤ テスト項目数／開発規模 （テスト密度に相当） 【補足】「より効果的な管理指標」の目安 測定状況、有用性及び実証性のすべてにおいて、◎の評価があること ・測定状況◎：測定方法が標準化されており，ほとんどのプロジェクトで測定している。 ・有用性◎ ：重点的な管理指標として利用しており，プロジェクトのコントロールに役立っ ている。 ・実証性◎ ：実証データで分析した経験があり，有効な関連性が見出されている。 なお、不具合検出数／テスト工数も上記の条件を満たしているが、不具合検出数／成果物規 模とほぼ同じ目的の指標なので、不具合検出数／成果物規模に絞ることにした。 さらに、分析を進めて行く中で必要と判断した次の管理指標を追加した。 ⑥ 不具合検出数／テスト項目数 （テストのヒット率または感度に相当） テストの効率性が高いか、テスト対象の成果物に潜在している不具合の密度が高い場合に 高くなると考えられる。 ⑦ テスト工数／開発規模 ⑧ 総欠陥数／開発規模 (2) データ収集 各組織にて、上記①～⑧の指標を導出するための次のデータを含むプロジェクトデータを収集 した。 ＜収集データ＞ 開発規模（KSLOC） レビュー指摘数（件） レビュー工数（人時） 上流での欠陥摘出比率（%） 収集できない場合は、レビュー指摘数／（レビュー指摘数＋テストでの不具合検出数）で 導出する。 不具合検出数（件） 結合テスト以降のテスト工程で検出した不具合の件数（単体テスト及び稼働後は除く）。 テスト項目数（項目数） 結合テスト以降のテスト工程におけるテスト項目数（単体テストは除く）。 7 © IPA, Japan. 2015 All rights reserved テスト工数（人時） 結合テスト以降のテスト工程におけるテスト工数（単体テスは除く）。 総欠陥数（件） 作りこまれた欠陥の総数は分からないので、擬似的にレビュー指摘数＋テストでの不具合 検出数で導出した。 また、データ収集にあたっては、次のことに留意した。 ＜データ収集の留意事項＞ データ件数について できるだけ多数のプロジェクトデータを収集する。 良群と否群のプロジェクト数が、少なくともそれぞれ 10 件以上となるようデータ収集する。 上記のデータのすべての項目が揃っていなくても構わない（データ欠損）があっても可と する。 データ収集の対象領域について 品質マネジメントの成熟度が一定レベル以上の組織から、そのマネジメント対象となって いるプロジェクトのデータを収集する。具体的には、目標と実績の評価や設計プロセスの 遵守状況の評価など、プロジェクトの途中で品質監査を実施したプロジェクトを対象にす る。 ドメインについて 異なるドメインのプロジェクトデータが混在していてドメイン間で傾向が異なる場合、ドメイ ンに分けて分析するのが望ましい。ドメインの偏りがないようにデータ収集するか、ドメイン に分けてデータ収集する。 除外対象について 次のような、外れ値/異常値と判断できるプロジェクトデータは対象外とする。 ◇うまくコントロールできなかった（内部的な理由によって異常な結果になった）プロジェ クト （具体的な判断基準については、各組織に委ねる） ◇顧客都合で、大幅に計画超過したり、長期にわたって中断したプロジェクトなど ◇極端に小規模なプロジェクト ◇開発規模が 0 のデータ 収集データ項目について ◇規模は原則として KSLOC ◇レビュー指摘件数 基本的に不具合件数とする。 (3) 良群否群の分別 各プロジェクトを品質の結果指標によって次のように評価し、その良否の評価によって二群（良 8 © IPA, Japan. 2015 All rights reserved 群と否群）に振り分ける。 ＜良群と否群の振分け方＞ 結果指標は、品質（特に信頼性及び機能適合性）に関するものとする。 代表的にはサービスイン（カットオーバ）以降に見つかった不具合件数を用いた不具合 密度（不具合件数÷開発規模）であるが、具体的な結果指標は各組織に委ねる。日頃活 用しているものの中から選択する。 結果指標による良否の判定基準についても各組織に委ねる。次のどちらかを採用する。 ・判定基準 1：各組織において採用している判定基準によって、良群と否群とに振り分け る。ただし、その基準によって振り分けた良群と否群のプロジェクト数が極 端に偏っている場合には、他の結果指標を採用するか、判定基準 2 を採 用する。 ・判定基準 2：結果指標の中央値によって、良群と否群とに二分する。 【補足】良群、否群の定義と良否の判定基準について 良群、否群とは、各組織において品質（特に信頼性及び機能適合性）が相対的に良いも のの集合と良くないものの集合を意味する。基本的には、品質（特に信頼性及び機能適合 性）の代表的な結果指標である「サービスイン（カットオーバ）以降に見つかった不具合件数 を用いた不具合密度（不具合件数÷開発規模）」によって、良群、否群のデータ数がどちら かに偏り過ぎないように二群に大別することとした。具体的にはその結果指標の中央値で 二分するか、各組織において信頼性が良いと評価する水準値を用いて二分する。 ただし、このように良群、否群を分けられない組織については、具体的な結果指標及び 良否の判定基準をその組織に委ねることとした。 なお、データ数が多ければ、良い／普通／悪い の三群に分けて、良い群と悪い群を比 較する方法等が考えられる。ニ群に分けるより三群に分ける方が、より傾向が現れやすいと 考えられる。 (4) 各組織での分析 分析用集計ツールを用いて各組織内で分析した。 （「付録 4 分析用集計ツールの入力用シート」、「付録 5 分析用集計ツールの報告用シート」及び 「別添資料 分析用集計ツール（Excel ファイル）」を参照） ＜生データの入力＞ 新規開発の良群と否群、改良開発の良群と否群に振り分けた生データを、分析用集計ツール の対応する入力シートの入力領域（赤枠内）の該当するデータ項目列に値貼付けすると、自動 的に計算された基本統計量や検定結果が、分析用集計ツールの報告用シートに表示される。 9 © IPA, Japan. 2015 All rights reserved ＜分析用集計ツールの機能と表示内容について＞ 基本統計量の相対化 報告用シートには、生データに基づく基本統計量が相対値化されて表示される。 また、常用対数化したデータに基づく基本統計量についても同様に表示される。 （相対化しないと、各組織の分析結果を持ち寄るのが困難なため） ［備考］データの相対化方法について z 得点による標準化（すなわち、( x - 平均値) / 標準偏差）によって相対値化される。 ここでの平均値と標準偏差は、結果指標の良群、否群を含めた全体のもの。 z 得点することで、平均値より小さい値は負の値、平均値より大きい値は正の値になり、 0 を中心にバランスのとれた値になる。また、正規分布であれば±3 を超える確率は 0.003 など、直感的にも理解しやすくなる。 両側検定 P 値 良群、否群の平均値の差を、Welch の t 検定に沿って検定した結果のうち、両側検定 P 値が報告用シートに表示される。 Welch の t 検定では、二群の母集団が正規分布に従っていることを前提にしている。こ の P 値は帰無仮説（平均に差がないという仮説）が成立する確率を示すものなので、この 値が小さいほど対立仮説（平均に差があるという仮説）が成立する確率が高いということ になる。 データ分布の歪度 報告用シートの各指標の良群、否群のそれぞれに対して、データ分布の非対称性の 程度を示す「歪度」の値が表示される。歪度の絶対値が 2 以上であれば、非対称性が強 いと言える。また、歪度が正の値は右裾広がり、負の値は左裾広がりの分布であることを 示す。上記の Welch の t 検定は正規分布を前提にしていることから、歪度の絶対値が 2 以上の場合は、対数化データの方の検定結果を採用した方が良いと考えられる。 (5) 横通し分析 上述のように分析方法を共通化して各組織で分析した結果（分析用集計ツールの報告用シート） を持ち寄り、それらを横通しで分析した。具体的には、各組織の分析結果をサマリ表に整理・要約 した上で、共通的に見られる傾向を探した。 10 © IPA, Japan. 2015 All rights reserved 2.3 分析結果 各組織の分析結果を要約したものを、サマリ表 1～3 に示す。 各組織の分析結果を横通しで見て、共通的に見られる傾向を次の観点で探した。 ＜共通的に見られる傾向か否かの評価基準＞ C1：多数に（目安として 2/3 以上に）見られる傾向か否か ただし、データ数が 10 件未満の結果は除外して評価する。 C2：顕著に（10%有意な結果が過半数に）見られる傾向か否か この条件を満足しない場合は、「やや」と表現する。 共通的に見られる傾向を次に示す。 概ね、上流での不具合摘出比率は良群の方が高い傾向と、下流での（テスト時の）不具合 検出密度（不具合検出数／開発規模）は良群の方が低い傾向が見られた。 ＜新規開発の場合＞ 下流での（テスト時の）不具合検出数／開発規模は、良群の方がやや低い。 （C1:67%, C2:33%） 不具合検出数／テスト項目数は、良群の方がやや低い。 （C1:67%, C2:33%） 総欠陥数／開発規模は、良群の方がやや低い。 （C1:75%, C2:50%） ＜改良開発の場合＞ レビュー指摘数／開発規模は、良群の方がやや高い。 （C1:75%, C2:13%） 上流工程での欠陥摘出比率は、良群の方が高い。 （C1:88%, C2:63%） 下流での（テスト時の）不具合検出数／開発規模は、良群の方が低い。 （C1:100%, C2:78%） 不具合検出数／テスト項目数は、良群の方が低い。 （C1:89%, C2:67%） ［注］改良開発では顕著な傾向が見られたが、新規開発では顕著な傾向が見られなかった。 新規開発の分析結果については、提供組織が少なかったことやデータ件数が少なかったことが影 響していると考えられるが、追究できていない。 11 © IPA, Japan. 2015 All rights reserved 【サマリ表 1～3 における「傾向」の見方】 サマリ表 1～3 では、各指標が示す良群の傾向を次のように矢印で表示している。 矢印の色（または向き） 良群の平均値が否群の平均値より大きい場合には赤色（上向き矢印）、小さい場合には緑 色（上向き矢印）で表示している。 矢印の向き 良群、否群の平均値の差を Welch の t 検定を用いて検定した結果のうち、両側検定 P 値 によって、次のように表示している。 及び は、10%有意であり、良群、否群の平均値の差が顕著であることを示している。 ◇良群の方が指標値が大きい P<0.1 P<0.2 P<0.5 P>=0.5 ◇良群の方が指標値が小さい P<0.1 P<0.2 P<0.5 P>=0.5 ここで、Welch の t 検定にあたっては、対数化したデータを用いている。（Welch の t 検定は正 規分布を前提としているので、対数化することによって正規分布化できる。また、対数化すること によって外れ値の影響を受けにくくする。） ただし、良群、否群の歪度の絶対値がどちらも 2 未 満の場合には、対数化しないデータを用いている。 12 © IPA, Japan. 2015 All rights reserved サマリ表 1：品質に関する分析結果サマリ（新規開発） ◇良群の方が指標値が大きい P<0.1 P<0.2 P<0.5 P>=0.5 ◇良群の方が指標値が小さい P<0.1 P<0.2 P<0.5 P>=0.5 組織 C社 新規開発 D社 新規開発 F社 新規開発 G社 新規開発 H社 新規開発 I社 新規開発 J社 新規開発 開発 規模 ①（上流） ﾚﾋﾞｭｰ指摘 数／規模 傾向 ②（上流） ﾚﾋﾞｭｰ工数 ／規模 ③上流工程 での欠陥 摘出比率 ④（下流） 不具合検出 数／規模 ⑤（下流） テスト項目 数／規模 ⑥（下流） 不具合検出 数／テスト 項目数 評価不能 ⑦（下流） テスト工数 ／規模 ⑧総欠陥 数／規模 評価不能 良群件数 164 164 8 164 164 164 149 21 164 否群件数 30 30 0 30 30 30 29 1 30 良群件数 12 12 12 12 12 12 12 12 12 否群件数 12 12 12 12 12 12 12 12 12 傾向 傾向 評価不能 良群件数 23 15 15 15 21 21 22 0 14 否群件数 42 22 22 22 30 30 30 0 22 評価不能 評価不能 評価不能 傾向 評価不能 良群件数 48 0 1 0 48 29 29 48 0 否群件数 49 3 3 3 49 25 25 49 3 良群件数 29 29 29 29 29 29 29 29 29 否群件数 42 42 42 42 42 42 42 42 42 傾向 傾向 評価不能 良群件数 30 30 0 7 30 30 21 30 30 否群件数 7 7 0 7 7 7 7 7 7 良群件数 120 5 4 5 86 87 83 43 5 否群件数 60 4 2 4 52 51 50 24 4 傾向 13 © IPA, Japan. 2015 All rights reserved サマリ表 2：品質に関する分析結果サマリ（改良開発 1/2） ◇良群の方が指標値が大きい P<0.1 P<0.2 P<0.5 P>=0.5 ◇良群の方が指標値が小さい P<0.1 P<0.2 P<0.5 P>=0.5 組織 A社 改良開発 B社 改良開発 （外れ値 除外） B社 改良開発 （異常値 除外） C社 改良開発 D社 改良開発 E社 改良開発 F社 改良開発 G社 改良開発 開発 規模 ①（上流） ﾚﾋﾞｭｰ指摘 数／規模 ②（上流） ﾚﾋﾞｭｰ工数 ／規模 ③上流工程 での欠陥 摘出比率 ④（下流） 不具合検出 数／規模 ⑤（下流） テスト項目 数／規模 ⑥（下流） 不具合検出 数／テスト 項目数 ⑦（下流） テスト工数 ／規模 ⑧総欠陥 数／規模 傾向 良群件数 19 19 19 19 19 19 19 19 19 否群件数 22 22 22 22 22 22 22 22 22 良群件数 221 224 198 233 229 222 225 217 221 否群件数 67 66 42 71 73 66 68 66 68 良群件数 241 240 219 233 240 239 241 238 240 否群件数 69 73 45 71 73 72 73 72 73 良群件数 320 320 40 320 320 320 309 69 320 否群件数 58 58 3 58 58 58 57 4 58 良群件数 15 15 15 15 15 15 15 15 15 否群件数 15 15 15 15 15 15 15 15 15 良群件数 32 32 32 32 32 32 32 32 32 否群件数 11 11 11 11 11 11 11 11 11 傾向 傾向 傾向 傾向 傾向 傾向 評価不能 良群件数 33 24 24 26 30 30 35 0 24 否群件数 36 26 27 25 31 31 33 0 24 良群件数 23 3 4 3 23 15 15 22 3 否群件数 24 2 3 2 24 16 16 23 2 傾向 14 © IPA, Japan. 2015 All rights reserved サマリ表 3：品質に関する分析結果（改良開発 2/2） 品質に関する分析結果サマリ （改良開発2/2） 組織 開発 規模 ①（上流） ﾚﾋﾞｭｰ指摘 数／規模 ②（上流） ﾚﾋﾞｭｰ工数 ／規模 ③上流工程 での欠陥 摘出比率 ④（下流） 不具合検出 数／規模 ⑤（下流） テスト項目 数／規模 ⑥（下流） 不具合検出 数／テスト 項目数 ⑦（下流） テスト工数 ／規模 ⑧総欠陥数 ／規模 傾向 H社 改良開発 良群件数 73 73 73 73 73 73 73 73 73 否群件数 68 68 68 68 68 68 68 68 68 傾向 I社 改良開発 評価不能 良群件数 26 26 0 16 26 26 24 26 26 否群件数 9 9 0 9 9 9 9 9 9 良群件数 494 31 40 27 343 364 337 241 27 否群件数 214 15 18 15 180 169 163 124 15 傾向 J社 改良開発 2.4 評価 当分析の評価として、以下の点が挙げられる。 (1) 命題の実証 良群の方が、上流での欠陥摘出比率が高い傾向と、下流での不具合検出密度（不具合検出数 ／開発規模）が低い傾向が見られたことから、「開発の早い段階から品質をコントロールすれば結 果指標が良くなる」という命題を、概ね支持する分析結果が得られたと言える。 このことから、次のことをお勧めする。 「上流での欠陥摘出比率を高めるなど、開発の早い段階から品質をコントロールすることによ って品質向上を図る。」 【補足】命題を概ね支持する分析結果が得られたが、命題とは異なる分析結果となった組織が少 数ではあるが存在している。その理由について確からしいことは分かっていない。組織の成 熟度が関係しているとか、開発規模の大小に強く影響を受けているとか、種々の要因が考 えられる。確からしい要因を探るべく、プロジェクトの実態調査や定性的な分析を進めること が今後の検討課題である。 15 © IPA, Japan. 2015 All rights reserved (2) 分析アプローチの有効性の確認 分析方法を共通化した上で各組織が分析した結果を持ち寄り、それらを横通しで分析するアプ ローチ（横断的分析アプローチ）を採用した。 上記(1)の命題の実証を通じて、横断的分析アプローチの有効性を確認できた。 ＜横断的分析アプローチの特長＞ データ提供企業間で開発プロセス、メトリクス、計測手法等が必ずしも揃っていない問題を避 けることができるので、より鮮明に傾向を読み取れると期待できる。 また、組織ごとに分析するステップを踏むことによって、組織間の入力値のばらつきの影響を 軽減する効果も期待できる。 各組織の生データは機密データであり収集困難であるが、各組織で分析した結果（相対化し た統計情報）なら持ち寄ることができる。 分析用集計ツールを共通に使用することによって、効率的で正確な分析を実現できる。 16 © IPA, Japan. 2015 All rights reserved 3. システムリスクと開発工数の関係分析 3.1 分析の狙い 次の仮説の検証を通じて、「高度なＩＴシステム（システムリスクの高いソフトウェア）の開発には、 それ相応の品質保証（レビュー、テスト等）の工数が必要である」という命題②をデータに基づいて 実証し、「ＩＴシステム価格の適正化」を促進する。 【システムリスクの高いソフトウェアの開発プロジェクトに対して検証する仮説】 H1： 規模当たりの総開発工数（総開発工数／開発規模）は多くなる。 H2： 規模当たりの総テスト工数（総テスト工数／開発規模）は多くなる。 H3： 規模当たりの総テスト項目数（総テスト項目数／開発規模）は多くなる。 3.2 分析方法 2 章での分析と同様、各組織が保有する生データを集めて分析することは容易でないことなどか ら、次の手順を経て各組織で分析した結果を集めた上で、横断的分析アプローチによる横通し分 析を実施した。このように、各組織にデータ収集・分析作業の一部を担ってもらうことで、情報を収 集しやすい状況を作った。 具体的には、以下の手順でデータ収集及び分析を実施した。 (1) 新規開発と改良開発のそれぞれについて、システムリスクの高低で分けたデータセットを各組 織で用意する。 ＜システムリスクの高低の振り分け方＞ 各プロジェクトについて次のようにシステムリスクを評価し、システムリスクの高群と低群とに 振分ける。 各プロジェクトのシステムリスクについては、信頼性、公共性、社会性ごとに次のように高／ 低を評価した上で、それらの評価結果を総合して評価する。具体的には、信頼性、公共性、 社会性のうち二つ以上の評価が高の場合、システムリスクが高と総合評価する。 信頼性 数分以内での回復が要求される 評価 高 回復が数分を超えても許容される 低 17 © IPA, Japan. 2015 All rights reserved 公共性 公共性が高く，社会・経済活動に密着し，機能の停止・低下が社会的に混 乱を及ぼすシステム（監督官庁への報告を要する場合がある） あるいは、 個人情報を扱うシステム 上記以外のシステム 社会性 トラブル時にマスコミ報道の対象になる可 能性がある 評価 高 低 評価 高 低 トラブル時にマスコミ報道の対象にならない 【補足】システムリスクについて ◇システムリスクはプロジェクトの外的要因に関するものであり、各プロジェクトの内的要 因に依存しないものである。一方、プロジェクトリスクは各プロジェクトの内的要因に依 存する、各プロジェクトにとってのリスクである。 システムリスク、プロジェクトリスクのど ちらを採用して分析するのが良いか議論した結果、ＩＴ利用企業へメッセージを発信す る上でより重要なのはシステムリスクであることから、今回はシステムリスクを採用するこ ととし、プロジェクトリスクに関する分析については今後必要に応じて検討する課題とし た。 ◇システムリスクをできるだけ適切かつ容易に評価する基準について議論した結果、上 記のように信頼性、公共性及び社会性の観点から総合評価するのが良いとの結論に 至った。 (2) 各組織においてデータを吟味し、外れ値を除外する。 (3) システムリスクの高低のそれぞれについて、開発規模、 H1、H2、及び H3 に示した値の件数、 平均値、五数要約、標準偏差をそれぞれ求める。また、システムリスクの高低を合わせた全体 の平均値と標準偏差を求める。 (4) システムリスクの高低のそれぞれについて求めたこれらの値を、高低を含めた全体の平均値と 標準偏差を用いて計算した z 得点に変換する。変換後は、全体の平均値を 0、全体の標準偏 差を 1 として標準化した値が得られる。 (5) システムリスクの高低について、二群の平均値の差の検定の一手法である Welch の t 検定を行 い、両側検定による P 値を求める。 (6) その際、分布が右に歪んでいることが想定されるので、対数化したデータを用いて分析する。 (7) 件数、標準化した平均値及び五数要約、検定結果の P 値という情報のみを IPA/SEC に提出す る。 18 © IPA, Japan. 2015 All rights reserved 3.3 分析結果 各組織の分析結果を要約したものを「分析結果の要約表」に示す。「傾向」の見方については、2 章 の場合と同様である。 各組織の分析結果を横通しで見て、共通的に見られる傾向を次に示す。 開発規模の影響を吟味する必要性があるものの、開発規模当たりの総開発工数と総テスト工数 については、システムリスクが高い場合の方が工数の平均値が大きくなる傾向が確認できた。 一方、総テスト項目数については、システムリスクが高い場合と低い場合で平均値に差があると は言えないことが確認できた。 【システムリスクの高いソフトウェアの開発プロジェクトに対して検証する仮説と検証結果】 H1 ○規模当たりの総開発工数（総開発工数／開発規模）は多くなる。 規模当たりの総開発工数 (H1) については、仮説を部分的に支持するという結果が得られた。 H2 ○規模当たりの総テスト工数（総テスト工数／開発規模）は多くなる。 規模当たりの総テスト工数 (H2) については、仮説を概ね支持するという結果が得られた。 H3 ×規模当たりの総テスト項目数（総テスト項目数／開発規模）は多くなる。 規模当たりの総テスト項目数 (H3) については、仮説を支持するという結果は得られなかった。 分析結果の要約表：システムリスクの高低と、対数化指標の関係分析 H1 組織 開発 種別 データ件数 (リスク高 - 低) Ａ社 新規 4 – 15 改良 8–5 新規 8 – 13 改良 15 – 8 新規 B社 C社 開発規模 H2 H3 総開発工数／ 開発規模 総テスト工数／ 総テスト項目数／ 開発規模 開発規模 10 – 10 非対数化 非対数化 新規 10 – 50 P値不明 P値不明 改良 25 – 150 P値不明 P値不明 改良1 77 – 13 改良2 26 - 64 改良 D社 E社 P値不明 ◇システムリスク高の方が指標値が大きい P<0.1 P<0.2 P<0.5 P>=0.5 ◇システムリスク高の方が指標値が小さい P<0.1 P<0.2 P<0.5 P>=0.5 H1とH2は複数事例で傾向が確認されたが、H3は確認されなかった 19 © IPA, Japan. 2015 All rights reserved 3.4 評価 (1) 命題の実証 規模当たりの総開発工数については、仮説 H1「システムリスクの高いソフトウェアでは、規模当た りの総開発工数（総開発工数／開発規模）は多くなる」を部分的に支持するという結果が得られ た。 規模当たりの総テスト工数については、仮説 H2「システムリスクの高いソフトウェアでは、規模当 たりの総テスト工数（総テスト工数／開発規模）は多くなる」を概ね支持するという結果が得られた。 これらのことから、「高度なＩＴシステム（システムリスクの高いソフトウェア）の開発には、それ相応 の品質保証の工数が必要である。」という命題をデータに基づいて概ね実証できたので、「ＩＴシス テム価格の適正化」を促進することができる。 (2) 分析アプローチの有効性の確認 分析方法を共通化した上で各組織が分析した結果を持ち寄り、それらを横通しで分析するアプ ローチ（横断的分析アプローチ）を採用した。 上記(1)の命題の実証を通じて、2 章と同様に横断的分析アプローチの有効性を確認できた。複 数組織のデータを手元に集めて横断的に統計解析を行うのは難しいものの、データ提供組織の協 力が得られれば、横断的な情報を比較的容易に集めることが期待できる方法であると言える。 20 © IPA, Japan. 2015 All rights reserved 4. 考察 4.1 信頼性に影響するプロセス要因の分析について (1) 要因間の依存関係の影響について 良群の方が上流での欠陥摘出比率が高い傾向が見られたことと、下流での不具合検出密度（不具 合検出数／開発規模）が少ない傾向が見られたことから、上流での欠陥摘出比率が高ければ下流で の不具合検出密度が低くなるという因果関係がありそうである。また、開発規模が他のデータ（及び指 標）に影響を与えているという懸念がある。一般に、データ（及び指標）間の依存関係が、分析結果に 影響している可能性がある。 データ（及び指標）間の依存関係（相関）を調査し因果関係を考察することによって、あるいは多変 量解析を行うことによって、より本質的で確からしい要因を追究することが今後の検討課題である。来 年度においては、この検討課題に取り組む所存である。 ［備考］ データ（及び指標）が独立ではなく、何らかの依存関係が想定される場合、多変量解析を行うこと によって、より本質的な要因を探ることが推奨される。 (2) 実態調査について より確からしい要因を追究するためには、いくつかのサンプルデータに対して実態調査を行って検 討することが望ましく、今後の検討課題としている。来年度においては、この検討課題にも取り組む所 存である。 4.2 システムリスクと開発工数の関係分析について 分析結果から、規模当たりの総開発工数(H1)については仮説を部分的に支持するという結果が得ら れた。規模当たりの総テスト工数(H2)については仮説を概ね支持するという結果が得られた。 しかし、規模当たりの総テスト項目数(H3)については仮説を支持するという結果は得られなかった。 以下、この結果について考察する。 総テスト工数は総開発工数の一部なので、総開発工数には総テスト工数に比べてより多くの変動要 因が影響する。そのため、総テスト工数に関する仮説 H2 が支持されたとはいえ、総開発工数に関する 仮説 H1 が同様に支持されるとは言えない。従って、これらの結果は妥当と考えることができる。 一方で、システムリスクの高いプロジェクトの方が低い方に比べて規模当たりの総テスト工数が増える 理由として当初は次を考えていた。「システムリスクの高いプロジェクトの方がリスクベースドテストよりも網 羅的なテストが行われる傾向があるため、テスト項目数が増える。その結果として、総テスト工数も増加 する。」しかし、仮説 H3 が支持されなかったことにより、この論理を積極的に支持する結果が得られたと はいえない。 総テスト工数に関する仮説 H2 が支持され、総テスト項目数に関する仮説 H3 が支持されなかった理 21 © IPA, Japan. 2015 All rights reserved 由の一つとして、開発規模の影響が挙げられる。開発規模の大きいプロジェクトでは、その機能要求や それらの組合せが膨大になるため、限られた納期と予算の範囲では網羅的なテストをすべてやり切るこ とができず、結果として、リスクベースドテストで対応せざるを得ない状況に追い込まれることがあり得る。 本取り組みでは、開発工数に影響する要因としてシステムリスクに着目してきたが、納期と予算の圧 力の前には、開発規模の大きさがテストの行動に強く影響しているのかもしれない。この仮説の妥当性 を検証するデータを現時点では持ち合わせていないが、そうだとすれば、IT システムの価格と納期の適 正化に向けてより強く働きかける必要がある。同時に、品質を追求することで開発工数を低く抑えるとい う品質管理の基本的な考え方を実践する努力が求められる。 4.3 横断的分析アプローチについて 本取り組みでは、「横断的分析アプローチ」を採用して分析した。 横断的分析アプローチ：分析方法を共通化した上で各組織が分析した結果を持ち寄り、それら を横通しで分析するアプローチ 横断的分析アプローチによって、「開発の早い段階から品質をコントロールすれば結果指標が良くな る」という命題及び「高度なＩＴシステム（システムリスクの高いソフトウェア）の開発には、それ相応の品質 保証の工数が必要である」という命題をデータに基づいて概ね実証できた。これらの命題の実証を通じ て、横断的分析アプローチの有効性を確認できた。 ただし、横断的分析アプローチを成功させるためには、「分析方法の共通化」が前提として重要であ る。本分析アプローチでは、試行錯誤（数回の試行と検討）を経て、「データ収集の共通化事項」として、 最終的に「2.2 分析方法」の「(2) データ収集」の＜データ収集の留意事項＞に示した条件を採用し た。 横断的分析アプローチを成功させるためには、この中で特に次の条件が重要と考えられる。 ＜データ収集の主要な条件＞ (1) 品質マネジメントの成熟度が一定レベル以上の組織から、そのマネジメント対象としたプロジ ェクトのデータを収集する。 （組織の成熟度が、信頼性の主要な変動要因の一つと考えられるため） (2) ドメインの偏りがないようにデータ収集するか、ドメインに分けてデータ収集する。 （業種等のドメインの種別が、信頼性の主要な変動要因の一つと考えられるため） (3) 次のような、外れ値/異常値と判断できるプロジェクトデータは対象外とする。 （外れ値/異常値の影響を軽減するため） ◇うまくコントロールできなかった（内部的な理由によって異常な結果になった）プロジェクト ◇顧客都合で、大幅に計画超過したり、長期にわたって中断したプロジェクト ◇極端に小規模なプロジェクト 22 © IPA, Japan. 2015 All rights reserved 5. おわりに 本取り組みにおける分析アプローチ（横断的分析アプローチ）は、高度な統計解析を行うのは難しい ものの、データ提供組織の協力が得られれば横断的な情報を比較的容易に集めることが期待できる。 今回限られたデータからではあるが分析の結果、概ね命題を支持する結果が見られたことから、今回 行った分析アプローチは命題の実証に有効と考えられる。 横断的分析アプローチの有効性が確認できたため、今後の課題としては、より精緻な分析や、信頼性 変動要因間の相関分析や工期短縮の限界などの新たな分析に引き続き取り組んで行きたい。 また、より多くのデータを集めることで、客観性の高い分析結果を示すために、このような調査に協力 してもらえる組織を増やし、より広い範囲で情報を集めることが挙げられる。そのためには、データ保有 企業が容易に参加できるような仕組み作りが必要であり、本 WG で継続検討したいと考えている。 参考文献 (1) 「野中誠：複数組織データに見るシステムリスクと開発コストの関係，情報処理学会研究報告， Vol.2014-se-186, No.11, 2014/11/14」 23 © IPA, Japan. 2015 All rights reserved 付録 1 信頼性メトリクス WG 検討メンバ 氏名 主査 委員 委員 委員 委員 委員 委員 委員 委員 委員 委員 委員 委員 オブザーバ オブザーバ 事務局 事務局 事務局 事務局 のなか 野中 い さ じ 誠 伊佐治 おおや 大屋 おきしお 沖汐 おぐら 小掠 ないとう 所属 まこと てつ 哲 つとむ 力 もとじ 大志 たかし 隆 やすお 内藤 康生 なかじま たけし 中島 ふじはら 藤原 はっとり 毅 りょういち 良 一 かつみ 服部 克己 ほんだ なおみ 誉田 直美 わしざき 鷲崎 さおとめ 早乙女 よしたに 葭谷 はちや ひろのり 弘宜 まこと 真 つとむ 努 たかのり 八谷 貴則 やすえ のぶすけ 安江 伸輔 やました ひろゆき み なわ としのぶ さえき まさお 山下 三縄 博之 俊信 佐伯 正夫 つかもと 塚元 いくじ 郁児 東洋大学 日立製作所 日本アイ・ビー・エム 日本ユニシス SCSK ニッセイ情報テクノロジー 三菱電機 三菱電機インフォメーションシステムズ USOL 北海道（日本ユニシス） 日本電気 早稲田大学 NTT データ経営研究所 TIS 富士通 スミセイ情報システム IPA/SEC IPA/SEC IPA/SEC IPA/SEC 24 © IPA, Japan. 2015 All rights reserved 付録 2 信頼性メトリクス WG 開催日 回数 開催日 第一回 2014 年 1 月 22 日 第二回 2014 年 2 月 27 日 第三回 2014 年 3 月 20 日 第四回 2014 年 4 月 23 日 第五回 2014 年 5 月 22 日 第六回 2014 年 6 月 26 日 第七回 2014 年 7 月 24 日 第八回 2014 年 8 月 21 日 第九回 2014 年 9 月 25 日 第十回 2014 年 10 月 30 日 第十一回 2014 年 11 月 27 日 第十二回 2014 年 12 月 18 日 第十三回 2015 年 1 月 29 日 第十四回 2015 年 2 月 19 日 25 © IPA, Japan. 2015 All rights reserved 付録 3 各社の管理指標調査結果の集計サマリ 質問1. 下記の表に挙げた管理指標について，次の観点からそれぞれ◎○△×のいずれかで回答してください。主観的で結構です。 ①測定状況 … 分析対象のプロジェクトにおいて， ◎：測定方法が標準化されており，ほとんどのプロジェクトで測定している。 ○：測定方法にばらつきはあるが，ほとんどのプロジェクトで測定している。 △：測定しているプロジェクトは半数程度である。 ×：この管理指標は測定していない。 ②有用性 ◎：重点的な管理指標として利用しており，プロジェクトのコントロールに役立っている。 ○：管理指標として利用しており，プロジェクトのコントロールに役立っている。 △：管理指標として利用しているが，プロジェクトのコントロールに役立っているかは何ともいえない。 ×：測定していない， ③実証性 … この管理指標と結果指標（品質基準達成／未達，見逃しバグ多／少など）との関連性について， ◎：実証データで分析した経験があり，有効な関連性が見いだされている。 ○：実証データで分析した経験はないが，実証データを分析すれば有効な関連性が見いだされる可能性が高い。 △：実証データで分析した経験があるが，有効な関連性は見いだせなかった。または，経験がなく，有効な関連性が見いだせるかどうか分からない。 ×：実証データでの分析を行うことは難しい，または不可能である。 分類 管理指標 上流工程 レビュー指摘数／レビュー工数 レビュー指摘数／成果物規模 レビュー工数／成果物規模 レビュー工数／開発工数 上流工程での欠陥摘出比率 成果物規模／レビュー時間 開発工数／成果物規模 レビュー工程別の欠陥除去比率 下流工程 不具合検出数／テスト工数 不具合検出数／成果物規模 テスト工数／成果物規模 テスト項目数／成果物規模 意味 レビュー工数当たりの欠陥摘出数 成果物規模当たりの欠陥検出数 成果物規模当たりのレビュー工数 開発工数に対するレビュー工数の比率 上流での欠陥混入数（の予測値）に対する，レビューでの 欠陥摘出数の合計 レビュー時間当たりの成果物規模 成果物規模当たりの開発工数 指摘＋見逃し欠陥数に対する，見逃し欠陥数の比率 テスト工数当たりの不具合検出数 成果物規模当たりの不具合検出数 成果物規模当たりのテスト工数 成果物規模当たりのテスト項目数 目的の例 レビューの十分性，効率性を評価 レビューの十分性，有効性を評価 レビュー工数の十分性を評価 レビュー工数の十分性を評価 測定状況 ○1 △2 ×3 ◎3 ○1 △2 ◎1 ○1 △3 ×1 △2 ×4 有用性 ○1 △2 ×3 ◎3 ○1 △2 ◎3 △1 ×2 ○1 △1 ×4 実証性 ◎1 △3 ×2 ◎2 ○1 △3 ◎2 ○1 △2 ×1 ◎1 ○1 △1 ×2 レビューの有効性を評価 ◎1 ○1 △2 ×2 ◎1 ◎3 ○1 レビューの効率性，適切性を評価 開発作業への投入工数の十分性，生産性を評価 レビューの有効性を評価 テストの十分性、効率性を評価 テストの十分性を評価 テストの十分性を評価 テスト項目の十分性を評価 ○1 ○2 ○1 ◎1 ○1 ◎5 ○1 ○2 ◎4 ○2 ×5 △1 ×3 △2 ×3 △2 ×2 △1 ×3 ◎1 ◎1 ◎4 ◎1 ◎4 △2 ×3 ○1 ×5 ○1 △1 ×3 △3 ×3 ○1 △2 ×2 ○2 △2 ×3 ○1 △1 ◎1 ◎1 ◎1 ◎2 ◎3 ◎1 ◎3 ○1 ○1 ○2 ○2 ×2 △1 ×4 △1 ×2 △2 ×2 △2 ×2 △1 △2 ×2 △1 質問2. 上記以外に，有用性および／または実証性の観点から特に推奨する管理指標があれば以下に挙げてください。行は適宜増やしていただいて結構です。 分類 意味 目的の例 測定状況 有用性 実証性 下流工程 テスト工程別の欠陥除去比率 指摘＋見逃し欠陥数に対する，見逃し欠陥数の比率 上流と同様、下流で欠陥数、修正工数が過大となる原 因が分析可能になる ○ ○ ○ 下流工程 テスト設計工数/テスト工程工数 テスト工程全工数に対するテスト仕様書作成工数 テスト仕様書作成およびレビューの有効性を評価 △ △ × テスト仕様書作成およびレビューの有効性を評価 △ △ × 指標間の レビュー工数/ＫＬとレビュー摘出バ レビュー工数/ＫＬの度合いに対するバグ数/ＫＬという因果 レビューの十分性と作り込んだ品質の確認 関係 グ数/ＫＬ 関係で分析する ○ ◎ ◎ 指標間の テスト工数/ＫＬとテスト摘出バグ数 テスト工数/ＫＬの度合いに対するバグ数/ＫＬという因果関 テストの十分性と出荷する品質の確認 関係 /ＫＬ 係で分析する ○ ◎ ◎ バグ分析（真因分析）の結果得られ テスト終盤の重大バグに限定して分析するので、重要な バグ分析 る作り込み原因、見逃し原因（レ 観点の見逃しという意味になる ビュー、テスト） ◎ ◎ ◎ ◎ ◎ ◎ 測定状況 ○1 ×1 ○ ◎ × ◎ 有用性 ◎1 ×1 ◎ ◎ △ ◎ 実証性 ◎1 ×1 ◎ ◎ × ◎ 下流工程 管理指標 テスト設計レビュー工数/テスト設計 テスト仕様書作成工数に対するレビュー工数 工数 バグ傾向 統合テスト以降のバグを種類別に 分析 分類カウントする 出荷にあたって細かい確認もれがないかの確認 開発したＳＷの特性に対して、想定した種類のバグが出て 想定していなかった種類のバグがでていないか、思う いるかの確認 ように摘出できていない種類のバグがないかの確認 質問3. 結果指標として，有用なものの候補があれば以下に挙げてください。行は適宜増やしていただいて結構です。 分類 管理指標 リリース後 社内品質基準の達成／未達 社内品質基準の達成／未達 COPQ（Cost of Poor Quality) 初期障害件数 テスト システムテスト摘出バグ数/ＫＬ 説明 社内で設定したリリース後バグ密度が，あらかじめ定めた基準を満たしたか否か 出荷後バグ件数(実件数）あるいは重要度別件数の基準の達成状況 欠陥修正工数/プロジェクト総工数 顧客が納品物の受入検収完了以降、安定稼動までの間に発生した障害の件数。 システムテストバグ数は疑似的な出荷後バグ状況を表していると考えており、一定値以上摘出される場合は危険 26 © IPA, Japan. 2015 All rights reserved 付録 4 新規・良群 入力シート 0 開発規模 (KSLOC) 分析用集計ツールの入力用シート 新規開発の良群のプロジェクトデータを、赤枠の中に値貼り付けしてください。500件まで入力できます。 7項目がすべて揃っていないプロジェクトも含めてください。 ③については，①÷（①＋④）で便宜的に数値化したものを記入して頂いても結構です。 ★集計シート5ではテスト工数（単体テストを除く）が追加されています。 0 ①レビュー指摘数 （件） 0 0 0 0 0 ②レビュー工数 （人時） ③上流での 欠陥摘出比率 （％） ④不具合検出数 （件） ⑤テスト項目数 （項目） ⑥テスト工数 （人時） ◇上記の規模及び①、②、③、④、⑤、⑥の生データを入力すると、次ページの報告用シートが自 動的に作成される。 ◇入力用シートの内容は各社の生データが入力されるので、相対化したデータのみ次ページの 報告用シートに出力しそれを IPA/SEC としては収集している。 元の生データは一切各社の外に は出ないようにコントロールしている。 ◇分析用集計ツールを各社に配布することにより、統計処理の正確性及び効率の向上を図った。 27 © IPA, Japan. 2015 All rights reserved 付録 5 分析用集計ツールの報告用シート ＜新規開発プロジェクト＞ 2015/1/7版 ＜注記＞ ◇開発規模：KSLOC ◇①のレビュー指摘数について (0) 開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 歪度 0 0 (0) 対数化 開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ①（上流工程）レビュー指摘数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 歪度 0 0 ①対数化 （上流工程）レビュー指摘数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ②（上流工程） レビュー工数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 歪度 0 0 ②対数化 （上流工程） レビュー工数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ③上流工程での欠陥摘出比率 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ③対数化 上流工程での欠陥摘出比率 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 28 © IPA, Japan. 2015 All rights reserved 歪度 ④（下流工程）不具合検出数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 歪度 0 0 ④対数化 （下流工程）不具合検出数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ⑤（下流工程）テスト項目数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 歪度 0 0 ⑤対数化 （下流工程）テスト項目数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ⑥ （下流工程）不具合検出数／テスト項目数 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 歪度 0 0 ⑥対数化 （下流工程）不具合検出数／テスト項目数 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ⑦（下流工程）テスト工数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 歪度 0 0 ⑦対数化（下流工程）テスト工数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ⑧総欠陥数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 ⑧対数化 総欠陥数／開発規模 委員所属 結果指標 企業 IPA/SEC 良 (dummy) 否 最小値 第1 四分位数 中央値 平均値 第3 四分位数 最大値 件数 両側検定 P値 0 0 29 © IPA, Japan. 2015 All rights reserved 歪度 別添資料 分析用集計ツール（Excel ファイル） 添付の「分析用集計ツール.xlsx」参照。 30 © IPA, Japan. 2015 All rights reserved
© Copyright 2024 ExpyDoc
