dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

「エンジニアのためのドキュメントライティング」を読んだ

読んだのでメモ。

本書の目次

PART I ドキュメント作成の準備
- CHAPTER 1 読み手の理解
- CHAPTER 2 ドキュメントの計画

PART II ドキュメントの作成
- CHAPTER 3 ドキュメントのドラフト
- CHAPTER 4 ドキュメントの編集
- CHAPTER 5 サンプルコードの組み込み
- CHAPTER 6 ビジュアルコンテンツの追加

PART III ドキュメントの公開と運用
- CHAPTER 7 ドキュメントの公開
- CHAPTER 8 フィードバックの収集と組み込み
- CHAPTER 9 ドキュメントの品質測定
- CHAPTER 10 ドキュメントの構成
- CHAPTER 11 ドキュメントの保守と非推奨化

この本について

ドキュメントを書くことになったエンジニアが意識すべきことが網羅的にまとめられた本、という印象。

本書の主張を端的に表すと「ドキュメントもプロダクト開発と同じような考え方で計画・実装・運用しましょう」ということに尽きる、と解釈した。

プロダクト開発と同じように、とはたとえば次のようなこと。

  • 読み手(ユーザー)を理解し、何がドキュメントとして必要なのかを書き始める前に明らかにしておこう
    • プロダクト開発において、機能を作る前にユーザーのニーズを把握しようという話と似ている
  • いきなり最終的な文章を書き始めるのではなく、はじめにアウトラインを作り、ドラフトを書こう
    • プロダクト開発において、実装前におおまかな設計方針を立ててレビューしたり、実装時にまずコメントでおおまかな処理を書いてから肉付けしていくやり方に似ている
  • レビュー時にはレビュー観点を明確にしよう
  • リリースプロセスを明確にしよう。最終レビュー者は誰か?どこに公開するのか?新しいコンテンツをどのように発表するか?
  • リリースしたドキュメントに対してユーザーからフィードバックを受けるチャンネルを作ろう
  • リリースしたドキュメントが良いものであったか、品質を測定しよう

なので、(これは読む前の期待値とギャップがあった箇所でもあるが)単に良い文章を書くためのポイントではなく、その前後も含めた計画フェーズ、運用保守フェーズについても書かれている。というよりそちらのほうに重点が置かれている。

そのため、きれいな日本語文章を書くためのテクニックが知りたいという人にはあまり適さないように感じた。そういう人には日本語スタイルガイドのような書籍のほうが適切だと思う。(そっちも買ったけど読み途中)

もうひとつ、読む前の期待値とのズレがあったところとしては、本書では主に開発者向けのドキュメントの書き方を扱っているというところ。そのため、たとえばCHAPTER5では1章まるまる使ってドキュメント中のサンプルコードについて言及されている。なので自分のように非開発者向けのドキュメントを書こうとしている人には少々学びにしにくいところがあるかもしれないが、CHAPTER5 以外はおおむねどんなドキュメントに対しても言えることが書かれていたように思う。

感想

ドキュメントを書く「前」と書いた「後」のことまで扱った書籍は初めて読んだので参考になった。特に、公開後の品質測定と保守、非推奨化のところは読んでいてなるほどと思う部分が多かった。
また、構成に関しては、各章の冒頭に架空の企業(「Corg.ly」という、犬の鳴き声を人の言語に翻訳するサービスを開発している企業)のストーリーが書かれており、内容がすっと頭に入ってきやすかった。

あと、末尾に発展的な学習のためのリソースや参考文献のリンクが大量にあってありがたい。

不満な点、というかいまいち腹落ちしきれなかった点があるとすると、本書はドキュメントを書く前から書いた後までを体系的に学べる分、一個一個のトピックについてはさらっとしている。そのため、具体的なテクニックについてはそこまで書かれておらず、明日からすぐに使える実用的な知識が身についたかと言われるとそうではなかった。
この記事のように感想や要点をメモしておかないと「なんか良いこと書いてあったなー」で終わってしまいそうな本だった。※自分の場合、技術書以外は大体そうなりがち
逆に言うと、エンジニアとしてのキャリアでもっと早くから出会いたかった本。

メモ

印象に残った箇所をメモ。

読み手(ユーザー)を理解する

