0026. 技術的負債

みなさんこんばんは、きみのぶです。
今日はTwitterで技術的負債という言葉が飛び交っていましたね。ということで、僕もはやりの言葉を拾ってみようという試みをば。

この、技術的負債という言葉ですが、世間では「スピードを重視するために発生した歪み」みたいな形でよく言われていると思います。後からリファクタリングする予算がどうの、みたいな。
僕はこれ、少し話がずれていると思っていて。

技術的負債というのは「後で返さないと複利で面倒みが増えていく」という内容であって、当然のことながらこれは返済計画とセットじゃないと手を出してはいけない事だと思っています。そういう意味ではリファクタリングする予算とか言ってる時点でそもそも負債でもなんでもなく、ただの緩慢な自殺ですね。
では、どういうときに技術的負債を負うべきか。簡単ですね。ほぼ確実に返済可能な利益が見込める時です。結果的に、ビジネス要件に間に合わせる事が利益を得るための最低条件になっていることが多いだけですね。ビジネス要件に間に合えば雑にやっていいという訳ではないんです。
この利益は別に金銭的なものだけではなく「まず納得してもらう」「見てもらう」といったようなプロジェクト上の利益であることもあります。OSSであれば「誰かが直すために、まず振る舞いとして正しく動いている状態にする」なんていう所に落ち着くかもしれません。要は目的です。雑に作りたいな、と思ったときはその目的と、目的が達成された後これが返済されうるかを考えると、やっていいかが判断できると思ってます。

また、技術的負債を作る決断を行った人は、必要なときには「返済を諦める」という決断を可及的速やかに行う必要があります。当たり前ですが転がり初めた雪玉は横に蹴り出す事でしか大惨事を防げません。突然地震が来てあれがバラバラにならないかなぁ、って思いますけど、ならないんです。だめな時は「これを捨てる」「この部分は買う」みたいな、プランBが発動できるようにしておかないと詰むだけです。

往々にして、理由のない雑さは破滅を引き起こします。何度も「もうダメだなこれ」って思って焼け野原になるのを待った身としては「計画的にやっていきましょう」という言葉に落ち着く次第です。

ちなみに僕が作っているプラグインは「いけるやろ」って感じで公開すると1時間以内にマイナーバージョンアップしますよ。

ではまた。

2022/12/22 30分