NISHIO Hirokazu[日本語][English]

アート・オブ・コミュニティ勉強会

アート・オブ・コミュニティとは

- アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには
- Amazon
Ubuntuのコミュニティマネージャなどをしてきた著者Jono Baconが書いた本(日本語版2011年)
コミュニティを「立ち上げ、育て、運営し、成果につなぐ」ための実務書
現場で起きる問題をどう設計で防ぐか／起きたらどう処理するか

なぜ今読み返すか

デジタル民主主義2030(dd2030)プロジェクトの現状
- 3月にSlackなどが公開され、安野氏が3つのOSSプロダクトの定例と全体定例とに出席して強力に牽引
- 安野氏は5月に政党チームみらいを立ち上げて、何人かのエンジニアがそちらに移動・忙殺される
  - 特にOSSプロダクトの公開までの実装をしていた人は安野チーム内で都知事選後にも活動し続けていた人たちなので当然選挙期間に忙しくなる
  - dd2030は一旦速度が落ちる、選挙期間中は仕方がないよねぇという気持ち
- 7月に国政政党が成立
  - チームみらい側に行った人は国政政党としての業務で引き続き忙殺される
  - それはそうだな…
- 政党結成から半年余りが過ぎ、dd2030は一旦速度が落ちて停滞が発生したのちに新たな動きが生まれつつある
  - 政党結成前の状態に戻ることはない、現状を前提として今後をどうしていくかを考えなければならない、ということが誰の目にも明らかになってきた
- 西尾個人としては
  - 5〜7月はサポーターとしてチームみらいを応援していた
  - が、国政政党化のあと、チームみらいのエンジニアチームに入るのではなくサポーターとして緩やかなつながりに留める選択をした
  - ので、政党になったことに起因する忙しい仕事は引き受けておらず、dd2030を比較的みることができている状況
  - とはいえ自分でもdd2030以外にいくつものプロジェクトを抱えていて、dd2030にフルコミットするほどの余裕はない感じ
カリスマ的リーダーの功罪
- カリスマ的リーダーが強いリーダーシップを発揮すると物事が速く進むが、それでいいのか、という問題意識があった
  - 台湾のデジタル民主主義がAudrey Tangに依存し過ぎていたのではないか、という懸念
  - 安野チーム台湾報告会
- 一方で、特定の個人に依存しない構造は速度が遅くなるのではないか
  - OSSコミュニティにおいても結局Linus Torvaldsのような人が必要なのではないか
  - 優しい終身の独裁者
  - osdev-jpも一旦停滞を経験して、今は新たな「引っ張る人」が現れてきてうまくいっている
    - 「第二の牽引役が自然発生する」パターンがあるのは希望。ただし待っているだけで発生するとは限らないのが難所。
- Cartographerのような新しいコミュニケーション支援技術によって解決するのか？それともやっぱり強いリーダーが必要なのか？
- ここら辺を考えるにあたって、参考図書としてUbuntuのコミュニティの設計論は参考にするべきだなと考えた
  - 前LLM時代におけるコミュニティマネジメントのバイブルという認識
今回、話を広げすぎると僕のキャパが足りなくて風呂敷を畳めないのでOSSコミュニティにフォーカスする
- だけど基本的には他の形態の組織においても類似の構造はある
- ドラッカーの非営利組織の経営も混ぜて考察したかったけどキャパが足りなかった
- 成果を求めるコミュニティとそうではないコミュニティがある気がする
  - この勉強会では「成果を求める」側（何らかのアウトプットを生み、成果につなげたいコミュニティ）の話に限定する。
  - 「みんなが仲良く居心地よく、各自が満足していればOK」タイプのコミュニティ論は今回はスコープ外。

1: アート・オブ・コミュニティ
- コミュニティとは何か：
  - コミュニティを「人の集まり」ではなく、価値提供と参加の循環として捉える。
