研究用語ミニ辞典 A small dictionary of the field

時間的な制約などのもとで選ばれた「その場しのぎの設計・実装」が、後の変更コストを増大させていく現象。Ward Cunninghamが1992年の経験報告で示した「借金」のたとえに由来します。うまく使えば開発を前に進める力になりますが、放置すると保守の負担が積み上がります。 What happens when expedient design and implementation choices, made under constraints such as time pressure, drive up the cost of future changes. The term traces to a borrowing metaphor Ward Cunningham introduced in a 1992 experience report. Used well it moves development forward, but left unpaid it accrues a growing maintenance burden.

借金の比喩で技術的負債を語るときの二つの側面。その場しのぎの実装そのものを「元本」、放置している間に膨らむ追加の保守コストを「利息」と見立てます。負債を早く返す（リファクタリングなどで解消する）ほど、支払う総コストは小さくなります。 The two sides of the borrowing metaphor. The expedient implementation itself is the principal, and the extra maintenance cost that swells while it sits untouched is the interest. The sooner the debt is repaid, through refactoring and the like, the smaller the total cost.

技術的負債のうち、開発者自身が明示的に認識し、コメントや課題票などの形で書き残したもの。研究者が定義・検出する負債とは異なり、開発者の言葉で負債の存在が示されている点が特徴です。コード中のコメントに残すSATD-Commentと、課題管理システムで管理するTD-Issueに大別されます。 The part of technical debt that developers themselves explicitly recognize and record, in comments or issue tickets. Unlike debt that researchers define and detect, it is debt made visible in the developer's own words, split broadly into SATD-Comment, left in source-code comments, and TD-Issue, managed in an issue tracker.

SATDのうち、個々の開発者がソースコード中のコメントとして残す負債の痕跡（TODOやFIXMEなど）。ソースコードレベルで負債の存在を示す、もっとも身近な形です。 The form of SATD an individual developer leaves as a source-code comment, such as a TODO or FIXME. It is the most familiar way debt is marked at the source-code level.

課題管理システム上で、プロジェクトとして管理される負債の課題票。debtなどのラベルを付けて明示的に管理されることが多く、SATD-Issueとも呼ばれます。個人が残すSATD-Commentに対し、プロジェクトレベルで負債を扱う点が特徴です。 A debt issue managed at the project level in an issue tracker, often marked explicitly with a label such as debt; also referred to as a SATD-Issue. Where SATD-Comment is left by an individual, this handles debt at the level of the project.

外部から見た振る舞いを変えないまま、内部の構造を整理・改善するコード変更。技術的負債の元本を解消する、代表的な返済手段です。データ型の変更やリネームなど、細粒度の変更が組み合わされることも多いとわかっています。 Restructuring and improving a program's internal structure without changing its external behavior. It is the primary way of repaying the principal of technical debt, often applied as a combination of fine-grained changes such as data-type changes and renaming.

重複したロジックや過度に長いメソッドなど、設計上の問題を示唆するコードの兆候。研究者が定義した指標にもとづき、コードから機械的に検出できる負債の代表例で、開発者が明示するSATDとは異なる「検出する系譜」に属します。 A surface indicator of a design problem, such as duplicated logic or an overly long method. A representative form of debt detectable mechanically from code using researcher-defined criteria, belonging to the "detection" lineage rather than the SATD lineage of developer-stated debt.

規模・複雑さ・変更履歴など、ソフトウェアやその開発過程を定量的に表す指標。技術的負債の検出や特徴づけに用いられ、ソースコード由来の指標だけでなく、変更間隔や作成者数のような開発履歴由来の指標も含まれます。 Quantitative indicators of software and its development process, such as size, complexity, and change history. Used to detect and characterize technical debt, spanning both source-code metrics and development-history metrics such as change interval and author count.

プログラムを実行せずにソースコードを解析し、コードスメルや潜在的な不具合などを見つける手法。専用のセットアップが要る一方、バージョン管理の履歴だけから計算できる指標は、これに頼らずに負債の候補を絞り込む選択肢にもなります。 A technique that analyzes source code without executing it, to find code smells and potential defects. It requires dedicated tooling, so metrics computable from version-control history alone offer a way to screen debt candidates without it.

バグを含むプログラムに対し、テストを通過する修正パッチを自動的に生成する技術。正しさは満たしても、コーディング規約違反を増やすなど、可読性・保守性の面で別の課題を抱えることが分かっています。 A technique that automatically generates a fix, a patch that passes tests, for a buggy program. It can satisfy correctness while raising other concerns for readability and maintainability, such as an increase in coding-standard violations.

データをあらかじめ定めたクラスに割り当てる分類モデルの総称。決定木はその一種で、木構造の分岐によって分類し、どの指標がどう効いているかという判断の根拠を読みやすいのが特徴です。 A general term for models that assign data to predefined classes. A decision tree is one such classifier: it classifies through a sequence of branching decisions arranged as a tree, which makes the basis for its judgments, which metrics matter and how, easy to read.