投稿が遅れてしまい失礼致しました。
仕事や年末の忙しさに加えて体調不良やトラブルもあり、例年以上に時間が思ったように取れず、アドベントカレンダーだというのに大晦日の投稿になってしまいました…。
本稿では、ぼくが主宰しているGotanda.pmというコミュニティと、その継続のための工夫について書きます。
Gotanda.pmとは
Gotanda.pmは五反田を拠点としたPerlエンジニアのための技術コミュニティです。
その活動の一環として Gotanda.pm Perl Technology Conference というカンファレンスを行っています。（技術の勉強を通じて交流することを目的としたものを目指しているため、あえて勉強会ではなくカンファレンスという言葉を用いています。）
そのため、とても緩い雰囲気で行われています。
カンファレンスはGotanda.pmにとっては必ずしも無くてはならないものではありませんが、
他の技術者を知る機会、また、いま他のひとが気になっている技術を知る機会、コミュニティの様子を覗く機会を提供するために開催を行っています。
カンファレンス/勉強会の開催の苦労
さて、もしあなたがコミュニティの勉強会などのイベントの主催であれば、その開催に当たってさまざまな意思決定をする必要があるでしょう。
たとえば、日程と会場、時間帯やスケジュールはどうするのか、他のイベントと日程は重なっていないか、何人まで参加できるのか、テーマはどうするか、スピーカーは何人いるべきか、募集方法はどうするか、会場等で費用が掛かる場合はどうやって工面するのか、会場での飲食は可能なのか、飲食を提供するか、参加費を徴収するか、どのように広報するのか、徴収する場合はお釣りを用意する時間と手間も確保する必要があるし、会場の準備/撤収の人員の確保、会場となるビルが施錠される時間帯がある場合はその時間帯に到着した参加者を誰がどのようにピックアップするのか、他に決めなければいけないことはないか、などなど細かいことまで含めて本当に様々なことを決める必要があります。
大きなイベントともなれば、更にスポンサーやゲスト、ノベルティやお金とスケジュールのやりくりなどもこれに加わってきます。
そして、何か問題があれば迷惑や被害を被った人から苦情が来るわけです。
つまり、多かれ少なかれ、責任を要求されます。
完全無償のボランティアで運営するコミュニティに責任を求める人もどうなんだという意見もあるでしょうけど、
迷惑や被害を被ってしまった人に対しては当事者の身を顧みれば申し訳が立たないと思う場面もあるかもしれません。特に金銭の揉め事は厄介です。
なんにせよ、そういう面倒事が起きるのは面倒なので割けたいとは誰もが思うことでしょう。
そのため、主催者は問題が最小化しつつイベントが最高になるよう、これらの意思決定をすることになります。
リスクが小さければ無視できるものも多いとはいえ、リスクの取捨選択も含めた意思決定には神経を使います。時間も使うことになるでしょう。
時間は有限です。当然、コミュニティの運営と言えども全ての時間をその準備に充てることはできません。
また、モチベーションも有限です。頑張れば乗り切ることもできるでしょうが、無限に頑張り続けるだけのモチベーションを維持することは極めて困難です。
有志で運営するものだからこそ、効率化が必要になります。
フレームワーク化する
イベントをどのように開催すれば良いのかをフレームワーク化することで意思決定すべきことをリスト化することができ、TODOを可視化しやすくなります。
また、やるべきことが見えていると行動しやすくなります。
Gotanda.pmの場合はカンファレンスの開催を3/6/9/12月に行うということを決めています。
主催者にとっては、日程の選択肢を絞りやすくなり、参加者にとっては、予定を調整しやすくなります。
また、決定事項をYAMLに記載すればconnpassへのイベント登録をほぼ全自動で行ってくれるMotherというシステムを作り、利用しています。
会場のキャパシティから、参加者枠/発表者枠などをいい感じに計算して入れたり、懇親会参加のアンケートを生成するなどの機能も持っています。
これはイベント日のスケジュールをある程度フレームワーク化しているが故に作ることができました。
ほかにも、会場や物事を決める順序など、様々なことをあらかじめ決めておくことで開催が楽になります。
Gotanda.pmではまだ実現できていませんが、誰でも開催することができるよう運営ノウハウを明文化したいと考えています。
反面、何もかもを毎度同じにしすぎると面白みが薄れる要因にもなるため、加減は必要だとは思います。
やらなくて良いことをやらない
たとえば、人数が少なくかつほぼ顔見知りのメンバーだけであれば、事前徴収せずに懇親会会場で割り勘精算などでも十分な場合もあります。トラブルが発生する可能性が低くかつ万が一問題が起きても当事者間のやりとりだけで解決できる見込みが高いためリスクが低く見積もれるためです。
さらに、金銭のやりとりが発生しなければ参加/不参加のチェックは重要ではなくなるかもしれません。
などなど、その時々の状況に応じて妥協できる点はたくさんあるはずです。
まとめ
少しづつですが、毎回少しづつ楽になってきている気がします。
簡単になりますが、これが少しでも技術コミュニティの運営を始めようとする方々、関わる方々の一助となれば幸いとなります。
さて、ここまで書いてきたことですが、これらはプログラミング原則に則ったものであることにお気づきでしょうか。
- KISS(Keep It Simple, Stupid) => シンプルに保つ
- DRY(Don't Repeat Yourself) => 手順を毎度定義せずに済むようにする
- YAGNI(You Aren't Going to Need It) => 必要になるまでやらない
プログラミング原則は技術コミュニティの運営にも役立つ！というオチで〆させて頂きます。
ありがとうございました。