「技術負債」の正体とスタートアップで問題になるパターン

「技術負債は必ず存在する」と認識している投資家・M&A担当者は多いです。しかし「どの種類の負債が、どのフェーズに生まれ、なぜスタートアップでは特に問題になるのか」まで言語化できる方は多くありません。技術DDにおいて技術負債を評価するとき、その正体を分類せずに「ある・ない」で判断しても意味がありません。

本稿では、技術負債を3分類で整理し、スタートアップ固有の蓄積メカニズムを解説した上で、投資・買収判断に使える評価フレームワークを提示します。

技術負債の3分類

よく参照されるのがMartin Fowlerが2009年に提唱した「技術的負債の4象限（意図的/偶発的 × 慎重/無謀）」です。負債の性質を整理するフレームワークとして広く知られています。しかし投資・DD文脈では、「どこから生まれたか」という発生源の視点が加わると、より実践的な評価ができます。

図1：技術負債の3分類

1. 意図的な負債

意思決定者が将来のコストを知りながら、意図的にトレードオフを選んだ結果生まれる負債です。スタートアップが初期PMF検証のために設計を省略した場合や、リリースデッドラインのために一時的な実装を採用した場合がこれに当たります。

具体的な発生場面の例を挙げると、「投資家へのデモに間に合わせるためエラーハンドリングを省略したまま本番リリースした」「ユーザー認証の設計を後回しにしてとりあえずIDとパスワードをそのまま扱う実装で出した」「スケーラビリティを無視したシンプルなデータ構造で検証を優先した」といったケースがこれに当たります。いずれも「知った上で選んだ」判断です。

意図的な負債の本質は「借金」であり、それ自体は悪ではありません。問題になるのは、返済計画がないまま元利が積み上がるケースです。

2. 偶発的な負債

知識・経験の不足から、意図せず蓄積された負債です。「後から知れば分かる」ことを、当時の開発者が知らなかった結果として生まれます。

代表的なのは、要件が曖昧なまま実装を進めた結果の設計ミス、ライブラリ選定の誤り、テスト戦略の欠如などです。

発生例として：バックエンドエンジニアがフロントエンドも兼任することになりReactのstate管理パターンを知らずにコンポーネント間のデータ受け渡しを深くネストさせてしまったケース、ORMを使ったDB操作でN+1問題（ループ内で毎回クエリが発行される）に気づかず本番でパフォーマンス障害を引き起こしたケース、セッション管理の設計を誤ったまま認証機能を実装し後から基盤ごとの作り直しが必要になったケース——いずれも「知っていれば避けられた」という共通点があります。

偶発的な負債は「学習コスト」として一定は許容できますが、組織として同じ過ちを繰り返している場合は、技術力・開発プロセス自体に問題があると判断できます。

一方で、AI コーディングアシスタントの普及によって、この類型の負債は今後徐々に低減していく可能性があります。GitHub Copilot や Claude Code などのツールは、N+1 問題の検出・セキュリティ上の誤りの指摘・より適切な設計パターンの提案をリアルタイムで行えます。「知っていれば避けられた」ミスの一部は、AI が補完することで発生しにくくなります。ただし、AI の提案を無批判に採用することで新たな偶発的負債が生まれるリスクもあるため、レビュープロセスの重要性は変わりません。

3. 環境変化由来の負債

最もスタートアップで見落とされやすい類型です。当時は適切だった設計・技術選択が、事業のスケールや市場環境の変化によって負債に転化するケースです。

スケールの壁: 数百ユーザーを前提に設計したデータベース構造が、数十万ユーザー到達時にボトルネックになる
組織の壁: 2〜3人で共有していたコードベースが、10人のチームで並行開発する際にマージコストを爆発させる
外部依存の崩壊: 当時は最良の選択だったSaaSやOSSが、方針変更・価格変更・サポート終了によって負債化する

環境変化由来の負債は、設計した当時は正解だったという点が重要です。過去の開発者を責める問題ではなく、成長に伴って発生する構造的なコストとして評価する必要があります。

