give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

みんなが安心して参加できる勉強会・懇親会のために主催者ができること(自由に再利用 or 改変可能なスライド付き)

はじめに

先日、TwitterでIT勉強会や懇親会に関するこちらのツイートを拝見しました。

いやあ、勉強会や懇親会ってなかなかハードルが高いですよね。
僕も初めて勉強会に参加したときはとてもドキドキしましたし、懇親会で初対面の人とワイワイ話したりするのはいまだに苦手なのでよくわかります😅

それだけに、自分が勉強会を主催するときは、なるべく参加者のみなさんの心理的ハードルを下げたり、懇親会でひとりぼっちの人が出てきたりしないように、いろいろサポートしてあげたいなーと思っています。

ちなみに、上で紹介した2つめのツイートに出てくる「TokyoGirls.rb」は僕が主催者の一人としてかかわったイベント(Ruby勉強会)です。

techplay.jp

TokyoGirls.rbでは「ぼっち対策」をはじめ、参加者のみなさんが最初から最後まで楽しめるように、いろんな施策や工夫を実践してみました。

前回書いたエントリと多少重複するところも出てきますが、今回は安心して参加できる勉強会や懇親会のために主催者がどういうことをすればいいのか、僕がTokyoGirls.rbで実際にやった工夫を紹介していきます。

また、記事の最後にTokyoGirls.rbで実際に使用したスライドをCC BYライセンスで公開しています。
この記事で紹介した施策をご自身のイベントでも取り入れてみたい、という方はこちらもぜひご活用ください!

【もくじ】

イベントページで

勉強会やカンファレンスのコンセプトや対象レベルを明確にする

イベントページで「いったいどんな勉強会で、何が学べるのか(何を学びたい人が集まるのか)」「初心者プログラマや初参加の人でも気軽に参加してよいのかどうか」を明文化しておきましょう。

主催する人は「そんなもんイベントページを眺めたらだいたいわかるやんけ」とか「勉強会なんて誰でも自由に参加できるに決まってるやろ」と思うかもしれません。
ですが、初心者さんや今まで勉強会に行ったことがない人の心理的ハードルは思った以上に高いです。
そのため、「初心者さんや初参加の人も大歓迎ですよ」と明文化しておくことは重要です。

アンチハラスメントポリシーを用意しておく

純粋に技術の話を聞きに来たはずなのに、いざイベントが始まると技術とは無関係な部分で嫌な思いをしてしまった、ということもときどき起こるみたいです。
そういうことが起こらないようにアンチハラスメントポリシー(または行動規範、Code of Conduct)を用意しておきましょう。

TokyoGirls.rbのアンチハラスメントポリシーはCC BYライセンスで公開しているので、どなたでもこちらを自由に改変してアンチハラスメントポリシーを作成していただいて構いません。
blog.jnito.com

アンチハラスメントポリシーを用意したからといって、ハラスメント行為を100%防げるとは考えていませんが、それでも「運営者は何も言いません。みなさんの自由意志にすべてお任せします」とするよりも、その確率を減らせると思います。

また、「運営としてハラスメント行為は看過することはありませんよ」という意思を明確にすることで、「もし勉強会に行って嫌な思いをしたらどうしよう」と考えている人の心理的ハードルを下げる効果も期待できます。

参加アンケートを採る

多くのイベント告知サービスでは参加時にアンケートを集めることができます。
このとき、以下のような内容を聞いておくと良いかもしれません。

  • プログラミングの経験年数は?
  • 勉強会の参加回数は?
  • 自称コミュ障ですか?

このアンケート結果は勉強会当日に利用します。
利用方法は後述します。

(オプション)女性専用枠を用意する

「勉強会に参加してみたいけど、女性がほとんどいなかったらどうしよう」と不安に思う女性の方も結構おられるようです。

イベントページで「女性の方も大歓迎です」と書くのもひとつの手ですが、端から見ると「大歓迎だからといって、他にも女性がたくさん来る保証はない」と思われてしまい、実はあまり効果がなかったりします。(経験者談)

そこで、TokyoGirls.rbでは女性専用枠と性別不問枠を用意しました。
こうすれば、他にも女性の参加者いることが可視化され、女性の心理的ハードルを下げることができます。

f:id:JunichiIto:20200116093211p:plain:w300

ただし、TokyoGirls.rbは「女性も参加しやすい(でも女性限定ではない)Ruby勉強会」がコンセプトだったので、こういうことがやりやすかった、という背景はあると思います。
世間一般の勉強会だと「なぜ女性専用枠?🤔」と思われそうなので、採用するのは少し難しいかもしれません。

