第７分科会（Ｘ２グループ）

ソフトウェア開発における欠陥情報移転法の提案
The way to transfer a defect information “Sen-kun”(=Lesson and learned from BattleExperience) in software development
主査：
副主査 ：
リーダー ：
研究員 ：

細川永田
齋藤
小川
仁藤

宣啓（日本アイ・ビー・エム株式会社）敦 （ソニー株式会社）伸介（株式会社メタテクノ）
哲生（株式会社 JSOL）
土屋 治世（SCSK 株式会社）千博（矢崎総業株式会社） 森 龍二 （株式会社エクサ）

研究概要
ソフトウェア開発プロジェクトにおいて発生する欠陥の情報は，一般に同一プロジェクト内で欠陥管理票（バグ票）として蓄えられ，欠陥修正のために使用されることはあっても，別のプロジェクトの品質向上に活用されてはいなかった．
本研究では，ソフトウェア品質向上の観点から欠陥情報を別プロジェクトにおいて横断的に再利用するために，欠陥発生のメカニズムを図式化した「欠陥モデル」とプロジェクトと欠陥の属性情報である「欠陥特性」を合わせて移転する欠陥移転法を考案し，その有効性を確認した．
Abstract
Information on defects that occurs in a software development project is generally
stored as bug reports in the project and is referred for the debugging, but seldom
used in different project for quality improvement.
In this research, we investigated the way to transfer the defect information to apply
for the quality improvement using the "defect model"(which transformed a mechanismof flaw occurrence into a diagram) and the "defect attribute"(which is attributeinformation on a project and defect).
1. はじめに1.1 背景と問題
ソフトウェア開発プロジェクト（以下、プロジェクト）において、ソフトウェア欠陥（以下、欠陥）は，開発工程の進捗に伴い発見され，蓄積・管理される．しかしながら，蓄積・管理の対象は，あくまで発生した事象そのもの (インシデント)であり，その発生原因である「欠陥」が蓄積されることはまれである．安定的なプロジェクト運営と品質の高いソフトウェアの提供のために，労力をかけて欠陥を収集する組織は存在するものの，収集した欠陥をそのまま利用できるプロジェクト（例えば同一製品の派生開発など）以外では，欠陥の再利用はほとんど進んでいないというのが実情である．
その原因は，以下のような欠陥の収集方法にあると考える．
(1)主観的判断による分類
ソフトウェア開発の現場では「重大度」「緊急度」のように，ステークホルダーによって受け取り方が異なる主観的な数値(1～5)やランク付け(ABC など)などの分類が行われている．主観的判断による分類では，分類の妥当性自体が個人の判断に依存するため，属人的で使いにくい．また，同一製品の派生開発などを除けば，過去のプロジェクトと現在のプロジェクトでは，プロジェクトの目的・ステークホルダー・環境が異なる のが一般的である．したがって過去プロジェクトでメンバーが判断した分類結果が，次のプロジェクト

1