スタートアップ特有の負債蓄積メカニズム

大企業のソフトウェア開発と比べると、スタートアップには技術負債が急速に蓄積しやすい構造的要因があります。

図2：スタートアップで技術負債が蓄積しやすい4つの要因

速度優先の組織文化

「リリースを遅らせるくらいなら技術的に不完全でも出す」という判断は、初期フェーズのスタートアップでは合理的です。市場からのフィードバックなしに設計を完璧にしても、ピボットが必要になれば無駄になります。

しかしこの文化が固定化されると、技術的負債を取る判断が意思決定として可視化されなくなります。「いつかやる」という暗黙の了解が共有されるが、いつまでも実行されない状態が続きます。

CTOが不在または兼任

スタートアップの初期では、代表がCTOを兼ねていたり、エンジニアが実質的な技術責任を持ちながら正式な役割を持っていないケースがあります。

この状態では技術方針の一貫性が保ちにくく、採用したエンジニアそれぞれが異なるアプローチで実装を進める結果、スタイルと設計思想が混在したコードベースが生まれます。この種の負債は、コードの「量」ではなく「複雑さ」として蓄積するため、後から可視化しにくいです。

ピボットの痕跡が残り続ける

スタートアップはピボット——ビジネスモデルや機能の転換——を繰り返します。しかし多くの場合、旧機能のコードは完全に削除されず「使われていないが存在している」状態で放置されます。

これをデッドコードと呼びますが、放置されたデッドコードは以下のコストを生みます。

新規開発者の学習コスト（「これは何のために存在するのか」）
依存関係の複雑化（デッドコードが生きているコードと絡み合う）
セキュリティリスク（メンテナンスされていないコードへの依存）

初期メンバーへの知識集中

創業エンジニアや初期メンバーは、なぜその設計を選んだかという背景知識を持っています。しかしその知識はドキュメントに残されず、頭の中に留まることが多いです。

チームが拡大し、初期メンバーが抜けると、その設計の文脈が失われ、後続の開発者が「なぜこうなっているのか分からない」まま改修を続けます。これがさらなる設計の複雑化を招きます。

各要因への実践的な向き合い方

ここまで挙げた4つの要因は、スタートアップが成長する過程でほぼ避けられないものです。問題なのは蓄積自体ではなく、蓄積を認識せず放置することです。それぞれの要因に対して、完璧な解決でなくても実践できることがあります。

速度優先の開発でもできること — トレードオフを取った事実を記録することです。「この実装は○○のため暫定対応、△△フェーズで再設計する」という一文をIssueやPRのコメントとして残すだけで、負債は「見えない借金」から「管理できる借金」に変わります。Notion・GitHub Issues・Linear のいずれでも構いません。

CTOが不在でも・兼任でもできること — コーディング規約とレビュー基準の策定・適用は、今やAIに委ねられる部分が大きいです。ESLint・Prettier などの静的解析ツールに加え、GitHub Copilot や Claude Code をレビュープロセスに組み込むことで、専任のCTOがいなくても一定の設計品質を自動的に担保できます。人間が判断すべき設計の意思決定に集中し、規約チェックはAIに任せる構造が現実的です。

ピボットの痕跡があっても — 使われていないコードを一掃する必要はありません。まず「デッドコードである」とコメントを付けること、そして四半期に一度でも不要コードの棚卸しスプリントを設けることが現実的な対処です。完全な削除より、まず可視化が先決です。

知識が集中していても — ADR（Architecture Decision Records: 設計上の意思決定記録）を残す習慣をつけることです。「なぜこの設計を選んだか・他の選択肢と比べたトレードオフは何か」を短い文章で記録するだけで、初期メンバーが抜けた後のコンテキスト損失を大幅に減らせます。

要するに、負債の蓄積メカニズムを知ること自体が、投資家・M&A担当者にとっても価値があります。「この組織がどの要因で負債を積んでいるか」を見極めることで、返済難易度と必要なリソースをより精度高く見積もれるからです。

ROIで測れない負債をどう評価するか

