give IT a try

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

プログラミングを学ぶにあたって詰まったこと 〜ソニックガーデンの伊藤さん編〜

Twitterとかを見てると、最近「プログラミングを学ぶにあたって詰まったこと」というテーマのブログ記事をよく見かけるので、僕もちょっと書いてみます。

僕が今まで「プログラミングを学ぶにあたって詰まったこと」と言えば・・・う〜ん、これと言ってぱっと思いつかないんですよねえ、プログラミングの学習自体においては。

この理由としては、

  • 辛い思い出は全部忘れた
  • 少しずつ階段を上ってきたので苦労しなかった
  • 苦労を苦労と感じなかった
  • 簡単なことしかやってないので実は何もスキルが付いてない
  • 実は天才だった

のどれかなんじゃないかと思います。はい。

強いて言うなら、SIer時代に「次はJava案件をやるからオブジェクト指向を勉強しといて」って言われて、Javaの本を買って読んだけど本を読んでもオブジェクト指向が全然ピンと来なかったことぐらいでしょうか?

しかし、この件も今思えば、「オブジェクト指向を勉強しといて」と言われた割には、結局その案件の中身はVBの焼き直しみたいなコードばかりで、オブジェクト指向の知識はさほど要求されませんでした。なので、別に何も困らなかったんですよね。

オブジェクト指向に関してはその後、めっちゃ面白いJava案件に2つほど巡り会い、優秀な先輩プログラマの手ほどきを受けながら楽しく勉強できました。
そこで「オブジェクト指向、めっちゃ面白い!」となったので、それからは自分でオブジェクト指向関連の本をめっちゃたくさん読みまくって「オブジェクト指向、完全に理解した」っていうぐらいになりました(笑)。
僕はこんな感じでオブジェクト指向を習得したので、「大変だった」「苦労した」という記憶はあまりありません。

ところで、先ほど半分ふざけたような「理由」をいくつか挙げましたが、これってふざけているようで実はホントなんじゃないかと思ったりします。

辛い思い出は忘れた

まあ、これは文字通りです。
もしかすると苦労してた時期もあったのかもしれませんが、今となっては「これ」という記憶が思い出せません。

少しずつ階段を上ってきたので苦労しなかった

最初に入ったSIer時代は「ちょっとずつ難しい課題」を与えられていた気がします。
そのぶん、成長の上昇カーブは緩やかだったかもしれませんが、ひいひい言いながら階段を上るような苦労をした記憶はありません。

苦労を苦労と感じなかった

プログラミングって楽しいんですよね。
新しい知識を学ぶのも面白いし、「よっしゃ動いた!」っていう感覚を味わうのも楽しいし。
僕は昔からプログラミングをクイズを解く感覚でやってきているので、「わかった!」とか「解けた!」っていう喜びを感じると、それまでの苦労はすべて吹っ飛ぶのかもしれません。

簡単なことしかやってないので実は何もスキルが付いてない

これは少しネガティブな理由ですが、ちょっと当てはまってるかもしれません。
コンピューターサイエンスとか、機械学習とか、そっちのガチの数学の知識が必要になりそうな領域はほとんどやってないんですよね。
もしそういう知識を習得しようとすると、「楽しい楽しい」ばかり言ってられなくなるかもしれません。

実は天才だった

一番ふざけた理由ですね(笑)。
まあ、天才は言い過ぎだと思いますが、でも僕は昔から学校の勉強は得意な方だったんで、プログラミングの学習もまあまあスムーズにできてるんじゃないかなーと思うことはあります。
学校の勉強をこなす感覚でプログラミングの学習を進められているというか。
ただし、文系出身なので、さっきも言ったように理系レベルの数学の知識を要求されると刃が立ちません😅

プログラミングの習得以外で苦労したこと

上で述べたように、プログラミングの習得ではあまり苦労した記憶はないのですが、これまでの仕事を振り返ると「いやあ、あれは大変だったなあ」と思うことはあります。
たとえば、こんな感じです。

  • 最初に入ったSIerで体験したデスマーチ案件(毎日ほぼ終電、土日も出勤が何日も続いた苦しい思い出w)
  • たちの悪い💩コードを量産しまくるくせに、自分の書いたコードに対してどこまでも自信満々で非常に扱いづらかった前職の同僚
  • ソニックガーデンに入って周りのプログラマに追いつけるようになるまでの2〜3年間

このように、大変だった思い出はいくつかあるのですが、あまり技術的な問題ではありません。
ソニックガーデンに入って大変だった思い出も「ソニックガーデンのプログラマに要求される総合力」が不足していたのが原因であって、「プログラミングそのもの」がボトルネックになってたわけじゃないんですよね。

もちろん、RailsやRSpecの知識が不足していて大変だった、という記憶はありますが、それはあくまで知識量の問題であって、Railsの○○○がなかなか理解できなくて苦労した、というわけではありません。
フレームワークやライブラリのクセに振り回されて実装に時間がかかった、という記憶もありますが、それも結局知識量や経験値だけの話だと思います。

もしこの先プログラミングで苦労する可能性があるとすれば

もうこの年になると「プログラミングはほとんど理解した」と言ってもよい・・・と思ったのですが、「いや、こういうのは苦労しそう」というトピックをいくつか思いつきました。
ひとつは先ほども言ったように、コンピューターサイエンスや機械学習など、数学的な知識やセンスが要求されそうな分野です。

