コミュニティの事業への効果を可視化するわかりやすい指標　コンバージョン率や解約率とは異なる定量的な測り方

「CS主導」と「マーケ主導」で作るコミュニティの違い

渡壁拓也氏（以下、渡壁）：続いての質問です。「コミュニティを立ち上げるに当たって、ファーストピンとなる方の選び方や注意すべき点はありますか？」というご質問もいただいております。

小島英揮氏（以下、小島）：今言った話ですが、まず製品の良さを理解していただいていますか？　それを真似しようとしている人ですか？　という、本当にこのスライドそのものになるんです。

渡壁：なるほど。

小島：リーダーとフォロワーの説明を簡単に書いていますが、ここを見つけられるかどうかがすごく大事です。ここが見つけられなければ、自社製品を使っている方を一度集めて、そこからリーダーやフォロワーぽい人をある種あぶり出す作業が必要かもしれません。

B2Bの企業をご支援している時にたまに感じるのが、意外とマーケティングの人がお客さんに会っていないという問題があります。お客さんを知らず、スプレッドシートのリストでしか見ていない方がいらっしゃって、それではリーダーとフォロワーを見分けるのはちょっと難しいと思います。

カスタマーサクセスがコミュニティを作ることが多いのは、そのあたりにも原因があるかもしれません。お客さんを知っているからやりやすいので。

でも、カスタマーサクセスが作ると、既存のお客さまの中からしか候補者を見つけられないので、これから使いたい人を見つけるのが難しいんですよね。なので、バランスは必要ですが、マーケティングの方もお客さまに会う作業を、おろそかにしないでやっていただくほうがいいかと思います。

サービスを提供する企業がコミュニティを作る際のポイント

渡壁：続けて、「コミュニティのメンバーは個人でもあるべきだと思いますか？　1つの企業から複数名が参加するコミュニティも存在するかと思います。その場合、熱意の高いコミュニティの運営を目指すに当たって留意すべき点があれば教えてください」ということです。

小島：すごくいい質問ですね。基本的には個人で参加していただくのが正しくて、大企業の場合はその会社からいろんな人が来ているのがたぶん自然だと思います。コミュニティ的な要素を持ちながらユーザー会的なものをやる。

AWSだと「Enterprise-JAWS」という、企業として参加するんだけど、コミュニティ的なUGCを作り出す場があるんです。あれはちょっと特殊な例で、みなさんがもしコミュニティをやるのであれば、企業内個人として参加しやすいものをやるべきではないかなと思いますね。

渡壁：ありがとうございます。「とても興味深く拝聴しておりました。製品中心のビジネスではなく、士業やコンサルタントなどのサービスを提供するビジネスを行う企業がコミュニティを作る上でのポイントはございますでしょうか？」という質問も来ています。

小島：まさにコンテキスト（文脈）ですね。サービスの内容がちょっとわかりませんが、提供しようとしているサービスの世界観や、やろうとしていることが関心軸になれば、いいコミュニティになるのではないかと思います。

製品を紹介する時は、その製品が提供する世界観がみなさんに共感されるかどうかがすごく大事な気がしますね。これは、どうなんでしょうね。サービスとは実際の製品のことでしょうか？　もし追加でコメントをいただければ、プラスしてお答えしたいと思います。

渡壁：ありがとうございます。その間に、他の質問も読み上げさせていただければと思います。「コミュニティを、クローズドなコミュニティからオープンに移行する際には、コミュニティ全体をオープンにするイメージでしょうか。感覚的にはクローズドに残すのもありなのかなと思い、ご質問させていただいております」。

小島：まず、「オープンにする」とは、入るためのハードルが低くなるという意味で言っています。なので、「オープンにする」とは全体がオープンになるということです。

一方で、このご質問は、リーダータイプの人とコミュケーションをちゃんと取っておきたいとおっしゃっていると思うんです。それはごくごく普通にみなさんがやっていらっしゃって、オープンなコミュニティとは別に、リーダーグループとの連絡網やSlackなんかをお作りになっている方がいらっしゃいます。エンゲージメントを高める上では当然そうしたほうがいいのではないかと思います。

自社製品やサービスのユーザーに限定したコミュニティの魅力

渡壁：先ほどのコンサルティングの部分のご質問に追加でご回答いただいております。アドバイスするコンサルティング……。

小島：じゃあそれが商品ですよね。ビザスクさんのサービスみたいなものですね。

渡壁：おっしゃる通りでございます。

小島：例えばビザスクさんだったら、提供しているナレッジシェア。「プロとそれを必要としている人がもっと早くマッチングされる世界があったほうがいいよね。なぜならば……」みたいなところで共感軸を作れたら、コミュニティになるのではないかと思います。