第７分科会（Ｘ２グループ）
でも同じであるとは限らず，かつ過去プロジェクトに再調査やヒアリングを行うことも難しいため，汎用的な分類結果は役に立たないのが実情である．
(2)欠陥の表現方法
本研究で述べる「欠陥情報」とは，プロジェクトで発生するインシデントのうち，故障と判断されたものの発生原因や解決の経緯を記述した，いわゆる欠陥管理票（バグ票）に記載されている情報，と定義する．
一般的には欠陥情報を論理的なモデル図などを用いず，あくまで自然言 語による文章表現で記述するため，原因究明の元となる直接的な情報が見えにくく，かつ欠陥混入メカニズムの重要情報である間接情報を見落とすことが多い．
1.2 研究の狙い
プロジェクトの安定的運営と高品質のソフトウェア提供を目的として，欠陥は異なるプロジェクト間で再利用・共有すべきであるという前提を置く．現実のプロジェクトでは，一般に欠陥管理票の形で蓄積され，テスト工程における欠陥の消し込み（修正）に用いられる．派生開発や同一製品の保守では，プロジェクトの類似性から過去プロジェクトの欠陥そのものが移転されることも多い．
一方，欠陥分類が主観的であるという問題に対しては，「 ODC」や「バグ分析」などの経験的な欠陥分類の方法が知られている [1]ものの，学術的に確立された，あるいはデファクト・スタンダードと呼べる欠陥分類法はない．また学術的に効果が証明された欠陥表現の方法も存在しない．
プロジェクト横断的な欠陥の水平展開を目的に対して，最適な欠陥表現とは何かを追求することを本研究の狙いとした．その過程で，欠陥表現そのものの伝達力と，その伝達力をさらに強化するものは他にないかを検証することとした．
以降本稿では，先行研究をヒントにした欠陥利用の検証（ 2 章）と，本研究で提案する欠陥情報の利用法の詳細と検証（3 章），実験結果の評価と考察（4 章），最後にまとめと今後の展望（5 章）を述べる．
2. 先行研究とその検証
2.1 先行研究
欠陥の再利用に関する過去の研究成果では，欠陥混入メカニズムを表現，伝達するためのモデルについての研究がある.
細川らの研究では，欠陥混入メカニズムを表現・伝達するための，抽象化モデル（以降欠陥モデルという）を提唱している[2]．これは,欠陥管理票（バグ票）に表現しきれていないプロジェクトの制約条件・環境因子を付加したモデル図であり，欠陥情報の移転を行うために必要な情報を最大限記録したものである．欠陥モデルにより，従来手法の問題点である主観的判断の排除と欠陥の表現方法の両方の改善を狙っている．
また,柏原らの研究では ,この欠陥モデル図で ,欠陥混入のメカニズムを表現するための表記ルールと記述方法を提案している [3]．
・表記ルール：「不具合」「欠陥」「過失因子」「誘発因子」というノードを規定
・記述方法：①表記ルールに従い,「不具合」「欠陥」「過失因子」「誘発因子」をモデリング②誘発因子が漏れなく,重複なく，矛盾なく示されているかを確認③業務や製品固有の言葉を避け，一般化して表現④モデリングした欠陥メカニズムをレビュー
以上のように，先行研究では欠陥モデルとそのメカニズムの有用性については検証が行われている．しかし、欠陥モデルが実際のプロジェクトにおいて使われた結果，有用性があるか，という点までは検証されていない．そこで我々は，欠陥情報の移転・水平展開のために，欠陥モデル図の有用性を測定・検証した．
2

第７分科会（Ｘ２グループ）
RQ1:欠陥モデル図により欠陥は移転できるか？
欠陥モデル図による欠陥情報の移転イメージを図 1（拡大図付録 1）に示す．

図１ 欠陥モデル図による欠陥情報の移転
2.2 欠陥モデル図利用の有用性の検証（実験１回目）
RQ1 を検証するために以下の実験を行った．
2.2.1 実験１回目の実験方法
欠陥モデル図が背景の異なるプロジェクトで利用可能であることを，一般的にプロジェクトで行われるリスク管理の“リスク候補抽出”作業を用いて検証する． RQ1 の検証のため、欠陥が移転できた度合いをリスク抽出件数で測る こととした. 欠陥モデル図（図 2,拡大図 付録 2）は，被験者の所属企業とは異なる企業の不具合事例を使用した．

図 2 欠陥モデル図
今回の実験は以下の手順で実施した．対象プロジェクトの情報については付録 3 に示す．
＜実験手順＞①実験対象プロジェクト A，B，C において，被験者 3 名（各プロジェクトのマネージャー
以下，PM）が、表 1 の手順 1→手順 2 の順で実施した.
②手順 1 と手順 2 を比較し，各 PM のリスク候補の抽出件数に変化があるかを見た．
表 1 プロジェクトリスク候補の抽出手順（実験１回目）
手順№
リスク候補抽出方法
方法概要
12

欠陥モデル図を使用しない各PM 個人が好む方法
欠陥モデル図（図 2）を付与した方法－・手順 1 でリスク候補の抽出を行ったあと，欠陥3

第７分科会（Ｘ２グループ）モデル図（図 2）を提供する．
・欠陥モデル図（図 2）を見て，リスク候補を追加抽出してもらう．
・欠陥モデル図（図 2）から抽出されたリスク候補の件数を測定する．

