Google アナリティクス 4 プロパティを作成し、GA4 での計測を開始する

この記事は個人ブログと同じ内容です

www.ritolab.com


これまで UA(ユニバーサルアナリティクス)で行っていた計測に加え、GA4(Google アナリティクス 4)プロパティの設定を行い、GA4 にて計測を開始するまでを行っていきます。

はじめに

略語が多めに登場してややこしいので最初に整理だけしておきます。本記事で使う略語はそれぞれ以下に対応しています。

  • GA:Google AnalyticsGoogle アナリティクスそのものを指しています)
  • UA:ユニバーサルアナリティクス プロパティ(終了となる従来の計測方式を指しています)
  • GA4:Google アナリティクス 4 プロパティ(移行する新しい計測方式を指しています)
  • GTM:Google タグ マネージャー

GA4 プロパティの作成

まずは GA の管理画面に遷移します。

プロパティにある、「GA4 設定アシスタント」を押下します。

設定アシスタント画面が表示されたら、「新しい Google アナリティクス 4 プロパティを作成する」にある「はじめに」ボタンを押下します。

モーダルが表示されるので、内容を確認して「プロパティを作成」ボタンを押下します。

これで接続済みのプロパティとして GA4 のプロパティが表示されるようになりました。

「GA4 プロパティを確認」ボタン押下するとアシスタントの設定画面に遷移することができます。

ここからそれぞれの細かい設定を必要に応じて行っていきますが、ひとまず GA4 のプロパティ作成はこれで完了になります。

測定 ID の確認

GA4 プロパティが作成できたので、タグマネージャーに設定を行っていくのですが、そこで必要になる「測定 ID」をメモしておきます。

管理画面のプロパティより、「データストリーム」を表示し、先程作成した GA4 プロパティの詳細を表示させます。

詳細情報の中に「測定 ID」が表示されているのでメモしておきます。

GTM 設定

GA4 プロパティでの計測を GTM(Google タグ マネージャー)で設定していきます。

まずは GTM の画面にアクセスします。

タグ画面に遷移し、「新規」ボタンを押下します。

タグの設定より、「タグタイプを選択して設定を開始」を押下します。

タグタイプを選択します。「Googleアナリティクス:GA4設定」を選択します。

タグの設定画面へ遷移するので、ここで事前にメモした「測定 ID」を入力します。

次に、トリガーより、「トリガーを選択してこのタグを配信」を押下します。

トリガーの選択が表示されるので、「All Pages」を選択します。

タグの設定、そしてトリガーの設定内容を確認して、画面右上の「保存」ボタンを押下します。

これでタグの設定は完了です。

プレビューで確認する

タグの設定ができたら、公開する前にプレビューで動作確認を行っておきます。

画面右上のプレビューボタンを押下し、プレビューを開始します。

タグアシスタントが起動するので、確認する URL を入力し、connect ボタンを押下します。

ポップアップが開いて入力した URL のページが表示されますが、この時に画面右下にタグアシスタントのウィンドウも表示されます。

(ブラウザに Google Chrome を使っている場合)この時に、元の画面を見て「For an improved debugging experience, install the Tag Assistant Companion browser extension」と表示されていたら、install のリンクから Chrome 拡張を入れます。

chrome.google.com

あとはサイトを回遊して、タグが動作しているかを確認します。

タグアシスタント側の Tags Fired に GA4 が表示され、GA4 のタグが動作していることを確認できました。

動作確認ができたので、あとは公開ボタンを押下して変更を適用すれば設定は完了です。

GA4 の画面

GA4 タグを公開できたので、GA4 プロパティの画面を見てみます。

まだタグを公開したてなので何もデータが溜まっていないことがわかりますが、タグは動作しているので、リアルタイムの部分だけは確認できる状態であることが確認できます。

また、左のメニューも UA と比べて変わっていることが確認できます。

別の画面を見てみてます。

ご覧の通り、UA のデータは引き継がれないので現状では空っぽです。

ちなみに UA 側の計測も生きているので、GA4 と UA の画面を両方開いてみると、両方計測が行われていることも確認できます。

まとめ

GA4 での計測を開始するところまでを行いました。

