こんにちは、ZOZOテクノロジーズ CTO室の池田（@ikenyal）です。

2020年のZOZOテクノロジーズのテックブログは、本記事で100本目に到達しました。1年間の公開記事数としては、過去最多であり、百の大台に乗れたことを嬉しく思います。

それを記念し、この記事ではテックブログに力を入れる理由であったり、どのような運用をしているか・何に気をつけているのかについて触れたいと思います。スケジュールとマイルストーンの仕組み化、公開日時を調整する際のポイント、記事の編集・校正時のポイント、日々の執筆者トレーニングについてもご紹介します。

なぜテックブログに力を入れるのか

「テックブログを頑張ろう」というフレーズは採用を強化していきたい多くの企業で耳にするものだと思います。

では、なぜテックブログにコストをかけてまで注力するのでしょうか。ZOZOテクノロジーズにおいても、今年その根幹に立ち返り、再度議論をしました。

テックブログの目的に立ち返る

私の所属するCTO室では技術広報も職務領域です。そのため、テックブログに関してもその目的の明確化を行い、KPIを定めた運用を続け、エンジニアに対してそれらを伝えていく責任があります。

なお、弊社のテックブログは、現在のZOZOテクノロジーズ（当時のスタートトゥデイテクノロジーズ）に吸収合併された一社であるVASILYのテックブログが前身です。

techblog.zozo.com

VASILY時代より、現在のCTO今村が先頭に立ち、テックブログを継続していました。その当時からテックブログを実施する目的は変わっていません。その目的に関しては今村の以下の記事で社内向け説明ページのキャプチャを添えて触れられています。

note.com

目的からやらないといけないことを細分化する

しかし、大きな目的が定められていたとしても、それだけでは四半期や半年、1年単位で何をやるべきかが明確になりません。

そこで、CTO室と広報で連携し、日々の技術広報のKPIを定められるよう、直近から3年間で技術広報が目指す先、つまり技術広報戦略を定めました。

まず、「最終的に目指す先」を定め、そこから「それを実現するためには何が必要なのか」を順に考えていきます。「何をどの順に達成しないといけないのか」のステップを明確にしていくのです。

これをすることにより、テックブログをやることによって最終的に何を目指していて、それに向けて今は何をやらないといけない段階なのかが可視化できます。そして、それを用いることで社員へ明確な説明ができると同時に納得をしてもらえる材料になります。実際に今年、この技術広報の背景をCTO室通信（毎月CTO室が公開している社内報）で解説し、社員から「技術広報やテックブログの背景を知ることができて良かった」という意見も得られ好評でした。

では、弊社の場合、どのようにステップを分解していったのかを紹介します。

ZOZOの経営戦略に「MORE FASHION x FASHION TECH」が掲げられています。 corp.zozo.com

このZOZOグループの大きな目標を技術の力で実現させることが、我々ZOZOテクノロジーズという企業が果たさねばならない最終目標です。

次に、その「MORE FASHION x FASHION TECH」が実現されるために必要な状況を考えます。「世の中により価値のあるプロダクトを届ける」ということが、必要だと考えました。利用していただくための「価値あるプロダクト」がなければ、世界中の皆様に何も届けることができない、という考え方です。

さて、そのようなプロダクトを届けるためには何が必要でしょうか。何か構想があってもそれを作り上げるエンジニアが不在では形になりません。つまり、素晴らしいエンジニアが会社に集結し、会社全体の技術力の向上が必要でしょう。

そして、次に素晴らしいエンジニアが集まる会社になるために何をすべきかを考えます。エンジニアが入社したくなるような「会社のファン」を増やすために、認知度向上のための技術発信が必要でしょう。いわゆる、技術ブランディングに力を入れる必要があるのです。弊社もここに注力をしている状況です。

このように、最終的なゴールから直近で達成しなければならないポイントを明確にすることにより、「なぜやるのか」「どのような意味があるのか」が自然と明確になります。

ここまでの流れをまとめると、以下のようなステップに分解できました。

