修士論文 開発履歴からのトピック抽出に基づく 開発者活動の可視化

NAIST-IS-MT1151112
修士論文
開発履歴からのトピック抽出に基づく
開発者活動の可視化ツール
山田 悠太
2013 年 3 月 6 日
奈良先端科学技術大学院大学
情報科学研究科 情報科学専攻
本論文は奈良先端科学技術大学院大学情報科学研究科に
修士 (工学) 授与の要件として提出した修士論文である。
山田 悠太
審査委員：
飯田 元 教授
（主指導教員）
松本 健一 教授
（副指導教員）
宮崎 純 准教授
（副指導教員）
市川 昊平 准教授
（副指導教員）
開発履歴からのトピック抽出に基づく
開発者活動の可視化ツール∗
山田 悠太
内容梗概
オープンソースソフトウェア（OSS）の開発が活発であり，その品質は商用利
用が可能なものであるが，品質の保証やサポートの不備などの課題を抱えている．
そのため，OSS 利用箇所で不具合が発生した場合，企業は OSS プロジェクトの開
発者に連絡を取ることが考えられ，連絡を取るべき開発者を探す必要がある．し
かし，膨大なソフトウェア開発履歴から特定の開発者を探すことは困難である．
通常，ソフトウェア開発では構成管理システムが利用されており，開発で作成・
編集されるソースコードや開発における不具合の発生・修正の履歴などを記録
している．本研究では，構成管理システムの 1 つであるバージョン管理システム
（VCS）に記録されたコミットログを用い，開発者の活動履歴を可視化する手法を
提案する．まず，VCS のコミットログからコミット単位で文書を作成する．次に
潜在的ディリクレ配分法を用いて文書からトピックを解析する．解析によって得
られたトピックの単語分布と文書に対するトピック分布を用いて開発者ごとのト
ピック割当値を求める．そして，求めた割当値から可視化ツールを用いてトピッ
クの変化の可視化を行う．
本論文では Apache Ant, CAROL, jEdit, WALA の 4 つのオープンソースソフ
トウェアプロジェクトの VCS を対象にトピック解析を行い割当値を算出し，ト
ピック可視化ツールを通して可視化を行った．また，VCS のデータから評価問題
を作成し，可視化ツールを用いる場合と git や grep などの UNIX コマンドのみを
∗
奈良先端科学技術大学院大学 情報科学研究科 情報科学専攻 修士論文, NAIST-IS-MT1151112,
2013 年 3 月 6 日.
i
用いる場合の 2 つの方法で被験者に解答してもらうことで，可視化ツールの有用
性の評価と考察を行った．その結果，可視化ツールはコマンドを用いる場合より
も短時間の学習で使用することができ，容易に情報を検索することが可能である
ことが分かった．
キーワード
リポジトリマイニング，トピックモデル，可視化，開発支援, ソフトウェア進化
ii
A Tool for Visualizing Developer Activity Based
on Topic Extraction from Version Archivies∗
Yuta Yamada
Abstract
The development of open source software (OSS) is highly dynamic. Although
OSS quality can be equal to that one of any commercial software, concerns arise
due to the lack of quality assurance and support. If a critical bug occurs in an
OSS, the company using it would require to contact the developers of the OSS,
and furthermore, they would need to find the most suitable developer by analyzing
the software development history. However, to find him from the vast amounts
of information becomes troublesome since OSS developers are distributed.
Recent software development uses configuration management systems that keep
the record of source file creation and modifications as well as bug fixes. In this
paper, we propose an approach to visualize the activity of an individual developer
using records of a version control system. The basics steps of my approach can
be described as follows. First, some documents are generated from commit log
comments. Second, some topics are derived from them using Latent Dirichlet
Allocation. Third, some topic metrics are calculated using topics and words
distribution. Finally, visualization of the data and topic metrics using a topic
visualization tool.
In this paper, four OSS projects were analyzed for topic analysis: Apache
Ant, CAROL, jEdit and WALA. I provide the development history information
∗
Master’s Thesis, Department of Information Science, Graduate School of Information
Science, Nara Institute of Science and Technology, NAIST-IS-MT1151112, March 6, 2013.
iii
using a topic visualization tool. In addition, to evaluate my approach and tool
I constructed questions for some subjects to answer using on the one hand, the
topics visualization tool and, on the other hand, UNIX commands. I evaluated
and discuss the usefulness of the proposed approach from the subjects answers.
The experimental results, indicate that the visualization tool was able to find the
required information faster than using UNIX commands.
Keywords:
Mining software repositories, Topic model, Visualization, Development support,
Software evolution
iv
目次
1. はじめに
1
2. 背景
4
2.1
潜在的ディリクレ配分法 . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
トピック進化モデル
. . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.1
HALL モデル . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
リンクモデル . . . . . . . . . . . . . . . . . . . . . . . . .
6
関連研究 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
3. 提案手法
11
3.1
文書の作成
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
トピック解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.3
トピック割当値の計測 . . . . . . . . . . . . . . . . . . . . . . . .
14
3.4
トピック可視化ツール . . . . . . . . . . . . . . . . . . . . . . . .
16
3.4.1
チャート作成ライブラリ . . . . . . . . . . . . . . . . . . .
16
3.4.2
トピックグラフ . . . . . . . . . . . . . . . . . . . . . . . .
17
3.4.3
可視化ツールの機能 . . . . . . . . . . . . . . . . . . . . .
22
4. 評価実験
27
実験内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.1
実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.1.2
事前講義 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.3
問題解答 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.4
アンケート . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.2
評価基準 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3
実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.4
考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.4.1
解答結果の有意差 . . . . . . . . . . . . . . . . . . . . . . .
33
4.4.2
学習の影響 . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.1
v
4.4.3
直前の解答を利用する問題 . . . . . . . . . . . . . . . . . .
39
4.4.4
可視化ツール及び入力用トピックデータの問題点 . . . . .
40
4.4.5
考察のまとめ . . . . . . . . . . . . . . . . . . . . . . . . .
41
5. おわりに
43
謝辞
44
参考文献
46
付録
49
A. 実験後アンケート
49
B. 実験結果詳細
50
B.1 被験者の解答と解答手順 . . . . . . . . . . . . . . . . . . . . . . .
50
B.2 実験後アンケート結果 . . . . . . . . . . . . . . . . . . . . . . . .
58
vi
目次
図目次
1
HALL モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2
リンクモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3
提案手法の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4
文書の作成
12
5
トピック変化グラフ
6
区間における積み上げグラフ
. . . . . . . . . . . . . . . . . . . .
19
7
トピックにおける積み上げグラフ . . . . . . . . . . . . . . . . . .
20
8
開発者のトピック変化グラフ
. . . . . . . . . . . . . . . . . . . .
21
9
全区間における積み上げグラフ . . . . . . . . . . . . . . . . . . .
22
10
ツールチップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
11
キャプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
12
データの表示／非表示 . . . . . . . . . . . . . . . . . . . . . . . .
25
13
グラフの状態遷移 . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
18
表目次
1
トピック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2
文書のトピック分布
. . . . . . . . . . . . . . . . . . . . . . . . .
5
3
トピック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4
文書のトピック分布
. . . . . . . . . . . . . . . . . . . . . . . . .
15
5
可視化ツール入力用のデータ構造 . . . . . . . . . . . . . . . . . .
17
6
ツールチップに表示される情報 . . . . . . . . . . . . . . . . . . .
23
7
実験に用いた OSS プロジェクトデータ . . . . . . . . . . . . . . .
27
8
実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
9
グループごとの解答する問題と方法 . . . . . . . . . . . . . . . . .
30
vii
10
小問解答時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
11
解答正誤表
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
12
平均解答時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
13
正答率 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
14
正答率（x を含まない） . . . . . . . . . . . . . . . . . . . . . . .
36
15
1 回目と 2 日目の平均解答時間 . . . . . . . . . . . . . . . . . . . .
39
16
前問を利用した問題の平均解答時間 . . . . . . . . . . . . . . . . .
39
17
実験後アンケート結果（番号 1-7） . . . . . . . . . . . . . . . . .
59
viii
関連発表論文
研究会・シンポジウム
1. 山田 悠太, 藤原 賢二, 吉田 則裕, 飯田 元, “トピック抽出に基づく開発者の
活動に着目したリポジトリ可視化手法,” 情報処理学会研究報告 ソフトウェ
ア工学研究会報告, 2012-SE-178(16), pp. 1-7 2012 年 11 月.
ix
1. はじめに
オープンソースソフトウェア（OSS）とは，ソースコードが公開されているソ
フトウェアのことである．近年では，SourceForge.net1 や GitHub2 などと言った
ソフトウェア開発プロジェクトを共有するための Web サービスが台頭してきたこ
とにより OSS の開発が活発になっている．現在，モバイルデータ通信やスマート
フォン・タブレットの普及により，インターネットへアクセスすることが容易と
なっており，それに伴って Web アプリケーションの開発が活発になっているが，
これを動かす基盤として LAMP3 と呼ばれるものがある．これは Linux, Apache,
MySQL, Perl などのソフトウェアで構成されており，これらのソフトウェアは全
て OSS である．現在の OSS は商業利用が可能な品質であるものが多く開発され
ており，その大半が利用料を必要としない．そのため，企業は OSS を商業利用す
る傾向にある [1, 2, 3]．しかし，OSS を利用する際の欠点として，OSS の品質の
保証やサポートの不備が挙げられる．品質の高いソフトウェアであっても，不具
合を持たないソフトウェアはない．もし，企業の製品に不具合が発生し，その原
因が OSS にあった場合，その対処は困難になることが考えられる．そのため，一
部企業では自ら OSS の開発に参加し品質の向上などを行っている [4]．
OSS のプロジェクトには様々な形がある．一人の開発者が中心となって開発す
るプロジェクトもあれば，複数の開発者が役割を決めて開発するプロジェクトも
ある．しかし，OSS プロジェクトの性質上，一人の開発者がプロジェクトの始めか
ら終わりまで参加する可能性は低い．それは開発者自身がプロジェクトに参加す
るかを自由に選択することができるからである．開発に対するモチベーションが
下がったり，事情により開発への参加が困難になったりした場合など，プロジェク
トから抜けることがある．そのため，OSS プロジェクトでは時間経過に従って開
発に携わるメンバーは変化していく．また，プロジェクトで開発者が担当するも
のにはソフトウェアのコンポーネントに関するものと，コーディングやバグ修正
などの活動に関するものの 2 種類がある．企業の開発プロジェクトではそのよう
1
http://sourceforge.net/
http://github.com/
3
http://e-words.jp/w/LAMP.html
2
1
な担当が明確に決まっていることが多いが，OSS プロジェクトでは明確に決まっ
ていないことが多い．もし，企業のプロジェクトにおいて OSS の利用箇所に不具
合が発生した場合，企業は OSS の不具合箇所の開発を担当した開発者に連絡を取
りたいと考える．また，公開されている OSS のソースコードを基にソフトウェア
を改良している際に一部のソフトウェアコンポーネントの振る舞いに疑問を持っ
た場合なども同様である．しかし，不具合箇所を最後に編集した人物が実際に開
発を担当した開発者であるか断定することはできない．なぜなら，元から存在す
るソースコードの編集をしたのみの可能性があるからである．例えば，不具合を
見つけてそのパッチを作成した，テストコードを元にリファクタリングを行った
などが挙げられ，このような活動だけでは元のソースコードを理解してるとは限
らない．つまり，最新の更新情報だけでは実際に連絡を取りたい開発者を断定す
ることはできず，一意に決めるには開発履歴から該当する開発者を探す必要があ
る．また，OSS プロジェクトに参加する開発者が他の参加者の活動を把握してい
るとは言い切ることは早計であり，自身の作業にのみ集中して他の開発者の活動
を把握していないことが考えられる．そのため，メーリングリスト等を用いてプ
ロジェクト全体に連絡を取っても，プロジェクトの他の開発者の動向を把握して
いる開発者がいないと返信までに多大な時間が掛かることが予想される．ソフト
ウェア構成管理ソフトのログ出力機能とキーワード検索を用いれば，連絡を取り
たい開発者を探すことが可能である．しかし，一般的にソフトウェア開発履歴は
膨大であり，いくつものキーワードを用いて検索して絞り込まない限り人間の目
で確認することは困難である．
そこで本研究では，ソフトウェア開発履歴を自動的に解析し，そのデータから
プロジェクトにおける開発者に着目した活動履歴の可視化ツールを提案する．ま
ず，ソフトウェア開発における成果物からソフトウェア開発者の活動に関係のあ
る単語を抽出し文書を作成する．そして，文書からトピックを解析する．トピッ
ク解析は文書に含まれる自然言語の確率分布などを用いて解析を行い，結果とし
てトピックと呼ばれる単語分布と解析時に利用した文書のトピック分布を生成す
る．トピック解析後．トピックの単語分布と文書に対するトピック分布を用いて
開発者ごとのトピック割当値を求める．そして，トピック割当値のデータから提
2
案するトピック可視化ツールを用いて，トピックの変化を表したグラフを描くこ
とで，利用者に開発履歴の情報を提供する．
また，可視化ツールの有用性を評価するために，OSS プロジェクトの開発履歴
から問題を作成し被験者実験を行った．実験は可視化ツールを用いる場合と git
や grep などの UNIX コマンドのみを用いる場合の 2 つの方法で問題を解答し，そ
の解答時間と解答の正答率で評価を行った．その結果，可視化ツールはコマンド
を利用した場合よりも短時間で解答を求めることができ，コマンドと同等の正答
率で解答できることが分かった．
以降，2 章ではソフトウェア工学分野におけるトピック解析とそれを利用した
既存研究について述べる．3 章では本論文で提案する手法について述べ，4 章で
は提案手法を実装したトピック可視化ツールの評価実験の結果と考察を述べる．
最後の 5 章では本研究をまとめる．
3
2. 背景
この章ではトピック解析に用いられる潜在的ディリクレ配分法（LDA: Latent
Dirichlet allocation）[5]，トピック解析を利用したソフトウェア工学分野におけ
る進化モデル及びトピック解析を利用した既存研究について述べる．
2.1 潜在的ディリクレ配分法
LDA は自然言語処理で使われるトピックモデルを作成する手法の 1 つであり，
統計情報を利用したモデルである．LDA は文書の集合からその文書に含まれる
単語の出現確率を用いることでトピック（話題）を解析する．LDA はトピック数
K を指定するとトピック zk=1...K を出力する．また，文書 d が N 個ある時，ト
ピック分布 θdi=1...N を出力する．トピック分布 θ の大きさはトピック数 K に依
存する．
抽出されるトピック z は単語の確率分布であり，その分布からトピックの意味
を考えることが可能である．例えば各トピックの上位頻出単語が表 1 である場
合，トピック A に属する単語は fix, bug, error である．このことからトピック A
はバグ修正に関するトピックであると考えられる．同様に，トピック B はメソッ
ドやクラスの変更に関するのトピック，トピック C は新しいメソッドの追加に関
するトピックと考えられる．
また，トピック分布 θ は文書がどのトピックに属するものかを表した確率分布
のことである．例えば表 2 の場合，文書 A はトピック A について 0.7，トピック
B について 0.2，トピック C については 0.1 の生起確率を持っている．この時，文
表 1 トピック
上位キーワード
トピック A
fix, bug, error
トピック B
change, method, class
トピック C
add, method, new
4
書 A はトピック A の意味を持った文書である確率が高いことを表している．
LDA の利点として，直接関係のない単語であってもトピックとして抽出する
ことが挙げられる．これは同じ文書中に含まれない単語同士であっても同一のト
ピックのキーワードとして抽出されるということである．ソフトウェア開発は複
数人で行われておりソースコードにコメントを書く場合や構成管理システムに情
報を登録する場合などにおいて表記揺れが起きることが考えられる．例えば，ソ
フトウェア開発における不具合やバグを表す単語として defect, error, bug, failure,
fault などが挙げられ，明確な意味に違いがあるものの，類似した意味を持つため
人により使い分けずに使用することが考えられる．ソフトウェアの不具合を直し
た際のコミットログコメントとして fix bug と書く人もいれば，fix error と書く人
もいると言うことである．このような場合でも LDA ではどちらも同一のトピッ
クとして抽出されることが期待できる．
2.2 トピック進化モデル
トピック進化モデルとは時間経過によるトピックの変化を表したモデルのこと
である．ソフトウェア開発プロジェクトを例にトピックの変化を説明すると，プ
ロジェクトの初期では『要求』に関するトピックが多く出現するが，
『要求』のト
ピックは時間経過により出現頻度が小さくなり，逆に『設計』に関するトピック
が多く出現するようになる．更にプロジェクトが進行すると，
『開発』や『テスト』
などのトピックが大きくなる．これが時間経過によりトピックが変化すると言う
ことである．トピック進化モデルとして，ソフトウェア工学では HALL モデルと
リンクモデルの 2 つの進化モデルが提案されている．
表 2 文書のトピック分布
トピック A
トピック B
トピック C
文書 A
0.7
0.2
0.1
文書 B
0.2
0.8
0.0
文書 C
0.1
0.0
0.9
5
全ての文書
トピックの
単語分布
LDA
文書の
トピック分布
図 1 HALL モデル
2.2.1 HALL モデル
Hall らは全文書からトピック解析した結果を用いるモデルを提案している [6]．
このモデルは全ての文書 D = {d1 , d2 , ..., dN } からトピックを解析し，その後，任
意の基準で文書を分割する手法である（図 1）．文書を分割後，各文書のトピック
分布を用いて各区間のトピック割当値の大きさを求める．文書を分割する基準は
時間単位の場合もあるが，ソフトウェア工学ではソフトウェアのバージョン単位
や， バージョン管理システムへのコミットを一定数でまとめたものも使われる．
この分割基準は後述のリンクモデルでも同様である．
2.2.2 リンクモデル
Mei らは最初に基準を決めて，その基準で文書を分割してから用いるモデルを
提案している [7]．このモデルは最初に区間を設けて文書を分割してから，分割区
間ごとの文書集合からトピック解析を行う（図 2）．次に各区間ごとに類似トピッ
クをまとめる．これはリンクモデルでは各区間ごとに抽出されるトピックが異な
るものだからである．そのため，類似トピックをトピック間で結びつける作業が
必要になる．
2.3 関連研究
この節ではソフトウェア工学分野におけるトピック解析を利用した関連研究と
そのソフトウェア開発履歴の可視化に関する研究について述べる．
6
トピック
区間1の
文書集合
LDA
トピック
区間vの
文書集合
トピック
分布
区間1
LDA
区間v
トピック
分布
図 2 リンクモデル
• トピック解析を用いた研究
Hindle らはソフトウェア開発履歴から開発プロセスを半自動的に推定し，
可視化する手法を提案している [8]．彼らの手法では，Word-bugs 解析や LDA
によるトピック解析を用いてコミットやバグ修正などを統一プロセスにお
ける各プロセスに関連付け，RUP Hump チャートを模倣した図として可視
化する．これにより，プロジェクトのどういった時期にどのようなプロセス
が重点的に行われていたかを分析することができる．この手法はプロジェ
クト全体を俯瞰することを主目的としており，開発者個人の開発プロセス
を分析するための可視化は十分ではない．また，Hindle らは Time-Window
と言う窓を定義し，その窓が示す区間のコミットログコメントから LDA を
用いてトピックを解析することでプロジェクトの流れの可視化を行ってい
る．[9]．この手法は，本論文で提案する手法に類似しているが，トピック
間を結びつけるためのトピックの類似度の計算や開発者に着目した可視化，
可視化を画像ではなくツールとして提供する点で本手法と異なっている．
Thomas らはソフトウェア開発の成果物からソフトウェアの保守や理解
支援が有効であるかをトピックモデルを利用する手法を提案している [10]．
成果物であるソースコードの識別子とコメントからトピックを抽出しリン
クモデルで進化モデルを構築し，ライングラフとヒートマップの 2 種類の
可視化を行うことで，ソフトウェアの開発の変化を表している．また．ト
ピック進化メトリクスを定義し，開発の変化のパターンを分析している．こ
の手法はソースコードの識別子とコメントを元にトピックを解析してため，
7
ソフトウェアコンポーネントの振る舞いに関するトピックが多く見つかって
いる．そのため，開発者の活動に着目する場合，この手法の適用は難しい．
Bernardi らは LDA を用いて Mozilla Firefox と Google Chrome のバグ管
理システムからトピックを抽出し，両プロジェクト間におけるバグの発生
傾向の差違について分析を行っている [11]．この論文では異なる対象から
トピックを解析した場合でも，トピック同士で傾向を比較することが可能
であることを示している．このバグ発生傾向の差違の大きさを見ることは，
リンクモデルで異なるトピックを結びつける際に役に立つと考えられる．
Chen らはソースコード中の識別子とコメントから抽出したトピックとソ
フトウェアに含まれる欠陥の数やコード行数を用いて，欠陥予測に利用で
きるトピックメトリクスを提案している [12]．この手法では文書全体に 1 度
だけ LDA を適用する方法でトピック解析を行っている．文書全体に LDA
を適用する方法は容易な方法であるが，逆に出現頻度の低いトピックが抽
出されない場合がある．そのため，局所的に出現頻度の高いトピックが消
失してしまう問題がある．
Hazeline らはトピックモデルをソフトウェアトレーサビリティを組み合
わせて，トレーサビリティの精度向上を提案している [13]．トピックモデ
ルとソフトウェアを構成しているファイルの追跡を交互に繰り返すことで，
ファイルがどのようなトピックを持ち，また，他にどのファイルが類似し
た意味を持つトピックであるかを求め，ソフトウェアの構造を可視化する．
トレーサビリティを組み合わせることで，類似するトピック間以外に，ど
のような繋がりを持っているか求めている．しかし，これまでのトピック
モデルを利用した研究と同じく，開発者単位の活動に着目している訳では
ない．
• 開発活動の可視化に関する研究
大蔵らはソフトウェア開発プロジェクトを可視化し，プロジェクトの振り
返りを支援する環境としてプロジェクトリプレイヤを開発した [14, 15]．プロ
8
ジェクトリプレイヤは，構成管理システム（CVS4 ，Subversion5 など）に記
録されたソースコード変更履歴，バグ管理システム（Bugzilla6 ，GNATS7 な
ど）に記録されたバグに関する情報，プロジェクトにおいて利用されてい
たメーリングリストの情報を時系列に沿って可視化する．既存のソフトウェ
ア開発履歴とプロジェクトリプレイヤを用いることで，プロジェクト分析
者は容易にプロジェクトを時系列に沿って俯瞰することができる．しかし，
開発履歴の可視化と開発者の活動履歴は別々の形で表しており，開発者の
活動を可視化していない．
藤原らはソフトウェアの開発履歴からリファクタリングの実施頻度と欠
陥混入頻度を測定し，リファクタリングと欠陥混入の影響について調査し
ている [16]．この手法では，開発履歴からリファクタリングの活動にのみ着
目して検出を行っている．開発履歴から特定の活動を求める際は，それぞ
れの活動に適した手法を採用する．しかし，複数の異なる活動を求めよう
とした場合，それぞれの活動を求めるのに必要な時間や抽出結果の粒度を
揃えることが困難であると考えられる．
Nielsen らはソーシャルネットワーク解析を用いて，開発者間の関連度を
求め，開発者間の繋がりを可視化する手法を提案している [17]．また，Bird
らは OSS のメールの履歴をソーシャルネットワーク解析することにより，
プロジェクトコミュニティ内にある小規模なサブコミュニティを求めてい
る [18]．彼らは巨大で複雑な OSS プロジェクトが成功を収めている背景に
はサブコミュニティの存在があると仮定し，いくつかの検証を行っている．
これら手法では開発者間の繋がりを知ることは可能であるが，開発者間の
繋がりの理由を知ることや時系列の情報を知ることはできない．
Lee らは開発者の行動パターンがソフトウェア品質に及ぼすと仮定し，
Mylyn8 から行動パターンを表すメトリクスを提案し，バグ予測を行い既存
4
http://cvs.nongnu.org/
http://subversion.apache.org/
6
http://www.bugzilla.org/
7
http://www.gnu.org/software/gnats/
8
http://www.eclipse.org/mylyn/
5
9
メトリクスと比較を行っている [19]．Mylyn とは統合開発環境 Eclipse9 プラ
グインの 1 つであり，開発者のタスクを管理し，開発者の行動をイベント
して記録する．Mylyn を利用することで，開発者の詳細な行動履歴を追跡
できるが，行動の記録が Eclipse の利用時に限定されること，Mylyn の記録
の開始や終了を開発者自身で管理しなければならない問題がある．
既存のトピック解析を利用した研究ではいずれもプロジェクト全体を対象とし
たものである．可視化する際もプロジェクト全体を対象とするのは同様であり，
プロジェクトに参加する開発者には着目されていなかった．逆にソーシャルネッ
トワーク解析における開発者間の関係を求める可視化では，プロジェクトの開発
履歴に関する情報の欠如が見られた．本論文で提案する手法では，プロジェクト
の開発の流れを表した上で，更に開発者の活動履歴の情報を付加する可視化を行
う．また，可視化をグラフ画像として出力するのではなく，動的にグラフの変更
が行えるツールを通して可視化を提供する．
9
http://www.eclipse.org/
10
3. 提案手法
本章では提案するトピック解析を用いたモデル構築手法と解析結果を可視化す
るツールについて述べる．トピック解析は開発の活動履歴に関するものを得るた
めに，バージョン管理システム（VCS）のコミットログコメントを利用する．可
視化はプロジェクトの活動履歴及びその活動を行った人物を提示することを目的
としている．また，可視化ツールは時間視点やトピック視点など複数の視点を自
由に切り替えることができ，利用者が取得したい情報のみを提示できる．図 3 は
提案手法の概要を表しており，可視化までの手順は主に 4 つに分けられる．
手順 1 文書の作成
VCS のコミットログコメントから文書を作成する．
手順 2 トピック解析
作成した文書を入力としてトピックを解析する．
手順 3 トピック割当値の計測
VCS のコミットログと解析して得られた文書のトピック分布を用いて，開
発者ごとのトピックの大きさを表すトピック割当値を求める．
手順 4 トピック割当値の可視化
トピック割当値を用いて複数の視点から可視化を行う．
以降の節では各手順の詳細について記述する．
3.1 文書の作成
本手法では，VCS のコミットログコメントからトピック解析の対象となる文書
を作成する（図 4）．VCS はソフトウェア開発履歴を管理するシステムの 1 つで
あり，一般的にソフトウェアのソースコードの変更を記録するものである．変更
を記録することをコミットと呼び，コミット時にはソースコードの変更点や変更
理由を要約したコミットログコメントを書くのが一般的である．つまり，コミッ
11
VCS
抽出
リビジョン
@12
コミット
@13 リビジョン
@13
コミット
@14 リビジョン
@14
コミット
＠15 リビジョン
@15
文書
文書
文書
文書集合
入力
トピック
LDA
出力
可視化
文書のトピック
分布
図 3 提案手法の概要
リビジョン@12
コミットログ
コミット
ステミング
図 4 文書の作成
12
リビジョン@13
文書@12
トログコメントからソフトウェア開発の活動内容を知るための単語を得ることが
期待できる．また，コミットログのみを用いることでソフトウェア開発環境に依
存しない利点がある．
文書とは，単語の集合である．コミットログコメントを単語に分解し，その単
語集合を文書とする．また，本手法では単語ごとにステミングを行う．ステミン
グを行うのは同義の単語を 1 つにまとめることができ，2.1 節で説明した LDA の
分析精度を向上させるためである．文書の作成は英文と和文で異なる．
• 英文
英文は単語ごとにスペースで分かれているため，スペースを頼りに単語
に分ける．その後，単語ごとにステミングを行う．英語におけるステミン
グは単語を語幹のみにする処理である．例えば，initially や initialize にス
テミングを行うと initi となる．
• 和文
和文は英文とは違い，スペースのような単語の区切りとなる記号がない
ため，形態素解析を行い単語に分割する必要がある．形態素解析とは，文
章を意味のある最小の単位にまで分割し，品詞を判別する処理である．次
にステミングを行うが，日本語におけるステミングは動詞と形容詞を原形
にする処理のことである．例えば，
「見た」は「見る」，
「白く」は「白い」の
ように活用されているものを原形に置換する．
文書はコミットごとに作成する．コミットごとに文書を作成することで，文書
にコミットの日時や変更を行った開発者の名前などを関連付けることができる．
3.2 トピック解析
トピック解析は LDA が実装された機械学習ツール MALLET[20] を用いる．ト
ピック解析に LDA を用いるのは 2.1 節で述べたように，潜在的な関係をトピック
として抽出することが期待できるからである．ソフトウェア開発は大勢の人の手
13
で行われており，開発者ごとの表記揺れを対処するために LDA を用いるのは適
当である．
トピック解析には入力として文書集合を使い，出力として表 3, 4 ようなトピッ
クを表す単語分布と入力に用いた文書のトピック分布を得る．HALL モデルでは
図 1 のように全ての文書を入力とするため，LDA を適用するのは 1 回限りであ
る．リンクモデルでは図 2 のように最初に区間を決め，その区間に含まれる文書
集合に LDA を適用するため，区間の数だけ LDA を適用する必要がある．本手法
における区間はコミットを行った日時を基準とする．例えば，3ヶ月単位で区間
を分割する場合，1 月から 3 月が 1 つの区間となり，その区間に含まれるコミッ
トログコメントから作成した文書の集合に LDA を適用する．
3.3 トピック割当値の計測
本手法では，開発者ごとのトピック割当値 TA を文書のトピック分布を用いて
求めることで，開発者ごとの活動履歴を分析する．トピック割当値とは，トピッ
クの大きさを表す尺度であり，区間に含まれるトピック分布の生起確率の合算値
となる．また，文書の開発者属性ごとにトピック割当値を求める．Author は文書
の開発者属性を得ることを意味しており，m は開発者名を表している．
TAmk =
N
∑
θdn k (Author (dn ) = m)
(1)
n=1
表 2 をある区間のトピック分布と仮定し，文書 A, B に開発者 α，文書 C に開
発者 β の属性を持つと仮定する．この時，開発者 α の合算値はトピック A が 0.9，
表 3 トピック
上位キーワード
トピック A
fix, bug, error
トピック B
change, method, class
トピック C
add, method, new
14
トピック B が 1.0，トピック C の値は 0.1 となる．開発者 β も同様にトピック A
が 0.1，トピック B が 0.0，トピック C が 0.9 となる．つまり，この区間において
開発者 α はトピック A とトピック B に関する開発を行っていたと考えられ，同様
に開発者 β はトピック C に関する開発を行っていたと考えられる．
HALL モデルの場合，文書を月単位で区切り，区間ごとにトピック割当値を求
める．リンクモデルでは，区間ごとにトピックが独立しているため，それぞれの
区間でトピック割当値を求めることになる．また，リンクモデルでは独立してい
るトピック同士を結びつける処理が必要となる．本手法ではトピックが持つ単語
分布を利用する．トピック間の結びつけは次の手順で行う．
手順 1 時系列の古い区間のトピックから順に見る．
手順 2 区間に含まれるトピックごとに，そのトピックの上位頻出単語と過去のト
ピックが持つ上位頻出単語を比較する．
• 一致した単語があった場合，新しい方のトピックの単語分布の値を一
致した単語の分だけ合算する．
手順 3 合算値が閾値を超えた場合，区間の異なるトピックを 1 つに結びつける．
手順 4 トピックの単語を記録する．
• 過去のトピックと結びつかなかったトピックは，新しいトピックとし
てそのトピックが持つ単語を記録する．
• 過去のトピックと結びついた場合，過去のトピックの単語を新しいト
ピックの単語で上書きして更新する．
表 4 文書のトピック分布
トピック A
トピック B
トピック C
文書 A
0.7
0.2
0.1
文書 B
0.2
0.8
0.0
文書 C
0.1
0.0
0.9
15
手順 5 全ての区間で手順 2，3，4 の処理を繰り返す．
• トピック名は，そのトピックの全ポイントに含まれる単語分布で決ま
る．同一のトピックが複数のポイントにある場合，各単語分布の同一
単語の確率を合算したものの上位 3 位を選択しトピック名とする．
• 各トピックのポイントごとにサブタイトルが付けられ，それはそのポ
イントの単語分布の上位 5 単語を抽出し，トピック名とする．
3.4 トピック可視化ツール
この節ではトピック割当値の可視化を行うために開発した可視化ツールについ
て記述する．可視化は 3.3 節で求めたトピック割当値を利用し，複数の視点を持つ
グラフを表示するツールで提供する．可視化の結果は画像データではなく，プロ
グラムを用いてインタラクティブに可視化グラフを描くことで，ツール利用者が
自由に可視化結果を得ることが可能になる．可視化ツールは JavaScript とチャー
ト作成ライブラリを用いて実装する．入力データはトピック割当値だけではなく，
トピック名や開発者の名前を含んでおり，それらのデータを JSON10 形式で記述
しツールへの入力とする．入力データのデータ構造は表 5 の通りである．以降の
項では可視化ツールが提供する各グラフの説明と機能について記述する．
3.4.1 チャート作成ライブラリ
可視化には Highcharts11 と呼ばれる JavaScript のライブラリを利用する．JavaScript
であるため，Web ブラウザが動作する環境であればツールを動作させることが可
能である．Highcharts ライブラリは容易に使うことができる．また，豊富な API
を有しており，複雑なグラフを描くことやインタラクティブなグラフを提供する
ことが可能である．更に，Web ページにはレファレンスやサンプルスクリプトが
公開されているため，各 API の動作確認も容易にできる．
10
11
http://www.ietf.org/rfc/rfc4627.txt
http://www.highcharts.com/
16
3.4.2 トピックグラフ
可視化ツールには 5 つのトピックグラフを表示することが可能である．
1. トピック変化グラフ
トピック変化グラフは，横軸を区間ごとの時系列，縦軸をトピック割当
値の値としてプロットしたグラフである．3.3 節では開発者ごとに割当値を
求めたが，このグラフは同一のトピック割当値を合算してから描いている．
プロジェクトの開発履歴の流れを知りたい際に，トピックの変化を俯瞰的
に描くこのグラフが有用である．図 5 はトピック変化グラフの例である．ト
ピックごとにポイントの色と形状が異なり，凡例にトピックの名前を載せ
ている．
2. 区間における積み上げグラフ
ある区間に着目したときに，その区間に含まれるトピックの大きさを表
すグラフである．横軸はトピック名を表しており，縦軸はトピック変化グラ
フと同じく開発者ごとのトピック割当値を合算した値を表しているが，開
発者ごとに色分けされており積み上げグラフとなっている．このグラフで
は他の開発者が区間においてトピックに寄与していた度合を見ることが可
能となる．図 6 は区間における積み上げグラフの例である．横軸のトピッ
表 5 可視化ツール入力用のデータ構造
キー
値
title
タイトル（文字列）
subtitle
サブタイトル（文字列）
date
区間情報（文字列配列）
topics
トピック名（文字列配列）
topicName
ポイントごとのトピック名（2 次元配列）
series
author
（オブジェクト）
pointset 開発者のトピック割当値データ（2 次元配列）
開発者名（文字列）
17
図 5 トピック変化グラフ
18
図 6 区間における積み上げグラフ
クの並びに特別な意味はなく，凡例にはグラフの色と開発者名の対応が記
載されている．
3. トピックにおける積み上げグラフ
あるトピックに着目したときに，そのトピックが含まれる区間のトピッ
クの大きさを表すグラフである．横軸は時系列を表し，縦軸は区間におけ
る積み上げグラフのグラフと同じく開発者ごとのトピック割当値の合算値
を表す．1 つのトピックの変化のみを見ることができ，どのような開発者が
携わっているかも視覚的に知ることが可能である．図 7 がトピックにおけ
る積み上げグラフの例である．横軸は時系列を表しているが，トピックが
含まれない区間は省略されているため，トピックに関する活動が行われて
19
図 7 トピックにおける積み上げグラフ
いた時期のみを容易に読み取ることが可能である．また，このグラフの色
と開発者の対応は区間における積み上げグラフと一致している．
4. 開発者のトピック変化グラフ
1 のグラフのように全開発者の合算値ではなく，特定の開発者のみのデー
タを利用したグラフである．特定の開発者の開発履歴のみを見たい時に役
に立つ．図 8 は開発者のトピック変化グラフの例である．開発者が関わって
きた区間のみをグラフとして描くため，開発者の活動期間も容易に知るこ
とが可能である．
5. 全区間における積み上げグラフ
2 の区間を全区間に拡張したものであるが，ポイントは開発者ではなく
20
図 8 開発者のトピック変化グラフ
21
図 9 全区間における積み上げグラフ
区間で積み上げたものになっている．開発全体のトピック割当値の大小を
比較することができ，また，区間ごとにポイントがあるため，トピックがど
の時期にどれだけ変化しているかを容易に知ることも可能である．図 9 は
全区間における積み上げグラフの例である．
3.4.3 可視化ツールの機能
可視化ツールは以下の機能が実装されている．
• ツールチップ
• キャプション
22
• ポイントの表示／非表示
• グラフの拡大
• グラフの状態遷移
ツールチップは，グラフ上にマウスポインタを載せると情報を表示させる機能
のことであり，図 10 のように表示される．マウスポインタのある横軸の項目名
とそこに存在する各ポイントの情報が全て表示される．表示される情報はグラフ
によって異なっており，詳細は表 6 の通りである．ツールチップはグラフから素
早く情報を取得することが可能である．トピック変化グラフの場合，プロットさ
れているポイントが何のトピックなのかを凡例を参照することなく知ることが可
能であり，指定した区間のトピックの情報を短時間で確認することができる．
キャプションは，グラフ上の各ポイントに主要開発者名とポイントのトピック
名を表示させる機能である．これはトピック変化グラフでのみ機能し，凡例横の
チェックボックスでトピックごとに情報の表示・非表示を選択することができる
（図 11）．初期状態では全て非表示になっている．ツールチップとは異なり，キャ
プションは常にグラフ上に情報を表示させることが可能である．また，キャプショ
ンによりトピックのポイント上に情報が表示されるため，凡例からトピックのポ
表 6 ツールチップに表示される情報
グラフ種類
ツールチップの情報
トピック名
トピック変化グラフ
トピック割当値の合算値
主要開発者
区間における積み上げグラフ
トピック名
トピックにおける積み上げグラフ
開発者名とそのトピック割当値
開発者のトピック変化グラフ
トピック名
割当値
全区間における積み上げグラフ
区間とそのトピック割当値
23
図 11 キャプション
図 10 ツールチップ
イントがグラフ上のどこにプロットされているかを容易に知ることが可能となる．
凡例のトピック名をクリックする事により，任意のポイントを非表示にしたり，
表示したりすることができる．クリックされたトピック名はグレーアウトし，グ
ラフ上からそのトピックに関するポイントが非表示になる（図 12(a)）．もう 1 度
クリックすると，再びポイントが表示される（図 12(b)）．初期状態では全てのポ
イントが表示されている．表示・非表示されるポイントによってはグラフエリア
がリサイズされるため，グラフの視認性は維持される．この機能を利用すること
で，利用者の必要なトピックのポイントのみを表示させたり，逆に必要のないト
ピックのポイントを非表示にしたりすることができ，可視化の情報を整理するこ
とが可能となる．
グラフの拡大は，グラフのプロットエリア上で拡大したい範囲をドラッグして
指定することで行う．ドラッグして指定した領域を拡大表示し，場合によっては
視認性を保つためにグラフがリサイズされる．元の縮尺に戻すにはプロットエリ
アの右上のリセットボタンをクリックすることで可能である．グラフが拡大でき
るのは横軸の項目のみである．プロジェクトの歴史の長さや区間の間隔，トピッ
ク数によってはデータが膨大になってしまい，初期状態ではグラフの視認性を低
24
(a) 非表示
(b) 表示
図 12 データの表示／非表示
下する可能性がある．また，一部の期間にのみ存在するトピックがあったりする．
そのような場合にグラフを拡大し一部区間を表示させることでグラフの視認性を
向上させる．
グラフの状態遷移とは，グラフの上のポイントやボタンをクリックすることで
別の視点に着目したグラフに遷移することである．図 13 はグラフの状態遷移を表
したものである．可視化ツール起動時はトピック変化グラフが表示される．この
時，グラフ上のトピックのポイントをクリックした場合，クリックされたトピッ
クに関する積み上げグラフに遷移する．また，ポイント以外をクリックした場合，
ツールチップに表示されている区間に関する積み上げグラフに遷移する．遷移し
た先の積み上げグラフのポイントは開発者を表しており，このポイントをクリッ
クした場合，クリックした開発者に関するトピック変化グラフに遷移する．開発
者のトピック変化グラフでは起動時のグラフと同様に，ポイントをクリックする
とそのポイントのトピックに関する積み上げグラフに遷移する．プロットエリア
のグラフをクリックして遷移する以外に，Initialize ボタンと Total Topics ボタン
をクリックすることで別のグラフに遷移することが可能である．Initialize ボタン
25
グラフ上のポイントをクリック
ポイントをクリック
トピックにおける積み上げグラフ
Initialize ボタン
クリック
ポイント以外でクリック
トピック変化グラフ（ツール起動時）
開発者のトピック変化グラフ
ポイントをクリック
Total Topics ボタン
区間における積み上げグラフ
クリック
ポイントをクリック
全区間における積み上げグラフ
図 13 グラフの状態遷移
をクリックした場合，起動時のトピック変化グラフに遷移し，Total Topics ボタ
ンをクリックした場合，全区間における積み上げグラフに遷移する．この 2 つの
ボタンは常に表示されており，グラフがどのような状態でも遷移することが可能
である．
26
4. 評価実験
本章では 3.4 節で述べたトピック可視化ツールの有用性を評価するための実験
とその結果・考察を述べる．評価実験は被験者に問題を提示し，可視化ツールを
用いる場合と UNIX コマンドのみを用いる場合の 2 つの方法で解答する形式で
実施した．実験の問題は OSS プロジェクト Apache Ant12 ，CAROL13 ，jEdit14 ，
WALA15 のバージョン管理システムのコミットログから作成し，プロジェクトご
との 4 つの大問，合計 18 の小問を用意した．実験に利用した OSS プロジェクト
に関する情報は表 7 の通りである．また，被験者には大問が終了するごとに各小
問の解答手順について記述してもらい，全ての問題が終わった後にアンケートを
記述してもらった．その後，実験結果とアンケートから可視化ツールの有用性を
評価する考察を行った．
4.1 実験内容
評価実験では，最初に可視化ツールと UNIX コマンドの使い方についての事前
講義を行った．次に，被験者に可視化ツールとコマンドの 2 つの解答方法を用い
て問題を解答してもらった．可視化ツールを用いる解答は，可視化ツールで得ら
れる情報のみを用いて解答し，コマンドを用いる解答は，OSS プロジェクトのソ
表 7 実験に用いた OSS プロジェクトデータ
プロジェクト名
開発期間
コミット数
開発者数
Apache Ant
2010 年 01 月 - 2013 年 01 月
12789 回
46 人
CAROL
2002 年 06 月 - 2012 年 09 月
2236 回
37 人
jEdit
2001 年 09 月 - 2012 年 10 月
7151 回
41 人
WALA
2006 年 11 月 - 2013 年 01 月
3611 回
22 人
12
http://ant.apache.org/
http://carol.ow2.org/
14
http://www.jedit.org/
15
http://wala.sourceforge.net/
13
27
フトウェア開発履歴のデータを Git 形式で配布し，直接 Git のデータから情報を
取得してもらい解答してもらった．また，大問が終わるごとに被験者の解答手順
について記述する時間を設けた．最後に，被験者の知識や可視化ツールを利用し
た感想を問うアンケートを行った．以降では，実験に用いた環境と実験の事前講
義，問題解答，アンケートの詳細について述べる．
4.1.1 実験環境
実験で用いるパソコンの環境は被験者間で統一した．可視化ツールは JavaScript
で実装されているため，パソコンのスペックに可視化ツールの応答速度が大きく
左右される．応答速度の違いが実験結果に影響を与えないために，実験環境を統
一することでツールの応答速度のばらつきを抑えた．実験に用いたパソコンの環
境は表 8 の通りである．
実験で使用する全てのデータはあらかじめローカルストレージに置いた．また，
事前に可視化ツールの入力とする JSON ファイルを作成しておき，実験でツール
を使う場合はトピック割当値を解析する時間を含めないことにした．本実験で入
力に用いるトピック割当値のデータは，モデルをトピック進化モデルのリンクモ
表 8 実験環境
名称
OS
CPU
メモリ
ストレージ
ディスプレイ解像度
ブラウザ
JavaScript ライブラリ
可視化ライブラリ
Git
内容
Windows 7 SP1 (64bit)
Intel Core i5 M560 2.67GHz
4.00GB
ハードティスクドライブ
1366 x 768 （13.3 インチ）
Google Chrome v24
jQuery 1.9.0 (Minified)
Highcharts 2.3.5
msysgit 1.8.0
28
デル，1 区間を 3ヶ月単位，区間あたりのトピック数を 10 個に設定し作成した．
区間を 3ヶ月単位としたのは，トピック解析を行うためのデータ量を確保するた
めである．また，トピック数を 10 個としたのは，リンクモデルでデータを構築
する際のトピック間の結びつけにおいて，多くの結びつきを得られるパラメータ
が 10 個前後だったからである．
4.1.2 事前講義
問題解答前に，あらかじめ可視化ツールの使い方を一通り説明することで被験
者のツールに関する知識を統一した．可視化ツールの説明は 3.4.3 項で記述した実
装されている機能について行った．また，ツールのデモンストレーションを行い，
同時に被験者には実験と無関係のデータを用いてツールを使用し使い方を確認さ
せた．次に，一般的な UNIX コマンドについて説明し，コマンドに関する最低限
の知識を被験者に教えた．評価実験の前に行った予備実験の結果から今回の実験
で説明するコマンドは git の log コマンド，grep，wc の 3 つとした．また，リダ
イレクトやパイプ，grep を使った OR 検索や AND 検索の方法を簡単に説明した．
4.1.3 問題解答
問題解答では，被験者が問題を解く解答時間を測定した．問題は大問ごとに複
数の小問が設けられており，被験者ごとに小問単位で解答時間を測定した．被験
者は小問を解く度に終了の発言をし，それをもってその小問の解答時間を記録し
た．大問を切り替える際は時間の測定を停止した．また，この時に被験者には小
問ごとの解答手順を記述してもらった．
実験は 1 つの小問に対して予備実験の解答時間を参考に 5 分の制限時間とした．
もし，制限時間内に解答ができない場合は無解答として扱った．また，いくつか
の問題は直前の問題の答えを用いるものがあり，そのような問題の制限時間は小
問の数だけ増加させた．例えば，後述する Apache Ant の小問 1，2，3 は連続し
ているため，制限時間は 3 問合わせて 15 分とした．
29
問題は Apache Ant, CAROL, jEdit, WALA の順で行った．また，被験者を先に
可視化ツールを使って解答するグループと先に UNIX コマンドを使って解答する
グループの 2 つに分け，大問が終わるごとに，解答方法を入れ替えた．前者のグ
ループは Apache Ant と jEdit の問題をツールを使って解答し，CAROL と WALA
の問題はコマンドを使って解答した．同様に，後者のグループは Apache Ant と
jEdit はコマンドを使い，CAROL と WALA は可視化ツールを使って解答した．
表 9 は上記の内容をまとめたものである．
可視化ツールを使う被験者は，ツール以外から情報を取得してはいけないが，
ツールの使い方など事前講義で理解できなかった点に関する質問は許可した．ま
た，ツールの多重起動を許可した．UNIX コマンドを使う被験者は，分からない
コマンドがある場合，インターネットで検索することが許されていた．
各大問の問題は次の通りであった．ただし，解答を可視化ツールで求める場合，
年月を問う問題は年月ではなくトピック解析した区間で答えても良いものとした．
• Apache Ant
1. Apache Ant プロジェクトの開発が最も盛んだった年月を答えなさい．
2. 1 の答えの区間で活発に活動に参加していた人物を上位 3 人を順に答
えなさい．
3. 2 の答えの 1 位の人物のプロジェクト参加期間の始まりと終わりの年
月を答えなさい．
4. checkstyle を最も行っていた年月を答えなさい．
表 9 グループごとの解答する問題と方法
解答方法
グループ
可視化ツール
UNIX コマンド
先行可視化ツール
Apache Ant, jEdit
CAROL, WALA
先行 UNIX コマンド
CAROL, WALA Apache Ant, jEdit
30
5. 4 の答えの月に最も checkstyle を行っていた開発者を 1 人答えなさい．
6. 5 の答えの人物がプロジェクト参加期間の始まりと終わりの年月を答
えなさい．
• CAROL
1. Maven プラグインの利用を開始した年月を答えなさい．
2. Maven プラグインを利用していた開発者上位 3 人を順に答えなさい．
3. 不要なフォルダの削除を最も行っていた年月を答えなさい．
4. 3 の答えの年月で不要なフォルダの削除を最も行っていた人物は誰か
答えなさい．
5. 開発者 benoitf が最も開発を行っていたのは年月を答えなさい．開発と
はコードの削除や更新作業を意味する．
• jEdit
1. コンパイルに関係する不具合の修正を行っている人物を上位 2 人を答
えなさい．
2. 1 の答えの人物のそれぞれのプロジェクト参加期間の始まりと終わり
の年月を答えなさい．
3. コーディングスタイルの修正を最も行っていた年月を答えなさい．
4. 3 の答えの年月でコーディングスタイルを最も行っていた人物を答え
なさい．
• WALA
1. ソースコードコメントの調整を最も行っていた年月を答えなさい．
2. ソースコードコメントの調整を最も行っている開発者を 1 人答えなさい．
3. 2007 年 1 月から 3 月に最もプロジェクトに参加していた開発者を上位
2 人答えなさい．
31
4.1.4 アンケート
実験後に記名式アンケートを行った．アンケート（付録 A）では，被験者の
UNIX コマンドやリポジトリマイニングの知識，可視化ツールの使いやすさや，
ツールとコマンドの解答方法の比較についてを回答してもらった．リポジトリマ
イニングとは構成管理システムのデータから，有用なデータを抽出することであ
る．被験者の知識について問うアンケートは UNIX コマンドを用いて解答する際
の結果を考察する時に用いるために行った．本実験ではコマンドの知識が被験者
ごとに統一されておらず，知識の偏りがあり，また，リポジトリマイニングの経
験にも偏りがあった．そのため，被験者ごとに解答時間に差が生まれることが考
えられたからである．使用後の可視化ツールについて問うアンケートは 4.2 節で
後述する評価基準を用いた考察とは別に，被験者によるツールのユーザビリティ
を考察するために行った．
4.2 評価基準
可視化ツールの評価基準は解答時間と解答の正答率の 2 つとした．解答時間は
4.1.3 項で説明した小問あたりの作業時間を用いた．しかし，制限時間を過ぎ解答
されなかった小問については，解答時間を検証する際に扱わないものとした．解
答の正答率は解答時間とは異なり解答されなかったものをデータとして扱わない
ものとする場合と間違いにする場合の 2 つに場合分けし検証した．
また，t 検定16 と F 検定17 を用いて有意差を確認した．t 検定とは 2 つのデータ
群の平均に統計的有意差があるかを調べるものである．同様に，F 検定では 2 つ
のデータ群の分散に統計的有意差があるかを調べるものであり，F 検定の結果次
第で t 検定の方法が異なる．有意差があるとは 2 つのデータの差には意味がある
ことが考えられることであり，有意差がないとは 2 つのデータの差は偶然発生し
たものとすることである．つまり，t 検定で有意差があるとなれば 2 つのデータ
の平均には差があると言え，F 検定で有意差があるとなれば 2 つのデータの分散
16
17
Microsoft Excel の T.TEST を利用
Microsoft Excel の F.TEST を利用
32
は異なっていると言える．本実験では，有意水準を 5%とし，両側確率が有意水
準を下回った場合，統計的有意差があると言える．両側確率とは分布の両端の確
率を示す確率であり，この確率が有意水準よりも大きいと偶然であると判断され
有意差がないことになる．
4.3 実験結果
実験は情報科学研究科に所属する 4 名を対象に実施した．実験参加者の条件は
UNIX コマンドを使ったことのある人とした．
実験結果は表 10, 11 のようになった．表 10 は被験者の小問の解答時間である．
x は制限時間により解答されなかった問題である．本実験では合計 8 問の小問が
制限時間により解答されなかった．表 11 は解答の正誤表である．正解は 1，間違
いは 0，一部正解は分数で表している．各被験者の詳細な解答は付録 B.1 に記載
する．
小問の平均解答時間は表 12 の通りである．被験者全体の平均は 2 分 53 秒，可
視化ツールのみでは 1 分 51.7 秒，UNIX コマンドのみでは 4 分 3.9 秒であった．平
均時間を計算する上で，解答されなかった小問については考慮しなかった．また，
解答の正答率は表 13 の通りであり，被験者全体の正答率は 69%，可視化ツール
のみでは 82%，UNIX コマンドのみでは 55%であった．そして，解答されなかっ
たものを除外した場合の正答率は表 14 の通りであった．
4.4 考察
実験結果から可視化ツールと UNIX コマンドについて解答時間と正答率，被験
者アンケートを踏まえて考察を行った．
4.4.1 解答結果の有意差
可視化ツールと UNIX コマンドの解答時間と解答の正答率の平均に統計的有意
差があるかを確認した．
33
表 10 小問解答時間
問題番号
Ant
被験者 A
被験者 B
可視化ツール
被験者 C
被験者 D
UNIX コマンド
小問 1
4:22.3
3:36.6
8:01.4
15:00.0
小問 2
3:12.2
1:14.4
x
x
小問 3
0:38.9
1:59.9
x
x
小問 4
4:02.6
1:43.0
3:05.3
7:30.0
小問 5
1:00.2
0:12.7
3:05.3
7:30.0
小問 6
0:29.6
0:32.9
3:05.3
x
CAROL
UNIX コマンド
可視化ツール
小問 1
4:05.2
5:15.4
1:09.6
1:44.4
小問 2
x
2:28.7
1:23.9
4:33.8
小問 3
x
0:48.1
1:05.4
0:53.9
小問 4
x
0:17.3
0:26.3
0:44.8
小問 5
4:40.1
4:05.0
0:53.4
6:40.9
jEdit
可視化ツール
UNIX コマンド
小問 1
2:05.3
3:22.5
4:07.7
9:26.6
小問 2
1:36.2
0:19.0
1:43.2
x
小問 3
1:40.2
1:31.7
0:52.3
4:37.8
小問 4
0:11.0
0:07.5
0:56.6
0:34.7
WALA
UNIX コマンド
可視化ツール
小問 1
2:37.6
1:11.1
2:55.0
3:39.0
小問 2
2:45.4
0:16.3
2:36.8
0:41.1
小問 3
3:17.5
8:22.1
1:09.4
2:26.2
34
表 11 解答正誤表
問題番号
Ant
被験者 A
被験者 B
可視化ツール
被験者 C
被験者 D
UNIX コマンド
小問 1
1
1
1
1/2
小問 2
1
1
x
x
小問 3
1
1
x
x
小問 4
0
1
1
0
小問 5
0
1
1
1
小問 6
0
1
1
x
CAROL
UNIX コマンド
可視化ツール
小問 1
1
1
1
1
小問 2
x
1/3
1
2/3
小問 3
x
0
1
1
小問 4
x
1
1
1
小問 5
0
0
1
0
jEdit
可視化ツール
UNIX コマンド
小問 1
1/2
1
1/2
1/2
小問 2
1/2
1
1/2
x
小問 3
1
1
1
1/2
小問 4
1
1
1
1
WALA
UNIX コマンド
可視化ツール
小問 1
1
1
1
0
小問 2
1
1
1
1
小問 3
1
1
1
1
35
表 12 平均解答時間
対象
平均解答時間
被験者 A
2:27.0
被験者 B
2:04.7
被験者 C
2:17.3
被験者 D
4:43.1
被験者全体
2:53.0
可視化ツール
1:51.7
UNIX コマンド
4:03.9
表 13 正答率
表 14 正答率（x を含まない）
対象
対象
正答率
正答率
被験者 A
56%
被験者 A
67%
被験者 B
85%
被験者 B
85%
被験者 C
83%
被験者 C
94%
被験者 D
51%
被験者 D
65%
被験者全体
69%
被験者全体
78%
可視化ツール
82%
可視化ツール
82%
UNIX コマンド
55%
UNIX コマンド
73%
36
最初は解答時間の有意差を確認した．制限時間により解答されなかった問題が
あるためデータに対応関係がない．よって，まず F 検定を行い分散が等しいか確
認した．F 検定を行うと両側確率は 1.52 × 10−5 と算出された．これは有意水準
5%以下であるため，分散に統計的有意差があると言えた．つまり，2 つの方法の
解答時間の分散は分散が等しくない不等分散であることが分かった．次に t 検定
を行い，平均に有意差があるかを確認した．F 検定の結果から不等分散であるこ
とを考慮して両側確率を求めると，0.007 となった．これは有意水準 5%以下であ
るため，2 つの方法の平均には統計的有意差があると言えた．よって，可視化ツー
ルと UNIX コマンドの解答時間には有意差があり，表 12 より，ツールを利用し
た方がコマンドを用いる場合に比べて半分の時間で解答を導くことが可能である
ことが分かった．
次に解答の正答率の有意差を確認した．ただし，制限時間により解答されなかっ
た問題を間違いに含む場合と含まない場合の 2 通りの有意差を確認した．
• 間違いに含む場合
解答されなかった問題を間違いに含む場合，データに対応関係がある．それ
を考慮した t 検定を行うと両側確率は 0.014 となった．これは 0.014 < 0.05
であるため，統計的有意差があると言えた．つまり，制限時間を設けた場
合，解答の正答率はツール側の方が良い．
• 間違いに含まない場合
解答されなかった問題を間違いに含まない場合，データに対応関係がない
ため，先に F 検定を行い分散の有意差を確認した．F 検定を行うと両側確
率が 0.72 となった．これは 0.72 > 0.05 なので，分散が等しい等分散である
ことが分かった．等分散であることを考慮した t 検定を行うと，両側確率は
0.34 となり，0.34 > 0.05 であるため，統計的有意差はないことが分かった．
解答されなかった問題を間違いに含む場合，正答率に統計的有意差があること
を確認した．しかし，表 11 を見ると，解答されなかった問題は実験の前半で多く
見られた．前半ではコマンドを用いた解答全体の約 36%が制限時間で解答されず
間違いとされているが，後半ではその割合が約 7%しかなかった．これは被験者
37
が実験中にコマンドの操作に慣れ，コマンドを用いた情報検索が洗練してきたこ
とが考えられる．また，付録 B.2 のアンケート番号 1 のデータより，今回の被験
者に UNIX コマンドを熟知している人は 1 人もいないことが分かった．もし，被
験者が UNIX コマンドに精通している人であったならば，間違いを含まない場合
の結果のように，解答方法により正答率に有意差は生まれないと考えられる．
4.4.2 学習の影響
実験の前半と後半の結果から比較し，被験者の学習について考察する．表 15
は，各解答方法の 1 回目と 2 回目を分けて，小問の平均解答時間を算出したもの
である．可視化ツール 2 回目の平均解答時間は 1 回目の解答時間から 10%短縮さ
れただけだった．しかし，UNIX コマンドの場合は有意差はないが 36%解答時間
が短縮されていた．4.4.1 項でも述べたように，被験者が 2 回目の UNIX コマンド
解答時は解答方法に慣れてきた，コマンドの操作方法に慣れてきたことが考えら
れる．また，1 回目の平均解答時間には有意差があるが，2 回目の結果では有意差
はなかった．つまり，コマンドを用いた方法はコマンドの使用経験により，ツー
ルと変わらない結果を生むことが考えられる．
しかし，可視化ツールは学習による解答時間の短縮は効果が小さいものの，コ
マンドに不慣れや知らない人であっても短時間の説明でツールを使うことが可能
になると考えられる．本実験で用いた可視化ツールの使い方は事前講義時の 30
分間で説明したのみであった．被験者はコマンドには精通しているとは言えない
が，今まで何度も使用したものであり，その利用時間はツールよりは長時間であ
ると考えられる．更に本実験の結果の大半は可視化結果の方が優れた結果を示し
ていた．つまり，可視化ツールを使用することで，UNIX コマンドを用いたリポ
ジトリマイニングの知識がなくても，コマンドやマイニングに精通している人と
同程度に開発履歴から情報を得ることが可能であると考えられる．
38
4.4.3 直前の解答を利用する問題
Apache Ant の小問 2, 3, 5, 6 や CAROL の小問 4，jEdit の小問 2, 4 は直前の解
答を用いた問題であった．これらの問題は前問の内容をそのまま引き継ぐため比
較的短時間で解答できると考えられる．解答時間の平均に統計的有意差が確認で
きるのは可視化ツールを用いた解答において前問の解答を利用する場合と利用し
ない場合であった．表 16 から，解答方法に問わず前問の解答を利用する問題は，
利用しない場合に比べて約 2 倍の早さで解答できることが分かった．付録 B.1 に
各被験者の解答手順を記載しているが，被験者の解答手順の記述から可視化ツー
ルの利用者は前問の解答を利用する問題の場合，ツールチップやキャプション，
グラフの遷移を利用することで解答を行っていた．UNIX コマンドの場合は新た
にコマンドを打ち直す必要があるが，可視化ツールはマウス操作を数回するだけ
の短時間の動作で関連情報を得ることができるため，解答時間に差が生まれるこ
とが考えられる．
表 15 1 回目と 2 日目の平均解答時間
解答方法
回数
平均解答時間
可視化ツール
1 回目
1:56.4
2 回目
1:44.4
1 回目
4:55.5
2 回目
3:08.4
UNIX コマンド
表 16 前問を利用した問題の平均解答時間
解答方法
前問
平均解答時間
可視化ツール
利用する
0:54.7
利用しない
2:28.0
利用する
2:27.5
利用しない
4:37.7
UNIX コマンド
39
4.4.4 可視化ツール及び入力用トピックデータの問題点
• トピック名の重複
トピック名にはいくつか類似した名前のトピックが存在することがあった．
例えば，付属 B.1 の Apache Ant の小問 4 における被験者 A の解答は間違っ
ていた．被験者 A は凡例の中から問題にあうトピックを全て選択したが，1
つだけ類似したトピックを見逃していた．その見逃したトピックが小問の
正解となっているが，被験者 A は見逃してしまったため解答を間違うこと
になった．
類似したトピックは 1 つのトピックとしてまとめるべきであるが，まとめ
る作業は困難である．本実験の可視化ツール用のデータはリンクモデルで
構築しているが，他の区間のトピックと結びつけるための閾値とその求め
方の設定が困難である．トピックを表す単語分布を利用してトピック間を
結びつけるが，閾値が大きいとトピック間で結びつきが発生しづらく，逆
に小さいと関係のないトピック間で結びついてしまう．また，リンクモデ
ルでは同じ区間で類似したトピックが抽出されたとしても，結びつくこと
はない．もし，そのようなトピックがあった場合，別々のトピックとして
扱われてしまう．そのため，同じ区間内でも，トピック間の類似度を計算
しまとめる必要があると考えられる．
• 粒度の大きい区間
本実験では 1 区間を 3ヶ月単位とした．3ヶ月単位であるため，年月を問わ
れる問題において，コマンドを用いた解答は詳細な年月まで解答すること
が可能だが，可視化ツールの場合は 3ヶ月単位の解答となってしまった．こ
の 3ヶ月単位となってしまう理由としてトピック解析の対象をコミットログ
コメントにしたこと，また，リンクモデルを採用したことが挙げられる．コ
ミットログコメントは基本的に短文であり，短いものは数単語しか含まな
いことが多々ある．また，リンクモデルは区間を設けて，その区間でトピッ
ク解析をする必要がある．すると，区間に含まれる文書ではトピック解析
に必要なデータ量に達すことができずに，正常に解析できない場合がある．
40
そのため，本実験では十分なデータ量を確保するために 3ヶ月単位で区間を
設けた．
HALL モデルを採用するとトピック解析で全ての文書を用いてトピック解
析するため，リンクモデルのようにデータ量の不足により解析が失敗する
心配がない．しかし，HALL モデルでは一部の特徴的なトピックのみ解析さ
れる心配がある [10]．本実験では，開発者に着目したトピックを求めようと
しているため，粒度の小さいトピックが消えてしまう可能性のある HALL
モデルを利用しなかった．
• データ増加によるユーザビリティの低下
可視化ツールは JavaScript によって実装されているため，処理速度が速く
ない．そのため，データ量が増えると処理を終えるまで時間が多く必要と
なる．また，データ量が増えると言うことはトピックが増加したり期間が
長かったりすることであり，プロットエリアのポイント間の密度が大きく
なったり凡例の一覧が膨大になったりする．すると，キャプションやツール
チップを表示しても，目的のトピックのポイントを特定するのは困難にな
る．ツールの処理速度はマシンスペックやブラウザ，画面の煩雑さは解像度
に依存するため高解像度の環境があればある程度解決するが，どれも根本
的な解決にはならない．類似トピックをまとめたり，不必要なトピックを
求め入力用のデータとして用いないようにしたりすることでデータ量の削
減を行うことで処理時間を抑えることができ，過剰な可視化も軽減できる．
また，開発者の情報に関しても，開発に関わりが小さい人を求めてデータ
量を削らなければならないと考えられる．
4.4.5 考察のまとめ
可視化ツールは解答に必要とする時間を UNIX コマンドよりも有意に短縮する
ことができ，また，コマンドと同等の正答率を示すことが分かった．また，可視
化ツールは学習による解答速度の向上はないものの，初期段階からコマンドに比
べて短時間で解答することが可能であり，初期コストが小さいことが分かった．
41
関連情報を求める場合も，可視化ツールの方が時間的に優れていた．しかし，可
視化ツールの入力としたデータは決して良いものではなかった．そのため，入力
用のデータの生成についての改善を考える必要があることが分かった．また，被
験者からの利用アンケートを通じてツール機能の改善点なども見つかった．
42
5. おわりに
本論文では開発者に着目したソフトウェア開発履歴の可視化を目的として OSS
プロジェクト Apache Ant, CAROL, jEdit, WALA の 4 つを対象に，それらのバー
ジョン管理システムのコミットログコメントからトピック解析をし，解析結果を
可視化ツールで提供することで提案手法の有用性評価と考察を行った．その結果，
可視化ツールは UNIX コマンドを利用した情報検索よりも短時間で情報を検索す
ることが可能であること，ツールに可視化により開発者の活動情報を知ることが
可能であることが分かった．また，可視化ツールは短時間の講義で利用すること
ができ，コマンド以上に容易に扱えるものであることが分かった．
しかし，入力として用いた解析データにはいくつかの問題があった．類似のト
ピックが正常に結びつかずそれぞれ別々のトピックになり，データ量の関係から
3ヶ月単位で区間を設けてトピックを抽出したことにより時系列に対して粒度の
大きなデータを提供することになった．この問題を解決するには，トピック解析
時の最適なトピック数の選択やトピック間を結びつける際の指標の作成，コミッ
トログコメント以外からプロジェクトの活動内容が含まれた文書を作成しデータ
量を増やすなどの処理を行う必要があると考えられる．
また，可視化ツールの有用性を確認することはできたが，実験に参加した被験
者から多くの欠点や改善点が指摘された（付録 B.2 のアンケート番号 8, 9 を参
照）．被験者らの意見を基に可視化ツールを改良すれば，ツールは更に有用なも
のになると考えられる．
今までのトピック解析を利用してきた研究ではプロジェクト全体の活動に着目
し可視化が行われていたが，本論文では開発者に着目した可視化を行った．また，
評価実験により開発者の情報がツール通した可視化で有用に提示可能であること
を示せた．
43
謝辞
本研究を進めるにあたり，多くの方々に御指導，御協力，御支援を頂きました．
ここに謝意を添えて御名前を記させて頂きます．
奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア設計学研究室 飯田
元 教授には，本研究の全過程において熱心な御指導を賜りました．研究方針だけ
ではなく，研究に対する姿勢，論文執筆，発表方法についても多くの御助言を頂
きました．心より厚く御礼を申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア工学研究室 松本 健
一 教授には，様々な場面で本研究に対し貴重な御指導，御助言を賜りました．心
より感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 データベース学研究室 宮崎 純
准教授には，様々な場面で本研究に対し貴重な御指導，御助言を賜りました．心
より感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア設計学研究室 市川
昊平 准教授には，様々な場面で本研究に対し貴重な御指導，御助言を賜りまし
た．心より感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア設計学研究室 田中
康 特任准教授には，様々な場面で本研究に対し貴重な御指導，御助言を賜りまし
た．心より感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア設計学研究室 吉田
則裕 助教には，本研究を進めるにあたり，広範囲かつ多大な御助力を頂きまし
た．特に，学会発表や論文投稿時に貴重な御助言を頂戴いたしました．心より感
謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア設計学研究室 高井
利憲 特任助教には，様々な場面で本研究に対し貴重な御指導，御助言を賜りまし
た．心より感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア設計学研究室 伏田
享平 特任助教（現 NTT データ）には，本学在籍時に様々な場面で本研究に対し
貴重な御指導，御助言を賜りました．心より感謝申し上げます．
44
奈良先端科学技術大学院大学 呂 悠妃 氏には研究の遂行に必要な事務処理など，
多岐にわたり御助力頂きました．心より感謝申し上げます．
奈良先端科学技術大学院大学情報科学研究科ソフトウェア設計学研究室の皆様
には，日頃より多大な御協力と御助言を頂き，公私ともに支えて頂きました．あ
りがとうございました．
最後に，大学院への進学に理解を示し私を支えてくれた両親，そして普段から
相談に乗ってくれた姉に心より深く感謝します．
45
参考文献
[1] 栗原雅, 緒方啓吾. 企業 IT に浸透するオープンソースソフト, 2012. http:
//it.impressbm.co.jp/e/2012/05/08/4328.
[2] な ぜ 企 業 は オ ー プ ン ソ ー ス を 使 わ な い の か,
2010.
http://www.
hitachi-solutions.co.jp/forum/tokyo/vol46/.
[3] IPA（独立行政法人情報処理推進機構）. 第 3 回オープンソースソフトウエ
ア活用ビジネス実態調査 (2009 年度調査）.
[4] オープンソースソフトウェアへの取り組み. http://www.scsk.jp/product/
oss/index.html.
[5] David M. Blei, Andrew Y. Ng, and Michael I. Jordan. Latent dirichlet
allocation. Machine Learning Research, Vol. 3, pp. 993–1022, 2003.
[6] David Hall, Daniel Jurafsky, and Christopher D. Manning. Studying the
history of ideas using topic models. In Proceedings of the Conference on
Empirical Methods in Natural Language Processing (EMNLP ’08), pp. 363–
371, 2008.
[7] Qiaozhu Mei and ChengXiang Zhai. Discovering evolutionary theme patterns from text: an exploration of temporal text mining. In Proceedings of
the eleventh ACM SIGKDD international Conference on Knowledge Discovery in Data Mining, (KDD ’05), pp. 198–207, 2005.
[8] Abram Hindle, Michael W. Godfrey, and Richard C. Holt. Software Process
Recovery using Recovered Unified Process Views. In Proceedings of the 26th
IEEE International Conference on Software Maintenance (ICSM ’10), 2010.
[9] Abram Hindle, Michael W. Godfrey, and Richard C. Holt. What’s hot and
what’s not: Windowed developer topic analysis. In Proceedings of International Conference on Software Maintenance (ICSM ’09), pp. 339–348, 2009.
46
[10] Stephen W. Thomas, Bram Adams, Dorothea Blostein, and Ahmed E. Hassan. Studying Software Evolution Using Topic Models. Science of Computer
Programming, pp. 1–23, 2013. in press.
[11] Mario Luca Bernardi, Carmine Sementa, Quirino Zagarese, Damiano Distante, and Massimiliano Di Penta. What Topics do Firefox and Chrome
Contributors Discuss?
In Proceedings of the 8th Working Conference on
Mining Software Repositories (MSR ’11), pp. 234–237, 2011.
[12] Tse-Hsun Chen, Stephen W. Thomas, Meiyappan Nagappan, and Ahemed E.
Hassan. Explaining software defects using topic models. In Proceedings of
the 9th Working Conference on Mining Software Repositories (MSR ’12),
pp. 189–198, 2012.
[13] Hazeline U. Asuncion, Arthur U. Asuncion, and Richard N. Taylor. Software
traceability with topic modeling. In Proceedings of the 32nd ACM/IEEE
International Conference on Software Engineering - Volume 1 (ICSE ’10),
pp. 95–104, 2010.
[14] Kimiharu Ohkura, Keita Goto, Noriko Hanakawa, Shinji Kawaguchi, and
Hajimu Iida. Project Replayer with email analysis – revealing contexts in
software development. In Proceedings of the 13th Asia Pacific Software Engineering Conference (APSEC ’06), pp. 453–460, 2006.
[15] 大蔵君治, 後藤慶多, 川口真司, 花川典子, 飯田元. ソフトウェア開発におけ
る知識還元のためのプロジェクト再現ツール. ソフトウェアエンジニアリン
グ最前線 2006, pp. 75–78, 2006.
[16] 藤原賢二, 伏田享平, 吉田則裕, 飯田元. オープンソースソフトウェアを対象
としたリファクタリングが欠陥混入に与える影響の調査. 日本ソフトウェア
科学会 第 28 回大会 講演論文集, No. 5C–3, pp. 1–5, 2011.
[17] Peter Axel Nielsen and Gitte Tjørnehøj. Social networks in software process
47
improvement. Journal of Software Maintenance and Evolution: Research
and Practice, Vol. 22, No. 1, pp. 33–51, 2010.
[18] Christian Bird, David Pattison, Raissa D’Souza, Vladimir Filkov, and
Premkumar Devanbu. Latent social structure in open source projects. In
Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering (SIGSOFT ’08/FSE-16), pp. 24–35, 2008.
[19] Taek Lee, Jaechang Nam, DongGyun Han, Sunghun Kim, and Hoh Peter In.
Micro Interaction Metrics for Defect Prediction. In Proceedings of the 19th
ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE ’11), pp. 311–321, 2011.
[20] Andrew Kachites McCallum. MALLET: A Machine Learning for Language
Toolkit. http://mallet.cs.umass.edu, 2002.
48
付録
A. 実験後アンケート
1. UNIX コマンドの利用頻度はどれくらいですか？
(a) マニュアルを読まなくても一般的なコマンドであれば扱える．
(b) コマンド名は分かっているが，オプションを使う場合は man やイン
ターネットで検索しないと分からない．
(c) 検索して見つけたコマンドを使うことができる．
(d) コマンドをどこで使うか分からない．
2. Git や Subversion を使ったことがありますか？
(a) 自分のソースコードはリポジトリで管理している．
(b) 時々使ったり，公開されているリポジトリをダウンロードしたりする．
(c) 授業等で習った程度．
(d) 使ったことがない．
3. ソフトウェア開発経験はありますか？（複数回答可）
(a) 授業の個人課題しかない．
(b) グループ演習で集団開発をした．
(c) OSS の主要開発面メンバーである．
(d) バイトで業務用ソフトウェア開発をしたことがある．
(e) ソフトウェア開発会社で働いていた．
4. 『リポジトリマイニング』が何か知っているか？
(a) リポジトリマイニング関連の研究を行っている．
(b) リポジトリマイニング関連の論文を読んだことがある．
49
(c) 本を読んだり，他人の発表を聞いたりしたことがある．
(d) 知らない．
5. 普段は何を使ってプログラミングしますか？（複数回答可）
(a) Eclipse などの統合開発環境
(b) 高機能テキストエディタ（実行環境や補完機能が搭載されたもの）
(c) テキストエディタ（メモ帳など）
6. 可視化ツールと UNIX コマンドのどちらが簡単に解答を導き出せましたか？
(a) 可視化ツールの方が簡単
(b) やや可視化ツールの方が簡単
(c) どっちも同じくらい
(d) やや UNIX コマンドの方が簡単
(e) UNIX コマンドの方が簡単
7. 可視化ツールは動作が重たかったですか？
(a) 重い
(b) 我慢できる重さ
(c) 普通
8. 可視化ツールの良かった点と悪かった点を自由に書いて下さい．
9. 可視化ツールに欲しい機能を書いて下さい（空白可）．
B. 実験結果詳細
B.1 被験者の解答と解答手順
Apache Ant
被験者 A，B：可視化ツール
50
被験者 C，D：UNIX コマンド
小問 1 A: 2002 年 01 月から 03 月
被験者 A 2002 年 01-03 月
最初の画面で 2002 年 01-03 月の点が 1 番大きく，他の年月のトピッ
ク割当値の合計が 2002 年 01-03 月の値に達していなかったから．
被験者 B 2002 年 01-03 月
トピック変化グラフで大きそうな年月のトピック割当値を合計し
た結果 2002 年 01 − 03 月が 1 番大きいかったから．
被験者 C 2002 年 2 月
最初にリポジトリの範囲を確認して git log –pretty=format:”%ad”
| grep year で year を変えながら確認し 2002 年と決める．先のコマ
ンドにパイプ処理で grep month を追加し，month を 1 月から 12
月まで順に変えて確認した．
被験者 D 2002 年
git log –pretty=format:”%an(%ad) ‘%s’” — grep year で year の
値を変えて確認した（月までは確認していない）．
小問 2 A: Peter Donald, Stefan bodewig, Stephane baillez
被験者 A perter donald, stefan bodewig, stephane bailliez
2002 年 01-03 月のグラフから割当値の大きい順に決めた．
被験者 B perter donald, stefan bodewig, stephane bailliez
小問 1 の答えの年月のポイントをクリックし，トピックの積み上
げグラフのツールチップから選択した．
被験者 C 時間切れ
被験者 D 時間切れ
小問 3 A: 2000 年 10 月から 2002 年の 12 月
被験者 A 2000 年 10-12 月から 2002 年 10-12 月
小問 2 の棒グラフから perter donald をクリックし，perter donald
のグラフを表示させ，その期間を見る．
51
被験者 B 2000 年 10 月から 2002 年 12 月
perter donald のポイントをクリックし，perter donald のグラフの
左端と右端を確認する．
被験者 C 時間切れ
被験者 D 時間切れ
小問 4 A: 2006 年 10 月から 12 月（正確には 2006 年 11 月）
被験者 A 2004 年 10-12 月
checktyl number magic, checkstyl jackson kevin の内，大きい方の
年月を選択した．
被験者 B 2006 年 10-12 月
checkstyl を含むトピック名を凡例から選択肢，最も割当値の大き
いものを選択した．
被験者 C 2006 年 11 月
git log –pretty=format:”%ad ‘%s’” | grep checkstyle | grep year で
確認後，以下小問 1 と同様の方法で解いた．
被験者 D 2005 年
git log コマンドの結果を grep checkstyle — grep year で year を変
更しながら確認した（月までは確認していない）．
小問 5 A: Peter Reilly
被験者 A stefan bodewig
トピック checkstyl jackson kevin のグラフへ遷移して最も割当値
の大きい人物を選択した．
被験者 B peter reilly
ポイントにマウスオーバーで Main Author を見る．
被験者 C Peter Reilly
git log –pretty=format:”%an %ad ‘%s’” | grep 2006 | grep Nov |
grep checkstyle | less で確認した．
52
被験者 D Peter Reilly
小問 4 の結果を更に grep で絞り込んだ．
小問 6 A: 2003 年 7 月から 2008 年 6 月（正確には 2003 年 5 月から 2010
年 5 月）
被験者 A 2000 年 04-06 月から 2013 年 01-03 月
小問 5 のグラフから stefan bodewig のグラフを表示して，その期
間を見る．
被験者 B 2003 年 7 月から 2008 年 6 月
3 と同様，peter reilly のグラフを表示して確認する．
被験者 C 2003 年 5 月から 2010 年 5 月
git log –pretty=format:”%an %ad” | grep “Peter Reilly” | less で
最初と最後の日付を確認した．
被験者 D 時間切れ
git log に grep -e ‘Peter Reilly’ をする．
CAROL
被験者 A，B：UNIX コマンド
被験者 C，D：可視化ツール
小問 1 A: 2007 年 10 月（導入は 2007 年 3 月，10 月から使われ始めた
被験者 A 2007 年 05 月
git log –pretty=format:”%an(%ad) ‘%s’” — grep -i Maven でヒッ
トした最初の年月．
被験者 B 2007 年 5 月
git log から grep Maven して，wc で集計した．
被験者 C 2007 年 10-12 月
凡例から Maven を含まないものを非表示にし，トピック releas
maven plugin から最大のポイントの年月を解答した．
被験者 D 2007 年 10-12 月
トピック releas maven plugin のグラフから．
53
小問 2 A: benoitf, loris, eyindanga
被験者 A 時間切れ
小問 1 の結果を grep し集計しようとした．
被験者 B benoitf
多そうな人物を 3 人選び grep 名前 | wc で確認した．
被験者 C benoitf, loris, eyindanga
トピック releas maven plugin の積み上げグラフから，目測した．
被験者 D eyindanga, benoitf, fornacif
Total Topics からトピック releas maven plugin を見た？
小問 3 A: 2007 年 10 月から 12 月（正確には 2007 年 10 月）
被験者 A 時間切れ：
被験者 B 2007 年 8 月
grep folder を行い，明らかにこの年月が多かったから．
被験者 C 2007 年 10-12 月
凡例からトピック remov folder unwant，remov directori extra 以
外を非表示にし，明らかに大きかったポイントの区間を選択した．
被験者 D 2007 年 10-12 月
トピック remov floder unwant が問題に該当するトピックと判断
した．
小問 4 A: loris
被験者 A 時間切れ：
被験者 B loris
小問 3 の結果を目 grep した．
被験者 C loris
トピック remov folder unwant のグラフを表示し，目視で明らかに
大きいもの選択した．
被験者 D loris
トピック remov folder unwant のグラフから判断した．
54
小問 5 A: 2005 年 01-03 月（正確には 2005 年 3 月）
被験者 A 2005 年 5 月
git log –pretty=format:”%an(%ad)”を実行し，目で確認した．
被験者 B 2005 年 11 月
–author=benoitf で多そうな年月を目 grep で選択し，wc で集計
した．
被験者 C 2005 年 01-03 月
トピック releas maven plugin に参加していたので，そのグラフを
クリックし，更に開発者 benoitf のグラフへ遷移し，そのグラフか
ら目測で判断した．
被験者 D 2005 年 04-06
開発者 benoitf のグラフと開発をトピック thi commit creat と置き
換えて，その割当値が最大のものを選択した．
jEdit
被験者 A，B：可視化ツール
被験者 C，D：UNIX コマンド
小問 1 A: spestov，kpouer
被験者 A kpouer, shlomy
トピック fix warn compil のグラフから，割当値が大きい上位 2 人
を選択した．
被験者 B spestov, kpouer
compile の文字を含むトピックを選択し，その中から主な開発者を
2 名選択した．
被験者 C spestov, krisko
git log –pretty=format:”%an ‘%s’” | grep compile | grep fix | less
の結果を目 grep し選択した．
被験者 D spestov, jgellene
git log –pretty=format:”%an(%ad) ‘%s’” | grep -e fix -e compile
55
の結果から．
小問 2
spestov: 2001 年 10 月から 2006 年 3 月
（正確には 2001 年 9 月から 2006 年 2 月）
kpouer: 2005 年 1 月から 2012 年 12 月
（正確には 2005 年 2 月から 2012 年 10 月）
• 被験者 A: それぞれの開発者のグラフを表示し，その期間を見て答
えた．
– kpouer: 2005 年 01-03 月から 2012 年 10-12 月：
– shlomy: 2007 年 07-09 月から 2011 年 10-12 月：
• 被験者 B： それぞれの開発者のグラフを表示し，その期間を見て
答えた．
– spestov: 2001 年 10-12 月から 2006 年 01-03 月：
– kpouer: 2005 年 01-03 月から 2012 年 10-12 月：
• 被験者 C： git log –pretty=format:”%ad %an’” | grep name | less
で name の部分に小問 1 の問題の答えを入力し，その結果の最初
と最後を確認した．
– spestov: 2001 年 9 月から 2006 年 2 月：
– krisko: 2002 年 10 月から 2004 年 7 月：
• 被験者 D 時間切れ：
小問 3 A: 2009 年 10-12 月（正確には 2009 年 10 月）
被験者 A 2009 年 10-12 月
トピック fix code style のグラフから判断した．
被験者 B 2009 年 10-12 月
style の含むトピックを選択し，そのなで最大値のトピックの区間
を確認した．
被験者 C 2009 年 10 月
git log –pretty=format:”%ad ‘%s’” | grep -i coding | grep -i style
56
| less の結果から目 grep で選択した．
被験者 D 2009 年
git log –pretty=format:”%an(%ad) ‘%s’” | grep ‘coding style’ で
確認した．
小問 4 A: kpouer
被験者 A kpouer
小問 3 のグラフから最大の割当値の開発者を選択した．
被験者 B kpouer
最大値のトピックのポイントをマウスオーバーし，ツールチップ
の Main Author で確認した．
被験者 C kpouer
git log –pretty=format:”%an %ad ‘%s’” | grep -i coding | grep -i
style | grep 2009 | grep Oct | less の結果から目 grep で確認した．
被験者 D kpouer
小問 3 の結果から目 grep し選択した．
WALA
被験者 A，B：UNIX コマンド
被験者 C，D：可視化ツール
小問 1 A: 2009 年 04-06 月（正確には 2009 年 04 月）
被験者 A 2009 年 04 月
git log — grep comment から目 grep で選択した．
被験者 B 2009 年 04 月
被験者 A に同じ．
被験者 C 2009 年 04-06 月
凡例から comment を含まないトピックを非表示にして，目視で選
択した．
被験者 D 2007 年 07-09 月
57
ソースコードコメントをトピック tweak comment format と解釈
し，そのトピックの値が最大となる区間を選択した．
小問 2 A: sjfink
被験者 A sjfink
git log –pretty=format... — grep comment から目 grep で選択
した．
被験者 B sjfink
被験者 A に同じ．
被験者 C sjfink
凡例のチェックボックスでキャプションを表示させ，それを確認
した．
被験者 D sjfink
トピック tweak comment format のグラフから選択した．
小問 3 A: sjfink, dolby-oss
被験者 A sjfink, dolby-oss
git log –pretty=format:”%an(%ad)” — grep 2007 — grep -e Jan
-e Feb -e Mar の結果を目 grep で選択した．
被験者 B dolby-oss, sjfink
git log のオプションで–since “2007-01-01” –until “2007-03-01” を
して目 grep で選択した．
被験者 C dolby-oss, sjfink
区間 2007 01-03 のグラフを表示させて，グラフを見て解答した．
被験者 D sjfink, dolby-oss
被験者 C と同じ．
B.2 実験後アンケート結果
アンケート番号 8 可視化ツールの良かった点と悪かった点
58
表 17 実験後アンケート結果（番号 1-7）
アンケート番号
被験者 A
被験者 B
被験者 C
被験者 D
1
b
b
b
c
2
a
c
b
c
3
a, b, d
a, b
a, b
e
4
b
b
a
a
5
a, b
a, c
a, b
a, c
6
a
b
a
a
7
b
b
b
c
• 良かった点
– 開発者のプロジェクト参加期間が一目で分かるのは便利だった．
– 出題された問題は全体的にツールの方が解きやすかった．
– 容易に理解することができた．
– コマンドを覚える必要がない．
• 悪かった点
– ツールが反応しているかどうか分からない．ツールの重さは許容
できるが，グラフ遷移時のアクションがないため，ツールが止まっ
ているのか遷移中なのかが分からない．
– 初期画面の積み上げグラフがなかったので，Ant の小問 1 を解く
のが困難だった．
– グラフの色に類似した色が多くあり，分かりづらい．
– 比較問題で，グラフの差違が見られない場合，あらかじめシェル
スクリプトを用意しておけば，コマンドの方がより正確に結果を
得られると思った．
– データが多い場合，目的のものを探すのが難しい．特に凡例が多
すぎる場合．
59
アンケート番号 9 可視化ツールに欲しい機能
• 初期画面の凡例のトピック名をクリックすると，そのトピックのグラ
フに遷移するようにしてほしい．しかし，ポイントの表示／非表示の
機能は据え置きにしてほしい．
• 初期画面の区間ごとのトピック割当値の合計を表示してほしい．
• 凡例を対象とした検索機能が欲しい．
• ポイントを全て表示／非表示にする機能が欲しい．
• ローディング中のアクションが欲しい．
• 3ヶ月区切り以外のデータも見たい．
• 積み上げグラフでは，全てベタ塗りではなく，斜線などを入れて可読
性を上げてほしい．
• 前に表示していたグラフに戻る機能が欲しい（ポイントの表示／非表
示などの状態を維持したまま）．
• データを出力する機能が欲しい．
60