EM・テックリード向け 50人規模の勉強会が50回以上続いた話
こんにちは。ドリーム・アーツの伊勢川です。
この記事では、勉強会の主催・継続に苦労されているEM・テックリードの皆さんに向けて、勉強会を継続する工夫について紹介します。
勉強会の概要
ドリーム・アーツの製品開発本部では、部内のエンジニアやデザイナーを対象とした勉強会を隔週で開催しています。任意参加ですが毎回50-60人が参加する人気の勉強会で、50回以上続いています。
なぜ始めたか
2023年頃、コロナ禍以来リモートワークが長く続き、日常業務には支障はないものの、業務と直接関係のないコミュニケーションの機会がコロナ禍以前と比べて減っていました。
「協創」をミッションに掲げるドリーム・アーツにとって、チームを超えた有機的で偶発的なつながりは非常に重要なことであり、その機会をどんどん増やしていきたい。
そこで、まずはチーム横断の勉強会を企画し、各チームの知見を共有しあう習慣をつけることで、チームを超えた助け合いが発生しやすい状況を作ることを目指しました。
勉強会のテーマ例
漠然とチームの知見を共有してほしいと言われてもイメージしにくいため、まずは特定のテーマを設けて、それに対する知見を募集しました。
テーマは狭くなりすぎないよう、品質特性や副特性レベルの抽象的なものを指定しました。そして、1-3月は「性能」、4-6月は「UX」などのように期間を決めて、各チームから発表内容を募集しました。
募集して待っているだけだと、発表者や発表チームが偏ってしまうため、最初のうちは各チームのマネージャーと定期的な企画会議をして、ネタと発表者を指定してもらうようにしました。
実際発表してもらったテーマは下記のようなものがあります。
- 性能
- 性能概論
- SmartDB※の性能試験と性能改善事例
- Shopらん※の性能試験と性能改善事例
- InsuiteX※の性能試験と性能改善事例
- DBのパフォーマンス・チューニング
- データベースのアーキテクチャとパフォーマンス
- 42 Tokyo バックエンドチューニングコンテストの技術詳細の共有
- 性能に関連したポストモーテム共有
- UX
- UX概論
- エンジニアのためのデザイン基礎
- デザインシステムの共有
- SmartDBのUI改善事例
- ShopらんのUI改善事例
- InsuiteXのUI改善事例
- テスト
- LeanとDevOpsの科学のおさらい
- テスト概論
- SmartDBのテスト
- Shopらんのテスト
- InsuiteXのテスト
- 生成AI
- 生成AIの仕組み、プロンプトエンジニアリング、エージェント、リスク
- 製品の価値向上にどう使うか
- 開発業務にどう使うか
- 今後のソフトウェア業界にどういう影響が出るか
- セキュリティ・信頼性
- クラウドセキュリティの概論
- SmartDBのシステム構成
- Shopらんのシステム構成
- InsuiteXのシステム構成
- ゼロトラスト/多層防御
- MITRE ATT&CKについて
- github利用ポリシー
- github actionsの利用時の注意点
- 鍵管理ポリシー
- ローカル開発環境の注意点
- Secure by Desing, Secure Coding
- アプリケーションの静的解析・動的解析
- 脆弱性の事例
- セキュリティ関連のポストモーテム共有
- ドメイン知識
- 各製品のカスタマーサクセス事例の共有
- 現場訪問レポート
※「SmartDB(スマートデービー)」, 「Shopらん(ショップラン)」, 「InsuiteX(インスイートエックス)」は自社製品の名称です。
勉強会の進行に関する変遷
初期のタイムテーブル
アジェンダ | 時間 |
---|---|
メインテーマ | 20分 |
全体で質疑応答 | 5分 |
ブレイクアウトルームでディスカッション | 10分 |
LT1 | 5分 |
LT2 | 5分 |
最初の頃はオンラインの参加者が多かったため、メインテーマの発表の後に、ブレイクアウトルームでディスカッションをする時間を設けていました。
しかし、コロナ禍も明けて徐々にリアル参加が増えて、リアル参加者の人数も加味した自動的なブレイクアウトルームの割当が難しくなりました。また、わざわざディスカッションの時間を設けなくても、その前にチャットで議論が盛り上がっていることも多かったため、ブレイクアウトルームでのディスカッションは廃止しました。
代わりにメインテーマを最後に持っていき、勉強会が終わった後に続けて話したい人は、各拠点でディスカッションができるよう、会議室を予定より少し長めに予約するという運用に変えました。
またLTが思いのほか人気コンテンツとなり、気合いを入れて資料を準備して時間オーバーする人が増えたため、当初5分だったLTは7分までOKとしました。
メインテーマの他にも、突発的に共有したい内容が出てきたときには割り込めるよう、予備の枠も設けました。
現在のタイムテーブルはこんな感じです。
現在のタイムテーブル
アジェンダ | 時間 |
---|---|
LT1 | 7分 |
LT2 | 7分 |
メインテーマ | 20分 |
予備 | 10分 |
何度か訪れた存続の危機と対策
勉強会を継続していく中で、何度か存続が危ぶまれる時期もありました。ありがちな内容ですが、それを乗り越えた過程なども含めて紹介します。
支援者の異動
1つ目の危機は、大きめの組織変更の際に、勉強会の立ち上げを後押ししてくれた本部長が、別の本部に異動になったことでした。その際に、これまで勉強会運営に協力してくれていたマネージャー層の顔ぶれも変わり、勉強会の意義や背景から説明が必要になりました。発表のネタ提供や、発表者のアサインも各チームのマネージャーに依存していたため、協力が得られないと存続が難しい状況でした。
そこで、まず新しい本部長やマネージャーに勉強会の意図を説明し、一度勉強会に参加してもらいました。また、新しく入った本部長やマネージャーにも自己紹介LTの発表をお願いし、この勉強会の場で発表をすると、部内のコミュニケーションがスムーズになるという効果を実感してもらいました。
最初のうちは、その効果に懐疑的な人もいたと思います。しかし、何度か勉強会に参加してもらって、そこで発生する議論などを聞いてもらうと、だんだんと協力的になって、いいネタがあるときには提供してもらえるようになりました。
運営者の長期休暇
2つ目の危機は、これまで勉強会を企画・運営してきた私が育休に入ることでした。企画・運営の細々したタスクは一人でやっていたため、私が休みに入ると存続ができません。
そこで、この機に一人運営をやめて、きちんと企画・運営チームを組成することにしました。
まずリーダーは、メンバー育成や組織化に強い人の心当たりがあったため、その人に打診。
次に企画・運営のメンバーは、各チームから1人は入る形で協力を依頼。勉強会を企画するのが得意そうな人、エンジニアやデザイナーのコミュニケーションのハブになってそうな人、それなりに業務経験があってこういう活動をしても自分のメインの仕事がちゃんとできそうな人に声をかけました。
みんな快く協力してくれて、これにより、運営者がいなくなるという問題は回避できました。引き継ぎ期間で企画運営に関するやり方を資料化してもらい、チームとしての活動が無事スタートしました。
ネタの在庫切れ
3つ目は危機というよりは、ただのありがちな問題ですが、ネタの在庫切れです。計画的に発表依頼をしていなかったために、発表できるネタの在庫が切れるケースもあれば、時期的にあまり発表できるネタがないといった在庫切れのケースもあります。
ネタの在庫が枯渇しないよう、ネタを集め&ネタづくりのための工夫としては、下記のようなことを行っています。
ポストモーテムの共有
勉強会で発表してもらうネタは、なるべく発表者の負担にならないもので、かつ、参加者の学びが大きいものが理想です。その理想的なネタの一つが、ポストモーテムの共有です。
障害が起こった際や、障害につながるヒヤリハットがあった際に、ふりかえりを行っており、それをポストモーテムと呼んでいます。ポストモーテムの結果は、「SmartDB(スマートデービー)」に登録しているため、勉強会用に資料を準備をする必要がありません。また、他のチームにとって参考になる内容も多く、他の製品がどういう対策をしてきたのかを教えてもらうきっかけにもなり、発表者にとっても、参加者にとっても学びの多い内容になります。
このポストモーテムを在庫として持っておくことで、予定していた発表者の都合がつかないときなどに割り当てることができます。(もちろん急ぎ共有すべきようなポストモーテムがあるときは、勉強会の開催を待たずに共有しています。)
雑談チャンネルや週報のチェック
他にも勉強会のネタを探すために、情報集めの取り組みをやってきました。
例えば、業務で使っているチャットの中に雑談専用のチャンネルや、週報の内容をたまにチェックして、いいネタを持っている人がいないかを探しています。
また、1on1ミーティングや雑談の際に、最近取り組んでいることを聞いてみるとよいネタが出てくることが多いです。
ネタ集めの体制とマネジメント層の協力
個人でのネタ集めには限界があるため、ネタ集めの体制と各チームのマネジメント層の協力が不可欠です。
前述の通り、企画・運営チームを組成したことにより、各メンバーからネタが集まってくるようになりました。また、各チームのマネージャーの協力が得られたことで、各チームで力を入れている取り組みや、技術的な詳細まで共有した方がいいようなネタが、企画・運営チームに集まってくるようになりました。
その他、継続のための工夫
存続の危機を乗り越える以外にも継続をするための工夫があり、いくつか代表的なものを紹介します。
人気シリーズ
「私の仕事紹介」というLTを毎回2人ずつ持ち回りでお願いしており、これが参加者が継続的に集まる人気シリーズとなっています。顔見知りの人でも、過去にどんな仕事をやってきた人かを知る機会はあまりなく、このLTを通じて、一緒に働く人に対する興味や理解が深まるのが人気の理由の一つだと思います。
参加者が多い場合、持ち回りの発表は準備の負荷を分散できるため継続がしやすいです。ただ、発表日程を忘れる人もいますし、突然参加できなくなることもあるため、日程のリマインドや当日変更に備えた予備の発表者の手配などの対応が必要です。
このような、普段は知ることができない人となりを知れるようなテーマは人気コンテンツになりやすいと思います。
社外のネタの活用
ときには社外の知見を取り入れることで、新しい視点が加わり、社内の勉強会がマンネリ化しないよう工夫しています。例えば、社外の取引先の人に講演を依頼したり、社外の勉強会に参加した人に参加レポートを発表してもらったりしています。
例えば最近では、DBの専門家の方にパフォーマンス・チューニングに関する発表をしてもらいました。また、今月は関西で開催されるシンポジウムへの参加者を募ってその内容をレポートしてもらう予定です。
社外情報発信の道づくり・採用活動への貢献
最近では、社内勉強会で発表したネタを、社外のテックブログのネタとして再利用することで、採用活動にも貢献しようとしています。
社外に情報発信する道を作ることで、内容のクオリティ向上につながり、発表者のモチベーションアップも期待できます。
また、採用活動に結びつけることで、予算が確保しやすくなり、前述の外部講師の招待など、お金がかかる施策も実施しやすくなりました。さらに、ドリーム・アーツは全社員が採用活動に関わる「全社採用」を掲げており、勉強会が全社採用に貢献することが明確になり、より活動がやりやすくなりました。
今後のチャレンジ
今後は社外にも公開された勉強会にチャレンジします。まずは、今月末に第一回の勉強会を開催予定です。社外の方も参加可能です。個人開発やOSS開発に興味のある方、AI ✕ ワークフローエンジンに興味のある方は、ぜひご参加ください。
タイトル:個人開発から始めたOSSが2K Starを獲得するまで
講師:Yota Hamada 氏 (Descarty株式会社 代表取締役)
急速に人気が高まっているOSSの軽量ワークフローエンジン daguの開発者。
TypeScript Deev Diveの翻訳や、Go言語によるDDDの記事を執筆。
日時:2025/6/25(水) 19:00-20:30
場所:恵比寿ガーデンプレイスタワー 29F ドリーム・アーツ オフィス内
申し込み:https://dreamarts-pr.connpass.com/event/357735
また、おまけのLTとして、『個人開発から始めるB2B SaaS』というテーマで私も登壇予定です。こちらもご期待ください。
まとめ
勉強会を継続するための工夫をまとめると、次の3つに集約できると思います。
- しかるべき人(偉い人と現場の実力者)を巻き込み組織化する
- 人気コンテンツをみつけてシリーズ化する
- 勉強会の運営の手間を減らしつつ、わかりやすい成果(採用など)に紐づく活動にする
当たり前の内容ですが、こういった当たり前の要素をうまく組み合わせることで、好循環が生まれ、実際にはそこまで労力をかけなくても、みんなのちょっとずつの協力で運営を続けられるようになります。
この記事が、社内勉強会の継続に悩む皆さんに少しでも役立てば幸いです。
Discussion