良い質問ですね。上記の投稿では最初のローンチを念頭に置いていましたが、実際にはそれほど単純ではありません。エンタープライズ企業では、何らかの形で事前にコミュニティが存在しています。
私が何を意味しているのかを具体的に説明するために、私たちの Discourse に先行していたコミュニティは複数のプラットフォームに分散していました：
- Yammer（Viva Engage）
- Sharepoint
- Microsoft Teams
これにより、期待値の管理が著しく困難になりました。
Viva Engage からのユーザーは「自分が投稿したいものを何でも投稿できる」という期待を持っていました。運営チームはモデレーションを行わず、近づいてくるすべてのマネージャーの気まぐれにイエスと答えていました。その結果、マネージャーの KPI を満たすためだけのコミュニティが生まれました。新しいコミュニティが立ち上がり、3ヶ月間活発になった後、死に絶えていました。言うまでもなく、この考え方を克服し、なぜそのアプローチが数ヶ月後に失敗するのか、そして私たちの構造化された長期的なアプローチがなぜ6〜12ヶ月後により良い結果をもたらすのか（ただし、最初は遅くなる）を説得するために、大規模なコーチングとコミュニケーションの努力が必要でした。
Sharepoint は「自分が望むファイルを何でもアップロードできる」という期待を生みました。エンタープライズレベルでは、ファイルをオープンに共有する際には非常に注意が必要です。各顧客やサービスプロバイダーには会社との独自の契約があり、彼らが私たちに共有する各ファイルには異なる機密性の要件があります。Sharepoint はユーザーがそのファイルに誰がアクセスできるかを正確に設定できますが、Discourse はできません（当然です、ファイル共有プラットフォームではないので）。私はこの問題を、ユーザーにファイルを Sharepoint にアップロードし、それらのファイルへのリンクを共有するように促すことで回避しました。共有されたファイルにアクセスできない場合、トピック内で権限を依頼できました。面倒ですが、訴訟を起こされるより安上がりです。
MSTeams は「ここで自分のチャンネル/コミュニティのパーティションを持てる」という期待を生みました。いいえ、Discourse の目的はまさにその逆でした。プロジェクトの目標は、ナレッジサイロではなく知識の共有をすることでした。チームのチャンネルは機密情報やプロジェクト固有の知識には良い解決策でしたが、より一般的な文脈に抽象化できるものは Discourse で共有することが奨励されました。