はじめに
こんにちは、エンジニア組織の技術広報を担うDevRelブロックの@ikkouです。ARやVRをはじめとするXRといった技術領域を担う創造開発ブロックと、技術戦略の策定やエンジニア組織の強化を担うCTOブロックも兼任しています。
これから3つの記事にかけて、皆さんが見ているこの「ZOZO TECH BLOGを支える技術」を紹介していきます。1本目となる本記事では、これまでの取り組みと今後の展望を紹介します。
目次
はじめに
まずはじめに、DevRelブロックとZOZO TECH BLOGについて紹介します。
DevRelブロックについて
DevRelブロックは、ZOZOにおけるエンジニア組織の「技術広報」を担うチームです。この「ZOZO TECH BLOG」の運用・執筆支援をはじめとして、技術カンファレンスや勉強会での登壇支援や開催など、エンジニア組織の技術発信とブランディングを支援しています。
これまではCTOブロックがその役割を担ってきましたが、今年の春から専門チームとして新設されました。私のように他ブロックを兼任しているメンバーと、DevRelブロック専任のメンバーで構成されています。
技術広報を担う組織の場合、人事やコーポレート広報の経験者が担当または兼任しているケースもありますが、ZOZOの場合は全員エンジニアです。それぞれ素地となる専門領域は異なりますが、エンジニアとしての視点を持って取り組んでいます。
ZOZO TECH BLOGについて
まさに今皆さんが読んでいる、このZOZO TECH BLOGは、今年で13年目となり、現在までに様々な技術領域の記事やイベントレポートなどが約650本投稿されています。歴史を紐解くと、まず2011年5月9日に「株式会社VASILY」の「VASILY Tech Blog」として始まりました。2018年4月に複数社で「株式会社スタートトゥデイテクノロジーズ」として合併、名称が「スタートトゥデイテクノロジーズ テックブログ」に変わりました。そして同年10月に商号が「株式会社ZOZOテクノロジーズ」に変わり、あわせて名称も「ZOZO Technologies TECH BLOG」に変わりました。その後、2021年秋の吸収分割で「株式会社ZOZO」と「株式会社ZOZO NEXT」に分かれ、現在の「ZOZO TECH BLOG」になりました。
このように何度かの組織改編や名称変更を経てきましたが、テックブログに対する思いや熱量は変わることなく、現在はZOZO所属のエンジニアとZOZO NEXT所属のエンジニアが記事を執筆しています。
ZOZO TECH BLOGを支える技術
早速、本記事のテーマとなる「これまで」と「これから」を紹介していきます。
これまで
前述の通り、これまではCTOブロックが技術広報の役割を担ってきました。そのため、このZOZO TECH BLOGの運用も同様にCTOブロックが担っていました。テックブログにかける思いや、その運用方法については、前任の担当者が2020年末に記事として公開しています。今でも十二分に通用するテックブログの運営・運用ノウハウが詰まっているので、ぜひご一読ください。
これまでの仕組みと課題、その解決
一部、先の記事にも記載されていますが、記事公開までおおまかには次のプロセスを経ていました。
- 各部署から執筆予定をヒアリング
- スケジューリング
- 概要のレビュー
- デザイナーチームに画像の作成依頼
- 記事の執筆とテストページへのデプロイ
- 記事のレビュー
- 指摘箇所の修正
- 予約投稿と公開
- X(Twitter)にシェア
長年の運用によって培われてきたこのプロセスですが、一部の運用に改善の余地がありました。引き継いだタイミングと、DevRelブロックが組成されたタイミングで、それらの課題を解決するためのアプローチを考えました。
スケジューリング
当初はConfluenceで運用していましたが、見やすさを重視するためGoogle スプレッドシートに移行しました。また、それぞれのステータスを追いやすい形式に変更しました。
行を固定している#0は凡例です。スケジューリングの前工程として、各部署から上期・下期ごとの執筆予定の記事数をヒアリングするとともに、この予定表に記載しています。執筆者には、執筆予定の記事について、概要を記載してもらい、後工程に続きます。それぞれの工程では、依頼前・依頼済み・確認済みなどのステータスを変更することで、公開までの進捗を把握できるようにしています。
概要のレビュー
まず、執筆者の上長による概要のレビューを経て、DevRelブロックでも同様にレビューしています。このレビューは、検閲のようなものではなく、記事の内容を把握するためのものです。また、執筆者が記事を書く際に、概要を書くことで記事の方向性を明確にできます。
デザイナーチームに画像の作成依頼
ZOZO TECH BLOGの記事冒頭にあるOGP画像は、すべてデザイナーが作成しています。Slackに「TECH BLOG 画像作成依頼ワークフロー」を用意し、公開日・タイトル・概要・確認ページのURL・使用可能な画像アセットを記した上で作成を依頼します。デザイナーは、このワークフローを参照して画像を作成しています。この画像は、記事の内容を表現するだけでなく、SNSでシェアした際にも目を引くように工夫しています。
画像の作成依頼は公開日の14営業日前までに依頼するようにしています。デザイナーのマンパワーにも限りがあるため、記事は公開できる状態になっているが、画像が作成できていないという状況が時々発生してしまいます。対策として、昨今流行りの画像生成AIの利用や、記事タイトルのテキストを画像化するなども検討していますが、現時点ではクオリティの観点から見送っています。今後の課題のひとつです。
記事の執筆とテストページへのデプロイ
概要のレビューが済んだ後、各エンジニアは専用のリポジトリに記事を作成します。記事の執筆には、以前から変わらずMarkdownを採用しています。textlintを導入しているため、執筆中に必要最低限のチェックを行なえます。そしてPushすることで非公開のテストページに自動的にデプロイされ、表示を確認できます。その際にtextlintも実行されるので、手元でのチェックから漏れたエラーを確認の上、修正できます。
このCI/CDはもともとCircleCIによって実現していましたが、現在はGitHub Actionsに移行しています。この移行の詳細は後続の記事で紹介します。
記事のレビュー
一定まで執筆した、あるいはすべて書き終えた記事は、まずチーム内でレビューされます。チーム内レビューでは、記事内の技術的な内容の正しさを担保しています。ZOZOには一部の技術領域においてテックリードという制度があるので、ときにはチームの垣根を越えてテックリードがレビューすることもあります。
チーム内・テックリードの後、DevRelブロックでもレビューします。画像の作成依頼と同じように、Slackに用意してある「TECH BLOG レビュー依頼ワークフロー」からレビューを依頼してもらいます。DevRelブロックのレビューでは、誤字脱字や表記揺れ、表記誤りなどを修正するとともに、記事の方向性が概要と一致しているかを確認します。DevRelブロックが組成されるまで、このレビューパートは1人で行なっていたため、レビューのタイミングが遅くなるといった課題がありました。何より属人的になることで、可用性が低い運用となっていました。そういった背景もあり、現在のDevRelブロックが組成されたことで、マンパワーの増強によりできることが増え、その結果、これまで培ってきたことの改善と今後に向けた施策も考えられるようになりました。
マンパワーが増強されたとはいえ、期末など記事の公開が集中しがちなタイミングでは、レビューが追いつかないこともあります。画像の作成同様にAIを活用することも検討していますが、現時点ではまだ実現していません。これもまた今後の課題のひとつです。
予約投稿と公開
画像が用意され、各レビューが完了した記事は、執筆者自身の手で本番環境に下書き保存しています。下書き保存の完了後、スケジュールを確認しながらDevRelブロック公開日時を決めて予約投稿を設定しています。公開日の大原則は以前から変わらず、「1日に複数の記事は公開しない」と「午前11時に公開する」としています。
X(Twitter)にシェア
記事公開に先立ち、執筆者には記事の概要文を用意してもらっています。この概要文を記事公開にあわせてX(Twitter)のZOZO Developersアカウント（@zozotech）でシェアしています。これまでの経緯からこのシェアは人事組織が担っていましたが、現在はDevRelブロックが担当しています。
今後の展望
一連の流れは紹介した通りです。画像作成やレビューといったマンパワーに起因する課題はありますが、DevRelブロック組成以前に比べて可用性が高まっていると感じています。これからは、この可用性を維持しつつ、さらに改善していくことを目指しています。その一部を紹介します。
AI導入による効率化
前述の通り、画像作成とレビューにおけるAIの導入は今後の課題です。前者の画像作成については、例えばこれまでのOGP画像を学習データとして与えることで、ZOZO TECH BLOGらしい画像を生成できるかもしれませんが、まだ公開できるフェーズではありません。後者のレビューも同様ですが、textlintを活用することで、誤字脱字や表記揺れ、表記誤りなどの多くは自動的に修正できるようになっています。それ以上の言い回しや表現方法をAIが判断できるのか、今はまだ引き続き検証が必要な段階です。
別の観点では、記事執筆にGitHub Copilotが使える可能性も感じています。ちなみに、ZOZOは先日GitHub Copilotを全社導入しました。詳細はぜひ以下の記事をご覧ください。
GitHub Copilotは多くの場合、コードの補完に利用されていますが、テックブログのような文章を書く場面でも活用できます。実際にこの記事も一部でGitHub Copilotの恩恵を受けています。記事すべてをGitHub Copilot然りAIに完全に任せるのはまだ早いと考えていますが、補完のような形であれ、AIを活用することで執筆者の負担を軽減できるとも考えています。
反響の可視化
改善のひとつとして執筆者に記事公開後の反響を伝えようと考えています。実はこれまで、記事公開後に記事のPV数やシェア数を執筆者に伝えることはしていませんでした。現在は「DevRelブロック通信」という社内報で前月に公開された記事と、ブックマーク数が目立った記事を紹介していますが、記事公開後のフォローが不十分だと感じています。そこで、PV数・シェア数・はてなブックマーク数といった情報の他、記事に対するコメントや質問を共有することで、執筆者が記事を書くモチベーションにつながると考えています。
この記事公開後の反響の可視化については、もともと導入していたGA4とLooker Studioを組み合わせることで実現できます。このLooker Studioに関する詳細も後続の記事で紹介します。
まとめ
本記事ではDevRelブロックと、ZOZO TECH BLOGのこれまでとこれからを紹介しました。ZOZO TECH BLOGについては、後続の2つ目と3つ目の記事も楽しみにしてもらえると嬉しいです。
現在、DevRelブロックメンバーの募集は行なっていませんが、DevRelブロックが技術広報という形で支援するのはエンジニアの皆さんです。一緒にZOZOのサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
