エンジニアへのマーケティング活動（DevRel）について

3 May, 2021

マーケティング

ヘッドレスCMSは従来のCMSとは異なり、フロントエンドの実装が必須となる。
そのため、microCMSのファーストタッチのターゲットはエンジニアだ。（実務として管理画面を操作するのは非エンジニアである）

前回記事にもしたが、セールス / マーケティング観点でいろいろと悩み抜いた末、結局はエンジニア目線に立ち返ろうという結論に辿り着いた。
薄々勘づいていてはいたが、対エンジニアのマーケティングにおいては従来のSaaSの王道は通用しないということが分かってきた。
書籍「DevRel エンジニアフレンドリーになるための3C」では次のように述べられている。

開発者をターゲットに従来のマーケティングと同じ手法を適用すると、おそらく失敗します。開発者は分析能力が高く、技術に忠実であり、またデータ主導で非常に忙しい人たちです。彼らにとっては、押し付けタイプの過大広告や流行語に満ちた広告よりも、誰かが実際に試してみてどうなったのかという体験談や開発者同士の口コミのほうが説得力があるのです。

そもそも国産プロダクトでエンジニアをターゲットにするものは少ないため、参考になりそうな企業が国内にあまりいない。
toCのメディア寄りやプログラミングスクール系であれば多く存在するが、特にツールやアプリケーションとなるとほとんどない。
その理由は端的に言うと、海外プロダクトに淘汰されてしまっているからである。
日本人のプログラミング能力は別に世界でも戦えるレベルだと思っていて、どちらかと言うと資本力で負けてしまうケースが多い。
海外のスタートアップへの投資額は日本の約10倍。地価的な話もあるが、それでも日本の数倍の人数相手に勝つのは難しい。

一方でなぜmicroCMSはエンジニア向けサービスなのに国産でここまでやれてきたかというと、実際にコンテンツを入稿するユーザーは非エンジニアだからである。
基本的に日本人は英語への耐性がないので、管理画面が英語のサービスはなかなか導入しづらい。
ヘッドレスCMSは海外で爆発的に伸びていて、今や数えきれないくらいサービスがあるが、日本においては最大手の Contentfulにも負けていない。

DevRelとは

エンジニアのマーケティング活動としてDevRelという単語がある。
Developer Relations（デベロッパーリレーションズ）の略で、外部の開発者とのつながりを形成し自社製品／サービスを知ってもらうためのマーケティング活動を指す。
ざっくり下記のような活動を行う。

自分たちが開発者に伝えたい技術情報を提供しながら、製品の認知度向上と採用を促進する
開発者のニーズを理解することでそれに基づいた新たな提案をする
開発者からの率直なフィードバックに基づいて、開発者体験や製品の改善につなげる

DevRelにおいては、ユーザー（開発者）を巻き込んだ形でのマーケティング活動が肝となる。
プロダクトのファンを増やし、ユーザー自ら薦めたくなるような仕組みづくりをしていく。

microCMSでは特にDevRelを意識しているわけではなかったが、自然とユーザーを巻き込む形でここまで成長してきている気がする。

DevRelの3C

DevRelを成功させるための3つの要素（3C）がある。

Code
Contents
Community

ここでいう Code / Contents に関してはmicroCMSはある程度着手できている。
Communityだけ手付かずという状態。
前々からコミュニティを作ろうかという話は何度も上がっているが、おそらく想像以上に工数がかかるであろうというのと、上手く回すのが難しそうというところで踏み切れていない。
もう少しメンバーが増えてきて、コミュニティに永続的に付きっきりになれる人が出てきたタイミングで始めるとかが現実的な話か。
そもそもコミュニティを作ることによって、お役立ち情報などが閉じた環境で共有されてしまうのは避けたいというのもある。
なので、作るにしてもオープンな方向性のコミュニティを模索していきたい。

コミュニティの自走化というのは、DevRelを展開するベンダー側の担当者（コミュニティマネージャーやエバンジェリストなど）がオフラインの場に参加しなくても、勉強会やミートアップがコミュニティ側のメンバーによって自主的に開催される状態を指します。

書籍内にあった上記のような状態が一番素晴らしい形に思える。
実はmicroCMSも非公式でのワークショップがいくつか開かれているようなので、良い傾向な気がする。（今のところ敢えてあまり関与していない）

勉強会やミートアップは自分は結構好きで、以前はよく参加していた。
こういったイベントも企画していきたいが、やはり難しいのは継続性だと思う。
前職でもWebフロントエンドイベントの開催などに関わっていたが、どうしても年単位で継続していくのは大変だと身を持って感じた。

イベントの開催には、その目的を事前にハッキリさせておくことが重要だと思う。
採用なのか、サービス認知UPなのか、つながり作りなのか、その辺りがフワッとしていると続ける意味が分からなくなってしまい、主要メンバーが忙しくなったりしたタイミングで終わってしまう。
イベントを主催する場合はその辺りをちゃんと考えようと思う。

AARRR

AARRRモデルは近年インターネットのビジネスにおける顧客分析の分解モデルとして使われている。以下の5つ頭文字をとっている。

Acquisition（誘導）
Activation（活性化）
Retention（継続）
Referral（紹介）
Revenue（収益）

これはいわゆるファネルの形になっていて、下に進めば進むほど対象人数は減っていく。
この各段階ごとにDevRelマーケティング施策がある。
一番最初の入り口のAcquisitionにおいては図の通りである（書籍より）。

この一覧を見るとまだまだやれていないことは多い。
動画系はぼちぼち始めていく予定だ。
ノベルティなんかもやってみたいが、コロナ禍においてはあまり効果が得られないだろう。早く終息してほしい。
コミュニティも状況が整ったら・・・。

AARRRとはまた異なるが、アカウント登録から実際に有料課金されるまでの割合が最近は安定してきており、やっと式を立てられる段階まで来た。
あとは母数を増やすことと、割合を高めていくことに注力していけば良いと思っている。

先日、microCMSブログをOSS化したが、反響はかなり大きかった。
なんとGitHubスターは200超えである。
Real WorldでのJamstack構成ということで、Web制作界隈の方々の参考になれば嬉しい。
この施策ができるのはヘッドレスCMS運営母体のみであろう。（通常、自社ブログのソースコードを公開しても何のメリットもない）

こんな感じでエンジニアならではの施策を今後もいろいろと模索していきたい。

まとめ

結局のところ、エンジニアが信じるのはやはり「技術」だ。
広告や営業はあまりマッチしない。
家電なんかでも事細かに製品を比較して購入する方も多いと思うので、営業側からしたら厄介な存在だろう。
が、それはある意味健全でもある。

１. 興味を持ってもらう
２. 実際に触ってもらう
３. 良いと思ってもらう
４. 周りにシェアしてもらう

という正のループを回していくことが一番の近道だと思う。