Happy Elements株式会社 カカリアスタジオ Advent Calendar 2016の25日目の記事です。
担当は「あんさんぶるスターズ！」グループの @kusakari です。
はじめに
Happy Elements株式会社のエンジニア数は社員23名、アルバイト8名（全員学生）です1。このくらいの規模での社内勉強会について、最近考えることがあったのでまとめてみたいと思います。
前提として現在Happy Elements株式会社ではエンジニアは5つのアプリグループと全社横断のインフラグループの6グループに分かれており、インフラグループの他には全社横断のグループがないため、**各アプリグループごとの裁量は大きい一方で、アプリ間の情報共有面は弱い（Qiita:Teamがメイン）**という特徴があります。
社内勉強会について
エンジニアの採用面接で比較的良く聞かれる質問に「社内勉強会は活発ですか？」というものがあります。これには決まって「時期によります…。」という歯切れの悪い回答をしています。ただ、これは本当に時期によるという表現が正しく、要は勉強会をよく企画する人の担当アプリが運用フェーズであれば、勉強会が開催される一方で、立ち上げフェーズとなると開催されづらくなるという傾向があります。
弊社では古くは某ミドルウェアの英語資料翻訳読み合わせ会からはじまり、アニメーション勉強会、インフラミドルウェア勉強会、（ジャンルを問わない）おすすめ本発表会、1時間でミニゲームを作るハッカソン、Unity勉強会などなど、様々な勉強会を実施してきました。また、オフィスのカフェスペースを公開して、社外の方も呼んでkyoto.rbを実施していた時期もありました。
このような勉強会では、勉強会参加者がまた参加したいという気持ちとなれるかどうかは、発表者次第という場合が多く、発表者に負担がかかりやすい状況になってしまっていました。また、発表者が準備不足で内容がもう一つだったり、価値ある発表とするため発表者やテーマがなかなか決まらなかったりすると、そういうタイミングで休止となることが多かったように感じています。
その他にも15〜20人程度のメンバー数では、全員のスキルレベルに合った内容にすることが難しく、ばらばらのスキルレベルの参加者の満足度を高い状態で維持することが難しいという問題もありました。例えば、Unity勉強会の場合、発表内容にUnity縛りがある中で多くの参加者に満足してもらえる発表をすることの難易度が高さ、そしてそれを継続していくことの難しさはご理解頂けるかと思います。
環境の変化による、目的の変化
そもそも社内勉強会では、自社で弱い部分をみんなで育てていこう、共通の知識をつけて底上げしていこうという目的が主だったように思います。しかし、ここ数年で人が増えたり、開発するアプリがウェブからネイティブとなり、より複雑な内容になって専門性が増していくことで、誰もが同じ知識・スキルをもつことよりも、誰が何をやっていて何が得意かを知ることであったり、何かあれば依頼できるような交流をもっておくことの方が大事なのではないかと考えるようになりました。
勉強会の目的を「交流」にする
そう考えると、勉強会の目的を「交流」とすることで、以下のような問題が解決できるのではないかと考えました。
- チーム間の交流が少ないこと
- 誰が何をしていていて、何が得意かがわからないこと
- Qiita:Teamに投稿はあるものの、あまり読まれていなさそうなこと
また、そうすることでおのずと勉強会の発表内容も以下のように決まりました。
- 新しいこと・難しいことを発表するのではなく、実践的な内容の発表をする
- 準備に多くの時間をかけるのではなく、ポイントだけを発表してその後の交流につなげる
- 発表内容はLTとして、一回の開催で各グループから一人ずつ発表してもらえるように
- 一度の開催での発表者数を安定させるため
このような考え方で今年の10月より月1回「月次エンジニア交流会」を開催しています。
実際に開催してみて
10月から3回ほど開催してみての感想です。
- 想定していたよりも、交流できていて良かった
- 同じグループで固まる人たちもいるけれど、同じグループ内でもエンジニアだけでゆっくり話をする機会は多くないと思うため、それはそれで良い
- 様々なジャンルの話が出るため、毎回誰もが一つくらいは興味をもてる内容がある可能性は高そう
- 普段からグループ内で勉強会を実施しているグループは資料も既にあって良さそう
- 一度集まる場ができるので、そこから二次会が発生したりなど、きっかけとしても役立つ
継続していくために
やはり開催するたびに問題点は見つかり、改善していく必要性は感じています。問題点があることで、参加者が減っていってしまっては「交流」という目的が果たせなくなってしまうため、参加者が増えていくように改善していきたいと考えています。
初回は「こんなもんかな」という感じではあったのですが、第二回の開催後に明文化したルールを作る必要性を感じました。それは、「勉強会（交流会）」は安定して継続していくとが重要だと感じたからです。
例えば、交流会の開催を企画した自分がいなくなっても、あるいは、なぜこういう交流会を実施しようと考えたかを参加メンバーが知らなかったとしても、今後も良い形で継続しできることが価値のあることで、そのためにはルールが必要だと考えました。
そのために考えたルールが以下のものです。
こちらはまだ12月の開催（3回目）で実施用に作った暫定ルールであるため、今後も改善していく必要があると考えています。
エンジニア交流会暫定ルール
準備担当・レポート担当
- 1回の交流会につき、準備担当者1人とレポート担当者1人を決める
- 最初にアルファベット順にて準備担当のグループ決定する
- 準備担当のグループ内で相談して、準備担当者・レポート担当者を決定する
交流会の流れ
- LT
- グループ名アルファベット順で発表
- 毎回各グループから1人ずつ発表
- 発表者がいない場合は飛ばす
- ご歓談
LTのルール
内容
- 最初の1枚のスライドは必ず自己紹介とする、それ以外は自由
- 今後いつ使うかわからないUnityの新機能の話などよりは、比較的実務に近い内容を推奨
- 資料1〜2枚とか、気負わず軽い内容の発表でも全然OK
- 1分につきスライド1枚とかだと調整しやすい
例えば以下のようなもの
- Unityのバージョンアップ時のはまりどころ
- 最近うまくできた実装
- 最近のはまったところ、悩み
- 開発・レビューの進め方などで工夫しているところ
- 運用の仕方（他職種との連携含む）で工夫しているところ
時間
- 最長でも10分とする
- 最初の「チーン」で発表開始。
- 「チーン」担当はレポート担当者。
- 9分で「チーン」とラスト1分をお知らせする。
- 10分で「チーン」と鳴ったら強制打ち切り終了とする。
準備担当の仕事
開催の準備
- 担当となった時点で、各グループの開発リーダーにLTメンバーのアサインをお願いする
- 開催一週間前を目安で再度お願いしておく
- 合わせて開催一週間前に、Slackのエンジニアチャンネルで交流会開催を告知する
飲食物の準備2
- 事前に何を注文するか決定する
- 3日営業日前を目安に告知して、用意する人数を確認する（参加人数とは別）
- 1日前を目安に用意する人数を確定する
- 当日、注文する
- 飲み物も買ってくる
- 必要あれば、割り箸・紙皿も購入する
交流会終了後
- 発表者に特定の場所に発表資料をアップロードしてもらう
- レポート担当がどういう会だったか、それぞれの発表内容と会全体を簡単にまとめてレポートする
- レポート担当が責任をもって発表者に資料をアップロードしてもらう
- 交流会の翌営業日中にはQiita:Teamにレポートをアップロードする
- これにより参加しなかった人に興味をもってもらえるようにする
- 経費精算を行う
まとめ
Happy Elements株式会社のエンジニア社内勉強会・月次交流会についてご紹介しました。
もし近い組織体制や規模感の会社などで、参考にしていただけるようならうれしいです。
おわりに
Happy Elements株式会社カカリアスタジオではエンジニアの社員およびアルバイトを募集しています。こちらからご応募ください！
イラストについて
いらすとやさんのイラストを使わせて頂きました。ありがとうございます！