DevLove関西「勉強会勉強会」に参加してきました
休日を利用して大阪へ遠征してきました。
DevLOVE関西「勉強会勉強会」 - DevLOVE関西 | Doorkeeper
関西圏の勉強会参加は初めてだったので
「どんな雰囲気なんだろう？」
「どんな人たちが集まるんだろう？」
「友達100人できるかな？w」
ということにドキドキ、ワクワクしながら参加しました。
参加者は全部で50名弱で、勉強会を主催している方（勉強会の達人）が多数いました。
そういった達人たちとお話し出来て、色んな刺激を受けつつとても楽しい時間を過ごせました。
（友達100人は出来ませんでしたがw）
勉強会はセッション3部＋ビアバッシュで実施されました。
セッション１：勉強会勉強会
1つ目のセッションは楽天の吉岡さん（@hyoshiok）のお話でした。「勉強会に関する気づきを得る」ということをゴールとし、勉強会ってどんなもの？に始まり
参加者視点、主催者視点、発表者視点での目的や課題をお話をして頂きました。
印象的だったのは「勉強会の法則（よしおかの法則）」というものです。
勉強会には色々課題があって
- 参加者視点の課題
- 主催者視点の課題
- 発表者視点の課題
があるけど、じゃあなんで参加するの？なんで主催するの？なんで発表するの？
という質問の答えとしてこの法則が成り立つということでした。
勉強会の法則（よしおかの法則）
- 勉強会のメリット ＞ 開催のコスト
- 勉強会のメリット ＞ 参加のコスト
- 勉強会のメリット ＞ 発表のコスト
勉強会のメリットがそれぞれのコストを上回れば開催するし参加するし発表するだろう、ということです。
つまり、勉強会を成功させるためには
- 開催／参加／発表のコストを下げるように働きかける
- 勉強会のメリットを上げるように働きかける
という２つのアプローチが必要である、ということをおっしゃってました。
単純明快な方程式でとても分かりやすかったです。
セッション２：勉強会を開催する大まかな流れ
2番目はDoorkeeperの中の人、Paul McMahonさん（@pwim）でした。Paulさんは「日本のRubyistと外国のRubyistをつなげたい」というビジョンを持っていて
実際にそれをどうやって実現したか、というお話をしてくれました。
ここで印象的だったのは
という考え方でした。
既存のものをうまく活かして新しいこと（自分のやりたいこと）を実現するというのは素晴らしいことだと思いました。
セッション３：社内勉強会のお話
最後のセッションは中村洋さん（@yohhatu）による社内勉強会のお話でした。私も社内勉強会に積極的に関わる立場として、一番楽しみにしていた内容でもありました。
このセッションでは
「テーマは汎用的な方が人が集まりやすい」
という気づきを与えて頂きました。
これは
- Play framework勉強会
- JUnit／TDD勉強会
- CI／Jenkins勉強会
という具体的なテーマにしてしまうと、（特に勉強会に対するモチベーションの低い方にとっては）
「うちの現場ではPlay framework使ってないしな〜」
「TDD？CI？なんかよく分からないから参加するのやめとこ〜」
「今後使うこともないし興味もないな〜」
という参加しない理由になりがちだということです。
そういったテーマよりは
というようなテーマにした方が、間口が広がって人が集まりやすいということでした。
これには「なるほど！」とめっちゃ納得がいきました。
あと
「テストケースの紹介…と見せかけてJUnitやTDDの話をしたり」
「リリース前のチェックリストの話…と見せかけてCIやJenkinsの話をしたり」
という「抱き合わせ」の話も興味深かったです。
ビアバッシュ
今までいくつか勉強会に参加してきましたが、ビアバッシュやったのは初めてでした。ビアバッシュ、良かったですね〜
Paul McMahonさん（@pwim）も発表中に話してたんだけど
やっぱ日本人はお酒が進めば進むほど打ち解けやすいと思うし、話も弾みました。
若干私の愚痴を聞いて頂いてばっかりだった感は否めませんがw
さいごに
DevLove関西、めっちゃ良かった。色んな人から刺激を受けて「もっと自分頑張らないかんな〜」というエネルギーももらったし
なにより達人たちとお話出来て楽しかったですね。
また機会があれば参加したいです。
