研究の詳細The study in depth

技術的負債は、時間的制約などの下で選ばれた低品質な設計・実装を「元本」、放置により積み上がる保守コストを「利息」になぞらえた概念です。近年は課題管理システムで debt ラベルを付けて負債を報告・管理する運用（TD Issue）が広まりました。しかし、報告される前に手を打つには、課題報告を前提とせず、コードそのものから負債を捉えたいという動機が生じます。 Technical debt likens low-quality design or implementation chosen under constraints such as time pressure to the "principal", and the extra maintenance cost that accrues while it is left unaddressed to the "interest". Teams increasingly report and manage it by attaching a debt label to issue reports (TD Issues). To act before debt is reported, however, we want to capture it from the source code itself, without presupposing an issue report.

先行研究は大きく二つの流れに分けられます。研究者が定義する負債（コードスメルなど）を静的解析やメトリクスでコードから検出する系と、開発者が明示した負債（SATDやTD-Issue）をテキストから同定する系です。本研究は、開発者が課題として報告した負債を、それを構成するコードから捉えるという、これまで手薄だった領域に位置づけられます。 Prior work splits into two lines: detecting researcher-defined debt (such as code smells) from code via static analysis and metrics, and identifying developer-explicit debt (SATD, TD-Issues) from text. This study occupies the underexamined space of capturing the debt developers reported as issues from the code that constitutes it.

データセットDataset

Skryseth らが公開した55,600件のTD-Issueを出発点に、(1)公開リポジトリ、(2)Java、(3)負債を解消するコード変更が存在する、の3条件で絞り込み、140プロジェクト・5,229件のTD-Issueを得ました。欠損メトリクスのあるファイルを除外した最終的な実験データは72,952ファイルです。 Starting from the 55,600 TD-Issues released by Skryseth et al., we kept (1) public repositories, (2) Java, and (3) issues resolved by a code change, yielding 140 projects and 5,229 TD-Issues. After excluding files with incomplete metrics, the experimental dataset contains 72,952 files.

ラベルの定義Labeling

TD-Issueの解消時に変更されたファイルの変更直前版をTDファイル、TD解消に一度も関与しなかったファイルの最新変更の直前版をNon-TDファイルとします。ファイル単位で分類します。 A TD file is the version just before a file was changed to resolve a TD-Issue; a Non-TD file is the version before the latest change of a file never involved in resolving a TD-Issue. Classification is at the file level.

特徴量とモデルFeatures and model

72のソースコードメトリクス（規模・複雑さ・依存・構造）と5のファイルメトリクス（変更間隔・変更回数・作成者数・経過年数・階層の深さ）を使います。ファイルメトリクスは各ファイルのラベル版までの履歴のみから計測し、解消の変更やそれ以降を含めないため、時間的リークはありません。モデルは解釈性を重視した決定木（CART）で、Gini重要度により効く指標を可視化します。評価は層化10分割交差検証を10回、正解率に加え適合率・再現率・F1を報告し、多数クラス基準（0.644、TD比率約36%）と対比します。 We use 72 source-code metrics (size, complexity, dependency, structure) and 5 file metrics (change interval, number of changes, number of authors, age, directory depth). File metrics are measured only from history up to each file's labeled version, excluding the resolving change and later history, so there is no temporal leakage. The model is an interpretable decision tree (CART); Gini importance reveals which metrics matter. We evaluate with 10 repeats of stratified 10-fold cross-validation, report precision, recall, and F1 alongside accuracy, and compare against a majority-class baseline (0.644; TD ratio about 36%).

解釈可能なCARTでの正解率は0.827（基準0.644）。ソースコードメトリクスのみでは0.765と弱く、ファイルメトリクスのみ（0.822）に及びません。より強力なランダムフォレストにすると全体が底上げされ、特にソースコードのみが0.765から0.853へ跳ね上がります。ただし最良でも0.883で、コードスメル研究の0.97超には届きません。したがって「課題報告の負債はコードスメルとは性質が異なる」という対比は、分類器を変えても頑健です。 With an interpretable CART, accuracy is 0.827 (baseline 0.644). Source-code metrics alone are weak (0.765), below file metrics alone (0.822). A stronger random forest lifts every model, and source-code-only jumps from 0.765 to 0.853; even so the best model (0.883) stays short of the 0.97+ reported for code smells. The contrast with code smells is therefore robust to classifier choice.

さらに、プロジェクトをまたぐ評価（プロジェクト単位の交差検証）では、全モデルが基準値付近（0.564〜0.703）まで低下します。プロジェクト内評価の数値は、未知プロジェクトへの適用に対して楽観的だと分かります。ファイルメトリクスは相対的に最も頑健で、開発履歴の情報がプロジェクト間でやや転移しやすいことを示唆します。 Under a cross-project evaluation (project-grouped cross-validation) all models fall near the baseline (0.564 to 0.703): the within-project figures are optimistic for unseen projects. File metrics are the most robust, suggesting development-history information transfers across projects somewhat better.

