Jagu’e’r Tech Writers とは？

Jagu’e’r Tech Writers (以降 Tech Writers) は、Jagu’e’r (Google Cloud のエンタープライズユーザー会) の情報発信を盛り上げる！をテーマに発足した分科会です。2023 年 8 月に立ち上げました。

Tech Writers では Meetup を中心に、情報発信を盛り上げるための様々なアクティビティを実施しています。分科会に参加することで、スキル、ナレッジ、ノウハウ、コツなどを楽しみながら高めあえる場を目指しています。

Meetup #8 を開催しました

2024 年 10 月 22 日 (火) に、Meetup #8 を開催しました！

Meetup #8 ではゲストにメルペイ Tech PR の mikichin さん、Google Developer Adovocate の Kaz さんをお招きし、各社ではどのように技術情報発信を行われているか教えていただきました。

メルペイの技術情報発信文化のつくり方

はじめのセッションは株式会社メルペイ Tech PR の mikichin さんに「メルペイの技術情報発信文化のつくり方」というタイトルで、メルペイ社における技術情報発信文化を醸成するためにやっていることについてお話しいただきました。

自己紹介

2021 年 8 月にメルペイ入社
Tech PR 担当としてエンジニア向け X の運用、テックブログの推進、技術イベントの企画運営などを行なっている
Go Conference 2024 運営メンバー

メルペイでは唯一の Tech PR だそうです。お一人でここまで影響力のある活動をされているのは素晴らし過ぎます！

Engineering Engagement Team とは

メルペイは開発組織内にエンジニアリングオフィスがあり、その中にエンジニアリングエンゲージメントチームが存在します。mikichin さんはエンジニアリングエンゲージメントチームに所属しています。エンジニアリングエンゲージメントチームでは下図のようにエンジニアの体験を候補者体験と従業員体験にわけ、複数の観点からエンジニア組織のスケールを図るための活動を行われています。Tech PR の領域としては「認知」「興味」という領域を主に担当されています。Tech PR としては「採用」は担っていません。

エンジニアリングエンゲージメントチームの関係者としては下図のような方々と協力しながら進められています。

メルペイが技術発信を大切にしている理由

メルペイでは、次の 3 つの要素において技術情報発信を大切にしています。

業界貢献
会社のブランディング
個人の成長

Tech PR Roadmap について

メルカリではロードマップ経営を推進しており、「ありたい姿を描く」というのが馴染み深い文化の 1 つとして形成されています。メルペイではそれを踏まえ、技術情報発信のロードマップを作成されています。ロードマップは、チームのゴールである技術情報発信のありたい姿をまとめたものです。

ロードマップは 3 つの要素で構成されています。

External Vision (社外からどう思われたいのか)
Internal Vision (社内をどうしたいのか)
Numbers (Vision 達成の指標)

Tech PR Roadmap は技術発信カルチャー推進プロジェクトに取り組んでおり、そのプロジェクトの一環として作成されました。ロードマップは、長期的な目標を描き、メンバーも取り組みやすくするために作成されています。

下図は過去実績です。FY 22 で Tech PR (mikichin さん) がジョインされたタイミングとのことでした。Tech PR の活動がいかに効果があったのか、一目でわかりますね！

メルペイでは、CTO、VPoE、MoM (Manager of Managers)、EM (Engineering Manager) など、エンジニアリング組織全体でロードマップの作成に参画しました。全員参加型のミーティングで意見を出し合い、共通認識を形成することで、その後の行動に繋げています。

エンジニアリング組織全体にシェアするだけだと意見を貰いづらいと思い、各チームの定例ミーティングに参加し、意見をもらうということも行われたとのことでした。ここまですることにより「自分たちが関わらずに勝手に作られた」という意識なく進めることができます。

巻き込み方について

技術情報発信自体はエンジニアが発信したいモチベーションを持っていることが多いですが、それを実現するには各レイヤーの方々の理解がないとなかなか進みません。

CTO & VPoE の巻き込み方
- 四半期に 1 回は発信をするように働きかける
  - 例 : 社内 Tech Talk での発表 (3 名に 1 人)、Advent Calendarなどのブログ企画の執筆
EM の巻き込み方
- 基本的に EM を通してチームメンバーへの働きかけになるので、EM が動ける状態が大事
- EM がロードマップを納得はしているが、進めていくことへの不安があることがわかった
- 「Tech PR における EM の役割」というグループディスカッションを実施
  - 例 : ネタが無いと感じている EM と、ネタを見つけるのが得意な EM をグルーピングしてディスカッションしてもらう

具体的な取り組み事例

メルペイでは技術情報発信活動を活性化するために、さまざまなアクションを実施されています。

社内 Tech Talk の開催

メルペイでは、社内 Tech Talk という社員が気軽に発表できるイベントを定期的 (四半期に 1 回) 開催しています。

