2年間の開発者ブログ運営のノウハウや意識してること

みなさんこんにちは、イノベーションセンターの @Mahito です。普段は社内のエンジニアが働きやすくなることを目標に、コーポレートエンジニアとしての活動やエンジニア向けイベントの企画・運営をしています。

今回は、本 NTT Communications Engineers' Blog を2年間運営してきたノウハウについて共有できればと思います。先日はてなブログ DevBlog Meetup #1 に登壇させていただく機会があり、ブログ運営に関していくつかお話しさせていただいたのですが、イベント当日に言えなかったことや言ったことの補足などをできればと思います。

開発者ブログのこれまでと目的

開発者ブログの運用ノウハウをお伝えする前に、少しだけ本ブログについてのお話をさせていただきます。

こちら「開発者ブログをリニューアルしました!」でも書いたのですが、NTT Com では元々2015年に6月頃から開発者ブログを開始しました。当時はCMSを自分たちで運用していくスタイルでしたが、CMSの使い勝手やレビューのしづらさなどもあり、リニューアルという形ではてなブログへと引っ越しをする形になりました。

エンジニアブログをリニューアルする際には、開発者ブログに以下のような目的を定めました。

NTT Comのエンジニアの取り組みを広く知ってもらう
社外のユーザーやエンジニアとコミュニケーションをとれるきっかけの場とする
NTT Comのエンジニアが自己発信できる場を提供する

NTT Comにはさまざまなエンジニアがそれぞれの仕事をしていますが、その多くは外部には見えません。例えば、NTT Comのニュースリリースを見ても、技術の詳細などは書かれていません。そのため、リクルーター活動などをしていると、NTT Comのエンジニアが何をしているのか社外に知られていないと感じることが多くありました。

一方で、エンジニアの中には自分たちの取り組みを知ってもらうことで、社外のエンジニアやユーザーと繋がり、そこから採用や新規ユーザーの獲得に繋げたいと考えている人もいます。しかし、社外のエンジニアやユーザーとの交流のきっかけや、自分たちで発信する場があまりないという問題がありました。そこで、開発者ブログを通じて、これらの問題を解決できるようにしていこうとなりました。

運用のノウハウ・意識していること

執筆者の確保・継続・インセンティブ設計

NTT Comでは、ブログは書きたい人が書くというスタイルを取っています。これは、持ち回りで定期的に記事を出すということよりも、書きたい人のやる気を優先することでいい記事が生まれ、いい結果につながるのではというような話だったと思います。（運営の中で全然議論にならなかったのでうろ覚えです）

おかげで1ヶ月近く新しい記事がでないこともありますが、タイミング的にまだ公開できない未公開記事や、「書きたい！」と言って準備してくれている人が常にいる状態のため、運営スタッフは「今週もでなかったね〜」ぐいらいのノリで焦りは特にありません。

新規の執筆者をどう確保するのかという点では、以下の3点を意識しています。

定期的にブログの取り組みを社内に紹介することで取り組みに興味を持ってもらう
ニュースリリースを見て、技術的に面白そうな取り組みをしているところに声をかける
執筆のハードルを下げる

1. 定期的にブログの取り組みを社内に紹介することで取り組みに興味を持ってもらう

社内でもまだまだ開発者ブログに取り組んでいることを知らない人もいるため、社内での開発者ブログの認知を上げることや、そのタイミングではブログのネタがなく興味を持たなかった人に再度知ってもらうことで書くきっかけにつながればと思っています。社内に紹介する方法としては、社内ポータルの周知に「今月どんな記事が出たかのまとめ」を掲載したり、新しい記事がでたら Slack や Microsoft Viva Engage（旧称 Yammer）に自動投稿したり、社内のイベントでブログの活動を紹介したりとさまざまです。

2. ニュースリリースを見て、技術的に面白そうな取り組みをしているところに声をかける

我々運営スタッフも社内のすべてを知っているわけではないので、運営の定例などで NTT Com のニュースリリースをチェックし、技術的に面白そうな取り組みをしているところに連絡をしています。こちらの「駆け出し開発チームでも45万回利用されるシステムを2カ月で作れた話」はニュースリリースを見て、運営から声をかけさせてもらった記事です。個人的にはプロジェクトのはじまるきっかけなど、ニュースリリースに書かれていない部分も知ることができとてもいい記事でした。

3. 執筆のハードルを下げる

執筆者のハードルを下げる取り組みは、「執筆したいけどできない」とか「こんなこと書いていいのかな」という問題を解決することです。

前者は、稼働の問題や周囲の理解、技術的な問題など、さまざまな理由がありますが、副社長や幹部に開発者ブログの活動にお墨付きをいただいています。何か問題があれば「偉い人の承認を得ている取り組みですよ」ということができます（使ったことはないけど）。

また、後者に関しては、運営スタッフが色々サポートできます。例えば、NTT Comの開発者ブログでは、記事はMarkdownで記載され、GitHubを利用して記事の管理やレビューをしています。執筆者の中には、これらに慣れていない方もいますが、運営スタッフがサポートして記事が書けるようにお手伝いしています。

「こんなこと書いていいのかな」という疑問に対しては、運営スタッフが相談に乗ることもあります。エンジニアは、自分たちのやっていることがたいしたことではないと思いがちですが、「自分たちならではの部分や工夫」があることも多いため、そういった部分を記事に取り入れることを提案します。また、開発者ブログを継続することで記事の専門性が深くなったり、難しい課題を解決した話がでることもありますが、それによって新しい執筆者が「自分はそんな記事をかけない」とハードルを感じることもあります。そのため、時々「知ってるようで知らない YAML のご紹介」のような比較的軽い記事を投稿して、執筆者のハードルが上がりすぎないように意識しています。

