GTM エンジン: ICE、Bullseye、次のチャネルを実際にどう選ぶか

チャネルは19ある。そのうち1つか2つがビジネスを動かす。GTMエンジンの仕事は、どのチャネルをどの順番で使い、いつ機能しなくなるかを見極めることだ。このガイドでは、チャネルの全体像、ICEによる優先順位付け、Bullseyeのリング、停止基準を伴うチャネル実験、そしてスケール可否を判断するチャネル別ユニットエコノミクスを扱う。

ほとんどの企業は、前職でうまくいったチャネルや流行りのチャネルを選ぶ。どちらもあてにならない経験則だ。チャネルの講座を終えたファウンダーはSEO、メール、LinkedInに自信を持ち、3つを同時に試す。半年後、ブログは中途半端、メールリストは40人、投稿習慣は8週目で途絶えている。どれも積み上がらなかった。どのチャネルにも、成果が出るだけの集中した注意を注げなかったからだ。

// 01チャネルの宇宙

GTMプランニングの最初の間違いは、選択肢が少ないと思い込むことだ。ファウンダーは知っているチャネルを3つか4つ検討し、最も簡単なものを選び、それを戦略と呼ぶ。Tractionの著者たちは19の異なる獲得チャネルを整理している。検索広告、SEO、コンテンツ、メール、ソーシャル、パートナーシップ、アフィリエイト、事業開発、セールス、バイラル、エンジニアリング発のマーケティング、変則的なPR、広報、展示会、オフラインイベント、登壇、コミュニティ構築、既存プラットフォーム、ターゲット市場のブログ。

// 02ICEによる優先順位付け

• インパクト: このチャネルがうまく機能した場合、どれくらい大きく成果を動かせるか。
• 確信度: このチャネルが自分たちの文脈で本当に機能すると、どれくらい確信できるか。証拠、類似例、過去の試行に基づいて考える。
• 実行しやすさ: 意味のあるテストを走らせるのに、どれくらいの労力、時間、予算がかかるか。

ICEスコア = インパクト × 確信度 × 実行しやすさ

1から10のスケールを使う。掛け算にすると、どの軸のゼロも強く効く。誰も信じていない、あるいはテスト不可能なチャネルは、理論上のインパクトが大きくても勝ち筋になりにくい。

よくあるスコアリングの間違い

• インパクトを過大評価する: インパクトが9でも他がすべて2なら、ICEの積は36でほぼ下位になる。確信度と実行しやすさも、インパクトと同じくらい真剣に扱う。
• 確信度を楽観と混同する: 確信度は「どんな証拠があるか」だ。競合の事例、データ調査、過去の試行など具体的な根拠を1つも挙げられないなら、7ではなく3以下と見る。
• 機会費用を無視する: 実行しやすさは相対的だ。週10時間かかるチャネルは、他が週20時間かかるなら簡単で、他が3時間なら難しい。

// 03Bullseyeフレームワーク

ICEはランク付けされたリストを生み出す。Bullseyeはそれをどう扱うかを決める。

• 外側のリング (可能性あり): すべてのもっともらしいチャネル。ICEでランク付けされた完全なリスト。意図的に広く取る。
• 中間のリング (有望): 能動的にテスト中の3〜5チャネル。明示的な成功基準と停止基準を持つ、小さく期限付きの実験を並列で走らせる。
• 内側のリング (中核): 不釣り合いな投資に値すると分かった1〜2チャネル。積み上がる成長エンジン。時間、予算、注意の大半を使う。

// 04チャネル実験を走らせる

どのチャネル実験も、始める前に5つのことを明示する必要がある。

• 仮説: 「OSSが解決する問題に関する深い技術記事は、60日以内にホスト型プランの登録を少なくとも5件生む」。
• 最小のテスト: 意思決定に足る証拠を生む最も安価な形。12本のコンテンツシリーズは要らない。エンジニアがすでにその課題を検索する文脈に合う、深い技術記事が3本あればよい。
• 固定期間: チャネルに応じて30 / 60 / 90日。SEOとコンテンツは回収までの遅れがあるため長めに見る。有料広告とアウトリーチは30日で判定できる。
• 成功基準: 「Y未満のCACでホスト型プランの登録を少なくともX件生む」。事前に数字を挙げられないなら、どんな結果でも合理化してしまう。
• 停止基準: 「60日後にチャネルからのホスト型プラン登録が合計2件未満なら停止し、労力を振り向け直す」。停止基準はサンクコストバイアスを断ち切る。