全77指標のモデルでは、重要度の上位5つをファイルメトリクスが独占します。効果量（Cliff's δ）で見ても、変更間隔（δ=−0.478、大）と変更回数（+0.381、中）が最大で、ソースコードメトリクスはいずれも小。負債ファイルは、規模と依存が大きく、変更間隔が短く変更回数が多い、という姿が浮かびます。 In the all-77-metric model, file metrics occupy the top five importances. By effect size (Cliff's δ) the change interval (δ = −0.478, large) and number of changes (+0.381, medium) are the largest, while source-code metrics are all small. A debt file tends to be larger and more dependency-heavy, with shorter change intervals and more changes.

効果量Effect sizes

木構造とコンポーネントTree structure and components

ファイルメトリクスのみの木は、根で変更間隔29.7日を境に分岐します。頻繁（間隔が短い）かつ多く（6.5回超）変わるファイルは負債を含みやすく、稀にしか変わらず階層の深いファイルは負債を含みにくい、と読めます。配置の観点では、負債は util・model・service・config・impl といった、多くのコードから参照される共通部品に生じやすい傾向がありました（表記揺れはレマタイゼーションで吸収）。ただしこれらは最頻出のディレクトリでもあるため、順位は出現率も部分的に反映します。 The file-only tree splits at a change interval of 29.7 days. Files changed frequently (short interval) and often (more than 6.5 times) tend to contain debt, while rarely changed, deeply nested files tend not to. By placement, debt clusters in widely-referenced components such as util, model, service, config, and impl (notation variants absorbed by lemmatization). These are also the most common directories, so the ranking partly reflects component prevalence.

プログラム内容への着目Attending to program content

課題報告の負債は、メトリクスが要約する構造だけでは捉えきれず、RFでも0.883にとどまります。メトリクスは内容を捨象した要約であるため、コード内容そのものを入力とする表現学習が次の有望な方向です。Issue-reported debt is not fully captured by the structure metrics summarize; even a random forest reaches only 0.883. Because metrics abstract away content, representation learning that takes the code content itself as input is a promising next direction.

開発文脈の役割The role of development context

CARTではファイルメトリクスが構造メトリクスを上回りましたが、RFでは正解率が並びます。したがって「開発文脈が支配的」と強くは言えず、より頑健な言い方は「開発履歴は有効で安価、かつプロジェクト間で比較的転移しやすい信号」です。Under CART, file metrics outperform structural metrics, but under a random forest they tie on accuracy. So we avoid claiming context "dominates"; the robust statement is that development-history information is an effective, inexpensive, and relatively transferable signal.

実務家と研究者への含意Implications

• 実務家：静的解析環境がなくても、バージョン履歴だけで点検対象を安価に絞り込める。閾値は各プロジェクトのデータに合わせて調整するのがよい。Practitioners: screen inspection targets cheaply from version history alone, even without a static-analysis setup; tune thresholds to each project's data.
• 研究者：同じ「メトリクス＋機械学習」でも、正解ラベルの出所で難易度が変わる。多数クラス基準との比較と、プロジェクト間評価の報告を標準にすべき。Researchers: under the same "metrics + machine learning" setup, difficulty depends on the ground-truth origin. Comparing against a majority baseline and reporting cross-project performance should be standard.

内的妥当性：TDファイルのラベルは解消時の変更対象に由来し、付随的な変更が混じり得るためノイズを含みます。一方、ファイルメトリクスは各ファイルのラベル版までで計測しており、時間的リークはありません。単一のデフォルト設定CARTを用いたため、「限界」に関する結論は分類器に依存します（RFではより高い）。Internal: TD-file labels come from the change targets at resolution and may carry noise from incidental changes. File metrics, however, are measured only up to each file's labeled version, so there is no temporal leakage. Because we used a single default-setting CART, conclusions about "limits" are classifier-specific (a random forest is higher).

構成概念・結論・外的妥当性：Non-TDファイルにも未報告の負債が混入し得ます。欠損メトリクスによる除外は1,086件（TD 229 / Non-TD 857）で軽微。コードスメルとの対比はデータ・タスクの異なる参照比較で、RFでも成り立ちます。対象はGitHub上のOSS Javaであり、他言語や商用開発への一般化には注意が必要です。Construct, conclusion, external: Non-TD files may still contain unreported debt. Exclusions for missing metrics total 1,086 (229 TD / 857 Non-TD), which is mild. The comparison with code smells is a reference contrast across differing data and tasks, and it holds under a random forest. The targets are OSS Java on GitHub, so generalization to other languages or commercial development warrants care.

データ整形・実験（reproduce_experiments.py）・コンポーネント分析・作図までの一連のスクリプトと、日英READMEを整備しています。python reproduce_experiments.py で本文の各表を再現できます。We maintain scripts for data preparation, experiments (reproduce_experiments.py), component analysis, and figures, with a bilingual README. Run python reproduce_experiments.py to reproduce the paper's tables.

概要にもどる ›Back to overview ›