技術負債の難しさの一つは、財務上の負債と違い、元本と利息を定量化しにくい点です。「技術負債が○円ある」とは言えません。

では、投資・DD文脈でどう評価するのでしょうか。以下の3つの観点を組み合わせます。

開発速度の変化トレンド

過去6〜12ヶ月のリリース頻度・1機能あたりの開発期間を確認します。チームの規模が変わっていないにもかかわらず、リリース頻度が低下したり開発期間が延伸している場合、負債の蓄積による速度低下が起きている可能性が高いです。

具体的には：「1年前と今を比べて、同規模の機能を作るのにどのくらい時間がかかりますか？」という問いが有効です。

ただし、中小規模のスタートアップでは開発工数を正確に記録していないケースも多く、実測値を得るのが難しい場合があります。その場合は以下の代替的なアプローチが使えます。

Gitのコミット・PR履歴から傾向を読む: リポジトリへのアクセスがあれば、月次のコミット数・PRマージ数の推移は数分で確認できます。同じ人数でコミット頻度が右肩下がりになっているなら、何らかの障壁が生じているシグナルです。
エンジニアへのヒアリング: 「最近、以前は簡単だったのに難しくなったと感じる作業はありますか？」という開かれた問いは、定量データがなくても開発速度の変化を拾えます。
タスク管理ツールのサイクルタイム: JIRA・Linear・GitHubのIssueが使われていれば、チケットのオープンからクローズまでの時間（サイクルタイム）の推移が開発速度の代理指標になります。
経営陣・現場の体感: 「リリースが以前より遅くなったと感じますか？」という問いに対して、経営陣とエンジニアの認識が一致しているかどうかも一つの判断材料です。乖離が大きい場合は、負債が可視化されていない状態を示すことがあります。

テストカバレッジとインシデント頻度

自動テストのカバレッジが低く、リリースのたびに障害が発生している状況は、「変更コスト」が高い状態を示します。

テストカバレッジには主に以下の種類があります。

カバレッジの種類	計測対象	目安
ライン（行）カバレッジ	テストで実行された行の割合	80%以上が一般的な目標
ブランチカバレッジ	if/elseなど各分岐が実行されたか	ラインより厳しい基準
関数カバレッジ	呼び出された関数の割合	重要な関数が漏れていないかの確認
ステートメントカバレッジ	実行された文の割合	ラインカバレッジに近い概念

注意すべきは、「カバレッジ率が高い＝品質が高い」とは限らない点です。アサーション（期待値との検証）がないテストはカバレッジを稼げても実質的な保護にはなりません。DDでは数値だけでなく、「テストが何を守っているか」という質の確認が重要です。コアとなるビジネスロジック・決済・認証まわりのカバレッジが低い場合は特に注意が必要です。

テストのない状態で機能追加を続けると、「直したら別のところが壊れた」という連鎖が増え、開発チームは変更を恐れるようになります（チェンジフォビアと呼ばれます）。この状態になると、表面的にコードの量は増えていても、実質的な開発能力は低下しています。

エンジニアの離職傾向と採用難易度

技術負債が重症化した組織では、技術力の高いエンジニアが先に離職する逆選択が起きます。「このコードベースで働きたくない」という判断は、市場価値の高いエンジニアほど持ちやすいです。

採用面でも、技術負債の多いコードベースはエンジニアのハードルが高くなります。採用候補者のコードレビュー・インタビュー同席時に、コードベースの品質についての反応を見ることが一つの指標になります。

静的解析ツールによる定量評価

上記3つの観点は「結果」を見るものですが、コードベースそのものを計測することで、より直接的に負債の規模を推定できます。エンジニアにアクセスを依頼するか、DDの一環として技術専門家が分析を行う方法です。

循環的複雑度（Cyclomatic Complexity）

Thomas J. McCabeが1976年に提唱した、プログラムの制御フロー内に存在する独立したパスの数を数える指標です。if / for / while / case などの分岐が増えるたびにスコアが加算されます。一般的な目安は「10以下：良好、20超：要注意、50超：危険水域」とされています。

