コミュニティマネジメントの技術
「コミュニティの事業をやってる会社なんだから経営もコミュニティマネジメントでいきたい」。なるほど、わかる。しかし、コミュニティマネジメントについてどこにもまとまってないのだが？
今ここで解決しよう。そうしよう。
文化のデザインとマネジメント
最初に、トップダウン的なマネジメントが問題解決の役に立たないような場合の話をする。
以前、企業文化について書いた。
企業文化とは明確な指示、目的、ルールがないときに社員がとるデフォルトの行動である。
もう少し具体的に言うと、短期的な優先度が5番目のトピックに対するメンバーの行動がそのチームの文化である。全ての行動の優先度が高いとは限らない。というより会社におけるメンバーの行動のほとんどはそれほど優先度が高くない。例えば
朝にあいさつをする
これを個人の目標設定にする会社はほとんどない（と思う）。一方でこれができない会社は長く存続する感じがしない。こういう会話がなされることが容易に想像できる。
上司「なぜあいさつしないんだ！ちゃんとあいさつしろ！」
これに対して
部下「ちゃんと売上あげてるんだからいいじゃないですか。あいさつと売上どっちが大事なんですか？売上下がってもいいならやりますけど」
こう言われると苦しい
上司「・・・そういう問題じゃない！あいさつするのは当たり前だろ！」
ロジカルではなくなってきた
部下「じゃあやりますけど売上下がっても文句言わないでくださいね」
これに対する結末も容易に想像できる。おそらく、部下は挨拶をしない、売上目標は達成する、そして遠くないうちに離職する。
最も重要で本質的な1〜3個の問題を解決する方法については多くのノウハウが共有されている。
では、短期的な優先度が5〜7番目くらいだが占める時間が多いという問題についてはどう扱うべきか。
コミュニティマネジメントはこれに対する解答になりうる。
コミュニティ型のアーキテクチャ
コミュニティとそうでないものについて定義する。まず、コミュニケーションには出し手と受け手がある。あるいは逆に、出し手と受け手が存在するできごとをコミュニケーションという。
サービスはこのどちら側を軸にするかでアーキテクチャが分かれる。
メディア型：受ける側を軸にする
コミュニティ型：出す側を軸にする
適当なサービスを10個くらい思い浮かべて欲しい。すべてのサービスに出す側と受ける側の両側があると思うが、どのサービスもどちらか一方を物凄く不便にしても成り立つはずだ。
例えば、映画を配信するサービスならば映画をつくるのも登録するのも放映するのも全部手作業でも問題ない。配信する側は苦労する一方で、視聴者はできるだけ苦労をなくし満足度を高めるようにする。
一方でSNSやC2Cと呼ばれるサービスを思い浮かべてみよう。そのサービスは発信側のハードルを下げ、さらに他者が誰も見ていなかったとしても楽しめるように作られているはずだ。
例えば、ユーザー同士がものを売買するサービスは2種類に大別できる
良いものを買うことがサービス
いらないものを出品できるサービス
前者は買う側を軸にしていて、後者は売る側を軸にしている。出し手と受け手の関係で出し手を軸にするのがコミュニティだ。これはサービスコンセプトという観点で重要だが、何を解決したいのかという点ではより重要になる。
良いものを買えるようにしたい
いらないものを他者に渡せるようにしたい
買い手の立場から見ると、前者は能動的、後者は受動的なものだ。別の言い方をすると、短期的な優先度が高くなりやすいものは前者のアーキテクチャ、短期的な優先度が高くなりにくいものは後者のアーキテクチャの方が上手くいきやすい。
マネジメントの観点では、「メンバーの全員が必ずやるべき」ならばメディア的に、「メンバーの全員じゃなくても良いが多くにやってもらいたい」ならばコミュニティ的に進めると施策が機能しやすい。
発信者にフォーカスする
KPIの木
コミュニティ型のアーキテクチャにおいて第一に考えるべきことは発信者を起点に考えることだ。例えば、何らかの講演会を開くときには次のようなKPIを設定すると思う。
申込数
参加者の滞在時間
参加者の満足度
これを成し遂げるために講演者、テーマや会場を選ぶと思うが、これはメディア的な考え方だ。コミュニティ的な考え方ではこれが逆になる。
講演したい人の数
講演時間
講演者の満足度
申込数や参加者の満足度はこれに付随するKPIとなる。手段と目的が逆転していることに気づいてもらえると思う。
自己の満足
講演会の例だとフォーカスすべきKPIは講演者の満足度だから、極端な状態として参加者はゼロでも良い。矛盾していると感じるかもしれないがこれがコミュニティの入り口である。それでも楽しいという状態を作ることが大事だ。人間には元来、発信したい欲求がある。
つぶやく
メモを書く
歌う
走る
どれも一人でやっても楽しいものだ。これをさらに楽しくする要素がある。それは継続することだ。誰も知らなくても、何の役に立たなくても、人間はなにかを続けることを楽しいと感じる生き物だ。
これをさらに楽しくするのが他の人に知ってもらうことだ。いわゆる承認欲求である。これはコミュニティの始めのステージではなく、後の方のステージであることに注意してほしい。そして最後に、他者に知ってもらうことを楽しいと感じると、自身も他者を知ろうとしたくなる。これは他者を楽しませることに繋がる。こういう順序でコミュニティは形成される。
熱の伝播
チームのメンバーを増やしたいときどうするだろうか。方法は2つある。
チーム外のメンバーを勧誘する
チーム内のメンバーにより楽しんでもらう
前者はメディア的なアプローチである。
チーム外の気づいていないあるいは活性化していない候補に熱を与える。これは短期的な効果を得られやすいが、一方で元々熱のあるチーム内メンバーが「冷める」現象が起きやすい。また、熱を与えることを止めると一切効果が得られなくなる。
後者はコミュニティ的なアプローチである。
最も熱のあるチーム内のメンバーにさらに熱を与える。熱を伝播させることによって、結果的にチーム外の活性化していない候補に熱を与える。これは短期的な効果を得られにくいが、チーム内を常に活性化し続けるためチーム内メンバーのエンゲージメントを強く高める。ネットワーク効果と呼ばれるものだが、これを意図して働くように設計する。
一人ひとりと向き合う
新しいメンバーを獲得するのでなく、既存メンバーに何らかの実行をしてもらいたいときはどうするべきか。これも2通り考えられる。
チーム全体に伝達する
メンバーの一人ひとりと話す
前者はメディア的なアプローチである。
一見効率的に見えるがそうでないことがある。これが効率的な状況は、その内容が全員に共通する最高優先度のタスクである場合か、個別にアプローチできないくらい大規模に展開する場合だ。例えば
災害が発生したため、全員が速やかに建物を脱出しなければならない
伝えたい人数は1000万人である
逆に非効率的になるのは短期的な優先度が低いタスクか、個別にアプローチできる程度の人数に展開する場合である。例えば
3ヶ月以内に書類を提出する
伝えたい人数は50人である
後者はコミュニティ的なアプローチである。
さっきと同じ絵だ。コミュニティ型なアプローチでは新規のメンバーに対するアクションと既存のメンバーに対するアクションは同じになる。
別のケースを考えてみよう。既存メンバーになにかをリマインドするときどうするか。これも2通りある。
まだやってもらっていないメンバーにやってもらうようにお願いをする
すでにやってもらったメンバーに感謝をする
これは先の新規メンバーを獲得するときの話と同じだ。社員から書類を回収する最も効率的な方法は、実は期日を守る社員に感謝を伝えることだ。そうするとその社員は他の社員のサポートをするようになる。逆に感謝されていない、あるいはそれに意味がないと感じられる場合、それを続けることをやめてしまう。
コミュニティの状態
モメンタム
コミュニティ的なアーキテクチャは瞬発力はないが強い慣性が働く。コミュニティは回りだすとそれを放置しても勝手に回るようになる。
マネジメントにおける課題は次の2つに大別される。
状況を変化させたいもの
状況を維持したいもの
状況を変化させるにはトップダウンが効率的だ。誰からの反発も受けずに難しい意思決定をすることはできない。悪い状況を好転させるにはCxOの意思の力が必要である。
一方、力をかけずにそのまま続いてほしい、あるいはさらにスケールアウトしてほしいものというものもある。こういうのは自己組織化されたコミュニティが効率的だ。
トップダウンマネジメントとコミュニティマネジメントのどちらが優れているということはない。自動車を始動したり坂道を登るときは低速ギア、最高速度を効率的に維持するなら高速ギアが有用である。
クラスタ
コミュニティ内部の状態は一枚岩ではない。むしろ、多様な興味が混在する。先に述べたように熱量の高い層と熱量の低い層が存在するが、より正確にはこういう構造になる。
縦が熱量、横が興味と関心の幅となる。例えば、noteというサービスの場合は次のようになっていると思う（想像で書くがそれほどずれてはいないだろう）。
（熱量）記事を頻繁に書く人とそうでない人がいる
（興味）様々なカテゴリーがある
（濃度の偏り）記事を頻繁に書く人ほどカテゴリーに左右されなくなる（誰からも読まれる記事を書いたり、色々なカテゴリーの記事を読む傾向が出る）、一方で記事を書かない人はカテゴリーの影響を強く受ける
また、パレートの法則が再現する。
2割の人や記事が8割のビューを生み出す
2割の人は絶対に記事を書かない
よって、コミュニティマネジメントで行うべきは次のどれかになる。
熱量の最も高いクラスタに注目して熱量の総量を大きくする
熱量が中くらい箇所の熱量を上げて、熱量の高いクラスタを大きくする
熱量の低いクラスタを底上げする
熱量の低いクラスタの幅を広げる
熱量の高いクラスタと低いクラスタの温度差を縮める
どれかが欠けるとコミュニティが脆くなるため、実際にはそれぞれに対して同時に施策を打つだろう。
エコノミクス
発信者にフォーカスするというのはミクロな話だ。マクロに捉えた場合どうなるか。なにかが交換される環境では次の3つの要素がある。
ノードがもつ値
ノードが渡す値
ノードが受け取る値
1つ目はストックであり、2つ目と3つ目はフローである。渡す値と受け取るは等しい。「値」はお金でも知識でも感情でも何でも良い。
コミュニティは静的なものではなく動的なものである。ノードそのものの状態とノード同士の相互作用からなる系を考える必要がある。
活性化していないノード候補、すなわち外部のネットワークを考慮すると
こういう図になるが、これがそのサービスのTAMとなる。
応用例
少し具体的な例で考える。
『朝のあいさつ』問題の解答
最初の問題の処方箋はあまり難しくない。わたしが挨拶しない類の人間なので「わたしですら思わずやってしまう状況」を作ることができれば良い。
朝にあいすつするメンバーを昇格させる
朝にあいさつをするメンバーが出社する時間を会社の出社時間として設定する、結果的に多くの社員はそのメンバーと同じ時間帯に出社する
朝にあいさつをするメンバーのデスクをオフィスの中央か玄関の近くにする、または給湯室の近くにする
熱量の高い箇所を活性化し、その周辺にネットワーク効果が働くようにする。逆に熱量が低い部分は断熱して、負のネットワーク効果が働かないようにする。短期的に優先度の高くないトピックは優先度の高くない物理的な状況の影響を強く受けるからそれを調整する。逆に引っ越しをしたりリモートワークに移行したときに、意図せざる形でこういうことが起きることがあるので注意しよう。
テックブログ
テックブログは二極化する
たくさん書かれる、何もしなくても皆が勝手に書く
全く書かれない、どんなに頑張っても続かない
なぜこうなるのか。エンジニアにとってテックブログの優先度はだいたい5番目くらいだからトップダウンマネジメントは絶対に上手く行かないし、コミュニティが形成されているなら何もしなくても上手く回る。
おわりに
熱力学第二法則である、エントロピーは増大する。
弊社の重要機密を書いてしまったわけだが、まあ問題にならないだろう。スクラムと同じで『理解は容易、実践は困難』。
以下、宣伝
この記事が気に入ったらサポートをしてみませんか？