【イベントメモ】今こそマーケティング視点を！ DevRelがもつ可能性を探る。〜DevRel/Japan CONFERENCE 2022から
2022年８月５日（金）〜６（土）にDevRel/Japan CONFERENCE 2022がオンライン／オフライン並行で開催されました。昨年もコミュニティやマーケティングに関する多くの知見をを与えていただいたこのイベント。今年もまた個人的に気になったセッションについて紹介してみたいと思います。
＜カンファレンスの動画です＞
パネラー紹介
小島 英揮さん
・パラレルパートナー,Still Day One合同会社 代表社員
・JAWSの立ち上げ、JP_Stripeの支援
・書籍「コミュニティマーケティング」「DevRel エンジニアフレンドリーになるための3C」
ぎょりさん
・Autifyのマーケティングディレクター
・クラウドインテグレーター、ベンチャーを経て３社目
・小島さんとはJAWS立ち上げ時代から
佐々木 大樹さん
・富士通クラウドテクノロジーズでマーケティング／社内コミュニケーションを担当
・株式会社MOONGIFT様に協力をもらってDevRelを推進
山崎 亘さん
・株式会社ウフルでenebulerのプロダクトマーケティング
・元ORACLE
・SONOSのユーザーグループ運営
Q1:皆さんはDevRel専任or兼任
・専任はゼロ
DevRelとは？
DEvRelは外部の開発者との相互コミュニケーションを通して、自社や自社製品と開発者との関係性を築くためのマーケティング手法
・本当は「✕✕✕をするために」良好な関係を築く
今日お話したい事
・ホントに「良好な関係」構築だけで良い？
・ビジネスに寄与する「良好な関係」とは？
・社内外ステークホルダーとどう連携スべきか？
OWWHを意識して、社内外のステークホルダーから「イイね！」を得られるDevRelの実行方法
Q2:みなさんが実務でDevRelに期待していることは？
山崎さん：まず使ってもらって、アウトプット（ブログ）を出してもらうこと。使い勝手や機能についてのフィードバック。
アウトプットしていただくために良好な関係を築く
佐々木さん：ゆくゆくは開発者のコミュニティを作れれば嬉しい。今のステージとしてはとにかく触れてもらう。初めてコードを書くというレベルの人が触れやすいコンテンツを提供したい。製品の正しい期待値を持ってもらう
ぎょりさん：まず使ってるユーザーがより活用してもらい開発プロセスが改善していくこと。プロダクトへのフィードバックはめちゃくちゃ大事。フィードバックの広さ深さが継続される状態にすること。関わる役割による幅広さは大事。
＜マーケティングとは？＞
ターゲットに行動変容を促すあらゆる活動
Objective:（目的達成のために）
Who（誰に）
What（何を）
How（どう伝えるか）
・・・Objectiveなくして勝利なし
DevRelをやっていて自分の中でゴールの近道を考えますか？
山崎さん：最終的には使える人が増えてビジネスにつながるということでなのですが、どっちの道を進めばそっちのゴールに近づくのか？日々変えている感じになりますよね。
・・・・Objectが変わるとやり方も変えていく
マーケのObjectiveしか見ていないケースになりがち、会社のObjectiveとの整合が出来ていないとDevRelが評価されない。
「技術者との良好な関係」はマーケティングの目標と連動しなければならない。技術者の中の「誰」を明確にする
Ｑ３.マーケターだからこそDevRelで苦労した点は
小島さん：参加者の中から技術的な話をしてほしいと思うが、ニーズには「メーカーとしてどうなの」を聞きたい声もある。技術的な情報のニーズには技術的内容（例えばコードそのもの）で答える。
佐々木さん：セミナーやユーザーコミュニティなど色々あるわけですが、求められるのは製品の使い方だけでなく「困っていることの解決」なのでけっこう広く知らないといけない。入ってくる技術トレンドを見通す力も判断に求められる。
ぎょりさん：幅広く知識がないと伝えられないというのはあります。その時に使う言葉にも気をつけないといけません。マーケターとしてはわかりやすく伝えていく事と正しく伝えていく事の間を取らないといけない。「こういった課題を解決できますよ」まで消化したメッセージにしていきたい。
測定可能な状態にするという難しさはありつつ、時間軸と量を一緒に見に行くようにしています。定量的に図るすべを模索中。
小島さん：テクニカルなお客様に接するときには社内のいろんなリソースの協力をもらったりするのですか？
ぎょりさん：エンジニアもそうですがサポートを行っているメンバーもいます。
山崎さん：前職は大きな会社だったのでDevRelに手が出せす壁があったので、フラストレーションも溜まっていた。演じなのコミュニティでも「別にマーケターはいらない」と言われりもした。
今の会社は小さいので全体の流れがわかるようになったし、IoTにシフトするという方針なかでも、会社の中のエンジニアだけでなく市民開発者にも方向を変えているようになった。ベースとなるのはコミュニティの協力があるのですが、製品を作っているメンバーをつれてきて混ざることが出来ている。何でもかんでもわかっている人は居ないので、色んな人を集めてきてまとめるのがうまく言ったときは嬉しいですね。
小島さん：お客さんが困って居ることを解決するためには技術のこと、製品のこと、マーケティングのこともわかっていないといけない。だからマーケが関わる必要があるのかなぁと思います。
エンジニアの誤解の話はありましたが、マーケターは「これやったらいくらになるの？」とは言いません。お客様の信頼を得て、フィードバックループを作って、正しく理解してもらうのが最終的にやりたいことです。
Q4:DevRelは、次のステージのどこに聞くと考えている？
「顧客獲得」「顧客育成」「顧客理解」
佐々木さん：顧客獲得にフォーカスしていますが、いがいに顧客育成に効いている。ユーザー同士の課題対応の情報交換など。
山崎さん：獲得に一番力を入れていますが、一番嬉しいのは製品理解で製品に対してフィードバックしてインプリメントできたときです。
ぎょりさん：プロダクトのフェーズにより異なってきますが、今のAutifyについては顧客理解が一番大きいかなと思います。理解が深まれば獲得や育成に起用していくと思っています。
小島さん：かつてマーケは顧客獲得が主眼でしたが、顧客育成を経ていまは顧客理解に重点が置かれるようになってきた。「ドリルと穴」の話や「HEINTZの逆さボトル」の話など
・・・・フィードバックループの構築が鍵
視聴者からの質問
Ｑ：開発者に響いたかどうかをどうやって効果測定している？
山崎さん：コンテンツであればQiitaへの投稿などのコンテンツ、機能であればソーシャルメディアやブログの話題を見ています。
小島さん：SNSの投稿だけでなく「やってみました」のようなアクションに繋がったかどうかですね
佐々木さん：記事の流通とかはよく見ます。QiitaとかZennとか、個人がターゲットの製品なのでTwitterなどはよく見ます。イベントの参加人数も見ています。ユーザーコミュニティをGithubのリポジトリを立ててやっているのですがGithubは寄与数が見えるのでそれをトラッキングしています
ぎょりさん：プロダクトの機能レベルで使われているかをウォッチしています。顧客セグメント別や利用年数別に見ています。正解はないので色々な視点で見ています。
最終的にはＬＴＢで見ていくのですがＬＴＢはいち活動と繋げづらいので難しいなぁと思います。
山崎さん：View数もベースとしては見ます。
小島さん：数と状態をみると反応を追いやすいと思います。
まとめ&ひとこと
DevRelはマーケティングの活動そのもの
マーケターとしてのOwwhの視点を共有してもらえるとDevRelと連動できるし、動いてほしいと思っている人が動いてくれているか、その人が響くコンテンツかどうかも見やすくなる
社内外に対していい状況が作れる
マーケターもDevRel的な視点を持たないといけない
決して違う部門ではない
ぎょりさん：ぜひ、Twitterで「Devrelマーケ仲良し」とTweetしてください。マーケはプロダクトをどう良くしていくかを考えていますし、頼っていただいて共創出来るといいなと思っています。マーケをきらいにならないでください
佐々木さん：お三方の話はボク個人には勉強になった。ありがとうございました。
山崎さん：我々のオブジェクティブは我々の製品を使ってユーザーの皆さんがハちおれッピーになることかなぁと思っています。そのためにはマーケターとかDevRelとか開発メンバーが手段を問わずにやれることがいっぱいあるのでオブジェクティブのために仲良くやれたらと思います。
感想
マーケとDevRelの関係の話はあまり接したことがないので興味津々でした。（そんな対立があったとは・・・）コミュニティに参加する側の視点で見ても非常に勉強になりました・・・・というか楽しく聞けました。オブジェクティブの話はマーケターとDevRelの間だけではなく、開発者とユーザーなどいろんなことに大切な要素だと感じました。
相変わらず小島さんの仕切りは美しいです。
ありがとうございました
この記事が気に入ったらサポートをしてみませんか？