情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)

コードクローンのリファクタリング可能性に基づいた
削減可能ソースコード量の分析
石津 卓也1,a)

吉田 則裕2崔 恩瀞3

井上 克郎1

受付日 2018年7月31日, 採録日 2019年1月15日

概要：コードクローンはソフトウェア保守を困難にさせる要因の 1 つといわれている．また，コードク
ローンのリファクタリングとは，外部的な振舞いを保ちながら，コードクローンを削減するプロセスであり，ソフトウェア保守性を上げる可能性がある．企業が請負うソフトウェアの保守性向上をサービスとして，ソースコードのリファクタリングが検討されることがある．しかし，コードクローンのリファクタリ
ングによる削減できる開発のコストを見積もる際，複数の課題が発生する可能性があるため，その見積もりが難しくなることがある．そこで，本研究では，リファクタリングの見積もりに関する課題を解決して，
コードクローンをリファクタリングしたと仮定したときの削減可能ソースコード量を推定する手法を提案する．また，7 つのオープンソースソフトウェア（OSS）に対して削減可能ソースコード量を推定し，コー
ドクローンの行数と比較して平均 6.9%であることが分かった．
キーワード：コードクローン，リファクタリング可能性，削減可能ソースコード量，オープンソースソフ
トウェア

Analyzing the Amount of Reducible Source Code
Based on the Refactorability of Software Clones
Takuya Ishizu1,a)Norihiro Yoshida2

Eunjong Choi3

Katsuro Inoue1

Received: July 31, 2018, Accepted: January 15, 2019

Abstract: Code clone makes software maintenance more diﬃcult. Refactoring of code clones is one process of
reducing code clones while maintaining external behavior. It is able to increase the software maintainability.
When a company which is commissioned to maintain software has to estimate the cost and beneﬁt of refactoring source code owned by a customer. They have trouble preparing their estimates because of refactoringcode clones that have several problems is diﬃcult. We proposed a solution to each problem and applied amethod to investigate “the amount of reducible source code” for seven open source software products. As aresult of the investigation, we found that approximately 6.9% of the detected code clones could be reduced.
Keywords: code clone, refactorable, the amount of reducible source code, open source software

1. まえがき
ソフトウェア保守を困難にさせる問題の 1 つとして，コー

ドクローンの存在があげられる [6]．コードクローンとは，
ソースコード中に存在する互いに一致または類似した部分を持つコード片のことである [9]．既存のコード片をコピー
アンドぺーストによって再利用することがコードクローン

1
2
3

a)

大阪大学
Osaka University, Suita, Osaka 565–0871, Japan
名古屋大学
Nagoya University, Nagoya, Aichi 464–8601, Japan
奈良先端科学技術大学院大学
Nara Institute of Science and Technology, Ikoma, Nara 630–
0192, Japant-ishizu@ist.osaka-u.ac.jp

c 2019 Information Processing Society of Japan

の主要な発生原因として知られている．コードクローンはソフトウェア保守を困難にさせる要因の 1 つといわれている [9]．たとえば，開発者が一部のコードクローンに変更を行った場合，変更されなかったコードクローンはそれ以降では望まれない動作を行う可能性をプログラム内に残す

1051

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)ことになる．そのため，潜在的なバグを生み出しにくいプ

そこで，本研究では，コードクローンのリファクタリン

ログラム構造を実現するために，コードクローンを削減さ

グによる削減可能ソースコード量を見積もるための手法せる必要がある [5]．また，コードクローンを削減するたを提案する．本手法は次のとおり問題を (1) と (2) を解決めの研究が多く提案されてきた [1], [2], [3], [15], [16], [18]．

した．

コードクローンの削減する代表的な方法としてコードク
ローンのリファクタリングがある [8].

まず，問題 (1) を解決するために，コードクローンのリ
ファクタリング可能性を自動で判断するために JDeodor-

コードクローンのリファクタリングとは，外部的な振舞

ant [18] を利用した．JDeororant はその機能の 1 つにクいを保ったまま，コードクローンを 1 つのメソッドにまとローンペア（互いに一致または類似しているコード片の対）

めるプロセスを指す [15]．コードクローンに対するリファ

からリファクタリング可能性で評価する．

クタリングのプロセスは 2 つの作業によって実現できる．

問題 (2) を解決するために，削減可能ソースコード量の1 つは，コードクローンをまとめるための共通のメソッド

大きさに着目して，オーバラップしているコードクロー

を新規に作成する作業である．もう 1 つは，コードクロー

ンの中から削減可能なソースコード量が大きなコードク

ン自体は共通メソッドの呼び出し文に置換する作業である．

ローンを優先的にリファクタリングする方針を採用した．

近年，保守性が低下した商業用ソフトウェアの保守性をこの方針に従う場合，見積もりに必要な時間計算量はコー向上させたいという需要に応えるために，他の企業のソフ

ドクローンの個数にともなって増加する．そのため，我々トウェアの保守性向上をサービスとして提供する企業が存

はオーバラップしているコードクローンに対して，メタ在する．また，これらの企業は効率的な保守活動を実現す

ヒューリスティックによる近似アルゴリズム [4], [17] を適るためにソフトウェアのリファクタリングを提供する*1 ．

用し，リファクタリングするべきコードクローンの組合せ

このリファクタリングには，潜在的なバグの除外やデッドを選択的に決定する．

コードの特定，冗長なソースコードの削減などがあげられまた，提案手法を用いて，7 つのオープンソースソフト

る．冗長なソースコードを削除する一環として，コードク

ウェア（以下，OSS とする）の削減可能ソースコード量をローンのリファクタリングがある．依頼元企業と請負先企調査した．また，提案手法の妥当性を確認するために OSS

業との間では，リファクタリングにおける削減行数や金銭である JEdit，JMater，Apache Ant に含まれる 80 個のリ的および時間的コストなど見積もってから契約が行われる．

ファクタリング可能なクローンセットに対して，手動でリしかし，一般的に，巨大化したソースコードはその構造ファクタリングした結果と提案手法による結果を比較した．

の理解が難しいため，コードクローンのリファクタリング

以降，2 章では研究の背景について説明し，3 章では提を見積もる際に次の 2 つの問題が生じうる．(1) リファク

案手法について述べる．4 章では削減可能ソースコード量

タリングすべきコードクローンを特定することは困難であの調査の方法と結果を説明し，5 章でまとめと今後の課題

ることと (2) 検出したコードクローンの位置情報が部分的について述べる．

