多くのソフトウェア系の創業者が、シンプルな理由で失敗する。リリースが遅すぎるのだ。彼らは何年も誰にも見せずにプロダクトを開発し、初めて実際の顧客が触れた途端にそれが崩れ去るのを目の当たりにする。

Indie Hackersポッドキャストでは、そうした物語が数多く紹介されている。番組の掲げるミッションは、起業家たちの失敗から学ぶ手助けをすることだが、ホストのCourtland Allenは、それが本当に可能なのかについてしばしば実存的な悩みを口にする。

…何度も何度も、顔が真っ青になるまで人に言い聞かせても、結局は本人が外に出て自分の失敗を通して手痛い形で気づくまで、耳を貸さなかったり、本当の意味を理解しなかったりするようなことがあるんです。

-Courtland Allen, Indie Hackers Podcast

私はいつもこう思っていた。「いや、Courtland、それは非効率だよ。僕はタダでもらえる教訓はありがたくいただいて、高くつく失敗はやらずに済ませよう」と。

この記事のタイトルから察しがついたと思うが、その目論見はうまくいかなかった。

プロダクトのアイデア

アイデアが浮かんだのは、これまで書いた中で最も醜いコードを眺めていたときだった。それは昨年作ったレシピ検索ツールの中にあった。そのアプリは結局ヒットしなかったが、たまにいじるのは楽しかった。コードベースの中で、常に私を悩ませていた部分が一つあった。材料のパース処理だ。

たとえば "2 cups finely chopped red onions" のような文字列が与えられたとき、アプリは 2 が数量で、cups が単位であるといったことを判別しなければならなかった。

当初、パース処理はシンプルだったが、エッジケースが増えるにつれてどんどん脆く複雑になっていった。やがてロジックは、正規表現という苛立たしい迷宮へと堕ちていった。正規表現はテキスト処理のための強力な命令だが、悪名高いほど読みにくい。

すべてを捨てて機械学習のソリューションに置き換えたい誘惑に駆られたが、それはあまりにも大きな取り組みになる。収益ゼロのウェブサイトの小さな機能のために、何ヶ月もの開発期間を投資するわけにはいかなかった。

そして、ひらめいた。もし材料のパース自体がビジネスになるとしたらどうだろう？ 自分にとって問題なのだから、他の開発者も同じように苦労しているはずだ。うまくいけば、その中には収益を上げている人もいて、問題を解決してあげれば、そのお金をいくらか私に払ってくれるかもしれない。こうして、私の材料パースサービスであるZestfulのアイデアが生まれた。

幻のMVP

リーン・スタートアップの世界では、「MVP」、すなわちミニマム・バイアブル・プロダクト（実用最小限の製品）がよく話題になる。MVPとは、アイデアの最もシンプルな形だ。できるだけ早く作り、見込み顧客の手に渡し、その反応から本当に問題を解決できているかを判断するのがセオリーだ。

よくある失敗談の一つが、自分のアイデアに自信を持ちすぎるあまりMVPを作ることを怠った創業者の話だ。その代わりに、誰も欲しがらない本格的なプロダクトに何ヶ月も何年も投資してしまう。

Zestfulでは、私はちゃんとMVPを作った。際限のない微調整や改善というウサギの穴にハマらないよう、事前に受け入れ条件まで定義したのだ。

約120時間の開発作業の後、動くプロトタイプは受け入れ条件を満たした。

しかし、正式なローンチはさらに2ヶ月後になった。その間、私はひたすらコードを書き続けていた。

これはセールスのためのコーディングだから大丈夫

MVPが「完成」した後に、なぜあれほど長い間空回りすることになったのか不思議に思うかもしれない。そこで、この2ヶ月間の私の思考プロセスをまとめてみた。

1日目：受け入れ条件を達成

サービスは動く！ でも顧客が使うには、コマンドラインで複雑な式を書かなければならない。

Web 3.1の時代に、顧客に curl コマンドを書かせるなんて失礼じゃないか？ シンプルなHTMLフロントエンドを追加すれば、顧客はブラウザから直接サービスを試せるようになる。

5日後

基本的なフロントエンドは動く。でも、説明もなく孤立したHTMLフォームがぽつんと置かれているのは変だ。

フォームの周りにウェブサイトを作る必要がある。でも、超シンプルなサイトだから1日でできるはずだ。

4日後

よし、サービスにウェブサイトができた。

…でも、各フィールドを説明するドキュメントページがない。これは今日の午後に片付けてしまおう。

2日後

ページが増えすぎて、モバイルではナビゲーションバーがはみ出してしまう。

ナビゲーションバーをレスポンシブ対応させよう。使っているWebフレームワークのAngularなら、1時間もあればできるはずだ。

8日後…

それはヒドラだった。「あと一つ簡単なものを追加する」のを終えるたびに、その結果として必要になるものが二つも現れるのだ。コード完成を宣言してから2ヶ月が経ち、何もリリースできていないことに私は愕然とした。

