日本ソフトウェア科学会第 30 回大会 (2013 年度) 講演論文集

トピック抽出を用いたソフトウェア開発履歴の可視化
ツール
山田 悠太

吉田 則裕

藤原 賢二

飯田 元

商業利用されるオープンソースソフトウェア（OSS）が近年多く存在する．それは，OSS の品質が高く利用料を必要としないからであるが，欠点として品質の保証やサポートの不備が挙げられる．もし，OSS に問題があった場合，企業は OSS の担当者に問い合わせをする可能性があるが，OSS プロジェクトの性質上特定の人物を探すのは困難であると考えられる．そこで，本研究では版管理システムのコミットログからトピックを抽出し，開発者に着目した可視化を行った．また，可視化を行うためのツールを実装し評価を行った．

Recently, commercial software products often incorporate Open Source Software (OSS). Industrial developers often need to know plans of enhancement and bug ﬁx for a speciﬁc feature/component of OSS when theyshould determine whether or not to incorporate it. However, it is diﬃcult for outsiders to retrieve a personfamiliar with a speciﬁc feature/component in OSS due to the voluntary nature of the contributions. In
this paper, we present a tool for visualizing version archives to support industrial developers who ﬁnd OSS
developers familiar with a speciﬁc feature/component. This tool applies topic analysis to version archives
for characterizing activities of individual developer.

者に問い合わせることが効率的であるが，OSS プロ

1 はじめにジェクトでは開発箇所やその担当を管理することは少オープンソースソフトウェア（OSS）は Source-

なく，またプロジェクトへの参加は開発者の自由意志

Forge.net や GitHub のソフトウェア開発プロジェクに基づくため時間経過によりプロジェクトの参加者トを共有するための Web サービスが近年台頭してきは刻々と変化してしまうため，開発者を探すにはプロたことにより開発が活発である．そして，OSS は利用ジェクトの開発履歴から探すことになる．

料を必要としないため，品質の高い OSS は商業利用開発履歴の可視化は今までも行われている．Hindleする傾向が大きくなっている [5]．しかし，OSS を利らはソフトウェア開発履歴から Word-bugs 解析や用する問題点としてソフトウェアの品質保証や OSSLDA によるトピック解析を用いて統一プロセスにおプロジェクトのサポート体制の不備が挙げられる．もける各フェーズのプロセスに関連付け，RUP Humpし，企業のプロジェクトにおいて OSS 利用箇所で問チャートを模倣し可視化を行っている [2]．Thomas ら

題が発生した場合，企業は OSS プロジェクトに問題はソースコードの識別子とコメントからトピックを抽について問い合わせることが考えられるが，OSS プ

出し，可視化を行うことでソフトウェア開発の変化をロジェクトの体制によっては回答までに時間が掛かっ表している [4]．しかし，これらの既存研究は開発全てしまう．そのため，直接問題箇所を担当した開発体にしか着目されていない．

A Topic-based Visualization Tool for Archives of Developer Activity
Yuta Yamada, Kenji Fujiwara, Norihiro Yoshida, Hajimu Iida, 奈良先端科学技術大学院大学 情報科学研
究科, Graduate School of Information Science, Nara
Institute of Science and Technology.

そこで，本研究では開発履歴であるバージョン管理システム（VCS）のコミットログからトピックを抽出し開発者の活動に着目した可視化を行う．コミットログは開発者が行った活動内容を簡潔に記述するため開発者の活動を知ることが期待でき，開発者に着目した可視化により開発者ごとの活動の流れを容易

表1に知ることが可能になる．また，コミットログのみをトピックの単語分布

上位キーワード用いることで特別なデータ収集する必要が無く，開発

トピック Afix, bug, error

言語に依存せず本手法を適用することが可能である．

トピック Bchange, method, class

可視化はツールを通して行いインタラクティブに情報トピック Cadd, method, newを提示することを可能とし，ツール利用者が可視化から自由に情報を得られるようにする．可視化を行うこ

活動を行った開発者が一意に定まるためである．とで開発履歴から開発の流れを知る必要が無くなり，

2. 1. 2 トピック解析

誰にでもそれが理解できるようになる．

トピック解析では，手順 1 で作成した文書からトピックを抽出する．トピック解析は潜在的ディリク

2 可視化手法

レ配分法（LDA: Latent Dirichlet Allocation） [1] が本章では提案する手法であるトピック解析を用いた実装された機械学習ツール MALLET [3] を用いる．

モデル構築手法とトピック可視化ツールについて述べ

LDA は自然言語処理で使われるトピックモデルを作る．トピック解析はプロジェクトにおける活動履歴に成する手法であり，入力に用いる文書集合からその文関するトピックを求めるために，VCS のコミットロ書に含まれる単語の出現確率を利用してトピックを解グコメントを利用する．可視化はプロジェクトの活動析する．解析で抽出するトピック数は自由に設定する

