情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)

効率的な開発履歴理解のためのGit に対するソースコード検索機能の統合
佐々木 美和1,a)柗本 真佑1,b)

楠本 真二1,c)

受付日 xxxx年0月xx日, 採録日 xxxx年0月xx日

概要：効率的なソフトウェア開発の管理を実現するためには，版管理システムを用いた開発履歴の理解が必須である．しかし，一般的な版管理システムにおける履歴操作は grep や diﬀ などのテキストベースな操作に制限されている．そのため，ソースコードの構文情報や意味に基づいた履歴操作は容易ではない．一方，ソースコード検索に関する様々な研究が行われてきたが，これらの方法では開発履歴を追うことができない．本研究では，版管理システムとして広く用いられている Git を対象に，リポジトリの履歴操作系
コマンドに対してソースコード検索技術を統合することを提案する．この統合により使用者の関心外の情報を削除することが可能となり，効率的な情報の絞り込みが可能となる．提案手法の実現のために，Gitの Java 実装 JGit を拡張した MJgit を設計し実装した．MJgit では git-show や git-diﬀ，git-log といった
過去のリビジョンの情報を取得するコマンドに対し，メソッド名や変数名の指定といった検索クエリを使用できる．評価実験として，実際のリポジトリを用いた性能評価実験，及び被験者 16 名を用いた有用性の確認実験を行う．
キーワード：版管理，履歴理解，ソースコード検索，MJgit，Git，構文抽象木

Integrating Source Code Search into Git Clientfor Eﬀective Understanding of Code Change History
Miwa Sasaki1,a)

Shinsuke Matsumoto1,b)

Shinji Kusumoto1,c)Received: xx xx, xxxx, Accepted: xx xx, xxxx

Abstract: In order to achieve eﬀective development management, it is important to manipulate and understand the change histories of source code in a repository. Although general version control systems provide
change history manipulations, these systems are restricted to line-based and textual operations such as grep
and diﬀ. As such, these systems cannot follow the syntax/semantics of the source code. While various studies
have examined querying and searching source code, these methods cannot follow historical changes. The key
concept of this paper is the integration of a source code search technique into Git commands that manipulate
historical data in a repository. With this integration, it becomes possible to mask information that is notinterested by the developers, and it is possible to narrow down eﬃcient information. This paper presents
MJgit, a prototype tool for achieving the above goal. In MJgit, developers can use search queries such as
specifying method names and variable names for time direction operations such as git-show, git-diﬀ, andgit-log. As an evaluation, we conducted a performance experiment using actual software repositories. Also,
we confirmed eﬀectiveness and eﬃciency of our tool by user study where 16 subjects participated.
Keywords: Version control system, understanding code change history, source code search, MJgit, Git,
abstract syntax tree

1

a)
b)

大阪大学 大学院情報科学研究科
Graduate School of Information Science and Technology,
Osaka University
m-sasaki@ist.osaka-u.ac.jp
shinsuke@ist.osaka-u.ac.jp

c 1959 Information Processing Society of Japan⃝c)kusumoto@ist.osaka-u.ac.jp

1

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)

また，Historage [11] はソースコードの変更をメソッド単

1. はじめに
Git や SVN に代表される版管理システムは，多くのソ
フトウェア開発プロジェクトで利用されている [7]．これら版管理システムを操作しリポジトリ内のソースコードの開発履歴を理解することで，効率的な開発の管理が可能である [22]．開発履歴の理解により，なぜコードが変更されたのか [19]，いつバグが混入したのか [14]，誰をデバッグ担当にすべきか [2]，といった開発プロジェクトにおける様々な疑問を解消することが可能となる．
一般的な版管理システムでは，grep や diﬀ などの Unix

位という細粒度で分析可能であるが，既存のリポジトリを大幅に再構築する必要がある．
本研究のキーアイデアは，開発履歴を操作する Git コマ
ンド（git-diﬀ，git-log，git-show など）に対してソースコー
ド検索機能を統合することである．この 2 つの統合により，Git コマンドによるリビジョンのメタ情報（誰が，いつ，なぜ，など）の検索と，コード検索による構文を考慮した検索，という 2 つの観点を組み合わせた履歴操作が可能となる．組み合わせたコマンドの具体例は以下の通りである．

系コマンドに基づいた履歴操作機能がサポートされてい$ git log--method=x -- author = miwa

る．例えば，git-diﬀ コマンドを用いれば，最新リビジョン$ git log--method=x -- since =2018 -01 -01とその直前リビジョンの差分を diﬀ 形式のフォーマットで$ git log--method=x -- grep = ' fix for '$ git diff--method=x revA .. revB取得できる．これらのコマンドはテキストデータに対する
汎用ユーティリティとして設計されており，正規表現に基

method オプションは我々の提案するツールで拡張されづいて強力なパターンマッチングも利用可能である [13]．

たクエリである（ここでは実際の表記から簡略化していしかしながら，これらのコマンドはその高い汎用性と引きる）．Git は標準で author や since，grep などの検索をサ換えに，ソースコードの構文情報やその意味に基づいた操ポートしている．各クエリはそれぞれ開発履歴の「誰が」，作を行うことはできない．

「いつ」，「なぜ」を明らかにする．我々の手法は，このよ

多くのプログラミング言語では，単一のソースコード
ファイルはコードの本質たる実行ステートメントだけではうなメタ情報を指定しながらメソッド x に焦点を合わせて
コードの変更履歴を確認することができる．

なく，様々な種類の記述（コメントやアノテーション，コ

本研究の目的は，上記のアイデアを実現し，開発者に対ピーライトなど）で構成されている．中でもコメントやコする効率的な開発履歴の理解を実現することにある．本論

ピーライトは自然言語で記述されており，これがテキスト

文では，この目標を達成するための Git クライアントの拡ベースの検索に対してノイズになることがある．例えば，

張ツール，MJgit を実装し評価する．この提案ツールは，ある開発者がコードクローン [20] によって引き起こされ指定されたメソッド名や変数名などの構文情報に基づいてるバグ伝搬 [17] をチェックするために，テキストベースのJava ファイルの開発履歴を絞り込むことができる．拡張

操作を用いて if 文を検索している場合を考える．この場

クエリが指定されていない場合，MJgit は拡張対象である

合，実行ステートメントの if 文だけでなく，コメント内

Git クライアントの Java 実装（JGit）と同じように動作すの “if” という文字列が検索に引っかかってしまい，結果とるため，MJgit は JGit クライアントに対して完全な後方互して開発者に対するノイズになる．

換性を持つ．MJgit の評価実験として，実際のソフトウェ

このような問題を解決するために，ソースコードの検索

アリポジトリを用いた性能評価実験，及び有用性を確認すに関する様々な研究が行われている [5,6,8,9,15,18,23–25]．

るための被験者実験を実施した．

これらの手法は，抽象構文木や制御フローグラフといった2. 研究動機

ソースコードの構造に基づいた検索を実現する．よって，テキスト表現ではなく構文情報を利用してソースコードの本研究の研究動機として，図 1 に示す 2 つの履歴理解に一部（メソッドやステートメントなど）を特定することがついて，git-diﬀ を用いたシナリオを説明する．各図には 2可能である．

