この記事は RevComm Advent Calendar 2022 の 3 日目の記事です。前日は持田さんの「生産性の高い定例会議を行うための準備と進め方」でした。
はじめに
こんにちは小島です。普段はサーバーサイドエンジニアとして MiiTel for Zoom の開発をしています。同時に、僕はこのブログ (RevComm Tech Blog) の管理人もしています。
今回は RevComm のチーム紹介のひとつとして、テックブログを運用するチーム体制や取り組みについて書きます。
体制の紹介
まずは体制です。RevComm ではテックブログは編集部制をとっています。つまり、企画の立案・執筆者のアサイン・スケジュール管理などを担うチームがあり、全員エンジニアで構成されています。現在、チームメンバーは 4 人です。
社内ではテックブログ運営と呼んでいるので、この記事でもそう表記します。
このテックブログ運営を立ち上げている時期に、僕が「我々は何をするためにいるのか」をスライド一枚でさっと定義しました。
簡単にいうと、読者に記事を届けるためにやれることはすべてが仕事であるという定義です。
この定義のもとで、大きく 4 つの仕事をしています。
- 読者に興味を持ってもらうために、記事の内容をよりよくする（ネタ出し・企画立案）
- 読者に信頼してもらうために、記事を定期的に公開する（執筆スケジュール管理）
- 読者に不信感を与えないために、記事の内容を校正する（原稿のレビュー）
- 読者と接点を持つために、SNS などで更新の発信をする
重要なことは、どの仕事も読者を起点にしていることです。読者にとって意味のあることでなければ、我々の仕事ではありません。これは当たり前ですが、重要なことです。
運営としての活動
運営は主に次の 3 つの活動をしています。
- 定例会議（毎週）
- 企画会議（月1程度）
- オフィスアワー（ほぼ毎週）
定例会議
弊社では、Asana というタスク管理ツールを全社で採用しています。記事の管理には、 Asana のボード（カンバン）を利用しています。
このボードを見ながら、執筆やレビューの状況などを週次の定例会議で管理しています。経験上、毎週必ず実施することが、進捗管理にとって最も効率がよいと感じています。
というのも、テックブログの執筆や運営は優先度がどうしても下がりやすい業務内容だからです。僕も含めて運営メンバーは普段プロダクトの開発などをしているので、ロードマップ実現やバグ修正などと比較すると、どうしてもブログ運営の仕事は後手に回りがちです。
そこで、毎週約 30 分の定例会議の時間を設けることで、その 30 分は自分たちが運営としての仕事について考えたり、忘れていたことを思い出したりします。1 回の時間は短くてもよいですが、毎週記事の進捗状況をチェックすることが重要だと捉えています。
企画会議
定例会議とは別に月に 1 回程度、企画会議を実施しています。
定例会議では記事の進捗などの細々とした確認ごとに終始してしまうので、新しい記事や読者に僕らが伝えたいことは何か？という視点で物事を考える時間を取っています。
実施した実績はまだ少なく、会議体としてはまだ模索中です。
企画会議という名前にはしていますが、記事の企画のブレストだけをテーマにするのはよくないなと考えています。すべては読者のためであるという原則に立ち戻り、運営としてどのような取り組みをするべきかや、読者や執筆者のための取り組みについても考える時間にしています。
そこで出てきた取り組みのひとつがオフィスアワーです。
オフィスアワー
企画会議で、運営として記事の執筆者のサポート体制を作ることがいいのではないかという意見があがりました。そこで、ある運営メンバーに主導してもらい、毎週 1 時間オフィスアワーを開催することにしました。
一般的にオフィスアワーは大学でよく使われる用語で、教員が生徒からの質問などを受け付ける時間のことです。テックブログ運営では、技術記事や社内ドキュメントに関する相談を受け付ける場としてオフィスアワーを定義しています。
RevComm では、社内会議は主に Google Meet を利用しています。毎週決まった時間（現在は水曜の16:00）に Google Meet に集まり、執筆者の質問に答えたり、記事の構成の壁打ちをしたりしています。
また執筆者に限らず、ブログについてよもやまな質問や相談も受ける場としても機能しています。
執筆をしてもらうために
執筆者とのコミュニケーションは最も重要な仕事のひとつです。そして、人と人とのコミュニケーションなので正解はありません。執筆者によって、組織によってやるべきことは違うと思います。
とはいえ、ほとんどの状況で間違っていないと僕が確信しているスタンスがいくつかあります。この記事ではそのスタンスを 3 つ紹介します。
「あなたに」書いてほしいという旨を伝えること
企画を考える時、多くの場合は執筆者をセットで考えます。
「この記事をあなたに書いてほしい」と依頼するときに、なぜ「あなた」が選ばれたのかを説明できることが重要ですし、何よりそれが企画のキモだと思っているからです。
例えば「チームのオンボーディング内容を紹介する記事を書きたいです」と言うのと、「若手エンジニアから見たチームのオンボーディング体制をテーマにした記事を書きたいから、25 歳のあなたに書いてほしいです」と伝えるのとでは、執筆を依頼された人の納得感が違うでしょう。
そして記事のネタと執筆者がマッチしていることは、記事の品質に直結します。組織論を入社 1 ヶ月のメンバーが書くことはできませんし、採用活動などで多忙なマネージャーに最近得た技術的な学びを書いてもらうのもズレた記事になってしまうでしょう。こんな記事があればよさそうだというアイデアに対して、誰が一番そのアイデアをよりよく昇華してくれるかを考える、それが企画だと思います。
そして企画を深く考えられるからこそ、エンジニアがテックブログの運営をやる意義があると思っています。
執筆者をリスペクトし、讃えること
最初依頼から記事の完成まで、執筆者をリスペクトすることが大事だと考えています。
運営は依頼をする立場です。へりくだるのもまたおかしいですが、一緒に記事の作成プロジェクトを進める仲間だととらえ、プロダクト開発のチームメンバーに接するのと同じように接するのがよいと考えています。
また、公開後は執筆者を讃えます。記事の公開当日は社内の Slack で更新を通知し、みんなで讃えます。これに加えて、月に 1 度行われるエンジニアの全体会議で記事を執筆いただいた方の名前を挙げ、感謝するようにしています。
記事の執筆は大変な仕事です。それを完遂した方には、重ねて感謝しましょう。
無理をさせないこと、やれる人にやってもらうこと
最後に、お互い無理にやろうとしないこと、やれる人にやってもらうことです。これが個人的に最も重要視していることです。
技術記事を書くのは簡単なことでしょうか？特にブログを運営するような人や日常的に記事を書いている人であれば、「記事なんて誰でも書ける」とさえ思っているかもしれません。
しかし、そんなことはありません。どんな文書も訓練しないと書けないし、適性もあるでしょう。また、普段から記事をよく書いている人でも、事業にインパクトのある仕事をしているときにブログ記事の執筆を優先することは難しいでしょう。誰でも指名すれば記事のひとつくらいは書ける、というのは暴論だと思います。
そして重要なことですが、発信の方法は文書執筆がすべてではありません。社内でアンケートを取ったところ、文書執筆は苦手でも登壇には意欲がある人や、スライド作りには苦手意識がない人もいました。要は、人には向き不向きがあるのです。文書執筆が得意ならテックブログで、人前でしゃべることが好きならイベント登壇で、ソフトウェア作りが得意なら OSS という形で発信してもらうのが一番いいと思うのです。
テックブログには採用広報メディアという性格もあります。採用のために何が伝わるといいのかと考えれば、僕らエンジニアが楽しく働いていることが伝わるのが一番だと考えています。とすると、無理にブログを書いてもらうことはむしろ逆効果になりかねません。
体制が未熟でブログ以外の発信の場をまだ用意できていませんが、2023 年はブログ以外の場を用意することを考えたいと思っています。
終わりに
テックブログは立ち上げ初期からこの体制で運用し、少しずつ軌道に乗ってきました。最初こそ大変でしたが、徐々にテックブログは社内でも浸透してきて、最近では企画案を持ってきてくれる人や、執筆の立候補をしてくれる人も増えてきました。
立ち上げ期は越えましたが、ブログの性質上これからも継続していくことが何よりも重要です。今後もよりよい発信ができるように運営として改善していきます。そして社内の取り組みを楽しく発信できるメディア運営を目指していきます。
RevComm ではエンジニアを募集しています。このブログを読んで興味を持ってくれた方、参加したいと思ってくれた方もぜひ採用サイトをチェックしてみてください。
