この記事は
Applibot Advent Calendar 2020 および
CyberAgent Developers Advent Calendar 2020の記事になります。
前日は@tenonnoさんの「UnityプロジェクトにC#8.0,9.0を導入してみた」という記事でした。
はじめに
私が(株)アプリボットにサーバサイドエンジニアとして中途入社して、すでに3年以上が過ぎました。
入社してすぐ、社内でLT会があるとのことで参加し、
お酒（感動）と軽食が振る舞われる中、絶妙に暗く狭いMTGルームで発表を聴いたことをよく覚えています。
恐らくそれが社内LT会の第1回目でした。
第2回目の会ではLT発表も行い、少しずつ話せる仲間が増えていく大きなきっかけになりました。
数ヶ月してすぐ、LT会の運営の手伝いの一端を任されることになり、
それまでほぼコストを掛けず運用していた色々な用意（酒や軽食や席配置やLT登壇者など）に
勝手にモチベを持ち、力を注いでいると、半年もする頃にはほぼ一人で運用をすることになっていました。
そのまま色々な形を遂げながら毎月のLT会を続け、それももう3年以上になります。
会社の人員の増加は勿論ありますが参加者は当初の倍以上になり、
社内エンジニアの大半が登壇経験者なのではないかと思います。
覚えている限りにはなりますが、社内でのLT会の立ち上げと、どのように目的や形を変えてきたのかお話しします。
この記事はノウハウや技術記事というより、アプリボットにおける一例としての経験談です。
LT会・勉強会を行うこと
勉強会やLT会には開催する意図があります。
外部の勉強会は採用やサービスプロモ目的などのものも多くあり、
目的やレベルにあった勉強会を選ばないと得られるものの少ない経験をすることになります。
大学院生・社会人1年目の頃は見分けがつかず、何も得られない時間を過ごした事もありました。
新卒で入社した会社には、社内で個人が自由に勉強会を開けるシステムがありました。
社内の勉強会カレンダーにテーマと名前を入れると参加登録できるようになり、勉強会を開く仕組みです。
何度か参加しましたが、お互いにお互いの普段の業務やレベルが分かっており、
「単純に何かを教える・教わる」という目的も明確だったため、
有意義な知識を得られる勉強会が多かったように感じます。
社内での勉強会は聞き手と登壇者が、お互いの目的やレベルを把握しやすく、
コミュニケーションも無駄になりにくいので大きなメリットを得やすいのではないかと思います。
その時は割と頻繁に勉強会が開かれていましたが、
アプリボットに転職すると自主的に勉強会を行う人は少なく、これは社内の雰囲気や文化なのだと知りました。
勉強会はどのように作るべきか
勉強会やコミュニケーションが苦手な方がある一定数いることは把握していますし、
実際、意識だけ高い雰囲気を出した価値の薄いものや、
目的やレベルのマッチングがしにくい企画や、コミュニケーション力を求めてくる勉強会もあると思います。
しかしこれまで以上に技術の話が気軽にでき、
情報を誰が持っているか知ることができるようになることは
仕事のしやすさにも直結しますし、知見や経験を育てられるので組織として価値があります。
社内勉強会を活用するメリットは確実にあると感じたので
マッチしない勉強会を機械的に開くことに意味があるのではなく、
勉強会の運用や内容は、環境とメンバーに応じて変わるもので、文化として段階を経て育てていくものだと考えました。
そういった社内勉強会を通じて作られる文化をアプリボットでも作りたいと思い、何か出来ることはないかと考え始めます。
LT会の立ち上げ
当時、社内での勉強会は時々開かれる事はあっても定期的に開催されるものではなく、
定期的な勉強会が継続しなかった経験もしていると聞いています。
私が転職してきた時、アプリボットにはA.R.T.（Applibot Root Technologies）という技術基盤チームがあり、
この活動報告を行うことを大きな目的の一つとして、定期的に行うLT会を企画し始めたところでした。
A.R.T.には社内でも技術力の高いエンジニアが少数精鋭で所属していたので
そのエンジニア達を中心として開かれたものでした。
社内の中心メンバーが顔広く人員を集めることで始まり、当時参加者は10~15名前後です。
当時の運営は私の前任だったエンジニアがほぼ1名で行っており、
LTメンバーを2〜6名誘うことと、軽食とお酒を発注して当日のMTGルームを抑えることが仕事です。
LT会は定時後に開催され、
大体固定のメンバーが大半と、その時々で途中で参加退室するメンバーがちらほらいて
LTが終わるとあとは自由に、残ったお酒で自然と飲み会が始まり23時頃に解散するような流れです。
これが今の社内LT会の原型です。
この勉強会を手伝うようになったので、運営をより良く出来ることはないかと考えました。
回り始めるまで
問題点
LT会を企画してはいましたが、参加メンバーがあまり変わっていなかったことと、
運営の企画頼りなので開催頻度がまちまちで、このままだと過去の勉強会のように疲れていずれ無くなる危機感がありました。
イベントなどの継続運営は、**「モチベがある誰かが頑張る」か「勝手に回るように文化にする」**ことのどちらかが必要です。
初期の運営ではもちろん前者で、かつ能力の高い中心エンジニアが引っ張っていましたが、
それ故多忙だったこととモチベがあるメンバーだけが頑張り続けると、
人依存なので疲れて心が折れたり、辞めた時にイベントも消えてしまいます。
理想と目的
まずは着実に走り初めて、習慣にし、より多くの人を巻き込んで文化にして、自然と開催されるようになる流れが理想です。
継続運用はなるべく運営コストを掛けないことがポイントだと言いますが、
その反面、価値が薄まってしまう危険があるので、
順を追ってちゃんと回り始めるまではそれなりのコストが必要です。
自分だったらそのコストが払えると判断したので、
身軽な自分自身でモチベを高く持って推進力を上げることから始めることにしました。
目的がブレないように軌道に乗ってから運営のメンバーを増やせばいいのではと考えたからです。
社内で勉強会をすることの意味として、
「技術共有」と「コミュニケーション」という目的に大別出来ると思いますが、
技術共有はコミュニケーションが出来れば自然としやすくなると考え
第一の目的として**「（技術共有を通じて）コミュニケーションが取れる場にすること」にしました。
そのためまずは勉強会のKPIとして参加人数を増やすこと**に定めました。
これは単純なようで難しい課題です。
組織やゲームの運用と同じく、いかに固定メンバーを作りながら新規参加者を継続的に増やすかがポイントになります。
また、私個人的な思想と経験から、
知識・経験に差のあるメンバー（慣れたメンバーと新規参加者や、クライアントとサーバなど）が
どちらの楽しみや価値を損なわずに一緒に何かを行うには、
**「レベルを分けて住み分けられるようにする」か、「経験者が初心者をサポートして共生する文化を作る」**のどちらかだと考えています。
社内勉強会においてコミュニケーションを第一目標にしていたので、後者を理想とし、
特に内容などを分けることなく、レベルや内容、サーバー・クライアント合同のLT会にすることに決めました。
慣れたメンバーが新しい人を自然と歓迎したり、技術的な補足などが雑談レベルでも出来れば良さそうです。
また当初からのコミュニケーションに時間を取る流れを引き継ぎ、
前半はお酒と軽食を楽しみながらLTなどの勉強会コンテンツを行い、
後半はその場の流れでコミュニケーションの場として飲み会が出来るスケジュールにします。
多くの人数が負担なく参加できるように月1での開催です。
具体的な改善
目標や座組が決まったので要素を徹底的に洗い直しました。
- 毎月規則性を持たせて定期的に開催する
習慣化しておくことで参加者のスケジュールに前々から入れてもらうと良いでしょう。
-
なによりも参加ハードルを下げる
- 参加する目的や交流のレベルに自由度を持たせる、何かを強制することはしない
- 会や、声の掛け方を義務っぽく重苦しくしない
- ちゃんと開催意図を伝えておく、意図に反した意味の無いことはしない
- 参加者には何を参加目的にさせても良い（例えば飲食のためでも良い）
- 入社タイミングで一度来てもらう（多方面から誘う、自己紹介をしてもらえないか頼んでみる）
- 知り合いから声を掛けてもらい、一緒に参加出来るように根回しする
- 自由参加・自由退出
- 積極的に登壇してもらう（登壇する前に様子を見に来る、登壇自体が初回の参加理由にもなることも）
- 不自然ではない席配置や声掛けで参加者を一人にさせない
- 事前にフラットに来るか声を掛けてみる
- なるべく広くて明るい部屋（狭くて暗いと心理的に参加しづらい）
- 仲良しグループでクラスタを固め過ぎない
- 意見を取り入れる
- TOPICSを見えやすくする
これまでの経験から、強く参加したくない意志や理由も持っている人は意外とそこまで多くありません。
会社にもよると思いますが、参加しない方のほとんどが単純に忙しかったり、
飽きたり、参加する面倒くささが勝ってしまう場合が多いようです。
そのためなるべく参加のハードルを下げ、開放的に楽にすることで、
ちょっとしたきっかけで来てくれることが多くありました。
-
参加ハードルは下げても技術共有のレベルは下げない
- 勉強会がメインコンテンツなのでLTや企画の内容の考案は丁寧に行う
- 技術共有を通じて、の前提を失わないようにする
勉強会だから来てくれる人もいますし、エンジニア組織というものを踏まえると
技術の話が気軽にでき、レベル感をお互いに推し量れている関係性が理想です。
あくまでもただの飲み会にならないように気をつけます。
- 毎回飽きない内容にする
- まずいお酒は絶対に出さない（かなり大事）
- お酒は切らさない（とても大事）
- 軽食も飽きないように毎回業者を変えてみる
- 軽食は中央に並べて座るより、バイキング制にした方が移動が多くなって交流が生まれやすい
- 内容や依頼メンバーに緩急を持たせる（技術orキャリアや経験談寄り、上級者向けor初心者向けなど）
- 告知ではTOPICSや変更点などを記載し読まれやすい内容を盛り込む
- イベントごとなどで特別企画を入れる
- LTは集中力が継続し、用意が重くなりすぎない10~15分×3名程（内容によっては拡張版にするなど）
ざっと思いつくものを列挙してみましたが、少しずつ、試行錯誤しながら改善を続けました。
お酒の量や種類、クーラーボックス導入、上長への予算UP交渉、地道な声掛け、座組の工夫など
些細だと思われる部分まで毎月何かしらの改善を行っていきました。
やや遺憾ではありますが、
何故か一緒に成長してきた私自身の酒好きブランディング（お酒は好きです）のおかげで
お酒の内容にもこだわれたり、さくっと気軽に声を掛けることができ、結果的には良かったと思います。
別で運営していた社内部活動に勧誘してコミュニティを広げるなども大分役に立ちました。
ここまででかなりの運営コストを掛けてしまってはいますが、
1~2年継続すると大分社内LT会も安定し、KPIとしていた参加人数も倍以上になりました。
組織運営
社内LT会は、恐らく存在を知らないエンジニアはいないであろうレベルまで成長しました。
問題点
しかし当日の設営準備以外、運用改善を私一人で行っていたため
先述の通り人依存で、以下のような限界も感じていました。
- 運営コストが掛かりすぎる
- 企画や改善の発想に個人という限界を感じる
- コミュニティは広がったが、どうしても自分に寄っている気がする
組織運営と効果
このタイミングで、**「技術ボード」**というエンジニアの方針決定や改善を行う中心組織で
LT会を運営するのはどうかという話が上がってきました。
私自身は運営にそのまま携わりながら、組織運営を行うことにしました。
正直突然だったのであまり意図してはいませんでしたが、結果的に先述の通り、
着実に走り初めて、習慣にし、より多くの人を巻き込んで文化にして、自然と開催されるようになる流れの次のステップに進むことになります。
現在は技術ボードの後継として**「ATLS」**というエンジニア中央組織ができ、私も含めそこでの運営に引き継がれました。
巻き込める運営メンバーが増えたことで、少しずつこれまでの意図を相談したり反省を共有していきながら
同じ思想を持つ組織として運営していくことが出来るようになりました。
一度危うくなりかけたのが、持ち回りとして機械的な運営になりそうになったことです。
運用コストを下げるために単に持ち回りして仕事を分配しただけでは、運営担当者によって質が下がり
イベント自体のモチベ低下やムラや無駄が生じることになります。
今はある程度分担しながらもうまく回せていますが、そこでの最も大きな要素は
目的を忘れず、運営組織内で同一の認識を持ち、今必要な改善を忘れずに検討し続けることだと思います。
そうして上記の問題はかなり改善され、
飲み会の初めで軽いゲームを行ったり、誘えるメンバーの幅が増えたり、
プランナーなどの他業種にも参加してもらったりとコミュニケーションや企画に幅が出せるようになりました。
またこの頃には文化としても大分馴染んできており、
登壇を依頼しても拒絶されることもそれほどなくなり、飲み会まで参加してくれるメンバーも大分増えました。
またこのエンジニアの集まりの延長として、
これまで安定開催のなかったエンジニア忘年会も継続して企画されることになりました。
8~9割という参加率で、新たなコミュニケーションの場として多くの方が参加してくれています。
現在
現在参加人数は30~40名ほどで安定運用を続けています。
社内の全雇用形態を含めたエンジニアのおよそ半数ほどです。
ATLSには組織活性化チームという技術コミュニケーション特化のチームがあり
このLT会の運営を中心に、他にも多くのエンジニアイベントが作られることになりました。
技術のアウトプットのための会
勉強会としては、それまでのLT会がコミュニケーションを重視したものであったため、
加えて新しく「アウトボット会」という技術のアウトプットを目的とした会が新しく作られました。
これまで定時時間外に業種やレベルを問わず行われていたLT会ですが、
アウトボット会では差別化を図り、技術のアウトプットに重きをおいて開催することにしています。
- 業務時間内に行う
- 専門的な技術の話がしやすいようにサーバ編とクライアント編で会を分ける
- 登壇は基本ルールとして順番に全エンジニアが持ち回りで担当する（あくまでも強制ではない）
- 月1でサーバ編とクライアント編それぞれ1hずつに絞って集中して行う
- 飲食は特になし
- 参加は自由
LTの文化が大分馴染んでいたこともあり、割とすんなり受け入れられることになりました。
アウトボット会もそろそろ10回目の開催を迎えます。
リモートでの対応
また、リモート業務が増えた事もあり、勉強会も集まることが難しくなったため
現在この両方のLT会はZoomによって開催されています。
参加する層がやや変動しましたが、
家庭のある方や忙しいメンバーなど新たなメンバーが参加出来るようにもなりました。
Zoomならではの工夫は難しいところですが、改善を行いながら運営されています。
今年は忘年会も集まることは厳しいですが、このLT会の拡張版として企画が行われています。
これから
最後になりますが
安定して技術共有やコミュニケーションが出来るようになってきた現在、
先述の当初の目的はほとんど達成されています。
ですが、勉強会の運用や内容は、環境とメンバーに応じて変わるもので、文化として段階を経て育てていくものという思想は続いています。
ATLSチームとして最近は新しいステップとして以下のようなことを考えています。
- 安定して開催する（当初の目的・クリア
） - 文化として多くの人を巻き込んで運用できるようにする（当初の目的・クリア）
- 組織的に技術や知識をしっかり溜め込めるようにする
- 人の持つ技術や知識を必要に応じて組織として引き出せる状態にする
技術的な話やコミュニケーションが取りやすい場は出来てきたと思うので、
これからはそれを知識やコミュニケーションをより有効な財産として活用できるようになり、
エンジニア組織としての価値や技術を上げていくことを目的としています。
組織として、より良い施策や制度をエンジニアから組み立てていければ良いなと思います。
組織でのイベントの運営方法や立ち上げ方には色々な意見があると思います。
目的に対してLT会や勉強会が最善の方法だとも
ここに書かれた全てや今の形が最善で正しいとも全く思いませんが、
ぜひこの事例の他にも有効な施策や、経験がある方がいらっしゃいましたら教えていただけると幸いです。