情報処理学会 インタラクション 2019
IPSJ Interaction 2019

INT19018
2019/3/6

CodeGlass: GitHub のプルリクエストを活用したコード断片のインタラクティブな調査支援システム
柴藤大介1,a)

有薗拓也1,b)

宮崎章太1,c)

矢谷浩司1,d)

概要：ソフトウェア開発においてソースコードの理解は必要不可欠である．特に，実際の開発においてはコードの一部分（コード断片）の理解が必要となることが多い．我々が行ったインタビュー調査では，GitHub のプルリクエストの説明文とコメントに，コード理解において有用な情報が含まれていることが明らかとなった．しかし既存のシステムでは，コード断片の理解支援のためにプルリクエストが十分に活用されていない．そこで我々は，ユーザが選択したコード断片に関連する過去のプルリクエストを抽出し，ユーザに提供する CodeGlass を開発した．CodeGlass では，プルリクエストの説明文を解析し，実装内容
や開発背景に関する文章をインターフェース上で強調して表示することが可能となっている．CodeGlassのアルゴリズムにより，選択されたコード断片が過去のバージョンにおいて分裂していた場合にも，関連する過去のプルリクエストをユーザに提供することができる．我々が行った CodeGlass の定量的および定性的評価の結果，コード断片の理解や専門的用途における CodeGlass の有用性が確認された．

1. はじめに

近年のソフトウェア開発では，GitHub*1 という多人数開発を支援するコードホスティングサービスが広く利用されソフトウェア開発においてソースコードの理解は必要不ている．GitHub では，コード変更の管理とコードレビュー

可欠である．ソフトウェア開発者はコードを書くだけでなを支援する機能であるプルリクエストを用いたソフトウェ

く，同じチームの他の開発者によるコード変更をレビュー

ア開発が推奨されている．他の開発者にコード変更の意図

したり，開発プロジェクトのスケジュールや進捗を管理しや内容を正しく伝えるためには，プルリクエストにコードたりする必要がある．その全てのタスクにおいて，正確な変更の説明文を記すことが重要とされている．この説明文

コード理解が常に必要となる．このため，ソフトウェア開発におけるコード理解の重要性は広く認知されている．
実際のソフトウェア開発では，ソースコード全体ではな
く，コードの一部分（コード断片）の理解が必要となることが多い．例えば，開発者はバグを修正するために，関連するコード断片（関数やクラスなど）の現状を把握してか
らコードの修正を行う．コードレビューにおいても同様に，主に変更のあったコード断片に対して問題がないことを確認する．このようにコード断片の理解はソフトウェア
開発において重要であり，コード断片の実装内容や開発背景といった情報をユーザに提供することができれば，ソフ
トウェア開発を支援できると考えられる．
図 1: CodeGlass 上でユーザは選択したコード断片に関連す
1

a)
b)
c)
d)

IIS-Lab東京大学
The University of Tokyo
7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033, Japan
shibato@iis-lab.org
arizono@iis-lab.org
miyazaki@iis-lab.org
koji@iis-lab.org© 2019 Information Processing Society of Japanる過去のプルリクエストを参照することができる．プルリ
クエストの説明文に含まれる実装内容や開発背景といった情報は，ユーザのコード理解を支援することができる．

*1

https://github.com

159情報処理学会 インタラクション 2019
IPSJ Interaction 2019

INT19018
2019/3/6には，コード変更の実装内容や開発背景といった，コード

た過去のコード変更を提示することにより，コード変更

変更を理解するための情報を記載することが求められる．

にバグが含まれることを防ぐために着目すべき点を開発

我々が行ったプログラマを対象としたインタビュー調査で者がより正確かつ効率的に発見することが可能となった．

は，プルリクエストに含まれる情報がコード断片の理解に

JRipples や CRITICS がコードレビュアーのコード理解のおいて有用であることが示唆された．しかし，プルリクエ

支援を目的としている一方で，正確なコードレビューを行

ストは主にソフトウェア開発の効率化を目的として利用さうためにはコード変更の説明が詳細に記述されているこ

れており，コード断片の理解を支援するためには十分に活とも重要である．そこで Buse ら [4] は，コード変更から用されていない．

その説明文を自動生成する手法を実装した．ユーザ評価のそこで本研究では，コード断片に関連する情報を提供す

結果，既存のコミットメッセージの 89 ％は Buse らの手

る CodeGlass というシステムを開発した（図 1）．CodeGlass法を用いて生成できうる内容であることが分かった．同様

はユーザが選択したコード断片に関連する過去のプルリクに，Linares-Vasquez ら [13] が開発した ChangeScribe もま

エストを抽出し，ユーザに提供する．さらに，プルリクエ

た，コミットメッセージとして使用可能な説明文をコードストの説明文を解析し，実装内容や開発背景に関する文章

変更から自動生成するシステムである．ChangeScribe にはをインターフェース上で強調して表示することが可能と説明文にコード変更の内容だけでなくその背景も含めるたなっている．LHDiff [1] を改良したアルゴリズムにより，めに，複数の情報抽出アルゴリズムが実装されている．

選択されたコード断片が過去のバージョンにおいて分裂し本研究の目的は，前述の先行研究とは異なり，コード断ていた場合にも，CodeGlass は関連する過去のプルリクエ

片の理解支援である．コード理解においては，コード変更

ストを提供することができる．学生による CodeGlass の定に付随する説明文が有益であることが既に明らかとなって量的評価により，コード断片の理解のための情報収集においる [5], [19]．本研究はコード断片に関連する過去のコー

いて，CodeGlass が有用であることが分かった．さらにプド変更を抽出し，それらに含まれる説明文をユーザに提供

ログラマを対象とした定性的評価を行った結果，専門的用することで，コード断片の理解支援を目指す．

途における CodeGlass の有用性が明らかとなった．本研究がソフトウェア工学とヒューマン・コンピュータ・インタ
ラクションの分野にもたらす貢献は以下の通りである．

2.2 ドキュメントの作成と活用の支援
ドキュメントはコード理解における有用な情報源であ• ユーザが選択したコード断片に関連する過去のプルリ

り，その重要性は広く認知されている．しかし実際のソフクエストを表示し，実装内容や開発背景に関する文章

