コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『大吉祥寺.pm』に行ってきたよメモ

大吉祥寺.pm - connpass』に参加してきたのでそのメモです、

各発表の感想

ざっと見たものだけピックアップで… ※資料スライドは見つけたら貼ります。


大吉祥寺.pm 基調講演

感想

  • 出てくるフレーズが一つ一つ面白いご自身の歴史の発表
  • 前夜に行われた生存者バイアスナイトを地で言っている内容だった
  • 人に歴史あり、というのを感じる発表だった

関連リンク


多様性の時代を生き抜くキャリアプラニング

感想

  • キャリアプランニングの考え方の話
  • 日本では総合職に対してジョブローテーションをさせる考え方があるが、その根底は個々人の長所の発掘なのかもしれないなと改めて聞いて思うなど
  • ときにはインフラ、ときにはフロントエンドみたいにできると自分の長所を見出しやすいのかもしれない

関連リンク


開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ

感想

  • カスタマーサクセスからWebエンジニアに変わって景色の見え方が変わった、という内容の話。
  • お互いのコミュニケーションの話で、何を大事にするといいかということを改めて感じる。
  • 異なるコミュニティ文化圏の人たちにうまく伝えることって大事
  • 個人的に強烈に違和感を感じる部分があったので、それに関してはどこかで書き留めたいなと思っている。

関連リンク


君たちはどうコードレビューする(される)か

感想

  • コードレビューをどうするかという話
  • 個人的にこの手の話を見るたびに、目指すべきは「チームの共通見解の構築」が第一の目的になるんだろうなとは感じている。
    • どこまで行っても品質の「担保」にはならないので、その部分は品質を守るためにあるいくつかの防御壁の一つぐらいの感覚
  • 最近このコードレビューに至る前にADRなどで仕様の議論をして相互理解を図るのもテクニックの一つなのかなと思いつつある

関連リンク


組織のスケーリングと持続性

感想

  • エンジニアに求められることと、その先の事業貢献する話。
  • スケーリングしたのに売上が増えないと、逆回転して退職につながるというのはなるほどなと思う話だった。
  • 半自動的にプロダクトの未来や事業の未来を自分ごとに落とす仕組みがOKRなのではないかなと思い、この話と連動させると理にかなっている仕組みなのではないのか?とか思ったりなどした。

関連リンク


Linux コンテナの歴史を追うとコンテナの仕組みがわかる

感想

  • Linuxとコンテナの歴史の話。
  • 登壇自体は途中から聞き始めたので、資料ベースで読み返しをしたのですがコンテナ技術がLinuxの技術と地続きなっているのがスッと入る話でした
  • 「コンテナは仮想じゃないよ隔離だよ」というのは意識しておきたいなと思う一句でした。

関連リンク


デザインのこれまでとこれから

スライドはなさそう

感想

  • ここ10年のデザイン周りの話の振り返り
  • そういや色々使ってましたねというのと一斉を風靡したinVisionがサービス終了したのが驚き
  • みんな意外とAdobeFigmaの話を知らなそうな反応だった

関連リンク


僕のキャリアとワインと鍋

感想

  • 飲食店であるワインと鍋にまつわるいろいろな話とエンジニアリングの話
  • ゴーストレストランをやって手応えを掴むというところからしプロダクトマネジメント力高いのでは…?など思った
  • 現在のWeb開発のプラクティスってどこにでも転用可能なんだなと思ったし、そういう話もいろいろなところで聞くなと思いました。

関連リンク


ドメインモデリングの現在地点

感想

  • ドメインモデルというがこれは何を解決したいのかなどを掘り下げていった話
  • 複雑さに関して、本質的なものと偶有的なもの、ローカルなもの、グローバルなものと切り分けて行って考えを整理していく過程はただただ聞いてて面白かった。
  • また、最終的にビジネスロジックとバリデーションの話に着地したのも知見が多く、スライドを自分なりに噛み砕いて解釈したい

関連リンク


集中して作業する技術

感想

  • 健康と集中に関するエビデンスが詰まったスライド
  • 健康のためには睡眠と運動が大事…という話題以外にもちゃんと即実践できるものがあってよかった
  • 個人的にポモドーロ計測をやっていた身なので、7ポモが出せるのはすごいという印象
  • デスク環境を整える話はkawasimaさんの話に通ずるものがあった

関連リンク


ノート PC に Linux 入れてみたけど結構良かった