- コラボレーション駆動のエートス
2: コミュニティ計画
- 目的・価値・方針・参加者像を言語化し、運営の“迷い”を減らす
- ToDoリストに落とす
3: 風通しの良いコミュニケーション
- コミュニケーションチャンネルの構築
- コミュニケーションの場の設計、やりとりの型、参加のハードルを下げる工夫
4:プロセス:シンプルであれば持続できる
- 属人化を減らすために、手順・判断・役割分担を「シンプルに」整備する
- プロセスの再評価 - 習慣化
5: ワークフローを補助するツール
- ワークフローを回すための道具（Wiki、課題管理、VCSなど）をどう選び、どう運用に載せるか。
- バグトラッキング、ソースコード管理
6: Buzzの波を起こす
- 認知と参加を生む発信
- ニュース、イベント、SNSなどの使いどころ。
- マイクロブログ、メディア活用
7: コミュニティの評価
- コミュニティの健康状態をどう見立て、改善につなげるか
8: 運営
- 運営とリーダーシップ
- 評議会の設立、Ubuntuの運営体制
- ガバナンス／リーダーシップ
- 意思決定、役割、権限、透明性、スケールのさせ方。
9: 対立への対処
- 荒れ・疲弊・燃え尽き・攻撃的行動などの扱い方（予防と介入）。
10: イベントの開催と運営
- イベントを「単発の催し」ではなくコミュニティ形成の装置として設計・実行する。
- スプリント、サミット、アンカンファレンス

コミュニティとは

同じ場所にいて集団(グループ)を形成するだけではなく、メンバー同士の相互作用が重要
人々はなぜ一緒に行動するのか：それは「一体感」があるから。
- 強いコミュニティを作るにはまず一体感を考えるべきで、一体感がなければコミュニティではない。
一体感の定義：この本では「ポジティブな信用経済による、ポジティブな成果」と定義する。
- 「成果を生み出す」が「共通の製品」でなく、個々人の興味が満たされる／個々人の制作物がうまくいく、でもいいのかな
  - LLM時代のOSSでは「中心に巨大な共通プロダクトがある」前提が崩れるケースが増える気がしている。
    - 中心がソースコードではなく、参照実装・テンプレ・プラグイン・ドキュメント・人材プール（質問できる人がいる）など“再利用可能な知見”になりうる。
  - 一つのコミュニティがあって、個人がコミュニティに溜まった知見をもとにそれぞれプロダクトを作る形のOSSプロジェクト、と整理できそう
    - その整理はアリ。「複数プロジェクトが並行し、知見が薄く共有される」形を前提に設計する、という話にもつながる（後半の「プロジェクトの束としてのコミュニティ」）。
資本主義経済の強さを豊かさや生活水準で測るように、信用経済の強さは“一体感の強さ”で測る。
相互作用と一体感の関係は？
相互作用と一体感は、原因→結果→強化のループ関係です。
- 相互作用（会話・やりとり）が起きる
  - → そこで「助けてもらえた／ちゃんと返ってきた／約束が守られた」みたいな経験が積み上がる
- その積み上げが信用経済（信頼・互酬・期待の形成）を生み、「この場に属している」「一緒にやれる」という一体感になる
- 一体感が強まると、次はもっと相互作用が起きやすくなる（声をかける・参加する・貢献するコストが下がる）
- ただし重要なのは、相互作用なら何でも一体感が増えるわけではない点です。
  - 荒れた議論、無視、攻撃、搾取（片方だけが得する）みたいな相互作用は信用経済を毀損して一体感を下げる（「ここは危ない／得しない」と学習する）
  - 逆に、歓迎・感謝・フォロー・透明な意思決定のような相互作用は信用経済を育てて一体感を上げる
- なので関係を一言で言うと、相互作用は“一体感”を作る材料で、一体感は相互作用を加速するエンジン、です

コミュニティ計画

第2章: コミュニティ計画
- 1章で「コミュニティ＝相互作用と一体感（信用経済）」の話をしたうえで、2章は「じゃあ、成果に向けてどう設計していく？」を扱います
2章で繰り返し出てくる道具立てが「コミュニティToDoリスト」
- 成功に向けた施策を、抽象論ではなく“やることリスト”として表現して、チームで動ける形に落とします
まず俯瞰（2.1）して、コミュニティ内部の「塊（サブグループ）」「関係」「穴（人手が足りないところ、コミュニケーションが足りないところ）」を見つける
- 次に、その“穴”を埋めたり循環を回すために、具体タスク（ToDo）に落とす（2.5）
- 塊、関係、穴を探すの、やろうとするとすごく難しそう。
  - 全く同感。ここは「正しいことが書いてある」けど「誰が・どうやってやるか」が抜けがち。