CHAPTER 1 読み手の理解 より。
効果的なドキュメントを書くためにはとにかく読み手となるユーザーへの共感、具体的にはユーザーがそのドキュメントに何を求めているのかを理解する必要があると書かれている。そして、ユーザーを理解するために次のような方法を紹介している。

  • ユーザーのゴールを理解する
    • ユーザーがドキュメントを読んで達成したいこと(例:犬の鳴き声を人の言葉に翻訳する)と、ユーザー全体に渡る組織のゴール(例:Corg.lyのAPIを新規ユーザーが組み込めるように支援することで、新規ユーザーを獲得してオンボードする)との整合を取る
  • ユーザーを理解する
    • ユーザーが開発者だったら、スキルレベルは?役割は?
  • ユーザーの理解を検証する
    • サポートチケットなど既存の情報リソースを活用したり、インタビュー、開発者アンケートなどを通じて新しい情報を集める
  • ユーザー調査から得られた知見をまとめる
    • ペルソナ、ユーザーストーリー、ジャーニーマップ、フリクションログ

個人的には最後に出てくるフリクションログというのが初耳だった。フリクション = 摩擦、抵抗 の意味で、本書ではソフトウェアやサービスの利用時にうまく使えなかったことや、違和感などを示している。ユーザーに代わって自分自身がソフトウェアを試して体験を記録し、そのときに感じた違和感やイライラがドキュメントやソフトウェアの改善のヒントになる。

フリクションログの例(「CHAPTER 1 読み手の理解」より引用)

機能品質と構造品質

CHAPTER 9 ドキュメントの品質測定 より。
まず、章の冒頭でこのような文がある。

ドキュメントの品質を測定する前に、まず「品質」の定義から始める必要があります。幸いなことに、Googleの執筆者とエンジニアのグループがまさにこの質問に取り組んでいました。つまり、コード品質の評価と似た方法によって、ドキュメントの品質を測定していたのです※60。彼らの作成したドキュメントの品質の定義はとても簡単です。

ドキュメントが優れているのは目的にかなっている場合である。

そして、ドキュメントの品質を機能品質と構造品質に分類し、以下のように定義している。

  • 機能品質:ドキュメントの目的やゴールが達成されているかどうか
  • 構造品質:ドキュメント自体がうまく書かれているか、うまく構成されているか

ここで重要なのが、機能品質と構造品質では機能品質のほうがより重要であるということ。ドキュメントとしていかに上手にかかれていたとしても、目的やゴールが達成されない限りは良いドキュメントとは言えないということになる。

ドキュメントの品質をどう測定するか

同じく CHAPTER 9 ドキュメントの品質測定 より。
先ほど機能品質のほうが構造品質よりも重要だと書いたが、じゃあ機能品質をどう測定すればいいの?については明言されていない。 "機能品質全体の測定は困難です" と書かれているぐらいだ。ただ、CHAPTER1で定義した読み手のゴールやより上位の組織のゴールと照らし合わせて、そのゴールの達成度合いをどう測定すればいいかを考えることになる。

また、少なくとも次の質問に応えられるようにすべき。

  • なぜ測定したいのか?
  • その情報を使って何をするのか?
  • その努力で、どのように組織のゴールを前に進められるのか?

ドキュメントの保守:いかにして新鮮な状態に保つか

CHAPTER11 ドキュメントの保守と非推奨化 より。
プロダクトのリリースプロセスにドキュメントの変更も組み込むことで整合を取りましょう、という話はせやなって感じ。

あと面白かったトピックとしては

ドキュメントオーナーを決める

ドキュメントの責任は全員にある、と考えられることが多くあります。それゆえに、誰も責任を負ってないとも言えるでしょう。そこで、ドキュメントの課題への対応、ドキュメントの変更に対するレビュー、必要であればドキュメントの更新に責任をもつドキュメントオーナーを明示的に任命することで、責務を明確にしてください。責務の明確化は、ドキュメントが古くなることの防止に役立ちます。

コンテンツの鮮度確認

ドキュメントが大規模になると知らず知らずのうちに情報が古くなることもあるので、コンテンツを確認する予定日を決めておくという手もある。たとえばGoogleでは、ドキュメントの上部に次のようなメタデータを埋め込んでおくことで、コンテンツが現在でも正確かどうか確認するようなリマインダーを飛ばすしくみがあるらしい。