スライドはなさそう、forteeはこちら

感想

  • elementary OSを入れた話
  • かなりMacライクに使えそうなので、軽くてMacっぽくトラックパッド使いたい!って人にはよさそう
  • ただ登壇のときにはワタワタしそうという事例を目の当たりにしました

関連リンク


コミュニケーションをパスと捉えている話

感想

  • サッカーのパスになぞらえたコミュニケーションの話
  • 一休さんの橋の端のような)パスのパスの話みたいにもなったがうなづけるところは多かった
  • 相手の状況を把握するというのと、前段の発表の「勝手に諦めない」という話に通ずるものがあるなと聞いていた。

関連リンク


エンジニアリングじゃないエンジニアのお仕事

スライドは見つけたら貼ります、forteeはこちら

感想

  • エンジニアから技術広報や教育のほうにまわった事に関する話
  • スカウト送ったり送られたりは大変だよね…とは思いながら聞いてました。
  • 時間切れで教育の話は聞けなかったのでスライドが公開されたらちょっと見てみたいなと思いました。

関連リンク


あらゆる重大な選択の際に使えるアーキテクチャ思考

スライドは見つけたら貼ります、forteeはこちら

感想

  • 物事を考えるときは感情だけでなく論理と一緒に洗い出して評価していくと良いよねという話
  • 「全部の非機能要件を拾うのは無理」というのはたしかにそう
  • 現状のコンテキストに合わせて相対する軸を出してあげる考え方は大事。

関連リンク


ぼっちを避けて楽しむためのアノテコノテ

感想

  • コロナ禍によって失われたオフライン勉強会知見をコンパクトにまとめてくれたスライド
  • アイコンしかわからない、とかはかなり多いはずなのでわかるものがあると便利なのはそれはそう
  • ちなみにこのブログはfaviconをアイコンにしたことにより、「なんかみたことある…」が増えた気がします(定性評価)

関連リンク


大人の社会科見学 ~ NTT 技術史料館に行ってみよう!

感想

  • NTT技術資料館の行ってみたレポ&推せるときに推せトーク
  • 子どもの頃は知らないことを知るみたいな側面で好きだったんですが、ある程度大人になるとベースの知識との差分埋めみたいなのができて楽しいよなと思います。
  • ガイドさんもいるみたいなので行ってみたくなりました

関連リンク


僕はまだ見ぬ誰かを動かすために登壇をする。

スライドリンクは見つけたら貼ります

感想

  • 幸福と登壇について、哲学的なアプローチから入る話
  • いわゆる「何者」かになれば幸福を捕まえることができるんじゃないかというところから、そうではなかったんだという話に入るところがとてもキレイに語られていました。
  • 勇気とは何かというのも深い問いだなと思いました。

関連リンク


全体を通しての感想

  • 10年の振り返りもあり、技術的な話もあり、若い層の経験談もあり、抽象的な設計の話もあり、バラエティに富んだ会だなと改めて思いました。
  • 最後に「続けていくことが大事」という話をされていましたが、つくづく自分自身もこのブログを続けていてそう思いました。
    • 自分自身も様々な場所の勉強会で刺激をもらいつつ、自分の記録と周りへの議事録共有のぐらいの気持ちでブログにしたためていますが、たまに誰かの役になったお声はいただくので細々とやりたいなと思っています。
  • 登壇したいなという気概が一段と高まったので、とりあえずYAPC函館とKaigi on Railsかな…とか思っています。
  • もっと本当は The One Person Framework で雑にシュッとつくることもやりたいのでそこもやりたいぞという気持ちに

関連リンク

『アナタはなぜ チェックリストを使わないのか?』を読み終わったよメモ

読んだ本

読むきっかけ

明確にどなたかのツイートかは覚えてないのですが、Twitterなどでオススメされていたのを見たのがきっかけ

本について

この書籍の著者であるアトゥール・ガワンデ氏は外科医かつ公衆衛生学者である。このガワンデ氏は2008年頃に「Safe surgery saves lives checklist」(安全な手術は命を救うチェックリスト)を作り上げたのだが、このチェックリストができあがるまでのエピソードと「チェックリスト」という考え方が汎用的に使えることをまとめた本となっている。

ミスが許されない医療の現場でいかに成功率を上げるかということにおいて、チェックリストが有用であることを様々な角度で語られている。

また、書籍の最後には「チェックリスト作成ためのチェックリスト」があり、普段の生活のチェックリストを作る際にも役立つものとなっている。

