KISS or Die: スタートアップ企業で上級エンジニアが失敗する理由

私の最初のスタートアップ企業は失敗し、周辺のいくつかのスタートアップ企業も失敗しました。私たちは10万ドル分のGCPクレジット、エンタープライズでシステムを構築した創業エンジニア、そして市場投入戦略を持っていました。そして私たちは失敗しました。それは間違った構築をしたからではなく、うまく構築したからでした。それが問題だったのです。

「最適ではない」と感じられるテックスタックと格闘している間に、私たちは最も重要なもの、つまり時間、勢い、そして戦略的なチャンスを失いました。

この話は常識のない人々についてではありません。私には常識があり、物事をシンプルに保つべきだということも知っていました。しかし、あなたの思考モデルが状況に合わないとき、すべての常識は吹き飛んでしまいます。あなたは自分を殺す「正しい」決断をしてしまうのです。

これは悪いエンジニアリングについての話でもありません。優れたエンジニアリングがスタートアップ企業を殺す方法についての話です。あなたをシニアにする経験そのものが、最大の負債になる方法。「正しくやる」あるいは「シンプルにやる」ことが、しばしば間違ったやり方になる理由です。

この記事では、思考モデルを紹介し、正しい決断を下し、私がした間違いを避けるのに役立てます。

:::tip 対象読者： スタートアップ企業を立ち上げるか、初期段階のスタートアップ企業に参加するシニアエンジニア。エンタープライズや大手テック企業で5年以上過ごしている場合、これはあなたへの警告です。

:::

\

思考モデル #1 - 「無料」のインフラは最も高価

10万ドル分のGCPクレジットは贈り物のように見えますが、それは罠です。「すでに支払い済み」だからと過剰なエンジニアリングに向かわせます。コンピュートインスタンス、ロードバランサー、コンテナレジストリ、そしてエンタープライズのセットアップが必要なエンタープライズツールを手に入れます。何が必要なのでしょうか？「プッシュしてデプロイ」するボタンです。

確かに、GCP/AWS/AzureでGitHubからVMにデプロイするワークフローを構築することはできます。いくつかの製品はそれに近いです。しかし、それには追加の手順が必要です：Cloud Buildの設定、IAMロールの設定、デプロイメントスクリプトの作成、シークレットの管理、ヘルスチェックの設定など。実際の製品をデプロイする前に、デプロイメントインフラの構築に時間を浪費します。

一方、RailwayやFly.ioのようなプラットフォームは、スタートアップ企業が実際に必要とするものを提供します：GitHubからの即時デプロイが可能な永続的なVM。できるだけ簡単に：コードをプッシュすると、デプロイされます。環境変数、SSL、ロードバランサー、ログなどを備えたすぐに使えるVMです。「無料」ではありませんが、準備ができています。

無料クレジットは「すでに支払い済み」だからと過剰なエンジニアリングに向かわせます。最も価値のあるリソースである時間を費やしながら、お金を節約していると自分自身を納得させるのです。

\

思考モデル #2 - 「最小限」≠「シンプル」

伝統的なKISSの原則は、ソフトウェアをシンプルに保つよう教えています。しかしスタートアップ企業では、それは間違ったターゲットです。ソフトウェアをシンプルに保つのではなく、解決策をシンプルに保つべきです。

真のシンプルさは、コードの複雑さではなく、総労力で測るべきです：

総労力 = 初期構築 + メンテナンス + デバッグ + 機能追加 + セキュリティアップデート + スケーリング変更

ゼロから構築すると、これらすべてを永遠に所有することになります。サービスを使用すると、これらのほとんどがゼロになります。「膨大な」第三者サービスは、実際には総労力を最小化するためのシンプルな解決策なのです。

私のOAuthの例

私たちの創業エンジニアは、「未知のライブラリ」を使用する代わりに、OAuthをゼロから構築することを決めました。1週間後、彼はPRを提出しました：JWTトークン、リフレッシュトークンのローテーション、セッション管理、ロールベースのアクセス制御を備えたクリーンなOAuth実装。依存関係なし、ベンダーロックインなし、私たちが制御するコードだけです。

私はそのPRを拒否しませんでした。そしてこれは間違いでした。1週間の作業を捨てることはモラルを崩壊させるでしょう。しかし、それはコードの複雑さを生み出し、間違ったレールに乗せてしまいます。さらに、事前にアプローチについて議論しなかったことが私たちの本当の間違いでした。私たちはエンジニアリングのプライドに戦略的な決断をさせてしまったのです。

その後、クライアントはMicrosoft OAuthとGoogle OAuthを必要としました。カスタム実装は、リファクタリング、リフレッシュトークンのローテーション、エッジケース、RBA、その他のことに数日を要しました。各「シンプルな」追加には、私たちのカスタム認証の深い理解が必要でした。すべてのセキュリティアップデートは私たちが実装する必要がありました。すべての新しい要件は私たちがコーディングする必要がありました。

原則

典型的なシニアエンジニアの間違い：成果ではなく制御を最適化すること。スタートアップ企業では、現実はシニアエンジニアの考え方を完全に逆転させる必要があります：

