Timee Product Team Blog

Timee Product Team Blog

タイミー開発者ブログ

LeSS' Yoaké(レスの夜明け) Asia 2024に参加して感じたことをトークしてみました!

こんにちは。今回はLeSS' Yoaké(レスの夜明け) Asia 2024 というカンファレンスに参加したメンバーの内、3名で記憶に残ったセッションやトークについてざっくばらんに会話をしてみたので、その内容を一部編集したうえでブログにまとめさせていただきます。

登場人物の紹介

  • raz
    • プロダクトエンジニア。昨年まではスクラムマスターをしていました。
  • maho
    • バイブスキング。昨年からスクラムマスターをはじめました。
  • shihorin
    • スクラムマスター。2024年5月タイミーにジョイン。

印象に残ったセッションやトークはなんですか?

Last Day午前中のOST(オープン・スペース・テクノロジー)の様子。

shihorinが参加したテーブルでは「偉くないけど組織を変えたい」というテーマでディスカッションしていました。現場から組織へアプローチするにはどうすればいいのか、どんな課題がありそうなのかを話してみたかったので、このテーブルに参加。実績や感謝を積み重ねていった先で、上層部からの信頼を得て話せる機会を作っていくことが大事そう、といった内容でディスカッションをしていました。


shihorin:OSTの「偉くないけど組織を変えたい」というテーマが印象に残っています。現場は忍耐が必要だ、コツコツやろうと思っていても、それを組織の上層部と握れていないと結局覆されてしまうことがあるという話を中心にしていました。上層部が求めているのは、一般的に見えやすい数字であることが多く、実際にうまくいっているのかどうかは現場に近づかないとわかりません。だから、数字に表れるような成果をほしがってしまう一方、現場としては「数字だけじゃないんだよ」という声があって難しいという会話がありましたね。

raz:なるほどね。そのテーマ、確かにOSTでありましたね。Slackで見た記憶があります。偉いほうがやりやすいのはそうですけど、それは「トップダウンでやれ」と言っているのと同じです。深く考えずに言いますけど、アジャイルとかそういう最近の考え方で言うと、ズレている感じはしますね。

maho:場合によっては、トップダウンがあってもいいとは思うんですけどね。

raz:両方大事ですよね。

maho:うんうん。ただ、トップダウンだけだとコミットメントするのが難しいときはある気がしますね。

raz:すべての人が納得しないとうまく進められないから、推進する人が偉いかどうかはあんまり大事じゃないのかなって。もし推進する人が偉い人と会話も不可能みたいな立場だと、相当根気が必要かなとは感じます。

maho:推進する人が持っていたほうがいいもので言うと、逆に何があるといいんですかね。私は一つ、バイブスはあるのかなと思っています。

raz:おお、最近のホットトピックね。

maho:人に感情とかコミットメントする気持ちみたいなものを伝えていくうえでは、やっぱりバイブスの力って強いんですよね。その場にいるからこそ共有できるものだと思っているので、もちろんバイブスがすべてを解決するとは思っていないんですけど、大きな影響力があると感じます。推進する人にバイブスを作り出して伝えていく力があると、広がりやすく共感も得られやすいのかなと。そこからコミットメントが生まれやすい感覚を持っています。

raz:mahoさんにはぜひ、バイブスをテーマにしたブログを書いてもらって。

maho:BasのセッションでもLeSSの導入の話があったじゃないですか。あのときに同一拠点でチームメンバーが可能な限り直接会える環境にできたほうがいいって言っていたと思うんですよ。直接会えるほうがバイブスは伝わりやすいので、その場にいるっていうことが強く影響する。仕組みでそれを起こしやすくするのはオフラインなのかもなと思いました。

shihorin:確かに、オンライン上の切り取られた情報だけだとバイブスが伝わりづらいのかもしれないですね。

maho:不可能ではないとは思うんですけどね。オンライン上でもバイブスってあると思うんですけど、なかなか作り出すのが難しい。少なくとも情報は限られてしまうので、ライブ感はその場にいるほうが強いのかなと思います。

shihorin:今の推進する人の話を聞いて、私とmahoさんが座っていたテーブルにいたLINEヤフーの方たちとの会話を思い出しました。LINEヤフーではLeSSのチームの中にスクラムマスターはいない代わりに、スクラムを推進するチームがあるそうなんです。推進チームでは、開発者やPMの中から有志でスクラムを推進したい人たちを集めて、スクラムマスターの役割を共同でやっている。話をした方たちは、まずスクラムを一緒に盛り上げてくれそうな素直な人をその推進チームに引っ張ってきて、挑戦してもらっていると言っていました。最初から自分で手を上げて推進していきたいと言えると一番いいとは思うけど、いい意味で巻き込まれてみるというのも選択肢としてあるのかもしれないなと感じました。誘ってくれたので乗っかってみるみたいな。それもバイブスなのかもしれないですね。

raz:そうですね。やっぱりオンラインだと他のチームの様子がわからないじゃないですか。巻き込まれたいなとか、あっちに行きたいなっていう気持ちをあまり持てない感じはあります。

maho:そもそもわからなかったら、そういう気持ちにもなれないですよね。

raz:そういうムーブメントを起こすのがオンラインだと難しそう。オンラインだと空間的な距離が遠くて見えないから。自分から見ようとしなければ見えないので、推進をするのが難しいんだろうなと思いますね。

maho:オンラインだと「ちょっと向こうで何かやっているな」「気になるな」とかもないですもんね。

raz:たとえば、チームのSlackチャンネルを全部見て追っているとか、そこまでしている人は一定知っているかもしれない。でも、今のタイミーの規模感だと、全部見るのは逆に情報量が多すぎてノイズになるから、チャンネルを抜けている人もいると思います。僕も抜けちゃってますけど……。結果、全部の情報が遮断されるから「別のチームが何をやっているのかよくわからない」みたいな人が増えるような気がします。

maho:今のrazさんの話を聞いて思ったんですけど、オンラインだとそういうのも“情報”になりがちかなって。LeSSの夜明け初日のグループワークで、五感で学ぶ話があって、五感が使われにくいのはオンラインの弱点かもと思いましたね。他のチームが何をやっているのかは、Slackだと単に文字情報になりがちですけど、同じオフィスで隣合って仕事をしていたら会話が聞こえてきて、楽しそうな様子を感じるとかがありますよね。より五感が使われやすい。その辺は人の心を動かしやすいという意味で、やっぱり違いなのかもしれないなと思います。


