DevRelの施策(コンダクター)

はじめに

これまで、数回に分けつつDevRelの基本的な考え方となる「4C」について解説しています。最初にContents(コンテンツ)、前々回ではCode(コード)、前回ではCommunication(コミュニケーション)を取り上げました。4Cの最後となる今回は、Conductor(コンダクター)について解説します。コンダクターは人に関する要素になります。

DevRelは開発者とのつながり(リレーション)にフォーカスしていますので、人は大事な要素です。今回の内容を押さえておくことで、DevRelではどういった職種の方達が関わっているのかが見えてくるはずです。

エバンジェリスト・アドボケイト

エバンジェリスト・アドボケイトはどちらも宗教に関連する用語です。区別するためにテクノロジーエバンジェリスト、デベロッパーアドボケイトと呼んだりします。名前は違いますが、行なっていることはあまり変わらない印象なので、1つにまとめて紹介します。また、以降は単にエバンジェリストと書きます。

エバンジェリストの大きな役割は、自社サービスについてテクノロジーの視点から啓蒙活動を行うことです。例えばイベントやカンファレンスでの登壇、ブログ記事の執筆、コミュニティイベントへの参加、ソーシャルメディアでの発信などがあります。

多くのエバンジェリストがもともと開発者としてのバックグラウンドを持っています。そして、専門的な技術分野があり、そのスキルセットを活かしてエバンジェリスト活動(啓蒙活動)を行います。分かりやすいところでは、Unityなどのゲーム分野においてはもともとゲーム開発を行なっていた方がエバンジェリストになっていることが多いです。啓蒙を受ける側の開発者としても、その分野での有名な人や経験豊富な方が語った方が腑に落ちやすいでしょう。

ここからは、エバンジェリストの主な役割を紹介していきます。

登壇

エバンジェリストに必要なスキルの1つがプレゼンテーションスキルでしょう。小さなミートアップイベントからカンファレンスまで、数多くの登壇機会があります。イベントには、様々な属性の開発者がいます。既存ユーザーもいれば、まだサービスを知らない・触ったことがない人もたくさんいるでしょう。そうした方々にサービスを知ってもらい、「使ってみようかな」と思ってもらうのに登壇はピッタリです。

登壇例

相手が開発者であるという点を考えると、宣伝的なプレゼンテーションは禁物です。営業的な雰囲気を感じると、開発者は去ってしまうでしょう。開発者が楽しめるような技術的な内容を盛り込んだ、魅力あるプレゼンテーションをしなければなりません。そうしたプレゼンテーションは開発者としてのバックグラウンドがないと、バランスが掴みづらいようです。

魅力あるプレゼンテーションを行うには、トークスキルはもちろんのこと、スライドを作成するスキルも必要です。営業的なスライドは文字が多く、プレゼンテーションの内容が全て盛り込まれた内容になっているものをよく見かけます。営業資料ならそれでも良いですが、DevRelでは営業をしたいわけではありません。開発者の目を惹きつけ、使ってみたいと思わせるスライドはそう言ったものではないでしょう。

ブログ記事の執筆

多くのエバンジェリストが自社やQiita、Zennなどでブログ記事を書いています。エバンジェリストは自社サービスの一番のユーザーであるべきで、体験した際の記事や、他の開発者の創造性を刺激するような内容を発信しなければなりません。こうしたアウトプットスキルが根底にないと、魅力あるエバンジェリストになるのは難しいかもしれません。

ブログ例：ニフクラ mobile backend (mBaaS) お役立ちブログ

もし、すでに自社サービスがローンチしており、後からエバンジェリストになったという方であれば、ぜひ自社サービスをビギナーとして触り始めるところからブログ記事にしていきましょう。初学者の目線で書けるのは、初学者である時が一番有効です。慣れてしまうと忘れがちな躓きポイントと回避策を書いておくことで、多くの初学者にとって役立つコンテンツになるでしょう。

デモアプリの開発

エンジニアからエバンジェリストになると、開発現場からは遠ざかってしまいます。そのため、開発業務に携われなくなるのを危惧する声も多いです。確かにプロダクトレベルのコードを書く機会は減ってしまうでしょうが、開発に関わることはできます。その1つがデモアプリの開発です。

デモアプリ例：NCMBMania/monaca-voice-recorder

自社のAPIやSDKを使って、デモアプリやチュートリアルコンテンツを作成します。エバンジェリストは自社プロダクトの第一ユーザーであり、新しい機能を率先して利用したり、ユーザー目線でのフィードバックを行うべきです。むしろシステム内部を知らない分、使いやすいAPIの設計やSDKの形を提案できるでしょう。

筆者の場合、よくSDK開発も行っています。言語としてはNode.js/TypeScript/Python/PHP/Ruby/Dartなどです。そうした様々な言語を使ったSDK開発や、そのSDKを使ったデモアプリ開発を行えるのはエバンジェリスト職の魅力ではないでしょうか。

ソーシャルメディアでの発信

