各社の技術広報が明かす「RubyKaigiスポンサーの裏話」運営ノウハウやコミュニティへの想いに登壇したのでイベントレポートを書いている。

タイトルの通りです、登壇してきました。

moneyforward.connpass.com

登壇して人心地ついたなーと思ってたんですが、思った以上に参加者の方が前日以降にぐぐぐぅ〜っと増えてびっくりしました。 それだけだとブログを書こうと思えなかったんですが、Twitterでの反応やコメントなどがあって「あ。意外とみんな関心や悩みの共感ポイントがあるんだな〜」って感じたのでこの記事を書いてます。

登壇資料はこちらです。

まとめ記事速報を弊社メンバーが書いてくれたのでよければこちらもどうぞ。

zenn.dev

とりあえず終わったあとの感想

いやー元々は技術広報がメインになるイベントって誰得なんだろう?と思っていたので、参加も登壇も全然OKだけどなにを求められてるんだろうなー?が今回のイベント登壇で一番悩んだポイントでした。 結果、ANDPAD鳩さんが割とナレッジよりの発表をされたり、iCARE荻野さんが採用にフォーカス、クックパッド緑川さんがエンジニアの参加についてだったのでエモめな内容に振り切って

「なぜRubyKaigiのスポンサーをしてるんですか?」

に答えられるようなものにしようと考えました。

各社、感じている課題は共通しているんだけど表現方法が違っていたり、それぞれが見ている視点は違うんだけど求めている方向性や意味は同じだなと感じられてよかったです。

Twitterやアンケートの初速も聞いているところによると悪くないので一安心でした。

イベントを開催して感じたこと

最近は技術広報やDevRelというラベルがついたからか、こういった知見や経験を学ぶ場がエンジニアのコミュニティから徐々に広報や人事の領域に越境しているようになったなぁと感じています。 アンケートの速報段階ですがいわゆる非エンジニア職の方の回答がおよそ20〜25%ほどあったようです。 詳細は後日イベントレポートがでる……と思うんだけど自分が担当じゃないのでわからない。まぁ多分イベントレポートは出すんじゃないかな…ということでそちらにおまかせしようと思います。

開催して思ったのは

「正解ではなく、自分が間違っていないことを確かめたい」

なのかなと思いました。 技術広報のような仕事を非エンジニア職の方がやるときに「果たしてこれでいいのだろうか?」という不安があるのだと思います。

そういった人にとって今回のイベントは参考になるナレッジよりも「自分たちが目指そうとする方向性の正しさ」を補強する、という意味で自信を持ってもらえたのかもしれないなと思いました。

もしかすると今回参加した方々が求めるもの、参加している会社は「技術をアウトプットすることが文化になっている企業・組織」なので期待したものではなかった可能性はあるかなと思いつつ、 そこはすでにいろんな方が通ってきた道でもあり、ブログや登壇などである程度ナレッジがあると思うのでそれほど情報面、知識面では困らないのかなと思ってます。

昨年の技術広報アドベントカレンダーもあるので知らなかったという方は見てみるのもいいかなーと思います。 25記事あるので毎日1記事読んでも25日楽しめます。

qiita.com

登壇したときの最後に「並走することが大事、意識している」と言ったと思うんですが、並走はただのHowで成し遂げたいアウトカムはメンバーが自信を持ってくれることです。 このあたりはクックパッド緑川さんの発表でも似た表現があったと思います。

個人的には技術広報という立場での登壇で積極的に発信するつもりは実はあまりなくて、ぼくは他社で技術広報をされている方よりも出遅れていると思ってるので学習して成長していった先で登壇という形につながるといいかなーと思ってます。 なんですが、まあ今回背景の部分にフォーカスしようと考えたのは技術広報は「定性と定量の両方を考えなくてはいけない」からだと考えています。

技術広報だから、というと語弊があるんですが、結局マネジメント職も技術広報も「実際に手を動かしものごとを成し遂げるのは他のメンバー」なわけです。 そうすると必ず「なぜやるのか?」と「やった効果はどうなのか?」が必要になります。

これらはどちらが欠けても駄目なんですが、後者のほうは比較的マーケティングや人事の方は意識しやすいのではないかと思います。 逆に背景や想いといったエンジニア文化、ハッカー文化特有のノリや雰囲気、空気感というのはなかなか理解されないものがあります。

一番手っ取り早いのは体験してもらうことなのかな?と思うんですが、こういったエモめな話はあまり人前でしにくいんじゃないかなと思ったのでせっかく登壇するなら他の人がやりにくい、やらないことにチャレンジしてみようかなと思い、今回の登壇と相成りました。

多分具体的なナレッジのほうがわかりやすいし、バズリやすいのかなと思うんですがエンジニアでない人にとってはこういった背景をどう設計するのか?なにを感じればいいのか?という情報に飢えてるんじゃないかと思ってます。 もしですね、その予測が当たっていれば何かの参考にしてもらえると嬉しいです。

ひとまず終わった状態のなぐり書きでこのブログを書いているので、荒らがあると思うんですがまあこういうものもたまにはいいかなと思って書いています。

RubyKaigiの準備は各社これから徐々にヒートアップしていくと思います。 そういったタイミングで今回のイベントが開催できたということは1つ参考になる事例紹介としてよかったのかもしれません。

コロナ禍になって、オフラインイベントを知らない若いエンジニアの方もだいぶ増えたと聞きます。 前夜祭でコミュニティへと入ってもらう障壁を下げて、後夜祭で楽しんだこと、わからなかったこと、次回どうするのかといったRubyKaigiの体験を次に繋げる施策なんかができるといいなーと思ってます。

コミュニケーションの濃度は「経験 > 会話 > 文字」ではないかなと思っててい、これにプラスして量である「単純接触回数」が含まれ、コミュニケーションの質を形成するんじゃないかなーと思ってます。 ぼくはRubyKaigiの運営とは全く関係がないんですが、できるだけいろんな方に経験を、そして会話をしてもらいたいと考えています。

なんかあったら所属企業が違ってもいいんでTwitterで雑に連絡してもらえればなーと思います。 (こういうときに知らない人との窓口になるMeetyがあると便利だったんだぁ……)