メインコンテンツへスキップ
Beancount.io Logo

シリーズA前のキャップテーブルのミス:オプションプール・シャッフル、ベスティングの落とし穴、積み上がったSAFE

公開日 最終更新 約1分Mike ThriftMike Thrift
シリーズA前のキャップテーブルのミス:オプションプール・シャッフル、ベスティングの落とし穴、積み上がったSAFE

毎週どこかの法律事務所で起きている光景がある。タームシートの期限前夜、創業者がキャップテーブルのスプレッドシートを開いてみると、数字が合わない。18か月前に去った共同創業者が、まだ元の付与分の100%を保有したままになっている。同じエンジェルラウンドから発行された2件のSAFEに、異なる転換上限(キャップ)が入力されている。誰が何をどれだけ所有しているのか、確信を持って答えられる人がいない。

企業がシリーズAに到達するころには、キャップテーブルはたいてい3、4人の異なる人物の手が入っており、そのうち誰もキャップテーブルの専門家ではない。設立時に弁護士が作成し、共同創業者が共有スプレッドシートで維持し、初期の従業員のオファーレターは別途作成されてマスターファイルに反映されないまま残っている。それぞれの編集は単体では小さく、正当化できるものだ。しかし積み重なると、投資家が最も厳しく精査しようとしているまさにその瞬間に、会社の所有構造を静かに誤って伝える文書ができあがる。

キャップテーブルのミスは、単なる経理上の煩わしさではない。資金調達を数週間遅らせたり、リード投資家を尻込みさせたり、創業者が気づかないうちに持分を手放す結果を招いたりする。ここでは実際に何が問題になるのか、そしてタームシートが机に届く前にそれをどう見つけるかを解説する。

キャップテーブルが実際に記録しているもの

資本政策表(キャップテーブル)とは、誰が会社をどれだけ所有しているかを記録した台帳である。最もシンプルに言えば、すべての株主、すべてのオプション付与、すべてのSAFEや転換社債、そしてそれぞれが会社に占める割合を、現在(「転換後」または完全希薄化後)の状態と、未行使のオプションや転換証券がすべて行使された場合の状態の両方でリストアップしたものだ。

その後者の計算、すなわち完全希薄化後の所有比率こそが、混乱の大半が生じる場所だ。発行済株式の40%を保有している創業者も、オプションプール、未転換のSAFE、未行使のワラントを織り込むと、実際には30%近くにまで下がっていることがある。投資家は常に完全希薄化後の基準で取引を評価する。自分の所有比率についての認識が発行済株式だけに基づいているなら、実在しない数字を根拠に交渉していることになる。

オプションプール・シャッフルとは

シリーズAで最もよく見られ、かつ最も誤解されている希薄化イベントが、ベンチャー業界で「オプションプール・シャッフル」と呼ばれるものだ。タームシートの中では読み飛ばしてしまいそうな一行として現れるが、見過ごすと高くつく。

仕組みはこうだ。シリーズAの投資家は通常、健全な規模のオプションプール――多くの場合ポストマネー(資金調達後)のキャップテーブルの15〜20%程度――を用意しておくことを求める。次の波の従業員を採用するのに十分な持分を確保しておくためで、原理的には問題ない。問題は、そのプールがいつ作られ、誰が希薄化の負担を負うかにある。

もし新しいプールがラウンド成立のに切り出される(「プレマネー」のプール)場合、その株式はほぼ既存株主――主に創業者たち――から丸ごと出ることになり、新しい投資家の持分比率はその希薄化から完全に守られる。創業者はこれに、署名した後に計算し直して初めて気づくことが多い。20%の持分を交渉して獲得したはずの投資家が、プレマネーのプール拡大を差し引いた結果、実質的に23〜24%を所有することになり、その差のほぼすべてを創業者側が吸収する形になる場合がある。

