最初に「ファンドレイズ」の誤った言い間違いをほぼしてしまったとき、私は小さなフィンテック組織に投稿者が飛び込んでくるのを眺めていました。11日で5人から12人へ。きれいなステップ関数で、チャートに出てくるタイプのやつ——見た瞬間にSlackを開きたくなるやつです。私は投資家の友人にメッセージ草案を送りました。「このチームが資金を集めました。今後2週間以内に発表があるはず」——そして、そこで我に返りました。同じ形がその四半期に6回まったく同じように燃え上がっていて、実際にラウンドに結びついたのは2回だけだったからです。残り4回は、ハッカソン、Google Summer of Codeのコホート、オープンソースの投稿者向けスプリント、そして「個人アカウントにコミットしていた」チームでした。組織改編（re-org）でカウントが跳ね上がったのです。
私はそのメッセージを削除しました。
その日から、私はGitHubのどんな単一シグナルも信じないことにしました。約4,200のスタートアップ組織を6か月間ウォッチしてコミットのトラフィックを見た結果、重要視する5つのパターンと、それらを束ねる1つのルールがあります——「シグナルは単独では発火しない」。1つ見えたら、私は肩をすくめます。2つが同じ2週間の中で同時に発火していたら、椅子から立ちます。
Pattern 1 — the contributor step function
最も引用されているパターンは、同時に最も騙されやすいパターンでもあります。スタートアップが2週間で投稿者5人から12人へ増える。仮説はこうです——ラウンドがクローズし、チームが採用を立ち上げて、新しいエンジニアが最初のコミットを押し出している。仮説が当たることもあります。でも、それはしばしば「ノイズ」です。
私が実際に見るのは、ユニーク投稿者が持続的に50%増えることを最低4週間確認すること、そして新しい投稿者が、その組織内の複数のリポジトリに現れることです。単発のドキュメント中心のスプリントだけでは足りません。新しい投稿者が1つのリポジトリにだけコミットして10日後に消えるなら、それはハッカソンです。コードベース全体に出てきて、その後も残っているなら、それは採用です。
以下は、私が毎週GitHub Archiveのミラーに対して実行しているSQLです。凝ったものではありません——ただしlast_commit_atでの結合（JOIN）が、ハッカソンの誤検知を殺してくれます：
WITH new_contribs AS (
SELECT actor.login AS user, repo.org AS org,
MIN(created_at) AS first_commit_at,
MAX(created_at) AS last_commit_at,
COUNT(DISTINCT repo.name) AS repos_touched
FROM gh_archive_events
WHERE type = 'PushEvent'
AND created_at BETWEEN now() - interval '60 days' AND now()
GROUP BY 1, 2
)
SELECT org, COUNT(*) AS retained_new_contribs
FROM new_contribs
WHERE first_commit_at >= now() - interval '30 days'
AND last_commit_at >= now() - interval '7 days'
AND repos_touched >= 2
GROUP BY org
ORDER BY retained_new_contribs DESC;
repos_touched >= 2のフィルタ単体だけでも、以前私が受けていた誤検知の約40%を落としてくれます。この数字は机上の空論ではありません——これを追加した週に、実際にノイズがどれだけ減ったかがそれでした。
Pattern 2 — the infrastructure explosion
30日以内に同じ組織内で、新しい公開リポジトリが3つから5つ現れる。そして新しいリポジトリはインフラっぽい形——SDK、社内ツール、デプロイ設定、terraformモジュールなど。フォークのスプリントではありません。ドキュメントサイトの派生でもない。きちんとしたプラットフォームの土台作りです。
これはレアですが、発火するときはほとんど単独では起きません。企業がプラットフォームエンジニアリングに「思いつきで」投資することはありません——それをやるのは、そこに使う余地（ランウェイ）ができたときです。私はYCのある会社が、Series Aの発表の2か月前にこれをやっているのを見つけました。きっかけは1週間で4つの新規リポジトリが作られたこと。名前はAWSのサービスにちなんでいて、CTOが作成しており、すべてのリポジトリで初回コミットが「ローカルで開発してきたコード」というより、社内に用意した足場（scaffolding）をそのままチェックインしたように読める内容だったのです。
コツは：各新規リポジトリの最初のコミットを読むことです。最初のコミットが、事前のローカル履歴がない状態で200ファイル規模のgit pushなら、「非公開リポジトリが公開された」可能性が高いです。最初のコミットが単一のREADME.mdなら、誰かがゼロから始めている。次に興味深いのは2つ目です——インフラ領域での「新規スタート」は、チームに新しいものを作るだけの余裕（ブリージングルーム）があるという合図になります。
Pattern 3 — weekend commits across multiple humans
コミットログが「平日のみ」から「週7日」の状態に変わっていくスタートアップは、何かに向かって突っ走っています。落とし穴：ソロの創業者による週末の活動だけでは意味がありません。彼らはいつもそうしていたはずです。3人か4人の投稿者による週末の活動が、3週連続で持続しているなら、期限があるということです。
このパターンを生む期限を、私のデータで頻度順に並べると：
- ファンドレイズのためのデモ（通常Series A以降——プレシードのチームは週末に人が集合するような編成を引っ張るほど小さすぎます）。
- プレスのサイクルが付いたプロダクトローンチ。
- 同じレーンで走る大企業の直近の動きに対する競合的な対応。
この3つのうち2つは投資家にとって興味深いものです。3つ目はエンジニアである私にとって興味深いです。なぜなら、3つ目は通常、転機（＝大きな動き）がHacker Newsに現れる10日前に目に見える形で出てくるからです。
Pattern 4 — the documentation sprint
エンジニアは自発的にドキュメントを書くことはありません。だから、チームのコミットログが突然、機能開発からドキュメントへと切り替わると——READMEの書き換え、APIリファレンス、アーキテクチャ図、コントリビューションガイドなど——誰かが彼らにそうさせたことになります。その「誰か」はだいたい3人のうちの誰かです。資金調達のリードとしてデューデリジェンス準備をしている人、OSSローンチに向けてコミュニティ責任者として準備している人、新しいVPエンジニアが採用した人たちのオンボーディングをしている人。
3つとも興味深いです。最も「ファンドレイズだ」と一意に見分けられるのは、sequence（シーケンス）です。機能コミットのスプリントがあり、次にドキュメントへ強くピボットし、その2週間後に再び機能へ戻る。あのミッドサイクルのドキュメント・スプリントこそが入念な準備です。チームは、投資家のアナリストが初めてコードベースを開くときに、コードベースがすっきり読める状態になっていることを確認しています。
パターン5 — 速度（バリュエーション）のレジーム転換
最も強いシグナルは、同時に最も単純でもあります。14日間のローリング・ウィンドウでコミット速度を計算します。それを組織の6か月平均と比較してください。現在のウィンドウが平均の2倍を超え、さらに次の2つのウィンドウでも1.8倍を上回って推移するなら、チームはレジームを変えています。今週やる気があるから速く出しているのではありません。彼らの下で何か組織的な変化が起きたから、より速く出しているのです。
速度レジームの変化は、私が測定してきた他のどの単一指標よりも、ラウンドとの相関がよりはっきりしています。発表の約3週間前にリードタイムがあります。ヒット率は単体だと約35%で、つまりレジーム変更の3分の2はラウンドにつながりません。ピボットもあります。ピボット後の立て直しもあります。そして、ただあるエンジニアがすごくワクワクして一時的に加速しただけ、というケースもあります。
しかし、レジーム変更がコントリビューターのステップ関数と重なると、私の2025年Q3〜Q4のバックテストではヒット率が約70%に跳ね上がります。私が実際に動くのは、この組み合わせです。
私が間違えていた部分
最初の3か月は、コミット数にコミット速度の変化よりも重い比重を置いていました。高ボリュームの組織は質の高いリードだと見込んでいました。でも違いました。単に規模が大きいだけでした。
修正は、セクター内でzスコアを使うことでした。5人の開発者のdevtools企業での200コミットの週は、レジーム変更です。50人規模のAIインフラ企業での200コミットの週は、ただの火曜日です。(velocity - 6mo_mean) / 6mo_stddevで順位付けし始めてから、ノイズが減り、小規模チームのシグナルが上位に浮上しました。結局資金調達につながった組織は「うるさかった」組織ではありませんでした。自分たちの静かなベースラインが、最初に崩れた組織だったのです。
私が毎週月曜に実際にやっていること
データが何を示そうと、ワークフローは毎週同じです：
- ウォッチリストに載っている各組織について、最新の14日分の
PushEventを取得します（現時点で約4,200）。 - 各組織について上記の5つのパターンを計算します。
- 同時に2つ以上のパターンが発火している組織に絞り込みます。
- 生き残った各組織について、GitHubの組織ページを開き、直近1週間のコミットをざっと見ます。コミットが「バージョンを上げているだけ」ではなく、本物のプロダクト作業のように見えるなら、その組織は通話リストに入れます。
- 通話リストはドキュメントに投入し、各会社につき1行のメモを添えます。ある週は4社分、ある週は30社分になります。
もう単一パターンの発火だけでは動きません。投資家の友人に、ハッカソンを開催していたフィンテックについてメールしそうになったあの日以来、そのやり方はやめました。シグナルは大きかった。けれどシグナルは間違っていたのです。修正は「より良いシグナル」を見つけることではありませんでした。どれか1つを信じる前に、2つが同意するよう強制することでした。
元の記事はsignals.gitdealflow.comに掲載されていました。週次のSignal Reportは無料です—ペイウォールも、アカウント作成も不要です。
