先日、ポール・グレアムのツイートを読んだ。失敗した創業者でも、良いものを作り、なぜ失敗したのかを理解していれば、たいていは称賛されるという内容だった。

私と二人の兄弟が2007年にクラウドファンディングのスタートアップ「microPledge」を立ち上げたとき、私たちも確かに良いものを作ろうとしていた。どんなプロジェクトでも利用できるクラウドファンディングプラットフォーム、なかでもソフトウェアプロジェクトに焦点を当てたものだ。

そして、なぜ失敗したのかはわかっているつもりだ。最初のバージョンはMVP（Minimum Viable Product）とは程遠い複雑なものだったし、潜在的なユーザーに試してもらい、売り込む前に作ってしまった。そして最後の一撃となったのが、PayPalをめぐる法的な問題だった。

この記事では、私たちのスタートアップの概要を振り返り、犯した失敗とそこから学んだことを掘り下げ、記録として出来事のタイムラインを残したい。また、なぜKickstarterは成功し、microPledgeはそうならなかったのかについても考える。とはいえ、microPledgeが一つ確実にkickstart（始動）させたものがある。それは私たち自身のキャリアだ。

microPledgeの概要と誕生の経緯

2006年1月のこと、兄のバーウィンが通勤途中にmicroPledgeのアイデアを思いついた。最初の着想はこんなものだった。「近所の人や友達、おばあちゃんまでみんなが20ドルずつ出し合って、地域の遊び場を作るところを想像してみて。必要なのは、そうした新しいものづくりを可能にするウェブツールだけだ！」

すぐに彼は兄弟であるブライアンと私に声をかけ、一緒に作らないかと誘ってきた。ブライアンはちょうどウェブデザイン会社を立ち上げたばかりで、すぐに参加した。私は大学を卒業して2年ほど経ったところで、ポール・グレアムのエッセイを読み漁っており、ぜひ参加したいと思った。ちょうどPythonというプログラミング言語にも注目していて、使ってみたいと思っていたところだった。

タイミングは絶妙だった。「crowdfunding（クラウドファンディング）」という言葉が初めて使われたのが2006年8月のことだ。私たちは2006年6月から2007年7月にかけて約12か月をかけてプラットフォームを構築し、クラウドファンディングという概念がまさに人気を集め始めていた2007年8月にローンチした。

こちらが当時のmicroPledgeのホームページのスクリーンショットだ（現在は閲覧専用のウェブサイトで保存されている）。

当初はソフトウェアプロジェクトの資金調達支援に焦点を当てていたが、どんな種類の物理的なプロジェクトでも使えるシステムにしたいと考えていた。

資金を集めたいクリエイターは簡単にプロジェクトを作成できた。私たちはプロジェクト作成フォームをあえて1画面のシンプルなものに抑えたのだ。

そこでプロジェクトの作成者は目標金額を設定し、あとは支援（プレッジ）が集まるのを待つだけだった。プレッジされたお金は、支払いの時まで信託口座に移される仕組みだった。

決済システムにはPayPalを使った。当時、他人へお金を支払う（出金する）ことを可能にしていた数少ないプロバイダーの一つだったからだ。ただ、始める際に私たちは利用規約の細則を十分に読み込んでいなかった。端的に言えば、PayPalは信託としてお金を保有されることを嫌うのだ。この件については後で詳しく触れる。

エンジェル投資家からは少額の資金を得た。家族から約NZ$10,000、友人からNZ$60,000だ。当時、その投資は会社の3分の1の価値に相当すると見積もっていたので、創業者である私たち3人で残りの3分の2を保有した。このお金で、フルタイムで開発に取り組む間の3人分の最低限の生活費をまかなうことができた。

今振り返ると、あの時期は本当に楽しかった。兄弟と一緒に自分たちだけのスタートアップで働き、PythonやSQL、ウェブ開発を学ぶ日々だった。

なぜ失敗したのか

microPledgeは完全な失敗だったわけではない。約1200人のユーザー、100件のプロジェクト、合計$25,000のプレッジを集めた。そのうちのごく少数が目標を達成した。つまり、少しは手応えを得たものの、その後伸び悩み、資金が尽き、最終的に失敗したのだ。

