社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

ソースコードコメントに着目した
技術負債に対する修正の類似性の調査
岡島

早紀†

神田

哲也†

井上

克郎†

† 大阪大学大学院情報科学研究科〒565-0871 大阪府吹田市山田丘 1-5
E-mail: †{s-okajim,t-kanda,inoue}@ist.osaka-u.ac.jp
あらまし ソフトウェアの開発工程において，開発者はさまざまな理由で最適ではないコードを記述することがある．
こういった一時的な解決策が原因となり長期的にみたソースコードの品質が低下することを技術負債という．技術負債の中でも特に開発者が意図的に導入し，自然言語を使用してソースコードコメントにその存在が記述されているものを自認された技術負債 (SATD) という．SATD はそれ自身が欠陥の原因になり得るだけでなく将来的にソフトウェ
アの保守性の低下を引き起こすため，リファクタリングによって除去されることが望ましい．しかし SATD の多くは除去の優先度が低く，実際に除去される SATD は一部のみであり，SATD は長い間放置される傾向にあることがわ
かっている．そこで本研究では，SATD に対する修正支援を目指し，SATD コメントが示す内容と SATD へと加えられる修正の類似性を調査した．調査の結果，SATD に加えられる修正の類似度は SATD コメントの量とコメントルー
ルに大きく影響されることが確認された．また調査結果からデータベースを構築し，修正支援ツールの試作を行った．
キーワード SATD，ソースコード，修正支援

A Study on Similarity of Modifications to Technical Debt Focusing on Source
Code Comments
Saki OKAJIMA† , Tetsuya KANDA† , and Katsuro INOUE†† Software Engineering Laboratory, Department of Computer Science Graduate School of Information
Science and Technology, Osaka University
1-5, Yamadaoka, Suita, Osaka, 565-0871
E-mail: †{s-okajim,t-kanda,inoue}@ist.osaka-u.ac.jp

1. ま え が きされるコード行数やファイル構造数が多く，SATD を含むファイルに対する変更はより複雑であるという結果を得た．これ

ソフトウェアの開発工程において，開発者はさまざまな理由

は SATD はそれ自身が欠陥の原因になり得るだけでなく将来で最適ではないコードを記述することがある．こういった一時的にソフトウェアの保守性の低下を引き起こすことを示してお的な修正が原因となり長期的に見たソースコードの品質が低下

り，SATD はリファクタリングによって除去されることが望ますることを技術負債という [1]．技術負債は発見や対処が容易

しいが，Potdar らの研究によると実際に除去される SATD はでないことからソフトウェアの保守や全体の品質に悪影響を及26.3% から 63.5% のみである [3]．また Gabriele らの研究でぼすため開発プロセスでその存在を特定し管理する必要がある

は，SATD が導入されてから除去されるまでに平均して 1,000

ことが分かっている [2]．

以上のコミットがされることから，SATD は長い間放置される

技術負債の中でも特に開発者自身が技術負債の導入時にその傾向にあることがわかっている [5]．SATD が除去されず長い存在に気付いていて，かつその存在を自然言語を使用してソー間放置される理由として，他の技術負債と比較した優先度の低スコードコメントに記述しているものを SATD(Self-Admitted

さが考えられる．SATD に最も多く見られるのは設計に関するTechnical Debt) という [3]．Wehabi らの調査 [4] では，SATD

ものである [6]．設計に関する SATD とは複雑なメソッドや一を含むファイルは SATD を含まないファイルと比較して変更

時的な回避策を指し，これらはソフトウェアの動作には直接関—1—係しないため他の SATD と比較して除去の優先度が低くなっていることが予想できる．

表 1 SATD コメントの例
プロジェクト名

SATD コメントの例

前述の通り，SATD はソフトウェアの保守性の低下を引き

camel//TODO is this needed

起こすため取り除かれるのが望ましいが，プロジェクトによっ

gerrit//Not exact but we cannot do any betterては導入された SATD のうち過半数は除去されずに長い期間

hadoop//TODO fix this

放置されているのが現実である．そこで SATD への修正支援

log4j//This feels like a hack and it does not work

tomcat//FIXME Add flags if possible

ツールとして，ソースコードのファイル構造を街のように可視化し，除去するべき SATD を目立たせて表示することでユーザに除去を促す環境が提案されている [7]．しかし実際に SATDを表すコメントを SATD コメントとする．実際にソースコーを解消するには，具体的にどのような修正が必要かの情報が求ド中に現れた SATD コメントの例を表 1 に示す．

