はじめに
最近は外資系ITベンダー(プラットフォーム、サービス、ツールなど)の日本法人で、DevRel関連職の採用が目立ってきています。では、日系企業でこれらの職の採用があまり見られないのはなぜでしょうか？
DevRelというアプローチを取る戦略は、かんたんに説明すると「ベンダーとユーザー(開発者)の間に技術力を以て信頼関係を築くこと」であると言えます。その先に、ブランドの確立やファンの増加、コミュニティマーケティングによるSell through the Communityが見えてきます。
つまり、開発者が使うためのAPIや、開発・運用するためのプラットフォームやツールを提供している会社でないと、DevRelというアプローチを取る意味があまりありません。
いや、ごく一部のSIerではデベロッパー・アドボケイトやテクニカル・エバンジェリストを置いている事実を知っています。彼らは、SIerとして担いでいるプラットフォームやツールのエバンジェリストとして活動しているケースが多いようです。
いずれにしても、DevRel関連職を配置する企業の特徴がなんとなく見えてきたと思います。今回のブログでは、このDevRel関連職をこれから自社に設けようと考えている方をはじめ、「DevRel関連職はどの部門に所属させるのが良いのか？」に興味を持っている方向けに一緒に考察してみようと書いてみたものになります。
DevRel関連職を一旦定義する
DevRel関連職と一口に言っても、実は色々なRoleが存在します。以下に代表的なものを列挙します。これらは、会社によっては、それぞれが独立したRoleの場合もありますし、一つのRoleで複数の役割を兼ねている場合もあります。一つの参考として見てください。
テクニカル/テクノロジー・エバンジェリスト
今ではエバンジェリストという役職名も結構知られてきたのではないでしょうか。その名の通り伝道師、つまり自社のサービスやプラットフォームを世に広めていく役割です。特にテクニカル・エバンジェリストは、自身のデベロッパーとしての技術力を活かしたエバンジェリスト活動を展開します。
デベロッパー・アドボケイト
いつの間にか、エバンジェリストという名称よりもアドボケイトという名称のほうが、DevRel系の求人では目にすることが多くなりました。テクニカル・エバンジェリストとデベロッパー・アドボケイトの違いについては、人や会社によって定義が異なっているので、ここでは一つの参考説明として「テクニカル・エバンジェリストの役割に加え、開発者の声をHQへフィードバックする」役割の人としておきます。
テクニカルコンテンツ・クリエイター/ライター/Webサイト編集長
DevRelでは、開発者向けに色々なコンテンツを作成し提供していきます。また、そういったコンテンツを開発者向けWebサイトなどで公開していきます。このあたりを対応するのがテクニカルコンテンツを作成する担当や、そのコンテンツを管理し公開するWebサイトの編集長だったりします。
コンテンツ作成などはエバンジェリストやアドボケイトが行うケースも多いですが、Webサイト管理はだいたいにおいて専任がいるでしょう。（なお筆者はすべて兼務してたことがありますｗ）
コミュニティ・マネージャー
DevRelに力を入れる企業には、その企業が提供するプラットフォームやサービスのユーザーコミュニティを活性化させる施策を打っていることが多いです。特にグローバル展開している企業であれば、各ローカルに根付いたユーザーコミュニティ（開発者コミュニティ）を成長させるために、このコミュニティ・マネージャーという役割で人を置くことでしょう。
場合によっては、MVPやChampion、Ambassadorプログラムのような、外部アドボカシープログラムを担当することもあります。
プログラム・マネージャー
テクニカル・エバンジェリストやデベロッパー・アドボケイトが色々なデベロッパー系イベントで登壇したり、ハンズオンワークショップを実施したり、ハッカソンをサポートしたりするにあたって、年間通してどのイベントにどのように参加するか、また自社のオウンイベントとしてどのような企画を進めるか、などDeveloper Relationsに関連するプログラム（≒ イベント）を企画、管理する立場です。
表舞台に出ることは少ないですが、DevRelを推進する上で重要な役割です。
想定しうる所属部門
さて、そんなDevRel関連Roleがたくさんあるわけですが、実際のところこれらの人たちはどの部門に属するのが良いのでしょう？
また、すでにDevRelを推進している会社では、これらの人たちはどこの部門に所属しているのでしょう？
筆者の経験上、主に以下がDevRel関連職の人が所属しうる部門だと思います。
営業部門：主に売上や利益、 案件数や顧客数などの数字を目標に置く部門です。顧客に対しては企業のフロントマンとも言えるでしょう。
マーケティング部門：企業の広報、ブランド、ソーシャルメディア、フィールドマーケティング、チャネルマーケティング、プリやポストでの営業支援、イベント関連など、幅広く活動します。
R&D部門：その企業が取り組む製品や技術に対して、研究開発を担う部門です。通常はあまり表舞台に出ることはありませんが、研究成果の発表などで大きなイベントに立つこともあります。
コーポレート部門：バックオフィスを担う部門です。総務、経理、人事、経営企画、などありますが、特に最近DevRelに絡んでくるのは人事部門です。
※ 広義ではマーケティング（特に広報）もコーポレート部門とみなす会社もあるようです。
良い点と悪い点
ここでは、各部門にDevRel系のチームを配置した際の良い点と悪い点を考察したいと思います。
営業部門
Pros：プリ、ポスト含め既存ユーザー、ポテンシャルユーザーへのリーチが容易。営業目的としてバジェットの確保が比較的容易。
Cons：部門として数字責任が課せられることがほとんどなので、短期的(長くても1年以内)な成果を求められる。DevRelは長期的な戦略なので相性が良くない。
マーケティング部門
Pros：Newアカウントに向けての活動がやりやすい。オウンドメディアやオウンドイベントの企画運営はたいていマーケが担当してるので、DevRel活動とSyncさせやすい。
Cons：KPIにリードの取得を求められることが多く、開発者向けイベント（特にコミュニティリーチの活動）との相性が良くない。また、こちらも短期的な成果を求められがち。
R&D部門
Pros：研究開発系のプロジェクトは長期的なものもあるため、DevRel活動の時間軸に近い場合がある。将来へ向けての投資の意味でのコストセンターなので、DevRelのアプローチと相性が良い。
Cons：そうは言っても研究開発が主たる業務であり、DevRel一本槍の活動をR&Dとして企業が認めるケースは比較的少ないかも。
コーポレート部門
Pros：こちらも間接部門という性質上、コストセンターとして活動はしやすい。また、経営層に近い部門という側面もあるので、DevRel活動を会社に認知させやすいかも。
Cons：現状コーポレート部門でDevRelに絡んでくるのは人事くらいなので、極めて範囲の狭いDevRelアプローチになってしまう。最初から採用目的のDevRelということであればアリかも。
まとめ
今回の内容は、筆者が7年間、3社でDevRel関連職を経験してきた中での体験談から書いています。どの会社にも言えることとして、会社本体がDevRelの重要性をどこまで理解しているかが肝です。
DevRelは種まきです。まだ畑は耕されてすらいないかもしれません。そんな中に、乱暴に種を蒔いて短期間で芽が出てくるのを期待されても困ってしまいますね。畑を耕し(市場開拓)、正しい場所に種を蒔き(ポテンシャルユーザーへのリーチ)、然るべきステップで育て上げて(イベント実施、コミュニティの育成)、ようやく芽が出ます(プロダクト、サービスへの興味)。そこから花を咲かせる(ユーザーになる)まで導いて、枯れないようにケアをする(チャーンの防止)、そんな一連の流れを技術力を以てリードしていくのがDevRel関連職の仕事です。
どの部門も、DevRelを実施するに適してるかと問われれば、一長一短だと言えるでしょう。それは、まだまだDevRel関連職がチームとして、部門として確立できてないということなのかもしれません。
参考になるであろう、グローバル企業のDevRelパーソン達との情報交換も時に非常に有効であると思います。
是非、DevRel Meetup in Tokyoへ参加して、たくさんのDevRelパーソンと話をしてみてはいかがでしょうか！
それでは！