今回は、既に GA で計測を行っている(UA タグ設置済み)の状況で、GA4 のタグでの計測を行なう。という状況で進めましたが、例えばタグマネージャーを使っていない場合などもあると思います。

Google が提供しているドキュメントが充実しているので、基本的にはそちらを探せば、GTM 以外(サイトに GA タグを直接設置している場合)でのタグの設置方法もあるので、探してみてください。

support.google.com

support.google.com


現在 back check 開発チームでは一緒に働く仲間を募集中です。

herp.careers

herp.careers

herp.careers

herp.careers

herp.careers

herp.careers

チームのメンバーと開いた勉強会がよかったのでYOWでふりかえる

この記事は個人ブログと同じ内容です

チームのメンバーと開いた勉強会がよかったのでYOWでふりかえる

みなさん、こんにちは。ぐっきーです。

最近チーム内で気になる技術などを勉強するのに、不定期に業務後に集まって勉強会をやるようになりました。

発端としては、「GraphQL に興味があって、 AWS の AppSync を使って簡単に触れるみたいなんで試してみたいんですよね〜」というメンバーの声があったので、「面白そうだから他の人にも声かけて仕事終わりに試してみようよ!」というやりとりからでした。

メンバーのslack投稿
メンバーのslack投稿

今回は、勉強会をやった結果、自分の中でどんな気づきがあったかを YOW の手法でふりかえってみました。

YOW

YOW とは 、「行動」と「その結果」を分けて考えやすい手法で、事実関係が明らかにしやすいことが特徴です。

Y: やったこと

O: 起きたこと

W: 分かったこと

に沿って順に書いていき、事実を元にどんなことが分かったかをふりかえります。

参照:

ふりかえり

さっそくふりかえってみました。

今回は、 Figjam を使い、30分間を測ってその中ででてきたことを付箋に書き出していきました。

以下、ふりかえりのアウトプット:

YOWのアウトプット
YOWのアウトプット

慣れてくると変わるかもですが、初挑戦ということもあり YOW を出すのに時間がかかってしまいました。

もしチームでやってみるときは事前に少人数でトライアルをやってみるなり、時間は多めに確保するなりしてみるといいのかもしれません。

また、ふりかえりのスコープを過去2回開催した勉強会全部を含めてふりかえりました。

その結果、2つめの勉強会に頭を切り替えて思い出しをしている間に時間がどんどん過ぎてしまったので、スコープはなるべく小さくふりかえることの大切さを再認識しました。

まとめ

YOW でのふりかえりは初めてだったのですが、Y.やったこと、O.起きたこと、W.わかったことをひとまとめにして書き出すので、因果関係の仮説が言語化できたのがよかったです。

最後に YOW をやってみたことに対して YOW を出してみました。

Y: わかったことから先に出したものがあった

O: YOW は揃えられた

W: 詰まったら順番は気にしないでいいのかも

YOW の順に書き出すことに詰まった時は、どんなことが分かったんだっけ?→なにが起きたからだっけ?→あれをしたからか!という風に順不同で考えても価値はあると思うので、とにかく小さなことでも書き出してみるのが大事かなと思いました。

今後機会をみて、チームでも試してみたいと思います。

最後に

勉強会定着してきたら業務内でできるように調整したいな!

ついでに宣伝です。 現在 back check 開発チームは一緒にはたらく仲間を募集中です。 カジュアル面談も実施してますので、お気軽にお申し込みください!

herp.careers herp.careers herp.careers herp.careers herp.careers herp.careers

また、弊社 CTO 兼 back check の PM を担当している松本の Meety もご用意しておりますので、チェックしてみてね!

meety.net

ユニバーサルアナリティクス(UA)から Google アナリティクス 4(GA4)に移行する

この記事は個人ブログと同じ内容です

www.ritolab.com


Google Analytics(GA)において、2023 年 7 月 1 日(GA360 は 2023 年 10 月 1 日)にユニバーサルアナリティクス プロパティ(UA)での計測が停止するとのことで、GA4 への移行を行うにあたり、新しいプロパティである Google アナリティクス 4 プロパティ(GA4)への移行についてまとめました。

はじめに