(2.2)チーム: 一体感を生み出す構成要素
- チームはコミュニティ構造を構成するブロック(p.27)
- チームは一体感を構成する単位(p.28)
- コミュニティ中にチームが入っているイメージ？
  - Ubuntuみたいに大きいコミュニティだと、まず“中にサブグループがある”入れ子構造が自然になる。
- 「一体感のある計画」とは何か？
  - 計画が分断を強めない設計が必要
  - 構造（チーム分割）だけ作って終わりにせず、横断コミュニケーションが“起きるように保証する”ところまでを計画に含める
  - ようするにコミュニティをサブグループに分割したならグループをまたぐコミュニケーションをしっかり構築しないと分断が加速するよねと言う話
→3章のコミュニケーションの話につながる

コミュニケーション

コミュニティは「プロセス・ガバナンス・ツール」みたいな“目に見える部品”だけで回るわけではなく、その部品同士をつなぐ“間”＝コミュニケーションが品質を決める
「良いコミュニケーション」は、メンバーが同じ方向を向いて協働し、関係性を作るための土台。
壊れると混乱・誤解・不信が増え、説明待ちで疲れるか、離脱が起きる。
さらに、コミュニティの会話は検索エンジンにも拾われるので、外部からの新規参加者はログを読んで参加意欲を決める（＝コミュニケーション品質は採用面にも直結）。
- これMLがWebで公開アーカイブされてた時代の話かな？
- 2025年にはコミュニティがSlackに移動して無料版の制約でログがどんどん失われる
  - コミュニティはもう検索不能ですよね…
    - 体感そう。だから「どこを検索可能に残すか」を設計対象にする必要がある。
      - 例：ログはクローズ（安心して話せる）／Wikiはオープン（新規導線・参照用）という分業。
    - Scrapboxのオープンなプロジェクトでやったりすれば検索可能性が高まるのかな
    - オープンWiki/Scrapboxは検索性と入口づくりに効く。一方、リアルタイムの熱量はチャットが出やすいので「役割分担」が現実解。
    - ログはクローズだが、wikiはオープン、という判断をしてるケースを知ってます
    - これはいいバランスだと私は思います。
  - Discordに移行する話もよく聞く
    - 僕はPlurality本のコミュニティがDiscordで作られていたのでDiscordを使うようになったが、それ以前からもMinecraftのMODなどのサポートチャンネルとかは軒並みDiscordだった
    - osdev-jpは割と乗り換えに成功した。Slack→Discord。
  - 公開の場所にログを置かない選択をしているコミュニティも多い
    - Discordで聞く形の情報共有
    - この判断に対して不満を持つ人もいるが、どちらにもメリットがある話であり、コミュニティがログをどうするかは各コミュニティが決めること
    - チャットログ即公開は、発言にめっちゃ気を遣うようになるので、皆疲弊しそう
      - まあでも2ちゃんねるみたいに、オープンでもあまり疲弊してなさそうな場合もあります。
      - それは、それで疲弊しない人だけが書き込んでるだけなんじゃないでしょうか
      - オープン前提とクローズド前提は使い分けが必須だという感覚。
- dd2030はSlackやGitHubのログをLLMでweeklyの活動報告にまとめることを行なっている
  - どれくらい有用なのかは不明
  - いまは AI くんにまとめてもらえばよいので楽そう。
    - 活動レポートはLLMで変わる点かも
    - 週次前提の仕組みは、流量が落ちると「寂しい週報」問題が出る。月次に寄せる等の調整が必要。
    - 更新が少なければレポートを無理に出さなくてもいいのでは。更新が少ない＝キャッチアップが楽、という良い面もある。
重要な比喩「コミュニケーションチャネルは“習慣の高速道路”」
- 人は慣れた道を走りたがるので、無理に別チャネルへ矯正しようとしても失敗しがち。
どのツールを使うにせよ、コミュニケーションは friendly / clear / productive を目標にし、メンバーが“やりやすく楽しい”状態を作るべき

4章プロセス：シンプルであれば持続できる

