Technical Debt

技術的負債という、開発の「借金」 Technical debt: development's own kind of borrowing

技術的負債（Technical Debt）とは、時間的な制約などのもとで選ばれた「その場しのぎの設計・実装」が、後の変更コストを増大させていく現象のことです。借金と同じで、うまく使えば開発を前に進める力になりますが、返さずに放置すると利息のように保守の負担が積み上がっていきます。 Technical debt is what happens when expedient design and implementation choices, made under constraints such as time pressure, drive up the cost of future changes. Like a loan, it can move development forward when used well, but if left unpaid it accrues interest in the form of a growing maintenance burden.

主な内容へSee the essentials 木村の研究へKimura's research

定義とメタファーDefinition and metaphor

「借金」というたとえは、どこから来たのかWhere the borrowing metaphor comes from

この比喩は、Ward Cunningham が1992年の経験報告（OOPSLA）で示したものです。急いで書いた実装は、それ自体が「借金」であり、機能を早く届ける助けになる一方で、書き直して整理するまでは利息を払い続けることになる、という考え方です。品質の低い応急的な実装を「元本」、放置している間に膨らむ追加の保守コストを「利息」と見立てると、負債を早く返す（リファクタリングなどで解消する）ほど、支払う総コストは小さくなります。 The metaphor was introduced by Ward Cunningham in a 1992 experience report (OOPSLA). Code shipped in a hurry is itself a kind of debt: it can help deliver features sooner, but until it is rewritten and cleaned up, the team keeps paying interest. If we treat low-quality, stopgap implementation as the principal, and the extra maintenance cost that swells while it sits untouched as the interest, then the sooner the debt is repaid (resolved through refactoring and the like), the smaller the total cost paid.

元本Principal

その場しのぎの実装そのものThe expedient implementation itself

締め切りに間に合わせるために選んだ、簡便で品質の低い設計・コード。今この瞬間は前に進めますが、あるべき形からは離れています。The simpler, lower-quality design or code chosen to hit a deadline. It moves things forward right now, but departs from how it ought to be.

利息Interest

放置した分だけ増える保守の負担The maintenance burden that grows while it sits

負債を抱えたまま開発を続けると、変更のたびに余計な手間・不具合・遅れが生じます。返済を先延ばしにするほど、この利息は積み上がります。Keep building on top of the debt and every change costs extra effort, bugs, and delay. The longer repayment is postponed, the more this interest compounds.

なぜ生まれるかWhy it arises

わざと負う場合と、気づかず負う場合があるSome debt is taken on knowingly, some without noticing

負債は必ずしも失敗の産物ではありません。納期や人手の制約のもとで、あえて負うことが合理的なトレードオフになる場合もあれば、経験の不足や状況の変化によって、意図せず生じてしまう場合もあります。Martin Fowler はこれを「意図的か／不注意か」と「慎重か／無謀か」という二つの軸で整理し、四つの象限（Technical Debt Quadrant）として示しました。 Debt is not always the product of failure. Under deadlines and limited staff, taking it on can be a reasonable trade-off; at other times it appears without intent, through inexperience or a change in circumstances. Martin Fowler organized this along two axes, deliberate versus inadvertent and prudent versus reckless, into four quadrants (the Technical Debt Quadrant).

慎重Prudent

無謀Reckless

意図的Deliberate

慎重かつ意図的Prudent and deliberate 「今は出荷する。影響は承知のうえで対処する」 "We must ship now and will deal with the consequences."

影響を理解したうえで、あえて負う戦略的な負債。Debt taken on strategically, with its impact understood.

無謀かつ意図的Reckless and deliberate 「設計している時間はない」 "We don't have time for design."

代償を軽視して、急ぎのために品質を切り捨てる。Cutting quality for speed while dismissing the cost.

不注意Inadvertent

慎重かつ不注意Prudent and inadvertent 「今なら、どう作るべきだったか分かる」 "Now we know how we should have done it."

学びによって、後から良い設計に気づく前向きな負債。Debt seen only in hindsight, as understanding grows.

無謀かつ不注意Reckless and inadvertent 「レイヤ分割って何のこと？」 "What's layering?"

知識の欠如ゆえに、負っていることにさえ気づかない。Debt incurred without even realizing it, for lack of knowledge.

負債のかたちThe forms it takes

負債は、いろいろな場所にたまるDebt accumulates in more than one place

