アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

著者 : Jono Bacon 渋川よしき

• オライリージャパン (2011年5月26日発売)

作品紹介・あらすじ

コミュニティは、地域の貢献活動やオープンソースソフトウェア開発はもちろん、製品リリースのマーケティングなどを行う際にも大きな役割を果たします。ものやサービスへの愛情に起因する人々の「貢献したい気持ち」を組織として形作ることで、コミュニティは関係する人々に、ビジネス効果を含めたさまざまな機会をもたらします。本書は、信頼あるネットワークと力強いマーケティング力を持ち、常に新しいアイデアの源泉となるコミュニティの構築と維持について解説します。風通しの良いコミュニケーションのノウハウから、口コミを活用したマーケティング「Buzz」の作り方、対立への対処法、ワークフローを助けるツールまで、具体的事例を挙げて分かりやすく説明します。

感想・レビュー・書評

[akiyama924さんの感想 · 2012年4月30日]

本書は、Ubuntuのコミュニティ・マネージャーがコミュニティにまつわるありとあらゆることを形式知化しようと試みた本です。

第1章に「信用貯金」（Social capital）という言葉が出てきます。これは、コミュニティのメンバーが他の人に対して、プラスとなるような行動をしたときに、その人に増えていくものだそうです。

そして、コミュニティはこの信用貯金を交換する場だというのですね。

なるほど。これからの世の中は、貨幣よりも信用貯金の方が大切になると思いました。

[yumu19さんの感想 · 2014年3月23日]

Ubuntuコミュニティを例にとり、ボランティアコミュニティの運営手法について書かれている。
これだけの膨大な量の経験や手法をまとめていて、本当に素晴らしい本。

ただ、現状解決したいと思っている課題をこの本を読んで全て解決できたかというと、そうではない。
Ubuntuコミュニティとは組織規模もタイムスケールも違うので、状況に応じて具体的な課題解決方法を考える必要がある。

あと、たった3年ほど前の本だが、当時と今では使うツールが違うだろう。たとえば、当時Wikiを使ってまとめていた情報が、今ならGoogle Docsを使ったほうが便利なものがある。


Ubuntuコミュニティは、たくさんのエンジニアやその他のリソースに恵まれているように感じられたが、その魅力を支えているのは何なのだろう。

