本稿は、 バングラデシュ・グラミン銀行、Google 勤務を経てサンフランシスコのスタートアップスクール Tradecraft に参加した三好大助氏（@daisuke344）による取材記事の寄稿。Growth team の研究のため Uber, Slack, Dropbox はじめとする 40 社以上のインタビュー、ならびに現地スタートアップでの経験を元に本稿執筆。現在は彼は日本で創業準備中。グロースに関する相談は彼までどうぞ。

まず本稿は、シリコンバレーの方が優れているというスタンスでもなければ、すべてのスタートアップが “Growth team” をつくるべき、という趣旨でもありません。サンフランシスコ、シリコンバレーで急成長を遂げるスタートアップたちが、どのように組織をつくってきたのか。

その問いの答えを探してきた僕自身が見つけた「事実」と「方法」を、概論としてお伝えするのが目的です。

シリコンバレーで急成長中のスタートアップの多くは “Growth team” というものを持っているらしい。それでは、「Growth team とはそもそも何をする人たちなのか」「どう組織すればいいのか」「何から始めればいいのか」。

本稿は、これらの一見初歩的ながら一筋縄ではいかない問いかけに、出来る限り一般化して回答することに挑戦します。Growth team 未経験の方々に対しては、まず Growth team を組織していく大まかなイメージを掴んで頂きつつ、具体的なアクションも把握できる「入門編」のような位置づけになることを願って。

既に Growth team を運営されている方々にとっては、シリコンバレーの事例に触れてヒントを得られる「補助線」となることを願いながら。紙面の許す限り心を込めて書いてみます。

本記事の内容：

• 1. 急成長スタートアップがこぞって配置する “Growth team” とは何か？
• 2. Growth team 3つのモデル
• 3. Growth team のつくり方: PMF & Hustle 編
• 4. Growth team のつくり方: Scale 編
• 5. アクションリスト

1. 急成長スタートアップがこぞって配置する “Growth team” とは何か？（≠ Growth Hack）

LinkedIn でぜひ “Growth” と肩書検索してみてください。そのまま文字通り “Growth” やら、“Growth Engineer”、 ”Growth Marketing”、”VP, Growth” 等たくさんの役職が出てきます。シリコンバレーの有名どころのスタートアップであれば大抵抱えているこの “Growth” と名のつくポジションと “Growth team”。結局のところ、彼らは一体何をしているのでしょうか？

肩書から察するに、近年日本でも広まってきた “Growth Hack” という手法だけを行っている人たちではなさそうです。しかし正直なところ、非常に曖昧な印象が否めませんよね。「どうせまた新しく出てきたバズワードなのでは？」「既存の組織と較べてぶっちゃけ何が違うの？」これが、Tradecraft の門を叩いた初日に僕が抱えていた率直な疑問でした。

今本稿をご覧のあなたも同様の問いを持っているかもしれません。そして、この問いに対する答えは半分イエスです。やはり「流行り」であることは否めません。

しかし、シリコンバレーを代表する 40 社以上のグロース専門家たちのインタビューや講義を経て分かったのは、その「流行」っている背景にこそ本質的な問いかけがあり、その「問いかけ」は、十分注視に値するテーマだということです。

Tradecraft の Growth 論を指導する Graham Hunter は言います。

まず、Growth team とは必ずしも Growth Hack を行う集団のことではない。より大きな問題意識に基づいた組織論なんだ。既存の機能別縦割りの組織体系では、スタートアップの成長指標を伸ばすのに決して最適な形とは呼べない。これが解くべき問いだ。

この Graham の言葉から紐解くに、Growth team とは「成長指標を最大化させるために最適化された組織体系」と定義できそうです。では、この Growth team が解こうとしている「問い」をもう少し深くみていきましょう。こちらの図は、大企業によくある機能別にMECEな組織形態を示しています。

しかし、このように機能別に組織を構成することが、必ずしも成長指標にとって最適とは限りません。例えばあるEコマースのスタートアップが Dave McClure の提唱する AARRR のフレームワークをそのまま用いて指標を置き、プロダクトの成長を定義していたとします。 （なお、AARRR をそのまま用いることは少ないですが、多くのスタートアップが AARRR をベースに自分たちなりのユーザーファネルを定義して指標化していることが多いです）