読後の感想

チェックリストの本質を見つめ直させる

この書籍ではガワンデ氏が建築業界、航空業界で使われているチェックリストの考え方を取り入れて医療業界に取り入れていくエピソードも紹介されている。その過程を通して「チェックリストが持つ本来の力を発揮するものはどのようなものであるべきなのか」ということもわかる内容となっている。

本質がどのようなもであるか?というのは書籍の最後にある「チェックリスト作成のためのチェックリスト」を見ていただければと思うのだが、この中のチェックリストを開発する際のチェック項目に以下のようなものがある

「各項目は見逃される可能性が高く、必須である」 - アナタはなぜ チェックリストを使わないのか? チェックリスト作成のためのチェックリスト より抜粋

個人的にはこの部分が非常に重要だと感じた。こちらに関しては書籍内で書かれている航空機のチェックリストの事例の話を見ると非常にわかりやすいので、抜粋して紹介する。

単発のセスナ機での飛行中に、エンジンが停止したときのためのチェックリストだ。(中略)このチェックリストには、エンジン再始動の方法が六つの手順に凝縮されている。燃料バルブを開く、予備燃料ポンプのスイッチをいれる、などだ。だが、一つ目の手順が最も興味深い。そこには「飛行機を飛ばせ」とだけ書いてあるのだ。パイロットは、エンジンの再始動や原因の分析に一所懸命になり、最も基本的なことを忘れてしまうことがある。「飛行機を飛ばせ」硬直した思考を溶きほぐし、生存の確率を少しでも上げるためにそう書いてあるのだ。 - アナタはなぜ チェックリストを使わないのか? 第八章 P203-204より抜粋

事故が発生して頭が真っ白になったら普段できていたこともできなくなる、というエピソードはどこでも聞く話ではあるが、それを加味して事故時の対応のチェックリストに盛り込まれている。

チェックリストはマニュアルでも教科書でもない

普段チェックリストを作っているとただの「手順書」となってしまう場合がある、言い換えればマニュアルになってしまう。このことに関して書籍内で「チェックリストはマニュアルでも教科書でもない」と書かれている。

航空機のチェックリストの事例のとおり、良いチェックリストは要点が凝縮されており、それ自体がなにかの手順を説明するものにはなっていない。そうしてしまうと利用者が使いにくくなってしまうし、純粋に手術や航空機の操縦などで細かく書かれた手順をこなすというのは、紙に対してペンでチェックをいれるようなことができないので難しい。

また、マニュアルではないという側面が強く感じられるのは各項目が簡潔に書くべきというところで、マニュアルや教科書は「何もわかっていない」人向けに書かれるものだが、チェックリストは「ちゃんとわかっている人がヌケモレせずやる」というためのものになっている。そのためこの書籍では「プロフェッショナルこそチェックリストを有効活用すべきである」という旨のことがかかれている。こあたりもマニュアルとは異なるというところを表しているなと感じた。

予想外のミスはコミュニケーションで軽減させる。

不確実性が高い事象を取り扱うことが多ければ多いほど、トラブルやミスが起きやすい。それらをカバーするために「チェックリスト作成のためのチェックリスト」には下記のような項目がある。

「チームメンバーのコミュニケーションを向上をさせるような項目を加えること」 - アナタはなぜ チェックリストを使わないのか? チェックリスト作成のためのチェックリスト より抜粋

これは、コミュニケーション不全が多い場所ではミスが起きやすいという話から記載がされている。

著書の中の例だと手術の話がある。手術の実施前に自己紹介や取り組むことに関しての話がされていない状態で挑んだ場合、なにか予想外のトラブルが起きたときに誰にどう頼むべきかもわからず混乱する。ただ少しばかりの自己紹介と簡単な作業の概要に関して手術の前に言葉を交えるだけでトラブルが起きたときに対処しやすい。また事前に喋るタイミングがあれば、不安に思っていることや心配事もお互いに告げやすい。

また、建設現場のエピソードでは以下のように書かれている。

建設を任された専門家たちは個人の能力を過信せず、二種類のチェックリストを使う。単純な手順の間違いを防ぐチェックリストと、話し合いをさせることで予想外の困難も確実にすべて解決させるためのチェックリストだ。 - アナタはなぜ チェックリストを使わないのか? 第三章 P82より抜粋

チェックリストの力を最大限につかう