--
計画通りよりも偶然によって開発される
実績主義：メンバーの成果や功績、能力によって責任や承認が得られるシステム
Linux,Wikipedia,OSM,CCなどのフリーカルチャーのコミュニティ
ミッションは何か？
コラボレーションを行う機会、及び領域はどこか？
必要なスキルは何か？
ミッションステートメントは400字で。メンバーがわかるか。外部者がわかるか。やる気を引き出せるか。
目標には「達成基準」「達成のためのタスク」「責任者」の情報が含まれる
とことん話し合う。どうすれば最悪な電話ができるか？
メンバーがチームを自由に作れるようにする。事前承認不要にすると驚くべき多様性が生まれる。
ドキュメントに貢献しているメンバーがいたら、その人はドキュメントチームのコアとなる。
似たようなコミュニティの構成を真似ると良い
コミュニケーションが上手くいっているか？「タスク」「感謝」をどのように伝えるかしらべる
参加する人全員が楽しくなるようなシンプルなコミュニケーションのサンプルを提供する
最大の間違いの一つが「自分をプロのように見せる」
間違えたら素直に謝る
自転車小屋の議論
新メンバーに対して、期待していることを素直に伝える
ライティングスキル：『英語文章ルールブック』
自虐ネタで和ませる
自分が高揚するシーンから学ぶと、よい文章が書ける
プロセスとは「新メンバーが参加する手順」「貢献を行う手順」「コラボレーションする手順」「対立を解決する手順」
メンバーが意見を自由に出すことが出来、その意見がプロセスに反映されると、雰囲気はオープンになる
パブリックなコミュニケーションチャンネルやパブリックなミーティングを持つ
メンバーを増やす時、闇雲に声をかけることはせず、適切な人にだけ声をかける
継続して貢献してくれることは重要。2日間集中してその後なにもしないよりもいい。
☆継続して貢献してもらうためには、達成感を常に提供する。
そのためには、生産的であり、行った貢献がきちんと評価され、それが継続的に繰り返される。
フィードバックを集める方法、調査と1対1のディスカッション
バグ・デー　イベント
コミュニティカウンシルのコミュニケーションチャンネルだけはプライベート
内輪のグループは作るべきではない
コミュニティに対しては、伝統的なマーケティング手法が通用しない
コミュニティのすべての人に、Buzzの波の手法を学んでもらう
偉大な顧客は、偉大な顧客を作る手助けをする
マネージャーがどこに注力したとしても、コミュニティは自分たちの興味のままにコラボレーションする
一生懸命働いていることが伝わると、その人の意見は信用される
コミュニティに必要なのは、風通しとオープン性
Buzzの波を起こす秘訣は、グラスを半分だけ満たすこと
メッセージ中の重要な部分を、表題と段落に分ける
コミュニティメンバーに、楽しい気持ちや達成感、誇りなどを持ってもらう。
ソフトウェアを紹介するときには、一番紹介したい機能が一目でわかるスクリーンショットを貼る
編集者は雑誌の紙面を埋めたがっている
アンケートは、1問30秒、10問以内。
建設的な批判を合理的に受け取ることが出来ないコミュニティにならない
責任は価値のある資産。
☆責任感を利用するのではなく、彼らに責任をきちんと預けなければなりません。
メンバーとの対話を大事にしなければならない。
コミュニティリーダーとして達成したいビジョンを説明した時に、メンバーがワクワクしてくれれば、コミュニティは成功します。
コミュニティに必ずしもリーダーが必要ということはない。
ほとんどの人は運営を見てもカッコイイと思わない。運営のインフラやドキュメントを最低限にすべき。
成果を上げなかったメンバーを自然に除外するシステムを作る。
Wikiを準備して、アジェンダを公開する
他のオープンソースコミュニティと同様に、Ubuntuは民主主義ではなく実績主義
メンバーシップ承認
コミュニティのリーダーとして、一体感とファミリー感を目指す。その鍵が「イベント」
締切リストをGoogleカレンダー
多くの人が、準備に必要な時間を少なめに見積もる
優秀なまとめ役は、作業遅れを素早く見つける方法と、重要なタスクに注意を向けさせるうまい方法を知っている ← じゃあそれを教えてくれ
権限は運営チームに委譲する
イベント共通の要素がある。それらを準備すれば9割方終わり。
主催者と面識がない人ほどドタキャン率が高い
スポンサー：もとめるお金が少なければ少ないほど、より多くを得ることが出来る。
リーダー自身のTODOリストが手に負えなくなってきたら、他の人に回す
対立が発生したら正面から向き合う。無視したり、未解決なままにしてはいけない。

[奈良女子大学学術情報センターさんの感想 · 2021年9月29日]

↓貸出状況確認はこちら↓
https://opac2.lib.nara-wu.ac.jp/webopac/BB00176685

[blackhorryさんの感想 · 2020年7月21日]

多少冗長ではあるが参考になりそうなことは多い。分量半分くらいにまとめてもらえたら嬉しい

[sou (08thse)さんの感想 · 2019年10月12日]

コミュニティの運営よりのお話です。
少し抽象化すれば、チーム運営にも活用できると思いました。

[hirocsさんの感想 · 2019年8月15日]

”
＜キーフレーズ＞

＜きっかけ＞”

[別府さんの感想 · 2016年9月12日]

原書: The Art of Community
著者：Jono Bacon
訳者：渋川よしき　

【内容紹介】
　2011年05月 発行
　336ページ
　ISBN：978-4-87311-495-8
　フォーマット Print PDF

　コミュニティは、地域の貢献活動やオープンソースソフトウェア開発はもちろん、製品リリースのマーケティングなどを行う際にも大きな役割を果たします。ものやサービスへの愛情に起因する人々の「貢献したい気持ち」を組織として形作ることで、コミュニティは関係する人々に、ビジネス効果を含めたさまざまな機会をもたらします。本書は、信頼あるネットワークと力強いマーケティング力を持ち、常に新しいアイデアの源泉となるコミュニティの構築と維持について解説します。風通しの良いコミュニケーションのノウハウから、口コミを活用したマーケティング「Buzz」の作り方、対立への対処法、ワークフローを助けるツールまで、具体的事例を挙げて分かりやすく説明します。
　世界最大のオープンソースプロジェクト、Ubuntuのコミュニティマネージャとして活躍する著者が執筆した本書は、コミュニティを作りたい人、コミュニティ運営に悩む人、コミュニティの力を最大限に活用したい人、必携の一冊です。
＜https://www.oreilly.co.jp/books/9784873114958/＞

