# コミュニティマネジメント ## 定義 コミュニティマネジメント(Community Management)とは、ウェブサービスの技術チーム(開発・エンジニアリング・オペレーション)とユーザコミュニティの間に立ち、両者の情報を橋渡しする実践である。『ウェブオペレーション』8 章(2011)は、この役割を担う職種を**コミュニティマネージャ**と呼び、Flickr のコミュニティディレクタだった [[Heather Champ]] へのインタビューを通じて、その仕事の中身——編集・キュレーション、オンラインイベントの主催、新機能ローンチ時のヘルプフォーラムでの告知、コミュニティからのフィードバックの技術チームへの伝達——を描く。チャンプはこの役割を「みんなをつなげる糊」と表現する。コミュニティマネジメントは技術的な障害対応そのものではなく、**障害や変更が起きたときにユーザコミュニティへどう向き合うか**という、技術書では扱われることの少ない視点を提供する(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]])。 ## コミュニケーションのフィードバックループ 8 章が描く情報伝達の構造は次のとおりである。 1. 障害発生時、修復にあたる開発者・エンジニア・オペレーションが非同期でコミュニティマネージャに進捗(修復状況・見込み時間)を伝える。 2. コミュニティマネージャがそれをコミュニティメンバへ伝える。 3. コミュニティメンバが遭遇した問題は、コミュニティマネージャを経由してオペレーションチームへ伝わる。これにより、オペレーションチームはヘルプフォーラムを直接監視する必要がなくなる。 チャンプはこれを「コミュニケーションのフィードバックループ」と呼び、聞き手のジョン・オルスポーはこれを、オペレーションや開発者が使うアラートシステム(Nagios・Ganglia・Cacti)になぞらえた——「問題が発生したら、コミュニティマネージャが知らせてくれる」。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]]) ## インシデント時の情報統制 コミュニティマネージャとエンジニアで構成する**事前確立のインシデントチーム**を持つことで、問題発生時に経営層や広報からの個別の状況確認に忙殺されずに済む。社外への告知は「内部で問題を調査中です。解決策を検討しています」という簡潔なものにとどめ、詳細な問い合わせには「インシデントマネージャと話をしてください」の一言で対応する。8 章はこれを「航空管制を設置して、適切な人が適切な量の情報を持てるようにする」と表現する。問題の存在を早期に認めることは、社外に誇張されて伝わることを防ぐ効果もある——ユーザはサイト復旧までの時間の使い方を判断するために、どんな情報でも必要としているからである。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]]) ## ローンチ時の関わり 新機能ローンチでは、プロダクト担当者・エンジニア・オペレーション・コミュニティマネージャが集まり、起こりうる問題を事前に表計算ソフトで洗い出す。コミュニティが経験すること・トリアージの方法・各チームの対応・コミュニティマネージャからコミュニティへ伝えること・広報から社外へ伝えることを役割ごとに列挙しておく。ローンチ可否と日程は「最終決定会議(go or no-go meeting)」で全員のフィードバックをもとに決定され、影響が最も大きいオペレーションチームが最終決定権を持つことが多い。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]]) ## 横断的知見 現時点で本 concept に集約されているソースは『ウェブオペレーション』8 章の 1 件のみであり、複数ソースを突き合わせて初めて見える知見はまだ蓄積されていない。関連する [[インシデント管理]] concept が集約する SRE Book(2016)の ICS(Incident Command System)は、インシデントコマンダー・オペレーション・**コミュニケーション担当(利害関係者への情報発信)**・プランニングという 4 役割を処方するが、この「コミュニケーション担当」がもっぱら想定するのは組織内外の利害関係者一般への発信であり、ユーザコミュニティ向けの発信を専任する役割としては明示的に切り出していない。8 章(2011)は、SRE Book が ICS を体系化する 5 年前の時点で、コミュニティマネージャという専任職種による**ユーザ向け情報発信の実務**(早期の簡潔な事実確認 → 詳細はエンジニアから提供され次第共有、事前確立チャネルによる経営層対応の一本化)をすでに具体的に運用していたことになる。これが ICS の「コミュニケーション担当」の先行事例と呼べるかどうかは、SRE Book 側の記述を本概念のソースとして正式に読み込み突き合わせるまでは未検証の解釈にとどまる。 ## 未解決の問い - SRE Book(2016)の ICS における「コミュニケーション担当」は、ユーザ向け(社外)発信と組織内の利害関係者向け発信を役割として区別しているか。区別していないなら、8 章のコミュニティマネージャ専任という体制は ICS より役割分解が細かいことになる。 - コミュニティマネージャとインシデントコマンダーの権限関係(誰が何を社外に発信してよいかの最終判断者)は 8 章では明示されていない。他ソースでの確認が必要。 - 8 章は 2006〜2011 年の Flickr(Yahoo! 傘下)という単一企業・単一時代の実務例にとどまる。ステータスページ(Statuspage 等の専用 SaaS)やソーシャルメディア上のインシデント告知が一般化した 2010 年代後半以降、コミュニティマネジメントの実務はどう変化したか。 - 「社外と社内の告知は似たようなものになる」という 8 章の主張(インターネット上ではユーザも社内も同じ経験をしているため)は、社内向けインシデントレポート([[インシデントレポート執筆]])が重視するナラティブの詳細さとは対照的に、社外向けリアルタイム告知はむしろ意図的に簡潔・曖昧にとどめる。この「詳細さの非対称性」は他の企業・時代の事例でも再現されるか。 ## 関連 - [[インシデント管理]] — ICS の「コミュニケーション担当」ロールとの比較対象 - [[インシデントレポート執筆]] — 事後の内部向けナラティブとの対比(詳細さの非対称性) - [[Flickr]] — 実践の舞台 - [[Heather Champ]] — Flickr の元コミュニティディレクタ、本概念の一次証言者 - [[John Allspaw]] — 聞き手。当時 Flickr のオペレーション側の当事者でもあった ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]] — ヘザー・チャンプ, 聞き手 ジョン・オルスポー, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 8 章.