初期スタートアップを静かに沈める SaaS 開発の9つの失敗

わざと SaaS プロダクトを間違って作る人はほとんどいません。初期スタートアップを沈める失敗とは、プレッシャーの中で賢い人々が下す、静かでもっともらしく聞こえる判断であり、その時点ではどれも正しく感じられます。私たちは同じ9つが、創業者のガレージでも資金潤沢なチームでも、何十ものプロダクトで繰り返されるのを見てきました。良い知らせは、それらが予測可能だということ——つまり回避できるということです。これは、最初の一行を書く前にすべての創業者がモニターに貼っておくべきだと私たちが願うリストです。

私たちは中小企業向けにソフトウェアを作っており、そのため2つのまったく異なる場面で呼ばれます。一つは初日、スケッチとアイデアしかない時。もう一つは、残念ながらより多いのですが、9か月目——創業者が貯金を使い果たし、プロダクトは技術的には動くのに、誰も対価を払っていない時です。この2つ目の電話が、私たちにこのリストを教えてくれました。検死をするたびに、早期に負わされ、放置されて化膿した、同じわずかな傷が現れるのです。

これらの失敗はどれも才能の問題ではありません。犯す人々はたいてい有能で勤勉です。問題は、SaaS の構築が、自分のアイデアに胸を躍らせている時には自然には湧いてこない、非常に特殊な「自制」を報いる点にあります。では、おおむね効いてくる順に9つを見ていき、なぜそれぞれがこれほど誘惑的なのかを正直に語りましょう。

1. 一人の顧客とも話す前に半年間作り続ける

これは原罪であり、最も高くつきます。創業者はアイデアが良いと確信し——実際そうかもしれません——黙り込んで半年間ひたすら作り、誰も頼んでいない洗練されたプロダクトを携えて現れます。市場は努力に報いません。誰かが対価を払ってでも消したいと思う問題を解決することに報いるのです。

解決策は複雑ではなく、ただ気まずいだけです。完成する前に、粗いものを本物の見込み顧客に見せること。クリックできるモックアップ、ランディングページ、あるいはメールで手作業で行うサービスの手動版でも構いません。人々が欲しがると確認する前に作る一週間ごとが、間違った通りに建つ家を飾る一週間になりかねません。

2. いもしない100万人のユーザーのために作る

2つ目の失敗はプロフェッショナリズムの衣装をまとっています。創業者、あるいは野心的な初期エンジニアが、初日から膨大なスケールに耐えられるようシステムを設計します——マイクロサービス、Kubernetes、マルチリージョンのデータベース、手の込んだキャッシュ層。責任感があるように感じられます。しかし実際には罠です。最も希少な資源である「時間」を、手に入れば幸運といえる問題への防衛に費やしているのです。

退屈な単一データベースのモノリスは、最初の数千ユーザーまで、そして最初の売上をはるかに超えて、楽々と運んでくれます。スケール時に重要になるアーキテクチャ上の判断は、出発点で予見できるものではほぼ決してなく、早すぎる複雑さはプロダクトの変更を遅くします——初期において、それこそが唯一あなたを本当に殺すものです。想像上の100万人目ではなく、次の10人の顧客のために作りましょう。

3. 最小でも、実用でも、プロダクトでもない MVP

誰もが MVP を作ることには同意します。実際にやる人はほとんどいません。代わりに出荷されるのは、創業者が想像できたあらゆる機能を詰め込んだ肥大した「バージョン1」です。機能を削ることが野心を削るように感じられるからです。その結果は3倍の時間がかかり、3倍のコストがかかり、学びにくくなります——肥大したプロダクトが失敗しても、どの部分が間違っていたのか分からないからです。

本物の MVP は、誰かが対価を払うほど十分にうまく一つのことを行います。それだけです。規律とは、何を含めるかを決めることではなく、何を省くかを決めることです。先送りする「当たり前」の機能一つひとつが、取り戻せる一週間であり、推測ではなく本物のユーザーで答えられる問いになると知ったうえで。

