原幹公認会計士事務所

開発生産性という文脈で、「技術的負債」というキーワードを時々耳にするようになりました。果たしてこれはどんな考え方なのでしょうか？

「技術的負債」は、Wikipediaによれば次のように定義されています。

https://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5

行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。

最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。

ここでは「組織で共有されない知識」「複雑すぎて変更が難しいコード」などが例示されています。品質の低いコードを使い続けることを「利息の支払」と表現しているのが興味深いですね。ここでは、当初採用した技術やコードが足かせとなって開発生産性に影響を及ぼす事象全般、と仮に定義します。

たとえば商用サービスに利用するアプリ開発の場合、アプリそのものでのユーザー獲得や収益向上を直接的に志向することから、開発段階での最適なアーキテクチャ選定を行い、その後急速に陳腐化しないよう保守性や拡張性に配慮する必要があります。

仮に技術的負債をイメージするならば以下のようになるでしょうか(以下、複式簿記のルールをあえて逸脱して表現します)。

ソフトウェア資産(付加価値を持つ無形の資産)を生成するには「ヒト」の知恵と作業が必須になります。従って、一般的な処理の流れとしては

1. 人件費の計上
2. ソフトウェア（及び技術的負債）の発生
3. 売上の計上
4. ソフトウェアの償却

という順番になりましょう。

このとき「技術的負債」はどこにマッピングされるのでしょうか。現行の会計ルールではそもそもオフバランス項目なので、B/Sには出現しません。結果として、利息の支払い(たとえば低品質コードを使い続けること)による費用が表面化しないことから、P/Lインパクトとして意識されることはないでしょう。しかし一方でボディブローにように経営資源を費消する側面があることは留意する必要があります。

技術的負債を抱えることのデメリットとして容易に想像できるのは、たとえば回収コストが足かせとなってその企業の競争力の阻害要因になることです。たとえば一点突破を目指して新たな市場を創造することを目指すようなベンチャーにとっては、リソースをいかに集中投下するかが重要なので阻害要因は極力排除したいはずです。技術的負債の存在が収益獲得の足を引っ張るのであれば、そのようなリスクは排除しておきたいはず。

ではどうすればよいのでしょうか？一般的には

技術的負債の解消(2)および利息支払い(5)のスピード＜収益獲得のスピード

を維持することで、生産性を下げずにビジネスのスピードを維持することができるかもしれません。よりよいのは技術的負債の解消(または利息の支払)期間中に次のプロダクトへの投資が完了し、リリースと同時に技術的負債を完済していることでしょうか。(完済の意味するところが明確にイメージしにくいところですが)

特定のアーキテクチャを採用する段階で不可避的に技術的負債が発生することから、現行の会計ルールでは見えない(オフバランスなので)技術的負債のP/Lへのインパクトをいかに可視化して改善プロセスに乗せて行くのか(または行くべきなのか)。このあたりに、特にベンチャー企業の成長スピードへのヒントがあるのかもしれません。

※お問い合わせはこちらから

https://ssl.form-mailer.jp/fms/e5d2273b248067