情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

大規模 OSS 開発における不具合修正時間の短縮化を目的としたバグトリアージ手法
柏 祐太郎1,a)

大平 雅雄1,b)

阿萬 裕久2,c)

亀井 靖高3,d)

受付日 2014年5月19日, 採録日 2014年11月10日

概要：本論文では，大規模 OSS 開発における不具合修正時間の短縮化を目的としたバグトリアージ手法を提案する．提案手法は，開発者の適性に加えて，開発者が一定期間に取り組めるタスク量の上限を考慮している点に特徴がある．Mozilla Firefox および Eclipse Platform プロジェクトを対象としたケーススタ
ディを行った結果，提案手法について以下の 3 つの効果を確認した．(1) 一部の開発者へタスクが集中するという問題を緩和できること．(2) 現状のタスク割当て方法に比べ Firefox では 50%（Platform では誤差が大きすぎるため計測不能），既存手法に比べ Firefox では 34%，Platform では 38%の不具合修正時間を削減できること．(3) 提案手法で用いた 2 つの設定，プリファレンス（開発者の適性）と上限（開発者が取り組むことのできる時間の上限）が，タスクの分散効果にそれぞれ同程度寄与すること．
キーワード：バグトリアージ，大規模 OSS 開発，0-1 整数計画法

A Bug Triaging Method for Reducing the Time to Fix Bugs
in Large-scale Open Source Software Development
Yutaro Kashiwa1,a)Masao Ohira1,b)Hirohisa Aman2,c)Yasutaka Kamei3,d)Received: May 19, 2014, Accepted: November 10, 2014

Abstract: This paper proposes a bug triaging method to reduce the time to ﬁx bugs in large-scale open
source software development. Our method considers the upper limit of tasks which can be ﬁxed by a developer in a certain period. In this paper, we conduct a case study of applying our method to Mozilla Firefox
and Eclipse Platform projects and show the following ﬁndings: (1) using our method mitigates the situation
where the majority of bug-ﬁxing tasks are assigned to particular developers, (2) our method can reduce up to
50%–83% of time to ﬁx bugs compared with the manual bug triaging method and up to 34%–38% comparedwith the existing method, and (3) the two factors, Preference (adequate for ﬁxing a bug) and Limit (limitsof developers’ working hours), used in our method have an dispersion eﬀect on the task assignment.
Keywords: bug triage, large-scale open source development, 0-1 integer programming

1. はじめに
1
2
3
a)
b)
c)
d)

用工程においても多数の不具合が検出される．多くの場
合，不具合管理システムを用いて，不具合の再現方法や修近年の大規模システム開発では，試験工程だけでなく運正方法を詳細に記録し，不具合は漏れのないように管理さ

和歌山大学
Wakayama University, Wakayama 640–8510, Japan
愛媛大学
Ehime University, Matsuyama, Ehime 790–8577, Japan
九州大学
Kyushu University, Fukuoka 819–0395, Japans141015@sys.wakayama-u.ac.jp
masao@sys.wakayama-u.ac.jp
aman@cs.ehime-u.ac.jp
kamei@ait.kyushu-u.ac.jp

れる．不具合管理システムに報告された不具合 1 つ 1 つに

c 2015 Information Processing Society of Japan

対して，重要度や優先度を設定し，開発者に修正タスクを割り当てることをバグトリアージと呼ぶ [1]．
しかしながら，大量に不具合が報告される現状では，個々の不具合に対して適切にバグトリアージを行うことは容易ではない．実際，大規模オープンソース開発プロ
ジェクトの Eclipse や Mozilla では，約 4 割の不具合に669

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

対して，担当者の再割当てが行われており [2]，人手によついて説明し，5 章で実験の結果を示す．6 章では，実験るバグトリアージには限界があることが知られている．

結果と追加実験の結果に基づいて提案手法の適用範囲およ

担当者の再割当ては，人的リソースを浪費するだけでは

び妥当性について考察する．最後に 7 章でまとめと今後のなく，不具合の修正作業を滞らせるため，できる限り生

課題について述べ，本論文を結ぶ．

じないようにすることが望ましい．そのため現在，バグトリアージを支援するための研究がさかんに行われてい2. バグトリアージ
2.1 現状のバグトリアージにおける問題点

る [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]．
先行研究で提案されている手法のほとんどは，個々の不OSS 開発におけるバグトリアージは一般に，Bugzilla な具合に対して確実かつ迅速に修正できる開発者を推薦する

どの不具合管理システム（BTS: Bug Tracking System）をことを目的としている．過去の不具合報告とその修正履歴

用いて行われる．BTS の管理者は，プロジェクトに所属すに基づいて，新規に報告された不具合に対して適任の担当

る多数の開発者から当該不具合を修正するのに適任の開発者を推薦することで，再割当てを起こしにくくすることが者を決定し，不具合修正タスクを割り当てる必要がある．

狙いである．しかし，既存手法は，個々の不具合修正の難

しかし，多くの場合，BTS 管理者が最初に割り当てた開発

易度や手間を考慮しないため，ごく一部の開発者にタスク

者では不具合を修正できずに，担当者を変更（再割当て）し割当てを集中させる傾向にある．優秀な開発者でも不具合て不具合が修正されている．担当者の再割当ては不具合が修正に取り組める時間は有限であるため，既存手法は現実

最終的に修正されるまでの時間を大きく滞らせる [12]．そ的でないと考えられる．

のため，近年の大規模 OSS 開発では，再割当ての頻発がプ

そこで本研究では，0-1 整数計画法に基づく不具合修正

ロジェクト全体としての不具合修正の長期化を引き起すとタスクの割当て手法を提案する．不具合の割当て問題を，いう問題がある [2]．実際，Eclipse や Mozilla では，約 4 割

開発者と不具合の組合せ問題としてとらえ，個々の開発者の不具合に対して担当者の再割当てが行われており，1 度のタスク量に制約条件を課することでタスク割当てを最適の担当者の変更で修正時間が平均約 50 日遅れるとされてい化し，プロジェクト全体としての不具合修正活動の効率化

る [2]．再割当てによる不具合修正時間の長期化は，大規模を目指す．本論文では，以下の Research Question に取り

OSS プロジェクトにおいて解決すべき喫緊の課題であると組み，提案手法の有用性について議論する．

されており，バグトリアージを支援する手法がこれまで多RQ1：既存手法は，特定の開発者へ負荷を集中させる傾向

数提案されてきた [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]．

があるか？ 提案手法ではその問題を緩和できるか？

代

表的な既存のバグトリアージ手法 [3] を用いて，既存手法

2.2 既存のバグトリアージ手法とその問題点

が一部の開発者にタスクを集中して割り当てる可能性があ

既存のバグトリアージ手法の目的は，担当者の再割当てることを確かめる．また，提案手法を用いることでタスクが頻発しないようにあらかじめ最も適任と思われる開発者集中を緩和できることを確かめる．

にタスクを割り当てることである．既存手法は主に，機械

RQ2：提案手法は，プロジェクト全体の不具合修正時間

学習に基づく方法を採用している [1], [3], [6]．具体的には，の短縮化に寄与するか？ 0-1 整数計画法に基づくタスク

開発者が不具合報告に記述したタイトルと概要からなるテ

割当ての最適化により，プロジェクト全体として不具合修

キストデータを入力として，各開発者が過去に用いた単語