この書籍を読むと、チェックリストは平時の事前確認や有事のトラブル対応など様々な場面で使うことができることがわかる。また無意味なチェックリストに関して意味のあるものへの変え方も見えてくるので、普段チェックリストに辟易してしまっている人ほど、一読する価値があるような本なのではないかなと思いました。

関連リンク

非機能要件の検討に困ったときに参考にすると良い資料『非機能要求グレード2018』

観点として何をおさえておくといいんだっけ?というときに役に立つのでメモ

対象ページ

システム構築の上流工程強化(非機能要求グレード)紹介ページ | アーカイブ | IPA 独立行政法人 情報処理推進機構

みどころ

「非機能要件って何を見ればいいんだっけ?」と思ったときに自分自身に馴染のある部分に関してはすぐ検討できるが、馴染のない部分は忘れがちになる。そういうときに「一般的にはどういう要素があるんだ?」ということをざっと紹介してくれている。また自分自身が扱うシステムがどの程度のレベルまで担保すればいいのだろうというときに具体的な指標も示してくれる。

メインの資料自体はExcel形式になっており、項目ごとに気にするべき観点とそれに対する対応度合いがレベルで表現されている。例えばシステムが稼働素べき時間を5段階で表しており、レベル3は「1日のうち1時間の停止は許容する」レベル5は「24時間無停止」というような形で項目ごとに守るべき段階を例示してくれている。また、モデルケース別にどのレベルまで担保すべきか?という例示もセットで用意されている。

とりあつかうもの次第で気にするべき非機能要件の要素は変わるが、そこに関しても上からなぞっていくと頭に浮かべておいたほうがいいポイントが見ることができるので、普段非機能要件を整理しない人にはもちろん、普段からやってきていた人もヌケモレチェック用途として利活用できそうな資料でした。

関連リンク

RailsでActiveRecordからidがキーのHashを作りたいときはindex_by が便利

表題ですべてを語るシリーズです。

検証した環境

$ bin/rails -v
Rails 7.1.2

index_byとは

Railsガイドの説明が簡潔なので引用する。

index_byメソッドは、何らかのキーによってインデックス化されたenumerableの要素を持つハッシュを生成します。 - Active Support コア拡張機能 - Railsガイド- 9.1 index_by

今回の事例

レコードのidをKeyにして、Valueに実態のModelのレコードが入っているHashを用意したい場合。今回はBookモデルのすべての値を対象とする。

index_byを使わない場合

以下のような書き方になる

result_hash = Book.all.each_with_object({}) do |object, hash|
  hash[object.id] = object
end

index_byを使う場合

以下のように書ける

result_hash = Book.all.index_by(&:id)

関連リンク

『設計ナイト2024』に行ってきたよメモ

設計ナイト2024【オフライン】 - connpass』に参加してきたのでそのメモです。

各発表の感想

※資料スライドは見つけたら貼ります。


ロジックから状態を分離する技術

感想

  • 純粋関数の話を基軸にいかに容易にしていくのか、という話
  • 入力から必然的に出力が決まるロジック類をDomainとしておこうという発想はよかった
  • 純粋関数の構成デザインパターンの分け方すごくいいなぁと思ったのと、このあたりの話を提唱している人いないのがびっくり

関連リンク


コンポーネント設計ってなんだろう

感想

  • コンポーネント」がどういうものかを見つめて、そこからコンポーネントとそのコアとなる部分の整理に仕方の話に言及した話
  • 個人的には「メンタルモデルの写像をつくる、ではなくメンタルモデルと乖離の少ない設計モデルをつくるように動く」という考え方は持っていなかったので学びが多かったです。
  • 最終的なコンポーネント設計に関しても「アウトサイドインで抽象度を段階的に下げていって設計していく」というのは頭にいれておくとよさそうな考え方だなと感じた。

関連リンク


そのDDDは本当にDDDといえるのか?

www.slideshare.net

感想

  • いわゆる戦略的DDDをちゃんとやるためにはという具体的な話
  • ビジネスと一体になって動かないといけないよね、というところで気にかけるべきところに関しての話が色々でてきてこのレイヤーでの経験値が薄い身としては聞いてて気になるところがあったので資料が後日みれたら読み返したいなと思いました。

関連リンク


オブジェクト指向考古学: 人類は再び DCI の夢を見るか

