AIのおかげで最小限の人員で10億ドル級スタートアップを構築できるようになった

• スタートアップ成功の新たなパラダイムとして、少人数チームが巨大な価値を生み出すやり方が注目されている
• スピード、明確さ、当事者意識が少人数チームにとって重要であり、階層や調整コストが取り除かれると、意思決定は直接的かつ迅速になり、製品リリースの速度が最大化される
• 組織設計ではアンチフラジャイルな構造と自律的なポッド（pod）運営が核心であり、道具ではなくシステム設計こそが真のレバレッジをもたらす
• 採用は最後の手段とし、成果志向のT字型人材に集中し、ネットワーク型コアと外部リソースを通じて柔軟にスケールする
• 性急な拡大と早すぎる採用の隠れたコストを警戒し、少人数で明瞭さをスケールさせる創業者像を新たな標準として提示する

---

1. 「人が多いほど、前進も多い」という神話

• Instagramは従業員13人で10億ドルで買収され、WhatsAppは55人で190億ドル、YouTubeは65人で16.5億ドルで買収された
  • これらは例外ではなく、少人数の集中チームが不均衡に高い価値の企業を築くという反復的なパターンの初期シグナルだった
• これらのチームの共通点は、単なる好機や優れた製品アイデアではなく組織構造にあった
  • 素早く動けるからこそ素早く動き、アラインメント会議に縛られず意思決定を行えた
  • 単にオーバーヘッドを減らしたのではなく、スピードを鈍らせるあらゆるものを取り除いた
• これはAIや投資家の引き締めによって生まれたトレンドではなく、以前から存在していた構造的優位性であり、最も成功したテック企業を静かに支えてきたものだ
• Leanなチームは、単に資源制約の中で生き残るだけでなく、しばしばより優れた成果を出す
• 今日では、より良いツール、自動化、配布手段があるため、少人数チームの潜在力はかつてないほど高い

2. 少人数チームが勝つ理由: スピード、明確さ、当事者意識

• 少人数チームの強みは、より一生懸命働くことではなく、異なるやり方で運営することから生まれる
• 小さなチームにはプロセスの霧がない
  • 会議の準備のための会議もなく、助手席で手持ち無沙汰に座る人もいない
  • 全員がクリティカルパス上にいて、すべての意思決定が直接的だ
• 階層の本質と調整の重みを取り除くと、残るのはスピードだ
• 信頼はデフォルトで存在し、獲得したり文書化したり委任したりする必要がない
  • 誰が何をしていて、それが目標とどうつながっているかを全員が理解している
  • 組織図やプロジェクト管理ツールがなくても、責任はデフォルトで可視化される
• 少人数チームは自然に信頼の基盤をつくる
  • 多くのスタートアップは、実際に必要になる前に調整を外部化しようとして、プロダクトマネージャーを早すぎる段階で採用してしまう
  • 少人数チームで調整が起きるのは、人が超人的だからではなく、システムが翻訳レイヤーの負荷を受けていないために_有機的に_起こるからだ
• Beehiivは小さなプロダクトポッドに完全なオーナーシップを与えることで、20人未満で脱出速度に到達した
• Gumroadは、大半のシリーズAスタートアップより小さなチームで年間経常収益1,000万ドルを超え、意思決定が6つの階層を通過する必要のない会社を設計した
• 少人数チームは人材密度の利点も享受する
  • 100人は必要なく、関心を持ち、問題を最初から最後まで引き受け、明確さを持って動ける5人がいればよい

3. 脆くないスタートアップを設計する: 構造こそ戦略

• 大半のスタートアップは、小さいから崩れるのではなく、明確さが欠けているから崩れる
• 人が多いほど力も大きいという前提は時代遅れだ
  • 脆弱性は少人数から生まれるのではなく、膨れ上がった構造から生まれる
  • オーナーシップのない複雑さと、一貫性のない成長から生じる