<!--
Freshness:{owner:“karthik”reviewed:2021-06-15}
-->
リンクチェッカー

ドキュメント内で大量にリンクされてるといつの間にかリンク切れが発生するので、それを防ぐリンクチェッカーというツールがある。本書で紹介されているのは htmltest というもの。よさそう。


ドキュメントオーナーと鮮度確認の話を読んで、Notion に最近追加された Wiki 機能を思い出した。

Wikiとページの有効性確認 – Notion (ノーション)ヘルプセンター

まだ自分では使いこなせていないんだけど、Verification というのが「このページは○日間は新鮮な情報です!」という意思表示をすることで、読み手に今も有効なドキュメントかどうか示すことができるし、期限切れ時に通知がくるので最新かどうかチェックする役目も果たせる。(○日までは新鮮!って言ってもそれまでに情報が古くなってる可能性は全然あるんだけど、ないよりまし的な)

気に入った一節

可能ならば、よく報告される課題と顧客からのフィードバックのトレンドを理解するために、サポートチームと密に連携しましょう。顧客が同じ課題に何度も遭遇しているなら、ドキュメントまたはプロダクトを更新することで、その課題を解決する必要があります。

CHAPTER8 フィードバックの収集と組み込み より。
ドキュメントへのフィードバックを受け付けるチャンネルのひとつとしてサポートチケットもあるよね、ぐらいのさらっとした内容なので全然重要でもなんでもないんだけど、最近カスタマーサポート体制のこととかを考えていたので思うところがあった。

問い合わせ対応ってプロダクト開発における割り込みタスクとして敬遠されがちだったり、専門チーム作ってそっちに任せるのが定石っぽくなってるけど、やっぱりお客様から一番最初にいただく声ってプロダクトやドキュメントの改善の種としてはものすごい財産なんだよなー、だからチーム分けるにしてもそこをうまくつないであげる必要があるよなー、みたいなことを考えていた。ドキュメント関係ない。

余談

読書メモの残し方はこの2つの記事を参考にした。

前者を真似してメモを残す作業をやらなかったら絶対記憶に残らない本になってたと思うし、後者の気に入った一節を探す作業も「んーどこが一番お気に入りだったかな」って考えながらハイライト箇所を行ったり来たりして楽しかった。

参考リンク

「GPT-4 Developer Livestream」視聴メモ

見た。英語はほとんど聞き取れていないが、デモはわかりやすかった。

[1:35] 記事の要約

https://openai.com/research/gpt-4 の記事を貼り付けて「要約して。ただし全部 G から始まる単語だけ使って」というやや難易度の高い要約を GPT-3.5 と比較。

GPT-3.5 は条件を満たしていないが、

GPT-4 だとかなり正確に要求に答えてくれる。

[6:20] プログラミングのアシスタント:Discordボット作る

「あなたは AI プログラミングアシスタントです」とか「ステップバイステップで考え、詳細も全部書きだしてください」などの指示を与えてる。

GPT-4 が出力したコードを Jupyter Notebook に貼り付けて実行するとエラーが出る。このときも、エラーメッセージをただ貼り付けるだけで適切な修正をしてくれる。

「Jupyter を使ってるんだけど、この環境でも動くようなコードにできる?」みたいなリクエストにも答えてくれる。

画像も渡せる。

[16:10] 手書きのモックからHTML/CSS/JSを生成

手書きのモックをスマホで撮影し、それをGPT-4に渡してコード生成してもらう。

普通にできてる。すごい。

[18:55] 税法(tax code)の長い文章を渡して、税金の金額を計算させる

感想

手書きのモックからコード生成しちゃうデモはけっこう衝撃。エラーメッセージ貼り付けるだけでコード修正してくれるのも便利。自分がやったことない分野の勉強をサポートしてもらう、という用途には非常に強力。
「これで新しいこと勉強するのめちゃくちゃ楽になるわー」という楽観的な気持ちと、いやそんなこと言ってる間にそもそもプログラミングの仕事が淘汰されてしまうのではという悲観的な気持ちと両方ある。

2023年1月のふりかえり

今年もなるべく1ヶ月おきに書く。