直近から3年間の目指す先を明確化する

直近の目標である「発信によって認知を広め、会社のファンを増やす」ための方針を定めます。詳細は割愛しますが、弊社では3カ年計画を定め、2020年度・2021年度・2022年度で、それぞれどのような状況を目指すのかを具体的に定めました。それらを元に、テックブログ、外部登壇や自社主催のイベント開催など、それぞれの技術広報における施策のKPIを定め、CTO室と広報の定例で数値を追うようにしました。

具体的なKPIを定めることにより、並行する多くの施策をバランス良く継続できます。

テックブログの業務だけを行う専任者がいることは稀であり、エンジニアが他の業務と掛け持ちで運営していることが多いかと思います。そのような状況だと「気づいたらやらなくなっていた」「忙しくて放置状態になっていた」という状況が起こりがちでしょう。そのような状況が発生しかけたとしても、定例で数値を確認することになるので、早期のリカバリが可能になり、継続的な施策として定着させる手助けになるでしょう。

どのような運用をしているのか

ここでは、テックブログを日々どのように運用しているのか、その一部をご紹介します。この運用に関しては、CTO室の設立後、仕組み化を大きく導入できた領域です。

弊社のテックブログの記事はすべてCTO室のレビューを必須としており、私が担当しています。執筆開始前の概要確認から、執筆後の編集・校正をすべて行っています。他の業務をこなしつつも、100本の記事をレビューしてきました。まるで編集長ですね。

なぜそこまでチェックをしているのかと言うと、前述の「技術ブランディングのため」というのが答えです。テックブログは個人の作業メモや備忘録ではありません。企業の公式な発信媒体であり、それらの記事が読者の皆様に価値を与えないと意味がありません。「価値」とは、チュートリアルに載っていない細かい部分の新しい知見の共有であったり、新規性のある独自に工夫をした手法・アーキテクチャ、ZOZOTOWNの大規模トラフィックにいて得られる知見、などです。我々の発信よって、それを参考にした社外のエンジニアのスキル向上につなげ、業界全体・社会への還元につながれば幸いです。

また、記事の事前チェックにより、間違った内容だけでなく、社外秘の情報や数値が含まれていないか、いわゆる炎上につながるような不適切な表現がないか、を確認する役割も大きいです。それらが一度でも外部発信に含まれてしまうと、ブランディングに影響を与え、それまでの苦労が一瞬で水の泡となりかねません。

スケジュールとマイルストーンの仕組み化

まず、CTO室が四半期（3か月）ごとに、エンジニアが所属する部に記事の募集をかけます。この段階で、「どのチームが、どの週に記事を公開するか」までを確定させます。これを四半期が始まる1か月程前に確実に行うことにより、期初から計画的なペースで記事を公開できるようになります。そして、慌ただしくなりがちな期初の執筆者に対しても早めに調整・リマインドをできる環境を作っています。

その際に、前述の今村の記事でも紹介しているようなマイルストーンを定義し、チェックボックス形式でその進捗を管理しています。それぞれのマイルストーンに対し、記事公開の何日前までに完了しなければいけないのかの期日も定め、その期日を過ぎてもチェックボックスに動きがない執筆者に対してリマインドと状況確認を行います。

リマインドの期日には多少の余裕を持たせているため、ここで問題が発生してもリカバリが可能です。場合によっては、その次週公開予定の執筆者と公開日の調整を行うことも可能です。

この早めの遅延検知により、「実は期日ぎりぎりで未着手でした」という事態を防止します。期日ぎりぎりでの執筆になると、執筆者自身も辛くなりますし、運営側もレビュー時間の不足やスケジュールの破綻が起こって辛い状況になります。場合によっては、期日の兼ね合いで不完全な状況での記事公開をせざるを得ないということにもなりかねません。誰も得をせず、お互いに不幸な状況になってしまいます。そのような状況に陥ると、テックブログに対して全員が後ろ向きになり、施策が停滞してしまう可能性が高くなります。