メンバーの登壇機会を作ることはもちろん、技術発信に慣れてないメンバーの練習の場としても利用されています。

ブログ企画

社内だけではなく、社外にも定期的に取り組みが発信できるように、半年に1回ブログ企画を実施しています。12 月のアドベントカレンダーや 6 月頃に「Merpay Tech Openness Month」というものを開催しています。アドベントカレンダーは今年も開催されるようなので、ぜひチェックしましょう！

Tech PR 属人化の緩和

Tech PR Roadmap を作成し、それに向けた取り組みは始めたばかりではあるものの、ワーキンググループが立ち上がったり、メンバー同士でも意識した会話がなされたり、既に変化が起きているとのことでした。また、以前は社内 Tech Talk を声がけしてもなかなか枠が埋まらない状態だったところが、現在は直接声を掛けなくても自発的に枠が埋まっていく状態になってきているとのことです。

今後はロードマップを改訂しながら、エンジニアリング組織全体で取り組んでいきたいとのことです。

まとめと感想

技術情報発信は、企業の成長、会社のブランディング、個人の成長にとって重要です。一方で業務と並行して行うことは困難なため、継続的に実施していくためにどのような支援をするのかが大事です。

メルペイでは、エンジニアリング組織全体を巻き込み、技術情報発信の文化を醸成する活動を進められています。「エンジニアリング組織を育ててていく」という目的を共有しながら、一緒に考えて実行していくことで、エンジニアが技術情報発信に取り組みやすい環境をうまく作られているなと感じました。見習いたいですね！

参加者からのワイガヤコメント

1人ですべてやってるのすごいですね…!!
自分でやっていかないと発信する気持ちもわからないし説得力も出ないですよね
発信者数を見るのは属人化をコントロールするのにいいですね
カルチャー醸成、、すごく大事だけど難しいですよね><
上がやらないと下がやらないは学び。
締め切り設定だいじ！
期日が明確だとやりやすい、というのはあるかも

Google DevRel の取り組み

次のセッションでは、Google の Developer Adovocate の Kaz さんに、Kaz さんがこれまでの Google で行われてきたこと、技術情報発信で取り組まれてきたこと、大事にしていることをお話しいただきました。

Kaz さんのこれまでに発信された技術ブログやセッションなどは下記にまとめられていますので、ぜひご覧いただければと思います。

https://github.com/kazunori279/my-sessions-and-bio

Google 入社前 – Developer Community

Kaz さんは 13 年ほど前に Google に入社されました。Google 入社のきっかけは Developer Community だったとのことです。以前は、フリーランスとして Java のサーバーサイドエンジニアとして活動していましたが、2008 年頃に Google App Engine の提供が開始され、使い始めました。Datastore など SQL が通用しない技術で、Google ではどのようにアプリケーションを作っているのだろう、どうやって使いこなせば良いのだろうという疑問から同士が集まるようになり、appengine ja night (後に gcp ja night に改名) という Meetup が始まりました (当時の様子はこちらからレポートを見ることができます)。

Google 入社後 – gTech での活動

Kaz さんは AppEngine や Datastore などの技術ブログをはてなブログで執筆なども行われており、そのような活動の中で Google から声がかかったのがきっかけで Google に入社することになります。入社後は gTech (Google 広告の技術サポートの部門) でお客様の技術サポートに従事されています。

gTech での技術サポートの中ではビッグデータを扱うために Dremel (Google 社内の BigQuery) でクエリをバンバン叩くなど、Google の技術に実際に触れながら技術サポートをされていました。

Google の Solution Architect

Google の Solution Architect のロールができ、Kaz さんは Global で 3 人目の Solution Architech になります。当時は「Google Cloud」というサービス名ではなかったですが、現在 Google Cloud にある製品の中でも、当時は App Engine、Cloud Storage しかないような状態が数年ありました。実際のユーザーも少なかった、まさに黎明期ですが、Solution Architect としてそれらの後の Google Cloud 製品になるサービスを使った技術サポートを行われていました。Global チームなので、日本だけではなく、台湾やニューヨークなど、さまざまな国に訪れて、世界中の色々な案件で技術の紹介やサポートをされていました。当時は Google Cloud 自体がスタートアップのような規模だったため、非常に面白かったそうです。

Google Cloud の Developer Advocate

Google の Developer Relations チームはこれまでもありました。例えば Android や Chrome などの開発プラットフォームが既に存在するプロダクトの Developer を支援する Developer Advocate、Developer Program Engineer などの方々です。それとは別に Google Cloud の Developer の支援のためのチームが新たに作られ、Kaz さんはそのチームに Developer Advocate としてジョインすることになります。

これまでの執筆活動

Kaz さんはライティングが元々好きというのもあり、フリーランス時代からテックライターのお仕事 (Java World など) もされていました。Google に入ってからも、数多くの技術ブログを執筆されています。