められる．さらに，SATD の迅速な解消を目指すには，SATD

Wehabi らの研究 [4] では SATD を含むファイルと SATD

コメントがソースコードに追加された時点で修正案を提示するを含まないファイルにおける変更の複雑さを比較することで，必要がある．

SATD がプロジェクトの品質に与える影響を調査している．5

そこで本研究では，修正支援を目的に SATD コメントが示

つのオープンソースプロジェクトに対して調査を行い，SATDす内容と SATD へと加えられる修正の類似性を調査し，修正を含まないファイルと比較して SATD を含むファイルの方が支援ツールの試作を行った．具体的には，調査対象となるプロ変更されたコード行数やファイル構造数が多く，変更が複雑でジェクトの過去のすべての編集内容をトレースし，SATD コメあるという結果を得た．このように SATD はそれ自身が欠陥

ントの削除に伴ってなされたコードの編集内容とコメント内容の原因になり得るだけでなく将来的にソフトウェアの保守性のを記憶した．つぎに SATD コメントをベクトル化したのち，ク低下を引き起こすため，リファクタリングによって除去される

ラスタリング手法のひとつである K-means 法を用いてクラスことが望ましい．

タリングを行った．最後に SATD コメントの内容をもとに分SATD はその定義からあくまでも一時的に導入されたもの

けられたそれぞれのクラスタにおいてコードの編集内容の類似であり，将来的に取り除かれることを想定しているが，Potdar性の調査を行った．類似性の調査にはコードの編集内容をトーらの調査によれば SATD は全ソースコードファイルのうちクン化したものの組に対して局所アラインメントのスコアを算

2.4% から 31.0% に含まれており，そのうち実際に除去され出し，スコアが閾値 α を超えるものを修正が類似すると定義

る SATD は 26.3% から 63.5% のみであることが分かっていして，各プロジェクトの SATD に対する修正の類似性を調査

る [3]．Gabriele らの 159 のオープンソースソフトウェアに対した．

する調査 [5] では，プロジェクト内に含まれる SATD は平均

2. 背

景

して 51 個であり，プロジェクトの規模が大きくなるにつれて

SATD の数も増加するとされている．また SATD が導入され

本節では今回の研究の基となる関連研究について説明する．

てから除去されるまでに平均して 1,000 以上のコミットがされ

2. 1 節では技術負債，2. 2 節では自認された技術負債，2. 3 節でることから，SATD は長い間放置される傾向にあることがわかは SATD の検出手法について説明する．

る．SATD が放置される原因として考えられているのが他の技

2. 1 技 術 負 債

術負債と比較した優先度の低さである．Potdar らの調査ではソフトウェアの開発工程において，予算の減少やスケジュー

SATD を 5 つの種類に分類したところ，最も割合が高いのは設

ルの短縮，顧客の要求等に応えるために開発者は一時的な解決計に関する負債であり，これは SATD 全体の 42% から 84%を図ることがある．こういった最適ではない解決策を負債とみを占めていることがわかった [6]．ここでいう設計に関する負なし，負債により長期的に見たソースコードの品質が低下する

債とは，具体的には不十分な抽象化，長すぎるメソッド，一時ことを技術負債という [1]．技術負債には不十分なテスト，コ

的な回避策や不十分な実装などを指し，これらはソフトウェア

ンパイラの警告などさまざまな種類のものが存在するが，ここの動作には直接関係しないため他の SATD と比較して除去のでは特にソースコード中にみられる負債について述べる．既存

優先度が低くなっている．

研究では，技術負債はソフトウェアの品質や保守において悪影

2. 3 SATD の検出手法

響を及ぼす可能性があるため，開発プロセスでその存在を特定

SATD は負債を導入した開発者自身によってソースコードコ

し管理する必要があることが分かっている [2]．技術負債を特メントに文書化される特性から，ソースコードコメントを通じ定する手法としては，ソースコードメトリクスやコードスメル

た検出が可能である．Potdar らは Eclipse，Chromium OS，等を用いたソースコード分析 [8] [9] が使用される．

Apache HTTP サーバー，ArgoUML の 4 つのプロジェクトに

2. 2 自認された技術負債含まれる 101,762 のコメントを手作業で解読することで SATD