ここからは、運営者として気をつけているポイントをいくつか紹介します。

公開日時を調整する際のポイント

1つ目は公開日時を調整する際のポイントです。

弊社のテックブログも以前は更新頻度が一定ではなく、停滞する時期もありました。そこから定期的な発信を続けたところ、テックブログ自体のアクティブユーザー数が維持・増加することが見えてきました。そのため、1日にまとめて記事を公開するのではなく1日1本ずつ継続して公開するようにしています。同じ週の担当になった執筆者の中で、進捗状況を考慮しながら公開日が別になるように割り振っています。

さらに、公開時間も調整しています。特に情報解禁の時間であったり、プレスリリースに合わせたりする必要がなければ、基本的に午前11時の公開をしています。これは、Google Analyticsの曜日時間帯別PVのヒートマップから、1番読まれる時間帯の開始時刻に合わせての設定です。平日と休日でも読まれ方に差があるので、土日祝日の公開は基本的に避けています。なお、土日祝日を避けるのは、万が一、記事の内容に修正が必要になった場合、迅速な対応が取りにくくなるリスクを避ける意味もあります。

記事の編集・校正時のポイント

2つ目に記事の編集・校正時のポイントです。

固有名詞の表記を正しく書くことは当たり前のことですが、指摘する回数が非常に多いものです。例えば、「Slack」を「slack」と表記されるパターンをよく目にします。Slackの場合、ロゴの文字は小文字のsなのですが、固有名詞としては大文字のSで始まるSlackが正しい表記です。記事で固有名詞を使う際には、記憶やロゴの見た目で判断せず、公式サイトで今一度確認をしましょう。GitHubをGithubとするパターン、YouTubeをYoutubeとするパターンも非常に多いです。

また、我々はZホールディングスグループなので、ヤフーとも親戚関係です。そのため、以前よりもヤフーの名称を社員が利用する機会が増えました。Yahoo!Japan、Yahoo!JAPAN、Yahoo！JAPAN、Yahoo・Yahoo!など多種多様な表記をされることがあるのですが、これらは正しい表記ではありません。会社としては「ヤフー」「ヤフー株式会社」、サービスとしては「Yahoo! JAPAN」と書くのが正しい表記です。年賀状やメールを出す際に相手の名前の漢字に気をつけますよね。会社名もそれと同じです、正しい表記で記載するのはマナーだと考えています。

他には、表記揺れも修正対象です。記事内で表記揺れがあったり、同じ事象を指す用語が別の呼び方になっていると、読み手が理解しにくくなるため、統一をします。ここで気をつけているのは、テックブログ内でルールをがちがちにはしていないところです。「ください」はひらがなで、「出来る」はひらがなで、などしても良いのですが、そこまではしていません。執筆者はそれぞれ別なので、どの表記を採用するのかは執筆者ごとの個性として捉え、記事内での統一に留めるようにしています。ただし、その個性も、正しい表記を利用していることが大前提です。

加えて、テックブログなので、「！」の多用や、「〜な気がします」「〜かもしれません」などの曖昧な表記があれば修正をしています。記号類は冒頭や末尾の挨拶部分であれば良いのですが、テックブログとして真面目に発信している本文内では適さないと判断しています。また、曖昧な表現で断言しないことも同様に適しません。自信のない内容や、断言しきれない「個人的の見解」ばかりだと、テックブログとして読者が参考にして良いのか判断に困ってしまいます。執筆の際には自信を持って言い切れるように、調査や準備をしておく必要があります。

なお、textlintによる自動校正も導入していますが、最後は人による確認が必要でしょう。

日々の執筆者トレーニング

そもそも、テックブログを書く行為はある程度のスキルや経験がどうしても必要になってしまいます。そのため、テックブログをいきなり書く自信がないエンジニアには、アドベントカレンダーでその練習をしてもらったりしています。2020年のアドベントカレンダーでは、12月の25日間で合計100本の記事を発信できました。

qiita.com qiita.com qiita.com qiita.com