トウェア開発プロジェクトではドキュメントを作成する時を強調する CodeGlass インターフェースの構築間が不足していることが多い [6]．そこでドキュメントの• LHDiff [1] の改良による，過去のバージョンにおけるコード断片の追跡精度の向上• コード断片の理解における CodeGlass の有用性の定量的・定性的評価

2. 関連研究2.1 コード変更の理解支援作成支援や，既存のドキュメントを活用したコード理解の支援に関する研究が広く行われてきた．

Sridhara ら [16] は Java の関数の要約を自動生成する
SWUM というシステムを実装した．SWUM はソースコー
ド全体と関数の構造的関係性を解析することで，ドキュメ
ントとして使用可能な関数の説明文を自動生成することができる．McBurney と McMillan [14] は SWUM をさらに改

GitHub をはじめとする多くのソフトウェア開発管理シ

良し，与えられた関数のコード内での使用例も追加できる

ステムでは，コード差分を記録することでコード変更の追ようにした．これらの手法により，自動生成される説明文跡が可能となっている．加えて，開発管理システムの多くに文脈を考慮した情報を追加することが可能となった．まがバージョン管理の機能を提供しており，コード変更の管た Stylos ら [17] は，Java の API のドキュメントが簡単に検理やコードレビューのために広く活用されている．先行研

索できるようになる Jadeite を開発した．ユーザは Jadeite

究では，ソフトウェア開発におけるコード変更を理解する

上でドキュメントにエイリアスとなるクラス名や関数名をことを支援するための様々な手法が調査されてきた．

追加することができる．このエイリアスは実際の Java のソースコードの多くの部分に影響を与えるコード変更がAPI と紐づいており，ユーザは API の名前だけでなくそのバグを含んでいた場合，システムに重大な問題が生じてエイリアスでも API のドキュメントを検索することがでしまう恐れがある．Buckner ら [3] が開発した JRipples できる．

は，構文解析を行うことにより，コード変更にバグが含ま

既存のドキュメントをコード理解のために活用する先行れていた際にソースコードの中で影響を受ける可能性があ

研究も多く存在する．Stack Overflow の投稿には API の使るクラスをユーザに提示することができる．Zhang ら [22]

用方法が記述されていることが多いため，ユーザは独自にが開発した CRITICS は，与えられたコード変更と類似しドキュメントを作成・管理することなく API の使用方法を© 2019 Information Processing Society of Japan160

情報処理学会 インタラクション 2019
IPSJ Interaction 2019

INT19018
2019/3/6

参照できる可能性がある．そこで，Subramanian ら [18] はことで，コード変更をより分かりやすく他の開発者に伝えAPI と Stack Overflow 上の投稿のコード例を紐付けるアルることが可能となっている．PA3 と PA5 は，コードが実装

ゴリズムを実装した．また Dekel と Herbsleb [7] は，膨大された理由を後から確認するために，開発背景といった情なドキュメントからコード理解において重要な情報を抽出

報を含むプルリクエストを参照することがあると指摘した．

することでコード変更のデバッグの成功率を改善できるこ

それは，実装を見ててこれってどういう意図でこうとを示した．さらに Treude ら [20] は，教師あり学習を用なってんのとかが，気になった時は，結構プルリクエ

いて Stack Overflow から現在のドキュメントには含まれてスト上で議論がなされていることが多いので，それをいない情報を抽出する手法を実装し，教師なし学習を用い探しに行くことはあります． [PA3]た手法と比較してより多くの有用な情報を Stack Overflow

僕はわりと探っちゃうタイプなので，昔どういうことから抽出できることが明らかとなった．

あったんだろうみたいなのは追っちゃう感じですね．

このように既存の情報源を活用したコード理解の支援に関する研究が広く行われてきたが，情報源としての GitHub[PA5]のプルリクエストの有用性はまだ明らかとなっていない．
プルリクエストは GitHub を用いた開発において一般的に使用されており，プルリクエストの説明文はドキュメントとして活用できる可能性がある．コード理解を支援するための情報源としての GitHub のプルリクエストの可能性を示すことも本研究の目的の 1 つである．

3. インタビュー調査
3.1 プログラマの要望調査
実際のソフトウェア開発でのコード理解における障壁を調査するために，我々は IT 企業に所属する 5 人のプログラ
マ（PA1–5，全員男性）にインタビューを行った．実験参加
者は全員，ソフトウェア開発プロジェクトにおいて GitHubを日常的に利用していた．インタビューでは実験参加者がコード理解をどのように行い，その際にどのような障壁が存在するのかを重点的に尋ねた．
開発背景を理解する難しさ
チーム開発においては，実装やコードレビューのために
他の開発者が実装したコードを理解する必要があるが，他人が書いたコードの理解には大変な労力を要する．また，実際のソフトウェア開発におけるコード理解では，コードの実装内容だけでなく，なぜ実装されたのかという開発背景も把握することが重要である．PA1 は，コードレビュー
において背景知識の不足がコード理解における問題の一つであることを以下のように指摘した．
プロダクトの背景がわからないことが課題となってい以上より，プルリクエストの説明文にはコード理解において有用な情報が含まれている可能性があり，実際に開発現場で利用されることがあることを確認した．この発見により，プルリクエストをコード理解に活用するシステムを構築することを考えるに至った．

3.2 既存技術の問題点調査
続 い て 我 々 は ，既 存 の ツ ー ル, 特 に tig*2 と recursive-

blame*3 がコード理解の支援においてどのように不十分であるかを調査した．tig は git blame のコマンドを再帰的に実行できるコマンドラインインターフェースであり，

recursive-blame は特定のキーワードを含む過去のコード変更を抽出することができるコマンドである．本調査ではGitHub のプルリクエストを用いた開発経験のある 7 人の学生（PB1–7）にインタビューを行った．インタビューではまず tig または recursive-blame を用いてコード断片の調査を行ってもらい，その後 2 つのツールに対する使用感を尋ねた．その結果，既存のツールでは過去のプルリクエス
トをコード理解のために活用することができない 2 つの理由が明らかとなった．
コード断片追跡機能の限界
実験参加者らは，既存のツールではコード断片が削除または移動された際に，開発履歴の情報が抽出できなくなることを指摘した．これはコード断片が削除または移動された場合，既存のツールでは単にコード断片が存在しないことのみが表示されるからである．

