エンジニア採用施策にミートアップはいかが？

昨今、エンジニア採用に積極的な企業各社は技術ブログに力を入れています。弊社iCAREでもブログやTwitterを中心とした外部への情報発信に力をいれております。

iCAREの場合も、応募者から選考の過程で「ブログを読んで興味を持ちました！」といった反響が多く、ブログ施策は今後も続けていく予定です。

ただ、今回はこの技術ブログと比較しながら、iCAREがここ1年近くとても力をいれている、技術ミートアップについてお話ししたいと思います。

なぜミートアップ？

なぜ今ミートアップの話をするのか？
なぜ採用施策としてのブログとミートアップを比較するのか？

その理由は、端的にいえば技術ブログよりも、技術ミートアップのほうがメンバーたちが生き生きと楽しく取り組んでおり、また採用面においても一定の効果を見せているからです。

2年以上にわたって毎月開催してきたiCARE Dev Meetupは、採用・ブランディングにおいて、非常に大きな効果を発揮しつつ、メンバーたちが自発的に創意工夫を加えながら支え続けてきています。

言い換えると、ミートアップは、技術ブログと違って、組織として頑張ってそれを促進したり、維持のために工夫しなくても、メンバーたちが楽しんで自発的に推し進めることができる施策だということです。

また、その成果は採用にとどまらず、メンバーのエンゲージメントの向上や学習・成長機会の創出など、多方面でとても良い効果を発揮しています。

では、技術ブログは？

採用施策や学習組織作りの一環としてメンバーに技術ブログを書いてもらう、ということをしている企業はたくさんあります。
多くの企業において、これが成功をおさめ、ブランディングやメンバーのスキルアップに効果をもたらしています。その一方でまたうまくいっていない組織も多々見られるようです。

実際、iCAREでも開発者ブログをメンバーに対してタスク化したり、目標設定に組み込むことで、一定の質と量を担保してきました。応募者の方からも「ブログを読んで興味を持ちました」と言われることも多く、めざましいとは言えないにせよ、一定の成功をおさめてきました。

ただ常に難しさも感じてきました。

目標設定に組み込んでも、どうしても「書かなければならない」状況は生まれてしまい、「今、このテーマで書きたい！」という自然発生的なモチベーションからではなく、目標のためにエンジニアが「頑張って」書く、ということが起こりがちです。

また業務が忙しいタイミングにぶつかると、業務を優先すべきか、ブログを書くべきかというジレンマに陥ります。

ミートアップの場合、それらの問題は？

iCAREのミートアップの場合、これらの問題は技術ブログほど表面化しません。なぜでしょうか？いくつか理由があると思われます。

ひとつは、ブログの場合の責任が、筆者という「個人」に帰するのに対して、ミートアップの場合の責任は、それを運営する「チーム」に帰するからかと思われます。

もちろん、講演(LT)の責任は、登壇者「個人」に委ねられますが、iCAREのミートアップの場合、登壇者の大半は、社外の著名なエンジニアの方々で構成されるので、毎月社内から登壇するメンバーは一人か二人です。責任が個人に委ねられる頻度は高くありません。

しかも、外部の「著名な」エンジニアをお招きして一緒に登壇するため、社内から出る登壇者の士気もいきおい高くなります。士気が上がるというよりはプレッシャーがかかる、といった方が正しいかもしれません。とはいえ基本的に希望者に登壇してもらうため、良い意味でのプレッシャーとなります。

もうひとつ忙しい業務とのバランスの問題ですが、これもミートアップの運営がチームで行われるため、大きな問題にならずにきています。ミートアップの運営に関して、個人レベルで業務とのバランスをとることが難しければ、運営のタスクをチーム内で分散することで問題を回避できています。

インパクトの大きさは？

技術ブログとのインパクトの違いはどうでしょうか？
これについてはそもそも質の異なる施策のため単純比較は難しいところです。組織構成員一人一人の「個」の技術の高さを訴求する、という意味では、ミートアップはブログに太刀打ちするのは難しいと思います。

ただし、個人レベルの魅力ではなく、「チーム」としての魅力を訴求するという意味では、iCAREのミートアップはブログよりも遥かに成功していると感じています。

細やかな運営をすることで、チームとしての結束力やコミュニケーションの活発さを感じてもらうことができます。また、OBS(ライブ配信する際に使用するPC用のソフト)を利用したデザイン性の高い配信、Youtubeでのライブ配信とアーカイブ化などを通して、チームメンバーが情報感度高く、かつ新しいことにどんどん挑戦する文化を持っていることを伝えることができます。

また毎月様々なテーマを扱い、様々なエンジニアの方々をお招きすることで、iCAREのエンジニアがどんな人に、どんなことに関心を寄せているかを知ってもらうことができます。またミートアップのような登壇機会、学習機会を広く社外に提供することで、「閉じた」エンジニア集団ではなく、「開かれた」エンジニア集団であり、コミュニティに貢献する意志が強いこともアピールできます。

あと、ここもとても大きなポイントになりますが、iCAREのミートアップにご登壇いただいているエンジニアの皆様は、界隈で知名度の高い方が多く、とてもクオリティの高いLTをしてくださいます。そのため毎回社内外のエンジニアにとても喜ばれるミートアップになっており、その点でもiCAREが素晴らしいイベントを開催できる良い組織であるという印象を持ってもらうことができています。

楽しさの問題

ブログとの違いで一番大きいと思われるのが、「楽しさ」の点だと思います。ブログも良いのが書ければ、その喜びは大きいと思います。しかし、難しいのは、この喜びをチームの中で「共有」することです。Aさんが書いた記事についてBさんがAさんと同じように喜ぶのはなかなか難しいです。

しかし、ミートアップを終えて、その内容がとても満足がいくものだった場合、ミートアップの運営チームは全員が、我が事としてこの成功を喜ぶことができます。しかも、この喜びの波動は、個人の喜びより遥かに大きいので、容易に組織内全体に伝播します。そして、おそらくですが、これはさらに組織を越えて、登壇者の方々や、参加者の方々へも波及していると思われます。

実際、登壇者の方々や参加者の方々から「良いチームですね」とか「とても楽しそうな雰囲気が伝わってきます」といった言葉をいただくことが多いです。

最後に

さて、ここまで読んでくださった方々は、iCAREの技術ミートアップがどのように運営されていて、それがどのように発展してきたか、ご興味をお持ちいただいたのではないかと思います。

ですが、iCAREのミートアップは、毎月開催で今月(2021年10月）25回を迎えております。その歴史は、2年以上にわたり、その間、いろいろな挑戦、失敗、成功がありました。なので、このテーマについては次回、詳しくお伝えしたいと思いますので、楽しみにお待ちいただければと思います。

ということで、今回は、採用施策としてブログも良いが、ミートアップも良いぞ（あるいはもっと良いぞ！）というお話でした。

もし弊社iCAREのミートアップにご興味お持ちいただけましたら、次回10月開催

【iCARE Dev Meetup #26】 デザイナーとフロントエンドエンジニアを繋ぐ技術

にぜひご参加ください。また過去開催分につきましては、

Youtubeチャンネル、DevTeam @iCARE

からご覧いただくことができます。

また、弊社では、健康管理システムCarelyを開発・運営・提供しております。ご興味ございましたら、こちらからお問い合わせください。