「遠くへ行きたければ、みんなで行け」を読んだ¶
読んだ本¶
「遠くへ行きたければ、みんなで行け 〜「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則」を読んだ。
原題は People Powered: How Communities Can Supercharge Your Business, Brand, and Teams 。
著者は Jono Bacon。Ubuntu、XPRIZE、GitHubなどのコミュニティに関わってきた人物で、コミュニティ戦略やマネジメントを専門にしている。
※アフィリエイトリンクですどんな本か¶
この本は、ベーコンメソッドと呼ばれるコミュニティ設計のフレームワークについて、その要素をそれぞれ説明したものである。
コミュニティを「人が自然に集まる場」として眺めるだけではなく、設計し、運営し、継続させる対象として扱っている。
扱っている範囲は広い。オープンソースコミュニティの話も出てくるが、それだけではない。企業のプロダクト、ブランド、チームに対して、コミュニティの力をどう組み込むかが中心にある。
本の軸は、コミュニティを作るときに必要になる要素を分解することにあると思う。たとえば、何のために集まるのか、誰が参加するのか、参加者はどんな行動を取れるのか、貢献をどう見えるようにするのか、といった話が出てくる。
個人的には、コミュニティを気合いや善意だけで回すものとしてではなく、プロダクトに近いものとして扱っている点が印象に残った。
目次を見ると、ミッション・ステートメント、エンゲージメント・モデル、バリュー・ステートメント、ペルソナ、オンボーディング、ロードマップ、インセンティブ、ゲーミフィケーション、イベント戦略などが扱われている。単に「人を集める方法」ではなく、人がそこに居続ける理由をどう作るか、参加者が自分の役割をどう見つけるか、運営側がそれをどう支えるか、という話が多い。
読みながら、自分がイベント運営で考えていたことよりも、ひとつ手前の設計が多いと感じた。イベントのテーマ、登壇者、告知文、当日の進行を考える前に、そもそもこの場は何のためにあるのかを決める。その土台がないままイベントだけを作ると、毎回の判断が場当たり的になる。
10のカルチャーコア¶
本の第7章には「10のカルチャーコアを理解する」という項目がある。コミュニティの文化を、雰囲気やノリとして片付けず、設計できる要素として扱う話だと受け取った。
細かい項目をそのまま並べるというより、自分の理解では、次のような問いに分解できる。
オープンであろう (Be open)
実務的であろう (Be pragmatic)
個人的にであろう (Be personal)
ポジティブであろう (Be positive)
協調的であろう (Be collaborative)
リーダーであろう (Be a leader)
ロールモデルになろう (Be a role model)
親身になろう (Be empatheic)
地に足のついた人であれ (Be down-to-earth)
不完全であれ (Be imperfect)
こうして見ると、カルチャーは自然発生するものというより、日々の判断の積み重ねに近い。何を歓迎するか、何を拾うか、何に反応するかで、少しずつ場の性格ができていく。
たとえば「初心者歓迎」と書くだけでは足りない。初めて来た人にどんな説明をするのか、質問しやすい時間を作るのか、経験者だけが盛り上がる話題に寄りすぎていないか。そういう細かい判断が、実際の文化になる。
この考え方は、かなり耳が痛かった。自分たちが何を歓迎し、何を大事にする場なのかを、あまり言葉にできていなかったからだ。
ベーコンメソッド¶
もうひとつ、本の第1章で紹介される枠組みに「ベーコン・メソッド」がある。
目次を追うと、このメソッドはその後の章で、ミッション、エンゲージメント・モデル、価値の提示、ペルソナ、オンボーディング、ロードマップ、成果の測定、文化、成長戦略、インセンティブ、イベント戦略などへ展開されている。
自分の理解では、これはコミュニティを「いい感じに盛り上げる」ための精神論ではなく、設計して、実行して、測り、改善していくための進め方だ。コミュニティを作るときに、目的、対象者、参加の流れ、貢献の形、成果の測り方を順番に考えていく。
ここもプロダクト作りに近い。誰に向けたものなのかを決め、最初の体験を用意し、継続する理由を作り、うまくいっているかを見直す。イベントを開催するだけなら、当日の内容を作れば一応形になる。けれど、コミュニティとして続けるなら、その前後まで設計しないといけない。
公式目次で確認できる項目を、自分たちの活動に置き換えるなら、たぶん次のような順番になる。
大義(Mission)と価値(Value)を作る
自分のコミュニティでのエンゲージメント・モデルを選ぶ
君自身が提供したい価値をきちんと言葉にする
ビッグロックス、確固たる塊をつくろう
オーディエンスを知り、理想のオーディエンス・ペルソナを構築しよう
導入路とエンゲージメント・モデルを設計する
四半期実施計画を建てる
成熟した状態や成功を測る指標を創造する
ケイデンス(律動)を実施する。何度も繰り返して組織に筋肉を作っていく
自分のインセンティブマップを作成する
この順番で考えると、イベントの企画だけを見ていても足りないことがわかる。告知を出して、人が来て、当日が終わる。そこで止まると、毎回単発のイベントになる。
本が言っているのは、そこから先をどう作るかだと思う。参加した人が次に何をするのか。運営側は何を見て改善するのか。コアメンバーは何を判断軸にして動くのか。そのあたりを決めておくことで、コミュニティは偶然ではなく、少しずつ育てる対象になる。
コミュニティを作る前に決めること¶
本の中で繰り返し出てくるのは、コミュニティには目的と設計が必要だという話だ。
「人が集まれば何かが起きる」ではなく、どんな人に来てほしいのか、その人たちは何を得られるのか、どんな行動を取れるのかを考える。これは、イベントを開くときにも、その後に継続的な場を作るときにも必要になる。
特に重要なのは、ミッションやビジョンを明確にすることだと思った。運営側がなんとなく同じ方向を見ているつもりでも、言葉にしていないと少しずつズレる。参加者から見ても、何の場なのかわからない場所には入りにくい。
自分がコミュニティを立ち上げようとしたときも、この部分は弱かった。初回のイベントはできても、その後に何を続けるのか、参加者にどんな関わり方をしてもらうのかが曖昧だった。
ミッションが曖昧だと、イベントの内容を決めるときの判断軸も曖昧になる。この企画はやるべきなのか、この内容でいいのか、誰に向けた場なのか。そういう判断をするたびに、何を基準にしているのかがはっきりしなかった。
たとえば、登壇テーマを決めるときでも、初心者向けにするのか、運営メンバーが面白いと思うものを優先するのか、地域の人が参加しやすいことを優先するのかで判断は変わる。どれも間違いではない。ただ、どれを優先する場なのかが決まっていないと、判断のたびに迷う。
これは告知文にも出る。誰に来てほしいイベントなのかが曖昧だと、文章も曖昧になる。結果として、参加者から見ても「自分が行っていい場なのか」「何を得られる場なのか」が見えにくくなる。
この本でミッションの話を読んで、自分が引っかかっていたのはここだったのだと思った。ミッションはかっこいい言葉を掲げるためのものではなく、日々の判断を揃えるためのものだった。
参加の段階を用意する¶
もうひとつ参考になったのは、参加の段階を用意するという考え方だ。
コミュニティには、見るだけの人、イベントに参加する人、発信する人、運営を手伝う人、中心メンバーになる人がいる。全員にいきなり濃い関わり方を求めても無理がある。
だから、少しずつ関わりを深められる道筋が必要になる。
イベントに参加する
SNSで感想を書く
ハッシュタグで投稿する
LTをする
運営を手伝う
次の企画を一緒に作る
こうした段階が見えていると、参加者は次に何をすればいいかがわかる。運営側も、誰がどの段階にいるのかを見やすくなる。
自分たちのコミュニティに置き換えると、まずはハッシュタグ付きの投稿に反応する、感想を拾う、次回の登壇やLTにつなげる、といった小さい導線から始められそうだと思った。
本を読んでいて、参加者に「もっと関わってほしい」と思うなら、関わり方を用意するのは運営側の仕事だと感じた。
ただ参加してください、では次につながりにくい。参加したあとに感想を書く、次回のテーマに投票する、懇親会で話す、短いLTをする、運営の一部を手伝う。こういう小さい段階があると、参加者は自分の温度感に合わせて関われる。
逆に、参加と運営の間が急に遠いと、関わりたい人がいても入ってきにくい。いきなり中心メンバーになるのは重い。けれど、受付を少し手伝う、SNSで告知を広げる、次回のテーマ案を出すくらいならできる人はいるかもしれない。
この段階を作ることも、カルチャーを作ることの一部だと思う。
貢献を見えるようにする¶
コミュニティでは、参加者の貢献を見えるようにすることも大事だと書かれている。
貢献といっても、大きな役割だけではない。イベントに来る、感想を書く、質問する、知り合いを誘う、資料を共有する。こういう行動もコミュニティを支えている。
ただ、見えない貢献は本人にも周囲にも伝わりにくい。運営側がリアクションする、紹介する、次の機会につなげることで、参加者は「自分もこの場に関わっている」と感じやすくなる。
このあたりは、イベント運営をしているとかなり実感がある。投稿にいいねをするだけでも、何も反応しないよりはずっと良い。小さいが、継続すると場の温度が変わる。
貢献の可視化は、報酬を用意するという話だけではない。むしろ「見ています」「助かっています」「次につながっています」と伝えることに近い。
イベント後に感想を書いてくれた人がいれば拾う。質問してくれた人がいれば、次の企画のヒントにする。登壇してくれた人には、資料や話の内容を改めて紹介する。こういう反応があると、参加者の行動がコミュニティの中で意味を持つ。
何もしないと、貢献は流れていく。感想も、質問も、紹介も、一度きりの出来事になる。そこに運営が反応すると、参加者の行動が場の一部になる。
期待と少し違ったところ¶
読む前は、もう少し市民コミュニティや地域コミュニティ寄りの本だと思っていた。日本語版にはCode for Japan代表理事の関治之さんによる解説があり、コミュニティそのものを主語にした内容を想像していた。
実際には、企業、ブランド、プロダクト、チームを強くするためにコミュニティをどう活かすか、という色もかなり強い。
この点は期待と少し違った。ただ、逆に言えば、コミュニティを継続可能な仕組みとして見るには参考になる。熱量だけで続けるのではなく、目的、参加者、導線、貢献の可視化を設計する。その考え方は、地域や技術コミュニティにも応用できる。
特に、コミュニティを「善意でなんとかするもの」として扱わないところは参考になった。善意は大事だが、善意だけに頼ると、動ける人に負荷が寄る。誰かの熱量が落ちた瞬間に止まる。
本の方向性はビジネス寄りでも、そこから学べることはある。続けるためには、目的、役割、参加の段階、反応の仕方を決める必要がある。これは企業コミュニティでも、地域コミュニティでも、技術コミュニティでも同じだと思う。
読んで考えたこと¶
最近、コミュニティの立ち上げに挑戦したが、うまくいかなかった。
初回のイベントはできた。ただ、その後の継続参加や、運営側のモチベーション維持が難しかった。今思うと、イベントを開くことと、コミュニティを育てることを分けて考えられていなかった。
イベントは一度作れば開催できる。コミュニティは、次に来る理由や、関わり続ける理由を作らないと続かない。
もうひとつ難しかったのは、不安を共有できているのかどうかも曖昧だったことだ。
動きが下火になったときに、こちらから動くべきなのか、それとも自然に任せても大丈夫なのか。その判断ができなかった。もしかすると、ただ自分が不安に思っていただけかもしれない。けれど、その不安を運営メンバーと同じ言葉で扱えていなかったので、危ない状態なのか、見守ってよい状態なのかもわからなかった。
この本を読んで、まず見直したいと思ったのは次の2つだった。
何のためのコミュニティなのかを短い言葉で説明できるようにする
その言葉を作る過程で、運営メンバーそれぞれの意見を出す
ミッションは、最初からきれいな文章にできなくてもいいと思う。むしろ文章にする道程で、それぞれが何を大事にしているのかを出すことが肝だと思った。
そのうえで、参加者が次に取れる行動を用意する。
大きい仕組みをいきなり作るより、まずはここからでよさそうだ。
今なら、最初にやるべきことはイベントを増やすことではなく、運営側で話すことだと思う。
何のために自分たちは動くのか。どんな人に来てほしいのか。参加した人に、帰るとき何を持っていてほしいのか。動きが下火になったとき、何を見て判断するのか。
このあたりを話しておかないと、イベントの数を増やしても同じところで迷いそうだ。逆に、ここが揃っていれば、多少うまくいかないイベントがあっても、次にどう直すかを話しやすくなる。
まとめ¶
「遠くへ行きたければ、みんなで行け」は、コミュニティ運営を感覚ではなく設計の対象として扱う本だった。
オープンソースや企業コミュニティの話を入口にしながら、目的の定義、参加の段階、貢献の可視化といった実務的な話が多い。コミュニティ運営を始めたい人だけでなく、イベントを継続的な場につなげたい人にも参考になる。
個人的には、コミュニティを「イベントの延長」ではなく「人が関わり続ける仕組み」として考え直すきっかけになった。