ソフトウェア・シンポジウム2018 in 札幌

トピックモデリングに基づく開発者検索手法の構築へ向けて福井 克法
和歌山大学 システム工学部
fukui.katsunori@g.wakayama-u.jp

大平 雅雄
和歌山大学 システム工学部
masao@sys.wakayama-u.ac.jp

要旨

川辺 義勝
株式会社 SRA
kawabe@sra.co.jp

されている．例えば，Mockus らは，ソースファイルの変更履歴に基づいてソフトウェアシステムのモジュール毎

効率的なソフトウェア開発には適切な人材配置が重要に開発者の専門性を計測する手法を提案しており，問いとなるため，ソフトウェア開発組織は各開発者がこれま合わせ先として適任の開発者を検索できるよう支援してで携わった業務に関する経験をできる限り詳細に把握しいる [1]．同様に，Robbes らは，ソースファイルの変更管理できることが望ましい．しかしながら，組織の規模

履歴に加えて変更時期（直近の変更であれば専門性を高がある程度大きくなると在籍するすべての開発者の業務くする）を考慮した開発者検索手法を提案している [2]．

経験を人為的に管理することは現実的に困難な問題とな先行研究は，多数の開発者が在籍する大規模組織におる．本研究の目的は，ソフトウェア開発の全工程を対象

ける開発者検索手法としてはある程度の有用性を期待でとして開発者を広く検索できる手法を構築し効率的な人

きるものの，構成管理システムに記録される活動と紐付

材配置を支援することである．特に本論文では，メーリく開発者，すなわち，製造工程や保守工程において構成

ングリストアーカイブへ潜在的ディリクレ配分法 (LDA:

管理の対象となるファイルを変更したことのある開発者

Latent Dirichlet Allocation) を適用した結果に基づいて，検索語と開発者の関係性を定量的に計測することにより開発者を検索する手法を提案する．4 つの OSS プロジェ
クトのメーリングリストアーカイブを対象として提案手法の評価実験を行った結果，プロジェクトによってばらつきが見られるものの，提案手法により 61%〜100%の精度で開発者を検索できることが分かった．

のみしか検索の対象にできないという点で適用範囲に限界がある．実際の開発組織においては，要件定義や基本・
詳細設計などの上流工程を主に担当する場合もあり，業
務の中でソースファイルの変更に直接的に関与しない開発者も少なくない．したがって先行研究は，大規模な開発組織内に在籍する開発者を広く検索する手法としては実用性の観点で問題があると言える．
本研究の目的は，ソフトウェア開発の全工程を対象として開発者を広く検索できる手法を構築し効率的な人材

1. はじめに配置を支援することを最終的な目的とする．特に本論文
では，メーリングリストアーカイブへ潜在的ディリクレ

効率的なソフトウェア開発には適切な人材配置が重要

配分法 (LDA: Latent Dirichlet Allocation) を適用したとなるため，ソフトウェア開発組織は各開発者1 がこれま結果に基づいて，検索語と開発者の関係性を定量的に計で携わった業務に関する経験をできる限り詳細に把握し測することにより開発者を検索する手法を提案する．

管理できることが望ましい．しかしながら，組織の規模

本論文の構成は以下の通りである．続く 2 章では，提がある程度大きくなると在籍するすべての開発者の業務案手法の詳細について記述する．3 章では，提案手法を

経験を人為的に管理することは現実的に困難な問題とな評価するための実験について述べる．4 章で評価実験のる．そのため，構成管理システムに記録された開発者の結果を示し，5 章において結果を考察する．6 章で関連

過去の活動履歴に基づいて開発者を検索する手法が研究

研究を紹介し，最後に 7 章において，まとめと今後の課題について述べ本論文を結ぶ．

1 本研究における開発者とは，ソフトウェア開発工程に関与するす
べての実務者を指す．

81

SEA

ソフトウェア・シンポジウム2018 in 札幌

2. 提案手法
2.1. 概要
本研究の目的は，ソフトウェア開発の全工程を対象として開発者を広く検索できる手法を構築し効率的な人材

