YAMADA TAISHI’s diary

ゲームについてとか私の日記とか。このブログのあらゆるコードは好きにどうぞ。利用規約があるものは記事内のGitHubのRepositoryのリンクで貼られていると思うので、そちらを参照ください。

社内勉強会が廃れる会社で社内勉強会主催してみた

こんにちは、やまだたいし( やまだ たいし@ソシャゲプログラマ (@OrotiYamatano) | Twitter )です。
これは社内勉強会を立ち上げた私の経験談です。

目次


はじめに

ターゲット


これから勉強会を主催しようとしている人。
勉強会を主催したいけど何をすればいいかわからない人。

やってること


内容:読書会(今はリーダブルコード現在3回目が終了)
小規模の勉強会:5~8人(運営合わせて)
参加募集先:社内エンジニアが集う68人のSlackグループ(+新人7名くらい)
運営:3人(+アドバイザー1人)
枠:30~45分(伸びる時がある)昼休み時間
補足:社外端末利用不可、ノートPCを皆持ってるわけではない
場所:会社会議室
スタンス:有志

運営チームを発足するまで

まず、勉強会に需要があるか、会議室を使えるか等を調べました。

調査


需要調査:
チーム内Slackで呼びかけたりしました。そのSlack内で一定数以上人がいるなら相対的に参加したい人も同じ割合で全体に存在するはずと思いました。
(チームでやりたいという人が居たので、やる方に舵をきりました)

会社ルール調査:
就業規則、身の回りの先輩などから勝手に会議室を借りて良いのか、規則的に労働時間内を勉強会に使って大丈夫か調べました。

運営チーム発足


運営チームメンバー募集。
需要があるかを調査すると同時に運営チームメンバーの募集を行いました。
全然集まらず3ヶ月ぐらいかかりました。
募集でSlack全体に向けてメンションを飛ばしたりしても全く反応はありませんでした。個別にやらないかと聞く方がレスポンスが良いです。
1人で行うという手もありましたが意図として以下のことをしたかったので3人集めました。

  • 定着させたい、定期的に主催したい
  • 振り返りをしたい
  • 記録を残したい

これらをするには勉強会主催当日メンバーが1人欠けても大丈夫なように3人は募集する必要がありました。

相談


Slackで運営チームがやり取りできるチャンネルを作り、運営チームで目指すべき目的や方針を決めました。
はじめは「Slackで草案を出して会議で中身を考えよう」と思ったのですが、「他の人の意見に口出ししたくなった」り、「会議で中身がガラッと変わる」などがありました。
Slackでの草案では効率が悪かったため、結局「定期的な会議で中身を決める」ことになりました。

なぜ、まず運営チームで目指すべき目的や方針を決めたのか。
それは一言に勉強会と言っても人によってそれぞれ「技術共有が目的」だったり、「自分の能力を伸ばすことが目的」だったり、「コミュニケーションをとることが目的」だったり目的が様々で
運営チーム内で衝突が起きてしまったり、「思ってたのとは違う」という意見が出ないようにするためです。
(それでメンバーが抜けてしまうと悲しいですからね)

打ち合わせは、毎週水曜日のお昼に会議の時間(30~45分)を作り少しずつ内容を勉強会でする内容やルールを詰めていきました。
ちなみにお昼に会議を行っているのは「勉強会を始めてもいないのに勉強会の打ち合わせを業務時間中に行うのは、どうなんだ」と横槍が入り、業務時間中に会議の時間が取れなかったからです。

色々やることなどのメモや進捗状況はトレロとSlackで記録しました。
メンバーのやる気がなかったら会議も続かなかったと思うのでメンバーには感謝です。

また、運営チームを立ち上げた後になったのですが、上長に相談をしました。
勉強会を行う上で業務遂行に多少影響が出るので、メンバーそれぞれの部署の上長に個別に許可を貰いました。

勉強会内容

勉強内容の検討