略語が多めに登場してややこしいので最初に整理だけしておきます。本記事で使う略語はそれぞれ以下に対応しています。

  • GAGoogle AnalyticsGoogle アナリティクスそのものを指しています)
  • UA:ユニバーサルアナリティクス プロパティ(終了となる従来の計測方式を指しています)
  • GA4Google アナリティクス 4 プロパティ(移行する新しい計測方式を指しています)

なぜ GA4 に移行しないといけないのか

support.google.com

発表の通り、従来の UA では、2023 年 7 月 1 日を以て計測が行われなくなります。つまり、GA の UA 画面を見ても何もデータが入ってこなくなります。

計測停止後も GA 上の UA 画面は見られるみたいですが、それも 6 ヶ月後くらいに見られなくなります。

Google AnalyticsUA を終了し GA4 へ移行する背景

UA は web サイトの計測を想定しています。

一方で昨今では、ネイティブアプリ(スマホアプリ)も当たり前の時代になり、クロスデバイスでの計測やネイティブアプリ計測など、web アプリケーションに限らずこういったアプリの計測もスムーズに行えるように最適化された GA4 が発表されました。

UA と GA4 で変わること

マーケター的には「画面 UI が変わる」という部分、エンジニア的には「計測方法が変わる(セッション(ヒット)単位からイベント単位へ)」というのが大きく変わることと言えそうです。

レポートとか作成して GA の画面を眺めるのが日課になっている人には新しい UI への慣れが課題になりそうですが、エンジニア的にはイベントベースの計測となったことで、実はシンプルになったんじゃないか感はあったりします。(やれイベントだ PV だっていうのが一本化された、という意味で)

ただし、GA4 になると API 関連も変更あるはずので(スキーマが異なるため)、Reporting API を使っていたりする場合はそこの対応は必要になりそうです。

いつ GA4 に移行するのが良いのか

できるだけ早く移行するのが最良です。なぜかというとUA の計測データは GA4 には引き継がれない」からです。

どういうことかというと、UA と GA4 は GoogleAnalytics で見る画面が別になります。GA4 で計測を開始した場合、GA4 の画面で見られる数値は GA4 で計測したものだけです。

こんな感じで、GA4 の画面に UA で計測していた時のデータは入ってこないため、事実上これまでの UA での計測データとはさよならしなければなりません。

つまり、過去データがどれだけの範囲必要かによって前もって GA4 での計測を始めておく必要があるということです。

UA と GA4 は同時に利用できる

UA から GA4 に移行すると、それまで見れていた指標がすべて見れなくなり、完全にゼロの状態からスタートするのか?というのが心配になりますが、UA と GA4 はサポート終了までは同時に利用できます。

さらに前述の通り GA 上の画面としても UA と GA4 は別になるので、ひとまず GA4 での計測も開始しておき、2023 年 7 月 1 日 までは移行期間として UA の画面と GA4 の画面を両方見つつ、段々と GA4 の UI に慣れていく。ということも可能です。

さらに、GA4 はこれで完成ではなく、UA サポート終了までにも機能追加がおそらく行われていくのではないかと思われるので、そういった意味でも、サポート終了までは UA と GA4 を併用していくという使い方が現時点では良いと思います。(UA にあったのに GA4 ではあれが見れないこれが見れないがもしあった場合に、それがもしかしたら今後見れるようになるかもしれないという意味で。どうなるかわかりませんがここは現時点で諦めるというよりも、継続して情報収集していく姿勢の方が正解だと思います。)

UA のデータは活かせないのか

せっかくこれまで UA で溜めてきたデータがさらっと無くなるのに納得がいかない人もいると思います。

UA で溜めたデータはエクスポートして CSVスプレッドシート等で落とすか、Reporting API で過去のデータを引っ張ってきてどこかに保存することで救出はできそうです。

support.google.com

developers.google.com

UA と GA4 ではスキーマが異なるので、UA のデータを取り出せても両者を統合して分析するとしたら工夫が必要になりますが、ひとまず、UA のデータを取り出すこと自体はできそうです。

まとめ

ユニバーサルアナリティクスのサポート終了アナウンスが出たのは 2022 年 3 月 16 日

blog.google

本記事執筆が同年 4 月 23 日、そしてサポート終了が 2023 年 7 月 1 日、ということで、今から切り替えても GA4 に 1 年以上のデータは溜められそうです。

