スタートアップの「技術的負債」はいつ爆発するのか？

技術的負債の悪影響はいつ顕在化する？

スタートアップ初期は技術的負債（technical debt）を溜めがち。高速リリース重視と小規模・若手チームという体制がそれに拍車をかけます。

ソフトウェア系スタートアップは以下の３つのフェーズを経て成長してゆくと考えられています：

1. 誕生フェーズ（Inception）：創業～MVP
2. 安定化フェーズ（Stabilization）：ユーザー獲得～プロダクト-マーケット・フィット
3. 成長フェーズ（Growth）：事業拡大

技術的負債が「仕込まれる」のは誕生フェーズです。 内部品質を妥協してでもプロダクトをリリースしなければなりません。意図せずして技術的負債を負ってしまう場合が大半ですが、戦略的に「今は借金」と割り切るケースもあります。

スタートアップにおける技術的負債についてはすでに無数の研究成果が報告されています。しかし、誕生フェーズで発生した技術的負債の悪影響が具体的にいつ・どのようなかたちで顕在化するかは明らかではありませんでした。

それを明らかにする興味深い研究成果が、サウジアラビアのBin Faisal UniversityのAbdullah Aldaeej、そして米国University of Maryland, Baltimore CountyのCarolyn Seamanによって2022 IEEE/ACM International Workshop on Software-Intensive Businessで発表されています。論文のタイトルは「The Negative Implications of Technical Debt on Software Startups: What they are and when they surface」（ソフトウェアスタートアップにおける技術的負債：どんな悪影響が、いつ顕在化するのか）です。今回はこちらの内容を解説していきます。

スタートアップ企業5社から17名にインタビュー

研究チームは5社・17名（創業者+開発者）へのインタビューを実施し、分析対象データを入手しました。対象となったスタートアップ企業は、創業者または共同創業者1名以上と、開発者1名以上が参加できた会社のみに絞っています。

インタビューでの発言録（transcript）から、技術的負債の悪影響として共通的に出現する以下の6つのテーマを抽出しました。いずれも、技術的負債に関して定番トピックです。

1. リリース後のバグ増加（Increased post-release bugs）
2. 保守作業にかかる時間の増大（Extra time to perform maintenance activities）
3. 機能追加が困難（Inability to perform enhancements）
4. プロダクト進化に制約（Evolution restrictions）
5. インフラコスト（Infrastructure costs）
6. テストコードを書けない（Difficult-to-write test code）

これらは既知の悪影響ですが、本研究の貢献は「いつ・どのフェーズで表面化するか」を具体化した点です。

誕生フェーズ（Stage 1）：プロダクト進化に制約

まずは図中の「Stage 1」、誕生フェーズです。スタートアップはMVP開発に注力しており、技術的負債の発生状況やその将来的なインパクトにはあまり注意を払いません。コード規模もまだ大きくないため、悪影響はまだ実感されないのが普通です。

しかし、調査対象の1社ではこのような早期のフェーズで 「プロダクト進化に制約」 を体験しました。

「プロダクト進化に制約」 は多くの場合、将来の発展に対して不適切なアーキテクチャやインフラを選定してしまっていることによる 「アーキテクチャ負債」 や 「インフラ負債」 に起因します。

このスタートアップでは、地理データ（geographical data）を扱うサービスを開発していたのですが、データベースとして選定していたMySQLが地理データを扱うのに適切でなかったため、MVP開発に支障が出てしまっていました。使用する技術の選定で、初期の段階でつまずいてしまった事例となっています。

安定化フェーズ（Stage 2）

MVPをリリースし、プロダクト-マーケット フィットを実現すべく試行錯誤を続けるフェーズです。ここでは4種類の悪影響が観測されました。

リリース後のバグ増加（Stage 2）

開発を急いだ結果、無事にリリースはできたのですが、そこから不具合の報告が頻発してしまいます。様々な種類の技術的負債が関係しますが、特に適切なテストに関する 「テスト負債」 が強く影響しています。

保守作業にかかる時間の増大（Stage 2）