続いては、初日のCraig Larman氏によるKeynote「AI & HR: Evolving Organizations in an AI World」から、AIとの向き合い方について考えさせられたことを話し合いました。


raz:僕は最初のKeynoteの「AIエージェントを使って生産性が爆上がりしていった結果エンジニアの形が変わる」という話が印象に残っていて、価値観を変えるタイミングの一つなのかなと思いました。今後は元気にデジタルデバイスを扱える人からすると「AIを使いこなせない」ことを驚かれる時代になっていくんだろうなと。きちんと「価値観のアップデートをしていかないとね」と伝えていく必要があるのではと思います。

あと、XでEbackyさんが「LeSSだから大規模で」という考え方じゃなくて、その時代や状況に合わせてちゃんと変化していくことが大事なんじゃないかなと話されていたのに共感しました。僕らはアジャイルな人間である限り、価値観のアップデートを常にしていかないといけないよなと思いました。AIで生産性が十倍百倍千倍と上がっていくのはすごいけどね。個人的には、そうなった結果として、自分たちの価値観のアップデートが必要になる時代が来ると考えています。ただのツールじゃなくて、考え方や価値観が変わるものなんじゃないかな。使いこなすことが前提みたいな感じですかね。

shihorin:そのセッションの最後で、“ヒューマンスキル”は人間だけが持っているものじゃなく、AIのスキルでもあるという話がされていました。たとえば心理カウンセリングは、人間にカウンセリングされるよりも、AIにカウンセリングされるほうを好んでいる人が多いというデータがあるそうで。ヒューマンスキルではなくなっているというのが衝撃的だったかも。

raz:バイブスはね、ヒューマンスキルですよ。きっと。

maho:AIでもできるようになるかもしれないけど、バイブスはそうであってほしいですよね。価値観のアップデートの話はとても納得したんですけど、その時代に適応して価値観をアップデートしていくうえでは、やっぱり見たいものしか見ないという姿勢はダメなんだろうなという気持ちになりましたね。別に自分に都合のいいものだけ見えているわけではないと思うけど、見たいものしか見ずに固執してしまうと、自分の頭の中で見えていると思っている世界と、現実の世界にギャップが生まれることになる。適応しているつもりでも適応できていないみたいなことが起きていくのかもなと。オープンマインドでいきたいですね。

raz:AIによって人間の仕事がなくなるとかは、どうなるかわからないですからね。なくなると言われている仕事もなんだかんだ残り続けているじゃないですか。逃げ切りマインドで「自分はこのメンタルで最後まで生き抜いて死ぬんだ」というのも考え方の一つとしてはありだと思いますね。たとえば、一生ガラケーを使っている人が悪いわけではない。変えないのが悪いわけではないですけど、選択肢が狭まる可能性はあると思いますね。

maho:確かに。選択肢が狭まっていないかどうかは気にしたい。

raz:「ガラケーでも孫とLINEできないけどいいか」となるのも適応の一つだとは思うんですけどね。

shihorin:LINEができないという悩みを解決したいから「スマートフォンに変えよう」となるのは、内発的動機づけで変えようとしているんですよね。携帯会社から「ガラケーのサービスが終わるので変えてください」と言われても内発的動機づけじゃない。

raz:サービスが終わるなんて知らんってなるんですよね。

maho:使い続けられるなら変えないという選択肢もありますもんね。

raz:そもそも新しい携帯を使いこなす気がないならね。買ってみた結果いいじゃんってなる可能性も、もちろんありますけどね。

脱線しましたが、LeSSだから大規模じゃなきゃいけないみたいなのも違くて、固まった考え方から脱することが大事かなとは思いましたね。

maho:確かに、枠を広げるっていう意味ですよね。

参加して気づいたことや学んだことはなんですか?

maho:全体を通じて思ったことはコツコツやることの大切さです。意外と他の参加者が悩んでいることも、そのコツコツができていないからの悩みなのかなと。一撃でどうにかしようとして、うまくできなくて悩んでいそう。セッションとかを聞いても、成功している人の例は地道にやるべきことを積み上げているパターンな気がするんですよね。それが結局一番の近道なんだろうなと思いました。

shihorin:それだけ長く育んでいたのに壊されちゃったという話もありました。プロフェッショナルな人でもそれぐらいの年数がかかるのだと印象に残りましたね。自分は半年スクラムマスターをしてるけど「うまくいかん」と言っているのは、おこがましいのかもしれません。

maho:時間的な遅れがあるフィードバックもありますからね。やってすぐフィードバックを得られるものでもないけれど、人ってすぐに結果を求めがちじゃないですか。

shihorin:そう、ほしくなっちゃう。

raz:でも、そこに根気強く付き合ってくれる会社というのもなかなか難しいんじゃないかな。

maho:結果を出す、実績みたいなのは大事そう。

raz:プロダクトがちゃんと作られていれば、一定大丈夫だとは思うんですけどね。物ができていれば続けられるとは思う。

shihorin:私はスクラムのカンファレンスに初めて参加して、その場だけの学びじゃなく、今こうして話しているように、後で会話をしたときに気づく学びもあるので、学びは点じゃなくて線なんだなって気づきました。

raz:大事ですよね。アフタートークじゃないですけど、セッションについて話して理解を深めること。まず、話すだけでもアウトプットになって理解を深めることになりますし、他の人からフィードバックをもらえる。自分はこう考えたなどの話をシェアしてもらえれば、より学びが強化されますからね。そういうのがオフラインカンファレンスのいいところ。オンラインでも、ちゃんと設計すればできるんでしょうけど。オフラインカンファレンスに参加してよかったですか?

shihorin:そうですね、私は参加してよかったなという気持ちになりました。

読者に伝えたいこと

shihorin:参加してみたらええやん。受け身で教えてもらうんじゃなくて、誰かと喋ったり、OSTなどのコンテンツに積極的に参加したりするのが大事!新米スクラムマスターの方にもおすすめです。

