コミュニティ所有モデル

コミュニティ エンタープライズ
1

コミュニティの所有権と運用モデルについて考えており、あなたの組織内でコミュニティがどのような位置づけにあるかについてもっと知りたいです。

以前は明確だが異なる2つの考え方がありました。一方では、コミュニティチームは自律的で自己統治可能な独立した単位であるべきだと主張し、他方では、他の部門に報告する方が理にかなっているという意見でした。

私には意見がありますが、大企業内でコミュニティマネージャー（CM）として働いた経験はありません。実際に（またはかつて）そのような立場にいた方々のご意見を伺いたいと考えています。

私の現在の見解は、小規模な組織や、コミュニティが単一の部門のみを対象としている場合、その部門に報告する方が理にかなっているというものです。

例えば：

コミュニティの目標 報告先
サポートの軽減 サポート
獲得、提唱、またはイベント マーケティング
製品フィードバック、テスト、アイデア創出 プロダクト

一方、多くの部門を対象とするエンタープライズ規模のコミュニティは、自律的なリーダーシップにより適切に運営される可能性が高いです。部門がサイロ化せず、強力な機能横断的なガバナンスが確立されている場合、競合するステークホルダーの優先事項が多すぎることによる問題を回避する最も効果的な方法であるように思えます。

コミュニティ・ラウンダーテーブルのこのデータは、独立したアプローチが回答者全体で拡大していることを示唆しており、そのうち約30%は1,000人以上の従業員を擁する組織からのものです。

image
image788×798 89.2 KB

コミュニティの所有権とガバナンスモデルにより、直接的にどのようなメリットや課題に直面していますか？

「いいね！」 9
2

最初の返信から始めようかな :zany_face:

現在の役割では、コミュニティチームはマーケティング部門内に属しており、その利点は確かにあると思います。これにより、ポジショニング、ローンチ、コンテンツ、アドボカシー、そして企業が伝えようとしているより大きな物語に対して、強力な結びつきを持てます。

しかし、私は常にコミュニティは従来のマーケティングとは異なるものだと感じてきました。確かに重なる部分はありますが、その背後にある運営ロジックは異なります。例えば、獲得ファネルで有効な手法が、コミュニティ内部でも必ずしも有効であるとは限りません。適切な判断とは、最も即座なエンゲージメントやキャンペーン価値を生み出すものではないこともあります。時には、傾聴し、ペースを落とし、フィードバックのための空間を作ること、あるいは測定が難しい場合でも信頼を守ることが必要です。

私にとって、マーケティング部門内に所属する最大の課題は、コミュニティが「ただの別のチャネル」に還元されないようにすることです。なぜなら、コミュニティはただ放送するだけの別のオーディエンスではないからです。

このモデルが最も効果を発揮するのは、コミュニティチームがメンバーファーストの意思決定を自律的に行える一方で、支援する他のチームとも密接に連携している場合だと思います。

総じて、答えは「コミュニティはX部門に属すべきだ」というものではないと思います。より重要な問いは、組織がコミュニティチームに部門横断的に運営するための権限、アクセス、そして信頼を与えているかどうかではないでしょうか。ただし、私はエンタープライズ規模のコミュニティでのみ経験があるため、小規模なコミュニティについては、主にサービスを提供している部門に報告する方が理にかなっているとも考えられます。しかし、コミュニティがマーケティング、プロダクト、サポート、カスタマーサクセス、教育などを同時にサポートする段階になると、より独立したコミュニティリーダーシップの価値が理解できます。

さもなければ、コミュニティは実際に何が必要かではなく、どの部門がそれを「所有」しているかによって形作られてしまうリスクがあります。

「いいね！」 9
3

その通りです。最も基本的なレベルでは、コミュニティはファネルの上部にある獲得チャネルとして機能しますが、一度コミュニティに参加すると、より複雑な信頼関係を構築していく必要があります。

[quote=“noahl, post:2, topic:404814”]
より重要な問いは、組織がコミュニティチームに部門横断的に活動するための権限、アクセス権、そして信頼を付与しているかどうかではないでしょうか。
[/quote]\n
同意します。ここがモデルが破綻するポイントです。

あなたが言いたいのは、コミュニティチームが完全に自律しており、機能的にはマーケティング部門に報告ラインを持っている、ということですね。もしそうであれば、マーケティングチームがメンバーファーストではないとあなたが判断する施策を実行しようとした場合、境界線はどう引きますか？また、利害の衝突はどう解決しますか？

さらに、あなたのコミュニティがマーケティング目標の達成を目的として設計されている場合、他の部門の関係者からの要求に対処する際に課題は生じませんか？

「いいね！」 6
4

あなたの推測は概ね正しいですが、少し留保があります。

私たちはマーケティング内に位置しているため、「独立したビジネスユニット」という意味で完全に自律的とは言いません。しかし機能的には、コミュニティの日々の運営方法、スペースのトーン保護、メンバーにとって適切かどうかの判断において、かなりの自律性を持っています。