これまで執筆された技術ブログはこちらにまとめられていますが、その中でもインパクトがあったのがこちら。「TensorFlow を使ってきゅうりの仕分けシステムを作った」という内容の技術ブログです。Google Cloud の AI/ML を知っている方なら、ご存知の方は多いはず。

当時は TensorFlow は出たばかり、サンプルがあったとしてもネコの判別くらいのアカデミックなサンプルしかありませんでした。実際のきゅうり農家の仕分けシステムで応用したこの技術ブログは Newsweek に取り上げられるほど非常に話題になりました。

How Artificial Intelligence is Helping Japanese Cucumber Farmers

ブログを書く上で気をつけているポイント

Google では技術ブログ等の Public なドキュメントを書く上で守るべき様々なルールがあります。そのような制約がありつつも、Kaz さんは「自分の思い、熱意をシェアする」ことを大切にされています。

こちらは「TensorFlow でじゃんけんマシンを作る」というユニークな技術ブログです。Kaz さんが熱意を持ってやりたかったことは「ガジェット系の記事を書きたい」ということや、機械学習を一から学ぶ中で知った「線形代数をビジュアルで表したい」ということ、そして「TensorFlow を使うと簡単に表現できる」ということです。自分が熱いと思える技術でなければいけないし、会社の方針とうまくマッチングさせなければいけないです。

もう 1 つエポックメーキングだったとご紹介いただいたのは、TPU チームと一緒に執筆された技術ブログです。最初の TPU に関するブログです。GPU や CPU との違いは、メモリアクセスをせずに膨大な演算をする設計 (systolic array) を持ったチップを Google がゼロから作りました。この技術はアニメーションにしないと理解できないと考えた Kaz さんはこのブログのためにベンダーとアニメーションを制作し、TPU の凄さをわかりやすく表現しています。

Kaz さんがブログで重要視されるのは、わかりやすくするためのビジュアルや、現場でどのように使われているのか（あのテクノロジーはこんな風な見え方をするんだ、という意外性）といった面を表現するところだそうです。ライゾマティクスの演出に Cloud Vision API を使っていただいた事例では、実際に取材に伺いながらブログ化されたそうです。

Perfume とライゾマティクスの新たな試みを支える Google の機械学習

「ラーメン二郎の判別を AI で行う」テーマの技術ブログも、ご存知の方も多いはずです。データサイエンティストの方が試された事例をフィーチャーして紹介されています。

現在 Kaz さんのチームは Cloud AI チームとして、新しいプロダクトの機能の紹介などを中心とした情報発信をされています。特に最近は Embedding などの技術について、図などを用いながらわかりやすく表現されています。

また昨今の LLM 界隈では歴史が語られないことも多いので、これまで Google がやってきた技術 (推薦システムや検索システムなど) などのような技術の歴史を踏まえる点も大事にされています。そうすることで、これまでの技術的な背景と、新しい技術をそれぞれちゃんと理解した上で、それらを組み合わせるとこういうことができるよ、ということが理解できます。「現場の人が困らないような技術を提供したい」ということを実現するため、Kaz さんは執筆を続けられています。

Enhancing your gen AI use case with Vertex AI embeddings and task types

まとめと感想

Kaz さんはこれまで本当に多くの技術ブログを Google Cloud として執筆されていて、その 1 件 1 件が濃厚で素晴らしい内容になっています。その技術ブログの執筆を続けられているモチベーションは「技術に対する熱意をシェアする」や「現場の人が困らない技術を提供したい」といったところにある、という姿勢は非常に学ぶことが大きいです。だからこそ熱意を持って技術ブログを書き続けられるんですね。

そして個人的には Kaz さんがこれまでの Google での活動を聞きたかったということもあり、非常に貴重なセッションでした。

参加者からのワイガヤコメント

深く深く聞きたいエピソード
Google Cloud立志編ってかんじで面白い話！
生き証人ですな
自分が感じる熱意を伝えることが大事
API叩くだけでは面白くない..気をつけよう。笑
図解だけでなくアニメーションで解説するのは面白いかもしれない。
熱意はアウトプットに化学反応を産みますよね！素晴らしいです

質疑応答

どのような KPI を決めているか？

情報発信はやればやるほど良いということは確かなのですが、続けていくためには KPI などのような定量的判断材料が必要だと思います。そういったものを用意されているのか、どのように考えられているのかお聞きしました。

メルペイ mikichin さん
- 過去に設定された KPI はこちらのブログで解説している
  - メルペイ Tech PR が実際にまわしている PDCA サイクル
- 前提として、技術発信の文化は特定の人に偏るのではなくエンジニアリング組織全体で状態をキープし続けたいと思っている
  - その中で「どのくらいの人が発信したいと思っているのか」を大事にしている
  - 例 : 向こう半年の発信意欲