maho:参加して何を感じたか、学んだかを話して整理する。具体的なアクションをする。続けていくことが大事だと思います。アクションに対するフィードバックを得て自分のふるまいを改善していくことが、アジャイルやスクラム、LeSSに向き合っていくことかなと。継続した活動をサボることなく、甘えずにやっていきたいです。一人では対話できないし、継続もなかなか難しいので一緒にやっていくことが大切だと思います。「私がバイブスキングだ」という気持ちでバイブスを大事にしていきたいです。

raz:セッション全部を通して、オーガナイザーはこれが正解だよという言い方はしていませんでした。自分たちで対話して考えることが多かった、変わったカンファレンスだったので、人によっては「全然何も教えてくれない」と思うかもしれません。でも、それがかえって現実的というか……。実際に人の成功体験から学べることはあまり多くないし、失敗やうまくいっていないこと、今目の前で起こっていることに向き合っている時間が物事を進めていくうえでは大事です。レスの夜明けは、そこに焦点を当てたいいイベントだと思います。あのカンファレンスを受け入れられない人は、LeSSの導入が難しいかもしれないので、価値観、考え方をアップデートしていかなきゃと気づいてもらえるといいのかも。こういうイベントは、つい受け身になりがちですが、臆せず参加してみて友だちを作ったらいいと思います。


今回3名でアフタートークをして得られた学び・気づきを、今後の仕事で生かしていきたいです!

Kaigi on Rails2024 に参加しました

タイミーの新谷、亀井、甲斐、須貝です。

Kaigi on Rails 2024 が10月25日、26日の2日間で開催されました。タイミーは昨年に引き続きKaigi on Railsのスポンサーをさせていただきました。

また、タイミーには世界中で開催されているすべての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。詳しくは以下をご覧ください。

productpr.timee.co.jp

この制度を使ってオフラインでは6名のエンジニアが参加しました。

ライブ感ある集合写真

参加して聞いたセッションのうち印象に残ったいくつかをピックアップしてご紹介します。

Keynote: Rails Way or the highway

https://kaigionrails.org/2024/talks/palkan/
https://evilmartians.com/events/keynote-rails-way-or-the-highway-kaigi-on-rails-2024

test-prof の作者であり Evil Martians の principal backend engineer である @palkan さんによる Rails way とは何なのか、Rails を拡張する際に考えていることについての発表でした。

Railsのレールを伸ばすときの考え方として、「カスタムアプリケーション開発者の考え方ではなく、フレームワーク作者の考え方を持とう」というメッセージは個人的に強く刺さりました。一方、Railsアプリケーション開発者にとってフレームワーク作者の考えを持つのは簡単なことではないと思います。rails/rails のコードを気軽に読むのはもちろん、main branch にあるコードだけでフレームワーク作者の意図を読み取るのには限界があるため Issue や Pull Request の議論のキャッチアップも必要だと感じます。
個人としてこの能力を持つための努力をしていきたいと思いつつ、組織としてこの能力を持ち続けるためには技術顧問の採用によってこの部分を補完するのも一つの手としてありそうだなと思いながら聞いていました。
@euglena1215

speakerdeck.com

RailsのPull requestsのレビューの時に私が考えていること

https://kaigionrails.org/2024/talks/yahonda/

Rails コミッターをされている @yahonda さんが Rails に Issue / Pull Request を出すときに押さえておいてほしいポイントと @yahonda さんがコメント・レビューするかの判断基準についての発表でした。

1つ前の基調講演で「フレームワーク作者の考えを持とう」という @palkan さんの発表から実際に Rails コミッターはどんなことを考えながらコメント・レビューをしているのかという流れで繋がりを感じながら聞いていました。
ユースケースがあるか、という観点においては自身も Real world use case? と聞かれてうまく答えられなかったことがあるため Pull Request の例が出てきたときはヒヤヒヤしながら聞いていました。「誰のどの問題を解決したいのか」「その問題はこの解決方法で解決するのが適切なのか」という観点は普段のプロダクト開発においても重要な観点であり、OSS活動においてもプロダクト開発においても意識し続けたいと思います。
@euglena1215

speakerdeck.com

Identifying User Identity

https://kaigionrails.org/2024/talks/moro/

@moroさんによる登壇です。昨年は Simplicity on Rails という話を Kaigi on Rails でされています。私の理解では昨年の登壇で地に足のついた Rails way とは?という話をされていたと思っており、そこからの流れで今年、基調講演も含めて Rails way についての言及が多く、大変にっこりしております。
そのうえで、今回の @moro さんのお話は User Identity にスコープを絞ったお話です。最初の方で「大雑多に『ユーザー』と呼びがち」という話をしてカラフルな名前について言及していたので、てっきりモデリングの文脈で言及される「よく『ユーザー』って名前をつけがちだけれど場面によってそれぞれの『ユーザー』の振る舞いが変わるんだからもう少し適切にモデリングしようよ」という話かと思ったのですが違いました。今回は User Identity です。おそらく、 Identity の話をしたかったが、「ユーザー」という表現にも納得感がない。とはいえ、伝えたい内容が Identity だから泣く泣く「ユーザー」という表現にしたかったので冒頭でエクスキューズされたのかな、と勝手に思っております。
架空のユーザー管理機能をつくるぞ、ということで、 Gem などを使わずにどうすれば適切に identify したい単位としてのユーザーをコードで表現すればいいのか?ということについて説明されておりました。ユーザーが「いる」こと = identity という説明をして、 users テーブルにはほぼ id だけあればいい、というお話です。これにはものすごく納得感があります。たしかに、ユーザーの属性としてメールアドレスだとか名前だとかをつけがちですが、システムとしてそれらが必要な場面はほとんどなく、大体の場合 association としての id (存在していること)さえわかれば十分です。そして、昨今の個人情報の扱いという点でも id とメールアドレスなどのユーザー属性のライフサイクルは異なります。そういう点でもこの主張にはとても納得感があり、かつ登壇内容も明快でわかりやすくとても参考になりました。
ユーザーの登録に関しての説明も良かったですね。「登録しようとしているコト」を表す UserRegistration モデルを用意すると Rails っぽくユーザー登録をハンドリングできる、というのは昨年の登壇を聞いているととても納得感のあるものです。個人的に面白いと思ったのは UserRegistration モデルに belongs_to :user, optional: trueUserRegistration モデルと User の association がオプショナルになりうる、ということです。これは、ユーザー登録途中で離脱した状態を表現でき、なかなかのアハ体験でした。
少しだけ懇親会でお話を伺い、こんな質問をしてみました。「ユーザー登録を表現する UserRegistration のようなイベントモデルを見つけるにはやはりチームメンバーにそれなりのスキルが必要でしょうか?」と。「いやーそうなんですよねー」という回答をいただきまして、このあたりのスキルは「一朝一夕では身につかないんだなー」と思い、今後もさらに興味を持って Rails と向き合っていきたいなと思いました。
@yykamei