• 最も強い少人数スタートアップは、階層を追加してスケールするのではなく、人員数が前進の推進力と_無関係になる_システムを設計することでスケールする
• PostHogのプレイブック: レバレッジ単位としてのチーム
  • PostHogが50人未満で驚くほど幅広い製品を構築できたのは、チームをマイクロスタートアップの艦隊のように設計したからだ
    • 各ユニットは2〜6人で構成され、それぞれが事業の一部分を所有する
    • 各チームは自分たちで目標を設定し、自分たちでレビューを行い、自分たちでロードマップを構築し、自分たちで品質管理を担い、自分たちでデプロイスケジュールを管理する
    • 依存関係も引き継ぎもない
  • これが解決するのはスピードだけでなく回復力だ
    • 1つのチームが停滞しても、他のチームはリリースを続ける
    • 意思決定が失敗しても、爆発半径は局所的にとどまる
  • Basecampは約30人で管理職なしに運営され、非同期コミュニケーションとローカルな意思決定を維持しながら、収益性の高いSaaSを運営している
  • Oculusも20億ドルで買収される前は75人のチームで運営されており、規模ではなく構造がイノベーションを牽引することを証明した
  • トレードオフは何か。肩書きを超えて考えられる強力なジェネラリストが必要であり、通常は階層が担う仕事をカルチャーが担うようにしなければならない
    • カルチャーとは、共有された価値観、非同期の透明性、明確な目標を意味する
• サイロではなく、システム
  • スタートアップは人員で定義されるのではなく、ループで定義される
    • 収益ループ、製品ループ、フィードバックループ
  • 少人数チームは、すべての行動が部門間の深淵を越えずに次の行動を生み出す、緊密で自己維持的なシステムの中で動くときに勝つ
  • マーケティングチームがデータチームからレポートが届くまで2週間待たなければならない時点で、すでにスピードは失われている
  • 顧客フィードバックがプロダクトリーダーに届くまでに5回の会議が必要な時点で、その真実は薄められている
  • 構造はシグナルを加速させるべきであり、減衰させてはならない
• 自前の「スタートアップたちのスタートアップ」を構築する
  このモデルを再現するには:
  • 自律的なポッドをつくる - 各チームに明確なミッション、担当領域、リリース権限を与える
  • 共有指標を使う - すべてのチームが同じ成果にどう貢献しているかを見えるようにする
  • 意思決定サイクルを短縮する - 6週間スプリントで動き、非同期チェックインを行い、何がうまくいき何がうまくいかなかったかを1ページの簡潔なレビューにまとめる
• カルチャー優先、構造は後からついてくる
  • どう構造化するかは、単なる運営効率ではなくアイデンティティの問題でもある
  • 仕事の組織の仕方は、チームに何を重視しているかを伝える
  • 自律性、オーナーシップ、スピードのようなものは偶然に生まれるのではなく、設計されるものだ
  • 脆いスタートアップは「これは誰にエスカレーションすべきか？」と問い、脆くないスタートアップは「これを直す最も速い方法は何か？」と問う

4. 道具ではなくシステムがアドバンテージ

• 多くの創業者が陥る一般的な罠: ツールをレバレッジだと勘違いすること
  • 自動化ソフトウェアを詰め込み、最新のAIコパイロットを買い、何十ものSaaSプラットフォームを統合しても、なぜ依然として遅いのか不思議がる
• 問題はツールではなく、システムの不在だ
• 効率性はソフトウェアを積み重ねることから生まれるのではなく、人間の努力が希少で、慎重で、尊重されるワークフローを設計することから生まれる
  • すべての作業は、自動化されるずっと前に「これは存在する必要があるのか？」という問いを受けるべきだ
• 壊れたプロセスを加速するツールは問題を解決せず、ただより速く時間を無駄にさせるだけだ

• Pieter Levelsのプレイブック: オーケストレーション > 自動化

  • Pieter Levelsは、チームなしでシステム設計を極めることで、数百万ドル規模のビジネスポートフォリオを築き、広く知られるようになった
    • Nomad List、Remote OK、Rebase――これらは単なるウェブサイトではなく、ユーザー行動がビジネスを養うよう緻密に設計された機械だ
  • Levelsは、より多くの機能をコードしてスケールしたのではなく、製品が実質的に自走できるようになるまで摩擦を取り除くことでスケールした
  • Nomad Listの仕組み:
    • ユーザーが都市を記録し、フィードバックを共有し、生活費データを更新することでコンテンツが生成される
    • そのコンテンツがロングテールSEOを駆動し、何十万ものページが自然にインデックスされる
    • SEOがトラフィックを呼び込み、トラフィックが有料サブスクリプションを促進する
    • 有料会員がコミュニティを管理し、品質を高く保つ
  • サポートチームも、営業も、マーケティング部門もない。あるのはループだけだ
  • 彼が使うAIツール（画像生成、メール下書き、モデレーションフィルター）は単なる補助役であり、中核エンジンではない
  • これは自動化ではなくオーケストレーションだ
  • 同様のパターンはMinecraftの初期にも見られた。Markus Perssonは、マーケティングチームも営業オペレーションも、コミュニティとダウンロードボタン以上のインフラもないまま、構築し収益化した
    • 製品品質がファンの参加を促し、それが販売を促進し、それがより良い開発資金を生み出す自己強化ループ

