DevRelに関わる職種
はじめに
前回まで、実際にDevRelで行っていることや、その種類について紹介してきました。今回は、そうしたさまざな施策を「誰が行うのか」について解説していきます。
ときどきそのような記述等を見かけるのですが、DevRelは職種ではありません。DevRelに関わる様々な職種があり、そうした方々が部署としてのDevRelに所属する形になります。
テクノロジーエバンジェリスト・デベロッパーアドボケイト
自社製品、サービスを外部の開発者に相対して啓蒙する役割を担っているのがテクノロジーエバンジェリストやデベロッパーアドボケイトです。単にエバンジェリストやアドボケイトと言ったりもしますが、元々は宗教用語(エバンジェリスト＝伝道者)です。以降ではエバンジェリスト、アドボケイトとして解説します。
この2つの肩書きは、求められているロールに大きな違いはありません。エバンジェリストはカンファレンスなどで多くの開発者に接するのに対して、アドボケイトはより個人や数人の開発者と相対して彼らの実課題を一緒に解決するというイメージです。1つのチームにエバンジェリストとアドボケイトの両方がいて、きちんとロールを分けているケースは少ないでしょう。
カンファレンス登壇の例
エバンジェリストやアドボケイトの多くが開発者としてのバックグラウンドを持っています。自社テクノロジーを開発者に伝えるためには、開発者としての目線が必要だからです。とはいえ、技術自体と自社を愛する心があれば、さくらインターネットの横田 真俊さんのような開発者ではないエバンジェリストにもなれるでしょう。
他にも、LINEの櫛井 優介さんがCulture Evangelistという肩書きだったり、必ずしも「テクノロジー」エバンジェリストではないケースもあります。
コミュニティマネージャ
開発者コミュニティを作るのであれば、企業側からも窓口になる人が必要です。コミュニティマネージャはそのための職種です。開発者コミュニティが自社運営の場合とコミュニティ主体の場合で、取るべき立ち位置が変わるので注意してください。
自社運営の場合は、コミュニティマネージャーがイベントの設計と運営を担当します。社内メンバーに登壇を依頼したり、イベントの開催場所の手配、司会などを担当します。イベント実施後には参加人数やツイート数などをレポートとして作成します。
コミュニティ主体の場合には、運営には参加しないのが一般的です。一例としてJAWS-UGが知られています。JAWS-UGはAWSを利用している企業や個人の方々が運営しているコミュニティで、AWSは運営に参加していません。ただし、必要に応じてサポートを提供しています。このときのAWS側の窓口がコミュニティマネージャーの役割です。
ユーザーコミュニティイベントの例
コミュニティ主体の場合は、イベントを行いたくなるようにネタを提供したり、会場の手配などを手伝います。普段の業務に忙殺されていると、ついついイベント実施が面倒になってしまいます。あまり間を空けないように、定期的に開催されるように促していくのがコミュニティマネージャーの腕の見せどころでしょう。
マーケティング担当者
DevRelはマーケティング活動なので、マーケティング担当者の存在は欠かせません。エバンジェリストやアドボケイトが自分の成果まできちんと数値化して追いかけるのは時間、労力的に難しいでしょう。そこでマーケティング担当者が成果を計測できる仕組みを作り、イベント告知やメールマガジン発行などでサポートすることになります。
マーケティング経験のないエバンジェリストやアドボケイトが考えるマーケティング活動は、定量的な目標よりも定性的なものに重きが置かれがちです。EXPOなどで名刺を集めたり、メーリングリストの送信先を集める、効果的なLP(ランディングページ)を設置するといった活動はマーケティング担当者の方が得意分野になるでしょう。
編集長
自社ブログやオウンドメディアなどコンテンツマーケティングを行うのであれば、そのコンテンツ品質を守る編集長の存在が必要です。編集長がコンテンツの方針を決め、書き手を探します。アイディアを出したり、上がってきた原稿の校正、公開タイミングの設定を行います。
自社ブログを継続する上で、編集体制はとても大切です。エンジニアが自由に、どんどん発信してくれる文化はそうそう簡単に作れるものではありません。編集長自ら動き、エンジニアに働きかけることでようやく発信してくれるのが一般的です。
さくらインターネットの例「さくらのナレッジ」
また、エンジニアの書いてくれた原稿を編集して読みやすい形に整えるのも大事な役割です。第三者の目線で読むことで、誰が読んでも分かりやすい文章に仕上げなければなりません。前提知識の漏れがあったり、用語の解説や対象読者層に合わせた文章構成など、編集は大事な機能になります。
カスタマーサクセス
サブスクリプション型モデルにおいて注目されている職種がカスタマーサクセスです。開発者のサポートであったり、その進捗の管理、プロダクトになったときの事例インタビューなどを手がけます。特にサポートから事例までの流れが大事で、待ちのサポートではなく積極的な姿勢が臨まれるでしょう。
エバンジェリストやアドボケイトがどちらかというとプリセールス(認知度向上や製品選定に関わる)なのに対して、カスタマーサクセスはポストセールス(利用開始後)に関わります。利用企業のビジネスを伸ばす手伝いをしながら、より自社のサービスを利用してもらえるように促します。複数のプロダクトがある場合にはクロスセル、利用量を増やす施策はアップセルと呼ばれます。
カスタマーサクセスが相対するのは自社サービス利用の多い企業、または今後多くの利用が見込まれる企業になります。そのため、顧客のビジネス理解やコミュニケーションスキルが求められます。
サポート
サポートもDevRelにおいて重要な存在です。最近ではカスタマーサクセスと同義で扱われることが多いですが、サポートは大量に寄せられる質問を適切に素早く返答することが求められます。多くの企業ではサポートレベルに段階が設けられており、顧客のステータスによって対応期限が決まっています。
テンプレートなどで効率化を求められることが多いですが、あまり一辺倒なな対応は開発者を失望させてしまうでしょう。
サポート窓口としては、チャットやフォーラムを利用することが多いです。TeratailやStack overflowといった開発者向けに特化したQ&Aサービスを利用したサポートを提供することもあります。こうした外部に公開されたQ&A上でのサポートは検索エンジンにインデックス化されるので、同一の質問に対するセルフサポートでも役立ちます。
質問に対するサポートの速さは開発者体験に大きく関わります。開発者は課題を抱えており、それが解決するまで次のステップには進めません。長期間課題が解決しなければ、他社製品への乗り換えを検討してしまうことでしょう。早期に解決できれば、開発者の離脱を防ぐのはもちろん、ロイヤリティーを向上させる効果も期待できます。
人事担当者
ここ数年、エンジニア不足という言葉がよく聞かれます。それもあって、各企業がエンジニア確保に奔走する中、カンファレンスなどのスポンサーに人事予算が使われています。実際、筆者が運営に関わるカンファレンスなどで、人材獲得目的でスポンサーしてくれる企業は多いです。
そのため、人事担当者もDevRelに関わっていると考えるべきでしょう。ブース出展などを通じて開発者とのつながりを形成しています。自社や自社サービスを知ってもらいつつも、あまり宣伝色を強めると避けられてしまいます。良い塩梅で開発者とコミュニケーションすることで、彼らの興味を引けるはずです。
カンファレンスブースの様子
そうした会話の中では技術的な話につながることもあるでしょう。その場合に備えて、開発者の話す技術用語を学んでおいたり、自社テクノロジーについて知識を蓄えておくのは大切です。もちろん自社にエバンジェリストやアドボケイトがいれば、一緒にブースに入ってもらうのも良いでしょう。
ソリューションアーキテクト
ソリューションアーキテクトと呼ばれる通り、顧客と相対して彼らをサポートする存在と言えます。CxO(Chief x Officer)と呼ばれる経営層と話したり、営業担当者と同行して顧客の課題を解決します。AWSではAWS認定ソリューションアーキテクト-アソシエイトという資格制度を設けて、この資格を取得した人をソリューションアーキテクトとして認定しています。
ソリューションアーキテクトでは技術的なスキルはもちろんのこと、顧客ビジネスの理解というスキルが大きく求められます。ビジネス理解に必要なものとして、コミュニケーションスキルも必要です。
企業によってはテクニカルアーキテクトと呼ばれることもあります。
CMO(Chief Marketing Officer)
マーケティング部門の取締役であるCMOは、DevRelに限らず企業のマーケティング戦略全般を担う存在です。CMOがDevRelを理解している、少なくとも開発者が重要なステークホルダーだと認識しているかどうかはDevRel活動に大きな影響を及ぼします。
DevRel活動の継続可否はトップダウンで決まることがほとんどです。そのため、DevRelで重視されるリレーションシップや認知度向上という点を理解してくれるマーケティング部門でないと、継続が困難になります。
日本企業においてはマーケティング＝4大メディアへの予算配分という場合がまだまだ多かったり、広報＝宣伝発信のみと言うケースも多いのが実情です。そうした企業ではDevRel活動は難しいかも知れません。
CTO(Chief Technical Officer)
DevRelチームが開発部に所属している場合はCTO管理下になるでしょう。この場合、マーケティングへの理解度が大きな鍵になります。マーケティングを知らない、技術しか分からないエンジニア上がりのCTOだとDevRelが不幸になります。
最近では社内エンジニアの情報発信(ブログや登壇など)に力を入れているCTOが増えています。そうした点において、DevRelとまではいかなくとも発信活動をサポートしてくれるケースは多いのではないでしょうか。
おわりに
今回は、DevRelに関わる主な職種について取り上げました。一貫して言えるのは、まず自社や自社サービスに対する理解が必須ということです。その上で、職種に合わせた知識が必要になります。
また、多くの職種において開発者と相対する機会が多くなります。開発者と会話ができるよう、技術用語や技術トレンドを学んでおくことをお勧めします。それが相手の理解にもつながるはずです。