- 発信者の UU を見ている
  - 組織全体のうち何%が発信しているのか
- ブログの PV は見ていない
  - 発信したことが素晴らしい
  - ニッチなネタは刺さる人には刺さる、PV が結果ではない
Google Kaz さん
- 数年単位で組織変更があるし、それに伴って評価指標も変わる
- 取れる数字は限られている
  - PV、ブログ件数、イベント登壇数など
- コロナ前はイベント登壇数はよく見られていた（1 年で 150 件！）
- 現在はドキュメント数、サンプルコードの件数など
- トラッキングする方法も難しい
  - ワークショップ開いてクーポンを配布し、アクティベートされたか、といった一連のプログラムを準備する必要がある

PV やコンバージョンなどと言った指標を KPI にしてしまうと、収集する仕組みを用意する必要が出てきたり、Kaz さんがおっしゃっているように取れる値も限定的になってしまい、無理矢理感が出てしまいます。また PV が悪かった場合、モチベーション低下を引き起こしてしまう可能性もあります。

メルペイさんでは、どれだけの数の発信者が継続的に発信意欲を持っているのかという点を指標とされているということでした。こういった KPI にすると、収集先が社内で済む (アンケートなど) 話なので取りやすそうです。

シニアになるにつれて書かなくなる場合にどのような働きがけができるか？

入社当初は書いていたけれども、シニアになるにつれて徐々に書かなくなってしまう、といった現象は、技術ブログを運営したことがある方なら経験されたことが多いと思います。そういった課題に直面したとき、どのような働きがけができるでしょうか。

メルペイ mikichin さん
- 「書かなくなる」の本当の課題は何かというのは気になる
  - よく聞くのは「時間がない」「ネタがない」「シニア前にやり切った」
- 人によって理由は様々だし、理由によって打ち手が変わってくる
- 無理強いはしていない
  - ライフイベントや子育てなど…色々環境の変化もある
- やっている人がマジョリティになっているかを重要視している
  - 熱意ある人が影響を与えることに気をつけている
  - 若手がやる気に満ち溢れているので、新卒をうまく使う、など
  - 外からの刺激を作るようにしている
Google Kaz さん
- コミュニティの継続的な運営にも近い課題
  - appengine ja night を運営する中でも起きていた
  - みんな飽きてしまう
  - コミュニティはどんどん洗練化していってしまう（初心者が置いてけぼりの話題ばかりになってしまう）
- 新陳代謝を図る仕組みを作る
  - コミュニティマネージャーのような人が黒子のように、熱意のある人をリサーチ
  - 新たに参加してもらったり、発表してもらったりすることを継続的に行う

シニアが書かなくなる理由は、一様ではなく色々な理由が考えられます。理由によって打ち手は変わるので、ちゃんと一人一人に理由を聞くことは大事です。ただそれは「書きたいと思っている」という前提があってこそであり、書くモチベーションがそもそも無い場合にはやる気に満ち溢れている若手を盛り上げるなど、外からの刺激を与えることも重要です。

Kaz さんのコミュニティ運営での経験談も、そのまま情報発信にも活かせるお話しだったかと思います。ブログ執筆者が固定化されてしまうということもよくある話です。そういった意味でも、外からの刺激によって新陳代謝が図れると飽きのこない仕組みづくりができるのでは無いかと思います。

まとめ

メルペイさんには Tech PR としてどのように技術者が積極的に情報発信を続けられる支援ができるか、具体的な方法をご紹介いただきました。マネージャーの巻き込み方にはすごく納得できました。エンジニアチームはどうあるべきか、どこを目指していくのか共通認識を持って進めていくことで、マネージャーからの働き掛けができたり、エンジニアがより積極的に情報発信ができる環境を作れるのだと思います。

Kazさんにはこれまで行われてきた Google の技術情報発信について話していただきました。13 年以上続けられているモチベーションは「熱意を持って技術をわかりやすく伝えたい」ところにある、という点に感銘を受けました。

企業・組織、または個人が技術情報発信をモチベーションを維持しながら続けるためには、技術情報発信を通して何をしたいのか？どうなりたいのか？そのためにどのような内容を執筆するのか？といった点を考えることが重要です。私も情報発信する身としても、支援する身としても、改めて振り返りたいと思います。

今回も得ることが非常に多かった Meetup でした！ぜひ参考にしてください！

Jagu’e’r Tech Writers Meetup にご参加ください！

Jagu’e’r Tech Writers Meetup ではこの記事のような内容を、毎回テーマを決めて月1回ペースで開催しています。技術情報発信にご興味のある方はぜひ参加して交流しましょう！

Jagu’e’r (Google Cloud のエンタープライズユーザー会) にこちらから参加した上で、ぜひ Meetup にもご参加ください。

タグ: テックブログ, テックライティング, 技術ブログ