イベント開催までの準備で

名札を用意する(できればTwitterアイコン付きで)

勉強会で参加者用の名札が用意されることは一般的だと思います。
名札がないと懇親会で相手をどう呼べばいいのか分からない(名前を聞いてもすぐ忘れてしまう)という問題が起きるので、最低限、相手の名前のわかる名札は用意しておいた方がよいでしょう。

さらに、名前だけでなく、TwitterアイコンやTwitterアカウントがわかる情報も名札に載せられると良いです。
TokyoGirls.rb Meetup vol.2では、名札に貼れるTwitterアイコンシールを用意しました。


ITエンジニアのTwitter使用率はかなり高いですし、Twitterアイコンを名札に載せておくことで「あ、このアイコン見たことあります!」と会話が生まれる可能性があります。
また、勉強会が終わったあともTwitterを見てるときに「あ、このTwitterアイコンはあの勉強会でしゃべった人だ!」と気づくことがあるかもしれません。

参加者の属性も名札で表現できると、さらにベター

あとは、参加者の属性を名札や名札の紐で表現できるとさらにベターです。
参加者の属性というのは、たとえば参加者に関する以下のような項目です。

  • 一般参加者か、登壇者か、スタッフか、スポンサー関係者か
  • 自称・初心者かどうか

TokyoGirls.rbでは参加者の属性は名札下部の配色(と"STAFF"のような文字)で表現していました。

f:id:JunichiIto:20191231150401j:plain

ほかにも「自称・初心者さんには若葉マークを貼ってもらう」というようなことをしておくと、「あ、この人も私と同じ初心者さんなんだ」と安心して話しかけられるかもしれません。

どんな方法であれ、名札に載せた情報で「今、目の前にいる人が何者なのか、どんな属性の人なのか」を可視化できると、懇親会でお互いに話しかけやすくなると思います。

勉強会のオープニングで

経験の浅い人や初参加の人もたくさんいることを伝える

初心者さんや勉強会初参加の人は、「ここにいる人は全員、熟練のプログラマで、こんな超初心者は私だけかもしれない」「私以外はみんな過去に参加したことがある人で、知り合いが一人もいないのは私だけなのかもしれない」と不安に思っている可能性があります。

そこで、参加アンケートで集めたプログラミングの経験年数や勉強会の参加回数をオープニングでお知らせしましょう。
以下はTokyoGirls.rbで実際に使ったスライドです。

f:id:JunichiIto:20200116095745j:plainf:id:JunichiIto:20200116095749j:plain

このように参加者全体の経験年数や参加回数を可視化できれば、初心者さんも「よかった、初心者は私だけじゃないんだ」と安心することができます。

アンチハラスメントポリシーについてあらためて説明する

アンチハラスメントポリシーは参加者全員が事前に読んでおくことが前提になりますが、まだ読んでない人や一度読んだものの、すっかり頭の中から抜け落ちてる人がいるかもしれません。
ですので、あらためてオープニングでも簡単に説明しておきましょう。

f:id:JunichiIto:20200116100154j:plainf:id:JunichiIto:20200116100201j:plain

意図せず加害者になってしまうことを恐れる人もフォローする

アンチハラスメントポリシーの提示は「被害に遭うのが怖い」という人を安心させることができる一方で、「自分の何気ない発言で相手を傷付けてしまうかもしれない」と過剰に心配する参加者を生み出す恐れもあります。

主催者はそういう参加者をフォローしておくことも大事です。
TokyoGirls.rbでは以下のようなことをオープニングで伝えました。

  • 過剰に心配しないでください。まずは「ちょっとした心がけ」だけで十分です
  • もし、悪意なく誰かを傷つけてしまった場合、我々運営スタッフが最初からあなたを厳しく非難することはありません
  • ハラスメントが起きたときは加害者も被害者もきっとショックを受けていると思うので、我々運営スタッフは双方の参加者を全力でサポート&フォローします

f:id:JunichiIto:20200116100725j:plain

会場にいる運営スタッフを紹介する

オープニングでは会場にいる運営スタッフを紹介しておきましょう。
そして「何か困ったことがあればお近くのスタッフに何でも言ってね!!」と参加者のみなさんに伝えてください。
緊急連絡先がわかっているのとわかっていないのでは、参加者の安心感も大きく変わってくるはずです。