にオーバラップすることである．これらの問題はリファク
タリング可能な行数の見積もりに大きく誤差が生じさせ，
ソフトウェアの保守性向上のためのサービスに支障をきた

2. 背景
2.1 コードクローン

すことがある．問題 (1) を回避するために容易にリファク

コードクローンとは，ソースコード中に存在する互いに一

タリング可能性を判断できるコードクローンにのみ焦点を致または類似した部分を持つコード片のことである [6], [9]．

当てる方法が考えられる．しかし，容易にリファクタリン

また，互いに一致または類似しているコード片の対をクグ可能性を判断できるコードクローンは，ソースコードがローンペアと呼び，コードクローンの集合をクローンセッ

それほど複雑ではないなどの理由があり，本質的な解決にトと呼ぶ．また，コードクローンは次の 3 つのタイプ分類は至らない．そのため，巨大化したソースコードを対象とできる．

した，コードクローンのリファクタリング可能性に注目し• タイプ 1 空白行やコメント行などのコーディングス

た推定手法が必要になる．また，問題 (2) に対して，再帰的タイルを除いて完全に一致するコード片を持つ．

なリファクタリングを適用することでコードクローンを削• タイプ 2 変数名や関数名，変数の型などの識別子の減できる可能性がある．しかし，再帰的なリファクタリン
グは必ずしもすべてのオーバラップしているコードクロー
ンに対応できるわけではない．また，再帰的にリファクタ
リングを適用した場合，メソッドを呼び出す階層が深くなる可能性もある．

みが異なるコードクローンである．

• タイプ 3 タイプ 2 であるうえに命令文の挿入や削除，変更が行われたコードクローンを指す．
コードクローンの主要な発生原因として既存のコード片をコピーアンドペーストにより再利用することがあげられる．コードクローンはソースコード行数を増大させ，ソフ*1

http://info.hitachi-ics.co.jp/product/rf/index.html

c 2019 Information Processing Society of Japan

トウェア保守を困難にする [6]．たとえば，コードクロー

1052

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)

れる効果は事前に推定するのが困難であるという現実がある．したがって，開発者がコードクローンのリファクタリ
ングにおける削減効果の推定結果は，コードクローンのリ
ファクタリングを行う動機の判断指標として利用する場
面が考えられる．本稿では，その判断指標として削減可能
ソースコード量を定めた．削減可能ソースコード量とは，
仮にコードクローンをリファクタリングした場合に，コー
図 1 コードクローンのリファクタリング

Fig. 1 Refactoring code clone.

ドクローンの削除によって元のソースコードから減少すると予想されるソースコード行数の推定値を表す．
削減可能ソースコード量の評価基準としては，コードク

ンに修正が加えられる場合，そのコードクローンと同一のローンの個数やトークン長，行数などが候補にあげられる．

クローンセットに属するコードクローンに対して一貫性

そのため，リファクタリング前後のソースコードの変化をのある修正を検討する必要性がある．もしすべてのコード

どのようにすれば，効果的に表現できるのか考える必要がクローンに対して一貫した修正が行われてなかった場合ある．

は，バグの原因が生じる可能性がある．そのため，コード

また，ソースコード全体から検出されたコードクローン

クローンの効率的管理をする必要がある．しかし，ソフトの削減可能ソースコード量を求めるには，以下の 2 つの問

ウェアの規模が大きくなるにつれて，開発者の意図しない題を解決するための条件を満たすクローンセットを求める

コードクローンが発生したり，複数の開発者で開発したり必要がある．2 つの問題は 2.2.1 項と 2.2.2 項でそれぞれ説するため，すべてのコードクローンの位置を把握するのは明する．

難しくなる．したがって，コードクローンを自動で検出す• リファクタリング可能性

るツールが多く提案されてきた [11], [13], [14], [20]．

• オーバラップ2.2.1 リファクタリング可能性の問題

2.2 削減可能ソースコード量

コードクローンのリファクタリングは一部のコードク

コードクローンを削減させる方法として，リファクタ

ローンのみに可能であり，リファクタリングが可能である，リングと呼ばれるプロセスをコードクローンに適用する

またはリファクタリングが困難であるといった評価をリことができる [15]．コードクローンのリファクタリングとファクタリング可能性と呼ぶ [18]．リファクタリングが困

は，コードクローンを共通のメソッドやクラスにまとめて，難である例として，メソッドの返り値は最大で 1 つの型しコードクローンは呼び出し文に置換して削減するというプか持てないが，コードクローンによっては条件分岐によっ

ロセスである．

て必ずしも同じ型の返り値を持つとは限らない状況や，そ図 1 はコードクローンのリファクタリングの例を表し

れぞれのクラスがディレクトリ構造で見たときに非常に離ている．コードクローンを図 1 では，コードクローン C1

れている状況があげられる．このようにリファクタリングと C2 の共通の処理部分が新しいメソッドとして抽出され，可能性を判断するために必要な条件は複数存在する．ただコードクローン C1 と C2 は共通のメソッドの呼び出し文

し，コードクローンのリファクタリング可能性はプログラに置き換えられている．コードクローンのリファクタリン

ム言語の機能に大きく依存すると考えられる．

グを実施する際，どこに共通処理のコード片をまとめるの2.2.2 オーバラップの問題

か判断するには，各コードクローンが存在する階層構造や

コードクローン検出ツールは，互いにソースコードが重継承関係などを考慮する必要がある．そのため，必ずしもなっているコードクローンを検出することがある．このよ同一ファイル内に作成をすべきとは限らない．

うな状態をオーバラップと呼ぶ．また，クローンセットに

コードクローンをリファクタリングするために，開発者属するコードクローン ca1 が別のクローンセットに属するはコードクローンの位置や階層構造に着目して，外部的なコードクローン cb1 とオーバラップしているとき，それら振舞いが変わらないように行う必要がある．このコードクのクローンセットはオーバラップしていると表す．オーバ

ローンのリファクタリングにおけるソースコードの削減

ラップしている ca1 と cb1 を含むクローンセットを同時に効果を事前に推定することが求められている．この背景にリファクタリングした場合，それぞれのコードクローン ca1

は，保守性が低下したソフトウェアの保守性向上をサービと cb1 の共通処理を持つメソッド間では重複したコード片スとして提供する企業が存在するという事例があげられが含まれてしまい，同じ処理を 2 回実行してしまう．そのる．特に，複雑に巨大化したソースコードにおいて，そのため，これらのコードクローンを同時にリファクタリング

保守性は低下している場合が多く，それらから検出されたすることはできない．したがって，もしオーバラップしてコードクローンのリファクタリングに費やすコストや得らいるクローンセットの削減可能ソースコード量を重複して

