「夏のTechRachoフェア」2日目記事になります。
morimorihogeです。暑かったり涼しかったりな日々が続きますね。
弊社ではここ3年くらい、毎週木曜の昼休み明けの枠で社内勉強会の枠を取っており、その他にも就業時間後に有志で行われる勉強会など、継続的に勉強会の機会を設け続けてきました。
弊社は40-50人規模の開発会社ですが、この規模の開発会社で継続的な勉強会運営ができている会社は意外と少ないかも？と思ったので、どうやって社内の勉強会運営及び継続性を確保してきたかをまとめてみたいと思います。
書いていくうちに長くなってしまったので前後編に分けることにしました。前編は社内勉強会の企画～実施編です。後編ではどうやって継続して開催するか、という話を中心にする予定です。
※2019/07/29更新：後編を公開しました -> 3年間毎週社内勉強会を継続してきた秘訣（後編）
※読めばわかるかと思いますが、どの会社・組織でも適用できるベストプラクティスではありません。あくまで事例の一つとして読んでください
現在の社内勉強会運営状況
詳細を語る前にまずは現状の社内勉強会の運営状況をまとめてみます。
僕の観測範囲では、今弊社（BPS株式会社）では以下の勉強会が定期・不定期運用されています。
- 定例社内勉強会枠（毎週木曜昼休み明け14:00-）: 旗振り：morimorihoge ※本エントリの対象です
- 週刊Railsウォッチ（毎週木曜19:30-）：旗振り：hachi8833 & morimorihoge
- IPA情報処理技術者試験勉強会（毎週火曜19:30-）：旗振り：ohno
- 不定期もくもく会（ここ最近お休み中？）：旗振り：jhonda
色々ありますが、今回は社内では最も歴史の長い、ここ3年くらい運用されている定例社内勉強会枠について書いていこうと思います。
参考までに、定例勉強会では以下のようなテーマを毎週木曜昼休み明けに行ってきました。
僕が打ち合わせ等で出社できないケースを除きできる限り毎週欠かさず開催するようにしてきたので、僕の発表だけで140件くらい開催履歴があります。
※2016年くらいからやってますが、エクスプローラがこれ以上縦に伸びなかったので直近だけ
勉強会を始める前にやること
社内勉強会を始める前には、以下のことを順番にやっていきました。
- 目的と期待値（期待する形態）を決める
- コアメンバーを集める（量より質）
- 偉い人を味方につける根回しをする
目的と開催形態を決める
一番大事です。中途半端にふわっとしてると以後のフェーズで企画倒れか暴走します。
「勉強会」は今色々な文脈で利用されるため、どんな目的・形態でやるのかをしっかりと最初の内にイメージを固めることが大事です。
「目的」と「開催形態」、それぞれ大事なので順に説明していきます。
「目的」という切り口
そもそも何のために勉強会をやるのか、勉強会によって何を得たいのかというのはとても大事です。
ここ数年「勉強会」は純粋な技術習得目的なものから情報交換目的、採用目的、はたまた製品営業のものなど、それらの要素が複雑に絡み合って色々な人達の色々な思惑が絡んできています。
これはこの後の開催形態や根回しの仕方にも関わってくるので、発起人がしっかり意識すると良いでしょう。
以下はありがちな目的例です。
- 純粋に自分たちの技術習得をメインにしたい！（今回の対象はこれ）
- エンジニア初の勉強会は大抵これだと思います。発起人及び参加者が、技術的なスキルアップを目指す勉強会になります。
- 多くの場合開催・運営の手間はなるべく大きくせず、勉強会の中身の質を大事にしたいという方針に寄っていくと思います。
- 社内オンリー、社外公開どちらのケースも考えられます
- 自社のブランディングを強化して、エンジニア採用を強化したい！
- 採用担当者が主導で企画した場合、ゴールは「採用」になるケースが多いです。
- 企業側のメリットが明らかになるため予算は付きやすい傾向がありますが、採用目的が表に出すぎて中身が伴わないタイプの勉強会はエンジニアから嫌われることも多いため、バランス感覚が求められる印象です。
- 性質的に社外向けの勉強会となるため、社内エンジニアが参加するメリットが出せないと、協力者を集めにくいかもしれません。
- 自社の製品・サービスを使ってもらいたい！顧客拡大したい！
- 経営サイドが主導で企画した場合になりがちなやつです。ゴールは「売上・顧客数増大」となります。
- このケースの場合は、もはや対象がエンジニアですらなくなるケースもあります。製品紹介や宣伝、体験会のような形態になるかもしれません。
- でかい会場でたくさん人を集めることが重要になったり、モノによってはその場で購入・契約してもらう準備などの手配も必要かもしれません。
- 社外向け、かつ発表者はエンジニアではなく営業担当になるケースもあるため純粋に技術に興味のあるエンジニアは集まりにくくなります。
代表的な3種類の目的を出してみましたが、発起人として大事なのは「何が一番大事かを決める」ことです。勉強会開催にあたって参加・協力するメンバーが増えていく中で、それぞれが少しずつ違う目的に向かって走り出してしまうことがあります。そうしたときに、バランスをどのあたりに置くかという基準となるものなので、大事にしましょう。
それぞれの目的は必ずしもトレードオフの関係になるとは限りませんが、具体的な動きをはじめたときにトレードオフが発生することがあります。そういったときに発起人が「この勉強会の目的や落とし所はこうしたいから、そのやり方はNOだ」と言えるようにしておくことが大事です。
自分のやりたかった方向性から離れて暴走してしまうと、発起人のやる気がどんどん削られていってしまうので、目的はなあなあにせずに持っておくのが良いです。
風のうわさには「最初はエンジニア主導でワイワイやっていたのに、採用・経営層が自分たちのやりたいようにテコ入れしていったことでエンジニアが離れていってしまって消滅」というケースを聞くこともありますので、悲しいことにならないようにしたいですね。
「開催形態」という切り口
以下は社内勉強会で僕が話した「勉強会のスヽメ」という発表の記事から抜粋したものです。今回の趣旨にちょうど良さそうなので貼り付けます。
- テーマを決めた「XXX勉強会」
- おそらくICT系エンジニアの中では最も親しみのあるタイプだと思います。小規模なものでは社内勉強会から大きなものではTech Conferenceなんかも広義のなかではここに入る認識です。
- 発表者と聴衆という講演スタイルになるため、発表者の発表の質==勉強会の質となる傾向が強いです。
- 大抵発表者を集めるのに苦労することが多いため、最近ではLT（Lightning Talk）など、発表の敷居を下げる試みなども盛んにされています。
- このタイプは聞きに来る人は時間さえあれば参加できるのでお手軽な一方、発表者は事前準備などでそれなりにリソースを咲く必要があるという傾向があります（ただし、その分発表者が得るものも大きい）。
- ワークショップ系
- XXXワークショップ、YYYチュートリアル、ZZZハンズオンなどの名前で開催される、参加者が実際に手を動かすスタイルの勉強会です。
- 人数規模や参加の前提条件にもよりますが、あまり高度な内容にしすぎると参加者が脱落していくので、高度な内容の場合は詳細な手順書が用意されたり、レベルを控えめにして（または開催時間を長めにして）脱落者を減らす試みがされることが多い印象です（たまにガチなのもある）。
- 実際に参加者が手を動かして形ある成果が得られるので「何かやった感」が強く得られるのが魅力です。
- 企業が自社製品やライブラリ、力を入れているOSSなどを対象として開催するケースも多くあります。
- ハッカソン・コンテスト系
- 制限時間以内に各自何かを作って発表するスタイルの勉強会です。
- 「お題」が用意されることが多く、その中で創意工夫して個人やチームで何かを作り上げていくスタイルです。
- 参加にあたっては「すでにある程度モノを作れること」という前提条件がつくため、完全に何もできない人は参加を断られる可能性があります。
- ビジネスコンテスト風味なベンチャー支援臭の強いものから、一発ネタで笑いを取りに行くなど色々な趣旨・人たちがいますが「何か作りたいけど作りたいものがない、作りたいものがあるけど一人で作るには力が足りない」といったケースではマッチするかもしれません
- 輪読会系
- 書籍や論文などを対象に、参加者複数人で手分けして内容を詳細に読み・お互いに読み進めていくスタイルです。
- 難しい本や、英語書籍などの一人で正しく読むのが難しい本などが対象になることが多いです。
- 読みたい人だけ集まってやるケースもありますが、1～2人は「先生役」としてきちんとその内容について理解している人がいたほうが「参加者全員が内容を間違って理解してしまう」というリスクが避けやすいです。
- シンポジウム系
- 主に企業や団体が自分たちの製品や取り組みの宣伝目的で行う会です。
- 厳密には勉強会ではないと思いますが、企業によっては「勉強会」という名目でこのタイプの会を行うケースがあります。
- 内容としては製品紹介や事例紹介など、発表者側も開催側も「仕事としてやっている」感が強い、ビジネス色の強い会になりがちです。
「勉強会」という言葉が色々な意味を持ってきてしまった昨今、どういった開催形態のものを自分が望んでいるのか、人に伝える際に勘違いのないようにしたいところです。
その他の要素
目的・形態が決まったら、以下のような点も考えていきましょう。
- 頻度：週次・月次・不定期？
- 時間：1時間程度？半日？全日？
- 人数規模：～5人？～10人？～20人？それ以上？
- 募集範囲：社内のみ？社内＋知り合い内のみ？社外もOK？
- 形式：講演方式（発表者＋聴衆）？持ち回り方式（発表者＝聴衆で持ち回り）？
これらを決める際にオススメなのは最初から高望みしすぎず、失敗しないラインからはじめることです。
1回やって終わりにする勉強会であれば構いませんが、反応が良ければ2回目も・・・と考えるのであれば、小さな成功体験を積み上げることで、周りからも成功しているように見せることが大事です。
イベント開催経験が多数ある人であれば別ですが、それほど経験がない場合は特に最悪コアメンバーだけでもなんとか運営できる規模にすることをオススメします。
コアメンバーを集める
大体会の方向性が固まったら、次はコアメンバー（発起人含む）を集めましょう。
開催規模にもよりますが、継続性のある勉強会をしたいなら、コアメンバーは最低2名は欲しいです。
小規模で1回だけ・不定期開催なものであれば一人で頑張ってもなんとかなりますが、長く続けるにはモチベーション的な都合や緊急時の対応も含め、バックアップが欲しいところです。
コアメンバーを集める際には広く広告してもいいですが、基本的には一本釣り方式で個別に声をかけるほうがうまくいくケースが多い印象です。
なお、人数が集まりすぎてもうまくいかないです。発起人の開催目的をしっかり理解してくれて、同じ方向を見て動ける人を集めましょう。
小規模な勉強会であれば、まずは一回目を開催してみて反応の良かった参加者の中からコアメンバーを探すという方式も可能です。そのためにも1回目の開催はなるべく自分の目的に沿った理想的な会になるようにがんばりましょう。
コアメンバーに大事なのは「やる気と価値観の一致」です。「偉い人（決裁者）」に声をかけるのは次のフェーズにしましょう。
偉い人（決裁者）を味方につける根回しをする
ここまで来たらいよいよ開催に向けて動き出します。
どんな会社でも社内には色々な価値観を持つ人がいるため、最初から全員に支持されると思わないほうが良いです。価値観や役職によっては「勉強会の準備や開催をしている時間があるなら業務しろよ」と思う人も出てくる可能性は大いにあります。
まだ開催したこともない勉強会に対する熱量は発起人とその他の人たちでは天と地ほどのさがあるため、気持ちとしては無関心上等、最初から良い反応が返ってくるほうがレアくらいに思っておきましょう。
こうした中でうまくやるためには明確な反対者を生み出さないことが大事で、そのためには偉い人（決裁者）の力を借りるのが手っ取り早いです。
個人的な価値観で良い印象を持っていない人でも、上長や役員が承認している「会社の決定」にまで反対してくることは、それが直接当人の不利益にならない限りはそうそうないものです。
偉い人を説得するためには色々な考慮事項がありますが、まずは声をかける前に、どの程度会社の了解が必要そうなのかを再考しましょう。
業務時間外に空き会議室を使って社員だけが集まってやる程度の勉強会であれば、そこまでうるさく言われない会社も多いとは思いますが、土日に社外の人を呼んだり業務時間中の開催などを考えていたりする場合、それなりに事前の根回しをしておかないと面倒なことになる可能性があります。
このあたりは会社によっても方針が違うと思いますので、自社の風土や過去の同様な企画をやったことのある人に聞いてみるのが良いでしょう。
必要なリソース感がわかってきた上で、以下を検討します。
- 誰に声をかけるか？
- 目的や趣旨にある程度賛成してくれるであろう人、かつ必要なリソース手配ができる権限を持っている人に声をかけます。
- 組織・会社に対するメリットを整理する
- 実際にどれくらいのリソースを要求するのかにもよりますが、会社のリソースを消費する分どれだけメリットがあるのかは説明すべきです。リソース消費が極小な場合はデメリットがないという説明でもありです（少し押しは弱いですが）。
- この説明の仕方は所属組織の文化に応じた「受け入れられやすい」ものにしておく必要があります。
- 例1）社内メンバーのスキル向上によって自社開発チームの開発力を上げることができる（メリット）
- 例2）業務時間終了後の空き会議室を使い、打ち合わせなどが入る場合はそちらを優先して運用するので、会社の追加負担はない。（デメリットのなさ）
この根回しの難易度は、どれくらい会社や組織のリソースを使うのか、所属組織の文化や価値観、前例のあるなしによって大きく変わってきます。
例えば、業務時間中に開催する場合は実質会社がその勉強会に人件費を払っているのと同じ状態になるので「やりたいから」だけでは認められづらいでしょう。懇親会で食事などを出したければ現金もかかりますし、社外の人を呼び集めたりする場合には来場者対応のスタッフ、セキュリティの考慮も必要になってきます。
ある程度大手の企業になってくると部署やチーム予算などがあったり、人事が勉強会サポートスタッフをやってくれるケースもありそうですが、中小企業だと大抵は仕組みが無いところからのスタートになります。
仕組みが無いところに新しいことを始めようとする場合には、多かれ少なかれ理由の説明が必要というのは世の常なので、このあたりは多少面倒でも後々敵を作らずに進めるためには手を抜かずにやっておきたいところです。
勉強会開催が決まったら準備すること
第一回の勉強会は特に力を入れて成功させましょう。
「成功」とは「目的」を達成できるような会にできたかどうかです。人数を集めてもいまいちな会もあれば、人数が少なくても内容の濃い会というのはあります。
特に第一回は「次」をやろうとしたときのモデルケースになるため、手を抜かないことが大事です。もしやろうとしている勉強会が所属組織ではじめての勉強会だった場合、大コケすると次回開催の難易度が上がってしまいます。
確実に参加する層に声をかけ、最低限の開催条件を満たす
いきなり全社アナウンスなどはせず、まずは確実に参加してくれそうな層に声をかけます。「最悪このメンバーだけでも開催しよう」と思える人たちから参加の合意を得ましょう。
ここでは「みんなが参加するなら僕も」という層は後回しで、参加の意思の強い人を少なくても良いので集めます。
一人でいきなり声をかけてはじめても周りは巻き込めません。最初は一人ずつ声をかけてみるのがコツです。
ある程度参加者が集まると連鎖的に「みんなが参加するなら～」という層も入って来てくれますので、まずは地を固めましょう。
＃ このあたり、群衆の英知もしくは狂気なんかがイメージとして参考になります。
また、講演方式やワークショップ型の勉強会をやる場合は、この時点で主催者以外にも発表・先生役をしてくれる人を探し、協力を依頼しましょう。
アナウンス時点で広く募集しても良いですが、主催者枠以外がスカスカの講演枠は埋まりにくいです。
社内アナウンスする
ここまでで最低限の開催が確定できたので、社内アナウンスしましょう。
日時、場所、テーマなどは当然ですが、初回の場合は会の趣旨も併せてアナウンスすると良いでしょう。
また「よくわからないけど新しいことをやるのは自分たちの迷惑になるかもだからなんとなく反対」という勢力が出る可能性がゼロではないので、前述の根回しした偉い人に許可を得た公認の会であることもアナウンスすると良いです。
※アナウンス自体を偉い人にしてもらう、というのも効果的です
もし出席人数を事前に把握する必要があるような会の場合には、前節で声をかけた人たちが既にエントリー済みのエントリーフォームを用意すると良いでしょう。
声掛け済みの人は基本的に会の趣旨に賛同している人たちなので、メンバーを見せることでなんとなくどんな雰囲気の会になるのかなども社内メンバーであればある程度わかると思います。
なお、エントリー0人の状態でフォーム公開するのは様子見する人たちが出てしまうため、人数を多く集めたい場合にはこういうところも気を遣えると良いと思います。
開催前にリマインドする
初回や不定期開催の場合は特に、前日及び当日あたりに改めて開催のリマインドを流すと良いでしょう。
リマインドすることで、
- 純粋に会を忘れていた人が忘れず参加してくれるようになる
- ほぼ固まった参加者名簿を見て「XXさんが参加するなら僕も」という人が追加でエントリーしてくれる可能性がある
- 今回勉強会にまだ興味のない人にも「やってるよ」感を広告することができる
といったメリットが得られます。
なお、懇親会などでお金のかかる予約・手配を行っている場合、キャンセルがあるととても大変になります。リマインド及び懇親会参加確認はより慎重に行ったほうが良いです。
※可能なら人数の多少の増減に対応できる形態が良い
勉強会当日
当日の動きは会の形態や規模によって大きく異なるので一概に言えることは少ないのですが、主催者側として意識すると良いのはなるべく多くの人に満足してもらえるように努め、可能な限り「不満」な人をゼロにすることでしょうか。
参加者の満足度を最大にすることはそれはそれで大事ですが、もし社内の文化として今後も勉強会を開催していきたいという思いがあるなら「不満」と感じる人を減らすのはもっと大事です。
「不満」を感じる部分は人それぞれですが、例えば過度な身内ネタや差別的・攻撃的な内容などは控えると良いでしょう。
明らかにNGな内容については、例えばRubyKaigiで用いられているようなアンチハラスメントポリシーを広告したりするのも良いと思います。
また、プログラマが集まるとエディタ戦争やSIerあるあるな闇深いデスマ話などはネタとして盛り上がりやすいトピックですが、冗談を冗談として笑えない性格や立場の人もいるかもしれません。
内輪話は輪に入れれば面白いですが、輪に入れない人は楽しくないものがほとんどなので、広めに人を集めて開催する場合には特に注意すると良いでしょう。
＃ このあたり、僕もたまにやりすぎてしまうことがあり反省することがあります
その他、実際に開催することで「こういう風にできたらもっと良かったね」「XXXはないの？」といった意見を色々ともらえると思いますが、何よりも一番苦労するはずの主催者が満足できる会にできたかが大事です。
勉強会開催はほとんどの場合で主催者のやる気によって支えられていると言って過言ではないので、自分のモチベーション管理もまた大事にしましょう。
BPSの社内勉強会では？
長々と書いてきましたが、3年間続いている弊社の週次社内勉強会では以下のような運用となっています。
目的
社内エンジニアのスキル向上、及び技術や業務ノウハウの共有を行うことで、全体としての出力を向上させる。
全社的に技術習得やスキルアップに対して前向きであるという文化を醸成していく。
運営形態：いわゆる講演方式
希望者がいれば適宜お願いしつつ、いなければmorimorihogeが発表ネタを持ち込んで話しています。大体30分～最大1時間の枠で、社内の少し広いスペースを使って行っています。昼過ぎの業務時間中に行っているため、懇親会などは特にやっていません。
開催人数規模：5～20人程度
内容やタイミングにもよって人数は大きく変動しますが、概ね10人弱程度が参加してくれているようです。
参加の可否：社員は自由（プロジェクト状況により上長と要調整）、社外の人は特例を除きターゲットとしない
社内ネタの話をしづらくなるため、基本は社外非公開前提でやっています。問題解決系の話の具体例を出そうとするときや、特定プロジェクトで起こった話などをする場合、NDA等の都合で社外公開を前提としてしまうと内容が薄まったり準備が大変になります（NDAの影響のない発表用のサンプルコードを用意するなど）。
※NDAなどに抵触する可能性のない内容の場合はたまたま採用面接で来ていた方などに参加してもらうことなどはあります。
なお、業務が忙しくて部屋まで来られない人向けの社内向け動画配信中継も行っています。こちらについては後日担当メンバーが記事を書いてくれると思いますので詳細は省きます。
内容：技術トピックから業務系の内容までありだが、遠回りでも業務に関連するもの
業務時間に実施しているため、発表内容は多少遠回りでもいいので一応業務に関連する内容ということにしています。
勉強会に参加してないメンバーは普通に業務をしているので、あまりにもお遊びな内容は心証よくないよね、というところもあります。
利用している社内リソース
- 社内打ち合わせスペース（毎週固定予約・1時間）
- 参加・発表メンバーの参加・準備時間（参加者10名1時間、発表者準備4時間として1回14人時くらい？）
というわけで、会社から見た場合はほぼ人件費ですね。扱いとしては社内教育・技術研鑽といったカテゴリに属すると思います。
前編まとめ
というわけで、前編では社内勉強会を企画・開催するにあたって注意してきた点などをまとめました。
BPSの場合は元々エンジニアメンバーが主体ということもあり、社内勉強会そのものを開催するにあたっての障害はそれほどありませんでしたが、人数が増えていく中で舵取りや運用については微調整したりしてきました。
それほど特殊なことを書いたつもりはないので、おそらく多くの開発会社やエンジニアチームなどで応用できるのではないかと思います。
・・・と、ここまで書いてきた内容であえて詳細を避けてきたものがあります。それは主催者・発表者のモチベーションをどうやって継続して保つかという点です。
この辺を書いていこうとするとまだまだ長くなってしまいそうなので、前後編に分けることにしました。夏のTechRachoフェアは8/30まで実施予定なので、それまでには後編を用意したいと思います。ではでは。
※2019/07/29更新：後編はこちら -> 3年間毎週社内勉強会を継続してきた秘訣（後編）