て，長く見ている人が初めてそのチーム内でレビュー

違う名前や使い方が変わったときに，じゃあ何になっできるようになっていて，まだやっぱり新入りの人がたんだろうというってのを探すためには，前の名前しコードレビューできるような状況までドキュメント

か知らないときは自分で探さないといけない．削除なが整備されていないし，やっぱり背景理解が難しい．

のか，変更なのかわからないのが今のツールではわか[PA1]
コード理解のための情報源としてのプルリクエスト
実験参加者らはコード変更をレビュアーに説明するために，GitHub の機能の一つあるプルリクエストを活用していた．プルリクエストでは，説明文に目的や内容を記述する© 2019 Information Processing Society of Japanらない． [PB4]
インタラクションの限界

tig と recursive-blame では，追跡するコードの行やキー*2*3

https://github.com/jonas/tig
https://github.com/scottgonzalez/recursive-blame161

情報処理学会 インタラクション 2019
IPSJ Interaction 2019

INT19018
2019/3/6

ワードを繰り返し指定することで，関連する過去のプルリ

る過去のプルリクエストの表示順を時系列順，実装内容

クエストを特定することができる．しかし，プルリクエス（Execution）に関する情報が多い順，開発背景（Rationale）

トを特定した際に提示される情報には，説明文やコメント

に関する情報が多い順に並び替えることができる．これにが含まれていないため，コードの理解につながると限らなより，どのように開発が進められてきたか（History）といいことが指摘された．

う情報に加えて，実装内容や開発背景を含むと考えられる全部やった後にさ，description なかったらさ，なんや
ねんって感じやん．多分 description が一番大事だから，はずれだったらすぐ次のを見せてほしい． [PB2]

プルリクエストを強調して提示することも可能となっている．
それぞれのプルリクエストには，タイトルやプルリクエ
ストの ID，含まれるコミット数，コードの変更行数，そしtig ではコード中の 1 行を，recursive-blame ではキーワーてコメント数が表示されている．また，GitHub 上でのプルドもしくはコード 1 行のみを検索に利用できるが，コードリクエストや，コード差分，レビューコメント，そしてプル

理解においては複数行の選択が必要であることを指摘してリクエスト作成者へのウェブページへのリンクも示されていた．

いる．加えて，図 2a (3) に示すように，選択されたコード

コード読んでて，この行だけわかんないってなることはないから． [PB1]

断片と一致する可能性があるコード断片が過去のバージョンの 1 つで複数ある場合，そのコミットへのリンクも表示する．ユーザがプルリクエストのタイトルをクリックする

この if の中みたいな，意味のある単位で見たい．if のと，CodeGlass はその詳細を表示する（図 2b）．詳細画面

行自体は別にそれほど興味ないし中身が大事かな，みでは，プルリクエストの基本的な情報に加えてレビューコ

たいな． [PB5]

メントも表示される．また，図 2b (4) に示すように，プル
リクエストの説明文中で実装内容や開発背景に関する情報

3.3 まとめ
我々が行った関連研究の調査では，コード理解に重要な情報は以下の 5 つに大別されることがわかった．

であると推定された箇所は，色付きの文字で強調される．

CodeGlass においてユーザは，クラスや関数といった単位に縛られることなく自由にコード断片を選択し，関連す• Execution: そのコードが何を実行するのか [9].

る過去のプルリクエストを調べることができる．特にユー• Rationale: 何故そのコードが実装されたのか [9].

ザが大きなクラスや関数のコードを調査する際には，自由• History: そのコードがどう変更されてきたのか [21].

にコードを分割して調べることができるため有用であると• Contributor: 誰がそのコードの実装に関わったのか [8].

考える．CodeGlass はプログラミング言語に依存すること• Usage: そのコードがどこでどう使用されるのか [10].

なく動作するため，GitHub 上の全てのオープンなリポジト

我々のインタビュー調査により，プログラマが特にコーリに対して，CodeGlass のサーバにリポジトリをクローンド変更に関する詳細な説明と開発背景の知識をプルリクすることで利用可能となっている．アクセス制限などを設

エストに求めていること，さらに既存のツールではそれ定することで，技術的にはプライベートリポジトリにも対が十分に支援されないことが明らかとなった．したがっ応することができる．

て，我々が構築するシステムにおいては特に Execution とRationale に関する情報収集を支援すべきであると考えた．

4. CodeGlass インターフェース

5. 実装内容と開発背景を含む説明文の抽出手法
プログラマを対象としたインタビューにより，コード断片の理解においてプルリクエストに含まれる情報が有用でCodeGlass は GitHub のプルリクエストを用いてコードあることがわかった．また，コード断片を理解する上で，断片の理解を支援するインタラクティブなツールである．

そのコード断片の実装内容だけでなく，開発背景も理解す

本研究におけるコード断片は，ソースコード中の一部の連ることが重要であることが明らかとなった．しかし既存の続したコードである，と定義する．即ち，コード断片は一システムでは，コード変更の説明文に含まれる情報を，実行のコードにも，関数やクラス，あるいはファイル全体の装内容や開発背景といった情報に分類することは行われてコードにもなり得る．CodeGlass はユーザが選択したコー

いない．そこで我々は，プルリクエストの説明文内の文章

ド断片に関連する過去のプルリクエストを抽出し，インの中から，関連するコード変更の実装方法と関連するコー

ターフェースを通じてユーザに提供する．

ド変更の実装理由を抽出するための分類器を実装した．

図 2 に CodeGlass のインターフェースを示す．ユーザはマウスドラッグでコード断片を指定する（緑でハイライ

5.1 データセットの構築ト）ことで，関連する過去のプルリクエストやコミットを開発者が実装内容や開発背景といった重要な情報を漏れ確認できる（図 2a）．図 2a (1) に示すボタンから，関連すなくプルリクエストに記述することを促すために，GitHub© 2019 Information Processing Society of Japan162

情報処理学会 インタラクション 2019
IPSJ Interaction 2019

INT19018
2019/3/6(a) 関連するプルリクエストの一覧画面．