正時間を短縮できるかどうかを実験的に検証する．すなわの出現頻度を算出し，機械学習のアルゴリズム（たとえばち，一部の開発者へのタスク集中を緩和することが，プロSVM [13]）を適用することで，各不具合に対して開発者をジェクト全体の不具合修正活動を効率化できることを示す．

推薦するためのモデルを得る．構築したモデルに従うこと

RQ3：提案手法で用いる各種設定が，タスク割当ての最で，比較的高精度（約 70–75%程度）に新規に報告された

適化にどのように寄与するか？ 提案手法の特徴は主に，不具合の修正に対応可能な開発者を推薦できる [3]．

(1) 不具合に対する開発者の適性（プリファレンス）を数値

しかしながら，1 章でも述べたように，既存手法は，一定化し，適性の高い不具合をできるだけ多く割り当てること期間内に開発者が不具合修正に取り組める時間を考慮しなと，(2) 一部の開発者にタスクが集中するのを避けるため

い．また，個々の不具合修正の難易度や手間を考慮しない．

に，一定期間内に修正可能な不具合の数に上限を設けるこ

そのため，必ずしも有能な開発者が担当する必要のない軽とにある．プリファレンス有無，上限の有無により 4 つの微な不具合であっても，優先して有能な開発者に割り当てモデルを構築し，修正時間短縮化の効果を詳細に調べる．

る可能性が高い．結果として，既存手法は一定期間内に取以降，2 章では，バグトリアージ支援に関する関連研究

り組むことのできるタスク量を超えて一部の有能な開発者について紹介し，本研究との違いを明らかにする．3 章でにタスク割当てを行う恐れがある．有能な開発者以外の開は，0-1 整数計画法に基づくバグトリアージ手法を提案す

発者にも対応可能な軽微な不具合を，その他の開発者へ分

る．4 章では，提案手法の有用性を確認するための実験に散して割り当てることで，プロジェクト全体としての不具

c 2015 Information Processing Society of Japan

670

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

表 1

合修正活動をさらに効率化できる余地があるといえる．

本論文で用いる用語一覧

Table 1 Terms used in this study.

3. 不具合修正時間の効率化を目的としたバグ
トリアージ手法

用語
カテゴリ

記号

k

本研究では，開発者が一定期間内に修正可能な不具合に意味
不具合票の「コンポーネント」と「優先度」で分類したもの．
修正タスクをどの開発者に優先的に割り当てる

関する上限を設けたうえで，プロジェクト全体の不具合修
正効率にとって最適となる開発者と不具合の組合せを求め

プリファ

る新たなバグトリアージ手法を提案する．そのアプローチ

レンス

べきかを示す尺度．Pij とは開発者 Di がカ

Pij

テゴリ k の不具合修正タスク Bj に対するプ
リファレンスを示している．
Pij = カテゴリk における開発者Di の修正数
カテゴリk における修正タスクの総数

として，本研究では，不具合と開発者の組合せ問題をナッ
プサック問題と見なす．ナップサック問題とは，重みと利開発者 Di が不具合修正タスク Bj に要する得を持つ複数のアイテムを，最大重量が決まっているナッ
コスト

Cij

である．本研究では，ナップサックをプロジェクト全体の上限

L

修正能力の上限，アイテムを不具合，重みを不具合の修正

割当て可に要する時間，利得を不具合に対する開発者の適性を数値

能時間

プサックに入れる際に，ナップサックに入れたアイテムの時間．過去に開発者 Di がカテゴリ k の不具合修正タスクを完了するのに要した修正時間の中央値とした．

総価値が最大となるようなアイテムの組合せを求める問題

タスクの集中を防ぐために設定する値
一定期間内に修正可能なタスク量（時間）．

Ti

化したもの（プリファレンス）として考え，ナップサック

Ti は開発者 Di の担当可能時間を示す．
Ti = 上限 L− n
j=1 Cij ∗ xij

問題の解法である 0-1 整数計画法 [14] を用いる．
式 (2)，(3) の制約の下で式 (1) の値が最大となる xi の組

3.1 0-1 整数計画法

合せを見つけ出すことがナップサック問題の目的である．

0-1 整数計画法は，与えられた条件の下で目的を達成するためにより良い解を求める方法であり，ナップサック問定式化された 0-1 整数計画問題は，lp solve *1 といったソルバで容易に解くことができる．

題の解法として知られている．0-1 整数計画法に代表される数理計画法は，近年の計算機の発達により改めて注目さ

3.2 0-1 整数計画法に基づくタスク割当て

れている最適化手法であり，生産問題やスケジューリング

3.2.1 用語定義
まず，以降の議論を円滑に行うために，本論文で用いる問題といったオペレーションズリサーチ分野をはじめとして，ソフトウェア工学の分野でも応用され始めている [15]．

用語を定義する．表 1 には，用語の一覧をまとめる．

ナップサック問題は以下の 0-1 整数計画問題として定式化

カテゴリ（タスクの分類）：本研究では，開発者 Di （i =できる．

1, 2, . . . , m）には，不具合修正タスク Bj （j = 1, 2, . . . , n）

Maximize :Subject to :

n

i=1
n


に対する適性が存在すると想定する．そこでまず，個々の

vi xi

(1)

wi xi ≤ c(2)

修正タスクをカテゴリ k として分類する．カテゴリ k は，
不具合票の「コンポーネント」と「優先度」で定義される．

i=1

xi ∈ {0, 1}(i = 1, 2, . . . , n)

たとえば，対象コンポーネントを “UI” とする不具合票が2 件あり，それぞれ優先度が “P1” と “P5” とされている(3)

場合は別々のカテゴリの修正タスクとして区別される．同

ここで vi および wi はそれぞれ i 番目のアイテムの利得と様に，同じ優先度であってもコンポーネントが異なる場合

重みを表している．xi は目的変数と呼ばれ，ナップサック

は，別カテゴリとして区別される．修正タスクの分類にコ問題の解である．ここでは，そのアイテムを選択するか否

ンポーネントと優先度を用いる理由は，不具合修正時間がか（選択しない：0，選択する：1）を表している．式 (1) はコンポーネントと優先度に依存することを示した先行研究

目的関数と呼ばれ，この値の大きさで前述の目的変数の組の知見によるものである [16]．ただし，通常 5 段階で表現

合せが他の組合せよりも良いものかどうかを判断できる．

される優先度は，デフォルトの “P3” が用いられる場合がナップサック問題における目的関数は選択されたアイテム

非常に多いため，本研究では，優先度が “P1” と “P2” をにおける利得の総和を表し，この値を最大化することを目

優先度 “高”，“P3” を優先度 “中”，“P4” と “P5” を優先度的とする．一方，式 (2) は重量制限を表した制約条件であ“低” とし 3 段階に分けた．

り，選択されたアイテムの総重量が最大重量（c）以下でな

プリファレンス（開発者の適性）：0-1 整数計画法の目的関ければならないことを表している．式 (3) はすでに述べた数では，目的変数に係数を設定する．本研究では係数としxi に関する制約であり，この値が 0 または 1 のいずれかして，プリファレンス P を用いる．プリファレンスとは，修か許されないことを示している．

*1

c 2015 Information Processing Society of Japan

Ip solve 5.5: http://lpsolve.sourceforge.net/5.5/

671

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

xij ∈ {0, 1}(5)

目的関数：各不具合に対する各開発者のプリファレンスと目的変数の積の総和を最大化する．個々の開発者の適性に合うタスクがプロジェクト全体として最大となるような組合せを求めることを意味する．

