技術コミュニティを2年間運営して主宰イベントを50回開催してきた上で意識や工夫してきたこと

この記事は、「fukuoka.ex Elixir／Phoenix Advent Calendar 2021」23日目の記事です。
きのうは @tashirosota さんの記事でした！

本記事では、2021年12月23日時点、筆者が技術コミュニティを2年以上運営し主宰イベント回数50回以上を開催してきた上で「意識してきたこと」や「工夫してきたこと」、について述べます。

結論

1. 無理しない。自身の負担にならない程度でやる。
2. 「楽しいから続けている」があやしくなったら立ち止まる。ふりかえる。場合によっては、ちがう道筋を検討する。（コミュニティ運営を続けるか・主宰者であり続けるか否かの判断もここに含む）
3. 上記2点の改善を達成するために、自動化やエンジニアリング手法によって運営がラクになるしくみ、楽しくなるしくみ作りを行う。および模索しつづける。
4. 参加者の方が参加してくれているからこそコミュニティが成り立っている、このことは間違いない事実であり、この点を決して忘れないようにする。
5. Elixirや関連技術および他言語や他の技術スタックおよび関係者に対して最大限の配慮に努める。

おことわり

• 本記事で述べている話は、筆者個人の価値観に基づく内容であり、他者へ勧めるものでも、ましてや押し付けようとするものでもない です
• へーこういった価値観のオーガナイザーもいるのか、ぐらいの温度感でお読みいただけると幸いです

本記事における「技術コミュニティ」の定義

• IT技術やプログラミング言語および周辺技術に関して、学びを得たり、理解を深めたり、技術力を向上させたりすることを目的とした場であり、基本的には対価が発生することのない、継続的かつ同期コミュニケーションによるオンライン/オフライン形式の勉強会をおもな活動として行っている集まり

対象読者

• 技術コミュニティ運営者および関係者
• 何らかの技術イベントへの参加経験がある方もしくは参加検討中の方
• その他、どなたでも、技術コミュニティ運営に関し興味ある方

背景

筆者が主宰しているコミュニティの概要、および本記事を書くに至った背景は以下です。

筆者の主宰コミュニティについて

開発言語Elixirをわいわい盛り上げていく、世界に開かれた技術コミュニティ

というスローガンに基づく技術コミュニティ「kokura.ex」のオーガナイザーを、2019年10月より務めています。

kokura.exポータルサイト

• ElixirのWebフレームワーク Phoenix ベースでつくってます

kokura.exの活動事例

• kokura.ex主宰勉強会の開催数が、2021年下半期で通算 50回 を超えました
  • kokura.exラジオ
    • 最新のITや開発言語Elixirの話をする音声配信コンテンツ
  • 「ElixirドキュメントやTypespecsを書いてみよう！」勉強会
    • Elixir開発におけるドキュメント作成作法やTypespecsの書き方ノウハウ等の理解・共有を目的とした、OSS公開視野のオンライン形式による勉強会
  • Elixirもくもく会
    • もくもく会
  • 「実際に英語でCFP・プレゼンテーションを書いてみよう！」の会
    • 海外カンファレンスの英語CFPや英語プレゼンテーションをつくることをテーマとした、オンライン形式の勉強会
• kokura.ex主宰の勉強会（前項CFPの会）から発展して、筆者自身をふくむ有志4名が 海外カンファレンスにCFP提出〜登壇 するなど嬉しいこともあったりしました
  • ElixirConf US 2021
• その他、FMラジオに出演 してkokura.exのお話をしたりとか、他オーガナイザーさんとの 共同イベント したりとか、ふだんはkokura.exのslackでわいわいやったりとか、いろいろやってます

なぜ本記事を書くに至ったか

直接的なきっかけは、先日参加したオンラインイベントで、kokura.ex主宰イベント開催数が50回を突破したことについてのお話や来年の抱負語りなどしたことです。