境界線は、コミュニティがビジネス目標をサポートできるが、それらの単なる配信手段にはなれないということです。

リクエストが届いたとき、(マーケティングキャンペーン、リサーチ会話など)、通常は即座に「はい」または「いいえ」というわけではありません。むしろ：ここでのメンバー価値は何ですか？これは適切なスペースですか？フレーミングはコミュニティとの関係に合っていますか？多くの場合、答えは「はい、でもその形式では」、「はい、でも違うアプローチが必要です」、「そのチャンネルでは」、「基礎作業が終わるまでは」です。

リクエストが「メンバーファースト」でない場合、それは通常、フレーミングが適切でないためです。

私たちの多くのチームがコミュニティの価値を認識しており、これは良いことですが、各チームの「小さなリクエスト」は、注意深く管理されなければ、すぐに騒々しいまたは搾取的な体験になり得ます。

他のチームが自分の専門分野を知っていることを信頼するのと同じように、彼らも私たちの専門分野を理解しています。何かを支援するために創造的な方法を見つける必要がある場合、私たちはそうします。

しかし、コミュニティの健全性がその価値を与えるものとして残る必要があります。

「いいね！」 7
5

両方のポイントに完全に同意します。これに伴う主な課題は、数多くの対立する利害を持つ人々を調整する必要がある点です。そうしないと、自分のキャリアを台無しにしてしまいます：

  • 上司を怒らせると、予算やリクエストの処理が難しくなります。
  • ユーザーを怒らせると、数値が下落し、苦情が上司に届きます。つまり、上司を怒らせることになり、結果として予算やリクエストの処理が難しくなります。
  • 上司の同僚を怒らせると、そのトピックを理解しているつもりで、意味のないことを要求する人々との会議に出席することになります。上司がコミュニティについて熟知しているなら、それほど悪くありません。しかし、上司がコミュニティについて知らない場合、これらの人々を教育しようとする間に、PowerPointの作成が非常に上手になります。
  • 上司の上司を怒らせると……まあ、ご存知のとおりです。

では、エンタープライズレベルでコミュニティを所有する最も適切な立場は誰でしょうか？

私の意見では、対外的なコミュニティはカスタマーサービスが所有し、対内的なコミュニティはDevOps、IT、または学習と知識管理などの形でビジネス全体をサポートするチームが所有すべきです。そして、コミュニティが対外的かつ対内的な場合、カスタマーサービス、プロダクトなどの各部門の代表者が混在する専用のコミュニティ部門を設立すべきです。これにより、コミュニティ部長による自律的なリーダーシップと、部門代表者の熔炉による部門横断的なガバナースという両方の利点を享受できます。

私がマーケティングをリストから除外したことに気づいたかもしれません。コミュニティの最も一般的な所有者であるマーケティングですが、個人的にはマーケティングが所有するコミュニティは好きではありません。単に、そのようなコミュニティが私の最善の利益のためにあるとは感じられないからです。つまり、どうあり得るでしょうか？マーケティングの目的は、製品を購入する可能性のある人々を見つけて引き付けることです。これは定期的に「その人が最適な選択肢ではない場合でも、製品を購入するように説得する」ということを意味します。常にではありませんが、私にとって十分な頻度で、偏見に基づく懐疑的な目でそれらに接します。

一方、カスタマーサポートはコミュニティとして見るのが大好きです。ここでは、ユーザー/顧客としての私の体験を改善することが存在理由である人々によって所有されている場所です。コミュニティが対外的な場合、カスタマーサポートの手に委ねるべきです。ただし、プロダクトチームとも非常に良い密接な関係を築くことを要件としています。

「いいね！」 3
6

これは興味深い視点ですね。Discourse において、Meta はマーケティング部門に属しています。

私たちの「マーケティング」の立場は、このコミュニティを活用して人々が Discourse をより成功裡に運用できるように支援することで、それが顧客維持（リテンション）のツールとなるというものです。

「いいね！」 1
7

興味深いですね。目標が顧客維持（マーケティングの一部）であっても、実際の活動の大部分がカスタマーサポートである場合、なぜ所有権（責任の所在）がカスタマーサポートではなくマーケティングに属すると考えられるのでしょうか？ アクティブな活動を行っているという点から、所有権はカスタマーサポートに属した方が適切ではないでしょうか。それとも、階層的な観点からカスタマーサポートはマーケティングに包含されているのでしょうか？

例えば、マーケティングが所有権を持つ典型的な階層構造は以下のようになりますか？

graph TD
    HOM[マーケティング責任者] --> MCE[カスタマーサクセス/サポートマネージャー]
    HOM --> MM[マーケティングマネージャー]
    HOM --> MS_MGR[セールスマネージャー]
    HOM --> CONTENT[コンテンツ/SEOリード]
    MCE --> CSS[カスタマーサポートスタッフ]
    MM --> MKT_STAFF[マーケティングスタッフ]
    MS_MGR --> SALES_STAFF[セールススタッフ]