これは成長フェーズ（Stage 3）でもっと顕著に出ます。もし安定化フェーズで顕在化する場合には「ユーザートラフィックの増大」または「既存コードまたはツールに開発チームが不慣れ」のいずれかの条件がトリガーとなっていました。

MVP／ファーストプロダクトをリリースしユーザー数が増えてくると、当初の想定に基づく作りこみでは、増大するトラフィックをさばききれなくなることが往々にしてあります。対応が後手後手にまわりがちで、保守作業にかかる原因分析や影響分析にかかる時間が増大してしまいます。

また、このフェーズでは開発組織が大きくなっていきますが、既存コードやツールに不慣れなメンバーも出てきます。ドキュメントが不備であったり知識の共有がうまく回せなければ、単純であるはずの作業が大きな負荷になってしまうこともあります。

機能追加が困難（Stage 2）

スタートアップがユーザーインターフェース（UI）の改善やカスタマイズをしようとしたとき、アーキテクチャ負債またはインフラ負債が原因で顕在化していました。選定したアーキテクチャやインフラが、次に実現したいUIとマッチしていなかったときの現象です。PCブラウザを念頭にフレームワークを選定したため、アプリ版開発に支障が出る、などです。

プロダクト進化に制約（Stage 2）

こちらも、アーキテクチャ負債やインフラ負債に起因して顕在化する悪影響です。

成長フェーズ（Stage 3）

プロダクト-マーケット フィットを実現し、ユーザーも獲得したため、事業を拡大してゆくフェーズです。プロダクトの機能を拡張していったため、既にコード規模も膨張しており、開発体制も大規模化しています。本研究では5種類の悪影響が観測されています。

保守作業にかかる時間の増大（Stage 3）

当初のデザイン（設計）やアーキテクチャが現在の事業規模を支えきれなくなってきています。 デザイン（設計）負債や アーキテクチャ負債が原因です。

機能追加が困難（Stage 3）

成長フェーズでの機能追加は、インフラ負債とくに開発インフラであるフレームワークに起因する悪影響が観測されました。フレームワークのアップデートを怠ったままきてしまい、それが大きな問題を引き起こした事例です。

インフラコスト（Stage 3）

本研究で観測された悪影響はクラウド利用に関連しています。初期に選定したアーキテクチャやインフラが、現在の利用規模にマッチしておらず、負債となって大きな金銭コストを発生させます。

テストコードを書けない（Stage 3）

開発プロセスの中にテスト工程を位置付けていないスタートアップ企業は珍しくありません。プロダクト-マーケット フィットを模索して新機能の開発を続けるなかで、十分なテストまで手が回らないからです。

しかし成長フェーズにまで到達すると、プロダクトの品質が重要になります。今まで蓄積したコードのテストにも着手しますが、それが想像以上に困難なのです。デザイン（設計）負債やテスト負債が関係しています。もともとテストを想定していないコードに対して、後からテストを書くのは極めて困難なのです。

この悪影響を克服するには、蓄積してきたデザイン（設計）負債やテスト負債の返済が必要になります。大規模なリファクタリングによってテスト可能な状態に持っていってから、系統的なテストを導入していくことになります。

まとめ

紹介論文の結論部で著者らは、「リソース不足やプロダクトに関する不確実性など多くの制約のなかで活動しているため、ソフトウェアスタートアップは技術的負債を、その悪影響が顕在化するまで、放置してしまう」 と述べています。

蓄積されてしまった技術的負債は、将来の自分たちからの借金です。本研究は、どのような悪影響がいつごろ顕在化するのかを明らかにしました。多くのスタートアップ企業にとって有益な情報ではないでしょうか。

紹介した論文

• A. Aldaeej and C. Seaman, “The Negative Implications of Technical Debt on Software Startups: What they are and when they surface,” 2022 IEEE/ACM International Workshop on Software-Intensive Business (IWSiB), Pittsburgh, PA, USA, 2022, pp. 23-30, doi: 10.1145/3524614.3528629.