報告される前の技術的負債を、メトリクスで捉える Catching technical debt from software metrics, before it is reported

Yuta Kimura（大阪公立大学工業高等専門学校） · Osaka Metropolitan University College of Technology
Masao Ohira（和歌山大学） · Wakayama University · IEICE Trans. Inf. & Syst. に投稿中（査読中）Under review at IEICE Trans. Inf. & Syst.

課題として報告される前に、コードそのものから技術的負債を見つけられるか。 Can we find technical debt straight from the code, before anyone files a ticket?

研究の詳細を読むRead the study in depth 主要な発見へJump to the findings

分類の正解率Classification accuracy 0 › 1.0

基準baseline 0.644

全指標All (77) 0.827

ファイル 5File (5) 0.822

コード 72Source (72) 0.765

開発履歴だけの5指標が、72のソースコード指標に匹敵する。 5 development-history metrics rival 72 source-code metrics.

140

対象プロジェクトprojects

72,952

ファイルfiles analyzed

メトリクスmetrics

0.827

正解率（基準 0.644）accuracy (baseline 0.644)

5 : 72

履歴指標が構造指標に匹敵history rivals structure

ソフトウェアは長く使われるほど保守費が膨らみ、その一因が技術的負債、すなわち後の変更を高くつかせる、その場しのぎの設計や実装です。近年は課題管理システムで debt ラベルを付けて負債を報告・管理する運用（TD Issue）が広まりました。しかし早期に手を打つには、報告される前にコードそのものから負債を見つけたい。本研究は、GitHub上のJava 140プロジェクト、約7.3万ファイルを対象に、72のソースコードメトリクスと5のファイルメトリクス（開発履歴）で「開発者が負債と報告したファイル」をどこまで分類・特徴づけできるかを検証しました。 The longer software lives, the more it costs to maintain, and one driver is technical debt: expedient design or implementation that makes future changes costlier. Teams increasingly tag issues with a debt label to report and manage it (TD Issues). But to act early, we want to find debt from the code itself, before it is reported. This study asks how far 72 source-code metrics and 5 file (development-history) metrics can classify and characterize the files developers reported as debt, across 140 Java projects on GitHub (about 73k files).

4つのポイントFour takeaways

01メトリクスには「天井」があるMetrics have a ceiling

全メトリクスを使っても正解率は0.827（多数クラス基準0.644）。強力なランダムフォレストでも0.883どまりで、コードスメル研究の0.97超には遠く及びません。課題報告の負債は、コードスメルとは性質が異なります。 Even with all metrics, accuracy reaches only 0.827 (majority baseline 0.644); a strong random forest tops out at 0.883, far below the 0.97+ reported for code smells. Issue-reported debt differs in nature from code smells.

02「履歴」が「構造」に匹敵するHistory rivals structure

わずか5つのファイルメトリクス（変更間隔・変更回数・作成者数・経過年数・階層の深さ）が、72のソースコードメトリクスに匹敵・凌駕。バージョン管理履歴だけで計算でき、言語にも依存しません。 Just 5 file metrics (change interval, number of changes, authors, age, directory depth) match or beat 72 source-code metrics. They are computable from version-control history alone, independent of language.

03限界にも正直にHonest about limits

プロジェクトをまたぐ評価（未知プロジェクトへの適用）では、正解率は基準値付近まで低下。「絞り込みの手がかり」にはなっても、そのまま使える検出器ではないことを明確に示しました。 Under a cross-project evaluation (applying to unseen projects), accuracy falls close to the baseline. A useful screening signal, not a ready-made detector.

04解釈可能で、再現可能Interpretable and reproducible

性能だけでなく「なぜ」を読める決定木で分析。データ整形から実験・作図まで、分析パイプラインを整理しています。 We analyze with an interpretable decision tree so the "why" is legible, and organize the full pipeline from data preparation to experiments and figures.

研究の進め方The study in four steps

正解ラベルGround truth

開発者が報告したTD-Issueの解消時に変更されたファイルを「負債あり」とする。ツール定義ではなく現場の認識が基準。Files changed to resolve developer-reported TD-Issues are labeled as debt, grounded in developers' own recognition, not a tool's definition.

特徴量Features

72のソースコードメトリクス（規模・複雑さ・依存）と、5のファイルメトリクス（開発履歴）。72 source-code metrics (size, complexity, dependency) and 5 file metrics (development history).

モデルModel

解釈性を重視した決定木（CART）。Gini重要度でどの指標が効くかを可視化。An interpretable decision tree (CART); Gini importance reveals which metrics matter.

2つの問いTwo questions

RQ1: どこまで分類できるか。RQ2: 負債ファイルを特徴づける指標は何か。RQ1: how well can we classify? RQ2: which metrics characterize debt files?

数字が語ることWhat the numbers say

全指標All metrics ファイル指標のみ (5)File only (5) ソースコード指標のみ (72)Source only (72)

分類の精度。メトリクスだけでは0.827から0.883で、コードスメルの0.97超には届かない。ファイル指標(5)のみでもソースコード指標(72)に匹敵する。 Classification accuracy. Metrics alone reach 0.827 to 0.883, short of code smells' 0.97+. Five file metrics rival 72 source-code metrics.

開発履歴（ファイル）指標Development-history (file) metric ソースコード指標Source-code metric

効いている指標。全77指標のモデルで、重要度の上位5つをファイルメトリクスが独占。負債は「コードの構造」だけでなく「開発の文脈」に関わることを示唆。 What drives the model. In the all-77-metric model, file metrics occupy the top five importances, so debt is tied to development context, not code structure alone.

負債ファイルの姿（RQ2）The shape of a debt file (RQ2)

大きく、依存が多い：行数やインポート数が中央値で大きい（例：総行数 120 対 82）。Larger and more dependent: higher median lines and imports (e.g., 120 vs 82 total lines).
よく変わる：変更間隔が短く、変更回数が多い（最大級の効果量）。Changed often: shorter change intervals and more changes (the largest effect sizes).
依存される場所に集まる：util・model・service など、多くのコードから参照される共通部品に負債が生じやすい。Concentrated in depended-upon components: debt clusters in widely-referenced parts such as util, model, and service.

なぜ重要かWhy it matters

「メトリクスで検出」という同じ枠組みでも、正解ラベルの出所（ツール定義か、開発者の認識か）で難易度が大きく変わります。本研究はこれを定量的に示しました。実務的には、静的解析環境がなくてもバージョン履歴だけで点検対象を安価に絞り込める可能性を示し、研究的には、コード内容そのものを入力とする表現学習など、次の検出手法の設計指針を与えます。 Within the same "detect-with-metrics" framework, difficulty changes sharply with the origin of the ground truth: a tool's definition versus developers' recognition. We show this quantitatively. Practically, teams can cheaply screen candidates from version history without a static-analysis setup; scientifically, it points next-generation detectors toward learning from code content itself.

正直な但し書き：ここでの数値はプロジェクト内評価です。プロジェクトをまたぐ評価では正解率が基準値付近まで下がるため、未知プロジェクトへの適用にはさらなる工夫（プロジェクト文脈のモデル化など）が必要です。 An honest caveat: these figures come from a within-project evaluation. Under a cross-project evaluation accuracy drops near the baseline, so applying to unseen projects needs further work, such as modeling project context.

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

位置づけ、データセット、RQ1・RQ2の全数値、妥当性の脅威までを解説した詳細ページを用意しています。A detailed page walks through the positioning, dataset, the complete RQ1 and RQ2 results, and threats to validity.

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