speakerdeck.com

Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜

https://kaigionrails.org/2024/talks/haruna-tsujita/

私はHotwireを触ったことがなく、個人的価値観としてはそこまで重きを置いていないのですが、だからこそ、このような場で実際に向き合っている方々の知見を得られるのは有用な機会であると思い、本発表を聞かせていただきました。

登壇者の@haruna-tsujitaさんが所属される株式会社キャタルは英語4技能塾を運営されており、前々職でガッツリ関わった分野なので非常に懐かしく感じています。そして、前々職と同様の少数精鋭だからこそ、バックエンドエンジニア2人が片手間でReactの面倒見るのがしんどいというペインがあり、Reactを捨ててHotwireに至るという意思決定がされたことがわかりました。

この事情は非常に理解できて、私の前職は技術者が数人規模のスタートアップで、Railsエンジニアが片手間でVue JS2を触っていましたが非常に開発量が多くしんどい思いをしていました。また、モダンなJSはプロジェクトの基幹部分の整備が非常に重たく、私は仕組みが出来上がったVueやReactのコンポーネントつくるくらいなら書けますが、まっさらな状態からモダンJSの実行基盤をつくる、という能力を持っていないことが結構なコンプレックスになっています。そして、これは私の個人的感情だけでなくそこを触れる人材を確保し続ける、というのがスタートアップにとっては重荷であるということを経験しています。会場の挙手の反応などを見てもHotwireを利用している企業は一定数存在するらしい、という空気があり、「Railsエンジニアが片手間でフロントを見る」という選択肢においては利用できるのかもしれないという学びを得ました。幸いにして弊社においては専業でReactを書いてくれるフロントエンドエンジニアの面々がいるおかげでこのような心配をせずに済んでいるのですが…。

話を戻しますが、HotwireはSPAとはアプリケーションを構成する考え方が違う、というnay3さんの話を孫引きして解説してくれているのがまた面白い話で、SPAのコンポーネント単位の考え方から離れて、違うURLで部品の差分を表現する「Web紙芝居」と呼ばれるちょっと昔に逆行した仕組みを敢えて用いることで設計をコントロールしているのは興味深いです。

ある程度ちゃんとした組織なら私はSPAを推すでしょう。ですが、数人規模の会社でよりにもよって私がテックリードをしなければならないような危機的状況に陥った場合、もしかするとHotwireは助けとなるかもしれない。そういう示唆を得られた登壇でした。

(甲斐 宏味)

speakerdeck.com

Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -

https://kaigionrails.org/2024/talks/igaiga/

igaigaさんによるRailsらしいモデル設計とその分割についての発表でした。ご自身もおっしゃっていたようにpalkanさんのオープニングKeynoteの内容とも重なるところがあり、自分はこの手の話が好物なのでとても楽しく聞かせてもらいました。
モデリングをする際にイベント型モデルを見いだせるとRailsのレールにぴったりハマることが多いというのは自分の実感にもよく当てはまるところで、Railsアプリケーション開発者としてこのあたりのコツを掴んでいるかどうかは大きな差になると思います。イベント型モデルを発見できるとControllerはそのイベント型モデルに対するCRUDになるので基本のアクション(create, show, update, deleteなど)で表現できるようになり(いわゆる「DHH流ルーティング」)、このレールに乗せていく感覚を得られると開発が楽しくなってきます。
このあたりの話はigaigaさんが参考資料に載せられていたtexta.fmというポッドキャストでもよく議論されているので、このセッションが面白いと思った方にはぜひ聞いてほしいです。特にep3の「Low-Code Development」ではイミュータブルデータモデリングにも触れており、論理モデリング段階でupdateとdeleteをしないという思考の制約を入れるとイベントを発見しやすくなる、といったテクニックをt-wadaさんがされていて非常に勉強になります。
@sugaishun

speakerdeck.com

 


 

今回の Kaigi on Rails は Conceptual な発表が多かったように思います。そのおかげで Railsway とは何なのかをより一層理解できました。
Kaigi on Rails を運営してくださったオーガナイザーのみなさん、発表されたスピーカーのみなさん、スポンサーとして Kaigi on Rails を盛り上げてくださった各企業のみなさんありがとうございました!

今年も一昨年もスポンサーのブース抽選に外れブース出展できなかったのですが、来年こそはブース出展できることを楽しみにしています。来年はブースで会いましょう!

 

また、Kaigi on Rails の後夜祭として LT イベントを TOKIUM さんと永和システムマネジメントさんと 11/12(火)で共同開催します。Kaigi on Rails ネタや Kaigi on Rails によらない Ruby/Rails ネタなどいろいろなことをお話しする会になるかと思うので、興味があればぜひご参加ください!

tokium.connpass.com

BigQuery + Looker Studioでt検定した話

こんにちは!タイミーでデータアナリストをしているkantaと申します。

普段はマーケティングの皆様とCM施策やCRM関連の分析を担当したり、他部署向けの講習会を企画したりしております。11月から半年ほど育休を取得予定のため、育休前最後の仕事(?)として当ブログの執筆を担当いたします。

さて、今回は「BigQuery + Looker Studioでt検定した話」と題しまして、その方法をご紹介できればと思います。

なぜ BigQuery + Looker Studioでt検定をしたいのか?

タイミーでは、BIツールとしてLooker Studioを使っていますが、分析の中でいくつか機能の不足を感じる点があります。その一つが、今回のタイトルにもなっているt検定です。t検定はその施策の効果が有意であったか、有意でなかったかを推定するために非常に重要な要素です。PythonやRなどのプログラミング言語だけでなく、Excel、スプレッドシートおよびLookerでも実施できます。

しかしながら、Looker Studioではt検定がサポートされておらず、他のツールで出力した検定結果をインポートする必要があります。(2024年10月現在)