c 2019 Information Processing Society of Japan


1053

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)

3.1 ステップ 1：コードクローンの検出
まず，最初にコードクローンを検出する．本研究では
コードクローンの検出をするために CCFinderX [12] を用いた．CCFinderX は様々な大規模ソフトウェアに適用されており [7]，高いスケーラビリティ性を示しているため，本研究で利用した．CCFinderX は 2.1 節で説明したタイプ

1 とタイプ 2 のコードクローンを検出することができる．
また，タイプ 3 のコードクローンについては，本研究では対象に含まない．タイプ 3 のコードクローンをリファク
タリングする際には一部の行をコードクローンの範囲外へ
図 2 オーバラップしている簡単なソースコード例

Fig. 2 Simple example of overlapping of source code.

移動させる場合が存在している．しかし，3.4 節で説明す
る計算方法では，移動作業を考慮をしていないので削減可能ソースコード量を見積もれないからである．よって，タ数えてしまった場合，オーバラップしているクローンセッ

イプ 3 のコードクローンを対象とした計算は今後の課題でトの削減可能ソースコード量と実際の削減行数とは異なるある．

可能性がある．この問題を解決するために，コードクロー
ンが互いにオーバラップしている場合，リファクタリング
するコード片を分割したり，一方だけをリファクタリング
したりするといった工夫が必要である．

3.2 ステップ 2：コードクローンのリファクタリング可能性の計測
このステップでは，検出されたコードクローンのリファク

図 2 は，オーバラップしているコードクローンの例をタリング可能性を計測する．本研究ではリファクタリング示す．この表は，3 つのクローンセット a，b，c にそれぞ可能性を計測するために JDeodorant を使用した [18], [19]．

れ属する 4 つのコードクローン ca1 ，cb1 ，cb2 ，cc1 についJDeodorant はリファクタリングを支援する Eclipse プラて対応する関係を示している．クローンセット a はコードグインとして開発されリファクタリング可能性を判断する

クローン ca1 を持つ．クローンセット b はコードクローン機能を提供する．このツールは複数のコードクローンがリ

cb1 ，cb2 を持つ．クローンセット c はコードクローン cc1

ファクタリング可能になるのに必要な前提条件とネスト構を持つ．

造木，プログラム依存グラフを利用することによりリファ

図 2 に示すソースコードは 2 つの IF 文（1 行目から 3 行

クタリング可能性を非常に高い精度で評価する．

目と 4 行目から 6 行目）と 1 つの WHILE 文（7 行目から

JDeodorant が計測するリファクタリング可能性につい9 行目）によって構成されている．クローンツールは検出て説明する．JDeodorant はクローンペアのリファクタリ

条件としてしきい値などを満たしているコードクローンでング可能性の前提条件を以下のように示している [18]．こあれば，図 2 のように 3 つのクローンセットに分けて検出

れらの前提条件に 1 つでも違反していた場合，そのクローする可能性がある．このとき，コードクローン ca1 は cb1 ，ンペアはリファクタリング困難と見なされる．

cb2 ，cc1 のそれぞれとオーバラップしている．また，クロー

文献 [16] では，11 名のプログラマが Eclipse 上で様々なンセットに基づいて表現すると，クローンセット a と b，a

条件をもとにリファクタリングできるのか観察する被験者と c はそれぞれオーバラップしていると表現できる．

実験が行われた．その中で下記で示した条件を満たさない

3. 提案手法
この章では，ソフトウェアから検出されたコードクロー
ンをリファクタリングした場合の削減可能ソースコード量

リファクタリングは困難であると述べられている．そのため，本研究においても文献 [16] で定められた前提条件に従う．

( 1 ) 変数のパラメータ化の際に制御依存，データ依存，反を算出する手法について説明する．図 3 は提案手法の概復操作や出力の振舞いに変更がない必要がある．

要を表している．提案手法は図 3 に示すように．5 つのス( 2 ) それぞれ異なる子クラス型を持つ変数は，共通の親クテップから構成される．

ラスで宣言されているか，あるいはオーバライドされ( 1 ) コードクローンの検出

たメソッド内でのみ呼び出されている必要がある．

( 2 ) コードクローンのリファクタリング可能性の計測( 3 ) リファクタリング可能なクローンセットの抽出( 4 ) クローンセット 1 つの削減可能ソースコード量の計算( 5 ) オーバラップの解決
以降の節でそれぞれのステップの詳細について説明する．

c 2019 Information Processing Society of Japan( 3 ) フィールド変数のパラメータ化は，そのフィールド変数が変更可能ならば許可しない．

( 4 ) メソッド呼び出しのパラメータ化は，void 型を返さないときのみ可能である．

( 5 ) 抽出されたメソッドは，2 つ以上の変数を返さない必

1054

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)

図 3 削減可能ソースコード量算出の概要図

Fig. 3 Overview of calculating the amount of reducible source code.

要がある．

( 6 ) 条件付き return 文がコードクローンのコード片に含まない必要がある．

( 7 ) 分岐処理を意味する命令文（BREAK，CONTINUE）
があれば，それに対応する反復命令文がコード片を含まない必要がある．

3.3 ステップ 3：リファクタリング可能なクローンセッ
トの抽出出式について説明する．ある 1 つのクローンセット S に属する n 個のコードクローン ci を入力として得られる削減可能ソースコード量 T (S) は次の式 (1)〜(3) によって計算される．

size(c) = lend (c) − lbegin (c) + 1
c∗size =

n
1 

(1)

size(ci )(2)

T (S) = n ∗ c∗size − (c∗size + 2 + n)

(3)

n

ci ∈S

次に，リファクタリング困難なコードクローンを除外す
る．ただし，JDeodorant はクローンペア単位でリファク

式 (1) において，size(c) はコードクローン c が存在する

タリング可能性を評価している．そのため，同じクローン

行数を表し，lend (c) と lbegin (c) はそれぞれコードクローン

セットに属するコードクローンでも，特定の組合せの場合

c の終了行番号と開始行番号を示している．これらの情報

はリファクタリング困難になっている場合がある．そこはクローン検出ツールによって得られる．式 (2) は，n 個ので，同じクローンセット内でリファクタリング可能である

コードクローンの平均行数 c∗size を示している．これは同と計測されたクローンペアを 1 つも含んでないコードク

一クローンセットに属するコードクローンであっても，開ローンをリファクタリング困難なコードクローンとして除発者ごとに改行などの好みのコーディングスタイルが存在外する．そして，1 回以上リファクタリング可能と計測さするためにこれらのコードクローンが異なる行数を持ってれたクローンペアについては，そのどちらのコードクローいる可能性がある．そのために，本研究では平均的なコーンもリファクタリング可能と見なす．