• スタックではなくシステムから始める

  • あまりにも多くの創業者が「どのツールを導入すべきか？」から始めてしまう
  • より良い問いは次の通りだ: 自分が今も手作業でやっている、最も反復的な仕事は何か？
  • 次に: その作業は存在する必要があるのか？
  • そしてその後で初めて自動化に手を伸ばすべきだ
  • システムが肥大化していれば、AIはそれを良くしない。ただより速くし、運用コストを高くするだけだ

5. 肥大化せずに採用する: いつ、なぜ、誰を

• ほとんどの創業者は採用をマイルストーンとして扱い、祝うべきことだと考える
• しかし初期段階では、採用は単なる意思決定ではなく負債だ
  • 新しい人が入るたびに重みが増す。会話は増え、コンテキスト共有は増え、複雑性は増す
• より良いアプローチは最後の手段として採用することだ――まずシステムを構築する
• 問うべきはこうだ: これは自動化できるか？ テンプレート化できるか？ 一時的に外注できるか？
• 答えがノーで、その仕事がミッションクリティカルなときにのみ、人を迎えるべきだ
  • そのときでも基準は非常に高くあるべきだ

• 役割ではなく成果のために採用する

  • 初期段階のチームに必要なのは、それぞれの小さなバブルの中で働く専門家ではない
  • 最初から最後まで問題を引き受けられる人が必要だ
  • それはT字型人材を探すことを意味する
    • ある領域で深い専門性を持ちながら、他の領域では幅広いスキルを持つ人
    • コードが書けるマーケター、コンバージョンファネルを理解するデザイナー、顧客と話すことを楽しむエンジニア
  • 重要なのは、その人が組織図にきれいにはまるかではなく、継続的な調整なしに成果を出せるかどうかだ
  • 部門をつくる代わりにミッションをつくり、そのミッションを完全な自律性で前進させられる人を探すべきだ

• 初期の肥大化の罠を避ける

  • 必要ないもの:
    • 誰にも求められていないチケットを書くプロダクトマネージャー
    • まだ売る準備ができていない創業者のために会議を設定する営業開発担当者
    • 8人のチームを管理するHRリーダー
  • 必要なもの:
    • 全体像を見られる職人
    • ループで考えるオペレーター
    • 許可を求めないビルダー
  • AmazonがTwitchを9億7,000万ドルで買収する前、Twitchはおよそ100人の従業員でLeanに運営されていた
    • ニッチカテゴリーにおける超高速成長が、常に肥大化したチームを必要とするわけではないことの証拠だ
    • 必要なのは徹底した製品集中とコミュニティレバレッジだけだ
  • スタートアップの最初の本能が「これのための誰かが必要だ」なら、立ち止まるべきだ
  • 代わりにこう試すべきだ: 「これのためにはシステムが必要で、それが機能しないなら、3人分の仕事を1人で処理できる人を探そう。」

6. モデルを壊さずにスケールする

• 小さく始めるのは簡単な部分だが、成長しながら小さな精神を保つことこそが難しい
• 製品が跳ね、収益が伸び、要求が増えたときに本当の試練が来る
  • 顧客は増え、機能は増え、対処すべきエッジケースも増える
• 自然な反応は採用によって拡大することだ。より多くのチーム、より多くの管理職、より多くの階層
• 注意しなければ、会社を機能させていたもの（スピード、明確さ、オーナーシップ）が失われ始める
  • 単に人を足すのではなく、摩擦を足してしまう

• ネットワーク型コア

  • 肥大化せずにスケールする方法の1つは、ネットワーク型コアを築くことだ
  • 中心部: 小さく恒久的なチーム――指揮ユニットであり、コアそのもの
    • ビジョン、ロードマップ、カルチャーを担う人たち
  • そのコアの周囲: フラクショナル採用、契約人材、エージェンシー、AIベースのプロセスによるモジュール型のリングがあり、必要に応じて拡大・縮小する
    • この外側の層は、すべての機能を内製化せずに高度技能または大量処理の仕事を担う
  • サポートは柔軟に設計し、マーケティングはローンチに合わせて拡大し、その後縮小できるようにする
  • AIを日常業務に使い、ヘッドカウント目標を満たすためではなく、限定的なミッションのために専門家を雇う
  • WazeはGoogleに10億ドルで買収されたが、Leanな内部チームとユーザー生成データの外部ネットワークを組み合わせたハイブリッドモデルでスケールした
    • ボランティアの地図編集者とクラウドソーシングの報告が、内部の複雑性を増やすことなく製品をより賢くした