スコープの手早い正気チェック

どの機能も最初のビルドに入れる前に、私たちは創業者に一つの問いを声に出して答えさせます。「これなしで出荷したら、有料顧客が一人でもプロダクトの利用を拒むだろうか?」 正直な答えが「いいえ」なら、その機能は待機です。「必須」機能リストのどれほど多くが、この一文の前で蒸発するか、驚くはずです。

• 機能がユーザーに尽くすためではなく投資家を感心させるために存在するなら、待機。
• 機能が20人に1人未満しか遭遇しないエッジケースを扱うものなら、待機。
• まだ誰も変えてほしいと頼んでいない挙動を設定する設定画面を作っているなら、待機。
• 「競合が持っているから」がリストにある唯一の理由なら、待機。
• それを取り除いても1件の販売も止まらないなら、待機。

4. 課金とオンボーディングを後回しに扱う

創業者は中核機能に愛を注ぎ、それからローンチの2週間前になって、顧客には登録し、支払い、実際に使い始める手段が必要だと思い出します。課金はパニックの中で後付けされます。オンボーディングはログイン画面と肩をすくめるだけ。しかし「興味を持った訪問者」から「支払う、有効化されたユーザー」への道のりこそがあなたのビジネスであり——そこで売上の大半が静かに漏れていくのです。

本当に優れた中核機能を持ちながら、登録後に何をすべきか誰も分からず、最初の5分でサインアップの大半を失うプロダクトを私たちは見てきました。サブスクリプション、トライアル、日割り計算、決済失敗、解約、新規アカウントの空状態の体験——これらは事務作業ではありません。顧客がとどまるかどうかを決める瞬間における、まさに本物のプロダクトなのです。

5. マルチテナンシーを間違える(あるいは飛ばす)

これは、惨事になるまではまったく問題なく見える失敗です。SaaS とは多くの顧客が一つのシステムを共有することであり、彼らのデータをどう分離するか——マルチテナンシー——は土台となる判断です。間違えれば、顧客を適切に隔離できないものを作るか、もっと悪ければ、ある会社が別の会社のデータを見られるバグを出荷します。テナント間のデータ漏洩ほど、すべての顧客を一度に失う速い方法はありません。

風変わりな構成は不要です。たいていの初期プロダクトでは、すべてのテーブルとすべてのクエリで厳格に強制されるテナント ID を備えた単一の共有データベースで十分です——ただし、その隔離が土台に組み込まれてテストされていて、後から振りかけたものでないことが条件です。失敗はシンプルな手法を選ぶことではありません。失敗は意識的に決めず、本番に出てから穴に気づくことです。

6. ユーザーの動きを見る術なく闇雲に出荷する

ローンチします。人々が登録します。そして……沈黙。どの機能に触れ、どこで詰まり、なぜ去るのか、まるで分かりません。だから推測します。勘や、最も声の大きい顧客メール、あるいは自分の直感に基づいて次の機能を作ります——自分のプロダクトに何か月もいた後では、それはあなたが持つ最も当てにならない計器です。

基本的なプロダクト分析と、フィードバックを集める簡単な仕組みは、成長期の贅沢品ではありません。それは舵取りの手段です。それらなしでは、あなたはビジネスではなく、高価な意見を運営しています。「私が2か月かけて作った機能を、ユーザーの80%が一度も開かない」というほど単純なことを知るだけでも、闇雲に作るさらなる2か月より価値があります。

7. セキュリティとバックアップを「後で」に残す

スピードは初期の宗教であり、たいていそれは正しい。しかし、後付けすると壊滅的に高くつくものがわずかにあり、セキュリティはその筆頭です。パスワードを適切に保存すること、誰が何にアクセスできるかを締めること、そして——どうか——動作するテスト済みのバックアップを持つことは、時間がある時に足す任意の機能ではありません。それは、その上に建てる「床」です。