履歴及びその活動を行った開発者を提示することを目ことが可能であり，解析によりトピックの単語分布と的としている．また，可視化ツールは開発者単位の視入力に用いた文書ごとのトピック分布を求められる．

点やトピックに着目した視点など複数の視点を切り替

トピックは単語の確率分布であり，分布の上位のえることができ，ツール利用者がインタラクティブにキーワードからトピックの意味を知ることが可能であ必要な情報を見つけ出すことを可能としている．

る．表 1 はトピックの単語分布の例であり，トピック

A は上位のキーワードから不具合の修正のトピック
2. 1 トピックモデルの構築と分かる．同様に，トピック B はメソッドやクラストピックモデルを構築するには 5 つのプロセスがの変更，トピック C は新規メソッドの追加と分かる．

必要であり，それは順に『文書の作成』『トピック解

文書のトピック分布とは，文書がどのトピックに析』『トピック割当値の計測』『トピックの連結』『ト属するかを示した確率分布である．例えば，表 2 でピックの命名』である．図 1 はモデルの構築手順の概は文書 A はトピック A について 0.7，トピック B に要である．

ついて 0.2，トピック C については 0.1 の生起確率を2. 1. 1 文書の作成持っているため，文書 A はトピック A の意味を持っ文書の作成では，VCS のコミットログコメントかた文書である確率が高いことを示している．LDA のらトピック解析を行うための文書を作成する．文書利点として，直接的な繋がりを持たない単語でも同一とは単語の集合のことであり，文書はコミットごとにのトピックのキーワードとして抽出することが期待で作成する．また，コミットログコメントを単語に分解きることが挙げられる．ソフトウェア開発は複数人で後にステミングを行う．ステミングとは語幹以外を行われているため，同じ活動を行ったとしても人によ取り除く処理であり，例えば removed, removing →りコミットログコメントの表現揺れが起きることが考

remov のように，語幹のみにすることでトピック解えられるが，LDA であれば表現揺れを抑えて同一の析時の精度を上げることができる．コミットログコメ

トピックとして抽出されることが可能である．

ントを用いる理由は，開発で行われたことが要約されまた，本手法では区間ごとにトピック解析を行う．

たものであり開発の活動内容を含んだ単語が含まれ例えば，区間を 1ヶ月単位とする場合はコミットログていることが期待できるからであり，コミットごとにを 1ヶ月単位で区切り，区間ごとにそこに含まれるコ手順1

バージョン管理システム
抽出

リビジョン
@12

手順3, 4, 5

コミット
コミット
コミット
@13 リビジョン@14 リビジョン
＠15 リビジョン
@13
@14
@15

文書

文書

文書

手順2

トピック
LDA

出力

文書のトピック
分布

トピックモデル

入力

文書集合

図1
表2

トピックモデルの構築手順

そのため，トピックの変化を求めるためには異なるト文書のトピック分布

ピック間で類似するトピックを結びつけ 1 つのグルートピック A

トピック B

トピック C

プにする必要がある．トピックは単語分布であり，生文書 A

0.70.20.1

起確率の大きい上位のキーワードがトピックの意味

文書 B

0.20.80.0を表している．つまり，上位キーワードが一致したと

文書 C

0.1

0.00.9き，類似のトピックと考えることが可能である．しかし，上位キーワードであっても生起確率の大きさに差表3があるため，生起確率の値も考慮して類似度を計算

開発者ごとのトピック割当値

し，閾値を超えたときに 2 つのトピックを同一のトトピック A

トピック B

トピック C

ピックグループとする．トピックは過去から順に比較

開発者 α

0.9

1.00.1

し上位キーワードを記録する．もし 2 つのトピック

開発者 β0.1

0.00.9が類似トピックだった場合，過去の上位キーワードを新規のトピックの上位のキーワードで上書きし記録

ミットログのみを用いてトピック解析を行う．

する．

2. 1. 3 トピック割当値の計測

2. 1. 5 トピックの命名

トピック割当値とは，トピックの大きさ尺度であトピックの名前は 2 種類あり，トピックグループのり，同一区間に含まれる文書のトピック分布の生起確総称とトピック単体ごとの名称である．トピックグ率を合算したものである．また，トピック割当値は開ループの総称は，グループに属するトピックの単語分発者ごとに求める．例えば，表 2 がある区間のトピッ

布を利用し，トピック割当値同様に同一キーワードごク分布であり，開発者 α が文書 A および B，開発者との生起確率の値を合算し，合算値の上位であるキー

β が文書 C に属するとき，各開発者のトピック割当

ワードの 3 つを順に並べて命名する．また，トピック値は表 3 のように求まる．トピック割当値から，こ単体の名称は，トピックの単語分布の上位 5 つのキーの区間において開発者 α はトピック A とトピック B