運営チームに、いきなり勉強会をやろう言っても何をすれば良いのかメンバーが戸惑ってしまうと思ったので、はじめに私からメンバーに提案しました。
私は「何の勉強会が良いかを考える為」に私が所属しているSlackグループ「Unityゲーム開発者ギルド」にて色々アドバイスを貰いながら、実際に主催する勉強会は何が良いか考えました。
LT大会を最初は考えましたが、主催側が準備で疲れる、LTの回数を重ねるとLTする人が限定される等の理由から見送りました。
最終的に何にしたかというと「当日までに多くの準備が必要ない」、「少人数でもある程度盛り上がる」、「定着が出来そう」など利点がある読書会にしました。

今、考えると第一回だけはLT大会にした方が良かったかもしれません。
理由は成果が分かりづらい、派手さが無い(派手さが無いと勉強会自体に中々注目してもらえない)、という理由です。

また、行う時間帯については、かなり話し合いました。
弊社が裁量労働制やフレックス、勤務形態が人それぞれあり、勤務時間がバラバラであること、(出社時間がバラバラだから朝や業務時間後は厳しい)
業務時間中で行うには会社の協力が必要(単純に皆と働いている途中で抜けにくい、業務時間だと費用計算が面倒)なことなどを考え、
業務時間にも非業務時間にも扱える時間帯の、お昼時にしました(業務時間の活動とするか非業務とするかは部署の判断に任せた)。

会社の協力が得られるなら、自分の時間を使いたくないという人も一定数居るため、業務時間中にやることをオススメします。
しかしながら、業務時間中の場合、それなりの成果物を求められる場合もあるので注意が必要です。
(会社協力のもと、勉強会を始めちゃうと気軽に辞めれないというデメリットもある)

勉強会の中身


読書会とは:
読書会とは、皆で集まって本を読む活動です。

弊社では以下のように運用:

  • 技術書など皆が勉強になる内容を取り上げ、集まったメンバーでディスカッション
  • 一つの本を数週間に渡り読み進める
  • 開催頻度は週1回水曜日、13時から35分行う
  • 本は持ってない人がいる場合、運営側で印刷

タイムスケジュール的には以下のような感じ

  • オープニングトーク(読書会の説明等や遅れてくる人がいるためこの時間を設けている)
  • 本の黙読を行う/本で気になった箇所や重要に思った箇所、疑問点などを付箋に一言で1付箋一つ書き出す(13分)
  • 皆が書いた付箋を並べて共通点が多い付箋をまとめたり人の付箋を眺めたりする(2分)
  • 皆が気になった付箋を優先的に、その付箋についてディスカッションをする(10分)
  • エンディングトーク(次回告知や勉強会に対するアンケートなどを取る時間に利用)

はじめは誰でも、とっつきやすいリーダブルコードを読む書籍として選びました。
(新人たちが「読んだことあるので……」と全く来ない人たちも居たので読書会の宣伝方法や書籍検討の余地はありそう)

意外にも集まったのはソコソコのベテラン層。

準備/役割、勉強会の振り返り


運営チームで日々振り返りと準備を前日(火曜30~45分)のお昼とその次の日(木曜30~45分)のお昼に打ち合わせ。
流石に高頻度な打ち合わせは疲れるので、慣れたら前日の準備の会はやめるつもりです。

準備/役割

弊社は全員がグーグルアカントを持っているのを利用して
グーグルのグループカレンダーと、googleサイトを使いサイトを作りスケジュールなどを共有する場所を作りました。

また、勉強会をスムーズに進められるように運営チームとアドバイザーを呼んだりして何回かリハーサルを行いました。

運営チームでそれぞれ役割分担をしてそれをローテーションでやっています。
現在はサポートも居ないと回りませんが、サポートが居なくても勉強会を回せるようにしたいと考えています。

ファシリテーター

  • 当日の司会進行
  • スライド用意
  • 当日の会議室、PC抑え
  • 金曜日には次回申し込み開始
  • 前日リマインド、当日10分前リマインド

サポート

書紀

  • 当日のタイムキーパー(5分前などになったら)
  • 勉強会の内容を書き留める(後日グーグルドライブ展開)

前日に何を話すのかというと、当日にすることの確認と、今後どうしていきたいか等です。

勉強会のふりかえり