Maximize :図 1 修正可能なタスク量（時間）の求め方

m 
n


Pij xij(6)

i=1 j=1

Fig. 1 The amount of available time for bug ﬁxes.

制約条件：本研究では，目的関数に対する制約条件として，

正タスクをどの開発者に優先的に割り当てるべきかを示す尺度である．本研究では，カテゴリ k の修正タスクの総数に対する開発者 Di の修正実績数の比をプリファレンスとする．たとえば，“UI” コンポーネントを対象とする優先
度 “高” の修正タスクが過去に 10 件存在し，そのうち，開発者 Di が 5 件を担当したことがあれば，開発者 Di に対するカテゴリ k （U I∗ 高）の不具合 Bj のプリファレンス

Pij は，0.5 として計算される．

以下の 2 つを課する．式 (7) は，一部の有能な開発者にタスクが集中するのを防ぐための制約である．式 (8) は，同一の不具合を複数人の開発者が同時に修正することを避けるための制約である．

• 各開発者に割り当てるタスクに要するコストの合計は割当て可能時間を超えないことnCij xij ≤ Ti

(i = 1, 2, . . . , m)

(7)

j=1

上限：開発者が一定期間内に修正できるタスク量には限りがあると考えるのが自然である．本研究では，開発者 Diが一定期間に修正可能なタスク量（時間）を考慮した不具合の割当てを行う．図 1 は，修正可能なタスク量の求め方を示した概略図である．修正可能なタスク量は割当て可能
時間 Ti から求める．また，割当て可能時間 Ti は，あらか• 1 つの不具合を担当する開発者は 1 人以下であることm
xij ≤ 1
(j = 1, 2, . . . , n)(8)i=1

3.3 提案手法の適用手順
提案手法の適用手順は以下のとおりである．

じめ設定する上限 L（日）と，新規の修正タスク割当て時

Step 1：パラメータの設定 手法の適用前にあらかじめ点ですでに開発者 Di が担当している不具合のコスト Cij

上限 L を設定する．L の値で各開発者の修正可能時間 Ti

から求める．コスト Cij は，開発者 Di が不具合修正タスを初期化する．

ク Bj に要する時間で，過去に開発者 Di がカテゴリ k のStep 2：プリファレンスとコストの算出 開発者 Di がカ

不具合修正タスクに要した時間の中央値とした．

テゴリ k の不具合修正タスク Bj に必要なコスト Cij とプ

新規に割り当てる修正タスクのコストの合計が Ti を超え

リファレンス Pij をすべて算出する．

ないようにすることで，特定の開発者へ修正タスクが極端

Step 3：割当て待ち不具合の追加 前回の割当てを行っに集中するのを防ぐ効果を期待できる．なお，上限 L はプ

た日から今回の割当てを行う日までに報告された不具合をロジェクトによって大きさを変えることができる．また，割当て待ち不具合として待機させる．

本論文の実験においては，全開発者に対して同じ上限 L を

Step 4：0-1 整数計画法の適用 前節で述べた 0-1 整数計

設定することを想定しているが，実際の運用においては，画法を用いて，割当て待ち不具合を開発者に割り当てる．

一定期間内に不具合修正取り組むことのできる時間は開発

割り当てられた不具合は割当て待ち不具合から外す．

者ごとに異なるものと思われる．その場合は，上限を開発

Step 5：Ti の更新 Step 4 で割り当てられてた不具合の者ごとに設定（上限 Li ）することも可能である．

コスト分だけ各開発者の修正可能時間 Ti を減らす．

なお，先行研究 [6] と同様に，過去の修正タスクに要し（n 日後）まで時間を進め，各開発者の Ti を n（日）増やた個々の修正時間は，以下の式から求めた．
修正日数 = 修正完了日時 − 割当て日時 + 1 日(4)*ただし，小数点以下は切り捨てる

3.2.2 定式化
本研究では目的変数，目的関数，制約条件を次のように定義する．
目的変数：xij とは，開発者 Di に不具合 Bj を担当させるかどうかを表し，0 の場合は開発者 Di に不具合 Bj を割り当てないことを，1 の場合は割り当てることを意味する．

c 2015 Information Processing Society of Japan

Step 6：次の割当て日に進む（Step.2 へ） 次の割当て日
す．ただし，n（> 0）の値はタスク割当ての状況やニーズ
によって決まるものであり，一意に定めることは難しい．
本論文では議論の一般性を損なわないよう，n は本提案手法の利用者が任意に決定できる自然数であるとする．また，

Ti は Step 1 で設定した L より大きくしない．次に Step 2に戻り，Step 2 から Step 6 を繰り返す．

4. ケーススタディ
本章では，Research Question に取り組むために行った672

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

表 2 データセット

Table 2 Data sets.
プロジェクトFirefox
Platform

解決済み

対象不具

コンポー

カテゴリ

不具合（件）

合数（件）

ネント数

リー数

2002/10/1〜2011/9/30

10,165

2,536

28

60

評価データ

2011/10/1〜2012/9/30

1,648

659

31

39

学習データ

2002/10/1〜2011/9/30

21,802

1,910

19

28

評価データ

2011/10/1〜2012/9/30

932

578

17

23

データセット期間

学習データ

表 3 各フィルタリングにおける不具合数

Table 3 Number of bugs in each ﬁltering step.
Firefox
フィルタリング

Platform

学習データ

評価データ

学習データ

評価データ

A

各プロジェクトから収集した不具合

105,294

11,76578,8563948

B

A のうち修正時間および修正者が特定でき，かつ修正された不具合

10,165

1,648

21,802932

C

B のうち，不具合の修正時間が外れ値になっていない不具合

8,699

1,496

18,370871

D

C のうち，アクティブ開発者が修正した不具合

2,536

659

1,910

578

表 4

データセットに含まれるアクティブな開発者

Table 4 The number of active developers in the data sets.
プロジェクト図 2 不具合修正時間のヒストグラムと統計量

Fig. 2 Histograms and statistic of the bug ﬁxing-time.

全開発者

アクティブ開発者

Firefox734

21

Platform

301

23

べての開発者を対象としてタスク割当てを行うのは現実的でない．また，すべての開発者が活発に不具合修正を行っているわけではない [16] ため，修正タスクを担当できる見ケーススタディについて述べる．

込みのある開発者のみにタスクを割り当てる必要がある．
そこで本研究では，評価データの最初の日，つまり 2011

4.1 準備年 10 月 1 日を基準とし，半年以内に 6 回以上（1 カ月に

4.1.1 データセット

1 回程度を想定）の修正タスクを完了させた開発者を「ア

本論文では，2 つの大規模 OSS プロジェクト（Mozilla

クティブ開発者」と定義し，タスク割当ての対象とする

Firefox，Eclipse Platform）を対象にしたケーススタディ（表 4）．なお，タスク割当ての精度を保証するために，対を行う．両プロジェクトは既存研究の多くが分析対象とし象の開発者以外が修正した不具合報告はデータセットからており [1], [2], [3], [4], [6], [8], [16]，本ケーススタディで得除外した．

られる結果の妥当性を確保できる．

本ケーススタディでは，2002 年 10 月 1 日〜2011 年 9 月

表 2 にケーススタディで用いるデータセットの概要を，

31 日の間に報告された不具合を学習データ，データセット