結局のところ何をしても移行待ったなしのため、早めに対応するのが最良であることには変わりありません。

次の記事では、実際に移行作業を行っていきたいと思います。


現在 back check 開発チームでは一緒に働く仲間を募集中です!!

herp.careers

herp.careers

herp.careers

herp.careers

herp.careers

herp.careers

PHPerKaigi 2022 やっぱオフライン楽しいね

この記事は個人ブログの転機です

PHPerKaigi 2022 やっぱオフライン楽しいね - メガネの日記

はじめに

今年も無事にPHPerKaigi 2022 開催できたこと、本当にありがとうございます!
なんと今年はオフラインと、オンラインのハイブリット開催でした!

今回も PHPerKaigi 2021 に引き続き、コアスタッフとして参加させていただきました

f:id:akki_megane:20220413144423j:plain

オフライン楽しいですね

そしてオフラインはやっぱり楽しいですね!

久しぶりに合った方と近況を雑談したり、
初めて参加くれている方とも話せてとても楽しいものです

ベテラン勢がいつもの感じで、フリースペースで雑談してたり、
みんな血眼になってトークンを探しているを見ると、いつもの感じだなーとほっとしました

↓PHPerの刻印押してドヤって自分です f:id:akki_megane:20220413162143p:plain

アンカンファレンス 今年も無限LTをしました

f:id:akki_megane:20220413164820j:plain

実は2019年から、毎年恒例で無限LTという狂気のLT回を実施しているんですが、
2022年の今年も、現地でアンカンファレンスを実施することができました!

開始当初は 参加表明してくれたのは5人だったのですが、 LTをしているうちに飛び入りで参加したいと手を上げてくれるひとが増え、最終的には10名の方がLTをしてくれました

無限LTにテーマの縛りありません、自分は最近発表された、Lambda Function URLs の話しを当日作って話ました 他にも、notion、kotlin、Dockerの壊し方、高専、などなど今年もバラエティー豊かでとても面白かったです!

LTしてくれたみなさん、LTを聞いてくれたみなさんありがとうございました!
ぜひ来年もやりたいので、みなさんお待ちしております

無限LTの説明
speakerdeck.com

感想

やっぱオフラインは最高でした、設営等の会場準備は大変でしたが、
久しぶりの再開や、新しい出会いなどオンラインならではの楽しさをたくさん味わえました

来年あるならぜひ、懇親会でお酒を飲みながら話したいなー

最後に宣伝

現在 back check 開発チームは一緒にはたらく仲間を募集中です!!

herp.careers herp.careers herp.careers herp.careers herp.careers herp.careers

ZaPASSコーチ養成講座特別セミナーに参加してみた

この記事は個人ブログと同じ内容です

ZaPASSコーチ養成講座特別セミナーに参加してみた


こんにちは、back check の開発メンバーのぐっきーです。

チームではスクラムマスターの役割を担当しています。 日頃どうしたらチームにアジャイルな考え方が身につくかを考える中で、自分が気づけることは少しずつでてきたのですが、そこにメンバーの共感を得て改善を促せるようになるにはまだまだ自分の力不足だと感じています。

そんな中で、社内の別の開発チームで長年スクラムマスターをやっている方は、チーム合同で行う輪読会や、スクラムマスター同士の共有会で、自分が持てていなかった視点について考え、気づきを得られるようなコミュニケーションをとってくれています。 そこで、その方に相談したところ、ZaPASS JAPAN 株式会社様が開催されるコーチングの「基本スキルとスタンス」とは?〜ZaPASSコーチ養成講座 特別セミナー〜をご紹介頂き、この度参加してきたので、そこで感じたことをまとめます。

zapass.co

コーチングとはなにか?

そもそもコーチングとはどんなことをするものなのか、という明確な定義はありません。

コーチングを認識するには、コーチの語源を理解するとイメージがしやすいかと思います。コーチは、馬車が最初にハンガリーのKocsという街で作られたことに由来して、馬車のことをcoachと呼ぶようになってできた言葉です。

つまり、コーチングの文脈ででてくるコーチは、馬車のように相手の方がたどり着きたいと思っているところにたどり着けるように一緒に関わっていく人のことを指しています。