【目次】
訳者まえがき
まえがき
はじめに

1章　アート・オブ・コミュニティ
1.1　コラボレーション駆動のエートス
1.2　コミュニティの本質
1.3　コミュニケーションの基礎
1.4　チャンスをつかむ
1.5　コミュニティマネージャ：コミュニティになる
1.5.1　個性をこじ開ける
1.5.2　信用こそがすべて
1.5.3　聞くことの価値
1.5.4　エゴを避ける、さもなければ他の人があなたを避ける
1.5.5　理論vs行動：行動が勝つ
1.5.6　自分自身になる
1.6　次章に向けて

2章　コミュニティ計画
2.1　成功への計画
2.1.1　コミュニティ：俯かん視点
2.2　チーム：一体感を生み出す構成要素
2.2.1　自分の場所を見つける
2.2.2　一体感の単位
2.2.3　読み手 vs 書き手
2.2.4　実績主義
2.2.5　一緒に働くこと＝成功
2.2.6　多様性
2.3　コミュニティのデザイン
2.3.1　オープンな中で焼き上げる
2.3.2　ミッションステートメントの構築
2.3.3　戦略計画の構築
2.4　計画を書き上げる
2.4.1　ブレインストーミングのためのアイディア
2.5　一緒に綱を引く
2.5.1　チーム：分割と統治
2.6　戦略のドキュメント化
2.7　まとめ

3章　風通しの良いコミュニケーション
3.1　彼が言った/彼女が言った
3.2　コミュニケーションチャンネルの構築
3.2.1　わかりやすいコミュニケーションのための努力
3.2.2　選択、選択
3.2.3　コミュニケーションのメディア
3.3　例を示して会話の仕方を伝える
3.3.1　毎日のコミュニケーション
3.3.2　長い文章
3.4　まとめ

4章　プロセス：シンプルであれば継続できる
4.1　獲得すべきものに視線を向け続ける
4.1.1　大切なものから視線を外さないようにする
4.2　最高のプロセスを構築する
4.2.1　複雑な物を分解する
4.2.2　プロセスをじっくり考える
4.3　ニーズを査定する
4.3.1　コミュニティのサイクル
4.3.2　コミュニティの入り口
4.3.3　貢献者を評価する
4.3.4　フィードバックの管理
4.4　プロセスに賛同してもらう
4.4.1　プロセスをドキュメント化する
4.4.2　つけやすくする
4.4.3　プロセスを使用する
4.5　プロセスの再評価
4.5.1　習慣化する
4.6　次章に向けて

5章　ワークフローを補助するツール
5.1　自分のワークフローを理解する
5.1.1　役割
5.1.2　シンプルなワークフローの構築
5.1.3　コラボレーションのメカニズム
5.1.4　シンプルなワークフローのサンプル：Ubuntuのバグワークフロー
5.2　最高のインフラの構築
5.2.1　SaaS（ソフトウェア・アズ・ア・サービス）
5.3　リソース崇拝を避ける
5.4　技術コミュニティで使うツールについて考える
5.4.1　バグのトラッキング
5.4.2　ソースコード管理
5.4.3　協調編集
5.5　コミュニティの風通しの良さの維持
5.5.1　ツールアクセス
5.5.2　コミュニケーション
5.5.3　レポート
5.6　定期的なワークフローの見直し
5.6.1　構造化したフィードバックを収集する
5.7　次章に向けて

6章　Buzzの波を起こす
6.1　マインドシェア
6.1.1　マインドシェアのチャンス
6.2　Buzzの波を構成する要素
6.2.1　ミッション
6.2.2　一緒に連帯する
6.2.3　周りを動かす言葉
6.2.4　活動家になる
6.2.5　間違った行動をしないことが正しい行動
6.2.6　誠実
6.3　基地を設置する
6.3.1　狙い
6.3.2　最新情報に維持する
6.3.3　会話を作り上げる
6.3.4　オンライン化する
6.3.5　マイクロブログ
6.4　Buzzの波のサイクル
6.4.1　計画
6.4.2　ビルドアップ
6.4.3　アナウンス
6.4.4　レビュー
6.5　Buzzのターゲット
6.5.1　コミュニティのアナウンス
6.5.2　コミュニティのサポーターを増やしていく
6.6　アライアンスを作る
6.6.1　プロのメディア
6.6.2　アマチュアのメディア
6.7　まとめ