循環的複雑度が高い関数は、単体テストで網羅すべき分岐のパターンが多く、テストを書くこと自体が難しくなります。テストカバレッジが低いコードに循環的複雑度の高い関数が集まっている場合、変更のリスクが最も高い箇所として優先的に評価すべきです。

認知的複雑度（Cognitive Complexity）

SonarSourceが2016年に提唱した認知的複雑度は、循環的複雑度の弱点——「分岐の数は同じでも、ネストの深さで理解しやすさは全く異なる」——を補完するために設計されています。ネストが深いほど重みづけスコアが加算される仕組みで、人間がコードを読むときの認知的負荷をより正確に反映します。

たとえば同じ循環的複雑度5のコードでも、5つの独立したif文が並んでいる場合と、3重ネストの中にif文が入り組んでいる場合では、後者の方が圧倒的に理解しにくいです。認知的複雑度はその差を数値に表せます。

指標	提唱者・年	計測対象	弱点
循環的複雑度	McCabe（1976）	制御フローの独立パス数	ネストの深さを考慮しない
認知的複雑度	SonarSource（2016）	人間の理解難易度	ツールなしでは算出困難

関数・メソッドの複雑度スコアが高い箇所が多数存在する場合、そのコードは変更のたびにバグが混入しやすく、レビューコストも高い状態です。DDでは「高複雑度の関数が全体の何%を占めるか」を一つの指標として用います。

機能数・コード規模からの負債推定

コードベース全体の規模（SLOC: Source Lines of Code）と、機能・クラス・モジュールの数を把握することで、「複雑さの密度」が見えてきます。たとえば、1万行のコードに500関数があるシステムと、同規模のコードに50関数しかないシステムでは、後者の方が1関数あたりの役割が肥大化していて保守しにくい傾向があります。

また、関数・メソッドの平均行数が長い（目安として50行超が多数）場合は、単一責任の原則が守られておらず、変更の影響範囲が読みにくい設計になっていることが多いです。

SonarQube / SonarCloud などの静的解析ツール

SonarQube（OSSのセルフホスト版）や SonarCloud（クラウド版）は、認知的複雑度・重複コード・セキュリティホットスポット・テストカバレッジをダッシュボードで可視化するツールです。CI/CDに組み込まれていれば、PRごとに品質ゲートが走り、負債の増加を自動検知できます。

DDの場面では、対象企業がこうした静的解析ツールを導入・運用しているかどうか自体が、技術組織の成熟度を示すシグナルになります。ツールが入っていない場合でも、コードリポジトリへのアクセスがあれば短時間で初期スキャンを実行できます。他にも Code Climate や GitHub上で動作する CodeQL など、用途に応じた選択肢があります。

ツール	主な用途	形態
SonarQube / SonarCloud	複雑度・重複・セキュリティの総合評価	OSSまたはSaaS
Code Climate	保守性スコア・技術負債時間の可視化	SaaS
CodeQL	セキュリティ脆弱性の深い静的解析	GitHub統合

致命的な負債と許容できる負債の見分け方

すべての技術負債が同じリスクを持つわけではありません。以下の基準で重篤度を分類します。

局所化されているか、全体に広がっているか

特定モジュールや機能に閉じた負債は、リファクタリングの対象を限定できるため返済コストが見積もりやすいです。一方、設計思想が全体に浸透している場合——例えば、セキュリティの考慮が全体を通じて欠落しているなど——は、部分的な改善が困難です。

返済ロードマップが存在するか

「この部分は技術負債だと分かっており、○フェーズで対応予定」という状態は、管理された負債です。返済計画がない場合、負債は経営上の判断対象ではなく「なかったことにされている問題」として扱われています。

DDで「どの技術負債が最も重要で、いつ対処するつもりですか？」と聞いたとき、具体的な回答が出るかどうかは、技術組織の成熟度を測る一つの指標になります。

セキュリティ・コンプライアンスに関わるか

