はじめに
本記事は、「有志の社内勉強会を1年で50回くらいやった結果 伝えたいこと」で書いた「勉強会アンチパターン」の対処例についてです。
自分自身あれからいろんな勉強会を見てみて、いろいろなやり方があるよな・・・と、認識を改めたものです。
また、自分の記事で定義した『アンチパターン』は、「絶対にダメ！」というほどのものではないため、誤解を解く意図もあったりする。
宿題を出す
「モチベーションの低い奴はやってこないから、宿題は準備するコストに対して見合うほどのリターンはないよ」ということで、アンチパターン定義していた。
ゲーミフィケーション化
「勉強会をゲーミフィケーションする」を読んで、「確か」にと思った。
ついて来れる人を対象に、フィードバックループを回すことで、効果を最大化するってのは、ありだな。と。
強制する
「強制はモチベーション下げるから、継続性の観点からNGやで」ってことで、アンチパターン定義していた。
仕事にする
「勉強会」というよりは「調査報告会」みたいな形。
実際に部門でやってて、ある程度うまく行った気がする。（自分は運営側じゃなくて参加者側で参加した）
- テーマ選定（運営の仕事）
- チームにテーマを割り振る（部門のメンバ全員が対象）（運営の仕事）
- 必ず外部の研修に参加してもらう
- チームごとに発表内容をまとめる（チームごとに責任持ってやる）
- チームごとに発表する（偉い人の講評あり）
4〜5人で1チーム。5チームくらいできた。
発表は1組1時間程度なので、発表の日は1日かけてのイベントになる。
仕事なので、ちゃんと業務時間内にやってもらう。（有志とか、自己啓発とか、そういうのじゃなくて、仕事の一つ。）
イベント頻度としては半期に1回程度。
外部研修への申し込みは、テーマ発表から1ヶ月以内にやってもらう。（運営でチェックする）
テーマは、
「テスト自動化」や「UML」など、今の現場に馴染みが無いだけの一般技術や、
「ディープラーニング」とか、「ブロックチェーン」とかの先端系技術など、様々。
「競合他社のソリューション情報」などのビジネス系のテーマもあった。
発表は、
研修の内容をそのまま発表されてもしょうがないので、
「何かしら実践してみる」とか、「部門への適用方法の検討」とか、「この先、部門としてどう取り組んでいくべきかの考察」などを加えなさい、
っていう条件がついた。
結果としては、
「部門のメンバーの、新しい技術への感度が上昇した」感があった。
実践・検討・考察の深さはかなりメンバーに依存しており、「素晴らしい発表だな！」ってのもあれば「これは・・・」ってのもあった。
まぁ別に全部が当たりの発表になるわけがないので、運営側も特に気にしてない感じだった。
また、発表の仕方もかなり癖が強く、発表に「慣れている人」「慣れていない人」の差がかなり浮き彫りになった。
（今まで発表の機会がほとんど無いエンジニアにやらせるわけだし、そんなものだろう。）
色々な発見がありつつも、業務ピークと重なると動けないチームもあり、現場負荷はそこそこ高い。
現場負荷の解消に関しては、業務量自体のマネジメント話になるので、ここでは割愛するが、「勉強会があることを前提に、仕事を調整した」という考え方の転換が大きかった様に感じる。
前記事で書いてた「動機付け云々の話」に関しては、これは「仕事なんだからやりましょう」で押し通せるのが強み。
上司からの指示で、「勉強会しなさい！」と言われたら、この形にしようかなと思う。
ちなみにこれの運営は「部門で2・3番目に偉い人」がやっていた。
以上です。（気が向いたら追加していきます）