技術的負債とは？新機能とどちらを優先するかの判断軸をわかりやすく解説
「技術的負債を返したいのに、新機能の要望に押されて時間が取れない」
「リファクタリングの必要性を説明しても、なかなかわかってもらえない」
こうした悩みの多くは、技術的負債と新機能を、別々の物差しで測っていることから生まれています。
技術的負債と新機能は、対立するものではありません。どちらも顧客価値を高めるための投資です。
優先順位は、「いま達成したいことに、どちらがより近づくか」という同じ基準で判断できます。
この記事では、技術的負債の意味と例から、新機能との優先順位の判断軸、現場でのつまずき、AI時代の向き合い方までを解説します。
リファクタリング（プログラムの動作を変えずに、コードの中身を整理すること）の具体的な手法や、計測ツールの設定は扱いません。
技術的負債と新機能の判断軸
この記事を読んで、「うちのチームもこの状態かもしれない」と感じた方もいるのではないでしょうか。
技術的負債と新機能の優先順位で迷うとき、その原因は「別々の基準で比べている」ことにあります。
こうした判断の観点を整理した資料を用意しています。気になる方は確認してみてください。
＼ 登録不要・無料でダウンロードできます ／
技術的負債とは？
技術的負債は、言葉だけが広まり、意味がずれて使われやすい概念です。
まずは基本を次の3つに整理します。
- 技術的負債は、将来の変更を重くする「前借り」
- 意図して借りるものも、気づかないうちにたまるものもある
- もともとビジネス側と話すための言葉だった
まずは用語の位置づけから見ていきます。
1. 技術的負債は、将来の変更を重くする「前借り」
技術的負債とは、将来の変更を難しくしたり、手間を増やしたりする設計や実装のことです。いまのスピードと引き換えに、将来の手間を背負うという意味で「前借り」と言えます。
お金の借金と同じように、技術的負債には利息がつきます。整理されていないコードの上に機能を足すたびに、理解や確認に余計な時間がかかります。この余計な時間が、利息にあたります。
たとえば、次のようなものが技術的負債の例です。
- 同じ処理があちこちにコピーされていて、1か所を直すと他も直す必要がある
- 自動テストが足りず、変更のたびに手作業での確認が増える
- サポートの切れた古いライブラリ（外部から取り込んで使うプログラムの部品）を使い続けている
2. 意図して借りるものも、気づかないうちにたまるものもある
技術的負債には、締め切りに間に合わせるために、意図して借りるものがあります。「今回はこの形でリリースして、あとで整理する」という判断です。
一方で、気づかないうちにたまるものもあります。開発を進めて理解が深まると、書いた時点では最善だった設計が、いまの状況に合わなくなっていきます。使っている技術のサポート終了など、環境の変化から生まれるものもあります。
多くの負債は、その時点での判断の結果として積み上がっていきます。
3. もともとビジネス側と話すための言葉だった
技術的負債という言葉を生んだのは、ウォード・カニンガム（Ward Cunningham）氏です。1992年の学会での報告で、初めてリリースするコードを借金にたとえました。
当時、彼は金融系のシステムを開発していました。上司に説明する必要があったのは、リファクタリングに時間を使う理由です。そこで、金融の世界になじみのある借金にたとえたと本人が語っています。
また彼は、このたとえを「雑なコードを書いて、あとで直せばいい」という意味で使ったわけではないとも説明しています。
つまり技術的負債は、もともと開発者とビジネス側が同じ言葉で話すために生まれた表現です。
この視点が、新機能との優先順位を考える出発点になります。
技術的負債と新機能、どちらを優先する？
私たちがよく受ける質問の一つが、「新機能と技術的負債、どちらを優先すればいいのか」です。
答えを出すための考え方を、次の2つに分けて整理します。
- 判断軸は「いま達成したいことに、どちらがより近づくか」
- 技術的負債の解消も新機能も、顧客価値への投資
まずは判断軸から見ていきます。
1. 判断軸は「いま達成したいことに、どちらがより近づくか」
常に新機能を優先するのも、常に技術的負債を優先するのも、うまくいきません。優先順位は、チームがいま何を達成したいかによって変わります。
たとえば、新しい顧客を増やしたい時期であれば、新機能のほうが価値を生みやすくなります。一方で、次のような状態がいま達成したいことの妨げになっているなら、技術的負債の解消のほうが価値につながります。
- リリースに時間がかかる
- 障害が多い
- 小さな変更にも手間取る
迷ったときは、「これをいまやらなかったら何が困るか」を、新機能と技術的負債の両方に問いかけてみてください。同じ問いを当てることで、両者を同じ基準で比べられるようになります。
重要なのは、どちらを優先するかを先に決めておくことではなく、いま達成したいことに照らして判断し続けることです。
2. 技術的負債の解消も新機能も、顧客価値への投資
新機能は、顧客に新しい価値を直接届けます。技術的負債の解消は、その価値を届けるスピードと確かさを支えます。形は違っても、どちらも顧客価値を高めるための投資です。
設計の分野で知られるマーティン・ファウラー（Martin Fowler）氏は、質とコストの関係について、コードの中身の質を高めると、むしろ開発のコストが下がると説明しています。
整理されたコードの上では、新しい機能を早く、少ない手戻りで足せるからです。
技術的負債の優先順位で、現場がつまずく3つのパターン
判断軸がわかっていても、現場では新機能と技術的負債をうまく比べられないことがあります。
よく見られるのは次の3つです。
- 新機能だけを優先し続ける
- 技術的負債の解消だけに集中する
- プロダクトオーナー（PO）と開発者が別々のものを見ている
自分たちのチームに当てはまるものがないか、確かめながら読んでみてください。
1. 新機能だけを優先し続ける
新しい要望が次々に入り、技術的負債の解消がいつも後回しになるケースです。最初は問題がなくても、後回しが続くと、少しずつ変化が現れます。
リリースまでの時間が延びる、不具合が増える、見積りが当たらなくなる、といった変化です。やがて、新機能を届けるスピードそのものが落ちていきます。
2. 技術的負債の解消だけに集中する
逆に、品質改善や設計の見直しばかりが続くケースもあります。開発者にとって意味のある作業でも、顧客にとっての変化が見えにくく、その時間を使った理由を説明できなくなります。
技術的負債の解消も、それ自体は目的ではありません。価値を届けるための手段です。
3. プロダクトオーナー（PO）と開発者が別々のものを見ている
何をつくるかを決めるPOは新機能を、どうつくるかを担う開発者は技術的負債を見ている、という状態です。見ているものが違うと、優先順位の話し合いは「どちらの言い分を通すか」という対立になりやすくなります。
共通するのは、新機能と技術的負債を、別々のものとして扱っている点です。
本来は、「どちらが顧客価値につながるか」を一緒に考える場です。
スクラムでは、POが「何をつくるか」を決め、「どうつくるか」は開発者に委ねます。
役割を分けたうえで、POが優先順位にどう責任を持つのかは、以下の記事で解説しているので、参考にしてください。
技術的負債を価値で説明できるチームは、何をしているのか？
新機能と技術的負債をうまく比べられているチームには、共通点があります。
自分たちの状態を見直すための問いとあわせて、次の3つを紹介します。
- 技術的負債の解消を、顧客に届く変化に言い換えている
- 技術的負債も、新機能と同じリストに並べて比べている
- あなたのチームは、技術的負債を解消する理由を説明できますか？
まずは言葉の使い方から見ていきます。
1. 技術的負債の解消を、顧客に届く変化に言い換えている
うまくいっているチームは、技術的負債の解消を「コードがきれいになる」で終わらせていません。解消した結果、顧客や事業に何が起きるかまで言葉にしています。
たとえば、次のような言い方です。
- リリースにかかる時間が半分になる
- 同じ種類の障害が起きなくなる
- 新しいメンバーが早く開発に加われる
「技術的にきれいにしたい」という理由だけでは、優先順位はなかなか上がりません。POも開発者も、顧客価値という共通の言葉で話せるようになると、技術的負債は新機能と同じ土俵に乗ります。
共通の言葉で話すことは、技術的負債という言葉が生まれたときの使われ方そのものです。
2. 技術的負債も、新機能と同じリストに並べて比べている
技術的負債の解消を別枠の作業にしていると、いつまでも優先順位の話し合いに乗りません。うまくいっているチームは、技術的負債の解消も、新機能と同じ優先順位リストに並べています。
スクラムでは、この優先順位リストをプロダクトバックログと呼びます。技術的な改善や不具合の修正も、その大切なアイテムです。同じリストを見ながら話すと、「この新機能と、この改善のどちらが先か」を具体的に比べられます。
技術的な改善を新機能と同じリストで比べる考え方は、以下の記事でも取り上げています。「これをいまやらなかったら何が困るか」という判断の問いも共通です。
3. あなたのチームは、技術的負債を解消する理由を説明できますか？
次の3つのうち、1つでも当てはまらないものがあれば、新機能と技術的負債を同じ基準で比べられていない可能性があります。
- いま抱えている技術的負債が、どんな問題を引き起こしているか説明できる
- その負債を解消すると、何が良くなるかを説明できる
- 新機能と技術的負債のどちらがいま達成したいことに近づくか、チームで話せている
まずは、チームが気になっている技術的負債を1つ選び、「解消すると何が良くなるか」を書き出してみてください。
AI時代に技術的負債との向き合い方はどう変わる？
AIを使った開発が広がり、技術的負債を取り巻く状況も変わり始めています。
変化のポイントは次の3つです。
- 開発が速くなるほど、負債の利息も速くふくらむ
- コードだけでなく、判断の記録も古くなる
- 小さいうちにすぐ返す判断が、価値につながりやすくなる
判断軸そのものは変わりません。変わるのは、比べたときの結果です。
1. 開発が速くなるほど、負債の利息も速くふくらむ
AIを使えば、コードを書くスピードは大きく上がります。その分、整理されないまま積み上がるコードも速く増え、負債の利息がふくらむスピードも上がります。
アジャイルソフトウェア開発宣言の起草者の一人であるケント・ベック（Kent Beck）氏は、AIと進めた開発の経験を記しています。AIは複雑さを減らさずに継ぎ足しを重ね、最後には次の機能を正しく実装できなくなったといいます。
AIが書くコードの質そのものは、上がってきています。ただ、日本におけるTDDの普及・実践を牽引してきた和田卓人氏は、AIに任せるだけではコードの保守性は高まらず、結果として開発速度にも悪影響を与える可能性を指摘しています。
技術的負債の利息は、AIの作業にもかかるようになりました。
生成AIの出力は、確かめずに使うと誤りを速く積み上げてしまうこともあります。速さと品質を両立させるための確認の組み込み方は、以下の記事で解説しています。
2. コードだけでなく、判断の記録も古くなる
実際に現場では、AIで開発が速くなったことで、こんなことが起きています。issue（問題などを記録するチケット）に残した仕様が、1週間後にはもう古くなっている。
そして、issueを書き直すという作業が新たに発生する。この書き直しの手間は、判断の記録にたまった負債、つまり意図負債の利息です。開発が速いほど、記録と現実のズレも速く広がります。
「なぜそう決めたのか」という判断の根拠や目的、前提が記録されていない、または記録が古くなっている状態のことです。コードにたまる技術的負債に対して、判断の記録にたまる負債と言えます。
あとから意図を取り戻すのは難しく、ときには不可能になります。AIで判断の数とスピードが増えたいま、その瞬間は逃しやすくなっています。
3. 小さいうちにすぐ返す判断が、価値につながりやすくなる
AI時代の技術的負債は、利息がつくスピードが速くなる一方で、返すためのコストは下がりつつあります。
ウォード・カニンガム氏は1992年の報告で、すぐに書き直して返すなら、少しの負債は開発を速めると書いていました。AI時代は、この「すぐに返す」ことの価値がいっそう高まっています。
これは、常に技術的負債を先に返すという意味ではありません。判断軸は変わらず、「いま達成したいことに、どちらがより近づくか」です。
ただ、同じ軸で比べたときに「小さいうちにすぐ返す」ほうが達成したいことに近づく場面は、以前より増えています。
重要なのは、負債を「あとでまとめて返すもの」として積み上げず、見つけた時点で優先順位リストに乗せることです。
変更のたびに「壊すのが怖い」と感じる状態は、それ自体が負債のサインです。
テストで「安心して変更できる状態」をつくる考え方と、生成AIにテストを書かせたときの注意点は、以下の記事で解説しています。
技術的負債に関するよくある質問
技術的負債について、よく寄せられる質問をFAQ形式で整理しました。
技術的負債は英語で何と言いますか？別の言い方はありますか？
英語ではTechnical Debtと言います。
言い換えるなら「将来の変更にかかるコストの前借り」です。「負債」と呼ぶのは、借りたら返すという判断がセットになっているからです。
技術的負債はゼロにしたほうがいいですか？
ゼロを目指す必要はありません。まず試して学ぶために、意図して負債を借りることは有効な判断です。
問題になるのは、借りたことを忘れて、返す判断をしないまま放っておくことです。借りたときに「なぜ借りたのか」「いつ見直すのか」を残しておくと、あとで返す判断がしやすくなります。
技術的負債はどう測ればいいですか？
コードの複雑さを数値で示すツールもありますが、最初は開発者の困りごとを言葉にすることから始めるのがおすすめです。
「この機能を変えるたびに不具合が出る」「ここは怖くて触れない」といった声は、負債のありかを示すサインです。そこに、リリースにかかる時間や障害の件数など、チームがすでに見ている数字を結びつけると、価値として説明しやすくなります。
古いシステムは、少しずつ返すよりつくり直したほうがいいですか？
つくり直すか、少しずつ返すかに決まった正解はありません。ここでも、いま達成したいことにどちらがより近づくかで考えます。
つくり直しは、完成するまで新しい価値が届かない期間が長くなりやすい進め方です。少しずつ返す進め方なら、途中でも改善を顧客に届けながら進められます。つくり直しを選ぶ場合も、小さく区切って途中で価値を確かめられる形にすると、判断を修正しやすくなります。
まとめ
技術的負債は、将来の変更を重くする「前借り」です。そしてその解消は、新機能と同じく、顧客価値を高めるための投資です。
重要なのは、「いま達成したいことに、どちらがより近づくか」を、POと開発者が同じ言葉で判断できる状態をつくることです。
最初から、負債の大きさを正確に示せなくても構いません。判断を重ねる中で、チームに合った説明の仕方が見えてきます。
まずは、チームが気になっている技術的負債を1つ選び、「解消すると何が良くなるか」を書き出してみてください。
書き出した内容を新機能と並べて判断するには、プロダクトの価値と優先順位に責任を持つ視点が欠かせません。判断の仕方を実践的に学びたい方は、CSPO認定スクラムプロダクトオーナー研修の受講を検討してみてください。
