開発方針を相談する

PMF 前に技術負債をどこまで許容するべきか

捨ててもよい負債と、初期から残してはいけない負債を分ける。

この記事の結論

「PMF 前なので、コードは雑でいいですよね」

スタートアップ CTO や創業者からよく聞く言葉です。半分は正しいです。事業仮説が外れれば、コードは捨てる前提 なので、綺麗に作るより、速く検証するほうが価値があります。

ただし、すべてを雑にすると、PMF が見えてきたタイミングで詰みます。データが壊れている、認証が抜けている、課金で事故が起きる。これらは「PMF 後に直せばいい」では済まない領域です。

この記事では、PMF 前のスタートアップで、許容できる技術負債 と 許容してはいけない負債 を分けて整理します。

PMF 前の開発で大事なこと

PMF (Product-Market Fit) 前の開発で最も大事なのは、事業仮説の検証速度 です。コードの綺麗さや、テストカバレッジ、ドキュメントの量よりも、

が優先されます。

Anthropic の創業者向けプレイブックでも、AI ネイティブ・スタートアップの MVP 段階では、アーキテクチャとセキュリティの実装に集中して技術負債を抑える べきだが、それ以外は速度優先、という方向性が示されています (The founder's playbook / Anthropic)。

「全部を綺麗に作る」のは、PMF 後のリソースがある段階の話。PMF 前は 「壊れてはいけない部分だけ守る」 が現実解です。

許容できる負債

PMF 前で許容できる負債を整理します。

UI の粗さ

手運用

分析の簡易化

テストカバレッジの低さ

ドキュメントの少なさ

これらは 「事業が伸びたら直す」「事業が止まったら捨てる」 で問題ない領域です。

許容してはいけない負債

逆に、PMF 前でも絶対に手を抜いてはいけない領域があります。

データモデル

理由: 後から直すと、過去のデータが復元できない。事業が伸びるほど、データモデルの作り直しコストが指数的に増えます。

認証

理由: 認証の不備は、情報漏えいに直結。事故が 1 件起きると、それまでの売上が消えるレベルのインパクトがあります。

権限

理由: 「他社のデータが見える」という事故は、SLA 違反、損害賠償、契約解除につながります。

セキュリティ

理由: 一度漏えいすると、データを取り戻せません。

課金

理由: 「課金で事故った」という事故は、信頼失墜と返金対応で大きな損失になります。

これらの領域で負債を作ると、PMF 後に直そうとした時には、すでに本番顧客のデータと業務が動いている ので、直すこと自体が事故リスクになります。

詳しくは Vibe Coding で作ったシステムが、本番で使えない理由 で 8 つの破綻パターンとして整理しています。

AI 生成コードで増えやすい負債

AI ツール (Cursor / Claude Code / Codex) で実装が速くなった結果、負債が積み上がるスピードも速くなりました。具体的には:

Anthropic のセキュリティ解説でも、AI を使った脆弱性管理のボトルネックは 「発見」ではなく「検証・トリアージ・修正」 に移っている、と整理されています (Using LLMs to Secure Source Code / Anthropic)。AI で速く書ける時代こそ、判断と修正に人間の時間を集中させる必要がある ということです。

ここまでで「自社の技術負債を整理したい」と感じたら、診断フェーズから相談するのが現実的です。

技術負債のレビューを相談する →

負債を管理する仕組み

PMF 前でも、負債を 意図的に管理する 仕組みは入れておきます。完璧に綺麗にする必要はありませんが、何が負債で、いつ直すかは把握しておきます。

ADR (Architecture Decision Records)

重要な技術判断を、1 ページの文書に残します。「なぜこの設計にしたか」「将来直すべきか」を書いておくと、後で見直すときに迷いません。

CLAUDE.md / AGENTS.md

「触ってはいけないファイル」「直したい部分」をプロジェクト文脈ファイルに書きます。AI も人間も、ここを参照することで負債を踏まない判断ができます。

月次の負債レビュー

月 1 回、「これは直さないと事故るか」を判断する 30 分の会議を持ちます。負債リストを更新し、優先順位を決めます。

「直す予算」を月次で確保

毎月、開発工数の 10〜20% を 負債解消の予算 として確保します。これがないと、機能追加だけが優先され、負債は積み上がる一方になります。

致命的な負債を判断するチェックリスト

「これは致命的か、許容できるか」を判断するチェックリストです。

観点致命的許容できる
データ過去データが壊れる可能性UI 表示の不整合
認証他人になりすませるUI のログイン体験が悪い
権限他社・他部門のデータが見える自分のデータの表示順がおかしい
課金二重課金、返金漏れ領収書の文面が古い
セキュリティSQL インジェクション、漏えいパスワード強度が弱い設定
個人情報ログに PII が残るユーザー名の表示桁数

致命的なものは 即時対応、許容できるものは 記録だけ残して PMF 後 に扱う、と分けます。

min's での負債管理スタイル

min's では、技術負債の管理を以下の形で支援しています。

診断 (1〜2 週間)

直す優先順位の提案

修正並走

費用感は、診断 50〜100 万円、修正は規模に応じて 100〜500 万円が典型的です。

技術負債のレビューを相談したい方へ

min's では、PMF 前のスタートアップの技術負債診断、致命的な負債の特定、修正並走を支援しています。

以下のような状態であれば、ご相談ください。

次に読む記事

参考

動くデモで終わらせず
本番まで持っていく開発を

AI で作りかけたもの、止まりかけている開発、新しいプロダクトの構想。 まずは現状を整理するところから、ご相談ください。

開発方針を相談する概算見積もりを依頼する