自認された技術負債 ( Self-Admitted Technical Debt : SATDの検出を行い， SATD コメントに多用される 63 の単語・フ) とは，Potdar らによって提案された概念であり，技術負債のレーズを発見した [3]．ほかにもソースコードコメントを利用中でも特に開発者が意図的に導入し，ソースコードコメントをした SATD の検出手法としてこれまでに正規表現を用いたも使用してその存在が文書化されているものを指す [3]．SATDの [10]，自然言語処理 (NLP) を用いたもの [5]，テキストマ—2—

イニングを用いたもの [11] などが存在している．2. 1 節で述除された

べたソースコードメトリクスやコードスメルによって検出され（ 2 ） ソースコード部分に変更はなく，SATD コメントが削る技術負債は高い誤検出率の影響を受ける可能性があるのに比除された

べて，ソースコードコメントを通して検出される技術負債は開（ 3 ） ソースコード部分に変更があり，SATD コメントが削発者が自ら負債と認めている特性から信頼度が高いとされてい除された

る [12] [5]．

(1) のケースと (2) のケースはいずれも偶発的に起こった SATD

3. 調 査 手 法
3. 章では，SATD を指すコメントの内容と，実際にその SATD
に対して加えられた修正の類似性の調査手法を述べる．今回は調査対象のプログラム言語を Java に限定している．調査にあコメントの除去であり，SATD の本質的な除去とはいえない．

SATD の本質的な除去を特定するためには，(3) のケースのコ
ミットのみを調査対象とする必要がある．

3. 2 SATD コメントが指すコード範囲の特定
SATD に対する修正の類似性を求めるためには， SATD コ

たって，以下の手順で必要なデータを得た．

メントが指す SATD の範囲を特定する必要がある．今回の調査（ 1 ） SATD が削除されたコミットの特定では SATD コメントの削除と同時に削除された箇所を SATD

（ 2 ） SATD コメントが指すコード範囲の特定

コメントが指すコード範囲，SATD コメントの削除と同時に編（ 3 ） SATD に対する修正の類似度の算出

集された箇所を SATD に対する修正範囲とする．

3. 1 SATD が削除されたコミットの特定

3. 3 SATD に対する修正の類似度の算出

3. 1 節では，SATD コメントとその SATD に対して加えら

最後に， SATD コメントの内容と SATD に対して行われる

れた修正の類似性を調査するため，プロジェクトの各コミット

修正の類似性を調査する．手順としては， SATD コメントをからソースコードコメントの削除を抽出し，ソースコードコメ

コメント内容から分類したのち，各クラスタ内におけるコード

ントを通じて SATD を特定する手法について述べる．具体的の修正内容の類似度を求める．コードの修正内容の類似度の算には，

出には局所アラインメントのスコアを使用しており，トークン（ 1 ） コメントが削除されたコミットの特定列に変換したソースコードのアラインメントスコアが閾値 α（ 2 ） SATD コメントの識別を超える場合に修正が類似とする．

（ 3 ） SATD が削除されたコミットの特定

3. 3. 1 SATD コメントのクラスタリングの 3 つの工程で実現する．

SATD コメントの内容をベクトル化し，クラスタリングを

3. 1. 1 コメントが削除されたコミットの特定行う．コメントのベクトル化手法には Doc2Vec を用いていまずはじめにソースコードコメントが削除されたコミットのる．Doc2Vec は gensim [14] ライブラリを使用して Python

特定を行う．今回はバージョン管理システムの Git を使用してで実装した．クラスタリングには X-means 法 [15] を用いた．

いる．調査対象を Java で記述されたコードに限定しているの

X-means 法とは教師なし学習である K-means 法の拡張アルゴ

で，プロジェクトのすべてのコミットを対象に git show コマ

リズムで，クラスタ数 K を自動決定するものである．X-means

ンドを実行し， Java ファイルの変更箇所を確認する．コメン

法によるクラスタリングは PyClustering [16] ライブラリにトの除去があったコミットのハッシュ値とコメントの内容を記よって実装している．このとき， SATD を表現するコメント

憶する．複数行にまたがるコメントは 1 つのコメントとして処に頻出する単語はクラスタリングにおいて重要な役割を果たさ理する．また，SATD と無関係なコメントを除くために，以下ないため，無視している．

のコメントは対象としない．