個，または 3 個のメソッドの開発履歴が記されている．

しかし，これらの手法は特定リビジョンのソースコードに対してのみ有効であり，ソースコードの変化の履歴を追2.1 例 1 あるメソッドの開発履歴の理解

跡することはできない．一部，ソフトウェアリポジトリに

図 1(a) はメソッド x と y の 2 つのメソッドの開発履歴

対するソースコード検索を取り入れた研究は行われていを表している．初期状態として，リビジョン 1 の時点で 2

る [4, 10]．しかしながらこれらの研究の焦点は，数万を超つのメソッド x と y が図のような順番で宣言されているとえる大量のソフトウェアリポジトリをいかにスケールする

する．リビジョン 2 で，メソッド x の宣言がファイルの最形で分析させるか，という点にあり，開発者が特定のリポ後（メソッド y の後ろ）に移動されている．リビジョン 3

ジトリの理解のために直接用いるような仕組みではない．

でメソッド x の中身が修正された．ここで，ある開発者がc 1959 Information Processing Society of Japan⃝2

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)

x()

メソッド
y()

履歴を取得する際に構文情報を指定できる．この場合，メ
ソッド名 x を git-diﬀ に指定することで，表面的な変更やrev.1 -

メソッド
修正

初期状態

x()

ことができる．結果として，図のようにメソッドの移動に

rev.2 宣言場所を移動

よる出力を排除し，本質的な修正部分のみを開発者に提示

rev.3 (HEAD)可能である．

メソッドxの修正

既存手法：$ git diff r1..r3

2.2 例 2 バグ修正と一時的なパッチの除去
図 1(b) はより実用的かつ複雑な状況を表している．初提案手法：$ mjgit diff r1..r3 --method=x期状態として，リビジョン 1 の時点で 3 つのメソッド x，(a) 例 1 あるメソッドの開発履歴の理解

x()
メソッド
メソッド呼び出し
バグ
パッチ

メソッド
y()

y，z が宣言されており，メソッド x はメソッド y を呼び出している．リビジョン 2 でメソッド x にバグが混入されz()

rev.1 初期状態
rev.2 バグ混入

た．次にリビジョン 3 でバグを含むメソッド x がメソッド

z を呼び出すように変更された．さらにリビジョン 4 でメ
ソッド x，y，z 以外の場所でいくつかの変更が行われた．
そしてリビジョン 5 で開発者がバグに気付き，一時的な修正パッチをメソッド z に適用した．このパッチはメソッド

rev.3 メソッド呼び出し追加
rev.4 その他の修正

x から渡された引数の null チェックなどの一時的な解決方法である．ここで，ある開発者がバグを根本から修正しようとしている．さらに，一時的なパッチも除去する必要がrev.5 (HEAD)

プログラムの本質に関わらない変更をフィルタリングする

バグ修正パッチを追加

TO-BE 既存手法1：$ git diff r1..r5ある．
既存手法 1： ここに git-diﬀ を実行すると，リビジョン

1 から 5 までのテキスト差分を得ることができる．しかしこのコマンドの場合，最初の例と同様に，リビジョン 4 で

既存手法2：
Search relating to method x at r5行われた，バグ修正とは無関係の修正がノイズとなる．通提案手法：$ mjgit diff r1..r5 --method=x

さく分割することが推奨されている [16] が，多くの修正が(b) 例 2 バグ修正と一時的なパッチの除去

図 1: 研究動機
Fig. 1 Motivating examples

常，版管理システムを利用するにあたって，コミットを小単一のコミットにまとめられてしまうという状況がしばしば起こる [12]．このような絡み合ったコミットも同様のノイズを生み出す要因となりうる．
既存手法 2： この例のような状況では，ソースコード検
索 [6, 8, 9, 15, 18, 23, 24] や変更波及解析 [1, 3, 21] が有効なメソッド x の開発履歴を理解しようとしている．

アプローチとして知られている．変更波及解析は構文木ま既存手法： 開発履歴を確認する簡単な方法としては，

たはフローグラフに基づいて依存関係を追跡することで，

git-diﬀ を用いてリビジョン 1 から 3 までの差分を見る方修正が生み出す潜在的な影響範囲を特定する．開発者は，法であり，これは Git クライアントをインストールしてい「メソッド x のみに関連するメソッド」という検索をリビ

れば，追加のインストールなしに使用することができる．

ジョン 5 の時点のソースコードに適用することで，関心のしかし，このようなテキストベースのコマンドは，ソースあるメソッドを見つけることができる．ただし，これらのコードの構文情報やフローを考慮していない．したがっ

手法では開発履歴をサポートできないという制限がある．

て，これらのコマンドは，プログラムの機能自体に影響が従って出力結果にはリビジョン 1 から 5 で変更されていななく広範囲に行われた変更（コードのフォーマット変更やいメソッド y が含まれてしまう．メソッド y にバグが存在メソッドの並べ替えなど）がある場合，開発者にとって不せず，開発者の関心外にある場合，この情報はノイズにな

要な情報を大量に提供してしまう．図の例の場合，git-diﬀ

る可能性がある．

を使用するとメソッド x は削除されて，かつ追加されたよ提案手法： 提案ツール MJgit を使用すると，開発者はうに見えてしまうが，実際は移動しただけである．ペンのリビジョン 1 から 5 での変更点かつメソッド x に関連するアイコンで表されている本質的な修正は，メソッド移動の差分のみを取得することができる．これによって，図のよ

ノイズに埋もれてしまう．

うにノイズのない開発者の関心部分だけが出力される．こ

提案手法： 提案手法により，開発者はリポジトリから

c 1959 Information Processing Society of Japan⃝3

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)

コードファイル中から削除する．このように，テキス

MJgit の処理プロセス※ 当該リビジョンで変更された
ソースファイル群
for each file pair

2. リビジョン間のソースコードを取得

コード検索
1. コマンド$ mjgit diff –queryを実行
git リポジトリ
MJgit
開発者
ソースコードログ

3. 任意のコード検索
技術を適用
4. クエリに該当する部分以外を削除

5. テキストdiffの計算

図 2: MJgit における git-diﬀ コマンドの処理の流れ
Fig. 2 Processing flow of MJgit for git-diﬀ command-4cm -3.5cm

ト diﬀ 計算の前にコード検索を適用し，該当しない部分を削除したテキストファイルを生成して差分計算することにより，様々な履歴取得コマンドとコード検索の組み合わせが実現できる． なお，テキスト diﬀ の計
算には標準 Git による Longest Common Subsequence
アルゴリズム [13] を用いる．

5. 最後に， クエリ該当部分のみが記述されたソースコー
ドファイルに対し，diﬀ アルゴリズムを適用すること
で， 必要のない情報を排除した差分を開発者に提示する．

3.3 コード検索技術の例では，図のようにバグとパッチのみを抽出可能であり，単一のソースコードから特定のプログラムスニペットやスプログラムの変更理解の支援，及びそのメンテナンス作業

テートメントを検索する方法はいくつか存在する [1, 5, 25]．

の手助けとなる．

同様に，大量のソースコードファイルを格納するデータ

3. 提案ツール：MJgit
3.1 概要
MJgit の目的は，Git コマンドに対してソースコード検