前回:2022年のふりかえりと2023年にやりたいこと - dackdive's blog

✨ やったこと

簿記3級を取った

現職の業務ドメイン理解のためにようやく取得した。(正確には1月中には間に合わず合格したのは2/4)
1年ぐらい前に一度挫折してたのだが、年明けにやらねばという気持ちが再燃して3週間ぐらい集中して取り組んだ。
1月後半から大学の授業が始まるというので良い意味でお尻が決まってたのがよかった。

勉強にあたっては CPA Learning というサイトが無料で簿記の勉強ができてめちゃくちゃよかった。

大学(UoPeople)の新学期が始まった

1月後半から大学の新学期がスタートした。今期は CS1104 Computer Systems を取っている。

この講義で使用する教科書の1つが、気になってた「コンピュータシステムの理論と実装」らしい。早速買った。

今は NAND 回路とか加算器とかを学んでいる。この先どういうふうに発展していくのか楽しみ。

📝ブログ・登壇

今月はなし。

💬 所感

今月は簿記3級取得に大半の時間を費やしてその他のことが手つかずだったが、これぐらい1つのことに集中して取り組めたのはよかったと思う。
反面、業務で何をやっていたかという記憶がほとんどなく、達成感や成長を感じにくい月だった。四半期の境目で次に向けた準備をしていたからというのもあるが、週・月でやったことを振り返るようにしないとなかなかこの問題は解決しないのではないかという不安もある。何か良い方法あったら知りたい。コーチングとか受けるといいんだろうか。

💪2月のテーマ

一度オリャっと興味薄くなったものを削除した。来月は基本的には大学の授業で精一杯だと思う。。。

💸 買ったもの

正確には昨年末だが、左右分離式のキーボードを購入した。ようやく慣れてきた。。。
打ち心地はそこまで悪くないけど HHKB のほうが好きかな。Ultimate Hacking Keyboard も気になったけど値段で断念。いつか使ってみたい。

2022年のふりかえりと2023年にやりたいこと

例によって新年を迎えてしまったが今年も書く。

去年:

2022年中のふりかえり:

読んだもの

ちゃんと読んだ本はおそらくこの 2 冊だけだった。

また、仕事や技術関係ない本としては女の園の星を買った。めちゃくちゃよかった。

書いたもの

2022年に個人ブログに書いた記事は 18 件、Zenn に投稿した記事は 4 件だった。

仕事:Customer Reliability Engineer(CRE)という領域へのチャレンジ

仕事面では、これまでの Web アプリケーション開発を行うエンジニアから CRE というロールに転向したのが今年一番のチャレンジだった。
2022年の前半はプロダクト開発と兼任という形だったが、夏以降はこのロールに専念している。

CRE に関しては正直まだまだ「何をミッションとしたロールか?」とか「Reliability(信頼性)とは何に対するものか?」とかがきちんと言語化できてない部分もあり、何を為すべきか試行錯誤しながら進めている。それでも、今までより一層顧客の存在を強く意識しながら、エンジニアリングで解決できることを模索するのは非常に面白いテーマだと感じる。また、データ分析など技術的にも興味をそそられるトピックが転がっている。

また、業務に関するブログ執筆や勉強会登壇という形でアウトプットできたのも良かった。

(とはいえ、四半期に1記事ぐらいは活動内容をアウトプットしたいなと思ってたので、半分ぐらいしかできてないことになるが)

技術

技術面では、2022年これを新たに勉強した!と呼べるものがなかったように感じている。
だいたいが業務で関係しそうなフロントエンド系のトピックを素振りした、ぐらい。

学業:University of the People(UoPeople)

昨年9月から通い始めたオンラインの大学も気づけば1年経過していた。
とはいえ今年は転職したこともあって 2 term ほど休んでいるため、3 科目しか受講していない。
そのせいか、まだ入学してよかったと思えるような面白い科目にはめぐりあえてないなというのが正直なところ。

このあたりの感想は別途まとめたい。

プライベート

3人目の子供が産まれた。大変だけど楽しいです。
子供が3人になったことで今まで以上に自分のために使える時間が減ったのか?についてはまだよくわからない。時折夜泣きに悩まされる以外はそこまで劇的に変わった感じはしない。ただ洗濯など家事の負荷が全体的に少しずつ上がっているかもなという感覚はあり、家族でうまく分担したり金で解決できることは解決して省力化を図ったほうがいいかもしれない。

2023年にやりたいこと

1年という長期的なスパンで目標を立てるのがとても苦手で長続きしないので、基本的には毎月伸ばしたいことを棚卸ししてその都度自分が一番やりたい!と思ったことに投資していきたい。
CRE という仕事にやりがいを感じているしまだまだ全然できるようになっていないので引き続きそこを頑張っていきたいなと思いつつ、うまくいけばいくほど業務でプロダクトのコードを書く仕事からは離れることになると思うので
プライベートでコード書く習慣をいかに作れるか、が来年は大事になりそう。

また、特別技術的に学びたい領域はないものの、 Web フロントエンドの新しいライブラリだのなんだのの使い方をキャッチアップすることに対して若干の疲れというか虚無感(これを繰り返していても自分はエンジニアとして何も成長できないんじゃないか、という)みたいなものを最近は顕著に感じるので
来年はその割合を減らしつつ、もうちょっと流行り廃りに左右されないことを学びたい。大学に入学したモチベーションもそれなので。

先日、 Rust 界隈で有名な helloyuki さんが 2022年学んだ技術|helloyuki|note というブログ記事で

余談ですが今年は大学で使われるような教科書を買ってきて何分野か読むことにハマっていました。教科書は意外とコスパがよく情報も網羅的なので、特定のトピックを学びたいとなった際に何冊か読むのが好きです。

と書かれており、そうそう自分もそんなふうに1つのテーマに腰を据えて勉強したいんだったという気持ちを再確認した。

2022年11月のふりかえり

先月に続いて1ヶ月単位で書く。

前回:2022年10月のふりかえり - dackdive's blog

🚀 先月の伸ばしたいことリスト

11月も先月に続き「react-testing-library での良いテストの書き方を学ぶ」でした。
結果は、またしても進捗ほぼ0でした。

11月からまた大学の講義がスタートしたことと、月の中盤から後半にかけて Google タグマネージャー(GTM)を学びたい衝動に駆られてそちらを優先してしまったことなどが主な理由。
あと、伸ばしたいことリストに書いたときと比べてこれを学ばねばという緊急度や重要度が下がってしまい、それにつられてモチベーションも下がってしまったというのがありそう。

✨ やったこと

大学(UoPeople)の新学期が始まった

11/10 から大学の新学期がスタートした。今期は Programming 2 – CS 1103 を受講している。

以前受けた CS1102 と同じく、いわゆる普通のプログラミングの講義かつ言語は Java なのであまりモチベーションは高くない。
が、週によってはトピックが Stack や Queue といったデータ構造であったり Recursive Descent Parser というパーサーだったりするので、ちょっとだけコンピューターサイエンスを感じられて楽しい。

今期はなるべく課題に使う時間は抑えめにして、その分学びができるだけ大きくなるよう講義内容を自分なりにアレンジしたい。
たとえば教科書に書かれてるサンプルコードは全部 Kotlin で写経するとか。

Google タグマネージャーについて学んだ

本を一冊買って読んだ。

基本的なところはわかったがあまりまだ手を動かせてないので、reading-list のアクセス数を見られるようにする、などチャレンジしたい。

📝ブログ・登壇

ブログ1件のみという結果でした。

ブログ

💬 所感

1ヶ月はほんと一瞬。それでも強い気持ちを持たないと月初に立てた目標に全然手を付けられずその月が終わるということになりがち。

💪12月のテーマ

改めて興味ないものは一旦消して整理した。上位2件がいずれも新しいものになっている。
1つめの Linux のしくみは発売されたときから気になってたので、この機会に買ってみた。これを UoPeople と並行して少しでも読み進められれば万々歳って感じだと思う。

2つめのテクニカルライティングというか日本語スタイルガイドについては、以前 LINE のミートアップで知って買ったものの積ん読状態だった。が、最近社内でこれを有志で読もうという話をしていてモチベーションが再度高まったのでやっていくことにした。

💸 買ったもの

特になし。

「現場で使える Googleタグマネージャー実践入門」を読んだ

自分で作ったサイトのアクセス数分析ができるようになりたいなと思って Google アナリティクスとかを調べていたところ、Google タグマネージャー(以下 GTM)という存在を知ったので一冊本を買って読んでみた。

この本について

現場で使える Googleタグマネージャー実践入門 | マイナビブックス より引用。

■本書の特徴
Googleタグマネージャーの学習環境を構築できる
→ミスを恐れずにトライアンドエラーできるよう、本書では学習環境の構築から解説します。デモ環境で学習できるので、だれかに迷惑をかけることなく実践できます。
 
・逆引きとして、用途に合わせた項目がすぐ見つかる
→実際の現場でよく使われる事例を中心にまとめてあります。困りごとからすぐに事例を見つけられます。  
UAからGA4の移行にも対応できる →UAからGA4への移行にも対応できるよう、それぞれの設定方法を併記しています。新規設定だけでなく、移行にも利用いただけます。

発売日が2022年06月22日で GTM でググった中では新しく、また自分は手を動かしながら学べる系の本が好きなので良さそうな印象を受けこの本にした。

章の構成は以下。

Chapter1 Googleタグマネージャーとは
Chapter2 学習環境の構築
Chapter3 Googleタグマネージャーの導入
Chapter4 基本操作
Chapter5 現場で使える逆引きレシピ 基本編
Chapter6 現場で使える逆引きレシピ 応用編
Appendix 現場で役立つTips

感想

「GTM なんもわからん!」という状態でまず読む本としては良さそうに思った。
自分はある程度ネットの情報を調べた後にこの本を読んだのだが、GTM ってなんなの?GA との関係性は?とか、GTM の構成要素であるタグ・トリガー・変数の説明などは非常にわかりやすかった。

手を動かす系の本として、気軽に試せる環境を提供してくれてるのも良かった点。ただ1から順を追って学ぶハンズオンっぽい内容ではなく、後半(Chapter 5 & 6)によくあるユースケースをカバーしたレシピ集があるので気になったものをかいつまんで試す感じ。

レシピの一部を載せる。

# Chapter5 現場で使える逆引きレシピ 基本編

5-1 Googleアナリティクスの導入(UA, GA4)
5-2 外部リンククリック数の計測(UA, GA4)
5-3 メール送信(mailto)クリック数の計測(UA, GA4)
5-4 電話番号タップ数の計測(UA, GA4)
5-5 ボタンのクリック数の計測(UA, GA4)
5-6 SNSボタンのクリック数の計測(UA, GA4)
...

# Chapter6 現場で使える逆引きレシピ 応用編

6-1 オリジナルの変数作成
6-2 さまざまなファイルクリックの計測
6-3 仮想ページビュー数の計測
6-4 精読ページビューの計測
6-5 ブログの執筆者名・カテゴリー名の計測
...

書籍の内容とは関係ないが、最近本を読むときに「最初から最後まで全部読んですべてを理解しようとしない」を意識していて、それがやりやすい本でもあった。
実際 Chapter 4 の途中からはさっと目を通しただけだし、Chapter 5, 6 のレシピもとりあえず気になる Chapter 5 の一部だけやって、残りは必要になったときに読み返そう、という感じで 3, 4 時間程度で読了した。

環境は WordPress で、GTM もプラグインとしてインストールするため、開発者目線では React などで作ったアプリケーションにどう組み込むの?というのはイメージしにくいかも。ここについては Appendix 6 でコードスニペットを直接埋め込む方法も紹介されてはいる。

1つ残念だった点を挙げると、自分は GTM の中でも「データレイヤー」という機能が調べてもよくわからないな〜というのが本を買ったモチベーションだったのだが、データレイヤーについては説明もあっさりしていて、また手を動かして試すこともできなかった。(自分の理解では、データレイヤーは JavaScript を書いてデータを送信する必要があるのだが、WordPress でそれをやる方法がよくわからずだった)

学習メモ