3. 3. 2 分類した SATD に対する修正の類似性の調査上で得たクラスタ内での修正の類似性を調査する．具体的に•自動的に生成されたコメント•

コメントアウトされたソースコードの断片

は，修正箇所のトークンを文字列に変換し，クラスタ内での任•ライセンスコメント

意の 2 トークン間での局所アラインメントスコアを求める．

3. 1. 2 SATD コメントの識別a ) 修正箇所のコードのトークン化

2. 2 節で記述した通り，SATD は SATD コメントを通じてそ

修正内容の比較を行うために，修正箇所のコードのトークンの存在箇所を特定することができる．今回は Huang らによる化，文字列への変換を行う．この作業は修正によって削除されテキストマイニングを用いた SATD コメント識別手法 [11] をたコード部と挿入されたコード部に分けて行う．修正箇所の使用した．Huang らの検出ツールでは，入力として受け取った

コードの文字列への変換は以下の手順で行う．

テキストのラベル (w/SATD or w/ SATD) を出力する．

（ 1 ） コメントを削除したコード片に対して字句解析を行う

3. 1. 3 SATD が削除されたコミットの特定（ 2 ） ユーザ定義の変数や関数等はすべて同一トークンとみここまでで SATD コメントが削除されたコミットの特定をなす行った．しかし，SATD コメントが削除されることと SATD が（ 3 ） 字句解析によって得たトークンをそれぞれ一文字に変削除されることは同義ではない [4], [13]．SATD コメントが削換する

除された場合，以下の 3 つのケースに分類することができる．

（ 4 ） 空白・改行を削除して文字列を得る（ 1 ） メソッド/クラスの削除に伴って SATD コメントも削

コードのトークン化の例を図 1，図 2，図 3，図 4 に示す．

—3—

StringBuffer buf = new StringBuffer();for(int i = 0; i < token.length; i++){buf.append(token[i]);}M × M の表 H_ del(N, N )，H_ ins(N, N ) を用意し，以下に従って表を埋める．

{
if score_ del(i, j) > α then 1

H_ del(i, j) =else 0{

図 1 コメントを削除し字句解析を行う

H_ ins(i, j) =0
0 = new
for(int 0 = 0; 0 <
0 .
0 . 0
( 0 [0]);
}

0
0

();
; 0++){

if score_ ins(i, j) > α then 1
else 0

つぎに，H(i, j) = H_ del(i, j) and H_ ins(i, j) となる表H を用意する．ここで H(i, j) = 1 のとき，m(i) と m(j) は削除行と挿入行のそれぞれが類似することを意味している．

H(i, j) = 1 となる m(i) と m(j) を類似する修正とする．
図 2 識別子や定数をすべて同一トークンとみなす

0
2 ( 3
0 .

0 = 1
0 = 0; 0 <0 .
0( 0 [0]);00

最後に，i ∈ (0, 1, ..., N − 1) に対して以下の計算を行う．

}

∑

N −1

();
; 0++){

common(i) =H(i, j)j=0

これは同一クラスタ内に m(i) と類似する修正が common(i)個含まれることを意味する．common(i) が最大となるような
図 3 字句解析によって得たトークンを文字に変換i を i_ max とするとき，m(i_ max) をクラスタを代表する修正とし，

00=10();2(30=0;0<0.0;0++){0.0(0[0]);}

図 4 空白・改行を削除して文字列を得る

b ) 局所アラインメント
修正の類似性の調査には局所アラインメント [17] を用いる．
局所アラインメントとは， 2 つの文字列間の類似する部分を求めるアルゴリズムである．2 つの文字列を比較し，文字の挿入のあった部分に - （ギャップ）を入れることで文字列の対応する位置を合わせる．この結果得られる文字列のことをアライン
メントという．一般に，2 つの文字列から構成可能なアライン
メントは複数存在する．そこで得られたアラインメントを評価するために局所アラインメントのスコアを導入する．局所アラインメントのスコア score は以下の式から導出される．

score = match − mismatch − gap
上記では，match は位置が一致する文字の数，mismatch は一致しない文字の数，gap は挿入した “-” の数である．アライン

common(i_ max)Nをクラスタ C における修正の類似度とする．
similarity(C) =4. 調 査 実 験
SATD コメントを通じた修正支援を実現するためには，SATD
コメントの内容と SATD への修正内容に類似性を見つけ出す必要がある．4. 章では，3. 章で述べた手法を実際にオープン
ソースプロジェクトに適用し，SATD コメントの内容と SATDへの修正内容にどの程度類似性がみられるかを調査する．
実験対象
今回の調査は Camel，Gerrit，Hadoop，Log4j，Tomcat の

5 つの Java オープンソースプロジェクトを対象に行っている．
それぞれアプリケーションドメインや規模，コントリビュー
タの数が異なるもので，開発が活発に行われていること，十分な量のコメントが含まれていることを条件に，Maldonad らによって選定されたものである [10]．実験対象のプロジェクト
名，Java ファイル数，総リビジョン数，総コード行数，コント
リビュータ数を表 2 に示す．
表 2 調査対象プロジェクトの規模メント間での文字の一致が多いほどスコアは高くなり，文字の削除・挿入が多いほどスコアは低くなる．局所アラインメント

プロジェクト名Java ファイル数

総リビジョン数

KLOC

コントリビュータ数のスコアの算出には Smith-Waterman アルゴリズム [18] を用

camel

17,46346,005

1,830

647

いた．

gerrit2,793

36,093380368c ) 修正の類似度の算出