この際、通常の Marketing team であれば “Acquisition” のみを担当したり、Product team はやんわりと全ファネルに関わっていたりと、どこかに偏りやモレ、手薄になってしまう箇所が現れてしまいます。先ほどの図で例えると、このようにカバーし切れていない溝が空いてしまっているイメージです。

通常の大企業であればこれでいいかもしれませんが、急成長を至上命題とするスタートアップにとっては、この形態は必ずしもベストではありません。否、命取りになることもあるでしょう。
この溝を埋めていくために、どう組織を変えていくのか。この問いに対する一つの解として “Growth team” という概念が存在しています。

2. Growth team 3 つのモデル

では、具体的にどのようにこの溝を埋めていけばいいのでしょうか。40社以上のインタビューを通じて見えた、Growth team の 3 つのモデルをご紹介したいと思います。

A. Functional モデル

このモデルに当てはまる代表的な企業は、Dropbox, Twitter, LinkedIn です。彼らは気づきました。

「機能別の組織形態のままでは、成長指標をうまく伸ばしきれない！」

では、この溝を埋めるために Product team が動こう。

こうして生まれたのが最初のモデルである Functional モデル。 Growth team の誕生です。Functional モデルにおいては既存の組織ストラクチャーの中に “Growth Product Manager (Growth PM)” や “Growth Engineer” と呼ばれる役職を新設し、彼らに成長指標のカバーし切れていない部分を積極的に担わせました。

多くの組織は上図のようにプロダクト機能ごとに Growth PM を設置し、これらの機能改善を通じて成長指標への貢献を目指します。

そしてこのモデルにおける PM やエンジニアによる活動を、Dropbox の PM であった Sean Ellis が “Growth Hack” と名付け概念化したことにより、Growth team の存在が爆発的に広がります。

B. Independent モデル

2つ目のモデルは Growth team を専任のチームとして独立させて、溝を埋めに行った形です。Functional モデルを眺めていた人たちは思いました。

「いやいや、もういっそのことしっかり責任者も立てて組織としてコミットしよう。直で CEO にレポーティングもさせよう。」

こうして “VP, Growth” という人物が誕生します。そしてその下に Growth PM 並びに専任の Growth Engineer たちを置く流れが生まれました。

C. Independent モデル（Cross-Functional ver.）

最後の 3 つ目は Independent モデルの発展形です。

「というかそもそも Marketing team だったり他の部署も成長指標に関与してるんだから、みんな巻き込んで統合しようよ」

そんな気づきから、Uber や Facebook が取り入れ、今流行りを見せているモデルと言えます。

このように、VP, Growth の下に Growth PM や Growth Engineer のみならず、マーケティングやデザイナーをも組み込んで、機能横断的 (Cross-functional) な Growth team を構築するところが増えてきました。

この図の通り、User funnel の指標ごとにエンジニアやマーケティングが協業するグループをつくってマネジメントする会社もあれば、実作業としては別々に動くものの、同一の User funnel の指標に対してレポーティングさせているケースもあります。（なお、Uber や Facebook の場合は規模が大きく Growth team 内でさらに細かく分かれているので、この図の通りではありません）

また、元 Lyft の Growth 責任者である Adam Fishman がジョインした WyzAnt では、マーティング副社長のポジション並びにレポートラインを廃止し、新設した Growth 部署内にマーケティングメンバーを完全に集約、エンジニアと共同で成長指標を追わせています。

このように最近のスタートアップでは、そもそもマーケティング部署をおかず独立した Growth 部署内にマーケティング人材を集約させ、エンジニアと協業させている会社も増えてきている印象です。

以上 3 つのモデルの他にも、Marketing team 主導で成長指標をカバーしていく Udemy に代表されるモデルもあったりします。各々のビジネスモデルに合わせた適切な Growth team のモデルを、いまだ多くのスタートアップが模索しているのが現状のように見えます。

3. Growth team のつくり方 : PMF & Hustle フェーズ編

ここまで大きく 3 つの Growth team のモデルを紹介してきました。そしてここまでお読みいただいたところで、次のような疑問を持った方もいらっしゃるのではないでしょうか。

「そもそも、この Growth team がつくれるのはある程度の規模のスタートアップではないのか」