f:id:JunichiIto:20200116101135j:plain

懇親会で

さて、いよいよ懇親会の始まりです。
いきなり「懇親会です!みなさん楽しくご歓談ください!」で始めてしまうのではなく、参加者の緊張をほぐし、お互いに話しかけやすくなる工夫を実践しましょう。

なお、TokyoGirls.rb Meetupでは懇親会用の飲食店に移動するのではなく、会場内で飲食物を提供するスタイルの懇親会にしています。

f:id:JunichiIto:20200117072218j:plain
第1回ミートアップの懇親会の様子です

みんな自称・コミュ障であることを理解してもらう

僕が観測する限り、ITエンジニアの大半は「自称・コミュ障」です。
「あの人、いつもめっちゃ仲よさそうにいろんな人と話してるやん!」と思うような人でも、1対1で話してみると「いや〜、人と話すのは苦手なんですよねえ」とおっしゃる人が多かったりします。
かく言う僕も自称・コミュ障です。初対面の人と話すのはほんとに苦手です!!

・・・ということを知らない人も多いと思うので、懇親会が始まる前にそのことを参加者に伝えましょう。
TokyoGirls.rbでは「ぼっちが懇親会でするべき97のこと」というTogetterページからいくつかツイートを引用して紹介しました。

f:id:JunichiIto:20200116101930j:plain

もし、参加アンケートで「あなたは自称・コミュ障ですか?」というアンケートを採っていれば、その結果をこのタイミングで発表するのも効果的だと思います。
(Yes/Noで答えるだけなので、事前アンケートなしでその場で挙手してもらう、とかでもいいかも?)

そして、「コミュ障なのはお互いさまだから、ぼっちの人を見かけたら、こんにちは😃と話しかけてあげてください」と、参加者のみなさんに伝えておきましょう。

最初にグループ分けをする(アンチボッチ・グルーピング)

大勢の人が集まっている中でいきなり「さあ、みなさんご歓談ください!」とするよりも、ある程度「最初に誰と話すか」を決めておいた方が最初の会話が生まれやすいと思います。

そこでTokyoGirls.rbでは「アンチボッチ・グルーピング」と題して、参加者をある条件でグループ分けし、最初はそのグループで話してもらうようにしています。

第1回ミートアップのグループ分けの条件は「あなたが使っているエディタは何?」でした。
f:id:JunichiIto:20200116103435j:plain

第2回ミートアップのグループ分けの条件は「最初に買ったRubyの技術書は何?」でした。
f:id:JunichiIto:20200116103518j:plain

もちろん、グループの人数が一発で均等に分かれることはないので、運営スタッフは「秀丸を一度でも使ったことがある人は、こちらのグループへ!」みたいな感じで、参加者をいい感じに誘導してあげてください。

飲食物を置いておくテーブルもグループの数に合わせて用意しておくと、グループ分けがスムーズに進みます。

なお、このグループ分けはあくまで「懇親会がスタートしたときのグループ分け」であって、最初から最後までそのグループから動くな、というわけではありません。
ですので、主催者は「ある程度話したらグループを移動しても大丈夫ですよ」と参加者に伝えておきましょう。

パックマンルールを実践してもらう

パックマンルールというのは、他の人があとから入りやすいように1人分のスペースを空けておいてもらうルールのことです。
できればこのルールも実践してもらうように、参加者のみなさんにお願いしておきましょう。

f:id:JunichiIto:20200116104755j:plain

会話のテンプレートをスクリーンに映しておく

TokyoGirls.rbでは懇親会中に以下のような会話のテンプレートをスクリーン上でループ再生しています。

  • そのTwitterアイコンは何ですか? or どこで撮ったんですか?
  • 今日の勉強会で一番印象深かった発表は?
  • 使ってるエディタは?
  • よく行く勉強会はありますか?
  • プログラミング歴はどれくらいですか?
  • オススメの本は何ですか?
  • 好きなgemは何ですか?
  • Ruby以外で興味のある(or よく使う)言語やフレームワークは?
  • エンジニアになったきっかけは?
  • どんなお仕事をされていますか?
  • 自分史上最大のバグを教えてください
  • オススメのストレス解消法を教えてください
  • 健康維持のために気を付けてることはありますか?
  • 尊敬するITエンジニアや憧れのITエンジニアは誰ですか?
  • 今日のイベントはどこで知りましたか?
  • 会社に女性エンジニアは何人いますか?

f:id:JunichiIto:20200116105252j:plainf:id:JunichiIto:20200116105257j:plain