あらためて考えてみると、「50回開催」という数は客観的にみてひとつのマイルストーンでは確かにあるよなあと、思ったりしたわけです。
区切りの良い数字でもあるので、この機会に、コミュニティ運営について自身が意識してきたり工夫してきたりしたあれこれを整理してみようと考えたのでした。

余談（Elixirってどんなふうなのかコード例）

IEx

iex()> "Elixir" |> String.graphemes() |> Enum.frequencies()
%{"E" => 1, "i" => 2, "l" => 1, "r" => 1, "x" => 1}

公式に載ってた紹介コードを拝借しました。

本編

ざっくり前半が自身に向かっているマインド、後半が他者に向かっているマインドです。

1. 無理しない

• 基本方針として、「自分自身の体調コンディションやプライベート」を「コミュニティ活動」より優先する
  • 精神的、体力的に余裕がある状態を維持するように努める
  • 余裕がない状態では、アクションがおかしくなりがちで、結果、自分も関係者もみんな不幸になると心得る
• 負荷を強く感じはじめてて、コミュニティ活動へのコミットが厳しくなってきたら、主宰イベント延期や中止の判断、コラボイベント参加への遅延参加や中座を申し出などを行う
  • この原則を設けておくことで気持ちが楽になる
  • それ以前に、こういったことが頻繁に発生するようなら根本的に何か間違っているはずなので、問題点の洗い出しや方向転換などを行う
• 自身の生活リズムに沿ったイベント設計を行う
  • 筆者は朝方なので、朝開催のイベントが多くなりがちですが、これはこれで良しとする
    • イベントが朝方であったら、朝方の参加者には向いていて助かる人もいるのでは、と割り切る
  • ただし、他コラボレーターさんとの共同イベント企画などのイレギュラーケースは当然あるため、臨機応変に動けるようにもしておく
• お金がかかることは（極力）しない
  • スポンサー付いているわけでもないし、参加費不要のイベントが基本スタンスのため、自費をジャブジャブつかってゴージャス化、とかはやらない
    • kokura.exのコミュニティサイトもHerokuリリース
      • 無料プランでなくHobbyプランにはしている
      • 無料プランもあるけど、ずっと使っているので感謝の気持ちを込めてせめてHobbyプランの料金ぐらいは、、という理由があるので自費で払わせていただいています

2. 「楽しいから続けている」があやしくなったら立ち止まる

• 楽しいからやる、が健全にコミュニティ運営を続けるカギだと最近わかってきた
  • 楽しくない状態で義務的に続けることではない
  • コミュニティ運営することで知見が得られたり、恩返しとか何かしらの貢献に繋がったりとか、楽しい以外のことがあるのも事実ではあるが、それらは副次効果とみる
• ただし、楽しく続けられる積極的な仕組みづくりや工夫は大事であり、模索するべき
  • 次項「3.」の自動化のしくみづくりもこれに関連
• これら踏まえた上で、「楽しい、がなくなったら撤退も視野」＝コミュニティ主宰者降板、コミュニティ終了宣言も、視野に入れておく
  • 上記「敗北条件」を定めておくことで、逆説的に回避意識が働いたり、工夫するモチベーションにつながる
  • 勝利条件は、「楽しく続けている状態を保持している」こと

3. 上記2点の改善を達成するために、自動化やエンジニアリング手法によって運営がラクになるしくみ、楽しくなるしくみ作りを行う

イベント通知や管理システムなど自動化まわりを整備して、人間の負担範囲をどんどん減らしていきたい

イベント管理機能

• kokura.exポータルサイトの Event ページをスクラッチ実装
  • ほとんど HTTPoison |> Jason だけでシュッと書いた

イベント通知機能

• Zapier
  • connpass / Twitter / slack 連携のため、Twitter ~ Slack をつなげるZapを作った
  • 最初にZapをつくって走らせさえすれば、connpass でイベント告知して、Twitter、kokura.exのslackチャンネル（#kokura-ex）へ自動で通知が飛ぶ経路を自動化できる

イベント内容のドキュメント化