ドクローン c∗ を用いた．

3.4 ステップ 4：クローンセットごとの削減可能ソース

算演算子を境目にその前後で別々のソースコードの状態を式 (3) で求められる削減可能ソースコード量 T (S) は減
コード量の計算計算する．式 (3) の第 1 項では，コードクローンのリファ

このステップでは，リファクタリング可能なコードク

クタリングが行われる前のソースコードに含まれるクローローンのみが含まれるクローンセットごとの削減可能ソーンセット S に属する n 個のコードクローン ci 全体のソースコード量を求める．本研究では，削減可能ソースコード

スコード量を表している．減算演算子以降では，2 つの観量の単位はソースコード行数とする．まず，削減可能ソー点で計算されている．1 つ目は c∗size + 2 の部分であり，こスコード量をクローンセットごとに計算する目的についこではコードクローンの共通処理が抽出されたメソッドのて説明する．ここで求めるクローンセットごとの削減可能

行数を表している．この式で 2 が加えられているのは，メソースコード量は次のステップ 5-2 において，オーバラッ

ソッドの導入文および終了文を追加されるためである．な

プしているクローンセットに対してメタヒューリスティッ

お，ここでの計算は主に Java 言語を対象としているが，ほクを適用するために用いる．また，オーバラップしていなかの言語では必ずしも 2 行の追加でサブルーチンの記述がいクローンセットの削減可能ソースコード量についてはこ

完了するわけではないことに気を付けたい．

のステップ 4 で求めた削減可能ソースコード量を用いる．

式 (3) の計算結果は負の数，すなわちコードクローンを次に，クローンセットごとの削減可能ソースコード量の算

リファクタリングすることでソースコード全体の行数が増

c 2019 Information Processing Society of Japan


1055

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)

加する場合が考えられる．本研究では，ソースコードをど(1) はオーバラップしないための論理式である．(2) と (3)れだけ縮小させられるのかが調査することが目的であるたはどちらもオーバラップをする関係を示した論理式である

め，リファクタリングすることで全体のコードが長くなる

が，包含関係にあるか否かで場合分けをしている．

コードクローンを選択しない仕組みを採用している．

ステップ 5-2：メタヒューリスティックの適用

2 つ目の式は n であり，これはすべてのコードクローン

本手法では，オーバラップしているコードクローンののコード片を呼び出し文に置換した場合に必要な行数と想中から同時にリファクタリングして削減可能行数を最大定している．この本研究では，Java 言語においてメソッドとするクローンセットの組合せを選択するために，メタの呼び出し文は一行で完結するものと想定しているが，他

ヒューリスティックな手法を採用した [4], [17]．我々の先の言語では必ずしもそうではない．これら 2 つの計算部分

行研究 [10] では，Java 言語の OSS に対して 4 つのメタがコードクローン削除によるソフトウェアの振舞いの変更

ヒューリスティックなアルゴリズムを用いて，削減可能を防ぐための記述に必要な最低限の行数である．よって，

ソースコード量を推定した．その結果，これらのアルゴリ

元のコードクローンの行数とこれらの差が削除可能ソース

ズムによる推定値の差はほぼないことが判明した．そこでコード量である．

本研究では，実行時間が最も短い貪欲法を採用した．
貪欲法によるクローンセットの組合せを決定するアルゴ

3.5 ステップ 5：削減可能行数を最大とするクローンセッ
トの組合せの選択

リズムについて要点を説明する．詳細は文献 [10] である．
また，この詳細は文献 [4], [17] に従い提案したものである．

最後にソースコード全体の削減可能ソースコード量の計提案手法では，メタヒューリスティックと呼ばれる組合せ算するために，前のステップ 4 で計算したクローンセット

最適化問題における，近似解を求める解放を持つアルゴリ

ごとの削減可能ソースコード量を用いて，オーバラップしズムの基本的な枠組みを用いている．このメタヒューリスているクローンセットとオーバラップしていないクローン

ティックでは，対象問題の表現方法，状態の更新条件，評セットに分けてそれぞれの削減可能ソースコード量を計

価値の決定をユーザが決める．貪欲法では，オーバラップ

算して，最後に足し合わせる．オーバラップしていないク

しているクローンセットに対して，評価値を式 (3) で求め

ローンセットはクローンセットごとの削減可能ソースコーられる削減可能ソースコード量 T (S) として組合せの候補

ド量をすべて足し合わせればよいが，オーバラップしていとして選択する．

るクローンセットは同時にリファクタリングして削減可能

オーバラップしていないクローンセットと貪欲法により行数を貪欲法を用いてクローンセットの組合せを選択す

解の候補に含まれるすべてのコードクローンに対するリる．よって，オーバラップを解決する手順は次のとおりでファクタリングによる削減可能ソースコード量の総和が対ある．

象ソフトウェアの削減可能ソースコード量として求めら• ステップ 5-1 オーバラップの検出れる．

• ステップ 5-2 メタヒューリスティックの適用

自身とのオーバラップ

ステップ 5-1:オーバラップしているコードクローンの検出

オーバラップにおける考慮をしなければならない状況が2 つのクローンセットにそれぞれ属するコードクローン

ある．クローンセットのオーバラップには，同一のクロー

c1 ，c2 のオーバラップの検出は次のような条件を調べるこンセット内で生じる場合もある．この現象は SWITCH 文とで可能になる．なお，あるクローン c の開始行を tb (c)，など同じ命令文が連続しやすいコード片で生じやすい．同

終了行を te (c) とする．(1) コードクローン c1 ，c2 がオー

じ命令文が続くコード片であるため，コード片を分割すれバラップしない場合：

ばリファクタリングできそうではあるが，本研究ではこのte (c1 ) < tb (c2 ) ∨ te (c2 ) < tb (c1 )ような現象が起きるクローンセットを調査対象から除外す(2) コードクローン c1 ，c2 がオーバラップする，かつ，ないリファクタリングである可能が高いためである．

包含関係にない場合：

る．これは削減可能ソースコード量の算出手法に適用でき