個人情報・決済・医療データを扱うプロダクトで、セキュリティ上の技術負債が存在する場合は即時評価が必要です。この種の負債は、インシデントが発生した際のコスト（対応費用・損害賠償・レピュテーション損失）が返済コストを大幅に上回ります。

投資・買収後に発覚したセキュリティ上の負債は、クローバック（損害賠償）や取引見直しの対象になることがあります。

結論：「致命的な負債」の定義

3つの基準を総合して、以下の条件のいずれかに当てはまる負債を「致命的」と判断します。

段階的返済が不可能: 部分的なリファクタリングでは対処できず、アーキテクチャの全面的な再設計が必要な負債。既存機能を維持しながら並行して移行できないため、事業停止リスクを伴うことがある。
セキュリティ・コンプライアンス上のリスクが即時顕在化するもの: 個人情報漏洩・不正アクセス・規制違反につながりうる負債。発覚後の対応コストが、事前対処コストの数十倍になる。
エンジニア組織の再生産が止まっているもの: 技術負債が深刻すぎて優秀なエンジニアの採用・定着ができない状態。コードベースを改善できる人材そのものを獲得できなくなり、負債が加速度的に悪化する悪循環に入っている。

逆に、これらに当てはまらない——局所化されており、返済計画があり、セキュリティリスクがなく、採用への影響が限定的な——負債は、DDの判断として「管理可能な負債」として扱えます。致命的かどうかの判断は、負債の存在そのものではなく、組織がその負債と向き合える状態にあるかによって決まります。

ケーススタディ：典型的な負債蓄積パターン

パターン1：PMF前後での設計凍結

初期フェーズでPMFを急いだチームが、事業検証後もその「PMF前の設計」のまま機能を拡張し続けるケースです。初期の設計は少数ユーザー向けの検証用であり、スケーラビリティは考慮されていません。

このパターンのシグナル：

データベースにインデックスが不十分で、ユーザー増加に伴いクエリが遅くなっている
認証・権限管理が「とりあえず動く」状態のまま本番運用されている
モノリスの中に機能が詰め込まれ、一部の変更が全体に影響する

対応難易度は高く、設計を全面的に見直すには既存機能を維持しながらの段階的移行が必要です。通常の機能開発と並行して進めるため、数ヶ月〜1年単位のリソースが必要になります。

パターン2：組織スケール時のアーキテクチャ摩擦

チームが3〜4人から10人以上になったとき、コードベースの分担が難しくなるパターンです。1つのリポジトリ・データベース・デプロイパイプラインを全員で共有しているため、変更の衝突・テスト環境の競合・デプロイ待ちが頻発します。

このシグナル：

PRのマージに時間がかかり、マージコンフリクトが常態化している
テスト実行時間が15分を超え、CIの待ち時間が開発のボトルネックになっている
「あのコードは○さんしか分からない」という領域が複数存在する

対応の方向性としては、マイクロサービス化やドメイン分割が一般的ですが、組織構造とアーキテクチャを同時に変えるため、段階的なアプローチが必要です。

パターン3：外部依存の集中リスク

ある特定のSaaS・OSSに依存した設計を採用し、そのサービスが価格改定・機能廃止・買収によって利用継続が難しくなるケースです。

典型例：

特定のメール配信サービスへの強結合
サポートが終了した古いOSSフレームワーク
生成AI APIへの直接依存（モデル変更・価格変更・APIの仕様変更リスク）

この種の負債は、依存対象が変化するまで顕在化しません。DDでは「主要インフラ・SaaSの代替性」を確認し、移行コストと移行難易度を評価することが重要です。

パターン4：外部事業者への開発委託で生じた負債

自社にエンジニアがいない状態で受託開発会社やフリーランスにアプリ開発を依頼し、納品物のコードをそのまま引き継いだケースです。

このパターンが特に問題になる理由は、設計上の意思決定の背景が社内に残っていないことです。委託先がなぜその設計を選んだか、どのような制約の下で実装したか、どの部分が暫定対応かという文脈がコード以外の形で引き継がれていないため、後から改修する際のコストが大きく膨らみます。

このパターンのシグナル：