この疑問に対して僕も同じ立場をとります。初期のスタートアップの多くは Growth 云々を語るより前に、ユーザーが欲するものをつくることに必死でしょう。もっと言うとそうしたステージのスタートアップにとって Growth team は必要ないのかもしれません。

では、どの時期からどのように Growth team の概念を導入していけばいいのでしょうか。

この章では 3 つのモデルから一旦離れて、Growth team の概念に時間軸を取り入れて整理してみます。Creative Market の Growth を統括する Zack Onisco 提唱の「スタートアップ 3 つのステージ」がシンプルで分かりやすいので、彼の定義による各ステージごとの、Growth team に対する考え方を俯瞰して見てみましょう。

まず 1 つ目のステージが Product / Market Fit (PMF) のステージ。このステージのゴールは「ユーザーが欲しいモノをつくること」。そもそもユーザーが必要としているものをつくれていないままグロース施策を打っても、それは穴の空いたバケツに水を注ぐようなもの。

ユーザーの課題と解決策はマッチしているか。その解決策を形にしたプロダクトは十分なマーケットを捕らえる見込みがあるか。こうした問いに答えられるようになる（＝PMF を達成する）までは Growth team はつくらない。それがこのステージのスタートアップへのメッセージになります。

もちろんお察しの通り 「じゃあ PMF の具体的な定義って何なんだよ」という議論は今も大いに花咲いています。Sean Ellis の「”このプロダクトがなくなったらがっかりする” 人が40%以上」という定義に始まって諸説あるのが現状です。

本稿では文量の都合上深くは突っ込みませんが、私見として無理やり一般化すると、シリーズ A の資金調達前であれば Growth team について議論する必要のない場合が多数でしょう。

次の 2 つ目のステージが Hustle ステージです。 このステージに入って初めて Growth team の雛形を描いていくことになります。このステージのゴールは、「確固たる 1 つの Acquisition （ユーザー獲得）チャネルを特定すること」。Zack は次のように語ります。

「初期のスタートアップでは、 1 つの Acquisition チャネルが全体のユーザー獲得の 8 割以上を占めることが多い。例えば Creative Market では初期のユーザーの 9 割が SEO 施策経由だった。Retention, Activation をクリアした上で、どれだけ早く、効率的に、この初期の Acquisition チャネルを探し当て Hustle ステージを抜けられるかがスタートアップ成功の成否を分ける。」

もちろん全てのスタートアップがこの形を取ることはあり得ませんが、一般的にはこのように前述 AARRR のフレームワークで言う Retention → Activation → Acquisition の順に成長指標を改善し、最終的に 1 つの確かな Acquisition チャネル発掘に移っていく流れが多い印象です。

このステージで想定される全社員数は 10 ~ 30 人程度。会社全体がいわば Growth team として一丸となり、成長指標改善のための施策を回していくイメージです。では、このステージではどのように Growth team の雛形をつくっていくのでしょうか。主なアクションとしては 2 点です。

• 1. Growth team 責任者 (≒Growth PM) を置く (初期においては大抵 CEO が兼務)
• 2. チームに合った Growth Process を確立させる

1. の Growth team 責任者の役割は、2. の Growth Process のマネジメントを行うこと。では、Growth Process とは何か。Growth Process とは、どのようなサイクルでもって Growth 施策を仮説検証していくのかというプロセスの話になります。

そしてここも一般化の難しいポイントなのですが、この Growth Process には Bullseye Framework (日本語解説書籍), Brian Balfour model, Sean Ellis model 等、幾つかのメジャーな流派が存在しています。これらの流派の型を参考にしつつ、自分のプロダクトに合った方法論を確立していくことが、このステージの肝になります。

本当は全てのモデルに関して解説を添えたいところなのですが、文量の都合上なかなか困難なので、詳細は上記リンクに譲らせてください。ここでは簡単にそれぞれの型に触れるに留めます。
Sean Ellis model はこの中で恐らく一番分かりやすいプロセスです。

エンジニア主導の Growth team に適していて、上記リンクをご覧いただければ英語でもかなりイメージが掴めるかと思います。Brian Balfour model は、Sean Ellis model をより細かなプロセスまで踏み込んだモデルです。Backlog（検証アイデア集）や Playbook（成功アイデアを汎用化）の管理の仕方が参考になります。