• Notion
  • 勉強会で取り上げたコードやトピックなどを取りまとめて置いている
    • kokura.ex主宰の各イベント参加者で「見たい！」「復習のため役立てたい」と希望される方を募って、もしいたら閲覧権限を付与していく運用
    • Notionは書くのが楽しくなる機能満載
  • とはいえ現状では完全手作業の部分なので、自動化ちょっとずつ入れていきたい

わいわい音声で話す場

• Discord
  • 気軽に入ってElixir関連の話をしたりできるようにする目的でサーバー立てた
  • 複数人リアルタイム画面共有により、各人のコード画面見せ合いながらわいわいできることも強み
  • kokura.exのローカル運用ルールとして、テキストチャットは禁止している
    • テキストチャットはslackの方に集約させたいため
  • いずれ海外コミュニティと共同イベントを開催したいと考えており、これも技術選定理由
    • 筆者の観測範囲では、海外コミュニティではDiscordけっこう使われている印象
  • 余談だが、DiscordのバックエンドにはElixirも使われている
    • Elixirコミュニティ運営者として、Elixir製ツールは使いたい・応援したい気持ちもある

タスク管理

• ClickUp
  • 使い慣れてるのが技術選定理由
    • UIとかが好み
    • 好みのツール使うと楽しくなるので良い
  • 今のところ非公開運用
    • 現状のコミュニティ規模観点から、公開するメリットが特にないから非公開でタスク管理
    • 今後、コミュニティ活動報告的な意味もふくめて公開にしていっても良さそうとは思っている

現状、kokura.exで導入しているこれらの他にも、良さそうなツールがあったらどんどん使っていきたいと思っていて、

• 増えたら項目を追加します（予定）
• こんなツールもあるよ！みたいなご意見あったらぜひ聞いてみたいです

4. 参加者の方が参加してくれてるからこそコミュニティが成り立っている、このことは間違いない事実であり、この点を決して忘れないようにする

• いちばん大事な意識かもしれない
  • これについては実際に達成できているのか?が正直、自己判断つかない
  • 達成を目指し続けるしかない
  • 前項2.で「敗北条件」と言葉を選んだのは、コミュニティを閉じることは敗北ではあると自分に言い聞かせるため
    • 自分ごとだけではない、の気持ちは忘れないようにしたい
• 自分ひとりでなく、コミュニティという「チーム」だからこそ成しえられることがある、を噛み締める
  • 「早く行きたければ、ひとりで行け。遠くまで行きたければ、みんなで行け。」（アフリカのことわざ）

If you want to go fast, go alone. If you want to go far, go together.

5. Elixirや関連技術および他言語や他の技術スタックおよび関係者に対して最大限の配慮に努める

• 特に、他言語や他の技術スタックに対する言動に配慮する
  • たとえば、いわゆる言語間戦争の火種になるような発言はしない、加担もしない
  • 特定の言語や技術スタックをdisるような発言がある場所には入らない、関わらない
    • たとえ自分は発言していなくても、外の人からは同一視されると心得る
• 「こんなことも知らないのか」みたいな見下すような発言をしない、マウンテンゴリラにならない
  • 自分が言われて嫌になりそうなことは、少なくとも自分側から他者へは言わないようにする
  • 議論を避ける、こととは異なる
    • このあたりの話って「ものの言い方」の問題が大きいと思っていて、議論するならばそこでは建設的な方向に向かった議論が行われるべき、という考え
• 特定技術の原理主義的な発言をしない
  • どの技術も技術選択肢のひとつである、と冷静な目を持ち続ける
• これら踏まえた上で、推し言語・推し技術を遠慮なく推す
  • 筆者は Elixir 推しです

まとめ

くりかえしになりますが、あくまで筆者個人の価値観にもとづく話です。

できていること、まあできていること、まだできていないこと、と混ぜこぜになっており、これら含めて続けていきたいものと思っています。
もしかしたら今後も定期的に記事の内容をアップデートしていくかもしれません。

明日の「fukuoka.ex Elixir／Phoenix Advent Calendar 2021」24日目は、@zacky1972 さんの記事です。お楽しみに！