技術的負債はコードだけの話ではありません。開発のさまざまな側面にたまり、代表的には次の四つのかたちで語られます。 Technical debt is not only about code. It gathers across many facets of development, and is commonly discussed in these four forms.

コード負債Code debtCode debt

読みにくいコードや重複したロジックなど、実装レベルの劣化。もっとも身近な負債。Implementation-level decay such as hard-to-read code and duplicated logic. The most familiar form.

設計・アーキテクチャ負債Design debtDesign / architecture debt

構造の劣化や密結合など、全体の骨組みにかかわる負債。影響が広く、返済も重い。Debt in the overall skeleton, such as structural decay and tight coupling. Wide-reaching and costly to repay.

テスト負債Test debtTest debt

不足したテストや検証の抜け。変更が安全かどうかを確かめにくくなる。Missing tests and gaps in verification. It becomes harder to confirm that a change is safe.

ドキュメント負債Documentation debtDocumentation debt

更新されない文書や、実態とずれた説明。新しく入る人の理解を妨げる。Documents left un-updated, or descriptions out of step with reality. They slow down newcomers' understanding.

どう管理するかHow it is managed

負債は「なくす」より「付き合う」The aim is to live with debt, not just erase it

認識するRecognize

開発者自身が負債を明示する。コード中のコメント（SATD）や、課題管理システム上のTD-Issueとして残す。Developers make the debt explicit, as comments in code (SATD) or as TD-Issues in the issue tracker.

見つける・測るFind and measure

静的解析やコードスメルの検出、ソフトウェアメトリクスで、負債のありかと大きさをつかむ。Static analysis, code smell detection, and software metrics locate the debt and gauge its size.

返済するRepay

外部の振る舞いを保ったまま内部構造を整えるリファクタリングで、元本を解消していく。Refactoring reshapes the internal structure while preserving external behavior, paying down the principal.

予防するPrevent

レビューや規約、継続的な改善を通じて、新たな負債が無秩序に積み上がるのを抑える。Review, coding standards, and continuous improvement keep new debt from piling up unchecked.

ポイント：目的はすべてを消すことではなく、負債を「見える」状態にして、返す・残すの判断をコントロール下に置くことです。 Note: the goal is not to erase everything, but to keep debt visible so the choice to repay or defer stays under control.

研究の潮流Research landscape

「検出する系譜」と「明示された負債をたどる系譜」Two lineages, and the bridge between them

技術的負債の研究には、大きく二つの流れがあります。一つは、研究者が定義した負債（コードスメルなど）をコードから検出する系譜。もう一つは、開発者が自ら明示した負債（SATDやTD-Issue）を、テキストから同定する系譜です。近年の焦点のひとつは、この両者を橋渡しすること、すなわち開発者が認識した負債を、コードやメトリクスの側から捉え直すことにあります。 Research on technical debt runs along two broad lineages. One detects debt as defined by researchers, such as code smells, from the code itself. The other identifies debt that developers made explicit, such as SATD and TD-Issues, from text. A current focus is bridging the two: capturing the debt developers recognize from the side of code and metrics.

検出する系譜: コードスメルや構造指標から、負債候補を機械的に見つけるThe detection lineage: finding debt candidates mechanically, from code smells and structural metrics
たどる系譜: SATD・TD-Issueなど、開発者の言葉で明示された負債を同定するThe tracing lineage: identifying debt made explicit in developers' own words, as SATD and TD-Issues

木村の研究との関係Where my research fits

このサイトの研究への入り口Entry points to the studies on this site

木村祐太の研究は、ここまで見てきた「認識する・測る・返す」の各段階にまたがります。関心のあるテーマから、各研究の紹介ページへどうぞ。 Yuta Kimura's research spans the stages seen above, from recognizing debt to measuring and repaying it. Start from whichever theme interests you.

メトリクスによる分類・特徴づけClassifying debt with metrics

ソフトウェアメトリクスから技術的負債を分類し、特徴づける。Classifying and characterizing technical debt from software metrics.

返済とリファクタリングRepayment and refactoring

負債がどのように返済されるのか、リファクタリングの実態を追う。How debt is repaid in practice, tracing real refactoring activity.

TD-Issue の自動分類Automatic TD-Issue classification

課題管理システム上で明示された負債を、自動で見分ける。Automatically identifying debt made explicit in issue trackers.

自動生成パッチと品質Auto-generated patches and quality

自動生成されたパッチが、コード品質や規約とどう関わるか。How automatically generated patches relate to code quality and standards.

研究一覧を見るSee the research 全業績リストへFull publication list