ドキュメントがなく、コードのコメントも少ない
社内に「このコードをゼロから読める」エンジニアがいない
委託先との契約終了後、バグ修正や機能追加の見積もりが高騰した
コード品質の基準（テスト・命名規則・設計方針）が社内の他のコードと著しく乖離している

DDでは「誰が書いたか・引き継ぎドキュメントはあるか・社内に読めるエンジニアがいるか」を確認することが出発点になります。最悪のケースでは、委託先のコードが属人化・ブラックボックス化しており、事実上の作り直しが必要な場合もあります。

パターン5：ノーコード・ローコード・不慣れな技術スタックの採用

非エンジニアや不慣れなエンジニアが迅速に立ち上げるために、ノーコードツール・ローコードプラットフォーム、あるいはチームが習熟していない技術スタックを採用したケースです。

ノーコード・ローコードツール（Bubble、Webflow、Adalo 等）は初期立ち上げには有効ですが、事業が成長してプロダクトの複雑度が上がると、以下の問題が顕在化します。

カスタマイズ限界: プラットフォームの制約に縛られ、必要な機能が実装できない
ベンダーロックイン: プラットフォームの価格改定・サービス終了が直接事業リスクになる
移行コストの不可視化: コードへの移行を検討した際、「何をどう作り直すか」の設計費用が別途発生する

不慣れな技術スタックの問題も類似しています。「流行っているから」「採用候補者が使っていると言ったから」という理由でチームが習熟していない言語やフレームワークを採用した場合、実装の品質が低く、後任エンジニアが理解できないコードが量産されます。

DDで確認すべきポイントは「現在の技術スタックをチームが選んだ理由」と「そのスタックに習熟したエンジニアがチームに何人いるか」です。理由が曖昧で習熟者が少ない場合、環境変化由来の負債に準じた評価が必要です。

まとめ：技術負債を「分類して評価する」習慣

技術負債は「ある・ない」で判断する対象ではなく、「どの種類が・どのフェーズで・どの規模で蓄積しているか」を分類して評価するものです。

分類	発生要因	評価の視点
意図的な負債	スピード優先のトレードオフ	返済計画の有無
偶発的な負債	知識・経験の不足	組織的な改善ループの有無
環境変化由来の負債	成長・外部変化	再設計計画と優先順位

スタートアップの技術DDでは、コードの品質そのものより、その負債を認識・管理・返済する能力が組織に備わっているかを評価することが本質的です。

技術負債の基本概念については技術負債とは結局何か：投資家・経営者向けの再定義も参照ください。技術DDにおける負債以外の評価軸については技術デューデリジェンスの全体像と7つの評価軸で整理しています。

投資先・買収対象の技術組織の評価や技術DDの伴走支援についてはTiedPro 投資家向けサービス、またはお問い合わせからご相談ください。

よくある質問

Q. 技術負債の評価はエンジニアでないとできませんか？

分類と重篤度の評価は、非エンジニアでも一定程度可能です。「返済計画があるか」「開発速度のトレンドはどうか」「誰が知識を持っているか」は経営・財務の視点から確認できます。ただし、具体的な技術構造（依存関係の密度・テスト戦略・セキュリティ設計）の評価には技術専門家の同行が有効です。

Q. 技術負債の返済にはどのくらいのリソースが必要ですか？

規模と種類によって大きく異なります。局所化された偶発的な負債であれば、開発リソースの15〜25%を3〜6ヶ月投じれば改善できるケースが多いです。設計全体に広がった構造的な負債は、1〜2年の継続的な取り組みが必要になることもあります。返済コストの見積もり自体を投資判断の材料とするため、DDの段階でエンジニアと詳細な棚卸しを行うことを推奨します。

Q. 技術負債が多い企業への投資は避けるべきですか？

必ずしもそうではありません。重要なのは「管理されているか」です。技術負債を認識した上で、優先順位をつけて返済計画を持っている組織は、むしろ技術経営の成熟度が高いと評価できます。問題になるのは、負債の存在を把握していないか、把握していても返済の意思・能力がない場合です。