以下では、私たちが失敗したと思う様々な理由を説明する。後から振り返れば簡単に見えることだが、2006年当時の若いソフトウェアオタク3人には明らかではなかった。

こうしたことのほとんどは、どんな「スタートアップ入門」記事にも「やってはいけないこと」リストとして書かれているだろう。後知恵とは実に素晴らしいものだ。

複雑すぎた進捗・支払いシステム

microPledgeが軌道に乗らなかった理由の一つは、システムが単純に複雑すぎたことだ。私たちはマーケティングの知識がほとんどないエンジニア3人だったことを思い出してほしい。死ぬほどシンプルな「バージョン1」を作る代わりに、私たちはルーブ・ゴールドバーグ・マシンを作ってしまったのだ。技術的には素晴らしいが、理解するのが難しい。

私たちは段階的な支払いシステムを設計した。プロジェクト作成者がスライダーをドラッグして（例えば）「30%完了した」と宣言し、その進捗を示す証拠として写真やソースコードをアップロードする。すると支援者に通知が届き、支援者もスライダーをドラッグして投票する。投票期間の後、作成者は30% × 総プレッジ額 × 平均投票率に相当する金額を受け取るという仕組みだった。

こちらがプロジェクトページのスクリーンショットの1つだ（このプロジェクトは目標を達成したが、結局開発されることはなかった）。

何ページにもわたるプロジェクト作成者向けFAQの長さが示す通り、詳細は膨大だった。さらに、本格的なプロジェクト見積もりシステムも用意していた。誰でもプロジェクトのアイデアを提案でき、開発者がそれに対して見積もりを出し、最も良い見積もりが採用されるというものだった。

誤解しないでほしいのだが、複雑なシステムのわりにはmicroPledgeのUIは適切なものだった。私たちは詳細を詰めるのに多くの時間を費やしたのだ。「資金調達の温度計」や進捗スライダーは明確で視覚的にわかりやすく、詳細はツールチップの裏に段階的に表示され、作成者も支援者も投票プロセスをガイドされるようになっていた。

私たちの間違いはもっと早い段階にあった。誰も必要としない精巧なシステムを設計してしまったのだ。microPledgeの2年後にローンチしたKickstarterは、シンプルな「Back this project」ボタンで成功した。プロジェクト作成者は、目標を達成すれば全額を得られ、達成しなければ何も得られない。進捗段階も、投票も、支払い計算もない。

私たちが複雑さのために複雑なシステムを作ったわけではない。支援者がクリエイターを信頼し、実際に製品を作り上げてくれるかという問題を解決したかったのだ。しかし実際には、人々はかなり信頼深く、ほとんどの場合それでうまくいくことがわかった。製品を届けないKickstarterのクリエイターのケースは比較的まれで、そのとき支援者は不機嫌になる。だが彼らはリスクを承知で支援しているのだし、たった$20をプレッジしたくらいで、どれほど腹を立てるというのだろうか。

要するに、microPledgeはMVPとしては複雑すぎ、ユーザーが本当に求めていたものと比べても複雑すぎたのだ。支援者が求めているのはシンプルな支援ボタンだけで、クリエイターが求めているのは支払いだけなのだから。

過剰に作り込んだソフトウェア

完璧主義の傾向があるソフトウェアエンジニア3人を一つの部屋に集めれば、物事を作り込みすぎるのは必然だ。

例えば、既製品（あるいは単なるSQL）を使う代わりに、自作のミニORMを開発した。スタートアップとしては、フレームワークレベルのコードを書くことではなく、仕事をやり遂げることに集中すべきだった。

PostgreSQLの設定をいじってWALログを使うようにするのにも多くの時間を費やした（当時は設定が難しかった）。そうすれば「最新のバックアップがあります」と胸を張ってユーザーに言えるからだ。1日1回バックアップを保存する、pg_dumpを使った5行のスクリプトを書けば済んだのに。

私自身、ランダムなSHA-1ハッシュの衝突を検出して処理するコードの実装に何時間も費やしたことを覚えている。これは基本的に数十億年かけても起こり得ないことなので、暗号学的ハッシュに関する記事をもっと読んでおくべきだったのだろう。

