遅すぎるスケーリングと早すぎるスケーリングのリスク

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

将来の成長に向けた計画を立て始めるのに、早すぎるということはありません。あなたが構築しようとしているのが図書館なのか、コーヒーショップなのかを明確にすれば、適応的な戦略の設計を始めることができます。

私たちは顧客ベースに関する調査を実施し、コミュニティに課題を抱える顧客において一貫して現れる3つの早期兆候を発見しました。

  • 明確なユースケース/基本的なローンチ方向性の欠如
  • ステークホルダー間の調整不足/明確な責任者の欠如
  • 早期の進捗状況の欠如（キックオフ後に活動が停滞する）

これらの重要な要素が最初から適切に処理されない場合、それらは後工程での失敗の先行指標となります。

これらへの対応が遅すぎると、コミュニティはますます脆弱になり、早期に分裂するリスクが高まります。コミュニティの分裂：成長が障害になる時を参照してください。

動き出しが早すぎることによるリスクはそれほど高くなく、以下のような形で現れる傾向があります。

  • 必要以上に複雑なプロセス
  • メンバーが不必要な摩擦を経験する
  • スタッフの負担が重い
  • 不況（活動の低迷）
  • レポート用の有意義なデータの欠如

さらに読む
コミュニティのライフサイクル：ローンチからレガシーへ

上記の記事で言及しているコミュニティは、拡張性が不十分であるためプロセスが破綻したコミュニティの良い例です。私たちのモデレーションプロトコルは拡張性に欠けていたため、vBからDiscourseに移行する際に見直す機会を得ました。それは正しい判断でした。

他にも体験談をお持ちの方はいますか？

「いいね！」 6
2

このような調査結果を共有していただきありがとうございます。明らかに、このフォーラムは活気あるコミュニティの素晴らしい例であり、Discourseフォーラムソフトウェアが適切に使用されている優れた例です。小さくまだ成長中のコミュニティの管理者として、ここで示された例から学ぶことはたくさんあります。

顧客ベースから得た経験を共有していただけるのは特に有用で、感謝しています

「いいね！」 4
3

120万人という巨大なコミュニティを、遅すぎるタイミングでスケーリングした際のおもしろいエピソードがあります。

SkyscraperCityは、世界で最大級の、もしや最も大きな、建築、都市環境、大都市の構造物に特化したコミュニティの一つです。世界中の都市開発や大型構造物が点在する各地域にはそれぞれ専用のセクションが設けられています。当然ながら、コミュニティ内では膨大な数の写真が共有されています。というのも、メンバーたちは議論されている高層ビルについて、本当に、本当に詳しく見せたり説明したりするのが大好きだからです。

問題は、あなたが予想するところでは発生しませんでした。

問題は、画像処理や添付ファイルのスケーリングが遅れたことではありませんでした。それは既知の要因であり、プラットフォームはそれを処理できるよう設計されていました。

問題は、独自の大都市圏の数が増加し、大陸、国、州、そして最後に都市という階層に基づいたカテゴリ、サブカテゴリ、サブサブサブカテゴリがそれぞれ新しく追加されるにつれて発生しました。都市には無数の地区が存在し得るため、その数は膨大でした。コミュニティの情報アーキテクチャは、各エリアが活発になることに対応できるプラットフォームの能力を超えてスケーリングしてしまいました。膨大なカテゴリの重みによってプラットフォームは悲鳴を上げ、パフォーマンスは極端に低下しました。ページ間のナビゲーションはひどく遅く、投稿など不可能な状態でした。

使用されていた特定のプラットフォームは、カテゴリのノードツリー上に構築された古いXenForoのカスタムビルドであり、構造の一部として数百や数千の個別カテゴリを処理するように設計されていませんでした。その設計上、各ノードは相当量のリソースを占有するため、ある時点でノードの数が増えるほど、プラットフォームは不安定になります。私がオタクなので、コミュニティに対してこれを視覚的に説明する際に、『スタートレック：ニュージェネレーション』のあるエピソードに例えました。ワープエンジンが時空の構造に頻繁に穴を開け、交通量の多い領域の空間を弱めてしまうという話です。

無数のカテゴリ（サブサブサブサブカテゴリなど）は、人気のある宇宙領域の内外で数百のワープドライブが作動することでその領域が崩壊するのと同じように、プラットフォームの安定性に「損傷」を与えていました。

解決策は連邦のそれとそれほど異なりませんでした。つまり、穴を開ける頻度を抑制し、上限を設けることです。そこで、情報アーキテクチャを大幅に改訂し、低レベルのカテゴリだけでなく、いくつかの高レベルのカテゴリも統合することで、システムは安定しました。

もちろん、Discourseではこの問題は発生しません。Discourseはカテゴリを巨大な構造木ではなく、一等のコンテナとしてはるかに優れた方法で扱うからです。いわば菌糸ネットワークやトランスワープ導管のようなものです。しかし、これは私が経験した「早すぎるスケーリング」の最も顕著な例の一つであり、かつ、問題がどこから来るのかを予想しにくいケースでした。

「いいね！」 1
4

素晴らしい例ですね！共有していただきありがとうございます。

同様のケースを目撃したことがあります。私が管理したコミュニティではなく、私たちの顧客ベースの中でです。名前は挙げませんが、ある大手ブランドが当社を訪れ、コミュニティを Discourse へ移行したいと望みました。彼らはナビゲーションソフトウェアを提供しており、サービスを提供するすべての地理的ロケーションごとにサブカテゴリを設けていました。

当時、数千ものカテゴリがある場合、管理機能への負荷が心配でした。より深い階層の構築を拒否し、タグの強力な機能を説いてみましたが、彼らは頑として譲りませんでした。持続可能我们认为な方法で機能するとは到底考えられなかったため、私たちはその取引から撤退しました。

スケーラブルな情報アーキテクチャ（IA）を設計することは非常に重要です。

「いいね！」 1