IT業界における『知のインフラ』の最大のぜい弱性
はじめに
「『社外勉強会を完膚なきまでに叩き潰すたった１つの簡単な方法』というタイトルでブログを書いたんですよ。あまりのことにカッとなってね。本当に腹立ちますよね、ああいう事を平気でされると！ でも私もさすがに大人なんで、『後はボタン押すだけッッ！！！』っていうすんでのところで思いとどまって、そのまま放置しているんです。」
という話を、先週飛び入り参加した「とあるIT勉強会コミュニティの定例会議の皮を被った『餃子を食って騒ぐだけの飲み会』」で伺いました。その方がもしかしたら今後その記事を公開してくれるかもしれないので、「社外勉強会を完膚なきまでに叩き潰すたった１つの簡単な方法」に言及するのはここまでにしとこうかと思います。本エントリではその答えそのものは触れないつもりですが、内容的にはほぼ正解が分かる様な内容まで書くつもりです、そのかわりめっちゃくちゃ長文だけど。明確な「正解」が簡潔に知りたいは、今すぐこのエントリを表示しているブラウザタブを閉じて、前述の方がブログ公開してくれるのをじっとお待ち下さい。(いつまで待っても公開されない可能性もあるけど、笑)
それではよろしくどーぞ。
IT勉強会ブーム・・・？
IT業界では社外勉強会がブームと言われて久しいです。
東京都内では規模の大小を抜きにすれば平日休日問わず毎日必ず複数のIT勉強会イベントが開催されています。HTML5j.orgとか話題の技術トピックを扱う勉強会は、募集開始後わずか数時間で100人超の枠が満席になりますし、DevLOVE2012やスクラム道EXPO 2012のようなコミュニティ主催の有料イベントながら多数の参加者が集まるものも出て来ています。先日開催されたデブサミ2013では個人や企業ではなくIT勉強会コミュニティが数多くセッションを持っていました。都市部だけではなく、地方でも勉強会が開催されるのも最近は珍しくありません。
IT業界における「社外勉強会」は、既に一過性のブームなどではなく、完全に定着した「知のインフラ」と言えるのかもしれません。
ドタキャン問題
これだけ大規模にかつ頻繁に開催されるようになると、やはり問題も当然のように多発します。特に最近界隈で話題になっているのが「ドタキャン問題」。いちいち説明する必要もないでしょうが、「ドタキャン」とは直前になってイベントなどの参加を取り止める(キャンセルする)ことを指します。「土壇場キャンセル」の略語ですね。問題視されている「ドタキャン」は「参加者」、つまり勉強会にやってきて聞く側の人達が行うケースです。さすがに登壇者のドタキャンは聞いた事がないですね、あれば大問題どころじゃないけど。
オレは「DevLOVE」と「BMG Works」という勉強会コミュニティに頻繁に出席していますが、この「ドタキャン問題」は前者の「DevLOVE」の方で最近非常に問題視されているんですね。「DevLOVE」は約1,400名が参加するIT勉強会のコミュニティで、3月は週二回のペースでなんらかのイベントを開催しており、日本でもかなり大きなITコミュニティに分類されます。DevLOVEのFacebookグループに参加されている方は、もしかしたら話題にされているのを目にした事があるかもしれません。
なんでも、最近のイベントの傾向として、直前でのドタキャン率が、酷い時で50%近くになるそうです。ちゃんと連絡があったり、正規のキャンセル手続きを踏む人はまだマシで、何の連絡も無く対外的には「参加」のままで、でも当日会場には来ない、という人も10%程度いるようです。先日の「We energize us - 明日の現場を高揚させるアプローチを探す-」も、定員は40名で、この枠は一旦は満席かつキャンセル待ちまで発生したのに、当日実際に参加された方は半分程度の21名でした。この21名は申込サイト「DoorKeeper」の記録を参照していますが、既に何の連絡もなくキャンセル手続きも取らずドタキャンしていた人が数名いたのは判明しているので、もう少し参加者が少なかったはずです。(一方でドタ参もいたのかな？) このイベントはオレも運営側だったのですが、@papandaさんはじめ関係者、登壇者のお二人も非常にガッカリしていたのを目にしています。
「ドタキャン問題」の何が「問題」か？
「ドタキャン」というのは、おそらくITの勉強会に限らず、多くのイベントで問題視される問題なのでしょう。オレはそれら全てのコンテキストを分析した訳ではないので、他のものはひとまず置いておいて、今回は「『IT勉強会のドタキャン問題』の何が問題か？」にフォーカスして話を進めたいと思います。一個ずつ要素を分析して行きましょう。
当日運営の妨げになる？
ドタキャンが発生する事で、運営側になにか不利益が発生する、もしくは余計な手間が発生する、そういうことはあるのでしょうか？
これはおそらく「No」でしょう。予想以上に人が来過ぎて、席が足りない、混雑していて整理出来ない、不満が噴出する、というのなら分かりますが、予想より来場者が少なかった場合には、むしろ当日の運営側の負担としては少なくなるはずです。
唯一考えられるのは「来場者受付を設け、参加予定者が全員来場した時点で受付をクローズ、そのスタッフが別の役回りを行うことを想定している」というケースです。が、有料イベントでない限りIT勉強会できちんと受付を用意しているケースは殆どありませんし、そもそもとして「受付担当が複数の役回りをこなすことを前提としている」というのは、運営側の不手際なだけな気もします。なのでこのケースは除外。
少なくとも現時点でオレが思い付く限りでは、ドタキャンによって当日運営に余計な負担が生じる事はなさそうです。
前日までの準備の妨げになる？
続いて、「勉強会の前日までの準備」では「ドタキャン」は妨げになるのでしょうか？・・・って書き出しといてなんですけど、妨げになるわけがないですね。ドタキャンが出るのは「イベント直前」なんだから。それ以前に全てが済んでしまう「前日までの準備」に影響が及ぶはずがない。
そうはいっても一応分析してみると、勉強会の準備として「運営スタッフ」が準備しなくてはならない内容は以下のようなものが考えられます。この際「登壇者」と「運営スタッフ」は別として考えます。ここでは「運営スタッフ」と、勉強会の会場を提供してくれる企業や施設の担当者：「会場提供者」にフォーカスしましょう。
- イベントの企画
- 登壇者の選定
- 登壇者への登壇依頼
- 会場選定
- 会場使用依頼
- 打合せ(登壇者・会場提供者・運営スタッフ)
- 告知
- 告知文章の作成
- 告知メディア(ML, Facebook, Twitter, etc…)の選定
- 申込窓口(ATND, こくちーず, DoorKeeper, etc…)の選定
- 申込人数管理
- 満席の場合
- 会場調整(増席の打診)
- 増席時の告知
これらの中でドタキャン問題が絡みそうなところは、早期に満席になってしまった場合の「増席」に伴う調整です。せっかく借りた会場をお断りして別の会場を探すことまでやるケースは非常に稀ですが、会場提供者にもっと広い会議室を用意してもらう、会場提供者はもしその部屋が既に社内で使われていた場合には譲ってもらうなどの調整を行う、など少なからずコストが発生します。
が、そのコストに関しても、ドタキャンが発生する前には払い終わってしまっているので、ドタキャンが発生する頃には関係ありません。
やはり、どうも前日までの準備も関係無さそう。
登壇者の発表に影響はある？
ここまでで、運営側(会場提供者含む)にはどうも参加者のドタキャンはあまり関係無さそうです。
では、登壇者側はどうでしょうか？
登壇する人は、聴講者の人数によって話し方やプレゼン資料の作り方を変える熟練者もいるそうです。この場合「100人用に発表内容を用意したのに50人しか来なかった！」となると、確かに影響があるでしょう。ただ、IT勉強会の場合、登壇者は単なる「一エンジニア」である場合が多いので、よほど手慣れた人でない限りここまで考慮して発表出来る人というのは非常に希有です。影響がないこともないでしょうが、とりあえず無視しても大丈夫ではないかと思われます。
とりあえずここまでで、運営スタッフ、会場提供、登壇者、準備するそれぞれの、どの立場から見ても、それほどドタキャンが労力的に負担をかけるようなことは無さそうです。
・・・じゃあ誰に影響があるのさ？
コストは分かった、メンタルはどうした？
ここまでオレは、敢えて関係者の精神面は考慮せずに分析してきました。やはりここを無視して話を進める事は出来ません。というより、この「ドタキャン問題」は、この精神面に対する影響が全てといっても過言ではないでしょう。
登壇者からすれば、申込画面の「満席」の様子を見ていたならば、一度は会場が満員になる光景まで目に浮かんでいたはずです。ところが、いざ当日会場にやってきたら、会場は半分しか席が埋まっていなかったとなったら、どんなに冷静な人でもやはりショックを受けます。自分が否定された気にさえなるでしょう。
会場提供側としても、満席→増員ということになれば、二度以上会場の調整に奔走することになります。せっかく方々に調整してやっと会場を確保したのに、「前の会場のまんまで良かったじゃん！」となれば憤りを感じない方がおかしい。
そしてイベントの企画から関わるスタッフ。連絡もなく来ない、もしくは直前でキャンセルされる。せっかく準備したのに、自分たちの仕事をないがしろにされた気分になるはずです。ましてや運営スタッフは会場提供者や登壇者に交渉し、お願いして、彼らに負担を強いる形で依頼を行っています。自分たちの気持ちよりは、そうやって協力してくれた人達に申し訳ない気持ちでいっぱいになるのではないでしょうか、自分が悪い訳でもないのに。
労力や費用的には全く問題がなくても、関係者の精神・・・モチベーションと表現した方が良いかもしれません・・・をポッキリと折る。それが「ドタキャン問題」の最大の問題点です。
「ドタキャン問題」が続くとどうなるか？
では「ドタキャン問題」が続くとどうなるのでしょうか？
今のIT勉強会の殆どは、エンジニア同士の「善意」や「やる気」がきっかけで開催されています。もっと勉強したい、新しいものを知りたい、向上したい、自分の力を試したい、自分を認めてもらいたい、みんなと一緒に学びたい、仲間が欲しい、盛り上げたい、困っている人を助けたい。IT勉強会はエンジニアのモチベーションで成り立っているのです。
もちろん、それらに該当しないケースもあります。転職支援企業が主催する勉強会のように具体的に転職目的のエンジニアをピックアップすることを目的として勉強会を開催する事例も多いですし、自社のプロダクト・サービスの宣伝目的でIT勉強会コミュニティに参加する企業もあります。それにしたって、企業の「事業を推進したい」というモチベーションで成り立っているのだと思います。
でも、せっかく準備したものが、直前まで満員御礼で、開始間際になってキャンセルが続出する。・・・どんな気分だと思います？
モチベーションもへったくれもないですよね。天国から地獄に叩き付けられた気分になるでしょう。あまりに酷ければ「もう二度と勉強会なんて開催しない！」と思うかもしれません。
この辺は、社内や仲間内でイベントを開催されている方で、一生懸命呼び掛けたのに当日になって2〜3人しか集まらなかった、という経験を持つ方なら理解して貰えるかもしれません。
ではなぜ人は勉強会をドタキャンするのか？
そうは言ってもドタキャンする側にはドタキャンする側の、それ相応の理由があるはずです。だって少なくとも一度は「面白そう！」「行ってみよう！」と思ったはずですから、それを断念する理由もあって然るべきでしょう。
では、どんなケースが考えられるのでしょうか？
1.自身の体調不良
風邪、交通事故、ギックリ腰、なんでもいいんですけど、申し込んだ時点ではまさか当日そんなものになるとは思っていない人が殆どです。体調不良になってしまった場合には、勉強会どころではないのは当然です。
「日頃の体調管理が…」云々の話はひとまず無視します。
2.家族のトラブル・身内の不幸
例えば奥さんが体調を崩してしまって看病しなくてはいけない、子供が学校で大怪我をした、祖父母や親戚が亡くなった。これらのケースは、自身に不備が無くともやはり家族・親族の事情を優先させるべきでしょう。
3.障害やトラブルが発生した
IT業界には突然の障害やトラブルの発生がつきものです。お客さんが突然荒ぶったりするケースもありますね。目の前に突然降ってきた仕事をやっつけない限り、勉強会どころか家にも帰れません。これが原因で勉強会を諦めざるを得ないケースは非常に多いと思います。
4.仕事が忙しい
勉強会の参加申込が始まるのは、大体開催日の一ヶ月前です。申込時点では忙しくない、もしくは、多少忙しくても開催日までには忙しさも緩和されているだろう、と楽観的希望的観測により参加申込をしたものの、その後仕事が忙しくなってしまい、結局行けなくなってしまった、というケース。
3 のケースに非常に似ていますが、突発的に忙しくなるのと恒常的に忙しいのとでは大きな隔たりがある、とオレは思っています。
5.他の用事が入った、他の用事を入れてしまった
勉強会より優先度の高い用事を入れてしまい、勉強会の参加を見合わせるケース。突発的な商談や接待、古い友人や遠方から来た友人との再会、意中の女の子をデートを誘ったらその日その時間しか空いてなかった、etc…が考えられるでしょうか？
6.忘れていた
前述の通り、勉強会の参加申込が始まるのは、大体開催日の一ヶ月前なので、実際に開催日がやってくる頃にはすっかり忘れている場合もあるでしょう。
7.疲れた、だるい、めんどくさい
上記のどれにも当て嵌まらず、なんとなく当日になって気分が乗らない、最近仕事が忙しくて体調不良とまでは行かなくてもできれば休みたい、めんどくさい、と勉強会参加を見合わせるケースもあるかと思います。
さて、いくつか思い付くままに列挙してみましたが、大体こんなところでしょうか？
これらの場合、どうしても防ぎ様の無いのは、おそらく1〜3までだと思います。4以降は正直何らかの形で防げるはず。
例えば、4のケースはそもそもの自身の仕事の見積の甘さから来るものですから、冷静に仕事の状況を見て参加が難しそうだとちょっとでも感じたら、申込をしない・気付いた時点で出来るだけ早期にキャンセルする、という対策が打てます。
また、5のケースは、オレの場合だと「スケジュール絶対先勝ちのルール」を設けていて、先に予定が入っていれば、例えどんな重要な用事であっても元々入っていた予定を優先するようにしています。オレが過去に勉強会より他の予定を優先させたのは、部下の転職相談に乗る時のような他者の人生が大きく左右される可能性があるケースのみでした。
オレの優先順位は「家族→Jリーグ→仕事→コミュニティ→他いろいろ」なので、それを遵守するようにしています。
ちなみに、「ドタキャン」する人の大多数は「なんの連絡も寄越さず理由も書かず(利用しているサービスの設定や機能でキャンセル理由が書くことができない場合もある)申込サイトのシステムでキャンセルするだけ、もしくはキャンセル手続きも行わず当日無断欠席する、というケースが大多数だそうです。事情があって参加できないのなら堂々と「行けませんゴメンナサイ」くらい連絡すればいいものを、何の連絡もなくただただドタキャンする、それって社会人としてどうなんでしょうね？
早期に一度「満席」になることの弊害
人気のIT勉強会だと、募集開始からほんのわずかの時間で満席になってしまうことがあります。
例えば前述の「HTML5j.org」の開催する「HTML5とか勉強会」は、月一のペースで100人超の応募枠で開催されていますが、一日と経たず満席になってしまいます。「HTML5とか勉強会」は元々大きな会場を借りて開催しているので、募集時以上の増席は基本的にはなく、あとはひたすらキャンセルされるのを待つしかありません。
こうなると申し込む側の心理として「このイベントに行くかどうか迷う」余裕はありません。何度か「早めに申し込もうと思ったけどあっという間に満席になってしまって申し込めなかった」という経験をした人は、やがて「行けるかどうか分からないけど、とりあえず申し込んでおこう」と考えるようになるでしょう。
本当にイベントに参加したい、申し込んでも行けると熟考した人が参加出来ず、よく考えもせずに脊髄反射で申し込んだ人が参加枠を取得出来て結果ドタキャンする。
ではドタキャンされにくくする為に出来るだけ直前の募集開始にしたらどうなるでしょうか？ 確かに一ヶ月前に募集が始まるよりは一週間前に募集が始まった場合の方が、より具体的に予定が判明して「やっぱり行けなくなった」となるケースはかなり減少する事が予想されます。でも反対に「せっかく行きたいテーマだったけど、もう別の予定が入ってて行けない。なんでもっと早く告知を行ってくれなかった？」と言い出す人は絶対に出てきます。イベント開催者としては、ドタキャンも嫌だけど、そもそも人が集まらないことは凄く怖いはずです。だから、募集開始時期というのは、あまりイベント直前に行うことが出来ないんですね。ある程度みんなの予定の見通しが立ってない頃に告知を打たないと、逆に意味がないわけです。
「ドタキャン」する人の傾向
この間勉強会の中の人に話を聞いたところ、実は既にある程度ドタキャンする傾向を洗い出しているんだそうです。
- 募集開始後かなり早期に申込を行う人
- 募集エントリの際のアンケート入力欄の「必須項目以外」を入力しない人
だいたいこの2条件のいづれか、もしくは両方が当て嵌まるそうな。ただし、これらは「直前とはいえきちんとキャンセル手続きを踏んだ人」の傾向で、無断で欠席した人は洗い出しようがないので傾向分析ができないそうです。傾向分析しようと考えたこともあるそうですが、その為には出欠確認を行わなければならず、勉強会運営のコストが跳ね上がってしまうそうです。ジレンマですなぁ。
「ドタキャン」があまり発生しない勉強会も存在する
ここまで散々「IT勉強会イベントでドタキャンが多発している問題」について書いてきましたが、実は一方で全くドタキャンが発生していないコミュニティも存在します。例えば、オレが主に参加しているもう一方のコミュニティ「bmg works」の開催イベントは、DevLOVEと比べるとキャンセル率が低いように見受けられます。また、DevLOVEでも東京で開催している「DevLOVE無印」*1は前述の通りですが、一方で「DevLOVE関西」や「DevLOVE仙台」ではキャンセルがほぼ「0」だそうです。
これらのコミュニティには
- 開催規模が比較的小規模である
- コミュニティが結成されてから日が浅い
- 参加者同士が知り合いである場合が多い
- 参加者のモチベーションが極めて高い
という特徴が見て取れます。小規模コミュニティであるがゆえに、自分たちが発起者と近いところにいる、自分たちがコミュニティを盛り上げないといけない、という意識が高くなる事から、もっともコミュニティ・イベントが盛り下がる危険のある「イベント参加者が少ない」という事態を極力回避したい、それゆえ出来る限りイベントへ出席しようと考えているのかもしれません。
どうやって「ドタキャン」を防ぐか？
では、IT勉強会の運営スタッフは、どんな方法で「ドタキャン」を防げば良いでしょうか？ いくつか対策を考えてみたいと思います。
直前で参加意思の確認を再度行う
IT勉強会イベントの申込には、大抵の場合ATNDやDoorKeeperのようなイベント告知サービスが用いられます。これらには参加希望者にリマインドメールを送る機能が備わっています。この機能を使って、二週間前、一週間前、3日前といった具合にリマインドを出し、本当にイベントに出席出来るかどうかの意思確認を行うようにするのです。
・・・まぁ実際のところを言うと、この対策は既に取られていて、どのコミュニティでも大体リマインドメールが送られてくるようになっていますが、ほぼ全く効果がないそうです。メールの重要性が薄れているのかなんなのか知らないけれど、みんな見ないで捨ててるか、見てもすぐ忘れちゃうんでしょうかね？
ブラックリストを作成する
キャンセル手続きを取った人は、イベント告知サービスには残りますので、ここから「イベント開催当日、もしくは前日にドタキャンを行った人」に条件を絞り込んで記録し続ければ、「頻繁にイベントをキャンセルする人間の記録」つまりブラックリストを作成することが可能です。
これらを常に確認するようにすれば、申込が始まった時点で「おそらくこいつはキャンセルするだろう」と目論見を付けて以後の対応・・・増席とか・・・を行うことで被害を減少出来ます。精神的にも「こいつとこいつは多分前日にキャンセルするな」と見当がついていればショックは少ないでしょう。
しかし、これにも限界があります。キャンセル履歴から洗い出す「ブラックリスト」では限界があり、以下の人間には対応出来ないのです。
- キャンセル手続きを行わず無断欠席をする人
- イベント参加時のID(名前)を頻繁に変える人
- 他のコミュニティが運営するイベントでドタキャンを繰り返している人
出欠確認をきちんと行う
これは上記「ブラックリストを作成する」の対応出来ないパターン「1」の対応策です。
受付を設けて出欠確認を行うのは運営コストとしては大きくなりますが、そこを「必要コスト」と割り切れば、まぁ出来なくはありません。
また、 選任で受付を置かなくても、「参加される方は自分の名前に『○』を付けて下さい。」と入口に貼っておいて名簿に参加者自身が記入して貰う形にすれば、出欠確認に要するコストはかなり削減出来るでしょう。
問題点を挙げるとすれば、もし受付で出欠確認が漏れてしまうと、出席している人を「無断欠席者」としてカウントしてしまう危険がある、ということくらいでしょうか？
有料イベントにする
無料だから気安く参加出来て、気安く欠席できるわけです。だったら身銭を切って「参加費用」を払ったら、キャンセル率は下がるのではないでしょうか？
結果から言うとこれも効果がなかったそうです。金を払っていてもいなくても、別の用事を優先する人もいるでしょうし、お金を払ってしまったからこそ「金タダでくれてやったんだから後はこっちの勝手だろ」とばかりに堂々と欠席出来る、という見方も無くはありません。身銭を切る事がキャンセル抑止には働かないのは検証済みなんだそうです。
また、そもそもとして法人でも個人でも無い「ITコミュニティ」がお金を扱うというのは非常に難しいのです。残金があればどこかで管理しなくてはいけないし、利益が発生すると税金も収めなくては行けない。キャンセル者から返金を求められたら場合によっては応じなくてはいけない。世間から「金の亡者」というバッシングを受けることもあるでしょう。前述の通り、ITコミュニティというのはモチベーション駆動の要素が大きいので、金銭が発生するというのは逆にマイナス要因になりかねないんですね。
参加条件のハードルを上げる
例えば「イベント告知サービスを用いず、メールのみで申込を受け付ける」など、申込時の方法を手間がよりかかり精神的ハードルを高いものにする、といった方法です。
以前何かで読んだのですが、「男女ペア」でしか申し込めない、というイベントがあったそうです。そのイベント、平日朝7時からの開催にも関わらず欠席率が非常に低かったとのこと。「自分が行かなかったら他人に迷惑をかけてしまう」という連帯責任が生じるからかもしれませんね。
これはイベントの規模や人気度合い・対象層によっては上手く行く気がします。ただ、沢山人を集めたい場合にはそのハードルの高さが却って足枷になるかもしれませんね。
また、IT業界において社外勉強会に出席する人の割合は、全体の1〜5%程度だそうです。ドタキャン問題とは別に「もっと多くの人に外に出てほしい・参加してほしい」という視点から考えた時、参加のハードルを上げることは、非常に矛盾します。
小規模人数のイベントにする
小規模のイベント開催にすることで「あなたが来なかったらイベントが成り立たないんだよ」と訴えかける手法です。前述のドタキャン発生率が低いコミュニティも「小規模である」という条件がありました。参加者同士が知り合いなら尚のこと効果を発揮しそうな気もします。逆に言えば、一見さんにとってみれば一度ドタキャンしたりすると次回以降気まずくて参加申込さえできなくなっちゃうでしょうね。それが良いか悪いかは分かりませんが。
継続型のイベントにする
イベントが一回こっきりで終わり、ではなく、メンバーを入れ替えず最低数回は同じメンバーで開催すると最初から決めてイベントを行うというアイディアです。じょじょにメンバー同士が顔見知りになるので休みにくくなる、という傾向があります。ちょうどオレが以前参加していた「7人のアジャイルサムライ」と似た形式のイベントですね。おそらく上記「小規模人数のイベントにする」と併用するのが望ましいでしょう。
これは上手く行けば最終日の打ち上げでみんなで美味しいビールが飲めますが、徐々に参加メンバーが減って行くとかなり悲惨な末路を辿る事になります。…で、その「悲惨な末路」が高確率で待っているのがIT業界という世界です、途中で欠席してしまうと、それ以降に顔を出しづらくなってしまいますからねぇ。
告知だけは前々から行っておき、実際の募集開始はイベント直前で行う
イベント開催日までの期間を十分に設けて募集を行うと、直前でドタキャンが起こる。かといって直前で募集を行うと既に予定が入っていて参加できない。だったら、その折衷案として「前々から告知だけは行っておいて(募集ページも公開しておいて)、参加申込の募集開始はイベント開催直前(一週間前くらい？)に開始する」という方法です。対象のイベントに参加したい人でもとりあえず予定を空けておくきっかけがありますし、
唯一困りそうなのは「募集枠に対して申込数が多過ぎ、増席の手続きを取らなくてはいけない場合に、調整時間があまりない」という事態が発生しそうな気がします。まぁ「増席しません」って割り切っちゃえば良い気もしますけど。
ドタキャンを想定してある程度多めに人数枠を告知する
「このくらいのイベントならたぶん○○人くらいドタキャンが発生するだろう」とあたりをつけておいて、それを見越して「実際の席数」＋「予測ドタキャン発生数」で応募をかける、というものです。もし、予測よりドタキャン発生が少なかった時には、パイプ椅子でもどっかから調達したり、念の為に「当日来場される時間が遅い場合には立ち見になる可能性があります。」とデメリット表示を書いておくのが望ましいでしょう。
「だったら何で最初から人数通りの枠を用意しておかなかった！」と非難を浴びる覚悟は、多少なりとも必要でしょうね。
開催者が諦める
前述の通りIT勉強会イベントは、モチベーション駆動の要素が大きいです。開催者のやる気次第。気持ちひとつの問題。要は当人達が納得するかどうかだけなのです。
だったら、開催者と運営スタッフは、自分が傷つかないように「さっさと諦めちゃう」というのはどうでしょう？
所詮他人なんて信用できない。特に東京は自分さえ良ければいいと思っている輩が多過ぎる。IT業界にいる人間はコミュニケーション下手が多いと言われていますし、コンピュータの相手ばかりしてるようなろくでもない連中に、社会ではごく当たり前の「約束を守る」「時間を守る」「ほう・れん・そう」を求めるなど、どだい無理な話なんだ、と割り切って考えるのです。諦めれば人は楽になれる。自分の欲しいものだけに集中して、それ以外は一切切り捨てる。今までだって似たようなことはいくらでもあったじゃないですか、無理難題を言ってくる顧客、気位ばかり高いくせに出来の悪い後輩、高圧的でこちらの言葉に耳を貸さない上司、いやみばかり連発するお局様、それと同じに扱えばいいだけですよ。
そうやってやっていけば、ドタキャン問題に限らず、どんな問題が発生しても自分を犠牲にせずに対応できるでしょう。なあんだ、こんな簡単で素晴らしい解決策があったじゃないか！！
・・・それって、楽しいですか？
最後の切り札
以前@papandaさんがこんなことを言っていました。
「DevLOVEはたった2人から、社内勉強会として始めた。あいつとだったらもう一回最初からでもやり直せる。だから『嫌になったら最初の2人に戻ればいいや』と思っていたし、思えたからこそ、ここまでやってこれた。」*2
ITコミュニティのリーダーには、どんなコミュニティのリーダーであって一様に「終わらせる権利」を持っています。自然消滅かもしれないし、「音楽性の違い」とか人気ロックバンドのように解散宣言の後サヨナラライブをやってもいい。とにかく、その権利を誰かに引き継がない限り、今ある勉強会とコミュニティを終わらせることができます。そりゃ周囲から文句のひとつも言われるでしょうが、始めたのがその人なんだから、終わらせる権利くらい持っていたっていいでしょうよ。
「IT勉強会コミュニティはモチベーション駆動である」と繰り返し述べてきました。これは翻せば「モチベーションが無くなった時点でそのIT勉強会コミュニティは終わる」ということを示唆します。IT勉強会の開催者と運営スタッフのモチベーションを現状大きく削ぐ起因が「ドタキャン問題」であるならば、この問題が続くとどうなるかは、おのずと想像がつくと思います。
おわりに
ここまで偉そうに書いてきましたが、オレ自身「勉強会のドタキャン」を一度もしたことが無い、なんてことはありません。むしろ、申込数が圧倒的に多い分、ドタキャンしてきた数も他の人よりはるかに多いでしょう。もちろんすべて事情あってのことですが、だからと言って欠席連絡を怠って良いわけがなく、連絡をしたとしても開催者・運営スタッフのみなさんに迷惑をかけている事実には変わりがありません。本当に申し訳なく思います。
今回オレはたまたま勉強会運営スタッフと距離の近いところに顔が出せて、「社外勉強会のドタキャンが問題になっている」と聞く機会がありましたが、基本的には単なる「一参加者」です。参加者の立場で、ITの社外勉強会とそのコミュニティからは多大な恩恵を受けていますし、できればもっと盛り上がってほしいとも思っています。
冒頭で「『社外勉強会』は、既に一過性のブームなどではなく、完全に定着した『知のインフラ』と言えるのかもしれない」と述べましたが、『インフラ』と呼ぶにはあまりにもぜい弱で、ちょっとした、「モチベーション」というあまりにも不確実な理由で崩壊しかねない存在であることを、参加する我々は知っておいた方が良いかもしれません。それは単なる「一参加者」であってもです。自分たちのちょっとした気遣いで、自分が恩恵を受けているコミュニティを盛り上げたり、一方で止めを刺したりする可能性がある、という意識があるかないかで、ずいぶんと変わってくるんじゃないかと思います。
できることなら、参加者側にも運営側にも良い効果が表れるよう、それぞれに気遣える関係であるのが望ましいですね。
