バランスシートで考える技術的負債

はじめに

エンジニアリングの課題としてよく話題になるのが技術的負債という言葉です。プロダクトを開発していった結果、その一部に満足のいかない部分が生まれ、それによって開発効率が落ちてしまうようなものを技術的負債と呼んでいると思います。つまり作り出した物が負債となってしまったという解釈が多いのではないかと思うのですが、私は作り出していないために生まれる技術的負債もあるのではないかと思っています。

この記事では、技術的負債を言葉の由来でもある会計的な視点から見てみることで、技術的負債の本質を解き明かし、どのように計画的な技術的負債の運用を行うかについて考察します。なお、私に会計的な専門知識はないのと、簡単化のために、あくまで会計風の表現で技術的負債を表してみたものと思ってください。

バランスシートで考えるプロダクト開発

技術的負債について触れる前に、まず、プロダクト開発を会計的に表現するとどうなるのかをバランスシートで考えてみます。バランスシートは資産、負債、純資産の3つの要素で構成されます。資産とは利益を生み出すもの、負債とは返済義務があり一般的に金利の発生するもの、純資産とは返済義務のないもので、負債と純資産の合計が資産と一致するように作られます。

下の図はプロダクトをこれから作り始めるときのバランスシートです。

株主からの調達や自己資金から純資産を用意し、それが現金という形で資産になっています。プロダクト開発を進めるとどうなるかというと、人件費などによって現金が減り、プロダクトという資産が生み出されます。

つまり、大雑把に言うと、プロダクト開発とは、現金をプロダクトに変換するプロセスであると考えることができます。そして、現金がプロダクトに変換されると、プロダクトが現金(利益)を生み出します。生み出された利益は利益余剰金などとして純資産を増加させます。

現金をプロダクトに変換し、プロダクトが現金を稼ぐことによって、資産を増やしていくというのがビジネスということになりますが、現実はそううまくはいきません。現金→プロダクト→現金という課程において、必ずどこかに損失が発生します。これまでのバランスシートでは資本金だけでプロダクト開発を行う前提になっていましたが、銀行から融資を受けて負債を抱えている場合を考えます。借りるような負債には一般的に金利がかかるため、現金の一部が利子の支払いに使われることになり、本来プロダクト開発に使いたかった資本金を効率的にプロダクトに変換することができなくなったり、プロダクトが生み出す利益が少なくなったりします。その結果、プロダクト開発を進めるにつれて(大きな利益を生めなければ)資産が減っていくことになります。

現実には負債を抱えていない場合でも、現金をプロダクトに変換する課程において、コミュニケーションコストや採用費など避けられない損失は発生します。これらは損益計算書では販管費などとして処理されますが、バランスシート上には表記されないので、ここでは負債の返済と利払いのみが損失、つまり現金を消費するものであるとします。

以上のことをふまえると、プロダクト開発とは、プロダクト、現金、負債、純資産の4つ要素で構成されたバランスシートで考えることができます。

バランスシートで考える技術的負債

プロダクト開発のビジネスとは、現金をプロダクトに変換し、プロダクトが利益を生み出すものであるとしました。そして、その過程において負債の返済や利払いによって損失が発生し、利益との通算によってバランスシートで表される資産が拡大/縮小することになります。もちろんビジネスであるので目指すは資産の拡大ということになりますが、それをバランスシート上の要素からコントロールするには、負債といかにうまく付き合うかが大切になってきます。なぜならバランスシート上で損失を発生させるのは負債のみであるためです。

ここで、改めて負債について考えてみましょう。負債とは返済義務があり、一般的に利払いによって損失が発生するものです。これを逆に考えてみると、プロダクト開発ビジネスのバランスシート上では、損失が発生するようなものはすべて負債であると考えることもできます。そして、負債のうち、『技術的に解決可能だが、解決されていないために損失を発生させるものが技術的負債である』といえるのではないでしょうか。一般的な技術的負債のイメージは、早期リリースや技術力不足などによって作ったプロダクトの一部が負債となってしまっているようなものだと思います。私はそれよりも技術的負債が対象とする範囲は広いのではないか、具体的には、作っていないことによる技術的負債もあるのではないかと考えています。さらに、技術的負債の中にも現金をプロダクトに変換する過程において損失を生むものと、プロダクトが現金を生み出す過程において損失を生むものの2つに分類されると思っています。これらをそれぞれ、開発効率にかかる技術的負債、利益率にかかる技術的負債、と呼ぶことにして具体例を考えてみます。

開発効率にかかる技術的負債