1行まとめ
- プロセスは「目的達成のための道具」なので、シンプルにして持続させる
シンプルさは持続可能性
コミュニティが「やりたいこと」を実行できるようにする手順（プロセス）の設計がテーマ
シンプルで効果的、非官僚的なプロセスを作り、タスク遂行・協働・成果の共有を可能にすること
プロセスは「目的達成のための道具」
- プロセスが目的化すると死ぬ
  - “プロセスのためのプロセス”を作らない
- プロセス作りが「人の集団を運営（govern）する」中核
- 運営が目的を乗っ取る危険を警戒
- ルールと文書で全問題は解けない
良いプロセスの設計
- 他の人が迷わず再現できる形に、プロセスを部品分解して定義する
  - 目標
  - 対象となる関係者
  - 要件
  - 関連するステップ
  - 検証
- 短く説明できる
  - 短く言えないプロセスは、たいてい複雑すぎて破綻する（or 形骸化する）
参加の「オンランプ」を設計せよ
- この章の山場の一つが On-ramp（オンランプ）
  - オンランプ（参加の階段）を設計する
  - オンランプ＝オンボーディング？
    - yes、オンランプは高速道路のメタファーでオンボーディングは船のメタファーだね
- 参加者が戦力になるまでの“道筋”をプロセスとして設計する話
  - 参加できると知る
  - 学ぶ
  - 何をやるか分かる
  - 貢献が祝われる
プロセスは一度作って終わりじゃない（定期的棚卸し）
- 運用してみるとズレるので、フィードバックを取り、定期タイムラインに結びつけて見直す
- Ubuntu の例ではサイクルの節目やサミットで再評価
- 改善の習慣化
言いたいことはわかるがか誰がそれをやるのか…
だれがやるのか：よくある3パターン
- 1. コミュニティリーダー／コアメンバーが「最初だけ作る」
  - 立ち上げ期はこれが最短。
  - ただし燃え尽きやすいので、後で必ず移譲が必要。
- 1. 「プロセスオーナー（Steward）」を役職として置く
  - 例：オンランプ担当、意思決定プロセス担当、リリースプロセス担当…みたいにプロセスごとに担当者を置く。
  - 権力者というより「困ったらこの人に聞ける」「更新の責任者」くらいの軽さが良い。
- 1. 小さな作業部会（Working Group）で持つ
  - 1人にしない。
  - 2〜4人で「月1で棚卸し」「改善提案を出す」みたいに回す。
なるほどな〜〜
- 1. コミュニティリーダー／コアメンバーが「最初だけ作る」
  - そういう意味では立ち上げ期には安野チームのやり方である「毎週の定例会議+Google Docsでの議事録」というスタイルが導入された
  - 半年経って、もう辞めたい的なムードになってきている
    - 3つのうち1つ(いどばた)はもうなくなっている
    - ちょうど前回の広聴AIの定例会議ではそれまで回してくれていた人がもう継続したくないとのことで、一旦「ブロードリスニング本執筆プロジェクト」の部分だけの定例へと縮退した
    - 執筆プロジェクト完了後に定例が消滅するだろうなぁという気持ち
  - まあ、「じゃあ自分が司会をして定例を続けるのか」と言われると、そこまで定例が維持されることに熱意を感じてはいないから、仕方ないよなぁという気持ち
    - 誰も続ける意思がないものは続かない
- 1. 小さな作業部会（Working Group）で持つ / 1人にしない
  - 1人だと辛いよね
  - いまコミュニティ運営に関する定例を年内に行おうという感じになっているので、ここは近々改善しそう
  - 小さな作業部会ってどうやったら作れるんだろう、と考え続けてます
    - 作業部会を作ることが目的になるとダメなので、「必要性」を洗い出して、それを引っ張ってくれる人を募集する？
    - 必要に応じて生まれるものなのかも→working group

5章ワークフローを補助するツール