もう少し話をすると、世界観だけで世界を作ると、他のサービスを使ってもいいことになるんですよね。例えばビザスクさんだったら、同じようにマッチングサービスをしているところがあるじゃないですか。

渡壁：もちろんでございます。

小島：だからマーケット全体を広げたいなら今言ったみたいなことがいい。でも、ビザスクさんのユーザーのコミュニティを作りたいのであれば、「ビザスクを使ってこううまくいったよ」という話がされる場を作ったほうが、たぶんいいと思います。

ビジネスに直結させる時は、その製品やサービスにくっつけるというか、ユーザーの声を中心に作るのが、ポイントかなと思います。そうすると、参加する人が少なくなるのではないかと思われるかもしれませんが、ノイズが多くなるよりは自社にとっていいコミュニティになるのではないかと思います。

渡壁：私も勉強になりました。ありがとうございます。

コミュニティ運営者に必要な視点

渡壁：続きまして、「コミュニティの初期は自走までに時間もかかることから……」。

小島：めっちゃかかりますね。

渡壁：「運営側の能力も大きいと実体験として感じています。自走できるまでの期間を短くするために、コミュニティが優先して考えて実行するポイントは何か、ご教示いただけますと幸いです」というご質問をいただいています。

小島：難しいですよね。正しくやるしかない。丁寧にやるしかないかなと思います。これをやれば早くうまくできるということは、なかなかないかな。

逆に、「参加する人をちゃんと選んでいない」とか「ちゃんと参加者とエンゲージメントを作っていない」とか「参加者同士がネットワークできる場をきれいに設計できていない」と、いつまで経っても自走しません。そう簡単に自走しないので、2年から3年ぐらいかけてやるものだと思っていただくといいと思います。

一番ダメなのが、自走してほしいので「明日からリーダーの人はこれをやってください」とどんどんタスクみたいに渡してしまうこと。これは絶対ダメです。「僕もやるから一緒にやりましょう」という視点が必要です。

なので、コミュニティの対面に立つ人の人間力というか好かれる力、それから同じファン・ユーザーの視点で、このサービスや製品がいいと思う気持ちがものすごく大事です。

渡壁：ありがとうございます。1つ前のご質問に戻ってしまうんですが、「マーケットを広げるようなコミュニティでは、実際にどういったコミュニティがございますか」というご質問をいただいています。

小島：うーん、うまくいっているかどうかわからないんですけどね。「クラウドを広める」だと、昔だったら「いろんなクラウドの話をしましょう」みたいなクラウドなんとか研究会があったりするんですけど。今はもうWeb3なんとかとか、あるじゃないですか。

だけど、範囲が広すぎるコンテキストだと、リーダー層の人たちが思っていることも幅広に、つまりばらばらになってしまいがちなので、ベクトルが合いにくいんですよね。なので、あまりうまくいっていないイメージがあります。うまくいくとはベクトルがぴたっと合うことなので、自社サービスとか特定プラットフォーム上の話のほうが、実は広がりやすいかなと思います。お答えになっているかわからないですけどね。

コミュニティを分けるのは「コンテキスト」

渡壁：今の部分とも少し関わってくるのかなと思いますが、「最終的には企業の目指す姿に賛同するコミュニティを作りたいという思いはありつつも、初めは製品一つひとつのコミュニティを作ったほうがよいのでしょうか。また、こういった場合に後から統合することは可能でしょうか？」というご質問をいただいています。

小島：集めても大丈夫なのはどの粒度の人か、という話だと思うんですよね。例えば、みなさんがAmazonのクラウドサービスをどれぐらいご存じかわかりませんが、AWSの製品でいくと、中に200個ぐらいサービスがあるんですね。製品ごとにコミュニティを作ったらたぶん破綻するし、その必要はない。なぜかと言うと、組み合わせてAWSとして使うものだからです。

逆にこれは架空の話ですが、アルコールもビールも作っている飲料メーカーがあるとします。ビールも飲んでいる人も、清涼飲料水を飲んでいる人も、お茶を飲んでいる人も、みんなユーザーじゃないですか。でも、これを一緒にすると合わない気がしますよね。

ビールにはビールのコンテキストがあるし、スポーツ飲料にはスポーツ飲料のコンテキストがある。これはたぶん、製品カテゴリーごとに分けたほうがいい気がします。最後は「このメーカーのドリンクはこういうビジョンがあるよね」みたいなのはもしかしたらあるのかもしれないですけど、たぶん入り口はばらばらだと思います。

それからレストランとか宿のレビューサイトとかがありますね。仮にレストランのレビューサイトのコミュニティを作るとしましょう。レビュアー全員を集めても、みんな考えていることが違うから、たぶんうまくいかないんですよね。

