11年モノのテックブログを引き継いでから、持続性を高めるために行ったこと
この記事は技術広報 Advent Calendar 2022の19日目の記事です。
こんにちは、@yamamoto_manabuです。
今回は2020年のDevRel/Asiaで発表した「11年モノのテックブログを引き継いでから始めたこと、続けたこと、やめたこと」を、その後2年間のアップデートを追加・再構成し、特に"持続性の向上につながったこと"にフォーカスして文章化したいと思います。
テックブログの運用に従事されている方、これから始めるの方へのヒントになれば幸いです。
30秒サマリー
目的とコンセプト、ポリシーを整理しよう
「発信テーマに制約は持つべきか？」「レビュープロセスは組み込むべきか」といったポリシーの悩みは、テックブログ運用につきものだと思いますが、大抵の場合、その最適解は目的やコンセプトに依存すると感じています。もしポリシーにお悩みだったら目的、コンセプトを整理することをおすすめします。社内の定性的な印象に目を向けよう
周りからの協力を得るためには、「まあまあ大変だったけど、書いて良かった」と定性的に感じてもらうことが重要です。技術広報という役割を担うと、どうしてエクスターナルコミュニケーションに目がいきがちですが、同じぐらい、もしくはそれ以上にインターナルコミュニケーションが重要だと感じています。もし前者ばかりに時間を割いているという場合はぜひ一度後者にも目を向けてみると良いと思います。
自己紹介
2012年にヤフー（@ydnjp）にバックエンドエンジニアとして入社し、その後なんやかんやあって、2019年の4月からヤフーの技術情報を扱うWebサイト（Yahoo!デベロッパーネットワーク）や、テックブログ（Yahoo! JAPAN Tech Blog）のPdMを務めています。
また複業でタクシーアプリ「GO」の株式会社Mobility Technologies（@mot_techtalk）で技術広報支援を行っています。
今回はそれらの業務の中での知見を紹介します。
背景
Yahoo! JAPAN Tech Blogは、2008年12月から運用を開始し、もう14歳になるサービスです。開始当初は有志による手弁当での活動でしたが、2018年から前述の技術広報部門に移管の上、再スタートしました。
テックブログを引き継いだ当時、記事の発信頻度は下降傾向でした。当時は有志からボトムアップに記事が寄稿されるのを待つ運用だったので、発信の頻度にムラもありました。
目的とコンセプト、ポリシーを整理
となると、運営から能動的に「記事を書いてみませんか！」と周りに声掛けしようとなるわけですが、いざやろうとすると「誰にどんな声を掛けたらいいんだろう」という悩み、さらに言えば「技術的なトピックであれば何でもかんでも発信していいんだっけ？」という疑問がわきました。この「なにを発信したらよいんだっけ」という課題。これに効いたのが目的とコンセプト、ポリシーの整理です。
私たちの場合は以下の流れで整理しました。
目的の再確認
コンセプトとポリシーを言語化
ポイントはこれらを順序よく進めるのではなく、いったりきたりしつつ整理していくことだと思います。
目的の再確認
まず目的を再確認しました。なぜこのテックブログを運用しているのか、立ち上げ当時の目的を思い出しつつ、現在時点において何を目的とするか？を言語化していきます。言語化のためには以下のようなことを行うのがオススメです。
過去の担当者たちにヒアリング
掲載した記事をすべて読む
他社のテックブログを読む
その中で立ち上げ当初の目的はなんだったのか、その達成状況はどうだったのかが整理しつつ、今の自社の企業方針とマッチできているかなどを見比べて、現在時点において何を目的とするかを整理します。
自社・他社さまざまなブログを読んだ結果、テックブログの目的はだいたい3つに分類できる印象でした。
採用
エントリーの促進であったり、社内文化をオープンにすることで採用時のミスマッチを防止するなどの目的。拡販
開発者向けの商材の拡販をしたい、インバウンド営業のための情報発信。情熱
言語化に迷ったのですが、これは自社に所属している開発者の情熱、自分が取り組んできたことをどんどん発信していきたい、これまでGiveされてきた技術コミュニティにGiveし返したいという思いに、会社として発信の場を提供し応えるというものです。言語化には迷ったものの、意外と少なくないケースだと思っています。
この内どれか一つにフォーカスされる訳ではなく、それぞれの軸に重みがつくようなイメージです。
この軸を使って自分たちのメディアの目的を再確認しました。Yahoo! JAPAN Tech Blogの立ち上げ当初は、拡販 > 情熱 > 採用という重み付けだったように推測しているのですが、それを現在の社内外環境に照らし合わせて、私たちは採用 > 拡販 > 情熱 と重み付けを見直しました。
※これだけ見ると情熱をないがしろにしているようにも見えるのですが、施策はテックブログだけではないので、情熱の発露先は別に準備をして、テックブログとしてはこういう重み付けでいこうと考えました。
また採用や拡販に重きを置くならさらに深掘りが必要であろうと思い、考え方としてAISASを参考にしました。
AISASの詳細はぜひヤフっていただくとして、Attention（注意）→ Interest（関心）→ Search（検索）→ Action（購買）→ Share（情報共有）を採用プロセスに置き換えて考えました。
ヤフーは一定の認知獲得はできているので、ヤフーにすでに興味を持ってもらっている方が、ヤフーだったらどんな仕事ができるのか、その調査ニーズに応えられるようにする。つまりSearch以降に寄与できるようにしようと定めました。
コンセプトとポリシーを言語化
前述の目的をベースにして、コンセプトとポリシーに落とし込みました。
Yahoo! JAPAN Tech Blogは「社外のクリエイター」のみなさんと「ヤフーのクリエイター」をつなげるメディアというのをコンセプトに掲げました。そして「ヤフーにすでに興味を持ってもらっている方が、ヤフーだったらどんな仕事ができるのか、その調査ニーズに応えられるようにする」という目的を叶えるために、業務に関連する話題を発信して「ヤフーの技術力」であったり「それを支える文化」「業務内容の魅力」のいずれかが伝わるような情報発信をすると、テーマに関するポリシーを設けました。
他にも「記事を読んでくれた方に自分もこんな仕事がしたい」や、「これを書いた人と一緒に働きたい」という読後感を得てもらえることを意識して、よりリアリティや温度感がでるように、なるべく当事者自身に発信してもらうといった執筆者に対するポリシー、業務内容を発信していくのでそれに応じたレビューポリシーなどを自然と定められました。
テックブログを書くという開発者体験の最大化
前述の目的次第ではあるのですが、採用目的の場合、テックブログの効果は長期目線になる且つ、定量的には分析しづらいものです。
運営担当者的にはなんとかなく効果はある気はするけど、定量的な効果を関係者に説明できず、周りからの協力を得づらくなってしまう。そういう状況にならないようにしなければという危機感がありました。
そこで至ったのは、関係者に「まあまあ大変だったけど、書いて良かった」と定性的にでも感じてもらうということです。そう感じてもらうために取り組んでいる施策をいくつか紹介します。
編集プロセス
執筆者に伴走する編集者を記事ごとにアサインするようにしています。
Yahoo! JAPAN Tech Blogは業務内容の一部を発信していくため、内容に社外秘情報が含まれていないか確認したり、場合によって発生する社内手続きをサポートして、執筆者になるべく記事を書くこと以外の負担がないように注意しています。
また、執筆者が意図しないような伝わり方をしてしまいそうな表現が含まれていないか客観視したり、希望に応じてタイトルや構成を一緒に考えるといった記事の内容についても伴走するようにしています。
反響の収集とフィードバック
記事公開後、一定期間をおいた後に、執筆者と編集者で1on1フィードバックの時間を作っています。
PVだけでなく、SNS上のコメントや、社内のSlackでの反響、この記事を基点にどれだけの方が採用情報に興味を持ったかなどをお伝えするようにしています。
フィードバックの際は以下のようなことに気を配っています。
PVは解釈が独り歩きしやすいデータなので「PVはその記事のテーマに関心を持つ層の人数に依存するので、記事間の優劣を示すものではない」といったこと都度説明。
SNS上のコメントは執筆者本人もチェックしていることも多いですが、本人目線だと10あるポジティブよりも1しかないネガティブの方に目がいってしまうということ起きえます。そこで編集者が10は10、1は1と改めてお伝えすることで、ネガティブに過剰に反応されないよう温度調整をするようなこともしています。
このように反響を正しく受け取ってもらえるよう注意を払っています。
記事を書いて良かったと感じるポイントは人それぞれです。
ただこれまで多くの執筆者に接してきた範囲では「記事に対する反響をもらったときに書いて良かったと感じる」というのは大多数の方で共通したポイントでした。
参考：ブログを書いてて「嬉しい」のはどんな時？ – DevelopersIO 著者のみんなに色々聞いてみた Advent Calendar 2021
そのため収集するだけでなく、より反響をもらいやすくするための取り組みも行っており、例えば最近では以下のような記事の感想を送れるようなモジュールを記事の下部に置くような改修を行いました。
こういったところから得られた反響も執筆者にお伝えすることで、なるべく「まあまあ大変だったけど、書いて良かった」と感じていただけるように心がけています。
またこの1on1フィードバックの場を通じて、私たちの運営への意見なども収集し、運営側の改善にもつなげています。
関係者へのサンクスメッセージ
Yahoo! JAPAN Tech Blogは業務内容の一部を発信していくため、業務時間の中で記事を書いていただいています。
そのため、記事を書いたのは執筆者本人だけかもしれませんが、書ける環境・状態を作れたのは執筆者の周りの方々の協力があってこそなので、執筆者だけでなく、周辺の関係者の方にも感謝と前述の反響についてを伝えるようにしています。
技術広報という役割を担うと、社外からどういう印象を持ってもらうかというエクスターナルコミュニケーションに目がいきがちですが、それと同じぐらい、もしくはそれ以上にインターナルコミュニケーションが重要だと感じています。もし前者ばかりに時間を割いているよという場合は、ぜひ一度後者にも目を向けてみてはいかがでしょうか。
まとめ
目的とコンセプト、ポリシーを整理しよう
「発信テーマに制約は持つべきか？」「レビュープロセスは組み込むべきか」といったポリシーの悩みは、テックブログ運用につきものだと思いますが、大抵の場合、その最適解は目的やコンセプトに依存すると感じています。
もしポリシーにお悩みだったら目的、コンセプトを整理することをおすすめします。社内の定性的な印象に目を向けよう
周りからの協力を得るためには、「まあまあ大変だったけど、書いて良かった」と定性的に感じてもらうことが重要です。技術広報という役割を担うと、どうしてエクスターナルコミュニケーションに目がいきがちですが、同じぐらい、もしくはそれ以上にインターナルコミュニケーションが重要だと感じています。もし前者ばかりに時間を割いているという場合はぜひ一度後者にも目を向けてみると良いと思います。
ちなみに2020年のDevRel/Asiaでの発表ではKPIをどう持つかなど、この記事では触れなかったことも紹介しているので、もしお時間あればこちらもご覧ください。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？