もちろん、このテンプレートのとおりに会話する必要はありませんが、口下手な人はこういうテンプレートがあった方が助かるかもしれません。

運営スタッフがぼっちの人をフォローする

運営スタッフはぼっちの人をもし見かけたら、自分から話しかけに行って、うまく他のグループの中に誘導してあげてください。
ただし、TokyoGirls.rb Meetupでは、ここまでの様々な施策が功を奏したのか、ぼっちの人を見かける機会はかなり少なかったです。

イベント終了後に

開催後アンケートを採り、運営スタッフ間でふりかえりをする

イベントが終わったら参加者にアンケートの回答をお願いしましょう。
イベント全体の満足度や感想を集め、それらをインプットにして運営スタッフでふりかえりミーティングを開催してください。

ふりかえりはKPT方式(KPT=Keep/Problem/Try)で行うのがお勧めです。
良かった点はさらに良くできないか、悪かった点は次回でどう改善できるか、みんなでアイデアを出し合いましょう。

その他

無理せず、やれることだけをやる

ここまで様々な施策や工夫を紹介してきましたが、これらを全部実践しようとするとそれなりにコスト(金銭的にも・時間的にも)がかかります。
「すべての勉強会がこうあるべきだ!」などと言うつもりは決してありません。
無理することなく、勉強会の規模や性質、スタッフの人数等に応じて、主催者一人ひとりが「いい塩梅」を模索してください。

参考までにTokyoGirls.rb Meetup vol.2の規模を載せておきます。

  • 一般参加者 68名(募集人数ベースでは83名)
  • 登壇者 8名
  • 企業スポンサー4社(無料招待した関係者=6名)
  • 運営スタッフ 7名


・・・以上が安心して参加できる勉強会・懇親会のためにTokyoGirls.rb Meetupで実践した施策や工夫でした。

お役立ち情報:自由に再利用や改変ができるスライドを公開しています

他の技術コミュニティの主催者が参考にしたり、ご自身の勉強会で引用したりできるように、TokyoGirls.rb Meetup vol.2のオープニングや懇親会で使ったスライドをCC BYライセンスで公開しています。
必要に応じてご自由にお使いください。

TokyoGirls.rb Meetup vol.2 #tokyogirlsrb - Speaker Deck

また、Keynote形式のファイルもこちらからダウンロードできますので、スライドの内容を改変したい場合はこちらをお使いください。

TokyoGirls.rb-Meetup-vol.2.key - Google ドライブ
f:id:JunichiIto:20200117232111p:plain

まとめ

というわけで、このエントリではTokyoGirls.rb Meetup vol.2での取り組みを例に挙げながら、安心して参加できる勉強会・懇親会のために主催者ができることをいろいろと紹介してみました。

とはいえ、先ほども述べたとおり、別に全部の施策を無理に実践する必要はありません。
「これなら費用対効果が高そう」と思ったものをいくつかピックアップするだけでも良いと思います。

このエントリがIT技術者向けの勉強会や懇親会を主催している方の参考になれば幸いです😊

あわせて読みたい

TokyoGirls.rb Meetup vol.2の開催レポートです。
今回のエントリには書いていない、勉強会主催者向けの知見や情報も載っているので、こちらもあわせてどうぞ。
blog.jnito.com

今回のエントリでは「アンチボッチ・グルーピング」という取り組みを紹介しましたが、もともと「アンチボッチ」というキーワードが最初に登場したのは、2011年に開催されたRubyKaigiだったそうです。
その経緯についてはこちらの記事をご覧ください。
june29.jp

託児室?名札にTwitterアイコン?アンチハラスメントポリシー?TokyoGirls.rb Meetup vol.2の工夫ポイントあれこれ #tokyogirlsrb

はじめに

去る2019年12月21日にTokyoGirls.rb Meetup vol.2を開催しました。
おかげさまでたくさんの方に参加していただき、イベントとしては大成功だったと思います😆
TokyoGirls.rb Meetupは基本的に「ふつうのRuby勉強会」なのですが、イベントを成功させるために運営としてあれこれ工夫を凝らした部分もあります。
そこで、このエントリではTokyoGirls.rb Meetup vol.2の運営上の工夫等をお伝えしていきます。

f:id:JunichiIto:20200104181127j:plain
ありがたいことに、当日の会場はほぼ満席でした!

techplay.jp

【もくじ】

TokyoGirls.rb Meetupって何?