そうなると、一つの検定を実施するために以下の三つを管理しなければなりません。

これらの管理工数を少しでも削減するために、以下のような構成でLooker Studio上にt検定結果を表示したいと思います。

BigQuery + Looker Studio でt検定する手順

それでは、その手順についてご紹介します。

UDFの実装につきましては、以下のブログを参考にさせていただきました。

BigQueryで始めるt検定 - Re:ゼロから始めるML生活

1. UDFの作成

BigQueryにはユーザー定義関数(UDF)という機能があり、SQLまたはJavaScriptで関数を作成できます。この機能を利用して、JavaScriptでt検定のUDFを作成します。

1-1. JavaScriptライブラリ「jStat」のダウンロード

GitHubリポジトリからjstat.jsをダウンロードします。

https://github.com/jstat/jstat/blob/1.9.6/dist/jstat.js

1-2. 任意のGCSバケットにjstat.jsをアップロード

GCSバケットにアップロードし、バケット名とファイルパスを控えてください。

ここでは、YOUR_BUCKET 配下にlibraries/jstat.js として作成したものを記載します。

1-3. p値を算出するUDFの作成

以下のクエリをBigQueryで実行します。

YOUR_PROJECTYOUR_DATASETは事前に作成しておいてください。

CREATE OR REPLACE FUNCTION `YOUR_PROJECT.YOUR_DATASET.studentt_cdf`(t FLOAT64, dof FLOAT64)
RETURNS FLOAT64 LANGUAGE js
  OPTIONS (
    library="gs://YOUR_BUCKET/libraries/jstat.js"
  )
AS """
// スチューデントのT分布を用いて、与えられたt統計量と自由度に対する双方向のp値を計算
return jStat.studentt.cdf(-Math.abs(t), dof) *2
"""
1-4. t検定を実施するUDFの作成

1-3で作成したUDFを利用し、t検定を実施するUDFも作成します。

同様に以下のクエリを実行してください。

CREATE OR REPLACE FUNCTION `YOUR_PROJECT.YOUR_DATASET.ttest_ind`(data ARRAY<FLOAT64>, data2 ARRAY<FLOAT64>)  
AS ((
    WITH dataset1 AS (
        SELECT
            d AS A
        FROM UNNEST(data) as d
    )
    ,dataset2 AS (
        SELECT
            d AS B
        FROM UNNEST(data2) as d
    )
    , mean AS (
        SELECT 
            AVG(A) AS ma, 
            AVG(B) AS mb
        FROM dataset1, dataset2
    )
    , lena AS (
        SELECT 
            COUNT(A) AS len_a
        FROM dataset1
    )
    , lenb AS (
        SELECT 
            COUNT(B) AS len_b
        FROM dataset2
    )
    , Ama AS (
        SELECT 
            A,
            ma,
            A - ma AS A_ma,
        FROM dataset1, mean
    )
    , bmb AS (
        SELECT 
            B,
            mb,
            B - mb AS B_mb,
        FROM dataset2, mean
    )
    , pow_Ama AS (
        SELECT
            SUM(A_ma * A_ma) AS A_ma_2
        FROM Ama
    )
    , pow_Bmb AS (
        SELECT
            SUM(B_mb * B_mb) AS B_mb_2
        FROM bmb
    )
    , S2 AS (
        SELECT 
            (A_ma_2 + B_mb_2) / (len_a + len_b - 2) AS s_2
        FROM pow_Ama, pow_Bmb, lena, lenb
    )
    , t AS (
        SELECT 
            len_a,
            len_b,
            (ma - mb) / SQRT((s_2/len_a) + (s_2/len_b)) AS t_value
        FROM mean, S2, lena, lenb
    )
    SELECT 
        `YOUR_PROJECT.YOUR_DATASET.studentt_cdf`(t_value, len_a + len_b-2) AS p_value
    FROM t
))

2. クエリの作成

以下のクエリを実行し、p値を得ることができます。

実際に使用するときは各グループの数値をARRAY_AGG で配列にして扱うことが多いです。

WITH test_data AS ( 
    SELECT 
        [0.0,5.0,29.0,3.0,4.0,32.5,46.3] AS A,
        [9.0,4.0,5.0,6.0,4.0,2.0,3.0,1.0,2.0,4.0] AS B
) 
SELECT `YOUR_PROJECT.YOUR_DATASET.ttest_ind`(A, B) AS p_value FROM test_data

3. Looker Studioで可視化

3-1. Looker StudioのデータソースでBigQueryを選択

3-2. 先ほど作成したカスタムクエリを記述

定義したUDFはLooker Studioからも実行できます。

3-3. 見た目を整えて完成!

詳細は公式ドキュメントをご確認ください。

手順は以上となります。

BigQuery + Looker Studioでt検定した感想

ここまでお付き合いいただきありがとうございました。今回の最大のメリットは、すでに述べたように、管理すべきツールを減らせる点にあります。

その一方で、実際のデータだとクエリが冗長になり、レビューやメンテナンスがしづらくなってしまう場合もあります。

また、そもそも検定とBIツールによる可視化は分けて行うべきという考え方もあると思い、実装してみたものの用途は限られるという印象です。

あくまで選択肢の一つとして、分析の要件や環境に合わせた選択が必要ですね。

We’re Hiring!

私たちは、ともに働くメンバーを募集しています!!

カジュアル面談も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。

タイミーデータサイエンスグループの働く環境について

自己紹介

こんにちは。タイミーのデータエンジニアリング部 データサイエンスグループ所属の吉川です。

1年前にタイミーに入社し、データサイエンティストとして日々業務に取り組んでいます。

前職では大手ゲーム会社で全社のCRMや離脱予測のモデル構築を担当していましたが、縁あってタイミーに入社することになりました。

まず入社後のミッションは「データを活用したプロジェクトの立ち上げ」でした。 立ち上げにあたり、何に取り組むか、社内の問題を探索し、下記のようなビジネス面とデータ活用面の2軸で取り組む領域やテーマの選定を行いました。

  • ビジネス面:ポテンシャルがあり、ビジネスインパクトが大きいか
  • データ活用面:データ量が多く予測モデルの活用などデータ駆動型のアプローチが取りやすいか