図 1. メーリングリストアーカイブへの LDA の適用配置を支援することである．特に本論文では，メーリン
グリストアーカイブへ潜在的ディリクレ配分法 (LDA:

Latent Dirichlet Allocation) を適用した結果に基づいて，検索語と開発者の関係性を定量的に計測することに
より開発者を検索する手法を提案する．メーリングリス
トアーカイブを用いる理由は，開発工程の違いや部門の違いを問わずメーリングリスト2 が開発組織において現状最も広く利用されているコミュニケーションツールであるため，開発者を広く検索するためのデータソースとして適していると考えたためである．
メーリングリストアーカイブを用いた最も単純な開発者検索手法には，メーリングリスト内で各開発者が使用した単語の回数に基づいて検索語毎に開発者を順位付けする方法が考えられる．しかしながら，このような単純な方法では，開発者が特定の投稿で多数同じ単語を使用した場合や，様々な分脈や話題で広く利用される一般的な単語を使用した場合には，開発者の専門性をその単語から想起することが困難になる．検索語となる単語がメーリングリスト内のどのような議論で特徴的に利用されてきたのかについての意味的な分析を踏まえて，検索
語と開発者の関連性が定量化される必要がある．そこで
本研究では，メーリングリストに存在するトピック（潜在的な意味）を把握する手段として潜在的ディリクレ配分法（LDA : Latent Dirichlet Allocation）[3] を用いることとした．
提案手法は主に，(1) メーリングリストアーカイブに
LDA を適用しトピックを抽出する処理，(2) メーリング
リストへの各投稿と検索語との関係性を定量化するための処理，(3) 検索語との関係性が高い投稿を行った開発者を順位付けするための処理から成る．以降では，それぞれの処理を詳しく説明する．

図 2. LDA のグラフィカルモデルを用いる．図 1 は，メーリングリストアーカイブへ LDAを適用する一連の流れを示したものである．本節では，LDA のアルゴリズムを簡潔に説明するとともに，メーリングリストアーカイブを LDA に適用する際の前処理について説明する．

2.2.1. 潜 在 的 ディリ ク レ 配 分 法（LDA : Latent
Dirichlet Allocation）
LDA は文章の生成過程を確率的にモデル化するトピッ
クモデルの 1 つである．トピックモデルとは，文章集合に含まれる潜在的なトピック（潜在的な意味）を推定するモデルである．LDA を用いることで，文章集合に含まれる複数のトピックを推定できるだけではなく，各トピックを構成する単語のトピック内での生起確率である
単語分布や，1 つの文書に含まれるトピックの構成割合であるトピック分布を計算することができる．
図 2 に，潜在的ディリクレ配分法のグラフィカルモデ
ルを示す．LDA では 1 つの文書は複数のトピックから構成されており，各トピックで生起する単語の生起確率に応じて文書が生成されるという考えに基づいたモデルであるため，各文書はトピックの構成比であるトピック
分布θを持っており，θに応じて生起する単語のトピッ
ク Z が決定する．トピック Z の単語分布より生起する単語 W が決定する．n は 1 つの文書上の単語の出現回数を表し，M は文書数，K はトピック数を表す．αはθを決定するための，βはφを決定するためのハイパーパラ
メータである．

2.2. LDA によるトピック抽出
本研究では，メーリングリスト全体に含まれるトピッ
クと各投稿を構成するトピックを把握するために LDA
2 個人間のやり取りを含むメールは本研究では対象外とする．

82

SEA

ソフトウェア・シンポジウム2018 in 札幌

2.2.2. メーリングリストアーカイブへの LDA の適用
メーリングリストアーカイブに LDA を適用するためには，メーリングリストアーカイブから抽出したテキス
トデータ（本文）を数値で扱う必要がある．本研究では，
図 1 左部分に示したように，Bag-of-Words を用いてテキストデータをベクトル化する．具体的には，メーリン
グリストへの各投稿に含まれるテキストデータ（本文）
図 3. トピック特定

を Document1，Document2 のように行として，投稿中に出現する単語を Word1，Word2 のように列とし，各投稿に含まれる単語の頻度を行列で表したものが本研究で扱う Bag-of-Words ベクトルである．本研究では，30%以上の文書に出現する一般的な単語（頻繁に使われる特徴的ではない単語）を除外してから Bag-of-Words ベク
トルを作成している．また，文書全体で 2 回以下しか出現しないような単語も専門性を表す際のノイズとなる可能性が高いためあらかじめ除去した．

2.3. 検索語と各投稿との関係性の定量化
図 4. トピック分布の抽出

本研究では，開発者の人材配置を意図して大規模な開発組織に所属する開発者を検索する際には，開発者の業
務経験や技術スキルを表す専門的な用語が検索語として用いられると想定している．本研究ではまず，LDA を適用した際に算出されるトピック分布θおよび単語分布

Twi = (t1 , t2 , t3 , t4 , t5 )φを用いて検索語と各投稿の関係を定量化し，2.4 節で(1)

これらの 5 つのトピックを利用して式（2）よりに各述べる開発者のスコアリングのための前処理を行う．

投稿ごとに DocScorewi ,dj を算出する．

まず，LDA の適用により抽出されるトピックから検索語と関連性の高い上位 5 つのトピックを抽出する．図3 に示すように，具体的には各トピックの単語分布から検索語の生起確率が高い順に 5 つのトピックを抽出する．
この処理によって，検索語とは一致しなくても検索語を含むトピックに含まれる単語を用いた開発者を検索する
手がかりとなる．すなわち，検索語を含むトピックを何らかの専門性を表す文脈であると仮定し，その文脈に多く現れる開発者を検索語に関連性の深いエキスパートと考え検索結果の上位に位置付けるための前処理である．
次に，検索語と関連性の高い上位 5 つのトピックが各
投稿にどの程度含まれているかをトピック分布（図 4）から算出し，検索語と各投稿との関係性を DocScorewi ,djとして定量化する．
まず，各検索語 wi に対して生起確率の高い上位 5 つのトピック Twi として特定する．

