DevRelの施策(コミュニケーション)

はじめに

前々回から数回に分けつつ、DevRelの基本的な考え方となる「4C」について解説しています。最初にContents(コンテンツ)、前回でCode(コード)を取り上げました。3回目の今回はCommunication(コミュニケーション)について解説します。

DevRelは開発者との良好な関係性を築くことが大きな目的です。その際、一方的に発信するだけでは関係性の構築は難しいでしょう。相互のコミュニケーションがあってはじめて、関係性を構築できます。そのため、コミュニケーションはDevRelにとって、とても大事な要素になります。

今回は、DevRelにおけるコミュニケーションについて、例を挙げつつ解説していきます。

開発者コミュニティ

こと日本において、多くの開発者コミュニティが存在します。プログラミング言語、フレームワーク、クラウドサービスなど実に多種多様です。個人として興味がある、会社で利用しているなどそれぞれの理由があって、コミュニティに所属していることでしょう。

世界にも多くの開発者コミュニティがありますが、日本は特にコミュニティが活発であると感じています。一定の開発者規模があり、個々の都市もそれなりに大きく、言語(日本語)のバリアーがあるなど、日本では開発者コミュニティの育つ土壌が存在します。もちろん開発者同士の相互協力する姿勢があることも、開発者コミュニティが育つ要素になっています。

開発者コミュニティを探そうと思ったら、日本ではまずconnpass、次にDoorkeeperを利用するでしょう。英語圏のコミュニティはMeetup.comを使うかもしれません。しかし、日本でconnpassが有名なのと同様に、国によって開発者がよく使うツールは異なるので、コミュニティの探し方にも注意が必要です。

connpass

こと日本について言えば、成長著しいコミュニティとしてはIoT縛りの勉強会! IoTLTになるでしょう。頻繁にイベントを行いつつ、かつハードウェアが絡むIoTにおいてLTが幾つも発表される発信意欲はとても素晴らしいです。

ベンダー系のコミュニティ(ユーザーグループ)としてはJAWS-UGが最も有名でしょう。AWSに絡む仕事をしている方であれば、一度はイベントに参加したり、見聞きしたことがあるはずです。定期的なイベントはもちろん、年次でのイベントも行われており、歴史は長いですが今なお熱量の高いコミュニティです。

JAWS-UG

ソーシャルメディア

特に日本ではよく利用されているTwitterは、開発者とのコミュニケーションチャンネルとして有効です。発信はもちろんですが、メンションやハッシュタグを使ってユーザー動向を伺い、その場でサポートしたり連絡したりできます。

有名なメーカーやサービスでは中の人が有名になったりします。つい、そうした成功例を真似たくなる話を聞きますが、なかなかうまく行くものではありません。一朝一夕に真似ようとしても、必ず失敗するでしょう。何よりTwitter担当者がTwitterを長く運用してきた経験がないと、何をツイートすれば良いのかもわからないでしょう。