• 敏捷性はスケールするが、設計があってこそ

  • Leanであることは脆いことを意味しない。脆いのは、浅い仕事をする肥大化したチームだ
  • 内側から外側へ構築し、緊密なコアと拡張可能なシェルを持てば、表面積が大きくなっても敏捷性を維持できる
  • 会議を増やさずにアウトプットを拡大でき、混乱を加えずにより大きな複雑性を扱える
  • それが技術だ: 測定しやすいものではなく、重要なものを成長させること
  • 最高の創業者は、単に会社を拡大するのではなく、明確さをスケールさせる

7. 早すぎる採用に潜む隠れたコスト

• プロダクト・マーケット・フィットを見つける前に拡大した創業者に話を聞くと、後悔は驚くほど似ている: 「私たちは採用が早すぎた。」
• それは楽観から始まる。いくつかの勝利、少しの資金、そして突然「チームをつくる」時が来たように感じる
• しかし強固な基盤（明確な製品価値、緊密な顧客フィードバックループ、再現可能な獲得）がないまま人員を増やすことは、前進ではなく不確実性を増幅させるだけだ

• 組織負債は実在する

  • 早すぎる採用は、単に資本をより速く燃やすだけではない
  • 調整負債も増やす――アラインメントを取り、オンボーディングし、管理すべき人が増える
  • 感情的負債も増やす――まだ影響を出していない役割を正当化しなければならない圧力が生まれる
  • 文化的負債も増やす――少人数チームが繁栄するオーナーシップのメンタリティを薄めてしまう
  • モメンタムは忙しさに置き換わり、実験の代わりに会議が進み、製品リリースの代わりに作業レビューを行うようになる
  • 気づけば、すべてが以前より長くかかるのに、誰もその理由をはっきり説明できない

• 複雑性にはコストがある

  • 新しい人はすべて、ネットワークのノードだ
    • より多くの意思決定がアラインメントを必要とし、より多くのツールがアクセス権を必要とし、より多くの階層が説明を求める
  • 製品が必然的に方向転換するとき（いつもそうだ）、今度はもはや存在しないビジネスのバージョンのために採用された人たちを抱えることになる

• 基本の問いを置き換える

  • 採用前に問うべきでないこと: 「これのための誰かが必要か？」
  • 代わりにこう問うべきだ:
    • 「ワークフローを再設計できるか？」
    • 「このレイヤーを自動化できるか？」
    • 「Leanを維持できる程度に、この端の部分だけを外注できるか？」
  • 人員は進歩のバッジではなく、明確さへの賭けだ

8. 新しい種類の創業者

• 原型が変わりつつある
• 未来の創業者は、1億ドルを調達して100人を雇う人ではなく、5人で年間1,000万ドルの売上を回し、夜に安心して眠れる人だ
• ストレスではなく、システムを通じて成長をオーケストレーションするソロ創業者
• 自ら売れ、自らサポートする製品を持つ3人チーム
• 会議もドラマもなく、1日に6桁の売上を稼ぐ6人企業
• 彼らはもはや珍しいケースでも外れ値でもなく、新たな標準になりつつある
• その変化は、単なる効率性よりも深い
  • それは優雅さ、オーナーシップ、持続可能性に関わるものだ
• 今日の最高の創業者は、成長そのもののために成長を追わない
  • 自らの組織的複雑性の重さに押しつぶされることなく、統制し、進化させ、誇りに思える会社を築いている
• 小さいことは、単に美しいだけでなく戦略的だ
  • 精神的にも健全であり、適切な手にかかれば止められない
• これは、質素な始まりへのノスタルジーではなく、肥大化せずに偉大なものを築くための戦術ガイドだ

[shakespeares]

少人数のチームが勝つ理由として、スピード、明確さ、当事者意識にはひとまず同意しますが、安定した運営も必要な状況であれば、組織は大きくならざるを得ないと思います。
最近、大きな組織の中でセルやサイロとして運営される理由とも合致している気がします。