2.2.2 実験 1 回目の実験結果
今回の実験結果を図 3 に示す（詳細 付録 4）．
この結果から，欠陥モデル図を利用したリスク候補の抽出件数に大きな変化はなかったといえる．

図 3 実験結果（実験 1 回目）
2.2.3 実験１回目の結果考察
プロジェクト A では，手順 1 と手順 2 で変化は見られなかった．プロジェクト B とプロ
ジェクト C では，リスク候補件数が 1～2 件増加した．これらのデータからは，欠陥モデル図がリスク候補の抽出に寄与したとは言い難いという結果が得られた．その理由は , 以下の２つが考えられる．
1. 表現方法
2. 伝達情報不足
これらの２つの理由のうち，例えばプロジェクト A より，「 構成管理の仕組みが確立しており，この事例から抽出されるリスク候補はない」 というコメントを受領している．欠陥が埋め込まれた時，構成管理が十分でない状況であったことが理解されていることから，欠陥モデル図表現の有効性は認められるものの，欠陥の情報が不足していた可能性が推察された．
3. 提案手法と再実験
3.1 今回提案する欠陥移転法
2 章の実験より，「欠陥モデル図だけ与えられた場合，欠陥情報の直観的な理解に留まり，欠陥を自プロジェクトのリスク候補として認識されるまでには至らない」という課題が発見された．
そこで次に，この課題を解決するため，「欠陥モデル図で表現された欠陥を自プロジェクトのリスク候補として認識されるようにするための方法」を検討した．
過去の研究成果を検討した結果，細川らの提唱する「欠陥特性」[4]に着目し，これを「欠陥モデル図」に付加することで，モデルを具象化する方法を提案する．
細川らの研究では，欠陥には欠陥自体の固有の性質（欠陥特性と呼ぶ）によって，欠陥を欠陥と認識し，個々の欠陥が獲得した性質を区別できるとし，この欠陥特性により欠陥の伝達は容易になることが示されている．
先行研究[4]では，欠陥特性とは以下のように定義されている．
(1)基本特性：「これらの特性が満たされれば欠陥」と言える特性
・具現性：成果物（中間成果物を含む）に不備として含まれる性質
・有害性：期待された結果からの逸脱を引き起こす性質
4

第７分科会（Ｘ２グループ）
・因果性：混入背景から混入，表出までの過程が，因果関係を持つ性質(2)混入特性：欠陥の混入から除去までのライフサイクルの中で欠陥の混入に寄与する
特性
・連鎖性 ：時間・工程・対象を跨ぐ形で，欠陥が別の欠陥を発生させる性質
・好欠乏性：人・組織・作業対象・環境等の不足が大きいほど欠陥の混入確率が増幅される性質
・好複雑性：人・組織・作業対象・環境等が複雑であるほど欠陥の混入確率が増幅される性質
・増殖性 ：成果物のコピーもしくは再利用により，ある欠陥が再生産される性質
2 章の実験で使用した欠陥モデル図は「欠陥特性」の中の因果性 を重視したモデル図である．それゆえ，抽象化の過程で「削ぎ落とされた欠陥特性（＝具現性，有害性など）」が存在する．そこで我々は，「欠陥モデル図では不足している欠陥特性＝具現性，有害性，混入特性」を移転先のプロジェクトに欠陥モデル図とともに提供すれば，欠陥の移転，すなわち欠陥情報がリスク候補として認識される本質的な伝達に有効なのではないか ，と考えた.

図 4 欠陥移転法による欠陥情報の移転プロセス
今回提案する欠陥移転法により欠陥情報が移転されるイメージを図 4 に示す（拡大図付録 5）.
この欠陥移転法によって，以下の成果が期待できると考えた．
・欠陥モデル図だけ提供する場合よりも， 「自分のプロジェクトの場合，どういう影響があり，どういうリスクがあるか」という気づきを与えやすくなる．
・背景の異なるプロジェクト間でも，欠陥特性を加えることで，欠陥情報の移転・再利用が容易になる．
この提案が有効であるかを，以下の RQ を設定して検証実験を行った．
RQ2: 背景の異なるプロジェクトにおいて，欠陥特性を加えた欠陥モデル図を渡すことで欠陥情報の移転・再利用が促進できるか？
3.2 今回提案する欠陥移転法の検証（実験 2 回目）
RQ2 を検証するために以下の実験を行った．
3.2.1 実験 2 回目の実験方法
2.2.1 で実験を行ったプロジェクト A,B,C の PM に対して、以下の手順で実験を実施した.
＜実験手順＞