改めて、コーチングをオーソドックスに定義をするのであれば、夢や目標実現のサポートのために、なんでも幅広くやることです。

学んだこと

このセミナーでは、1. インプット、2. インプット後に感じたことの話し合い、3. 共有を繰り返す方法で進められました。 その中で、インプットとしては主に以下の内容について触れられました。

  • なぜ現代社会でコーチングのニーズが高まっているのか
  • ティール組織について
  • SINIC 理論
  • コーチングの語源
  • コーチに求められるコンピテンシー
    • 対話力
  • コーチングの対話モデル
    • GROWモデル + H
  • 3大スキル
    • 聴く
    • 質問する
    • FB / 承認
  • ティールで重要な観点
    • パーパス
    • ホールネス
    • セルフマネージメント
  • コーチングはこうではない
    • 指示命令型ではない→問う
    • 延長線上ではない→Moon shotを目指す
    • 予定調和ではない→Jazz
    • 理路整然にではない→あるがままに
  • 4大傾聴スキル
    • うなずく
    • あいづち
    • ANGEL EYE
    • おうむ返し

特に印象的だった話

コーチとは、いままでの当たり前の先を共に探求していくパートナー

一昔前は、コーチングとはゴールに向かってどうしたら早く達成できるかの壁打ち相手でした。 現在は、ゴール達成のニーズはありつつ、より重要な動きとして、組織に所属するメンバーの人生そのものにフォーカスを当てたコーチングに会社がOKを出すように変わってきました。

なぜなら人生そのものにフォーカスした方が、結果として会社でのパフォーマンスに直結すると考えられているからであり、今後もよりますますその考え方は強くなっていきそうとのことでした。

その上で、現在は企業が組織として進化していく上で、ボトムアップ型でセルフマネジメントと自己実現を満たすことで、業務のパフォーマンスの向上を狙うような組織運営のナレッジが少ないことから、企業としてコーチと二人三脚で新しいスタイルを模索する企業がでてきているとのことでした。

ソフトウェア開発でもウォーターフォールからアジャイルに切り替えようとする企業が増えてきている中でアジャイルコーチやスクラムマスターという職種が出現している点でとても共感しました。

ZaPPAS では、このようにコーチングをスキル単体としてではなく、大きな視野にスコープを持って、社会に求められているコーチングとはどんなものなのかを捉えて学ぼうとしているとのことでした。

場の雰囲気

場の雰囲気もうひとつ、小寺毅 講師の場づくりがとても心地よかったことが強く印象に残っています。穏やかな喋り口調、自分のルーツや考え方(あるがまま)の開示、会話のテンポ、話者の言葉を受け止めて承認する聴き方、柔和な表情など、会話の中のひとつひとつの所作から自分も話していいんだという気持ちにさせてくれるような不思議な体験でした。 まるでひとつのコーチとしての理想像をみた気がしました。

twitter.com

おわりに

今回のセミナーを受けて、私自身含め、チームが自己管理型の組織として、目標達成のために進化するモチベーションを保ち続けられるようになるためには、その目標を達成することがメンバーひとりひとりがやりがいや自己実現など、人間としての欲求を満たすことにもつながると認識できる状態が必要だと感じました。 今後、メンバーが特に大切にしたいことを可能な範囲でチームで共有し、働くことで充実感を得られるような、上質なコラボレーションのできるチームをみんなで築いていきたいなと考えています。

さいごに少しだけ宣伝です。

現在 back check 開発チームは一緒にはたらく仲間を募集中です!! 私たちと一緒に、 back check を通して「信頼が価値を持ち、信頼によって報われる社会の実装」に挑戦してみませんか?

herp.careers herp.careers herp.careers herp.careers herp.careers herp.careers herp.careers

ポイント制&相対見積もりへの移行の経緯とプランニングツールを自作したお話

こんにちは、匠平@show60です。

back check 開発チームではプランニングポーカーを用いたタスクの見積もりを実施しています。

その作業を支えるべく、フルリモート勤務のチームでもオンラインでプランニングポーカーを行えるツール Okimochi Planning を作りました。冬休みの自由研究として (勝手に) 取り組んだのですが、チームで実際に約3ヶ月ほど運用し、改良を重ねて基本仕様としては問題ないものになったかと思っています。