(b) プルリクエストの詳細画面．

図 2: CodeGlass のインターフェースは，ユーザが選択したコード断片（緑にハイライトされたコード）に関連する過去のプルリクエストの一覧を表示する．抽出されたプルリクエストの表示順は，時系列順，実装内容（Execution）に関する情報が多い順，開発背景（Rationale）に関する情報が多い順に並べることができる (1)．各プルリクエストにはタイトル，コ
ミット数，コードの追加および削除行数，コメント数，そして関連する各ウェブページへのリンクが表示される (2)．さらに，選択されたコード断片と一致する可能性があるコード断片が過去のバージョンの 1 つで複数ある場合，そのバージョンにおけるソースコードへのリンクが表示される (3)．プルリクエストのタイトルをクリックすると，その詳細情報を確認できる．詳細画面では，プルリクエストの情報に加えて，レビューコメントも表示される．さらに，Execution に分類される文章は緑色で，Rationale に分類される文章は青色で表示される (4)．のリポジトリにはマークダウンで書かれたプルリクエスト

GitHub から条件 1 と条件 2 を満たすデータを収集したのテンプレートを登録することができる *4 ．テンプレー

結果，26 のリポジトリと 4061 件のプルリクエストのデートに沿ってプルリクエストの説明文を記述することで，他タを集めることができた．その 26 のリポジトリに登録さの開発者がコード変更を理解するために必要な情報を網れているプルリクエストのテンプレートについて，著者の羅したプルリクエストを作成することができる．テンプ

2 人が Execution または Rationale に該当するヘッダーを手

レート内のヘッダーには，実装内容（Execution）に該当す動で抽出した．そして，それらのヘッダーの下に存在するるヘッダー（“Implementation Details” など）や，開発背景

文章を抽出することにより，Execution の文章を 3141 件，（Rationale）に該当するヘッダー（“Motivation and Context”

Rationale の文章を 3451 件を得た．さらに，抽出した文章など）などが多く採用されている．そのようなヘッダーの内に含まれるマークダウン表記と絵文字を削除すること

下に記述されている文章を抽出することで，分類器の学習

で，分類器の学習用のデータセットを構築した．

に必要なラベルづけされたデータセットを構築することと5.2 分類器の実装と評価

した．
以上のようなデータを GitHub から収集するために，我々

分類器の実装にはサポートベクターマシンを用いた．学は次の条件を満たすリポジトリに存在するプルリクエスト

習に必要な特徴量は，文章の分類において一般的に使用のデータを抽出した．

されている bag-of-words， tf-idf，word2vec を用いた [11]．

条件 1

リポジトリのスター数が 100 以上であること．

さらに，tf-idf と word2vec が抽出する情報が互いに補完的

条件 2

プルリクエストのテンプレートがリポジトリに登な役割を果たすことが報告されているため [12]，本研究録されており， Execution に関係する節か Rationale ににおいても word2vec を tf-idf により重み付けした特徴量関係する節がテンプレート内に存在すること．

（word2vec+tf-idf）も利用した．それぞれの特徴量を用いて条件 1 はリポジトリの開発者数の目安として掲げたもの

分類器を学習し，10 分割交差検証法により分類器の精度である．スター数が大きいものほど GitHub 上での開発がを検証した結果，bag-of-words を用いた時の F 値の平均が盛んであり，条件 2 を満たすプルリクエストを多く取得で0.64，tf-idf を用いた時の F 値の平均が 0.68，word2vec をきるだろうと考えた．また，条件 2 に適応することで，前用いた時の F 値の平均が 0.72，word2vec+tf-idf を用いた時

述のようにラベルづけされたデータを収集することがでの F 値の平均が 0.73 であった．以上より word2vec+tf-idf

きる．

を用いた時が最も精度が高かったため，word2vec+tf-idf を用いて学習を行った分類器を CodeGlass 上に実装した．

*4

https://help.github.com/articles/
creating-a-pull-request-template-for-your-repository© 2019 Information Processing Society of Japan

図 2a (1) に示すボタンから，ユーザはプルリクエスト163

情報処理学会 インタラクション 2019
IPSJ Interaction 2019

INT19018
2019/3/6の表示順を時系列順，Execution に関する情報が多い順，

おいて他のコード断片と統合されていたり，分割されて実Rationale に関する情報が多い順に並び替えることができ装されていたりする可能性がある．特に大規模なソフトる．さらにプルリクエストの詳細画面では，Execution およ

ウェア開発プロジェクトでは，ソースコードの構造的変更

び Rationale に 80%以上の確率で分類されると推定された文が繰り返し行われることが多いため，LHDiff をそのまま章がハイライトされる．図 2b (4) に示すように，Execution

CodeGlass のサーバに実装すると，CodeGlass の実用性がに分類される文章は緑色の，Rationale に分類される文章は制限されてしまう．そこで我々は新たに graceful matching

青色の文字で表示することで，ユーザの情報収集を支援すを提案し，LHDiff に導入することでこの問題を解決するこることが可能となっている．

とを試みた．

6. コード断片追跡アルゴリズムの改良

LHDiff は CPT が常に一つであるという仮説の下，最もdT として決定する．
文字列的類似度が高いコード断片を CP

6.1 LHDiff の改良方法

我々は新たに，正解目的コード断片が一つに定まる可能

CodeGlass のサーバは，ユーザが選択したコード断片に関連する過去のコミットを抽出する必要がある．git のコ

性が高いことを示す閾値である DMT（Definitive MatchingdT の候補の文字列的類似
Threshold）を導入した．CPS と CP

マンドである blame を使うことで，コード断片を最後に変dT を決度が DMT よりも高かった場合，LHDiff と同様に CP

更したコミットを特定することができる．しかし，git のコ

定する．しかし，過去にソースコードの構造的な変更や大マンドではコード断片が過去のバージョンにおけるソース

規模な修正が行われていると，文字列的類似度が低くなり，

コードのどこに存在するのかを知ることができない．した

CPT を正確に一意に推測することが難しくなる．そこで，がって，ユーザが選択したコード断片に関連する過去のコ
ミットを最新のものだけでなく全て抽出するためには，選別の閾値である CMT（Candidate Matching Threshold）を導dT が存在しなかった場合，CMT
入する．DMT を上回る CP

