0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Discord でコミュニティサーバを運営する際のベストプラクティスとアンチパターン

0
Posted at

昨今,個人運営・企業運営の別なくさまざまなコミュニティが立ち上げられていますが,そのプラットホームとして Discord を利用することは非常に妥当性があり,また実際多用されています.
しかし,その運営手法に関しては,必ずしも適切とはいえない状態にあるコミュニティが数多く存在します.私が一人のメンバーとして参加しているコミュニティでも,そのような,言ってしまえば「誤った運営」がされているのをよく目にします.これは管理者が必ずしも「すべき運営」を知らないか,何かしらの理由で外れてしまっていることが原因の多くを占めているものと思われます.
参加者数が数十人程度と小規模であるならばまだしも,100 人 1,000 人が参加しているとなれば適切に運営する必要があるのは言うまでもありません.しかし,その手法について記述した資料はあまりないように思えます.そのため,自分自身の理解を再確認する意味も込めて,文章化しようと思います.

おことわり

私は小規模ながらコミュニティ運営の経験こそあれど,それを専門としてやっているほどではありません.なおかつ,本稿で述べることが必ずしもすべてのコミュニティに適応するという訳でもありません.そして,私はあくまでも私自身が管理・運営しているコミュニティについてのみ責任を持つのであって,その他のコミュニティに関する一切の責任を持ち得ません.当該コミュニティを管理する立場の皆様が責任を持って,意思決定を行ってください.

想定するコミュニティの運営方針について

コミュニティと一言で言ってもその毛色は様々ありますが,多くはこれらかと思います.

  • 動画配信者の視聴者が集まるコミュニティ
  • 同好の士が集まるコミュニティ

基本的にこれらを念頭に入れつつ,全般に共通する考え方を述べていきます.

Discord の利用が妥当と言える理由

まずは前提として,なぜ Discord が使われるのかというところを考えます.かなり人口に膾炙しているような雰囲気があるため Discord を採用するという判断が所与のものとされがちにも思えますが,念の為考えを明文化してみましょう.

一つに「立ち上げるのが簡単」という理由が挙げられるでしょう.Discord のアプリを立ち上げて,参加しているサーバの一覧が並ぶ列の最下部にあるプラス記号のボタンを押せば作成に進めますし,UI も分かりやすくてあまり難しいことを考えなくても作れてしまいます.
また,アクティブユーザ数が多いということも重要です.「自分でコミュニティを立ち上げられる」サービスの中では最多クラスと言えましょう.加えて基本利用が無料であることも大きいと言えます.課金サービス(Nitro / Boost)はありますが,必須ではありません.これらは利用の敷居を大きく下げることになるため,参加者を集めるにも有利でしょう.
そして,権限の制御が柔軟に行えたり,外部サービスとの連携が容易にできたり,Bot を動かせたり,やろうと思えば実装次第で結構好き勝手できるのも利点です.
これらを「Discord を使う理由」としておきましょう.

やや逸れますが,Boost について言及しておきましょう.これは,ある程度規模が大きいコミュニティを運営する際に欲しい機能をアンロックできるサービスで,Boost のレベルには 3 段階あります.詳しくは別途調べて欲しいですが,ボイスチャットでの音声のビットレートが上がったり,画面共有の解像度・フレームレートが上がったり,アイコン・バナーの画像に GIF が使えるようになったり,オリジナルの招待リンクを発行できるようになったりします.

すべき運営と避けるべき運営について

まずは,そのコミュニティが「何のためのコミュニティか」を明確にしておく必要があります.その上で,管理者が取り組むべきことに加えて,先の方で上げた二つの例について,それぞれに向いた運営手法を見ていきます.

まず,そのサーバの所有者となるアカウントの二要素認証を有効にしましょう.これは主には乗っ取り対策です.規模が大きいサーバならば,運営者とは別に,サーバを所有する専用のアカウントを用意したほうが良いこともありますが判断はお任せします.
(しかし,それに限らず二要素認証は有効にしておくべきです.)