TokyoGirls.rb Meetupを知らない方のために、簡単に特徴をまとめておきます。

  • 基本コンセプトは、女性も参加しやすい(でも女性限定ではない)Ruby勉強会
  • 登壇者は全員女性
  • 参加者は男女とも参加OK。ただし女性専用枠を設けて男女比率がなるべく半々になるようにしている
  • ママエンジニアやパパエンジニアも参加しやすいように託児室を用意(追加料金は不要)

TokyoGirls.rbの基本コンセプトは以下のエントリにも書いているので、詳しく知りたい方はこちらもご覧ください。

blog.jnito.com

さらに、今回は「女性も登壇しやすいRuby勉強会」を実現するために、登壇者を公募しました。
(招待スピーカー4名、公募スピーカー4名の計8名が登壇)

blog.jnito.com

今回の会場は株式会社SmartHRさま!

今回は株式会社SmartHRさまのイベントスペースをお借りしてイベントを開催しました。
めっちゃ広くて、めっちゃきれいで、一介のRubyコミュニティがお借りするには贅沢すぎる空間でした。

f:id:JunichiIto:20191231134033j:plain

会場の椅子を前後互い違いに並べてみました

ちあみに、会場の椅子は前後で重ならないよう互い違いに並べてみました。
つまり、こういうイメージです。

f:id:JunichiIto:20191231134433p:plain

上の図を踏まえて下の写真を見ると、前後で互い違いに並んでいるのがわかるでしょうか?

f:id:JunichiIto:20191231134807j:plain

一部の人はこの工夫に気づいてくれていたみたいで、開催後アンケートに「配慮がすごくてびっくりした」と書かかれていました✌️

託児室はイベント会場に併設されたキッズルームを使用させてもらいました

今回の託児室はイベント会場に併設されたキッズルームを使用しました。
ここもSmartHRさまのイベントスペースの一部です。(最初からキッズルームがあるなんてすごい!)


f:id:JunichiIto:20191231162353j:plain
f:id:JunichiIto:20191231162407j:plain

また、今回は託児サービスの依頼を株式会社ネス・コーポレーションさんにお願いしました。
比較的リーズナブルな料金設定にもかかわらず、とても親切かつ丁寧にお子さんたちの託児を担当してもらいました。

奥さんも大助かり?パパエンジニアや登壇者の方も託児室を利用しました

今回、託児室では合計6名のお子さんをお預かりしました。
託児室の利用には特に制限を設けていないため、イベントに関わる人であれば(定員を超えない限り)誰でも利用可能です。
今回は登壇者の方や、パパエンジニアの方も託児室を利用されていました。

勉強会の臨時託児室というと、どうしても「お母さんの利用」が最初に思い浮かびますが、お父さんが利用すると奥さんにも非常に喜んでもらえるみたいです。

しかし、今回「子供を連れて勉強会に参加してもいい?」と相談すると、逆に「えっ、いいの?」と、前のめりになって協力してくれました。

当日は家を出た11時から合流した19時まで自分の時間を過ごせたようで、合流したときには心なしか普段より機嫌が良さそうでした。
 

30歳既婚男性、1歳7ヶ月の子供を連れてTokyoGirls.rb vol2 に参加する|ken3ypa|note

f:id:JunichiIto:20200105113927p:plain
画像の引用元 https://note.com/ken3ypa/n/nb90e0dd7e2f7

ちなみに、今回はかとりえさん(@katorie)を託児室専任の運営スタッフとしてアサインさせてもらいました。
託児室運営に関わる知見はまた後日かとりえさんにまとめてもらう予定です。

2020.2.5追記:託児室運営の知見をまとめてもらいました

かとりえさんに託児室運営の知見をまとめてもらったので、詳しく知りたい方はこちらのブログをどうぞ!

katorie.hatenablog.com

Twitterアイコンシール付きの名札を用意しました

ITエンジニアはよくTwitterを使っています。
そのため「本人の顔や名前はよくしらないけど、Twitterのアイコンだけだったらなんか知ってる」という状況がよく起こります。

そこで考えました。
名札にTwitterのアイコンが出ていれば、「あ、このアイコン見たことある!」みたいな感じで会話が弾むんじゃないかと。

で、出来上がった名札がこちらです!

f:id:JunichiIto:20191231144901j:plain

登壇者や一般参加者の方の名札だとこんな感じです。


懇親会ではこちらの思惑通り、あちこちでTwitterアイコンを介した会話が生まれていたようです。
初対面の人同士でも「今からフォローさせてもらうんで、ちょっと名札見せてください!」みたいな会話している人を見かけて、「やっぱり作って良かった!」と思いました😊