そして Bullseye Framework は、Acquisition チャネル 発掘に特化したプロセスです。この型が参考になる一番のポイントは、Acquisition チャネルの候補は 19 種類に絞られると言い切っており、いかに効率的に 1/19 を掘り当てるかにフォーカスしている点です。

僕が働いてきたスタートアップでは、上記 3 つを参考にしながら自社に合ったプロセスを作り、Trello 及び Google スプレッドシートで仮説検証の管理を行ってきました。

Acquisition 指標が上がる仮説をデータから立て、その仮説を立証するために必要な N 数から必要日数や工数を求め、検証してうまく行けばそのデータを元に次の仮説へ繋げる。これを早い時では 1 ~ 2 日のペースでがしがし回すイメージです。そしてその中で Growth Process 自体も検証、最適化していきます。

このようにプロダクトに合った Growth Process を確立し、Retention, Activation の改善、そして 1 本の Acquisition チャネル発掘に成功したら、いよいよ本格的な Growth team 組織化の議論に移ることになります。

4. Growth team のつくり方: Scale フェーズ編

最後の Scale フェーズのゴールは「組織化」です。いよいよ 3 つの Growth team モデルの議論に戻ってきます。ある程度の Retention 率が担保され、Acquisition チャネルも特定できたタイミングで、組織のモデルを構想して採用を進めていきます。

では、どの Growth team モデルを選択するのがベストなのでしょうか。もちろん普遍的にベストなモデルがあるわけでなく、それぞれのモデルにメリット・デメリットが存在しています。

この章では現在シリコンバレーでもホットトピックの一つとなっている「Growth team モデルの選択」に関して、Functional モデル (A) 対 Independent モデル (B&C) の比較で整理していきたいと思います。

Independent モデル (B&C)

まずは Independent モデル から。このモデルは Facebook や Uber が取り入れたこともあって近年人気を博し、多くのスタートアップが VP Growth 及び独立した Growth 組織を導入し始めました。

「このモデルの良い点は、組織全体として成長指標にコミットする姿勢をつくれることです。各成長指標に対する責任の所在が明確となり、Functional モデルより速い成長が可能です」

と、元 Evernote Growth Head の Naomi Ionita は述べます。一方で Pinterest の Lead Product Manager である Casey Winters は、この Independent モデルに次のように警鐘を鳴らします。

「このモデルは往々にして Product team との不和を招く。Pinterest も当初は Independent モデルを採用していた。そして実際にものすごいスピードで成長を実現できた。例えばこのモデル移行後、サインナップフローを集中的に改善した結果、Acquisition と Activation の指標を大幅に増やすことができた。しかし Product team からユーザーエクスペリエンスを犠牲にしすぎていると声が上がり、結局 Functional モデルに戻したんだ。」

ではこのような Growth team と Product team 間の信頼関係を維持するにはどうしたらいいのでしょうか。この点に関して Naomi は彼女自身の経験を次のように述べます。

「Growth 施策が Product team の活動に影響を与えてしまうのは不可避です。しかしその一方で Growth team と Product team の棲み分けを出来る限り明確にし、Growth Head と Product Head が綿密にコミュニケーションを取り合うことで、この不和を限りなくゼロに近づけることも十分に可能です。結局のところ、この問題の原因は Independent モデルそのものにあるのではなく、人間関係のマネジメント能力に依るところが大きいのです。」

現に、Independent モデルの代表例とされる Facebook と Uber の Growth 組織は、共に Ed Baker という卓越したマネジメント能力で有名な VP が組織しています。では具体的にそのマネジメントとはどういったアクションになるのでしょうか。Naomi は、以下のようなアクションを推奨しています。

• Product team との線引、責任所在を明確にすること
• 各 Growth 施策ごとの UX リスク洗い出しを行う習慣をつくること
• Growth meeting への Product Head 参加を必須にすること

成長指標を大きく引き上げる一方で UX への影響が懸念される Independent モデル。僕自身この Independent モデルの組織で働いてみて感じたのは、規模が小さいときには特に問題なく機能するということ。しかし、40 人、50 人と大所帯になるにつれ、Naomi の推奨するように、チーム間のコミュニケーションを仕組みとして整備する必要があるように思います。

Functional モデル (A)

では Functional モデルの場合はどうでしょう。BitTorrent の Product Head である Pramod Sokke は、このモデルの利点を Product Head が Growth 施策とのバランスを取れる点にあると述べます。

