テックブログ立ち上げから１年間の取り組みと学び：「編集チーム」としての試行錯誤をふりかえる

はじめに

エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」の開発をしている @koma_koma_d です。エンジニアとしての職務の傍らで、このテックブログの編集チームメンバーを務めてきました（「編集チーム」が何かについては後述します）。

当ブログは、2021年3月に開始し、この3月でちょうど1年になりました。この1年間のブログ運営では、うまくいったこともありましたし、うまくいかなかったこともたくさんありました。今回の記事では、この1年間をふりかえることで、「企業のテックブログに携わる人たちに役立つ情報を提供する」ことができればと思います。

ブログの始まりと編集チームについて

編集チーム発足まで

テックブログを開設しようという考えは、実際に始動されるだいぶ前からあり、マネージャーなどが中心となり準備を進めていました。企画の検討や、ブログとは別にある採用スライド資料の作成などはこの段階からされていました。

しかし、マネージャー陣だけではブログの持続的な運営は困難ということで、2021年1月に私を含む3名に声がかかり、「編集チーム」が組成されることになりました。このチームの主な役割は、ブログの記事制作を担うことです。ブログを始めるのは簡単ですが、継続するのは困難です。記事を執筆してくれる人を探し、執筆が始まった記事を公開まで導くというのは、労力を必要とすることだからです。記事を一定以上のペースで公開していくためには、記事のデリバリーに責任をもつチームが必要だと考え、編集チームが発足しました。

編集チームの発足とブログの始動

編集チームのメンバーは、それまでに進行していたコンテンツ案のそれぞれを「担当編集」として引き継ぎ、執筆担当者の書いた原稿のレビューやスケジュール管理、実際のブログ公開作業などを担うようになりました。

そうして、いよいよ2021年3月にブログが始動しました。最初に公開したのは、Ruby コミュニティなどでも活動してきた技術責任者の @sunaot の記事2本で、幸いなことに、いずれの記事も広く読んでもらうことができました。

tech.bm-sms.co.jp

始動してから取り組んだこと・工夫したこと

さて、以上のようにスタートしたこのブログですが、ブログを始動させるタイミングでは、記事自体をデリバリーすることを優先して、コンテンツ以外の部分（デザインや運営の仕組み）は作り込まずに始めました。ここからは、始動してから取り組んだことや、始めた工夫について紹介します。

ブログデザインを刷新する

ブログのデザインは、始動から少し経った5月に、社内のデザインチームに作ってもらったものに切り替えました。始動の前には既に「デザインどうする？」という話は出ていたのですが、「まずはブログとしては始めてしまおう」ということで、このタイミングでの刷新になりました。

「エス・エム・エスって見たこと/聞いたことある会社だな」と思ってもらえるようにしたいというのが目的のひとつなので、早い時期にデザインをコーポレートカラーに合わせたものに変更したのは良かったと思っています。ただ、アイキャッチ画像との平仄が合っていないという問題がつい最近まで存在していたので、もっと早く変更できていればという思いはあります。

定期的なふりかえりを実施する

デザイン刷新と同じころに、月次での「ふりかえり」も始めました。

開始当初は Google Analytics を入れるだけ入れていたという程度で、とにかく記事をリリースしていくということに専念していたのですが、軌道に乗ってきたため、試行錯誤ができるように月次でふりかえりをチームで行うことにしました。

このふりかえりでは、記事のデリバリープロセス全体についての改善を模索するのですが、その一環として、前月に公開した記事を中心に、 Google Analytics などでさまざまなメトリクスを確認しています。記事はそれぞれがユニークなので、どのような記事（内容だけでなくタイトル・アイキャッチなどを含めて）が読まれやすいのかなどを分析し、試行錯誤を重ねるようにしています。

例えば、以下のようなメトリクスを確認しているほか、気になる動きが Google Analytics 上で見られれば細かく「どうしてそうなっているのか」などを掘り下げたりもしています。

ブログ全体での月間ユニークユーザー数
ブログ全体での検索流入ユーザー数
記事別の訪問数
記事別の検索流入数
Search Console での特定キーワードでの順位

執筆してくれた人の労に報いる

ブログの継続のためには記事を執筆する人が不可欠です。記事の執筆をお願いしてきた人たちはみなさん協力的なのですが、そうはいっても記事を書くのは大変なことです。1本の記事がそのまま何かの成果（代表的なのは採用）に結びつくことはそうそうないのですが、執筆担当者が「書いてよかった、また書いてもいいな」と思ってもらえるように配慮しています。

たとえば、記事を公開したときには、Slackのエンジニア全員のいるチャンネルで編集チームメンバーから一言添えて共有しています。RSSフィードの機能で配信する手もあるのですが、あえて手動で投稿しています。

執筆者と一緒に記事を作ってきた編集チームメンバーはその記事の良いところを一番よくわかっていますし、執筆中の執筆担当者の苦労も知っているので、他の人にも見えるところで執筆担当者に感謝の意を伝えるとともに、社内の多くの人にその記事の魅力を伝えるという役割も担っています。

始動後に出てきた課題とそれへの対応

ブログを始めてから出てきた課題もたくさんあります。前述のふりかえりの場や、ブログ運営用の Slack チャンネルでの話を通じて、課題に対して手を打っていきました。ここでは一部ですが、取り組んで良かったと思うことを紹介します。

始動後に速やかに増員を行った

3人体制で始まった編集チームでしたが、2ヶ月くらい経ったタイミングで、「結構これは負担が大きい」という声が上がり、編集チームの人員増強を行うことになりました。

