これまでに挙げてきた施策は次の通りです。

• ドキュメント整備
• ブログ
• ソーシャルメディア
• イベント
• メールマガジン

DevRelのゴールとして開発者とのコミュニティ形成をあげていますので、DevRelの施策としてのコミュニティ作りは大きな意味を持ちます。ただし、コミュニティを作ろうと思ってもうまくいかないケースのが多いのではないでしょうか。コミュニティは言葉の定義も曖昧で、どう作るのがベストであるといった答えがないものなのです。

かといって、何もしないで自然的に発生するものでは決してありません。コミュニティを作りたいと考える人（大抵最初は社内の人でしょう）が「コミュニティを作る！」と手を上げなければはじまらないのです。

コミュニティは純粋、かつ楽しいという感情的な動きで形成され、継続されるものです。そこから何か自社にとってメリットのあるものを得ようとする邪な気持ちはすぐに開発者に伝わってしまうものです。利用してくれている開発者に感謝し続ける気持ちが必要でしょう。

DevRelでは主に企業サービスのサポートになりますので、企業主導で行うコミュニティが多くなります。例外としてはJAWS（Japan AWS）が知られています。しかしJAWSにしても初期段階においてはAWSのエヴァンジェリストが積極的に関わっていましたので、企業が提供するサービスにおいて、全く自然的にコミュニティ主導ではじまるサービスというのは多くないのではないでしょうか。IBMが提供するBluemixのコミュニティ、Bluemix UG（ユーザグループ）はパートナー企業の参加がほとんどのようです。

しかしこれが決して悪いわけではありません。コミュニティとして成り立ち、企業が積極的にバックアップしていくことでユーザ同士のつながりが生まれたり、新しいビジネスの発生につながれば全く問題ないでしょう。また、大事なのはコミュニティがあることでユーザと企業とのつながりが生まれ、愛着を持ってもらえるようになるということです。これは無形資産であり数値化するのは難しいですが、コミュニティがないサービスは利用者とサービスのつながりが希薄になり、飽きたらすぐに使うのを止めてしまったり、忘れてしまう可能性が高くなります。もちろんその結果、他社サービスに移る可能性も高くなるでしょう。マインドシェアを獲得しておくことで、他社の参入障壁になるのです。

コミュニティについては自社の冠をつけて行うこともできますし、自社のサービス領域全体に対するコミュニティとすることもできます。最近であればIoTなどがそうでしょう。自社ブランディングを考えて、冠をつけても誰も見てもらえないと思うならば、技術名を冠にしたコミュニティでも問題ありません。

大事なのは利用者に楽しんでもらえる場を用意することであり、その熱量がまだ使ったことのない人たちにも伝播していくことです。それ以上の成果を求めようとして失敗するケースは多々あるのでくれぐれも注意してください。