4. 調査(tb (c1 ) < tb (c2 ) ∧ te (c1 ) > tb (c2 ) ∧ te (c1 ) < te (c2 ))我々は提案手法を 7 つの OSS の削減可能ソースコード∨ (tb (c2 ) < tb (c1 ) ∧ te (c2 ) > tb (c1 ) ∧ te (c2 ) < te (c1 ))量を本手法を用いて推定している．また，提案手法の妥当(3) コードクローン c1 ，c2 がオーバラップする，かつ，性を確認するために JEdit *2 ，JMeter *3 ，Apache Ant *4 に包含関係にある場合：(tb (c1 ) < tb (c2 ) ∧ te (c1 ) > te (c2 )∨ (tb (c2 ) < tb (c1 ) ∧ te (c2 ) > te (c1 ))c 2019 Information Processing Society of Japan

含まれる 80 個のリファクタリング可能なクローンセット
*2
*3
*4

http://www.jedit.org/
https://jmeter.apache.org/
https://ant.apache.org/

1056

情報処理学会論文誌

表 1

Vol.60 No.4 1051–1062 (Apr. 2019)

調査対象の OSS（*単位は kLoC ）Table 1 Statistics of the analyzed OSS systems

表 2 各 OSS から検出されたコードクローンとクローンセット

Table 2 The numbers of code clones and clone sets in each(*unit is kLoC).
プロジェクト名

バージョン

Ant

OSS.
行数*

1.10.1268

CLoC*（%）

プロジェクト名

60（22.3）

Ant

コードクローン数

クローンセット数

POP

2,981

515

5.79
2.48

Columba

1.4

54

4.6（8.5）

Columba335

135

JMeter

3.2

91

5.6（6.1）

JMeter

437

201

2.17

124

54

2.29

9,976

2,309

4.32

JEdit

5.4.0

180

1.8（1.0）

JEdit

JFreeChart

1.0.19310

175（56.4）

JFreeChart

JRuby

1.7.27325

61（18.8）

JRuby

4,383

1,398

3.13

Xerces

2.10.0238

83（34.9）

Xerces

4,889

1,311

3.73

に対して，手動でリファクタリングした結果と提案手法による結果を比較した．

4.1 各オープンソースソフトウェアに含まれる削減可能
ソースコード量の分析
動機

表 3

検出されたクローンペア数とリファクタリング可能なクロー
ンペア数

Table 3 The numbers of detected clone pairs and refactorable
clone pairs.
プロジェクト名

クローンペア数

リファクタリング可能なクローンペア数（%）

Ant

8,785

2,068（23.5）

提案手法が実際の OSS から検出されたコードクローン

Columba597

187（31.3）の行数に対してどのくらい削減できるのかを分析する必要

JMeter294

99（33.7）がある．リファクタリング困難なコードクローンやオーバ

JEdit

100

17（17.0）

ラップするコードクローンがどの程度の頻度で出現するのJFreeChart

84,551

8,765（10.4）

JRuby

15,546830（5.3）

Xerces44,764

1,612（3.6）

かはプロジェクトごとに異なる．たとえば，すべてのコー
ドクローンのリファクタリング可能性やオーバラップを考慮せずに，リファクタリングできるコードクローンの行数を見積もった場合，その見積もりはコードクローンの数には JEdit である．

比例すると予測できる．しかし，リファクタリング可能性

表 2 は CCFinderX で検出したコードクローンとクローやオーバラップの影響を考慮した場合，比例するかどうか

ンセットの個数，クローンセット 1 つあたりに属するコー

は調査すべき事項であると考える．
調査対象
本調査で対象とした OSS について説明する．すべてのプロジェクトが主に Java 言語で記述されている．
表 1 は，対象とした 7 つの OSS プロジェクトとその行

ドクローンの個数を示す．コードクローンメトリクス POPの値の平均を示す．コードクローンメトリクス POP は
コードクローンの総和からクローンセットの個数の除算で求められる．コードクローンメトリクス POP の値が大きいほど削減可能ソースコード量は大きくなる．したがっ数，コードクローンが占める行数（CLoC）を表している．

て，この POP によって，リファクタリング時に削除され本研究では，既存研究 [10], [18] で対象となったプロジェク

るコードクローンの数がより多くなることが予想できる．

トの中から，Java 言語で記述されていて，コンパイルが可表 2 で分かるようにコードクローン数が最も多いのは，能だったプロジェクトを調査対象として選択した．
表 1 で分かるように最もコードクローンが検出さJFreeChart で，コードクローン行数に反映されている．全体のおおよその傾向として，コードクローンの個数とコーれたプロジェクトは JFreeChart である．ソースコード

ドクローン行数は比例することが分かる．また，POP の

全 体 の 56.4%が コ ー ド ク ロ ー ン で あ る こ と が 分 か る ．

値は，最大が Apaache Ant の 5.15 で，最小が JMeter のJFreeChart *5 はグラフを作成するための Java のライブ

2.17 である．

ラリである．作成するグラフごとに機能を実装している

表 3 は対象 OSS から検出されたクローンペアの個数とので，非常に多くのコードクローンが見られるものと考

JDeodorant で評価したリファクタリング可能なクローン

えられる．次にコードクローンを多く含むプロジェクトペアの個数を示す．全体のクローンペアのうち，最大では Apache Xerces *6 で 34.9%である．このプロジェクトは30%程度のクローンペアがリファクタリング可能なクローXML 文書のパースを操作するためのパッケージである．

ンペアである．これはクローン検出ツールが多様なコード

その反面，最もコードクローン行数が少ないプロジェクト

クローンを見つけようとして，複数のメソッドにまたがる*5*6

http://www.jfree.org/jfreechart/
http://xerces.apache.org/

c 2019 Information Processing Society of Japan

コード片を持つようなコードクローンや類似した命令文の繰り返しをするようなコードクローンが検出結果に多く含1057

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)

表 4 JDeodorant に基づいたリファクタリング可能な行数とクロー
ンセット数

JDeodorant に基づいたリファクタリング可能行数と削減可能
ソースコード量（行数）の割合

Table 4 The numbers of refactorable lines and clone sets basedon JDeodorant.
プロジェクト名

表 6

JDeodorant and the amount of reducible source code.

JDeodorant 行数

クローンセット数

11,224353

Ant

Table 6 Comparison of the refactorable lines based on

プロジェクト名

JDeodorant 行数削減可能ソー割合

スコード量

Columba

1,394

41

Ant

11,224

3,429

0.31

JMeter

1,117

45

Columba

1,394

584

0.42

JEdit

384

13

JMeter

1,117

385

0.34

384

136

0.35

JFreeChart

30,495

629

JEdit

JRuby

7,708

351

JFreeChart

30,495

9,700

0.32

Xerces

16,611

374

JRuby

7,708

2,161

0.28

Xerces

16,611

5,533

0.33

Average

3,133

9,848

0.32

