技術的負債の「会計的」性質
負債とはなにかについてわたしたちが理解していないという事実そのもの、あるいはこの概念の融通無碍であることそれ自体が、負債の力の基盤である。
デヴィッド・グレーバー 「負債論」
ソフトウェア開発において、欠陥のある未熟な実装によって機能の追加や修正が難しくなることを、借金に喩えて「技術的負債」と呼ぶことがある（Wikipedia）。
現代のソフトウェアはもはや「サービス」に近い製品が多いが、サービスは顧客に受け入れられて初めて収益を生み出すことができる。広く使われているソフトウェアも最初は数少ない機能にたくさんのバグを添えてリリースされ、試行錯誤を経て顧客に受け入れられる。つまり、機能の追加や修正が難しくなることは、それ自体が潜在的な損失と言える。
しかし、私にはこの「技術的負債」という言葉は会計上の「借金」とは随分と異なる意味を持っているようにも思える。というのも極端な話、もし機能の追加や修正が全く生じないと仮定すると、いかに未熟な実装であっても「技術的負債」を返済する必要はない。ということは、技術的負債の「金額」や「返済の要否」はソフトウェアの将来にわたる変更可能性や変更範囲によって大きく変動すると考えられる。
この「技術的負債」の性質を会計の観点からはどう評価すべきだろうか。なお、ここでは財務諸表における表示そのものでなく、あくまで会計的な考え方で技術的負債をどう分類・測定できるかについて書くことにする。
負債の性質について
「会計的」負債
まずは会計上の負債の定義を明らかにする。
IASB（国際会計基準審議会）はIFRS（国際会計基準）の制定・改訂にあたり、根拠となる会計上の概念の理論的体系として「Conceptual Framework for Financial Reporting」という文書を公表している。2018年3月に公表された最新版には、「負債」の定義について次のような記載がある。
A liability is a present obligation of the entity arising from past events, the settlement of which is expected to result in an outflow from the entity of resources embodying economic benefits. [F 4.4(b)]
つまり、会計上の負債は「過去の事象によって生じた現在の義務であり、経済的便益の流出を伴うと想定されるもの」と定義できる。「義務」として確定していないものは会計上の負債ではない。なお、IFRSにおいて負債はさらに次の2つに区分される（本当はもっとあるけど無視）。
“金融負債”: 借入金のように、契約によって生じる第三者に対する支払債務（IAS 32で規定）。
“非金融負債”: 将来の損失に備えた「引当金（Provision）」や特定の条件が満たされたときに発生する「偶発債務（Contingent liability）」など（IAS 37で規定。後述）。
「技術的」負債
Wikipediaによれば「技術的負債」という言葉の初出はWard Cunninghamというソフトウェアエンジニアが1992年3月に書いたこの記事らしい。
ここでCunninghamは「量が多く未熟で修正が大変なコード」を出荷することを借金に喩えて「技術的負債」と呼んでいる。つまり、ソフトウェアの出荷によって借金が生まれ、それが時の経過に従って利息（コードの修正にかかる時間）を生み出し、さらに借金を増やしていくという考え方だ。
Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.
この負債は「返済」しなければならないだろうか。もし柔軟性が欠如していた（inflexible）としても、ユーザーが目的を果たすにあたって問題なさそう（may work fine and be completely acceptable to the customer）であれば、それを返済する必要は無いと考えることもできる。
返済の義務が生じるのは、コードを修正しなければならないときだ。コードの修正を生じさせる原因は様々だが、ここでは発生の原因によってCunninghamの技術的負債を以下の2つに分けることにする。
“技術的負債”: 特定の要件に対して、設計やプログラミングの知識・能力・情報の不足など技術的能力に起因する負債。例えば、設計・プログラミング能力の欠如による複雑な関数、セキュリティに問題のある古いライブラリの放置など。
“要件的負債”: ビジネス上の要件に由来する負債。後述。
「要件的」負債
例えば、ここにスマートフォン向けゲームを開発するA社がある。A社は、ゲーム内でアイテム購入に使える通貨Gをユーザーに与える。当初、ユーザーは一切お金を払わず、完全無料で遊ぶことができた。やがてユーザーが増えてきて収益化の見込みが立ったので、A社は「Gをアプリ内課金で買える」機能を追加することにした。このとき、A社は資金決済法の規制に従い、無料で付与するGとユーザーが購入するGの発行額・消費額・残高を無料/有料で区別して管理しなければならない。不幸にして現在のデータ構造でこの要件を満たすことが難しい場合、それは「誰の」責任だろうか。
これは極端な例だが、その「負債」が設計やプログラミング等の技術的能力の不足から生じたものでなく過去に決定されたビジネス上の要件に起因するものであれば、「技術的負債」という呼び方は公平ではなく、「要件的負債」と呼ぶべきだろう。
いかに優秀なソフトウェアエンジニアが数多く在籍する組織でも、ビジネス側の要件が柔軟でなかったり周囲の環境が大きく変動する場合、この要件的負債を生み出すことがある。その多くは、意思決定者と開発者の間で要件の認識や時間の見積についてコミュニケーションが不足していることによって生じる。
負債の会計的性質とその認識・測定
負債の性質について整理したので、いよいよ技術的負債および要件的負債の「会計的」評価を進めることにする。
技術的負債
技術的負債は「過去の事象によって生じた現在の義務」で、「経済的便益の流出を伴うと想定される」ので、（返済の義務が確定している場合に限っては）会計的に考えても負債として計上すべきだ。
しかし、返済時期や金額が確定している訳ではないので、借入金のような金融負債、確定債務ではない。どちらかといえば非金融負債、その中でも将来の損失に対する「引当金」に近いと言える。
引当金はIAS 37の定義によると
a liability of uncertain timing or amount.
つまり、（負債の定義には該当するが）返済時期や金額が不明確なものだ。そのうち、金額を合理的に見積もることが可能なものを引当金と呼ぶ。
a present obligation (legal or constructive) has arisen as a result of a past event (the obligating event), payment is probable (‘more likely than not’), and the amount can be estimated reliably.
技術的負債は特定の要件に対し、設計やプログラミング等の技術的能力の不足に起因して生じた負債であると定義した。その「金額」については、過去の実績やより技術力の高いソフトウェアエンジニアによって合理的に見積もることが可能であると考えられる。
また、IFRSではIAS 37で全ての貸借対照表日において引当金の見直しを行い、もし引当対象の債務が発生しなくなった場合はそれを貸借対照表から消す（つまり負債でなくなる）ことを要求している。
Remeasurement of provisions [IAS 37.59]
- Review and adjust provisions at each balance sheet date
- If an outflow no longer probable, provision is reversed.
支払の必要に応じて合理的に見積もり必要がなくなったら負債から消す、という引当金の性質は、コードの修正範囲やその可能性に応じて「金額」や「支払要否」が決まる技術的負債の性質に近いと言える。
要件的負債
要件的負債も技術的負債と同じく「過去の事象によって生じた現在の義務」であり、「経済的便益の流出を伴うと想定される」ので、会計的に考えても負債として計上すべきである。
しかし、「いつ」「いくら」返済することが確定している訳ではないので金融負債ではなく、かつ負債の発生可能性や金額を合理的に見積もることが難しいことから、偶発債務（条件付債務）に近いと言える。引当金と偶発債務はどちらも将来の損失可能性に対する不確定な債務だが、前者は合理的に見積もることができるもの、後者はできないものという違いがある。
偶発債務はIAS37号の定義によると
a possible obligation depending on whether some uncertain future event occurs, or a present obligation but payment is not probable or the amount cannot be measured reliably
つまり、将来特定の条件を満たしたときに発生する債務、もしくは支払い義務はあるが信頼性を持って測定することが不可能な債務だ。
このような債務への「会計的な」対処方法としては、合理的に計算できる部分は貸借対照表に載せ（つまり引当金）、残りは潜在的な債務になりうる金額を注記として投資家向けに開示する。
大きく話題になった例だと、シャープが鴻海精密工業との買収交渉において、事業撤退時に負担する保証費用や訴訟の賠償額の合計3,500億円を将来の潜在的な債務（偶発債務）として提示しており交渉が難航しているとの報道があった（シャープは公式に報道を否定）。
会計における「投資家」はソフトウェア開発における意思決定者（プロデューサー、Product Owner、Project Managerと呼ばれることが多いと思う）と考えられるので、（会計的に考えれば）開発者が要件的負債の存在を確認・報告する責任があり、意思決定者およびその上司が要件的負債の存在・解消について責任を負うことになる。
結論: 技術的引当金
この記事では、いわゆる技術的負債の会計的性質について書いた。
まず、返済の義務がなければ会計的には「負債」ですらない。そして、技術的負債は会計的には借入金というより「引当金」に近い。これからは技術的負債のことをより正確に「技術的引当金」と呼ぼう。一方で、要件的負債は「偶発債務（条件付債務）」に近いが、発生可能性が高く金額を合理的に見積もることが可能な場合には引当金と言える。
このように会計的手法を用いて分類したからといって、私たちの目の前に積み上がった負債が消えてなくなるわけではない。
しかし、ソフトウェア開発における負債について会計的分類を行うことは、それを「負債」として認識すべきなのか、そうだとしたらどのタイミングでどの程度の金額なのかを測定する上で、客観的な視点を提供できると考えている。
人類の歴史的な記憶から来るものなのか、「負債」という言葉は「自分が悪い」という気持ちを呼び起こさせるので、負債の正体や本質を見極めてよりプレッシャーの少ない言葉に言い換えていきたい。