DocScorewi ,dj =5∑

θtk ,wi × ϕtk ,dj

(2)

k=1

ここで，θtk ,wi は検索語 wi のトピック tk における検索語の生起確率を表し，ϕtk ,dj は投稿 dj のトピック tkのトピック分布の比率を表す．θtk ,wi は，検索語 wi の生起確率が高いトピックほど検索語 wi に関する内容を含むトピックであると考え DocScorewi ,dj の値が高くなる．また，ϕtk ,dj についても，検索語と関連性の高いト
ピック tk の比率が高いほどトピック tk の内容を投稿 djが多く含むと考え DocScorewi ,dj の値が高くなる．

2.4. 開発者の順位付け
次に，2.3 節で求めた DocScorewi ,dj を利用して検索語と開発者の関係性を AuthorScoredevn として算出し

83

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 1. 評価実験に使用するデータセット
プロジェクト

期間

件数

開発者数

Apache Hive2008/11/11∼2010/10/07

1,881

28

Apache Pig

2007/10/31∼2010/09/28

1,662

44

Apache ZooKeeper

2007/10/31∼2010/09/28

1,506

23

Apache Chukwa

2009/03/10∼2013/10/08

877

25

4,209

118

合計

3.2. 対象データセット
図 5. 開発者の順位付け
本実験では，Apache Hadoop プロジェクトのサブプロ
ジェクトである Apache Chukwa，Apache ZooKeeper，

開発者を順位付けする（図 5）．

AuthorScoredevn =N umOf∑M ailDocScorewi ,dm

Apache Hive，Apache Pig のメーリングリストアーカイ
ブを評価対象とする．本手法は大規模組織での人材配置に役立てることをの最終的な目標としているため，1 つの組織を再現するためにプロジェクトの内容が離れすぎていないプロジェクトを選択した．また，正解集合を作成しやすいように，Hadoop のサブプロジェクトであるがサブプロジェクト間で開発者の重複が少なく，データが取得しやすいという理由で上記４プロジェクトを選択
した．

(3)

m=1

N umOf M ail は各開発者が投稿した件数を表しており，AuthorScoredevn は各開発者の各投稿の DocScore
を足し合わせることで算出する．AuthorScore を開発者間で比較して，AuthorScoredevn が高い開発者ほど検索
語に関連したトピックを含む投稿を多く行っていると考えられる，すなわち，検索語と関連性の高い開発者と考えられるため，AuthorScore の高い順に検索結果として

3.3. データセットの作成

出力する．
実験のデータセットとして使用する対象プロジェクトの開発者向けメーリングリストのメールデータを mbox

3. 評価実験形式で取得する．取得した mbox ファイルは月ごとにすべての投稿が１つのファイルに連結して保存されてい本章では，提案手法を評価することを目的に行った評

る．mbox ファイルから実験に必要なデータ（送信者情価実験について述べる．

報，メッセージ ID，本文など）を取得することができ

3.1. 目的る．ただし，開発者メーリングリストには，開発者同士のやりとり以外にプロジェクトで利用されているツール

本実験の目的は，検索語に対してふさわしい開発者を(Bugzilla, JIRA, Jenkins 等) から通知される投稿も含
まれてるため，それらの投稿はあらかじめ除去した．また，本文に含まれる URL や開発者の署名は LDA を利用してトピック抽出する際のノイズとなるため，正規表
現を利用してできる限り除去した．
上記の処理を施した後の本評価実験で使用したデータセットの内訳を表 1 に示す．メーリングリストへの投稿は総計 4,209 件，開発者（投稿者）は延べ 118 人であった．この内，複数のプロジェクトに参加している開発者
が 2 人存在する．取得したこれら 4 つのサブプロジェク
トの mbox ファイルを１つの mbox ファイルにまとめる
ことによって，複数プロジェクトが混在した合成データ

本手法により検索できているかを確かめることである．
実験の対象として複数のプロジェクトが混在しており
様々な工程の開発者が使用している開発組織のメーリン
グリストアーカイブを用いることが望ましい．しかし，企業などの開発組織から大規模なデータを入手することが困難なため，本実験では 4 つの OSS プロジェクトのメーリングリストアーカイブを合成し，複数プロジェク
トが混在したような合成データを作成する．各プロジェ
クトのドメイン用語を検索語とした時，対象としたドメ
イン用語を用いるプロジェクトに所属する開発者を検索でるかどうか調べることで提案手法を評価する．

84

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 2. tf-idf 値の高い上位 10 単語
Hive単語