しかも私たちは、課金してくれるユーザーも、まともな収益戦略もないまま、こうしたことをすべてやっていたのだ。スタートアップの生死はコードの技術的な巧みさではなく、収益を生み出せるかどうかにかかっているということが、まだ身に染みていなかったのだ。

この2つの「複雑にしすぎ」問題の両方に役立ったであろうことは、もう一人のエンジニア気質の兄弟ではなく、アートやビジネス寄りの人材をチームに加えることだった。

仕組みを強調し、完成品を見せなかった

上に示した私たちのプロジェクトページを見れば、最も目立つのは支援者が手にする製品ではなく、プレッジや進捗の部分であることがわかる。プロジェクト自体を売り込むのは、小さな段落だけだった。

それをKickstarterのプロジェクトページと比べてみてほしい。Kickstarterでは、作ろうとしている製品を売り込む大きな動画が冒頭にあり、通常はその製品についての長文の説明が高品質な写真とともに続く。こちらがKickstarterのプロジェクトページの上部だ。

Kickstarterは、クリエイターが（潜在的な）製品を本当に輝かせられるよう手助けしている。私たちのプロジェクトページはそうではなかった。しかも彼らは素晴らしいプロジェクトページの作り方をガイドしてくれる。実質的に、彼らはこれらのミニ・スタートアップの創業者たちに、自分自身のオーディエンスへの売り方を教えているのだ。

私たちがこの間違いを犯したのは、金を払う顧客、つまり支援者（セールスの言葉で言えばバイヤー）ではなく、クリエイターの視点で物事を考えていたからだと思う。同じように、「Kickstarter」という名前は「microPledge」よりもやや優れている。プレッジという入力ではなく、製品という出力を強調しているからだ。

焦点の選び方の誤り

microPledgeは物理的なプロジェクトもサポートしていたが、プロモーションの労力のほとんどはソフトウェアプロジェクト、特にオープンソースソフトウェアの資金調達手段として注がれていた。

そこから始めたのは、それが私たちの知っている分野で、ソフトウェアの配布が簡単だったからだ。しかし振り返ってみると、それはほぼ確実に間違いだった。オープンソースにもお金はあるが、それは一般的にクラウドファンディングからではなく、企業向けサポートや拡張機能からもたらされるものだ。

Kickstarterや他のプレッジサイトは、現実の物理的なプロジェクトに焦点を当てる傾向がある。一般の人々に、ソフトウェアよりもハードウェアのガジェットや新しいタイプの靴にお金を出してもらう方が、はるかに簡単なのだ。

ユーザーが本当に必要としているものを掴めなかった

失敗のもう一つの大きな理由は、市場の声を聞くことも、実際のユーザーが本当に何を求めているのかをテストすることもなく、システムを作ってしまったことだ。

もちろん、多少のプロモーションは行った。主に、私たちが役に立つだろうと考えたソフトウェアプロジェクトの作成者に向けてだ。例えば、microPledgeの配信に使っていたApache用のmod_wsgi拡張のメンテナーであるGraham Dumpletonとは何度もやり取りした。彼を説得して寄付のみのプロジェクトでmicroPledgeを使ってもらい、その過程で貴重なフィードバックをもらった。

そして2007年9月には、ニュージーランドの新聞であるDominion Postで少し取り上げられた（記事は姉妹ニュースサイトのStuff.co.nzにも掲載された）。

とはいえ、私たちはもっと早い段階から――12か月も開発に費やす前に――潜在的なプロジェクト作成者や実際の支援者に売り込むべきだった。このフィードバックに基づいて製品を頻繁に改善すべきだった。おそらくそうしなかった最大の理由は、私たちにとってコードを書くことは楽しく、電話を取ることは楽しくなかったからだ。

PayPalをめぐる法的な問題

ローンチから数か月以内に、すでにうまくいっていないことは見えていた。しかし、とどめを刺したのは、ローンチから1年後に起きたPayPalとの法的なごたごただった。

microPledgeのお金の扱い方はこうだった。PayPal経由でプレッジを受け付け、そのお金を信託口座に移し、最後にプロジェクトが進捗するにつれてプロジェクト作成者に支払うという流れだ。