プロセスを回すためには、道具（ツール）選定と運用が必要
ツールは目的ではなく、ワークフローを回すための道具（選び方と載せ方が重要）
押さえる点
- コミュニケーション／タスク管理／ナレッジ共有など、用途ごとに「何が残るべきか」を決める
  - 「何が残るべきか」とは？
  - ここでの「何が残るべきか」は、ざっくり言うと“その場の会話や作業が終わったあとでも、あとから誰でも参照できる形で残しておくべき情報（＝記録・痕跡）は何か？”という意味です。
    - 第5章はワークフローの透明性を、だいたい (1)ツールへのアクセス / (2)コミュニケーション / (3)レポーティングの3つに分けています。
    - そのうえで「残すべきもの」を具体化するとこうなります：
      - 貢献（contribution）の記録：理想は「各貢献がURLで参照できる」状態。コミットや変更が追える、誰が何をしたか辿れる、という話です。
        
        誰がどうやって記録していくか難しいけど。
        
        osdev-jpに限って言えば、書きたい人が書けばいいのです。
        
        運営がすべきことは、ここに書いてほしいですっていう場所を作っておくこと。
        
        誰も書かないかもしれないけど、それを責めたり嘆いたりしてはいけない。3つ試して1つうまくいくくらいが普通なので
      - コミュニケーションのログ：会話は“後からオンラインで参照できる”のが黄金律、と書いていて、MLのアーカイブやチャットログの公開が例に出ます。
      - 活動レポート（同じページにいるための要約）：全体が今何をしているかを共有する報告。これは自然には発生しにくいので、シンプルにして参加を促す必要がある、という文脈です。
        
        これが毎週の定例会議の議事録という形で残されていた
      - 例外として、対立や個人に関わるセンシティブ案件などは、コミュニティ評議会（Community Council）的な場で非公開アーカイブが合理的な場合もある、としています。
    - 要するに、「誰かの頭の中」や「閉じた雑談」に重要情報が埋まらないように、参照可能な形で“成果・議論・決定理由”が残る設計にしようという話です。
- ツールを増やすほど参加コストが上がるので、最小限で“迷わない導線”を作る
  - 最小限で“迷わない導線”を作るには？
  - 迷わない導線：最小構成（これだけ）
    - 入口を1つに固定
      - 「まずここ」ページを1つ（README / Notion / Web）
        
        そこ以外は全部ここに誘導する（SNS、Slack固定投稿、イベント資料）
    - そのページに置くのは3ブロックだけ
      - What：このコミュは何をしてる？（1〜2文）
      - Now：いま何が動いてる？（3〜5行の箇条書きで十分）
      - Next：あなたは次に何をすればいい？（ボタン3つまで）
    - Next（ボタン）は3つまで
      - 「参加したい」→ 招待/参加方法
      - 「貢献したい」→ “最小タスク一覧”へ
      - 「提案したい/困ってる」→ Issue/フォームへ
    - 貢献の“最小タスク”は5個だけ用意
      - 例：ドキュ誤字修正、用語整理、テスト、サンプル作成、議事録要約
        
        → “やり方”も各1行で書く（例：PR出す、コメントする等）
    - 迷子を救う一文を必ず置く
      - 「迷ったら #help（or メール）に『参加したいです』と書いてください」
        
        → この“逃げ道”があると離脱が減ります。
    - さらに効く1つだけ追加するなら
      - 「24時間ルール」：入口経由の問い合わせ/提案は24h以内に一次反応する（「受け取った、担当割り当てる」だけでOK）
      - ツールは導入して終わりではなく、運用ルール（どこに何を書くか）までセットで設計する

6章 Buzzの波を起こす（認知と参加を生む）

1行まとめ
- 良い活動でも、知られなければ人は来ない（認知と参加を生む仕掛けを作る）
押さえる点
- ニュース・イベント・SNSなどを、コミュニティの目的に合わせて使い分ける
- 短期の盛り上がり（Buzz）を、継続的な参加（信用経済）につなげる設計が必要
具体的にどう設計するのか？
狙いは「良い活動をしているのに知られない」を解消して、参加・協力・採用・寄付などに繋がる“期待”を作ること。
- 設計テンプレ（Buzz設計 1枚）
  - Buzzの核（ひとことで）
    - 「誰のどんな問題を、どう良くするコミュニティか」を1文に固定（ブレると拡散しない）
  - “基地（Base）”を先に作る
    - 公式サイト/README/参加方法/FAQ/問い合わせ先/行動規範
    - SNSは基地への導線。基地がないと燃えるだけで残らない
  - ターゲットを3つに分ける（Buzz Targets）
    - 例：参加者（貢献する人）／利用者（使う人）／支援者（紹介・資金・場所）
      - → ターゲットごとに“刺さる投稿”が違う
  - Buzzサイクルを回す（週〜月のリズム）
    - 予告（次に何が起きる）
    - 実況（いま動いてる感）
    - 成果（何ができた）
    - 次の入口（今からできる小タスク）
    - この4点を毎サイクルで出す
  - 同盟（Alliances）を設計する
    - “相互に得する形”を用意：共同イベント、相互リンク、共著、コラボ企画
    - 依頼文テンプレも作っておく（担当が変わっても回る）
  - イベント/カンファの使い方を決める
    - 目的：採用？協力者探し？認知？
    - KPI：名刺交換数ではなく「次の行動（参加/Issue/申込）」に落とす
