スタートアップの技術的負債との付き合い方｜壊さず、止めず、少しずつ改善する

スタートアップの案件に参画して、コードベースを初めて見たとき。

「...これは、厳しいな。」

テストがない。型定義がゆるい。命名規則がバラバラ。同じ処理が3箇所にコピペされている。READMEに書いてあるセットアップ手順が動かない。

スタートアップの開発現場では、こうした技術的負債に出会うことが珍しくありません。そしてエンジニアとしての本能が「全部書き直したい」と叫びます。

でも、ちょっと待ってください。

技術的負債はなぜ生まれるのか

スタートアップの優先順位

技術的負債はサボった結果ではないことがほとんどです。スタートアップでは、限られたリソースの中でプロダクトを市場に出すことが最優先されます。

投資家へのデモが来週ある → テストを書いている時間はない
ユーザーから機能要望が殺到 → リファクタリングより新機能
資金が尽きる前にPMF（Product Market Fit）を見つけたい → 完璧なアーキテクチャより速度

スタートアップの開発文化でも解説していますが、スタートアップは「正しく作る」より「速く作って検証する」が優先される環境です。技術的負債は、その結果として蓄積されたものです。

負債にも種類がある

技術的負債は一括りにできません。種類によって対応の優先度が変わります。

種類	例	リスク	対応優先度
セキュリティに関わるもの	認証の実装漏れ、SQLインジェクション	高	即対応
データに関わるもの	スキーマの設計ミス、マイグレーションの不整合	高	早めに対応
スケーラビリティに関わるもの	N+1問題、インデックスの欠如	中〜高	ユーザー増加前に対応
保守性に関わるもの	テスト不足、型定義の欠如、命名の不統一	中	段階的に改善
コードスタイルに関わるもの	フォーマットの不統一、不要なコメント	低	余裕があるときに

「全部書き直したい」衝動をコントロールする

なぜ書き直しは危険か

新しく参画したエンジニアが「このコードは酷いから全部書き直しましょう」と提案するケースがあります。気持ちはわかりますが、フルリライトは多くの場合、悪手です。

理由:

今動いているコードには、見えないビジネスロジックが詰まっている。書き直す過程で、意図せず挙動が変わるリスクが高い
書き直しの間、プロダクトの開発が止まる。スタートアップにとって開発の停止は致命的
書き直したコードが「前よりマシ」になる保証がない。新しい負債を生むだけのこともある
チームのモチベーションに影響する。「このコードは酷い」は、書いた人への否定になり得る

新規参画者が避けるべきこと

スタートアップに参画して最初の1〜2ヶ月は、既存のコードやアーキテクチャを批判する発言は控えるのが賢明です。

そのコードが書かれた背景（時間的制約、当時のチーム体制、ビジネスの優先順位）を理解しないまま「ダメだ」と断じると、チームとの信頼関係を損ないます。

まずはコードベースを読み、歴史を理解し、チームの文脈を把握してから、改善提案を「相談」の形で持ちかけるのが適切です。

現実的な改善アプローチ

ボーイスカウトルール

「来たときよりも美しく」。ボーイスカウトルールは、触ったコードを少しだけ改善してからコミットするプラクティスです。

機能を追加するときに、触ったファイルの型定義を追加する
バグを修正するときに、そのバグが再発しないテストを1つ書く
コードレビューで気づいた命名の問題を、ついでに直す

1回の改善は小さくても、チーム全員がこれを習慣にすれば、コードベースは徐々に良くなっていきます。大規模なリファクタリングの時間を取らなくても、日常的に改善が進むのがこのアプローチの強みです。

ストラングラーフィグパターン

レガシーなコードを一度に書き直すのではなく、新しい実装で古い部分を少しずつ置き換えていくパターンです。

例えば、古いAPIエンドポイントを新しい設計に移行する場合:

新しいエンドポイントを既存のものと並行して作る
フロントエンドを1画面ずつ新しいエンドポイントに切り替える
すべての画面が切り替わったら、古いエンドポイントを削除する

このアプローチならプロダクトを止めることなく、段階的に改善できます。

テストを後から追加する戦略

テストがないコードベースにテストを追加する場合、全てのコードにテストを書く必要はありません。リスクの高い部分から優先的に書いていきます。