択されたコード断片が過去のバージョンにおいてどこに存を上回るコード断片を全て，CPT である可能性があるとし在するのかを特定する必要がある．

てインターフェースに返す．CodeGlass のインターフェー

アルゴリズムを説明するために，まず被選択コード断片

スは，それらのコード断片を含むコミットを図 2a (3) のよと目的コード断片を定義する．被選択コード断片（CPS ）うに表示する．ユーザはそのコミットをクリックして過去

は，ユーザが CodeGlass のインターフェース上で選択したのバージョンにおけるソースコードを確認し，CPS として

コード断片である．また目的コード断片は，過去のバー

選択し直すことで，引き続きコード断片の調査を継続する

ジョンにおける被選択コード断片と対応したコード断片でことができる．

ある．アルゴリズムは CPS の情報を受け取り，過去のバー

DMT と CMT の二つの閾値を設定するために，Chart.js

ジョン内の目的コード断片の位置を推定する．ここで，正dT ）を解目的コード断片（CPT ）と推定目的コード断片（CPのリポジトリに含まれる 49 個のコミットにおける，変更

新たに定義する．正解目的コード断片は過去のバージョン

した．このデータセットでは LHDiff だけでは CPT を特定

における CPS にマッチするコード断片である．また，推定することが難しい構造的変更からなるコミットのみを意

目的コード断片はアルゴリズムが推定した過去のバージョ

図的に選定した．そして，それぞれのコード断片に対してンにおける被選択コード断片を意味する．アルゴリズムがdT と CPT が一致する．
完全に正しく動作した場合，CPCPS を選択し，それに対応する CPT のラベル付けを行った．

先行研究では，コード断片を過去のバージョンの中でコード断片を IM（incorrect match）としてラベル付けした．

追跡する手法が提案されており，それらを CodeGlass の

図 3 に CPT （青）と IM（橙）の文字列的類似度の分布を前と変更後のコード断片の一対をデータセットとして構築

さらに，CPT と最も文字列的類似度の高い，CPT ではない

サーバのアルゴリズムとして活用できる可能性がある．

示す．この分布から IM の類似度は 0.65 未満であることがAsaduzzaman ら [1] が開発した LHDiff は，プログラミン

分かる．また，CPT の類似度は 0.4 より大きいことも分か

グ言語非依存で動作するコード断片追跡アルゴリズムである．したがって我々は，DMT を 0.65 に，CMT を 0.4 に設る．LHDiff は word-level fuzzy matching [15] を用いて CPS
dT との文字列的類似度を計算し，最も類似度が高かっ
と CP

定した．

たものを CPT として決定する．

6.2 改良アルゴリズムの定量的評価

しかし我々が LHDiff の事前調査を行った結果，コード

graceful matching が目的コード断片の特定の精度をどの変更が構造的変更（関数の統合や分裂，リファクタリング

程度改善するのかを明らかにするために，我々は GitHubなど）を含む場合，LHDiff はコード断片の追跡に失敗すの実際のコード変更データを用いた定量的評価を行った．

ることが分かった．この原因は，LHDiff では CPT が一つ評価に用いるデータセットは，1,000 人以上の開発者からしか存在しないと仮定されているからである．実際のコースターを付けられており，かつデータセット構築時に最ド変更履歴では，被選択コード断片が過去のバージョンにも新しく更新のあった Chart.js のリポジトリを選択した．

© 2019 Information Processing Society of Japan164

情報処理学会 インタラクション 2019
IPSJ Interaction 2019

INT19018
2019/3/6

7. 定量的ユーザ評価実験
7.1 実験内容
コードの Contributor と Usage に関する情報収集においては，既に有用なツールが広く使用されている（git-blame
コマンドなど）．そこで本実験においては，Execution（実装内容），Rationale（開発背景），History（開発経緯）に関する情報収集に関する評価を重点的に行うこととした．
コード理解を支援するツールのユーザ評価では，デバッ
グのタスクが広く採用されている [2], [7]．デバッグのタ
図 3: CPT （青）と IM （橙）の文字列的類似度の分布．

スクでは，実験参加者は故意に実装されているバグを特定はじめに Chart.js のリポジトリから 100 個のコード断片をし修正することが求められる．しかし，CodeGlass の場合

選択し，それらを Short（9 行以下，34 個のコード変更），

ユーザが過去のコード変更履歴を参照できてしまうため，

Middle（10 行以上 30 行以下，33 個のコード変更），そして実験参加者はバグ修正に必要なコード変更を容易に特定でLong（31 行以上，33 個のコード変更）の 3 つのグループきてしまう恐れがある．

に分類した．次にそれら 100 個の原コード断片の開発履歴

そこで我々は，箇条書きの短いドキュメントの作成をを辿り，5 つ以上の過去のバージョンにおけるコード断片

実験のタスクとして採用した．このタスクにおいて実験を抽出し，原コード断片と組み合わせる事で評価用のデー

参加者らは，与えられたコード断片に関する Execution，

タセットを構築した．そして，過去のコード断片を特定す

Rationale，History の情報を箇条書きで記す作業を行った．

る精度を graceful matching の有無で比較評価した．

また箇条書きの各項目に対して，実験参加者にはその項目評価指標として適合率（Pcp ）と再現率（Rcp ）を用いた．
dT として正しく推定されたのコード行数，li を CP
dT
lc を CPに対する自信度を 0 から 100 で与えるように指示した．高として間違って推定されたコードの行数，ln を CPT に含ま
dT には含まれてないコードの行数とした時，適合れるが CPることを意味する．

c
率と再現率は Pcp = lcl+l,ilc
Rcp = lc +lと定義した．
n

い自信度は，その項目のドキュメントに対し強い自信があ

1 つのタスクの時間は 20 分と設定した．また，我々は Chart.js のリポジトリにおける 3 つのソースコードの図 4 が示すように，全ての条件において graceful matching

ファイルをタスクとして選んだ．タスクに使用するソーを用いることで適合率と再現率が改善された．また，適スコードのファイルは，core.animations.js，core.element.js，

合率及び再現率の結果と graceful matching の有無に対して

