growth-loops

グロースループ（あなたがいなくても次の5,000人へ）

最初の50人のユーザーは、DM、知人の助け、ひとつの成功したローンチを通じて、手作業で獲得しました。それがユーザーを獲得する正しい方法であり、最初から拡大を前提としたものではありませんでした。次に取り組むのがグロースループです。あるユーザーが製品を普通に使うことで、次のユーザーにその存在が伝わり、そのユーザーが同じことを繰り返します。一度きりの紹介ではなく、継続するサイクルです。

以下の場合に使います： 投稿をやめるたびに成長が頭打ちになる、すべてのユーザーが創業者からのDMかローンチ日にたどり着く、または、すでにいるユーザーから新たなユーザーがまったく生まれていないのに、第3のチャネルを追加しようとしている場合です。

核となる考え方

チャネルは直線的です。労力をかけるとユーザーが増え、手を止めると増加も止まります。ループは出力を入力に戻します。利用によってアーティファクト、公開された痕跡、または招待が生まれ、それを見つけた新たな開発者が利用を始め、サイクルが再び動き出します。チャネルは消耗しますが、ループは複利的に成長します。

いやらしい仕組みにしないためのルール： どのループも、自分のためだけではなく、ユーザーに役立つものでなければなりません。ユーザーが誇りを持って送れるブランド入りレポートはループですが、ユーザーが嫌がるウォーターマークは、余計な手順が増えただけのスパムです。ループによって体験が損なわれるなら、それはループではなく、信頼を損なうものです。

前提条件： ループは、与えたものを何でも増幅します。第2週のリテンションに問題があれば、ループが増幅するのは成長ではなく解約です。このスキルに進む前に、1時間以内に最初の価値を得られること（time-to-first-value）、実際のユーザーを最初の50人獲得していること（first-50-users）、そしてコホートが戻ってくること（know-if-its-working、Franklの開発者純リテンション）を確認してください。どれかひとつでも満たせていないなら、まず取り組むべきなのはその問題であり、これではありません。

開発者向けツールで実際に機能するループ一覧

開発者向けツールで実際に機能する6つのループです。必要なのはひとつだけです。それを最大限に機能させましょう。

1. ショーケースループ。 製品の出力が共有可能で、あなたの名前も添えられています。CodePenのリンク、ロゴを残したままエクスポートできるレポート、ドキュメントの「Generated by X」フッターなどです。crowd.devのコミュニティ健全性レポートはブランドを表示した状態でエクスポートされ、受け取った人からレポートの作成方法を尋ねられました。その質問が登録につながったのです。
2. バッジループ。 開発者がREADMEに掲載したいと思うステータス表示です。「ビルド成功」（Travis CI、CircleCI）やカバレッジ率（Codecov）などがあります。あなたのツールを使うすべてのリポジトリを訪れる人に、さりげなく宣伝できます。バッジは品質を示すことで価値を発揮するのであって、登録をせがむものではありません。
3. ワークフローループ。 ツールが共有ワークフロー内で動作し、非ユーザーにもその働きが見えます。Snykは脆弱性の修正を含むプルリクエストを自動で作成します。すべての共同作業者がそのPRをレビューし、ツールを見つけて登録します。修正済みのイシューにボットがコメントする場合や、開発者がチームに転送する概要メールも、同じ仕組みです。
4. チームループ。 ある開発者が導入すると、ツールが共有リポジトリ、CIパイプライン、またはロックファイルに入り、共同作業者全員が触れるようになります。そして開発者が転職した際には、新しい職場の初日にインストールされます。判断のポイントは、「一緒に使う人が増えると、ツールはさらに便利になるか？」です。そうであれば、ポップアップではなくオンボーディングに招待機能を組み込みましょう。
5. パブリックコンテンツループ。 利用によって、見知らぬ人が見つけるコンテンツが生まれます。StackBlitzやPostmanのパブリックワークスペースのように、公開されて誰でも閲覧できるユーザー作成のプロジェクトやコレクション、サポートチケットの中で埋もれず検索結果に残るコミュニティの回答、そしてユーザーからの質問をきっかけに書かれるチュートリアルなどです（founder-led-contentがこのループの原動力です）。
6. マーケットプレイスループ。 開発者が普段利用している場所に公開しましょう。VS Code拡張機能、Jenkinsプラグイン、フレームワークのスターターギャラリー、GitHub独自の掲載面（トレンド、「使用中のリポジトリ」、依存リポジトリなど）があります。これで、そのプラットフォームを新たに使うユーザーが、あなたのツールを見つけられるようになります。

意思決定ツリー：ひとつのループを選ぶ

Does normal use already produce something other developers can see
(an output, a badge, a PR, a config in a shared repo)?
├─ YES → showcase, badge, or workflow loop. Instrument what is
│         already happening before you build anything new. This is
│         the cheapest loop you will ever get.
└─ NO  → is the tool more useful when a team uses it together?
         ├─ YES → team loop: put the invite where the value is,
         │        not in a growth popup.
         └─ NO  → do developers search or ask in public when this
                  problem bites?
                  ├─ YES → public-content loop: answer and publish
                  │        where it gets indexed, every time.
                  └─ NO  → your ICP may be too diffuse to loop.
                           Tighten it in `who-is-this-for` first.