開発効率にかかる技術的負債の代表例が、プロダクトを作ったことによる技術的負債、俗に言う「イケてないコード」です。可読性が低いことによって認知負荷が高まってしまったり、変更容易性がないことによってちょっとした変更に時間がかかるようになってしまったりしたものを指します。この場合、コードを理解するのに時間がかかったり、機能を追加するためには別の場所を改修する時間が必要になったりします。例えば、新機能を追加するために10時間分の現金(人件費)かかったとして、コードを読むのに1時間、他の場所の改修に3時間かけていたとすると、現金をプロダクトに返還できた時間は6時間になるので、開発効率は単純計算で60%ということになります。残り40%の現金は技術的負債への利払いによって失われたと考えられるでしょう。このイケてないコードを解決する、あるいは生み出さないためには、コードレビューをすることやDesign Docのような設計プロセスを取り入れることが大切だと思います。 今の開発効率が60%だったとしても、新しく増え続けるコードの開発効率が80%だったのであれば、最終的な開発効率は80%に収束していきます。あるいは、リファクタリングやリプレースによって既存のコードの開発効率を高めるというのも有効です。

ほかにどのようなものが開発効率にかかる技術的負債として挙げられるでしょうか？作っていないことによる技術的負債の例を挙げてみると、自動テストがないことが該当すると思います。例えば、ユニットテストがあれば10秒で動作確認ができる関数のために毎回手動で1分動作確認をしていたとすると、テスト1回あたり50秒分の損失を生んでいるといえます。テストを1回しかしないのであれば50秒の損失で済みますが、100回テストが必要になった場合は1時間以上の損失になります。インテグレーションテストやE2Eテストでは、自動テストの有無によってユニットテストさらに大きな差が生まれます。つまり、自動テストを整備することが技術的負債の積み上がりを軽減/返済していると考えることもできると思います。

利益率にかかる技術的負債

利益率にかかる技術的負債というとSaaSの利用が挙げられると思います(AWSなどのクラウドプラットフォームやIDaaSなどのXaaSもSaaSとしてまとめます)。SaaSの利用によって短期間でプロダクトをリリースできるようになり、素早く売上を得られるようになる一方、毎月損失を生むことになります。例えば認証認可のSaaSを導入すれば認証認可機能は作らなくてよくなりますが毎月利用料がかかります。これをバランスシートで考えると、認証認可機能を負債として借りることで、プロダクト内に認証認可機能を導入したということになります。銀行で現金を借りて、資産に現金が加わるようなものです。

もちろん借りたものには利子を払うことになるのですが、この利子は現金をプロダクトに変換する効率を悪化させるようなものではないので利益にかかる技術的負債であると考えることができます。
SaaSの利用を技術的負債と呼ぶのは違和感があるかもしれません。ただし、認証認可機能は技術的に自分で作ることもできるのです。もちろん作るということは時間をかけて現金を認証認可機能に変換するということになりますが、一度作ってしまえば利用料という利子を払う必要がなくなるので、認証認可機能は負債ではなく純資産になります。SaaSという技術的負債を真に返済するというのは、SaaSの利用をやめてその技術を自分たちで内製するということです。

技術的負債は意図的に抱えるべきもの

技術的負債は一般的によくないものと考えられていて、この記事でも損失を発生させる悪者のように書いてきましたが、ほんとうにそうでしょうか？もちろん損失を発生させる悪い側面はあるものの、必ず避けるべきものというわけではありません。意図的に技術的負債を抱えることによってビジネスを早く前進させることができます。

では、どういう場合に意図的に技術的負債を抱えるべきかというと、次の2つの場面においてです。

1つめは、開発時間を減らし、短期でリリースすることで得られる売り上げなどの利益が長期的に払い続ける技術的負債へ払う利子を上回ることが想定される場合です。具体例を挙げると、ChatGPTのような革新的なサービスを他社より少しでも早くリリースし、他社より先に年間サブスクリプションを契約してもらえれば、少なくともサブスクリプションが切れるまでの1年間は他社を上回る収益を得られるかもしれません。最近各社が対話型AIを導入した検索エンジンを発表しているのも、AI検索エンジン市場での先行優位性を確保しつつ、従来の検索エンジンのシェアを奪い取るためでしょう。もしかすると、これら対話型AIは短期リリースを優先されているために、内部では相対的に大きな技術的負債を抱えたプロダクトになっているかもしれません。

技術的負債を抱えるべき2つめの場面は、開発費用を減らすことによって得られるリターンが長期的に払い続ける技術的負債に払う利子を上回ることが想定されるときです。例えば、誰が見ても文句のつけようのない設計をするには1年間かかってしまうけれど9割の人が文句をつけない設計でよければ1ヶ月でリリースできるような場合や、認証認可機能を内製すると1年分の開発費がかかってしまうがSaaSを導入することにより1ヶ月で認証認可機能を導入できるような場合です。開発時間を1年から1ヶ月に減らすということは、11ヶ月分の開発費用を減らすということです。なお、開発費用を減らすと開発時間も減らすことになるため同じようなものだと考えられるかもしませんが、厳密には異なります。例えば社員ではなく業務委託メンバーにSaaSの内製を依頼すれば社員の開発時間を消費せずに置き換られるかもしれませんが、これをしないのであれば開発費用を減らすためにSaaSを使っていると言えるでしょう。(ビジネスドメインに興味はなくても認証認可機能を作ってみたいエンジニアはいるだろうという前提があります。)