- 役割分担（最小）：Buzzオーナー1名＋素材係（成果のログを集める）1名＋投稿係（整形して出す）1名
うちのコミュニティはBuzz の活動をまったくやってないから誰でもウェルカムなのに Closed community みたいになってる。
- うちのも
- 「閉じているつもりはないのに、外からは閉じて見える」現象の実例。Buzzは“勧誘”というより「入口が見える状態」を作る作業かも？

7章コミュニティの評価（健康状態を見立て、改善につなぐ）

1行まとめ
- 健康状態を見立てないと改善できない（何を見て、どう直すか）
押さえる点
- 参加・貢献・定着・摩擦など、活動の“症状”を観察して原因に当てる
- 数値だけではなく、会話の質や「新規が入れるか」などの定性的サインも重要
もっと詳しくいうと？
- まず前提：評価は「点数付け」じゃなく「次の手当てを決める」ため - 健康診断の目的は「数値を眺めて安心/不安」じゃなくて、どこが詰まっていて、どの介入をすると効くかを決めること。 - だから設計は常に症状 → 可能性の高い原因 → 介入 → 再測定のループで考える。 - 見るべきものは4層ある（ここを押さえると迷わない） - コミュニティの健康は、だいたいこの4層で観察できます。 - 入力（流入）：新規が来ているか - 変換（参加→貢献）：来た人が動けるか - 維持（定着）：続くか／戻ってくるか - 内部摩擦（負債・対立）：進みを阻害するものが増えてないか - - まあこういうことを言い出すと、安野さんがいなくなった時点で新規の人の参加はかなり減ったと思う - 序盤がすごく多かっただけで今が妥当なペースという考え方もできる - 来た人が動けるか/続くかに関してはかなり渋いと思うな〜 - 「来た人が動けるようにドキュメントが整備されるべきだ」「そうだね！異論ない！」という感じで、具体的にドキュメントは整備されていってない感じがある - 既存のドキュメントに残ってないことに関して、新しく来た人は古参の頭の中だけにあると感じるが、古参は「ドキュメントに残ってないことは忘れている」ので自信を持ってドキュメントを書くことができない、というような感じかなぁ - 何がいけなかったのかなぁ - 開始当初の爆速の段階で毎週のログを定例に残すことはできていた、多分それが徐々に「より抽象度の高いドキュメント」に結晶化していく必要があったのだろう - が、3~5月は爆速すぎてそれに手が回らず、ドキュメント化されてない知識のあったメンバーが政党結成で急にいなくなり、どこにも情報がない状態になったと思う - 知識のあったメンバーも、もう「半年触れてないから忘れたなぁ」という感じになってると思う - ドキュメントは書くべき対象が生まれた時に血を流してでも書く必要がある、と感じてます…（そうしないともう書けない…） - LLMを使えばドキュメントが要らない世界が来る、のではなかったのか
- 症状A：新規は来るのに定着しない - 原因候補 - small task が無い（いきなり難しい） - これ難しい話だと思うんだよね - small taskはDevinに投げたらあっさり解決される - 簡単に解決できる問題を解決してない状態に維持することがストレス - AI時代の組織における若手育成の困難さみたいな話になっちゃう - UIをちょこっといじったとして、元々のA案と新しいB案のどちらがいいかを誰が判断するのか - 優しい独裁者がいない組織においては、こういう明瞭な採択基準のない変更の採用決定がグダる - small taskが可能になるようなプラグインシスシムを導入するか〜という気持ち - このタスク自体はまったくsmallでない、大変！

8章運営（リーダーシップとガバナンス）