優先順位の目安:

決済・認証・権限管理：バグが直接的な損害に繋がる部分
頻繁に変更される部分：変更のたびにデグレリスクがある
複雑なビジネスロジック：人間の目では正しさを確認しにくい部分
外部APIとの連携部分：外部の変更に影響を受けやすい

「テストカバレッジ100%」を目指す必要はありません。ビジネスリスクの高い部分のテストがあるだけで、チームの安心感は大きく変わります。

チームで技術的負債に取り組む

負債を「見える化」する

技術的負債の最大の問題は、エンジニア以外には見えないことです。PdMやCEOに「技術的負債がヤバい」と言っても、具体的に何がどうヤバいのかが伝わりません。

対策として、以下のように「見える化」すると、非エンジニアのステークホルダーにも理解してもらいやすくなります。

影響をビジネス指標で説明する：「この負債を放置すると、新機能の開発に通常の1.5倍の時間がかかります」「ここを改善すればページの読み込みが2秒短くなり、ユーザーの離脱率が下がります」
優先順位をつけて提案する：「全部直す必要はありません。この3つだけ対応すれば、開発速度が戻ります」
工数を見積もる：「この改善は2日でできます。新機能の開発を2日遅らせる代わりに、今後の開発効率が上がります」

改善の時間を確保する方法

スタートアップでは「リファクタリングだけの時間」を確保するのが難しいことが多いです。現実的なアプローチは以下の通りです。

新機能の開発と一緒にやる：機能追加のついでに、触る範囲のリファクタリングも行う（ボーイスカウトルール）
スプリントの一部を改善に充てる：「毎スプリントの20%は技術改善に使う」とチームで合意する
大きな改善はロードマップに入れる：セキュリティやスケーラビリティに関わる改善は、機能開発と同列でスケジューリングする

いずれの場合も、チームやPdMと合意した上で進めることが大切です。エンジニアの独断で「今週はリファクタリングします」と決めると、プロダクト側のスケジュールに影響が出ます。

フリーランスとしての技術的負債への向き合い方

正社員との違い

フリーランスとしてスタートアップに参画する場合、正社員と比べて以下の点が異なります。

契約期間がある：3ヶ月〜6ヶ月の契約期間内で成果を出す必要がある
長期的なコミットが前提ではない：自分がいなくなった後もチームが困らない形で改善する
立場として「外の人間」：チームの文化や歴史を尊重した上で提案する

フリーランスが貢献できるポイント

フリーランスだからこそ提供できる価値があります。

外部の視点 チームの中にいると見えなくなる問題が、外から参画した人間には見えることがあります。「他のプロジェクトではこういうやり方をしていました」という情報は、チームにとって貴重です。ただし、「前の現場ではこうだった」という言い方は避け、「こういう方法もあるかもしれません」と提案の形にすると受け入れられやすいです。

特定領域の集中改善 フリーランスの契約期間を「特定の技術的負債を解消するプロジェクト」に充てるケースもあります。「3ヶ月でテスト基盤を整える」「APIのリアーキテクチャを担当する」など、明確なゴールを持った改善に集中できるのはフリーランスの強みです。

ドキュメントの整備 自分がキャッチアップする過程で作ったメモやドキュメントは、次に参画する人にとっても有益です。「自分がいなくなっても、このドキュメントがあればキャッチアップできる」状態を残すことは、チームへの大きな貢献になります。

まとめ

技術的負債はサボった結果ではなく、スタートアップの優先順位の結果
「全部書き直す」は多くの場合悪手。プロダクトを止めず、段階的に改善する
新規参画者は、まずコードの歴史と背景を理解してから改善を提案する
ボーイスカウトルール（触ったところを少し改善）が最も持続可能
テストは全部に書かなくていい。ビジネスリスクの高い部分から
技術的負債を非エンジニアに伝えるには、ビジネスへの影響で説明する
改善の時間はチームで合意して確保する。エンジニアの独断で進めない
フリーランスとしての貢献は、外部の視点・集中改善・ドキュメント整備

スタートアップ案件への参画に興味がある方はスタートアップ×フリーランス参画ガイドを、開発文化の違いはスタートアップの開発文化をご覧ください。