対策として求めるべきことははっきりしている。必ずしも認められるとは限らないが、オプションプールの規模設定と創設をポストマネーで行うよう交渉することだ。そうすればプール拡大による希薄化は、新しい投資家を含む全株主に比例配分され、創業者側からだけ切り出されることがなくなる。VCがプレマネーのプール条件を完全に譲らない場合、次善策としては、今後12〜18か月で会社が現実的に必要とする採用規模に見合うところまでプールの規模を交渉で縮小し、必要以上に全員を希薄化する過大な準備枠を受け入れないようにすることだ。

欠落した、あるいは機能していない創業者ベスティング

2つ目のよくあるミスは、投資家がまだ視野に入っていない、会社設立の段階で起きる。創業者が自分自身にベスティングスケジュールを一切付けずに株式を無条件で発行してしまうケースだ。

創業初期には不要に思えるかもしれない――自分は創業者なのだから、自分の株式にベスティングを付ける意味があるのかと。しかし創業者ベスティングの理屈は、初日における共同創業者同士の信頼とは何の関係もない。それは、誰も想定していないシナリオに対する備えなのだ。すなわち、8か月で離脱した共同創業者が持分を丸ごと保持し続け、その株式を価値あるものにするための貢献をその後一切しない、という事態への備えである。業界データによれば、シリーズBに到達するまでにおよそ3分の2のスタートアップが共同創業者の離脱を経験しているという――これは仮説上の稀なケースではなく、むしろ中央値に近い結果なのだ。

市場標準は、1年のクリフを伴う4年のベスティングスケジュールである。最初の12か月は一切ベスティングせず、その後25%が一括で権利確定し、残りの75%はその後3年間にわたって月次で権利確定していく。これはあらゆるキャップテーブルツールと法律事務所のテンプレートに標準として組み込まれている理由がある――投資家はそれが備わっていることを当然視しており、それがない会社はデューデリジェンスの段階で即座に警戒信号として扱われる。

技術的にはベスティングが設定されていても創業者を捕らえる、関連する落とし穴がある。それは、シリーズAを迎える時点で、すでにベスティングの大半が完了してしまっている状態だ。投資家は一般に、シリーズAでの資金調達時点で創業者の持分のうちベスティング済みの割合が40%程度を超えていないことを望む。投資家の資金は将来の何年もの労働を支えるためのものであり、すでに終わった年月への報酬ではない、という論理である。シリーズAの時点で90%がベスティング済みの創業者は、ベスティングリセット――すでに得た持分のかなりの部分を、ラウンドの条件として再びベスティングし直すこと――を求められる可能性がある。これを事前に知っておけば、期限に追われて受け入れるのではなく、意図的に交渉することができる。

積み上がったSAFEによる緩やかな希薄化

SAFE(将来株式取得のための簡易契約)が人気なのには理由がある。速く、安く、シード段階の会社がラウンドの価格付けをせずに資金調達できるからだ。問題が始まるのは、ある会社が18か月の間に3件、4件、あるいは5件ものSAFEを発行し、それぞれ異なるバリュエーションキャップ、ディスカウント率、最恵国待遇条項を持っているにもかかわらず、それらすべてが価格付きラウンドで同時に転換されたときに何が起きるかを、誰もモデル化していない場合だ。

それぞれのSAFEは単体で見れば小さく見える。しかし積み重なると、創業者が一度もモデル化しなかった希薄化へと複利的に膨らんでいくことがある――シード段階全体を通じて手放すつもりだった以上に、会社のかなり大きな部分が転換によって食われてしまうケースすらある。広く引用されている2024年のある業界調査では、米国のスタートアップの40%超が、転換証券の管理不備に起因する法的紛争や資金調達の遅延に見舞われたと報告されており、その大部分は転換条件が不明確だったこと、あるいはSAFEがそもそもキャップテーブルに正しく記録されていなかったことに端を発していた。

