Above & Beyond

日々のアウトプット記録

DevRel Meetup in Tokyo #35 〜ソーシャル〜 に参加してきました

昨日は 「DevRel Meetup in Tokyo #35 〜ソーシャル〜」という Meetup に参加してきました。

devrel.connpass.com

tl;dr

エントリ書くのに時間かかっていたら、togetterの方に昨日のツイートがバッチリまとめられていました。 こちらを見れば当日の雰囲気は分かると思いますので、お急ぎの方はこちらをどうぞ。

togetter.com

以下、参加したレポートになります。

DevRelって何?

DevRelって何?というのは、イベントのページに書いてあるので引用すると

AmazonGoogleFacebookEvernoteGitHub…多数の企業が実践しているマーケティング手法がDevRel(Developer Relations)です。外部の開発者とのつながりを形成し、製品やサービスを知ってもらうこと、さらに彼らの声を聞くことでサービスの改善や機能追加に活かしていく活動になります。

いわゆる、エバンジェリストとかアドボケイドと呼ばれる人たちが知見を共有したり情報交換をする場が、DevRel Meetup になります。 とはいえ、そういう人たちばかりでなく

と、興味がある人でも参加可能ということもあって、気がつけばもう8回ほど参加させていただいてます。自分では一番長く参加しているコミュニティMeetupです。

なぜ参加したか

理由は簡単で、参加して楽しいですし、自分は話下手なのでエバンジェリストとかアドボケイドと呼ばれる人たちの話を聞くのは凄く勉強になるからです。あ、エバンジェリストとか凄いよね、というミーハーな気持ちもあります。(をい)

参加して楽しい、というのは多分コミュニティを運営している人たちが頑張っていて、参加する側へのホスピタリティが行き届いているからだと思います。興味があるというだけで毎回参加していて、申し訳ない気持ちなのでたまに会場の設営とか片付けをお手伝いさせていただいてますが、本当に凄いなと思います。あとは、そういう運営の人たち自身もこのMeetupを楽しんでいる感じがしていて、そこも凄くいいなと思うし、参加したくなるポイントだなと感じます。

楽しい雰囲気は、Twitter で #devreljp のハッシュタグを追ってみると伝わると思います。

ソーシャル

で、今回のテーマはソーシャル。3名の方が登壇されました。

  • 濱田さん@クラスメソッド
  • yositosiさん@Togetter
  • 戸倉さん@職業戸倉彩

全エンジニアDevRelな組織におけるソーシャル活用方法

クラスメソッドの 濱田さん(@hamako9999) の発表です。

speakerdeck.com

クラスメソッド といえば、AWSのコンサルなどをしている会社ですが、Developers.IOという技術メディアで圧倒的な量のブログ記事を発信し続けているということでも有名だと思います。

dev.classmethod.jp

「エンジニア全員が情報発信(DevRel)する組織におけるソーシャル活用のヒント」ということで、クラスメソッドという会社がどうやって 情報発信を通じてDevRel に繋がっていくかということをお話されていました。

詳しい内容はスライドを見ていただくとして、印象的だったのは

”アウトプット主義”に基づき全社員が社外及び社内の読者への情報共有

  • とにかくアウトプット
  • 書きたいときに書きたいことを書きたいように書く
  • 読者に有益なら社内のノウハウでも書く

というのを徹底して行っているという話です。情報発信からフィードバックまでのループが機能することで、会社にも個人にもメリットがある。このことからクラスメソッドのDevRelの特徴として、数名のエバンジェリストが情報発信するのではなくエンジニア全員が情報発信をするというのが挙げられていました。情報発信を促す仕組みとして、情報発信の数やフィードバックなどが評価制度に組み込まれている(減点ではなく加点)そうです。徹底してますよね。

で、情報発信に際して、事前の必須上司レビューはない(レビューは任意だが、見て貰える人は必ず居る)、という部分で自分がツイートしたスライドの写真にたくさん「いいね」をつけてもらったのがこの部分。

f:id:kabukawa:20181011105032p:plain

エンジニアだったらもはや同意しか無いんじゃないでしょうか。 とはいえ、「誰かがそれこそ公序良俗に反するどうしようもない記事を公開したら」という懸念もあると思いますが、「杞憂です」とばっさり。確かに、全員が情報発信する中ではそんなものを公開する人が同僚に居るなんて思いたくないでしょうし、そういう意味での抑制は効くでしょうからそんな心配は不要なのかもしれません。

フィードバックの可視化もいろいろな指標で可視化されていて、ここまで徹底してやっていれば企業からの情報発信もうまく回るのかもな、と思いました。

カンファレンスやセミナーでツイートやまとめを活用するノウハウ

Togetter の yositosi (@yositosi) さんと アオヤマ ミント (@MintoAoyama ) さんによる カンファレンスやセミナーでツイートやまとめを活用するノウハウについてのお話。 スライドは公開されていませんので、拙いまとめになります、、、 資料が公開されたのでリンクを貼っておきます。