このカテゴリーの残酷なところは、うまくいかなくなるその瞬間まで、ずっと逃げ切れてしまう点です。1年間すべて順調で、それから一度の侵害、一度の誤った一括削除、一度のランサムウェアの朝が、その1年で築いた信頼とデータを消し去ります。セキュリティ部門を求めているのではありません。最初から基本がそこにあることを求めているのです。インシデント後に足すコストは、潰れた会社の数で測られるからです。

8. 間違ったステージに間違った作り手を雇う

非エンジニアの創業者は残酷な選択に直面します。これを実際に誰が作るのか? 2つの典型的な失敗は互いに鏡映しです。一つは、見た目は正しいがテープでつなぎ合わされたものを納品し、何かを変える必要が生じた瞬間に崩れ落ちる、できるだけ安いフリーランサーを雇うこと。もう一つは雇いすぎ——まだ顧客を一人も獲得していないプロダクトを作るために、フルの給与を払うシニアの完全なチームを構えることです。

正直な答えは、あなたが今どこにいるかに完全に依存します。アイデアを検証するには、初期プロダクトを以前に作ったことがあり、何を省くべきか正確に知っている、小さく経験豊富で実利的なチームが欲しい。実証済みのプロダクトをスケールさせるには、別の本能を持つ別の人々が欲しい。作り手をステージに合わせること自体が一つのスキルであり——ここを間違えると、このリストのどの技術的判断よりも多くのお金を無駄にします。

9. ローンチをゴールラインとして扱う

最後の失敗は最も悲しいものです。あれほどの努力の後に来るからです。チームはローンチ日を目標として扱い、そこに到達するためにすべてを投じ、計画も予算も、その先へのエネルギーもないまま疲れ果てて到着します。しかしローンチはゴールラインではありません。それは唯一重要なフェーズの始まりです。本物のユーザーから学び、週ごとに改善していくフェーズです。

SaaS プロダクトは決して「完成」しません。最初のバージョンは仮説であり、ローンチ後の数か月は、それがどれほど間違っていたかを——良い意味で——知る時です。それを見越し、わずかな滑走路と多くの好奇心を蓄えておく創業者こそ、ぐらついたローンチを本物のビジネスに変える人々です。スタートラインに着くためにすべてを使い果たした人々は、たいていそこから先へはあまり進めません。

9つすべてを実際に避ける方法

失敗のリストを読むのは簡単です。締め切りのプレッシャーの下で、自分のお金を賭け、自分のアイデアを胸に抱いてそれらを避けるのは、本当に難しい。そこで、うまくやる創業者がたいていどう動くかの短縮版を紹介します——ルールとしてではなく、盗む価値のある習慣として。

1. 1
   作る前に検証する

   本格的なコードを書く前に、粗いものを本物の見込み顧客の前に置き、彼らが払うと確認する。やるのは安く、飛ばすのは残酷。
2. 2
   最小の本物のプロダクトを選ぶ

   プロダクトが必ずやるべき一つのことを定義し、それ以外をすべて容赦なく先送りする。「バージョン1」が意図的に含めないものを書き出す。
3. 3
   退屈に作り、テナントを隔離する

   機能する最もシンプルなアーキテクチャを使うが、顧客間のデータ分離は初日から土台となるテスト済みの判断とする。
4. 4
   お金の道を早く設計する

   登録、オンボーディング、課金を事務作業ではなく中核プロダクトとして扱う。最初の5分が、残りが見られるかどうかを決める。
5. 5
   計測を入れ、学ぶためにローンチする

   基本的な分析とフィードバックを整えて出荷し、ローンチ後のフェーズのために滑走路を残し、最初のバージョンを答えではなく問いとして扱う。

気づいてください。これらのほぼ何一つコーディングの腕についてではありません。何を作り、何を飛ばし、いつやるかを知る——判断についてなのです。だからこそ、技術的に有能な多くのチームが、それでも失敗するプロダクトを生み出します。SaaS の難しい部分は決してエンジニアリングではありませんでした。それは自制でした。

よくある質問