「BitTorrent の場合は、私が Growth 指標も見る体制になっています。そのため、Growth 指標達成のためのプロダクトロードマップと non-Growth 指標のためのロードマップの二種類を作成し管理しています。これによって長期的な事業成長の視点で製品のクオリティを管理できるのです。」

当然といえば当然ですが、このように Independent モデルの抱えるリスクをかなり抑えることができそうです。では、すべての Growth team がこの Functional モデルにすべきほど万能なのでしょうか。

まず懸念としては、Product Head への負荷が挙げられます。少なくとも BitTorrent の規模で 2 つの製品ロードマップ管理は口で言うほど簡単な仕事ではないでしょう。また当然ながら、Independent モデルほどリソースを成長指標にコミットさせていないため、相対的に成長速度は下がる傾向にあることを Pramod も認めています。

スタートアップの状況によっては Independent モデルを選択し、成長指標にフォーカスした方が良いケースもあるでしょう。

しかし、一番肝心な点は、この Functional モデルであったとしても組織内の軋轢が生じうる、というやはりマネジメント上の問題です。こうした問題を避けるため、Functional モデルの代表企業である Twitter, LinkedIn, Dropbox 等でも、Growth 施策の UX 影響度を分析する責任者を置いています。

”Growth Hack” の生みの親で元 Dropbox Growth Head の Sean Ellis は次のように述べます。

「Growth team の成否を分けるのは、仮説検証プロセスそのものだけではなくコミュニケーションに依るところも大きいのかもしれない。私の今の会社は Functional モデルだが、それでも各施策のユーザー体験へのリスクを検討し、実装後も徹底して影響度を測っている。そしてそのデータを全員にシェアし、透明性を確立するよう努めている。Growth meeting で各部門の Head を参加させているのもこの透明性確立のためだ。」

Sean の述べるように、Functional モデルであったとしてもこうした地道なコミュニケーションの積み重ねが、組織内の透明性を高め、Growth とユーザー体験のバランス維持につながるのでしょう。

ここまでの Functional モデルと Independent モデルの比較、並びに他 2 つのステージを整理すると上図のようになります。ご理解いただけた通り、Functional モデルと Independent モデルのどちらがいい、という話ではなく、それぞれのモデルを足がかりとして自社に最適な組織体系をデザインしていく、そのプロセス自体がこの Scale ステージの肝だと考えています。

最後に

ここまでお付き合いいただきありがとうございました。最後に「では結局何をすればいいの？」にお答えするため、Growth team をつくるにあたってのチェックリストを作成しました。参考になれば幸いです。

1. そもそも本当に Growth team は必要か？

• Growth team を持たないスタートアップもたくさん存在する
• そもそも本当に Growth team が必要なのか？短期的な成長を求める明確な理由はあるか

2. 始める準備はできているか？

• プロダクトの成長を定義できているか
• 成長に寄与する因数を User Funnel の形に整理し指標化できているか (例: “AARRR”)
• Product Market Fit がつかめているか

3. Hustle ステージのアクション

• Growth team 責任者 (≒Growth PM) を置く (初期においては大抵 CEO が兼務)
• チームに合った Growth Process を確立させる

4. Scale ステージのアクション

• 自分の組織に合った Growth team モデルを選択、構築する（例: 急速な成長を追い求めるのであれば Independent モデル、UX とのバランスを取るのであれば Functional モデル）
• どのモデルを選択するにせよ、組織内の透明性を高めることが成否を分ける
• それぞれのモデルを起点として、自社にとって最適な組織体系をデザインしていく

以上、「Growth team とはそもそも何をする人たちなのか」「どう組織すればいいのか」「何から始めればいいのか」という一般化の難しい問いかけに対して、出来る限り多くの方にご理解いただける回答となるよう努めました。文量の都合上どうしても具体論の足りない箇所があったり、僕より豊かな経験をお持ちの方の中には、ご自身のご意見と反する箇所もあったかと思います。

そうした議論のたたき台に本稿がなれば嬉しい限りですし、そうした議論の一助となることで、日本のスタートアップシーンに微力ながら貢献できれば幸いです。ご意見ご感想等あれば @daisuke344 までお寄せください。長いお時間本稿にお付き合いいただき、本当にありがとうございました。