hiveopensourc
srcpartmetaexcept
jobconf
thriftsrcbucket
protect
numreducetask
processnam
libjartf-idf 値
29494.33
7406.33
5130.524256.35
3680.843274.152116.89
2010.47
1842.931746.07

Pig
単語
physicallay
pig
mapreducelay
cocoongld
inactiveaccountpiggybankeq
acctforeachtf-idf 値
6189.565193.714413.45
2088.30
1757.781718.071497.06
1425.57
1389.781334.48

Zookeeper
単語
tf-idf 値
nioservercnxn
964.15zookeep
906.55nioservercxn
842.17
todd
810.10clientcnxn
756.99socket662.31
peer
543.22antlib504.34hunt
488.12
elect483.75

Chukwa単語
tf-idf 値
adaptor818.90
chukwa683.94hicc
420.35demux
398.50collector
296.34
seqfilewrit281.23agent
267.72row
249.19depart243.32scienc243.26を作成する．
図 6. 汎用語の削除

3.4. 評価実験用の検索語の抽出
評価実験において，提案手法が検索語にふわさしい開3.4.2. 特徴語の抽出

発者を提示することができるかどうかを調べるために，実験で用いる検索語をあらかじめ用意しておく必要があ

文章中の単語の重要度を評価する手法の１つに tf-

る．評価実験で用いる検索語は，各プロジェクトのドメ

idf がある．tf-idf は文章 d における単語 t の出現頻度
tf(t, d)(Term Frequency) と，単語 t が出現する文書数の全文書数に対する割合である df(t) の逆数の対数をとった逆文書頻度 idf(t)(Inverse Document Frequency) に基づいて，式（7）で算出することができる．

インの特徴を表すような用語（ドメイン用語）が望まし
い．本論文におけるドメイン用語とは，特定の開発のみで使用される用語，または，特定の開発を表すような用語を指す．
評価実験では，文書集合の単語の重要度を評価する手法である tf-idf を用いて各プロジェクトの特徴語を抽出

tf(t, d)

し検索語を決定する．また，プロジェクト内で頻繁に利|{t ∈ Td }|
|Td |

(4)

|{d ∈ D : t ∈ Td }|
|D|

(5)

=

用されている語もプロジェクトの特徴を表しているのではないかと考え頻出語を抽出して検索語とする．頻出語

df(t)は tf 値を用いて抽出することが一般的であるが，tf 値=を用いて抽出すると tf-idf 値を用いて抽出した場合と重複することが多いため，本研究では df 値を用いて抽出

idf(t) =した．以降では，評価実験用の検索語を抽出するために

1
df(t)

(6)

tf(t, d) · idf(t)

(7)

log2

行った処理について説明する．

tfidf(t, d) =3.4.1. 汎用語の削除

ここで，Td は文章 d で出現する単語の集合を，D は全文書の集合を表している．

まず，図 6 のように，すべてのプロジェクトで共通し

本実験では各投稿 1 通を 1 つの文書として td-idf を適て利用される汎用語を削除する．汎用語は，各プロジェ

用し，各プロジェクト毎に出現単語の tf-idf 値を算出しクトから特徴語と頻出語を抽出する際のノイズになるとた．出現単語の tf-idf 値を目視で確認して，プロジェク

考えられる．例えば，投稿メッセージの冒頭でのあいさ

トの特徴を表すと考えられる上位 10 単語を各プロジェク

つ（Hi や Dear など）や，実験で用いたプロジェクトはトの特徴語として抽出した．表 2 に抽出した各プロジェ

hadoop のサブプロジェクトであるため hadoop などの用語も全てのサブプロジェクトのメーリングリストで出現する汎用語に含まれる．

クト毎の特徴語（if-idf 値の高い単語）を降順に示す．

3.4.3. 頻出語の抽出
各プロジェクトの頻出語は式（5）の df (t) の値の高い
上位 10 単語を用いる．tf (t, d) は単語の使用頻度である

85

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 3. df 値の高い上位 10 単語
Hive単語

hiveopensourc
hive
srcpartthriftmetaexcept
jobconfsrcbucket
protect
numreducetask
metastor

Pig
df 値
7311.00
4844.00
2041.00
1357.00
1231.00
1102.00
836.00590.00456.00448.00単語

pig
physicallay
mapreducelay
schemaforeachgate
cocoonpiggybankgld
javaccdf 値18039.00
1194.00
830.00569.00539.00516.00495.00452.00407.00365.00

Zookeeper単語
df 値
zookeep
2152.00hunt
404.00nioservercnxn
242.00clientcnxn
239.00
todd
216.00elect
201.00socket198.00nioservercxn
193.00lock
165.00peer
148.00

表 4. 特徴語（tf-idf 値の高い上位 10 単語）を検索

Chukwa単語
df 値
chukwa1560.00
adaptor
347.00hicc
168.00demux
168.00collector
123.00scienc115.00depart114.00jiaqi
113.00agent
107.00seqfilewrit
79.00