8

私たちはエンタープライズ組織ではなく、人員もかなり少ないことを覚えておいてください。そのため、より多くの人がいる場合の設計とは必ずしも一致するわけではありませんが、報告ラインは大きく変わらないと思います。

「サポート」はテイラーと、主にメタのチームインボックスを通じて活動する技術担当アドボケイトです。「カスタマーサクセス」はチャウと彼のチームで、プライベートカテゴリを通じてエンタープライズ顧客をサポートしています。マーケティングが戦略を所有していますが、他の部門を通じてワークロードを管理しています。

IMG_2125.HEIC
IMG_2125.HEIC1920×2560 533 KB

トビアスが去って以来、私たちはコミュニティ担当の正社員を擁していないため、この構造は他よりもむしろガバナンスや意思決定に関するものです。ダニエル（CS）が中心となり、メー（マーケティングディレクター）や社内スタッフ数名（私を含む）のサポートを受けています。

本当にそうでしょうか？ メタで行っていることは、購入者向けのカスタマーサクセス（プライベートカテゴリ経由）と、ビルダー向けのデブレルサポート（メインOSコミュニティ）の混在だと言えます。私たちのサポートチームは、チームインボックス以外でメタのコミュニティをサポートするために費やす時間は非常に少なく、コミュニティはある程度自己維持しています。

メタはチケット回避ツールとして意図されていません。なぜなら、サポートを求めている人の大多数は私たちの顧客ではないからです。

「いいね！」 1
9

へえ、それはかなり重要な点ですね。このことを見て取る視点が変わりました。Discourseはフリー＆オープンソースなので、Metaのユーザーを常に顧客と捉えていました。しかし、一方で、大多数は有料ではないので、技術的には顧客ではありません。

そして、この定義は、所有権を明確にする上で非常に効果的な線引きを生むようです。製品の大半のユーザーが有料ですか？ はい - カスタマーサポート； いいえ - マーケティング。

「いいね！」 2
10

私の見方では、私たちの戦略はここ数年でかなり自然発生的に進化してきました。

初期の頃、主に製品と連動していたと思います。具体的には、以下の2点を達成する方法を模索していました：

  • 自社で製品を試用する（dogfooding）こと かつ
  • オープンソースのユーザーから機能に関する早期のフィードバックを得ること

その見返りとして、ユーザー（広義の顧客）が得られる価値は以下の通りでした：

  • チームとコミュニティからのサポート
  • 製品の方向性に関する意見の反映

これらの要素が、このコミュニティの基盤を今も支えていると思います。

（このサイトは（有料）顧客とのコミュニケーションにも使用していますが、その多くはプライベートなチャネル（個人メッセージや非公開カテゴリ）を通じて行われています。ここではいったんそれについては言及しません（ネストした括弧を許してください））。

有機的に生まれたもう一つのユースケースは、「定着（retention）」と「推奨（advocacy）」です。これも当初は主に有料ではない顧客への対応に重点が置かれていましたが、副次的な効果として、コミュニティは有料顧客にも価値を提供しています。

最近では、コミュニティがビジネスの存続と成長をどのように支えられるかという点に、より大きな重点を置いています。もちろん間接的ですが、これもオープンソースコミュニティに役立ちます。

しかし、私たちはコミュニティが有料顧客、およびどのプラットフォームを選ぶべきか最善の判断を下そうとしている見込み顧客に適切にサービスを提供することを確実にしたいと考えています。定着と推奨は、この目標に最も密接に結びついていると言えるでしょう。

この点において、組織内の2つの部門、マーケティングとカスタマーサクセスとの間で、大きな重複があります。

現在の組織図では、コミュニティはマーケティングに報告していますが、カスタマーサクセス、マーケティング、プロダクト、そして執行陣から直接関与するメンバーがいます。

私たちが行っていることを「コミュニティはマーケティングの傘下にある」と単純化するのは難しいです。確かにその通りですが、それ以上の要素が多数存在します。

「いいね！」 3
11

例：私は満足しているユーザーですが、有料顧客ではありません。ここでの私の意見には、バグの報告、修正の提案、デザイン案とデザイン決定へのフィードバック、機能の提案が含まれます。 これらをどこに分類すればよいかは、製品の未来の方向性をどのように捉えるかによります。おそらくマーケティングでしょう。

「いいね！」 1
12

マーケティングの範疇には収まらないと思います。

実際には、これらはすべて「プロダクト開発」に含まれます。社内では、これにはエンジニアリング、デザイン、プロダクトマネジメントが含まれます。

私は、これがこのコミュニティの基盤であると信じています：

ただしもちろん、プロダクトとマーケティングは協力関係にあります（コミュニティの文脈だけでなく）。

実際には、コミュニティが「マーケティングに属する」と言えなくもないですが、コミュニティの所有権は共有されており、誰もが関与しています。

「いいね！」 3