表 3 にデータセット作成時に行ったフィルタリングの一の最後の 1 年である 2011 年 10 月 1 日〜2012 年 9 月 30 日

覧を，図 2 にデータセットの不具合の修正時間のヒストグの間に報告された不具合を評価データとして，既存手法おラムと統計量を示す．各プロジェクトから収集した不具合

よび提案手法を比較する．

データのうち，修正時間および修正者が特定でき，かつ，

4.1.2 実験の手順

修正（FIXED）された不具合のみを用いている（図 2 では

本ケーススタディでは，既存手法および提案手法により解決済み不具合に該当する）．なお，不具合報告の中には，タスクを割り当てる実験を行い，得られた割当て結果を用数年間放置された後に修正されるものも存在するため，不いて修正時間を算出する．実験の概要を図 3 に示す．

具合の修正時間の分布を箱ひげ図で確認し，外れ値となる
不具合はデータセットから除外している．

本実験では，実験上の日付を用意し，その日付に従って不具合報告を再現する．不具合データには報告日時が記さ

本ケーススタディでは，既存手法および提案手法によりれており，報告日時が実験上の日付と同じであれば報告さ修正タスクを開発者に割り当てる実験を行うが，OSS プロ

れたと見なし，該当する不具合を提案手法および既存手法

ジェクトの開発者は比較的短期間でプロジェクトを去るこで割り当てていく．該当する不具合の割当てが済めば，実とが知られている [17] ため，各プロジェクトに在籍したす験上の日付を進め，再び該当する不具合の割当てを繰り返

c 2015 Information Processing Society of Japan


673

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

図 4

全期間における各開発者の修正日数（既存手法 vs. 提案手法）

Fig. 4 Distribution of the total cost of assignments by devel図 3 実験の概要

oper in the testing sets.

Fig. 3 An overview of the experiment.

す．本実験では 365 日分の割当てを行う．
すべての日数分の割当てが終了すると，次に修正時間の算出を行う（図 3 右）．提案手法および既存手法を用いると，実際に修正した開発者に割り当てられないことがある．
その場合は実際の修正時間が算出できないため，学習デー

図 5タから個々の開発者における各カテゴリの不具合の修正時

Fig. 5 Distribution of the total cost of assignments by devel-間の中央値を求め（すなわち，コスト Cij ），実験上の修正

繁忙期における各開発者の修正日数（既存手法 vs. 提案手法）

oper in a busy time of year.

時間として使用する．

4.1.3 実験環境と設定
本ケーススタディでは，0-1 整数計画法を用いてタス
ク割当て問題の解を求めるために，オープンソースの数
理計画ソフトウェアである lp solve5.5.2.0 を用いた．また，CPU：Intel Core i7 2.30 GHz，OS：CentOS 6.2，メ
モリ：2 GB の計算機を用いて実行した．
提案手法を適用するためには，あらかじめ上限 L と，次回の割当て日までの間隔（3.3 節 Step 6 の n）を設定する必要がある．本研究ではデータセットに含まれる不具合の修正に要した時間の第 3 四分位値を求め，その値を切り上げた値とし，Firefox では L = 10，Platform では L = 9 と設定し，n は 1 日とした．また，既存手法には，Anvik らの機械学習に基づくバグトリアージ手法のうち，最も精度期間を用いて，既存手法と提案手法によるタスク割当ての結果を比較する．繁忙期を設定した理由は，タスク量の上限を考慮しない既存手法と上限を考慮する提案手法とで，割当て結果に顕著な違いが見られると考えたためである．
結果：図 4 および図 5 はそれぞれ，テストデータにおける全期間および繁忙期に各アクティブ開発者が取り組んだ
タスク量（修正日数）を示している*2 ．また，図中の削減
日数（折れ線グラフ）は提案手法が既存手法と比較し，削減できた修正日数を示している．なお，既存手法と提案手
法とでは開発者に割り当てるタスク数が異なるため，図中に示した結果は，両手法で共通に割り当てられたタスクから修正時間を算出し比較したものである（割当て結果の詳細については表 5 を参照されたい）．
図 4 の全期間での比較では，既存手法を用いた場合，の高い推薦を行える SVM ベースの手法 [3] を用いた．
また，提案手法の適用手順（3.3 節）では Step 6 の後にStep 2 に戻り，コストとプリファレンスの再計算を行う．
本実験において再計算を行うことは，評価データを学習
データに追加して実験を続けていくことになる．これにより他の手法と実験環境が同じでなくなり，比較結果に影響を与える恐れがある．そこで本実験では Step 6 において，Step 2 に戻るのではなく Step 3 に戻ることとする．

Firefox では 2 人の開発者に合計で設定期間（365 日）以上を要するタスクが割り当てられており，一部の開発者に多くの負荷がかかっていることが見て取れる．また，

Platform においても 1 人の開発者に設定期間に近いタス
クが割り当てられている．図 5 の繁忙期では，Firefox で

2 人，Platform で 1 人の開発者に合計で設定期間（31 日）
以上を要するタスクが割り当てられている．
一方，提案手法を用いた場合，全期間と繁忙期の両期間

4.2 実験と結果
RQ1：既存手法は，特定の開発者へ負荷を集中させる傾向があるか？ 提案手法ではその問題を緩和できるか？
動機：既存手法は一部の有能な開発者に集中して修正タス
クを割り当てる可能性がある．既存手法と提案手法で一部において，開発者間でタスク量のばらつきは見られるものの，設定期間以上のタスク割当ては生じていない．また，提案手法を用いることで，既存手法において負荷が大きい
開発者ほど，修正日数が大きく削減されている（右側の縦軸）ことが分かる．
これらの結果から，提案手法は開発者が修正できるタスの開発者に修正タスクが集中しすぎないかどうかを確認する．
アプローチ： テストデータにおける全期間（365 日間）と不具合報告の最も多かった月（繁忙期：31 日間）の 2 つのc 2015 Information Processing Society of Japan

ク量を考慮して不具合割当てを行っており，一部の開発者*2

横軸の番号は，開発者のタスク量（修正日数）を降順に並べたときの順番を表すものであり，開発者を特定するものではないことに注意されたい．図 4 および図 5 以外の結果も同様である．

674

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

表 5

現状の割当て方法，既存手法および提案手法によるタスク割当て結果の比較

Table 5 Comparison of task assignments between the three methods.
Firefox

プロジェクト割り当てた不具合（件）割り当てた開発者（人）合計修正日数（日）手法

現状の割当て方法

共通化前

659

Platform

既存手法

提案手法

現状の割当て方法

439

440

578

377

共通化後

既存手法

提案手法

386

572

385

共通化前

16

17

18

20

19

12

共通化後

16

15

18

20

19

11

共通化前

5,816

3,091

1,685

4,893

995

901

共通化後

2,920

2,220

1,471

3,433

967

599

へタスクが集中するのを緩和できるといえる．

RQ2：提案手法は，プロジェクト全体の不具合修正時間の表 6 条件の有無による 4 つのモデル

Table 6 Four models with and without P and L.
L：なし

L：あり

モデル A：プリファレン

モデル B：上限を設定し短縮化に寄与するか？
動機：RQ1 の結果から，提案手法は既存手法に比べ，特定の開発者へのタスク集中を緩和できることが分かった．しかし，プロジェクト全体の不具合修正時間を短縮化できな