hadoop11,31457,2422,560

273

修正の類似度はクラスタごとに算出する．あるクラスタ

log4j

1,894

11,007243

86

tomcat2,404

20,420570

39

C = ⟨m0 , m1 , . . . , mN −1 ⟩ における任意の修正 m(i)，m(j) をそれぞれ削除行と挿入行に分割し，削除行ごと，挿入行ごとに局
所アラインメントのスコアを算出する．ここで m(i)，m(j) 間の削除行の局所アラインメントのスコアを score_ del(i, j)，挿
入行の局所アラインメントのスコアを score_ ins(i, j) とする．

4. 1 SATD に対する修正の類似度の算出
3. 1 節で得た SATD コメントに対してクラスタリングを行い，クラスタごとに修正の類似度を求める．クラスタに含まれ—4—

表 3 SATD に対する修正の類似性
プロジェクト名

SATD コメント数

クラスタの修正の類似度の平均

camel

263

0.53

gerrit65

0.40

hadoop

941

0.89

log4j

37

0.77

tomcat

915

0.72

表4

SATD コメント

263

クラスタを
代表する修正有効なクラスタに分類されるコメントの割合が極端に低くなっ有効なクラスタの割合
コメントの割合

camel

データベースたことが原因である．Log4j は有効なクラスタの割合に対して有効なクラスタの割合

SATD コメント数

クラスタ ID

図 5 修正支援の処理概要

有効なクラスタに分類される
プロジェクト名

クラスタリング

0.16

0.12

ている．これはそもそもの SATD コメント数が少ないことが原因で，コメントに類似性が見られなかった多数の修正がひとつのクラスタに分類されているためである．

gerrit

65

0.00

0.00

hadoop

941

0.78

0.40

コメント内容によってクラスタリングされた修正内容を修正

log4j

37

0.75

0.10

支援に使用するには，有効なクラスタの割合と有効なクラスタ

tomcat

915

0.48

0.16

に分類されるコメントの割合が高いものが有用である．よって今回の調査対象のプロジェクトの中では Hadoop のデータが修る全修正を削除行と挿入行に分割し，任意の 2 修正間で削除行
ごと，挿入行ごとに局所アラインメントのスコアを求める．削除行の局所アラインメントスコアと挿入行の局所アラインメン

正支援に最も有用である

5. 修正支援ツールの試作

トスコアがともに閾値 α を超えるような修正の組を類似する修．最後に SATD コメントの内容と SATD への修正の類似正とする．類似する修正が最も多くなるような修正をクラスタ性を利用した修正支援ツールの試作を行った．本章ではデータを代表する修正とし，クラスタを代表する修正に類似する修正ベースの構築方法とケーススタディを記す．

の数をクラスタ内の全修正の数で割ったものをクラスタ内の修

5. 1 データベースの構築

正の類似度として求めた．また，修正支援への応用の可不可を

4. 章で得たクラスタをデータベースの構築に使用する．具

判断するために，修正の類似度 > β となるクラスタを有効なク

体的には，クラスタ内で最も多く見られたコードの修正内容をラスタとし，全クラスタ数に占める有効なクラスタの割合と有クラスタを代表する修正とし，クラスタの ID とクラスタを代効なクラスタに分類されるコメントの割合を求めた．

