技術的負債という言葉を本来の意味以外で使わないようにしよう
技術的負債という言葉を本来の意味以外で使わないようにしよう
言葉の定義が間違っているからっていう理由ではありません。
技術的負債を詳しく知りたい方は、このブログよりも t-wada さんのブログ【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明を読んでください。
Ward Cunningham 氏はなぜ後悔しているのか
Ward Cunningham 氏が金融系ソフトウェア（WyCash）を開発していた頃に思いついた比喩です。
お金を借りて、事業をいち早く拡張し、それによって収益を増やすことで、利子を返済してもよりたくさんの収益が得られるからってやつです。多分ですけど。
「技術的負債」という言葉が、メンテナンスできないコードを許容する言い訳に使われていることを嘆いているようです。
返済するつもりもないのに「技術的負債だから」と言い、メンテナンス可能なコードにし続けるのはエンジニアとして当然のことなのに、それすら怠る言い訳になってしまっているのです。
金融の負債と比べてみる
まず、本来の意味での技術的負債は金融の負債とだいたい同じなわけです。
| 金融の負債 | 技術的負債（本来） | |
|---|---|---|
| 借りた額 | 分かっている | 分かっている |
| 利子 | 分かっている | 分かっている |
| 返済金額 | 分かっている | 分かっている |
| 返済計画 | ある | ある |
| 最終的に | いいことになる | いいことになる |
まあ、最終的にいいことになるかはわからないですが、そこを目指しているのは同じでしょう。
では、誤用されている「技術的負債」はどうでしょうか。闇金と比べてみます。
| 闇金 | 技術的負債（誤用） | |
|---|---|---|
| 借りた額 | 分かっている | 分かっていない |
| 利子 | 分かっている | 分かっていない |
| 返済金額 | 怪しい | 分かっていない |
| 返済計画 | 怪しい | ない |
| 最終的に | やばい! | やばい! |
リボ払いと比べても同じです。
| リボ払い | 技術的負債（誤用） | |
|---|---|---|
| 借りた額 | 分かっている | 分かっていない |
| 利子 | 分かっている | 分かっていない |
| 返済金額 | 怪しい | 分かっていない |
| 返済計画 | 怪しい | ない |
| 最終的に | やばい! | やばい! |
闇金やリボ払いを利用する人は、返済額を認識できてなくて返済計画も立ててない人もいると思います。しかし、返済をしようと思えば返済金額を調べることはでき、返済計画を立てられるわけですし、返済ができないという結論も出せるわけです。
技術的負債 (誤用) は軽い問題とみられてしまう
誤用の方の技術的負債という言葉は、かえって軽い問題だと思われている節があります。
- 技術的負債という言葉のせいで、技術者だけの問題だと認識されがち
- いくら借りてるかすらわからないのに、さも金額が分かっている印象になる
技術的闇金とネタで言う人も多いんですが、返済金額が分かる闇金の方がまだましです。
強引に例えるなら、息子が知らないうちにあちこちの消費者金融で借金をしていて、それを肩代わりするようなものです。あとからあとから適当な借用書が出てきて、闇金やリボ払いに知人からの借金などなど、当初思ってた金額の何十倍や何百倍に膨らんで終わりが見えない状況ですかね?
誤用の方で使ってしまうと、問題の本質を見失ってしまいます。誤用の方は組織全体で取り組まないと解決できません。
じゃあ何て呼べば?
じゃあ何て呼べば? って話なんですが...
いい言葉がないんですよね... 一部で言われてる技術的闇金でも生ぬるいと思うんですよね。そもそも技術的ってつけると技術者だけの問題だととらえられるしねぇ...
うーん...
最後に
どう呼ぼうと、やらないといけないことは変わりません。表面上の言葉の印象につられないようにし、現状の問題ってなんなのか? ってのを常に追い求める必要があります。
Discussion
変えるとしたら以下ですかね？
技術的負債(本来)→リファクタリング引当金
(ちゃんと計画して見積もってるので)
技術的負債(誤用)→技術的簿外債務
(負債であることは間違いないが計上されてない＝いくらあるかもわからなければ返済計画もない)
この記事筆者の @masakura さんが理解している「技術的負債」の言葉の定義とは何でしょうか？
どのような定義を前提として書かれた記事なのかを明確にして頂きたいです。
t-wada さんのブログには直接的に「技術的負債」の定義について書かれていません。
間接的な表現になっています。
人によっては理解が異なり、言葉の定義がブレる可能性があります。
私が読み取った内容と、この記事筆者の @masakura さんが理解している定義が異なってはそもそも話になりません。
また、時間が経過すると元の記事も何らかの事情で閲覧できなくなる可能性があり、この記事は意味をなさなくなります。
定義についての記事なので、この記事内で定義を明確にして頂く必要があると考えます。
金融での比喩表現ではなく、どのような「技術的負債」の定義が本来の定義で、どのような「技術的負債」の定義が誤用されているという前提の記事なのか明確に書いていただきたいです。
技術的負債の云い替えとして「足枷」を推しまする。
歩行速度と開発速度が遅くなる点で類似なので。
とても面白い内容でした！
本質的には、技術的負債と呼ぶことは「組織全体の問題を技術者だけの問題に矮小化してしまう」ということかなと理解しました。組織やチーム全体として意思決定して借りたものであるのに、「技術的」というだけでエンジニアだけが返す形になってしまうと、優先順位が上がらず利子が溜まり続けてしまいますね、、
また、エンジニアが独断で負債を積んでしまうケースもあり、借りる判断も返す判断も、本来は組織・チーム全体で行うべきなのかなと思います。(ビジネス上の期限と技術的な設計の兼ね合いから行われる判断など)
参考記事にもある通り、返済可能なしっかりとした設計を前提として、実務的にあえてアンチパターンを取るなど、意図を持った設計が重要だと感じました。本来はこのように考えるべきが、エンジニア側が雑さを許容する際の言葉として使ってしまうことが問題というわけですね、
一点、言葉尻の話になってしまうのですが、闇金も一種の負債であって、計画的に返済できるものだけが負債ではないのかな、と思いました。その意味で、雑な設計実装も技術的負債と言えるのかなと。すでにそう広まってもいますし、理論的にもそう捉えられると思います。
であれば「技術的負債には2種類ある」という枠組みの方が、かえってわかりやすいかなと思いました。
計画的負債：返済見込みがあり、意図的に取った借金（資本的）
無計画負債：返済額も計画もなく積み上がったもの（闇金型）
この2つを区別して「後者は避けよう、あるいは前者に転換しよう」と言う方が、現場での会話としても使いやすいと感じました！
この本文の主張はよくわかりません。
多くの開発者にとってCunningham氏の「経営層への説明手法」よりも『達人プログラマー』で提示した「コードの品質を維持し将来の自分を助けるためのエンジニアの習慣」という文脈のほうがしっくりきます。
いまはこっちの解釈が普通でしょう。
金融用語としての「負債」は返済から逃れられない重苦しさがありますが、『達人プログラマー』では負債を「戦略的に負うもの」と捉える余裕が生まれます。「今はスピードを優先してあえて負債を抱えるが、後で必ずリファクタリングで解消する」というプロフェッショナルとしての判断を肯定できるようになったからです。
「負債」という言葉を使うことで、完璧主義に陥りがちな開発者が完璧ではない今の実装を認めた上で、いつかより良くするという意識をもてるようにしています。
経営者のための恐怖のメタファーではなく、プログラマーのための仕事の組み立て方のメタファーになったことこそが、この言葉が現場で使われている理由かもしれませんね。