技術的負債：経営者・投資家（マクロ視点）から見た場合と技術者（ミクロ視点）から見た場合では見え方が異なるみたい

Twitterを見ていたら、技術的負債が話題になっていたので考えてみた。

あるツイートの「コード（プログラミングのコードのこと）は書いた瞬間に負債になる」という発言に対して、

「いやだから手前の書いたコードはB/Sの左側だろ。いくら経年劣化してもその点は変わらない。負債ってのは右側で、なぜ右側かと言えば人様のものだから」

とコメントしている人がいた。

さらには「世界中のエンジニアのほとんどはこんな会計の基本的なことも知らないのか」というコメントも。

負債というのは人様から借りているもののことなのだから、自分で生み出したものに負債という言葉を使うな、という主張だけど‥

むしろ会計的にはこの発言の方が間違っている。

負債の本質は「将来支出を産む義務」であって、「人様のものが負債になる」という主張は本質的ではない。

デロイトトーマツのIFRS用語集から引用すると、

負債とは「過去の事象から発生した当該企業の現在の義務で、その決済により、経済的便益を有する資源が企業から流出する結果となることが予想されるもの。」

現に「人様のもの」ではないけど負債になるものはあって、例を挙げると資産除去債務という勘定科目がそうだ。

つまり「自らが生み出した資産に付随して負債が生まれる」って発想は実はかなり会計的。

というところまで考えてみて、技術的負債って資産除去債務と似てるとこあるな、と思ったのでもう少し掘り下げてみる。

技術的負債と資産除去債務って似てるよね

資産除去債務の定義は以下の通り。

①有形固定資産の取得、建設、開発、又は通常の使用によって生じ、

②当該有形固定資産の除去に関して発生し、

③法令又は契約で要求される法律上の義務又はそれに準じるもの

それに対応させて、技術的負債を以下のように定義することもできるはず。

①無形固定資産の取得・開発によって生じ、

②当該固定資産の除去または更改に関して発生し、

③法令または契約で要求される法律上の義務またはそれに準ずるもの

三番目が結構重要だと思うが、世の中のソフトウェアというものは基本的には作ってしまっておしまいではなくて保守運用がセットになっているもの。

それが「契約で要求される法律上の義務またはそれに準ずるもの」となる可能性は大いにある。

パッと思いつきでつらつらと書いてみたけれど、技術的負債に対応する会計基準必要じゃないかな〜と思う。

だって世の中はすでに無形資産の時代になっている。

リンク

いまの会計基準ではオフバランスだから正しく見積もることができないけど、技術的負債によるP\Lインパクトは潜在的にはあるわけだから可視化できた方がいいよね。

ただ、それはそれとしてエンジニア側が技術的負債を産まない努力は必要なわけで、

おそらくこの「技術的負債なんてものはない」派の人が言わんとしているのは言葉通りの意味ではなく、「技術者が技術的負債なんて言葉に甘えてクソコードを量産するんじゃねえ」ということのはず。

その方便として、「技術的負債なんてものはない」「みんなが言ってるのは正しくは技術的負債ではない」というのは方便としてはアリだろう。

エンジニアというミクロな視点からは、技術的負債という概念にはあまり有効性はなく、スパゲッティコードを書くことの言い訳にしかならないというような言い分もわからなくはない。

それならばいっそ技術的負債という概念の存在を否定してしまえ、という考え方もありうるだろう。

しかし、ミクロでは有用でない概念でも、マクロでは重要になるということは往々にしてある。またミクロとマクロで方策の結果に違いが出るという合成の誤謬という概念も有名だ。

経営者や投資家というマクロ視点からすると、技術的負債は確実にそこにあるものである。

それを不可視化することによるデメリットはかなり大きいだろう。もしそうしてしまえば見えないところで工数がかさみ、予定していない出費が嵩むことになるわけだから。

B/Sにオンバランスするなどして正しく認識しておけば、将来の出費を見積もることもできるし、財務諸表を読む投資家も判断しやすくなるのではないか、という話。