表 5 提案手法に基づいた削減可能ソースコード量（行数）とクロー
ンセット数（括弧内は，検出されたコードクローン全体に対する削減可能ソースコード量およびクローンセット数の割合，単て全行がリファクタリングされるわけではなく，約 32%が位は%）Table 5 The amount of reducible source code and the num-削減できることを示している．

ber of clone sets based on the proposed assessment

この理由には次の 2 つが考えられる．1 つ目の理由と(the value in parentheses shows the proportion of re-

して，互いにオーバラップしているコードクローンから

ducible source code and the number of clone sets to

優先してリファクタリングすべきコードクローンを選

all detected code clones).
プロジェクト名択したことがあげられる．このとき，コードクローンの削減可能ソースコード量

クローンセット数

オーバラップの仕方次第では，削減可能な行数は減る可Ant

3,429（5.7）

264（26.2）

能性がある．2 つ目の理由は，リファクタリングにおけColumba584（12.7）35（25.9）

JMeter385（6.8）

36（17.9）

JEdit

136（7.6）

13（24.1）

JFreeChart

9,700（5.5）

401（17.4）

JRuby2,161（3.5）

251（18.0）

n ∗ c∗size − (c∗size + n + 2) = (n − 1) ∗ c∗size − 2 − n となる．

Xerces5,533（6.6）

244（18.6）

n の最小値は POP の最小値と等しく，2 である．削減可

る振舞いの変更を防ぐために書かれる共通処理を持つメソッドと呼び出し文の存在である．たとえば，コード
クローンメトリクス POP の値が n において，式 (3) は能ソースコード量は共通処理を持つメソッドの呼び出し文
まれているためと思われる．最もリファクタリング可能ながオーバヘッドとなり，削減可能なコードクローン行数はクローンペアが得られたプロジェクトは JFreeChart であ半分以下になると考えられる．

る．ただし，割合では，Columba *7 や JMeter が 30%を超え得られた削減可能ソースコード量の考察ているのが確認できる．最小は Apache Xerces で 3.6%で

表 5 で示すように対象 OSS のソースコードからコードあった．

クローンのリファクタリングより削減可能なソースコード

調査結果

量は，平均 6.9%にとどまることが明らかになった．OSS

表 4 は各 OSS の JDeodorant が示したリファクタリン
グ可能なクローンセットの行数とそのクローンセット数での場合，多くの開発者が保守作業に携わっているため，この結果は予測しうる範囲内といえる．

ある．また，表 5 は JDeodorant の結果を基に提案手法をまた，検出されるコードクローン数にも着目した場合，用いた削減可能ソースコード量とそのクローンセット数をJEdit の個数が変化していないのは，オーバラップしてい示している．削減可能ソースコード量の括弧内の数値は，るクローンセットが存在していないためである．JEdit 以

元のソースコードから検出された全コードクローン行数に外の OSS では，オーバラップしているクローンセットが対する比率を表している．

存在している．また，表 5 中のクローンセット数の列内

表 6 は表 4 で示した JDeodorant に基づいたリファクタのカッコ内の数値は，検出されたすべてのクローンセット

リング可能な行数と，表 5 は JDeodorant の結果を基に提の個数と比較した削減可能なクローンセットの個数の割合

案手法を用いた削減可能ソースコード量を比較した結果をを示している．比率だけを見るなら，Apache Ant が最大示している．7 つの OSS における平均割合は約 32%であの値 26.2%を示している．削減可能なクローンセットの個る．これは JDeodorant がリファクタリング可能と示した数を見ると，最大は 401 個の JFreeChart である．しかし，

コードクローンは，そのリファクタリングする過程においJFreeChart の場合，検出されたコードクローン全体に対す*7る削減可能ソクローンセット数の割合は最小で 17.4%であhttps://sourceforge.net/projects/columba/

c 2019 Information Processing Society of Japan


1058

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)

る．これは，多くのコードクローンが検出され，その中にオーバラップしているコードクローンが多く含まれている

表 7

手動と自動で推定した削減可能ソースコード量の比較

Table 7 Comparison between manual and automatic estiminations of the amount of reducible source code.

からである．

プロジェクト名

4.2 手動のリファクタリングとの比較
動機

クローンセット数

手動

自動

JEdit

14

131

136
385

JMater36

397

Apache Ant

30

597

654

All

80

1,097

1,170

JDeodorant のリファクタリング可能性に基づいた削減
可能ソースコード量は，JDeodorant に依存する．しかし，この数値の信頼度は，JDeodorant の正当性が不可欠となる．そこで，この章では，JEdit，JMater，Apache Ant に含まれるリファクタリング可能と評価されたクローンセッ
ト 80 個を対象に，手動でリファクタリングを実行して，その削減量を計測した．その手作業による計測値と提案手法
を用いて見積った削減可能ソースコード量を比較して，提案手法によって推定した削減可能ソースコード量の正当性を確認する．JEdit，JMater はそれぞれ 14 個と 36 個の削減可能なすべてのクローンセットを対象に実験を行った．
また，Apache Ant に対しては，264 個の削減可能なクロー

図 4ンセットのうち，タスク定義を行うコアパッケージである

Fig. 4 Example of refactoring code clones with errors.

誤差が発生したコードクローンのリファクタリング例

taskdefs パッケージよりさらに小さないくつかのパッケージに含まれる合計 30 個すべてのクローンセットを対象とのコーディングスタイルに一致させた場合に，複数行した．30 個という数字は削減可能なクローンセット数 264

にわたる場合がある．

個の約 11.3%に相当する．実験を行う対象やパッケージを• instanceof 句でオブジェクトが特定のクラスと等しい

絞る理由は，テストコードを実験環境で再現することが困か確認した後，そのオブジェクトを判定したクラスと難であるパッケージが含まれていたり，すべての削減可能

して扱うようにキャストする処理が含まれる．

なクローンセットを対象にするためには多くの時間が必要

1 つ目の原因は共通メソッドに返り値が必要となり，そのであったりするためである．

返り値を返すための return 文を追加するために誤差が生手動によるリファクタリング

じてしまうからである．評価対象の 80 個のクローンセッ

JDeodorant でリファクタリング可能と評価された 80 個

トのうち，4 個のクローンセットに対して，これが原因でのクローンセットを手動でリファクタリングを行った．こ

誤差が生じた．この誤差を解決するには，共通処理を持つ

こで，計測する削減行数は，削減可能ソースコード量に基メソッドとして抽出してきたコード片を分析して，必要なづいて同様の計算方法を用いて測定した．すなわち，リ