運用

NTT Com 開発者ブログの運用は有志の運営スタッフで行われています。運営スタッフに参加している理由は面白そう、社内の取り組みが知りたい、社内の人と知り合いたいなど人それぞれですが、業務時間内の仕事の合間を縫って活動をしています。

運営スタッフのやることは主に以下のとおりです。

記事のレビュー
執筆者のサポート
記事のネタ・執筆者探し
運営上の課題解決

運営スタッフは毎週定例を設けており、上記の進捗状況などについて共有したり議論をしています。

レビュー

記事のレビューは GitHub 上で行っており、執筆者の Pull Request（以下、PR）が来るとランダムで運営スタッフからレビュー担当が１名つきます。また、レビューの前に GitHub Actions が動作し、はてなブログへ下書き状態での記事投稿や、textlint を用いて表現や文章のチェックがなされます。

レビューでは執筆者が伝えたいことや文章の個性をそのまま読者へ届けられるようにしつつも、より読みやすい形で出すために以下のような点を確認しています。

読者が読んでいて疑問に思うところがないか
読者が読みやすい文章表現になっているか
数字の正確性確認
ブログに使われている画像に問題がないか

記事によってはレビュー担当のカバーする技術分野から離れた専門領域の内容をレビューすることもあります。そうした場合はその領域をカバーできるスタッフに代わってもらいますが、代わってもらう人がいない場合は自分で調べながらレビューすることもあります。私自身専門外の記事レビューを何度か経験しましたが、レビューは難しくも普段と違う技術領域を知るきっかけになり楽しんでいました。

textlint では社名（正式略称は「NTT Com」）や商品名、日本語の表現などがチェックされ、問題があれば PR にコメントとして残されます。これは、読者の方が読みやすい文章になるだけでなく、レビュー担当の負担を減らすことや、レビューの見逃しをなくすことに繋がっています。

記事公開

記事の公開はレビューが終わり次第可能となり、PR の Merge ボタンを押すと GitHub Actions が下書き状態だった記事を公開状態に変更します。執筆者の希望公開日があればその日にデプロイをしますが、希望がなければ、運営スタッフが Page View（以下、PV）が稼げそうなタイミングでリリースをします。この２年間でどういうタイミングに公開すると PV が伸びやすいかなど仮説を持って検証してきており、そうしたノウハウを活用しています。

記事公開にはレビューや textlint などのチェックを行っていますが、公開後に見つかるタイポや表現の問題があります。その場合、修正の PR を作成し、レビュー、マージの手順を踏んで記事を更新しています。

ボタン1つで公開や修正をできる Continuous Delivery のしくみにすることで、記事の公開・修正のハードルを下げることに繋がっています。

KPI や指標

「ブログの KPI をどうしているか」という質問がイベントでもありましたが、NTT Com の開発者ブログにも KPI はあります。 PV 数や記事の投稿数など、定量的な指標を KPI にしていますが、あくまで、「NTT Com の開発者ブログがこういう状態になっていたら嬉しい」ぐらいの目標設定として数字は置かれています。

KPI の管理は毎週のスタッフ定例で進捗確認をしながら KPI の達成に向けた施策の検討や実施をしており、毎年12月のアドベントカレンダー企画や、社内の執筆者向けた情報公開、イベントなども行っています。

先日もブログリニューアル２周年を記念した運営スタッフと執筆者の Meetup が行われ、この２年間の活動の振り返りや、今後についての話し合いなどが行われました。

その他

長く続けるために個人的に意識していること

ブログ運営を２年間続けている中で私個人として意識していることがあります。それは、 「ゆるく」 運営をしていくことです。

「8年続く社内勉強会を続けていくために行っていること」というタイトルの記事でも書かせてもらったのですが、運営を頑張ることはとても大事な一方で、頑張りすぎてしまうと燃え尽きてしまいあとが続かないこともあります。

先述したとおり、運営スタッフはそれぞれが開発者ブログに対して何らかの目的や思いを持って活動をしています。一方で、運営スタッフは本業の合間を縫ってエンジニアブログの運営をしているため、運営を頑張るほどに運営スタッフの負担が上がり燃え尽きる可能性もあります。社内の取り組みをより多くの人に知ってもらうための開発者ブログの活動を、運営スタッフが思いを持って運営し続けていけるしくみとして、「ゆるさ」が大事だと考えています。

その運営をゆるくするためにしくみのひとつとして、定例の簡素化があります。

運営スタッフの定例は時間と議題だけを決め、そのとき集まれるメンバが Slack ハドルミーティングに集まります。議事録などは毎回残しているので参加できなかった運営スタッフは後から読むことができます。また、Slack ハドルミーティングは普段から開発者ブログに関して運営や執筆者たちがやり取りをするチャンネルを用いているため、定例には運営スタッフ以外にも開発者ブログの運営や執筆に興味がある人も参加できるオープンな形で開催しています。

この他にも GitHub の PR によるレビューや、GitHub Actions を使った textlint、記事の下書き投稿・公開の自動化などのしくみも、我々運営スタッフの負担を減らし、ゆるくやっていくためのしくみの1つとして用意したものです。

今後も開発者ブログの運営が長続きするように、我々運営が頑張りすぎず、ゆるく運営を続けていければと思っています。