最近のエンジニアの感覚だと、技術的負債というのを極端に嫌うケースがあるそうですね。
技術的負債とは…
行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。
この言葉は確かにキャッチーだ。プログラムなんて動けばいいでしょという上司に楯突く時に使いやすい武器になりそうだ。
「負債」という言葉はなかなか面白い比喩である。
では少し、負債という言葉について調べてみると、こういうのが見つかる。
負債は借入金や買掛金などの法律上の債務であるとイメージされがちですが、厳密にいったらこれは間違いです。
すなわち負債とは、法律上の債務に限らず、いずれ会社が負担することになるであろう経済的負担で貨幣額で合理的に評価できるものが該当します。
http://financial.mook.to/accounting/01/bs_03.htm
「いずれ負担することになるであろう」ってのは大切なキーワードかもなぁ。
さらに、
前述のとおり負債とは法律上の債務に限らず、企業が負っている経済的負担となりますが、将来企業が負担することになるであろう経済的負担であれば全て無制限に負債になるのではなく、貨幣額で合理的に評価できる確実性の高いものだけが負債として貸借貸借対照表に計上されることになります。
http://financial.mook.to/accounting/01/bs_03.htm
負債とは、合理的に評価できる確実性の高いものだけが負債として計上されるのだそうです。
決して言葉遊びをしているわけではないのですが、会計上の負債というのは資産の一部であり、新しいお金を生むための源と言われています。
つまり、
技術的負債は、その負債が実資産を産んでいて、その生産プロセス上で損失が生まれるからこそ、返済すべき負債としてふさわしい
ということじゃないですかね。
単純なクソコード=技術的負債、と言ってしまう人がもしいたら、それはちと大げさな表現じゃないでしょうかね。
特に新規事業やスタートアップについては、まだ事業化や事業化の種になっていないフェーズ、とりわけ少人数の時に、少しいきあたりばったりに作ったコードを技術的負債と呼ぶには少し早いですね。
実際の所、技術的負債が実際の負債として影響が出るのは、そのコードを繰り返し編集すると言ったケースで無駄な工数が繰り返し発生したり、バグを誘発しやすいコードだったりと、損失が発生する事実に対して、負債が表面化するわけですよね。
もし、まだそこまでたどり着いていないのであれば、
-x(負債) * 0(ビジネス上の価値) = 0
というのが現実ですし、その表現がいくらなんでもというのであれば、潜在的な技術的負債の候補として、解決すべき課題リストに入れておき、他の優先順位と照らし合わせながらタスク化しておきましょう。
もちろん、だからダメなコードでいいというわけではありません。限られた打席の中で、できる限り良いバットを振るのはプロの仕事なのですから。理想状態で品質とスピードが伴っていれば、技術的負債など生まれないに越したことはありません。ペアプロやコードレビューなどは、そういうのをチームワークで産まないための方法論なのですから、さまざまな取組で回避することを模索しましょう。
しかしながら、なかなか辛い事実ですが、ソースコードに対する価値は、そのコードの結果生まれるお金の価値や、利用者に提供している幸せの価値として評価されます。
ビジネスの場においては、どんなにソースコードがキレイでも、他人や社会に対する価値が生まれてなければ、評価としては0ですし、技術的負債と呼びたいコードが、沢山の人を幸せにしていたら、作り手にとってはうんざりするコードだったとしても、そのコードの価値は間違いなく高いです。そして大前提として、後者のような状態に対してのみ技術的負債という言葉が伴うのではないでしょうかね?
ちなみに家入さんがいたころの元ペパボ社員的認識で言うと、こんなことを書くと怒られちゃうかもしれないですが、家入さんの書くコードは、フレームワークなどを好む専門の技術者からして見たら、たいがいが技術的負債だったのではないかと思います。しかし同時にアイディアマン、アントレプレナーの書くソースコードとして強烈な資産価値を生む存在でもあったように思えます。そういう状況を目の当たりにしているので、そもそも技術的負債というものを全く恐れないし、むしろ歓迎だという認識が僕にはあります。サービスがスケールしそうになったら専門の技術者がコードの運用をしやすいように書き直せばいいですし、誇らしい仕事だと思います。
僕も、昔、受託の仕事をしてたころに、同僚のデザイナーが書いたFlashのActionScriptを全部書き換えて怒られたことあります。サーバサイドまで見ている僕にとってそれは技術的負債になるように見えたからです。でも、そこで表現されていたクリエイティブの価値は一切変えてないです。役割の違いにおけるソースコードの捉え方の違いというのも、技術的負債の概念には含まれていると思うんですよね。そこに慌てて返済すべき絶対的価値があるのか、他のプライオリティに対して恐れに足るものなのかは、よく考えてからこの言葉を使った方が良いと思いますね。わかってる人ならいいのですが、少し負債という言葉が強烈すぎて、技術者としての体質が弱くなるように思えてなりません。
追記;
そもそも負債という表現は、理解に求められるコンテキストが難解だと思ってます。それこそ「借金、すぐに返さなきゃ怖い!死ぬ!」って思っちゃう人か、経営者のように借りられる時に借りる意味や、そのメリットを知ってる人とは決して同じ価値を共有できない言葉ですし、前者の方がエンジニアの性格上近しいと思っています。これが技術的負債というキーワードが、業界的によくないと思っている部分です。
また、今すぐユーザ情報が流出するようなセキュリティホールは負債でもなんでもなくて、ただの欠陥ですので、判明したら、すぐに直しましょう。負債というのは、wikipediaでの説明からも、現時点での返済や改善を留保した決断を内包しているのは明らかです。
現場のエンジニアにとって、自分の思い通りにならない会社の決断がむかつく、という愚痴ワードに見えることも多々有ります。そういう曖昧なものだからこそ、技術的負債というキーワードが「エンジニア界隈」にとってキャッチーなものだったのだと思うのですが、いずれにせよ今すぐ返さなくても良いという言い分も併記されてないと、状況が不適切なのか否かは、外野からは絶対に判断できません。
その上で、僕が個人的に思うのは、こういう愚痴みたいな意味が内包されてる言葉はあまりいい言葉じゃないので、早くみんな忘れましょう。本人にとってネガティブワードは自分をよくない方向に洗脳するだけなのでオススメしないです。でも、ゆっくり諦めず、状況を改善し続ける勇気だけは忘れずに。ソースコードの問題点を知っているのは技術者だけなのですから。
【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください