DeveloperからDeveloper Advocateにキャリアチェンジして３週間経った話

DevRel Advent Calendar 2021 20日目の遅刻記事です。

これまで

2013年ごろからWeb業界に入り、PHPやWordPressでプログラミングを始めました。
2015年にAWSを利用するSaaS企業に転職し、そこからはAWS LambdaまたはAmplifyとNetlify / Stripe / Algoliaを組み合わせるようなアプリケーションをJavaScript / TypeScriptで色々作ったり保守したりしていました。

現在地

2021年11月末からDeveloper AdvocateとしてStripeにジョインしました。
まだ１ヶ月経っていない状態で、業務も研修やOJTの割合がほとんどです。

Developer Advocateについて

まだ自分の中でうまく言語化できているわけではありませんが、「開発者と会社をつなぐ仕事」だと考えています。Developer Relationの取り組みの１つ、でしょうか。

エバンジェリストとの違いや、言葉の由来などは、以下の記事がすごくわかりやすかったです。

https://blog.agektmr.com/2013/04/google-developer-advocate.html

Stripeでは、Blog / YouTubeだけでなく、DiscordやTwitter上でのコミュニケーション、OSSとそのコミュニティへの貢献（コード・スポンサー・登壇）など、かなり幅広く取り組まれています。

https://dev.to/stripe
https://github.com/stripe-samples
https://twitter.com/stripedev
YouTubeのvideoIDが不正ですhttps://www.youtube.com/stripedevelopers
https://discord.com/invite/stripe
https://go.stripe.global/dev-digest

いまやっていること

いきなり全部をやることはできないので、ひとまず元々得意な方であったブログ記事作成に集中してい取り組んでいます。

https://qiita.com/organizations/stripe

Stripe Taxの日本サービス提供開始がちょうど１つ目の研修期間が終わるころでしたので、QiitaのアカウントやOrgnizationはそこに標準を当てて作成しました。

https://qiita.com/hideokamoto/items/e92b6ae22065b0d134cd

Dev -> DAで変わったこと

ドキュメントを読む時間が長くなった

今まで以上にドキュメントを念入りに読むようになった気がします。
これまでは、「要件を満たすために、なにができるか・どうすればいいか」を目的として記事を探したり読んでいました。
今は「もっと便利にできるオプションを紹介し忘れていないか」や「そのやり方が古い方法ではないか。もし古いならどう変更しないといけないか」などを考えながら読んでいます。

読み込めば読み込むほど、「あ、これ前職で使えばよかったなぁ・・・」となる箇所がいくつも出てきています。そしてそういう情報を見つけた時は、「たぶん同じように困っている人はいるはずだ」と考えて、記事化候補のリストに追加しています。

「誰に向けて書くか」を意識するようになった

これまでも個人ブログでいろいろ記事は書いていました。が、大体の記事は、「自分が後で思い出せなくなったときに読む用」であって、「コードスニペットと簡単な説明」しかないようなものも少なくありませんでした。

DAになってからは、できるだけ「その記事を使ってワークショップができる」レベルを意識するようにしています。（できていない記事もまだあるとは思いますが・・・）

個人的に興味深かったのが、Stripe Taxの紹介で書いた２記事のアクセス数でした。

１つ目に書いたのは、包括的・網羅的に機能やメリット・ユースケースを紹介した記事です。

https://qiita.com/hideokamoto/items/e92b6ae22065b0d134cd

そしてその後追加で、Billingに特化した記事を公開しました。

https://qiita.com/hideokamoto/items/878a92f325f063c1ae77

１週間ほど経ってページの閲覧数の伸び方を見ると、後者の方が安定してアクセスがあることがわかりました。

これはまだ仮説段階ではありますが、タイトルで「自分に関係がありそうだ」と思えるように記事を作らないと、中身以前にアクセスしてもらえないケースが増えてくるのかなと考えています。

とはいえ、包括的に紹介する記事がないと「そもそもこれはなに？」の説明が大変になります。

なので、目指すところとしては

• 1: ドキュメント（複数ページ）の内容を１記事で包括的に把握できる記事
• 2: 詳細は１にリンクさせつつ、個別のユースケースでの使い方を紹介する記事
• 3: 可能ならば、実際に動くサンプルも用意する
• 4: TwitterなどのSNS向けに概要をまとめた画像を４枚用意する

の4本柱になるかなと思っています。

Dev -> DAで変わらないこと

新しいOSSやツールを積極的に試す

前職でも、仕事の効率化や新しい機能のために色々と今まで触ったことのないツールに手を出していました。
その部分はDAになってからも変わりはなく、むしろ「このユースケースなら、こいつはどう使えばいいだろう？」のように考える幅が増えた分１つ１つにかける時間が多くなっている印象はあります。

また、「OSSコミュニティなどに参加して、Stripeを知ってもらうこと」も取り組みの１つなのですが、いきなり乗り込んで「Stripeの話をします！」では受け入れられるとは思えません。実際、コミュニティの運営をしている立場の場合ですと、製品のプロモーションが目的だと思われるセッションの優先順位を高くすることはあまりありませんでした。

ですので、そのコミュニティに参加するためにも、そこで話題になっているツールや機能については、しっかりと試し、もしその中でStripeを組み込めるユースケースがあれば、あくまで１トピック・１ユースケースとして話題に混ぜ込むくらいを目指す必要があると思います。

コードはやっぱり書く、いっぱい書く

コンテンツを作る中で、「書いてあるコードが動かない」のは読み手からするととてもストレスです。
※便宜上、長くなりすぎるために省略が入り、コピペでは動かないものは仕方ないと思います。

ですので、コードを掲載する場合には実際に自分の手元で動かして問題ないかを確認しています。

また、社内で新しい機能のテスティングに参加することなどもあり、そこでは「開発者として使いやすいか？ドキュメントはわかりやすかったか？」などをフィードバックする必要があります。

他にも、他部署とやりとりする中で、「この製品・エクステンションについて紹介して欲しい」という話題が出ることもあり、そうなるとやはりまずは自分で動かす必要がでてきます。

書くコードの毛色は大きく変わりましたが、「１つを深く」から「いろんなもの（言語・FW・環境）でほどよく」になっているのかなと思います。

個人開発は身を助ける

Stripeの製品には、一部テスト環境で試せないものがあります。
その機能を試したくなった場合に、自分のStripeアカウントがあることがとても助かっています。

個人的にStripeやAlgolia・AWSなどを使い倒したくて作っているプロジェクトがあるのですが、規模はとても小さくとも「実際に動いているもの」であることには変わりなく、そのログや設定などを改めて確認することで見えてくることもすくなくありませんでした。

全員がやるべき・・・だとは思いませんが、やはり「紹介する・紹介したいプロダクトを実際に使った経験を積めること」はかなり強みになるのではないでしょうか。

来年に向けて

まだまだOJT期間は終わっておらず、また他のチームの方ともあまり顔合わせなどもできていない状態です。

できることはそこまで多くない現在位置ですが、来年また「こういう取り組みができました」とアドベントカレンダーで紹介することができればと思いながら、2022年を励みたいと思います。

余談：登壇機会ください

個人開発や仕事に集中していたことと、コロナ後のオンラインシフトに出遅れたことがあり、イベントへの参加や登壇機会をかなりロスしています・・・

Stripeに限らず、Algolia / WordPress / Jamstack(Next.js / Gatsby) / AWS / TypeScript / Ionicなど、いろいろ話せるネタはありますので、スピーカーやイベントのネタを探されている方は是非Twitter(@hide__dev)へのDMやメンション、またはこの記事へのコメントなどでお声がけください。

「こういう話喋れます？」みたいな軽いもので大丈夫ですので、なにとぞよろしくお願いしますm(_ _)m

• https://wp-kyoto.net/
• https://github.com/wpkyoto/
• https://github.com/hideokamoto/