名札デザインと印刷はSmartHRさま、シール作成は僕でした

ちなみにこの名札、Twitterアイコンが貼ってあるだけじゃなくて、デザインもめっちゃオシャレです。(ですよね??)
この名札のデザインと印刷もSmartHRさまのご厚意で用意していただきました。
デザイナーのNamさん、印刷をしてくださったSmartHRさま、何から何までどうもありがとうございます!

f:id:JunichiIto:20191231150401j:plain

それから、シールを作って持っていったのは僕です。
こんな手順でTwitterアイコンシールを作成しました。

  1. 申込時のアンケートで参加者のTwitterアカウントを収集する
  2. 自作のRails製アイコン収集ツールを使って、Twitter API経由で参加者のアイコン画像を集める
  3. 印刷用CSSを利用してA4用紙にアイコンを敷き詰める
  4. 100均で売ってるA4サイズのシール用紙に自宅のプリンタを使って印刷する(下記写真)
  5. ハサミで1枚ずつシールを切る

f:id:JunichiIto:20191231150300j:plain

アンチハラスメントポリシーを作って、オープニングで説明しました

みんな大人だし、わざわざ言わなくても大丈夫だろう、とは思うものの、第1回と同様にアンチハラスメントポリシーを用意して、オープニングで簡単に説明しました。
TokyoGirls.rbで用意しているアンチハラスメントポリシーの詳しい内容はこちらをご覧ください。

blog.jnito.com

なぜアンチハラスメントポリシーを用意するのか?

アンチハラスメントポリシーを用意する理由を一言で説明するのは難しいのですが、まずは参加者のみなさんに安心してほしい、という思いが一番大きいかもしれません。
すなわち、アンチハラスメントポリシーを掲げることは、「運営としてハラスメント(嫌がらせ)を看過することはありませんよ。だからみなさん安心して参加してください」という運営サイドからの明示的な意思表示だと考えています。

アンチハラスメントポリシーを用意したからといって、ハラスメントを完全に防げるとは思っていません。
それでも何も用意しないよりかは(つまり「運営は何も言いません。参加者の自由意志にすべて任せます」としてしまうよりも)、その確率を減らせると思います。
また、万一問題が起きたときにも、それはアンチハラスメントポリシーに反する行為です、と運営が指摘しやすくなります。

さらに、スタッフをオープニング時にあらかじめ紹介しておくことで、何か気になることが起きたときに参加者の人も報告や相談をしやすくなるはずです。

f:id:JunichiIto:20191231152530p:plain
オープニングでは会場に常駐している運営スタッフを紹介しました

id:takahashimさんもほぼ同じ内容をブログに書かれているので、アンチハラスメントポリシーについて深く掘り下げたい方はこちらもぜひご覧ください。

「僕は・私はハラスメントしていないか心配です」問題にどう対処するか

しかし、世の中は難しいもので、アンチハラスメントポリシーがあることで、逆に勉強会や懇親会を楽しめない人が出てくるケースもあります。
それが「僕は・私はハラスメントしていないか心配です」問題です。

この問題は文字通り、「ハラスメントはやめましょう」というメッセージを伝えることで、今度は「悪気なく誰かを傷つけてしまうかもしれない」「嫌な思いをさせるかも?と思ってまったく話ができない」と、過剰に心配してしまう人たちを生み出す問題です。

この問題は解決がなかなか難しいです。
そもそも何がハラスメントと受け止められるのかは、受け手の捉え方によっても違ってくるので、画一的に「こうすれば解決」と断言できるような模範解答はありません。

この問題については、オープニングで運営チームからこんなメッセージを発信しました。

加害者になることを過剰に恐れないでください。まずは「ちょっとした心がけ」だけ持っていれば十分です。「心がけ」があるかないか。きっとそれだけであなたの行動は変わってくるはずです。

しかし、それでもハラスメントが発生する可能性をゼロにすることはできないでしょう。

もし、悪意なく誰かを傷つけてしまった場合、我々運営スタッフが最初からあなたを厳しく非難することはありません。

交通事故が起きたときと同じように、ハラスメントが起きたときは加害者も被害者もきっとショックを受けていると思うので、我々運営スタッフは双方の参加者を全力でサポート&フォローします。

f:id:JunichiIto:20191231155101p:plain
イベント当日のオープニングで使ったスライドです