まとめると、開発費用と開発時間を減らすことで得られるリターンが払う利子より多いなら技術的負債を抱えた方がいいということになります。無意味に短期リリースをしても得られる売り上げに対して払うべき技術的負債の利子が高くなるし、過度に時間をかけて技術的負債を減らしても利子に対する開発費用が見合わないのです。「要はバランス」と言ってしまえばそれだけですが、基本的にはいくつか設計案を出すくらいの時間は確保し、その中から最善の案を選ぶようにしておけば必要以上に大きな技術的負債を抱えず現実的な期間でリリースできるのではないでしょうか。

技術的負債との戦い方

意図的であれ偶発的であれ、すべてのプロダクトがなにかしらの技術的負債を抱えているでしょう。プロダクトが大きくなるにつれ内包する技術的負債も大きくなり、利用者が増えるにつれSaaSの利用料もかさんでいきます。なにも手を打たなければ、現金をプロダクトに変換することができなくなり、利益を得ることもできなくなるかもしません。では一体どのように技術的負債の影響を減らすかというと、返済をするか借り換えをすることになると思います。
返済とは単純に技術的負債の量を減らすことによって利子を抑えようというものです。具体的には、構造化されていないプログラムを構造化することによって可読性や変更容易性を高めたり、自動テストを整備することによってテスト時間を短縮したり、SaaSの機能を内製して利用料をなくしたりすることです。技術的負債の返済はよく言われていると思いますし、イメージがしやすいのではないでしょうか。
では、技術的負債の借り換えとはなんなのでしょう？一般的な借り換えとは、銀行Aの負債を返済するために銀行Bで新たに融資をうけるというものです。なぜそんなことをするのかというと銀行Bの方が同じ額の現金を借りても金利が低いことで支払う利子が少なくなるためです。技術的負債についても同じで、金利が低い技術的負債に乗り換えれば負債を返済した場合と同じように払う利子を抑えることができるのです。具体的には、同じような機能を持つがより安いSaaSに乗り換えた場合などが該当します。

技術的負債の影響を減らすには、返済して量を減らすか借り換えで金利を下げるのが有効であると説明しました。これは技術的負債の影響の大小が、量x金利に比例する利子(損失)の大小に比例するためです。
実はもう一つ技術的負債の影響の減らす方法があります。それは量x金利x支払い頻度で求められる利子総額を減らす方法です。量と金利は0になることはないと思いますが、支払い頻度は場合によっては0にすることができるかもしれません。
例えば、昔在籍していた人が作った古のプログラムでどういう仕組みなのかはわからないがバグもなく動いているような部分があったとします。これは、技術的負債の量という意味ではかなり巨大なものかもしれませんが、それ以降変更することがないのであれば利払いが0になります。逆にこういうものを無理にリファクタリングなどをしようとすると大きな利払いが発生するので、本当に必要になる場面までは極力放置して生み出される利益だけを得るのがいいかもしれません。

バランスシートで考えるプロダクトの価値

これまでバランスシートで見てきた技術的負債の考え方を生かして、自社プロダクトの価値とはなんなのかを考えてみます。自社プロダクト内の認証認可SaaSをバランスシートで考えると、SaaSから認証認可機能を負債として借りてくるかわりに手数料という利子を支払うものであるとしました。これは認証認可SaaSのバランスシートを考えた場合にも同じことがいえます。認証認可SaaSはおそらくその機能の一部、例えばメール送信機能などをメール送信SaaSから借りてきて手数料を払っていることでしょう。

これを逆方向に広げて自社プロダクトの利用者のバランスシートを考えてみると、結局自社プロダクトというのも利用者に対して機能を提供し利用料をもらっているということです。自社の資産であるプロダクトの価値というものは、利用者にとっては負債であり、自分たちが技術的負債を減らしたいように、利用者はプロダクトの利用をやめて利払いを減らしたいと考えています。自分たちがSaaSの利用をやめて内製できないのと同じように、自社プロダクトも莫大な価値を内製や借り換えの検討がされないほどの利用料で提供することができれば、利用者はプロダクトを手放すことができなくなり、プロダクトはどんどん成長していくのではないでしょうか。そしてプロダクトの価値を積み上げ、利益を最大化するためには技術的負債をコントロールする必要があるでしょう。

おわりに

技術的負債をバランスシートで考えてみると、個人的には漠然としか捉えられていなかった技術的負債の正体が見えてきたように感じました。実際の現場では、今のプロダクトはどれくらいの資産になっていてそのうちどれくらいが技術的負債なのかを正確に計ることはできないと思いますが、今はどれくらいの開発効率や利益率なんだろうかと考えたり、どういう技術的負債の改善に取り組むと効果的なのかを考えたりするときに思い出してもらえれば幸いです。