具体的な取り組みとして、顧客のスコアリングモデルを構築し、そのスコアを基に顧客フォローを実施するなど、仕組みの構築を行っています。

この記事の目的

ちょうど1年前にタイミーに入社したのですが、応募や内定承諾の意思決定をする時にこんな情報があったら欲しかったと思ったことを2つ、この記事で書きたいと思います。同じようにタイミーのデータサイエンティスト職への応募や内定承諾を迷われている方がいらっしゃれば、その方の一助になれば幸いです。

1. フルリモートで働けるのか?

入社時はフルリモートでしたが、あくまで一時的な状態で、そのうち出社にならないかという不安がありました。

私の転職理由は、前職は素晴らしい職場だったのですが、フル出社体制で片道1時間30分の通勤を強いられていたことが転職理由の一つでした。朝、子どもがまだ寝ている時間に出社しなければならず、子どもとの時間を確保するために転職を決意しました。そのため、新しい職場でもフル出社になれば、同じ問題の繰り返しになってしまうという懸念がありました。

実際に入社して1年経った今でも、入社直後と変わらずフルリモートで勤務できています。データサイエンスグループでは地方にお住まいの方もいらっしゃるので、フル出社になるということは、よほどの大きな経営方針がない限り今のところはなさそうです。

また、タイミーのビジョン、ミッションと照らし合わせても、この柔軟な働き方は今後も続いていくと考えています。

2. 転職をして、人間関係の資産がゼロの中、リモートで業務を進めるのは大変なのでは?

対面での関係性がある状態でのリモートワーク経験しかなかったため、上記のような不安を持ちました。

入社して1年経ちますが、データサイエンスグループをはじめ協働している他部門の心理的安全性が高く、入社前に抱いていた不安は杞憂に終わりました。

プロジェクトの実例

特に他部門との関係性がない中で多くの関係者と合意形成を図りながら業務を進めるのは、リモートだと大変なのではと考えていました。しかし、タイミーの組織はフラットで階層が少なく、コミュニケーションコストが低いため、リモートであってもプロジェクトマネジメントに大きな困難はありませんでした。

例えば、現在他部門と進めているスコアリングのプロジェクトでは、調整に必要な関係者も多くなく、MTGの場で意思決定できるため、ストレスなくプロジェクトを進行できます。

前々職で同じようなプロジェクトを経験しましたが、階層型組織にありがちな「MTGで方針決定後、さらに上位レイヤーに確認する」ということを何度も繰り返しており、意思決定から実行までにかなりの時間がかかっていました。その時との体感差でいえば、同じことが1/3くらいの期間でできたのではないかと思います。

リモート前提の組織設計

また、タイミーはリモート前提で組織が円滑に回るように仕組み化されています。従来の対面を基本とした働き方前提でリモート環境を組み込むと、情報共有の不足やコミュニケーションの断絶など、さまざまな無理が生じがちです。しかし、タイミーは最初からリモート前提での業務遂行ができるようにさまざまな制度設計がされているので、そのような問題を最小限に抑えられているように感じています。

具体的には、MTGはオンライン・オフラインどちらでも参加が可能だったり、ドキュメントを残して情報共有したりする文化が徹底されています。これにより、物理的な距離に関係なく、チーム全体で一貫性のある業務遂行が可能となっています。

データ基盤の整備

さらに、データ部門に限っていえば、タイミーではデータ基盤が整備されているため、BigQueryを叩けば必要なデータを即時に取得でき、これにより、データ利活用におけるコミュニケーションコストが抑えられていると感じています。

自律的な働き方と組織の成長

こうした環境下なので、自発的に課題を見つけ、自律的に動ける人にとってはとてもやりがいのある職場だと思います。階層が少ないことで意思決定が迅速に行われ、社員一人ひとりの意見やアイデアが直接反映されやすい。だからこそ、データサイエンティストは自身の専門知識と創造力を最大限に活かし、新しい取り組みを通じて組織全体の成長に寄与することができます。

加えて、タイミーでは最新のテクノロジーの活用にも積極的で、生成AIなどの取り組みも始まっています。社内GPTなども利用可能で、そうしたものを活用しつつ、業務効率化を進めています。実際、この記事の作成においても、誤字脱字のチェックに社内の生成AIツールを活用しました。

タイミーはデータサイエンティストにとって技術的な挑戦が可能で、組織的な柔軟性もある非常に魅力的な環境だと思います。

以上、1年前の入社時に、当時知りたかった2つのことを記事にまとめてみました。

今、タイミーへの応募や入社を検討中の方にとって、少しでも参考になれば幸いです。

We’re Hiring!


タイミーのデータエンジニアリング部・データアナリティクス部では、ともに働くメンバーを募集しています!!

現在募集中のポジションはこちらです!

「話を聞きたい」と思われた方は、是非一度カジュアル面談でお話ししましょう!

LeSS Yoake ASIA 2024 Day5 レポート

スクラムマスターの吉野です!

株式会社タイミーはLeSS Yoake ASIA 2024のスポンサーとして参加し、私も招待チケットを利用して現地に行ってきました!

今回の記事はDay5のレポートです!

Day1のレポートはこちら

セッション : 企業変革の現実から考える「組織レベルのアジャイル」への道のり (ABeam Cunsulting)

  • 1つのチームから複数チームへ拡大するパターン
  • 組織改革の形で、大規模な組織にアジャイルを適応するパターン

2軸にて、組織へアジャイルを広めていくストーリーが聞けました!

前者については、スクラムが成功したチームがあっても、2つ目以降のチームに同じ形で導入しようとしても、簡単にうまくいくわけではない、というお話でした。

ふりかえりの質が悪い、Doneの定義が形骸化している、頻発するメンバーの入れ替えに伴い開発が安定しない、というスクラムチーム立ち上げ期に経験する問題。スクラムマスターがチームの「自分ゴト化」をリードし、その後、見守る形へ移行していく流れで各問題の解決に向けて進められていました。

個人的な感想となりますが、かなり共感できたのは「スクラムマスターが背中を見せる」という点です。

スクラムマスターがリーダーシップを発揮するところがスタート地点だと考えています。なぜなら、まずはスクラムマスターがリードし、チームを成功に導き、その後適切にデリゲーションを行なっていく流れが大切だと考えています。

