研究の詳細The study in depth
背景と位置づけから、データセットと特徴量、分類性能とアブレーション、考察、妥当性の脅威、再現性までを解説します。要点だけを見たい場合は概要ページへ。 Background and positioning, dataset and features, classification performance and ablation, discussion, threats, and reproducibility. For the short version, see the overview.
背景と位置づけBackground and positioning
技術的負債(TD)のうち、開発者自身が明示的に認識・管理するものを SATD(Self-Admitted Technical Debt)と呼びます。SATDは、コード中のコメントで表される SATD-Comment と、課題管理システム上で管理される SATD-Issue に大別されます。 Debt that developers themselves explicitly recognize and manage is called SATD (Self-Admitted Technical Debt). It divides into SATD-Comment (expressed in code comments) and SATD-Issue (managed in an issue tracker).
SATD-Comment には多くの研究蓄積がある一方、SATD-Issue はプロジェクトレベルで負債を管理する例が少なく、研究に使えるデータが不足していました。本研究は、このデータ不足を解消する第一歩として、負債を明示的に管理していないプロジェクトからも SATD-Issue を収集できるよう、自動分類モデルを構築します。 SATD-Comment is well studied, but SATD-Issue is understudied because few projects manage debt at the project level, leaving a shortage of usable data. As a first step to resolve this shortage, we build an automatic classifier so SATD-Issues can be collected even from projects that don't explicitly manage debt.
手法Method
データセットDataset
負債を課題票で管理している 4つのOSSプロジェクトから、GitHub REST API で課題票を収集しました。各プロジェクトの負債ラベル(debt / technical debt など)が付いた課題票を SATD-Issue(正例)とします。
We collected issues via the GitHub REST API from four OSS projects that manage debt as tickets. Issues carrying each project's debt label (debt, technical debt, etc.) are the positive class, SATD-Issues.
| プロジェクトProject | ラベルLabel | SATD | 課題票Issues |
|---|---|---|---|
| microsoft/vscode | debt | 1,612 | 102,292 |
| influxdata/influxdb | kind/tech debt | 111 | 9,903 |
| saleor/saleor | technical debt | 106 | 2,623 |
| nextcloud/server | technical debt | 73 | 9,273 |
対象プロジェクトと課題票数。SATDは正例の数で、全課題票に対しごく少数(不均衡)。Studied projects and issue counts. SATD is the (small, imbalanced) positive class within all issues.
特徴量とモデルFeatures and model
特徴量は4系統から作ります:メタデータ(起票者の経験・オープン課題数など 7項目)、課題票(タイトル長・コメント数・解決時間など 9項目)、コード(追加/削除クラス数・行数・ネストなど 14項目)、そして本文テキスト。テキストは spaCy(en_core_web_lg)でトークン化・レンマ化し、Markdown・URL・コードスニペットを除去して BoW と TF-IDF に変換。多重共線性は VIF で除去し、特徴量は Min-Max で正規化。分類器には SVM を用います。
Features come from four groups: metadata (reporter experience, open-issue count, etc.; 7), issue (title length, comment count, resolution time, etc.; 9), code (added/deleted classes, lines, nesting, etc.; 14), and the body text. Text is tokenized and lemmatized with spaCy (en_core_web_lg), stripped of Markdown, URLs, and code snippets, and turned into BoW and TF-IDF. Multicollinearity is removed via VIF, features are Min-Max scaled, and an SVM is the classifier.
分類性能Classification performance
最も正例が多い vscode では、TF-IDF を用いた SVM が Precision 0.995・Recall 0.903・F1 0.947 を達成しました。一方、正例が数十件と少ない influxdb・saleor では Recall が伸びず(不均衡データの難しさ)、F1 が低くなります。nextcloud/server は中間的です。データ量が性能を大きく左右することが分かります。 On vscode, which has the most positives, an SVM with TF-IDF reaches Precision 0.995, Recall 0.903, F1 0.947. Where positives number only dozens (influxdb, saleor), recall lags (the difficulty of imbalanced data) and F1 drops; nextcloud/server sits in between. Data volume strongly shapes performance.
| プロジェクト(最良設定)Project (best config) | Precision | Recall | F1 |
|---|---|---|---|
| microsoft/vscode · TF-IDF | 0.995 | 0.903 | 0.947 |
| nextcloud/server · TF-IDF | 0.965 | 0.525 | 0.671 |
| influxdata/influxdb · BoW | 0.762 | 0.238 | 0.352 |
| saleor/saleor · BoW | 0.475 | 0.213 | 0.285 |
各プロジェクトの最良設定での分類性能。正例が多いほど高い。Best-config performance per project; more positives, better scores.
どの特徴量が効くか(アブレーション)What drives it (ablation)
vscode で特徴量の系統を出し入れして寄与を調べました。テキストだけでは F1 は 0.598 にとどまりますが、課題票・メタデータの特徴を加えると 0.9 前後まで跳ね上がります。一方、コードの特徴は単独ではほとんど寄与しません。全特徴を組み合わせた最良モデルは F1 0.947 に達しました。テキストは必要だが十分ではなく、課題票まわりの文脈情報が決め手になる、という構図です。 On vscode we added and removed feature groups. Text alone reaches only F1 0.598, but adding issue and metadata features lifts it to around 0.9. Code features contribute little on their own. The best model combining all features reaches F1 0.947. Text is necessary but not sufficient; the context around the issue is decisive.
| 特徴量の組み合わせFeature combination | F1 |
|---|---|
| テキストのみText only | 0.598 |
| テキスト + 文脈特徴Text + context features | 0.887 |
| 全特徴(最良)All features (best) | 0.947 |
vscode でのアブレーション(抜粋)。コードのみの特徴は寄与が小さい。Ablation on vscode (excerpt); code-only features add little.
考察Discussion
- データ量が鍵:正例の多い vscode で高精度。小規模プロジェクトでは、より多くの正例か、プロジェクト横断の学習が必要。Data volume is key: high accuracy on data-rich vscode; smaller projects need more positives or cross-project learning.
- 文脈が効く:本文テキストに加え、課題票・メタデータの文脈特徴が性能を大きく押し上げる。Context matters: beyond body text, issue and metadata context features lift performance substantially.
- 次の一手:BoW/TF-IDF に代えて Word2Vec や Transformer による表現学習で、少数データでも頑健な分類を目指せる。Next step: replacing BoW/TF-IDF with Word2Vec or Transformer representations could make classification robust even on scarce data.
妥当性の脅威Threats to validity
構成概念:SATD-Issue の正解は各プロジェクトの負債ラベルに依存します。ラベル運用の差がノイズになり得ます。テキスト表現は BoW/TF-IDF に基づき、語順や文脈を十分に捉えていない可能性があります。Construct: SATD-Issue ground truth relies on each project's debt label, so labeling differences can add noise. Text is represented with BoW/TF-IDF, which may not fully capture word order or context.
外的妥当性:対象は4つのOSSプロジェクトに限られます。他のプロジェクトや、負債を明示的に管理していないプロジェクトへの一般化は、今後の検証課題です。External: the study covers only four OSS projects; generalization to others, especially projects that don't explicitly manage debt, remains to be validated.
再現性Reproducibility
分類モデルの構築・評価に用いたコードを GitHub で公開しています。The code used to build and evaluate the classifier is available on GitHub.