感想

  • DCI(DataContextInteraction)に関しての話
  • ロール指向という考え方は馴染みやすい考え方だなと示唆が得られた。
  • Webにおけるシステムのオブジェクトは短命なので、状態が変化することよりもどう振る舞うかに強く着目して考えるほうがいいんではないか、というのはRailsActiveRecordとうまく噛み合わせることで巨大化の封じ込めの一助になるのではなどと思ったりした。

関連リンク


コミュニティ/カンファレンス運営を支援する社団法人を設立する話

感想

  • ストレートに法人を設立する話のLT
  • コミュニティも人も推せるうちに推せは本当にそう思いました…
  • ちなみに創設されるのは「一般社団法人日本テックコミュニティファシリテーター協会」とのことです!

関連リンク


Railsでクリーンアーキテクチャを考えてきた

感想

  • Railsでクリーンアーキテクチャをやる話
  • Railsで依存関係の逆転したいとかそういう考えにあまり至ったことがないので、改めてその視点で考えてもいいのかなと思いました。
  • 依存性のルール付けならPackwerkのgemを使うのもいいのではないかなど聞いていて思いました。

関連リンク


やらない事を決める設計

感想

  • やらないことを決めるにはどうすればいいかというお話
  • BtoB SaaSなどだとバーニングニーズどうするのみたいな話なので色々考えること多いですよねという気持ちになりました。
  • プロダクトの不確実性が多いうちは捨てやすく作るというのは改めて大事ですねと思いました。
    • いわゆる捨てやすさの話は前の発表にあったコンポーネントの考え方を活用すればできそうだなという気分にもなりました。

関連リンク


良い開発のためにまず組織を設計せい

感想

  • 組織に関しての設計のお話
  • 不要なコミュニケーションを減らして、頻度を適切に調整するのは確かに大事。
  • 政治力の教科書としてサンクチュアリが出てきたのですが、未読なので読んでみたくなりました

関連リンク


全体を通しての感想

  • 設計という点においては同じでしたが、具体的な実装、アプリケーションの構造としての設計、前段としてのモデリングなどの設計、組織設計などバラエティに富んだ話でした。
  • 抽象的な概念の話も多く、そのあたりは出てきたフレーズを拾って知識補強したいなというところが多かったです。
  • 日本語だとデザインという言葉に関連する設計の話はなかったので、そのあたりも含めるともっとバラエティに富んだ設計話ができそうだなと思いました。
  • 自分自身も思っていることがいくつか発表では出てきたので、何かしらの形で発表することで思考を整理できたりするのかもなと思いました。そのため自分も「設計」ってテーマでちょっと頭を整理したいなと考えています。

Google Tag Manager で Google Analytics 4のユーザスコープのカスタムディメンションを設定する場合は変数を使わないとできない

Googleタグになってからの設定方法がわかりにくいものが多かったのでメモとして。

ユーザスコープのカスタムディメンションとは

GoogleAnalytics4(以下GA4)ではユーザの属性情報などを設定できる「ユーザスコープのディメンション」があるが、独自でディメンションを設定したいときにユーザスコープのカスタムディメンションを使うことができる。 イベントのディメンションなどと異なるのは、ユーザそのものの属性なので、逐一イベント情報としてセットしなくても、ユーザ単位で情報を整理することができる。 たとえばユーザディメンションとして性別などの情報をもっているので、わざわざ毎イベントに性別情報をイベントディメンションとしてセットしなくてもユーザに一度付与するだけで探索に扱うことができる。

なお性別などは従来のディメンションとして用意されているので、公式のヘルプに入れたいものがないかを確認すると良いです。

Google Tag Manager(GTM)でのカスタムディメンションの設定方法

Google Tag Manager(以下GTM)でユーザーのカスタムディメンションを送付するには大きく3つのステップを踏みます。

  1. 送りたいユーザーの情報をGTMで取得できるようにDataLayerにpushする記述を追加する
  2. DataLayerの情報を拾い上げて変数として取得できるようにする
  3. GA4を実行するタグ(Googleタグ)の設定値として「Googleタグ:イベントの設定」変数で設定値を作る
  4. 送信の動作確認をする
  5. GA4側のユーザカスタムディメンションの設定を追加する

今回は udemae_rank というユーザスコープのカスタムディメンションをGA4で設定することを想定して例示を付記します。

1. 送りたいユーザーの情報をGTMで取得できるようにDataLayerにpushする記述を追加する