ベースから特定のソースコードファイルを検索するためにも多くのアプローチが提案されている [4, 10]．いずれの手法も，提案手法におけるコード検索を実現する手法として適用することが可能である．

索機能を統合することにより，効率的な開発履歴の理解を

本論文では，具体的なコード検索技術として Eclipse JDT支援することである．MJgit の基本的なアイデアは，Git（Java Development Tools）の AST を用いた静的コードス

における履歴情報を取得するコマンド（git-diﬀ や git-log

ライシングを採用する．この方法では，生成された AST等）に対して，ソースコードの特定の部分を絞り込む拡張のルートから探索を始め，クエリに該当する AST ノード

クエリの指定を可能とする，という点にある．このアイデを順に発見していくことで，クエリの該当箇所を検索する．

ア実現にあたっては，どのようにコード検索を実現するか，

例えば method=x というクエリの場合，以下 2 つの AST

どの Git コマンドを拡張するか，の 2 点が重要となる．本ノードがクエリの該当箇所となる．

節では，まず MJgit 利用時の処理の流れについて概説し• ノ ー ド 名 が x で あ る SimpleName ノ ー ド を 持 つ（3.2 節），コード検索技術（3.3 節），及び拡張対象となる

MethodDeclaration ノード（x の宣言）

Git コマンド（3.4 節）について説明する．
• ノ ー ド 名 が x で あ る SimpleName ノ ー ド を 持 つ
3.2 処理の流れ
git-diﬀ コマンドを対象とした時の MJgit の処理の流れ

MethodInvocation ノード（x の呼び出しを含む文）
また，AST の各ノードには AST 生成の元となったソーを図 2 に示す．図の各手順について以下で説明する．

スコードファイルへの行番号が対応付いている．この行番

1. まず開発者は 2 つのリビジョン，A と B 間の差分を取号を元に，ソースコードファイルのどの行がクエリに該当得するために git-diﬀ を実行する．この時，MJgit でするかを探し出す．最終的にクエリに該当した行以外の全追加された拡張クエリを指定する．

ての行を削除し，テキスト diﬀ への入力とする．

AST を用いた静的コードスライシングの処理の流れを
2. 次に，MJgit は各リビジョンのソースコードを取得
する．

3. 任意のコード検索技術により，指定クエリに該当する
ソースコード箇所を検索する．提案手法はコード検索
技術には依存しておらず，任意の検索技術を用いることができる．MJgit で採用した具体的なコード検索技
術については 3.3 節で述べる．

4. コード検索で該当した箇所以外の全ての行を，ソース

c 1959 Information Processing Society of Japan
⃝

図 3 に示す．この手法では，1. AST を構築する，2. クエ
リに該当する AST ノードを検索する，3. クエリに該当す
る AST ノードのみからテキストを生成する，の 3 手順で構成される． なお，コード検索は対象リビジョンで変更された Java ファイルに対してのみ適用される．

3.4 拡張対象となるコマンド
Git はリポジトリを管理・操作するための様々なコマン
ドをサポートしている．提案手法は履歴理解の支援が目的

4

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)

MJgit の処理プロセス

1. AST を構築

コード検索for each revision

2. query に該当する
ASTノードを検索
3. 検索に該当するASTノード
からソースコードを生成※ 当該リビジョンで変更された
ソースファイル群
for each file pair

2. リビジョン情報を取得

コード検索
1. コマンド$ mjgit log –queryを実行

3. 任意のコード検索
技術を適用
4. クエリに該当する部分以外を削除

図 3: AST ベースのコード検索手法

5. テキストdiffの計算

Fig. 3 AST-based code search techniquegit リポジトリ
MJgit
開発者
ソースコードログ

であるため，「過去のリビジョンに対して」「履歴を取得する」コマンドへの適用が適当である．この 2 つの性質を満

6. diffを含むリビジョン
のみを抽出

たすコマンドを表 1 に示す．この表のコマンドは，それぞ図 4: MJgit における git-log コマンドの処理の流れ

れ 1 つ以上のリビジョンからログやソースコードファイル

Fig. 4 Processing flow of MJgit for git-log commandを取得する．また，これらのコマンドは since や authorなどのリビジョン情報を取得するクエリをサポートしている．
なお，表に示す各コマンドは，コマンドごとにその出力の単位が異なる．git-diﬀ ではリビジョン間のテキスト差
分情報の集合が，git-log ではリビジョン情報（すなわちログ）の集合が出力の単位となる．このリビジョン情報は差分情報を内包する．git-show は，git リポジトリ内の 3 種類のオブジェクト（commit，blob, tree）の詳細を取得するコマンドであり，git-diﬀ と git-log が要素の集合を取得するのに対し，git-show は単一の要素を取得する．
各コマンドで出力単位が異なるのに対し，MJgit によるソースコードの何を絞り込むかという「クエリの意味」は，
どの Git コマンドでも共通である．例えば，method=x というクエリを指定した場合，メソッド x の宣言とメソッ
ド x の呼び出しを含む文，の 2 つに関心を絞り込むという意図となる．そのクエリ指定により得られる出力は，どのGit コマンドと組み合わせるかによって変わるが，クエリはリビジョン情報が内包するソースコード群に対して適用される．よって，処理の各手順は先に述べた図 2 と同等である．
このような履歴に対して情報を取得するコマンド では，履歴情報に内包されるソースコードにコード検索技術を適用することができる．よって，提案手法により拡張される
ソースコードの構造に基づいた検索クエリは，標準 Git に実装されている日付や著者名に対するクエリと同様に，クエリ解釈の一貫性を保つ．表 1 に示した履歴に対して情報を取得するコマンドでは，履歴情報に内包されるソース
コードにコード検索技術を適用できるため，MJgit の拡張
対象は同表に示す 4 つのコマンドとした．

3.5 実装MJgit の実装は，Java ベースのオープンソースの Git ク
ライアント，JGit*1 を拡張して行われた．MJgit のソース
コードは GitHub 上で公開されている*2 ．
現在の MJgit がサポートする検索クエリ，及び拡張コマの解釈そのものは一貫性を保つ．
このクエリ解釈の一貫性は，MJgit のクエリ検索が差分ンドの一覧は表 2 の通りである． なお，前節で示した，表 1

情報の生成元となるソースコードのみに対して働くことに
表 1: 拡張対象となる Git コマンド起因する．git-diﬀ では処理対象が差分情報そのものであTable 1 Extended git commands

り，クエリ検索はその差分情報に直接適用できる．git-log
によりリビジョン情報の集合を取得する場合でも，個々のコマンド名

リビジョン情報が内包する差分情報にクエリ検索が適用される．よって，クエリの解釈は git-diﬀ と全く同じ内容となる．

git-diﬀ 以外のコマンドへの拡張の一例として，git-log コ
マンドの処理の流れを図 4 に示す．git-log ではリビジョ*1ン情報の集合に対して処理が行われるが，コード検索自体*2

c 1959 Information Processing Society of Japan
⃝

概要

対象
リビジョン数

git-diﬀ

リビジョン間の差分を取得する

git-show

リビジョンの詳細を取得する

1

git-log

リビジョンログを取得する≥1