スと上限を設定せず，修正 た条件下で，修正時間の短
P ：なし 時間の短い開発者に不具 い開発者に不具合を優先
合を優先的に割り当てる的に割り当てるいのであれば，タスク割当てを分散させる意義が薄れてしモデル C：プリファレン

モデル D：上限を設定しまう．そこで，提案手法がプロジェクト全体の不具合修正

スのみ設定し，カテゴリごた条件下で，プリファレン

時間を短縮化できるかどうかを検証する．

P ：あり とのプリファレンスが高 スの合計が最大となるよアプローチ：現状のタスク割当て（OSS プロジェクトで行い開発者にタスクを割りうに不具合を割り当てる

われている実際のタスク割当て）の修正時間，既存手法と当てる（提案手法）

提案手法で実験して得られた修正時間をそれぞれ比較する．
結果：表 5 に，現状の割当て方法による割当て結果，既存たプリファレンス P と上限 L が，タスク集中の回避にど手法および提案手法を用いた割当て結果を示す．前述したのように寄与するかの詳細については不明なままである．

とおり，それぞれの方法で割り当てられるタスクの数が異アプローチ：P の有無，L の有無により 4 種類のモデルをなるため，3 つの方法で共通して割り当てたタスクのみに構築し，それぞれのモデルを比較することで，タスク割当

した結果を「共通化後」として示している．比較のため，て問題におけるプリファレンスおよび上限の効果を調べる．

以下では共通化後の結果について議論する．

各モデルの特徴は，表 6 のようにまとめることができる．

Firefox では，プロジェクト全体としての合計修正日数

結果：表 7 に，各モデルを用いてタスク割当てを行った結は，現状の割当て方法で 2,920 日，既存手法で 2,220 日，

果を示す．以下では，P と L がタスク集中の回避にどのよ提案手法で 1,471 日となり，既存手法は現状の割当て方法

うに寄与したのかを，表 7 の結果から議論する．

に比べて約 24%，提案手法は現状の割当て方法に比べて約モデル A とモデル B との比較：プリファレンスを設定

50%の修正時間を削減できることが分かった．また，提案せず上限の有無のみで比較する．モデル A（L なし）に手法を用いた場合，既存手法に比べ約 34%の修正時間を削比べモデル B（L あり）のタスク割当て人数は，両プロ減できることが分かった．

ジェクトにおいて増加している（Firefox：1 人から 15 人，

Platform ではプロジェクト全体としての合計修正日数
は，現状の割当て方法で 3,433 日，既存手法で 967 日，提案

Platform：1 人から 14 人）．上限の設定はタスク割当てを分散させる効果があるといえる．

手法で 599 日となり，既存手法は現状の割当て方法に比べモデル A とモデル C との比較：上限を設定せずプリて約 72%，提案手法は現状の割当て方法に比べて約 83%のファレンスの有無のみで比較する．モデル A（P なし）に

修正時間を削減できることが分かった．また，提案手法を比べモデル C（P あり）のタスク割当て人数は，全プロ用いた場合，既存手法に比べ約 38%の修正時間を削減でき

ジェクトにおいて増加している（Firefox：1 人から 9 人，

ることが分かった．

Platform：1 人から 12 人）．プリファレンスの設定により，

RQ3：提案手法で用いる設定（プリファレンスと上限）が，修正実績数だけではなく修正タスクへの開発者の適性が反タスク割当ての最適化にどのように寄与するか？

映される．上限の設定と同様に，プリファレンスの設定は

動機：RQ2 より，提案手法がプロジェクト全体の不具合修

タスク割当てを分散させる効果がある．

正時間の短縮化に効果があることが分かった．しかし，修モデル B とモデル D との比較：上限を設定したうえで，正タスクに対する開発者の適性と，一定期間内に開発者がプリファレンスの有無で比較する．モデル B（P なし）に比取り組めるタスク量の上限を考慮するためにそれぞれ用いべモデル D（P あり）のタスク割当て人数は，Firefox では増

c 2015 Information Processing Society of Japan


675

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

表 7 モデルごとのタスク割当ての結果

Table 7 Comparison of task assignments between the four models.
Firefox

プロジェクト割り当てた不具合（件）割り当てた開発者（人）合計修正日数（日）Platform

モデル

A

B

C

D

A

B

C

D

適性

無

無

有

有

無

無

有

有

上限

無

有

無

有

無

有

無

有

共通化前

659

659

559

440

578

578

575

572

共通化後

440

440

440

440

572

572

572

572

共通化前

1

15

10

18

1

14

12

12

共通化後

1

15

9

18

1

14

12

12

共通化前

4,284

3,066

4,897

1,685

5,780

1,186

997

901

共通化後

2,860

2,022

2,115

1,685

5,720

1,174

910

901

加し，Platform では割当て人数が減少した．
（Firefox：15
人から 18 人，Platform：14 人から 12 人）．上限が先に設定されている場合は，プリファレンスの設定はタスクの分散に必ずしも有効ではない．
モデル C とモデル D との比較：プリファレンスを設定し，上限の有無で比較する．モデル C（L なし）に比べモデル D（L あり）のタスク割当て人数は，Platform では変

図 6 提案手法を用いた割当て結果（繁忙期 vs. 閑散期）

Fig. 6 Assignment results (busy vs. less busy period).

化はなかったが，Firefox では増加している（Firefox：9 人から 18 人，Platform：12 人から 12 人）．モデル D では，割り当てられる開発者の数は，両プロジェクトで共通して，

プリファレンスの設定に加え，上限の設定により，さらに繁忙期に比べて閑散期の方が少ないことが見て取れる．まタスク割当てを分散できたことを示している．プリファレ

た，繁忙期に比べて閑散期では，修正日数のばらつきが大ンスを設定したうえで，上限を設定することはタスク分散

きいことが見て取れる．

の効果を高める可能性がある．

図 6 のような結果になった理由は次のように考えられ以上の結果から，プリファレンスおよび上限の設定は，る．閑散期には，開発者に割り当てられるタスク量が上限

タスク割当ての分散に効果がある．特に上限の設定がプリL に達しない．そのため，従来手法と同様，最も適任の開ファレンスの設定よりタスクの分散に大きく寄与する．

発者にのみタスクを割り当てることができる．一方，繁忙

5. 考察
5.1 提案手法の適用範囲

期には，開発者に割り当てられるタスク量が上限 L に達する開発者が多いため，上限 L を超える分のタスクが次に適任の開発者に分散して割り当てられる．

本研究ではプロジェクト全体での不具合修正時間の短縮

これらの結果から，閑散期に提案手法を適用する場合に化を目的とするバグトリアージ手法を提案した．しかし，は，最も適任の開発者にのみタスクを割り当てるという，

OSS 開発では，時期ごとに不具合の報告量や開発者数，不従来のバグトリアージ手法と同様の利点があり，繁忙期に具合修正に要する時間は異なるため，提案手法がプロジェ提案手法を適用する場合には，プリファレンスが大きい開クトのあらゆる状況に適しているとは限らない．本節で発者を中心にタスクを割り当てつつ残りのタスクをその他

は，提案手法がどのような状況に適しているかを，追加分の開発者に分散させることで開発者の負荷状況をコント

析の結果とともに考察する．

ロールできるといえる．したがって，繁忙期と閑散期が存

5.1.1 不具合報告状況への対応

在するプロジェクト（たとえば，メジャーバージョンのリ提案手法は，特定の開発者へタスクが集中するのを回避

リースの前後で不具合報告数が大きく増減するプロジェク