いきなり「xxした方がいいよ」「xxはやめた方がいい」とアドバイス中心になっても、チームおよび個人は受け止めることに心理的なハードルを感じてしまう可能性があります。

そのため、まずはリーダーシップを発揮することが、序盤においては大切だと考えています。

2つ目のパターンについては、大規模アジャイルの導入を成功させたい企業に対し、支援および現場に入ってリードしたお話でした。 経営層もどうすれば良いのかわからない、もしくは、経営層が考える実行計画がある状態からどうやって成功させるかを考えます。 実際にできる人はいるのか?試しに作ってみたら、できる可能性は見出せるのか?という形で、想像と小さく実験することにより、アジャイルの必要性を徐々に知ってもらうとのことでした。

ポイントをいくつか説明する中で、印象的だったのは“アジャイルという言葉を使わない”です。 アジャイルという言葉にはさまざまな印象が紐づいてしまっていたり、言葉に引っ張られてしまっったりで、本当に考えるべきことにフォーカスが当たらない可能性があるとのこと。これは私が好きな考え方でした!私もチームへスクラムを適応していく際には、「気がついたらスクラムをやっている」というパターンを選んだりします(必ずその形というわけではありませんが)。スクラムガイドを読み込み、チームがスクラムを形式から体現するのは大切だと思うのですが、「スクラムをガイド通りに行う」が目的になってしまうケースをいくつか経験してきました。アジャイルやスクラムはあくまで考え方や実行する上での選択肢であり、本当にやるべきことは顧客に届ける価値をいかに高められるか、そして事業をいかに成功させるかにフォーカスすることを忘れないため、あえて初期段階ではスクラムを意識させない形でリーダーシップを見せていくことも行っています。

クロージングキーノート : How to adopt LeSS (Bas氏)

LeSSを導入する前からLeSS導入後について、

  • どのような準備が必要か
  • 最序盤の動きは何が必要か
  • どのような改善点があるのか

を、Bas氏の経験を交えて話されていました。

意思決定はとても重要とのことです。

いくつかをピックアップすると、

  • 私たちのプロダクトの定義はなにか?
    • 内部的なことや小さなプロダクトを含めて大きく定義する必要がある。それは、顧客が思っているよりも小さく定義してしまうと顧客との対話が難しくなる
  • プロダクトオーナーはだれか?
    • 真のプロダクトオーナーは、プロダクトにまつわるお金を辿っていくとわかる。プロダクトの予算の決定権を持っている人はだれなのか
  • 同一拠点で、リアルで顔を合わせながら仕事をする
    • プロダクトの開発が複数拠点を跨いでいたり、チームメンバー同士が顔を合わせることがなく仕事をすると、協働がしづらくさまざまなデメリットの要因となる

というお話が印象的でした。

LeSSだからLeSSのやり方があるわけではなく、他の形式や概念を採り入れた開発をしていても重要とすべきことは同じだと感じました。

自分たちのプロダクトを自分たちが一番理解し、必要な意思決定者を巻き込み、チームがコラボレーションしやすい環境でアウトカム最大化のためにアウトプットを最大化させられる働き方をする大切さの再確認ができました!

Bas氏の苦悩が伝わったエピソードとしては、「マネージャーや経営層が変わった場合、そこまで積み重ねたものがすべてひっくり返ってしまう可能性がある。決して短くない数年間が、経営者の一声ですべて無くなってしまった経験もした。しかし、私はその事象に対して、どうすれば良いのかの答えをまだ持てていない」というお話でした。絶対的な力に抗えない状況は、苦しいですね...。もちろん私も答えを持っていませんが(笑)、一度LeSSを実施できた組織は横断的にノウハウを獲得できていると思うので、再挑戦に向かえるのではないか、と思っています。

以上がDay5のレポートとなります!

直接お話をしたことがなかったCraigさん、Basさんと直接お話ができ、私にとっては貴重な体験ができたカンファレンスでした。

LeSS Yoake ASIA 2024は初回ということもあり、次回以降はさまざまなところでカイゼンが行われると思います!それも、次の楽しみになりそうな印象でした!

カンファレンスを運営されたみなさま、貴重なお時間をありがとうございました!

(お弁当は好きなプレートをチョイスできる形式だったのですが、炭水化物を2つ選んでしまい、お腹いっぱいになりました)

予測の不確実性を定量化できるConformal Predictionをサクッと解説する

こんにちは、タイミーでデータサイエンティストとして働いている小栗です。

今回は、機械学習モデルの予測の不確実性を定量化する手法であるConformal Predictionについてご紹介します。

Conformal Predictionとは

機械学習モデルの予測値がどの程度信頼できるか知りたい場面は多いと思います。

医療診断のように誤った予測が重大な問題につながる状況でモデルを使用する場合、予測の不確実性を定量化してそれを元に判断できると嬉しいです。

Conformal Prediction(以下CP)はUncertainty Quantification(不確実性の定量化。以下UQ)のパラダイムの1つであり、モデルの予測値の集合/区間を統計的に厳密に作成します。

Conformal Predictionで生成される予測集合の例。出典: Angelopoulos, Bates (2022)

続きを読む

LeSS Yoake ASIA 2024 Day1 レポート

こんにちは! スクラムマスターを担当している吉野です!

株式会社タイミーはLeSS Yoake ASIA 2024のスポンサーとして参加し、私も招待チケットを利用して現地に行ってきました!

本記事ではDay1のコンテンツのいくつかをレポートします!

Opening Session

オープニングキーノートは、Craig Larmanさんによる "AI & HR: Evolving Organizations in an AI World" というタイトルで、AIが私たちにもたらしてくれる変化を、AIができることの紹介、AIの変化に合わせて個人の役割の変わり方からチームのあり方の変化、と、徐々にスコープを広げて話されていました。

特に印象的だったのは、一部の専門性をAIが担ってくれる未来はそう遠くないというお話でした。

現在は各スペシャリストで構成されています。 それは、各メンバーがバリューを個々の専門性の領域で発揮しているからとなります。

チームメンバーの専門性が特別必要な領域や、ルーティンワークを必要とする業務は、AIにお任せすることで、個人の時間に余裕を持たせることができます。余裕ができた時間で何をするのか? それは、学習です。それも自身の専門性を深める学習ではなく、他の領域についても学ぶことが大切とのことでした。

