OFFICIAL SNS
DevRelと旧来のマーケティング手法との違いについてです。これまでアクティビティ主体、ボトムアップ、聞くマーケティングを挙げてきました。今回は4つ目、コミュニティによるサポートについてです。
DevRelにおいてコミュニティサポートは欠かせない存在と言えます。コミュニティとはいわば有志の集まりであり、そこに金銭の授受は発生しません。もちろんサービス提供会社の人が中に入って解答するケースもあります。
コミュニティを立ち上げるならサービスインした時に最初から用意されているか、サービス自体が盛り上がってユーザ数が伸びてきた段階にしましょう。まだ伸びていない段階からコミュニティを用意しても、誰も発言せずに過疎になる可能性があります。そんなゴーストタウン化したフォーラムを見た人は本体サービスまで面白くないものだと勘違いしてしまう可能性があります。
そのため一定のアクセス数が確保できると確証できるまでは開始しない方が良いでしょう。もしやるのであれば最初からはじめた方が良いです。
場所だけ用意されて「さぁ質問してください！」と言ってもなかなかできるものではありません。最初はサービス提供側から幾つか質問と回答例を出しておくのが良いでしょう。また、メールフォールなどで来たお問い合わせを使ってサンプルにするのも良いかと思います。
その際、ステマだと思われないために“質問サンプル”や“過去質問”などと記しておくのが良いかと思います。
旧来の広告主体のマーケティングにおいてはサービス提供企業のサポートは必須になります。システムやサーバの場合、24時間/365日でサポートを提供する場合も少なくありません。その分の金額が料金に含まれています。
DevRelを提供する場合、無償で提供されるサービスも多いため全ユーザに手厚いサポートを提供するのは困難です。そのためユーザ同士でサポートし合える、コミュニティの存在が欠かせません。コミュニティの中から他のユーザを積極的に助けてくれるユーザを創出するのもDevRelの大きな目的と言えます。
これは4つの面でメリットがあります。
まず無料ユーザに対して手厚いサポートを提供するのは本来開発に充てるべきリソースを費やしてしまう可能性があり、コミュニティはそのリソースの消費を防ぐことができます。
コミュニティがなければユーザは本サービスの問い合わせを使ってしか調べる手段がありません。しかしコミュニティを用意することで、質問がきても「コミュニティに投げてください」と言うことができるようになります。
コミュニティを提供することで、サポートを有料サービスとして提供することができます。オープンな質問はコミュニティ、クローズドな質問は有料サポートといった区分けができます。有料でお金をもらっているため、手厚いサポートが実現できます。
質問者としてもクローズドであればソースコード内部の込み入った質問もしやすくなるでしょう。オープンな場合にはなかなか難しい質問も有料サポートを用意してあげることでお互いメリットが生まれるでしょう。
コミュニティサポートはオープンなもので提供し、ユーザ同士の対話がそのままサービスのナレッジになるということです。あなたは何か困った点があれば検索エンジンで調べるでしょう。そこに過去の質問がインデックス化されていることでユーザは素早いセルフサポートができるようになります。
クローズドなサポートは社内の限定的なナレッジ蓄積にとどまってしまいます。そして内容も細かな点になるため、おいそれとオープンにできないものが多くなります。その結果として多くのユーザから同じような質問が寄せられ、何度も同じ解答をしなければならなくなるのです。
Webサービスや技術はよほどのものでない限り、あっという間に他社に真似されてしまう可能性があります。プログラムはバイナリデータなので、一度作られたものを同じように再現するのはゼロから創出するのに比べて大幅に楽です。
しかしコミュニティはユーザとのつながりであり、その中で育まれた信頼感は一朝一夕に模倣できるものではありません。Googleで検索した時に情報がたくさん出てくるのと出てこないサービスがあったら、あなたはどちらを使いたいと思うでしょうか。
また、類似のサービスが出てきた時に既にコミュニティが形成されていると、みんな新しいサービスに流れず使い続けてくれます。それは人と人のつながりであり、アナログな無形資産があなたのサービスにおいて最も大きな資産になるのです。
逆にデメリットを見てみましょう。
最も大きな問題としてはコントロールできない（してはいけない）という点です。コミュニティは場を用意するのは企業でも良いですが、その自治制はユーザにゆだねるべきです。もちろんルールは予め提示しておくべきですが、よほど悪意をもって行わない限りは目をつぶらなければいけません。
過干渉が続くと、それだけでユーザは白けてしまい、話しづらい雰囲気を作ってしまいます。もし悪い評価が出たとすれば、それを消すのではなく、改善のタネとして修正していく心構えが必要です。
質問は増えるのに回答者が増えないと、やる気がないサービスに見られてしまいます。そんな時にはDevRelの一環として存在するエヴァンジェリストと呼ばれる人たちに積極的に回答してもらうようにしましょう。
もし社内で抱えるエヴァンジェリストである場合は自分の発言が公式回答になってしまう点に注意して行ってください。あくまでもユーザの一人として…といった意見の出し方は通じません。特に回答に問題があった場合などは余計な反発を生む恐れがあります。
コミュニティサービスは掲示板またはQ&Aサービスを使って行うのが一般的です。有名なところではStack Overflow、GitHub、Discourseなどが知られています。この違いとしてはデータが自分たちの手元にあるのか、全く違うのかといって点にあります。Stack Overflowを使った場合、そのデータは自分たちと全く違う場所にあります。GitHubのIssuesを使った場合、データは違う場所にありますが、自分たちの管理下に置くことができます。Discourseはオープンソース・ソフトウェアなので、自社で立ててカスタマイズ含めて自由に自社の管理下でコントロールができます。
この違いとしては、まずアクセス解析が行えるか否かという問題があります。最近注目を集めている質問であったり、Web検索流入の変化、コミュニティから本体サービスへの流出がどれくらいあるかなど、分析できるデータがとれるかどうかは大きな問題になります。Stack Overflowは全くとれず、GitHubも多少です。Discourseは自由にデータがとれます。
次に質問のしやすさがあります。Stack OverflowやGitHubは既に使い慣れたサービスである分、質問の障壁は低いと言えます。特にStack Overflowの場合は他にもたくさんの質問が並んでいますので、質問しやすい雰囲気があります。GitHubはIssueを切った経験はプログラマの誰もが持っていると思います。ですが、全くの新しいリポジトリ化で質問するのは緊張することもあるでしょう。Discourseは全くの新規で立ち上げますのでユーザ登録の障壁も存在することになります。
コミュニティサポートはオープンソース・ソフトウェア（またはそれ以前）からの文化としてプログラマの間には存在します。かつてはメーリングリストが多かったですが、それはオフラインでも読めるからです。最近はインターネットがつながっているのが当たり前になっていますので、Webブラウザ上でコミュニティを提供するのが一般化しています。
メールにてDevRelに関するニュース、アップデートをお送りします。
Contact is below.