語とした場合のプロジェクト毎の平均正答率
プロジェクト

トピック数

100

500

1000

Apache Hive

81%

61%

62%

ため特定の文書に偏って同じ単語が使用されていても高Apache Pig

91%

100%

99%

い値が示されるのに対して，df (t) は単語 t が出現する

Apache ZooKeeper

61%

70%

73%

文章が多いほど高い値を示すため，プロジェクト内で幅

Apache Chukwa

71%

67%

78%

広く使われている単語も各プロジェクトの特徴を表すのではないかと考えた．表 3 に各プロジェクト毎の頻出語

表 5. 頻出語（df 値の高い上位 10 単語）を検索語（df 値の高い単語）を降順に示す．

とした場合のプロジェクト毎の平均正答率

3.5. 実験手順

プロジェクト

トピック数

100

500

1000

Apache Hive

78%

65%

66%

Apache Pig

86%

99%

91%

ジェクトを組み合わせた合成データに対して LDA

Apache ZooKeeper

66%

75%

75%

を適用する．LDA ではトピック数を任意の数に設Apache Chukwa

71%

69%

82%

評価実験は手順で行った．
手順 1：LDA モデルの作成 3.3 節で述べた 4 つのプロ定できる．設定したトピック数が検索精度に与える影響を調べるため，本評価実験ではトピック数をそた，表 5 に，頻出語（df 値の高い上位 10 単語）を検索語

れぞれ 100，500，1000 の 3 つのモデルを作成した．

とした場合の平均正答率をプロジェクト毎に示す．表 4

各モデルに対して各投稿のトピック分布およびト

および表 5 ではそれぞれ，設定したトピック数別（100,

ピック毎の単語分布を計算する．

500, 1000）で平均正答率を示している．ここでの正答率とは，表 2 および表 3 の検索語を用いて検索を行なった
結果得られる上位 10 名の開発者が，検索語が属するサ
ブプロジェクトに何名参加していたかを表す．例えば，
hiveopensource を検索語とした場合に Apache Hive に参加する開発者が 10 名中何名検索結果として提示されていたかで正答率を求める．したがって，ここでの平均
正答率とは，検索語 10 単語を用いて検索を行った場合の正答率の平均値を表す．
以下ではサブプロジェクト毎に検索精度を議論する．

手順 2：特徴語・頻出語を用いた開発者の検索 3.4 節
で述べた各プロジェクトの特徴語および頻出語を検索語として用いて提案手法を適用する．2.4 節で述べた AuthorScore の高い上位 10 名の開発者を検索結果とする．
手順 3：検索結果から正答数と正答率を算出 手順 2 の検索で得られた開発者がどの程度正しく検索できているか検証するために，検索して得られた開発者が特徴語および頻出語（検索語）が出現するプロ

4.1. Apache Hive プロジェクトの実験結果

ジェクトに参加していれば正解，参加していなければ不正解としてトピック数とプロジェクト毎に正答特徴語を用いた検索結果

数と正答率を算出する．

すべての検索語の正答率の平均では，トピック数を100 に設定した時に正答率が 81%で最も高い値を示
し，トピック数を 500 に設定した時の正答率が 61%で最も低い値を示した．トピック数を 1000 に設定した時の正答率は 62%であった．

4. 実験結果
表 4 に，特徴語（tf-idf 値の高い上位 10 単語）を検索語とした場合の平均正答率をプロジェクト毎に示す．ま

86

SEA

ソフトウェア・シンポジウム2018 in 札幌

頻出語を用いた検索結果

67%で最も低い値を示した．トピック数を 100 に設定した時の正答率は 69%であった．

すべての検索語の正答率の平均では，トピック数を100 に設定した時に正答率が 78%で最も高い値を示し，トピック数を 1000 に設定した時の正答率が65%で最も低い値を示した．トピック数を 500 に設定した時の正答率は 66%を示した．

頻出語を用いた検索結果
すべての検索語の正答率の平均は，トピック数を1000 に設定した時の正答率が 82%で最も高い値を示し，トピック数 500 に設定した時の正答率が 69%で最も低い値を示した．トピック数 500 に設定した時の正答率は 71%であった．

4.2. Apache Pig プロジェクトの実験結果
特徴語を用いた検索結果
すべての検索語の正答率の平均は，トピック数を4.5. 実験結果のまとめ500 に設定した時の正答率が 100%で最も高い値を示し，トピック数を 100 に設定した時の正答率が91%で最も低い値を示した．トピック数を 1000 に設定した時の正答率は 99%であった．

差はあったが，正答率は 61%〜100%であった．Apache

各プロジェクトとトピック数の設定によって正答率にPig の特徴語を用いてトピック数を 500 に設定した時の正答率が 100%で最も高く，Apache Hive の特徴語を用いてトピック数を 500 に設定した場合の正答率が 61%で最も低かった．Apache Hive ではトピック数を 100 に設定した時，Apache Pig ではトピック数を 500 に設定
した時，Apache ZooKeeper と Apache Chukwa ではト
ピック数を 1000 に設定した時が最も正答率が高かった．