あとは、関数型プログラミングのモナドやC言語のポインタなんかも現時点ではほとんど理解していません。
もしこの先、こういった知識が必要になると、「うおー、プログラミング、わからん!!」と頭を抱えたりするかもしれません。

楽しくできればそれでええやん、という開き直り?

その一方で、コンピューターサイエンスや機械学習、ポインタ等をがんばって今から覚えたいか?って言われると、そうでもないんですよね〜。
もちろん、できて困ることはないし、むしろできた方が絶対良いというのは理解できるんですが、「自分の好きな領域か?」とか「お金を稼ぐため、もしくは自分の中のコンプレックスを克服するため以上のモチベーションが果たしてあるか?」と自問自答すると、「うーん・・・」っていう感じなんですよね。
RubyやRailsは大好きで、(これでご飯が食べられるなら)このままずっとやり続けたい!!って思うんですが。

年齢的にも「この先プログラマとしてどう立ち振る舞っていくか」っていう将来のプランをそろそろ考えなきゃいけないなーと思っているので、ちょっとこのあたりはまた時間があるときにじっくり考えてみたいと思います。

ただひとつ言えるのは、自分の好きなことをやっているときは楽しいし、人から見れば苦労に見えることでも本人は苦労と感じない、ということです。
これはこれで、プログラマの仕事をやっていく上で大切にしなければならない観点のひとつなのではないでしょうか?(と言って、自分がRubyやRailsを続けたい理由を正当化してみるw)

まとめ

というわけで、このエントリでは僕自身の「プログラミングを学ぶにあたって詰まったこと」を書いてみる・・・つもりが、後半はなんかちょっとあさっての方向に議論が飛んで行ってしまいました。

まあ、どこを切り取っても僕の個人的なポエムですが、何かみなさんの参考になる点があれば幸いです😅

2019.1.22追記

そういえば、過去に僕が詰まったことを2つ思い出しました!(やっぱり忘れてたw)
その話を追記しておきます。

Rubyのブロックがわからなかった

僕が一番最初にRubyの勉強をしたのはウサギが表紙のRuby本です。
当時は仕事でRubyを使う予定はなく、個人的な趣味としてこの本を読んでいました。

プログラミングRuby―達人プログラマーガイド

プログラミングRuby―達人プログラマーガイド

この中にたしかこんなコードがブロックのサンプルコードとして載っていた気がします。

3.times do
  print "Ho! "
end
#=> Ho! Ho! Ho!

しかし、これだけ見ても「ブロック」が何なのかよくわかりませんし、それまでJavaでfor (int i = 0; i < array.length; i++)みたいなコードばかり書いていた僕は、このコードがループ処理になっていることすら想像が付きません。
しかも出力しているのが"Ho! Ho! Ho!"で、そもそも「"Ho! Ho! Ho!"って何やねん?いったい何がしたいねん??」というところから意味がわかりませんでした。(これがサンタクロースの笑い声だと知ったのは、これよりあとの話です)
結局この本は最初から最後まで「ブロックがようわからん」と思いながら読んでいた記憶があります。

・・・という思い出があるので、僕が「プロを目指す人のためのRuby入門」(通称チェリー本)を執筆したときは、当時の自分でも理解できるようにブロックについてできるだけ詳しく説明しました!!

f:id:JunichiIto:20200122072800p:plain
「プロを目指す人のためのRuby入門」4.3.2項より抜粋

RailsのルーティングとRESTの概念がわからなかった

僕がRailsを使って初めてのサンプルアプリを作ろうとしたときの話です。
何かデータをCRUDする画面を作ろうとしていたと思うのですが、

  • 新規登録はcreateアクションで、HTTPメソッドがPOST
  • 更新はupdateアクションで、HTTPメソッドがPUT/PATCH
  • 削除はdestroyアクションで、HTTPメソッドがDELETE

という関係になっていることがわからず、「えっ、えっ、どうしたらデータを更新できるの??世の中にはGETとPOSTの2種類しかないんじゃないの??」「えっ、REST?RESTって何??」といろいろ混乱した記憶があります。

しかもRailsのルーティングって、これだけでCRUDで使う5つアクションを定義できちゃうんですよね。

resources :users

これにもビックリ、というか、「routes.rbを見ても何が定義されているのかさっぱりわからん!!」と思いました。

それまでずっとStrutsを使っていて、StrutsはRESTの概念がない&アクションの定義はすべて明示的に行うWebフレームワークだったので、いろんなことが暗黙的に決まってしまうRailsの考え方に、なかなか付いていけなかった記憶があります。


あと、このエントリに書いた「僕があまり苦労しなかった理由」をもう一つ思いついたので、それも書いておきます。

わからないことはそれが必要になるまで後回しにしていた

これは比較的最近のアプローチなのですが、何かを新しいことを学ぶときに2〜3回考えてもよく理解できないことがあれば、諦めてさっさと次に進む、ということもよくやっています。
で、実際にその知識が必要になったときに、もう一度そのポイントを勉強し直します。
必要に迫られたときが一番モチベーションが高く、学習効率が良くなるので、遅延評価もしくはJust in Time(JIT)方式で勉強するのも意外とオススメです。

この学習方法については以下のエントリで詳しく説明しています。
blog.jnito.com

今回の追記は以上です!

みんなが安心して参加できる勉強会・懇親会のために主催者ができること(自由に再利用 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