はじめに

みなさん、お久しぶりです！　
ワンキャリアでエンジニアをしている中西(@nana_nigiiro)です。
以前、デスクツアーの記事を書いてからしばらく経ち、内定者から社員へと無事にクラスチェンジしました。

現在はQA (Quality Assurance) チームとDevRel (Developer Relations) チームのリードをしています。
(QAチームの立ち上げに関しても、また別の記事でご紹介いたします)

この記事では、

• そもそもDevRelって何？

• なぜワンキャリアでDevRelチームの発足に至ったのか？

• テックブログの難しさとその対策

という部分に焦点を当てて話していきたいと思います。

そもそもDevRelとは？

Developer Relations(DevRel)とは「自社製品やサービス・企業と開発者の良好な関係性を築くためのマーケティング施策」のことを指します。

自社製品やサービスと開発者の関係性で言うと、例えば以下が該当します。

APIを公開することで、開発者が自社製品と互換性のあるサービスを作れるようにする

• SocialDog (TwitterAPIを活用)

• LINEで宅急便 - ヤマト運輸 (LINEのMessaging APIを活用)

• 家計簿 マネーフォワード ME (金融機関の参照系APIを活用)

開発者コミュニティ育成などを通じて、サービスの利用を活性化させる

• コミュニティの勉強会を通して利用者が増える (例：AWS)

• Q&Aサポートを充実させ、利用のハードルを下げる

一方、企業と開発者の関係性でいうと、技術的観点からの広義のブランディング・採用活動の意味合いが強くなります。
イベントやコンテンツ、SNSなどを通じて開発者と接点を持てば持つほど、開発者から興味や関心は持ってもらいやすくなります。
その結果として、多くの人が認知し、開発組織として魅力的なイメージがついた会社には多くの人が集まります。

DevRelは海外ではAWS(Amazon Web Services), Microsoft, GoogleなどGAFAMを中心にかなり普及してきています。日本でもSORACOM, LINE, yahoo!などDevRelに取り組んでいる企業は徐々に増えてきています。

個人だとMOONGIFTの中津川さんが有名です。
DevRelの概要をもっと知りたい方はこちらの記事をお読みください。

DevRelチーム発足の経緯

では、ワンキャリアのDevRelはどうなのかという話をしたいと思います。
現在、ワンキャリアはエンジニア向けのサービスを提供しているわけではないため、技術的観点からの広義のブランディング・採用活動がメインとなります。

しかし、そもそも、なぜエンジニアに向けたブランディングや、採用活動を後押しするようなDevRelという活動が重要なのでしょうか？

それは、エンジニア採用が3つの観点から難しいと言われているからです。(HirinGeek by Wantedly.)

1.採用競争が激しい
dodaが出している「転職求人倍率レポート(2022年6月)」では、IT・通信業の求人倍率は5.43倍と全体平均の1.91倍と比べ、2.5倍以上となっている。

2.業務の専門性が高く変化が激しい
一口にエンジニアといっても業務領域は細分化されており、ポジションごとに求められる経験・スキルが変わってきます。特に稀有な経験・スキルを持っているエンジニアはさらに少なくなり、より競争が激しくなっている。

3.採用できる媒体が限られる
採用媒体を利用せずに、Twitterや知人からの連絡といった人脈を利用してリファラル転職するエンジニアも増えてきており、他の職種と同じ媒体だけでは採用ターゲットが見つからなくなってきている。

上記の理由からエンジニア採用のステップは複雑かつ、多様化してきています。

当たり前ですが、知られていない・よくわからないエンジニア組織は就職先の候補として名前が上がることすらありません。
弊社にエンジニア組織ができたのはここ数年のことであり、まだまだ世間での認知度は非常に低いのが現状です。
そこで、DevRelチームを発足し、自分達がどんなエンジニアリング組織なのか外部に発信していくことが重要だと考えました。

他社事例を参考に、さまざまな施策について検討し、まずはテックブログから始めることに決めました。
テックブログは記事を通じて技術面でも組織面でもやっていることが見えやすく、アセットとして積み重ねていくことができます。