5

第７分科会（Ｘ２グループ）①実験対象プロジェクト A，B，C において，被験者 3 名（各プロジェクトの PM）が、表 2の手順 1→手順 2→手順 3 の順で実施した。（図 2 を見たあとで、図 5 を見た。）②手順 1、手順 2、手順 3 を比較し，各 PM のリスク候補の抽出件数に変化があるかを見た．

手順№
123

表 2 プロジェクトリスク候補の抽出手順（実験 2 回目）
リスク候補抽出方法
方法概要
欠陥モデル図を使用しない PM 個人の好む方法
欠陥モデル図（図 2）を付与した方法

欠陥モデル図（図 5 拡大図 付録 6）と欠陥特性（表 3）を付与した方法

図5－・手順 1 でリスク候補の抽出を行ったあと，PM に欠陥モデル図（図 2）を提供する．
・欠陥モデル図（図 2）を見て，リスク候補を追加抽出してもらう．
・欠陥モデル図（図 2）から，抽出されたリスク候補の件数を測定する．
・欠陥モデル図（図 2）に，欠陥特性（表 3）を追加する（図 5）．欠陥特性には，抽象化の過程で削ぎ落とされた欠陥特性の中から「混入特性」を使用した．
※PM を対象とした場合 ，好欠乏性・好複雑性の 2 点が有効であったため ，この 2 つの要素を増幅因子として追加した．
・手順 2 でリスク候補の抽出を行ったあと，PM に欠陥特性（表 3）と欠陥モデル図（図 5）を提供する．
・欠陥特性（表 3）と欠陥モデル図（図 5）を見て，リスク候補を追加抽出してもらう．
・欠陥特性（表 3）と欠陥モデル図（図 5）から抽出されたリスク候補の件数を測定する．

欠陥特性を付与した欠陥モデル図6

第７分科会（Ｘ２グループ）

表 3 欠陥特性（混入特性）
項目
内容
人的欠乏
PM の工数不足
対象欠乏－環境欠乏
テストケース漏れ
好複雑性
人的複雑
PM が同時に複数案件を担当
対象複雑
複数ベンダーによる開発
環境複雑
ベンダーごとに開発拠点が異なる
3.2.2 実験 2 回目の実験結果
今回の実験結果を図 6 に示す（詳細 付録 4）．
すべてのプロジェクトにおいて，「欠陥特性を付与した欠陥モデル図」を利用したリスク候補の抽出件数が増加するという変化が見られた．
特性名
好欠乏性

図 6 実験結果（実験 2 回目）
3.2.3 実験 2 回目の結果考察
今回の実験では，欠陥特性を付与した欠陥モデル図を与える方法は，欠陥モデル図を与えるだけの 2 章の方法より，平均で 1.5 倍程度のリスク候補が抽出された．これにより，欠陥特性を付与した欠陥モデル図を与える方法は，欠陥モデル図を与えるだけの方法より，より背景の異なるプロジェクトにおいて再利用が可能であることを確認できた． プロジェ
クト A のコメント（付録 7）にある「 抽象化されたモデル図よりも具体化されているほうが，自プロジェクトに置き換えてイメージしやすいように思う」から，追加した情報が自プロジェ
クトの背景と一致したため，リスク候補として認識した項目数が増えたのではないか，と推察される．