破滅の原因となったのは、この「信託としてお金を保有する」という部分だった。これは本当に私たち自身の落ち度だった。PayPalの利用規約を十分に注意深く読んでおらず、信託としてお金を保有することは彼らが禁止していることの一つだったのだ。

PayPalが気づいたきっかけは、クレジットカード詐欺師が私たちのサイトを通じてマネーロンダリングを試みたことだった。これがPayPalに発見され、彼らが監査を行った結果、私たちが信託としてお金を保有していることに気づかれたのだ。

私たちは善意でやっており、もちろん約束通りに支払いも行っていたが、PayPalには「仲間（pal）」の要素がほとんどないことを思い知らされた。信託としてお金を保有していることが発覚すると、彼らは即座に私たちのアカウントを凍結し、サポート窓口に何度も電話をかけて弁明したにもかかわらず、6か月間にわたって資金を凍結したままにした。

私たちはやきもきし、ユーザーも当然ながら動揺した。様々な選択肢や他の決済プロバイダーを検討したが、いずれにせよmicroPledgeは期待したほどの手応えを得られていなかったので、この6か月間の凍結は事実上の死刑宣告となった。

会社・知的財産の売却の試み

お手上げとなった後、私たちは方針を変え、microPledgeのプレッジシステムを興味を持つ相手に売却しようと試みた。しかし、知的財産には大した価値がないことがわかった。何件か問い合わせはあったが、買い手は現れなかった。

しかも、その価格はほぼ投げ売り同然だった。私たちはただコストの一部でも回収しようとしていたのだ。私たちの「目論見書」から引用すると、潜在的な買い手は次のいずれかを購入できた。

1. 完全なウェブソフトウェアのライセンス、価格はUS$7,500。ソースコードの完全な権利と改変権を含む。
2. 上記すべてに加え、独占権や再販権などを含むプラットフォームの完全な所有権。価格は要交渉――US$35,000以上のオファー。

私たちはFlippa.comで会社自体を売却しようとも試みた。ここでもまた、ほとんど何の進展もなかった。結局、すべての売却の試みは立ち消えとなり、数年後にmicropledge.comドメインを失効させることになった。

学んだこと

失敗は良い教師であり、私たちはこの2年間で多くのことを学んだ。

ビジネス

スタートアップの面で学んだことは、基本的に上記の「なぜ失敗したのか」リストの逆だ。

• 死ぬほどシンプルなバージョン1から始める（KISSの原則）。
• （金を払う）顧客が求めるアウトプットを強調する。
• 金を払ってくれる市場に焦点を当てる。おそらくオープンソースではない。
• まず売る――コードを書く前に。
• 決済システムの細則を読む。:-)

とはいえ、この経験から貴重なビジネス経験は得られた。兄のブライアンがmicroPledgeの親会社であるBrush Technologyを設立し、microPledgeの失敗後、バーウィンと私は数年間その運営を手伝った。同社は今でもソフトウェア・電子機器のコンサルティング会社として存続している。

microPledgeの数年後、私たちはHivemindという別のスタートアップを立ち上げた。そこで作ったのは具体的な製品、養蜂箱用の電子モニタリング・報告システムだった。養蜂家に売るのは難しいが、このスタートアップはかなりうまくいき、以前学んだ教訓のいくつかを実践に活かすことができた。

技術

ソフトウェアエンジニアリングの正式な訓練を受けていないプログラマーとして、スタートアップでの経験からどれだけ多くのことを学んだかを実感したのは、何年も経ってからだったと思う。

技術的な面では、ウェブ開発（HTTP、HTMLフォーム、そして危険と言える程度のCSSとJavaScript）を学んだ。Python開発や、リレーショナルデータベースとSQL（特にPostgreSQL）も学んだ。始めた当時はブライアンがおそらく最も詳しかったが、私たち全員が多くのことを学んだと思う。

ウェブフレームワークについても学んだ。Djangoも評価したが、最終的に選んだのはweb.py、Aaron Swartzが作ったマイクロフレームワークだった。今でも活発にメンテナンスされているのには驚いている。私は今でもウェブツールは小さく軽いものが好きだ。フレームワークよりライブラリ寄りのものが。

