NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

エンジニアの私が技術広報として意識していること

本記事は  技術広報Week  3日目の記事です。
👩‍💻  2日目  ▶▶ 本記事 ▶▶  4日目  📈

こんにちは、古田です。

今日は私が所属する技術広報チームの紹介と、自身のチーム内での経験について書かせていただきたいと思います。

技術広報チームについて

NRIネットコムの技術広報チームは、メンバー全員が現場業務の傍らで活動を行っており、本業はAWSソリューション事業の推進Webシステム開発のPMデジタルマーケティングコンサルまで様々です。また、仕事以外にも、はてなブロガーやツイッタラー、技術書執筆者など様々なバックグラウンドを持つメンバーがいます。

二足の草鞋での活動は時間的な制約や苦労も多いですが、その分、メンバーの持つ多彩な知識・経験を集結し、試行錯誤しながら推進しています。今回のブログイベント『技術広報Week』では、そういった技術広報チームの多彩なカラーもお伝えすることができれば幸いです。

自己紹介

私の専門はWebアプリケーションエンジニアですが、現在は開発プロジェクトのPMやスクラムマスターという立場が中心です。クセ者 強者揃いの技術広報チームの中で、自分なりに貢献できることは何かなと考えながら活動してきました。前置きが長くなりましたが、今回はそんなエンジニアの私が、技術広報チームとしてブログ運営等で意識してきたことを書いていきたいと思います。

攻めの意識

ともかくテックブログは記事執筆の協力者で成り立っています。0から始めた活動を広げるためには、記事数・執筆協力者を増やすという攻めの姿勢が大事です。とはいえ、ガンガン行こうぜ!というノリだけで執筆活動の輪は広まりません。大切なのは「書いて良かった」と執筆者自身に思ってもらうことではないでしょうか。開発者体験もとい執筆者体験の重視です。これがあるチームには自然と仲間が増えていくものだと、普段の開発現場でも実感しています。

ピアレビュー

記事は必ずレビューを経てから公開されますが、このレビューというものが、特にレビューイにとって非常にストレスフルなものだということは、システム開発に関わる人はよくご存じかと思います。

このストレスの原因のひとつは「シニアとジュニア」「委託元と委託先」といったレビューアとレビューイの関係性からくるものです。「ブログ運営側と執筆協力者」がこういった関係になることは、絶対に避けたいと考えています。レビューの仕組みづくりについては1日目の佐々木さんの記事でも触れられていますが、ここではもう1点、個人的な工夫として、ピアレビューの考えを挙げてみます。

具体的には、執筆協力者が集まるSlackチャンネル上で、誰もが自由に公開前の記事を読み、気付いた点があればコメントします。運営チームも一読者としてコメントをします。執筆者でもあり読者でもあるという、全員が同じ立場になってレビューをしあうことで、レビュー工程でのストレスを軽減できるように努めています。

本記事のコメントの様子

フィードバック

2つ目は、執筆者へのフィードバックです。せっかく手間をかけて書いた記事は読んで欲しいものだと思いますし、それが書いてよかった、次も書こうというモチベーションに繋がります。

上で書いたコメントを付け合うレビューでは、レビューアとしての指摘よりも、読者としての感想のコメントを意識しています。「みんな興味を持って読んでるよ」という事実を執筆者が実感できる仕組みです。

他にも、はてなブックマークやTwitterでの反響などを日々ウォッチして、運営チームが気が付いたものは、できる限り執筆者にお伝えするようにしています。

Twitterでのリアクションの共有の例

守りの意識

企業の広報として情報発信する上では、守りを意識する必要もあります。「炎上」やセキュリティのリスクなどは避けては通れない課題です。

炎上しないために

前章に書いた「レビュー」も炎上リスクを減らすための施策の一つですが、私がレビュー時に気を付けている視点の一つは、その記事を読んだ人の中にモヤっとした感情を抱く人がいないか?という点です。

攻撃的な内容の記事が炎上するのは誰もが予測できると思いますが、テックブログでまさかそんな記事を書く人はいないのではと思う方も多いでしょう。しかし、技術系の記事であっても、例えばレガシーな技術をネタにしたり、ある言語とある言語の対立を煽ったりなど、エンジニアの拘り故に、無自覚的に特定の分野やそれに携わる人たちへの攻撃性を持ってしまうことも珍しくありません。

執筆者本人だけでは気付きにくいポイントを、幅広い読者の視点を想像しながら読んだり、また実際に社内の幅広い立場の人に読んでもらうことで、事前に摘んでいく必要があります。

アカウントセキュリティ

2つ目はアカウントセキュリティです。技術広報チームでは、本ブログの他にもSNSやイベントプラットフォームなどのWebサービスを運用していますが、個人利用と同じ感覚で企業アカウントを取得し利用してしまうと、システムでいうところの「rootユーザーを共有」している状態になり、セキュリティ的にはご法度です。

企業アカウント本体と別に、執筆者など利用者個人ごとのユーザーアカウントを設けた上でサービスを利用させるというのは、システム設計においては基本のキですが、こういった活動では案外疎かになりがちなポイントです。

はてなブログであればブログメンバー機能、TwitterなどのSNSは専用のツールを利用することで、これを実現できます。弊社ではマーケティングオートメーション(MA)ツールを利用して、企業アカウント本体と利用者アカウントの分離や承認フローを実現しています。他にもログイン時の多要素認証(MFA)の徹底など、セキュリティエンジニア的な目線でサービス運用の守りを固めています。

見るだけで恐ろしい、絶対にダメなパターン

おわりに

「エンジニア、技術広報ナニモワカラナイ」から始まった活動でしたが、「PR」「広報」「マーケティング」とは何かを理解して自分なりの「技術広報」の定義を考えたり、またGoogle AnalyticsやSearch Consoleを触ってLooker Studioを作ったりと、これまでのキャリアで未知だった分野について、頭と手の両方を動かして新鮮な経験ができたと思っています。

ブログ執筆協力の輪や、技術広報活動の輪を、これからもさらに広げていけるよう頑張っていきたいと思いますので、引き続きNRIネットコムBlogイベントへのご支援をよろしくお願いいたします。

執筆者古田 拓也

たぶんシステムアーキテクト。
デスクトップアプリが専門でしたが最近は何でも屋

X