しつつ，可能な限り適任の開発者にタスクを割り当てる．

トなど）において，提案手法は特に有用であると考える．

プロジェクトへ報告される不具合が多い状況と少ない状況

一方，いずれの開発者も上限 L に達することのないようなとで，開発者の負荷がどのように変化するかを確認する．

小規模プロジェクトにおいては，開発者推薦の精度のみを

図 6 は，不具合報告の最も多かった月（繁忙期 31 日間）

追求した従来のバグトリアージ手法（文献 [3] など）の利と，最も少なかった月（閑散期 31 日間）のそれぞれで，各用が適していると思われる．

開発者に割り当てられたタスクの量（修正日数）を示した

5.1.2 開発者の負荷状況への対応グラフである．なお，提案手法によりタスクが割り当てらケーススタディでは，上限 L の大きさをデータセットにれなかった一部の開発者は図から省略している．タスクを含まれる不具合修正時間の第 3 四分位値（Firefox では 10

c 2015 Information Processing Society of Japan


676

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

図 8 L の大きさと割り当てた不具合数および合計修正日数の関係

Fig. 8 Relationship among L, assignments, and ﬁxing-time.
表 8 コスト算出方法の妥当性の検証
図 7 L の大きさ別割当て結果

Table 8 The total costs (actual vs. simulated data).

Fig. 7 Assignment results of the size of L.

日，Platform では 9 日）として固定した．上限 L の大きさ

現状の割当て方法実験

差Firefox

4,451

4,660

−209

Platform

4,787

1,982

2,806

によって開発者の負荷は大きく変わると考えられるため，

L の値を変化させてその効果を詳細に調べる．
図 7 は，上限 L の値を変化させたときの開発者のタス
ク量を示したものである．上限 L を大きくしたときの開発験で行ったような第 3 四分位を用いた機械的な設定ではな
く，過去の不具合修正タスクを調査して L を設定するのが望ましいといえる．

者のタスク量の変化は一様であったため，紙面の都合上，10，20，30（日）の値だけを示す．

5.2 修正時間算出方法の妥当性

Firefox では，L が大きくなるにつれて，タスク量の最もまず，修正時間の算出方法の妥当性について検証する．

大きい開発者とその他の開発者とのタスク量との差が小さ

表 8 は，現状の割当て方法で実際に要した不具合修正時くることが見て取れる．一方，Platform では，各開発者の間の合計と，現状の割当て方法で割り当てられた修正タス

タスク量は多少変化するものの，L の変化によりタスク量クを提案手法の修正時間算出方法（不具合修正のコストの分布は大きく変わらないという結果となった．

Cij ：開発者 Di がカテゴリ k の不具合修正タスク Bj を完

図 8 は，上限 L と割り当てた不具合数，合計修正日
数の関係を示したものである．図から見て取れるように，了するのに要した時間の中央値）で求めた不具合修正時間の合計とを比較したものである*3 ．

Firefox では，上限 L が大きくなるにつれ，割り当てた不まず，Firefox では，提案手法の方が約 209 日とやや大具合数および合計修正日数が増えるのに対し，Platform で

きく修正時間を算出しているものの，約 4%の誤差でありは，上限 L が大きくなっても，割り当てた不具合数には

修正時間の算出方法についてはおおむね妥当であったとい

ほとんど変化はみられない．また，合計修正日数についてえる．

も，Firefox ほどの大きな変動はみられない．Platform で一方，Platform では，提案手法の方が修正時間を 2,800は，多くのタスクのコストは L より小さいため，L を変日以上小さく見積もっている．同じ修正時間算出方法を用化させても一部の開発者に優先して割当てを行うという状いたケースステディにおいての既存手法と提案手法とを

況はあまり改善されないことが原因と考えられる．一方，比較した結果と結論自体には影響を与えないが，提案手

Firefox では，Platform に比べてタスクのコストが L より法を実際に Platform に適用する際には，本論文における大きい場合が多く，L を大きくすることで割当て可能な開修正時間の算出方法は大きな問題があるといえる．した発者が増えたと考えられる．

がって，RQ2 の結論は，“提案手法は，現状のタスク割当

以上の結果から，上限 L は本来，開発者への負担を加味て方法に比べ Firefox では 50%の不具合修正時間を削減でしながらプロジェクト管理者が決定すべきであるが，不具き（Platform では誤差が大きすぎるため計測不能），既存合修正に要するタスク量の分布によって，Firefox のよう手法に比べ Firefox では 34%，Platform では 38%の不具合に L を大きくすることが望ましいプロジェクトが存在する

修正時間を削減できることが分かった” とする．

ことが分かった．また，Platform のように，不具合修正に*3要するタスク量が小さいものが多くを占める場合は，L を大きくしても負荷分散の効果が得られない場合もあり，実c 2015 Information Processing Society of Japan

提案手法の修正時間算出方法に基づくため，現状の割当て方法で割り当てられたタスクの修正時間を計算できない場合がある．計
算可能なタスクのみを対象として比較しているため，表 8 の比較
結果は，表 5 の合計修正日数とは異なる数値が示されている．

677

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

Platform において修正時間の見積り誤差が大きくなった

同程度のコストであれば，優先度 “高” の不具合は，「優先

理由は，Platform では不具合修正時間の分散が大きかった的に」プリファレンスの高い開発者に割り当てられる可能ことに起因するものと考えている．図 2 で示したように，性が高い．これらのことから，本論文での実験結果に優先

Platform では，約 45%の不具合が 1 日以下で修正されて度は大きな影響を与えなかったと思われる．ただし，優先いる．一方，修正時間の平均値は 9.0 日（図 2）である．そ度の分布が均等なプロジェクトや優先度の低い不具合が大のため，不具合修正のコストが 1 日とした開発者を多く想半を占めるようなプロジェクトでは，提案手法を適用する

定することとなり，修正時間が過剰に短く算出されたもの

ことで前述の問題点が生じる恐れがある．提案手法をよりと思われる．前述した図 8 からも，コストの過小見積りが一般性の高いものにするためには，今後，優先度に重み付原因となって，L が小さな場合でもほとんどの不具合が割けを考慮するなどして，優先度の高い不具合がプリファレ

り当てられていることが見て取れる．

ンスの高い開発者に割り当てられることを保証する必要が以上から，Platform のようなコストの小さな不具合が多くを占めるプロジェクトでは，本論文で用いた修正時間算ある．

5.3.2 コストとプリファレンスのバランス

出方法には限界があるといえる．実験の精度向上および実提案手法の目的は修正時間の削減であるが，修正時間を際の適用を考えるうえで，修正時間（コスト）算出方法は最小化するようにコストを用いるのではなく，プリファレ

今後改良する必要がある．

ンスを最大化するように目的関数を定めている．提案手法は，コストに関する制約条件を設けることにより，プリ5.3 目的関数の改良

ファレンスの総和を最大化するためにプリファレンスが大5.3.1 優先度の重み付けの必要性

きくコストが小さい開発者に不具合を優先的に割り当て

提案手法は，不具合修正タスクを分類するカテゴリの作

る．これにより，直接的な修正時間の削減ではないが，修成において，不具合の優先度を 3 段階（高・中・低）に分

