技術的負債の返済は、どれだけリファクタリングを伴うのか How much does paying down technical debt mean refactoring?

池原大貴・, 木村祐太
コンピュータソフトウェア Vol.43 No.1 (2026) pp.54-67 ・ 査読付き（FOSE2024推薦） Computer Software, Vol.43 No.1 (2026), pp.54-67 · Refereed (recommended from FOSE 2024)

課題管理システムで報告された負債。その「返済」のコミットを開けてみると、そこに何が起きているのか。 Debt reported in an issue tracker gets "repaid." Open those commits. What actually happens inside?

研究の詳細を読むRead the study in depth 主要な発見へJump to the findings
59.6%がリファクタリングを含むinclude refactoring

TD-Issueの返済コミットの59.6%がリファクタリングを含み、その過半数は複数操作を組み合わせる（1コミット中央値3種類）。 59.6% of TD-Issue repayment commits include refactoring; over half combine multiple operations (median 3 types per commit).

139
JavaプロジェクトJava projects
59.6%
返済＝リファクタリング含むrepayments with refactoring
3
1コミットあたりのリファクタリング種類数（中央値）refactoring types per commit (median)
RefMiner
リファクタリング検出ツールRefactoringMiner

技術的負債は、将来の保守コストを押し上げるだけでなく、ソフトウェアの進化を妨げます。だからこそ、負債は早めに取り除く＝「返済」することが望まれます。近年は課題管理システムで debt ラベルを付けて負債を管理する運用（TD-Issue）が広まりましたが、その返済時にそもそもどのようなコード変更が行われているのかは、これまで十分に検討されてきませんでした。本研究は、GitHub上の 139 のJavaプロジェクトを対象に、TD-Issueに紐づく返済コミットを RefactoringMiner で解析し、返済とリファクタリングの関係を明らかにします。 Technical debt not only raises future maintenance cost but also hinders software evolution, so removing it early (its "repayment") is desirable. Teams increasingly manage debt by tagging issues with a debt label (TD-Issues), yet what code changes actually occur during repayment has been underexamined. Analyzing repayment commits linked to TD-Issues across 139 Java projects with RefactoringMiner, this study clarifies the relationship between repayment and refactoring.

3つのポイントThree takeaways

RQ1返済の約6割はリファクタリング~60% involve refactoring

TD-Issueを解消する返済コミットの59.6%がリファクタリングを含み、そのうち過半数は複数のリファクタリング操作を組み合わせていました。59.6% of repayment commits that resolve TD-Issues include refactoring, and over half of those combine multiple refactoring operations.

RQ2操作は細粒度が中心Fine-grained operations

適用されるリファクタリングは、データ型の変更やリネームといった細粒度の変更が中心でした。大がかりな再設計より、こまやかな手入れが多い姿です。The refactorings applied are mostly fine-grained (data-type changes and renaming), more careful tidying than sweeping redesign.

RQ3型変更は同時多発しやすいType changes co-occur

リファクタリングを行う際は、変数・戻り値などのデータ型を変える操作を、同時に複数まとめて適用する傾向がありました。When refactoring, developers tend to apply several data-type-changing operations at once, across variables, return values, and other elements.

研究の進め方The study in three steps

1

TD-Issueの収集Collect TD-Issues

名前に debt を含むラベルが付いた Issue を収集する。Gather issues labeled with a name containing debt.

2

返済コミットの収集Collect repayment commits

TD-IssueのIDをコミットメッセージに含むコミットを集める。Find commits whose messages reference a TD-Issue ID.

3

操作の検出Detect operations

収集した返済コミットを RefactoringMiner で解析する。Analyze the collected repayment commits with RefactoringMiner.

なぜ重要かWhy it matters

「負債を返済する」と言っても、実際に何が行われているのかは曖昧でした。本研究は、返済とリファクタリングの結びつきを定量的に示し、返済の実像を可視化します。今後は、負債の種類ごとに返済パターンを整理することで、実務者が「どの負債に、どんな手入れが要るか」を見通せるようにすることを目指します。 "Repaying debt" was a vague notion in practice. By quantifying its link to refactoring, this study makes repayment concrete. Future work aims to organize repayment patterns by debt type, helping practitioners anticipate what kind of work each debt will require.

分析の要点Method notes

  • 対象：GitHub上の 139 Javaプロジェクト、debt ラベルのTD-Issue。Targets: 139 Java projects on GitHub; TD-Issues carrying a debt label.
  • 紐づけ：コミットメッセージ中のIssue IDで返済コミットを同定。Linking: repayment commits identified via issue IDs in commit messages.
  • 検出：RefactoringMiner でリファクタリング操作の種類と共起を分析。Detection: refactoring types and co-occurrence analyzed with RefactoringMiner.

背景・手法・全結果を詳しくBackground, method, and full results

データセット、各RQの詳しい数値、妥当性の脅威までを解説した詳細ページがあります。A detailed page covers the dataset, the numbers behind each RQ, and threats to validity.

研究の詳細ページへGo to the in-depth page