技術的負債（Technical Debt）

そもそもこのワードはなにか

"Technical Debt"

いつのまにかTechnicalがついた

実はWard Cunningham氏本人がDebtのメタファーの話を解説している

https://ricapitolare.vercel.app/svg?url=https://wiki.c2.com/?WardExplainsDebtMetaphor#.svg https://wiki.c2.com/?WardExplainsDebtMetaphor

https://ricapitolare.vercel.app/svg?url=https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor#.svg https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor

このページ以外での歴史と考察はこちらが詳しい

https://ricapitolare.vercel.app/svg?url=https://qiita.com/blue32a/items/cb350772f8c4c5897b0a#.svg https://qiita.com/blue32a/items/cb350772f8c4c5897b0a

負債のメタファーの源流を整理する

Ward Cunningham氏は負債のメタファーに「負債・スピード・負担・アジリティ」の4つの視点を持っている

このメタファーが生まれた状況の前提

負債の視点

ドメイン知識と実装が乖離していくこと——それが生産性の障害になることを指していた

この状態のことを「払っても払っても追いつかない＝利子を払い続けている」と比喩表現した

スピードの視点

借入をすれば物事をより早く前に進めることができるようになりますが、そのかわり返済し終えるまでは利子を払い続けることにもなります。

ごく一般的な認識で、お金を借り入れることで事業スピードを上げられたりする。そして返済がつきまとう。

わからないまま手をこまねいているより、市場からフィードバックを得る——そのための加速装置として借り入れるのはポジティブな行為だということ

ここでいう借り入れは 『現時点での理解で目の前の問題に対するコードを書くこと』

つまり市場のニーズの解消にクリティカルな実装じゃないかもしれないが、それでもコードを書いてデプロイするということ

負担の視点

長い間プログラムにただ機能を追加するのみで、それら機能に関して学んだ知識を反映する整理整頓を怠っていたならば、次第にプログラムからは知識が失われ、作業にかかる時間はひたすら長くなっていきます。言い換えるなら、すべて利子で食い潰され、進捗はゼロに近づいていくでしょう。

つまり『行為として借り入れるだけで返済しない——得たドメイン知識と現実装との乖離の解消を怠ると生産性が低下していく』ということ

アジリティの視点

私は雑なコードを書くことには全く賛成しませんが、たとえ理解が不完全だとしても、目の前の問題に対する現時点での理解を反映するコードを書くことには賛成です。

理解が不完全な段階でもソフトウェアを開発して借入をできるようになりたいならば、そのソフトウェアに現時点での理解を可能な限り反映させることが重要です。

そうしておけば、いざリファクタリングをするときが来たなら、コードには当時何を考えていたかが明快に残っているので、現在の理解に合わせてリファクタリングするのも容易になります。

「正しいドメイン知識と実装が一枚岩になっていなくとも、どうして動いているかわからない状態でなければリファクタリングはできるだろう」ということ

そもそも何度も借り入れと返済を繰り返すなら、それができる状態であらねばならないということ

そのためにはめちゃくちゃな設計・実装ではいけないということ

後述する"廃墟"では何度も借り入れと返済を繰り返せないため、負債のメタファーとはもう別次元にいる

要約すると

"借り入れをする"とは

『現時点での理解で目の前の問題に対するコードを書くこと』

あるいは『市場からフィードバックをもらい問題を知るために現時点での理解でコードを書くこと』

"返済をする"とは

『借り入れた結果で得たドメイン知識と現実装との乖離を解消するリファクタリングをすること』

プロダクトの推進とリファクタリングのサイクルと生産性の維持を金融プロダクトだったから負債というメタファーで表現したまで

返済できる状態であり続けるにはクリーンなコードでないといけない

このワードはメタファーでしかない

『プロダクトの推進とリファクタリングのサイクルと生産性の維持』というソフトウェアプロダクトの開発に付きまとう"過酷で根深い問題"——このあるある話を単語で表現しているに過ぎない

https://ricapitolare.vercel.app/svg?url=https://bliki-ja.github.io/TechnicalDebt#.svg https://bliki-ja.github.io/TechnicalDebt

https://ricapitolare.vercel.app/svg?url=https://bliki-ja.github.io/TechnicalDebtQuadrant#.svg https://bliki-ja.github.io/TechnicalDebtQuadrant

設計の不備が負債かそうじゃないかなんて考えることが、そもそも間違ってると思う。 技術的負債というのはメタファなのだから、 ここで問うべきなのは「負債のメタファは、 設計上の問題を考える助けになるだろうか？ そして、他人と意見交換しやすくなるだろうか？」だ。 負債のメタファを使う大きなメリットは、 技術者以外にも話が通じやすくなることだろう。

あくまでメタファーなのだから、このワード単体で世界中の様々な現場で発生する問題の原因や種類やコンテキストを100%ズレなく捉えられるはずがそもそもない

いまあなたがメタファーとして指しているものはなにか

技術的負債というワードを持ち出すときメタファーとして指したいなにかしらの問題があるはずで、このワードを使う以上は、その問題はなにかを正しく捉えたほうがよい。

源流であるWard Cunningham氏が「ドメイン知識と実装の乖離の問題」を抱えていたときにそれを"Debt"と表現したように問題自体を正しく捉えられないといけない。

技術的負債というワードが使われるとき、すでに借りる・返すというサイクルから逸脱した問題を指しているケースは多いと感じる

例えば「今のままで事業をドライブさせるだけの資本"しかない"」とか

リファクタリングだとか機能の刈り取りだとかリアーキテクトだとか、そういったことに組織が手や頭を働かせることができない貧血状態に陥っているケース

例えば「外部依存していてあと6ヶ月で動かなくなる機能」とか

経緯としては負債のメタファーを経て出来上がった問題かもしれないが、論じているときはすでに次元が異なっているケース

負債のメタファーを使わないほうがいいケースも当たり前にある、という例

技術的負債なのではなく、貧乏だから廃墟に住み続けているのだという正しい認識が必要

おそらく皮肉を込めての発言だと思うが、状況を正しいメタファーで表すことの大切さも同時に発現されている

負っているとして、では技術的負債はどこから何を借り入れているか？

将来のメンテナビリティないしはリファクタリングの工数から借り入れていると言えるのではないか