もう一つ学んだのは、私が「diffテスト」と呼んでいるものだ。これはバーウィンのアイデアだったが、彼が最初に考えたものではないだろう――「スナップショットテスト」や「ゴールデンファイルを使ったテスト」と呼ばれているのを聞いたことがある。基本的な考え方は、テストの期待される出力をファイルに保存し、そのスナップショットをソース管理にコミットしておくというものだ。そしてテスト対象のコードを実行した際に、出力を新しいファイルに書き出し、テストはそれをスナップショットとdiffするだけで済む。それ以来、この手法を多くのプロジェクトで使ってきた。特にデータ変換のタスクに非常に有効だ。

しかし、おそらく最も重要だった学びはチームワークだ。チームでソフトウェアを作る方法、仕事を分割して整理する方法、良いツールを使うことの重要性などだ。microPledgeは、私にとってチームで開発し、バージョン管理を使った初めての仕事だった。この指導のほとんどは、中規模のソフトウェア会社で数年間働いていた年長の兄バーウィンから得たものだ。

結論

私の最大の収穫は、そうした失敗からの学びのすべてが、その後のキャリアにとって非常に価値があったということだ。特に私自身のキャリアにとって価値があったのは、Pythonでウェブアプリを開発した技術的な経験と、（小さな）チームでソフトウェアを構築する方法を学んだことだった。

今知っていることを知った上でmicroPledgeを作っていたら、成功していただろうか。十分に可能性はあったと思う。もっとシンプルなシステムを作り、正しい人々にプロモーションしていただろうからだ。

ただ、一つ今でも持てなかっただろうものがある。シリコンバレーでの存在感だ。ポール・グレアムたちがY Combinatorをボストンからシリコンバレーに移したのには理由がある。小さなニュージーランドでこのようなスタートアップの資金を調達するのは、はるかに難しいのだ。とはいえ、地元での小規模な成功は収められたのではないかと思う。

Kickstarterが成功したのは――彼らには称賛を送りたい――シンプルで明確であり、システムをお金の仕組みではなく、クリエイターが売ろうとしている製品に焦点を当てたからだ。

またスタートアップをやるだろうか。今までは「いや、しばらくはもっと安定した会社で働きたい」と思っていた。だが、この記事を書いてみて驚いたことに、また気持ちが奮い立った。そろそろまたその時なのかもしれない！

タイムライン

以下はmicroPledgeのタイムラインだ（主に自分用の記録として！）。

• 2006年1月：バーウィンが通勤中に最初のアイデアを思いつく
• 2006年1月：最初のSubversionコミット
• 2006年2月：3兄弟によるμPledge（当初の名前）についての初会合。議事録からの引用：「（むなしくも？）6か月で何かリリースできるものを用意できると想像している。」
• 2006年3月：ウェブフレームワークを決定。Djangoではなくweb.pyを選択したのは、「学習コストが6分の1」ではるかに軽量に感じられたため
• 2006年6月：最初のコードコミット。コード構造とミニORMの着手
• 2006年7～12月：初期コード。データモデル、HTML生成、サーバー構築
• 2007年1月：PayPal処理のコード
• 2007年2～3月：ページテンプレート、プロジェクトページ、進捗スライダーなど
• 2007年3月：microPledgeの特許出願書を作成
• 2007年4～5月：プレッジと投票、資金引き出し機能、サインイン、開発者が10%のペナルティで撤退できる機能
• 2007年5月：Amazon S3を使ったファイルアップロードとプロジェクトのサムネイル
• 2007年6～7月：テストとバグ修正の追い込み、PostgreSQLのWALバックアップ、サーバー構築の完了
• 2007年8月：ローンチ！　プレスリリース、Slashdot.orgへの投稿、複数のオープンソースプロジェクトへの働きかけ
• 2007年9月：Dominion Postに記事が掲載
• 2008年9月：信託口座で資金を保有していたためPayPalにアカウントを停止される
• 2008年10月：1200人のユーザーに1人$10のプレッジを呼びかけ、「microPledgeを継続するため」（別の決済プロバイダーへの切り替え）
• 2009年12月：microPledgeのソフトウェアまたは知的財産の売却を試みる
• 2010年2月：Flippa.comで会社の売却を試みる
• 2013年2月：micropledge.comドメインを失効させる。ある時代の終わり。