ワードを順に並べて命名する．もし，トピックグルーに関する開発を行っていたと考えられ，同様に開発者プに属するトピックが 1 つである場合，グループのβ はトピック C に関する開発を行っていたと考えら総称とトピックの名称の上位 3 つは一致することにれる．

なる．

2. 1. 4 トピックの連結
本手法では区間ごとにトピック解析を行っているため，区間ごとに異なるトピックが抽出されてしまう．

さを比較することで，開発者がそのトピックに関する活動にどれだけ寄与していたのかを知ることができる．トピックグループに着目した場合は類似のトピックが行われていた時期のみを知ることが可能であり，また，そのトピックの活動に関わる開発者の変化を知ることが可能である．区間に着目した場合も同様に時間経過により，関係する開発者の変化を読み取ることが可能である．

2. 2. 2 可視化ツールの機能
図3

トピック可視化ツールの画面（カラムスタイル）

トピック可視化ツールには 5 つの機能がある（図 2を参照）．

2. 2 トピック可視化ツール

ツールチップはプロットエリア上にマウスポインタ

ト ピック 可 視 化 ツ ー ル は 前 節 で 構 築 し た ト
ピック モ デ ル を 用 い て 可 視 化 を 行 う．†1 実 装 はを載せると表示され，その軸上にあるドットごとのトHTML+JavaScript で行われているため Web ブラの詳細を知ることが可能である．また，開発プロジェウザが動作する環境で動作し，チャート作成ライブラ

クト全体をドットでプロットしてる場合は，その区間

リ Highcharts を利用している．

で最も開発を行っていた開発者の名前も表示するた

2. 2. 1 プロットスタイル

め，容易に主要開発者のみを知ることが可能である．

可視化を行う際のスタイルには 2 つあり，図 2 のドットスタイルと図 3 のカラムスタイルである．

ピック割当値やカラムなら各開発者のトピック割当値

凡例にはトピックグループ名が載っている．凡例の名前をクリックする事により，対応したドットなどをドットスタイルは主に横軸が時系列を表すときに用非表示したり表示することが可能である．そのため，いられる．ドットはトピックを表しており，色と形状トピックグループ名を読み取り必要の無いものを非表が一致するものは同じトピックグループに属している示にして，プロットされているグラフの可読性を上げトピックである．縦軸はトピック割当値の大きさを表ることが可能である．

しており，時間経過によるトピックの変化を知ることまた，凡例のトピックグループ名の横にあるチェッが可能である．開発プロジェクト全体に着目したもの

クボックスをオンにすることで，そのトピックグルーと開発者に着目したものの 2 種類があり，前者は従来プが属するトピックのドット上にキャプションを表示の可視化のように開発全体のトピックの変化を表してすることが可能である．キャプションにより表示されおり，後者は開発者個人のトピックの変化を表すためる情報はツールチップとほぼ同じであるが，キャプ開発者が行った活動を読み取ることができる．

ションは常に表示させることが可能であり，トピックカラムスタイルは主にトピックグループや区間に着ごとの名前を知ることも可能である．さらに，副作用目したときに用いられる．横軸はトピックグループにとしてキャプションの表示することにより，どの位置着目した場合はグループに属するトピックが抽出されにドットがプロットされているかを容易に知ることがた各区間，区間に着目した場合は区間に含まれる各トできる．

ピックが表示される．縦軸はドットスタイルと同じくプロットエリア上でマウスをドラッグすると，ドトピック割当値の大きさを表しており，そのトピックラッグして指定した範囲を拡大することが可能であに関係する開発者のトピック割当値を積み上げたものる．もし，ドットが密集して視認性が悪くても，密集になっている．積み上げられたトピック割当値の大き箇所を拡大すること解決することができる．

†1 http://www.highcharts.com/

拡大表示
凡例

ツールチップキャプション

図2

トピック可視化ツールの画面（ドットスタイル）

UNIX コマンドである git log コマンド，grep コマン

3 評価実験

ド，wc コマンドを利用したリポジトリマイニングの本章ではトピック可視化ツールの有用性を評価する方法について説明を行った．

ために行った評価実験について記述する．実験では，事前講義後，被験者を 2 つのグループに分け問題

OSS プロジェクトの Apache Ant, CAROL, jEdit,を解答してもらった．問題はプロジェクトごとに複数WALA のコミットログからそれぞれトピックモデル問を用意した．一方のグループがツールを利用するを構築し可視化を行った．そして，それぞれのコミッ

場合はもう一方はコマンドを利用して問題を解答し，トログから開発者の活動に関する 4 つの大問を作成

大問が終わると次の大問では解答方法をグループでし，被験者には可視化ツールのグラフから情報を読み入れ換え実験を行った．可視化ツールを用いる場合

