キャリア戦略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を使う予定はなく、個人的な趣味としてこの本を読んでいました。単行本この中にたしかこんなコードがブロックのサンプルコードとして載っていた気がします。i++)みたいなコードばかり書いていた僕は、このコードがループ処理になっていることすら想像が付きません。Ho!"って何やねん?いったい何がしたいねん??」というところから意味がわかりませんでした。(これがサンタクロースの笑い声だと知ったのは、これよりあとの話です)結局この本は最初から最後まで「ブロックがようわからん」と思いながら読んでいた記憶があります。大型本RailsのルーティングとRESTの概念がわからなかった僕がRailsを使って初めてのサンプルアプリを作ろうとしたときの話です。新規登録はcreateアクションで、HTTPメソッドがPOST更新はupdateアクションで、HTTPメソッドがPUT/PATCH削除はdestroyアクションで、HTTPメソッドがDELETEという関係になっていることがわからず、「えっ、えっ、どうしたらデータを更新できるの??世の中にはGETとPOSTの2種類しかないんじゃないの??」「えっ、REST?RESTって何??」といろいろ混乱した記憶があります。Railsのルーティングって、これだけでCRUDで使う5つアクションを定義できちゃうんですよね。:usersこれにもビックリ、というか、「routes.rbを見ても何が定義されているのかさっぱりわからん!!」と思いました。それまでずっとStrutsを使っていて、StrutsはRESTの概念がない&アクションの定義はすべて明示的に行うWebフレームワークだったので、いろんなことが暗黙的に決まってしまうRailsの考え方に、なかなか付いていけなかった記憶があります。あと、このエントリに書いた「僕があまり苦労しなかった理由」をもう一つ思いついたので、それも書いておきます。わからないことはそれが必要になるまで後回しにしていたこれは比較的最近のアプローチなのですが、何かを新しいことを学ぶときに2〜3回考えてもよく理解できないことがあれば、諦めてさっさと次に進む、ということもよくやっています。実際にその知識が必要になったときに、もう一度そのポイントを勉強し直します。Time(JIT)方式で勉強するのも意外とオススメです。この学習方法については以下のエントリで詳しく説明しています。Rubyはじめに先日、TwitterでIT勉強会や懇親会に関するこちらのツイートを拝見しました。2020勉強会数えきれないくらい行ってるけど人見知りなので未だに懇親会苦手感ある(とっても楽しいのだけど)懇親会でTokyoGirls.rbのぼっち対策が行われた会を数件見ていて、この活動広まるといいなあ...と思ってる。2020いやあ、勉強会や懇親会ってなかなかハードルが高いですよね。僕も初めて勉強会に参加したときはとてもドキドキしましたし、懇親会で初対面の人とワイワイ話したりするのはいまだに苦手なのでよくわかります😅それだけに、自分が勉強会を主催するときは、なるべく参加者のみなさんの心理的ハードルを下げたり、懇親会でひとりぼっちの人が出てきたりしないように、いろいろサポートしてあげたいなーと思っています。ちなみに、上で紹介した2つめのツイートに出てくる「TokyoGirls.rb」は僕が主催者の一人としてかかわったイベント(Ruby勉強会)です。techplay.jpTokyoGirls.rbでは「ぼっち対策」をはじめ、参加者のみなさんが最初から最後まで楽しめるように、いろんな施策や工夫を実践してみました。前回書いたエントリと多少重複するところも出てきますが、今回は安心して参加できる勉強会や懇親会のために主催者がどういうことをすればいいのか、僕がTokyoGirls.rbで実際にやった工夫を紹介していきます。BYライセンスで公開しています。無理せず、やれることだけをやるお役立ち情報:自由に再利用や改変ができるスライドを公開していますまとめあわせて読みたいイベントページで勉強会やカンファレンスのコンセプトや対象レベルを明確にするイベントページで「いったいどんな勉強会で、何が学べるのか(何を学びたい人が集まるのか)」「初心者プログラマや初参加の人でも気軽に参加してよいのかどうか」を明文化しておきましょう。主催する人は「そんなもんイベントページを眺めたらだいたいわかるやんけ」とか「勉強会なんて誰でも自由に参加できるに決まってるやろ」と思うかもしれません。初心者さんや今まで勉強会に行ったことがない人の心理的ハードルは思った以上に高いです。そのため、「初心者さんや初参加の人も大歓迎ですよ」と明文化しておくことは重要です。アンチハラスメントポリシーを用意しておく純粋に技術の話を聞きに来たはずなのに、いざイベントが始まると技術とは無関係な部分で嫌な思いをしてしまった、ということもときどき起こるみたいです。Conduct)を用意しておきましょう。BYライセンスで公開しているので、どなたでもこちらを自由に改変してアンチハラスメントポリシーを作成していただいて構いません。blog.jnito.comアンチハラスメントポリシーを用意したからといって、ハラスメント行為を100%防げるとは考えていませんが、それでも「運営者は何も言いません。みなさんの自由意志にすべてお任せします」とするよりも、その確率を減らせると思います。「運営としてハラスメント行為は看過することはありませんよ」という意思を明確にすることで、「もし勉強会に行って嫌な思いをしたらどうしよう」と考えている人の心理的ハードルを下げる効果も期待できます。参加アンケートを採る多くのイベント告知サービスでは参加時にアンケートを集めることができます。このとき、以下のような内容を聞いておくと良いかもしれません。プログラミングの経験年数は?勉強会の参加回数は?自称コミュ障ですか?このアンケート結果は勉強会当日に利用します。利用方法は後述します。(オプション)女性専用枠を用意する「勉強会に参加してみたいけど、女性がほとんどいなかったらどうしよう」と不安に思う女性の方も結構おられるようです。イベントページで「女性の方も大歓迎です」と書くのもひとつの手ですが、端から見ると「大歓迎だからといって、他にも女性がたくさん来る保証はない」と思われてしまい、実はあまり効果がなかったりします。(経験者談)そこで、TokyoGirls.rbでは女性専用枠と性別不問枠を用意しました。すれば、他にも女性の参加者いることが可視化され、女性の心理的ハードルを下げることができます。TokyoGirls.rbは「女性も参加しやすい(でも女性限定ではない)Ruby勉強会」がコンセプトだったので、こういうことがやりやすかった、という背景はあると思います。世間一般の勉強会だと「なぜ女性専用枠?🤔」と思われそうなので、採用するのは少し難しいかもしれません。イベント開催までの準備で名札を用意する(できればTwitterアイコン付きで)勉強会で参加者用の名札が用意されることは一般的だと思います。名札がないと懇親会で相手をどう呼べばいいのか分からない(名前を聞いてもすぐ忘れてしまう)という問題が起きるので、最低限、相手の名前のわかる名札は用意しておいた方がよいでしょう。名前だけでなく、TwitterアイコンやTwitterアカウントがわかる情報も名札に載せられると良いです。vol.2では、名札に貼れるTwitterアイコンシールを用意しました。2019ITエンジニアのTwitter使用率はかなり高いですし、Twitterアイコンを名札に載せておくことで「あ、このアイコン見たことあります!」と会話が生まれる可能性があります。勉強会が終わったあともTwitterを見てるときに「あ、このTwitterアイコンはあの勉強会でしゃべった人だ!」と気づくことがあるかもしれません。参加者の属性も名札で表現できると、さらにベターあとは、参加者の属性を名札や名札の紐で表現できるとさらにベターです。参加者の属性というのは、たとえば参加者に関する以下のような項目です。一般参加者か、登壇者か、スタッフか、スポンサー関係者か自称・初心者かどうかTokyoGirls.rbでは参加者の属性は名札下部の配色(と"STAFF"のような文字)で表現していました。ほかにも「自称・初心者さんには若葉マークを貼ってもらう」というようなことをしておくと、「あ、この人も私と同じ初心者さんなんだ」と安心して話しかけられるかもしれません。どんな方法であれ、名札に載せた情報で「今、目の前にいる人が何者なのか、どんな属性の人なのか」を可視化できると、懇親会でお互いに話しかけやすくなると思います。勉強会のオープニングで経験の浅い人や初参加の人もたくさんいることを伝える初心者さんや勉強会初参加の人は、「ここにいる人は全員、熟練のプログラマで、こんな超初心者は私だけかもしれない」「私以外はみんな過去に参加したことがある人で、知り合いが一人もいないのは私だけなのかもしれない」と不安に思っている可能性があります。そこで、参加アンケートで集めたプログラミングの経験年数や勉強会の参加回数をオープニングでお知らせしましょう。以下はTokyoGirls.rbで実際に使ったスライドです。このように参加者全体の経験年数や参加回数を可視化できれば、初心者さんも「よかった、初心者は私だけじゃないんだ」と安心することができます。アンチハラスメントポリシーについてあらためて説明するアンチハラスメントポリシーは参加者全員が事前に読んでおくことが前提になりますが、まだ読んでない人や一度読んだものの、すっかり頭の中から抜け落ちてる人がいるかもしれません。オープニングでも簡単に説明しておきましょう。意図せず加害者になってしまうことを恐れる人もフォローするアンチハラスメントポリシーの提示は「被害に遭うのが怖い」という人を安心させることができる一方で、「自分の何気ない発言で相手を傷付けてしまうかもしれない」と過剰に心配する参加者を生み出す恐れもあります。主催者はそういう参加者をフォローしておくことも大事です。TokyoGirls.rbでは以下のようなことをオープニングで伝えました。過剰に心配しないでください。「ちょっとした心がけ」だけで十分ですもし、悪意なく誰かを傷つけてしまった場合、我々運営スタッフが最初からあなたを厳しく非難することはありませんハラスメントが起きたときは加害者も被害者もきっとショックを受けていると思うので、我々運営スタッフは双方の参加者を全力でサポート&フォローします会場にいる運営スタッフを紹介するオープニングでは会場にいる運営スタッフを紹介しておきましょう。「何か困ったことがあればお近くのスタッフに何でも言ってね!!」と参加者のみなさんに伝えてください。緊急連絡先がわかっているのとわかっていないのでは、参加者の安心感も大きく変わってくるはずです。懇親会でさて、いよいよ懇親会の始まりです。「懇親会です!みなさん楽しくご歓談ください!」で始めてしまうのではなく、参加者の緊張をほぐし、お互いに話しかけやすくなる工夫を実践しましょう。Meetupでは懇親会用の飲食店に移動するのではなく、会場内で飲食物を提供するスタイルの懇親会にしています。第1回ミートアップの懇親会の様子ですみんな自称・コミュ障であることを理解してもらう僕が観測する限り、ITエンジニアの大半は「自称・コミュ障」です。「あの人、いつもめっちゃ仲よさそうにいろんな人と話してるやん!」と思うような人でも、1対1で話してみると「いや〜、人と話すのは苦手なんですよねえ」とおっしゃる人が多かったりします。言う僕も自称・コミュ障です。初対面の人と話すのはほんとに苦手です!!・・・ということを知らない人も多いと思うので、懇親会が始まる前にそのことを参加者に伝えましょう。TokyoGirls.rbでは「ぼっちが懇親会でするべき97のこと」というTogetterページからいくつかツイートを引用して紹介しました。参加アンケートで「あなたは自称・コミュ障ですか?」というアンケートを採っていれば、その結果をこのタイミングで発表するのも効果的だと思います。(Yes/Noで答えるだけなので、事前アンケートなしでその場で挙手してもらう、とかでもいいかも?)そして、「コミュ障なのはお互いさまだから、ぼっちの人を見かけたら、こんにちは😃と話しかけてあげてください」と、参加者のみなさんに伝えておきましょう。最初にグループ分けをする(アンチボッチ・グルーピング)大勢の人が集まっている中でいきなり「さあ、みなさんご歓談ください!」とするよりも、ある程度「最初に誰と話すか」を決めておいた方が最初の会話が生まれやすいと思います。そこでTokyoGirls.rbでは「アンチボッチ・グルーピング」と題して、参加者をある条件でグループ分けし、最初はそのグループで話してもらうようにしています。第1回ミートアップのグループ分けの条件は「あなたが使っているエディタは何?」でした。第2回ミートアップのグループ分けの条件は「最初に買ったRubyの技術書は何?」でした。グループの人数が一発で均等に分かれることはないので、運営スタッフは「秀丸を一度でも使ったことがある人は、こちらのグループへ!」みたいな感じで、参加者をいい感じに誘導してあげてください。飲食物を置いておくテーブルもグループの数に合わせて用意しておくと、グループ分けがスムーズに進みます。このグループ分けはあくまで「懇親会がスタートしたときのグループ分け」であって、最初から最後までそのグループから動くな、というわけではありません。主催者は「ある程度話したらグループを移動しても大丈夫ですよ」と参加者に伝えておきましょう。パックマンルールを実践してもらうパックマンルールというのは、他の人があとから入りやすいように1人分のスペースを空けておいてもらうルールのことです。できればこのルールも実践してもらうように、参加者のみなさんにお願いしておきましょう。会話のテンプレートをスクリーンに映しておくTokyoGirls.rbでは懇親会中に以下のような会話のテンプレートをスクリーン上でループ再生しています。使う)言語やフレームワークは?エンジニアになったきっかけは?どんなお仕事をされていますか?自分史上最大のバグを教えてくださいオススメのストレス解消法を教えてください健康維持のために気を付けてることはありますか?尊敬するITエンジニアや憧れのITエンジニアは誰ですか?今日のイベントはどこで知りましたか?会社に女性エンジニアは何人いますか?もちろん、このテンプレートのとおりに会話する必要はありませんが、口下手な人はこういうテンプレートがあった方が助かるかもしれません。運営スタッフがぼっちの人をフォローする運営スタッフはぼっちの人をもし見かけたら、自分から話しかけに行って、うまく他のグループの中に誘導してあげてください。Meetupでは、ここまでの様々な施策が功を奏したのか、ぼっちの人を見かける機会はかなり少なかったです。イベント終了後に開催後アンケートを採り、運営スタッフ間でふりかえりをするイベントが終わったら参加者にアンケートの回答をお願いしましょう。イベント全体の満足度や感想を集め、それらをインプットにして運営スタッフでふりかえりミーティングを開催してください。ふりかえりはKPT方式(KPT=Keep/Problem/Try)で行うのがお勧めです。良かった点はさらに良くできないか、悪かった点は次回でどう改善できるか、みんなでアイデアを出し合いましょう。無理せず、やれることだけをやるここまで様々な施策や工夫を紹介してきましたが、これらを全部実践しようとするとそれなりにコスト(金銭的にも・時間的にも)がかかります。「すべての勉強会がこうあるべきだ!」などと言うつもりは決してありません。無理することなく、勉強会の規模や性質、スタッフの人数等に応じて、主催者一人ひとりが「いい塩梅」を模索してください。vol.2の規模を載せておきます。Meetupで実践した施策や工夫でした。BYライセンスで公開しています。必要に応じてご自由にお使いください。Deckまた、Keynote形式のファイルもこちらからダウンロードできますので、スライドの内容を改変したい場合はこちらをお使いください。vol.2での取り組みを例に挙げながら、安心して参加できる勉強会・懇親会のために主催者ができることをいろいろと紹介してみました。いえ、先ほども述べたとおり、別に全部の施策を無理に実践する必要はありません。「これなら費用対効果が高そう」と思ったものをいくつかピックアップするだけでも良いと思います。vol.2の開催レポートです。今回のエントリには書いていない、勉強会主催者向けの知見や情報も載っているので、こちらもあわせてどうぞ。blog.jnito.com今回のエントリでは「アンチボッチ・グルーピング」という取り組みを紹介しましたが、もともと「アンチボッチ」というキーワードが最初に登場したのは、2011年に開催されたRubyKaigiだったそうです。その経緯についてはこちらの記事をご覧ください。vol.2を開催しました。Meetupは基本的に「ふつうのRuby勉強会」なのですが、イベントを成功させるために運営としてあれこれ工夫を凝らした部分もあります。vol.2の運営上の工夫等をお伝えしていきます。Meetupを知らない方のために、簡単に特徴をまとめておきます。参加者は男女とも参加OK。女性専用枠を設けて男女比率がなるべく半々になるようにしているママエンジニアやパパエンジニアも参加しやすいように託児室を用意(追加料金は不要)TokyoGirls.rbの基本コンセプトは以下のエントリにも書いているので、詳しく知りたい方はこちらもご覧ください。blog.jnito.comさらに、今回は「女性も登壇しやすいRuby勉強会」を実現するために、登壇者を公募しました。(招待スピーカー4名、公募スピーカー4名の計8名が登壇)blog.jnito.com今回の会場は株式会社SmartHRさま!今回は株式会社SmartHRさまのイベントスペースをお借りしてイベントを開催しました。広くて、めっちゃきれいで、一介のRubyコミュニティがお借りするには贅沢すぎる空間でした。会場の椅子を前後互い違いに並べてみましたちあみに、会場の椅子は前後で重ならないよう互い違いに並べてみました。託児室はイベント会場に併設されたキッズルームを使用させてもらいました今回の託児室はイベント会場に併設されたキッズルームを使用しました。ここもSmartHRさまのイベントスペースの一部です。(最初からキッズルームがあるなんてすごい!)なんとか到着しました!ムスメを託児ルームに...。2019また、今回は託児サービスの依頼を株式会社ネス・コーポレーションさんにお願いしました。比較的リーズナブルな料金設定にもかかわらず、とても親切かつ丁寧にお子さんたちの託児を担当してもらいました。奥さんも大助かり?パパエンジニアや登壇者の方も託児室を利用しました今回、託児室では合計6名のお子さんをお預かりしました。託児室の利用には特に制限を設けていないため、イベントに関わる人であれば(定員を超えない限り)誰でも利用可能です。今回は登壇者の方や、パパエンジニアの方も託児室を利用されていました。勉強会の臨時託児室というと、どうしても「お母さんの利用」が最初に思い浮かびますが、お父さんが利用すると奥さんにも非常に喜んでもらえるみたいです。今回「子供を連れて勉強会に参加してもいい?」と相談すると、逆に「えっ、いいの?」と、前のめりになって協力してくれました。当日は家を出た11時から合流した19時まで自分の時間を過ごせたようで、合流したときには心なしか普段より機嫌が良さそうでした。https://note.com/ken3ypa/n/nb90e0dd7e2f7ちなみに、今回はかとりえさん(@katorie)を託児室専任の運営スタッフとしてアサインさせてもらいました。託児室運営に関わる知見はまた後日かとりえさんにまとめてもらう予定です。2020.2.5追記:託児室運営の知見をまとめてもらいましたかとりえさんに託児室運営の知見をまとめてもらったので、詳しく知りたい方はこちらのブログをどうぞ!katorie.hatenablog.comTwitterアイコンシール付きの名札を用意しましたITエンジニアはよくTwitterを使っています。そのため「本人の顔や名前はよくしらないけど、Twitterのアイコンだけだったらなんか知ってる」という状況がよく起こります。名札にTwitterのアイコンが出ていれば、「あ、このアイコン見たことある!」みたいな感じで会話が弾むんじゃないかと。出来上がった名札がこちらです!登壇者や一般参加者の方の名札だとこんな感じです。2019懇親会ではこちらの思惑通り、あちこちでTwitterアイコンを介した会話が生まれていたようです。名札デザインと印刷はSmartHRさま、シール作成は僕でしたちなみにこの名札、Twitterアイコンが貼ってあるだけじゃなくて、デザインもめっちゃオシャレです。(ですよね??)この名札のデザインと印刷もSmartHRさまのご厚意で用意していただきました。デザイナーのNamさん、印刷をしてくださったSmartHRさま、何から何までどうもありがとうございます!それから、シールを作って持っていったのは僕です。こんな手順でTwitterアイコンシールを作成しました。API経由で参加者のアイコン画像を集める印刷用CSSを利用してA4用紙にアイコンを敷き詰める100均で売ってるA4サイズのシール用紙に自宅のプリンタを使って印刷する(下記写真)ハサミで1枚ずつシールを切るアンチハラスメントポリシーを作って、オープニングで説明しましたみんな大人だし、わざわざ言わなくても大丈夫だろう、とは思うものの、第1回と同様にアンチハラスメントポリシーを用意して、オープニングで簡単に説明しました。TokyoGirls.rbで用意しているアンチハラスメントポリシーの詳しい内容はこちらをご覧ください。blog.jnito.comなぜアンチハラスメントポリシーを用意するのか?アンチハラスメントポリシーを用意する理由を一言で説明するのは難しいのですが、まずは参加者のみなさんに安心してほしい、という思いが一番大きいかもしれません。アンチハラスメントポリシーを掲げることは、「運営としてハラスメント(嫌がらせ)を看過することはありませんよ。みなさん安心して参加してください」という運営サイドからの明示的な意思表示だと考えています。アンチハラスメントポリシーを用意したからといって、ハラスメントを完全に防げるとは思っていません。それでも何も用意しないよりかは(つまり「運営は何も言いません。参加者の自由意志にすべて任せます」としてしまうよりも)、その確率を減らせると思います。万一問題が起きたときにも、それはアンチハラスメントポリシーに反する行為です、と運営が指摘しやすくなります。スタッフをオープニング時にあらかじめ紹介しておくことで、何か気になることが起きたときに参加者の人も報告や相談をしやすくなるはずです。オープニングでは会場に常駐している運営スタッフを紹介しましたid:takahashimさんもほぼ同じ内容をブログに書かれているので、アンチハラスメントポリシーについて深く掘り下げたい方はこちらもぜひご覧ください。は・私はハラスメントしていないか心配です」問題にどう対処するかしかし、世の中は難しいもので、アンチハラスメントポリシーがあることで、逆に勉強会や懇親会を楽しめない人が出てくるケースもあります。それが「僕は・私はハラスメントしていないか心配です」問題です。この問題は文字通り、「ハラスメントはやめましょう」というメッセージを伝えることで、今度は「悪気なく誰かを傷つけてしまうかもしれない」「嫌な思いをさせるかも?と思ってまったく話ができない」と、過剰に心配してしまう人たちを生み出す問題です。この問題は解決がなかなか難しいです。そもそも何がハラスメントと受け止められるのかは、受け手の捉え方によっても違ってくるので、画一的に「こうすれば解決」と断言できるような模範解答はありません。この問題については、オープニングで運営チームからこんなメッセージを発信しました。加害者になることを過剰に恐れないでください。「ちょっとした心がけ」だけ持っていれば十分です。「心がけ」があるかないか。それだけであなたの行動は変わってくるはずです。それでもハラスメントが発生する可能性をゼロにすることはできないでしょう。悪意なく誰かを傷つけてしまった場合、我々運営スタッフが最初からあなたを厳しく非難することはありません。交通事故が起きたときと同じように、ハラスメントが起きたときは加害者も被害者もきっとショックを受けていると思うので、我々運営スタッフは双方の参加者を全力でサポート&フォローします。イベント当日のオープニングで使ったスライドですまあ、簡単に言えば「最後は我々運営スタッフがなんとかするから、ドーンとぶつかって来い!大丈夫、大丈夫!」ということです。最後は運営チームでなんとかするしかない!「そんなこと言ったって、実際に問題が起きたらどうするの?」と思われるかもしれませんが、それはそのときになってみないとわかりません。仮にハラスメントが起きたとしても、そこでどんなハラスメントが起きるのか、前もって予見できる人はこの世にいないでしょう。このコミュニティは僕一人で運営しているのではなく、信頼できる運営スタッフが僕以外にもたくさんいます。「何か起きてもチームで対処すればきっとなんとかなるはず」と僕は信じていました。勉強会におけるハラスメントの話題についてはSlack上でもスタッフ同士でよく意見交換していて、認識や考え方もある程度統一できているので、それが「きっとなんとかなる」の後ろ盾になっています。vol.2ではアンチハラスメントポリシーに関連するような問題は発生せず、無事に終わらせることができました。言うなら一点、託児室をネタにしたブラックジョークっぽいツイート(保護者の方にとってあまり気分が良くない発言)を見かけたので、DM越しに僕から声を掛けて削除してもらいました。ツイートの削除はすぐに対応してもらったので、こちらとしては特に問題視していません。このやりとりがスムーズに進んだのは、もしかするとアンチハラスメントポリシーの件を事前に話していたおかげかもなー、と思ったりしています。懇親会では「ぼっち対策」や雑談のネタを提供しました第1回ミートアップと同様にアンチボッチ・グルーピング(ひとりぼっちの人が発生しないように、共通の属性でグループを作る取り組み)を実施しました。ちなみに、今回のグルーピング条件は「最初に買ったRubyの技術書は何?」でした。2019その他にもパックマンルールを推奨したり、懇親会の雑談ネタを提供したりしていました。パックマンルールや、懇親会で話すネタや、次に行くのにオススメの勉強会情報が常にスライドに映っている。2019参加者のみなさんの反応など最後に、Twitterで見かけた参加者のみなさんの反応をいろいろまとめておきます。2019今回、初めて託児を利用してテック系のイベントに参加した。2019アンチハラスメントポリシーのお話。2019参加者の男女比について託児室もあって男女比率が半分くらいでこんないい話を聞ける勉強会。本当にこれエンジニアの勉強会?という男女比ですごい。雰囲気が全然ちがうなー。2019その他、イベント全体の感想などこういう勉強会やエンジニアのコミュニティ参加したことなかったんですが、予想以上の収穫でした。コミュ障が孤立しない仕組みもあり、たくさんの方とお話ができました。2019とても有意義な時間でした...加えて空気と治安が良くて、主催の方々やスポンサーの皆様が色々考えて開催されている事を肌で感じて本当に感謝の気持ちでした...。懇親会が終わった後に全員で集まった記念撮影をしたのですが、そのときのかけ声はRubyの勉強会らしく「Rubyで配列をループさせるときに使うメソッドは〜?」「はい、each(イーチ)!」にしてみました。vol.2について、運営者視点で工夫した点などをまとめてみました。実は舞台裏では準備段階から直前までバタバタしていて結構大変なところもあったのですが、みなさんの反応を見ていると「大変だったけど、開催して良かったなあ」としみじみ思いました。登壇してくださったみなさん、参加者のみなさん、どうもありがとうございました。今回のイベントはスポンサー企業各社の協力無しでは実現できませんでした。会場スポンサーの株式会社SmartHRさま、および託児スポンサーのCI&T株式会社さま、トレジャーデータ株式会社さま、株式会社万葉さま、どうもありがとうございました。次回の開催日は未定ですが、そのうちまた開催したいなと思います。できれば次は関西でやりたいですね。運営スタッフのうち2名が関西在住なので!次回もみなさんどうぞよろしくお願いします😄あわせて読みたい登壇者のスライドはこちらにまとめてあります。blog.jnito.comイベント当日のツイートはこちらでご確認ください。togetter.comvol.1は今年の3月に開催しました。そのときの様子はこちらにまとめてあります。はてなブログPro株式会社ソニックガーデンで働くRubyプログラマ。2017年11月に「プロを目指す人のためのRuby入門」を出版。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。