最も重要とも言える Discord の機能にロールがあります.Discord サーバの参加者すべてに割り振られるロールとして @everyone がありますが,@everyone だけでは何もできないようにしておくのが良いでしょう.ロールごとの権限を設定する画面に行くとロールのリストの一番下に @everyone がありますが,これを開いてすべての権限を無効化する(「権限をクリア」する)のがオススメです.閲覧・発言を始めとしたありとあらゆるアクションが取れなくなります.そして,@member のようなロールを作成し,閲覧・発言など基本的な権限を与えた上でそのロールを付与するようにするのが一般的な運用かと思います.
付与したい対象を個別に指定したい権限があれば,都度ロールを作成して振り分けましょう.例えば,特定のチャンネル(またはそれらをまとめたカテゴリ)へのアクセスを制限したい場合,そのチャンネル・カテゴリの閲覧・発言を有効にしたロールを作成し,何かしらの方法でロールを付与する形になります.
そして,一般参加者に付与するロールとは別に,管理者向けのロールも作成しましょう.それも,一つだけではなく複数段階に分けることをオススメします.例として @管理者 / @準管理者@admin / @manager などです.高位のロールほど取れるアクションの幅を広くしていくことで,マネジメントを柔軟に行えます.Discord の場合,スパムアカウントがそこそこの割合で発生しますが,それに対応できる人は限定させるべきです.しかし,Kick や Ban を行える人が数人だけでは,スパム等の迷惑行為への対応が遅れがちになってしまいます.そのようなことにならないよう,タイムアウトのみ実施できるよう設定した低位の管理者ロールを作成してある程度信頼出来るアカウントに付与しましょう.管理者ロールを持つアカウントのみアクセスできるカテゴリを用意しておいてチャンネルを作成し,発生した事件と行った対応について報告をしてもらうようにすれば,その後の対応も迅速に行えることが望めます.高位の管理者のみが Kick / Ban をできるようにすることで,権限の乱用も防げます.まずはタイムアウトだけしておいてもらって被害の拡大を防ぎ,その悪質度に応じて高位の管理者が Kick または Ban を行うようにするという,2 段構成にするのが良いでしょう.

特に気をつけるべき設定としては,まず @everyone / @here へのメンションを禁じることです.スパムアカウントは高確率で @everyone メンションしてくるのであらかじめ権限を消しておきましょう.そもそも,@everyone メンション自体がかなり強い影響力を持ったアクションなので,管理者であっても常用すべきではありません.
また,「メッセージ履歴を読む」が有効になっていないと過去のやり取りが一切見えなくなるので,基本的には有効にしておくことをオススメします.

サーバ設定からコミュニティを有効にすると,オンボーディング機能が使えるようになります.これはサーバに参加した時にルールやガイドラインの確認を促したり,付与するロールの割り振りができるようになったりするものです.ロールの付与などを参加者の選択に合わせて勝手に行ってくれるので便利です.

これらに加えて,私はすべてのアクションのログを取るようにしています.外部サービスですが,ProBot というものを導入することで,ログ専用のカテゴリに作ったチャンネルに流すよう設定できます.

image.png

このカテゴリ内はログ通知専用とし,サーバを所有しているアカウント以外発言できないようにしましょう.議論が必要なのであれば管理者用のカテゴリ及びチャンネルを作り,そちらですべきです.

視聴者コミュニティの場合,参加条件を特に設けないオープンなコミュニティと,有償サブスクリプションに加入している場合のみ参加権が得られるクローズドなコミュニティとに大別されると思われますが,いずれにせよすべきことは変わりません.

企業などが公式のコミュニティサーバとして用意する場合,YouTube に動画を投稿したことなどを知らせる通知をするチャンネルを作成することが多いと思います.これ自体はなんの問題もないのですが,ここで @everyone を発出することが往々にして見られます.しかし,これは絶対にしてはいけません.もしあなたが管理者となっているコミュニティで行ってしまっている場合,今すぐに解消しましょう.
理由としては以下の通りです.

  • コミュニティの趣旨から逸脱する
  • 参加者が個別に通知の受信を制御することができない
  • 確実に受信させる必要のある通知と区別できない

