これは『2023年度を数字で振り返る「技術広報LT大会」』の登壇内容について、
口頭で話したことを補足しつつ、その他話せなかったこと含めてドキュメントにまとめたものです。
LT大会は楽しいですね、各社の発表も有益情報が多かったので、また行こうと思います。
TL;DR
- テックブログの投稿本数が94倍、PV数が39倍に。
- まずは、定石に則りアンチパターンを潰す。
- 自社の風土に合わせてローカライズしてアウトプットを継続する工夫を。
- 書きたいものを書いてもらった上で、「できる限り読まれる努力」は運営の責任。
- 当ドキュメントは色々私が書いてますが、全て編集長がやったことです。
荒廃したテックブログの再生
荒廃してました！
レバテック開発部としては、年2本しかテックブログを書いていませんでした。
荒廃の定義にもよりますが、私はこれを荒廃と見てました。
技術広報を促進していくタイミングで、まずはここからやれねばなーと思っていました。
再生！
結果と言いつつ、まだ過程に過ぎませんが。
一旦再生！
荒廃の要因
社内ヒアリングしました。
① 書くネタが無い
② 書くのが面倒
③ 書いても読まれない
特段、自社特有の納得できる合理的な理由があるわけでもなく、
まあテックブログ荒廃あるあるでした。
世の中の「あるある」問題に対する解決策は、
だいたい先人が解決してくれてます。
巨人の肩に乗りましょう。
鳥獣戯画フリー素材サイトはなんでもある
成功の鍵はないが、失敗の鍵は豊富。
テックブログ運用についての参考資料は諸々ありましたが割愛します。
見えてきたこととしては、
- うまく行ってる企業の多くは「アウトプット継続」を最上目的としていること。
- その他、成功要因は確立されておらず、企業によってマチマチ。
- 逆に、失敗要因は再現性高く確立されていること。
故に、レバテック開発部としては
- 定石に則りアンチパターンを潰す
- あとは自社の風土に合わせてローカライズ
やったこと
①ハードル激下げ
何重ものチェックを挟んでいたフローから、チェックなしへ。
結果的には今のところ無問題です。
リスクを負ってでもハードルは下げることで、
アウトプット数が増え、打席に立つことでクオリティも上がっていくと思います。
ちなみに希望者はレビュー挟んでます。編集長がナイスレビューしてくれます。
②編集長就任
ネタ出し！告知！根回し！
いるといないじゃ全然違います。
編集長に責任と権限を与えることが重要かと思います。
また、EM/VPoEレイヤーではなく、メンバーレイヤーに近い方を編集長にしたことも、
ハードルを下げた一要因になったかなと思います。
私が登壇して私がZennに書いてますが、
テックブログ関連でやった工夫はほとんど編集長の手柄です。
ちなみに編集長はこんな記事書いてます。
③目標は置かない
ふわっとした「アウトプット継続」だけを目標に置く。
それ以外はなにも置かない。
これは定石にあったため、素直に取り入れました。
本数もPVも計測はしつつ、目標は追っていないです。
PVも多けりゃいいとも思っていないです。
これはおそらくフェーズにもよるので、
いつか目標を置くときも来るだろうと思っています。
④運営上の思想を明示
編集長の思想を明示しました。
スタンスとしては
「あなたが書きたいもの書いてほしい、それを見たい」
「いいねが多い記事≠いい記事」
この思想についてはこれだけで一本ドキュメント化出来ると思うので、
いつか編集長に書いてもらいます！
⑤Zennはいいぞ！
正直、弱者の戦略だと思います。弱者は言いすぎかもしれませんが。
もともと自社ドメインのブログで書いてました。
そこからZennに移行してます。
やはりプラットフォームは強く、圧倒的に読まれやすいなと思います。
Zenn以外のプラットフォームも検討しましたが、直近数年の動きを見る限りはZennかなあ、となりました。
自社ドメインの方がベターな企業さんももちろんあって、
すでに自社ドメイン・自社Xアカウントに人がついている企業はそうすべきだなと思います。
そういう意味では、Zennが弱者の戦略って言うよりも、
自社ドメインのブログを選択することはかなり強者の戦略だなと思っています。
どうしても読まれづらいので。
毎日書いてるとトレンドにレバテック開発部が3つも4つも上がってくる
⑥Zenn Publication Proはもっといいぞ！
・Publication 記事のレビュー
・統計ダッシュボード
・記事へのPRバナー
など他にも続々機能拡張するとのこと...!
年間99,800円です。
テックブログ執筆の工数や、
採用費用、技術広報の予算全体と比較すると、
月8,000円は全然ペイするな、という所感です。
⑦スタンプでネタ収集
ネタは他人目線のほうが見つかりやすい、と思っています。
「各種リリース報告や各種スレにてネタ発見→収集」
というスパイラルを目指してます。
正直これはまだ始めたばかりで運用乗り切っていないので、
これから浸透していけたらと思っています。
⑧非エンジニアもガンガン書いてく
デザイナーやDevRelやら。
一緒に仕事するビジネスサイドも巻き込む。
私も非エンジニアですが月1くらいで書いていけたら良いですね～
先月書いた記事↓
まとめ
技術広報担当者は、読まれる責任を負っているのか
「書かせること」よりも、「書いてくれた価値ある何かを誰かに読んでもらうこと」に、
もっと目を向けないとなあ、と自戒も込めて思いました。
「書きたいものを書け」と言いつつも、読まれないものは書き続けられないと思います。
書きたいものを書いてもらった上で、「できる限り読まれる努力」は運営の責任としていこうと思います。
テックブログも、プロダクトマネジメント
広義の「プロダクトマネジメント」と見立てると色々考えが捗るなあと思いました。
まだ考えまとまっていませんが。
「ドキュメント」それ自体をプロダクトと捉えたときに、
ユーザーは読者。著者がサービス提供者側。
厳重なレビューでコネコネ検討するよりも、
多少雑でも良いからに市場に出して、
FBを得て、また次の記事を書く。
そのサイクルを高速化していけると、最終的によいドキュメントが生まれていく。
ライター自身の学習効率も上がっていきますし。
必ずしも市場に評価される必要はないので注意ですが。
一方、「テックブログ」をプロダクトと捉えると、
ユーザーは著者。編集長や運営がサービス提供者側。
いかに書きやすくするか、気持ちよく書いてもらうか、書く前後の体験を良くするか。
書く人が「何書けば良いのか」がパッとわかるテックブログは、いいテックブログだなと思います。
そのためにも、テックブログの思想やコンセプトがあると良いなと思います。
余談：社内施策はサービスと考える
社内の尊敬するデザイナーが
社内向けの施策は「社員＝ユーザーに向けたサービス」と考える
と言っていました。
「社員だから頑張れよ」に甘えずに、
サービスのユーザーとして捉えたUX的思考が必要だなあ、などと思いました。
反応
反応も上々でよかったです！
またLT大会で会いましょ～
登壇スライドはこちら
ウィアハイアリング
技術広報専任/兼任ともに積極採用中です！
JD・求人すら作れていませんが、興味ある方DMください！
Discussion