頻出語を用いた検索結果
すべての検索語の正答率の平均は，トピック数を500 に設定した時の正答率が 99%で最も高い値を示
し，トピック数を 100 に設定した時の正答率が 86%で最も低い値を示した．トピック数を 1000 に設定した時の正答率は 91%であった．

5. 考察
4.3. Apache ZooKeeper プロジェクトの実験結果
本章では，評価実験の結果を踏まえ，提案手法の有用
特徴語を用いた検索結果

性と今後の課題について考察する．

すべての検索語の正答率の平均は，トピック数を1000 に設定した時の正答率が 73%で最も高い値を示し，トピック数を 100 に設定した時の正答率が61%で最も低い値を示した．トピック数を 500 に設定した時の正答率は 70%であった．

5.1. 正答率と提案手法の有用性
実験の結果，Apache Pig の検索語を用いて実験を行った場合が最も正答率が高い結果となった．表 1 で示した
ように Apache Pig の開発者数は 44 人と最も多く，他の頻出語を用いた検索結果

3 サブプロジェクトは多くとも 28 人である．これらの結果を鑑みると，多くの開発者が議論に参加する活発なメーリングリストであったため，Apache Pig の開発者の経験やスキル，役割などに沿って LDA によるトピッ
ク抽出が他のサブプロジェクトに比べて上手く行えたのではないかと考える．結果として，検索語から得られる上位 10 人の開発者が，検索語毎に比較的分散して出力された結果，他のサブプロジェクトよりも高い平均正答率を示したのではないかと考えている．
一 方 で ，特 徴 語 を 検 索 語 と し た 場 合 の Apahce
Zookeeper は，61%（トピック数）と最も平均正答率が低かった．トピック数を増やすことで平均正答率が 70%

すべての検索語の正答率の平均は，トピック数を1000 と 500 に設定した時の正答率が 75%で最も高い値を示し，トピック数を 100 に設定した時の正答率が 66%で最も低い値を示した．
4.4. Apache Chukwa プロジェクトの実験結果
特徴語を用いた検索結果
すべての検索語の正答率の平均は，トピック数を1000 に設定した時の正答率が 78%で最も高い値を示し，トピック数を 500 に設定した時の正答率が

87

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 6. 正答率が半分以下の検索語
検索語

thrifthicc

libjarpeer

javaccnumreducetask

socketsrcbucket∼ 73%に向上するものの，平均正答率には改善の余地があると言える．また，Apache Hive のようにトピック数を増やすと平均正答率が低下するプロジェクトも存在するため，トピック数を増やすことが平均正答率の向上につながるとも一概には言えない．Apahce Zookeeper の開発者は 4 つのサブプロジェクトの中では最も少ない 23人であり，メーリングリストへの参加者数が正答率に影響を与えている可能性も否定できない．これらのことから，プロジェクトの開発者数，投稿数，トピック数からは平均正答率との一貫した因果関係を読み取ることはできないため，検索精度の向上へ向けて今後は各開発者の投稿内容をより詳細に分析する必要がある．
評価実験の結果全体としては，すべてのプロジェクトにおいても平均正答率は 6 割以上を示しており提案手法
は一定の有用性を示したと考えている．

antlibseqfilewritrowjobconf

sciencれる．

javacc は，Java Compiler Compiler の略であり Java
言語向けの構文解析器生成ツールである．
socket は，ネットワーク用語の一つであり通信プロト
コルを利用する際に通信の出入り口を Socket のことを指していると考えられる．このようにこれらの単語は必
ずしも各サブプロジェクトの開発に特化した内容で用いられる用語ではなく，サブプロジェクト内で比較的頻繁に利用される語であった．
さらに，numreducetask の正答率が低かった原因として，複数のプロジェクトで使用されていたため各プロジェクトの特徴を表すことができなかったと考えられる．
chukwa プロジェクトでは tf-idf 値が 13.55，pig プロジェ
クトでは tf-idf 値が 52.56 で出現していた．3.4.1 節で述べたように，本研究では汎用語をあらかじめ除去して合成データを作成しているが，本評価実験では 4 つのプロジェクトで共通して出現する単語のみを除去している．
2 つあるいは 3 つのプロジェクトで共通して出現する単語も汎用語として除去することで平均正答率の向上につながる可能性がある．しかしながら，汎用語として多くの用語を除去すれば，該当するトピック・開発者が紐付きにくくなる可能性もあるため，汎用語の削除の効用については実験条件を追加し比較する必要がある．
また，正答率が半分以下であった残りの hicc，srcbucket，seqfilewrit については，検索語として抽出したプロジェクトでのみ使用される語であったが正答率は半分以下であり，正答率の低さを説明することが現時点では困難なため，今後はより詳細に各検索語の利用される文脈を投稿内容から理解する必要がある．

