おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

勉強会のスタイルを模索してみる

社内勉強会の必要性を日々感じています。

とはいえ、うちの組織ではここ数年のあいだ勉強会は失敗続きでした。
簡単に勉強会をしようと声掛けしても集まらない現状です。

ということで、これまでとは違った勉強会を始めています

業務で発生した課題をきちんと考えるという趣旨で3人だけで勉強会を始めました。
具体的には、Java のパフォーマンス課題とその改善についてです。

現状の課題を洗い出すワークショップをして課題を認識してもらったり、
どうしたいかを問いかけたり、後輩2人を議論の起点にするようにしています。

宿題をやってきてくれたり(感動した!!)、Q&Aも活発です。
思っていたよりも積極的に参加してくれています。

「知っておくべき」の単なる押しつけ

ちょっと背伸びしたくらいの難しさであったり、
業務上の課題に関連がある、課題解決のヒントになるような内容であると
意欲が出てくるのかもしれません。

しかし、過去失敗してきた勉強会というのは
・勉強会の内容が業務とかけ離れている
・単方向な講義形式
でした。

業務とは直接関係はないけれど、これは知っておくべきと誰かが判断した。
将来的には役に立つので、上位者が保有している知識を伝えるべきだ。

そういった参加者視点ではない理由から開催された勉強会がほとんどでした。
参加者もこれは勉強すべきと言われ、そういう雰囲気を感じて、参加します。

しかし、知っておいたらいいかも…なにかの役に立つかも…といった
あいまいな動機で参加しても収穫は少ないものです。
なにしろ、その後が続かないです。

結局、主催者が価値観を押し付けて開催できて満足。
参加者の頭には全然残っておらず、なにも変わっていない。
しばらくして、その事実に主催者も参加者も幻滅する。

その繰り返しだったのかなと。

課題解決型の勉強会

自分が今かかえている課題を解決するための勉強会であれば、
参加意欲がわきますし、参加することによる効果も高いです。

そもそも現状の課題が意識できていない場合がありますので
課題発見する場を提供するのも必要になるかもしれません。

今うちの組織に必要なのは、そういった課題解決型の勉強会かもしれません。
業務の延長線で、少し背伸びして考えてみる。そういう場を作っていこうと思います。