Chapter 1 Google タグマネージャーとは

  • GTMはタグマネージメントツール=「さまざまなタグを一元管理できるツール」
  • Googleプロダクトとの親和性◎。GA4は測定IDを登録するだけで導入できる
  • マスタータグのみで複数のタグを一元管理できる:「ワンタグ」
    • 簡単にタグの追加・削除ができる
  • 1-2 Googleタグマネージャーの三大要素(タグ・トリガー・変数)
    • タグ
    • トリガー
      • 設定したタグを発動させるための「条件を設定する」こと
      • 例:サイト全ページのページビュー計測をGAで行う場合、「ページビュー」というトリガータイプを「全ページ」に発生させる
    • 変数
      • 例:「Page URL」というGTMの変数は現在のウェブページのURLを返す
      • あらかじめ用意された「組み込み変数」と、ユーザー側で新規に設定できる「ユーザー定義変数」の2種類

Chapter 4 基本操作

  • ゴール
    • プロダクト:GA(ユニバーサルアナリティクス)
    • 設定:対象サイトのすべてのページビューを計測できるようにする
  • 4-2 タグの種類について
    1. サポートされているタグ
      • Googleが公式にサポートしているタグ。GAやGoogle広告など
    2. コミュニティテンプレートギャラリー
    3. カスタムタグ
  • 4-9 データレイヤー変数
    • デフォルトでは取得できない独自データをGTMに渡すことで、GTM内でタグやトリガーとして活用できる仕組み

    サイト上でGTMのスニペットコードが読み込まれるごとに、データレイヤーの中にサイトで得たデータが送られ、その送られたデータを基にタグやトリガーが動作しています。つまり、GTMの機能としてさまざまな「タグ」や「トリガー」を利用できますが、それらはデータレイヤーの中に貯まっているデータを活用して動作しているという状況です

    • データレイヤー変数の作り方
      1. JavaScriptの実装
      2. データレイヤー変数の定義
      3. カスタムイベントの定義
      4. カスタムディメンションの作成

2022年10月のふりかえり

試験的に1ヶ月単位でやったことをふりかえってみる。

前回までは四半期おきだった:2022年7〜9月のふりかえり - dackdive's blog

🚀 先月の伸ばしたいことリスト

10月にやりたいと思ってたのは「react-testing-library での良いテストの書き方を学ぶ」でした。
こちらについてはほぼ進捗0という結果に。。。

こうなってしまった要因はいくつかあって、まず月の前半は個人開発で作ってた Google カレンダーの予定を色別に集計する君(生産性可視化おじさんと呼んでいる)をキリのいいところまで作り切る & ブログ書く、というのを優先していたこと。

そして月の後半はイベント登壇の準備で忙しかったこと。

極めつけに最終週は Zod が気になってついそっちを優先してしまったこと、が原因です。

後悔はしていない。が、ぐぬぬ。。。

✨ やったこと

↑でほとんど書いてしまったが、それ以外。

英語の勉強をはじめた

定期的にやってくる「英語勉強せねば」という感情がまたしても押し寄せてきて、同僚氏に薦められた「英語のハノン」という本を買った。

朝の散歩を始めた

運動不足という不安をずっと抱えつつも何も習慣化できてない状態が続いていたのだが、最近は朝のうちに30分ぐらい家の周りを散歩するようにしている。せめてこれぐらいは。。。という。
で、散歩中に何かすることないかな→英語のリスニング勉強にすれば一石二鳥では!ということで英語もスタートした、みたいなところもある。

📝ブログ・登壇

ブログは4件、イベント登壇が1件でした。

ブログ

イベント登壇

登壇資料

💬 所感

仕事面では、8月からはじまった四半期の切れ目ということで慌ただしかったものの一つの節目を迎えられた。今QはCREとしての業務がメインで、やることかなり絞ってフォーカスできたのはよかったと思う。

また、プライベート面では久しぶりに勉強会に登壇してLTしたというのが大きな出来事だった。LTの後のパネルディスカッションがメインコンテンツだったので、非常に考えさせられる質問をいただきながらもモデレーターや他の登壇者の方とわいわい話せたのはすごく楽しめた。

なんとか週内に感想をブログにできるといいな。

💪11月のテーマ

伸ばしたいことリストに動きがなかったので据え置きです!あと、11月から大学も新学期が開始するはずなのでしばらくはそちらで忙しくなりそう。

💸 買ったもの

子供の分も含めてパンを食べると食費もバカにならないなーと思って自家製パンをやってみることにした。まだ2回ぐらいしか稼働してないけどできたて美味い。