1. 考えるのをやめる：「これはほんの数日のコーディングだ」 \n 考え始める：「これは実際の製品をコーディングしない数日だ」
2. 考えるのをやめる：「これを簡単に構築できる」 \n 考え始める：「構築しないことで簡単に解決できる」
3. 考えるのをやめる：「第三者サービスは複雑さを増す」 \n 考え始める：「第三者サービスは複雑さを吸収する」

\

\

思考モデル #3 - 快適な選択

私たちは創業エンジニアが深く知っていたため、Angularを選びました。賢明な決断ですよね？自分の強みを活かし、質の高いコードを出荷する。フレームワークは良かったのですが、問題はそのエコシステムでした。

エコシステムの罠

Angularは優れており、私たちのエンジニアはそれで何でも構築できました。

しかし「何でも」は始めるだけで時間がかかりました。デプロイメント、認証、基本的なUIコンポーネントのセットアップは、単一の機能を書く前に無限の設定を意味しました。私たちがAngular Materialのテーマをデバッグしている間、競合他社は（そしてそうするでしょう）Next.js + Vercelを使用して、すでにユーザーをオンボーディングしていました。

Next.js + Vercelのパスと比較してみてください：初日にnpx create-next-appでスケルトンアプリをデプロイし、Clerk認証とshadcn/uiコンポーネントを追加し、初日に実際の機能を出荷します。同じ目的地、まったく異なる旅です。

なぜこれが起こるのか？

違いはフレームワークの品質ではなく、エコシステムの最適化です。Next.js/Reactは、他のスタートアップ企業向けのツールを構築するベンチャー企業に支えられています：

• UI: shadcn/ui - コピー、ペースト、出荷
• 認証: Clerk/Supabase - 数分で設定
• デプロイ: Vercel - gitプッシュが本番環境と同等
• その他すべて: スタートアップ企業が必要とするものなら、誰かがサービスを構築しています

Angularのエコシステムはエンタープライズに対応しています：強力で、柔軟で、無限にカスタマイズ可能。50人のチームには完璧（？）ですが、3人のチームには毒です。

\

思考モデル #4 - コアを構築し、コンテキストをレンタルする

しかし、適切なツールを持っていても、最後の罠があります：できるからという理由で、すべきではないものを構築する衝動です。この罠は技術的に強いチームと、私たちが想像できる以上のスタートアップ企業を殺します：すべきではないのに、できるからという理由で誰も求めていないものを構築することです。

私たちは誰も必要としない機能に少なくとも合計で1ヶ月を費やしました。Auth0が存在するのにカスタムOAuth。Redis + Celeryが存在するのにPostgresベースのジョブキュー。コンソールがうまく機能していたのに初日からTerraform。各決定は生産的に感じましたが、それぞれが顧客との対話や他の顧客開発のような実際の課題に直面するための自己妨害でした。

パターンはシンプルです：顧客があなたを選ぶ理由にならないなら、それを構築しないでください。

私の50ドルルール

SaaSの費用が月額50ドル未満なら、それを構築する余裕はありません。あなたの時間は高すぎます。

カスタムOAuthの構築には、メンテナンスと異なるOAuthプロバイダーの追加に合計1〜2週間かかります。スタートアップ企業のバーンレートでは、それはエンジニアリング時間で5,000〜15,000ドル、または機会損失の時間です。Auth0は最大25,000人のアクティブユーザーまで無料で、その後は月額35ドルです。一度構築するのにかかるコストで、35年間Auth0を支払うことができます。

つまり、これはお金の問題ではなく、優先順位と機会費用の問題です。

例外

私の意見では、それなしではユーザーについて学べない場合にのみ構築してください。簡単な例は、ユーザーがAI生成レポートに対価を支払うかどうかをテストする必要がある場合です。需要を証明する最もシンプルなバージョンを構築してください。そして他のすべてはスリップしようとします。はい、インフラをスキップし、「正しくやる」をスキップし、機能を出荷しないベストプラクティスをスキップし、テストをスキップしてください。繰り返しますが、コードを書く際にはできるだけ怠惰になってください。

私が実際に使用しているもの

• 認証: Clerk（React-native、より良いDX）またはAuth0（B2B重視、エンタープライズ対応）
• メール: Resend（開発者第一）またはSendGrid（実績あり）
• 分析: PostHog（スケールまで無料）
• モニタリング: Sentry（エラーに対して無敵）
• ホスティング: CloudflareまたはVercel（Next.jsに完全に依存する場合）

これらは推薦ではなく、スピードを最適化した私自身の選択です。あなたのスタックは異なるかもしれませんが、この原則は変わりません。

\

\

結論

LLMは構築を商品化しました。Claudeを持つどんなジュニアでも、あなたが誇りに思うカスタム認証システムを作成できます。あなたの価値はもはや何を構築できるかではなく、何を構築すべきでないかを知ることにあります。

リーダーシップとは、シグナルとノイズを分離する能力です。真のシニアであることは、自分の知識の90％を無視し、明日のアーキテクチャではなく、今日の解決策を出荷する規律を持つことを意味します。