財務諸表というフレームワークで考えるソフトウェア開発と技術的負債
この記事は「Funds Advent Calendar 2022」21日目の記事です。
ファンズ株式会社 CTO の若松と申します。
今年も例年通り Twitter の運用は三日坊主となり、 note についても筆を断ったまま2022年を終わりを迎えようとしていたところ、アドベントカレンダーの時期が来ていました。
せっかくの機会ではあるので、以前から漠然と思っていた考えを整理してみたいと思い、この記事では財務諸表を読み解く概念的な考え方を使い、技術的負債について読み解いてみることにしました。
ソフトウェア開発上の概念である"技術的負債"
ファンズは、貸付ファンドのオンラインマーケット「Funds」を通じて、個人投資家には着実な資産運用の機会を提供しつつ、企業に対しては借入によるファイナンスの機会を提供しています。そのような事業業態の性質上、コーポレートファイナンス的な考えに触れる機会も一般的なエンジニアよりは少しだけ多くあります。
一方で、ソフトウェア開発においてはいわゆる「技術的負債」という概念が存在します。技術的負債は Wikipedia によると次のように定義されています。
技術的負債（technical debt）、または設計負債、コード負債とは、ソフトウェア開発における概念であり、時間がかかるより良いアプローチを使用する代わりに、今すぐ簡単な（限定的な）解決策を選択することで生じる追加の手直しの暗黙のコストを反映したものである
この文脈における技術的"負債"というのは、財務的な考え方を反映したものではなく、あくまで一種の喩えとして使われているに過ぎません。
ただ負債であるという以上、ある程度（財務的な）負債とも一定の共通点があるはずです。そこで以下では財務諸表の解釈を少し広げて、ソフトウェア開発に対してどのように適用できるかを見ていくことにします。
財務諸表というフレームワーク
財務諸表といえば、企業の経営状況や財務状況を把握するための手段です。ですがここでは一度財務的な観点から離れ、その本質的な構造に着目してみることにしましょう。
バランスシートは現在の資源の状態を表したもの
まず財務諸表の中でも基本となる、バランスシート（BS）の構造を見てみましょう。もっとも単純な BS の構造は以下のようになっていると思います。
バランスシートの右側には負債と純資産（自己資本）が、左側には資産の状態が表現されますね。
通常のバランスシートは金額という価値尺度を元に左右の構造を見ることになりますが、ここでそれぞれの要素の意味を少し考えてみます。
まず純資産（自己資本）です。元手となる資本金や前期までの利益による利益剰余金などが相当し、自分の保有する投入資源であると考えられそうです。
それに対して負債は、借入や社債などにより調達した、自分のものではない資金です。少し広く解釈するとこれは自分のものではない投入資源であると考えられます。
バランスシートの左側に相当する資産は、一般的には流動資産（現金・預金など）や固定資産（不動産など）などがありますが、いずれにしても投入した資源が現在どのような形になっているかを示すもので、投入した資源の形を表すものと考えらそうです。
このようにしてバランスシートの解釈を広げたものが次の図です。
この整理で、バランスシートは投入資源した資源量とその資源の現在の形を示す、現時点のスナップショットと考えることができそうです。
PL はある特定期間の生産結果を表す
次に損益計算書（PL）について考えてみましょう。
PL についてはざっくり売上・費用・利益という区分で考えてみます。
売上は企業がサービスや商品を提供することにより稼いだ金額の総額です。これはもう少し解釈を広げれば、生み出した生産物の総量であると考えることができそうです。
次に費用ですが、これは企業が生産などの経済活動に伴って支払う支出のことです。端的に言えば生産に伴って支払うコストであると考えることができます。
最後に利益は売上から費用を引いたものであり、企業にとって実質的な価値のあるものであると捉えてよいでしょう。
このように整理することでPL はある特定期間における総生産物とそこで生まれた実質的付加価値を表すものであると整理することができそうです。
ソフトウェア開発におけるBSとPLとは
ここからは、先ほどの解釈を広げた BS と PL について、ソフトウェア開発上の概念を適用してみましょう。先ほどまでの議論で、BS と PL 上の概念は次のように整理しました。
BS: 投入資源した資源量とその資源の現在の形を示す、現時点のスナップショット
PL: ある特定期間における総生産物とそこで生まれた実質的付加価値を表すもの
さて上記の整理にもとづいて、ソフトウェアの開発における資源や活動を BS と PL というフレームワークへ適用するならば、次のように考えられるのではないかと思います。
投入資源: ソフトウェアの生産力
（既存のソフトウェア・人材・開発体制など）生産物: 開発されるソフトウェア
実質的付加価値: 企業の利益を創出したり、ソフトウェアの生産性を向上させることのできる成果物
またこれらの帰結として、ソフトウェア開発における BS と PL の構成要素としては、次のように考えることができるのではないかと思います。
ソフトウェア開発における生産力と資産とは
ここで整理したソフトウェア開発における BS の構造は次のとおりです。
資産 → ソフトウエアや開発体制
負債 → 技術的負債
純資産 → ソフトウェア生産力
ソフトウェアの生産性に関与する要素の例とし、下記のようなものがあると考え、それらをまとめてソフトウェア生産力としています。
ソフトウェアを開発する人的資源
開発体験やソフトウェアの品質担保を実現する技術的資源
システム全体のアーキテクチャ・インフラストラクチャ・CI/CD パイプライン などの技術的基盤
ADR や仕様文書・開発上のポリシーなどの技術的資産
開発カルチャーなどの無形文化
一方資産に該当するのは、上記のようなソフトウェア生産力に直結する技術資産のほかに、企業としての収益創出源となる開発物などが存在すると考えられそうです。
技術的負債は簡単だが限定的な解決策の蓄積
技術的負債は時間がかかるより良いアプローチを使用する代わりに、今すぐ簡単な（限定的な）解決策を選択することで生じる追加の手直しの暗黙のコストである、というのが冒頭の説明でした。
財務的な負債は明示的に借り入れるものなのに対して、技術的負債は自然発生的に生まれることも多く、むしろ意識しなければ自然に積み上がっていくようなものです。
技術的負債の中には、意図して選択する技術的負債もあるでしょう。しかしソフトウェア開発の実態としては、意図的に選択してとった技術的負債よりも、よかれと思って選択したが、後から振り返ってみると技術的負債となっていたという類のものが多いのではないでしょうか。
PLではソフトウェア開発の生産性を評価する
さて BS の構成要素をソフトウェア開発のコンテキストで解釈し直したところで、 PL のほうも見てみます。 PL の構造は次のようにしています。
売上 → 開発されたソフトウェア
費用 → 本質的価値を得るのに必要な（本来は不必要な）開発
利益 → 開発で得た本質的で資産価値のある成果物
ここで着目したいのは、開発したソフトウェアのうちすべてが価値があるものではなく、本当に資産としての価値がある（=利益創出や生産性の向上に繋がるなど）は開発したソフトウェアの一部であるという点です。
資産価値のある成果物ではない「価値を得るのに必要な付随的開発」とは、ある機能を開発するのに別の機能に対しても影響が出ることから、別の機能についても改修を加える必要があるといったシーンを想定したものです。
ここから、いかに本質的な価値の割合を多く生み出すことができるか、という点が、ソフトウェア開発における生産性の鍵となってくるのがみえてきます。
BSとPLから見るソフトウェア開発の生産活動
さてここまでの段階で、一度本来の財務的な BS と PL に話を戻してみましょう。財務的な BS と PL は、ざっくりいえば次のような関係性を持っています。
期初の BS に積まれている資産を活用して売上を作り、そこで出た利益が純資産となるので、それを元手にさらに利益を創出していく…というのが営利企業の行う経済活動です。
ソフトウェア開発における BS と PL で同様の生産活動を記述してみると、次のようなものになると思われます。
つまりソフトウェア開発の世界においては、ソフトウェアの生産力を元手とした技術的資産を活用して新たなソフトウェアを開発したり価値を高めていき、ソフトウェアの生産力を強化することにより、より価値の高い技術的資産を生み出すといったサイクルを行っているのだと捉えられそうです。
技術的負債の捉え方
ここからは、この BS と PL というフレームワークに則して、技術的負債の性質について考えてみましょう。
技術的負債の増加は本来の利益創出を妨げ・効率性を下げる
（財務的な）本来の意味の負債は利息を払う必要があります。負債が大きいと、それに応じた利息を払う必要があることから利益を圧迫します。
もちろんそれでも営利企業が負債を取るのは、借入を行うことで利息以上の利益を期待することができきるからということになるでしょう。
それに対して技術的負債が大きいと、本質的ではない開発に対してより多くの開発が必要とされることになります。
上記のイメージは概念的なものですが、実際には技術的負債による利息 = 追加開発分は、下の図のように2倍やそれ以上になることもザラだと思います。
技術的負債の解消はソフトウェアの生産効率向上につながる
たとえばリファクタリングなどの技術的負債の解消のための活動は、技術的負債を解消することを通じて、利益率を向上させるというような意味合いで捉えることができると思います。
技術的負債の返済のための開発、すなわちリファクタリングなどの開発は、それ自体は企業としての収益創出に何ら寄与しないため、ソフトウェア開発に携わったことのない人の視点からすると、それよりも利益創出に関わる開発にリソースを振るべきでは？という考え方になることも多いでしょう。
一方で先の節で述べたように、技術的負債の積み上げは長期においては本来の価値創出における効率性を低くしてしまいます。資産価値のある成果物を継続的に生み出していくにあたっては、技術的負債を返済していくことが必要であるといえそうです。
（ファンズの場合、リファクタリングの必要性について説明を問われるようなこともあまりありませんが、エンジニア出身ではない事業責任者に対して技術的負債の解消が必要な理由を説明する必要がある場合、こうした考え方は説明の手助けになるかもしれません。）
技術的負債は必ずしもネガティブなものとは限らず、コントロールすることが重要
技術的負債を積み上げることは、必ずしも悪い意味だけを持つものではありません。
技術的負債を取ることは、短期的にはより多くの成果物を残すことにつながります。事業のフェーズにおいては機能開発のタイミングが決定的に重要であることもあるはずで、時には積極的に技術的負債を取ることも必要といえます。
ただし技術的負債の積み上がり方が大きくなりすぎると、価値を生まない開発に対してほとんどの時間を割くことになり、小さな開発であっても非常に大きな改善コストがかかるような状況となっていきます。
そのような状況を防ぐためには過度な負債を取らない、継続的に負債を返済していくなどして、技術的負債が返済不可能なほどに大きくならないようにすることが重要といえそうです。
Funds の開発はどうなのか？
さて、ここまで考え方の話のみに終始していて、 Funds の開発についてはほとんど述べてきませんでしたが、Funds の開発はどうなのでしょう？
技術的負債について定量的に計測したりすることはありませんが、ファンズではその指針として、開発組織独自の行動指針（バリュー）を設けています。
この中の１つに「持続可能なやり方を採用する」という方針があります。
持続可能なやり方を採用する
スタートアップであっても、技術的負債や組織的負債を軽視しません。知識の明文化や、維持しやすい成果物を残すなど、属人化せずに持続できる手法を採用することで、組織や事業の長期的成長を支えていきます。
この指針に即して考えるならば、技術的負債が大きく蓄積してしまうような状態は、持続可能なやり方ではないと思います。言い換えれば技術的負債を適切なレベル（返済可能なレベル）に維持したまま開発を続けることが、持続可能なやり方を採用することにつながると考えています。
まとめ
今回は"技術的負債" をバランスシートなどの構造と対比しつつ紐解いてみました。
無計画な技術的負債の積み上げは、長期的な価値の創出力低下に繋がり、競争力も下げてしまう。技術的負債を適切にコントロールすることが、事業として、そして世の中に価値を創出し続けるためにために必要なのかなと考えています。
（宣伝）ファンズ株式会社では一緒に働くメンバーを募集しています
ファンズ株式会社では、一緒に働くメンバーを募集しております。
また現在募集中のポジションはこちらにあります！
少しでも興味のある方とは、ぜひカジュアルにお話しできればと思いますので、ぜひご連絡をいただけると嬉しいです！