トラフィックではなくループを測る

毎月、次の1つの質問をします。新規登録者のうち、既存ユーザーの行動がきっかけとなった人の割合はどれくらいですか（バッジのクリック、アーティファクトの共有、修正PR、設定のコミット、スレッドへの回答など）。

• 10%未満： あるのはチャネルであり、ループではありません。ユーザーが50人なら問題ありませんが、500人では問題になります。
• 前月比で増加し、30%に達している： ループが回り始めています。他のことを追加する前に、ループに力を注ぎましょう。
• サイクルタイムも追跡しましょう。1ターンに2週間かかるループは複利的に成長しますが、6か月かかるものは、ループを装ったチャネルです。
• ここでのアトリビューションは厳密ではなく、方向性を示すものです（Czakon）。自由記述の「どこで当社を知りましたか？」欄が、率直な測定手段になります。すべての回答に、ループかチャネルかのタグを付けましょう。

もっともらしく見える間違い

• リテンションが低いままループを構築する。 ユーザーが離れていく製品を拡散しても、離脱を早めるだけです。まずはリテンションの基準を満たす必要があります。
• 開発者に有料の紹介インセンティブを与える。 「紹介すると20ドル、紹介された人にも20ドル」は、まさにそれを嫌う対象者には賄賂のように映り、すでに得ている本物の推薦まで台無しにします。開発者が紹介するのは、そのツールのおかげで自分の評価が上がるからです。だから、それを簡単にできるようにしましょう。
• 無理に拡散させる。 削除できないバッジや透かしは削除され、反感を買い、話題にされます。価値の両立が必要です。そうでなければ何もしないことです。ループはまずユーザーの役に立ち、削除できるものでなければなりません。それでも残るものには、より大きな価値があります。
• ローンチ時の急増をループと取り違える。 ローンチはハンドルを1回回すだけです（launch-it）。見るべきなのは、ローンチで獲得したユーザーがさらにユーザーを生み出すかどうかです。グラフが元の水準に戻るなら、それはチャネルでした。
• 稼働率30%のループを3つ運用する。 重要な規模に達していない未完成のループは、何も生み出しません。漏れのある3つより、複利的に成長する1つのループが勝ります。1つ目があなたの手を離れて回るようになってから、2つ目を追加しましょう。
• B2Cの仕組みをまねる。 ウェイトリスト、招待制、連続利用記録は、開発者には「グロースハックしている」と映ります。最初のルールは変わりません。開発者に嘘をつかないこと。いずれ見抜かれます。

実例

Snykの中核となるループは、徹底的に磨かれたワークフローループです。製品の通常の役割は、脆弱性を修正するプルリクエストを開くことです。そのPRの1つをレビューするチームメイトは誰でも、自分のリポジトリで、このツールが紛れもなく役立つことを、売り込み抜きで目にします。価値を届けること自体が製品への接触につながっており、後付けの仕掛けはありません。対照的な失敗例は、コミットメッセージに「Xを試そう！」と付け加えるツールです。価値を提供せずに製品への接触だけを生み、アンインストールされます。同じ場所でも、結果は正反対です。参考にすべき問いは「どこにロゴを置けるか？」ではなく、「製品がすでに行っている仕事のうち、見知らぬ人が評価してくれそうなものはどこか？」です。

次の30分でやること

• 直近の登録者20人を、創業者の行動、ローンチ時の急増、既存ユーザーの行動に分類します。3つ目のグループを正直に数えましょう。その数が基準値です。
• カタログを見て、製品の通常の利用だけで半分は実現できているループを1つだけ選びます。新たに作るのではなく、計測できるようにしましょう。
• 製品がすでに行っている仕事のうち、見知らぬ人が評価してくれそうなものを見つけ、さりげなく、削除可能なリンクを付けます。
• 「どこで当社を知りましたか？」が自由記述になっていることを確認し（know-if-its-workingを参照）、回答にループかチャネルかのタグを付け始めます。
• 基準を確認します。2週目のリテンションが崩れているなら、このスキルは一旦保留し、time-to-first-valueに取り組みましょう。ループは待てますが、ユーザーの離脱は待ちません。

---

実際の開発者向けツールのGTM経験をもとに、Adam Frankl（The Developer-Facing Startup）とJakub Czakon（markepear.dev）のフレームワークを取り入れています。ループのカタログは、Jonathan Reimerの*［Growing Developer Tools: A Handbook］(https://reimer.me/growing-devtools)*をもとにし、ループモデルにはBrian BalfourとCasey Winters（Reforge）によるものを採用しています。 製品にどのループが合うかわからない場合や、構築したループが複利的に成長していない場合は、［LinkedIn］(https://www.linkedin.com/in/devtoolgtm/)からご連絡ください。