技術的負債って嫌ですね。言葉からして嫌ですね。すろっくさんです。
前提を振り返ってみると……
行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。
ちょっと調べましょうかね。
負債ってのはどうしてもサービス運用してたら生まれるし、仕方ないかな。抱えてしまった負債についてとやかく言うつもりはなくて、それがやっぱりすごい成長を経験してしまったものの運命というか宿命なんだろうなー。
じゃあ具体的にどういうのを負債っていうの？と思ったら藤川さんがいい感じに書いてくれてた。
負債とは、合理的に評価できる確実性の高いものだけが負債として計上されるのだそうです。
決して言葉遊びをしているわけではないのですが、会計上の負債というのは資産の一部であり、新しいお金を生むための源と言われています。
つまり、
技術的負債は、その負債が実資産を産んでいて、その生産プロセス上で損失が生まれるからこそ、返済すべき負債としてふさわしい
ということじゃないですかね。
特に新規事業やスタートアップについては、まだ事業化や事業化の種になっていないフェーズ、とりわけ少人数の時に、少しいきあたりばったりに作ったコードを技術的負債と呼ぶには少し早いですね。
実際の所、技術的負債が実際の負債として影響が出るのは、そのコードを繰り返し編集すると言ったケースで無駄な工数が繰り返し発生したり、バグを誘発しやすいコードだったりと、損失が発生する事実に対して、負債が表面化するわけですよね。
スタートアップや新規事業に限った技術的負債の考え方 fs Garage
僕はこれにAgreeです。
なので、負債と僕が呼ぶのは
- 動いているが、運用がすごく面倒くさい / つらい
- バグが発生しやすい
- 工数が果てしなく無駄
とかね。とりあえず動いていて、滅多に誰も触らないようなところとかはとりあえずまだいいです。ただソースコードは古くなるんで、どっかで書き直さないとあかんです。Railsとか最たる例ですね。Ruby関連はこまめなアップデートかけないと、本当にエンジニアが作業しづらくなります。でも、ね。
Rubyのバージョンって一年になんどあがるのかな。スタートアップの結果がわかるまで一年、として、一年でRubyのバージョンって何回あがるのかな。もちろんクリティカルに技術的負債が作業効率に影響及ぼしてたり、DXを最悪にしてるなら早めの返済はいいけれど、その会社、何年続いているんですか？って思う。
作るときに最新版つかわなかったならそれはそれで、技術的負債が生まれることが問題なんじゃなくて明らかにエンジニアの怠慢であり設計ミスな気がします。技術的負債が生まれづらい設計をしないと、そんなの言語に関わらず負債になるに決まってます。
だから、価値創造も大切だし、前に進むのも大事。
だけど、攻守のバランスをとることができないエンジニアリングが不幸を招くのだと思います。この場合の不幸は、技術的負債によって、全体の作業効率を下げたりバグが発生しまくったり、誰も理解できない仕様だったり、ということだと思います。で、毎日仕事していて、毎日触れていたら「ここ、いつか問題になるよね……」っていう勘所って大体つくようになりそうな気がしてます。
僕の経験からいうと社会人はいった頃からそういう勘所は自分は鋭かった感じがします。ただそれって勘でしかないしすごく説明しづらい。僕の勘は「野球の外野手が、ボールが打ち上がった瞬間外野フライになったことを見て、音と曲線から落下点を予測する」っていう感じの勘所です。で、これっていっつも障害や負債になりそうなやつに対して反応するんだよねえ。
話がそれた。まあ、そういう問題になりそうな勘所を発揮できるようになれば技術的負債の返済ってのはあとは優先順位と時期的な話、そして判断だけだと思います。そこはもうCTOの仕事だからなあ。技術責任者はそういったバランス＝価値創造にも、技術に対しても無関心ではいけないと思う。あーごっつたべたい。
ただこれって経営的にも株主的にも理解される話ではないから、説明難しいね。
ただ、結局プライオリティと作業工数、価値創造とのバランスをエンジニアが理解しないで負債は返すべきってところに注力しちゃうと、会社、特にスタートアップでは不幸になるような気がしてならないね。もちろん、逆も言えるのだけど。