久しぶりにウクライナが関係のない話。
エンジニア界隈で、技術的負債という言葉がある。
日本語版Wikipediaの概説を持ってくると、
技術的負債（英語: technical debt）、または設計負債、コード負債とは、ソフトウェア開発における概念であり、時間がかかるより良いアプローチを使用する代わりに、今すぐ簡単な（限定的な）解決策を選択することで生じる追加の手直しの暗黙のコストを反映したものである。
というものである。
言葉の理解
この技術的負債という言葉、エンジニアになった最初の頃は言葉を選ばずにいうと上品に担当部分の(自分を含めた)過去担当者を罵倒する言葉程度にしか思っていなかった。
過去のエンジニアが知識がなかったから・センスがなかったからこんな出来の悪いものになっている。自分はその尻拭いをしているんだやれやれ、ということを誰かを傷つけないように言うために使われているかのように思っていた。（周りの使い方もそんなもんだったと思う）
言葉の意味の体感
最近体感としてこの言葉の本来の意味がわかってきた。 多くのエンジニアは「技術的負債」の解消に関する仕事をつまらない仕事と感じるだろうが、基本的に技術的負債について頭を抱えないといけないのはプロジェクトマネージャーより上の立場であると思う。
投資(＝機能追加＝技術的負債の増大)と負債の返済のリソースを割り当てるべきなのか、負債を少なく済ませてくれるような有能（＝高価）な人材を雇うべきなのか（＝金銭的な負債の増大）といったことに頭を抱えるための
スタートアップが成長し続けないといけない理由
たとえばみんな大好きRuby on Rails。
これからWebサービスで起業しようと思ってRuby on Railsを使ってWebサービスを作ったとする。 (話を簡単にするため、フロントエンドのフレームワークとかミドルウェアはないものとする。)
今の最新マイナーバージョンは7.0なので、当然そのバージョンを使って作り始めることになるだろう。 近年の傾向を見るに、だいたいマイナーバージョンのリリースから3,4年くらいセキュリティサポート終了まである。 しかもサポート期間がだんだん長くなっている傾向があるので、下手したら7.0は5年くらいサポートされるかもしれない。
この間は、変更が小さいアップデートだけを取り入れていけば良いわけだ。 もちろん、後で一気に上げるのは大変なので、適宜その時最新のメジャー・マイナーバージョンアップに追従していくのが望ましいことではあるが、後回しにしてもいいっちゃいい話になる。
すると、この間は「自分達が書くコード」部分に全ての開発リソースをつぎ込めることになる。
しかし、いざそろそろバージョンアップなんかもちゃんとやっていかなきゃいけないねとなってくるとこれまで100%の開発リソースを自分達の書くコードに集中させることができていたのを徐々にライブラリのバージョンアップという、新たな価値は生まない仕事に振り向けていかなくなってしまう。
ちゃんと売上が成長し開発組織にも投資をして少しずつ負債を返す方にもリソースを投入していくのが健全な道だ。
仮に売上が成長していないんだとすると、売上が上がっていないソフトウェアにさける資金も少なく、限られたリソースを負債を返す方ではなくまずは売上が成長できるポイントを見つけようと探すための「機能追加」に投入せざるを得ない。 そしてタイムオーバーまで組織を成長させることができなければ一気に負債が襲ってきて、ほとんどその組織は新しい価値を生み出す仕事に時間が使えなくなってしまう。
となると、そのタイミングでビジネスを始めたまだ負債のない新しいスタートアップに劣ることになる。
たとえ調達をしなくても
スタートアップ企業の多くは、ソフトウェア開発と無縁ということはなかなか少ないのではないだろうか。 顧客への提供価値がSaaSなどITサービスの場合はもちろんだが、業種としてソフトウェア産業でなくてもソフトウェアを使って同業種の大企業より上手い立ち回りができるというのが、一般的なスタートアップの戦い方だ。
エクイティ調達をしない限り、成長しないといけないということはない（最悪中小企業として、成長せずにビジネスを継続する）ということはないものだと思っていた。 ファイナンスの観点からするとそうなのだが、経営資源の質という点で見ると、エクイティ調達をしない限りスタートアップ的なビジネスは一度始めると成長をし続けないといけない理由があるのだなぁ、ということがわかってきた。