4. 評価・考察
4.1 評価2 章，及び 3 章の検証から，以下の結論が得られた．
(1)RQ１に対する評価
背景の異なる別プロジェクトの PM に「欠陥モデル図」だけで欠陥情報を移転した場合は，2 章の実験１回目の結果より，リスク候補抽出件数が向上するという効果は認められなかった．すなわち，欠陥を移転するための表現として，「欠陥モデル図」だけでは情報は不足している，という評価が得られた．
この理由を考察すると，欠陥モデル図だけでは，欠陥の伝達情報が不足しているため，と推察される．
(2) RQ2 に対する評価
背景の異なる別プロジェクトの PM に「欠陥モデル図」に「欠陥特性」を加えて提供した
場合は，3 章の実験 2 回目の結果より，リスク候補抽出件数が平均して 1.5 倍に増加するという効果が認められた．すなわち，欠陥特性を欠陥モデル図に加えるという欠陥の表現は，欠陥を移転するための表現として有用性があるという評価が得られた．
7第７分科会（Ｘ２グループ）
4.2 考察今回の実験では，欠陥モデル図だけを与えるより，欠陥モデル図に欠陥特性を加える欠陥情報の移転法に対して有効性が確認された，という結果になった．
また, PM を主体とする“管理系ロール”に対する欠陥移転では，欠陥モデルの作成過程すなわち抽象化の過程で排除した具象情報が必須である事がわかった．
このことから，今後の課題としては，欠陥伝達の移転元と移転先のロールの違いを，抽象具象の度合いを調整することで吸収することが可能か ,という点が挙げられる．その課題解決に向けて，例えば「システムアーキテクト」「品質管理担 当者」「研究者」といった抽象的な情報を扱うことに長けているロールを対象にした実験などを行っていくことが必要である．
5. おわりに
5.1 まとめ本研究では欠陥情報の移転法として,「欠陥モデル図」に「欠陥特性」を付加する手法を提案した．経験値の浅い PM の場合，欠陥モデル図だけでは，リスク認識を高めるには至らないケースでも「欠陥特性」を付加することで，リスク認識の向上に有効である点を確認した．
5.2 今後の課題・展望
本研究に対する今後の課題としては，以下の点が挙げられる．
(1)実験を行った際のアンケート(付録 7)では,「 膨大な情報を提示されても見る気がしない 」と言う意見もあった．我々の提案した方法は，抽象化して削った具現性をまた付加していく，という方法であり，具現性を加えすぎるとかえってリスクに気付きにくくなるという，諸刃の剣的な性質がある．欠陥特性という具象情報の付加の度合いのバランスの追求が必要である．
(2)欠陥特性情報の縮約・分類・クラスタリング，現在未検討の欠陥特性の追加等を経て，実リスク・実課題との関連づけを行なうなど，混入確率と発症傾向等のデータ測定の蓄積も今後の改善課題である．
(3)今回の検証対象は時間の制約もあり,やむを得ず同じプロジェクトの PM を対象に実験
1,実験 2 行ったが，本来であれば,被験者グループは複数用意して実験を行うべきである.
また,4 章でも述べた通り，PM 以外の職種を対象にした場合は異なる結果が出る事も想定される．より汎用性の高い欠陥移転法の研究の為に，PM 以外のロールを対象にした実験を行い，実験サンプル数・パターン数を増やし，統計的な実証を試みることが必要である．
これまで欠陥情報は単に蓄積することばかりの焦点が向けられがちであった．今回我々は，この状況を改善するために，プロジェクト間での欠陥情報再利用を促す欠陥移転法を提案した．欠陥情報は欠陥管理票の中で眠らせておくだけでは宝の持ち腐れである．ソフトウェアの品質向上のために，積極的に活用され，プロジェクト間での流通が活発化されていくことを期待する．
6.
参考文献[1]ソフトウェア品質知識体系ガイド（第 2 版）−SQuBOK Guide V2-，SQuBOK 策定部会，2014[2]細川宣啓ら，"過失に着目した欠陥のモデリング"，JaSST2013，2013[3]柏原一雄ほか，”ソフトウェア欠陥予測アルゴリズム” , 第 30 年度ソフトウェア品質管理研究会分科会報告書，2015[4]細川宣啓ら，”自律した品質改善活動に寄与する欠陥特性の提案”，第 30 年度ソフト
ウェア品質管理研究会分科会報告書， 2015

8

第７分科会（Ｘ２グループ）
付録 1

図 1 拡大図付録 2

図 2 拡大図

9

第７分科会（Ｘ２グループ）
付録 3

実験対象プロジェクトの概要

プロジェクト名
X（移転元）

A

BC

付録 4

C

