# どうでもいいけど、Blogの記事タイトルに【考察】とか書くの飽きたから中止。
社内勉強会に対する期待を振り返ってみて
一般的な勉強会のメリット感について考えてみたところ、大きく3点になりそうな気がする。
- 深い知識の探求
- 思わぬ知識を知る
- 人と交流するネットワークの構築
ただ、社内勉強会を行う場合
- 企業システムに深い知識は求められない
- 幅広い知識は、現場で使う範囲が限られる
- ネットワークは社内に限られる
ということで、メリットは少ない。
社内勉強会を検討中の人は、上記の違いを踏まえて対応してほしいと思う。
ただ、自分が勉強会を開催するのは以下のメリット感がありそうだったので、チャレンジなのです。
- 新人や視野の狭いアプリ開発メンバーにフレームワークや基盤性能を意識してもらう
- 今後、上位になったり、他プロジェクトに行っても役に立つように引き出しを作る
- 視野を広げて、モチベーションをあげる（これ最重要）
- 勉強ネタが発展して、提案できるネタができるといいなぁ（これイマイチ）
とはいえ、なかなかうまくいかない。
社内勉強会のアンチパターン
だいたい、以下のパターンで、中止に追い込まれる。
- 技術に興味があるメンバーが技術屋をやっているとは限らない（特にIT業界！）
- 上位になる気がない若手もいる
- 企画者の強制によって始まるため、モチベーションを積極的に植えつけないと、むしろ下がる
- 企画者が説明をするだけで、他のメンバーは人事だったり、寝ちゃったり
- 輪講（みんなで少しずつ勉強する）も強制でやるとモチベーションは低くなる
- 勉強会の説明資料の品質が悪くなると存在意義が危ぶまれる
- そもそも、皆忙しくて、勉強会に割り当てる余裕が無い
つまり、モチベーション向上と勉強時間の確保が非常に難しい。
トライ＆エラーの1回目
ということで、少し考えた。
結果はでていないけど、以下の方法だとうまくいく気がしている。
- 輪講を行う
- ただし、新しいことのテーマではなく、現状の改善策を提案する
- 提案はライトニングトークで行い、資料の準備時間が少なくてもそれっぽくなるようにする
- ライトニングトークは5分間。週間で勉強会を行うので、1回の勉強会で1人消化する。
- ライトニングトーク以外の時間は、企画者やチームリーダーが勉強会の本体を行う
- うまくいけば、コードレビュー会もそんな感じにしてゆく。
個人的には「年内の勉強会は週次でやってみて、年末に効果をまとめる」ことを考えている。
というわけで、勉強会の結果はまた今度。
ではまた。