speakerdeck.com

セッションは Togetter さんでイベントなどに協力するときに使われている「ツイート流れるマシーン」というツールを使って行われました。 なので、最初にツイート流れるマシーンの説明が。参加者の皆さんは自分たちのイベントなどのときに使いたい!とかいくらなの?という反響が続々とツイートされる状況に。

ツイート流れるマシーンについては、以下の アオヤマ ミントさんの書かれたQiitaの記事が参考になります。 実装のさわりも書かれているので、エンジニアの皆さんには興味深い内容なのではないでしょうか。

qiita.com

画面を分割してスライドなどを見せながら、横にツイートを流して会場の反応を流すことでインタラクティブな一体感を持たせられるツール、と、自分で書いていても何を言っているかわからないと思うので、J-Wave のイベントで使われたときのまとめのリンクを貼っておきます。

togetter.com

DevRel Meetupでの画面は写真撮ってなかったので、ツイートを引用しますが、こんな感じでした。

で、横に出るツイートは実はリアルタイムではなく3秒間表示されないようにバッファリングをされているとのこと。イベントで表示させたくないツイート(広告とか関係ないツイート)を排除するための制御で、この時間を使って流すツイートを「人力で」選別するのだそうです。なぜ人力かというと、自動的に高い精度でスパムや不要なツイートを排除するのは難しいというのが理由だそうです。せっかくのインタラクティブに一体感を出しているときに関係ないツイートが表示されたら一気に醒めるので、このこだわりはなるほどな、と思いました。(選別する側はずっと集中して見ていなければならないので大変だと思いますが)

で、ツイート流れるマシーンの話が落ち着いたところで本題の togetter の話。 Twitterは情報が流れていく(フロー)なメディアですがこれをストックに変えるのがtogetter。 togetterはもともと開発イベントのアーカイブとして誕生したとのこと。

目指しているのはストック化による価値の最大化。

  • 参照しやすく
  • 見やすく
  • 検索しやすく
  • 編集しやすく
  • 管理しやすく
  • 拡散しやすく
  • 共有しやすく

ということを実現しようとしている。10年前(togetterを始めた時)のまとめも見ることができる。

t.co

サービスの継続性というところもあるけど、これは案外難しいところだと思います。 SEOよりソーシャル流入を重視しているというのも、「ストック化による価値の最大化」という視点で考えると納得。 月間5万はてブというのもすごいですね。

あと、使い方として公開ではなく個人のプライベートまとめ用にも利用されている方がいるというのも面白いなぁと思いました。 そういうふうに使うという発想はなかった。。。

イベントにおける togetter の役割は主催者もしくは登壇者と参加者の間のリアクションをコンテンツ化すること。

カンファレンスでのまとめ作成代行で得たノウハウ 以下の内容を主催者が事前・オープニング・ルーム毎にアナウンスする。

  • ツイートを積極的に推奨
  • ルームごとのハッシュタグの徹底
  • ツイート禁止事項の告知
     スライドNや顔出しNGの場合
  • まとめを作成することの周知
  • セッションの写真を最低1枚ツイート

最後の写真はなぜ重要かというと、まとめへのリンクを貼るときにその写真がサムネイルになる(OGP)から。「Togetter映え」させるためには写真が大事。

まとめることのメリット

  • 主催者にとって
    追加の成果物、議事録、レポーティング、アーカイブ
  • 登壇者にとって
    自分のセッションのログ、視聴者の反応
  • 参加者にとって
    モチベーション、参加した実績、ふりかえり
  • 参加しようと思っている人
    会場の様子、質疑応答の内容、今後の参考

最新情報

10/10から、まとめ内でのスライド展開機能が提供され始めたとのことです。 いままではリンクだけだったので、この機能が有効になったことでスライドのまとめが作成できる様になりました。

Developper Relations におけるSNS戦略(Twitter編)

最後は 戸倉さん(@ayatokura ) による「Developper Relations におけるSNS戦略(Twitter編)」というセッション。 スライドは公開されていると思ったら、表紙画像だけだったので思い出しながらの拙いまとめになります、、、

f:id:kabukawa:20181011131732p:plain

Twitterアカウントのクラウディア窓辺の中の人としてキャラクターコミュニケーションという話から始まりました。 知らなかったのですが、最初からクラウディア窓辺の中の人として始めたわけではなく、すでにあるキャラクターに憧れて、中の人になるために努力した」という流れだったというのは、ちょっとおもしろいなと思いました。

キャラクターコミュニケーションはキャラを通じていうとことと会社から言うことでは伝わり方が違うというのも面白いですよね。

で、キャラクターの話は一旦置いておいて、技術系のアカウントの種類について整理した上で、それぞれのケースで運用管理する場合の課題を挙げられています。

技術系アカウントいろいろ