core.ticks.js（タスク A，タスク B，タスク C）とした．な

重回帰分析を行った結果，適合率と再現率が有意に改善

お，実験参加者への負担を抑えるためにタスクの時間をされたことが分かった．適合率における回帰係数は 0.058

20 分に制限したため，リポジトリの中で比較的短いソー（SE = 0.025, p < .05），再現率における回帰係数は 0.051

スコードを選択した．著者のうち 2 人がそれら 3 つのソー（SE = 0.021, p < .05）であった．さらに，Short グループ

スコードと開発履歴を確認し，ドキュメントに記されるべの方が Long のグループと比較して，有意に高い適合率及き情報を解答としてまとめた．その結果，平均で 11.7 件のび再現率であった（ p < .05）．

Execution に関する情報，9.3 件の Rationale に関する情報，

graceful matching の評価を行った結果，コード断片の特6.7 件の History に関する情報からなる解答を作成した．

定における適合率および再現率を約 5%改善できたことが実験の条件は，GitHub 上のインタフェース（non-CG），分かった．また図 4 に示すように，graceful matching が頑開発背景と理由の並べ替え機能がない CodeGlass（CG-），

健性に貢献することが示された．例えば，ある 1 つのデー

並べ替え機能を持つ CodeGlass（CG）の 3 通りである．タ

タでは，LHDiff のみの場合適合率と再現率がそれぞれ 0.30

スクの順序を固定した上で，インタフェースの割当順序をと 0.40 であったが，graceful matching を適用することでcounter-balance した．

両方ともに 0.80 まで改善したことが確認された．graceful

本ユーザ評価では，12 人の学生（PC1–12，全て男性）をmatching はコード断片の特定の精度を改善することができ

実験参加者として得た．全員，1 年以上のプログラミング

るため，我々は graceful matching を CodeGlass に導入する経験がある，GitHub を用いた開発経験がある，JavaScriptこととした．

の使用経験がある，Chart.js の開発と使用経験がない，条件を満たしていた．以上を満たす実験参加者らは，開発経験はあるが今回取り組む開発プロジェクトに関する背景知識がないため，CodeGlass の想定ユーザと一致する．

© 2019 Information Processing Society of Japan165

情報処理学会 インタラクション 2019
IPSJ Interaction 2019

INT19018
2019/3/6

図 4: graceful matching のコード断片の特定精度の評価の結果．Short グループの適合率は，graceful matching を用いた場合，用いなかった場合の両方において中央値が 1.0 であった．
表 1: 適合率，再現率，自信度の平均．但し，括弧内は標準偏差である．3 つの条件は，GitHub 上のインタフェース（non-CG），
開発背景と理由の並べ替え機能がない CodeGlass（CG-），並べ替え機能を持つ CodeGlass（CG）である．
non-CG

CG-

CG

適合率

再現率

自信度

適合率

再現率

自信度

適合率

再現率

自信度

Execution

0.93 (0.09)

0.45 (0.18)

61.1 (10.7)

0.87 (0.13)

0.44 (0.23)

66.4 (11.7)

0.90 (0.11)

0.53 (0.24)

77.5 (10.9)

Rationale

0.86 (0.30)

0.17 (0.09)

63.7 (10.4)

0.95 (0.11)

0.31 (0.12)

63.4 (10.5)

0.89 (0.15)

0.34 (0.17)

66.8 (8.07)

History

0.08 (0.29)

0.01 (0.04)

30.7 (16.9)

0.50 (0.52)

0.14 (0.12)

58.9 (19.3)

0.33 (0.49)

0.12 (0.15)

63.7 (24.7)「オープンソースのコードを利用した自習（2 人）」が挙げ

表 2: 反復測定の一元配置分散分析の結果．
適合率

再現率

られた．特に複数人での開発を行う場面やオープンソース

自信度

p

η2

F

p

η2

F

p

η2

Execution

1.71 .20

0.06

0.47

.63

0.03

4.00

< .05

0.22

Rationale

0.73 .49

0.04

6.51 < .01

0.27

1.17

.33

0.06

History

2.71 .09

0.14

4.18 < .05

0.22

9.68 < .001

0.40

F

のプロジェクトにおいて，与えられたコードを理解するのに適しているという声が上げられた．
自分が使いたいと思うときっていうのは，やっぱり複
数人でやってるんだったら，自分が担当してない部分

7.2 実験結果
実験参加者らが作成したドキュメントの箇条書きのうち，事前に作成した解答に含まれる項目を正解数として数えた．そして，その正解数をもとに適合率と再現率を計算した．但し，ドキュメントに何も記されていなかった場合，適合率，再現率ともに 0 とした．表 1 に，適合率，再現率，自信度の平均と標準偏差を示す．実験結果を分析するために，システム（non-CG，CG-，CG）を要因とした反復測
定の一元配置分散分析（ANOVA）により，適合率，再現率，自信度を比較した（表 2）．その結果，Execution の自信
度，Rationale の再現率，History の再現率と自信度の計 4 つのコードを理解したいなー，って思うときにこれを．

[PC5]
全部どういうコードでこの人が書いたかっていうのが，今まではソースとかコメントしか読めなかったけども，プロジェクト自体がどうやって運んでいくかっていうのもちょっと引いた目で見るみたいなことがいろいろな教材も無限にあるし，っていうのでいいん
じゃないかなと． [PC7]8. プログラマによる定性的評価

において，3 条件間に有意性が認められた．ボンフェロー

さらに我々は，専門的なプログラマにとっての CodeGlass

ニ法による多重比較を行った結果，non-CG と CG-およびの有用性を調査するために，4 社の IT 企業から 8 人のプロ

non-CG と CG の間に有意差が認められたのは，Rationale

グラマ（PD1–PD8, 全て男性）を募り，インタビューによの再現率（ p < .05）と History の自信度（ p < .01）であっる CodeGlass の定性的評価を行った．

た．また，Execution の自信度において non-CG と CG の間

この定性的実験の参加者からも CodeGlass が有用になり（ p < .01），History の再現率において non-CG と CG-の間うる場面に関して複数の意見が得られた．具体的には，過（ p < .05）に有意差が認められた．

去のプルリクエストの参照が容易になる（8 人），開発チー

