DevRelは企業の事業活動の一環として行われます。この点がコミュニティやオープンソース・ソフトウェアの開発とは異なります。そして活動範囲は大きく分けて3つに分類されると考えられます。

1. 認知獲得から利用開始まで
2. 利用開始から促進
3. 求人、広告費用の低減

認知獲得から利用開始まで

DevRelが得意とする範囲として、認知度の獲得が挙げられます。マーケティングのAARRRモデルで言う最初のAAであるAcquisition（新規ユーザー獲得）とActivation（利用開始）に相当する部分です。DevRel版AARRRモデルであるAAARRRPモデルに当てはめると最初のA（Awareness：認知する）も含まれます。ハッカソンや登壇、セミナーなどを通じてまず知ってもらう、体験してもらう、ユーザ登録してもらうまでのフェーズになります。

知ってもらうのがなぜ大事かというと、知らないとそのユーザは他社の類似サービスを利用するからです。開発者の数は有限であり、一つのサービスを採用したら別なサービスを選択しないでしょう。あえてプロジェクトの中でRuby on RailsとDjangoとLaravelを組み合わせたりしないでしょう。特に開発者向けのサービスはプロジェクトの中に組み込まれると、よほどのことがない限り載せ替えをしません。あるサービスにとっての1ユーザ獲得は、他のサービスにとっての-1なのです。

知ってもらった上で選ばれないとしたら、それはサービス側の問題です。機能や価格、ドキュメント、UIなどが問題なのかも知れません。それはそれで大きな問題ですが、まず知らないと選定の土俵にすら上げてもらえません。その状態を避けるべきです。

利用開始から促進

利用開始から別なフェーズがはじまります。ここは主にサポートやカスタマーサクセスの分野になります。また、ドキュメントや管理画面の使い勝手なども大きな要素になります。使い始めてから何か違うと感じて離れてしまうと、実は知らない時以上に大きなマイナスにつながる可能性があります。つまり一旦失望してしまった、ネガティブな印象をぬぐい去るのは大変だからです。顧客との関係性で言えば、マイナスになってしまった状態です。知ってもらうからには良い印象を持ち続けてもらう必要があります。

困った、と感じてしまう状態にならないのがベストです。しかし、すべてのユースケースを全方位的に予期するのは不可能です。そのため、困った状態になるのは当たり前だと考えるべきです。その上で困った状態からいかに素早く、軽やかに解決に導けるかが大きな課題になります。それは画面のエラーメッセージで、セルフサポートできる仕組みかも知れません。困った時にWeb検索して解決できるようにコンテンツを用意することかも知れません。さらにQ&Aフォーラムやメール、電話でのサポートかも知れません。

利用が進むと課金のフェーズになります。利用量や機能によって課金される場合、この最初の課金が大きな壁になります。1円と500円に大きな差はありませんが、0円と1円には非常に大きな壁があります。特にデジタルの世界においては費用が目に見えづらく、課金を嫌がる声が強いのは間違いありません。この課金部分はDevRelよりもビジネスモデルが大きく関わることでしょう。

一旦課金されたユーザにおいては、カスタマーサクセスによる手厚いサポートが提供されます。アップセル（さらなる高機能版への移行）とクロスセル（別な製品と組み合わせる）が主な手段になります。企業がサービスを利用する場合、それが彼らのビジネスを拡大させたり、費用を低減するのに利用されます。そこでアップセル・クロスセルを通じてさらなる利益拡大、費用減少が狙えるならば、課金を拡大するのを躊躇する理由はないでしょう。

このフェーズで起きる問題は課金額の低減です。つまり他社サービスに流れたり、顧客のサービスが縮小している場合に起こります。この点をフォローアップできるのもカスタマーサクセスの責任範囲になるでしょう。

求人、広告費用の低減

DevRelによる認知度拡大と、顧客満足度向上による紹介（リファラル）が増えると、新規獲得コストや宣伝コストが下がります。DevRelにおいては広告は信用度を下げていますので、利用者自身の声とエバンジェリスト・アドボケイトによる開発者目線の声の方が届きやすくなります。DevRelに取り組む人事部の活動も同様です。企業の知名度が上がれば、より良い人材が獲得しやすくなるでしょう。

DevRelで自社製品の売り上げ拡大を狙う一方で、認知度や信頼性を上げることで費用の減少を狙うのも大きな目的になります。

その他

その他のDevRelによるメリットとしては、利用者からのフィードバックを得るという点があります。これはマーケティングで言うところのプロダクトマーケットフィット（PMF）になります。ユーザの声を聞くことで、彼らに必要なものを開発できます。余計な機能の開発に工数を割かれることなく、市場にフィットした製品を作り続けることが企業としての生き残り戦略につながるでしょう。

実現する戦術について

こうしたDevRelの戦略を進めるための戦術として次のようなものが考えられます。

• ドキュメント整備
• コンテンツマーケティング
• ハンズオン
• ハッカソン
• コミュニティマーケティング
• コンテスト
• 動画
• SDK/ライブラリ
• メールマガジン
• eBook
• その他いろいろ

この辺りはサービスの特性、費用に合わせて考えるべきでしょう。

まとめ

DevRelの戦略はそれほど複雑ではありません。やること（戦術）が多すぎて複雑に見えてしまいますが、企業（または製品）メリットから考えれば良いだけです。ぜひ皆さんのすべき、できる点を模索してください。

MOONGIFTではDevRelのアウトソーシングを提供しています。DevRelに取り組みたいが、アイディアも人員も不足している…そんな場合はぜひお問い合わせください。コンサルティングも可能です！