テックブログを始めてみてわかったこと

では、実際テックブログを始めてみてどうだったのか？

テックブログについてよく言われている言葉があります。
「テックブログは継続が難しい」
弊社も例に漏れず、しばらくは投稿を継続できていたのですが、私が入社した2022年4月から4ヶ月ほど、更新ができていませんでした。

原因は私のディレクション不足と言ってしまえばそこまでですが、より具体化すると「テックブログを書く仕組み」と「インセンティブ」の２点が大きな要因として挙げられます。

まず、テックブログを書く仕組みに関しては、組織を巻き込んだ仕組み化ができていませんでした。
テックブログが始まった当初、当時内定者だった私が執筆者のフォローから投稿までを全て受け持っていました。
しかし、私が社員となり他の業務が増えたことで、私だけでは管理しきれなくなり破綻しました。
つまり、内定者時代に記事を出せていたのは、そこに個人の時間を多く投下していただけであり、周りを巻き込み、ルールに従って運用していくという仕組みづくりはできていなかったのです。

次に、執筆者にインセンティブを与えるような構造になっていないことも問題でした。
人によりますが、１つの記事を執筆するのに修正含めて5-10時間程度かかります。
エンジニア組織内で各メンバーにお願いして書いてもらうにしても、日々の業務と並行してこの工数を捻出するのは非常に難しいです。
特に初期は有志のボランティアに頼っていたため、業務が多忙になると優先度が下がっていき書くペースはどうしても落ちます。
結果的に管理ができなかったこともあり、期日遅れが常習化してしまいました。

このように要因を明らかにしていく中で、運用体制を抜本的に改革していく必要があると気付かされました。

どのように改善していったのか

まずは周りを巻き込み、DevRelチームのメンバーや関係者を増やしました。
ライター経験のある方や、個人でブログ運営をしている方にDevRelチームに入っていただき、複数人でスケジュールやコンテンツを管理する体制を作りました。
また、広報チームとも連携をとり、記事作成の半分を受け持ってもらうような体制を組みました。
これにより、属人的だった管理体制を組織化することができ、運用の不安定さが減りました。
加えて、私のディレクションコストが軽減し、執筆に時間を割けるようになりました。
コンテンツ数が少なく、活動が閑散としている状態では社内でも協力しようと思ってくれる人は増えません。私が先頭を切って記事を積極的に出していくことで、社内に協力してくれるファンを増やしていこうと考えています。

また、インセンティブに関しても、個人目標に「テックブログを含む外部発信」を入れることで、テックブログを書くことが評価されるような仕組みも作りました。
これにより、各エンジニアは業務時間の一部を使って、テックブログの執筆や、外部イベントへの登壇、OSSのコントリビュートなどに取り組むことができるようになりました。
まだ制度を整備したばかりではありますが、「今度こんな記事を出してみたいから執筆する際に相談させてほしい」といった声をいただいております。
この制度をうまく機能させて、外部発信を積極的にしていく文化を根付かせることができれば、自然とテックブログのコンテンツも増やせていけると考えています。

さいごに

今回は以下３つに焦点を当ててお話ししてきました。

• そもそもDevRelって何？

• なぜワンキャリアでDevRelチームの発足に至ったのか？

• テックブログの難しさとその対策

テックブログはとにかく継続していくことが何より重要だと考えています。
運用体制を改革したとはいえ、継続して投稿できるかどうかはこれからにかかっています。

また、DevRelチームとしては、外部イベントへの登壇機会創出やエンジニア向けイベントの開催など、テックブログ以外の活動も少しずつ進めていきたいと考えています。

※追記
ありがたいことに2022/8/5にDevRel/Japan CONFERENCE 2022に登壇する機会をいただきました。

DevRelチームは目的も活動も企業ごとに少しずつ違っており、模範回答はありません。私たちはワンキャリアとしてのDevRelチームをこれからも模索し、その中で弊社のエンジニア組織に興味を持ってくれる方が増えるよう取り組んでいきます。
もしワンキャリア技術開発部にご興味を持った方はこちらをご覧ください。