これは重要だが、後回しにできる

私はなんとしてもローンチする必要があった。しかし、クリティカルなタスクのリストはまだ完了していなかった。完了まであと5日はかかると見積もっていた。

すると、奇妙なことが起きた。できるだけ早くリリースすると心に決めた途端、「あれば重要なもの」と「ローンチに必要なもの」は違うのだと気づいたのだ。

一例が利用規約だった。これなしでローンチして、数日後に書いたらどうなるだろう？ 最悪の場合、法的な争いが起きたときに立場が弱くなるが、ローンチから数日のうちに誰かが訴えてくる可能性はどれほどあるだろうか？

とにかくローンチしろ

タスクリストの各項目について、「これなしでローンチしたらどうなる？」と自問した。利用規約と同じように、すべてのタスクを容赦なく疑ってかかった結果、本当にローンチに必要なチェックリストが浮かび上がった。24時間も経たないうちに、私はAPIマーケットプレイスであるRapidAPIにZestfulを公開した。サービスがついに稼働したのだ！

いよいよ真実の時だった。サービスは実際のお客様からの支払いを受け付ける準備が整った。あとは買ってもらえるよう説得するだけだ。

拒絶を避けるためにローンチを遅らせたのか？

「完成」から「ローンチ」までの2ヶ月間の宙ぶらりんな期間に、友人から「プロダクトを顧客に見せるのが怖いのでは？」と聞かれた。ローンチを遅らせていたこれらのタスクは、単に拒絶を避けるための口実だったのではないか、と。

その考えが頭をよぎったことはあったが、すぐに打ち消した。私は以前セールスの仕事で、飛び込み営業の電話をかけ、1日に40回も「ノー」と言われてきた。拒絶なんて怖くなかった。

ローンチ当日、私は初めてのコールドピッチを書くために腰を据えた。面識のないレシピアプリの開発者に宛てたメールだ。なぜ私の材料パースサービスを彼らのアプリに組み込むべきなのかを説明しなければならなかった。

30分間、白紙の画面を見つめたまま、何も書き出せずに苦しんだ。友人には何十回もサービスについて説明してきたが、今回は違った。セールスポイントを思いつくたびに、顧客からの厳しい反論が頭に浮かんだ。

それがなぜあなたの請求する価格に見合うのですか？

それでどうやって私の利益が増えるのですか？

なぜあなたが必要なのですか？

まずい。私は拒絶を恐れていたのだ。

これまでとは違う種類の拒絶

これはセールスの仕事とはまったく違った。あの仕事は企業に光ファイバー回線を売ることだったが、私自身が光ファイバーを敷設したりネットワークを設計したりしたわけではない。だから拒絶されても平然と受け流せたのだ。

今回は、自分で作ったものを売っていた。しかも、それは自分で作ったソフトウェアだった。ソフトウェアを書くことは、私のアイデンティティの核だ。これ以上得意なことも、これ以上誇りに思っていることもない。もし顧客にプロダクトを見せたら、こう思われるかもしれない。「これはあまり良くない。あなたはこれを売ろうとしているのだから、良いと思っているはずだ。ならば、あなた自身があまり優秀ではないということだ」と。

厳しい現実

何十件ものピッチと数回の会話を経ても購入はゼロで、やっと気づいた。私は、顧客が欲しがらないプロダクトに何ヶ月も投資してしまった典型的な開発者になっていたのだ。

私のようなサービスを活用できる企業もあったが、最も必要としている企業はすでに自前で作ってしまっていた。残りの企業は「面白いサービスだね」とは言ってくれたものの、月額わずか20ドルでも費用に見合わないと判断した。

そしてそこで、戦略の致命的な欠陥に気づいた。顧客にとって最も大きなコストは私の月額料金ではなく、サービスを統合するためにアプリを改修するコストだったのだ。

さらに、彼らは外部依存が一つ増えることのコストも天秤にかけなければならなかった。もし私のサービスが障害を起こしたらどうなるのか？ 彼らのアプリは止まってしまうのか？ それとも、サービスが停止したときのために、まったく別の代替動作モードを構築する必要があるのか？

私は順序を間違えていた

振り返ってみると、私のプロセスは逆だった。顧客へのコールドピッチは最後のステップだったが、本当は一行のコードを書く前にやるべきだったのだ。

初期の段階で、私は「先にプロダクトを作る」という決断を正当化していた。顧客はアイデアには「イエス」と言っても、結局はプロダクトを買わないかもしれない。私は「イエス」を、顧客がサービスを購入することで合意する、本物のセールスにしたかったのだ。

その論理自体は今でも正しいように思えるが、私は「ノー」の価値を見落としていた。顧客がコンセプト段階でプロダクトを拒否するなら、作り上げた後で気が変わることはない。もし全員がノーと言うなら、それはおそらく行き止まりなのだ。

Samantha Masonによる編集。イラスト：Loraine Yow。