研究の詳細The study in depth

技術的負債は、将来の保守コストを押し上げるだけでなく、ソフトウェアの進化そのものを妨げます。だからこそ、負債は早めに取り除く＝「返済」することが望まれます。近年は課題管理システムで debt ラベルを付けて負債を管理する運用（TD-Issue）が広まりました。 Technical debt not only raises future maintenance cost but also hinders software evolution itself, so removing it early (its "repayment") is desirable. Teams increasingly manage debt by tagging issues with a debt label (TD-Issues).

先行研究は、負債とリファクタリングの関係（SATDとの共起など）や、負債返済に伴うコード変更を扱ってきました。しかし、TD-Issueの解消時にそもそもどのようなコード変更が行われているのか（返済がどの程度リファクタリングを伴うのか）は、十分に検討されていませんでした。本研究はこの間隙に位置づけられます。 Prior work examined the link between debt and refactoring (e.g., co-occurrence with SATD) and code changes accompanying repayment. But what code changes actually occur when a TD-Issue is resolved, how far repayment involves refactoring, had not been examined. This study occupies that gap.

データセットDataset

GitHub GraphQL API を用い、名前に debt を含むラベルの付いた クローズ済みのTD-Issue を収集。Java の 139プロジェクトを対象としました。次に、TD-IssueのIDをコミットメッセージに含む返済コミットを集め、RefactoringMiner 3.0.7 でリファクタリング操作を検出します。 Using the GitHub GraphQL API we collected closed TD-Issues whose labels contain debt, across 139 Java projects. We then gathered repayment commits that reference a TD-Issue ID in their messages and detected refactoring operations with RefactoringMiner 3.0.7.

規模Scale

返済コミットは全 6,625 件、変更ファイルは全 103,134 件。これらを分析単位とし、コミット単位・ファイル単位の両方でリファクタリングの関与を測ります。 There are 6,625 repayment commits and 103,134 changed files in total, analyzed at both the commit and file levels for refactoring involvement.

TD-Issueを解消する返済コミットのうち、リファクタリングを含むものは 3,950 件（59.6%）。ファイル単位で見ると、リファクタリングを含むのは 33,450 件（32.4%） でした。返済のかなりの部分がリファクタリングを伴う一方、変更ファイルの多くはリファクタリングを含まない、という二面性が見えます。 Of the repayment commits that resolve TD-Issues, 3,950 (59.6%) include refactoring; at the file level, 33,450 (32.4%) do. A large share of repayment involves refactoring, yet many individual changed files do not, a two-sided picture.

単独で最も多いのは データ型の変更（Change * Type） と リネーム（Rename *） でした。上位はいずれも細粒度の変更で、メソッドの抽出（Extract Method）や移動（Move Method）のような大がかりな操作は相対的にまれです。1コミットあたりのリファクタリング種類数は中央値で3程度でした。 The most frequent single operations are data-type changes (Change * Type) and renames (Rename *). All the top operations are fine-grained; larger moves such as Extract Method or Move Method are comparatively rare. The median number of refactoring types per commit is about three.

組み合わせ分析から、リファクタリングを行う際には、変数・戻り値・属性・引数といった複数の要素のデータ型を同時にまとめて変更する傾向が明らかになりました。型に関する変更は単発では終わらず、関連する箇所へ波及して同時適用される、という返済の「かたち」が見えてきます。 The combination analysis shows that when developers refactor, they tend to change the data types of several elements (variables, return values, attributes, and parameters) at once. Type changes rarely stay isolated; they ripple to related sites and are applied together, revealing a characteristic shape of repayment.

返済コミットの一部を人手で分類したところ、TD-Issueにはコード／設計の改善を目的とするものが最も多く（約44%）、次いで TODO・SATD関連（約17%）、テスト・Flaky対応（約15%）、UI関連（約5%）などが続きました。負債と一口に言っても目的は多様で、返済の内容も一様ではないことが示唆されます。 A manual classification of a sample of repayment commits found that code/design improvement is the most common purpose of TD-Issues (~44%), followed by TODO/SATD-related (~17%), test/flaky handling (~15%), and UI-related (~5%). "Debt" spans diverse purposes, so repayment content is not uniform.

今後は、負債の種類ごとに返済パターンを整理することで、実務者が「どの負債に、どんな手入れが必要か」を見通せるようにすることを目指します。 Future work aims to organize repayment patterns by debt type, helping practitioners anticipate what kind of work each debt requires.

構成概念：リファクタリングの検出は RefactoringMiner の能力に依存し、検出漏れや誤検出があり得ます。対象はJavaに限られ、Kotlin など他言語の変更は分析対象外です。Construct: refactoring detection depends on RefactoringMiner, so misses and false positives are possible. The scope is Java; changes in other languages such as Kotlin are excluded.

内的・外的妥当性：返済コミットは、コミットメッセージ中のIssue IDで同定するため、リンクされていない返済は捕捉できません。対象はGitHub上のOSS Java 139プロジェクトであり、商用開発や他言語への一般化には注意が必要です。Internal & external: repayment commits are identified via issue IDs in messages, so unlinked repayments are missed. Targets are 139 OSS Java projects on GitHub, so generalization to commercial development or other languages warrants care.