git-blame

ファイルの最終更新を取得する≥1

2

https://eclipse.org/jgit/
https://github.com/kusumotolab/m-sasaki_MJgit

5

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)の拡張対象コマンドのうち，git-blame のみ現在未実装となっている．MJgit は現在，メソッド名と変数名を指定するクエリをサポートしている．さらに，exec-statement，comment，javadoc，annotation というクエリもサポートしており，指定されたタイプのプログラム文だけを指定$ jgit diff r1..r3$ mjgit diff r1..r3 –-method=x- public void x(int a, int b){// ab
int tmp = a;a = b;
b = tmp;- }することができる．例えば，実行ステートメントだけの差@@ -27,4 +20,13@@分やリビジョンログは exec-statement クエリで取得する+ public void x(int a, int b){+// ab
+int tmp = a;+a = b;+
b = tmp;
+
a ++;
+
b --;
+ }

ことができる．コード検索は，これらの構文情報についてのパラメータを指定することで実行される．また，現在のMJgit では，クエリは git-diﬀ と git-show，git-log で使用できる．検索クエリが指定されていない場合，ツールはオ
リジナルの JGit クライアントと同じ動作をする．

public void x(int a, int b){
int tmp = a;a = b;
b = tmp;
a ++;
b --;

+
+
}

図 5: git-diﬀ コマンド出力の比較
Fig. 5 Comparison of git-diﬀ command outputs

3.6 各コマンドの振る舞いと出力例
ここでは，2 つの特定リビジョンを対象とする git-diﬀ と

git-show，及び複数のリビジョンを対象とする git-log のそ
れぞれの出力例を説明する．

3.6.1 git-diﬀ と git-show
git-diﬀ と git-show は 2 つの特定リビジョン間のソースコードの差分を確認するコマンドである．このコマンドにソースコード検索を組み合わせることで，出力される差分を使用者の指定した構文情報だけに絞り込むことができる．
例えば，method=x を指定すると，x の宣言とその呼び出しを含む文が検索され，それ以外の差分は省略される．変更されたファイルにコンパイルエラーが存在し，AST が構
築できない場合，検索クエリは無視され，通常のテキストベースな diﬀ による差分が出力される．

$ jgit log –-name-status$ mjgit log –-variable=i

commit 3e383445c7f82
Author: miwa <miwa@osaka.ac.jp>
Date:
Sat Jul 28 08:29:05 2018

commit 058efd8ae793c
Author: miwa <miwa@osaka.ac.jp>
Date:
Fri Jul 27 10:14:58 2018

% xnull
src/Main.java



i
  $!'"(

commit c5afd3dae1b7eAuthor: shin <shin@osaka.ac.jp>
Date:
Fri Jul 27 17:04:06 2018
#(&src/Main.java
src/Logger.java
commit 058efd8ae793c
Author: miwa <miwa@osaka.ac.jp>
Date:
Fri Jul 27 10:14:58 2018i  $!'"(
src/Logger.java

図 6: git-log コマンド出力の比較
Fig. 6 Comparison of git-log command outputs

具体的な出力結果を図 5 に示す．左の出力がクエリを指定しないオリジナルの出力結果であり，右の出力は，左複数のログの中から指定した構文情報を変更したリビジョの出力に method=x クエリを指定することで情報を絞り込

ンのみを絞り込むことができる．

んだ際の結果である．この図は 2 節で述べた一つ目の例

例えば，variable=i を指定すると，変数 i の宣言やそれ（図 1(a)）に対応しており，メソッド x の移動と修正が混が用いられている文が変更されたリビジョンが検索され，在しているケースを表す．method=x クエリを指定するこi に関連しないログは全て省略される．なお，現在の実装とで移動がフィルタリングされ，かつコメントが除外されではクエリ variable に用いることが可能な変数の種類は本質的な修正のみが提示されている．

局所変数のみであり，フィールドは対象外である． リビ

3.6.2 git-log

ジョンに構文エラーを含むファイルが存在している場合，

git-log はリビジョンのログを取得するコマンドである．

AST が構築できず，指定クエリが変更されたかどうかを判

このコマンドにソースコード検索を組み合わせることで，断できない．よって，そのログは構文エラーを含むという警告文とともに出力される．
具体的な出力結果を図 6 に示す．左の出力が提案クエ

表 2: MJgit の検索クエリと拡張コマンド
Table 2 Queries and extended git commands of current MJgit
拡張コマンドgit-log, git-show, git-diﬀ

指定可能なクエリ

実行ステートメント（exec-statement）（クエリ指定方法）

コメント（comment）

Javadoc（javadoc）
アノテーション（annotation）

リを指定しないオリジナルの出力結果であり，右の出力は，variable=i クエリを指定することで情報を絞り込んだ出力である．なお，左のコマンドでは各リビジョンで編集したファイル名が出力される，Git の標準オプショ
ン--name-status を指定して実行している．
この例では，3 つのログが存在するリポジトリに対して

メソッド名の指定（method=method name ）git-log を実行している．variable=i クエリを指定するこ

変数名の指定（variable=var name ）とで，i が変更されたログだけが出力されている．

c 1959 Information Processing Society of Japan⃝6

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)

オリジナルの git-log には，ファイル名や編集者を指

git-diﬀ では，mjmethod はメソッド main のみの差分を出力定してログをフィルタする機能が設けられている．ここし，mjexec-stmt は実行ステートメントの差分のみを出力し，で，ファイル src/Logger.java の変数 i の履歴を確認

コメントや Javadoc，アノテーションなどの実行分以外のしたい開発者が，標準 Git コマンドを用いてファイル名

変更をフィルタリングする．git-log では，mjmethod はメ

src/Logger.java を指定したとする．しかし，このファイ

ソッド main が変更されたログのみを出力し，mjexec-stmt はルは 2 つ目のリビジョン c5af3d でコピーライトの変更が実行ステートメントが変更されたログのみを出力する．

行われており，ノイズとなりうる．ここで MJgit で変数 ijgit コマンドは，性能比較におけるベースライン計測のというクエリを与えることで，この開発者の関心にマッチために設定した実験タスクである．本実験では，このベーした検索が可能となる．

スラインに対して mjmethod と mjexec-stmt の性能低下の程度を確認する．さらに，mjmethod と mjexec-stmt はクエリ検索

4. 性能評価実験の該当のしやすさが性能に与える影響を調べるために設定したタスクであり，mjmethod はクエリ検索に該当する部分

4.1 実験の目的
本実験の目的は，MJgit による拡張クエリの実行性能が実用的かどうかを確認することである．MJgit では指定さが比較的少なく，mjexec-stmt は逆に該当部分が多くなるクエリである．

れたクエリを処理するために，抽象構文木の構築と該当する部分木の検索という処理が必要である．この追加処理

4.3 実験結果

が，Git 利用時における実行性能に対してどの程度影響を

4.3.1 git-diﬀ の結果
git-diﬀ の実行結果を図 7 に示す．3 つの箱ひげ図はそれ与えるかを確認する．

ぞれのクエリを指定した時の git-diﬀ の実行時間を表している．ただし，実行時間が 5 秒を超えていた 2 つの外れ値