// 05チャネルのユニットエコノミクス

登録を生むチャネルは、まだ機能するチャネルではない。LTVより高いCACで登録を生むかもしれず、そうなると新しいチームアカウントごとにユニット単位で赤字を出している。$49/seat/moのホスト型プランと4 seatの混合チーム(おおよそ$2,350のACV)で、$6KのCACはチャーンを織り込む前から12ヶ月の回収期間を意味する。OSS配布チャネル(GitHubスター22K、週次アクティブOSSユーザー約3K、ホスト型プランへの変換率1.8%)はその基準を余裕で超える。ほとんどの有料チャネルは超えない。

チャネルごとのペイバック期間

• SEOコンテンツ: 回収は長い(4〜6ヶ月)が、積み上がるカーブを持つ。キャッシュランウェイが必要。
• 有料広告: 月ごとに回収できるが上限がある。支出を止めた瞬間にリターンも止まる。
• パートナーシップ: 大当たりか外れか。素晴らしいパートナー1つが1年分の労力を回収する。多くのパートナーは何も回収しない。
• ニュースレタースポンサーシップ: 安定した出力に控えめな複利。ペイバックプロファイルではSEOと有料広告の間に位置する。デベロッパーニュースレター(Bytes、Pointer)のスポンサーシップは50Kの受信箱に一度届き、何週間も登録をじわじわ生む。

チャネルごとのLTV:CAC比

分析の第二層は、チャネルがいつ損益分岐に達するかだけでなく、支出の1単位ごとに生産性があるかを問う。LTV:CAC(モジュール1.1で導入)が健全性チェックになる。健全なチャネルの目安として3:1は使いやすい。

// 06チャネルからシステムへ

GTMエンジンはチャネルの総和ではない。それらの合成だ。各層が次を養う有向グラフであり、フィードバックループが支払うチームを再び獲得に変える。

• 獲得: 認知とトラフィックを生むトップオブファネルのチャネル。仕事は、適切な人々を引き寄せること。
• 捕捉: OSSドキュメントの登録ウォール、ホスト型プランのランディングページ、GitHub Sponsorsでの言及、カンファレンストーク後のフォローアップフォーム。仕事は、温まったOSSユーザーをチームアカウントに変えること。
• 信頼づくり: メールシーケンス、コンテンツのフォローアップ、ソーシャルリターゲティング。仕事は、登録済みの見込み客を購入準備の方向に動かすこと。
• 転換: ホスト型プランの無料トライアル、チームトライアルのオンボーディング、より大きなチーム向けのデザインパートナーコール。仕事は、関心の高い登録を有料のチームアカウントに変えること。
• フィードバック: DevOpsミートアップでの顧客トーク(獲得の燃料)、OSSコミュニティ内のエンジニア間の紹介(新規獲得)、サイトのGitHubスターとロゴ(コンバージョン改善)。仕事は、出力を再び入力に変えること。

フィードバックループはファネルとエンジンを分けるものだ。ホスト型プランを採用したチームが使い方について技術記事を書き、それがデベロッパーニュースレターの枠を獲得し、同じ原型の新しいチームを引き寄せる。意図的にループを閉じるときだけ、システムは積み上がる。

// 07持ち帰る6つのこと

• 01: 19のチャネルが存在する。1つか2つがビジネスを回す。広くブレインストームし、強く切る。
• 02: ICEはランク付けを強制する。掛け算のスコアリングはどの軸でもゼロを強く反映する。確信度と実行しやすさはインパクトと同じくらい重要。
• 03: Bullseyeは動きを生かし続ける。外側(可能性あり)、中間(テスト中)、内側(積み上がる中核)。チャネルは両方向に動く。
• 04: チャネル実験には、テスト前に定義された明示的な成功基準と停止基準が必要。停止基準が意思決定を強制する。
• 05: チャネルレベルのCACとペイバックが診断だ。ブレンド数値は補助金を隠す。
• 06: 機能するGTMエンジンは獲得 → 捕捉 → 信頼づくり → 転換 → フィードバックだ。フィードバックループが積み上がる効果を生む。