1行まとめ
- 意思決定・役割・権限・透明性を設計し、スケールしても揉めにくくする
押さえる点
- 誰が何を決めるか（権限）と、どう決めるか（手続き）を明確にする
- 透明性は信用経済の土台（納得感が参加を支える）
- 属人化を減らすために、役割と引き継ぎ可能な運営を作る
- この章のガバナンスは、国家みたいな重い話というより「誰が何を決めるか／どう決めるか／納得できる形で記録するか」の設計です。 - コミュニティが大きくなると、善意と空気だけでは決められなくなり、逆に「決め方」が無いせいでメンバーがやりたいことを進められなくなる——その状態を解消するのが目的、という立て付けです。 - わかる〜〜 - 優しい独裁者が居るときには、その独裁者にOKを貰えばいいだけだからプロセスがシンプル - スケールが大きくなると1人の独裁者のキャパを超えるようになってファサードが必要になる→階層組織の発生
今いちばん揉めがちな決定は
揉めてない、停滞している
8章（運営・ガバナンス）的に言うと、必要なのは“裁判所”じゃなくてエンジン（役割・リズム・入口・優先順位）。
- 停滞の典型パターン（原因の当て方）
  - 次の一手が見えない：何をやれば前に進むかが曖昧
  - 入口が弱い：新規・周辺が入っても動けない（オンランプ不足）
  - オーナー不在：誰も「進める責任」を持ってない（決める人はいても動かす人がいない）
  - 成果が見えない：進捗が共有されず、やっても報われない
  - タスクが大きすぎる：最小単位に分解されてない
- 最小の“停滞脱出”設計（8章でいう運営の骨）
  - 1. 推進役を1人置く（権限じゃなく責任）
    - 役名：プロジェクト・スチュワード（期限つきでOK：まず4〜6週間）
    - 権限：大きな決定はしない
    - 責任：次の1週間の作業を見える化して前に進める
  - そんなのやりたい人いないのでは...

9章対立への対処（予防と介入）

1行まとめ
- 対立は起きる前提で、予防と介入の両方を用意する
押さえる点
- 荒れ・疲弊・燃え尽き・攻撃的行動は、信用経済を壊すので早めに扱う
- 「問題が起きにくい設計」と「起きた時の手順」を分けて整備する
目下のところ荒れたり攻撃的な人が出たりはしてない感じ
- 一般論としてはCode of Conductを定めておくことによってそれに違反した人をスピーディにBANできるようにするとかが考えられる
- そういえばCode of Conductを定めるべきだという議論があった気がするが、その後進んだんだったかな...(記憶がない)
- BAN するしないも意思決定か〜という気持ち。
  - BANの意思決定はみんなしたがらないので、やっぱりCoCからある程度機械的に判断できることが重要
  - Teal 組織の本とかでもそうだったけど、変な人が入ってきたときに追い出す(もしくは周辺に留める)仕組みについてちゃんと語らないのよね。

10章イベントの開催と運営（コミュニティ形成の装置）

