プロジェクト特性データやバグ管理データなどを対象として、それらのデータが持つ規則性をみつけます。望ましい規則性であれば、それらが起こりやすくなるように、望ましくない規則性であればそれらが起こりにくくすることにより、より効率の良いソフトウェア開発につなげることができます。

規則性発見に相関ルール分析を使っています。相関ルールの対象データは名義尺度（新規、改修）もしくは順序尺度（大中小など）であるため、数値データ（間隔尺度、比尺度）を扱えるように拡張しています。

対象とするエンピリカルデータは、複数のプロジェクトのプロフィール（バグ密度や工程比率や実現の難易度等）を表形式であらわしたものである。表形式になっていれば、特にプロジェクト特性のデータである必要はなく、バグ管理の表も対象となる。プロジェクトデータの表の例を表1、バグ管理表の例を表2に挙げる。

表1

バグ管理の表だと以下のようになるだろう。

表2

これらのデータから相関ルール（AかつBならばC: + メトリクス）を抽出する。メトリクスは支持度（出現頻度）や「AかつB」の部分と「C」の部分の依存度合いの強さを表すものである。相関ルールは、もともと小売店やコンビニでの購買データ（POSデータ）を解析し、Aが起こるとBが起こるという規則（相関ルール）を発見し、そのルールがどれくらいの頻度でおこり、「AとB」と「C」の共起の度合い（「C」が起きたときに「AとB」が起きているかどうか）を自動的に抽出する。相関ルールがわかれば、どういう商品をどれくらいおけばよいか、時間帯によって配置や数量を変えたり、効率化が可能である。これと同様のことを上にあげた表1や表2のようなデータから抽出すると、プロジェクトやバグによって、状況を把握したり、プロセスを改善したりするなど効率化ができる。

ルールの表記は、相関ルールと同様に

AかつB ⇒ C 支持度 x、信頼度 y、リフト z

と書く。

⇒よりも前の部分（AかつB）の部分を前提部、Cの部分を結論部と呼ぶ。

前提部は1つ以上の項目の組合せが書ける。結論部には単一の項目となる。

xはプロジェクトやバグ全体のうちルールが含まれる割合を表す。たとえば、100プロジェクトのうち、前提部を満たすようなプロジェクトが同時に結論部を満たすプロジェクトの数が30あれば、xは30/100である。すなわち、xが大きければそのルールにはそのデータセットの中において、普遍性があるといえる。

yは前提部を満たすプロジェクトのうち、どれくらいのプロジェクトが結論部を満たしているかを表す。たとえば、100プロジェクトのうち、前提部を満たすプロジェクトが60あり、同時に結論部も満たしているプロジェクトが30あれば、30/60になる。すなわち、yが大きければその前提部と結論部との結びつきが深いことを表す。yの値が小さければ、結論部に関係なく単に多くのプロジェクトが前提部にあてはまりる場合がある。

zは前提部を満たすプロジェクトの信頼度と前提部がないとき（全てのプロジェクト）の信頼度の比である。たとえば、前提部を満たすプロジェクトが60あり、そのうち、結論部を満たしているプロジェクトが30あれば、信頼度は30/60である。100プロジェクトのうち、前提部に関係なく結論部を満たすプロジェクトが40ある場合、その信頼度は40/100となる。このあとき、zは(30/60)/(40/100)で求められる。zが大きければ（一般には1より大きければ）、結論部が発生するために、前提部が寄与していることを表す。逆にzが小さければ、結論部は前提部に関係なく起きていることを示す。

相関ルール分析法により、抽出されたルールから上述のメトリクスをみながら、解釈が与えられるルールをみつける。相関ルールの抽出には、Agrawalらのアルゴリズムを用いる。Agrawalらのアルゴリズム(*)では、最低支持度を与え、支持度が低いルール（出現頻度が低いルール）を枝刈りしていき、計算結果の爆発を防ぐ。最低支持度の与え方や対象データに依存するが、100プロジェクト程度のデータからでも支持度0.05以上のルールは数千ルール程度は抽出される。

これらのうち、特に信頼度とリフト値に注意しながら、解釈が与えられるようなルールを選ぶ。リフト値の大きなルールは、前提部によって結論部が引き起こされている可能性が高く、ルールの信頼度が高ければ、前提部が起きれば高い確率で結論部が起こるからである。解釈が与えられたルールから望ましい部分や望ましくない部分を選ぶことにより、見積り時の指標値やプロセス改善につなげることができる。たとえば、（開発種別＝拡張開発）⇒（結合テスト工数比率＝高）、というルールが抽出され、リフト値や信頼度が大きい場合を考える。これらが実際の状況を表していることが確認できたなら、拡張開発の際には結合テスト工数の比率を大きく見積ったり、拡張開発に特有の結合テストのオーバヘッドがないかを調べることができる。