表する修正の内容をキーとしてデータベースの構築を行った．

比較する 2 つのトークン列のうち長い方の長さを L とするとデータベースの構築には GNU Database Manager を用いた．

き，閾値 α を以下のように設定した．

また言語は Python を使用している．実際の修正支援では，追{加された SATD コメントを入力として受け取り，クラスタリα=

L × 0.6 (L < 30 のとき)
18 (L ≥ 30 のとき)

調査対象のすべてのプロジェクトに対して各クラスタの修正のングを行い，該当クラスタを代表する修正を出力することを想定している．修正支援の処理概要を図 5 に示す．

5. 2 ケーススタディ

類似度を求めた．得られた修正の類似度の平均と SATD コメ

ここでは試作した修正支援ツールの実行例を記す．データ

ント数の関係を表 3 に示す．表 3 から，一般に SATD コメン

ベースの構築には全体の SATD コメントのうち 90% を使用

トが多いほど各クラスタ内における修正の類似度は高くなるこ

し，残り 10% をケーススタディに用いた．

とがわかる．

Hadoop のある SATD コメントを入力として修正支援ツー

修正支援への応用の可不可を判断するために，各プロジェク

ルを実行した例を図 6 に示す．修正支援ツールを実行すると，

トにおいて全クラスタ数に占める有効なクラスタの割合と有効

該当プロジェクト名のウィンドウが立ち上がり，入力として渡なクラスタに分類されるコメントの割合を求めた．ここで，有した SATD コメントと SATD コメントの周辺コード，デー

効なクラスタの閾値 β = 0.8 としている．得られた結果を表 4

タベースから得られたクラスタを代表する修正内容が表示されに示す．

る．図 6 から，入力 として与えた SATD コメントの周辺に実Camel や Gerrit のように有効なクラスタの割合が低い場合，複数の種類の修正が含まれるクラスタが多いことを意味している．Hadoop は SATD コメント数が多いことが要因となって際に加えられた修正と出力として得られた該当クラスタを代表する修正が類似していることがわかる．

6. ま と め

有効なクラスタの割合と有効なクラスタに分類されるコメン
トの割合が高くなっているが，同様に SATD コメントが多い

5 つの Java オープンソースプロジェクトに対して， SATD

Tomcat の値はあまり高くない．これは Tomcat に記述されてコメントの内容と実際に SATD に加えられた修正の類似性をいる SATD コメントが “TODO” や “FIXME” の単語のみの調査した．

ものが多く，コメントのクラスタリングがうまく行われなかっ調査実験では，一般的に SATD コメントが多いほどクラス—5—

図 6 修正支援ツールの実行例

タ内の修正の類似性が高くなることがわかった.SATD コメン
ト数が多くても有効なクラスタに分類されるコメントの割合が低いプロジェクトも存在する. これは SATD コメントが詳細に記述されていないことが原因であり，有効なクラスタに分類されるコメントの割合は，SATD コメントの数だけでなくコメントルールが大きく影響することがわかった. 有効なクラスタの 割合に対して有効なクラスタに分類されるコメントの割合が極端に低くなっている. これは そもそもの SATD コメント
数が少ないことが原因で，コメントに類似性が見られなかった多数の修正がひとつのクラスタに分類されているためである.
修正支援ツールの試作では，調査実験での結果から得た修正支援に有用と判断された Hadoop のクラスタを用いてデー
タベースを構築した．全 SATD コメントのうち 90% をデータベースの構築に使用し，残りの 10% をケーススタディに使用した．実際に Hadoop プロジェクトのある SATD コメントを入力として与えたところ，入力 として与えた SATD コメントの周辺に実際に加えられた修正と出力として得られた該当クラ
スタを代表する修正が類似していること確認できた．
今回は調査対象を Java で記述されたものに限っているが，技術的負債の特定にソースコードコメントを使用しているため，
自然言語でコメントを記述できる言語には今回の手法を応用できる．
また今回はオープンソースプロジェクトのみを調査対象として扱っている．そのため，コメントルールが厳格に定められている企業が開発したプロジェクトなどに関しては，今回の調査
結果と異なる結果になる可能性がある．
文

献[1] N. Brown, Y. Cai, Y. Guo, R. Kazman, M. Kim, P.
Kruchten, E. Lim, A. MacCormack, R. Nord, I. Ozkaya,
R. Sangwan, C. Seaman, K. Sullivan, and N. Zazworka,“Managing technical debt in software-reliant systems,” Proceedings of the FSE/SDP Workshop on Future of Software
Engineering Research (FoSER ’10), pp.47–52, 2010.
[2] Z. Li, P. Avgeriou, and P. Liang, “A systematic mapping
study on technical debt and its management,” J. Syst.
Softw., vol.101, no.C, pp.193–220, March 2015.

[3] A. Potdar and E. Shihab, “An exploratory study on selfadmitted technical debt,” Proceedings of the 30th International Conference on Software Maintenance and Evolution(ICSME2014), pp.91–100, 2014.
[4] S. Wehaibi, E. Shihab, and L. Guerrouj, “Examining
the impact of self-admitted technical debt on software
quality,” Proceedings of the 23rd International Conference on Software Analysis, Evolution, and Reengineering(SANER2016), pp.179–188, March 2016.
[5] G. Bavota and B. Russo, “A large-scale empirical study
on self-admitted technical debt,” Proceedings of the 13th
International Conference on Mining Software Repositories(MSR2016), pp.315–326, ACM, New York, NY, USA, 2016.
[6] E.d. Maldonado and E. Shihab, “Detecting and quantifying
diﬀerent types of self-admitted technical debt,” Proceedingsof the 7th International Workshop on Managing Technical
Debt (MTD2015), pp.9–15, Oct. 2015.
[7] 一ノ瀬智浩，畑 秀明，松本健一，“ソースコード上の技術的負債除去を活性化させるゲーミフィケーション環境の開発，” 2016 年
度 情報処理学会関西支部 支部大会 講演論文集，pp.1–4，2016．
[8] R. Marinescu, “Detection strategies: metrics-based rules for
detecting design flaws,” Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM2004),
pp.350–359, 2004.
[9] N. Zazworka, R.O. Spínola, A. Vetro’, F. Shull, and C.
Seaman, “A case study on eﬀectively identifying technical debt,” Proceedings of the 17th International Conference on Evaluation and Assessment in Software Engineering(EASE2013), pp.42–47, 2013.
[10] E.D. Maldonado, R. Abdalkareem, E. Shihab, and A. Serebrenik, “An empirical study on the removal of self-admitted
technical debt,” Proceedings of the 33rd International Conference on Software Maintenance and Evolution (ICSME
2017), pp.238–248, Sept. 2017.
[11] Q. Huang, E. Shihab, X. Xia, D. Lo, and S. Li, “Identifying
self-admitted technical debt in open source projects using
text mining,” Empirical Softw. Engg., vol.23, no.1, pp.418–
451, Feb. 2018.
[12] F.A. Fontana, J. Dietrich, B. Walter, A. Yamashita, and M.
Zanoni, “Antipattern and code smell false positives: Preliminary conceptualization and classification,” Proceedingsof the 23rd International Conference on Software Analysis,
Evolution, and Reengineering (SANER 2016), pp.609–613,
March 2016.
[13] F. Zampetti, A. Serebrenik, and M. Di Penta, “Was selfadmitted technical debt removal a real removal?: An indepth perspective,” Proceedings of the 15th International
Conference on Mining Software Repositories (MSR2018),
pp.526–536, 2018.
[14] R. Řehůřek and P. Sojka, “Software Framework for Topic
Modelling with Large Corpora,” Proceedings of the LREC2010 Workshop on New Challenges for NLP Frameworks,
pp.45–50, May 2010.
[15] D. Pelleg and A. Moore, “X-means: Extending k-means
with eﬃcient estimation of the number of clusters,” In Proceedings of the 17th International Conference on Machine
Learning, pp.727–734, June 2000.
[16] A. Novikov, “annoviko/pyclustering: pyclustering 0.8.2 release,” Nov. 2018. https://doi.org/10.5281/zenodo.1491324[17] D. Gusfield, Algorithms on Strings, Trees, and Sequences:
Computer Science and Computational Biology, Cambridge
University Press, New York, NY, USA, 1997.
[18] T.F. Smith and M.S. Waterman, “Identification of common molecular subsequences.,” Journal of molecular biology, vol.147, no.1, pp.195–197, March 1981.

—6—