・派生開発
・複数ベンダー・物流システム・Web 系
・システム統合
・複数ベンダー・ＰＭの業務経験年数：4 年
・ワークフロー支援システム
・Web 系
・新規開発
・ＰＭの業務経験年数：15 年
・生産管理システム
・Web 系
・サーバリプレイス
・ＰＭの業務経験年数：30 年

抽出されたリスク候補の概要

プ ロ ジ
ェ ク ト
名AB

プロジェクトの概要

手順№
1リ ス ク
候 補 件
数7件

27件

311 件

・ベンダーごとに定義されたローカルな構成管理ルールの影響に伴う不具合発生．
・複数ベンダーを取り纏める管理者（構成管理担当者）の作業負荷増に伴い，構成管理が不十分になる可能性がある．
・他ベンダーによる PGM 変更に伴い，テストケース数が増加する（工数が増加する）．
・顧客対応，トラブル対応等による PM 作業負荷増加に伴い，プロジェクト管理（構成管理，品質管理，進捗管理，課題管理等）が手薄になる．

111 件

・品質 3 件，組織 2 件，他社依存 4 件，
コスト・機能要求 各 1 件

213 件

・品質：PM が単独で行っている他のタスクに欠陥が潜在．
・品質：構成管理対象物の中に古いコードが残っている．

318 件

・体制強化しない場合の PM の計画タスクにおける QCD への影響．
・結合テスト密度は品質基準に達しているか
・構成管理対象物以外にバージョン管理している物はないか，ある場合古い物はないか
・流用機能が潜在欠陥を含んでいないか
・テスト網羅性は１００％か・他担当案件状況によって，更に PM 投入工数が減らないか

110 件

・要員 4 件，品質 2 件，技術・コスト・納期・顧客 各 1 件

抽出したリスク候補の概要／0 件の理由
・スコープ・顧客・体制 /要員・技術・提案 /見積・スケジュー
ル・コスト 各１件
（理由：構成管理の仕組みが確立しており，この事例から抽出されるリスクはない．）

10

第７分科会（Ｘ２グループ）

付録 5

2

11 件

・構成管理の不備による不具合発生．
（メンバーの入れ替わりが多発すると発生確率は高くなる．影響も大きい．）

3

17 件

・異なる開発環境の影響に伴う不具合発生
・管理者の作業負荷増に伴う作業漏れ発生
・他ベンダー間のコミュニケーションロス発生
・作業ピーク時のメンバー増減に伴い，構成管理ルールが徹底されなくなる．
・テストケース漏れ，テスト実施漏れ（既存機能のテスト自動化）
・構成管理ツール使用上のルールがない，または間違った使い方による影響
・リリースルール，テストルール

図 4 拡大図

11

第７分科会（Ｘ２グループ）
付録 6

図 5 拡大図

付録 7

PM からのコメント

プロジェ
クト名A

コメント
・抽象化されたモデル図よりも具体化されているほうが，自プロジェクトに置き換えてイメージしやすいように思う．
・プロジェクト特性に紐づく欠陥事例であれば参考になる．
・他プロジェクトの欠陥 DB から，自プロジェクトに関連する欠陥情報を抽出する際、膨大な量の情報が抽出されると見る気になれない．
・各プロジェクトの特性から抽出した欠陥情報が，品質管理部署から提供されると良い．
・欠陥の対応に使った工数も情報としてあると良い．
・欠陥の発生確率も情報としてあると良い．
・開発技術面の欠陥情報を提供してもらえると良い．
・欠陥データを他プロジェクトで活用するということはしてこなかったので，考え方としては良いと思う．
・潜在リスクを認識するには良い情報かもしれない．

B

・現在担当中のプロジェクトにおいて直接関係するリスクはないが，提供された欠陥情報からリスク候補を想定することは可能．
・欠陥モデル図や欠陥特性は，育成中の PM に有効であると思う．

C・プロジェクトによっては，誘発因子，増幅因子に記載されている項目すべてが，リスク候補として認識されるべき．
・膨大な情報を提示されても見る気がしない．欠陥情報をどう提供するかの工夫が必要．

12

第７分科会（Ｘ２グループ）
・複数の過失が関係しあって１つの欠陥を発生させることがある．
・欠陥モデル図がいくつかあると良い．
・欠陥モデル図がレベル分けされていると良い．

13