5.2. 検索語と正答率
実験の結果，検索語によって正答率の違いがあることが分かった．各プロジェクトで使用した検索語のうちトピック数 100，500，1000 のいずれかに設定した際に正答率が半分以下であった検索語を表 6 に示す．
正答率が半分以下であった検索語のうち thrift, libjar,
javacc, socket, antlib, row, science, peer については，
ソフトウェア開発に関するプロジェクトでは頻繁に利用される単語であるため，各プロジェクトの正答率が半分以上であった検索語と比較すると各プロジェクトの特徴を表すことができず正答率が低かったと考えられる.
thrift は，Apache Thrift プロジェクトのことを指していると考えられる．Apache Thrift は RPC（リモート
プロシジャーリコール）フレームワークのプロジェクトである．RPC はネットワークに接続された他の PC 上
でプログラムを呼び出すためのプロトコルである．
libjar は，Java 言語において外部ライブラリをインポートする際に lib フォルダに jar ファイルを置くため，
外部ライブリのインポートの一連の流れに関する内容がデータに含まれていたため出現した単語であると考えら

5.3. トピック数
実験の結果から，トピック数の変化による正答率の変化はプロジェクトによって異なることが分かった今回の実験では，トピック数による正答率の大きな違いは見られなかったが正答率を上げるためにはデータに対して最適なトピック数を設定する必要があると考えられる．本

88

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 7. Apache Hive の特徴語：srcbucket
topic:100：正答率 (80%)

topic:500：正答率 (50%)

#74

#97

#88

#75

#9

#225

#143

#2

#210

#244

ok

ok

org

junit

junit

timefram

junit

junit

org

junit

junit

org

type

info

org

timefram

tabl

data

type

info

exec

junit

hive

exec

info

maintain

ok

tabl

ok

org

tabl

data

problem

hiveopensourc

hive

hdf

data

ok

partit

data

info

tabl

java

usr

tabl

hive

partitinfo

srcpart

ok

data

java

tabl

file

exec

zookeep

srcpartsrcparttabl

tabl
srcpart

org

hive

data

org

ok

think

hr

partitjava

partit

queri

class

build

file

client

usr

org

class

usr

hr

partitrefer

job

hiveopensourc

project

hiveopensourchrhrpartitbuild

srcpart

ok

data

usr

award

queri

exec

hive

hr

節では，特定のプロジェクトでのみ使用されているが，が，ソフトウェア開発組織では会議や会話でのコミュニ

正答率が半分以下を示した hicc について設定したトピッケーションが中心となるためメールアーカイブに開発にクのうち正答率が最も高かったトピック数と低かったト関する議論などが残りにくい．そのため，本手法をソフ

ピック数で検索語が含まれるトピックとして提案手法に

トウェア開発組織に応用するにあたり，メールアーカイより特定できた上位 5 つの構成語を比較することで，正ブのみでなく会議の議事録や仕様書を利用することが有答率とトピック数の違いを考察する．表 7 は，検索語と効であると考える．また，本実験では tf-idf 値と df 値をして srcbucket を用いた時に特定できたトピックの主要用いることで機械的に各プロジェクトの開発者を検索すな構成語を表している．正答率の最も高かったトピック

るための語を決定したが，ソフトウェア開発組織におい数 100 の時と，低かったトピック数 500 の時に特定できて利用する際の検索語は異なると考えられる．

たトピックの構成語を比較すると 3.4.3 節で特定できた

6. 関連研究

Apache Hive の特徴語と頻出語がトピックの構成語として含まれている数は一緒であったが，正答率が高かった
トピック数 100 の時の方が，hiveopensourc などの tf-idf
値がより高い語が多く含まれていた．正答率の高かったトピック数と低かったトピック数で特定できたトピックの構成語を確認することで正答率の高かったトピック数の方が，各プロジェクトの特徴語と頻出語が多く含まれることや，より tf-idf 値が高い語が含まれる場合が多い
ことが分かった．そのため，正答率が高い場合は正答率が低い場合よりも特定したトピックの内容が各プロジェ
クトに関連するトピックであったため正答率が高くなったと考えられる．

本研究で提案したような開発者検索手法および推薦手法は広く研究されている．本節では，本研究に関する関連研究としてコードレビューや不具合修正などに着目した開発者推薦に関する研究を紹介する．

Rahman ら [4] は，開発者推薦において特にコードレ
ビューを行うレビューアーについて着目した．コードレ
ビューはテストやコーディングの初期段階で行われ，あらかじめバグとなる箇所を適切な開発者が目視でコードを確認しバグを発見することで開発の全体的なコストを削減することができることが知られている．レビュー待ちのプルリクエストに対して，過去に開発者がレビュー

5.4. ソフトウェア開発組織への応用へ向けてしたプルリクエストとの類似度を測ることで推薦手法を提案している．

