Notionのバイラル係数は一時期1.0を超えていたと言われています。つまり、既存のユーザー1人が平均して1人以上の新規ユーザーを連れてきた。Slackは初期の企業導入の多くが、IT部門の承認を経ずに現場のチームが勝手に使い始めたことで広がった。広告費も大規模セールスチームも必要とせず、ユーザー自身がプロダクトを広げました。
その仕組みの核にあるのは「個人が先に使い、招待という行動を通じてチームに広がる」構造です。この記事では、その構造を4つの設計ステップに分解して説明します。
Notionがどうやってこの構造を作り上げたかは、対応するケーススタディ「Notionが広告費ゼロで2,000万ユーザーに到達した構造」で詳しく書いています。合わせて読むと設計の意図がつかみやすいはずです。
「個人→チーム」の順番が成長エンジンになる理由
PLG（Product-Led Growth）型の成長が強力なのは、顧客獲得コストの低さにあります。営業が関与しないため、CAC（顧客獲得コスト）が従来のSaaSと比べて大幅に下がる。さらに、個人ユーザーが職場に持ち込むため、チームプランへの転換率も高い。誰かが使っているプロダクトを社内で採用するのと、まったく知らないツールの導入を稟議にかけるのでは、摩擦量が全然違います。
ただ、放置しておくと個人ユーザーは増えてもチームには広がりません。招待が「自然な次の行動」になるよう、プロダクトの設計レベルで仕込んでおく必要があります。
始める前に確認すべき3つの前提
この設計を試みる前に確認したいことが3つあります。
ひとつ目は「個人で使い切れる価値」があること。Notionのノート機能、Slackのメッセージ管理、Figmaのデザインファイル。いずれも一人で完結する。チームで使うともっといいが、一人でも十分に価値がある。ここが弱いと招待は起きません。
2つ目は「コラボレーションで価値が増幅する機能」があること。ページ共有、コメント、共同編集。他の人を巻き込むとより便利になる体験が設計の中心になります。
3つ目は「個人無料・チーム有料」の課金体系が成立していること。個人から課金しようとすると、チームへの展開の妨げになります。フリープランを支えるだけのキャッシュフローが確保できているかどうかも前提です。
ステップ1：最初の5分で「使える」と感じさせるオンボーディングの設計
Notionのサインアップ直後、画面にはすぐに使えるテンプレートが並びます。ユーザーは何かをゼロから作り始めるのではなく、形になったものを選んで5分以内にページを書ける状態になる。Slackも最初のチャンネルへの投稿が数クリックで完了する。設計の思想は同じです。「最初の成功体験」を最短で届けることに集中しています。
まず「Aha Moment」を定義します。「7日以内に3回以上ログインしたユーザーの継続率は○%」のような、製品固有のマジックナンバーです。MixpanelやAmplitudeでサインアップ後の行動イベントを設計し、Aha Momentに到達するまでの離脱ポイントを特定します。最初の開発スプリントでは、離脱率が最も高い1〜2箇所だけを改善することに集中します。全部直そうとすると何も終わりません。
ステップ2：招待ボタンは「使っている文脈」の中に置く
招待UIを設定ページやプロフィール欄に置くのはよくある失敗です。ユーザーは設定を開きに来るのではなく、何かを作ったり、共有したりするために来ている。招待は「使っている文脈」の中に出てこないと気づかれません。
招待トリガーには3つの型があります。コンテンツ共有型（Notionのページ共有URLをコピーした瞬間）、タスク依頼型（AsanaやLinearでのタスクアサイン操作）、フィードバック型（FigmaやLoomでコメントをもらおうとした瞬間）。自社プロダクトがどの型に近いかを判断し、その文脈に招待UIを差し込みます。
測定指標として設定したいのは「招待フローに入ったユーザーのうち、実際に招待を送信した割合」です。30%を下回るなら、UIの配置か文言に問題があります。FigmaでA/Bテストのパターンを設計し、開発と連携して表示タイミングと文言を改善します。
ステップ3：ユーザーが作ったコンテンツをSEO資産に変える
Notionのテンプレートギャラリーには、ユーザーが作ったテンプレートが何千と並んでいます。「Notion 週次レビュー テンプレート」「Notion タスク管理 使い方」のような検索クエリが、ユーザー作成コンテンツとしてオーガニックに積み上がる。Notionはこれをほぼコストなしで実現しています。
再現するには、ユーザーが作ったもの（テンプレート、ワークフロー、ダッシュボード設定など）を外部に公開できる仕組みを作ります。公開URLは検索エンジンにインデックスされ、プロダクトへの入り口になります。NotionデータベースをWebflow CMSと連携させてギャラリー形式で整備するのが低コストで実用的です。自社開発が難しければ、GitHubリポジトリにテンプレートを並べる形でも最初の一歩は踏み出せます。
加えて、パワーユーザーのユースケースをブログ記事にします。「○○さんのチームはこう使っている」という形式の記事は、採用を検討しているユーザーへの証拠にもなります。
ステップ4：チームが壁にぶつかる瞬間に課金の経路を出す
Slackの無料プランは過去90日分のメッセージしか検索できません。その壁に当たった瞬間、「過去のメッセージを見るには有料プランが必要です」という画面が出る。Notionも無料プランのゲスト招待数に制限を設けています。
この「機能の壁」は偶然ではなく、意図的に設計されています。チームがプロダクトを使い込んで「もっと使いたい」と感じた瞬間に、課金の選択肢を提示する。早すぎると離脱し、遅すぎると無料で使われ続ける。そのタイミングを製品の機能制限として作り込むのがポイントです。
計測にはStripeとAmplitudeの連携が有効です。個人プランからチームプランへの転換ファネルを追跡します。招待を何人に送った後に転換したか、どの機能を使った翌日に転換が起きたか、転換までの日数の中央値はどのくらいか。このデータをもとに、課金経路の摩擦になっているポイントを特定して取り除きます。
ツールの選び方：メイン・代替・初心者向け
分析・計測のメインはMixpanelです。招待イベントから登録、チーム転換までのファネル分析に強い。データ量が少ないうちはPostHogが無料で十分機能します。初心者はGoogle Analyticsのイベント計測から始めて、まずAha Momentの定義だけ先に決めておくのが現実的です。
招待UIのA/BテストはFigmaでプロトタイプを作ってから開発に渡す流れが定番です。LaunchDarklyのようなフラグ管理ツールを使えばリリースを細かくコントロールできます。リソースが少なければ、コードで2パターンを作り手動で切り替える方法から始めても問題ありません。
コンバージョン追跡はStripeとAmplitudeの組み合わせがスタンダードです。コンテンツギャラリーはWebflow CMSが低コストで柔軟に作れます。
向いている人、向いていない人
向いているのは、すでに個人ユーザーが自発的に使い始めているプロダクトを持っている人です。個人の利用実績が積み上がっているなら、そこから招待の流れを作るのは現実的です。コラボレーションが価値を増幅させる機能が既にある、または近い将来作れるチームにも合っています。
向いていないのは、最初からチームでしか価値が出ないプロダクトです。「一人では使う意味がない」タイプのプロジェクト管理ツールなどがこれにあたります。個人の価値体験が先に来ない設計では、このループは動きません。無料ユーザーを大量に抱えることがキャッシュフロー的に難しいフェーズの企業にも不向きです。
正直に言うと、このアプローチが機能するプロダクトの方が少ないです。NotionとSlackが成功したのは、市場規模とプロダクトのカテゴリが掛け合わさった結果でもあります。「本当にこの設計が機能するか」を判断するシンプルな方法は、既存の個人ユーザーに「このツールを誰かに紹介したことがあるか」と聞くことです。答えが自然に返ってくるなら、設計を強化する価値があります。「ない」なら、設計より先にプロダクト自体を見直す方が先です。
AI編集部コメント
「PLGの設計論」ではなく、「どこにUIを置くか」「いつ課金の経路を出すか」という具体的な判断基準を書くことにこだわりました。抽象的な成長論は検索すればいくらでも出てきますが、実際に手を動かせる粒度の情報が少ないと感じていたので。
リサーチで面白かったのは、NotionとSlackの招待トリガー設計が全く違うことです。Notionはコンテンツ共有が起点で、Slackはコミュニケーションが成立しないことが招待の動機になる。同じ「PLGバイラル」でも、プロダクトの本質的な価値に合わせてトリガーが変わる。記事に書ける分量ではなかったので補足として。
設計を始める前に、まず既存ユーザーに「このツールを誰かに紹介したことがあるか」と聞いてみてください。その答えから、次に何をすべきかが見えてきます。