今回は back check 開発チームが行ってきたタスク見積もりの経緯と、自作プランニングツールについて紹介させていただきます。

時間&絶対見積もりから、ポイント&相対見積もりへの移行

back check 開発チームがスクラム開発を導入した当時、チケットの見積もりはタスクの消化時間を単位として、絶対見積もりを行っていました。

この見積もり方法には2つの大きな問題があったのですが、チームのスクラム開発の成熟度向上とともに徐々ストーリーポイントを用いた相対見積もりへと移行していきました。

フィボナッチ数列を用いて不確実性を認める

大きいチケットの見積もりは不確実性が高くなります。小さいタスクが "1時間で終わるか2時間で終わるか" は見積もれるかもしれませんが、"6時間かかるか7時間かかるか" は不確実性が高すぎるため見積もりの難易度が上がります。

これを解消するため、「大きいものほど不確実が高い」を表すことができるフィボナッチ数列を見積もりに用いました。数列が "0, 1, 2, 3, 5, 8, 13 ..." という単位で上がっていくので、例えば「6時間かかりそうだな」と思った場合は、6は数列に含まれないので近接する 5 か 8 とする必要があります。

ja.wikipedia.org

フィボナッチ数列の導入により、不確実なものの見積もりは不確実であることをチームとして認めることができ、"6時間か7時間か" といった不毛な議論を防ぐことができます。

こうした非線形の数列も、見積もりのスケールにふさわしい。見積もりの対象が大きくなると不確実性が増えていくという様子にうまく対応しているからだ。

参考: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法 - P75より

相対見積もりを用いてスキル差をなくす

この時点での見積もりは、「このタスクは自分なら6時間かかる」といったような見積もりを行っていました。

個人のスキル差があるため、当然見積もりの結果にも差異が出るという問題があります。特に back check ではメンバーのマルチスタックな働きを推奨し、自分が得意でない分野のタスクにも取り掛かる機会があるためこの課題は顕著に現れていました。

この解消のために、相対見積もりを導入しました。あるタスクの見積もりを決め、それと比較したときのボリュームを見積もるという方法です。このときタスクの消化時間に換算しません。

例を挙げてみます。

【前提】
・タスクA: すでに完了しているタスク
・タスクB: これから見積もるタスクで、タスクAよりも実装ボリュームが大きい
・開発メンバー1: タスクAは2時間で実装可能。タスクBはタスクAより3倍程度の大きさだと考える。
・開発メンバー2: タスクAは4時間で実装可能。タスクBはタスクAより2倍程度の大きさだと考える。

【絶対見積もりの場合】
タスクBを見積もるとき、
開発メンバー1は3倍程度と考えるため、6時間と見積もった。
開発メンバー2は2倍程度と考えるため、8時間と見積もった。

【相対見積もりの場合】
開発チームとして、タスクAを1ptと据え置いて、他のタスクはタスクAと比較して見積もるものとする。
タスクBを見積もるとき、
開発メンバー1は3倍程度と考えるため、3ptと見積もった。
開発メンバー2は2倍程度と考えるため、2ptと見積もった。

最終的にチームの見積もりとして収束させる過程において、相対見積もりではタスクの大きさだけを考慮して議論すればいいのに対して、絶対見積もりでは個人のスキル差も考慮する必要があるため複雑です。場合によっては「開発メンバー1が実装することになるだろうから6時間にしよう」と個人に依存した結果にもなりかねません。

相対見積もりを用いることで、個人のスキル差を排除し、タスクの大きさだけに注目した見積もりを実施できるようになります。

また相対見積もりは絶対見積もりと比較して見積もりがしやすいという利点もあります。

人は10倍以内のものならうまく見積もれる、という研究がある。自分の住んでいる街のことなら、いろいろな場所への相対的な距離をうまく見積もれるはずだ。 [中略] もしこれが、月面までの距離や隣の国の首都までの距離だったら、はるかに不正確な見積もりしかできない。

参考: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法 - P74より

ここで重要なのは、相対見積もりのための基準を何にするかですが、back check 開発チームでは、過去に完了したタスクから適切なものをピックアップして基準チケットと据え置いています。新規参画メンバーには分かりにくいという課題も出てくるのですが、そのときは基準チケットを更新するなど柔軟に対応する姿勢を取っています。