まあ、簡単に言えば「最後は我々運営スタッフがなんとかするから、ドーンとぶつかって来い!大丈夫、大丈夫!」ということです。はい。

最後は運営チームでなんとかするしかない!

「そんなこと言ったって、実際に問題が起きたらどうするの?」と思われるかもしれませんが、それはそのときになってみないとわかりません。
仮にハラスメントが起きたとしても、そこでどんなハラスメントが起きるのか、前もって予見できる人はこの世にいないでしょう。

ですが、このコミュニティは僕一人で運営しているのではなく、信頼できる運営スタッフが僕以外にもたくさんいます。
なので「何か起きてもチームで対処すればきっとなんとかなるはず」と僕は信じていました。

勉強会におけるハラスメントの話題についてはSlack上でもスタッフ同士でよく意見交換していて、認識や考え方もある程度統一できているので、それが「きっとなんとかなる」の後ろ盾になっています。

幸いハラスメント行為は発生しませんでした

幸いなことに、今回のTokyoGirls.rb Meetup vol.2ではアンチハラスメントポリシーに関連するような問題は発生せず、無事に終わらせることができました。

あえて言うなら一点、託児室をネタにしたブラックジョークっぽいツイート(保護者の方にとってあまり気分が良くない発言)を見かけたので、DM越しに僕から声を掛けて削除してもらいました。
ツイートの削除はすぐに対応してもらったので、こちらとしては特に問題視していません。
このやりとりがスムーズに進んだのは、もしかするとアンチハラスメントポリシーの件を事前に話していたおかげかもなー、と思ったりしています。

懇親会では「ぼっち対策」や雑談のネタを提供しました

第1回ミートアップと同様にアンチボッチ・グルーピング(ひとりぼっちの人が発生しないように、共通の属性でグループを作る取り組み)を実施しました。
ちなみに、今回のグルーピング条件は「最初に買ったRubyの技術書は何?」でした。

f:id:JunichiIto:20200105101053p:plain


その他にもパックマンルールを推奨したり、懇親会の雑談ネタを提供したりしていました。


参加者のみなさんの反応など

最後に、Twitterで見かけた参加者のみなさんの反応をいろいろまとめておきます。

Twitterアイコン付きの名札について



託児室について


アンチハラスメントポリシーについて


参加者の男女比について



その他、イベント全体の感想など




最後の記念撮影は「はい、each!」

懇親会が終わった後に全員で集まった記念撮影をしたのですが、そのときのかけ声はRubyの勉強会らしく「Rubyで配列をループさせるときに使うメソッドは〜?」「はい、each(イーチ)!」にしてみました。

f:id:JunichiIto:20191231161805j:plain
参加者全員で「はい、each!」しています


まとめ

というわけで、このエントリでは2019年12月21日に開催したTokyoGirls.rb Meetup vol.2について、運営者視点で工夫した点などをまとめてみました。

実は舞台裏では準備段階から直前までバタバタしていて結構大変なところもあったのですが、みなさんの反応を見ていると「大変だったけど、開催して良かったなあ」としみじみ思いました。

登壇してくださったみなさん、参加者のみなさん、どうもありがとうございました。
また今回のイベントはスポンサー企業各社の協力無しでは実現できませんでした。
会場スポンサーの株式会社SmartHRさま、および託児スポンサーのCI&T株式会社さま、トレジャーデータ株式会社さま、株式会社万葉さま、どうもありがとうございました。

次回の開催日は未定ですが、そのうちまた開催したいなと思います。
てか、できれば次は関西でやりたいですね。運営スタッフのうち2名が関西在住なので!

次回もみなさんどうぞよろしくお願いします😄

あわせて読みたい

登壇者のスライドはこちらにまとめてあります。
blog.jnito.com

イベント当日のツイートはこちらでご確認ください。
togetter.com

vol.1は今年の3月に開催しました。そのときの様子はこちらにまとめてあります。
blog.jnito.com

【書評】「Ruby on Rails 6 エンジニア 養成読本」を読んで自信をもってRails 6に移行しよう!

はじめに

id:willnetさんこと、前島真一さんから「Ruby on Rails 6 エンジニア 養成読本」という書籍をご恵贈いただきました。
前島さん、どうもありがとうございます!

f:id:JunichiIto:20200104095430j:plain

というわけで(本をいただいてからかなり時間が経ってしまいましたが)、今回は本書の書評を書いてみようと思います。

Ruby on Rails 6 エンジニア 養成読本 (Software Design plusシリーズ)

