「エンジニア採用を拡大したいが、何から始めたら良いかわからない」といった方は、とても多いのではないでしょうか。
このような中で、自社の“IT技術”に関する情報を外部に戦略的に発信し、エンジニアへの企業ブランディング向上に繋げる「技術広報」という考え方が、IT企業を中心に注目を集めています。
今回のHR-Studyは、自社の技術力やエンジニアの取り組みなどを戦略的に発信し、社外のエンジニアの認知を高める「技術広報」について取り上げ、テックブログの運営方法や各施策の効果について、元エンジニアとしてDeNA技術広報を務める玉田さん、メルペイの技術広報である地田さんにお話いただきました。
「技術広報を始めるメリットを知りたい」「技術広報の具体的な取り組み内容を知りたい」という方は、ぜひ参考にしてください。
※本記事は、2023年02月10日 12:00 – 13:00 に実施されたイベント内容をもとに再編成したものです。
登壇者紹介
玉田 大輔|株式会社ディー・エヌ・エー 技術統括部Engineering室技術広報
2009年 DeNA 新卒入社。エンジニア、エンジニア採用担当、エンジニア研修PM、スクラムマスター、エンジニアマネージャー、事業開発担当という経験を経て、2018年から DeNA の技術広報を担っている。
地田 美紀|株式会社メルペイ Tech PR
大学卒業後、人材紹介の営業およびキャリアカウンセラー、IT領域の採用担当、新規事業担当、広報PRを経験。2021年8月、メルペイ入社。Tech PR担当として、エンジニア向け Twitter の運用、テックブログの推進、技術イベントの企画運営などを行っている。
モデレーター紹介
西村 創一朗|株式会社HARES CEO/複業研究科/HRマーケター
1988年神奈川県生まれ。新卒でリクルートキャリアを経て、本業の傍ら2015年に株式会社HARESを創業。2017年1月に独立し、複業研究家として企業向けコンサルティングや、経産省「人材力研究会」の委員を務めるほか、『複業の教科書』を出版。独立後、3年間で3度メンタルダウンを経験し乗り越えた原体験を元に2021年10月にメンタルヘルステック領域のスタートアップとして株式会社Mentallyを創業。
[勉強会の内容をまとめたスケッチノート]
目次
はじめに|そもそも「技術広報」とは何か
DeNAの玉田です。もともとはエンジニアとしてDeNAに入社し、2018年から技術広報を担当しています。
技術広報になってから、Twitterやエンジニアブログの運用、DeNA TechConという技術カンファレンスの主催などを手掛けてきました。Twitterアカウントは間もなく1万フォロワーで、DeNA TechConは計7回開催し2,000名以上のエンジニアにconnpassで登録いただいた実績があります。本日はよろしくお願いします。
メルペイのTech PRを務める地田と申します。
私は営業や採用担当、新規事業担当など幅広いキャリアを歩んできて、メルペイに入社する直前はスタートアップの広報・PRとして働いていました。
そして、広報・PRの仕事で技術広報に関わる機会があり、Tech PRのキャリアを積みたいと考えて2021年8月にメルペイに入社しました。
今日は、約1年半メルペイで取り組んできたことをお話したいと思います。
本日のモデレーターを務める西村です。まず、パネルディスカッションに移る前に、そもそも技術広報とは何か、その基礎知識について簡単にご紹介したいと思います。
本日のテーマである技術広報とは、社外のエンジニアに対して自社のプレゼンや認知拡大などを目的に、技術的な情報の社外発信を推進することを指します。
発信方法としては、テックブログの運営や自社イベントの開催、SNSでの発信といったアプローチが主流です。エンジニア採用を推し進める目的だけでなく、企業のイメージアップのためにおこなうケースも増えてきています。
この話をふまえて、お2人から具体的な取り組み内容について伺っていきたいと思います。
パネルトーク|DeNA・メルペイが実践する技術広報
Q1. 技術広報を始めたきっかけは?
最初のトークテーマは、「技術広報を始めたきっかけ」です。いつ・どんな目的で・なぜ技術広報を始めたのか教えていただけますか?
私は、DeNAにエンジニアとして入社した後に、事業開発や採用・研修など様々な業務に携わってきましたが、その中でも「エンジニア×人事」として提供できる価値が高いと感じました。
2018年に「エンジニア×人事」として異動することになり、異動後に求められた仕事が技術広報でした。おそらくですが、エンジニア採用市場が以前に比べ更にレッドオーシャン化しており、技術ブランディングの重要性が高まったことが、私が技術広報になった理由だと思っています。
メルペイは、2015年頃から技術広報を始めたと聞いています。当時のメルカリCTOが「もっと多くの人に技術の良さを知っていただきたい」と考え、発信する文化を作ったそうです。
現在は『技術の発信が産業への還元』という方針を掲げ、エンジニアの技術発展に貢献したいという想いで取り組みを進めています。
また、メルペイではTech PRの独自方針として「メルペイのエンジニアリング組織に関わる発信(技術、ヒト、組織など)をし続ける仕組みを作る」をミッションに置いています。
Tech PRは開発組織内のEngineering Engagement Teamに所属しており、このチーム自体の業務領域は「候補者体験」から「従業員体験」と広くまたがっていますが、その中でもTech PRは「認知・興味」の部分を担当しています。
Q2. 技術広報の具体的な発信方法
続いて、どのような方法で社外のエンジニアに情報発信をしているのか、その発信内容とあわせて教えていただけますか?
Twitterや技術カンファレンス、テックブログなど、リーチできる人が多い手法を選んでいます。
発信手法よりも、発信するコンテンツが非常に大事ですよね。僕たちは、エンジニアのみなさんが業務で工夫したり取り組んだりしたことを「抽象化」してから発信することをサポートするように心掛けています。
個別・具体的な課題解決方法が万人に当てはまるケースは稀です。抽象化した方が、より多くの方の課題解決の後押しができると考えています。
抽象化すると、より社会全体に活かせるノウハウになるという考え方は共感します。
弊社は、主にエンジニアブログを使って情報発信をしていますが、これに加えて、大小さまざまイベントを開催しています。
その中でも、毎年主催している「Merpay Tech Fest」が最も大きなイベントで、2022年は3日間で20のトークセッションとワークショップを実施しました。
Q3. テックブログの運用方法について
2社ともたくさんの手法をお持ちですね!
続いては、より具体的にテックブログの運用方法やコンテンツ企画のコツなどについて伺いたいと思います。
テックブログの運用方法は、2022年末のアドベントカレンダーに『技術広報としてできることを増やすためにおこなってきた仕組み化』というタイトルで、今までチームで培ってきたノウハウを記事化しました。
今まで、多いときには年4回も技術カンファレンスを実施してきたので、そろそろカンファレンスのフローをマニュアル化する必要があると考えました。テックブログに関しても同様に、標準化をするために記事にノウハウをまとめました。
アドベントカレンダーの記事の内容を、かいつまんでご紹介します。
テックブログの運用において、「エンジニア個人が記事を書いて情報発信する」ができる現在ですが、そこであえて「エンジニアが会社のブログで記事を書く」を選んでもらうためには会社として提供できる付加価値が重要だと考えています。
たとえば、会社のブログで公開すると公式Twitterアカウントで宣伝してもらえる、公式Twitterアカウントのフォロワーは多いので、記事を公開すればエンジニアにとってメリットがあるといったような形です。これは、1番わかりやすい付加価値だと思います。
また、記事を書く際の最も大きなハードルは、ネタ選び、企画(構成案)の作成です。スムーズにブログ作成に取り組めるように「壁打ち」を一緒にして、ネタ整理や構成作成のフォローをおこないます。
具体的には、最初にどのようなネタであれば書き進めることができそうか聞き出し、その中で面白そうな部分を抽出していきます。そして、ブログ内容を誰に読んで欲しいのか、読んでもらった後にどうなってほしいか、といったゴールまで決めていきます。
執筆や登壇準備が初めてのエンジニアに全部丸投げするのではなく、技術広報としての目線も入れて壁打ちした方が書きやすくなると思っています。
私は、普段からのエンジニアへの声掛けや社内アンケートの実施、アドベントカレンダーなど特集を企画して、エンジニアがブログを書きやすい環境づくりを推進しています。
また、メルカリグループとしては「メルカリエンジニアリングブログ」という場所に各社の記事が公開されるので、公開日時が被らないようメルカリ側の担当者と調整することも多いですね。
何を書けば良いか悩むメンバーは多いですが、ネタに困ったらエンジニアリングマネージャーに直接相談しています。
私は、玉田さんのようにエンジニア経験がなく壁打ちはあまりできないので、記事の内容はメンバーやエンジニアリングマネージャーに頼りつつ、書いてもらった記事のチェックをして読みやすい文章になるようフィードバックをしたり、目を引くようなタイトルを提案するようにしています。
Tech PRは、第3者目線で添削・編集をして、より良いコンテンツにブラッシュアップする役割と考えています。
なるほど。玉田さんのようにエンジニア経験を活かしたり、地田さんのように広報や採用スキルを活かしたりするなど、アプローチ方法はさまざまですよね。
ちなみに、テックブログを定期的に書いてくれるエンジニアはどれくらいいるのでしょうか。
まだまだ参加人数は少ないので、もっと書いてもらえるように特集を組むなどの仕掛けづくりを試みている最中です。通常業務がある中で、プラスαでブログを書いてもらっているので、時間をうまくとって、みんなで協力して継続している感じですね。
DeNAでも、なるべく自発的に書いてもらえるような声掛けをおこなっています。
時には「記事が足りないです。誰か協力お願いできないですか」といったように新しいエンジニアにお願いすることも多く、いつも決まった方が書いているわけではないです。
会社の規模や方針にもよりますが、「年に1回は必ず全員で書く」とスケジュールを決めている企業もあるそうですよ。
ブログの記事執筆は、エンジニアの通常業務のアドオンとのことですが、評価項目には入れていますか?
部署によってまちまちです。評価項目に入れていない部署もありますが、組織全体のカルチャー基準に情報発信の内容を組み込むことで、全体で取り組みやすいようにしています。
DeNA Engineer Quality(DEQ)というDeNAのエンジニアとして大切にしていきたい価値観を言語化したものの定義の1つに「Expand your horizons」を掲げているのですが、これは「外部発信をする・外部情報を組織として収集する」を重視した基準です。
この価値観をエンジニア「組織」のカルチャーとして策定してから、会社全体の情報発信や共有が進んだと実感しています。
Q4. 技術広報施策の良かったこと・しくじり話
それでは、これまでに技術広報で進めた施策で良かったことや、うまくいかなかったことを振り返っていただけますか?
しくじりは多いですよ。
大きくやらかしたわけではありませんが、先日、上司と1on1をしたときに「玉田さんは、最初は仕事を丁寧にお願いするけど、2回目以降は慣れた態度になり周囲への感謝が減っちゃうよね」とフィードバックされました。
忙しすぎて、施策に協力してくれたエンジニアの皆さんへの感謝が伝えきれていなかったのは反省点です。
技術広報は長期施策なので、「一緒にずっと頑張っていきたい」と思われないといけない。もっと丁寧に、感謝の言葉やフィードバックを伝えていこうと考えています。
関係づくりを怠ってしまったことが、最近のしくじり話なんですね。地田さんはいかがですか?
想定以上にイベント集客ができなかったり、イベント日時がメルカリグループ内で被ってしまったり、という失敗はありました。
一時期、メルカリグループ全体でイベントが乱立していたときに、同じ技術領域のイベントが被ってしまって。
イベントページを公開した後でしたが、仕方がなく日程を再調整しました。
技術広報に積極的な会社だからこそ、イベントが被ってしまったんですね。
失敗談ではなく、成果や振り返る基準についてもお聞かせいただきたいです。
振り返る際は、採用数やPV数はKPIにせず、業界のエンジニアのみなさんが「DeNAをどう思っているか」を計測しています。
弊社もPV数などは追っておらず、発信人数、発信数などを見ています。そして、メンバーが能動的に発信したいと思っているかという「意欲」を確認しています。
せっかく自ら情報発信したにも関わらず、いやな経験をして「もう発信したくない」とならないよう、みんなが前向きに発信できる環境づくりをするのもTech PRの役割だと考えています。
Q5. 技術広報に必要な要素とは
ここまでの話を踏まえて、どのような人が技術広報に向いていると思いますか?
大前提として、技術への興味は重要です。その上で、コミュニケーション力とわからないことを素直に聞ける力が必要だと思います。
私がわからないと素直に伝えることで、エンジニアメンバー達も「この部分は自分たちがフォローしないといけないんだ」と理解できてフォローしやすくなります。
エンジニア経験がなくても、わからないことは素直に聞いて、協力することが大事です。
エンジニアとのコミュニケーションで意識していることはありますか?
エンジニアの方々が何をやっているのか、興味を持って知ろうとする姿勢を見せることでしょうか。ちゃんと興味を持っていると伝われば優しく教えてくれます。助けて欲しいことは、遠慮せずに言うように心掛けていますね。
僕のようにエンジニアのバックグラウンドを持っている方であれば、「発信する内容についてはわからないからお任せします」と謙遜するのではなく、「一緒に良くしていこう」という対等な姿勢で向き合うことが大事だと思います。
そして、エンジニアのバックグラウンドを活かして外部発信する内容を確認し、「一般の方はこれだとわかりづらいかも」と具体的なフィードバックをすること。ただし、エンジニアへの配慮を忘れず言葉を選ぶことが大事だと思います。
ただお願いするのではなく、一緒に作る姿勢が大切なんですね。
視聴者からのQ&A
最後に、視聴者のみなさんから寄せられた質問を取り上げていきます。
Q1. エンジニアブログは、1記事あたり何時間ほどかかるものですか?
人によって執筆時間に差があります。そのため、業務の中にどうやって組み入れるかは本人にお任せしています。
前に計測してみたとき、登壇資料は2日ほどかかる方が多かったですね。ですが、やはり個人差があるので、中には1週間かけている人もいました。
慣れている方であれば4時間あれば1記事書けるそうですが、最初は2日ほど見積もっておけばいいのではないでしょうか。
ただ、時間をかけることよりも、何を発信していくかが大切なので、あまり時間にとらわれすぎず取り組んでみると良さそうです。
Q2. 組織の評価項目に入れると技術広報は促進しやすくなると思いますか?
組織カルチャーであるDEQ(DeNA Engineer Quality)を定義してから、メンバー同士の情報交換は盛んになり、かなり効果を得られるようになりました。
今後は外部発信の強化を課題としていますが、以前に比べて現状は、前向きな雰囲気になったと感じています。
Q3. バズったコンテンツ/エンジニアに好評だった記事の内容を教えて下さい
DeNAの創業者である南場がAWSサミットで登壇したコンテンツは、とても好評でした。AWS サミットでは多くの経営者の方々も視聴者として閲覧するため、同じ経営者として得た学びをどうにか共有できないかと考え、学びを抽象化できたのが良かったのではないかと思っています。
直近のアドベントカレンダーで好評だった記事としては、Machine Learning Platformチームの立ち上げからクローズまでの話を書いた記事やGraphQLについてまとめた記事ですね。
これらの記事はどの会社にでもありえる事象を抽象化し、一つの事例として紹介しているので好評だったのだと思います。