正時間を短くする効果がある．一方，目的関数にコストをけて用いるが，個々のタスクの割当てにおいては優先度を加味するようにした場合，直接的に修正時間を短くするこ考慮していない．そのため，優先度の低いタスクに対してとはできると考えられるが，比較的修正が容易な不具合の高いプリファレンスを有する開発者にタスク量の上限に達みを修正している開発者に，プリファレンスの小さな（適する程度にまで多数割り当てられた場合，その開発者には性の低い）不具合を多く割り当てる可能性が高まる．結果

優先度の高いタスクが割り当てられない場合が生じる可能

的に，再割当てを招く原因になると考えられる．実際の運性がある．タスク割当て自体にはタスクの優先度を考慮し用では，再割当てをある程度許容していても問題はない

ないという点が，実験での評価にどれほどの影響を与える

が，一般的に再割当ては修正時間を遅らせるため，本研究かを調べるために，表 9 にデータセットに含まれる不具ではまず，再割当てができるだけ発生しないようにするこ

合の優先度の分布を示す．過半数の不具合の優先度は “中”とを前提として修正時間の削減を目指した．目的関数におで，優先度が “高” と “低” の割合は小さいことが見て取れ

いて，再割当てが起きないようなコストとプリファレンス

る．多くの大規模 OSS プロジェクトでは，優先度の偏りのバランスがとれれば，さらなる修正時間の削減が見込めが顕著にみられることが知られており [16]，Firefox およびるため，目的関数を改良したバグトリアージ手法の構築を

Platform でも同様の傾向であった．特に，優先度 “低” の今後の課題としたい．

不具合の割合は非常に小さいため，前述したような状況は

5.3.3 学習データの量

ほとんど生じなかったものと考えられる．一方，Eclipse で本実験では，学習データとして 9 年分のデータを用いたは Firefox に比べ，優先度 “高” の不具合の割合は大きい．

が，修正の回数を重ねるとともに各開発者の役割や能力優先度が “高” の不具合に対処した開発者は相対的に少なが変わることも考えられる．ここでは，本実験で用いた学

いため，同じ開発者であれば，優先度 “高” が属するカテ

習データの期間が適切であったかを検証する．表 10 は，ゴリに対してのプリファレンスは，優先度が “中” のカテ

表 8 のコスト算出方法の妥当性の検証結果に学習データ

ゴリに対するプリファレンスよりも高くなる．そのため，のうち 2010 年 10 月 1 日から 2011 年 9 月 30 日の 1 年だ

表 9 各優先度における不具合の分布

表 10 学習データの期間の違いによる算出コストの誤差

Table 9 Distribution of bugs by priority.

Table 10 Diﬀerences of estimated costs.

Firefox
優先度

プロジェクトPlatform

Firefox

Platform

学習データ

評価データ

学習データ

評価データ

期間

全期間

1年

全期間

1年

高

33 (2%)

10 (2%)

404 (16%)176 (27%)

現状の割当て方法

4,451

4,451

4,787

4,787

中

1,876 (98%)

568 (98%) 2,060 (81%)

481 (73%)

実験

4,660

4,672

1,982

2,939

低

1 (0%)

2 (0%)

差

−209

−221

2,805

1,848

0 (0%)

c 2015 Information Processing Society of Japan

72 (3%)

678

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

けを用いた場合を追加したものである．最後の 1 年だけを実験を行っておらず，実験結果に与える影響は分かってい使った場合，全期間に比べて Firefox ではわずかながら誤ない．n の変化による実験結果に与える影響の測定および差が大きくなるものの（−209 日（4%）→ −221 日（5%）），

n の最適な大きさの議論は今後の課題とする．

Platform では誤差が小さくなった（2,805 日（58%）→ 1,848

5.4.3 不具合修正に求められるスキルと不具合修正時間日（38%））．なお，割り当てた不具合数に変化はなかった．

本論文では，各開発者は同じカテゴリの不具合を同程度

これらの結果から，提案手法を適用するプロジェクトに依の時間で修正できると仮定している．しかし，実際の不具存するものの，学習データは大きければ大きいほど良いと合修正では，同じカテゴリであっても不具合の症状は様々は限らないことが分かった．一方，直近の割当てトレンド

であり，不具合の修正に必要とされる知識やスキルは同じを反映するために直近のデータのみを学習データ用いる場と限らない．したがって，同じカテゴリの不具合でも少な合，コストが少数の不具合によって影響を受けやすくなる

からず修正時間が異なると考えられる．実際，5.2 節で示ため，必ずしも小さな学習データが良いとは限らない．学したように，Platform プロジェクトに対しては本研究で習データの量は，不具合の修正数やカテゴリ数に依存する用いた不具合修正時間には，大きな誤差があることを確認ため，今後の課題として，様々なプロジェクトを対象に，した．本論文では，不具合修正時間の算出根拠として，不学習データとテストデータの量の関係を検証し，提案手法

具合修正時間予測に関する先行研究 [12] から，予測モデル

が最も効果的に適用できるよう学習データの期間を設定の構築において重要な変数である開発者とカテゴリ（コンする方法を構築したい．なお，今回はコストのみの検証を

ポーネントと優先度）を用いた．しかしながら，文献 [12]

行ったが，プリファレンスでも同様に，学習データとテス

を含め，現状の不具合修正時間予測モデル（たとえば，文トデータの量のバランスについても今後検証する必要が

献 [18] や [19]）は必ずしも十分な予測精度があるとはいえある．

ないため，不具合修正時間の見積り精度の改善は，提案手法の有用性を向上させるうえでも重要な課題である．

5.4 制約5.4.1 共通後の割当て結果

5.4.4 割当ての自動化に際しての新たな仕組みの必要性
本手法ではアクティブ開発者を定義し，アクティブ開発

本論文では，Mozilla Firefox および Eclipse Platform プ

者のみにタスク割当てを行えるようにしている．実際の運ロジェクトを対象としたケーススタディを行い，提案手法

用では，アクティブでない開発者にも，修正が可能と思わの有用性を検証した．両プロジェクトにおいて提案手法はれる不具合を修正してもらう方が効率的である．そのた

既存手法に比べて，タスク集中の緩和とプロジェクト全体

め，アクティブ開発者ではない開発者が，アクティブ開発

としての不具合修正活動の効率化に効果があることが分

者に自動割当てされたタスクの中から自分が貢献できそうかった．提案手法の一般性を保証するためには，今後さらなタスクを判断し，アクティブ開発者からタスクを譲り受にプロジェクトの種類を増やして検証する必要がある．まけることを可能にする仕組みを作る必要がある．

た，本研究では主に，既存手法と提案手法の比較を目的としていたため，共通化後の不具合割当て結果に基づいて議

6. おわりに論を行った．しかしながら，既存手法および提案手法はと本研究では，大規模 OSS 開発における不具合修正時間

もに，現状の割当て方法に比べて割当て可能な（コストのの削減を目的としたバグトリアージ手法を提案した．提案算出が可能な）不具合の数自体は少なかった．今後は Park

手法は，0-1 整数計画法に基づいてタスク割当てを最適化

ら [6] のコスト算出方法を参考にするなどして，より実際する点に特徴がある．

に沿った割当てが行えるよう手法を改良する必要がある．

Mozilla Firefox および Eclipse Platform プロジェクトを

5.4.2 次回の割当て日までの間隔 n が与える実験への影響対象としたケーススタディを行った結果，提案手法につい実験では次回の割当て日までの間隔（3.3 節 Step 6 の n）
を 1 日とした．n を小さい値にすると，有用な開発者には早く報告された不具合がより配分されやすく，有用な開発て以下の 3 つの効果が確認できた．