Ruby on Rails 6 エンジニア 養成読本 (Software Design plusシリーズ)

「Ruby on Rails 6 エンジニア 養成読本」のもくじ

本書の目次はこのようになっています。
Rails 6の新機能の紹介 → Rails入門記事 → フロントエンド関連の記事 → テストの話 → Rails 6で改善された機能の紹介、という流れですね。

  • 巻頭特集・ようこそRuby on Railsの世界へ ~ここが変わった! Rails 6の新機能~
  • 特集1 Rails 6ではじめるRuby on Rails再入門
    • 第1章:RubyとRailsの基礎知識
    • 第2章:Railsコマンドの基本
    • 第3章:Rails の開発を体験しよう
    • 第4章:Rails アプリケーションを公開しよう
  • 特集2 Rails 6からのイマドキ フロントエンド開発
    • 第1章:webpack へ変わったJavaScriptの管理
    • 第2章:SprocketsによるCSSの管理
    • 第3章:Railsに標準で組み込まれているJavaScript
    • 第4章:控えめなJSフレームワークStimulus
  • 特集3 Rails新時代の組み込みテスト
    • 第1章:Railsに標準で組み込まれているテストの種類と並列テスト
    • 第2章:ユニットテストでテストを書こう
    • 第3章:システムテストでアプリケーション全体の動作を確認する
  • 一般記事・押さえておきたい!Rails 6で改善された機能一覧

それでは、以下が本書の書評です。

よかったところ

Rails 6の新機能が理屈や仕組みも含めて把握できる!

僕みたいに普段Railsを使って仕事をしていて、「Rails 6が出たな〜。新機能がいっぱい追加されてるけど、ひとつひとつチェックする時間はちょっとないんだよな〜」と思ってる人には最適な内容だと思いました。

Action TextやAction Mailbox、複数データベースの利用など、Rails 6の新機能が「ほどよい深さ」で紹介されています。
「ほどよい深さ」というのは、表面的に「こんなことができるようになりました」と機能を紹介するだけでなく、それがどういうからくりで実現されているのか、というところまで説明されている、という意味です。

技術というのはやっぱり理屈をわかっていた方が、その新機能を業務で使うべきかどうかを適切に判断できたり、不具合の調査がしやすくなったりするんですよね。
そういった情報を惜しみなく載せてくれているのがありがたいなと思いました。

新機能以外の解説記事もGood!

新機能の話ばかりではなく、個人的にそこまで得意ではないフロントエンド周りの話題(Webpack/Webpackerとか)や、実務でも少しずつ使い始めているActive Storageの解説も詳しく載っているのが良かったです。
特にActive Storageについては、この本を読んで「なるほど!」と思った部分を実務に適用したりすることもできました。

惜しかったところ

経験者向けの本に振り切ってくれた方が個人的には良かったかも

あくまで「僕個人の観点においては」という注釈付きになりますが、「少し惜しかったなあ」と思うのはRailsの入門記事が本書の約3割占めていたことです。
この入門記事があることで、本書のターゲットはいったい誰?という気持ちになりました。

この記事だけかなり初心者向きすぎるんですよね。
それ以外は中級者向けというか、Rails経験者向けの内容だったので、経験者はこの入門記事からあまり学べる内容がないし、Rails初心者はこの入門記事以外はちょっとハードルが高い、という問題が起きそうな気がしました。
つまり、初心者と経験者、どちらにとっても読み飛ばすページが発生してしまう、ということです。

個人的には入門記事のページ数をぐっと減らして、経験者向けの内容をもっと増やした方が良かったんじゃないかなーと思いました。
(おそらく経験者ばかりでなくRails初心者も読者に取り込みたい、という編集者さんサイドの意向が強く働いた結果なんじゃないかなと推測しますが・・・)

まとめ

というわけで、このエントリでは「Ruby on Rails 6 エンジニア 養成読本」の書評を書いてみました。

マイナスポイントも一部書きましたが、全体としてみれば「そろそろRails 6に移行していかなきゃ」と考えているRails経験者の方(つまり、僕みたいなエンジニアのことです)には十分オススメできる内容になっていると思います。
本書を読んで自信をもってRails 6へ移行していきましょう。

Railsエンジニアのみなさんはぜひチェックしてみてください!

Ruby on Rails 6 エンジニア 養成読本 (Software Design plusシリーズ)

Ruby on Rails 6 エンジニア 養成読本 (Software Design plusシリーズ)