IT企業所有 技術コミュニティ所有 個人所有
・公式アカウント
・特定専門アカウント
・開発者向けアカウント
・公認キャラクターアカウント
Bot
・技術公式アカウント
・本家コミュニティアカウント
・ローカルコミュニティアカウント
・キャラクターアカウント
Bot
・キャラクター
・ニックネーム
・本名
Bot

IT企業で運用管理する場合の課題

管理者 運用コスト 運用内容
専任 or 兼任
技術者 or 非技術者
・日本語 or 英語
・運用管理期間
・運用管理時間(週末/深夜)
・業務委託の有無
予算
企業ブランディング
技術ブランディング
関係部署との調整
・ツイート頻度
・ツイート品質
・ツイート専用ツール
リツイート頻度
・リプライ頻度
・メンション頻度
著作権
炎上対策(企業責任)

コミュニティで運用管理する場合の課題

管理者 運用コスト 運用内容
共有 or 固定メンバー
責任範囲
・技術者 or 非技術者
・日本語 or 英語
・運用管理期間
・運用管理時間(週末/深夜)
・予算
コミュニティブランディング
技術ブランディング
・ツイート頻度
・ツイート品質
・ツイート専用ツール
リツイート頻度
・リプライ頻度
・メンション頻度
著作権
・炎上対策

個人で運用管理する場合の課題

管理者 運用コスト 運用内容
本名 or ニックネーム
所属先の公開の有無
・技術者 or 非技術者
・日本語 or 英語
・運用管理期間
運用管理時間(週末/深夜)
セルフブランディング
専門分野/不得意分野
・ツイート頻度
・ツイート品質
・ツイート専用ツール
リツイート頻度
・リプライ頻度
・メンション頻度
著作権
炎上対策(自己責任)

こうやって見ると、企業でアカウント運営するのは色々難しそうだな、と思いました。

で、ここでキャラクターの話に戻ってきます。 キャラを通じていうとことと会社から言うことでは伝わり方が違う、というところからIT系の技術系アカウントとしてキャラクターアカウントを持っているところが結構あるという話に。

確かに結構ありますよね。 これらはすべてBotじゃない限りは必ず中の人がいて運用管理しているわけです。(中の人は居ないんですけど、という話はさておき)

で、中の人として1万人のフォロワーがいた経験者の話として

  • どこからが仕事でどこからがプライベートなのかわからないときも
  • 最初はフォロワーが伸びないのが苦しかった
  • ツイートしてないと生きてないと思われる
  • 誰かに貢献できたことがわかったとき、やっててよかったと実感できる
  • エバンジェリスト」や「中の人」としてのSNS活動は仕事ではなく生き様ですね

あと、フォロワーについては

  • フォロワーは必ずしも人間ではない
  • フォロワーは必ずしも自分のファンではない
  • フォロワーは必ずしも東京在住ではない

という話もされていて、なるほどと妙に納得しました。 (いや、考えてみれば当たり前なんですが、やっているうちにそういう感覚が薄れていくというか)

最後に、個人でツイートしたことでのノウハウと言うか、アドバイスとして

1.エンジニアであれ 2.正しい情報を伝える(鮮度、公式か個人の意見か明確に) 3.コミュニケーション(リプライ・メンションもまめに!) 4.センス(社会性、品格、ダイバーシティインクルージョンで) 5.エンゲージメント(アクションを明確に伝え相手に行動させる)

ということを仰っていたのが、凄く印象に残りました。

LT

LTは以下の3本でした。それぞれについても書きたかったんですが、ちょっと力尽きました。 wataru yamazaki さんの内容は別の機会(次回の DevRel meetup?)にシェアしてもらえるんじゃないかと思います。

まとめ

今回は参加者もいつもより多く、わいわい楽しく時間が過ぎていく感じでした。

内容もとても参考になるものばかりで、参加できてよかったです。 (その分まとめるのに時間がかかってしましました。。。)

このエントリを読んで、少しでもこのコミュニティ楽しそうと思ってくれる人が増えて、参加者が増えたりしてくれると嬉しいなと思います。

尚、再来週にこんなミートアップが予定されています。

www.meetup.com

in English とある通り英語で実施される DevRel Meetupです。 とは言え、ほとんど参加者は日本人ですし、今回のように最初からアルコールが入るので、まぁ勢いで行けば大丈夫なんじゃないかと。 (経験者は語る)

まだ空きはあるようなので良かったらこちらもチェックしてみてください。

DevRelに興味を持ったら

技術書典で本を出されています。紙の本は完売のようですが電子書籍は販売中ですのでAmazonのKndleストアで買えます。 読みやすく書かれていますし、ページ数も多くないので楽しく読めると思います。 (レビューは、、、今日書けるといいな。。。)

デベロッパーコミュニティ【光編】

デベロッパーコミュニティ【光編】

デベロッパーコミュニティ【闇編】

デベロッパーコミュニティ【闇編】

更に詳しく DevRel について知りたいという方は以下の本を読みましょう。おすすめです!