読者です 読者をやめる 読者になる 読者になる

White Box技術部

WEB開発のあれこれ(と何か)

勉強会おじさんになって思うこと

チーム内交流のために勉強会を開催していたら、なんか勉強会おじさんっぽくなってしまったので 今後の実施方法も考えて、少し現状を振り返ってみました。

なぜ勉強会を始めたのか?

そもそも勉強会を始めるきっかけだったのは、もちろん単純にやりたかっただけというのもありますが、 急激なチームメンバー増と、チーム内でのチーム分けにより、チームメンバーの交流機会が減り、 メンバー間で信頼関係の構築がなかなかできていないように感じたからです。

そこで、開発機能や案件内容にかかわらず、メンバーが集って交流できる場の一つとして、 勉強会を企画することにしました。

勉強会が信頼関係の構築になるのか?

勉強会のスタイルはいくつかありますが、現在実施している勉強会は、

『発表者がいて、他の人はそれを聞いて、場合によって質問する』

というスタイルです。

一般募集で行われる勉強会やカンファレンスでよくあるスタイルのあれです。
これだと発表者以外とは交流できないように感じますが、私にはちょっとした期待がありました。

同じ経験を共有することによる効果

映画館で好きな映画を観たとき、周りの人に不思議な親しみを感じることがありませんか?
別に誰かと会話をしたわけでもないのに、です。
同じ場に集って一つのことを経験・共有すること、ただそれだけで見知らぬ他人と共感できるなら 同じチームのメンバー間であれば会話せずにはいられなくなるのではないでしょうか?

結果的には

思惑通り、発表者への質問から会話が盛り上がったり、終わってから雑談が行われたりと、交流のネタになってくれました。 KPTのKeepでも、複数人から勉強会に関することが度々上がり、受け入れられているように感じました。

またgitの勉強会後では、業務中gitの操作で詰まった場合は、発表していた人に相談しているところも見受けられ、 発表者には仕事が増えて申し訳ないですが、聞かないことによって問題が発生する機会はなくなっていくため、 いい方向に向かっているように感じます。

ふと思いましたが、勉強会の間に今集まっているメンバーがどういう人なのか、 軽く紹介しているとより一層効果があるかもしれませんね。

勉強会の運営方法について

ここからは勉強会の運営自体に関する内容になります。

1. テーマ決め

まずは勉強会のテーマを決めます。

メンバーが興味を持ちやすいように、単純に技術の話と、現在の開発内容に関連した話で、 交互にテーマを変えるようにしています。(勉強会は週1で定時後1時間に実施しています)

テーマは事前募集したり、KPT内容からストックしておいたりしています。

2. 発表依頼

次に、テーマに即した内容を発表して貰えそうな人に、こんなこと話してもらえませんかとお願いに行きます。

これ大事!本当に大事!!発表者がいないと始まらないですし、一生懸命お願いしています。
ちなみに、このときお願いする発表者は、なるべく違う人になるように心掛けています。

なかなか発表者が確保できなそうであれば、自分が一人目の発表者になり、一緒にやりましょうという感じで誘っています。

3. 場所決め

そして、集まりそうな人数を想定して、開催場所を押さえます。

個人的な理想としては、普段の開発作業場の近くにオープンスペースがあって、 ちらっと立ち寄っていけるような感じでやれたらよいのですが、 なかなかそう上手いようにオフィスができているわけではないため、適当な広さの会議室を押さえます。

最近は参加人数に合った会議室が押さえられず、ここが頭を悩ませています。。

4. 参加者募集

最後に参加の募集と、発表・LTの募集をチャットと全体定例でします。

勉強会への参加は強制ではないので、参加して貰えるように勉強会の内容をまとめた周知ページを作成しています。
また、1回の勉強会は定時後1時間を目安にしているので、発表人数が不足していればLTネタがありそうな人に声をかけたりします。

5. 開催

開催の挨拶と今日のテーマについて軽く話して、順次発表に入ります。

メンバー交流という目的があるため、発表中のツッコミもOKとしているので、 そのことを予め話しておくのと、発表中に合いの手を入れたりして、 会話できる雰囲気作りを忘れないようにしています。

あと、写真も撮るようにしています。

6. まとめ

勉強会の周知ページに、発表資料と撮った写真を上げて、チャットで周知します。

これは参加できなかったメンバーにも好評のようなので、当日中にやってしまうといい感じでした。 感想等あればチャットのネタになりますし、話題になってる間ほど、次の発表をお願いしやすい気がします。

以上、繰り返し

勉強会のテーマ決めやスケジューリングは、大体2回先まで行うようにしています。

メイン発表者が1名だけだと、当日急遽都合がつかなくなった場合に開催できないので、 できれば2名以上に発表をお願いできているといい感じでした。

課題として感じていること

今のところ上手くいっているように見える勉強会ですが、個人的には課題も感じています。

人数について

最初は7人位だったのですが、すぐさま20人超えで集まるようになり、 いつの間にか部署をまたいでの参加者も出てきて、単純に場所の調整が難しくなってきました。

また、人数が増えるたことによって、参加を控える人が出てくることを懸念していたりします。

参加者が増えることは、交流の輪が広がり発表内容も膨らむため喜ばしいのですが、 チーム内交流という目的もあるため、チームメンバーが参加しやすいように、 テーマと発表者は偏らないように調整しないとダメですね。

主催者が自分だけ

今一番課題として感じているのは、主催者が私だけなところです。

私がいないから開催できない、ではよろしくないので、 勉強会の流れを定期的に周知しておき、私がいなくても参加者主導で進行できるように種を蒔いておきたいです。

そして勉強会おじさん問題

あんまり勉強会のことばかりを周知していると、「セリは勉強会のことしかやってないのではないか?」と思われてしまい、 私がチームの利益にならない人として認識され、そもそも勉強会に参加する人が減るのではないかという想いがあったりします。

これを防ぐには、業務で成果を出すしかないと思います。
そのため勉強会を主催する人は、業務+勉強会調整で単純に忙しくなります。

これはもうしょうがないですね。バランスを取りながらやっていくしかないでしょう。

それでも勉強会は良いです

色々ありますが、勉強会が開催できてよかったと思っています。

新しいことを知れたり、知識・考えを共有できたり、話のネタができたり、エンジニアならではの喜びが享受できました。 まだ始めて間もないので、定着するように頑張っていきたいと思います。

まあ、でもあれですね、あえて頑張りどころを言うなら・・・

「この人こんなにすごいんだ。あれ?なんかセリさんはリードエンジニアなのに感心してばっかじゃね?発表内容もしょぼくね?変わったほうがよくね?」

みたいなプレッシャーとの戦いですね!