DevRelで使われるソーシャルメディアはTwitterが一番多く、ついでLinkedInになるでしょう。FacebookやLINE、Instagramはあまり使われていない印象です。こうしたソーシャルメディア上で発信を行うのも大事な役割です。複数人で運用する場合もありますが、多くの場合特定の担当者が責任を持って運用します。

ソーシャルメディア例：ニフクラ mobile backend (@nifcloud\_mb)

主な発信内容はブログ記事やイベントの案内などになるでしょう。また、サービス名などでエゴサして、困っているユーザーがいれば積極的に助けるのも大事な役割です。企業アカウントではキャラクター付けするケースもありますが、DevRel周辺のアカウントではあまり見かけません。少し前には女性キャラクターのアカウントを作成し、発信するトレンドがありましたが、止めてしまったり発進停止するケースが増えています。

コミュニティへの参加

ユーザーコミュニティであったり、外部の開発者コミュニティに参加して開発者とコミュニケーションします。自社プロダクトを知ってもらう機会にもなりますし、現在開発者が課題と感じていることを聞ける場にもなります。

コミュニティイベントの例

とあるエバンジェリストは、自分の仕事を「自社プロダクトに改宗してもらうこと」と表現していました。そのため自社プロダクトのユーザーコミュニティだけでなく、コンペティターであるサービスのユーザー会にも積極的に参加していました。ある意味アウェーになるコミュニティですが、そうした中でも良好なコミュニケーションを行えると、活動の幅が広がるでしょう。

ユーザーコミュニティでは自社プロダクトに対するフィードバックを得る良い機会になります。そうした開発者の生の声は開発チームにフィードバックし、改善につなげなければなりません。

コミュニティマネージャー

コミュニティマネージャーは自社プロダクトに関するコミュニティを作り、育てるのが主な役割になります。DevRelに関する職種としては、最もコミュニケーション能力が求められるかも知れません。

コミュニティは主に2パターンあり、運営母体によって分かれます。以下、その2つについて紹介します。

自社運営のコミュニティ

自社運営の場合、コミュニティマネージャーやエバンジェリストが運営します。イベントの企画、登壇者のアテンド、会場の準備、受付などを自社で行います。そしてユーザーなどの開発者の方を招いてイベントを開催します。

この場合のメリットは、自社責任でイベントをハンドリングできることです。コンテンツの品質、イベントの頻度、競合他社の参加可否などを自由に決められます。コミュニティマネージャーとしてイベントを行うのが仕事になるので、忙しくてイベントができないという事態も避けられます。

デメリットはマンパワー不足に陥りがちなことです。イベントの企画や登壇者探しなどは、かなりの工数がかかります。毎月1回行うとしても、年間12回程度しかイベントを開催できません。イベントをもっと数多く開催しようと思うと、1人では回せなくなるでしょう。

ユーザー運営のコミュニティ

有名なコミュニティとしてJAWS-UGがあります。主にパートナー企業などにより運営されますが、純粋にそのプロダクトが好きだから参加している方もいます。地域によって支部が分かれたり、特定技術領域にフォーカスした分科会もあります。

ユーザー運営のメリットは、少ないコミュニティマネージャーでもコミュニティが大きく広がっていく可能性があることでしょう。各支部の運営はユーザーに任せられるので、自社の支店がない地域でもイベントが開催される可能性があります。

ユーザー運営コミュニティの例：JAWS-UG (AWS Users Group – Japan)

デメリットは運営をユーザーに委ねるため、その内容までコントロールするのは難しいということです。むしろコントロールしようとすると、運営してくれている方々の反発を招きかねません。ユーザー主体のコミュニティの場合、コミュニティマネージャー自身コミュニティメンバーの一員であるという認識が必要です。

ユーザー主体のコミュニティが実現できるかはユーザー数が一定数以上存在することや、利用者が自社プロダクトにロイヤリティーを持っていることなどが最低条件になります。そのため、敷居の高いコミュニティ形態とも言えるでしょう。

プログラムマネージャー

DevRel活動の一環としてイベントへのスポンサードやスピーカーの手配、ハッカソンへの開発チーム派遣などを管理します。スポンサーとしてブースを出す場合には、その展示物の配送手配やノベルティ発送なども行います。

ブース例

大企業になると、イベントも毎週のように(場合によっては重複して)参加します。そうした際にスピーカーが重複しないように管理したり、備品が確実に発送されるように手配します。中小企業では必要ないかも知れませんが、複数人体制になったり、企業規模が大きくなると必要不可欠になるでしょう。

マーケター

もちろん、マーケターも必要です。DevRelに関わる人たちは技術的なスキルとマーケティングスキルが求められますが、それでも選任のマーケターに比べると見劣りするでしょう。適切な目標と測定方法の設定、施策決定、モニタリングなど様々な場面でマーケティングスキルが求められます。

