「DevRel エンジニアフレンドリーになるための3C」の1章〜3章まで読んだ
- 作成
- 2020-03-03
「DevRel」という言葉自体を聞いたことがなく、気になって購入しました。
DevRelをざっくりと説明すると、「商品のPR」と使われるようなPR「Public Relations」の「開発者版」と捉えると分かりやすく、企業やサービスと開発者（Developer）を繋ぐ役割のことです。
商品を消費者や企業に向けてプッシュするのであれば、マーケティングや営業を通して宣伝し、製品を購入して使ってもらうことが前提になりますが、本書は開発者に特化した形になっています。
前半のまとめと感想
第1章 今なぜ、開発者向け共創マーケティングなのか
序章のような前置きから。
AppleやGoogleなどの海外IT企業は、顧客からのフィードバックはもちろん、社外の開発者も巻き込んでイノベーションを起こしている様子を伝えています。なぜ敢えて開発者なのか、それは開発者が昔と比べてビジネスを変えるレベルまでの影響力を持つようになってきたため。そして外部の開発者と関係値を深めることでビジネス課題の解決策やアイディアを一緒に模索しようとしている企業も増えていること述べています。
第2章 Developer Relations（DevRel）とは
DevRelの概要と戦略策定の話。DevRelとは「企業と開発を繋ぐ役割」と定義し、アウトバウンド寄りの「エヴァンジェリスト」との違いはインバウンド・アウトバウンドの両方を担って、開発者に寄り添いながら製品やサービスの活用方法を共に作る役割を果たすとしています。
さらにその定義の上で、3章以降に続くコード・コンテンツ・コミュニティの3Cにアプローチする以前の全体戦略として、計画書の書き方や認識合わせとしてのディベロッパージャーニーマップの作り方の紹介してます。ディベロッパーマップとは、UXのくだりでよく一緒に語られるカスタマージャーニーマップを開発者にフォーカスしたジャーニーマップでした。違いというと、カスタマージャニーマップでは「レディネス」という概念があります。これは製品に対する学習者の状態のことを指しています。
エンジニアが対象者なのかなというほど計画書やジャーニーマップの作り方が手厚く解説されていて、私にとっては何度も聞いたような話でした。しかしレディネスといった考え方は新鮮です。対象のサービスを知らない段階から、コミッターになるまでを6段階に分けてレベル分け。カスタマージャーニーマップだとということでしょうが、体験したことがなかったので参考にできそうです。
第3章 Code
少しずつ各論に入っていきます。まずは3Cのうちの一つである「コード」。この「コード」の中にはソースコードだけではなく、チュートリアルやドキュメント、ファーストステップガイドといった純粋なソースコード以外のものも含まれています。これらをどのようにKPIの数字に落とし込んだり、広報施策についても比重を置いて解説しています。
Webマーケティングは曲がりなりに触ってきているので、斬新！って思うところは正直そこまでありませんでしたが、筆者の経験談として書かれているノベルティの配布方法は「なるほど」と思わされるものでした。
ノベルティをばら撒くように配布しても効果が見込めなかったのか、何かの対価としてノベルティを配布していることをしています。具体的にどんな対価としてノベルティを配布しているか引用をすると、
- Twitterで情報拡散してもらう
- サービスやプロダクトなどにユーザーに登録してもらう
- アンケートに答えてもらう
- クイズに答えてもらう
- サービスやプロダクトを体験してもらう
という内容。私もイベントに出歩くのでノベルティをいただきますが、たしかにこういう取り組みをしている企業や団体は少ないように思います。自分がもし採用担当とか展示会でなにかを開発者向けにプッシュすることになったら…？と考えるとこの辺のイメージはつきやすかったです。
後編に続きます。
売り上げランキング: 64,615