最近社内で短時間勉強会を行っている。 特徴としては、
- 1時間〜1時間半くらいで終わる
- 参加者、主催者が特に事前準備をしない
ことがあげられる。
たとえば"他事業部のサービスのソースコードを読む会"をやったときは、
- 30分間他事業部のサービスのソースコードを各自読み、Wikiページ(ちなみにうちの会社ではConfluenceを使っている)に感想や参考になりそうな点を書き込む。
- その後30分〜60分間、各自感想や参考になりそうな点を発表して、意見を交換する
といった流れだ。 こういう形式なら参加者も主催者も準備が特に必要なく気軽に開催できる。
ここ最近やった会は以下だ。
StyleGuideを読む会
- Ruby, RailsのStyleGuideを読む。読んだ結果の感想や気付き、疑問点等々をWikiページに書き込み、各自みんなで話しあう。
- StyleGuideを読んで理解することはコードを書くうえでMUSTなのだが、まだRubyやRailsのコードをあまり書いたことがないメンバーがいたり、また以前StyleGuideを読んだ人も意外と忘れていたりするので、開催してみた。
- StyleGuideを読んだことがないメンバーにはいいきっかけになったし、またお互い良いスタイルがなにかの認識合わせができてよかったと思う。
他事業部のサービスのRailsソースコードを読む会
- 大規模サービスのRailsソースコードを読む機会ってあまりなく、大きなサービスをRailsで作っていると若干不安になることがある。そのため他事業部のサービスのRailsソースコードを読むことで、引き出しを増やしたり、良い設計や実装を自分のサービスに取り込もうという企画。
- 自分が知らなかった便利なGemを使っていたり、参考にできそうな設計がされていたりして、有益な会になった。
NewRelicをみんなで触ってみる会
- NewRelicというパフォーマンス監視ツールがあり、それを導入しようと話がすすんでいた。
- ただ、一方的に導入しても他のエンジニアが使わなければ宝の持ち腐れになってしまう。
- そのため、導入前にみんなでNewRelicを触ってみる会を設けた。
- これも例によって30分間各自NewRelicを触ってみて、その結果の感想だったり、気づいた便利な機能だったり、こういうことが解決できそうといった感想をWikiページに書き込み、そのあとの30分間で各自発表しあう形式にした。
- これによって自分も知らなかった便利な機能を知ることができたり、各自がNewRelicを使うことでどんなことが解決できそうか理解することができた。
開発環境共有会
- 便利なツール1つとっても知っているだけで生産性が上がることってありますよね。そういったお得な情報をみんなで共有して各自の開発速度を上げようという趣旨の共有会
- 例えば、普段使っている便利なツール、便利な設定、便利なコマンド、使っているキーバインド、使っているシェル、使っているエディタ、使っているキーボード、マウス、取り入れている開発スタイル、タスク管理方法などをWikiページに書きまくって、各自発表する。
- エンジニアはツールや環境に凝る人が多いので、会は結構盛り上がる。
- 知らなかった便利情報が集まって非常に有益な会になった。Wikiページに書いてあるので参加しなかったエンジニアもみることができるのがまたいい。
一部、勉強会というより共有会に近いですね。
あとこのスタイルは読書会でも適用できて、30分間各自指定した本を読みその感想をWikiページに書いて、残り30分間感想を発表しあうみたいな形式が可能です。 (このスタイルは以前同僚がやっていて、今回の一連の勉強会もそのスタイルを拝借した)
短時間で終わって参加者主催者が特に準備がないスタイルは気楽にできるので、ぜひ皆さんもやってみてはいかがでしょうか。