• 特定の開発者へタスクが集中するという問題を緩和できる．

者が上限に達し，遅く報告された不具合はそれ以外の開発• 現状のタスク割当て方法に比べ Firefox では 50%（Plat-

者に割り当てられやすいというデメリットがある．そのデ

form では誤差が大きすぎるため計測不能），既存手法

メリットをふまえたうえ，実験で n を 1 日と設定した理由に比べ Firefox では 34%，Platform では 38%不具合修は，OSS 開発では管理者が毎日，不具合を開発者に割り当てている状況を最適化手法に置き換えることでどれくらい改善するのかを試すためである．一方，n の値が大きけれ正時間を削減できる• プリファレンスと上限が，タスクの分散効果にそれぞれ同程度寄与する

ば，割当て待ちとなる不具合が増え，前述のデメリットを本研究の今後の課題は，実際のプロジェクトでの適用と改善できると考えられる．本紙では n を大きくした場合のより厳密な比較を行うために不具合修正時間（コスト）の

c 2015 Information Processing Society of Japan

679

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)

算出方法を改良すること，また，機械学習を用いてプリ
ファレンスの精度を向上させることなどがあげられる．
謝辞 本研究の一部は，独立行政法人情報処理推進機構[18]が実施した「2013 年度ソフトウェア工学分野の先導的研究支援事業」の支援および文部科学省科学研究補助金（基盤（C）：24500041）による助成を受けた．

[19]

and Hsu, G.: Open Borders? Immigration in Open
Source Projects, Proc. MSR 2007, p.6 (2007).
Weiss, C., Premraj, R., Zimmermann, T. and Zeller, A.:
How Long Will It Take to Fix This Bug?, Proc. MSR
2007, p.1 (2007).
Hewett, R. and Kijsanayothin, P.: On modeling software defect repair time, Empirical Software Engineering, Vol.14, No.2, pp.165–186 (2009).

参考文献
[1]
[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]
[15]

[16]

[17]

Anvik, J., Hiew, L. and Murphy, G.C.: Who should ﬁx
this bug?, Proc. ICSE 2006, pp.361–370 (2006).
Jeong, G., Kim, S. and Zimmermann, T.: Improving bug
triage with bug tossing graphs, Proc. ESEC/FSE 2009,
pp.111–120 (2009).
Anvik, J. and Murphy, G.C.: Reducing the eﬀort of bug
report triage: Recommenders for development-oriented
decisions, ACM Trans. TOSEM 2011, Vol.20, No.3,
pp.10:1–10:35 (2011).
Bhattacharya, P. and Neamtiu, I.: Fine-grained incremental learning and multi-feature tossing graphs to improve bug triaging, Proc. ICSM 2010, pp.1–10 (2010).
Guo, P.J., Zimmermann, T., Nagappan, N. and Murphy,
B.: “Not my bug!” and other reasons for software bug
report reassignments, Proc. CSCW 2011, pp.395–404(2011).
Park, J., Lee, M., Kim, J., Hwang, S. and Kim, S.:
COSTRIAGE: A Cost-Aware Triage Algorithm for Bug
Reporting Systems, Proc. AAAI 2011 (2011).
Bortis, G. and van der Hoek, A.: PorchLight: A Tagbased Approach to Bug Triaging, Proc. ICSE 2013,
pp.342–351 (2013).
Tamrawi, A., Nguyen, T.T., Al-Kofahi, J.M. andNguyen, T.N.: Fuzzy Set and Cache-based Approachfor Bug Triaging, Proc. ESEC/FSE 2011, pp.365–375(2011).
Shokripour, R., Anvik, J., Kasirun, Z.M. and Zamani,
S.: Why So Complicated? Simple Term Filtering andWeighting for Location-based Bug Report Assignment
Recommendation, Proc. MSR 2013, pp.2–11 (2013).
Naguib, H., Narayan, N., Brugge, B. and Helal, D.: Bug
report assignee recommendation using activity proﬁles.,Proc. MSR 2013, pp.22–30 (2013).
Runeson, P., Alexandersson, M. and Nyholm, O.: Detection of Duplicate Defect Reports Using Natural Language Processing, Proc. ICSE 2007, pp.499–510 (2007).
Ohira, M., Hassan, A.E., Osawa, N. and Matsumoto,K.: The Impact of Bug Management Patterns on Bug
Fixing: A Case Study of Eclipse Projects, Proc. ICSM
2012, pp.264–273 (2012).
Gunn, S.R.: Support Vector Machines for Classiﬁcation and Regression, Technical report, Universityof Southampton, Faculty of Engineering, Science andMathematics; School of Electronics and Computer Science (1998).
福島雅夫：数理計画法入門，朝倉書店，東京 (1996).
阿萬裕久：論理的制約条件付き 0-1 計画モデルを用いた
重点レビュー計画法，コンピュータソフトウェア（日本ソフトウェア科学会誌），Vol.29, No.2, pp.612–621 (2012).
Mockus, A., Fielding, R.T. and Herbsleb, J.D.: Two
Case Studies of Open Source Software Development:
Apache and Mozilla, ACM Trans. TOSEM 2002, Vol.11,
No.3, pp.309–346 (2002).
Bird, C., Gourley, A., Devanbu, P., Swaminathan, A.

c 2015 Information Processing Society of Japan柏 祐太郎 （学生会員）
平成 25 年和歌山大学システム工学部
情報通信システム学科卒業．現在，同大学大学院システム工学研究科博士前期課程在学中．学士（工学）．ソフ
トウェア工学，特にマイニングソフト
ウェアリポジトリの研究に従事．

大平 雅雄 （正会員）
平成 10 年京都工芸繊維大学工芸学部
電子情報工学科卒業，平成 15 年奈良先端科学技術大学院大学情報科学研究科博士後期課程修了．同大学情報科学研究科助教を経て，平成 24 年和歌山大学システム工学部准教授．博士（工学）．ソフトウェア工学，特にマイニングソフトウェアリ
ポジトリの研究に従事．電子情報通信学会，ヒューマンイ
ンターフェース学会，ACM 各会員．

阿萬 裕久 （正会員）
平成 13 年九州工業大学大学院工学研
究科電気工学専攻博士後期課程修了．
同年愛媛大学工学部助手．平成 19 年
同大学大学院理工学研究科講師．平成25 年より同大学総合情報メディアセンター准教授．ソフトウェアメトリク
ス，エンピリカルソフトウェア工学に関する研究に従事．
博士（工学）．平成 24 年電子情報通信学会情報・システム
ソサイエティ活動功労賞，平成 25 年情報処理学会山下記念研究賞受賞．電子情報通信学会，日本ソフトウェア科学会，日本知能情報ファジィ学会，IEEE 各会員．

680

情報処理学会論文誌

Vol.56 No.2 669–681 (Feb. 2015)亀井 靖高 （正会員）
平成 17 年関西大学総合情報学部卒業．
平成 21 年奈良先端科学技術大学院大学情報科学研究科博士後期課程修了．
同年日本学術振興会特別研究員（PD）．
平成 22 年カナダ Queen’s 大学博士研究員．平成 23 年九州大学大学院システム情報科学研究院助教．博士（工学）．ソフトウェアメ
トリクス，マイニングソフトウェアリポジトリの研究に従事．電子情報通信学会，IEEE 各会員．

c 2015 Information Processing Society of Japan

681