本実験では，OSS プロジェクトのメーリングリスト

Alan ら [5] は，不具合修正を担当する開発者の推薦手法を提案した．開発者の推薦を行う際に，バージョン
管理システムのデータと不具合管理システムのデータに着目した．双方のデータを用いた際の推薦手法の結果の比較を行い．双方のデータを用いた手法の利点についてを用いることで評価実験を行なった．しかし，OSS プロ
ジェクトと企業などのソフトウェア開発組織ではコミュ
ニケーションの取り方が異なると考えられる．OSS プ
ロジェクトでは，メールでのコミュニケーションが中心であり議論の内容等がメールアーカイブに残りやすい

89

SEA

ソフトウェア・シンポジウム2018 in 札幌

述べた．より正確に目的の開発者を推薦したい場合は，る必要があり良い結果を得るためには最適なトピック数

バージョン管理システムをデータとして用い，正確さよを推定する必要がある．今後は LDA 以外のアルゴリズ

りも関連する開発者を多く推薦したい場合は，不具合管

ムを用いてメーリングリストと各投稿から特徴量を抽出

理システムのデータを用いることが良いことを示した．

し，正答率を改善する予定である．

Bayati ら [6] は，特に情報セキュリティに関する分野に精通した開発者を推薦するための手法を提案した．ソフ
トウェアのセキュリティバグの深刻度について述べ，情報
セキュリティに関する知識を持った開発者を推薦する手法を提案した．大規模 QA サイトである StackOverflowのデータから投稿に付与されたタグと，質問への回答数，信頼度スコアを利用することで開発者をスコアリングし開発者を推薦する手法を提案した．
これらの研究では，特定のタスク（レビュー，不具合修正など）における開発者の検索・推薦を支援することを目的としており，汎用性の高い開発者検索を目指す本
研究とは立場が異なるが，検索結果の評価方法や検索精度の議論については本研究の参考になる．

謝辞
本研究の成果は株式会社 SRA と国立大学法人和歌山大学との共同研究の一部である．また，本研究の一部は，文部科学省科学研究補助金（基盤 (A): 17H00731，基盤(C): 18K11243）による助成を受けた．

参考文献[1] Mockus, A. and Herbsleb, J. D.: Expertise
Browser: A Quantitative Approach to Identifying Expertise, Proceedings of the 24th International
Conference on Software Engineering, ICSE ’02, pp.
503–512 (2002).

7. まとめと今後の課題[2] Robbes, R. and Röthlisberger, D.: Using Developer Interaction Data to Compare Expertise Metrics, Proceedings of the 10th Working Conference on
Mining Software Repositories, MSR ’13, pp. 297–
300 (2013).

本研究ではソフトウェア開発におけるコミュニケーショ
ンデータであるメーリングリストでの開発者のやりとりに着目し，大規模ソフトウェア開発組織における適切な人材配置を支援することを最終目的にして開発者検索手法を提案した．具体的には，メーリングリストに対して[3] Blei, D. M., Ng, A. Y. and Jordan, M. I.: Latent
Dirichlet Allocation, J. Mach. Learn. Res., Vol. 3,
pp. 993–1022 (2003).

トピックモデルを適用し，メーリングリストからトピッ
クと各トピックの単語分布，各投稿のトピック分布をそれぞれ算出し，検索語と各投稿との関係性の定量化する[4] Rahman, M. M., Roy, C. K. and Collins, J. A.:
CoRReCT: Code Reviewer Recommendation in
GitHub Based on Cross-project and Technology
Experience, Proceedings of the 38th International
Conference on Software Engineering Companion,
ICSE ’16, pp. 222–231 (2016).

とともに検索語と開発者の順位付けして開発者を検索するための手法を提案した．

OSS プロジェクト 4 つのメーリングリストを用いて複数プロジェクトが混在した合成データを作成し，各プ
ロジェクトの tf-idf 値の高い特徴語と df 値の高い頻出
語を検索語として用いて評価実験を行なった．プロジェ
クトによって正答数にばらつきはあったが，すべてのプ[5] Anvik, J. and Murphy, G. C.: Determining Implementation Expertise from Bug Reports, Proceedings of the Fourth International Workshop on Mining Software Repositories, MSR ’07, pp. 2– (2007).

ロジェクトで各プロジェクトの検索語を用いて検索を行なった結果，正答率は 61%〜100%であった．本研究における開発者の検索を行う際には，各プロジェクトでのみ使われるドメイン用語を検索語に用いると正答率が上[6] Bayati, S.: Security Expert Recommender in Software Engineering, Proceedings of the 38th International Conference on Software Engineering Companion, ICSE ’16, pp. 719–721 (2016).

がることが分かった．
今回はメーリングリストとメーリングリストに含まれる各投稿の内容把握のためにトピックモデルである LDAを用いた．しかし，LDA は事前にトピック数を設定す

90

SEA