2023年夏、SmartHRでDevRel（Developer Relations）が始動しました！
SmartHRのDevRelは生まれたてほやほや。会社、そして担当者自身にも経験や知見がありません。
そこで、他社で積極的に活動をされているDevRelの先輩がたをお招きして座談会を開催しました。
前編では、DevRelとは何かや、活動の成果とその計測方法、体制、予算についてお話をうかがいました。
（座談会は2023年9月に行いました。内容は当時のものです）
目次
座談会メンバー
櫛井優介さん（以下、941）
LINE株式会社（現LINEヤフー株式会社）
Developer Relations室 Developer Successチーム所属
2004年ライブドア入社。2008年よりイベントなどを担当し、2018年3月より現職。
主に技術広報活動全般、技術系イベントの運営や各種イベントのスポンサー窓口を担当。スタートレックとHHKBとビリヤードとBTSが好き。
X：@941
杉田絵美さん
株式会社MIXI
開発本部 たんぽぽ室 DevRelグループ マネージャー
大手グルメポータル創業期から上場までエンジニアとして従事。米国留学後、2009年にミクシィ（現MIXI）入社。SNS mixiなどの開発に携わり、EM、新規事業のPdM、技術広報、採用人事を経て、現在はたんぽぽ室DevRelグループにて技術・採用広報のほか、社内外技術者コミュニティの支援等を行う。趣味は旅とカメラ。
玉田大輔さん
株式会社ディー・エヌ・エー（DeNA）
技術統括部エンジニアリング室・技術広報
2009年にDeNAに入社。エンジニア、スクラムマスター、人事、事業開発などを行い、2018年7月より技術広報。DeNAの技術ブランディング責任者を担う。DeNA TechCon の Organizer を 2019年から担当しており、2019年に社長賞を受賞。趣味は剣道で五段、地域道場の先生をしている。
聞き手：稲尾尚徳（以下、inao）
SmartHRのDevRel。前職は編集者。
X：@inao
自己紹介
inao：本日の意図なんですが、SmartHRのDevRelが立ち上がりまして、メンバーは僕一人で、僕はやったことがないという。
941：すごい決断ですね（笑）。初めて聞いた。
inao：会社としても僕としても知見がないので、みなさまの知見をお聞かせいただければと思います。よろしくお願いします。
まず簡単に、自己紹介をお願いします。ご経歴とか、DevRelとして行ってることの概要とか。
玉田： DeNAで技術広報をやっています。DevRelじゃなくて技術広報と言っています。
2009年、DeNAにエンジニアとして入社して、そこからスクラムマスターとか人事とか、あとはエンジニアをやめてビジネス事業開発もやったりとかして、いろいろ転々とした先に、やっぱりエンジニア×人事みたいなところがいいなということで、2018年7月から技術広報をやっています。
DeNAの技術ブランディング全体を担当していて、DeNA TechConの Organizerも2019年から担当しています。もともとDeNA TechConは年一開催だったんですけど、2021年に年4回やって、2022年に年2回やって、回数だけでいうとこれまでに7、8回ぐらい技術カンファレンスをやった経験がある感じです。
趣味で剣道をやっていて、地域の道場の先生もしています。よろしくお願いします。
inao：五段なんですよね。
941：すごい！
玉田：五段から先生の資格なんで。はい。よろしくお願いします。
941：LINEの櫛井です。今はLINEのDeveloper Relations室のDeveloper Successチームにいます。
2004年にライブドアに入って、そのときはWebディレクターとして入社しました。2008年からは、エンジニアの採用をどんどんしていきたいということでその活動に振り切ったので、もう15年ぐらい似たような仕事をしている感じです。
今は技術広報活動全般と、技術系のイベントの運営、あとは技術系のイベントにスポンサーするかどうかの判断、出すんだったらこういうふうにやろうみたいなところを全部見ています。
inao：「DevRelの祖」って呼ばれてるんですよね。
一同：笑
玉田：そうですね。DevRel GuildというSlackコミュニティで、DevRelの祖である941さんを呼びたい、という話がありました（笑）。
941：自分のやってる活動にあとから名前が付いたので、うれしい反面、DevRelってどうとらえられてるのかなというのがちょっと気になってて。ぜんぜんキラキラした仕事じゃないのに、最近はキラキラっぽいニュアンスがあるなと思ってて。
杉田：MIXIの杉田と申します。もともとはエンジニアで、MIXIには中途で入って、開発をやったりとか、エンジニアリングマネージャーをやったりとか、新規事業のプロダクトマネージャーをやったりとかしているうちに、採用は大事だなと思って。ちょうど採用・技術広報を探している部署があったので、そこに社内転職をさせてもらったのがDevRelキャリアのはじまりです。そのうちエンジニアの採用も手伝うようになったりして、より採用人事との連携を強くしたくなったのと、活動範囲を全社に広げたり、勉強会や社内イベントなどもやっていきたいと思って人事に異動して、MIXI初のDevRelチームを作ってもらいました。今は開発本部というMIXIの開発組織を横軸で支える部署にチームごと異動して活動しています。
inao：みなさんバックボーンがバラバラですね。
941：そうですね。うちに大学生のアルバイトの子が一人いたんですけど、卒業するから新卒でDevRelに入りたいって言ってきて。いや、ファーストキャリアは絶対にここじゃないよって（笑）。
玉田：ああー、わかる。
941：新卒カードは絶対違うとこで使ったほうがよいです。なので、セカンドキャリアっていうか、他に何かやってから……。
杉田：ですね。ベースで何か自分の強みが一つあって、それプラスアルファのDevRelかなという気がします。
inao：なるほど。
941：人事っぽい人もいるし、開発から来る人もいるし、ディレクターやってた人もいる。でもいきなりファーストキャリアからというのはあんまり聞いたことがない。編集からDevRelも初めて聞きました。
玉田：inaoさんの編集からDevRelへのキャリアチェンジ、おもしろいですよね。
941：いいと思います。
玉田：強みがあって、おもしろそうだなと思います。
941：「DevRel初めてです」っていう人で、こういう座談会のセッティングはできないじゃないですか。
杉田：はい。
玉田：できないですね。
941：やっぱり編集の強みがすごい出てるなと思います。
inao：ありがとうございます。
そもそもDevRelって？
inao：まず総論というか全体的なことをおうかがいします。僕の入社してすぐのミッションに「『SmartHRのDevRel組織とは』という定義を作りましょう」というものがあったんですけど、やったことない仕事を定義するのはすごく難しくて……。
941：それはそうですね。
inao：それでみなさまの記事などをおおいに参考にさせていただき、なんとか文章にまとめたんですけれども、これを見ながら、うちはこんな感じで定義してるよとか、ここをこう変えたらもっと良くなるよとかのご意見をいただければと。
杉田：難しいですね。
941：あんまり偉そうに言えるようなかっちりしたものでもないですけど（笑）。
玉田：自分ではDevRelって呼ばないようにしていて、技術広報って呼ぶようにしています。技術ブランディング活動を推進していく人として自分を定義しています。
自分でブランディングの本をけっこう読んで、ブランディングの社内のスペシャリストにも相談して、何をやったらいいのか整理していったんですよ。その結果、その定義が自分としてしっくりきてるんですよね。
まずは会社として、エンジニアのみなさんにこう思ってもらいたいというイメージがあって、一方で世の中のエンジニアがうちの会社のことをこう思ってるというイメージがあるんですけど、そこの重なりが技術ブランディング、ブランドかなと思っています。重なりがちゃんと大きくなるようにしていく仕事が「技術広報」かなっていうのが、自分にはすごくしっくりきていて、それをがんばろうと思っています。
inao：自分たちのブランドイメージは言葉にしてまとめられてるんですか？
玉田：そうですね。社内のエンジニアにいろいろ聞いて、僕らが大事にしたいイメージってなんだろうなっていうのをまとめました。そして、アンケート調査で実際にそのイメージを持ってるのかを聞くと、実は持っていないみたいなものがあったりするので、そこを補強するブランディング活動をやったりしています。
inao：調査というのは社内の方に対して？
玉田：いえ、社外です。
inao：へええ。ブランドイメージはどこかで公開されていますか？
玉田：あー。対外的にはやってないです。それやるのはありですね。
inao：もし公開されたらぜひ拝見したいです！ 続いて941さんのところはDevRelをどのように定義なさっていますか？
941：私は、DevRelの役割は4つ定義できるかなと思ってます。
1つ目はDeveloper Relations。名前そのままですが、エンジニアが外部のエンジニアと直接コミュニケーションをとって、意見や情報を自社プロダクトや関連技術の改善につなげる。Googleさんとかがやっているのはこれにあたりますね。
2つ目はマーケティング。製品を広めるなどの広報活動をするエバンジェリスト的な役割です。
3つ目はテックブランディング。イベント、メディア、SNSなどを通じて、技術情報を発信したり、社内のエンジニアと社外のエンジニアのコミュニケーションをサポートしたりする活動などがこれにあたります。
4つ目はインターナルサポート。私達の会社ではデベロッパーサクセスって言ってますけど、社内のエンジニアの満足度を上げる活動です。
それぞれは役割なので、活動としては重複することもあります。
inao：インターナルサポートはどんなことをされてるんですか？
941：一つはエンジニアにとっていい制度を作ることですね。隙間で制度化されてないものっていっぱいあるんですけど、そういうのをちゃんと制度化してあげるとか。明確に「こういう役割をDevRelは担うので、困ったら言ってくださいね」と周知しておいて窓口を作ってます。あとは採用して人を増やすみたいなところも含めて、より良い開発環境を作るっていうところは、私達の活動のミッションとして定義されてます。
inao：エンジニアリングを伴う開発環境まで含まれるんですか？
941：そこまではしないですね。エンジニアたちがより活動しやすくなるためなので、具体的には、社内で勉強会したりとか、足りてない勉強会のサポートをしてあげるとか、そもそもの組織の立ち上げのタイミングでフォローするとか、そういうことです。
inao：ありがとうございます。杉田さんのところはDevRelをどのように定義なさっていますか？
杉田：うちはもともとが採用PRや技術ブランディングから始まっているんですけど、だんだんと社内外関わらず開発者同士の関係構築や強化っていうところが目標になってきたので、よりわかりやすくということでDevRelという組織名に変えました。
DevRelの役割としては、けっこう何でも屋になっています。何でも屋になっている背景としては、仕事の境界を設けずに、社内には開発者としてMIXIで働く中で何か困ったことがあったらとりあえず言ってください、何でも相談してくださいみたいなかたちにしているというのがあります。
一応、何でも屋であってもゴールは設けていて、MIXIという強いチームを作ることをゴールにしています。現在は、活動領域は4つあって、ブログ（「MIXI の Developer Relations チームは何をしているのか | by Emi Sugita | MIXI DEVELOPERS」）にも書いているんですけど、採用マーケティング、技術広報、開発者コミュニティの支援、生産性向上支援です。生産性向上支援は今はあまりできてないんですけど、新卒の技術研修とか、各クラウドのトレーニングとか、941さんがおっしゃったようなエンジニアリングの周辺で必要なこととかを実施したりしてますね。
inao：技術研修やトレーニングのコンテンツはどなたが作るんですか？
杉田：新卒向けの技術研修は毎年エンジニアたちが作ってくれています。
inao：なるほど。一緒にやるみたいな。
杉田：そうですね。プログラム全体の箱だけ用意して、あとは、講師陣に、こういうコンセプト、こういう狙いがあるので、こういうものを作ってくださいと。
inao：毎年新人研修のすごい資料を公開されていますよね。ありがとうございます。
inao：僕がまとめたDevRelの定義はいかが思われますか？
941：定義としては合ってると思うんですよ。外れてはいない。ただ、その中で何を自分たちのミッションとして掲げるかはまた別なんで。
inao：なるほど。
杉田：会社とか組織によって、やるべきことってぜんぜん違うので。採用のためなのか、社内のエンゲージメント向上のためなのか、その組織が持つ課題によって、目的がまず違う。
941：相談してねって言われて、いざ相談したら「ちょっと忙しくてできません」ってなっちゃうと、良くないじゃないですか。なので、1人でできる範囲をまず見極めたほうがいいかもしれないですね。あれもこれもってなっちゃって「結局あいつ何も動いてくれねえな」みたいな感じになると、声をかけてもらえなくなるので、できることをできるって言ったほうがいいとは思います。
玉田：うちは工数の4割か5割ぐらいが技術広報で、残りが社内のエンジニア組織がより良くなるための活動をやっています。エンジニアマネージャーのマネジメント支援とか、オンボーディングのドキュメント整備とか、制度作ったりとか、要は入社してから退職するまでのいろんなエンジニア活動を支援するみたいなことも半分やってたりするんですね。
私は先ほどエンジニアリング室の中にある技術広報チームの話しかしなかったんですけど。その両方を合わせてDevRelって言っているところもあれば、外部のブランディングだけをファンクションで分けてやるみたいなやり方もあるから、本当にどういう組織なのか、どういう役割を持つかによって、ここらへんの定義は違ってくるのかなあ。
活動の成果とその計測
inao：続いては、成果と計測についておうかがいしたいです。うちの上長から聞いてきてって言われたんですが、DevRelが事業にもたらしているものは何だと考えていて、どのように計測なさっていますか？
941：これね、難しいんですよ、一番。
杉田：うちは持ってないです。はい。
ですが、一応数字は見ています。Xであったりとか。あとは定性部分では、アンケートでフィードバックをもらったりとかしてはいます。でも、「この数値」っていう数値そのものは追ってはいません。
結局、いろんな数字は作ろうと思えば作れるじゃないですか。だけどたとえば、イベントをやるっていったときに、参加者数を目標にしたとしても、それが成果とは限らないっていう。
941：参加者数とかは実は水増しできるんですよね（笑）。
杉田：そうなんですよね。数字は伸びたかもしれないけど、エンジニアの満足度、参加者の満足度はどうなんだいってところもあったりする。正しい判断ができなくなっちゃうかなっていうのはあるので、数字の成果指標は持ってないですね。
941：私のチームでは期初に一回KPI（Key Performance Indicator）を設定するんですけど、そのときOKR（Objectives and Key Results）みたいな感じで、プロジェクトごとに一応Key Resultsを決めます。プロジェクトは、内向けと、外向けの大きいイベントであるTech-Verse、ISUCON、あとはブログとかSNSみたいな感じで大きめに分けています。その中で一応数字は設定するんですよ。ブログは月何本ぐらい出したいよねとか、イベントは何人ぐらい呼んで、とかやるんですけど。定期的に会社の合併とかけっこう大きい動きがあるので、「それどころじゃねえ!!」みたいな（笑）。ちょっとそっちの対応に忙しくて「ブログを書いてる暇ねえ」みたいな状況が2年おきぐらいに来る。あんまりブログの数だけ出しても意味ないんで。結局、数字はもちろん追ってるんですけど、KPIは活動「量」に置いていますね。
inao：活動量？
941：はい。イベントにどれくらい支援をしましょうとか、自分たちで開催できるミートアップを年間何本やりましょうとか、社内向けの勉強会を年間何本ぐらいやろうみたいなのをまずいったんは設定しますね。そこに向けてまずはがんばろうという。
一つやってるのは、インフラやセキュリティなどの技術領域ごとで担当を決めてるんですよ。その領域ごとで、現場からの要望に100%応えるっていうのは、一応、数値というか、求められる姿勢として見てますね。
inao：要望に応えられるかどうかってことですね。
941：そうです。意味なく断ってないとか、ちゃんとポジティブに一緒にやれる体制ができているかとか。本当はこっちからグイグイ行きたいぐらいですけど、まずは彼らの要望を全部満たすっていうところは、目標としては持っています。
inao：なるほどなるほど。
杉田：ブログとかもそうなんですけど、アウトプットはけっこう外部要因に左右されるようなものもあるので、時期によって書けたり書けなかったり。そういう意味もあって、うちもエンジニアに対して何本ぐらい書いてくださいって言いにくいので。唯一プッシュしてるのはアドベントカレンダーくらい。それだけは、「年末だし！ ちょっと今年の振り返りをして書きましょうか！」ってやってはいますね。
941：イベントにすると書きやすいですよね。
杉田：そうそう、そうですよね。自分たちも年末年始で学習しようという意思もあるので、その前に1年間の振り返りを自分でして、まとめて、自分がやったこととかも含めて公開するっていうタイミングにしてもらってます。
inao：なるほど。
活動量っておもしろいですね。要望に応えられたか、とか以外だと、他にどんなものを取られてますか？
941：基本あんまり振り返らないので。
一同：笑
杉田：後ろは振り返らない（笑）。
inao：そうするとやはり活動量。
941：そうですね、はい。
あとは、ちょっと隠しパラメータとしては、偉い人たちの要望にもきっちりしっかり応えるみたいなのはあります。これ、めちゃくちゃ大事なんですよね。
いざというときに「このチームは動けてないな」みたいな印象を持たれると、いろいろな業務がすごいやりにくいんですよね。なので、偉い人が持ってくるちょっと特殊な案件は全部ちゃんとこなす、みたいなことはやってます。
杉田：そこはうちもあるかもしれませんね。
941：ありますよね!?
杉田：やっぱり何のためにやってるかって言ったら、会社の事業の成長のためにやってる部分があるので。戦略上こういうふうにしたいとかこういうことをやりたいとかっていうリクエストには、なるべく応えるようにしています。
inao：急な要望にも応えられるようにちょっと余力を設けたりしますか？
941：いや、違います。普段100パー全力でやってるので、120パーがんばるんですよ。
inao：あー、聞かなきゃよかった！（笑）
杉田：そうですね。うちも、偉い人の要望というか後押しで実施したものとして、3月に開催したMIXI初のテックカンファレンスであるMIXI TECH CONFERENCEがあります。
玉田：やってましたね！ DeNA TechConと日にちがかぶっちゃったんですよ。なので、MIXI TECH CONFERENCEとDeNA TechConは、お互い宣伝しあったんです。
inao：玉田さんのところはいかがですか？
玉田：うちは大規模なアンケートを年に1回とっています。世のエンジニアの方々がどういう会社のことをいいと思ってるのかとか、どういう印象をこの会社に持ってるのかとか。あとはブログとか技術カンファレンスとかいろいろある中、何がきっかけでこの会社のことをいいなと思ったのか、みたいなことを調査してます。
年に1回ずつ3年間調査したので、けっこう傾向がわかってきて。それで年間の戦略を考えるという感じですね。
あとは細かく、まさにOKRみたいな感じでやってて、とあるときは、「Twitterのフォロワー1万人突破するぞ」っていうのをがんばってやって、何とか突破した。
あと今はやってないんですけど、技術カンファレンスの登壇がすごい少ないときに、CFP（Call for Papers）にたくさん応募を出して、採択を増やすぞという取り組みをやりました。一番多いときはiOSDCで100人の登壇のうち、1割はDeNAの人が登壇者だ！というのを達成しましたね。
その期その期で力を入れるものがはっきりしていると、それが積み重なって良くなるんじゃないかなと思っています。
次はうちは何を強みにして、どこで勝負しようかみたいなのはOKR的にやるといいかなと思います。
inao：大規模アンケートっていうのは、DeNAについての質問ですか？
玉田：DeNAだけじゃないです。あと、DeNAの名前は隠してやってます。他社さんに協力いただいて。
inao：そうなんですね！ テック系の各社合同で取られてるってことですか？
玉田：いや弊社だけです。アンケート会社ではないんですけど、そういうアンケートを実施できそうな会社さんに相談して、ご協力いただいてます。
941：あれほんと大変なんですよね。
玉田：すごい大変。
941：技術ブランディング調査って、結局、自分たちだけでやろうと思うと、自分たちのことをそもそも良く思ってくれてる顧客がターゲットになってくるから、すごいバイアスがかかりますよね。「その数字をとってどうすんの？」みたいな話にしかならないからやらないんですけど。すごいな。けっこうお金がかかりますよね。
杉田：だいぶですよね（笑）。うちも別文脈で大昔やってましたけど、やっぱりちょっとお金がかかるわりに、それを活かせるかというと……。
941：難しいですよ。数百万かかりますよね。
玉田：そうですね。最初に設計するときに、マーケティングに詳しい方に相談に乗ってもらって。分析結果からどう戦略に活かしていくかっていうのは、わりと納得感あって、いろんな人を説得しやすい材料になったんで。その結果があったからTechConを年4回やろうって結論になったんですよね。
一同：あああー。
941：説得のための材料には、かなりなりますよね。
inao：どういう結果だったから年4回やることになったんですか？
玉田：会社によって強みって違ってくるんですけど、弊社の場合はやっぱ自社技術カンファレンスが、DeNAに行きたいと思ううえでの要因としてけっこう大きいというのがわかったので。じゃあもうそこ一点打法で、技術カンファレンスばっかやろうって思って、年4回に増やそうと。
941：極端だなあ。
一同：笑
inao：やっていかがでした？
玉田：一本足打法は大変すぎて、他が何もできませんでした（笑）。やっぱりまんべんなくいろいろやらないと駄目なんだなっていうのが、学びとしてあります。弊社のことをよく思ってもらいやすい施策はもちろんあるんだけど、それ以外を全部弱めてしまうと駄目ですね。全体的にちゃんとやるし、そのうえでの比重をどっか強める部分があるのがいいと思います。
で、弊社がそうやって1本だけに集中してる間に他社さんがいろんなことをやってて、じゃあどっちのほうがブランディングが上がったのかって見てみたら、弊社みたいな一本足でやってるところじゃない会社さんのほうがブランディングが上がってたりしたんで。
一同：へえええ。
玉田：なるほどなーみたいな感じで。やっぱりいろいろやんなきゃいけないからしんどいなっていう。
杉田：しんどいです（笑）。
さっきお金の話がありましたけど、うちは事業を作って直接的にお金を生む組織じゃないから、お金をいかに使わずにうまいこと効果を出していくかっていうところはけっこう工夫してやってる感じですね。
先日の3月のテックカンファレンスもだいぶお得にやってると思います（笑）。
inao：どんな工夫をされたんですか？
941：基本、人員は自分たちで？
杉田：自分たちでやったりとか。
941：外注しないってことですよね。
杉田：制作費については極力そうですね。
玉田：社外のイベントでトップスポンサーをやるのは相当慎重に、ですよね。
杉田：そうですね。もちろん決裁が通らなかったりするので。
inao：協賛のコスパっていうのは、たとえば何を見ていますか？。
杉田：X上とかで盛り上がるイベントとそうでないものがあると思うんですけど、総合的に見て、いかにコストをかけた分の効果を得られるかっていう。
941：私は担当なんでよく見ているんですけど、イベントによってスポンサーの金額ってバラバラなんですよ。同じダイヤモンドスポンサーという名前でも、200万円もあれば50万円もありますよね。熱量が高い人がたくさん来るイベントもあれば、なんかスーツの人ばっかりのイベントもあって。でもなぜかスーツのほうが金額が高かったりして「これは届けたい対象ではないからやめよう」という判断をすることが必要なので。そこはね、ずっと見続けるしかないんですよ。
玉田：同じiOSの領域でもiOSDCとtry! Swiftという2つのカンファレンスがある。AndroidもDroidKaigiとKotlinFestなどがあります。力の入れ具合をどうするかっていうのは、何回かやって温度感がわかって、だんだん調整されていく感じかなとは思うんですけど。
経験のないうちとか認知がないうちは、トップランクのスポンサーでバーンと出して、この領域に弊社はいるんだよ！っていうのをアピールするとかは、けっこうやられる会社さん多いですね。もう何年も昔からやってるところとかは、わりともうそこの枠は空けて、ゴールドあたりに落ち着いてるのはよく見ます。
inao：なるほどー！
941：評価の話に一個つけ加えさせてもらいたいんですけど、うちの会社は半年に1回、レビュー期間があるんですね。そこでCレビューという、要は360度評価があって、協業している同僚からどう評価されてるかっていうのは、うちのマネージャーはめっちゃ見てます。どういう活動で助かったのかとか。
杉田：けっこうDevRelは、そうですよね。多分、上からは見えてないことが多いので。
941：現場からどう評価されてるかはすごく見てますね。設定した目標に対して未達かどうかっていうよりは、日々の活動がどうだったとか、こういうとき助けてくれてありがとうみたいな声のほうが、けっこう印象としても、結果としても、強い気がしますね。
inao：それが自然に集まるようにしてるんですか。
941：半年おきにレビューがあるので、そのときに匿名で、良いとか悪いとか言われる機会があります。
inao：それをちょっと書いてくれませんか、ってお願いするんですか？
941：そうです。普段協業をしてるメンバー同士で「この半年どうでしたか」っていうのをお互いに書き合うんですね。そこで見た評価をうちのマネージャーはけっこう見てくれてはいますね。
杉田：それって全社で一気に？
941：そうです、そうです。
inao：それ以外だと評価の数字は何かあるんですか。
941：CレビューとPレビューがあって、Pレビューはいわゆるパフォーマンスレビューなんで普通の評価ですね。「最初に決めたこの数値、この目標を、あなたはやれましたかどうですか」っていうものです。
Cレビューはみんなからの評価なので、参考程度ではあるんですけど、僕らの活動が日々どう評価されてるかっていうのは濃密に出るんですよね。たとえば「会社を辞めようと思ったけど、DevRelの941さんはこういう活動ですごく支援してくれて、他の会社ではこういうことはしてくれないから、条件面をクリアしてくれたら残ります」みたいなこと言ってくれたらしくて。
inao：めちゃくちゃうれしいことですね。
杉田：評価に関してはそうですね、さっきの指標じゃないんですけど、外部要因的なところで、今期はここまでやろうみたいなことを設けても、自分たちの力だけではどうにもならないことで変わってしまうことがあるので。
ざっくりとしたゴールとかは持ちつつも、それに対してどう貢献できたかとか、人によって、いかにパフォーマンス良くできたかとか、結果を得られたかとかを見たりしていますね。
あとは、いまうちのチームは2人しかいないんですけど、1名がDevRelになりたてだったりするので、壮大なスキルマップを作りました。
一同：おおおーーー！
玉田：すごい!!
941：スキルマップ見たい！ 見たいよ！
inao：興味津々。
杉田：先ほど言った4つの活動領域についてそれぞれスキルを紐づけていってスキルマップを作って、持ってるスキル、持ってないスキルを確認して、今期はどれに注力していこうかみたいなことを、毎週の1on1で話しながら挑戦していってもらってます。
inao：どう貢献したか、どう工夫したかとかはレポートでまとめてもらうんですか。
杉田：ですね。もちろん私も日々見ているのでわかってはいるんですけど、自分としてどうとらえているかというところの確認のため出してもらってます。
inao：壮大なスキルマップ、興味津々ですね。
941：見たい。
杉田：壮大すぎて「なんだこれ、脳みそか？」みたいな。
inao：項目も多いんですか？
杉田：そうですね、4つの活動領域に対して必要なスキルもさまざまだし、プロジェクトマネジメントスキルひとつとってもいろいろありますし。
941：それ、公開されますか？
杉田：そろそろ公開しようかなと。
一同：おおお。いいですね。
玉田：うちの評価の場合は、下期は技術カンファレンスが一番大きくて、主な定量的指標としては参加いただく方の人数と満足度を設定しています。参加人数はちょっと厳しくなってきてますね。やっぱり以前と同じ手法ではぜんぜん集まらなくなってきていて、毎回右肩上がりの達成というのは難しいなと思いつつも、満足度のほうは改善し続ければし続けるだけ上がってくるなあと思っています。満足度についてはNSATという手法をよく使うんですけど、それがこれまで110とか120だったのが、前回のDeNA TechCon 2023では、アンケート回答数も多かったんですけど、168くらいですごい高くなっていました。
上期はそのほかの技術カンファレンスとか、技術ブランディング活動の展開とかが評価指標です。いかに登壇数を増やすかとか、社内のエンジニアの発信数を増やすかみたいなところを最近はOKRに置いていますね。
一時期はTwitterフォロワー数とかも評価対象になっていて、めちゃ上げるようにがんばってたんですけど、1万突破してから最近はそれを見ないようにしています。最近はXになって動きがよくわからなくなってきているので、フォロワー数を増やすというのは今の時代には合ってないかなと。
inao：カンファレンスの参加人数が厳しいというのは、回を重ねると厳しくなってくるということですか？ それともコロナの影響ですか？
玉田：コロナの影響でみんな家にこもってたときはオンラインイベントってすごい集客しやすかったんですけど、今はもう状況が変わってきています。同じだけの広告予算を使っても、ぜんぜん人が集まらない。
inao：なるほど、ありがとうございます。
DevRelの体制
inao：続きまして、DevRelの体制について教えてください。開発者の人数にもよると思いますので、よろしければ開発者の人数も。
杉田：MIXIはDevRel自体は2名です。3人いたんですけど、1人が「エンジニアに戻ります。バイバイ！」って（笑）。
一同：笑
杉田：なので今2名ですね。ただ、開発本部にアシスタントさんがいらっしゃるので、アシスタントさんにイベントのお手伝いとか、もろもろ事務的なこととかをお願いしています。デザイナーさんも開発本部内にいるのでチラシデザインなどはお願いしています。
あとは採用人事とか、コーポレート広報とかとも連携しています。業務によっては法務とか知財、総務・社内ITまわりもですね。
DevRelってオフィスを使ったイベントとかで、若干、通常の使い方はしないので、怒られがちだったり、イレギュラーな相談ごとの多い立場なんですね。
941：わかる。だいたい何かお願いすると「初めての事例です」って言われる。「そういう風に使う人はいないですねー」みたいなことがすごい多い。
杉田：通常の事業、ビジネスではないので、法務とか経理とかも、事例にないことがけっこう多い。たとえば協賛も、通常であれば広告費じゃないですか。だからそれなりの契約書の内容になってくるとは思うんですけど、それだと技術コミュニティ側はボランティアベースでやってることも多いので対応負荷が高くなっちゃうので、その辺も連携してちょっと調整したりとかしています。
オフィスの利用のイベントとか、社内の勉強会とかは社内のエンジニアが手伝ってくれていますね。
941：うちはエンジニアが900人くらいいます。私達のチームは、さっき言ったようにジャンルによって分業してるんですけど、今は4人でやっていて、マネージャーが1人います。基本的にみんなのスキルセットは同じで、やれることは同じになっています。
できることとして、イベント企画、運営、撮影、配信、プロジェクトマネジメント全般が、全員等しくできる感じになってるので、たとえば誰か一人倒れても、状況だけ聞かせてもらえればぱっとスイッチできる状態にはなってる感じです。
で、うちはMIXIさんと一緒で法務とか総務とかは専門部署が担当してくれるので、細かいところはそっちと連携してやるんですけど、基本的には僕らは案件ごとにプロジェクトマネジメントしている。大きいものだと他の人も入れますけど、基本的には全部一人でやれる状態にはしています。
inao：4名規模のチームがいくつかある？
941：いえ、4名だけです。これからLINEヤフーになりますけど、ヤフーのみんなからは、けっこうハードにやってますねと言われます。
杉田：ちなみにうちはエンジニア350人くらいですが、100人のエンジニアに対して1人つくみたいな話ですかね。
941：inaoさんいけますね。
inao：はい、うち100人くらいです。
941：じゃあ、いけるんじゃないですか。週3日くらいでいけますよ（笑）。
inao：えええええーーーーー!! 人を増やす話にもっていければと思ったのに（笑）。
杉田：人数少ないほうが楽ではあります。スピードは速い。
941：なんでもかんでも合意を取り始めたらきりがないですからね。
杉田：やっぱりプロジェクトの進行に関しても、いちいち線引きしてこれでいきましょうって合意取って、みたいなことをやるよりも、どんどん動いちゃったほうが早い。協賛もどんどん、もらったらすぐ申し込まなきゃいけないみたいな。
941：結局、上の決裁さえ大きく取れていれば、あとは自由にやらせてもらったほうが動きやすいです。
杉田：こういう自由な人たちがたくさんいます（笑）。
玉田：DeNAのエンジニアはけっこういるんですが、エンジニアリング室のメンバーは6名です。それぞれ別のスキルセットです。その中でエンジニアじゃないのが2名。
なるべくドキュメント化して、本人が倒れても他の人でカバーできるようにしようとはしてるんですけども、やっぱりそれぞれが何か特化したものがありますね。 やることはもうめっちゃたくさんあって、チームでやってるんで、不慣れな人がやったりもします。それこそ法務と調整していろんなことをやるみたいな。
最近は、OSSに貢献するときにどういうケースなら大丈夫かというガイドラインを法務と一緒に作りました。策定に1年半ぐらいかかったんですよ。
941：かかりますね。うちもOSSは別チームで動いています。
玉田：グレーだったところを、ちゃんと会社としてガイドラインを作るっていうのがけっこう大変で、そういうのをやったりしてます。
新卒エンジニアは今年は約60名入りました。けっこうな人数じゃないですか。でも一人一人にちゃんとメンターをつけて、配属ガチャっていうのがないように、HRのメンバーがめちゃくちゃ丁寧に一人一人調整して、全員の希望を第3希望までもらって、部署にも見てもらって、部署にジョブディスクプションを書いてもらって、説明会もして、全員が第1希望、第2希望になれるようにやってました。
941：すごい。手厚いなあ。
玉田：もう「配属ガチャなくす!!」って決めてがんばったんで。それの記事をHRの方に書いてもらい、今度公開します（「DeNAの新卒配属プロセスの裏側を赤裸々に公開！ | BLOG - DeNA Engineering」）。
inao：楽しみです。
DevRelの予算
inao：みなさん、予算とか持たれてるんですか？
一同：はい、明確にあります。
inao：うちはまだないんです。
941：そりゃそうでしょうね。
inao：イベントとかもその予算の中からスポンサーを？
杉田：そうです。
941：私達も組織を作るとき、一番最初はやっぱり予算について時間を割きましたね。
inao：自分たちの活動は自分たちの予算から、と。
941：そうです。今までのそれぞれやってた活動を積み上げて、かつ、こういうこともやっていきたいから、これぐらいの予算が欲しいっていうのを一番最初にCTOに承認してもらって、それを消化して結果を出しながら、じわりじわりと増やしていきました。
杉田：もともとが人事スタートなので、人事のほうで採用イベントや求人サイトなどの広告費用の中から技術イベントなどにも協賛しましょうみたいなところから始まってますね、予算取りは。
941：うちは3つくらい予算があって、外部のイベントにスポンサーするお金と、あとはインターナルでいろいろ作っていくと内製だけだと大変なので、外部のパートナーに、たとえばライターさんとかカメラマンさんとかに入ってもらうのにその制作費用みたいなやつと、あとは通年に関わる協賛費用みたいのがあるんですよ、学会とか。そういう3つの柱が大きくあって、それを予算としてますね。
玉田：弊社は4項目に分かれていて、DeNA TechCon向け予算と、技術カンファレンススポンサーとかの外部ブランディング予算、社内向けイベントの予算、あとは協賛イベント予算。協賛イベントというのは、うちの会社のオフィスを利用してエンジニア向けの勉強会を開催するときにその開催をちょっと支援するみたいなことです。
（後編につづく）
制作協力：イトウヒロコ
写真：小山田 法師