おいしいランチを出張先で探したい人と、とにかく毎日コスパがいいところで飲みたい人と、ここ一番の記念日的なところでいい店を使いたい人と、コンテキストがたぶん違うんですよね。だから同じサービスでもコンテキストが違えばグループが違う。

例えば、実際にある例だと、freeeというクラウド会計のサービスがあります。あそこは例えば会計士の方向けとか、オーディエンスによって、コンテキストによって、いくつかコミュニティを分けているんですよね。だから、製品が同じだからといって1つのコミュニティでいいかどうかもまたわからないんです。

そこで、さっきのOWWHが来るんですよね。「事業をどうしたいんですか？」というObjectiveがある。そのために「誰がメインのカスタマーですか？」「誰を相手にしないといけないんですか？」。それごとにコミュニティを作るのがオッケーならそれごとに作ればいいし、束ねたほうがいいんだったら束ねることになるんだと思います。

コミュニティがもたらす事業への効果を数値化する方法

渡壁：「コミュニティがもたらす事業への効果を数値化する方法はございますか」というご質問もいただいています。

小島：これは製品によるし、計測できるかどうかにも依ります。さっきのSalesforceさんなんかはコミュニティを経由して、コミュニティに参加している企業かそうではないかで、例えばチャーンレートを比較して数値を出したりしています。

それから、ある会社はコミュニティのイベントを経由した会社がコンバージョンする率が高いかどうかを見ていたりします。ただ、そこを絶対指標にするのは難しい気がします。

先ほども言ったように、ビジネスを大きくするためには絶対にUGCの数が必要で、お客さんがどれだけユースケースを語ってくれているかが大事です。マーケティングのイベントでベンダーが話すより、絶対お客さまが事例を話したほうがいいじゃないですか。すごくいいスピーカーをコミュニティから何人輩出できたか、のほうがわかりやすい指標になると思います。

それを最終的な売りに結びつけるには、他のマーケティング策が必要です。だから、これを統合して考えるマーケティングの人がいないと難しい。逆に、統合したマーケティングの中でコミュニティをうまく使うと、非常にスケールすると思います。

だから、担当の子に「ちょっとコミュニティ運営やっておいて」と軽く渡すような仕事ではないんですよね。かなりいろんなマーケティングのファネル（見込み顧客が商品の認知から購入までの間にふるいにかけられ少数になっていくこと）に関わるものなので。

関わるならマーケティングの本部長とか部長クラスが理解していないとあまりうまくいかない。うまくいっている会社はみんなそうですね。

参加者の自発性を引き出す方法

渡壁：お時間的に、こちらが最後のご質問になるかと思います。「ユーザーさまの自発的な行動を促進するために、コミュニティがどこまで介入して、どこからユーザーさまの自発性に委ねていらっしゃるのか、コミュニティ提供側として力を入れるべきポイント、コツを教えていただけますと幸いです」というご質問をいただいています。

小島：自発を促す方法ですか。

渡壁：おっしゃる通りです。

小島：やはり、「登壇とか企画の機会をどんどんお渡しする」ですよね。自分の場にどう関わっていただくかはすごく大事なので。さっきのAWSのJAWS DAYSも、初めはAWSが場所も用意して、僕とかがおせっかいにも「こんなセッションで誰々に話してもらうといいんじゃないですか？」と、初めは型を作っていたんですよ。

やっていくと、2〜3年でユーザーの人が、「いやいや、僕らで決められるので、あんまり決めてもらわなくていい。場所ぐらいは用意してもらうのはいいけど、コンテンツは自分たちで決めるんだ」とおっしゃってくださったんですね。

それは、何回か登壇をして企画をやるうちに、「もっと自分でコントロールしたい」という思いがお客さまの中に出てきたからだと思うんです。だからやはり、登壇したり企画したり、場をたくさん作る回数が多ければ多いほど、自立に結びつく可能性があります。

逆に、みんながついてきていないのに回数だけこなしていくと、（自立から離れ）参加者として慣れてしまう。放っておいても場が作られるので、「参加するだけでいいんだ」になってしまうと、今度はぜんぜん火がつかなくなるので、このバランスが難しいですね。

巻き込みながら必要なアシストをして、イベントとかアクティビティの回数が少なくならないように気をつける。関わる人が減らないように気をつけるのがポイントかなと思います。

渡壁：ありがとうございます。それではお時間となりましたので、まだまだご質問をいただいている中、大変恐縮ではございますが、本日のご講演をここまでとさせていただければと思います。

小島：みなさんのプラスになれば幸いです。これを機にコミュニティをやってみたという人がいたら、僕のFacebookでもいいので、「こんなのをやっています」と教えていただいたり、CMC_Meetupの中でお伝えいただいたりすると幸いです。本日はどうもありがとうございました。