1行まとめ
- イベントは単発の催しではなく、コミュニティ形成の装置として設計する
押さえる点
- スプリント／サミット／アンカンファレンスなど、目的に合わせて形式を選ぶ
- 開催前後の導線（参加→次の関与）を作ると、信用経済に繋がりやすい
- イベントがコミュニティ形成の装置というのは全く同感で、2011年の「[ネットワーク形成システムとしての未踏](/ja/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%BD%A2%E6%88%90%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%A8%E3%81%97%E3%81%A6%E3%81%AE%E6%9C%AA%E8%B8%8F)」とかで書いた - 毎年開催されることと、そこに前年の修了生が呼ばれることが本質的に重要という気持ち - [2020未踏社団:プロジェクト発生成長のプロセス](/ja/2020%E6%9C%AA%E8%B8%8F%E7%A4%BE%E5%9B%A3%3A%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E7%99%BA%E7%94%9F%E6%88%90%E9%95%B7%E3%81%AE%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9)にも書いた - ![image](https://gyazo.com/d1edcdfc4dcf194cdf5542b0211fc7cc/thumb/1000) - 個人的には未踏社団ができた頃に色々イベントを開催しようとして疲弊したのでイベント開催は自分のエネルギーの減り方が激しいからやりたくないなぁという気持ち - 鵜飼さんが頑張ってくれる未踏ジュニアとか、毎年開催されてて蓄積効果が高くて良い - Code for Japanの[Social Hack Day](/ja/Social%20Hack%20Day)も毎月開催する体制が出来上がってて素晴らしいね - あれもNotionに蓄積が起きるように設計されている

一通り読んだ

つらつら書いてきたけどなんか解決策は思いつかないなぁ
- 去年はコミュニティ疲れを感じ、今年一年は会社以外のコミュニティから離れてました…来年はどうしようかな
  - そういう「消滅」は基本的にはいいことだと思っています、私は。
    - メンバーが変われば、それに合わせて変わっていくのほうが自然なので。
    - 維持することが目的になると、一気につまらなくなるので。
  - 終わるべき時に終わることもまたコミュニティのあるべき姿…という気持ち
  - コミュニティを継続させるメリットがないのなら、自然消滅はとてもよいのです。メリットがあるなら、メリットがある人が集まって頑張ろう。
    - なにかこうしたいっていうのがあるのなら、それを前面に出して、新規コミュニティを立ち上げるくらいの気分でやるといいと思います（内部チームとして）。
  - 他の人の心をたき付けられないアイデアは、実はあんまり価値がないから、やるべきではない、という考え方もある？
    - Open Space Technologyの真髄と似てる気がする。
  - 本当に求められるなら、また同じようなコミュニティが生まれると信じてます
AIに色々聞いて色々提案はあるけど(当番制を導入するとか)、少なくとも僕はやりたくないなぁという気持ち
他の提案、例えば「入り口を一つにする」とかは、目新しくない
- コミュニティの中ですでに既知であって、誰もやっていないだけ
トップダウンリーダーシップがなくなったことによって色々変わったが、今からトップダウンリーダーシップをやったら改善するのか？というとそうでもない気がする
- - 1: 初期には強いリーダーとそれに共感する人の集まりがあった - リーダーは意思決定(=方向の取捨選択)を介して人々の方向ベクトルをそろえる働きをしていた - 求心力 - 2: リーダー不在期に個々のメンバーは自分の方向性を模索した - 点で表現するならランダムウォーク - 3: 結果として人々の方向ベクトルの分散が大きくなった
- この3の状況からトップダウンリーダーシップをしても、その「新しい方向性」に合意されにくい
  - 「我々はボランティアであって、再配置できるリソースではない」という反発が出てくる
    - from 広聴AIの方向性の議論2025-12-06
  - これが雇用関係のある企業とボランティアグループの違いだね
    - 雇用関係があると「その人が存在して活動すること」に対して支払いがあるので、「活動」を「新しい方向性」にアサインできる
    - ボランティアは自分の共感している「方向性」に自分の活動を「寄付」しているだけなので、「新しい方向性」に同意できないなら活動が寄付されない
    - 十分に人材プールが大きければ、「新しい方向性」に共感する人を見つけられる
      - 人材プールが小さければ「新しい方向性」に共感する人を発見できない
プロジェクトの束としてのコミュニティ
- これは短命なプロジェクトが時間軸方向に繰り返し実行されるコミュニティの話
- 今観察しているものは複数のプロジェクトが並行して存在している形
  - コミュニティ全体として一丸・一枚岩で何かをするのとは違う形
- - 1: プロジェクトによる濃いグループが存在している状況
  - 2: なくなって散っていく状況
  - 3: 散った先で新たなプロジェクトが形成されている状況
    - 元のグループを介して緩やかにつながっているが、アテンションは新しい濃いグループの方に向いている
      - マインドシェアは新しいグループの方が大きい
  - (注意点)この図は人を1つの点のように表現しているが、その表現だと人は一度に一つのプロジェクトにしか所属できない
    - 実際には複数の全然異なるものに所属できるし、それぞれに対するアテンションの強度は一瞬で変わる
    - 良い表現方法をまだ発見していない

アート・オブ・コミュニティ勉強会draft-v1

https://chatgpt.com/c/693fa04b-f054-832a-91bb-f9c1bcae8a26 https://chatgpt.com/c/693fc369-7444-832b-af1a-ffbde9ce552d

(C)NISHIO Hirokazu / Converted from Markdown (ja)
Source: [GitHub] / [Scrapbox]