HAWK
(Hawk)
1
「エンタープライズ・レディ」とはあなたにとってどのようなものですか?(辛辣な意見も歓迎!) および コミュニティが初期段階を超えて成長していることを示すシグナル からの議論の続きです:
管理されない成長は、支援するフレームワークやプロセスが成長速度についていけない場合に始まるパラドックスを生み出します。つまり、コミュニティの社会的複雑さが、その運用構造を超えてしまうということです。
これは以下のような形で現れる可能性があります:
- モデレーションのギャップ
- フラグ(通報)が増えるにつれて、既存のガイドラインにおける例外ケースがより頻繁に発生します。
- 明確なポリシーではなく、非公式なプロセスによるリアクティブな(事後対応の)モデレーションは、ケースの処理方法に不整合を招き、信頼の崩壊を助長します。
- 誰が決定したわけでもないのに、例外が先例となり、下流でより多くの摩擦を生むことがあります。
- 文化的な漂流
- パワーユーザー(アクティブな上級ユーザー)が文化を形成することは初期段階では往々にして好ましいですが、大規模化において適切に管理されない場合、ガバナンスの問題になり得ます。
- 大規模なコミュニティでは、匿名性の高まりと文脈の欠如により説明責任が低下し、新しい行動パターンが生まれる余地ができます。
- モデレーション機能がコミュニティに合わせて拡大したとしても、元のモデレーターとパワーユーザーの割合が新規メンバーに対して希釈されすぎて、文化的な規範が失われることがあります。
- レポートの複雑さ
- 初期段階の成功は往々にに体験談に頼りますが、エンタープライズレベルでは価値の証拠を提供する必要があります。
- 適切な指標が最初から定義・追跡されていなかった場合、ビジネスケースの構築がより困難になります。
- 埋もれた知識
- 拡張可能な分類体系がない場合、選択肢のパラドックスがどこに投稿すべきかという点で摩擦を生みます。
- 情報アーキテクチャが弱体化すると、検索結果がノイズ混じりになり、人々が検索をあきらめて再度質問するようになるにつれて、問題は悪化します。
- 内部の所有権の分裂
- 機能横断的な意思決定に対する明確な責任者がいない場合、コミュニティに対して異なるものを求める複数のチームが圧力を生むことがあります。
コミュニティでこれらの状況のいずれかを経験した方はいますか?どのように解決しようとしましたか?
「いいね!」 12
モデレーションに不整合が生じた場合や、フラグが放置されている場合は、通常、モデレーションチームと話し合いを行います。どこに人的リソースが必要なのか、チームはどのように対応しているのか、といった点です。その後、こうした問題のサポートのため、アクティブで信頼できるユーザーを試用期間付きでTL4またはカテゴリモデレーターに昇格させます。
この場合、ai による関連トピックは非常に役立ちます。なぜなら、時には回答を含む関連するトピックを提供してくれるからです。関連トピックが多すぎると、提案されるトピックは現在のトピックの単なるエコー(繰り返し)に過ぎないというデメリットがあります。
有用な回答を含む非常に古いトピックを浮上させ、重複トピックを整理(マージまたは削除)します。
他の人がどのような対策を講じているか、伺いたく思います。
「いいね!」 6
私は基本的に生成AIに懐疑的な立場ですが、この点については同意せざるを得ません。何となく、この「関連トピック」機能は、あらゆるソフトウェアに追加されたAIバブル時代の機能の中で、私の一番のお気に入りになっています。以前「類似トピック」では見つけられなかった、私が抱えている問題が既に解決済みであることを見つけるのに、驚くほど正確に役立っています。
「いいね!」 3
putty
(putty)
4
いい意味でも悪い意味でも、これまでにこれらに遭遇したことはありません。ユーザーベースは大きいが、比較的静かです(
)。
コミュニティが成長するにつれて感じた唯一の痛みは、カテゴリとグループのスコープクリープです。
- カテゴリの場合、完全なカテゴリを正当化するボリュームがないコンテンツの種類を収容するために、わずかな例外を設けることです。既存のどこかに無理やり押し込むか、新しいトピックがほとんどない新しいカテゴリを作成するかです。
- (内部)グループの場合、適切な人が不在である可能性があり、そのため代替者を追加する必要がありますが、彼らは決して削除されませんでした。
「いいね!」 1
HAWK
(Hawk)
5
うん、それはいいね。私が言及していたギャップは、一般的にはフラグの処理方法や意思決定の方法における不整合に関するものだ。それらが適切に解決され、文書化されていない場合、追加のモデレーターを追加することは問題を悪化させる可能性がある。全員が同じ認識を持っていることをどうやって保証するのか?
うん、これも過去に苦労したことがある。私が見つけた最善の回避策は、[一時的な]タグだ。タグのインスタンスが十分にある場合、新しいサブカテゴリに移動するのは簡単だ。
「いいね!」 3
jpishgar
(Joe)
6
私の世界では、規模がコミュニティにとって最大の転換点となってきました。
これは、特にB2Cやマニア層を対象としたコミュニティが、ある特定の規模を超えると、あなたが列挙したような諸問題が連鎖的に発生し始めるという興味深い現象です。その中で最も顕著なのは文化的な漂流でしょう。コミュニティ設立の本来の目的が、ユーザーベースの動向の変化や自然な離脱によって放棄されたり、影に追いやられたりする現象です。
私を常に襲うのは、構造的なコンテンツ分類の破綻点です。これはあなたが「拡大する分類体系の中で埋もれていく知識」と呼んだ、つまりノイズが多すぎることです。コミュニティを bonsai(盆栽)や果樹(例えによります)として捉える私のメンタルモデルでは、ディスカッションのカテゴリ(枝)があまりにも大きく、活発になりすぎると、以前それを支えていたコアユーザーにとって害になることがあります。アクティビティが急増すると有用性は低下し、コミュニティマネージャーが注意を払わないと、コンテンツの価値が希薄化して崩壊してしまいます。
ここでのコツは、カテゴリを分割するべきタイミングを有機的に見極め、かつコアユーザーを失わないようにすることです。これにはかなりの手作業による注意が必要です。
主要なカテゴリが大きくなりすぎて使い物にならなくなり、コミュニティが衰退したり、最初はカジュアルな「一般議論」だったエリアが肥大化して、コンテンツがもはや表面化しなくなったりする例を数多く見てきました。
この解決策は科学よりも芸術に近いものですが、私は「アクティブ」なカテゴリの評価方法に注目しています。伝統的に、Redditの古い定義を採用しています。1日あたり5投稿以上が「アクティブ」とみなされ、そこが自己維持可能なコアが形成されたことを示す基準です。「あまりにもアクティブすぎる」場合の下限は、中規模コミュニティの場合、同じ5を3乗した数値(つまり1日あたり約125投稿)です。3乗とするのは、このモデルが絶えず拡大するドーナツ形状の系列であり、人間の頭脳が記憶から相互作用できる範囲、つまり私たちの軌道内のアクターに対する範囲を考慮しているからです。
私が目にしたもう一つの重大な問題は、知識ベースのエンタープライズコミュニティにおける破綻点で、恐ろしい過剰モデレーションが災いをなす場合です。モデレーターが多すぎたり、モデレーションが強硬すぎたり、過度に厳格だったり、説教的だったりすると、新規ユーザーの同化を抑制する効果があり、結果として「長老」ばかりの非常に停滞したプールが形成されます。権力欲に駆られたモデレーションや、礼儀正しさを超えて教条的な厳格さまで及ぶトーン・ポリシングの過剰な努力は、コミュニティの活力を窒息させ、文化を阻害し、最終的にその有用性を低下させたり、完全に消滅させたりします。
大規模なコミュニティでは、モデレーションについて透明性を保ち、懲罰的ではなくリハビリテーション的な観点から、かつ優雅に行われることを求め、モデレーションがコミュニティの地位や特権ではなく、市民参加の形であることを維持することが重要です。
モデレーションのギャップについては、私の経験則は、必要な数よりも20%多いモデレーターを確保することですが、彼らが追加の潜在的なモデレーターを特定する権限を持っていることを確認することです。
「いいね!」 3
ice.d
(discord ice)
7
これは私にとってちょっとした課題です。
私はフォーラムの所有者ではなく、モデレーター兼管理者チームのリーダーとして、スタッフが適切な行動をとるよう見守り、フォーラムに適切な数のスタッフがいることを確認する役割を担っています。時折、よりアクティブなスタッフの一人として、私はちょっとした負担を感じています。半ばアクティブなユーザーと話し合い、スパムやハラスメントなどのユーザー関連の違反を処理することで私の負担を少し軽減してもらうために、彼らにモデレーター権限を与える可能性について考えることがあります。しかし、彼らはしばらくの間姿を消してしまうのです。時折、私は自問します…
フォーラムの所有者/創設者がしばらくオフラインになり、コミュニティと交流しないことが、非常に小さなフォーラムへの投稿や貢献への人々の意欲を低下させているのでしょうか?
その理由は以下の通りです。
昨年、私はこのフォーラムに参加しましたが、当時はそこそこアクティブでした。しかし夏になり、アクティビティは急激に低下しました。DAU/MAU(日別アクティブユーザー数/月別アクティブユーザー数)はひどく、フォーラムのスティッキーネス(継続利用の度合い)も悪かったです。そして今年、勢いを取り戻すのに大きく失敗し、所有者はほとんどアクティブではありませんでした。最近ではフォーラムが頻繁にダウンしており、他のウェブサイトからユーザーからフォーラムがダウンしている理由を尋ねるメッセージを多数受け取り、理由を説明する必要がありました(所有者から受信したメールによると、フォーラムのサーバーに何らかの問題があったようです)。そして、フォーラムがようやく復旧した際、一部のユーザーがチャットで投稿し始め、半ばアクティブになりました。しかし、その時私は悲しくなりました。他の三人の管理者が非常にアクティブではなかったため、アクティブな状態を維持し続けると、私の負担がまた重くなることを知っていたからです。それは良いことだとは分かっていましたが、今では再び活動が止まっており、私の疑問は頭から離れません。
「いいね!」 1
ted
(Ted Johansson)
8
これは興味深い話題ですね。特定のクリエイタープラットフォームでは、この問題について多くの議論が行われてきました。そこではモデレーションが(予測可能ながら)恣意的に適用されています。いくつかのケースでは、プラットフォーム自体がその判断を公開していません。しかし、透明で公平かつ一貫性のあるモデレーション体制を構築したいと仮定した場合、大規模なシステムではどのように設計すべきでしょうか? アピールシステム? 内部監査? 暴走するモデレーターを捉えるためのパターン認識?
モデレーションの隙間を除く他の点は、多くの組織が成長する過程で内部で経験するのと同じ問題のように聞こえます。 
「いいね!」 3
HAWK
(Hawk)
9
テッドさん、お久しぶりです。 
私の経験では、適切な人材を採用し、彼らに信頼を寄せること、定期的なコミュニケーション、プロセスの文書化(例外ケースを含む)、そして明確な異議申立て経路の整備がより重要だと考えています。
The Community Lifecycle: From Launch to Legacy より引用
55人のボランティアモデレーターからなるチームは、すでに円滑に運用されていました。ガバナンスは、異なるサブフォーラムに割り当てられたチームリーダー、アドバイザー、メンターによって分散管理されており、すべてが中央で管理され、詳細に文書化され、定期的に再評価されるプロセスに従って運営されていました。
関連する経験をお持ちの方がいれば、他の意見も聞きたいです。
「いいね!」 2
sps
(Sukhman Preet Singh Jawa)
13
このシナリオは親しみやすく、まるでコミュニティ構築のビンゴカードから項目を消していくような気分でした。
課題が浮上するたびに、理解とサポートを示すチームメンバーや、非常に役立つDiscourseスタッフらが積極的に対応してくれるのを見るのは励みになります。
私の見解では、パワーユーザーがコミュニティの行動に影響を与えることは、その行動が定めたガイドラインと一貫して一致している限り、本質的に問題ではありません。
私が最も興味を持っているのは、経験豊富でポジティブなパワーユーザーを長期的に持続可能に維持することです。コミュニティが拡大・進化していく中で、これらのメンバーは文化的規範やベストプラクティスを新しい世代のアクティブメンバーへと伝える上で重要な役割を果たし、コミュニティの長期的な健全性を確保します。
「いいね!」 3
HAWK
(Hawk)
14
@sps さん、完全に同意します。多くの場合、まさにその理由からパワーユーザーを育成することは非常に有益です。
おめでとうございます!数年前に、まさにそれについていくつかの調査を行いました。Motivations - Building Successful Superuser Programs をご覧ください。
「いいね!」 2
カレンダー機能/カレンダー統合(およびビデオ会議統合)の非常に「部分的」な実装は、Discourseのエンタープライズ利用における明確な課題です。
Microsoft中心の職場環境でDiscourseをより深く導入しようとする際、Discourse上で完全に進行したトピックの最後に、日付/時間の設定にはDiscourseの投票機能のような便利機能が含まれていたにもかかわらず、カレンダー設定にはTeams/Outlookのリンクを貼り付ける必要があると認めなければならないのは、正直なところ恥ずかしい限りです。多くのチームは(特に初期段階では)、参加者からの強いDiscourseへのコミットメントを必要とするDiscourse内カレンダーの完全な採用に乗り出すわけではありません。
「いいね!」 2
HAWK
(Hawk)
16
あなたもラッキーです!カレンダー/イベントは現在積極的に開発中で、ビデオ会議はロードマップにあります。ギャップについては認識しています。
「いいね!」 2
Tris20
(Tristan)
17
私の意見では、特に初期段階において、これとプロジェクト内の上位陣に対する慎重な期待値管理が極めて重要です。
誰にでも門戸を開き、Discourse を過剰に宣伝するのは、プロジェクトを簡単に壊すことになります。関連性のない、または注意を散漫にするようなあらゆる種類の投稿、あるいはフォーマットが酷く専門家を怒らせるような質問が押し寄せ、管理チームは初期のユーザー数(これは間違いなく減少します)に引きずられることになります。この状態からの回復は、予防するよりもはるかに困難です。
私たちはこれを解決するために、以下のトピックを特に読み終えるまで、新トピックの作成を禁止しました。
- 良い質問の書き方(Stack Overflow の手法)
- 共有してはいけないこと(顧客の機密保持義務による)
- 共有してもよいこと、および違法なコンテンツを合法にするための修正方法
これにより、三つの成果が得られました。
- プラットフォームのモデレーションが容易になりました。トピック作成前に、何が良くて何が良くないかを非常に明確に示しました。
- 低努力なコンテンツの波から専門家を保護しました。
- 多くの人を怒らせました
特に3番目についてですが、初期の制限に直面したスタッフの約20〜30%は、10分間の読書は自分には屈辱的であり、すでに完璧な質問の書き方を知っていると考えていたと推定します。少数の場合ではその通りでしたが、大部分の場合、これは私が考えうる文化に合わない人々を遠ざけることになりました。具体的には:
- 読書は書き物よりも重要である
- プラットフォームには謙虚な姿勢で臨む
- 他のスタッフが
- a) あなたを助けるために「ボランティア」で費やす時間を減らせるように
- b) 2〜3年後にもトピックから学べるように
適切にフォーマットされた質問をすること
[quote=“HAWK, post:1, topic:402716”]
適切なメトリクスが最初から定義・追跡されていない場合、ビジネスケースの構築がより困難になります。
[/quote]\nこれも非常に良い点です。トピック数、トピックの閲覧数、回答数などを基にしたROI(投資対効果)の式を作成し、最終的に、専門家がDiscourseで一度尋ねられることで、異なる通話やメールチェーンで複数回尋ねられる場合に比べて、どれだけの時間が節約されたかを算出することが非常に役立ちました。
「いいね!」 5
HAWK
(Hawk)
18
トリストン、良いポイントですね。「初期段階」と言っていますが、以前からコミュニティが存在していたのでしょうか?それとも、文字通り最初のローンチのことをおっしゃっているのでしょうか?
Tris20
(Tristan)
19
良い質問ですね。上記の投稿では最初のローンチを念頭に置いていましたが、実際にはそれほど単純ではありません。エンタープライズ企業では、何らかの形で事前にコミュニティが存在しています。
私が何を意味しているのかを具体的に説明するために、私たちの Discourse に先行していたコミュニティは複数のプラットフォームに分散していました:
- Yammer(Viva Engage)