対策はSAFEを避けることではなく、価格付きラウンドの時点で一度きり計算するのではなく、新しいSAFEを発行するたびに転換シナリオをモデル化することだ。「プレマネー評価額$24Mで$6Mのシリーズ Aを調達したらどうなるか」という単純なシナリオを、SAFEを発行するたびに再計算しておけば、デューデリジェンスの最中に発見するのではなく、まだ取引条件を調整できる余裕があるうちに複利的な希薄化を捉えられる。

「ほぼすべてのキャップテーブルに計算ミスがある」と言われる理由

これはキャップテーブルを専門的に審査する投資家やキャップテーブル専門家からの直接の実感であり、誇張ではない。新規付与後の希薄化が反映されていない、ベスティング開始日が実際のオファーレターと一致していない、SAFEが誤った転換キャップで入力されている、口頭では合意したが正式に文書化されなかったアドバイザー向け付与――これらのどれか一つでも、それに依存するすべての所有比率を狂わせる。

スプレッドシートがこうしたミスを捕捉できないのは、そもそもそのために設計されていないからだ。スプレッドシートは入力された数式を忠実に計算するだけで、あるベスティング開始日が8か月前に署名されたオファーレターと整合しているかどうか、あるいはSAFEの転換条件が正しく入力されているかどうかという概念を持たない。専用のキャップテーブルソフトウェアは、入力項目同士を相互検証することで、こうしたミスのかなりの部分を捕捉する。これが導入が急速に進んでいる大きな理由であり、シリーズAおよびBの企業の大多数は今やスプレッドシートではなく専用のキャップテーブルツールを使っている。もっとも、構造がシンプルな非常に初期段階のプレシード企業であれば、きちんと管理されたスプレッドシートでも依然として機能する。

すでにキャップテーブルが乱れている場合、資金調達の最中にその場しのぎで直そうとする衝動は理解できるが、順序が逆だ。デューデリジェンスが始まる前に整理しておくべきだ。

  1. 分からないことをすべて洗い出す。 どの付与に書類があり、どれにないか、どのベスティング開始日が推定値か。
  2. すべての株主に自分の持分を確認してもらう。 創業者、従業員、アドバイザー、SAFE保有者――全員に。
  3. 元となる文書を集める。 オプション契約書、SAFE、転換社債、取締役会の同意書――合意した内容の記憶ではなく。
  4. それらの文書と整合するようにテーブルを再構築する――自分が正しいと思い込んでいた内容ではなく。
  5. 取締役会の承認を得る。 投資家の前に出す前に、整合が取れたテーブルが正確であることを確認してもらう。

帳簿管理の規律は現金だけでなく持分にも及ぶ

毎月銀行口座を丁寧に照合している創業者でも、キャップテーブルを継続的に維持するのではなく、資金調達の直前に慌てて更新する後回しの対象として扱ってしまうことがある。しかし持分も他の財務記録と同様の記録であり、帳簿と同じ規律を払うに値する。付与が発生したらその都度記録し、離脱があれば即座に反映し、SAFEはおおよその近似値ではなく実際の条件で記録する。キャップテーブルを、期限に追われて再構築するものではなく、リアルタイムで更新される生きた財務記録として扱う会社は、思わぬ発覚のリスクをはるかに小さくしてデューデリジェンスに臨むことができる。

同じ原則は、財務記録の他の部分にも当てはまる。プレーンテキストでバージョン管理された帳簿であれば、いつ、誰によって取引が記録されたかを正確に把握できる――これはクリーンなキャップテーブルに必要なのと同種の監査証跡を、日々の財務にも適用したものだ。

財務管理をシンプルに

資金調達に向けて準備する際、クリーンな財務記録はクリーンなキャップテーブルと同じくらい重要だ――投資家はその両方を精査する。Beancount.ioはプレーンテキスト会計を提供し、完全な透明性とデータへのコントロール、フルバージョン履歴、ベンダーロックインなしを実現する。無料で始めると、なぜ開発者や財務の専門家がプレーンテキスト会計に切り替えているのかがわかるはずだ。

この記事を共有