4.2 実験設計
2 つの Java のオープンソースリポジトリに対して MJgit

は図から除外している．

を実行し，その実行速度や出力されるログの数の減少率にオリジナルの JGit では，全ての git-diﬀ が 2 秒以内に実ついてオリジナルの JGit と比較する．より具体的には，検行され，実行時間の中央値は 0.8 秒であった．この値を性

索クエリを指定した git-diﬀ と git-log の実行時間をオリジ

能比較のベースラインとする．MJgit で拡張クエリと共にナルの JGit の実行時間と比較する．git-diﬀ は，オープン

git-diﬀ（mjmethod と mjexec-stmt ）を実行した場合，実行時間

ソースリポジトリである JUnit4 と Log4j の全ての隣接リの中央値は 0.8 秒から 2 秒へと増加した．なお，mjmethod

ビジョンのペアに対して実行した．git-log はリポジトリ内と mjexec-stmt の間にはほとんど違いはなかった．さらに，の全リビジョンに対して実行した．いずれのコマンドも 10

2 つのプロジェクトでの結果を比較しても，両プロジェク回ずつ実行し，その平均を計測値とする．

ト間には大きな違いはなく，結果にはほぼ同じ傾向が見ら

対象プロジェクトの概要を表 3 に示す．両プロジェクト

れた．

共に 1,000 以上のリビジョンを持っており，15 年以上開発

性能低下の理由を明らかにするために，実行時間の増加率され続けている．git-diﬀ では，検索クエリは Java ファイと Java ファイル数の相関関係を調べた．ファイル数との相ルが変更されたリビジョンのみに作用するため，Java ファ

関を調べた理由は，図 2 に示す通り，MJgit による追加処理

イルが変更されていないリビジョンは実験対象外とした．

が複数ファイル全てに適用されるためであり，この部分が性同様に，リビジョンにコンパイルエラーが含まれている場

能低下要因になっているとの仮説に基づく． 調査の結果を合のリビジョンも実験対象から除外した．

図 8 に示す．グラフの各プロットは 1 つのリビジョンを示

MJgit では様々な検索クエリを組み合わせることができしている．x 軸は各リビジョンでコミットされた Java ファる．この実験では，表 4 に示す 3 つのコマンドを比較しイルの数を表し，y 軸は実行時間の増加率を表している．実た．コマンドはそれぞれ jgit, mjmethod , mjexec-stmt とラベル付けする．jgit はオリジナルの JGit のコマンドを表す．

表 4: 比較した 3 つのコマンド
Table 4 Compared three commands

表 3: 実験対象プロジェクトの概要

ラベル

Table 3 Summary of subject projects
JUnit4Log4j

2000/12

2000/11

2,187

3,275

git-diﬀ 対象のリビジョンペア数

900

1,891

最新リビジョンでの Java ファイル数

443

309

プロジェクト開始月
全リビジョン数c 1959 Information Processing Society of Japan⃝jgit
mjmethod
mjexec-stmt

実行したコマンド$jgit diff A..B$

jgit log$ mjgit diff A..B --method=main$ mjgit log--method=main$ mjgit diff A..B --exec-statement$ mjgit log--exec-statement

7

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)

実行時間（秒）5

実行時間（秒）5

実行時間（秒）1000

実行時間（秒）
1000

4

4

800

800

3

3

600

600

2

2

400

400

1

1

200

200

0

0

jgit

mj

method

mj

0

jgit

exec-stmt(a) JUnit4

mjmethodmj

exec-stmt(b) Log4j

0

jgit

mj

methodmj

jgit

exec-stmt(a) JUnit4

mjmethodmj

exec-stmt(b) Log4j

図 7: git-diﬀ に対する実行時間の比較

図 9: git-log に対する実行時間の比較

Fig. 7 Comparison of execution times for git-diﬀ commands

Fig. 9 Comparison of execution times for git-log commands

Javaファイル数100

出力log数（個）
3500
3000
2500
2000
1500
1000
500
0
jgit

Javaファイル数
100

80

80

60

60

40

r=0.5720

40

r=0.77

20

0

0

0
5
10
15
20
実行時間の増加率（倍）(a) JUnit4

0
5
10
15
20
実行時間の増加率（倍）(b) Log4j

mj

methodmj

exec-stmt

出力log数（個）
3500
3000
2500
2000
1500
1000
500
0
jgit

(a) JUnit4

mjmethodmj

exec-stmt(b) Log4j

図 8: 実行時間の増加率と Java ファイル数の相関

図 10: git-log で出力されたログ数の比較

Fig. 8 Relationship between performance reduction rate andFig. 10 Comparison of number of logs for git-log commands

number of java files

確認できた．そして mjmethod と mjexec-stmt には大きな差は
行時間の増加率は，「mjexec-stmt の実行時間/jgit の実行時間ないことから，実行時間増加の主たる要因はコード検索で」で計算されている．相関係数は JUnit4 と Log4j についはなく，AST の構築だと考えられる．これを改善する方法て 0.57 と 0.77 であり，有意であった．

としては，一度構築した AST をキャッシュのように保存

4.3.2 git-log の結果する方法が考えられる．ソースコードの AST を初めて構

git-log の実行時間の比較を図 9 に示す．jgit での実行

築した際に，その AST をキャッシュとして保存しておけ

時間は両プロジェクト共に 1.2 秒と極めて短い時間で完了

ば，git-log などの何度も AST を構築しなければならない

できた一方，提案手法では最低でも 200 秒であり少なくとコマンドの速度改善に繋がると考えられる．

も数百倍の時間増加が確認できた．特に時間増加が大きい

その一方で，git-log に対しては無視できない大幅な性能

ケースは，Log4j に対して mjmethod を実行した際の 844 秒低下が確認できた．特に，絞り込み効果の大きいクエリほである．

ど著しく性能が低下する傾向にあった．この理由について

拡張クエリによる出力ログ数の削減状況についての結は，git-log はファイルとリビジョンの全ての組み合わせに果を図 10 に示す．mjmethod のような特定メソッドのみを対して，コード検索が適用される点にあると考えられる．

フィルタリングする絞り込み効果の大きいクエリでは，大この性質により，git-diﬀ での性能低下割合にリビジョン数

幅なログ数の削減効果が確認できる．さらに実行時間の結を乗算する形で性能悪化が現れたと推測できる． 上記で述果を表す図 9 と比較すると，このようなクエリほど実行時

べた AST 構築の工夫や，キャッシュ等の組み合わせによ間が増加する傾向が読み取れる．

る性能改善が必須であるといえる．
ただし，この実験ではリポジトリ内の全て（2100 個以上）

4.4 考察のログを得る，という状況における性能を比較した．しかほぼ全てのリビジョンに対して，git-diﬀ は 5 秒以内に完し，実際の開発過程において過去のログを確認する場合，了することができた．git-diﬀ に対する MJgit の拡張クエ

一部の直近のリビジョンのみに関心があることが多い．こリの利用は実用的な範囲であると考えられる．

の場合の性能低下は全ログの場合と比べて極めて小さく，また，実行時間の増加とファイル数の相関から，Java のファイル数が多いと実行パフォーマンスが低下することがc 1959 Information Processing Society of Japan⃝