- Sharepoint

- Microsoft Teams

これにより、期待値の管理が著しく困難になりました。
Viva Engage からのユーザーは「自分が投稿したいものを何でも投稿できる」という期待を持っていました。運営チームはモデレーションを行わず、近づいてくるすべてのマネージャーの気まぐれにイエスと答えていました。その結果、マネージャーの KPI を満たすためだけのコミュニティが生まれました。新しいコミュニティが立ち上がり、3ヶ月間活発になった後、死に絶えていました。言うまでもなく、この考え方を克服し、なぜそのアプローチが数ヶ月後に失敗するのか、そして私たちの構造化された長期的なアプローチがなぜ6〜12ヶ月後により良い結果をもたらすのか(ただし、最初は遅くなる)を説得するために、大規模なコーチングとコミュニケーションの努力が必要でした。
Sharepoint は「自分が望むファイルを何でもアップロードできる」という期待を生みました。エンタープライズレベルでは、ファイルをオープンに共有する際には非常に注意が必要です。各顧客やサービスプロバイダーには会社との独自の契約があり、彼らが私たちに共有する各ファイルには異なる機密性の要件があります。Sharepoint はユーザーがそのファイルに誰がアクセスできるかを正確に設定できますが、Discourse はできません(当然です、ファイル共有プラットフォームではないので)。私はこの問題を、ユーザーにファイルを Sharepoint にアップロードし、それらのファイルへのリンクを共有するように促すことで回避しました。共有されたファイルにアクセスできない場合、トピック内で権限を依頼できました。面倒ですが、訴訟を起こされるより安上がりです。
MSTeams は「ここで自分のチャンネル/コミュニティのパーティションを持てる」という期待を生みました。いいえ、Discourse の目的はまさにその逆でした。プロジェクトの目標は、ナレッジサイロではなく知識の共有をすることでした。チームのチャンネルは機密情報やプロジェクト固有の知識には良い解決策でしたが、より一般的な文脈に抽象化できるものは Discourse で共有することが奨励されました。
「いいね!」 3
Orioni
(John)
20
少し関係ある話ですが、スケーリングとコミュニティの分裂について話していることです。
人類学には「ダンバーズ・ナンバー」という用語があります。簡潔に説明すると:
ダンバーは、人間が安定した関係を維持できる人数は約150人であると提唱しました
Discourse内で、あるユーザーが関心を持つユーザーのサークルの平均サイズを調べることができるでしょうか?また、ユーザーグループやカスタムグループなどの一般的な分析から結論を導き出すことは可能でしょうか?
私がこの質問をする理由は、社会的な範囲の限界に達するか、あるいはその限界を超えることがコミュニティの分裂点に寄与する要因となる可能性があるからです。
これはDiscourseが大規模に分析できるものですか?興味深い研究になるでしょう。
追記:以前、ダンバーズ・ナンバーの理論は別の文脈でこの古い議論でも言及されていました。 Don't be fooled by activity metrics – they may vary greatly in different community types - #8 by HAWK
HAWK
(Hawk)
21
確かに大規模なコミュニティにおいてそれは寄与する要因の一つです。あなたの戦略には、そうしたグループが分裂し、半自律的に運営されることを支援するプロセスを含めるべきです。
出典: Community Fragmentation: When Growth Becomes Your Obstacle
オンライン・コミュニティのライフサイクルにおける最終段階は「分裂(mitosis)」と呼ばれ、これは単一の細胞が遺伝的に同一の子細胞に分裂する細胞分裂のプロセスにちなんで名付けられました。その目的は、アイデンティティを維持したまま分裂を可能にすることです。サブグループが元のコミュニティのDNA――つまり価値観、文化、共有された伝承――を、メンバーだけでなく継承できるようにするには、意図的な取り組みが必要です。
分裂の戦略は、コミュニティそれぞれが固有のものなので異なって見えますが、成功するためには、より広範なコミュニティ・エコシステムの一部として共生しながら自律的に運営されるサブグループの形成を可能にすることが不可欠です。
「いいね!」 2