目次
「自分たちが欲しいツール」を作っただけだった
ソフトウェア開発の世界でGitHubを使ったことがない開発者を見つけるのは困難である。2024年時点で1億人以上の開発者が利用し、2018年にMicrosoftが75億ドルで買収したこのプラットフォームは、ソフトウェア開発のインフラそのものと化している。
しかし、GitHubの始まりは3人のプログラマーが週末に「自分たちが欲しいツール」を作ったに過ぎない。外部資金はゼロ。ビジネスプランもゼロ。あったのは、Gitというバージョン管理システムに対する不満と、それを解決するプログラミングスキルだけであった。この事例は、エフェクチュエーションの「許容可能な損失の原則」が技術者主導のスタートアップにおいて自然に発現するケースを示している。
Tom Preston-Wernerと共同創業者たちの背景
GitHubの共同創業者はTom Preston-Werner、Chris Wanstrath、PJ Hyettの3人である。2007年当時、Preston-WernerはGravatar（アバター画像サービス）を運営するフリーランスの開発者、WanstrathはCNET Networksでプログラマーとして勤務、Hyettはウェブ開発者として活動していた。**全員が本業の収入を持つ、いわゆる「週末起業家」**であった。
3人に共通していたのは、Linus Torvaldsが開発した分散型バージョン管理システムGitに対する強い関心と、それを使いやすくするホスティングサービスの不在に対する不満であった。Gitは強力なツールであったが、コマンドラインベースで使いにくく、共同作業のためのウェブインターフェースが存在しなかった。
この時点で3人が持っていた手段は以下の通りである。「自分は誰か」としてはRuby on Railsに精通したウェブ開発者、「何を知っているか」としてはGitの仕組みとオープンソース開発の文化、「誰を知っているか」としてはサンフランシスコの開発者コミュニティであった。資金も、マーケティングの知見も、企業経営の経験もなかった。
週末プロジェクトからユニコーン企業への進化
スポーツバーでの最初の会話
2007年10月、Preston-WernerとWanstrathはサンフランシスコのスポーツバーで偶然出会い、Gitホスティングサービスのアイデアについて意気投合した。その夜のうちに、二人は週末を使って開発を始めることを決めた。
ビジネスプランは存在しなかった。市場調査も行われなかった。あったのは「自分たちが使いたいサービスがないから、自分たちで作ろう」という動機だけであった。この意思決定プロセスは、Sarasvathy（2001）が示す手段ドリブンのアプローチそのものであった。
夜と週末だけの開発
2007年10月から2008年2月まで、Preston-WernerとWanstrathは平日の夜と週末のみを開発に充てた。PJ Hyettも途中から加わった。全員が本業を持ちながらの開発であり、GitHubのために費やしたのは余暇の時間のみであった。
開発コストは事実上ゼロであった。サーバーにはSlicehostの安価なVPSを使い、月額数十ドル程度。開発ツールはすべてオープンソース。失敗した場合に失うのは、週末の自由時間と月額数十ドルのサーバー代だけであった。
プライベートベータからの段階的公開
2008年1月、GitHubはプライベートベータとして限定公開された。まず身近な開発者コミュニティに無料で使ってもらい、フィードバックを収集する戦略であった。
2008年4月に正式ローンチした時点で、すでに6,000のリポジトリが作成されていた。この段階でようやく有料プランが導入されたが、パブリックリポジトリは無料のままとするフリーミアムモデルが採用された。
外部資金なしでの黒字化
GitHubは最初の4年間を外部資金なしで運営した。2012年にAndreessen Horowitzから1億ドルの資金調達を行ったが、それはすでに黒字化を達成した後のことであった。資金調達は成長の加速のためであり、生存のためではなかった。
この点は、多くのスタートアップが赤字状態で資金調達に走るのとは対照的である。
エフェクチュエーション原則の分析——「許容可能な損失」としての開発者の余暇
「時間」を許容可能な損失として設定する合理性
Sarasvathy（2008）は、許容可能な損失が金銭だけでなく時間、機会費用、心理的コストなど多面的な概念であることを強調している（Sarasvathy, 2008, pp. 40-42）。GitHubの創業者たちが設定した許容可能な損失は、主に「週末と夜の時間」であった。
この設定の合理性は二重である。 第一に、余暇の時間は本業のパフォーマンスに影響しない（したがって収入が減るリスクがない）。第二に、プログラミングは3人にとって趣味でもあり、たとえGitHubが失敗しても、コードを書く時間そのものは無駄にはならない。
自分たちが最初のユーザーであることの意義
Dew et al.（2009）は、許容可能な損失の原則が市場の不確実性を低減する効果を持つと論じている（Dew et al., 2009, pp. 115-118）。GitHubの場合、創業者自身が最初のユーザーであったことで、この不確実性の低減が自然に実現された。
「自分が使いたいかどうか」という判断基準は、市場調査や顧客インタビューよりも迅速かつ低コストである。しかも、創業者たちはGitユーザーのコミュニティに深く関与しており、自分たちのニーズが他の開発者にも共通していることを経験的に知っていた。
フリーミアムモデルの損失構造
Sarasvathy（2001）は、エフェクチュエーションの論理が**「予測ではなくコントロール」を重視する**ことを示した（Sarasvathy, 2001, p. 252）。GitHubのフリーミアムモデルは、この原則を巧みに適用している。
無料ユーザーにかかるサーバーコストは、有料プランの収益で賄える範囲に設定された。無料ユーザーが増えることで有料転換の母数が拡大するが、そのコスト増は段階的であり、常にコントロール可能であった。
実務への示唆——技術者が始めるスタートアップの型
GitHubの事例は、技術者が自らのスキルを活かしてスタートアップを始める際の合理的なパターンを示している。
第一に、「自分が欲しいもの」を作ることで市場リスクを最小化する。 創業者自身がターゲットユーザーであれば、製品の価値検証に外部のリサーチは不要である。この戦略は、許容可能な損失を最小限に抑えながら、製品の方向性を正確に定める効果がある。
第二に、本業を維持しながら開発することで経済的リスクをゼロにする。 週末と夜の時間を開発に充てることで、失敗しても経済的な打撃はゼロである。この「失っても構わない時間」の投資が、GitHubの場合は75億ドルの企業価値を生み出した。
第三に、外部資金調達は黒字化の後で行う。 GitHubは利益が出る体制を確立した上で、成長加速のためにVCの資金を受け入れた。**「生存のための資金調達」ではなく「拡大のための資金調達」**という順序が、経営の自由度を保持することを可能にした。
「許容可能な損失の原則」での原則解説と「エフェクチュエーション事例集」も参照されたい。
引用・参考文献
- Sarasvathy, S. D. (2001). Causation and effectuation: Toward a theoretical shift from economic inevitability to entrepreneurial contingency. Academy of Management Review, 26(2), 243–263.
- Sarasvathy, S. D. (2008). Effectuation: Elements of Entrepreneurial Expertise. Edward Elgar Publishing.
- Dew, N., Sarasvathy, S. D., Read, S., & Wiltbank, R. (2009). Affordable loss: Behavioral economic aspects of the plunge decision. Strategic Entrepreneurship Journal, 3(2), 105–126.
- Chandler, G. N., DeTienne, D. R., McKelvie, A., & Mumford, T. V. (2011). Causation and effectuation processes: A validation study. Journal of Business Venturing, 26(3), 375–390.
- Read, S., Sarasvathy, S. D., Dew, N., & Wiltbank, R. (2016). Effectual Entrepreneurship (2nd ed.). Routledge.
参考書籍