GTMに読み取る情報を設定する仕組みとして「DataLayer」という仕組みが存在している。DataLayerの情報設定は今回の本筋ではないので割愛するが、詳しくは公式のドキュメント を参照していただきたいです。

GTMで読み込む値として datalayer_udemae_rank という値をDataLayerの値として設定する場合、以下の内容を計測したいページに書き込みます。(細かい位置や制約などは公式ドキュメント参照のこと)

dataLayer.push({'datalayer_udemae_rank': 'B+'});

2. DataLayerの情報を拾い上げて変数として取得できるようにする

GTMではdataLayerの値をGTM上の変数として取り扱う設定があります。こちらも本筋ではないので詳しい説明は割愛しますが、「変数」→「ユーザ定義変数」の新規ボタン→鉛筆マークから「データレイヤーの変数」で設定を作ることができます。このとき読み込みたいデータレイヤー変数の名前を設定して取得できるようにします。

先程の例を踏襲すると、データレイヤーの変数名として datalayer_udemae_rank を記述します。名前は自由につけて問題ないのですが、例では「送信用データレイヤ変数」としています。

GTM上でdataLayerから取得した値を「送信用データレイヤ変数」として定義

3.GA4を実行するタグ(Googleタグ)の設定値として「Googleタグ:イベントの設定」タグで設定値を作る

計測をするためのGA4のタグと連動させます。前提としてGTMでGA4のタグを設定しておく必要があります。

従来GTMを使う場合は、GA4のタグの埋め込み自体はページ事に行うのではなくGTM側から埋め込みます。もし、GA4のタグをGA4で発行できるスニペットを使って埋め込んでいる場合はできないためGTM側にGA4の設定をする記述に変更してください。

2024年6月現在、GTMでGA4の設定をする場合は「Googleタグ」を作って設定します。

Google タグを選んで設定を作成する

このGoogleタグはGA4のタグを設定することができる設定情報になります。こちらも本筋ではないので割愛しますが、公式のドキュメントが非常に分かりづらいのでアユダンテさんの「[GTM] 新しいGA4のタグ設定の仕方 | アユダンテ株式会社」を参照にしてみてください。

このGoogleタグを設定すると、GA4の基本的な動作がするようになります。上記の参照ドキュメントにも記載はあるのですが、この「Googleタグ」の設定項目を調整するとユーザースコープのカスタムディメンションが送信されるようになります。

ユーザースコープのカスタムディメンションの設定方法

Googleタグには共通して送信するイベントの設定をする項目があります、それが「共有イベントの設定」です。そこに「イベントの設定変数」という項目があります。 ここにはGTM側の変数として「Googleタグ:イベントの設定」の変数が設定することができます。

Googleタグ:イベントの設定」には通常のイベント送信情報である「イベントパラメータ」の欄もあるのですが、ユーザスコープの内容を設定したい場合は Google Analytics User Properties の欄の方の設定を追記します。

今回は udemae_rank を送信したいので先ほど設定した「送信用データレイヤ変数」を値にセットし、プロパティ名を送信したいパラメータ名である udemae_rank に設定します。

GA4側で受け取ってほしいパラメータ名を記述して設定する

変数を作成したら、先程設定したGoogleタグ側の設定にも以下のように設定します。

Googleタグ側の「イベントの設定変数」に先程の設定を追加する

これでdataLayer.pushから拾い上げた値をGA4側へ送信できます。

4.送信の動作確認をする

動作確認をする場合は、「タグマネージャーのプレビュー」と「GA4のDebugView」を使うことで、ユーザープロパティの値として設定されているかを確認できます。事例ベースでの説明は割愛しますが、使い方の説明などは以下のアユダンテさんのサイト参照のこと。

5.GA4側のユーザカスタムディメンションの設定を追加する

GTM側で送信するだけしかしていないので、GA4側で利用できるようにカスタムディメンションの設定を追加してあげる必要がある。詳しくはこちらもアユダンテさんのサイト参照のこと。

Google アナリティクス 4 プロパティ(GA4)にカスタムディメンション / カスタム指標が登場! | アユダンテ株式会社

今回の場合は udemae_rank を追加してあげたいので、以下のスクショのような設定を追記してあげる。

範囲をユーザーにして作成する

なお、このカスタムディメンション設定前に到達したイベントは記録されないのでお気をつけください。

関連リンク

『「データモデリングでドメインを駆動する」読書感想会』を見たよメモ

