DevRel（Developer Relations）は開発者向けにサービスを提供している企業に限らず、開発者を雇用する場合やシステム開発を行っている企業であっても大事な施策になります。開発者との信頼関係は社内外を問わず、重視すべきものでしょう。

そんな中、DevRelに予算を割り当てられないプロダクトがたくさん存在します。理由はなぜかと言えば、費用対効果が分からないという点に尽きるようです。逆に、費用対効果が明確であれば、予算を投じやすいということになるでしょう。

そこで取り入れたいのがマーケティングの考え方です。

マーケティングとは何か

Wikipediaによれば、マーケティングとは「顧客が真に求める商品やサービスを作り、その情報を届け、顧客がその価値を効果的に得られるようにする」ことです。物づくりだけでなく、その情報を顧客に届けて、顧客自身がそれを得られるようにする仕組みです。日本だと売れる仕組みと言ったりします。開発者向けのサービスを提供している場合、広告がほとんど効果的でないというのがよく知られています。インターネットサービスのほとんどが広告によって収益をあげており、日々の仕事の中でインターネットサービスを利用するのに慣れている開発者は広告に触れ続けています。一般的に広告というのはノイズであり、目にしないで済むならばそれに越したことはないと考えられます。テレビ番組を録画した際のCMスキップ機能はまさにそれで、インターネットであれば広告ブロッカーがよく使われています。

顧客にとって良いものを作るのは当然として、その情報を届けるのに広告が相応しくないとします。ではどうやって情報を顧客に届ければ良いのでしょうか。インターネットサービスにおいて、すでに顧客になっている人たちに対して情報を届けるのはさほど難しいものではありません。例えばメールアドレスをすでに知っていたり、Facebookログインによって誰が顧客であるか、簡単に把握できます。これはリアル店舗での販売で、メーカーが誰が買ったのか分からないのに比べるととても優位です。店舗でさえ、会員カードや特典付きクレジットカードなどによって顧客動向を把握しています。メーカーは販売店舗に商品を卸していますので、実際に買った顧客の姿は分からないのです。だから広告はマスマーケットに対してリーチするファーストステップと言えました。

開発者に情報を届ける「デベロッパーボイス」

偶然は3回続くと運命というのは恋愛の話ですが、これはマーケティングにおいても無視できない話です。例えば朝、とある人が書いたAというWebサービスに関するブログを読んだとします。次に昼間、同僚とランチにいったら同じくその人がAの話をしたとします。さらにふと勉強会サイトを見ると、そのAに関する勉強会が行われているのを知ったとします。これはAというWebサービスが流行る前兆なのではないかと思ってしまうのではないでしょうか。

これは何となく分かるような気がしますよね。ネットワークが広がっていく時の仕組みとして知られており、オンラインとオフライン、能動と受動、社内外など複数から情報が届けられることで、情報が正しいと思ってしまうのです。オンラインの情報だけが溢れていても難しく、自分だけで情報を集めていても伝搬しづらいものです。様々な媒体から情報が届いてはじめて、腑に落ちるのです。

サービス運営側からの情報発信というのは一番バイアスがかかっていると感じるものです。その最たるものが広告です。広告は発信側がお金を払って発信しています。お金が嫌いという人は決していないと思いますが、開発者の多くはお金によって自分の考えを左右されるのを好みません。広告はお金の臭いがするので毛嫌いされるのです。逆に最も信頼性が高いとされるのは外部の開発者による、公平な目線での情報発信です。とは言え、ここにも自然な情報バイアスがあり、受け手が無意識下で「これは良いサービスなのだろう」と思って情報を受け取った場合と、「これは悪いサービスなのだろう」と思って受け取った場合で印象は変わってきます。これは致し方ないことなのですが、それでも公式情報が「私たちのサービスは良いものです」と言っているよりは、受け手の心理的バイアスは低くなっているものです。

なぜ第三者の意見は受け入れやすいのでしょうか。例えば自分にとって有益な意見でも、信頼している相手と嫌っている相手とでは受け止め方が異なります。これは人として致し方ないことです。北風と太陽の話と同じで、結果としてコートを脱ぐという行為であっても無理矢理脱がされそうになれば抵抗し、暖かくして周囲の状況が変われば自ら脱ぐものなのです。この時、公式の情報というのは北風になりやすいものです。特に最初は。

公式情報が太陽になれないかと言われれば、そんなことはありません。しかし最初は北風だと思われてしまうものです。自分の考えを改めたり、新しいことに挑戦するのは誰だって二の足を踏んでしまうものです。そこで無理に相手にコートを脱がせるのではなく、太陽になってくれる人たちを創り出せば良いのです。それが第三者たる開発者です。彼らは自分たちの言葉で、新しいWebサービスについて語ってくれます。その言葉は取って付けたような気どったものではないでしょう。もしかしたら運営側の望んだものではないかも知れません。しかし、それが開発者の言葉「デベロッパーボイス」であり、同じ開発者に刺さる言葉なのです。餅は餅屋ではありませんが、開発者に刺さる言葉は開発者にしか語れないのです。

公式の情報が含めるべき12の要素

公式の情報は開発者に届かないとしたら、公式はどういう情報を発信すれば良いのでしょうか。発信しなければ伝わる訳はありません。沈黙は金ではありません。答えは「開発者が語りたくなるような情報」を発信するのです。つまり「デベロッパーボイス」のタネを用意するのです。詳しくは別記事に譲りますが、今回は要素だけ挙げておきます。

1. 自慢（ボースト）
2. 素敵（クール）
3. 共感（エンパシー）
4. 愉快（ハッピー）
5. 自分（マイセルフ）
6. 革命（レボリューション）
7. 秘密（シークレット）
8. 簡単（シンプル）
9. 高速（スピード）
10. 物語（ストーリー）
11. 驚き（サプライズ）
12. 質問（クエスチョン）

これらの要素が散りばめられたメッセージこそ、開発者の心を捉えて、彼らに語ってもらえるのです。