そうすることで、個々が専門性を高めるチームではなく、様々なことに関わることのできるメンバーでチーム内の協働を促進し、よりチームの透明性を高められるということでした。

クロスファンクショナルなチームを作ることに苦労されているお話をよくお聞きしますが、このようにAIを使うことで、チーム組成を進めることができるとのこと。

(GLAD Developer = Generative-AI & LLM-Assisted Development)

そして、将来は一人の開発者と複数のAI Agentsの可能性も…

AIが専門性を担ってくれる可能性と、チームの形の可能性を一つ知れたセッションでした。

スポンサーセッション(Red Hat)

Red Hatさんによるスポンサーセッションでは、いくつかのチームでの議論を通しつつ、チームのスクラム/LeSSをより促進させるためには、組織変革へ目を向ける必要があることをメインに話されていました。

また、その組織変革に必要な要素を表す「スターモデル」を通して戦略/構造/プロセス/リワード/人材の考え方について、具体的な例を通しての説明がありました。

実際に使用し、方針を現場で立てるには、各項目のつながりとWhyとなる軸は説明できる必要があると思いますが、観点が簡潔にまとまっているモデルで、とっかかりに使えそうな印象を受けました。

また、その組織を変えることができる人物は「スクラムマスター」とのことです。

現在のタイミーでは「Agile Practice Team」というスクラムマスターで構成される、組織に向き合うチームがあります。

私も所属しているチームで、この発表はチームの存在意義を言語化してくれている!という気持ちになりました。

その他にも、ディスカッションの時間もあり、チームで多くの意見を出し合いました。

1時間とは思えない密度のセッションでした!

The LeSS Company CEOによるトークセッション

フルスタックCEOというパワフルな自己紹介をされていた、The LeSS Company CEOのBastiaan氏によるセッションでした。

LeSSの広がりやどのような場で活用されているのか、世界レベルでのお話を聞くことができました。

また、本セッションテーマについて、次のセッション時間に直接お話を伺いしました。

Bastiaanさん、Basさん、Akiさんとの廊下トーク

本来であれば、LeSS Morning 主催のワークショップの時間だったのですが、偶然にも廊下で3人のお姿を見つけて、話しかけてみました。

お話しした内容のうち、いくつかを以下に記載します。

最適なスケールフレームワークを選択するには? A. やりたいことをマネージャーなどに伝えるのではなく、まずは経営層の困っていることなどに寄り添うこと。システムモデリング(思考)などを使用し、困っていることを明確にする。 その中で、いくつかのフレームワークを当てこんだ時にうまくいくのか、うまくいかないのか、どのようなデメリットがあるのかを明確にする。 まずは、経営層の困っていることやプロダクトの課題を見える化することが大切。 特に、昨今はチームの認知負荷を減らすことが重要視されている傾向がある。多くの経営層の悩みにつながっており、あなたの場でも関係する可能性があるので見てみると良い。

Stage of Agileのデータから、LeSSの割合が少なくなっていて、SaFEの割合が多くなっている。これはなぜなのか? A. ガードナーに伺ったところ、実際のLeSS利用率は増えている。ガードナーは7000人にヒアリングしている。State of Agileの方は1000人しかデータを取っていないので、どのような人に向けてのアンケートかで、内容が変わってしまう。また、その人の意思とは反するデータになっているケースもある。例えば、ボスが変わってしまったことで、利用しているフレームワークがガラッと変わってしまうなど。なので、データの信憑性としてはそこまで高いものではないため、ある程度参考値ぐらいに考えた方が良い。

(名刺もいただきまして、「困ったらいつでも連絡して欲しい!」とオープンに接してくれたのがめちゃくちゃ嬉しかったです!)

スポンサーセッション : LINEとヤフーそれぞれの組織でのLeSS実践奮闘記

LINEヤフーより、nakoさん(@nako418)の登壇でした。

LeSSに挑戦し、難しい点に当たりつつもLeSSの実践を進めていったお話でした。

印象的だったのは、常に何ができるのかという選択肢を考え、一番最適な形を選択し続ける動きをされていたことです。

例えば…

  • フィーチャーチームとコンポーネントチームのどちらが良いのか?(理想と現時点)
  • オーバーオールイベントの参加者はどのような人を集めるのか?

など、要所要所の考える必要があるポイントでしっかりと選択肢を洗い出し、都度最適と思えるものを理由と合わせて選択して実践していくことは、とても参考になりました。

また、困ったお話についても、バックログの整理方法など多くの人が向き合うことになりそうな問題をピックアップされていて、すごく共感が多かったセッションでした!

(整理は、ひとまずエピックレベルで並び替え、必要になる上位のものに一旦フォーカスしていくとのことでした)

Q&A Craigさん / Basさんに質問Time

一度業務で抜けたため終盤のみの参加でしたが、それでも濃い質問と鋭い返答が多い印象でした。

例えば…

質問 : マネージャーがいない組織における、責任の所在は?生産性の可視化ができていない、となった場合の問題は誰が責任を負うのか?マネージャーがいない組織において、どのように解決していくのか。

回答 :

  • チームが責任を持つことが大切
  • スクラムマスターがそれを促す
  • 人数の少ないマネージャーができるのであれば、人数の多いチームメンバーもできるのではないか?

“マネージャーでないとできない” という制約を個人の中に持ってしまっていたことに気がついた瞬間でした。大切なのは、“なぜチームが気にしないのか” ということを考え、システムとシステム構造を変えることが大切と話されていました。

ディナー

(写真を撮っていなくて残念…) 8種類ぐらいのビールと美味しそうな夕食が並んでいて、ビュッフェスタイルの懇親会でした。 ビールを何回もおかわりしつつ、多くの方とお話しして回りました。

そのため、夕食にはほとんど手をつけず…

イベント全体で時間が押していたため、1時間と短めの懇親会でした。 (もっと多くの方と交流したかった…!!)

終わりに

以上でDay1のレポートとなります! 運営の方にお話を伺ったところ、初めての大規模開催とのことでした。

機材トラブルや時間が押してしまった等、いくつか大変そうなシーンもありましたがあの規模のカンファレンスを開催されていたのはめちゃくちゃすごかったです! (同じ規模のイベントをいつか私も開催したい)

まだDay5がありますので、引き続き楽しみつつ学んでいきたいと思います!