それぞれが所属チームでのエンジニアとしての仕事も抱えていたため、所属チームでの仕事がばたつくと記事のデリバリーにも影響が及んでしまうという難点もありました。

この段階で即座に @sunaot が追加で3人のエンジニアに声をかけ、6人体制になりました。6人体制になったことで、障害対応や体調不良、重要なプロジェクトなどでメンバーの一部が欠けた際にも、補い合って記事をデリバリーし続けることができましたし、一人当たりの負荷が減って続けやすくなりました。

また、人数が増えたことにより、それぞれの人が持っているスキル（Google Analytics の読み方など）や、それぞれの人の近くにいる「いい記事を書いてもらえそうな人」の情報の情報が共有されるようになったのも、ブログ運営にとっては有益でした。

マクロのメトリクス以外のフィードバックを得るようにした

前述の通り、ふりかえりの場では、Google Analytics などのメトリクスを見ています。それらのメトリクスは、「記事がどれだけ読んでもらえたか」などといったマクロの傾向を把握するのには有益なのですが、「読み手に対してどういう影響を与えたのか」などはこれだけではわかりません。

そこで、エンジニア採用担当者や面接担当者から、「ブログを読んでもらえているか」や「ブログに対してどのような声があったか」などを共有してもらうようにしています。そうしたフィードバックを得ることで、「ブログを通じてどのようなことを伝えていく必要があるのか」を考える自分たちでも気づいていなかった「エス・エム・エスの特徴」を発見することもありました。

「むきなおり」を行うようにした

前述のように、「ふりかえり」は定期的に行い、「これまでの記事・取り組みはどうだったか」「次はどういう取り組みをすればいいか」という議論は常にしていました。しかし、どうしても限られた時間の中で実施しているため、もう一段抽象的な「何を目的として、どこを目指して行動をしていくのか」というレベルの議論をする機会は作れていませんでした。

その結果、始動のタイミングでは全員で話をしてある程度は合わせていたはずのチームとしての方針に対する理解が、時間の経過とともにバラバラになってしまい、コンテンツを考える際などの議論がまとまらないという場面が出てきました。

そこで、普段のふりかえりとは別に、「むきなおり」の時間を設けるようにしました。その場では、「ブログでどのようなことを目指しているのか」といった全体に関わる事柄を改めて話し合います。その中で、コンテンツ作りの方針や、ブログ運営の体制など、見直していくとよさそうな点を見つけられたので、一つ一つ改善していこうとしているところです。

ブログを運営する中でわかってきたこと

最後に、ブログを運営する中でわかってきたことを紹介します。

バズる記事だけが重要ではない

上記のようにふりかえりをしながらブログを運営していく中で、公開するコンテンツの位置付けについて少しずつ自覚的になってきました。

記事のなかには、SNSで「バズる」記事もありますが、ほとんどの記事はそうではありません。しかし、バズりはしなかったけど検索流入がありつづける記事や、広く読まれるわけではないが特定の読み手に刺さる記事（スカウトを送る際などに、その人に読んでもらうと良さそうな記事を添付したりしています）にも意義があるということが見えてきました。

また、ブログ全体としての記事の積み重ねによって会社のイメージが形成されていく（「エス・エム・エスさんはこういう記事が多くて、〇〇を大切にしている会社なのだなと感じました」というフィードバックをもらうことが繰り返しありました）という側面もあるということも発見でした。

編集チームでの仕事には副産物がある

編集チームのメンバーはエンジニアリングの仕事の傍らでブログ運営の仕事をしているのですが、ブログ運営を通じて得られる副産物がありました。この種の仕事はともすると「本当はエンジニアリングにもっと時間を使いたいのに」と敬遠されがちですが、以下に書くような副産物があると、ブログ運営に関わるインセンティブにはなりそうです。

他事業・他チームのエンジニアとの関わりが得られる

エス・エム・エスは、40を超えるサービスを運営しており、エンジニアは（多くがプロダクト開発部という横串組織に所属してはいるものの）普段は担当するサービスのなかで仕事をしています。Slackでの雑談・勉強会や、社内のテックトークイベントなどで関わる機会もあるのですが、ブログ編集チームメンバーを務めることでこれまでにはない他事業のエンジニアとの関わりが生まれました。

まず、編集チームの他のエンジニアです。編集チームは、記事コンテンツ案を考える都合などもあり、様々な事業のエンジニアの混成チームとなっています。事業ごとに扱っている技術スタックもビジネスモデルも異なるので、そういったチームで一緒に仕事をしていると、新たな発見がしばしばありました。例えば、私は担当している事業が介護事業者向けのSaaSで、基本的にはログインした後の世界を主戦場としているのですが、人材紹介のサービスを担当しているエンジニアは集客の部分にも強みがあり、SEOやGoogle Analytics などの扱いに慣れているので、ブログの運営面では学ばせてもらうことが多かったです。

また、執筆担当者のエンジニアとの関わりも貴重でした。記事の中には、執筆担当者単独で書けてしまうものもありますが、編集チームメンバーと執筆担当者が二人三脚で進めていくものも多くあります。その場合、打ち合わせや非同期でのコミュニケーションを通じてコンテンツを作っていくことになるのですが、その過程でのやりとりで（最終的な記事には表れないような）裏話や、技術の詳細について話を聞くことがしばしばありました。執筆担当者はシニアなエンジニアであることも多いので、そういった話を直にきけるのは「役得」でした。