約5ヶ月運用したテックブログの立ち上げとルールづくり
note社では今年（2022年）の8月末あたりから、技術記事を週1回更新をしています。
▲技術ブログはこちら
当たり前ですが、週1で回すためには社内のエンジニアの力が必要不可欠です。そして、技術記事を書いていくための体制構築やルールづくりが必須になります。
note社の運用ルールもまだまだ改善の余地はあるのですが、なんとか11月までは円滑に週1更新で進めることができました。（12月はエンジニアアドベントカレンダーがあるので運用停止中）
まだ始まってから数ヶ月の運用ではあるのですが、知見が少しずつ溜まってきたので、現状のルールについて記録を残しておこうと思います。
※ こちらは 1人で25日書く技術広報 Advent Calendar 2022の7日目の記事です。今、この記事を公開している時点から10日先を考えるとネタがなさすぎて怖いです。
前提1：記事がストックなのかフローなのか意識する
「技術記事を書く」となると「バズる」思考になりがちですが、すべての記事がバズる必要はありません。例えば、個人へのインタビューなどはまさにその好例で、「採用者に向けて書く」ことの意識が重要です。
この目的設定が誤っていると、誰に届けるべきなのか曖昧になってしまいます。
執筆している記事が「採用者に響くためのストック情報」なのか「バズるためのフロー情報」なのかを意識することが大事なのです。
技術広報がこれらの前提を意識していなければ、バズるバズらないの尺度でしか判断できなくなってしまいます。数値だけを追い求めると辛くなっていき、運用自体を止めることにもなりえるでしょう。
エンジニアが発信すること自体に意味があります。エンジニアの発信を広めて最大化することこそが技術広報の一つの仕事なのではないでしょうか。（私の現在の課題でもあります）
前提2：経営層と合意をとる
上記の記事でも書いたのですが、運用を始める前に技術ブログを進めていくことの合意をとりました。また、「技術記事をタスクとして、業務時間内に書いてもOK」というルールも握りました。
以下が技術広報としてのスタンスです。
技術記事の執筆をエンジニアに依頼 / 相談する
技術記事の執筆は業務として扱う
今まで自発的に取り組んでいた方は引き続き自由に書いてOK
記事のレビューは実施する
レビューする際の強度を事前に決める
文章をいじられたくない人は誤字脱字の確認のみにする
必ず全員に周ってくるものではない
業務時間に執筆ができるという前提があれば、依頼する側も執筆する側も気持ち的に楽になる部分があります。
実際に運用してみると、エンジニアから「業務時間に書いてもいいんですか？」と聞かれることが何度かありました。曖昧なことははっきりと線引することで、作業が進めやすくなる部分があるのかなと思います。
記事執筆に興味のない人にとっては業務時間を使って良いという前提が付いたとしても魅力的に感じない可能性を考慮に入れるべきです。
ただし、業務時間に書けることを全員が喜ばしく思っているとは限らない点には注意が必要です。（他部署から見ると、エンジニアだけが優遇されていると思われる可能性もありえます）
あくまで「ルールを決めたことで社内で動きやすくなる」という精神面でのハードルを下げる効果があるのかなと考えています。
掲載媒体について
基本的にはエンジニア個々人のnoteアカウントで公開してもらっていますが、QiitaやZennでの公開もOKとしています。また、匿名で書きたい人がいた場合には公式アカウントからの投稿も可能にしています。
▲最終的には上記のエンジニアサイトにまとめていく
記事公開までの流れ
記事公開までの流れは以下のようにしています。
最低でも公開の1ヶ月前には技術広報から依頼 / 相談
ネタ自体をこちらから提案 or 書けるものがないか相談
締切の1週間前になったら進捗確認
記事が書けなそうであれば、ペアブロギングなどを実施
記事が完成したらレビュー
公開
ごくごく普通の公開フローですが、工夫している部分があるので、いくつか紹介します。
- 執筆前の事前ヒアリング
記事を書く前に、先にエンジニアへは事前のヒアリングを行っています。
エンジニア個々人で方針に違いがあるため、事前に簡単な認識合わせをすることで円滑に進められるようにしています。
- ネタの提案
依頼するときには具体的なネタの提案をなるべくするようにしています。
エンジニアの中には、「自分がやってきた仕事がおもしろいとは思えない」という意見を持っている人もいます。
記事を書くほどのことをしていない
周りと同じように業務をこなしているだけ
新しい発見がない
外部公開するほどのことがない
他社で公開している技術記事のようなことが書けない
そんなに文章量があることをしていない
自分の開発が未知の技術領域に挑戦しているわけではない
他にもあるかもしれませんが、社内でヒアリングする限りでは上記のような理由が多くでてきました。
たしかに、先進的な技術記事を書くためには「誰が見ても新しい技術的なチャレンジ」は必要な視点です。しかし、「まったく同じサービスをつくる経験」はできません。サービスをつくること自体が新しい挑戦であり、他社のエンジニアからすれば未知なる領域です。
ですので、エンジニア自身がネタを見つけるのではなく、こちらから「あなたの開発はおもしろいですよ」と伝えるのも必要なことだと考えています。
- 締切について
レビューするための締め切り日と記事公開日を1週間ずらしてそれぞれ伝えています。
日程をずらすことでレビューをじっくり行うことができますし、締切に遅れていても予定を合わせやすくすることができます。
- ペアブロギング
私も知らなかったのですが、ペアプログラミングのように一緒に作業を進めていくペアブロギングという手法があります。
まだ実際にはやったことがない（エンジニアは基本的に執筆能力が高い）のですが、書けないときのための救済措置はいくつか用意しておくべきでしょう。
- レビュー体制
レビューを行うのは以下の3名です。
技術広報
記事の確認 / 編集
EM（エンジニアリングマネージャー）
技術的な誤りがないかの確認
PR
最終的なPRチェック（出してはいけないものがないか）
レビュー層が厚く感じるかもしれませんが、基本的には技術広報でだいたい完了させる予定です。
EMとPRにはそれぞれの視点での誤りや危険な表現がないか、確認だけをするようなイメージです。
まとめ：実際に運用してみて変えていく
いくつか執筆するためのルールを書いてきましたが、運用してみるとやはり穴があることがわかります。
ルールづくりを詳細に行うことも大事ですが、粗いルールでもまずは走り出してみて進めてみるのがいいのかなと思います。
ただ、体制が粗すぎると執筆に不安が生まれてしまうため、記事を書く目的やレビュー体制などは決めておくべきだと思います。（初めて書いてもらうエンジニアに実験として書いてもらってから、運用ルールを固めていくのもありなのかなと思います）
また、note社としてはまだ発信の体制ができただけの状態です。ここからその発信をどう広めていくのかが課題です。「noteが技術記事を定期的に出している」ということを様々なエンジニアに届けていく仕組みが必要です。届ける仕組みについては、今期の私の課題だと思っています。
最後になりますが、テックブログはエンジニアの協力して成り立ちません。また、テックブログの運用は技術広報の功績ではないと思っています。周りの力を借りて初めて進めることができる施策なので、そこを勘違しないように進めていく心構えが必要かなと思います。（自戒を込めて）
▼技術広報の記事をさらに読みたいかたはこちら
▼他社事例
この記事が気に入ったらサポートをしてみませんか？