この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
マーケ部長：「ハマちゃん、ツイ廃やんな？」
ハマコー：「まぁ、人並みには…」
マーケ部長：「じゃ、ソーシャル活用テーマでなんか喋って」
ハマコー：「（でたよ、この会社）」
というわけで、下記勉強会にてソーシャル活用について喋ってきました。
DevRel Meetup in Tokyo #35 〜ソーシャル〜 - connpass
- 一エンジニアの自分は、マーケティング素養皆無
- twitterのつぶやきに戦略性は皆無
- すいません。DevRelって、初めて聞きました
- ウチの会社って、ブログは有名やけど、ソーシャルとかなんかあったっけ？
- てか、これ、スーツの人の集まりやんな？俺が喋っても、むっちゃ浮く気がするけど！？
悶々とした気持ちを抱えながら当日参加してきたんですが、参加者スーツっぽい人は皆無で、エンジニアの人も非常に多く、ハッシュタグつぶやきも300超という、なんせとっても楽しい勉強会でした。
（祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 DevRelﾏﾂﾘﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ
登壇内容「全エンジニアDevRelな組織におけるソーシャル活用方法」
クラスメソッドにおけるDevRelとは
本日、端的にお伝えしたいことはこちらです。
DevRel（Developer Relation）の一般的な定義ってこんな感じだと思います。
クラスメソッドのDevRelは、言ってしまえばこんな感じです。
DevRelには、エンジニア全員が参加していて、その量は圧倒的です。頭おかしいレベルです。その中核と成るのがブログですが、クラスメソッドにおけるDevRelをイメージにするとこうなります。
これが、圧倒的な物量と圧倒的な速度で回っているのが、クラスメソッドの最大の特色じゃないでしょうか。なんでこんなもんが回っているのかと言うと、会社の仕組みとして、これを円滑に回すための仕組みや文化が有るからなんですね。
エンジニア全員がDevRelに携わる秘訣
自分はまだ入社1年ぐらいのペーペーですが、このサイクルにどっぷりハマっている1エンジニアの視点から、「クラスメソッドにおいて、全エンジニアDevRelが回る秘訣」を考えてみました。
秘訣①「評価制度にブログが組み込まれている」
これは、そのまんま人事考課にブログ本数が組み込まれているということです。いくら「アウトプットが大事やで！」と言ってても、評価されないとしたらエンジニア目線で不信感溜まりますもんね。まずはベースとして、この部分は確立したほうが良いかと思います。
秘訣②「社内レビューが一切ない」
これ、自分がこの会社入って一番衝撃だったんですが、まじでブログでも登壇するときの発表内容も事前の上司レビューが一切ありません。もちろん、お願いしたら必ず誰かがレビューはしてくれるんですが、事前の必須レビューは一切ないです。
何か外にアウトプットしようとしたとき、過剰な上司レビューが入る体制だと、どうしても「上司のレビューを抜けること」に意識がいくんですね。そういう体制になっていると、「何か書こう」と思ったときに、レビューが気になって「やっぱ止めた」となりがちなんですよ。これは情報発信の体制として健全じゃないと。
結局は会社とエンジニアの間にある信頼感だと思います。エンジニアが「書きたい」と思ったときになんでも書いて良い会社としての姿勢が、この「事前レビュー一切なし」に出ているんじゃないでしょうか。
「公序良俗に反する内容を誰かが公開したらどうするの？」とかね、そういうの杞憂です。無いです。ただ、「こういう記事の書き方はやめよう」というガイドラインは存在します。弊社のガイドラインを一部紹介します。
- ブログに書いてはいけないガイドライン
- 対象サービスをディスる表現
- 非公開ベータ版などの情報
- 個人情報がのった情報（スクショなどは要注意）
- ネットの噂ベースの情報
- 事実誤認やサービス規約違反を推奨する内容
- コピペや引用の範囲を越えた転載
- 特定団体や個人の誹謗中傷
技術ブログで情報発信を考えている組織は、是非このあたり参考にしていただければと思います。
秘訣③「ソーシャルフィードバックが可視化されている」
「ソーシャルフィードバック → 承認欲求」
各記事には、シェア数をベースとしたポイントがあります。シェア数が一定数以上あがってくると、記事にリボンがつくんですね。でこれが、どんどん派手になってくると。こまい仕組みなんですが、実際これでモチベーションあがります。なぜか上がります。
各エンジニアのプロフィール欄には、こういった経験値が表示されていたりもします。これ、自分のプロフィールページです。
また、全社の四半期報告会ごとに、SNSシェア、PV、本数でランキングされ、トップの人は表彰されたりというのもやってます。
まとめ
以上、全エンジニアが情報発信者（DevRel）なクラスメソッド式、ソーシャル活用でした。
登壇資料
登壇後日談
当日の勉強会の様子は、togetterにまとめられています。まとめ人が、なんとtogetterの社長（yositosiさん）！！という豪華まとめ。ワチャワチャした感じが伝わるかと。
同じく登壇されていたのが、戸倉彩さん、yositosi(@yositosi)さんというビッグネームで、正直登壇前は「自分、なにしゃべるんだこれ…」と日和ってたんですが、参加いただいた方にクラスメソッドの雰囲気が伝わったようで嬉しかったです。全部は紹介しきれませんが、ハッシュタグでも嬉しい反応いろいろいただきました。
クラスメソッドの濱田さん来た。
「全員エンジニアでDevRel な会社」その表現いいなぁ。パクろう。#devreljp— keisuke hikita (@hornets79) 2018年10月10日
エンジニアさんが語る「クラスメソッドにおけるDevRelイメージ図」#devreljp #devrel pic.twitter.com/kR2UrnzuPv
— 戸倉彩 (Aya Tokura) @Software Design連載スタート (@ayatokura) 2018年10月10日
エンジニア全員が情報発信！！
#devreljp pic.twitter.com/KnO07MxwWd
— DJ yhata@Japan (@yhata555) 2018年10月10日
これ、すべての文章書く人の気持ちだと思う #devreljp pic.twitter.com/y6aQP0JLBp
— たびちん／ワカタビタキエ (@takiyoro) 2018年10月10日
この資料作っている中で、改めて「なんでこの会社って、みんなブログ書きまくるんやろう…」と普段思っていることを可視化し社外の方に説明できたのは、良かったのかなぁと思います。これからも、ガンガンブログ書いていきますよっと。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
2