また実験後に行ったインタビューでは，CodeGlass がど

ムの新メンバーの教育に有用である（5 人），オープンソーのような開発場面で有用になりそうかを実験参加者に質スのコード理解に有用である（4 人），が挙げられたそれら問した．その結果，想定される利用場面として，「知らなに加えて，実験参加者らはプログラマの専門的な用途においコードの理解（7 人）」，
「バグ修正方法の理解（3 人）」，ける CodeGlass の利点を述べた．

© 2019 Information Processing Society of Japan

166

情報処理学会 インタラクション 2019
IPSJ Interaction 2019

隠れた開発背景の理解
実際のソフトウェア開発現場では，厳格な期日や実装力の不足などの様々な理由から，常に最善の実装方法が選択

INT19018
2019/3/6

9. 考察
9.1 ユーザ評価の結果に関する議論

されるとは限らない．しかし，完成されたソースコードでアルゴリズムの評価に関する考察は 6 章にて議論したたはそういった開発背景は隠れてしまう．実験参加者 2 名

め，ここではユーザ評価の結果について考察を行う．学生（PD3 と PD7）は，CodeGlass はソースコードの裏にある開による CodeGlass の定量的評価により，Rationale と History

発背景を理解することにおいて有用であると述べた．

に関する情報収集の再現率と，Execution と History に関す

新規で入ってコード見ると，だめなコードがたくさんあるんですよね．でも実はそれは特定の技術を使ってはいけないみたいな制約のもとの苦渋の決断だったこ
とってかなりあるんですよね．そういうのはコードをみても絶対に分からないし，かといって大規模だと履歴を追うのは相当つらい． [PD7]る情報収集の自信度に対して，CodeGlass の有意な効果が認められた．一方で，全ての情報の分類における適合率に対しては，CodeGlass の有意な効果は見つけられなかった．
この原因の一つとして，実験参加者らは確度の高い情報のみをドキュメントに記した可能性がある．

Execution の再現率，適合率に関しては有意な差が確認されなかった．これは使用したコードが比較的短いものであ

ソフトウェア開発プロジェクトでは通常仕様書が作成さり，プルリクエストに頼らずとも実装内容をある程度推察れるが，開発が進んでも仕様書が更新されない状況が多くできたためであると考えられる．一方，Rationale と History

発生する．CodeGlass は，古い情報からなる仕様書とソーの再現率は有意な差があり，CodeGlass の一定の効果を確

スコードの乖離を埋められる可能性が指摘された．

認するものである．

仕様書をもとにコードを作って，仕様書をもとにテス

また，実験結果における再現率が総じて低いことが確認

トするんですが，でもやっぱり経緯はわかんないし，された．この原因の一つとして，タスクに 20 分という時仕様書とコードの間のギャップって凄まじいんですよ

間制限を設けたことが挙げられる．時間制限により実験参ね．仕様書もコードも結果であって，開発理由とかは加者らは，理解するのが簡単な箇所からドキュメント作成

本当にわからない． [PD7]を行ったと考えられる．

8 人のプログラマを対象としたインタビューでは，Codeプルリクエストによるドキュメント作成

Glass 特有の有用性を明らかにすることができた．特に IT

ソフトウェア開発におけるドキュメントの重要性は広く企業といった専門的な組織における開発では，コードレ

認知されているが，実際の開発現場では，開発者はドキュビューを円滑に行うために GitHub のプルリクエストが日

メント作成に時間を割くことができていない [6]．実験参常的に利用されている．2 人の実験参加者（PD5 と PD8）

加者 2 名（PD5 と PD8）は，CodeGlass が将来参照する時

は，CodeGlass を開発組織に導入することで，プルリクエのために，プルリクエストの説明文を詳細に書く習慣をストの説明文をより詳細に書く習慣を作ることができる

CodeGlass が促す可能性があると述べた．

かもしれないと述べた．この利点は専門的な組織における

やっぱりなぜそのコードになったのかが重要で，プルリクは開発フローに既にあるし，それをもう少しちゃんと書いたらドキュメントになるってのはすごく新し

CodeGlass の新たな有用性を示唆しており，CodeGlass の
長期的システム評価を行うことで，コード断片の理解の支
援のみならず，ソフトウェア開発プロセスの改善における有効性が明らかになる可能性がある．

いし実用的ですね． [PD8]
コードレビューの支援
ソフトウェアの品質を担保する上でコードレビューは重要な仕事である．しかし，コードレビューを適切に行うためには，ソースコードとその開発背景に関する十分な理解が必要となる．3 人の実験参加者ら（PD1，PD3，PD6）は，

CodeGlass では過去のプルリクエストを簡単に参照できる
ため，コードレビューにおいても有用であると指摘した．

9.2 本研究の限界
ユーザ評価により CodeGlass の有用性を明らかにすることができた一方で，本研究にはさらなる改良を要する点が存在する．ソフトウェア開発においてプルリクエストが使用されていない，あるいは説明文が十分に書かれていない
場合，CodeGlass を有効活用することはできない．先行研
究ではコード変更の説明文を記述することを支援するシステムが実装されており [13]，CodeGlass と併用することで，レビューしていてコードの意図がわかんない時とか，

プルリクエストの使用や説明文の詳細な記述を促すことがかなり複雑なコードだった時に，プルリクに詳しく説できる可能性がある．

明があるかなあって感じだったので，今言ったような時に使うかなあと． [PD1]© 2019 Information Processing Society of Japan

CodeGlass は過去のプルリクエストを用いてコード断片に関連する情報を提供することができるが，ソースコード

167情報処理学会 インタラクション 2019
IPSJ Interaction 2019

全体の俯瞰的な理解の支援に関しては評価を行っていない．

INT19018
2019/3/6[6]

リポジトリのファイルやクラス構造の理解支援は本研究の目的とは外れるが，Chronicler [21] のようなソースコード
全体の理解を支援するシステムと併用することで，コード[7]

理解をより包括的に支援できる可能性がある．

CodeGlass は選択されたコード断片に関連するプルリク[8]

エストのみを提示するが，大規模なリポジトリにおいて

CodeGlass を使用した場合，多くのプルリクエストが表示[9]

