今の時代は製品やサービスが乱立しています。AとBという製品があった時に、何が違うのか説明するのは困難になっています。しかし私たちは自然とAを選んでしまうのです。この自然と選んでしまう行動を起こさせるものこそがDevRelであり、開発者に対するブランディングと言えます。

同じようなサービスがある時代だからこそ、違いはDevRelによって現れてきます。DevRelは開発者コミュニティという無形資産を作り出します。これはおいそれと真似できるものではありません。大きな差別化要因になります。

そしてDevRelによって開発者の本音、現場の問題を聞くことができれば新しいサービス開発に活かすことができます。本当に必要な機能だけを作ることができれば、ムダな開発コストもかけず、彼らに刺さる製品開発ができるようになるでしょう。これもまた、他社との差別化につながります。その結果、他社とは全く違うサービスができあがるでしょう。

DevRelの問題の一つは身を結ぶまでに一定の期間が必要ということです。もしすぐに飛び立てるサービスがあったとすれば、それはサービスの刺さる量が半端ではなかったということでしょう（最近であればSORACOMなど）。そうでないサービスでも継続的に活動を行うことで、徐々にコミュニティが形成できていくはずです。そのためにはまず何よりも続けることが重要です。

また、中の人たちの熱量がDevRelとして外部に伝わりやすいので、何よりも自分たちが使っていて楽しい、役立つサービスでなければなりません。ドッグフードを自分たちで食べているサービスであれば、足りない機能やトレンドに合っていないかどうかもすぐに分かります。自分たちのサービスの一番の使い手であるようにしましょう。そして、そこで培った知見をコミュニティにフィードバックするのです。もちろんそれだけでは利用者と同じ目線でしかありません。さらに使い込み、業界のトレンドを知ることで一歩、二歩先行く存在になっていなければなりません。それが開発者にとっての魅力となるはずです。

コミュニティができたとしても、放置しておいて良いわけではありません。育ち、情報が出るまで慎重に見守る必要があります。さらに声をかけたり、フォローしたりと様々なケアが必要でしょう。コミュニティは開発者の熱意によって形成されるものであり、熱が冷めればあっという間に空中分解してしまいます。そうならないためには作る時と同じくらいの労力が必要でしょう。

DevRelを継続的に行うことによって得られるものとしては、開発者との信頼関係であったり、彼らからのフィードバック、他社との差別化などになります。開発者との絆を強固にすることで他社には模倣できない資産が形成できるはずです。