実際に表1, 2のようなデータを相関ルール分析するためには、前処理として、数値のデータを区間に離散化しておく必要がある。たとえば、再利用規模（KLOC）のような0以上の整数値をとる場合に、0～10: 小、10～100: 中、100以上: 大、のような区間を用意する。相関ルール分析を実行する前に、前処理として、表1, 2に含まれる数値を区間にわけておく必要がある。また、規模などはずれ値が非常に大きく、全体に与える影響が多い場合は、対数をとっておくとよい。たとえば、ほとんどのプロジェクトで流用率が10KLOC以下で1つだけ1000KLOCのものが存在すると、1000KLOCの大きさのせいで他のプロジェクトの値が相対的に小さい範囲になってしまい、その特徴を見過ごす場合がある。1000KLOCのデータを特異値として対象データから削除することもできるが、対数をとることにより、はずれ値が与える影響を相対的に小さくすることができる。

我々が開発したNEEDLEは、上述のような区間の区切り方や区関数を細かく指定できる機能があり、特に、連続値を区間にわける作業を試行錯誤する場合に手間が省ける。

エンピリカルソフトウェア工学で扱う表1, 2のようなデータには規模や比率などを表す数値データが多い。また、それらの数値がどういう分布をしているのかを知ることには大きな意味がある。工数やバグ密度の平均が低くなるような状況を探せたとしても、その分散が大きければ、期待する効果は得られないだろう。一般に分散が大きいことは、予定や見積りが難しい（はずれることがある）ことを表す。たとえば、テスト工程の半分を海外にアウトソースしたときの実績データから、テスト工程にかかる費用の平均が海外にアウトソースしないときより低いということがわかった場合、あわせて、その分散がアウトソースしない場合の費用の分散との比較をする必要がある。アウトソースすることにより、全体的に費用が下がることが推測されるが、それに伴うリスク（コミュニケーションミスにより、テストをうまく実行してくれず、結局、自社のテスト要員を多く追加して費用がかさんだ等）についても検討する必要があるからである。

そこでNEEDLEでは、結論部だけに限定して、区間ではなく、連続値の統計量（平均、標準偏差）を利用できるよう拡張している。ルールの記述方法は上述とほぼ同じであるが、結論部が平均値と標準偏差になる。すなわち、前提部分を含むプロジェクトはどのような分布の結論部になっているかを知ることができる。

* Agrawal R., Imielinski T., Swami A.,: Mining Association Rules between Sets of Items in Large Databases, Proceedings of ACM SIGMOD Conference on Management of Data, pp. 207-216 (1993).

プロジェクト特性データやバグ票を対象として、前回書いた、数値部分（連続値）を区間に分割してから、抽出するルールを質的ルールと呼ぶ。今回は、結論部分を区間に分割せずに、数値のまま扱う量的ルールについて書く。

質的ルールの対象が、離散化された区間であるのに対して、特定の結論部を指定して、前提部を満たすプロジェクトの結論部の値の統計量を算出するのが、量的ルールである。

量的ルールは、
AかつB⇒C(平均、分散)
と書き、Cを指定する。前回の表1であれば、たとえば、バグ密度を結論部に指定して、その平均と分散を求める。これにより、前提部を満たすプロジェクトやバグの結論部の値の分布がわかる。

前回の表1からは、たとえば、(開発種別＝拡張)かつ(要求のコミット具合＝a.承認済み)⇒総バグ密度(平均 0.72, 標準偏差0.21)というようなルールが得られ、前提部を満たすプロジェクトの総バグ密度の平均と標準偏差がわかる。

量的ルールにも質的ルールと同様に、支持度を計算することができる。ただし、信頼度とリフト値は求められない。そのかわりに、基準化平均（全体平均比）、基準化標準偏差（全体標準偏差比）を求める。基準化平均（全体平均比）は前提部がないとき、すなわち全プロジェクトの結論部の平均と前提部を含むプロジェクトやバグの結論分の平均の比である。

基準化平均をみれば、前提部がないときと比べて、前提部がある場合に、平均値が何倍になっているかがわかる。たとえば、総バグ密度を結論部とする場合には、前提部により、基準化平均が1よりも大きくなっていれば、前提部にバグ密度を上げる原因が含まれている可能性がある。

基準化標準偏差は、前提部を含むプロジェクトの結論部の標準偏差と全プロジェクトの結論部の標準偏差の比である。基準化標準偏差をみれば、前提部がないときと比べて、前提部がある場合に、標準偏差が何倍になっているかがわかる。たとえば、総バグ密度を結論部とする場合には、基準化標準偏差が1よりも大きくなっていれば、前提部にバグ密度のばらつきを大きくする原因が含まれている可能性がある。

以下の機能をもつNEEDLEというツールを開発しています。

• CSV データファイルからアソシエーションルールを抽出することができます．


• 結論部となる項目を指定することができます．


• 抽出したアソシエーションルールを評価する 3 つの指標(支持度，信頼度，リフト値)を算出します．


• 「購入した/していない」の2値だけではなく，多値を扱うことができます．


• データ項目が実数 (量的変数)となる項目を扱うことが可能です．


• 複数の条件を and と or でつなげることができます．


• 結論部となる項目が実数値 (量的変数)の場合，平均値と標準偏差を計算します．