勉強会が終わったらふりかえりをしています。
振り返る内容は、運営としてどうだったか、全体の雰囲気はどうだったかなどです。
そもそも、このまま読書会で良いのかというのも話したりします。

ふりかえる前に表明じゃんけん(ファイブフィンガー)を行います。
本のカイゼン・ジャーニーや「青木とと」さんのふりかえりを参考にしました。
(青木ととさんの場合はKPTのふりかえりですが……)

lycoris102.hatenablog.com

表明じゃんけん(ファイブフィンガー):
会や取り組みのふりかえりで自分の中で評価を数値化して、じゃんけんのように「せーの」でメンバー全員が手を出します。

5本:とっても上手くやれている
4本:うまくやれている感触あり
3本:可もなく不可もなく
2本:不安は少しある
1本:全然駄目で絶望的

ふりかえりをする前に表明じゃんけんをしていると、それぞれがどんな思いで、ふりかえりの会に参加しているか分かるため、とても良いと感じました。
中途半端な意見をさけるため、今は3本指は、たてないというルールにしています。

極端に意見が割れた場合、なぜその指をたてたのか、なぜ5本ではなく4本なのかなど聞くことが出来るので良いです。
表明じゃんけんをした後にKPTでふりかえります。

KEEP:
良かったことではなく、続けたいこと

PROBLEM:
問題なら何でも(なおすか、どうかは別問題)

TRY:
次回やること(PROBLEMやKEEPの内容と被るものもある)

KPTのツールにはトレロを利用しています。
参加者人数が安定しないものの勉強会自体は段々と改良出来ているように感じます。
ボイスレコーダーを導入してみたり。
ふせん張る時に剥がれることを考え磁石を購入して剥がれ落ちないように改善してみたり、時間配分を修正していったりなど。
昨日今日の打ち合わせでは読書会だけでは飽きるから別の会も主催した方が良いかもなどの意見が上がっています。

その他


主催しようと思ったのはUnityの勉強会に参加したり、enpelさんの技術書展の本を読んだり、「Unityゲーム開発者ギルド」にて「社内勉強会やりたいな」ボソっとつぶやいたら、様々なアドバイスが飛んできたからです。
青木ととさん、enpelさん、imo(井本)さん、ねぎたまさん、なかじ(nkjzm)さん、ないちさん……他にもココには書ききれない程の人にアドバイスを貰いました。
ありがとうございました。

enpelさんの本 booth.pm

後、勉強会を主催する前に他社さんはどうやって社内勉強会を主催しているのだろうと気になって、KMSさんの社内勉強会にお邪魔したりもしました。
呼ばれても無いのにお邪魔して、すみませんでした。(当日浮いてた)

(集合写真の一番右が私) kms3.com

他に、勉強会をする上で、ねぎたまさんに本を借りました。
勉強をしていくコミュニティを廃れさせないためにはどうすればいいか、どうやってコミュニティを大きくしていくかそういう内容がまとめられた「コミュニティ・オブ・プラクティス」という本を借りました。
指標となる本があることで次はどういうアクションをするのが正しいのか考えやすくなったので、とても役立っています。
ありがとうございます。早く読みきります、すいません。

まとめ


色々書きましたが、こんな感じで社内勉強会をはじめました。
弊社は勉強会が立ち上がっても潰れてしまう会社らしいので今後も続けていくためにはスケールアップや他の会の運営、運営の透明化などが必要だと感じています。
今回は運営の透明化や、やったことの公開を目的で記事を書きました。これを見て弊社の勉強会に参加するメンバーが増えたり、これから勉強会をやる人の誰かの助けになればいいなと思います。
また、キリのいいタイミングでブログ記事を書こうと思います。
読んでくださり、ありがとうございました。
Unityゲーム開発者ギルドにコミュニティオブプラクティスについて私がまとめた文や勉強会を立ち上げるまでに貰ったアドバイスなどをまとめてありますので気になる人はコミュニティに入ってみると良いかもしれません。
Unityを触っている開発者ならゲームを作っていなくてもOKらしいので、ないちさんに問い合わせてみると良いと思います。
Unityゲーム開発者ギルドは良いぞ。

scrapbox.io

以上、やまだたいしでした。