DevRel Meetup in TokyoのTwitterアカウント(https://twitter.com/devreltokyo)

宣伝するためのチャンネルと考えると、ついフォロワー数ばかり気にしてしまいます。しかし、あくまでもユーザーとのコミュニケーションチャンネルだと考えれば、別な視点が必要になるでしょう。困っているユーザーがいないか、ヘルプを求める声にいち早く対応するといった使い方ができます。

世界的に見れば、Twitterはあまり大きなサービスではありません。他のソーシャルメディアとしてはFacebookやLinkedInがあります。また、国によってはWeChatやWhatsAppのようなコミュニケーション機能を使っているケースもあるようです。この辺りも国によって事情が違うのが面白いです。

Q&A

開発をしていて、何も調べずに完了するケースは多くありません。大抵、APIやコードの書き方を調べながら開発を進めるのではないでしょうか。そうした困った際に役立つのがQ&Aサービスです。世界的に見ればStack Overflow、国内ではTeratailが有名です。

Teratail

こうしたQ&Aを通じた開発者サポートもDevRelの大事な施策です。質問をしている間、開発業務は止まってしまう、または著しく生産性が落ちます。その状態で放置されれば、開発者としても良い気持ちはしません。むしろストレスが溜まって、最終的に解決できなさそうと感じれば、他のサービスへの乗り換えを検討するでしょう。

逆に質問してすぐに答えてもらえたらどうでしょうか。もちろんすぐに開発に戻れますし、開発者体験としても非常に優れたものになります。Q&Aは開発者体験を大きく左右するものだと、体感的に知っている方は多いでしょう。

ニフクラmobile backendではGitHubのIssuesを使ってQ&Aを提供しています。有償顧客にはテクニカルサポートを提供しているので、このQ&Aは主に無償ユーザー向けになります。こういったQ&Aに寄せられる質問はいわば生きた質問であり、実際に開発を行っている方達が感じている問題です。質問に答えることで他の人がWeb検索でセルフサポートできるようになったり、開発にフィードバックしてプロダクトの改善にも繋げられます。

フォーラム・メーリングリスト

Q&Aに似ていますが、少し前はメーリングリストが主流でした。今でもGoogle Groupを使っているサービスがありますが、あまり主流ではありません。ただし、企業によってはオープンな場で質問を書く文化がなく、メールを使った方が良いというケースもあります。この辺りの最適なコミュニケーションツールは対象とする開発者層によって異なります。

Google Group

フォーラムでは、開発以外の話題にも触れやすいのが特徴です。製品のアップデート、利用法全般、ビジネス面などの話題も取り上げられます。Q&Aサービスは開発者向きですが、フォーラムは開発者以外の方にも参加しやすく、書き込める雰囲気があります。

フォーラムではDiscorseやVanillaを使っているケースが多いように見えます。メーリングリストといえばmailmanが最も有名だったと思いますが、最近ではほとんど見かけません。Google Groupを利用しているケースが少し残っているかな…といった程度です。

ハンズオン

ハンズオンは座学のイベントではなく、参加者が実際に手を動かして学ぶイベントです。手を動かすためにPCを用意したり、サービスアカウントが必要になることも多いので、ウェビナーと比べると敷居が高くなります。その代わり、学習意欲が強く、積極的に学ぼうとする方達が多い傾向があります。

ハンズオンの様子

イベントの時間は様々で、半日〜1日がかりで取り組む規模の大きなものもあれば、数時間で終わるものもあります。筆者がよく行なっているのはオンラインで1時間程度というものです。必要な部分だけを学べる形にして、つい飽きてしまいがちなオンラインでも短時間に集中して実施できるようにしています。

コロナ禍前であれば、開催場所に集まってもらってハンズオンを行なっていたのですが、イベントスペースに持ち込むPCは外部ディスプレイがなかったり、普段使っているものではなかったりと不便なことがよくありました。オンラインハンズオンの場合、自宅やオフィスの使い慣れたデバイスで行えるのが大きなメリットです。その場で画面を見ながらサポートしづらいというデメリットはありますが、それでもメリットの方が大きいように感じます。

ハンズオンはちょっとした作品を作ったり、自分の手を動かしてなんらかの形になるものを作り上げます。出来上がったものがそのままお土産になるので、ウェビナーと比べて満足度が高くなります。

ハッカソン

ハッカソンは1〜2日間程度、集中して行われる開発コンテストです。こうしたハッカソンを主催したり、協賛してテクノロジーを提供します。そして参加者にプロダクトに触れてもらって、そのフィードバックを得るのが目的になります。

ハッカソンの様子

フィードバックを得ると言っても、使えない状態(ベータ版など)で使ってもらうのはお勧めしません。もし不具合があったときに、その場で修正できない可能性は高いですし、もしそういう不具合に遭遇すれば開発者の失望を招きかねません。十分に使える状態になってからハッカソンに出る方が良いでしょう。

ハッカソンはコロナ前後でずいぶん体験が変わってきたように感じます。コロナ前は顔をつけ合わせて不休で頑張るといったものでしたが、オンラインになってからはライトな雰囲気で個々に頑張るといった形になっています。テクノロジー提供側としても参加者とコミュニケーションを取りたいのですが、なかなかうまくいかない場合が増えています。

おわりに

DevRelConというカンファレンスのオリジナル主催者であるHoopy社のMatthew氏は「A handshake is more than worth a click」と言っています。直訳すれば「握手はクリックよりも価値がある」ということですが、これは対面などを通じたコミュニケーション全般に言えることでしょう。オンラインで発信するだけでは関係性を築くのは難しく、意思疎通があってはじめてできるものです。

ただし、開発者によっては住んでいる場所や仕事のスタイル、趣味などは異なります。みんながオフラインイベントに参加できるわけではなく、オンラインやソーシャルメディアが好きという方もいます。開発者に合わせて最適なコミュニケーションスタイルを取れるのがベストでしょう。