1 つめの「コミュニティの趣旨から逸脱する」について.
何のためにコミュニティを作るのかを考えると,そこに「強制力を持って通知を受信させる」必要性はどこにもないことがわかるでしょう.コミュニティである以上,主たる目的は「視聴者同士ファン同士の相互交流」であるはずで,そこに「通知を受信させる」という要件が介在する余地はありません.
しかし,これは通知用のチャンネルを作るべきでないと言っている訳ではありません.それ自体はコミュニケーションの起点にもなりうるものです.@everyone で通知を送りつけることがいけないのです.通知を受け取りたい参加者が全てではありません.中には,あまり通知を受け取りたくない人もいます.(私はかなりその気があります.)そのような参加者がいるということを想像できず,参加者全員を巻き込むのは運営者のエゴに他ならず,ある種の迷惑行為とも言えます.絶対に避けましょう.
とはいっても,その通知の存在をありがたく思う人がいるであろうこともまた事実です.なので,@notify-youtube などの通知専用のロールを作成し,オンボーディングの段階で通知を受け取りたいかどうかを選択できるようにしましょう.こうすれば,通知を受け取りたい人・受け取りたくない人双方にとってよい状況を作れます.@everyone のようなメンションは通知チャンネルをミュートしていても貫通してくるので受け取り手でフィルタを掛けることができませんが,そもそもロールごと分けてしまえば元から受信しないのでなんの問題にもなりません.
そもそもの話をしてしまうと,例えば YouTube に動画が上がった通知なら,チャンネルを登録して通知をオンにすれば YouTube が直接送ってくれるので,そもそも Discord を通す必然性がないのです.新着を早く知りたい人は既に通知を受け取る設定にしているはずです.プラットフォーム側が用意してくれている機能があるのに,外部の API を経由させるのは非効率でしょう.まぁ,PC であれば Discord は比較的常に開いている人が多いので,気付きやすいという利点がないわけでもないですが・・・
(しかしスマートフォン側でアプリさえ入れていればポップアップが出てくるので,この利点も薄いものではあります.)
通知を受信させるためにコミュニティを開いているというなら話は別ですが,そんなことはまぁしないでしょう.

2 つめの「参加者が個別に通知の受信を制御することができない」について.
関連する内容を先にも述べましたが,コミュニティ運営側から通知を送りたい場合,受け取り手のことを考える必要があります.コミュニティ自体に関する通知であっても緊急を要しないものに @everyone を発出するのは避けるべきで,それぞれの通知内容ごとに @notify-* を作成するのが望ましいです.すべての参加者が受け取りたい内容が同じとも限りません.「これは受け取りたい.でもこれは別にいい.」ということはあらゆるパターンで起こり得ます.そこの選択肢を選ぶ権利はすべての参加者が等しく持つべきで,運営の一存で決めることはあってはなりません.

3 つめの「確実に受信させる必要のある通知と区別できない」について.
@everyone が最も強制力・影響力を持つものである以上,乱用は避けるべきです.緊急を要しないなら,せめて @here にとどめておくべきでしょう.
オオカミ少年の寓話が分かりやすい例ですが,そのような本来重要度の高いアクションを常用してしまうと,本来使うべきシーンでの効果・意味合いが薄れてしまうという問題が発生します.

@everyone を気安く使っているコミュニティが散見されますが,絶対に辞めてください.

同好の士が集まるコミュニティの場合は主に個人または少数によって運営され,特定の界隈の人が集まることが多いでしょう.
この場合,ある程度細分化してチャンネルを用意し,会話が混信しないように図らうことが多いと思いますが,あまり細かく設定しすぎても面倒なだけなので,「これとこれは明らかに別チャンネルだな」というのを整理しましょう.
加えて,フォーラムを作成しておくと都合が良いこともあります.質問・相談の場として使う例が多いでしょうか.


かなり勢いで書いたので粗もあるかとは思います.気付き次第更新していきます.

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?