give IT a try

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

迷惑電話が大っ嫌いなあなたに!パナソニックの迷惑電話ブロック機能付き電話機を1年使ってみた感想

はじめに

今回は我が家で使っている家電の紹介です。
我が家ではパナソニックのVE-GD66DL-Wという電話機をかれこれ1年ぐらい使っています。

現在(2020年1月時点)は後継機のVE-GD67DL-Wという電話機が発売されているようです。

パナソニック デジタルコードレス電話機 子機1台付き 迷惑ブロックサービス対応 ホワイト VE-GD67DL-W

パナソニック デジタルコードレス電話機 子機1台付き 迷惑ブロックサービス対応 ホワイト VE-GD67DL-W

  • 出版社/メーカー: パナソニック(Panasonic)
  • 発売日: 2019/11/14
  • メディア: エレクトロニクス

なぜこの電話機にしたのかというと、迷惑電話ブロック機能が付いているからです。

迷惑電話ブロック機能は以下のような仕組みで実現されています。

  • トビラシステムズという会社が提供している迷惑電話データベースから1日1回、データを自動ダウンロードする
  • このデータベースに登録されている電話番号から電話がかかってきたら、自動的に着信を拒否する(呼び出し音も鳴らない)
  • データは電話回線を使ってダウンロードするので、1ヶ月あたり「1回10円x31日=310円」の電話代(=サービス利用料)が発生する

迷惑電話ブロック機能の詳細については以下のページを参照してください。

迷惑ブロックサービスとは? - ファクス - Panasonic

今回のエントリではこの電話機の迷惑電話ブロック機能を1年ほど使ってみた感想を書いてみます。

迷惑電話をブロックしたかった理由

迷惑電話をブロックしたかった理由は、迷惑電話がイヤだったからです・・・だと、そのまますぎますね😅
なので、もう少し詳しく言うと、以下のような理由があったからです。

  • 僕は在宅でプログラミングの仕事をしており、難しいロジックを考えているときに電話が鳴ると、集中力が切れてしまうから
  • 最近は携帯電話にかかってくることがほとんどで、自宅の固定電話に掛けてくるのは学校の先生ぐらい。なので、固定電話が鳴ると「えっ、子どもたちに何かあったのかな?」と心配になるから
  • いつでも手元に置いてあって、さっと応対できるスマホとは異なり、固定電話だと子機や親機のところまで歩いて取りに行く手間が発生するから
  • ただでさえ上記のようなマイナスポイントがあるのに、電話に出たらしょうもない塾の勧誘電話だったりすると、「せっかく出たのになんやねん!!💢💢💢」と怒りの感情がこみ上げてくるから

上記のような理由をひとことでまとめると、「精神衛生上、完全に害悪でしかないから」ということですね。

迷惑電話がかかってくるのはせいぜい月に1〜2回程度なので、決してそこまで頻度が多いわけではありません。
ですが、UX(ユーザーエクスペリエンス、ユーザー体験)の観点からすると1つ1つが最悪のUXだと言えます。

で、迷惑電話ブロック機能って実際どうなの?

そして、気になる迷惑電話ブロック機能のブロック精度ですが・・・100点満点でいうと、70点から80点ぐらいですね。
結局のところ、「ブラックリスト判定方式」なので、かけてきた相手の電話番号がブラックリストに入っていない限り、迷惑電話はかかってきます。
感覚的には「月に1〜2回」から「1ヶ月に1回あるかないか」程度に下がった感じです。

ただし、減点主義で考えれば「なんだ、やっぱり取りこぼしがあるのか」と思われるかもしれませんが、逆に加点主義で考えれば「何件かの迷惑電話をブロックできただけでも万々歳」と考えることもできます。
先ほども述べたように、迷惑電話は1つ1つが最悪のUXなので、「1つでも最悪のUXを未然に防ぐことができた」と考えれば、その点は大きく評価できます。

ブロックできた件数を見るのは気持ちがいい

ちなみに、迷惑電話がブロックされると、本体にブロックした件数が記録されていきます。

f:id:JunichiIto:20200120100510j:plain

たまにこの件数をチェックして、件数が増えていると「おお、ブロックできてる〜❤️」とハッピーな気分になれます。
これは非常に良いUXです😊

自分で着信拒否の番号追加もできる

迷惑電話ブロック機能で阻止できず、迷惑電話を受け取ってしまった場合は、着信履歴からその番号を今後拒否することもできます。
簡単な子機のボタン操作で登録が完了するので、迷惑電話がかかってきたら、電話を切ってすぐにその番号を拒否設定に追加するようにしています。

f:id:JunichiIto:20200120101339p:plain:w350
電話機の説明書から抜粋

まとめ:迷惑電話が大っ嫌いな人には個人的にはオススメ

というわけで、今回は我が家で使用している迷惑電話ブロック機能付き電話機を紹介してみました。

「迷惑電話がゼロにならないと意味がない!」という人にはお勧めできませんが、「少しでも減ってくれれば、それだけでもありがたい」と考えている人には十分お勧めできます。
少なくとも僕個人は「買って良かったな」と思っている電話機です。

迷惑電話に困っている方は今回のエントリを参考にしてみてください!

パナソニック デジタルコードレス電話機 子機1台付き 迷惑ブロックサービス対応 ホワイト VE-GD67DL-W

パナソニック デジタルコードレス電話機 子機1台付き 迷惑ブロックサービス対応 ホワイト VE-GD67DL-W

  • 出版社/メーカー: パナソニック(Panasonic)
  • 発売日: 2019/11/14
  • メディア: エレクトロニクス

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

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