されてしまう恐れがある．コード理解において有用でない
プルリクエスト（“Fix typos” や “Clean up indent” など）のフィルタリング機能などが今後の課題である．

[10]

CodeGlass はユーザが選択したコード断片に関連する情報のみを提供しており，コード断片を参照する関数といっ[11]た他のコード断片に関する情報提示は行っていない．例
えば構文解析を用いることで選択されたコード断片と強く関連する他のコード断片を特定できると考えられるが，CodeGlass の特徴であるプログラミング言語の非依存性が失われてしまう．選択されたコード断片に関する情報を完[12]全に抽出するためには，さらなる検証が必要である．

10. 結論本研究では，コード断片に関連する情報を提供する Code-[13]

Glass というシステムを開発した．CodeGlass はユーザが選択したコード断片に関連する過去のプルリクエストを抽[14]出し，ユーザに提供する．さらに，プルリクエストの説明文を解析し，実装内容や開発背景に関する文章をインター
フェース上で強調して表示することができる．情報系の学[15]

生およびプログラマを対象としたユーザ評価を行った結果，プルリクエストの説明文に含まれる情報が，コード断[16]

片を理解する上で有用であることが明らかとなった．
謝辞 本研究の一部は，科学研究費助成事業（若手研究[17]

18K18088）によって支援された．また，本研究の実験に参加してくださった全ての実験参加者に感謝する．
参考文献
[1]

[2]

[3]

[4]
[5]

Asaduzzaman, M., Roy, C. K., Schneider, K. A. and Penta,
M. D.: LHDiff: A Language-Independent Hybrid Approachfor Tracking Source Code Lines, 2013 IEEE International
Conference on Software Maintenance, pp. 230–239 (online),
DOI: 10.1109/ICSM.2013.34 (2013).
Bragdon, A., Zeleznik, R., Reiss, S. P., Karumuri, S., Cheung, W., Kaplan, J., Coleman, C., Adeputra, F. and LaViola,Jr., J. J.: Code Bubbles: A Working Set-based Interface for
Code Understanding and Maintenance, Proc. CHI ’10, pp.
2503–2512 (2010).
Buckner, J., Buchta, J., Petrenko, M. and Rajlich, V.: JRipples: a tool for program comprehension during incremental
change, Proc. IWPC ’05, pp. 149–152 (2005).
Buse, R. P. and Weimer, W. R.: Automatically Documenting
Program Changes, Proc. ASE ’10, pp. 33–42 (2010).
D’Ambros, M., Lanza, M. and Robbes, R.: Commit 2.0,
Proc. Web2SE ’10, pp. 14–19 (2010).

© 2019 Information Processing Society of Japan

[18]
[19]

[20]

[21]

[22]

de Souza, S. C. B., Anquetil, N. and de Oliveira, K. M.: A
Study of the Documentation Essential to Software Maintenance, Proc. SIGDOC ’05, New York, NY, USA, pp. 68–75(2005).
Dekel, U. and Herbsleb, J. D.: Improving API Documentation Usability with Knowledge Pushing, Proc. ICSE ’09, pp.
320–330 (2009).
Kagdi, H., Hammad, M. and Maletic, J. I.: Who can help mewith this source code change?, Proc. ICSM ’08, pp. 157–166(2008).
Ko, A. J., DeLine, R. and Venolia, G.: Information Needs
in Collocated Software Development Teams, Proc. ICSE ’07,
pp. 344–353 (2007).
Ko, A. J., Myers, B. A. and Aung, H. H.: Six Learning Barriers in End-User Programming Systems, Proc. VLHCC ’04,
pp. 199–206 (2004).
Le, Q. and Mikolov, T.: Distributed Representations of Sentences and Documents, Proceedings of the 31st International
Conference on Machine Learning (Xing, E. P. and Jebara, T.,eds.), Proceedings of Machine Learning Research, Vol. 32,
No. 2, Bejing, China, PMLR, pp. 1188–1196 (online),available from ⟨http://proceedings.mlr.press/v32/le14.html⟩(2014).
Lilleberg, J., Zhu, Y. and Zhang, Y.: Support vector machines
and Word2vec for text classification with semantic features,2015 IEEE 14th International Conference on Cognitive Informatics Cognitive Computing (ICCI*CC), pp. 136–140 (online), DOI: 10.1109/ICCI-CC.2015.7259377 (2015).
Linares-Vásquez, M., Cortés-Coy, L. F., Aponte, J. andPoshyvanyk, D.: ChangeScribe: A Tool for Automatically
Generating Commit Messages, Proc. ICSE ’15, Vol. 2, pp.
709–712 (2015).
McBurney, P. W. and McMillan, C.: Automatic Documentation Generation via Source Code Summarization of Method
Context, Proc. ICPC ’14, pp. 279–290 (2014).
Sankoff, D. and Kruskal, J. B.: Time warps, string edits, andmacromolecules, The Theory and Practice of Sequence Comparison, Reading (1983).
Sridhara, G., Pollock, L. and Vijay-Shanker, K.: Automatically Detecting and Describing High Level Actions Within
Methods, Proc. ICSE ’11, pp. 101–110 (2011).
Stylos, J., Faulring, A., Yang, Z. and Myers, B. A.: Improving API documentation using API usage information, Proc.
VL/HCC ’09, pp. 119–126 (2009).
Subramanian, S., Inozemtseva, L. and Holmes, R.: Live API
Documentation, Proc. ICSE ’14, pp. 643–652 (2014).
Tao, Y., Dang, Y., Xie, T., Zhang, D. and Kim, S.: How
Do Software Engineers Understand Code Changes?: An Exploratory Study in Industry, Proc. FSE ’12, pp. 51:1–51:11(2012).
Treude, C. and Robillard, M. P.: Augmenting API Documentation with Insights from Stack Overflow, Proc. ICSE ’16, pp.
392–403 (2016).
Wittenhagen, M., Cherek, C. and Borchers, J.: Chronicler:
Interactive Exploration of Source Code History, Proc. CHI’16, pp. 3522–3532 (2016).
Zhang, T., Song, M., Pinedo, J. and Kim, M.: Interactive
Code Review for Systematic Changes, Proc. ICSE ’15, Vol.
1, pp. 111–122 (2015).

168