書籍を完走しきれずイベント日を迎えましたが、『データモデリングでドメインを駆動する』読書感想会を見たのでメモです。

各発表の感想

書籍「データモデリングドメインを駆動する」の感想を各々語るスタイルで実施されたので、今回は感想を記載するスタイルでのひとくちメモになります。(お名前はconnpassやTwitterから拾いましたが間違えてたらご指摘ください。。)


magnoliakさんの感想発表

スライドは見つけたら貼ります

感想

  • 整合性の緩急の話は大変共感しやすい部分だなと改めて感じた。
  • ただ「詳細だけを記録してデータを使えばいいじゃない、と思ったがそうもいかなかった」という事例の話があったが、自分自身明確にこの手の話で打ちのめされた経験がないので具体エピソードを聞いてみたかった。

hidenorigotoさんの感想発表

感想

  • 問題領域と解決領域の部分のピックアップが助かりました。
  • ソフトウェア設計を題材にして考えてみるところは思考の訓練として面白そうでした

MadoWindaheadさんの感想発表

発表のもととなったブログは以下

madowindahead.info

感想

  • 利用者目線を持て、といっても自分本位の方に引きずられがちであるという話があり、刺さるものがあった。
  • プリトランザクションという考えの話は興味深かった
    • トランザクション処理の前(プリ)の情報を指すフレーズで、自身が掌握するシステムに入る前の情報のことを指す考え方、という話でした。
  • スチュワードシップなど普段考えない観点ああったのが学びがあった

masatsugumatsusさんの感想発表

感想

  • 「実装が好きな人は、実装的なシステムのモデルとメンタルモデルを合致させようとしてしまう」という旨の話があり難しい話だなと感じた
    • 普段Rails(というかActiveRecord)を利用して仕事しているとうまい折り合いの付け方は難しいと感じている。
  • マスターデータの話に関してはまだ書籍の読み込みが足らない部分なので、自分が理解しているマスターデータとの差分を埋めたいと思った。

kabanyasuさんの感想発表

発表中紹介されていたブログ 杉本啓さんの『データモデリングでドメインを駆動する』を公認会計士が読んだ感想 | コラム | 合同会社オントロジー

感想


Tanaka9230さんのLT感想発表

感想

  • 普段の生活のなかと今回の書籍を並べて考えるときにわかりやすい事例だった
  • 残と残をつなげるというのはややこしいが向き合わないといけないシーンはあるなと感じた。

関連リンク


yu_mi0825さんのLT感想発表

スライドは見つけたら貼ります

感想

  • RDBやアプリケーションフレームワークに引っ張られてモデリングしてはならないというところは大変共感できた
  • ルールにこそコアドメインが含まれているし、そのあたりがおざなりになりがちという旨の話があり、頭にいれておかないといけない考えだなと感じた

tunemageさんのLT感想発表

感想

  • 「よく言語化してくれた」という話をされていたので、基幹システムに携わる方には暗黙知形式知されたものなんだなという雰囲気が強く感じられた。
  • 私が基幹システムを普段やらないのもあったのだが「基幹システムだからわかりにくい部分が多い」というのは本当に感じたので読み終えた暁には書いていただいたブログを眺めたい

関連リンク


veilchenさんのLT感想発表

スライドは見つけたら貼ります

感想

  • Salesforceはつらい。
  • ローコードツール共通の概念ではあるが、よいデータの設計の仕方の勘所がない人がつくると後々辛くなるというのは本当にそうだな…と感じました。

smith_30_さんの感想発表

感想

  • SoRからSoEが生まれる瞬間というのが事例を交えて紹介されていたのでわかりやすかった
  • SoRとSoEのあたりも普段のソフトウェア開発と照らし合わせたときの概念がしっくり来てないので、書籍読みながら咀嚼したいなと感じた

全体を通しての感想

  • 「残」に関しての概念に関して感銘を受けた方が多く、みなさん口々に言及されていたように思う
  • 個人的に最後の感想戦で語られていた、自由度に関しての話に関して考えさせられる部分が多かった。
    • 固定する部分は固定し、可変できる部分を考える。可変の部分は個々人の裁量の可能性にも影響するのでガチガチに固めると新しい発想などが出てこない
    • 日本人の国民性みたいな部分として創意工夫するところがあるので、裁量という概念を置くのは重要そう
  • 書籍が時間の都合上完全に読みきれてないので、読み終えたあとに改めて今日の感想を咀嚼したいと思いました。