実際の開発者がこの性能低下をどのように感じるかは被験者実験による調査が必要である．

8

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959) 

less や Web ブラウザといった様々なツールを組み合わせて  

行われる．本被験者実験では，「あるメソッド/変数」に着目しているという状況を想定し，そのメソッド/変数がど

のリビジョンで変更されたか（TaskA ）と，そのリビジョ

ンでどのように変更されたか（TaskB ）の 2 種類にタスクを分類した．

       

図 11: 被験者の熟練度
Fig. 11 Skill of subjects

TaskA は履歴の中から対象のリビジョンを探し出すタスクであり，以下のコマンドの利用を想定している．
$# 既存手法jgit log# 提案手法$ mjgit log -- method = x

TaskB は，TaskA で発見したリビジョンでの具体的な変5. 被験者実験
5.1 概要この実験の目的は，Git を用いた開発履歴の理解というタスクに対して，MJgit がどの程度有用であるかを確認す

更内容をコードリーディングし，特定のメソッド/変数がどのように変更されたかを理解するタスクであり，以下のコマンドの利用を想定している．
$

況での履歴理解に要する時間を比較する．さらに定性評価
として，インタビューにより MJgit を使用した印象やコメントを収集し分析する．履歴理解のコードリーディングタ
スクは，性能評価実験でも用いた Log4j のリポジトリから
著者らが作成した．

# 提案手法$ mjgit show -- method = x

ることである．このために，被験者 16 名に対して複数のコードリーディングタスクを与え，MJgit あり/なしの状# 既存手法jgit show

TaskA は 2 ペア（4 タスク），TaskB は 8 ペア（16 タス
ク）の計 10 ペアのタスクを用意した．各ペアはタスクの難易度や，コードの変更内容が似たもの同士になるように設定した．そのペアの片方で MJgit を利用可能（ツールあり）とし，もう片方で利用不可（ツールなし）と設定し，ペアごとの結果を比較する．なお，全てのタスクは Log4jのリポジトリに記録された実際の変更履歴から，著者らが作成した．

5.2 被験者
被験者は大阪大学大学院情報科学研究科に所属する教員

1 名，同研究科所属の修士の学生 12 名，大阪大学基礎工学
部の学部生 3 人の計 16 名を対象とした．さらに，被験者は後述するタスク難易度の差を除外するために，X と Y の2 つのグループに分割した．
被験者の Git と Java に対する熟練度を図 11 に示す．全5.4 タスクの実行順序とツール有無の割り当て
この実験では，MJgit への慣れやタスクへの慣れによる実験への影響が考えられる．この影響を排除するために，先ほど設定した各ペアの実行順序が隣合わないように，かつツールありタスクとツールなしタスクが交互になるようにタスクをシャッフルした．

ての被験者はコードリーディングの対象となる Java 言語の文法を熟知している．一部の Git に習熟していない被験者には，練習タスクの最中に実験に用いる最低限の Git コ

表 5 に，シャッフルされたタスクの実行順とタスクの答えとなる変更内容の例を示す．タスク ID の数字はタスク

マンドの利用方法を習得してもらった．
表 5: タスクの実行順序と MJgit 有無の割り当て（一部）

5.3 実験タスク

Table 5 Execution order and allowance for MJgit usage foreach task

実験タスクは，Git リポジトリに対する開発履歴の理解である．実施した 2 種類のタスクは以下の通りである．

実行

MJgit の有無

順序

X

Y

引数を追加

1

あり

なし

引数を追加

4

なし

あり

2a

null チェック追加

5

あり

なし

2b

null チェック追加

2

なし

あり

3a

変更なし*3

3

あり

なし

3b

変更なし

6

なし

あり

...

...

ID

変更内容

TaskA : ある期間中のリビジョンから，特定のメソッド/

1a

変数がどのリビジョンで変更されたかを見つける．

1b

TaskB : TaskA で発見したリビジョンで，特定のメソッ
ド/変数がどのように変更されたかを理解する．
現実的には，開発履歴の理解という行為は「なぜ」「誰が」「どのファイル/メソッド/変数を」「どのように」といった様々な観点を内包しており，git-log や git-diﬀ，さらには

c 1959 Information Processing Society of Japan⃝*3

コードフォーマッタ等の変更により，一見変更されているように見えるがプログラム的に一切変更なしというケース．

9情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)の難易度を表しており，数字が同じタスクはペアであるこ

とを意味する．タスク ID の末尾の a と b はペア間の識別子であり，被験者グループ X に対しては a のタスクで提案

ツールあり，b のタスクで提案ツールなしとした．一方グ
ループ Y に対しては，b でツールなし，a でツールありと




した．



5.5 実施の流れ

被験者実験は以下の流れで実施した．


1. MJgit の機能の解説：MJgit の使用方法や振る舞いに

TaskA
TaskA
     

ついて被験者に説明する．

TaskB
TaskB
     

図 12: タスク完了時間の比較
Fig. 12 Comparison of completion time

2. タスクの練習：簡単な練習用タスクを実行してもらい，ツールの具体的な使い方と回答の方法を習得しても5.7.2 個々のタスクに対するタスク完了時間の結果

らう．

より詳細な分析として，個々のタスクに対する作業時

3. タスク実行：5.4 節で決定したタスクの実行順序通り

間の結果を図 13 に示す．各箱ひげは個々のタスクを表しに被験者にタスクを実行してもらう．グループ X/Yており，隣り合う 2 つの箱ひげが同難易度のタスクペアの被験者のいずれもツールあり/なしのタスクを交互を意味している．白色の箱ひげが MJgit なし，ピンク色に 20 回実施する．各タスク実施後は，回答用フォー

が MJgit ありを意味する．なお，個々のタスクペアは難ムにその作業時間と回答を記入する．

易度で並び替えられており，右ほど難しいタスクである．

4. アンケート回答：全タスクを完了した後，オリジナルの JGit と比較した MJgit の印象を回答してもらう．

TaskA は複数のログから目的のログを探す内容であり，複数のコマンドの組み合わせが必要なため難易度が高い．
まず，ツールによる効果が大きかったケースとして，左から 3 番目のタスクがある．このタスクは，メソッド宣言

5.6 定性評価
全タスクの実施後，被験者に以下のアンケートを答えてもらい，ツールの有用性や課題を確認する．

順序の移動などによりメソッド全体が大きく変化したよ
うに見えるが，本質的な変更は一切ないというタスクである．このようなノイズが多いリビジョンの理解に対して，• TaskA で MJgit は使い易かったか（5 段階評価）• TaskB で MJgit は使い易かったか（5 段階評価）• MJgit による速度低下をどう感じたか（5 段階評価）• 今後 MJgit を使いたいか（5 段階評価）

表 6: 被験者ごとのタスク完了時間の比較
Table 6 Comparison of completion time for each subject
MJgit なし

MJgit あり

平均完了時間平均完了時間

被験者

グループ

1

X

143 秒

75 秒

5.7 実験結果

2

X

192 秒

160 秒

5.7.1 タスク完了時間の結果

3

X

107 秒

106 秒

4

X

160 秒

61 秒

5

X

213 秒

128 秒

了時間の比較を図 12 に示す．縦軸はタスク完了に要し

6