自作プランニングポーカーツールの紹介

開発チームは基本フルリモートのため、オンラインでプランニングが可能なツールを探していました。

チームでいくつかのツールを試してみましたが、どれも痒いところにあと一歩手が届かないものばかりだったため、「なければ作れ」ということで作ってみました。

f:id:show-hei:20220331172259p:plain
okimochi planning

okimochi_planning

2022年始の冬休みの期間で作り、新年一回目のリファインメントから実際に利用を開始しました。

実際に運用してみると必要な機能が見えてきたので、ユーザー (チームメンバー) からのフィードバックを元に次のリファインメントまでに実装しておくという開発サイクルを続けました。運用開始から約1ヶ月ほどで現在の形に落ち着いています。

ファビコンが Nuxt のままだったり、デザインがシンプルすぎるなどせめてそこくらいは直してから出せよって感じなんですが、自分に "Second best tomorrow" と言い聞かせてこの場でシェアします。

基本的な使い方

  1. 「Create New Room」でプランニング用のルームを作成
  2. 作成されたルームの URL を共有し、メンバーがルームに入室できる
  3. カードを選択しポイントを見積もる
  4. 「Reveal」で全カードをオープンする
  5. 「Clear」で全カードをリセットする

ここがポイント🤘

  • Reveal されたカードはポイント数値昇順でソートしているのでカード数のカウントがしやすいです
  • 入室するが見積もりには参加しない人 (PO など) のために、Voter ボタンで切り替えることで閲覧モードにすることができます
  • Reveal されているときに入室すると、次の投票からしか参加できません (遅れずに投票しようね)

といった簡単な機能ではありますが、基本機能は備えているので、ぜひ試してみていただけると嬉しいです。

さいごに

私たち back check はリファレンスチェックを日本の採用のスタンダードにすべく日々奮闘中です。一緒に市場を盛り上げたいという仲間を募集しております。

herp.careers

herp.careers

その他のポジション もありますのでぜひこちらもご覧ください!

Udemyのデータサイエンティストコースを一通りやった

こちらは個人ブログの転載です

note.com

PMとしてデータを正確に把握することは非常に重要だと考えたときに、統計学的な有意性、ディープラーニングを用いたより正確なデータモデリングの作成において体系的な知識が必要になると感じ、Udemyを探していたところ 【世界で37万人が受講】データサイエンティストを目指すあなたへ〜データサイエンス25時間ブートキャンプ〜 という講座が95%OFFで販売されており、興味本位で購入してみた。 実際にやってみたら定価でも十分なクオリティーであり、自分のような非データサイエンティストでも理解しやすい内容だったので、感想を書いてみる

学習できる内容

この講座では下記が学習できると書いてある

  • データサイエンティストになるために必要な一連のツールについて学ぶことができます
  • 統計分析、NumpyやPandasなどを使ったPythonのプログラミング、高度な統計学上の手法、Tableaau、StatsModelとScikitLearnを使った機械学習の実装、TensorFlowを使ったディープラーニングの実装
  • データの前処理の方法
  • 機械学習の背景にある考え方
  • Pythonを使って統計上の分析をする方法
  • Pythonを使った線形回帰とロジスティック回帰分析
  • クラスター分析と因子分析
  • 実生活における実践問題を通じた深い理解
  • TensorFlowをはじめとした、ディープラーニングを進める上で必要とされるツール
  • 過学習・過少学習とその解決方法について
  • 訓練用データ、検証用データ、テストデータの概要と具体的な実装方法について
  • 最先端の機械学習アルゴリズム(Adamなど)の概要と実装方法について
  • 信頼区間や検定など、少し難易度が高い統計上の知識
  • 機械学習の全体像と、それぞれの用語の深い理解
  • 汎用性の高い実装方法について
  • p値やt値といった統計上の指標と回帰分析との関係について
  • バッチ処理の概要と実装方法

