UU 160%成長を支えたエンジニアと共創するブログ醸成術
この記事はDevReljp アンカンファレンス2024で登壇した内容の文字起こしです。
資料はこちら
UU 160%成長を支えたエンジニアと共創するブログ醸成術ということで話していきます。CARTA HOLDINGSの技術広報 中村です。よろしくお願いします。
まずテックブログの運営やってるって方ってこの中にどれくらいいらっしゃいますか？半分ぐらいですね。ありがとうございます。
みなさん、こんな悩みありませんか？
これ、僕も差し当たって問題にぶち当たりました。この1年くらいトライしてみて気づいたのは、エンジニアと並走するパートナーになるとうまくいくことでした。
で、1年間試してみた結果としてはUUが160%、本数としてはそんなに増えなかったんですけど、自律的にブログ書いてくれる人っていうのが増えていきました。
悩み、皆さんあると思うのですが、もしかしたらこういう感じでやってませんか？経験上これをやるとあんまりうまく回らないなという風に思っています。
では、改めまして、技術広報チームマネージャーをやってます中村と申します。6年間ぐらいエンジニアをやっていて、昨年、専任広報に転身しました。1.5年で通算100本ぐらいブログの担当させていただいて、担当記事での はてブ数は1700くらいです。
早速、今日のアジェンダです。
まず一つ目、エンジニアに丸投げせず共に作るパートナーに。
先ほど記事が出てこないという話を最初にしたと思うんですけど、出てこないというよりは書き方がわかんないんじゃないかなと思ってます。
理由の1つ目はライティングの技術がないこと、2つ目は書くことへの苦手な意識があること。3つ目は書くことやそれ以外の面倒さが嫌。
サポートする方法としては2つあるなというふうに思っていて、1つはレビューする有効を良くするというところですね。で、2つ目は執筆のサポート、何もないところから一緒に作っていくというところですね。
今回は2つ目の「何もないところから作っていく」について。
執筆サポートは、並走するパートナーとして一緒に走っていく。全体の流れをサポートすること、特に詰まるポイントとしては誰のために書くのかを決める。つまり、ペルソナの定義と要旨の整理ですね。
ブログに書く場合、何か元になる施策やってるはずです。その施策の狙いと変化、ビフォー・アフターと何を学んだのかっていうところを共に整理していく。
また、ブログ書く上でエンジニアに担当してもらう領域っていうのを絞った方がいいというふうに僕は思っています。
僕みたいに専任広報がいる場合は書くこと、つまりブログ執筆だけに集中してもらう。それが本質的価値で、あとは煩雑なんでそれを広報がやると責務を分けちゃってもいいと思います。もちろん執筆に関しても丸投げではなくて、一緒にペアで書くこともあります。
1回目の執筆のUXを高めると、リピーターと自立的な人が増えていくんですよね。1回目はめっちゃしっかりフルマネージドでサポートしていく。2回目からは
この前のやり方でやったしわかんないところだったら聞いてね
とリピーターを増やしたり自立的な動きを促していくっていうのをやっております。
番外として、レビュー投げるときのコツもあるなという風に思っています。
基本的にレビューしてくれる人ってめっちゃ忙しい人ばっかりなんで、「こういうポイントを見てほしいです」っていう風にポイントを指定してあげると帰って来やすいです。
アジェンダの2つ目。社内の小さな発信を拾い、その良さを本人に伝える。実はネタがないんじゃなくて、広報が拾えてない・提案がないか、エンジニア自身に出す自信がないのか、どっちかのケースが多いです。
ネタがないと言った時に、じゃあどうやってネタを探すのか？割と難しいと思います。これの理由は二つあって、構造的な問題と認知負荷的な課題があると思います。
構造的な問題に関しては、普段エンジニアと共に仕事をしない場合はどういう仕事やってるのか？そもそもわかんないケースがあります。認知負荷的な課題としては一緒に仕事していたとしてもシンプルに流量が多く認知負荷が高い問題。
じゃあどうやってアプローチするのかというと、社内の中にしかネタは存在しないんで、ストック情報をひとまず拾いに行く。
フロー情報は後回しにする。可能な限りエンジニアと仲良くしていく。
これらが大事かなというふうに思います。
キャッチアップの方法としては、エンジニアがまとめた情報を頼ります。狙い撃ちで僕が読むのは以下。
フロー情報で唯一読んでるのはエンジニアのtimesチャンネルです。CARTAはtimes文化があるんですけど、ここにしかエンジニアの人柄が現れないので読んでいます。エンジニアの能力的な部分っていうのは上のストック情報でわかるんですけど、キャラクターとかは出てこないんで、それはある程度追ってます。
技術責任者のミーティング資料も頼れるものですね。これは抽象度高いんで背景理解があれば比較的読みやすい。
さっきも言った通り、エンジニア組織が10個以上あるので追うのめっちゃ大変なんですけど、幸いなことにCARTAは技術力評価会制度によって追いやすい体制になっています。これは90分間のプレゼンを半期ごとに行う評価制度で、その資料はオンラインで読めます。それを読めば個々人の仕事についていくことができる。
あとは、発信に自信がないエンジニアの場合は、エンジニアの勇気をサポートしに行く動きをします。ネタが見つかった後に提案しても本人から「いや出さなくていいっすよ」みたいな返答が割とあります。
こちらから「ここがいいと思うんですよね」と魅力を伝えた上で出してもらうというのも1つの手かなと思います。
番外的には、CARTAの場合は社内ブログがあって、それにいいねがつけれるので「ほら15個もついてるじゃないですか？」と社内評判を自信に変えてもらうのも方法の1つです。
3つ目ですね。組織のためだけではなくて、個人のキャリアの武器を作る。
そもそも組織は何のためにブログ運営やってるかっていうと、採用広報観点と社内育成観点があると思います。これは多分、皆さん承知の通りだと思います。
多くの場合「採用広報が主眼だよね」は組織上の前提であり、育成、成長に関しては発信の副産物、という立ち位置かと思います。
一方で、エンジニアにとってのモチベーションは何か。
組織目線と自身の観点、個人の観点があると思います。
組織目線では成果のアピール、後輩の育成、採用と複合的な目線があります。個人の目線では成長やキャリア資産を作る、つまり外に向かって自分の実績を喋っていくための「キャリアの武器」を創ることかと思います。
この「キャリアの武器」を一緒に作っている気持ちを尊重してあげるというのはすごく、やっぱり僕も大切だと思っています。
一緒に胸張って出せるものを作ろうよ
って姿勢を続けていくと、
あの人に任せたらちゃんといいものを一緒に作ってくれるから任せればいいよ
って先輩づてに言ってもらえるケースが増えています。そういう風にブログを出す文化を醸成していくことが必要かな？大事だったなと思います。
また、届いた反響を書いてくれた人にはちゃんと成果を伝え報いるのも大切です。例えば週のはてブサマリに掲載されてたよ、とか。
まとめです。エンジニアが必要としてるのは締切追ってくる人じゃなくて、一緒に創ってくれる人だと思います。その熱量は確実に伝わるかな、と思います。
以上、僕がやってきたテックブログ運営の取り組みです。ご清聴ありがとうございました。