X

99 秒

44 秒

た時間であり，横軸が TaskA （あるいは TaskB ）に対する

7

X

152 秒

112 秒

ツールなしとありの結果を表す．なお，実験中に被験者か

8

X

104 秒

96 秒

らツールの動作について質問を受けたことで作業時間が大

9

Y

256 秒

149 秒

きく伸びた 1 ケースは，結果から除外することとした．

10

Y

131 秒

110 秒

11

Y

80 秒

49 秒

12

Y

144 秒

105 秒

• その他 MJgit についての自由記述

TaskA と TaskB における MJgit ありとなしのタスク完

TaskA と TaskB いずれにおいても，完了に要する時間が削減されている．特に TaskA では大幅な時間削減が確

13

Y

213 秒

175 秒

認でき，その中央値は 140 秒から 72 秒に減少（約 50%削

14

Y

229 秒

98 秒

減）している．ウィルコクソンの順位和検定を用いて有意

15

Y

198 秒

156 秒

16

Y

141 秒

76 秒

160 秒

106 秒

差を検定したところ，TaskA で p = 4.11 ∗ 10

−7

，TaskB で

p = 2.62 ∗ 10−3 であり，共に優位な差が確認できた．
c 1959 Information Processing Society of Japan
⃝

平均

10

情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)


700







600
500
400
300
200
100
0

TaskA

TaskB







図 13: 個々のタスクに対する完了時間の比較
Fig. 13 Comparison of completion time for each task

MJgit は効果を大きく発揮すると考えられる．

かし，MJgit では検索したいメソッドの文脈に絞って log

一方で，左から 2 番目のペアや 6 番目のペアでは大きなを見ることができるため，ここで表示されるコミットが減少は見られなかった．これらのタスクでは，対象メソッ

見たいメソッドを変更したものであることが保証されてドに対して大幅な変更がなく，変更箇所も 1,2 行の if 文のおり，レビューの手間が大幅に削減できると思う．

追加などの比較的発見しやすく，理解しやすいタスクであった．このようなノイズが少ないリビジョンに対してはとても使い易く便利なツールだと思う．特に log コマン

MJgit はあまり大きな効果を発揮できなかった．

ドでクエリを指定できるのは便利だと感じた．

5.7.3 被験者ごとのタスク完了時間の結果
被験者ごとのタスク完了時間の比較を表 6 に示す．この
表は，各被験者の全 20 個のタスクにおける平均作業時間
を，ツールの有無で分類して一覧にした表である．
全ての被験者が，MJgit を使用することで作業時間の平均時間を削減できていた．その中でも被験者 6 と 11 は，出力結果に対して文字列検索するといった外部ツールを併用しており，ツールなしでもタスク完了時間が短い．そのよ
うなツール等に熟練した被験者であっても，ツールを使うことでその作業時間をさらに短縮できており，提案ツール

同様の Java 構文に特化した検索機能が GitHub に実装されていると便利だと思う．

一方で，MJgit の短所や改善点に関する意見もいくつか見受けられた．
空行のみの変更がしばしば出てきたので，そのような場合
はログ出力を抑制してほしい．また，コードフォーマッ
トの変更のようなプログラムの動作に影響のない diﬀ は出力しないオプションがあると良い．

の有用性が伺える．

変数名だけでなく，どのメソッドの変数かというスコープ

5.7.4 アンケートの結果

も同時に指定できるとより絞り込みがうまく働くと思う．

アンケートの結果得られた MJgit に対する意見を図 14に示す．この結果から，この実験で与えたタスクにおいて

Exception 周りのみの差分を得るようなオプションもある

MJgit はオリジナルの JGit 以上の使いやすさがあり，実行と特定の状況で役に立つ．

時間の低下はそれほど気にならないということがわかる．
また，git-log を使用する TaskA において MJgit が特に使
いやすいことがわかる．そして，今後 MJgit を使用したいと思った被験者は 12 名であった．

MJgit に対する意見の自由記述の回答をいくつか抜粋する．好意的な意見としては以下のような意見があった．
通常の log コマンドではコミットメッセージから変更内容を予測するしかなく，実際に見たいメソッドが変更されたのかどうかは show を組み合わせてみるしかない．しc 1959 Information Processing Society of Japan
⃝5.8 考察
被験者実験の結果により，MJgit を使用することで開発者のタスク完了時間を大幅に削減できており，MJgit は開
発履歴の理解というタスクに有用であると結論付けることができる．特に，複数のログから関心対象となるログを抜き出すタスク（TaskA ）で完了時間を半分に削減できていた．複数の開発履歴の中から，履歴に関するメタ情報（日付や開発者等）と Java 構文情報の組み合わせにより，効

11情報処理学会論文誌

Vol.0 No.0 1–13 (??? 1959)

TaskA 

TaskB
 





なノイズが影響する要因に対しては，実験の繰り返しによりそれらの変動要因を除外する必要がある．また，被験者実験におけるタスクの実行順序によって実験に慣れが発生
し，結果に影響を与えている可能性も考えられる．



  


次に外部妥当性に関して考える．性能評価実験では 2 つ





の Java プロジェクトのみを実験対象とした．他のプロジェ
  




クトに対して行なった場合には異なる結果が得られる可能性がある．また，被験者実験では実験で使用した Git についてある程度の知識を持った開発者のみを被験者としている．被験者が Git に不慣れな場合，異なる結果が得られる

"!
"

また構成概念妥当性に関する脅威としては，被験者実験での実施タスクは履歴の理解という複雑な行為の一部を抜場合がある．








き出した内容である点が挙げられる．実際の開発作業で履歴を理解するという状況では，それ以外の様々な手順を踏

む必要があり，MJgit による作業効率の向上は実験結果と異なる可能性がある．

!# !#

7. おわりに
本論文では効率的な開発履歴の支援を目的として，Git コ

図 14: アンケート結果

マンドに対してソースコード検索を統合するツール，MJgit

Fig. 14 Interview resultsを提案した．性能評価実験では，git-diﬀ に対する性能低下
は概ね実用の範囲内であることを確認した．また，被験者

率的な対象の絞り込みを支援できているといえる．

実験では，履歴理解というタスクに対してその完了時間を

被験者の中には grep などの文字列検索を併用していた被削減できること，及び複数の被験者から好意的な意見を得験者も存在していたが，このような条件下でも MJgit は有ることができた．性能評価実験で確認できた git-log に対効であった．これは，単純な文字列検索ではコードの本質する大幅な性能低下は，気にならないという意見が多く，とは関係のないコメントなどに検索がヒットしてしまい，

直近の数リビジョンを確認するような状況では無視できる

ノイズになるためだと考えられる．加え，コードフォー

範囲であるといえる．

マッタの適用やメソッドの移動といったテキスト部分が大

現在，MJgit はメソッド名と変数名の指定，及びプログ幅に変更するような状況では，提案手法による構文情報を

ラム構文の指定をサポートしているが，スコープの指定と用いたクエリの効果が大きかった．

いったより高度な構文情報の指定や，拡張対象コマンドでまた，実験で提示した 20 個のタスクは，1 個当たり数分以内に完了できるような容易な内容であった．実際の開発ありながら MJgit でサポートされていない git-blame の実
装は今後の課題である．

