多くのソフトウェア系スタートアップ企業はその初期段階において、技術的負債（technical debt、テクニカルデット）を蓄積しがちです。プロダクトリリースのスピード重視、そして小規模で経験の浅い開発体制もそれに拍車をかけます。
ソフトウェア系スタートアップは以下の３つのフェーズを経て成長してゆくと考えられています：
- 誕生（Inception）：創業から最初のプロダクト（MVP）のリリースまで
- 安定化（Stabilization）：プロダクトがユーザーを獲得し、「プロダクト-マーケット フィット」を実現するまで
- 成長（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」（ソフトウェアスタートアップにおける技術的負債：どんな悪影響が、いつ顕在化するのか）です。今回はこちらの内容を解説していきます。
技術的負債の悪影響
Aldaeejらは、スタートアップ企業5社から合計17名の創業者／開発者を対象とする半構造化インタビューを実施し、分析対象データを入手しました。対象となったスタートアップ企業は、創業者または共同創業者1名以上と、開発者1名以上が参加できた会社のみに絞っています。そして、インタビューでの発言録（transcript）を対象とするテーマ分析を実施し、技術的負債の悪影響として共通的に出現する以下の６つのテーマを抽出しました。
- リリース後のバグ増加（Increased post-release bugs）
- 保守作業にかかる時間の増大（Extra time to perform maintenane activities）
- エンハンス不能（Inability to perform enhancements）
- プロダクト進化に制約（Evolution restrictions）
- インフラコスト（ Infrastructure costs）
- テストコードを書けない（Difficult-to-write test code）
これらは技術的負債の悪影響としては知られているものです。本研究ではさらに、これらの悪影響が顕在化するタイミングと悪影響の形態について明らかにしたところに価値があります。
成長3フェーズと技術的負債の悪影響
上で挙げた、技術的負債の6種類の悪影響が顕在化するタイミングは、スタートアップ成長の3フェーズに基づいて、以下のようにまとめられています。
ここでは、各フェーズごとに何が起こっているかという視点で解説します。
誕生フェーズ（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.
コメント