かんたんにサマリをすると、

  • データに対峙したときに、統計学上の有意な形でデータをサマライズできるようになる
  • 各種分析手法(回帰、分類など)をどういうときに適応すべきかわかるようになる
  • 統計学をもとに、各種フレームワークを用いた機械学習ディープラーニングの実装の方法がわかるようになる
  • 上記をPythonを使って実際にプログラミングして求める手法がわかるようになる

というところで、非学習者でも一個一個丁寧に教えてくれるので、講義が終わったときには、たんにツールを使えるという状態ではなく、なぜそのツールを使う必要があるのか、そのツールを使うとどういうものが求まるのかということが体系的に理解できるようになる。

特に印象的だったもの

このコース、全部で26hもあるそうで、当然全部を紹介しているととんでもない量になってしまう。特に印象的だったものを書いてみる。

  • p値やt値といった統計上の指標と回帰分析との関係について
    • さらっと書いてあるものの、前半の統計学の手法においては、このテーマがかなり中心的にあったように思う。p値やt値は仮設検定(何かしらの仮設が有意であるといえるかどうかの判定)において重要な数値を持たらす。この数値によって仮設の有意性が図れるということで、具体的な例をもとに検定を行うことで実際のビジネスのシーンでどうやって活用されるのかの片鱗が見えた。
  • 機械学習の背景にある考え方
    • 機械学習はインプットとアウトプットの間のブラックボックスをなすものであるという考え方がとても腑に落ちた。ここでこう書くだけだと当たり前のようにも思えるが、実装を通じて意識するべきは「適切な問い(=ほしい結果)」の設定と「適切な情報の提供(=前処理などを通じたデータの整理)」にのみ集中することで結果を得ることができるというのが結構衝撃だった。
    • 基本的なこの考え方と、ベースとなる知識を持っていれば、仮に今後何かしらの壁にぶつかっても有識者に適切な質問の投げかけができ、彼らの返答も理解できるようになるのではという実感を得られたので、機械学習を業務に取り入れる心理的ハードルが一気に下がった。
  • Pythonを使って統計上の分析をする方法
    • 今回はロジスティック回帰だけやり、他の分析手法は一旦飛ばしてしまった。一方でどういう分析がどういう意味を持つのかというのは理解できたので、今後必要に応じて選択できるようにインデックスは貼っておく

学習をする上で用いた環境

本講座ではAnacondaを用いた環境設定方法を紹介していた。一方で自分の環境はMacであり、Anacondaを使った経験もないことから、環境の差異が発生すると面倒であるという点、また今後の実務においての使いやすさを鑑みてDockerの環境を選定した。

docker のimageとしては jupyter/docker-stacksにあるイメージが非常に使い勝手が良かったので、こちらを用いている

また、エディターはVSCodeのRemote Containerで作業。カーネルの選択などもDockerイメージ内部のPythonを選択することで簡単に実行できるのがとても良い

{
        "name": "Tensorflow Env",
        "dockerComposeFile": [
                "../docker-compose.yml"
        ],
        "service": "tensorflow",
        "workspaceFolder": "/home/jovyan/work",
        "settings": {},
        "extensions": [
                "ms-toolsai.jupyter",
                "ms-python.python"
        ]
}
version: "3"

services:
  tensorflow:
    image: jupyter/tensorflow-notebook
    ports:
      - 10000:8888
    volumes:
      - ./src:/home/jovyan/work

上記設定だけで、あとはVSCodeのReopen in Containerを選択するだけで環境が立ち上がる。とても楽。

本講座はGoogle Drive上に講義に用いるソースコードやデータなどが保管されており、都度ダウンロードしてzip解凍する形式をとっていた。 zip解凍後のディレクトリをそのままVSCodeDnDすれば環境に展開できたので、これも開発者体験としてはとても楽なのでおすすめ

今後の活かし方

本講座ではあくまで与えられた数値をもとにモデル化し、評価するというところまでで収まっている。十分実案件でも使える知識は身についているとは思うものの、実際に自分でやろうとすると理解不足なところが浮き彫りになるので、その際にこの講座に立ち返り、復習していくことで知識を身に着けていこうと思う。 また、問の立て方は理解したものの、有意性が事前にわかっている問であることが前提であるため(講義である以上は仕方ない)、適切な問いを建てることが難しそうだなと思った。ここはいくつか実際のデータを活用することで感覚的に理解できるようになれればと思っている