エバンジェリストの活動においても効果測定が求められますが、それを意識しながら活動するのはとても大変です。そこでマーケターから測定できるURLをもらったり、測定ポイントを教えてもらうことで仕事が進みやすくなります。

DevRelの活動はコミュニティやフィードバックなど、定性的なものがとても多いのが難点です。測定しづらいために、後で振り返ったときに何が効果的だったのか分かりづらいでしょう。そうした際にマーケティング視点で効果測定し、数字を追いかける姿勢はとても大切です。

サポートエンジニア・カスタマーサクセス

外部の開発者との接点として、サポートエンジニアやカスタマーサクセスの存在は欠かせません。エバンジェリストの活動の多くがプリセールス(購入前の顧客向け)であるのに対し、サポートエンジニアは購入してくれた顧客をサポートする仕事になります。

中の人が積極的に答えてくれるフォーラム例：Ionic Forum - Build cross-platform mobile apps with HTML, CSS, and JavaScript

SaaSやクラウドサービスの多くは、使ってみてサポートが悪いと判断されると簡単に契約停止されてしまいます。SaaSではチャーンレート(解約率)をKPIとしているのはそのせいです。継続して使い続けてもらうからこその成長であり、その要になるのがサポートエンジニアです。

サポートエンジニアに寄せられる質問は開発チームへフィードバックし、今後の開発計画立案に活かすべきです。また、FAQの充実であったり、オンラインでのQ&Aフォーラムでの回答などもナレッジ蓄積とセルフサポートへつながるでしょう。

テクニカルライター

テクニカルライターの主な職務はドキュメントの整備や体裁の統一、ブログ執筆などになります。ドキュメントで用語が統一されてなかったり、異なる言い方があると開発者を混乱させます。サポートへ寄せられる質問でも用語が違うと、正しいサポートができなくなる場合があるでしょう。そうした問題を防ぐのがテクニカルライターの役割です。

テクニカルライターのいるプロダクトでのドキュメント例：Hexabase 開発ガイド

コード中のコメントから自動生成されるドキュメントもありますが、そちらもテクニカルライターのチェックを通した方が良いでしょう。エンジニアはドキュメントを書くのが主な職務ではないので、どうしても人によって品質のバラツキが生じます。そうした差異をなくし、読みやすいドキュメントにすることで、開発しやすさを維持できます。

テクニカルライター自身がエンジニアリングスキルを持っている場合と、そうでない場合があります。前者の場合、プログラミングもしながら文書が書けるので、より品質高いドキュメントになるでしょう。後者の場合、ライティングスキルが高い人が多いので、コラムなどの技術系記事が得意な方が多いようです。

トランスレーター

海外のクラウドサービスを日本市場で展開する場合、ドキュメントの翻訳などでトランスレーターが必要になります。英語のドキュメントのままでは、日本企業での利用はあまり増えないでしょう。そのためドキュメントの翻訳が必要になったり、ブログ記事の翻訳も必要になります。

ローカライズドキュメントの例：Drupal 8 ユーザーガイド

最近では翻訳サービスの品質も高くなっていますが、それらはGoogleでインデックス化されているわけではないため、日本語で検索しても見つかりません。あらかじめ翻訳しておくことで、日本語情報として検索されるようになります。

ドキュメントの翻訳は一時的な作業ではなく、開発が続く限り継続して行う必要があります。開発部隊と細かくリレーションをとりながら進めないと、オリジナル言語と日本語ドキュメントで差異が生じかねません。間違ったドキュメントほど開発者の信頼を裏切るものはないので、継続できる工数とマンパワーが確保できるかどうか慎重な判断が必要です。

人事

開発者向けのサービスやAPIを提供していない企業でもDevRelを行っているケースが増えています。そうした企業の目的は開発者の雇用です。自社を知ってもらい、魅力を伝えることで転職してもらうことを期待しています。そのため、開発者向けのカンファレンスでブースを出している場合において、人事部門から予算が出ていることは多々あります。

人事担当者においても、開発者を対象とした場合に相手を理解する気持ちが必要です。開発者を大切にしていない企業はすぐに見透かされてしまい、雇用もままならないでしょう。その結果、開発者の質が下がる、給与を高くするなどライバル企業と差ができてしまいます。

日本の少子高齢化とIT化もあって、開発者が売り手市場トレンドは今後もしばらく変わらないでしょう。開発者を雇用する上で、人事担当者の責任は大きいと言えます。特に昨今では一極集中が続いており、人気のある企業とそうでない企業ではっきり分かれるようになっています。

おわりに

今回は、DevRelに関係する主な職種とその仕事内容を紹介しました。人事やマーケターのようにDevRel専門職ではない職種もありますが、思っているよりも多かったのではないでしょうか。個人の素養によって、様々な選択肢があるのがお分かりいただけたかと思います。

DevRelではエバンジェリストやアドボケイトにスポットが当たりがちですが、それ以外の職種もとても大事です。一職種で開発者の様々なニーズを満たせるわけではありません。ぜひ全社一丸となってDevRelに取り組んでください。