現場ではより複雑かつノイズの多い状況下での履歴理解が謝辞 本研究の一部は，日本学術振興会科学研究費補助必要であり，このような場合に MJgit はより有効に働くと金基盤研究（B）（課題番号：16H02908，18H03222）の助考えられる．

成を得て行われた．

実行速度については，性能評価実験で大幅な性能低下が確認できたが，本被験者実験のアンケートからはほとんど

参考文献

気にならないという意見が多かった．これは，直近の数リ[1]

ビジョンを確認するような状況では性能低下の影響が小さかったからだと考えられる．

6. 妥当性の脅威
内部妥当性に関する議論として，性能評価実験では全て

[2]

[3]

のコミットに対して MJgit を実行しているが，1 コミットに対して計測対象コマンドを一度ずつしか実行しておらず，繰り返しのないデータになっている．実行速度のよう

c 1959 Information Processing Society of Japan⃝[4]

Acharya, M. and Robinson, B.: Practical Change Impact Analysis Based on Static Program Slicing for Industrial Software Systems, Proc. International Conference
on Software Engineering, pp. 746–755 (2011).
Anvik, J., Hiew, L. and Murphy, G. C.: Who Should Fix
This Bug?, Proc. International Conference on Software
Engineering, pp. 361–370 (2006).
Arnold, R. S.: Software Change Impact Analysis, IEEE
Computer Society Press (1996).
Bajracharya, S., Ossher, J. and Lopes, C.: Sourcerer: An
infrastructure for large-scale collection and analysis of12

情報処理学会論文誌

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]
[17]

[18]

[19]

[20]

[21]

Vol.0 No.0 1–13 (??? 1959)

open-source code, Science of Computer Programming,Vol. 79, pp. 241–259 (2014).
Binkley, D. and Harman, M.: A large-scale empirical
study of forward and backward static slice size and context sensitivity, Proc. International Conference on Software Maintenance, pp. 44–53 (2003).
Cohen, T., Gil, J. and Maman, I.: JTL: The Java Tools
Language, Proc. International Conference on Objectoriented Programming Systems, Languages, and Applications, pp. 89–108 (2006).
D. Alwis, B. and Sillito, J.: Why are software projects
moving from centralized to decentralized version control
systems?, Proc. Workshop on Cooperative and Human
Aspects on Software Engineering, pp. 36–39 (2009).
D. Roover, C., Noguera, C., Kellens, A. and Jonckers, V.:
The SOUL Tool Suite for Querying Programs in Symbiosis with Eclipse, Proc. International Conference on
Principles and Practice of Programming in Java, pp.
71–80 (2011).
de Moor, O., Verbaere, M., Hajiyev, E., Avgustinov,
P., Ekman, T., Ongkingco, N., Sereni, D. and Tibble, J.: Keynote Address: .QL for Source Code Analysis, Proc. International Working Conference on Source
Code Analysis and Manipulation, pp. 3–16 (2007).
Dyer, R., Nguyen, H. A., Rajan, H. and Nguyen, T. N.:
Boa: A Language and Infrastructure for Analyzing
Ultra-large-scale Software Repositories, Proc. International Conference on Software Engineering, pp. 422–431(2013).
Hata, H., Mizuno, O. and Kikuno, T.: Historage: Finegrained Version Control System for Java, Proc. International Workshop on Principles of Software Evolution
and the annual ERCIM Workshop on Software Evolution, pp. 96–100 (2011).
Herzig, K. and Zeller, A.: The Impact of Tangled CodeChanges, Proc. Working Conference on Mining Software Repositories, pp. 121–130 (2013).
Hunt, J. W. and Szymanski, T. G.: A Fast Algorithm
for Computing Longest Common Subsequences, Communicaitons of the ACM, Vol. 20, No. 5, pp. 350–353(1977).
Kim, S., Zimmermann, T., Pan, K. and Whitehead,
E. J. J.: Automatic Identification of Bug-Introducing
Changes, Proc. International Conference on AutomatedSoftware Engineering, pp. 81–90 (2006).
Kimmig, M., Monperrus, M. and Mezini, M.: Querying source code with natural language, Proc. International Conference on Automated Software Engineering,pp. 376–379 (2011).
Meyer, M.: Continuous Integration and Its Tools, IEEE
Software, Vol. 31, No. 3, pp. 14–16 (2014).
Mondal, M., Roy, C. K. and Schneider, K. A.: Bug Propagation through Code Cloning: An Empirical Study,
Proc. International Conference on Software Maintenance and Evolution, pp. 227–237 (2017).
Paul, S. and Prakash, A.: A framework for source code
search using program patterns, Transactions on Software Engineering, Vol. 20, No. 6, pp. 463–475 (1994).
Rastkar, S. and Murphy, G. C.: Why Did This CodeChange?, Proc. International Conference on Software
Engineering, pp. 1193–1196 (2013).
Rattan, D., Bhatia, R. and Singh, M.: Software clone detection: A systematic review, Information and Software
Technology, Vol. 55, No. 7, pp. 1165–1199 (2013).
Ren, X., Shah, F., Tip, F., Ryder, B. G. and Chesley,c 1959 Information Processing Society of Japan
⃝

[22]

[23]

[24]

[25]

O.: Chianti: A Tool for Change Impact Analysis of Java
Programs, Proc. International Conference on Objectoriented Programming, Systems, Languages, and Applications, pp. 432–448 (2004).
Sun, X., Li, B., Leung, H., Li, B. and Li, Y.: MSR4SM:
Using topic models to eﬀectively mining software repositories for software maintenance tasks, Information and
Software Technology, Vol. 66, pp. 1–12 (2015).
Urma, R. G. and Mycroft, A.: Source-code queries withgraph databases – with application to programming language usage and evolution, Science of Computer Programming, Vol. 97, No. Part 1, pp. 127–134 (2015).
Volder, K. D.: Jquery: A generic code browser with adeclarative configuration language, Proc. International
Symposium on Practical Aspects of Declarative Languages, pp. 88–102 (2006).
Weiser, M.: Program Slicing, Proc. International Conference on Software Engineering, pp. 439–449 (1981).

佐々木 美和平成 29 年大阪大学基礎工学部情報科学科卒業．同年より同大学大学院情報科学研究科コンピュータサイエンス専
攻博士前期課程在学中．

柗本 真佑 （正会員）
平成 22 年奈良先端科学技術大学院大学博士後期課程修了．同年神戸大学大学院システム情報学研究科特命助教．
平成 28 年大阪大学大学院情報科学研
究科助教．博士（工学）．エンピリカ
ルソフトウェア工学の研究に従事．

楠本 真二 （正会員）
昭和 63 年大阪大学基礎工学部情報工学科卒業．平成 3 年同大学大学院博士課程中退．同年同大学基礎工学部助手．平成 8 年同講師．平成 11 年同助教授．平成 14 年同大学大学院情報科
学研究科助教授．平成 17 年同教授．
博士（工学）．ソフトウェアの生産性や品質の定量的評
価，プロジェクト管理に関する研究に従事．IPSJ，IEICE，

JSSST，IEEE，JFPUG，PM 学会，SEA，各会員．

13