取る方法とリポジトリから直接 UNIX コマンドを用は，ツールから得られる情報のみで解答してもらっいて解答を導く方法の 2 種類で解答してもらい，そた．UNIX コマンドを用いる場合は，事前講義で教えの解答に要した時間と解答の正解率で評価を行った．

たコマンド以外のコマンドでも被験者自身が普段かまた，被験者はソフトウェア工学を学ぶ 6 人の大学ら利用しているコマンドや知らないコマンドをネット院生であった．

で調べることで利用可とした．また，大問には複数の小問があり解答時間の計測は小問ごとに行った．小問

3. 1 実験手順

1 問ずつ解いてもらい，解けない限り次の小問へ進め

実験はまず事前講義としてトピック可視化ツールないようにし，また，原則として 1 問 5 分で解答し，と UNIX コマンドの事前講義を行った．可視化ツー

5 分を過ぎた場合は解答を無視して次の小問へ進んで

ルはデモ用のデータを用いて被験者にツールを実際にもらった．

使ってもらいながら，各機能の説明を行った．また，大問が全て解き終わったら，被験者のコマンドやリ表4

小問あたりの平均解答時間と正解率知識を有していることが分かっている．そのため，被全体

ツール

コマンド

験者は初めて利用する可視化ツールよりコマンドを平均解答時間

2:25.1

1:37.3

3:31.1

用いてリポジトリから情報を検索することに慣れて正解率68%83%

52%いるはずである．しかし，実験結果からは初めて利

正解率※

78%

83%78%

用する可視化ツールの方がコマンドを用いた場合よ※時間切れの問題を無視する場合りも良い結果を示している．つまり，可視化ツールを利用方法を短時間学ぶだけで使いこなすことができ，ポジトリマイニングに関する知識を問うアンケート

また，可視化により詳細なデータを直ぐに読み取るこを行った．とが可能になる．

3. 2 実験結果と考察

4 まとめと課題

実験結果は表 4 のようになった．小問あたりの平均本研究では，開発者に着目したソフトウェア開発履

時間は可視化ツールの方がコマンドを利用した場合歴の可視化を目的として OSS プロジェクトを対象にと比較して 2 分ほど早く解答されていることが分か

トピックモデルを構築し，それをツールを可視化する．また，問題の正解率に関しても，ツールの方がコることで開発履歴を分かりやすく知ることができるマンドに比べて正しく解答されている．しかし，時間ことの有用性評価と考察を行った．その結果，可視化切れの問題を無視し，解答された問題のみを対象とすツールは UNIX コマンドを利用した方法よりも短時る場合は，ツールとコマンドででは 5 ポイントの差間で情報を求めることが可能であり，短時間の学習時があるだけである．

間で利用可能であることが分かった．また，トピックそれぞれの解答時間と正解率の平均に統計的有意モデルが開発者活動を表していることも確認できた．

差があるかを有意水準を 5%とし，T 検定と F 検定を

しかし．被験者からトピック可視化ツールに関して用いて確認した．まず，解答時間の場合，制限時間に機能不足や使い方が分かりづらいなどの指摘された．

より計測できなかった問題があるためデータに対応

そのため，有用性が確認できたものの，更なる改良が関係がないため，F 検定を行い分散が不等分散である必要であることが考えられる．

かを確認し，その結果，解答時間の分散は不等分散であることが分かった．次に不等分散を考慮した T 検

参 考 文 献定を行い，両側確率が 0.000757 となり有意水準を下[1] Blei, D. M., Ng, A. Y., and Jordan, M. I.: Latent
dirichlet allocation, Machine Learning Research,Vol. 3(2003), pp. 993–1022.
[2] Hindle, A., Godfrey, M. W., and Holt, R. C.: Software Process Recovery using Recovered Uniﬁed Process Views, Proc. of ICSM ’10), 2010.
[3] McCallum, A. K.: MALLET: A Machine Learning for Language Toolkit, 2002. http://mallet.cs.
umass.edu.
[4] Thomas, S. W., Adams, B., Blostein, D., andHassan, A. E.: Studying Software Evolution Using
Topic Models, Science of Computer Programming,(2013), pp. 1–23. in press.
[5] IPA（独立行政法人情報処理推進機構）: 第 3 回オー
プンソースソフトウエア活用ビジネス実態調査 (2009年度調査）.

回った．よって，可視化ツールとコマンドの解答時間には統計的有意差があることが分かった．また，同様に正解率についても両側確率が 0.000517 であったた
め，それぞれの正解率にも有意差があることが確認された．しかし．時間切れの問題を無視する場合は両側確率が 0.167 となり，有意水準を上回るため有意差が確認できなかった．
最後に行ったアンケートにより，被験者全員が今まで UNIX コマンドの利用経験があり，また Git やSubversion の知識やリポジトリマイニングに関する