返り値とその型を取得する必要があると考えられる．

ファクタリング前のクローンセット全体の行数からリファ

2 つ目の原因は開発者のコーディングスタイルを考慮しクタリング後の共通処理を持つメソッドの行数と置換された結果，共通処理を持つメソッドの開始行数が複数行にわた呼び出し文の和を引いた値となる．

たる場合が見られたために誤差が生まれたことである．本

比較結果

調査の場合は，一部の開発者がソースコード中の中括弧の

表 7 は JEdit，JMater，Apache Ant で削減可能と評価

みを改行して 2 行にわたるコーディングをしていたため，されたクローンセット 80 個を対象に，手動でリファクタ

誤差が生じた．この場合以外にも，extends 文や implement

リングしたコードクローンの削減量と自動的に算出した削文，長すぎる引数などを改行するコーディングスタイル

減可能ソースコード量を示している．自動的に推定されたは考えられる．これらを解決するためには，開発者ごとの削減可能ソースコード量は全体で 1,097 行に対して，手動

コーディングスタイルを考慮する必要がある．あるいは，による削減行は 1,170 行であった．すなわち，73 行の差が改行そのものはプログラムの動作の本質そのものには影響存在することが分かった．

がないと考えて，コーディングスタイルを考慮しない削減

この原因が誤差が生じた原因に関する考察

可能ソースコード量を測る手法も考えられる．

73 行の誤差が発生した原因としては，次の 3 つが考えられる．

図 4 は誤差が発生したコードクローンの一部とそのリファクタリングするにあたって作成した共通処理を持つメ• 返り値のために return 文が必要な場合がある．

ソッドの例である．ソースコードの一部は冗長であるため• 共通メソッドや呼び出し文の開始行や終了行を開発者に中略している．元のコード片は，Object 型の変数 sourcec 2019 Information Processing Society of Japan


1059

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)を getSource() メソッドで取得した後，そこに代入されて場合，共通の処理を持つメソッドを作成する際にメソッド

いる変数に応じて処理が分岐している．また，このコードの開始行と終了行を書く必要はない．

クローン箇所の後の処理で，ふたたび変数 source を利用するために source の変数を返す必要がある．そのため，ク5.2 リファクタリング可能性の前提条件への妥当性

ローンペアがまとめられた共通処理を持つメソッドには，リファクタリング可能性の前提条件は，文献 [16] 中の被その変数 source を返すために return 文を追加している．

験者実験の結果に基づいて定められている．このことは，また，このソースコードを作成した開発者はメソッドの開リファクタリング可能性に強い制約を持たせており，リ

始行数を中括弧で改行するコーディングスタイルである．

ファクタリングを行う開発者に高度なプログラミング技術

そのため，開発者のコーディングスタイルを考慮して，作を求めないものと思われる．そのため，提案手法における成した共通処理を持つメソッドの開始行でも中括弧を改行

リファクタリング可能性の制約条件が，ツールや開発者のさせている．

技術が実際のソースコードの削減に与える影響は大きく，

3 つ目の原因は，オブジェクトクラスのインスタンスが必ずしも提案手法の削減可能なソースコード量の推定結果

特定のクラスであるか判別して，そのクラスへキャストすが正しくないといえる．そのため，JDeodorant とは異なる処理が含まれるコードクローンの存在である．このようるリファクタリング可能性の前提条件を持つリファクタリなソースコードを提案手法どおりにリファクタリングする

ングツールなどを用いて同様の検証を行う必要があると考ことは削減困難であると判断した．

える．

4.3 調査結果の考察

6. まとめと今後の課題

4.1 節の調査結果から JDeodorant が計測するリファク

本稿では，コードクローンのリファクタリングによる削タリング可能性に基づいた削減可能ソースコード量は，各減可能ソースコード量の算出手法を提案した．そして，削OSS の平均 6.9%であることが判明した．また，4.2 節の調減可能ソースコード量を算出するうえで生じる 2 つの課題

査結果により手動によるリファクタリング結果は 1,097 行

であるコードクローン間のオーバラップとコードクローンとなり，推定された削減可能ソースコード量 1,170 行と比のリファクタリング可能性について説明した．調査実験で較した．発生した誤差については，それぞれ適切な対処を

は 7 つの Java 言語で記述された OSS を対象とした削減可検討する必要がある．そして，この傾向は調査対象の OSS

能ソースコード量を測定して，その傾向を考察した．削減

だけではなく他のオープンソースソフトウェアについても可能なソースコード量は検出されたコードクローン行数全

同様に得られると考えている．

体のおよそ 6.9%である．また，検出されたクローンセッ

JDeodorant は開発者にとって外部的な振舞いが変わる

ト数の 20%ほどが削減可能であった．最後に，削減可能ことがない簡単なコードクローンのリファクタリングを支

ソースコード量の正当性を評価するために，手動のリファ援している．しかし，JDeodorant がリファクタリング可

クタリングによる削減可能ソースコード量と比較した．そ

能性を評価する際に用いる前提条件に違反するリファクタの結果，削減可能ソースコード量の算出手法の強い妥当性

リングであっても，コードクローンのリファクタリング方を得た．

法を工夫することで回避できる可能性があるため，4.1 節

今後の課題として，以下があげられる．

や 4.2 節の結果で得られた傾向は変わる恐れがある．しか• 削減可能ソースコード量に関して，大規模な商用プロ

しながら，検出したコードクローンを開発者がほとんど加工をせずに得られる削減可能ソースコード量としては重要な知見を得られたと考える．

5. 妥当性への脅威
5.1 計算式の妥当性

グラムへの適用を行う必要がある．

• リファクタリング可能なコードクローンをリファクタリングした場合の，実際のソフトウェア保守へ与える影響を調査する必要がある．

• タイプ 1，タイプ 2 に加えて，タイプ 3 のコードクローンの削減可能ソースコード量の算出手法の提案する．

3.4 節の式 (3) は，リファクタリング対象のコードクロー• 削減可能ソースコード量は多様なコードスタイルに影ンによっては適切な推定値を得ることができない．本研究響を受けるため，ランダムサンプリングなどの手法をでは，式 (3) はクラスやメソッドを宣言する文を含まないこ

用いて評価する．

とを前提に削減可能ソースコード量を推定している．これは，コードクローンがクラスやメソッドである場合が稀であるためである．しかし，クラスまたはメソッドをリファ
クタリングする場合，式 (3) の計算手法では正しい結果は得られない．たとえば，メソッドをリファクタリングする

c 2019 Information Processing Society of Japan• 前提条件が異なるリファクタリングツールを用いた評価手法を用いる．

