技術的負債というメタファ

技術的負債についてはじめて知ったのは、マーチン・ファウラーの「技術的負債」というエントリーでした。

システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。
「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンなどスの負債と同じく）技術的な負債が発生する、ということになる。通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。
(中略）
このメタファーを使うと、早いけれど汚い方法がなぜよく使われるのか、ということを説明できる。ビジネスの世界で市場機会の優位性を得るために負債を負うのと同じように、開発者たちは重要な納期に間に合わせるために、技術的負債を負うことがある。ただ、あまりにもよく見受けられる問題は、開発組織は自分たちの負債をコントロールできなくなり、将来的な開発作業の多くを利子を払い続けるということに費やさねばならなくなる事だ。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=TechnicalDebt&key=%B5%BB%BD%D1%C5%AA%C9%E9%BA%C4

ソフトウェアに対する機能修正を行う際（これは機能追加だけでなく、仕様バグ・設計ミス（仕様の認識間違い）などによる機能修正も含む）、「汚いけれども早いやり方」を選ぶ場合、その早さの代償としてソフトウェアが背負うものを「負債」に喩えたものです。

かつてわたしが師匠の元ので組込みソフトウェアを開発していた際、テストフェーズ以降に発生した修正については、設計上正しくはないけれども修正による影響範囲が最小で、素早く修正出来る方で修正していました。この項目についてはかならすメモを取り、納品（リリース）後だいたい1週間という期間を切って、その期間無いで出来るのであれば綺麗な修正に置き換えました。できない場合は本来やるべき綺麗な設計をドキュメントに残しました。

リリース後のコードから「汚い部分」を取り除く作業を、師匠のチームでは「ブラッシュアップ」と読んでいて、かならすそこまでを工数としていました。

もし、本当に納品したソフトウェアがそれっきりのものであった場合、この1週間の工数は払うべきでないのかもしれません。しかしリリース後に出てきた「要望」に対応したり、そのソフトウェアを土台として新たなソフトウェアを作るということは、実の所、よくあることです。

そして、どうせ技術的負債を返すならば、そのソフトウェアのことを覚えている内に返してしまうのが一番です。日を於けば忘れてしまうことで、思い出したり、理解する工数が発生してしまいます。だからリリース後すぐにブラッシュアップするのが一番オトクです。徹底的に合理的であった師匠らしいプロセスでした。

しかしこれを独り立ちしたわたしがやろうとするときに立ちふさがる「そういう事態が発生してからで良いじゃん」という意見は「動いているならそれが正しい」「汚くっても正しく動くならなにが問題あるのか」という観念と深く結びついて、そういうことを肌で知っている人以外に、うまく納得させることができるのかというと、難しいな、と思っていました。

後日この「技術的負債」というメタファーを知ったと時、この払うべきコストを「わかっていない人」に「払うべきだ」と納得させるのに、とても良いメタファーだと感心したのを思い出しました。

* * *

JavaBlack さんの「技術的負債は避けるべきか？」もちろんです． - カレーなる辛口Javaな転職日記を読んで、そんな師匠とのきゃっきゃっうふふなエピソードを思い出しました。

その必要性を理解出来てない人に説明するのに「うまく出来ているな」と思われたメタファーを逆手に、「返さなくていい条件はいずこ」と考察する okuさんのエントリーはある意味びっくりでした。読み物としては面白いと思ったのですが、はたしてこの「負債」というメタファーはそこまでの検証に耐えるほど、きちんと「負債」のモデルに乗れるものなのか。

技術的負債というメタファで大切なところは、

早くて汚い修正の対価は「負債」に似ている
「負債」を抱えるという選択肢はもちろんあるが、「負債」には利子が発生する
「負債」を抱えすぎるとやがて返済不能に陥る。

というところだと思います。

上記エントリーに対する個人的な見解は、技術的負債は「最初から汚い設計」の問題点を語るためのメタファにはあまりふさわしくはないのでは？、です。Smart UI を選ぶべきシチュエーションの考察において、「技術的負債」というメタファを持ち出すことは、モデルとしてあまり有益には感じません。

「プレハブ小屋でよいところに立派な家を立てる必要がない」という程度のお話に「負債」というメタファが登場する必要性をあまり感じないからです（負債云々の前にプレハブ小屋は構造的に増築できませんし、ある程度の規模以上のものをプレハブで安全な建造物にすることはできませんから）。

※これは「顧客が本当に必要だったもの」の文脈かもしれませんね。

ですので、この文脈で技術的負債を引っ張りだすのは、言葉遊び以上の意味はないと考えますが、あえて乗っかるとするならば、利子が利子を呼び借金だるまになって首が回らなくなる様が「技術的負債」という比喩の肝だと思っておりますので、JavaBlack さんの

なんで糞コードの維持工数が「定数」なんだよ

に深く共感いたします。また、その「利子」の示すものは単に運用工数だけでなく、指数関数的に高まっていくバグの発生率という面もありますので、バグによって発生する損害という形で表面化する「コスト」もあわせて考察すると、より面白い読み物になるかな、と思いました。