7章　コミュニティの評価
7.1　コミュニティの内省
7.2　フィードバックの基礎
7.2.1　目的の定義
7.3　フックとデータ
7.3.1　統計と自動収集のデータ
7.3.2　調査と構造化されたフィードバック
7.3.3　観察によるテスト
7.3.4　評価システム
7.3.5　一般的な認識を収集する
7.4　匿名とプライバシー
7.4.1　匿名
7.4.2　プライバシー
7.5　次章に向けて

8章　運営
8.1　責任
8.2　運営には価値がないわけではない
8.3　運営とコミュニティ
8.4　運営のケーススタディ
8.4.1　リーダーに従う
8.4.2　人々を参加させる
8.4.3　刺激を与えることを目指す
8.4.4　平穏を維持する
8.5　リーダーから学ぶ
8.5.1　独裁的でカリスマ的なリーダーシップ
8.5.2　啓蒙的独裁体制
8.5.3　委任による運営
8.6　コミュニティ・カウンシルの設立
8.6.1　評議会の設計
8.6.2　カウンシル（評議会）の設立趣意書
8.6.3　評議会メンバーの指名と選出
8.7　サンプル：Ubuntuの運営
8.7.1　まず最初に
8.7.2　Ubuntuコミュニティの体制
8.7.3　メンバーシップ
8.7.4　エスカレーション
8.8　運営の拡大
8.8.1　いつがその時かを知る
8.8.2　サブ・カウンシルを作る
8.8.3　のコミュニケーション
8.9　まとめ

9章　対立への対処
9.1　動物の本能
9.1.1　対立の構造
9.2　嵐の前の静けさ
9.2.1　議論好きな性格
9.2.2　提案に対するバリア
9.2.3　責任に関する問題
9.2.4　正当性の欠如
9.3　対立解決のプロセス
9.3.1　ファシリテーターという役割
9.3.2　対立の解決
9.4　燃え尽き症候群に対処する
9.4.1　燃え尽き症候群の発見と治療
9.4.2　ワーク・ライフバランス
9.5　まとめ

10章　イベントの開催と運営
10.1　ファミリーの価値を創造する
10.2　イベント
10.3　準備を行う
10.3.1　ステップ1：要求の理解
10.3.2　ステップ2：協力者を探す
10.3.3　ステップ3：締め切りの設定
10.3.4　ステップ4：時間を作る
10.4　物理的なイベントの準備
10.4.1　共通の要素
10.4.2　スプリントの準備
10.4.3　サミットの開催
10.4.4　アンカンファレンスの準備
10.5　スポンサーの獲得
10.5.1　自分のニーズの理解
10.5.2　スポンサーの見つけ方と対応
10.5.3　お金の取り扱い
10.6　オンラインイベントの運営
10.6.1　共通の要素
10.6.2　オンライン・ミーティング
10.6.3　オンライン・チュートリアル
10.7　まとめ

第一幕の終わり
索引

[esasaharaさんの感想 · 2014年9月7日]

オンラインコミュニティマネジメントのポイントが良く整理されている。この手のノウハウは、暗黙知のレベルにとどまっていることが多いので、役立つ。

[mikiyugoさんの感想 · 2014年3月4日]

面白い。

世にも珍しいコミュニティ、集団を扱う技術書。

ただのubunts開発の歴史と思うか、経営本と読むかは読者次第か。中途半端な経営本と比べるとよっぽど勉強になる。

[syikootwさんの感想 · 2013年7月2日]

(主にオンラインの)コミュニティの運営の仕方。ボランティアな人々との共同作業の注意点。たらたら長めだが未経験なので勉強になる。

著者はUbuntu Linuxコミュニティのとりまとめの方。英文版は公開されてる。(SNSも盛り込んだ2nd Ed.も出てる) > The Art of Community Online : http://www.artofcommunityonline.org/

一章の考え方論、真ん中へんのBuzzの使い方や、対立の解消方法、最後のイベントの立て方とかは勉強になった。この辺りは経験ある人なら無意識にしてることなんだろうけど、主催も参加もあまりしない僕には無縁きわまりない。少なくとも自分が得意なとこではないな。慣れた人を探して仲良くなろう。

逆に言うと、中盤はプロジェクトマネジメント手法的なところと被る。PMP/PMBOKとか。その辺りの違いが書いてあれば読み飛ばしできるのに。ただ本書の想定読者は、はじめてコミュニティを始める有志達。PMPなど泥臭いものは知らない方が幸せな気がするので、よい構成だと思う。