• 提案手法が削減可能ソースコード量を推定する実行時間について調査する．

• 今回対象の OSS は十分にリファクタリングされてい1060

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)

る可能性がある．リポジトリ内ですでにリファクタリ
ングされている変更に対して評価する．
謝辞 本研究は JSPS 科研費 JP25220003，JP18H04094，[19]

JP16K16034 の助成を受けた．
[20]

参考文献
[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]
[10]

[11]

[12]

[13]

[14]

[15]
[16]

[17]

[18]

Bavota, G., Carluccio, B.D., De Lucia, A., Di Penta, M.,
Oliveto, R. and Strollo, O.: When Does a Refactoring
Induce Bugs? An Empirical Study, 12th IEEE International Working Conference on Source Code Analysis andManipulation, pp.104–113, SCAM (2012).
Bouktif, S., Giuliano, A., Merlo, E. and Neteler, M.:
A novel approach to optimize clone refactoring activity,
Proc. GECCO 2006, pp.1885–1892 (2006).
Edwards III, B., Wu, Y., Matsushita, M. and Inoue,K.: Estimating Code Size After a Complete Code-Clone
Merge，情報処理学会研究報告，Vol.2016-EMB-41, No.3,
pp.1–8 (2016).
Harman, M., Phil, M., Jerﬀeson, de Souza, T. and Yoo,
S.: Search Based Software Engineering: Techniques,
Taxonomy, Tutorial, Empirical Software Engineeringand Verification, pp.1–59 (2012).
肥後芳樹，吉田則裕，楠本真二，井上克郎：産学連携に基づいたコードクローン可視化手法の改良と実装，情報処
理学会論文誌，Vol.48, No.2, pp.811–822 (2007).
肥後芳樹，楠本真二，井上克郎：コードクローン検出とその関連技術，電子情報通信学会論文誌，Vol.J91-D, No.6,
pp.1465–1481 (2008).
肥後芳樹，楠本真二，井上克郎：コードクローン分析ツー
ル Gemini を用いたコードクローン分析手法，電子情報通信学会，Vol.105, No.228, pp.37–42 (2005).
肥後芳樹，吉田則裕：コードクローンを対象としたリファ
クタリング，コンピュータソフトウェア，Vol.28, No.4,
pp.43–56 (2011).
井上克郎，神谷年洋，楠本真二：コードクローン検出法，コンピュータソフトウェア，Vol.18, No.5, pp.47–54 (2001).
石津卓也，吉田則裕，崔 恩瀞，井上克郎：メタヒュー
リスティクスを用いた集約可能コードクローン量の推定，情報処理学会研究報告，Vol.2016-SE-193, No.5, pp.1–8(2016).
Jiang, L., Misherghi, G., Su, Z. and Glondu, S.:
DECKARD: Scalable and Accurate Tree-Based Detection of Code Clones, Proc. ICSE 2007, pp.96–105 (2007).
Kamiya, T., Kusumoto, S. and Inoue, K.: CCFinder: A
multilinguistic token-based code clone detection system
for large scale source code, IEEE Trans. Softw. Eng.,
Vol.28, No.7, pp.654–670 (2002).
神谷年洋，肥後芳樹，吉田則裕：コードクローン検出技術の展開，コンピュータソフトウェア，Vol.28, No.3,
pp.29–42 (2011).
Kim, H., Jung, Y., Kim, S. and Yi, K.: MeCC: memory comparison-based clone detector, Proc. ICSE 2011,
pp.301–310 (2011).
Fowle, M.: Refactoring: Improving the Design of Existing Code (1999).
Murphy-Hill, E. and Black, A.P.: Breaking the barriers
to successful refactoring: observations and tools for extract method, Proc. 30th International Conference on
Software Engineering, pp.421–430, ACM (2008).
O’Keeﬀe, M. and Cinneide, M.O.: Search-based refactoring: an empirical study, Proc. SBSE, Vol.20, No.5,
pp.345–364 (2008).
Tsantalis, N., Mazinanian, D. and Krishnan, G.P.: As-

c 2019 Information Processing Society of Japansessing the Refactorability of Software Clones, IEEE
Trans. Softw. Eng., Vol.41, No.11, pp.1055–1090 (2015).
Tsantalis, N., Mazinanian, D. and Rostami, S.: Clone
Refactoring with Lambda Expressions, Proc. ICSE
2017, pp.60–70 (2017).
山中裕樹，崔 恩瀞，吉田則裕，井上克郎：情報検索技術に基づく高速な関数クローン検出，情報処理学会論文誌，Vol.55, No.10, pp.2245–2255 (2014).

石津 卓也
平成 27 年度大阪大学基礎工学部情報科学科卒業，平成 29 年度大阪大学大阪大学院情報科学研究科博士前期課程修了．現在，株式会社富士通研究所に勤務．コードクローンのリファクタリ
ング支援に関する研究に従事．

吉田 則裕 （正会員）
平成 21 年大阪大学大学院情報科学研
究科博士後期課程修了．同年日本学術振興会特別研究員（PD）．平成 22 年
奈良先端科学技術大学院大学情報科学研究科助教．平成 26 年名古屋大学大学院情報科学研究科附属組込みシステ
ム研究センター准教授．平成 29 年より同大学大学院情報学研究科附属組込みシステム研究センター准教授（改組による）．博士（情報科学）．コードクローン分析手法やリ
ファクタリング支援手法に関する研究に従事．

崔 恩瀞 （正会員）
平成 27 年大阪大学大学院情報科学研
究科博士後期課程修了．同年同大学大学院国際公共政策研究科助教．平成28 年奈良先端科学技術大学院大学情報科学研究科助教．平成 30 年より同大学先端科学技術研究科助教（改組による）．博士（情報科学）．コードクローン管理やリファク
タリング支援手法に関する研究に従事．

1061

情報処理学会論文誌

Vol.60 No.4 1051–1062 (Apr. 2019)井上 克郎 （正会員）
昭和 59 年大阪大学大学院基礎工学研
究科博士後期課程修了（工学博士）．
同年大阪大学基礎工学部情報工学科助
手．昭和 59 年〜61 年，ハワイ大学マノア校コンピュータサイエンス学科助教授．平成 3 年大阪大学基礎工学部助教授．平成 7 年同学部教授．平成 14 年より大阪大学大学
院情報科学研究科教授．ソフトウェア工学，特にコードク
ローンやコード検索等のプログラム分析や再利用技術の研究に従事．本会フェロー．

c 2019 Information Processing Society of Japan

1062